SYSTEM AND METHOD FOR ALIGNING REVENUE STREAMS IN A CLOUD SERVICE BROKER PLATFORM - Patent application

Abstract

To provide a system and a method for matching revenue streams in a cloud service broker platform.SOLUTION: A system 700a includes: a transaction mediator that receives all transactions for operations at independent software vendors (ISVs); an ISV rating engine that rates the transactions and sends orders to an enterprise resources planning system; a sales cost (cos.) calculator that generates a matched fee based at least in part on the total revenue and a customer cost fee; and an ISV contract catalog configured to store a plurality of contracts between the ISV and the cloud service broker platform.SELECTED DRAWING: Figure 7A

Description

[Technical Field]

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS This utility patent application claims priority to U.S. patent application Ser. No. 15 / 954,238, filed April 16, 2018, which is incorporated herein by reference.

[0002] The present disclosure relates to systems and methods for billing, and more particularly to systems and methods for aligning revenue streams in a cloud services broker platform. [Background technology]

[0003] Many software vendors now offer their software through online service platforms. Such software-as-a-service (SaaS) platforms allow SaaS subscribers / end users to acquire and use software services hosted by the SaaS provider. SaaS, also known as "on-demand software," is typically priced on a pay-per-use or subscription basis. For example, a SaaS subscriber may pay a monthly (or annual) subscription fee to the SaaS vendor to access the SaaS platform for a set period of time (e.g., one month). Conversely, under pay-per-use pricing, the SaaS subscriber pays the SaaS provider based on the subscriber's usage of the SaaS platform within a given period. For example, the subscriber may be charged based on a fee-per-usage, where usage is measured based on one or more resources within the SaaS platform. In these "subscriber-vendor" structures, the billing relationship between the subscriber and the SaaS vendor is one-to-one, with the SaaS vendor's costs being passed directly to the subscriber, who then pays to ensure continued access to the SaaS platform.

[0004] An alternative system for software service delivery uses cloud service brokers. A cloud service broker is an institution that acts as an intermediary between subscribers / end users and SaaS vendors. Cloud service brokers may aggregate different software services (available from various SaaS vendors) to present an integrated service set (i.e., a cloud service package) to subscribers. In some cases, cloud service brokers may also host software services and act on behalf of traditional SaaS vendors. Additionally, cloud service brokers enable the provisioning and sale of subscriptions to various SaaS vendors at different levels, resulting in a tiered system of downstream resellers. These resellers can then resell the services to lower-level resellers and end users. In some cases, these resellers may price SaaS offerings at a different pricing structure compared to the SaaS vendors and / or cloud brokers.

[0005] Because the cloud service broker is the only entity capable of managing the many relationships in such a software distribution system, billing in a cloud service broker system is managed through the cloud service broker. However, revenue matching and settlement can be problematic. For example, billing complexity in a cloud broker system arises due to the mix of SaaS vendor types, the influence of resellers, and the various billing structures offered by each of these entities. For example, a cloud service package may include multiple software services from multiple SaaS vendors. Each of these multiple software services within the cloud service package may include various billing structures (e.g., a combination of usage-based and subscription-based structures, each with varying incentives and billing attributes). Furthermore, downstream resellers may offer their own unique pricing structures for the cloud service package.

[0006] When subscriber end users acquire software services from a cloud service broker or downstream reseller, billing for these subscriber end users is not a one-to-one relationship as in a traditional "subscriber-vendor" architecture. Instead, subscriber end users in a cloud service broker architecture may be billed based on different pricing within the hierarchy of the cloud service mediated delivery channel. Therefore, implementing such a billing architecture must take into account variations in billing rules and billing architectures from entities across the hierarchy (i.e., SaaS vendors, resellers, downstream resellers, etc.). Furthermore, while differences may exist between billing rules from upstream entities (e.g., SaaS vendors) and downstream entities (e.g., resellers), billing subscriber end users based on one particular entity's billing architecture is inappropriate. For example, fixed markups and discounts may be applied by upstream entities (e.g., SaaS vendors), but the markups and discounts may not be appropriate for downstream entities (e.g., reseller end users). Similarly, if the same billing rules were applied at each level of the software distribution system, it would result in inflexible contracts and rules for software service delivery. Additionally, pricing (and corresponding billing rules) cannot be customized based on the specific type of entity within the distribution channel. For example, direct subscriber end users may be billed differently than indirect subscriber end users. This results in lost revenue across different elements of the software distribution system. Finally, it is also not possible to execute bulk purchases of services that are delivered according to different billing rules, resulting in lost opportunities for larger service distributors.

[0007] Therefore, a need exists for improved systems and methods for aligning revenue streams in a cloud service broker platform. Summary of the Invention [Means for solving the problem]

[0008] In at least one embodiment of the present disclosure, a system for aligning revenue streams in a cloud service broker platform is provided. The system includes a service vendor, a cloud broker, resellers at different hierarchical levels, such as a first reseller, a second reseller, and a third reseller. The system further includes an end customer, who may receive services directly from the service vendor or indirectly through the reseller.

[0009] In at least one embodiment of the present disclosure, a system for aligning revenue streams in a cloud services broker platform includes a marketplace, a service provider database (vendor contract catalog), a partner database, a marketplace broker, optional federation connectors, a transaction mediator, a usage database, a provisioning database, connectors, a scheduler, and a network.

[0010] In at least one embodiment of the present disclosure, a marketplace broker is configured to manage contracts established between various entities within the system.

[0011] In at least one embodiment of the present disclosure, the marketplace broker is configured to store a catalog of available services, is configured to monitor billing usage of connectors, and (optionally) includes cooperating connectors.

[0012] In at least one embodiment of the present disclosure, a marketplace broker is configured to sell services to partners via the marketplace.

[0013] In at least one embodiment of the present disclosure, the marketplace further includes a transaction mediator configured to store billing information for all transactions passing through the system. The marketplace is further configured to store reconciliation-specific details for all transactions passing through the system.

[0014] In at least one embodiment of the present disclosure, a cloud broker may be run by a partner, which operates to offer the services of a service vendor to subscribers.

[0015] In at least one embodiment of the present disclosure, the cloud broker is also configured to maintain a hierarchy of resellers and sub-resellers.

[0016] In at least one embodiment of the present disclosure, the cloud broker and the marketplace broker may operate as a single entity.

[0017] In at least one embodiment of the present disclosure, a method for aligning revenue and cost streams in a cloud services broker platform is provided, the method including determining transactions as they apply over a billing period, initiating the transactions, renewing or initiating them based on transaction attributes of a subscriber's billing cycle, calculating costs for the billing period, determining agreements between service vendors and a cloud broker, and calculating the broker's cost of sales for each period.

[0018] In at least one embodiment of the present disclosure, the method includes keeping records of each service vendor's contracts and subscriptions and calculating each individual service cost for a particular billing period.

[0019] In at least one embodiment of the present disclosure, the method includes calculating costs at each of the service vendors, calculating service costs at a cloud broker, calculating costs at a reseller, and creating a consolidated bill for the end customer.

[0020] In at least one embodiment of the present disclosure, costs are calculated for each of the service vendor, cloud broker, and reseller, and a consolidated bill is generated for the end customer.

[0021] In at least one embodiment of the present disclosure, the method includes reporting attributes of the provisioning operation to a transaction mediator, storing the data in a service usage database, requesting a service usage report for reconciliation with a service vendor, receiving billing rules of the service vendor, calculating total usage of the service, sending the report to an integration connector, sending the report to a marketplace broker, applying a pricing model of the service vendor to generate the usage report for reconciliation with the service vendor, requesting the service usage report for partner billing, receiving billing rules from the partner subscription, calculating total usage of the service, sending the report to an integration connector, sending the report to the marketplace broker, applying a pricing model from the partner, and billing the partner.

[0022] In at least one embodiment of the present disclosure, the method further includes reporting attributes of the provisioning operation to a transaction mediator, storing the data in a service usage database, initiating an estimate of cost of sales per service SKU, executing billing rules of the service vendor, calculating the cost of sales per service SKU, and reporting the cost of sales per service SKU to an ERP system. [Brief explanation of the drawings]

[0023] [Figure 1]FIG. 1 is a schematic diagram of a system for aligning revenue streams in a cloud services broker platform, according to one embodiment.

[0024] [Figure 1A] FIG. 1 is a schematic diagram of a system for aligning revenue streams in a cloud services broker platform, according to one embodiment.

[0025] [Figure 1B] FIG. 1 is a schematic diagram of a system for aligning revenue streams in a cloud services broker platform, according to one embodiment.

[0026] [Figure 2] FIG. 1 is a schematic diagram of a system for aligning revenue streams in a cloud services broker platform, according to one embodiment.

[0027] [Figure 2A] 1 is a flow diagram and components of a method for aligning revenue streams in a cloud services broker platform, according to one embodiment.

[0028] [Figure 2B] 1 is a flow diagram and components of a method for aligning revenue streams in a cloud services broker platform, according to one embodiment.

[0029] [Figure 2C] 1 is a flow diagram and components of a method for aligning revenue streams in a cloud services broker platform, according to one embodiment.

[0030] [Figure 3] 1 is a flow diagram and components of a method for aligning revenue streams in a cloud services broker platform, according to one embodiment.

[0031] [Figure 4] 1 is a flow diagram and components of a method for aligning revenue streams in a cloud services broker platform, according to one embodiment.

[0032] [Figure 5] 1 is a flow diagram and components of a method for aligning revenue streams in a cloud services broker platform, according to one embodiment.

[0033] [Figure 6] FIG. 1 illustrates a method for aligning revenue streams in a cloud services broker platform, according to one embodiment.

[0034] [Figure 7A] FIG. 1 is a schematic diagram of a system for aligning revenue streams in a cloud services broker platform, according to one embodiment.

[0035] [Figure 7B] FIG. 1 is a schematic diagram of a system for aligning revenue streams in a cloud services broker platform, according to one embodiment.

[0036] [Figure 8] FIG. 1 illustrates components of a system for aligning revenue streams in a cloud services broker platform, according to one embodiment.

[0037] [Figure 9] FIG. 1 illustrates components of a system for aligning revenue streams in a cloud services broker platform, according to one embodiment.

[0038] [Figure 10] FIG. 1 illustrates a method for aligning revenue streams in a cloud services broker platform, according to one embodiment.

[0039] [Figure 10A] FIG. 1 illustrates a method for aligning revenue streams in a cloud services broker platform, according to one embodiment.

[0040] [Figure 10B] FIG. 1 illustrates a method for aligning revenue streams in a cloud services broker platform.

[0041] [Figure 10C] FIG. 1 illustrates a method for aligning revenue streams in a cloud services broker platform, according to one embodiment.

[0042] [Figure 11] FIG. 1 illustrates a method for aligning revenue streams in a cloud services broker platform, according to one embodiment.

[0043] [Figure 12] FIG. 1 illustrates a method for aligning revenue streams in a cloud services broker platform, according to one embodiment.

[0044] [Figure 13] FIG. 1 illustrates a method for aligning revenue streams in a cloud services broker platform, according to one embodiment. DETAILED DESCRIPTION OF THE INVENTION

[0045] DETAILED DESCRIPTION OF THE DISCLOSED EMBODIMENTS Reference will now be made in detail to the preferred embodiments of the present disclosure, examples of which are illustrated in the accompanying drawings. Additional features and advantages of the present disclosure will be set forth in the description which follows, and may be obvious from the description, or may be learned by practice of the disclosure. The foregoing general description and the following detailed description are exemplary and explanatory and are intended to provide further explanation of the present disclosure, as claimed.

[0046] 1 , a system for cloud service delivery via a cloud service broker is shown, generally designated 100. The system 100 includes a service vendor 102, a cloud broker 104, a first reseller 106, a second reseller 108, a third reseller 110, and an end customer 112.

[0047] In at least one embodiment of the present disclosure, the service vendor 102 is an entity that offers subscriptions to its clients (e.g., businesses or customers of different sizes). For clarity, the service vendor 102 may also be referred to as a "service provider," although it should be understood that both terms may be used synonymously. Additionally, the service vendor 102 may offer subscriptions to applications and services located on an independent software vendor's hosting server (not shown). The service vendor 102 may further host services subscribed to by customers. The service vendor 102 may be a software development company that develops, supports, and runs services (typically on its own cloud infrastructure). The service vendor 102 also sells and offers subscriptions to its services. It will be understood that the service vendor 102 provides an application programming interface (API) for each of its services. The API may include a set of classes, procedures, functions, structures, and constants provided by the service vendor 102 for use by external applications. The service vendors 102 may include multiple service vendors (e.g., service vendors 102a, 102b, and 102c), such as, for example, Dropbox®, Amazon® Web Services, and Office365®. Each of the multiple service vendors 102 provides various software services such as email, web hosting, file sharing and storage, networking, telephony, messaging, video conferencing, general communications, enterprise resource planning (ERP), customer relationship management (CRM), and supply chain management, to name a few non-limiting examples. It will be appreciated that the service vendors 102 may offer their services to resellers or directly to end customers.

[0048] In at least one embodiment of the present disclosure, the service vendor 102 is configured to monitor usage of its services by resellers and end customers. For example, the service vendor 102a (Office365®) may be configured to monitor computing resource usage resulting from subscribers' use of the service vendor's 102a services. The computing resources may include at least one measured metric selected from the group consisting of one or more computing resources used on an hourly basis, one or more read and write I / O operations, and network bandwidth usage, to name a few non-limiting examples. It will be further understood that the usage measurements may be performed through one or more application programming interfaces (APIs). It will also be understood that metrics obtained from such monitoring may be stored within the service vendor's 102 environment or may be transmitted to other entities in the system 100, such as via the Internet.

[0049] It will be appreciated that service vendors 102 may be configured to apply their own billing rules. For example, service vendor 102b (e.g., Amazon® Web Services) may apply a flat monthly pricing structure, while service vendor 102c (e.g., Dropbox®) may apply a proportional fee for computing resource usage. It will further be appreciated that service vendors 102 may transmit billing rules to other entities in system 100.

[0050] In at least one embodiment of the present disclosure, the system 100 further includes a cloud broker 104. The cloud broker 104 is an entity that provides the functionality to aggregate different software services (e.g., from service vendors 102) via APIs to provision and sell subscriptions to the service vendors' 102 services to various other entities (e.g., resellers and end customers). It will be appreciated that the cloud broker 104 provides user interfaces for different types of service vendors 102. For example, a service vendor that provides communication services (e.g., email) will have a different interface than a hosting or storage service vendor (e.g., Dropbox). It will be further appreciated that the provisioning of different interfaces supports a tiered system of resellers as further disclosed herein.

[0051] In at least one embodiment of the present disclosure, system 100 further includes resellers at different hierarchical levels. For example, first reseller 106 may be a geographically based reseller (e.g., first reseller 106a serves the United States, first reseller 106b serves France, and first reseller 106c serves Brazil). System 100 may further include downstream resellers, such as second reseller 108 and third reseller 110. Resellers may be organized based on any factor, such as geographic distribution, industrial industry, consumer industry, or technology industry, to name a few non-limiting examples. While only a select number of resellers and downstream resellers are shown, it will be understood that system 100 may include any number of resellers and downstream resellers connected by software and hardware systems (e.g., the Internet) of types known in the art, which systems are operable together to perform the functions delegated to the resellers by this disclosure.

[0052] In at least one embodiment of the present disclosure, the system 100 further includes an end customer 112. The end customer 112 may include an individual or a business organization that subscribes to services provided by the service vendor 102 (or services that may at least originate from the service vendor 102). It will be understood that the end customer may receive services directly from the service vendor 102 or indirectly through a reseller. For example, with reference to FIG. 1 , the end customer 112a may receive services from a second reseller 108a, which is a downstream reseller of the first reseller 106a. Similarly, the end customer 112b may receive services from a third reseller 110b, which is a downstream reseller of the second reseller 108b, which is in turn a downstream reseller of the first reseller 106a. It will be appreciated that each of the resellers will be configured to use its own billing and pricing structure, so that each of the end customers 112 may receive different prices and billing terms even if they subscribe to the same service from the service vendor 102.

[0053] 1A , a system for aligning revenue streams in a cloud services broker platform is shown, generally designated 120. System 120 includes a marketplace 122, a service provider database 124, a partner database 126, a marketplace broker 128, federated connectors 130, a transaction mediator 132, a usage database 134, a provisioning database 136, connectors 138, a scheduler 140, and a network 142.

[0054] In at least one embodiment of the present disclosure, service provider database 124, partner database 126, usage database 134, and provisioning database 136 store information generated by system 120 and / or retrieved from one or more sources. In at least one embodiment of the present disclosure, as shown in the embodiment of FIG. 1A , service provider database 124 and partner database 126 may be “associated” with marketplace broker 128, and usage database 134 and provisioning database 136 may be “associated” with transaction mediator 132. Each of service provider database 124, partner database 126, usage database 134, and provisioning database 136 may also be “associated” with a server or computing device remote from marketplace 122, where the remote server or computing device is capable of two-way data transfer with marketplace 122, such as, for example, in Amazon AWS, Rackspace or other virtual infrastructure, or any business network. In at least one embodiment of the present disclosure, the marketplace 122 in which each of the service provider database 124, partner database 126, usage database 134, and provisioning database 136 resides is electronically connected to the service provider computing devices and partner computing devices 104 (e.g., via network 142) and components therein such that they are capable of continuous two-way data transfer with each other.

[0055] For clarity, each of the service provider database 124, the partner database 126, the usage database 134, and the provisioning database 136 is depicted as a single database in FIG. 1A . Those skilled in the art will appreciate that each of the service provider database 124, the partner database 126, the usage database 134, and the provisioning database 136 may comprise multiple databases connected by software and hardware systems (e.g., the Internet) of types known in the art, which are operable together to perform the functions delegated to each of the service provider database 124, the partner database 126, the usage database 134, and the provisioning database 136 according to this disclosure. Each of the service provider database 124, the partner database 126, the usage database 134, and the provisioning database 136 may also be part of a distributed data architecture, such as a Hadoop architecture, for example, for big data services. Each of the service provider database 124, the partner database 126, the usage database 134, and the provisioning database 136 may comprise a relational database architecture, noSQL, OLAP, or other database architectures of types known in database technology. Each of the service provider database 124, partner database 126, usage database 134, and provisioning database 136 may include one of many well-known database management systems, such as, for example, MICROSOFT's SQL Server, MICROSOFT's ACCESS, MongoDB, Redis, Hadoop, or IBM's DB2 database management systems, or database management systems available from ORACLE or SYBASE. Each of the service provider database 124, partner database 126, usage database 134, and provisioning database 136 retrievably stores information communicated to it, as further disclosed herein.

[0056] In at least one embodiment of the present disclosure, the marketplace broker 128 is configured to manage contracts established between various entities within the system 100 (e.g., service vendors 102, cloud brokers 104, first resellers 106, end customers 112, etc.). For example, all subscriptions to services offered by any of the multiple service vendors 102 are governed by a contract, which records the terms of the service, such as pricing, license costs, and service level agreements, to name a few non-limiting examples. Similarly, a reseller (e.g., first reseller 106) may have additional (or different) contract terms, but the end customer's 112 receipt of the service is governed by the reseller's contract terms, not the service vendor's. In such an example embodiment, the ability to provision, sell, and modify a particular service is governed by the applicable contract terms of the service vendor 102.

[0057] In at least one embodiment of the present disclosure, the marketplace broker 128 is configured to store a catalog of available services (i.e., services offered by service vendors or resellers). A service offered by a service vendor 102 is considered "available" when the service vendor 102 has a contract with the marketplace 122. In the process of assigning a contract, the service provider 102 may provide the marketplace 122 with service plans, billing rules, and connectors (e.g., connector 138) for each service (e.g., SKUs as further disclosed herein). The plans and billing rules of the service vendor 102 are stored in the service provider database 124.

[0058] In at least one embodiment of the present disclosure, the marketplace broker 128 is further configured to monitor billing usage of the connector 138. For example, a partner 104a may be an entity that desires to provide a service based on the service vendor 102. When the partner 104a creates a new service offering based on the service vendor 102, the partner 104a operably connects to the marketplace 122 using the connector 138 to enable contracting for the service vendor 102's services. This may be considered "provisioning." For example, with reference to FIG. 1A , the cloud broker 104 may be run by the partner 104a, who desires to offer the service of the service vendor 102. In such an example embodiment, the partner 104a is made "available" through the marketplace 122 through the use of the connector 138 (i.e., the service vendor 102 is made available to the partner 104a through the use of the connector 138). Continuing with this example, partner 104a, once provisioned, may provide services to resellers 106 or even end customers 112.

[0059] In at least one embodiment of the present disclosure, the marketplace 122 further includes an integrated connector 130 configured to receive usage reports from the transaction mediator 132 based on the partner's subscription (as further disclosed herein). For example, an agreement between the marketplace broker and the partner may require that invoices be sent on the first day of each month, and the integrated connector 130 sends a request to the transaction mediator 132 on the first day of each month to receive the necessary data. The integrated connector 130 requests service usage (per service SKU) for a particular service and receives aggregate usage per SKU within the service unit. Because the cloud service broker marketplace in the embodiment shown in FIG. 1A does not operate on direct information from service customers about their activities and transactions performed, the cloud service broker marketplace must extract this information by monitoring transactions passing through the connectors using transaction mediators and integrated connectors.

[0060] In at least one embodiment of the present disclosure, the marketplace 122 further includes a connector 138. The connector 138 is configured for all services (e.g., services offered by any of the service vendors 102). For each of multiple service vendors 102 (e.g., as shown in FIG. 1 ), the connector 138 is configured to distinguish one subscription from another, as further disclosed herein. The connector 138 is configured to identify the source of the service (i.e., the identity of the service vendor 102) and the destination of the service (i.e., the identity of the end customer 112). It will be appreciated that the connector 138 may also receive information about the service during provisioning of the service. In at least one embodiment of the present disclosure, the connector 138 is deployed on a per partner subscription basis, such that the connector 138 defines the partner 104a and its subscriptions. It will be understood that any tenant (e.g., end customer 112) and end user IDs are generated by the cloud broker 104, and the subscription IDs are generated by the service vendor 102 when each of the multiple service vendors 102 confirms successful provisioning to the connector 138. While a single connector 138 is shown, it will be further understood that the system 120 may include as many connectors 138 as necessary to support each of the multiple service vendors 102. For example, if the marketplace broker 128 purchases N subscriptions for N different services, the marketplace 122 may provide N connector 138 instances for each of the N different services.

[0061] In at least one embodiment of the present disclosure, marketplace broker 128 is configured to sell services to a partner (e.g., partner 104a) via marketplace 122 according to a service plan for this particular partner. For each sale of a partner's service, marketplace broker 128 sends a request to a connector hub (not shown, but as disclosed in U.S. Application No. 15 / 005,151, incorporated herein by reference in its entirety, for "PROVISIONING APPLICATIONS USING A CONNECTORS HUB SERVICE") to deploy a connector instance (e.g., connector 138) for the partner (e.g., partner 104a) to operatively connect with marketplace 122 and to coordinate a provisioning channel. Simultaneously, marketplace broker 128 provides billing services to the partner via federated connectors 130 and transaction mediator 132. It will be understood that the marketplace broker 128 operates in a similar manner to the cloud broker 104, except that while the cloud broker 104 provides a channel for selling software as a service, the marketplace broker 128 provides a mechanism for provisioning services that will ultimately be sold as services.

[0062] In at least one embodiment of the present disclosure, the connector 138 is operatively connected to the transaction mediator 132, for example, when provisioning of a service is completed. The connector 138 is further configured to report to the transaction mediator 132, the report including markers of the action such as activation date, provisioning, cancellation, modification, service ID (as further disclosed herein), identification of the cloud service broker, number of services, activation, modification, and cancellation, to name a few non-limiting examples. It will be further appreciated that the connector 138 may report the identity of entities within a hierarchical billing system. For example, the entities may include the first reseller 106, the second reseller 108, the third reseller 110, and the end customer 112. The connector 138 further operates to perform an analysis of the activity by the transaction mediator 132.

[0063] In at least one embodiment of the present disclosure, system 120 further includes a scheduler 140 operatively connected to connector 138. It will be appreciated that in the illustrated embodiment, the services sold include disk space, CPU time (pay-per-use services). Scheduler 140 is configured to retrieve such information and provide tracking of resource utilization (e.g., disk space utilization, CPU time) by sending periodic requests to applicable service vendors 102. Scheduler 140 is further configured to send resource utilization information to transaction mediator 132 on an as-needed or periodic basis.

[0064] In at least one embodiment of the present disclosure, the marketplace 122 further includes a transaction mediator 132. The transaction mediator 132 is configured to store billing information for all transactions going through the system 120. For example, a transaction between the end customer 112 and the service vendor 102a can be of a type such as a purchase of software from the service vendor 102a, a software and / or service upgrade from the service vendor 102a, a software and / or service downgrade from the service vendor 102a, a service cancellation from the service vendor 102a, or the like. In at least one embodiment of the present disclosure, the transaction mediator 132 is further configured to track a service identifier, which is an alphanumeric identifier of a resource type associated with the transaction. The transaction mediator 132 is further configured to track a unit of measure (UOM), such as, for example, the number of units or licenses used by subscribers of the service vendor 102. The transaction mediator 132 may also track the amount of service usage and start and end dates, as well as receive any metering or monitoring of computing resource usage and billing rules from the service vendor 102, to name a few non-limiting examples.

[0065] In at least one embodiment of the disclosure, the marketplace 122 is further configured to store coordination-specific details for all transactions going through the system 120 via a transaction mediator 132. For example, each of the multiple service vendors 102 may have a vendor identifier (ID) associated with it. The transaction mediator 132 is further configured to collect other identifiers, such as, for example, service vendor-side data (e.g., a subscription ID), any other unique identifier, a partner identifier or subscription ID for any reseller or end customer, partner-side data (e.g., an end customer's subscription ID), and an order identifier.

[0066] For every transaction, the transaction mediator 132 must store the minimum amount of data that needs to be reported (if applicable), the vendor's identity, the reseller's identity, the end customer's identity, the billing rules from the service vendor 102 and the resellers (e.g., the first reseller 106, the second reseller 108, and the third reseller 110), and the usage and pricing for each entity in the system 100.

[0067] In at least one embodiment of the present disclosure, the cloud broker 104 may be operated by a partner 104a, which operates to provide the services of the service vendor 102 to subscribers. The cloud broker 104 is further configured to receive usage information for all resource types tracked by the request, and aggregated by resource type, and prorated according to terms indicated by the service vendor 102 (or reseller). Continuing with the previous example, if the service vendor 102a (Office365®) is configured to bill based on the computing resource usage incurred by subscribers, the vendor 102a tracks this information, and the transaction mediator 132 is configured to receive this information.

[0068] In at least one embodiment of the present disclosure, the cloud broker 104 is also configured to maintain a hierarchy of resellers and sub-resellers. For example, the cloud broker 104 may serve a first reseller 106, a second reseller 108, a third reseller 110, and an end customer 112 (as shown in FIG. 1 ). In such an example embodiment, the cloud broker 104 is configured to capture and maintain consumption of cloud services by subscribing entities. It will be appreciated that the cloud broker 104 is configured to enable partners to capture and bill usage of subscribers (e.g., end customers 112), while the marketplace broker 128 may operate to bill partners for usage of connectors 138.

[0069] The transaction mediator 132 is further configured to record with a software agent transactions indicating individual billable provisioning operations of cloud services between the end customer 112 and the service vendor 102. In at least one embodiment of the present disclosure, information related to the transactions is then processed and forwarded to a central system (e.g., the marketplace 122) where the information can be extracted for billing purposes. It will be further appreciated that by monitoring the provisioning flows, the cloud broker 104 can provide real-time billing information without having to rely on the same billing rules imposed by the service vendor 102 data.

[0070] It will be appreciated that revenue matching and settlement functions to balance costs and revenues between the marketplace and vendors. For example, the marketplace broker is billed by the vendor and generates costs. In at least one embodiment, partners are billed per transaction by the marketplace broker through the connector. In at least one embodiment, the marketplace broker generates the revenue stream, and a transaction mediator collects all data about transactions passing through the connector so the marketplace broker can estimate the cost of sales per service (SKU). It will be further appreciated that the marketplace broker has all the data necessary to do this. The marketplace enforces pricing terms and vendor billing rules on partner transactions and reports this to an internal or external ERP system for accounting purposes. A more detailed and updated system is shown in FIG. 7A, and detailed methods are shown in FIGS. 10-13.

[0071] In at least one embodiment of the present disclosure, the cloud broker 104 and the marketplace broker 128 may operate as a single entity, as shown in system 150 of FIG. 1B. It will be understood that the marketplace broker 128 may perform the same functions as the cloud broker 104, as disclosed further herein.

[0072] In at least one embodiment of the present disclosure, the system 150 includes a first reseller 106, a second reseller 108, a third reseller 110, and an end customer 112. The second reseller 108 may include a sub-reseller, although it will be understood that the sub-reseller operates to further resell services from the first reseller 106, as disclosed above. The third reseller 110 may include a tenant that subscribes to services from the marketplace broker 128, although it will be understood that the tenant operates to use the services. It will further be understood that the end customer 112 may be an end user of a tenant (e.g., an employee end user of a company tenant that subscribes to the service) or an end user of a reseller-type entity (e.g., a direct consumer of the integrated software services provided by the reseller 110).

[0073] In at least one embodiment of the present disclosure, the marketplace broker 128 is configured to be operable to provision the first reseller 106, the second reseller 108, the third reseller 110, and the end customer 112 as needed, for each to implement its own billing and pricing rules, as further disclosed herein.

[0074] 2, a flow diagram and components of a method for transaction processing in a cloud services broker platform are shown and generally designated 200. Flow diagram 200 includes transactions 202 as applied over a billing period 204. In at least one embodiment of the present disclosure, transactions 202 include purchases 210, add-ons 212, upgrades 214, downgrades 216, and cancellations 218. Although only a few select transactions are shown, it will nevertheless be understood that transactions 202 may include any type of transaction as known and practiced by those skilled in the art in aligning revenue streams in a cloud services broker platform.

[0075] In at least one embodiment of the present disclosure, each of the transactions 202 may include transaction attributes such as a service start date, a billing period, and any incentives, to name a few non-limiting examples. For example, the purchase 210 is for a monthly billing period (i.e., the billing period is one month), and the incentive includes a first month of service free. It will be understood that the transaction attributes (also known as billing rules) result from agreements between various entities within the system 100 (e.g., the cloud broker 104, the first reseller 106, etc.). It will further be understood that other billing rules, such as free periods, full payment, pro-rata purchases and / or cancellations, add-ons, upgrades, downgrades, alignment (e.g., alignment of billing periods between parent and child subscriptions), and anniversary dates, may be included with respect to each of the transactions 202.

[0076] In at least one embodiment of the present disclosure, a subscriber (e.g., end customer 112) may initiate a transaction, but the subscriber's billing cycle is updated or initiated based on transaction attributes. For example, purchase 210 is a transaction to purchase a service. Attributes of purchase 210 include a monthly frequency (i.e., monthly billing cycle) with a first month free as an incentive. Thus, in the first billing cycle (i.e., the first month), the subscriber is not charged any fees. Similarly, the same subscriber may initiate add-on 212 several months later. In such an example, the cost of add-on 212 is added to the subscriber's total cost of service. As shown in FIG. 2 , in the third month, subscriber cost 212a is added to subscriber cost 210a. Attributes of add-on 212 indicate that its billing cycle is aligned with the parent's billing cycle (i.e., purchase 210). Thus, add-on 212 will be billed during the same billing cycle as purchase 210. As shown in FIG. 2 , add-on 212 includes a free first month as an incentive. It will be appreciated that an add-on 212 may have its own alignment attribute such that its billing cycle does not align with the parent's billing cycle (ie, purchase 210).

[0077] In at least one embodiment of the present disclosure, a subscriber may also desire to upgrade their service. For example, an upgrade 214 transaction may be initiated (e.g., in marketplace 122) in which subscriber cost 214a is amended to upgraded subscriber cost 214b (as shown in FIG. 2). The upgrade 214 includes attributes for prorating during the “old” period and prorating during the “new” period. During the billing cycle in which the upgrade 214 is initiated, the transition from subscriber cost 214a to subscriber cost 214b results in the subscriber's costs being prorated on a monthly billing cycle on either side of the transition (i.e., the subscriber is prorated based on subscriber cost 214a from the start of the billing cycle until before the upgrade, and based on subscriber cost 214b from the time of the upgrade until the end of the billing cycle).

[0078] In at least one embodiment of the present disclosure, billing period cost 220 is calculated at the end of each billing period based on the sum of multiple costs incurred by the subscriber. For example, during billing period 220a, and assuming one subscriber initiated all transactions 202, the subscriber's costs may include subscriber cost 210a, subscriber cost 212a, subscriber cost 214a, and subscriber cost 216a (including downgrade transitions). It will be understood that the cost for billing period 220a is the sum of all individual service costs incurred by the subscriber. It will further be understood that such costs may include a cost per reseller, a cost per end customer, or a cost per service vendor, to name a few non-limiting examples.

[0079] Referring to FIG. 2A , an example method 240 for aligning revenue streams in a cloud service broker platform is illustrated, in accordance with at least one embodiment of the present disclosure. In example 240, a contract between a service vendor and a cloud broker is defined, and multiple subscriptions to the service vendor are created (i.e., a subscription to Plan P1, a subscription to Plan P2, and a subscription to Plan P3, where Plan P1 costs $100, Plan P2 costs $200, and Plan P3 costs $300 for each billing period). It will be appreciated that each of the multiple subscriptions includes multiple billing attributes associated therewith. In example 240, each of the multiple subscriptions has a subscription alignment, with an anniversary date falling on the 10th of each month (the start / end of each billing period for each of the multiple subscriptions). Furthermore, each of the multiple subscriptions includes a promotional period during which the service vendor offers a free period leading up to the first anniversary date. Each of the multiple subscriptions also includes a provision for pro-rata billing after the end of each billing period. It will be appreciated that the billing attributes of each subscription may be up to the service vendor 102 .

[0080] Continuing with example 240, a first registrant (e.g., end customer 112) may initially subscribe to service plan P1, as shown at 250a, a second registrant may initially subscribe to service plan P3, as shown at 252a, and a third registrant may initially subscribe to service plan P4, as shown at 254a. At the end of the billing cycle, for each of the registrants, the service vendor 102 will send an invoice to the appropriate cloud broker (e.g., cloud broker 104), as shown at 260b, 262b, 264b, 266b, and 268b. For example, 260b shows the total cost for subscribing to plans P1, P2, and P3 during billing period 260a. In this example, the cost in 260b is $0 because each of the plans includes a promotional free service period that ends on the first contract anniversary, as described above. Similarly, in 262b (costs for billing period 262a), the cost of plan P1 is $100, the cost of plan P2 is $0, and the cost of plan P3 is $600. It will be appreciated that when a service vendor submits an invoice to the marketplace broker 128, it must match costs (i.e., amounts paid to the vendor) with revenues (i.e., amounts received from resellers or partners). By monitoring all transactions with the transaction mediator 132, the marketplace computing device 122 is configured to simulate the vendor's billing process by applying the vendor's billing rules (which may be stored in the service provider database 124, as further disclosed below). It will be further appreciated that the marketplace broker 128 enables reconciliation with the vendor's invoices to produce accurate cost-revenue matching.

[0081] Continuing with the above example, Figure 2B illustrates an agreement between the cloud broker 104 and its subscribers (e.g., end customers 112a, 112b, 112c, 112d) where the subscribers subscribe to monthly subscriptions. As shown in Figure 2B, for this subscriber, plan P1 costs $120, plan P2 costs $240, and plan P3 costs $360. It will be further understood that attributes that apply to each of the plans include subscription alignment with the contract anniversary date being the purchase date, no free period, no refunds for plan changes, pro-rata cancellations, and prepayment of fees.

[0082] According to the billing model shown in Figure 2B, broker revenue 270 for each period follows the total revenue for the billing period. For example, during period 270b, the total cost of Plan P1 is $120, the total cost of Plan P2 is $0, and the total cost of Plan P3 is $720. Similarly, during period 272b, the total cost of Plan P1 is $120, the total cost of Plan P2 is $0, and the total cost of Plan P3 is $720. Continuing with this example, during period 274b, the total cost of Plan P1 is $120, the total cost of Plan P2 is $240, and the total cost of Plan P3 is $720.

[0083] In at least one embodiment of the present disclosure, system 100 is further configured to maintain a record of contracts and subscriptions for each service vendor (e.g., service vendor 102), reseller (e.g., reseller 106), and end customer (e.g., end customer 112). It will be appreciated that this allows each entity in the hierarchy to perform reconciliation and profit and loss analysis. For example, referring to FIG. 2C , a settlement and reconciliation between broker sales 270 of cloud broker 104 and broker payments 272 of cloud broker 104 is shown. In this example, as shown in 260b, broker sales during period 270b for Plan P1 are $120, while broker payments during the same period for Plan P1 are $0. It will be appreciated that, as shown in FIG. 2C , there is a cost-revenue match between broker sales 270 and broker payments 272 for every billing period.

[0084] Referring now to FIG. 3 , a flow diagram and components of a method for aligning revenue streams in a cloud service broker platform are shown, generally designated 300. Flow diagram 300 illustrates services 302, service billing rule attributes 302a, billing periods 310, and monthly service amounts in service units 312. In at least one embodiment of the present disclosure, each of services 302 represents a service subscribed to by a subscriber (e.g., end customer 112). It will be understood that services 302 may be received from cloud broker 104 or from marketplace broker 128 depending on the provisioning channel architecture, in other words, whether cloud broker 104 and marketplace broker 128 operate as a single entity, as shown in system 150 but not in system 120. In at least one embodiment of the present disclosure, each of services 302 has a service billing rule attribute 302a associated therewith. For example, the service identifier "SKU-C3" includes attributes "a", "f", and "p", where "a" indicates that SKU-C3 is aligned, "f" indicates that it has an initial free period, and "p" indicates that it is pro-rated, for example, during cancellation.

[0085] In at least one embodiment of the present disclosure, each monthly consumed service amount 312 within a service unit is calculated by adding each individual amount of service during a particular billing period 310. For example, during billing period 310b (February), the monthly service total 312b includes consumed service amounts associated with SKU-A1, SKU-B2, SKU-C3 (afp), SKU-D4 (apf), and SKU-D4 (uff). Each monthly service total 312 is calculated by adding each individual amount associated with a service 302 based on each of the service attributes 302a. A monthly consumed service amount is then calculated for each SKU, for example, during billing period 310b (February): SKU-C3 - 1.63, SKU-A1 - 0.16, SKU-B2 - 0.13, SKU-D4 - 1.35. It will be appreciated that each monthly cost (or revenue depending on the contracting party, i.e., vendor or partner) may be calculated by multiplying the monthly service amount in service units by the price of the service in accordance with billing rules.

[0086] Referring now to FIG. 4 , a flow diagram and components of a method for aligning revenue streams in a cloud services broker platform are shown, generally designated 400. In at least one embodiment of the present disclosure, a sales order 402 is generated. The sales order 402 indicates a subscription period 404, which is divided into multiple billing periods (406a, 406b, and 406c). For each billing period, a billing cost is calculated. For example, in billing period 406a, a pre-order bill 408a is calculated. At the end of billing period 406a, usage is collected. At the end of billing period 406a, a post-order bill 410a is calculated. It will be understood that the subscription period 404 may be divided into multiple billing periods based on the sales order 402 or some other contractual terms agreed upon between the subscriber and the service provider (e.g., the service vendor 102 or reseller), or even the end customer.

[0087] 5, a method and components for aligning revenue streams in a cloud service broker platform are shown and generally designated 500. The method 500 includes steps 502 of calculating costs at each of the service vendors 102, 504 of calculating service costs at the cloud broker (marketplace) 128, 508 of calculating costs at the resellers 106a and 108a, and 510 of generating a consolidated bill for the end customer 112a.

[0088] In at least one embodiment of the present disclosure, in step 502, costs are calculated for each of the service vendors 102. For example, the cloud broker (marketplace) 128 has contract information for each of the service vendors 102 since the service vendors 102 were initially set up (i.e., made "available"). A contract-based pricing structure is created for each of the service vendors 102. For example, service vendor 102a may bill on a monthly billing cycle based on a license structure, with invoices due on the fourth of each month and payments due at the end of the period. Similarly, by way of example, service vendor 102b may bill on a quarterly billing cycle based on a "pay-as-you-go" structure, with invoices due on the fifth of each month and payments due at the end of the billing period.

[0089] In at least one embodiment of the present disclosure, costs are calculated at the cloud broker (marketplace) 128 in step 504. For example, the cloud broker (marketplace) 128 may need to generate an invoice based on a monthly billing period even if the service vendor 102b bills on a quarterly basis. In such an example embodiment, the cloud broker (marketplace) 128 is configured to calculate costs based on estimated costs if the service vendor's billing period is in the future.

[0090] In at least one embodiment of the present disclosure, costs are calculated for the resellers 106a, 108a in step 508. Again, each of the resellers 106a and 108a may have independent contract terms and conditions, resulting in billing characteristics that differ from those of the service vendor 102. For example, at the reseller 108a, the service vendor 102a (office365®) may have a contract anniversary date that falls on the 15th of each month, but as noted above, the service vendor 102a bills on the 4th of each month.

[0091] In at least one embodiment of the present disclosure, a consolidated bill is generated for the end customer 112a in step 510. It will be appreciated that a single bill is generated for the end customer 112a such that all costs resulting from the end customer's 112a subscription are generated on a single bill based on the end customer's 112a billing characteristics. It will be appreciated that the end customer's 112a billing characteristics may differ from the characteristics of upstream entities (e.g., the service vendor 102 and the resellers 106a and 108a).

[0092] 6, a method for billing and reconciliation in a cloud service broker platform is shown, generally designated 600. In at least one embodiment of the present disclosure, the method includes a step 602 in which the connector 138 reports attributes of the provisioning operation to the transaction mediator 132, a step 604 in which the transaction mediator 132 stores data in a service usage database 134, a step 606 in which the federated connector 130 requests a service usage report for reconciliation with the service vendor 102, a step 608 in which the transaction mediator 132 receives billing rules of the service vendor 102 for determining service usage, a step 610 in which the transaction mediator 132 calculates total usage of the service, a step 612 in which the transaction mediator 132 sends the report to the federated connector 130, a step 614 in which the federated connector 130 sends the report to the marketplace broker 128, and a step 615 in which the marketplace broker 128 receives the usage report for reconciliation with the service vendor 102. the transaction mediator 132 receives billing rules from the partner 104a's subscription and the transaction mediator 132 applies the billing rules to determine service usage data; the transaction mediator 132 calculates total service usage; the transaction mediator 132 sends the report to the transaction connector 130; the transaction mediator 132 sends the report to the marketplace broker 128; and the marketplace broker 128 applies the pricing model from the partner 104a's subscription for the usage report and bills the partner 104a.

[0093] 7A and 7B, a system for aligning revenue streams in a cloud service broker platform in accordance with at least one embodiment of the present disclosure is shown and generally indicated at 700. System 700 includes an independent software vendor (ISV) rating engine 702, a cost of sales calculator (cos. calculator) 704, and an enterprise resource planning (ERP) system 706.

[0094] In at least one embodiment of the present disclosure, the ISV rating engine 702 is operatively connected to the transaction mediator 132. The ISV rating engine 702 is further configured to receive transaction information from the transaction mediator 132 of the marketplace broker 128. By way of non-limiting example, transaction types include activation, cancellation, modification, upgrade, downgrade, add-on, usage collection, and the like. In at least one embodiment of the present disclosure, the transaction mediator 132 sends the transaction to the ISV rating engine 702. It will be understood that each transaction from the transaction mediator 132 includes, for example, a resource identifier, an ISV contract identifier, a subscription identifier, a resource stock-keeping unit (SKU) value, a transaction type, a quantity, a date, and the like. In at least one embodiment of the present disclosure, information associated with the transaction is declared within the marketplace broker 128. In at least one embodiment of the present disclosure, the ISV rating engine 702 stores the fees in a database operatively connected to the ISV rating engine 702. It will be further appreciated that the ISV rating engine 702 may implement pricing rules based on past history of user transactions, such as volume discounts, renewal period length, and other current price calculation rules.

[0095] In at least one embodiment of the present disclosure, the cos. calculator 704 is configured to calculate the actual cost of sales for each transaction or contract conducted on the marketplace 128. In at least one embodiment of the present disclosure, the terms of the contract between the marketplace broker 128 and the partner 104 or reseller 106 may differ from the terms of the contract between the marketplace broker 128 and the service vendor 102 (i.e., no dependency exists between these two contracts) depending on the provisioning channel architecture, i.e., whether the cloud broker 104 and the marketplace broker 128 operate as a single entity, as shown in system 700a but not system 700b. It will be understood that the marketplace broker 128 can set up any billing and pricing rules for the reseller 106. That is, the billing and pricing rules provide flexibility for the marketplace broker 128 and create a larger revenue stream than the terms of the contract whereby the marketplace broker 128 pays the service vendor 102. As an example, the marketplace broker 128 may sell a software bundle containing different applications developed by various service vendors to a reseller 106 and set up one subscription period for the entire bundle of applications. The marketplace broker 128 may also set up special discounts. However, the marketplace broker 128 would have to align the revenue stream from the reseller (e.g., the reseller 106) with the costs owed to the service vendor (e.g., the service vendor 102).

[0096] In at least one embodiment of the present disclosure, the cos. calculator 704 is configured to facilitate automated cost calculations. The cos. calculator 704 requests cost estimates for each resource SKU for a period defined by the agreement between the marketplace broker 128 and the reseller 106 from the ISV rating engine 702. It will be appreciated that, as disclosed herein, the cos. calculator 704 aligns cost streams and revenue periods, which is important for further revenue matching and settlement. For example, some billing periods in the agreement between the marketplace broker 128 and the reseller 106 may be longer than billing periods from the agreement between the marketplace broker 128 and the service vendor 102. In such an embodiment, the ISV rating engine 702 provides cost estimates for future billing periods based on transaction metrics received via the transaction mediator 132.

[0097] In at least one embodiment of the present disclosure, an enterprise resource planning (ERP) system 706 is operatively connected to the ISV rating engine 702 or the marketplace 122. The ERP system 706 is of a type well known to those skilled in the art, such as, for example, SAP®, Microsoft Dynamics®, or the like. It will be understood that the ERP system 706 may be cloud-based and remote from the marketplace 122 or may be a component of the marketplace 122. In at least one embodiment, the ERP system 706 is configured to receive financial and other data and operate together to perform the functions delegated to the ERP system 706 according to the present disclosure.

[0098] 8, an ISV contract catalog computing device is shown, generally designated 800. In at least one embodiment of the present disclosure, the ISV contract catalog computing device 800 includes an ISV catalog 802, an application catalog 804, a price formation catalog 806, a price constructor tool 808, an ISV billing rules manager 810, a contract manager 812, a rating engine interface 814, a notification manager 816, and a user input interpreter 818.

[0099] The ISV catalog 802 is a service running on the ISV contract catalog computing device 800. The ISV catalog consists of several parts. The product catalog 804 stores information about available ISV services integrated with the cloud service broker marketplace system via connectors. The product catalog also includes a set of resources associated with the services. Through the price constructor tool 808, the ISV can adjust the price of the service and resource usage. The price constructor tool 808 can include various pricing settings, such as volume dependencies, usage periods, special discounts for certain types of clients, and various arguments on which the price formula can depend. The ISV can use various pricing settings and combine them to set their own pricing terms, including pricing terms in the form of mathematical formulas. The price constructor catalog 806 stores pricing terms set by the ISV using the tool 808 or manually. The ISV billing rules store billing rules for services and associated resources. The various billing rules are illustrated in FIG. 2 at 202. The contract manager stores the terms of the contract between the ISV and the cloud service broker marketplace 128. The rating engine interface 814 is responsible for interfacing with the rating engine and handling requests and responses. The notification manager 816 notifies the rating engine and the cloud service broker marketplace 128 about any changes to product listings, prices, billing rules, or contracts from the ISV side. The user input interpreter 818 is a UI for the ISV and helps the ISV interact with the ISV catalog service 802.

[0100] In at least one embodiment of the present disclosure, the ISV contract catalog device 800 inherits the service provider billing rules and service plan database 124. In at least one embodiment of the present disclosure, the ISV contract catalog device 800 and the tiered partner contract catalog 126 may be combined as a product catalog (not shown). In at least one embodiment of the present disclosure, the product catalog may include at least one database with products including the vendor's services with prices (established by the vendor, established for partners, resellers).

[0101] 9, components of an ISV rating engine computing device are shown and generally designated 900. In at least one embodiment of the present disclosure, the ISV rating engine computing device includes a transaction mediator interface 902, a transaction manager 904, a fee generator 906, a fee quote manager 908, a price calculator 910, a rating manager 912, a resource usage manager 914, an ISV contract catalog interface 916, a cos. calculator interface 918, an ERP interface 920, and a federation usage calculator 922.

[0102] In at least one embodiment of the present disclosure, the resource usage manager 914 is configured to support a pay-per-use model and receives transactions with usage from the transaction mediator 132. In at least one embodiment of the present disclosure, the federation usage calculator 922 takes over the functionality of the federation connector 130 and is configured to calculate and report per-SKU usage to the marketplace computing device 122.

[0103] 10 , a method 1000 for aligning revenue streams in a cloud service broker platform is illustrated, in accordance with at least one embodiment of the present disclosure. In at least one embodiment of the present disclosure, at step 1002, the transaction mediator 132 submits any transaction including a “collect” request for any service resource. The method 1000 proceeds to step 1004, where the ISV rating engine 702 requests contract details (e.g., pricing rules, etc.) for the service resource from the ISV catalog 802 and waits for usage reports. The transaction mediator 132 checks whether this contract exists, in step 1006, and if so, proceeds to step 1008; if not, proceeds to step 1036. In at least one embodiment of the present disclosure, at step 1008, the transaction mediator 132 submits the usage reports to the ISV rating engine 702. The ISV rating engine 702 collects the usage reports and generates fees with prices that comply with the pricing rules. For example, the ISV rating engine 702 may create one rate per billing period associated with this resource set up with the service vendor 102. Alternatively, if a contract defines different prices for different resource amounts, the ISV rating engine 702 may wait until a threshold is exceeded, create a rate at the first price, and then collect usage until the next threshold is reached and / or exceeded.

[0104] In at least one embodiment of the present disclosure, the ISV catalog 802 includes contract details for agreements between the marketplace broker 128 and the service vendor 102. In particular, each agreement between the marketplace broker 128 and the service vendor 102 includes data about applications, their descriptions, resource SKUs, and at least one set of resource identifiers (e.g., service vendor numbers) associated with the applications, subscription periods, pricing rules, currencies, units of measure, billing rules for activation, cancellation, modifications (e.g., add-ons, upgrades, downgrades), and invoicing. It will be appreciated that the ISV catalog 802 also has a user interface for setting pricing rules, a catalog containing all possible pricing rules, and a price constructor tool including a user interface for service vendors or other entities to set up pricing rules. It will be appreciated that the various pricing terms are broad but pre-configured. At a minimum, the requirement is that these price formation rules must be determined by the ISV rating engine 702 based on information contained in the transaction from the transaction mediator 132 (i.e., it will be understood that the price formula should be expressed in terms of variables reported by / to the transaction mediator 132, or can otherwise be calculated directly based on them).

[0105] Continuing with method 1000, at step 1008, it is checked whether there is a resource subscription associated with the incoming transaction. If there is, method 1000 proceeds to step 1010; if not, method 1000 proceeds to step 1038, where it checks whether the transaction is an "invoke."

[0106] In step 1010, a transaction type is defined. In at least one embodiment of the present disclosure, in step 1012, "activation" transactions are determined and characterized by two attributes associated with them: aligned (a) and unaligned (u), and three attributes associated with the activation of the transaction: a contract anniversary date, including free, full price, and pro-rata. If the transaction is indeed an "activation," method 1000 proceeds to step 1058, and the transaction may be stored as an "error" because a contract already exists as determined in step 1006. (Similarly, if in step 1040 the transaction is determined to be an "activation," the method proceeds to step 1042; otherwise, the method proceeds to step 1036, and the transaction is stored as an "unaligned").

[0107] If the transaction is not an "activation," method 1000 proceeds to step 1014. In step 1014, it is determined whether the transaction is a "cancellation." In at least one embodiment of the present disclosure, a cancellation has three associated attributes: free, full price, and pro-rata. If the transaction is not a cancellation, method 1000 proceeds to step 1060.

[0108] If the transaction is a cancellation, method 1000 proceeds to step 1016, where an existing active resource subscription is identified on the resource associated with the transaction. Method 1000 then proceeds to step 1018, where the service vendor's 102 billing period is identified for the associated resource SKU. In step 1020, the ISV catalog 802 is queried to retrieve the cancellation rules for the applicable contract with the service vendor 102. A negative price charge is created in step 1022 by determining the cancellation rules for the current billing period in step 1024, and then implementing the cancellation rules in step 1026 to calculate a negative price for the cancellation.

[0109] In at least one embodiment of the present disclosure, any estimated charges for further billing periods are determined in step 1028. If no such billing charges exist, the charges created from the previous step are stored in step 902. If there are charges to store, charges are created in step 1030 with a negative price for all estimated charges, and prices for the estimated charges are identified in step 1032. In step 1034, all generated charges are stored and listed with the associated transaction.

[0110] Referring again to step 1040 of method 1000, if the transaction is "activation," method 1000 proceeds to step 1042, as shown in FIG. 10A . In at least one embodiment of the present disclosure, in step 1044, the ISV catalog 802 is queried for the billing period associated with the resource SKU. In step 1046, the ISV catalog 802 is further queried for a pricing rule set associated with the resource SKU. In at least one embodiment of the present disclosure, in step 1048, a rate is created with the end date of the service vendor's 102's furthest billing date. For example, transaction data is identified in step 1050, pricing rules are determined in step 1052, and the price is implemented in step 1054. In step 1056, the created rate is stored.

[0111] Referring again to step 1058 of method 1000, after the transaction is stored as an "error," method 1000 proceeds to step 1060, as shown in FIG. 10C. In step 1060, it is determined whether the transaction is a "change." In at least one embodiment of the present disclosure, a change transaction has six attributes: three for the old subscription: free, full price, and pro-rata; and three for the new subscription: free, full price, and pro-rata.

[0112] In at least one embodiment of the present disclosure, existing active resource subscriptions on resources associated with the transaction are identified in step 1062. At 1064, a type of change transaction is identified and a billing period of the service vendor 102 is identified for a period associated with the resource SKU. The method 1000 then proceeds to step 1068, where the ISV catalog 802 is queried for change rules from the contract with the service vendor 102. It will be appreciated that the ISV catalog 802 is also queried for price rules associated with the resource SKU and type of change transaction. In at least one embodiment of the present disclosure, a change fee is created in step 1072, change rules for the current billing period are determined in 1080, and the change rules are implemented in step 1082.

[0113] Method 1000 then proceeds to step 1090, where it is determined whether any estimated fees exist for further billing periods. If there are no fees to store, method 1000 ends at step 1092. If so, for all estimated fees, a fee is created at step 1094 that includes a price associated with the estimated fee associated with the resource. It will be further appreciated that at step 1096, the price of the estimated fee is identified, and at step 1098, all created fees associated with the transaction are stored and listed.

[0114] It will be understood that in the CSB platform, the base price of a resource is fixed and set by a contract between the service vendor 102 and the marketplace broker 128. It will be further understood that there are several types of discounts, namely, volume discounts (to name a few non-limiting examples, for per-unit subscriptions, the quantity is the number of units; for pay-as-you-go subscriptions, the quantity is directly defined as the quantity of purchased resources such as memory, network bandwidth, and other computer resources). It will also be understood that discounts can be implemented based on subscription renewal periods. For example, the first-year discount can be 25%, the second-year discount can be 35%, etc. The discount tiers can be set by the service vendor 102, but discounts can be set as percentages and as cash-equivalent delta adjustments. It will be understood that discounts can be set as a combination of terms.

[0115] In at least one embodiment of the present disclosure, an updated price calculation can also be set up. For example, if a subscriber purchases a resource subscription volume that exceeds some threshold in a year, a special discount can be implemented. To implement the updated price calculation, the transaction is stored and a true-up charge is issued if some threshold for a discount is achieved. The ISV rating engine 702 implements pricing and billing rules for each resource SKU after receiving transactions from the transaction mediator 132 and requesting contract details from the ISV catalog 802.

[0116] 11 , a method for aligning revenue streams in a cloud services broker platform is shown and generally indicated at 1100. Method 1100 illustrates operation of ISV rating engine 702 in response to a request from cos. calculator 704, in accordance with at least one embodiment of the present disclosure. Method 1100 begins at step 1102, where a new quote request is received from cos. calculator 704. At step 1104, ISV rating engine 702 checks whether a resource subscription exists associated with the received request. If a request does not exist, method 1100 proceeds to step 1106 and then loops back to step 1102.

[0117] If a request exists, the method 1100 proceeds to step 1108, where the requested quote period end date is identified. In step 1110, the requested quote period end date is compared to the nearest future billing date according to the associated contract with the applicable service vendor 102.

[0118] In at least one embodiment of the present disclosure, in step 1112, the end date of the requested quote period is checked to see if it exceeds the next billing date per the associated contract with the applicable service vendor 102. If not, method 1100 proceeds to step 1120 as further disclosed herein.

[0119] If so, method 1100 proceeds to step 1114, where the ISV catalog 802 is queried for the price rule set associated with the resource SKU for the preferred billing period and the billing date following the end date of the quote period. In step 1116, a fee is created for the billing date following the end date of the quote period. In step 1118, the next billing date is assigned as the billing date following the billing date after the end of the quote period. Method 1100 then ends in step 1120, where the new fee is sent and stored for the requested period.

[0120] It will be appreciated that the ISV catalog 802 may include rules for quoting. For example, if a service vendor (such as Microsoft) has a prepayment system, such a service vendor may set up rules for the next billing period to calculate the average consumed resource amount and prepare an invoice according to such rules. At the end of such billing period, the service vendor may send an adjusted invoice; it will be further appreciated that the ISV rating engine 702 may implement such adjustments to the quote request from the cos. calculator 704.

[0121] 12, a method for aligning revenue streams in a cloud services broker platform is shown and generally indicated at 1200. Method 1200 illustrates operations for the ISV rating engine 702 to send recurring reports to the ERP system 706 in accordance with at least one embodiment of the present disclosure.

[0122] The method 1200 begins at step 1202 by checking whether an asynchronous task for repeated ranking is received. It will be understood that this task can also be synchronous. If no such task is received, the method 1200 loops back to 1202.

[0123] If so, method 1200 proceeds to step 1204, where all active subscriptions are selected such that the next billing date for such active subscriptions is not later than the current date. Method 1200 then proceeds to step 1206, where the selected subscriptions are grouped by resource SKU and a task is performed for each group.

[0124] In at least one embodiment of the present disclosure, in step 1208, the ISV catalog 802 is queried for a price rule set associated with each applicable resource SKU. In step 1210, a price is generated for the billing period followed by the current date. In step 1212, price formation rules are determined, and in step 1214, the price is implemented.

[0125] In at least one embodiment of the present disclosure, the next billing date is assigned as the billing date following the current date in step 1216. The method 1200 ends in step 1218, where the charges for the requested period are transmitted and stored.

[0126] 13, a method for aligning revenue streams in a cloud services broker platform is shown and generally indicated at 1300. Method 1300 illustrates operation of ISV rating engine 702 to monitor changes in ISV contract catalog 802 in accordance with at least one embodiment of the present disclosure.

[0127] Method 1300 begins at step 1302, where the ISV rating engine 702 checks (periodically or continuously) to see if it has received a price change notification from the ISV contract catalog 802. Upon receiving a notification, method 1300 proceeds to step 1304, where the affected subscriptions are selected and fees are ordered. Method 1300 then proceeds to step 1306, where the selected subscriptions are grouped by resource SKU and a task is performed for each group.

[0128] In at least one embodiment of the present disclosure, in step 1308, the ISV catalog 802 is queried for a price rule set associated with each applicable resource SKU. In step 1310, any pending charges for the affected subscriptions are canceled. The method 1300 then proceeds to step 1312, where charges for the billing period are generated. In step 1314, price formation rules are determined, and in step 1316, the prices are implemented.

[0129] In at least one embodiment of the present disclosure, a refund charge may be generated for previously affected ordered charges that were previously overcharged in step 1318. Method 1300 ends in step 1320 with the charges for the requested period being transmitted and stored.

[0130] It will be appreciated that the ISV rating engine 702 also receives updates from the ISV catalog 802 for pricing rules and ties to resources associated with past transactions. The ISV rating engine 702 performs updated price calculations and adjusted rates at the end of the service vendor's billing period associated with the latest pricing terms. It will also be appreciated that all adjusted rates may be automatically reported to the ERP system 706 in recurring cost reports as disclosed in method 1200.

[0131] In at least one embodiment of the present disclosure, the cos. calculator 704 receives information about the billing periods set up for the agreement between the marketplace broker 128 and the reseller 106 either by the time the marketplace broker 128 distributes the cloud application itself through the reseller chain, including all billing periods for which the CSB platform needs to align its billing rules and cost flows; or by the time the marketplace broker 128 has third-party partners, including the partner platform's own billing. In such an embodiment, it will be understood that the marketplace computing device will include a contract catalog of tiered parties, including each partner's prices and billing terms. It will be further understood that the product catalog may be stored within the marketplace computing device, but may preclude the need to store pricing information independently (i.e., at the tiered parties). In at least one embodiment of the present disclosure, such marketplace computing devices have the same ISV rating engine to calculate revenue according to information received from the same transaction mediator 132 through the collaborative connector 130 and to implement pricing and billing rules from the partner contract catalog.

[0132] While the present disclosure has been illustrated and described in detail in the drawings and foregoing description, it is to be considered in character as illustrative and not restrictive, it being understood that only certain embodiments have been shown and described, and that all changes and modifications that come within the spirit of the disclosure are desired to be protected.

Claims

1. A transaction mediator operatively connected to a cloud service broker platform and a service vendor via the use of a connector, the transaction mediator configured to receive all transactions for operations at an independent software vendor (ISV); an independent software vendor (ISV) rating engine operatively connected to the cloud services broker platform and the transaction mediator and configured to receive the transactions, provide estimated fees for a future billing period based on received transaction metrics, and send an order to an enterprise resource planning system; an independent software vendor (ISV) catalog operatively connected to the cloud services broker platform and configured to store a plurality of agreements between the independent software vendors (ISVs) and the cloud services broker platform; operatively connected to the cloud service broker platform; a cost of sales calculator configured to receive historical and real-time transaction data from the transaction mediator, obtain pricing rules and contract terms for each service SKU from the ISV catalog, apply rates generated by the ISV rating engine based on the pricing rules, and generate aligned rates at least in part based on a comparison of total partner revenue from subscriptions and customer cost rates incurred under vendor contracts; A system for aligning revenue streams in a cloud services broker platform.

2. The system of claim 1 , wherein the transaction mediator is further configured to track all transactions passing through the cloud service broker platform.

3. The system of claim 2 , wherein the transaction mediator is further configured to report the transaction to the independent software vendor rating engine.

4. The system of claim 2 , wherein the transaction mediator is further configured to transmit data for each of the independent software vendors.

5. 2. The system of claim 1, wherein each of the plurality of contracts includes contract details selected from the group consisting of a set of software applications, a software application description, resources, resource identifiers, a subscription period, pricing rules, currency, units of measure, billing rules for activation, cancellation, modification, and invoicing.

Images