MXPA00003912A - Validationgateway - Google Patents

Abstract

A method for billing a customer credit card account includes the steps of (a) sending a validation request message from a caller interaction processor to a validation gateway (308);(b) converting the validation request message from a client server protocol to a packet switching network protocol (310);(c) sending a card request message from the validation gateway to a financial processor for authorization to charge the customer credit card account (312);(d) sending a card reply message from the financial processor to the validation gateway (314);(e) converting from the packet switching protocol to the client server protocol (316);(f) sending a validation response message from the validation gateway to the caller interaction processor (318).

Description

MEANS OF VALIDATION 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 the telecommunications network are services provided by telephone companies, which are carried out in telecommunications networks. A well-known example is the long-distance voice service dial 1, which allows a customer to dial a 1 plus a ten-digit number from their home phone, speaking coa. a party that answers the telephone on the line of the ten digit number dialed, and pay for the telephone call when invoiced at the end of the month. Although dialing 1 is popular, other call and payment options are sometimes preferable. For example, a phone card call allows an individual to make a call from a different phone to their home phone, and charge the call to the home phone bill, using the phone card. One of these call and payment options is the debit call, which is also referred to as a previously paid call. The debit call allows a customer to put the funds in an account, and to charge those funds every time a phone call is made. The standard debit call processing includes verification of the account balance, before connecting the call and checking the balance in progress during the call. An example of a typical debit customer is a parent who buys a debit call card for a child away from home. Once a debit account is established, a customer can add funds to the debit account. Customers frequently add funds to their debit accounts using credit cards. To add funds, a customer contacts the telephone company by dialing a telephone number that is answered by a customer service representative, or an operator, and requests that funds be added to the debit account. The customer service representative or operator gathers the customer information, and processes the request to add funds. In order to add funds, the customer must select a payment method, and the customer service representative or operator must obtain authorization and enter the necessary information to subsequently bill the customer. If the customer chooses to pay for funds added to a debit account using a credit card, authorization must be obtained for the charges from the financial institution that provides the credit card account to the customer. Authorization to charge to a customer's credit card account is typically obtained by accessing a computer system owned by the financial institution. The computer system typically includes a database with information about the customer's account, and one or more computer programs that can determine, using information about the customer's account, if a particular transaction is authorized to bill the card account. customer's credit When the financial institution authorizes a transaction, the telephone company receives an authorization response code, which reflects a commitment from the financial institution that it will pay the telephone company for the services provided. Because the computer systems used by financial institutions communicate using a different protocol to the computer systems that operate in telephone networks, the conversion of the protocol is needed so that the computer systems that operate in the telecommunications networks can be accessed. automatically the computer systems used by financial institutions that authorize billing transactions. A protocol is a standard that computer programs follow to be compatible with other computer programs. The protocols determine what information is transmitted, what timing values should be associated with the transfer of information, and what format should be used to transmit the information. A standard or protocol may be used throughout the telecommunications industry, or it may be owned by a private entity for use with computer systems sold or operated by that entity. Components of the telecommunications network are available, which allow communication between the computer systems operating in the telecommunications network and the computer systems used for financial institutions, for the authorization in real time of charges processed by a human operator However, these components do not allow real-time authorization of automatically processed charges, and they do not provide real-time updates to the telephone company's computer systems that process billing for other telecommunications products. The computer systems used by telephone companies process billing differently from the computer systems used by financial institutions. Typically, billing for a telecommunications product can not occur until after a call is ended, because billing depends on the duration of the call. For example, when a customer uses a calling card with added features, such as the ability to access news and weather, billing for the call involves a two-step process. First, telecommunication network computer systems that process calling cards provide a record of the use of the calling card to computer systems that process the billing of the telephone company. Secondly, a switch, which is a component within the telecommunications network, provides information about the duration of the call to the billing computer systems of the telephone company. Then, the billing computer systems of the telephone company reconcile these records. However, unlike billing by calling using a calling card with added features, billing for a request to add funds to a debit account does not depend on the call duration. The customer requests to add a specified amount to a debit account. The duration of the call affects the amount of funds deducted from the account at the end of the call, but not the amount added to the customer's account. Therefore, adding the specified amount to the debit account can be done as a single transaction. Unfortunately, the current telephone company billing computer systems are not programmed to process billing for a single transaction. As a result, the reconciliation of the records of the billing computer systems of the telephone company, and the records of the computer systems of billing of the financial institution currently is not in real time. Reference is made to the reconciliation process of the records of the billing computer systems of the telephone company and the billing computer systems of the financial institution as conciliation.

COMPENDIUM OF THE INVENTION The system and method of the present invention provide communication between telecommunications networks and computer systems used by financial institutions, for the purpose of processing customer requests to pay for telecommunication services with their cards of credit. With the present invention both the real-time authorization and the reconciliation of charges are possible. In addition, the present invention provides the protocol conversion between a client server protocol used by telecommunications networks and an X.25 protocol used by the financial institutions' computer systems. The conversion of the protocol allows the communications for requests to invoice, using a credit card processed both by a human operator, and automatically. The system of the present invention comprises a validation gateway that has a computer program that allows the transfer of messages, and the conversion of the protocol, to allow the. communication between the telecommunications network that received the call, and the computer system used by the financial institution that provides the customer with the services of the credit card. The validation gateway operates in an internal exchange network, to provide an interface between the internal exchange network and the computer systems owned by financial institutions. An internal exchange network is a telecommunications network that provides long distance telephone services and other telecommunications services. The computer program in the validation gateway includes software modules that perform the specified functions. The modules inside the computer program of the validation gateway receive messages from, and send messages to, the calling interaction processors. Interaction processors that call are processors that allow a human operator to interact, or interact directly with a debit client to receive client call processing information. Two examples of interaction processors that call are the manual operator consoles and the service switching control points (SSCPs). The manual operator console is a computer that is similar to a personal computer, and is operated by a human operator to provide the human operator with the necessary information to request customer information, and enter the information provided by the customer to process the call. The service switching control point provides automated call processing for a debit client that uses a keypad to enter the information received by the service switching control point. The computer program at the validation gateway also includes software modules that send messages to, and receive messages from, the computer systems used by financial institutions, which are referred to as financial processors. Financial processors are the computer systems used by financial institutions to authorize charges to credit card accounts. These modules act as a single interface point for the transfer of messages from multiple clients between the validation gateway and the financial processor. In addition, the computer program in the validation gateway includes a module that converts between the protocol used by the calling interaction processors and the protocol used by the financial processors for credit card authorization. This module accepts the validation request messages in a request information format. The module stores the information received in the message and constructs a card request message to be sent to the financial processor. This module also accepts a financial processor card reply message, retrieves the stored information, and constructs a validation response message to be sent to the calling interaction processor. The method of the present invention comprises steps to receive, convert the protocol, and send messages to process customer credit card applications. The method of the present invention includes the steps for receiving a validation request message from a calling interaction processor, constructing a card request message that can be understood by the financial processor, and sending the card request message to the financial processor. . The method of the present invention also includes steps for receiving a card reply message from the financial processor, constructing a validation response message that can be understood by the calling interaction processor, and sending the validation response message to the processor. calling interaction.

The system and method of the present invention is not limited to the processing of credit card authorization requests. Interaction processors that call are clients that operate in a client server network. A client server network is a network of one or more computer systems, which includes multiple clients that are controlled and monitored by one or more servers. In this case, the interaction processors that call are clients that are controlled and monitored by the computer systems of the operator's network center, which are servers. In addition, the present invention can be used to communicate with any processor that is accessed by means of a packet-switched network, and is not limited to accessing a financial processor. Therefore, the system and method of the present invention can provide protocol conversion between any client server protocol that a client uses, and any packet switching protocol that a processor uses, to allow the transfer of messages. The system and method of the present invention also allows access by financial processors to computer systems operated by the telephone company that validates calling cards, pre-paid cards, and other cards provided by the telephone company. The present invention accepts requests from the res that the financial processors use, typically an X.25 network, performs a protocol conversion, transmits the request to the appropriate computer system in the telecommunications network, and provides an answer to the requester by means of the X.25 network. The computer program modules in the validation gateway perform the same functions, albeit in a different order, to process these requests. Subsequently, other features and advantages of the invention are described in detail, as well as the structure and operation of different embodiments of the invention, with reference to the accompanying drawings. In the drawings, the same reference numbers generally indicate identical, functionally similar, and / or structurally similar elements. The drawing in which an element appears first is indicated by the digits further to the left in the corresponding reference number.

BRIEF DESCRIPTION OF THE FIGURES Figure 1 is a blog diagram of an interface environment of a validation gateway, in accordance with a preferred embodiment of the present invention. Figure 2 is a block diagram of the structure of an interface validation gateway of the interface environment of Figure 1, in accordance with a preferred embodiment of the present invention. Figure 3 illustrates the flow of messages between a manual operator console and the financial processor, in accordance with a preferred embodiment of the present invention. Figure 4 illustrates the protocol conversion of a client server protocol to X.25, in accordance with a preferred embodiment of the present invention. Figure 5 illustrates the conversion of X.25 to a client server protocol, in accordance with a preferred embodiment of the present invention. Figure 6 illustrates the flow of messages between the service switching control point and the financial processor, in accordance with a preferred embodiment of the present invention. Figure 7 illustrates the flow of messages to create a billing data record by means of a validation gateway, in accordance with a preferred embodiment of the present invention. Figure 8 illustrates the message flow to validate a received request message in a permanent virtual circuit X.25, in accordance with a preferred embodiment of the present invention. Figure 9 illustrates the message flow to validate a received request message in an X.25 switched virtual circuit, in accordance with a preferred embodiment of the present invention.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS Figure 1 is a block diagram of a validation gateway interface 102 interface environment, in accordance with a preferred embodiment of the present invention. The validation gateway 130 provides access to the financial processor 132, to allow the validation of credit cards. The validation gateway interface 102 environment is a possible environment of a validation gateway 130. The validation gateway interface interface 102 described below includes the telecommunications network needed to process requests. of the customer to add funds to a debit account. The validation gateway 130 allows the components of the telecommunications network to communicate with a financial processor 132. A financial processor 132 is a computer system that provides credit card charge authorization. The financial processor 132 typically uses the X.25 protocol, and can be accessed by means of an X.25 network. A typical call can be processed manually by a human operator, using a manual operator console 122A, or automatically by means of the service switching control point (SSCP) 138. The components of the telecommunications network include many telecommunications networks such as first and second local exchange networks 106 and 134, and an internal exchange network 110. The internal exchange network 110 comprises a plurality of switches including an internal exchange network switch 108 and a bridging switch 112. In addition , inside the internal exchange network 110, an automated call distributor (ACD) 114, an intelligent service network application processor (ISNAP) 116, manual operator consoles 122A, 122B, ... 122n, a advanced intelligent network access (AIN) gate 124, a service data point (SDP) 128, and validation access gate 130, for processing client requests e debit to add funds to debit accounts managed by a human operator. If the validation request for adding funds to a debit account is processed automatically, the service switching control point 138, the service data point 128, the advanced intelligent network 124, the validation access gate 130 are used. , and a Billing Data Registration (BDR) server. Please refer to the attached Glossary for a reference of acronyms and their definitions. The interface environment of a validation access gate 130 can best be described by reference to the processing of a typical call. First, the interface environment of a validation gateway 130 will be described with reference to a typical call, which is manually processed by a human operator. A debit client establishes a call using a telephone 104. The call is received by a first local exchange network 106. The 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. a local telephone operator company such as Bell Atlantic. The first local exchange network 106-sends the call to an internal exchange switch 108A in an internal exchange network 110. Like the first local exchange network 106, an internal exchange network 110 comprises a plurality of switches, a which are also referred to as exchanges, which are located throughout a geographical area. However, the internal exchange networks 110 typically comprise switches throughout a large geographic area to process long-distance telephone calls. For example, a national internal exchange network 110 comprises switches located throughout the nation. When a call is routed to the internal exchange network 110, it can be routed to one or more switches within the internal exchange network.

If the call is received by an exemplary internal exchange network switch 108A, the internal exchange network switch 108A will route the call to a bridging switch 112A. The bridging switch 112A will then route the call to the ACD 114. Alternatively, if a bridging switch 112A receives the call, the bridging switch 112A will route the call to the ACD 114. In other words, if the call is received by a bridging switch 112A, then the call can pass through only the bridging switch 112A before being routed to the ACD 114. The switches in the internal exchange network 110, including the internal exchange network switch 108, and the bridging switch 112 , can be implemented using D-250 switches manufactured by Nortel. After the bridging switch 112 sends the call to the ACD 114, the ACD communicates with the ISNAP 116 to route the call to a manual operator console 122A. The exemplary manual operator console 122A allows a human operator to handle an individual debit call. The manual operator consoles 122 are logically defined in the software as being in groups. The ISNAP 116 selects a manual operator console 122A and ensures that incoming calls are distributed among the logically defined groups. The ACD 114 provides switching functionality between the selected manual operator console 122A and the internal exchange network 110. The ACD 114 can be implemented using the automated call distributor manufactured by Nortel. The ISNAP 116 communicates with the manual operator consoles 122 by means of the computer systems of the operator's network center. The preferred embodiment of the present invention includes two computer systems of the operator's network center, a wide area network (WAN) 118 of the operator network center, and a local area network (LAN) 120 of the network center of the operator. operator. The WAN 118 of the operator network center and the LAN 120 of the operator center help the ISNAP ~ 116 to direct the call to a manual operator console 122A. In addition, WAN 118 of the operator center and LAN 120 of the operator center store the information used to process the calls. Manual operator consoles 122 communicate with WAN 118 and LAN 120 of the operator's network center, using UDP / IP. Manual operator consoles 122 are computer consoles that receive information from WAN 118 of the operator's network center and LAN 120 of the operator's "network center, and they give the human operator (not shown) the information to direct the debit client's call Unfortunately, WAN 118 from the operator's network center and LAN 120 from the operator's network center do not include debit client account information Manual operator consoles 122 need access to another system of the computer for the purpose of obtaining information from the debit client's account The service data point 128 stores the information of the debit customer's account that was used for traffic management, service provisioning, and billing of the calls In accordance with the present invention, the manual operator console 122 accesses the service data point 128 by means of the advanced intelligent network 124 and the LAN 1 28 of the service data point. In addition, the advanced intelligent network 124 also provides protocol conversion between the transmission control protocol / internet protocol (TCP / IP) using the service data point 128 and the user datagram protocol / internet protocol (UDP / IP) using the manual operator consoles 122. The advanced intelligent network 124 is described in more detail in the co-pending United States Patent Application with Attorney Number CDR-96-009 (1575.2240000), entitled "Advanced Intelligent Network Gateway", incorporated herein by reference. The selected manual operator console 122A uses the information received from the service data point 128 to process the call. If the customer who is establishing a debit call does not have sufficient funds in their debit account, and wishes to use a credit card to add funds, the manual operator console must obtain authorization for the customer to charge the credit card. The authorization of the charges to the credit card is done by a financial processor 132. The financial processor 132 is accessed to process the customer's request, which is interchangeably referred to herein as a validation request, by means of of the validation access gate 130. The validation gateway 130 translates between UDP / IP using the manual operator consoles 122 and the X.25 protocol used by the financial processor 132. The validation gateway 130 has a computer program that is referred to as a validation computer program, which is also referred to as a validation application (VALID_APP), which performs the message transfer and protocol conversion that is needed for a message flow between the manual operator console 122A and the financial processor 132. VALID_APP includes software modules that interconnect with the operated consoles r manuals 122A, perform protocol conversion, and interconnect with X.25 network using financial processor 132. The preferred embodiment of the present invention performs translation between the UDP / IP protocol and the X.25 protocol. However, the present invention can perform the protocol conversion between any client server protocol and any packet-switched network protocol. A client server protocol is a protocol that uses a client server network, such as UDP / IP. A packet-switched network protocol is a protocol, such as X.25, that uses a packet-switched network. Therefore, the system and method of the present invention can provide message transfer and protocol conversion to any packet-switched network protocol, and is not limited to the X.25 protocol. Although the system and method of the present invention is described with respect to the X.25 protocol, it should be understood that the term "X.25 protocol" refers to any protocol that uses a packet-switched network. VALID_APP performs the protocol conversion by means of constructing a card request message of a validation request message, and by means of constructing a validation reply message of a card reply message. Initially, the manual operator console 122A sends a request, validation message to request authorization to bill a customer's credit card. The validation request message contains transaction data such as the account number of the customer's credit card, the type of credit card, the expiration date of the credit card, and the amount the customer wishes to charge to ka credit card. The validation gateway converts the validation request message to a card request message, which is sent to the financial processor 132. When the financial processor 132 has determined whether to authorize the transaction, the financial processor 132 sends a reply message from card to validation gate 130. The validation gate 130 performs a similar function of converting the card reply message to a validation reply message. The validation gateway then sends the validation reply message to the manual operator console 122A. The present invention is not limited to providing a protocol conversion for an authorization of a request to bill a customer's credit card. Thus, the term card request message should be understood as referring to any message sent by a validation gateway 130 to a packet-switched network. Likewise, the term "card reply message" should be understood as referring to any reply message received by a validation gateway from a packet-switched network. In the following figures the message flow will be described in more detail. between the manual operator console 122A and the validation access door 130. The financial processor 132 is a computer system that includes a database that stores information from credit card accounts for credit card accounts. Merchants and companies that accept credit cards buy the services of a company that has the ability to access financial processors, such as the exemplary financial processor. The company or bank maintains information about the credit cards and guarantees that a merchant will be paid for an authorized transaction, the merchant receives an authorization response code that can be used to ensure that the merchant receives the payment for the authorized transaction. . When the financial processor 132 receives a card request message from the validation gate 130, it either authorizes or rejects the transaction, and responds with a card reply message to the validation gate 130, including a Authorization response code that authorizes the charges, or that explains why the authorization was rejected. In the following figures the flow and format of the card request message and the card reply message, sent between the validation gate 130 and the financial processor 132 will be described in more detail. After the operator console manual 122A has finished the call processing, it releases the call back to the bridging switch 112, by means of ACD 114. The bridging switch 112 connects the call to the receiver 136 by means of a second local exchange network 134. Like a first local exchange network 106, a second local exchange network 134 comprises switches and terminating equipment within a localized area. The example that is used to illustrate a first local exchange network 106, a network of the local Bell operating company, such as Bell Atlantic, also applies to a second local exchange network 134. __ As previously mentioned, a typical call is it can be processed manually by a human operator, using a manual operator console 122A, or automatically by means of a switching control point of service 138. The processing of an automated call is similar to that of a call manually processed by a human operator , in the sense that both calls originate in a telephone 104, access a first local exchange network 106, and access an internal exchange network switch 108, or bridging switch 112 in an internal exchange network 110. However , the automated debit calls are not routed to a manual operator console 122A by means of an ACD 114, an ISNAP 116, a WAN 118 of the center of the network of the op server and a LAN 120 from the center of the operator's network. The automated debit calls are routed from the bridging switch 112 directly to a service switching control point 138. The service switching control point 138 comprises automated switching and response capability. The service switching control point 138 receives a call from a bridging switch in much the same way as the ACD 114. However, unlike the ACD 114, the call need not be routed to a manual operator console 122A . The switching control point of service 138 has automated response capability that can ask the caller for the necessary information, with much in the same way as a human operator of the manual operator console. The switching control point of the service 138 receives the information of the caller, and has the ability to process the call using the information. The service switching control point 138 can be implemented using a platform based on Ericsson AXE-10 switching with an automated response unit (ARU) improvement. Like the manual operator console 122A, the service switching control point 138 requires debit customer account information to process the debit call. Like the manual operator console 122A, the service switching control point 138 obtains this information from the service data point 128. If the service data point 128 indicates that additional funds are needed in a debit account, the switching control point of service 138 will ask the caller to determine if the caller would like to add funds to the debit account. If the caller would like to add funds to the debit account, the switching control point of the service 138 accesses the financial processor 132 to validate the credit card by means of the advanced intelligent network 124 and the validation access gate 130 Because the advanced intelligent network 124 performs the protocol conversion between TCP / IP and UDP / IP, the validation gateway 130 performs the protocol conversion between UDP / IP and X.25. Like a call processed by a manual operator console 122A, VALID_APP performs the protocol conversion between UDP / IP and X.25 by means of constructing a card request message from a validation request message, and constructing a validation reply message from a card reply message: When the switching control point of service 138 processes the call, the switching control point of service 138 sends a validation request message to request authorization to bill a customer's credit card. The validation request message received by the validation gateway 130 is in the same format, and contains the same data fields as the messages received from the manual operator console 122A. Just like the call that is processed manually by a human operator, using a manual operator console 122A, when the validation of the credit card is complete, and funds are added to the client's debit account, the call is released back to the bridging switch 112, and is terminated by means of a second local exchange network 134 to a telephone 136. The validation gateway 130 of the present invention is preferably implemented using a computer system 202, as shown in FIG. the form of the block diagram in Figure 2. The computer system 202 includes one or more processors, such as the processor 206, connected to the busbar 204. Also connected to the busbar 204 is the memory 208 (preferably memory direct access, RAM), and secondary storage devices 210. Secondary storage devices 210 include, for example, a hard disk drive 212 and a removable storage medium unit 214 (such as a disk drive, for example). The VALID_APP is preferably a computer program that resides in main memory 208, while it is running. When it is running, this computer program enables the computer system 202 to perform the features of the present invention as described herein. In this way, the VALID_APP represents a controller of the computer system 202 (and of the processor 206). Alternatively, the VALID_APP is predominantly or entirely a hardware device, such as a hardware state machine. In a modality, the present invention is a computer program product (such as the removable storage medium 216, which represents a computer storage disk, compact disk, etc.) comprising a computer readable medium, which has the control logic recorded in the same. The control logic, when loaded into the main memory 208, and executed by the processor 206, enables the processor 206 to perform the operations described herein. Figure 3 illustrates the message flow 302 of the manual operator console 122A - financial operator 132. "Messages sent between the manual operator console 122A and the financial processor 132 are transmitted by means of the validation access gate 130. VALID_APP, which is the validation computer program in the validation gateway 130, performs message transfer and protocol conversion necessary for a message to flow between the manual operator console 122A and a financial processor 132. Prior to describing the message flow 302 of the manual operator console 122A - financial processor 132, an overview of the message flow between the manual operator console 122A and the financial processor 132 is provided, which highlights the functions of the multiple software modules of the computer program VALID_APP. The message flow 302 of the manual operator console 122A-financial processor 132 comprises a a two-part transaction including: (1) 'an authorization request sent from the manual operator console 122A to the financial processor 132, and (2) a reply, with an authorization or a rejection, from the financial processor 132 to the manual operator console 122A. The multiple software modules included in the computer program VALID_APP are interconnected with the manual operator console 122A, perform protocol conversion between UDP / IP using the manual operator console 122A and the X.25 protocol used by the financial processor, and interconnect with the X.25 network that the financial processor 132 uses. VALID_APP includes a client reception module referred to as the user's data protocol / protocol protocol reception module.

(UDP_RECV), and a referral module to the client referred to as the user's internet protocol / datagram protocol module (UDP_SEND) that interconnects with the manual operator console 122A. A client reception module is a validation computer program module that receives requests from clients, such as the caller's interaction processors. A client submission module is a validation computer program module that sends replies to clients. The module UDP_RECV accepts the requests for the authorization of charges to credit cards of the manual operator consoles 122. The module UDP_SEND sends the responses, including the authorization or the rejection of the charge to the credit card, received from the financial processor 132, to manual operator consoles 122. Both UDP_RECV and UDP_SEND are individual interface points for all manual operator consoles 122, and for the switching control point of service 138. VALID_APP also includes a validation module referred to. as a validation process module (VALID_PROCESS "VALID_PROCESS"). A validation module is a validation computer program module that performs the necessary protocol conversion for the transfer of messages between clients and processors. The module VALID_PROCESS performs the necessary protocol conversion for the communication between the manual operator console 122A and the financial processor 132. When the module UDP_RECV receives a validation request message, requesting the authorization of charges to credit cards from the console of manual operator 122A, VALID_PROCESS constructs a card request message to be sent to the financial processor 132. When the financial processor 132 sends a card reply message either authorizing or rejecting the charges associated with a particular transaction, VALID_PROCESS constructs a response message Validation to send via the module UDP_SEND to the manual operator console 122A. An additional module inside the computer program VALID_APP is a communications module referred to as an X.25 communications process module.

(X.25 COMM_PROCESS). A communications module is a validation computer program module that interconnects with a packet-switched network, such as the X.25 network.

A communications module is not limited to interconnection with an X.25 network, but can be interconnected with a processor through any packet-switched network. The X.25 module COMM_PROCESS interacts with the financial processor 132. The X.25 module COMM_PROCESS sends card request messages to the financial processor. In addition, the X.25 module C0MM_PR0CESS forks a child process that accepts the card reply messages, with an authorization or rejection, from the financial processor 132. When a module forks another module, the initial module, which is also made reference as a mother module, temporarily creates the second module, which is also referred to as a child module. The second module is typically created temporarily to handle a particular transaction, and then it exits, in such a way that a module remains, the mother module. In step 306, the manual operator obtains a validation request to bill the customer's credit card account. The caller on a telephone 104 is received by a manual operator console 122A as described above. A human operator operates the manual operator console 122A. The human operator gathers the customer's transaction data. The transaction data is any data that the operator needs to complete the transaction. The transaction data to make a customer request to charge to a credit card include a customer credit card number, the type of credit card, that is, Visa, MasterCard, American Express, and expiration date. Transaction data can also include the customer's address or zip code for verification. In addition, the client provides an amount for authorization that is the amount to be invoiced to the customer's credit card, "and is included in the transaction data." The human operator enters the transaction data obtained from the customer in the manual operator console 122 A. In step 308, the manual operator console 122A sends a validation request message to the validation access door 130. The manual operator console 122A fills the fields in a validation request message, which is also interchangeably referred to herein as a request information message, with the transaction data obtained by the client. The format for the validation request message is referred to as the request information message format, and is shown in Table 1 below.The validation request message includes fields, which are referred to as request fields Validation, which are filled with the transaction data to identify the call, the customer, and the merchant. The request information message format includes a field referenced as achMerchantID that is 16 characters. The achMerchantID field is populated with a merchant identifier and a customer's credit card account identifier. A merchant identifier identifies the merchant that is providing the services for which the customer is paying to use their credit card. The customer credit card account identifier, which is interchangeably referred to herein as a customer credit card account number, is typically an 11-15 digit long number, which identifies a card account customer's credit In addition, the request information message format includes a 2-character achCardType field, which is populated with the type of credit card the client is using, a 4-character achExpDate field, which is populated with the expiration date of the client's credit card, and an achZipCode field of 9 characters, which is filled with the client's zip code. The request information message also includes a quantity field for authorization entitled achAuthAmtLong which is 9 characters, and is filled with the amount authorized by the customer. The additional transaction data included in the request validation fields of the validation request message is used to identify and route the call. An example is the telephone number from which the customer called, which is referred to as the call from the number. The call from the number is filled in the 16-character achCallFromNumber field. Another example of transaction data is the number the customer is calling, which is also referred to as the number call, which is filled in the 16-character achCallToNumber field. The additional transaction data is filled in the validation request fields of the validation request message, as shown in Table 1 below.

TABLE 1 In step 310, the validation gateway 130 convethe validation request message from a client server protocol to X.25. In this case, the client server protocol used by the manual operator console is UDP / IP. The conversion of the protocol is performed by means of multiple software modules of the computer program VALID_APP in the validation gateway 130. The validation request message is received by means of the module UDP_RECV of the computer program VALID_APP. The UDP / RECV module sends the validation request message to the VALID_PROCESS module, which performs the conversion from UDP / IP to X.25. The protocol is converted by means of VALID_PROCESS which constructs the card request message to be sent to the financial processor 132. Figure 4 shows additional details of the protocol conversion and the function of the software modules of the computer program VALID_APP. In step 312, the validation gateway 130 sends the card request message of the validation gateway to the financial processor 132, for authorization to charge to the client's credit card account. The X.25 module COMM_PROCESS sends card request messages to the financial processor 132. In addition, the X.25 module COMM_PROCESS forks a child process, which accepts card reply messages, with authorization data that is an authorization or rejection , from the financial processor 132. Although the X.25 module COMM_PROCESS is the main module used to send card request messages, the process of sending the message from the communications module involves many modules that branch off from the module X.25 COMM_PROCESS. The process of sending card request messages varies depending on whether the card request message is sent over a permanent virtual circuit or a switched virtual circuit. A permanent virtual circuit is initialized after system startup, and a permanent link remains between the validation access gate 130 and an X.25 node (not shown) in the X.25 network, which interconnects the gate access gateway. validation 130 to financial processor 132. A permanent virtual circuit remains a permanent link until the system is turned off. A switched virtual circuit is initialized when a card request message is initiated, and is terminated after transmission of the validation response message, which terminates the particular validation transaction. If a permanent virtual circuit is used to transmit a card request message, the X.25 module COMM_PROCESS sends the card request message via the permanent virtual circuit in the X.25 network to the financial processor 132. If a virtual circuit switched to transmit a card request message, the X.25 COMM_PROCESS forks a service module out of X.25. The X.25 service module requests an X.25 link from the X.25 network, which can provide interconnection with the financial processor 132. The X.25 COMM_PROCESS sends the card request message to the service module outside X. 25 The X.25 service module sends the card request message to the financial processor 132, by means of the switched virtual circuit that is provided in the X.25 network. In step 314, the financial processor 132 sends a card reply message to the validation gate 130. The validation gate 130 receives the card reply message in the communications module of the computer program VALID_APP in the validation access door 130. If a permanent virtual circuit was used to transmit the card request message, the card reply message is received in the same permanent virtual circuit. The card reply message is received via X.25 C0MM_PR0CESS. The X.25 COMM_PROCESS sends the card reply message to VALID_PROCESS. If a switched virtual circuit was used to transmit a card request message, the card reply message is received in the same permanent virtual circuit. The card reply message is received through the service module outside X.25. The X.25 service module sends, the card reply message to VALID_PROCESS. The service module outside X.25 also sends a received response message to the X.25 COMM_PROCESS. The X.25 service module is used only for a particular validation transaction. In step 316, the validation gateway 130 converts the X.25 protocol card reply message to the client server protocol. VALID_APP receives the card reply message from the financial processor, in the communications module. The communications module sends the card reply message to the VALID_PROCESS module, to perform the protocol conversion. VALID_PROCESS constructs a validation response message and sends the validation response message to UDP_SEND. In Figure 5 more details of the protocol conversion and the function of the software modules of the computer program VALID_APP are illustrated. In step 318, the validation gate 130 sends a validation response message to the manual operator console 122A. The validation response message includes an authorization response code, which uses the manual operator console 122A to determine if the customer is authorized to pay for the requested amount, using the credit card. The operator enters the information into the manual operator console 122A to send a message to the service data point 128 to update the customer's account to the new amount that the customer can use for previously paid calls. Figure 4 illustrates in more detail the conversion of a client server protocol to an X.25 protocol 310. In the preferred embodiment of the present invention, the protocol conversion that is performed is between UDP / IP and X.25. In the preferred embodiment of the present invention, the validation access gate 130 is interconnected with either a manual operator console 122A, or the advanced intelligent network 124 that communicates with the service switching control point 138. manual operator console 122A as the advanced intelligent network 124 communicate with the validation access gate 130, using UDP / IP. Although the service switching control point 138 uses TCP / IP, the advanced intelligent network 124 performs a protocol conversion between TCP / IP and UDP / IP. Therefore, the validation gateway 130 communicates with both types of calling interaction processors, the manual operator consoles 122 and the switching control point of the service 138, using UDP / IP. As a result, the client server protocol, in the preferred embodiment of the present invention, is UDP / IP regardless of whether the calling interaction processor is a manual operator console 122A or the service switching control point 138. In addition, the protocol conversion is performed as described with respect to Figure 4, regardless of whether the call is received from the manual operator console 122A or the service switching control point 138. In step 406, the The validation request message is received by the client reception module of the computer program VALID_APP. The client receiving module is the module inside the VALID_APP that receives the validation messages from the calling interaction processors, such as the manual operator consoles 122 of the service switching control point 138. The module is referred to as reception of the client as UDP_RECV when it is specialized to receive messages from the client server networks using the UDP / IP protocol, as in this case. The UDP_RECV module is an individual interface point for all the interaction processors that call, including the manual operator consoles 122 and the service switching control point 138. The UDP_RECV module receives validation request messages from both types of interaction processors that call, the manual operator consoles 122 and the control point of the operator. service switching 138.

In step 408, the validation request is sent to the validation module, which is also referred to as VALID_PROCESS of the VALID_APP. VALID_PROCESS receives the validation request message in the request information format described in Table 1, from the client reception module. VALID_PROCESS creates a card request message, using data in the validation request message. The card request message is in a format that can be understood by the financial processor 132. In step 410, VALID_PROCESS retrieves the transaction data from the validation request fields of the validation request message. The transaction data includes the merchant identifier and the account identifier of the customer's credit card, retrieved from the ach merchant ID field, the type of credit card the customer is using, retrieved from the achCardType field, the expiration date of the credit card of the customer that is retrieved from the achExpDate field, the zip code of the customer retrieved from the achZipCode field, and the amount that the customer authorizes to be billed to the credit card, retrieved from the achAuthAmt field. The transaction data also includes the number that the client called, which is retrieved from the achCallToNumber field, and the number from which the client called is retrieved from the achCallFromNumber field. The additional transaction data is retrieved as shown in Table 1 above. In step 412, VALID_PROCESS stores the transaction data in a local pending message list. A pending list of local messages is a series of addresses associated with memory, for temporary use, to store data. VALID_PROCESS stores the transaction data in the local message pending list while creating the card request message in the format that can be sent to the financial processor 132. In step 414, VALID_PROCESS constructs a card request message. Because the validation request message can not be understood by the financial processor 132, the VALID_PROCESS constructs a card request message that can be understood by the financial processor 132. The card request message includes the 2-character achCardType fields, which is filled with the credit card type, the 16-character achMerchantID field, which is populated with the merchant's identifier and the customer's credit card account identifier, and the 4-character achExpDate field, which is filled with the Expiration date of the customer's credit card. The card request message also includes the 16-character achCallToNumber field, which is filled with the called number, and the 16-character achCallFromNumber field, which is filled with the number from which it was called. As shown in the following Table 2, additional fields are included in the card request message. TABLE 2: CARD REQUEST achCallFromNumber (16) fraudulent calls In step 416, VALID_PROCESS sends the card request message to a communications module referenced as X.25 COMM_PROCESS of the VALID_APP. The X.25 COMM_PROCESS sends card request messages to the financial processor 132. The X.25 COMM_PROCESS is an individual interface point for sending card request messages from the validation gateway 130 to the financial processor 132. The X. 25 COMM_PROCESS sends the card request messages as described in step 312 of Figure 3. Figure 5 illustrates the conversion of the X.25 protocol to a client server protocol. In step 506, the validation access door 130 receives a card reply message from the financial processor, in the X.25 module C0MM_PR0CESS of VALID_APP. In step 314 of Figure 3 the process for receiving a card reply message is described. In step 508, the X.25 module C0MM_PR0CESS sends the card reply message to VALID_PROCESS.

VALID_PROCESS converts the message from a card reply message to a validation response message. In addition, as for sending a message from the manual operator console 122A to the financial processor 132, when a message is sent from the financial processor 132 to the manual operator console 122A, VALID_PROCESS converts the X.25 message to the protocol server, UDP / IP. In Table 3, below, the format for the card reply message is provided.

TABLE 3 - CARD ANSWER In step 510, VALID_PROCESS retrieves the authorization data from the card reply message. The authorization data is either an authorization code or a reason code for rejection, which corresponds to a reason for the rejection. If the authorization is approved, an authorization code is retrieved from the achAuthCode_Rej ectReason field, which is 6 characters. If the authorization was rejected, a rejection reason code corresponding to the reason for the rejection is retrieved from the achAuthCode_Rej ectReason field, which is a field of 6 characters. The additional authorization data includes the authorization source code that is contained in the byAuthSrcCode field. In step 512, VALID_PROCESS maps the response data retrieved from the card reply message to an authorization response code. The manual operator console 122A can not process the authorization code and the reason code for rejection. The financial processor 132 has the capability to provide many authorization codes and response codes that are useful in many different applications. However, the manual operator console 122A needs less specificity in the reason for authorization or rejection to process the call. VALID_PROCESS has a list of response codes that can be understood by the manual operator console 122A or the switching control point of service 138. VALID_PROCESS maps either the authorization code or the reason code for rejection to an authorization response code . An authorization response code can be understood by the manual operator console 122A or the switching control point of the service 138, and provides information indicating whether the transaction was authorized, and if not, the reason for the rejection. In step 514, VALID_PROCESS retrieves the transaction data from the local message pending list. VALID_PROCESS stored the transaction data in the pending list of local messages during processing of the validation request message sent from the manual operator console 122A. In step 516, VALID_PROCESS constructs a validation response message using the transaction data retrieved from the pending local message list and the response code. In step 412 of Figure 4, VALID_PROCESS stores the transaction data in a local pending message list. VALID_PROCESS now retrieves the transaction data from the local message pending list. VALID_PROCESS constructs a validation response message using the retrieved transaction data and the authorization code obtained in step 514. In step 518, VALID_PROCESS sends the validation response message to the dispatch module to the client. The sending module to the client is capable of sending messages to the client's server networks, such as the operator's service network. In this case, the send module to the client is referred to as the UDP_SEND module, because the client's server protocol is UDP / IP. The UDP_SEND module is an individual interface point to send validation response messages to the calling interaction processors. The UDP_SEND module sends validation response messages to both the manual operator consoles 122 and the service switching control point 138. Figure 6 illustrates the message flow 602 of the service switching control point 138 - financial processor 132 The service switching control point 132 sends a message to the financial processor 132, by means of the advanced intelligent network 124 and the validation access gate 130. The advanced intelligent network 124 provides the translation between TCP / IP using the control point of "service switching 138 and UDP / IP used by the consoles. Handbook 122. The advanced intelligent network conversion process 124 is described in more detail in the United States Patent Application with Attorney Number CDR-96-009 (1575.2240000), entitled "Advanced Intelligent Network Gateway". ", incorporated as reference above, the validation gateway 130 translates between UDP / IP of the user using the manual operator consoles 122 and the X.25 protocol used by the financial processor, in step 606, the control point The service switch 138 obtains a request from the client, referred to as a validation request, to bill the client's credit card account. it is received by a service switching control point 138 as described above. The client enters the transaction data using the keypad of the telephone 104. The switching control point of the service 138 gathers the transaction data of the client. The transaction data includes a credit card number of the customer, type of credit card, ie Visa, MasterCard / American Express, and expiration date. Transaction data can also include the customer's address or zip code for verification. In addition, the customer provides an amount for authorization that is the amount that is going to be billed to the customer's credit card, and is included in the transaction data. In step 608, the service switching control point 138 sends a validation request message to the validation access gate 130. The service switching control point 138 sends the validation request message to the gate validation access 130, after consulting the service data point 128. In order to allow a client to establish a previously paid call, the switching control point of the service 138 queries the service data point 128 to determine whether The customer has sufficient funds in his previously paid card account to establish the call. If the client has insufficient funds, the switching control point of service 138 gives the client the option of adding funds using a credit card. If the customer selects to add funds to his previously paid card account using a credit card, the switching control point of the service 138 gathers the transaction data and sends the validation request message. The service switching control point 138 sends the validation request message to the advanced intelligent network 124 for the conversion of the TCP / IP protocol to the UDP / IP protocol. After converting the validation request message from the TCP / IP protocol to the UDP / IP protocol, the advanced intelligent network 124 sends the validation request message to the validation gateway 130. The validation request message that was sent from the AIN 124 to the validation gate 130 is in the same format and contains the same information as the validation request message that was sent from the manual operator console 122A to the validation gate 130 described in Figure 3. As with the validation request message that was sent from the manual operator console 122A, the validation request message that was sent from the advanced intelligent network 124 contains the transaction data that was obtained from the client. Like the validation request message that was sent from the manual operator console 122A, the validation request message that was sent from the advanced intelligent network 124 includes an achMerchantID field of 16 characters, which is populated with a merchant identifier and a credit card account identifier of the customer, referred to herein interchangeably, as a customer credit card account number. The merchant identifier identifies the merchant who is providing the services the customer is paying to use their credit card account. The customer's credit card account number identifies the account of a customer's credit card. Also, like the validation request message that was sent from the manual operator console 122A, the validation request message that was sent from the advanced intelligent network 124 includes a 2 character achCardType field which is populated with the type of credit card that the customer is using, an achExpDate field, which is populated with the expiration date of the customer's credit card, and a 9-character achZipCode field which is populated with the client's postal code. In addition, like the validation request message that was sent from the manual operator console 122A, the validation request message that was sent from the advanced intelligent network 124 includes an authorization quantity field, the achAuthAmtLong, which It has 9 characters and is populated with the amount authorized by the client. Like the validation request message that was sent from the manual operator console 122A, the validation request message that was sent from the advanced intelligent network 124 also contains the additional transaction data that was used in the processing of the call. In the preferred embodiment of the present invention, the transaction data that is used for the processing of the call in the validation request message that was sent from SSCP 138, are the same as the transaction data that was used for the processing of the call that is sent in the validation request message from the manual operator console 122A. Both the call of the number and the call to the number are populated in the validation request message from the advanced intelligent network 124. The call from the number is populated in the achCallFromNumber field of 16 characters. The call to the number is populated in the 16-character achCallToNumber field. The additional transaction data is populated in the validation request message as shown above in Table 1. In step 610, the validation gateway 130 converts the validation message from a client server protocol into a protocol X.25. Similar to the processing of validation request messages that are sent from the manual operator console 122A, the VALID_APP performs the protocol conversion. The process for converting the protocol is the same for the messages that are sent from the manual operator console 122A and the SSCP 138. In the figure 4, the process to convert from a client server protocol to an X protocol is described. .25. In step 612, the validation gateway 130 sends a card request message to the financial processor 132 for authorization to charge to the client's credit card account. Similar to processing a request sent by the manual operator console 122A, the financial processor 132 authorizes or rejects the transaction using the account information that is stored in a database. As with the processing of a request that originated from the manual operator console 122A, a card request message may be sent which is the result of an application of the SSCP 138 to the financial processor 132 on a permanent virtual circuit or a circuit virtual switched over the X.25 network. The process for sending a card request message from the validation gate 130 is the same whether the request originates from the manual operator console 122A, or from an SSCP 138. In step 312 of Figure 3 both the process for sending a card request message from the validation gateway 130 to the financial processor 132 over a permanent virtual circuit, as well as the processor for send a card request message on a switched virtual circuit. In step 614, the financial processor 132 sends a card response message to the validation access door 130. Like the processing of a request originating from a manual operator console HA. The validation gate 130 receives the card response message in the communication module of the VALID_APP. Like the processing of a request from the manual operator console 122A, the child X0MM_PR0CESS_ X.25 receives the card request message if a permanent virtual circuit was used and through an external X.25 service module if a user was used. virtual circuit switched. The process for receiving the card response messages is the same regardless of the type of the originating or terminating interaction processor. In step 314 of Figure 3 the process for receiving a card response message is described in more detail. In step 616, the validation gateway 130 converts the card response message of the X.25 protocol to the protocol of the client server. Like the processing of requests that originate from and terminate at a manual operator console 122A, the VALID_APP performs a protocol conversion of the X.25 protocol to the client server protocol for responses originating from, and which terminate in SSCP 138. Also, like the processing of requests originating from and terminating in a manual operator console 122A, the client server protocol is UDP / IP because the advanced intelligent network 124 is convert from TCP / IC using SSCP 138, to UDP / IP. Figure 5 shows additional details of the protocol conversion. In step 618, the validation gateway 30 sends a validation response message to the SSCP 138. Like a validation response message that is sent to a manual operator console 122A, the validation response message to the SSCP 138 includes an authorization response code that uses SSCP 138 to determine if the customer is authorized to pay the amount that was requested using the credit card. If the customer is authorized to charge the amount that was requested, SSCP 138 sends the message to update the database in SDP 128 to reflect in the client's account the new amount that the customer can use for the call that was paid previously.

In step 620, the validation access door 130 writes a non-billable billing information record (BDR). The present invention allows the installation to be completed when the authorization of the credit card is complete. The installation refers to the completion of the processing that is needed to bill the customer. In the prior art systems, the installation was completed when the billing data record was combined with an OSR (operator service record) and processed by the billing systems. An operator service record contains the time of the call and other call information and is written by a switch after the completion of a call. A billing information record contains the information of the credit card and is written by a manual operator console 122A. Although the installation is completed when the credit card authorization is complete in the present invention, the billing data record and the operator's service record are written and sent to notify the billing systems that the installation is complete . When an SSCP 138 handles the call, the validation gateway 130 sends a request to the downstream systems to write a non-billable billing data record containing the credit card information. For the purpose of processing the calls of both the manual operator consoles 122, which do not have the non-billable billing data records written by the validation access door 130, and of the SSCP 138, which does have a data record of Non-billable billing written by the validation gateway 130, the validation gateway 130 must be able to determine what type of interaction processor the calling party sent the call. The validation gateway does not write a non-billable billing data record for calls processed by the manual operator console 122A, because the non-billable billing data record is written by the manual operator console 122A after it is receives the validation response message. The validation access door. 130 uses the chServiceldentifier field of the validation request message to determine whether the call was sent through a manual operator console 122A or an SSCP 138. If the chServiceldentifier field is populated with a 1, the call was sent from SSCP 138 and the validation gateway 130 writes a non-billable billing data record. If the chServiceldentifier field is populated with a 0, the call was sent from a manual operator console 122A and the validation access gate 130 does not write a non-billable billing data record. After the validation gateway 130 receives the validation request message, the validation gateway 130 stores the information that was received in the validation request message, which includes the 0 or 1 that was populated in the chServiceldentifier field, in a local pending message list. In step 412 of Figure 4 is described the storage of the information in the pending local message list, which applies to the processing of a call from both the manual operator console 122A, and the SSCP 138. When the access door of validation 130 receives a card response message from the financial processor 132, the validation access gate 130 retrieves the transaction data, including the 0 or 1 that was populated in the chServiceldentifier field, from the pending list of messages local. The validation access gate 130 determines whether a non-billable billing data record should be written, based on whether the chServiceldentifier field was populated with a 0 or a 1. If the chServiceidentifier field was populated with a 1, after the validation gateway 130 sends a validation response message to the SSCP 138, the validation gateway 130 writes a non-billable billing data record. A keyword is used in a validation configuration file to begin the process for writing the non-billable billing data records. The writing of a non-billable billing data record via the validation gateway 130 includes that the validation gateway 130 sends a billing data registration write request to the database server 140 of the registration register. billing information and that a billing data record write response is received from the database server of the billing data record. Figure 7 describes in more detail the process for writing non-billable billing data records. In step 622, the validation gateway 130 sends the request to write the billing data record to the database server 140 of the billing data record. The database server 140 of the billing data record contains a database that stores the non-billable billing data records. The non-billable billing data record is written to that database. A server configuration file of the network information distribution service (NIDS) database is used to determine in which server 140 of the billing data record to write the non-billable billing data record. Figure 7 illustrates the creation of a billing data record by a message flow 702 of the validation gateway 130. The validation gateway 130 writes a billing data record for a validation request that originates from an SSCP 138. As discussed in step 620 of Figure 6, the validation gateway ZL30 determines that the validation request originated from an SSCP 138 if the chServiceldentifier field is populated with a 1. In step 620 from Figure 6 further details of the process are provided to determine if the validation request message originated from an SSCP 138. In step 706, the validation gateway 130 writes a billing data record writing request. The billing data record writing request is sent by the VALID_PROCESS module of the computer program VALID_APP on the validation gateway 130. As mentioned, a billing data record contains the credit card information 'and it is used by billing systems to determine that the installation is complete. The request to write the billing data record is a request to the database server 140 of the billing data record. to write a non-billable billing data record. In step 708, the VALID_PROCESS module sends a billing data record writing request to the non-blocking application module (NBAPP). The credit card information that is needed to write the billing data record is sent in the invoice request to the billing data record. The VALID_PROCESS module branches the NBAPP module to act as an interface from the VALID_PROCESS module to a client process module (CLPROC). The NBAPP module is a validation computer program module that acts as a single interface point for all messages that are transferred between the VALID_PROCESS module and the CLPROC module. The NBAPP module ensures that messages that are sent between the VALID_PROCESS module and the CLPROC module do not block, by monitoring the message and providing synchronization. In step 710, the NBAPP sends the request of writing the billing data record to CLPROC. The database server 140 of the billing data record is part of the network information distribution service (NIDS). The NIDS is a computer system that is also part of an exchange network 110 and is used to perform different call processing functions for telecommunications services. The NIDS uses a protocol referred to as the protocol: Sequence Packet Protocol (NSPP) of the Network Information Distribution Service (NIDS). Because the billing data record server 140 requires that the billing data record write request be in a format compatible with the NSPP, the CLPROC module packages the write request for the billing data record for the NSPP, the CLPROC module is the validation computer program module that provides the NSPP interface which includes synchronizing, packaging the message, and waiting for a answer. The packaging of the message in a format that can be understood by the NSPP includes converting the message protocol, parsing the message, and converting the message headers. In step 712, the CLPROC module sends the request to write the billing data record to a billing data registration service. The billing data registration service is the computer program on the database server 140 of the billing data record, which collects the billing data records to send the systems downstream for billing. In this case, because the billing data record is for a credit card transaction, billing is not necessary. The installation that is needed to invoice the client is complete at the time of authorization of the charges to the credit card by the financial processor. As a result, the billing data record service creates a non-billable billing data record to show that the installation is complete. The billing data record is referred to as a non-billable billing data record, because there is no billing as a result of the billing data record. In step 714, the billing data recording service writes the non-billable billing data record. The non-billable billing data record is stored in a database on the server 140 of the billing data record. The non-billable billing data record is processed by billing systems similar to other billing data records, however, there is no billing as a result of processing a non-billable billing data record. The non-billable billing data record simply provides information indicating that the installation is complete. In step 716, the billing data recording service sends a write response from the billing data record to a demultiplexing process module (DEMUX_PROCESS). The DEMUX_PROCESS module acts as a single interface point for validation requests from different clients. The DEMUX_PROCESS module is the module of the validation computer program that manages the packets that are received from the billing data registration service on the database server 140 of the billing data record and ensures that the packages are identify on the basis of the client that sent the request. The DEMUX PROCESS module determines which validation request is associated with a particular package that was received from the billing data registration service. The DEMUX_PROCESS module sends the package to a linear list of responses corresponding to the client from which the request was received. The billing data record writing request is a replying message, indicating whether the non-billable billing data record was successfully written by the database server 140 of the billing data record. In step 718, the DEMUX_PROCESS module sends a write response from the billing data record to the CLPORC module. The CLPROC module acts as an interface to send the message to the NBAPP module. Again, the CLPROC module provides synchronization and packaging of the message. In step 720, the CLPROC module sends the write response of the billing data record to the NBAPP. The NBAPP acts again as an interface between the VALID_PROCESS and the CLPROC. In step 722, the NBAPP sends the write response of the billing data record to the VALID_PROCESS module. When the VALID_PROCESS module receives the write response from the billing data record, the writing of the non-billable billing data record is completed. Figure 8 illustrates the message flow to validate a request message that was received on a permanent virtual circuit X.25. The validation gate 130 receives a request from the X.25 network to validate a card issued by the telephone company. Examples of cards issued by the telephone company are calling cards, pre-paid cards, and international calling cards. Computer systems validate cards over the telecommunications network. Requests to validate these cards can come from a packet switched network, such as the X.25 network, and protocol conversion is needed to enable computer systems over the telecommunications network to process the request. Like the requests that are sent from the validation gateway 130 to the packet switching network, the requests that are sent from the packet switching network to the validation gateway 130 comprise a two-part transaction which includes: (1) a request that is sent from the packet switching network to a card database of the telephone company and (2) a replica, with an authorization or a rejection, from the card database from the telephone company to the packet switching network. The same software modules of the validation computer program are used from X.25 and the client server protocol used by the telephone company. Also, like the requests that are sent from the validation gateway 130, the present invention is not limited to providing a protocol conversion for an authorization of a request to use a card issued by a telephone company. The present invention can be used for the protocol conversion for any request that is sent from a packet switching network to a client server network. Therefore, it should be understood that the term message of. "telephone card request" refers to any request message that a packet-switching network sends to a validation gateway 130. Likewise, it should be understood that the term "telephone card request message" refers to any message of replication that is sent from a validation access gate 130 to a packet switching network. In step 806, the C0MM_PR0CESS X.25 receives a telephone card request message from the X.25 network. In step 808, the X.25 communication module sends the telephone card request message to the VALID_PROCESS module. The VALID_PR0CESS module performs the conversion of the X.25 protocol to the client server protocol that can be used to interface with the local database or the data application processor (DAP) to be queried. The process for converting the protocol is described with respect to Figure 4. In step 810, the VALID_PROCESS sends a query from the local database to a local database. The local database is a card database of the telephone company. A card database of the telephone company contains the customer account information that is used to validate a card issued by the telephone company. The information that is contained in a card database of the telephone company includes the customer's account information such as the customer's name, calling card number and the account balance. The consultation of the local database is an inquiry to determine whether to use the information in the local database if the card is valid and, in the case of pre-paid cards, if there are sufficient funds available in a customer account to process a call. The local database authorizes or rejects the customer's request to invoice using the card issued by the telephone company. In step 812, the local database sends a query response from the database to the VALID_PROCESS module. The query response from the local database indicates whether the customer is authorized to bill using the card issued by the telephone company. However, the local database is only one type of card database of the telephone company. The customer account information for the cards issued by the telephone company can also be maintained by a data application processor (DAP). If the query of the "local database is a database that is not found or data is found, you can store the customer account information in the DAP for that particular type of card. Local data contains a response, the module VALID_PROCESS immediately performs step 818. In step 814, if the query response of the local database is a database that is not found or data that is not found, the VALID_PROCESS sends a query from the data application processor (DAP) to the DAP Some cards that are issued by telephone companies, such as calling cards, are not validated using the local databases These cards are validated using a database A DAP The DAP contains customer account information similar to the local database, such as customer name, customer account number, and account balance, if the answer to the local database query is If a database is not found or data is not found, then the account information for the card can be maintained in the database in the DAP. Validation of the calling card is done by means of answering the DAP query.

In step 816, the DAP sends a query response from the DAP to the VALID_PROCESS. The DAP query response indicates whether the customer is authorized to bill using the card issued by the telephone company. In step 818, the VALID_PROCESS sends a telephone card response message to the C0MM_PR0CESS X.25 module. The VALID_PROCESS converts the client's server protocol message to an X.25 protocol that can be understood by the computer system that sent the phone card request message through the X.25 network. The process for converting the protocol is described in more detail with respect to Figure 5. In step 820, the COMM_PROCESS X.25 sends a telephone card response message to the X.25 network. Figure 9 illustrates the message flow to validate a request message that was received in an X.25 switch virtual circuit. A validation request can be received to validate a card issued by a telephone company either in a permanent virtual circuit or in a virtual switch circuit from the X.25 network. If the call is received on a virtual switch circuit, the process is slightly different than if it is received on a permanent virtual circuit. In step 906, a parent X.25 service in the module receives a telephone card request message from the X.25 network. A parent service in the module is a module that branches through the COMM_PROCESS X.25 module. However, unlike the other branching modules, the parent service in the module is not limited to a particular transaction. The COMM_PROCESS X.25 module forks the parent X.25 service in the module when the system is started and the parent X.25 service in the module is used until the system shuts down. In step 908, the parent X.25 service in the module forks a child X.25 service in the module. The parent X.25 service in the module sends the request message to the X.25 child service in the module for processing. In step 910, the child X.25 service in the module sends the telephone card request message to the VALID_PROCESS. Like the messages requesting the validation of the cards issued by the telephone companies, the requests that are transmitted to the validation gateway 130 on the switch virtual circuits require the conversion of the protocol. The VALID_PROCESS performs the X.25 conversion to the server protocol of the client using the local database or the DAP to be queried. The process for the conversion of the protocol is described in more detail with respect to the Figure In step 912, the VALID_PROCESS sends a local database query to a local database. As with the processing of requests received over permanent virtual circuits, requests received over virtual switch circuits need access to the appropriate database, where the customer's account information is stored with the objective of validating or denying the request. The client's account information, such as the customer's name, account number, and account balance, is stored in a local database for some cards issued by the telephone companies. The query of the local database is a query to determine, using the information in the local database, if the card is valid and, in the case of prepaid cards, if there are sufficient funds available in a bank account. client to process a call. The local database authorizes or rejects the client's request to invoice, using the card issued by the telephone company. In step 914, the local database sends a query response from the database to the VALID_PROCESS. The query response from the local database indicates whether the card issued by the telephone company is valid. In the same way as the processing of an application that was received on a permanent virtual circuit, the customer's account information can be stored on a DAP. If the customer's account information is stored in the DAP, the query response from the local database is a database that is not found or data that is not found. If the query of the local database contains a response, the module VALID_PROCESS then performs step 920. In step 916, if the query response of the local database is a database that is not found or data that can not be found, the VALID_PROCESS sends a DAP query to the DAP. Regardless of whether the card request message was received over a permanent virtual circuit or a switched-virtual circuit, if the customer's account information is stored in the DAP, a DAP query must be sent to the DAP for authorization. In step 918, the DAP sends a DAP query response to the VALID_PROCESS. The DAP query response indicates whether the customer is authorized to bill using the card issued by the telephone company. In step 920, the VALID_PROCESS sends a telephone card response message to the child X.25 service in the module. In the same way as processing other messages, the VALID_PROCESS provides the protocol conversion. In this step, the protocol conversion is from the client server protocol to the X.25 protocol. The process for converting the protocol is described in more detail with respect to Figure 5. In step 922, the child X.25 service in the module sends a telephone card response message to the X.25 network. The telephone card response message is sent over the virtual switch circuit that was used to send the request. The use of the switch virtual circuit terminates when the transaction is completed for a particular request. _ In step 924, the parent X.25 service in the module terminates the child X.25 service in the module. The X.25 child service is used to process only one particular transaction. When that transaction is completed, the X.25 parent service in the module terminates the X.25 child service in the module. The system and method of the present invention can be used in processing a validation request to pay for telecommunications services other than services that were previously paid for with a credit card. For example, customers could pay bills at the end of the month using credit cards by dialing a manual or automatic platform that accepts credit card information. As well as processing the requests to increase funds to a debit account, the validation gate 130 would receive the request from the telecommunications network and send the request to a financial processor 132 through an X.25 network. The processing of the request to be sent to a financial processor 132 is the same, regardless of the services for which it is being paid, if the validation requests are received from the advanced intelligent network 124. The system and method of The present invention is also not limited to providing an interface for transactions between exchange networks 110 and financial processors 132. The system and method of the present invention can be used whenever a communication between a client server network and a client network is needed. a network that is using the X.25 protocol. The validation gateway can perform message transfer and protocol conversion between any computer system requiring transfer and the client server to the conversion capabilities of the X.25 protocol. If the present invention is used to transfer messages carrying out functions other than credit card validation, the transaction data included in the validation request and the response messages and the credit card application and the messages of answer, it would be the transaction data that is needed for the particular transaction. For example, if the present invention is used to perform protocol conversion for messages that are sent from a remote automatic unit over a client server network to a database over an X.25 network to make a reservation in a flight of a particular airline if there is a seat available, the transaction data in a form of validation and response request messages and the card request and reply messages, would include a particular airline, the date, and the flight number. The modalities of the validation gateway can be interconnected with networks that use any type of client server protocol such as UDP / IP. In addition, the validation gateway is not limited to the interconnection with networks that use the X.25 protocol. The system and method of the present invention can provide message transfer and protocol conversion for any packet switched network protocol. In addition, the system and method of the present invention can be implemented using different formats for the validation request message, the telephone card request message, the telephone card replication message and the validation replication message. The validation request message does not need to be in the request information format. Any format that contains the information that is needed to process a credit card application can be used. Similarly, the telephone card request message and the telephone card replication messages need not be in the specified format, as long as the telephone card request message and the telephone card replication message contain the information necessary to obtain the replication authorization and can be understood by the processor to which access was obtained through a packet switched network. In addition, the validation replication message does not need to be in the request information format. Again, if the information that is needed to process a replica is included in the message, the format of the message with the present invention can be used. Another embodiment of the present invention does not require that a non-billable billing data record be written. Because the installation occurs in real time with the authorization, a billing data record does not need to process the customer's billing. In this manner, one embodiment of the present invention does not include a non-billable billing data record that is written by the manual operator console or by the validation gateway 130. In a further embodiment of the present invention, they are processed authorization requests automatically through the automatic operator consoles, rather than SSCP 138. Automatic operator consoles, also referred to as automatic response units, are used to process many automatic telecommunications services. The system and method of the present invention can be used with any caller interaction processor that can obtain the information that is needed from the client to process the call. The system and method of the present invention can also be used with a COMM_PROCESS X.25 that does not bifurcate a child process or service in the process. The COMM_PROCESS X.25 is a single interface point between the VALID_PROCESS and the X.25 network. Any module that can perform the interconnection functions between the VALID_PROCESS and the X.25 network or another packet switching network can be used. Although different embodiments of the present invention have been described above, it should be understood that these have been presented by way of example only, not as limitations. In this way, the extent and scope of the present invention should not be limited to any of the exemplary embodiments described above, but should be defined only in accordance with the following claims and their equivalents.

Glossary ACD: Automatic Call Distributor The ACD provides switching functionality between the selected manual operator console and the interconnection network. AIN: Intelligent Advanced Network The advanced intelligent network access gateway is a computer system that provides message transfer and protocol conversion that allow communication between manual operator consoles and the SDP.

BDR: Billing Data Record A record that is used to process customer invoices written by the caller's interaction processor or the validation gateway. The billing information record contains the credit card information for billing purposes. CLPROC: Client Process The CLPROC module of the computer program VALID_APP provides the interface and synchronization for message transfer between the validation gateway and the billing data log server. The CLPROC module also packages the message to the receiver, either the validation gateway or the billing data log server. DEMUX PROCESS: Process for demultiplexing The DEMUX_PROCESS module of the computer program VALID_APP receives the response packets for the multiple credit card authorization transactions from the billing data record server and sends the packets to the linear response list associated with the particular authorization transaction. LAN: Local Area Network The LAN assists in the distribution of calls between manual operator consoles and provides information to manual operator consoles in the processing of calls. SNAP: Intelligent Service Network Application Processor ISNAP selects a manual operator console and ensures that incoming calls are distributed among groups that were logically defined from manual operator consoles. NBAPP: Non-Blocking Application The NBAPP module of the VALID_APP computer program transmits non-blocking calls between the validation gateway and the billing data log server. NIDS: Network Information Distribution Service NIDS is a network that distributes information, such as a client-server network. NSPP: Sequential Package Protocol of the Network Information Distribution Service (NIDS) The NSPP is a session-oriented, guaranteed delivery, packet exchange protocol. The NSPP provides communications with client-server programs that use UDP / IP. OSR: Operator Service Record A record that is used in customer invoice processing that writes a switch and that contains the time of the call and other information related to the call. SDP: Service Data Point The SDP stores the customer account information that is used for traffic handling, service provisioning, and billing of debit calls. SSCP: Service Switching Control Point It comprises the capacity of the switching unit and automatic response. The service switching control point provides the automatic processing of debit calls by interacting directly with the calling party, who enters the information on the telephone keypad. TCAP: Transaction Capability Application Part The TCAP refers to a TCAP message that conforms to the industry standard ANSI SS7 ISUP and is used to transfer the information between the manual operator consoles and the SDP. TCP / IP: Transmission Control Protocol / Internet Protocol TCP / IP is the protocol used by the SDP. UDP / IP: User Datagram Protocol / Protocol Internet A client server protocol used by manual operator consoles. UDP_RECV: Datagram Protocol User / Internet Protocol Reception Module A module of the VALID_APP computer program that receives messages from the calling party's interaction processors over the client's server networks using the UDP / IP protocol. UDP_SEND: User Datagram Protocol / Internet Protocol Sending Module A computer program module VALID_APP that sends messages to the caller's interaction processors over the client's server networks using the UDP / IP protocol. VALID_APP: Validation Application Computer Program A computer program that processes validation requests from the calling party interaction processors (either manual operator consoles or SSCP). The validation application computer program converts the validation request message into a card request message that can be processed by the financial processor. The validation application computer program sends the card request message to the financial processor and receives a card replication message from the financial processor, which responds to the card request message. Then, the validation application computer program converts the card replication message into a validation response message and sends the response to the interaction processor of the calling party. The VALID_APP performs the protocol conversion between the UDP / IP and the X.25. VALID_ PROCESS Validation Processing Module: The VALID_PROCESS is a module of the VALID_APP computer program that constructs the card request messages using the validation request messages that were received from a calling party interaction processor. In addition, the VALID_PROCESS constructs the validation response messages using the card replication messages that were received from a financial processor. The VALID_PROCESS provides the protocol conversion between UDP / IP and X.25. WAN: Wide Area Network The WAN helps in the distribution of calls between manual operator consoles and provides the information to the manual operator consoles that will be used to process the calls. X.25 COMM_X.25 PROCESS Communications Processing Module: The first module of the VALID_APP computer program for sending card request messages to the financial processor. The X.25 COMM_PROCESS forks a child process that accepts card replication messages from the financial processor. The X.25 COMM_PROCESS child is terminated when the validation transaction completes.

Claims (22)

1. A method for billing a customer's credit card account, comprising the steps of: (a) receiving via a validation gateway a validation request message containing the transaction data from an interaction processor of the calling party; (b) converting the validation request message from a client server protocol to a packet switching network protocol; (c) sending a card request message from the validation gateway to a financial processor for authorization, to be charged to the client's credit card account: (d) receiving a message via the validation gateway of card replica from the financial processor; (e) converting the packet switching network protocol to the client server protocol; and (f) sending a validation response message from the validation gateway to the caller's interaction processor. The method according to claim 1, characterized in that it further comprises: (g) writing a billing data record via the validation gateway; and (h) sending the billing data record from the validation gateway to the database server of the network information distribution service. The method according to claim 1, wherein step (a) comprises: obtaining via the interaction processor of the calling party, the validation request for billing the client's credit card account; collect transaction data by an operator: enter the transaction data inside the interaction processor of the calling party; send through the caller's interaction processor, the validation request message to bill the client's credit card account; and receiving through the validation gateway, a validation request containing the transaction data; wherein the interaction processor of the calling party comprises a manual operator console. The method according to claim 1, wherein step (b) comprises: obtaining by means of a processor of interaction of the calling party, the request for validation to bill the account of the customer's credit card; collect transaction data using the caller's interaction processor; send through the caller's interaction processor, the validation request message to bill the client's credit card account; and receiving via the validation gateway, a validation request message containing the transaction data; wherein the interaction processor of the calling party comprises a service switching control point or an automatic response unit. The method according to claim 1, wherein step (a) comprises: populating by means of the interaction processor of the calling party, one or more validation request fields in the validation request message with the data Transactions that were obtained through the caller's interaction processor from a client or customer's credit card; and sending through the interaction processor of the calling party, the validation request message to the validation gateway. The method according to claim 1, wherein step (a) comprises: populating by the caller's motion processor a merchant identifier field in the validation request message with a merchant identifier associated with the service provider and a credit card account identifier of the customer that was obtained from a customer or a customer's credit card; populate through the caller's interaction processor an authorization quantity field in the validation request message with an authorization amount that was provided by the customer to be invoiced to the client's credit card account; populate by means of the interaction processor of the calling party one or more validation request fields in the validation request message with additional transaction data; and sending via the interaction processor of the calling party the validation request message to the validation gateway; wherein the validation request message is in a request information format. The method according to claim 1, wherein step (b) comprises: receiving via the validation gateway from the interaction processor of the calling party, the validation request message; retrieve the transaction data from the validation request message; store the transaction data in a pending list of local messages; and constructing a card request message using the transaction data that was received in the validation request message. The method according to claim 1, wherein step (b) comprises: receiving via a client reception module of the validation computer program on the validation access gate, from the interaction processor of the calling party, the validation request message; sending the validation request message from the client reception module, to a validation module of the one or more validation computer programs on the validation access door; recover the transaction data from the validation request message through the validation module; store the transaction data in a pending list of local messages using the validation module; "construct by means of the validation module the card request message from the transaction data in the validation request message, and send the card request message from the validation module, to a program communications module. computer validation on the validation access door 9. The method of compliance with the claim 1, wherein step (c) comprises: sending the card request message from a communications module of a validation computer program on the validation gateway to the financial processor. The method according to claim 1, wherein step (d) comprises: receiving via a communication module of a validation computer program on the validation gateway, a card replication message from the processor financial. The method according to claim 1, wherein step (e) comprises: receiving via the validation gateway from the financial processor, the card replication message; recover the replication data from the card replication message; assign the replication data to a response code; recover transaction data from a pending list of local messages; and constructing a validation response message using the transaction data from the pending list of local messages and the response code. The method according to claim 1, wherein step (e) comprises: receiving via a communications module of a validation computer program on the validation gateway, from the financial processor, the message of card replica; sending the card replication message from the communications module, to a validation module of the validation computer program, on the validation access door; recover the authorization data from the card replication message, by means of the validation module; assign the authorization data from the card replication message; retrieve transaction data from the pending list of local messages; construct through the validation module a validation response message, using the transaction data in the pending list of local messages and the response code; and sending the validation response message from the validation module, to a client sending module of the validation computer program on the validation gateway. 13. The method according to the claim 2, wherein step (h) comprises: sending through a validation module of a validation computer program on the validation access door, a request to write billing data record to a non-blocking application module; send through the application module of non-blocking the request to write billing data record, to a client processing module; send through the customer processing module a request to write billing data record to a billing information registration service; send through the billing data registration service a billing data record write response to a demultiplexing process module; send through the process module to demultiplex, a write response of billing data record to the client process; send through the customer's processing module a billing data record write response to the non-blocking application module; send through the non-blocking application module, a write-in response to billing data registration to the validation module. 14. A method for converting a message from a client server protocol to a protocol of the packet switching network, comprising the steps of: (a) receiving via the client receiving module of a validation computer program on the validation gateway, of a client of a client server network, a validation request message; (b) sending the validation request message from the client reception module of the validation computer program, to a validation module of the validation computer program on the validation gateway; (c) retrieving the transaction data from the validation request message, by means of the validation module; (d) storing the transaction data in a pending list of local messages by means of the validation module; (e) building through the validation module a compatible request message of the packet switching network, from the transaction data in the pending list of local messages; (f) sending the compatible request message of the packet switching network from the validation module, to a communications module of the validation computer programs on the validation gateway; and (g) sending the compatible request message of the packet switching network from the communication module of the validation computer programs on the validation gateway, to a packet switching network. The method according to claim 14, wherein step (g) comprises: sending the compatible request message of the packet switching network from the communications module of the validation computer programs over the access gate of validation, to a packet switching network by means of one or more permanent virtual circuits between the validation access gateway and the packet switching network. The method according to claim 14, characterized in that it further comprises: bifurcating an external X.25 service module through the communications module; sending the compatible request message from the packet switching network from the communication module to the external X.25 service module; and sending the compatible request message of the packet switching network to the packet switching network by means of one or more switched virtual circuits connecting the validation gateway and the network using the external X.25 service module. packet switching 17. A method for converting a message from a packet-switched network protocol into a client server protocol, comprising the steps of: (a) receiving via the communications module of a validation computer program, a message of replication from a packet switching network; (b) sending via the communication module the reply message to a validation module of the validation computer program; (c) retrieve the transaction data from the pending list of local messages; (d) construct through the validation module, a validation response message, which includes the response code; and (e) sending the validation response message from the validation module to a client sending module of the validation computer program. The method according to claim 17, wherein step (a) comprises: receiving the replication message via the communications module of the validation computer program, from the packet switching network by means of one or more permanent virtual circuits. The method according to claim 17, wherein step (d) comprises: recovering the transaction data and the replication data by means of the validation module from the replication message; selecting through the validation module a response code that corresponds to the replication data that was received in the replication message; and construct through the validation module, a validation response message that includes the response code. The method according to claim 17, characterized in that it also comprises the following steps that must be carried out before step (a): receiving through an external service module X.25 of the validation computer program, over the door of validation access, a replication message from the packet switching network; and sending the replica message, via the external X.25 service module, to the communications module of the validation computer program on the validation gateway. The method according to claim 17, characterized in that it also comprises the following steps that must be carried out before step (a): receiving through an external service module X.25 of the validation computer program, on the door of validation access, a replication message from the packet switching network by means of one or more switched virtual circuits; and _ sending the replication message via the external X.25 service module to the communication module of the validation computer program on the validation gateway. 2

2. A method for validating a request message received by a computer using a client server protocol from a computer program, using a packet-switched network protocol, comprising the steps of: (a) receiving via a communication module of a validation computer program, a request message from a packet switching network; (b) sending via the communications module the request message to a validation module of the validation computer program; (c) send through the validation module a query of the local database, to a local database; _ (d) receiving through the validation module a response to the local database query, from the local database; (e) if in step (d) it is determined that the response to the query of the local database is a database that was not found or data that was not found, send through the validation module, a query to the processor of data applications, to a processor of data applications; (f) if in step (e) the query was sent to the data application processor, receiving through the validation module, a query response to the data application processor from the data application processor, - (g) ) sending through the validation module, a reply message to the communications module; and (h) sending through the communications module, a reply message to the packet switching network. 24. A method for validating a request message received by a computer using a client server protocol from a computer program, using a packet-switched network protocol, comprising the steps of: (a) receiving via a parent X.25 service in the computer program module, a request message from a packet switching network; (b) branch using the parent X.25 service in the module, a child X.25 service in the module; (c) sending through the X.25 child service in the module, the request message to a validation module of the validation computer program; (d) sending through the validation module, a query of the local database to a local database; (e) receive through the validation module, a response to the query of the local database from the local database; (f) if in step (e) it was determined that the response to the query of the local database is a database that was not found or data that was not found, send through the validation module, a query to the processor of data applications, to a processor of data applications; (g) if in step (f) the query was sent to the data application processor, receive through the validation module, a response to the query of the data application processor from the data application processor; (h) sending through the validation module, a replication message to the child X.25 service in the module; (i) send through the child X.25 service in the module, the replication message to the packet switching network; and (j) terminate the child X.25 service in the module, using the parent X.25 service in the module. 24. A method for responding, by means of a processor to which access was gained through a packet switching network, to a request sent by a client over a client server network, comprising the steps of: receiving a request message from validation that contains the transaction data; converting the validation request message, from a client server protocol to a protocol of the packet switching network; sending a request message converted to the processor by means of the packet switching network; receive a reply message from the processor; converting the replication message, from a protocol of the packet switching network to a client server protocol; and send the validation response message to the client, over the client server network. 25. A network of the computer system, comprising: a service data point for storing the customer's debit account information; an access door of the advanced intelligent network that is coupled to the service data point; one or more center operator network computer systems that are coupled to the access gate of the advanced intelligent network; a validation gateway that couples to one or more of the center computer systems of the operator network that are coupled to a processor by means of a packet switching network; and one or more operator consoles that are coupled to one or more computer systems of the operator network. 26. A network of the computer system comprising: a service data point for storing the customer's debit account information; an advanced intelligent network access gate that is coupled to the service data point - one or more center computer systems of the operator network that are coupled to the gateway of the advanced intelligent network; a validation gateway that couples to one or more of the center computer systems of the operator network that are coupled to a processor by means of a packet switching network; and a service switching control point that is coupled to the service data point.