Browse Prior Art Database

Lazy Protocols for Transaction Systems

IP.com Disclosure Number: IPCOM000015863D
Original Publication Date: 2002-Apr-15
Included in the Prior Art Database: 2003-Jun-21
Document File: 2 page(s) / 41K

Publishing Venue

IBM

Abstract

This proposal relates to the provision, at a protocol level, of an additional interchange between two parties or processes to determine whether sufficient information or detail has been passed for the successful completion of a transaction without having to wait for the complete, prescribed interchange to be executed, thereby potentially reducing response times and network traffic.

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 52% of the total text.

Page 1 of 2

Lazy Protocols for Transaction Systems

This proposal relates to the provision, at a protocol level, of an additional interchange between two parties or processes to determine whether sufficient information or detail has been passed for the successful completion of a transaction without having to wait for the complete, prescribed interchange to be executed, thereby potentially reducing response times and network traffic.

     Our proposal relates to any transactional system which the following example may serve for illustrative purposes: for on-line banking, for instance, the user must provide various information to the bank's server so that the server can authorise or complete a transaction, such as account number, date, time, amount, and perhaps PIN. During the interchange between client application and the server, information 'packets', in the sense of individual details, are transmitted quasi asynchronously to the server. The information is used by the server, as the end-user continues to fill in details, to access a database and begin matching input to the record or records retrieved from the database. What we are proposing is that as soon as sufficient information is received, then the server will simply interrupt the upload of additional information and request confirmation that the transaction can be completed, even though not all fields have been provided. 'Sufficient information' may, we suggest, be determined in a number of different ways: (a) based on Customer profile; (b) based on a 'fuzzy match' between the current information and the complete record in the database; and/or (c) based on preset levels of acceptability depending on the nature of the transaction to be completed. This may be dynamically altered, for instance to reduce the overall threshold before the server resumes control and interrupts the transfer of additional information based on perceived network...