System and method that allows a telephone data repository to communicate with an external system

Abstract

The present invention allows a telephone data repository to communicate with an external system, the interface system comprising a first communications link connecting the telephone data repository to an interface, a second communications link connecting the interface to the external system, and the interface configured to retrieve a plurality of telephone data from the telephone data repository via the first communications link, format the plurality of telephone data into a plurality of formatted telephone data that is compatible with the external system, and to send the plurality of formatted telephone data to the external system via the second communications link. The present invention also provides a method that allows a telephone data repository to communicate with an external system, comprising the steps of connecting to the telephone data repository via a first communications link, connecting the external system via a second communications link, retrieving a plurality of telephone data from the telephone data repository via the first communications link, formatting the plurality of telephone data into a plurality of formatted telephone data that is compatible with the external system, and sending the plurality of formatted telephone data to the external system via the second communications link.

Claims

What is claimed is:

1. An interface system that allows a telephone data repository to communicate with a separate external system, the interface system comprising:

a first communications link connecting the telephone data repository to an interface;

a second communications link connecting the interface to the external system; and

the interface configured to retrieve a plurality of telephone data from the telephone data repository via the first communications link, format the plurality of telephone data into a plurality of formatted telephone data that is compatible with the external system, and to send the plurality of formatted telephone data to the external system via the second communications link, wherein the plurality of telephone data includes a plurality of activated telephone numbers, a plurality of deactivated telephone numbers, and a plurality of local number portability requests.

2. The interface system as recited in claim 1, wherein the first communications link comprises:

a data distribution subsystem;

a third communications link connecting the interface to the data distribution subsystem; and

a fourth communications link connecting the data distribution subsystem to the telephone data repository.

3. The interface system as recited in claim 1, wherein the external system is an ANI Reference Information System.

4. The interface system as recited in claim 1, wherein the external system is a Metro Intelligent Network Administration Service Management System.

5. The interface system as recited in claim 1, wherein the external system is a Network Control System.

6. The interface system as recited in claim 1, wherein the external system is a Provisions Voice Network.

7. The interface system as recited in claim 1, wherein the plurality of telephone data comprises a plurality of telephone porting data defining how to route a call from a first service provider to a second service provider.

8. The interface system as recited in claim 1, wherein the plurality of telephone data comprises:

a plurality of telephone network data; and

a plurality of subscription information.

9. The interface system as recited in claim 1, wherein the plurality of telephone data further comprises:

a plurality of modified telephone numbers.

10. The interface system as recited in claim 1, further comprising an application for updating an internal transaction table in the telephone data repository to reflect current status of processed data messages.

11. The interface system as recited in claim 1, wherein the interface is further configured to recover unprocessed data messages from the telephone data repository.

12. The interface system as recited in claim 1, wherein the interface is further configured to perform read and write operations on a plurality of interface sockets communicably coupled to the telephone data repository.

13. The interface system as recited in claim 1, and further comprising a plurality of second communications links connecting the interface to a plurality of differing external systems each having a differing format for said plurality of telephone data.

14. An interface system that allows a telephone data repository to communicate with a separate external system, the interface system comprising:

a first communications link connecting an interface to the external system;

a second communications link connecting the interface to a data distribution subsystem;

a third communications link connecting the data distribution subsystem to the telephone data repository; and

the interface configured to retrieve a plurality of telephone data from the telephone data repository via the first communications link, format the plurality of telephone data into a plurality of formatted telephone data that is compatible with the external system, and to send the plurality of formatted telephone data to the external system via the second communications link, wherein the plurality of telephone data includes a plurality of activated telephone numbers, a plurality of deactivated telephone numbers, and a plurality of local number portability requests.

15. The interface system as recited in claim 14, wherein the external system is a Metro Intelligent Network Administration Service Management System.

16. The interface system as recited in claim 14, wherein the external system is a Network Control System.

17. The interface system as recited in claim 14, wherein the external system is a Provisions Voice Network.

18. The interface system as recited in claim 14, wherein the plurality of telephone data comprises a plurality of telephone porting data defining how to route a call from a first service provider to a second service provider.

19. The interface system as recited in claim 14, wherein the plurality of telephone data comprises:

a plurality of telephone network data; and

a plurality of subscription information.

20. The interface system as recited in claim 14, wherein the plurality of telephone data further comprises:

a plurality of modified telephone numbers.

21. The interface system as recited in claim 14, further comprising an application for updating an internal transaction table in the telephone data repository to reflect current status of processed data messages.

22. The interface system as recited in claim 14, wherein the interface is further configured to recover unprocessed data messages from the telephone data repository.

23. The interface system as recited in claim 14, wherein the interface is further configured to perform read and write operations on a plurality of interface sockets communicably coupled to the telephone data repository.

24. The interface system as recited in claim 14, and further comprising a plurality of second communications links connecting the interface to a plurality of differing external systems each having a differing format for said plurality of telephone data.

25. A method that allows a telephone data repository to communicate with a separate external system, said method comprising:

connecting to the telephone data repository via a first communications link;

connecting the external system via a second communications link;

retrieving a plurality of telephone data from the telephone data repository via the first communications link;

formatting the plurality of telephone data into a plurality of formatted telephone data that is compatible with the external system; and

sending the plurality of formatted telephone data to the external system via the second communications link, wherein the plurality of telephone data includes a plurality of activated telephone numbers, a plurality of deactivated telephone numbers, and a plurality of local number portability requests.

26. The method as recited in claim 25, wherein:

connecting the external system comprises connecting a plurality of differing external systems via a corresponding plurality of second communications links; and

formatting the plurality of telephone data comprises formatting said plurality of telephone data into a plurality of differing formats that are each compatible with a respective one of the plurality of differing external systems.

27. An interface for communicating telephone data between a telephone data repository and a separate external system, said interface comprising:

means for retrieving a plurality of telephone data from the telephone data repository via the first communications link;

means for formatting the plurality of telephone data into a plurality of formatted telephone data compatible with the external system; and

means for sending the plurality of formatted telephone data to the external system via a second communications link, wherein the plurality of telephone data comprises a plurality of telephone porting data defining how to route a call from a first service provider to a second service provider, wherein the plurality of telephone data includes a plurality of activated telephone numbers, a plurality of deactivated telephone numbers, and a plurality of local number portability requests.

28. The interface system as recited in claim 27, wherein said interface is connected to a plurality of external systems by a corresponding plurality of second communications links, wherein:

said means for formatting comprises means for formatting said plurality of telephone data into a plurality of differing formats; and

said means for sending comprises means for sending said plurality of telephone data to said plurality of external systems in said plurality of differing formats.

Description

FIELD OF THE INVENTION

The present invention relates in general to the field of telecommunications and more specifically to a system and method that allows a telephone data repository to communicate with an external system.

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'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'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'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'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, 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 allows a telephone data repository to communicate with an external system, the interface system comprising a first communications link connecting the telephone data repository to an interface, a second communications link connecting the interface to the external system, and the interface configured to retrieve a plurality of telephone data from the telephone data repository via the first communications link, format the plurality of telephone data into a plurality of formatted telephone data that is compatible with the external system, and to send the plurality of formatted telephone data to the external system via the second communications link.

In addition, the present invention provides an interface that allows a telephone data repository to communicate with an external system, the interface system comprising a first communications link connecting an interface to the external system, a second communications link connecting the interface to a data distribution subsystem, a third communications link connecting the data distribution subsystem to the telephone data repository, and the interface configured to retrieve a plurality of telephone data from the telephone data repository via the first communications link, format the plurality of telephone data into a plurality of formatted telephone data that is compatible with the external system, and to send the plurality of formatted telephone data to the external system via the second communications link.

The present invention also provides a method that allows a telephone data repository to communicate with an external system, comprising the steps of connecting to the telephone data repository via a first communications link, connecting the external system via a second communications link, retrieving a plurality of telephone data from the telephone data repository via the first communications link, formatting the plurality of telephone data into a plurality of formatted telephone data that is compatible with the external system, and sending the plurality of formatted telephone data to the external system via the second communications link.

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's upstream systems is used for this purpose.

The present invention provides a facility for administering the service provider subscription information relating to a particular customer. In this regard, the SOA is equipped with a host of functions for creating, canceling, acknowledging, modifying, retrieving, activating, disconnecting and removing subscription version information. The SOA has an audit capability that permits audits of a customer's porting activity based on a telephone number and receives notifications from the NPAC/SMS to ensure that it is fully informed of relevant events relating to a service provider's subscriptions.

The present invention provides the interface structures that permit service providers to read and update their own service provider information within the NPAC/SMS. In this regard, the interface permits service providers to update the information in their service provider profile as well as add and delete their own network data. The information is accessible to all service providers via a standard interface to assure correct call routing.

The present invention provides a system that interfaces directly with existing telecommunication 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 the old service provider according to processes internal to the old service provider. The messaging format includes signal protocols that can be used by both the 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 performs certain validation checks, and attempts to match a notification received from the new service provider with a concurring notification that may be sent from the old service provider, permitting the two service providers to complete the port.

The present invention provides a means of downloading subscription and network data from the NPAC/SMS to the local service provider's applications for correct call routing and network provisioning. In this regard, an Interface Broadcast Agent ("IBA") Subsystem is provided as a means of interfacing a service provider's downstream systems with the NPAC/SMS. In one embodiment, the IBA Subsystem is configured to automatically receive new network or subscription data or modifications to existing data. The IBA Subsystem may also request data using a download request. The request can be based on a time period, telephone number, telephone number range or other indicator. The service provider can also directly read the data from the NPAC/SMS.

The present invention provides the software and hardware platforms for achieving Local Number 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 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. Methods for transferring a customer's port data from an old service provider to a new service provider are also disclosed.

Disclosed, in one embodiment, is a system for maintaining a customer's local telephone number when a switch is made from a current service provider to a new 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 administration application is communicably linked to the regional number portability subsystem and configured to send a porting request for a specific customer to the portability subsystem and the service providers interfaced to the portability subsystem. A local service management application is communicably linked to the regional number portability subsystem via a second data pathway and configured to receive the porting data. The local service management application supports the interface to the second service provider and delivers the porting request containing the new routing data for the customer allowing the service provider to continue to route calls to the customer at their existing telephone number once the switch is made.

The local service management application supports a host of interface processing applications used for porting a customer's telephone number among different service providers once the port request has been arranged between the old and new service providers. An interface processing application processes messages from a system's Interface Broadcast Agent Repository ("IBAR") into a defined format compatible with a local service providers downstream interface system and ports a customer's present telephone service information from a IBAR database to a second service provider's downstream interface system. The interface processing application updates the IBAR to reflect the current status of processed messages.

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'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;

FIG. 10 is a flow chart for a Downstream Interface Subsystem for providing a MINA/SMS Request Processing Interface according to one embodiment;

FIGS. 10A, 10B, 10C, 10D, 10E, 10F, 10G, 10H, 10I, 10J and 10K are flow charts for various processes in the Downstream Interface Subsystem for providing a MINA/SMS Request Processing Interface according to one embodiment;

FIG. 11 is a flow chart for a Downstream Interface Subsystem for providing an ARIS Request Processing Interface according to one embodiment;

FIGS. 11A, 11B, 11C, 11D, 11E and 11G are flow charts for various processes in the Downstream Interface Subsystem for providing an ARIS Request Processing Interface according to one embodiment;

FIG. 12 is a flow chart for a Downstream Interface Subsystem for providing a NCS Request Processing Interface according to one embodiment;

FIGS. 12B, 12C, 12D, 12E, 12F, 12G, 12H, 12I and 12J are flow charts for various processes in the Downstream Interface Subsystem for providing a NCS Request Processing Interface according to one embodiment;

FIG. 13 is a flow chart for a Downstream Interface Subsystem for providing a RTE7 Batch Extract according to one embodiment;

FIGS. 13A, 13B and 13C are flow charts for various processes within the Downstream Interface Subsystem for providing a RTE7 Batch Extract 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'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's telephone number as denoted by line 36.

Once the new service provider 26 obtains the customer'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'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'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'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 ("FTP").

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 VARCHA2(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_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 Number
     VARCHAR2(10)
    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)

                                         TABLE 2
                           Domain field list for IBA Database.
    Name               Code                     Label                  Type
    billingIdentifier  BILLING_ID               Billing Identifier
     VARCHA2(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
     VARCHA2(9)
    CNAM SSN           CNAM_SSN
     NUMBER(3)
    contactType        CONTACT_TYPE             Contact Type
     VARCHAR2(2)
    country            COUNTRY
     VARCHA2(20)
    endUserLocationType END_USER_LOC_TYPE
     VARCHA2(2)
    endUserLocationValue END_USER_LOC_VALUE
     VARCHA2(12)
    identifier         ID
     NUMBER(10)
    ISVM DPC           ISVM_DPC
     VARCHA2(9)
    ISVM SSN           ISVM_SSN
     NUMBER(3)
    LIDB DPC           LIDB_DPC
     VARCHA2(9)
    LIDB SSN           LIDB_SSN
     NUMBER(3)
    LNPtype            LNP_TYPE
     NUMBER(1)
    LRN                LRN
     VARCHA2(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
     VARCHA2(4)
    stateProvince      STATE_PROV               State/Province
     VARCHA2(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)