EP0968479B1

EP0968479B1 - A transaction processing system

Info

Publication number: EP0968479B1
Application number: EP97915658A
Authority: EP
Inventors: Patrick Clarke; George Burne; Hubert O'donoghue; Eoin Flood; Timothy O'sullivan; Francis O'rourke; David O'neil; John Trintech Limited McGUIRE; Christopher Meehan; Cyril Mcguire
Original assignee: Trintech Ltd
Current assignee: Trintech Ltd
Priority date: 1997-03-19
Filing date: 1997-03-19
Publication date: 2005-07-13
Anticipated expiration: 2017-03-19
Also published as: ATE299607T1; JP2001519941A; EP0968479A1; DE69733718D1; WO1998041940A1; AU2305097A

Abstract

A transaction processing system (1) communicates with point-of-sale terminals (8) via a communications sub-system (3) which performs communications and protocol routing, and a transaction logic sub-system (4) which performs transaction logic-based routing. Transaction signals are processed internally in the system on a processor (4(b)) or are routed to external processors (10). Message traffic is minimised by operation of incoming partners (20) and associated outgoing partners (23) writing data to a variable database (7(a)) and retrieving this data if required at a subsequent stage in the process.

Description

The invention relates to a transaction processing system, and more particularly to host or central processing of point-of-sale transaction in real-time in communication with point-of-sale terminals.

In recent years, payment technology has been changing rapidly, with increasingly complex and more numerous types of cards being used. In contrast to the more traditional magnetic stripe cards which typically have less than 50 bytes of data, newer types of card with on-board chips result in communication and processing of considerably more data than has heretofore been the case. Such payment methods include smart cards, secure electronic transaction (SET), corporate purchase cards, off-line debit cards, electronic purse cards, etc.

Because of these developments, the transaction processing systems operated by card issuers must be capable of comfortably handling many simultaneous transactions in which the data size per transaction may be up to 1KB.

This must be achieved within a maximum response time of 30 seconds for external processing, or sub-second for internal processing.

Another requirement is that the transaction processing system be expandable in a modular manner to handle different levels of simultaneous transactions. A further requirement is that the system be easily modified for handling different transaction types.

Various developments have been made in this area of technology, including the apparatus described in US 4751374 (Omrom) which describes an improved method for summation of data and in US 4396624 (Visa) which describes an improved mechanism for memory management.

PCT Patent Specification No. WO 95/12269 discloses that the general objective of providing a transaction processing system which would accommodate improved data handling capabilities required by developments in card technologies is well known and that the problem has been apparent for some considerable time. This particular patent specification discloses a transaction card network, a communications system and a transaction processing means, all of which are well known in the art. The specification is directed towards providing a more efficient communication system used in the processing of such payments. However, it does not address the serious problem of how the actual transactions are to be handled. The need is to handle a large number of transaction signals simultaneously.

Similarly, US Patent Specification No. 5280625 discloses a communications network which is satellite linked such that point-of-sale terminals in the form of transaction or credit card readers are linked to a host computer. Again, the invention is directed towards the communications problems rather than the data handling problems.

British Patent Specification No. 2281648 discloses an in-house credit card authorisation method and while it may be relatively successful for a small number of transactions, unfortunately it does not overcome the major problem that the present invention addresses.

Two published articles of interest discuss the problem and very clearly show why there are serious problems that need to be addressed in credit card and other payment card transaction processing systems. These articles are Walton, J. "Credit Card Data Capture", Computer Bulletin June 1986 UK, Vol. 2, Ser. 3, Pt. 2, ISSN 0010-4531 and Linden LF "Plastic Card Technology - Look for Brisk, Orderly Evolution (Financial DP)" Magazine of Bank Administration - January 1984, USA, Vol. 60, No. 1, ISSN 0024-9823, Pages 22-25, XP 0020448300.

However, while there have been such developments in specific areas of transaction processing, there is need for a comprehensive and overall structure to cope at a technical level with the growing and changing demands of transaction processing.

The invention provides a transaction processing system according to claim 1.

The use of the communication handlers, the incoming and outgoing partners, and the variable database in this way breaks the processing down to separate communications and transaction logic-based elements. Thus, the system may be easily upgraded/expanded. Further, high simultaneous throughput may be easily controlled.

In one embodiment, each incoming partner comprises means for transmitting only a general section of the signal to the outgoing partner, and writing the balance of the data to the variable database. This minimises internal signal traffic and required processing capacity.

Preferably, each outgoing partner comprises means for monitoring contents of the received general signal according to transaction logic and means for appending variable fields retrieved from the variable database to the signal to generate a transaction processing signal. This allows a large degree of flexibility.

In one embodiment, each outgoing partner additionally comprises means for retrieving static data from a static database to generate the transaction processing signal. The data break-down between the variable and static databases allows fast data retrieval.

Preferably, each outgoing partner comprises means for transmitting a transaction processing signal to a remote host system for transaction processing according to transaction logic. This also provides excellent flexibility.

In one embodiment, data is stored in the database in a series of linked strings, each string having a set of data fields and an identifier for the next string in the chain, the first strings in the chain relating to more general information. This allows very fast data access in real time without sacrificing flexibility in data record size.

In one embodiment, components of the system reside on physically separate data processing hardware machines and signals are communicated between tasks on different machines via a message server which comprises means for reading a queue identifier and routing the signal to a queue associated with the receiving task. This provides excellent signal transfer control in a distributed environment.

Preferably, the system further comprises a status server which stores global data relating to all available tasks in the system and provides functions to access the global data. This allows universal dissemination of information across the system among all components - particularly important for a distributed environment.

In one embodiment, each machine of the system comprises a task server comprising means for controlling performance of tasks on its associated machine. Preferably, each task server comprises means for providing said message queue identifier. These features allow efficient real time task control.

Preferably, the system further comprises a monitor comprising means for transmitting messages to the status server and to the task servers from a user interface.

Ideally, said communication handlers are each directly linked to a particular port. This feature allows very fast communications routing.

In one embodiment, said transaction processor is also an outgoing partner. The system may have some dedicated transaction processors, all internal processing may be performed by the outgoing partners, or there may be a mix.

Preferably, said transaction processor comprises means for routing the output signal to the point-of-sale terminal via the outgoing partner, the incoming partner, the communications handler, and the associated port. By returning on the original path, the various nodes can immediately re-transmit using stored data and logic.

The invention will be more clearly understood from the following description of some embodiments thereof, given by way of example only, with reference to the accompanying drawings, in which:-

Fig. 1 is an overview representation showing a transaction processing system of the invention and the environment within which it operates;

Fig. 2 is a block diagram illustrating the major components of the system;

Fig. 3 is a diagram illustrating a primary routing section of the system;

Fig. 4 is a diagram illustrating operation of a secondary routing section of the system; and

Figs. 5 and 6 are diagrams illustrating the manner in which messages are routed and tracked within the system.

Referring to Fig. 1, there is shown a transaction processing system 1 of the invention. The system 1 comprises local and wide area network links 2 which interconnect communications machines 3 and a transaction handling machine 4. The machine 4 is connected to a database 7.

The links 2 which interconnect the different parts of the system 1 are based on a TCP IP Protocol, with an Ethernet™ hardware link. The network link may alternatively be of the FDDI or Token Ring types, for example.

The system 1 communicates in real-time with a large number of point-of-sale terminals 8 and also with

external processors

10, 11 and 12. The terminals 8 may be single point-of-sale devices or point-of-sale systems handling many transactions.

The system 1 operates to communicate with the point-of-sale terminals 8 in real-time to receive transaction signals, either processes the transactions itself ("on-us"), or directs the signals to an

external system

10, 11 or 12 depending upon the particular requirements. The output is then routed back to the relevant point-of-sale terminal 8. All this takes place in real-time.

Referring now to Fig. 2, the logical structure of the system 1 is illustrated. The communication machines 3 form sub-systems which provide primary routing in a symmetrical manner, each end providing two-way communication via ports and communication devices such as modems.

The machine 4 provides secondary routing based on transaction logic, again in a symmetrical manner and acts as a buffer between the communication sub-systems 3 and a transaction processing sub-system 4(b) residing on the machine 4. The communication sub-systems 3 direct signals to the external processors 10 and also receive the results back for communication to the relevant point-of-sale terminals. Both the transaction logic routing and the transaction processing is carried out in conjunction with the database system 7, which has a variable database 7(a) and a static database 7(b). The variable database 7(a) stores data generated in real time and associated with particular transactions. On the other hand, the static database 7(b) stores data which is pre-set, such as a credit card limit or person's address.

Referring now to Fig. 3, construction of a communications sub-system 3 is illustrated. The router 3 has ports 15, up to several hundred in number. Each port is directly associated with a particular communications handler 18, to which it transmits every received signal. Received signals are thus immediately routed to a particular communications handler 18.

Each communications handler 18 is programmed to relay the received signal, without modifying it in any way, to a particular incoming partner on a transaction logic sub-system 4(a) after completing communication tests such as LRC checks.

There is a many-to-one relationship of communication handlers 18 to incoming partner for each major type of signal. In this case it is approximately four to one. The types of signal include authorisation requests and data/batch capture requests. The handlers 18 have sufficient intelligence to filter according to the signal type, without processing message contents.

Referring now to Fig. 4, operation of a transaction logic sub-system 4(a) is illustrated. For data capture the incoming partner 20 writes to the database 7. During real-time transaction processing an incoming partner 20 receives a full transaction signal 21 and validates it according to transaction-based logic. An important aspect of the incoming partner 20 is that it retrieves certain fields from the incoming signal and generates a generic signal 22 which it immediately transmits to an associated outgoing partner 23.

The fields 24 of data which are not transmitted to the outgoing partner 23 are written to the variable database 7(a) by the incoming partner 20.

The outgoing partner 23 reads the data fields within the generic signal 22 and determines according to transaction logic whether or not additional data is required for processing of the signal. Most often, such data is not required, however, if it is required, some or all of the variable data (indicated as 26) which was written to the variable database 7(a) is retrieved. In addition, the outgoing partner 23 receives data from the static database 7(b). This data includes additional data which can be retrieved by "hooks" in the message. An example is a category code for a merchant.

In this way, the outgoing partner 23 re-constitutes a signal 28 which is transmitted to a processor for processing of the transaction. The decision as to which processor processes the transaction is based on transaction logic. The processor may be internal to the system 1, namely in the sub-system 4(b) (possibly on a different hardware machine). The processor may alternatively be remote, in which case the transaction processing signal is routed through the other side of the system 1 to the external processor. In certain cases, the outgoing partner may perform the processing - giving more distributed internal processing and thus a higher throughput. This may require provision of multiple databases. Whichever element processes the transaction uses the static database to firstly authorise the transaction, and secondly to update data such as the credit limit. This data is indicated as S.

On the return path, the output from the processor which processes the signal is routed through the outgoing partner 23, the incoming partner 20, the handler 18 and then back to the originating point-of-sale terminal via the relevant port 15.

The following sets out an example of the signals which are transmitted in the system 1.

The original signal 21 may include:-

The variable signal 24 which is written to the variable database 25 may be represented as:-

As shown in Fig. 4 next to the variable database 7(a), data is stored in the database system 7 in a chained arrangement in which there is an initial record having main data followed by an outgoing identifier. The main data may be regarded as the primary data for a record. The outgoing identifier is a chain link to a next sequence of fields which begins with the identifier, followed by specific data and one or more outgoing identifiers. Each of the outgoing identifiers links this sequence to a next sequence beginning with the identifier and followed by the data. Each of the individual strings is of a fixed length to provide simple database control. However, as is clear from this structure, the overall record is of indefinite length. Each sequence includes a merchant identifier, and a terminal identifier for easy retrieval and access.

Referring now to Fig. 5, the manner in which signals or messages are communicated between the different components of the system 1 is now illustrated. In the example given, there is communication between a communication machine 3 and a transaction handling machine 4. The machine 3 has a number of communication handlers 18, an RPC message server 30 and an RPC task server 40. The machine 4 also has an RPC message server 30 and an RPC task server 40. The partners on the machine 4 are indicated generally by the

numerals

20 and 23 and are implemented by software tasks, each having both an incoming partner and the associated outgoing partner. In this embodiment, the tasks illustrated are all incoming/outgoing partner pairs and all transaction processing of the system is performed by these tasks, unless performed remotely. However, the machine 4 may have tasks which only perform transaction processing upon receipt of signals from an outgoing partner. The function of the message server 30 in the machine 4 is to receive variable length messages from the communication handlers 18 and to route them to a specified local message queue, namely an incoming partner 20. Communication between a communication handler 18 and an incoming partner 20 is indirect, via the two message servers 30. The receiving message server uses a message queue identifier embedded in the signal by the client in order to direct the signal to the appropriate queue. The message server 30 does not need to know the contents of the message. The following is the structure of a message which is passed between a communications handler and a partner:-

nMsgType is the type of the message being sent.
nMsgQID is the ID of the message queue the remote procedure writes to.
nMsgLen is the length of the message being sent.
cMsg is the buffer being sent across and MBUFSIZE is the maximum size of the buffer.

In order for the client to determine the queue identifier to be inserted in the signal, it must pass to the task server the task identifier it wants to communicate with and the machine name that the task is running on. The task server 40 keeps information on all tasks and so returns the appropriate message queue identifier to the client. The client is then able to transmit the signal to the message server 30.

Referring now to Fig. 6, use of the task servers 40 is illustrated. The task server 40 is particularly effective at providing control in the distributed environment of the transaction processing system 1. The main message-handling processes in the system include a status server 60, several task servers 40, a monitor 50, and a user interface 70 which transmits commands to the monitor 50. The other processes are the communications handlers 18 and the

partners

20 and 23.

The status server 60 holds global data about all available tasks in the system 1 and provides functions to access this data. There is one task server 40 per hardware machine in the system 1. There is one monitor 70 in the system 1 and it transmits messages to the status server 60 and to the task servers 40. A user interacts with the system 1 through the interface 70, which in turn interacts with the monitor 50.

The status server 60 manages a static global array of shared memory which contains details about all the tasks in the system 1. Any communication with the status server 60 is performed through RPC function calls. The global memory array is read from or written to indirectly by any task on any machine by calling the status server's public RPC functions, or by the tasks themselves writing directly to the status server's shared memory. The size of the array is hard-coded to hold information about 300 task processes. This size cannot be changed at run-time. In summary, the status server 60:-

receives RPC messages from tasks,

updates global shared memory as required,

receives RPC messages from the monitor 50 and sends it information about tasks as requested, and

re-reads the task configuration file at regular intervals to add/update/remove tasks in the system 1.

It will be appreciated that the invention provides a system which operates very effectively to handle a large number of transaction signals simultaneously. This level of control is achieved by distributing the tasks between the communications handlers, the incoming partners, the outgoing partners, and the internal transaction processors (task processors). By directly linking communications handlers with ports there is a very fast protocol-based routing within the system. Further, by use of incoming and outgoing partners which use transaction logic to process the signals with reference to the variable and static databases, the size of the messages being handled is minimised and the signal may be processed very efficiently. The processor which performs the transaction processing (either the outgoing partner, another internal processor or an external processor) is able to handle the signal very efficiently because of the manner in which the message is handled before it is received. The implementation of these processes on machines connected in a distributed manner is achieved very effectively by use of the task servers, the message servers, the status server and the monitor.

The invention is not limited to the embodiments described, but may be varied within the scope of the claims in construction and detail.

Claims

A transaction processing system of the type comprising:-

a communications sub-system connected to external point-of-sale terminals and having communications handlers;

means for validating incoming signals received from the communications handlers according to transaction logic;

a variable database (7a);

means for writing incoming signals received in real time to the database;

means in the system for generating a transaction processing signal;

a transaction processor associated therewith; and

means in the communications sub-system for subsequent routing to the originating point-of-sale terminal of signals from the transaction processor characterised in that

the communications sub-system (3) has a plurality of ports (15) for communication with the point-of-sale terminals (8), each port (15) being directly connected to a specific communications handler (18) forming part of a transaction logic sub-system (4a) at least two communications handler incoming partners (20) connected to each communications handler to form part of the transaction logic sub-system (4a), each incoming partner (20) being adapted to handle a specific type of incoming signal received from the communications handler;

an associated communications handler outgoing partner (23) connected to each incoming partner (20) for a received signal (22) from the incoming partner (20) and the transfer of signals back and forth with the incoming partner (20), the transaction processor and the point-of-sale terminals (8), the means for validating the incoming signals being included in the incoming partner (20).
A system as claimed in claim 1, wherein each incoming partner (20) comprises means for extracting a general section (22) of the incoming signal (21) for subsequent transmission as the received signal (22) to the associated outgoing partner (23), and writing the balance of the data (24) to the variable database (7a).
A system as claimed in claim 2, wherein each outgoing partner (23) comprises means for monitoring contents of the received general signal (22) according to transaction logic and means for appending variable fields (26) retrieved from the variable database (7a) to the signal (22) to generate a transaction processing signal (28).
A system as claimed in claim 3, wherein each outgoing partner (23) additionally comprises means for retrieving static data from a static database (7b) to generate the transaction processing signal (28).
A system as claimed in any preceding claim, wherein each outgoing partner (23) comprises means for transmitting a transaction processing signal (28) to a remote host,system for transaction processing according to transaction logic.
A system as claimed in any preceding claim, wherein data is stored in the database (7) in a series of linked strings, each string having a set of data fields and an identifier for the next string in the chain, the first strings in the chain relating to more general information.
A system as claimed in any preceding claim, wherein components of the system reside on physically separate data processing hardware machines (4) and signals are communicated between tasks on different machines via a message server (30) which comprises means for reading a queue identifier and routing the signal to a queue associated with the receiving task.
A system as claimed in any preceding claim, further comprising a status server (60) which stores global data relating to all available tasks in the system and provides functions to access the global data.
A system as claimed in any preceding claim, wherein each machine of the system comprises a task server (40) comprising means for controlling performance of tasks on its associated machine.
A system as claimed in any of claims 7 to 9, wherein each task server (40) comprises means for providing said message queue identifier.
A system as claimed in any preceding claim, further comprising a monitor (70) comprising means for transmitting messages to the status server (60) and to the task servers (40) from a user interface.
A system as claimed in any preceding claim, wherein said communication handlers (18) are each directly linked to a particular port (15).
A system as claimed in any preceding claim, wherein said transaction processor is also an outgoing partner (23).
A system as claimed in any preceding claim, wherein said transaction processor comprises means for routing the output signal to the point-of-sale terminal (8) via the outgoing partner (23), the incoming partner (20), the communications handler (18), and the associated port (15).