WO2002001517A1

WO2002001517A1 - A method for carrying out electronic commerce transactions

Info

Publication number: WO2002001517A1
Application number: PCT/IT2000/000263
Authority: WO
Inventors: Filippo Alliney
Original assignee: Mover S.P.A.
Priority date: 2000-06-26
Filing date: 2000-06-26
Publication date: 2002-01-03
Also published as: AU2000258452A1

Abstract

A method (400, 500) of carrying out electronic commerce transactions on a telematics network, comprising the steps of generating (505) an incomplete payment order, the incomplete payment order being free of sensitive information relating to an instrument of payment of the user, storing (450) the sensitive information on a service centre's server computer system, generating (506-518) a digital signature of the incomplete payment order by the user's computer system and sending (524) the digital signature to the service centre's computer system; under the control of the service centre's computer system, checking (527) the digital signature, completing (539-542) the payment order by adding the sensitive information, and carrying out (545-557) a transaction corresponding to the completed payment order.

Description

"A method for carrying out electronic commerce transactions"

DESCRIPTION

The present invention relates to a method of carrying out electronic commerce transactions.

Various methods have been proposed in recent years for carrying out electronic commerce transactions (e- commerce) securely on a telematics network, for example, on the INTERNET. In general, a_. user makes a connection with a vendor ' s computer system by means of a computer system of his own, and then selects one or more goods to purchase. Once the user has completed the selection of the goods to be purchased, the vendor's computer system invites the user to indicate a method of payment for the purchase .

A method commonly used consists of the generation of a payment order by the entry of a credit-card code. In particular, the vendor's computer system requests the user to type in the number, issue date, and expiry date of the credit card; this information is then transmitted to the vendor ' s computer system which carries out a corresponding transaction towards a credit-card control circuit . To prevent the credit card number being intercepted during transmission from the user's computer system to the vendor's computer system, the credit card number is generally transmitted in encrypted form.

A drawback of this method is that there is always a possibility of the credit card number being intercepted and deciphered by third parties such as hackers. Moreover, the credit card number is in any case communicated to the vendor (without the user being able to check his actual identity) ; this involves unsafe disclosure of this information with possible loss of control thereof. A different known method consists in storing the credit card number in a computer system of a separate body such as, for example, a bank; a corresponding access code is then supplied to the user. In this case, when the user makes a purchase, the user's computer system sends the information relating to the payment order (except for the credit card number) and his access code, suitably encrypted, to the bank's computer system. The bank's computer system then carries out the transaction and correspondingly notifies the vendor's computer system. The credit card number is thus never supplied to the vendor, preventing its uncontrolled disclosure.

This solution does not, however, ensure the security of the transaction. In fact, in this case also, the access code may be intercepted and deciphered by third parties; the security code may then be used to make purchases fraudulently by debiting their cost to the user's credit card.

It is an object of the present invention to overcome the above mentioned drawbacks. To achieve this object, a method of carrying out electronic commerce transactions as indicated in the first claim is proposed.

Briefly, the present invention provides a method of carrying out electronic commerce transactions on a telematics network, comprising the steps of generating an incomplete payment order relating to a purchase of at least one item selected by means of a user's client computer system on a vendor's server computer system, the incomplete payment order being free of sensitive information relating to an instrument of payment of the user, storing the sensitive information on a service centre's server computer system, supplying an encryption key to the user, generating a digital signature of the incomplete payment order, by the user's computer system, by means of the encryption key, and sending the digital signature to the service centre's computer system; the method further comprises, under the control of the service centre ' s computer system, the steps of checking the digital signature by means of a corresponding deciphering key, completing the payment order by adding the sensitive information, and carrying out a transaction corresponding to the completed payment order.

The present invention also proposes a corresponding method executed under the control of the service centre ' s computer system, a computer program, and a corresponding program product for implementing said method, a system for carrying out electronic commerce transactions, and a user's client computer system, as well as a service centre's server computer system for use in the system.

Further characteristics and the advantages of the method according to the present invention will become clear from the following description of a preferred embodiment thereof, given by way of non-limiting example, with reference to the appended drawings, in which:

Figure 1 is a basic block diagram of a system in which the method of the present invention can be used,

Figure 2 shows a user's computer schematically,

Figure 3 shows the contents of a memory of the user' s computer and of a service centre ' s computer system, Figures 4, 5a and 5b show, as flow charts, a user acquisition method and a method of making a purchase, respectively.

With reference to Figure 1 in particular, this shows a system 100 comprising a telematics network 105, typically the INTERNET. The INTERNET is a world-wide network of computer systems with a decentralized structure. INTERNET computer systems use a client/server architecture in which a remote computer system (a server) supplies information and services to a local computer system (a client) . The INTERNET provides for various access protocols; in particular, the HTTP protocol (hypertext transfer protocol) permits access to a subsystem of servers known as World Wide Web (WWW) sites, or simply web sites, which support the management of hypertext documents known as web pages. Each web page is constituted by a file in HTML (hypertext mark-up language) format which permits links to other documents.

A server of a vendor's computer system (MERCH) 107 is connected to the telematics network 105; typically, the vendor's computer system 107 constitutes a web site used to advertize and sell goods of various types such as products (motorcars, books, disks, programs) or services

(travel, entertainment). Typically, the vendor's site provides an electronic catalogue in which the goods for sale, their characteristics and their price, are listed.

A user also has access to the telematics network 105 by means of a respective access provider (not shown in the drawing) ; the user has a client computer system formed by a computer (USER) 110c to which a smart card terminal 11Ot is connected; the terminal llOt includes a display, a keypad, and a slot used for reading/writing the smart card. In particular, a main smart card 112m is used by the user personally, and one or more additional smart cards 112a are used by people authorized by the user (such as his wife and children) .

The system 100 also includes a service centre's server computer system 120 constituted by an outer or front-end subsystem (SERVf) 12Of, by an intermediate subsystem (SERVi) 120i, and by an inner or back-end subsystem (SERVb) 120b. The front-end subsystem 120f is connected directly to the telematics network 105; the intermediate subsystem I20i is connected to the front-end subsystem 12Of, by means of a dedicated line 125fi, and the back-end subsystem 120b is connected to the intermediate subsystem 120i by means of a dedicated line 125bi, each dedicated line being protected by suitable access barriers (firewalls) .

The back-end subsystem 120b is connected to a bank's computer system (ACQ) 130 by means of a dedicated line 135; the bank, which is known as the acquirer bank, controls transactions performed by means of credit-card sales terminals ("point of sale" or POS) terminals. The acquirer bank's computer system 130 is in turn connected in conventional manner to a computer system of a credit- card control circuit, to a computer system of banks issuing credit cards (known as issuer banks) and to a computer system of a bank at which the vendor has a current account of his own (not shown in the drawing) .

Each smart card 112m, 112a is constituted by a card made of plastics material on which, for example, the name of the user or of the authorized person (who are generally referred to as smart-card holders) is printed, and inside which there is a microprocessor with a respective non-volatile memory (typically an E²PROM) . The smart card 112m, 112a has a secret security code (a PIN) which is used to activate the smart card 112m, 112a and to lock/unlock it.

The smart card 112m, 112a stores an asymmetric encryption program, for example of the RSA (Rivest Shamir Adelman) type. In an asymmetric encryption system, two distinct keys (a private key and a public key) are provided. One key is used to encrypt an original message

(that is, to transform it into an apparently unintelligible form) ; the other key is used to derive the original message from the encrypted message. The two keys are generated in a manner such that it is not computationally feasible to derive the private key from a knowledge of the public key.

The holder's private key is stored on the smart card 112m, 112a. The smart card 112m, 112a also stores a digital certificate (defined, for example, by the X.509 standard) .^' The digital certificate contains information identifying the holder (such as his name, address, etc.), the holder's public key, and the name of a certification authority (the service centre in the case in question) . The digital certificate also includes a digital signature for the information indicated above, generated by means of a private key of the certification authority. The certification authority thus ensures that the holder of the private key/public key pair is actually the person indicated in the digital certificate. The identity of the certification authority is in turn ensured by a further, higher-level certification authority, up to a generally recognized main certification authority, so as to define a so-called public key infrastructure (PKI) .

The digital signature of the original message is produced by initially generating a hash value also known as a digital fingerprint of the original message. The hash value is constituted by a predetermined number of bits less than that necessary to represent the original message directly; the hash value is nevertheless substantially unique for the original message (in the sense that any change in the original message produces a different hash value) . The hash value is generated with the use of a one-way hash function, in which it is unfeasible from a computational point of view, to derive the original message by knowing the respective hash value. The digital signature is then generated by encrypting the hash value with the signatory's private key. Anyone who receives the original message and the respective digital signature can check the signature simply by generating a further hash value of the original message and checking whether it corresponds to the hash value extracted from the digital signature by means of the signatory's public key.

For simplicity of illustration, the drawing shows only one vendor's computer system 107, only one user's computer system 110c, not, and only one acquirer bank's computer system 130; clearly, however, the system described above may be used with any number of vendors ' computer systems and users ' computer systems connected to the telematics network and with any number of acquirer banks ' computer systems connected to the service centre ^■ s computer system by means of respective dedicated lines. Similar consideration apply if the various computer systems are connected differently, for example, by means of a public or other type of network or by a geographical network (a wide area network, or WAN) , if the user has a system based on a television set or on a mobile telephone connected to the telematics network by means of a WAP protocol (a wireless application protocol) or a UMTS (a universal mobile telecommunications system), etc..

With reference now to Figure 2, the computer 110c is constituted by a personal computer (a PC) formed by various units which are connected in parallel to a communication bus 205. In particular, a microprocessor (μP) 210 controls the operation of the computer 110c, a working memory 215, typically a DRAM, is used directly by the microprocessor 210, and a read-only memory (ROM) 220 contains a bootstrap program for the computer 110c.

Various peripheral units are also connected to the bus 205 (by means of respective interfaces) . In particular, a bulk memory consists of a hard disk 225, a drive device (DRV) 230 for reading optical disks (CD- ROMs) 235, and a drive device (DRV) 240 for reading/writing floppy disks 245.

Finally, the computer 110c includes an input unit which consists of a keyboard 250 and a mouse 255, an output unit which consists of a monitor 260 and a printer 265, an interface (ITF) 270 for the connection of the terminal llOt, and a MODEM 275 for connection to the telematics network 105.

Similar considerations apply if the computer has a different architecture, for example, if it is constituted by a central unit to which various terminals are connected, or by a computer network, if it is provided with other units, such as a sound card, etc.

A structure similar to that described above, suitably scaled, is also used for the vendor's computer system, for the front-end subsystem, for the intermediate subsystem, and for the back-end subsystem of the service centre's computer system, and for the acquirer bank's computer system. For example, the various subsystems of the service centre ' s computer system have a dual structure (to ensure continuity of service) and have a multiprocessor architecture (to offer improved performance) with systems for checking the integrity of the data stored, etc.

With reference now to Figure 3, this shows part of the contents of the working memory of the computer 110c, of the front-end subsystem 120f, of the intermediate subsystem 12Oi, and of the back-end subsystem 120b, during an operation thereof; typically, the information (programs and data) is stored in the bulk memory and is loaded (at least partially) into the working memory during the execution stage, in addition to an operating system and various applications programs (not shown in the drawing) . The programs are initially installed on the hard disk from CD-ROM; alternatively, the programs are supplied on floppy disks, are preloaded on the hard disk, or are stored on any other computer readable medium or are transmitted on a network, broadcast or, more generally, are supplied in any form which can be loaded directly into the working memory. In particular, the computer 110c includes a driver module (M_DRV) 305 which physically controls the transmission of data on the telematics network 105 by means of the MODEM. The driver module of the MODEM 305 communicates with a browser 310 for access to the telematics network 105. The computer 110c also includes a driver module (T_DRV) 315 which physically controls the exchange of data with the terminal llOt; the driver module of the terminal 315 is in communication with the browser 310. The front-end subsystem 120f includes an engine

(ENG) 320 for controlling communication with the telematics network 105. Various web pages (WP) 322 are present in the bulk memory of the front-end subsystem

120f; the web pages 322 are transmitted to the computer 110c (by means of the telematics network 105) under the control of the engine 320. The engine 320 communicates with a certification module (CA) 323 which has reading access to a database 324. The database 324 is constituted by a relational table which contains a record for each smart card holder (accessible by means of an identification code of the holder) ; the record is composed of a field (DC) containing a copy of the holder ' s digital certificate .

The intermediate subsystem 12Oi includes a module 325 for controlling a public key infrastructure (PKI) . The PKI module 325 receives information from a user acquisition module (REG) 326 and correspondingly modifies the database 324 (of the front-end subsystem 12Of) . The customer acquisition module 326 controls a further database 327. The database 327 contains a record for each smart card holder; the record is composed of a field

(INFO) containing information relating to the holder

(such as his name, address, a flag which identifies the holder as a user or an authorized person, an activation flag, etc.) a field (MAX) containing a maximum monthly spending limit for the smart card, and a field (CONT) containing accounting information (such as a list of the transactions carried out by means of the smart card and a total of the purchases made during the current month) . The back-end subsystem 120b includes a module for controlling payment orders (PAY) 338. The payment module 338 has reading access to a database 340 which contains a record for each smart card holder; the record is composed of a field (CC) containing sensitive information relating to a credit card, such as its number, issue date and expiry date; the credit card is always that of the user, either when the holder is the user or an authorized person. The payment module 338 also controls communication with the acquirer bank's computer system 130.

The front-end subsystem 120f and the back-end subsystem 120b communicate with one another by means of a shared area 328 of the memory of the intermediate subsystem llOi, controlled by a producer/consumer policy. This shared memory 328 contains a record for each transaction in progress, composed of a field (ORD) containing an incomplete payment order (described in detail below) and a field (RES) containing information relating to the result of the corresponding transaction. The shared memory 345 is accessed for reading and writing by the engine 320 (of the front-end subsystem 120f) and by the payment module 338 (of the back-end subsystem 12Oi) . The engine 320 also has writing access to the database 327 (of the intermediate subsystem llOi) . Similar considerations apply if the programs and the data are organized differently, if other functions are provided, etc. Alternatively, no digital certificate is stored in the service centre's computer system, the user uses a different payment instrument (such as a debit card, a direct debit on his current account) , the database of the back-end subsystem also stores sensitive data (such as a code for the use of the credit or debit card) , there is provision for the use of various payment instruments (which can be selected by the user or automatically) etc.

With reference now to Figure 4 (in combination with Figure 3), when the service centre's computer system 120 acquires a new user, a series of routines, which together make up a method 400, are performed at successive stages in time. The method 400 starts in box 405 and then goes on to box 410 in which the user's computer 110c is connected (by means of the browser 310) to the site of the service centre's computer system 120. The engine 320 transmits one or more web pages to the user's computer system 110c in order to request the entry of user registration data and possibly a maximum monthly spending limit. The method then goes on to box 415, in which the engine 320 creates a new record for the user in the database 327; the user's registration data and the maximum spending limit are copied, respectively, into the INFO field (asserting the flag which identifies the holder as a user and deasserting the activity flag) , and in the MAX field (this field is set at a value which is not valid if the user does not require a maximum spending limit) ; at the same time, the CONT field is initialized at a value indicative of an absence of transactions.

The method then checks in box 420 whether the user has requested the issue of one or more additional smart cards 112a. If not, the method goes directly to box 425 (described below) . If, on the other hand, additional smart cards 112a have been requested, the method goes to box 427 in which, for each additional smart card requested, the engine 320 sends to the user's computer system 110c one or more web pages requesting the entry of the registration data of the authorized person and of any maximum monthly spending limit. The engine 320 then creates a new record for the authorized person in the database 327, in box 430; the authorized person's registration data and any maximum spending limit are copied, respectively, into the INFO field (deasserting the flag which identifies the holder as a user and the activity flag) and into the MAX field, simultaneously initializing the CONT field. The records of the authorized people and the record of the respective user are related to one another logically by means of suitable pointers. The method then goes on to box 425.

With reference now to box 425, the method generates a paper acceptance form which is sent to the user by post; the acceptance form contains a service contract (to be signed) , a data sheet in which the user enters the sensitive information (number, issue date, expiry date) of his credit card, and a transfer instruction in favour of a current account, of the service centre, to be completed with information relating to a current account of the user (to confirm the user's identify with certainty) .

As soon as the contract and the data sheet (sent back by post in separate envelopes by the user) , are received by the service centre, the method goes to box 450 in which a new record is created for the user and for each authorized person in the database 340. The data sheet is supplied by the service centre to a separate body which checks the formal correctness of the sensitive information relating to the credit card. This separate body then accesses the back-end subsystem 120b and copies the sensitive information relating to the credit card into the CC field of the respective records in the database 340.

Once the transfer instruction (supplied by the user to his own bank) is received by the service centre ' s bank, the method goes to box 465, in which the module 326 asserts the activity flags of the records associated with the user and with the authorized people in the database 327. The module 326 then activates the PKI module 325 which creates a new record for the user and for each authorized person in the database 324. The PKI module 325 then generates a private/public key pair and a respective digital certificate for the user and for each authorized person. The digital certificate is copied into the DC fields of the respective records in the database 32 .

The method then goes to box 470 in which the creation of a new main smart card 112m for the user and of a new additional smart card 112a for each authorized person is activated. The holder's private key, the respective digital certificate, the various programs

(encryption, communication, etc.) and the PIN are stored on each smart card 112m, 112a. The main smart card 112m and any additional smart cards 112a are then sent to the user by post. Going on to box 475, the PIN of each smart card 112m, 112a is sent to the user by electronic mail (e- mail) by means of a compressed file with a password selected by the user (by means of the acceptance form) . The user obtains each PIN by decompressing the corresponding file by means of the same password. The method then terminates in the final box 480.

Similar considerations apply if a different procedure is provided for authenticating the user (or even with the user going to the service centre personally in order to provide the required information) , if the PINs are sent to the user printed inside closed envelopes, if a void transaction is performed on the user's credit card (to check that the sensitive information and the registration data correspond) , if the PIN can be personalized by the user (for example, in order to be set so as to be the same as the access code of a debit card of the user) , etc .

With reference now to Figures 5a-5b (in combination with Figure 3) , these show, as a flow chart, a method by which the user can make a purchase on the telematics network 105. The method starts in box 503 and then goes to box 504 in which the user is connected to the vendor's site and browses through his electronic catalogue. Each time the user selects an item to be purchased, an identification of the item is added to an electronic shopping trolley. Upon completion, the user confirms the goods selected and then orders their purchase. The vendor ' s site requests the user to indicate a method of payment for the purchase. If the user selects the method of payment provided for by the present invention, an incomplete payment order relating to the purchase is generated (by the user in favour of the vendor) . The incomplete payment order includes information identifying the vendor (such as a name) , the amount of the payment, the current date, an order code generated by the vendor ' s computer system, etc.; the incomplete payment order does not, however, contain any sensitive information relating to the user's credit card.

The method goes to box 506 in which a secure connection to the service centre, for example, by means of a HTTPS (secure HTTP) or SSL (secure sockets layer) is activated automatically. The engine 320 sends to the user's computer 110c a web page which invites the holder to insert a smart card (main or additional) in the terminal llOt. As soon as the holder inserts the smart card 112m, 112a in the terminal llOt, the driver module of the terminal 315 sends a corresponding signal to the service centre's computer system 120 (by means of the browser 310 and the MODEM driver module 305) . The method consequently goes on to box 509, in which the engine 320 sends to the user's computer 110c a further web page which invites the holder to type in the PIN of the smart card 112m, 112a on the keypad of the terminal llOt. As soon as the holder types in the PIN (and the PIN typed in corresponds to that stored on the smart card) , the computer 110c sends a corresponding signal to the service centre's computer system 120.

The method goes on to box 512, in which the browser 310 generates a hash value of the incomplete payment order by means of a one-way function. The method then goes to box 515, in which the hash value is sent to the terminal 11Ot (by means of the driver module 315) and hence to the smart card 112m, 112a inserted in the terminal llOt. Going on to box 518, the smart card 112m, 112a generates a digital signature of the hash value corresponding to the incomplete payment order; in particular, the digital signature is generated by encrypting the hash value with the holder's private key (stored on the smart card 112m, 112a) . In box 521, the digital signature and the holder's digital certificate are sent from the smart card 112m, 112a to the driver module 315 of the terminal. Going on to box 524, the same information is passed to the browser 310 and then, together with the incomplete payment order, to the MODEM driver module 305 which sends it to the service centre's computer system 120 (by means of the telematics. network 105).

The information is received by the engine 320 in box 527. The engine 320 interrogates the certification module 323 to check the holder's digital certificate. In particular, the certification module 323 generates a further hash value of the digital certificate and checks whether it corresponds to the hash value extracted from the digital certificate by means of the service centre • s public key. The engine 320 then checks the digital signature of the incomplete payment order in similar manner; in particular, the engine 320 generates a further hash value of the incomplete payment order and checks whether it corresponds to the hash value extracted from the digital signature by means of the holder's public key (obtained from the respective digital certificate) .

If the check has a negative result, the method goes to box 530 in which the purchase is stopped and a corresponding error message is sent to the user's computer 110c and to the vendor's computer system. The method then terminates in the final box 532. If, however, the check has a positive result, the method goes to box 533, in which the vendor's computer system checks that the payment order is correct (that is, whether the amount corresponds to that of the order code) .

If the incomplete payment order is not confirmed by the vendor's computer system, the method goes to box 534 in which the purchase is stopped (and a corresponding error message is sent to the user's computer 110c and to the vendor' s computer system) and then terminates in the final box 532. If, however, the incomplete payment order is confirmed, the method goes to box 535, in which the maximum monthly spending limit and the total spent in the current month are read from the MAX field and from the CONT field of the record in the database 327 associated with the holder, respectively. The amount of the payment order is added to the total spent. If the result of the sum exceeds the spending limit, the method goes to box 536 in which the purchase is stopped (with a corresponding error message) and then terminates in the final box 532.

If, however, the result of the sum does not exceed the spending limit, or if no spending limit is set, the method goes to box 539, in which the engine 320 stores the incomplete payment order in a new record in the shared memory 328; this incomplete payment order is then read by the payment module 338. Going on to box 542, the payment module 338 obtains the sensitive information relating to the user's credit card from the respective record in the database 340; the payment order is completed with this sensitive information.

Going on to box 545, the payment module 338 simulates a real POS terminal and carries out a transaction corresponding to the payment order, sending a message to the acquirer bank's computer system 130. The method then checks the result of the transaction in box 548 and consequently sets the REG field of the corresponding record in the shared memory 328; this result is read by the engine 320. If the transaction has not been carried out (for example, because the credit card is not valid, or a monthly spending limit has been exceeded, etc.) the method goes to box 551 in which the purchase is stopped (with a corresponding error message) and then terminates in the final box 532. If, however, the transaction has been performed correctly, the method goes to box 554 in which the engine 320 updates the record associated with the holder in the database 327 with the information relating to the transaction carried out (adding the amount of the purchase to the monthly total) . Going on to box 557, a confirmation message is sent to the computer 110c; a corresponding electronic mail message (similar to a receipt issued by a real POS terminal) is then sent to the user's computer 110c and to the vendor's computer system; this receipt message is preferably signed digitally by means of the service centre ' s private key (so as to guarantee its authenticity) . The method then terminates in the final box 532.

Similar considerations apply if another equivalent method is implemented, for example, if error procedures are provided for, if various concurrent processes perform the above-described operations in parallel, if the order is not checked with the vendor, if no receipt is issued, etc.; alternatively, a different encryption algorithm is used (for example with an elliptical curve or even symmetrical) , the digital signature is generated in another way (for example, without calculating a hash value), the payment order is sent to the service centre's computer system in encrypted form, different information is sent to the service centre ' s computer system together with the digital signature (or even the digital signature alone) , the digital certificate (with the respective holder's public key) is not stored in the service

, centre ' s computer system, the transaction is carried out differently (for example, by direct connection to a user's bank), etc.

It will be noted that, in the above-described embodiment of the present invention, the service centre does not issue or directly control any credit cards but acts exclusively as a channel for the exchange of information between the various computer systems involved in the transaction. Moreover, the service centre does not arrange any financial operations or generate payment or collection orders independently or on the account of third parties. The service centre does not therefore determine credit positions with regard to any participant in the transaction. However, this does not exclude the use the method of the present invention should that not be the case, for example, if the functions of the service centre are performed directly by the acquirer bank or by the credit-card control circuit.

More generally, in the method of the present invention, an incomplete payment order relating to a purchase of at least one item selected by means of a user's client computer system on a vendor's server computer system is generated; the incomplete payment order is free of sensitive information relating to an instrument of payment of the user. The sensitive information is stored on a server computer system of a service centre and an encryption key is supplied to the user. A digital signature of the incomplete payment order is generated by the user ' s computer system by means of the encryption key and is sent to the service centre's computer system. The service centre's computer system checks the digital signature by means of a corresponding deciphering key, completes the payment order by adding the sensitive information, and carries out a transaction corresponding to the completed payment order.

The method of the present invention is particularly secure since no sensitive information is transmitted on the telematics network (even in encrypted form) . In fact, even if the digital signature were intercepted and deciphered by third parties, it would not provide any information which could be used to make purchases fraudulently (debiting the respective cost to the user's credit card) .

This also ensures that the incomplete payment order has not been altered during transmission on the telematics network; in fact, any modification of the incomplete payment order leads to a negative result of the checking of its digital signature (with consequent stopping of the purchase) .

This method also avoids disclosure of the sensitive information relating to the credit card, which is never communicated to the vendor.

This substantially ensures that it is impossible for the purchase order subsequently to be rejected by the user.

The particular embodiment described above offers further advantages. For example, the digital signature is generated by the smart card off-line and is sent directly to the service centre ' s computer system without the holder's private key passing through the browser in any way; no trace of the private key thus remains on the user ' s computer so that this information cannot be read by third parties who might gain entry to the user ' s computer fraudulently by means of the telematics network. Moreover, the use of smart cards (with the respective PINs) further reduces the chance of the holder's private key being used by unauthorized people; this also makes it extremely difficult (if not impossible) to extract the holder ' s private key from the non-volatile memory of the respective smart card.

The fact that the hash value is generated on the computer and then sent to the smart card for the production of the digital signature considerably reduces the amount of information exchanged between the computer and the terminal and the amount of information processed by the smart card (purely the hash value and not the entire incomplete payment order) .

The particular architecture of the service centre ' s computer system further increases the security of the method of the present invention. In fact, all of the sensitive information relating to the credit cards is stored in the back-end subsystem; this subsystem is not directly accessible from outside, since all of the communications with the front-end subsystem take place by means of the shared memory of the intermediate subsystem. Even if a third party were to succeed in gaining entry to the front-end subsystem fraudulently (via the telematics network) the third party would have access solely to information which is non-sensitive and hence of no use.

Similar considerations apply if a different peripheral device (such as an intelligent terminal) , under the control of which the digital signature is generated, is provided, if the computer sends a different value indicative of the incomplete payment order to the smart card inserted in the terminal, if the shared memory has a different structure, etc. Alternatively, the computer sends the entire incomplete payment order to the smart card, the front-end subsystem and the back-end subsystem communicate with one another in a different way. The method of the present invention may also be used (with a simpler but less secure structure) without any access code for the smart cards, with a different physical key, or simply with a password which activates the encryption program, generating the digital signature directly on the user's computer, or with a service centre ' s computer system formed by a single computer. The additional smart cards make the control of purchases on the telematics network extremeiy flexible

(for example, for a family) . The fact that it is possible to arrange a maximum spending limit also enables the purchases made by family members to be kept constantly under control by the user.

Similar considerations apply if a maximum spending limit is provided only for the additional smart cards, if the maximum spending limits relate to different periods (for example, three months) etc. Alternatively, no maximum spending limit is provided, or it is not possible to issue additional smart cards .

Naturally, in order to satisfy contingent and specific requirements, an expert in the art may apply to the above-described solution many modifications and variations all of which, however, are included within the scope of protection of the invention as defined by the following claims .

Claims

CLAIMS 1. A method (400,500) of carrying out electronic commerce transactions on a telematics network comprising the step of generating (505) an incomplete payment order relating to a purchase of at least one item selected by means of a user's client computer system on a vendor's server computer system, the incomplete payment order being free of sensitive information relating to an instrument of payment of the user, characterized by the steps of: storing (450) the sensitive information on a service centre ' s server computer system, supplying (470-475) a encryption key to the user, generating (506-521) a digital signature of the incomplete payment order by the user's computer system, by means of the encryption key, sending (524) the digital signature to the service centre ' s computer system, and under the control of the service centre ' s computer system: checking (527) the digital signature by means of a corresponding deciphering key, completing (539-542) the payment order by adding the sensitive information, and carrying out (545-557) a transaction corresponding to the completed payment order.

2. A method according to Claim 1, wherein the user's computer system (110c, llOt) includes a computer (110c) connected to the telematics network (105) and a peripheral device (llOt) connected to the computer, the step (506-521) of generating the digital signature comprising the steps of: inputting (506-509) the encryption key to the peripheral device, sending (512-515) a value indicative of the incomplete payment order from the computer to the peripheral device, generating (518) the digital signature under the control of the peripheral device, sending (521) the digital signature from the peripheral device to the computer.

3. A method (400, 500) according to Claim 2, wherein the value indicative of the incomplete payment order consists of a hash value of the incomplete payment order generated by the computer (110c) .

4. A method (400, 500) according to Claim 2 or 3, wherein the peripheral device includes a smart card terminal (llOt) and wherein the step (470-475) of supplying the encryption key to the user comprises the step of supplying (470-475) a smart card (112m) to the user, the encryption key and a encryption program being stored on the smart card, and the digital signature being generated by the smart card when it is inserted in the terminal (llOt) .

5. A method (400, 500) according to Claim 4, further comprising the step of supplying at least one further smart card (112a) to a person authorized by the user, the further smart card being associated with the user's instrument of payment.

6. A method (400, 500) according to Claim 5, further comprising, under the control of the service centre's computer system, for each further smart card (112a), the steps of: storing (430) a maximum spending limit relating to a predetermined period, storing (554) a total amount of the purchases made in the period by means of the further smart card, cancelling (548-551) the payment order if .the sum of the total amount and of the amount of the payment order associated with the further smart card exceeds the corresponding maximum limit.

7. A method (400, 500) according to any one of Claims 1 to 6, wherein the service centre ' s computer system (120) includes a first subsystem (12Of) and a second subsystem (120b) communicating with one another by means of a shared memory (345) of an intermediate subsystem (120i) , the step of checking (527) the digital signature being performed under the control of the first subsystem, and wherein the method further comprises the step of sending (539) the incomplete payment order from the first subsystem to the second subsystem, the steps of completing (542) the payment order and carrying out (545- 557) the corresponding transaction being performed under the control of the second subsystem.

8. A method (400, 500) of carrying out electronic commerce transactions on a telematics network wherein an incomplete payment order relating to a purchase of at least one item selected by means of a user's client computer system on a vendor ' s server computer system is generated, the incomplete payment order being free of sensitive information relating to an instrument of payment of the user, the method comprising, under the control of a service centre ' s computer system, the steps of: storing (450) the sensitive information on the service centre's computer system, supplying (470-475) an encryption key to the user, receiving (506-518) a digital signature of the incomplete payment order generated by the user ' s computer system by means of the encryption key, checking (527) the digital signature by means of a corresponding deciphering key, completing (539-542) the payment order by adding the sensitive information, and carrying out (545-557) a transaction corresponding to the completed payment order.

9. A computer program (320, 340) directly loadable into a working memory of a service centre ' s server computer system (120) for performing the steps of the method of Claim 8 when the program is run on the service centre's computer system (120).

10. A program product (235) comprising a computer readable medium on which the program of Claim 9 is stored.

11. A system (100) for carrying out electronic commerce transactions on a telematics network (105) comprising a user's client processing system (110c, not) having means (310) for generating an incomplete payment order relating to a purchase of at least one item selected on a vendor's server computer system (107), the incomplete payment order being free of sensitive information relating to an instrument of payment of the user, characterized in that it includes a service centre ' s server computer system (120) having means (340) for storing the sensitive information, the user's computer system (110c, llOt) further comprising means (llOt) for generating a digital signature of the incomplete payment order by means of a encryption key and means (305-315) for sending the digital signature to the service centre ' s computer system, and the service centre's computer system (120) further comprising means (320) for checking the digital signature by means of a corresponding deciphering key, means (338) for completing the payment order by adding the sensitive information, and means (338) for carrying out a transaction corresponding to the completed payment order .

12. A service centre's server computer system (120) for use in the system (100) of Claim 11 for carrying out electronic commerce transactions, the service centre's computer system (120) comprising said means (340) for storing the sensitive information, said means (320) for checking the digital signature, said means (338) for completing the payment order, and said means (338) for carrying out the transaction.

13. A user's client computer system (110c, llOt) for use in the system (100) of Claim 11 for carrying out electronic commerce transactions, the user's computer system (110c, llOt) comprising said means (310) for generating the incomplete payment order, said means (llOt) for generating the digital signature, and said means (305-315) for transmitting the digital signature to the service centre's computer system.