CA2243386A1 - System and method for achieving local number portability - Google Patents

Abstract

A system for maintaining a customer's telephone number when a switch from one service provider to a second provider is made interfaces with a regional customer number database to keep track of local numbers and the corresponding local service provider which services each number. Service providers interface with the database and obtain information at the telephone number level that permits individual providers to determine which carrier is providing service to which telephone number. A neutral third party maintains and administers the database allowing free access by any participating provider.

Description

., MCI RefNo.: CAR-97-019 Attorney Docket No.: 3030-2047 SYSTEM AND ~'IETHOD FOR ACHIEVING
LOCAL NUMBER PORTABILITY

TF,CHNICAr, FTF,T,n ;-The present invention relates in generàl to the field of telecommunicationsand more specifically to a system and associated methods for keeping a customer's telephone nurnber when a s~itch is made from one telecomm-~nic~hons service provider to another.

., ,~

BACKGROU~I~ OF I~ VENTIOI'~

Withou~ 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 5 competitive and sophisticated network of equipment manufacturers and service providers. Since the early 1980s, the industry has seen a shi~ from pure analog techniques over copper wire to digital techniques using fiber optic cabling. Today, customers can choose from a large array of consurner telecommunications services including local and lon~ distance calling~ 800 and 900 calling accounts, TCP/E' (i.e.
10 the "Intemet") and others.

Typically, a teleco~ unications customer obtains access to such services by establishing an account with a service provider. The ser~ice 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 nurnber can be the local 15 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 autornated system for a switched connection to a network element such as a domain server. Other examples include, but are not lirnited to, a customer's facsimile machine, cell phone number or voice mail.

At the sarne time industry deregulation has brought about the entry of .~_ multiple service providers within single geographic re~ions. In addition to competition, t~e 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 accornmodate a host of 5 services. Thus, a comrnon situation has evolved wherein a single customer will have a home number, an of fice number, a facsimile machine nurnber, a cell phone number, an Tnternet account number and possibly others, as examples.

Today's service providers employ advanced inforrnation technology systerns using sophisticated equipmcnt such as routers, switches and digital cross~or~ects.
10 At a minimum, the eq~l;pment must be configured to ensure calls reach their destination regardless of the service provider. While industry standards and co~u~lications protocols have been adopted by the industry, cooperation amorlgst service providers has been critical to implementing a reliable network. Today, a customer can place a clear noise free call firom alrnost anywhere in the world.

The Public Switched Telephone Network ("PSTN") comprises the telecommunications backb~ne 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 destin~tion on the PSTN. This 20 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 m~int~in the sarne local nurnber even if the S customer remains at the same location. Thus, until the present invention, there was no way to port a customer's number from one service provider to another within the same local region. -In short, as competition for communications services has grown so has thevalue attached to a customer's telephone nurnber. At present, different "LRNs" are 10 used arnong different service providers. 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 nurnber not already in use by another customer.

While long distance carriers have enacted portability solutions on a regional 15 or even national basis for certain classes of services, such as 800 and 900 accounts, the local portability probtem 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 for ned, pursuant to the Illinois Comrnerce Commission Order on Customers First Plan (Docket 94-0096 dated April 20 7, 199S), 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. ~or did the commission establish the hardware and soft~vare interfaces required to implement a nationwide portability solution.

Thus, a need exists for a system and method of achieving local nurnber S portability on a nationwide basis. A system and method of sharing a single telephone number over different local exc~nge carriers would fill a void not presently addressed by the pIior art.

SUI~IMARY QE ~E IN~NTIO~

As such, a primary object of the present invention is to provide a hardware and software platforrn to effect the porting of local telephone numbers from one service provider to another. The systems and subsystems of the invention are 5 designed to commuIucate with a Number Portability Administration Center Service Management System ("NPAC/SM;,S") which receives and stores updated customer routing information and makes it available to participating service providers. The NPACISMS contains a record of all portcd numbers and a history file of all transactions relating to the porting of a number.

Another object of the present invention is to provide a system for Local Number Portability ("LNP") that submits service orders changes to a NPAC/SMS.
In this regard, a Service Order A~ministration ("SOA") subsystem is provided as means of entering and submitted services order changes to the NPAC/SMS via an intefface that supports the retrieval and update of subscription, service provider and 15 network infolmation. A ~raphical user interface or a message-based interface to a service provider's upstream systems may be used for this puIpose.

Another object of the present invention is to provide a facility for ?~mini.stering the service provider subscription inforrnation relating to a particular customer. rn this regard, the SOA is equipped with a host of functions for creating, 20 canceling, acknowledging, modifying, retrieving, activating, disconnecting and removing subscription version inforrnation. The SOA has an audit capability that perrnits audits of a customer's porting activity based on a telephone number and receives notifications frorn a NPAC/SMS to ensure that it is fully inforrned of relevant events relating to a service provider's subscriptions.

Still another object of the present invention is to provide the interface structures that permit service provid,e~rs to read and update their own service provider information within a NPACISMS. In this règard, the interface permits service providers to update the inforrnation in their service provider profile as well as add and delete their own network data. The inforrnation is accessible to all service 10 providers via a standard interface to assure correct call routing.

Another object of the present invention is to provide a system that interfaces directly with existing tclecommunication equipment operated by all service providers. In this regard, a new service provider can obtain authorization to port a customer using a standardized message format that notifies an old service provider 15 according to processes interrl~l to the old service provider. The mec.~aging format includes signal protocols tnat can be used by both tne old and new service providers to sends update notifications to the NPAC/SMS using the SOA. Upon receipt of the notification(s), the NPAC/SMS perforrns certain validation checks, and attempts to match a notification reccived from the new service provider with a concurring 20 notification that may be sent from the old service provider, permitting the two service providers to complete the port.

Yet another object of the present invention is to provide a means of downloading subscription and network data from a NPAC/SMS to the local service provider's applications for correct call routing and network provisioning. In this regard, an lnterface Broadcast Agent ("IBA") subsystem is provided as a means of 5 interfacing a service provider's downstream systems with the NPAC/SMS. In one embodiment, the lBA subsystem is configured to automatically receive new network or subscription data or modifications to existing data The E3A may also request data using a do~vnload request. The request can be based on time range, telephone number, telephone nurnber range or other indicator. A service provider can also 10 directly read the data from the NPACISMS.

The invention provides the software and hardware platforms for achieving Local Nurnber Portability. A central or regionalized database is used to keep track of local numbers and the corresponding local service provider that services each number. Service providers interface with the database and obtain inforrnation at the 15 telephone number level that perrnits individual providers to determine which carrier is providing service to which telephone nurnber. A neutral third party m~int~in~ and a~minictlors thc database allowing free access by any participating provider. Methods for transferring a customer's port data from an old service provider to a rlew service provider are also disclosed.

Disclosed, in one embodirnent, is a system for m~int~ining a customer's local telephone number when a switch is made from a first service provider to a second service provider. The system uses a regional number portability subsystem containing a plurality of telephone number porting data defining how to route a call from one service provider to another. A service order application is cornmunicably linked to the regional number portability subsystem and configured to send a porting S request for a specific customer to the portability subsystem and service providers interfaced to the subsystem. A local service management application is comrnunicably linked to the regional number portability subsystem via a second data pathway and configured to receive the porting request. The local service management application supports the interface to the second service provider and 10 delivers the porting request cont~ining the new routing data for the customer allowing the customer to m~int~in their existing telephone number once the switch is made.

For a more complete understanding of the present invention, including its features and advantages, reference is now made to the following detailed description, 15 taken in conjunction with the accompanying drawings.

B~FF DF.SCR~PTION Q.E 1~ l~ WINGS
In the drawings:
Figure I is an overall process flow diagrarn for the method used to transfer a customer's port data from an old service provider to a new service provider 5 according to one embodiment of the invention;
Figure ~ is a high level block diagram for the interface between a Service Order Adrministration ("SOA"), an Interface Broadcast Agent ("IBA'~ and a regional number portability ~minj~tration center according to one embodiment of the invention;
10Figure 3 is a block diagram of the SOA and IBA subsystems and their interface to various business applications;
Figure 4 is a block diagram of an SOA broken down into its component subsystems according to one embodirnent;
Figure S is a block diagram of the IBA broken down into its component 15subsystems according to one embodiment;
Figure 6 is a detailed block diagrarn of the Interface Broadcast Agent Repository subsystem brok~n down into its component subsystems; and Figure 7 is a block diagram illustrating the Order Entryl Order Processing interface subsystem according to one embodiment of the invention.
20Coll~s~ollding numerals in the drawings refer to corresponding parts unless otherwise indicated.

.
,,,_~ .

nETAI~.EI) ~ESC~PTIO~ QE ~IE INVE~l~ON
Turning now to Figure l, ~ flow diagram of a telephone number porting process, denoted generally as 10. is shown. In general, process 10 is used by a customer 12 to achieve Local ~umber Portability ("LNP") when switching from one S service provider 14 to another 16. As shown, a customer 12 initiates the process 10 by contacting either an old service provider 14 or a new service provider 16 to arrange a transfer of the customer's porting data from the old service 14 to the new service 16. The communications be~een the customer 12 and the old service provider is indicated by link 13 while link 1~ represents the cormnunications link 10 with the new service provider 16. Therca~er, the old service provider 14 and new service provider 16 comm-~nicate via link 17 with each other in order to a~Tange a data port for the customer 12.
Once the new service provider 16 has obtained the customer's port data, the provider 16 notifies the Number Portability Adrninistration Center Service 15 Management System ("NPAC/SMS'~ 18 of the pending port prior to ~ctivation. The interface between the new service provider 16 and the MAC/SMS 18 is supported by link 19.and conforms to'recognized industry standards such as the "NPAC/SMS
Interoperable Interface Specification", version 1.0, by Lockheed Martin IMS
Corporation, October, 1996. In general, the NPAC/SMS 18 m~int~inc a centralized 20 regional number database for all customers in a given region and receives the port request from a new service provider 16.
According to the invention (see Figures 4 through 7), an interface is established between the ~PAC/S~IS 18 and the participating service providers permitting the transfer of the customer's port data.
A customer's port request is communicated to either the customer's old service provider 14 or a ne-v service provider 16 to the NPAC/S~IS 18. After the port request 19 has been received by the NPAC/SMS 18, the NPAC/SMS 18 communicates with the old service provider 14, the new service provider 16 and all other service providers 20, via links 25, 23 and -21, respectively, to activate the port.
This permits a customer 12 to port his existing number from an old servicc provider 14 to a new service provider 16 while at the same time notifying all other service 10 providers 20 within that region that the port has been completed allowing proper call routing.
With the knowledge that the customer's number has been ported from one provider to another, all service providers 14, 16, and ~0 can configure their networking equipment for correct call routing within that region. The particular 15 embodiment of the present invention incorporates significant advantages in that it allows for the serl~ling and receiving of porting data from regional databases (i.e.
maintained at the NPAC/SMS 18) providing for a smooth transition from an old service provider 14 to a new service provider 16.
Turning now to figure 2, a block diagram of a system for achieving local 20 number portability is shown and denoted generally as 30. Specifically, figure 2 shows that thc regional NPAC/SMS 18 is cornmunicably linked to ~o functional - sub-systems, a Service Order Administration ("SOA") sub-system 32 and an ., ~ .

Interface Broadcast Agent ("IBA") sub-system 34 via communications links 33 and 35, respectively.
The SOA 3~ is the responsible application that sends the customers port data from one service provider to another service provider. Likewise, the IBA 34 is the S responsible application for service management processes at the local network level.
The SOA 32 and IBA 34 work together with the NPAC/SMS 18 to send and receive customer porting data from regional call routing centers and data sourcoe to more centralized inforrnation sources and applications. This configuration 30 provides a distributed architecture which allows the porting of data to the local applications and 10 networking equipment maint~ined by service providers for a~y~ iate call routing and processing In one embodiment, the SOA 32 is communicably linked to one or more local applications 36, which are maintained by thc rcgional service provider. Examples of the local applications 36 include, but are not limited, to local residential and 15 business lines for voice, data and fax cornrnunications as provided by the local service provider. The local applications 36, in turn, are commllnie~bly linked and used by other service providers 38, other Complex Local F.xch~nge Carriers ("CLEC") 40 and yet other Local Exchange Carriers ("LEC") 42 depending on the existing network of service providers. ~t is the SOA 32 that acts as an inte~nediary 20 between the local applications 36 and the regional NPAC/SMS 18 thus providing a smooth non-intrusive solution for local nurnber portability.
Likewise, the lBA 34 provides tht interface between the regional NPAC/SMS

18 and a plurality of other network entry systems such as those shown in boxes 44, 46 and 48. The specific functionality of the network entry systems 44, 46 and 48 may vary but in general they form a platfo~m for receiving, storing, and routing customer port data. E.Yarnples of services that use the port data include local and 5 long distances networlcs and 800 services.
For example, business applications 48 can comprise a ~t~b~e of records for all provider systems needing access to the customer porting data. An example well known to those skilled in the art is the ANI reference information system. The local net~vork interfaces 46 can be an intelligent network architecture that supports routing l 0 queries dunng call processing. An example of a network interface 44 would include the Metro Intelligent Network Architecturc that forms a tie-in into available communications services. Such services may include an 800 or 900 ser~ice or other silnilar offerings that may require access to the port data through a regional toll switch network from the N~PAC/SMS 18 for correct call servicing and routing.
While figure 2 illustrates a single embodiment for achieving local number portability, it should be understood that other architectures may be similarly conceived and reduced to p'ractice upon reference to this disclosure. It is anticipated therefore, that such other cmbodiments are well within the scope and spirit of the present invention. Specifically figures 4 through 7 disclose detailed architectural 20 designs, in the form of block diagrams, for various subsystems, including an SOA
32 and IBA 34, which may be used in a specific and preferred embodiment for achieving local number portability.

, Tuming now to Figure 3. a diagram illustrating the interaction between the NPAC/S~S l 8. the SOA 32 and the IBA 3~1 sub-systems is shown and denoted generally as 50. Customer Order Entries and Order Processing ("OE/OP") at the local level are represented at 62, which as shown is coupled to iocal SOA engine 58.
5 The SOA engine 58 feeds customer telephone information into the regional SOAs 54 located in various regions. The SOA sub-system 32 comprises the regional SOAs 54 and SOA engine 58. While the use of three (3) regional SOAs 54 in figure 3, it is envisioned that each region providing local nurnber portability will have a corresponding SOA 54.
An interface between the SOA sub-system 3~ and the NPAC/SMS 18 computer processing systems 52 is shown by lines 51. The SOA sub-system 32 sends the port data to systems 52 which, in turn, relay the port request irl a pre~le~ned message forrnat to the I13A sub-system 34.
Likewise, the IBA sub-system 34 comprises a plurality of regional IBAs 56 15 that update the IBA repository 60. The 113A repository 60 is accessible by a plurality of downstrearn applications such as business applications 64 and network provisioning and configuration systems 66. It should be understood, however, that any type of downstream system can be connected to the IBA repository 60 at the option of the scrvice providcr. In this way the porting data is distributed to existing 20 network applications, such as long distance and local business, for proper call routing and processing.
The SOA subsystem 32 provides the means for submitting customer service i order changes to the NPAC/SMS 18. Tuming now to figure 4, the SOA ~2 is shown broken down into itS functional components. LNP transactions originating either from a GUI interface or the SOA Engine 80 are received through stored procedures 82. The stored procedures 8~ place the transaction informat~on into the outbound 5 link 84 and received by the SO~ Message Handler ("SMH") 86 that reads and processes the inforrnation. The SMH 86 queries the SOA Database 81 for any required extra inforrnation and passes the transaction onto the SOA Manager ("SMG") 98, which sends the transaction to the NPAC/SMS 18 and waits for a response. When the response is received from the NPAC/SMS 18, it is routed back 10 to the SMH 86, which then loads it into an inbound link 84 for the stored procedure 82.
The SMG 98 also receives notifications from the NPAC/SMS 18.
Notification transactions are passed onto the Unsolicited Event ~n-llçr ('~EH") 90 which, in turn, processes the transactions and updates the SOA database 81 when 15 necessary.
Also shown is a Resynch Subscription Version Process ("RSP") 88 coupled to the SOA database 81 ~vh~re it is used to synchronize the SOA subsystem 32 after a period of downtime. After the SMG 98 binds to the NPAC/SMS 18, the RSP 88 is started. In operation, the RSP 18 requests from the NPAC/SMS 18 all subscription 20 versions that have a modification time-starnp more recent than the last time the SMG
98 had an association with the NPAC/SMS 18. The RSP 88 also sets a downtime flag in an audit database tables to in~is~te that an audit was ongoing during a period of downtime.
The [BA Subscription Version Report ("ISVR") 9~ is used to report discrepancies between the SOA Database 81 and IBA Database 102. The Check Link 96 monitors the physical coMection between the SOA 32 and NPAC/SMS 18.
5 If the physical connection is broken, the Check Link 96 will reset the SOA subsystem 32.
All the processes within the SOA subsystem 32 (with the e~cception of the lSVreport 92) are monitored by the Process Monitor 94. The Process Monitor 94 starts applications when they are required and if an application termin~tes, the 10 Process Monitor 94 is notified. The Process Morlitor 94 automatically restarts applications that are int~ d to always be run~ng, like the SMG 98 and Check Link 96, if they te~minate. The one exception is the ISVreport 92 which is operator controlled and is not mor~itored by the Process Monitor 94.
In the preferred embodiment, the Process Monitor 94 is the parent process for l 5 the SOA 32 and n3A 34 subsystems. The Process Monitor 94 will watch over all of the standard processes required to run the subsystems 32, 34 and keeps a table of all applications spawned andbperational information about each such application.
The SOA Message Handler 86 allows the GUI component of the SOA 32 to communicate with the NPAC/SMS 18. In one embodiment, multiple instances of the 20 SOA Message Handler 86 are run to allow for greater throughput wherein each such instance of the SOA Message Handler 86 receives requests from a single outbound link 84. Thus, all output to the stored procedures 82 is done through separate links, ~17--- , _ 7~

one for each GUI workstation The SOA Message Handler 86 receives messages from the GUI via the outbound link 8~. Messa~es are processed, data acquired and organized by tasks which preferably are broken down at an object level (i.e. Subscription Version, 5 Audit, Service Provider, and Network). Based on a message identifier, the SOA
Message Handler 84 is configured to collect and assemble the information required by the NPACt SMS 18. ..
In one embodiment, messages are relayed to a DSET Distributed Systems Generator ("DSG") Manager through a UNIX sockets interface. The DSET DSG
10 Manager is used to irnplement the interface between the SOA 32 and the NPAC/SMS
18. The UNIX sockets arc used for the interface between the ~3A Agent 112 (See figure 5) and other IBA applications as well as the SOA Manager 98 and other SOA
applications.
All outgoing messages that go to the NPAC/SMS 18 are logged. The SOA
15 subsystem 32 then waits for a response (successful, failure or timeout) from the DSET DSG Manager. The SOA subsystcm 32 processes any data received with the reply, updating the SOA d'atabase 81 where required, and relays the request result back to the GUI application through one or inbound link(s) 83.
The Unsolicited Events Message Handler 90 is used by the SOA subsystem 20 32 to handle notification data received from NPAC/SMS 18. The Unsolicited Events Message F~ntller 90 starts up by making a connection to the UN~ sockets and then waiting for a message to be sent from the DSET DSG Manager.

_ .

When a messa~e is ieceived ~y the Unsolicited Events Mess~ge Handler 90 from the DSET interface aaent, the Unsolicited Events Mess~ge Handler 90 deterrnines the type of message and performs the required actions for that message type. When the action is complete the Unsolicited Events Message Handler 90 S forrnats and sends a reply to the DSET DSG Mana~er which translates the message into a CMIP event and sends the event to NPAC/SMS 18. The Unsolicited Events Message Handler 90 resumes waitlng for the next message to appear in the UNIX
socket.
As stated the SOA Database 81 is used to store and m~int~i~ the current 10 number information for a customer. Table 1 below is doma~n field listing for an SOA Database 81 according to one embodiment:

~lamo Code Label Type Bi'l _'' ~=~ BILLING_ID Billing Identilier VARcHAR2(4) u l BOOL_iND Boolcan Indicator NUM8ER(I) City CITY VARcHAR2(2o) CLASS DPC CLASS_DPC VARCHAR2(9) CLASS SSN CLASS_SSN NUMBER(3) CNAM DPC CNAM_DPC VARCHAR2(9) CNAM SSN CNAM_SSN NUM8ER(3) ContactType CONTACT_TYP Contact Type VARCHAR2(2) Country COUNTRY VARcHAR2(2o) EndUserLocationType END_USER_LOC_TYPE VARcHAR2(2) EndUserLocarionVaiue END_USER_LOC_VALUE VARcHAR2(l2) Idennfler ID NUMBER(10) Identifler 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) LNPtypo LNP_TYPE NUMBER(I) LRN LRN VARcHAR2(lo) NPA NXX ;'IPA_NXX NPA-NXX VARCHAR2(6) NPA NXX NPA_N~CX2 NPA-NXX VARcHAR2(6) OpcraaonAction OPER_ACT Operanon Action NUMBER(3) Posul Codo PC Postal Code VARCHAR2(40) ServProvlD SP_ID VARcHAR2(4) ScrvProvlD SP_ID2 VARCHAR2(4) sulcr~ ;,. c STATE_PROV Sute/Provincc VARCHAR2(2) Sutus STATUS Sutus Fl~g NUMBER(10) Systemrype SYSTEM_TYPE NUMBER(I) Te!:,h ~Nu.~ . TN Telephone Numbcr VARCHAR2(10 Timesump T2 DATE

~, r N~me Code L~bel Type Timeslamp T DATE
T~ r~ ,,",~ TUNABLE_NAME Tun~blc N~me VARCHARl(40) Tun~blcV~luc TUt~AE~LE_VALUE runabl~ Valu~ VARCHAR2(~0) Uscrldentifi~r USER_ID VARCHAR~(30) VARCHAR2(9) T~blel:DomlinListforoneEmbodimentoftheSO~ D~t~b~se81.

Turning to figure 5, the Regional Interface Broadcast Agent ("RIBA") ;6 is broken down into itS component subsystems. In general, RIBA ;6 provides the interface between the NPAC/SMS ~;8 and the ~nterface Broadcast Agent Repositor,v ("IBAR") 110. In the preferred embodiment, requests are forrnatted using a 5 Cornmon Message Managcment Information Protocol ("CMIP") and once received by the IBA Agent 112 and are then forwarded to any one of ~e ~BA Message Handlers ("IMH") 114, 122, 124, 126 or 128. Preferably, four (4) I~Is are used, each h~n~l~ina CMIP requests for a specific object type: one for subscription versions 122, one for service provider networks 124, one for LRNs 126 and one for NPA-10NXXs 128. Each IMH 122, 124, 126 and 128 handles the C~P requests which are received and updates the IBA Database 102. The IBA Agent 112 also receives notification, recovery complete and action transactions. These transactions are forwarded to ay~ropl;ate logging functions, which, in turn, process and handle the tIansactions and update the ~BA database 102.
15Upon startup, the 1:13A Agent 112 reads each data item (subscription version, LRN, NPA/NXX, etc.) from the RIBA database 10~ and load them into memory .
These data items forrn the Managed Instance Tree ("MIT") used by the RIBA 56 as reference points to the stored data during its operation. Once the reload has , completed, the IBA A~ent 11~ binds to thc NPAC/SMS l8. When the bind has been successfully established. the ~BA Agent 112 requests that the NPAC/SMS 18 download all of the subscription, NPA-NXX and LRN data which was acc~ ed duIing the time that the IBA Agent 11~ was not bound to the NPACISMS lg. Upon 5 successful completion of the download, the IBA Agent 11~ informs the NPAC/SMS
18 that the download has been completed and normal processing resumes.
In one embodiment, the IBA Database 102 is updated ~om files using the ~ile Transfer Protocol ("FTP") as illustrated by blocks 130 and 132. The FrP
applications 130 and 132 are controlled by an operator which involves the steps of reading the subscription version 130 and service provider networlc information 132 to form a file and update the a~plop.iate database tables with the new information.

Table 2 is a domain field listing for an the IBA Database 102 according to one emborliment:

Name Code Lsbel Type b~ n~r~ntifi~r BlLL~(i ID Billing Idcntifier VARCHAR2(4) boole~n~n.li~tor BOOL_IND Boolean Indicator NUMBER(I) city CITY VARCHAR2(20) CLASS DPC CLASS_DPC VARCHAR2(9) CLASS SS~ CLASS SSN Ntl~ER(3) CNAM DPC CNAM_DPC VARC~R2(9) CNAM SSN CNAM_SSN NUMBER(3) contactType CONTACT_rYPE Cont~ct Type VARCHAR2(2) country COUNTRY VARcHAR2(2o) endUscrLocltionType END_USER_LOC_TYPE VARCHAR2(2) endUserLocatianValue END_USER_LOC_VALUE VARCHAR2(12) identifier ID NUMBER(10) ISVM DPC ISVM_DPC VARCH~R2(9) ISVM SSN ISVM_SSN NUMBER(3) LIDB DPC LIDB_DPC VARCH~R2(9) LIDB SSN LIDB_SSN NUMBER~3) LNPtype LNP_TYPE NUMBER(I) LRN LRN VARCHAR2(10) NPA NXX NPA NXX NPA NXX VARCHAR2(6 opcr~ionAction OPER_ACT NUMBER(3) Name Code L~bel Type ,,r.,~ nld ORGNZ_ID ID numbe~ ol an VARcHAR(3) .lion, clicnt. NPAC.
rc~ion31 IBA.
Post~l Code PC Post~l Code VARCHAR~ 0) servProvlD SP_ID VARCHAR7(~) st~tePr~vince STATE PROV St~ rovince VARCI~IAR2(2) status ST~TUS Sl~lus FlDg NUM8ER(10) systemType SYSTEM_TYPE Nl ,l OI~C~ - ~I Tel~phone Number VARCHAR;!(lo) times~amp T DATE
tunsblcNamc TU~A8LE_NAME Tun~ble Nlme VARCHAR~(40~
tunnblcVIluc TUNABLE VALUE Turllblc Vlluc VARcHAR2t4o) U5cr;i 'ficr USER_ID VARcHAR2(3o) ZIP VARCHAR2(40) T~ble~:Dom~infieldlistfor B A Dat~b~se.
All of the applications wi~hin the RIBA subsystem 56 (except the FTP
processes 130 and 132) are monitored by the Process Monitor 134. The Process Monitor 134 is responsible for invoking applications when they are required and if a process te~in~tes the Process Monitor 134 is notified. Applications that are int~ ed to always be run~ing are automatically restarted by the Process Monitor 134 if they terrnin~te.
Any transactions received by the lBA Agent 11~ are forwarded to the a~ .pliate logging applications such as the IBA Notification Logger 116, the ~3ARecovery Complete Logger 118 or IBA Action Logger 1'0. Each of the logging applications 116, 118, 1~0 handle the transactions and update the D3A Database 102.
The IBA Database 102 can also be updated from flat files by the FTP
Network Download 132 and FTP Subscription Version Download 130 applications.
The Check Link application 136 monitors the physical connection between the RIBA 56 and ~PAC/SMS 18. If the physical connection is broken, Check Link 136 will reset the RIBA subsystem 56.
All the processes within the RIBA subsystem ~6 (with the exception of the _ FTP processes 130 and 132) are monitored by the Process Monitor 134. Thus, the Process Monitor 134 is the parent process for both the SOA 3' and RIBA 56 subsystems and watches over all of the standard processes required to run each system. The ~BA Message Handlers ("IMH") 122, 124, 126 and 128 are used to accept messagcs from NPACISMS 18 and to perforrn the required actions on these messages.
The IMHs 122, 124, 126 ana 128 aLso rçceive messages ~om the NPAC/SMS
18 requesting operations to be performed on the database tables of the IBA Database 102. Examples of these operations include SET, CREATE and DELETE. When the NPAC/SMS 18 sends a message to the RrBA 56, it is received by the DSET DSG
Agent, validated and stripped of protocol related information. The DSET DSG
Agent determines which ofthe four IMH applications (Service Provider 124, NAP-N~ 128, LRN 126 and Subscription Version 122) the message is addressed to and sends the data to the co~ onding application process via a UNIX socket interface.
When the applol)liate IMH (either 122, 124, 126 or 128) accepts the message, thedata is then extracted from the message and the operation is detennined. An SQL
statement is built for the action with the data values extracted from the message and the SQL statement is performed, updating the D3A Database 102.
The Network Download File Transfer Protocol 132 is used to restore the E~A
Database 102 and rBAR 110 from the NPAC/SMS 18 via FTP/TCPIP. The iBAR
110 provides a means for holding and distributing the data received from the NPAC/SMS 18 to all thc various downstream systems maintained by the service provider. In the preferred embodiment. all activities from the download file transfer are logged. The Subscription Version Download File Transfer Protocol 130 may also be used to restore the IBAR 110 and RIBA database 102 from theNPAC/SMS 18 using FTP/TCPIP. Preferably, the activities from the download file transfer are logged.
In use, the NPAC/SMS 18 sends variable length create requests to the Cl~
Agent 112 consisting of subscrip~lon data and a list of one or more telephone nurnbers for each subscription data element. The cMrp Agent 112 extracts the create request from the CMIP message and forrnats it into a structure suitable for use by the IBA Action Logger 112 which, in tum, extracts thc subscription version data fromthe structure.
The ~3A Notification Logger 116 is used to log notifications received by the CMIP Agent 112. In this way, the ~PAC-SMS Operational Inforrnation and VersionNew NPA-NXX notifications are logged. The C~P Agent 112 receives these notifications from the NPAC/SMS 18, formats the inforrnation into a usablestructure and forwards the structure to the ~3A Notification Logger 116 over a UN~
socket. The IBA Notifica~ion Logger 116 is started by the Process Monitor 134 atthe request of the CMIP Agent 112.
The rBA Recovery Complete Logger 118 is used to log Recovery Complete Replies and Download Replies sent by the NPAC/SMS 18 to the II3A Agent 112.
The IBA Agent 112 receives these actions from the NPAC/SMS 18, formats the inforrnation into a usable structure and for~,vards the structure to the rRA Recovery -t4-Complete Logger 118 over a I~NIX socket. The E3A Recovery Complete Logger 118 is started by the Process Monitor 134 at the request of the IBA Agent 112.
A particularly advantageous aspect of the present invention is that it provides interfaces from the Interface Broadcast Agent Repository 110 to intemal systems operated by the individual service provider. In one embodiment, four proprietarydownstream systems have been coupled to the IBA~ llO for receiving data. The Networlc Control System ('~CS~) and RTE7 systems manage local number portability information in the long distance environment while the Metro Intelligent Ne~vork A~Tninic~ation Scrvice Management System ("MINA/SMS") is configured to manage local nurnber portability irLformation on the local service network level.
Also, the ANI Reference Information System ("ARIS") collects local number portability ("LNP") information for distribution to service provider business systems 44, 46 and 48.
As such, and according to one ernbodiment of the invention, the IBAR 110 supports the following features:
- A facility to consolidate LNP data from the RIBA Database 102 into the IBAR 1~0.
- A data distribution application that manages distribution of data to the ARIS, MINAJSMS, and NCS 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 preferably using the DECmessageQ product from Digital Equipment -~5-Corp - An on-line interface to the MrNA~SMS system preferably using Service Builder System Management Interface product from Northem Telecom.
- An on-line interface to the ARIS system preferably using the Registry Messa~ing product from MCI.
- A batch interface t~the RTE7 !ong distance support system using FTP. A database update application (the RII subsystem) reads the data from the message queue and performs the necessary database updates in the I~AR 110.

In one cmbodiment, a stored procedure extracts data ~om the IBAR 110 and writes the data to one of three links, each dedicated to one of the downstream on-line interface applications. Data ~om each link is read by a dedicated data distribution l 5 application (part of the DDS subsystem 170 sho~,vn in figure 6) which will in turn broadcast it to dedicated mcssage queues for the ARIS, MINA/SMS and NCS request processing applications.
The Process Monitor 134 provides the means to start and stop the IBAR 110 and monitors each application or restarts any application which terminate 20 abnorrnally.
Turning to Figure 6, the subsystem for the Interface Broadcast Agent Repository ("rBAR") is shown and denoted generally as 110. An rBA Queue Processor ("IQP") 150 is responsible for sending all the changes that the RIBA
subsystem 56 receives from the NPACJSMS 18 to the IBAR 110. The IQP
subsystem 150 is also responsible for ensuring all records of transactions on the RIBA 56 are delivered to the IBAR 110.
In operation, the IQP subsystem 150 processes records from a specific database table and puts the inforrnation into a message queue 152. The IQP
subsystem 150 will process all res~onses from the IBAR system 110 and make the appropriate updates to the table. The IQP subsystem 150 numbers each message before it is put into the message queue 152 to ensure the messages are delivered in sequential order. The IBAR 110, in turn, verifies that the message read is the rlext consecutively numbered message from the RIBA 56.
I~ one embodiment, the IBAR 110 responds to each message sent as to whether it was successfully applied, rejected due to validation errors, or needs to be resent. If the number is out of sequence then the I:BAR 110 iss~es a "resend" of the lS specific message and any messages that have been put into the Message Queue 152 after that specific message. rf the specific message requested for resend cannot be found, a "lost" message notification is sent and the resend continues.
The RIBA to ~BAR Interface ("RII") lS4 is responsible for keeping the IBAR
110 up to date with the changes that occur on the RIBA 56. The RII 154 receives messages from a RIBA 56 via the Message Queue 1 ~t, interprets the messages and performs the appropriate database functions. Multiple instances of the RII 154 may be run to accomrnodate various types of NPAC/SMS 18 including the ones that are ..

operated by Lockheed-Martin and Perot. RII 154 will call stored procedures 158 to perfo~n the database transactions and to populate links 160 with the inforrnation stored in the LBAR Database 162.
In the preferred embodiment, the RII 154 receives messages from the RIBA
5 56 via a specific message queue 152. Messages are processed, and the underlying message data acquired and organized by tasks broken down at the 'object' level (i.e.
Telephone Number, Audit, Servic~Provider, and Network). The Database 162 is updated with the 'object' data and at the end of a success~l transaction, the RII 154 will issue a confirmation message to the message queue 152.
The RII 154 verifies each mess~ge received from the RIBA 56, to erlsure that no duplicate messages from the RIBA ~6 are processed. This is accomplished by each RIBA 56 tagging all messages with trackIng nurnbers. The R~I 154 subsystem records all tracking numbers associated with a RIBA 56 and matches the record with the tracking number in the IBAR database 162. This provides the ability to track 15 messages from any RIBA ;6.
The RII 15~ also has the ability to receive messages from various types of NPAC/SMS 18. Each ~PAC/SMS 18 may have different information that is to be sent to the RIBA 56 and then the IBAR 110. Since each NPACISMS 18 could have different information to send and thus a version lD is used to identify the type of 20 NPAC/SMS 18 reviewing a given region. In the RIBA 56, the information is mapped to set structures and sent through the message queue 152. The RII 154 subsystem is able to reco~rLize the type of structure that was populated by the RIBA

56 and map the infom~ation to the appropriate database fields. The use of the version ID allows for multiple NPAC/SMS 18, via the RIBA 56, to send all information to one message queue 157 Also shown is a Data Distribution Subsystem ("DDS") 170 which sends transactions to a second message queue 17' for a downstrearn interface. Preferably, multiple Data Distribution application formats are supported includin, NCS 174, ARIS 176 and MINA 178, one ~r each of the downstream interfaces. In one embodiment, data is retrieved from an Oracle pipe 160 and forwarded to an interface subsystem on the message queue 17~. Once the message has been sent to the downstream interface, the record in the IBAR Database 162 will have its status changed to "Scnding" in~;catlng that the message has been sent to keep track of the state of the transaction.
In one implementation, the Downstream Intefface Subsystem ("DIS'~ 180 supports four proprietary interfaces: the MINA/SMS 18 , ARIS 184, RTE7 186 and NCS 188. It should be understood, however, that any interface may be supported depending on the subsystem supported by the seIvice provider. With the proprietary interfaces, the DIS 180 allows the IBAR 110 to communicate with e~t~ systems us~ng the following mecl~ni~m~:
- The MINA/SMS interface 182 is implemented as a stream of data sent via a TCP/IP socket interface using SMI protocol.
- The NCS interface 188 is implemented using the ported telephone number and request Service Provider NPA-NXX data received from the Data Distribution Subsystem 170 from the message queue 1~2 and sent to the ~CS. Preferably, the communication is set up as a two-way dialog, i.e. IBAR 110 sends data to the NCS, and the NCS
replies af'ter processing thc data.
- Ported telephone number data received from the l:)ata Distribution Subsystem 170 on message queue 172 and sent to ARIS 186 using MCI RegistIy or a ~imilar cornmunications protocol.
- The RTE7 interface 188 is implernented as a file of ASCII based data sent via TCP/IP using FTP software Preferably, this file is created on a regularly scheduled basis in batch mode.
In one embodiment, three (3) real time on-line interface applications are found in the DIS 180 that support NCS 182, MINA/SMS 184, and ARIS 188. A user is able to access a menu from which he/she can select one of the following optiorls:
1. - disconnect from NCS msgQ

2. - connect to NCS msgQ

3. - logoffMINA/SMS session 4. - logon to MINA/SMS session 5. - deregister from ARIS registry 6. - register with ARIS Registry In response to a selection, the Service Configuration and Management Application ("SCM") 202 will send a signal to one of three DIS applications 182, 184 or 186. In the UNIX operating environment, two signals are used: SIGUSRI and SIGUSR2. The SIGUSRI signal is used for "connect" and "logon" comm~n-ls with the SIGUSR2 signal reserved for "disconnect" and "log off' comm~nflc.
The Audit/Reconciliation Subsystem ("AARS") 190 provides a downstream system for interfacing with the IBAR 110 and provides the ability to co~ e service provider databases against the IBAR Database 162. The ARS 190 will support both regularly scheduled and on demand audit requests. In one embodiment, a system a~ministrator is given the ability ta'schedule regular audits and request on-~ern~nd audits. Audit data can be extracted from the IBAR database 162 and wntten to a disk file 192 for tr~nsmi.ssion to a downstream system using FTP. The ARS 190 will support requests for subsets of the data in the IBAR database 162 as well as complete database durnps.
Figure 6 also shows the use of a Process Monitor Subsystem ("PMS") 200 within the IBAR 110. The PMS 200is started at system start-up and spawns the initial E3AR applications including DDS 170, DIS 180 and RII 154 subsystems. In other embodiments, more copies of the same systems can be spawned by the PMS
200 upon request. The initial information is stored in a file and loaded by the PMS
200 when it is started.
As shown, the SCM 202 is a part of the PMS 200 and provides the means to stop and restart communications bet~,veen each of the real time on-line interfaces found in the DIS 180 and its do~ L.~aull server counterpart operated by the service provider.
An Emulator Subsystem ("EMU") 210 is communicably linked to the l:)IS

._~

180 and in the preferred embodiment supports four different emulators: the NCS 212, MINA/SMS 214, ARlS 216 and DDS '18 emulators The EMU 210 programs are used for testing and validation of the DIS 180. In one embodiment, cornmunication between the DIS 180 and EMU 210 subsystem programs is accomplished using 5 different protocols for each individual prograrn. as follows:
DDS Emulator DECmessageQ
NCS Emulator -- DECmessageQ
MINA SMS Emulator UNIX TCP/IP socket library ARI~ Emulator Registry The utilities subsystem 2~0 contains a set of utility functions that are available to speed development of UN~C and SQL prograrns. These functions have been developed specifically for use in the ~13AR 110 application envirorlment and provide solutions to comrnon problem Lc.ll~LL~ ents such as Oracle stored procedures 1i8, message queue access, FTP access, error h~n-lling, process signal control and any other software functions that may be best implemented as a utility.
As stated, the SOA 32 and IBA 34 subsystems interface with the NPAC/SMS
18, such as that m~int~ined by Lockhced Martin in Illinois. In this sequel, a Graphical User Interface may be used to provide a human-machine interface between the service provider Order Entry/Order Processin~, ("OE/OP") systems, such as the one illustrated in figure 7, and the SOA 32 and IBA 34 subsystems.
In one embodiment, a mechanized interface supporting uploading of data, audits/queries of the NPAC/SMS 1~ and operational messaging is supplied. Thus, the Subscription Version '~5?~ ~otification 254, LRN Request 256, NPA-NXX
Request t58, Audit 260 and Ser~ice Provider Request 262 services can comprise the base set of messages for communications between OE/OP 250 and the SOA 32.
Each request message received from the SOA 32 receives a reply back from the a Listener Application ~70 indicating that the message has been received andqueued for transmission to the appropriate NPAC/SMS 18. This reply does not, however, indicate that the message has been sent to or processed by the NPAC/SMS18. When the message has been sent to and processed by the NPAC/SMS 18, a response message from the SOA 32 will be sent to OE/OP 62 cont~inin~ the result of the original request message returned by the NPAC/SMS 18.
rhe Upstrearn Message Listener ("UML") 70 is responsible for receiving SOA 3~ front end messages to be delivered to an NPAC/SMS 18 and to write these requests to the SOA Manager Database 300. The UML 270 is also responsible for determir~ing the particular NPAC/SMS 18 to which each messagc is to be delivered.
The Upstream Message Handler Subscription Version ("U~ISV'~ 314 will poll the SOA Manager Subscription version queuing table to retrieve all records based on telephone nurnber range. Each record retrieved is analyzed to cleterrnine the action to be perforrned based on the message type of the record and record status.
If the record is a new message the UMHSV 314 will call the a~,)ropl;ate stored procedure. Once a response is received from the stored procedure, it is ., "~

evaluated and the retum code is used to update the record status in the 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 cont~ining only the error message header. The response message will be sent to the OE Front End 250 S on Registry 288. The UMHSV 314, in turn, will wait for a confirrnation from the front end 250 of a successful receipt of the message in order to delete the record from the message qucuing table.
The U~L1~11 Message Handler LRN ("UMHLRN") 316 polls the SOA
Manager LRN queuing table to retrieve all LRN Message records. Each record 10 retrieved is analyzed to deterrnine the action to be performed based on the message type, record status, and received date of the record.
If the record is a new message, the UMHLRN 316 calls bhe a~y~liate stored procedure. The retuIned value of the stored procedure will be evaluated and a response message will be created.
If the record is not a new message, the date of the record is e~mine~ If it is expired, it will be deletcd ~om LRN queuing table. Otherwise, a response message will be created and sent to the SOA front end 250 via Registry 285. If the UMHLM 316 receives a confi~n~tion of a successful receipt of the message, the UMHLRN 316 deletes the record from the message queuing table. Otherwise, the 20 result status of the queuing table will be updated for the request.
The U~ aLn Message Handler NPA-NXX ("UMH NPA-NXX") 318 is used to poll the SOA Manager NPA-N~Y queuing table to retrieve all NPA-NXX
Message records Each record retrieved is analyzed to determine the action to be performed based on the message type, record status, and received date of the record.
If the record is a new messaae, the UMH NPA-~X 318 calls the ~yl.ro~Liate stored 5 procedure. The returned value of the stored procedure will be evaluated and a response message created.
If the record is not a new message, the date of the record is ex~mined and if it is expired, it will be deleted from NPA-NXX queuing table. Otherwise, an error response message is created. The response message is sent to the front end 250 via 10 Registry 285. If the application received a confirrn~tion of a succescfill receipt of the message from the front end 250, the Message Handler 318 deletes the record from thc message queuing table. Otherwise, the result status of the queuing table will be updated for the request.
The Audit Message Handler 320 is used to poll the SOA Manager Audit 15 queuing table to retrieve all request records for processing. Each record retrieved is analyzed to determine the action to be pcrformed based on the message type of the record and record status. If the record is a new message, the Message Handler 320 calls the a~p~o~,iate stored procedure. Once a response is received from the stored procedure, it is evaluated and the return code is used to update the record status in the 20 queuing table and a response message is created cont~ining the header and the message data.

If the record is not a new message, the response message is created cont~ining an error message header. If the record is a new message but has been queued longer than a configurable amount of time, it is considered to be expired. The responsemessage is created containing an error message header. The response message will~e sent to the front end 250 via Registry 285. The process will wait for a confirmation from the front end 250 of a successful receipt of the message in order to delete the record from the messa~ge queuing table.
A Provide Message Handler Application 322 is also provided for polling the SOA Manager Provider queuing table to retrieve all request records. Each record retrieved is an~lyzed to determine the action to be performed based on the message type of the record and record status.
If the r~cord is a new message, thc Service Provider 322 calls the a~lo~liate stored procedure. Once a response is received from the stored procedure, it is evaluated and the return code is used to update the record status in the queuing table and a response message is created cont~ining the header and the message data ~f t~e 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 aconfigurable arnount of time, it is considered to be expired. The response message is created cont~ining an error message header.
The response message is sent to the front end 250 via Registry 285. The service provider waits for a confirrnation &om the &ont end of a successful receipt of the message in order to dclete the record from the message queuing table.
The Upstream ~vIessage Handler 310 also includes a Notification Message Handler 312 that polls the SOA ~anager Notification table to retrieve all records.
The action to be perforrned on each retrieved record will be determined based on the message type and the status of the record.
If the record is a new request, the infomlation needed to create the response message will be fetched from the'~OA MGR Database 300 or the corresponding database table will be updated.
If the record is not a new request, an error response message will be created l 0 and sent to the front end 250 via Registry 285. If the process received a con~n~hon of a successfi~l receipt of thc message from thc front end 2S0, the Message Handler 310 deletes the record from the SOA Manager Notification table. Otherwise, the result status of SOA Manager Notification table will be updated for the request. The Message Handler 310 keeps run~ing until all the records in the SOA Manager 15 Notification table are processed. If there is no more record in the SOA Manager Notification table, the Message Handler 310 sleeps for a certain time before it wakes up and begins to poll the S~A Manager Notification table again.
The Emulation Subsystem 250 includes an application called EMU Server 264 and 266 which emulates the SOA Front End server. The EMU Server 264, 266 20 receives messages from the SOA message handlers direct ~om the service providers mess~gin~ and communication systems and the messages, in turn, are parsed, displayed on the console and saved to a Log file.
The EMU server application ~6~ 266 emulates the SOA Front End client by reading sarnple messages from a file and passing them onto the colTesponding listener using the Registry ~85. The E~IU client waits for a reply firom the listener 5 before sending another message.
ln the preferred embodiment, a utilities subsystem 330 is provided and comprises a set of utility functions Ei~at are available to speed development of UN~
and SQL pro~ams. These functions have been developed specifically for use in the OE Interface application environrnent to provide solutions to common progr~mmin~J
l 0 requirements, such as Oracle stored procedures.
Preferably some method of access control is provided to manage security issues that arise from colmll~Lications between the IBA 34/SOA 32 subsystems and the NPAC/SMS 18. In one embodimcnt, an access control field is included in messages flowing between the IBA 34/SOA 32 subsystems and the NPAC/SMS 18 lS 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.
In one embodiment, messages flowing between the IBA 34/SOA 32 subsystems and the NPAC/SMS 18 incorporate a variable called 20 "LnpAccessControl" for the access control field with the following inforrnation:
SystemID: 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 SystemType: Identifies the kind of system that is connecting: SOA, ~BA, SOA and IBA or NPAC.
UserId: An optional field that passes a userId used mostly for logging.
ListId: This is an integer that identifies the list from which a key was chosen to create the signature. '~
KeyId: 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 systemId, the system type, the userId, the cmipD~,pd.lu-~Tirne, and sequenceNurnber without se~atola between those fields or other additional characters. Encryption is done using RSA encryption using the key from the Icey list specified. Validation of this field ensures data intcgrity 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 downtirne.

Definitions: When used, the terms "interface", "line", "lines", "link", "corrlmunications 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. The terrns "outbound link" and "inbound link" have meaning in 5 the context of the Oracle database structure and associated protocols as "pipes"
which can be used for the transfer and corr~nunication of data from system applications and programs, whether extemal or intemal. The terms "outbound link"
and "inbound link" also have meaning in the context of the Unix operating system structure and associated protocols as "sockets" which can be used for the transfer and 10 communication of data from system applications and programs. Such conventions are well known to those skilled in the art.
While this invention has been described in reference to illustrative embodiments, the description is not int~n-le~ to be construed in a lirniting sense.
Various modifications and combinations of the illustrative embodiments as well as 15 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.

., ' ' R~ ... ~ ~ .... , "

Claims (13)

1. A system for maintaining a customer's local telephone number when a switch is made from a first service provider to a second service provider, said system comprising:
a regional number portability subsystem containing a plurality of telephone number porting data defining how to route a call from said first service provider to said second service provider;
a service order application communicably linked to said regional number portability subsystem via a first data pathway and configured to send a porting request for a specific customer; and a local service management application communicably linked to said regional number portability subsystem via a second data pathway, said local service management application configured to receive said porting request, said local service management application supporting an interface to said second service provider for delivering said porting request and providing new routing data about said specific customer using the customer's existing telephone number.

2. The system for porting a customer's local telephone number according to claim 1 wherein said service order application comprises:
means for receiving and processing customer orders for local telephone service;

a local service order database containing a plurality of current telephone number and customer transaction information; and a service order application engine forming a bridge between said means for receiving and processing customer orders and said service-order database, said service order application engine configured to update said service order database with customer specific telephone number data.

3. The system for porting a customer's local telephone number according to claim 2 further comprising a check link application which monitors the interface between said service order application and said regional number portability subsystem.

4. The system for porting a customer's local telephone number according to claim 1 wherein said local service management application comprises:
a regional service database containing a plurality of current telephone number and customer transaction information;
an interface agent application to said regional number portability subsystem, said interface agent application configured to receive customer routing messages from said service order application;
means for handling said customer routing messages depending on the object type; and means for updating said regional service database.

5. The system for porting a customer's local telephone number according to claim 4 further comprising a check link application which monitors the interface between said local service management application and said regional number portability subsystem.

6. The system for porting a customer's local telephone number according to claim 5 wherein said check link application is configured to reset said local service management application when said interface between said local service management application and said regional number portability subsystem is broken.

7. The system for porting a customer's local telephone number according to claim 4 further comprising a plurality of transaction logging applications configured to receive transaction requests, handle said requests and update said regional service database.

8. An interface system for communicating telecommunications customer porting requests from a local service provider to a number portability administration center, said interface system comprising:
means for interfacing to local service provider business applications, said means configured to accept transaction data from said business applications and operably linked to at least one local order entry order processing terminal;
a transaction database communicably linked to said means for interfacing to local service provider business applications, said transaction database containing a plurality of customer telephone number data and a plurality of internally stored transaction transfer applications that control the flow of data between said local service provider and said number portability administration center;
a transaction message handling application communicably linked to said plurality of internally stored applications for reading transaction data designated for said number portability administration center; and a managing application configured to receive said transaction data from said transaction message handling application, said managing application communicably linked to said number portability administration center.

9. The interface system according to claim 8 further comprising a synchronization application coupled to both said transaction database and said managing application and configured to re-synchronize said interface system after a predetermined period of downtime.

10. The interface system according to claim 9 further comprising an unsolicited event handler application communicably linked to said managing application for receiving notification transactions.

11. The interface system according to claim 8 further comprising:
a local service database containing a plurality of customer telephone number data; and a discrepancy reporting application communicably linked to both said local service database and said transaction database.

12. A method of porting a customer's telephone number among different exchange carriers comprising the steps of:
requesting a change from a first service provider to a second service provider;
transmitting a customer's present telephone service information to a repository containing a plurality of service provider and telephone customer data; and porting said customer's present telephone service information from said repository to said second service provider.

13. A system for porting a customer's telephone number among different exchange carriers comprising:
a repository containing a plurality of service provider and telephone customer data;
means for requesting a change from a first service provider to a second service provider;
means for transmitting a customer's present telephone service information to said repostory, said means for transmitting communicably coupled to said repository via a first link; and means of porting said customer's present telephone service information from said repository to said second service provider, said means of porting communicably coupled to said repository via a second link.