|
|
|
Interconnection or interaction of plural electronic cash registers (ECRs) or to host computer (e.g., network detail, transfer of information from host to ECR or from ECR to ECR, etc.) |
Financial transaction processing system and method6039245
Abstract
A financial transaction processing system (10) enables processing transactions from various types of card activated terminal devices (12) which communicate using a variety of electronic message formats. The transaction processing system may operate to authorize transactions internally using information stored in a relational database (32) or may communicate with external authorization systems (18). The transaction processing system includes among its software components message gateway routers (MGRs) (24, 164) which operate using information stored in the relational database to convert messages from a variety of external message formats used by the external devices and authorization systems, to a common internal message format used within the system. The system further uses database information to internally route messages to message processing programs (MPPs) (108, 138) which process messages and generate messages to the external devices and authorization systems. The MGR also converts the outgoing messages from the internal message format to the external message formats which can be interpreted by the external devices and systems to which the messages are directed.
Claims
We claim:
1. A transaction processing system comprising:
a computer;
a plurality of external devices, each external device in operative connection with the computer, wherein each of the external devices is operative to send or receive at least one message comprised of fields;
a database in operative connection with the computer, wherein the database includes data representative of:
each of the plurality of external devices and an associated external format used to send messages to or to receive messages from each respective external device;
information concerning transformation of messages between at least one internal message format and a plurality of external message formats, such information including at least one message identifier value, and a message type, a message format and message field positions associated with the message identifier value;
wherein the computer is operative to transform an incoming message from a message sending one of the plurality of external devices from the external format used by the message sending one external device to the internal message format, and to transform an outgoing message to a message receiving one of the plurality of external devices from the internal message format to the external format used by the message receiving one external device, and wherein the computer is operative to cause the incoming and outgoing messages to be transformed responsive to the message identifier value and the field position data associated with each respective message.
2. A transaction processing system comprising:
a computer;
a plurality of external devices, each external device in operative connection with the computer, wherein each of the external devices is operative to send or receive at least one message comprised of fields;
a database in operative connection with the computer, wherein the database includes data representative of:
each of the plurality of external devices, and for each external device an associated external message format used to send messages to or to receive messages from the respective external device;
transformation information concerning transformation of messages between at least one internal message format and a plurality of external message formats, the transformation information including at least one message identifier value, and a message type, a message format and message field conversions associated with each message identifier value; and
wherein the computer is operative to transform an incoming message from a message sending one of the plurality of external devices from the external format used by the message sending one external device to the internal format, and to transform an outgoing message to a message receiving one of the plurality of external devices from the internal message format to the external message format used by the message receiving one external device, and wherein the computer is operative to cause the incoming and outgoing messages to be transformed responsive to the message identifier value and the field conversion data associated with each respective message.
3. A system for processing financial transactions comprising:
a database including data concerning transaction message formats, wherein the database includes stored information concerning transformation of messages between a standardized internal message format and a plurality of external message formats;
a computer in operative connection with the database, wherein the computer includes a message gateway router (MGR) function, wherein the MGR function is operative to selectively convert messages between the plurality of external formats and the internal format;
at least one external device, wherein the external device is in operative connection with the computer, wherein the external device is operative to generate messages in at least one of the external formats;
a driver in operative connection with the computer and the external device, wherein when the device generates a message the driver is operative to include in the message a message direction indicator, and wherein the MGR is operative responsive to the message direction indicator in the message to convert the message from the external format associated with the external device, to the internal format.
4. The system according to claim 3 wherein the database includes data representative of an identity of the one external device, and wherein when the external device generates the message the driver is further operative to include in the message data representative of the identity of the device, wherein the MGR is operative responsive to the direction indicator and the device identity data to convert the message from the external message format associated with the external device to the internal format.
5. A system for processing financial transactions comprising:
a database including data concerning transaction message formats, wherein the database includes stored information concerning transformation of messages between a standardized internal message format and a plurality of external message formats;
a computer in operative connection with the database, wherein the computer includes a message gateway router (MGR) function, wherein the MGR function is operative to selectively convert messages between the plurality of external formats and the internal format;
at least one external device, wherein the external device is in operative connection with the computer, wherein the external device is operative to receive messages in at least one of the external formats;
message processing software, wherein the computer is in operative connection with the message processing software, and wherein the message processing software is operative when an internal format message is being sent to the external device to include in the message a message direction indicator, and wherein the MGR is operative responsive to the message direction indicator in the message to convert the message from the internal format to the external format associated with the external device.
6. A transaction processing system comprising:
a computer, wherein the computer includes at least one message gateway router function (MGR) and a plurality of other software functions operating therein;
a plurality of external devices, wherein each external device is in operative connection with the computer, and wherein each of the external devices is operative to send or receive messages in one of a plurality of external message formats;
a database in operative connection with the computer wherein the database includes data representative of:
each external device and an associated external message format used to send messages to or to receive messages from each respective external device;
information concerning transformation of messages between at least one internal message format and a plurality of external message formats;
identities of a plurality of nodes, wherein each of a plurality of system components including each external device, each MGR and each other software function corresponds to a node, and wherein the database includes in correlated relation with at least one node identity, a parent node identity;
wherein the computer is operative responsive to the MGR and the stored information concerning transformation of messages, to cause an incoming message from a message sending one of the plurality of external devices to be transformed from the external message format used by the message sending one external device to the internal message format, and to cause an outgoing message to a message receiving one of the plurality of external devices to be transformed from the internal message format to the external message format used by the message receiving one external device, and wherein the computer is operative to send at least one of the incoming message or the outgoing message from the MGR to a system component corresponding to a first node responsive to a first parent node identity stored in correlated relation with an identity of the first node.
7. The system according to claim 6 wherein at least one of the incoming message or the outgoing message includes data representative of a node identity, and wherein the computer is operative to send the at least one message to a system component corresponding to the node identity.
8. A system for processing transactions comprising:
a computer;
a plurality of external devices in operative connection with the computer;
at least one message transforming software function in operative connection with the computer;
a timer function in operative connection with the computer;
a database in operative connection with the computer, wherein the database includes data representative of:
each of the plurality of external devices and an associated external message format used to send messages to or to receive messages from each respective external device;
transformation information concerning transformation of messages between each of a plurality of external message formats and an internal message format;
wherein the message transforming software function is operative to determine a format of a device message having either the internal format or one of the external formats, and wherein when the device message is in one of the external formats the message transforming software function is operative responsive to the transformation information to cause the device message to be transformed to the internal message format, and wherein when the computer sends the device message to an external device the message transforming software function is operative responsive to the transformation information to cause the device message to be sent to the external device in the external format used by the external device, and wherein the computer is operative in sending the device message to the external device to send a timing message to the timer function and the timer function is operative to cause the device message to be sent to the external device.
9. The system according to claim 8 and wherein the timer fiction is operative to send a timing response message a time after receipt of the timing message, and wherein when the external device sends a device response message responsive to the device message within the time, the computer is operative to send a timing delete message to the timer function, wherein receipt of the timing delete message is operative to cause the timer function not to send the timing response message.
10. A transaction processing system comprising:
a computer, and a message processing program software function (MPP) in operative connection with the computer;
a plurality of external devices in operative connection with the computer, wherein each external device communicates in at least one of a plurality of external message formats;
a timer in operative connection with the computer;
a database in operative connection with the computer, wherein the database includes transformation information concerning transformation of messages between a plurality of external message formats and an internal message format;
wherein the computer is operative responsive to the transformation information to cause incoming messages from the external devices to be transformed from the respective external message format of the incoming message to the internal message format, and to cause outgoing messages to the external devices to be transformed from the internal message format to the respective external message format used by an external device to which the outgoing message is directed, and wherein responsive to sending an outgoing message to an external device the MPP is operative to cause a timing message to be sent to the timer and wherein the timer is operative a time after receipt of the timing message to send a timing response message to the MPP.
11. A system for processing transactions comprising:
a database including data concerning transaction message formats, wherein the database includes information concerning transformation of messages between an internal message format and a plurality of external message formats;
a computer in operative connection with the database;
a message gateway router (MGR) in operative connection with the computer;
a message processing program (MPP) in operative connection with the computer;
wherein the MGR is operative responsive to the information in the database to cause a received message in one of the plurality of external formats to be transformed to the internal format, and wherein the MGR is operative to determine a message type associated with the received message, and is further operative responsive to the message type to route the message to the MPP, wherein the MPP processes the received message in the internal format.
12. The system according to claim 11 wherein the message in the internal format includes an ISO 8583 message format portion, and wherein the MPP is operative to parse the ISO 8583 message portion into a plurality of cells in an array, each cell containing data from a field of the ISO 8583 message portion.
13. The system according to claim 11 wherein the database further comprises a plurality of state flow tables and related parameter tables, and wherein the computer is operative to execute a plurality of functions, wherein said functions operate on said parameters determined from said parameter tables and deliver a true or false result.
14. The system according to claim 13 wherein said MPP is operative to perform the functions determined from said state flow tables.
15. A system for processing financial transactions comprising:
a database including data concerning transaction message formats, wherein the database includes stored information concerning transformation of messages between an internal message format and a plurality of external message formats; and
a computer in operative connection with the database, wherein the computer includes a message gateway router software function (MGR), wherein the MGR is operative to determine a format of a received message, the received message having either the internal format or one of the external formats and a message direction indicator associated with the message, the message direction indicator being indicative of either an incoming message direction or an outgoing message direction, and wherein when the received message is in the internal format the MGR is operative responsive to the message direction indicator being indicative of the outgoing message direction to transform the message selectively to any one of the plurality of external formats, and wherein when the received message is in one of the plurality of external formats the MGR is operative responsive to the message direction indicator being indicative of the incoming message direction to transform the message to the internal format, wherein the internal format includes an ISO 8583 message format portion.
16. A method for processing financial transactions generated by a plurality of external devices, each of said external devices communicating messages in a different external message format, said processing conducted in a computer in operative connection with a data store comprising the steps of:
storing in a data store data representative of an address uniquely associated with each external device and an external message format for each said device, which format is stored in correlated relation with said address;
storing in the data store data representative of each external message format in correlated relation with data representative of a location of a message type in a message in said external message format;
storing in the data store data representative of each external message format and message type in correlated relation with data representative of a transformation of an external message having said message format and message type, wherein said transformation is operative to produce an internal format message;
receiving with said computer a device message from an external device having an address, said device message having an external device message format and device message type;
determining the external message format of said device message from said data stored in the data store responsive to said device address;
determining the message type for said device message from said data in the data store responsive to the external device message format and the device message;
generating an internal message format message corresponding to the device message responsive to the data stored in the data store, the device message format and the device message type.
17. Computer readable media bearing instructions which are operative to cause a computer to carry out the method steps recited in claim 16.
18. A method for processing financial transactions generated by a plurality of devices, each of said devices communicating messages in a different external message format, said processing conducted in a computer in operative connection with a data store, comprising the steps of:
storing in the data store data representative of each of the devices operatively connected to provide messages to the system, and storing for each of said devices data representative of an external message format in which each said device communicates its messages;
storing in the data store data representative of how to convert messages in each said external message format to a message in an internal message format;
storing in the data store data representative of how to process transactions in the internal message format;
receiving device messages with said computer from said devices, said device messages in said external message formats;
transforming said external format messages from said devices to internal format messages with the computer responsive to the data stored in the data store; and
processing with the computer the internal format messages responsive to data stored in the data store.
19. Computer readable indicia bearing instructions thereon which are operative to cause a computer to carry out the method steps recited in claim 18.
20. A method for processing financial transactions in a system including external devices, at least one computer in operative connection with the external devices, and at least one data store in operative connection with the computer, wherein each external device communicates with the computer through electronic messages, the messages having different message formats, comprising the steps of:
storing in a data store data representative of:
a transformation of each of a first plurality of messages between an external message format and an internal message format;
an identity of each of a second plurality of external devices; and
for each device identity, an external message format for messages communicated to and from the device;
determining with the computer responsive to the information in the data store an identity of an external device generating or receiving a message;
transforming the message with the computer responsive to the format and transformation data in the data store corresponding to the device identity, wherein when the message is a first type which the device generates the message is transformed from an external format indicated in the data store as associated with the device to the internal format, and wherein when the message is a second type which the device receives the message is transformed from the internal format to the external format.
21. The method according to claim 20 wherein in the storing step the data representative of transformation includes data representative of a third plurality of message types for each message communicated in each of the external formats, and wherein the transforming step includes determining with the computer responsive to the message type information in the data store, a message type of the message wherein in the transforming step the message is transformed responsive to the message type.
22. The method according to claim 21 wherein in the storing step the data representative of transformation includes data representative of a message type location in each of the external format messages, and wherein determining the message type in the message transformation step includes determining with the computer responsive to the information in the data store the message type location in the message, and reading the information at the location in the message.
23. The method according to claim 21 wherein in the storing step the data representative of transformation includes data representative of a fourth plurality of internal message identifiers, each internal message identifier corresponding to a message having one internal or external message format and message type, and wherein the transforming step includes determining with the computer responsive to the data in the data store an internal message identifier for the message.
24. The method according to claim 21 wherein the message includes a plurality of fields, and each field includes message data, and wherein in the storing step the transformation data includes data representative of positions of each of the fields in the one message associated with an internal message identifier, and wherein the transformation step includes repositioning the message data from the fields of a message responsive to the position data corresponding to the internal message identifier associated with the message.
25. The method according to claim 24 wherein in the data storing step the transformation data includes data representative of conversion of message data from a first form to a second form in the one message having the internal message identifier, and wherein the transformation step includes converting message data from the fields of the message responsive to the conversion data corresponding to the internal message identifier associated with the message.
26. The method according to claim 20 wherein the message comprises a plurality of fields each field including message data, and wherein in the data storing step the transformation data includes data representative of positions of each of the fields in the message, and wherein the transformation step includes repositioning message data from the fields in the message.
27. The method according to claim 26 wherein in the data storing step the transformation data further includes data representative of conversions of message data from a first form to a second form, and wherein the transformation step includes converting message data in at least one field of the message from the first form to the second form.
28. The method according to claim 20 and prior to the transforming step further comprising the step of including in the message a designator, wherein a first designator is added to the message when the message is the first type, and wherein a second designator is added to the message when the message is the second type, and wherein in the transformation step the transformation is accomplished responsive to the designator included in the message.
29. Computer readable media including instructions which are operative to cause a computer to carry out the method steps recited in claim 20.
30. A method for processing financial transaction messages in a system including a plurality of external devices, at least one computer, at least one device driver in operative connection with the computer and at least one of the external devices, and at least one data store in operative connection with the computer, wherein each external device communicates with the computer through device messages, the device messages including a plurality of external message formats, comprising the steps of:
storing in the data store data representative of:
message layouts for a plurality of external message formats and an internal message format;
a device identity for each of a plurality of external devices; and
for each device identity, a corresponding external message format for messages communicated by the corresponding device;
receiving a device message with the computer from at least one of the external devices, wherein the device message is in an external message format;
including in association with the device message using a device driver receiving the device message, a message direction indicator and device data corresponding to the device identity stored in the data store for the external device generating the device message;
transforming with the computer the external format message from the external device, to generate to a corresponding internal format message responsive to the direction indicator, device data, and a portion of the data stored in the storing step; and
processing with the computer the internal format message.
31. The method according to claim 30 and further comprising the steps of:
generating a further message in the internal message format, wherein the further message includes identity data representative of the identity of the external device and a further message direction indicator;
further transforming with the computer the further message to generate a corresponding further device message having the external message format communicated by the external device, responsive to the further message direction indicator, the identity data and a portion of the data stored in the storing step.
32. A method for processing financial transactions in a system including a plurality of external devices, at least one computer, at least one data store in operative connection with the computer, and at least one message processing program in operative connection with the computer, wherein each external device communicates with the computer through electronic messages, the messages including a plurality of different message formats, comprising the steps of:
storing in a data store data representative of:
message layouts for a plurality of external message formats and an internal message format;
for each of the external devices, an external message format for messages communicated by the corresponding external device;
including with the computer in an internal format message directed to an external device, a message direction indicator; and
transforming with the computer the internal format message, to generate an external format message in the external format communicated by the external device, responsive to a portion of the data stored in the storing step and the direction indicator included in the internal format message.
33. A method for processing transactions generated by a plurality of external devices, each of the external devices communicating messages in a different external message format, the processing conducted with a computer in operative connection with a data store, comprising the steps of:
storing in the data store, data representative of an address uniquely associated with each external device and an external message format for each said device, which format is stored in correlated relation with the address;
storing in the data store, data representative of each external message format and data representative of a location of a message type in a message in the respective external message format;
storing in the data store, data representative of each external message format and message type and data representative of a transformation of an external message having the respective message format and message type, wherein the transformation is operative to produce an internal format message;
receiving with the computer a device message from an external device having an address, the device message having an external device message format and device message type;
determining the external message format of the device message from the data stored in the data store responsive to the device address;
determining the message type for the device message from the data in the data store responsive to the external device message format and the device message; and
generating an internal message format message corresponding to the device message responsive to the data stored in the data store, the device message format and the device message type.
34. A method for processing transactions generated by a plurality of devices, each of the devices communicating messages in a different external message format, the processing conducted with a computer in operative connection with a data store, comprising the steps of:
storing in the data store, data representative of each of the devices operatively connected to provide messages to the system, and storing for each of the devices data representative of an external message format in which each device communicates its messages;
storing in the data store, data representative of how to convert messages in each external message format to a message in an internal message format;
storing in the data store, data representative of how to process transactions in the internal message format;
receiving device messages with the computer from the devices, the device messages in the external message formats;
transforming the external format messages from the devices to internal format messages with the computer responsive to the data stored in the data store; and
processing with the computer the internal format messages responsive to data stored in the data store.
35. A method for processing transactions in a system including external devices, at least one computer in operative connection with the external devices, and at least one data store in operative connection with the computer, wherein each external device communicates with the computer through electronic messages, the messages having different message formats, comprising the steps of:
storing in a data store, data representative of:
a transformation of each of a plurality of messages between an external message format and an internal message format;
an identity of each of a plurality of external devices; and
for each device identity an external message format for messages communicated to and from the device;
determining with the computer responsive to the information in the data store, an identity of an external device generating or receiving a message;
transforming the message with the computer responsive to the format and transformation data in the data store corresponding to the device identity, wherein when the message is a first type which the device generates, the message is transformed from an external format indicated in the data store as associated with the device to the internal format, and wherein when the message is a second type which the device receives, the message is transformed from the internal format to the external format.
36. A method for processing transactions in a system including a plurality of external devices, at least one computer, at least one data store in operative connection with the computer, and at least one message processing program in operative connection with the computer, wherein each external device communicates with the computer through electronic messages, the messages including a plurality of different message formats, comprising the steps of:
storing in a data store, data representative of:
message layouts for a plurality of external message formats and an internal message format;
for each of the external devices, an external message format for messages communicated with the corresponding external device;
and alternatively either:
setting with the computer responsive to an internal format message directed to an external device, a message direction indicator indicative of an outgoing message;
transforming with the computer the internal format message, to generate a corresponding external format message in the external format communicated by the external device, responsive to data stored in the storing step and the direction indicator set by the computer responsive to the internal format message; or;
setting with the computer responsive to an external format message directed from an external device, a message direction indicator indicative of an incoming message;
transforming with the computer the external format message, to generate a corresponding internal format message in the internal format, responsive to data stored in the storing step and the direction indicator set by the computer responsive to the external format message.
37. Computer readable media bearing instructions which are operative to cause a computer to carry out the method steps recited in at least one of claims 16, 18, 20, 30, 32, 33, 34, 35, or 36.
Description
TECHNICAL FIELD
This invention relates to financial transaction processing systems. Specifically, this invention relates to a system and method for processing financial transactions that originate at credit, debit or stored value card activated terminals such as automated teller machines and point of sale terminals.
BACKGROUND ART
Systems and methods for processing financial transactions are known in the prior art. Such systems include those used to process credit card transactions and debit card transactions. In systems of this type, transaction messages are transmitted between card activated terminal devices and remote computer systems which authorize the transactions. Such systems also keep an accounting of the amounts to be charged to a customer's account and credited to the account of a merchant or bank. Such card activated terminal devices include automated teller machines ("ATMs"), point of sale ("POS") terminals and other financial transaction terminal devices. Terminal devices of these types can also be activated using stored value cards, which are sometimes referred to as "cash cards" or "smart cards".
In transaction processing systems, transaction messages often must be passed between and processed in several different computer systems. Messages pass from the terminal devices to the remote systems that can authorize and track the transactions. Return messages pass from the remote systems back to the terminal devices.
The development of transaction processing systems has been complicated by the fact that different card activated terminal devices communicate using different messages and different message formats. Further complicating the development of such systems is that transaction messages must be passed and tracked through systems which have different types of hardware and software. This has necessarily limited the capabilities of transaction processing systems.
In recent years an effort has been made to develop standardized formats for financial transaction messages. For example, the International Organization for Standards has developed International Standard ISO 8583 entitled Financial Transaction Card Originated Messages--Interchange Message Specifications, 2nd Edition, 1993. This publication which is ISO Reference No. ISO 8583, 1993(E) is incorporated herein by reference. This ISO Standard provides a somewhat standardized typography for certain types of electronic financial transaction messages. However, while the Standard provides guidelines for the content of messages, it does not provide standardization for methods to be used in routing of such messages. As a result, the methodology for routing messages remains to be dealt with within the programming constraints of the particular type of hardware and software associated with a particular system.
A further complication with respect to the ISO 8583 Standard is that it does not specify a single message format. Rather, the Standard is flexible in that certain data fields which may be a part of a message, are not required to be present in all messages of the same type. Thus, some messages complying with the Standard may contain data that other messages of the same type also fully complying with the Standard, do not. The ISO Standard messages may also have so-called "private fields" in which those using the Standard may include data of their choosing.
The fields which make up the parts of a Standard compliant message may also have various lengths. Operators of systems and vendors of terminal devices each have implemented the ISO Standard for their systems or devices somewhat differently. As a result, while certain aspects of the messages may be the same, they are often substantially different. This poses challenges for system operators in processing transaction messages which comply with the ISO Standard.
A further complication in the processing of financial transaction messages is that there is a large installed base of terminal devices which do not comply with the ISO Standard. Such devices use their own unique message formats. As a result, it is necessary to translate messages from these devices into different formats for subsystems that use and ISO Standard format. Of course, these subsystems must include hardware and software for translating their messages into the message format of the particular terminal device when transaction messages pass from the subsystem to the device.
The need for financial transaction processing systems to translate messages from one format to another adds complexity and cost to such systems. A further drawback is that efforts to expand such systems so that they can communicate with additional types of terminal devices and other systems, require the development of software that can process and generate the various types of messages that are encountered. This usually results in a patchwork systems architecture which takes considerable time to develop and which cannot be readily expanded. All of these drawbacks add cost and complexity to financial transaction processing systems.
Thus, there exists a need for a financial transaction processing system and method that is more readily adaptable to communicating with a variety of other types of external systems and terminal devices, which can be more readily modified and upgraded to communicate with different types of external systems and terminal devices, and which can be more readily expanded to add new features and functions.
DISCLOSURE OF INVENTION
It is an object of the present invention to provide a transaction processing system which can communicate with a plurality of other types of transaction processing systems.
It is a further object of the present invention to provide a financial transaction processing system that can communicate with different types of terminal devices that communicate in varied message formats.
It is a further object of the present invention to provide a financial transaction processing system that can be more readily adapted to communicate with other types of systems and devices.
It is a further object of the present invention to provide a financial transaction processing system that is more reliable by providing distributed and redundant processing capabilities.
It is a further object of the present invention to provide a financial transaction processing system that will operate on a variety of computer software and hardware platforms.
It is a further object of the present invention to provide a method for processing transactions that enables translation of messages between varied message formats.
It is a further object of the present invention to provide a method for processing financial transactions that enables communication between authorization systems and terminal devices which use different message formats.
It is a further object of the present invention to provide a method for processing financial transactions that uses common method steps for converting transaction messages of various types into a common message format.
It is a further object of the present invention to provide a method for processing financial transactions that provides a common approach to building outgoing transaction messages that can be used with a variety of outgoing message formats.
It is a further object of the present invention to provide a method for processing financial transactions that is fast and reliable.
Further objects of the present invention will be made apparent in the following Best Modes for Carrying Out Invention and the appended claims.
The foregoing objects are accomplished in an embodiment of the present invention by a financial transaction processing system in which transaction messages are routed to and from card activated terminal devices. The card activated devices are commonly point of sale terminals and automated teller machines. Transaction messages are transmitted from the terminal devices to an authorization subsystem or network. The authorization subsystem may be integral with the financial transaction processing system of the present invention or may be a separate and distinct external system or network of systems. Transaction messages from the authorization subsystem are routed through the system of the present invention and back to the proper terminal device.
The preferred embodiment of the present invention includes a distributed processing system and preferably runs on several different computers. The computers are connected through interfaces and device drivers to external devices which include authorization systems or networks and terminal devices. The system software further includes a relational database which is programmed with database table records which includes data representative of the message formats used by each type of terminal device and external authorization system to which the system is connected.
The system software includes a message gateway router ("MGR") which operates to take each message that comes from a terminal device or external authorization system or network, and transform the message into a common internal message format based on the information in the database. This process for transforming external messages having different formats to a common uniformly defined format, is carried out through a systematic series of steps which are common to a wide variety of external messages which can be processed.
Once in the internal message format, the messages are routed and processed by one or more message processing programs ("MPPs"). MPPs process each message depending on its type and generate a resulting message. The resulting message is then routed to an appropriate address in the system. The system may include various types of application programs for authorizing transactions within the system and storing information in the database. Certain types of transaction messages may be processed in the system of the invention and the resulting message converted to a different format which is used by an external authorization system or network. The format of the message transmitted to the external authorization system may be a totally different message format from both the message format used internally by the transaction processing system of the invention as well as the message format used by the terminal device which originated the message to the system.
The present invention is structured to provide distributed processing by networking the software components across various items of computer hardware. In addition, the preferred form of the present invention processes financial transaction messages based on database structures which may be readily developed and modified through a graphical user interface ("GUI"). This enables the system configuration to be readily changed and facilitates modification of the system to process transaction messages between additional types of external authorization systems and terminal devices which use different message formats.
BRIEF DESCRIPTION OF DRAWINGS
FIG. 1 is a schematic view of the network topography of a financial transaction processing system of an embodiment of the present invention.
FIG. 2 is a schematic representation of the software components which comprise an embodiment of the software of the financial transaction processing system of the present invention.
FIG. 3 is a schematic view of a standard message envelope representing the data included in internal messages transmitted within the financial transaction processing system of the present invention.
FIG. 4 is a graphical representation of a transaction message passing through a first portion of the financial transaction processing system of the present invention.
FIG. 5 is a schematic view of how a transaction message is further processed through a portion of the financial transaction processing system of the present invention beyond the processing steps shown in FIG. 4.
FIG. 6 is a schematic view of how a transaction message is further processed in a portion of the financial transaction processing system of the invention beyond the processing steps shown in FIG. 5.
FIG. 7 is a schematic view showing how a transaction is further processed beyond the processing steps shown in FIG. 6 and is delivered to an external authorization system, network or other external system.
FIG. 8 is a schematic view that shows a message being received from an external authorization system or other external network by the system of the present invention.
FIG. 9 is a schematic view showing further processing of a message within the financial transaction processing system of the present invention beyond the processing steps shown in FIG. 8 when encryption or decryption of the message is required.
FIG. 10 is a schematic view showing processing of the message within the financial transaction processing system of the invention and delivering the message to a terminal device.
FIG. 11 is a schematic representation of a message being processed from a terminal device through a line driver and into a message gateway router of the financial transaction processing system of the invention.
FIG. 12 is a schematic view of a financial transaction message being processed to identify it as a particular type of message within the message gateway router of the financial transaction processing system.
FIG. 13 is a schematic view of a message undergoing parsing and reconstruction into the system internal message format by the message gateway router portion of the financial transaction processing system.
FIG. 14 is a schematic view of a message address being determined after a message has been parsed and reconstructed by the message gateway router.
FIG. 15 is a schematic view of a message from the message gateway router being addressed and transmitted within the financial transaction processing system.
FIG. 16 is a schematic view of a message being received by a message processing program of the financial transaction processing system.
FIG. 17 is a schematic representation of a transaction message being laid out in an array of defined cells in the message processing program represented in FIG. 16.
FIG. 18 is a schematic view of a message being processed within a message processing program of the financial transaction processing system of the present invention.
FIG. 19 is a schematic view of the process of storing a message in the relational database of the financial transaction processing system by the message processing program.
FIG. 20 is a schematic view showing a message processing program of the present invention sending a message to a next message processing program within the system.
FIG. 21 is a partial database schema for system nodes showing the layout of data records associated with node type terminal, node type line and node type process nodes of the financial transaction processing system of the present invention.
FIG. 22 is a partial database schema used for parsing and constructing messages having a non-ISO format in the message gateway router of the transaction processing system.
FIG. 23 is a partial database schema associated with FIG. 22 for use with parsing and constructing ISO format type messages in the financial transaction processing system.
FIG. 24 is a partial database schema including portions of a database schema used for determining the system address for a message processing program.
FIG. 25 is a partial database schema graphically representing steps for processing financial transaction messages within the message processing program using a state flow process.
FIG. 26 is a partial database schema used for determining the destination of transaction messages that are passed from the system of the invention to an external authorization system.
FIG. 27 is a schematic view showing the operation of the message gateway router of the financial transaction processing system of the present invention in connection with a device used for encryption and decryption of transaction messages going to and from the financial transaction processing system.
FIG. 28 is a schematic view of a timer used within the system of the invention to verify that outgoing or incoming messages are properly responded to.
FIG. 29 is a partial database schema used in connection with routing messages to a message processing program within the system of the present invention.
FIG. 30 is a schematic view of the process steps used in connection with routing messages from a message processing program to a message gateway router within the system of the invention.
BEST MODES FOR CARRYING OUT INVENTION
Referring now to the drawings and particularly to FIG. 1, there is shown schematically therein the topography of an embodiment of the financial transaction processing system of the present invention generally indicated 10. The system communicates with terminal devices 12 which are represented by point of sale terminal 14 and an automated teller machine ("ATM") 16. It should be understood that the present invention is intended to be used to communicate with a wide variety of terminal devices which may be connected to the system either individually or as part of a group of devices networked together.
The system 10 further communicates with external authorization systems generally indicated 18. These external authorization systems may include credit card processing networks such as VISA.RTM. or MasterCard.RTM.. In addition, these external authorization systems may include debit card processing systems such as the Cirrus.RTM. or Plus.RTM. networks. Alternatively, the external authorization systems may include systems operated by individual financial institutions or proprietary networks which authorize and track transactions. Both terminal devices and external systems are considered as external devices for purposes of processing transactions in the system of the present invention.
Terminal devices communicate through electronic messages. Electronic messages from the terminal devices are communicated through a driver generally indicated 20. The driver is a device which can send and receive messages from the terminal device to which it is connected. Likewise, the external authorization systems 18 send and receive messages to and from the remainder of the system through a driver 22.
As shown in FIG. 1, the drivers 20, 22 are in operative connection with one or more computers and each pass messages to and from a software component within the system called a message gateway router or "MGR" 24, 25. As later explained, the MGR operates to take incoming messages and to convert them into a common internal message format used within the financial transaction processing system of the invention. Similarly, the MGRs 24, 25 also convert internal messages within the system to the external message formats needed to communicate with the various external authorization systems 18 and terminal devices 12. Although multiple MGRs may be shown in the drawings it should be understood that all MGRs are identical.
The financial transaction processing system of the invention also includes software components called message processing programs or "MPPs". The exemplary system shown schematically in FIG. 1 includes an MPP 26 and an MPP 28. These MPPs are intended to represent processes performed by the system using messages of a particular type. It should be understood that the system may execute a large number of processes and that there may be a large number of MPPs. Because each MPP is made to process a particular type of message, each MPP is generally different from other MPPs.
As shown in FIG. 1, the financial transaction processing system of the present invention uses distributed processing in which the MGR and MPP components communicate through an internal network. The network uses the TCP/IP network communication protocol which is known to those skilled in the art. TCP/IP enables messages to be moving between a plurality of different components within the system simultaneously and further enables messages to be transmitted and received between system components which may be operating on computers running at different speeds and in geographically distant locations. The preferred embodiment of the invention enables the asynchronous processing of transactions in a manner later explained in detail.
Each of the logical software components of the system communicates through the TCP/IP network through an associated listener and sender software as graphically represented in FIG. 1. Each listener serves to capture and assemble messages intended for its associated destination from the TCP/IP network within the system and to place the received messages in queue for delivery to the associated component. Similarly, each sender derives the address of the next component in the system that will process the message and dispenses the message into the network for delivery to the destination. Each listener in the system operates in an identical manner to all other listeners. Likewise, each sender works in a manner identical to all other senders. The manner in which TCP/IP networks operate for the dispatch and receipt of messages is known to those skilled in the art.
A graphical representation of the logical levels of software components of the financial transaction processing system of the present invention is shown in FIG. 2. The software components of the system operate in one or more computers. The software which operates in a computer schematically indicated 17, includes an operating system component schematically indicated 30. The operating system operates on compatible computer hardware and may be one of several commercially available systems such as OS/2 or AIX from International Business Machines, Windows NT from Microsoft Corporation or UNIX from Novelle, Inc. It should be understood that the software of the present invention is intended to run on different types of hardware platforms which may be running different operating systems within a distributed processing system connected through the internal TCP/IP network.
The software architecture of the preferred embodiment of the present invention further includes a relational database schematically indicated 32. The relational database is preferably one that employs structured query language ("SQL") compliant commands. Such databases include commercially available products such as Oracle from Oracle Corporation, Sybase from Sybase, Inc. or DB2 from International Business Machines. Of course other embodiments may employ other types of databases and/or other approaches to storing and recovering data. The database is alternatively referred to herein as a memory or data store.
As previously discussed, the system preferably includes a networking software component schematically indicated 34. This enables the software components of the internal network of the system to communicate in a local area network ("LAN") or a wide area network ("WAN") configuration. The preferred form of the invention employs TCP/IP communication, but in other embodiments other networking approaches may be used.
The software further includes device drivers schematically indicated 36. Each software driver is set up to communicate specifically with the terminal or network drivers 20 or 22 which communicate with particular devices, terminals or networks which are connected to the drivers through data lines.
Drivers are also included which communicate with external authorization systems and networks 18. Device drivers may be included which communicate directly with a particular transaction processing terminal. Such communication may be through lease line or modem type communications. As later explained, in the preferred form of the present invention the characteristics of messages associated with a particular external message destination such as a line or terminal, are defined and stored in the database 32. These defined characteristics enable the deciphering or constructing of messages that pass to and from the connected external devices which include authorization systems, networks and terminals.
The software components of the system further include the message gateway router ("MGR") previously mentioned. The system may run several MGRs, but each is identical. The MGR includes functional subcomponents which include a universal message parser ("UMP") 38. As later discussed, the MGR using the universal message parser serves to interpret incoming messages and transform them to a common internal message format for routing and processing within the system.
The MGRs further place incoming messages in a standard message envelope ("SME") designated 40. The SME is the internal message format used within the system of the invention. The SME includes a data portion of the message in an ISO message format, as well as a header which includes routing information used to route messages between the components of the system. MGRs also operates to convert outgoing messages from the internal SME message format to external formats.
The software architecture also includes application programs generally indicated 42. The application programs include instructions for carrying out various types of transaction processing within the system. As graphically shown in FIG. 2, some representative types of applications include a retail payment application 44. This software application may be used for example by a retail chain store which issues its own store credit card to customers. When a retail payment application is included as part of the system, information concerning customers and their associated cards and amounts would be maintained within the database 32. The operator of the retail payment system could then keep track of the customers using its store credit card and bill the customers for the value of items purchased on credit using their cards at the stores of the retailer/system operator.
The system operator can keep track of the cards that were issued, including the identities of the customers who have them, their associated credit limits and other information, using a card management software application, schematically indicated 46. The card management application 46 works in conjunction with information in the database to control the production and issuance of new cards, to invalidate lost or stolen cards or to render temporarily unusable cards that are over a user's credit limit.
Of course, in most financial transaction systems it is necessary to accept cards other than those which may have been issued by a particular retailer. Such cards commonly include MasterCard.RTM., VISA.RTM., American Express.RTM., Diner's Club.RTM., Discovers.RTM. and other credit or debit cards. As a result, it is often necessary to have software applications which will route these transactions from the system to the proper external authorization network and back again. Such programs are schematically represented by the switch support application 48.
The financial transaction processing system of the present invention may also include other software applications. These may include check authorization, schematically indicated 50. Such an application may determine whether a particular customer who wishes to cash a check should be allowed to make a payment in that manner. Such applications may involve checking data within the database 32 to determine if the customer meets certain criteria and/or making inquiries to authorization networks 18 or to particular financial institutions.
Another exemplary application within the software is an application which tracks customer loyalty which is generally indicated 52. Such an application is used to determine how frequently a particular customer purchases from a particular establishment using a debit or credit card. Similarly, a software application may be used to determine what products or brands of merchandise a particular customer purchases and how frequently such purchases are made. Within the system provisions are made for recording and tracking this information within database 32, or within other databases which may be connected to the system through the internal network or external networks.
The software architecture of the invention as indicated in FIG. 2 may include applications which process transactions from stored value cards or so-called "smart cards". Such software is graphically designated 54 as a stored value application. This application contains the instructions necessary to process the various transaction schemes associated with stored value cards, as well as the information necessary to communicate information concerning the use of stored value cards to and from various external networks and devices. Typically stored value cards work in connection with or as an adjunct to a credit or debit card. This enables a single smart card to operate as a credit card or debit card, as well as a cash substitute. The stored value application 54 may also operate to add value to a stored value card either on a credit or debit basis through internal processing and/or by communication with external authorization systems or networks.
A further application shown in the software architecture is an electronic benefits transfer ("EBT") application. The EBT application schematically designated 56 may be used for processing card based transactions associated with public benefits. For example, it is becoming increasingly common for public benefits recipients to receive their benefits electronically so as to eliminate paper vouchers or food stamps. EBT application 56 enables transmission and processing of messages from various POS terminal devices and/or exchange of messages with the external networks and systems which are capable of processing, authorizing and recording electronic benefits transactions.
It should be understood that the system of the present invention may include only some of the software applications discussed herein, which are exemplary. Other applications which perform different functions may also be used.
The software architecture of the preferred embodiment of the present invention also includes a shared memory manager component ("SMM") 58. The SMM 58 enables the holding of data from the database for ready access in the shared memory of the computers of the system. The SMM has an associated routine which places into a block in RAM selected database information at system start up. Maintaining information in the SMM rather than making more frequent physical read requests to the database 32 makes the software of the present invention operate more rapidly.
A timer component 60 of the invention is used to keep track of messages that are sent by the system. This enables the asynchronous processing of messages. As later explained, if a message should become lost or if an error should prevent further processing of a message, the timer component returns the original message to the sending point. This enables the occurrence of such event to be detected.
The system further includes an automated problem management system application ("APMS") 62. The APMS software is used for tracking and recording problems that arise within the system. The APMS 62 is connected with a status monitor software component 64 which serves to track the operational status of various components in the system. As a result, the APMS can be used to identify areas within the distributed system which are down or which are experiencing delays. The APMS may also be structured to re-route transaction messages to other sites where the desired processing may be accomplished.
A further feature of the software of the present invention is graphical user interface software application generally indicated 66. The graphical user interface ("GUI") is associated with client workstations which are preferably computer stations which include displays and input devices. These stations enable the set up of system configuration data by manipulating the information held within the database. This is done in the preferred embodiment through the use of a GUI created using rapid development, object oriented software interface development tools for SQL compliant databases. A suitable tool for such use in such development is PowerBuilder.RTM. software from PowerSoft Corporation.
Using the GUI creation tools, high level graphic representations of system components including hardware and software are provided which may be manipulated by a systems operator. Such manipulation may include the ability to add or delete terminal and network connections to the system, to reconfigure the system to communicate with different terminals and networks, and to add, delete and modify the information to be used by the various application programs. The graphical user interface software component may also be used to select various types of terminal on-line connections which will then change message routing. The user is enabled to input the desired changes using input devices such as a keyboard or mouse and to observe the results of the changes on the display. The GUI enables the user to configure the system at a high level. The user's configuration changes the underlying database relationships so the system changes its operation to conform to the changes input through the graphical user interface.
The GUI also preferably enables the client workstations to be used to easily set up data in the database, as well as to track desired functions and information. Such macro instruction capabilities provided through the GUI enable the rapid development and configuration of database information tailored to the particular type and operation of the system involved.
The software of the preferred embodiment of the present invention is delivered into the computers of the system from computer readable media which includes the instructions which are operative to cause the computer to carry out the steps later described. The computer media may include any media from which the software may be read including for example one or more tapes, diskettes or a hard disk drive. The software may be installed by placing the media in the computer or by loading the software from media residing in another computer through an electronic "download".
It will be appreciated by those skilled in the art that the system of the present invention provides a generally uniform approach to processing a widely disparate group of incoming card based transaction messages which involve different message formats and message types which places such messages in a uniform internal format. By processing these disparate messages in a consistent and systematic way the system is enabled to receive and process these messages and to produce messages which may be further processed within the system and/or communicated to external authorization systems or networks in the external formats recognized by such systems and networks.
Transaction Processing Example
To more fully explain the operation of the financial transaction processing system of the present invention, an example of how a transaction is processed through the system is hereinafter described. It should be understood that this is an example of a particular type of financial transaction and that other embodiments of the invention may use somewhat different process steps and parameters.
Referring to FIG. 4, in this example a message originates from a terminal device which in FIG. 4 is a POS terminal 68. POS terminal 68 of necessity is capable of generating as well as receiving many messages, all of which in this example have the same message layout or format. These messages may or may not be in some type of ISO 8583 message format. Typically however, to be used as a transaction terminal, the messages transmitted and received from POS terminal 68 must include certain information. For example, card based transaction messages usually include customer identifying information such as a customer's account number.
POS terminal 68 must also be capable of sending information which identifies where it is located, and the entity such as a retail establishment in which it is operating. This enables the entity that is providing merchandise, services, credit or cash to the customer to be properly credited with the amount charged to the customer (less transaction fees). Likewise, messages going to and from the POS terminal must be capable of representing amounts associated with the various transactions. Other transaction messages reflect situations where the customer's card is invalid or where the transaction is denied for various reasons. POS terminals or other card activated terminal devices often must send and receive information necessary for verification of personal identification numbers ("PINS") which verify that the proper customer is using the card.
Other messages transmitted to or from POS terminal 68 may include messages associated with encrypting or decrypting data. These may include keys which enable the scrambling or unscrambling of transaction messages to prevent fraud or improper use of transaction processing systems.
Other transaction messages may include repeat messages in the event that a first message is lost. Other data generated by the terminal 68 may reflect the particular items purchased or services rendered as part of the transaction. Various goods purchased may be tracked as part of the transaction. This is facilitated through linking the POS terminal to an electronic cash register which is connected to a database containing inventory information. Other transaction messages from a POS terminal may include batch transmission of a log of daily transactions conducted at the terminal.
While a large number of transaction message types have been identified in the ISO 8583 Standard, it will be apparent to those skilled in the art that an even greater variety of transaction message types may be transmitted by or received from terminal devices of various types.
Device Driver
As shown in FIG. 4, POS terminal 68 communicates messages to and from a device driver indicated 70. The functions performed by the device driver are schematically shown in FIG. 11. The terminal 68 is connected to physical hardware generally indicated 72. This physical hardware is a type of network data line or phone line connection which enables the electronic messages to enter and exit the device driver portion of the software. This physical hardware receives and transmits the raw messages which come from and go to the terminal in the format used by the terminal.
A protocol portion of the software in the device driver is schematically indicated 74. Protocol portion 74 is connected to and controls the physical hardware 72 in accordance with its application programming interface ("API"). The protocol portion 74 of the device driver 70 operates on an incoming message to strip any protocol dependent parts of the raw message. This is done based on the protocol definition which is programmed in the device driver component. The protocol portion 74 also operates to provide a data item representative of the identity or physical address of the particular terminal from which the message is coming.
The protocol portion of the software sends the raw message and the physical address information to the address resolution protocol portion ("ARP") 76 of the device driver. The ARP 76 performs several functions. First, it adds a system header to the text of the raw message. This system header is initially a series of blanks or zeros. It is constructed to eventually have data in the 12 message fields of the standard message envelope ("SME") shown in FIG. 3. The header that is added by ARP 76 is sized to accommodate data fields 1 through 11. The raw message from terminal 68 minus protocol dependent portions is in message field 12 at this point.
The ARP 76 of the driver 70 also operates to insert header layout version data in field 1 of the header. This data as shown in FIG. 3 is representative of a header layout version. Generally a financial transaction processing system will only have one header layout version. However, if it is desired to accommodate several different header layouts, perhaps so the system may process both financial messages and other types of messages, this may be facilitated by having various line drivers apply different headers depending on the type of messages defined as coming into the system through the particular driver.
The ARP 76 also operates to insert data in field 8 of the header to indicate that the message being handled is an incoming message. It also inserts data in field 7 to indicate the message is coming from an external source. This indicates that the message needs to be processed from the raw external message format to the standardized internal message format.
As shown in FIG. 11, the ARP 76 operates to access data which is stored in the database, but which is preferably available in block memory in RAM when the system is running because of the shared memory feature of the system. The database includes data representative of system "nodes", each node corresponding to a component of the system. One data block includes node table records associated with the particular line and/or terminals attached to the line which is sending the message to the system. This data is laid out in a node table record 78 which is partially shown schematically in FIG. 11. The node table record 78 contains considerable information associated with the line and/or terminal from which the message is coming. By matching the node table record containing the physical address data which has been delivered to ARP 76, with the node table records in memory, the system can find a node ID which is called a NODE.sub.-- SID in table record 78. The NODE.sub.-- SID is determined by matching the node table record which has the corresponding physical address data therein. The ARP 76 then operates to obtain the NODE.sub.-- SID value from the node table record 78. The ARP 76 then places the NODE.sub.-- SID value in field 2 of the header. The NODE.sub.-- SID is the system identifier used in the system to identify the particular component in the system which sends or receives a message.
The ARP 76 then passes the raw message with the header portions filled in so far to the interprogram communication ("IPC") 80 portion of the device driver. The IPC functions in connection with the operating system software operating in the computer to send the message and header to a queue associated with a message gateway router, MGR 81 software component. The IPC also inserts the NODE.sub.-- SID for the node table record for the line driver in field 10 of the header which is the current "processing node". The IPC also inputs the time it received the message in field 3 of the header. As no time has yet been spent processing the message, field 9 remains at zero.
While the example of node table record 78 shown in FIG. 11 is a partial schematic only, an example of the kinds of data found in node table records is shown in FIG. 21. FIG. 21 schematically shows three types of node tables. An upper portion 82 of the node table as shown is data that is typically stored for all types of nodes. Three types of nodes are typically encountered in the system of the invention each of which correspond to a type of system component. These are a node type terminal, a node type line and a node type process. If the particular node is for a node type line, the data in the node table would include the data represented by the lower middle table portion 84 as shown in FIG. 21.
Similarly, if the node table is associated with a specific terminal, for example an automated teller machine, the node table would include the data in the upper portion 82 as well as the data as shown in the lower left table portion 86 in FIG. 21. External authorization systems are like terminals in that they are an external component or device which sends and receives messages. Likewise, timers 60, APMS 62 and encryption devices preferably have similar capabilities. As a result all these components have a similar node table layout which is designated as a node type terminal.
If a node is associated with a process such as a message processing program ("MPP"), a message gateway router ("MGR") or shared memory manager ("SMM"), the node type process table record has an upper node table portion 82. The table record also has a node type process portion associated with it similar to table portion 88 shown in the lower right in FIG. 21.
It will be understood that each node type has an associated node type table and that there are three distinct node type tables for lines, terminals and processes. FIG. 21 is structured as shown because each of these node type tables contains some of the same types of data and it is easier to show this common data through a single table portion 82 rather than in triplicate. It should be further understood that each node which corresponds to a component within the system, will have an associated node table record which defines the characteristics of the component represented by the particular node.
It should be noted for purposes of illustration that the tenth entry down in upper portion 82 of the node table shown in FIG. 21 is the PHYSICAL.sub.-- ADDR value which is representative of a physical address. This is the physical address value that is matched by ARP 76 of driver 70 to find the corresponding NODE.sub.-- SID which identifies the node table record for a particular terminal device. It should also be noted that node tables associated with node type processes do not include a physical address. This is because such nodes are within the internal system network and messages thereto are addressed through the TCP/IP network protocol as later discussed.
The message is now ready to be sent to the message gateway router 24. In this example only fields 1, 2, 3, 7, 8, 10 and 12 in the SME are filled in with data by the line driver. In other examples where the terminal which originated the message is part of a line group the ARP 76 also inserts the NODE.sub.-- SID of the node type line table record associated with the line driver which receives the message, in field 11 of the SME. This is necessary to make sure that a message that is responsive to the original message can find its way back to the line that the original message came in on. This is important for handling dial up devices which may have messages come in on any of several phone lines. The data in field 11 enables a responsive message to be routed back to the device on the line which remains open during processing of the transaction. If the component sending the message always uses a designated line for communication with the system, field 11 of the SME is not used.
The Message Gateway Router
As shown in FIGS. 4 and 11, the message gateway router MGR 81 takes the message from the IPC 80 out of the input queue of that MGR. At this point the message structure includes the raw message that was sent by the terminal 68 in field 12 of the SME without the protocol portions of the original message.
As schematically shown in FIG. 12, the MGR first operates to look at the message direction indicated in field 8 and the data source in field 7 of the header. If the message direction represents "in" the MGR puts the message in its buffer. The MGR then takes the NODE.sub.-- SID value which is in field 2 of the header and looks up the corresponding node table record in shared memory. As the data source in field 7 indicates "external" the MGR is operative to transform the raw message to the internal format.
As shown in FIG. 12, the node table record 78 for the node associated with the terminal includes an entry which points to the format of incoming messages at that particular node. This entry is the IN.sub.-- MSG.sub.-- FMT.sub.-- SID. It should be noted that in the layout of the actual node table 82 shown in FIG. 21 the IN.sub.-- MSG.sub.-- FMT.sub.-- SID is the seventh entry down on the table. It is also indicated to be a "foreign key". The MGR is operative in this situation to read the IN.sub.-- MSG.sub.-- FMT.sub.-- SID value in the node table record for the terminal 68 included in field 2 of the header.
It should be noted in FIG. 21 that the node table records contain data on both the format of messages coming in and out of a system node. Most devices and systems use the same message format for both incoming and outgoing messages so both table record entries are generally the same. However, it is possible to configure the system to send outgoing messages to an external device in a different message format than that used for incoming messages from the device if appropriate.
The MGR operates responsive to the information in fields 7 and 8 of the header to execute steps to transform the message text in field 12 of the SME. The MGR 81 holds the message from the line driver in a buffer and takes the IN.sub.-- MSG.sub.-- FMT.sub.-- SID value to the data in shared memory and looks for a match in a "message format" table record that includes this entry. This is represented by message format table 90 in FIG. 12. Message format table 90 is designated MSG.sub.-- FMT because as explained later, this corresponds to an actual table name for records in the database as shown in FIG. 22.
From corresponding message format table record 90, the MGR finds the message type offset and the message type length for the particular incoming message format. This is represented by the columns in the table MSG.sub.-- TYPE.sub.-- OFFSET and MSG.sub.-- TYPE.sub.-- LENGTH. The offset and the length are indicators of where to find data in the raw message that tells what type of transaction message the raw message is.
As graphically demonstrated in FIG. 12, the MGR proceeds to use the message offset to go into the message text in field 12, a distance equal to the offset number of bytes. In FIG. 12, an example is shown where the offset is four bytes, each byte being representative of a digit.
After going into field 12 of the message a distance equal to the offset, the MGR then reads the following number of bytes equal to the message type length. In the example shown in FIG. 12 the message type length is six digits. Again it should be remembered that the digits in the portion of the raw message determined by the message offset and message type length will be used to identify what type of raw message it is that is incoming from terminal 68.
The process executed by the MGR 81 to find offset and length values is also demonstrated with reference to the database schema shown in FIG. 22. The desired MSG.sub.-- FMT:2 table record is found by searching for the IN.sub.-- MSG.sub.-- FMT.sub.-- SID value shown as FMT.sub.-- SID which is the "present key" to the table. The data corresponding to the message type offset and message type length are the fifth and sixth columns in the table, respectively.
Referring now to FIG. 13, the MGR 81 takes the bytes which represent the message type determined from the message offset and length, and goes to the database information in the shared memory. The MGR looks for a "message map" table record that includes both the message type value as determined from the offset and length information, and which also includes the IN.sub.-- MSG.sub.-- FMT.sub.-- SID from the original node table record. By searching through message map table records a match is eventually found. As shown in FIG. 13, this data is found by the MGR in a particular message map table record 92.
From the message map table record 92 an internal message ID value is determined. This is represented INT.sub.-- MSG.sub.-- SID. This internal message format identifier is then placed in field 4 of the header shown in FIG. 3 by the MGR. It should be remembered that this INT.sub.-- MSG.sub.-- SID designator is representative of both the message format for incoming messages from terminal 68, as well as the particular type of message that has come from the terminal. This is useful because as later explained, this data can be used to determine how to parse the raw message data and place it into a standardized internal message format that is used within the system. This data is also used to determine the MPP where this message can be processed.
FIG. 22 shows a database schema which includes a message map table which is designated MSG.sub.-- MAP. As shown, this table includes as "present keys" the IN.sub.-- MSG.sub.-- FMT.sub.-- SID from the node table record which is indicated FMT.sub.-- SID, and the message type designated MSG.sub.-- TYPE. From these two data elements the INT.sub.-- MSG.sub.-- SID is determined which is the third column in the table.
The MGR next operates to set a counter, preferably to zero. This counter corresponds to a "field number". The parts of a financial transaction message in field 12 of the SME are called "fields". The indicia in each field represents particular information. In order to process transactions, the various message formats are defined as having a particular type of information in each field. Thus, in general it can be said that even though the values of information in a particular field may vary from message to message, the particular type of information represented by the values in that field for all such messages having the given format will be the same type.
The MGR operates using this principle when converting a message into the internal format to take each field in the raw incoming message and to copy that data into a new field in a new message. The field where the data is eventually positioned is determined by the ISO 8583 Standard in the preferred embodiment of the invention. As a result, a raw incoming message which may have a totally different format from an ISO message, is parsed, transformed and copied one field at a time to generate a new message which complies with the ISO 8583 Standard. Messages which partially comply with the Standard are likewise parsed, transformed and copied to create a new message that is consistent with the internal SME format to be used within the system of the invention.
Non-ISO incoming message formats which contain data which is not required to be in a particular field by the ISO Standard have such data placed in a private field in the ISO message by the MGR. The data is placed in the private field with a SUBFIELD.sub.-- SID header. Each SUBFIELD.sub.-- SID has its own parser database table records which define its fields. Likewise, incoming ISO compliant messages which contain private field data, will have that data maintained in a private field. However, as the MGR builds a standardized ISO message format for use within the system a corresponding SUBFIELD.sub.-- SID header is placed with the data in a private field in a new message.
The process of parsing, transforming and reconstructing the raw message in field 12 of the SME into the internal ISO format is graphically demonstrated with regard to FIG. 13. The MGR takes the INT.sub.-- MSG.sub.-- SID value from the header and finds the message field table records including this value in shared memory. The MGR then takes the INT.sub.-- MSG.sub.-- SID and the FIELD.sub.-- NUM value from the counter and finds a message field table record in shared memory which contains these two data elements. This is shown schematically by message field table record 94 in FIG. 13. The message field table record may contain a field switch indicator which points to field switch table records 95. The field switch table records contain information on conditional message field ordering. The message field table record also may include a field map indicator which points to field map table records 97. The field map table records contain information on how constant data values found in the original raw message are to be converted to other data values which are placed in the fields of the new internal message.
Message field table 94, message map table 97 and field switch table 95 direct the MGR through a process in which iterative tables are looked up to find the proper locations to place the data from the raw message into the new ISO message. The table records also cause the data from a field in the raw message to be converted to a different data value if required to comply with the ISO format. As each field from the raw message is processed, the FIELD.sub.-- NUM counter is changed. If the field switch indicator in a message field table is not used, the FIELD.sub.-- NUM is incremented by the counter to the next field number. Alternatively, if the message field table record includes FIELD.sub.-- SWITCH.sub.-- IND, the FIELD.sub.-- NUM is incremented to the FIELD.sub.-- NUM value in the corresponding field switch table record. The field number identified is then similarly processed, using the message field table record for that INT.sub.-- MSG.sub.-- SID and FIELD.sub.-- NUM.
The MGR carries out the parsing of the raw message and the construction of the new internal ISO message by building a cell array. The location of each field in the raw message in field 12 of the SME is represented by values in the message field table record having the INT.sub.-- MSG.sub.-- SID and corresponding FIELD.sub.-- NUM value. The same table record provides the ISO.sub.-- BIT data which represents where the data in the raw message field number is to go in the internal ISO message format (once the raw message data is converted in accordance with data in a corresponding field map table record if necessary). The MGR places this data in the array of cells in an order that corresponds to the fields of the standardized internal ISO 8583 message of the system.
The MGR operates to create this cell array of data in RAM. This cell array is used by an "ISO create" function to generate the new message in the internal message format. As shown in FIG. 13 an MGR ISO array 93 includes cells with the data from each field in the raw message transformed through conversion of field values in accordance with the field map table records and rearranged in accordance with the field switch table records. Each cell of the MGR ISO array 93 includes not only the field data but also other data from the message field table records 94. This data generally includes the ISO.sub.-- BIT.sub.-- SID, VAR.sub.-- LEN.sub.-- SID, VAR.sub.-- LEN.sub.-- ENCODE.sub.-- SID, VAR.sub.-- LEN.sub.-- CNT.sub.-- SID and DATA.sub.-- FMT.sub.-- SID. For data in private fields the data includes the ISO SUBFIELD.sub.-- SID and the corresponding information from the corresponding message subfield database table records. This data is representative of not only where the data goes in the internal message, but also can be used to derive information on how the MGR ISO array data is presented in the internal ISO message format.
Once the MGR ISO array 93 is completed the MGR executes the "ISO create" function. The ISO create function takes the message format data in the cells of the MGR ISO array 93 and looks up ISO field table records 91. The ISO create function of the MGR conventionally uses a FMT.sub.-- SID value of "0" in the preferred embodiment in matching the ISO field table records to create the new internal message. By successively matching the data in the ISO field table records to the data in each of the cells, an ISO.sub.-- DATA.sub.-- LEN value for each cell can be located. This is indicative of the length the corresponding field is to occupy in the internal ISO message.
From the ISO field table records the ISO create function of the MGR determines the field length for each field in the new internal message. It then compares the field length to the message data in the array 93. If the length matches, the data may be directly used in the new message. If the data length does not match the ISO create function buffers or converts the particular data field in accordance with its programmed logic based on the differences and operates to modify the message field data in the cells of the MGR ISO array. This is represented by the initial buffering of the message field with zeros in FIG. 13. Of course the "location" of the message field from the raw message has been changed in accordance with the message field and field switch table records. Further, although the raw message data is shown unchanged in FIG. 13, it should be understood that the raw message data is often transformed or converted to another format or value in accordance with the field map table records.
The MGR includes a number of programmed procedures that are used to convert data from one form to another. This may include procedures that convert data values or formats in the raw message to those required for the ISO message. The procedures for converting data are generally a fixed part of an MGR and as later described are also used for converting internal message data to external formats.
The ISO create process in the MGR converts the entire MGR ISO array into an ISO 8583 message. The SUBFIELD.sub.-- SID data is included with the private field data in the new message. Of course, if an error occurs while the raw message is being transformed to the new message, the MGR proceeds to generate an error message. The error message may be transmitted to the APMS 62.
The MGR also operates to update the information in fields 1 through 11 in the SME header and to place the header data in a header array in the MGR. The MGR carries over the values in fields 1 through 11 from the line driver except that it changes field 7 to indicate the message is now in an internal data format. It also adds the processing time to field 9. This is the total time spent by the system processing the message since the original message was received from terminal 68. The MGR adds its processing time to the existing value in the field. The MGR also places its NODE.sub.-- SID in field 10 of the header.
The layout of the message field, field switch, field map and ISO field table records which are involved in parsing and converting a raw message format to a standardized ISO 8583 message format is represented by the partial database schemas shown in FIGS. 22 and 23. It should be noted with regard to FIG. 23 that there are ISO subfield table records which provide the ISO create function with the information necessary to put data in private fields in the standardized internal message format.
The Sender
If the MGR completes its processes successfully, a new internal ISO message is created. This message includes the header with fields 1 through 11 in FIG. 3 and a message text in field 12 which is in a standardized internal ISO 8583 format. Fields 1 through 4, 7 through 10 and 12 are filled in at this point and the remainder are zeros. Field 11 is filled in if the component originating the message is part of a line group. This new message is sent to a sender 96 which is a software component associated with the MGR as shown in FIG. 4. The function of the sender is to determine the next destination for the message in the system. In this case the sender derives the IP address and IP port for the MPP that can process the message within the system.
This is accomplished by the sender taking the INT.sub.-- MSG.sub.-- SID from field 4 in the header of the new message. The sender then goes to the database information in shared memory and finds a message router table record which contains this information. This is demonstrated schematically in FIG. 14 by message router table 98.
By finding the message router table record including the INT.sub.-- MSG.sub.-- SID value, the sender can determine a SERVICE.sub.-- SID from that record. The sender places the SERVICE.sub.-- SID value in field 5 of the SME header. The sender then takes the SERVICE.sub.-- SID value and looks for a service provider table record schematically indicated 100 in FIG. 14 which includes this entry. From the service provider table record the sender determines an associated MPP.sub.-- SID. The MPP.sub.-- SID corresponds to a node SID. In this case because it is associated with an MPP it is a node type process table record. Table portions 88 and 82 as shown in FIG. 21 show the data contained in an MPP node table record.
The sender associated with the MGR also puts the MPP.sub.-- SID value determined from the service provider table 100 into the header of the message. It is inserted in the target node SID which is field 6 of the header. This is done to provide an indication within the message of the target address for the message. As a result the fields 1 through 12 of the SME are now filled with data, except field 11 is blank when the terminal which originated the message is not part of a line group.
The data contained in the message router and service provider table records is represented by the partial database schema shown in FIG. 29. As shown in the MSG.sub.-- ROUTER table, the INT.sub.-- MSG.sub.-- SID is used to determine a SERVICE.sub.-- SID which is then used as a present key to the SERVICE.sub.-- PROVIDER table to find the MPP.sub.-- SID which is the node address of the MPP which is capable of processing the message having the particular INT.sub.-- MSG.sub.-- SID value.
The sender associated with the MGR uses the MPP.sub.-- SID to find where to send the message. The MPP.sub.-- SID is a NODE.sub.-- SID for a node type process node, which is schematically indicated by node table records 102 and 104 in FIG. 15. As this node has a node type process table record, a SERVER.sub.-- SID value is retrieved from the table record by the sender.
The SERVER.sub.-- SID value points to further data which is used to determine the IP address and port ID of the particular MPP. The determination of the SERVER.sub.-- SID is demonstrated by the partial database schema in FIG. 21. This is shown in the table portion 88 which has the SERVER.sub.-- SID as the third column in the table. The database schema includes a SERVER.sub.-- SID value in connection with the NODE.sub.-- SID which identifies the system address of the particular MPP target node that can process the message.
The sender uses the SERVER.sub.-- SID value to determine the IP address and IP port ID of the required MPP so that the message may be sent to that MPP through the TCP/IP network. The sender goes to the database information in the memory and finds a server table which includes that SERVER.sub.-- SID value from the node table record. The server table is partially graphically represented 106 in FIG. 15. From the server table the sender retrieves the IP address designated IP.sub.-- ADDR in the table. The IP.sub.-- PORT.sub.-- ID is known from the node type process table record. Using the application programming interface ("API") associated with Unix, or other operating system being used, the message is sent through the TCP/IP network to the designated IP address and specific IP port ID.
The process of finding the IP address from the SERVER.sub.-- SID is graphically demonstrated with respect to the partial database schema in FIG. 24. As shown therein the server table records provide a correlation between the SERVER.sub.-- SID key and the IP.sub.-- ADDR. This combined with the IP.sub.-- PORT.sub.-- ID from the node table record enables deriving the proper address for the message.
Message Processing Program ("MPP")
As shown schematically in FIGS. 5 and 16, an MPP 108 which is the target of the message has a listener 110 software component associated therewith. The listener functions to receive messages sent to the port ID for that MPP listener at the IP address and to pull the packets of the message back together from the TCP/IP network. Listener 110 then puts the message in the MPP's input queue designated 112 in FIG. 16. It should be remembered that this message, although switched through TCP/IP, is placed back in the queue 112 in the format shown in FIG. 3 with the message text in field 12 in the standardized internal ISO 8583 message format. It should be understood that the MPP may reside on the same computer or on a different computer than the MGR which dispatched the message.
MPP 108 is a software component that is designed for specifically handling the type of message that it receives. Commonly the first step that MPP 108 will accomplish is to create an ISO field array from the message. This is graphically demonstrated with regard to FIG. 17. The MPP takes the ISO 8583 message and parses it out into an array comprised of cells 114.
Each of the cells contains data in a field of the message as defined by the ISO Standard or data in a subfield defined for the internal ISO message format. It should be remembered that in creating the internal ISO message there may have been private field data or data that was not required to be in a particular field by the ISO 8583 Standard. This data was placed in the so-called "private fields" of the ISO 8583 message by the MGR.
The MPP 108 uses data from the ISO parsing table records shown in FIG. 23 to parse the message and place it in the cells of the array. The ISO message in field 12 of the SME is in the ISO 8583 format. It includes bit maps as defined by the Standard for indicating the presence or absence of data in the 128 fields which make up the ISO message. The MPP operates to hold the message in a buffer and to parse that original message and copy it into the cells of the array based on the ISO data length values stored with the corresponding ISO bit sid values in the ISO field table records. The ISO field table record layout shown in FIG. 23 demonstrates the stored relational data. It should be understood that the FMT.sub.-- SID value for the table records used in this case is "0" which is the value for an ISO format message in the system.
The MPP executes a routine that iterates through the 128 fields of the ISO message. As the length of each field of the ISO message is determined the MPP copies the data from the original message in the buffer and places it in the corresponding cell of the array.
Subfield data is laid out in subfield cells 116 as shown in FIG. 17. The ISO.sub.-- SUBFIELD.sub.-- SID values placed in the private fields with the data by the MGR correspond to data in ISO subfield table records that define the field number and length for each item in the private field data. The ISO subfield tables define the location and length of each subfield in a private field. The MPP executes a routine similar to that used with the non-private fields that goes through each subfield in a private field and places the data in the subfield cells of the array.
In the preferred form of the invention the MPP includes multiple cell arrays. This enables processing data from one array and storing the result in other arrays. This approach enables using the data in the first array again after it has been previously used for processing. In the preferred form of the invention the MPP includes four cell arrays. This is shown schematically in FIG. 17. Of course in other embodiments other numbers of cell arrays may be used.
MPP State Flow
The MPP functions to process an incoming message and to generate a new message. This processing of a message by an MPP may involve, for example, a request to authorize a financial transaction and generating a message in response. This response message would typically allow the transaction to go forward, or to deny the transaction. In this example the MPP would be generating a return message which is routed back to the originating terminal device. Alternatively, the MPP may perform processing on the message and then send the resulting message through the system for eventual transmission to an external network or other external authorizing system.
When the MPP performs processing it does so using a state flow process. This process is graphically demonstrated with regard to FIG. 18. The ISO 8583 message which has been mapped into an ISO array includes by definition a message type identifier field which indicates the transaction type and message type that the particular message represents. This is a requirement of the ISO Standard. The MPP takes the MPP.sub.-- SID from field 6 of the header and the ISO defined message type identifier out of the field cell in the array and uses them to determine the processing steps that the MPP 108 is to go through. Because there may be several processing steps, the MPP also sets a counter to a first state number. This counter, which may be set initially at "one" but may be initially set at any other number depending on the design of the system, is called a STATE.sub.-- NUM parameter.
To determine what to do with the message, the MPP takes the message type which is designated MSG.sub.-- TYPE, the STATE.sub.-- NUM and the NODE.sub.-- SID for the MPP to the database table records held in shared memory. The MPP finds a state flow table record 118 including these parameters as graphically indicated in FIG. 18. From the state flow table record the MPP determines a FUNCTION.sub.-- SID and a PARM.sub.-- SID. The FUNCTION.sub.-- SID is then used to find a state function table record 119 by matching this data. From the state function table record a function class can be determined which is designated FUNCTION.sub.-- CLASS.sub.-- SID.
The FUNCTION.sub.-- CLASS.sub.-- SID is then used to find a state class table record 117. The state class table record provides the name of the parameter table which provides the parameter to be processed designated PARM.sub.-- TABLE.sub.-- NAME. The PARM.sub.-- SID from state flow table record 118 is then used to go to a STATE.sub.-- PARM.sub.-- TABLE graphically indicated 120 in FIG. 18, determined from table record 117 and having that PARM.sub.-- SID. The state parameter table 120 may include a field number value designated FIELD.sub.-- NUM which corresponds to the field bit number in the ISO message data in the cell array which contains the data that is to be used in carrying out the particular steps associated with this FUCNTION.sub.-- SID and STATE.sub.-- NUM. The state parameter table may alternatively point to other data or can provide data to be used which is not in one of the cells of the original array.
Having the field bit number for the data in the original ISO array (or the source of other data) that is to be used to carry out the function, the MPP then operates to execute a desired function on the data. This is done within the coding of the system which includes a wide variety of functional operations that may be executed with data from the fields in the message. These operations can be selectively pointed to by the FUNCTION.sub.-- SID and STATE.sub.-- NUM data in the state flow table records. The MPP operates to execute the function with the data in the field from the ISO array (or other source) that is determined from the state parameter table 120.
The functions that are executed by the MPP using the field number data from the ISO array are designed to give a "true" or "false" response. A simple example of this may be the situation where the determination of whether the card being used by a customer initiating a transaction has expired. To check whether the card has expired the state flow table points to the state parameter table which includes the field bit number in the ISO 8583 message cell array which points to the cell where the expiration date of the card is contained in the cell array. The function called in response to the FUNCTION.sub.-- SID and STATE.sub.-- NUM compares the expiration date to the current date and returns an answer to the question of whether the card expiration date is beyond the current date. If the card is not beyond the expiration date the answer is "true". If the card is beyond the expiration date the answer is "false". The state flow table record 118 provides the next state number to be used by the MPP if the response is true as well as a new state number to be used if the answer is false. These are shown by the designators NEXT.sub.-- STATE.sub.-- TRUE and NEXT.sub.-- STATE.sub.-- FALSE in table record 118.
In response to receiving the result of the executed function, the STATE.sub.-- NUM designator is changed to the STATE.sub.-- NUM that pointed to by the true or false response. The new STATE.sub.-- NUM is then used to look up a new state flow table record which corresponds to the NODE.sub.-- SID of the MPP and MSG.sub.-- SID which are the same as before, and the new STATE.sub.-- NUM. Looking up the function class and parameter table data from the state function and state class table records respectively, points to a new state parameter table record which contains the PARM.sub.-- SID. This table points to the FIELD.sub.-- NUM of the ISO 8583 data (or other data) which is to be used in carrying out the next step. As before the FUNCTION.sub.-- SID and STATE.sub.-- NUM are then used to identify a new function to be executed in the code.
This new function will return a result that is either "true" or "false". The true or false return determines the next STATE.sub.-- NUM which is then used to repeat the process by looking up yet another state flow table record. The process repeats until all of the functions to be carried out by the MPP through the state flow process have been executed.
It should be noted that the processes in the code which are called by the FUNCTION.sub.-- SID and STATE.sub.-- NUM may include functions that access the database 32. These may include functions which look up, compare, modify and replace database information.
An advantage of this approach is that the state flow table records point to the functions to be executed. As a result, these common functions are used over and over again when called. They do not have to be rewritten or incorporated into a different program when a new situation requiring a similar function is to be added to the system. This enables selecting from existing functions and configuring states and flows to accomplish processing transactions. This approach avoids the need for conventional programming.
The ISO cell array containing the original message is also used during the state flow processes which are carried by the MPP 108 to produce resulting data which is stored in the other cell arrays of the MPP. Resulting data is moved into cells of the MPP arrays in accordance with the configuration of the MPP. STATE.sub.-- PARM table records include MSG.sub.-- STRUC.sub.-- SID values which designate the cell arrays in the MPP. Because the ISO 8583 message has up to 128 fields that can be used to hold transaction data, data in a significant number of fields may be changed through the state flow processes. As a result of thesc processes new message data is generated by the MPP in the cells of one of its ISO cell arrays. This array which contains the final resulting message generated through the state flow processes carried out by the MPP is schematically shown as Array IV in FIG. 17.
The state flow processes of the MPP are represented by the partial database schema shown in FIG. 25. The Figure shows a state flow table designated STATE.sub.-- FLOW.sub.-- T which is the layout of table records which include a particular MPP SID, MSG TYPE and STATE.sub.-- NUM. A state function table is STATE.sub.-- FUNCTION.sub.-- T and a state class table is STATE.sub.-- CLASS. The various STATE.sub.-- PARM tables show different types of field designators and other information that correspond to the PARM.sub.-- SID determined from a state flow table record. The STATE.sub.-- PARM tables also control the placement of resulting data in the cell arrays of the MPP. Of course, as previously discussed there is a different state flow table record for each state number for a given MPP.sub.-- SID and message type.
The MPP 108 must also derive information concerning where to send the message next. For purposes of this example, we consider a situation where a transaction message is eventually going to be transmitted to an external network for authorization. The identity of the network can be derived by MPP 108 through association with data in the primary account number ("PAN") within the ISO 8583 message. The process of deriving the address of the ultimate system node where the message can be processed is done by the MPP 108 and is demonstrated schematically with reference to FIG. 30.
Card based financial transaction messages in the ISO format include the PAN associated with the card used in connection with the transaction. The PAN includes a PAN prefix. The PAN prefix contains information which can be used to derive information on a particular entity which can authorize a transaction. This is a convention that is established by standards first adopted by the American Banking Association. Unfortunately, the PAN prefix generally varies between four and six digits for financial transactions in the ISO 8583 format.
To begin derivation of information on a system node representative of where the transaction can be authorized, the largest PAN prefix (six digits) is copied from the PAN and compared to columns in a series of BIN.sub.-- ACCEPTED tables indicated 124 in FIG. 30. The PAN prefix is designated the parameter BIN.sub.-- NUM. Each BIN.sub.-- ACCEPTED table record 124 includes a BIN.sub.-- LEN parameter which corresponds to a particular PAN prefix that identifies an AUTH.sub.-- NODE.sub.-- SID. The AUTH.sub.-- NODE.sub.-- SID is the node of the system which corresponds to the authorizing entity.
The MPP begins by iteration through the BIN.sub.-- ACCEPTED table records looking for a match on the initial assumption that the PAN prefix is six digits. It first runs through all the BIN.sub.-- ACCEPTED tables with BIN.sub.-- LEN parameters of six digits. If no match is found, one digit is dropped from the PAN prefix (BIN.sub.-- NUM) and all the table records having a BIN.sub.-- LEN of five digits are checked. Again, if no match is found a digit is dropped from the prefix and table records having BIN.sub.-- LEN of four digits are checked. The process can be continued with three digits and so on if such BIN.sub.-- LEN values are used in a particular system.
When a BIN.sub.-- ACCEPTED table record is found in which the BIN.sub.-- NUM (PAN prefix) and BIN.sub.-- LEN (authorization designator) match, the table provides a NODE.sub.-- SID of the ultimate node for the entity that can authorize the transaction. This AUTH.sub.-- NODE.sub.-- SID is the NODE.sub.-- SID in the system for the external third party authorization network. This NODE.sub.-- SID value is placed by MPP 108 in one of the cells of one of its arrays. In this example MPP 108 uses this ultimate target node value for routing the message that is produced by the MPP as later explained.
The processes carried out in MPP 108 creates a new ISO message array. This is a new message with a new header. A new message is preferably put together from the data in the cells in Array IV of the MPP. The header in fields 1 through 11 of the SME is built by MPP 108 using state flow processes. The MPP includes a "create header" function which generates the new data for the header fields.
For purposes of this example the new message generated by the MPP 108 is one that will ultimately be sent to an external authorization system or network. This is commonly done where the external network must authorize the financial transaction. Generally, the data format used by the external network for its messages will be different from the message format used by the terminal 68 that originated the first transaction message and the SME format used within the system of the present invention. The method in which the new message from the MPP 108 is later processed and converted to the format used by the external network is later discussed in detail.
The new SME format message generated by the MPP 108 has generally new data in header fields 1 through 11 compared to the message that the MPP received from MGR 24. The data in field 1 is the header layout version as shown in FIG. 3. The data in field 1 of the new message will be the same as in the received message because as previously indicated, only one header layout is used in the exemplary system described herein.
Field 2 is the SOURCE.sub.-- NODE.sub.-- SID for the system node originating the message. Because MPP 108 has generated a new message, the node sid value associated with MPP 108 is inserted in this field.
Field 3 is the message receive time for receipt of the message by the system. As MPP 108 has built a new message, the current time is inserted in field 3 by the MPP.
Field 4 contains the internal message sid of the new message. Because the MPP is defined as creating a particular type of new message, the INT.sub.-- MSG.sub.-- SID of the new message is known. The INT.sub.-- MSG.sub.-- SID value for the new message is a function of the message type and format. The message type is part of the ISO format data in field 12 of the SME and the message format is the ISO format used internally by the system. The INT.sub.-- MSG.sub.-- SID value is available from database records associated with each type of ISO message. As a result, the MPP can derive this value or can be configured to insert the value to save processing time. It should be remembered that this INT.sub.-- MSG.sub.-- SID value here is for the message in the SME format that is moving toward an external authorization network. This message will be converted to an external format before being sent.
The MPP 108 also derives the SERVICE.sub.-- SID of an MPP that can next process the new message. The MPP 108 also has available the TARGET.sub.-- NODE.sub.-- SID value of the external network which will receive the new message. This data can be used to complete the data that is needed for fields 5 and 6 of the SME header.
MPP 108 is configured to produce a particular message which will go to a particular external network or system. This ultimate target node sid has a node type terminal table record in shared memory as shown in FIG. 21. The MPP 108 finds the OUT.sub.-- MSG.sub.-- FMT.sub.-- SID for the table record of the ultimate target node. As graphically represented in FIG. 21 this is the eighth column in table portion 82.
The MPP 108 then takes the message type for the new ISO message it has generated. The MPP goes through the message map tables in shared memory which have the OUT.sub.-- MSG.sub.-- FMT.sub.-- SID of the external network (ultimate target node). The MPP finds a message map table record which has the MSG.sub.-- TYPE of its new message. This then provides the INT.sub.-- MSG.sub.-- SID value which corresponds to the message type being sent and the format used by the external network. (See message map table layout in FIG. 22.) The MPP 108 then derives the SERVICE.sub.-- SID for an MPP that can process the message that is going to the external network. This is done by the MPP 108 finding a message router table record which includes the NODE.sub.-- SID for the external network and the INT.sub.-- MSG.sub.-- SID for the message the external network is going to receive. As shown by the layout of message router tables in FIG. 29, the table record with both of these values includes the SERVICE.sub.-- SID of the MPP that can process the message. The SERVICE.sub.-- SID value for this next MPP can be inserted in field 5 of the reader, or if the message is not going directly to an MPP, may be stored in a private field of the message in field 12 for later use. Storage for later use may be done where the message is first going to a timer component before the next MPP, as later discussed.
The NODE.sub.-- SID of the MPP to which the new message generated by MPP 108 will be sent is now derived by MPP 108. As shown in FIG. 29, the service provider table record including the SERVICE.sub.-- SID has the MPP.sub.-- SID value which is the NODE.sub.-- SID of the MPP which can process the new message MPP 108 has generated. This data can be inserted in field 6 of the message by MPP 108 as the "target node" for the message. Alternatively, the ultimate destination node can be designated as the target node sid in field 6. The setting of the "message direction" in field 8 allows two alternative routing approaches later discussed. However, if the message from MPP 108 is going to a timer before being sent to the next MPP, the target node sid value for the ultimate node can be placed in a private field in the ISO message in field 12 of the SME for later use in a manner that will be explained.
As is apparent from the above discussion, MPPs can generally be thought of as dealing with a particular external data format and the SME format. The MPP deals with incoming and outgoing messages of the particular format. The processing of messages by the MPP is determined by the message type and direction.
MPP 108 also completes the other fields in the header of the SME for the message it has generated. As indicated in FIG. 3, field 7 is the data format indicator for the source of the message. In this case the MPP is the source of the message so its field 7 data indicates an internal data source. This is true of all messages generated by MPP 108.
Field 8 indicates message direction. Message direction in the preferred embodiment is "1" for "in", "2" for "out" and "3" for "MPP to MPP". If the message is being sent directly to the next MPP, field 8 would be set to "3". If the direction is set to "3" the message will be routed based on the SERVICE.sub.-- SID value in field 5 of the message. However, if the NODE.sub.-- SID of the next MPP (as opposed to the ultimate target node) is placed in field 6 of the message the MPP sets field 8 to "1" and the message will be routed based on field 6 data.
Alternatively, if the message will be sent to a timer before going to a next MPP, the message direction would be set to "2" for "out". The MPP would put the NODE.sub.-- SID of a timer in field 6 and the ultimate destination node would be stored in a private field in the ISO message in field 12. As later explained, the timer software component which enables asynchronous transaction processing is treated as an external device.
Field 9 is the processing time. This is additive from the time the original message from terminal 68 entered the system. In this example MPP 108 would add its processing time to the value in field 9.
Field 10 is the last processing node for the new message. The NODE.sub.-- SID for MPP 108 is inserted by the MPP in this field.
As previously discussed, field 11 is used when the terminal which originated the original message is part of a line group. It is used to find the line driver which has picked up the line that the terminal dialed. In this example where terminal 68 is not part of a line group field 11 would be a zero value. In other examples where the terminal originating the message is part of a line group, the value in field 11 of the message generated by MPP 108 would be the same as the incoming message to the MPP.
It should be understood that MPPs are generally configured by the system operator. The user has the ability using the graphical user interface 66 and input devices associated with the computer to set the state flows which build the new message in a manner desired for the particular system. The user also has the option to take advantage of opportunities to shorten transaction processing times by saving values for reuse later in private fields in the ISO message in field 12 of the SME. This is done by defining a layout for table records for the subfield where the data is to be stored in particular message types. This is represented by the layout for ISO Subfonnat and ISO Subfield table records in FIG. 29. This data can then be used to achieve shortcuts by having the next MPP look for this data in an incoming message before taking steps to derive the same data.
The MPP 108 also creates transaction records. A state in MPP 108 executes a "create transaction record" function in re |
