System, method and article of manufacture for managing transactions in a high availability system

• US 6,363,363 B1
• Filed: 08/24/1999
• Issued: 03/26/2002
• Est. Priority Date: 06/17/1996
• Status: Expired due to Term

• Current Assignee: Hewlett Packard Enterprise Development LP (Hewlett-Packard Enterprise Company)
• Original Assignee: Verifone, Inc. (Verifone Systems, Inc.)
• Inventors: Kramer, Glenn A., Nguyen, Trong, Rowney, Kevin T. B., Haller, Daniel R., Berger, David A.
• Primary Examiner(s): Peeso, Thomas R.
• Application Number:
  US09/382,718
• Time in Patent Office: 945 Days
• Field of Search: 705/77, 705/80, 705/26, 705/27, 705/29, 705/34, 705/40, 709/203, 709/219, 709/227, 709/230, 709/238, 709/245, 709/250, 709/249
• US Class Current: 705/40
• CPC Class Codes: G06Q 20/00 Payment architectures, schemes or protocols apparatus for performing or posting payment transactions G07F7/08, G07F19/00; electronic cash registers G07G1/12
• CPC Class Codes: G06Q 20/085 involving remote charge determination or related payment systems
• CPC Class Codes: G06Q 20/10 specially adapted for electronic funds transfer [EFT] systems; specially adapted for home banking systems
• CPC Class Codes: G06Q 20/102 Bill distribution or payments
• CPC Class Codes: G06Q 30/04 Billing or invoicing

Abstract

An architecture is disclosed allowing a server to communicate bidirectionally with a gateway over a first communication link, over which service requests are initiated by the server. In response to a transaction received from a host legacy system at the gateway, the gateway parses one or more transaction response values from the host message, maps the one or more transaction response values to a canonical response code, and stores the canonical response code in a transaction log. According to a broad aspect of a preferred embodiment of the invention, communication networks that employ transactions between applications must effectively manage transactions that flow over the network. In addition, networking systems must also detect counterfeit transactions, especially, when the networking systems are utilized for financial transactions. An active, on-line database is utilized as a transaction log to track original requests, valid retrys and detect fradulant transactions. The transaction log serves as a memory cache where the received host response is returned to a valid retry transaction should the original response fail to reach a server because of a communications problem.

Claims

1. A method for processing a transaction request at a gateway communicably connected to a server via a first communication link and a host via a second communication link, comprising the steps of:

receiving the transaction request from the server via the first communication link;

extracting one or more data elements from the transaction request;

determining whether the transaction request is a retry request or a new request based on at least one of the extracted data elements;

updating a transaction database whenever the transaction request is the retry request; and

storing the extracted data elements in the transaction database, generating a host transaction request using the extracted data elements and transmitting the host transaction request to the host via the second communication link whenever the transaction request is the new request.

2. The method of claim 1, wherein the one or more data elements of the transaction request comprises:

a merchant'"'"'s transaction identifier; and

a request response pair identifier.

3. The method of claim 2, wherein the request response pair identifier comprises:

a first part that remains the same for the same request for all retry attempts; and

a second part that indicates the number of retry attempts.

4. The method of claim 2, wherein the transaction request further comprises:

a merchant identifier;

a terminal identifier;

a request date; and

a field containing request specific data.

5. The method of claim 1, wherein the step of determining whether the transaction request is a retry request or a new request based on at least one of the extracted data elements comprises:

determining a retry count from at least one of the extracted data elements;

identifying the transaction request as the new request when the retry count is equal to zero; and

identifying the transaction request as the retry request whenever the retry count is greater than zero.

6. The method of claim 5, wherein the extracted data elements includes a request response pair identifier and the retry count is determined from the request response pair identifier.

7. The method of claim 1, wherein the step of determining whether the transaction request is a retry request or a new request based on at least one of the extracted data elements comprises:

determining a retry count from the extracted data elements;

determining whether the transaction request is already recorded in the transaction database by comparing at least one of the extracted data elements to one or more previously extracted data elements stored in the transaction database;

identifying the transaction request as the new request when the retry count is equal to zero and the transaction request is not already recorded in the transaction database; and

identifying the transaction request as the retry request whenever the retry count is greater than zero and the transaction request is already recorded in the transaction database.

8. The method of claim 1, wherein the step of updating a transaction database whenever the transaction request is the retry request further comprises:

determining whether a host response corresponding to the transaction request has been received from the host;

generating a transaction response using the host response and transmitting the transaction response to the server via the first communication link when the host response has been received from the host; and

generating a host retry request for the transaction request and transmitting the host retry request to the host via the second communication link when the host response has not been received from the host.

9. An apparatus for processing a transaction request at a gateway communicably connected to a server via a first communication link and a host via a second communication link, comprising:

means for receiving the transaction request from the server via the first communication link;

means for extracting one or more data elements from the transaction request;

means for determining whether the transaction request is a retry request or a new request based on at least one of the extracted data elements;

means for updating a transaction database whenever the transaction request is the retry request; and

means for storing the extracted data elements in the transaction database, generating a host transaction request using the extracted data elements and transmitting the host transaction request to the host via the second communication link whenever the transaction request is the new request.

10. The apparatus of claim 9, wherein the one or more data elements of the transaction request comprises:

a merchant'"'"'s transaction identifier; and

a request response pair identifier.

11. The apparatus of claim 10, wherein the request response pair identifier comprises:

a first part that remains the same for the same request for all retry attempts; and

a second part that indicates the number of retry attempts.

12. The apparatus of claim 10, wherein the transaction request further comprises:

a merchant identifier;

a terminal identifier;

a request date; and

a field containing request specific data.

13. The apparatus of claim 9, wherein the means for determining whether the transaction request is a retry request or a new request based on at least one of the extracted data elements comprises:

means for determining a retry count from at least one of the extracted data elements;

means for identifying the transaction request as the new request when the retry count is equal to zero; and

means for identifying the transaction request as the retry request whenever the retry count is greater than zero.

14. The apparatus of claim 9, wherein the means for determining whether the transaction request is a retry request or a new request based on at least one of the extracted data elements comprises:

means for determining a retry count from the extracted data elements;

means for determining whether the transaction request is already recorded in the transaction database by comparing at least one of the extracted data elements to one or more previously extracted data elements stored in the transaction database;

means for identifying the transaction request as the new request when the retry count is equal to zero and the transaction request is not already recorded in the transaction database; and

means for identifying the transaction request as the retry request whenever the retry count is greater than zero and the transaction request is already recorded in the transaction database.

15. The apparatus of claim 14, wherein the extracted data elements includes a request response pair identifier and the retry count is determined from the request response pair identifier.

16. The apparatus of claim 9, wherein the means for updating a transaction database whenever the transaction request is the retry request further comprises:

means for determining whether a host response corresponding to the transaction request has been received from the host;

means for generating a transaction response using the host response and transmitting the transaction response to the server via the first communication link when the host response has been received from the host; and

means for generating a host retry request for the transaction request and transmitting the host retry request to the host via the second communication link when the host response has not been received from the host.

17. A computer program embodied on a computer-readable medium for processing a transaction request at a gateway communicably connected to a server via a first communication link and a host via a second communication link, comprising:

a code segment for receiving the transaction request from the server via the first communication link;

a code segment for extracting one or more data elements from the transaction request;

a code segment for determining whether the transaction request is a retry request or a new request based on at least one of the extracted data elements;

a code segment for updating a transaction database whenever the transaction request is the retry request; and

a code segment for storing the extracted data elements in the transaction database, generating a host transaction request using the extracted data elements and transmitting the host transaction request to the host via the second communication link whenever the transaction request is the new request.

18. The computer program of claim 17, wherein the one or more data elements of the transaction request comprises:

a merchant'"'"'s transaction identifier; and

a request response pair identifier.

19. The computer program of claim 18, wherein the request response pair identifier comprises:

a first part that remains the same for the same request for all retry attempts; and

a second part that indicates the number of retry attempts.

20. The computer program of claim 18, wherein the transaction request further comprises:

a merchant identifier;

a terminal identifier;

a request date; and

a field containing request specific data.

21. The computer program of claim 17, wherein the code segment for determining whether the transaction request is a retry request or a new request based on at least one of the extracted data elements comprises:

a code segment for determining a retry count from at least one of the extracted data elements;

a code segment for identifying the transaction request as the new request when the retry count is equal to zero; and

a code segment for identifying the transaction request as the retry request whenever the retry count is greater than zero.

22. The computer program of claim 21, wherein the extracted data elements includes a request response pair identifier and the retry count is determined from the request response pair identifier.

23. The computer program of claim 17, wherein the code segment for determining whether the transaction request is a retry request or a new request based on at least one of the extracted data elements comprises:

a code segment for determining a retry count from the extracted data elements;

a code segment for determining whether the transaction request is already recorded in the transaction database by comparing at least one of the extracted data elements to one or more previously extracted data elements stored in the transaction database;

a code segment for identifying the transaction request as the new request when the retry count is equal to zero and the transaction request is not already recorded in the transaction database; and

a code segment for identifying the transaction request as the retry request whenever the retry count is greater than zero and the transaction request is already recorded in the transaction database.

24. The computer program of claim 17, wherein the code segment for updating a transaction database whenever the transaction request is the retry request further comprises:

a code segment for determining whether a host response corresponding to the transaction request has been received from the host;

a code segment for generating a transaction response using the host response and transmitting the transaction response to the server via the first communication link when the host response has been received from the host; and

a code segment for generating a host retry request for the transaction request and transmitting the host retry request to the host via the second communication link when the host response has not been received from the host.