JP7508618B2 - SYSTEM AND METHOD FOR ALIGNING REVENUE STREAMS IN A CLOUD SERVICE BROKERAGE PLATFORM - Patent application - Google Patents

Description

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

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.

Currently, many software vendors 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 SaaS providers. SaaS, also called "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 a SaaS vendor to access the SaaS platform for a certain period of time (e.g., one month). Conversely, in a pay-per-use pricing structure, a SaaS subscriber pays a SaaS provider based on the subscriber's usage of the SaaS platform within a given period of time. For example, a subscriber may be charged based on a fee per usage, where the 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, and the SaaS vendor's costs are passed directly to the subscriber, who then pays to ensure ongoing access to the SaaS platform.

An alternative system of 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 set of services (i.e., cloud service packages) 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 allow provisioning and selling 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 the SaaS offerings at a different pricing structure compared to the SaaS vendors and/or cloud brokers.

Billing in the cloud services broker system is managed through the cloud services broker because the cloud services broker is the only entity capable of managing the many relationships in such a software delivery system. However, revenue alignment and settlement can be problematic. For example, billing complexity in the 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 services package may include multiple software services from multiple SaaS vendors. Each of these multiple software services within the cloud services package may include various billing structures (e.g., a combination of usage-based and subscription-based structures, each with varying incentives and billing attributes). Additionally, downstream resellers may offer their own unique pricing structures for the cloud services package.

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 cloud service mediated delivery channels. Thus, implementation of 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, although differences may exist between billing rules from an upstream entity (e.g., SaaS vendor) and a downstream entity (e.g., reseller), billing imposed on subscriber end users based on one particular entity's billing architecture is inappropriate. For example, fixed markups and discounts may be applied by an upstream entity (e.g., SaaS vendor), but the markups and discounts may not be appropriate for downstream entities (e.g., end users of the reseller). 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 in 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, bulk purchases of services that are delivered according to different billing rules cannot be performed, leading to missed opportunities for larger service distributors.

Therefore, there is a need for improved systems and methods for aligning revenue streams in a cloud service broker platform.

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, which may receive services directly from the service vendor or indirectly through the reseller.

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.

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

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 the connectors, and (optionally) includes an associated connector.

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

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.

In at least one embodiment of the present disclosure, the cloud broker may be run by a partner, which operates to provide the service vendor's services to subscribers.

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

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

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 includes determining transactions as they apply over a billing period, initiating the transactions, and updating or initiating the transactions 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.

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

In at least one embodiment of the present disclosure, the method includes calculating the cost at each of the service vendors, calculating the service cost at the cloud broker, calculating the cost at the reseller, and creating a consolidated invoice for the end customer.

In at least one embodiment of the present disclosure, costs are calculated for each of the service vendors, cloud brokers, and resellers, and a consolidated invoice is generated for the end customer.

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 for 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 for the service vendor to generate a usage report for reconciliation with the service vendor, requesting a service usage report for partner billing, receiving billing rules from a partner subscription, calculating total usage of the service, sending the report to an integration connector, sending the report to a marketplace broker, applying a pricing model from the partner, and billing the partner.

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 the 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.

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

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

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

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

1 illustrates a flow diagram and components of a method for aligning revenue streams in a cloud services broker platform, according to one embodiment.

1 illustrates a flow diagram and components of a method for aligning revenue streams in a cloud services broker platform, according to one embodiment.

1 illustrates a flow diagram and components of a method for aligning revenue streams in a cloud services broker platform, according to one embodiment.

1 illustrates a flow diagram and components of a method for aligning revenue streams in a cloud services broker platform, according to one embodiment.

1 illustrates a flow diagram and components of a method for aligning revenue streams in a cloud services broker platform, according to one embodiment.

1 illustrates a flow diagram and components of a method for aligning revenue streams in a cloud services broker platform, according to one embodiment.

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

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

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

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

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

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

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

FIG. 1 illustrates a method for aligning revenue streams in a cloud services broker platform.

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

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

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

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

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 following description, or may be obvious from the description, or may be learned by practice of the present 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.

Referring now to FIG. 1, a system for cloud service delivery via a cloud service broker is shown and generally indicated at 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.

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 services. 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 (usually 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 in 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), supply chain management, to name a few non-limiting examples. It will be appreciated that the service vendors 102 may provide their services to resellers or directly to end customers.

In at least one embodiment of the present disclosure, the service vendor 102 is configured to monitor the 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 in 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.

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 fee proportional to the utilization of computing resources. It will be further appreciated that service vendors 102 may transmit billing rules to other entities in system 100.

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 of aggregating different software services (e.g., from the service vendors 102) via APIs to provision and sell subscriptions to the services of the service vendors 102 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.

In at least one embodiment of the present disclosure, the system 100 further includes resellers at different hierarchical levels. For example, the first reseller 106 is a geographically based reseller (e.g., the first reseller 106a serves the United States, the first reseller 106b serves France, and the first reseller 106c serves Brazil). The system 100 may further include downstream resellers, such as the second reseller 108 and the third reseller 110. The 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. Although only a select number of resellers and downstream resellers are shown, it will be understood that the system 100 may include any number of resellers and downstream resellers connected by software and hardware systems (e.g., the Internet) of a type known in the art, which systems are operable together to perform the functions delegated to the resellers by the present disclosure.

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 the services provided by the service vendor 102 (or at least services that may 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 also 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.

Referring now to FIG. 1A, a system for aligning revenue streams in a cloud services broker platform is shown and generally indicated at 120. The system 120 includes a marketplace 122, a service provider database 124, a partner database 126, a marketplace broker 128, an association connector 130, a transaction mediator 132, a usage database 134, a provisioning database 136, a connector 138, a scheduler 140, and a network 142.

In at least one embodiment of the present disclosure, the service provider database 124, the partner database 126, the usage database 134, and the provisioning database 136 store information generated by the 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, the service provider database 124 and the partner database 126 can be "associated" with the marketplace broker 128, and the usage database 134 and the provisioning database 136 can be "associated" with the transaction mediator 132. Each of the service provider database 124, the partner database 126, the usage database 134, and the provisioning database 136 can also be "associated" with a server or computing device remote from the marketplace 122, where the remote server or computing device is capable of bidirectional data transfer with the 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 bidirectional data transfer with each other.

For clarity, each of the service provider database 124, the partner database 126, the usage database 134, and the provisioning database 136 is shown as a single database in FIG. 1A. It will be understood by those skilled in the art that each of the service provider database 124, the partner database 126, the usage database 134, and the provisioning database 136 may include multiple databases connected by software and hardware systems (e.g., the Internet) of a type 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 by 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 include a relational database architecture, noSQL, OLAP, or other database architecture of a type well known in the database art. Each of the service provider database 124, the partner database 126, the usage database 134, and the 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 system, or database management systems available from ORACLE or SYBASE. Each of the service provider database 124, the partner database 126, the usage database 134, and the provisioning database 136 retrievably stores information communicated to it, as further disclosed herein.

In at least one embodiment of the present disclosure, the marketplace broker 128 is configured to manage contracts established between various entities in the system 100 (e.g., the service vendor 102, the cloud broker 104, the first reseller 106, the end customer 112, etc.). For example, all subscriptions to services provided by any of the multiple service vendors 102 are governed by a contract that 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., the 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 and not the service vendor's contract terms. 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.

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 allocating a contract, the service provider 102 may provide the marketplace 122 with service plans, billing rules, and connectors (e.g., connectors 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.

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, the partner 104a may be an entity that wishes 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 so that the service of the service vendor 102 can be contracted. This may be considered "provisioning." For example, referring to FIG. 1A, the cloud broker 104 may be run by the partner 104a, who wishes to provide 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 reseller 106 or even end customer 112.

In at least one embodiment of the present disclosure, the marketplace 122 further includes an integration connector 130 configured to receive usage reports based on the partner's subscription from the transaction mediator 132 (as further disclosed herein). For example, the contract between the marketplace broker and the partner may require that invoices be sent on the first of each month, and the integration connector 130 sends a request to the transaction mediator 132 on the first of each month to receive the required data. The integration connector 130 requests service usage (per service SKU) for a particular service and receives total usage per SKU in the service unit. Because the cloud service broker marketplace of the embodiment shown in FIG. 1A does not operate on direct information from the service customer about the service customer's activity and transactions performed, the cloud service broker marketplace must extract this information by monitoring transactions that pass through the connector using the transaction mediator and integration connector.

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 a plurality of 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, so that the connector 138 is configured to define the partner 104a and its subscriptions. It will be appreciated that any tenant (e.g., end customer 112) and end user IDs are generated by the cloud broker 104, and subscription IDs are generated by the service vendor 102 when each of the multiple service vendors 102 confirms successful provisioning to the connector 138. It will be further appreciated that while a single connector 138 is shown, 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.

In at least one embodiment of the present disclosure, the marketplace broker 128 is configured to sell services to a partner (e.g., partner 104a) via the marketplace 122 according to a service plan for this particular partner. For each sale of the partner's service, the 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 the marketplace 122 and to coordinate a provisioning channel. At the same time, the marketplace broker 128 provides billing services to the partner via the associated connectors 130 and the transaction mediator 132. It will be appreciated 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 a service.

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), cloud service broker identification, 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 an entity 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 is further operative to perform an analysis of the activity by the transaction mediator 132.

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

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, an upgrade of software and/or services from the service vendor 102a, a downgrade of software and/or services from the service vendor 102a, a cancellation of a service 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 a subscriber 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.

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

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., first reseller 106, second reseller 108, third reseller 110), and the usage and pricing for each entity in the system 100.

In at least one embodiment of the present disclosure, the cloud broker 104 may be run by the partner 104a, which operates to provide the services of the service vendor 102 to the subscriber. 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 pro-rated according to the 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 generated by the subscriber, the vendor 102a tracks this information and the transaction mediator 132 is configured to receive this information.

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 hold the consumption of cloud services by the subscribing entities. It will be appreciated that the cloud broker 104 is configured to enable partners to capture and bill the usage of subscribers (e.g., end customers 112), while the marketplace broker 128 may operate to bill partners for the usage of the connectors 138.

The transaction mediator 132 is further configured to record transactions with a software agent indicative of 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.

It will be appreciated that revenue matching and settlement serves 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 the transaction mediator collects all data about the transactions that pass through the connector so that the marketplace broker can estimate the cost of sale per each service (SKU). It will be further appreciated that the marketplace broker has all the data necessary for this. The marketplace enforces the 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.

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 further disclosed herein.

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 lower-level reseller, which will be understood to operate to further resell the service from the first reseller 106, as disclosed above. The third reseller 110 may include a tenant that subscribes to the service from the marketplace broker 128, which will be understood to operate to use the service. It will be further understood that the end customer 112 may be an end user of the 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 service provided by the reseller 110).

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 necessary, for each to implement its own billing and pricing rules, as further disclosed herein.

2, a flow diagram and components of a method for transaction processing in a cloud services broker platform are shown and generally indicated at 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.

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 a monthly billing period (i.e., the billing period is one month) and the incentive includes a first month free service. It will be appreciated that the transaction attributes (also known as billing rules) result from agreements between various entities in the system 100 (e.g., the cloud broker 104, the first reseller 106, etc.). It will be further appreciated 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 contract anniversary dates, may be included with respect to each of the transactions 202.

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. The 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., first month), the subscriber will not be 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 210a is added to subscriber cost 212a. The attributes of add-on 212 indicate that the 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 add-ons 212 may have their own alignment attributes such that their billing cycle is not aligned with the parent's billing cycle (i.e., purchase 210).

In at least one embodiment of the present disclosure, a subscriber may also wish 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). Upgrade 214 includes attributes of pro-rata during the "old" period and pro-rata during the "new" period. During the billing cycle in which upgrade 214 is initiated, the transition from subscriber cost 214a to subscriber cost 214b results in the subscriber's costs being pro-rataed on a monthly billing cycle on either side of the transition (i.e., the subscriber is pro-rataed based on subscriber cost 214a from the start of the billing cycle until before the upgrade, and is pro-rataed based on subscriber cost 214b from the time of the upgrade until the end of the billing cycle).

In at least one embodiment of the present disclosure, billing period cost 220 is calculated based on the sum of multiple costs incurred by the enrollee at the end of each billing period. For example, during billing period 220a, and assuming one enrollee initiates all transactions 202, the enrollee's costs may include enrollee cost 210a, enrollee cost 212a, enrollee cost 214a, enrollee cost 216a (including transitions to downgrades). It will be understood that the cost of billing period 220a is the sum of all individual service costs incurred by the enrollee. It will be further 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.

2A, an example embodiment 240 of an example method for aligning revenue streams in a cloud service broker platform is shown, in accordance with at least one embodiment of the present disclosure. In the 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 the example 240, each of the multiple subscriptions has a subscription alignment, with an anniversary date falling on the 10th of each month (start/end of each billing period for each of the multiple subscriptions). Additionally, each of the multiple subscriptions includes a promotional period during which the service vendor provides a free period until 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 determined by the service vendor 102.

Continuing with example 240, a first enrollee (e.g., end customer 112) may initially subscribe to service plan P1, as shown at 250a, a second enrollee may initially subscribe to service plan P3, as shown at 252a, and a third enrollee may initially subscribe to service plan P4, as shown at 254a. At the end of the billing cycle, for each of the enrollees, 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 of 260b is $0 because each of the plans includes a promotional free service period that ends on the first contract anniversary date, 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 sends an invoice to the marketplace broker 128, it is necessary to match the cost (i.e., the amount paid to the vendor) with the revenue (i.e., the amount received from the reseller or partner). 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 invoice to generate accurate cost-revenue matching.

Continuing with the above example, FIG. 2B illustrates an agreement between the cloud broker 104 and its subscribers (e.g., end customers 112a, 112b, 112c, 112d) where the subscribers sign up for monthly subscriptions. As shown in FIG. 2B, for this subscriber, plan P1 costs $120, plan P2 costs $240, and plan P3 costs $360. It will be further appreciated 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.

According to the billing model shown in FIG. 2B, broker sales 270 for each period follow the total sales 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.

In at least one embodiment of the present disclosure, the 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 payment 272 of cloud broker 104 is shown. In this example, as shown in 260b, broker sales during period 270b of plan P1 are $120, but broker payment during the same period of plan P1 is $0. It will be appreciated that there is a cost revenue alignment between broker sales 270 and broker payment 272 for every billing period, as shown in FIG. 2C.

3, a flow diagram and components of a method for aligning revenue streams in a cloud service broker platform are shown and generally indicated at 300. The flow diagram 300 shows services 302, service billing rule attributes 302a, billing period 310, and monthly service amount in service units 312. In at least one embodiment of the present disclosure, each of the services 302 represents a service subscribed to by a subscriber (e.g., end customer 112). It will be appreciated that the services 302 may be received from the cloud broker 104 or from the marketplace broker 128 depending on the provisioning channel architecture, in other words, whether the cloud broker 104 and the 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 the 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 during cancellation, for example.

In at least one embodiment of the present disclosure, each of the monthly consumed service amounts 312 in a service unit is calculated by adding each of the individual amounts of the service during a particular billing period 310. For example, during billing period 310b (February), the monthly service total amount 312b includes consumed service amounts associated with SKU-A1, SKU-B2, SKU-C3 (afp), SKU-D4 (apf) and SKU-D4 (uff). Each of the monthly service total amounts 312 is calculated by adding each individual amount associated with the service 302 based on each of the service attributes 302a. The monthly consumed service amounts are then calculated per SKU, for example, during billing period 310b (February), as follows: 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 according to billing rules.

Now referring to FIG. 4, a flow diagram and components of a method for aligning revenue streams in a cloud services broker platform are shown, generally indicated at 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 a number of billing periods (406a, 406b, and 406c). For each of the billing periods, 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 appreciated that the subscription period 404 may be divided into a number of 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.

Referring now to FIG. 5, a method and components for aligning revenue streams in a cloud service broker platform is shown and generally indicated at 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 invoice for the end customer 112a.

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 from when 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, but with an invoice due date on the 4th of each month and payment 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, but with an invoice due date on the 5th of each month and payment due at the end of the billing period.

In at least one embodiment of the present disclosure, in step 504, costs are calculated at the cloud broker (marketplace) 128. For example, the cloud broker (marketplace) 128 may need to generate an invoice on a monthly billing period basis 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.

In at least one embodiment of the present disclosure, costs are calculated in step 508 for the resellers 106a, 108a. Again, each of the resellers 106a and 108a may have independent contract terms and conditions, so the billing characteristics will be different from the characteristics 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.

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

6, a method for billing and reconciliation in a cloud service broker platform is shown and generally indicated at 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 cooperative 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 to determine 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 cooperative connector 130, a step 614 in which the cooperative 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 method includes step 616 of applying the pricing model of the service vendor 102 to generate the report, step 618 of the affiliate connector 130 requesting the service usage report for partner 104a billing, step 620 of the transaction mediator 132 receiving the billing rules from the subscription of the partner 104a and the transaction mediator 132 applying the billing rules to determine the service usage data, step 622 of the transaction mediator 132 calculating the total usage of the service, step 624 of the transaction mediator 132 sending the report to the affiliate connector 130, step 626 of the affiliate connector 130 sending the report to the marketplace broker 128, and step 628 of the marketplace broker 128 applying the pricing model from the subscription of the partner 104a for the usage report and billing the partner 104a.

7A and 7B, a system for aligning revenue streams in a cloud services 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.

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 appreciated 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 pertaining to 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 prices in a database operatively connected to the ISV rating engine 702. It will be further appreciated that the ISV rating engine 702 can implement price formation rules based on the past history of user transactions, such as volume discounts, renewal period length, and other current price calculation rules.

In at least one embodiment of the present disclosure, the cos. calculator 704 is configured to calculate the actual cost of sale of each transaction or contract made 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., there is no dependency 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 in 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 are flexible for the marketplace broker 128 and generate a larger revenue stream, as compared to the terms of the contract where 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 the 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).

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 from the ISV rating engine 702 an estimate of the cost of each resource SKU for a period defined by the contract between the marketplace broker 128 and the reseller 106. It will be appreciated that, as disclosed herein, the cos. calculator 704 aligns cost streams and revenue periods that are important for further revenue alignment and settlement. For example, some billing periods of the contract between the marketplace broker 128 and the reseller 106 may be longer than billing periods from the contract 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.

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 appreciated 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 be operable together to perform the functions delegated to the ERP system 706 by the present disclosure.

Referring now to FIG. 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.

The ISV catalog 802 is a service that runs 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 that are integrated with the cloud service broker marketplace system through a connector. The product catalog also includes a set of resources associated with the service. 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 price formation settings, such as dependencies from volume on which the price formula can depend, duration of use, special discounts for some types of clients, various arguments, etc. The ISV can use various pricing settings, but combine these to set its own price conditions, including price conditions in the form of a formula. The price formation catalog 806 stores the price conditions set by the ISV through the tool 808 or manually. The ISV billing rules store the billing rules for the service and related resources. The various billing rules are illustrated in FIG. 2 at 202. The contract manager stores the contract terms between the ISVs 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 changes in product listings, prices, billing rules, or contracts from the ISV side. The user input interpreter 818 is the UI for the ISVs and helps them interact with the ISV catalog service 802.

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 hierarchical 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 (set by the vendor, set for partners, resellers).

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 utilization manager 914, an ISV contract catalog interface 916, a cos. calculator interface 918, an ERP interface 920, and a federation utilization calculator 922.

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 is configured to take over the function of the federation connector 130 and calculate the usage per SKU and report it to the marketplace computing device 122.

10, a method 1000 for aligning revenue streams in a cloud service broker platform is shown, according to at least one embodiment of the present disclosure. In at least one embodiment of the present disclosure, in step 1002, the transaction mediator 132 sends any transaction including a "collect" request for any service resource. The method 1000 proceeds to step 1004, where the ISV rating engine 702 requests the ISV catalog 802 for the contract details (e.g., pricing rules, etc.) of the service resource and waits for the usage report. In step 1006, the transaction mediator 132 checks whether this contract exists, and if so, proceeds to step 1008, otherwise proceeds to step 1036. In at least one embodiment of the present disclosure, in step 1008, the transaction mediator 132 sends the usage report to the ISV rating engine 702. The ISV rating engine 702 collects the usage report and creates a fee with a price that follows the pricing rules. For example, the ISV rating engine 702 may create one rate for each billing period associated with this resource set up with the service vendor 102. Alternatively, if a contract defines different prices for different amounts of resources, 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.

In at least one embodiment of the present disclosure, the ISV catalog 802 includes contract details for contracts between the marketplace broker 128 and the service vendor 102. In particular, each contract 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 number) associated with this application, subscription period, price formation rules, currency, unit of measure, billing rules for activation, cancellation, modification (e.g., add-on, upgrade, downgrade) and invoicing. It will be appreciated that the ISV catalog 802 also has a user interface for price formation rule configuration, and a price constructor tool including a catalog containing all possible price formation rules, and a user interface for the service vendor or other entity to set up the price formation rules. It will be appreciated that the various price 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).

Continuing with method 1000, in 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, otherwise method 1000 proceeds to step 1038, where it is checked whether the transaction is "initiate".

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: contract anniversary date, including free, full price, and pro rata. If the transaction is indeed an "activation", the method 1000 proceeds to step 1058, and the transaction may be stored as "false" since a contract already exists as determined in step 1006 (similarly, if in step 1040, it is determined that the transaction is an "activation", the method proceeds to step 1042, otherwise the method proceeds to step 1036, and the transaction is stored as "unaligned").

If the transaction is not an "initiate," method 1000 proceeds to step 1014. In step 1014, it is determined whether the transaction is a "cancel." In at least one embodiment of the present disclosure, a cancel has three associated attributes: free, full, and pro-rated. If the transaction is not a cancel, method 1000 proceeds to step 1060.

If the transaction is a cancel, the method 1000 proceeds to step 1016 where existing active resource subscriptions are identified on the resources associated with the transaction. The method 1000 then proceeds to step 1018 where the service vendor 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.

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

Referring back 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 the price formation 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 furthest billing date of the service vendor 102. For example, transaction data is identified in step 1050, price formation rules are determined in step 1052, and the price is implemented in step 1054. In step 1056, the created rate is stored.

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: free, full, and pro-rata for the old subscription, and free, full, and pro-rata for the new subscription.

In at least one embodiment of the present disclosure, existing active resource subscriptions on resources associated with the transaction are identified in step 1062. In 1064, the type of change transaction is identified and the billing period of the service vendor 102 is identified for the 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 the 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.

The method 1000 then proceeds to step 1090 where it is determined whether any estimated charges exist for further billing periods. If there are no charges to store, the method 1000 ends at step 1092. If so, charges are created at step 1094 for all estimated charges, including prices associated with the estimated charges associated with the resource. It will be further appreciated that at step 1096, the prices of the estimated charges are identified, and at step 1098, all created charges associated with the transaction are stored and listed.

It will be understood that in the CSB platform, the base price of resources 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 (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 computing resources, to name a few non-limiting examples). 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 the discounts can be set as percentages and in cash equivalents as delta modifications. It will be understood that the discounts can be set as a combination of terms.

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 amount 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 corrective charge is issued if some threshold for the discount is achieved. The ISV rating engine 702 implements the pricing and billing rules for each resource SKU after receiving the transaction from the transaction mediator 132 and requesting the contract details from the ISV catalog 802.

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 there is a resource subscription associated with the received request. If there is not, method 1100 proceeds to step 1106 and then loops back to step 1102.

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

In at least one embodiment of the present disclosure, in step 1112, a check is made to see if the end date of the requested quote period is beyond 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.

If so, method 1100 proceeds to step 1114 where 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 charge 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 charge is sent and stored for the requested period.

It will be appreciated that the ISV catalog 802 may include rules for quotations. For example, if a service vendor (such as Microsoft) has a prepaid system, such a service vendor may set up rules for the next billing period to calculate the average resource consumption amount and prepare an invoice according to such rules. At the end of such billing period, the service vendor may send a corrected invoice, and it will be further appreciated that the ISV rating engine 702 may implement such corrections to the quotation request from the cos. calculator 704.

Referring now to FIG. 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 an ISV rating engine 702 to send recurring reports to an ERP system 706 in accordance with at least one embodiment of the present disclosure.

The method 1200 begins at step 1202 by checking whether an asynchronous task for repeated grading is received. It will be appreciated that the task may also be synchronous. If no such task is received, the method 1200 loops back to 1202.

If a task is received, 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 the task is performed for each group.

In at least one embodiment of the present disclosure, in step 1208, the ISV catalog 802 is queried for a set of price rules 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, the price formation rules are determined, and in step 1214, the price is implemented.

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

Referring now to FIG. 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 an ISV rating engine 702 to monitor changes in an ISV contract catalog 802 in accordance with at least one embodiment of the present disclosure.

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.

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 cancelled. The method 1300 then proceeds to step 1312, where charges for the billing period are generated. In step 1314, the price formation rules are determined, and in step 1316, the prices are implemented.

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

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.

In at least one embodiment of the present disclosure, the cos. calculator 704 receives information about the billing periods set up for the contract between the marketplace broker 128 and the reseller 106 by either: the marketplace broker 128 may receive information 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 appreciated that the marketplace computing device will include a contract catalog of the tiered parties, including the prices and billing terms of each partner. It will be further appreciated 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 a marketplace computing device has the same ISV rating engine to calculate revenue according to information received from the same transaction mediator 132 through the federation connector 130, and to implement pricing and billing rules from the partner contract catalog.

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

Claims (4)

receiving, at an independent software vendor (ISV) rating engine, a new request for quote from a cost of sales calculator;
identifying in said independent software vendor rating engine an end date for said new request for quotation;
comparing the termination date and a nearest future billing date in the independent software vendor rating engine, the nearest future billing date being based at least in part on a contract between a service vendor and a cloud services broker platform;
requesting a plurality of pricing rules from an independent software vendor catalog in the independent software vendor rating engine, the plurality of pricing rules including a preferred billing term and a billing date for the new request for quote;
generating, in the cloud services broker platform, at least one rate for the billing date that follows an end date of the new quote request;
assigning, in the cloud services broker platform, a next billing date that includes a billing date that follows the end date of the new quote request.
A method for aligning revenue streams in a cloud services broker platform. The method of claim 1, further comprising the step of transmitting a price for the new quote request to a database within the cloud service broker platform. The method of claim 1, wherein the at least one fee further includes a conditional price formation and a latest price formation. The method of claim 3, wherein the conditional pricing includes at least one billing rule for a pricing condition.