[go: up one dir, main page]
More Web Proxy on the site http://driver.im/

EP1139243A1 - Système de facturation et de gestion de clients - Google Patents

Système de facturation et de gestion de clients Download PDF

Info

Publication number
EP1139243A1
EP1139243A1 EP00106948A EP00106948A EP1139243A1 EP 1139243 A1 EP1139243 A1 EP 1139243A1 EP 00106948 A EP00106948 A EP 00106948A EP 00106948 A EP00106948 A EP 00106948A EP 1139243 A1 EP1139243 A1 EP 1139243A1
Authority
EP
European Patent Office
Prior art keywords
billing
customer management
application
management system
classes
Prior art date
Legal status (The legal status 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 status listed.)
Withdrawn
Application number
EP00106948A
Other languages
German (de)
English (en)
Inventor
Jochen Kappel
Josef Markgraf
Michael Meadows
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
LHS Group Inc
Original Assignee
LHS Group Inc
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by LHS Group Inc filed Critical LHS Group Inc
Priority to EP00106948A priority Critical patent/EP1139243A1/fr
Priority to US09/819,446 priority patent/US20020087341A1/en
Priority to PCT/IB2001/000575 priority patent/WO2001073625A1/fr
Priority to AU44455/01A priority patent/AU4445501A/en
Priority to EP01923007A priority patent/EP1307814A4/fr
Priority to AU2001249747A priority patent/AU2001249747A1/en
Priority to AU2001249748A priority patent/AU2001249748A1/en
Priority to EP01923008A priority patent/EP1314096A4/fr
Priority to AU2001249746A priority patent/AU2001249746A1/en
Priority to US09/823,866 priority patent/US20020052979A1/en
Priority to US09/823,892 priority patent/US7082609B2/en
Priority to EP01923006A priority patent/EP1328863A4/fr
Priority to PCT/US2001/010535 priority patent/WO2001075630A1/fr
Priority to US09/823,894 priority patent/US20020049864A1/en
Priority to PCT/US2001/010534 priority patent/WO2001075550A2/fr
Priority to PCT/US2001/010533 priority patent/WO2001075584A1/fr
Priority to US09/825,438 priority patent/US20020059332A1/en
Priority to US09/825,151 priority patent/US7086084B2/en
Priority to US09/825,298 priority patent/US7086066B2/en
Publication of EP1139243A1 publication Critical patent/EP1139243A1/fr
Withdrawn legal-status Critical Current

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/48—Program initiating; Program switching, e.g. by interrupt
    • G06F9/4806—Task transfer initiation or dispatching
    • G06F9/4812—Task transfer initiation or dispatching by interrupt, e.g. masked
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q10/00—Administration; Management
    • G06Q10/10—Office automation; Time management
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q30/00—Commerce
    • G06Q30/04—Billing or invoicing
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2221/00—Indexing scheme relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F2221/21—Indexing scheme relating to G06F21/00 and subgroups addressing additional information or applications relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F2221/2141—Access rights, e.g. capability lists, access control lists, access tables, access matrices
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities

Definitions

  • the present invention relates to a billing and customer management system, especially for communication services, according to the preamble of the claim 1.
  • Billing and customer management systems are used in all companies, who offer goods or services where the level of consumption of the Goods or the length of use of the services are the main criteria for the amount of the price to be paid by the end consumer. These companies also usually have a very large number of customers (cf. Electricity, gas and water supply, telecommunications), which is an enormous Administrative effort entails. Billing and customer management systems usually enable such companies to easily manage the enormous Amount of customer data, calculate the according to appropriate presettings costs to be billed and are usually also for the invoicing as such responsible.
  • a central one Database used, in particular for storing all application data serves.
  • this is usually designed and provided as a relational database thus also represents the main server of the system.
  • the user Via clients, and in particular Via GUIs (Graphic User Interfaces), the user receives certain services of customer administration and accounting.
  • You can additional application servers connected between the clients and the database his. Every client or application server is with the central database connected, from which all data required for the application are queried and changed can be.
  • the system 14 has a central, relational database 17 that operates simultaneously forms the main server of the system 14 and with a plurality of modules 3 a network is connected.
  • the modules 3 can either be used as clients or be designed and offer as an application server with attached clients the respective user via GUIs or programming interfaces Predefined services from the accounting or customer administration area to claim something.
  • the necessary data records are in tables the central database 17 is stored and retrieved from there.
  • MSC Mobile Switching Center
  • call data such as origin, destination, duration and service of mobile phone calls.
  • the information is in the billing and customer management system 14 read and processed there by suitable accounting modules 20, which calculate the call charges (rating).
  • the data required for this will be retrieved from the central database 17, and after the billing process the newly determined data are stored again in the database 17.
  • This data can in turn be called up by an invoice generation module 22 with which the provider can create customer invoices (Billing).
  • Customer management as such (Customer Care) is also based on several modules, each used for different services, carried out.
  • a module 24 can provide information about free Resources to SIM card seller 34 are forwarded.
  • a provider module 26 for processing money transactions with banks and credit card companies 36 and modules 28 for the transmission of data to a Subscriber register (HLR: Home Location Register) 30 of the mobile radio network in which Data from participants are saved.
  • HLR Home Location Register
  • All modules 3 are directly connected to the central database 17 and can be connected to one another but do not communicate via direct interfaces.
  • the interfaces between the modules 3 are usually not explicitly defined at all. Instead, the central database 17 serves as a large implicit interface between all different modules 3, creating a multitude of unnecessary internal Sub-dependencies is caused.
  • the interface is therefore a Set of database tables shown.
  • the database 17 also mostly used as a server for the business logic in Configuring the various modules 3 is used in addition to data storage additionally as an interface to external systems and for communication between the modules 3.
  • the present invention is therefore based on the object of providing a billing and customer management system, in particular for communication services create changes or additions to the system due to changes System user wishes as quickly as possible with as little programming effort as possible can be carried out.
  • the system has a distributed component architecture in which components are designed in accordance with the services offered, that can communicate directly with each other via interfaces becomes flexible Configuration of business logic allows, so that customer needs with a Minimum implementation changes can be met.
  • the system can be extremely flexible and easy to increase the number of adapt the data to be processed.
  • the system is advantageously arranged in at least two hierarchically Layers divided with increasing degree of abstraction. Every layer isolates the layer above it downwards so that the layer above it Layer implementation details of the layers below remain hidden.
  • the system is divided into a base layer (Base Layer), general layer, technical support layer (Technical Services Layer), Application Layer (Application Layer) and Business Layer (Business layer).
  • the system in at least two hierarchically arranged levels (tiers) according to the technical tasks is divided. Processes can operate simultaneously in different logical levels and run independently of each other; is also an even finer division possible in physical levels.
  • tiers levels
  • Processes can operate simultaneously in different logical levels and run independently of each other; is also an even finer division possible in physical levels.
  • the billing and customer management system is the system divided into presentation level, application level (Application Tier), Meta-Application Tier (Domain Tier) (Domain tier), Persistence tier (Persistence tier) and Database level (Database Animal).
  • An application is created via the meta-application level means advantageously provided within the system to to describe yourself. This allows a dynamic (i.e. feasible at runtime) Configuration of the behavior of the individual components.
  • the system particularly advantageously has a meta-application dictionary (meta-application Dictionary) on, reducing the programming effort for changes Server side can be kept very low.
  • meta-application dictionary metal-application Dictionary
  • the system has devices that Provide interface model of the server on the client side and so that the communication technology used is hidden from a client developer.
  • the system advantageously offers defined interfaces and mechanisms for Request distribution, so that several similar application servers to the system can be added, reducing the possible number of to be processed Data can be increased almost arbitrarily with little effort, without the processing speed to affect.
  • the system advantageously offers the possibility of exchanging components or add so that the system is not out of date and simple may offer other or additional services without complete System needs to be replaced or profound code changes made Need to become.
  • the creation of upgrades is therefore relatively inexpensive and easy.
  • the division of labor within the system is advantageously promoted by that the database is divided into a variety of independent database sections and / or there are several separate databases that communicate with only one component at a time.
  • the system advantageously provides mechanisms that are based on components enable distributed transaction and storage management, which enables Robustness and reliability of the overall system is ensured.
  • FIG. 2 is a schematic model of a first embodiment of the invention Billing and customer management system 1 shown.
  • this system 1 is a database 7 only for permanent storage of data that can be retrieved later.
  • the rest of the above Functions of databases 17 used in previously known systems 14 are now largely taken over by the application logic.
  • Corresponding the services offered in the area of billing or Customer management components 5 are formed that interact with each other. can communicate via common interfaces and not the database 7 must use as an interface. This is a faster information exchange between individual applications, and through the separation the application logic from the database 7 achieves a structure that is flexible, expandable and suitable for processing large amounts of data. Changes or extensions of system 1 can be done without much programming effort be made.
  • This structure makes it possible to do any Solve problem only once, and the solution in a simple way for all components 5 of system 1. At the same time is for almost everyone implemented solution ensures that they are not just a specific set Problem solves, but always a category of problems.
  • the Fraud Management component becomes Fraud detection used. Irregularities or strong deviations from the usual behavior of the customer, for example when a high Number of international calls is found at a customer who has never been made calls abroad.
  • "Trouble Ticket Management” Complaints from customers and fault reports registered by the network itself and edited. An address register is created using the "Address Management” component managed, which allows the plausibility of an address to be checked.
  • the component Accounts Receivable can act as a kind of debt accounting component be understood. With their help, incoming payments are registered, open Bills uncovered and accounts cleared.
  • the component "Document Management" stands for the administration of customer documents (letters, faxes etc.) ready. Through the services of the "Task Management” component the corresponding work orders placed after receipt of orders.
  • the component "Order Management” is for order processing and customer management services responsible. Using the “Product Management” component the end user can check the availability of products and price lists be informed.
  • the "Inventory Management” component is for inventory management responsible, i.e. with their help is an administration of the forgiven and free phone numbers, SIM cards or other items possible.
  • Each of the components 5 mentioned performs a relatively large number of services. As already mentioned above, the components 5 can have direct interfaces Exchange data with each other. So if, for example, the component “Accounts Receivable” requires special customer data, it no longer picks it up Data back from the database, but receives the required data directly from the Order Management component or equivalent other components.
  • the component model for a billing and customer management system 1 requires basic functionality in a centralized framework 10 is available.
  • Each individual component 5 is of all other components independently. However, the components rely on one sentence of services to work properly. These needed services can also be supplied by components from other manufacturers. Then it is possible to integrate them into a system with the system's own components.
  • the present system 1 is not a purely service-based model trained, but also exhibits several elements of a more object-oriented Model. Details will be discussed in more detail later.
  • a component is a design unit with contractually specified interfaces and (if possible) only explicit context dependencies .
  • a software component can be used independently and is the subject of a composite design with Driffer products .”
  • component 5 is independent of other components can be set up and used that a component 5 can be used by billing or other providers Form customer management systems, and that a component 5 only Interfaces, i.e. has no condition in the usual sense of the word, although a component can have 5 properties and certain explicit ones Makes demands on their use within a context.
  • the components 5 in the present system 1 are generally relatively extensive. This follows from the fact that a component 5 is independent within a certain one Context can be used and must therefore be completed sufficiently. However, components 5 with only one interface are also possible.
  • Component interfaces are primarily service-based. Under the Prerequisite that a component 5 has no state, the Interfaces created by a component instance, services and send back no information about the status of component 5. The number of services or interfaces provided by a component 5 Delivered must correspond to the number that is necessary to make up the set of behaviors publish completely, summarized within component 5 is.
  • the present component model primarily uses Line services, especially around the use of components 5 with To enable components from other manufacturers.
  • the present uses Billing and customer management system 1 between those for this System 5 components also developed a more traditional, object-oriented Model option where components 5 use their internal classes publish through other components, which is more of a peer-to-peer architecture corresponds.
  • the components 5 thus exist as individual closed units within of a system.
  • the technical basis for execution and communication is delivered through a framework 10.
  • the framework 10 is part of the whole Systems 1, which is completed by the business-specific logic. Details about the architecture of the system 1 is explained in the description of FIG. 3.
  • Components 5 communicate with each other, providing published services use, but also have contextual requirements, i.e. the whole behavior, on which a component 5 is dependent, and not in the Component 5 itself is implemented by other components or by Framework originate.
  • a key feature of the framework is that it is closed, i.e. the framework provides the container for the execution of a component 5.
  • the structure of the component design allows it to be simple Packing application elements for the purpose of seclusion.
  • the structure of the component software is therefore as follows: Business domain classes are grouped into packages, one package being a relatively fine logical one Represents domain. These packages are grouped into components 5, so that packages in a component contain 5 classes that are to a certain extent mutually use, while packages in separate components 5 mutually use as little as possible. Finally, components 5 are put together grouped in servers. This grouping can be optional, it being cheap is when components 5 that often communicate with each other are in the same server are summarized. To connect to third-party frameworks, it is necessary many dependencies as possible between the execution environment and one Remove component 5. Therefore, each component 5 needs its own global one AbstractFactory instance; this cannot happen per server as it is not guaranteed is that component 5 will run within this server.
  • AbstractComponent class contains the attributes and the behavior that is common to all components 5. Specific components 5 are subclasses of this class. Because the services provided by one Component 5 are delivered, involved in transactions, and multiple Component services may be involved in a transaction is the AbstractComponent class transactional.
  • the subclasses of the AbstractComponent class, the actual components 5, include all services specific to component 5. Another one An essential feature of each subclass is an instance of a facade class for each external component with which component 5 communicates.
  • Services at the component boundaries or services in others Components implemented are modeled internally using facade objects.
  • the services in the facades are those that are the component 5 needed to work.
  • component "A” internally has one "B” facade instance and a "C” facade instance if they intersect in the components "B” and “C” used.
  • the design and implementation of the Component “A” can then largely independent of component “B” and “C” are executed. If components 5 are used, must the services in the facades in appropriate services in others Components are mapped.
  • these facades are implemented in such a way that mapping a facade service to an actual component service without change of the code can be executed. For this reason there is an abstract Class that contains general behavior, the AbstractFacade class. Either the framework supports published domain objects as well as components 5 10 transactions between components 5. For service propagation implicit propagation is used from component to component. in the Storage management area are the transaction contexts for non-transaction-related Purposes.
  • Embodiment of the accounting and customer management system 1 for a services used in component facades when services for external components.
  • components 5 their internal classes for use by other intrinsic systems Components 5.
  • FIG. 3 shows the division of system 1 into hierarchically arranged layers (Layers) with increasing degree of abstraction and in layers (tiers) accordingly divided the technical tasks.
  • the layers and levels in architecture of system 1 provide a two-dimensional matrix. However, this subdivision is not explicitly represented in the package structure of the framework 10.
  • Each layer is of the complex concerns of the ones below Layers isolated, so that communication between the layers only by means of Use of standard interfaces is implemented. This will make a high one Degree of flexibility and independence guaranteed.
  • the system 1 is divided into five layers.
  • the lowest base layer (Base Layer) 40 contains classes, the basic Deliver behaviors such as system resources, operating system, and hardware-specific Classes.
  • the layer also includes the behavior of that used Third party software is obtained.
  • the basics of CORBA a common standard architecture for Object request broker, as well as from TopLink, an object-related facility to include.
  • TopLink an object-related facility to include.
  • Java used as a programming language in this embodiment Java used.
  • the technical support layer (Technical Services Layer) 44 which includes classes that offer software engineering services.
  • the application layer 46 above contains all classes and behavior for a dynamic definition of the elements of an application or a component 5 on a meta level. Instances of these classes are used when interacting with a real application.
  • the services of technical support layer 44 are combined into an abstract application and mechanisms for describing the elements of the domain level 58 allowed on a meta level.
  • the application layer 46 includes the Classes that represent the highest level of abstraction in the system, for example the factory, which provides different services from the ones below Layers used, such as transaction and persistence support.
  • the entirety of the elements from the base layer 40 to parts of the application layer 46 can also be referred to as a (technical) framework 10. It is only through the business layer (Business Layer) 50 that the specific Contains classes for the behavior of an application and a component 5, and in which the actual service-specific processes are programmed, system 1 is completed.
  • the insulation of the individual layers realizes that, for example, the Business logic developer activity does not involve a change in an underlying one Layer (such as a change in the operating system) is affected.
  • System 1 can also be divided into different levels (tiers). It is between distinguish between the division into logical and physical levels.
  • the Division of the system into two logical levels (thick clients) or three logical levels Levels (thin clients) is made because of different logical levels Processing processes can run independently and simultaneously.
  • the system is also in one finer level structure divided by physical levels.
  • the top level and therefore the level closest to the system user is the presentation level (Presentation Tier) 52.
  • the server is not actually compatible with the Presentation level 52, its framework 10 still needs some Provide facilities with which the objects of the presentation level 52 communicate can, and also determine how presentation-specific behavior must be treated.
  • the elements of the presentation relate to the representation of information, the navigation through this information and its manipulation.
  • the framework 10 of the server requires the use of an object-oriented User interface ahead and provides appropriate facilities.
  • the Elements of presentation level 52 use the descriptive information which is delivered in meta application instances to define aspects of how Business objects and their attributes should be viewed or used.
  • This Meta application information provides an isolation layer between the presentation objects (Windows) and application or business objects. A additional insulation layer can be achieved through access privilege facilities that show or hide server elements.
  • the application tier 54 includes classes and interfaces, which represent the application, as well as classes related to the application Pack component behavior in packages. Included are a number of classes which are necessary for the interaction with an application, as well as the fundamental abstract class for application control classes and application process classes. These classes form the main interface for clients within the applications. They provide the fundamental mechanisms for communication with the application, by creating instances of desired objects and allow navigation to these objects.
  • the application level 54 contains the classes that model business processes, which are the underlying ones Use business objects. Most of the individual recruitment work is therefore isolated in this plane.
  • the application level 54 contains the facade objects, which are the main facilities represent for communication between components 5.
  • the classes in the meta-application tier 56 provide one Application facilities to describe and change yourself.
  • the meta application level 56 consists of classes that define the information allow for aspects of application objects and domain objects. This Classes make it possible to dynamically reflect aspects of business objects configure a meta level. Such aspects include the title of Classes also contain format masks and lengths for attributes, contain information, whether certain attributes are mandatory, etc.
  • the meta-application facilities are at a higher level than the applications and provide general functionality that is applicable to all applications is.
  • Domain level 58 assigns the business object classes a specific application domain.
  • the domain level 58 the level that is the only class that includes the business domain model an application.
  • the work area for application developers is therefore limited mostly at this level.
  • Domain level 58 consists almost entirely of an abstract domain class, from which all business objects inherit their behavior.
  • the domain level contains 58 domain classes, each subclass of the above represent the abstract class mentioned. These classes don't model stable changing behavior of the central classes of a problem domain. Any inconsistent Behavior that affects a domain class is grouped into classes, which are assigned to application level 54, but by the domain classes to be used.
  • the Persistence Tier 60 is the level that defines the interactions between Domain objects and persistent storage. Consequently it includes the behavior that provides persistence for objects, namely their storage and retrieving.
  • the level also includes the class that the connections managed with the database 7. Overall, it provides an illustration the class model of domain level 58 to the data model of the database 7 and on the other hand supports mechanisms for transaction-secured Manipulation of the data in the database 7.
  • client side 70 and server side 71 are shown separately.
  • server side 71 On server side 71 are business layer objects 72, application layer objects 74, and Meta application layer objects 76 outlined.
  • client side 70 On client side 70 are the required ones Interfaces 66, in particular GUIs, as well as specially designed interfaces JavaBeans 68.
  • the arrows outline the respective interaction options between client and server or within the client.
  • GUI facilities are created so that the system user has user interfaces Can make settings, reducing the programming effort is reduced. Through their use it is possible to use the interface model of the server on client side 70 and thus the one used Hiding communication technology from a client developer.
  • the system user thus has interfaces at which he can access can attach to implement his special requests. This happens on special localized locations so that no basic code is changed got to.
  • Meta application dictionary the dynamic configuration of application information and procedures on a meta level.
  • the real thing Dictionary is represented by an instance that acts as the root of the dictionary and also contains information about the application as such. Of the dictionary also contains the set of instances, the meta information define for classes.
  • the meta application dictionary therefore has a lot of properties that apply to each class in the server.
  • An extension or The behavior of the entire system 1 can be changed during the runtime, without having to change the existing code.
  • These extensions will be implemented by the business classes listed in the server derived or added as new classes.
  • the new Classes are configured in the server by the meta application facilities of the server can be used. These subclasses can overwrite most of the existing methods and therefore have the option of to change or expand the existing functionality.
  • Fig. 5 shows a schematic representation of the development of the prior art Systems 14 to a first and a second embodiment of the invention Billing and customer management system 1.
  • the one made in FIG Division of the systems into three logical levels for presentation logic 82, application logic 80 and database 84 is only a background for the previously described classification of the accounting and To view customer management system 1 in physical levels, of which how mentions preferably more than three may exist.
  • presentation logic 82 formed application logic 80 and database 17 each a large block with corresponding communication options, which have already been explained in detail for FIG. 1.
  • System 1 now not only enables application logic 80 to separate according to the services offered, rather it is also conceivable that the database 7 itself in logically separate database sections 12 instead of forming a large monolytic block and / or that several separate databases 12 exist. Each database section and / or each separate database 12 is then exactly for one component 5 responsible, which it delivers data and from which it stores data.
  • the present billing and customer management system 1 makes it possible to reproduce other application servers according to existing servers and use them in parallel. This makes the billing and Customer management system 1 also for system users with a few million billable Customers and a large number of transactions.
  • system 1 provides mechanisms that are based on the components 5 Enable distributed transaction and storage management.
  • the preferred model of the billing and customer management system presented above 1 is only to be regarded as a preferred embodiment, conceivable however, there are many modifications to this particular embodiment.
  • the number of layers and levels is not exactly due to that in the above Example defined number defined, but can be arbitrarily up or down can be varied as long as the division into at least two layers and maintaining at least two levels.
  • System 1 can also be used as desired apply to thin or thick clients.
  • the exact division into components 5, that was explained in relation to FIG. 1 is also to be understood merely as an example. Therefore can also provide other billing and customer management services can be combined into a corresponding component 5, as long as the general criteria for component 5 are met.
  • the Use of Java, CORBA and TopLink is only a question of the current one Market offer; it is also conceivable to use other products with similar properties use for the present purposes.
  • billing and customer management system 1 is not limited to use in the telecommunications sector. Rather, it is quite possible to use System 1 throughout the consumer industry (Electricity, water, gas, internet etc.) or parts of the system 1 to be used for pure customer management in companies.

Landscapes

  • Engineering & Computer Science (AREA)
  • Business, Economics & Management (AREA)
  • Theoretical Computer Science (AREA)
  • Strategic Management (AREA)
  • General Physics & Mathematics (AREA)
  • Physics & Mathematics (AREA)
  • Marketing (AREA)
  • Entrepreneurship & Innovation (AREA)
  • General Business, Economics & Management (AREA)
  • Economics (AREA)
  • Software Systems (AREA)
  • Development Economics (AREA)
  • Human Resources & Organizations (AREA)
  • Accounting & Taxation (AREA)
  • Data Mining & Analysis (AREA)
  • Operations Research (AREA)
  • Quality & Reliability (AREA)
  • Tourism & Hospitality (AREA)
  • Finance (AREA)
  • General Engineering & Computer Science (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)
EP00106948A 2000-03-31 2000-03-31 Système de facturation et de gestion de clients Withdrawn EP1139243A1 (fr)

Priority Applications (19)

Application Number Priority Date Filing Date Title
EP00106948A EP1139243A1 (fr) 2000-03-31 2000-03-31 Système de facturation et de gestion de clients
US09/819,446 US20020087341A1 (en) 2000-03-31 2001-03-28 Customer care and billing system
PCT/IB2001/000575 WO2001073625A1 (fr) 2000-03-31 2001-03-29 Systeme de suivi et de facturation de clientele
AU44455/01A AU4445501A (en) 2000-03-31 2001-03-29 Customer care and billing system
EP01923007A EP1307814A4 (fr) 2000-03-31 2001-03-31 Systeme et procede de meta application
AU2001249747A AU2001249747A1 (en) 2000-03-31 2001-03-31 A meta application system and method
AU2001249748A AU2001249748A1 (en) 2000-03-31 2001-03-31 Corba jellybeans system and method
EP01923008A EP1314096A4 (fr) 2000-03-31 2001-03-31 Systeme et procede de circuits integres d'architecture d'agents de requetes d'objects communs
AU2001249746A AU2001249746A1 (en) 2000-03-31 2001-03-31 Object to object communication system and method
US09/823,866 US20020052979A1 (en) 2000-03-31 2001-03-31 Object to object communication system and method
US09/823,892 US7082609B2 (en) 2000-03-31 2001-03-31 Meta application system and method
EP01923006A EP1328863A4 (fr) 2000-03-31 2001-03-31 Systeme et methode de communication objet a objet
PCT/US2001/010535 WO2001075630A1 (fr) 2000-03-31 2001-03-31 Systeme et procede de circuits integres d'architecture d'agents de requetes d'objets communs
US09/823,894 US20020049864A1 (en) 2000-03-31 2001-03-31 Corba jellybeans system and method
PCT/US2001/010534 WO2001075550A2 (fr) 2000-03-31 2001-03-31 Systeme et procede de meta application
PCT/US2001/010533 WO2001075584A1 (fr) 2000-03-31 2001-03-31 Systeme et procede pour communication d'objet a objet
US09/825,438 US20020059332A1 (en) 2000-03-31 2001-04-02 System and method for memory management
US09/825,151 US7086084B2 (en) 2000-03-31 2001-04-02 System and method for logins
US09/825,298 US7086066B2 (en) 2000-03-31 2001-04-02 System and method for exception handling

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
EP00106948A EP1139243A1 (fr) 2000-03-31 2000-03-31 Système de facturation et de gestion de clients

Publications (1)

Publication Number Publication Date
EP1139243A1 true EP1139243A1 (fr) 2001-10-04

Family

ID=8168310

Family Applications (1)

Application Number Title Priority Date Filing Date
EP00106948A Withdrawn EP1139243A1 (fr) 2000-03-31 2000-03-31 Système de facturation et de gestion de clients

Country Status (3)

Country Link
EP (1) EP1139243A1 (fr)
AU (1) AU4445501A (fr)
WO (1) WO2001073625A1 (fr)

Families Citing this family (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8832178B2 (en) 2002-11-06 2014-09-09 Noel William Lovisa Service implementation
WO2004042640A1 (fr) * 2002-11-06 2004-05-21 Noel William Lovisa Mise en oeuvre de services
AU2003275765B2 (en) * 2002-11-06 2010-08-05 Noel William Lovisa Service implementation
EP1939806B1 (fr) * 2006-12-29 2011-05-11 Accenture Global Services Limited Inventaire de numéro pour des systèmes de télécommunication cellulaires
US8676745B2 (en) 2006-12-29 2014-03-18 Accenture Global Services Limited Integrated number management module and service order system

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2000007128A1 (fr) * 1998-07-29 2000-02-10 American Management Systems, Incorporated Systeme de facturation et de service client convergent et modulaire

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2000007128A1 (fr) * 1998-07-29 2000-02-10 American Management Systems, Incorporated Systeme de facturation et de service client convergent et modulaire

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
BOYD: "Customer Billing Technology and Issues", ANNUAL REVIEW OF COMMUNICATIONS INTERNATIONAL ENGINEERING CONSORTIUM, vol. 47, 1994, Chicago, IL, US, pages 800 - 806, XP000455398 *
KLEISSNER: "Enterprise Objects Framework", SIGMOD RECORD, vol. 24, no. 2, 1 June 1995 (1995-06-01), New York, NY, US, pages 455 - 459, XP002047857 *

Also Published As

Publication number Publication date
AU4445501A (en) 2001-10-08
WO2001073625A1 (fr) 2001-10-04

Similar Documents

Publication Publication Date Title
EP1194865B1 (fr) Procede de tenue de fichiers dans un reseau de systemes de banques de donnees en partie repliques
DE69835158T2 (de) Zugriffpunkt zur dienstverwaltung
DE69738309T2 (de) Verteilte verarbeitung
DE60035800T2 (de) Verfahren zum unterstützen von verteilten transaktionen mit jdbc 1.0 -treibern
DE69631373T2 (de) Abrechnungsverwaltung für telekommunikationsbenutzung
DE19954268B4 (de) Verfahren und System zur Verbesserung des Workflow in Workflow-Management-Systemen
DE10195968B4 (de) System und Verfahren zur Bereitstellung einer Kreuzdimensionalen Berechnung und eines Kreuzdimensionalen Datenzugriffs in einer Online-Analytischen Verarbeitungs-Umgebung (ON-LINE ANALYTICAL PROCESSING = OLAP)
WO2006103096A2 (fr) Systeme de reseau d'ordinateurs pour elaborer, synchroniser et/ou exploiter une seconde banque de donnees a partir de/avec une premiere banque de donnees et procedure appropriee
EP0520083B1 (fr) Protection de la consistance des données dans un système de télécommunications numériques
WO2006103090A1 (fr) Systeme de reseau informatique concu pour synchroniser une seconde banque de donnees a une premiere banque de donnees et procede associe
WO2006103098A2 (fr) Systeme de reseau informatique pour etablir, synchroniser et/ou faire fonctionner une seconde banque de donnees a partir d'une premiere banque de donnees / avec une premiere banque de donnees, et procede correspondant
DE10311074A1 (de) Verfahren und Anordnungen in einem Telekommunikationsnetz
DE102006047499A1 (de) Datenerweiterbarkeit mit Hilfe externer Datenbanktabellen
DE19628168A1 (de) Vernetztes multimediales Netz
EP1179793A1 (fr) Portail pour fournisseurs de services financiers
DE10314597A1 (de) Verfahren und Anordnungen in einem Telekommunikationsnetz
EP1139243A1 (fr) Système de facturation et de gestion de clients
DE10244459A1 (de) Rechner- und/oder Software-Architektur unter Verwendung von Micro-Kernel- und Multi-Tier-Konzept mit Komponententechnik
EP1234231B1 (fr) Procede permettant de produire des interfaces utilisateur graphiques pour des programmes informatiques
EP1285315B1 (fr) Systeme de traitement d'informations et son procede d'exploitation
DE602004001762T2 (de) Verfahren und computersystem zur datenzuweisung
DE69534777T2 (de) Flexibler anrufregistrierungsmechanismus
DE19951756B4 (de) Verfahren zur Datenverwaltung sowie Computerprogramm und -system zu dessen Ausführung
Aneesh Globale Arbeit: Algokratische Formen der Organisation
EP1239377A1 (fr) Système de gestion de données et procédé de gestion de la synchronisation de structures de données

Legal Events

Date Code Title Description
PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

AK Designated contracting states

Kind code of ref document: A1

Designated state(s): AT BE CH CY DE DK ES FI FR GB GR IE IT LI LU MC NL PT SE

AX Request for extension of the european patent

Free format text: AL;LT;LV;MK;RO;SI

AKX Designation fees paid
REG Reference to a national code

Ref country code: DE

Ref legal event code: 8566

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE APPLICATION IS DEEMED TO BE WITHDRAWN

18D Application deemed to be withdrawn

Effective date: 20020405