WO2014165967A1 - Procédé et système de gestion de portails de nuage et système de facturation associé - Google Patents

Procédé et système de gestion de portails de nuage et système de facturation associé Download PDF

Info

Publication number
WO2014165967A1
WO2014165967A1 PCT/CA2014/000324 CA2014000324W WO2014165967A1 WO 2014165967 A1 WO2014165967 A1 WO 2014165967A1 CA 2014000324 W CA2014000324 W CA 2014000324W WO 2014165967 A1 WO2014165967 A1 WO 2014165967A1
Authority
WO
WIPO (PCT)
Prior art keywords
billing
customer
cloud
entity
computing device
Prior art date
Application number
PCT/CA2014/000324
Other languages
English (en)
Inventor
Cherylynn GRANT
Daniel Monteiro FERREIRA
Original Assignee
Cloud Carte Inc.
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Cloud Carte Inc. filed Critical Cloud Carte Inc.
Publication of WO2014165967A1 publication Critical patent/WO2014165967A1/fr

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/02—Details
    • H04L12/14—Charging, metering or billing arrangements for data wireline or wireless communications
    • H04L12/1403—Architecture for metering, charging or billing
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q30/00—Commerce
    • G06Q30/04—Billing or invoicing
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04M—TELEPHONIC COMMUNICATION
    • H04M15/00—Arrangements for metering, time-control or time indication ; Metering, charging or billing arrangements for voice wireline or wireless communications, e.g. VoIP
    • H04M15/43—Billing software details
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/02—Details
    • H04L12/14—Charging, metering or billing arrangements for data wireline or wireless communications
    • H04L12/1428—Invoice generation, e.g. customization, lay-out, database processing, algorithms for calculating the bill or formatting invoices as WWW pages
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/02—Details
    • H04L12/14—Charging, metering or billing arrangements for data wireline or wireless communications
    • H04L12/1432—Metric aspects
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04M—TELEPHONIC COMMUNICATION
    • H04M15/00—Arrangements for metering, time-control or time indication ; Metering, charging or billing arrangements for voice wireline or wireless communications, e.g. VoIP
    • H04M15/44—Augmented, consolidated or itemized billing statement or bill presentation

Definitions

  • the present disclosure generally relates to cloud/hosted computing solutions, and in particular relates to the management of cloud/hosted products purchased by a customer.
  • the present disclosure relates to a billing system that may be included with the cloud/hosted computing solutions.
  • Cloud and Hosting environments are becoming increasingly popular with many businesses globally.
  • Many of these technology solution providers provide portals for customers to login and manage their own services.
  • the customer may not leverage all the services from one provider; in this case they would use other providers for different offerings, which would mean multiple provider portals, logins, passwords, reports, ticket submissions, bills, etc.
  • Figure 1 is a block diagram showing exemplary system architecture for a cloud portal manager system.
  • Figure 2 is a block diagram showing the logical components of the cloud portal manager system.
  • Figure 3 is a block diagram showing the processes for the purchasing of a cloud product subscription.
  • Figure 4 is a data flow diagram for a cloud product subscription provisioning request.
  • Figure 5 is a data flow diagram showing a process for obtaining cloud product subscription details.
  • Figure 6 is a block diagram showing processes for setting a customer's workspace domain name.
  • Figure 7 is a data flow diagram showing a process for setting a customer workspace domain name.
  • Figure 8 is a data flow diagram showing an account payment process.
  • Figure 9 is a block diagram showing a process for consolidating billing.
  • Figure 10 is a block diagram showing application components of a billing system
  • Figure 11 is a process diagram showing a process for generating intermediary values based on a variety of inputs
  • Figure 12 is a process diagram showing a multi-tiered processing of service inputs
  • Figure 13 is a process diagram for billing
  • Figure 14 is process diagram showing a rules based engine applying rules for both a customer and line items
  • Figure 15 is an architectural diagram showing the deployment of a cloud portal manager system.
  • the present disclosure provides a method at a computing device containing a rules based billing system, the method comprising: retrieving, for each billable entity, entity processing rules for the billing entity from memory on the computing device; applying, for the billing entity, the entity processing rules at a processor of the computing device; obtaining, for each billing item associated with the billing entity, billing item processing rules for the billing item from memory on the computing device; calculating, for each billing item, an amount based the billing item processing rules at a processor of the computing device; and generating an invoice based on the applying and calculating.
  • the present disclosure provides a computing device containing a rules based billing system, the computing device comprising a processor configured to: retrieve, for each billable entity, entity processing rules for the billing entity from memory on the computing device; apply, for the billing entity, the entity processing rules at a processor of the computing device; obtain, for each billing item associated with the billing entity, billing item processing rules for the billing item from memory on the computing device; calculate, for each billing item, an amount based the billing item processing rules at a processor of the computing device; and generate an invoice based on the applying and calculating.
  • the present disclosure provides a method at a server having a billing scheduler module for a service portal comprising a plurality of services, the method comprising: obtaining all accounts for the plurality of services; determining all subscriptions from the accounts; for each subscription, finding consumption details and creating a distributor bill based on the consumption details; adding a distributor markup and creating a partner's bill; and adding a partner markup and creating a customer bill; and consolidating all distributor bills, partner bills and customer bills to create a single bill for each distributor, partner and customer of the service portal.
  • the present disclosure further provides a server comprising a billing scheduler module for a service portal having a plurality of services, the server further comprising a processor configured to: obtain all accounts for the plurality of services; determine all subscriptions from the accounts; for each subscription, find consumption details and creating a distributor bill based on the consumption details; add a distributor markup and creating a partner's bill; and add a partner markup and creating a customer bill; and consolidate all distributor bills, partner bills and customer bills to create a single bill for each distributor, partner and customer of the service portal.
  • Embodiments of the present disclosure provide a solution to serve as an alternative to customer's multiple service providers cloud/hosting portals.
  • aspects of the present disclosure provide a single cloud portal manager application for the customer to manage and maintain all of their cloud/hosted solutions from service providers.
  • the embodiments of the present disclosure consist of a username, password and security question to login to the main dashboard of a Cloud Portal Manager (CPM) page. This page provides a snapshot of all the cloud/hosted services the business currently has with a single provider or multiple providers.
  • CPM Cloud Portal Manager
  • a first aspect of the present disclosure provides customers the ability to manage all their services from one single portal workspace.
  • a consolidated portal service provider may set up the customer's administrator account at an initial contract stage. When an administrator of the customer first logs into the portal, they will be prompted to change password and enter security questions for identity verification purposes; then the administrator is granted access to the customer's workspace. The administrator may then update a password and add additional user access fields for executives, marketing and other IT staff, among others.
  • the administrator user may have the ability to restrict specific views for the additional users in the organization.
  • the administrator user can update all user names & passwords, contact information, titles, authorizations, submit tickets and has full access to all the cloud/hosted subscriptions linked to the customer.
  • a history and activity log of all user logins, changes, for tracking of user activity may be provided.
  • the consolidated portal service provider may have the ability to make changes or update the customer's workspace if the main administrator account is not available. Further, the consolidated portal service provider may provide additional backup to the business or customer. .
  • a second aspect of the present disclosure provides an agnostic dashboard with all existing subscriptions that a customer has with cloud/hosting providers.
  • This application allows the customer to simply login and view all of their existing subscriptions at a glance from any provider.
  • This page can only be viewed once the administrator has updated their profile page, and changed password and identity questions. The view on this page has thumbnails from the various cloud/hosted services providers and provides a small status of their service.
  • the customer has a thumbnail for all the services that they have subscribed for, either through the consolidated portal service provider, as described below, or independent from the consolidated portal service provider.
  • the view shows a thumbnail for various services, including but not limited to, ExchangeTM/Email, Cloud Infrastructure as a Service or Virtual Appliances, Security, Financial, Telecom, Cloud Storage, calendar for renewals/Updates and Recent site Activity.
  • the left hand side a tool bar has links that may remain permanently on each page.
  • such tool bar may include: LOGO, Solution Upgrades, My Portal for user changes, contract agreements & statements of work (SOW) for services, Marketing (for Campaigns, Ads, Training, Seminars, Promotions), Section for Advertising.
  • the following may be included: Welcome customer and company name, site tips, last login date, Urgent announcements from providers, upgrades or updates from service providers or site upgrades. This page allows the user/customer to view all of their services and manage any changes that are required
  • a third aspect of the present disclosure provides the customer the ability to click on a subscription thumbnail for a more in depth view of their existing subscription. For example if the user clicks on the ExchangeTM/Email thumbnail they will have a full view of their contracted services with their provider.
  • the customer may then make changes to user emails, increase or decrease users, edit users, view utilization, downloads, suspend users, change email packages, subscribe to new services, view all users data, add backup, allocate user information, manage services, change task, view spam filters.
  • the customer can make the changes and save before exiting this service provider and returning to the dashboard or exiting the application.
  • the customer clicks on the Infrastructure as a Service thumbnail the click will bring the customer to a more in-depth view of the customer's Cloud Infrastructure.
  • the customer may be able to see all of its virtual servers, storage, RAM, networking, public or private, additional resources, fail-over sites, status of existing services and upgrade to additional services.
  • the customer may be able to submit tickets to add additional virtual appliances, storage, RAM and see the pricing for these additional resources.
  • the customer may have the ability to pull up their service provider agreements on this page or from the dashboard. All announcements for service disruptions may be notified by the provider and the consolidated portal application may display these updates for its customers in the consolidated portal application for simplicity.
  • a fourth aspect of the present disclosure provides a method for managing the financial aspect of the customer services with multiple providers.
  • the customer may have the ability to view its services by clicking on the thumbnail to view their existing services with providers and break the services down to selected categories for reporting capabilities. For example, all signed agreements and statement of works can be accessed from this page as well as the user portal link on the tool bar.
  • the customer may use the fourth aspect to view the service start and end date, total monthly spend, term of agreement, terms and conditions, run all reports on services, audits, financial savings, select to pay bills in the portal, calendar showing upcoming renewals, electronic signatures for agreements, extra usage charges, import and export to a spreadsheet, graphs & charts, billing history, request for billing department and previous spending years with providers. Further, providing the financial history of a business's technology spend monthly, quarterly or annually may help executives with future decision making processes.
  • a fifth aspect of the present disclosure provides a method for managing a marketing strategy for customers or partners of the consolidated portal service provider who would like to white label/resell the consolidated portal application.
  • the marketing section may have ongoing advertisements on the toolbar sections that the customer can see once they login to the portal.
  • This section of the portal may show upcoming events, new product release, discounts, specials, seminars, conferences, service provider new products and purchase portal themes.
  • the customer can click on the advertisement or go to the solution upgrade tab on the left hand tool bar for more information.
  • the customer can register for events, webinars, and training from the marketing section of the portal. Providing this option allows the customer the ability to sign up to cloud/hosting events, upgrade/downgrade service offerings and leverage additional savings from providers.
  • a billing system utilizes rules for one or both of the customer and/or the billing item to provide for an individualized bill that can accommodate any situation.
  • the billing system may be used with the cloud services based embodiments. However, the billing system could further be used on its own or in combination with other types of services, and the present disclosure is not limited to the billing system being associated with the cloud services embodiments.
  • FIG. 1 shows a simplified architectural diagram for a cloud portal manager 110.
  • Cloud portal manager 110 is, in accordance with one embodiment of the present disclosure, an Enterprise, Portal- based application designed to simplify and facilitate the management of cloud products purchased by a customer.
  • customers such as users 120, 122 and 124 from Figure 1
  • customers can purchase new products in the form of subscriptions, obtain detailed information of each subscription they have purchased, such as usage and/or number of resources allocated to the customer, and extract statistical and financial reports.
  • customers may also cancel subscriptions of products individually or terminate their accounts altogether.
  • Cloud portal manager 110 is capable of provisioning and extracting management information from cloud products by connecting to Cloud Providers' interfaces and web services.
  • Cloud providers 130, 132 and 134 are shown, but this is not meant to be limiting and any number of cloud providers can be used within the system of the present disclosure.
  • Cloud providers typically expose interfaces consumed by their own management solutions.
  • One purpose of cloud portal manager 110 is to leverage interfaces for the various products offered by several cloud providers and give the customer a simple, easy to use workspace where they can manage all products to which they subscribe from one single location.
  • Cloud products purchased by customers through cloud portal manager 110 provide Infrastructure as a Service (laaS), a model which customers pay periodically based on a fixed, recurring amount (for instance, a monthly fee) and/or based on the usage or consumption of those products, when applicable.
  • Cloud portal manager 110 may also be a Software as a Service (SaaS) solution.
  • SaaS Software as a Service
  • customers need to create user accounts which are bound to subscriptions. Through these subscriptions customers are charged a recurring amount in exchange of being granted the permission to manage their products and purchase new ones.
  • Payment service 140 may be a remote system to which cloud portal manager 110 connects and may be implemented by a third party or a partner. In other embodiments payment service 140 may be part of could portal manager 110. Whenever the customer's billing cycle ends, cloud portal manager 110 invokes the payment service 140 to charge the customer. Customer billing is calculated by the purchased cloud products and services. Cloud portal manager 110 then conciliates the amount that the customer owes into one single, detailed bill. Such billing is described further below.
  • cloud portal manager 110 Another feature that may be provided by cloud portal manager 110 is domain name maintenance.
  • the cloud portal manager 110 acts as a broker to Domain Name Service (DNS) providers 150 and allows customers to purchase and manage domains from the user interface of cloud portal manager 110.
  • DNS Domain Name Service
  • This feature makes DNS maintenance in cloud portal manager 110 an laaS product similar to services offered by Cloud Providers and could be regarded as yet another cloud product.
  • the ability to use a domain purchased by the customer to route the customer to their cloud portal manager workspace is also a feature of the cloud portal manager 110.
  • the customer wishes to do so they can configure a domain so that, when they type that domain from a web browser, they are redirected to their workspace in the cloud portal manager 110.
  • a signature service 160 may be used by cloud portal manager 110 to authenticate customers, such as users 120, 122 or 124, cloud providers such as cloud providers 130, 132 or 134, or other service providers such as payment service 140 or DNS provider 150.
  • a client 120 represents the customer's computer as the user interface to the cloud portal manager 110 application.
  • the application is web- based. That is, the customer uses the web browser of their choice to access the portal. The choice of the browser implementation is beyond the scope of this specification. Other options are however possible, and while the present disclosure uses a web-based application for illustrative purposes, non-web based applications could also be used.
  • FIG. 2 When the client browser 210 creates a hypertext transfer protocol (HTTP) request to cloud portal manager 110, the response is a set of hypertext markup language (HTML) 214; JavaScript 216 and/or cascading style sheets (CSS) 218 files that form the Cloud Portal Manager's user interface, also known as the Cloud Portal Manager Front-End 212.
  • HTML hypertext markup language
  • CSS cascading style sheets
  • the JavaScript code when loaded by the browser, may also make Ajax calls to Restful web services exposed by Cloud Portal Manager. In that case the body of the request and response is composed of JavaScript Object Notation (JSON) streams.
  • JSON JavaScript Object Notation
  • Cloud portal manager 110 is the Enterprise application that is the main subject of this specification. It is hosted by a portal container 220 and uses such infrastructure to function properly.
  • the portal container provides the basic infrastructure necessary for the application to run. Elements of the infrastructure are the maintenance of user accounts, websites and web pages; security and access control; and the capacity to render pages and portlets wired into them.
  • Cloud Portal Manager functions as a broker to manage Cloud and DNS products by connecting to cloud providers 130, provisioning products and extracting information. It is also capable of charging customers based on their subscriptions and resource consumption.
  • the client browser 210 connects to portal container 220 through one or more portlets 222 or servlets 224.
  • the portlets 222 or servlets 224 interface with a cloud portal manager back end 230 through a web controller 232.
  • An account manager 234 communicates with web controller 232 and further communicates with various adaptors, including a database adaptor 240, a payment adaptor 242, a provider manager 250 which includes various provider managers 252, a signature adaptor 260, and a DNS adaptor 262. Account manager 234 further communicates with an account provisioning service 270. Each of these components is described in more detail below.
  • a cloud provider 130 is the third party vendor of a cloud product. Examples of cloud products are email services, virtual servers and appliances, network connectivity, Network-Attached Storage (NAS), backup solutions, security solutions and others. Cloud providers 130 offer web services and other types of interfaces that allow client applications to provision and manage products.
  • cloud products are email services, virtual servers and appliances, network connectivity, Network-Attached Storage (NAS), backup solutions, security solutions and others.
  • Cloud providers 130 offer web services and other types of interfaces that allow client applications to provision and manage products.
  • Cloud portal manager 110 and specifically portal container 220, contains various provider adapters 252, each of which is responsible to connect to a specific cloud provider interface and execute operations on it.
  • the implementation details of the cloud providers' applications and interfaces are outside the scope of the present description.
  • the DNS Provider 150 is responsible to register a domain name in the Domain Name Service registry so that it can be referenced as an Internet address.
  • Cloud portal manager 110 allows customers to purchase domains and register them in the DNS registry by connecting to the DNS Provider's provisioning interface through a DNS Adapter 262. Once provisioned, the domain subscription is added to the customer's billing information so that they can be charged properly.
  • Cloud Portal Manager 110 connects to a payment service 140 in order to charge customers when their billing cycle is over and therefore their bill is due.
  • a payment service may be a third party application through which customers makes payments in order to use their cloud portal manager workspace and cloud products.
  • the cloud portal manager application connects and sends payment requests to an interface of the payment service through a payment adapter 242.
  • the choice of the payment service vendor and its implementation details are outside of the scope of this description.
  • An electronic signature is an electronic means to create a digital version of a signature that can be associated to a person or entity.
  • the use of an e-signature in a digital document associates the document to the person or entity so that they can be regarded as the document's author or that they are bound to the document's terms.
  • the signature service 160 may be a third-party application that implements an e-signature solution.
  • Cloud portal manager 110 requires customers' e-signatures in order to sign up to a new account, to obtain new cloud product subscriptions or when a Statement of Work is submitted due to a customization need.
  • Cloud portal manager 110 communicates with the signature service's interface through a sigl 1 nature adapter 260. The choice of the signature service vendor and its implementation details are outside of the scope of this description.
  • Both the portal container 220 and cloud portal manager 110 rely on databases to persist data.
  • all the data may be stored in the cloud portal manager's database 280, whereas the portal container 220 stores the bare minimum amount of information for it to work properly.
  • the data stored in the portal container's database 290 depends on the vendor chosen, and is outside of the scope of this description.
  • the embodiments described herein are multi-tiered. That is, the solutions contain modules that run in different hosts given their purpose.
  • the user interface runs in the customer's browser 210 of choice.
  • the user interface may be called the cloud portal manager front-end 212.
  • the enterprise application is also known as the cloud portal manager back-end 230 and contains business logic, exposes web controllers to serve the cloud portal manager front-end 212 and contains the adapters to connect to third-party applications, including but not limited to cloud providers 130, payment service 140, DNS providers 150, among others.
  • the application's database is hosted by a Database Management System (DMS) and provides data persistence.
  • DMS Database Management System
  • the contract between the cloud portal manager front-end 212 and the cloud portal manager back-end 230 may use the HTTP protocol in one embodiment. Consequently any HTTP-compliant browser is suitable to operate the application. The customer is free to use the browser of their choice. When applicable, the application may require that the browser supports HTTPS in addition to HTTP to provide security and data integrity. Further, Cloud Portal Manager Versions may include client applications for mobile devices. The communication between these client applications and the Back-End will typically also comply with the HTTP protocol.
  • the cloud portal manager front-end 212 is the module that corresponds to the application's front-end tier and implements the user interface. It includes all views, fields and components that make the interaction between the customer and the application possible. As a web-based solution, it is a graphical interface that uses the well-known, widely used technologies such as HTML, JavaScript and CSS.
  • the Hyper-Text Markup Language is the technology used by cloud portal manager 110 to render the user interface.
  • Web browsers can process the HTML document included in a cloud portal manager response and display it on the customer's screen or play multimedia files included in it.
  • Cloud portal manager views are composed mainly of browser objects derived from HTML elements.
  • JavaScript is a programming language that can be interpreted and executed by web browsers.
  • Cloud portal manager 110 uses JavaScript programs to implement the user interface behavior.
  • the application's JavaScript module responds to user input and processes it by executing validation, sending requests to the cloud portal manager back-end 230 and processing its responses.
  • the JavaScript module can also dynamically change the view by adding or removing HTML elements and enabling or disabling them.
  • Cascading Style Sheet is a language that describes the presentation semantics of documents written in a markup language such as HTML. Its purpose is to define the style, or look-and-feel, of web pages, including elements such as layouts, colors and font types. CSS facilitates the separation of content from presentation.
  • Cloud portal manager 110 uses CSS as the language that defines how its view is presented to the customer.
  • the portal container 220 is the underlying platform that provides the basic infrastructure services that allow cloud portal manager 110 to operate.
  • cloud portal manager 110 is an Enterprise application and thus may require the portal container 220 to be an Enterprise Application Server.
  • Services that cloud portal manager 110 may require from an Enterprise Application Server include, but are not limited to:
  • the Portal Container must provide the following features to Cloud Portal
  • Website maintenance create, retrieve, update, delete, activation, deactivation
  • Portal containers 220 are implemented and distributed by different vendors.
  • Portlets 222 are pluggable user interface components that can be rendered and processed by a portlet container 220. Portlet 222 processing typically produces markup code that is aggregated into a web page. Portlets 222 may also trigger services provided by the application. In fact, some cloud portal manager front-end 212 components may use portlets 222 to send cloud product provisioning requests to the cloud portal manager back-end 230.
  • the portlet 222 implementation which is provided by the portal container 220, delegates control to the application code via web controllers 232. More information on portlets may be found in the Java Portlet API Specification v2.0, JSR-286. However, other technologies could be used.
  • Servlets 224 are components used by Web Application Servers to process user requests. They are widely used by applications due to the server's ability to use servlets 224 to delegate control to application code.
  • HTTP Servlets are components that can handle HTTP requests, which can be created and sent by web browsers. The choice of the servlet 224 implementation is typically done through the analysis of the request URL.
  • cloud portal manager 110 uses HTTP servlets to expose Restful web services that process Ajax requests created by the cloud portal manager front-end 212 JavaScript module 216.
  • the servlet 224 then delegates control to the application code via web controllers 232.
  • a .NET framework for JAVA may be used to create the above. More information on servlets may be found in the Java Servlet API Specification v3.0, JSR-315. However, other technologies could be used.
  • cloud portal manager 110 may need to provide basic information to the portal container 220 to ensure the features of portal container 220 work properly.
  • the account provisioning service is the abstraction of the Application Programming Interface (API) provided by the portal container 220 to maintain the customer accounts on the Portal. This API includes operations such user, website and page maintenance, and domain name to customer workspace mapping.
  • API Application Programming Interface
  • the account manager sub-module 234 communicates with the Account Provisioning Service and is vendor-dependent. Therefore different adapters are implemented per vendor. Based on the vendor that is chosen to become the application's portal container 220, a specific adapter is chosen.
  • the portal database 290 is responsible to persist the portal container- specific data.
  • the cloud portal manager back-end 230 is an application that runs as a web module in the portal container 220. It encapsulates the cloud portal manager back-end 230 components, processes and services that implement cloud portal manager 110 functionality.
  • the cloud portal manager back-end 230 is a three- layered application.
  • the service facade layer consists of web controllers 232, making the application a service provider.
  • the business service layer is composed of the account manager 234 and contains all business rules.
  • the data access layer is formed by the various adapters shown in Figure 2, making it a client to third-party applications and APIs.
  • the boundary of the cloud portal manager back-end 230 is drawn by web controllers 232 in one end and the adapters in the other.
  • the cloud portal manager 110 can be regarded as a hub to cloud products, allowing customers to manage the services they purchase from a centralized location.
  • the cloud portal manager 110 is a facilitator that brings simplicity and ease-of-use.
  • the web controllers are the entry points to the Back-End and are designed to serve the Front-End. There are two types of Web Controllers:
  • Actions are triggered by portlet 222 implementations. Their purpose is to interact with users in the form of wizards, that is, navigation among different views to execute a use case or achieve a goal.
  • Web Services Endpoints are triggered by servlets 224 that implement Restful Web Services.
  • Restful Web Services please refer to JAX-RS: the Java API for RESTful Web Services, also known as JSR-31 1. Endpoints are designed for system-to-system integration and do not support wizards. Again, a .NET framework over Java could be used for this.
  • the output may be a message to be displayed to the customer in case of Actions or JSON streams that go in the HTTP response body in case of Web Service Endpoints.
  • the account manager 234 is the application's orchestrator. It is responsible for controlling all request processing, whether it is a request to provision a customer's subscription for a cloud product or obtaining usage or financial information about a certain subscription. To do so, account manager 234 is able to delegate control to the provider manager 250, the cloud portal manager database adapter 240, the account provisioning service 270, the payment adapter 242 and the DNS adapter 262 in the embodiment of Figure 2.
  • the account manager 234 is an orchestrator in the sense that it is able to delegate (orchestrate) control to the modules above by following the business rules of the functionality being executed.
  • the account manager 234 also controls the transaction that governs the subscription provisioning. The request processing is described in below with reference to Figure 3.
  • a billing sub-module is part of the account manager. It has a batch process that executes whenever the user's billing cycle ends. It conciliates the billing information from all the customer's subscriptions and creates a unified bill with details of consumption and fees related to all cloud products to which the customer has subscribed. The account manager then calculates the total amount and invokes the payment adapter 242 to charge the user.
  • the billing sub-module also supports not charging the customer for a certain subscription in case they decide to pay the subscription's cloud provider 130 directly.
  • Cloud portal manager 110 may persist information for proper functionality in one embodiment.
  • the information is therefore stored in a database 280.
  • the database adapter 240 is responsible for connecting to the database 280 to retrieve and persist data requested by the account manager 234.
  • the database 280 is the location where cloud portal manager 110 stores the information it processes. It may contain information such as, but not limited to:
  • the payment adapter 242 is invoked by the account manager's billing sub- module to charge users for their subscriptions. Every customer account has a payment type which defines how the customer wishes to pay for those subscriptions. The payment type depends on the payment service 140 vendor chosen and therefore cloud portal manager 110 supports any payment type as long as the specific adapter is implemented.
  • the signature adapter 260 is invoked by the account manager 234 whenever the customer is required to provide a signature.
  • Signature adapters provide a bridge between cloud portal manager 110 and signature service 160 vendors. Whenever a new vendor is chosen, signature adapter 260 may be implemented in order to interface with it.
  • the provider manager 250 is a pool of provider adapters 252.
  • the function of provider manager 250 is to return to the account manager 234 the provider adapter 252 suitable for the cloud product that is the subject of the customer's subscription. For instance, when the customer requests to subscribe to a cloud product, the account manager 234 informs the provider manager 250 the cloud product in question. The provider manager 250 then returns the correct provider adapter 252 to the account manager 234 so that the provisioning operation can be performed by the cloud provider 130.
  • Each cloud provider 130 supported by cloud portal manager 110 has a provider adapter 252 counterpart responsible for the communication between the application and the provider.
  • provider adapters 252 cloud portal manager 110 is capable to create, update and cancel subscriptions as well as retrieve information such as consumption and billing.
  • Implementations vary depending on the type of interface defined by the cloud provider 130. However, all implementations have the purpose of connecting to and invoking operations on the provider.
  • the contract between an adapter and the account manager 234 is unique. That is, all provider adapters 252 need to communicate with the account manager 234 through the same interface. This makes cloud portal manager 110 provider-agnostic and consequently provides a holistic subscription management process.
  • the DNS adapter 262 is responsible for connecting to the DNS provider 150 and to invoke operations to register or unregister domain names on behalf of the customer. In one embodiment, the mapping of a domain name to the customer's workspace in cloud portal manager 110 is not performed by the DNS adapter 262 but by the account provisioning service 270.
  • the actor of the following use cases is a customer that owns a cloud portal manager 110 account.
  • Figure 3 shows a use case which describes the process of purchasing a subscription to a cloud product. It is a multipart use case and includes other use cases (described below) as part of the procedure. It is assumed that the customer 310 has already authenticated and has access to their workspace.
  • the customer 310 accesses the cloud portal manager products page and accesses the functionality to purchase a new cloud product.
  • the purchase may include selection of a form of payment, as shown at block 330, signing terms and conditions, as shown at block 340, and/or provisioning of a cloud product subscription, as shown at block 350. Each is described below.
  • Product types define what kind of service the product provides. Examples of product types are “Storage”, “Network”, “Virtual Appliances”, “Security”, “Email”. The customer chooses a product type.
  • a list of sub-types may be presented to the customer based on the product type chosen.
  • “Virtual Appliances” sub-types may include “Servers”, “Routers”, “Load Balancers” while “Security” sub-types may include “Firewalls”, “Anti-Virus”, “Intrusion Detectors”. If the list of sub-type is presented, then the customer may choose a product sub-type.
  • the list of cloud products that match the chosen type and sub-type may then be presented to the customer.
  • the list contains information such as name, vendor, description and price.
  • the customer then chooses the cloud product. Based on the choice, the form of payment is selected at block 330, the terms and conditions are signed at block 340 and the cloud product subscription is provisioned in block 350.
  • Payment types may include (but are not limited to) "Credit Card”, “Third- Party Payment Service” and “Pay Cloud Provider directly”. The customer selects the payment type.
  • cloud portal manager 110 delegates the payment registration to the payment service 140 vendor. If necessary, the customer may need to create a new payment account with the vendor. The vendor then returns the payment authorization to cloud portal manager 110.
  • a customer 310 may also choose to "Pay Cloud Provider directly". This option does not involve cloud portal manager 110 charging the customer for the cloud product usage. An informative message explaining the implications of paying the provider directly may be presented to the customer.
  • the customer 310 is presented with a Terms & Conditions document associated with the cloud product chosen.
  • a list of signature options may be presented to the customer. For example, the list may contain two options: sign digitally or sign hard copy. The customer 310 selects a signature option.
  • the customer 310 may be redirected to the signature service 160 vendor application to sign the document digitally.
  • the signature service 160 vendor stores the signed document and returns a serial code to cloud portal manager 110.
  • a link to download the document may be presented to the customer. The customer can then download, print and review the document. If accepted, the user signs the document and scans it. In one embodiment, the customer 310 can upload the scanned signed document to cloud portal manager 110. Cloud portal manager 110 may further submit the signed document to the signature service 160 vendor.
  • the signature service 160 vendor stores the signed document and returns a serial code to cloud portal manager 110.
  • Cloud portal manager 110 stores the serial code into the customer's account.
  • FIG. 4 shows a process diagram for a cloud product subscription provisioning request.
  • a user 310 communicates with a client browser 210.
  • client browser 210 may communicate with a portlet 222, which may communicate with a web controller 232.
  • web controller 232 may communicate with an account manager 234.
  • Account manager 234 may then communicate with various elements, including provider manager 250, provider adaptor 252, account provisioning service 270 and database adaptor 240.
  • the process of Figure 4 starts when the customer 310 activates the HTML control that submits the HTML form to provision the chosen cloud product's subscription, as shown by arrow 410.
  • the client browser 210 submits a HTTP request to cloud portal manager back-end 230, as shown by message 412.
  • the portlet 222 implementation (implemented by the portal container 220) intercepts the request of message 412.
  • Portlet 222 then analyses the request. In particular, the request input is extracted from the request body.
  • the suitable cloud portal manager web controller 232 is chosen. Control is delegated to the web controller 232, as shown by message 414.
  • the web controller 232 validates the input, as shown by arrow 416. If the validation fails, an error 418 is thrown, a detailed message is presented to the customer 310.
  • the web controller 232 converts the input into a format accepted by the account manager 234.
  • the web controller 232 delegates the execution to the account manager 234, passing the input, as shown by message 420.
  • the account manager 234 requests from the provider manager 250 the suitable provider adapter 252 based on the cloud product information present in the input, as shown by message 430.
  • the provider manager 250 returns the provider adapter 252 to the account manager 234, as shown by message 432.
  • the account manager 234 invokes the provider adapter 252 by passing the input, as shown by message 440.
  • the provider adapter 252 connects to the cloud provider's interface and sends the request to provision the customer's subscription to the cloud product.
  • the cloud provider processes the request, provisions the subscription and returns the outcome to the provider adapter 252 (not shown).
  • the provider adapter 252 returns the output of the provisioning request to the account manager 234, as shown by message 442.
  • the account manager 234 invokes the account provisioning service 270, passing the customer's subscription information, as shown by message 450.
  • the account provisioning service 270 stores the information in the portal container's database.
  • the account provisioning service 270 returns the customer provisioning outcome back to the account manager, 234, as shown by message 452.
  • the account manager 234 may then invoke the database adapter 240 to store the customer's subscription to the chosen cloud product into the cloud portal manager's database.
  • the invoking is shown by message 460 in the embodiment of Figure 4.
  • the database adapter 240 connects to the database 280 and stores the subscription. At this point the subscription is added to the customer's account and the billing cycle begins.
  • the database adapter 240 returns the execution back to the account manager 234.
  • the account manager 234 commits the transaction and at this point the provisioning operation is considered to be successful.
  • the account manager 234 returns the execution back to the web controller 232, passing the output, as shown by message 470.
  • the web controller 232 converts the output back to the same format of the input. A result message is also added to be displayed to the customer. The web controller returns the execution back to the portlet 222 implementation, as shown by arrow 472.
  • the portlet 222 implementation returns.
  • the portal container 220 writes the output into the response, which is then sent back to the browser 210, as shown by message 474.
  • the browser 210 renders the output in the form of a HTML screen, as shown by arrow 476.
  • the screen contains a detailed message and, if applicable, extra subscription details.
  • Each cloud product has a corresponding portlet to display the customer's subscription details associated to it.
  • the process to obtain these details may be the same across cloud products.
  • the difference is the provider adapter 252 that is returned by the provider manager 250, which is directly related to the subscription's cloud product.
  • the customer activates the HTML control that submits the HTML form to query the details of the cloud product's subscription, as shown by arrow 510.
  • the client browser 210 then submits a HTTP request to cloud portal manager back-end 230.
  • the portlet 222 implementation (implemented by the portal container 220) intercepts the request 512.
  • the request 512 is analyzed and the request search criteria are extracted from the request body.
  • the suitable cloud portal manager web controller 232 is chosen. Control is delegated to the web controller, as shown by arrow 514.
  • the web controller 232 validates the input. If the validation fails, an error 518 is thrown, and a detailed message is presented to the customer.
  • the web controller 232 converts the search criteria into a format accepted by the account manager 234.
  • the web controller 232 delegates the execution to the account manager 234, passing the search criteria, as shown by message 520.
  • the account manager 234 requests from the provider manager 250 the provider adapter 252 suitable to the cloud product, as shown by message 530.
  • the provider manager 250 returns the provider adapter 252 to the account manager 234, as shown by message 532.
  • the account manager 234 invokes the provider adapter 252, as shown by message 540, passing the search criteria.
  • the provider adapter 252 connects to the cloud provider's interface and sends the search criteria.
  • the cloud provider searches for the subscription and returns the details to the provider adapter 252 (not shown).
  • the provider adapter 252 returns the details to the account manager, as shown by message 542. The details are added to the output. [00117] If necessary, the account manager 234 invokes the account provisioning service 270, passing the search criteria, as shown by message 550. The account provisioning service 270 searches for the subscription details in the portal container's database.
  • the account provisioning service 270 returns the details to the account manager 234, as shown by message 552. The details are added to the output.
  • the account manager 234 invokes the database adapter 240, passing the search criteria, as shown by message 560.
  • the database adapter 240 connects to the cloud portal manager's database 280 and retrieves the corresponding details.
  • the database adapter 240 returns the details to the account manager 234, as shown by message 562. The details are added to the output.
  • the account manager 234 returns the output back to the web controller 232, as shown by arrow 570.
  • the web controller 232 converts the output back to the same format of the input. A result message may also added to be displayed to the customer. The web controller returns the execution back to the portlet 222 implementation, as shown by arrow 572.
  • the portlet 222 implementation returns.
  • the portal container 220 writes the output into the response, which is then sent back to the browser 210, as shown by message 574.
  • the browser 210 renders the output in the form of a HTML screen, as shown by arrow 576.
  • the screen contains the subscription details and, if applicable, a success message.
  • a customer 310 may set a customer workspace domain name at block 620. If necessary, this may involve the purchase of a domain name at block 630.
  • the Domain Name is a special cloud product. It is differentiated from other cloud products in the sense that it can be used by cloud portal manager as the customer's workspace address.
  • the cloud portal manager 110 may execute the purchase of a cloud product subscription, as described above.
  • the customer may choose "Domain Name".
  • all references to "Provider Adapter” therefore refer to a DNS adapter.
  • the customer may need to authenticate with the portal container 220.
  • the customer accesses the workspace configuration page.
  • the workspace configuration portlet is presented.
  • the customer may choose the option to define a Domain Name for the workspace.
  • the Domain Name Configuration form is presented.
  • a HTML component to purchase a new domain name is available, and the above process to purchase a domain name may be invoked if the customer selects this option.
  • the customer provides the domain name in the form and activates the HTML control that submits the HTML form to set the customer's workspace domain name, as shown by arrow 710.
  • the client browser 210 submits a HTTP request 712 to cloud portal manager back-end 230.
  • the portlet 222 implementation (implemented by the portal container 220) intercepts the request.
  • Request 712 is analyzed at portlet 222.
  • the domain name is extracted from the request body.
  • the suitable cloud portal manager web controller 232 is chosen. Control is delegated to the web controller 232, as shown at arrow 714.
  • the web controller 232 validates the domain name, as shown by arrow 716. If the validation fails, an error 718 is thrown, and a detailed message is presented to the customer.
  • the web controller 232 delegates the execution to the account manager 234, passing the domain name, as shown by message 720.
  • the account manager 234 invokes the account provisioning service 270, passing the domain name, as shown by message 730.
  • the account provisioning service 270 associates the customer's workspace to the domain name and stores the association in the portal container's database.
  • the account provisioning service 270 returns the execution back to the account manager 234, as shown by arrow 732.
  • the account manager 234 invokes the database adapter 240 to store the customer's workspace domain name into the cloud portal manager's database 280, as shown by message 740
  • the database adapter 240 connects to the database 280 and stores the domain name.
  • the database adapter 240 returns the execution back to the account manager, as shown by arrow 742.
  • the account manager 234 commits the transaction and at this point the provisioning operation is considered to be successful.
  • the account manager 234 returns the execution back to the web controller 232, as shown by arrow 770.
  • a result message is added to the output to be displayed to the customer 310.
  • the web controller 232 returns the execution back to the portlet 222 implementation, as shown by arrow 772.
  • the portlet 222 implementation returns.
  • the portal container 220 writes the output into the response 774, which is then sent back to the browser 210.
  • the browser 210 renders the output in the form of a HTML screen, as shown by arrow 776.
  • the screen contains a success message.
  • a billing scheduler 810 is the actor. It triggers the use case when the customer's billing cycle finishes, that is, the billing due date is reached.
  • the billing scheduler 810 and billing system as a whole could be part of the cloud portal manager.
  • the processes described herein for the billing subsystem could be a stand-alone system or used with other services.
  • the integration of the billing system into the cloud portal manager is therefore merely illustrative.
  • the billing due date is part of the customer's cloud portal manager account.
  • the account bill corresponds to the aggregation of the customer's portal cloud manager account subscription plus the subscription to all cloud products they have purchased.
  • cloud portal manager 110 processes the customer's account and generates a unified bill.
  • the amount that cloud portal manager charges the customer is the sum of all items in the bill that have as form of payment an option that involves cloud portal manager 110 in the payment process, as described above with regards to block 330 of Figure 3.
  • the billing scheduler 810 creates a RESTful Web Service request containing the customer account identifier and submits it to cloud portal manager 110, as shown with request 820.
  • the endpoint servlet 224 intercepts request 820 and the request is analyzed and a suitable web controller 232 is chosen.
  • the servlet 224 invokes the chosen web controller 232, passing the customer's account identifier, as shown by arrow 822.
  • the web controller 232 delegates the execution to the account manager 234, passing the customer's account identifier, as shown with message 824.
  • the account manager 234 invokes the database adapter 240, passing the customer's account identifier, as shown with message 830.
  • the database adapter connects to the cloud portal manager's database 280 and searches for the customer account details.
  • the details contain the customer's subscriptions, which include cloud product information.
  • the database adapter 240 returns the customer details to the Account Manager, as shown by message 832.
  • the account manager 234 requests from the provider manager 250 a provider adapter 252 that is suitable to the subscription's cloud product, as shown with message 840.
  • the provider manager 250 returns the suitable provider adapter 252, as shown by message 842.
  • the account manager 234 invokes the provider adapter 252, passing the subscription information, as shown by message 850.
  • the provider adapter 252 connects (not shown) to the cloud provider 130 and invokes the search operation.
  • the cloud provider 130 searches for the subscription information, which contains usage and other billing details, and returns it back to the provider adapter 252.
  • the provider adapter 252 returns the subscription details to the account manager 234, as shown by message 852.
  • the subscription details are added to the customer account details.
  • the process of messages 840, 842, 850 and 852 continues to loop for all subscriptions a customer has.
  • the account manager's billing sub-module conciliates all subscriptions and generates an unified bill, as shown by arrow 860.
  • the total payment amount is calculated as being the sum of the payment amounts of all subscriptions that have a payment type applicable to cloud portal manager 110.
  • a payment type is applicable to cloud portal manager 110 if it must send the amount to the payment service 140 in order to charge the customer.
  • one exemplary process at the billing manager sub-module is shown with regards to Figure 9, described below.
  • the account manager 234 invokes the payment adapter 242, passing the unified bill, as shown by message 870.
  • the payment adapter 242 then connects to the payment service 140 and requests it to charge the customer by the payment amount defined in the unified bill.
  • the payment service 140 charges the customer and generates an invoice which is returned to the payment adapter 242.
  • the payment adapter 242 returns the invoice to the account manager 234, as shown by message 872.
  • the invoice is added to the customer details.
  • the account manager 234 invokes the database adapter 240, passing the customer details, as shown by message 880.
  • the database adapter 240 connects to the cloud portal manager database 280 and updates the customer details including the invoice.
  • the database adapter 240 returns the execution back to the account manager 234, as shown by arrow 882.
  • the account manager 234 commits the transaction and at this point the payment operation is considered to be successful.
  • the account manager 234 returns the execution back to the web controller 232, as shown by arrow 890.
  • the web controller 232 writes a success message to the response and returns the execution to the RESTful Web Service servlet 224, as shown by arrow 892
  • the RESTful Web Service servlet 224 sends the response back to the billing scheduler 810, as shown by arrow 894.
  • FIG. 9 The process of Figure 9 starts at block 910 and proceeds to block 912, in which all accounts are gathered from a current billing cycle. The results of block 912 are then shown as "billing accounts" in block 914. The billing accounts are then processed and all subscriptions are gathered from the billing accounts, as shown at block 916. The results of block 916 are shown at block 918.
  • the billing subscriptions are then processed at block 920 and each is then considered at block 922.
  • the cycles consumption details are gathered at block 930, resulting in a distributor's billing item at block 932.
  • the distributor's billing item is then added to the distributor's bill with the provider at block 934, resulting in an aggregated distributor's bill with the provider shown at block 936.
  • the billing subscription is then processed to add a distributor markup to a partner at block 940. This results in a partner's bill item, shown at block 942.
  • the partner's bill item is added to the partner's bill at block 944, resulting in an aggregated partner's bill shown at block 946.
  • the billing subscription is further analyzed and a partner's markup is added to a customer bill, as shown at block 950. This results in a customer's bill item 952.
  • the customer's bill item is added to the customer's bill at block 954, resulting in an aggregated customer's bill 956.
  • the process further proceeds to block 960 in which a check is made to determine any further billing subscriptions need to be processed. If yes, the process proceeds to block 922 in which the next billing subscription is retrieved. [00175] From block 960, if there are no further billing items then the process proceeds to block 970 in which all subscriptions have been processed and all of the aggregated bills are gathered.
  • the system compiles all of the aggregated distributor's bills and generates one per provider, as shown at block 972.
  • the system further compiles all of the aggregated partner's bills and generates one per partner, as shown at block 974.
  • the system further compiles all of the aggregated customer's bills and generates one per customer, as shown at block 976.
  • the consolidated partner's bills are then sent to the partner's at block 980.
  • the consolidated customer's bills are then sent to the customer's at block 982
  • a flexible billing system is provided that is multi-level and transactional. Further, the system may have a multi-currency, multi-tier structure which is designed to support a hierarchical relationship between customer entities and a database. In one embodiment, the design may provide margins, discounts and other processing within these hierarchical relationships.
  • the billing system is designed to run as a black box with an opaque implementation and a flexible service oriented architecture based interface.
  • the interface to the billing system utilizes a published set of application programming interfaces (APIs) which create a level of abstraction between the data and the outside world. This allows the implementation details of the billing system to be changed without adversely affecting interconnected systems.
  • APIs application programming interfaces
  • the interface with the billing system may further provide services, including but not limited to, the creation, reading, updating or deleting of data. Services including querying, management, security enforcement, bulk data export, reporting, and bulk data import may also be provided through such interface.
  • the billing system is a rules based system, where a rules processing engine can both apply rules to the customer and to the individual items within a customer's bill.
  • rules may be used, for example, to normalize price, compare items that are disparate, handle unit conversions at each layer and allow for differentiation of the same product based on whether the product is being bought or sold.
  • an interface API 1010 is a module that is used to provide multiple means of interfacing the billing system with other systems, including the cloud portal system described above.
  • the interface API 10 0 allows other systems to import data and/or export data to the various subsystems managed by the billing system.
  • the interface API is a flexible and extensible subsystem that utilizes a variety of input and output technologies. These include a service oriented architecture based web service API that can be used to manipulate and query data in the billing system. Further, a file drop system may be provided for bulk imports and exports. A query based input/output subsystem may further be supported, as well as an ad hoc public facing database that can be used to input and output billing data in a custom, on demand, format.
  • a second component of the application domain is the agent portal 1012.
  • the agent portal allows agents to interact with the system. Such interaction may be used to query customer accounts, query partner accounts, query distributor accounts, add distributors, add partners, place orders, view reports, edit reports and make adjustments to services and service providers.
  • the software application domain includes a partner portal 1014.
  • the partner portal 1014 allows agents to interact with the system. Such interactions may be used to edit service descriptions, view usage reports, view disputes and charge backs, among other features.
  • a distributor portal 1016 is further provided, which allows distributors to interact with the system. Such interactions may include the editing service descriptions, viewing the usage reports and viewing disputes and charge backs, among other features.
  • a management portal 1020 is used to allow administrators to monitor, configure and maintain the billing subsystem.
  • the administrators may view queues and back-logs, configure work flows, enable and disable features, as well as edit user security settings, among other features.
  • Such portals therefore allow interaction with the billing service 1030 as well as a reporting service 1032. Further, access may be provided to data stores including a services data store 1040, agents data store 1042, coordination queue 1044, reports 1046 and a history 1048.
  • the services database 1040 provides a data store which holds all services and subscribers to the service. This includes distributors, partners and service details.
  • Agents database 1042 is a data store that holds persistent data used to drive the agent portal. It holds the security credentials and workflow data required for the agent portal 1012.
  • the coordination queue 1044 is a workflow oriented data store used to move bulk data between major data stores and also to facilitate billing and reporting services. It is also used to import and output functions for the billing system.
  • Reports database 1046 is a data store used to generate and store reports.
  • the reports data base 1046 is its own data store in order to prevent online databases required by customer facing websites to be affected.
  • History database 1048 is an audit data store. Such history database 1048 tracks all changes to the billing subsystem and allows administrators to understand how changes are affecting the performance of the system.
  • a dynamic and adaptable data and programming model is provided.
  • Such system may be used, for example if the billing system is applied to a cloud services platform, where various services within such cloud services platform are sold using a wide range of units per measurement.
  • cloud hosting may be sold with one or more of the following units: gigabytes of space per month, CPU usage per month, internet bandwidth cap per month, IP addresses may be charged either per IP address or per batch of IP addresses per month, one time installation fees may be charged, among other factors.
  • billing may be pay per month, per user per month, per usage consumption, among others.
  • the billing system uses a metadata driven data store to maintain information that can map between various service offerings and allow the system to adapt to new service offerings during the billing cycle.
  • the meta-data is sometimes used, along with a workflow engine, to generate code necessary to process billings and reports for various services.
  • Each service offering entered into the system may then be mapped to a specific set of meta-data tags that enable the system to discover and understand the parameters that are used to drive the services and the details required to bill users using such parameters.
  • Interface API is therefore a flexible and extensible subsystem utilizing a variety of input/output technologies.
  • the API may include a data input queue which includes an input queue processing workflow module.
  • Such input queue processing workflow module takes data from an external source, reads the input queue meta-data and determines how to process the input data. If necessary, a small applet or program may be generated using meta-data that can process the input queue data. The workflow engine therefore converts the input data to an internal representation needed for the billing system using such meta-data.
  • the interface API may include a service oriented architecture API where a pair of queues are supported.
  • a first queue could be used for input and another used for output.
  • processing workflow can direct output to the output queue and input can come from the input queue, which allows a system to absorb a high volume of calls per hour.
  • data may need to be transformed and normalized using information stored in meta-data tables.
  • Normalized information is used to generate a program code that is then used to process billing and other workflows. Output from each workflow is stored in intermediary tables that are then used to feed other workflow functions.
  • block 1110 is used to read subscriber details. Such details may come from a normalized service descriptor's store 1112 and a service subscriber's store 1114. From block 1110, once the details are read, the process proceeds to block 1120 in which the service meta-data is analyzed. The data may come from a service meta-data store 1122.
  • the process may then proceed to block 1130 in which service billing logic is generated and the service billing logic is then used to process billing at block 1140.
  • the intermediary values may be then stored at a data store 1150.
  • billing may be performed at multiple stages. Service details are normalized as much as possible to allow the same workflow to work across a variety of services and prices are normalized to a standard unit that is then converted to and from the final currency at one stage of the billing finalization.
  • FIG. 12 shows that a service input 1210 is converted to a normalized unit pricing at block 1212 and the intermediary service details are then stored at block 1214. These intermediary details are then provided as a service input 220.
  • the service input 1220 can then be used to store service meta-data 1230, store service programming logic 1232 and store normalized service descriptors 1234
  • a programmable, iterative billing cycle may then be applied to the services and subscriptions in order to generate a final bill.
  • the billing process starts at block 1310 and proceeds to block 1312 in which the next subscriber account set is retrieved. From block 1312 the process proceeds to block 1314 in which the account set services are retrieved.
  • the process then proceeds to block 1344 in which the partner margins are calculated and at block 1346 refunds are processed based on the stored refunds at block 1320.
  • the process then proceeds to block 1350 in which the final partner accounts are calculated and these final accounts are stored at block 1352.
  • the partner margins are also stored, as shown at block 1354 and refunds and adjustments are stored at block 1356.
  • Refunds for distributors are processed at block 1364 and are stored, as shown, at block 1366.
  • each subscriber initial bill is processed in a serial manner. Services that the subscriber uses are added up and an intermediary summary is created. Refunds and other charges are calculated and the intermediary details are pushed into a holding queue. Further, partner margins may be calculated including the sum of the services sold during the billing period and charge backs, refunds and other charges are summarized. An intermediary summary of the partner margins is stored and may be calculated in a hierarchical manner where volume pricing is also supported.
  • Partner summaries as indicated above may be used to generate distributor summaries.
  • the billing cycle is managed by a work-flow engine which processes each service based on the type of service.
  • the code for the work-flow engine is derived from the meta-data associated with each service.
  • a user interface may be published that allows for a drag and drop design of workflow processing. Administrators may be able to generate or alter work-flow parameters using tools designed for such work-flow.
  • billing may be performed on a scheduled basis depending on factors including contractual arrangements, cancellations and changes to services.
  • the billing system provided above stores the time-zone that the billing is to be initiated in and the time zone is configured during the process of configuring service contracts.
  • the workflow engine may utilize this information and use it as a reference point for billing processes.
  • various security parameters may be added to ensure the secure billing system.
  • security parameters may include database encryption for some or all of the data.
  • access to various database tables may be controlled based on various security features including user groups and privileges.
  • changes to data tables can trigger auditing functionality. For example, changes in database will push audit records into a history data store and can include information such as changes made, times of the change, user that made the change, a session that the user logged in with, among other features. Also, whenever a user has logged into a system, a user session record may also be generated and stored for such user.
  • the billing system may include a series of triggers and notifications.
  • the billing system may monitor internal and external data for events that are of interest to users and provide notification of these events through a variety of means.
  • events may include price changes, new services, changes in exchange rates, among others.
  • events may include price changes, new services, changes in exchange rates, among others.
  • the viewing of services or purchase of services by consumers may be notified to distributors.
  • the notification based on the trigger can occur through a variety of means such as e-mail, short message service, social media, among other options.
  • the billing system may be designed to support international usage and thus the user interface, and currency, among other features may be customized based on a user, which may be supported through the meta-data for that user.
  • FIG. 14 shows an overall process for one embodiment of the billing system.
  • the process of Figure 14 starts at block 1410 and proceeds to block 1412 in which the process retrieves the customer that is to be billed.
  • the process then proceeds to block 1414 in which the customer's billing routine is looked up.
  • the calculation routines may be used to process the customer items and may be stored in, for example, extensible mark-up language (XML) files. These files then generate code and rules that are used to calculate the customer billing.
  • the customer billing routine at block 1414 may be broken down such that each individual customer has an individualized customer routine.
  • classes of customers may be created. Such classes of customers may be based on a set of services and terms, for example.
  • each line item is then billed.
  • the line item billing utilizes a lookup of item details at block 1418.
  • the line item details may be based on a billing value such as dollars per month but may also be based on a normalized value such as kilobytes per month translated to a dollar figure. The value may or may not be fixed. For example, a promotion may be included such a 2000 free units and then subsequent units are charged.
  • the line item details are described in a document such as an XML file that may be individualized per line item or may be classed based on a grouping or type of line item.
  • block 1420 the usage is calculated given current date, time, and usage metrics. Further, input to block 1420 may come from block 1422 in which the process looks up or calculates optional usage values for the billing period. Customer usage of services can be metered. In such a case, program routines are used to calculate the customer usage value and are stored in rules such as in an XML file. The metered usage is then returned in units required to complete the calculation.
  • the application After signing up for a new cloud portal manager account, the application creates a new workspace and grants the customer access to it.
  • the workspace corresponds to a portal website.
  • the workspace (or portal website) has a set of pages. Each page contains portlets that fulfill the purpose of that page.
  • portlets that fulfill the purpose of that page.
  • One example of such an implementation is described below. However, other options are also possible.
  • Portlets are used in all pages and can be grouped in the following categories: [00236] Cloud Product Subscription Details Portlets
  • Each cloud product provides two portlets: one summary portlet, which can be accessed through the dashboard, and one subscription details portlet, which can be viewed in the "My Products" page tab that corresponds to the cloud product type in question. For instance, if the customer has a subscription to a virtual server, they have access to the portlet that shows the customer's subscription summary in the "Dashboard” tab and to the portlet that shows the customer's subscription details in the "Virtual Appliances" tab.
  • the portlets retrieve subscription information by following the steps described in Figure 5 above, for example.
  • This portlet is found in the "Cloud Portal Manager Products” page and is intended to support a customer's request to subscribe to a new cloud product. It achieves its purpose by following the steps described above.
  • the account management portlet is used to allow the customer to view its account information, including the accounts of the users that are members of their team and therefore have access to their workspace. Through the portlet users can update their information (such as name, email address, etc), add or remove members, and grant them access to or revoke them access from the workspace pages and portlets.
  • the "My Products" page contains detailed information on all cloud products to which the customer has subscriptions.
  • the page is formed of tabs, where each tab shows a different view which in turn shows information related to a cloud product type.
  • Dashboard [00245]
  • the dashboard tab provides the summary information of all customer subscriptions. Each subscription is made available to the user as a summary portlet on the page.
  • the kind of information shown in the dashboard portlet refers mainly to consumption of cloud product resources and outstanding monetary amount owed by the customer from the beginning of the billing cycle up until the moment the portlet retrieves the subscription information.
  • One special portlet shows the aggregated financial information associated to all of the customer's subscriptions.
  • the layout of the portlets in the dashboard may be configurable. Customer may add portlets to and remove them from the page, as long as the user has a subscription to the cloud product which is the subject of that portlet.
  • the Email Server tab may show details on the customer's subscriptions to an email servers. Details may include the list of email accounts and amount of storage used by the accounts' inbox folders, for example.
  • the Virtual Appliances tab may show details on the customer's subscriptions to virtual servers, routers, load balancers and other virtual appliances. Customers can view information such as CPU speed, amount of RAM, Storage type and amount, operation system, etc.
  • the Storage tab may show details on the customer's subscriptions to storage cloud products, including amount available, amount used and virtual appliance to which it is exposed as a file system volume (if applicable). [00254] Telco. Connectivity
  • the Telco. Connectivity tab may show details on the customer's subscriptions to telecommunications products such as voice and data plans associated to cellular telephones. Details may include a list of phone calls, amount of downloaded and uploaded data, number of conversation minutes, among other information.
  • the Security tab may show details on the customer's subscriptions to security products. Available information may include reports on detection intrusion and other types of attacks.
  • the Networking tab may show details on the customer's subscriptions to network connectivity products such as network speed and amount of downloaded and uploaded data.
  • the "My Account” page allows the customer to maintain their account and those of their team. It may contain the account management portlet described above.
  • the "Cloud Portal Manager Products” page shows the list of products offered by cloud portal manager 110. Through this page customers may purchase new subscriptions to offered cloud products. It may contain Cloud Product Subscription Request portlets as described above.
  • the "My Contracts" page is a special customer account page. It is intended to show the Terms & Conditions, Statement of Work and other legal documents that the customer has signed, as results of the activities described above.
  • the cloud portal manager 110 is multi-tiered. That means that each tier may run in a different computer or group of computers.
  • the cloud portal manager deployment plan forms a topology of servers running similar applications connected as clusters, and each cluster corresponds to a tier.
  • the front- end tier which is hosted by the customer's computer (and consists of the cloud portal manager front-end 212)
  • the deployment plan focuses on the following concerns:
  • cloud portal manager 110 is designed to be highly available, that is, the processing of customer requests should not be denied due to the lack of computational resources. This is done through redundancy and efficient disaster recovery.
  • Performance Customer requests should be processed with an amount of time that is considered acceptable and a well-known number of concurrent requests are guaranteed to be processed within that amount of time.
  • Load- balancing and server tuning are techniques that help achieving highly performing applications.
  • the deployment plan uses virtual appliances to host the cloud portal manager application components.
  • Each node in the topology corresponds to a virtual server, storage unit or load balancer. That means that the solution is cloud-based and uses cloud products. Consequently one may note that cloud portal manager 110 relies on some of the very products it offers to customers.
  • the number of nodes per cluster, the operating system and amount of computational resources (CPU, RAM, disk, etc) allocated for each virtual server may be determined based on the deployment.
  • the load balancer 1510 is the gateway to the cloud portal manager back- end 230. Requests coming from customers' hosts are routed to this node.
  • the load balancer's purpose it to forward each request to the most suitable node in the portal container cluster 1520 according to a load-balancing algorithm, for processing. Any active node in the portal container cluster 1520 may be designated by the algorithm to process the request; however, only one node may process it.
  • the cloud portal manager back-end 230 is deployed into a group of portal container instances and each instance is deployed on a virtual server.
  • the portal container instances being Enterprise Application Servers, offer the feature of connecting them together in a cluster. This configuration is called the clustered portal container 1520.
  • the clustered portal container 1520 may have the following features configured: • Session replication: The load balancer 1510 forwards customer requests to a portal container node deemed to be the most suitable at the time the request reaches it. That means that following requests may not necessarily be forwarded to the same node (unless sticky sessions are used). To guarantee reliability, each node broadcasts to the other nodes changes to the user session whenever they occur, so that the changes are reflected on the node that processes the following request.
  • Application state replication Application-related data such as cache and properties is synchronized among the cluster nodes through broadcasting. That means that whenever a node makes changes to its application-specific state, that change is broadcast to the other nodes which in turn update their own state.
  • the database driver provided by the portal container and used by the database adapter 240 supports a load-balancing feature that is leveraged by cloud portal manager 110.
  • the addresses to the nodes in the database cluster 1530 are included so that the database adapter 240 load-balances its connections.
  • the database cluster 1530 corresponds to a group of virtual servers running clustered database management instances.
  • the database management system clustering feature guarantees data replication across the cluster and provides availability, reliability, scalability and performance.
  • the choice of the database management system vendor is outside of the scope of this description.
  • the virtual servers designated as nodes in both portal container cluster 1520 and database cluster 1530 need to persist data in a file system.
  • Cloud Portal Manager's storage solution consists in subscriptions for a storage cloud product.
  • the cloud product provides block level storage volumes that are exposed to the virtual servers as file system volumes.
  • Each node in the portal container cluster 1020 or database cluster 1530 has one of such file system volumes.
  • the storage units 1540 are independent from the virtual servers, which mean that a storage unit is not affected in case that the virtual server that utilizes it fails.
  • the faulty server may be replaced by a new server and the storage unit exposed to it as a file system volume. The new server then replaces the faulty one and this procedure can be performed during disaster recovery.
  • Backup of each storage unit may be part of the cloud product subscription.
  • the cloud product may include data encryption and all data stored in the storage units 1540 and their backup is encrypted, ensuring data integrity and privacy.
  • the cloud portal manager 110, databases, storage and backup, billing and other services of Figures 1 to 15 may be implemented on one or more servers or computers, each having a processor configured to execute program logic to perform the methods described above.
  • Each server or computer further includes a communications subsystem configured to allow the server or computer to communicate with the other entities described herein.
  • various servers or computers may include a tangible, non-transitory storage medium for storing program code for performing the methods described above.
  • exemplary clauses include: [00288] AA.
  • a method at a server for managing a plurality of cloud product subscriptions comprising: receiving, at the server, a request from a remote computer, the request being intercepted by a portlet on the server; finding, at the server, a web controller for the request; validating the request at the web controller; invoking an account manager for the request; finding, from the account manager, an adaptor for a cloud services provider; and sending, utilizing the adaptor, information regarding the request to the cloud services provider.
  • a server for managing a plurality of cloud product subscriptions comprising a processor configured to: receive a request from a remote computer, the request being intercepted by a portlet on the server; find a web controller for the request; validate the request at the web controller; invoke an account manager for the request; find, from the account manager, an adaptor for a cloud services provider; and send, utilizing the adaptor, information regarding the request to the cloud services provider.

Landscapes

  • Engineering & Computer Science (AREA)
  • Business, Economics & Management (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Development Economics (AREA)
  • Economics (AREA)
  • Accounting & Taxation (AREA)
  • Finance (AREA)
  • Marketing (AREA)
  • Strategic Management (AREA)
  • Physics & Mathematics (AREA)
  • General Business, Economics & Management (AREA)
  • General Physics & Mathematics (AREA)
  • Theoretical Computer Science (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)

Abstract

La présente invention concerne un procédé associé à un dispositif de traitement informatique faisant appel à un système de facturation à base de règles, le procédé faisant appel à la récupération, pour chaque entité facturable, de règles de traitement d'entité à partir d'une mémoire; à l'application des règles de traitement d'entité; à l'obtention, pour chaque élément de facturation, de règles de traitement d'élément de facturation; au calcul, pour chaque élément de facturation, d'une quantité basée sur les règles de traitement d'élément de facturation; et au fait de générer une facture sur la base de l'application et du calcul. La présente invention concerne en outre un procédé associé à un serveur de gestion de plusieurs abonnements de produits en nuage, le procédé faisant appel à la réception, au niveau du serveur, d'une requête d'un ordinateur à distance, la requête étant interceptée par un portlet sur le serveur; à la recherche, au niveau du serveur, d'un contrôleur Web associé à la requête; à la validation de la requête au niveau du contrôleur Web; à l'appel d'un gestionnaire de comptes en ce qui concerne la requête; à la recherche d'un adaptateur d'un fournisseur de services en nuage; et à l'envoi, au moyen de l'adaptateur, d'informations concernant la requête au fournisseur de services en nuage.
PCT/CA2014/000324 2013-04-08 2014-04-04 Procédé et système de gestion de portails de nuage et système de facturation associé WO2014165967A1 (fr)

Applications Claiming Priority (4)

Application Number Priority Date Filing Date Title
US201361809439P 2013-04-08 2013-04-08
US61/809,439 2013-04-08
CA 2811590 CA2811590A1 (fr) 2013-04-16 2013-04-16 Gestionnaire de portail en nuage universel unique combinant toutes les solutions des fournisseurs de services de technologie en nuage/heberges en un portail en nuage sans rapport avec un fournisseur
CA2,811,590 2013-04-16

Publications (1)

Publication Number Publication Date
WO2014165967A1 true WO2014165967A1 (fr) 2014-10-16

Family

ID=51688772

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CA2014/000324 WO2014165967A1 (fr) 2013-04-08 2014-04-04 Procédé et système de gestion de portails de nuage et système de facturation associé

Country Status (2)

Country Link
CA (1) CA2811590A1 (fr)
WO (1) WO2014165967A1 (fr)

Cited By (11)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20160328226A1 (en) * 2015-05-08 2016-11-10 Desktop 365, LLC Method and system for managing the end to end lifecycle of the virtualization environment for an appliance
US20170134381A1 (en) * 2015-11-09 2017-05-11 Microsoft Technology Licensing, Llc Dashboard as remote computing services
US10320935B2 (en) 2015-01-28 2019-06-11 Red Hat, Inc. Cache data validation
US20190196682A1 (en) * 2016-08-24 2019-06-27 Selfserveme Pty Ltd. Customer service systems and portals
US10572324B2 (en) 2016-09-12 2020-02-25 Microsoft Technology Licensing, Llc Intelligent listening system for agile delivery of cloud services
CN110930183A (zh) * 2019-11-14 2020-03-27 云赛智联股份有限公司 一种公有云客户费用异常检测系统
CN110969492A (zh) * 2019-12-20 2020-04-07 北京金山云网络技术有限公司 一种云产品的计价方法、定价方法、装置及系统
CN111210273A (zh) * 2020-01-03 2020-05-29 湖北省楚天云有限公司 一种政务云平台资源的计量计费方法和系统
CN114185854A (zh) * 2021-12-02 2022-03-15 百融云创科技股份有限公司 一种SaaS系统的离线记费方法及系统
CN114697146A (zh) * 2020-12-14 2022-07-01 中国石油化工股份有限公司 面向勘探开发云应用服务的计费管理方法
US20220414722A1 (en) * 2019-12-20 2022-12-29 Beijing Kingsoft Cloud Network Technology Co., Ltd. Valuation Method, Pricing Method, Apparatus and System for Cloud Product

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20040117224A1 (en) * 2002-12-16 2004-06-17 Vikas Agarwal Apparatus, methods and computer programs for metering and accounting for services accessed over a network
US20090300608A1 (en) * 2008-05-29 2009-12-03 James Michael Ferris Methods and systems for managing subscriptions for cloud-based virtual machines
US20110295727A1 (en) * 2010-05-28 2011-12-01 James Michael Ferris Systems and methods for aggregate monitoring of utilization data for vendor products in cloud networks
WO2012024955A1 (fr) * 2010-08-27 2012-03-01 中兴通讯股份有限公司 Procédé et système de facturation pour informatique en nuage
US20130282540A1 (en) * 2012-04-19 2013-10-24 2Nd Watch, Inc. Cloud computing consolidator billing systems and methods

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20040117224A1 (en) * 2002-12-16 2004-06-17 Vikas Agarwal Apparatus, methods and computer programs for metering and accounting for services accessed over a network
US20090300608A1 (en) * 2008-05-29 2009-12-03 James Michael Ferris Methods and systems for managing subscriptions for cloud-based virtual machines
US20110295727A1 (en) * 2010-05-28 2011-12-01 James Michael Ferris Systems and methods for aggregate monitoring of utilization data for vendor products in cloud networks
WO2012024955A1 (fr) * 2010-08-27 2012-03-01 中兴通讯股份有限公司 Procédé et système de facturation pour informatique en nuage
US20130282540A1 (en) * 2012-04-19 2013-10-24 2Nd Watch, Inc. Cloud computing consolidator billing systems and methods

Cited By (20)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10911562B2 (en) 2015-01-28 2021-02-02 Red Hat, Inc. Cache data validation
US10320935B2 (en) 2015-01-28 2019-06-11 Red Hat, Inc. Cache data validation
US10678526B2 (en) * 2015-05-08 2020-06-09 Desktop 365, LLC Method and system for managing the end to end lifecycle of a virtualization environment
US10303453B2 (en) * 2015-05-08 2019-05-28 Desktop 365, LLC Method and system for managing the end to end lifecycle of the virtualization environment for an appliance
US20160328226A1 (en) * 2015-05-08 2016-11-10 Desktop 365, LLC Method and system for managing the end to end lifecycle of the virtualization environment for an appliance
US10375072B2 (en) * 2015-11-09 2019-08-06 Microsoft Technology Licensing, Llc Dashboard as remote computing services
US20170134381A1 (en) * 2015-11-09 2017-05-11 Microsoft Technology Licensing, Llc Dashboard as remote computing services
CN108351769A (zh) * 2015-11-09 2018-07-31 微软技术许可有限责任公司 作为远程计算服务的仪表板
US11095648B2 (en) * 2015-11-09 2021-08-17 Microsoft Technology Licensing, Llc Dashboard as remote computing services
CN108351769B (zh) * 2015-11-09 2021-11-12 微软技术许可有限责任公司 作为远程计算服务的仪表板
US20190196682A1 (en) * 2016-08-24 2019-06-27 Selfserveme Pty Ltd. Customer service systems and portals
US11805032B2 (en) * 2016-08-24 2023-10-31 Selfserveme Pty Ltd. Customer service systems and portals
US10572324B2 (en) 2016-09-12 2020-02-25 Microsoft Technology Licensing, Llc Intelligent listening system for agile delivery of cloud services
CN110930183A (zh) * 2019-11-14 2020-03-27 云赛智联股份有限公司 一种公有云客户费用异常检测系统
CN110969492A (zh) * 2019-12-20 2020-04-07 北京金山云网络技术有限公司 一种云产品的计价方法、定价方法、装置及系统
US20220414722A1 (en) * 2019-12-20 2022-12-29 Beijing Kingsoft Cloud Network Technology Co., Ltd. Valuation Method, Pricing Method, Apparatus and System for Cloud Product
CN111210273A (zh) * 2020-01-03 2020-05-29 湖北省楚天云有限公司 一种政务云平台资源的计量计费方法和系统
CN114697146A (zh) * 2020-12-14 2022-07-01 中国石油化工股份有限公司 面向勘探开发云应用服务的计费管理方法
CN114697146B (zh) * 2020-12-14 2024-04-19 中国石油化工股份有限公司 面向勘探开发云应用服务的计费管理方法
CN114185854A (zh) * 2021-12-02 2022-03-15 百融云创科技股份有限公司 一种SaaS系统的离线记费方法及系统

Also Published As

Publication number Publication date
CA2811590A1 (fr) 2014-10-16

Similar Documents

Publication Publication Date Title
US11044305B2 (en) Cloud federation as a service
US20200184394A1 (en) Constraints and constraint sharing in a catalog service platform
US10740711B2 (en) Optimization of a workflow employing software services
WO2014165967A1 (fr) Procédé et système de gestion de portails de nuage et système de facturation associé
US20190108575A1 (en) Graph processing service component in a catalog service platform
US11244261B2 (en) Catalog service platform for deploying applications and services
RU2597507C2 (ru) Шлюзовой уровень абстракции
US10057186B2 (en) Service broker for computational offloading and improved resource utilization
US8965957B2 (en) Service delivery framework
US20070027784A1 (en) Network payment framework
US20160132808A1 (en) Portfolios and portfolio sharing in a catalog service platform
US20160260157A1 (en) Rapid service orchestration and management
US10511453B2 (en) Information processing system and charge calculation apparatus
US20120158931A1 (en) Method and Apparatus for the Execution of Adaptable Composed Computer-Implemented Services with Integrated Policies
US8175994B2 (en) Method and system for self-learning issues remediation
EP3937109A1 (fr) Plateforme de distribution de service multicanal et procédé associé
WO2016077483A1 (fr) Plateforme de service de catalogues permettant de déployer des applications et des services
Moore et al. A service broker and business model for saas applications
Kumar et al. Serverless Integration Design Patterns with Azure: Build powerful cloud solutions that sustain next-generation products
Patel et al. Introduction to Cloud Computing and Amazon Web Services (AWS)
McIntyre IBM SmartCloud: Becoming a Cloud Service Provider
Vega García A proposal for a Business Framework targeted at emerging business services and applications
Soinu Cloud Solutions for Mobile Applications
Leu et al. Implementing Billing as a Service by an IPDR Aggregator System
Mavrogeorgi et al. SLA Management in Storage Clouds

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 14782684

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 14782684

Country of ref document: EP

Kind code of ref document: A1