US20070150480A1

US20070150480A1 - Service delivery platform

Info

Publication number: US20070150480A1
Application number: US11/400,249
Authority: US
Inventors: Hans Hwang; Cenk Ikiz
Original assignee: Accenture Global Services GmbH
Current assignee: Accenture Global Services Ltd
Priority date: 2005-04-11
Filing date: 2006-04-07
Publication date: 2007-06-28
Also published as: AU2006201515A1; US20140038550A1; AU2006201516A1; US9444930B2; AU2006201516B2; US8554916B2; US20060227953A1

Abstract

A service delivery platform is disclosed, including method and apparatus for managing the delivery of a variety of services to customers or subscribers. Exemplary services that may be managed using the service delivery platform include telecommunication services such as cable, wire line and wireless services. The service delivery platform creates, hosts, and manages services over different channels and end user devices. The implementation of the service delivery platform will dramatically simplify service deployment and management, and allow an enterprise to develop new services more rapidly with the reduced development efforts.

Description

CROSS REFERENCE TO RELATED APPLICATIONS

This application claims the benefit of U.S. Provisional Application No. 60/670,114, filed Apr. 11, 2005.

COPYRIGHT NOTICE

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

BACKGROUND

The present application relates generally to provision of services such as telecommunication services. More particularly, the present application relates to a service delivery platform and method to improve the delivery of telecommunications services.
Service providers provide services to their customers in response to customer orders, change requests and other processes. One particular class of service providers is telecommunications service providers, which provide telecommunication services to their customers, referred to as subscribers. Telecommunications services currently include both wire line and wireless technologies. Examples of wire line telecommunication services include telephone service and related services such as voice mail, call forwarding, three way calling and caller identification, or cable television service and associated cable-provided services, such as internet access. Examples of wireless telecommunication services include cellular telephone service and associated services such as voice mail and three way calling, wireless electronic mail and paging.
Provision of such services includes many aspects. The service must be initially provisioned, or established. This can include establishing an account for charging and billing the subscriber. This can include setting up service provision channels, such as designating a telephone number or other unique resource for the subscriber, providing dedicated hardware and software for the subscriber, such as installing a telephone line. After provisioning, if the service is provided on a per-unit basis, the service must be metered to measure the quantity of the service consumed. Bills must be generated and payments credited. If additional services are subscribed, the additional services must be provisioned and the account adjusted accordingly. Each change requires updating the equipment and software involved in service provision.
Recently, there has been a significant interest in the Service Provider (SP) industry to converge or consolidate different media such as voice, data, and video into single enterprise architecture. This would enable the enterprise to deliver value-added services such as unified communications, video and media rich solutions, and collaboration and knowledge sharing.
Previous systems for provisioning new services and updating existing services have required a new service setup for each service added. Thus, if a telecommunication service provider has in place telephone voice service to a number of subscribers and decides to add a new voice mail service, the telecommunication service provider must develop new hardware and software for implementing the system, a new billing process and other related features of the new service. If further services are developed for offer to subscribers, the process must be repeated for each new service or modification of a service. Repeating the process is expensive, time consuming and can delay the introduction of new services or features.
Moreover, a technical problem is created for service providers who seek to expand their offerings to different services or to extend existing services to add new features. Legacy systems may be implemented using hardware and software which are fully functional but no longer supported or no longer the best choice. Such legacy systems may be technologically incompatible with new equipment for providing services which are to be packaged with a legacy service. New implementations of services or features are preferably built on advanced equipment and software to leverage current technologies, efficiencies and standardized tools. Getting legacy systems to work well with newly installed systems may be difficult to accomplish technically and may require substantial time and cost. As one example, many current telecommunications services are provided using the standardized Advanced Intelligent Network. Newer equipment makes use of the infrastructure of the internet, which employs a data transfer protocol such as transmission control protocol/internet protocol (TCP/IP). Even a technical interworking of new and legacy systems is possible, the resulting system may not include all desired functionality and may not be optimized for the service provider's needs. The final product or suite or products may be limited by the limitations of the incorporated legacy system.
Accordingly, there is a need for an improved system and method for delivering services to existing subscribers and new subscribers. There is a technical need for a system and method which allow a variety of technically different service provision systems to operate smoothly and efficiently.

BRIEF SUMMARY

By way of introduction only, the present embodiments provide a service delivery platform, including method and apparatus for managing the delivery of a variety of services to customers or subscribers. The service delivery platform (SDP) is a platform architecture that fully exploits the convergence opportunities made available for the service providers (SPs) recently. The SDP creates, hosts, and manages services over different channels and end user devices. The implementation of the SDP will dramatically simplify service deployment and management, and allow the enterprise to develop new services more rapidly with the reduced development efforts.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a block diagram of a service provider system;
FIG. 2 is a functional block diagram of a service delivery system;
FIG. 3 is a functional block diagram of as service delivery platform for use in the service delivery system of FIG. 1;
FIG. 4 is a physical architecture diagram of a service delivery platform;
FIG. 5 is an interaction diagram illustrating a process of changing features of an existing service using a service delivery platform;
FIG. 6 is an interaction diagram illustrating a process of creating a new offer using a service delivery platform;
FIG. 7 is an interaction diagram illustrating a process of creating a billing feed using a service delivery platform;
FIG. 8 is an interaction diagram illustrating a process of providing a value-added reseller with a customer view using a service delivery platform;
FIG. 9, including FIG. 9 a and FIG. 9 b, is an interaction diagram illustrating a process of creating a new account in an enterprise environment using a service delivery platform;
FIG. 10 is an alternative interaction diagram illustrating a process of creating an account with two new services using a service delivery platform
FIG. 11 is an interaction diagram illustrating a process of authenticating and authorizing an end user of services using a service delivery platform;
FIG. 12 is an interaction diagram illustrating a process of handling a provisioning exception when provisioning services using a service delivery platform;
FIG. 13 is an interaction diagram illustrating a process of changing offer properties of an offer of services by a service provider, using a service delivery platform; and
FIG. 14, including FIG. 14 a, FIG. 14 b, FIG. 14 c and FIG. 14 d, illustrates an object model for use in conjunction with a system and method like the present embodiments, while FIG. 15, including 188 sheets, illustrates exemplary implementations of the disclosed products and processes of the present invention.

DETAILED DESCRIPTION OF THE PRESENTLY PREFERRED EMBODIMENTS

The present invention provides a technology architecture that enables efficient and rapid creation and support of applications by service providers who provide or seek to provide services to subscribers. The architecture standardizes the interfaces linking applications to operational and back office support systems and network capabilities. This reduces the time required for the service creation process and gets products to market faster. It also reduces the cost of service creation and support. The architecture provides a common, reusable set of development tools. It allows reuse of discrete and modular functionality across the entire platform. It has the capability to define and apply common control policies to applications. And it has the capabilities to define and manage integrated profiling of users, services and resources. These all provide greater flexibility in bundling and packaging features and applications to create new services.
In one embodiment, the present invention provides a service delivery platform which is modular, flexible and designed to support the delivery of value-added services. The service delivery platform includes a suite of plug-and-play solutions built on a standardized platform, such as the Microsoft .NET platform, available from Microsoft Corp., Redmond, Wash. This platform is optimized for delivery to SMBs as managed services. The service delivery platform further provides a modular, end-to-end service delivery platform that substantially automates sales, order management, provisioning, billing and operations management. The service delivery platform relies on a reusable, component-based model that maximizes reuse and flexible service bundling.
The service delivery platform can be extended to the widest variety of services, service providers and customers. Examples of telecommunications services that can beneficially be implemented in accordance with the service delivery platform include hosted Microsoft Exchange messaging services, including mobile electronic mail (email), facsimile and short message service and email archiving; hosted Microsoft Sharepoint, which is a system allowing network-based collaboration within an organization and with customers and business partners; Unified Messaging/Unified Communications (UM/UC); HiPath Openscape, a multimodal communications application from Siemens Enterprise Networks, San Jose, Calif.; web hosting; media on demand; secure instant messaging; web conferencing and live meetings (LM); and Voice Over Internet Protocol (VoIP); Microsoft Customer Relationship Manager (CRM); Microsoft Great Plains, which provides capabilities for financial management, distribution, manufacturing, project accounting, human resource management, field service management, and business analytics; and television over Internet Protocol (IP TV), and others applications. This list is intended to be illustrative and not exhaustive.
A system in accordance with the present embodiments reduces the amount of work required to implement new services by incorporating the functions common to all managed services into the service delivery platform itself. For example, for developing core service functionality, common routines such as logging, metering, tracking, etc., are well-defined and available for use by the service. For developing portal screens for the user interface (UI) for a service, pre-existing WebParts, from Microsoft Sharepoint, reduce the UI development time. For adding a new service description to a catalog of services, the service delivery platform provides a standardized service catalog structure which defines elements to be included, which ensures seamless integration with the rest of the service. Further, for creating provisioning logic and workflows, a rules engine based on Microsoft BizTalk simplifies the effort required to implement workflow. Existing workflows provide a starting point for implementing new workflows. For creating new interfaces that may be required by the new or expanded service, the system in accordance with the present embodiments isolates interface complexities from developers and allows reuse of existing interfaces. For providing interface for a service to a billing platform, the system features an interface to a billing platform which is architected to minimize changes with additional services. For creation of service specific reports, existing reports can be used as a starting point. Well-defined data structures reduce development time. Further, for establishing operations processes for a new service, the system allows the additional service to suggest modifications to existing operations support processes, rather than establishing new processes. These features substantially improve the efficiency of establishing a new service or expanding a service.
Referring now to the drawing, FIG. 1 is a block diagram of a service provider system 100. The system 100 includes customer-side components 102 and system-side components 104. The components communicate over an enterprise messaging backbone 106.
The customer-side components 102 include a customer self-service function 108, a customer management system 110, an order manager 112, a usage manager 114, and a customer database manager 116. The customer side components 102 provide order entry, billing and customer care functionalities. The self-service function 108 allows a customer or service subscriber to view or modify an account without assistance and intervention by an agent of the service provider. This could be through World Wide Web access by the subscriber or by actuation of a telephone menu system. The order manager 112 manages the provisioning of new or changed services for subscribers. The usage manager 114 monitors usage of the service, for example, to ensure the customer only accesses services in accordance with his subscription. The customer database manager 116 manages the content of and access to the customer database. Other components may be included or substituted depending on the particular services provided or the particular service provider.
The system-side components 104 include a network 120, a third party supplier gateway 122, a billing and invoicing system 124, an enterprise manager 126, external interfaces 128, and a service delivery platform 130. The network 120 includes the service delivery infrastructure of data processing equipment and associated software. The third party supplier gateway 122 is a portal permitting service providers other than the service provider associated with the system 100 to provide services to customers. The billing and invoicing system 124 receives information about the nature and amount of services used, terms of service between the service provider and the subscriber and generates a bill for the subscriber. The enterprise manager 126 provides overall system control. The external interfaces 128 allow the system 100 to communicate data and information with other sources.
The service delivery platform 130 creates, hosts, manages, controls, and deploys the value-added services provided by the system 100. The service delivery platform 130 operates as a system within the larger service provider system 100. The service delivery platform 130 interacts with the entire system 100 through the enterprise messaging backbone 106. The enterprise messaging backbone provides interfaces and process management over the entire network, bridging system and information in order to provide complete and consistent operations and management. The service delivery platform 130 will be described in greater detail below.
FIG. 2 is a functional block diagram of a service delivery system 200 including the service delivery platform 130 of FIG. 1. The service delivery system 200 includes the service delivery platform 130, a service activation function 202, a service integration and management function 204, an operations support system 206, business support systems 208 and service platforms 210. The SDP 130 is a core engine that encapsulates support services for value added services that might be offered by the service provider. The SDP 130 includes service creation, service deployment, service enablement and service assurance capabilities as will be discussed below.
The service activation function 202 permits initiation of service provision to one or more customers. It presents a user interface or other access portal to a customer of the service provider or an agent or operator working on behalf of the service provider to activate the service. This function 202 also allows subsequent modification of the service, such as adding or deleting capabilities. The customer may access this function 202 himself, such as over a World Wide Web interface or through a telephone menu system. Alternatively, the customer may engage the operator in a phone call or live online session, or by any other means, to specify the service requirements.
The service integration and management (SIM) function 204 includes a customer relationship manager (CRM) front end 212 and a portal 214. The SIM function 204 allows users, both internal users such as operators and customer relations managers and external users such as customers the ability to access and use SDP services. The CRM front end 212 provides the hardware and software for interacting with a customer or operator. Any suitable customer relations management device or service may be used. Examples include call center software and hardware which allows customers to speak by telephone with operators and allows the operators, in turn, to activate and update service provisioning using the service delivery platform 130. To this end, the CRM front end 212 interacts with a CRM interface web service 216 to access data and other information of the SDP 130. The SDP 130 has a counterpart CRM integration adapter 218 which communicates with the CRM interface web service 216, preferably using internet protocol (IP) or other standard data communication.
The portal 214 allows outside users access to the SDP 130 and includes a portal interface web service 220. The SDP 130 has a counterpart portal integration adapter 222. Again, the portal web service 220 and the portal integration adapter 222 preferably use internet protocol (IP) or another standard. Customers may utilize external customer relation management (CRM) systems to request service activation. The customers will purchase product services or packages offered by service catalog for the external systems, not for the SDP. The portal 214 allows communication between the SDP 130 and these external systems.
The operations support system (OSS) 206 provides inventory control, monitoring, etc., and is integrated with the SDP 130. The OSS 206 includes an inventory/resources function 224 and a manager of managers (MOM) 226. The OSS 206 permits integration between the SDP 130 and new or pre-existing OSS systems for the enterprise. In one embodiment, the OSS 206 uses Microsoft's EAI middleware, BizTalk, to offer coded business events, a fundamental architecture backbone, workflow management, data requirements, and data transformation rules required to integrate the service provider's Customer Relationship Management, Billing, and Provisioning Services.
The inventory/resources function 224 operates with an inventory/resources web service 228 which communicates with a counterpart inventory/resources adapter 230 of the SDP. Similarly, the MOM 226 operates in conjunction with a MOM interface web service 232 which communicates with a counterpart MOM integration adapter 234 of the SDP 130.
The business support systems 208 provide billing, customer relation management functions, etc., and are integrated with the SDP 130. The business support systems (BSS) 208 include a billing function 236, an invoicing function 238, a customer insight function 240 and a customer relation manager 242.
The BSS 208 receives billing records and other information about the provision of services to the customer by the service provider. Billable data records as created by a metering service are submitted to the back-end billing system 236 for billing and real-time charging purposes. Billing integration with BSS allows operators to effectively monetize their services to customers based on their service usage and to prevent revenue leaks due to missing service events.
The billable data records submitted to the operator's business support systems are also be used by the invoicing function 238, the customer insight function 240 and the customer relation manager 242. The invoicing function 238 uses the billing data records and other user account information to prepare and send invoices to customers. The customer insight function 240 extracts information about customer behavior, purchasing patterns and so forth. For example, this function 240 enables service providers to analyze service usage activities of subscribers based on access history in order to generate abstract usage patterns and supply such valuable insight to value-added services for fine-tuning personalization engines. The customer relation manager 242 monitors controls the way in which interaction with a customer is tailored to each individual customer, based on other information about the customer, such as services purchased, payment patterns, etc.
The billing function 236 interacts with the SDP 130 using a billing interface web service 244. The SDP 130 has a counterpart billing integration adapter 246. Similarly, the invoicing function 238 interacts with the SDP 130 using an invoice interface web interface 248, which communicates with an invoicing integration adapter 250 of the SDP 130. The customer insight function 240 interacts with the SDP 130 using an insight interface web service 252, which has a counterpart insight integration adapter 254 of the SDP 130. Lastly, the CRM 242 interacts with the SDP 130 using a CRM interface web service 256, which in turn has a counterpart CRM integration adapter 258.
FIG. 3 is a functional block diagram of a Service Control/Order Management Component Architecture 300 for use in the service delivery system of FIG. 1. The component architecture 300 is divided up in the four Service Control/Order Management Component modules that make up a larger infrastructure interoperating with the Enterprise Messaging Backbone.
The Service Control/Order Management Component provides integrated subscriber and service management. It includes common logic that allows resources and services to be dynamically configured based on user profile, service definition, policy information, current resource allocation, and resource state.
This environment shall also consist of the control services that provide identity management for access control, metering service for creating billable data records, profile and personalization management, notification engine to support push-based alerts to customers, and content provider services that facilitate the integration of SDP with content providers.
These modules include a Service Deployment Environment 302, a Service Creation Environment 304, a Service Enablement Environment 306 and a Service Assurance Environment 308. In addition, in the illustrated embodiment, the component architecture 300 includes a Service Interaction and Management Environment 310. This environment 310 may be omitted from some embodiments of the SDP architecture. However, when included, it is tightly integrated to the SDP architecture. The environment 310 provides the interfaces through which users interact with services.
The Service Deployment Environment 302 provides deployment tools and mechanisms and resource management to help system administrators to manage deployed services in a distributed network. This module provides resource management that helps system administrators to manage deployed services in a distributed network. As an example, it supports the integration with content distribution networks to distribute services to operators' edge networks on a global scale to enable customers to access services hosted by the nearest servers.
The Service Creation Environment 304 consists of several subsidiary components that allow for the creation of new services to be introduced to the Service Control Environment. Further, the Service Creation (SC) Environment 304 provides a development environment for software developers to create new services and to extend existing ones. The Service Creation Environment 304 simplifies the creation and reduces the time-to-market of new services. This module further provides the service catalogue that manages the services, an integrated development environment, and platform software development kits (SDKs) to facilitate the creation of new services. It also helps content providers create new content applications that leverage the services from the SDP.
The SC Environment 304 provides a development environment for software developers to create new services and to extend existing ones. It simplifies the creation and reduces the time-to-market of new services. Essentially, this environment creates necessary capabilities to host new services and deploy them to the SCM environment so that the customers can sign-up, configure and receive any information services that are hosted and managed by the SDP.
The SC Environment 304 is comprised of the following modules. These modules create and port-in any necessary capabilities to deliver new or updated data services to the customers;

- Avanade Connected Architecture .NET 3.0 (ACA.NET)
- Service Configuration Tool
- Web Services based Service Directory
- Integrated Development Environment (IDE)
- Product-specific Software Development Kits (SDKs)

Integrated Development Environment (IDE) and development toolkit should be utilized to facilitate building of new features and services that utilize component oriented, service building blocks that to build new services. ACA.NET provides APIs to third party developers and includes deployment infrastructure. Service Configuration Tool facilitates building of Execution and Control and Management functions capabilities. In addition to the above modules, a testing environment can be set up to check for any errors before the new services are launched to the SCM environment.
ACA.NET is a set of application blocks that are generally built on the Microsoft.NET platform. ACA.NET complements and extends the .NET framework with common architecture and services. Additionally, the ACA.NET framework is built on the new development paradigm of Service Oriented Architecture (SOA). Additionally, ACA.NET is configurable based upon Aspect Oriented Architecture (AOA) which allows the behavior of an application to be configured via XML configuration files and attribute declarations instead of programmatically. ACA.NET is intended to abstract the infrastructure details of messaging between objects away from developers allowing the developers to concentrate on enabling functionality while ACA.NET generates the necessary plumbing.
ACA.NET is composed of a Service, Framework, and Aspect architectures. The Service architecture consists of the business logic and the communication infrastructure. The Service architecture enables messaging between objects via transports. Messages have a type and wire format specific to the system being built. Messages can be serialized and marshaled. The transports include web services, .NET Remoting, and in-process function calls.
The Framework architecture consists of “mainline” core functionality such as data access and manipulation and “sideline” functionality such as caching and remoting. The Aspect architecture allows behavior declaration to instance objects that enable the Service and Framework architectures. Using ACA.NET, developers can quickly create and enable applications that can be easily deployed on the SDP platform. ACA.NET also has wizards to transform existing classes and components into Web Services without writing any new code. There are no API calls into the framework so misuse of the framework and bugs are eliminated or reduced. Also, services can be deployed over multiple transports without affecting service code. Lastly, application logic is protected from changes in communication technologies. Overall, ACA.NET 3.0 allows developers to create loosely coupled applications that communicate to compose large, complex systems.
For any application that a vendor or service provider intends to create, ACA.NET automatically generates the code for the sender and the receiver and the underlying transports that are used to communicate messages with the service layer, which is the core functionality that is developed by the vendor. Using this model, vendors can rapidly develop applications that can be seamlessly deployed within the SDP environment.
ACA.NET is based on Aspect Oriented architecture. Aspects are a declarative way to control the behavior of an application's functionality. Aspect attributes are set through XML configurations rather than programmatically through code. This reduces the amount of custom code and increases consistency throughout an application. An example of Aspect Oriented Architecture is Authorization. Virtually all applications must use some form of authorization, regardless of how it may be implemented. The basic functionality for authorization remains the same for all applications. Thus, using ACA.NET vendors can quickly configure global attributes for authorization then using minimal code can implement it as desired while certain core functionality remains centrally controlled.
The Service Enablement Environment 306 provides support for the execution of SDP and value added services. This includes service control, service orchestration and management and service execution. The Service Enablement Environment 306 includes a Service Brokering and Integration Environment 312, a Service Control module 314 and Service Execution module 316.
Although the central core functionality of the SDP platform is the BizTalk integration, several areas of functionality must remain consistent throughout the solution. In order to meet immediate requirements and provide a scalable system that allows future enhancement, a standard platform must exist. This standard platform ensures common methods for data access, exception handling, security, and logging. The use of ACA.NET as a foundation ensures that development will be consistent and reliable throughout the application lifecycle. Additionally, configuration and maintenance will be reduced as well as shortening the development time.
ACA.NET can also help vendors extend their applications into other areas of the SDP platform by enabling them to quickly and efficiently write to Microsoft Exchange Server, Microsoft Active Directory, or Microsoft Operations Manager (MOM). For example, the ACA.NET Framework writes significant events to the event log, providing a way to debug the application during development and after deployment. It also helps administrators detect and diagnose problems when they occur. The critical events in ACA.NET are not only logged to the event log but also published as WMI events. The message in any of the event logs contains detailed information and is human readable. Each event ID is defined distinctly within each framework and therefore can be used as an event filter by monitoring tools such as MOM.
ACA.NET reports significant events within the frameworks through the publishing of WMI events. These events cover all the events that the ACA.NET Framework writes to the NT event log. The mechanism by which Windows collects performance data on various system resources is called the performance counter. Performance counters can provide useful information on how the system is running. They not only provide statistics on how much stress a system or application is under, but also allow the application throughput measuring. ACA.NET takes advantage of performance counters to expose the inner health and stress of the framework to monitoring tools. Applications built with ACA.NET have critical performance counters built-in just by using the framework.
The events generated by the ACA.NET framework (for example, a Data Service configuration failure) are written to the event log by default. With the ACA.NET Logging Service you need the configuration to use the EventLogSink, run the Log Distributor, and then call WriteToLog in your code to write to the event log. The ACA.NET Framework instrumentation event log uses the name of the framework that the event originated from as the event source of the logged message. Using ACA.NET operators can quickly enable existing applications as web services and extend them to use server other server and system components much more efficiently than would be possible without ACA.NET. Additionally any new development can be developed more quickly and with more consistency, allowing developers to concentrate on the core services rather than communications within the application or within an integrated system.
The Service Brokering and Integration Environment 312 consists of service orchestration that provides rule-based process scheduling and integration services that integrate the service delivery platform with content management, BSS, OSS, and device management systems to provide end-to-end services to customers.
The Service Control module 314 provides integrated profile and service management. The Service Control module 314 includes common logic that allows resources and services to be dynamically configured based on user profile, service definition, policy information, current resource allocation, and resource state. Accordingly, the Service Control module 314 includes an Identity Management and Administration function 318, a Profile Management function 320, a Service Catalog 322, a Security Policy Management module 324 and a Reporting/Auditing function 326.
The Identity Management and Administration function 318 allows management and control of identity information for service subscribers. Operators need an identity management solution to prevent unauthorized access to their services and protect the privacy of customer data. By providing effective security management for identity data, the identity management system also helps to prevent the revenue leakage problem that results from identity theft and malicious attacks, which has plagued operators on a global scale.
Accordingly, in one embodiment, the Identity Management and Administration function 318 includes an Access Management function, a Confidentiality function, an Identity Integration function, a Unified Directory and provision for Single Sign-on. Identity Administration applies to identity lifecycle management; that is, the provisioning and maintenance of digital identities for customers and content providers. The Access Management function is the service associated with establishing, enforcing, and managing the authentication, authorization, and auditing policies for customers and content providers. The Confidentiality function applies to protecting the privacy of connections between customers and services and securing identity data managed by SDP against unauthorized access. Identity data is often distributed in multiple systems within an operator's environment, or across different Internet communities. The Identity Integration function represents a holistic approach to the management of distributed but interrelated identities in separate repositories by providing a consistent, accurate representation of identities across heterogeneous systems while recognizing the identity ownership roles of individual systems. The Unified Directory is a consolidated or federated database for managing subscriber, service, and device information. Single Sign-on is a mechanism to verify a user across multiple applications through a single authentication challenge.
The Profile Management function 320 allows management of subscriber and other profiles. Information about subscribers, networks, and services are managed in profiles. A profile is a container of properties for a particular subject. Profile management function 320 manages the following profiles.
Network Profile. This profile contains properties about the operator's CDN that the SDP deployment environment supports for deploying services onto servers on edge networks. It also contains profiles for network elements in the operator's network including SMS, MMS, HLS, and others.
Subscriber Profile Each profile contains identity data about a subscriber, including the subscriber's registered account name and access credential, address, and other identity data. It also contains preferences, subscriptions, summarized usage patterns, and device configurations for the subscriber.
Content Provider Profile Each profile contains the identity data about a content provider, which is used by the content provider service to manage the access to the operator's SDP system from content providers.
Service Profile Each service deployed by the operator needs to be managed in profiles in order to facilitate operations management. The service profiles also facilitate access to each service from device applications.
The Service Catalog 322 includes a business level set of service and products that are used to manage packages and offers that are sold/resold to customers and resellers. The Service Catalog in one embodiment is organized as follows:
Product A Product is hardware or software used to provide a consumable unit of service. Each product is based on an application and/or hardware that enables services and service variants.
Service A Service is an atomic derivative of a Product (i.e., the minimum possible) that offers a consumable unit of service. For a given product, SDP can support one or many services.
Service Variant A Service Variant is a catalog unit derived from Service that contains configured details and attributes that define a set of unit of service. The system supports creating different variants of every service, so that the service is offered to different types of target users.
Offer An Offer is set of Service Variants for presentation to customers for purchase. Service offers consist of one or many Service Variants. It can also include other offers.
Service Group A Service Group is a container used to allow customers to group end-users and link the accounts to a service template. In this context, a customer is a service provider and an end user is a service subscriber.
Solution A solution is a set of service variants or offers that represents a customer's right for subscription. When a customer subscribes to an offer or service variant, that selection becomes a solution for that customer. The customer's end users or subscribers will be eligible to utilize the corresponding services that are included in the solution.
The Service Catalog provides all the necessary information about value-added services that can be hosted on the Accenture's SDP. It is a reference data source that will describe the product and feature information, network location, configuration, and access mechanisms of each service. SDP supports two different ways in which the service activation request can be submitted to the SDP:

- The service activation requests can be created by bundling service catalog information from the SDP's portal and submitted directly to the SDP.
- The customers can request service activation by purchasing products and packages from external CRM systems such as Siebel platform and send the requests to the SDP for processing.

The Service Catalog helps the customers who are requesting service activation or configuration directly from the SDP's portal by presenting all the selectable options and features for desired value-added service. The Service Catalog will be retrieved and configured into the SDP's portal so that the customers can “browse” through the catalog to select the products and features for the service activation.
The catalog elements can be selected by the customers on the portal and submitted to the SDP as part of a service activation request order. The order management module is responsible for pre-preprocessing the service activation requests, and the Provision Engine picks up all the selected catalog items and provisions them as service products and features. During the service activation process, the workflow manager may trigger billing events based on the catalog items selected by the customers to properly bill the customers for the products and features.
For the instances where the customers utilize external CRM systems to request service activation, the customers purchase product services or packages offered by the service catalog for the external systems, not for the SDP. Therefore, the external catalog only provides product and feature information for service activation. The SDP's service catalog then complements this by providing other technical information about the services such as service configuration, network resources, and access mechanisms to deliver the services that are being activated. The SDP's service catalog should be comprehensive to accommodate the service activation requests sent by external systems.
The identity management solution for SDP provides four major functions:
Identity Administration

- This applies to identity lifecycle management; that is, the provisioning and maintenance of digital identities for customers and content providers.

Access Management

- This is the service associated with establishing, enforcing, and managing the authentication, authorization, and auditing policies for customers and content providers.

Confidentiality

- This applies to protecting the privacy of connections between customers and services and securing identity data managed by SDP against unauthorized access.

Identity Integration

- Identity data is often distributed in multiple systems within an operator's environment, or across different Internet communities. Identity integration represents a holistic approach to the management of distributed but interrelated identities in separate repositories by providing a consistent, accurate representation of identities across heterogeneous systems while recognizing the identity ownership roles of individual systems.

The Service Control module 314 further includes the Security Policy Management module 324. Within this the SDP, the Security Policy Management module 324 provides a single authoritative, integrated and federation directory, provided via Active Directory and interoperating with an SDP Access Manager to ensure that capabilities and information with the platform are relevant and private.
The Security Policy directory may be characterized by a Role and a Privilege. A Role is a business classification assigned to a customer or account that is defined by a set of characteristics or privileges. Usage of the Role in SDP allows for specialized distinction of abilities to represent a business function, such as a value added reseller (VAR) as a role, where the VAR role represents each of the abilities that a VAR or accounts of a VAR is able to perform. A Privilege is a business characteristic or right that is represented in SDP. An example of this may be the right to create an account or over-ride service pricing. The grouping of privileges defines the Role and within SDP, the usage of Role and Privilege is extremely flexible and is not defined via inline code. What this does is allow SDP to define new roles and new privileges as extended capabilities and new business agreements are formed.
The Reporting/Auditing function 326 provides standardized logging functions to support reporting and audit functions. In one embodiment, this is characterized by the following:
Activity/Availability: SDP activity and availability reporting. This may include service uptime, transactions/sec, active users, time based activity, etc.
QoS/GoS: Quality of Service and Grade of Service reporting. This can include reporting over platform and over value added service (VAS).
Service Usage: VAS usage reporting, including either VAS specific or platform general information. Platform specific reporting includes information such as subscription to service, most common used services and most common used features.
Events/Auditing: SDP events and auditing logs. This includes, for example, a number of failed login attempts, login history, suspension history, etc.
Performance: reporting on platform health. This includes metrics-based reporting on counters such as average provision time, number of expired processes, number of retry attempts, active accounts, etc.
Resource: Reporting over SDP physical and logical resources that cover each Service. This may include quota levels, resources exceeding critical level, resources over utilized, resource over time, etc.
End-User: End-User reporting, number of services, subscribed service health.
Customer: Customer reporting, number of services, number of accounts, service usage, resource usage, etc.
Other types of reporting and reporting content may be included or substituted as well.
The Service Execution module 316 forms a standardized framework and architecture to execute services for a subscriber or an application. The Service Execution module 316 encourages reuse of existing components such as a VXML media server. The Service Execution module 316 leverages a set of common services such as authentication, authorization, presence, and personal information management functions. The Service Execution Module 316 includes in one embodiment Service Gateways 328, Service Building Blocks 330 and Infrastructure 332.
The Service Gateways 328 are responsible for managing solutions for customers and value-added resellers (VARs). A Solution is a container for the Service Variants and Offers selected by a Customer to be reserved for their Users. In the illustrated embodiment, there are two types of service gateways. The first type is Third Party Service Access Gateways, which extend the service delivery platform to support third party retail and wholesale service providers such as content providers, gateway providers and retail channels. The second type is Network & Service Gateways which provide interfaces to network and service elements to allow higher layer service logic to access them in a standardized and protected way.
The Service Building Blocks 330 provide a set of common services and resources that are generally common to all SDP value added services. The Service Building Blocks 330 provide synergy across products and simplify handling of special customer requests. Several exemplary building blocks are described below. Many others may be included as well.
A Session/Signaling building block provides real-time management of a service session for data, voice, and video applications. This building block also signals the appropriate network and service elements to set up one or more sessions in order to deliver service. Further, the Session/Signaling building block maintains the session as required to support the service. Examples include a call agent using session initiation protocol (SIP), H.323 data communication protocol, Media Gateway Control Protocol, etc., SIP proxies, a Video on Demand (VoD) server, SS7 to PSTN and mobile networks, etc.
A Content Management building block provides content provisioning and management capabilities including Digital Rights Management (DRM). Further, this building block may be shared across services such as internet protocol television (IPTV), VoD) and it provides provisioning and management application programming interfaces (APIs). Also, the Content Management building block provides a mechanism for real-time interaction with content by working with security access authentication modules such as “authenticate user,” “check parental controls” and other access, providing uniform resource locators (URL) to a content delivery network (CDN) and correctly encoded content, and providing a DRM key to access content.
A Notification Engine building block provides a high-performance platform for scalable notification services that generate messages customized to meet target subscribers' specific needs. The notification messages, or alerts, can originate from a variety of sources such as external data feeds and data updates by value-added services, and they can be delivered to various devices including pocket PCs, PCs or mobile telephones through multiple communication channels. Typical notification messages include those for appointment reminders, flight delays, and availability of new service or content. The Notification Engine in one embodiment is an orchestrated process that supports event collection, event generation, event distribution and subscription.
A Presence/Location building block provides common service for managing state and context information for users, applications, and devices, such as IP address, bit rate, network location, device, preferences, etc. Further, the Presence/Location building block keeps track of current user and service profiles including user preferences and subscribed service profiles. Also, the Presence/Location building block forms a centralized or federated repository for managing user and service profiles including features and parameters needed to execute services. Still further, the Presence/Location building block provides protocols and interfaces for accessing and updating presence/state information. Examples of such protocols include Session Initiation Protocol for Instant Messaging and Presence Leveraging Extensions (SIMPLE), Extensible Messaging and Presence Protocol (XMPP) and Java Message Service (JMS). Examples include a Class 5 Switch subscriber/service database, a Remote Authentication Dial In User Service (RADIUS) server, a Wireless Home Location Registrar (HLR) and the Third Generation Partnership Project IP Multimedia System (3GPP-IMS) Home Subscriber Server (HSS).
A Security Services building block provides common authentication and authorization services that can be shared across applications and services platform.
A Presentation/Rendering building block provides real-time data transformation and formatting to support different types of devices such as extensible markup language (XML), hypertext markup language (HTML), and wireless markup language (WML). The Presentation/Rendering building block also provides format conversion functions on behalf of servers and devices.
A Metering Service building block acts as a mediation system between the service providers and billing systems. This building block is an orchestrated process that supports; event collection, aggregation, transformation, tracking and submission. This building block receives or captures events in call detailed record (CDR) format from other services for tracking and billing purposes. The building block further integrates with the operator's billing system by converting CDR data to billable data records and submitting them to the operator's billing system for real-time charging and billing purposes. Further, the Metering Service building block supports multiple units of measurement by event type, volume (in bytes), time, locality, and content type, based on business requirements. Preferably, the Metering Service building block supports the use of Internet Protocol Detailed Record (IPDR) as the standard data format for billable data records and supports Charging Control which allows integration with billing engines to support pre-paid environments such as real-time signaling networking and post-paid environments, and combinations.
The Metering engine receives or captures events in call detailed record (CDR) format from other services for tracking and billing purposes. It integrates with the operator's or service provider's billing system by converting CDR data to billable data records and submitting them to the operator's billing system for real-time charging and billing purposes. It supports multiple units of measurement by event type, volume (in bytes), time, locality, and content type, based on business requirements.
The metering engine is an orchestrated process that involves the following tasks:
Event Collection

- Receives and captures events from other services and SDP. Product catalog pricing and subscription level information will be captured and input into CDR in a consistent and routine manner. Collection data will include detailed information of bundle, product, pricing, discounting, and even description.

Aggregation

- May aggregate multiple CDRs or consolidate one CDR with other data into one billable data record. CDRs will be grouped during each billing cycle linked by shared account number that the billing system will also use or reference.

Transformation

- Transforms CDR data into billable data record formats accepted by specific billing systems. This transformation also includes the creation of summary level billing items, such as discounting totals, grand totals, usage & tiered based pricing.

Tracking

- Records each CDR for tracking and auditing purposes. Each process in the billing cycle event are tagged with a tracking code or status. These tracking codes are used to properly handle the work process in the processing of all events and billable accounts in the SDP solution.

Submission

- Submits billable data records to billing systems through the BSS Integration Service. The SDP solution submits in a configurable schedule and contain run-time business logic to determine the integration source for generated bill records.

To provide operators maximum flexibility in integrating diverse billing systems, the metering service supports the use of Internet Protocol Detailed Record (IPDR) as the standard data format for billable data records. IPDR is a standard defined by IPDR.Org, an open consortium of leading service providers, equipment vendors, system integrators, and billing and mediation vendors collaborating to facilitate the exchange of usage and control data between network and hosting elements and business support systems. IPDR defines an XML-based schema to represent CDR details for billing purposes, and it is widely supported by many leading billing systems vendors.
A Media Services building block provides media access and delivery services and provides a request/response mechanism for accessing multi-media such as audio, video and data. Further, the Media Services building block supports protocols for delivering media to devices, applications, and users, and provides media transformation capabilities and encoding and decoding services. Examples include a VoD server, CDN, Broadcast TV head-end, a Web server using HTTP/HTTPS, an audio server and a VoiceXML Media Server.
A Media Gateways building block provides a translation function between media streams for different networks and clients. Examples include a voice over internet protocol (VoIP) to time division multiplexing (TDM) media gateway and other vocoding devices.
A Bridging building block bridges media such as voice, video and data for multi-user collaboration. The building block preferably ideally supports reformatting to different devices such as Media Gateway functions. Examples include voice conference bridges, data conferencing such as the facilities provided by WebEx, PlaceWare and MeetingPlace, and video conferencing.
A Naming/Routing building block provides a name resolution mechanism for identifying services and resources in networked environment. Further this building block provides routing service to determine the optimal path and allocates networked resources. Still further, this building block dynamically assigns resources to devices and servers.
A Messaging building block provides various forms of messaging between addressable users, devices, and applications and provides protocols, routing, and data stores to deliver messages. Further, the building block provides channel and routing mechanisms to support notification services. Examples include electronic mail (SMTP, POP3, IMAP), instant messaging, voice mail, fax and short message service (SMS).
A Synchronization Services building block manages and synchronizes information between applications and servers that need to use similar information. Examples include a Personal Information Manager (PIM) calendar and contacts across devices, such as Microsoft ActiveSync.
The Infrastructure 332 of the Service Execution Module 316 allows for a set of Next Generation Network (NGN) services to facilitate support of emerging and future value added services. The Infrastructure 332 includes and is not limited to in an all-IP network approach to the support for Data, Voice, Wireless, Rich Media Content, and Unified Messaging Services.
The Service Brokering and Integration Environment 312 provides support for the execution of Service Control/Order Management and value added services. This environment 312 includes Service Control, Service Orchestration and Management and Service Delivery. The environment 312 includes several modules, including a Process Management module 334, an Order Management module 336, a Provisioning Management module 338, a Content Management module 340, a Network Integration module 342, a Device Integration module 344, and a OSS/BSS Integration module 346.
The Service Brokering component in SDP is a set of core service control elements designed to control network resources and coordination of services. Resource control will allow fundamental control to the Service Execution infrastructure for management of ports, server connections, and other when customers access service resources. The service resources will work to monitor and control quality of service (QoS) to allow for efficient usage of service resources. This will involve reallocation, redirection and denial of services in order to maximize the availability of the service resources.
The Process Management module 334 coordinates information flow within SDP, acting as a message processing backbone. Further, the Process Management module 334 enables integration of all internal (enterprise application integration, or EAI) and external (business-to-business, or B2B) applications and services. The Process Management module 334 is further responsible for orchestrating and executing workflow. In one embodiment, it is implemented with Microsoft BizTalk Server 2004, but other implementations are possible.
The Order Management module 336 interacts with one provisioning system or trading partner at a time, accepting complex orders to be “decomposed” into more atomic “work orders” to be workable by provisioning entities. This module creates work orders based on decomposition criteria, dynamically releases work orders and validates work orders.
The Provisioning Management module 338 receives, processes, and fulfils the provision requests for authorized users. The Provisioning Management module 338 in one embodiment consists of capabilities for service provision management and directory provision management.
The Content Management module 340 implements an offer syndication process that includes the acquisition, aggregation, transformation, staging, rating, and publishing of a variety of content from content providers and aggregators.
The Network Integration module 342 leverages the network service elements, such as those for MMS, SMS, ILS, SIP, and so on, to provide end-to-end solutions for customers. The Network Integration 342 leverages the network service elements, such as those for MMS, SMS, HLS, SIP, and so on, to provide end-to-end solutions for customers.
The Content Integration 344 operates to simplify integration tasks, connect through an adapter to retrieve content and provide the content to the value-added services which provision them to customers' devices.
The Device Integration module 346 provides device management and device adaptation for value-added services. This includes fault management, or the process of identifying and fixing device-related system or application problems and faults and configuration, or providing device configurations. The also includes accounting, or managing profiles and service usage of all devices, and performance, or identifying network congestion or system performance issues and providing fixes, and security, including ensuring access to specific services.
The OSS/BSS Integration module 348 provides a common framework for integration with OSS, including device services; BSS, including billing system; and network service elements, including LBS, SIP, SMS/MMS, and HLS.
The Service Creation Environment 304 is a development environment for software developers to create new services and to extend existing ones. The Service Creation Environment 304 simplifies the creation and reduces the time-to-market of new services. The Service Creation Environment 304 includes a Service Directory 350, an IDE and .NET Framework 352, a Service Configurator 354, Software Development Kits (SDKs) 356, and user interface (UI) Widgets and Wizards 358.
The Service Directory 350 enables developers to discover, select, and reuse components from each service in creating new services and extending existing ones. Since its delivery of services relies on web services, standards such as UDDI and WSDL are used.
With respect to the IDE and .NET Framework 352, the SDP in one embodiment is built on Microsoft's .NET Framework using Visual Studio .NET as the integrated development environment (IDE). The Visual Studio .NET provides a Rapid Application Development environment for service creation. Developers can develop new services with a variety of .NET compliant programming languages.
The Service Configurator 354 is used to dynamically generate ASPX pages, the controls and the properties associated with these controls, thus enabling customization of web pages by each client. The SDKs 356 are resources for software developers. In addition to the IDE, developers can take advantage of product-based Software Development Kits (SDKs) in creating new services, or expanding the existing ones. Finally, the UI Widgets and Wizards 358 are a set of libraries to facilitate the creation of new service control and management pages. The power of this is insuring the modularity of user interface (UI) code, consistency with style sheets and reduced programming time for reusable widgets
The Service Deployment Environment 302 provides deployment tools and mechanisms and resource management to help system administrators to manage deployed services in a distributed network. The Service Deployment Environment 302 includes a Configuration Management module 360, a Patch Management module 362, an Image Management module 364, a Capacity Management module 366, an Inventory Management module 368 and a Resource Management module 370.
While it is important to enable developers to quickly develop new services under the SDP, it is equally important to enable operators to manage the deployment of new services in the core networks or content deployment networks. The SD environment shall provide the following functions:
Deployment Tools

- Help to automate the deployment process in order to reduce complexity and eliminate downtime.

Support for Content Deployment Network

- Content deployment network helps operators to deploy services on edge servers in the operator's content deployment network or content deployment network-like environment, in order to improve accessibility, reduce latency, and customize data based on the customer's locale. The Service Deployment environment of SDP supports deployment with third-party content deployment network systems.

Resource Management

- Administrators must be able to manage information about the deployed services in terms of version numbers, operating system, system configuration and hardware configuration. The Resource Management (RM) module stores and manages resources needed for activation of services. Key strengths are:
- The RM module will support at least the following kind of resources:
  - Sequence-based resources (such as UIDs)
  - Limited resources (such as dedicated servers)
  - Round-robin resources
  - Manually managed resources
  - IP blocks (for managing IP addresses)
    The RM module should have a web-based tool in order to manage resources, thresholds, constrains and alarms

The Configuration Management module 360 is responsible for managing the attributes and values that make up and define a service. This model provides the flexibility for SDP to implement and deploy Services in the future that could not initially be foreseen. Using an adaptable and configurable model ensures that within SDP there is a standard understanding of what constitutes a Service so that other components are able to access and operate effectively.
The Patch Management module 362 is responsible for ensuring that the latest security updates and patches are installed for Services. SDP includes a Patch Management module 362 that manages hardware updates, application updates, operating system updates, scheduling management, inventory detection and roll back automation.
The Image Management 364 is designed to rapidly deploy new OS and application images to physical or virtualized hardware for the service provider enterprise to deploy new Services and scale out for future demand. This reduces deployment time and defects by using hardened and repeatable deployment images
The Capacity Management module 366 captures and manages the capacity levels and sources and contains a library of functions used to perform interaction with asset management and resource threshold. From the SDP side, capacity tracking is performed via tools like Operations Manager (MOM), System Management Server (SMS) and other tools. From the services side, performance thresholds that feed into capacity tracking are performed.
The Inventory Management module 368 is also known as Asset Management. This module considers the entire asset life cycle, from procurement through disposal. It enables the service provider to track and control both hardware and software. It accounts for and empowers the service provider to administer all financial and contractual aspects of the service provider's information technology (ITA) environment. This module also allows the service provider to take control of hardware and software inventory, track corporate contracts, fixed assets, and determine TCO of all of SP's assets
The Resource Management module 370 is a comprehensive set of capabilities that allow for: resource partitioning, assignment of resources by sequence, manual, round-robin, limited resource, physical resource limit checks or reserve/release resource. The module 370 operates at a logic level, working with resource pools and quotas, and at the physical level where it is able to check and notify when resources are over allocated or nearing limit.
The Service Assurance Environment 308 provides monitoring and management functions for the SDP infrastructure and services. The Service Assurance Environment 308 includes a Business Activity Monitoring module 372, a Fault & Availability Monitoring module 374; Performance Monitoring module 376, and an Event Monitoring module 378. This module provides management functions to manage the deployment and execution of services in the operator's network, which include security, service, and service level agreement (SLA) management.
The Service Assurance environment provides management functions that span all the layers in the SDP framework. At a high level, it provides the following functions for the SDP and the value-added services:
Fault Management

- This service quickly identifies problems and faults in the network or services with real-time service monitoring and alerts systems administrators with accurate problem descriptions. This service also provides automatic fail-over services in the event of unexpected system failures. Fault management is the ability to locate faults, determine the cause, and make corrections. It also includes implementing fault-tolerant hardware systems and fault-tolerant procedures. Fault management involves the following

Configuration

- This service manages configuration, such as settings, policies, version controls for all the services. This service further manages the change control for all the software components.

Accounting

- This service tracks detailed activities and changes for all the services and provides historical logs for auditing purposes. Accounting is essential to measuring all aspects of the system to ensure SLA compliance.

Performance

- This service monitors the performance of each service and the whole system, and identifies and reports performance-related problems to system administrators for trouble shooting and problem solving. This service further provides summarized reports on system performance for decision makers. One of the main reasons of an application or system failures are a condition of extremely degraded performance. Performance management allows high levels of application performance in a server based computing environment.

Security

- This service manages the security implementation for all the services and the operator's network to detect and prevent unauthorized intrusions, denial of service attacks, and any suspicious activities.

The Business Activity Monitoring module 372 performs the real-time monitoring and access to key business and service performance indicators of up to date, live and relevant information for the purpose of improvement of the management and operations of the platform and its services.
The Fault & Availability Monitoring module 374 provides the ability to locate faults, determine the cause, and make corrections. This module also implements fault-tolerant hardware systems and fault-tolerant procedures. Fault management involves the continuous monitoring and the collection of statistics on servers, traffic conditions, and usage so potential faults can be forecast and avoided as well as setting threshold conditions, alarms, and the ability to remotely control servers and other devices to perform some or all of the preceding tasks from a single management location.
The Performance Monitoring module 376 provides improvement of application response times, management of server processor and memory resources, prevention of server lockups caused by rogue application, the ability to clamp individual applications to a fixed percentage of processor resource, the ability to identify, in real-time, any number of threads that are contributing to excessive processor load, and then to reduce the load for this set of threads appropriately.
The Event Monitoring module 378 is an underlying operations platform that captures a wide variety of system and application events from servers that are distributed throughout a hosting environment and collects them in a central database. This module supports event consolidation, and the ability to intelligently and automatically determine which items are of critical importance to an administrator.
The various components of the Service Control/Order Management Component Architecture 300 rely on certain core technologies 380 for communication of data. The service delivery platform uses a layered, service-oriented architecture based on open standards enabling interoperability, flexibility, and adaptability. In one embodiment, the core technologies 300 include an Integrated Services Network (ISN). ISN is a run-time component that provides configurable routing based on web services description language (WSDL) documents. ISN maps any WSDL-defined service to another service on any available transport channel. ISN is usually deployed at the firewall and has access to internal services. The ISN provides the following features: Intelligent Routing; Export Routing, Import Services; Security and Management; Transformation; Universal Description, Discovery, and Integration (UDDI) Publication and Lookup.
As noted, a variety of readily available technologies may be used to implement the core technologies 380. Certain core products are used in combination in one embodiment to facilitate the integration of systems and the automation of business processes and the presentation of services in an integrated “dashboard” experience. These products include Microsoft .NET, Microsoft .NET/ACA.NET; Windows Server 2003; BizTalk Server 2004; SQL Server 2000; Active Directory; and Microsoft Provisioning Framework. Other commercially available technologies may be included as well, or substituted, and custom software may replace any of these commercially available applications.
SDP .NET is at the core of SDP as illustrated in the embodiment of FIG. 3. The application is built using Windows Server 2003, IIS 6.0 web server, Visual Studio & .NET Frameworks in C#.NET. The core of SDP is built using Microsoft .NET technologies creating a distributed enterprise application. At the core of the technology include background servicing, scheduling, real-time exception handling, audit logging, Simple Object Access Protocol (SOAP) headers, custom performance counters, caching, remoting, and a Service Configurator. The .NET core includes components written in C# .NET for business functions like, Server Management, Profile Management, Resource Management and Metering
The backbone of SDP business processing is contained in a SDP Middleware component, part of the foundation and core services. The SDP Middleware component is built using BizTalk Server 2004 to leverage the technologies capabilities for state management, Hydration/Dehydration, data transformation, EAI/Adapters/XML interface, dynamic rules processing, status management, automated and human workflow, and integrated visual studio EDI.
In the SDP Middleware component, a Web Service layer simplifies integration with Service Provider infrastructure. BizTalk coordinates actions required to complete requested business processes, such as order entry submissions from a customer relations manager or customer server representative or account management actions by a service subscriber. Custom adapters allow integration with multiple products and platforms.
SDP uses a layered, service-oriented architecture based on open standards enabling interoperability, flexibility, and adaptability. Avanade Connected Architecture (ACA).NET is a set of application blocks built entirely on the Microsoft.NET platform. It is intended to abstract infrastructure details of messaging between objects away from developers and it ensures that development will be consistent and reliable throughout the application lifecycle. Microsoft Connected Service Framework (CSF) simplifies service control, is scalable, reliable and secure, supports a broad range of devices and is based on proven products such as BizTalk, Windows, SQL, Visual Studio.NET, and open standards such as XML, HTTP, and Web Services
The SDP core technologies 380 further includes an SDP database. The SDP database is the central store for Products/Services, Customer profiles, subscriptions, orders, resources, and provision information. The SDP database is interrelated to the core platform and the Unified Directory. Built using enhanced Telecom Operations Map (eTOM/SID) as a basis and implemented using Microsoft SQL Server 2000 on Windows Server 2003. In order to handle the SDP functional modules and capabilities of the application, a Master Data Model (MDM) supports a shared service oriented approach and operates as the data store for all master SDP data that may include services, accounts, events, exceptions, packages, resource metering, billing event data, value-add services, value-add resellers, packages & bundles.
A Unified Directory provides integrated profile and service management. The Unified Directory includes common logic that allows resources and services to be dynamically configured based on user profile, service definition, policy information, current resource allocation, and resource state. The Unified Directory is implemented in one embodiment with Microsoft Active Directory and is responsible for providing a multi-tenant organization hierarchy. All resellers, customers, end-users, service provider, and other forms of organizations and users, will all be contained in an active directory under a service oriented security architecture. What this does is allow everyone to “live” in the same directory while having access only to the little “island” that one is responsible for. This results in a customer only being able to view its own end-users and no one else's.
The architecture 300 of FIG. 3 further includes an Application/Services Gateway 382.: The Application/Services Gateway 382 provides an interface to value added services in the SDP architecture via open standards like Parlay/OSA and proprietary software API's. Opening and controlling access to services allows third party vendors, resellers, developers and external systems to interface with SDP value added services.
FIG. 4 illustrates a physical architecture of a service delivery platform (SDP) 400. The SDP 400 includes a Service Deployment Environment 402, a Service Creation Environment 404, a Service Enablement Environment 406 and a Service Assurance Environment 408. The SDP 400 is operative to control and provide access to one or more value added services, including value added service (VAS) 410. To that end, the SDP 400 has access to the Internet 412 and communicate using data protocols appropriate to the Internet, such as TCP/IP. For implementing the service, the SDP 400 includes a Service Execution Environment 416.
The VAS 410 implements any of a variety of services, including for example telecommunications services. These services may include wire line telecommunication service such as telephone and facsimile service, wireless telecommunication service such as cellular telephone and paging, and internet service, either wire line, wireless or a combination of the two. In the illustrated example, the VAS 410 includes servers and associated hardware and software to provide streaming media, electronic mail service, provisioning, web hosting and real time communications. For particular services, the VAS 410 may include alternative or additional components. The VAS 410 includes a switch 414 in data communication with a switch 418 of the Service Execution Environment 416.
The Service Deployment Environment 402 provides deployment tools and mechanisms and resource management to help system administrators to manage deployed services in a distributed network. The Service Deployment Environment 402 implements in hardware and software the functions associated with the Service Deployment Environment 302 of FIG. 3. The Service Deployment Environment 402 in the illustrated embodiment includes servers and other equipment for Code Migration, Server/Image Deployment, Capacity Planning, Inventory Management, IP Management, Patch Management, Configuration Management, Catalog Importing and Bulk Account Importing. Other devices may be provided as well. The Service Deployment Environment 402 is connected through a switch to the Service Execution Environment 416 and the Service Enablement Environment 406.
The Service Creation Environment 404 includes several components that allow for the creation of new services to be introduced to the Service Enablement Environment 406. Further, the Service Creation Environment 404 provides a development environment for software developers to create new services and to extend existing ones. The Service Creation Environment 404 simplifies the creation and reduces the time-to-market of new services. The Service Creation Environment 404 implements in hardware and software the functions associated with the Service Creation Environment 304 of FIG. 3.
To that end, the Service Creation Environment 404 includes servers and other equipment to implement Version Control, an ACA.NET framework, the SDP framework, a Service Configuration Tool, a Build Directory, a Build Database and a Build Server. These components and optionally others are accessed through a Development Station. The Service Creation Environment 404 communicates through a switch with the Service Deployment Environment 402, the Service Execution Environment 416 and the Service Enablement Environment 406.
The Service Enablement Environment 406 in the embodiment of FIG. 4 includes a Service Interaction and Management Environment 420, a Service Orchestration and Integration Environment 422, a Service Control and Management Environment 424 and Integrated Systems and Applications 426.
The Service Interaction and Management Environment 420 provides a front end or user interaction space for service users and providers. The Service Interaction and Management Environment 420 accordingly includes several servers providing user interface (UI) functionality and databases. The user interfaces include a Self Service UI portal, an Operator UI portal, a Partner UI portal and an Order Entry portal. The Service Interaction and Management Environment 420 further includes a UI Portal database and an Order Entry database accessible by the UI portals. The Service Interaction and Management Environment 420 is connected through a switch with the Service Deployment Environment 402, the Service Execution Environment 416 and the Service Orchestration and Integration Environment 422.
The Service Orchestration and Integration Environment 422 includes an Orchestration Front End Zone 428 and an Orchestration Back End Zone 430. The Service Orchestration and Integration Environment 422 orchestrates various operations required for provisioning, providing and billing for services. The Orchestration Front End Zone 428 includes an SDP Work Flow Orchestration server, a Message Queue Server, an External SDP Web Services server, an SDP Integration Server, and an Integrated Order Manager server. The Orchestration Back End Zone 430 includes a Presence Server, an SDP Work Flow Database, a Message Queue Database and an Order Database. The Service Orchestration and Integration Environment 422 communicates through switches with the Service Interaction and Management Environment 420, the Service Creation Environment 402, the Service Execution Environment 416 and the Service Control and Management Environment 424.
The Service Execution environment provides a run-time environment for controlled services such as identity management for access control, service management, subscriber management, and content management. None of these services works in isolation. In order for the Service Execution environment to execute the necessary business processes to fulfill the requests made by the users of the SDP (via Web Portal), or by the external systems (for example, via OSS and BSS), collaboration among different services in the environment is required.
The Orchestration and Integration component is responsible for the collaboration among different services by providing following capabilities:
Work Flow Management
Business Process Management
Application Integration
As may be seen from above list, the Orchestration and Integration component is not only be responsible for being the information “broker” among all interacting entities, but also be responsible for “orchestrating” the execution of business process based on the logical order of actions and the corresponding flow of messages for given process.
In SDP, the work flow should usually be initiated by the users requesting information services in real-time from the web front-end. However, on some occasions, the flow will be initiated by internal batch applications such as Notification Engine or even by external application like OSS and BSS via receiver adaptors. Regardless of the origin of the flow, the request/message will be first processed by the Orchestration and Integration module upon arrival if the request needs to be work-flowed in order to be fulfilled. Then the Work Flow Management module should make the following decisions in order to forward the request/message to the appropriate processing elements/modules:

- Should the request be forwarded to different module or processed within the Orchestration Scheduler.
- To where the message should be forwarded.
- How incoming message be forwarded based on the system or request status.
  Once the Work Flow Management module determines where to forward messages, the messages can be simply placed onto the adapter for the destination module/application.

The routing rules can be stored into a database table or into a XML document as a look-up file. This maintains the logic in the Work Flow Management being transparent from the specific business rules. This design approach promotes better maintainability and scalability for the Work Flow Management module. Another design option is to utilize BizTalk Server's Business Rules Engine.
However, not all transactions or requests that are submitted into the SDP will be processed via work flow manager. There are a number of requests that can be submitted to the SDP which do not require any kind of work flow due to the simple nature of the requests. For example, the requests to get user account and product lists, and to save profile information about a user should not invoke any work flow to manage and process the requests. These requests, for example, can be fulfilled by calling appropriate API's via interfaces such as web services from the web portal.
One example where work flow management would be required is for the request that interacts with the systems external to the core SDP (for example, CRM or Billing systems) where the requests and responses are not usually synchronized and the whole transaction can be “long-running”. Another example would be where a single request into the system spawns multiple invocations to the different modules in the system asynchronously.
The work flow manager should be utilized or invoked on an as-needed basis, not as a “Gateway” or an “Entry point” to the SDP. It should be transaction-type based. This approach will conserve the system resources for the SDP during run-time and improve overall performance of the SDP platform.
Microsoft BizTalk Server 2004 is implemented as an Orchestration and Integration module within the Service Control and Management and Service Execution environments. It enables integration of all internal (EAI) and external (B2B) applications and services to deliver and provision variety of information services by coordinating the flow of information. Again, in addition to the integration capability, it executes a pre-determined set of business processes according to the Orchestration Schedules that dictate the sequence of tasks to be performed based on the business requirements.
With respect to application integration, several modules within the SDP exchange information and collaborate in real-time to deliver information services and fulfill requests generated by external entities. These include Web Portal, Service Management, Identity Management, Profile and Personalization Management, Content Management, OSS and BSS.
The Orchestration and Integration module acts as an information broker that manages the flow of information for all of constituent applications. In order for any two modules to exchange information, the Orchestration and Integration acts as intermediary. No two modules can communicate each other without the intervention of Orchestration and Integration module. This design option allows easier coordination of information flow and the SDP platform to be scalable for additional functional modules in the future.
The Service Control and Management Environment 424 includes a Service Control Front End Zone 432 and a Service Control Back End Zone 434. The Service Control Front End Zone 432 communicates with the Service Orchestration and Integration Environment 422. The Service Control Back End Zone 434 communicates with local storage 436. The Orchestration and Integration module acts as an information broker that manages the flow of information for all of the above modules. In order for any two modules to exchange information, the Orchestration and Integration acts as intermediary. No two modules can communicate each other without the intervention of Orchestration and Integration module. This design option allows easier coordination of information flow and the SDP platform to be scalable for additional functional modules in the future.
The following are different modes of information exchange between modules that can be implemented in the SDP:
Synchronous Transaction—in real-time mode
Asynchronous Transaction—in real-time mode
Batch Transaction
Design decisions are made in order to determine for each module in the Service Execution environment what transaction mode should be implemented to communicate with the Orchestration and Integration module.
Since the synchronous transaction waits until the response arrives, it is ideally suited for cases in which the immediate response of the transaction is required. For example, the transaction to authenticate a user via Identity Management, or the transaction to display personalized contents via Content Management are ideal candidates for this type of transaction. The XML documents are exchanged between modules as means of communication.
An asynchronous transaction is a bit more difficult to manage, but it allows multiple transactions to be executed concurrently and optimizes resource usage. The Notification Engine within the SDP provides push-based alerts to customers. The requests may be made to the Notification Engine from the Orchestration and Integration module in the beginning of the user session, but the request may not be fulfilled instantaneously. The alerts can be useful to the user if they can be provided anytime during the session, or during allotted system time-out. Hence, this type of transaction can be implemented as asynchronous. The BizTalk Server provides a feature to “de-hydrate” the transaction to store it on the database table if it exceeds given time-outs.
A batch transaction should be implemented for those transactions that have much longer response time, in the order of hours and days. Therefore, the ideal candidates for this type of transaction are that of external organizations. The interaction of the SDP with OSS and BSS can be implemented as batch transactions. Additional complexities arise when interfacing with external organization, and therefore the following functionalities should be built around the adapters for interaction in the Orchestration and Integration module:

- Validation capability to check all the fields in the incoming message based on the Interface Agreements: if the validation fails, the documents are returned to the sender without processing.
- Encoding and decoding capability for encryption: this may be required for secure transmission.
- XML document converter capability: the BizTalk Server can only process XML documents internally. For those organizations that use other messaging mechanisms such as EDI and MQ Series, the incoming messages should be converted into XML equivalents.

In addition to the above components to implement batch transaction, there must be a batch process that constantly run in the background to frequently check the message queues to see if any new messages to receive and to send.
The Service Control Front End Zone 432 includes an Access Control Manager server, a Directory Manager; server, a Role and Policy Manager server, a Single Sign-on Manager server, a Profile Subscription Manager server, a Service Catalog Manager server and an Internal SDP Web Services server. Further, the Service Control Front End Zone 432 includes a Provision Request Manager server, a Service Dispatcher manager, a Metering Engine, a Notification Engine, a Personalization Engine, SDP Core Architecture Components and a Resource Manager server.
The Service Control Back End Zone 434 includes the Unified Directory, a Role & Privilege Database, a Single Sign-on Database, a Profile Subscription Database, a Service Configuration Database and the Service Catalog. The Service Control Back End Zone 434 further includes a Provision Route Rule Database, and SDP Usage Patterns Database, a Metering Collection Database, a Notification Database, a Personalization Database, SDP Core Architecture Components Database and a Resources Database. In addition to the Service Orchestration and Integration Environment 422 and the local storage 436, the Service Control and Management Environment 424 communicates with the Service Assurance Environment 408.
The Service Assurance Environment 408 provides monitoring and management functions for the SDP infrastructure and services. The Service Assurance Environment 408 includes hardware and software for implementing the functions associated with the Service Assurance Environment 308 of FIG. 3.
The Service Assurance Environment 408 includes an electronic support portal server, a web console server, a management console server, a root cause analysis server, a Data Access Consolidator Agent Manager server, a Reporting Server, a Database, a Domain Controller and a domain name server. The Service Assurance Environment 408 thus includes facilities for monitoring fault conditions and performance of the SDP system 400.
FIGS. 5-12 illustrate use cases showing operation of the SDP system described above. These use cases illustrate interaction among the interested parties, including a customer, a Service Provider, and the SDP operator. Other active individuals include a Customer Service Representative, a Help Desk Operator and a Value Added Reseller. Upon initiation by these parties, several components of the SDP are active to implement the use case interaction, including a Web Service Interface, a Customer Profile Management engine, a Process Manager, a Customer Profile Management engine, User Profile Management engine, an integrated order manager, a Provisioning system and a Metering engine. Other active components include a Service Catalog Management engine, a Service Creator, a Work Flow Management engine, a Credential Management engine, a Directory Management engine.
In the last above description, the integration capability of the Service Orchestration and Integration Environment has been described. The orchestration capability of the module allows tasks within a business process to be sequenced and executed in real-time.
One ultimate goal of the SDP is to be able to provision and deliver any type of information and telecom services for the users. This implies that the orders or requests that users send from web front-end to the back-end may consist of different combinations of services, products, and features. This also implies that the SDP needs to interact with a variety of trading partners to fulfill customers' requests by provisioning different features on the orders. For example, a local phone service order with voice mail feature maybe provisioned at two different trading partners.
The fulfillment of the “complex” or “bundled” provision orders/requests demands the need of defining a business process to perform order management in the SDP. This subsection will describe the necessary tasks that will be required to implement the Order Management Process in the SDP. The following two areas of functionalities are built within the Service Orchestration and Integration Environment:
Order Processing and Work Order Generation
Order Lifecycle Management
The following describes these two capabilities.
The end users experiences are not limited to a single, unidirectional web front-end page flow. The users should be able to add, remove, and update any services, products, and features they can order during a single user session by visiting different pages in the SDP's Web Portal in any way that the user desires.
The added flexibility to the user experience on the web front-end implies that the orders/requests that are submitted by end users are bundled with different combinations of services, products, and features. This type of order can be referred to as a “complex” order because it may take more than one provisioning system or trading partner to fulfill the order.
Since the Orchestration and Integration module can interact with one provisioning system or trading partner at a time, the complex orders have to be first “decomposed” into more atomic “work orders” to be workable by provisioning entities. The following functionalities should be built in the Orchestration and Integration module to create and process work orders by decomposing the complex orders:
Creation of work orders based on decomposition criteria:

- The creation of work orders can be initiated by both end-user's complex orders and the responses received from the provisioning system
- The complex orders can be split into work orders according to set of predetermined business rules

Dynamic release of work orders

- Relationships are established and maintained across work orders to determine the dependencies for work order release and required processing steps

Validating work orders

- After the all the necessary work orders are created, the validity checks should be performed on all the work orders before submission.

The complex orders are decomposed into work orders in any way that a business rule dictates. They should be decomposed by different trading partners, services, or even by different features on the complex orders. One important design principle to note for this capability is that all the business rules that provide criteria for decomposition reside in database tables or in XML files. This allows the Order Management module to be transparent from the specific business rules, and encapsulate pure order processing capability that can be integrated with other applications.
On some occasions, all of the work orders that are generated from a complex order cannot be released into the provisioning systems at the same time. The release of work orders sometimes has to be sequenced and scheduled based on business rules. For example, if a complex order consists of two different services, Local Phone Service and DSL Service, two work orders can be generated: one for Local Phone Service and other for DSL service. However, the Local Phone Service work order has to be released and provisioned first before the DSL work order is released. Again, the predetermined work order release schedules are maintained in database tables or in XML files. This enables the capability to be reusable and maintainable.
Once all the work orders are submitted to the provisioning systems, the Order Lifecycle Management capability starts to tack the work orders until completion if successfully provisioned. Depending on the kind of service that the user needs to provision, the time to complete provisioning may vary. For example, the provisioning MS SharePoint or Exchange Services via MPS may complete instantaneously whereas the provisioning of telecom or data services may take hours or days.
All the requests/orders that should be provisioned by the SDP are tracked by the Order Management capability built within Orchestration and Integration module, and it notifies end-users whenever the order status changes. One of the benefits of implementing work order tracking capability is that especially for those work orders that require relatively lengthy provisioning time, if the work order “fallout” or exception occurs in the middle of the provisioning lifecycle, the order tracking capability should be able to determine where in the lifecycle the work order failed, and notify users immediately. If the exception is not fatal and can be resolved without the user's intervention, the Order Management capability dynamically generates and re-submits additional work orders so that the provisioning lifecycle can proceed.
In order to perform Order Lifecycle Management, the following capabilities are implemented in the Orchestration and Integration module:

- Transitioning of the order status in the provisioning lifecycle
- Handling of exceptions and fallouts during provision
- Dynamic generation of work orders based on incoming responses from external systems

After the work order is submitted to the provisioning system, the provision status of the work order can be tracked. This can be accomplished by updating the order status maintained in the database table based on the confirmation response the SDP receives whenever each phase of provision is completed from the provisioning system. Whenever there is a change in the order status, the user is notified of the change. Depending on the new status to which the work order moves, the components in the SDP may have to be notified as well. For example, if the order moves to the ‘Complete’ status, the message is sent to the Billing System to generate the bills for the customer, and the message is also sent to the Subscriber Management to update the customer's profile to grant access to the fully provisioned service.
However, during the usual provision lifecycle, the orders sometime “fallout” or fail to move on to the next phase. Then the provisioning system sends the message to the SDP indicating the exception had occurred. This triggers the order status to move to ‘Exception’ or ‘Fail’ status. The Orchestration and Integration module first assesses the response form the provision system, and if it is determined that it can be resolved by, for example, sending additional information from the database to the provisioning system, it dynamically generates and re-submit a work order. However, if it cannot be resolved in the module, the user is notified, and the errors in the work order should be manually fixed.
There are also “sunny days” work order provision scenarios that call for dynamic generation of work orders. During the provision lifecycle, if the provisioning system determines that it needs additional information from the SDP to complete the provision, it may request the information. Then the SDP will submit new work order that contains the requested information.
FIG. 5 is an interaction diagram illustrating a process of changing features of an existing service using a service delivery platform. FIG. 5 illustrates an operation in which a service variant manager chooses to modify features in an existing service variant. All users subscribed to the service will have their subscription updated.
In the use case illustrated in FIG. 5, the primary actor is a customer service representative of the service provider. A customer or service subscriber desires to have an existing service adapted to fit specific needs. The SDP operator desires to keep and maintain a record of the changed features. The Service Provider wants accurate information to provision feature changes for a user, and a Help Desk Operator wants to have access to records which tracks a user's request and the status of the request.
At step 502, the Customer Service Representative receives a request from the customer to change a feature on an existing service and The Customer Service Representative (CSR) requests the solution information for the customer, step 504. The solution information is stored as profile data in an SDP database. The Web Service Interface receives the request and initiates a request for the customer solution information to the Customer Profile Management engine, step 506. The Customer Profile Management engine returns the solutions for the customer to the Customer Service Representative, step 508.
The Customer Service Representative then selects the solution to update and requests to edit the details of a Solution Service Variant contained in the Solution. The CSR modifies an editable feature(s). The CSR selects how to apply these modifications to the underlying subscriptions. The CSR submits the changes, step 510. The Web Service Interface receives the request and initiates a request for modified feature(s) to the Process Manager, step 512. The Process Manager identifies the appropriate Orchestration to call. The Process Manager initiates a request to update the Solution Service Variant to the Customer Profile Management engine, step 514. The Profile Management engine returns status to the Process Manager, step 616.
The Process Manager initiates a request to retrieve the Subscriptions based on the Solution Service Variant to the User Profile Management engine, step 518. The User Profile Management engine returns the affected subscriptions to the Process Manager. The Process Manager updates the Subscription Service Variants with the modified values based on the override settings and initiates a request to update the Subscription Service Variant to the User Profile Mgmt engine. The User Profile Management engine returns status to the Process Manager. The Process Manager creates integrated order manager (IOM) Requests for the Subscription Service Variants affected. Based on the override settings, the IOM Request to Update Subscription is either submitted to IOM, step 520, or saved to a Database for User Activation. The Integrated Order Management engine will determine if the work order requires bulk or on-demand scheduling and initiate a request to the Provisioning system to propagate the changes to the subscribed service(s), step 522. The Provisioning system will provision the feature change for the users and return status to the Integrated Order Management engine, step 524. The Integrated Order Management engine will return status to the Process Manager, step 526. The Process Manager identifies the next step in the Orchestration schedule; update the status on the subscription. The Process Manager identifies the next step in the Orchestration schedule, Create a Billing Event. The Process Manager initiates a request to the Metering engine to create a billing event. The Metering engine creates a billing event for the subscription to the Process Manager. The Process Manager identifies that there are no more steps in the Orchestration schedule.
FIG. 6 is an interaction diagram illustrating a process of creating a new offer using a service delivery platform. In this use case, the primary actor is the service variant creator. In implementing this process, an Offer Manager wants the ability to create new offers containing the new service variant. The SDP Operator wants a record of the service creation and wants the provisioning engine to be able to provision the new service variant. The SDP Operator wants the ability to monitor the new service variant. The Service Variant Creator wants accurate, fast entry, with no errors to create the new service variant on the SDP and wants to make the service variant available to an Offer Manager.
In FIG. 6, the Service Variant Creator requests to view the available product definitions, step 602. The Web Service Interface receives the request and initiates a request for the product definitions to the Service Catalog Management engine, step 604. The Service Catalog Management engine returns the list of available product definitions to the Web Service Interface, step 606. The Web Service Interface returns the list of available product definitions to the Service Variant Creator, step 608.
The Service Variant Creator then selects a product definition and requests to create a new service, step 610. The Web Service Interface receives the request and initiates a request for the service definitions associated with the product definition to the Service Catalog Management engine, step 612. The Service Catalog Management engine returns the list of available service definitions to the Web Service Interface, step 614. The Service Creator enters the information necessary to create a service based on a selected service definition, step 616. The Web Service Interface receives the request and initiates a request to create the new service variant based on the selected service definition to the Service Catalog Management engine, step 618. The Service Catalog Management engine returns the new service variant creation status to the Web Service Interface, step 620.
FIG. 7 is an interaction diagram illustrating a process of creating a billing feed using a service delivery platform. In the process of FIG. 7, the primary actor is an external billing system. Among the stakeholders, an End User and customer both want the bill for services to be accurate, the SDP Operator wants to create an accurate billing feed for the billing system and wants a record of the billing feed creation. Finally, the Service Provider wants the billing events to be accurately captured in the SDP.
Prior to the process, the external billing system has requested billing records and the metering service receives and stores billing events from services. The External Billing System requests a billing feed, step 702. At step 704, the Work Flow Management engine interprets the request and routes a request to create a billing feed to the Metering Service. The Metering Service aggregates the billing events to create billable data records. The Metering Service requests subscription information from the Profile Management engine to append to the billable data records, step 706. The Metering Service requests account information from the Directory Management engine to append to the billable data records, step 708. The Metering Service creates a billable feed file comprised of billable data records. The Metering Service returns the billable feed file to the Work Flow Management engine, step 710.
FIG. 8 is an interaction diagram illustrating a process of providing a value-added reseller with a customer view using a service delivery platform. In this use case, the primary actor is a Value Added Reseller (VAR). Among the stakeholders in this process, the Customer wants the Customer's information to be accurate, the VAR wants an accurate summary of Customers, and the Service Provider wants accurate and easily accessible information regarding their VARS.
In FIG. 8 at step 802, the Value Added Reseller requests to view all of their customers. The Web Service Interface receives the request and initiates a request to the Customer Profile Management engine to retrieve the customer solutions, step 804. The Customer Profile Management engine identifies all the customers for the given reseller. The Customer Profile Management engine retrieves the customer solutions containing the Service Variants and Offers provided by the VAR. The Customer Profile Management engine returns the customer solutions containing the Service Variants and Offers provided by the VAR to the Web Service Interface, step 806. The Web Service Interface returns the customer solution back to the value added reseller, step 808. The Value Added Reseller requests to view the detailed customer information for each customer containing the Service Variants provided by the VAR, step 810. The Web Service Interface receives the request and initiates a request to the Directory Mgmt engine to retrieve the customer information, step 812. The Directory Management engine returns the customer information for the given VAR from Unified Directory to the Web Service Interface, step 814. The Web Service Interface returns the customer information back to the value added reseller, step 816.
FIG. 9 is an interaction diagram illustrating a process of creating a new account in an enterprise environment using a service delivery platform. FIG. 9 includes FIG. 9 a and FIG. 9 b. In this process, the primary actors are a Customer Administrator and the End User (of a Customer). Other stakeholders affected by the process include an End User, who wants accurate, fast entry, and no errors when ordering products, a Customer who wants a record of the order, the SDP Operator who wants a record of the order and the status of the order, and the Service Provider who ants to accurately provision the services for the new user.
The process begins at step 902 when the Customer Administrator (Admin) requests to create a new Solution, viewing the Offers/Service Variants within the Service Catalog. The Web Service Interface interprets the request and routes a request for the Offers/Service Variants available to the Customer to the Service Catalog Management engine, step 904. The Service Catalog Management engine returns the Offers/Service Variants that the Customer has a right to view to the Web Service Interface, step 906. The Web Service Interface returns the Offers/Service Variants to the End User, step 908, allowing him to select the items to add to their solution. The Customer selects 1 Offer containing 2 new services (1 asynchronous, 1 synchronous) to order, and submits the request to create a solution containing the Offer, step 910.
The Web Service Interface routes the request to the Customer Profile Mgmt engine to create the Solution, step 912. At step 914, the Customer Profile Mgmt engine returns the Solution ID to the Web Service Interface. The Customer selects to create a new Service Group, step 916, enters information for the New Service Group and selects to submit. The Web Service Interface routes the request to the Credential Mgmt engine to create the Service Group, step 918. The Credential Mgmt engine creates the new Service Group in the Unified Directory.
The Credential Management engine returns the Service Group ID to the Web Service Interface, step 920. The Customer selects to edit their Service Groups, step 922. The Web Service Interface routes the request to the Credential Management engine, step 924, to retrieve the Service Groups belonging to the Customer. The Web Service Interface routes the request to the Customer Profile Management engine, step 926, to retrieve the Solutions belonging to the Customer.
The customer selects to associate the 2 services in the above offer with the new Service Group and submits it, step 928. The Web Service Interface routes the request to the Customer Profile Management engine to create the relationship between the Service Group and the Services, step 930. The Customer Profile Management engine returns status to the Web Service Interface, step 932.
At step 934, the Customer requests to create a new End User. The Web Service Interface submits a request for the Available Roles to the Credential Management engine, step 936. The Credential Management Engine returns a list of available Roles to the Web Service Interface, step 938. The Web Service Interface submits a request for the Available Service Groups to the Credential Management Engine, step 940. The Credential Management Engine returns a list of available Service Groups to the Web Service Interface, step 942.
At step 944, the Customer enters the End User Account Information, including selecting a Role and Service Group (using Service Group created in the earlier steps). The Customer submits a request to create the new account. The Web Service Interface submits a request to the Directory Management engine to create an Account, step 946. The Directory Management engine sends a request to Credential Management to assign the new User to a Role group. The Directory Management engine sends a request to Credential Management to assign the new User to a Service Group. The Directory Management engine returns the User ID to the Web Service Interface, step 948.
Next, the Customer Logs Off and the new End User Logs On. The End User selects to subscribe to services, step 950. The Web Service Interface submits a request to the Customer Profile Management engine to retrieve the available Solution Service Variants based on Service Group and Customer, step 952. The Customer Profile Management engine returns an array of Solution Service Variants to the Web Service Interface at step 954.
At step 956, the End User selects the two Services to which to subscribe. The Web Service Interface routes the request to the Process Mgmt engine to create Subscriptions, steps 958. The Process Management engine routes a request to the User Profile Management engine to create a Subscription in the SDP Database for Service 1, step 960. The User Profile Management engine creates the subscription and returns status to the Process Management engine, step 962. The Process Management engine then routes a request to the User Profile Management engine to create a Subscription in the SDP Database for Service 2, step 964. The User Profile Management engine creates the subscription and returns status to the Process Management engine at step 966.
The Process Management engine creates an IOM Request and submits it to the Integrated Order Management engine at step 968. The Integrated Order Management engine validates the services using the Service Catalog Management engine. The Service Catalog Management engine returns validation status to the Integrated Order Management engine. The Integrated Order Management engine generates work orders based on the order request. The Integrated Order Management engine releases the work order to provision the new service 1 to the Provision Request Management engine, step 970. The Integrated Order Management engine releases the work order to provision the new service 2 to the Provision Request Management engine, step 972.
The Provision Request Management engine uses the Provisioning engine to provision new services. The Provision Request Management engine notifies the Integrated Order Management engine that the service 1 has been successfully provisioned, step 974. The Provision Request Management engine notifies the Integrated Order Management engine that the service 2 has been successfully provisioned, step 976. The Integrated Order Management engine returns order status to the Process Mgmt engine, step 976. The Process Management engine updates the status of the subscriptions, including the configuration information, step 978.
FIG. 10 is an alternative interaction diagram illustrating a process of creating an account with two new services using a service delivery platform. This process is a consumer version of the process of FIG. 9. In the process of FIG. 10, the primary actor is an End User, not from a customer. The relevant stakeholders in this process include the End User, who wants accurate, fast entry and no errors when ordering products, the SDP Operator who wants a record of the order and the status of the order, and the Service Provider who wants to accurately provision the services for the new user. Prior to execution of the process, there is anonymous access to a self-service portal of SDP.
In FIG. 10, the process begins at step 1002 when the End User selects to subscribe to services and requests to view the Offers/Service Variants within the Consumer Solution. The Web Service Interface interprets the request and routes a request for the Offers/Service Variants available to the End User to the Customer Profile Management engine, step 1004. The Customer Profile Management engine returns an array of Solution Service Variants to the Web Service Interface, step 1006.
The End User selects the two services to which to subscribe, step 1008, enters account information and submits the order as a new User. The Web Service Interface routes the request to the Process Management engine to create Subscriptions for a new user, step 1010. At step 1012, the Process Management engine routes a request to the Directory Management engine to create an Account for the User. The Directory Management engine creates the Account under the Consumer OU and returns the User ID, step 1014. The Process Management engine routes a request to the User Profile Management engine to create a Subscription in the SDP Database for Service 1, step 1016. The User Profile Management engine creates the subscription and returns the Subscription to the Process Management engine, step 1018. The Process Management engine routes a request to the User Profile Management engine to create a Subscription in the SDP Database for Service 2, 1020. The User Profile Management engine creates the subscription and returns the Subscription to the Process Management engine, step 1022. The Process Management engine then creates a Create Subscriptions Order Request and routes the order request to the Integrated Order Management engine, step 1024. The Integrated Order Management engine validates the services using the Service Catalog Management engine.
The Service Catalog Management engine returns validation status to the Integrated Order Management engine. The Integrated Order Management engine generates work orders based on the order request. The Integrated Order Management engine releases the work order to provision the new service 1 to the Provision Request Management engine, step 1026. The Integrated Order Management engine releases the work order to provision the new service 2 to the Provision Request Management engine, step 1028. The Provision Request Management engine uses the Provisioning engine to provision new services. The Provision Request Management engine notifies the Integrated Order Management engine that the service 1 has been successfully provisioned, step 1030. The Provision Request Management engine notifies the Integrated Order Management engine that the service 2 has been successfully provisioned, step 1032. The Integrated Order Management engine returns order status to the Process Management engine, step 1034. The Process Management engine updates the status of the subscriptions, including the configuration information, step 1036.
FIG. 11 is an interaction diagram illustrating a process of authenticating and authorizing an end user of services using a service delivery platform. In this process, the primary actor is the End User of a Customer. The End User wants access to purchase products, view their products, and manage their products/profile. Other stakeholders in the process include the Customer who wants access to purchase offers, to view their offers, and manage their offers/profile/end users, the Offer Manager wants access to manage offers, the SDP Operator, who wants a record of the users on the system and to provide a secure environment, and also wants to lock down privileges to reduce errors created by users on the system. Further, the SDP Operator wants access to monitor and maintain the SDP, the Service Provider wants access to manage the services and a Help Desk Operator: Wants access to system and user records to assist in resolving issues.
Referring to FIG. 11, at step 1102, the End User enters their credentials into the login screen and submits them. The credentials are encrypted. The Web Service Interface receives the request and initiates a request to authenticate the End User to the Access Control Management engine, step 1104. The Access Control Management engine decrypts the credentials. The Access Control Management engine validates the credentials against Unified Directory and returns account and membership information, step 1106. The Access Control Management engine requests validation of the subscription status for the End User from the Profile Management engine, step 1108. The Profile Management engine returns the subscription status for the End User to the Access Control Management engine, step 1110. The Access Control Management engine returns the account, membership, and subscription status information to the Web Service Interface at step 1112.
The Web Service Interface engine requests role information based on the membership information of the End User from the Role Management engine at step 1114. The Role Management engine returns the privileges for the End User to the Web Service Interface at step 1116. Finally, at step 1118, the Web Service Interface returns the account, membership, privileges information, and subscription status to the End User where it will be stored to the session.
FIG. 12 is an interaction diagram illustrating a process of handling a provisioning exception when provisioning services using a service delivery platform. In this process, the primary actor is the Provisioning Engine. Among the stakeholders in the process, the End User wants the system to handle the exception and be notified with a friendly message if the exception could not be resolved by the system; the Customer wants the system to handle the exception and be notified with a friendly message if the exception could not be resolved by the system; and the SDP Operator wants to be able to view the exceptions and the technical detail associated with the exception. Further, the Service Provider wants to be able to view the exceptions and the technical detail associated with the exception; and the Help Desk Operator wants to be able to view the exceptions and the technical detail associated with the exception.
Referring to FIG. 12, initially a provision request failure is logged as exception. The initial provision request is corrected and is reinstated for processing. At step 1202, the Provisioning engine responds with provisioning exception information to the Provision Request Management engine, step 1204. The Provision Request Management engine responds to the Integrated Order Management engine stating that the service could not be provisioned, step 1206.
The Integrated Order Management engine responds to the Work Flow Management engine stating that the service could not be provisioned, step 1208. The Work Flow Management engine requests to log the provision exception to the Exception Engine, 1210. The Exception Engine fails to correct the exception. The Exception Engine responds to the Work Flow Management engine with the provision exception details, 1212. The Work Flow Management engine sends the provision exception information to the Notification Engine at step 1214.
At step 1216, the Notification Engine sends the provision exception event to the SDP Operator. The SDP Operator views the provision exception event and resubmits the request to provision the service, steps 1218, 1220. The Work Flow Management engine routes the provision request to the Integrated Order Management engine at step 1222. The Integrated Order Management engine reconciles the provision request with the original work order for service provisioning and releases the work order to the Provision Request Management engine, step 1224. The Provision Request Management engine uses the Provisioning engine to provision the service at step 1226.
FIG. 13 is an interaction diagram illustrating a process of changing offer properties of an offer of services by a service provider, using a service delivery platform. The primary actor in this process is the Offer Manager, who wants to edit an existing offer property. Another interested stakeholder is the SDP Operator, who wants a record of the property change(s) for the offer.
In FIG. 13, at step 1302, the Offer Manager requests to view their existing offers. The Web Service Interface receives the request, step 1304, and initiates a request for the Offer Manager's offers to the Service Catalog Management engine, step 1306. The Service Catalog Management engine returns at step 1308 the filtered offers that the Offer Manager has the right to see to the Web Service Interface, step 1308.
The Web Service Interface returns the filtered offers to the Offer Manager, step 1310, allowing him to select offers to edit. The Offer Manager requests to edit an offer in the Service Catalog, 1312, 1314. The Web Service Interface receives the request and initiates a request at block 1316 to the Service Catalog Management. The Service Catalog Management engine returns the offer information and related service details for the selected offer to the Web Service Interface at step 1318.
The Web Service Interface returns the offer information and related service details to the Offer Manager, step 1320, allowing him to change the properties of the offer. The Offer Manager edits the desired offer properties and requests to save the changes. The Web Service Interface interprets the request and routes a request to update the offer to the Service Catalog Management engine, step 1320, 1322. The Service Catalog Management engine updates the offer information to reflect the property changes requested by the offer manager and returns status to the Web Service Interface at step 1324.
In the illustrated embodiments, all service activation, deactivation and modification processes are based on a workflow. A workflow is designed by using an operator web-based tool. A workflow is composed of:
A set of Status—Each status will represent a phase in the life-cycle of a particular service;
A set of Events—An event is something that changes the status of a service. Workflow state transitions are triggered by events. In the context of this documentation, there are two major types of events; Business Event and System Event. Most of the events will fall under these two main categories.
A Business Event is a system-independent message that represents a detailed business action through the Enterprise Application Integration (EAI) application. EAI is the process of coordinating the operation of various applications across an enterprise or service provider so that the applications can perform as an integrated enterprise-wide system.
A System Event is a system-dependent message that is sent by or sent to an application external to the EAI application. System Events correspond to the public interface exposed by a particular system, such as an XML document, an API call, or a database table. System Events are converted to or from Business Events and can have a one-to-one, one-to-many, or many-to-many relationship with Business Events.
A workflow is further composed of a set of Actions—An action is an operation that has to be performed when a state transition happens.
The services workflow rules are stored in a State-Transition Table (STT) kept on an SDP database. Each service type has its own STT.
In the illustrated embodiments, a common data mapping approach is implemented to create a solution that enables service providers to have a choice in selecting their billing, customer care, provisioning, and other applications and to enable business event definitions to be consistent across various application combinations. For each of the business events in scope a data-mapping matrix is created. Using this, commonalities are extracted to create event definitions. This common data model is used as an input to determine the data type conversion rules for the data transformations between applications.
These data mappings create the start of a master data model (MDM), which can be extended as additional applications are added to the solution. As new applications are added, the application data model will only need to be mapped to the master model rather than mapping to each of the other applications independently. Thus, as the SP solution grows, there is only the effort to maintain each application's specific format with its mappings to the SP (common) format for each business event.
In order to handle the SDP functional modules described above and the capabilities of the application, a master data model (MDM) is supported. The MDM supports a shared service oriented approach and operates as the data store for all master SDP data that may include services, accounts, events, exceptions, packages, resource metering, and billing event data.
The MDM is designed to support a common universal set of information. The SDP solution supports a wide array of value-added services, value-added resellers, packages and bundles. The SDP MDM supports differing value-added services by encapsulating a wide set of universal attributes. This allows the SDP to support current and future products and services that service providers will offer. The MDM also provides this level of flexibility for other SDP capabilities such as product packaging and account hierarchy.
In order to handle the business event transformations within the application connection models in a consistent manner, a common transformation framework will be utilized across each of the connection interfaces within the SDP. BizTalk performs transformations using XSLT. This requires that the incoming and outgoing messages must be in XML format. This means that some applications that cannot provide messages in XML format will utilize BizTalk's ability to convert other file formats to XML.
Presence Management is utilized to dynamically detect a user's ‘presence’ on a range of devices and networks. These can include fixed and mobile telephony, paging, instant messaging, voicemail, and email. A combination of network and device information is used to build an intelligent picture of a user's situation and accessibility. In order to manage user experience, the SDP recognizes a user's presence and customizes their experience based on their profile.
The components of presence management are as follows:
Presence

- User Access Control—Receive and manage events related to user network access and perform user authentication and authorization. User Access Policy Management—Provide policies to authenticate users from different types of networks (Wired, Wi-Fi, Wireless, Mobile)
- User Access Policy Configuration—Update user presence information on Unified Directory

Unified Directory

- Subscriber Information Management—Provide information regarding user status (authentication, localization, type of access)
- User Access Profile—Provide services subscribed by the user and the service technical profile (ex. Bandwidth)
- User Device Information—Provide details of user's device to access the services
- Third Party Management—Provide a single point of access to retrieve or store information to Unified Directory

Presence information is made available within the SDP in one embodiment by utilizing Microsoft Live Communication Server (LCS) 2003. LCS will be configured to trigger server processes without the users' intervention.
FIG. 14 illustrates an object model for use in conjunction with a service delivery platform (SDP) system and method. FIG. 14 includes FIGS. 14 a, 14 b, 14 c and 14 d. FIG. 14 forms an entity-relationship diagram of an example of a data model 1400 that stores and links information that relates to delivering a variety of services by one or more service providers to a plurality of service subscribers.
Referring to the portion of FIG. 14 shown in FIG. 14 a first, the data model 1400 generally includes an SDP_Offer entity 1402 that stores data relating to an offer. An offer is set of Service Variants for presentation to customers for purchase. Service offers consist of one or many Service Variants. An offer can also include other offers, referred to as sub-offers. In the example of FIG. 14, the SDP_Offer entity 1402 is designed to store offers according to offer name and offer description. The SDP_Offer entity 1402 includes an Offer ID field which serves as the primary key (PK) for the entity, thus uniquely defining each SDP offer data object. In addition, the SDP_Offer entity 1402 may include the following fields as foreign keys: Offer_Name, Offer_Description.
Additional fields may also be included in the SDP_Offer entity 1402. For example, as shown in FIG. 14, the SDP_Offer entity 1402 includes a Base_Offer_ID field for storing an identifier for a base offer; a Created By_ID for storing the identity of the person or entity who created the offer; a Created_Date_ID, for storing the date of creation of the offer; and Updated_By_ID for storing the identification of the person or entity which last updated the offer; and an Updated_Date, for storing the date of last update of the offer. Generally all of the data storage entities of the data model 1400 include these last four fields.
The data model 1400 further includes an SDP_Offer_Relation entity 1404. The SDP_Offer_Relation entity 1404 defines relationships between and offer and a sub-offer. The SDP_Offer_Relation entity 1404 includes the Offer_ID and Sub_Offer_ID fields as foreign keys which are linked to the SDP-offer entity 1402.
The data model 1400 further includes an SDP_Offer_Regrade_Options entity 1406. The SDP_Offer_Regrade_Options entity 1406 stores information about options for regarding an offer. The SDP_Offer_Regrade_Options entity 1406 includes the Offer_ID and Regrade_Offer_ID fields as foreign keys which are linked to the SDP-offer entity 1402.
The data model 1400 further includes a LNK_Offer_Service_Variant 1408. The LNK_Offer_Service_Variant 1408 stores information linking the SDP_Offer entity 1402 to a SDP_Service_Variant entity 1410, discussed below. The LNK_Offer_Service_Variant 1408 includes the Offer_ID as a foreign key which is linked to the SDP_Offer entity 1402. The LNK_Offer_Service_Variant 1408 includes the Service_Variant_ID as a foreign key which is linked to the SDP_Service_Variant entity 1410.
The data model 1400 further includes an SDP_Event_Message entity 1412. The SDP_Event_Message entity 1412 stores data defining a message about an event occurring in the SDP system. The SDP_Event_Message entity 1412 includes an Event_Message_ID as a primary key. The entity 1412 also includes several fields defining the event message, including an Event_Category_ID, an Event_Category_Name, and Event_Message_Type, and Event_Message_Name and an Event_Message_Description.
The data model 1400 further includes an SDP_Subscription_Type entity 1414. The SDP_Subscription_Type entity 1414 stores data about a subscription to a service provided by the SDP. The SDP_Subscription_Type entity 1414 includes a Subscription_Type_ID as a primary key and also includes a Subscription_Type_Description field and a Type_Value field defining the subscription type.
The data model 1400 also includes a UD_Service_Group entity 1416 defining a service group within the unified directory. The UD_Service_Group entity 1416 includes a Service_Group_ID as a primary key and also stores a Service_Group_Description field.
The data model 1400 also includes an SDP_Offer_Rule entity 1418. The SDP_Offer_Rule entity 1418 stores information defining rules about services which must be prescribed as a prerequisite to a particular service. The SDP_Offer_Rule entity 1418 includes an Offer_Rule_ID as a primary key and also stores a Service_ID field defining the service and a Prerequsite Service_ID field defining the service which must be subscribed as a prerequisite.
The data model 1400 further includes an SDP_Pricing entity 1420. The SDP_Pricing entity 1420 stores information about service pricing and includes a Pricing_ID as a primary key. Further, the SDP_Pricing entity 1420 stores several field defining pricing of the service, including a Pricing_Value field, a Currency_ID field, a Payment_Model_ID and a Payment_Term_ID.
The offer model 1400 further includes an SDP_Role_Privilege entity 1422. The SDP_Role_Privilege entity 1422 includes a Privilege_ID that is a primary key and also functions as a foreign key and is linked to an SDP_Privilege entity 1424. The SDP_Role_Privilege entity 1422 further includes a Role_ID as a primary key and a field labeled Privilege.
The SDP_Privilege entity 1424 linked to the SDP_Role_Privilege entity 1422 stores information about privileges in the SDP system. The SDP_Privilege entity 1424 includes a Privilege_ID field as a primary key and further includes a description field for storing information describing the privilege.
The data model 1400 further includes an SDP_Detail entity 1426. The SDP_Detail entity 1426 includes a Detail_ID or detail identifier as a primary key. The SDP_Detail entity 1426 also stores information in Detai_Value, Detail_Description and Reference_ID fields.
The data model 1400 further includes a REF Override Settings entity 1428 defining override settings for use in the SDP. The entity 1428 includes fields such as Override_Setting_ID, Override_Setting_Value, Soluton_Override Flag, Catalog Override_Flag and Default Flag.
For records that require geographical information, the data model 1400 includes several geographical entities. These include a REF_City entity 1430, a REF_State entity 1432 and a REF_Country entity 1434. The REF_City entity 1434 defines the relevant city and includes a City_ID field as a primary key. The entity 1430 further includes a City_Name field and a Country_ID field as a foreign key linked to the REF_Country entity 1434 and a State_ID as a foreign key linked to the Ref_State entity 1432.
The REF_State entity 1432 includes a State_ID field as a primary key and also stores a State_Name field defining state-related geographic information. Further, the REF_State entity 1432 includes a Country_ID field as a foreign key linked to the REF_Country entity 1434
The REF_Country entity 1434 stores information defining the country relevant to the described service or offer. The REF_Country entity 1434 includes a Country_ID field as a primary key and also a Country_Name field for storing information about the country associated with the service.
The data model 1400 further includes an SDP_Term entity 1436. The SDP_Term entity 1436 includes an identification field Term_ID as a primary key and also stores a Term_Description field with description information and a Pricing_ID field.
The data model 1400 further includes a Communication_Method_ID entity 1438. The Communication_Method_ID entity 1438 stores information about a communication method. The entity 1438 includes a Communication_Method_ID field with identification information, which is used as a primary key. Further, the Communication_Method_ID entity 1438 includes fields defining a Method_Description and Bill_Feed_ID.
Referring to the portion of FIG. 14 shown in FIG. 14 b, the data model 1400 includes an SDP_Product entity 1440 that stores data related to a product offered through the SDP. The SDP_Product entity 1440 includes a Product_ID field which serves as the primary key for the SDP_Product entity 1440. Additional fields are also included in the example of FIG. 14, including a Product_Name for storing a name or other identifier for the product, a Vendor field for storing identification of the vendor of the service, a Version for storing version identification information, a Service_ID field which identifies the service, a Product_Description including descriptive information about the product and an Added_Date field defining when the product was added to the SDP.
The data model 1400 also includes and SDP_Product Category entity 1442. This entity defines category information for the product. The SDP_Product Category entity 1442 includes a Product_ID field and a Category_ID field which function as both primary keys and foreign keys. As a foreign key, the Product_ID field is linked to the field in the SDP_Product entity 1440 with the same name. Similarly, as a foreign key, the Category_ID field is linked to the field in a REF_Category entity 1444 with the same name.
The REF_Category entity 1444 stores information about the product category. It includes a Category_ID field as a primary key. The entity 1444 further includes fields such as Category_Name, Category_Description and Category_type_ID. This last field may be used as a foreign key and is linked to a field with the same name in a REF_Category_Type entity 1446. The REF_Category_Type entity 1446 includes the field Category_Type_ID as a primary key. The REF_Category_Type entity 1446 further includes fields Category_Type_Name and Category_Type_Description for storing additional information about a category type for a product.
The data model 1400 further includes and SDP_Product_Configuration entity 1448. The SDP_Product_Configuration entity 1448 stores information about the configuration of a particular product. The SDP_Product_Configuration entity 1448 includes a field labeled Configuration_ID which serves as a primary key for the entity 1448. The SDP_Product_Configuration entity 1448 further includes fields storing configuration information labeled Product_ID, which also serves as a foreign key, Configuration_Name and Configuration_Description.
The data model 1400 further includes a REF_Billing_Schema entity 1450 which stores information about how a service is billed. The REF_Billing_Schema entity 1450 includes a primary key field labeled Billing_Schema_ID which stores an identity for the billing schema. The REF_Billing_Schema entity 1450 further includes a foreign key labeled Category_ID which is linked to the field of the same name in the REF_Category entity 1444. The REF_Billing_Schema entity 1450 further includes, in this embodiment, several other fields for storing data about the billing schema, including Billing_Schema_Name, Billing_Schema_Description, Billing_Schema_Version, Billing_Schema_XMLNS:XSI; Billing_Schema XSI:SchemaLocation, Billing_Schema_IPDRREcorder and MXLNS.
The data model 1400 also includes an SDP_Service entity 1452. The SDP_Service entity 1452 stores information about a service offered as part of the SDP. The SDP_Service entity 1452 includes a primary key labeled Service_ID, which stores identification information for the service. The SDP_Service entity 1452 further stores information about the service in several fields, including Service_Name, which stores a name of the service, Service_Description which stores a description of the service, Product_ID and Category_ID which store identifiers of the product and category for the service. Further, the SDP_Service entity 1452 includes fields labeled Type, which stores a category type, Start_Date and End_Date, which store information about the timing of provision of the service, and a Status_ID field.
The data model 1400 further includes the SDP_Service_Variant entity 1410 referenced above. The SDP_Service_Variant entity 1410 stores information about a service variant. A Service Variant is a catalog unit derived from a Service that contains configured details and attributes that define a set of unit of service. The SDP system supports creating different variants of every service, so that the service is offered to different types of target users. The SDP_Service_Variant entity 1410 includes a field labeled Service_Variant_ID which stores identification information for the service variant. The Service_Variant_ID operates as a primary key for the SDP_Service_Variant entity 1410.
The SDP_Service_Variant entity 1410 further includes a field labeled Service_ID which operates as a foreign key for the SDP_Service_Variant entity 1410. The field Service_ID is linked to the field of the same name in the SDP_Service entity 1452. The SDP_Service_Variant entity 1410 further includes fields which store information defining the service variant, including Service_Variant_Name, which stores the name of the service variant, Service_Variant_Description, which stores a description of the service variant, Base_Service_Variant_ID and Reseller_ID.
The data model 1400 further includes a SDP_Service Dependency entity 1454. The SDP_Service Dependency entity 1454 defines information about related services and respective dependencies among related services. The SDP_Service_Dependency entity 1454 includes a field labeled Service_ID which operates as a first foreign key for the SDP_Service Dependency entity 1454, and is linked to the field of the same name in the SDP_Service entity 1452. Further, the SDP_Service_Dependency entity 1454 includes a second foreign key labeled Related_Service_ID which is also linked to the SDP_Service entity 1452. In this embodiment, the SDP_Service_Dependency entity 1454 further includes fields which define the service dependency, labeled Dependency_Name and Dependency_Description.
The data model 1400 still further includes a LNK_Service_Payment_Term entity 1456. The LNK_Service_Payment_Term entity 1456 includes two fields which can operate as primary keys and foreign keys. The first is labeled Payment_Term_ID, which is linked to a field with the same label in a REF_Payment_Term entity 1458 (FIG. 14 c). The second is labeled Service_ID and is linked to the field with the same name in the SDP_Service entity 1452.
The data model 1400 further includes an SDP_Profile_Pricing entity 1460. The SDP_Profile_Pricing entity 1460 includes a primary key field labeled Profile_Pricing_ID. The SDP_Profile_Pricing entity 1460 further includes a first foreign key field labeled Currency_ID which is linked to a field with the same name in a REF_Currency entity 1470 (FIG. 14 c). Further, the SDP_Profile_Pricing entity 1460 includes a second foreign key field labeled Payment_Model_ID, which is linked to the field having the same label in a REF_Payment_Model entity 1472 (FIG. 14 c). The SDP_Profile_Pricing entity 1460 further includes a third foreign key field labeled Payment_Term_ID which is linked to the field with the same label in the REF_Payment_Term entity 1458 (FIG. 14 c).
The data model 1400 further includes a LNK_Service_Currency entity 1462. The LNK_Service_Currency entity 1462 includes two fields that can function as both primary keys and foreign keys. The first is labeled Service_ID and as a foreign key is linked to the field of the same name in the LNK_Service_Payment_Term entity 1456. The second is labeled Currency_ID and is linked as a foreign key to the Currency_ID field of the REF_Currency entity 1470 (FIG. 14 c).
The data model 1400 further includes a LNK_Billing_Element entity 1464. The LNK_Billing_Element entity 1466 includes a primary key field labeled Billing_Element_ID. The LNK_Billing_Element entity 1466 further includes fields which can function as foreign keys, includes Billing_Schema_ID, Billing_Element_Name and Billing_Element_Description.
The data mode 1400 further includes an SDP_Billable_Data_Record_Detail entity 1466. The SDP_Billable_Data_Record_Detail entity 1466 includes a primary key field labeled Billable_Data_Record_Detail_ID. The SDP_Billable_Data_Record_Detail entity 1466 further includes fields which function as foreign keys, including a field labeled Billable_Data_Record_ID, which point to the field of the same name in a SDP_Billable_Data_Record entity 1468; a field labeled Billing_Element_ID, which is linked to the field of the same name in the LNK_Billing_Element entity 1646. The SDP_Billable_Data_Record_Detail entity 1466 further includes a field labeled Billing_Element_Value.
The data model 1400 further includes a SDP_Billable_Data_Record entity 1468. The SDP_Billable_Data_Record entity 1468 includes a field labeled Billable_Data_Record_ID, which serves as a primary key for the entity 1468. The SDP_Billable_Data_Record entity 1468 further includes a field labeled Billing_Schema_ID which functions as a foreign key. It is linked to a field of the same name in the REF_Billing Schema entity 1450. The SDP_Billable_Data_Record entity 1468 further includes a field labeled Bill_Feed_ID which functions as a foreign key. It is linked to a field with the same label in the a SDP_Bill_Feed entity 1474 (FIG. 14 c).
Referring now to the portion of the data model 1400 shown in FIG. 14 c, the data model 1400 further includes the REF_Payment_Term field entity 1458. The REF_Payment_Term field entity 1458 includes a primary key field labeled Payment_Term_ID. The REF Payment_Term field entity 1458 further includes two additional fields configured to store information about the payment term. These are a Payment_Term_Name field and a Payment_Term_Desc field.
The data model 1400 further includes a LNK_Service_Payment_Model entity 1476. The LNK_Service_Payment_Model entity 1476 includes two fields that can function as either a primary key or a foreign key. First is a field labeled Payment_Model_ID which is linked to the filed with the same name in the REF_Payment_Model entity 1472. Second is a field labeled Service_ID which is linked to the Service_ID field of the SDP_Service entity 1452 (FIG. 14 b).
The REF_Payment_Model entity 1472 includes the field labeled Payment_Model_ID as a primary key. Further, the REF_Payment_Model entity 1472 includes two field configured to store data that is descriptive of the payment model. First is a field labeled Payment_Model_Name. Second is a field labeled Payment_Model_Desc.
The data model 1400 further includes the SDP_IOM_Request_Type entity 1478. SDP_IOM_Request_Type entity 1478 includes the field labeled IOM_Request_Type_ID as a primary key. The SDP_IOM_Request_Type entity 1478 further includes fields storing additional information defining the request to the integrated order manager (IOM), including a field labeled IOM_Request_Type_Name and a field labeled IOM_Request_Type_Description.
The data model 1400 further includes a SDP_Subscription_Service_Variant entity 1480. This entity stores information about a subscription service variant. This entity includes a primary key field labeled Subscription_Service_Variant_ID which identifies the subscription service variant. The SDP_Subscription_Service_Variant entity 1480 includes several fields with function as foreign keys. The first is labeled Currency_ID and is linked to the field of the same name in the REF_Currency entity 1470. The second field is labeled Payment_Model_ID and is linked to the same named field of the REF Payment_Model entity 1472. The third field is labeled Payment_Term_ID and is linked to the same named field of the REF_Payment_Term entity 1458. The fourth field is labeled Status_ID and is linked to the field with the same name of a REF_Status entity 1486. The fifth field is labeled Solution_Offer_ID and is linked to a field with the same name of a SDP_Solution_Offer entity 1488.
The SDP_Subscription_Service_Variant entity 1480 further includes a sixth field labeled Solution_Service_Variant_ID which is linked to a field with the same label in a SDP_Solution_Service_Variant entity 1490. The SDP_Subscription_Service_Variant entity 1480 further includes a field labeled Subscription_ID which is linked to the field with the same name of the SDP_Subscription entity 1484. The SDP_Subscription_Service_Variant entity 1480 further includes fields labeled Service_Variant name to store the name of the service variant and Service_Variant_Description to store a description of the service variant. Finally, in this embodiment, the SDP_Subscription_Service_Variant entity 1480 includes a field labeled Pricing_Value.
The data model 1400 further includes an SDP_IOM_Request entity 1482. This entity 1482 stores data about a request made to the SDP integrated order manager. The SDP_IOM_Request entity 1482 includes a primary key field labeled IOM_Request_ID which stores identification information for the request to the IOM. The SDP_IOM_Request entity 1482 further includes a first foreign key field, labeled Status_ID. This field is linked to the field of the same name in the REF_Status entity 1486. The SDP_IOM_Request entity 1482 further includes a second foreign key field, labeled IOM_Request_Type_ID, which is linked to the field with that name of the DSO_IOM_Request_Type entity 1478. The SDP_IOM Request entity 1482 includes other fields for storing data, including and IOM_Request Description field, an IOM_Request Content field and an Affected_ID field.
The data model 1400 further includes the SDP_Subscripton entity 1484. This entity 1484 has a primary key field labeled Subscription_ID. Further, the SDP_Subscripton entity 1484 includes fields labeled Subscription_Name, Subscription_Description and User_ID for storing information about the SDP Subscription.
The data model 1400 still further includes the REF_Status entity 1486, which has a primary key field labeled Status_ID and stores an identifier. The REF_Status entity 1486 further includes a Status_Name field for storing name information.
The data model 1400 further includes and SDP_Solution_Offer entity 1488. This entity 1488 has a primary key field labeled Solution_Offer_ID and a foreign key field labeled Solution_ID. The foreign key field is linked to the field with the same name of a SDP_Solution entity 1492 (FIG. 14 d). The SDP_Solution_Offer entity 1488 includes additional fields for defining a solution offer, including fields labeled Offer_Name, Offer_Description, Offer_Price, Offer_ID, Catalog_Offer_ID, Is_CatalogBase and Status_ID.
Still further, the data model 1400 includes a SDP_VAR_Customer_Relations entity 1494. This entity has a primary key field VAR_Customer_Relations_ID. This entity in this example further has three foreign key fields, including a first field labeled Solution_ID which is linked to a field in the SDP_Solution entity 1492, a second field labeled Solution_Offer_ID which is linked to a field in the SDP_Solution_Offer entity 1488, and a third field labeled Solution_Service_Variant_ID, which is linked to a field of the same name in a SDP_Solution_Service_Variant entity 1490. The SDP_VAR_Customer_Relations entity 1494 further has fields labeled Reseller_ID and Customer_ID for storing identification information for some of the parties involved with this service and the SDP.
The SDP_Solution_Service_Variant entity 1490 includes a primary key labeled Solution_Service_Variant_ID which stores data defining the solution service variant. This entity 1490 further includes several fields that define the content of a solution service variant, including fields labeled Solution_ID, Service_Variant_ID, Service_Variant_Name, Service_Variant_Description and Solution_Offer_ID. Other fields include Is_Catalog Base, Catalog_Service_Variant_ID, Pricing_Value, Currency_ID, Payment_Model_ID, Payment_Term_ID and Status_ID.
The data model 1400 further includes a REF_Security Group_Type entity 1496. This entity 1496 includes a primary key Security_Group_Type_ID which stores identification information. This entity also includes fields storing information about the security group, including a Security_Group_Type_ID field and a Security_Group_Type_Description field.
The date mode 1400 further includes a SDP_Subscription_Configuration entity 1498. This entity 1498 has a primary key field Subcription_Configuration_ID and in this embodiment, two foreign key fields. The first foreign key field is the Configuration_ID which points to a field in the SDP_Product_Configuration entity 1448 (FIG. 14 b). The second foreign key field is labeled Subscription_ID and points to the primary key field of the SDP_Subscription field 1484. The SDP_Subscription_Configuration entity 1498 includes other fields for storing information about the subscription configuration, including a Configuration_Value field.
Turning now to the portion of FIG. 14 shown in FIG. 14 d, the data model 1400 includes a LNK_Attribute Detail_Attribute_Mask entity 1502. This entity includes two foreign key fields. The first is labeled Attribute_Detail_ID and points to a like named field in an SDP_Attibute_Detail entity 1504. The second is labeled Attribute_Mask_ID and points to a field of an SDP_Attribute_Mask entity 1506.
The data model 1400 still further includes the SDP_Solution entity 1492. This entity 1492 has the primary key field labeled Solution_ID and several other fields for storing information. These fields include fields labeled Customer_ID, Solution_Name, Solution_Description and Is_Reseller_Solution.
The data model 1400 further includes a LNK_Solution_Service_Group entity 1508. This entity includes a field labeled Solution_ID which functions as both a primary key and a foreign key, a field labeled Security_Group_ID which functions as both a primary key and a foreign key and a field labeled Solution_Service_Variant, which also functions as both a primary key and a foreign key. Still further, the data model 1400 includes a SDP_Security_Group entity 1510 which has a primary key field labeled Security_Group ID. This entity 1510 has a foreign key labeled Security_Group_Type_ID which points to a field of the same name in the REF_Security_Group_Type entity 1496 (FIG. 14 c). Still further, this entity 1510 includes other fields to store information about the security group, including a Security_Group_Name field, a Security_Group_Description field, Security_Group_Guide field, a Security_Group_Type_ID field and a Customer_ID field.
The data model still further includes a SDP_Workflow entity 1512. This entity 1512 has a primary key labeled Workflow_ID and stores additional information in fields labeled Orchestration Name and Workflow_Type.
The data model 1400 further includes the SDP_Attribute_Mask entity 1506, with a primary key field labeled Attribute_Mask_ID. This entity 1506 includes other fields for storing data about the attribute mask, including fields labeled Value_Type, Text_Value, Default_Value, Min_Value, Max_Value, Inc_Value, Begin_Date, End_Date and Value_Description.
The data model 1400 also includes an SDP_Attribute_Detail entity 1504. The SDP_Attribute_Detail entity 1504 has a primary key field labeled Attribute_Detail_ID and further includes two fields for further defining the SDP attribute, a first field named Attribute_Detail_Name and Attribute_Detail_Description.
The data model 1400 further includes a SDP_Attribute entity 1514. This entity 1514 includes an identifying primary key labeled Attribute_ID. It further includes a foreign key Attribute_Detail_ID which is linked to the same named field of the SDP_Attribute_Detail entity 1504. The SDP_Attribute entity 1514 further includes fields labeled Attribute_Table, Attribute_Table_Record_ID, Attribute_Value, Editable_Flag and Override_Flag.
The data model 1400 further includes an SDP-Request_Workflow entity 1516. This entity 1516 includes two fields which can serve both as primary keys and foreign keys. The first field is labeled Request_ID, which as a foreign key, points to a field with the same name in a SDP_Request entity 1518. The second field is labeled Workflow_ID and points to the field with the same name in the SDP_Workflow entity 1512. The SDP_Request_Workflow entity 1516 also includes fields named Schema_Name, Schema_ID and Status_ID containing other information about the request.
The data model 1400 further includes a REF Action_Type entity 1520. This entity 1520 has a primary key labeled Action_Type_ID and two additional fields for storing information about an action type. The first field is labeled Action_Type and the second field is labeled Action_Table.
Further, the data model 1400 includes a UD_LNK_Customer_User entity 1522. This entity 1522 includes two fields that can function as both primary keys and foreign keys. The first is labeled Customer_ID and as a foreign key, points to a field of the same name in a UD_Customer entity 1526. The second field is labeled User_ID and is linked to a UD_User entity 1524. The UD_User entity 1524 in turn includes the primary key SDP_UserID and has two additional fields for storing information about a user of the SDP system, labeled First_Name and Last_Name.
The data model 1400 further includes an SDP_Request entity 1518. This entity 1518 has as a primary key Request_ID. The entity 1518 further has as a foreign key a field labeled SDP_User_ID which is linked to the primary key of the UD_User entity 1524. The SDP_Request entity 1518 further includes fields labeled Schema_Name, Schema_ID and Status_ID for storing additional information about an SDP request.
The data model 1400 for SDP further includes an SDP_Action entity 1528. This entity 1528 includes a primary key labeled Action_ID and a foreign key labeled Action_TypeID which points to the primary key of the REF_Action_Type entity 1520. The SDP_Action entity 1528 further includes fields labeled Action_Value and Action_Identifier.
The data model 1400 further includes the UD_Customer entity 1530. This entity has a primary key labeled Customer_ID and an additional field labeled SDP_User_ID. Further, the data model 1400 includes Role_ID entity 1526. This entity 1526 has a primary key field labeled Role_ID and an additional field labeled Role_Description.
The data model 1400 includes a UN_LNK_User_Role entity 1526. This entity has two fields that can function as both primary keys and foreign keys. The first field is labeled Role_ID and as a foreign key, points to the primary key of the Role_ID entity 1526. The second field is labeled User_ID and points to the primary key of the UD_User entity 1524.
Further, the data model 1400 includes a UD_User_Address entity 1532. This entity has two fields that can function as both primary keys and foreign keys. The first field is labeled Address_ID and as a foreign key, points to the primary key of a SDP_Address entity 1534. The second field has a label of SDP_User_ID and as a foreign key, points to the primary key of the UD_User entity 1524.
Finally, the data model 1400 includes the SDP_Address entity 1543. This entity 1534 has as a primary key a field labeled Address_ID. This entity 1543 includes several additional fields for storing address information, including Address _—1, Address _—2, City_ID, State_ID, Country_ID, and Postal_Code.
From the foregoing, it can be seen that the present application provides a service delivery platform, including method and apparatus for managing the delivery of a variety of services to customers or subscribers. The service delivery platform (SDP) is a platform architecture that fully exploits the convergence opportunities made available for the service providers (SPs) recently. The SDP creates, hosts, and manages services over different channels and end user devices. The implementation of the SDP will dramatically simplify service deployment and management, and allow the enterprise to develop new services more rapidly with the reduced development efforts.
Illustrative Implementatons
By way of example, the following information illustrates products and processes in which the subject matter disclosed herein may be used. The following examples including the associated figures which are incorporated herein by reference.
Profile Management
Service Providers (SP) are striving to reduce the time and cost associated with going to market with Value Added Service Offerings. To address this business need, they are seeking to consolidate media such as voice, data, and video into a single enterprise architecture. This consolidation into a single architecture will enable the enterprise to deliver Value Added Services such as unified communications, video and media rich solutions, and collaboration and knowledge sharing.
The present Service Delivery Platform (SDP) is a Solution for helping mobile and fixed-line operators to cost-effectively create, deploy, and manage value-added data services and make them easily and securely accessible by consumers from anywhere, anytime, and on any device.
The SDP is a platform architecture that delivers the ability to consolidate Services, Service Enablers, Network Enablers, Operational Support Systems, and Business Support Systems onto a single Platform. It enables the service providers to create, host, and manage services over different channels and end user devices. The implementation of the SDP simplifies service deployment and management, and allows the enterprise to develop new services more rapidly with reduced development efforts.
The SDP Architecture is comprised of multiple Environment segments in order to more easily manage ongoing operations and additional development efforts.
The Service Orchestration & Brokering (SOB) Environment is not only be responsible for being the information “broker” among all interacting entities, but also be responsible for “orchestrating” the execution of business process based on the logical order of actions and the corresponding flow of messages for given process.
The Service Execution & Creation (SEC) Environment is focused on providing capabilities for Executing and Creating Services on the SDP. Service Creation provides a development environment for software developers to create new services and to extend existing ones. Service Execution consists of a standardized framework and architecture to execute services for subscriber or application. It encourages reuse of existing components and leverages sets of common services.
The Service Management & Control (SMC) Environment provides a centralized environment to manage and control data required by Services and Systems within and integrating with the SDP. It provides the ability to manage and control Identity, Service Catalog, Subscription, Relationship, and Personalization data through configuration using a series of Modules designed to hold the data required by Systems as they are integrated into the SDP.
SDP Service Management & Control (SMC) Environment is composed of six modules, each containing a subset of functionality delivering value to the Operator.
Service Catalog Management—This module defines the set of Products, Services, and Service Variants. It is responsible for Offer Management which determines the configuration of Services that are provided to Resellers, Organizations, and End Users.
Subscription Management—This module provides the ability to define sets of Offers as Solutions to represent an Organizations right for subscription. It accesses End User eligibility to Subscribe to Offers and keeps records of all subscribed offers.
Unified User Management—This module provides the ability to manage Organizations and Users. It provides authorization capabilities though defining capabilities and associating Roles with those capabilities.
Profile Management—This module provides the ability to define and manage sets of properties for a particular subject area which may be customized for an instance of an Entity on the SDP.
Relationship Management—This module provides a medium for communicating through well defined interfaces with Partners and ensures that they have the necessary and subscribed information and skills to provide high-quality services to their customers.
Personalization Management—This module is based on implicit and/or explicit profile. The rules are specified for user and content and define how the content is to be presented to the final user matching the right implicit and explicit profile.
This example will focus on the SDP SMC Profile Management Module. The Profile Management Module provides a generic and flexible structure enabling all SDP managed information, including Service Catalog, Subscription, and Directory information, to be centrally stored and accessed. As new SDP managed information is identified, it can be configured using standard APIs rather than requiring custom development effort.
The value delivered by the Profile Management Module is a result of the following design choices.
The Profile consists of elements that are fundamental so that new data can be configured with relationships to existing entities.
The Profile elements are structured in an efficient hierarchical way so that the searching and traversing the Profiles can be done with minimal effort.
The Profile Data Model is based on generic and flexible foundations to be inter-operable with other external systems.
The Profile contains all the selectable options and features for SDP entities. These options and features are configured as Attributes for each Entity.
Functional Architecture
The SDP SMC Profile Management Module is comprised of three major functional entities. There are two components defined to manage the instances of the entities created on the SDP. The structure and relationships of the entity provides the framework for SDP Profile Management.
The Entities defined for Profile Management are:
Profile Type—A Profile Type defines the behavior and relationships of instances of a Profile. It identifies the logical subset of information that should be included in instances of a Profile. A Profile Type can be related to multiple Entities and have Default Profile defined. It will be associated with Profile Type Rules to define behavior.
Profile—A Profile is a configured instance of a Profile Type. The relationships and behavior defined for the Profile Type will be applied to the corresponding Profiles. Many Profiles can be created for a single Profile Type.
Attribute—An Attribute is a fully defined unit of data. An attribute contains a definition, including the validation criteria and permitted values for the unit of data. It also contains information to suggest the way the data should be displayed. Profiles are comprised of collections of attributes in order to support the data needs of the SDP in a generic and flexible manner.
SDP SMC PM Profile Type Management
The Profile Type Management Component manages the Profile Type entity defined in the SDP environment. A Profile Type defines the behavior and relationships of instances of a Profile. It identifies the logical subset of information that should be included in instances of a Profile.
Profile Type Configuration
There are currently eleven Profile Types defined in the SDP SMC Profile Management Module. New Profile Types may be added as the Platform expands and/or for specific Client needs via the SG&C by Administrative User(s).
Define the Profile Type via the SG&C.
Associate the Profile Type with Profile Type Rules.
Create Entity and Profile Type Relationships.
Define Attributes for the Profile Type.
Create a Default Profile for the Profile Type.
Activate the Profile Type
ACS for SDP SMC PM Profile Management
The Profile Management Component manages the Profile entity defined in the SDP environment.
Profile Configuration
The behavior of a Profile is a result of the Profile Type that it is based on. Each Profile Type has a defined set of Rules associated with it to achieve the desired behavior. External systems are required to submit the data for management of a Profile according to the specific needs of a particular Profile Type. These Profile Type Rules are enforced within the Profile Management Module for each Profile on the SDP.
In addition, external systems are expected to submit the values associated with an Attribute according to the defined Attribute Masks. The compliance of the Attribute Value with the defined Attribute mask is enforced within the Profile Management Module during the Create and Update operations of a Profile on the SDP.
Product Profile
The Product Profile can be created via the SG&C by Administrative User(s). It can be created independently, but most often will be created during the Product creation process.
Retrieve the Default Profile for the Product Profile Type.
Populate the Product Profile Properties and values for the Default Product Profile Attributes.
Define additional Attributes of the Product, indicating the Attribute Mask, Display Format, and Validation Criteria for each Attribute.
Submit this information to the exposed Create Profile Web Service. The Profile Management Module will save this information as an instance of a Product Profile.
Or submit this information to the exposed Create Product Web Service. The Service Catalog Management Module will save this information as an instance of a Product Profile linked to the Product entity using the Profile Management Capabilities.
Service Profile
The Service Profile can be created via the SG&C by Administrative User(s). It can be created independently, but most often will be created during the Service creation process.
Retrieve the Default Profile for the Service Profile Type.
Populate the Service Profile Properties and values for the Default Service Profile Attributes.
Retrieve a Product that the Service will be based on. Select the Attributes of the corresponding Product Profile that will be used by the Service to add to the Service Profile. Repeat for each Product that the service will use.
Optionally assign values to the Attributes included in the Service Profile. (Note: values are normally assigned when creating the instance of the Service Profile to be associated with a Service Variant)
Submit this information to the exposed Create Profile Web Service. The Profile Management Module will save this information as an instance of a Service Profile.
Or submit this information to the exposed Create Service Web Service. The Service Catalog Management Module will save this information as an instance of a Service Profile linked to the Service entity using the Profile Management Capabilities.
Network Profile
The Network Profile can be created via the SG&C by Administrative User(s). It can be created independently or during the Service creation process.
Retrieve the Default Profile for the Network Profile Type.
Populate the Network Profile Properties and values for the Default Network Profile Attributes.
Define additional Attributes for the Network, indicating the Attribute Mask, Display Format, and Validation Criteria for each Attribute.
Assign Values to the newly defined Attributes.
Submit this information to the exposed Create Profile Web Service. The Profile Management Module will save this information as an instance of a Network Profile.
Or submit this information to the exposed Create Service Web Service. The Service Catalog Management Module will save this information as an instance of a Network Profile linked to the Service entity using the Profile Management Capabilities.
Offer Profile
The Offer Profile can be created via the SG&C by Administrative User(s). It can be created during the Offer creation process.
Retrieve the Default Profile for the Offer Profile Type.
Populate the Offer Profile Properties and values for the Default Offer Profile Attributes.
Define additional Attributes of the Offer, indicating the Attribute Mask, Display Format, and Validation Criteria for each Attribute.
Assign Values to the newly defined Attributes.
Submit this information to the exposed Create Offer Web Service. The Service Catalog Management Module will save this information as an instance of an Offer Profile linked to the Offer entity using the Profile Management Capabilities.
Service Provider Profile
The Service Provider Profile can be created via the SG&C by Administrative User(s). It can be created independently or during the Organization creation process.
Retrieve the Default Profile for the Service Provider Profile Type.
Populate the Service Provider Profile Properties and values for the Default Service Provider Profile Attributes.
Submit this information to the exposed Create Profile Web Service. The Profile Management Module will save this information as an instance of a Service Provider Profile.
Or submit this information to the exposed Create Organization Web Service. The Unified User Management Module will save this information as an instance of a Service Provider Profile linked to the Organization entity using the Profile Management Capabilities.
Customer Profile
The Customer Profile can be created via the SG&C by Administrative User(s). It can be created independently, but most often will be created during the Organization creation process.
Retrieve the Default Profile for the Customer Profile Type.
Populate the Customer Profile Properties and values for the Default Customer Profile Attributes.
Submit this information to the exposed Create Profile Web Service. The Profile Management Module will save this information as an instance of a Customer Profile.
Or submit this information to the exposed Create Organization Web Service. The Unified User Management Module will save this information as an instance of a Customer Profile linked to the Organization entity using the Profile Management Capabilities.
Vendor Profile
The Vendor Profile can be created via the SG&C by Administrative User(s). It can be created independently or during the Product creation process.
Retrieve the Default Profile for the Vendor Profile Type.
Populate the Vendor Profile Properties and values for the Default Vendor Profile Attributes.
Define additional Attributes of the Vendor, indicating the Attribute Mask, Display Format, and Validation Criteria for each Attribute.
Assign Values to the newly defined Attributes.
Submit this information to the exposed Create Profile Web Service. The Profile Management Module will save this information as an instance of a Vendor Profile.
Or submit this information to the exposed Create Product Web Service. The Service Catalog Management Module will save this information as an instance of a Vendor Profile linked to the Product entity using the Profile Management Capabilities.
User Profile.
The User Profile can be created via the SG&C by Administrative User(s). It can be created during the User creation process.
Retrieve the Default Profile for the User Profile Type.
Populate the User Profile Properties and values for the Default User Profile Attributes.
Submit this information to the exposed Create User Web Service. The Unified User Management Module will save this information as an instance of a User Profile linked to the User entity using the Profile Management Capabilities.
User Preference Profile
The User Preference Profile can be created via the SG&C by Administrative User(s). It can be created during the User creation process.
Retrieve the Default Profile for the User Preference Profile Type.
Populate the User Preference Profile Properties and values for the Default User Preference Profile Attributes.
Submit this information to the exposed Create User Web Service. The Unified User Management Module will save this information as an instance of a User Preference Profile linked to the User entity using the Profile Management Capabilities.
BSS OSS Profile
The BSS OSS Profile can be created at the request of External Applications (ex. CRM). It can be created during the Organization, User, Billing Account, or Subscription creation process.
Retrieve the Default Profile for the BSS OSS Profile Type.
Populate the BSS OSS Profile Properties and values for the Default BSS OSS Profile Attributes.
Submit this information to the exposed Web Services for Organization, User, Billing Account or Subscription entities. The Profile Management Module will save this information as an instance of a BSS OSS Profile.
Billing Profile
The Billing Profile can be created at the request of External Systems. It can be created during the Billing Account creation process.
Retrieve the Default Profile for the Billing Profile Type.
Populate the Billing Profile Properties and values for the Default Billing Profile Attributes.
Submit this information to the exposed Create Billing Account Web Service. The Unified User Management Module will save this information as an instance of a Billing Profile linked to the Billing Account entity using the Profile Management Capabilities.
Application Architecture
The SDP SMC Profile Management Module consists of a Profile Management (PM) Processor which exposes Business Capabilities to manage the Profiles and Profile Types via Web Services. The PM Processor has the ability to execute a defined set of tasks for each Business Capability against the APIs exposed by 2 self-contained Profile Management components.
Within Service Management and Control Environment, Profile Management (PM) is composed of:
Integration Tier: implements workflow according to the web service call that has been received in order to abstract the three components and allow segregation between each of them to facilitate ease of separation in the future. A workflow contains a group of atomic tasks to be executed over Business Tiers.
Business Tier: implements the atomic business methods, which map to the business tasks that SCM Processor has to invoke in order to respond to web service requests. Atomic actions like Create, Update, Get, Change Status, are implemented taking in account the required business specific logic of each component. Nevertheless, every business method has the same signature that receives and returns an SDP Message, guaranteeing flexibility.
Data Access Interface: implements an abstraction layer to the Data Access Tier, providing the business tier the same interface regardless of the Data Access Tier class implementation. In this way, the implemented interface methods have access to the other Data Tier Interfaces, permitting access to the whole data in the database schema, but still ensuring the separation between the several database functional blocks.
Data Access Tier: implements methods that provide a consistent way to access the database. This access is made by means of stored procedures rather than directly accessing the database tables. This provides flexibility to change table's internal structures as well as foreign keys relation without the need of changing the code at all. Only internal implementation of stored procedures will have to be changed.
for SDP SMC PM Profile Type Management
The Profile Type Management Component is comprised of three classes. These classes encapsulate the functionality necessary to manage the Profile Type entity as defined for the SDP.
The Profile Type Manager is the Business Tier class that exposes the APIs available to manage the Profile Type. This class accepts and returns an SDP Message object in all instances. In addition to returning the result of the operation, a status and event collection is returned within the SDP Message.
The Profile Type Data Access Interface provides access to the data required by the Profile Type Manager through enabling the ability to interact with Data Access Tiers of other SMC Components.
The Profile Type Data Access class provides functionality to manage the Profile Type data stored in the SDP Database. It executes stored procedures against the SDP Database to Create, Retrieve, Update, and Delete Profile Type data. The Profile Type Data Access class also instantiates and populates SDP entities with Profile Type data.
The Profile Type Management Component provides the following capabilities to the SDP.
Create Profile Type
Update Profile Type
Activate Profile Type
Inactivate Profile Type
Suspend Profile Type
Retrieve Profile Type
Retrieve Profile Types
Retrieve Profile Types by Entity
Retrieve Profile Type Rules
Create Default Profile
Update Default Profile
SDP SMC PM Profile Management
The Profile Management Component is comprised of 3 classes. These classes encapsulate the functionality necessary to manage the Profile entity as defined for the SDP.
The Profile Manager is the Business Tier class that exposes the APIs available to manage the Profile. This class accepts and returns an SDP Message object in all instances. In addition to returning the result of the operation, a status and event collection is returned within the SDP Message.
The Profile Data Access Interface provides access to the data required by the Profile Manager through enabling the ability to interact with Data Access Tiers of other SMC Components.
The Profile Data Access class provides functionality to manage the Profile data stored in the SDP Database. It executes stored procedures against the SDP Database to Create, Retrieve, Update, and Delete Profile data. The Profile Data Access class also instantiates and populates SDP entities with Profile data.
The Profile Management Component provides the following capabilities to the SDP.
Create Profile
Update Profile
Activate Profile
Inactivate Profile
Suspend Profile
Retrieve Profile
Retrieve Profiles by Profile Type
Retrieve Profiles by Status
Retrieve Profiles by Entity
Retrieve Profiles by Entity Type
SERVICE CATALOG Management
The SDP SMC Service Catalog Management Module is comprised of six major functional entities. Each functional entity has a Component defined to manage the instances of the entity created on the SDP. The structure and relationships of these entities provide the framework for the SDP Service Catalog.
The Entities defined for the Service Catalog are:
Product—A Product is an Application, System, or Platform from which Services can be created. A Product can be a Service Enabler, Network Enabler or Service Platform. Each Product will have a set of attributes configured within a Profile that is specific to the Application, System, or Platform.
Service—A Service is the application of Product(s) that has value to the Business/Consumers. A Service can be comprised of one to many Products. Each Service will have a set of attributes selected from the attributes defined for the Product(s) it is based on. A Service also has provisioning and service provider information associated with it.
Service Variant—A Service Variant is a configured version of a Service. This is where the specific values are set for the selected product attributes defined for the Service. A Service Variant also has provisioning and service provider information associated with it.
Offer—An Offer contains a relationship with one to many Service Variants. These Service Variants may be based off the same or different Services. An Offer has pricing defined and therefore is available to be offered to Organizations and Resellers.
Category—A Category is defined to provide segmentation of Service Catalog entities. A Category can be used to define a subset of Products, Services, or Offers that may need to be retrieved or managed as a group.
Price—A Price is associated to Offers. A Price has dimensions of Currency, Payment Term, and Payment Model.
SDP SMC SCM Product Definition Management
The Product Definition Management Component manages the Product entity defined in the SDP environment.
Product Configuration
The Product and Profiles are created and configured through the SG&C by Administrative User(s). The Product can be created using the following process:
Define a Vendor Profile if a Vendor Profile for the Vendor of the Product does not already exist. The Vendor Profile will be created in Active Status.
Define a Product via the SG&C. It will be created in New Status.
Define a Product Profile. Define all Attributes for the Product including the Attribute Masks, Display Settings, and Validation Criteria required to maintain data integrity. The Product Profile will be created in New Status.
Review and Activate the Product Profile.
Create Relationships between the Product and the related Profiles. This includes a mandatory relationship with a Product Profile and an optional relationship with a Vendor Profile.
Review and Activate the Product.
The Product is available to use for creating Services.
SDP SMC SCM Service Definition Management
The Service Definition Management Component manages the Service entity defined in the SDP environment.
Service Configuration
The Service and Profiles are created and configured through the SG&C by Administrative User(s). The Service can be created using the following process:
Define an Organization and Service Provider Profile if the required Service Provider does not already exist. The Service Provider Profile will be created in Active Status.
Define a Service via the SG&C. It will be created in New Status.
Define a Service Profile. Select the Attributes from the relevant Product Profiles to include into the Service Profile. The Service Profile will be created in New Status.
Review and Activate the Service Profile.
Define a Network Profile. Enter values into the Attributes defined for the Network Profile. The Network Profile will be created in New Status.
Review and Activate the Network Profile.
Create Relationships between the Service and the related Profiles. This includes a mandatory relationship with a Service Profile, Service Provider Profile, and Network Profile.
Review and Activate the Service.
The Service is available to use for creating Service Variants.
SDP SMC SCM Service Variant Definition Management
The Service Variant Definition Management Component manages the Service Variant entity defined in the SDP environment.
Service Variant Configuration
The Service Variant and Profiles are created and configured through the SG&C by Administrative User(s). The Service Variant can be created using the following process:
Select a Service to create a Service Variant on. Define a Service Variant via the SG&C. It will be created in New Status.
Select a Service Profile from the Service to create an instance off. Assign values to the Attributes based on the criteria specified by the Attribute Masks and Validation Criteria required to maintain data integrity. The instance of the Service Profile will be created in New Status.
Review and Activate the Service Profile.
Create Relationships between the Product and the related Profiles. This includes a mandatory relationship with a Service Profile, Service Provider Profile and Network Profile.
Review and Activate the Service Variant.
The Service Variant is available to include in Offers
SDP SMC SCM Offer Definition Management
The Offer Definition Management Component manages the Offer entity defined in the SDP environment.
Offer Configuration
The Offers and Profiles are created and configured through the SG&C by Administrative User(s). The Offer can be created using the following process:
Define an Offer via the SG&C, by selecting the Service Variants to include in the Offer and assigning Prices. It will be created in New Status.
Define an Offer Profile. Assign values to the Attributes based on the criteria specified by the Attribute Masks and Validation Criteria required to maintain data integrity. The instance of the Offer Profile will be created in New Status.
Review and Activate the Offer Profile.
Create Relationships between the Offer and the related Profiles. This includes a relationship with an Offer Profile.
Review and Activate the Offer.
The Offer is available to include in Solutions for subscription purposes.
SDP SMC SCM Category Definition Management
The Category Definition Management Component manages the Category entity defined in the SDP environment.
Category Configuration
The Categories are created and configured through the SG&C by Administrative User(s). The Category can be created using the following process:
Define a Product Category by creating a Category with the Category Type indicating Product via the SG&C. It will be created in Active Status.
Create relationships between the Category and the corresponding Products.
The Product Category is available to use for retrieving and managing the corresponding Products.
Define a Service Category by creating a Category with the Category Type indicating Service via the SG&C. It will be created in Active Status.
Create relationships between the Category and the corresponding Services.
The Service Category is available to use for retrieving and managing the corresponding Services.
Define an Offer Category by creating a Category with the Category Type indicating Offer via the SG&C. It will be created in Active Status.
Create relationships between the Category and the corresponding Offers.
The Offer Category is available to use for retrieving and managing the corresponding Offers.
SDP SMC SCM Price Definition Management
The Price Definition Management Component manages the Price entity defined in the SDP environment.
Price Relationships
Offer N/A N/A An Offer contains a relationship with one to many Service Variants. These Service Variants may be based off the same or different Services. Price N/A Mandaton A price contains the pricing information for an Offer. The price contains the value, currency, payment model, and payment term. Multiple prices can be related to a single Offer. Prices are unique
Price Configuration
The Prices are created and configured through the SG&C by Administrative User(s) when creating an Offer. The Price can be created using the following process:
Define a Price for an Offer via the SG&C.
Enter a Value for the Price.
Select a Currency for the Price.
Select a Payment Model for the Price.
Select a Payment Term for the Price.
Save the Offer with the defined Price.
The SDP SMC Service Catalog Management Module consists of a Service Catalog Management (SCM) Processor which exposes Business Capabilities to manage the Service Catalog via Web Services. The SCM Processor has the ability to execute a defined set of tasks for each Business Capability against the APIs exposed by six self-contained Service Catalog Management components.
Within Service Management and Control Environment, Service Catalog Management (SCM) is composed of:
Integration Tier: implements workflow according to the web service call that has been received in order to abstract the six components and allow segregation between each of them to facilitate ease of separation in the future. A workflow contains a group of atomic tasks to be executed over Business Tiers.
Business Tier: implements the atomic business methods, which map to the business tasks that SCM Processor has to invoke in order to respond to web service requests. Atomic actions like Create, Update, Get, Change Status, are implemented taking in account the required business specific logic of each component. Nevertheless, every business method has the same signature that receives and returns an SDP Message, guaranteeing flexibility.
Data Access Interface: implements an abstraction layer to the Data Access Tier, providing the business tier the same interface regardless of the Data Access Tier class implementation. In this way, the implemented interface methods have access to the other Data Tier Interfaces, permitting access to the whole data in the database schema, but still ensuring the separation between the several database functional blocks.
Data Access Tier: implements methods that provide a consistent way to access the database. This access is made by means of stored procedures rather than directly accessing the database tables. This provides flexibility to change table's internal structures as well as foreign keys relation without the need of changing the code at all. Only internal implementation of stored procedures will have to be changed.
SDP SMC SCM Product Definition Management
The Product Definition Management Component is comprised of 3 classes. These classes encapsulate the functionality necessary to manage the Product entity as defined for the SDP.
The Product Definition Manager is the Business Tier class that exposes the APIs available to manage the Product. This class accepts and returns an SDP Message object in all instances. In addition to returning the result of the operation, a status and event collection is returned within the SDP Message.
The Product Data Access Interface provides access to the data required by the Product Definition Manager through enabling the ability to interact with Data Access Tiers of other SMC Components.
The Product Data Access class provides functionality to manage the Product data stored in the SDP Database. It executes stored procedures against the SDP Database to Create, Retrieve, Update, and Delete Product data. The Product Data Access class also instantiates and populates SDP entities with Product data.
Product Definition Management
The Product Definition Management Component provides the following capabilities to the SDP.
Create Product
Update Product
Activate Product
Inactivate Product
Suspend Product
Retrieve Product
Retrieve Products
Retrieve Products by Category
Retrieve Products by Status
Update Product to Vendor Profile Relationships
Update Product to Product Profile Relationships
SDP SMC SCM Service Definition Management
The Service Definition Management Component is comprised of three classes. These classes encapsulate the functionality necessary to manage the Service entity as defined for the SDP.
The Service Definition Manager is the Business Tier class that exposes the APIs available to manage the Service. This class accepts and returns an SDP Message object in all instances. In addition to returning the result of the operation, a status and event collection is returned within the SDP Message.
The Service Data Access Interface provides access to the data required by the Service Definition Manager through enabling the ability to interact with Data Access Tiers of other SMC Components.
The Service Data Access class provides functionality to manage the Service data stored in the SDP Database. It executes stored procedures against the SDP Database to Create, Retrieve, Update, and Delete Service data. The Service Data Access class also instantiates and populates SDP entities with Service data.
The Service Definition Management Component provides the following capabilities to the SDP.
Create Service
Update Service
Activate Service
Inactivate Service
Suspend Service
Retrieve Service
Retrieve Services
Retrieve Services by Category
Retrieve Services by Status
Update Service to Service Profile Relationships
Update Service to Network Profile Relationships
Update Service to Service Provider Profile Relationships
SDP SMC SCM Service Variant Definition Management
The Service Variant Definition Management Component is comprised of three classes. These classes encapsulate the functionality necessary to manage the Service Variant entity as defined for the SDP.
The Service Variant Definition Manager is the Business Tier class that exposes the APIs available to manage the Service Variant. This class accepts and returns an SDP Message object in all instances. In addition to returning the result of the operation, a status and event collection is returned within the SDP Message.
The Service Variant Data Access Interface provides access to the data required by the Service Variant Definition Manager through enabling the ability to interact with Data Access Tiers of other SMC Components.
The Service Variant Data Access class provides functionality to manage the Service Variant data stored in the SDP Database. It executes stored procedures against the SDP Database to Create, Retrieve, Update, and Delete Service Variant data. The Service Variant Data Access class also instantiates and populates SDP entities with Service Variant data.
The Service Variant Definition Management Component provides the following capabilities to the SDP.
Create Service Variant
Update Service Variant
Activate Service Variant
Inactivate Service Variant
Suspend Service Variant
Retrieve Service Variant
Retrieve Service Variants
Retrieve Service Variants by Service
Retrieve Service Variants by Status
Retrieve Service Variants by Service and Status
Update Service Variant to Service Profile Relationships
Update Service Variant to Network Profile Relationships
Update Service Variant to Service Provider Profile Relationships
SDP SMC SCM Offer Definition Management
The Offer Definition Management Component is comprised of three classes. These classes encapsulate the functionality necessary to manage the Offer entity as defined for the SDP.
The Offer Definition Manager is the Business Tier class that exposes the APIs available to manage the Offer. This class accepts and returns an SDP Message object in all instances. In addition to returning the result of the operation, a status and event collection is returned within the SDP Message.
The Offer Data Access Interface provides access to the data required by the Offer Definition Manager through enabling the ability to interact with Data Access Tiers of other SMC Components.
The Offer Data Access class provides functionality to manage the Offer data stored in the SDP Database. It executes stored procedures against the SDP Database to Create, Retrieve, Update, and Delete Offer data. The Offer Data Access class also instantiates and populates SDP entities with Offer data.
The Offer Definition Management Component provides the following capabilities to the SDP.
Create Offer
Update Offer
Activate Offer
Inactivate Offer
Suspend Offer
Retrieve Offer
Retrieve Offers
Retrieve Offers by Category
Retrieve Offers by Status
Update Offer to Offer Profile Relationships
SDP SMC SCM Category Definition Management
The Category Definition Management Component is comprised of 3 classes. These classes encapsulate the functionality necessary to manage the Category entity as defined for the SDP.
The Category Definition Manager is the Business Tier class that exposes the APIs available to manage the Category. This class accepts and returns an SDP Message object in all instances. In addition to returning the result of the operation, a status and event collection is returned within the SDP Message.
The Category Data Access Interface provides access to the data required by the Category Definition Manager through enabling the ability to interact with Data Access Tiers of other SMC Components.
The Category Data Access class provides functionality to manage the Category data stored in the SDP Database. It executes stored procedures against the SDP Database to Create, Retrieve, Update, and Delete Category data. The Category Data Access class also instantiates and populates SDP entities with Category data.
The Category Definition Management Component provides the following capabilities to the SDP.
Create Category
Update Category
Activate Category
Suspend Category
Retrieve Category
Retrieve All Categories
Retrieve All Product Categories
Retrieve All Service Categories
Retrieve All Offer Categories
Update Category to Product Relationships
Update Category to Service Relationships
Update Category to Offer Relationships
SDP SMC SCM Price Definition Management
The Price Definition Management Component is comprised of 3 classes. These classes encapsulate the functionality necessary to manage the Price entity as defined for the SDP.
The Price Definition Manager is the Business Tier class that exposes the APIs available to manage the Price. This class accepts and returns an SDP Message object in all instances. In addition to returning the result of the operation, a status and event collection is returned within the SDP Message.
The Price Data Access Interface provides access to the data required by the Price Definition Manager through enabling the ability to interact with Data Access Tiers of other SMC Components.
The Price Data Access class provides functionality to manage the Price data stored in the SDP Database. It executes stored procedures against the SDP Database to Create, Retrieve, Update, and Delete Price data. The Price Data Access class also instantiates and populates SDP entities with Price data.
The Price Definition Management Component provides the following capabilities to the SDP.
Create Price
Update Price
Activate Price
Suspend Price
Retrieve Price
Create Currency
Update Currency
Retrieve Currency
Retrieve All Currencies
Create Payment Model
Update Payment Model
Retrieve Payment Model
Retrieve All Payment Models
Create Payment Method
Update Payment Method
Retrieve Payment Method
Retrieve All Payment Methods
Create Payment Term
Update Payment Term
Retrieve Payment Term
Retrieve All Payment Terms
Create Tariff
Update Tariff
Retrieve Tariff
Retrieve All Tariffs
Subscription Management
The SDP SMC Subscription Management Module is composed of two major functional entities. Each major functional entity has a Component defined to manage the instances of the entity created on the SDP. The structure and relationships of these entities provide the framework for SDP Subscription Management.
The Entities defined for Subscription Management are:
Solution—A Solution contains a subset of the Offers defined within the Service Catalog to be used by an Organization. The Solution provides the ability to limit which Offers are available to an Organization. A Solution may contain many Solution Offers.
Solution Offer—An instance of the Offer, called a Solution Offer, exists in the Solution to allow the configuration of the Offer to be customized for an Organization by an Administrative User.
Solution Service Variant—An instance of the Service Variant, called a Solution Service Variant, exists in the Solution Offer to allow the configuration of the Service Variant to be customized for an Organization by an Administrative User.
Subscription—A Subscription contains an instance of a Solution Offer, called a Subscription Offer, which has been subscribed by a User. A Subscription contains only a single Subscription Offer.
Subscription Offer—An instance of the Solution Offer, called a Subscription Offer, exists in the Subscription to allow the configuration of the Subscription Offer to be customized for User by the Subscriber or an Administrative User.
Subscription Service Variant—An instance of the Solution Service Variants, called Subscription Service Variants, exist in the Subscription to allow the configuration of the Subscription Service Variant to be customized by the Subscriber or an Administrative User.
SDP SMC SM Solution Management
The Solution Management Component manages the Solution entity defined in the SDP environment.
Solution Configuration
The Solutions are created and configured through the SG&C by Administrative User(s).
The Default Solution for Marketing & Sales is created and configured during setup.
Define a Default Solution belonging to the Marketing & Sales Organization.
Upon Offer definition, the Offers will be automatically added as Solution Offers to the Default Solution.
Custom Solutions for Organizations can be created and configured through the SG&C by Administrative User(s).
Define a Solution for an Organization.
Add Solution Offers from the Default Solution to the newly defined Solution.
Customize Solution Offers or Solution Service Variant attribute values for the Organization.
SDP SMC SM Subscription Management
The Subscription Management Component manages the Subscription entity defined in the SDP environment.
Subscription Configuration
The Subscription created and configured through multiple channels.
The Subscription can be created and configured via the Portal by Subscribers.
Select an Offer to subscribe to from the Portal and submit to SO.
The Subscription can be created and configured via SMS by Subscribers.
Enter a Code for subscription corresponding to an Offer to the Message Parser.
The Message Parser translates to the corresponding Offer and submitted to SO.
The Subscription can be created and configured via CRM by Agents.
Pass the Service Type Name for Subscription by a User to the SO via the BSS OSS IF.
The Subscription to a Solution Offer is created based on the Service Type Name.
Application Architecture
The SDP SMC Subscription Management Module consists of a Subscription Management (SM) Processor which exposes Business Capabilities to manage the Solutions and Subscriptions via Web Services. The SM Processor has the ability to execute a defined set of tasks for each Business Capability against the APIs exposed by 3 self-contained Subscription Management components.
Within Service Management and Control Environment, Subscription Management (SM) is composed of:
Integration Tier: implements workflow according to the web service call that has been received in order to abstract the three components and allow segregation between each of them to facilitate ease of separation in the future. A workflow contains a group of atomic tasks to be executed over Business Tiers.
Business Tier: implements the atomic business methods, which map to the business tasks that SCM Processor has to invoke in order to respond to web service requests. Atomic actions like Create, Update, Get, Change Status, are implemented taking in account the required business specific logic of each component. Nevertheless, every business method has the same signature that receives and returns an SDP Message, guaranteeing flexibility.
Data Access Interface: implements an abstraction layer to the Data Access Tier, providing the business tier the same interface regardless of the Data Access Tier class implementation. In this way, the implemented interface methods have access to the other Data Tier Interfaces, permitting access to the whole data in the database schema, but still ensuring the separation between the several database functional blocks.
Data Access Tier: implements methods that provide a consistent way to access the database. This access is made by means of stored procedures rather than directly accessing the database tables. This provides flexibility to change table's internal structures as well as foreign keys relation without the need of changing the code at all. Only internal implementation of stored procedures will have to be changed.
SDP SMC SM Solution Management
The Solution Management Component is comprised of three classes. These classes encapsulate the functionality necessary to manage the Solution entity as defined for the SDP.
The Solution Manager is the Business Tier class that exposes the APIs available to manage the Solution. This class accepts and returns an SDP Message object in all instances. In addition to returning the result of the operation, a status and event collection is returned within the SDP Message.
The Solution Data Access Interface provides access to the data required by the Solution Manager through enabling the ability to interact with Data Access Tiers of other SMC Components.
The Solution Data Access class provides functionality to manage the Solution data stored in the SDP Database. It executes stored procedures against the SDP Database to Create, Retrieve, Update, and Delete Solution data. The Solution Data Access class also instantiates and populates SDP entities with Solution data.
The Solution Management Component provides the following capabilities to the SDP.
Create Solution
Update Solution
Activate Solution
Inactivate Solution
Suspend Solution
Retrieve Solution
Retrieve Solutions
Retrieve Solutions with Active Solution Offers
Create Solution Offer in Solution
Update Solution Offer
Activate Solution Offer
Inactivate Solution Offer
Suspend Solution Offer
Retrieve Solution Offer
Retrieve Solution Offers by Status
ACS for SDP SMC SM Subscription Management
The Subscription Management Component is comprised of 3 classes. These classes encapsulate the functionality necessary to manage the Subscription entity as defined for the SDP.
The Subscription Manager is the Business Tier class that exposes the APIs available to manage the Subscription. This class accepts and returns an SDP Message object in all instances. In addition to returning the result of the operation, a status and event collection is returned within the SDP Message.
The Subscription Data Access Interface provides access to the data required by the Subscription Manager through enabling the ability to interact with Data Access Tiers of other SMC Components.
The Subscription Data Access class provides functionality to manage the Subscription data stored in the SDP Database. It executes stored procedures against the SDP Database to Create, Retrieve, Update, and Delete Subscription data. The Subscription Data Access class also instantiates and populates SDP entities with Subscription data.
The Subscription Management Component provides the following capabilities to the SDP.
Create Subscription
Update Subscription
Activate Subscription
Inactivate Subscription
Suspend Subscription
Retrieve Subscription
Retrieve Subscriptions
Retrieve Subscriptions By Status
Update Subscription Offer
Activate Subscription Offer
Inactivate Subscription Offer
Suspend Subscription Offer
Retrieve Subscription Offer
Update Subscription Service Variant
Retrieve Subscription Service Variant
Retrieve Subscription Service Variants
Unified User Management
Functional Architecture
The ACS SDP SMC Unified Management Module is comprised of 5 major functional entities. There are 2 Components defined to manage the instances of the entities created on the SDP. The structure and relationships of these entities provide the framework for SDP Unified User Management.
The Entities defined for Unified User Management are:
Organization—An Organization contains a set of Users. An Organization has a type of at least one of the following: Customer, Reseller, Service Provider. The Organization will contain a reference to the Default solution upon creation. This provides the organization with access to Solution Offers provided by the Marketing & Sales Organization. The Organization may also have a relationship with a unique Solution created for their Organization.
User—A User belongs to an Organization. It contains one to many Billing Accounts. A User also has associated Roles which list the privileges on the SDP that will be granted to the User.
Billing Account—The Billing Account contains the billing information provided by the CRM system to the SDP. It specifies the data required to apply charges and bill a user. A Billing Account has Payee and Owner relationships with Subscriptions.
Roles—A Role contains a list of Privileges that should be granted to a User on the SDP. A User can have multiple Roles and Roles can have multiple Privileges.
Privileges—A Privilege corresponds to an exposed capability on the SDP. A Privilege can be associated with multiple Roles.
SDP SMC UUM Directory Management
The Directory Management Component manages the Organization, User, and Billing Account entities defined in the SDP environment.
Organization Configuration
The Organization can be created via the SG&C by Administrative User(s).
Define an Organization via the SG&C. A Workflow will be executed to create the Organization. It will be created in Active Status. An Organization is created with a Customer Profile by default.
If the Organization is specified as a Service Provider, Define a Service Provider Profile to link to the Organization.
Review and Approve the Service Provider Profile.
The Organization can be created via CRM by Agents
Define an Organization via CRM through the BSS OSS IF. A Workflow will be executed to create the Organization. It will be created in Active Status. An Organization is created with a Customer Profile by default.
User Configuration
Administrative Users can be created and configured through the SG&C by Administrative User(s).
Define an Administrative User via the SG&C. A Workflow will be executed to create the User under the Organization specified. It will be created in Active Status.
A User will be created with the Roles assigned through the SG&C.
User and User Preference Profiles will be created with the data assigned through the SG&C
The Users can be created and configured via CRM by Agents.
Define a User via CRM through the BSS OSS IF. A Workflow will be executed to create the User. It will be created in Active Status. A User is created with User, User Preference, and BSS OSS Profiles by default.
Billing Account Configuration
The Billing Accounts can be created and configured via CRM by Agents.
Define a Billing Account via CRM through the BSS OSS IF. A Workflow will be executed to create the Billing Account. It will be created in Active Status. A Billing Account is created with Billing and BSS OSS Profiles by default.
SDP SMC UUM Credential Management
The Credential Management Component manages the Role and Privilege entities defined in the SDP environment.
Role Configuration
Roles can be created and configured through the SG&C by Administrative User(s).
Define a Role via the SG&C. A request will be submitted to create the Role on the SDP.
Create relationships between Privileges and the Role.
Create relationships between Users and the Role.
Privileges can be created and configured through the SG&C by Administrative User(s).
Define a Privilege via the SG&C. A request will be submitted to create the Privilege on the SDP.
Create relationships between an exposed SDP capability and the Privilege.
Create relationships between Roles and the Privilege.
Application Architecture
The ACS SDP SMC Unified User Management Module consists of a Unified User Management (UUM) Processor which exposes Business Capabilities to manage the Organizations, Users, Billing Accounts, Roles, and Privileges via Web Services. The UUM Processor has the ability to execute a defined set of tasks for each Business Capability against the APIs exposed by 2 self-contained Unified User Management components.
Within Service Management and Control Environment, Unified User Management (UUM) is composed of:

- Integration Tier: implements workflow according to the web service call that has been received in order to abstract the three components and allow segregation between each of them to facilitate ease of separation in the future. A workflow contains a group of atomic tasks to be executed over Business Tiers.
- Business Tier: implements the atomic business methods, which map to the business tasks that SCM Processor has to invoke in order to respond to web service requests. Atomic actions like Create, Update, Get, Change Status, are implemented taking in account the required business specific logic of each component. Nevertheless, every business method has the same signature that receives and returns an SDP Message, guaranteeing flexibility.
- Data Access Interface: implements an abstraction layer to the Data Access Tier, providing the business tier the same interface regardless of the Data Access Tier class implementation. In this way, the implemented interface methods have access to the other Data Tier Interfaces, permitting access to the whole data in the database schema, but still ensuring the separation between the several database functional blocks.
- Data Access Tier: implements methods that provide a consistent way to access the database. This access is made by means of stored procedures rather than directly accessing the database tables. This provides flexibility to change table's internal structures as well as foreign keys relation without the need of changing the code at all. Only internal implementation of stored procedures will have to be changed.

SDP SMC UUM Directory Management
The Directory Management Component is comprised of three classes. These classes encapsulate the functionality necessary to manage the Directory entity as defined for the SDP.
The Directory Manager is the Business Tier class that exposes the APIs available to manage the Directory. This class accepts and returns an SDP Message object in all instances. In addition to returning the result of the operation, a status and event collection is returned within the SDP Message.
The Directory Data Access Interface provides access to the data required by the Directory Manager through enabling the ability to interact with Data Access Tiers of other SMC Components.
The Directory Data Access class provides functionality to manage the Directory data stored in the SDP Database. It executes stored procedures against the SDP Database to Create, Retrieve, Update, and Delete Directory data. The Directory Data Access class also instantiates and populates SDP entities with Directory data.
The Directory Management Component provides the following capabilities to the SDP.
Create Organization
Update Organization
Activate Organization
Inactivate Organization
Suspend Organization
Retrieve Organization
Retrieve Organizations
Create User
Update User
Activate User
Inactivate User
Suspend User
Retrieve User
Retrieve Users
Create Billing Account
Update Billing Account
Activate Billing Account
Inactivate Billing Account
Suspend Billing Account
Retrieve Billing Account
Retrieve Billing Accounts
SDP SMC UUM Credential Management
The Credential Management Component is comprised of 3 classes. These classes encapsulate the functionality necessary to manage the Credential entity as defined for the SDP.
The Credential Manager is the Business Tier class that exposes the APIs available to manage the Credential. This class accepts and returns an SDP Message object in all instances. In addition to returning the result of the operation, a status and event collection is returned within the SDP Message.
The Credential Data Access Interface provides access to the data required by the Credential Manager through enabling the ability to interact with Data Access Tiers of other SMC Components.
The Credential Data Access class provides functionality to manage the Credential data stored in the SDP Database. It executes stored procedures against the SDP Database to Create, Retrieve, Update, and Delete Credential data. The Credential Data Access class also instantiates and populates SDP entities with Credential data.
The Credential Management Component provides the following capabilities to the SDP.
Create Role
Update Role
Activate Role
Inactivate Role
Suspend Role
Retrieve Role
Retrieve Roles
Retrieve Roles By User
Create Privilege
Update Privilege
Activate Privilege
Inactivate Privilege
Suspend Privilege
Retrieve Privilege
Retrieve Privileges
Retrieve Privileges By Role
These illustrative examples are meant to be illustrative only. The disclosed system and method may be extended beyond these examples and applied to other contexts as well. Those ordinarily skilled in the art will recognize that a wide variety of modifications can be made to the embodiments shown or described while remaining within the scope of the invention.
It is therefore intended that the foregoing detailed description be regarded as illustrative rather than limiting, and that it be understood that it is the following claims, including all equivalents, that are intended to define the spirit and scope of this invention.

Claims

1. A system for managing delivery of a plurality of unrelated services by one or more service providers, the system comprising:

a service delivery server;

a service delivery database which uses a common data model to combine records for subscribers to all of the plurality of unrelated services; and

a service orchestration platform in data communication with the service delivery server and the service delivery database,

wherein the service orchestration platform enables definition, orchestration, and implementation of the plurality of unrelated services.

2. The system of claim 1 further comprising:

a third party portal for service provision by the one or more service providers to service subscribers.

3. The system of claim 1 wherein the plurality of unrelated services comprise telecommunications services.

4. A service delivery platform (SDP) for managing delivery of a plurality of unrelated services by one or more service providers to service subscribers, the SDP comprising:

a service orchestration and integration environment which manages work flow for services, manages business processes for the service providers and integrates constituent applications;

a service creation environment for creation and modification of services;

a service deployment environment to automatically deploy services; and

a service assurance environment to identify faults in services.

5. The SDP of claim 4 further comprising a unified directory accessible by the service orchestration and integration environment, the service creation environment, the service deployment environment and the service assurance environment.

6. The SDP of claim 5 wherein the unified directory is configured to store Provide information regarding subscriber status, services subscribed by the user and details of user's device to access the subscribed services.

7. The SDP of claim 6 further comprising a database to store data for common access by the service orchestration and integration environment, the service creation environment, the service deployment environment and the service assurance environment.

8. The SDP of claim 6 further comprising a data model defining relations among data stored in the database for subscribers, subscription accounts and related information.

9. The SDP of claim 6 wherein the data model determines data type conversion rules for the data transformations between applications accessing the data stored in the database.

10. A service delivery method comprising:

storing in a common data model data of a service delivery platform about a plurality of telecommunications services, service providers and subscribers;

receiving a request from a service provider for creating a new service;

in response, requesting product definitions from a service catalog;

receiving the product definitions and providing the product definitions to the service provider;

receiving a request for service definitions associated with a selected product definition;

receiving service information for the new service based for the service definitions; and

automatically creating facilities for providing the new service, including extending the common data model information about the new service, the provider of the new service and subscribers to the new service.

11. The method of claim 10 wherein storing data comprises:

storing in a service entity information about a service;

storing in a product entity linked to the service entity, information about a product offered by a service provider; and

storing in a service variant entity linked to the service entity, information about a service variant.

12. The method of claim 11 wherein storing data further comprises:

storing in an offer entity information about a service offer; and

storing in an offer service variant entity a link between the offer entity information and the service entity.

13. The method of claim 11 further comprising:

providing a web service for interaction with the service delivery platform;

receiving the request to create a new service via the web service; and

providing the product definitions via the web service.

14. The method of claim 10 wherein automatically creating facilities comprises:

adding an application to provide the new service; and

mapping an application data model for the added application to the master model without mapping to other existing applications.

15. A service delivery platform for telecommunications services, the service delivery platform comprising:

a service creation environment to create the telecommunication services;

a service deployment environment for managing the telecommunication services in one or more networks;

a service enablement environment to execute the telecommunication services;

a service assurance environment to track and monitor the provision of the telecommunication services; and

a common data model accessible by each respective environment for creating and modifying services and accounts of the service delivery platform.

16. The service delivery platform of claim 15 wherein the service deployment comprises:

a configuration management module to manage attributes and values for a service.

17. The service delivery platform of claim 15 wherein the service enablement environment comprises:

a user interaction space for service users and service providers.