Dismiss
InnovationQ will be updated on Sunday, Oct. 22, from 10am ET - noon. You may experience brief service interruptions during that time.
Browse Prior Art Database

Transaction Integrity with Mobile Computers and Smartcards

IP.com Disclosure Number: IPCOM000118036D
Original Publication Date: 1996-Aug-01
Included in the Prior Art Database: 2005-Mar-31
Document File: 2 page(s) / 92K

Publishing Venue

IBM

Related People

Lambourn, SK: AUTHOR [+3]

Abstract

In many circumstances, it is important to know positively whether a remote computer system has been updated. Transaction integrity protocols (e.g., two-phase commit) are normally used to ensure this. However, when a remote computer system is mobile, it may never be in direct communication with the same partner in the future. Examples could be a laptop which docks at different buildings, or a smart-card which could be used at many different retail outlets.

This text was extracted from an ASCII text file.
This is the abbreviated version, containing approximately 53% of the total text.

Transaction Integrity with Mobile Computers and Smartcards

      In many circumstances, it is important to know positively
whether a remote computer system has been updated.  Transaction
integrity protocols (e.g., two-phase commit) are normally used to
ensure this.  However, when a remote computer system is mobile, it
may never be in direct communication with the same partner in the
future.  Examples could be a laptop which docks at different
buildings, or a smart-card which could be used at many different
retail outlets.

      In these cases, if a transaction is interrupted before the
final confirmation, one or both partners are in doubt about whether
the transaction completed or not.  It may be very expensive or
impossible to guarantee communication between the two partners so as
to complete the transaction.  Furthermore, this in-doubt system may
undermine the user's confidence in the system.

      In most value transfer systems, in doubt transactions should
not allow the creation of duplicate value (in some cases this will be
illegal) and the destruction of value is highly undesirable although
acceptable on a small scale.

      A different example occurs when a transaction is too long to be
completed during a single connection - for example, where significant
offline or manual processing is required before the transaction can
be completed (for example, confirming identity or credit details).
In these cases, the business transaction is broken by mutual consent
into two IT transactions and there remains the problem of 'dialling
out' to a  mobile which will usually be offline, once the second IT
transaction is  approved.

      By adapting and enhancing the two-phase commit protocols with
the additional 'beaconing' concepts described below, transaction
integrity can be effectively maintained.  The basic protocol as used
here is as follows:
  1.  The base station notifies the mobile to prepare to carry
       out the transaction.
  2.  The mobile notifies the base to commit the transaction.
  3.  The base station confirms the transaction is committed.

The additions are as follows:
  o  The use of 'beaconing' to broadcast in-doubt transactions
      back to base stations on subsequent uses (one or more times).
      These would occur if the mobile had initiated the commit but
      had not received confirmation from the base.  The mobile
      'beacons' the in-doubt transaction a pre-determined number
      of times or for a pre-determined elapsed time, and then
      reverts to a pre-determined known state (either completing
      or rolling back the transaction).  In any...