Abstract:
The present invention provides a system and method for achieving local number portability. Local number portability is a feature that allows a customer desiring to change local telephone service to maintain the same telephone number regardless of the service. To achieve local number portability, the present invention maintains and manages a communication scheme between and among regional telephone service providers throughout the country. The present invention includes interface applications between the invention and regional providers, regional telephone data repositories, invention telephone data repositories, and downstream data processing applications. The present invention is particularly directed towards the interface between the present scheme and the downstream processing applications. The interface includes subsystems which assist in communicating data records between the present scheme telephone data repositories and the downstream applications. The data records include, for example, activated, deactivated and modified telephone numbers.

Description:
This is a continuation of application Ser. No. 08/897,906 filed Jul. 21, 1997 entitled “System and Method for Achieving Local Number Portability.” 
    
    
     FIELD OF THE INVENTION 
     The present invention relates in general to the field of telecommunications and more specifically to a system and method for a that allows a telephone data repository to communicate with an external system. The external system includes at least one data processing application. The present invention includes a system having an universal interface arrangement that facilitates communication between a telephone data repository and the data processing applications such that additional data processing applications can be added or subtracted without having to change the existing code of the present invention. 
     BACKGROUND OF THE INVENTION 
     Without limiting the invention, its background is described in connection with local telephone services and providers of such services. In general, the telecommunications industry has evolved into a highly competitive and sophisticated network of equipment manufacturers and service providers. Since the early 1980s, the industry has seen a shift from pure analog techniques over copper wire to digital techniques over optical fiber. Today, customers can choose from a large array of consumer telecommunications services including local and long distance calling, 800 and 900 calling accounts, TCP/IP (i.e. the “Internet”) and others. 
     Typically, a telecommunications customer obtains access to such services by establishing an account with a service provider. The service provider, in turn, will assign to the customer a telephone number for inbound calls or provide the customer with a dial-up number for outbound calls. For example, the number can be the local telephone number where the customer can be reached such as a home or business. The number can also be the local dial-in to an automated system for a switched connection to a network element such as a domain server. Other examples include, but are not limited to, a customer&#39;s facsimile machine, cell phone number or voice mail. 
     At the same time industry deregulation has brought about the entry of multiple service providers within single geographic regions. In addition to competition, the number and variety of telecommunications services continues to increase. Typically, a category of service is tied to a single unique number so that any one customer may consume a host of numbers to accommodate a host of services. Thus, a common situation has evolved wherein a single customer will have a home number, an office number, a facsimile machine number, a cell phone number, an Internet account number and possibly others. 
     Today&#39;s service providers employ advanced information technology systems using sophisticated equipment such as routers, switches and digital cross-connects. At a minimum, the equipment must be configured to ensure calls reach their destination regardless of the service provider. While standards and communications protocols have been adopted by the industry, cooperation amongst service providers has been critical to implementing a reliable network. Today, a customer can place a clear noise free call from almost anywhere in the world. 
     The Public Switched Telephone Network (“PSTN”) comprises the telecommunications backbone for most voice/data traffic in the world. For most local and long distance telephone calls a local telephone company acts as a local entry point to the PSTN. Typically, a Local Routing Number (“LRN”) is used to route the call from a point of origination to a point of destination on the PSTN. This is true regardless of who is servicing the call at either point. 
     This infrastructure, however, does not always accommodate a change in the service needs of an end customer. For example, often a customer desires to switch service providers to take advantage of a more attractive rate plan. The problem lies in that the customer is not guaranteed to maintain the same local number even if the customer remains at the same location. Thus, until the present invention, there was no way to port a customer&#39;s number from one service provider to another within the same local region. 
     In short, as competition for communications services has grown so has the value attached to a customer&#39;s telephone number. At present, call routing is based on a number associated with the switch used to handle the local call. Moreover, service providers have not developed a means for reliable call routing when a switch from one provider to another is made. Until the present invention, the only solution was to assign a new telephone number not already in use by another customer. 
     While long distance carriers have enacted portability solutions on a regional or even national basis for certain classes of services, such as 800 and 900 accounts, the local portability problem has not, until the present invention, been squarely addressed. Moreover, prior art efforts at local number portability have not been widespread. For example, an industry task force was formed, pursuant to the Illinois Commerce Commission Order on Customers First Plan (Docket 94-0096 dated Apr. 7, 1995), to develop a permanent number portability solution for Illinois. While the task force made progress in defining the problem and resolving certain issues related to implementing local number portability, it did not resolve the problem on a nationwide basis. Nor did the commission establish the hardware and software interfaces required to implement a nationwide portability solution. 
     Thus, a need exists for a system and method of achieving local number portability on a nationwide basis. A system and method of sharing a single telephone number over different local exchange carriers would fill a void not presently addressed by the prior art. 
     SUMMARY OF THE INVENTION 
     The present invention provides a system and method for facilitating communication between a telephone data repository and downstream data processing applications. The system includes a data distribution subsystem and interface subsystem in communication and positioned between the repository and the downstream applications. The subsystems include data pipes dedicated for each downstream application. The method includes reading data messages from the repository, formatting messages and routing the same to the downstream applications. In addition the method includes reading messages from the applications and routing same to the repository. 
     The present invention provides a hardware and software platform to effect the porting of local telephone numbers from one service provider to another. The systems and subsystems of the invention are designed to communicate with a Number Portability Administration Center and Service Management System (“NPAC/SMS”) which receives and stores updated customer routing information and makes it available to participating service providers. The NPAC/SMS contains a record of all ported numbers and a history file of all transactions relating to the porting of a number. 
     The present invention provides a system for Local Number Portability (“LNP”) that submits service orders changes to a NPAC/SMS. In this regard, a Service Order Administration (“SOA”) Subsystem is provided as means of entering and submitting services order changes to the NPAC/SMS via an interface that supports the retrieval and update of subscription, service provider and network information. A graphical user interface or a message-based interface to a service provider&#39;s upstream systems is used for this purpose. 
     For a more complete understanding of the present invention, including its features and advantages, reference is now made to the following detailed description, taken in conjunction with the accompanying drawings. 
    
    
     BRIEF DESCRIPTION OF THE DRAWINGS 
     FIG. 1 is an overall process flow diagram for the method used to transfer a customer&#39;s port data from an old service provider to a new service provider according to one embodiment of the invention; 
     FIG. 2 is a high level block diagram for the interface between a Service Order Administration (“SOA”), an Interface Broadcast Agent (“IBA”) and a regional number portability administration center according to one embodiment of the invention; 
     FIG. 3 is a block diagram of the SOA and IBA Subsystems and their interface to various business applications; 
     FIG. 4 is a block diagram of an alternative embodiment of the present invention with a National Network Management Center; 
     FIG. 5 is a block diagram of an SOA broken down into its component subsystems according to one embodiment; 
     FIG. 6 is a block diagram of the IBA broken down into its component subsystems according to one embodiment; 
     FIG. 7 is a block diagram of the IBAR broken down into its component subsystems according to one embodiment; 
     FIG. 8 is a block diagram of the SOA Engine broken down into its component subsystems according to one embodiment; 
     FIG. 9 is a block diagram of the NNMC GUI Subsystem according to one embodiment; and 
     FIGS. 10,  10 A,  10 B,  10 C,  10 D,  10 E,  10 F,  10 G,  10 H and  10 I are flow charts for various processes in the Emulator Subsystem according to one embodiment. 
    
    
     Corresponding numerals in the drawings refer to corresponding parts unless otherwise indicated. 
     DETAILED DESCRIPTION OF THE INVENTION 
     Throughout the following description, the terms “interface”, “line”, “lines”, “link”, “communications link”, “inbound link” and/or “outbound link” can mean a channel, signal pathway, data path, circuit, or other similar mechanism whether physical, virtual or logical, which can be used for the transfer and communication of data by system applications and programs, whether external or internal. The terms “outbound link” and “inbound link” can also mean “pipes” in the context of the Oracle database structure and associated protocols, or “sockets” in the context of the Unix operating system structure and associated protocols. Such conventions are well known to those skilled in the art. 
     Turning now to FIG. 1, a flow diagram of a telephone number porting process, denoted generally as  20 , is shown. In general, the telephone number porting process  20 , which achieves Local Number Portability (“LNP”), is used by a customer  22  to port or transfer his or her telephone number from an old service provider  24  to a new service provider  26 . The customer  22  initiates the telephone number porting process  20  by submitting a port request to either the old service provider  24  as denoted by line  32 , or the new service provider  26  as denoted by line  34 , to arrange the port or transfer of the customer&#39;s telephone number from the old service provider  24  to the new service provider  26 . Thereafter, the old service provider  24  and new service provider  26  arrange the port details for the customer&#39;s telephone number as denoted by line  36 . 
     Once the new service provider  26  obtains the customer&#39;s port request, the new service provider  26  notifies a Number Portability Administration Center and Service Management System (“NPAC/SMS”)  30 , which maintains a centralized regional number database for all customers in a given region, of the pending port as denoted by line  38 . Alternatively, the old service provider  24  can notify the NPAC/SMS  30  of the pending port as denoted by line  41 . 
     When the NPAC/SMS  30  receives the notification it performs certain validation checks. If the NPAC/SMS  30  only received a notification from one of the involved service providers, either the old service provider  24  or the new service provider  26 , will notify the service provider that failed to sent a notification that the NPAC/SMS  30  is expecting such a notification. If the NPAC/SMS  30  receives the missing notification and the notifications from the two service providers  24  and  26  indicate agreement, the NPAC/SMS  30  activates the port of the customer&#39;s telephone number when the new service provider due date is reached or the new service  26  provider sends and activation notice to the NPAC/SMS  30 . The NPAC/SMS  30  activates the port of the customer&#39;s telephone number by sending the new port data to the old service provider  24  as denoted by line  40 , the new service provider  26  as denoted by line  42 , and all other service providers  28  as denoted by line  44 . This ensures proper call routing to the customer because all the service providers in the region  24 ,  26 , and  28  can update their networking equipment accordingly. 
     If during the validation process described above the old service provider  24  failed to respond, the NPAC/SMS  30  will log the failure to respond and allow the new service provider  26  to proceed with the port when the due date is reached. On the other hand, if it was the new service provider  26  that failed to respond, the NPAC/SMS  30  will log the failure to respond, cancel the notification and notify both service providers  24  and  26  of the cancellation. If there is any disagreement among any of the service providers  24 ,  26  or  28  as to who will provide the new service to the customer  22 , the NPAC/SMS  30  will place the notification in a “conflict” state and notify the conflicting service providers  24 ,  26  or  28  of the conflict status. The conflicting service providers  24 ,  26  or  28  will determine who will serve the customer  22  using appropriate internal conflict resolution procedures. If the conflict is resolved, the NPAC/SMS  30  will remove the notification from the “conflict” once it is notified of the resolution and the process proceeds normally as described above. Alternatively, the new service provider  26  can cancel the port request. 
     The present invention incorporates significant advantages over the prior art in that it allows for the sending and receiving of porting data from regional databases, which are maintained at the NPAC/SMS  30 , and provides a smooth transition from the old service provider  24  to the new service provider  26 . 
     Turning now to FIG. 2, a block diagram of a system for achieving local number portability is shown and denoted generally as  46 . The NPAC/SMS  30  is communicably linked to two functional subsystems, a Service Order Administration (“SOA”) Subsystem  48  and an Interface Broadcast Agent (“IBA”) Subsystem  50  via communication interfaces  52  and  54 , respectively. 
     The SOA Subsystem  48  is the application responsible for sending the customer&#39;s port data from one service provider to another service provider. Likewise, the IBA Subsystem  50  is the application responsible for receiving, processing, storing and transmitting customer port data to the local networks. The SOA  48  and IBA  50  Subsystems work together with the NPAC/SMS  30  to send and receive customer porting data from regional call routing centers and data sources to more centralized information sources and applications. This configuration  46  provides a distributed architecture that allows the porting of data to the local applications and networking equipment maintained by service providers for appropriate call routing and processing. 
     The SOA Subsystem  48  is communicably linked to one or more local applications  56 , which are maintained by the local service provider. Examples of the local applications  56  include, but are not limited to, residential and business lines for voice, data and fax communications. The local applications  56 , in turn, are communicably linked and used by the customer Order Entry and Order Processing (“OE/OP”) systems of other service providers  58 , other Complex Local Exchange Carriers (“CLEC”)  60 , and other Local Exchange Carriers (“LEC”)  62 , depending on the existing network of service providers. The SOA Subsystem  48  acts as an intermediary between the local applications  56  and the NPAC/SMS  30 , thus providing a smooth non-intrusive solution for local number portability. 
     Likewise, the IBA Subsystem  50  provides the interface between the regional NPAC/SMS  30  and a plurality of other network entry systems  64 ,  66  and  68 . The specific functionality of the network entry systems  64 ,  66  and  68  may vary, but in general, they form a platform for receiving, storing, and routing customer port data. Examples of services that use the port data include local and long distances networks and 800 services. 
     For example, business applications  68  can comprise a database of records for all provider systems needing access to the customer porting data, such as the Automatic Number Identifier (“ANI”) reference information system. The local network interfaces  66  can be an intelligent network architecture that supports routing queries during call processing. The network interface  64  can include the Metro Intelligent Network Architecture that forms a tie-in into available communications services. Such services may include an 800 or 900 service or other similar offerings that may require access to the port data through a regional toll switch network from the NPAC/SMS  30  for correct call servicing and routing. 
     Turning now to FIGS. 3 and 4, the interaction between the NPAC/SMS  30 , the SOA Subsystem  48  and the IBA Subsystem  50  will be described. The Local Number Portability System of FIG. 3 is denoted generally as  70 , whereas the Local Number Portability System of FIG. 4 is denoted generally as  92 . Local Customer Order Entry and Order Processing (“OE/OP”) Systems (collectively referred to as the “Front End”)  78  send and receive LNP transactions or messages to and from a local SOA Engine  80 , which is an interface that routes the LNP transactions or messages to their appropriate destinations, such as the Regional SOA Subsystems  72  located in various parts of the country. In the case of FIG. 4, the SOA Engine  80  also receives and sends LNP transactions or messages from and to a SOA Graphical User Interface (“GUI”)  94 , and routes database queries to the RIBA  76  and IBAR  86  Subsystems. The Regional SOA  72  and SOA Engine  80  Subsystems form the SOA Subsystem  48 , which provides the means for submitting customer service order changes to the Regional NPAC/SMSs  74 . 
     Each Regional SOA Subsystem  72  is connected to a corresponding Regional NPAC/SMS  74  by communication interface  82 , and all of the Regional NPAC/SMSs  74  form the NPAC/SMS  30 . Similarly, each Regional NPAC/SMS  74  is connected to a corresponding RIBA Subsystem  76  by communication interface  84 . Communication interfaces  82  and  84  conform to recognized industry standards, such as the North American Council Functional Requirements Specifications and the current version of the “NPAC/SMS Interoperable Interface Specification” by Lockheed Martin IMS Corporation. Communication interface  82  utilizes a Common Management Interface Protocol (“CMIP”) and communication interface  84  utilizes both CMIP and File Transfer Protocols (“CFTP”). 
     Preferably some method of access control is provided to manage security issues that arise from communications between the SOA  32  and RIBA  34  Subsystems and the NPAC/SMS  74 . In one embodiment, an access control field is included in messages flowing between the SOA  32  and RIBA  34  Subsystems and the NPAC/SMS  74  and carries a digital signature. As is known by those skilled in the art, a digital signature is used for authentication purposes to guarantee the identity of the message sender. For example, the access control field can include the following information: 
     System ID: An identifier for the system that is using the interface. This is a key element in the authentication process. While it is passed in each Protocol Data Unit, it is only really important in the association establishment. 
     System Type: Identifies the kind of system that is connecting: SOA, IBA, SOA and IBA or NPAC. 
     User Id: An optional field that passes a user Id used mostly for logging. 
     List Id: This is an integer that identifies the list from which a key was chosen to create the signature. 
     Key Id: This is an integer that identifies which key from the 1000 keys in a list was used to generate a signature. 
     CMIP Departure Time: This is the time at which a message was sent. 
     Sequence Number: This is 32 bit unsigned integer that starts at 0 and is incremented until wrapping at the maximum value. 
     Signature: The signature field contains the MD5 hashed and encrypted System Id, the System Type, the User Id, the CMIP Departure Time, and Sequence Number without separators between those fields or other additional characters. Encryption is done using RSA encryption using the key from the key list specified. Validation of this field ensures data integrity and non-repudiation of data. 
     Association Functions: These are set of flags that are set when an association is established. 
     Recovery Mode: The recovery mode flag is used to recover after downtime. 
     The NPAC/SMS  30  then relays the port data in a predefined message format to the IBA Subsystem  50  through interfaces  84 . Like the SOA Subsystem  48 , the IBA Subsystem  50  comprises a plurality of Regional IBA Subsystems  76  that update a single IBAR Subsystem  86 . As shown in FIG. 3, the IBAR Subsystem  86  is accessible by a plurality of downstream applications, such as business applications  88 , and network provisioning and configuration systems  90 . It should be understood, however, that any type of downstream system can be connected to the IBAR Subsystem  86  at the option of the service provider. In this way the porting data is distributed to existing network applications, such as long distance and local business, for proper call routing and processing. Similarly, FIG. 4 depicts the IBAR Subsystem  86  sending LNP data to four specific Request Processing Applications ( 88  and  90  of FIG.  3 ): an ANI Reference Information System (“ARIS”)  96 . Metro Intelligent Network Administration Service Management System (“MINA/SMS”)  98 , Network Control System (“NCS”)  100  and Provisions Voice Network (“RTE7”)  102 . 
     Moreover, FIG. 4 depicts, several additional communication interfaces between the major subsystems of the LNP System  92 : database access interface  104  between the Regional SOA  72  and RIBA  76  Subsystems; database access interface  106  between the RIBA  76  and SOA Engine  80  Subsystems; and database access interface  108  between the SOA Engine  80  and IBAR  86  Subsystem. A National Network Management Center (“NNMC”)  110  is also shown. 
     The NNMC  110  is a stand-alone subsystem designed for basic querying of database information on the SOA  72  and IBAR  86  Subsystems. Accordingly, the NNMC  110  is connected through communication interfaces to the various databases in the LNP System  92 : the SOA Engine Subsystem  80  through database access interface  114 ; the SOA Subsystem  72  through database access interface  116 ; and the IBAR Subsystem  86  through database access interface  118 . An end-user can initiate a query using a NNMC GUI  112 , which is connected to the NNMC  110 . By entering a single telephone number and the database to query, either the SOA  126  (FIG. 5) or IBAR  172  (FIG. 7) Databases, an end-user can obtain such information as the LRN, effective date, service provider, action, status and telephone number range. 
     While FIGS. 3 and 4 depict the use of three (3) Regional SOA Subsystems  72 , three (3) Regional NPAC/SMSs  74 , and three (3) Regional IBA Subsystems  76 , it is envisioned that each region providing local number portability, regardless of number, will have a corresponding SOA Subsystem  72 . NPAC/SMS  74  and Regional IBA Subsystem  76 . Moreover, while FIGS. 2,  3  and  4  illustrate various embodiments for achieving local number portability, it should be understood that other architectures may be similarly conceived and reduced to practice upon reference to this disclosure. It is anticipated therefore, that such other embodiments are well within the scope and spirit of the present invention. For example, FIGS. 5 through 8 disclose a detailed architectural design, in the form of block diagrams, for various subsystems that may be used to achieve local number portability in a preferred embodiment of the present invention. 
     Turning now to FIG. 5, the SOA Subsystem  72  is shown broken down into its functional components. LNP transactions, also referred to as messages or requests, originating either from the SOA Engine Subsystem  80  or an SOA GUI  94  are received through stored procedures  120 , such as those used in an Oracle database structure. The stored procedures  120  send the message through a single outbound link  122  to a SOA Message Handler  124 . Note that throughput can be increased by running multiple instances of the SOA Message Handler  124 , each instance receiving messages from the single outbound link  122 . 
     The SOA Message Handler  124  organizes and processes the messages by tasks that are preferably broken down at an object level, e.g., Subscription Version, Audit, Service Provider and Network. Based on a message identifier, the SOA Message Handler  124  queries the SOA Database  126  to collect and assemble any additional information required by the NPAC/SMS  74 . The SOA Message Handler  124  then sends the message to the CMIP Manager  128 , which is a distributed systems generator that implements the interface between the SOA Subsystem  72  and the NPAC/SMS  74 , and waits for a response from the CMIP Manager  128 , such as success, failure or timeout. The CMIP Manager  128  then logs and sends the message to the NPAC/SMS  74 . 
     When the CMIP Manager  128  receives a response from the NPAC/SMS  74 , the response is routed to the SOA Message Handler  124 , which processes any information received with the response and updates the SOA Database  81  when required. The SOA Message Handler  124  then sends the response through an inbound link  130  to the stored procedures  120  and out to the originating SOA Engine Subsystem  80  or SOA GUI  94 . All output to the stored procedures  120  is done through separate inbound links  130 , one for each SOA GUI  96 . 
     The SOA Database  126  is used to store and maintain the current telephone number information for a customer. Table 1 below is domain field listing for an SOA Database  126  according to one embodiment: 
     
       
         
               
             
               
               
               
               
             
           
               
                 TABLE 1 
               
             
             
               
                   
               
               
                 Domain List for one Embodiment of the SOA Database 126. 
               
             
          
           
               
                 Name 
                 Code 
                 Label 
                 Type 
               
               
                   
               
               
                 BillingIdentifier 
                 BILLING_ID 
                 Billing Identifier 
                 VARCHAR2(4) 
               
               
                 BooleanIndicator 
                 BOOL_IND 
                 Boolean Indicator 
                 NUMBER(1) 
               
               
                 City 
                 CITY 
                   
                 VARCHAR2(20) 
               
               
                 CLASS DPC 
                 CLASS_DPC 
                   
                 VARCHAR2(9) 
               
               
                 CLASS SSN 
                 CLASS_SSN 
                   
                 NUMBER(3) 
               
               
                 CNAM DPC 
                 CNAM_DPC 
                   
                 VARCHAR2(9) 
               
               
                 CNAM SSN 
                 CNAM_SSN 
                   
                 NUMBER(3) 
               
               
                 Contact Type 
                 CONTACT_TYP 
                 Contact Type 
                 VARCHAR2(2) 
               
               
                 Country 
                 COUNTRY 
                   
                 VARCHAR2(20) 
               
               
                 EndUserLocationType 
                 END_USER_LOC_TYPE 
                   
                 VARCHAR2(2) 
               
               
                 EndUserLocationValue 
                 END_USER_LOC_VALUE 
                   
                 VARCHAR2(12) 
               
               
                 Identifier 
                 ID 
                   
                 NUMBER(10) 
               
               
                 Identifier 
                 ID2 
                   
                 NUMBER(10) 
               
               
                 ISVM DPC 
                 ISVM_DPC 
                   
                 VARCHAR2(9) 
               
               
                 ISVM SSN 
                 ISVM_SSN 
                   
                 NUMBER(3) 
               
               
                 LIDB DPC 
                 LIDB_DPC 
                   
                 VARCHAR2(9) 
               
               
                 LIDB SSN 
                 LIDB_SSN 
                   
                 NUMBER(3) 
               
               
                 LNPtype 
                 LNP_TYPE 
                   
                 NUMBER(1) 
               
               
                 LRN 
                 LRN 
                   
                 VARCHAR2(10) 
               
               
                 NPA NXX 
                 NPA_NXX 
                 NPA-NXX 
                 VARCHAR2(6) 
               
               
                 NPA NXX 
                 NPA_NXX2 
                 NPA-NXX 
                 VARCHAR2(6) 
               
               
                 OperationAction 
                 OPER_ACT 
                 Operation Action 
                 NUMBER(3) 
               
               
                 Postal Code 
                 PC 
                 Postal Code 
                 VARCHAR2(40) 
               
               
                 ServProvID 
                 SP_ID 
                   
                 VARCHAR2(4) 
               
               
                 ServProvID 
                 SP_ID2 
                   
                 VARCHAR2(4) 
               
               
                 StateProvince 
                 STATE_PROV 
                 State/Province 
                 VARCHAR2(2) 
               
               
                 Status 
                 STATUS 
                 Status Flag 
                 NUMBER(10) 
               
               
                 SystemType 
                 SYSTEM_TYPE 
                   
                 NUMBER(1) 
               
               
                 TelephoneNumber 
                 TN 
                 Telephone  
                 VARCHAR2(10) 
               
               
                   
                   
                 Number 
               
               
                 Timestamp 
                 T2 
                   
                 DATE 
               
               
                 Timestamp 
                 T 
                   
                 DATE 
               
               
                 TunableName 
                 TUNABLE_NAME 
                 Tunable Name 
                 VARCHAR2(40) 
               
               
                 TunableValue 
                 TUNABLE_VALUE 
                 Tunable Value 
                 VARCHAR2(40) 
               
               
                 UserIdentifier 
                 USER_ID 
                   
                 VARCHAR2(30) 
               
               
                 Zip 
                 ZIP 
                   
                 VARCHAR2(9) 
               
               
                   
               
             
          
         
       
     
     The Process Monitor creates separate instances, SOA Process Monitor  132  and RIBA Process Monitor  167 , which are the parent processes for the SOA  72  and RIBA  76  Subsystems and watch over all of the standard applications or processes required to run the Subsystems  72 ,  76 . The SOA Process Monitor  132  and RIBA Process Monitor  167  keep a table of all applications or processes spawned and operational information about each application, such as the exit status of each application. The SOA Process Monitor  132  does not, however, monitor the IBA Subscription Version Report  140  or the SOA Converter Process  142 . The SOA Process Monitor  132  starts applications when they are required and is notified if an application terminates. If an application, which is intended to always be running terminates, such as the CMIP Manager  128  and Check Link  134 , the The SOA Process Monitor  132  will automatically restart the terminated application. 
     A Resynch Subscription Version Process  136  is coupled to the SOA Database  126  and it is used to synchronize the SOA Subsystem  72  after a period of downtime. The Resynch Subscription Version Process  136  is started after the CMIP Manager  128  binds to the NPAC/SMS  74 . In operation, the Resynch Subscription Version Process  136  requests from the NPAC/SMS  74 , by way of the CMIP Manager  128 , all subscription versions that have a modification time-stamp more recent than the last time the CMIP Manager  128  had an association with the NPAC/SMS  74 . The Resynch Subscription Version Process  136  also sets a downtime flag in an audit database table to indicate that an audit was ongoing during a period of downtime. 
     The CMIP Manager  128  also receives notifications from the NPAC/SMS  74 . These notification transactions are sent to an Unsolicited Event Handler  138  which, in turn, processes the transactions and updates the SOA Database  126  when necessary. The Unsolicited Events Message Handler  138  waits for a message to be sent from the CMIP Manager  128 . When the Unsolicited Events Message Handler  138  receives a message from the CMIP Manager  128 , the Unsolicited Events Message Handler  138  determines the type of message and performs the required actions for that message type. When the action is complete, the Unsolicited Events Message Handler  138  formats and sends a reply to the CMIP Manager  128 , which translates the message into a CMIP event and sends the event to NPAC/SMS  74 . 
     The IBA Subscription Version Report  140 , which is monitored and controlled by the operator, is used to report discrepancies between the SOA Database  126  and the RIBA Database  144 , which is located in the Regional Interface Broadcast Agent (“RIBA”) Subsystem  76 . The Check Link  134  monitors the physical connection between the SOA Subsystem  72  and NPAC/SMS  74  so that if the physical connection is broken, the Check Link  134  will reset the SOA Subsystem  72 . 
     The SOA Converter Process  142  is a stand-alone process for NPA-NXX Split processing that performs a conversion of the telephone number value in the SOA Subscription Version table. Using tunable database links, the SOA Converter Process  142  accesses the NPA Split table in the IBAR Database  172  (FIG. 7) to determine the NPA-NXXs that are splitting, and their Permissive Dialing Periods (“PDPs”). At the start of a PDP, for a given NPA-NXX, the SOA Converter Process  142  performs a telephone number conversion. Each Subscription Version is retrieved from the SOA Database  126  to determine if the telephone number contains the old NPA-NXX. If so, the telephone number is modified to the new NPA-NXX. Other processes within the SOA Subsystem  72  continue processing during the conversion. 
     Turning to FIG. 6, the Regional Interface Broadcast Agent (“RIBA”) Subsystem  76  is broken down into its functional components. In general, the RIBA Subsystem  76  provides the interface between the NPAC/SMS  74  and the Interface Broadcast Agent Repository (“IBAR”) Subsystem  86 . When the NPAC/SMS  74  sends a message to the RIBA Subsystem  76 , it is received by the RIBA Agent  146 , which validates and strips the message of protocol related information. The RIBA Agent  146  then determines where the message is addressed to and sends the data to the appropriate application. 
     Messages from the NPAC/SMS  74  that request operations to be performed on tables within the RIBA Database  144 , such as SET, CREATE and DELETE, are sent to RIBA Message Handlers. FIG. 6 illustrates the use of four (4) RIBA Message Handlers, each handling CMIP messages for a specific object type and performing updating operations on tables within the RIBA Database  144 : a Subscription Version Message Handler  148 ; a Network Message Handler  150 ; a LRN Message Handler  152 ; and a NPA-NXX Message Handler  154 . When the appropriate RIBA Message Handler, either  148 ,  150 ,  152  or  154 , accepts the message, the data is then extracted from the message and the operation is determined. An SQL statement is built for the action using the data values extracted from the message. The SQL statement is then performed, which updates the RIBA Database  144 . 
     The FTP Network Download  162  and FTP Subscription Version Download  164  applications can update or restore the RIBA Database  144  and IBAR Database  172  from the NPAC/SMS  74  via FTP/TCPIP. These FTP applications  162  and  164 , which are controlled by an operator, read the subscription version and service provider network information from the NPAC/SMS  74  via FTP/TCPIP to form a flat file and update the appropriate database tables with the new information. These activities should be appropriately logged. 
     Upon startup, the IBA Agent  146  uses the Database Query process  166  to read each data item (subscription version, service provider network, LRN, and NPA-NXX information) from the RIBA Database  144  and loads them into memory. These data items form the Managed Instance Tree (“MIT”), which is used by the RIBA Subsystem  76  as reference points to the stored data during its operation. Once the load has been completed, the RIBA Agent  146  binds to the NPAC/SMS  74  and sends a download and recovery complete transaction to desynchronize the RIBA Subsystem  76 . When the bind has been successfully established, the RIBA Agent  146  requests that the NPAC/SMS  74  download all of the subscription, NPA-NXX and LRN data which was accumulated during the time that the IBA Agent  146  was not bound to the NPAC/SMS  74 . Upon successful completion of the download, the RIBA Agent  146  informs the NPAC/SMS  74  that the download has been completed and normal processing resumes. 
     The RIBA Agent  146  also receives notification, recovery complete and action transactions, which are forwarded to the appropriate logging utilities: a Notification Logger  156 ; a Recovery Complete Logger  158 ; and an Action Logger  160 . These logging utilities,  156 ,  158  and  160 , perform actions that are common to the RIBA log and notification programs. These procedures are contained in a separate program file and linked with the log and notification programs. When changes are required in the utility functions, these changes only need to be made in one place and the programs recompiled. These utilities process and handle the transactions and update the RIBA Database  144 . 
     In use, the NPAC/SMS  74  sends variable length create requests to the RIBA Agent  146  consisting of subscription data and a list of one or more telephone numbers for each subscription data element. The RIBA Agent  146  extracts the create request from the CMIP message and formats it into a structure suitable for use by the Action Logger  146  which, in turn, extracts the subscription version data from the structure. The Action Logger  146 , which communicates directly with the RIBA Agent  146 , is started by the Process Monitor  132  at the request of the RIBA Agent  146 . 
     The Notification Logger  156  is used to log notifications received by the RIBA Agent  146 . In this way, the NPAC-SMS Operational Information and Version New NPA-NXX notifications are logged. The RIBA Agent  146  receives these notifications from the NPAC/SMS  74 , formats the information into a usable structure and forwards the structure to the Notification Logger  156  over a UNIX socket. The Notification Logger  156  is started by the Process Monitor  132  at the request of the RIBA Agent  146 . 
     The Recovery Complete Logger  158  is used to log Recovery Complete Replies and Download Replies sent by the NPAC/SMS  74  to the RIBA Agent  146 . The RIBA Agent  146  receives these actions from the NPAC/SMS  74 , formats the information into a usable structure and forwards the structure to the Recovery Complete Logger  156  over a UNIX socket. The Recovery Complete Logger  156  is started by the Process Monitor  132  at the request of the RIBA Agent  146 . 
     Table 2 is a domain field listing for an the IBA Database  144  according to one embodiment: 
     
       
         
               
             
               
               
               
               
             
           
               
                 TABLE 2 
               
             
             
               
                   
               
               
                 Domain field list for IBA Database. 
               
             
          
           
               
                 Name 
                 Code 
                 Label 
                 Type 
               
               
                   
               
               
                 billingIdentifier 
                 BILLING_ID 
                 Billing Identifier 
                 VARCHAR2(4) 
               
               
                 booleanIndicator 
                 BOOL_IND 
                 Boolean Indicator 
                 NUMBER(1) 
               
               
                 city 
                 CITY 
                   
                 VARCHAR2(20) 
               
               
                 CLASS DPC 
                 CLASS_DPC 
                   
                 VARCHAR2(9) 
               
               
                 CLASS SSN 
                 CLASS_SSN 
                   
                 NUMBER(3) 
               
               
                 CNAM DPC 
                 CNAM_DPC 
                   
                 VARCHAR2(9) 
               
               
                 CNAM SSN 
                 CNAM_SSN 
                   
                 NUMBER(3) 
               
               
                 contactType 
                 CONTACT_TYPE 
                 Contact Type 
                 VARCHAR2(2) 
               
               
                 country 
                 COUNTRY 
                   
                 VARCHAR2(20) 
               
               
                 endUserLocationType 
                 END_USER_LOC_TYPE 
                   
                 VARCHAR2(2) 
               
               
                 endUserLocationValue 
                 END_USER_LOC_VALUE 
                   
                 VARCHAR2(12) 
               
               
                 identifier 
                 ID 
                   
                 NUMBER(10) 
               
               
                 ISVM DPC 
                 ISVM_DPC 
                   
                 VARCHAR2(9) 
               
               
                 ISVM SSN 
                 ISVM_SSN 
                   
                 NUMBER(3) 
               
               
                 LIDB DPC 
                 LIDB_DPC 
                   
                 VARCHAR2(9) 
               
               
                 LIDB SSN 
                 LIDB_SSN 
                   
                 NUMBER(3) 
               
               
                 LNPtype 
                 LNP_TYPE 
                   
                 NUMBER(1) 
               
               
                 LRN 
                 LRN 
                   
                 VARCHAR2(10) 
               
               
                 NPA NXX 
                 NPA_NXX 
                 NPA-NXX 
                 VARCHAR2(6) 
               
               
                 operationAction 
                 OPER_ACT 
                   
                 NUMBER(3) 
               
               
                 organizationId 
                 ORGNZ_ID 
                 ID number of an 
                 VARCHAR(3) 
               
               
                   
                   
                 organization. client, 
               
               
                   
                   
                 NPAC, regional IBA. 
               
               
                 Postal Code 
                 PC 
                 Postal Code 
                 VARCHAR2(40) 
               
               
                 servProvID 
                 SP_ID 
                   
                 VARCHAR2(4) 
               
               
                 stateProvince 
                 STATE_PROV 
                 State/Province 
                 VARCHAR2(2) 
               
               
                 status 
                 STATUS 
                 Status Flag 
                 NUMBER(10) 
               
               
                 systemType 
                 SYSTEM_TYPE 
                   
                 N1 
               
               
                 telephoneNumber 
                 TN 
                 Telephone Number 
                 VARCHAR2(10) 
               
               
                 timestamp 
                 T 
                   
                 DATE 
               
               
                 tunableName 
                 TUNABLE_NAME 
                 Tunable Name 
                 VARCHAR2(40) 
               
               
                 tunableValue 
                 TUNABLE_VALUE 
                 Tunable Value 
                 VARCHAR2(40) 
               
               
                 userIdentifier 
                 USER_ID 
                   
                 VARCHAR2(30) 
               
               
                 zip 
                 ZIP 
                   
                 VARCHAR2(40) 
               
               
                   
               
             
          
         
       
     
     The RIBA Process Monitor  167 , which was previously described in reference to the SOA Subsystem  72  (FIG.  5 ), watches over all of the standard applications or processes required to run the RIBA Subsystem  76 . The RIBA Process Monitor  167  does not, however, monitor the FTP processes  162  and  164 , or the RIBA Converter Process  170 . The RIBA Process Monitor  167  starts applications when they are required and is notified if an application terminates. If an application, which is intended to always be running terminates, such as the RIBA Agent  146  and RIBA Check Link  168 , the RIBA Process Monitor  167  will automatically restart the terminated application. The RIBA Check Link application  168  monitors the physical connection between the RIBA Subsystem  76  and NPAC/SMS  74 . If the physical connection is broken, the RIBA Check Link  168  will reset the RIBA Subsystem  76 . 
     The RIBA Converter Process  170  is a stand-alone process for NPA-NXX Split processing that performs a conversion of the telephone number value in the RIBA Subscription Version table. Using tunable database links, the RIBA Converter Process  170  accesses the NPA Split table in the IBAR Database  172  (FIG. 7) to determine the NPA-NXXs that are splitting, and their Permissive Dialing Periods (“PDPs”). At the start of a PDP, for a given NPA-NXX, the RIBA Converter Process  170  performs a telephone number conversion. Each telephone number record is retrieved from the RIBA Database  144  to determine if the telephone number contains the old NPA-NXX. If so, the telephone number is modified to the new NPA-NXX. Other processes within the RIBA Subsystem  76  are suspended for the duration of the conversion process. 
     Turning to FIG. 7, the Interface Broadcast Agent Repository (“IBAR”) Subsystem is shown and denoted generally as  86 . A particularly advantageous aspect of the present invention is that it provides interfaces from the IBAR Subsystem  86  to internal systems operated by the individual service providers. FIG. 7 illustrates four (4) proprietary downstream systems have been coupled to the IBAR Subsystem  86  for receiving data. The NCS  100  and RTE7  102  systems manage local number portability information in the long distance environment while the MINA/SMS  98  is configured to manage local number portability information on the local service network level. Also, the ARIS  96  collects local number portability (“LNP”) information for distribution to service provider business systems  68  (FIG. 2) and  88  (FIG.  3 ). 
     As such, and according to one embodiment of the invention, the IBAR Subsystem  86  supports the following features: 
     A facility to consolidate LNP data from the RIBA Database  144  into the IBAR Database  172 . 
     A data distribution application that manages distribution of data to the ARIS  96 , MINA/SMS  98 , and NCS  100  systems. This application will track the status of transactions to each of these systems. 
     An on-line interface to the NCS long distance support system  100  preferably using the DECmessageQ product from Digital Equipment Corp. 
     An on-line interface to the MINA/SMS system  98  preferably using Service Builder System Management Interface product from Northern Telecom. 
     An on-line interface to the ARIS system  96  preferably using the Registry Messaging product from MCI. 
     A batch interface to the RTE7 long distance support system  102  using FTP. 
     NPA-NXX Split Processing. 
     The IBAR Message Handler Subsystem  174  comprises the message handlers in the RIBA Subsystem  76  (FIG.  6 ). As previously described, the RIBA Agent  146  receives messages containing data from the NPAC/SMS  74  (FIG.  6 ). These messages are then directed to the proper message handlers: Subscription Version Message Handler  148 , Network Message Handler  150 . LRN Message Handler  152 , and NPA-NXX Message Handler  154 . These message handlers process the messages and data in block  176  (not explicitly shown in FIG. 6) and stores the data in the RIBA Database  144 . The IBAR Message Handler Subsystem  174  also inserts the data into a feeder table which will be read by the IBA Queue Processing Subsystem  178 . 
     The IBA Queue Processing Subsystem  178 , which is responsible for sending all changes received by the RIBA Database  144  to the RIBA/IBAR Interface Subsystem  182 , reads the data from the feeder table and tags each message with a tracking number before it is put into the Message Queue  180 . As will be described below, the tracking number ensures that the messages are delivered in sequential order. 
     The RIBA/IBAR Interface Subsystem  182  is responsible for keeping the IBAR Database  172  up to date with the changes that are made in the RIBA Database  144 . The RIBA/IBAR Interface Subsystem  182  includes a database update application  184  that reads and processes the messages from the Message Queue  180 . During processing, the underlying message data is acquired and organized by tasks, which are broken down at the “object” level (i.e. Telephone Number, Audit, Service Provider, and Network). The database update application  184  then updates the appropriate database fields in the IBAR Database  172  with the “object” data and calls stored procedures  186  to populate dedicated links  188 ,  190  and  192  with the information stored in the IBAR Database  172 . 
     To ensure that duplicate messages are not processed, the RIBA/IBAR Interface Subsystem  182  verifies that each message read from the Message Queue  180  is the next consecutively numbered message. The RIBA/IBAR Interface Subsystem  182  also provides the ability to track messages from any RIBA Subsystem  76  by recording all tracking numbers associated with each RIBA Subsystem  76  and its associated record in the IBAR Database  172 . 
     At the end of a successful transaction, the RIBA/IBAR Interface Subsystem  182  sends a response to the Response Queue  181  for each message received from Message Queue  180  as to whether it was successfully applied, rejected due to validation errors, or needs to be resent to the Message Queue  180 . The IBA Queue Processing Subsystem  178  reads the responses from the Response Queue  181 , processes them, and makes the appropriate updates to the table. For example, if the tracking number is out of sequence, the RIBA/IBAR Interface Subsystem  182  issues a “resend” of the specific message and any messages that have been put into the Message Queue  180  after the specific message. If, however, the specific message cannot be found in the table, the IBA Queue Processing Subsystem  178  sends a “lost” message notification and the resend process continues. 
     Multiple instances of the RIBA/IBAR Interface Subsystem  182  can be run to accommodate various types of NPAC/SMS  74 . This allows each NPAC/SMS  74  to have different information that is to be sent to the RIBA Subsystem  76  and then to the IBAR Subsystem  86 . As a result, a version ID is used to identify the type of NPAC/SMS  74  reviewing a given region so that all information can be sent to one Message Queue  180 . 
     As mentioned above, stored procedures  186  extract data from the IBAR Database  172  and write the data to the appropriate dedicated links  188 ,  190  and  192 . Each downstream on-line Data Distribution Application has its own dedicated link (e.g., link  188  for ARIS  96  messages, link  190  for MINA/SMS  98  messages and link  192  for NCS  100  messages). Data from each dedicated link is then read by the appropriate dedicated Data Distribution Application (e.g., application  196  for ARIS  96  messages, application  198  for MINA/SMS  98  messages, and application  200  for NCS  100  messages). 
     These dedicated Data Distribution Applications, which are part of the Data Distribution Subsystem  194 , then send the transactions to a second set of Message Queues, each dedicated Data Distribution Application having its own dedicated Message Queue (e.g., Message Queue  202  for ARIS  96  messages, Message Queue  204  for MINA/SMS  98  messages, and Message Queue  206  for NCS  100  messages). The Message Queues  202 ,  204  and  208  then send the transactions to the Downstream Interface Subsystem  208 , which contains an interface for each application format (e.g., ARIS Request Processing Interface  210  for ARIS  96  messages, MINA/SMS Request Processing Interface  212  for MINA/SMS  98  messages, and NCS Request Processing Interface  214  for NCS  100  messages). 
     Once the message has been sent to the appropriate interface in the Downstream Interface Subsystem  208 , the status of the record in the IBAR Database  172  will be changed to “Sending.” In addition, the Message Queues  202 ,  204  and  206  are continuously monitored as transactions are added to them so that any errors can be found and an alarmed can be triggered. In the event of a message failure, or a process or system failure, or during system startup, a recovery process is started and the status of the records in the IBAR Database  172  are checked. During this recovery process, all records in the IBAR Database  172  having a status of “Sending” will be resent to the Downstream Interface Subsystem  208  in the same manner as previously described. Regular processing of messages from the IBAR Database  172  to the Downstream Interface Subsystem  208  will be held up until the recovery process is complete. 
     In the Downstream Interface Subsystem  208 , a custom request processing application for each on-line interface to a network provider&#39;s external system will read the requests from a message and facilitate the transfer over the specific interface. They will format the data as required by the interface (eg., Northern Telecom&#39;s Service Management Interface protocol requirements) and ensure that the data is delivered across the interface. Typically, the data is sent in a synchronous manner to the network provider&#39;s external system via an ASCII based TCP/IP socket interface. The network provider&#39;s external system is responsible for queuing the data to a serial communication port. The responses received from the network provider&#39;s external system can be sent in an asynchronous manner. Although the Downstream Interface Subsystem  208  as illustrated in FIG. 7 supports four proprietary interfaces, it should be understood that any interface can be supported depending on the external system used by the service provider. 
     The Downstream Interface Subsystem  208  uses various mechanisms that allow the IBAR Subsystem  86  to communicate with external systems. For example, the MINA/SMS Request Processing Interface  212  is implemented as a stream of data sent via a TCP/IP socket interface using SMI protocol. The NCS Request Processing Interface  214  is implemented using the ported telephone number and request Service Provider NPA-NXX data and is set up as a two-way dialog, i.e. data is sent to the NCS  100  and the NCS  100  replies after processing the data, The ARIS Request Processing Interface  210  is implemented using the ported telephone number data and uses MCI Registry or a similar communications protocol, which is a one-way dialog, i.e. data is sent to ARIS  96 , but ARIS  96  does not return confirmation after processing the data. Unlike the other Request Processing Interfaces  210 ,  212  and  214 , the RTE7 Batch Extract  216  consists of a regularly scheduled batch job that extracts the required transactions directly from the IBAR Database  172  and writes them to a disk file  218 . The resulting disk file  218  is transmitted to RTE7  102  via TCP/IP using FTP. 
     Using the above described Request Processing Interfaces  210 ,  212  and  214 , a user is able to access a menu from which the user can: connect or disconnect from the NCS Message Queue; logon or logoff the MINA/SMS session; or register or deregister from the ARIS registry. In response to the user&#39;s selection, the Service Configuration and Management Application  242  sends a signal to one of three Request Processing Interfaces  210 ,  212  or  214 . For example, in the UNIX operating environment, two signals are used: SIGUSRI and SIGUSR 2 . The SIGUSRI signal is used for “connect”, “logon” and “register” commands; whereas the SIGUSR 2  signal is used for “disconnect”, “logoff” and “deregister” commands. 
     An Emulator Subsystem  220  is communicably linked to the Downstream Interface Subsystem  208  and is used for testing and validating the Downstream Interface Subsystem  208 . Communication between the Downstream Interface Subsystem  208  and Emulator Subsystem  220  is accomplished using different protocols for each individual program, such as: a DEC Message Queue for the DDS Emulator  222  and the NCS Emulator  228 ; a UNIX TCP/IP socket library for the MINA/SMS Emulator  226 ; and Registry for the ARIS Emulator  224 . 
     The Utilities Subsystem  230  contains a set of utility functions and common procedures  232  that are used to speed up the development of UNIX and SQL programs. These functions have been developed specifically for use in the IBAR Subsystem  86  application environment and provide solutions to common problem requirements such as Oracle stored procedures  184 , Message Queue access, FTP access, error handling, process signal control and any other software functions that may be best implemented as a utility. 
     An Audit Reconciliation Subsystem  234  provides service providers interfacing with the IBAR Subsystem  86  the ability to audit their databases against the IBAR Database  172 . Some service providers may consider the IBAR Database  172  to be the database of record for LNP data. The Audit Reconciliation Subsystem  234  supports both regularly scheduled and on demand audit requests. The Audit Reconciliation Subsystem  234  will support requests for subsets of the data in the IBAR database  162  as well as complete database dumps. A system administrator can schedule these requests and will manually clean out any audit files that are no longer required. Specifically, the Audit Subsystem  236  extracts the audit data from the IBAR Database  172  and writes it to a disk file  238  that can be distributed using FTP. 
     The Process Monitor Subsystem  240  provides the means to start and stop the IBAR applications and includes the Service Configuration and Management Application  242 , which was previously described, and a Process Manager  244 . The Service Configuration and Management Application  242  provides the means to stop and restart communications between each of the real time on-line interfaces found in the Distribution Interface Subsystem  208  and its downstream server counterpart operated by the service provider. The Process Manager  244  provides the means to stop and restart the RIBA/IBAR Interface Subsystem  182 , the Data Distribution Subsystem  194  and the Downstream Interface Subsystem  208 . Accordingly, the Process Monitor Subsystem  244  is started at system start-up and spawns the initial IBAR applications. The Process Monitor  244  also monitors each application process and will re-start any process that terminates abnormally. In other embodiments, the Process Monitor  244  can spawn more copies of the same systems upon request. The initial information is stored in a file and loaded by the Process Monitor  244  when it is stared. 
     The NPA-NXX Split Subsystem  246  is responsible for processing NPA splits and includes several processes: NETCAP File Access Process  248 ; LERG 12 File Access Process  250 ; Administrator Process  252 ; Time Trigger Process  254 ; Mass Duplication Process  256 ; Add-to-Split Process  260 ; Unsplit Process  262 ; Relief Date Modification Process  264 ; LRN Cleanup Process  266 ; and Telephone Number Cleanup Process  268 . These processes are described below. 
     The NETCAP File Access Process  248  determines when an NPA is going to split, what the new NPA-NXX is going to be, and at what date the split will occur. The NETCAP File Access Process  248  reads the NETCAP file and updates the NPA Split table in the IBAR Database  172  as appropriate. The NPA Split table in the IBAR Database  172  is where the status of each split is tracked and is used to provide the key input for driving NPA Split processing. The NETCAP file is the primary external data source of NPA Split information and is in a mainframe dataset format that must first be retrieved via FTP or some other mainframe-to-Unix utility. Although the NETCAP File Access Process  248  is preferably a regularly scheduled daily batch job, it can also be started manually by the system operator. 
     More specifically, the NETCAP File Access Process  248  first determines whether the NPA-NXX in the NETCAP file is portable by looking for the NPA-NXX in the IBAR Database  172 . If the NPA-NXX does not exist in the IBAR Database  172 , the NPA-NXX is bypassed. If on the other hand, the NPA-NXX does exist, the NPA-NXX is deemed to be portable and the RIBA Subsystem  76  associated the NPA-NXX is determined using the Action ID in the IBAR Database  172 . 
     The NETCAP File Access Process  248  then determines the type of record to insert, modify or delete in the NPA Split table for the portable NPA-NXX. Existing NPA Split records having a status of “Completed” are deleted. A NPA Split record having an action of “Unsplit” may also be deleted prior to the Duplication Trigger Point. If the Relief Date for a NPA split record changes before the Mass Duplication Process  256  has been run, then only the NPA Split record&#39;s Relief Date is modified and the Relief Date Modification Process is not required. 
     The LERG12 File Access Process  250  reads the LERG 12 file and updates the LERG 12 table in the IBAR Database  172  as appropriate. The LERG 12 file is a mainframe dataset that is downloaded as a flat file for processing and is used as a secondary external data source of NPA Split information as it pertains to LRNs. The NPA-NXXs defined in the NETCAP data serve to identify both telephone numbers and LRNs affected by a split, as it is understood that LRNs contain valid NPA-NXXs. The LERG 12 data is used for confirmation that the LRNs identified as split-affected by the NETCAP data are valid split-affected LRNs according to the LERG. The LERG 12 File Access Process  250  is preferably a regularly scheduled monthly batch job. 
     The LERG12 File Access Process  250  checks for the existence of a LERG 12 flat-file. If one exists, the LERG 12 table, which is used for exception reporting, is purged so at the LERG 12 flat-file data can be re-inserted in the IBAR Database  172 . This effectively replaces the old data in the LERG 12 table with the new data from the LERG 12 flat-file. The LERG 12 File Access Process  250  also has the ability to designate the LERG 12 flat-file via a command-line specified filename (optional), instead of using the default provided within the program. 
     The Administrator Process  252  produces exception reports based on information retrieved from the IBAR Database  172 , the NETCAP file and the LERG 12 file. This process is executed on demand by a systems administrator or operator. 
     The Time Trigger Process  254  reads the NPA Split table in the IBAR Database  172  and processes each active record according to the Action and Status attributes and other tunable parameters, such as the Duplication Trigger Point. The Duplication Trigger Point is a tunable period of time prior to the start of Permissive Dialing Period. The Time Trigger Process  254  updates the NPA Split table as appropriate and starts the following processes: the Mass Duplication Process  256 , the Add-to-Split Process  260 , the Unsplit Process  262 , the Relief Date Modification Process  264 , the LRN Cleanup Process  266 , and the Telephone Number Cleanup Process  268 . 
     The Time Trigger Process  254  is also responsible for setting a suspend flag in the IBAR Database  172  that, as will be described below, suspends the RIBA/IBAR transaction flow prior to the running of the Mass Duplication Process  256 , the Add-to-Split Process  260  and the Unsplit Process  262 . This ensures that all existing IBAR transactions will be processed without interruption of the incoming flow and that none of the new incoming transactions will be inadvertently bypassed during split processing. Once the Mass Duplication Process  256 , Add-to-Split Process  260  and Unsplit Process  262  are complete, the Time Trigger Process  254  resets the suspend flag. 
     The Time Trigger Process  254  runs continuously under the control of the Process Monitor  244 . At a tunable period of time and after each pass through the NPA Split table, the Time Trigger Process  254  sleeps for a short time. There will be one instance of the Time Trigger Process  254  for each RIBA Subsystem  76  to facilitate processing of the NPA Split table. Each RIBA Subsystem  76  will process only the NPA-NXXs particular to the region serviced by the RIBA Subsystem  76  and the Regional NPAC/SMS  74 . Each NPA Split record is processed in a synchronous mode such that, for each NPA Split record read, a process may or may not be executed depending on its conditions, and the process will be completed before the next NPA Split record is retrieved. 
     The Mass Duplication Process  256  reads the IBAR Database  172  and determines which records need to be duplicated for NPA Splits. Each current record that contains the affected NPA-NXX and an action of “Activate” or “Modify” is duplicated. The duplicated records are written to the IBAR Database  172  and then sent to MINA/SMS  98  by batch file and to the NCS  100  via Oracle pipes. The duplicated records are not sent to ARIS  96 . The Mass Duplication Process  256  is started by the Time Trigger Process  254  when the Duplication Trigger Point is reached for a given NPA-NXX. 
     The NPA Split Duplication Process  258  within the RIBA/IBAR Interface Subsystem  182  is responsible for notifying the IBA Queue Processing Subsystem  178  to suspend the RIBA to IBAR transaction flow and for duplicating incoming transactions at the appropriate time. For NPA Split processing, the NPA Split Duplication Process  258  regularly examines the suspend flag in the IBAR Database  172  that is set by the Time Trigger Process  254 . When the suspend flag is set, the NPA Split Duplication Process  258  notifies the IBA Queue Processing Subsystem  178  via the Response Queue  181 , which then stops sending messages from the RIBA Database  144  to the Message Queue  180 . The IBA Queue Processing Subsystem  178  periodically sends a message to the RIBA/IBAR Interface Subsystem  182  prompting the NPA Split Duplication Process  258  to check on the status of the suspend flag. Once the suspend flag has been reset by the Time Trigger Process  254 , the NPA Split Duplication Process  258  notifies the IBA Queue Processing Subsystem  178  via the Response Queue  181  to resume sending messages. 
     For duplicating incoming transactions, the NPA Split Duplication Process  258  first completes regular processing of each transaction, including committing the record to the IBAR Database  172 . The NPA Split Duplication Process  258  then compares each transaction against the NPA Split table in the IBAR Database  172  to determine whether the transaction is to be duplicated or not. A transaction is duplicated if the telephone number contains an affected NPA-NXX, the action is “Activate,” “Modify” or “Disconnect” and the current processing time is between the Duplication Trigger Point and the Mandatory Dialing Date. Duplicated transactions are assigned an Action ID indicating that it is a duplicate and not an original transaction. 
     Transactions that are duplicated during the period from the Duplication Trigger Point to the Relief Date are sent only to MINA/SMS  98  and NCS  100  via existing mechanisms. Transactions that are duplicated during the period from the Relief Date to the Mandatory Dialing Date are sent to ARIS  96 , MINA/SMS  98  and NCS  100  via existing mechanisms. 
     The Add-to-Split Process  260  performs the same role as the Mass Duplication Process  256  in reading the IBAR Database  172  and determining which records need to be duplicated for NPA Splits. This process, however, can be triggered by the Time Trigger Process  254  at any time that the Time Trigger Process  254  retrieves an NPA Split record indicating that an NPA-NXX requires Add-to-Split processing. An Add-to-Split can occur before and during the Permissive Dialing Period, with the same, or with different, start and end Permissive Dialing Period dates. 
     The records duplicated by the Add-to-Split Process  260  are written to the IBAR Database  172  and then sent to MINA/SMS  98  via the regular mechanism and not by batch file, as in the case of the Mass Duplication Process  256 . These duplicated records are also sent to NCS  100 , but are not sent to ARIS  96 . 
     The Unsplit Process  262  reads the IBAR Database  172  and determines which telephone numbers require a “Duplicated Disconnect” transaction, due to a NPA-NXX Unsplit. A “Duplicate Disconnect” transaction is created for each telephone number that contains an NPA-NXX that has been unsplit, and any action other than “Disconnect” or “Duplicate-Disconnect.” The “Duplicate Disconnect” transactions are sent to NCS  100  via the regular method, but are not sent to the ARIS  96  or the MINA/SMS  98 . ARIS  96  performs Unsplit processing of its own and MINA/SMS  98  is informed of “Disconnect” telephone numbers via E-mail. 
     The Unsplit Process  262  can be triggered by the Time Trigger Process  254  at any time between the Duplication Trigger Point and the Mandatory Dialing Date, if the Mass Duplication Process  256  has been run. The Time Trigger Process  254  ensures that the RIBA/IBAR incoming transaction feed is suspended prior to the running of the Unsplit Process  262 . 
     The Relief Date Modification Process  264  reads the IBAR Database  172  and determines which records need to be updated with a new Relief Date. Each record that contains an affected NPA-NXX is updated with the new Relief Date. These modifications are not sent to ARIS  96 , MINA/SMS  98  or NCS  100 . The Relief Date Modification Process  264  is triggered by the Time Trigger Process  254  at any time prior to Permissive Dialing Period if the Mass Duplication Process  256  has been run. 
     The LRN Cleanup Process  266  reads the IBAR Database  172  and determines which records require a modification to the LRN attribute. A “Modify” transaction is created for each record that contains an LRN with an old NPA-NXX, a telephone number not containing an old NPA-NXX, and any action other tan “Disconnect” or “Duplicate Disconnect.” The “Modify” transactions are sent to ARIS  96 , MINA/SMS  98  and NCS  100  using the regular methods. The LRN Cleanup Process  266  is triggered by the Time Trigger Process  254  to run at the LRN Clean-up Trigger Point, which is a tunable number of hours prior to the Mandatory Dialing Date. 
     The Telephone Number Cleanup Process  268  reads the IBAR Database  172  and determines which records require a “Disconnect” transaction. A “Disconnect” transaction is created for each record that contains an old NPA-NXX and any action other than “Disconnect” or “Duplicate-Disconnect.” The “Disconnect” transactions are sent to NCS  100  using the regular methods, but are not sent to ARIS  96  or MINA/SMS  98 . The MINA/SMS  98  is informed of “Disconnect” telephone numbers via E-mail. The Telephone Number Cleanup Process  268  is triggered by the Time Trigger Process  254  at the telephone number Clean-up Trigger Point which is a tunable number of hours after the Mandatory Dialing Date. 
     Briefly referring back to FIGS. 3 and 4, the SOA Engine Subsystem  80  uses a message-based protocol to provide an interface between the Local Customer Order Entry/Order Processing (“OE/OP”) Systems (collectively referred to as the “Front End”)  78  and the SOA  32  and RIBA  34  Subsystems. Thus, the SOA Engine Subsystem  80  allows the Front End  78  to upload data, audit, query and otherwise communicate with the NPAC/SMS  74 . 
     Now referring to FIG. 8, the SOA Engine Subsystem  80  will be described in detail. The Front End Emulator Subsystem  270  includes both client and server applications, which provide the interface between the SOA Engine Subsystem  80  and the Front End  78 . The client applications handle requests from the Front End  78 , whereas the server applications handle reply or responses to the Front End  78 . More specifically and as illustrated in FIG. 8, the client applications may include a Subscription Version Request Service  272 , a Notification Request Service  274 , a LRN Request Service  276 , a NPA-NXX Request Service  278 , an Audit Request Service  280  and a Service Provider Request Service  282 . The server applications may include a Query Reply Service  284  and an Action Reply Service  286 . 
     Each client application  272 ,  274 ,  276 ,  278 ,  280  and  282  sends request messages from the Front End  78  to an Upstream Message Listener Subsystem  300  using the appropriate Registry protocols  288 ,  290 ,  292 ,  294 ,  296  and  298 . Once a client application  272 ,  274 ,  276 ,  278 ,  280  or  282  sends a request message, that client application will wait for a reply message before sending another request message. 
     For each request message, the Upstream Message Listener Subsystem  300  determines the particular NPAC/SMS  74  to which the request message is to be delivered to and writes the request message to the SOA Engine Database  314  using a Subscription Version Request Listener  302 , a Notification Request Listener  304 , a LRN Request Listener  306 , a NPA-NXX Request Listener  308 , an Audit Request Listener  310  and a Service Provider Request Listener  312 . The appropriate Listener  302 ,  304 ,  306 ,  308 ,  310  or  312  also sends a reply message back to Front End  78  through the appropriate client application  272 ,  274 ,  276 ,  278 ,  280  or  282 . The reply message indicates only that the request message has been received and queued for transmission to the appropriate NPAC/SMS  74 , and does not indicate that the request message has been sent to or processed by the NPAC/SMS  74 . 
     The SOA Engine Database  314  contains a queuing table for each type of request message. The Upstream Message Handler Subsystem  316  polls these queuing tables using a Notification Message Handler  318 , a Subscription Version Message Handler  320 , a LRN Message Handler  322 , a NPA-NXX Message Handler  324 , an Audit Message Handler  326  and a Service Provider Message Handler  328  to retrieve the appropriate records and processes them accordingly. These Message Handlers will now be described in more detail. 
     The Notification Message Handler  318  polls the Notification table in the SOA Engine Database  314  to retrieve all records and determines the action to be performed on each retrieved record based on the record message type and status. If the record is a new request, the information needed to create the response message will be fetched from the SOA Database  126  or the corresponding database table will be updated. As was previously described in regard to FIG. 5, the new request message is processed by the SOA Subsystem  72 , sent to and processed by the NPAC/SMS  74  and a response message is created and returned containing the result of the new request message. If the record is not a new request, an error response message will be created. 
     The appropriate response message is then sent to the Front End  78  via Registry  330  and Query Reply Source  284 , or Registry  332  and Action Reply Service  286  where it is parsed, displayed on the console, and saved to a Log file. If the Front End  78  successfully receives the response message, a confirmation message is sent back to the Notification Message Handler  318 . If the confirmation message is received, the Notification Message Handler  318  deletes the record from the Notification table in the SOA Engine Database  314 . Otherwise, the result status of Notification table will be updated for the request. The Notification Message Handler  318  keeps running until all the records in the Notification table are processed. If there are no more records in the Notification table, the Notification Message Handler  318  sleeps for a certain time before it wakes up and begins to poll the Notification table again. 
     The Subscription Version Message Handler  320  polls the Subscription Version queuing table in the SOA Engine Database  314  to retrieve all records based on a telephone number range. The Subscription Version Message Handler  320  analyzes each retrieved record and determines the action to be performed based on the record message type and status. If the record is a new message the Subscription Version Message Handler  320  calls the appropriate stored procedure  120  (FIG. 5) in the SOA Database  126 . As was previously described in regard to FIG. 5, the new request message is processed by the SOA Subsystem  72 , sent to and processed by the NPAC/SMS  74  and a response message is created and returned containing the result of the new request message. Once a response is received from the stored procedure  120  (FIG.  5 ), it is evaluated and the return code is used to update the record status in the Subscription Version queuing table and a response message is created containing the message data and header. If the record is not a new message, a “resend” message will be reissued containing only the error message header. If the record is a new message, but has been queued longer than a configurable amount of time, it will be considered to have expired and the response message is created containing an error message header. 
     The appropriate response message is then sent to the Front End  78  via Registry  330  and Query Reply Service  284 , or Registry  332  and Action Reply Service  286  where it is parsed, displayed on the console, and saved to a Log file. If the Front End  78  successfully receives the response message, a confirmation message is sent back to the Notification Message Handler  318 . If the confirmation message is received, the Notification Message Handler  318  deletes the record from the Subscription Version queuing table in the SOA Engine Database  314 . 
     The LRN Message Handler  322  polls the LRN queuing table in the SOA Engine Database  314  to retrieve all LRN Message records. The LRN Message Handler  322  analyzes each retrieved record and determines the action to be performed based on the record message type, status and received date. If the record is a new message, the LRN Message Handler  322  calls the appropriate stored procedure (FIG. 5) in the SOA Database  126 . As was previously described in regard to FIG. 5, the new request message is processed by the SOA Subsystem  72 , sent to and processed by the NPAC/SMS  74  and a response message is created and returned containing the result of the new request message. Once a response is received from the stored procedure  120  (FIG.  5 ), it is evaluated and a response message will be created. If the record is not a new message, the date of the record is examined. If it is expired, it will be deleted from LRN queuing table. Otherwise, an error response message will be created. 
     The appropriate response message is then sent to the Front End  78  via Registry  330  and Query Reply Service  284 , or Registry  332  and Action Reply Service  286  where it is parsed, displayed on the console, and saved to a Log file. If the Front End  78  successfully receives the response message, a confirmation message is sent back to the LRN Message Handler  322 . If the LRN Message Handler  322  receives the confirmation message, the LRN Message Handler  322  deletes the record from the LRN Message queuing table in the SOA Engine Database  314 . Otherwise, the result status of the LRN Message queuing table will be updated for the request. 
     The NPA-NXX Message Handler  324  polls the NPA-NXX queuing table in the SOA Engine Database  314  to retrieve all NPA-NXX Message records. The NPA-NXX Message Handler  324  analyzes each record retrieved and determines the action to be performed based on the message type, status, and received date. If the record is a new message, the NPA-NXX Message Handler  324  calls the appropriate stored procedure (FIG. 5) in the SOA Database  126 . As was previously described in regard to FIG. 5, the new request message is processed by the SOA Subsystem  72 , sent to and processed by the NPAC/SMS  74  and a response message is created and returned containing the result of the new request message. Once a response is received from the stored procedure  120  (FIG.  5 ), it is evaluated and a response message created. If the record is not a new message, the date of the record is examined and if it is expired, it will be deleted from NPA-NXX queuing table. Otherwise, an error response message is created. 
     The appropriate response message is then sent to the Front End  78  via Registry  330  and Query Reply Service  284 , or Registry  332  and Action Reply Service  286  where it is parsed, displayed on the console, and saved to a Log file. If the Front End  78  successfully receives the response message, a confirmation message is sent back to the NPA-NXX Message Handler  324 . If the NPA-NXX Message Handler  324  receives the confirmation message, the NPA-NXX Message Handler  324  deletes the record from the NPA-NXX queuing table in the SOA Engine Database  314 . Otherwise, the result status of the NPA-NXX queuing table will be updated for the request. 
     The Audit Message Handler  326  polls the Audit queuing table in the SOA Engine Database  314  to retrieve all request records for processing. The Audit Message Handler  326  analyzes each record retrieved and determines the action to be performed based on the message type and status. If the record is a new message, the Audit Message Handler  326  calls the appropriate stored procedure (FIG. 5) in the SOA Database  126 . As was previously described in regard to FIG. 5, the new request message is processed by the SOA Subsystem  72 , sent to and processed by the NPAC/SMS  74  and a response message is created and returned containing the result of the new request message. Once a response is received from the stored procedure  120  (FIG.  5 ), it is evaluated and the return code is used to update the record status in the queuing table and a response message is created containing the header and the message data. If the record is not a new message, the response message is created containing an error message header. If the record is a new message, but has been queued longer than a configurable amount of time, it will be considered to have expired and the response message is created containing an error message header. 
     The appropriate response message is then sent to the Front End  78  via Registry  330  and Query Reply Service  284 , or Registry  332  and Action Reply Service  286  where it is parsed, displayed on the console, and saved to a Log file. If the Front End  78  successfully receives the response message, a confirmation message is sent back to the Audit Message Handler  326 . The Audit Message Handler  326  waits until the confirmation message is received in order to delete the record from the message queuing table in the SOA Engine Database  314 . 
     The Service Provider Message Handler  328  polls the Service Provider queuing table in the SOA Engine Database  314  to retrieve all request records. The Service Provider Message Handler  328  analyzes each record retrieved and determines the action to be performed based on the message type and status. If the record is a new message, the Service Provider Message Handler  328  calls the appropriate stored procedure (FIG. 5) in the SOA Database  126 . As was previously described in regard to FIG. 5, the new request message is processed by the SOA Subsystem  72 , sent to and processed by the NPAC/SMS  74  and a response message is created and returned containing the result of the new request message. Once a response is received from the stored procedure  120  (FIG.  5 ), it is evaluated and the return code is used to update the record status in the queuing table and a response message is created containing the header and the message data. If the record is not a new message, the response message is created containing an error message header. If the record is a new message, but has been queued longer than a configurable amount of time, it will be considered to have expired and the response message is created containing an error message header. 
     The appropriate response message is then sent to the Front End  78  via Registry  330  and Query Reply Service  284 , or Registry  332  and Action Reply Service  286  where it is parsed, displayed on the console, and saved to a Log file. If the Front End  78  successfully receives the response message, a confirmation message is sent back to the Service Provider Message Handler  328 . The Service Provider Message Handler  328  waits until the configuration message is received in order to delete the record from the message queuing table in the SOA Engine Database  314 . 
     The SOA Engine Convert Process  334  is a stand-alone process that is started up as is needed. It accesses the NPA Split table in the IBAR Database  172 , using tunable Oracle database links to determine the NPA-NXXs that are splitting and their Permissive Dialing Periods. At the start of a Permissive Dialing Period for a given NPA-NXX, the SOA Engine Converter Process  334  performs a telephone number conversion. Each telephone number record is retrieved from the SOA Engine Database  314  to determine if the telephone number contains the old NPA-NXX. If so, the telephone number is modified to the new NPA-NXX. Other processes within the SOA Engine Subsystem  80  continue processing during the conversion. 
     A Common Utility Function Subsystem  336  provides a set of utility functions that are available to speed development of UNIX and SQL programs. These utility functions, which include reading startup tunable parameters  338 , are developed specifically for use in the SOA Engine Subsystem  80  application environment to provide solutions to common programming requirements, such as Oracle stored procedures. 
     Now referring to FIG. 9, the NNMC GUI Subsystem  112  will be described. The GUI Subsystem  112  connects to the SOA Databases  126  in the SOA Subsystems  72 , the IBAR Database  172  in the IBAR Subsystem  86 , the SOA Engine Database  314  in the SOA Engine Subsystem  80 . Access to the SOA  126 , IBAR  172  and SOA Engine  314  Databases is performed via database links, which are stored in the NNMC Database  340 . A table within the NNMC Database  340  tracks the number of queries performed per day, per SOA Subsystem  72  and IBAR Subsystem  86 . The number of queries is limited to a tunable daily maximum before the end-user is denied access. Based on the telephone number queried, the NNMC GUI  112  uses a telephone number to NPAC cross-reference table within the SOA Engine Database  314  to determine the correct SOA Database  126  to access. 
     Turning now to FIG. 10, the processing flow of the Data Distribution Subsystem (“DDS”)  194  (FIG. 7) is illustrated and will be described. The DDS processing is started by the process monitor. There may be three instances of the DDS processing, one for each of the downstream interfaces, NCS  214 , MINA  212  and ARIS  210 . DDS processing  194  begins in block  400  and decision block  402  determines if the startup parameters are supplied. If the startup parameters are not supplied an error is logged in block  404  and the DDS shutdown process is called in block  406 . If, however, the startup parameters are supplied, decision block  408  determines if an incorrect number of startup parameters have been supplied. If an incorrect number of start parameters was supplied an error is logged in block  410  and an error alarm is set in block  412 . If, however, the correct number of startup parameters were supplied or the error alarm has been set, the DDS signal handler process is called in block  414 , which will be described in reference to FIG. 10A, to set up the DDS signal handler for the termination signal, SIGTERM. The DDS signal handler process  414  is set up to catch the SIGTERM signal coming from the process monitor and may perform a graceful shutdown if instructed Next, block  416 , all signals other than SIGTERM are blocked. Next, block  418 , the graceful shutdown command is initialized to false and the graceful waiting command is initialized to false. DDS startup process  420  is called in block  420  and will be described in reference to FIG.  10 B. DDS startup process  420  retrieves any needed environment variables, logs the process on to the database  172 , establishes a connection to a specific environmentally defined message queue ( 202 , or  204 , or  206 ) and may be needed for processing. If startup process  402  returns with a failure notification, as determined in decision block  422 , the DDS shutdown process is called in block  424 , which will be described in reference to FIG.  10 I. If, however, a failure notification was not returned, the DDS recovery process is called in block  426 , which will be described in reference to FIG.  10 C. If DDS recovery process  426  returns with a failure notification, as determined in decision block  428 , the DDS shutdown process is called in block  430 . If, however, a failure notification does not occur the DDS read pipe process is called in block  432 . 
     Turning now to FIG. 10A, the processing flow of the DDS signal handler process  414  is illustrated and will be described. DDS signal handler process begins in block  440  and the DDS signal handler process  414  determines in decision block  442  if the global variable G_WAITING is equal to false. If G_WAITING equals false, the global variable GRACEFUL SHUTDOWN is set to false in block  444  and the process returns in block  446 . If, however, G_WAITING does equal false the DDS shutdown process is called in block  488 . 
     Turning now to FIG. 10B the processing flow for the DDS startup process  420  is illustrated and will be described. The DDS startup process  420  begins in block  450  and connects to IBAR database  172  in block  452 . If a failure occurred connecting to the IBAR database  172 , as determined in decision block  454 , the console is alerted in block  456 , the error is logged in block  458  and a notification of failure is returned in block  460 . If, however a failure did not occur connecting to the IBAR database  172 , as defined in decision block  454 , configuration information from IBAR database  172  is retrieved in block  462 . If a failure occurred while retrieving configuration information, as determined in decision block  464 , a log error handler is called in block  466  and a notification of failure is returned in block  468 . If, however, a failure did not occur while retrieving configuration information, as determined in decision block  464 , the name of the pipe ( 188 , or  190 , or  192 ) is retrieved from a database table in the IBAR database  172  in block  470 . If a failure occurred retrieving the pipe name, as determined in decision block  472 , a error handler is called in block  474  and DDS shutdown process is called in block  476 . If, however, a failure did not occur, as determined in decision block  472 , the DDS  194  connects to the targeted message queue ( 202 , or  204 , or  206 ) in block  478 . If a failure occurred connecting to the targeted message queue ( 202 , or  204 , or  206 ), as determined in decision block  480 , a log error handler is called in block  482  and a response of failure is returned in block  484 . If, however a failure did not occur in decision block  480  a response of successful is turned in block  486 . 
     Turning now to FIG. 10C, the processing flow for the DDS recovery process  426  is illustrated and will be discussed. The DDS recovery process begins in block  490 , and if the number of resend is greater than the maximum, as determined in decision block  492 , an error handler is called in block  494  and the DDS shutdown process is called in block  496 . If, however, the number of resend&#39;s is not greater than the maximum, decision block  498  determines if the status flag equals sending or sending and saved. If the status flag is set to sending or sending and saved, the recovery cursor is opened in block  500 . Messages waiting to be resent are loaded into the database cursor. Decision block  502  determines if there are more messages for resend. If there are no more messages for resend, the cursor for database access is closed in block  504  and a response of successful is returned in block  505 . If, however, there are more messages for resend the messages are retrieved from the database cursor in block  506 . Next, block  508 , the messages are sent to the targeted message queue ( 202 , or  204 , or  206 ). If a error occurs, as determined in decision block  510 , an error handler is called in block  512  and the DDS restart communications process is called in block  514 . Next the process returns to decision block  492  and the process repeats. If the status flag is not set to sending and saved, as determined in decision block  498 , decision block  518  determines if the status flag is set to saved or sending and saved. If the status flag is not set to sending and saved, a response of failure is returned in block  519 . If, however, the status flag equals saved or sending and saved the recovery cursor is opened in block  520 . Decision block  522  determines if there are more messages for resend. If there are no more messages for resend, as determined in decision block  522 , the recovery cursor is closed in block  524  and a response of successful is returned in block  525 . If, however, there are more messages for resend the message is retrieved in block  526 . Next, block  528 , the status field in the client tracker table in the IBAR database  172  is updated to sending. If an error occurred updating the client tracker table, the log error handler is called in block  532 . If, however, a error did not occur updating the client tracker status the message is sent to the targeted message queue ( 202 , or  204 , or  206 ) in block  536 . If an error has occurred, as determined in decision block  538 , a log error handler is called in block  542 . Next the DDS restart communications process is called in block  544  and processing returns to block  492  and the processing continues. 
     Turning now to FIG. 10D the DDS read pipe process  432  begins in block  560 . If the graceful shutdown parameter is set equal to true, as determined in decision block  562 , the process returns in block  564 . If, however, a shutdown is not requested, decision block  566  determines if a system failure has occurred. If a system failure has occurred a notification of failure is returned in block  568 . If a system failure did not occur, as determined in decision block  566 , the G_WAITING global variable is set to true in decision block  570 . Next, block  572 , the message from the targeted pipe ( 188 , or  190 , or  192 ) is read into the targeted message queue ( 202 , or  204 , or  206 ). If a failure occurred reading the message from the targeted pipe ( 188 , or  190 , or  192 ) into the buffer, as determined in decision block  574 , the console is alerted in block  576 , an error is logged in block  578  and the targeted message queue ( 202 , or  204 , or  206 ) is refreshed in block  580 . The process then returns to decision block  562  where the process repeats. If, however, a response of failure did not occur, as determined in decision block  574 , the global variable G_Waiting is set to false in block  582 . Next, block  584 , the header information structure is unpacked. The header information structure may comprise of global variables such as, a RIBA action ID, a sequence number and a client action ID. If a failure occurred unpacking the header information structure, as determined in decision block  586 , a log error handler is called in block  588  and processing returns to decision block  562  where processing continues. If, however a failure did not occur, as determined in decision block  586 , decision block  592  determines if the test message was sent by RII subsystem  182 . If the test message was sent by RII subsystem  182  DDS read pipe process  432  returns to decision block  562  where processing resumes. If, however, the test message was not sent by RII subsystem  182 , the status of the transaction from the client tracker table is read for each transaction in block  594 . If the read fails, as determined in decision block  596 , a log error handler is called in block  598  and processing returns to decision block  562  where processing resumes. If, however, the read did not fail, as determined in decision block  596 , decision block  600  determines if the status of the received message is set equal to saved. If the status indicates saved the DDS process message is called in block  602 . If DDS process message  602  returns with a failure notification, as determined in decision block  604 , the DDS shutdown process is called in block  606 . If, however, the status does not equal saved, as defined in decision block  600 , or DDS process message  602  did not return a response of failure, as determined in decision block  604 , processing returns to decision block  562  where processing resumes. 
     Turning now to FIG. 10E, the processing flow for the DDS process messages process  602  is illustrated and will be discussed. The message is sent by the RII  182  to the DDS  194  and from the DDS  194  to NCS  214  to request a create/delete for a particular NPA-NXX. The body of the message comprises a header and message structure. The message structure is a service provider NPA NXX structure containing the contents of the message. The contents of the message structure comprises a service provider NPA NXX creation time stamp or IBAR time stamp, a service provider NPA_NXX effective time stamp or NPAC time stamp, a service provider NPA_NXX ID or service provider owner ID and a service provider NPA_NXX value. The process messages process begins in block  620 . Next, block  622 , the message header is copied into the body of the message that is to be sent to the targeted message queue ( 202 , or  204 , or  206 ). If the message has a status of saved, as determined in decision block  624 , the process proceeds to block  626 , which will be discussed herein in reference to FIG.  10 F. Next, block  628 , the saved message is unpacked. If a failure occurred unpacking the saved message, as determined in decision block  630 , the error handler is called in block  632  and a response of successful is called in block  634 . If, however, a failure did not occur unpacking the saved message, the IBAR time stamp is unpacked in block  636 . Decision block  638  determines if a failure occurred unpacking the IBAR time stamp. If a failure did occur unpacking the NPAC time stamp, the log error handler is called in block  632  and a response of successful is returned in block  634 . If, however, a failure did not occur the NPAC time stamp is unpacked in block  640 . If a failure occurred unpacking the NPAC time stamp, as determined in decision block  642  the log error handler is called in block  632  and a response of successful is returned in block  634 . If, however, a failure did not occur in block  642  the service provider owner ID is unpacked in block  644 . If a failure occured unpacking the service provider owner ID, as determined in decision block  646 , the log error handler is called in block  632  and a response of successful is returned in block  634 . If, however, a failure did not occur the create/delete request service provider NPA-NXX value is unpacked in block  648 . If a failure occurred unpacking the create/delete request service provider NPA-NXX value, the log error handler is called in block  632  and a response of successful is returned in block  634 . If a failure did not occur, the unpacked saved message structure is copied into the body of the message that is to be sent to the targeted message queue ( 202 , or  204 , or  206 ) in block  652 . Next, block  654 , the transactions status is updated to sending. If a failure occurred, updating the transaction status, as determined in decision block  656 , a log error handler is called in block  658 . If, however, a failure did not occur, as determined in decision block  656 , a message is logged in block  660  and the processed messages are sent to the targeted message queue ( 202 , or  204 , or  206 ) in block  662 . Decision block  664  determines if the return value from sending the queue messages is equal to too many messages. If the return value equals too many messages, processing returns to block  662 . If the return value does not equal too many messages, as determined in decision block  664 , decision block  668  determines if the return value is set equal to successful. If the return value is set equal to successful, as determined in decision block  668 , a response of successful is returned in block  670 . If the return value does not equal successful a log error handler is called in block  672 . Next, block  674 , DDS restart communications process is called, which is referenced to FIG. 10H, and the DDS recovery process is called in block  676  (FIG.  10 C). If, referring now to FIG. 10E, the message header does not equal saved, as determined in decision block  624 , decision block  678  determines if the message header equals sending. If the message header equals sending, processing continues to block  680 , where the process continues in FIG.  10 G. Next, block  682 , the sending message body is unpacked. If a failure occurred unpacking the sending message body, as determined in decision block  684 , the log error handler is called in block  686  and a response of successful is returned  688 . If, however, a failure did not occur, as determined in decision block  684 , the sending message structure is copied into the body of the message to be sent to the targeted message queue ( 202 , or  204 , or  206 ) in block  690 . Next, block  692 , the transactions status is updated to sending. If a failure occurred, as determined in decision block  694 , the log error handler is called in block  696 . Once the log error handler is completed, processing continues to block  700 . If, however, a failure did not occur, as determined in decision block  694 , the message is logged in block  698  and the processed messages are sent to the targeted message queue ( 202 , or  204 , or  206 ) in block  700 . Decision block  702  determines if the return value from sending messages to the message queue ( 202 , or  204 , or  206 ) is equal to too many messages. If the return value equals too many messages, processing returns to block  700  to continue processing. If the return value is set equal to successful, as determined in decision block  704 , a response of successful is returned in block  706 . If, however, the return value does not equal successful, the log error handler is called in block  708 . Next, block  710 , DDS restart communications process (FIG. 10I) is called and the DDS recovery process is called in block  712  (FIG.  10 C). If, now referring back to FIG. 10E, the IPC ID does not equal sending, as determined in decision block  712 , the log error is called in block  714  and a response of successful is returned in block  716 . 
     Turning now to FIG. 10H, the processing flow for the DDS restart communications process ( 514 ,  544 ,  674 ,  710 ) is illustrated and will be discussed. The DDS restart communications process ( 514 ,  544 ,  674 ,  710 ) begins in block  730 . If the target message queue ( 202 , or  204 , or  206 ) is opened, as determined in decision block  732 , the target message queue ( 202 , or  204 , or  206 ) is closed in block  734 . If, however, the target message queue ( 202 , or  204 , or  206 ) is not opened, communication with the targeted message queue ( 202 , or  204 , or  206 ) is terminated in block  736 . Next, block  738 , the message queue ( 202 , or  204 , or  206 ) is reinitialized. Next, block  740 , the communications with message queue ( 202 , or  204 , or  206 ) are restarted. If a failure occurred starting communications, as determined in decision block  742 , a error handler is called in block  744  and the DDS shutdown process is called in block  746 . If, however, a failure did not occur, as determined in decision block  742 , the process returns in block  748 . 
     Turning now to FIG. 10I, the processing flow for the DDS shutdown process ( 406 ,  424 ,  438 ,  448 ,  476 ,  496 ,  606 ,  746 ) is illustrated and will be discussed. The DDS shutdown process ( 406 ,  424 ,  438 ,  448 ,  476 ,  496 ,  606 ,  746 ) begins in block  760 , and decision block  762  determines if IBAR database  172  exists. If the connection to IBAR database  172  does exist, IBAR database  172  is disconnected from in block  764 . If IBAR date  172  connection does not exist, as determined in decision block  762 , or IBAR database  172  has been disconnected from in block  764 , decision block  766  determines if the target message queue ( 202 , or  204 , or  206 ) exists. If the target message queue ( 202 , or  204 , or  206 ) does exist, the target message queue ( 202 , or  204 , or  206 ) is closed in block  768 . If the target message queue ( 202 , or  204 , or  206 ) does not exist or the target message queue ( 202 , or  204 , or  206 ) has been closed, decision block  770  determines if the message queue is connected. If the message queue ( 202 , or  204 , or  206 ) is not connected the process ends in block  772 . If, however, the message queue ( 202 , or  204 , or  206 ) is connected the message queue ( 202 , or  204 , or  206 ) is disconnected from in block  774  and the process ends in block  776 . 
     While this invention has been described in reference to illustrative embodiments, the description is not intended to be construed in a limiting sense. Various modifications and combinations of the illustrative embodiments as well as other embodiments of the invention will become apparent to persons skilled in the art upon reference or description. It is, therefore, intended that the appended claims encompass any such modifications or embodiments.