MXPA05013662A - Versatile terminal adapter and network for transaction processing - Google Patents

Abstract

A terminal adapter, along with a value added network, is disclosed that interworks a plurality of terminals with a processing host to accomplish transaction processing. The terminals can use different protocols and typically incorporate card readers for completing financial or other types of transactions typically involving credit, debit, ATM or similar cards. The terminal adapter provides reliable and secure communication using a network based in part on the Internet as a primary form of communication. The terminal adapter also provides a secondary communication path in the event of a failure of the primary communication path, as well as automatic recognition of different terminal protocols, various security functions, error detection, and other network administration functions to ensure a flexible system and efficient transaction processing system.

Description

VERSATILE TERMINAL ADAPTER AND NETWORK FOR TRANSACTION PROCESSING FIELD OF THE INVENTION The present invention relates generally to terminal adapters for terminals that originate financial transactions, including credit / debit card readers, ATMs, and point of sale terminals. Specifically, terminals using various access protocols interact with a value-added network oriented to a transaction using a versatile terminal adapter that facilitates the interaction of the terminal with a server processor, where the server is also connected to network. In one embodiment, the terminal adapter uses an extended communications network, such as the Internet, as a primary means of accessing the value-added network, and uses the dial-up telephone service as a secondary means of accessing the network. value added in the case of failure of primary media. A network operations center manages the transaction-oriented value-added network for optimal performance.

BACKGROUND OF THE INVENTION Real-time electronic transaction processing is common in many industries, including retail sales, inventory control and healthcare. Businesses use devices such as card readers, which include magnetically-read coded cards, to increase the productivity and accuracy of various types of transactions. A common application is the use of credit cards to purchase goods and services in retail sales. Many retailers have deployed automated card readers to facilitate the processing of credit and debit card authorization to store personnel. Not only do automated credit card readers provide greater accuracy than manually typing information at the time of acquisition, they offer greater speed, convenience, and accuracy. Nowadays, it is common for each point of sale (POS) terminal to have an integrated card reader or to have a terminal connected to a nearby card reader. Typically, a card reader communicates with a server financial transaction processor using a dedicated telephone line. The card reader incorporates a standard modem implemented by a unique, low-cost integrated circuit based on standard modems, such as V.22, V.22bis or V.34. The card reader dials a programmed telephone number (normally local or free of charge) and establishes a telephone connection through a network with the server processor. The card reader transmits the transaction information that includes the card number, a transaction number and the amount of the acquisition to a server. The server processor accepts or declines the transaction and responds by returning an authorization number. This type of transaction normally occurs quickly, since it is desirable to minimize the delay and increase customer satisfaction. Many businesses have a single point-of-sale terminal, and therefore, require a telephone line to handle card authorization. This usually occurs in addition to a voice telephone line, used by the business, because the telephone line is usually dedicated to the card reader. If the telephone line is shared with a telephone for voice communication, then the operation becomes inconvenient, frequently resulting in the delay of card authorizations or voice calls. For businesses that have multiple POS terminals, a plurality of telephone lines are dedicated to card readers, often on a shared basis. While phone lines are shared between card readers, some cost savings are allowed, this may result in delays for a particular card reader, depending on the volume of current card authorization and the number of telephone lines. For a growing business with an increasing volume of card transactions or an increase in the number of card readers, the constant monitoring and determination of when adding new telephone lines is difficult and a distracting factor of the core business functions of the retailer. However, the use of dedicated telephone lines usually provides a high degree of reliability and security. Many businesses now have access to the Internet to complement various business functions. Access to the Internet is often provided for various workers on personal computers who use an internal local area network (LAN) that provides portal access to an Internet Service Provider (ISP). The installation of physical communication between the LAN and the ISP can be of various types, including private digital line, fiber optic, ISDN, DSL, cable modem, wireless, satellite, etc. Typically, digital access provisions provide higher data communication speeds compared to dial-up connections. Using a LAN to access the Internet, multiple users are allowed to access the Internet at the same time. Although simultaneous use can slow response times, one user does not "block" access to another, as is the case when a single telephone line is shared by multiple users or devices. Additionally, the cost of accessing the Internet does not necessarily require additional fees for each simultaneous user who has access to the Internet. In contrast, simultaneous access via telephone lines requires a plurality of telephone lines, each of which has a discrete incremental cost.

If retailers could configure their card readers to use the Internet to access the server processor, dedicated telephone lines for card readers may not be required, thus reducing costs for retailers. However, the use of separate telephone lines provides the advantage of a reliable and redundant communication architecture. By replacing all telephone lines with a single access provision to the Internet, a single point of communication failure is provided by leaving all card readers at the retailer's location without functioning, if access to the Internet is not available. The potential for loss of earnings, even for a relatively short break, may more than justify the higher cost of using separate telephone lines. Consequently, it may be desirable to have the advantages of access to the Internet while retaining the reliability and security of a dial-up connection. The Patent of E.U.A. No. 5,526,409, describes the use of a second telephone line that can be used as a secondary communication means in the event that the main telephone line or the modem can not be operated. However, using a single telephone line as the primary communications facilities limit the communication speed to transmit data and limit the destination to a single server. The patent also does not describe the automatic switching to the second telephone line or the automatic switching back to the primary telephone line.

The Patent of E.U.A. No. 5,778,173, describes the use of the Internet through a personal computer to facilitate a financial transaction, such as an acquisition. However, the entire transaction is not made using the Internet; a portion of the sensitive information to transmit the transaction is sent using a modem over a dial-up telephone connection. This configuration still requires a dedicated telephone line for each terminal and increases costs. Accordingly, a system is needed to use existing card reader terminals to access a financial server processor using an economical, reliable and secure secure transaction processing network, while providing support communication to ensure reliable processing and a secure transaction processing.

BRIEF DESCRIPTION OF THE INVENTION Generally described, the present invention works with a terminal, which normally incorporates a magnetic card reader, with a server processor using a terminal adapter operating in conjunction with a network. The terminal adapter and the network provide various value-added services, including synchronization, error detection, security, support communication and authentication to achieve fast, reliable, low-cost and efficient transaction processing.

Various modalities are described for adapting existing terminals or terminals based on personal computers. In accordance with one aspect of the present invention, a terminal adapter operating in conjunction with a network is provided to work a terminal with a server, wherein the terminal adapter incorporates a processor to receive a first request message from transaction from the terminal and interacting the message with the network using a second transaction request message. The network transports the transaction to the server and interacts with the message for a protocol used by the server. The response from the server is transported back to the terminal in a similar way. The terminal adapter in coordination with the network provides services that include: synchronization, authentication, error detection, support communication capability, automatic recognition of various terminal protocols and server addresses, automatic determination of network addresses to obtain configuration parameters, and the ability to automatically download new software. In accordance with another aspect of the present invention, various embodiments of the terminal / terminal adapter are described, including a software version in which functions associated with the terminal adapter are achieved by loading the software into a computer, such as a terminal. based on a personal computer that has existing communication capability with a network.

In accordance with one aspect of the present invention, a network node is provided for interacting a terminal adapter with a server. The network node incorporates a processor to receive a transaction request message from the terminal adapter and ensure that the request is synchronized, encrypted and error-free and transmit the message to another network node and to a server processor. The response of the server is transported back in a similar way to the terminal. The network node in coordination with the terminal adapter provides services that include: tuning, authentication, error detection, encryption and downloading of addresses, parameters and software to the terminal adapter. According to another aspect of the present invention, a method for interacting transaction messages through a terminal adapter is described, wherein the messages originating from a terminal are made to interact with a network to be processed by a server. The method includes: receiving a first message from the terminal, determining the protocol and destination of the server and mapping the first message to the second message for a network interface. The method includes ensuring synchronization between the terminal adapter and the network, encrypting and decrypting messages, switching over a support communications path as required, authenticating the terminal adapter to the network, discovering service address information and parameters of new settings, and download the software as required.

According to another aspect of the present invention, a network operation center is described for maintaining the information associated with each terminal, including the status of the primary and secondary communications path, operating status, software version indicators, indicators of parameter file version and different address information related to the service. The network operations center may additionally initiate communications with a defined location, in a defined manner, based on a defined status condition. In accordance with another aspect of the present invention, a method of a terminal adapter that interacts with a transaction-oriented request received on a terminal interface connected to a terminal with a first communication path providing access to a network is described. , comprising the steps of: receiving a first transaction request message at the terminal interface of the terminal adapter from a terminal incorporating a card reader; recovering the previously defined information stored in the terminal adapter associated with a network destination for said terminal interface; drawing a map of the first transaction request message to a second transaction request message via the terminal adapter, wherein the second transaction request message is encrypted; determining whether a primary communication path on a first network interface is operational; and sending the second transaction request message over the primary communication path, if the primary communication path is operational or sending the second transaction request over a second communication path if the primary communication path is not operational. According to another aspect of the present invention, a computer-readable medium with instructions for execution is described by a processor on a computer that has a display and is operatively connected to a card reader, and execute the software for processing sales transactions comprising instructions for: receiving a first transaction message from a card reader; determine an address associated with a server processor; generating a second transaction-oriented message that incorporates information in part from the first transaction message, synchronization information and a computer identification number; encrypt the second transaction message; sending the second transaction message on a first communication path if the first communication path can be operated or on a second communication path if the first communication path can not be operated; receive a first response from the server processor; and generate an indication display based in part on the first response.

BRIEF DESCRIPTION OF THE DIVERSE VIEWS OF THE DRAWINGS Having thus described the present invention in general terms, reference will now be made to the accompanying drawings, which are not necessarily drawn to scale and in which: Figure 1 illustrates one embodiment of the system in which the adapter The versatile terminal operates in accordance with the principles of one embodiment of the present invention. Figure 2 is further elaborated in an embodiment of the present invention that involves the value-added network according to the principles of one embodiment of the present invention. Figure 3 illustrates the transfer procedures before the transaction for the terminal adapter according to the principles of one embodiment of the present invention. Figure 4 illustrates a simple transaction message exchange according to the principles of one embodiment of the present invention. Figure 5 illustrates an exchange of session transaction messages according to the principles of one embodiment of the present invention. Figure 6 illustrates the protocol architecture for a terminal adapter mode using the primary communication path according to the principles of one embodiment of the present invention. Figure 7 illustrates various hardware components associated with a terminal adapter mode according to the principles of one embodiment of the present invention. Figure 8 illustrates various software components associated with a terminal adapter embodiment according to the principles of the present invention. Figures 9A-9B illustrate various software systems related to the modes of functions according to the principles of one embodiment of the present invention. Figure 10 illustrates a flow chart for switching the primary to the secondary communications path (and vice versa) according to the principles of one embodiment of the present invention. Figure 11 illustrates the stack protocol for a modality of the terminal adapter that uses the secondary communication path according to the principles of one embodiment of the present invention. Figures 12A-12C illustrate the modalities of the terminal adapter that automatically selects a terminal protocol in accordance with the principles of one embodiment of the present invention. Figures 13A and 13B illustrate the procedures and parameters provided to the terminal adapter for performing software download and configuration management in accordance with the principles of one embodiment of the present invention. Figure 14 illustrates various aspects of operation of the terminal adapter according to the principles of one embodiment of the present invention.

DETAILED DESCRIPTION OF THE INVENTION The present invention will now be more fully described below with reference to the accompanying drawings, in which some, although not all embodiments of the invention are shown. Certainly, these inventions can be represented in many different forms and should not be construed as limited to the modality set forth in the present description, instead, these modalities are provided, such that this description will satisfy the legal requirements. Similar numbers refer to similar elements throughout the procedure. The present invention is directed, in part, to a versatile transaction terminal adapter ("terminal adapter") that interacts various types of terminals with a value-added network ("network") for the purpose of achieving transactions, which include financial transactions, which will be used primarily to illustrate the principles of the present invention. The terminal adapter is designed to use the services of the network, which in turn use a communication infrastructure, such as the Internet, to provide the goals of trust, security and efficiency in communications in an economical way. Alternatively, the network may use other communication infrastructures, such as virtual private networks, ATM networks, WANs, or similar technologies to achieve these goals. Additionally, although the fundamentals of the present invention are illustrated using certain types of modalities, communication infrastructures and categories of transaction types, it will be readily appreciated that other communication networks or devices could be incorporated into the principles of the present invention for a variety of transaction types.

System Overview A system perspective of one embodiment of the present invention is shown in Figure 1. In Figure 1, the terminals of system 1 are typically located on the premises of a business, such as a retail store, bank, merchant, etc., although it is not limited to commercial sales applications. A common example is a card reader 2 located in the retail store, which can be a credit card reader, debit card reader or any other type of magnetic card reader, optical card reader or card reader " intelligent". In Figure 1, the card reader 2 is illustrated as being directly connected to the terminal adapter. The connection between the card reader and the terminal adapter can use a variety of connection means and often incorporate a RJ-11 telephone-type connector based on a flat old telephone interface (POTS). Specifically, the card reader expects to interface with the public switched telephone network (PSTN), which emulates the terminal adapter. Figure 1 also illustrates a plurality of card readers 4, which may be of the same type as the previous card reader 2, although it is connected to a multiple card reader driver 6. Controller 6 adds a plurality of card readers. card and multiplexes its transactions within a single communications installation. In this illustration, the controller 6 is connected to the terminal adapter 14. The interface presented by the terminal adapter 14 to the card reader 2 may be the same interface presented by the terminal adapter 14 to the multiple card reader driver 6. These They are two of many provisions that can be used to connect a terminal to the terminal adapter. For example, one modality of the terminal adapter connects several identical card readers 2, one terminal to each interface of the terminal adapter 14. The terminal is not restricted to being a card reader, although it can be a more sophisticated device, such as an ATM (ATM) 8. This type of terminal performs financial transactions, although the nature of the transaction may be more complicated or varied than that of a credit card authorization associated with the card readers identified above 2, 4. The ATM 8 is illustrated as being directly connected to the terminal adapter 14 and the ATM and the terminal adapter may be co-located adjacent or remotely located with each other. Again, various communication arrangements can be used to effect communication between the ATM terminal and the terminal adapter 14 which includes the use of multiple terminal controllers 6 previously described. Finally, Figure 1 also illustrates a point of sale (POS) terminal based on a personal computer (PC) 10 having an integrated card reader 11 that has access to the terminal adapter 14 via a modem 12. The POS terminal is usually a personal computer adapter for POS applications using standard operating software, such as the Microsoft Windows ™ operating system and controls the modem using one of several command languages, such as the Hayes ™ compatible modem command or the commands XON / XOFF. Those skilled in the art will recognize that alternative configurations are possible. For example, the POS 10 terminal could interface with the Terminal 14 Adapter using a USB cable connected to the USB ports, a serial RS-232 or RS-422 interface. Alternatively, the functions of the modem, or sub-group thereof, may exist in the POS terminal or in the terminal adapter as a virtual device driver. If the functionality of the modem is integrated into the terminal adapter, this can be a "software" modem or virtual modem. Specifically, the driver software emulates a modem command interface on the terminal adapter that allows the POS terminal to interact with the terminal adapter as if there were a current hardware modem connected to the POS serial interface. The POS terminal issues the standard modem commands through the serial interface which are, in turn, processed by the terminal adapter emulation software. In addition, the functionality of the terminal adapter can be integrated into a personal computer or the POS terminal by defining a "modem controller and data algorithm" or a virtual modem. Alternatively, the controller modem and data algorithm could be implemented in a server-client system comprising the terminals and a server. Other variations are possible, including the terminal adapter that provides interfaces that incorporate a selected asynchronous probe packet based on the protocol, such as the ISO protocol X3.28-1976, X.25, frame transmission, or bi-synchronous protocol to interface with other types of terminals. Additionally, the present invention is not limited to the card reader or POS terminals, but includes terminals that conduct transactions based on other data inputs, which includes a currency reader, OCR scanners, RF tag detector, sensors, personal computers. for specific purpose, computers that process with manual data entry keyboard, or any type of transaction-oriented processing device. Additionally, the card reader need not be synonymous with the terminal or incorporated in the terminal, and instead, the terminal may be considered to have, or encompass, a card reader whenever the terminal, such as the POS mode, it is in communication with a card reader or a similar functioning data entry device. Although a preferred embodiment of the present invention is directed to financial transactions, the principles of the present invention can be applied to transactions of a non-financial nature, such as telemetry, alarm, maintenance, health care, pharmacy or other applications that normally involve card readers for processing transactions that "slide cards". The terminal adapter 14 can be considered as having a "front end" comprising the terminal interfaces 2, 4, 8, 10. The front end of the terminal adapter can be configured in a variety of ways, including interfacing to a single terminal or a plurality of terminals. If a plurality of devices are interconnected, then the interfaces can be identical (e.g., all based on POTS), all different (e.g., a POTS and RS-232 serial interface), or a hybrid combination (e.g., two POTS interfaces and two RS-232 interfaces). In one embodiment, four POTS interfaces are provided and in another embodiment, two POTS interfaces and two RS232 asynchronous interfaces are provided. Obviously, other combinations of interfaces in the front end are imposed in the first instance motivations of commercial business, capacity and respective costs. The terminal adapter 14 can also be considered to have a "back end" comprising network interfaces interconnected with network communication facilities. In Figure 1, the terminal adapter 14 has two network interfaces at the rear end. One interface 16 is an Ethernet interface; generally connected to a LAN 18 and designated to the primary interface. This interface could be a 10BaseT type of access to the Ethernet, although those skilled in the art will easily recognize other types of LAN / MAN access standards that could be used, such as FDDI, ring network, hint data bus , 802.11x, etc. LAN 18 facilitates interconnection 26 with the Internet 20, because the terminal adapter may not always be in close proximity to the interface at the Internet interface. For example, a store operating multiple sales stations may have a terminal adapter located in the warehouse connected via the primary interface 16 to the corporate LAN 18 which in turn subsequently provides access to the Internet 20. The LAN also isolates The terminal adapter from various Internet access provisions. For example, the terminal adapter 14 is isolated from changes or updates in the physical connection 26 to the Internet, if this will be DSL, wireless, T1, etc. The LAN 18 in turn interfaces the Internet 20 using one of a variety of communication facilities 26, including: DSL, T1, T3, dial, ISDN, fiber optic, cable modems, WiFi, satellite, etc. The terminal adapter enters the Internet interface at the back end and uses either the PPPoE protocol (Point-to-Point Protocol over Ethernet) or the DHCP protocol using access to the Ethernet. PPPoE and DHCP are well-known methods for achieving TCP / IP access to the Internet over Ethernet and are well known in the field of data communications. The primary interface 16 is preferably a high-speed interface, at least fast enough to accommodate the transaction volume of the plurality of terminals. The terminal adapter 14 may also have a secondary interface 22 at the rear end illustrated by a connection to the public switched telephone network (PSTN). The second interface provides support communication capabilities in the event that the primary communication path is inoperable and generally operates at a slower speed than the primary interface. This secondary channel generally uses a telephone line and the terminal adapter usually incorporates an integrated modem and the PPP access protocol. The PPP is well known in the area of data communications to obtain TCP / IP access to the Internet over dialing. The PSTN is notorious for its reliability and general availability, although the speed of dial-up access is limited. However, this is usually the case where a business location will have a telephone line for voice dialing access that can be used intermittently for dial-up access to an ISP, while alternative access methods (such as DSL) are not as frequent. However, the terminal adapter 14 could incorporate such alternative access arrangements for the secondary interface, including: DSL, ISND, frame transmission, X.25, or some other communication protocols for the secondary interface. The secondary interface could still be of the same type as the primary interface. Normally, the secondary interface is based on modems that provide speeds of 28.8 Kbps or 56 Kbps (for example, V.34 or V.90), although other speeds could be used. The terminal adapter of this mode is based on connectivity to the PSTN for secondary access in the situation where the primary communication path is not functional in two ways. First, a preferred embodiment uses an installation 30 to access the Internet 20 to provide an alternative route to the network 33, such that the same group of services is provided. A second embodiment incorporates an installation 32 directly connecting the transaction processor 36. In this mode, the transaction processor 36 could implement the procedures for providing the same value-added services as provided by the aforementioned infrastructure 28, or alternatively, the financial transaction processor may not provide the additional services and allows the Secondary communication has a reduced level of functionality, although it still provides connectivity.

This may be an acceptable business alternative, because transaction-based applications that use a point-to-point POTS connection between the terminal adapter and the transaction processor may find it acceptable to operate without all the value-added services on a intermediate. The Internet 20 provides a communication infrastructure that carries information and provides a group of well-known services using the TCP / IP protocol stack. However, the needs of the terminals to carry out financial transactions (and other applications such as those mentioned above) may not be fully served by the data communication services provided by the Internet. For this reason, various extensions of services are required. These value-added services 28 are provided by various nodes connected to the Internet that operate an additional protocol at the top of the TCP / IP stack. Together, the Internet and the nodes provide enhanced services and comprise the network 33. Although the Internet may be associated with one modality, the value-added service network may be comprised of several nodes operating at the top of another network such such as WANs, LANs, or virtual private networks based on a variety of technologies. The value-added services provided by the network provide additional security, reliability, and flexibility to facilitate other functions that will be described in greater detail. This architecture is based on the concept of protocol layers and is known in the field of data communications. Figure 2, is further expanded on a possible mode of the Internet 20 and value-added services 28 that comprise the value-added network 33. As is well known, the "Internet" is not a single network, but a collection of networks that operate in a cohesive way. This is illustrated in Figure 2, which represents the Internet 20 in the form of two interconnected Internet service providers 27. In practice, there are literally thousands of such networks that comprise the "Internet". The services provided by the Internet use the TCP / IP protocol and are well known, although it may not be sufficient in terms of reliability and security for transaction processing. Accordingly, the nodes 25 are defined providing these additional functions in the network. The nodes 25 are connected to the Internet and can be directly interconnected as well (not shown). Although the three nodes are illustrated, in practice there may be many more, deployed in different geographical areas, reproduced by repetition and interconnected by reliability. In addition, some nodes 25 can be placed or integrated with other equipment, such as the transaction server processor 36 or Internet routers, LANS, portals, bridges or PBX's. There are three types of nodes that generally implement the value-added services and these are the client node 25a, the central node 25b and the service node 25c. The client node 25a interfaces with the terminal adapter, generally using the transport capabilities of the Internet. Although not illustrated, it is possible that the terminal adapter could directly connect to the client node 25a, using any number of communication facilities. This represents a modality in which the client's node and the Internet router's functionality are integrated. The client node 25a recognizes the terminal adapter 14 and performs the functions of synchronization, security, authentication and error detection as well as transmitting and / or interacting the information with the central node 25b. The central node is not always required, although if it is present, it transmits information through the same ISP provider 27 or a different one. The central node 25b can transmit information to other central nodes or to a service node 25c as illustrated in Figure 2. When the central node is routed to another central node, this can route the transactions to the less busy central node, or divert them to an alternative node in the event of a node failure. The service node 25c interfaces with the Transaction Server ("Server") processor 36 which uses any number of point-to-point facilities 34. The service node converts the protocols used when it receives the transaction from another node to the protocol used in it. communication with the server 36. In general, many of the services and features of the terminal adapter are provided with respect to a terminal that can be provided by a service node to a server processor. Therefore, for example, a server processor could initiate a transaction for another server. Generally, connection 34 of the service node to the server is a high-speed digital installation capable of multiplexing significant numbers of transactions. Because reliability is a major concern in financial transactions and other types of transactions, nodes 25 are usually replicated in various locations. For example, the service node is duplicated (not shown in Figure 2) in a diverse geographic location and is also connected to a server processor, such that the server can continue to communicate with an alternative service node if a node fails. of service or communication path. The service nodes can be balanced load (for example, each normally provides 50% of the total transaction traffic to the server) or be configured with a node as a hot wait (providing 100% of the transaction capacity, although it can be switched with the other node when required). Similarly, each service node is usually connected to a plurality of central nodes. Those experts in the field of network architectures will recognize the various configurations that can be used to provide reliable access between the server and the terminal adapter. Additionally, the server can be replicated in a diverse geographic location for reasons of redundancy and reliability. Figure 2 also illustrates a network operations center (NOC) 29 connected to the various nodes 25. The NOC 29 manages and manages the operation of the nodes and terminal adapters with respect to the network. With respect to the nodes, the NOC receives measures, alarm information, traffic statistics, load levels and similar information and acts accordingly. For example, if a node is not functioning properly, the adjacent nodes will reroute the node that is not functioning. The NOC is aware of the state of the node that does not work and can monitor the state of the node, while the problem is investigated and corrected. With respect to the terminal adapters, the NOC is also aware of its operation and maintains a profile for each terminal adapter 14 and its corresponding client node 25a. This allows the NOC to know the current network conditions and the operation status of each element, which includes both the nodes and the terminal adapters. The NOC may additionally communicate indirectly with the terminal adapter by sending management messages transmitted through the appropriate node through duplicate messages with the parameter file that the response executes. The NOC (via the network) can send a command to reset the terminal adapter, route the terminal adapter to the switch from its primary communications path to its secondary communications path, or move the switch to a different client node .

Normal operation Normal operation of the terminal adapter is usually divided into two phases: pre-transaction processing and transaction processing transfer. Various functions must be achieved in the processing phase before the transaction in order to communicate the transactions in the data transfer phase. In this context, "pre-transaction processing" refers to actions that occur before the processing of the terminal that originated the transactions. As will be discovered, the terminal adapter uses the transaction protocol procedures for the input load itself, in order to subsequently process the transactions from the terminal. Accordingly, the transaction message is used between the terminal adapter and the network in the "processing before transaction" phase. Because various aspects of the pre-transaction processing and the transaction processing phase generally reside in the data that is previously predetermined and fixed in the terminal adapter, these data are presented briefly. In other modalities, such as that of the controller modem and data algorithm incorporated in a PC, the PC manufacturer obviously does not previously and irremovably encode these values in the firmware of the PC. In these modes, these values are programmed into the device manually or loaded by reading a file.

Embedded Data A type of data manufactured in the firmware of each terminal adapter of a mode is a terminal adapter identifier value that uniquely identifies the device. This value can have the format of < id of the manufacturer > < model number > < serial number > < suffix > . This structure forms an identifier of 24 bytes, although other structures and values can be used to achieve a unique identifier programmed into the terminal adapter. For example, the MAC address (associated with the Ethernet network interface) could be concatenated with the serial number and used as an identifier. The terminal adapter identifier is normally sent in all messages to identify the particular terminal adapter to the network and allows, in part, that the network and the NOC maintain the status and service profile information for each terminal adapter. . Another example of the data programmed into the terminal adapter of a modality is a secret key used in encryption and authentication. The secret key value is not communicated over the interface, although it is used by both the terminal adapter and the network to encrypt information that is communicated over the interface. As is well known, the use of encryption also facilitates the authentication of a particular terminal adapter. Authentication can be achieved by the terminal adapter and the network that encrypts a common data value, exchanges and then compares the result. Only if the terminal adapter has the correct secret key, will this encrypted value match the value of the network. To use the secret key to encrypt transactions, encryption is achieved using a key derived from the secret key, the login and the transaction counter. In this way, if an unauthorized user breaks a message, the secret key is not revealed, and in this way, other messages are not compromised. The terminal adapter of a mode also stores a default configuration service name that describes the parameter file version that is currently maintained in the non-volatile memory. In this mode, a value is programmed in the terminal adapter that describes the version of the parameter file present initially in the ignition, although subsequently a determined value is obtained dynamically from the network and replaces the default value. Another example of data programmed into the terminal adapter of a modality is a default service name. The service name is a default URL of a server that provides address information "loading input", usually in the form of a group of IP addresses of client nodes that the terminal adapter uses to interact with, for transactions and administration functions (for example, parameter download). Normally, a terminal adapter uses a unique address for these functions, although for various reasons, which include reliability, alternative values are used.

These values are programmed in the terminal adapter as default values. In many cases, the default values are usually increased by the dynamically determined values provided by the network as part of the input loading procedure. The values obtained in dynamic form do not erase the default values (it must be remembered that the default values are encoded in a previously determined and immovable way in the terminal adapter), although the terminal adapter stores both and knows through the presence of the dynamic values, that the default values have been replaced.

Processing phase before the transaction As of the power up, the terminal adapter generally executes various related procedures. In one modality, these are: service discovery, synchronization and authentication, parameter download and software download. All are executed from the initial power-up of the terminal adapter, but later, the procedures can be invoked separately. Upon initial power-up, the terminal adapter of this mode first invokes a service discovery procedure to obtain a list of IP addresses corresponding to the client nodes. This is accomplished by sending a service discovery request using the service name address that is permanently encoded in the terminal adapter.

The terminal adapter of this mode is then synchronized and authenticated by itself for the network. These procedures occur together, such that authentication follows the occurrence of synchronization. Accordingly, "synchronization" implies synchronization and authorization in any case dictated by the context. Synchronization is usually required before sending transaction requests and occurs frequently after the terminal adapter has initially been powered on. For example, if the terminal adapter has been active for a long period of time, synchronization may be required again. The synchronization is set out in detail in conjunction with the normal transaction transfer, so that this explanation can be focused on the initial power-up functions. After synchronization, the terminal adapter of this mode selects one of the IP addresses obtained using the service discovery and uses them to initiate a parameter download using a transaction request. As stated subsequently, this is the form known as the "simple" transaction request. The parameter file contains various configuration and address information to facilitate the operation of the terminal adapter. The parameters may indicate, in part: where transactions should be sent, the primary and secondary communication path information, and where to obtain the new software applications for software downloads. The terminal adapter usually downloads a parameter file indicating its current parameter file version to the network. This is an implicit request to the network to indicate if a more current version exists. During initial power up, this value indicated by the terminal adapter is usually the default configuration service name encoded in the terminal adapter. When the network is called the default configuration service, it recognizes that the request must be routed to a specified process server and a configuration version number of zero indicates that the terminal adapter is requesting an initial parameter download. The network responds by sending the current name of the parameter file version together with the parameter data. Next, the terminal adapter in this mode examines certain parameters in the parameter file to determine if a software download should occur. The software download refers to downloading a new application code (binary image file) for execution. The terminal adapter examines the binary image name of most files that can be run recently, as indicated by the network in the parameter file and compares it with the current value stored in the memory. If the terminal adapter finds a file that can be executed differently compared to the one stored in the default memory (which is probably the case at initial startup), the terminal adapter calls the file that can be run again . The location that calls the executed file is usually indicated by an address in the parameter file. After the terminal adapter loads and runs the current application, it is ready to process transactions from a terminal. Therefore, you are ready to start the transaction processing phase.

Transaction processing phase Before sending a transaction, the terminal adapter is usually synchronized and authenticated for the network. This happens in a general way during the initial ignition, although it may be required again. The new synchronization occurs frequently and is considered a normal operating procedure. The synchronization facilitates transaction processing in an orderly fashion between the network (specifically, the client node) and the terminal adapter, as well as improving the security of the transaction by exchanging a new session cue. The new synchronization may be required if an error occurs when the terminal adapter moves the switch from the first to the second communication path, or when the terminal adapter switches the switch from one client node to another. Authentication is required to ensure that the network is communicating with a trusted entity and passes the encryption parameters (for example, a session cue, as discussed below) to the terminal adapter.

In the embodiment of Figure 3, terminal adapter 301 first opens a TCP connection to network 303 in step 300. The terminal adapter sends a synchronization request in step 302 and includes a transaction counter (TC) in the header of the message. After which, in subsequent transactions, the network will wait for the transaction counter to be incremented over the current value each time a transaction is sent. If the network receives an unexpected value, an error code is returned to the terminal adapter and the terminal adapter is required to synchronize its transaction counter again. The new synchronization is required under various conditions, including: that the terminal adapter is active for a long period, changing the switch from primary to secondary communication paths, or because it does not have the ability to complete a transaction. The network registers the TC value and calculates a digest message. The digest message is a condensed text series that has been distilled from the content of a text message, where its value is derived using a function in pieces of a path and is used to create a digital signature. The network can use a particular form known as a digest message 5 (MD5) based on a random value (RV) and the transaction counter (TC). This is returned in a synchronization response in step 304 which means that the synchronization occurred and that the terminal adapter will authenticate itself.

The terminal adapter responds by formulating a type 5 digest message (MD5) based on a secret key (PUC) and the transaction counter (TC) in step 306 and sends it to the network. The network compares this value with its previously calculated value, and assumes a match, returns a response in step 308, which indicates that the authentication has occurred successfully and includes a session cue (ST). The session cue is encrypted using the digest message and is used by the terminal adapter to derive the key used for subsequent encryption / decryption in the data transfer phase. Finally, when complete, the terminal adapter can close the TCP connection in step 310. Alternatively, the terminal adapter can leave the TCP connection open and avoid the additional steps to open a TCP connection before entering a phase. of subsequent data transfer. There are alternative security and authentication means that could be used to authenticate and encrypt information, which includes other public and private key schemes, such as RSA, PGP (very good privacy), etc. Those skilled in the art will recognize that a variety of message types, formats and encryption techniques could be used to achieve the synchronization and authentication function of the terminal and network adapter, although all of these are within the principles of the present invention.

The transaction processing phase is used to transport transactions that start from the terminal, and in one modality, there are two methods to achieve this: simple transactions and session transactions. The simple transaction is composed of a couple of request-response messages. These are often used in credit card or ATM based transactions where a couple of simple messages is enough to complete the transaction. The procedure is illustrated in Figure 4. In Figure 4, the terminal adapter 400 communicates with the network 402, typically with a client node 25a. The network 402 also communicates with a server 404, which is the financial transaction processor 36 of Figure 1. The terminal adapter must open a TCP connection in step 406 if a connection has not yet been opened. After that, a simple request 408 is sent to the network, which then routes the message to the appropriate server 410. The server processes the transaction 411 and responds in step 412. The network 402 receives the response and sends it in step 414 to terminal adapter 400. The terminal adapter extracts response 416 and sends the response to the terminal (not shown). If there are additional transactions that can use the same TCP connection, then the procedure is repeated in step 418. If there are no additional transactions, the terminal adapter will close the active TCP connection in step 422 and any additional transactions in step 420 will result in opening a TCP connection again in step 406. The other method for sending a transaction in this mode is to use the session transaction. The session transaction is used for more complex transactions, such as establishing activities that occur at the end of the day. For example, in some business implementations, the POS terminal retains the data for financial transactions during the day and must send the summary information to the server for establishments at the end of the day. A session transaction is composed of multiple request-response pairs and is more appropriate than the single request-response for long transactions. The session transaction is composed of multiple request-response pairs that are guaranteed to be delivered in sequential order to a server of the same logical connection. When a session transaction is initiated, the client node initiates a session with the appropriate service node and the service node responds with session context information, such as address and port information. This allows the client node to generate a map of the subsequent message associated with the session. If the transaction data is provided by the terminal, the client node includes the data in the login message, and the service node sends these to the server. The session context also allows the terminal adapter to continue a session using a different client node in the event that the initial client node becomes unavailable. This procedure is illustrated in Figure 5. Figure 5 illustrates the terminal adapter 500 that communicates with the network 502, which in turn communicates with the server 504. The terminal adapter must open a TCP connection in step 506 if a connection has not yet been opened. Then, the terminal adapter communicates a login request in step 508 to the network, along with the transaction data. The network routes the message to the appropriate server in step 510. Specifically, the client node receives and transmits the message to the service node, which then transmits the message to the server. The server processes the transaction data in step 512 and transports the response 514 to the network and is then transported again 516 to the terminal adapter. At this point, the terminal adapter in step 518 is ready to send transaction data and the network has internal session tables set to produce the terminal message maps subsequent to a specified session and server. The transaction data is formulated in step 520 and a session transaction request is sent to the network in step 522, which then routes the request 524 to the server, which processes the transaction 526. The response 528 is transported to the network and back 530 to the terminal adapter that extracts the response data 532. If additional transactions are desired, the procedure is repeated in step 531. Once all the request-response transaction messages are transported, the terminal adapter then formats a session termination request 534 and sends it to the network in step 536. If the The transaction is included, the network sends them to the server 538 and processes the message 540. The server sends a response 542 that is sent by the network to the terminal adapter 544 in the end session message that closes the assignment 546. Once completed, the TCP connection can be closed 548. Both forms of transaction have common aspects. First, transaction messages in any form incorporate a terminal adapter identification number. This may be the value encoded in a previously determined and immovable mode within the terminal adapter, or in the case of software running the PC emulating a terminal adapter, the value may be programmed into the device. The identification number of the terminal adapter uniquely identifies the device connected to the network 33. This unique value allows the network to maintain information for each terminal adapter using the network. If an error condition exists, the network will have the ability to correlate the condition with the particular device and take the necessary action. This may include, for example, notifying the appropriate service personnel to investigate a problem, such as a defective terminal adapter. Additionally, the statistics corresponding to each transaction can be maintained and recorded for a specific terminal adapter, allowing the added value information to be extracted from the periodic reports.

Second, both types of messages use error detection using well-known techniques, such as cyclic redundancy codes (CRC). This allows easy detection of errors in a transaction that can be detected by the network, the server or the terminal adapter and ensures that only uncorrupted data is processed. Additionally, both forms of transaction use encryption based on a secret key that is programmed into the terminal adapter at the time of manufacture. Encryption schemes are based on 3DES, AES or any other scheme well known in the art. The 3DES and AES schemes encrypt multiple texts of 8 or 16 bytes encrypted respectively, and when the encrypted text is not a multiple of the block size, then the ciphertext is filled with zero to the appropriate length. The encryption key can be generated based on the current MD5 on the concatenated value of the private key (known to the terminal adapter), the transaction counter and the session indication. Additionally, both transaction forms indicate a service name that is used by the network to determine the appropriate server to process the transaction. The service name is derived from the parameter download and is used by the network to identify a particular service node to then deliver the transaction to the appropriate server. Those experts in the field will recognize that the message formats to transport this information, which can be of different formats. In one embodiment, the messages indicate a packet type with defined values for the request / response session and the simple transaction request / response. A variety of coding and structures can be used to transport the previous information, as well as to encode the information. Previous capabilities to communicate transactions between the terminal, the network and the server ensure that: * only trusted entities are allowed to initiate a transaction with the network; * transactions are recognized in an orderly manner by the various entities; * transactions have error verifications at various points to ensure that no errors occur during communication; * transactions are encrypted before being delivered to the network to ensure that unauthorized recipients can not understand the contents; and * the terminal adapters are uniquely identified to allow the correlation of transaction events related to a specific user of the network. The system in which the terminal adapter operates can also be seen with respect to protocol stacks. As illustrated in Figure 6, a protocol stack 650 is implemented in the card reader 2 comprising a POS 651 application, which is normally programmed at the time of manufacture. This request uses the services of a financial transaction protocol 652, such as the VISA-II protocol (also known as VISA-2) to transmit credit card authorizations. This, in turn, resides in a telephone protocol 653 comprising the modem and dialing dialing procedures to communicate over the line to communicate over a telephone line 654 to the terminal adapter 14. The terminal adapter contains a protocol stack 656 that receives the information on the telephone cable 654, decodes the information using a corresponding telephone protocol 655, and transmits 657 the financial transaction protocol information on the back of the interface. This "back" of the interface uses the value-added service layer 658 to provide a secure and robust data transmission to the 636 server. The value-added service layer 658 uses the TCP / IP 659 protocol layer and incorporates the authentication procedures, tuning and encryption mentioned above for sending transactions. Transactions are communicated using TCP / IP over the Ethernet that requires the use of the IEEE 802.3 660 Ethernet protocol layer. The LAN is normally a 10BaseT Ethernet via the Internet. Not all protocol stacks for all physical elements are illustrated, since they are not required to illustrate the principles of the present invention. For example, the Ethernet / Internet bridges the LAN and provides access to the Internet that is not illustrated as it is transparent to the stratum of value-added services and higher layers. Additionally, only one value-added service node in network 33 is illustrated by protocol stack 662. This node is a combination of client node and service node, since it performs the interface to both the terminal adapter and the server . In practice, a separate protocol stack for a client node and a service node could normally exist, in communication with each other, using the Internet or other facilities. Those skilled in the art will also recognize many other variations. The value-added service node receives data through the lower layer 665, processed through the TCP / IP strata 664 and is then processed by the value-added service stratum 663. If it is acceptable, the data is transmitted by the stratum of service. financial transaction protocol 666 back to stratum TCP / IP 667 and a physical stratum 668, which can be based on a variety of protocols (eg, T1, DSL, etc.). The transmission layer 666 in the node may or may not convert the financial protocol to another variant as required by the server. The data continues through the physical facility 669 and the financial transaction server 636 which implements a protocol stack 674 comprising a physical layer 670, the TCP / IP layer 671, a financial transaction protocol 672, and a POS application . In this architecture, the two POS 651, 673 applications communicate in a client-server mode, as does the value-added service protocol layer 658 in the terminal adapter with the 663 value-added services protocol layer. in the value-added service node 25. This type of protocol layer modeling is well known in the art and indicates information that is transported transparently by a lower layer that provides services to the upper layers. The value-added service stratum is usually in communication with an internal administration application that runs on the terminal adapter and communicates with the NOC (not shown). This allows the value-added services stratum to respond to actions and events outside the direct scope of the value-added services protocol itself. For example, a service provided by the aggregate service stratum 658 is data reliability. The handling procedure in the terminal adapter detects a failure in the communications path from the rear end of the terminal adapter. The failure detected at the rear end of the primary network interface can be any type of failure in the physical layer of the Ethernet 660 (assuming access to the Ethernet for the primary communication path), the TCP / IP layer 659, the stratum of aggregate services 658, or stratum PPP 666 (assuming that dial-up access was used for the primary communications path). For example, a physical break in the Ethernet could result in a loss of electrical signals in the 660 physical stratum. A physical cable outage could also result in a failure in the TCP / IP 659 stratum, because it does not They could transmit the pictures. Other failures could only be in the TCP / IP layer, such as the failure to resolve an address request (for example, URL), or a failure to receive a response at the TCP / IP level. A failure in the stratum of aggregate services 658 could occur if there were a catastrophic failure of the service node 25, which could abandon the two functional strata from the perspective of the terminal adapter. For any reason that a failure is detected, the administration procedure directs the stratum of value-added services 658 to establish a secondary communication, directs again any terminal transaction request received subsequently to the secondary communications path and summarizes the processing of transaction. During a failure in the primary communication path, the terminal adapter returns an error to the terminal (which depends on the terminal interface). Normally, the terminal tries to start transactions again and the terminal adapter normally has the secondary communications path established for this moment. Another service provided by the value-added service stratum 658 of the terminal adapter, in conjunction with the value-added services node 25 may be service discovery and transaction synchronization. The service discovery allows the terminal adapter to obtain the addresses used to then discover the locations of the appropriate server to which the transactions are directed. In this mode, a port address and location is provided to address the transactions, although other addressing information could be used in other implementations. In conventional systems, the card reader 2 is normally programmed with a telephone number that establishes a direct connection to a server. Accordingly, each terminal is programmed with a destination address of the server. In the present system, the terminal adapter determines the appropriate server to transmit the financial transaction information based on the information provided by the network 33. Additional services may include security features that involve a terminal adapter to synchronize it first using a transaction counter before the communication of transactions. In addition, the terminal adapter can identify itself using a unique programmed identification number for the network 33. Finally, the terminal adapter can authenticate itself using a digest message. These activities ensure that the network is communicating with a known, reliable entity in a coordinated manner. The terminal adapter can also provide some value-added functions separate from the data transfer capabilities of the value-added service stratum. These can be seen as administration-oriented functions and an increase in functionality of the terminal adapter. For example, the automatic configuration of the transaction protocol used by the card reader 2 allows a variety of terminals to interface with the terminal adapter. Card readers 2 are usually programmed with a previously defined credit card authorization protocol, such as Visa-ll and are based on the recipient (usually the server, through the PSTN) to know, in advance, what is the protocol used. The terminal adapter 14 can work with a variety of terminals and is programmed to automatically detect and determine which financial protocol to use and the address to which the transaction will be directed. Therefore, the automatic configuration capability provides a versatile terminal adapter. Finally, the stratum of value-added services in conjunction with the administration application manages the download of software and new parameters. This ensures that when new value-added network services are deployed, requiring a corresponding improvement in the software in the terminal adapter, an EPROM microprocessor is replaced, or otherwise, requires manual intervention. This function allows the network to write parameters remotely to the terminal adapter to also maintain the status information.

Hardware Generals An embodiment of the principles of the present invention is illustrated in Figure 7, which describes the hardware configuration of the terminal adapter 14. The terminal adapter is comprised of several currently available integrated circuits. Returning to Figure 7, the terminal adapter 700 comprises a "front end" 706, which refers to the terminal and user input / output interfaces, as well as a "back end" 708, which refers to the network interfaces. The terminal adapter uses a microprocessor 702 as the main controller. Although the embodiment describes a microprocessor, other variations may be used, such as single microprocessor microcomputers or programmable controllers. The microprocessor uses an input / output data bus to control the various "front end" interfaces. These may include a series of LED indicators 710 indicating the general state of the terminal adapter, network interface status and terminal interface status. Alternatively, the LCD or other types of displays or visual indicators can be used to reflect the state, using, for example, text or cones. The status indicators indicate whether the primary or secondary network interface is currently in use, the status of modem bearers, and other indicators related to diagnostics. The RS-232 interface of console 712, allows the local terminal to connect to the terminal adapter and facilitates the programming of the terminal adapter, indicating the configuration changes, performing the administration functions, etc. The four POTS 714 interfaces are used to interface with the terminals using a standard RJ-11 telephone connector.

The data bus I / O of the microprocessor also communicates with the interests of network 708. This is usually the I / O data bus that is used to communicate with the terminal interfaces, although it is represented in the form of two separate data collector bars for clarity. The network interfaces can comprise an Ethernet 724 interface, which uses a standard 10BaseT protocol, and is used to transport the primary communication path. The terminal adapter can also incorporate another POTS 722 interface to transport the second communication path as a backup network interface. In one embodiment, the Ethernet interface 724 may be optional as the telephone interface 722 may be used to transport the communication path both primary and secondary. Regardless of the configuration, the network interface provides connectivity for the primary and secondary communications path. The microprocessor 702 also communicates with the memory in the form of a RAM 716, ROM 718 and a non-volatile RAM 720 (eg, "flash memory"). In other modalities, the ROM and the limited RAM could be integrated in the microprocessor as the one that is incorporated with the microprocessor single microcomputers. Finally, a power source 704 is present and this can incorporate a backup battery to store the data in the event of a temporary power pause. A guard timer 726 can be incorporated to reset the terminal adapter in case of a suspension. A manual reset button 728 provides another way to reset the terminal adapter.

Software Overview The software components associated with the hardware components are illustrated in Figure 8. The software architecture of the system 800 involves a real-time operating system 802 that interacts with a TCP / IP 804 protocol stack, the services value added 832 and a transaction protocol handler, which in this embodiment, comprises the VIS 844 terminal interface. The TCP / IP stack comprises several well-known protocol handlers, such as PPPoE (point-to-point protocol over Ethernet) 806, PPP (point-to-point protocol) 808, and CDP (dynamic server configuration protocol) 810. In addition, IP protocols (Internet protocol) are present. ), ICMP (Internet control message protocol), and the DNS (domain name server) 812, as well as the UDP / TCP (user datagram protocol / transmission control protocol) 814, and the 802.3 Ethernet 818 controllers. The TCP / IP 804 stack interacts with the network interface card 826 which is the primary network interface used by the 828 Ethernet receiver that connects to an RJ-45 830 connector. The TCP / IP 804 stack also interacts with the secondary network 820 interaction that incorporates a connected 822 modem controller. to a RJ-11 824 connector. The 802 real-time operating system also interacts with various 832 value-added services that can be implemented through modules to carry payload data 836, encrypt data 834, exchange security keys 838, download software 840 and perform service discovery 842. Finally, the real-time operating system 802 also interacts with the terminal interface 844, which comprises the software modules for a financial protocol handler 846, character handler 848 and modem handler 850. The terminal interface 844 then interacts with a POS 852 interface that multiplexes and formats the data for a standard 854 modem for one of the four RJ-11 856 connectors. FIGS. 8, illustrate the principles of the present invention as represented in a terminal adapter, although other embodiments exist. As indicated above, the terminal adapter 14 is involved with communications with the network 33, specifically with the nodes 25 or in other cases, indirectly with the NOC. Accordingly, the nodes also represent the inventive principles. Nodes can be compute servers with large amounts of memory, parallel processing and hundreds of I / O ports and they operate using a variety of operating systems, including UNIX, Linux and Windows. The associated hardware and software structure may vary from that described in Figures 7 and 8. Another embodiment is a variation of the terminal adapter 14 based on a personal computer. While the terminal adapter depicted in Figures 7 and 8 is a specific purpose computer equipped with specific purpose application software, a general-purpose personal computer may have software installed to achieve the same functions. Personal computers often incorporate many of the hardware and software components illustrated in Figures 7 and 8 and commonly incorporate a modem and / or Ethernet network interface card (NIC) to provide access to the Internet. The personal computer could similarly implement the PPPoE or CDP for Internet access over the Ethernet, and PPP over a dial-up connection to an ISP using the modem. Additionally, many of the software capabilities (for example, the TCP / IP stack and modem interfaces) are already present in personal computers enabled for the Internet. These often use a Microsoft Windows ™ operating system, which provides a well-known software platform for software development. Although a PC is a common representation for the terminal adapter functions, other modalities are possible, such as the installation of software in a mini-computer, or a server associated with a client-server implementation, where the server uses other operating systems , such as UNIX ™ or LINUX ™.

Another mode is possible when the personal computer is configured only with a modem and dialing capabilities, without access to the Internet. In this case, the connectivity of the personal computer uses a telephone line for both primary and secondary means of communication, although an ISP and / or different client node is used, this may be involved when dialing a secondary telephone number. The software for such an application can be loaded into the memory of the personal computer, including downloading software from a world wide web site on the Internet or uploading the application from a removable medium (for example, a floppy disk, tape, CD, etc.). In yet another embodiment, an API library (application programming interface) is provided which allows a third party to develop a system that incorporates value-added functions according to the principles of the present invention. In this case, the capabilities of the application are defined by the developer and are loaded for execution on the PC. The flexibility of the above modalities is illustrated in Figures 9A and 9B, with respect to how various value-added functions can be developed. In Figure 9A, two modes illustrate how the PC can currently access the Internet through an Ethernet and / or a dial-up connection. Specifically, in the alternative 1 900, the PC is running a POS 902 application that uses the services of the operating system 904. The operating system can be any of the common operating systems found in the PCs. Operating system 904 uses device drivers to interact with hardware interfaces. A device driver 906 allows interaction with a modem 910 that is connected to a telephone line 916, which is well known in the art. The other device driver 908 interacts with a network interface card (NIC) that is connected to an Ethernet 914. An alternative mode is illustrated in alternative 2 920, which similarly incorporates a POS 902 application, an operating system 904 and device drivers 924, 926. However, these device drivers interact with the interfaces on the PC. Specifically, a device driver 924 interacts with a serial RS-232 interface connected to a 930 modem. The other device driver 926 interacts with a USB (universal serial data bus) connected to a NIC 928. In this mode , the hardware to interact with the Ethernet and the telephone line is external to the PC and is connected by means of well-known serial interfaces. These systems can be easily aed by loading the appropriate software (ie, a "modem controller and data algorithm") to incorporate some of the functionalities of the terminal aer. This allows the hardware of an existing PC configuration to be aed to interact with the network to receive value-added services. In Figure 9B, a modality is illustrated in which the modem and NIC are integrated within the PC (corresponding to alternative 1 900 of Figure 9A). In Figure 9B, the PC 900 still incorporates the same POS 902 application and operating system 904. If it exists, the changes required to use the 956 enhancement software are minimal. Once the modem controller and data 956 algorithm is loaded , this creates a virtual serial port that receives and sends data to the POS application and the operating system. In essence, the POS application sends data to the software as if it were another serial interface, as illustrated by logic path 950. The modem controller and data algorithm recognizes various commands and modem data and after processing, uses to the operating system to interact with device drivers. Specifically, the modem controller and data algorithm interacts by means of a logical path 952 with the device driver 906 connected to the internal modem 910 and interacts by means of a logical path 954 with the device driver 908 connected to the NIC 912. The modem 910 and the NIC 912 are connected to a telephone line 916 and the Ethernet 914, respectively. In this way, the controller modem and data algorithm can use the NIC 912 to transport a primary communication path using the Ethernet and the 910 modem to transport a secondary communication path using the telephone line.

An alternative mode that uses a modem controller and data algorithm is feasible even when the PC has only one integrated modem, without an Ethernet access NIC. Similar to the terminal adapter that has only one telephone interface as a network connection, the controller modem and PC data algorithm can still initiate a secondary communication path using the modem to dial a second telephone number. An advantage of this mode is that the value added services of the network can be achieved by adapting existing PCs without requiring additional hardware. Some of the above value-added services are now examined in more detail as part of the terminal adapter mode. As indicated above, the principles of the present invention are not limited to the modality of the terminal adapter.

Secondary Communications Path The switch from the primary communication path to the secondary communications path is illustrated in FIG. 10. Specifically, FIG. 10 illustrates a flow chart depicting the error detection associated with the communication path. primary, which is commuted to a secondary communication path and restores the primary communication path from the determination that the primary communications path is working.

In Figure 10, the procedure begins at step 1000. The terminal adapter is processing transactions in a normal manner using the primary communications path associated with the Ethernet based on the network interface in step 1002. The system monitors faults , errors or abnormalities associated with the primary communication path in step 1004: Errors can be of different types. For example, an error could occur at the level of financial transaction protocol 1006 as a result of the structure or incorrect data. The error could be based on the TCP / IP 1008 level as a result of the failure to receive a response to a message. The error could be based on a physical stratum error 1010 as a result of a cut wire. Obviously, a cut wire can trigger errors in other layers. For whatever reason, the data may not be transmitted reliably, the system flow controls the terminals 1012 while the latter determines whether the secondary communication path is configured 1014. If not, then no further action can be taken 1018 However, under normal conditions, there will be a data configuration in the parameter file to configure the secondary communication path. The system retrieves the data, including the telephone number 1016 and originates a secondary communications path using the PPP protocol over a dial-up connection 1020. Once established, the terminal transaction processing can perform a 1022 digest. The system also indicates the state of the communications path by means of the front panel LEDs 1024 indicating that the secondary communications path is active. Sending transactions using the secondary communications path is accomplished by altering the routing table for the IP address used to send the transaction. During normal operation, the terminal adapter routes the IP address to send a transaction over the primary communications path using the Ethernet network interface (in the mode where there are two network interfaces) using the PPPoE or DHCP protocol. The new routing is achieved by "pointing" an IP address to the secondary communications path using the network interface based on the telephone and the PPP protocol. The system periodically monitors the condition that triggered the switch change in step 1026. This usually involves sending a "test" message over the primary communications path using the Ethernet-based network interface. The system has more than one IP address that it obtained through service discovery. While an address is used for transaction processing, the other one is used to test the primary connection. The test is achieved by configuring the internal TCP / IP frames (ARP and routes) in such a way that test messages destined for an address that are not currently used for transaction processing are routed to the primary (Ethernet) interface.

Based on the response or lack thereof of a test message, the terminal adapter may determine that the transaction processing should continue in step 1022 using the secondary communication path. However, if in step 1026 it was determined that the primary communication path has been restored and is reliable, the transactions are moved to the primary communications path in step 1028, "pointing again" to the IP address to route the data over the network interface based on the Ethernet. The secondary communication path using the telephone connection can then be terminated 1030 and the sending of test messages can be terminated. In this way, the terminal adapter can provide reliable, repetitive transaction processing when a failure occurs associated with the primary communication path. Figure 11 illustrates the protocol structure when the terminal adapter is using the primary communication path. Communications between the card reader and the terminal adapter are not directly impacted. Accordingly, the protocol stack in the card reader 1170 interacts with the similar protocol stack in the terminal adapter 1175 in the same manner as normal operation (see Figure 6). Similarly, the interaction of similar protocol stacks in node 1187 and financial transaction processor server 1189 are the same. The main difference during the use of the secondary communication path is in the communications between the back end of the terminal adapter and the value-added client / services node (specifically, the left protocol stack of the node representing the client node). in Figure 11). When the terminal adapter receives a message from a terminal, the message is passed through the value-added service layer 1177 via the TCP / IP layer 1178, although it now uses a PPP connection over a telephone layer 1179. Because the secondary communications path is a dial-up connection 1180, the PPP is used because this is a common method for transporting TCP / IP over a dial-up connection. The telephone connection interacts with the telephone network to complete the call to an ISP. The telephone network and the ISP are shown as a combined entity 1181, although those skilled in the art will note that there is a conversion at some point of the physical telephone connection 1180 for another type of physical connection 1182. This conversion is performed transparently to the node and the only requirement is that the physical layer 1183 in the node corresponds to the protocol used by the Internet provider 1181. Once the message is in the node, the information flows from the physical layer 1183 to the stratum TCP / IP 1184 , although in this case, the PPP protocol will probably not be used, because it is not likely that a dial-up connection will be used between the node and the Internet. The aggregate service layer 1185 ensures that transactions are continued without interruption using the secondary communications path using the aforementioned security, authentication and encryption procedures. The data is transmitted to the stratum of financial transaction protocol 1186, where it continues in this direction towards the server. In this situation, the service node (represented again as a combined client / service node) may be a physically different node than that used in conjunction with the primary communications. In addition, the client node can detect the existence of a new connection and notify the NOC of the situation. In this way, the NOC has the ability to detect when a particular terminal adapter is operating in the support mode. Additionally, different or additional central nodes can be used to route the transaction to the server. At this point, the terminal adapter indicates the change in the state of the primary communication path operation by means of the LEDs or other form of visual indications. The LEDs are a modality to provide users with a visual indication of the state of the primary and / or secondary communications path. The terminal also updates a status indication associated with each communication path. This status indication can be used by the terminal adapter to direct transactions to the primary or secondary communications path.

During the time in which the secondary communication path is used, the terminal adapter is also sending "test" messages over the primary communication path to determine if the connection is available. The criteria used to determine if it is available may vary. For example, the terminal adapter may have an error counter within a mobile window to determine that the primary communications path is unacceptable for transporting transactions. In this situation, test messages may result in responses that are monitored for error. Alternatively, the error caused by the switch change may be a total lack of operation in the primary path and any response to a test message may indicate that the primary communications path is available. Once the primary path is restored, the terminal adapter communicates the transaction using the primary communications path and the secondary communications path is terminated. The change in status is reflected in the LEDs and internal boxes as appropriate. In some installations, the terminal adapter can access the network with the appropriate communications path associated with a dial-up network connection. In this case, there still exists a form of secondary communication path, although this resides in a dial-up connection using the same telephone line, albeit for a different telephone number. In this circumstance, the secondary communication path does not provide communications when certain failures occur (for example, a cutoff of the telephone line). However, failures occur frequently in the ISP and are more likely than the failure of the telephone line or telephone network. In this situation, an alternative dial-up connection can be established for an alternative access point of the same ISP or for an alternative ISP. In this way, when the terminal adapter dials a second support telephone number, it evades the original fault. This could result in an alternative nt node serving the terminal adapter. Another modality involves the terminal adapter that establishes a direct dial connection to the nt node. When dialing is used for both primary and secondary communication paths (that is, the primary and secondary communication paths use a common network interface), the terminal adapter lacks the ability to determine when the primary communication path is restored This is because the "test" messages can not be sent, because the telephone line is dedicated for support access. The NOC becomes alert when the terminal adapter is operating using the secondary communications path and monitors the various conditions, which include the event that causes the switch to change on behalf of the terminal adapter. For example, if a link between the ISP and the nt node fails, the terminal could change the switch to the secondary communication path, evading the failed link. The NOC is aware of the link failure, and when the link is restored, the NOC directs the terminal adapter to terminate the secondary communications path and restarts communications using the primary communications path. There are a variety of techniques for effecting the NOC for terminal adapter communication and a method involves the use of the download capabilities of new communication parameters and code raised in the present description.

Automatic protocol configuration Figure 12A illustrates a modality of the terminal adapter that determines the appropriate protocol to use for a given terminal and the server to which the transaction will be sent. Terminals can use a variety of protocols, although they usually use an industrial standard or proprietary protocol for card authorizations. Common industrial protocols include VISA-1 and VISA-II for card readers and ATM machines, as well as internationally recognized protocols, such as ISO 8583. At a high level, two techniques are generally relevant to determine the terminal protocol, the appropriate transaction type message, and the service name (address) associated with the transaction. These techniques are analyzed and the map of the telephone number is drawn up. The way in which these are used, depends in part, on the server's capabilities. Specifically, some servers can only recognize simple transaction types. In this case, each terminal that accesses the server is presumed to require only simple transaction type messages. Consequently, each message is mapped to a simple transaction message once the destination server is determined. Other servers can recognize and require both session and simple transactions. In this case, the terminal adapter must select the appropriate transaction request message when transporting a terminal transaction. Because most transactions are simple, the terminal adapter in some cases is assumed to use simple transactions, unless the exception processing indicates that a transaction session should be used. In one mode, the terminal adapter and the server only send / accept simple transactions. The terminal adapter only has to recognize the type of protocol (for example, VISA-I or VISA-II) and the destination server. A method for the terminal adapter to determine the protocol used by the terminal is based on the telephone number dialed by the terminal. For example, in Figure 12A, the card reader 2 is programmed to dial a defined number. The terminal adapter processes the dialed number using frame 1290. Frame 1290 contains a column 1291 for each defined telephone number, a column for the associated protocol type 1224, and a column for the appropriate service name 1293. In this example, A geographic area can receive service through two server processors such as those identified by the names "fubar.1" and "fubar.2". Each service name can be associated with the protocol, either VISA-I or VISA-II. Consequently, there are four telephone numbers 1294, 1295, 1296, 1297 that are entered in the table; one for each combination. For example, dialing 404-555-1235 1295 will result in the terminal adapter using the VISA-2 protocol and addressing the request to the server "fubar.1". The terminal adapter must still analyze the message to extract the relevant information and copy it into a simple transaction request message. This message is sent to the client's node in the network using the boxes to route the message to a specific service node. In this way, the terminal adapter can be easily configured automatically by itself to use the appropriate protocol and select a server in the dialed number. Once in the service node, the transaction is then routed to the appropriate server. Another method in which the terminal adapter determines the appropriate terminal protocol is illustrated in Figure 12B. This method is based on the analysis rules defined and assumes that the terminal and the server can send / receive transactions, either simple or session. Normally, the vast majority of transactions are simple transactions with only a few cases that require session transactions. When a terminal establishes a connection with the terminal adapter (for example, dial a telephone number and an active connection is established), the terminal adapter 14 sends an "ENQ" or question message 1298 to the terminal. The terminal will respond by sending a message 1299 that includes a previously defined ASCII string. Based on the type of protocol implemented in the terminal, the message chain will have certain characteristics. For example, the message string will be one of several lengths with certain values at the beginning and / or end. For example, a rule is: (START WITH ("T.") OR START WITH ("E.") AND LEN (32) AND TERMINATE WITH ("98") This rule examines the message of the terminal and determines the character Start ASCII, the length and the last two characters.If the conditions match, then a lookup table indicates the type of protocol, the type of message and the server address.In this case, the terminal adapter produces a map of a message that starts with an ASCII "T" or "E.", which is 32 bytes long and ends with an ASCII "98" for a transaction request message that starts session 1289 using the service name " fubar.1"This requires that the terminal adapter implements more sophisticated analysis rules to recognize all types of messages for all types of protocols that can be received.A method to simplify the rules of analysis is to assume that each terminal message elaborates a map for a simple transaction type unless the format or indicate it in some other way. In this case, the processing exception can be used to simplify the rules of analysis. Figure 12C illustrates the processing of the analysis rules of a modality with additional detail. The procedure starts at step 1220 with the retrieval of the analysis rules 1221. There are rules for recognizing the various messages and a first rule is selected in step 1222. The start of the string is tested for its validity 1224 and if it does not match , the following rule is applied 1125 and the procedure starts again. Otherwise, the term of the string is tested for its validity 1226 and if so, it is tested for a match of 1227. If it does not match, then the following rule 1225 applies and the procedure is repeated. Otherwise, the length is tested for its validity 1228 and if a match 1229 occurs, then the message is acknowledged 1231 and the procedure is completed 1233, otherwise, the following rule 1225 is applied and the procedure is repeated. If there are no matches or the string is invalid, and there are no more rules 1230, then the message is not recognized 1232 and there is an error. The analysis for the string is completed in step 1233. Although this method requires a rule for each message, this does not offer certain advantages over the telephone mapping method. Specifically, it does not require the administration of different telephone numbers in the card readers in order to direct transactions to different locations. However, using any technique, the terminal adapter can automatically recognize a plurality of protocols used by different terminals and determine the appropriate message and server type.

Service discovery, parameter download and software The concepts of service discovery, parameter download and software download are intimately related. Service discovery is the procedure by which the terminal adapter discovers IP addresses for nodes that can provide additional information, such as the parameter file. The parameter file download involves receiving a file that contains configuration parameters. This file describes a configuration version number. The software download allows the new software to be downloaded to the terminal adapter and uses the address and other parameters obtained in the parameter file. The three procedures reside in the interaction of the terminal adapter with a network, although with different degrees of autonomy. The download of parameters or software in the terminal adapter facilitates the remote correction of software program errors, as well as deployment software to interact with the new services with the network. Terminal adapters can be updated without requiring manual replacement of terminal adapters or manual replacement of a portion of memory microprocessors, such as one or more read-only memory (ROM) microprocessors in the terminal or load adapters new software manual. The update can be done remotely, at convenient times, with minimal cost and interruption in service. The software update is controlled in part by the NOC. The NOC is the portion of the network that maintains the tables that associate each terminal adapter with its parameters. The initial load software of a terminal adapter of a modality comprises two separate programs called DLM (download program manager) and DLP (downloaded program). The terminal adapter can be programmed from the factory only with the DLM, and the DLP can be downloaded from the network after the terminal adapter is installed in the customer's premises. The DLP is normally stored in the non-volatile memory, although in the case of a non-volatile memory failure, the DLM with previously determined and immovable mode code allows recovery. In addition to the DLM, each terminal adapter is usually programmed from the factory with various parameters to allow you to initially connect to the network. As discussed above, these parameters typically include: the terminal adapter identification number, the secret or private encryption key, and the configuration service name. These parameters (except for the configuration service name) can be replaced by obtaining the values obtained dynamically, although in doing so, the programmed values are not deleted. For example, the terminal adapter that is absent that is a dynamically obtained service name stored in the non-volatile memory will use the default programmed value. The purpose of the DLM is to download and run the latest firmware version (DLP) that is stored in the non-volatile memory. The basic operation of the DLM of a modality is illustrated in Figure 13A, and was described in the following steps starting from a system reboot or initial startup. In Figure 13A, the procedure begins with turning on the terminal adapter 1350, which is the same as restarting the unit. From the first time it is turned on, there are no dynamic parameters stored in the flash memory (non-volatile). Therefore, only the values programmed by default exist. Using the service discovery procedure 1352 and the default configuration service name, the terminal adapter obtains at least one TCP / IP address for a client node to interact with. In step 1353, a TCP connection is established using the Ethernet to access the network or using the PPP over a dial-up telephone line. The terminal adapter is programmed with a default parameter file version (specifically, version zero, which indicates a default parameter file is present and means that all parameters are default values). In step 1354, the terminal adapter calls the configuration server parameter data. This is done by the terminal adapter (specifically, the DLM) that indicates its version number of parameter file to the network, and the network responds with a newer version followed by the parameter file. The network will only send the parameter data if the parameter file version of the terminal adapter is not the same as the version value stored in the server database. In this example, the network knows that the version sent by the terminal adapter (version zero) indicates a default parameter that is present in the terminal adapter, which indicates that no previous parameter download has occurred. If the terminal adapter already has the current version, the network will return the same parameter file version number. This informs the terminal adapter that it has the last parameter file and reduces the unnecessary transmission of the network data. If the terminal adapter has previously downloaded the parameters, even if they were adulterated, the parameters can be requested from the server that sends a version number zero in the packet. Any received data is stored in the non-volatile flash memory in step 1356. Next, in step 1358, the terminal adapter of this mode (using the DLM) verifies the current DLP version indicated in the parameter file and the compares against the version that is currently running. This is further verified to ensure that the data is not degenerate (i.e., free of errors as detected by a cyclic repeat check or a similar mechanism). If they are present and not degenerate, the DLM skips execution of the DLP application in step 1368, which then completes the procedure in step 1370. If instead, the DLP version is not current, then step 1360 is done to obtain the most current version. The terminal adapter retrieves an address from the parameter file and connects to the IP address for the purpose of performing a file transfer using FTP in step 1360. The terminal adapter then downloads the most recent DLP program in step 1362 If the download is not successful, in step 1364, then it restarts itself in step 1366 and repeats the procedure. If the download is successful in step 1364, then the new DLP program is executed in step 1368 and the procedure is completed in step 1370. The DLP program is the main application program that runs in the terminal adapter and performs the financial transaction processing and interaction. It uses the same parameters (see Figure 13B) as it is used by the DLM. The DLP can, however, have a different service name based on a dynamically obtained value, as the DLM procedure uses the previously determined and unmovable mode code value in the firmware. Advantageously, the DLP periodically checks if a more current parameter file exists, and if any parameters have changed or a new DLP is needed, the DLP performs a restart and the procedure is repeated as described above. Therefore, the DLM only performs a parameter file call, obtains the DLP, and then executes the DLP. The DLP then performs the so-called parameter file periodically. Only if the DLP resets the terminal adapter, the DLM executes itself. However, in this case, the DLM will observe that various parameters dynamically assigned are present in the flash memory and will use those values on the embedded values, skipping some of the steps identified above. Therefore, obtaining the new parameters and the new application code are intimately related, although there is the ability to download new parameters without having to download the new application code. Once the DLP is running, it will check periodically with the network, to verify if it has the most current version of the parameter file. The network responds by downloading a new parameter file when a newer parameter version is appropriate. A parameter in the file is an indication of a new DLP, which activates the DLP to initiate a file transfer. In this way, the network can control the loading of new parameters and software. The content of the parameter file of a modality is illustrated in Figure 13B. The first parameter in the file is the 1300 configuration version. This value indicates the current parameter file version that the terminal adapter has stored in memory. This could incorporate a time stamp to signify the latest version obtained.

The terminal adapter periodically searches the network to find out which current version the terminal adapter is running. If the network requires a new parameter file to be downloaded, it returns the current present version in the terminal adapter. Otherwise, the NOC returns a most recent parameter file version value, as well as the complete parameter file. In addition, the NOC can append management commands to control the terminal adapter that tells you to reset or activate the communication path switch. The frequency with which the terminal adapter verifies, the configuration version 1300 is determined by the configuration call interval 1301, usually expressed in seconds. This parameter is set to keep checking the terminal adapter for its parameter file version every hour or so, although larger or smaller time intervals can be used. Because the download of the new code suspends the normal operation of the terminal adapter, the terminal adapter can dispense with a periodic download, particularly if there are financial transactions in progress. The "maximum hop configuration register" 1302 indicates the maximum number of times that the terminal adapter can skip the request of the current parameter version. This value should not be exceeded by the terminal adapter regardless of the number of pending transactions. Periodic verification of a new parameter file version also works as a "heartbeat" indication of the terminal adapter for the network. The node that receives the parameter file requests to send the indication to the NOC, allowing the NOC to update its status boxes for that terminal adapter. Accordingly, receipt of a parameter file request by a terminal adapter indicates to the NOC that the terminal adapter is functioning. If the terminal has not requested its current parameter file version and the maximum hop interval is exceeded and has not initiated any transaction, then the NOC knows that the terminal adapter is not working. In such a situation, the NOC may initiate another procedure, such as issuing a notification to a previously defined destination in a previously defined manner for that terminal adapter. For example, the notification may be an email to a network administrator associated with the business entity that operates the terminal adapter identifying malfunction of the terminal adapter. Alternatively, the NOC could initiate a page, a pre-recorded phone call, or send an alarm message to a system, file, terminal or printer at the NOC. In this way, the NOC can react proactively to a terminal adapter that is not working. Similarly, the network can also monitor the use of the transaction, errors or other conditions and report them to the NOC, which initiates a similar notification. If software download is required based on an updated binary image name (DLP version number), the terminal adapter will initiate the request using the file transfer protocol (FTP), a well-known means for transferring files over the Internet. The address to prepare the request is obtained from the parameter file, as well as the required identification and security information. The FTP 1330 information comprises a URL, port number, username and password. The user name identifies the terminal adapter and an alternative mode could use the terminal adapter identification number. The password data authenticates the user as being authorized to receive the binary DLP file. Because FTP information is transferred without being encrypted using a TCP / IP connection for the terminal adapter, other modalities are described providing greater security. One method is to communicate a "challenge" based on a random value for the terminal adapter. The terminal adapter concatenates the challenge value with its secret key and calculates a digest message value 5 to determine a password. The terminal adapter sends this value to the network that has compared a similar value based on the knowledge of the network of the secret key of the terminal adapter. If the two values match, the terminal adapter is authenticated. Another variation to ensure secure file transfer is to use the secure data transfer service of the network. Specifically, a session transaction is used to communicate the file in an encrypted form. The terminal adapter and the network use the same encryption methods to pass the transactions that originate from a terminal to a server. The various authentication and encryption schemes can be used to perform the file transfer to an authenticated terminal adapter, such as using secure FTP procedures. The parameter file of Figure 13B also includes other parameters, including communication parameter information 1303, binary file features 1304, service discovery information 1305, primary communication information 1307, and support communication information 1309. Communication parameters 1303 indicate the type of "back end" interface currently used by the terminal adapter (e.g., Ethernet, secondary ISP, etc.). This value is included by the terminal adapter with each parameter file call request and indicates to the network the current network interface used by the terminal adapter. In this way, the network has the ability to monitor the state of the communications path of each terminal adapter. Other information includes the binary image file features (DLP program) 1304 which includes name, size, and error verification information that the terminal adapter must currently be using. The service discovery information 1305 indicates to the terminal adapter where terminal transactions should be directed, usually in the form of a URL. In turn, the client node in the network creates the map of the server name for a URL, which in turn is resolved using the DNS service within an IP address. In this way, the current IP addresses are "hidden" from the terminal adapter, allowing the network to make changes in the network transparently. This could be accomplished in a similar way, by providing the terminal adapter with a URL, although if the terminal indicated a unique URL, then all traffic must be routed to that single point of interconnection. Because the client node makes service maps for a URL, the client node can select one of several URLs based on geographic location, load capacity (for example, transaction processing capacity), or other aspects of network administration. In this form, the various server processors connected to separate nodes can be used to provide uniform transaction services for the terminal adapter. Additionally, this method never "exposes" server network addresses and thus provides added security and flexibility. The parameter file also contains the primary communication path information 1307, which includes the telephone number of the primary ISP and any associated modem commands (this is required only if the primary access is by dialing), identification information and password. The additional control information corresponding to the PPP configurations is included. Similarly, support communications path information 1309 is provided.

Operation illustration The general operation of the system is illustrated in Figure 14, which is a mode and illustrates a sub-group of elements that may be involved during normal operation. A card reader 2 is connected to a terminal adapter 14, wherein the terminal adapter has access to the Internet 26 via a primary communication interface 16. The terminal adapter also has a secondary communications interface 22 using a POTS telephone line 19a, connected to the telephone network 24 The terminal adapter is turned on and determines that it does not have a current application program loaded. It examines your default service discovery address information, which is programmed into the terminal adapter at the time of manufacture, and it uses this information to call an updated service discovery address. The terminal adapter then uses this information to synchronize and authenticate itself for the network. After this has happened, it uses a simple transaction to obtain a given service name in a dynamic way where it seeks to obtain a current parameter file configuration. A parameter in the file indicates the current software code that must be present and the terminal adapter determines whether to initiate a file transfer to obtain the current software. The information is then downloaded using the FTP address information in the parameter file.

Once this is accomplished, the terminal adapter is ready to handle terminal transactions. It synchronizes its transaction counter (if required) with the client node 25a and is authenticated by the client node using the techniques mentioned above. The authentication procedures also provide a clue to the terminal adapter by allowing adequate encryption and decryption of the transaction information. Once completed, the terminal adapter is ready to process transactions from the card reader 2. In this illustration, upon detection of a card slip, the card reader 2 initiates a telephone call and the terminal adapter emulates the necessary telephone signals, in such a way that a connection is established between the card reader and the terminal adapter. From the card reader's perspective, it seems to have established a phone call. The terminal adapter searches for the card reader using an ENQ message (for example, ASCII ENQ character) to request a response message. Upon receipt of the response message, the terminal adapter analyzes the message and selects the appropriate protocol to interact with the card reader. The terminal adapter also selects an appropriate service name that identifies a target server processor and a transaction type, which is a simple transaction type in this illustration.

Continuing with the illustration, the terminal adapter constructs a map of the transaction for a simple transaction protocol over an established TCP / IP connection and sends the message to the client node 25a. The client node processes the transaction to ensure that the transaction is allowed, synchronized, authorized, free of error and determines the appropriate node to which to send the request. This decision is based on the server name selected by the terminal adapter in the simple transaction protocol. The client node selects a route to send the transaction based, in part, on the service name, link capacity, configuration, and processor load. Assuming that it is sent directly to a service node 25b, the service node 25b then sends the transaction to the financial transaction processor 36 according to the protocol used to interconnect the server 36 and the service node 25b. The server and the service node are directly connected by means of a private line 34. The message is normally decrypted before being communicated to the server. The server receives the card authorization request, responds and the response is returned to the service node which normally encrypts the information and routes the response back to the client node 25a, subsequently to the terminal adapter 14 and finally to the card reader 2. This illustrates some aspects of a procedure of normal card authorization. Assuming now a failure associated with access to the Internet in the primary communications path using the primary network interface 16 (for example, the connection has broken down), the terminal adapter recognizes the failure by various means (for example, lack of response in the TCP / IP layer or loss of electrical signals in the physical stratum). The terminal adapter retrieves the secondary communication path parameters from its parameter file in the non-volatile memory, and initiates a dial-up connection for the ISP using the telephone number, as well as the appropriate identification and password information. Referring to Figure 14, the dial-up connection is moved from the telephone line 19a through the telephone network 24 and then by means of an alternative connection 19b to the client node 25a. The reached client node may be the same or different from one of those previously associated with the primary communication path. The terminal adapter must again synchronize the transaction counter, identify itself and authenticate itself before proceeding with transaction processing. The terminal adapter also updates its internal communication path status box and the LED status indicators, accordingly. Because the client node is aware of the establishment of the primary communications path, it notifies NOC 29 of the failure. The NOC then updates its status boxes and subsequently notifies the appropriate systems and / or personnel that the primary connection is broken. Periodically, the terminal adapter sends a "test" message over the Ethernet interface using the primary communication path to determine if it is functional. In this illustration, the terminal adapter uses an Ethernet to access the Internet in conjunction with the primary communications path and dial-up access to the Internet in conjunction with the secondary communications path. Because separate physical access methods are used, the terminal adapter can send a "test" message to determine if access to the Internet using the Ethernet access method is restored while using dial-up access to complete the transactions. This scheme must be modified if a single telephone line is used to establish a first connection using a first telephone number for the primary communication path and a second connection using a second telephone number for the secondary communication path. This is because the primary communications path can not carry a test message while the telephone line is used to support the secondary communications line. Of course, more sophisticated telephone services such as ISDN allow two connections over a telephone line, as do other telephony-based services. Normally, only one communication path can be operated using a single telephone line and the NOC will indicate, in response to a parameter file version request, that the problem causing the primary communication path to be inoperable has been corrected and that the terminal adapter must move the switch back to use the primary communications path. If a response is received at the primary communication path access using the Ethernet, this indicates that the communications path is restored. The terminal adapter moves the return switch to transport transactions over the primary connection. Of course, before transporting the transaction request, the terminal adapter must first synchronize and authenticate itself on the primary communications path. Therefore, the NOC is aware of when the change of the return switch occurs. The terminal adapter also updates its communications status visually using the LEDs, in order to facilitate the local diagnosis of the communications status. The terminal adapter updates its operation status tables corresponding to the primary and secondary communication paths. Periodically, the terminal adapter 14 requests from the client node 25a which version of the parameter file must be executing it. This is achieved by using a simple transaction request message that includes the terminal adapter identification number and the communication path status. The client node sends this message to the NOC. As a result, the NOC is not aware of the operation status of the terminal adapter. The NOC responds to the client node with a parameter file version number, and the client node sends the parameter file version number to the terminal adapter. Assuming that the version number in the response matches the version number in the terminal adapter, the terminal adapter continues to operate normally. If the NOC responded with a newer version number, this will indicate that at least one parameter in the file has changes and will also send the parameter file. The terminal adapter will examine the parameter file and if the DLP binary image name was different, the terminal adapter could call the current software, load it and then execute it. In this way, the terminal adapter has the ability to automatically interconnect a variety of terminal types, which can implement various protocols based on the destination server. The terminal adapter in conjunction with the network ensures that a reliable and secure communications capability is provided between the terminal and the server. If the primary communication path fails, the terminal adapter uses a secondary communication path and automatically restores the primary communication path when it is available. The NOC is aware of the operating status of each terminal adapter and provides alarm notifications as appropriate. Additionally, by means of the client node that prepares the service name map associated with the transaction request for a particular service node, the network has the ability to route the traffic to a selected server based on various conditions. In this way, the terminal adapter operating in conjunction with the nodes 25 has the ability to provide a network service oriented to a versatile and flexible transaction oriented. Many modifications and other embodiments of the inventions that are set forth in the present description will come to the mind of one of ordinary skill in the art to which these inventions pertain which has the benefit of the teachings presented in the foregoing descriptions and the associated drawings. Therefore, it should be understood that the inventions are not limited to the specific embodiments described and those modifications and other embodiments are intended to be included within the scope of the appended Claims. Although specific terms are employed in the present description, they are used in a generic and descriptive sense only and not for purposes of limitation.

Claims (39)

NOVELTY OF THE INVENTION CLAIMS

1. - A terminal adapter that interacts with a plurality of financial transaction processing terminals to a network, characterized in that it comprises: a plurality of terminal interfaces, wherein one of the plurality of terminal interfaces is configured to receive a first message from transaction request formatted according to a financial transaction format defined from one of the plurality of financial transaction processing terminals having an integrated magnetic card reader and initiating the first transaction request message in response to reading a card; and a processor that receives the first transaction request message, the processor is configured to analyze the contents of the first transaction request message based on the defined financial transaction format, generate a second transaction request message that is based on As part of the content of the first transaction request message, the processor determines a state of a first communication path associated with a first network interface stored in a communications path status box in a memory, wherein the processor determines the state based on previously received processing messages that are associated in a transaction protocol layer, sending the second transaction request message using the first communication path if the state of the first communications path can be operated.

2. The terminal adapter according to claim 1, further characterized in that the first network interface is based on an Ethernet protocol and the second communication path is associated with a telephone connection using a second network interface connected to the network. a telephone network.

3. The terminal adapter according to claim 1, further characterized in that the first network interface is connected to a telephone network using a telephone connection and the second communication path uses a second telephone connection associated with the first network interface. .

4. The terminal adapter according to claim 3, further characterized in that the first and second telephone connections do not exist simultaneously.

5. The terminal adapter according to claim 1, further characterized in that the second transaction request message additionally comprises a terminal adapter identification number.

6. The terminal adapter according to claim 1, further characterized in that the second transaction request message additionally comprises an error detection data field.

7. The terminal adapter according to claim 1, further characterized in that the second transaction request message is encrypted using the information derived from a synchronization response message

8. The terminal adapter according to claim 1 , further characterized in that one of the plurality of terminal interfaces is one of the group of a telephone interface and a serial interface.

9.- The terminal adapter in accordance with the claim 1, further characterized because the financial transaction protocol is the VISA-II protocol associated with the use of credit or debit cards.

10. The terminal adapter according to claim 1, further characterized in that the processor further determines the address of the server transaction processor to process the second transaction request message using a telephone number received at the terminal interface to have Access to a box that contains the phone number associated with the server transaction processor.

11. The terminal adapter according to claim 1, further characterized in that the processor further determines a server transaction processor to process the second transaction request message by analyzing the first transaction request message using the analysis rules to identify an address for the server transaction processor.

12. The terminal adapter according to claim 1, further characterized in that the second transaction request message additionally contains a transaction counter used to synchronize the second transaction request message with a connected network using the first or second one. Network interface.

13. The terminal adapter according to claim 1, further characterized in that it additionally comprises a memory that stores a first address obtained by the terminal adapter requesting a plurality of addresses from the initialization of the terminal adapter, where the first address is additionally contained in the second transaction request message.

14. The terminal adapter according to claim 1, further characterized in that it additionally comprises a memory that stores a parameter file version number, wherein the parameter file version number is further transported by a third message of transaction request.

15. The terminal adapter according to claim 1, further characterized in that the processor has the ability to send a third transaction request message indicating a parameter file version number of a first parameter file currently stored in a memory of the terminal adapter and receives it in response to a second parameter file that is stored in the non-volatile memory.

16. The terminal adapter according to claim 15, further characterized in that the second parameter file includes a software version parameter, and wherein the processor has the ability to initiate a file download request, receive the file , store the file in memory and execute the contents of the file based on the value of the software version parameter.

17. A system for maintaining a state in a network operations center of a terminal adapter connected to a transaction network, characterized in that it comprises: a network operatively connected to the terminal adapter adapted to receive a first indication message of status from the terminal adapter, the first status indication message includes a terminal identification number, a first parameter file version number, and a first communication path status indicator; and a network operations center operatively connected to the network adapted to receive the first status indication message from the network, the operation center of the network comprises a processor and a memory, the processor determines a time associated with the receiving the first status indication message in a status box and starting a stopwatch, and the memory stores the status box associated with the terminal identification number.

18. - The system according to claim 17, further characterized in that the state box stored in the memory additionally comprises a second communications path indicator associated with the terminal adapter and the processor compares the first communications indicator with the second indicator of communication path and issues a notification message if the first communications indicator is different from the second communications path indicator.

19. The system according to claim 17, further characterized in that the processor further examines the first parameter file version number in the first status indication message and responds by sending a second parameter file version number in a response message to the terminal adapter.

20. The system according to claim 17, further characterized in that the processor further examines the first parameter file version number in the first status indication message and responds by sending a plurality of addresses in a reply message to the adapter of terminal.

21. The system according to claim 17, further characterized in that the processor further examines the terminal identification number in the first status indication message and responds by sending the authentication data in a response message.

22. - The system according to claim 17, further characterized in that the processor upon receipt of a second status indication message resets the status update timer.

23. The system according to claim 17, further characterized in that the processor issues an e-mail message to an address determined in part by the terminal identification number when the status update timer exceeds a defined amount.

24. The system according to claim 17, further characterized in that the processor exceeding a defined amount of the status update timer produces a message to be displayed on a computer monitor comprising contact information including a telephone number.

25. A method for maintaining a status indication in a network operations center for a terminal adapter connected to a network node, characterized in that it comprises the steps of: receiving a first status update message from the terminal adapter by the network node indicating a first parameter file version number stored in the memory of the terminal adapter, wherein the first status update message additionally includes a terminal adapter identification number and a first path status of primary communications; transmit the first status update message from the network node to the network operations center; receive the first status update message in the network operations center and examine the terminal identification number and the parameter file version number; and record a status indication and record the time in a status indication box in the network operations center, where the status indication frame associates the status indication and records the time with the identification number of the adapter. terminal.

26. The method according to claim 25, further characterized in that it additionally comprises registering the first primary communication path status indicator in the status indication box.

The method according to claim 26, further characterized in that the network operations center, after receiving the first update message, compares the first primary communications state with a second primary communications state stored in the memory and issues a notification message if the first primary communication state is different from the second primary communication state.

The method according to claim 25, further characterized in that it further comprises the step of downloading the network operations center to the terminal adapter a second parameter file version number and a parameter file in response to receiving a first status update message.

29. - The method according to claim 25, further characterized by additionally comprising the step of downloading through the network operations center to the terminal adapter, a plurality of addresses in response to receiving a first status update message.

30. The method according to claim 25, further characterized in that it further comprises the steps of: computing the first authentication data in the network operations center; and downloading from the network operations center to the terminal adapter the encryption data used by the terminal adapter to authenticate the terminal adapter for the network. The method according to claim 30, further characterized in that it further comprises the steps of: receiving in the network operations center seconds the authentication data sent by the terminal adapter processed in part using the encryption data; and compare the first and second authentication data. 32.- The method according to claim 31, further characterized in that it further comprises the step of: sending a response from the network to the terminal adapter indicating that the terminal adapter is authenticated if the first and second authentication data are equal . The method according to claim 25, further characterized in that it further comprises the steps of: initiating a status update timer in the network operations center associated with the terminal identification number; resetting the status update timer if a second status update message is received associated with the terminal identification number or a transaction originating from the terminal adapter is detected; determine if the status update timer exceeds a defined limit; and issue a notification based, using in part, the information indicated in the status indication box if the status update time exceeds the defined limit. 34.- The method according to claim 33, further characterized in that the notification is an email sent to an address associated with the status indication box. The method according to claim 33, further characterized in that the notification is a telephone call to a telephone number associated with the status indication box. 36.- A terminal adapter comprising: a plurality of dial-in input ports, each input port incorporating a telephone connector and a cable that simulates an ordinary telephone service interface (POTS) for interfacing a point-of-entry device selling using an asynchronous communications protocol based on the VISA-II protocol, each dial-in port is also capable of receiving a first message sent from the point-of-sale device that is generated in response to reading a credit card; a first communication path using a first interface for interfacing the terminal adapter with the Internet using in part an IP-based communication protocol; a second communication path using a second interface for interfacing the terminal adapter with a telephone network; the second interface is operatively connected to a modem internally incorporated in the terminal adapter; and a processor, which is operatively connected to receive the first message from one of the plurality of dial-in ports, the processor generates a second message addressed to a credit-card authorization processor, the processor directs the second message and be to the first communication path, if it is determined that it is operationally based on information that is in a communications path status box, or to the second communication path, if the first communication path is destined to remain inoperative. 37. The terminal adapter according to claim 36, further characterized in that the second communication path uses a point-to-point protocol (PPP) to communicate over the telephone network with the credit card authorization processor. 38. The terminal adapter according to claim 36, further characterized in that the first communication path uses the Ethernet to communicate over the Internet with the credit card authorization processor. 39. The terminal adapter according to claim 36, further characterized in that the IP-based communication network is based on a TCP / IP protocol.