Transaction system

Data processing: financial – business practice – management – or co – Business processing using cryptography – Secure transaction

Reexamination Certificate

Rate now

  [ 0.00 ] – not rated yet Voters 0   Comments 0

Details

C705S067000, C705S065000, C380S046000, C713S170000, C713S172000, C713S184000

Reexamination Certificate

active

06236981

ABSTRACT:

BACKGROUND OF THE INVENTION
1. Field of the Invention
The present invention relates to a digital payment transaction system.
2. Related Art
With the growth and commercialisation of the internet, there has been an increasing need for technologies to allow payments to be made on-line. For transactions of relatively high financial value this need is adequately met, for example, by systems using electronic cheques issued by a trusted party such as a bank. Such electronic cheques are typically validated by a signature which is encrypted using a public key algorithm such as RSA. There is however a significant computational overhead associated with the use of such algorithms. Therefore, just as in real life a cheque is unlikely to be acceptable for a purchase of small value because of the associated transaction costs, so also in electronic commerce, electronic cheques are not suitable for payments of low value.
A number of proposals have been made for alternative transaction systems suitable for making the so-called “micropayments” required by low-value transactions. However, it has proved technically difficult to provide the low processing overheads required for any micropayment technology whilst maintaining an adequate level of security.
One example of a previous proposal for a micropayment system is that developed by the US corporation Digital and known as “Millicent”. This system is described by its proponents as a lightweight protocol suitable for supporting purchases costing less than a cent. It is based on decentralised validation of electronic cash at the vendor's server. The digital payment tokens in this system are termed “scrip”. They are issued by a central payment service in return for prepayment using a conventional payment method such as a credit card. The vendor may then accept scrip from the user in payment for goods or more typically for services. The vendor generates fresh scrip and returns it to the user as change for the transaction. The scrip is authenticated and fresh scrip generated by the vendor using a hash function. This represents a potential security weakness, in that if the hash function is cracked, then the scrip would be open to forgery and duplication. Moreover, there is a processing overhead associated with the use of the hash function by the vendor. Although this is less than the overhead associated, for example, with the use of a PGP-encrypted signature, it is nonetheless a significant limitation. It is admitted by the proponents of the Millicent system that, as a result of its limited efficiency, there is a practical lower bound to the transaction values it can handle. It is suggested that this lower bound is around {fraction (1/10)} of a cent. Millicent is therefore not suitable for use, for example, as a charging mechanism for internet usage. The costs of packet transmission on the internet have been estimated at around {fraction (1/600)} th of a cent.
European patent application EP-A-0507669 discloses an example of another type of payment system, based on smart card technology. Here, rather than cryptographic security being relied upon, security is based on the physical integrity of the card. A randomly selected sub-set of a number of token values is withheld, so that the presence of one of the withheld token values in a subsequent transaction can serve as an indication of attempted fraud. The set of tokens issued to a particular card is not statistically random but may, for example, all fall within a limited range of numerical values, and may be ordered in sequence determined by their numerical values.
SUMMARY OF THE INVENTION
According to a first aspect of the present invention, there is provided a method of operating a digital payment transaction system comprising:
a) storing at a payment server a sequence of random numbers;
b) issuing to a user a set of digital payment tokens comprising a sequence of digitally encoded random numbers derived from the said stored sequence of random numbers;
c) transferring a payment token from the user to a merchant platform;
d) transferring from the merchant platform to the payment server the payment token received from the user in step (c);
e) at the payment server, authenticating the token by comparing the value of the random number of the token from the merchant platform and a value derived from a corresponding position in the stored sequence of random numbers; and
f) subsequently communicating an authentication message from the payment server to the merchant platform.
The present invention provides a digital payment transaction system which offers improved efficiency and security and which is suitable for making micropayments, including very low value payments. This is achieved by issuing to the user a “carnet” or set of digital payment tokens which comprises a set of random numbers in a determined sequence. The numbers in the sequence are completely unrelated to one another, and there is no correlation between the numerical value of a token and its position in the sequence. This is in contrast with prior art proposals in which the tokens are related to one another by cryptographic transforms. The tokens are validated by passing them to the payment server where the token is compared with the corresponding number in the random sequence stored at the server. In this way, the system offers a high level of cryptographic security, while completely removing the processing overhead from the vendor.
In the description and claims the term “random” is used to encompass both truly random numbers and pseudo-random numbers which match, to within a required level of accuracy, the statistical properties of a truly random sequence.
Preferably the payment server is remote from the merchant platform and the merchant platform communicates over a communications network with the payment server. Typically, although not necessarily, all three of the user, the merchant and the payment server will be linked by internet connections.
Preferably the set of digital payment tokens is derived from the sequence of random numbers stored at the payment server by selecting part of the said sequence and encoding the said part of the sequence with a key which is specific to the user.
Generating the carnet by encrypting part of the random sequence using a user-specific key ensures that the required length of the random number sequence, and the associated storage needed in the payment server, scales acceptably as the number of users increases. At the same time, encryption with the user key further enhances the security of the method.
Preferably the part of the said sequence is encoded by a symmetrical block cipher. This is preferred as giving the highest level of security. Alternatively, in fields of use where it is more important to reduce the computational overhead involved in creating the carnet, a keyed hash function might be used. It will be understood that, by contrast with the Millicent proposal discussed above, hashing is used only within the payment server to produce the token values from the stored random number sequence, and does not determine the relationship between the different numbers in the carnet. The security of the system does not therefore rest upon the integrity of the hash function alone.
Preferably in step (d) of the method, the merchant communicates, together with each payment token, an authentication token from a sequence of authentication tokens issues by the payment server.
Although typically there will be greater trust between the vendor and the payment server, there is still a need to provide security for the transactions between these two parties. In the preferred implementation of the present invention, a particular effective approach is to use the same mechanism as that used to generate the payment tokens themselves. Then the payment server issues the merchant with a series of authentication tokens. These authentication tokens may be derived from the sequence of random numbers in the same manner as the payment tokens. The merchant can then return pairs of payment tokens and authentication tokens to the p

LandOfFree

Say what you really think

Search LandOfFree.com for the USA inventors and patents. Rate them and share your experience with other people.

Rating

Transaction system does not yet have a rating. At this time, there are no reviews or comments for this patent.

If you have personal experience with Transaction system, we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Transaction system will most certainly appreciate the feedback.

Rate now

     

Profile ID: LFUS-PAI-O-2507685

  Search
All data on this website is collected from public sources. Our data reflects the most accurate information available at the time of publication.