Method and system for building and managing dynamic rate cards for cloud service subscription

Abstract

Embodiments described herein generally relate to systems and methods for providing access to software products or services in cloud computing or other computing environments. Dynamic rate card management allows an organization to optimize the number of rate cards to a manageable level, where, for example, the rate cards may be associated with the type of contract policy. In accordance with embodiments, in order to accommodate the use of a dynamic rate card, a migration service or processing may be used to translate / migrate subscriptions that are initially created from a first, legacy, or previous subscription pricing model, instead to conform to a subscription pricing service model for use with the various systems, methods, and features described herein.

Description

[0001] COPYRIGHT NOTICE

[0002] A portion of the disclosure of this patent document contains material which is subject to copyright protection. The copyright owner has no objection to the facsimile reproduction by anyone of the patent document or the patent disclosure, as it appears in the Patent and Trademark Office patent file or records, but otherwise reserves all copyright rights whatsoever.

[0003] CLAIM OF PRIORITY AND CROSS-REFERENCE TO RELATED APPLICATIONS:

[0004] This application claims priority to U.S. Provisional Patent Application No. 63 / 462,878, filed April 28, 2023, entitled “SYSTEM AND METHOD FOR PROVIDING DEDICATED CLOUD ENVIRONMENTS FOR USE WITH A CLOUD COMPUTING INFRASTRUCTURE”; U.S. Provisional Patent Application No. 63 / 462,868, filed April 28, 2023, entitled “SYSTEM AND METHOD FOR PROVIDING DEDICATED CLOUD ENVIRONMENTS FOR USE WITH A CLOUD COMPUTING INFRASTRUCTURE”; U.S. Provisional Patent Application No. 63 / 462,875, filed April 28, 2023, entitled “SYSTEM AND METHOD FOR PROVIDING DEDICATED CLOUD ENVIRONMENTS FOR USE WITH A CLOUD COMPUTING INFRASTRUCTURE”; U.S. Provisional Patent Application No. 63 / 462,880, filed April 28, 2023, entitled “SYSTEM AND METHOD FOR PROVIDING DEDICATED CLOUD ENVIRONMENTS FOR USE WITH A CLOUD COMPUTING INFRASTRUCTURE”; U.S. Provisional Patent Application No. 63 / 462,882, filed April 28, 2023, entitled “SYSTEM AND METHOD FOR PROVIDING DEDICATED CLOUD ENVIRONMENTS FOR USE WITH A CLOUD COMPUTING INFRASTRUCTURE”; U.S. Provisional Patent Application No. 63 / 462,885, filed April 28, 2023, entitled “SYSTEM AND METHOD FOR PROVIDING DEDICATED CLOUD ENVIRONMENTS FOR USE WITH A CLOUD COMPUTING INFRASTRUCTURE”;and priority to U.S. Patent Application No. 18 / 639,766, filed April 18, 2024, entitled “METHOD AND SYSTEM FOR BUILDING AND MANAGING DYNAMIC RATE CARDS FOR USE WITH CLOUD SERVICE SUBSCRIPTIONS,” the priority of each of the foregoing applications is hereby claimed, and the contents of each of the foregoing applications and priority are incorporated herein by reference. TECHNICAL FIELD

[0005] The embodiments described herein generally relate to systems and methods for providing a cloud environment for use by tenants of a cloud infrastructure environment in accessing software products, services, or other offerings associated with the cloud environment, including systems and methods for building and managing dynamic rate cards related to a tenant’s subscription to software products, services, or other offerings associated with the cloud environment. BACKGROUND

[0006] Cloud computing environments can be used to provide access to a range of complementary cloud-based components, such as software applications or services, which enable organization or enterprise customers to operate their applications and services in a highly available, hosted environment.

[0007] The benefits to organizations of moving their application and service needs to a cloud environment include reducing the cost and complexity of designing, building, operating, and maintaining their own on-premises data centers, software application frameworks, or other information technology infrastructures; allowing them to instead focus on managing their day-to-day business.

[0008] In some cloud environments, organizations can use rate cards as a mechanism for managing product inventory pricing to end users or customers of the organization. In essence, each customer’s subscription to a software application or service is associated with a rate card that sets the pricing for the cloud service platform services according to each customer subscription. Such rate cards used by organizations to manage their customers’ product inventory pricing are static, with the company defining the pricing according to each customer subscription. Whether the price of an individual product goes up or down, the rate card can be modified in order to provide the most up-to-date pricing to customers. Similarly, the rate card can be modified to individually reflect an increase or decrease in the price of an individual product.

[0009] The above-described approach essentially employs a 1 : 1 rate card to each customer subscription relationship. While a 1 : 1 rate card provides technical accuracy in managing the delivery of products and their pricing to end users or customers of an organization for subscription relationships, this approach can become very cumbersome in situations where there are a large number of software application and / or service offerings, and / or where an organization has a large number of end users or customers that subscribe to the software application and / or service offerings.

[0010] For example, in such a 1 : 1 rate card system, every price change can trigger the creation of a rate card version for every subscription that exists in the system. For example, for a cloud system with 1000 customers and 10000 products, the static rate card approach as described above would be required to maintain 100 million price points for 1000 rate cards. New product releases can require updates to all 1000 rate cards. Price changes when the price of a product goes up or down based on the terms of various cloud service usage contracts will also need to be updated.

[0011] Such rate card management, per customer per product, keeping the terms of the subscription contract in line with the offering and dynamically adjusting to price changes, is a complex process. Adding a currency dimension to the rate card makes the process even more complex for global organizations. SUMMARY

[0012] The embodiments described herein generally relate to systems and methods for providing access to software products or services in a cloud computing or other computing environment, and in particular to systems and methods for building and managing dynamic rate cards for subscription-based products, services, or other offerings.

[0013] According to embodiments, optimized dynamic rate card management allows organizations to provide dynamically customized pricing. The embodiments described herein generally optimize the number of rate cards to a manageable level, where, for example: rate cards can be associated with types of contract pricing policies; subscriptions can be associated with applicable rate cards based on contract pricing policies and contract dates; and rate cards can be created and updated in a just-in-time manner based on the latest changes in prices of products in the system.

[0014] According to embodiments, to accommodate the use of dynamic rate cards, a migration service or process can be used to convert / migrate subscriptions initially created under a legacy or previous subscription pricing model (SPM) to conform to a subscription pricing service (SPS) model for use with the various systems, methods, and features described herein. BRIEF DESCRIPTION OF DRAWINGS

[0015] Figure 1 FIGURE illustrates a system for providing a cloud infrastructure environment, according to an embodiment.

[0016] Figure 2 FIGURE further illustrates how a cloud-based application or service can be provided using the cloud infrastructure environment, according to an embodiment.

[0017] Figure 3 FIGURE illustrates an example cloud infrastructure architecture, according to an embodiment.

[0018] Figure 4 FIGURE illustrates another example of a cloud infrastructure architecture, according to embodiments.

[0019] Figure 5 FIGURE illustrates another example of a cloud infrastructure architecture, according to embodiments.

[0020] Figure 6 FIGURE illustrates another example of a cloud infrastructure architecture, according to embodiments.

[0021] Figure 7 FIGURE illustrates a system providing a dedicated or private labeled cloud environment used by a tenant or customer of a cloud infrastructure environment, according to embodiments.

[0022] Figure 8 FIGURE further illustrates use of a cloud field by a tenant or customer of a cloud infrastructure environment, according to embodiments.

[0023] Figure 9 FIGURE further illustrates use of a cloud field by a tenant or customer of a cloud infrastructure environment, according to embodiments.

[0024] Figure 10 FIGURE illustrates a system for providing access to a software product or service in a cloud computing or other computing environment, according to embodiments.

[0025] Figure 11 FIGURE illustrates providing access to a software product or service in a cloud computing environment using a subscription pricing service, according to embodiments.

[0026] Figure 12 FIGURE further illustrates providing access to a software product or service in a computing environment using a subscription pricing service, according to embodiments.

[0027] Figure 13 FIGURE illustrates example use of a managed dynamic rate card associated with a new subscription, according to embodiments.

[0028] Figure 14 FIGURE illustrates example use of a managed dynamic rate card associated with a price list addition, according to embodiments.

[0029] Figure 15 FIGURE illustrates a table of example subscription types and corresponding rate cards, according to embodiments.

[0030] Figure 16 FIGURE illustrates example use of dynamic rate cards applied to various subscription-based products, services or other offerings, according to embodiments.

[0031] Figure 17 is a flow diagram illustrating a method of using dynamic rate cards, according to embodiments.

[0032] Figure 18 FIG. 1 is a flow diagram illustrating a method of modifying an At List Price (ALP) rate card, according to an embodiment.

[0033] Figure 19 FIG. 2 is a flow diagram illustrating a method of modifying an At Contract Price (ACP) rate card, according to an embodiment.

[0034] Figure 20 FIG. 3 is a flow diagram illustrating a method of modifying ALP and ACP rate cards for added cloud computing services, according to an embodiment.

[0035] Figure 21 FIG. 4 is a flow diagram illustrating a method of handling a new subscription to a set of cloud computing services, according to an embodiment.

[0036] Figure 22 FIG. 5 is a flow diagram illustrating a method of using an operator realm as a proxy for subscription identification, according to an embodiment.

[0037] Figure 23 FIG. 6 is a flow diagram illustrating a method of handling a new subscription to a set of subscriptions associated with an ACP rate card, according to an embodiment.

[0038] Figure 24 FIG. 7 illustrates an example of a cloud infrastructure architecture providing migration of rate cards, according to an embodiment.

[0039] Figure 25 FIG. 8 is a flow diagram illustrating a method of migrating a legacy rate card to a cloud infrastructure environment, according to an embodiment.

[0040] Figure 26 FIG. 9 is a flow diagram illustrating a method of verifying a migrated legacy rate card, according to an embodiment.

[0041] Figure 27 FIG. 10 is a flow diagram illustrating a method of subscribing to a migration in the context of an operator realm, according to an embodiment. DETAILED DESCRIPTION

[0042] Cloud computing or cloud infrastructure environments can be used to provide access to a collection of interconnected, cloud-based components such as software applications or services, which enables organization or enterprise customers to operate their applications and services in a highly available managed environment.

[0043] The benefits to organizations moving their application and service requirements to a cloud infrastructure environment include reducing the cost and complexity of designing, building, operating, and maintaining their own on-premise data centers, software application frameworks, or other information technology infrastructures; allowing them to instead focus on managing their day-to-day business.

[0044] cloud infrastructure environment

[0045] Figure 1 and Figure 2 The illustration depicts a system for providing a cloud infrastructure environment according to an embodiment.

[0046] According to an embodiment, Figure 1 The components and processes shown herein, as well as those further described herein with respect to various embodiments, may be provided as software or program code executable by a computer system or other type of processing device (e.g., a cloud computing system).

[0047] The illustrated examples are provided to illustrate computing environments that can be used to provide dedicated or privately tagged cloud environments for tenants of cloud infrastructure to use when accessing subscription-based software products, services, or other provisioning items associated with the cloud infrastructure environment. According to other embodiments, the various components, processes, and features described herein can be used with other types of cloud computing environments.

[0048] like Figure 1 As shown, according to an embodiment, cloud infrastructure environment 100 can operate on cloud computing infrastructure 102, which includes hardware (e.g., processor, memory), software resources, and one or more cloud interfaces 104 or other application programming interfaces (APIs) that provide access to shared cloud resources via one or more load balancers 106.

[0049] According to the embodiment, the cloud infrastructure environment supports the use of availability domains, such as availability domains A 180 and B 182, which enables customers to create and access cloud networks 184 and 186, and run cloud instances A 192 and B 194.

[0050] According to an embodiment, a tenancy can be created for each cloud tenant / customer (e.g., tenants A 142 and B 144), which provides a secure and isolated partition within the cloud infrastructure environment where the customer can create, organize, and manage their cloud resources. Cloud tenants / customers can access availability domains and cloud networks to access each of their cloud instances.

[0051] According to an embodiment, a client device (such as a computing device 160 having device hardware 162 (e.g., a processor, memory) and a graphical user interface 166) can enable administrators or other users to communicate with the cloud infrastructure environment via a network (such as a wide area network, local area network, or the Internet) to create or update cloud services.

[0052] According to embodiments, the cloud infrastructure environment provides access to shared cloud resources 140 via, for example, a computing resource layer 150, a network resource layer 164, and / or a storage resource layer 170. A customer can launch cloud instances as needed to satisfy computing and application demands. After a customer provisions and launches a cloud instance, the provisioned cloud instance can be accessed from, for example, a client device.

[0053] According to embodiments, the computing resource layer can include resources such as, for example, bare metal cloud instances 152, virtual machines 154, graphics processing unit (GPU) compute cloud instances 156, and / or containers 158. The computing resource layer can be used, for example, to provision and manage bare metal compute cloud instances, or provision cloud instances as needed to deploy and run applications as if in an on-premise data center.

[0054] For example, according to embodiments, the cloud infrastructure environment can provide control of physical host (bare metal) machines within the computing resource layer that run as compute cloud instances directly on bare metal servers without a hypervisor.

[0055] According to embodiments, the cloud infrastructure environment can also provide control of virtual machines within the computing resource layer that can be launched, for example, from an image, where the type and amount of resources available to the virtual machine cloud instance can be determined, for example, based on the image from which the virtual machine is launched.

[0056] According to embodiments, the network resource layer can include a plurality of network-related resources such as, for example, virtual cloud networks (VCNs) 165, load balancers 167, edge services 168, and / or connection services 169.

[0057] According to embodiments, the storage resource layer can include a plurality of resources such as, for example, data / block volumes 172, file storage 174, object storage 176, and / or local storage 178.

[0058] As Figure 2 As shown in FIG. 1C, according to embodiments, the cloud infrastructure environment can include a series of complementary cloud-based components, for example, as cloud infrastructure application and services 200, which enable an organization or enterprise customer to operate their applications and services in a highly available, managed environment.

[0059] For example, according to embodiments, a self-contained cloud region can be provided within an organization’s data center as a complete, for example, Oracle Cloud Infrastructure (OCI) dedicated region, which can offer the flexibility, scalability, and economics of a public cloud to the data center operator, while retaining full control over their data and applications to satisfy security, regulatory, or data residency requirements.

[0060] For example, such an environment can include, according to an embodiment, racks physically managed by the cloud infrastructure provider; racks of the customer; access rights for cloud operators to set up and hardware support; customer data center power and cooling; customer floor space; customer data center personnel’s locale; and physical access cages.

[0061] According to an embodiment, the dedicated region provisions the same set of Infrastructure as a Service (IaaS), Platform as a Service (PaaS), and Software as a Service (SaaS) products or services available in the public cloud region of the cloud infrastructure provider, such as, for example, ERP, Financials, HCM, and SCM. The customer can seamlessly lift and shift legacy workloads using the cloud infrastructure provider’s services (e.g., bare metal compute, VMs, and GPUs; database services, such as autonomous databases; or container-based services, such as container engines for Kubernetes).

[0062] According to an embodiment, the cloud infrastructure environment can operate according to an Infrastructure as a Service (IaaS) model that enables the environment to provide virtualized computing resources over a public network, such as the Internet.

[0063] In an IaaS model, a cloud infrastructure provider can host infrastructure components (e.g., servers, storage devices, network nodes (e.g., hardware), deployment software, platform virtualization (e.g., hypervisor layer), etc.). In some cases, the cloud infrastructure provider can also provision various services to work with these infrastructure components (example services include billing software, monitoring software, logging software, load balancing software, or clustering software). Thus, because these services can be policy driven, an IaaS user can be able to implement policies for driving load balancing, thereby maintaining availability and performance of applications.

[0064] According to an embodiment, an IaaS customer can access resources and services over a wide area network (WAN), such as the Internet, and can use the cloud infrastructure provider’s services to install the remaining elements of an application stack. For example, a user can log into an IaaS platform to create virtual machines (VMs), install an operating system (OS) on each VM, deploy middleware such as a database, create storage buckets for workloads and backups, and even install enterprise software into the VMs. The customer can then use the provider’s services to perform various functions, including balancing network traffic, troubleshooting applications, monitoring performance, or managing disaster recovery.

[0065] According to an embodiment, a cloud infrastructure provider can, but need not necessarily be, a third party service that specializes in providing (e.g., provisioning, renting, selling) IaaS. An entity can also choose to deploy a private cloud, thereby becoming its own infrastructure service provider.

[0066] According to an embodiment, IaaS deployment is the process of placing a new application or a new version of an application onto a prepared application server, etc. It can also include the process of preparing a server (e.g., installing libraries or daemons). This is typically managed by the cloud infrastructure provider, below the virtual machine manager layer (e.g., servers, storage, network hardware, and virtualization). Thus, the customer can be responsible for handling (OS), middleware, and / or application deployment (e.g., onto self-service virtual machines, which can be launched on-demand, etc.).

[0067] According to an embodiment, IaaS provisioning can refer to getting computers or virtual hosts for use, even installing the required libraries or services on them. In most cases, deployment does not include provisioning, and provisioning can need to be performed first.

[0068] According to an embodiment, challenges of IaaS provisioning include the initial challenge of provisioning a set of initial infrastructure before anything is running. Secondly, once everything has been provisioned, there is the challenge of evolving the existing infrastructure (e.g., adding new services, changing services, or removing services). In some cases, both challenges can be addressed by enabling a configuration that defines the infrastructure in a declarative manner. In other words, the infrastructure (e.g., what components are needed and how they interact) can be defined by one or more configuration files. Thus, the overall topology of the infrastructure (e.g., what resources depend on which resources, and how they each work together) can be described in a declarative manner. In some cases, once the topology is defined, a workflow that creates and / or manages the different components described in the configuration file can be generated.

[0069] According to an embodiment, a cloud infrastructure can have many interconnected elements. For example, there can be one or more virtual private clouds (VPCs) (e.g., a potential on-demand pool of configurable and / or shared computing resources), also referred to as a core network. In some examples, one or more ingress / egress traffic group rules can also be provisioned to define how ingress / egress traffic for the network will be set up, as well as one or more virtual machines (VMs). Other infrastructure elements can also be provisioned, such as load balancers, databases, etc. As more and more infrastructure elements are desired and / or added, the infrastructure can evolve step by step.

[0070] According to embodiments, continuous deployment techniques can be employed to enable deployment of infrastructure code across various virtual computing environments. Moreover, the described techniques can enable infrastructure management within these environments. In some examples, a service team can write code that is expected to be deployed to one or more, but typically many, different production environments (e.g., across various different geographic locations). However, in some examples, the infrastructure on which the code is to be deployed must first be set up. In some cases, provisioning can be done manually, resources can be provisioned with a provisioning tool, and / or once the infrastructure is provisioned, the code can be deployed with a deployment tool.

[0071] Figure 3 FIGURE 1 illustrates an example cloud infrastructure architecture, according to an embodiment.

[0072] As Figure 3 As shown in the middle, according to embodiments, the service operator 202 can be communicatively coupled to a secure host tenancy 204, which can include a virtual cloud network (VCN) 206 and a secure host subnet 208.

[0073] In some examples, the service operator can use one or more client computing devices, which can be portable handheld devices (e.g., cell phones, computing tablets, personal digital assistants (PDAs)) or wearable devices (e.g., head mounted displays), running software such as Microsoft Windows® and / or various mobile operating systems (such as iOS, Android, etc.), and supporting Internet, e-mail, Short Message Service (SMS), or other communications protocols. Alternatively, the client computing devices can be general purpose personal computers including, by way of example, personal computers and / or laptop computers running various versions of Microsoft Windows®, Apple Macintosh®, and / or Linux operating systems. The client computing devices can be workstation computers running any of a variety of commercially-available UNIX® or UNIX-like operating systems, including, without limitation, the variety of GNU / Linux operating systems

[0074] According to embodiments, a VCN can include a local peering gateway (LPG) 210 that can be communicatively coupled to an SSH VCN 212 via an LPG contained in the SSH VCN. The SSH VCN can include an SSH subnet 214, and the SSH VCN can be communicatively coupled to a control plane VCN 216 via an LPG contained in the control plane VCN. Further, the SSH VCN can be communicatively coupled to a data plane VCN 218 via an LPG. The control plane VCN and the data plane VCN can be contained in a service tenancy 219 that can be owned and / or operated by a cloud infrastructure provider.

[0075] According to embodiments, a control plane VCN can include a control plane demilitarized zone (DMZ) tier 220 that acts as a perimeter network (e.g., a portion of an enterprise network between an enterprise intranet and an external network). DMZ-based servers can have limited responsibilities to help contain potential breaches. Further, the DMZ tier can include one or more load balancer (LB) subnets 222, a control plane application tier 224 that can include application subnet(s) 226, and a control plane data tier 228 that can include database (DB) subnet(s) 230 (e.g., front-end DB subnet(s) and / or back-end DB subnet(s)). The LB subnet(s) contained in the control plane DMZ tier can be communicatively coupled to the application subnet(s) contained in the control plane application tier and an internet gateway 234 that can be contained in the control plane VCN, and the application subnet(s) can be communicatively coupled to the DB subnet(s) contained in the control plane data tier and a service gateway 236 and a network address translation (NAT) gateway 238. The control plane VCN can include the service gateway and the NAT gateway.

[0076] According to embodiments, a control plane VCN can include a data plane mirror application tier 240 that can include application subnet(s). The application subnet(s) contained in the data plane mirror application tier can include virtual network interface controllers (VNICs) that can execute compute instances. The compute instances can communicatively couple the application subnet(s) of the data plane mirror application tier to application subnet(s) that can be contained in a data plane application tier.

[0077] According to an embodiment, the data plane VCN can include a data plane app tier 246, a data plane DMZ tier 248, and a data plane data tier 250. The data plane DMZ tier can include LB subnet(s) that can be communicatively coupled to app subnet(s) of the data plane app tier and an internet gateway of the data plane VCN. The app subnet(s) can be communicatively coupled to a service gateway of the data plane VCN and a NAT gateway of the data plane VCN. The data plane data tier can also include DB subnet(s) that can be communicatively coupled to app subnet(s) of the data plane app tier.

[0078] According to an embodiment, the internet gateway of the control plane VCN and the data plane VCN can be communicatively coupled to a metadata management service 252 that can be communicatively coupled to a public internet 254. The public internet can be communicatively coupled to the NAT gateway of the control plane VCN and the data plane VCN. The service gateway of the control plane VCN and the data plane VCN can be communicatively coupled to cloud services 256.

[0079] According to an embodiment, the service gateway of the control plane VCN or the data plane VCN can make application programming interface (API) calls to cloud services without traversing the public internet. The API calls from the service gateway to the cloud services can be unidirectional: the service gateway can make API calls to the cloud services, and the cloud services can send requested data to the service gateway. Generally, the cloud services can not initiate API calls to the service gateway.

[0080] According to an embodiment, the secure host tenancy can be directly connected to a service tenancy that can otherwise be isolated. The secure host subnet can communicate with the SSH subnet through an LPG that can enable bidirectional communication on otherwise isolated systems. Connecting the secure host subnet to the SSH subnet can enable the secure host subnet to access other entities within the service tenancy.

[0081] According to an embodiment, the control plane VCN can allow users of the service tenancy to stand up or otherwise provision desired resources. The desired resources provisioned in the control plane VCN can be deployed or otherwise used in the data plane VCN. In some examples, the control plane VCN can be isolated from the data plane VCN, and a data plane mirror app tier of the control plane VCN can communicate with a data plane app tier of the data plane VCN via VNICs that can be contained in the data plane mirror app tier and the data plane app tier.

[0082] According to an embodiment, a user or customer of the system can make a request, such as a create, read, update, or delete (CRUD) operation, through the public internet that can communicate the request to the metadata management service. The metadata management service can communicate the request to the control plane VCN through the internet gateway. The request can be received by the LB subnet(s) contained in the control plane DMZ tier. The LB subnet(s) can determine that the request is valid, and in response to the determination, the LB subnet(s) can transmit the request to the application subnet(s) contained in the control plane application tier. If the request is verified and a call to the public internet is required, a call to the internet can be transmitted to the NAT gateway that can make the call to the internet. Metadata that the request is to store can be stored in the DB subnet(s).

[0083] According to an embodiment, the data plane mirror application tier can facilitate direct communication between the control plane VCN and the data plane VCN. For example, it can be desirable to apply changes, updates, or other appropriate modifications to the configuration to resources contained in the data plane VCN. With the aid of the VNICs, the control plane VCN can directly communicate with the resources contained in the data plane VCN, and thus can perform changes, updates, or other appropriate modifications to the configuration of these resources.

[0084] According to an embodiment, the control plane VCN and the data plane VCN can be contained in a service tenancy. In this case, a user or customer of the system can not own or operate the control plane VCN or the data plane VCN. Instead, the cloud infrastructure provider can own or operate the control plane VCN and the data plane VCN, both of which can be contained in a service tenancy. This embodiment can enable isolation of the network, which can prevent a user or customer from interacting with resources of other users or other customers. Furthermore, this embodiment can allow a user or customer of the system to privately store databases without having to rely on the public internet for storage, which can not provide a desired level of threat protection.

[0085] According to an embodiment, the LB subnet(s) contained in the control plane VCN can be configured to receive signals from the service gateway. In this embodiment, the control plane VCN and the data plane VCN can be configured to be called by a customer of the cloud infrastructure provider without having to call the public internet. This embodiment can be desirable for a customer of the cloud infrastructure provider because the database(s) used by the customer can be controlled by the cloud infrastructure provider and can be stored on a service tenancy that can be isolated from the public internet.

[0086] Figure 4 FIGURE 1 illustrates another example of a cloud infrastructure architecture, according to an embodiment.

[0087] As Figure 4 shown in FIG. 21, according to an embodiment, a data plane VCN can be contained in a customer tenancy 221. In this case, a cloud infrastructure provider can provide a control plane VCN for each customer, and the cloud infrastructure provider can provision a unique compute instance contained in a service tenancy for each customer. Each compute instance can allow communication between the control plane VCN contained in the service tenancy and the data plane VCN contained in the customer tenancy. The compute instance can allow resources provisioned in the control plane VCN contained in the service tenancy to be deployed or otherwise used in the data plane VCN contained in the customer tenancy.

[0088] According to an embodiment, a customer of a cloud infrastructure provider can have a database managed and operated within a customer tenancy. In this example, a control plane VCN can include a data plane mirror application tier, which can include application subnet(s). The data plane mirror application tier can reside in the data plane VCN, but the data plane mirror application tier can not be provisioned in the data plane VCN. That is, the data plane mirror application tier can have access to the customer tenancy, but the data plane mirror application tier can not exist in the data plane VCN or be owned or operated by the customer. The data plane mirror application tier can be configured to make calls to the data plane VCN, but can not be configured to make calls to any entity contained in the control plane VCN. The customer can desire to deploy or otherwise use resources provisioned in the control plane VCN in the data plane VCN, and the data plane mirror application tier can facilitate the customer’s desired deployment or other use of the resources.

[0089] According to an embodiment, a customer of a cloud infrastructure provider can apply filters to a data plane VCN. In this embodiment, the customer can determine what the data plane VCN can access, and can limit access from the data plane VCN to the public internet. The cloud infrastructure provider can not be able to apply filters or otherwise control access of the data plane VCN to any external network or database. The customer applying filters and controls to the data plane VCN contained in the customer tenancy can help isolate the data plane VCN from other customers and the public internet.

[0090] According to embodiments, cloud services can be invoked by the service gateway to access services that can not exist on the public internet, control plane VCN, or data plane VCN. Connections between cloud services and control plane VCNs or data plane VCNs can not be continuous. Cloud services can exist on different networks owned or operated by a cloud infrastructure provider. Cloud services can be configured to receive invocations from the service gateway and can be configured to not receive invocations from the public internet. Some cloud services can be isolated from other cloud services, and control plane VCNs can be isolated from cloud services that can not be in the same region as the control plane VCN.

[0091] For example, according to embodiments, a control plane VCN can be located in “Region 1,” and a cloud service “Deployment 1” can be located in Region 1 and “Region 2.” If a service gateway contained in the control plane VCN located in Region 1 makes an invocation to Deployment 1, the invocation can be transmitted to Deployment 1 in Region 1. In this example, Deployment 1 in the control plane VCN or Region 1 can not be communicatively coupled or otherwise in communication with Deployment 1 in Region 2.

[0092] Figure 5 FIGURE 1 illustrates another example of a cloud infrastructure architecture, according to embodiments.

[0093] As Figure 5 According to embodiments, the trusted application subnet(s) 260 can be communicatively coupled to the service gateway contained in the data plane VCN, the NAT gateway contained in the data plane VCN, and the DB subnet(s) contained in the data plane data tier, as shown in FIGURE 2. The untrusted application subnet(s) 264 can be communicatively coupled to the service gateway contained in the data plane VCN and the DB subnet(s) contained in the data plane data tier. The data plane data tier can include DB subnet(s) that can be communicatively coupled to the service gateway contained in the data plane VCN.

[0094] According to embodiments, the untrusted application subnet(s) can include one or more primary VNICs (1)-(N) that can be communicatively coupled to tenant virtual machines (VMs). Each tenant VM can be communicatively coupled to a respective application subnet 267(1)-(N) that can be contained in a respective container egress VCN 268(1)-(N) that can be contained in a respective customer tenancy 270(1)-(N). Respective secondary VNICs can facilitate communication between the untrusted application subnet(s) contained in the data plane VCN and the application subnets contained in the container egress VCNs. Each container egress VCN can include a NAT gateway that can be communicatively coupled to the public internet.

[0095] According to an embodiment, the public Internet can be communicatively coupled to a NAT gateway contained in the control plane VCN and contained in the data plane VCN. A service gateway contained in the control plane VCN and contained in the data plane VCN can be communicatively coupled to cloud services.

[0096] According to an embodiment, the data plane VCN can be integrated with customer tenancies. This integration can be useful or desirable for customers of the cloud infrastructure provider in situations where additional support can be needed when executing code. For example, a customer can provide code to be run that can be potentially destructive, can communicate with other customer resources, or can otherwise cause undesirable effects.

[0097] According to an embodiment, a customer of the cloud infrastructure provider can grant temporary network access to the cloud infrastructure provider and request functionality to be attached to the data plane application tier. Code to run the functionality can be executed in a VM, and the code can not be configured to run anywhere else on the data plane VCN. Each VM can be connected to one customer tenancy. Respective containers (1)-(N) contained in the VM can be configured to run the code. In this case, there can be double isolation (e.g., the containers run the code, where the containers can be contained in the VM contained in the untrusted application subnet(s)), which can help prevent incorrect or otherwise undesirable code from damaging the network of the cloud infrastructure provider or damaging the network of a different customer. The containers can be communicatively coupled to the customer tenancy and can be configured to transmit or receive data from the customer tenancy. The containers can not be configured to transmit or receive data with any other entity in the data plane VCN. Upon completion of running the code, the cloud infrastructure provider can dispose of the containers.

[0098] According to an embodiment, the trusted application subnet(s) can run code that can be owned or operated by the cloud infrastructure provider. In this embodiment, the trusted application subnet(s) can be communicatively coupled to the DB subnet(s) and configured to perform CRUD operations in the DB subnet(s). The untrusted application subnet(s) can be communicatively coupled to the DB subnet(s) and configured to perform read operations in the DB subnet(s). Containers that can be contained in a VM of each customer and that can run code from the customer can not be communicatively coupled to the DB subnet(s).

[0099] According to embodiments, the control plane VCN and the data plane VCN can not be directly communicatively coupled; or there can be no direct communication between the control plane VCN and the data plane VCN. However, communication can occur indirectly, where the cloud infrastructure provider can establish an LPG, which can facilitate communication between the control plane VCN and the data plane VCN. In another example, the control plane VCN or the data plane VCN can make calls to cloud services via a service gateway. For example, a call to a cloud service from the control plane VCN can include a request to a service that can communicate with the data plane VCN.

[0100] Figure 6 FIGURE 13 illustrates another example of a cloud infrastructure architecture, according to embodiments.

[0101] As Figure 6 According to embodiments, the trusted application subnet(s) can be communicatively coupled to a service gateway contained in the data plane VCN, a NAT gateway contained in the data plane VCN, and the DB subnet(s) contained in the data plane data tier, as shown in FIGURE 11. The untrusted application subnet(s) can be communicatively coupled to the service gateway contained in the data plane VCN and the DB subnet(s) contained in the data plane data tier. The data plane data tier can include the DB subnet(s) that can be communicatively coupled to the service gateway contained in the data plane VCN.

[0102] According to embodiments, the untrusted application subnet(s) can include primary VNICs that can be communicatively coupled to tenant virtual machines (VMs) that reside within the untrusted application subnet(s). Each tenant VM can run code in a respective container, and can be communicatively coupled to an application subnet that can be contained in the data plane application tier 281, which can be contained in the container egress VCN 280. Respective secondary VNICs 282(1)- (N) can facilitate communication between the untrusted application subnet(s) contained in the data plane VCN and the application subnet contained in the container egress VCN. The container egress VCN can include a NAT gateway that can be communicatively coupled to the public Internet.

[0103] According to embodiments, the internet gateway contained in the control plane VCN and contained in the data plane VCN can be communicatively coupled to a metadata management service, which can be communicatively coupled to the public Internet. The public Internet can be communicatively coupled to the NAT gateway contained in the control plane VCN and contained in the data plane VCN. The service gateway contained in the control plane VCN and contained in the data plane VCN can be communicatively coupled to cloud services.

[0104] According to embodiments,Figure 6 The pattern shown can be regarded as Figure 5 Exceptions to the pattern illustrated, and patterns that customers might expect if the cloud infrastructure provider cannot communicate directly with the customer (e.g., in a disconnected region). Customers have live access to the corresponding containers contained within each customer's VM. Containers can be configured to invoke appropriate secondary VNICs contained in one or more application subnets within the data plane application layer, which may be contained in the container's egress VCN. The secondary VNICs can then route the calls to a NAT gateway, which can then route the calls to the public internet. In this example, the containers that customers can access live can be isolated from the control plane VCN, and can also be isolated from other entities contained within the data plane VCN. Containers can also be isolated from resources from other customers.

[0105] In other examples, customers can use containers to invoke cloud services. In this example, a customer can run code within a container that requests a service from the cloud service. The container can then forward the request to a secondary VNIC, which in turn forwards it to a NAT gateway, which in turn forwards it to the public internet. The public internet can then be used to forward the request via an internet gateway to one or more load balancer (LB) subnets contained within the control plane VCN. In response to determining that the request is valid, the LB subnets can forward the request to one or more application subnets, which in turn forward the request to the cloud service via a service gateway.

[0106] It should be recognized that the IaaS architecture depicted in the figures above may have components other than those depicted. Furthermore, the embodiments shown in the figures are merely some examples of cloud infrastructure systems that can be combined with embodiments of this disclosure. In some other embodiments, the IaaS system may have more or fewer components than shown in the figures, may combine two or more components, or may have different component configurations or arrangements.

[0107] In some embodiments, the IaaS system described herein may include a suite of application, middleware, and database service providers delivered to customers in a self-service, subscription-based, elastically scalable, reliable, highly available, and secure manner.

[0108] cloud environment

[0109] According to an embodiment, a cloud infrastructure environment can be used to provide a dedicated cloud environment, such as one or more privately tagged cloud environments, for tenants of the cloud infrastructure environment to use when accessing subscription-based software products, services, or other provisioning items associated with the cloud infrastructure environment.

[0110] Figure 7 The illustration shows how a system according to an embodiment can provide a dedicated or private tagged cloud environment for use by tenants or customers of a cloud infrastructure environment.

[0111] While the examples described herein illustrate various systems, methods, and / or technologies that can be used in the context of providing a private tag cloud (PLC) environment, the systems, methods, and technologies described herein can be used within or with other types of cloud environments, depending on the various embodiments.

[0112] like Figure 7 As shown, according to an embodiment, a cloud infrastructure provider may supply one or more cloud environments (e.g., PLC environments) or domains to an operator 320 (e.g., a cloud infrastructure customer operating as a reseller). The operator / reseller may then customize and extend the cloud environment for use by its customer 330 to access subscription-based software products, services, or other offerings associated with the cloud infrastructure environment.

[0113] For illustrative purposes, examples of such subscription-based products, services, or other offerings may include a variety of cloud infrastructure software products, such as Oracle Fusion Applications, or other types of products or services that allow customers to subscribe to use these products or services.

[0114] Figure 8 The illustration further illustrates the use of the cloud domain by tenants or customers in a cloud infrastructure environment according to an embodiment.

[0115] like Figure 8 As shown, according to an embodiment, the system may include a cloud subscription service or component, referred to herein as a subscription manager in some embodiments, which exposes one or more subscription management APIs for creating orders for joining new customers or initiating a workflow that may create subscriptions and coordinate billing and pricing services or other components for cloud domain 400.

[0116] According to an embodiment, when an operator (e.g., a PLC operator) or its customers request a cloud environment, the system creates domains for use within regions 402 and 404; and leases 416 owned by one or more providers. These leases allow the domains to operate using their required service infrastructure and to be managed by the cloud infrastructure provider.

[0117] According to embodiments, the first step in the process is to create an operator tenancy 406 for the operator, and then hand over the region and associated domains to the operator for subsequent management. The operator then becomes the administrator of that tenancy, and they can view and manage everything that happens within that region, including their customer accounts and the use of cloud resources 412 by those customers, within that tenancy.

[0118] In general, once a region is handed over or provisioned to an operator, the cloud infrastructure provider cannot subsequently access data within the operator tenancy unless the operator authorizes the cloud infrastructure provider to do so, for example to troubleshoot problems that can arise.

[0119] According to embodiments, the operator can then create additional internal tenancies 408 intended for its own internal use, for example for evaluating end user or customer experiences, or providing a sales demo tenancy, or operating a database for its own internal use. The operator can also create one or more customer tenancies 410, for which end users or customers will serve as administrators. The use of cloud infrastructure (e.g., compute, storage, and other infrastructure resources) is consolidated by the operator, reflecting its own and its customers’ use, and reported to the cloud infrastructure provider.

[0120] According to embodiments, a user interface or console can be provided that allows the operator to manage its customer accounts and services provisioned to customers. The cloud infrastructure provider can also use the cloud infrastructure tenancy (e.g., a Fusion Applications tenancy) to install any required infrastructure services for use by the operator and its customers.

[0121] Figure 9 Further illustrated is the use of cloud domains by tenants or customers of a cloud infrastructure environment, according to embodiments.

[0122] As Figure 9 According to embodiments, the subscription manager 424 service or component exposes one or more subscription management APIs for creating orders for onboarding new customers, or for initiating workflows that create subscriptions and coordinate billing and pricing services or other components, as shown in FIG. 4B.

[0123] According to embodiments, the system can also include a billing service 428 or component that operates on logical containers of billing accounts or subscriptions and preferences for generating invoices for customers.

[0124] According to embodiments, the system can also include a subscription pricing service (SPS) 426 or component that operates according to a product catalog that defines what products a customer can purchase, and a price list (e.g., a rate card) that can be used for provisioning, the pricing service also owning that price list.

[0125] According to embodiments, to support the sales process through which subscriptions are created in the domains 420 and 422, a product can be selected from a product hub. Once an order is created via the subscription service 430, a subscription is created in the subscription manager, which thereafter manages the life cycle of the subscription and supplies what is needed in downstream services. The SPS component then manages the pricing and usage aspects for the ability to charge the operator ultimately or for the operator to charge its customers. Usage events are forwarded to the billing service or component, where invoices are created and pushed to the accounts receivable component depending on the billing preferences of the subscription.

[0126] According to embodiments, while the services provisioned in the domains report their usage to the metering service or component 432, such usage does not have any price associated with it. The rate processing determines, for example by applying a rate card, what the cost of each particular event is, determines the units and cost for that subscription, associates the cost with that record, and then forwards it to the billing service or component.

[0127] As further shown in Figure 9 As further shown in

[0128] The examples of the various systems shown above are intended to illustrate that a dedicated or private tag cloud environment can be provided for use by tenants of a cloud infrastructure in accessing subscription-based software products, services, or other offerings associated with a cloud infrastructure environment. According to other embodiments, the various components, processes, and features described herein can be used with other types of cloud computing environments.

[0129] Cloud Subscriptions

[0130] Figure 10 FIGURE illustrates a system for providing access to software products or services in a cloud computing or other computing environment, according to embodiments.

[0131] As further shown in Figure 10 As further shown in

[0132] Examples of such subscription-based products, services, or other offerings can include various cloud infrastructure software products or services that allow customers to subscribe to usage.

[0133] According to embodiments, the environment can include a number of components provided as operator singleton 438, domain singleton 439, and regional services 440, as further described below.

[0134] According to embodiments, a subscription can include artifacts such as, for example, products, commitments, billing models, and status. A subscription manager service or component can expose one or more subscription management APIs for creating orders for onboarding new customers, or for initiating workflows that create subscriptions and coordinate the creation of appropriate footprints in billing and pricing services or components, as further described below.

[0135] According to embodiments, a billing service or component operates based on a logical container of billing accounts or subscriptions and preferences for generating invoices. Each billing account generates one invoice per billing period. The billing service includes a first pipeline that accepts usage and costs from a metering service or component through a REST API, where billing writes the usage to a database from which a billing worker aggregates and computes balances; and a second pipeline that is responsible for fetching aggregated usage and commitments, and computing the charges for the billing interval.

[0136] According to embodiments, a subscription pricing service (SPS) 426 or component operates based on a product catalog that defines which products customers can purchase. The product catalog forms the backbone of a price list (i.e., rate card) that the pricing service also owns. The rate card is modeled as a public list of prices with pricing rules on top of it. The pricing service maintains a single price list for all products, can add new product prices, and can change existing prices. The price list has a complete history, with the latest version being the current rate card. Since some contracts can require taking a snapshot of the rate card, the pricing service handles this by recording the time at which a customer's rate card was created, and then querying the price list for that time.

[0137] According to embodiments, the SPS or pricing service is responsible for communicating with a product and pricing hub 421 to provide information about products, global price lists, and specific price lists and discounts for end user or customer subscriptions. For example, according to embodiments, the SPS can synchronize product information from the product hub, and global price lists from the pricing hub.

[0138] According to embodiments, the subscription manager service or component operates as an upstream service to receive new order requests from the order management 423 component (e.g., from an Oracle Fusion Order Management environment). The subscription manager service or component can provide subscription information, including subscription details such as offer configuration time or subscription type (commit, PayG), to the SPS service to help the SPS determine the valid base price (rate card) for the subscription. The subscription manager service or component can also send subscription discounts received from the order management component, which the SPS stores as pricing rules entities.

[0139] According to embodiments, the SPS service runs as a background process to manage a rate card service or component that is responsible for generating rate cards for new subscriptions and updating these rate cards when new changes in prices occur. The SPS service can provide APIs to access rate cards and pricing rules. The metering inline rate engine can utilize these APIs to obtain the rate cards and pricing rules specific to a subscription and then use this data for cost calculations.

[0140] According to embodiments, additional SPS components can include, for example, a pricing / product hub integration component that allows the operator entity managing the subscription-based products, services, or other offerings within the environment to provide their product and price lists, for example, provided by the product hub and pricing hub, respectively.

[0141] For example, according to such embodiments, the SPS product integration process can listen to create / update events in the product hub and make calls to the SPS product APIs. Similarly, the SPS pricing integration process can pull new price list creations from the pricing hub and make calls to the corresponding SPS pricing APIs.

[0142] According to embodiments, the system can also include an SPS core module that provides APIs for managing and accessing pricing entities. The pricing entities can be accessed by internal services (e.g., the inline rate engine).

[0143] According to embodiments, the system can also include a rate card manager component. The SPS service maintains the single base price of a product at a given time. However, the product price of a subscription depends on the base price of the offer configuration time and the price list change policy attribute of the subscription. The SPS service uses these properties to internally maintain the price to be used for a subscription. All these price lists are grouped in rate cards. The rate card manager can create and maintain rate cards, listen to price list changes and update existing rate cards with new prices, and listen to new subscriptions and assign rate cards based on subscription properties.

[0144] According to embodiments, the SPS service is responsible for managing the pricing rules for the subscription, including discounts offered to end users or customers. Pricing rule applicability can be based on attributes of the product, such as discount group, product category, or specific SKU. SPS internally needs to identify the list of products for which these rules will apply. To achieve this, the rule decoder engine can compile the pricing rules into a format that the inline rate engine can use for cost calculation. This compilation process can be triggered when a product or pricing rule is created or updated.

[0145] As Figure 10 According to embodiments, as shown in the example in FIG. 4, at 441, product and price information (e.g., managed in Fusion Applications) is sent to the SPS component.

[0146] At 442, the order is sent to the subscription manager component to create the subscription, rate card, and billing account.

[0147] At 443, the pricing configuration and pricing rules are sent to the SPS for the new order.

[0148] At 444, the subscription manager component is used to set up the billing account in the billing service or component.

[0149] At 445, the subscription manager component publishes events to the subscription manager streaming component.

[0150] At 446, the charge data is sent to the accounts receivable component 425 to generate an invoice.

[0151] At 447, the subscription manager component uses the Recycle and Subscription Life Cycle (RASL) events from the subscription manager streaming.

[0152] At 448, the activation service 427 reads the subscription manager event stream.

[0153] At 449, the customer gets activation data from the activation portal 429.

[0154] At 450, the lease life cycle service 461 provisions the lease as part of the subscription activation.

[0155] At 451, the lease life cycle service creates an account footprint during account provisioning within the account 463 component.

[0156] At 452, the lease life cycle service sets up the limit template during account provisioning within the limit service 467.

[0157] At 453, the account component acts as a downstream RASL client to handle legacy recycle and subscription life cycle 465.

[0158] At 454, the aggregated costs and usage are sent to the billing service 428 or component.

[0159] At 455, the organization can create sub-leases using the lease lifecycle service.

[0160] At 456, the metering service 432 or component obtains subscription mapping data.

[0161] At 457, the subscription service 430 obtains organization data 469 for subscription mapping.

[0162] At 458, the RASL component reads the subscription manager event stream.

[0163] At 459, the subscription service reads the subscription manager event stream; and at 460, the metering service or component obtains rate card data for each subscription, which can then be used for the ability to bill the operator or the operator to charge its customers a final fee.

[0164] The above-described examples are provided to illustrate that a dedicated or private tag cloud environment can be used to provide for tenants of a cloud infrastructure to use when accessing subscription-based software products, services, or other offerings associated with the cloud infrastructure environment. According to other embodiments, the various components, processes, and features described herein can be used with other types of cloud computing environments.

[0165] Dynamic rate cards for building and managing subscriptions

[0166] As described above, utilizing a 1 : 1 rate card per subscription relationship approach to providing access to software products or services in a cloud computing or other computing environment can be inconvenient, inefficient, or cost-prohibitive.

[0167] For example, each price change in such a system can trigger the creation of a rate card version for each subscription that exists in the system. For a cloud system with 1000 customers and 10000 products, a customized rate card approach would require the maintenance of 10 million price points for 1000 rate cards. A new product release can require the updating of all 1000 rate cards.

[0168] According to embodiments, systems and methods are provided for building and managing dynamic rate cards for cloud service subscriptions that allow rate cards to be associated with multiple subscriptions; and allow operators to provide customized, dynamic pricing and optimize the number of rate cards within easily manageable parameters.

[0169] According to an embodiment, an operator can use a single base price for each product against a given currency pair at a given time. The effective base price for a subscription can be determined based on the contract date and the subscription pricing strategy. Subscriptions created under a "current date list price" strategy result in the creation of a rate card that ensures these customers always pay the latest base price. Subscriptions created under a "contract date contract price" strategy result in the creation of a rate card that ensures these customers will pay the base price that exists at the contract date. Subscriptions created under a "lowest price among contract prices or reduced prices" strategy result in the creation of a rate card that ensures these customers will pay the lower of the base price that exists at the contract date or the latest lowest price.

[0170] According to embodiments, systems and methods are provided that utilize these groups, aggregate subscriptions into different groups, and use these groups to determine a base price for any given one or more customers, thereby reducing the complexity of rate card management while also providing the flexibility of custom pricing.

[0171] According to an embodiment, the system can provide dynamic management of cost assessments for service usage in a cloud environment. The system may include: a cloud environment deployed within the domain and controlled by a tenant operator; a cloud subscription service, manager, or component for managing subscriptions to cloud services; a subscription pricing service (SPS) configured to dynamically determine ratecard information for subscriptions; and a metering service.

[0172] According to an embodiment, a cloud environment deployed within the domain and controlled by an operator may include software products and / or services provided as cloud products and / or services by a vendor.

[0173] According to an embodiment, a cloud subscription manager can be configured to receive requests from end users to subscribe to one or more cloud products and / or services, and to complete the order by creating a subscription, wherein the subscription includes subscription pricing attributes.

[0174] According to an embodiment, the subscription pricing service can be configured to respond to pricing events and dynamically determine subscription rate card information based on subscription pricing attributes.

[0175] According to an embodiment, the metering service can be configured to receive rate card information from a subscription pricing service and end-user consumption information from a cloud service, wherein the end-user consumption information represents the end-user's use of the cloud service, and the end-user usage cost generated by the end-user's use of the cloud service is determined based on the rate card information and the end-user consumption information.

[0176] According to an embodiment, the subscription pricing service is operable to determine subscription rate card information based on subscription pricing attributes, which include one or more of the following: contract date price; and / or current rate price; and / or contract price and / or reduced price.

[0177] According to an embodiment, the metering service is operable to determine usage costs for the plurality of end users based on end user consumption information for each of the plurality of end users and rate card information, wherein the rate card information is based on a subscription pricing attribute common to each of the plurality of end users.

[0178] According to an embodiment, the subscription pricing service can include: a product integration tool service operable to pull product information data from a product hub operatively coupled to the system, wherein the product information data is representative of parameters of a cloud service; a pricing integration tool service operable to pull product pricing information data from a pricing hub operatively coupled to the system, wherein the product pricing information data is representative of pricing of the cloud service; and a pricing control plane operable with the product integration tool service and the pricing integration tool service.

[0179] According to an embodiment, the product integration tool service can be controlled by an operator of the system to modify the product information data representative of functional parameters of the cloud service, and / or to add additional product information data representative of additional parameters of the cloud product and / or service.

[0180] According to an embodiment, the pricing integration tool service can be controlled by an operator of the system to modify the product pricing information data representative of pricing of the cloud service, and / or to add additional product pricing information data representative of additional pricing of the cloud service.

[0181] According to an embodiment, the cloud environment can be deployed within a domain comprising a plurality of regions controlled by an operator.

[0182] According to an embodiment, one or more of the cloud products and / or services can be provided in each of the plurality of regions.

[0183] Subscription Pricing Service

[0184] Figure 11 FIGURE 1 illustrates the use of a subscription pricing service to provide access to a software product or service in a cloud computing environment, according to an embodiment.

[0185] As Figure 11 According to an embodiment, the subscription pricing service is responsible for providing information about products, global price lists, and price lists and discounts specific to end customer subscriptions, as shown in FIGURE 2.

[0186] For example, according to an embodiment, the subscription pricing service operates to sync product information from a product hub 421 A portion of the product and pricing hub 421 (as shown in FIGURE 2) and global price lists from a pricing hub 421 B portion of the product and pricing hub 421. Figure 10

[0187] ​According to embodiments, the cloud subscription manager operates as an upstream service to receive new order requests, e.g., from the order management 423 component. The cloud subscription manager can provide subscription information to a subscription pricing service (SPS). Subscription details such as, e.g., offer configuration time, subscription type (commit, PayG) help the SPS determine the valid base price (rate card) of the subscription. The cloud subscription manager can also send subscription discounts (e.g., received from the order management component), which the SPS stores as pricing rules entities.

[0188] According to embodiments, the subscription pricing service operates as a background process to manage a rate card service or component that is responsible for generating rate cards for new subscriptions and updating rate cards when new changes in prices occur. The subscription pricing service can expose APIs to access rate cards and pricing rules. The metering inline rate engine 540 can utilize these APIs to obtain subscription-specific rate cards and pricing rules and use this data for cost calculations.

[0189] According to embodiments, additional SPS components can include, e.g., a pricing / product hub integration component 500 that allows an operator entity (e.g., a PLC operator) to offer subscription-based products, services, or other offerings within the environment and manage its product and price lists, e.g., as provided by the product hub and pricing hub, respectively.

[0190] For example, according to embodiments, the SPS product integration flow can listen to create / update events in the product hub 421A and make calls to the SPS product APIs. Similarly, the SPS pricing integration flow can pull new price list creations from the pricing hub 421B and make calls to the corresponding SPS pricing APIs.

[0191] According to embodiments, the subscription pricing service 426 can include a product integration tool service 521A operable to pull product information data from a product hub 421A operatively coupled to the system, where the product information data is representative of parameters of a cloud service; a pricing integration tool service 521B operable to pull product pricing information data from a pricing hub 421B operatively coupled to the system, where the product pricing information data is representative of pricing of the cloud service; and a pricing control plane operable with the product integration tool service and the pricing integration tool service.

[0192] According to embodiments, the product integration tool service 521A is operable by an operator of the system to modify the product information data representative of functional parameters of the cloud service and / or to add additional product information data representative of additional parameters of the cloud product and / or service. The modified product information data and / or the additional product information data is registered via the control plane master area 520.

[0193] According to embodiments, the pricing integration tool service 521B can be operated by the operator of the system to modify product pricing information data representing pricing of cloud services, and / or to add additional product pricing information data representing additional pricing of cloud services. The modified product pricing information data and / or additional product pricing information data is registered via the control plane master region 520.

[0194] According to embodiments, a user interface or console 530 can be provided that allows the operator to manage their customer accounts and services offered to customers. The cloud infrastructure provider can also use a cloud infrastructure tenancy (e.g., a Fusion Applications tenancy) to install any required infrastructure services for use by the operator and their customers.

[0195] Figure 12 Further illustrated is the use of a subscription pricing service to provide access to software products or services in a computing environment, according to embodiments.

[0196] As Figure 12 As shown in FIG. 5B, according to embodiments, the additional SPS components can include, for example, a pricing / product hub (e.g., OCI) integration component 500 that allows an operator or entity offering subscription-based products, services, or other offerings within an environment to manage their product and price lists, for example, as provided by the product and pricing hub components 421, respectively.

[0197] For example, according to embodiments, the SPS product integration process can listen for create / update events in the (e.g., OCI) product hub 421 and make calls to the SPS product API. Similarly, the SPS pricing integration process can pull the creation of new price lists from the (e.g., OCI) pricing hub 421 and make calls to the corresponding SPS pricing API.

[0198] According to embodiments, the system can also include an SPS core module 502 that provides APIs to manage and access pricing entities. Pricing can be accessed by internal services (e.g., an inline rate engine).

[0199] According to embodiments, the system can also include a rate card manager component 504. The subscription pricing service maintains a single base price of a product at a given time. However, the price of a subscription depends on the base price at the time of offer configuration and the price list change policy attributes of the subscription. The subscription pricing service uses these properties to internally maintain prices for a subscription. All these price lists are grouped in rate cards. The rate card manager can create and maintain rate cards, listen for price list changes, and update existing rate cards with new prices. The rate card manager is also operable to listen for new subscriptions and assign rate cards based on the subscription properties.

[0200] According to embodiments, the system can also include a rules decoder engine 506. The subscription pricing service is responsible for managing the pricing rules for the subscriptions. These pricing rules include the discounts offered to the end customers. The pricing rule applicability can be based on attributes of the product such as, for example, discount group, product category, or specific SKU. According to embodiments, the subscription pricing service internally identifies the list of products for which these rules apply. To accomplish this, the rules decoder engine can compile the pricing rules into a format that enables the inline rate engine to be used for cost calculations. This compilation process can be triggered when a product or pricing rule is created / updated.

[0201] According to embodiments, the synchronization operation is performed in the SPS. In this regard, at 520, a new product is added to the product hub. Similarly, at 520, a new price list can be added to the pricing hub. Thereafter, at 522, the new product event and / or the new pricing event is indicated to the pricing / product hub integration component 500.

[0202] At 524, the pricing / product hub integration component 500 uses the API call of the SPS core 502. At 526, the new product and / or the new price is inserted into the product and / or price table of the SPS database 510.

[0203] At 528, the SPS uses the API call of the SPS core 502 to create subscription pricing configuration data and / or pricing rules, where the cloud subscription cloud subscription service, manager, or component 424 exposes one or more subscription management APIs for creating orders for onboarding new customers, or initiating workflows that create subscriptions and coordinate billing and pricing services or other components. Then, at 531, the SPS core 502 in turn inserts the configuration data and / or pricing rules into the SPS database 510.

[0204] According to embodiments, the system enables the operator to use the operator console 530 to perform various tasks, etc., including, for example, reading pricing rules, price lists, rate cards, at 532, and also including selectively creating pricing rules.

[0205] The operator console 530 makes an API call at 534 to retrieve the list and / or create pricing rules.

[0206] The metering inline rate engine module 511 can operate according to example embodiments to make an API call at 536 to retrieve the rate cards and / or pricing rules read from the SPS database 510 at 538.

[0207] In addition to the above, according to embodiments, the system also performs various one or more asynchronous background operations. In this regard, a new subscription can be read from the SPS database 510 to the rate card manager 504 at 540. Additionally, the rate card manager 504 can insert the generated rate card price list into the SPS database 510 at 541.

[0208] Also in addition to the above, according to embodiments, the system also performs various additional one or more asynchronous background operations. In this regard, a new pricing rule can be read from the SPS database 510 to the rule decoder engine 506 at 542. Additionally, the rule decoder engine 506 can insert the new pricing rule into the SPS database 510 at 543.

[0209] Dynamic rate card management

[0210] According to embodiments, the optimized dynamic rate card management allows organizations to provide customized or dynamic pricing and to optimize the number of rate cards to a manageable level, for example: rate cards can be associated with the type of contract pricing policy; subscriptions can be associated with the applicable rate card based on the contract pricing policy and contract date; and rate cards can be created and updated on the fly based on the last change in the price of a product in the system.

[0211] For example, according to embodiments, the system can operate using rate cards to group similar price lists for similar categories of subscriptions to optimize API calls from metering. Care should be taken to ensure that the correct rate card is mapped to the correct subscription and that the correct list of price lists is maintained for each rate card; otherwise, metering can receive the wrong rate, resulting in incorrect billing.

[0212] Figure 13 FIGURE 1 illustrates an example use of managing dynamic rate cards associated with a new subscription, according to embodiments.

[0213] As shown in Figure 13 According to embodiments, when a new subscription is created and there is no rate card for the latest price list, a new rate card can be generated.

[0214] Figure 14 FIGURE 2 illustrates an example use of managing dynamic rate cards associated with a price list addition, according to embodiments.

[0215] As shown in Figure 14 According to embodiments, when the price of an existing product changes or a new product is added, a new price list can be added. Changes in the price of an existing product do not affect rate cards of the CONTRACT_RATE type. Adding a new product will affect all rate cards. The rate card manager is responsible for updating rate cards when a price list changes.

[0216] According to embodiments, an organization can use a single base price per product for a given currency at a given time. The active base price for a subscription is determined based on the contract date and the subscription pricing strategy, such as (1) CurrentDate (List Price); (2) ContractDate (Contract Price); (3) (Contract Price - Discount) (whichever is) lowest price. According to embodiments, these constitute three subscription type groupings, which the system can then use to group subscriptions into a particular grouping and use to determine the base price. The three (3) groupings include CurrentDate (List Price), ContractDate (Contract Price), and (Contract Price - Discount) (whichever is) lowest price.

[0217] According to embodiments, subscriptions of the CurrentDate (List Price) type will always be charged at the latest base price.

[0218] According to embodiments, subscriptions of the ContractDate (Contract Price) type will be charged at the base price on the contract date.

[0219] According to example embodiments, subscriptions of the (Contract Price - Discount) (whichever is) lowest price type will be charged at the lowest of the base price on the contract date or the latest price.

[0220] Figure 15 A table 550 illustrating example subscription types and corresponding rate cards according to embodiments is illustrated.

[0221] A cloud computing environment according to embodiments herein can be used to provide access to a range of complementary cloud-based components, such as software applications or services, which enable an organization or enterprise customer to operate their applications and services in a highly available, hosted environment.

[0222] According to embodiments, the system enables a visitor or client carrier (such as a service provider, integrator, and independent software vendor (ISV)) that partners with a cloud operator to become a private-label cloud provider, thereby directly offering to its end customers a broad range of various applications and services that the operator can customize according to specific industry, market, and regulatory or government regulations.

[0223] Such visitor or client carriers can develop their own unique / proprietary infrastructure and platform services that can not be available in a public cloud environment, but their customers can find these infrastructure and services to have special value for certain industries, markets, and regulatory schemes.

[0224] To enhance value for operators, the embodiments described herein enable infrastructure and platform services to be offered under an operator-specific brand, while allowing operators to maintain full control over commercial terms, customer relationships, and touchpoints. This includes control over pricing strategies, including pricing for their own unique / proprietary infrastructure and platform services.

[0225] As mentioned above, organizations previously used static rate cards as a way to manage product inventory pricing for their customers, where the rate card defined pricing per customer subscription. Essentially, each customer subscription was associated with a rate card that set the pricing for platform services on a per-customer basis. Dynamic rate cards have also been used, where customers are always provided with the latest price regardless of whether the price of an individual product increases or decreases.

[0226] According to the embodiments described herein, customer behavior can be driven by locking the price to the contract date, or in some cases, to the lower of the contract date price or the latest price, rather than simply using the latest catalog price. However, using this approach in conjunction with the previously available ratecard scheme of one ratecard per subscription (1:1 relationship) would result in the system having to manage too many ratecards, thus placing a heavy overhead burden on the operator.

[0227] According to embodiments, this topic provides methods and systems for building and managing dynamic rate cards for cloud service subscriptions, which allow rate cards to be associated with multiple subscriptions.

[0228] Therefore, the highest level of improvement to be sought is the ability to associate a rate card with several (N) subscription relationships (1:N), whereas previously each subscription relationship was associated with its own unique rate card (1:1).

[0229] Compared to the previous 1:1 rate card to subscription scheme, the proposed 1:N rate card to subscription scheme offers several advantages. The first advantage is a significant reduction in the number of rate cards the system needs to maintain. Another advantage is the reduction in processing power required to update system rate cards in response to any changes in subscription pricing (such as potential price increases or discounts). In the new 1:N scheme, the number of rate cards that need to be updated to address pricing changes across all subscription relationships is drastically reduced. Furthermore, the metering component in the system that assesses subscription costs for cloud products only needs to consult a much smaller set of rate cards, unlike the old 1:1 rate card to subscription scheme which required sifting through the entire rate card allocation.

[0230] In this embodiment, the operator uses a single base price for each product against a given currency pair at a given time. The effective base price for a subscription is determined based on the contract date and the subscription pricing strategy.

[0231] Subscriptions purchased under the "Current Date List Price" strategy will generate a rate card that ensures these customers are always paid at the latest base price. Here, a single rate card can be used or associated with any number of existing or potential subscriptions that have been purchased or are about to be purchased under the "Current Date List Price" strategy (1:N relationship).

[0232] like Figure 15 As shown in the example in Table 550, as an illustrative example, the product price changes every three months. Although Figure 15 As an illustrative example, the product price is changed every three months. It should be recognized that product prices can be changed at any time or randomly, depending on expectations and / or needs. Therefore, Figure 15 The examples provided are not intended to limit the exemplary embodiments and are presented only as non-limiting examples.

[0233] In the embodiments and according to Figure 15 For an illustrative example, for the subscription type "List Price (ALP)," all subscriptions will have a single rate card ALP-0000. Price changes will add a new entry to this rate card. This is shown in the "List Price" column of Table 550, where, as you can see, all the displayed subscriptions (e.g., PayGSubQ1-1 to PayGSubQ4-3) use a single rate card ALP-0000. In the example, the price changes on January 1, 2022, April 1, 2022, July 1, 2022, and October 1, 2022 only resulted in the addition of a new entry to the single rate card ALP-0000. This 1:N relationship between one rate card and multiple subscriptions is much more efficient than the previous 1:1 scheme where each subscription was associated with one rate card.

[0234] In the embodiments and according to Figure 15 As an illustrative example, for the ACP (Advanced Contract Price) subscription type, a price change will generate a new rate card, but it will not affect existing rate cards. All subscriptions created during these modification windows will use the same rate card.

[0235] In this embodiment, subscriptions purchased according to the "contract date, contract price" strategy will generate a rate card in the example that ensures these customers will be paid at the base price on the contract date. In this scenario, price changes will generate a new rate card but will not affect existing rate cards.

[0236] This is Figure 15As shown in the “Contract Price” column of Table 550, a single rate card ACP-010122 is used for all subscriptions in ContractPriceSubQ1-1 to ContractPriceSubQ1-3 purchased, for example, during the time window from January 1, 2022 to April 1, 2022. Similarly, and as shown in the “Contract Price” column of the table below, a single other rate card ACP-040122 is used for all subscriptions in ContractPriceSubQ2-1 to ContractPriceSubQ2-3 purchased, for example, during the time window from April 1, 2022 to July 1, 2022. Similarly, the third rate card ACP-070122 is used to illustrate, for example, all subscriptions in ContractPriceSubQ3-1 to ContractPriceSubQ3-3 purchased during the time window from July 1, 2022 to October 1, 2022; and the fourth rate card ACP-100122 is used to illustrate, for example, all subscriptions in ContractPriceSubQ4-1 to ContractPriceSubQ4-3 purchased during the time window following the price change that occurred on October 1, 2022. This A:N relationship between rate cards (four (4) in the example) and the many subscriptions that can be created in the time window between price changes is much more efficient than the previous 1:1 scheme of one rate card for each subscription.

[0237] In the example embodiments described herein, unlike previous systems that required twelve (12) rate cards—one for each subscription—the new dynamic rate card technology of this disclosure requires only four rate cards. Therefore, there is a 1:N relationship between rate cards and subscriptions for subscriptions created within a time window between price changes. Furthermore, there is an A:N relationship between rate cards and the total number of subscriptions, where A < the total number of subscriptions. These 1:N and A:N relationships between rate cards and numerous subscriptions are far more efficient than the previous 1:1 scheme where each subscription was associated with one rate card.

[0238] In the embodiments and according to Figure 15 For an illustrative example, for the Contract Price-Reduction (ACPPD) type, subscriptions created during the same price window use a single rate card. If the price changes, a new ACPPD rate card is generated; and if the product price decreases, the existing rate card is updated.

[0239] In an embodiment, subscriptions purchased pursuant to the “contract price or lowest price in a drop” strategy will generate rate cards that ensure that these customers will pay the minimum of the contract date’s base price or the latest price. In this scenario, subscriptions created during the same price window use a single rate card. If a price increase occurs, then a new rate card is created; and if a price decrease occurs, then the existing rate card is updated to the new lower price(s). This is shown in the “contract price - drop” column in the following table, where, as can be seen, a single rate card, ACPPD-010122, is used for all of the subscriptions CPPriceDropSubQ1-1 through CPPriceDropSubQ1-3 shown as purchased during the time window of, for example, January 1, 2022 through April 1, 2022.

[0240] Similarly, and as shown in the “contract price - drop” column in table 550, Figure 15 Another single rate card, ACPPD-040122, is used for all of the subscriptions CPPriceDropSubQ2-1 through CPPriceDropSubQ2-3 shown as purchased during the time window of, for example, April 1, 2022 through July 1, 2022, as shown in the “contract price - drop” column in table 550. In this example, the price can drop on July 1, 2022. In this case, rate card ACPPD-040122 is updated to the new lower price, and all new subscriptions (e.g., CPPriceDropSubQ3-1 through CPPriceDropSubQ3-3 purchased during the time window of July 1, 2022 through October 1, 2022) all use the same rate card, ACPPD-040122, with the adjusted lower pricing information. A third rate card, ACPPD-100122, is used for all of the subscriptions CPPriceDropSubQ4-1 through CPPriceDropSubQ4-3 shown as purchased during the time window of, for example, after the price change on October 1, 2022. This rate card (three (3) in the example) to many subscriptions A:N relationship is much more efficient than the 1:1 scenario of one rate card per subscription associated with the previous system.

[0241] In this example, unlike the previous system that required the use of twelve (12) rate cards - one per subscription - the new dynamic rate card technique requires the use of only three rate cards. Thus, for subscriptions created in the time window between price changes, there is a 1:N relationship between rate cards and subscriptions. Furthermore, there is an A:N relationship between rate cards and the total number of subscriptions, where A < total number of subscriptions. These 1:N and A:N relationships between rate cards and many subscriptions are much more efficient than the 1:1 scenario of one rate card per subscription associated with the previous system.

[0242] In the table shown in Figure 15 , as an illustrative example, product prices are changed every three months. Here, the subscription type "List Price" will have a single rate card ALP-0000 for all subscriptions. Price changes will add new entries to this rate card. For "Contract Price" subscription type, price changes will generate new rate cards, but it will not affect existing rate cards. All subscriptions created during these modified time windows will use the same rate card. For "Contract Price - Discount" type, subscriptions created during the same price window use a single rate card. If the price changes, it will have a new rate card; if the product price drops, the existing rate card will be updated.

[0243] Embodiments herein utilize these groups, aggregate subscriptions into different groups, and use these groups to determine the base price for any given customer, thereby reducing the complexity of rate card management while also providing flexibility for custom pricing.

[0244] Figure 16 FIGURE 1 illustrates an example use of dynamic rate cards applied to various subscription-based products, services, or other offerings, in accordance with an embodiment.

[0245] As Figure 16 shown in Figure 15 , for the above example set described in conjunction with Figure 15 , prices are changed every three months. In this example, an organization with 10,000 subscriptions would typically need 10,000 rate cards to support custom pricing; however, the approach described herein reduces this to 9 rate cards. Thus, there is a significant benefit from using the embodiments herein according to the use of dynamic rate cards, relative to a system that does not benefit from dynamic rate cards, in accordance with an embodiment.

[0246] Rate Card Generation

[0247] According to an embodiment, rate cards are associated with subscriptions, so a new subscription will trigger a rate card generation workflow. New price creation or update will not trigger rate card generation, as rate card generation is useless unless new subscriptions are created within that time window. The system will respond to new subscription and price update events.

[0248] New Subscription Event

[0249] According to an embodiment, for a new subscription event, each subscription type system will respond as explained below:

[0250] 1. List Price (ALP):

[0251] a. Assign the existing ALP-0000 rate card to the new subscription.

[0252] 2. Contract Price (ACP):

[0253] a. Find the most recent time before the date of the subscription contract that there was a price change, called T max .

[0254] b. Find if there is an ACP rate card with TimeEffective = T max .

[0255] i. If so, then assign that ACP rate card to the new subscription.

[0256] ii. If not, then

[0257] 1. Create a new ACP rate card and add all product price points that were in effect at T max to the new ACP rate card.

[0258] 2. Set T max as the TimeEffective of the new ACP rate card.

[0259] 3. Update the subscription with the newly generated ACP rate card.

[0260] 3. Contract Price - Price Drop (ACPPD):

[0261] a. The method for ACPPD type is the same as the ACP rate card mentioned above, except the rate card type will be changed to ACPPD.

[0262] According to embodiments, in the above flow, rate card generation happens only for missing ACP and ACPPD type rate cards.

[0263] New product release

[0264] According to embodiments, the system is operable to react to a new product release by adding a new price entry to all rate cards in the system to reflect the new product release. According to embodiments, the system is operable to react to a new product release by using variations of the above behavior based on one or more policies that the organization can adopt and / or require.

[0265] Product discontinuation

[0266] According to embodiments, the system reacts to a product discontinuation by removing the product pricing from all relevant rate cards in the system.

[0267] Existing product price change

[0268] According to embodiments, for an existing product change, each subscription type system will respond as explained below:

[0269] 1. ALP (ALP):

[0270] a. Add new price entry for product in ALP-0000 rate card.

[0271] 2. ACP (ACP):

[0272] a. This will not require any changes as the price will remain constant as per contract.

[0273] 3. ACPPD (ACPPD):

[0274] a. Find all rate cards of type ACPPD.

[0275] b. For each rate card

[0276] i. Find the latest price of the product at the contract date.

[0277] ii. If it exists, then check if (new product price < contract date price)

[0278] 1. If true, then add new entry for ACPPD rate card using new updated price.

[0279] 2. Else update product price as per contract date.

[0280] iii. If it does not exist, then find the first price of the product after the contract date

[0281] 1. If (new product price < first price of product), then add new entry for ACPPD rate card using new updated price.

[0282] 2. Else update product price as per first price.

[0283] Custom pricing (discounts) beyond rate cards

[0284] According to embodiments, the methods described herein can be used to help organizations support custom rate cards. Organizations can further extend custom pricing by providing discounts on top of custom rate card prices. For example, an organization can add a discount policy such as, for example, “10% discount on all products for subscription A”. The effective base price can be the combined value of the rate card price minus the provided subscription discount. Organizations can maintain such discount rules outside of base rate cards and make them available for cost calculations. Using such custom rate cards and discounts provides organizations with an opportunity to provide competitive pricing.

[0285] Rate cards stored in mutable and semi-mutable data structures

[0286] According to embodiments, the rate cards are stored in the non-transitory memory device in variable data structures and semi-immutable data structures. For example, ALP rate cards can be stored in variable data structures, and ACP rate cards can be stored in semi-immutable data structures.

[0287] According to embodiments, to support the sales process through which a subscription is created in the domain, a product can be selected from a product hub. Once an order is created via the cloud subscription manager, a subscription is created in the cloud subscription manager, which thereafter manages the life cycle of the subscription and provisions what is needed in the downstream services. The SPS components then manage the pricing and usage aspects for the ability to charge the operator or the operator charges to its customers. Usage events are forwarded to the billing service or component, where depending on the billing preferences of the subscription, invoices are created and pushed to the accounts receivable component.

[0288] According to embodiments, while the services provisioned in the domain report their usage to the metering service or component, such usage does not have any price associated with it. The rate processing (e.g., by applying rate cards) determines what the cost of each particular event is, determines the units and cost for that subscription, associates the cost with that record, and then forwards it to the billing service or component.

[0289] According to embodiments, the subscription pricing service runs as a background process to manage the rate card service or component, which is responsible for generating rate cards for new subscriptions and updating these rate cards when new changes in prices occur. The subscription pricing service can provide APIs to access the rate cards and pricing rules. The metering inline rate engine can utilize these APIs to obtain the rate cards and pricing rules specific to a subscription and then use this data for cost calculations.

[0290] Use of dynamic rate cards

[0291] Figure 17 is a flowchart illustrating a method 600 of using dynamic rate cards according to embodiments.

[0292] As Figure 17 According to embodiments, a plurality of usage rates is identified at 602, where the plurality of usage rates respectively correspond to a plurality of cloud computing services. In example embodiments, values of the plurality of usage rates can be modified over time. These values can be processed for usage of services in a cloud environment.

[0293] The variable data structure is generated at 604 to reference a first set of values of a corresponding first set of usage rates of the plurality of usage rates. In an example embodiment, the variable data structure is modified in response to determining that a value of at least one usage rate of the first set of usage rates has changed. In this example, the variable data structure generated at 604 can be an ALP rate card that references a current set of values of a corresponding first set of usage rates of the plurality of usage rates.

[0294] The semi-immutable data structure is generated at 606 to reference a second set of values of a corresponding second set of usage rates of the plurality of usage rates. In an example embodiment, all or a portion of the semi-immutable data structure is not modified in response to determining that a value of any one usage rate of the second set of usage rates has changed. In this example, the semi-immutable data structure generated at 606 can be an ACP rate card that references a second set of values of a corresponding second set of usage rates of the plurality of usage rates.

[0295] The variable data structure is associated at 608 with a first plurality of affiliations in a first one-to-many relationship. In an example embodiment, the variable data structure is associated at 608 with a first plurality of affiliations including, for example, a first plurality of subscriptions in a first one-to-many relationship.

[0296] The semi-immutable data structure is associated at 610 with a second plurality of affiliations in a second one-to-many relationship. In an example embodiment, the semi-immutable data structure is associated at 610 with a second plurality of affiliations including, for example, a second plurality of subscriptions in a second one-to-many relationship.

[0297] The variable data structure is referenced at 612 to determine a first set of applicable values of service usage associated with usage of the plurality of cloud computing services by the first plurality of affiliations based on the first set of usage rates. In an example embodiment, referencing the variable data structure at 612 can include referencing the variable data structure to determine respective first set of applicable cost values of service usage associated with usage of the plurality of cloud computing services by the first plurality of subscriptions for user tenants of the cloud environment based on the first set of usage rates.

[0298] The semi-immutable data structure is referenced at 614 to determine respective second set of applicable values of service usage associated with the second plurality of affiliations of the plurality of cloud computing services based on the second set of usage rates. In an example embodiment, referencing the semi-immutable data structure at 614 can include referencing the semi-immutable data structure to determine respective second set of applicable cost values of service usage associated with usage of the plurality of cloud computing services by the second plurality of subscriptions for user tenants of the cloud environment based on the first set of usage rates.

[0299] Amended list price (ALP) rate card

[0300] Figure 18 FIG. 6 is a flowchart illustrating a method 620 of amending a list price (ALP) rate card, according to an embodiment.

[0301] As shown in FIG. 6, at 622, an updated value of an expired value of a first usage rate in a first set of usage rates is identified, according to an embodiment. Figure 18

[0302] At 624, the mutable data structure is updated to add an updated usage rate corresponding to the first usage rate in the first set of usage rates. According to an embodiment, the updated usage rate in the updated mutable data structure references the updated value.

[0303] Amended contract price (ACP) rate card

[0304] Figure 19 FIG. 6 is a flowchart illustrating a method 620 of amending a list price (ALP) rate card, according to an embodiment.

[0305] As shown in FIG. 6, at 622, an updated value of an expired value of a first usage rate in a first set of usage rates is identified, according to an embodiment. Figure 19

[0306] At 634, a new semi-immutable data structure is generated. According to an embodiment, the new semi-immutable data structure generated at 634 includes the semi-immutable data structure with an updated usage rate corresponding to the first usage rate in the second set of usage rates added. According to an embodiment, the updated usage rate in the new semi-immutable data structure references the updated value.

[0307] Amending ALP / ACP rate cards to add new cloud computing services

[0308] Figure 20 FIG. 6 is a flowchart illustrating a method 620 of amending a list price (ALP) rate card, according to an embodiment.

[0309] As shown in FIG. 6, at 622, an updated value of an expired value of a first usage rate in a first set of usage rates is identified, according to an embodiment. Figure 20

[0310] At 642, the mutable data structure is updated to add a new usage rate corresponding to usage of the new cloud computing service. According to an embodiment, the new usage rate in the updated mutable data structure references a value of the new usage rate of the new cloud computing service.

[0311] ​​​A new semi-immutable data structure is generated at 643, where the new semi-immutable data structure includes the semi-immutable data structure ACP rate card with the new usage rate corresponding to usage of the new cloud computing service added. According to embodiments, the new usage rate in the new semi-immutable data structure references the value of the new usage rate for the new cloud computing service.

[0312] The modified mutable data structure is referenced at 644 to determine the value of the new usage rate for the new cloud computing service of service usage associated with the first plurality of associated parties' usage of the new cloud computing service.

[0313] The semi-immutable data structure is referenced at 645 to determine the value of the new usage rate for the new cloud computing service of service usage associated with the first plurality of associated parties' usage of the new cloud computing service.

[0314] New subscription to a cloud service

[0315] Figure 21 is a flowchart illustrating a method 650 of handling a new subscription to a set of cloud computing services, according to embodiments.

[0316] As Figure 21 shown in FIG. 6B, according to embodiments, a new associated party is received at 652, where the new associated party is associated with one of the plurality of cloud computing services of the cloud infrastructure environment. In example embodiments, the new associated party can include a new subscription associated with one of the plurality of cloud computing services, etc.

[0317] The method 650 determines whether the value of the usage rate for the new associated party's access to one of the plurality of cloud computing services includes one or more of the first set of usage rates or the value of the second set of usage rates at 654.

[0318] The new associated party is associated with a mutable data structure or a semi-immutable data structure at 655, 656.

[0319] In embodiments, the new associated party is associated with the mutable data structure at 655 based on the value of the usage rate for the new associated party's access to one of the plurality of cloud computing services including one or more of the first set of usage rates. In embodiments, the new associated party is associated with the semi-immutable data structure at 656 based on the value of the usage rate for the new associated party's access to one of the plurality of cloud computing services including one or more of the second set of usage rates.

[0320] In embodiments, the new associated party is associated with the mutable data structure at 655 based on the value of the usage rate for the new associated party's access to one of the plurality of cloud computing services including one or more of the first set of usage rates, including the new associated party comprising a new subscription to a cloud service.

[0321] In the embodiment, at 656, the usage rate based on the new associate's access to one of a plurality of cloud computing services includes one or more of a second set of usage rates, including the new associate's new subscription to the cloud service associated with a semi-immutable data structure.

[0322] The carrier sector acts as a proxy for subscription identification.

[0323] Figure 22 This is a flowchart illustrating a method 660 for using the operator domain as a proxy for subscription identification according to an embodiment.

[0324] like Figure 22 As shown, according to an embodiment, based on the first subscription characteristic of a first associated party among a first plurality of associated parties relative to a plurality of cloud computing services deployed in a cloud computing infrastructure, method 660 determines at 662 that the first associated party is associated with a variable data structure.

[0325] In an example embodiment, based on the first subscription feature of the first associated party relative to multiple cloud computing services deployed in the cloud computing infrastructure, method 660 determines at 662 that the first associated party, which includes the first subscription of the first multiple associated parties, is associated with a variable data structure.

[0326] In an example embodiment, based on the first subscription characteristic relative to multiple cloud computing services deployed in the cloud computing infrastructure, including the operator domain associated with the service use of the first subscription, method 660 determines at 662 that the first subscription among the first plurality of associated parties is associated with a variable data structure.

[0327] Continue to refer to Figure 22 Based on the second subscription feature of the second associated party among the second plurality of associated parties relative to the multiple cloud computing services deployed in the cloud computing infrastructure, method 660 determines at 664 that the second associated party is associated with a variable data structure.

[0328] In an example embodiment, based on the second subscription feature of the second associated party relative to multiple cloud computing services deployed in the cloud computing infrastructure, method 660 determines at 664 that the second associated party, which includes the second subscription of the second plurality of associated parties, is associated with a variable data structure.

[0329] In an example embodiment, based on the second subscription feature relative to multiple cloud computing services deployed in the cloud computing infrastructure, including the operator domain associated with the service use of the second subscription, method 660 determines at 662 that the second subscription of the second plurality of related parties is associated with a variable data structure.

[0330] Dispose of new subscriptions associated with ACP rate cards

[0331] Figure 23is a flowchart illustrating a method 670 of provisioning a new subscription for a set of subscriptions associated with an ACP rate card, according to an embodiment.

[0332] As Figure 23 As shown in 672, according to an embodiment, a new association is received, where the new association relates to one of the plurality of cloud computing services of the cloud computing infrastructure. According to an embodiment, the new association received at 672 can include a new subscription to one of the plurality of cloud computing services of the cloud computing infrastructure, etc.

[0333] The method 670 determines, at 674, whether the value of the usage rate of access by the new association to one of the plurality of cloud computing services is one or more of the first set of usage rates or the second set of usage rates.

[0334] At 676, based on the determined usage rate of access by the new association to one of the plurality of cloud computing services being neither the first set of usage rates nor the second set of usage rates, a new semi-immutable data structure is generated.

[0335] Rate card migration

[0336] According to an embodiment, to accommodate the use of dynamic rate cards, a migration service or process can be used to convert / migrate subscriptions that were originally created under a legacy or previous subscription pricing model (SPM) to instead conform to a subscription pricing service (SPS) model for use with the various systems, methods, and features described herein.

[0337] Generally speaking, the so-called legacy or SPM rate cards are filled in by a sales person for each end customer at the time of subscription order. Thus, each end customer’s subscription to a cloud application service product has a legacy rate card associated with it; this provides a 1 : 1 relationship between rate card and product subscription in the SPM pricing model. In the SPM, each rate card by definition reflects the unit sales price for a given subscription, with all discounts already applied at the time of order.

[0338] Such legacy subscriptions are generally static, in that the company defines pricing per customer. However, SPM rate cards can be considered somewhat dynamic in that they can be used to provide the most up-to-date prices to selected customers, without being affected by changes in the overall price of individual products. To support this, the SPM scheme uses pricing strategies in conjunction with legacy rate cards, where the combination of pricing strategy and rate card subscription price is used to determine the end customer’s cost.

[0339] As noted above, in accordance with embodiments, to address the technical challenge of maintaining end user subscriptions, the system can include a subscription pricing service (SPS) that implements and maintains a dynamic rate card that is centered around a base price. That is, the SPS uses a single global base price for each product at a given time for a given currency pair. In the SPS model, the effective base price of a subscription is determined based on the contract date and subscription pricing rules— (1) CurrentDate (list price); (2) ContractDate (contract price); (3) (contract price - discount) (the lower of the two). Unlike the 1 : 1 legacy rate card to subscription mapping of the SPM subscription model, in the new SPS subscription model, the mapping between rate cards and end user subscriptions is essentially 1 : N.

[0340] While the 1 : N subscription model provided by the SPS reduces the complexity of pricing and supports modern pricing scenarios via base price modeling and discounts, there is a need to migrate existing legacy rate cards that use a 1 : 1 approach to the SPS pricing model that uses dynamic rate cards in a 1 : N approach.

[0341] In accordance with embodiments, the system includes a rate card migrator component or migration service or process (referred to herein in some embodiments as RC-Migrator) that migrates existing subscriptions and product-specific legacy rate cards used in the SPM model to dynamic rate cards used in the SPS model.

[0342] In accordance with embodiments, the rate card migration process uses the configuration / creation date of the SPM rate card to determine the base price to be applied to the subscription of the legacy (SPM) rate card or contract type subscription in the SPS.

[0343] In accordance with embodiments, next, the rate card migration process determines the discount to be applied to each subscription based on the difference between the base price determined in the SPS and the original product unit sale price of the subscription in the SPM. This difference is reflected in the (primary) SPS pricing rules to be applied to the SPS rate card base price for the particular subscription.

[0344] In accordance with embodiments, special pricing strategies supported by the legacy (SPM) rate card or subscription are accommodated in the rate card migration process by generating additional (secondary) pricing rules to be combined with the primary SPS pricing rules and the global base price that goes into effect at the configuration / creation date of each SPM rate card to be applied to the subscription.

[0345] Figure 24 FIGURE illustrates an example of a cloud infrastructure architecture 700 that provides for migration of rate cards, in accordance with an embodiment.

[0346] In accordance with embodiments, Figure 24The way SPM rate card 701 is migrated to SPS rate card 703 is shown generally. Overall, the SPS pricing model uses a single global base price for a product, which can be synchronized into the SPS system from the product pricing hub.

[0347] At 702, historical data from SPM is synchronized to SPS.

[0348] At step 704, the system inserts product and price list data into the SPS system.

[0349] At 706, the legacy (SPM) rate card or subscription is delivered to or read by the migration service (RC-Migrator) 707.

[0350] At step 708, the system determines the base price to be applied to the subscription of the contract rate type, as determined by, for example, a configuration, price, quote (CPQ) system or application 705 that helps sellers configure products or services and quote to meet the requirements of their customers.

[0351] According to embodiments, SPS needs the quoteConfigureDate of the subscription to determine the base price to be applied to the subscription of the CONTRACT_RATE type. SPS will get this quoteConfigureDate information from the CPQ / Source Channels for all subscriptions. The SPS system will generate a rate card price list item for a given quoteConfigureDate, priceChangePolicy combination. This rate card price list item contains only the base price, without any discount. Also, the SPS rate card is generic for subscriptions with the same quoteConfigureDate and priceChangePolicy.

[0352] At step 710, the rate card migrator 707 creates an order in the cloud subscription service, manager, or component that creates subscription price configuration information in the SPS system at step 712. The subscription pricing configuration contains the subscription quote date and price list change policy information. According to embodiments, SPS can generate a rate card based on this information.

[0353] According to embodiments, at 714, the system creates pricing rules based on the discounts mentioned in the SPM rate card for a given subscription, and creates and delivers additional pricing rules to SPS based on the SPS rate card and the pricing rules.

[0354] According to an embodiment, a verifier 709 is provided for reading the SPM rate cards at 716 and the SPS rate cards at 718 for comparison to verify the result of the SPM to SPS rate card migration.

[0355] RC-migrator processing

[0356] According to an embodiment, the rate card migration service or process operates according to a two-stage approach to create the pricing rules.

[0357] Stage 1: SPM RC discounts

[0358] In the first stage, the system reads the SPM rate cards for each subscription and generates discounts. Internally, it performs the following steps to generate discounts for a given subscription:

[0359] 1. Get the subscription creation date in SPM.

[0360] 2. Read all rate cards from SPM whose reason code is null for the subscription creation date. This matches exactly with the rate cards in the quote created by the sales person.

[0361] 3. These rate cards contain unitPriceDiscount (discretionaryDiscount) which is required by the rate card migration service or process to generate pricing rules in SPS.

[0362] a. Group all products similar discount category.

[0363] b. Determine the lowest discount in each group.

[0364] c. Create a pricing rule for the group with the lowest discount value of the discount category.

[0365] d. If the remaining discount is greater than 0, then subtract the category discount from each product in the group and create product specific pricing rules.

[0366] 4. Create pricing rules for ALL_SUBSCRIPTIONS using the standard discount percentage from SPM, typically

[0367] a mapping of (DiscountCategory + CommitmentModel (yearly, monthly, quarterly) -> discount percentage).

[0368] 5. Get the SPS rate cards and pricing rules created from the SPS system.

[0369] 6. Perform verification of SPM unitPrice for all rate cards from order creation till today for a given subscription.

[0370] 7. Identify all SPM rate cards that have a final price mismatch between SPS and SPM. Perform phase 2 for all such rules.

[0371] Phase 2: Additional discounts

[0372] In the second phase, the rate card migration service or process generates additional pricing rules to match the final unitPrice between SPM and SPS models by performing the following tasks:

[0373] 1. Read all the mismatched rate cards from the first phase in the order in which they were created.

[0374] 2. For each mismatched rate card, the following sub-steps should be performed:

[0375] a. Determine the difference between the SPM RC unitPrice and SPS (rate card minus all applied discounts for the product).

[0376] b. Create a pricing rule for the current product and subscription with the difference identified in step 2.a.

[0377] c. These additional pricing rules should have a start date and end date, which should be the same as the corresponding mismatched SPM rate card.

[0378] According to embodiments, there are scenarios where the rate card migration service or process needs to handle the start and end dates of these pricing rules, for example:

[0379] Generalized pricing rules should apply according to the start and end dates of the SPM subscription.

[0380] If a subscription has been renewed or supplemented, then the previous set of rules should be automatically disposed of, as the start and end dates of these pricing rules will be populated from the SPM subscription.

[0381] For mismatched scenarios, the start and end dates should be the same as the corresponding mismatched rate card.

[0382] Migrating legacy rate cards

[0383] Figure 25 is a flowchart illustrating a method 720 of migrating legacy rate cards to a cloud infrastructure environment, according to embodiments.

[0384] As Figure 25As shown in FIG. 7, according to an embodiment, the method 720 includes identifying, at 722, a plurality of usage rates corresponding to a plurality of cloud computing services, respectively, wherein values of the plurality of usage rates are modifiable over time for use with variable and semi-immutable data structures. According to an embodiment, identifying, at 722, the plurality of usage rates includes identifying the plurality of usage rates, wherein values of prices included in the plurality of usage rates are modifiable over time for use with variable and semi-immutable data structures.

[0385] According to an embodiment, the variable data structure references a first set of values of a corresponding first set of usage rates of the plurality of usage rates. According to an embodiment, in response to determining that a value of at least one usage rate of the first set of usage rates has changed, the variable data structure is modified. According to an embodiment, the variable data structure is associated with a first plurality of affiliates in a one-to-many relationship.

[0386] According to an embodiment, the semi-immutable data structure references a second set of values of a corresponding second set of usage rates of the plurality of usage rates. According to an embodiment, in response to determining that a value of any one of the second set of usage rates has changed, the semi-immutable data structure is not modified. According to an embodiment, the semi-immutable data structure is associated with a second plurality of affiliates in a one set of one-to-many relationships.

[0387] With continued reference to Figure 25 , the method 720 includes receiving, at 724, a new affiliate related to one of the plurality of cloud computing services. According to an embodiment, receiving, at 724, the new affiliate includes receiving the new affiliate including a new subscription related to one of the plurality of cloud computing services.

[0388] The method 720 includes identifying, at 726, a legacy usage rate value corresponding to access to the one of the plurality of cloud computing services via the new affiliate.

[0389] The method 720 further includes creating, at 728, a rule based on the legacy usage rate and a selected one of the plurality of usage rates. According to an embodiment, creating, at 728, the rule includes creating a pricing / discounting rule based on the legacy usage rate and the selected one of the plurality of usage rates.

[0390] The method 720 further includes generating, at 730, one of a new variable data structure or a new semi-immutable data structure based on the received new affiliate. According to an embodiment, the new variable or semi-immutable data structure references a determined value of a corresponding usage rate for accessing the one of the plurality of cloud computing services. According to an embodiment, the determined value is based on the rule and the selected one of the plurality of usage rates.

[0391] Figure 26 is a flow diagram illustrating a method 740 of validating a migrated legacy rate card, according to an embodiment.

[0392] AsFigure 26 As shown in the method 740, according to an embodiment, the verification of the subscription migration includes verifying the determined value referenced in the new data structure by receiving, at 741, a legacy value associated with usage of one of the plurality of cloud computing services and a post-migration usage value associated with usage of one of the plurality of cloud computing services and comparing the two at 742.

[0393] According to an embodiment, the method 740 of verifying a post-migration legacy rate card includes verifying the determined value referenced in the new data structure by comparing a legacy value associated with usage of one of the plurality of cloud computing services by applying a legacy usage rate to the usage of one of the plurality of cloud computing services, with a post-migration usage value associated with usage of one of the plurality of cloud computing services by applying the determined value to the usage of one of the plurality of cloud computing services.

[0394] Figure 27 is a flowchart illustrating a method 750 of subscription migration in the context of an operator domain.

[0395] As Figure 27 As shown in the method 750, according to an embodiment, an indication of a legacy subscription characteristic of a computing service deployed in the cloud computing service is received, at 751. At 752, a new mutable or semi-mutable data structure is generated based on the legacy subscription characteristic of the new affiliate with respect to the plurality of cloud computing services deployed in the cloud computing service.

[0396] According to an embodiment, the new mutable or semi-mutable data structure is generated at 752 based on the legacy subscription characteristic including an operator domain associated with service usage of the new affiliate with respect to the plurality of cloud computing services deployed in the cloud computing service.

[0397] According to various embodiments, the teachings herein can be implemented using one or more computers, computing devices, machines, or microprocessors, including one or more processors, memories, and / or computer readable storage media programmed in accordance with the teachings herein. It will be apparent to those of ordinary skill in the software art that a person of skill can easily prepare appropriate software coding based on the teachings of the present disclosure.

[0398] In some embodiments, the teachings herein can include a computer program product, which is a non-transitory computer-readable storage medium (or media) having instructions stored thereon / therein that can be used to program a computer to perform any of the processes of the present teachings. Examples of such a storage medium can include, but are not limited to, a hard disk, a floppy disk, a hard drive, a fixed disk, a ROM, a RAM, an EPROM, an EEPROM, a DRAM, a VRAM, a flash memory device, or any other type of storage medium or device which is suitable for storing instructions and / or data.

[0399] The foregoing description is provided for purposes of illustration and description. It is not intended to be exhaustive or to limit the scope to the precise form disclosed. Further modifications and equivalents will be apparent to those skilled in the art in view of this description.

[0400] Embodiments were chosen and described in order to provide the best illustration of the principles of the teachings and their practical application, to enable other skilled in the art to understand various embodiments and the various modifications that are suited to the particular use contemplated. The scope of the invention is defined by the following claims and their equivalents.

Claims

1. A method comprising: Identify multiple usage rates corresponding to multiple cloud computing services, wherein the values ​​of the multiple usage rates can be modified over time; Generate a variable data structure that references a first set of values ​​for a first set of usage rates among the plurality of usage rates, wherein the variable data structure is modified in response to determining that the value of at least one usage rate in the first set of usage rates has changed; Generate a semi-immutable data structure that references a second set of values ​​for a second set of usage rates among the plurality of usage rates, wherein the semi-immutable data structure is not modified in response to determining that the value of any one of the usage rates in the second set of usage rates has changed; The variable data structure is associated with a first plurality of related parties in a first one-to-many relationship; The semi-immutable data structure is associated with a second plurality of related parties in a second one-to-many relationship; The variable data structure is referenced to determine the corresponding first set of applicable values ​​for service usage associated with the use of the plurality of cloud computing services by the first plurality of related parties, based on the first set of usage rates. as well as The semi-immutable data structure is referenced to determine the corresponding second set of applicable values ​​for services associated with a second plurality of related parties of the plurality of cloud computing services based on the second set of usage rates.

2. The method according to claim 1, further comprising: Identify the updated value or change of the first usage rate in the first group of usage rates; as well as Modify the variable data structure to add an updated usage rate corresponding to the first usage rate in the first group of usage rates, wherein the updated usage rate in the modified variable data structure references the updated value.

3. The method according to claim 1, further comprising: Identify the updated value or change of the first usage rate in the second set of usage rates; as well as A new semi-immutable data structure is generated, the new semi-immutable data structure including a semi-immutable data structure with an updated usage rate corresponding to the first usage rate in the second set of usage rates, wherein the updated usage rate in the new semi-immutable data structure references the updated value.

4. The method according to claim 1, further comprising: Identify new usage rates for new cloud computing services that are not included in the plurality of cloud computing services; Modify the variable data structure to add a new usage rate corresponding to the use of the new cloud computing service, wherein the new usage rate in the modified variable data structure references the value of the new usage rate of the new cloud computing service; Generate a new semi-immutable data structure, the new semi-immutable data structure including a semi-immutable data structure ACP rate card with the new usage rate corresponding to the use of the new cloud computing service added, wherein the new usage rate in the new semi-immutable data structure references the value of the new usage rate of the new cloud computing service; The modified variable data structure is used to determine the value of the new usage rate of the new cloud computing service used by the service associated with the use of the new cloud computing service by the first plurality of related parties; and The semi-immutable data structure is used to determine the value of the new usage rate of the new cloud computing service used by the service associated with the use of the new cloud computing service by the first plurality of related parties.

5. The method according to claim 1, further comprising: Receive new affiliates or subscriptions related to one of the plurality of cloud computing services; The value of the usage rate for the new affiliate's access to one of the plurality of cloud computing services is determined to be one or more values ​​from either the first set of usage rates or the second set of usage rates; and one of the following: The new associated party is associated with the variable data structure based on the usage rate value of the new associated party's access to one of the plurality of cloud computing services, which includes one or more of the first set of usage rates; or The new associate is associated with the semi-immutable data structure based on the usage rate of the new associate's access to one of the plurality of cloud computing services, including one or more of the second set of usage rates.

6. The method according to claim 1, further comprising: Based on a first subscription feature or operator domain associated with the first associated party in relation to the service use of the plurality of cloud computing services deployed in the cloud computing infrastructure, the first associated party or subscription is determined to be associated with the variable data structure. as well as Based on the second subscription characteristics of the second associated party among the second plurality of associated parties relative to the plurality of cloud computing services deployed in the cloud computing infrastructure, it is determined that the second associated party or subscription is associated with the semi-immutable data structure.

7. The method according to claim 1, further comprising: Receive a new associate related to one of the plurality of cloud computing services; Determine whether the usage rate for the new affiliate's access to one of the plurality of cloud computing services includes one or more of the first set of usage rates or the second set of usage rates; and Based on the fact that the usage rate for the new associated party's access to one of the multiple cloud computing services is neither the first set of usage rates nor the second set of usage rates, a new semi-immutable data structure is generated.

8. A system comprising: One or more computers, including one or more microprocessors; A cloud environment running on one or more of the computers; Multiple services deployed within one or more domains of the cloud environment; as well as A ratecard service operable in the domain of a cloud environment controlled by a cloud infrastructure provider, the ratecard service being able to operate in the following ways: Identify multiple usage rates corresponding to multiple cloud computing services, wherein the values ​​of the multiple usage rates can be modified over time; Generate a variable data structure that references a first set of values ​​for a first set of usage rates among the plurality of usage rates, wherein the variable data structure is modified in response to determining that the value of at least one usage rate in the first set of usage rates has changed; Generate a semi-immutable data structure that references a second set of values ​​for a second set of usage rates among the plurality of usage rates, wherein the semi-immutable data structure is not modified in response to determining that the value of any one of the usage rates in the second set of usage rates has changed; The variable data structure is associated with a first plurality of related parties in a first one-to-many relationship; The semi-immutable data structure is associated with a second plurality of related parties in a second one-to-many relationship; The variable data structure is referenced to determine the corresponding first set of applicable values ​​for service usage associated with the use of the plurality of cloud computing services by the first plurality of related parties, based on the first set of usage rates. as well as The semi-immutable data structure is referenced to determine the corresponding second set of applicable values ​​for services associated with a second plurality of related parties of the plurality of cloud computing services based on the second set of usage rates.

9. The system of claim 8, wherein the rate card service is further operable to: Identify the updated value or change of the first usage rate in the first group of usage rates; and Modify the variable data structure to add an updated usage rate corresponding to the first usage rate in the first group of usage rates, wherein the updated usage rate in the modified variable data structure references the updated value.

10. The system of claim 8, wherein the rate card service is further operable to: Identify the updated value of the expired value of the first usage rate within the second set of usage rates; and A new semi-immutable data structure is generated, the new semi-immutable data structure including a semi-immutable data structure with an updated usage rate corresponding to the first usage rate in the second set of usage rates, wherein the updated usage rate in the new semi-immutable data structure references the updated value.

11. The system of claim 8, wherein the rate card service is further operable to: Identify new usage rates for new cloud computing services that are not included in the plurality of cloud computing services; Modify the variable data structure to add the new usage rate corresponding to the use of the new cloud computing service, wherein the new usage rate in the modified variable data structure references the value of the new usage rate of the new cloud computing service; Generate a new semi-immutable data structure, the new semi-immutable data structure including a semi-immutable data structure ACP rate card with the new usage rate corresponding to the use of the new cloud computing service added, wherein the new usage rate in the new semi-immutable data structure references the value of the new usage rate of the new cloud computing service; The modified variable data structure is used to determine the value of the new usage rate of the new cloud computing service used by the service associated with the use of the new cloud computing service by the first plurality of related parties; and The semi-immutable data structure is used to determine the value of the new usage rate of the new cloud computing service used by the service associated with the use of the new cloud computing service by the first plurality of related parties.

12. The system of claim 8, wherein the rate card service is further operable to: Receive new affiliates or subscriptions related to one of the plurality of cloud computing services; The value of the usage rate for the new affiliate's access to one of the plurality of cloud computing services is determined to be one or more values ​​from either the first set of usage rates or the second set of usage rates; and one of the following: The new associated party is associated with the variable data structure based on the usage rate value of the new associated party's access to one of the plurality of cloud computing services, which includes one or more of the first set of usage rates; or The new associate is associated with the semi-immutable data structure based on the usage rate of the new associate's access to one of the plurality of cloud computing services, including one or more of the second set of usage rates.

13. The system of claim 8, wherein the rate card service is further operable to: Based on the first subscription characteristic of a first associated party among a plurality of associated parties relative to the plurality of cloud computing services deployed in the cloud computing infrastructure, it is determined that the first associated party is associated with the variable data structure; and Based on the second subscription characteristic of the second associated party relative to the multiple cloud computing services deployed in the cloud computing infrastructure, the second associated party is determined to be associated with the semi-immutable data structure.

14. The system of claim 8, wherein the rate card service is further operable to: Receive a new associate related to one of the plurality of cloud computing services; Determine whether the usage rate for the new affiliate's access to one of the plurality of cloud computing services includes one or more of the first set of usage rates or the second set of usage rates; and Based on the fact that the usage rate for the new associated party's access to one of the multiple cloud computing services is neither the first set of usage rates nor the second set of usage rates, a new semi-immutable data structure is generated.

15. A non-transitory computer-readable storage medium having instructions thereon, which, when executed in a computer system including a processor, cause the computer to perform a method, the method comprising: Identify multiple usage rates corresponding to multiple cloud computing services, wherein the values ​​of the multiple usage rates can be modified over time; Generate a variable data structure that references a first set of values ​​for a first set of usage rates among the plurality of usage rates, wherein the variable data structure is modified in response to determining that the value of at least one usage rate in the first set of usage rates has changed; Generate a semi-immutable data structure that references a second set of values ​​for a second set of usage rates among the plurality of usage rates, wherein the semi-immutable data structure is not modified in response to determining that the value of any one of the usage rates in the second set of usage rates has changed; The variable data structure is associated with a first plurality of related parties in a first one-to-many relationship; The semi-immutable data structure is associated with a second plurality of related parties in a second one-to-many relationship; The variable data structure is referenced to determine the corresponding first set of applicable values ​​for service usage associated with the use of the plurality of cloud computing services by the first plurality of related parties, based on the first set of usage rates. as well as The semi-immutable data structure is referenced to determine the corresponding second set of applicable values ​​for services associated with a second plurality of related parties of the plurality of cloud computing services based on the second set of usage rates.

Images