MXPA99003748A - Fail-safe event driven transaction processing system and method - Google Patents

Abstract

The system and method of the present invention provide a fail-safe event driven transaction processing for electronic commerce applications. The system includes at least one system node having multiple entities and processes for communicating with outside devices, such as ATMs and financial institutions. Multiple links are provided between the system nodes to provide flexible routing in case of down nodes. A configuration database accessible by the processes provides a backup entity or process for each entity and process. A system monitor resides at each system node, monitors the operational status of each node and communicates the status to other nodes.

Description

SYSTEM AND METHOD OF TRANSACTION PROCESSING IMPULSED BY EVENT AND INSURANCE AGAINST FAILURE TECHNICAL FIELD OF THE INVENTION This invention relates generally to the field of computer systems. More particularly, the invention relates to a system and an event-driven transaction processing method and failures insurance.

CROSS REFERENCE TO RELATED REQUESTS This patent application is related to the co-pending application of the United States of America, series No., entitled SYSTEM AND METHOD OF DISTRIBUTED ONLINE DATA COMMUNICATIONS, filed on 1996.

BACKGROUND OF THE INVENTION Figure 1 is a simplified block diagram of a conventional electronic funds and information transfer (EFIT) system 10 using a conventional centralized communication system 11 which allows a number of application programs 12 to communicate to localized devices 14 located remotely of them.

For example, outdoor devices 13 may include one or more ATM machines (ATMs) 14 and financial institutions 15 in an electronic funds and information transfer system (EFIT), coupled through the centralized communications system 11, to a manager application program 16, a device manager program 17, and a funds transfer authorization program (AUTH) 18. The centralized communications system 11 may also be coupled to a daily program and database 19 to save each transaction, and a host interconnection process 20 to interconnect with financial institutions 15.

In the operation, when the transaction message for a cash withdrawal is generated in an automated teller machine 14, for example, it goes to a centralized communication system 11, which sends the transaction message to the device driver 17. The device driver 17 then extracts the information from the transaction message and constructs a message having a predetermined internal format that is understood by the application programs 12 and by a centralized communication system 11. This reformatted message is then sent back to the system of centralized communications 11 which then sends the message to the director 16. The director 16 determines the destination for the message and sends the message back to the centralized communications system 11 for its delivery to the recipient. The destination can be an authorization program 18, which can access a database 21 to determine if the transaction is authorized. The authorization contained in a return message is then sent to a centralized communication system 11 for delivery to a journal 19 to record the transaction and then it is returned to a device driver 17, again through the centralized communications system 11. The device driver 17 then converts the authorization message to an external format and sends it to the automated teller machine from which the transaction originated through the centralized communication system 11. The automated teller machine 14 then dispenses the Required funds or deny the transaction according to the information contained in the authorization message.

Where a transaction is required to obtain authorization from a financial institution 15, the authorization program 18 will then send the transaction message to the interconnection program 20 through the centralized communication system 11. The interconnection program 20 then reformats the message in one which is understood by the authorization system in the financial institution 15, and sends the reformed message to a centralized communications system 11 for delivery to the destination financial institution for authorization. The financial institution it then generates an authorization message and sends it to the centralized communications system 11, which sends it to the interconnection program 20 for the conversion back to the internal format understood by the application programs 12 and the centralized communication system 11. The The reformatted authorization message is then sent to the device manager 17 through the centralized communication system 11 which then converts the message to the external format as described above to provide the authorization message to the automated teller machine that originated the transaction.

It can be seen from the above that all the messages communicated between the application programs 12 and the external devices 13 must go through the centralized communication system 11, which is the central controller. As the electronic information and funds transfer system becomes larger and larger to accommodate more and more automated teller machines and financial institutions, the centralized communications system 11 becomes a bottleneck that slows down the response time of transaction and message delivery. This is a critical problem because transactions of this type typically require an almost instantaneous response time, bank customers do not want to wait more than 30 seconds for the automated teller machine to respond to their cash withdrawal requests.

In addition, because all communications must go through the centralized communications system 11, a single point of failure of system 11 will cause a disaster for the entire electronic information and funds transfer system and disable all ATM machines. in the system.

The centralized communication system 11 also has a further disadvantage of being required to recognize the message format in order to determine the destination of the message for management purposes. Therefore, the message format can not be easily changed without impacting most of the main functions of the system 11.

The centralized architecture of the system also means that its growth is limited by the capacity of the system 11. The system can not be easily expanded to accommodate an order of magnitude of more users without an expensive addition of computing platforms and other equipment components. In the computer industry, this expandability feature is called "escalation." In addition, a centralized system such as system 11 is not portable to other computing platforms, so that its placement is restricted to a single platform.

SYNTHESIS OF THE INVENTION Therefore, there is a need for an event-driven transaction processing system that overcomes the disadvantages associated with a system based on centralized communication systems described above.

In accordance with one aspect of the present invention, a failsafe event driven transaction processing system has at least one system node having a plurality of application processes for processing transactions initiated by a plurality of external devices. The system is based on a data communications system that supplies a plurality of message and service entities to the plurality of application processes for directing, retransmitting and receiving messages to and from one or the other. In addition, a system configuration database is included to store each entity and process and their respective backup entities. A system monitor which resides in each system node monitors and communicates the operational status to the system node to other system nodes.

In another aspect of the invention, a method for an event-driven transaction processing system records a system configuration database, a logical identifier for each node in the system, an address physical and a state of it. In addition, a backup node is optionally designated for each entity in the system configuration database. Each node puts together all the other nodes in the system for its status and its understanding of the state of the other nodes in the system. In response to the bridging process, the detection of a dropped node, the processing load carried by the dropped node is directed to the backup node.

In still another aspect of the invention, a transaction processing system includes at least one system node having a plurality of processes for communicating with a plurality of external devices. A configuration database is accessible by the processes, which store the logical names of the processes and the external devices and their corresponding physical addresses. A system library also provides a plurality of routines for the processes to transmit and receive messages to and from one to another. At least one application process uses the processes and the system library for communication with external devices to process transactions.

BRIEF DESCRIPTION OF THE DRAWINGS For a better understanding of the present invention, reference is now made to the accompanying drawings, in which: Figure 1 is a simplified block diagram of a conventional electronic line communication system using a centralized communication system.

Figure 2 is a simplified block diagram representation of a distributed online data communication system constructed in accordance with the teachings of the present invention; Figure 3 is a block diagram of the external monitor interconnections of the example system to a control point, the operation system and the applications; Figure 4 is a diagram of an example registration structure in the system configuration file; Figure 5 is a diagram of an example communications configuration; Fig. 6 is a simplified diagram of a distributed online data communications system that is being used in an example electronic information and funds transfer application; Figure 7 is a diagram showing the architecture and process flow of the line operators according to the teachings of the present invention; Figure 8 is a diagram of an example multiple layer architecture of the distributed online data communications system of the present invention, - Figure 9 is a diagram of an exemplary system message format according to the teachings of the present invention; Figures 10A and 10B are diagrams of example message structures used between a control point and other processes; Figure 11 is a diagram of an example message structure used between line managers and applications; Fig. 12 is a block diagram illustrating a database synchronization process according to the teachings of the present invention; Figure 13 is a block diagram illustrating an example process for detecting and handling the general failure in a node; Y Figure 14 is a block diagram illustrating an example process for processing the backup and restoring the primary node.

DETAILED DESCRIPTION OF THE INVENTION Preferred embodiments of the present invention are illustrated in Figures 2-14, like reference numbers being used to refer to like and corresponding parts of the various drawings.

Referring to Figure 2, a simplified block diagram of a distributed online data communication system 22 is shown. The distributed online data communication system 22 can support application processes by implementing a variety of event-driven applications, including electronic fund and information transfer (EFIT), point of sale (POS), electronic health care and benefit transactions, or any message-based transaction processing application. System 22 includes a number of processes, including a system monitor and its backup 24, a control point 26, a command installation 28, line handlers 30, an event keeper 32 and a diagnostic follower 34. system 22 further includes a system library 35 which contains a set of routines that is used by all system processes and all application processes 36.

The system library routines 35 provide interconnection procedures for carrying out basic functions and are preferably linked or compiled with the application and system processes. Figure 2 illustrates this coupling between the system library routines 35 and the system monitors 24, the control point 26, the line drivers 30, the guard 32, the follower 34 and the application processes 36 as an open pipe to distinguish it from I / O as in the centralized communication system 11 described above. System library functions include sending, receiving, addressing, queuing, saving and tracking messages. System library 35 enables application processes 36 to communicate with one another and with the outside world. The system library 35 preferably maintains a private data structure in the memory that contains the necessary information to carry out the address and receive services for the application processes. Each application process has its own copy of the library data. Therefore, each application process also has its own point of view of the processes with which it is communicated. This library data is dynamic, depending on the links to other processes that the application creates and discards. Library data can include environmental variables, buffers to read in messages, and a table listing all open processes that can be sent and / or received. messages. In addition, there are queues containing messages that will be sent to each destination.

System 22 is especially valuable for event-driven applications. A message arrival, a time out, a message failure and the I / O termination are examples of events. To recognize an event, an application calls a system library procedure RECEIVE. The system library 35 performs specific operation system and environment tasks to determine what event it is, then it gives a value for the type of event and the data associated with the event to the application. The following algorithm shows a main example circuit of an application program that uses this method: While there is no time to stop Call RECEIVE Toggle on TYPE OF EVENT if MESSAGE, process message if TERMINATION, process termination if FAIL, process fails if TIME OUT, process timer in other way, process unknown event end switch terminate while Environmental specific tasks can include unlocking a message or checking the queues for more messages to be sent. The specific tasks of the operating system may include interconnecting with the operating system to receive messages from another program or interpreting an operating system error. These tasks are carried out transparently for the applications 36.

System monitor 24 is a process running without stopping in order to monitor all system processes and reboot whatever has been dropped, including control point 26. System monitor 24 can collect processes that it monitors for information from state and receive acknowledgments of them. As also shown in Figure 3, the system monitor 24 accesses a system configuration database 37 through calls from system library 48 for the configuration of process information. To operate the system monitor 24 without stopping, a backup process 24 'is provided which runs in parallel with the monitor of the system 24. The system monitor 24 also uses the operation system calls 49 to create new cases of processes of application, stop a case of an instance of an application, and to receive notifications of failure of instances of application instances. The system monitor 24 preferably monitors critical information points and transactions for the backup process 24 '. If the primary system monitor fails, the backup process takes this and continues from the last verification point. Operators can control the system monitor 24 through the control point 26 through the command installation 28. The system monitor 24 can be configured to monitor only the processes in its own node 38, to also monitor the processes in one or more of other selected nodes 40, or to monitor all processes running on all nodes in the system depending on the application.

As shown in Figure 2, a system configuration database 37 contains data on all processes in system 22, which may include logical names, physical addresses, backup process identities and other properties. . The contents of the system configuration database 37 can be modified by commands from the command installation 28. The system configuration database 37 can be remotely accessed, duplicated at other sites, or distributed through multiple sites, depending on the application needs.

The system configuration database 37 contains several records, wherein each record contains information about an entity in the system 22. As shown in figure 4, the information in a record about an entity may include a type entity 23 , a logical name 25, a physical name 27, and 29 unique properties for the entity type. Entity type 23 is the type of record or entity; the logical name 25 is the name by means of which the applications access this entity, - the physical name 27 is the system name and the location of the entity; and properties 29 are information specific to the type of entity that is being defined in the record. Where desirable, the properties 21 can provide information about the entities that serve as backups for each entity.

There are several different entity types in the system 22, including but not limited to: SYSTEM, PROCESS, LOGICAL UNIT, PHYSICAL UNIT, LINE, USER, TERM, RECORD, ROUTE, NETWORK, COMMAND, NODE, GROUP, PARAMETER, AND ASSIGNMENT. Each type of entity is described in more detail below.

The SISTEMA entity contains information related to a site or node in the system. Therefore, a system configuration database 37 may include several SYSTEM entity records containing communication paths and other information related to all nodes in the system that can communicate with each other.

The PROCESS entity contains information that defines a process for the distributed online data communications system. An application that runs on the platform is mentioned by its logical name. The physical name includes the process identifier that runs. The properties section defines the location of the object and the resources that a process uses and provides information that allows the process that runs to be created.

The entity of LOGICAL UNIT (LU) is the most elementary form of a communications circuit. This describes the tail end for a particular device. When a process refers to a LOGICAL UNIT by its logical name, the message is directed to its line manager 30. The LOGICAL UNIT has links through the optional PHYSICAL UNIT (PU) entities that end in a LINEA entity ( L) as shown in figure 5. Line manager 30 (figure 2) uses the hierarchical information of LOGICAL UNIT, PHYSICAL UNIT, LINE, to reach the destination device address. The The physical location of the device is described by the physical names of the LOGICAL UNIT, PHYSICAL UNIT, and the LINE entities that are linked together. Therefore, the properties of the logical unit include the name of the line handler and the links. Other properties of the logical unit entity define the protocol of the LOGICAL UNIT and the protocol options. A logical unit can be used to define a communication path for an external source such as institutions 45 and automated teller machines 44 or other distributed online data communication system nodes 40 (Figure 2).

The PHYSICAL UNIT (PU) entity is an entity that allows a line designer to create a collection of one or more logical units. It is the logical division of a LINEA entity. the communication configuration often naturally follows the hierarchy shown in Figure 5. A physical unit entity is a means of indicating that the hierarchy takes advantage of the available bandwidth in communications. The logical name of the physical drive is specified to access it (such as a logical drive link string). The physical name contains address information to access a logical unit (a partial address). The properties include the protocol and a link to other entities that can be more physical units, but that must end in an entity in LINE.

The LINE entity defines a port on the physical equipment from which one or more multiple devices can be accessed through the communications circuit. The logical name of the LINE is specified by the logical units and the physical units linked to it through the link field. The physical name describes the name of the communication device or machine's port. The properties include the line handler program, the protocol and the protocol options.

When a line driver 30 receives a message for a logical unit, it has already chained the entity information together. A general algorithm for directing is used to access the port described in the LINE register, use the segment of the line described by the physical unit record (if present), and the address on the line unit record to transmit the message to the device at the end of the circuit.

The USER entity describes a valid user of the distributed online data communication system 22. This functions primarily as a security measure or for a saved access to the system. For terminals in secured area, it can be set that any user is valid. These terminals are defined in the system configuration database 37 as TERM entities.

The entity FILE defines a file for system 22 and its applications. It also has a logical name and a physical location. Accessing a file by a logical name allows the transparency of the machine and the location for a distributed system. An application accesses a file by specifying its logical name, the system library 35 (figure 2) and then determines the physical name and its properties and provides the access services for the information for the application.

The entity RUTA is a generic entity provided by the system 22 to be used by the application library (to be described below in conjunction with figure 6) or by the applications 36. In this type of record, a logical name is specified and a " The "related" handle is specified. The handler is a process entity. The handler process is an application programmed to recognize a message from the path source and process it accordingly. When an application indicates the route entity as a destination, the system library 35 automatically directs it to the handler process. This feature is useful when an application has a named command that is global for all processes in the system. This implementation from a global destination (by using a routing entity) maintains the generic system platform so that the System 22 does not have to know the specifics of an application and allows flexibility in the application.

The RED entity is a convenient means to describe the physical network that provides communications for a system. This does not affect the address but describes the apparatus that constitutes the distributed system.

The COMANDO entity allows an operator to make the user interconnection for the application of specific commands. A COMMAND entity consists of a logical name and a physical name (which is the command text), and the destination for the command. An example of such a command is when an application must have new keys for security. A COMMAND entity called CLAVES is defined in a system configuration file 37, which is used by an operator to inform the verification process to obtain new KEYS.

The NODO entity defines a computing node in the system 22. A computing node is a set of one or more physical processors tightly coupled. The configuration of a node is independent of the devices so that this can be a set of personal computers or a work station. Therefore, an application can be released from knowledge about this by accessing the logical name of the node. The properties of a node include a status indicator above or below that node. The entity in NODE is specified as a synchronized time node in the system entity. In this way, all transactions in the system 22, even when distributed through multiple nodes, can be synchronized for the same clock. The clock synchronization provided by the combination of the System registry configuration, with a time synchronization node and with a system library procedure called SYSTEM TIME.

The GROUP entity allows logical groupings of the entities in the system configuration database 37. This allows a necessary convenience to monitor and operate a large distributed system. When a group name is indicated for an operation, all the entities in that group are operated.

The PARAM entity allows variables in the environment for the application programs to be defined external to the program, so that these can be modified. A PARAM consists of a logical name and a value. When an application program requires an environmental variable, it invokes a system library procedure 35 which returns the value of the parameter. An example would be a PARAM with a logical name SECURITY on the ON value.

The ASSIGN entity is also used to describe the environment for application programs. This defines the external files for the program, so that they can be changed. An ASSIGN consists of a logical name and a file name or a record entity. When an application program requires a file to process it, it invokes a procedure from the system library 35 which returns the file name or the file entity.

Also shown in Figure 2 is the command installation 28, an interconnection for the operator or operators, and a control point 26, which is a controller and an administrator of the respective site or node of the system 22. The command installation 28 it can be in communications with a data input and an display device 42, such as a terminal, a computer, or a workstation, and can be linked through computer networks or telecommunication lines to the control point 26 The command installation 28 can provide a textual and / or graphical user interface for operators to receive commands and display system states.

The primary function of the control point 26 is to handle the requests from the command installation 28 to configure, monitor and control the entities in the local node.

This is the only maintainer of the configuration database of the system 37. The control point 26 is in communication with all the processes in the local node and is the central command transmitter and the information collector that is to be returned to the command installation 28 for display. The control point 26 communicates with all processes ugh a flexible and extendable sample oriented message standard as indicated in Figures 10A and 10B; described in detail below, thus allowing interconnection with command installations on multiple platforms. The command installation 28 is responsible for formatting and presenting information entrusted by the control point 26 in a manner that is appropriate for the chosen platform in a textual and / or graphic display format. The command installation 28 and the control point 26 also work together to provide security against unauthorized access to the system as defined by the user entity records contained in the system configuration database 37.

Line handlers 30 are processes that are responsible for data communications with external devices, such as, but not limited to, ATM machines 44, banking institutions 45 and other nodes 40 of the online data communications system distributed 22. An automated teller machine 44 is defined for the purpose of the present invention, as a dedicated terminal having a data entry device and an exhibit screen that receives and processes requests for bank customer transactions such as cash withdrawals, deposits, balance inquiries, etc. Line manager 30 may be specialized to operate according to specific communications protocols, such as Bisync, X.25, TCP / IP, SNA, and others. In addition, line 30 handlers can include bridge processes for foreign systems. More than one line handler processor 30 may be running concurrently to provide communications to a greater number of external devices.

The event recorder 32 is an enrollment process which receives messages destined for a file 46 and can perform some filtering functions. The stored messages can be retrieved by entering the appropriate commands in the command installation 28 or at the operating system level. A system library process is provided to format the stored messages.

The follower 34 is a process that collects messages communicated between the selected processes in the system and stores them in a follower file 47. An operator can initiate the follow-up and select the processes, the type of messages, and other indicative parameters ugh the command installation 28 or at an operating system level. A system library process is provided to format the file followed. Afterwards, the stored messages can be retrieved from the file 47 by commands placed in the command installation 28.

Referring to Figure 6, there is shown a simplified block diagram illustrating the process flow of an event-driven transaction processing system to fail-proof example. Figure 6 specifically shows the process flow for an example electronic information transfer and exemplary application (EFIT) built on a distributed online data communications system 50 constructed in accordance with the teachings of the present invention is shown. The distributed online data communication system 50 can include multiple nodes located remotely from one another, across the country, the continent and / or the globe. For example, in a two-node system, node A may be located in Chicago Illinois and node B may be located in Plano Texas. In an electronic information and funds transfer system, node A and node B can represent regional processing centers.

When applied to an electronic funds and information transfer system, a transaction may be initiated by a transaction acquirer such as an automated teller machine 52 that is being operated by a customer bank, for example, wherein the automated teller is directly coupled to node A of the distributed online data communication system 50. The customer can, for example, initiate the transaction by inserting a card issued by a banking institution containing a bank card. unique card number and associated data relating to the customer's account. The client also enters the type of desired transaction, such as a deposit, a withdrawal, or a balance question, and the associated dollar amount, if required. The desired transaction of the customer, the card number, and the line and numbers / device names of the ATM machine are packaged in a transaction message having a first predetermined format and communicated to a line handler (LH 54) A set of system library (SL) procedures 60 is coupled to the line handler 54. The system 50 can be thought of as having a multi-layer architecture 70 as shown in Figure 8. The deeper layer, the communications layer 72, represents the data communications equipment, the lines and protocols used by line handlers 54 to communicate with external devices. On top of the communications layer 72 is a system library layer 74 which corresponds to the functions carried out by the game and library procedures of the system 60 and the databases used therein. The library layer of the system 74 provides messaging services that are independent of the apparatuses and of the communications protocol in the communications layer 72. Above the system library layer 74 is an application library layer 76 which contains the additional messaging services and databases specific to the application. The uppermost layer is an application layer 78 which includes the application programs for carrying out specific functions such as the electronic information and funds transfer. It can be seen that the system library layer 74 releases the application flaps 76 and 78 of the joint and a tight coupling to the apparatus and to the protocols of the communication layer 72 to provide an independent apparatus and laptop interconnection. Referring to Figure 6, the library layer of system 74 is shown as system library (SL) 60 procedures accumulated with all processes, including processes in the application of library layer 76 as well as processes in the library layer. application 78. System library procedures 60 can be coded so that they are compiled with the code of each process. Alternatively, the system library procedures 60 may be contained in a running time library that may be called by all processes.

In Figure 6, the line handler 54 receives a transaction message from the automated teller machine to the start the client a transaction. Referring to Figure 7, additional details of the line handler process 54 are shown. In Figure 7, the arrows show the process flow in common code (almond) 31 and a custom code 33 of the line handler process 54. A request is first received to operate on a logical unit, such as start, stop or transmit. The line handler operates on the common logic unit code 31 by first finding the logical unit in the state table, then calling the custom code 33 to execute the protocol dependent functions at appropriate points in the processing. The state table provides suspended / dropped / up status information about the entities and logical units and is part of a global set of information maintained by the common code 31. The custom code 33 of the line handler then modifies (if it is necessary) the message processing based on the protocol, and returns control to the common code 31. The common line manager code 31 then performs 1/0 for the device such as the ATM machine, at the calculated address. Alternatively, the 1/0 for the device can be carried out by the custom code 33. The particular ATM machine from which the transaction originates has a predefined destination or predefined device driver (DH) 80 for all messages of your transaction predefined in a system configuration 37 as in Figure 2. The device 80 resides the message and reformats the message in a second predetermined format that is internal to system 50 and shown in Figure 9.

Figure 9 provides an example format 90 for messages transmitted in a distributed online data communication system 50. The message format 90 includes a block handler 92 the sual can include the information about the data block that follows, such as the number of messages in the block, the relative offset for the beginning of the first message in the block, and the total number of message bits in the block. The block handler 92 may also include an identifier that identifies the data as a message having a format recognizable by the system 50. What follows the block header 92 is a system header 94 which may contain multiple fields. The system header 94 may include information such as an indiscriminate identifier of the message type, a source entity name, a destination entity name. All processes and databases in the system 50 are each assigned to a unique logical name or identifier. The logical identifier is assigned and used by the system library 60 to direct all messages and identify the source and destination of the messages. The system header 94 also includes an extension size, a size of a tasker, and an application data size. The extension size provides flexibility to extend the size of the system header by an optional extension field 94 if necessary. The application wise size indicates the size of the application header field 98, which may be used in any way by the application library and application layers 76 and 78 (Figure 8) and may be optional. The message format 90 also includes an optional variable length apsication sampler. The asterisk (*) appended to the message fields in Figure 9 indicates whether the fields can be optional. This can be seen that the sample message format is generic and allows different types of applications to use the system.

Figure 10A provides an example of a message using the format shown in Figure 9 to control the point application data. The message may have block header header 92, system header 94 and optional extension 96, optional application header 98, and optional application data 100. In addition, control point application data may include a number of sample identifiers (TKN ID), their respectable lengths (LEN), and the associated data. The message ends with an end sample (FIN TKN) and a length of 0 to indicate the end of the message. In practice, as shown in Figure 10B, to initiate a new process, the message may include a sample command (CMD TKN) with its length, and its associated data being the command of start process (STRT CMD). The following sample identifier is the entity sample (ENTITY TKN), its length and the database configuration information of the system configuration in relation to the entity or process that is being initiated. The sample command, the start command, and the entity sample can be integer values, alphanumeric strings, or other appropriate representations. Note that in Figure 10B, the optional fields 92/98 may be omitted.

Referring to Figure 11, an example message structure for communications between the line handlers and the application processes is shown. In the line manager application header part, a number of fields are used to provide data about the message. For example, the line handler application header may include a message type field to indicate whether the application data contained in the message is data or information related to a command. One or more time stamps can also be provided for statistical analysis and sronization purposes. An error code can also be contained in the headset of the linehead application to indicate the nature of the error that has occurred. In addition, an internal identifier used to identify the destination of the message may also be included.

Continuing the process flow shown in Figure 6, the device manager 80 calls a system library procedure called SYSTEM SEND to deliver the transaction message received from the line manager 54 to another process, the manager (RTR) 110. The director 110 is accessible to an automated teller database 112 that contains information about the acquirer network, the ATM machine card numbers and the owners of the respective financial institution of the bank cards, and of the networks of ATM machines that the respective bank cards have permission to access. Therefore, the direstor 110 sees the card number contained in the message and determines whether the customer can access the particular ATM network, and also obtains the logical process identifier, AUTH01, which can authorize the transaction in question. Having obtained the logical identifier of an authorizer (AUTH) 116, the director 110 calls APP SEND and specifies in the message that the authorizer of destination (AUTH-DEST) is AUTH01. The SEND APP can be part of the application of the library layer 76 (Figure 8) which provides a set of library procedures 114. The application library 114 then resides the message and sends the system to send with the destination AUTH01 . The SEND system recognizes AUTH01 as a local authorizing program 116, and delivers the message to the authorizer 116. The message may be queued until the authorizer 116 pulls it from the queue to receive it The queue resides in the private memory of the system library of the sending process.

The authorizer 116 then examines the message and accesses a database or card definition files 118 for the necessary information to determine - whether the requested transfer is authorized. - Authorizer 116 int generates an authorization message and calls APP send to deliver the message. The authorizer 116 may specify in the message one or more destinations for the message such as return and DEST journal, which specify that the message will be returned to the originator and will be saved by the appropriate journaling process. In a predetermined sampo in the message format (Figure 5) the additional logical destination entity names can be specified. Therefore, the authorizer 116 may include a journal (JNL) 120 as a first destination and the originator of the message as the second or next destination in the message. The application library (AL) 114, upon examining the message, resolves the first destination (DIARIO_DEST) as the journal 120 and writes the message to it. The journal 120 then records the transaction in a designated file in a database 122 and calls APP SEND with what was specified as the next destination (NEXT_DEST) in the message. The application library 114 resolves the following destination as the originator of the transassination message or the return destination (RET0RN0_DEST) which is the handler of the device 80. The application library then calls the SEND system to deliver the message to the handler of the device 80. The handler of the device 80 sends the message to the line handler 54, which then delivers the message to the automated ATM machine 52 The automated teller machine then acts on the received message either by carrying out the transaction or by denying the requested transaction.

In the above-mentioned scenario, a requested transaction is authorized at the same node, the node A: However, a requested transaction on node A may alternatively be authorized on a remote node, node B by communicating the transaction message. to node B. For example, when director 110 receives a message from device manager 80, and sees the card number in its database 112 director 110 obtains from the database 112 a logical identifier of the process he can authorize the transaction, for example NODEB.AUTH01. The director 110 then calls APP SEND to deliver the message. The application library 114 then obtains NODEB.AUTH01 from the message and calls SYSTEM SEND with this parameter. System library 60 records the name of the foreign system, sees the name of the system in system configuration database names held in memory for efficiency and operation 130 by calling a system library routine, and obtains the logical address of the communisation port for the node B and its line handler 132. The database configuration 130 preferably stores the logical names and the corresponding physical addresses of all the processes and equipment of the system. Operating in this way, the processes require only knowing the logical names of other processes with which they interact, and it is the function of the system library to keep track of the physical location or of the diressions and to ensure the adesuada delivery of the messages .

The system librarian 60 then append the actual or physical destination addresses to the system header 94 (Figure 9) in the message as the next destination (next-DEST) and queue the message for the line handler 132 which passes the message about a line handler 132 'in node B. It can be seen that messages can be passed between line handlers 132 and 132' through computer networks, telecommunications networks, wireless networks, of satellite communications and the like.

In node B, line handler 132 'obtains the message and sends it to the next destination (next-DEST) specified in the message, which is NODEB.AUTH01 or authorizer 116'. The authorizer 116 'authorizes the transaction and calls the APP send to return an authorization message and records the transaction in one or more journal databases (RETURN and DAILY-DEST). The application library 114 'determines the destination of the journal (diary-DEST) to have a journal proceeding, and also notes the originator of the message as node A, so it calls the system to send specifying the destination as NODEA. daily. The send system then queues and writes the message for journal 120 on node A. The system library 60 'notes the name of the foreign system of NODEA, sees the system and determines the logical name of the somnavigation port for the node A. System library 60 'then append the actual destination address of journal 120 on node A to the system header 94 in the message on the next destination (next-DEST). The system library 60 'also sees the line handler 132' for the communication port for node A and queues the message for it. The line handler 132 obtains the message and sends it to the message to NODEA. iar 120, which is specified as the next destination. The journal 120 then receives the message and writes it for its database or transaction log file 122. The journal 120 then calls APP to send and specifies a next destination (next-DEST). The application library 114 resolves the following destination as the return destination (return-DEST) which is specified in the message as the handler of the device 80. The send system then queues and writes the message for the device handler 80 , which The authorization machine is trusted by the automated teller machine 52. The automated teller machine then carries out the requested transaction or denies the transaction, depending on the authorization in the message.

There are possible associated essenarios are different applications such as the transfer of information and electronic funds, where the system and the distributed online data sharing method 50 are equally applicable. For example, a host (not shown) such as a banking institution may be required to authorize the transaction. A host interconnect can be used to interconnect with the host. In addition, a cardholder may access the ATM card network in a first node, wherein the transaction is required to be authorized by the host in the second node, but the host interconnect may exist in a third node. Therefore, the transaction message can be signaled from the first node to the second node through the third node. The system library is similar and the application library processes can be used to complete this transat- uction.

The method and the distributed online data sharing system 50 according to the teachings of the present invention are constructed to provide database duplication in the case of a system failure in one or more nodes. Referring to Figure 6, a block diagram of example database duplication or synchronization system and process 200 is shown. Again, an electronic funds transfer and information application is used to illustrate the 200 system. When an event triggers a change in a seleded number of files or databases, this change is sent to the backup database for update your records. For example, when an authorizer 202 authorizes a transaction that changes the account balance of an account stored in a positive balance record (PBF) 204, the change is packaged in a message and sent to the DB-SYNC 306 process. client account record (CAF) 206 is updated, the astualizer 202 also sends the updated information in a message to the DB-SYNC 306 process. Similarly, a change to an account exception record (AEF) is sent by a file server process, CAD SVR 302, for the DB-SYNC 306 process.

The delivery of the updated data message is carried to sabo by calling the system library routine, send system. The message may contain a logical identity of the backup system or node, the type of record, and the changed data. The prosed DB-SYNC 306 then writes the message for the record of storing DB-SYNC 308 and also uses the send system to send the message to a prosess DB-SYNC 320 over the designated backup system, node A. recovery of the system library 60 can access the system configuration database 130 to determine the physical address of the destination system. A timer 310 can be started to keep track of elapsed time. The storage file DB-SYNC 308 works as a temporary buffer for the transaction data that requires duplication in the backup node. It can be seen that a similar line handler process, as shown in Figure 3, can be used to deliver the message to remote nodes.

The DB-SYNC 320 process on node A receives the message and sends the message to the server indicated by the type of record contained in the message, including PBF SVR 322, ATJTH 324, or CAF SVR 326. The appropriate server then stores the data of transsession in the message for the respective file or database 330-334. The DB-SYNC process at node A may send a message of acknowledgment to the process DB-SYNC 306 at node B upon receipt of the message or after the transshipment data is successfully stored in the proper file. Upon receipt of the acknowledgment message, the DB-SYNC process 306 deletes the corresponding message from the DB-SYNC 308 storage. If at the time the timer 310 sansizes the message resonance to it, it is not yet received by the DB-SYNC process. SYNC 306 of the backup system, where the DB-SYNC 306 can resurrect the message stored in the DB-SYNC 308 warehouse file and retransmit it to the backup system. The retransmitted message may include a sampo to indicate that this is a second transmission of a previously sent message.

Built in this way, each system in the node is assigned a backup system or a multiple backup in another node, and the data stored in the databases relayed to the transactions are duplicated. Therefore, the seleted files or databases between the primary and backup systems are synchronized so that they contain essentially the same data. It can be determined that certain transactions are essential for the operations of the system, for example, supplying cash, so that only the databases and associated files are this transsession are doubled. For example, the file of bankruptcy exemptions 208 may be duplicated because it registers ATM cards that have been lost or stolen and that may fall into unauthorized use.; the positive balance record 204 provides accounts that have a sufficient balance to sustain the cash assortment; and the customer account file 206 contains information on the customer's account. It can be seen that the database synchronization is not limited to these databases and records shown in Figure 6.

Referring to Figure 7, a simplified block diagram illustrating an example process for detecting and managing the general failure of a node is shown. A distributed online data communication system 400 in this case includes three nodes, Nodes A, B, and C. Communi- cation between the nodes is achieved by line handlers 402-406 connecting to each other as specified in the base. of system configuration data 130 (Figure 3) of each node. A backup connection, shown in dotted lines, can be seen, which is also provided between line handlers 402-406. Each articulation, primary and backup is represented by a logical unit. When the messages communicated between the line handlers 402-406 fail to be received within the specified time constraints, the back-up link is used for communication between the line handlers. If both primary and backup links fail and continue to fall, the control points 412-416 of the nodes can communicate through a joint 420-424 coupled between them to continue providing operators located on any node to access other nodes, including the node with faults.

Each node also has a system monitor 426-430, which carries out a greeting protocol with the system monitors of other nodes. Each system monitor sends a hello message to all other system monitors in the system. The greeting message preferably includes the view of the monitor sending the status of all the nodes in the system. When a system monitor receives a hello message from another node, it compares the state contained in the message with its own data to the state of all the nodes. The system monitors of two or more nodes must agree that a node is potentially dropped before the node is pronounced as dropped. For example, if the system monitor message 426 from Node A has been marked Node B as potentially dropped, and the system monitor message 430 from Node C has also marked Node B as potentially dropped, then an agreement has been reached. as for the state of Node B, and it is marked as being dropped. A system monitor marks a node as being potentially dropped when it has communications problems with the node through the primary and backup links, when it does not succeed in exchanging greeting messages with the monitor on that node, or when it obtains a greeting message from that node with a request of "Mark me down". This latter scenario can occur when the node is temporarily put offline for maintenance by an operator.

A more detailed description of the greeting process is as follows. The system monitor 426 in Node A reads from the system configuration database to obtain the logical names for the system monitors in other nodes in the system, which identify the system monitors 428 and 430. The system monitor 426 then sends a greeting message to the system monitor 428 in Node B. The greeting message contains its own status but not a sample of site. Site samples are used to communicate the status of other nodes. At the same time the time system monitor 426 sends the greeting to Node B, it also sets an interval timer. The system monitor 426 also sends a greeting to a system monitor 430 of Node C, also containing its own status but not the site sample. An interval timer is also set. The system monitor 426 of Node A then receives a greeting message from the system monitor 428 of Node B, which contains the status of Node B. This information is used to update a state table in Node A. The monitor System 426 also receives a greeting message containing the status of Node C of the system monitor 430, and uses the data therein to update the status table.

When the interval timer set for the Node B expires, the system monitor 426 of Node A again sends a greeting message to the system monitor 428 of Node B with the status of Node A and a site sample containing the status of Node C, as reported in the state table. Similarly, a greeting message is also sent to Node C with the status of Node A and a site sample containing the state of Node B when the second interval timer expires. The system monitor 428 in Node B responds to the greeting message of Node A this time with a greeting message containing its own understanding of the status of Node C in a sample site. The system monitor 426 of Node A then compares the state of Node C received from Node B with state input of C in its state table. Note that the state table of Node A may list the Node C as dropped if any of the previous greeting messages sent to Node C were not recognized or left unanswered. Therefore, if both the state table and the greeting message from Node B indicate that Node C is dropped, then the configuration database of the Node A system is schemed to mark Node C as dropped. The Node B, carrying out the exact process as it was dismantled above will also uncover the sate state of Node C and update its system configuration database accordingly.

The capture processing using a backup node to carry out the transaction load of the node sated in the same way. To notify the processes within the backup node to begin processing the transactions of the dropped node, the system monitor of the backup node can send a command message to the control point of the same node requesting that the configuration database of the backup node. system is updated to store the node saido, as described above, and in such a way that an announcement message is sent to all processes on the backup node that the take processing is starting.

During the take processing when one or more nodes are down, the traffic to the node or satellite nodes is directed to its backup node. For example, in Figure 8, Node B is dropped and Node A was previously designated as its backup system. Each process entity in the system also has at least one designated backup process, and the traffic is directed to the backup entities. For example, a terminal definition file records the network property data of each ATM machine terminal and each record of terminal definition file may have a primary node name and at least one backup node name maintained in the database of system configuration.

When a transaction is initiated at the automated teller machine 52 'coupled directly to the Node B during the take operation mode, it is communicated to the handler of the device 80 and to the director 110 of the Node A for processing. The manager 110 determines that his system is the backup system for this transaction during the take mode, and sends the transaction message to the authorizer 116. The authorizer 116 also determines that this is the backup process for the registration of definition file card particular (CDF) 118 for the current transfer and the authorizers of the transaction. The authorizer 116 may use a different set of predefined transaction authorization limits during the take mode. The authorizer 116 then sends the message to journal 120 to record the transaction in the transaction log file (TJF) 122 and also writes the transaction for a warehouse and shipping file (SAF) 432.

When a Node B becomes operational, a restoration process 434 communicates the database updates to the customer account file (CAF) 436 and the positive account file (PBF) 438, so that these are updated to reflect transactions that occurred during the intake period.

The description of the present invention given above is generally put in the context of the transfer of information and electronic funds as an example. However, the present invention is applicable to all application programs which require online communications with external devices or systems. Other examples include the implementation of an electronic benefits transfer system, automated online ticketing and credit card point of sale transactions.

Although the present invention and its advantages have been described in detail, it should be understood that various changes, substitutions and alterations may be made therein without departing from the spirit and scope of the invention as defined in the appended claims.

Claims (19)

R E I V I N D I C A C I O N S

1. An event driven and failover transaction processing system comprising: at least one system node having a plurality of application processes for processing transactions initiated by a plurality of external devices; a data communications system that provides a plurality of message and service entities to said plurality of application processes for directing, transmitting and receiving messages to and from one another; a system configuration database storing each entity and process and their respective backup entities; Y A system monitor that resides in each system node to monitor and communicate the operational status of each system node to another.

2. The system as claimed in clause 1, characterized in that each system node also comprises: at least one application database used in the processing of said transactions; Y at least one backup application database.

3. The system as claimed in clause 2, characterized in that said application processes further comprise a database synchronization process for transmitting modifications to said application database for the backup application database.

4. The system as claimed in clause 2, characterized in that said application processes further comprise a database restoration process for transmitting transactions processed by a backup system node for an application database residing in a database. dropped system node, after the fallen system node resumes its operations.

5. The system as claimed in clause 4, characterized in that said transactions processed by said backup system node is stored in a predefined database on said backup system until the fallen system node resumes operations and said processing process. Database restore successfully transmits such transactions to the database.

6. The system as such is claimed in clause 1, because the system monitor residing in each node comprises an output protocol to join the system monitors that reside in other system nodes for the state of the other system nodes.

7. The system as claimed in clause 1, characterized in that it also comprises a state table that can be accessed by said system monitor to receive the status of each node of the system.

8. The system as claimed in clause 1, characterized in that said application processes include an authorizing process for receiving a message containing a request for a transaction, and authorization of said request.

9. The system as claimed in clause 1, characterized in that said application processes include a directing process for receiving a message containing a request for a transaction and determining a destination for said message.

10. The system as claimed in clause 1, characterized in that said application processes include a journaling process to record each transaction.

11. The system as claimed in clause 1, characterized in that it also comprises: a primary communications link between each system node and at least one other system node; Y a backup communications link between each system node and at least one other system node, said backup communications link being operational when said primary communications link fails.

12. The system as claimed in clause 11, further characterized in that it comprises a communication link of sontrol between each system node for communicating control messages.

13. A method for operating a transaction processing system driven by fail-safe event comprising the steps of: record in a system configuration database a logical identifier, a physical address, and the status for each node in the system, - put together all the nodes in the system for their status and their understanding of the state of the other nodes in the system; Y direct processing messages to a backup node in response to determining that a node is down.

14. The method as claimed in clause 13 characterized in that the conjunction step comprises the steps of: send a greeting message from each node to each other node in the system, the greeting message contains the state of the sending node; receive the greeting message, update an entry of the status of the sending node in a state table and answer a greeting message to the sender node by the sender, the greeting message contains the state of the receiving node; again send a greeting message from each node to each other node in the system, the greeting message contains the status of the sending node and all the nodes in the system other than the intended recipient of the greeting message; and receive the greeting message, compare the status of all the nodes in the message with the corresponding entries in the state table. -

15. The method as claimed in clause 14 facesterized because the step of joining further comprises the steps of: mark a node as being dropped if both the state table and a predetermined number of nodes also indicate that the node is dropped in the greeting message in the comparison step; Y notify a designated node as a backup node to begin the process of restarting the load of the node node process.

16. The method as such and somo is claimed in clause 13 characterized in that it comprises the steps of: carry out the recovery processing of the twill of the fallen node process; store the transactions carried out during the recovery processing, - send the stored transactions to the dropped node when it resumes operations; Y Accumulate the database of the fallen node to reflect the transactions carried out during the resumption process.

17. The method as claimed in clause 16, characterized in that the step of storing the transaction involves the step of saving changes to a selected set of databases used in the recovery processing.

18. The method as claimed in clause 13 further characterized in that it comprises the steps of: note the modifications made to the data in at least one selected application data base; send such modifications to the backup application database; make the same modifications to the data stored in a backup application database.

19. The method as claimed in clause 18, characterized in that said note, sending and modifications constitute the steps made periodically to synchronize the data stored in the selected application database and its backup application database. R E S M E N The system and method of the present invention provide a fail-safe event driven transaction processing for commercial electronic applications. The system includes at least one system node that has multiple entities and prosesos to somunicate with other devices, such as financial institutions and automated teller machines. Multiple links are provided between the system nodes to provide a flexible address in the case of dropped nodes. A configuration database accessible by the processes provides a backup entity or process for each entity and process. A system monitor resides in each system node, monitors the operational status of each node and communicates the status to the other nodes.