GB2370475A

GB2370475A - Secure online transaction where a buyer sends some information direct to a bank and some via a vendor

Info

Publication number: GB2370475A
Application number: GB0031429A
Authority: GB
Inventors: Brian Monahan; Keith Alexander Harrison; Adrian Baldwin; Alex Chu
Original assignee: Hewlett Packard Co
Current assignee: HP Inc
Priority date: 2000-12-22
Filing date: 2000-12-22
Publication date: 2002-06-26
Also published as: GB0031429D0

Abstract

A communication method for passing information for a transaction across a distributed electronic network such as the internet, in which there is a user purchaser (2) and a merchant seller (4), the method comprising the steps of the user (2) providing the merchant (4) with a first token (10) comprising part only of the information required for the transaction and providing to a transaction authority financial institution (8) other than via the merchant (4) a second token (12) comprising other information required for the transaction, the merchant (4) supplying the first token (10) to the transaction authority (8) for the transaction. The tokens may be encrypted and/or signed.

Description

IMPROVEMENTS IN AND RELATING TO COMMUNICATION METHODS The present invention relates to communication methods and system and in particular to such methods and system for passing information for a transaction across a distributed electronic network.

A typical transaction with which preferred embodiments of the present invention is concerned is the purchase by a customer of goods or services from a merchant using a distributed electronic network such as the internet. Currently in such a transaction a customer makes a selection of the desired goods and/or services from the merchant's web site and provides the merchant with the information required to complete the financial element of the transaction. This financial information typically will include the customers bank and account details for a direct debit type transaction and/or the customers debit or credit card details, usually the card number, card holder's name, card holder's address and the card expiry date.

While this is generally satisfactory when dealing with a reputable merchant, it is a method and system open to abuse by a disreputable merchant. The customer may not be aware of the type of merchant with which he/she is dealing. For instance, a disreputable merchant could use the financial details provided by the customer to make multiple payment authorisations, to misrepresent the authorised payment and/or to sell the details on. In effect currently control of the transaction is entirely with the merchant. It is desirable therefore to increase

the security of a customer in such a transaction over a distributed electronic network.

It is an aim of preferred embodiments of the present invention to address the problem referred to above.

According to the present invention in a first aspect, there is provided a communication method for passing information for a transaction across a distributed electronic network, in which there is a user and a merchant, the method comprising the steps of the user providing the merchant with a first token comprising part only of the information required for the transaction and providing to a transaction authority other than via the merchant a second token comprising other information required for the transaction, the merchant supplying the first token to the transaction authority for the transaction.

Such a method prevents the merchant from gaining access to sufficient information from the transaction to use it fraudulently.

The transaction authority will generally be a financial institution and more generally is a body involved in completion of the transaction. Suitably, the transaction authority is a user's financial institution.

While there are many different types of information that can be transferred in the tokens, suitably, the first token comprises a transaction reference. Suitably, the first token comprises details identifying the transaction authority.

Suitably, the second token comprises a transaction reference.

Suitably, the first token is encrypted. Suitably, the second token is encrypted. Suitably, the encryption is asymmetric. Suitably, the encryption of a token is according to a public key of the transaction authority. Suitably, encryption is carried out based on a key incorporated in a token, preferably the customer's token.

Suitably, encryption is carried out based on a predetermined key, a transaction reference is associated with the predetermined key the transaction reference is transmitted with a token to the transaction authority, but the predetermined key is not. Encryption can be used to make the information in the tokens substantially inaccessible to an unauthorised party.

Suitably, the first token is transmitted from the user to the merchant. Suitably, the first token is transmitted from the merchant to the transaction authority.

Alternatively, the first token is transmitted to the transaction authority via a third party, which third party will generally be a merchant trusted source such as the merchant's bank.

Suitably, the second token is transmitted from the user to the transaction authority.

Suitably, the first token is transmitted substantially at the same time as the second token. Alternatively, a token may be pre-transmitted ahead of the other token.

According to the present invention in a second aspect, there is provided a communication system configured and adapted to operate according to the first aspect of the invention.

The present invention will now be described, by way of example only, with reference to the drawings that follow; in which: Figure 1 is a schematic network diagram illustrating a first embodiment of the present invention.

Figure 2 is a schematic network diagram illustrating a second embodiment of the present invention.

Referring to Figure 1 of the drawings that follow, there is shown schematically a customer 2, a merchant 4, a merchant's bank 6 and a transaction authority, in their case a customers bank 8 all of which are in digital communication across a distributed electronic network such as the internet. Alternative forms of distributed electronic networks include Wide Arena Networks (WANs) and Local Area Networks (LANs).

The merchant 4 provides a web site from which goods and/or services are available for purchase. Many examples of merchant web sites now exist of which www. amazon. com (trade mark) is one.

According to embodiments of the present invention, the customer 2 makes a selection of goods and/or services he/she wishes to purchase from the merchant web site and provide to the merchant 4 in plain text the information

they will require to deliver those. For instance the customer 2 may give details of the number of items desired, the delivery address and the delivery date. The details to be provided by the customer 2 to the merchant 4 will vary depending on the nature of the goods/services to be purchased and the particular web site.

To effect payment for the goods/services the customer 2 sends a merchant's token 10 in plain text to the merchant 4 with information a) identifying the customer's bank 8 and b) a customer purchase reference number.

Simultaneously, the customer 2 sends a customer's token 12 in plain text to the customer's bank 8. The customer's token contains the rest of the information required to complete the transaction with the merchant 4 for the relevant purchase. The information required will vary depending upon the way in which the customer 2 intends to pay the merchant and generally the information required by the customer's bank 8. For instance, if payment is to be effected by a payment from the customer's credit card, the customer's token 12 can contain the following information: c) customer name; d) customer address; e) customer purchase reference number; f) customer credit card number; g) customer credit card expiry date; and h) amount to be debited from account.

The merchant's token 10 is transmitted by the merchant to the merchants bank 6 together with additional information from the merchant 4 regarding i) the amount they expect to receive from the customer 2 as a result of the

transaction. The merchant's bank 4 contacts the customer's bank 8 using the information (from a) above) in the merchant's token 10 and provides the merchant's token 10 together with the additional information to the customer's bank 8.

Upon receipt of both the merchant's token 10 and the customer's token 12, the customer's bank 8 combines the data therefrom, reconciling the two tokens together by using the customer purchase reference number (from b) and e) above). The customer's bank checks the customer's details (as in c), d), f) and g) above) and determines from h) and i) above whether the amount to be paid as received in the customer's token matches with that in the merchant's token and additional information; and if the two correspond confirms to the merchant's bank 6 that the payment is authorised. The customer's bank 8 then or later will effect payment to the merchant's bank 6 to complete the transaction. Typically, payment will be by electronic funds transfer. Note that the payment may be authorised but made conditional on delivery of the goods/services.

Upon receipt of confirmation of payment the merchant's bank 6 informs the merchant 6 of same enabling the merchant to dispatch the goods/services ordered by the customer 2 confident that payment will be made (if needs be provided that the goods/services are delivered).

It will be appreciated that there are many different ways in which embodiments of the present invention can be implemented. Some of those are described below.

The transaction described above in relation to Figure 1 can be carried out without the intervention of the merchant's bank 6, in which case the merchant 4 transmits the merchant's token 10 directly to the customer's bank 10. This embodiment is shown schematically in Figure 2 of the drawings that follow in which like reference numerals are used.

In a further alternative embodiment the customer 2 provides the merchant 4 with two merchant tokens. The first merchant token contains the information in the merchant's token 10 referred to above in a plain text format while the second merchant token contains some of the information in the customer's token 12 referred to above in encrypted format. The encryption may be symmetric, asymmetric or a combination of the two (e. g. enveloping) depending on the level of security desired.

Preferably, an asymmetric encryption is used in which the customer's bank's public key is used to encrypt the second token so that only the customer's bank 8 is able to access the data of the second merchant token. Generally to minimise processing requirements an enveloping encryption is used ie the customer uses a symmetric encryption key with a bulk key to encrypt the token data and uses an asymmetric key (preferably the customer's bank's public key) to encrypt the bulk key.

The customer's token 12 without the information now in the second merchant token (though the data strictly need not be removed). It does not matter what data is selected so long as not all of the required information to complete a financial transaction is sent to the merchant (whether in encrypted form or not).

In this embodiment the merchant passes the first and second merchant tokens on to the customer's bank 8 (optionally via the merchant's bank 6). The customer's bank 8 decrypts the second merchant token and (as above) determines whether the transaction is to be completed.

Additionally the customer's token 12 may be encrypted (for convenience, but not necessarily in the same way as the merchant's token) for additional security. Generally it is undesirable for any customer financial details to be transmitted in unencrypted form. For convenience, if the same encryption is used the combined data from the customer's token 12 and the second merchants token (ie the data required to complete the financial transaction) may be encrypted and then split into the required merchant and customer tokens. So long as the customer is aware of the splitting algorithm and the customer's bank is aware of the re-joining algorithm how the data is split between the merchant and customer tokens is largely immaterial.

Such joining and rejoining algorithms can operate in various ways. For example, one way is to split a stream of data by alternately selecting odd-numbered and evennumbered bits or bytes to yield two separate streams.

Joining this data together involves alternately selecting from the two streams, in the correct parity, to form the single data stream.

Another way is to assume we have a stream of structured data objects, all having a common structure. These are split into two streams by systematically select fields from each record to form two separate data streams. At

the receiving end, reassembling the data into the fields for each object can put the two streams together. These approaches could equally apply when splitting individual tokens.

The customer purchase reference number can be used not only to match the relevant tokens, but also to prevent multiple use of the same tokens for repeat transactions. That is, the customer purchase reference number can be sequential (or otherwise symmetrically updated in) for each transaction so that the customer's bank 8 will not authorise a second payment request using the same customer purchase reference number.

In another embodiment, instead of the customer 2 sending the customer's token 12 substantially at the same time as it sends the merchant's token 10, the customer 2 can provide the customer's bank with a batch of pre-authorised payment tokens identified by customer purchase reference numbers. In that case the merchant's token 10 contains the customer purchase reference number, the amount to be debited and details of the customer's bank (e. g. an identity, an address and/or a sort code) which is sufficient for the customer's bank to complete the transaction. In this embodiment it is preferable for at least the customer purchase reference number to be encrypted so that the merchant cannot extrapolate to another pre-authorised customer purchase reference number.

In a further embodiment the customer fills in a plain text order form and uses a nonce (ie some random data), adds this as base 64 binary encoding to the plain text order form and digitally signs the combined document. The

digital signature is included with the combined document as a composite document. The composite document is then split in to two parts, a customer's token and a merchant's token. The customer's token contains the nonce and (optionally) the signature to be sent to the customer's bank. In this embodiment the customer's token is preferably encrypted. The remainder, the merchant's token is sent to the merchant with, in plain text format, an identifier of the intended eventual recipient, ie the customer's bank. Upon receipt by the customer's bank of the customer's token and the merchant's token the two are re-combined by the customer's bank, the digital signature decrypted and, if validated, the transaction is authorised as above.

In an advantageous implementation of the embodiment of the preceding paragraph, a customer is given a collection of random nonce values. A random identification number identifies each nonce being used, which random number is included in the merchant's token to allow the customer's bank of match up the nonce part for verification.

In a further refinement, the customer's bank chooses the nonces to be used, which are registered to the particular customer. As above, the nonces are also each attributed a random identification number (this may be by the customer's bank or by the customer) and a table crossreferencing the identification number with the nonce is generated.

The table is sent securely to the customer (ie encrypted using the customer's public-key and enveloped appropriately). In use, the customer then selects from

these nonces, taking care to use each one only once. The customer uses the nonce to encrypt their data, but now need not include the nonce in the transmitted token at all. Instead a token includes only the random identification number, which is used on receipt by the customer's bank to look up in the table the relevant nonce for decryption.

It will be appreciated by those skilled in the art that many variations within the scope of the present invention are possible. In particular the information included in any particular token can vary enormously.

In relation to the Figure 1 embodiment described above, the additional information provided by the merchant 4 may come from the customer 2. For instance, the merchant's token may be constructed initially to contain the amount to be debited from the customer's account and details of the merchant 4. Alternatively, the merchant's bank may provide some of these details.

To reduce customer risk, the pre-authorised customer purchase reference numbers may be restricted. For instance, they may authorise payments only up to certain amounts or to specified merchants.

Although the embodiments described above refer to single tokens, the data in a token can be sent in multiple subtokens if desired.

The embodiments above refer to the customer's bank. In other embodiments this may be another payment authority or trusted source.

Each token will comprise a data file in any format readable by the intended eventual recipient. All communications across the distributed electronic network may be encrypted.

The reader's attention is directed to all papers and documents which are filed concurrently with or previous to this specification in connection with this application and which are open to public inspection with this specification, and the contents of all such papers and documents are incorporated herein by reference.

All of the features disclosed in this specification (including any accompanying claims, abstract and drawings), and/or all of the steps of any method or process so disclosed, may be combined in any combination, except combinations where at least some of such features and/or steps are mutually exclusive.

Each feature disclosed in this specification (including any accompanying claims, abstract and drawings), may be replaced by alternative features serving the same, equivalent or similar purpose, unless expressly stated otherwise. Thus, unless expressly stated otherwise, each feature disclosed is one example only of a generic series of equivalent or similar features.

The invention is not restricted to the details of the foregoing embodiment (s). The invention extend to any novel one, or any novel combination, of the features disclosed in this specification (including any accompanying claims, abstract and drawings), or to any novel one, or any novel combination, of the steps of any method or process so disclosed.

Claims

CLAIMS : 1. A communication method for passing information for a transaction across a distributed electronic network, in which there is a user and a merchant, the method comprising the steps of the user providing the merchant with a first token comprising part only of the information required for the transaction and providing to a transaction authority other than via the merchant a second token comprising other information required for the transaction, the merchant supplying the first token to the transaction authority for the transaction.
2. A communication method according to claim 1, in which the transaction authority is a user's financial institution.
3. A communication method according to claim 1 and claim 2, in which the first token comprises a transaction reference.
4. A communication method according to any preceding claim, in which the first token comprises details identifying the transaction authority.
5. A communication method according to any preceding claim, in which the second token comprises a transaction reference.
6. A communication method according to any preceding claim, in which the first token is encrypted.
7. A communication method according to any preceding claim, in which the second token is encrypted.
8. A communication method according to claim 6 or claim 7, in which the encryption is asymmetric.
9. A communication method according to any one of claims 6 to 8, in which the encryption of a token is according to a public key of the transaction authority.
10. A communication method according to any one of claims 6 to 9, in which encryption is carried out based on a key incorporated in a token.
11. A communication method according to claim 10, in which the token is the customer's token.
12. A communication method according to any one of claims 6 to 9, in which encryption is carried out based on a predetermined key, a transaction reference is associated with the predetermined key the transaction reference is transmitted with a token to the transaction authority, but the predetermined key is not.
13. A communication method according to any preceding claim, in which the first token is transmitted from the user to the merchant.
14. A communication method according to claim 13, in which the first token is transmitted from the merchant to the transaction authority.
15. A communication method according to claim 13, in which the first token is transmitted to the transaction authority via a third party.
16. A communication method according to any preceding claim, in which the second token is transmitted from the user to the transaction authority.
17. A communication method according to any preceding claim, in which the first token is transmitted substantially at the same time as the second token.
18. A method of communication substantially as described herein, with reference to the drawings that follow.
19. A communication system configured and adapted to operate according to the method of any one of claims 1 to 18.