Patent Application
20180232786
This disclosure relates to a system and method of billing, and more particularly, to a system and method for matching revenue streams in a cloud service broker platform.
Currently, many software vendors offer their software via online service platforms. Such software as a service (SaaS) platforms, allow SaaS subscribers/end users to obtain and use software services that are hosted by the SaaS provider. SaaS, also referred to as “on-demand software,” is usually priced on a pay-per-use basis, or using a subscription fee. For example, a SaaS subscriber can pay a monthly (or yearly) subscription fee to the SaaS vendor for access to the SaaS platform for a particular time period (e.g. for a month). Conversely, in a pay-per-use scheme, a SaaS subscriber pays the SaaS provider based on the subscriber's usage of the SaaS platform, within a given period. For example, a subscriber may be charged based on a rate per usage, the usage being metered based on one or more resources within the SaaS platform. In these “subscriber-vendor” schemes, billing between a subscriber and a SaaS vendor is a one-to-one relationship wherein the SaaS vendor's costs are passed directly to the subscriber, which the subscriber will then pay to ensure continued access to the SaaS platform.
In an alternate system of software services distribution, a cloud services broker is used. A cloud services broker is an organization that acts as an intermediary between subscribers/end users and SaaS vendors. A cloud services broker may integrate different software services (available from various SaaS vendors) to present a unified set of services (i.e. a cloud services package) to a subscriber. In some situations, the cloud services broker also hosts the software services and operates in the stead of a traditional SaaS vendor. Additionally, the cloud services broker allows for the provisioning and selling of subscriptions to a variety of SaaS vendors at different levels, resulting in a hierarchical system of downstream resellers. These resellers can subsequently re-sell services to sub-resellers and end-users. In some situations, these re-sellers may price the SaaS offerings at different pricing schemes compared to the SaaS vendors and/or the cloud brokers.
Billing in a 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 distribution system. However, revenue matching and settlement may be problematic. For example, the complexities of billing in a cloud broker system arise because of the intermingling of the types of SaaS vendors, the influence of resellers, and the various billing schemes offered by each of these entities. For example, a cloud services package may include a plurality of software services from a plurality of SaaS vendors. The each of these pluralities of software services in the cloud services package may include various billing schemes (e.g. a combination of usage based and subscription based schemes, and each with varying incentives and billing attributes). Furthermore, downstream resellers may offer their own unique pricing schemes for the cloud services package.
When subscriber end users obtain software services from the cloud services broker, or a downstream reseller, billing for these subscriber end users is not a one-to-one relationship like in the traditional “subscriber-vendor” scheme. Instead, subscriber end users in the cloud services broker scheme may be billed based on different pricing within the layers of the cloud services brokerage distribution channel. Therefore, implementing such a billing scheme must account for the variations in billing rules and billing schemes from the entities throughout the hierarchy (i.e. SaaS vendors, resellers, sub-resellers, etc.). Furthermore, there may be a disparity between billing rules from upstream entities (e.g. SaaS vendors) and downstream entities (e.g. resellers), whereby billing imposed on subscriber end users based on one particular entity billing scheme is inappropriate. For example, fixed markups and discounts may be applied by upstream entities (e.g. SaaS vendors), which markups and discounts may not be appropriate for downstream entities (e.g. end users of resellers). Similarly if the same billing rules are applied on each level of the software distribution system, it would result in non-flexible contracts and rules of software services distribution. Additionally, there is an inability to customize pricing (and the corresponding billing rules) based on the specific types of entities in the distribution channel. For example, a direct subscriber end user may be charged differently than an indirect subscriber end user. This results in lost revenues across different elements of the software distribution system. Lastly, there is also the inability to perform wholesale purchases of services to be distributed following different billing rules, which also result in lost opportunity of larger service distributors.
Therefore, there is a need for an improved system and method for matching revenue streams in a cloud service broker platform.
In at least one embodiment of the present disclosure, a system for matching revenue streams in a cloud service broker platform is provided. The system includes service vendors, a cloud broker, resellers at different hierarchical levels such as first resellers, second resellers, and third resellers. The system further includes end customers where the end customers may receive services directly from the service vendors, or indirectly via resellers
In at least one embodiment of the present disclosure, the system for matching revenue streams in a cloud service broker platform includes a marketplace, a service provider database (vendor contract catalogue), a partner database, a marketplace broker, an optional federated connector, a transaction mediator, a usage database, a provisioning database, a connector, a scheduler, and network.
In at least one embodiment of the present disclosure, the marketplace broker is configured to manage the contracts established between the various entities in the system.
In at least one embodiment of the present disclosure, the marketplace broker is configured to store a catalog of available services, configured to monitor the billing usage of the connector, and includes the federated connector (optionally).
In at least one embodiment of the present disclosure, the marketplace broker is configured to sell services via the marketplace to partners.
In at least one embodiment of the present disclosure, the marketplace further includes a transaction mediator configured to store the billing information about all transactions going through the system. The marketplace is further configured to store reconciliation-specific details about all transactions going through the system
In at least one embodiment of the present disclosure, the cloud broker may be operated by a partner, the partner operating to offer the service of the service vendor, to a subscriber.
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 singular entity.
In at least one embodiment of the present disclosure, a method for matching revenue and cost streams in a cloud service broker platform is provided. The method includes determining transactions, as applied over billing periods, initiating a transaction, whereby the subscriber's billing cycle is updated or initiated based on the transaction attributes, calculating billing period costs, determining contracts between a service vendor and a cloud broker, and calculating the broker cost of sales for each period.
In at least one embodiment of the present disclosure, the method includes maintaining records of the contracts and subscriptions for each service vendor, and calculating the each of the individual costs of the services during particular billing periods.
In at least one embodiment of the present disclosure, the method includes calculating costs at the each of the service vendor, calculating service costs at the cloud broker, calculating costs at the resellers, and generating a consolidated invoice for end customer(s).
In at least one embodiment of the present disclosure, costs are calculated for the each of the service vendor, the cloud broker, the resellers, and a consolidated invoice is generated for end customer(s)
In at least one embodiment of the present disclosure, the method includes reporting attributes of a provisioning operation to the transaction mediator, storing the data in the service usage database, requesting the service usage report for reconciliation with the service vendor, receiving billing rules of service vendor, calculating the total usage of the service, sending the report to the federated connector, transmitting the report to the marketplace broker, applying the pricing model of the service vendor to create a usage report for reconciliation with the service vendor, requesting the service usage report for partner invoicing, receiving billing rules from the partner's subscription, calculating the total usage of the service, sending the report to the federated connector, transmitting the report to the marketplace broker, applying the pricing model from the partner, and invoicing the partner.
In at least one embodiment of the present disclosure, the method further includes reporting attributes of a provisioning operation to transaction mediator, storing the data in the service usage database, initiating estimation of cost of sales per service SKU, implementing billing rules of service vendor, calculating cost of sales per service SKU, reporting cost of sales per service SKU to ERP system.
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 disclosure will be set forth in the description that follows, and will be apparent from the description, or may be learned by practice of the disclosure. It is to be understood that both the foregoing general description and the following detailed description are exemplary and explanatory and are intended to provide further explanation of the disclosure as claimed.
Referring now to
In at least one embodiment of the present disclosure, the service vendor(s) 102 are entities that provide service subscriptions to its clients (e.g. business enterprises or customers of different size). For clarity, service vendor(s) 102 may also be referred to as “service providers,” and it shall be understood that both terms may be used interchangeably. Additionally, the service vendor(s) 102 can provide subscriptions to applications and services located on the independent software vendors' hosting servers (not shown). The service vendor(s) 102 can further host services that are subscribed to by customers. Service vendors 102 may be software development companies that develop, support and run services (usually on their own cloud infrastructures). The service vendor(s) 102 also sells and provides subscriptions to their services. It will be appreciated that the service vendor(s) 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(s) 102 for use in external applications. The service vendor(s) 102 may include a plurality of service vendors (e.g. service vendor(s) 102a, 102b, and 102c), such as, for example, Dropbox®, Amazon® Web Services, and Office 365®. The each of the plurality of service vendor(s) 102 offer various software services, such as, email, web hosting, file sharing and storage, networks, telephony, messaging, video conference, general communication, 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 vendor(s) 102 may offer their services to resellers or to end customers directly.
In at least one embodiment of the present disclosure, the service vendor(s) 102 is configured to monitor usage of their services by resellers and end customers. For example, service vendor(s) 102a (Office 365®) may be configured to monitor the compute resource usage caused by a subscriber's use of the service vendor(s) 102a's service. It will be appreciated that the compute resources can include at least one metered metric selected from a group consisting of one or more compute resources used on a per time 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 appreciated that the metering usage can be conducted at one or more of an application programming interface (API). It will also be appreciated that the metrics obtained from such monitoring may be stored in the service vendor(s) 102's environment, or can be transmitted to other entities in the system 100, such as, for example, via the Internet.
It will be appreciated that the service vendor(s) 102 may be configured to apply their own billing rules. For example, the service vendor(s) 102b (e.g. Amazon® Web Services), may apply a flat rate, monthly pricing structure, while service vendor(s) 102c (e.g. Dropbox®) may apply a rate commensurate with usage of compute resources. It will be further appreciated that the service vendor(s) 102 may transmit billing rules to other entities in the system 100.
In at least one embodiment of the present disclosure, the system 100 further includes a cloud broker 104. A cloud broker 104 is an entity which integrates different software services (e.g. from service vendor(s) 102) via an API and provides functionality of provisioning, and selling subscriptions to the services of the service vendor(s) 102, to a variety of 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 vendor(s) 102. For example, a service vendor that provides communications service (e.g. email), will have a different interface than a hosting or storage service vendor (e.g. Dropbox). It will be further appreciated that provision of different interfaces supports a hierarchical 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, first resellers 106 may be geographically based resellers (e.g. first reseller 106a serves the U.S., first reseller 106b serves France, and first reseller 106c serves Brazil). The system 100 may further include downstream resellers, such as second resellers 108, and third resellers 110. The resellers may be organized based on any factor, such as geographic distribution, industry verticals, consumer verticals, or technology verticals, to name a few non-limiting examples. Although only a select number of resellers and downstream resellers are shown, it will be appreciated that the system 100 may include any number of resellers, and downstream resellers, connected by software and hardware systems of a type well known in the art (e.g. the Internet), which collectively are operable to perform the functions delegated to the resellers according to the present disclosure.
In at least one embodiment of the present disclosure, the system 100 further includes end customers 112. The end customers 112 may include individuals or enterprise organizations that are subscribing to services offered by the service vendor(s) 102 (or those that may at least originate from service vendor(s) 102). It will be appreciated that the end customers 102 may receive services directly from the service vendor(s) 102, or indirectly via resellers. For example, referring to
Referring now to
In at least one embodiment of the present disclosure, the service provider database 124, the partner database 126, the usage database 134, and provisioning database 136 store information generated by the system 120 and/or retrieved from one or more information sources. In at least one embodiment of the present disclosure, the service provider database 124, and the partner database 126, can be “associated with” the marketplace broker 128, and the usage database 134, and provisioning database 136 can be “associated with” transaction mediator 132, as shown in the embodiment in
For purposes of clarity, the each of the service provider database 124, the partner database 126, the usage database 134, and provisioning database 136 are shown in
In at least one embodiment of the present disclosure, the marketplace broker 128 is configured to manage the contracts established between the various entities in the system 100 (e.g. service vendor(s) 102, cloud broker 104, first resellers 106, end customers 112, etc.). For example, every subscription to a service offered by any of the plurality of service vendor(s) 102 is governed by a contract, wherein the contract memorializes the terms of the service such as pricing, licensing costs, and service level agreements, to name a few non-limiting examples. Similarly, resellers (e.g. first resellers 106) may have additional (or different) contract terms wherein an end customer 112's receipt of service is governed by the terms of the reseller contract, as opposed to the terms of the service vendor's contract. In such an exemplary embodiment, the possibility to provision, sell and modify a particular service is managed by the applicable contract terms of the service vendor(s) 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. the services offered by service vendors or resellers). A service offered by service vendor(s) 102 is considered ‘available’ when the service vendor(s) 102 has a contract with the marketplace 122. In the process of assigning a contract, the service providers 102 may provide service plans, billing rules for each service (e.g. an SKU, as further disclosed herein) and a connector (e.g. connector 138) to the marketplace 122. The service vendor(s) 102's plans and billing rules 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 the billing usage of the connector 138. For example, partner 104a may be an entity that desires to offer service based on service vendor(s) 102. When the partner 104a creates a new service offering based on the service vendor(s) 102, the partner 104a uses the connector 138 to operably connect to the marketplace 122, such that the services of the service vendors 112 can be contracted for. This may be considered as ‘provisioning.’ For example, referring to
In at least one embodiment of the present disclosure, the marketplace 122 further includes the federated connector 130, the federated connector 130 configured to receive usage reports based on partner subscription from the transaction mediator 132 (as further disclosed herein). For example, a contract between a marketplace broker and a partner may require that the invoices be sent on the first day of the month, wherein the federated connector 130 sends the requests to the transaction mediator 132 on the first day of the month, to receive the necessary data. Federated connector 130 requests service usage of a particular service (per service SKU) and receive total usage per SKU in service units. As cloud service broker marketplace on the embodiment presented on the
In at least one embodiment of the present disclosure, the marketplace 122 further includes the connector 138. The connector 138 is configured specifically for every service (for example, a service provided by any of the service vendor(s) 102). For each of the plurality of service vendor(s) 102 (for example, as shown in
In at least one embodiment of the present disclosure, the marketplace broker 128 is configured to sell services via the marketplace 122 to partners (e.g. partner 104a) in accordance with service plans for that particular partner. It will be appreciated that for each sale of a partner's services, the marketplace broker 128 sends a request to a connector hub (not shown, but as disclosed in U.S. application Ser. No. 15/005,151, for PROVISIONING APPLICATIONS USING A CONNECTORS HUB SERVICE, which application is incorporated in its entirety by reference herein) to deploy a connector instance (e.g. connector 138) for the partner (e.g. partner 104a) to operably connect with the marketplace 122, and to tune the provisional channel. At the same time, the marketplace broker 128 provides billing service to the partner via the federated connector 130 and transaction mediator 132. It will be appreciated that the marketplace broker 128 operates in the same manner as the cloud broker 104 but that the cloud broker 104 provides the channel to sell software as a service, while marketplace broker 128 provides the mechanism to provision the service that will be eventually sold as a service.
In at least one embodiment of the present disclosure, the connector 138 is operably connected to the transaction mediator 132, for example, when provisioning of a service is accomplished. The connector 138 is further configured to report to the transaction mediator 132, wherein the report includes, a date of activation, provisioning, cancellation, change, service ID (as further disclosed herein), identification of a cloud service broker, the number of services, markers of actions such as activation, change and cancellation, to name a few non-limiting examples. It will be further appreciated that the connector 138 may report ID's of entities within a hierarchical billing system. For example, entities may include first resellers 106, second resellers 108, third resellers 110, and end customers 112. The connector 138 further operates to perform analysis of the activities by the transaction mediator 132.
In at least one embodiment of the present disclosure, the system 120 further includes a scheduler 140 that is operably connected to the connector 138. It will be appreciated that in an exemplary embodiment selling services include disk space, CPU-time (pay-as you go services). The scheduler 140 is configured to provide tracking of resource usage (e.g. disk space usage, CPU-time), by sending periodic requests to the applicable service vendor(s) 102, to retrieve such information. The scheduler 140 is further configured to transmit resource usage information to the transaction mediator 132 as needed, or periodically.
In at least one embodiment of the present disclosure, the marketplace 122 further includes a transaction mediator 132. A transaction mediator 132 is configured to store the billing information about all transactions going through the system 120. For example, a transaction between end customer(s) 112 and service vendor(s) 102a, may be of a type such as a purchase of software from the service vendor(s) 102a, an upgrade of the software and/or services from the service vendor(s) 102a, a downgrade of the software and/or services from the service vendor(s) 102a, a cancellation of the services from the service vendor(s) 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, the service identifier being an alphanumeric identifier of a resource type related to the transaction. The transaction mediator 132 is further configured to track the unit of measure (UOM) such as for example, the number of units or licenses being used by the subscriber(s) of the service vendor(s) 102. The transaction mediator 132 may also track the quantity and start and end dates of the service usages, as well as receive any metering or monitoring of compute resource usage, and billing rules from the service vendor(s) 102, to name a few, non-limiting examples.
In at least one embodiment of the present disclosure, the marketplace 122 is further configured to store reconciliation-specific details about all transactions going through the system 120, via the transaction mediator 132. For example, each of the plurality of service vendor(s) 102 may have a vendor identifier (ID) associated therewith. The transaction mediator 132 is further configured to collected other identifiers such as, for example, service vendor-side data (e.g. subscription ID); any other unique identifiers; a partner identifier or subscription ID for any resellers or end customers; partner-side data (e.g. end-customer's subscription ID) and order identifier.
It will be appreciated that for every transaction, the transaction mediator 132 must store minimal amount of data required to report (if applicable), the vendors' identity, the resellers' identify, the end customers' identity, the billing rules from the service vendor(s) 102 and the resellers (e.g. first reseller 106, second reseller 108, third reseller 110), and usage and pricing for the each entity in the system 100.
In at least one embodiment of the present disclosure, the cloud broker 104 may be operated by partner 104a, the partner 104a operating to offer the service of the service vendor(s) 102, to a subscriber. It will be appreciated that the cloud broker 104 is further configured to receive usage information of all tracked resource types by request, and aggregated by resource type and prorated according to terms set forth by the service vendor(s) 102 (or the resellers). Continuing with the previous example, if service vendor(s) 102a (Office 365®) is configured to bill based on compute resource usage caused by a subscriber, the vendor 102a may track 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, a cloud broker 104 may serve first resellers 106, second resellers 108, third resellers 110, and end customers 112 (as shown in
It will be appreciated that the transaction mediator 132 is further configured with a software agent to record transactions, indicative of individual billable provisioning operations of a cloud service, passing between an end customer(s) 112 and service vendor(s) 102. In at least one embodiment of the present disclosure, the information pertinent to the transactions is then processed and passed on to a central system (e.g. marketplace 122) where it could be extracted for billing purposes. It will be further appreciated that by monitoring the provisioning flow, the cloud broker 104 can provide real time billing information without the need to rely on the same billing rules imposed by service vendor(s) 102's data.
It will be appreciated that revenue matching and settlement operates to balance costs and revenue between the marketplace and vendors. For example, the marketplace broker is billed by vendors and generates costs. In at least one embodiment, the partner is billed by the marketplace broker per transaction via connector. In at least one embodiment, the latter generates a revenue stream, whereby the transaction mediator collects all data about transactions moving across connector, and the marketplace broker can estimate cost of sales per each service (SKU). It will be further appreciated that the marketplace broker has all needed data for this. Marketplace implements price conditions and approximate Vendors' billing rules on Partner transactions and report it to internal or external ERP system for accounting purposes. More detailed and updated system is shown on
In at least one embodiment of the present disclosure, the cloud broker 104 and the marketplace broker 128 may operate as a singular entity, as shown at system 150, in
In at least one embodiment of the present disclosure, the system 150 includes a first reseller 106, second reseller 108, third reseller 110, and end customer 112. It will be appreciated that the second reseller 108 may include a sub-reseller, wherein the sub-reseller operates to further resell the services from first reseller 106, as disclosed above. It will be further appreciated that the third reseller 110 may include a tenant subscribing to services from the marketplace broker 128, wherein the tenant operates to use the services. It will be further appreciated that the end customer 112 may be an end user of the tenant (e.g. an employee end user of a company tenant that has subscribed to the services), or an end user of a reseller type entity (e.g. a direct consumer of integrated software services provided by reseller 110).
In at least one embodiment of the present disclosure, the marketplace broker 128 is operably configured to provision the first reseller 106, second reseller 108, third reseller 110, and end customer 112, as needed in order for each party to perform its own billing and pricing rules, as further disclosed herein.
Referring now to
In at least one embodiment of the present disclosure, the each of the transactions 202 may include transaction attributes such as the start of service date, the billing period, and any incentives, to name a few, non-limiting examples. For example, purchase 210 includes a monthly billing period (i.e. the billing period is a month); and, the incentive includes a first month of free service. It will be appreciated that the transaction attributes (also known as billing rules), come from contracts between the various entities (e.g. cloud broker 104, first resellers 106, etc.) in the system 100. It will be further appreciated that other billing rules may be included for the each of the transactions 202, such as, for example, free period, payment in full, proration for purchase and/or cancellation, add-on, upgrade, downgrade, alignment (e.g. the alignment of billing periods between a parent subscription and a child subscription), and anniversary date.
In at least one embodiment of the present disclosure, subscribers (e.g. end customers 112) may initiate a transaction, whereby the subscriber's billing cycle is updated or initiated based on the transaction attributes. For example, purchase 210 is a transaction to purchase a service. The purchase 210's attributes include a monthly cadence (i.e. a monthly billing cycle), with a first month of free service as the incentive. Therefore, in the first billing cycle, (i.e. the first month), the subscriber is not charged with any fees. Similarly, the same subscriber may initiate an add-on 212 after a few months. In such an example, the costs of the add-on 212 are added to the total costs of the subscriber's services. As shown in
In at least one embodiment of the present disclosure, a subscriber may also want to upgrade a service. For example, an upgrade 214 transaction may be initiated (for example, at the marketplace 122), whereby the subscriber cost 214a is modified to the upgraded subscriber cost 214b (as shown in
In at least one embodiment of the present disclosure, a billing period costs 220 is calculated at the end of each billing period, based on the summation of the plurality of costs incurred by the subscriber. For example, during the billing period 220a, and assuming that one subscriber has initiated all the transactions 202, the subscriber's costs may include, the subscriber costs 210a, the subscriber costs 212a, the subscriber costs 214a, subscriber costs 216a (including the transition to a downgrade). It will be appreciated that the billing period 220a's costs is a summation of all the individual services costs incurred by the subscriber. It will be further appreciated 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.
Referring now to
Continuing with example 240, a first subscriber (e.g. an end customer 112) may initially subscribe to service plan P1, as shown at 250a; a second subscriber may initially subscribe to a service plan P3, as shown at 252a; and a third subscriber may initially subscribe to service plan P3, as shown at 254a. At the end of the billing cycle, for the each of the subscribers, the service vendor(s) 102 would send a billing invoice to the appropriate cloud broker (e.g. cloud broker 104), as shown at 260b, 262b, 264b, 266b, and 268b. For example, 260b indicates the total costs for subscribing to the plans P1, P2, and P3 during the billing period 260a. In the present example, the costs at 260b are $0 because the each of the plans includes a promotional free period of service that concludes at the first anniversary, as defined above. Similarly, at 262b (the costs for billing period 262a), the cost for plan P1 is $100, the cost for plan P2 is $0, and the cost for plan P3 is $600. It will be appreciated that when service vendor(s) send a billing invoice to the marketplace broker 128, there is a necessity to match costs (i.e. amounts paid to vendors) and revenue (i.e. amounts received form resellers or partners). By using the transaction mediator 132 to track all transactions, the marketplace computing device 122 is configured to simulate the process of vendor's billing by applying vendor's billing rules (which may be stored inside service provider database 12, as further disclosed below). It will be further appreciated that the marketplace broker 128 allows for the reconciliation with the vendor invoices and generate accurate cost-revenue matching.
Continuing with the above example, it is shown in
Following the billing model shown in
In at least one embodiment of the present disclosure, the system 100 is further configured to maintain records of the contracts and subscriptions for each service vendor (e.g. service vendor(s) 102), resellers (e.g. resellers 106), and end customer (e.g. end customers 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
Referring now to
In at least one embodiment of the present disclosure, the each of the monthly amount of consumed services in service units 312 is calculated by adding the each of the individual amount of the services, during particular billing periods 310. For example, during the billing period 310b (February), the total monthly amount of the services 312b includes the amount of the consumed services associated with SKU-A1, SKU-B2, SKU-C3(afp), SKU-C3 (afp), SKU-D4 (apf), and SKU-D4 (uff). It will be appreciated that the each of the monthly amount of the consumed services 312 are calculated by adding the each individual amount associated with the services 302, based on the each of the service attributes 302a. Then monthly amount of the consumed services is calculated per SKU, e.g. during the 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 the each of the monthly costs (or revenue, depending on contracting side—vendor or partner) may be calculated by multiplying monthly amount of the services in service units by price of service unit according to billing rules.
Referring now to
Referring now to
In at least one embodiment of the present disclosure, costs are calculated for the each of the service vendor(s) 102, at step 502. For example, the cloud broker (marketplace) 128 has contract information for each of the service vendor(s) 102 from when the service vendor(s) 102 was first set up (i.e. made ‘available’). For each of the service vendor(s) 102, a contract based pricing scheme is developed. For example, service vendor(s) 102a may charge on a monthly billing cycle based on a license structure, with a billing anniversary falling on the 4th day of the month, with payment in the end of the period. Similarly, service vendor(s) 102b, as an example, may change on a quarterly billing cycle based on a ‘pay-as-you-go’ scheme, with an anniversary date falling on the 5thof the month, with payment at the end of the billing period.
In at least one embodiment of the present disclosure, costs are calculated at the cloud broker (marketplace) 128, at step 504. For example, the cloud broker (marketplace) 128 may have to generate billing invoices on a monthly billing period basis, even though service vendor(s) 102b bills on a quarterly basis. In such an exemplary embodiment, the cloud broker (marketplace) 128 is configured to calculate costs based on expected costs if the billing period of the service vendor is in the future.
In at least one embodiment of the present disclosure, costs are calculated for the resellers 106a and 108a, at step 508. Here again, the each of the resellers 106a and 108a may have independent contract terms such that the billing characteristics are different from that of the service vendor(s) 102. For example, at reseller 108a, service vendor(s) 102a (office365®) may have an anniversary date falling on the 15th of the month, but as noted, service vendor(s) 102a bills on the 4th of the month.
In at least one embodiment of the present disclosure, a consolidated invoice is generated for end customer(s) 112a, at step 510. It will be appreciated that for the end customer 112a, a single invoice is generated such that all costs arising from end customer 112a's subscription are generated onto a single invoice based on the end customer 112a's billing characteristics. It will be appreciated that the end customer 112a's billing characteristics may be different from that of the upstream entities (e.g. service vendor(s) 102, and resellers 106a and 108a).
Referring now to
Referring now to
In at least one embodiment of the present disclosure, the ISV rating engine 702 is operably connected to the transaction mediator 132. The ISV rating engine 702 is further configured to receive transaction information from transaction mediator 132 of the marketplace broker 128. By way of non-limiting examples, transaction types include activations, cancellations, changes, upgrades, downgrades, add-ons, usage collection, and the like. In at, least one embodiment of the present disclosure, the transaction mediator 132 transmits transactions to the ISV rating engine 702. It will be appreciated that each transaction from the transaction mediator 132 includes information such as, for example, resource identifiers, ISV contract identifiers, subscription identifiers, resource Stock Keeping Unit (SKU) values, transaction type, quantity, date, and the like. In at least one embodiment of the present disclosure, the information appurtenant to transactions is declared within the marketplace broker 128. In at least one embodiment of the present disclosure, the ISV rating engine 702 stores charges in a database operably connected to the ISV rating engine 702. It will be further appreciated that the ISV rating engine 702 is able to implement the price formation rules based on previous history of user transactions, such as discounts for volume, length of renewal period, other late price calculation rules.
In at least one embodiment of the present disclosure the cos. calculator 704, is configured to calculate the actual cost of sales for each of the transactions, or contracts occurring on the marketplace 128. In at least one embodiment of the present disclosure, contract terms in a contract between marketplace broker 128 and partner 104 or reseller 106 (depending on provisioning channel architecture, in other words, whether the cloud broker 104 and the marketplace broker 128 operate as a singular entity, as shown at system 700a or not as shown at system 700b) may differ from contract terms between marketplace broker 128 and service vendor(s) 102 (i.e. there is no dependency between these two contracts). It will be appreciated that the marketplace broker 128 may set up any billing rules and price formation rules for reseller 106, the marketplace broker 128 to be flexible and generate bigger revenue streams, when compared to the contract terms paid by marketplace broker 128 to service vendor(s) 102. By way of example, the marketplace broker 128 may sell a software bundle to a reseller 106 containing different applications developed by various service vendors and set up one subscription period for the whole bundle of applications; the marketplace broker 128 may also set up special discounts. However, the marketplace broker 128 will have to match its revenue streams from resellers (e.g. reseller 106) with the costs owed to service vendors (e.g. service vendor(s) 102).
In at least one embodiment of the present disclosure, the cos. calculator 704 is configured to facilitate automatic cost calculation. The cos. calculator 704 requests for estimation of costs for each resource SKU with periods defined by the contract between the marketplace broker 128 and reseller 106. from ISV rating engine 702. It will be appreciated that the from cos. calculator 704 leads to alignment of costs streams to revenue periods that are essential for further revenue matching and settlement, as disclosed herein. For example, some billing periods of a contract between marketplace broker 128 and reseller 106 may be longer than billing periods from a contract between marketplace broker 128 and service vendors 102. In such an embodiment, the ISV rating engine 702 provides an estimation of costs for future billing periods, based on transaction metrics received via transaction mediator 132.
In at least one embodiment of the present disclosure, enterprise resource planning (ERP) system 706, is operably connected to the ISV rating engine 702, or the marketplace 122. The ERP system 706 is of a type well known to one having ordinary skill 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 collectively operable to perform the functions delegated to the ERP system 706 according to the present disclosure.
Referring now to
ISV catalog 802 is a service running on ISV contract catalog computing device 800. ISV catalog consists from several parts. Product catalog 804 stores information about available ISV services integrated with the cloud service broker marketplace system via connectors. It also contains a set of resources associated with services. Via price constructor tool 808 ISV can tune prices on services and resources usage. The price constructor tool 808 may contain a variety of price formation settings, e.g. dependencies from volume, period of use, special discounts for sonic type of clients, variety of arguments, on which price formula may depend, etc. ISV may use the variants of price settings, combine them and set its own price conditions, including a price condition in a form of mathematical formula. Price formation catalogue 806 stores price conditions set by ISV via the tool 808 or manually. ISV billing rules stores billing rules for services and associated resources. A variety of billing rules is depicted on the
In at least one embodiment of the present disclosure, ISV contract catalogue device 800 inherits the service provider billing rules and service plans database 124. In at least one embodiment of the present disclosure the ISV contract catalog device 800 and hierarchical partner contract catalogue 126 may be combined as a product catalogue (not shown). In at least one embodiment of the present disclosure, the product catalogue may include at least one database with products including vendors' services with prices (set by vendor, set for partner, resellers etc.).
Referring now to
In at least one embodiment of the present disclosure, the resource usage manager 914 is configured to support a pay-as-you-go model, and receives transactions with usage from the transaction mediator 132. In at least one embodiment of the present disclosure, the federated usage calculator 922 inherits the functionality of the federated connector 130, and is configured to calculate usage per SKU and reports the same to the marketplace computing device 122.
Referring now to
In at least one embodiment of the present disclosure, the ISV catalog 802 contains details about contracts between the marketplace broker 128 and the service vendor(s) 102. In particular, each contract between the marketplace broker 128 and the service vendor(s) 102 contains at least a set of applications, their descriptions, data about resources SKU, and resource identifiers (e.g. a service vendor number) associated with this application, subscription periods, price formation rules, currency, units of measure, billing rules for activation, cancellation, changes (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 rules setting, and a catalog with all possible price formation rules and price constructor tool with a user interface for a service vendor or other entity to set up price formation rules. It will be appreciated that the variety of price conditions are wide but preset. It will be further appreciated that at a minimum, a requirement is that these price formation rules must be resolved by the ISV rating engine 702 based on information contained in transactions from the transaction mediator 132 (i.e. the formula of price should be expressed in terms of variables reported by/to transaction mediator 132 or otherwise can be directly calculated based on them).
Continuing with method 1000, at step 1008, a check is made to see if the resource subscription associated with the received transaction exists. If it does, the method 1000 proceeds to step 1010; if it does not, the method 1000 proceeds to step 1038, where a check is made to see if the transaction is an “activation.”
At step 1010, the type of transaction is defined. In at least one embodiment of the present disclosure, an “activation” transaction is determined at step 1012 and is characterized by anniversary date with two attributes associated therewith: aligned (a), and unaligned (u), and three attributes associated with transaction activation: free, full, and prorated. If the transaction is indeed “activation,” the method 1000 proceeds to step 1058, where the transaction may be stored as ‘incorrect,’ because the contract already exists, as determined at step 1006. (Similarly, if the transaction is determined to be an “activation” as well, at step 1040, the method proceeds to step 1042; otherwise it proceeds to step 1036 where the transaction is stored as ‘inconsistent.’)
If the transaction is not an “activation,” the method 1000 proceeds to step 1014. At step 1014 it is determined whether the transaction is a “cancel.” In at least one embodiment of the present disclosure, a cancellation has three attributes associated therewith: free, full, prorated. If the transaction is not a cancellation, the method 1000 proceeds to step 1060.
If the transaction is a cancellation, the method 1000 proceeds to step 1016, where existing active resource subscriptions are identified, on the resource associated with the transaction. The method 1000 then proceeds to step 1018 where a service vendor 102 billing period is identified for the associated resource SKU. At step 1020, the ISV catalog 802 is queried to retrieve cancellation rules regarding the applicable contract with the service vendor(s) 102. At step 1022, a charge with a negative price is created, by resolving cancellation rules for the current billing period at step 1024, and then implementing the cancellation rules and calculating the negative price for cancellation at step 1026.
In at least one embodiment of the present disclosure, any estimation charges for further billing periods is determined at step 1028. If there are no such billing charges, the charges created from the preceding steps is stored at step 902. If there are charges to be stored, charges are created with negative prices for every estimation charge at step 1030, and prices are identified for estimation charges at step 1032. At step 1034, all created charges are stored and posted with the associated transaction.
Referring back to step 1040 of method 1000, if the transaction is an “activation,” the method 1000 proceeds to step 1042, as shown in
Referring back to step 1058 of method 1000, after the transaction is stored as “incorrect,” the method 1000 proceeds to step 1060, as shown in
In at least one embodiment of the present disclosure, existing active resource subscriptions on the resource associated with the transaction are identified, at step 1062. The type of change transaction is identified at 1064, and the service vendor(s) 102 billing period 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 about the change rules from the contract with the service vendor(s) 102. It will be appreciated that the ISV catalog 802 may also be 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 charge is created at step 1072 where change rules for the current billing period are resolved at 1080, and price and change rules are implemented at step 1082.
The method 1000 then proceeds to step 1090 where it is determined if there are any estimation charges for further billing periods. If no charges are to be stored, the method 1000 concludes at step 1092. Otherwise, charges with prices relevant to estimation charges associated with the resource for every estimation charge is created at step 1094. It will be further appreciated that the prices of estimation charges are identified at step 1096, and all created charges associated with the transaction are stored and posted at step 1098.
It will be appreciated that in CSB platform, a base price for resources is fixed and set by a contract between the service vendor 102 and marketplace broker 128. It will be further appreciated that there are several types of discounts: volume discount (with respect to subscriptions by units and where volume is a number of units; and with respect to pay-as-you-go subscriptions, volume is directly defined as a volume of purchased resource such as, memory, network bandwidth, and other computer resources to name a few non-liming examples). It will also be appreciated that discounts can be implemented based on the period of subscription renewals. For example, a first year discount may be 25%; a second year discount may be 35%, etc. The hierarchy of discounts may be set by the service vendor 102, and where discounts can be set as a percentage and as delta modification in money equivalent. It will be appreciated that discounts can be set as a combination of conditions.
In at least one embodiment of the present disclosure, late price calculation can be also set up. For example, if a subscriber during a year period purchases the amount of resource subscriptions above some threshold, a special discount can be implemented. For implementing late price calculations, transactions are stored and correction charges are issued, if some threshold for discount is being achieved. The ISV rating engine 702 receives transactions from transaction mediator 132 and after requesting contract details from the ISV catalog 802, implements price formation rules and billing rules for each resource SKU.
Referring now to
If the request does exist, the method 1100 proceeds to step 1108 where the end date of the requested estimation period is identified. At step 1110, the end date of the requested estimation period is compared with the nearest future billing date according to the associated contract with the applicable service vendor(s) 102.
In at least one embodiment of the present disclosure, the end date of the requested estimation period is checked to see if it is greater than the next billing date according to the associated contract with the applicable service vendor(s) 102, at step 1112. If it is not, the method 1100 proceeds to step 1120, as further disclosed herein.
Otherwise, the method 1100 proceeds to step 1114 where the ISV catalog 802 is queried about a set of price rules associated with the resource SKU for the billing period that is preferred, and the billing date following after the end date of the estimation period. At step 1116, charges are created for the billing date following the end date of the estimation period. At step 1118, the next billing date is assigned as a billing date following the billing date after the end of the estimation period. The method 1100 then concludes at step 1120 where the new charges are sent for the requested period and stored.
It will be appreciated that the ISV catalog 802 may contain rules for estimation. For example, if a service vendor (like Microsoft) has prepayment system, such a service vendor may set up rule that for the next billing period to calculate the average volume of consumed resources and prepare invoices according to such rules. It will be further appreciated that at the end of such a billing period the service vendor may send corrected invoices, where the ISV rating engine 702 may implement such corrections for estimation requests from cos. calculator 704.
Referring now to
The method 1200 begins at step 1202 where a check is made to see if an asynchronous task for recurring ratings is received. It will be appreciated that the task may also be synchronous. If such a task is not received, the method 1200 loops back to 1202.
If a task is received, the method 1200 proceeds to step 1204 where all active subscriptions are selected where the next bill dates for such active subscriptions are less than the current date. The method 1200 then proceeds to step 1206 where the selected subscriptions are grouped by resource SKU, and the task is executed for each group.
In at least one embodiment of the present disclosure, the ISV catalog 802 is queried about the set of price rules associated with each applicable resource SKU, at step 1208. At step 1210, a charge for the billing period is created followed by the current date. Price formation rules are resolved at step 1212, and the price is implemented at step 1214.
In at least one embodiment of the present disclosure, the next billing date is assigned as a billing date following after the current date, at step 1216. The method 1200 concludes at step 1218 where the charges for the requested period are sent and stored.
Referring now to
The method 1300 begins at step 1302 where the ISV rating engine 702 checks (periodically or continually) to see if it has received a price change notification from the ISV contract catalog 802. Upon receiving the notification, the method 1300 proceeds to step 1304 where affected subscriptions are selected, and charges are ordered. The method 1300 then proceeds to step 1306 where the selected subscriptions are grouped by resource SKU, and the task is executed for each group.
In at least one embodiment of the present disclosure, the ISV catalog 802 is queried about the set of price rules associated with each applicable resource SKU, at step 1308. At step 1310, any pending charges for affected subscriptions are revoked. The method 1300 then proceeds to step 1312 where a charge for the billing period is created. Price formation rules are resolved at step 1314, and the price is implemented at step 1316.
In at least one embodiment of the present disclosure, a refund charge may be created for ever affected ordered charge the previously overcharged, at step 1318. The method 1300 concludes at step 1320 where the charges for the affected period are sent and stored.
It will be appreciated that ISV rating engine 702 also receives updates from the ISV catalog 802 about price formation rules, which is bound to resources associated with the past transactions. It will be further appreciated that ISV rating engine 702 implements late price calculations and post correction charges in the end of the service vendor billing period related to conditions for late pricing. It will also be appreciated that all correction charges may be automatically reported to ERP system 706 with recurring cost reports as disclosed in method 12.
In at least one embodiment of the present disclosure, the cos. calculator 704 receives information about billing periods set up for contracts between marketplace broker 128 and reseller 106, by either: when marketplace broker 128 distributes cloud applications itself via the reseller chain, and where the CSB platform contains its own billing rules and all billing periods with which cost streams need to be matched; or, when the marketplace broker 128 has third-party partners and the partner platforms also contain their own billing. It will be appreciated that in such an embodiment, a marketplace computing device will include hierarchy participants' contract catalog with price and billing conditions for each partner. It will be further appreciated that the product catalog may be stored within the marketplace computing device, and preclude the need to store pricing information independently (i.e. at the hierarchy participants). In at least one embodiment of this disclosure, such a marketplace computing device has the same ISV rating engine for calculating revenue according to information received from the same transaction mediator 132 through the federated connector 130, for implementing price formation rules and billing rules from the partner contract catalog.
While the invention has been illustrated and described in detail in the drawings and foregoing description, the same is to be considered as illustrative and not restrictive in character, 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 invention are desired to be protected.
This utility patent application is a continuation-in-part of U.S. application Ser. No. 15/857,305, filed Dec. 28, 2017, which claims priority to U.S. Provisional Patent Application No. 62/439,619, filed Dec. 28, 2016, all of which applications are incorporated by reference herein.
| Number | Date | Country | |
|---|---|---|---|
| 62439619 | Dec 2016 | US |
| Number | Date | Country | |
|---|---|---|---|
| Parent | 15857305 | Dec 2017 | US |
| Child | 15954238 | US |
