BACKGROUND TO THE INVENTION Fraud on the Internet has reached unacceptable levels and financial and other institutions are expending vast sums and employing significant manpower in trying to make bank accounts and other records secure against"hackers".

Internet banking is now taking over from cheque writing as the method of choice for those who have payments to make. Conventionally a password, or possibly two passwords, are required to access a bank account. However, applicants are aware of techniques that make the protection allegedly offered by passwords almost useless. Bypassing these passwords and gaining access to accounts presents no serious problem to a competent"hacker".

The present invention seeks to provide a method and a system for preventing unauthorized operation of an account.

BRIEF DESCRIPTION OF THE INVENTION

According to one aspect of the present invention there is provided a method of conducting an electronic transaction which comprises: connecting a remote computer of the customer to an authentication server to open up an authorization and data transmission channel ; generating, upon said connection being made, a code which is unique to the connection established ; generating a first verifying code derived from raw data comprising said unique code and the ID of the remote computer and the date and time; transmitting said first verifying code to the customer along a communication channel other than said authorization and data transmission channel ; generating a second verifying code and storing this on the authentication server, the second verifying code being encoded and derived from said unique code, the ID of the remote computer and the time and date; entering said first verifying code at said remote computer; transmitting said first verifying code from said remote computer to said authentication server along said authorization and data transmission channel; transmitting both said first and second codes from the authentication server to a means for decoding the second verifying code to recreate the raw data and then using the re-created raw data to create a third verifying code; and comparing the first and third verifying codes.

Said second verifying code can be in the form of a global unique identifier; and the first verifying code in the form of a number with, for example, five digits.

According to a further aspect of the present invention there is provided a system for enabling an online transaction as defined above to be undertaken.

BRIEF DESCRIPTION OF THE DRAWING For a better understanding of the present invention, and to show how the same may be carried into effect, reference will now be made, by way of example, to the accompanying drawing in which the single figure is a flow diagram illustrating the system in accordance with the present invention.

DETAILED DESCRIPTION OF THE DRAWINGS The transaction commences when the customer uses his computer 10 to log on to the authentication server 12 of the financial institution at which his current account, savings account or other bank account is held. The customer logs on via the transmission line 14. Logging on occurs in the conventional manner by the insertion of one or more codes known only to the customer. The client authentication server 12 of the financial institution authenticates the information provided by the customer as the log on procedure takes place. This establishes an authentication and data communication channel between the customer 10 and the financial institution.

The authentication server 12 has stored therein information pertaining to the customer which the financial institution has previously requested and the customer has provided. The information can take many forms but should include at least :

(a) information pertaining to a second communication channel from the financial institution to the customer which the customer wishes the financial institution to use; and (b) information pertaining to when establishment of a data transmission channel is allowed, and how long the authentication and data communication channel may remain connected.

The information provided under (a) is hereinafter referred to as the customer's"notification profile"and can comprise, for example, the number of a cellular phone to which a text message can be sent or an email address to which a message can be sent.

The information provided under (b) will be referred to hereinafter as the customer's"expiry policy"and can, for example, specify that no connection before 8am, or after 5pm, is valid and that the transmission channel should be closed after a specified time.

The information under (a) and (b) is in XML format.

Upon the authentication and data transmission channel being opened, an identification code is generated by the server 12 which is unique to the connection which has been established. Each time a customer establishes an authentication and data transmission channel between himself and the institution, a new, unique identification code is allocated. This code will be referred to hereinafter

as the"request ID".

The data available for use now comprise the customer's notification profile, the customer's expiry policy, the customer's computer ID, the request ID and the time and date that the transaction commenced.

The request ID, the customer's computer ID and the time and date (the "raw ticket uid") are used by a secure server 16 to generate a global unique identifier which is a thirty two character number. This is generated using a protocol which is the industry standard worldwide. This number, in the present context, is referred to as a"ticket uid"."uid"is a shorthand way of writing"global unique identifier".

The ticket uid is transmitted along path 18 to the server 12 and stored in the memory of the server 12.

The"raw ticket uid"is hashed in the secure server 16 to provided a number of, say, five digits in length which is referred to hereinafter as the"token ID".

The token ID is sent to the customer along the communication channel 22 specified in the customer's notification policy as stored on the server 12.

The customer is prompted on the screen of the computer 10 to enter the token ID received, and the token ID is then transmitted to the financial institution's authentification server 12 along the previously established authentication and data transmission channel. Upon receipt of the entered token ID, the

authentification server 12 transmits the token ID and the ticket uid to the secure token server 16. The server decodes the ticket uid to recreate the raw ticket data and then produces a further identification number (referred to as a"match ID"). This is compared with the token ID. Only if there is a match between the token ID and the match ID can the transaction proceed. In the event of a mismatch the transaction is not permitted to proceed. By using the ticket uid to produce the match ID, there is assurance that it is the correct authorization server 12 that is communicating with the secure server 16. More specifically, the token ID is produced directly from the"raw ticket uid". The match ID is produced from the ticket uid which is also based on the raw ticket data but which has been stored on the server.

Reference numeral 24 designates the financial institution's computer on which all the client's financial information is stored.