Browse Prior Art Database

Lazy Protocols for Transaction Systems Disclosure Number: IPCOM000015863D
Original Publication Date: 2002-Apr-15
Included in the Prior Art Database: 2003-Jun-21

Publishing Venue



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 delays; or may be set based on fixed criteria, including security level of the communications link, source of the request, and so forth. In general terms, this would be implemented as some kind of qualified ACK from the server to the client which might include a 'Ready to commit this transaction'-type qualifier on the ACK to a given packet. The closest similar approach that we are aware of is in Dialogue Management for speech-enabled automated services. The Dialogue Manager retains a running status of how much information has been received, and will determine (i) what the next step is (how to prompt the user for the next piece of information); and (ii) when sufficient information based on fields being 'Optional' has been received to complete the transaction. This operates at the application level, and is bound to a specific task and specific interaction. Our proposal differs from this in that we implement the client-server negotiation at the protocol level, which increases the flexibility allowing the transaction to be explicitly controlled more easily. At a protocol level, of course, data 'packets', for instance during a stream or UDP connection, are individually checked and acknowledged. This guarantees that any out-of-sequence packets can be reordered, or that any missing packets can be resent. Our proposal differs from this, however, in that this is a purely mechanical process relating to any data transmission, with the goal to ensure all packets are received in accordance with the rules of the protocol. Instead, we are proposing that at the next