OPERATIONAL SUPPORT SYSTEM FOR COMMUNICATIONS

Abstract: An operation support system (OSS) for communications is built from a set of object-oriented software modules which can be distributed to be close to where data is being generated. The OSS is configurable, has standardised interfaces and can be designed to handle any of several aspects of operational support for a communications service, such as fault handling, order taking and session pricing. During use of the OSS, for instance for session pricing and logging, priced session data is encapsulated in an object and output to a customer management system. The OSS is configured by the use of policies. These can be preloaded but still accept data at runtime, making the OSS particularly flexible. Using a parser, it is possible to modify existing policies while an application programmable interface allows completely new policies to be added.

Description: OPERATIONAL SUPPORT SYSTEM FOR COMMUNICATIONS The present invention relates to operational support systems for communications networks. In co-pending International patent application number WO 96/2501 2, an information services provision and management system is described which deals particularly with access control, presentation of services to users and management of those services. Embodiments of the present invention are complementary to the information services provision and management system of co-pending patent application number WO 96/2501 2 in that embodiments of the present invention provide the "Back Office" systems such as billing and pricing and account management. Embodiments of the present invention could well be used in the same environment as described in said co-pending International patent application. Broadly, at the moment, two different types of operational support system (OSS) are deployed: large strategic systems for volume core services, and quick tactical solutions for high speed low volume services such as online information services. In both cases, the operational support systems are separate systems, or combinations of systems, managed independently from the services they support, and often remote from them. Both types of operating support systems are challenged by new market contexts. Large scale strategic systems generally have very long lead times and cannot respond rapidly to new service requirements. On the other hand, short term tactical solutions are typically isolated systems which do not inter-work with each other or with the strategic systems, and so do not allow cross-service packages to be marketed. The two types of OSS have completely different design philosophies and it is difficult to migrate services from one type to the other. A further issue is the operational cost of delivering the operational support functions. For example, for some information services such as reading a Worldwide Web Page, the cost of capturing and storing individual transaction records, and processing them to construct a bill, may significantly exceed the transaction price the market will bear. In such cases it may be necessary to tailor the support function around the commercial constraints. But there are often other reasons why data records are kept, for example for marketing intelligence and future product planning. There is a complicated trade off between the benefits of storing data and the costs incurred. Increasingly in the future, different types of services are likely to be offered over communications networks. For instance the increasing capability of technology is enabling a future where a wide variety of multimedia services can be delivered to users over communications networks. These services could include simple voice telephony, multimedia conference amongst many users, home shopping and video on demand. Additionally users may want such services to be delivered over a variety of terminal types such as a portable phone, portable personal computer and domestic television set with a set-top-box. These services come not only from development of the telecommunications environment, including telephony and cable television, but also from environments previously separate, such as the computing environment. For instance, there has been major growth of computer network services, such as those available on Internet. Collectively all these services can be referred to as information services Although to date (at least in the telephony world) the communication network operator and the service provider (SP) have generally coincided, this is not essential. Another trend expected in the future is that, increasingly, the service provider will be separate from the network operator. As in the case of Internet, several SPs (vendors) may offer their services (products) over a common network. Indeed, there may be further complexity involved in that the "common network" might in fact comprise multiple networks connected together, managed by many different network providers. In circumstances where many different services, supplied by multiple vendors, are available over one, or multiple, communications networks, there is an opportunity for service brokers or retailers. Competitive advantage can be gained by such brokers by offering customers better services and more effective access arrangements to those services. According to a first aspect of the present invention, there is provided a distributable operational support system, triggerable by use of a communications service by a user to provide at least one of the group of functions comprising fault handling, billing, customer help, and service provisioning, wherein the operational support system comprises means to receive a trigger related to said use of a service, and at least one data processing module, wherein said means to receive a trigger comprises means to issue, on receipt of a trigger, an instruction to the data processing module to process a set of data in respect of said related use of a communications service, and wherein said data processing module comprises: i) a configurable data set for use in providing one of the group of functions for an identified user; ii) a set of rules for use in processing said set of data, with reference to said configurable data set; iii) an inter-module interface for communicating with other modules; and iv) a management interface for use in reconfiguring the configurable data set. Embodiments of the present invention according to the first aspect can be provided by a set of objects, as understood in object-oriented software technology. For instance, one approach, as is used in embodiments of the present invention, to delivering flexible, interoperable business services for the future is to deploy a business object (in the sense of Object Technology) for each instance of a business service that is required. To carry out their functions, the business objects interact with each other and with the information services they are supporting. There can also be direct interaction between business objects and customers (eg to place an order or change a tariffing option), or between business objects and a business operations manager (eg to change prices or to deploy a new information service). Consequently several different types of interface can be defined: i) between each pair of business objects (the "intermodule interface"); II) between the business objects and the generic information services being supported; in) for direct customer interaction; and iv) for a business operations manager (a "management interface") In general, the interfaces need to be APIs (application programmable interfaces) Notion of standardised APIs is new for OSS functionality and it offers several benefits. First, it allows different instantiations of individual business objects depending on the application requirements, but such that the different instantiations can mteroperate. In addition, it is possible to move from one instantiation to another (eg to increase capacity to cope with greater volumes) without affecting the functional interactions. Second, different instantiations can be used at different granularities of operation - e.g. one instantiation could be attached to an individual information service, a second instantiation to groups of information services, and a third instantiation to an entire business. And third, standardised APIs allow information services from multiple service providers to be packaged together via common interfaces. The inter-module and management interfaces may of course be different parts of a common interface to the data processing module, each part simply being visible to different external objects or other system components This extends to the means to receive a trigger which may comprise part of the same interface The means to receive a trigger may be provided at least in part by another object in the system, or may be simply an input for receiving information from an external system such a standard call record, or session record, of some sort from a communications network such as a public switched telecommunications network or the Internet. A primary advantage of embodiments of the present invention is that it is not necessary to provide a centralised operational support system. Instead, operational support systems can be located so as to be close to where services are to be provided and used. For instance, the data processing modules can be distributed as objects to where different respective services of an available set of services are to be provided and used. In practice, an operational support system can be created from one or more templates, and instantiated, by management inputs. It can be instantiated to provide any of the group of operational support functions listed above, and additional functions such as outputting reports for data logging. By using a common interface across modules of an operational support system, it is possible to take a modular approach, adding both capacity and capability as services expand in usage and as more service types become desired in a portfolio. An important issue with business objects is designing the best granularity of operation, as mentioned above. At one (highly distributed) extreme, functionality could be attached to each atomic information service, with functionality built up incrementally through a service composition hierarchy to provide the support functionality for the overall service package. At the other extreme, a centralised OSS server could be used. In between are many gradations. The options need to be assessed for flexibility, ease of use, engineering feasibility and cost- effectiveness. Probably different distribution regimes will be appropriate for different business services (eg pricing might be highly decentralised and charging/billing centralised). A particular example of an operational support system according to an embodiment of the present invention is a pricing system. According to a second aspect of the present invention, there is provided an operational support system for use in providing at least one communications service, the system comprising a set of object-oriented modules, each module comprising data and at least one interface for accessing and modifying the data, the modules including: i) a service management system containing service data together with pricing policies for the or each active service and interfaces for adding new service data and viewing and changing existing service data; II) a customer management system which contains data about customers and includes interfaces for adding new customer data and viewing and changing customer data; and in) means for generating a session pricing and logging system for at least one active service, the session pricing and logging system having an interface for receiving session information about service usage by a customer of that active service, an interface for receiving at least one pricing policy from the service management system, means for associating a pricing policy with session information and means for outputting the session information and associated pricing policy to the customer management system. Preferably, the session pricing and logging system processes the session information by applying the relevant pricing policy to create a session object and it is the session object which carries the session information and associated pricing policy to the customer management system. The customer management system may preferably be divided into a customer management system and an account management system, the account management system containing data about accounts held by customers and including interfaces for adding new accounts and interviewing and changing existing accounts. In use of the system, a customer may initiate a service session. This is monitored in the session pricing and logging system which can take in information about service usage by customers by means of service session details, including event notifications, and which can then calculate the price that applies to each event notification by using a copy of the appropriate pricing policy provided by the service management system. Conveniently, the session pricing and logging system might associate the calculated price with the event notification and pass this priced session information to the customer management system, for instance to the account management system, for storage against the appropriate customer accounts. Modules as described above, according to either the first or the second aspects of the present invention, are capable of being configured by means of the use of policies which can be pre-loaded. Policy options can be included and selected either at run-time or compile-time. Alternatively, policies can be pre-loaded which can still accept inputs at run-time or compile-time. For instance, another object of the OSS might be designed to parse text into a policy. Policies can then be updated at a later time. For instance, in embodiments according to the second aspect of the present invention, the policies held in the service management system can be updated. These updated policies are then easily distributed to the relevant session pricing and logging system(s) and thus percolate through to customer bills, from the date of the update. The modules of embodiments of the present invention can be replicated and dispersed. For instance, it may be preferred that the service session pricing and logging module sits in customer premises, thus reducing traffic in a network due to information flow between modules of the OSS. In objects used in embodiments of the present invention according to the second aspect, there are three mam components: pricing, charging/billing and persistent storage. Initially, a pricing object operates with one configured instance per information service (le multiple instances of the object), but there is just one centralised instance of the persistent storage and one of a charging/billing object This is an example of the "granularity of operation" mentioned above. The aim with policies is to provide enough options (suitably parametrised) to cater for a wide range of information services. However, it is impossible to predict all policy requirements that will be needed in the future, so it is very advantageous to offer a programmable interface as well, to allow the introduction of completely new policies. A "second line of defence" helps for this; the use of object encapsulation to isolate potentially volatile aspects of the design. Connecting the programmable interface to a specific sub-object isolates the programmatic impact of a new policy, and provides the constraints to ensure interworking with other business objects and other information services. Other inventive aspects of the present invention are indicated in the attached set of claims. An OSS according to an embodiment of the present invention will now be described, by way of example only, with reference to the accompanying Figures in which: Figure 1 shows a schematic, functional block diagram of the OSS; Figure 2 shows in more detail a service management system for use in the OSS of Figure 1 ; Figure 3 shows a system for modifying pricing policies in the service management system of Figure 2; Figure 4 shows a customer management sytem for use in the OSS of Figure 1 ; Figure 5 shows attributes of an accounts, management system for use with the customer management system of Figure 4; Figure 6 shows a session pricing and logging system for use in the OSS of Figure 1 ; Figure 7 shows a service object for use in the service management system of Figure 2; Figure 8 shows a graphical illustration of a pricing policy for use in the OSS of Figure 1 ; Figure 9 shows a schematic block diagram of the process for logging a start notification by the OSS of Figure 1 ; Figure 1 0 shows a schematic block diagram of the process for pricing and logging an event notification by the OSS of Figure 1 , Figure 1 1 shows a schematic block diagram of the process for logging a session end notification by the OSS of Figure 1 ; Figure 1 2 shows a schematic block diagram of the process for logging a completed session by the OSS of Figure 1 ; Figure 1 3 shows a schematic block diagram of a charging and billing system for use in the OSS of Figure 1 ; Figure 14 shows the derivation of a specific charging policy from a general charging policy, for use in the OSS of Figure 1 ; Figure 1 5 shows a graphical representation of a specific discounting policy for use in the OSS of Figure 1 ; Figure 1 6 shows a charging policy editor hierarchy for use in editing charging policies such as the one of Figure 14; Figure 1 7 shows a bill creation interface for use in the charging and billing system of the OSS of Figure 1 ; Figure 1 8 shows a bill creation interface for both the charging and billing interface and the account management system of the OSS of Figure 1 , Figure 1 9 shows schematically the process steps involved in population of charges on a bill, in a bill production process; Figure 20 shows schematically the process steps involved in logging of a bill; and Figure 21 shows a hardware environment for the OSS of Figure 1 The following provides a description of a hardware environment relevant to embodiments of the present invention, together with general discussion of object-oriented technology and distributed processing environments, then goes on to give the top level design for an OSS according to an embodiment of the present invention, based on the use of configurable Business Objects. This OSS stores information about services, customers and their accounts. It provides a mechanism for storing service usage data, and it can produce bills that charge for service usage. HARDWARE ENVIRONMENT AND GENERAL DISCUSSION Software clearly provides the basis of the infrastructures needed in service provision systems according to embodiments of the present invention to implement scalable and deployable solutions Different types of software technology might be employed, and there are several functional design approaches which could be used. However, a common approach to the design and implementation of software systems in this technical environment uses object oriented software technology. This is known and used by international standards bodies (e.g. Open Software Foundation Object Management Group (OSF OMG), Open Systems Interconnection (OSI)). Reference might be made for example to "Object Management Architecture Guide", Revision 2.0, Second Edition, September 1 , 1 992. OMG reference: OMG TC Document 92.1 1 .1 . In general terms, "objects" in this context comprise units of software which represent entities or concepts of the real world by means of a combination of data and functionality. Data is encapsulated as internal attributes of an object and the associated functionality is encapsulated as methods which use or operate upon the attributes. Although an object may receive a message from another object requesting it to perform a method on its attributes which may result in the return of data, the attributes themselves are not directly accessible by external objects Such high degrees of encapsulation have not been readily available in earlier software technologies. From the perspective of the enterprises involved in satisfying the overall requirements of users for information services, there are likely to be significant challenges involved in designing a suitable infrastructure. A potential starting point would clearly be provision of an architecture (from high-level design to low-level implementation) that can technically and economically support such information services. Software and hardware resources of the computing infra-structure would be enabling components of the information service architecture. An aspect of the computing infrastructure is the processing environment and a known environment of suitable type for use in embodiments of the present invention is the distributed processing environment (DPE) which allows multiple processes to be run using multiple computer "nodes" . The DPE maintains a view of the multiple nodes and processes and handles message passing between nodes and objects, providing a common language for the exporting of interfaces for different objects residing on different nodes. That is, it assists with aspects of the software and hardware location transparency and facilitates the provision of scalable and deployable solutions. Standards for DPE already exist and are being extended. A node in this context might conveniently be provided by a computer with processors and memory which is capable of running an operating system, compatible distributed processing platform and objects executed as processes on the computer. Future information service retailing might be offered across a telecommunication information networking architecture that brings together elements of the multi-service network and DPE technologies mentioned. An example of such an architecture is that being defined by the TINA Consortium Reference might be made to "Telecommunications Information Networking Architecture" , Oshisanwo A., Boyd T., Proc. 4th IEEE Conf Telecommunications, IEEE, London 1 993. Such an architecture is based on Open Distributed Processing (ODP) principles of object orientation and distribution, applied to telecommunications system design using Telecommunications Management Network (TMN) managed objects and Intelligent Network (IN) concepts for service management and control In a TINA-C architecture, there are three sets of concepts, a logical framework architecture, a service architecture, and a management architecture. The logical framework architecture defines concepts and principles for the design of object-oriented software that operates in a distributed environment. Here a traditional layered computer architecture is defined, with computers and computer networks at the bottom, a distributed processing environment (DPE) in the middle, and (object-oriented) application software on top. The application software is itself subject to organisation in TINA-C The service architecture defines basic object types, and rules for their usage that can be used to design application software that provides services. A service is defined as a meaningful set of capabilities provided to a user. A service may have many users in different roles. For example, the end-user is the person who uses the service for its intended function, the service manager manages the service, and the network provider provides and manages the underlying resources required by a service. The notion of service in TINA-C applies to all applications that are accessible to users, including management services. The service architecture contains a call model suitable for a wide range of service types. The management architecture defines object types, and rules for their usage, that can be used to design application software to manage services, networks and computing systems. The (known) OMG type DPE core provides for communications between objects, provides dynamic bindings via a trader function and provides notification servers to give management information (such as faults, performance and the like). It provides generic "Application Programming Interfaces" (APIs) and message passing facilities. All application software is assumed to run on a DPE. Available documentation, in addition to the reference given above, includes a set of deliverables, such as "0-0 Modelling and Design", by J Rumbaugh et al, published by Prentice Hall in 1 991 , "Overall Architecture" TINA-C Deliverable 1 994 by M Chapman et al and "Guidelines for the Definition of Managed Objects", published in "The Management of Telecommunications Networks" edited by R Smith et al and published by Elhs-Horwood in 1 992 Referring to Figure 21 , the hardware view of a system in which embodiments of the present invention might be built is based on a transport network 1 101 which will carry for instance voice and data services, provided by service providers to users. The users will be connected to the network by different pieces of customer premises equipment (CPE) 1 102, 1 103 The various parties involved in offering and carrying those services, such as the service retailer, service provider and network provider, are also connected at computational nodes 801 to the transport network 1 101 . Data of various types may be available to the system, including for instance user profiles in a user profile store 1 1 04 sitting at a computational node 801 . Other data stores available by means of the transport network 1 101 , as shown, might include a policies data store 1 106 and a management information data store 1 107. The management information data store 1 107 may provide global management information in respect of services. Each computational node 801 is provided with a DPE kernel 81 1 , and therefore a protocol stack for use according to DPE principles. Embodiments of the present invention use policies. Policies for objects can be implemented as data structures stored on computer memory devices 1 1 06, which are interpreted by the component objects and can be dynamically updated. Use of policies is known and described in written publications such as a special issue of JSAC on network management, Volume 1 1 , No. 9, December 1 993, by J D Moffett and M S Sloman. "Session" and "Access" Concepts TINA-C systems make use of "session" concepts and "access concepts. These are as follows. Session concepts define those objects and interfaces that are required to support the initiation of, interaction with, and termination of services. Although services by their nature are different from each other, they all have a common fundamental property in that they provide a context for relating activities. Such a context is termed a Session. As a generic definition, the term session represents a temporal period during which activities are carried out with the purpose of achieving a goal. Three types of session have been identified: service session, user session, and communications session. A Service session is the single activation of a service. It relates the users of the service together so that they can interact with each other and share entities, such as documents or blackboards. A service session logically contains the service logic. A service session is computationally represented by a service session manager. A service session manager offers two types of operational interfaces. The first is a generic session control interface. This provides operations that allow users to join and leave a service. For certain services it may also offer operations to suspend and resume involvement in a service. The second type of interface will provide service specific operations, and will be dictated by the capabilities offered by the service logic. The ability to suspend and resume involvement in a service is a desirable feature for some services. For example, consider a multi-media conference that occurs over several days. During the night, when the conference is not in use, it should be possible to release expensive communications resources. The service session can maintain state about the conference, such as the users and resources involved. Maintenance of state and the ability to suspend and resume involvement would avoid the need for tearing down and recreating the service each day. A User session maintains state about a user's activities and the resources allocated for their involvement in a service session. Examples of state held in a user session include the user's accumulated charge, suspension and resumption history, and service specific state such as the current page being edited in a distributed document editing service, for example. When a user joins a service session, a user session is created. It is deleted when he leaves. The service session maintains links to the user sessions and thus provides a group oriented view. A Communication session is a service oriented abstraction of connections in the transport network. A communication session maintains state about the connections of a particular service session, such as the communication paths, end-points and quality of service characteristic A communication session is required only when stream between computational objects are required. Computationally a communication session manager provides the features of a communication session. It provides a connection graph interface of a service session to manipulate. A connection graph is an abstraction that defines concepts such as end-points and lines. A service session expresses connectivity requirements be adding, removing and linking end-points and lines. A service session manager will request connectivity between stream interfaces of computational objects. The communication session manger calls upon connection management objects to establish physical connections between the network access points of the relevant computing node, and nodal services that allow for a network access point to be connected to the software stream interface Connection management components are not discussed further in this specification A user can be simultaneously involved in multiple service sessions. A service session has one or more users associated with it, and for each associated user there will be a related user session. A service session may have one or more communication sessions if the service involves stream communication A communication session is related to exactly one service session. The purpose of these separations is to decouple service oriented activities from connection oriented activities. Many types of services may exist in a future network and not all will require the explicit establishment of connections (streams) The service session is therefore a point of control for all service types, creating communication sessions when necessary TOP LEVEL DESIGN FOR THE OSS This design has been implemented in Distributed Smalltalk for Visualworks, and the implementation is called P6 Any reference to "P6" in the following should be understood accordingly. In the following, it is first described how an OSS can be built from a number of business objects, and which business objects are included. Each of these business objects is then described in detail. Lastly, the objects that are used within the business objects are described in more detail. Referring to Figure 21 , the systems of the OSS described below will be installed on computing platform such as the communication nodes 801 shown and will for instance receive session information and other communications by means of the transport network 1 101 . In general terms, as will seen from the following specific description, the systems receive data and control inputs, respond to those inputs by generating and/or deploying data processing functionality, and output billing data concerning usage of communications services, processed according to prevailing pricing and charging policies. Design technique The design presented in this document has been developed using a technique based on Jacobson's Use Case Analysis [as set out in Ivar Jacobson, Object-oriented software engineering, A Use Case driven approach, Addison-Wesley, 1 992.] Designs developed using this technique are fully application-oriented, and do not consider the implementation environment. When a design meets its requirements, implementation can take place in the chosen environment. By excluding implementation needs from the design it becomes based purely on the problem and not on conditions prevailing during implementation. This has the advantage that the design can remain intact, should the implementation conditions change. Designs that are built using Use Case Analysis consist of two system models: a requirements model and an analysis model. The requirements model describes the functionality of the system. It describes the actors that may use the system, and the use cases which describe how the actors use the system. Actors may be human users or other systems communicating with the system being designed. The analysis model is derived from the requirements model. It gives a conceptual configuration of the system, consisting of control objects, entity objects and interface objects. Interface objects support the communication between actors and the system. Entity objects model the information that the system will handle over a longer period of time (persistent data). Control objects glue the interface objects and entity objects together; they usually exist for performing specific tasks and do not store persistent data, nor communicate directly with actors. The following presents the requirements and analysis (design) models for the business objects of P6. The requirements model consists of the general system description. The analysis model consists of the object diagrams and object descriptions. AN OSS BUILT FROM BUSINESS OBJECTS A Generic Case Referring to Figure 1 , an operational support system that supports a business which provides a number of services to a number of customers, and that can charge for their service usage, can be built from the following business objects: 1 . A Service Management System 1015 which contains data about services 1025, and includes interfaces for adding new services and viewing and changing existing services. It contains pricing policies 1020 for each active service; it provides business operations managers with an interface allowing them to change the pricing policies. The pricing policies 1020 define the prices that apply to event notifications. These prices depend on the service that generated the events, and event details such as time of occurrence or units content. 2. A Customer Management System 1035, which contains data 1095 about customers, and includes interfaces for adding new customers and viewing and changing customer data. 3. An Account Management System 1040, which contains data 1 065 about accounts held by customers, and includes interfaces for adding new accounts and viewing and changing existing accounts. 4. One Session Pricing and Logging System 1000 for each active service, which takes in information about service usage by customers, in the shape of service session details (including event notifications). It calculates the price that applies to each event notification, using a copy of the appropriate pricing policies 1010 for the service. It attaches this price to the event notification, and passes priced session information to the Account Management System 1040 for storage against the appropriate accounts. 5. A Charging and Billing System 1045 which produces bills for the accounts registered in the Account Management System 1 040. It uses charging policies 1060 which define how event prices are converted into actual charges which appear on a bill. It provides business operations managers (BOMs) with an interface allowing them to change the charging policies. 6. A Management Information and Control System 1030, which provides the BOMs with an interface through which they can view all that is going on in the system, and correlate any information. In this case the information that they can view will be limited to that generated by the other business objects. This system will make the policy management interfaces of the pricing and charging subsystems available to the BOM. An OSS may contain more than one of each of the business objects. For example, an OSS may support a number of service providers, each with a distinct set of customers. In this case, one may wish to include one Customer Management System 1035 and one Session Pricing and Logging System 1000 per service provider Implementation in P6 P6 as described below implements an OSS with one of each of the business objects only, but it may in particular have more than one Session Pricing and Logging System 1 000. In the design that follows, the differences between the generic design mentioned above and that of P6 have been indicated. Figure 1 shows the configuration of the OSS implementation of P6. When in P6 an OSS is started, it will consist of a Service Management System 101 5, a Customer Management System 1 035, an Account Management System 1040 and a Charging and Billing System 1 045 Management Information and Control business object 1030 is shown, but it is not essential. Session Pricing and Logging Systems 1000 are created when services are activated. In Figure 1 , the business objects in P6 are drawn individually, and their most important components are shown. Entity objects are drawn as small circles. Thin arrows with small arrowheads indicate entity relationships (e.g. an Account object knows about its Payment objects, Bill objects etc.). Fat arrows with bold arrowheads show which systems invoke methods on other systems. The people shown represent business operations managers and customer handling personnel. THE SERVICE MANAGEMENT SYSTEM 1015 Referring to Figure 2, a Service Management System 101 5 holds the details of services known to the OSS. There may be more than one Service Management System 101 5 in an OSS. P6 incudes one Service Management System 1 01 5 only however. A Service Management System 101 5 provides interfaces for viewing and updating details of existing services and for adding details of new services. Attributes Of The System The Service Management System 101 5 contains an attribute called services 1025, which is an indexed list of Service objects 1 1 05. Each Service object 1 1 05 contains the details of a service, and can be identified by a unique serviceld. Service details include the name, id and status of the service. They may also include the dates on which the service was created, activated or ceased, details of the service providers, details of problems that have occurred with the service, etc. The status of a service can be inactive, active, suspended or ceased. When a new Service object 1 1 05 is created, its status attribute is set to inactive. In the Service Management System 101 5 of Figure 2, the attribute services 1025 contains one Service object 1 105 for each existing service. Each Service object has an attribute pncingPolicies which may contain a Pricing Policies object 1020, which represents its pricing policies. These policies define the base prices that apply when a customer uses the service. Such prices may e.g. be based on time the service was used or the units of content provided by the service. Full details of the PncmgPolicy object 1020 are provided below, under the heading "The Session Pricing and Logging System". Each Service object also has an attribute pncingSystems, which contains references to all Session Pricing and Logging Systems that handle the session information for this service. Interfaces Provided By The System The Service Management System 101 5 provides interfaces which allow for the following: • viewing the list of all existing services viewing details of an existing service activating, deactivating, ceasing an existing service viewing the pricing policies for a service changing the pricing policies for a service • adding details of a new service Activating And Deactivating A Service To activate (launch) a service, its pricing policies must be specified and stored in a PncmgPolicies object 1020, which forms the pπcingPolicies attribute of the appropriate Service object 1 1 05. Once the pricing policies for a service are in place, the Service Management System 1 01 5 may be invoked to activate the service. When invoked, it will create a Session Pricing and Logging System 1000 which is dedicated to accepting session information for that service only. It provides that system with a copy of the pricing policies for the service. There may be more than one Session Pricing and Logging System 1000 for a service (e.g. one for each service provider offering this service) . P6 only shows one such system per service. References to the Session Pricing and Logging System 1000 that exist for a service, are held in the pncingSystems attribute of the corresponding Service object 1 105 A service may be deactivated, in which case all its Session Pricing and Logging Systems must be closed down gracefully. Also, sometimes only a selection of these systems may need to be closed down, when e.g. a service provider ceases trading. The Service Management System 101 5 provides interfaces for deactivating services and closing down their Session Pricing and Logging Systems 1 000. Changing The Pricing Policies 1020 For A Service Referring to Figure 3, while a service exists, its pricing policies 1020 may be changed. The Service Management System 1 01 5 provides an interface for this. When the system is invoked to change the policies for an active service, it will pass a new PricingPolicies object 1 020 to the appropriate Service object 1 105. That Service object will update its pricingPolicies attribute and pass a copy of the new PricingPolicies object 1 01 0 to all existing Session Pricing and Logging Systems 1000 for that service. Pricing policies' changes may also be provided to apply from a certain date, and for a specified amount of time (e.g. for a Christmas special). THE CUSTOMER MANAGEMENT SYSTEM 1035 Referring to Figure 4, a Customer Management System 1035 holds the details of customers known to the OSS.. There may be more than one Customer Management System 1035 in an OSS. This could e.g. be useful when there is more than one service provider: each Customer Management System 1035 could then hold details of the customers for a particular service provider. A Customer Management System 1 035 provides interfaces for viewing and updating customer details. It has very close links with the Account Management System(s) 1040 which holds details of the accounts held by the customers. In P6 as described below only one Customer Management System 1 035 is included. The rest of this section describes the scenario of P6, where there is one Customer Management System 1035 supported by one Account Management System 1040. Attributes In The System The Customer Management system 1035 contains an attribute called customers 1095, which is an indexed list containing a Customer object for each existing customer. Each Customer object 1 1 00 holds the details of one customer, and can be identified by a unique customerld. Customer details include the name and id of the customer. They may also include their address, credit status, etc. A customer may hold one or more accounts. To reflect this, each Customer object 1 100 has an attribute accounts, which contains a reference to all Account objects that represent accounts for which the customer is liable. Account objects 1070 are held in an Account Management system 1040, which is described in more detail in a following section entitled "The Account Management System". The Customer Management System 1 035 uses attribute accountManagement 4000, which contains a reference to the Account Management System 1040 that holds the Account objects 1070 for its customers. Figure 4 shows the main elements of the Customer Management System 1035 and the relevant parts of the Account Management System 1040. The Customer Management System 1035 uses objects of classes Customer, Account and Account-Management. These classes are described further in the following section and in the section entitled "Class Definitions". Interfaces provided by the system The Customer Management system 1035 provides interfaces which allow the following: viewing the list of all customers viewing details of an existing customer viewing the list of accounts for an existing customer viewing the account details for an existing customer adding a new customer updating the details of an existing customer • updating the account details of an existing customer creating a new account for an existing customer THE ACCOUNT MANAGEMENT SYSTEM 1040 Referring still to Figure 4, an Account Management System 1 040 holds the details of accounts for customers known to the OSS. There may be more than one Account Management System 1040 in an OSS. This could be useful when there is more than one Customer Management System 1035: each Account Management System 1040 could then hold details of the accounts for the customers of one of these Customer Management Systems 1035. An Account Management System 1040 provides interfaces for viewing and updating account details. It has very cJose links with the Customer Management System(s) 1035 that hold the details of the customers liable for these accounts. In P6, only one Account Management System 1040 is included. The rest of this section describes the scenario of P6, where there is one Account Management System 1 040 supported by one Customer Management System 1035. Attributes Of The System The Account Management system 1040 contains an attribute called accounts 1065, which is an indexed list containing an Account object 1070 for each existing account. Each Account object 1070 can be identified by a unique accountld. Accounts must be associated with a customer who is liable for the charges on the account, hence each Account object 1 070 is linked to a Customer object 1 100 (held by the Customer Management system 1035). This link is bidirectional, so that the Customer Management system 1035 can easily find all the accounts for which a customer is liable. The Account Management system 1 040 uses the attribute customerManagement 4005, which is set to contain the reference to the Customer Management system 1 035 that holds the customer data for its Accounts. The accounts attribute 1065 contains one Account object 1 070 for each account known to the Account Management System 1 040. Each Account object holds account details, such as information on when the account was created, the type of account, the address that bills need to be sent to (this may be different from the address of the associated liable customer), etc. It also includes details on the service usage that is to be charged to the accounts (stored in attribute sessions), bills that have been generated for the account (attribute bills) and payments that have been made to the account (attribute payments) , and a reference to the Customer object 1 100 representing the liable customer (attribute customer). Referring also to Figure 1 , the sessions attribute of an Account object 1070 contains service usage details in the form of Session objects 1085, which are generated by the Session Pricing and Logging System 1000 based on service usage information received from a service provider. As soon as a new session start notification is received for the account, the Session Pricing and Logging System 1 000 notifies the Account Management System 1040 that there is a session in progress. The Account Management System will then add a reference to the new Session object being generated in the Session Pricing and Logging System 1000 to the sessionsOpen attribute of the relevant Account object 1 070. 5 Once the Session Pricing and Logging System 1000 has received all details of the session, it passes the completed Session object 1085 to the Account Management System 1 040, which in turn will store the Session object 1085 in the sessions attribute of the Account object 1 070 that will be charged for it. The generation of the Session objects is described in 10 detail in one of the following sections. This is a fine example of the 'store objects where they are relevant' policy adopted in the design, i.e. while the Session object 1085 is being generated it exists in one system, the Session Pricing and Logging System 1 5 1000, and once it is complete, it is passed on to another system for further storage. Payment details are contained in Payment objects 1080. Each payment that has been made to an account is captured in a Payment object, which 20 is initially stored in the payments attribute of the appropriate Account object 1070. When a bill is generated (by the Charging and Billing System 1 045 described in a following section), a Bill object 1 075 is created that contains 25 the details of the bill. This object is stored in the bills attribute of the Account object 1070 for which it was generated. A bill may charge for zero or more Session objects 1085 and acknowledge zero or more payments. When a Charging and Billing System 1045 wishes to create a bill, it will first notify the Account Management System 1040, which will in 30 turn move the contents of the sessions and payments attribute to the sessionsForNewBill and paymentsForNewBill attributes of the appropriate Account object 1070. This will allow the construction of a bill to be done while ongoing service usage can be recorded at the same time. Note that this is another example of the 'store objects where they are relevant' policy, as the Bill object 1075 is being held by the Charging and Billing System 1045 while it is being filled with appropriate details; once it is completed, it is passed to the Account Management System 1040 for storage against the Account. When a Bill object 1075 has been generated it is passed to the Account Management System, which will place the Bill object in the bills attribute of an Account object 1070. The Account Management System 1040 will then move the contents of the sessionsForNewBill and paymentsForNewBill attributes of the appropriate Account object 1 070 to the sessions and payments attributes of the Bill object 1075. In addition accounts may be set up with subscriptions to particular service, indicating e.g. that they charge only for usage of these services. It would be possible to use PricedEvents for this, or to introduce Subscription objects to hold subscription details. Figure 5 shows an Account object 1070 and its links to Service, Customer, Payment, Session and Bill objects. Note that each Account object 1 070 knows about : 1 . the Customer object 1 1 00 that represents the customer that is liable for the account; 2. the Session objects 5020 that are to be charged to the account, but for which a session end notification has not yet been received, and/or which have not yet been included on any bill; 3. the Session objects 5025 that are currently being used in the production of a bill; 4. the Payment objects 5005 that represent payments made to the account, which have not yet been acknowledged on a bill; 5. the Payment objects 5000 that are currently being used in the production of a bill; 6. the Bill objects 1075 that represent the bills generated for the account; For each bill, there exists one Bill object 1075, which can be accessed from the Account object 1070 for which the bill was generated. Each Bill object that exists in the Account Management System 1040 knows about: 1 . the Payment objects 5010 which represent payments that have been acknowledged on the bill; 2. the Session objects 501 5 that represent the sessions that are charged for on the bill. The Session objects 5020, 5025, 501 5 that exist within the Account Management system 1040 represent sessions that are completed (closed). Each Session object represents one session. A Session object is accessible either directly from an Account objec 1070 (when it has not yet been charged for), or directly from a Bill object 1075 (that represents the bill that charges for it) . A Session object knows about: 1 . the Priced Event objects 5030 that represent the event notifications that form part of the session. Interfaces Provided By The System The Account Management System 1 040 provides interfaces to the Customer Management System 1035, the Session Pricing and Logging System 1000 and the Charging and Billing System 1045. Interfaces for use by the customer management system 1035: An interface for providing a new accountld, used when a new account is being set up for a customer. An interface for logging a new Account object 1070, used when a new account has been created and needs to be stored. Interfaces for use by session pricing and logging systems 1000: An interface for providing a new sessionNo that is unique for the account to which it is to be booked. Invoked when the Session Pricing and Logging System 1000 receives a session start notification. An interface for passing details of a Session object that has just been created in the Session Pricing andLogging System, but for which no session start notification has been received. An interface for logging a completed Session object 1085, used when the session end notification has been received by the Session Pricing and Logging System. Interfaces for use by the charging and billing system 1045: An interface for supplying account details to a Charging and Billing System 1045 when that system wishes to create a new bill for a specific account. An interface for logging a Bill object 1075 which has just been created and completed by a Charging And Billing System. Receipt of a new bill object 1075 for an account, involves also moving details from the attributes sessionsForNewBill and paymentsForNewBill for that Account object 1 070 (as described earlier). THE SESSION PRICING AND LOGGING SYSTEM 1000 Referring to Figures 1 and 6, Session Pricing and Logging Systems 1 000 are created by a Service Management System 1 01 5 when a service is activated. Each Session Pricing and Logging System 1000 is dedicated to one service only. It is responsible for accepting, pricing and storing information about the usage of that service by customers. This information is offered to the system by service providers. One Session Pricing and Logging System 1000 may serve more than one service provider. One service provider may pass information on service usage to more than one Session Pricing and Logging System. When a Service Management System 101 5 creates a Session Pricing and Logging System 1000, it passes that system a copy of the pricing policies 1020 for the service to which it is dedicated. Whenever the pricing policies 1020 for that service are updated in the Service Management System 101 5, that system will ensure that a new copy of the pricing policies is passed to all Session Pricing and Logging Systems for that service. Information 6000 about service usage by customers is offered to the Session Pricing and Logging System 1 000 in the form of service session details, which may include event notifications Upon receiving session details, the Session Pricing and Logging System creates a Session object 6005 and attaches to this one PπcedEvent object 6010 for each event notification that belongs to the service. For each PπcedEvent object 6010, it calculates the applicable price, using its pricing policies 1010, and adds this price to the object. Once all details of a session have been received and appropriately mapped in a Session object 6005, it passes the completed object to the Account Management System. An OSS may contain more than one Account Management System 1 040. When there are two or more such systems, the Session Pricing and Logging System 1000 must ensure that the Session object 6005 which it creates is sent to the appropriate Account Management Systems, i.e. each Session object 6005 must be sent to the system that contains the Account object 1070 for which the Session was created. (In P6, one Account Management system is described) Attributes Of The System Each Session Pricing and Logging System 1 000 contains attribute pricingPolicies, which contains a copy 1 01 0 of the pricing policies for the service to which it is dedicated. The master of these pricing policies is held in the Service Management system 101 5 against the Service object 1 105 for it is defined. The pricing policies 1020, 1010 define the prices that apply to event notifications that form part of service sessions. The Session Pricing and Logging System 1000 stores session information in Session objects 6005, which it creates for the purpose. Event information that forms part of the session is priced and stored in PricedEvent objects 6010 against the Session object 6005. While a session is in progress, the Session object and the associated PricedEvent objects are stored by the Session Pricing and Logging system in its attribute sessionslnProgress 6015. When a Session is completed, i.e. all information concerning it has been received and stored within it, it is transferred to the Account Management system 1040, which stores it against the Account object 1 070 for the account that will be charged for it. The Session Pricing and Logging System 1000 has an attribute which contains a reference to the Account Management System 1 040 to which it transfers Session objects 6005. It also contains a reference to the Service Management System 1 01 5 to allow service related warning messages to be posted. Figure 6 shows the Session Pricing and Logging system 1000 and its links with the service provider, the Service Management system 1 01 5 and the Account Management system 1040. Session information The service providers supply the Session Pricing and Logging system 1000 with session information 6000 concerning the usage of the service by customers. When a customer uses a service the service provider generates service session details, which include: 1 . a session start notification; 2. zero or more_ event notifications describing the events that occurred within the session, each event notification including eventDetails such as either a duration (time) or a number of units 'contents'; 3. a service session end notification. Each of these notifications contains: serviceld : the id of the service that generated the session sessionld : the unique id of the session, unique to the Session Pricing and Logging System. accountld : the account to which the session is to be booked timeStamp : the time the notification was generated. When there is more than one service provider supplying session information to the same Session Pricing and Logging System 1000, they must still provide sessionld's which are unique to the receiving system. This can be done by combining some service provider id with sessionld's that are unique to that service provider. Notifications that belong to the same session will have the same sessionld, serviceld and accountld. As all three types of notifications contain the same four basic attributes, a Notification abstract class is introduced, containing these attributes. The three notifications are then offered as objects of the classes SessionStartNotification, EventNotification and SessionEndNotification, each of which inherits from the Notification class. Sessions may overlap but it is assumed that for each session, the session start notification will arrive first, followed by zero or more event notifications, followed by the session end notification. Sometimes more than one customer may be involved in the same usage of a service (e.g. where a conference call is made). In that case service session information is created for each account to which (part) of the service usage will be charged. The service provider is expected to split the usage up accordingly. P6 assumes two types of eventDetails to be used in event notifications: they identify DurationBased events and UnitContentBased events. DurationBased event notifications specify an amount of time for which the corresponding event lasted; pricing of these event notifications is based on this duration. UnitContentBased event notifications specify the number of units contents that were used in the corresponding event; these event notifications are priced on the basis of this number. Session and PricedEvent objects Session objects 6005 are created by the Session Pricing and Logging System 1 000 and are filled with details from the session start, event and session end notifications. Each Session object 6005 contains the following attributes: sessionNo a session number that is unique for the account to which the session is to be charged; this is generated by the corresponding Account object held in the Account Management system when the session start notification is received. sessionld a unique session Id, unique to the service provider and service; this is taken from the sessionld of the session start notification (and is also identical to the sessionld of all other notifications that belong to the same session) serviceld the serviceld taken from the session start notification (and is also identical to the sessionld of all other notifications that belong to the same session); this must also be the serviceld for the service that this Session Pricing and Logging System is dedicated to startTime the timestamp of the session start notification endTime the timestamp of the session end notification pricedEvents a set of PricedEvent objects 6010, constructed from the event notifications that belong to the session PricedEvent objects 6010 are created by the Session Pricing and Logging System 1000 and are filled with details from an event notification. PricedEvent objects 6010 contain the following attributes: timestamp the timestamp of the event eventDetails the event details of the event notification price the price that applied to the event; this price is calculated, and added, by the Session Pricing and Logging System Note that the sessionNo, sessionld and serviceld of the eventNotification are not used in the PricedEvent object 6010, as this information is already mapped into the Session object 6005, with which the PricedEvent is associated. Before a PricedEvent object is created, the Session Pricing and Logging System 1000 needs to ensure that it matches a Session object. Pricing policies The pricingPolicies attribute of the Session Pricing and Logging System 1000 contains a PricingPolicies object 1010, which is a set of PricingPolicy objects. These PricingPolicy objects define the prices that apply to PricedEvents generated for the service to which the system is dedicated. The eventDetails attribute of the PricedEvent object 601 0 forms the basis for price calculation. The value of this attribute may be of one of a number of classes (e.g. in P6 these eventDetails can be of class DurationBasedEvent or UnitContentBasedEvent) . For each class that the attribute may exhibit, there will be one PricingPolicy object 1 010 in the pricingPolicies. Referring to Figure 7, ideally, it should be possible to define the classes that may be used in the eventDetails of an event notification as an attribute (eventDetailsC/asses) of each Service object 1 105 in the Service Management System 101 5. Each service may then have a number of such classes, potentially distinct. The Service Management System 101 5 must then ensure that services are activated only if its eventDetailsClasses 7000 contains a set of class names, and one pricing policy 7005 is defined for each of these classes. If the eventdetailsClasses attribute is not used, it is possible to assume that all services use the DurationBasedEvent and UnitContentBasedEvent classes only. A PricingPolicies object 1020 can be invoked to supply a reference to the PricingPolicy that applies to a given class of eventDetails. This PricingPolicy can then be invoked to perform the method setPricelnEvent: aPricedEvent, which ensures that the PricingPolicy calculates the applicable price for the PricedEvent, and places that price in attribute price of the PricedEvent. PricingPolicies objects 1020 can also be defined to contain a number of timed PricingPolicy objects; each to apply for a period of time that is specified with the object. This would allow special offers to be available over certain time periods (like the weekend or Christmas), or simply different pricing to be available for different parts of the day. The correct design of timed pricing policies needs to involve checks that there exist pricing policies that cover all future times (until the service is ceased), and that no two pricing policies apply at the same time for the same class of eventDetails. Management of timed pricing policies must be kept simple, so that business operations managers can easily change the policies, and so that they can be marketed appropriately. Pricing policies that have applied in the past should preferably be kept by the system, and not be changed. This allows for accounting to be done appropriately. P6 Pricing Policies P6 implements pricing policies which consist of a number of segments. Each segment defines the price of the PricedEvent objects 6010 whose eventDetails value falls within the range specified by the segment. A PricingPolicy object 1010, 1020 in P6 has two attributes: eventType the name of the class of eventDetails that is handled by this pricing policy segments the set of Segment objects, which define the price of a PricedEvent object for a given interval of values of the eventDetails attribute of the PricedEvent. Referring to Figure 8, consider e.g. a pricing policy for PricedEvents with eventDetails of class durationBasedEvent. The value of the eventDetails attribute in these PricedEvents indicate a length of time during which a customer used a service. Figure 8 illustrates the pricing policy. The value of eventDetails is mapped horizontally (in seconds), the price (in pence)vertically. It shows that event notifications for a service usage between 0 and 5 sees attracts a standard price of 5 pence. A usage of 21 minutes costs 9 pence. Each interval in the graph (0-5, 5-1 3, 1 3-21 , 24 - infinity) is mapped in a PricingPolicySegment object. A PricingPolicySegment object in prototype P6 has three attributes: startPoint the start point of the range of the segment; (the end point is set by the start point of the next segment, and need not be specified in this segment) initialPrice the price that applies at the startPoint rate the rate applicable within the interval specified by the segment. The price that applies to a PricedEvent is found by first finding the PricingPolicy object 1010, 1020 that applies to the PricedEvent, and then the PricingPolicySegment that covers the value of eventDetails of the PricedEvent. The price is then: initialPrice + (( value - startPoint) * rate). INTERFACES PROVIDED BY THE SYSTEM Management of Session Pricing and Logging Systems Session Pricing and Logging Systems 1000 are created by the Service Management System 101 5 when a Service is activated. When it is created, the system is immediately supplied with a uniqe id, the serviceld for the service that it supports, a reference to the Account Management System 1040 that it has to transfer completed Session objects to, and a copy of the pricing policies 1010 for the service. Interfaces to the Service Providers The Session Pricing and Logging System 1 000 accepts session information 6000 from service providers, and stores this in Session and PricedEvent objects 6010. It calculates the price applicable to each PricedEvent object 601 0, and inserts this in the object. It transfers Session objects 6005, once they are complete, to the Account Management System 1040. Referring to Figures 9, 10, 1 1 and 1 2, the following three subsections describe the actions of the Session Pricing and Logging System 1000 upon receiving a session start notification, an event notification and a session end notification. Logging A Session Start Notification 1 . To log a session start notification the service provider invokes the Session Pricing and Logging System 1000 to perform logSessionStart: sessionStartNotification. 2. The Session Pricing and Logging System 1000 performs the invoked logSessionStart: sessionStart-Notification method, by: a. invoking the AccountManagement System 1040 to provide a unique session number (by invoking method getUniqueSessionNo) for the account specified in sessionStartNotification; b. creating a Session object 6005 with this unique session number, and the contents of the sessionStartNotification; c. adding this Session object 6005 to the attribute sessionslnProgress 6015 d. invoking the AccountManagement System 1040 to perform setSessionOpen: newSession sessionNo withld: newSession sessionld withPricingSystem: sessionPricingAndLoggingSystemld for Account: newSession accountld, which ensures that the Account Management System sets an attribute in the Account object 1070 to which the current session will be charged, indicating that a session is open for that Account. Pricing And Logging An Event Notification 1 . To log an event notification the service provider invokes the Session Pricing and Logging System 1000 to perform priceAndLogEvent: even tNo tifica tion . 2. The Session Pricing and Logging System performs the invoked method priceAndLogEvent: eventNotification, by: a. creating a PricedEvent object 6010 pricedEvent which includes the timestamp and eventDetails from eventNotification. b. using the eventType of the eventNotification to find in the pricingPolicies 1010 the pricing policy that applies to the pricedEvent (if there is no appropriate policy, it notifies the Service Management System 101 5 and aborts the event logging). c. invoking the selected PricingPolicy object 1010 to perform setPricelnEvent: pricedEvent, which ensures that the correct price applicable to the event is calculated and inserted in pricedEvent. d. invoking the Session object 6005 with the sessionld specified in the eventNotification to perform addEvent: pricedEvent, which stores the pricedEvent 6010 against the appropriate Session object 6005. Logging A Session End Notification 1 . To log a session end notification the service provider invokes the Session Pricing and Logging System 1000 to perform logSessionEnd: sessionEndNotification. 2. The Session Pricing and Logging System performs the invoked method logSessionEnd: sessionEnd-Notification , in which it: a. invokes the Session object session 6005 identified by the sessionld specified in the sessionEnd-Notification to set its endTime to the value of timestamp from the sessionEndNotification. b. invokes the AccountManagement System 1040 to perform logSession: session, which ensures that the Account Management System adds the Session object 6005 to the Account object 1070, and removes the link from that Account to the Session object in the Session Management system 1 200 of the Service Pricing and Logging System 1000. c. removes the Session object 6005 from the Session Pricing and Logging System 1000 Interfaces to the Service Management System The Service Management System 101 5 contains the Service object 1 105 that represents the service to which the Session pricing and Logging System 1000 is dedicated. With this Service object 1 105 it holds the master of the PricingPolicies object 1 020 for the service. When an authorized business manager changes the pricing policies for the service, the Service object 1 1 05 ensures that any existing Session Pricing and Logging Systems 1000 for that service are updated with a copy of the new pricing policies 1020. THE CHARGING AND BILLING SYSTEM 1045 Referring to Figure 14, the Charging & Billing system 1045 is responsible for the creation and presentation of bills, which charge customers for their usage of services. It creates Bill objects 1075, which hold the details of bills, and passes these onto the Account Management system 1040 for storage against appropriate accounts. It holds the charging policies 1060, which define how the session objects 1085 are charged for on bills. It provides an interface 1400 for business operations managers to view and change these charging policies. It provides a bill presentation interface, which displays existing Bill objects. Figure 1 3 shows the Charging and Billing system 1045 and the relevant entity objects of the Account Management 1040, Customer Management 1035 and Service Management 101 5 systems. Attributes Of The System The Charging and Billing System 1045 works closely with an Account Management system 1040. The Charging and Billing system 1045 has an attribute accountManagement which contains a reference to the Account Management System that it works with. The Charging and Billing System contains the chargingPo/icies attribute, which represents the charging policies 1060 that are used in bill production. These policies define how Session objects 501 5 and their associated PricedEvent objects 5030 are charged for on bills, i.e. how the prices of the PricedEvent objects are translated into actual charges that occur on the bill. A bill contains details of the prices of services used by a customer on a session-by-session basis. A charging policy 1060 is able to apply a modification to the prices of sessions to provide a means of discounting certain services for a customer. A basic charging policy typically applies a discount (percentage) to the prices of sessions belonging to a range of services. The discount value and the services to which it applies are configurable. Charging policies 1060 All charging policies 1060 have a name and a charging option. A customer's account includes a set of charging options which are used to select the appropriate charging policies to calculate the charges for a bill during bill production. Basic Charging policy This basic type of charging policy 1060 is abstract and although it has the ability to calculate the charge modification for a session it is the responsibility for specific policies derived from this policy to define the actual charging algorithms. Derived policies redefine the method chargeModificationForSession: aSession to incorporate their own charging algorithms. The basic charging policy has the following attributes: chargingPolicyld The unique reference number of the charging policy. name The name of the charging policy. chargingOption The charging option of the charging policy. servicelds The IDs of the services for which the charging policy is applicable. P6 Charging policies Referring to Figure 14, the P6 charging policies 1060 are all derived from the basic pricing policy ChargingPolicy as shown. P6 Charging policy - Affinity Promotion (ChargingPolicyl97AffinityPromotion 1440) This is a charging policy where the sufficient usage of certain services results in discounting of certain related services. Affinity Services is a group of services which, when used sufficiently, will result in the discounting of prices for the use of services in another group of services know as Discounted Services. "Threshold" is the value which the total session prices for services in Affinity Services must reach to invoke the discounting of prices for services in Discounted Services. Discount is the discount (percentage reduction) applied to the price of each session which belongs to a Discounted Service to obtain a charge modification. It has the following attributes: affinityServicelds The IDs of services which when used sufficiently will result in the discounting of prices for services with IDs in discountedServicelds discountedService/dsJhe IDs of discountable services. discount The discount (percentage reduction) applied to the price of each session which belongs to a service with and ID in discountedServicelds to obtain the charge modification for the session. threshold The value for which the total session prices for services with IDs in affinityServicelds must reach over the billing period to invoke the discounting of prices for services with IDs in discountedServicelds. P6 Charging policy - Optimal Duration (ChargingPolicyl970ptimalDuration 1445) Referring to Figure 1 5, this is a charging policy which discounts the price of usage of a service to favour sessions of a chosen duration. The class implements a two-part charging line which is parameterized to give a maximum (optimum) discount 1 500 to sessions of a given duration. For sessions of this duration the optimum discount is applied to the session price. Duration shorter or longer than the optimum duration 1 505 produce a reduced level of discount. It has the following attributes: optimalDuration The duration of a session (seconds) which produces the largest charge modification (using optima/Discount) . optima/Discount The percentage discount applied to the price to obtain the charge modification for the session. Part 1 of the characteristic has a discount starting at zero for a session duration of zero and ascends linearly to reach a discount of optimalDiscount 1 500 when the session duration reaches optimalDuration 1505. Part 2 of the characteristic has a discount starting at optimalDiscount 1 500 and descends reciprocally towards zero as the session duration approaches infinity. P6 Charging policy - Preferred Services (ChargingPolicyl97Pref erred Services 1450) A charging policy which rewards the use of preferred services by discounting the price of the usage of those services. The price for usage of services with IDs in preferredServicelds will be reduced by discount percent. It has the following attributes: preferredServicelds The preferred services IDs. discount The percentage discount applied to prices of sessions with service IDs in preferredServicelds The interfaces of the system Charging Policies Management Referring to Figures 1 3 and 1 6, the Charging and Billing System 1045 provides an interface 1400 which allows the Business Operations Managers (BOMs) to find, create and edit charging policies. This interface 1400 manages the charging policies Affinity Promotion, Optimal Duration and Preferred Services. Each charging policy 1060 has a corresponding charging policy editor 1 600 which is able to create and edit instances of it. Each editor implements a GUI to allow the user to manipulate charging policies as required. Each charging policy is directly or indirectly derived from an EntityManager 1 605. The Entity Manager 1 605 provides the high level object manipulation facilities such as finding, creating and editing. The derived editors 1 610, 1 61 5, 1 620 provide specific facilities for handling the attributes of the actual charging policy instances being managed. The production of a Bill object The Charging and Billing System 1045 provides an interface 1 300 which allows a bill initiation system to request the production of a bill for an account specified by an accountld. The bill initiation system may be a business operations manager. When invoked to create a bill, the Charging and Billing System 1045 creates a Bill object which contains all details of a new bill for the specified account. To create this bill, it asks the appropriate Account Management System 1 040 for details that are to be used on the bill. It uses the charging policies 1060 to calculate how the prices associated with service usage that is to be charged transform into actual charges to be included on the bill. When it has completed the production of the Bill object, it transfers this object 1 075 to the Account Management System 1040 for storage against the account. The system may then acknowledge the production of the Bill object and pass a reference for that object to the initiating system. The Bill object contains: the accountld a billld, which is unique for this account a billDate, which is the date that the bill was created details of the customer who has to pay the bill the address where the bill will be sent to the type of bill (electronic, fax, postal etc) the balance of the last bill the number and date of the last bill the billing period details of the payments received since the last bill details of all sessions for which the bill charges the charges for these sessions subtotals and totals • any information on discounts due to charging policies in use • the total new charges generated for this bill • the balance of the account Referring to Figures 1 7 to 20, a detailed description of the process of bill creation is given below. The Figures show the objects that take part in the bill creation, and the methods that they invoke on each other. In the Figures, a bold-headed arrow is drawn from an invoking object to an invoked object; the name of the invoked method is given alongside the arrow. Unnamed arrows with light heads are drawn where an object knows about another object. • Referring to Figures 1 7 and 1 8, to ensure a bill is produced the bill initiation system invokes the Charging and Billing System to perform createBillForAccount: accountld, providing it with the account id of the account for which a bill needs to be generated. • In response the Charging and Billing System 1045 performs this createBillForAccount: accountld method by creating a new Bill object 1800. • It then invokes the Account Management system 1 040 to perform supply A ccoun tDetailsForBHHng: an A ccoun tld. The Account Management system 1040 performs the invoked method by invoking the Account object 1070 identified by anAccountld to perform prepareForBilling, which ensures that the Account object locks itself, allowing no other bills to be produced for this Account while locked. The Account Management System 1040 moves the contents of the sessions and payments attributes of the Account object 1070 to the sessionsForNewBill and paymentsForNewBill attributes of that Account and then returns a new billld and the reference to the Account object identified by anAccountld. • The Charging & Billing System 1045 then accesses the Account object 1070 to find all information that it needs for populating the bill 1 800. The following bill attributes are set: accountld, billingAddress, startDate, endDate, billDate, settlementDate, oldBalance, newBalance. The prices of new sessions are added to the bill. The charges for the bill's sessions are calculated and added to the bill. New payments received are also added to the bill. The bill's new balance is calculated. The details of price, charge and payment calculation are covered in the next section. • Referring to Figure 1 9, the Charging & Billing System is responsible for calculating exactly what charges are to be included in the bill. It uses the ChargingPolicies object 1060 to determine how the session prices translate to charges on the bill. It populates the Bill with the appropriate charging information. • Referring to Figure 20, the Charging & Billing System transfers the Bill object 1 800 to the Account Management system for storage against the Account object 1070 for which it was created. The Account Management System 1040 logs the bill in the bills attribute of the Account object 1070 and moves the contents of sessionsForBill and paymentsForNewBill and unlocks the Account object 1070.

Claims: CLAIMS 1 . A distributable operational support system, triggerable by use of a communications service by a user to provide at least one of the group of functions comprising fault handling, billing, customer help, and service provisioning, wherein the operational support system comprises means to receive a trigger related to said use of a service, and at least one data processing module, wherein said means to receive a trigger comprises means to issue, on receipt of a trigger, an instruction to the data processing module to process a set of data in at least partial provision of the function in respect of said related use of a service, and wherein said data processing module comprises: i) a configurable data set for use in providing one of the group of functions for an identified user; ii) a set of rules for use in processing said set of data, with reference to said configurable data set; iii) an inter-module interface for communicating with other modules; and iv) a management interface for use in reconfiguring the configurable data set. 2. A system according to Claim 1 , comprising a set of software objects including at least said data processing module as a software object. 3. A system according to either one of the preceding claims wherein the inter-module and management interfaces are different parts of the same interface to the data processing module. 4. A system according to any one of the preceding claims, wherein the data processing module comprises at least one alternative rule for use in processing said set of data, and wherein one or both of the interfaces is adapted for input of a selection indicator to the data processing module such that the data processing module applies a selected rule from available alternative rules, in the set of rules, in processing said set of data. 5. A system according to any one of the preceding claims wherein the configurable data set is a partial data set, one or both of the interfaces being adapted for input of data to the data processing module such that the data processing module applies data which has been input via one or both of the interfaces in processing said set of data. 6. A system according to either one of claims 4 or 5, wherein one or both of the interfaces comprises an applications programming interface. 7. A system according to any one of the preceding claims, wherein the means to receive a trigger comprises means to receive an event notification from a communications network. 8. A system according to Claim 7 wherein the means to receive a trigger comprises means to receive session information from a communications network in respect of a communications session by a user of the network. 9. A system according to Claim 8 wherein the configurable data set comprises session parameters and the set of rules comprises at least one rule for processing session information in accordance with those parameters. 1 0. A system according to any one of the preceding claims, which further comprises a module for generating one or more data processing modules. 1 1 . System provision apparatus, for providing a distributable operational support system according to any one of the preceding claims, wherein the system provision apparatus comprises means to generate a plurality of data processing modules, wherein said means to generate the data processing modules comprises: i) a data processing module template, provided with the means to receive a trigger, the inter-module and management interface(s); ii) means for loading a configurable data set to the template; and iii) means for loading a set of rules to the template. 1 2. System provision apparatus according to claim 1 1 , further comprising means to output each data processing module for transmission to a respective, predetermined location in a communications network. 1 3. System provision apparatus according to Claim 1 2, wherein the respective, predetermined locations may be the same for at least two data processing modules output by the apparatus. 14. An operational support system for use in providing at least one service over a communications network, the support system having, in use, an interface for receiving usage data in respect of the service, an interface for receiving pricing data and an interface for receiving rules or schemes for modifying the use of received pricing data to enable the generation of bills based on usage data, wherein the support system comprises at least one service management system which provides the interface for receiving pricing data, and wherein said support system further comprises means to generate at least one session pricing and logging system for said at least one communications service, the session pricing and logging system providing the interface for receiving usage data from the network, having an input for receiving pricing data from the service management system and having an output for providing usage data associated with, or processed by, pricing data for use in said generation of bills. 1 5. A system according to Claim 14 wherein the support system comprises means to generate a session pricing and logging system associated with each communications service currently available over the network. 1 6. A system according to either one of Claims 14 and 1 5 wherein the service management system comprises an input for receiving service data, which service data may comprise a service cessation indicator, the service managment system being provided with means to close down the session pricing and logging system associated with the relevant service. 1 7. A system according to any one of Claims 1 4, 1 5 or 1 6 wherein the or each session pricing and logging system responds to receipt of usage data indicating a service session to create an information module which comprises the usage and pricing data, or the usage data processed by the pricing data, for use in the generation of bills, and further comprises a customer account indicator, the or each session pricing and logging system outputting the module on termination of the relevant service session. 1 8. A system according to Claim 1 7 which further comprises at least one customer account management system which receives and stores said modules. 1 9. A system according to Claim 1 8 which further comprises at least one charging and billing system which provides the interface for receiving rules or schemes for modifying the use of received pr.icing data, the charging and billing system further having an interface to the customer account management system to access said modules and to apply said rules or schemes to modify billing information in said modules prior to bill generation. 20. A system according to any one of claims 14 to 1 9 wherein the service management system has means to output received updates in the pricing data to the relevant session pricing and logging system or systems, such that all subsequent modules output by the system or systems will carry the updated pricing. 21 . A system according to Claim 1 9 wherein the at least one charging and billing system has means for receiving updates or changes to the rules or schemes such that subsequent bills will be generated acording to the updates or changes. 22. A system according to any one of claims 1 7 to 21 , constructed by use of object oriented technology, said pricing data being comprised as policies for loading with respect to session objects, said session objects being created by the session pricing and logging system(s) for output as said modules. 23. A system according to any one of claims 1 7 to 22, constructed by use of object oriented technology, said rules or schemes being comprised as charging policies for loading with respect to session objects, said session objects being created by the session pricing and logging system(s) for output as said modules, the charging policies being used together with the relevant session objects in the creation of bill objects for storage prior to bill generation. 24. An operational support system for use in providing at least one communications service, the system comprising a set of object-oriented modules, each module comprising data and at least one interface for accessing and modifying the data, the modules including: i) a service management system comprising service data together with pricing policies for the or each active service, and comprising an interface for modifying the service data; ii) a customer management system comprising customer specific data, and comprising an interface for modifying the customer data; and iii) means for generating a session pricing and logging system for at least one active service, the session pricing and logging system having an interface for receiving session information about service usage by a customer of that active service, an interface for receiving at least one pricing policy from the service management system, means for associating a pricing policy with session information and means for outputting the session information and associated pricing policy to the customer management system. 25. A system according to claim 24 wherein the session pricing and logging system processes the session information by applying the relevant pricing policy to create a session object and it is the session object which carries the session information and associated pricing policy to the customer management system.

Inventors: FREESTONE DAVID, HORNE ALAN DENNIS, ONION PETER JOHN, WEZEMAN CLAZIEN DIEUDONNEE, FREESTONE, DAVID, HORNE, ALAN, DENNIS, ONION, PETER, JOHN, WEZEMAN, CLAZIEN, DIEUDONNEE
Applicants: BRITISH TELECOMM, FREESTONE DAVID, HORNE ALAN DENNIS, ONION PETER JOHN, WEZEMAN CLAZIEN DIEUDONNEE, BRITISH TELECOMMUNICATIONS PUBLIC LIMITED COMPANY, FREESTONE, DAVID, HORNE, ALAN, DENNIS, ONION, PETER, JOHN, WEZEMAN, CLAZIEN, DIEUDONNEE
Application year: 1998
Main classification: H04Q3
IPC codes: H04M15, H04Q3