[go: up one dir, main page]

WO1998033334A1 - Systeme d'aide a l'exploitation des communications - Google Patents

Systeme d'aide a l'exploitation des communications Download PDF

Info

Publication number
WO1998033334A1
WO1998033334A1 PCT/GB1998/000227 GB9800227W WO9833334A1 WO 1998033334 A1 WO1998033334 A1 WO 1998033334A1 GB 9800227 W GB9800227 W GB 9800227W WO 9833334 A1 WO9833334 A1 WO 9833334A1
Authority
WO
WIPO (PCT)
Prior art keywords
session
service
data
pricing
interface
Prior art date
Application number
PCT/GB1998/000227
Other languages
English (en)
Inventor
David Freestone
Alan Dennis Horne
Peter John Onion
Clazien Dieudonnee Wezeman
Original Assignee
British Telecommunications Public Limited Company
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by British Telecommunications Public Limited Company filed Critical British Telecommunications Public Limited Company
Priority to AU57724/98A priority Critical patent/AU5772498A/en
Priority to EP98901386A priority patent/EP0954931A1/fr
Publication of WO1998033334A1 publication Critical patent/WO1998033334A1/fr

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04Q—SELECTING
    • H04Q3/00—Selecting arrangements
    • H04Q3/0016—Arrangements providing connection between exchanges
    • H04Q3/0062—Provisions for network management
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04M—TELEPHONIC COMMUNICATION
    • H04M15/00—Arrangements for metering, time-control or time indication ; Metering, charging or billing arrangements for voice wireline or wireless communications, e.g. VoIP
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04Q—SELECTING
    • H04Q2213/00—Indexing scheme relating to selecting arrangements in general and for multiplex systems
    • H04Q2213/1305—Software aspects
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04Q—SELECTING
    • H04Q2213/00—Indexing scheme relating to selecting arrangements in general and for multiplex systems
    • H04Q2213/1313—Metering, billing
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04Q—SELECTING
    • H04Q2213/00—Indexing scheme relating to selecting arrangements in general and for multiplex systems
    • H04Q2213/13503—Indexing scheme relating to selecting arrangements in general and for multiplex systems object-oriented systems
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04Q—SELECTING
    • H04Q2213/00—Indexing scheme relating to selecting arrangements in general and for multiplex systems
    • H04Q2213/13524—Indexing scheme relating to selecting arrangements in general and for multiplex systems cost management

Definitions

  • the present invention relates to operational support systems for communications networks.
  • OSS operational support system
  • large strategic systems for volume core services and quick tactical solutions for high speed low volume services such as online information services.
  • 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.
  • 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.
  • 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
  • the operational support system comprises means to receive a trigger related to said use of a service, and at least one data processing module
  • 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
  • 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.
  • a business object in the sense of Object Technology
  • the business objects interact with each other and with the information services they are supporting.
  • interface 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")
  • the interfaces need to be APIs (application programmable interfaces)
  • Notion of standardised APIs is new for OSS functionality and it offers several benefits.
  • standardised APIs allow information services from multiple service providers to be packaged together via common interfaces.
  • 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.
  • 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.
  • 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:
  • 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;
  • a customer management system which contains data about customers and includes interfaces for adding new customer data and viewing and changing customer data;
  • 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.
  • 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.
  • 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.
  • 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.
  • policies can be pre-loaded which can still accept inputs at run-time or compile-time.
  • 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.
  • 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
  • the aim with policies is to provide enough options (suitably parametrised) to cater for a wide range of information services.
  • 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.
  • 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
  • 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
  • Figure 21 shows a hardware environment for the OSS of Figure 1
  • 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.
  • 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.
  • 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.
  • 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.
  • DPE distributed processing environment
  • 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.
  • Telecommunications Management Network Telecommunications Management Network
  • I Intelligent Network
  • the logical framework architecture defines concepts and principles for the design of object-oriented software that operates in a distributed environment.
  • 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.
  • DPE distributed processing environment
  • 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.
  • APIs Application Programming Interfaces
  • 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
  • CPE customer premises equipment
  • 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 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.
  • 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.
  • 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.
  • 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.
  • 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 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 .
  • 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 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 requirements model consists of the general system description.
  • the analysis model consists of the object diagrams and object descriptions.
  • 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:
  • 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.
  • a Customer Management System 1035 which contains data 1095 about customers, and includes interfaces for adding new customers and viewing and changing customer data.
  • 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.
  • 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.
  • 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.
  • BOMs business operations managers
  • 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
  • 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.
  • an OSS 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.
  • Fat arrows with bold arrowheads show which systems invoke methods on other systems.
  • the people shown represent business operations managers and customer handling personnel.
  • 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.
  • 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.
  • a new Service object 1 1 05 is created, its status attribute is set to inactive.
  • 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.
  • the Service Management System 101 5 provides interfaces which allow for the following:
  • 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.
  • 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.
  • the Service Management System 1 01 5 provides an interface for this.
  • the system 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).
  • a Customer Management System 1035 holds the details of customers known to the OSS.
  • 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.
  • 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.
  • 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”.
  • the Customer Management system 1035 provides interfaces which allow the following:
  • 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.
  • 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.
  • 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).
  • 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.
  • 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.
  • Session Pricing and Logging System 1000 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.
  • 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.
  • a bill may charge for zero or more Session objects 1085 and acknowledge zero or more payments.
  • a Charging and Billing System 1045 wishes to create a bill, it will first notify the Account Management System 1040, which will in
  • Bill object 1075 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.
  • 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.
  • 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;
  • 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:
  • 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:
  • Priced Event objects 5030 that represent the event notifications that form part of the session.
  • 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 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.
  • 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.
  • a Service Management System 101 5 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.
  • Session Pricing and Logging System 1 000 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
  • 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.
  • 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
  • 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.
  • the service providers supply the Session Pricing and Logging system 1000 with session information 6000 concerning the usage of the service by customers.
  • session information 6000 concerning the usage of the service by customers.
  • a session start notification 1. 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';
  • 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.
  • 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.
  • 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.
  • 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 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:
  • 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.
  • the Session Pricing and Logging System 1000 needs to ensure that it matches a Session object.
  • 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) .
  • 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.
  • 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.
  • 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.
  • FIG 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.
  • 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).
  • 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.
  • 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.
  • the Session Pricing and Logging System 1000 performs the invoked logSessionStart: sessionStart-Notification method, by:
  • the Session Pricing and Logging System performs the invoked method priceAndLogEvent: eventNotification, by:
  • 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
  • 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
  • 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.
  • 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.
  • 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.
  • 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.
  • the P6 charging policies 1060 are all derived from the basic pricing policy ChargingPolicy as shown.
  • P6 Charging policy - Affinity Promotion (ChargingPolicyl97AffinityPromotion 1440)
  • 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.
  • affinityServicelds The IDs of services which when used sufficiently will result in the discounting of prices for services with
  • Discounted (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.
  • 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.
  • 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.
  • 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.
  • 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 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.
  • the Charging and Billing System 1045 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
  • FIG. 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer And Data Communications (AREA)

Abstract

L'invention concerne un système d'aide à l'exploitation (OSS) de communications construit à partir d'un ensemble de modules logiciels orientés objets, répartis de manière à être proches de l'endroit où sont produites les données. L'OSS, qui est configurable, comporte des interfaces normalisées, et peut être conçu pour traiter tous les aspects relatifs à l'aide à l'exploitation d'un service de communications, tels que le traitement d'erreurs, la prise en compte des commandes, et la tarification session. Au cours de l'utilisation de l'OSS, pour la tarification et la consignation session notamment, les données relatives à une session ayant fait l'objet d'une tarification sont encapsulées dans un objet puis transférées vers un système de gestion clients. L'OSS est configuré selon différentes politiques. Celles-ci peuvent être préchargées tout en pouvant encore recevoir des données pendant l'exécution, ce qui rend l'OSS particulièrement flexible. L'utilisation d'un parseur permet en outre de modifier les politiques existantes pendant qu'une interface API permet d'ajouter de nouvelles politiques.
PCT/GB1998/000227 1997-01-27 1998-01-27 Systeme d'aide a l'exploitation des communications WO1998033334A1 (fr)

Priority Applications (2)

Application Number Priority Date Filing Date Title
AU57724/98A AU5772498A (en) 1997-01-28 1998-01-27 Operational support system for communications
EP98901386A EP0954931A1 (fr) 1997-01-27 1998-01-27 Systeme d'aide a l'exploitation des communications

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
EP97300500.2 1997-01-27
GB9701677.8 1997-01-28
GBGB9701677.8A GB9701677D0 (en) 1997-01-28 1997-01-28 Operational support system for communications

Publications (1)

Publication Number Publication Date
WO1998033334A1 true WO1998033334A1 (fr) 1998-07-30

Family

ID=10806670

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/GB1998/000227 WO1998033334A1 (fr) 1997-01-27 1998-01-27 Systeme d'aide a l'exploitation des communications

Country Status (3)

Country Link
AU (1) AU5772498A (fr)
GB (1) GB9701677D0 (fr)
WO (1) WO1998033334A1 (fr)

Cited By (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2003061199A1 (fr) * 2002-01-15 2003-07-24 Nextlimit Ab Identification d'objets de distribution
EP1517531A1 (fr) * 2003-09-18 2005-03-23 Swisscom Mobile AG Dispositif et procédé pour la compensation de coût de communication
US7602521B2 (en) * 2006-01-31 2009-10-13 Pitney Bowes Inc. Document format and print stream modification for fabricating mailpieces
US20110320578A1 (en) * 2010-06-29 2011-12-29 Alcatel-Lucent Canada Inc. Operations support system with modular architecture
CN117062020A (zh) * 2023-08-31 2023-11-14 中移互联网有限公司 能力调用话单的批价方法、装置及电子设备

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN111612555A (zh) * 2019-02-22 2020-09-01 卓望数码技术（深圳）有限公司 一种基于移动体系的产商品配置系统

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US4782517A (en) * 1986-09-08 1988-11-01 Bell Communications Research, Inc. System and method for defining and providing telephone network services
EP0452591A2 (fr) * 1990-04-16 1991-10-23 AT&T Corp. Méthode et appareil pour la facturation d'appels de communication valorisés
WO1995027255A1 (fr) * 1994-03-30 1995-10-12 British Telecommunications Public Limited Company Systeme de traitement de donnees utilise dans des installations destinees a etablir le prix des communications et a taxer celles-ci et son procede de production
WO1996008102A1 (fr) * 1994-09-07 1996-03-14 British Telecommunications Public Limited Company Structure support fonctionnelle d'un reseau de telecommunications

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US4782517A (en) * 1986-09-08 1988-11-01 Bell Communications Research, Inc. System and method for defining and providing telephone network services
EP0452591A2 (fr) * 1990-04-16 1991-10-23 AT&T Corp. Méthode et appareil pour la facturation d'appels de communication valorisés
WO1995027255A1 (fr) * 1994-03-30 1995-10-12 British Telecommunications Public Limited Company Systeme de traitement de donnees utilise dans des installations destinees a etablir le prix des communications et a taxer celles-ci et son procede de production
WO1996008102A1 (fr) * 1994-09-07 1996-03-14 British Telecommunications Public Limited Company Structure support fonctionnelle d'un reseau de telecommunications

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
CROOKES, JIM: "MULTISERVICE BILLING SYSTEM - A PLATFORM FOR THE FUTURE", BT TECHNOLOGY JOURNAL, vol. 15, no. 1, January 1997 (1997-01-01), IPSWICH, GB, pages 98 - 113, XP000688213 *
LOEB S ET AL: "USAGE INFORMATION COLLECTION AND MANAGEMENT PARADIGM FOR BROADBAND AND MULTIMEDIA SERVICES: ARCHITECTURAL EVOLUTION", ISS '95. INTERNATIONAL SWITCHING SYMPOSIUM, vol. 2, 23 April 1995 (1995-04-23), BERLIN, DE, pages 366 - 370, XP000495684 *

Cited By (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2003061199A1 (fr) * 2002-01-15 2003-07-24 Nextlimit Ab Identification d'objets de distribution
EP1517531A1 (fr) * 2003-09-18 2005-03-23 Swisscom Mobile AG Dispositif et procédé pour la compensation de coût de communication
US7602521B2 (en) * 2006-01-31 2009-10-13 Pitney Bowes Inc. Document format and print stream modification for fabricating mailpieces
US20110320578A1 (en) * 2010-06-29 2011-12-29 Alcatel-Lucent Canada Inc. Operations support system with modular architecture
CN117062020A (zh) * 2023-08-31 2023-11-14 中移互联网有限公司 能力调用话单的批价方法、装置及电子设备

Also Published As

Publication number Publication date
GB9701677D0 (en) 1997-03-19
AU5772498A (en) 1998-08-18

Similar Documents

Publication Publication Date Title
EP0808545B1 (fr) Fourniture et gestion de services d'informations
Raymond Reference model of open distributed processing (RM-ODP): Introduction
Bultan et al. Conversation specification: a new approach to design and analysis of e-service composition
CA2376249C (fr) Systeme de gestion de donnees
KR19990067327A (ko) 통신 네트워크용 서비스 창조 장치
EP0756804A1 (fr) Dispositif de creation de services pour un reseau de communications
Katzan Jr Cloud software service: concepts, technology, economics
EP1252594A2 (fr) Programmation et planification anticipee, et gestion proactive au cours de la maintenance et de l'entretien d'un environnement du type chaine d'approvisionnement reseautee
WO2001039029A2 (fr) Planification en collaboration des capacites et gestion anticipee des stocks lors de la planification de l'offre et de la demande dans un environnement de chaine d'approvisionnement fondee sur le reseau et procede associe
WO2001039086A2 (fr) Partage technologique lors de la gestion et du suivi du parc informatique dans un environnement du type chaine d'approvisionnement reseautee, et procede associe
WO1998033334A1 (fr) Systeme d'aide a l'exploitation des communications
CN103229485A (zh) 业务能力共享的实现方法和平台
EP0954931A1 (fr) Systeme d'aide a l'exploitation des communications
EP1275052A2 (fr) Gestion d'actifs durant le cycle de vie et en reseau dans un environnement de commerce electronique et procede associe
Lang et al. Distributed open simulation model development with DSOL services
Thimm et al. A mail-based teleservice architecture for archiving and retrieving dynamically composable multimedia documents
Hellemans et al. Accounting management in a TINA-based service and network environment
AU764851B2 (en) Information services provision and management
Farooqui et al. Architecture for Open Distributed Software Systems
Deliverable Overall Concepts and Principles of TINA
Bagley et al. The Information Services Supermarket-a trial TINA-C Design
WO1998052321A1 (fr) Systeme et procede ameliores de telecommunication
Redmond et al. Service level accounting in telecommunications
WO2002046977A2 (fr) Procedes de gestion commerciale bases sur la connaissance, et systemes de mise en oeuvre correspondants
Freestone et al. Operational support systems for the future

Legal Events

Date Code Title Description
WWE Wipo information: entry into national phase

Ref document number: 09102000

Country of ref document: US

AK Designated states

Kind code of ref document: A1

Designated state(s): AL AM AT AU AZ BA BB BG BR BY CA CH CN CU CZ DE DK EE ES FI GB GE GH GM GW HU ID IL IS JP KE KG KP KR KZ LC LK LR LS LT LU LV MD MG MK MN MW MX NO NZ PL PT RO RU SD SE SG SI SK SL TJ TM TR TT UA UG US UZ VN YU ZW

AL Designated countries for regional patents

Kind code of ref document: A1

Designated state(s): GH GM KE LS MW SD SZ UG ZW AM AZ BY KG KZ MD RU TJ TM AT BE CH DE DK ES FI FR GB GR IE IT LU MC NL PT SE BF BJ CF CG CI CM GA GN ML MR NE SN TD TG

DFPE Request for preliminary examination filed prior to expiration of 19th month from priority date (pct application filed before 20040101)
121 Ep: the epo has been informed by wipo that ep was designated in this application
WWE Wipo information: entry into national phase

Ref document number: 1998901386

Country of ref document: EP

WWP Wipo information: published in national office

Ref document number: 1998901386

Country of ref document: EP

REG Reference to national code

Ref country code: DE

Ref legal event code: 8642

WWW Wipo information: withdrawn in national office

Ref document number: 1998901386

Country of ref document: EP