MXPA00003914A

MXPA00003914A - Advanced intelligent network gateway

Info

Publication number: MXPA00003914A
Application number: MXPA/A/2000/003914A
Authority: MX
Inventors: Timothy Darland; Robert F Dickerman; Christopher P Tofanelli
Original assignee: Mci Communications Corporation
Priority date: 1997-10-21
Filing date: 2000-04-19
Publication date: 2001-06-26

Abstract

An advanced intelligent network gateway (102) that allows communication between telecommunications network component that use different protocols. In one embodiment, the advancedintelligent network gateway is used to communicate between a manual operator console (122A-122N) that are processing a customer's telephone call and a service data point (128) which is a database containing information needed to process the customer's telephone call. However, the advanced intelligent network gateway may also be used to receive and transmit messages between other telecommunication components. In addition, methods for protocol conversion of a transaction capabilities application part (TCAP) message from a user data protocol/Internet protocol (UDP/IP) to a transmission control protocol/Internet protocol (TCP/IP) implementation or vice versa. Methods for receiving and transmitting transaction capabilities application part messages are also described.

Description

MEANS OF ADVANCED INTELLIGENT NETWORK ACCESS Background of the Invention Field of the Invention The present invention relates generally to computer systems, and more particularly to providing a messaging interface between one or more computer system environments.

Related Technology The products of a telecommunications network are services that are supplied by telephone companies that are supplied in telecommunications networks. A well-known example is dialing 1 to obtain the long-distance voice service that allows the customer to dial 1 plus ten digital numbers from their home phone, talk to the party answering the phone on the line of the ten digital numbers marked, and pay for the phone call when invoiced at the end of the month. Even when dialing 1 is popular, other calling and payment options are sometimes preferred. For example, a phone card call allows the individual to use another phone than the one in their home and charge the call to their home phone account using the phone card. One of those call and payment options is the Debit call also known as call paid early. The debit call allows the customer to deposit funds into an account and debit those funds every time he makes a phone call. The process of a standard debit call includes checking the account balance before initiating the call connection and checking the balance during the course of the call. An example of a typical debit call customer is a parent who buys a debit card for their child who is out of the home. The debit call, as well as other call and payment options, are carried out in a telecommunications network. A telecommunication network comprises two basic elements: a telecommunications equipment, which is also referred to as components of the network, and links that connect the equipment or components. Since the handling of calls and the process of information for the debit calls differ from other voice services, the debit calls are handled by means of specialized components in the telecommunications network. That is, debit calls are handled using a specialized computer system. A computer system, such as those used for debit calls, has the need to communicate with other computer systems to Exchange information between one or more computer programs running on each computer system. A particular computer program may have the need to establish communication with programs that are executed in the same computer system or with programs executed in other systems through the network. To allow computer programs to communicate with each other, programmers have written programs that are compatible with standards or protocols. A standard or protocol may be used through the telecommunications industry or may be owned by a private entity for use with the computer systems sold or operated by that entity. The protocols determine what information is transmitted, what time values should be associated with the transfer of information, and what format should be used to transmit the information. The debit call is processed by a plurality of computer systems that provide the functionality of switching and routing, managing individual calls, and storing customer account information. However, computer systems typically operate programs that use different protocols. Unfortunately, a computer program that uses a protocol generally can not communicate with a computer program that uses another protocol.

The above can be overcome by providing a code in the computer program that translates the protocol received from and sent to the other computer program. However, if a computer program needs to communicate with different computer programs, a significant number of additional codes may be required to allow computer programs to communicate. As the size of the computer program increases, the cost of developing, building, and maintaining the computer system also increases. Also, long codes and the requirement of complex equipment increase the possibility of maintenance problems. The time and cost of development increases because large computer programs require labor and additional time for them to develop. Increases the cost of building the computer system because additional equipment such as links and memory are required. The cost of maintenance increases because the maintenance of additional code and equipment is more expensive. In addition, equipment and additional code increase the likelihood of more operating problems because the additional equipment may have failures and the additional code may have errors that will affect the program or the entire system.

SUMMARY OF THE INVENTION The system and method of the present invention allows the communication between components of the telecommunications networks that provide access to the manual operator consoles to the debit clients for customer service. A route to a manual operator console will be assigned to the debit client who wishes to service customers. However, the manual operator console does not contain information for the debit customer account. For the purpose of processing the call, the manual operator console enters a service data point (SDP) to obtain the debit customer account information. Unfortunately, the SDP uses a different protocol than the manual operator consoles. The present invention includes an advanced intelligent network access gate (AING) which is a computer system that provides message transfer and protocol conversion to allow communication between manual operator consoles and the SDP. The AING of the present invention can act as a single interface point between the multiple computer programs that use different protocols. The manual operator console communicates using TCAP encoded messages embedded in the packet-in-sequence (NSPP) protocol of the information distribution service of the transmission protocol network (NIDS, for its acronym in English). The NSPP is an implementation of the protocol protocol / internet protocol of the datagram (USP / IP) and provides communication with client-server programs. In a preferred embodiment of the present invention, the SDP is communicated by means of using the protocol of protocol / transmission control internet protocol (TCP / IP, for its acronym in English). The AING provides a system and method for converting TCAP messages encoded on the NSPP to and from the operator consoles to TCAP encoded messages based on the TCP / IP going to and from the SDP. Please consult the attached Glossary to see the reference of the acronyms and their definitions. The AINGW of the present invention comprises many layers of software for the transfer of messages and the conversion of protocols that are needed for communication between the manual operator consoles and the SDP. The AING includes a basic monitoring service (BOSS), an advanced intelligent network application (AIN_APP), an internal process communications manager (IPC_MGR), an NSPP interface module. (NIM, for its acronym in English), an alarm selector, and a module of measurements (OM, for its acronym in English) operational. The BOSS has the responsibility to start, stop, and monitor the processes in the AING. The AIN_APP is a computer program that includes software layers to receive, process, and transmit messages between the NIM and the IPCJMGR. The NIM is an IPC_MGR NSPP client and server. The IPC_MGR is an element of the peer-to-peer network. The AIN_APP performs the protocol conversion by receiving the message from the NIM and transmitting it to the IPC_MGR. The NIM unpacks the NSPP packet message before transmitting it to the AIN_APP. The AIN_APP transmits the message to the IPC_MGR, which packages it in a TCP packet and transmits it to the SDP. For the response, the IPC_MGR unpacks the TCP frame message before delivering it to the AIN_APP. The AIN_APP transmits the message to the NIM, which packages it in an NSPP packet and transmits it to the manual operator console. In order to process the messages that are transmitted between the NIM and the IPC_MGR, the AIN_APP performs multiple steps for the protocol conversion. The protocol conversion for messages sent from the NIM to the IPC_MGR involves decoding the messages, saving the message information temporarily in a row, and formatting the message again. The protocol conversion for messages transmitted from the IPC_MGR to the NIM involves decoding the message, validating that an error response message has not been transmitted, retrieving the information stored in a row, and re-filling the information in the response message.

The further features and advantages of the invention, as well as the structure and operation of various embodiments of the invention, are described below in more detail, whereby reference is made to the drawings appended thereto. In the drawings, numbers with like reference generally indicate identical elements, of similar functionality, and / or structurally similar. The drawing in which an element first appears is indicated by means of digits in the far left in the corresponding reference number.

Brief Description of the Figures Figure 1 is a block diagram of the. interface environment of an advanced intelligent network access gate (AING) in accordance with a preferred embodiment of the present invention. Figure 2 is a block diagram of the elements of an AING in accordance with a preferred embodiment of the present invention. Figure 3 in a block diagram of the structure of an AING in accordance with a preferred embodiment of the present invention. Figure 4 illustrates the flow of the AING message in accordance with a preferred embodiment of the present invention.

Figure 5 illustrates an application of an advanced intelligent network (AIN_APP) in accordance with a preferred embodiment of the present invention. Figure 6 illustrates the operation of a basic monitoring service (BOSS) of the AINGW of Figures 2 and 3 in accordance with a preferred embodiment of the present invention. Figure 7 illustrates the operation of the main routine of the AIN_APP program which resides in the main memory of the AING of Figures 2 and 3 in accordance with a preferred embodiment of the present invention. Figure 8 illustrates the operation of a module of the NIM message (AIN_PROCESS_MSG_NIM) in the process of an advanced intelligent network of the AIN_APP residing in the AING of Figures 2 and 3 in accordance with a preferred embodiment of the present invention. Figure 9 illustrates the operation of a selected start routine (BEGIN_CHOSEN) of the AIN_APP residing in the AING of Figures 2 and 3 in accordance with a preferred embodiment of the present invention. Figure 10 illustrates the operation of an IPC layer (AIN_PROCESS_MSG_IPC) message in process of an advanced intelligent network of the AIN_APP that resides in the AINGW of the Figures 2 and 3 in accordance with a preferred embodiment of the present invention.

Figure 11 illustrates the operation of a part receiving layer (RCAP_RECV) of the message of the transaction capabilities application of the AIN_APP residing in the AING of Figures 2 and 3 in accordance with a preferred embodiment of the present invention. Figure 12 illustrates the operation of a layer (TCAP_SEND) of transmission of application capabilities transaction message from the AIN_APP that resides in the AINGW of Figures 2 and 3 in accordance with a preferred embodiment of the present invention; and Figure 13 illustrates the operation of an expired chronometer routine (AIN_TIMER_EXPIRED) of an advanced intelligent network of the AIN_APP residing in the AING of Figures 2 and 3 in accordance with a preferred embodiment of the present invention.

Detailed Description of the Preferred Modes Figure 1 is a block diagram of the environment of the interface 102 of an advanced intelligent network access gate. The AING 124 is an interface between a service data point (SDP) 128 and one or more manual operator consoles 122. The AING 124 allows the information of the SDP 128 to flow, which stores the client's account information. debit, to the manual operator consoles 122A, 122B ... 122N that are used by human operators to process calls. For the purpose of promoting communication between the SDP that uses the control of the transmission protocol / internet protocol (TCP / IP) and the consoles of the manual operator 122 that is communicated to the telecommunications network that uses the packet protocol in sequence (NSPP) of the network information distribution service (NIDS), the AING 124 carries out the protocol conversion between TCP / IP and NSPP (UDP / IP). The environment 102 of the AING interface is a possible environment of an AING 124. The environment 102 of the AINGW interface described below is included in a telecommunications network that processes debit calls. The telecommunications network includes various networks such as a first and a second local telephone exchange 106 and 132 and an internal exchange network 110. The internal exchange network 110 comprises a plurality of switches, which includes a switch 108 of an exemplary network. internal exchange, and an exemplary bypass switch 112. In addition, within the internal exchange network 110, a service switch control point (SSCP) 130, an automated call distributor (ACD) 114, an intelligent service network application processor (ISNAP) 116, remote control consoles, Manual operator 122, AING 124, and SDP 128 are used to process debit customer service calls.

The environment of the AING 102 interface can best be described by referring to the process of a typical call. A debit customer makes a call by dialing the 800 number in a telephone 104. The call is first received in the network of the first local telephone exchange 106. A first local exchange network 106 comprises switches and terminating equipment within a localized area. An example of a first local exchange network 106 is a network of the local telephone company that is in operation, such as the Bell Atlantic. The first local exchange network 106 transmits the call to an internal exchange switch 108 in an internal exchange network 110. Like the first local exchange network 106, an internal exchange network 110 comprises a plurality of switches, also referred to as exchanges, which are located through a geographical area. For example, a national internal exchange network 110 comprises switches located throughout the nation. The internal exchange network 110 is typically used to process long distance telephone calls. When a call is assigned to a route of the internal exchange network 110, it can be assigned to one or more switches within the internal exchange network. If the call is received by the switch of the internal exchange network 108, the switch of the internal exchange network 108 will assign the route of the call to a bridging switch 112. Then bridging switch 112 will assign the route of the call to SSCP 130. Alternatively, if a bridge switch 112 receives the call, the bridge switch 112 will assign the route of the call directly to the SSCP 130. The switches in the internal exchange network 110, which includes the switch of the internal exchange network 108 and the Bypass switch 112, can be implemented by using the DMS-250 switches manufactured by Nortel. When a customer requires customer service assistance, or if the customer wants to make new charges to their previously paid card, a human operator can provide assistance. The SSCP 130 transmits the call to the ACD 114 by means of generating a message with the number 800 marked by the client. The SSCP 130 transmits the call to the ACD 114 via the bridging switch 112. After the bridging switch 112 transmits the call to the ACD 114, the ACD 114 communicates with the ISNAP 116 to assign the route of the call to a manual operator console 122A. The call is handled as a new call by the ACD 114. The exemplary manual operator console 122A allows a human operator to handle an individual debit call at a time. The manual operator consoles 122 are logically placed in groups. The ISNAP 116 selects a manual operator console 122A and ensures that incoming calls they are distributed among the logically defined groups. The ISNAP 116 has a database that contains the route assignment information (group number) for the 800 number used to dial the call. The ISNAP 116 returns the group number to the ACD 114, which in turn selects a specific operator 122A from this group and establishes a software and voice connection to this operation console 122A. The ACD 114 provides the switching functionality between the manual operator console 122A that was selected by the ISNAP 116 and the internal exchange network 110. The ACD 114 can be implemented by using an automated call distributor manufactured by Nortel . The ISNAP 116 communicates to the handheld consoles 122 through the NSPP in an operator network center (ONC) of a wide area network (WAN) and two networks of local areas (LANs) referred to as the ONC LANs / WAN 118. The ONC LANs / WAN 118 provides a connection to the manual operator console 122A and can assist the ISNAP 116 to direct the call to a console of manual operator 122A. The ONC LANs / WAN 118 is a transmission medium and provides access to the databases that store the information that was used to process the calls. The manual operator consoles 122 communicates with the ONC LANs / WAN 118 via the NSPP. The ONC LANs / WAN 118 can be implemented with one or more WANs and / or LANs through the use of Ethernet technology, a step symbol ring, or other similar technology WA? / LA ?. The manual operator consoles 122 are computer consoles that receive calls from the ACD 114 and proportional to the human operator (not shown) with the information to direct the customer's debit call. Unfortunately, the information that is received does not include the debit customer account information. The manual operator consoles 122 need access to the SDP 128 for the purpose of obtaining the debit customer account information. The SDP 128 stores the debit customer account information that is used for the handling of transit, service provision, and billing of debit calls. According to the present invention, the manual operator console 122 has access to the SDP 128 through the AI? GW 124 and the SDP LA? 126. The AI? GW 124 provides the protocol conversation between the TCP / IP using the SDP 128 and? SPP using the manual operator consoles 122. The AI? GW 124 includes one or more computer programs with layers serving as an interface with the SDP 128 and the manual operator consoles 122, perform the protocol conversion, and monitor other processes. The computer programs of the AI? GW 124 will be described in greater detail with reference to Figure 2 and Figures 4 to 10.

The manual operator console 122A selected uses the information received from the SDP 128 to process the call and then releases the call back to the bridging switch 112 through the ACD 114. The bridging switch 112 connects the call the receiver 134 through the a second local exchange network 132. Like a first local exchange network 106, a second local exchange network 132 comprises switches and terminating equipment within a localized area. The example used in the illustration of a first local exchange network 106, a telephone network in local operation such as the Bell Atlantic, also applies to a second local exchange network 132. Figure 2 is a block diagram of the elements of an AIN interface environment 102 of FIG. 1. The program layers of the AINGW 124 computer comprise a basic monitoring service (BOSS) 202, an advanced intelligent network application (AIN_APP) 204, an administrator of internal process communications (IPC_MGR) 206, an NSPP interface layer (NM) 210, an operational measurement process (OM) 214, a human machine interface (HMI) 216, and an alarm selector 218. The IPC_MGR 206 and the NIM 210 provide software interfaces between the AINGW 124 and the SDP 128 and the manual operator consoles 122 respectively. The AIN_APP 204 provides the transfer of messages between IPC_MGR 206 and the NIM 210 and the conversion of the protocol. The BOSS 202, OM 214, and the alarm selector 218 provide measurement, monitoring, and error log data. The HMI allows the configuration of entities within the programmed ones of the computer in the AINGW 124. The link AIN_SDP 208 and the link of the manual operator console AIN 212 provide links to the SDP 128 and to the manual operator consoles 122 respectively. The link of the manual operator console AIN 212 provides a link from the AINGW 124 to the manual operator consoles 122 through the ONC LANs / WAN 118. The BOSS 202 is responsible for starting, stopping, and monitoring the processes in the AI ? GW 124. The BOSS 202 is the first process initiated during the start-up of the AI? GW 124. The monitoring of the processes in the AI? It is done by using beats. In addition, the BOSS 202 accepts commands from the HMI 216 to start or stop the AI? GW 124 and commands from the? IM 210 to report the connectivity problems to the manual operator consoles 122. The BOSS is described below with reference to the FIG. 5. The AI? _APP 204 is a computer program in the AI? GW 124 which interacts between the manual operator consoles 122 and the SDP 128. The AI? _APP 204 interacts with the manual operator consoles 122 and the SDP 128 by means of a communication with the two interface programs, the? IM 210 AND IPC_MGR 206, In AI? GW 124. The AI? APP 204 interacts with the manual operator consoles 122 communicating with the NIM 210 and interacting with the SDP 128 by means of communicating with the I C_MGR 206. The AIN_APP 204 communicates with the NIM 210 and the IPC_MGR 206 through receiving and transmitting transaction messages of part application capabilities (TCAP). A TCAP message is in the same format as the TCAP message defined by the industry standard format for TCAP messaging for use with the Signaling System Number 7 (SS7) protocol. However, unlike the industry standard, TCAP messages are used with various protocols and are not limited to their use with the SS7. The current industry standard is published in document NCT 1.113 (1995) Part of the User (ISUP) of the Integrated Services Digital Network (ISDN) of Signaling System Number 7 (SS7) of the International Union of Telecommunications (ITU) and document 1111 (1992) of the Message Transfer Part (MTP) of Signaling System Number 7 (SS7) of the International Telecommunication Union (ITU) incorporated herein as reference in its entirety. In accordance with the preferred embodiment of the present invention, the TCAP messages received and sent by the ATN_APP 204 include the information for processing and billing the debit calls.

The AIN_APP 204 receives TCAP messages from the hand-held consoles 122 and transmits the TCAP messages to the SDP 128. When the AIN_APP 204 receives a response from the SDP 128, the AIN_APP 204 transmits the response to the hand-held consoles 122. In order to transmit the TCAP messages between the manual operator consoles 122 and the SDP 128, the AIN_APP 204 converts between the TCP / IP and the NSPP. The AIN_APP 204 includes software layers that receive, transmit, and perform the protocol conversion. Within the AIN_APP process, a layer that receives part of the transaction capabilities application (TCAP_RECV) receives TCAP messages from both the manual operator consoles 122 through the NIM 210 and the SDP 128 through the IPC_MGR 206. Within the process of the AIN_APP, a sending layer on behalf of the transaction capabilities application (TCAP_SEND) transmits messages from both the manual operator consoles 122 through the NIM 210 and the SDP 128 through the IPC_MGR 206. A layer Message NIM of advanced intelligent network process (AIN_PROCESS_MSG_NIM) and an IPC layer of the advanced intelligent network process message (AIN_PROCESS_MSG_IPC) performs the conversion protocol. The AIN_APP is described in more detail in Figures 5 and 7 through 13. The TCAP messaging is encoded in abstract syntactic notations (ASN.l). Abstract syntactic notation is a generic computer programming language which can be used to write message definitions for products that will reside on different platforms. The abstract syntactic notation used to encode the messages of the application part (TCAP) of the transaction capabilities complies with the standards of industry 2.07 and 2.08 established by the Consultative Committee of Telegraphs and International Telephones which is the committee that fixes the Standards of the International Telecommunications Union (ITU). The AIN_APP 204 communicates to the SDP 128 through IPC_MGR 206. The IPC_MGR 206 is a TCP / IP interface. In accordance with the preferred embodiment of the present invention, the IPC_MGR 206 allows communication with the SDP 128. The IPC_MGR 206 is related as a transport mechanism application because this is the mechanism that processes the use to transport messages. IPC_MGR 206 is described in more detail in U.S. Patent Application Serial Number 08 / 671,027 entitled "System and Method for Interprocess Communication" filed June 25, 1996, incorporated herein by reference in its entirety. its entirety Communication protocols, such as TCP / IP, provide connectivity for communication between two vertices in the network. Examples of TCP / IP implementations include Multinet, a computer program produced by TGV, Inc. and UCX, a computer program produced by manual 122 through the ONC LANs / WAN 118. The OM 214 captures the data of the call of the AIN_APP in the AINGW 124. The OM loads this data, through the NIM, to place it in the main processor subject to further analysis. The HIM 216 provides access through a series of software menus that allow the configuration, addition, or removal of configurable entities within the computer programs in the AINGW 124. The alarm selector 218 accepts from the other processes in AINGW 124. The alarms are registered in the log file and receive alarm treatment. The alarm treatment consists of setting the threshold and selecting the alarms so that the alarms can be processed by other computer programs in the network of the computer system. The AINGW 124 of the present invention is preferably implemented by means of using a computer system as shown in the form of the block diagram in Figure 3. The computer system includes one or more processors, such as a processor 306. connected to the interconnect bar 304. In a preferred embodiment of the present invention, the AINGW 124 is a DEC Alpha 1000 server with a central processing unit (CPU) operating at 266 megahertz (MHZ). It is also connected to the interconnection bar 304 the main memory 308 (preferably random access memory, RAM) and secondary storage devices 310. In a preferred embodiment of the present invention, the secondary storage devices 310 include, for example, a hard transmission 312 and a transmission of removable storage medium 314 (such as a disk drive, for example). The AIN_APP 204 is preferably a computer program that resides in the main memory 308 while it is running. When executed, this computer program enables the AINGW 124 to perform the features of the present invention as discussed herein. Therefore, the AIN_APP 204 represents a controller of the AINGW 204 (and processor 306). In one embodiment, the present invention is a product of the computer program (such as a removable storage medium 316, which represents a computer storage disk, compact disc, etc.) comprising a readable medium that has the logic recorded of control over it. The control logic, when loaded into the main memory 308 and executed by the processor 306, enables the processor 306 to perform the operations described herein. Figure 4 illustrates the flow of the message surrounding an AINGW 124. The flow of the message is described with respect to an exemplary call that is being handled by means of a manual operator console 122A. The flow of the message begins with the manual operator console 122A which transmits a TCAP message to the SDP 128 through the AINGW 124 to obtain information that is required to process and bill a call from the debit client. The SDP 128 supplies the information in the TCAP message, which is also referred to as a TCAP response message, which responds to the manual operator console 122A also through the AINGW 124. As shown in Figure 2, in AINGW 124 is home to various computer programs. The programs that support the transfer of messages between the manual operator console 122A and the SDP 128 are the services of the network interface module (NIMSYS), which is a computer program associated with the NIM 210, AIN_APP 204, and IPC_MGR 206. NIMSYS receives the message sent by the manual operator console 122A and transmits the message to AIN_APP 204 for protocol conversion. The AIN_APP 204 transmits the message to the SDP 128 through the IPC_MGR 206. When the SDP 128 responds, the IPCJMGR 206 receives the message. The IPC_MGR 206 transmits the message to the AIN_APP 204 for the protocol conversion. The AIN_APP 204 transmits the message to the manual operator console 122A through the NIMSYS. In step 406, the manual operator console 122A transmits a TCAP / NSPP message (UDP / IP). The TCAP message sent by the manual operator console 122A is in NSPP (UDP / IP) compatible format because the manual operator consoles 122 and the center of the LANs / WAN operator network communicate by using the NSPP over the UDP / IP. In step 408, the NIM receives the NSPP packet. The NIM transfers the message to the AIN_APP service. The NIM is described in more detail in U.S. Patent Application Serial Number 08 / 672,139 entitled "A Communication Gateway" mentioned above. In step 410, the AIN_APP 204 processes the message TCAP. The AIN_APP 204 transfers the message from the NIM to the IPC_MGR and provides a protocol conversion of the NSPP protocol (UDP / IP) to TCP / IP. The AIN_APP 204 is described in more detail with respect to Figures 5 to 13. The step 410 corresponds to the steps 508 to 512 of Figure 5. In step 412, the IPC_MGR receives the message from the AIN_APP 204. The IPC_MGR 206 carries the message from AIN_APP 204 to SDP 128. The process performed by IPC_MGR 206 is described in more detail in United States Patent Application Serial Number 08 / 671,027 entitled "System and Method for Interprocess Communication" referred to above . In step 414, the SDP 128 receives the TCAP / TCP / IP message. The TCAP message received by SDP 128 is compatible with TCP / IP.

In step 416, the SDP 128 transmits a TCA / TCP / IP response message. In step 418 the IPC_MGR 206 receives the message from the SDP 128. IPC_MGR 206 transports the message from SDP 128 to AIN_APP 204. The process performed by IPC_MGR 206 is described in greater detail in the Patent Application of the United States of America with Serial Number 08 / 671,027 entitled, "System and Method for Interprocess Communication" referred to above. In step 420, the AIN_APP 204 receives and processes the message. The AIN_APP 204 transfers the IPC_MGR 206 message to the NIM and provides the conversion of the TCP / IP protocol to the NSPP (UDP / IP). The AIN_APP 204 is described in greater detail with respect to Figures 5 to 13. The step 410 corresponds to steps 518 to 522 of Figure 5. In step 422, the NIM receives the message from the AIN_APP 204. The NIM process is described in more detail in the Patent Application of the United States of America with Serial Number 08 / 672,139 entitled, "A Communication Gateway" referred to above. In step 424, the manual operator console 122A receives the message. The response message received by the manual operator console 122A is in the NSPP format (UDP / IP). Figure 5 illustrates the flow of the message within the AIN_APP Various software layers of the AIN_APP, in the description of Figure 2, receive, transmit, and perform protocol conversions. The TCAP_RECV layer acts as the only interface to receive TCAP messages. The TCAP_RECV layer receives both the initial TCAP message from the manual operator console 122A and the response TCAP message from the SDP 128. The TCAP-SEND layer acts as the only interface for transmitting TCAP messages. The TCAP_SEND layer transmits both the initial TCAP message to the SDP 128 and the response message to the manual operator console 122A. The AIN_PROCESS_MSG_NIM layer performs the protocol conversion for the initial TCAP message sent from the manual operator console 122A to the SDP 128. The AIN_PROCESS_MSG_IPC layer performs the protocol conversion for the response TCAP message of the SDP 128 to the manual operator console 122A. In step 506, the manual operator console 122 transmits a TCAP message to the AINGW 124. The TCAP message complies with the ITU TCAP standard referenced above. For the purpose of describing how the information is passed between the manual operator console 122A and the SDP 128, a description of the TCAP message is provided below. In the preferred embodiment of the present invention, TCAP message fields are used either to assist in the transaction of the message or to pass other information, such as debit client account information, between the manual operator console 122A and the SDP 128. The TCAP message includes two parts: a transaction portion and a component portion. The transaction portion is used to assist in sending the message between the manual operator console 122A and the SDP 128. The transaction portion indicates the type of message and the portion of the component. The transaction portion and the component portion are described in the following table. The transaction portion is described in greater detail in Table 2 following Table 1.

Table 1 Table 2 At the beginning of the transaction, the manual operator console 122 transmits a start TCAP type message that requires a return response. The type of message is indicated in the first message field as shown in Table 2. Possible message type labels are described in more detail in the following Table 3. In addition, Table 3 provides the appropriate identifier for each message. label of the type of message.

Table 3 In addition to a transaction portion, the messaging of transaction capabilities also includes a component portion. The component portion can be one of the following types: invoke, return the result to the last one, return the result not to the last, return the error, or reject. In the start, end, unidirectional, and continuous message types, the component portion includes information to assist in sending the message. In addition, the type portion of the response messages of the end type component, or the continuous type includes the information needed by the manual operator console 122A. In the following Table 4 additional details of the component portion are provided.

Table 4 Whereas a start message of the TCAP type is transmitted from the manual operator console 122A, the component portion comprises an invocation component. The invocation component includes the operation to be performed and the parameters defined in a message-by-message basis. More information about the question or the invocation component is provided in the following Table 5.

Table 5 Table 5 shows the contents of the parameter field that in the question or invocation component of the TCAP message contains parameters that are defined on the basis of message-by-message. In a request message, the parameter content field contains the data necessary for SDP 128 to have access to the debit client's account. In an answer, the parameter content field contains the customer's account status. In step 508, the TCAP_RECV layer is executed within the AIN_APP. The TCAP_RECV layer determines which transport mechanism application sent the TCAP message. In other words, the TCAP_RECV layer determines whether the TCAP message is received by means of the NIM 210 of the manual operator console 122 or by means of the IPCJVIGR 206 from the SDP 128. When the message of the manual operator console 122A is transmitted, the TCAP_RECV layer will determine that the message is received from the NIM 210. When the TCAP_RECV layer determines the source of the message, it processes the corresponding decoder and constructor layers. The decoder and constructor layers are the layer AIN_PROCESS_MSG_NIM and the layer AIN_PROCESS_MSG_IPC. The TCAP_RECV layer is described in more detail with reference to Figure 11. The AIN_PROCESS_MSG_NIM layer is described in more detail with reference to Figure 8. With reference to Figure 10, the AIN PROCESS MSG IPC layer is described in more detail.

In step 510, the layer AIN_PROCESS_MSG_NIM is executed. Like the TCAP_RECV, the AIN_PROCESS_MSG_NlM layer is within the program of the AIN_APP computer. The AIN_PROCESS_MSG_NIM layer decodes the TCAP message and stores the message information in a configuration. The AIN_PROCESS_MSG_NIM layer fills a dialog identifier which identifies the element in the configuration where the information was stored. With reference to Figure 8, the layer AIN_PROCESS_MSG_NIM is described in more detail. In step 512, the TCAP_SEND layer is executed. The TCAP_SEND layer is also inside the AIN_APP. The TCAP_SEND layer determines which transport mechanism application will receive the TCAP message. In other words, the TCAP_SEND determines whether the TCAP message is transmitted via the NIM 210 to the manual operator console 122 or via IPC_MGR 206 to the SDP 128. Therefore, when the message is received from the manual operator console 122, the TCAP_SEND layer transmits the message to the SDP 128 via IPC_MGR 206. After the TCAP_SEND determines the recipient of the message, it processes the corresponding decoding and constructor layer of the message. With reference to Figure 12, the TCAP_SEND layer is described in more detail. In step 514, the SDP 128 receives the TCAP message. He SDP 128 is a computer system that includes a database that stores information from debit customer accounts. For typical debit calls, the SDP is reached 128 through SSCP 130. SSCP 130 provides automated menus that allow the debit client to select options and provide information to process the call. However, when the debit client wishes to use the services to clients, the route of the call must be assigned to one of the manual operator consoles 122 using the NSPP protocol (UDP / IP). The manual operator consoles 122 request information about the debit client required to process the call from the SDP 128 as it happens with the processing of a call by means of the SSCP 130. Unlike the processing of a call by means of the SSCP 130, a route is assigned to the call through the AIN because the protocol conversion is required. Like the processing of a call with the SSCP 130, the SDP 128 processes the TCAP message using information stored from the debit client's account. In step 516, the SDP 128 transmits a response TCAP message. The answer is a message of continuous type. Like the start type TCAP message, the continuous type TCAP message comprises a transaction portion and a component portion which are described in more detail in the Table 1 above. Unlike the start type TCAP message, the continuous type TCAP message has a type of continuous type message tag. In the previous Table 3 more details on message type labels are given. The SDP 128 stores the customer account information in the portion of the response TCAP message component that is shown in the previous Table 4. The component portion of a continuous type TCAP message comprises a return result component.

Table 6 The parameter field of the return result component of the continuous type TCAP message that is shown in Table 6 is used to transmit the account information of the debit client. The parameter field shown in Table 6 is the same format as the more detailed description of the parameter field that was commented with respect to the invocation component of the TCAP message of the startup type. The SDP fills the information within the content of the parameter field. In step 518, the TCAP_RECV layer is executed. The TCAP_RECV layer is the same layer that was processed in step 508 when the TCAP message of the start type was sent from the manual operator console 122. Like the start type TCAP message, the TCAP_RECV layer determines which mechanism application of transport sent the TCAP message. In other words, the TCAP_RECV layer determines whether the TCAP message is received by means of the NIM 210 of the manual operator console 122 or by means of the IPC_MGR 206 from the SDP 128. In step 518, the message is received from the SDP 128, so therefore, the TCAP_RECV layer will determine that the TCAP message was received from the IPC_MGR 206. When the TCAP_RECV layer determines the source of the message, it processes the corresponding decoder and constructor layers. With reference to Figure 11, the TCAP_RECV layer is described in more detail. At step 520, the layer AIN_PROCESS_MSG_IPC is executed. Like other layers that are described previously, the AIN_PROCESS_MSG_IPC layer is also within the program of the AIN_APP computer. The AIN PROCESS MSG IPC layer decodes the TCAP message and retrieves the information stored in the configuration during step 510. The AIN_PROCESS_MSG_IPC layer retrieves the dialog identifier of the message received from SDP 128. A dialog identifier is also used to identify the element in the configuration that was used to store the information during step 510 The AIN_PROCESS_MSG_IPC layer uses the dialog identifier to retrieve the information stored in the dialog configuration. The AIN_PROCESS_MSG_IPC layer fills the information stored within the TCAP message. With reference to Figure 10, the AIN_PROCESS_MSG_IPC layer is described in more detail. In step 522, the TCAP_SEND layer is executed. The TCAP_SEND layer is the same layer that was processed in step 512 when the TCAP message of the start type is transmitted from the manual operator console 122 to the SDP 128. Like the TCAP message process of the start type, the TCAP_SEND determines which transport mechanism application will receive the TCAP message. In other words, the TCAP_RECV layer determines whether the TCAP message is transmitted by means of the NIM 210 to the manual operator console 122 or by means of the IPC_MGR 206 to the SDP 128. Therefore, when the message of the SDP 128 is received with the If the TCAP_SEND layer determines the message that is being sent to the NIM 210 that provides the information to the manual operator console 122. When the TCAP SEND layer determines the message container, it processes the corresponding decoder and constructor layers. With reference to Figure 12, the TCAP_SEND layer is described in more detail. In step 524, the manual operator console 122A receives the continuous type TCAP message. The manual operator console 122A retrieves the information from the parameter contents field of the TCAP message and provides a human operator with the information needed to process the debit call. Figure 6 is a flow chart 602 illustrating the operation of the BOSS 202. The BOSS 202 is responsible for starting, stopping, and monitoring the processes in the AINGW 124. The BOSS 202 process is the first process that is called during the start of the AINGW 124. In step 606, the BOSS 202 starts through the batch process. The batch process submits batch jobs that include command procedures that start the BOSS 202 and enable the BOSS 202 to start processing. In step 608, the BOSS 202 reads the BOSS configuration file. The BOSS configuration file contains identifiers for each process that the BOSS 202 will initiate along with other information about the processes. In step 610, the BOSS 202 starts the processes in the BOSS configuration file. In this mode, the BOSS configuration file will call IPC_MGR 206.

During startup, each process initializes communication with the BOSS 202, performs internal initialization, and transmits a complete initialization message back to the BOSS 202. The BOSS 202 initiates the processes in the order that they are specified in the file Of configuration. The IPC_MGR 206 is responsible for the monitoring of the BOSS 202. Therefore, the IPC_MGR 206 is the first process that starts the BOSS 202. If the BOSS 202 malfunctions, the IPC_MGR 206 controls and starts again the BOSS 202. In step 612 , the BOSS 202 establishes a closure in each process that has been initiated. The closure will allow the BOSS 202 to be notified if a process ends. In step 614, the BOSS monitors the state of the applications. The BOSS 202 monitors specified processes to those that are related as beating processes. The BOSS configuration file has a heartbeat flag, which when set to Y, will cause the BOSS to monitor the beating process or beat. To monitor a process, the BOSS 202 transmits a heartbeat, starts a stopwatch, and waits for the response. If a response is not received from the process within the timeout period, the BOSS 202 will stop and start the process again. If other processes are interdependent of the malfunction of the process, the BOSS 202 will stop the other processes, restart the process that is malfunctioning, and then restart the others processes. In this embodiment, the heartbeat processes comprise the IPC_MGR 206, the alarm selector 218, the NIM 210, the AIN_APP 204, and the OM 214. The HMI 216 is not monitored by beats. In step 616, the BOSS 202 stops the applications.

The BOSS 202 stops the applications before the AINGW 124 system shuts down and is only in command of the HMI 216. Figure 7 is a flow diagram illustrating the operation of the main layer of the advanced intelligent network AIN_MAIN. The AIN_MAIN is the layer that is processed first when the AIN_APP 204 is started by the BOSS 202. The AIN_MAIN establishes the interconnections between the IPC_MGR 206 and the NIM 210 which allows the AIN_APP 204 to perform its functions as an interface between the operator consoles manual 122 and SDP 128. In step 706, the AIN_MAIN reads and validates the Advanced Intelligent Network (AIN) configuration file. The configuration file of the AIN contains the information that is needed to establish the connection with the SDP 128. In another embodiment of the present invention, the network contains more than one SDP 128. In that embodiment, the configuration file of the AIN contains the information that is needed to establish connections with all SDPs 128. More particularly, the configuration file of the AIN comprises a number of SDPs 128 and for each SDP 128, a singular SDP identifier, referred to as a key_server, the protocol to be used in communication with the SDP 128, such as TCP / IP, and the internet protocol addresses for each SDP 128. The internet protocol address is an address in the SDP 128 that identifies a point to interconnect and capture information. Typically, an SDP 128 has three protocol addresses from the internet. In step 708, the AIN_MAIN adheres to the IPC_MGR 206. The AIN_MAIN establishes an interconnection between the AIN_APP 204 and the IPCJMGR 206. Then the AIN_APP instructs the IPC_MGR to establish the TCP connections to the IP addresses to read the same from the file of configuration. The above allows the AINGW to communicate with the SDP 128. In step 710, the AINJYLAIN adheres to the NIM 210. When the AINJMAIN adheres to the NIM 210, the NIM announces to the consoles of manual operator 122 that the service to customers It is available for debit customers. In step 712, the AIN_MAIN initializes the dialog configuration. Dialog configuration is a configuration that can handle 1024 messages in a particular process. The dialog configuration stores information about the transaction as the transaction is being made. The YLAIN AIN stores a dialog identifier in the transaction capabilities message during the transaction. The dialogue identifier is used to recover the information that is stored in the dialog configuration during the transaction and points to the corresponding element in the configuration. In step 714, the AINJVLAIN routine instructs IPC_MGR 206 to establish communications. The routine of AIN_MAIN establishes communications with the NIM 210 after it has established TCP connections with the SDP 128 via IPC_MGR 206. In step 714, the AIN_MAIN winters and waits for a request from the NIM 210 to be received. Figure 8 is a flow chart 802 illustrating the process operation of the message client layer (AIN_PROCESS_MSG_NIM). The AIN_PROCESS_MSG_NIM layer receives the messages from the manual operator console 122A via the NIM 210 and the TCAP_RECV layer of the AIN_APP 204. In step 806, the AIN_PROCESS_MSG_NIM layer determines the operation code that was sent. An operation code is transmitted, which is one of the operation codes that were defined by the NSPP, by means of the NIM 210. The three operation codes that may be sent by the NIM 210 include UNKNOWN (UNKNOWN), MSG_INGW_REQ, and MSG_PICK. Each of the operation codes causes the AIN_PROCESS_MSG_NIM layer to perform a different function. The UNKNOWN operation code is an error message that causes an alarm. The operation code MSG_PICK is used to establish that the AIN_APP 204 is a service that is available. The MSG_INGW_REQ operation code is used by the manual operator console 122A to signal that a TCAP message is being sent to request information from the SDP 128. If the operation code is UNKNOWN, the step 808 is processed. In step 808, the layer AIN_PROCESS_MSG_NIM records an invalid alarm message. The invalid alarm message is recorded by means of the alarm selector 218. After performing step 808, the AIN_PROCESS_MSG_NIM proceeds to step 812. If the operation code is MSG__PICK, step 810 is processed. In step 810, the layer The AIN_PROCESS_MSG_NIM transmits a PICK_RSP message to the manual operator console 122A via the TCAP_SEND layer and the NIM 210. The PICK_RSP message indicates that the AIN_APP 204 is a service that is available. After performing step 810, layer AIN_PROCESS_MSG_NIM proceeds to step 832. If the operation code is MSG_INGW_REQ, step 812 is performed. Step 812 is the first to process the TCAP message sent by manual operator console 122A requesting SDP information 128. In step 812, the AIN_PROCESS_MSG_NIM layer finds the first element of the configuration available in the dialog configuration. The Dialog configuration is an internal configuration that is used to store transaction information. In step 814, the AIN_PROCESS_MSG_NIM layer registers the sender. The AIN_APP 204 allows access by means of many transport mechanism applications. Registering the sender allows the AIN_PROCESS_MSG_NIM to process the messages sent by multiple senders. For example, the SS7 manual operator consoles can be added to the network and processed by the AIN_PROCESS_MSG_NIM. The SS7 manual operator consoles are similar to the manual operator consoles 122 except that the SS7 manual operator consoles use SS7 signals instead of the NSPP. The AIN_PROCESS_MSG_NIM can be used to process the TCAP messages sent by the manual operator consoles SS7 122. In step 816, the layer of the AIN_PROCESS_MSG_NIM stores the header of the message. The message header is compatible with the SNPP and stored in the internal configuration. When a TCAP response message from SDP 128 is transmitted to the manual operator console 122A, AIN_PROCESS_MSG_IPC will retrieve the header of the message and reconstruct the message in the NSPP format to respond to the manual operator console 122A. In step 818, the layer of the AIN_PROCESS_MSG_NIM decodes the message. In step 820, the layer of the AIN_PROCESS_MSG_NIM determines the value of the selection variable. The value of the selection variable determines whether the BEGIN_CHOSEN routine is processed or a registered alarm and abort message is transmitted. The selection variable can be BEGIN_CHOSEN (START_SELECTED), END (END), ABORT (ABORT), CONTINUE (CONTINUE), UNKNOWN (UNKNOWN), and UNIDIRECTIONAL (UNIDIRECTIONAL). If the variable of the selection is BEGIN_CHOSEN, the BEGIN_CHOSEN routine is processed. If the selection variable is END, ABORT, CONTINUE, UNKNOWN, or UNIDIRECTIONAL, the AIN_PROCESS_MSG_NIM will register an alarm and send an abort message. In step 822, the layer of the AIN_PROCESS_MSG_NIM calls the routine BEGIN_CHOSEN. The BEGIN_CHOSEN routine validates and converts the data, destroys the TCAP message based on the NSPP and reconstructs the TCAP message based on the TCP / IP. The process of the routine BEGIN_CHOSEN is described in more detail with reference to Figure 9. After processing the routine BEGIN_CHOSEN, the AIN_PROCESS_MSG_NIM proceeds to step 832. In step 824, the layer AIN_PROCESS_MSG_NIM records an invalid alarm message. The invalid alarm message is recorded by means of the alarm selector 218. In step 826, the AIN_PROCESS_MSG_NIM layer creates an abort message. The abort message informs the manual operator console 122A that the request sent to the AINGW 124 is invalid.

In step 828, the AIN_PROCESS_MSG_NIM layer clears the configuration element. It is no longer necessary to store the information in an internal configuration for a response message from the SDP 128 to the manual operator console 122A because the request sent from the manual operator console 122A to the SDP 128 has been aborted. In step 832, the operation of the AIN_PROCESS_MSG_NIM is complete and the AIN_PROCESS_MSG_NIM is wintering until another message is received. Figure 9 is a flow diagram illustrating the operation of the selected start routine (BEGIN_CHOSEN). In step 906, the BEGIN_CHOSEN routine saves the originator of the transaction identifier in the free dialog configuration element founded by the layer of AIN_PROCESS_MSG_NIM in step 812 of Figure 8. The field of the originating transaction identifier is a field within the TCAP message portion as shown in Tables 2 and 3 above. For a TCAP message of the start type, the transaction portion contains an information element of the transaction portion as shown in Table 2. As shown in Table 3, the TCAP message of the start type includes an identifier of the transaction type. originating transaction in the field of the transaction identifier of the information element of the transaction portion of the TCAP message. During the processing of Debit client service calls, the key-server fills in the first 3 bytes of the originating transaction identifier field. In step 908, the BEGIN_CHOSEN routine sets the used / unused flag of the element in the dialog configuration to be used. This causes the information of the first processed message to be placed in the next element of the dialog configuration. In step 910, the BEGIN_CHOSEN routine validates the originating transaction identifier. The length of the originating transaction identifier is validated to ensure that it is 3 bytes. In step 912, the BEGIN_CHOSEN routine extracts key_server from the originating transaction identifier. Key_server identifies the SDP 128 that will receive the message.

Key_server is retrieved by routine BEGIN_CHOSEN from the field of the originating transaction identifier in the TCAP message. In step 914, the BEGIN_CHOSEN routine converts decimal key_server encoded in binary to an integer. Key_server is stored in a decimal format encoded in binary of 3 bytes. However, the binary decimal code allows 2 digits to be packed in 1 byte. After the conversion, key_server will be 6 bytes. In step 916, the BEGIN_CHOSEN routine validates key_server. Validate key_server involves the identification of a SDP 128 in particular that is associated with key_server and then retrieve the protocol addresses from the internet that are associated with SDP 128 of the AIN configuration file. The BEGIN_CHOSEN routine verifies that key_server is within the content of the AIN configuration file. If key_server is part of the contents of the AIN configuration, it corresponds to a valid SDP 128. The BEGIN__CHOSEN routine retrieves the Internet protocol addresses that correspond to the SDP 128 identified by the key_server of the AIN configuration file, Each SDP 128 has multiple Internet protocol addresses which are addresses in the SDP 128 that identifies the data points of the Internet. Possible interconnection to access the information In step 918, the BEGIN_CHOSEN routine adds 0x1000000 to the dialog id and fills the TCAP message with the dialog identifier, then the BEGIN_CHOSEN routine populates the dialog identifier in the transaction identifier field TCAP message source As shown in Table 2, the field of the originating transaction identifier is in the transaction component of the TCAP message The originating transaction identifier field no longer contains key_server since key_server was removed of the field of the originating transaction identifier in step 912. The identifier of The dialog is filled in the field of the originating transaction identifier of the TCAP message in place of key_servers. In step 920, the BEGIN_CHOSEN routine encodes the TCAP message. The routine BEGIN_CHOSEN encodes the TCAP message in the abstract syntax annotation of programming language of the generic computer standard in the industry (ASN.l). In step 920, the BEGIN_CHOSEN routine sets a stopwatch. In the preferred embodiment of the present invention, the chronometer is set for intervals in three seconds. The timer is configured to ensure that the response message that comes from the SDP 128 does not exceed a specified time, such as three seconds in the preferred embodiment of the present invention. In step 924, the BEGIN_CHOSEN routine transmits the TCAP message to the SDP 128 via IPC_MGR 206 by means of transmitting the message to the TCAP_SEND layer of the AIN_APP 204. Figure 10 is a flow chart 1002 illustrating the operation of the layer AIN_PROCESS_MSG_IPC The AIN_PROCESS_MSG_IPC receives the message from the IPC_MGR 206. In step 1006, the AIN_PROCESS_MSG_IPC layer validates the internet protocol address and returns the pointer to the service descriptor. The AIN_PROCESS_MSG_IPC layer validates that the internet protocol address corresponds to the internet protocol addresses associated with the SDP 128 that sent the TCAP message. The AIN_PROCESS_MSG_IPC layer returns the pointer to the corresponding service descriptor to a service. Like registering the sender that was made by the AIN_PROCESS_MSG_NIM layer in step 814 of Figure 8, by using a service descriptor, it allows the AIN_PROCESS_MSG_IPC to process multiple service response TCAP messages. For example, if an SDP 128 using signals from SS7 was installed, the AIN_PROCESS_MSG_IPC can process the messages received through the SS7 network. The service descriptor indicates the service that transmits the response message, such as SDP 128. In step 1008, the AIN_PROCESS_MSG_IPC layer decodes the message by using the ASN.l decoder which returns the decoded message to a structured buffer . Therefore, the application can access the individual parameters of the message. The abstract syntax annotation encoding (ASN.l) performed in step 920 of FIG. 9 is decoded. In step 1010, the AIN_PROCESS_MSG_IPC layer extracts the dialogue identifier of the TCAP message. In step 918 of Figure 9, the AIN_PROCESS_MSG_NIM layer stored the dialog identifier in the identifier field of the originating transaction portion of the TCAP message. Since the response message continued to be fixed, the TCAP message includes both origin and destination transaction identifiers as shown in Table 3 above. The dialog identifier is stored in the field of the destination transaction identifier in the response TCAP message sent from the SDP 128. The transaction portion of the continuous TCAP message is shown in more detail in Table 2 above. Additionally, the AIN_PROCESS_MSG_IPC layer validates the dialog identifier. The layer AIN_PROCESS_MSG_IPC validates that the dialog identifier is within limits. In other words, if the internal configuration has 2000 elements, the AIN_PROCESS_MSG_IPC validates the fact that the dialog identifier corresponds to an element between 0 and 1999. The AIN_PROCESS_MSG_IPC layer also validates the dialog identifier by means of ensuring that the flag of used / unused element in the configuration that corresponds to the dialog identifier is adjusted to be used. Validating that the used / unused flag of the element in the configuration corresponding to the dialog identifier is set to the used position, ensures that a TCAP response is not created for a response that was delayed beyond the period of - time out, which is configurable to three seconds in the preferred embodiment of the present invention. The time period outside is measured by means of the timer that was adjusted during step 922 of the process of routine BEGIN_CHOSEN. If the stopwatch time expires, an abort response message is transmitted to the manual operator console 122 and the used / unused flag that corresponds to the element in the configuration is adjusted to the unused position. With reference to Figure 13, the process to handle an expiring stopwatch is described in more detail. If the SDP 128 transmits a message that is delayed beyond the timeout period, the dialog identifier determines that it is no longer valid as a used / unused flag if it is set to not used. The AIN_PROCESS_MSG_NIM layer rejects the response message since the manual operator console 122A has already received an abort message and will not accept a response. In step 1012, the AIN_PROCESS_MSG_IPC layer replaces the destination transaction identifier with the originating transaction identifier saved. The AIN_PROCESS_MSG__IPC layer identifies the dialog configuration element that contains the NSPP header that identifies the manual operator console 122A that sent the message by using the dialog identifier that was retrieved from the destination transaction identifier of the portion of TCAP message transaction. The AIN_PROCESS_MSG_IPC layer retrieves the originating transaction identifier of the identified element from the dialog configuration. Then the AIN_PROCESS_MSG_IPC layer fills and stores the originating transaction identifier in the destination transaction identifier field of the message transaction portion TCAP. In step 1014, the AIN_PROCESS_MSG_IPC layer encodes the response TCAP message. In step 1016, the AIN_PROCESS_MSG_IPC layer cancels the timer. The stopwatch is canceled to ensure that it does not activate. In step 1018, the AIN_PROCESS_MSG_IPC layer transmits the continuous TCAP message to the manual operator console 122A via TCAP_SEND. The continuous type TCAP message contains the information requested by the manual operator console 122A in the return result component shown in Table 6 above. The information is stored in the parameter contents field shown in Table 6. In step 1020, the AIN_PROCESS_MSG_IPC layer clears the configuration element and sets the used / unused flag of the configuration elements in the configuration. unused position. The foregoing allows the configuration element to be used to process another TCAP message request from the manual operator consoles 122. Figure 11 is a flow chart 1102 illustrating the operation of the TCAP_RECV layer. The present invention has a single point of contact for the AIN_APP 204 to receive messages from different transport mechanism applications, specifically the NIM 210 interfacing with the console of manual operator 122 and IPC_MGR 206 which interfaces with SDP 128. The TCAP_RECV layer provides the only point of contact. In step 1106, the TCAP_RECV layer receives the TCAP message from the transport mechanism application, either the NIM 210 or the IPC_MGR 206. The TCAP_RECV layer receives the messages from the NIM when a TCAP message of the start type is transmitted from a console of manual operator 122A as described in step 408 of Figure 4. The TCAP_RECV layer receives the IPC_MGR 206 messages when a continuous type message is transmitted from the SDP 128 as described in step 418. In step 1108, the TCAP_RECV layer determines the sender of the TCAP message. In other words, the TCAP_RECV layer determines whether the TCAP message was received from the IPC_MGR 206 or the NIM 210. If the TCAP message was received from the IPC_MGR 206, step 1110 is carried out. In step 1110, the layer TCAP_RECV pulls the protocol address of the internet out of the stack. The internet protocol address is one of the three addresses associated with the SDP 128. In step 1112, the TCAP_RECV layer determines whether there are TCAP messages within the TCP / IP message. A TCP / IP message can contain multiple TCAP messages. If the TCP / IP message does not contain TCAP messages, step 1124 is carried out. In step 1114, the TCAP_RECV layer extracts the message TCAP of the TCP / IP framework. In step 1116, the TCAP_RECV layer determines whether the current of a previous TCAP message was fragmented. The TCAP_RECV layer determines whether the message is complete. If the message is fragmented or incomplete, the TCAP_RECV layer stores the message in a configuration and sets the timer. If the message remnant is received in another TCP / IP framework before the end of the timeout period, the TCAP_RECV layer will process the already completed TCAP response message. If the remnant of the message is not received within this timeout period, the configuration item will be cleared. If a reply TCAP message is not received, the timer time that was set during the processing of the BEGIN_CHOSEN routine in step 922 of Figure 9 will expire and the routine of the AIN_TIMER_EXPIRED will be processed. With reference to Figure 13, the AIN_TIMER_EXPIRED will be described in more detail. In step 118, the TCAP_RECV layer calls the layer of the AIN_PROCESS_MSG_IPC. After processing the AIN_PROCESS_MSG_IPC layer, step 1112 is carried out. If the TCAP message was received from the NIM 210, step 1120 is carried out. In step 1120, the TCAP_RECV layer pulls the message identifier and the number of message service outside the stack. The message identifier and the service number are NSPP parameters that identify the message. The message identifier is filled in the message Response TCAP. In step 1122, the TCAP_RECV layer calls the layer of the AIN_PROCESS_MSG_NIM. The layer of the AIN_PROCESS_MSG_NIM is described in more detail in Figure 11. After the layer of the AIN_PROCESS_MSG_NIM has been processed, step 1124 is carried out. In step 1124, the TCAMP_RECV layer winters and awaits another TCAP message. Figure 12 is a flow chart 1202 illustrating the operation of the TCAP_SEND layer. The TCAP_SEND layer transmits the messages to the transport mechanism applications. As in the received routine, the TCAP_SEND layer is a single contact point that transmits messages to different transport mechanism applications, specifically the NIM 210 and the IPC_MGR 206. In step 1206, the layer of the TCAP_SEND determines whether the message goes to the NIM. The TCAP_SEND layer determines which transport mechanism application, either IPC_MGR or NIM 210, will receive the TCAP message. If in step 1206 it is determined that the IPC_MGR 206 is the one receiving the TCAP message, then step 1208 is carried out. If the IPC_MGR 206 is not the one receiving the TCAP message the TCAP_SEND layer proceeds to step 1214. In step 1208, the TCAP_SEND layer pulls the server descriptor and the dialog handle out of the stack. The descriptor of server includes key_server and the protocol addresses of the internet that correspond to key_server. In step 1210, the TCAP_SEND layer rotates the list of protocol addresses on the internet and finds the first available connection. The TCAP_SEND determines if the connectivity to the address exists in the IPC_MGR and communication can be established. If connectivity does not exist, TCAP_SEND attempts to initiate communication with another address in IPC_MGR 206. If connectivity exists, TCAP_SEND proceeds to step 1212. In step 1212, the TCAP_SEND layer transmits the message to IPC_MGR 206. The operation of the TCAP_SEND illustrated by the flow diagram 1202 is complete after step 1212 is carried out as indicated in step 1230. If in step 1206 it is determined that the NIM 210 is the one receiving the TCAP message, it is perform step 1214. In step 1214, the TCAP_SEND layer determines the type of message. A type of message is one of the message types determined by the NSPP. The two message types that may be sent include the MSG_INGW_RSP and the MSG_PICKRSP. Each of the message types causes the TCAP_SEND layer to perform a different function. The message type MSG_PICKRSP is transmitted to the manual operator console 1122A during startup to establish that the AIN_APP 204 is an available service. The type of message MSG_INGW_RSP is transmitted to the manual operator console 122A to signal that a response to the TCAP message is being sent as long as the information that has been requested from the SDP 128. If in step 1214 it is determined that the message type is MSG_INGW_RSP, it is carries out step 1216. In step 1216, the TCAP_SEND layer pulls the return code and the dialog identifier out of the stack. The return code indicates whether the message succeeded or failed. In step 1218, the TCAP_SEND layer copies the header of the configuration element. The NSPP compatible header was stored in the internal dialog configuration by the AIN_PROCESS_MSG_NIM in step 816 of Figure 8. In step 1220, the TCAP_SEND layer constructs the message header INGWRSP. The header of the INGWRSP message is a compatible NSPP header. The TCAP_SEND layer constructs the NSPP headers so that the TCAP message is understood by the NIM 210. After the step 1220 has been carried out, the TCAP_SEND layer proceeds to step 1224. If in step 1214 it is determined that the type of message is MSG_PICKRSP, step 1222 is carried out. In step 1222, the TCAP_SEND layer constructs the PICKRSP message header. The PICKRSP message header is compatible with the NSPP.

In step 1224, the TCAP_SEND layer transmits the message to NIM 210. The TCAP_SEND operation, illustrated in flow diagram 1202, is complete after step 1224 is carried out as indicated in step 1230. Figure 13 illustrates the operation of the expired chronometer routine 1302 of an advanced intelligent network (AIN_TIMER_EXPIRED). In step 1304, the AIN_TIMER_EXPIRED routine searches for the configuration for the chronometer identifier corresponding to the expired timer. In step 1306, the routine of the AIN_TIMER_EXPIRED constructs a TCAP abort message header. In step 1308, the AIN_TIMER_EXPIRED routine returns a TCAP abort message to the sender. The TCAP abort message informs the manual operator console 122A that the message request was unsuccessful. If the information was requested to SDP 128 by the manual operator console 122A, the TCAP abort message indicates that the manual operator console 122A will not receive the requested information within the timeout period. In step 1310, the AIN_TIMER_EXPIRED routine clears the configuration element. The data contained in the configuration element is cleared and the used / unused flag of the configuration element is placed in the unused position. The above allows the element of the configuration is used to process another TCAP message. The routine operation of the AIN_TIMER_EXPIRED is completed after step 1310 has been carried out as shown in step 1312. Other embodiments of the present invention are possible. Referring to Figure 1, the AINGW 124 can be used in other environments that require the conversion of the procotolo. For example, the present invention may also include an SS7 MGR (Signage System Manager "7") which is used to interface with one or more computer systems using the SS7 protocol (Administrator of Signaling System Number 7). The SS7 protocol complies with the ITU standards that are described in the document previously referred to. The SS7 protocol would be used to establish communication with a computer system that is in interface with the SDP 128. In a modality that includes the SS7_MGR, the present invention converts from the NSPP protocol to SS7. The TCAP_RECV and TCAP_SEND layers include additional steps. In the TCAP_RECV, an additional step is included to determine if the message is received from the SS7_MGR. If the message is received from the SS7_MGR, the layer of the AIN_PROCESS_MSG_IPC is processed. In the TCAP_SEND layer, additional steps are included to determine if the message is transmitted to the SS7_MGR. If so, the process is similar if the message is transmitted to IPC_MGR 206.

Additionally, the layers of the AIN_PROCESS_MSG_IPC and the AIN_PROCESS_MSG_NIM include a step to determine if the message is communicating by using IPC_MGR 206 or SS7_MGR. The decoding and construction mechanisms include slight modifications that are necessary to make the message compatible with the SS7. Additional modalities that do not include the start-up and monitoring processes as described are possible. You can use other startup and monitoring processes and omit the monitoring processes. The processes of initiation and monitoring include the supervision service, alarm selector, operational measurement process, and the human machine interface. Even though different embodiments of the present invention have been described above, it should be understood that they have been presented only as examples, not as limitations. Therefore, the scope and scope of the present invention should not be limited in any way by any of the exemplary embodiments described above, but should be defined solely in accordance with the following claims and their equivalents.

Claims

CLAIMS 1. A method for converting a protocol from a transaction message of part application capabilities between the implementation of an internet protocol / transmission control protocol and the implementation of an internet protocol / user datagram protocol, which comprises the steps of: (a) receiving a transaction message of application capabilities from the sender; (b) convert the transaction protocol of part application capabilities between the implementation of a user datagram protocol / internet protocol and the implementation of a transmission control protocol / internet protocol; and (c) transmitting the transaction message of part application capabilities. The method of claim 1, wherein step (a) comprises the steps of: (i) receiving the transaction capability message from the sender; (ii) determine the protocol of the transaction message of part application capabilities; (iii) if in step (ii) it is determined that the protocol of the capability transaction message of part application is the implementation of a protocol of a user datagram / internet protocol, which pulls a message identifier and service number out of a stack; Y; (iv) call a software layer for the conversion of the user datagram protocol / internet protocol to a transmission control protocol / internet protocol. The method of claim 1, wherein step (a) comprises the steps of: (i) receiving the transaction capability message from the sender; (ii) determine the protocol of the transaction message of part application capabilities; (iii) if in step (ii) it is determined that the part application capabilities transaction message protocol is the implementation of an internet protocol / transmission control protocol, which pulls an internet protocol address out of a pile; Y; (iv) determine if an additional transaction message of part application capabilities is within a transmission control protocol / framework of the internet protocol. 4. The method of claim 3, further comprising the steps of: (v) If in step (iv) it is determined that the additional transaction message of the aforementioned application capabilities is within a transmission control protocol / internet protocol framework, extract the message from the transaction capabilities of application of part of the aforementioned transmission control protocol / framework of the internet protocol; (vi) determine if the message of the part application capabilities transaction is fragmented; and (vii) if in step (vi) it is determined that the part application capabilities transaction message is not fragmented, call a software layer to convert from a transmission control protocol / internet protocol, to a protocol of user datagram / internet protocol. The method of claim 1, wherein step (b) comprises the steps of: (i) determining the value of the operation code; Y (ii) If it is determined in step (i) that the operation code is UKNOWN, record an invalid alarm message. The method of claim 1, wherein step (b) comprises the steps of: (i) determining the value of the operation code; Y (ii) If it is determined in step (i) that the operation code is MSG_PICK, which transmits a PICK_RSP message to the sender The method of claim 1, wherein step (b) comprises the steps of: (i) determining the value of the operation code; and (ii) if it is determined in step (i) that the operation code is MSG_INGW_REQ, which finds a first configuration element; (iii) store a header of the transaction of part application capabilities; (iv) decoding the transaction of part application capabilities; and (v) determining a variable value of a selection variable. The method of claim 7, further comprising the steps of: (vi) if it is determined in step (vi) that the value of the variable of the selection variable is selected from the group consisting of END, ABORT, I CONTINUED, UNKNOWN, and UNIDIRECTIONAL, which records an invalid alarm message; (vii) create an abortion message; and (viii) transmit the abort message to the sender. The method of claim 7, further comprising the steps of: (vi) if it is determined in step (vi) that the value of the variable of the selection variable mentioned above is BEGIN_CHOSEN, which saves the identifier of the originating transaction in an element of the configuration; (vii) set a used / unused flag that corresponds to the configuration element to be used; (viii) validate the originating transaction identifier; (ix) extract a key_server from the originating transaction identifier; (x) convert key_server mentioned in binary encoded decimal format to integer format; (xi) validate key_server mentioned; (xii) adding 0x1000000 to a dialog identifier corresponding to the aforementioned configuration element to convert the aforementioned dialog identifier to hexadecimal format; (xiii) filling the transaction message of part application capabilities with the said dialog identifier; (xiv) encode the transaction message of part application capabilities; and (xv) setting a timer to record the time for a response to the transaction message of part application capabilities. 10. The method of claim 1, wherein step (b) comprises the steps of: validating an internet protocol address; returning a pointer to a service descriptor, which decodes the transaction message of part application capabilities; extracting a dialog handle associated with an element of the transaction settings configuration from part application capabilities; validate the aforementioned dialogue identifier; recover a source transaction identifier of said configuration element; replacing a destination transaction identifier in the transaction message of part application capabilities with said originating transaction identifier; and encode the transaction message of part application capabilities. The method of claim 10, further comprising the steps for canceling a timer that was set to record the time for a response to said transaction message of part application capabilities. The method of claim 10, further comprising the steps of: clearing the configuration element and set the used / unused flag that corresponds to the mentioned element of the unused configuration. The method of claim 1, wherein step (b) comprises the steps of: searching one or more elements of the configuration of a configuration for a configuration element that corresponds to a chronometer identifier; build an abort header for the transaction message of part application capabilities; return to the part application capabilities transaction message; and clearing an element of the dialogue configuration corresponding to the transaction message of application capabilities of the party identified by the information in one of one or more elements of the configuration corresponding to said chronometer identifier. The method of claim 1, wherein step (c) comprises the steps of: (i) determining the container of said transaction message of part application capabilities; (ii) if it is determined in step (i) that the aforementioned recipient requires the aforementioned transaction message of application capabilities of part in the implementation of the transmission control protocol / network protocol, take out a descriptor from the server and a dialog id outside from a pile; '(iii) unwrap a list of one or more protocol addresses from the internet; (iv) find an available connection; and (v) transmitting the transaction message of part application capabilities to an interprocess communication manager. The method of claim 1, wherein step (c) comprises the steps of: (i) determining the container of said part application capabilities transaction message; (ii) if it is determined in step (i) that the aforementioned recipient requires the aforementioned transaction message of application capabilities of part in the implementation of the datagram protocol of the user / protocol of the network, which determines the message type of the network. transaction message of part application capabilities. The method of claim 15, further comprising the steps of: (iii) if it is determined in step (ii) that the said message type is MSG_PICKRSP, constructing a header of the PICKRSP message; and (iv) transmitting the transaction message of part application capabilities to an NSPP interface module. 17. The method of claim 15, further comprising the steps of: (iii) if it is determined in step (ii) that said message type is MSG_INGW_RSP, to draw a return code and a dialog identifier out of the stack; (iv) copy a header of an element of the configuration; (v) construct a header of the INGWRSP message; and (vi) transmitting the transaction message of part application capabilities to an NSPP interface module. 18. A method for performing the protocol conversion of a transaction capability application message comprising: receiving the transaction message from part application capabilities; maintain a configuration that has one or more configuration elements; find one or more of the aforementioned configuration elements that are available; retrieve the transaction message data from part application capabilities; Saving the aforementioned data in one or more of the said configuration elements that are available; transmit the capabilities transaction message of part application; receive a transaction response message from part application capabilities; recover the aforementioned data from the mentioned configuration element; re-filling the mentioned data in said transaction response message of part application capabilities; and transmitting said transaction response message of part application capabilities. 19. A computer system for performing the protocol conversion of an application capabilities transaction message, comprising: an element for monitoring the process during protocol conversion; an element to interconnect with a receiving computer program; an element to interconnect with a transmitting computer program; and an element to perform the protocol conversion of the transaction response message of part application capabilities between the implementation of a transmission control protocol / internet protocol and the implementation of a user datagram protocol / protocol of the Internet. 20. The computer system of claim 19 wherein the elements for monitoring the process during the protocol conversion comprise: an element for reading the configuration file of the basic monitoring service; an element to start one or more layers of computer programs in the configuration file of the basic monitoring service; and an element to monitor one or more layers of computer programs in the basic monitoring service configuration file. The computer system of claim 19 wherein the elements for performing the protocol conversion of the transaction response message of part application capabilities between the implementation of a transmission control protocol / internet protocol and the implementation of a user datagram protocol / internet protocol comprising: an element to initiate communication with the previous element to interconnect with the computer program it receives and an element to interconnect with the computer program it transmits; an element to receive the transaction message of part application capabilities; an element to perform the protocol conversion of the part application capabilities transaction message; and an element for transmitting the transaction message of part application capabilities. 22. The computer system of the claim 19 wherein the elements to initiate communication with the above elements to interconnect with the computer program it receives and the elements to interconnect with the computer program it transmits comprises: an element to read and validate an application configuration file of a advanced intelligent network; an element to be attached to the previous element to interconnect with the computer program it receives; an element to attach to the previous element -to interconnect with the computer program it receives; an element to initialize a configuration; an element to establish communications; and an element to winter. 23. A computer system product comprising a usable computer means having a logical computer program stored thereon, wherein the computer logic program comprises: an element that receives to receive a transaction message of application capabilities from part; a conversion element to convert a protocol of the application implementation part transaction message between the implementation of an internet protocol / transmission control protocol and the implementation of an internet protocol / user datagram protocol; and a sending element for transmitting a transaction message of part application capabilities. 24. A computer comprising: an element that receives to allow a computer to receive a transaction message of part application capabilities; a conversion element to allow the computer to convert a transaction message protocol of part application capabilities between the implementation of an internet protocol / transmission control protocol and the implementation of a user datagram / protocol protocol the Internet; and an element that transmits to allow a computer to receive a transaction message from part application capabilities. 25. A computer system network comprising: a service data point for storing the information of a debit customer's account; an access door of an advanced intelligent network coupled to the service data point configured to perform the protocol conversion; one or more centers of the LANs / WAN operator network coupled to the advanced intelligent network access gate; and one or more operator consoles coupled to one or more operator network computer systems. 26. The network of the computer system of claim 25, further comprising: an automated call distributor coupled to one or more operator consoles; a bridge switch coupled to the automated call distributor; and a switch service control point coupled to the bridge switch. 27. The computer system network of claim 25 further comprising: an automated call distributor coupled to a LANs / WAN operator network center; a bridge switch coupled to the automated call distributor; and a switch service control point coupled to the bridge switch. 28. The computer system network of claim 26 further comprising: an intelligent service network application processor coupled to the automated call distributor and to a LANs / WAN operator network center.