GB2366007A

GB2366007A - Credit and charge card security technology and mechanism for e-commerce

Info

Publication number: GB2366007A
Application number: GB0002968A
Authority: GB
Inventors: Roy William Buckland
Original assignee: Individual
Current assignee: Individual
Priority date: 2000-02-09
Filing date: 2000-02-09
Publication date: 2002-02-27
Anticipated expiration: 2020-02-09
Also published as: GB0002968D0; GB2366007B

Abstract

In a credit transaction with a vendor, card and transaction details are encoded with an encryption algorithm to generate a unique transaction number that can be relayed to a vendor either personally or through use of an e-commerce environment. In relation to the encryption algorithm, this is supplied to a card-holder in the form of computer software which may be incorporated into a dedicated device or a computer terminal or the like. The vendor, in response to receipt of unique transaction number, communicates the unique transaction number to the card issuing authority such as a bank or the like which acts to decode the unique transaction number using a complementary decoding algorithm associated with the card-holder's encryption algorithm. The card issuing authority is then able to respond to the request of the vendor to authorise a line of credit for the card-holder. Consequently, the vendor is not directly appraised of all card and transaction details in the initial communication with the card-holder, thereby safeguarding potentially further fraudulent mis-use of the card and transaction details.

Description

<Desc/Clms Page number 1> CREDIT AND CHARGE CARD SECURITY TECHNOLOGY AND MECHANISM FOR E-COMMERCE This invention relates, in general, to a mechanism for protecting fraudulent, unauthorised use of credit and charge cards in an e-commerce or remote vendor access environment and is particularly, but not exclusively, applicable to computer program products and apparatus that enhance the security of credit, debit and charge card (or the like) in transactions. The present invention is of particular benefit when used for internet transactions, but can also be applied advantageously to postal and telephone transactions in a way that generally protects but the cardholder and the card owner (e.g. the issuing financial house or clearing bank) responsible for authorising and validating a line of credit.

With existing credit, debit and charge cards, a variable number of card details are freely exchanged during transactions with vendors, irrespective of whether the vendor is personally present or is remote (such as in the case of internet or telephone ordering and purchases). These card details generally include the card number, the card-holder's name and the expiry date. There is thus generally little security against subsequent intentional or unintentional misuse of this information by vendors or by third parties who gain access to it; this consideration is of particular concern with internet transactions where the reputability of vendors may be difficult to establish.

Known techniques partially address the internet security problem by encrypting data during the transit only between cardholder and vendor to prevent third party misuse. Other known schemes require the vendor to be registered with the card issuing company to ensure reputability or require three-way communication between the company, the cardholder and the vendor to authorise individual transactions. As an alternative approach, some card issuing companies simply insure the holder against misuse.

Unfortunately, such existing card security techniques may incur significant

additional operating costs for the card issuing company and vendor and thus limit the choice of vendor open to the cardholder. Moreover, with increasing internet and e-commerce traffic, validation with the card issuing authority (or agent) may be subject to increasing delays, especially if high levels of credit are requested that require specific consideration. Furthermore, such existing security techniques and operating procedures are also usually only applicable to transactions by internet, not post or telephone. Of course, it is possible to specifically limit the level of credit offered by a card to a predetermined (and relatively low) level, but this generally has the effect of discouraging card usage (and, in any event, does not limit the likely of fraudulent use of the card).

According to a first aspect of the present invention there is provided a method of limiting access to information pertaining to card transactions, the method comprising: applying an encryption algorithm to transaction details associated with a cardholder involved in a transaction, thereby to generate a unique transaction number for the transaction; relaying via a vendor the unique transaction number to a transaction clearance house that decodes the unique transaction number to determine at least one of authorisation and authenticity of the transaction; and sanctioning the transaction between the cardholder and the vendor subject to said determination of said at least one of authorisation and authenticity of the card transaction.

The transaction details may include at least one of hidden card data; transaction amount; payment type; and date information.

Sanctioning is typically subject to at least one of a requested payment amount; a transaction date; and a transaction period.

In a second aspect of the present invention there is provided a computer software package used for enhancing the security of credit, debit or charge card transactions by allowing the holder to produce a coded number that can be decoded by the company authorizing card payment.

The authorisation code is preferably produced in the format of a conventional card number.

Preferably, the amount or limiting amount of a transaction is encrypted.

A transaction number indicator such as the time, date or counter serial number of a transaction may also be encrypted.

In a further aspect of the present invention there is provided apparatus for limiting access to information pertaining to card transactions, comprising: means for applying an encryption algorithm to transaction details associated with a card- holder involved in a transaction, thereby to generate a unique transaction number for the transaction that is communicable, via a vendor, to a transaction clearance house, wherein the unique transaction number is decodeable remote from both the cardholder and the vendor.

In a further aspect of the present invention there is provided a communication system comprising: means for applying an encryption algorithm to transaction details associated with a cardholder involved in a transaction, thereby to generate a unique transaction number for the transaction; means for relaying via a vendor the unique transaction number to a transaction clearance house; and wherein the transaction clearance house includes: i) means for decoding the unique transaction number; ii) means for determining at least one of authorisation and authenticity of the transaction; and iii) means for sanctioning the transaction between the card- holder and the vendor subject to said determination of said at least one of authorisation and authenticity of the card transaction.

Advantageously, the preferred embodiments of the present invention ensure that card details are both encoded during communication with a vendor and that the vendor is subjected to a restriction in their ability to reuse subsequently an authorised amount of credit (or the number of times that a specific credit

authorisation) can be used. The potential for fraudulent or erroneous credit payments is therefore greatly reduced, with the system being reliable and having low operating costs. Moreover; the present invention allows use of credit card transactions with any vendor who accepts such credit (and charge card) payment mechanisms. Beneficially, the present invention can be used in conjunction with or independently to internet access, since the underlying inventive concept is applicable to telephone and postal transactions.

Preferred embodiments of the present invention will now be described with reference to the accompanying drawings; in which: F]Gs. 1 to 3 illustrate various transaction sequences showing exemplary frames of information presented to a cardholder (for communication to a vendor) and a card issuing authority according to preferred embodiments of the present invention.

According to the present invention, a program is loaded on to the card holder's computer (or provided in an electronic card or discrete device, such as a memory module for a cellular phone or a phone itself), which program is run when any transaction is about to be undertaken. The program produces an encrypted transaction number that is sent to the vendor and then, by the vendor, to the company which authorises payments from the "card" (i.e., in essence, the computer program encryption algorithm). It is envisaged that this encryption number will only authorise one form of payment, probably of a specified or limited amount, from the card-holder's account and its potential fcr misuse is therefore much restricted.

In one embodiment of the invention, the cardholder inputs the amount of the transaction into his card program. The card holder preferably also inputs a transaction number indicator (which could be, for example, the date). The program then produces a unique encrypted transaction number in the same format as a conventional card number for transmission to the vendor; this is the so-called E- Tu Safe number shown in the information frames of FIGs. 1 to 3. The generation of TM the E-Safe number in the form of a conventional (16-digit) card number is possible

because the length of conventional card numbers is much greater than is required merely for unique identification of the card type and holder name. The unique encrypted transaction number is provided to the vendor, such as by a verbal disclosure process or by electronic or otherwise written communication.

The vendor transmits this unique encrypted transaction number to the card clearance company, who decode the number and check that the transaction number indicator and transaction amount are valid before authorising payment. The number is then disabled for further transactions within a predetermined encryption validity period, probably less than one month. A database of transactions is typically retained clearance company, which database may therefore include information pertaining to the predetermined encryption validity period and used unique encrypted transaction numbers associated with a particular cardholder.

An advantage of this particular embodiment is that the vendor treats the encrypted number exactly like a conventional card number and thus incurs no additional costs and requires no special equipment or procedures.

Of course, more elaborate encryption algorithms could be used, such as ones that allow/support multiple daily payments of the same amount, regular monthly payments, payments in different currencies and requests for refunds. Some of these options, as shown in the accompanying drawing Figures, as selectable options within transaction windows offered to the card holder and the time of their making the request. Moreover, selection of any of these particular options generally requires appropriate coding of the unique encrypted transaction number.

As regards a first preferred algorithm, the card holder essentially inputs the amount of a proposed transaction into their card program, which program contains a hidden eight-digit serial number; this is shown in the uppermost frame of FIG. 1. The eight- digit serial number (which is preferable absolutely inaccessible) allows the issuance of up to one hundred million cards. The card/encryption program preferably encrypts a four-digit amount check into a transaction number of, preferably, a 16-

digit card number format (with the first four digits indicating a card type, in conventional fashion). The unique transaction number, together with the expiry date (which is optionally included by generally required by all vendors) and, possibly, cardholder name is communicated to the vendor who then seeks payment clearance via a telephone or internet link to an authorisation centre. The process could, of course, be entirely automated. The authorisation centre decodes the unique transaction number that therefore validates the transaction amount. The authorisation centre typically also checks the expiry date and possible the card- holder's name using the hidden card serial number (which the authorisation centre is, of course, aware of in view of it assigning the serial number to the card-holder). Payment is then authorised (or not) to the vendor, as the case may be. The transaction number could, in any event, be encrypted to provide a one-off transaction, thereby to provide added security in relation to previously unused vendors having no history of reputable trading.

The first embodiment, as will be understood; is simple to operate.

In a second embodiment of the present invention, as shown in FIGs. 2 and 3, additional information is included into the generation of the unique transaction number, which additional information is typically directed to payment type (e.g. standard one-off, subscription or repeat) and possibly also limited to a date of use basis. The hidden serial number may therefore need to be reduced, and is shown in the uppermost frames of FIGs. 2 and 3 to be a 7-digit number (allowing the issuance of ten million cards). The amount check may also required to be reduced to maintain a conventional 16-digiti card number format, although it will be 1M appreciated that the length of the E-Safe transaction number is arbitrary. Essentially, the process associated with the second preferred embodiment follows that embodied in relation to FIG. 1, except that the transaction date and payment type is also encoded. Consequently, interpretation of the encrypted transaction number may prevent agreed amount payments being made after expiry of a predetermined time, say one-month, since encryption (or even on agreed days of

particular months, for example). The second embodiment provides a higher level of transaction security.

In summary, the invention seeks to avoid the problems of the prior art by essentially replacing the card itself with a computer program that is, in effect, individual and to each cardholder. In a credit transaction with a vendor, card and transaction details are encoded with an encryption algorithm to generate a unique transaction number that can be relayed to a vendor either personally or through use of an e-commerce environment. The vendor, in response to receipt of unique transaction number, communicates the unique transaction number to the card issuing authority (such as a bank or the like) which acts to decode the unique transaction number using a complementary decoding algorithm associated with the cardholder. The card issuing authority is then able to respond to the request of the vendor to authorise a line of credit for the cardholder. Consequently, the vendor is not directly appraised of all card and transaction details in the initial communication with the cardholder, thereby safeguarding potentially further fraudulent misuse of the card and transaction details. The unique transaction number may also include limitations as to when and how many times the unique transaction number will be acknowledged by the card issuing authority as a valid request for the release of a line of credit, with such limitations based on, for example, an encoded date within the unique transaction number.

With the transaction algorithm being software based, access to the algorithm can also be password protected to mitigate unauthorised access to the encryption algorithm. Additionally, with data recording within the encoder environment of the present invention, a transaction number could replace the date to simplify input and provide additional security.

In generality, the encoder of the present invention is effectively produced in a portable form to allow free transportation, with the portable device possibly supporting a (re-)programmable metallic strip or smart-chip to allow access of automated teller machines (ATMs) and other swipe machines, thereby extending

the use of the inventive concept. The term "card" in the sense of the present invention must necessarily be viewed widely to include the concept of a credit, debit or charge card realised as an electronic artefact; although existing cards could clearly have account detail information transferred into an electronic domain where it is effectively encoded by the encryption algorithm of the present invention; this therefore supports migration of existing cards to a system having increased levels of security for the cardholder and card owner.

It will, of course, be appreciated that the above description has been given by way of example only and that modifications may be made within the scope of the present invention. For example; whilst the preferred embodiment of the present invention has been described in terms of the provision of a computer program product that can be loaded into memory of a computer terminal, the present invention may clearly be adapted, supplied or integrated in a number of forms. By way of specific (but not limiting) example, the encryption portion of the present invention can be implemented into discrete handheld devices such as electronic cards, cellular telephones or dedicated terminals, whilst a corresponding decryption portion is retained within the system and specifically in a way that is only accessible to the card issuing authority (that approves; validates or authorises the credit transaction). Of course, the size of the transaction number is not limited to 16-digits.

Claims

Claims 1. A method of limiting access to information pertaining to card transactions, the method comprising: applying an encryption algorithm to transaction details associated with a cardholder involved in a transaction, thereby to generate a unique transaction number for the transaction; relaying via a vendor the unique transaction number to a transaction clearance house that decodes the unique transaction number to determine at least one of authorisation and authenticity of the transaction; and sanctioning the transaction between the cardholder and the vendor subject to said determination of said at least one of authorisation and authenticity of the card transaction.
2. The method of claim 1, wherein the transaction details include at least one of hidden card data; transaction amount: payment type; and date information.
3. The method of claim 1 or 2, wherein sanctioning is subject to at least one of a requested payment amount; a transaction date; and a transaction period.
4. A computer program element comprising computer program code means a make a computer-controlled system execute procedure to perform any of the method steps of claims 1 to 3.
5. The computer program element of claim 4, embodied on a computer readable medium.
6. A computer software package used for enhancing the security of credit, debit or charge card transactions by allowing the holder to produce a coded number that can be decoded by the company authorising card payment.
7. A computer package according to claim 6, in which the authorisation code is

<Desc/Clms Page number 10>

produced in the format of a conventional card number.
8. The computer package according to claim 6 or 7, in which the amount or limiting amount of a transaction is encrypted.
9. The computer package according to claim 6, 7 or 8, in which a transaction number indicator such as the time, date or counter serial number of a transaction is encrypted.
10. Apparatus for limiting access to information pertaining to card transactions, comprising: means for applying an encryption algorithm to transaction details associated with a cardholder involved in a transaction, thereby to generate a unique transaction number for the transaction that is communicable, via a vendor, to a transaction clearance house, wherein the unique transaction number is decodeable remote from both the cardholder and the vendor.
11. Apparatus according to claim 10, wherein the apparatus is one of a memory- chip, a computer program, and a cardholder terminal.
12. A communication system comprising: means for applying an encryption algorithm to transaction details associated with a cardholder involved in a transaction, thereby to generate a unique transaction number for the transaction; means for relaying via a vendor the unique transaction number to a transaction clearance house; and wherein the transaction clearance house includes: 1) means for decoding the unique transaction number; ii) means for determining at least one of authorisation and authenticity of the transaction; and iii) means for sanctioning the transaction between the cardholder and the vendor subject to said determination of said at least one of authorisation and

<Desc/Clms Page number 11>

authenticity of the card transaction.
13. A method of limiting access to information pertaining to card transactions, substantially as hereinbefore described with reference to the accompanying drawings.
14. Apparatus for limiting access to information pertaining to card transactions, substantially as hereinbefore described with reference to the accompanying drawings.
15. A computer program product substantially as hereinbefore described with reference to the accompanying drawings.
16. A communication system arranged to limit access to information pertaining to card transactions, substantially as hereinbefore described with reference to the accompanying drawings.