WO1998053599A1

WO1998053599A1 - Object oriented call processing and service creation platform

Info

Publication number: WO1998053599A1
Application number: PCT/US1998/010585
Authority: WO
Inventors: Steven P. Higgins; Richard D. Moore; Michael M. Myers; Alastair N. Spinks
Original assignee: Mci Communications Corporation
Priority date: 1997-05-23
Filing date: 1998-05-21
Publication date: 1998-11-26
Also published as: AU7693898A

Abstract

An object oriented call processing system includes an object oriented database and a call processing application. A telecommunications system service creation platform (25) including an order entry server (18) that includes a central object oriented database for storing call flows. A plurality of order entry workstations (20a, 20n) are in communication with the order entry server (18). A plurality of product transaction servers (14a, 14b, 14c) are in communication with the order entry server (18). Each switch (10) of a telecommunications switch network is connected to an NCS platform (16) including three NCS Data Access Points (12a, 12b, 12c) using conventional data communication links (11). An NCS Order Entry (22) accepts input from a user representing network configuration data. An NCS Service Control Manager (24) converts the data to a format readable by the DAPs (12), and distributes it among the DAPs (12) over link (21).

Description

OBJECT ORIENTED CALL PROCESSING AND SERVICE CREATION PLATFORM

FIELD OF THE INVENTION

The present invention relates generally to methods and systems for processing telephone calls, and more particularly to a method of and system for creating call flows and processing telephone calls using object oriented technology.

DESCRIPTION OF THE PRIOR ART

Modern telecommunications networks provide a variety of services that require enhanced call processing. Such services include 800, Virtual Private Networks (VPN), and credit card accounts . These enhanced services may also include advanced features that require additional call processing. Such advanced features generally relate to methods of performing least cost routing (LCR) , and result in more than one possible route for a single number. The object of LCR is to choose the network route which minimizes costs based on certain variables. These variables, which define the advanced features of enhanced services, include such things as time-of-day, day-of-year, day-of-week, percent allocation, point of origination, and point of termination.

In addition to these features, a recent development in the international telecommunications environment has introduced a new set of requirements for call routing.

International Simple Resell (ISR) agreements among various countries have been made that dictate the type of network facilities that must be used when transporting a call between countries . These ISR agreements result in a need for a telecommunications network to employ an advanced call processing platform to ensure that international calls are routed to meet the long-term regulatory routing (LTRR) requirements, as well as take advantage of LCR features. Call processing refers to the functionality a network employs to determine how to route each call. It may be as simple as determining a single network termination for residential number, or as complicated as processing through several dozen tiers of logical decisions to determine the optimal one of hundreds of possible network terminations for a customer service 800 number. A plan for how a call will be processed by a network is referred to as a call flow.

To increase the efficiency of the switching network, the functionality needed to perform advanced call processing has been migrated off of the switches and onto external computers . These computers generally access one or more databases that contain network addresses for routing calls based on several different parameters, such as originating Automatic Number Identification (ANI) , dialed number, or time-of-day. The computer platform on which advanced call processing is performed is generally referred to as a Service Control Point (SCP) , and herein as a Network Control System (NCS) .

The current method of call processing on an NCS platform includes receiving from a switch a query message that contains originating ANI, dialed number, and possibly other data. The NCS then performs an iterative series of algorithms and table lookups . An initial key may be a customer identification based on either the originating ANI (i.e., for a VPN call) or on the dialed number (i.e., for an 800 call) . A table lookup is then performed to determine which set of features needs to be called upon. Table lookups for each of those features needs to be performed. Additional table lookups may be required if point of call origination or point of termination is relevant.

This conventional method presents several difficulties in call processing for enhanced services. Building new products is very difficult and requires extensive development time. Highly complex programming is needed in both the NCS executable programs and the NCS databases . Generally, because of the programming needed, new products are subject to long development cycles, frequently one year or more. New products must also be bundled and implemented in scheduled releases. Releases may occur only four or five times a year, requiring customers to wait for their services to be implemented. New products must also be developed to follow very rigid guidelines, such as the order in which features may be called upon in call processing. This severely limits the capability to customize call plans for customers .

Adding new features to existing products, or modifying a specific customer's call flow, is also extremely difficult. Like developing a new product, adding features to an existing product requires an extensive development cycle, must be implemented in a scheduled release, and must follow rigid guidelines dictating where in the call flow a feature may be added.

Once a call flow is implemented, its performance in call processing on a conventional NCS platform is limited by the numerous and iterative hashing algorithms and table lookups that must be performed. This will be especially evident with the implementation of long term regulatory routing (LTRR) call processing. In addition to customer/product identification and LCR functions that must be performed, a number of additional hashing and table lookups must be performed to determine how to route a call in accordance with LTRR requirements . This can be very time-consuming, and as with call processing in which a caller is waiting for the call setup to be completed, every fraction of a second is valuable.

The problems identified with conventional NCS call processing have analogies in the software industry in general . Increased demands on computers have caused traditional software technologies to become burdensome in terms of both development time and processing time. Object- Oriented Technology (OOT) has emerged as a new software technology that can be effective in decreasing development time and simplifying development. It can also increase performance in many applications.

While other facets of the software industry have migrated to OOT and are experiencing the benefits, telecommunications networks are still by and large controlled by traditional software technologies, such as structured programming languages, hashing algorithms, and iterative table lookups. These traditional software technologies present Network Control Systems with the previous mentioned problems of excessive development times of new products, effort and skills required in product development, difficulty in adding new features to calling plans, and limited performance of call processing.

SUMMARY OF THE INVENTION

An improved method for developing intelligent call processing products and for performing intelligent call processing services on a telecommunications network is provided by an advanced object-oriented platform. New call processing products are developed at a workstation with a graphical user interface (GUI) by selecting and placing icons, each of which represent a product feature, to create a call flow. This call flow is in the form of a node tree. The nodes of the tree, which represent the various features of the product, are embodied by objects in call processing. Nodes are defined by object classes. When a particular node is traversed in call processing, an object is referenced which represents the instantiation of that class (node) used by the particular call that is being processed.

When a new product, or call flow, is built, it is downloaded from the workstation to an object oriented database on a server. Data from this object oriented database are then uploaded to the network control platform. When a query for call processing is received by the network control platform from a switch, the customer is identified by performing an initial table lookup. A customer identification key that is returned serves as a pointer to the object that represents the base node of the appropriate call processing node tree. Alternatively, a specific product, revenue owner, or other parameter may be initially identified and used to point to the base node of the appropriate node tree.

From the base node, each node of the node tree is traversed via object pointer navigation. A pointer is an attribute in one object that contains an explicit reference to another object. When a node, or instance of a class, is traversed by the processing of a particular call, its object contains pointers to additional objects. These objects represent subsequent nodes on the node tree; one of them is chosen as the next node by the node being traversed. In such a manner, the nodes are traversed until an end node is reached. An end node represents the termination of call processing. The end node points to an information node that specifies how the call is to be handled. This specification will be a network address for routing, a request for default routing, or a request for call treatment (such as voice recording) to be applied at the switch.

In the present invention, an object-oriented call processing and service creation platform may be implemented as a platform for fast product development. Therefore, it is referred to as the Fast Product Development (FPD) platform. In the preferred embodiment, the FPD platform is coupled to an existing Network Control System (NCS) platform. The NCS platform provides call processing functionality from the prior art. Both the NCS and FPD platforms utilize transaction servers to receive switch queries, perform call processing, and respond with a network routing address. Platform coupling is accomplished by linking the Fast Product Transaction Servers (FPTS) of the present invention and the NCS Transaction Servers (NCS TS) via a Fiber Distributed Data Interface (FDDI) ring, which provides a local area network (LAN) environment.

By coupling the FPD platform to an existing NCS platform, call queries that qualify for FPD processing can be passed through the NCS TS and onto the FPTS. Other call queries can be processed by the NCS TS . Alternatively, call queries which qualify for FPD processing may be sent directly to the FPTS. This architecture allows for a distributed call processing environment in which call processing for both FPD applications and NCS applications can be performed on a single platform. It also allows for a phased migration from a traditional NCS platform to the FPD platform.

A Service Creation Environment (SCE) is provided in the FPD platform by one or more Fast Order Entry (FOE) Workstations. The FOE Workstation presents a GUI and may operate on any standard PC. It allows the user to create products by building call flows in a graphical manner that is analogous to the way in which a person visualizes call flows .

The FOE Workstations are connected to a Fast Order Entry (FOE) Server, which is in turn connected to each FPTS. When a user completes a call flow, the FOE Workstation downloads it to the FOE Server. The FOE Server maintains a centralized object-oriented database of record for all FPD call processing products. It also distributes the data from this database to each of the FPTS ' s in redundant fashion. In the preferred embodiment, in which the FPD platform is coupled to the existing NCS platform, the FOE Server is also connected to the order entry system of the NCS platform. This allows for network configuration updates that are entered in the NCS order entry system to be input to the FOE Server database. It also allows for network configuration updates to be entered into the FOE Workstation and fed to the NCS platform.

Products are created on the FOE Workstation by building call flows in a graphical manner. Call flows are built by placing icons, which represent call features, into a node tree. Each node in the tree represents a decision point in the call flow. Examples of nodes are the country a call originates in, the country a call terminates in, the time of day a call originates, the day of week of call origination, etc. Each branch of the node tree ends with a customized network routing termination, a default network routing termination, or a call treatment, which is typically a message played by a switch.

The nodes of the completed tree become instances of object classes embedded with pointers (object associations) , and are then loaded into an object oriented database (OODB) on the FOE Server. Each node, or object class, on a node tree represents a certain call feature, such as time of day of call origination. They are defined to have, as attributes, pointers to other objects based on the value of the key attribute (e.g., time-of-day) of the object. Data from the OODB is distributed to each FPTS for use in call processing. There may be a different node tree for different products, customers, revenue owners, other parameters, or combinations thereof.

When a switch receives a call that requires enhanced call processing, the switch issues a query to the NCS platform. This query contains such information as the dialed number and originating ANI . The NCS TS processes the query to a certain extent, based on the type of call. Then, if the query requires additional processing, the NCS TS sends the query to the FPTS.

When the FPTS receives the query, it performs an initial table lookup to determine the appropriate node tree to reference. The base node of the appropriate node tree is pointed to, a method on that base node is called, and an entire branch of the node tree is traversed via object pointer navigation. The last node, or object, referenced will point to an information object that provides either a network address for routing, a request for default routing, or a request for call treatment. Information objects are part of a separate inheritance tree than the call processing objects, and may therefore be modified (i.e., to reflect changes in network configuration) independently, without affecting call processing objects.

BRIEF DESCRIPTION OF THE DRAWINGS

Figure 1 is a block diagram illustrating the network architecture of the preferred embodiment, in which the FPD platform is coupled to an existing NCS platform.

Figure 2 is a block diagram illustrating the network architecture of a single cluster of FPD Transaction Servers and NCS Transactions Servers. Figure 3 is a block diagram illustrating the internal systems architecture and data flow of the Fast Product Transaction Server (FPTS) .

Figure 4 is an example of a call processing node tree for a single customer, illustrating the representation of call product features as object classes.

Figure 5 is an example of a call processing node tree used for LTRR for a telecommunications carrier (Revenue Owner) .

Figure 6a is an OMT object modeling diagram showing inheritance and association for call processing object classes .

Figure 6b is an OMT object modeling diagram showing inheritance and association for information nodes object classes . Figure 7 is a use case diagram illustrating the processing of a call query on the FPD platform. Figure 8 is a sample screen from an FOE Workstation showing the graphical presentation of a call flow builder.

Figure 9 is a block diagram illustrating the internal systems architecture of the FOE Server.

DESCRIPTION OF THE PREFERRED EMBODIMENT

Figure 1 illustrates the network architecture of a preferred embodiment of the invention. Each switch 10 of a telecommunications switch network is connected to an NCS platform 16 including three NCS Data Access Points (DAPs)

12a ... 12c using conventional data communication links 11, such as the well-known X.25 protocol over a packet switching network. An NCS DAP 12 is a cluster of communication and transaction servers, and is shown in greater detail in Figure 2. NCS DAP 12 is the primary NCS component for enhanced call processing. The three NCS DAPs 12 are totally redundant. The purpose of connecting a switch to three redundant NCS DAPs 12 is for network survivability.

A Fast Product Transaction Server (FPTS) 14a ... 14c is the primary call processing component of the FPD platform 25. In the preferred embodiment, an FPTS (i.e., 14a) is a cluster of two DEC Alpha 2100 units and one DEC Alpha 1000. This provides hardware scalability. However, more or fewer hardware units may be used. They operate with DEC'S VMS operating system. A detailed architecture of the preferred embodiment is shown in Figure 2.

With continued reference to Figure 1, each NCS DAP (i.e., 12a) is coupled with a primary FPTS (i.e., 14a) via a Fiber Distributed Data Interface (FDDI) ring 13. The FDDI ring 13 provides a LAN environment for the DAP 12a and

FPTS 14a to communicate. In the preferred embodiment, since both the DAP 12a and the FPTS 14a are DEC computers, DECNet provides the data communications protocol over the FDDI ring 13.

Each NCS DAP (i.e., 12a) is also coupled to the other two FPTS's (i.e., 14b and 14c) via standard Tl communications links 15, again using DECNet protocol. This is to provide redundancy in the event of an FPTS failure.

When the switch 10 receives a call that requires enhanced call processing, the switch 10 issues a query to the NCS DAP 12. This query is a message, which may be identified as an Application Data Field (ADF) message. The ADF message contains information such as originating ANI and dialed number. The ADF message is sent to the NCS DAP 12 over the X.25 data link 11.

The DAP 12 receives the ADF message and processes the query. If the query is for a qualified call (a call that requires additional processing on the FPD platform) , then a Generic Request Message (GReqM) is created by the DAP 12 and sent to a Fast Product Transaction Server (FPTS) 14 via the FDDI ring 13. The GreqM contains data from the original ADF message, along with data obtained from processing in the

DAP 12. The FPTS 14 processes the call and returns instructions for routing to the DAP 12. The DAP 12 then passes these instructions in an ADF response message to the switch 10. Order entry on FPD platform 25 occurs on one or more

Fast Order Entry (FOE) Workstations 20a ... 20n. These Workstations operate on standard PCS running Windows 3.11, Windows '95, or Windows NT. Each FOE Workstation 20 is connected to an FOE Server 18 via Wide Area Network (WAN) 19 in a client/server architecture.

FOE Server 18 is a DEC Alpha 2100. FOE Server 18 serves several functions. FOE server 18 maintains the object database of record for all products created on the FPD platform. Additionally, FOE server 18 provides FOE Workstations 20 with the data needed to develop call flows. FOE server 18 validates the products and call flows created on FOE Workstations 20. Finally, FOE server 18 distributes the new call flows to the FPTSs 14.

In the preferred embodiment, communications between the FOE Workstations 20 and the FOE Server 18, as well as communications between the FOE Server 18 and the FPTS 14, is via TCP/IP on links 19 and 17, respectively.

NCS platform 16 also includes an order entry system. The NCS Order Entry (NCS OE) system 22 accepts input from a user representing network configuration data. This data includes the dialed number or network address translations that are needed by NCS for call processing. An NCS Service Control Manager (SCM) 24 converts the data to a format readable by the DAPs 12, and distributes it among the DAPs 12 over link 21.

The NCS SCM 24 is also connected to the FOE Server 18 by a link 23. This allows for updates in network configuration data to be fed to the FPD platform, if routing translations are to be performed in the FPTS. The FOE Server 18 maintains the centralized object database and will update this database with data entered from the NCS OE 22 and FOE workstation 20.

Figure 2 illustrates the preferred architecture of a single DAP/FPTS cluster, such as DAP 12a and FPTS 14a. A single DAP 12a generally includes up to 25 Communication Servers (CS) 30a ... 30b, although only two are shown for illustrative purposes. The actual number implemented will depend on traffic volumes. A DAP 12a also includes a plurality of NCS Transaction Servers (TS) 32a ... 32b. An FDDI ring 13 provides a LAN environment for the various servers to operate in, communicating via DECNet protocol (although other protocols may be used) .

The FPTS 14a preferably includes multiple units, each operating as a distinct FPTS 14a-l ... 14a-3. In the example shown in Figure 2, three FPTS's are used. However, the architecture is scaleable and additional FPTSs may be added to support increased call volumes. The FPTSs 14 are linked to the NCS servers via the FDDI ring. Each NCS TS 32 and FPTS 14 may embody call processing functionality for different call applications. For example, as shown in Figure 2, there is an NCS TS 32a for VPN and credit card applications, and an NCS TS 32b for 800 applications . Each switch 10 in the telecommunications network is connected to each DAP 12a redundantly, via a single X.25 data link to each of two CSs 30a and 30b. This provides survivability in the event of either a link 11 failure or CS 30 failure. When a switch 10 issues a query for call processing to the DAP 12a, CS 30 identifies the call type. The CS 30 then determines which NCS TS 32 to route the query to. If it is for a VPN or a credit card call, the query is routed to NCS TS 32a for processing. If it is for an 800 call, the query is routed to NCS TS 32b for processing.

During NCS TS 32 processing of the query, it is determined whether the query requires processing by an FPTS 14. This determination is based on predefined conditions. NCS call processing is done by creating an initial database key, such as a customer identification code derived from the originating ANI, and performing a table lookup on that key. The result will be used to create another key, which will be used for another table lookup. This is an iterative process. During processing, predefined conditions may result in a request for FPTS processing. This is the trigger point. At this point, the NCS TS 32 creates a Generic Request Message (GreqM) . The GreqM, which contains data from the original ADF message along with that obtained from NCS TS processing, is sent to an FPTS 14.

The FPTS 14 processes the query and returns instructions for routing to the NCS TS 32. The NCS TS 32 then includes this information in the ADF response message that it sends back to the switch 10.

In the present invention, object oriented technology (OOT) is applied to call processing on FPTS 14. Using OOT, the present invention provides both an improved platform for building enhanced call products, and an improved platform for enhanced call processing.

The prior art of call processing on NCS TS 32 performed a series of hashing and table lookups . For example, an initial hashing key would be created from the originating ANI or dialed number. This key would then be used to perform a table lookup to retrieve a customer identification. The customer identification would then create another hashing key, which may be used to perform a table lookup to retrieve a key indicating that a day-of-week routing algorithm is to be used. This iterative process could incorporate various features of call processing (time-of-day, day-of-week, percent allocation, point of origination, etc.), but only in a specific orders pre-defined by the product type. It is also burdened by the slow execution of multiple table lookups.

Call processing using OOT is performed by defining each feature (i.e., day-of-week (DOW) routing) as an object class, and each instantiation of a feature (DOW) in a call flow as an object. These objects represent nodes on a node tree. The node tree itself represents the call flow, or call processing plan, for a particular customer's product or service.

Each object contains pointers to other objects in the node tree. A pointer is an attribute in one object that contains an explicit reference to another object. For example, Nodel may be of the class day-of-week (DOW) . It may contain an attribute that points to Node2 if the day of week of call origination is Monday through Friday, and another attribute that points to Node3 if the day of week of call origination is Saturday or Sunday. Based on the specific value (e.g., "Tuesday") given for the day of the week, a specific pointer is chosen and processing continues with the node pointed to by that pointer. This is referred to as pointer navigation, and replaces the traditional key table lookups in call processing.

Figure 3 illustrates the internal logical architecture of an FPTS 14. Also indicated in Figure 3 are data flows, numbered in order, to represent a typical call processing flow among the program modules of FPTS 14. A transaction server communications manager (Tscm) 40 receives messages from and sends messages to the NCS DAP 12. A call processing mailbox (CpMbx) 42 is the logical repository for messages sent to Tscm 40 from the NCS DAP 12. CpMbx 42 is a VMS system mailbox. A call processing distributor (CpDistributor) 44 distributes work to a call processing application (Cp) 46 by putting messages into a call processing queue (CpQueue) 48. In the preferred embodiment, there are multiple Cps 46, with each Cp application 46 having its own CpQueue 48. Cp 46 applies routing rules to a request for routing information and returns routing information. There are multiple Cp instances.

A response mailbox (RspMbx) 50 is the logical repository for messages sent from the Cp applications 46 to CpDistributor 44. CpDistributor 44 takes messages from RspMbx 50 and sends them to a transaction server communication manager mailbox (TscmMbx) 52, which is the logical repository for messages sent from Cp 46 to the NCS DAP 12. Like CpMbx 42, RspMbx 50 and TscmMbx 52 are VMS system mailboxes.

Cp application 46 creates a call record (CallRecord) 54 with information from the routing request. A call processing database (CpDb) 56, which is an object-oriented database contain routing rules and information, provides the information, based on a CallRecord 54, for creating a generic response 58. A statistics application (StatsApp) 60 collects call processing statistics for the FPD platform. In the preferred embodiment, StatsApp 60 resides on the FOE Server 18. The FPTS call processing flow is as follows:

1. Tscm 40 will Get a generic request message (GReqM) from the NCS DAP 12.

2. TSCM 40 will Put a Message into the CpMbx 42.

3. CpDistributor 44 will Get the Message from the CpMbx 40.

4. CpDistributor 44 will Put the Message into the CpQueue 48 for a Cp 46.

5. Cp 46 will Get the Message from the CpQueue 48.

6. Cp 46 will Create a Call Record 54 from the GReqM. 7. Cp 46 will Apply Rules (call processing rules) from the CpDb 56. 8. Cp 46 will Increment Call Processing Statistics based on the call tree nodes that were traversed in the CpDb 56.

9. Cp 46 will Create a Generic Response 58 from the CallRecord 54 and the database rules.

10. Cp 46 will Put a Message (Generic Response 58) in the RspMbx 50.

11. CpDistributor 44 will Get the Message (Generic Response 58) from the RspMbx 50. 12. CpDistributor 44 will Put the Message (Generic

Response 58) in the TscmMbx 52.

13. Tscm 40 will Get the Message (Generic Response 58) from the TscmMbx 52.

14. Tscm 40 will Send a Generic Response Message back to the NCS DAP 12.

15. Cp 46 will Send CallRecord 54 and Response 58 to StatsApp 60.

The CpDb 56 receives regular data updates from the FOE Server 18. Because call processing occurs around the clock, these updates must be made to the CpDb 56 while it is in use by a call processing application Cp 46. To ensure data integrity is maintained, a data locking mechanism must be used. In the preferred embodiment of the present invention, the object oriented database (OODB) , which is maintained in the FOE Server 18 and uploaded to the CpDb 56 on the FPTS 14, is built with a commercially available product called ObjectStore, offered by Object Design Inc., of Burlington, MA. This product allows an application to persistently store and access objects as if they were stored in local virtual memory even though these objects are stored in a remote database . Another mechanism which may be used is a CpFlipper. A second copy of the CpDb 56 is made and stored in the FPTS 14. At any given time, one copy is designated "read" and is used by Cp 46. The other copy is designated "write" and is updated by the upload from the FOE Server 18. The CpFlipper is a process that receives a flip request from the FOE Server when an update has been performed. CpFlipper will request a flip by placing a message into the CpQueue 48. Cp 46 will then get this message from the CpQueue and will flip the "read/write" designations on the two copies of the CpDb 56. That is, Cp 46 will start reading from the other copy. Cp 46 will then send a flip response to the CpFlipper, which will in turn send a notification to the FOE Server 18 to proceed with the update . Figure 4 illustrates a sample call processing node tree. This node tree is manifest as a collection of associated object classes (objects are associated via pointers) in the OODB that is stored on the FOE Server 18 and on each FPTS 14. On the FPTS 14, the OODB is stored in the CpDb 56 component, and cached into Cp 46.

Referring to Figure 4, the CPMainProcess node 62 represents the processing of the Call Record 54 (created in step 6 from Figure 3) to determine which node tree to call. This can be accomplished in a number of ways, depending on how the user partitions the various call trees. Generally, an initial lookup in a customer hash table is performed on either the dialed number, originating ANI, or carrier code to identify a product type, customer, or carrier. These options will depend on the particular application of the present invention. For example, if the dialed number is an

800 number, then the lookup will be to determine the owner of the 800 number. This will be the customer identification and will determine which call processing node tree to use. The customer identification will be the first node, or Base Node , of the tree .

Node trees are called with a pointer to a base node. More specifically, when Cp 46 determines the appropriate node tree from an initial hashing, it retrieves a pointer to an object in the CpDb 56 that represents the base node of that node tree. From there, various nodes are traversed in a branch that will end with an End Node. In the example shown in Figure 4, after the Base Node has been called by the CPMainProcess 62, the Base Node points to the next node, CpDOYl 64. This is defined as an object class that determines routing based on day of year of call origination. Days of year are numbered 1-366, and routing is defined as ranges of days. When a method on the CpDOYl node is called, an object is retrieved based on the value of the day-of-year (DOY) parameter that is obtained from the Call Record (created in step 6 from Figure 3) . For example, if DOY = 1-49, the CpDOWl node 66 is pointed to and called. If DOY = 50-123, the CpTODl node 68 is pointed to and called. If DOY = 124, the EndNode5 node 70 is pointed to and called. If DOY = 125-366, the CpDOW2 node 72 is pointed to and called.

CpDOW nodes route based on a day-of-week (DOW) parameter. CpTOD nodes route based on a time-of-day (TOD) parameter. CpDOWl and CpDOW2 are distinct nodes, defined differently by the range values and referenced nodes in their pointers. Such is also the case with CpTODl and CpTOD2, CpDOW2 and CpDOW3 , etc. Each branch ends with an EndNode . EndNodes always point to a Cplnfo node. The Cplnfo nodes contain explicit instructions for routing. These instructions will be included in a Generic Response Message that is returned to the DAP. They generally include either a network address for routing, a request for default routing (default routing is specified by the DAP), or a request for call treatment, which is, generally, a message played by the switch. Each

EndNode must point to one and only one Cplnfo node (so as to return a definite decision for call processing) , but an EndNode node may be pointed to by zero, one, or many CpFeature nodes . The Cplnfo objects are separately accessible through their own hash tables. This allows the Cplnfo objects to be modified (i.e., to reflect network configuration updates) without affecting the call processing objects.

It is important to note that Figure 4 is a sample node tree. The present invention allows for any order of features, or nodes, to be implemented. Thus it provides for extensive customization of call flows for various customers and products. It also allows for various types of base nodes, including product type, customer identification, and revenue owner. It is also important to note that the nodes are defined as object classes.

Figure 5 illustrates another example of a call processing node tree; in this case, one used for long term regulatory routing. This node tree is for a particular originating country for a particular revenue owner, and is thus only part of a more extensive node tree. Included as part of this Revenue Owner's 80 node tree, but not shown in Figure 5, will be several additional branches stemming from the second node down: Originating Country 82. The example shown in Figure 5 is for when the originating country is

Italy. The base node is the Revenue Owner 80. This is the carrier that owns the revenue for the call. For a call in which British Telecom (BT) is identified as the Revenue Owner 80, a pointer to the next node shown - Originating Country 82 - is made. When call processing traverses this node, it is determined that the originating country is Italy. This determination is made from a specific datum - the country code - that is included with the original switch query in the ADF message. It is sent to the FPTS 14 from the DAP 12 in the Generic Request Message (GReqM) , and becomes part of the Call Record 54 that is created in step 6 of Figure 3.

When the determination that originating country = Italy is made, a pointer to the next node shown - Egress Type 84 - is made. Egress type is defined by the type of network facility to be used to terminate the call. The two egress types are switched (shared) and dedicated access line (DAL) .

In similar manner, each node is traversed based on a determination made in the previous node. These determinations are manifest when a node chooses a subsequent node to process the call. Each object that is referenced has, as attributes, pointers to other objects. Thus, the node tree is traversed via pointer navigation. It should be noted that the second Terminating Country node 88 is not the same node as the first Terminating Country node 86, repeated. It is a distinct node, in which the object that it represents is defined differently (with different values) than the first Terminating Country node 86. Specifically, the attributes are going to define different pointers, as the nodes shown in the next level down are different. The Country Point-of-Entry (POE) nodes 90 and 92 determine at which location the Revenue Owner received the call. This determination will result in tree traversal based on the point of entry carrier. The bottom end nodes represent the end of call processing. Their objects contain pointers to other objects known as information objects (included in the end nodes for illustrative purposes) . An information object will contain explicit instructions for call processing. These instructions will be included in a Generic Response Message that is returned to the DAP. They generally include either a network address for routing, a request for default routing (default routing is specified by the DAP) , or a request for call treatment. Information objects are not part of the same inheritance tree as the other call processing objects. They are independently accessible from separate lookup tables in the OODB. This allows for information objects, which represent the results of call processing, to be quickly modified by network configuration data input from the FOE

Workstations 20.

OOT provides other desirable features for call processing. Data encapsulation insulates the internal structures and algorithms of a call processing node. This allows for a feature to change its internal algorithms for processing information without affecting other nodes that call it or the nodes that it in turn calls. Thus, each and any node may be modified without affecting the rest of call processing. This is not possible in the prior art, which utilizes iterative hashing and table lookups.

The call processing nodes exhibit independent behavior. This means the nodes are autonomous, not needing information from other features to do their work. In this manner, a call processing node does not care how it was called, nor does it care about which node it is calling. It only needs to know how to do its processing, which is embedded in the object class definition. Call data, such as origination date/time, is obtained from a central data store, namely, a call record created internally in the FPTS memory from the GReq .

Figure 6a is an OMT diagram of an inheritance tree, showing the associations among the various call processing object classes. The representation of Figure 6a is not equivalent to the call processing node tree shown in Figure 4. The inheritance tree of Figure 6a shows how the object classes that form the call processing nodes are defined. In conventional OMT notation, which is well known to those skilled in the art, each box is a defined object class. Triangles represent inheritance from a single base class to one or more derived classes. Solid balls represent multiplicity, with the ball being on the multiple class end. Diamonds represent aggregation (components to an assembly) and are on the assembly end.

Referring to Figure 6a, each class inherits attributes from the base class CpNode 94. From the CpNode class 94, two sub-classes, CpFeature 96 and CpEndNode 98 inherit. CpEndNode class 98 is for end nodes in the call processing node tree. End nodes indicate that call processing has reached a termination point. A CpEndNode object will contain a pointer to a Cplnfo object. The Cplnfo object contains the information needed to determine the termination type for a call. Cplnfo classes are part of a different inheritance tree. This tree and the association between CpEndNode and Cplnfo classes are shown in Figure 6b. With continued reference to Figure 6a, the CpFeature class 98 is the base class for the features that determine routing in a call flow, such as DOW, DOY, TOD, Egress, Access, etc. If additional features are to be defined, they will inherit from the CpFeature base class. From the

CpFeature class 98, three subclasses - CpRangeFeature 100, CpIndexFeature 102, and CpBinSortFeature 104 - inherit.

CpRangeFeature 100 is the base class for features that may be specified by ranges. These include day-of-year (DOY) , time-of-day (TOD) , and random percent allocation

(RPA) . Generally, routing decisions for these features are stated as ranges; for example, TOD values may be stated as 00:00 - 09:59, 10:00 - 12:59, 13:00 - 19:59, and 20:00 - 23:59. The subclasses of CpRangeFeatures 100 are CpDOY 106, CpTOD 108, and CpRPA 110. Of course, additional subclasses may be added. The pointers for these subclasses are kept in arrays, in which a pointer to a specific object is specified for a value range in the array.

CpIndexFeature 102 is the base class for features that may be specified by an index value. While DOY, TOD, and RPA may fit this category, it is more appropriate for features like day-of-week (CpDOW) 112, which only has seven values. Other subclasses are CpEgress 114, which determines type of network facilities (dedicated vs. shared) used to terminate a call, and CpAccess 116, which determines type of network facilities used to originate a call.

CpBinSortFeature 104 is the base class for features that map a Binary Coded Decimal (BCD) to a value. A BCD is a binary notation for a decimal number in which each digit is represented by a 4-bit sequence, or nibble. The number 7135551212 is represented in BCD by 10 nibbles, or 40 bits. Features that may utilize this include country of origination or termination, and carrier. This is because country codes that identify countries and carrier codes that identify carriers are included in the Call Record. These codes are in BCD format and may be mapped to a value in an array that identifies a pointer, based on the country or carrier represented. Therefore, the subclasses CpCountry 118 and CpCarrier 120 inherit from CpBinSortFeature 104.

Another subclass that inherits from CpBinSortFeature 104 is CpWZlSub 122, which represents a value for countries in what is defined as World Zone 1 (WZ 1) . Countries in WZ 1 include the United States, Canada, and various Caribbean islands. Currently, countries in WZ1 all use the same country code (1) . It may be desirable to distinguish routing based on the origination or termination within different WZ1 countries and Caribbean islands. Therefore, pseudo-country codes (PCCs) are assigned. In this manner, the CpWZl subclass serves many of the same features as the CpCountry class 118.

Some boxes in Figure 6a are identified as arrays with predetermined sizes and have the format ***_tp<***>. These represent values of array sizes that are determined when the classes are defined. The arrays are used as attributes in feature classes. They embody the various object pointers as array values. The actual sizes of these arrays are determined at compile time; a specific value is given during the declaration of the class. Therefore, in Figure 6a, these boxes represent these values which must be passed on to the subclasses during compile time. For example, the box identified as CpIndexFeature_tp<egressLngth> 124 represents a value for the array size of the array that will be used as a pointer in the subclass CpEgress 114; egressLngth is the constant that actually defines the array size. Figure 6b is an OMT diagram of another inheritance tree, showing the associations among classes that inherit from information objects. The information object class is named Cplnfo 126. Cplnfo 126 is associated with the CpEndNode class 96, but is from a different inheritance tree. In this way, Cplnfo 126 and its subclasses may be modified without affecting the CpNode class 94 and its subclasses from the call processing inheritance tree of Figure 6a. The association of the CpEndNode class 96 with the

Cplnfo class 126 is in the form of a pointer within the CpEndNode class 96. Each CpEndNode may be pointed to by zero, one, or multiple CpFeature nodes. However, a Cplnfo node must be pointed to by exactly one CpEndNode. The Cplnfo 126 classes specify how a call is to be treated or routed on the switch network 10. Three subclasses inherit from the Cplnfo 126 base class: CpRteDefault 128, CpRteTreatment 130, and CpRteSCP 132. The CpRteDefault 128 class specifies that default routing is to be used on the call. Default routing is as specified in the NCS DAP 12. CpRteTreatment 130 class specifies that a treatment is to be applied to the call at the Switch 10. For example, a treatment may be a voice recording that informs the caller the call cannot be completed. CpRteSCP 132 class specifies a particular network address to route the call to.

The CpRtelnfoTbl 134 is a hash table that contains pointers to all Cplnfo nodes, which contain all default routing instructions, call treatment instructions, and network addresses for FPD-specified routing.

Figure 7 is a use case showing call processing on the FPD platform. The entities represented include 800 Gateway, which is equivalent to the NCS DAP 12. In this example, the NCS TS for 800 (32c from Figure 2) has received the initial switch query, and a gateway to this component is used to pass the query on to the FPTS 14. CP Application is the Cp 46 component of the FPTS 14, shown in Figure 3. CpCallResp is the call processing object class for the Generic Response message 58 generated by Cp 46 of the FPTS 14. CpDOY is the call processing object class for the day-of-year features (CpDOY 106 of Figure 6a) . CpDOW is the call processing object class for the day-of- week features (CpDOW 112 of Figure 6a) . CpTOD is the call processing object class for the time-of-day features (CpTOD 108 of Figure 6a) . CpCallRec is the call processing object class for the Call Record 54 created by Cp 46 from the GReqM, as shown in Figure 3. Call Record 54 is used by the call processing features to obtain call data. CpTermNode is equivalent to CpEndNode 96 of Figure 6a, the final node of call processing that contains a pointer to a CpInfoNode 126, as shown in Figure 6b. Referring now to Figure 7, a call request (GReqM) is sent from 800 Gateway (DAP) to CpApplication. Cp Application builds a Call Record (CpCallRec) and performs call processing by making a routing decision based on the day of year of call origination. CpDOY queries the CpCallRec for the day of year of call origination and

CpCallRec responds with an answer "36." CpDOY determines from its array attribute that since DOY=36, a pointer to CpDOW is used. Then, CpDOW queries CpCallRec for the day of week of call origination. CpCallRec responds with an answer, "Wednesday." CpDOW determines from its array attribute that since DOW=Wednesday, a pointer to CpToD is used. CpTOD queries CpCallRec for the time of day of call origination. CpCallRec responds with an answer, "0347. " CpTOD determines from its array attribute that since TOD=0347, a pointer to CpTermNode is used. CpTermNode returns with specific instructions for call routing, based on information received from the Info node it pointed to. Control is returned to Cp Application and Cp Application builds a GResM (CpCallResp) . Cp Application sends the GResM (CpCallResp) to the 800 Gateway (DAP) . Referring now to Figure 9, the Service Creation Environment (SCE) of the FPD platform is provided by one or more FOE Workstations 20. Workstations 20 operate on standard PCs running conventional operating systems such as Windows 3.11, Windows 95, or Windows NT. The FOE Workstation 20 provides a graphical presentation that is used to create call flows. This may be built, as in the preferred embodiment, with VisualAge (TM) . VisualAge is an IBM product that provides an 00 visual application development environment . IBM VisualAge allows the user to develop applications by visually arranging and connecting both prefabricated and customized parts. It uses and includes Smalltalk, an 00 programming language. The FPD application that operates on the FOE Workstations 20 does so in a Smalltalk environment.

Figure 8 is an illustration of a sample screen from a FOE Workstation 20. Figure 8 shows a call flow builder that is used for building customer call flows. In the example shown, a call flow for an LTRR application is being built. An LTRR call flow is built for a Revenue Owner, which is the carrier that originates the call . Revenue Owners are indicated with a "$" icon 140. In the example shown, MCI is the Revenue Owner. The left column 142 contains icons that represent the various features of a call flow. By clicking and dragging an icon over to the call flow node tree 144, the icon is put in place in the call flow. By selecting the icon, specific values for that feature may be designated.

For example, a globe represents a country or call origination/termination. By selecting a specific icon, the user may select whether it indicates a country of origination (a globe with an "0" in it) , a country of termination (a globe with an "T" in it) , or a point of entry country, which is the country where the call enters the network (a globe with a "P" in it) . Once the icon has been dragged onto the node tree, the user may also select which country is represented by double-clicking on the icon. Thus, the first node in the second level of the tree shown is for calls that originate in the United Kingdom 146. The first node in the third level is for calls that terminate in the United Kingdom or the United States 148.

A triangle with an incoming arrow represents access type, and may be specified as shared or dedicated. Thus, in the call flow of Figure 12, one access type is shared 150. A triangle with outgoing arrow represents egress type, and may be specified as shared with a dialing plan (DP) , shared without a DP, dedicated, or VNC. In Figure 12, one egress type is dedicated or VNC 152. Clock icons represent time- of-day features, calendars represent day-of-week features, and telephones represent the end nodes of the tree, in which explicit instructions for call routing are given. Other icons for other features not shown, such as call percent allocation, may be included.

End nodes may include a default routing request, as indicated by a telephone with a "D" 154 in it, or a specific termination, as indicated by the "Londonl" 156 specification in Figure 12. Other values may be specified in accordance with the application.

All the data that is needed to create any call flow is stored on the FOE Server 18. When a user logs onto an FOE Workstation 20, their access is validated by the FOE Workstation 20. The user then selects which application they wish to build a call flow for. Based on this selection, the FOE Server 18 will upload all data needed for such an application. This includes values for each icon/feature selected. When the user completes a call flow, the FOE Server 18 validates it to ensure all default options are specified, all parameters are specified for range features (for example, it validates that if DOW feature is used, all seven days of the week are accounted for in the call flow), and each type of feature (DOW, TOD, etc.) is traversed only once on any single branch of a tree (for example, to prevent a DOW decision from being made twice in the same branch) . When validated, the call flow is downloaded to the FOE

Server 18, which stores the flow in the centralized OODB. The call flow is stored as a collection of associated objects .

Figure 9 illustrates the internal architecture of the FOE Server 18, and its interfaces with the FOE Workstations 20 and the FPTS 14. In the preferred embodiment of the present invention, the FOE Server 18 and Workstations 20 interact in a client/server model using DEC'S ObjectBroker (OBB) . OBB is an interprocess communications product that allows data to be passed between different operating environments . OODB 162 is a memory-cached disk-resident database on the FOE Server 18. OODB 162 is the database of record for the entire FPD platform. In the preferred embodiment, OODB 162 is implemented with ObjectStore, an object oriented database product commercially available through Object Design Inc., of Burlington, MA.

FPTS Data Distributors 164 are used to distribute data from OODB 162 to multiple FPTSs 14. Data distribution is performed by copying records from the local OODB 162 (on the FOE server 18) to the remote database on the FPTS 14. This copy utilizes ObjectStore mechanisms which make the remote database appear no different to the data distributor than the local database; that is, the data distributor simply manipulates objects in the databases (in this case, calling a method on the object in the FOE server database to create a copy of itself in the FPTS database) . A safe-stored queue 166 on the FOE server 18, which is managed by a queue manager 168, is used to indicate to the data distributors that updates need to be distributed; the records in this queue contain references to the trees that have changed, along with a mask. A mask is a series of bits, with each bit having one-to-one correspondence with an FPTS. Prior to data distribution, each bit is set to "1". When an FPTS successfully receives the record, the bit is flipped to "0" On the FPTS 14, these trees are placed in CpDb 56, shown in Figure 3. The trees are then available for call processing.

From the foregoing, it may be seen that the present invention provides object oriented call processing. The FPD platform allows fast product development by reducing the time to market for new products from about 54 weeks to 3-4 months. It provides a platform for meeting regulatory routing requirements while taking advantage of least cost routing features. The present invention simplifies product development, and allows products to be created and modified easily by non-programmers. It can process equal or greater transactions per second (TPS) , on the same type of processor, as the existing NCS platform. It can be built with commercially available, off-the-shelf products, which minimizes vendor costs.

Claims

WHAT IS CLAIMED IS:

1. A telecommunications system service creation platform, which comprises: an order entry server, said order entry server including a central object oriented database for storing call flows; a plurality of order entry workstations in communication with the order entry server, each said order entry workstation including means for creating call flows; and, a plurality of product transaction servers in communication with said order entry server, each said product transaction server including means for processing requests for call routing instructions according to call flows .

2. The service creation platform as claimed in claim 1, including means for downloading call flows from said order entry workstations to said order entry server.

3. The service creation platform as claimed in claim 1, including means for validating call flows created with said order entry workstations.

4. The service creation platform as claimed in claim 1, including means for uploading from said order entry server to said order entry workstations data needed by said order entry workstations in completing call flows.

5. The service creation platform as claimed in claim 1, including means for downloading call flows from said order entry server to said product transaction servers.

6. The service creation platform as claimed in claim 1, wherein said means for creating call flows includes graphical user interface means for enabling a user to create call flows by arranging and connecting icons.

7. The service creation platform as claimed in claim 1, wherein each product transaction server includes an object oriented database for storing call flows.

8. The service creation platform as claimed in claim 7, including means for updating call flows stored in the object oriented databases of the product transaction servers in response to changes in call flows stored in said central object oriented database.

9. The service creation platform as claimed in claim 8, wherein said means for updating call flows stored in the object oriented databases of the product transaction servers, includes: a queue in said order entry server, said queue containing records referring to changes in call flows stored in said central object oriented database and a record of which product transaction servers have received said records .

10. A system for processing calls, which comprises: a network control system, said network control system including: a plurality of data access points, said data access points receiving, processing and responding to queries for routing instructions from network switches ; a network control system order entry system for receiving system configuration data; and, a service control manager for converting system configuration data received at said network control system order entry system to a format readable by said data access points; a service creation platform, said service creation platform including: a plurality of product transaction servers in communication with said data access points, each said product transaction server including means for processing requests for call routing instructions according to object oriented call flows; an order entry server in communication with each of said product transaction servers, said order entry server including a central object oriented database for storing call flows; and, a plurality of order entry workstations in communication with the order entry server, each said order entry workstations including means for creating call flows.

11. The system as claimed in claim 10, wherein each of said data access points includes: a plurality of communications servers for receiving queries from and sending responses to said network switches ; and, a plurality of network control system transaction servers for processing queries for routing instructions received from said network switches.

12. The system as claimed in claim 11, wherein said product transaction servers are in communication with said network control system transaction servers and said network transaction servers include means for sending request for routing instructions to said product transaction servers.

13. The system as claimed in claim 10, wherein said service control manager of said network control system is in communication with said order entry server.

14. The system as claimed in claim 10, wherein said service creation platform includes means for downloading call flows from said order entry workstations to said order entry server.

15. The system as claimed in claim 10, including means for validating call flows created with said order entry workstations .

16. The system as claimed in claim 10, including means for uploading from said order entry server to said order entry workstations data needed by said order entry workstations in completing call flows.

17. The system as claimed in claim 10, including means for downloading call flows from said order entry server to said product transaction servers.

18. The system as claimed in claim 10, wherein said means for creating call flows includes graphical user interface means for enabling a user to create call flows by arranging and connecting icons.

19. The system as claimed in claim 10, wherein each product transaction server includes an object oriented database for storing call flows.

20. The system as claimed in claim 19, including means for updating call flows stored in the object oriented databases of the product transaction servers in response to changes in call flows stored in said central object oriented database.

21. The system as claimed in claim 20, wherein said means for updating call flows stored in the object oriented databases of the product transaction servers, includes: a queue in said order entry server, said queue containing records referring to changes in call flows stored in said central object oriented database and a record of which product transaction servers have received said records .

22. A call processing system, which comprises: an object oriented database containing call processing rules, said object oriented database including a plurality of hierarchically related nodes defining said call processing rules; and, a call processing application for creating call records from generic request messages, and applying processing rules to said call records to formulate generic response messages .

23. The system as claimed in claim 22, wherein said object oriented database includes a call processing node class and a call processing information class.

24. The system as claimed in claim 23, wherein said call processing information class includes: a call processing default routing subclass; a call treatment subclass; and, a call processing service control point routing subclass .

25. The system as claimed in claim 23, wherein said call processing node class includes a call processing feature class and a call processing end node class.

26. The system as claimed in claim 25, wherein said call processing feature class includes: a call processing range feature subclass for features that are specified by ranges of values; a call processing index feature subclass for features that are specified by index values; and, a call processing binary sort feature subclass for features that are specified by numerical values.

27. The system as claimed in claim 26, wherein at least some of said nodes of said call processing feature class include pointers to other nodes of said call processing feature class .

28. The system as claimed in claim 27, wherein at least some of said nodes of said call processing feature class include pointers to nodes of said call processing end node class.

29. The system as claimed in claim 28, wherein each node of said call processing end node class includes a pointer to a single node of said call processing information class.

30. The system as claimed in claim 29, wherein said call processing application accesses said object oriented database by generating a key from a call record, said key serving as a pointer to a particular node of said call processing node class, said particular node serving as a base node for a call processing node tree.

31. The system as claimed in claim 30, wherein said call processing node tree is traversed by object pointer navigation, based on said call record, from said base node to a particular node of said call processing end node class.

32. The system as claimed in claim 31, wherein said call processing application formulates said generic response message from the single node of said call processing information class pointed to by said particular node of said call processing end node class.

33. A call processing platform, which comprises: a communications manager for routing generic request messages from a data access point to a call processing mailbox, and routing generic response messages from a communications manager mailbox to said data access point; a call processing distributor for distributing generic request messages from the call processing mailbox to a call processing queue, and for distributing response messages from a response mailbox to the communications manager mailbox; and, a call processing application for receiving generic request messages from the call processing queue, creating call records from the generic request messages, applying call processing rules to said call records to formulate generic response messages, and sending said generic response messages to said response mailbox.

34. The platform as claimed in claim 33, wherein said call processing rules are stored in an object oriented database, said object oriented database including a plurality of hierarchically related nodes, said object oriented database including a CpNode class and a Cplnfo class, said CpNode class including a CpFeature class and a CpEndNode class, wherein at least some of said nodes of said CpFeature class include pointers to other nodes of said CpFeature class, and at least some of said nodes of said CpFeature class include pointers to nodes of said CpEndNode class, and wherein each node of said CpEndNode class includes a pointer to a single node of said Cplnfo class.

35. The platform as claimed in claim 34, wherein: said call processing application accesses said object oriented database by generating a key from a call record, said key serving as a pointer to a particular node of said call processing node class, said particular node serving as a base node for a call processing node tree; said call processing node tree is traversed by object pointer navigation, based on said call record, from said base node to a particular node of said call processing end node class; and, said call processing application formulates said generic response message from the single node of said call processing information class pointed to by said particular node of said call processing end node class, and information contained in said call record.

36. A method of processing telephone calls, which comprises the computer implemented steps of : receiving a generic request message for call processing information; creating a call record from said generic request messages ; accessing an object oriented database containing call processing rules, said object oriented database including a plurality of hierarchically related nodes defining said processing rules; and, applying processing rules of said object oriented database to said call record to formulate a generic response message containing call processing information.

37. The method as claimed in claim 36, wherein said object oriented database includes a call processing node class and a call processing information class.

38. The method as claimed in claim 37, wherein said call processing node class includes a call processing feature class and a call processing end node class.

39. The method as claimed in claim 38, wherein at least some of said nodes of said call processing feature class include pointers to other nodes of said call processing feature class .

40. The method as claimed in claim 39, wherein at least some of said nodes of said call processing feature class include pointers to nodes of said call processing end node class.

41. The method as claimed in claim 40, wherein each node of said call processing end node class includes a pointer to a single node of said call processing information class.

42. The method as claimed in claim 41, wherein said call processing application accesses said object oriented database by generating a key from a call record, said key serving as a pointer to a particular node of said call processing node class, said particular node serving as a base node for a call processing node tree.

43. The system as claimed in claim 42, wherein said call processing node tree is traversed by object pointer navigation, based on said call record, from said base node to a particular node of said call processing end node class.

44. The system as claimed in claim 43, wherein said call processing application formulates said generic response message from the single node of said call processing information class pointed to by said particular node of said call processing end node class, and from information contained in said call record.