EP1192608A2 - Procede et dispositif de paiement electronique - Google Patents

Procede et dispositif de paiement electronique

Info

Publication number
EP1192608A2
EP1192608A2 EP01928004A EP01928004A EP1192608A2 EP 1192608 A2 EP1192608 A2 EP 1192608A2 EP 01928004 A EP01928004 A EP 01928004A EP 01928004 A EP01928004 A EP 01928004A EP 1192608 A2 EP1192608 A2 EP 1192608A2
Authority
EP
European Patent Office
Prior art keywords
payment
user
transmitted
data
server
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Withdrawn
Application number
EP01928004A
Other languages
German (de)
English (en)
Inventor
Gilles Kremer
Martin Lafon
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Magicaxess
Original Assignee
Magicaxess
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Priority claimed from FR0005025A external-priority patent/FR2804264B1/fr
Priority claimed from FR0013101A external-priority patent/FR2814879B1/fr
Priority claimed from FR0015215A external-priority patent/FR2814880B1/fr
Application filed by Magicaxess filed Critical Magicaxess
Priority to EP02015506A priority Critical patent/EP1253564A3/fr
Publication of EP1192608A2 publication Critical patent/EP1192608A2/fr
Withdrawn legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/08—Payment architectures
    • G06Q20/12—Payment architectures specially adapted for electronic shopping systems
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/02—Payment architectures, schemes or protocols involving a neutral party, e.g. certification authority, notary or trusted third party [TTP]
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/04—Payment circuits
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/08—Payment architectures
    • G06Q20/10—Payment architectures specially adapted for electronic funds transfer [EFT] systems; specially adapted for home banking systems
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/32—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using wireless devices
    • G06Q20/322—Aspects of commerce using mobile devices [M-devices]
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/32—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using wireless devices
    • G06Q20/325—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using wireless devices using wireless networks
    • G06Q20/3255—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using wireless devices using wireless networks using mobile network messaging services for payment, e.g. SMS
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/32—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using wireless devices
    • G06Q20/326—Payment applications installed on the mobile devices
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/382—Payment protocols; Details thereof insuring higher security of transaction
    • G06Q20/3821—Electronic credentials
    • G06Q20/38215—Use of certificates or encrypted proofs of transaction rights
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/382—Payment protocols; Details thereof insuring higher security of transaction
    • G06Q20/3825—Use of electronic signatures
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/382—Payment protocols; Details thereof insuring higher security of transaction
    • G06Q20/3829—Payment protocols; Details thereof insuring higher security of transaction involving key management
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/385—Payment protocols; Details thereof using an alias or single-use codes
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/40—Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check credit lines or negative lists
    • G06Q20/401—Transaction verification
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/40—Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check credit lines or negative lists
    • G06Q20/403—Solvency checks
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/42—Confirmation, e.g. check or permission by the legal debtor of payment
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/42—Confirmation, e.g. check or permission by the legal debtor of payment
    • G06Q20/425—Confirmation, e.g. check or permission by the legal debtor of payment using two different networks, one for transaction and one for security confirmation
    • G—PHYSICS
    • G07—CHECKING-DEVICES
    • G07F—COIN-FREED OR LIKE APPARATUS
    • G07F7/00—Mechanisms actuated by objects other than coins to free or to actuate vending, hiring, coin or paper currency dispensing or refunding apparatus
    • G07F7/08—Mechanisms actuated by objects other than coins to free or to actuate vending, hiring, coin or paper currency dispensing or refunding apparatus by coded identity card or credit card or other personal identification means
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3247—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving digital signatures
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3263—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving certificates, e.g. public key certificate [PKC] or attribute certificate [AC]; Public key infrastructure [PKI] arrangements
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2209/00—Additional information or applications relating to cryptographic mechanisms or cryptographic arrangements for secret or secure communication H04L9/00
    • H04L2209/56—Financial cryptography, e.g. electronic payment or e-cash

Definitions

  • the present invention relates to an electronic payment method and device.
  • Websites that offer paid supplies or services often request payment by credit card.
  • users know that if their payment card number is copied with the expiration date, payments can be made with the account attached to this card without their agreement. These users are therefore very reluctant to use such a poorly protected payment method.
  • the present invention proposes to make a payment on a first communication network by implementing a number of single-use means of payment transmitted or validated by implementing a second communication network, preferably secure and comprising unique addresses of terminals, for example a mobile telephone network, two communication sessions being simultaneously open on the two communication networks.
  • a second communication network preferably secure and comprising unique addresses of terminals, for example a mobile telephone network
  • the present invention relates to a payment method comprising an operation of opening a communication session between a first user terminal and a merchant site server, on a first communication medium, characterized in that it includes, during said communication session:
  • the payment is made via a communication session with a payment server, on the first communication network, session during which the second communication network is used to authenticate the payer in transmitting confidential information to it on the second network, which it retransmits on the first network.
  • the payment server transmits payment information to the payee so that the transaction can be carried out.
  • the payment is made by transmitting on the second single address communication network, a means of payment number that the user transmits to the payee that the payee uses to obtain payment, in the same way as an embossed payment card number.
  • the simultaneity of the communication session between the user terminal and the server of the merchant site, on the first communication network and the payment operations ensures a increased security protection because the session on the first network cannot be modified by a third party.
  • the single-use means of payment is transmitted to the customer then the customer is authenticated to validate the use of the single-use means of payment.
  • the client is authenticated and then a single-use payment method is sent to him.
  • the use of the single-use payment method authenticates the customer.
  • the client is protected because the single-use payment method cannot be reused by a third party, in connection with the client's bank or credit account.
  • the site is also protected because the payment is signed, so the client is strongly authenticated and therefore cannot repudiate the payment.
  • the term "single-use means of payment” covers the cases where a number is taken, for example randomly, from a set of numbers of means of payment reserved for the implementation of the present method. This term also covers the case where the means of payment can be reused for a predetermined number of payments, up to a predetermined amount or for a predetermined duration.
  • the single-use payment method can only be used for a transaction corresponding to a communication session in progress between the user's terminal and the merchant site server.
  • each single-use payment method is displayed on a screen of an Internet access terminal.
  • the present invention relates to a graphical payment interface which comprises the display of a single-use means of payment, the user of which is authenticated to validate the use of this means of payment.
  • the present invention also relates to a single-use means of payment with which is associated an authentication carried out in accordance with the means set out in patent application FR 97 13825 filed on November 4, 1997.
  • these means include the transmission of confidential information over a communication medium, typically a telephone network or the transmission of alphanumeric wireless messages, inputting of this confidential information by the user on the Internet access terminal and the transmission of the confidential information over the Internet to authenticate the user.
  • the present invention also aims to solve the problem of the multiplication of encryption keys and of the risks which result therefrom.
  • cryptology a key is inserted at the time of data encryption to ensure the confidentiality of the latter.
  • SSL or Secure Socket Layer for security layer for the IP protocol itself (IPsec)
  • IPsec IP protocol itself
  • the present invention relates, according to one aspect, to a certification process, characterized in that it comprises: an operation for transmitting data from a transmitting computer system to a receiving computer system, on a first communication medium, an operation for generating a trace of said data representative of said data, by the receiving computer system, an operation for transmitting part of said trace to a communication device, on a second communication medium different from the first Communication medium, an operation for receiving said trace part by the transmitting computer system, an operation for transmitting said trace part from the sending computer system to the receiving computer system, and an operation for verifying the correspondence of the trace part received by the receiving computer system with the trace generated by the receiving computer system. Thanks to these provisions, the trace part is linked to said data and can be used to detect a subsequent modification of said data.
  • said trace is representative of a condensate of said domies. Thanks to these provisions, the trace part makes it possible to detect any subsequent modification of said data.
  • the method as succinctly set out above comprises an operation of transmitting an identifier of a user of the sending computer system. Thanks to these provisions, authentication of the user of the transmitting computer system or an electronic signature can be carried out.
  • the method as succinctly explained above comprises an operation of matching said identifier with an address of the communication device on the second communication medium.
  • the address of the communication device is an address which corresponds to the user of the sending computer system.
  • said trace is representative of a private key kept by the receiving computer system. Thanks to these provisions, the receiving computer system performs a signature of said data.
  • the method as succinctly explained above comprises an operation of matching said identifier with said private key. Thanks to these provisions, the receiving computer system performs a signature of said data on behalf of the user of the sending computer system.
  • the method as succinctly explained above comprises an operation of truncating said trace, and in that during the operation of transmitting at least part of said trace, the result of said truncation is transmitted. Thanks to these provisions, the part of said trace comprises fewer symbols than said trace.
  • the first communication medium is the Internet. Thanks to these provisions, data can be transmitted from any computer system connected to the Internet.
  • the second communication medium is a wireless network. Thanks to these provisions, authentication of the user of the sending computer system can be carried out at any location.
  • an identifier of a recipient computer system is transmitted, said method comprising an operation of transmitting said data from the receiving computer system to a computer system recipient.
  • the receiving computer system can serve as an intermediary in a transmission between the sending computer system and the recipient computer system. It can, moreover, provide dating, notarization or hand delivery certification functions to the recipient of said data.
  • the method as succinctly described above comprises an operation of matching said data with a public key and in that during the operation of transmitting said data to said recipient computer system, said public key is transmitted. Thanks to these provisions, the recipient of said data can verify the identity of the sender of said data, by implementing the public key.
  • the method as succinctly described above comprises an operation for generating confidential information by the receiving computer system and an operation for transmitting confidential information to a communication device to a second communication device. on the second communication medium, by the receiving computer system, an operation for receiving said confidential information by the receiving computer system, on the first communication means and an operation for verifying correspondence between the confidential information transmitted by the receiving computer system with confidential information received by the receiving computer system.
  • the present invention also relates to a certification device, characterized in that it comprises: a means of transmitting data from a transmitting computer system to a receiving computer system, on a first communication medium, means for generating a trace of said data representative of said data, by the receiving computer system,
  • the present invention relates, according to one aspect, to a certification process, characterized in that it comprises: an operation of receiving a disposable certificate;
  • the present invention relates to a certification method, characterized in that it comprises: - a first operation of signing data by a device for supplying said data without the private key of the user who supplies said data; and a second data signing operation which substitutes for the first signature, a second signature implementing a private key of said user.
  • the present invention relates to a data transmission method, characterized in that it comprises: an operation for transmitting said data from a first computer system to a second computer system; an operation for generating a seal or condensate representative of said data, from said data;
  • keys, seals, condensates or certificates are not stored on a user terminal, which protects them against any risk of theft or copying.
  • the certification can thus be independent of the terminal implemented by the signatory, which makes the signature portable from one system to another.
  • the disposable certificate has the same security characteristics as a private key.
  • a trace of the data to be transmitted is determined in the form known as the condensate (in English "hash"). Thanks to these provisions, any modification of the data to be transmitted after the generation of this condensate is detectable by use of the condensate.
  • an application routine that has been downloaded beforehand is implemented. Thanks to these provisions, the transmission of the data to be transmitted is protected by said routine. According to particular characteristics of each aspect of the present invention, during the operation of transmitting the encrypted data, the data to be transmitted are also transmitted. Thanks to these provisions, any modification of the data to be transmitted can be detected by using the encrypted data.
  • a secret seal is transmitted to a receiver on a telecommunications network and entered by the signatory on a user station which transmitted the data to pass. Thanks to these provisions, the user of the user station is authenticated by the fact that he simultaneously has a receiver on the telecommunications network.
  • the method comprises a signature substitution operation during which a private key of the signatory is associated with the data to be transmitted. Thanks to these provisions, the private key of a user can be kept in place on, on a security server, in such a way that no user station implemented by the data transmitter to be transmitted has to keep said private key. The private key is thus particularly protected.
  • the method comprises an operation of associating a date and a time with the transmitted data. Thanks to these provisions, data transmission is time-stamped. According to particular characteristics of each aspect of the present invention, the method includes an operation of storing the transmitted data and a signature. Thanks to these provisions, there is notarization of the transmitted data.
  • the disposable certificate is a certificate with a shorter life at one o'clock. Thanks to these provisions, the same certificate cannot be used for more than a predetermined period.
  • the present invention also relates to a certification device, characterized in that it comprises: - a means for generating a disposable certificate;
  • the user or client identifies himself on a first communication medium, for example the Internet, by providing a certificate, for example conforming to the PKI public key infrastructure, and said certificate comprises the unique address of a terminal of said user on a second communication medium, for example a mobile telephone number of the user.
  • a certificate for example conforming to the PKI public key infrastructure
  • said certificate comprises the unique address of a terminal of said user on a second communication medium, for example a mobile telephone number of the user.
  • the unique address on the second medium is encrypted with a public key in such a way that only certain authorized organizations or certain certification authorities can decrypt said unique address.
  • the certificate which comprises said unique address on the second communication medium points to, that is to say identifies or comprises, another certificate, for example conforming to the PKI public key infrastructure, which does not does not include said unique address.
  • FIG. 1 represents transmission of messages between entities participating in a transaction , according to a first embodiment
  • FIG. 2 represents transmissions of messages between entities participating in a transaction
  • FIG. 3 represents an image of a means of payment for electronic single use
  • FIG. 4 represents transmissions of messages between entities participating in a transaction
  • FIG. 5 represents transmissions of messages between entities participating in a transaction
  • FIG. 6 represents a succession of operations performed by a user terminal and a certification server, in a particular embodiment of the present invention
  • FIG. 7 represents a succession of operations performed by a user terminal and the certification server, in another particular embodiment of the present invention
  • FIG. 8 represents a succession of operations carried out by a terminal user and the certification server, in another particular embodiment of the present invention
  • FIG. 9 represents a flow diagram of implementation of another embodiment of the present invention.
  • single address terminal indicates a terminal on a communication network whose address cannot be assigned to another terminal. For example, a phone or pager is a single address terminal.
  • a customer is registered and has an account with a financial institution that implements a payment server adapted to determine a terminal address on a medium. communication in which each address is assigned to at most one terminal.
  • This account allows him to have a confidential domies storage file known as the "Server Side Wallet”. In this file are stored information relating to the payment method available to the customer and in particular relating to an electronic checkbook.
  • the financial institution is of the 'Issuer' type, that is to say, issuer of means of payment, here for single use, or it is an intermediary having concluded agreements with 'Issuer' banks.
  • the merchant has an agreement with the financial institution 'Issuer' and he has an open account which does not necessarily replace his traditional bank account in his bank called 'Acquirer' because it receives payments on behalf of the merchant.
  • the merchant presents, on the payment page of his site, an icon proposing to his customers to pay by means of a means of payment called "means of payment for electronic single use".
  • this icon can be that of a bank or a type of bank card.
  • the customer decides to pay for the items he has chosen and listed in his basket (known in France as “caddy”, registered trademark and in English as “shopping kart”).
  • the customer chooses as payment method the "electronic single use payment method" offered by the merchant. It is observed that this choice can be made by selecting a bank icon or an icon representing a check book or a check, for example.
  • the merchant refers the processing of this request to the financial body (or intermediary) which offers this payment service by electronic single-use payment method.
  • the client finds himself directly on a site of the financial organization.
  • the financial organization asks the client to identify himself to access the electronic checkbook service.
  • the client identifies himself.
  • the customer gives his name, first name, a user name and / or a password known only to him.
  • the financial organization presents the customer with the electronic single-use payment method filled with the elements corresponding to the transaction (name of the merchant, amount, time stamp, ...) for acceptance and electronic signature.
  • the single-use means of payment is represented in the form of a check on the screen of the client's terminal.
  • the customer confirms his acceptance.
  • the client selects with a pointing device such as a mouse, a "validation of payment” button.
  • the financial organization calculates an electronic signature, or seal, that is to say a sequence of non-predictable symbols and sends a certificate linked to the transaction and containing this sequence, via a mobile telephone network, such as the network GSM, on the customer's mobile.
  • the signature or seal is transmitted in the form of a short message known as "SMS”.
  • the customer authenticates and signs the electronic single-use payment method by re-entering the electronic signature of the certificate on the keyboard of his consultation station (or terminal) connected to the Internet (principle of electronic signature).
  • the financial organization returns the confirmation of payment to the customer and the merchant so that the latter delivers the products purchased.
  • a user of a first communication terminal connected to a communication network opens a communication session with a merchant site.
  • the merchant site offers payment by electronic single-use payment method and, in the event of acceptance by the customer, the merchant site or the first terminal opens a second communication session with a medium supplier site.
  • electronic single use payment method or the terminal issues an electronic single use payment method
  • a window representing the single use payment method comprises one, several or, preferably, all following fields:
  • confidential information is communicated to the user, via a second communication medium, such as a mobile telephone network or an alphanumeric message transmission network.
  • the user then enters the confidential information on the first terminal and the first terminal transmits this confidential information to the merchant site.
  • the method comprises an operation of transmission, by the merchant site, of a request for the issuance of the payment certificate to a third party site.
  • the third-party site transmits an available amount to an account assigned to said user.
  • the method comprises an operation of assigning a certificate of integrity to the set consisting of the single-use payment method and the confidential information entered by the user.
  • a client accesses, via a terminal 100 and a computer network 110, for example the Internet, to a merchant site 120, hosted by a network server 130 ( operation 105).
  • the client identifies himself by giving his names, first names and address or by the transmission, by the terminal 100 of a unique certificate issued to the client, for example a certificate linked to the PKI public key infrastructure.
  • a unique certificate issued to the client, for example a certificate linked to the PKI public key infrastructure.
  • the customer selects a payment option by electronic single-use payment method offered by the merchant site 120 (operation 115). It is observed that the merchant site 120 may only offer this option, because, unlike payments by bank card without signature, the customer cannot repudiate a payment made with signature or authentication.
  • the network server 130 then transfers the client to a payment site
  • the network server 130 of the merchant site 120 transmits to the network server 150 of the payment site 140 information representative of the identity of the merchant, of the merchant's bank references, of the identity of the client, of a single certificate issued to the client in accordance with the PKI public key infrastructure, of the amount of the transaction, of the time stamp and / or of the goods or services subject to the transaction (operation 135).
  • the client provides all or part of this information to the server 150 via the terminal 100, for example by transmission of a certificate issued to the client in accordance with the PKI public key infrastructure or by keyboard input (operation 136).
  • the payment server 150 determines whether the payment can be authorized, for example according to the identity of the customer, the amount of the payment, a statement of a financial or bank account of the customer, according to known procedures (operation 137 ). If payment can be authorized, the server 150 of the payment site 140 transmits information, for example an image, representative of an electronic single-use means of payment, for example a check image, to the client's terminal 100 (operation 145). In exemplary embodiments, this electronic single-use payment method is already partially or completely pre-filled, with all or part of the information transmitted during operation 135 (operation 155).
  • the client validates or not the payment by selecting, or not, a validation button linked to the information received by the terminal 100 during operation 145 (operation 165).
  • the network server 150 of the payment site 140 transmits to a signature server 160 information identifying the client (operation 175).
  • the server 150 transmits to the signature server information relating to the payment, for example the object of the payment, the amount of the payment, the time stamp and / or the name of the merchant.
  • the signature server 160 searches in a domiciled base or in a correspondence table for a unique address of a telecommunication terminal 170 linked to the client, for example a mobile telephone number on a mobile telephone network (operation 185).
  • the signature server 160 determines a single-use seal, in the form of a sequence of symbols (operation 186).
  • the seal depends on at least one element of the transaction, for example, the amount, the identity of the merchant, the identity of the customer, a unique certificate issued to the customer, the time stamp and / or the subject of the transaction.
  • the seal is determined as a mathematical function (by example a "hash” or condensate) of all or part of these elements.
  • the seal depends on the identity of the client and / or on a unique certificate issued to the client (for example linked to the PKI infrastructure for "public Key Infrastructure" or public key infrastructure).
  • the signature server 160 transmits to the telecommunications terminal
  • the signature server 160 transmits to the telecommunications terminal 170 at least one element of the transaction, for example, the amount, the identity of the merchant, the identity of the customer, the time stamp and / or the object of the transaction in addition to the seal (operation 188).
  • the customer reads the seal on a screen of the terminal 170 or listens to the symbol sequence dictated by a voice server on a loudspeaker of the terminal 170 then enters the seal on the terminal 100, for example on the keyboard or by voice dictation (operation 189).
  • the client connects the terminal 170 to the terminal 100 so that the transmission of the seal takes place automatically.
  • the seal is transmitted by the terminal 100 to the network server 150 (operation 191).
  • the server 150 transmits the seal to the signature server 160 (operation 192).
  • the signature server checks the seal (operation 193) and, if there is a correspondence between the seal issued during operation 187 and the seal received during operation 192, the signature server 160 transmits validation information signature to server 150 (operation 194).
  • the server 150 transmits payment validation information to the network server 130 (operation 195).
  • the signature server invalidates the seal for any other payment (operation 196).
  • the signature server 160 transmits signature failure information to the server 150 (operation 197) and the server 150 informs the client of the signature failure and asks him to supply the seal (operation 198) and operations 191 and following repeat themselves.
  • the signature server invalidates the seal and the payment server 150 transmits non-payment information to the server 130.
  • the servers 130, 150 and 160 have been shown as separate, in exemplary embodiments, at least two of the servers 130, 150 and 160 may be combined.
  • the operations 125 and following all take place during the same communication session between the terminal 100 and the server 150.
  • this communication session is secure, for example encrypted according to the SSL encryption standard.
  • FIG. 3 is shown an image of an electronic single-use payment method, as it can be displayed on a screen 19 of a terminal accessible to a customer.
  • This image 20 resembles that of a check comprising information areas: an area 21 indicating contact details of the issuing body, an area 22 indicating customer contact details, an area 23 indicating the amount of payment, in figures, a zone 24 indicating the amount of the payment, in words, a zone 25 indicating a number of means of payment, a zone 26 indicated the coordinates of the merchant, possibly, a reference zone 27 where the object of the transaction is indicated, - a signature zone 28, which here takes the form of a button
  • zones 21 to 27 and 29 are filled in automatically based on information provided by a merchant site server and / or a payment server, so that the customer only has to check the information carried by the electronic single-use payment method and to validate the payment by first clicking on the "validate payment and sign" button, then by entering a seal which it receives on a second communication medium with unique addresses, for example a mobile telephone network.
  • the image of the single-use payment method is automatically stored in the customer terminal's non-volatile memory.
  • an electronic single-use payment means is associated with a summary of transaction elements comprising at least the amount of the transaction, and, preferably, an identification of the merchant.
  • a client terminal 200 accesses via a first communication network 210, for example the Internet, to a merchant site server 220 (operation 205).
  • a first communication network 210 for example the Internet
  • a merchant site server 220 operation 205.
  • the terminal 200 provides the server 220 with an identifier of the user of the terminal 200, for example his names, first names and address, an abomiee name with or without password, a cookie, file placed by the merchant site on the terminal 200 (operation 209) or a single certificate issued to the user of terminal 200 in accordance with the PKI public key infrastructure.
  • an identifier of the user of the terminal 200 for example his names, first names and address, an abomiee name with or without password, a cookie, file placed by the merchant site on the terminal 200 (operation 209) or a single certificate issued to the user of terminal 200 in accordance with the PKI public key infrastructure.
  • the customer initiates payment operations by selecting a payment function on a page of said site, for example by clicking on a button (operation 211). While retaining, until the end of the payment operations, the open communication session with the terminal 200 connected to the first communication means 210, the server 220 of the merchant site provides, for example on the first communication network, an identification from the client to a payment server 230, preferably with an identifier of the working site, and a payment amount (operation 213).
  • the payment server 230 determines an address on the second communication network 240, preferably with unique addresses, for example a telephone network, for example a mobile network (operation 215).
  • the payment server 230 determines a number of single-use means of payment (operation 217) of which it stores in memory (operation 219) the relationship with an account 250 of the client, for example a credit card account or a bank account.
  • the number of single-use means of payment depends on the identity of the customer and / or elements of the transaction, for example the amount, the time stamp or the identity of the merchant.
  • the one-time payment method number is selected from a set of numbers similar to embossed payment card numbers.
  • the payment server 230 determines whether the payment is authorized, for example as a function of the amount of the payment and of payment authorization information associated with the account 250 (operation 221).
  • the payment server 230 transmits the number of single-use payment means to a terminal 260 connected to the second communication network 240 which has said address on the second communication network, for example by means of a short message (operation 223 ).
  • the payment server 230 determines a maximum duration of validity of the number of single-use payment means (operation 225).
  • the payment server transmits to the terminal 260 on the second communication network 240, the amount of the payment and / or an identifier of the merchant site (operation 227).
  • the terminal 260 receives the information transmitted and retransmits to the terminal 200, by an electronic link (operation 229) between the terminals 260 and 200 or, preferably, by manual copying carried out by the user of the terminals 200 and 260 in a window of a page on the merchant site provided for this purpose (operation 231), the single-use payment number.
  • the terminal 200 transmits to server 220 the number of single-use means of payment (operation 233).
  • the single use payment number takes the form of a known type payment card number and the user uses the single use payment number as a payment card number embossed on a plastic payment card.
  • the server 220 of the merchant site transmits the number of single-use means of payment to the payment server 230 (operation 235).
  • the server of the merchant site 220 transmits, if necessary, an amount of payment, an identifier of the merchant site and / or an identifier of the merchant's account, in particular that of this information which has not yet been transmitted to the payment server 230 ( operation 237).
  • the payment server 230 verifies the correspondence between the number of single-use payment method that the payment server 230 has transmitted to said address on the second communication network and the number of single-use payment method that the payment server receives from the server of the merchant site (operation 239).
  • the payment server 230 sends payment authorization information to the server 220 of the merchant site (operation 243), causes payment , possibly deferred, from the customer's account to the merchant's account, by modifying data stored in memory in relation to the customer's account (operation 245) and by causing the modification of data stored in memory in relation to a merchant's account (operation 247), and invalidates a new use of the same number of single-use means of payment in relation to the bank or credit accounts of the user (operation 249).
  • a user terminal 300 client accesses a payment server 310 on a first communication network 320, for example the Internet (operation 303) and asks a payment server 310 for a means number payment to single use, during a communication session on a first communication network 320 (operation 305).
  • the terminal 300 transmits to the payment server 310 an identifier of the user, for example his names, first names and address, a subscriber name with or without password, a cookie, file placed by the payment server 310 on the terminal 300 or a single certificate issued to the client in accordance with the PKI public key infrastructure (operation 307).
  • the payment server 310 determines an address on a second communication network 330, preferably with unique addresses, for example a telephone network, for example a mobile network (operation 309).
  • the payment server 310 also determines a number of single-use means of payment, the means of payment of which stores in memory 340 the relationship with a customer account, for example a credit card account or a bank account (operation 311).
  • the payment server 310 determines a duration of use of the single-use payment means (operation 313).
  • the means of payment number is selected from a set of available numbers similar to embossed payment card numbers.
  • the payment server 310 transmits the number of single-use payment means to a terminal 350 connected to the second communication network 330 which has said address on the second communication network 330, for example by means of a short message (operation 315).
  • the user receives the transmitted information (operation 317) and uses this single-use payment method to pay for a purchase on a merchant site 360 (operation 319), in a way that is in itself, for example by entering it into spaces provided to receive bank card numbers.
  • the server of the merchant site 360 transmits the number of single-use payment method to the payment server 310 with a payment amount, an identifier of the merchant site and / or an identifier of the merchant's account (operation 321).
  • the payment server 310 verifies the correspondence between the number of single-use payment method that it transmitted to the terminal 350 and the number of single-use payment method that the payment server 310 receives from the server of the merchant site 360 ( test 323) and, in the event of a correspondence, checks that the maximum duration of use of the single-use means of payment has not been exceeded (operation 325) and determines whether the payment is authorized, for example according to the amount of the payment to perform and information associated with customer account 370 (test 327).
  • the payment server 310 sends payment authorization information to the server 360 of the merchant site (operation 329), causes the payment, possibly deferred, from the customer's account to the merchant's account, by modifying data kept in memory in relation to the customer's account (operation 331) and by causing the modification of data kept in memory in relation to a merchant's account 380 (operation 333) , and invalidates a new use of the same single-use means of payment number in connection with the user's bank or credit accounts (operation 335).
  • FIG. 6 are represented a user station or transmitting computer system 600, an Internet application 610, a clean room 620, a storage memory 630, a second communication network 640 and a receiver 650 on the second communication network 640.
  • the room blanche 620 includes a firewall protection (in English "firewall") 660, a security server 670 and a certificate generator 680.
  • the operations carried out in the particular embodiment illustrated in FIG. 6 are represented in rectangles and numbered by 501 to 512.
  • the Internet application 610 and the clean room 620 are jointly called the receiving computer system.
  • the user station 600 is, for example, a personal computer (PC), a network computer (NC) or a personal digital assistant (in English Personal Digital Assistant or PDA) or any terminal allowing a remote communication, interactive terminal, TV decoder, etc.
  • the user station 600 is provided with remote communication software for implementing the Internet application 610, together with the security server 670.
  • This communication software remotely can be navigation software or e-mail software, for example.
  • the Internet application 610 allows communication between the user station 600 and the security server 670 and the transmission of data from the user station 600 to the storage memory 630, for example via the security server 670.
  • the room blanche 620 is a space protected against any physical intrusion, such as a bank vault.
  • the storage memory 630 is a memory adapted to store data for a long period, which exceeds one year.
  • the second communication network 640 is, for example, a telephone network and, even more particularly a network of mobile telephony or of alphanumeric receivers commonly called “pagers".
  • the second network 640 is called “second” by comparison with the Internet network, which is also called “first” network in the remainder of this patent application.
  • the second network 640 is suitable for transmitting a key, a seal, a condensate or a certificate from the security server 670 to the receiver 650.
  • the receiver 650 on the second network 640 can, depending on the type of second network 640, be any mobile phone, pager or receiver.
  • the receiver 650 allows the user of the user station 600 to take cognizance of information transmitted by the security server 670.
  • the firewall protection 660 is of hardware and / or software type and prohibits any software intrusion into the security server 670.
  • the security server 670 is a known type of computer server.
  • the 680 certificate generator is suitable for generating disposable certificates, for example of the type conforming to the PKI public key infrastructure, for example in accordance with the X509-V3 standard.
  • the user station 600 and the security server 670 are jointly adapted to implement the operations indicated below.
  • the security server 670 is suitable for providing application routines or "applets" to the user station 600.
  • the Internet application 610 downloads a certified application routine signed in the user station 600. It is observed that the application routine in question may not be downloaded that in the case where a copy of this routine is not already installed in the user station 600. This particular characteristic makes it possible to make portable the certification process object of the present invention, without slowing down this process in the case where the user successively implements the same user station 600, for several data certifications.
  • the certificate generator 680 generates a disposable certificate, for example in the form of a private key conforming to the PKI public key infrastructure, for example in accordance with the X509-V3 standard. For example, the disposable certificate is generated randomly by the generator 680.
  • the security server 670 transmits the disposable certificate to user station 600.
  • user station 600 implements the application routine downloaded during operation 501 to obtain a trace of the data to be transmitted, called condensate (in English "hash"), a trace which depends on the disposable certificate generated during operation 502 and the data to be transmitted and which allows the detection of any subsequent modification of the data to be transmitted.
  • condensate in English "hash"
  • the data to be transmitted and the condensate are downloaded from user station 600 to the Internet application 610.
  • the coordinates of each recipient of the data to be transmitted is transmitted by the user station 600 to the Internet application 610. These coordinates can take the form of electronic mail address (in English "e-mail"), telephone number or any other type of information allowing contact with each recipient of the data to be transmitted.
  • the integrity of the data to be transmitted is checked, using the disposable key generated during operation 502 and the condensate.
  • the disposable certificate generated during operation 502 is a certificate with a very short lifespan, preferably less than one hour.
  • the operation 510 is not executed since beyond the lifetime of the disposable certificate, this certificate cannot be used to certify data.
  • the operations 507 and 508 correspond to an example of signature which can be used in combination with the operations 501 to 506 above.
  • a secret seal is generated and transmitted, via the second network 640, to the receiver 650.
  • the address of the receiver 650 on the second network is determined by matching the identifier of the user transmitted during operation 501 with said address, in a correspondence table.
  • the secret seal is calculated on the signature elements of the document.
  • the secret seal depends on the data to be transmitted, their number, their content, the date and time of the generation of the secret seal, the private key of the data transmitter determined in correspondence. with the identifier of the user transmitted during operation 501, the internet address ("IP address") of the user station 600 and / or a number of the internet session during which the data is transmitted.
  • IP address internet address
  • the secret seal is obtained by calculation of a condensate of the data to be transmitted, for example in the form of a sequence of twenty symbols, of encryption of this condensate by the key the user of the user station 600, and of extracting part of the result of this encryption, for example eight symbols out of twenty.
  • At least one coordinate of at least one recipient of the data to be transmitted is transmitted with the secret seal, during operation 507, so that the sending user can identify the message that he is in the process of sign.
  • operations 507 to 509 are replaced by a signatme operation based on the use of a memory card ("smart card”) or a biometric measurement or any other means deemed reliable for strong authentication. of the user.
  • a memory card (“smart card”) or a biometric measurement or any other means deemed reliable for strong authentication. of the user.
  • Operation 509 consists in substituting a so-called PKI signature (for Public Key Infrastructure) for the signature carried out during operations
  • the transmitted domies are signed with the private key of the user who transmitted them (known as the "signatory" of the data).
  • the data transmitted, certified and signed by private key are transmitted to the storage memory 630 with a date and, optionally, a time in such a way that they are time-stamped, archived and notarized.
  • a recipient is, following operation 511, informed of the availability of the data to be transmitted and of operations similar to the operations set out above. above are implemented to make a certified copy on the user station of the recipient after having collected from him a signature.
  • FIG. 7 An example of a succession of operations implemented for this hand delivery is given in FIG. 7.
  • a destination user station or recipient computer system 700 the Internet application 610, the clean room 620, the storage memory 630, the second communication network 640 and a receiver 750 on the second communication network 640.
  • the operations carried out in the particular embodiment illustrated in FIG. 7 are represented in rectangles and numbered from 513 to 525. These operations can follow operations 501 to 512 illustrated in FIG. 6 and carried out in relation to a user station 600 generally different from the user station 700.
  • the destination user station 700 is, for example, a personal computer (PC), a network computer (NC) or a personal digital assistant (in English Personal Digital Assistant or PDA).
  • the destination user station 700 is provided with remote communication software for implementing the Internet application 610, together with the security server 670.
  • This remote communication software can be a navigation software or a mail software electronics, for example.
  • the Internet application 610 allows communication between the user station 700 and the security server 670 and the transmission of data from the user station 700 to the storage memory 630, for example via the security server 670.
  • the receiver 750 on the second network 640 can, depending on the type of second network 640, be a mobile phone, a pager or any receiver.
  • the receiver 750 allows the user of the destination user station 700 to take cognizance of information transmitted by the security server 670.
  • the destination user station 700 and the security server 670 are jointly adapted to implement the operations indicated above. below.
  • the security server 670 is adapted to supply application routines or "applets" to the destination user station 700.
  • the user of the destination user station 700 initially connects to the first network, for example to consult electronic mails.
  • the Internet application 610 sends to the destination user station 700 an electronic mail (e-mail) which indicates that information is made available to the user of the station 700.
  • e-mail electronic mail
  • at least one address of the sending user is transmitted in this electronic mail so that the recipient can identify the sending user.
  • the user accesses the internal application 610 by selecting his Internet address.
  • the Internet application 610 downloads a certified application routine to the destination user station 700. It is observed that the application routine in question can only be downloaded in the case where a copy of this routine is not already installed in the user station 700. This particular characteristic makes the certification process which is the subject of the present invention portable, without slowing down this process in the case where the user successively implements the same destination user station 700 , to receive several given sets. It is observed that the application routines downloaded during operations 501 and 515 can be identical to allow on the one hand the transmission of data to the memory 630 and, on the other hand, to receive data from this memory.
  • the operations 516 and 517 correspond to an example of signature which can be used in combination with the operations 513 to 515 above.
  • a secret seal is generated and transmitted, via the second network 640, to the receiver 750.
  • the secret seal is calculated on the signature elements of the document.
  • the secret seal depends on the data to be transmitted, their number, their content, the date and time of the generation of the seal, and or a number of the Internet session during which the data is transmitted.
  • At least one coordinate of the sending user of the data to be transmitted is transmitted with the secret seal, during operation 516, so that the receiving user can identify the sending user.
  • the certificate generator 680 generates a withdrawal certificate, for example in the form of a key conforming to the PKI public key infrastructure, for example in accordance with the X509-V3 standard.
  • the withdrawal certificate contains the public key of the user of the user station 600.
  • the security server 670 transmits the withdrawal certificate to the destination user station 700.
  • l application 610 determines a condensate of the data to be transmitted, which depends on the withdrawal certificate generated during operation 518 and on the data to be transmitted and which allows the detection of any subsequent modification of the data to be transmitted.
  • the data to be transmitted and the condensate are downloaded from the hitemet application 610 to the destination user station 700.
  • the integrity of the data to be transmitted is checked, in using the public key contained in the withdrawal certificate generated during operation 518 and the condensate.
  • a trace of the transmission of the data to the recipient user is certified and stored in the storage memory 630. This date and, optionally, a time is associated with the data. transmitted and is thus time-stamped, archived and notarized.
  • the security server makes available to the sender of the transmitted data an acknowledgment of receipt which informs it that the data which it has transmitted during operation 504 have been received by the 'one of their recipient. It is observed that an acknowledgment of receipt is transmitted to the data sender for each of the recipients of the data.
  • FIG. 8 are represented the user station or transmitting computer system 600, an Internet application 810, the clean room 620, the storage memory 630, the second communication network 640 and the receiver 650 on the second communication network 640.
  • the operations performed in the particular embodiment illustrated in FIG. 8 are represented in rectangles and numbered from 531 to 542.
  • the Internet application 810 and the clean room 620 are jointly called receiving computer system.
  • the user station 600 and the security server 670 are jointly adapted to implement the operations 531 to 542 indicated below.
  • the certification process it is assumed that several data sets are to be transmitted in a certified and signed manner from the user station 600 to the storage memory 630.
  • the user of the user station 600 connects to the security server 620 to start the certification process.
  • the Internet application 810 downloads a certified application routine to the user station 600. It is observed that the application routine in question may only be downloaded in the case where a copy of this routine is not already installed in the user station 600. This particular characteristic makes it possible to make portable the certification process object of the present invention, without slowing down this process in the case where the user successively puts uses the same user station 600, for several data certifications.
  • the certificate generator 680 generates a disposable certificate, for example in the form of a key private in accordance with the PKI public key infrastructure, for example in accordance with the X509-V3 standard. For example, the disposable certificate is generated randomly by the generator 680.
  • the security server 670 transmits the disposable certificate to the user station 600.
  • the user explicitly selects each of the data sets to be transmitted. For example, the user of the user station 600 selects, one by one, files to be transmitted, each file constituting a set of data to be transmitted. Still in the operation 534 coms, the user 600, implements the application routine downloaded in the operation 531 coms to obtain a condensate of each of the sets of data to be transmitted, which depends on the disposable certificate generated during operation 532 and data from said set. Each condensate allows the detection of any subsequent modification of a set of data to be transmitted.
  • the data sets to be transmitted and the condensates are downloaded from the user station 600 to the Internet application 810.
  • the coordinates of each recipient of each set of data to be transmitted is transmitted by the user extension 600 to the Internet application 610.
  • These contact details can take the form of an e-mail address, telephone number or any other type of information enabling each recipient to be contacted of the dominated to transmit.
  • the integrity of the data sets to be transmitted is checked, by using the disposable key generated during operation 532 and the condensates.
  • the disposable certificate generated during operation 532 is a certificate with a very short lifespan, preferably less than one hour.
  • the operation 510 is not executed since beyond the lifetime of the disposable certificate, this certificate cannot be used to certify data.
  • the operations 537 and 538 correspond to an example of signature which can be used in combination with the operations 531 to 536 above.
  • a secret seal is generated and transmitted, via the second network 640, to the receiver 650.
  • the address of the receiver 650 s the second network is determined by matching the identifier of the user transmitted during operation 531 with said address, in a correspondence table.
  • the secret seal depends on the areas to be transmitted, the number, the content, the date and time of the generation of the secret seal, the private key of the data transmitter determined in correspondence with the identifier of the user transmitted during operation 531, the internet address ("IP address") of the user station 600 and / or a number of the internet session during which the dominates are transmitted.
  • IP address internet address
  • the secret seal is obtained by calculating a condensate of the data to be transmitted, for example in the form of a sequence of 20 symbols, encrypting this condensate by the key the user of the user station 600 and of extracting part of the result of this encryption.
  • at least one coordinate of at least one recipient of the data to be transmitted is transmitted with the secret seal, during operation 537, so that the sending user can identify the data to be transmitted that he is in signing or at least half recipient of this data.
  • the reader will be able to refer to FIG. 9 and / or to the patent application PCT / FR98 / 02348 for better knowing examples of steps implemented during operations 537 and 538.
  • the common user of the user station 600 and the receiver 650 enters the secret seal and this secret seal is transmitted to the security server 670 where the seal is verified, operation 539.
  • operations 537 to 539 are replaced by a signature operation based on the use of a memory card ("smart card”) or a biometric measurement.
  • the transmitted data sets are therefore certified to be intact and signed by the user who transmits them.
  • Operation 539 consists in substituting a so-called PKI signature (for Public Key Infrastructure) for the signature made at the level of operations 537 and 538.
  • PKI signature for Public Key Infrastructure
  • the transmitted data sets are signed with the private key of the user who transmitted it (known as the "signatory" of the data).
  • the data sets transmitted, certified and signed by private key are transmitted to the storage memory 630 with a date and, optionally, a time, in such a way that they are time-stamped, archived. and notarized.
  • FIG. 9 represents a flow diagram of implementation of another embodiment of the present invention.
  • operations relating to a so-called "sender" computer system 901 implementing a first communication medium In the column to the right of the leftmost column are shown operations relating to a first communication device 902 implementing a second communication medium.
  • the sending computer system 901 and the first communication device 902 are used by a user who wishes to transmit data to a recipient user who uses the second communication device 904 and the recipient computer system 905.
  • the sending computer system 901 is a personal computer, or a network computer, connected to the Internet.
  • the destination computer system 905 is another personal computer, or another network computer, connected to the Internet.
  • the first and third networks can be confused or different.
  • the first and third networks can thus be the Internet.
  • the second and fourth networks may, in particular be non-wired networks.
  • the first communication device 902 is a mobile phone or a pager.
  • the second communication device 904 is a mobile phone or a page.
  • the second and fourth networks can be confused or different.
  • the first and second communication medium are different.
  • the third and the fourth communication medium are different.
  • the commumcation devices 901 and 904 have unique addresses sm the second and the fourth communication network, respectively.
  • the receiving computer system 903 is a network server connected to network interfaces to communicate s the first to fourth networks.
  • the receiving computer system 903 is a network server connected to network interfaces to communicate s the first to fourth networks.
  • the receiving computer system 903 stores in memory: the private key and the public key of each user capable of implementing the method described in FIG. 9,
  • the address of the recipient user s the fourth network is obtained from the sending user, as in the case illustrated in FIG. 9.
  • the start-up and initialization operations and the shutdown operations of the computer systems and of the communication devices are not shown in FIG. 9.
  • the transmitting computer system 901 connects to the receiving computer system 903, via the first communication medium.
  • the receiving computer system 903 transmits to the transmitting computer system 901 a program making it possible to determine a condensa of data to be transmitted.
  • the transmitting computer system 901 transmits to the receiving computer system 903, on the first communication medium: data to be transmitted to the destination computer system 905, a condensate of the data to be transmitted determined with the program transmitted during operation 909, - an identifier of a user of the sending computer system 901 or an identifier of the sending computer system 901, and an identifier of the recipient computer system 905 and an address of the second means of communication 904.
  • the receiving computer system 903 matches said identifier with a private key of the user of the sending computer system 901.
  • the receiving computer system 903 generates a trace of the data to be transmitted.
  • the trace is representative of the domies to be transmitted.
  • said trace is representative of a condensate of said data to be transmitted and of the private key kept by the receiving computer system 903.
  • said trace is obtained by an operation of signing the condensate by the private key of the user of the transmitting computer system 901.
  • said trace is linked to said data and any subsequent modification of said data is detectable.
  • the source of said data is thus authenticated by the user's private key.
  • the identifier of the user of the transmitting computer system 901 is matched with the same address of the communication device 902 on the second commumcation medium.
  • a transmission operation 915 of part of said trace at least part of the trace determined by operation 913 is transmitted by the receiving computer system 903 to the first communication device 902.
  • the transmission operation 915 comprises in the count of the truncation operation 916 in the coms of which the trace determined during the operation 913 is truncated and the result of said truncation is transmitted to the first communication device 902.
  • said part of the trace is received by the transmitting computer system 901.
  • the first communication device 902 displays said trace on a display screen and the user of the first communication device 902 types said trace sm mi keyboard of the emitting computer system 901.
  • the emitting user dictates said part of the trace which is recognized by a voice recognition system or the emitting user supplies said part of the trace to the emitting computer system 901 through any user interface.
  • said trace part is transmitted from the transmitting computer system 901 to the receiving computer system 903.
  • the receiving computer system checks the correspondence of the part of the trace received by the receiving computer system 903 with the trace generated by the receiving computer system 903.
  • the correspondence is, in the example of the Figure 9, an equality between the transmitted trace and the received trace. If there is no match, the system Computing receiver indicates to the sending user that it has not been authenticated, by means of the first communication medium or by means of the second communication medium and invites the sending user to start again the operations illustrated in FIG. 9. If there is a match, on the basis of a matching operation 920, the receiving computer system 903 matches said domies with a public key of the sending user.
  • the receiving computer system 903 transmits a message, for example an electronic mail, to the recipient user inviting him to connect via the third communication medium to the receiving computer system 903.
  • a message for example an electronic mail
  • an identifier of the emitting user or of the computer system 901 is transmitted in said message.
  • the recipient user makes the connection between the recipient computer system 905 and the receiving computer system 903.
  • the receiving computer system 903 During an operation for generating confidential information 923, the receiving computer system 903 generates confidential information. During a transmission operation 924, the receiving device 903 transmits said confidential information to the second communication device 904, via the second communication medium. In exemplary embodiments, an identifier of the sending user is transmitted with said confidential information.
  • said confidential information is received by the recipient computer system 905.
  • the second communication device 904 displays said confidential information on a display screen and the user of the second communication device 904 types said confidential information on a keyboard of the recipient computer system 905.
  • the recipient user dictates said confidential information which is recognized by a voice recognition system or the recipient user provides said confidential information to the recipient computer system 905 via any user interface.
  • said confidential information is transmitted from the recipient computer system 905 to the receiver computer system 903.
  • the receiving computer system 903 verifies the correspondence between the confidential information transmitted by the receiving computer system 903 and the confidential information received by the receiving computer system
  • the receiving computer device 903 indicates to the recipient user that it has not been authenticated, by means of the third or fourth communication medium and invites him to start again operations 922 and following.
  • the receiving computer system 903 transmits to the recipient computer system 905 the data to be transmitted.
  • the computer system 903 transmits jointly to the data to be transmitted: - a public key of the user transmits to the recipient computer system 905, the trace of said data to be transmitted calculated during the operation, and - a program making it possible to determine said condensate of said data.
  • the recipient computer system determines the condensate of said data to be transmitted calculated at the coms of operation 913 and uses the public key received at the coms of operation 928 to determine the condensate of said data which was used to generate the trace transmitted during operation 928.
  • the recipient user assumes that it is the transmitting user who transmitted the data to be transmitted and that these data have not been modified since they were transmitted by the transmitting user.
  • the operations presented in FIGS. 6, 7 or 8 and the operations presented in FIG. 9 are combined in such a way that, in these variants, a disposable key is used for the transmission of data from one computer system to another. and a trace which depends on the data to be transmitted and, possibly on a private key of the sending user, is implemented.
  • the user or client identifies himself, on the first communication medium, for example the Internet, by providing a certificate, for example conforms to the PKI public key infrastructure, and said certificate includes the unique terminal address of said user on the second communication medium, for example a user's mobile phone number.
  • the unique address on the second communication medium is encrypted with a public key in such a way that only certain authorized organizations or certain certification authorities can decrypt said unique address.
  • the certificate which comprises said unique address sm the second communication medium points to, that is to say identifies or comprises, another certificate, for example confo ⁇ ne to the key infrastructure public PKI which does not include said unique address.
  • the signature by the retransmission of a confidential seal or of a condensate causes the joint emission of a key, for example in conformity to the PKI public key infrastructure.

Landscapes

  • Business, Economics & Management (AREA)
  • Engineering & Computer Science (AREA)
  • Accounting & Taxation (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Theoretical Computer Science (AREA)
  • General Business, Economics & Management (AREA)
  • Strategic Management (AREA)
  • Computer Security & Cryptography (AREA)
  • Finance (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Development Economics (AREA)
  • Economics (AREA)
  • Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)

Abstract

La présente invention concerne un procédé et dispositif de paiement électronique qui comporte une opération d'ouverture d'une session de communication entre un premier terminal d'utilisateur et un serveur marchand, sur un premier support de communication, tel qu'Internet. Durant ladite session de communication, le terminal utilisateur constitue un certificat de paiement à usage unique. L'utilisateur reçoit, sur un deuxième terminal, tel qu'un téléphone mobile, une information confidentielle telle qu'un mot de passe et le transmet sur le premier support. La correspondance entre l'information transmise au deuxième terminal et celle transmise par le premier terminal est vérifiée et, s'il y a correspondance, le paiement est validé.

Description

PROCEDE ET DISPOSITIF DE PAIEMENT ELECTRONIQUE
La présente invention c jncerne un procédé et un dispositif de paiement électronique.
Les sites Internet qui proposent des fournitures ou des prestations payantes demandent souvent des paiements par carte de paiement. Cependant, les utilisateurs savent que si le numéro de leur carte de paiement est copié avec la date d'expiration, des paiements peuvent être effectués avec le compte attaché à cette carte sans leur accord. Ces utilisateurs sont donc très réticents à utiliser un moyen de paiement aussi peu protégé.
De leur côté, les sites marchands savent que les clients peuvent annuler, ou "répudier" les paiements fait avec les cartes de paiement parce qu'ils ne signent pas le paiement. Du fait de sa nature ouverte, Internet a augmenter les besoins de sécurité de transmission de données. En effet, l'architecture même de l'hiternet le rend particulièrement vulnérable : le protocole IP, totalement décentralisé, fait circuler les datagrammes, ou "paquets" sans qu'ils soient protégés. Les adresses IP elles-mêmes, gérées par les DNS (Domain Name Servers pour serveurs de noms de domaines), ne sont pas à l'abri d'actions de malveillance. Les systèmes d'exploitation ont des failles de sécurité. D'où une liste impressionnante de menaces :
- écoute de paquets ou "sniffing"; substitution de paquets ou "spoofing"; - piratage de DNS; déni de service; intrusions; et
- dissémination de programmes malveillants, viras et chevaux de Troie. Chacun des aspects de la présente invention vise à remédier à certains de ces inconvénients. A cet effet, la présente invention propose d'effectuer un paiement sur un premier réseau de communication en mettant en œuvre un numéro de moyen de paiement à usage unique transmis ou validé en mettant en oeuvre un deuxième réseau de communication, préférentiellement sécurisé et comportant des adresses uniques de terminaux, par exemple un réseau de téléphonie mobile, deux sessions de communication étant simultanément ouvertes sur les deux réseaux de communication. Ainsi, même si ce moyen de paiement est recopié, la copie est inutilisable, parce que le moyen de paiement est à usage unique, c'est-à-dire qu'il ne peut pas être utilisé deux fois. De plus, le moyen de paiement ne peut être volé sans disposer simultanément de deux terminaux reliés simultanément aux deux réseaux de communication.
Selon un aspect, la présente invention vise un procédé de paiement comportant une opération d'ouverture d'une session de communication entre un premier terminal d'utilisateur et un serveur de site marchand, sur un premier support de communication, caractérisé en ce qu'il comporte, durant ladite session de communication :
- une opération de transmission par le terminal utilisateur d'une information d'identification de l'utilisateur, - une opération de transmission à un serveur de paiement de l'information d'identification de l'utilisateur,
- une opération de constitution par ledit terminal utilisateur d'un certificat de paiement à usage unique,
- une opération de transmission par le serveur de paiement d'une information confidentielle à un deuxième terminal utilisateur, par intermédiaire d'un deuxième support de communication sur lequel chaque adresse est attribuée à au plus un terminal utilisateur,
- une opération de transmission par le premier terminal de ladite information confidentielle ; - une opération de vérification, par le serveur de paiement, de correspondance de l'information confidentielle reçue de la part du premier terminal sur le premier réseau de communication avec l'information confidentielle transmise au deuxième terminal utilisateur et,
- en cas de correspondance, une opération de validation de paiement.
Selon un aspect de la présente invention, le paiement est effectué par l'intermédiaire d'une session de communication avec un serveur de paiement, sur le premier réseau de communication, session pendant laquelle le deuxième réseau de communication est utilisé pour authentifier le payeur en lui transmettant une information confidentielle sur le deuxième réseau, qu'il retransmet sur le premier réseau. En cas d'authentification, le serveur de paiement transmet une information de paiement au payé afin que la transaction soit effectuée. Les inventeurs ont déterminé qu'il y avait un besoin pour à la fois authentifier un client qui effectue un paiement, et lui permettre de ne pas transmettre un numéro de carte de paiement, tout en mettant en oeuvre les moyens connus pour payer avec tout moyen de paiement. En effet, cela évite de modifier les systèmes utilisés par les sites, tout en leur garantissant une authentification des clients et une sécurité des moyens de paiement.
Selon un aspect de la présente invention, pendant une session de communication entre un payeur (client) et un payé (commerçant ou marchand) le paiement est effectué en transmettant sur le deuxième réseau de communication à adresse unique, un numéro de moyen de paiement que l'utilisateur transmet au payé et que le payé utilise pour obtenir le paiement, de la même manière qu'un numéro de carte de paiement embossée.
Dans ce mode de réalisation, la simultanéité de la session de communication entre le terminal utilisateur et le serveur du site marchand, sur le premier réseau de communication et les opérations de paiement assure une protection sécurité accrue car la session sur le premier réseau ne peut être modifiée par un tiers.
Dans des modes de réalisation particuliers, le moyen de paiement à usage unique est transmis au client puis le client est authentifié pour valider l'utilisation du moyen de paiement à usage unique.
Dans des modes de réalisation particuliers, le client est authentifié puis un moyen de paiement à usage unique lui est transmis.
Dans des modes de réalisation particuliers, l'utilisation du moyen de paiement à usage unique authentifie le client. Dans chacun de ces modes de réalisation, le client est protégé car le moyen de paiement à usage unique ne peut être réutilisé par un tiers, en relation avec le compte bancaire ou de crédit du client. Le site est aussi protégé car le paiement est signé, ainsi le client est authentifié fortement et il ne peut donc pas répudier le paiement. On observe que le terme "moyen de paiement à usage unique" recouvre les cas où un numéro est pris, par exemple aléatoirement, dans un ensemble de numéros de moyens de paiement réservés à la mise en oeuvre du présent procédé. Ce terme recouvre aussi le cas où le moyen de paiement peut être réutilisé pendant un nombre de paiement prédéterminé, jusqu'à un montant prédéterminé ou pendant une durée prédéterminée. Cependant, préférentiellement, le moyen de paiement à usage unique ne peut servir que pour une transaction correspondant à une session de communication en cours entre le terminal de l'utilisateur et le serveur du site marchand.
Dans un mode de réalisation particulier, chaque moyen de paiement à usage unique est affiché sur un écran de terminal d'accès à Internet. La présente invention vise une interface graphique de paiement qui comporte l'affichage d'un moyen de paiement à usage unique dont l'utilisateur est authentifié pour valider l'utilisation de ce moyen de paiement.
La présente invention vise aussi un moyen de paiement à usage unique auquel est associée une authentification effectuée conformément aux moyens exposés dans la demande de brevet FR 97 13825 déposée le 4 novembre 1997. Exposés succinctement, ces moyens comportent la transmission d'une information confidentielle sur un support de communication, typiquement un réseau de téléphonie ou de transmission de messages alphanumériques sans fil, la saisie de cette information confidentielle par l'utilisateur sur le terminal d'accès à Internet et la transmission de l'information confidentielle par Internet pour authentifier l'utilisateur.
La présente invention vise aussi à résoudre le problème de la multiplication des clés d'encryption et des risques qui en découlent. En cryptologie, une clé est insérée au moment du chiffrement des données afin d'assurer la confidentialité de celles-ci. Les différentes normes de sécurité disponibles, pour le courrier électronique, pour les sessions de communication du web (SSL ou Secure Socket Layer pour couche de sécurité), pour le protocole IP lui-même (IPsec), mettent en oeuvre tout l'arsenal des méthodes modernes : authentification et signature, échange de clé conventionnelle, chiffrement symétrique. Des centaines de millions de clés RSA ont ainsi été produites.
Il se pose alors de nouveaux problèmes : comment gérer ces clés ? Comme le note Jacques Stern, Directeur du Département Informatique de l'Ecole Normale Supérieure "il est illusoire d'utiliser un chiffrement RSA en laissant traîner ses clés secrètes sur un disque dur mal protégé contre les intrusions" (Dans un article publié dans "Le Monde" daté du 12 septembre 2000). En outre se pose la question de lier une clé publique RSA à son propriétaire légitime. La présente invention vise, selon un aspect, un procédé de certification, caractérisé en ce qu'il comporte : une opération de transmission de données depuis un système informatique émetteur à un système informatique récepteur, sur un premier support de communication, une opération de génération d'une trace desdites données représentatives desdites données, par le système informatique récepteur, une opération de transmission d'une partie de ladite trace à un dispositif de communication, sur un deuxième support de communication différent du premier support de Communication, - une opération de réception de ladite partie de trace par le système mformatique émetteur, une opération de transmission de ladite partie trace depuis le système informatique émetteur au système informatique récepteur, et une opération de vérification de la correspondance de la partie de trace reçue par le système mformatique récepteur avec la trace générée par le système mformatique récepteur. Grâce à ces dispositions, la partie de trace est liée auxdites données et peut servir à détecter une modification ultérieure desdites données.
Selon des caractéristiques particulières du procédé tel que succinctement exposé ci-dessus, ladite trace est représentative d'un condensât desdites domiées. Grâce à ces dispositions, la partie de trace permet de détecter toute modification ultérieure desdites données.
Selon des caractéristiques particulières, le procédé tel que succinctement exposé ci-dessus comporte une opération de transmission d'un identifiant d'un utilisateur du système informatique émetteur. Grâce à ces dispositions, une authentification de l'utilisateur du système mformatique émetteur ou une signature électronique peuvent être effectuées.
Selon des caractéristiques particulières, le procédé tel que succinctement exposé ci-dessus comporte une opération de mise en correspondance dudit identifiant avec une adresse du dispositif de communication sur le deuxième support de communication. Grâce à ces dispositions, l'adresse du dispositif de communication est une adresse qui correspond à l'utilisateur du système informatique émetteur.
Selon des caractéristiques particulières du procédé tel que succinctement exposé ci-dessus, ladite trace est représentative d'une clé privée conservée par le système informatique récepteur. Grâce à ces dispositions, le système mformatique récepteur effectue une signature desdites données.
Selon des caractéristiques particulières, le procédé tel que succinctement exposé ci-dessus, comporte une opération de mise en correspondance dudit identifiant avec ladite clé privée. Grâce à ces dispositions, le système informatique récepteur effectue une signature desdites données au nom de l'utilisateur du système informatique émetteur.
Selon des caractéristiques particulières, le procédé tel que succinctement exposé ci-dessus, comporte une opération de troncature de ladite trace, et en ce que au cours de l'opération de transmission d'au moins une partie de ladite trace, le résultat de ladite troncature est transmis. Grâce à ces dispositions, la partie de ladite trace comporte moins de symboles que ladite trace.
Selon des caractéristiques particulières du procédé tel que succinctement exposé ci-dessus, le premier support de communication est l'Internet. Grâce à ces dispositions, les données peuvent être transmises depuis n'importe quel système informatique relié à l'Internet.
Selon des caractéristiques particulières du procédé tel que succinctement exposé ci-dessus, le deuxième support de communication est un réseau sans fil. Grâce à ces dispositions, l'authentification de l'utilisateur du système informatique émetteur peut être effectuée en tout lieu.
Selon des caractéristiques particulières du procédé tel que succinctement exposé ci-dessus, au cours de l'opération de transmission desdites données, un identifiant d'un système informatique destinataire est transmis, ledit procédé comportant une opération de transmission desdites données depuis le système informatique récepteur à un système informatique destinataire. Grâce à ces dispositions, le système informatique récepteur peut servir d'intermédiaire dans une transmission entre le système informatique émetteur et le système informatique destinataire. Il peut, en outre, assurer des fonctions de datage, de notarisation ou de certification de remise en main propre au destinataire desdites données.
Selon des caractéristiques particulières, le procédé tel que succinctement exposé ci-dessus comporte une opération de mise en correspondance desdites données avec une clé publique et en ce que au cours de l'opération de transmission desdites données audit système informatique destinataire, ladite clé publique est transmise. Grâce à ces dispositions, Le destinataire desdites données peut vérifier l'identité de l'émetteur desdites données, par la mise en oeuvre de la clé publique.
Selon des caractéristiques particulières, le procédé tel que succinctement exposé ci-dessus comporte une opération de génération d'une information confidentielle par le système informatique récepteur et une opération de transmission à un deuxième dispositif de communication d'une information confidentielle à une dispositif de communication sur le deuxième support de communication, par le système informatique récepteur, une opération de réception de ladite information confidentielle par le système informatique récepteur, sur le premier moyen de communication et une opération de vérification de correspondance entre rinformation confidentielle transmise par le système informatique récepteur avec l'information confidentielle reçue par le système informatique récepteur.
Grâce à ces dispositions, le destinataire desdites données est authentifié. La présente invention vise aussi un dispositif de certification, caractérisé en ce qu'il comporte : un moyen de transmission de données depuis un système mformatique émetteur à un système informatique récepteur, sur un premier support de communication, un moyen de génération d'un trace desdites données représentatives desdites données, par le système informatique récepteur,
- un moyen de transmission d'au moins une partie de ladite trace à un dispositif de communication, sur un deuxième support de communication différent du premier support de communication,
- un moyen de réception de ladite trace par le système informatique émetteur,
- un moyen de transmission de ladite trace depuis le système informatique émetteur au système informatique récepteur, et - un moyen de vérification de la correspondance de la trace reçue par le système informatique récepteur et de la trace générée par le système informatique récepteur.
Les caractéristiques particulières et les avantages dudit dispositif correspondent aux caractéristiques particulières et avantages du procédé tels que succinctement exposé ci-dessus.
La présente invention vise, selon un aspect, un procédé de certification, caractérisé en ce qu'il comporte : une opération de réception d'un certificat jetable;
- une opération de chiffrement de données avec ledit certificat jetable; - une opération de transmission des données chiffrées;
- une opération de signature de la transmission desdites domiées; et
- une opération de révocation dudit certificat jetable.
Selon un aspect, la présente invention vise un procédé de certification, caractérisé en ce qu'il comporte : - une première opération de signature de données par un dispositif de fourniture desdites données sans clé privée de l'utilisateur qui fournit lesdites données; et une deuxième opération de signature de données qui substitue à la première signature, une deuxième signature mettant en oeuvre une clé privée dudit utilisateur. Selon un aspect, la présente invention vise un procédé de transmission de données, caractérisé en ce qu'il comporte : une opération de transmission desdites données d'un premier système informatique à un deuxième système mformatique; - une opération de génération d'un sceau ou condensât représentatif desdites données, à partir desdites données;
- une opération de transmission dudit sceau ou condensât par ledit deuxième système informatique;
- une opération d'authentification de l'émetteur desdites données mettant en oeuvre ledit sceau ou condensât ; et
- une opération de vérification dudit sceau ou condensât.
Grâce à chacun de ces aspects, les clés, sceaux, condensâts ou certificats ne sont pas stockés sur un terminal utilisateur, ce qui les protège contre tout risque de vol ou de copie. En outre, la certification peut ainsi être indépendante du terminal mis en oeuvre par le signataire, ce qui rend la signature portable d'un système à un autre.
Selon des caractéristiques particulières de chacun des aspects de la présente invention, au cours de l'opération de génération de certificat jetable, une clé privée est générée. Grâce à ces dispositions, le certificat jetable possède les mêmes caractéristiques de sécurité qu'une clé privée.
Selon des caractéristiques particulières de chacun des aspects de la présente invention, au cours de l'opération de chiffrement, une trace des données à transmettre est déterminée sous la forme connue sous le nom de condensât (en anglais « hash »). Grâce à ces dispositions, toute modification des données à transmettre après la génération de ce condensât est détectable par utilisation du condensât.
Selon des caractéristiques particulières de chacun des aspects de la présente invention, au cours de l'opération de chiffrement, est mise en oeuvre une routine applicative préliminairement téléchargée. Grâce à ces dispositions, la transmission des données à transmettre est protégée par ladite routine. Selon des caractéristiques particulières de chacun des aspects de la présente invention, au cours de l'opération de transmission des données chiffrées, les données à transmettre sont aussi transmises. Grâce à ces dispositions, toute modification des données à transmettre peut être détectée en utilisant les données chiffrées.
Selon des caractéristiques particulières de chacun des aspects de la présente invention, au cours de l'opération de signature, un sceau secret est transmis à un récepteur sur un réseau de télécommunication et saisi par le signataire sur un poste utilisateur qui a transmis les données à transmettre. Grâce à ces dispositions, l'utilisateur du poste utilisateur est authentifié par le fait qu'il dispose simultanément d'un récepteur sur le réseau de télécommunication.
Selon des caractéristiques particulières de chacun des aspects de la présente invention, le procédé comporte une opération de substitution de signature au cours de laquelle une clé privée du signataire est associée aux données à transmettre. Grâce à ces dispositions, la clé privée d'un utilisateur peut être conservée en lieu sur, sur un serveur de sécurité, de telle manière qu'aucun poste utilisateur mis en oeuvre par l'émetteur de données à transmettre n'ait à conserver ladite clé privée. La clé privée est ainsi particulièrement protégée.
Selon des caractéristiques particulières de chacun des aspects de la présente invention, le procédé comporte une opération d'association d'une date et d'une heure aux données transmises. Grâce à ces dispositions, la transmission des données est horodatée. Selon des caractéristiques particulières de chacun des aspects de la présente invention, le procédé comporte une opération de mise en mémoire des données transmises et d'une signature. Grâce à ces dispositions, il y a notarisation des données transmises.
Selon des caractéristiques particulières de chacun des aspects de la présente invention, le certificat jetable est un certificat à durée de vie inférieure à une heure. Grâce à ces dispositions, le même certificat ne peut être utilisé pendant plus qu'une durée prédéterminée.
La présente invention vise aussi un dispositif de certification, caractérisé en ce qu'il comporte : - un moyen de génération d'un certificat jetable;
- un moyen de réception d'un certificat j etable;
- un moyen de chiffrement de données avec ledit certificat jetable;
- un moyen de transmission des données cliiffrées;
- un moyen de signature de la transmission desdites données; et - un moyen de révocation dudit certificat j etable.
Selon un aspect de la présente invention, l'utilisateur ou client s'identifie sur un premier support de communication, par exemple Internet, en fournissant un certificat, par exemple conforme à l'infrastructure à clé publique PKI, et ledit certificat comporte l'adresse unique d'un terminal dudit utilisateur sur un deuxième support de communication, par exemple un numéro de téléphone mobile de l'utilisateur. Selon des caractéristiques particulières, l'adresse unique sur le deuxième support est chiffrée avec une clé publique de telle manière que seuls certains organismes habilités ou certaines autorités de certification peuvent déchiffrer ladite adresse unique. Selon des caractéristiques particulières, le certificat qui comporte ladite adresse unique sur le deuxième support de communication pointe sur, c'est-à-dire identifie ou comporte, un autre certificat, par exemple conforme à l'infrastructure à clé publique PKI, qui ne comporte pas ladite adresse unique.
D'autres avantages, buts et caractéristiques de la présente invention ressortiront de la description qui va suivre faite dans un but explicatif et nullement limitatif en regard du dessin annexé dans lequel : la figure 1 représente des transmissions de messages entre des entités participant à une transaction, selon un premier mode de réalisation, la figure 2 représente des transmissions de messages entre des entités participant à une transaction, selon un second mode de réalisation, la figure 3 représente une image d'un moyen de paiement à usage unique électronique, la figure 4 représente des transmissions de messages entre des entités participant à une transaction, selon un troisième mode de réalisation, la figure 5 représente des transmissions de messages entre des entités participant à une transaction, selon un quatrième mode de réalisation, la figure 6 représente une succession d'opérations effectuées par un terminal utilisateur et un serveur de certification, dans un mode de réalisation particulier de la présente invention, - la figure 7 représente une succession d'opérations effectuées par un terminal utilisateur et le serveur de certification, dans un autre mode de réalisation particulier de la présente invention, la figure 8 représente une succession d'opérations effectuées par un terminal utilisateur et le serveur de certification, dans un autre mode de réalisation particulier de la présente invention, et la figure 9 représente un organigramme de mise en oeuvre d'un autre mode de réalisation de la présente invention. Dans toute la description, le terme "terminal à adresse unique" indique un terminal sur un réseau de communication dont l'adresse ne peut être attribuée à un autre terminal. Par exemple, un téléphone ou un pageur est un terminal à adresse unique.
Dans le schéma de transaction exposé en figure 1, un client est inscrit et possède un compte chez un organisme financier qui met en oeuvre un serveur de paiement adapté à déterminer une adresse de terminal sur un support de communication dans lequel chaque adresse est attribuée à au plus un terminal. Ce compte lui permet d'avoir un fichier de conservation de domiées confidentielles connu sous le nom de « Server Side Wallet ». Dans ce fichier sont stockés les informations relatives au mode de paiement dont le client dispose et notamment relatives à un chéquier électronique.
L'organisme financier est de type 'Issuer', c'est-à-dire émetteur de moyen de paiement, ici à usage uniques, ou il est un intermédiaire ayant passé des accords avec des banques 'Issuer'.
Le marchand a un accord avec l'organisme financier 'Issuer' et il a un compte ouvert qui ne se substitue pas obligatoirement à son compte bancaire classique dans sa banque dite 'Acquirer' car elle reçoit les paiements pour le compte du marchand.
Le marchand présente, sur la page de paiement de son site, une icône proposant à ses clients de payer par intermédiaire d'un moyen de paiement appelé « moyen de paiement à usage unique électronique ». On observe que cette icône peut être celle d'une banque ou d'un type de carte bancaire.
En figure 1, sont représentées les étapes suivantes de mise en œuvre du procédé objet de la présente invention :
1/ Le client décide de payer les articles qu'il a choisis et référencés dans son panier (connu en France sous le nom de "caddy", marque déposée et en anglais sous le nom de "shopping kart"). Nous supposons dans la suite de la description que le client choisit comme mode de paiement le "moyen de paiement à usage unique électronique" proposé par le marchand. On observe que ce choix peut être effectué en sélectionnant une icône de banque ou une icône représentant un carnet de chèques ou un chèque, par exemple.
2/ Le marchand renvoie le traitement de cette demande vers l'organisme financier (ou intermédiaire) qui propose ce service de paiement par moyen de paiement à usage unique électronique. Dans des modes de réalisation exemplaires, le client se retrouve directement sur un site de l'organisme financier. 3/ L'organisme financier demande au client de s'identifier pour accéder au service de chéquier électronique.
4/ Le client s'identifie. Dans des modes de réalisation exemplaires, le client donne son nom, son prénom, un nom d'utilisateur et/ou un mot de passe connu de lui seul.
5/ L'organisme financier présente au client le moyen de paiement à usage unique électronique rempli avec les éléments correspondant à la transaction (nom du marchand, montant, horodatage, ...) pour acceptation et signature électronique. Dans des modes de réalisation exemplaires, le moyen de paiement à usage unique est représenté sous la forme d'un chèque sur l'écran du terminal du client.
6/ Le client valide son acceptation. Dans des modes de réalisation exemplaires, le client sélectionne avec un moyen de pointage tel qu'une souris, un bouton "validation de paiement". 7/ L'organisme financier calcule une signature électronique, ou sceau, c'est-à-dire une séquence de symboles non prédictibles et envoie un certificat lié à la transaction et contenant cette séquence, via un réseau téléphonique mobile, tel que le réseau GSM, sur le mobile du client. Dans des modes de réalisation exemplaires, la signature ou sceau est transmise sous la forme d'un message court connu sous le nom de "SMS".
8/ Le client s'authentifie et signe le moyen de paiement à usage unique électronique en ressaisissant la signature électronique du certificat sur le clavier de son poste de consultation (ou terminal) connecté sur le réseau Internet (principe de la signature électronique). 9/ L'organisme financier renvoie la confirmation du paiement au client et au marchand afin que celui-ci livre les produits achetés.
10/ L'organisme financier traite la transaction en transmettant les informations au réseau de compensation bancaire afin que le montant de la transaction soit crédité sur le compte du marchand dans sa banque 'Acquirer'. Selon un mode de réalisation particulier, un utilisateur d'un premier terminal de communication connecté à un réseau de communication, tel qu'un ordinateur personnel connecté à l'Internet, ouvre une session de communication avec un site marchand. Durant la session de communication, le site marchand propose un paiement par moyen de paiement à usage unique électronique et, en cas d'acceptation par le client, le site marchand ou le premier terminal ouvrent une seconde session de communication avec un site fournisseur de moyen de paiement à usage uniques électronique ou le terminal émet un moyen de paiement à usage unique électronique A cet effet, sur une fenêtre du premier terminal, une fenêtre qui représente le moyen de paiement à usage unique comporte un, plusieurs ou, préférentiellement, tous les champs suivants :
- un nom associe au site marchand,
- un montant de paiement, - mi nom associé à l'utilisateur,
- un numéro de compte attribué à l'utilisateur,
- un nom d'organisme payeur,
- un horodatage ("time-stamping" en anglais), et
- mie zone ou l'utilisateur doit fournir ladite information confidentielle. Pour effectuer le paiement, une information confidentielle est communiquée à l'utilisateur, par intermédiaire d'un deuxième support de communication, tel qu'un réseau de téléphonie mobile ou un réseau de transmission de messages alphanumériques.
L'utilisateur saisi alors l'information confidentielle sur le premier terminal et le premier terminal transmet cette information confidentielle au site marchand.
Après vérification de correspondance de l'information confidentielle reçue de la part du premier terminal sur le premier réseau de communication avec l'information confidentielle transmise au deuxième terminal utilisateur, le paiement est validé. Préférentiellement, le procédé comporte une opération de transmission, par le site marchand, d'une demande d'émission du certificat de paiement à un site tiers. Préférentiellement, le site tiers transmet un montant disponible sur un compte attribué audit utilisateur. Préférentiellement, le procédé comporte une opération d'affectation d'un certificat d'intégrité à l'ensemble constitué du moyen de paiement à usage unique et de l'information confidentielle saisie par l'utilisateur.
Dans le mode de réalisation particulier illustré en figure 2, un client accède, par l'intermédiaire d'un terminal 100 et d'un réseau mformatique 110, par exemple Internet, à un site marchand 120, hébergé par un serveur de réseau 130 (opération 105). Le client s'identifie en donnant ses noms, prénoms et adresse ou par la transmission, par le terminal 100 d'un certificat unique délivré au client, par exemple un certificat lié à l'infrastructure à clé publique PKI. Pour payer, on suppose dans la suite de la description de la figure 2 que le client sélectionne une option de paiement par moyen de paiement à usage unique électronique proposée par le site marchand 120 (opération 115). On observe que le site marchand 120 peut ne proposer que cette option, car, à la différence des paiements par carte bancaire sans signature, le client ne peut pas répudier un paiement fait avec signature ou authentification. Le serveur de réseau 130 transfert alors le client sur un site de paiement
140 hébergé par un serveur de réseau 150, ou serveur de paiement (opération 125). Dans des modes de réalisation exemplaires préférentiels, le serveur de réseau 130 du site marchand 120 transmet au serveur de réseau 150 du site de paiement 140 de l'information représentative de l'identité du marchand, de références bancaires du marchand, de l'identité du client, d'un certificat unique délivré au client conformément à l'infrastructure à clé publique PKI, du montant de la transaction, de l'horodatage et/ou des biens ou services objets de la transaction (opération 135). Dans des modes de réalisation exemplaires, le client fournit tout ou partie de ces informations au serveur 150 par l'intermédiaire du terminal 100, par exemple par transmission d'un certificat unique délivré au client conformément à l'infrastructure à clé publique PKI ou par saisie au clavier (opération 136).
Le serveur de paiement 150 détermine si le paiement peut être autorisé, par exemple en fonction de l'identité du client, du montant du paiement, d'un état d'un compte financier ou bancaire du client, selon des procédures connues (opération 137). Si le paiement peut être autorisé, le serveur 150 du site de paiement 140 transmet une information , par exemple une image, représentative d'un moyen de paiement à usage unique électronique, par exemple une image de chèque, au terminal 100 du client (opération 145). Dans des modes de réalisation exemplaires, ce moyen de paiement à usage unique électronique est déjà partiellement ou complètement pré-rempli, avec toute ou partie de l'information transmise au cours de l'opération 135 (opération 155).
Le client valide ou non le paiement en sélectionnant, ou non, un bouton de validation lié à l'information reçue par le terminal 100 au cours de l'opération 145 (opération 165). Lorsque le client valide le paiement, le serveur de réseau 150 du site de paiement 140 transmet à un serveur de signature 160 une information identifiant le client (opération 175). Dans des modes de réalisation exemplaires, le serveur 150 transmet au serveur de signature de l'information relative au paiement, par exemple l'objet du paiement, le montant du paiement, l'horodatage et/ou le nom du marchand. Le serveur de signature 160 recherche dans une base de domiées ou dans une table de correspondance, une adresse unique d'un terminal de télécommunication 170 lié au client, par exemple un numéro de téléphone mobile sur un réseau de téléphonie mobile (opération 185). Le serveur de signature 160 détermine alors un sceau à usage unique, sous la forme d'une séquence de symboles (opération 186). Dans des modes de réalisation exemplaires, le sceau dépend d'au moins un élément de la transaction, par exemple, le montant, l'identité du marchand, l'identité du client, un certificat unique délivré au client, l'horodatage et/ou l'objet de la transaction. Par exemple, le sceau est déterminé comme une fonction mathématique (par exemple un "hash" ou condensât) de tout ou partie de ces éléments. Préférentiellement, le sceau dépend de l'identité du client et/ou d'un certificat unique délivré au client (par exemple lié à l'infrastructure PKI pour "public Key Infrastructure" ou infrastructure à clé publique). Le serveur de signature 160 transmet au terminal de télécommunication
170 le sceau à usage umque (opération 187). Dans des modes de réalisation exemplaires, le serveur de signature 160 transmet au terminal de télécommunication 170 au moins un élément de la transaction, par exemple, le montant, l'identité du marchand, l'identité du client, l'horodatage et/ou l'objet de la transaction en plus du sceau (opération 188).
Pour valider le paiement, le client lit le sceau sur un écran du terminal 170 ou écoute la séquence de symbole dictée par un serveur vocal sur un haut- parleur du terminal 170 puis saisit le sceau sur le terminal 100, par exemple au clavier ou par dictée vocale (opération 189). Dans des variantes, le client connecte le terminal 170 au terminal 100 pour que la transmission du sceau ait lieu automatiquement.
Le sceau est transmis par le terminal 100 au serveur de réseau 150 (opération 191). Le serveur 150 transmet le sceau au serveur de signature 160 (opération 192). Le serveur de signature vérifie le sceau (opération 193) et, en cas de correspondance entre le sceau émis au cours de l'opération 187 et le sceau reçu au cours de l'opération 192, le serveur de signature 160 transmet une information de validation de signature au serveur 150 (opération 194). Le serveur 150 transmet une information de validation de paiement au serveur de réseau 130 (opération 195). Le serveur de signature invalide le sceau pour tout autre paiement (opération 196).
En cas d'absence de correspondance entre le sceau émis au cours de l'opération 187 et le sceau reçu au cours de l'opération 192, le serveur de signature 160 transmet une information de défaut de signature au serveur 150 (opération 197) et le serveur 150 informe le client du défaut de signature et lui redemande de fournir le sceau (opération 198) et les opération 191 et suivantes se répètent. Après trois échecs, c'est-à-dire trois opérations 197, le serveur de signature invalide le sceau et le serveur de paiement 150 transmet une information d'absence de paiement au serveur 130.
Bien que dans la description de la figure 2, les serveurs 130, 150 et 160 aient été représentés comme séparés, dans des modes de réalisation exemplaires, au moins deux des serveurs 130, 150 et 160 peuvent être confondus.
Préférentiellement, les opérations 125 et suivantes ont toutes lieu au cours de la même session de communication entre le terminal 100 et le serveur 150. Préférentiellement, cette session de communication est sécurisée, par exemple encryptée selon le standard d'encryption SSL.
En figure 3 est représenté une image d'un moyen de paiement à usage unique électronique, telle qu'elle peut être affichée sur un écran 19 d'un terminal accessible à un client. Cette image 20 ressemble à celle d'un chèque comportant des zones d'information : une zone 21 indiquant des coordonnées de l'organisme émetteur, une zone 22 indiquant des coordonnées du client, une zone 23 indiquant le montant du paiement, en chiffres, - une zone 24 indiquant le montant du paiement, en lettres, une zone 25 indiquant un numéro de moyen de paiement, une zone 26 indiquait des coordonnées du marchand, éventuellement, mie zone de références 27 où est indiqué l'objet de la transaction, - une zone 28 de signature, qui prend ici la forme d'un bouton
"valider le paiement et signer", et une zone d'horodatage 29, comprenant une date et, éventuellement, une heure de transaction. Tout ou partie des zones 21 à 27 et 29 sont remplies automatiquement en fonction d'informations fournies par un serveur de site marchand et/ou un serveur de paiement, afin que le client n'ait qu'à vérifier les informations portées par le moyen de paiement à usage unique électronique et à valider le paiement en cliquant d'abord sur le bouton "valider le paiement et signer", puis en saisissant un sceau qu'il reçoit sur un deuxième support de communication à adresses uniques, par exemple une réseau de téléphonie mobile.
Préférentiellement, l'image du moyen de paiement à usage unique est automatiquement conservée en mémoire non volatile du terminal du client.
Selon un aspect de la présente invention, un moyen de paiement à usage unique électronique est associé à un récapitulatif d'éléments de transaction comportant au moins le montant de la transaction, et, préférentiellement, une identification du marchand.
Dans le mode de réalisation particulier illustré en figure 4, un terminal de client 200 accède par l'intermédiaire d'un premier réseau de communication 210, par exemple Internet, à un serveur de site marchand 220 (opération 205). Préférentiellement, la communication entre le terminal 200 et le serveur
220 passe en mode de communication sécurisée, par exemple encryptée (opération 207) avant que l'utilisateur n'entre dans une zone de paiement du site marchand.
Le terminal 200 fournit au serveur 220, un identifiant de l'utilisateur du terminal 200, par exemple ses noms, prénoms et adresse, un nom d'abomié avec ou sans mot de passe, un cookie, fichier placé par le site marchand sur le terminal 200 (opération 209) ou un certificat unique délivré à l'utilisateur du terminal 200 conformément à l'infrastructure à clé publique PKI.
Le client déclenche les opérations de paiement en sélectionnant une fonction de paiement sur une page dudit site, par exemple an cliquant sur un bouton (opération 211). Tout en conservant, jusqu'à la fin des opérations de paiement, la session de communication ouverte avec le terminal 200 relié au premier moyen de communication 210, le serveur 220 du site marchand fournit, par exemple sur le premier réseau de communication, une identification du client à un serveur de paiement 230, préférentiellement avec un identifiant du site marchant, et un montant de paiement (opération 213). Le serveur de paiement 230 détermine une adresse sur le deuxième réseau de communication 240, préférentiellement à adresses uniques, par exemple un réseau téléphonique, par exemple mobile (opération 215). Le serveur de paiement 230 détermine un numéro de moyen de paiement à usage unique (opération 217) dont il conserve en mémoire (opération 219) la relation avec un compte 250 du client, par exemple un compte de carte de crédit ou un compte bancaire. Dans des modes de réalisation exemplaires, le numéro de moyen de paiement à usage unique dépend de l'identité du client et/ou d'éléments de la transaction, par exemple le montant, l'horodatage ou l'identité du marchand.
Dans des modes de réalisation exemplaires, le numéro de moyen de paiement à usage unique est pris parmi un ensemble de numéros similaires à des numéros de carte de paiement embossées. Le serveur de paiement 230 détermine si le paiement est autorisé, par exemple en fonction du montant du paiement et d'information d'autorisation de paiement associées au compte 250 (opération 221). Le serveur de paiement 230 transmet le numéro de moyen de paiement à usage unique à un terminal 260 relié au deuxième réseau de communication 240 qui possède ladite adresse sur le deuxième réseau de communication, par exemple par le biais d'un message court (opération 223). Eventuellement, le serveur de paiement 230 détermine une durée maximale de validité du numéro de moyen de paiement à usage unique (opération 225). Eventuellement, le serveur de paiement transmet au terminal 260 sur le deuxième réseau de communication 240, le montant du paiement et/ou un identifiant du site marchand (opération 227). Le terminal 260 reçoit l'information transmise et retransmet au terminal 200, par un lien électronique (opération 229) entre les terminaux 260 et 200 ou, préférentiellement, par recopie manuelle effectuée par l'utilisateur des terminaux 200 et 260 dans une fenêtre d'une page du site marchand prévue à cet effet (opération 231), le numéro de paiement à usage unique. Le terminal 200 transmet au serveur 220 le numéro de moyen de paiement à usage unique (opération 233).
Dans des modes de réalisation exemplaires, le numéro de paiement à usage unique prend la forme d'un numéro de carte de paiement de type connu et l'utilisateur utilise le numéro de paiement à usage unique comme un numéro de carte de paiement embossé sur une carte de paiement en matière plastique.
Le serveur 220 du site marchand transmet le numéro de moyen de paiement à usage unique au serveur de paiement 230 (opération 235). Le serveur du site marchand 220 transmet, éventuellement, un montant de paiement, un identifiant du site marchand et/ou un identifiant du compte du marchand, en particulier celles de ces informations qui n'ont pas encore été transmises au serveur de paiement 230 (opération 237). Le serveur de paiement 230 vérifie la correspondance entre le numéro de moyen de paiement à usage unique que le serveur de paiement 230 a transmis à ladite adresse sur le deuxième réseau de communication et le numéro de moyen de paiement à usage unique que le serveur de paiement reçoit du serveur du site marchand (opération 239). En cas de correspondance et si le numéro de moyen de paiement à usage unique est encore valide (test 241), le serveur de paiement 230 émet une information d'autorisation de paiement au serveur 220 du site marchand (opération 243), provoque le paiement, éventuellement différé, depuis le compte du client vers le compte du marchand, en modifiant des données conservées en mémoire en relation avec le compte du client (opération 245) et en provoquant la modification de données conservées en mémoire en relation avec un compte du marchand (opération 247), et invalide une nouvelle utilisation du même numéro de moyen de paiement à usage unique en relation avec les comptes bancaires ou de crédit de l'utilisateur (opération 249).
Dans un mode de réalisation particulier illustré en figure 5, un terminal utilisateur 300 client accède à un serveur de paiement 310 sur un premier réseau de communication 320, par exemple Internet (opération 303) et demande à un serveur de paiement 310 un numéro de moyen de paiement à usage unique, au cours d'une session de communication sur un premier réseau de communication 320 (opération 305). Le terminal 300 transmet au serveur de paiement 310 un identifiant de l'utilisateur, par exemple ses noms, prénoms et adresse, un nom d'abonné avec ou sans mot de passe, un cookie, fichier placé par le serveur de paiement 310 sur le terminal 300 ou un certificat unique délivré au client conformément à l'infrastructure à clé publique PKI (opération 307).
Le serveur de paiement 310 détermine une adresse sur un deuxième réseau de communication 330, préférentiellement à adresses uniques, par exemple un réseau téléphonique, par exemple mobile (opération 309). Le serveur de paiement 310 détermine aussi un numéro de moyen de paiement à usage unique dont le moyen de paiement conserve en mémoire 340 la relation avec un compte du client, par exemple un compte de carte de crédit ou un compte bancaire (opération 311). Le serveur de paiement 310 détermine une durée d'utilisation du moyen de paiement à usage unique (opération 313). Dans des modes de réalisation exemplaires, le numéro de moyen de paiement est pris parmi un ensemble de numéros disponibles similaires à des numéros de cartes de paiement embossées.
Le serveur de paiement 310 transmet le numéro de moyen de paiement à usage unique à un terminal 350 relié au deuxième réseau de communication 330 qui possède ladite adresse sur le deuxième réseau de communication 330, par exemple par le biais d'un message court (opération 315). L'utilisateur reçoit l'information transmise (opération 317) et utilise ce moyen de paiement à usage unique pour payer un achat sur un site marchand 360 (opération 319), de manière co me en soi, par exemple en l'introduisant dans des espaces prévus pour recevoir des numéros de cartes bancaires. Le serveur du site marchand 360 transmet le numéro de moyen de paiement à usage unique au serveur de paiement 310 avec un montant de paiement, un identifiant du site marchand et/ou un identifiant du compte du marchand (opération 321). Le serveur de paiement 310 vérifie la correspondance entre le numéro de moyen de paiement à usage unique qu'il a transmis au terminal 350 et le numéro de moyen de paiement à usage unique que le serveur de paiement 310 reçoit du serveur du site marchand 360 (test 323) et, en cas de correspondance, vérifie que la durée maximale d'utilisation du moyen de paiement à usage unique n'est pas dépassée (opération 325) et détermine si le paiement est autorisé, par exemple en fonction du montant du paiement à effectuer et d'information associée au compte du client 370 (test 327). Si le paiement est autorisé et si la durée d'utilisation n'est pas dépassée, le serveur de paiement 310 émet une information d'autorisation de paiement au serveur 360 du site marchand (opération 329), provoque le paiement, éventuellement différé, depuis le compte du client vers le compte du marchand, en modifiant des données conservées en mémoire en relation avec le compte du client (opération 331) et en provoquant la modification de données conservées en mémoire en relation avec un compte du marchand 380 (opération 333), et invalide une nouvelle utilisation du même numéro de moyen de paiement à usage unique en relation avec les comptes bancaires ou de crédit de l'utilisateur (opération 335).
En figure 6 sont représentés un poste utilisateur ou système informatique émetteur 600, une application Internet 610, une salle blanche 620, une mémoire de stockage 630, un deuxième réseau de communication 640 et un récepteur 650 sur le deuxième réseau de communication 640. La salle blanche 620 comporte une protection pare-feu (en anglais "firewall") 660, un serveur de sécurité 670 et un générateur de certificats 680. Les opérations effectuées dans le mode de réalisation particulier illustré en figure 6 sont représentées dans des rectangles et numérotées de 501 à 512. L'application Internet 610 et la salle blanche 620 sont conjointement appelé système informatique récepteur.
Le poste utilisateur 600 est, par exemple, un ordinateur personnel (PC), un ordinateur de réseau (NC) ou un assistant numérique personnel (en anglais Personal Digital Assistant ou PDA) ou tout terminal permettant une communication à distance, borne interactive, décodeur T.V., .... Le poste utilisateur 600 est doté d'un logiciel de communication à distance pour mettre en oeuvre l'application Internet 610, conjointement avec le serveur de sécurité 670. Ce logiciel de communication à distance peut être un logiciel de navigation ou un logiciel de courrier électronique, par exemple.
L'application Internet 610 permet la communication entre le poste utilisateur 600 et le serveur de sécurité 670 et la transmission de domiées depuis le poste utilisateur 600 vers la mémoire de stockage 630, par exemple par l'intermédiaire du serveur de sécurité 670. La salle blanche 620 est un espace protégé contre toute intrusion physique, telle qu'une salle de coffre d'une banque. La mémoire de stockage 630 est une mémoire adaptée à conserver des données pendant une longue période, qui dépasse une année.
Le deuxième réseau de communication 640 est, par exemple, un réseau téléphonique et, encore plus particulièrement un réseau de téléphonie mobile ou de récepteurs alphanumériques communément appelés "pageurs". Le deuxième réseau 640 est appelé "deuxième" par comparaison avec le réseau Internet, que l'on nomme aussi "premier" réseau dans la suite de la présente demande de brevet. Le deuxième réseau 640 est adapté à transmettre une clé, un sceau, un condensât ou un certificat depuis le serveur de sécurité 670 jusqu'au récepteur 650. Le récepteur 650 sur le deuxième réseau 640 peut, selon le type de deuxième réseau 640, être un téléphone mobile, un pageur ou un récepteur quelconque. Le récepteur 650 permet à l'utilisateur du poste utilisateur 600 de prendre comiaissance d'informations transmises par le serveur de sécurité 670. La protection pare-feu 660 est de type matérielle et/ou logicielle et interdit toute intrusion logicielle dans le serveur de sécurité 670. Le serveur de sécurité 670 est un serveur informatique de type connu. Enfin, le générateur de certificats 680 est adapté à générer des certificats jetables, par exemple de type conforme à l'infrastructure à clés publiques PKI, par exemple conforme à la norme X509-V3. Le poste utilisateur 600 et le serveur de sécurité 670 sont conjointement adaptés à mettre en oeuvre les opérations indiquées ci-dessous. Par exemple, le serveur de sécurité 670 est adapté à fournir des routines applicatives ou "applets" au poste utilisateur 600. Au début du processus de certification, on suppose que des données sont à transmettre de manière certifiée et signée depuis le poste utilisateur 600 jusqu'à la mémoire de stockage 630. L'utilisateur du poste utilisateur 600 se connecte au serveur de sécurité 620 pour lancer le processus de certification.
Au cours de l'opération 501, après identification de l'utilisateur au poste utilisateur 600, l'application Internet 610 télécharge une routine applicative certifiée et signée dans le poste utilisateur 600. On observe que la routine applicative en question peut n'être téléchargée que dans le cas où une copie de cette routine n'est pas déjà implantée dans le poste utilisateur 600. Cette caractéristique particulière permet de rendre portable le procédé de certification objet de la présente invention, sans ralentir ce processus dans le cas où l'utilisateur met successivement en oeuvre le même poste utilisateur 600, pour plusieurs certifications de données. Au cours de l'opération 502, le générateur de certificats 680 génère un certificat jetable, par exemple sous la forme d'une clé privée conforme à l'infrastructure à clés publiques PKI, par exemple conforme à la norme X509-V3. Par exemple, le certificat jetable est généré aléatoirement par le générateur 680.
Au cours de l'opération 503, le serveur de sécurité 670 transmet le certificat jetable au poste utilisateur 600. Au cours de l'opération 504, le poste utilisateur 600 met en oeuvre la routine applicative téléchargée au cours de l'opération 501 pour obtenir une trace des domiées à transmettre, appelé condensât (en anglais "hash"), trace qui dépend du certificat jetable généré au cours de l'opération 502 et des domiées à transmettre et qui permet la détection de toute modification ultérieure des données à transmettre.
Au cours de l'opération 505, les domiées à transmettre et le condensât sont téléchargés depuis le poste utilisateur 600 jusqu'à l'application Internet 610. De plus, des coordonnées de chaque destinataire des données à transmettre est transmis par le poste utilisateur 600 à l'application Internet 610. Ces coordonnées peuvent prendre la forme d'adresse de courrier électronique (en anglais "e-mail"), de numéro de téléphone ou de tout autre type d'information permettant de contacter chaque destinataire des données à transmettre. Au cours de l'opération 506, l'intégrité des données à transmettre est vérifiée, en mettant en oeuvre la clé jetable générée au cours de l'opération 502 et le condensât.
On observe qu'à la fin de l'opération 506, une copie des données à transmettre à été faite depuis le poste utilisateur 600 dans l'application Internet 610 et que cette copie est certifiée conforme à l'original grâce à la mise en oeuvre d'une clé jetable. Pour éviter que le certificat jetable soit réutilisé, au cours de l'opération 510, le certificat jetable est révoqué, c'est-à-dire qu'il devient inutilisable pour certifier des données. En variante, le certificat jetable généré au cours de l'opération 502 est un certificat à durée de vie très courte, préférentiellement inférieure à une heure. Dans cette variante, l'opération 510 n'est pas exécutée puisqu'au delà de la durée de vie du certificat jetable, ce certificat n'est pas utilisable pour certifier des données. Les opérations 507 et 508 correspondent à un exemple de signature pouvant être utilisé en combinaison avec les opérations 501 à 506 ci-dessus. Au cours de l'opération 507, un sceau secret est généré et transmis, par l'intermédiaire du deuxième réseau 640, au récepteur 650. L'adresse du récepteur 650 sur le deuxième réseau est déterminée en mettant en correspondance l'identifiant de l'utilisateur transmis au cours de l'opération 501 avec ladite adresse, dans une table de correspondance. Préférentiellement, le sceau secret est calculé sur les éléments de signature du document. Préférentiellement, le sceau secret dépend des données à transmettre, de leur nombre, de leur contenu, de la date et de l'heure de la génération du sceau secret, de la clé privée de l'émetteur des données déterminée en correspondance avec l'identifiant de l'utilisateur transmis au cours de l'opération 501, de l'adresse internet ("adresse IP") du poste utilisateur 600 et/ou d'un numéro de la session Internet au cours de laquelle les données sont transmises. Selon un exemple de mise en oeuvre de l'opération 507, le sceau secret est obtenu par calcul d'un condensât des données à transmettre, par exemple sous la forme d'une séquence de vingt symboles, de chiffrement de ce condensât par la clé privée de l'utilisateur du poste utilisateur 600, et d'extraction d'une partie du résultat de ce chiffrement, par exemple huit symboles sur vingt.
Préférentiellement, au moins une coordonnée d'au moins un destinataire des données à transmettre est transmis avec le sceau secret, au cours de l'opération 507, de telle manière que l'utilisateur émetteur puisse identifier le message qu'il est en train de signer.
Le lecteur pourra se référer à la figure 9 et/ou à la demande de brevet PCT/FR98/02348, incorporée ici par référence, pour mieux connaître des exemples d'étapes mises en oeuvre au cours des opérations 507 et 508. Au cours de l'opération 508, l'utilisateur commun du poste utilisateur 600 et du récepteur 650 saisie le sceau secret et ce sceau secret est transmis au serveur de sécurité 670 où le sceau est vérifié, opération 509.
En variante, les opérations 507 à 509 sont remplacées par une opération de signatme basée sur l'utilisation d'une carte à mémoire ("carte à puce") ou d'une mesure de biométrie ou toute autre moyen réputé fiable d'authentification forte de l'utilisateur.
A la fin de l'opération 508, les données transmises sont donc certifiées intègres et signées par l'utilisateur qui les transmet. L'opération 509 consiste à substituer une signature dite PKI (pour Public Key Infrastructure, soit infrastructure de clés publiques) à la signatme effectuée au cours des opérations
507 et 508.
Au cours de l'opération 509, les domiées transmises sont signées avec la clé privée de l'utilisateur qui les a transmise (dit "signataire" des données). Enfin, au cours de l'opération 511, les données transmises, certifiées et signées par clé privée sont transmises à la mémoire de stockage 630 avec une date et, éventuellement, une heure de telle manière qu'elles sont horodatées, archivées et notarisée. Dans une application de la présente invention à une remise en main propre des données transmises, un destinataire est, à la suite de l'opération 511, averti de la mise à sa disposition des données à transmettre et des opérations similaires aux opérations exposées ci-dessus sont mises en oeuvre pour effectuer une copie certifiée conforme sur le poste utilisateur du destinataire après avoir recueilli de sa part une signature. Par exemple, une signature telle qu'exposée dans la demande de brevet PCT/FR98/02348 peut, de nouveau être mise en oeuvre pour authentifier le destinataire. Un exemple d'une succession d'opérations mises en oeuvre pour cette remise en main propre est donné en figure 7. En figure 7 sont représentés un poste utilisateur destinataire ou système informatique destinataire 700, l'application Internet 610, la salle blanche 620, la mémoire de stockage 630, le deuxième réseau de communication 640 et un récepteur 750 sur le deuxième réseau de communication 640. Les opérations effectuées dans le mode de réalisation particulier illustré en figure 7 sont représentées dans des rectangles et numérotées de 513 à 525. Ces opérations peuvent suivre les opérations 501 à 512 illustrées en figure 6 et effectuées en relation avec un poste utilisateur 600 généralement différent du poste utilisateur 700.
Le poste utilisateur destinataire 700 est, par exemple, un ordinateur personnel (PC), un ordinateur de réseau (NC) ou un assistant numérique personnel (en anglais Personal Digital Assistant ou PDA). Le poste utilisateur destinataire 700 est doté d'un logiciel de communication à distance pour mettre en oeuvre l'application Internet 610, conjointement avec le serveur de sécurité 670. Ce logiciel de communication à distance peut être un logiciel de navigation ou un logiciel de courrier électronique, par exemple. L'application Internet 610 permet la communication entre le poste utilisateur 700 et le serveur de sécurité 670 et la transmission de données depuis le poste utilisateur 700 vers la mémoire de stockage 630, par exemple par l'intermédiaire du serveur de sécurité 670. Le récepteur 750 sur le deuxième réseau 640 peut, selon le type de deuxième réseau 640, être un téléphone mobile, un pageur ou un récepteur quelconque. Le récepteur 750 permet à l'utilisateur du poste utilisateur destinataire 700 de prendre connaissance d'informations transmises par le serveur de sécurité 670. Le poste utilisateur destinataire 700 et le serveur de sécurité 670 sont conjointement adaptés à mettre en oeuvre les opérations indiquées ci-dessous. Par exemple, le serveur de sécurité 670 est adapté à fournir des routines applicatives ou "applets" au poste utilisateur destinataire 700.
Au début du processus de certification, on suppose que des données sont à transmettre de manière certifiée et signée depuis la mémoire de stockage 630 jusqu'au poste utilisateur destinataire 700.
L'utilisateur du poste utilisateur destinataire 700 se connecte initialement au premier réseau, par exemple pour consulter des courriers électroniques. Au cours de l'opération 513, l'application Internet 610 émet à destination du poste utilisateur destinataire 700 un courrier électronique (e- mail) qui indique que de l'infoπnation est mise à disposition de l'utilisateur du poste 700. Dans des modes de réalisation exemplaires, au moins une coordonnée de l'utilisateur émetteur est transmise dans ce courrier électronique pour que le destinataire puisse identifier l'utilisateur émetteur.
Au cours de l'opération 514, l'utilisateur accède à l'application interne 610 en sélectionnant son adresse Internet. Au cours de l'opération 515, l'application Internet 610 télécharge une routine applicative certifiée dans le poste utilisateur destinataire 700. On observe que la routine applicative en question peut n'être téléchargée que dans le cas où une copie de cette routine n'est pas déjà implantée dans le poste utilisateur 700. Cette caractéristique particulière permet de rendre portable le procédé de certification objet de la présente invention, sans ralentir ce processus dans le cas où l'utilisateur met successivement en oeuvre le même poste utilisateur destinataire 700, pour recevoir plusieurs ensembles données. On observe que les routines applicatives téléchargées au cours des opérations 501 et 515 peuvent être identiques pour permettre d'une part la transmission de données vers la mémoire 630 et, d'autre part, pour recevoir des données depuis cette mémoire.
Les opérations 516 et 517 correspondent à un exemple de signature pouvant être utilisé en combinaison avec les opérations 513 à 515 ci-dessus. Au cours de l'opération 516, un sceau secret est généré et transmis, par l'intermédiaire du deuxième réseau 640, au récepteur 750. Préférentiellement, le sceau secret est calculé sur les éléments de signature du document. Préférentiellement, le sceau secret dépend des données à transmettre, de leur nombre, de leur contenu, de la date et de l'heure de la génération du sceau, et ou d'un numéro de la session Internet au cours de laquelle les données sont transmises.
Dans des modes de réalisation exemplaires, au moins une coordonnée de l'utilisateur émetteur des données à transmettre est transmise avec le sceau secret, au cours de l'opération 516, de telle manière que l'utilisateur destinataire puisse identifier l'utilisateur émetteur.
Le lecteur pourra se référer à la demande de brevet PCT/FR98/02348 pour mieux connaître des exemples d'étapes mises en oeuvre au cours des opérations 516 et 517. Au cours de l'opération 517, l'utilisateur commun du poste utilisateur destinataire 700 et du réceptem 750 saisie le sceau secret sur le poste utilisateur destinataire 700 et ce sceau secret est transmis au serveur de sécurité 670 où le sceau est vérifié. A la fin de l'opération 517, les domiées transmises sont donc certifiées intègres et signées par l'utilisateur qui les transmet. En variante, les opérations 516 et 517 sont remplacées par une opération de signature basée sur l'utilisation d'une carte à mémoire ("carte à puce") ou d'une mesure de biométrie.
Au cours de l'opération 518, le générateur de certificats 680 génère un certificat de retrait, par exemple sous la forme d'une clé conforme à l'infrastructure à clés publiques PKI, par exemple conforme à la norme X509- V3. Le certificat de retrait contient la clé publique de l'utilisateur du poste utilisateur 600. Au cours de l'opération 519, le serveur de sécurité 670 transmet le certificat de retrait au poste utilisateur destinataire 700. Au cours de l'opération 520, l'application 610 détermine un condensât des données à transmettre, qui dépend du certificat de retrait généré au cours de l'opération 518 et des données à transmettre et qui permet la détection de toute modification ultérieure des données à transmettre.
Au cours de l'opération 521, les données à transmettre et le condensât sont téléchargés depuis l'application hitemet 610 jusqu'au poste utilisateur destinataire 700. Au cours de l'opération 522, l'intégrité des données à transmettre est vérifiée, en mettant en oeuvre la clé publique contenue dans le certificat de retrait généré au cours de l'opération 518 et le condensât.
On observe qu'à la fin de l'opération 522, mie copie des domiées à transmettre à été faite depuis la mémoire de stockage 630 jusqu'au poste utilisateur destinataire 700 et que cette copie est certifiée conforme à l'original grâce à la mise en oeuvre d'une clé jetable. Au cours de l'opération 523, un accusé de réception d'intégrité est transmis depuis le terminal utilisateur destinataire 700 vers le serveur de sécurité 670. Cet accusé de réception d'intégrité témoigne que les données à transmettre ont été transmises au terminal utilisateur destinataire 700 de manière intègre, c'est à dire que les données à transmettre n'ont pas été modifiées après l'opération 520.
Au cours de l'opération 524, une trace de la transmission des données à l'utilisateur destinataire est certifiée et mémorisée dans la mémoire de stockage 630. Cette date et, éventuellement, une heure est associée aux données transmises et est ainsi horodatées, archivées et notarisée. Au cours de l'opération 525, le serveur de sécurité met à disposition de l'émetteur des données transmises un accusé de réception qui l'informe que les données qu'il à transmise au cours de l'opération 504 ont été reçues par l'un de leur destinataire. On observe qu'un accusé de réception est transmis à l'émetteur des données pour chacun des destinataires des données.
En figure 8 sont représentés le poste utilisateur ou système mformatique émetteur 600, une application Internet 810, la salle blanche 620, la mémoire de stockage 630, le deuxième réseau de communication 640 et le récepteur 650 sur le deuxième réseau de communication 640. Les opérations effectuées dans le mode de réalisation particulier illustré en figure 8 sont représentées dans des rectangles et numérotées de 531 à 542. L'application Internet 810 et la salle blanche 620 sont conjointement appelées système informatique récepteur.
Le poste utilisateur 600 et le serveur de sécurité 670 sont conjointement adaptés à mettre en oeuvre les opérations 531 à 542 indiquées ci-dessous. Au début du processus de certification, on suppose que plusieurs ensembles de données sont à transmettre de manière certifiée et signée depuis le poste utilisateur 600 jusqu'à la mémoire de stockage 630. L'utilisateur du poste utilisateur 600 se connecte au serveur de sécurité 620 pour lancer le processus de certification.
Au cours de l'opération 531, après identification de l'utilisateur du poste utilisateur 600, l'application Internet 810 télécharge une routine applicative certifiée dans le poste utilisateur 600. On observe que la routine applicative en question peut n'être téléchargée que dans le cas où une copie de cette routine n'est pas déjà implantée dans le poste utilisateur 600. Cette caractéristique particulière permet de rendre portable le procédé de certification objet de la présente invention, sans ralentir ce processus dans le cas où l'utilisateur met successivement en oeuvre le même poste utilisateur 600, pour plusieurs certifications de données. Au cours de l'opération 532, le générateur de certificats 680 génère un certificat jetable, par exemple sous la forme d'une clé privée conforme à l'infrastructure à clés publiques PKI, par exemple conforme à la norme X509-V3. Par exemple, le certificat jetable est généré aléatoirement par le générateur 680.
Au coms de l'opération 533, le serveur de sécurité 670 transmet le certificat jetable au poste utilisatem 600. Au coms de l'opération 534, l'utilisateur sélectionne explicitement chacun des ensembles de données à transmettre. Par exemple, l'utilisateur du poste utilisateur 600 sélectionne, un par un, des fichiers à transmettre, chaque fichier constituant un ensemble de données à transmettre. Toujours au coms de l'opération 534, le poste utilisatem 600, met en oeuvre la routine applicative téléchargée au coms de l'opération 531 pour obtenir un condensât de chacun des ensembles de domiées à transmettre, qui dépend du certificat jetable généré au cours de l'opération 532 et des données dudit ensemble. Chaque condensât permet la détection de toute modification ultérieure d'un ensemble de données à transmettre.
Au coms de l'opération 535, les ensembles données à transmettre et les condensât sont téléchargés depuis le poste utilisateur 600 jusqu'à l'application Internet 810. De plus, des coordonnées de chaque destinataire de chaque ensemble de données à transmettre est transmis par le poste utilisatem 600 à l'application Internet 610. Ces coordonnées peuvent prendre la forme d'adresse de courrier électronique (en anglais "e-mail"), de numéro de téléphone ou de tout autre type d'information permettant de contacter chaque destinataire des domiées à transmettre. Au cours de l'opération 536, l'intégrité des ensembles de données à transmettre est vérifiée, en mettant en oeuvre la clé jetable générée au cours de l'opération 532 et les condensât.
On observe qu'à la fin de l'opération 536, une copie des ensembles de domiées à transmettre à été faite depuis le poste utilisateur 600 dans l'application Internet 810 et que cette copie des ensembles de domiées est certifiée conforme à l'original grâce à la mise en oeuvre d'une clé jetable. Pour éviter que le certificat jetable soit réutilisé, au coms de l'opération 540, le certificat jetable est révoqué, c'est-à-dire qu'il devient inutilisable pour certifier des ensembles de domiées.
En variante, le certificat jetable généré au coms de l'opération 532 est un certificat à durée de vie très courte, préférentiellement inférieure à une heure. Dans cette variante, l'opération 510 n'est pas exécutée puisqu'au delà de la durée de vie du certificat jetable, ce certificat n'est pas utilisable pour certifier des données.
Les opérations 537 et 538 correspondent à un exemple de signature pouvant être utilisé en combinaison avec les opérations 531 à 536 ci-dessus. Au coms de l'opération 537, un sceau secret est généré et transmis, par l'intermédiaire du deuxième réseau 640, au réceptem 650. L'adresse du récepteur 650 s le deuxième réseau est déterminée en mettant en correspondance l'identifiant de l'utilisateur transmis au cours de l'opération 531 avec ladite adresse, dans une table de correspondance. Préférentiellement, le sceau secret dépend des domiées à transmettre, de lem nombre, de lem contenu, de la date et de l'heure de la génération du sceau secret, de la clé privée de rémetteur des données déterminée en correspondance avec l'identifiant de l'utilisateur transmis au cours de l'opération 531, de l'adresse internet ("adresse IP") du poste utilisateur 600 et/ou d'un numéro de la session Internet au cours de laquelle les domiées sont transmises. Selon mi exemple de mise en oeuvre de l'opération 537, le sceau secret est obtenu par calcul d'un condensât des données à transmettre, par exemple sous la forme d'une séquence de 20 symboles, de chiffrement de ce condensât par la clé privée de l'utilisateur du poste utilisateur 600 et d'extraction d'une partie du résultat de ce chiffrement. Préférentiellement, au moins une coordonnée d'au moins un destinataire des domiées à transmettre est transmis avec le sceau secret, au cours de l'opération 537, de telle manière que l'utilisateur émetteur puisse identifier les données à transmettre qu'il est en train de signer ou au moins mi destinataire de ces données. Le lecteur pourra se référer à la figure 9 et/ou à la demande de brevet PCT/FR98/02348 pour mieux connaître des exemples d'étapes mises en oeuvre au cours des opérations 537 et 538. Au coms de l'opération 538, l'utilisateur commun du poste utilisatem 600 et du récepteur 650 saisie le sceau secret et ce sceau secret est transmis au serveur de sécurité 670 où le sceau est vérifié, opération 539.
En variante, les opérations 537 à 539 sont remplacées par une opération de signature basée s l'utilisation d'une carte à mémoire ("carte à puce") ou d'une mesure de biométrie. A la fin de l'opération 538, les ensembles de données transmis sont donc certifiées intègres et signées par l'utilisateur qui les transmet. L'opération 539 consiste à substituer une signature dite PKI (pour Public Key mfrastructure, soit infrastructure de clés publiques) à la signature effectuée au coms des opérations 537 et 538. Au coms de l'opération 539, les ensembles de données transmis sont signés avec la clé privée de l'utilisateur qui les a transmise (dit "signataire" des données).
Enfin, au coms de l'opération 541, les ensembles de données transmises, certifiées et signées par clé privée sont transmises à la mémoire de stockage 630 avec une date et, éventuellement, une heure, de telle manière qu'elles sont horodatées, archivées et notarisée.
Dans une application de la présente invention à une remise en main propre des ensembles de données transmises, po chaque ensemble de données à transmettre, un destinataire est, à la suite de l'opération 541, averti de la mise à sa disposition de l'ensemble de doimées à transmettre et des opérations similaires aux opérations exposées ci-dessus sont mises en oeuvre pour effectuer une copie certifiée confoπne sur le poste utilisateur du destinataire après avoir recueilli de sa part une signature. Un exemple d'une succession d'opérations mises en oeuvre pom cette remise en main propre est domié en figure 7. La figure 9 représente un organigramme de mise en oeuvre d'un autre mode de réalisation de la présente invention. Dans la colonne la plus à gauche de la figure 9 sont représentées des opérations concernant un système informatique dit "émetteur" 901 mettant en oeuvre un premier support de communication. Dans la colonne à droite de la colonne la plus à gauche sont représentées des opérations concernant un premier dispositif de communication 902 mettant en oeuvre un deuxième support de communication. Dans la colonne centrale sont représentées des opérations concernant un système informatique 903 dit "récepteur" mettant en oeuvre le premier, le deuxième, un troisième et mi quatrième support de communication. Dans la colonne la plus à droite sont représentées des opérations concernant un système informatique 905 dit "destinataire" mettant en oeuvre le troisième support de communication. Enfin, dans la colonne entre la colonne centrale et la colonne la plus à droite, sont représentées des opérations concernant un deuxième dispositif de communication 904 mettant en oeuvre le quatrième support de communication.
Le système informatique émetteur 901 et le premier dispositif de communication 902 sont utilisés par un utilisatem qui souhaite transmettre des doimées à un utilisatem destinataire qui utilise le deuxième dispositif de communication 904 et le système informatique destinataire 905. Par exemple, le système informatique émetteur 901 est un ordinateur personnel, ou un ordinateur de réseau, connecté au réseau Internet.
Par exemple, le système informatique destinataire 905 est un autre ordinateur personnel, ou un autre ordinateur de réseau, connecté au réseau Internet. Les premier et troisième réseau peuvent être confondus ou différents. Le premier et le troisième réseaux peuvent ainsi être l'Internet.
Les deuxième et quatrième réseaux peuvent, en particulier être des réseaux non filaires. Par exemple, le premier dispositif de communication 902 est un téléphone mobile ou un pageur. Par exemple, le deuxième dispositif de communication 904 est un téléphone mobile ou un page . Les deuxième et quatrième réseaux peuvent être confondus ou différents. En revanche, le premier et le deuxième support de communication sont différent. De plus, le troisième et le quatrième support de communication sont différents. Préférentiellement, les dispositifs de commumcation 901 et 904 possèdent des adresses uniques sm le deuxième et le quatrième réseau de communication, respectivement.
Selon un exemple de réalisation, le système informatique récepteur 903 est un serveur de réseau connecté à des interfaces de réseau pour communiquer s les premier à quatrième réseaux. Dans la suite de la description de la figure
9, on considère que le système informatique récepteur 903 conserve des moyens nécessaires pour obtenir :
- une clé privée et une clé publique d'un utilisateur du système informatique émetteur 901, l'adresse du premier dispositif de communication 902 sur le deuxième support de communication, et - l'adresse du deuxième dispositif de communication 904 sur le quatrième support de communication. Par exemple, le système informatique récepteur 903 conserve en mémoire : la clé privée et la clé publique de chaque utilisatem susceptible de mettre en oeuvre le procédé décrit en figure 9,
- une table de correspondance entre des identifiants d'utilisateurs et des adresses sur le deuxième support de communication, et
- un moyen d'interroger une base de données conservant une table de correspondance entre des identifiants d'utilisatems destinataires et des adresses s le quatrième support de communication.
Selon une variante, l'adresse de l'utilisateur destinataire s le quatrième réseau est obtenue de la part de l'utilisateur émetteur, comme dans le cas illustré en figme 9. Les opérations de démarrage et d'initialisation et les opérations d'arrêt des systèmes informatiques et des dispositifs de communication ne sont pas représentées en figure 9.
Au coms d'une opération 908, le système informatique émettem 901 se connecte au système informatique réceptem 903, par l'intermédiaire du premier support de communication. Au coms d'une opération 909, le système informatique réceptem 903 transmet au système informatique émettem 901 un programme permettant de déterminer un condensa de données à transmettre.
Au cours d'opérations de transmission 910 et 911, le système informatique émettem 901 transmet au système informatique récepteur 903, sur le premier support de communication : des données à transmettre au système informatique destinataire 905, un condensât des doimées à transmettre déterminé avec le programme transmis au cours de l'opération 909, - un identifiant d'un utilisatem du système informatique émetteur 901 ou un identifiant du système informatique émettem 901, et un identifiant du système informatique destinataire 905 et une adresse du deuxième moyen de communication 904. Au coms d'une opération de mise en correspondance 912, le système informatique réceptem 903 met en correspondance ledit identifiant avec une clé privée de l'utilisateur du système informatique émettem 901.
Au cours d'une opération de génération 913, le système informatique récepteur 903 génère une trace des données à transmettre. La trace est représentative des domiées à transmettre. Préférentiellement, ladite trace est représentative d'un condensât desdites données à transmettre et de la clé privée conservée par le système informatique réceptem 903. Par exemple, ladite trace est obtenue par une opération de signature du condensât par la clé privée de l'utilisateur du système informatique émetteur 901. Ainsi, ladite trace est liée audites données et toute modification ultérieure desdites données est détectable. De plus, la source desdites données est ainsi authentifiée par la clé privée de l'utilisateur.
Au coms d'une opération de mise en correspondance 914, l'identifiant de l'utilisateur du système mformatique émetteur 901 est mis en correspondance avec mie adresse du dispositif de communication 902 sm le deuxième support de commumcation.
Au coms d'une opération de transmission 915 d'une partie de ladite trace, au moins une partie de la trace déterminée au coms de l'opération 913 est transmise par le système informatique réceptem 903 au premier dispositif de communication 902. Par exemple, l'opération de transmission 915 comporte au coms de l'opération de troncature 916 au coms de laquelle la trace déterminée au cours de l'opération 913 est tronquée et le résultat de ladite troncature est transmis au premier dispositif de communication 902.
Au cours d'une opération de réception 917, ladite partie de trace est reçue par le système informatique émetteur 901. Par exemple, le premier dispositif de communication 902 affiche ladite trace s un écran de visualisation et l'utilisateur du premier dispositif de communication 902 tape ladite trace sm mi clavier du système informatique émettem 901. Selon des variantes, l'utilisateur émettem dicte ladite partie de trace qui est reconnue par un système de reconnaissance de voix ou l'utilisateur émetteur fournit ladite partie de trace au système informatique émetteur 901 par le biais d'une interface utilisateur quelconque.
Au cours d'une opération de transmission de ladite partie trace 918, ladite partie de trace est transmise depuis le système informatique émettem 901 au système informatique récepteur 903.
Au cours d'une opération de vérification 919, le système informatique réceptem vérifie la correspondance de la partie de trace reçue par le système informatique récepteur 903 avec la trace générée par le système informatique réceptem 903. La correspondance est, dans l'exemple de la figure 9, une égalité entre la trace émise et la trace reçue. S'il n'y a pas correspondance, le système informatique réceptem indique à l'utilisateur émettem qu'il n'a pas été authentifié, par le biais du premier support de communication ou par le biais du deuxième support de communication et invite l'utilisateur émetteur à recommencer les opérations illustrées en figure 9. S'il y a correspondance, au coms d'une opération de mise en correspondance 920, le système mformatique réceptem 903 met en correspondance lesdites domiées avec mie clé publique de l'utilisateur émetteur. Au coms d'une opération de commumcation 921, le système informatique récepteur 903 transmet un message, par exemple un courrier électronique, à l'utilisateur destinataire l'invitant à se connecter par le biais du troisième support de communication au système mformatique réceptem 903. Selon des modes de réalisation exemplaires, un identifiant de l'utilisateur émettem ou du système mformatique 901 est transmis dans ledit message.
Au cours d'une opération de connexion 922, l'utilisateur destinataire effectue la connexion entre le système informatique destinataire 905 et le système informatique réceptem 903.
Au cours d'une opération de génération d'une information confidentielle 923, le système informatique réceptem 903 génère une information confidentielle. Au cours d'une opération de transmission 924, le dispositif récepteur 903 transmet ladite information confidentielle au deuxième dispositif de communication 904, par le biais du deuxième support de communication. Dans des modes de réalisation exemplaires, un identifiant de l'utilisateur émetteur est transmis avec ladite information confidentielle.
Au cours d'une opération de réception 925, ladite information confidentielle est reçue par le système informatique destinataire 905. Par exemple, le deuxième dispositif de communication 904 affiche ladite information confidentielle sm un écran de visualisation et l'utilisateur du deuxième dispositif de communication 904 tape ladite information confidentielle sur un clavier du système informatique destinataire 905. Selon des variantes, l'utilisateur destinataire dicte ladite information confidentielle qui est reconnue par un système de reconnaissance de voix ou l'utilisateur destinataire fournit ladite information confidentielle au système informatique destinataire 905 par le biais d'une interface utilisatem quelconque.
Au cours d'une opération de transmission de ladite information confidentielle 926, ladite information confidentielle est transmise depuis le système informatique destinataire 905 au système informatique récepteur 903.
Au coms d'une opération de vérification de correspondance 927, le système informatique récepteur 903 vérifie la correspondance entre l'infoπnation confidentielle transmise par le système informatique récepteur 903 et l'information confidentielle reçue par le système informatique récepteur
903. S'il n'y a pas correspondance, le dispositif informatique récepteur 903 indique à l'utilisateur destinataire qu'il n'a pas été authentifié, par le biais du troisième ou du quatrième support de communication et l'invite à recommencer les opérations 922 et suivantes. Lorsqu'il y a correspondance, au coms d'une opération de transmission des domiées au système informatique destinataire 928, le système informatique récepteur 903 transmet au système informatique destinataire 905 les domiées à transmettre. Préférentiellement, le système informatique 903 transmet conjointement aux doimées à transmettre : - une clé publique de l'utilisateur émettem au système informatique destinataire 905, la trace desdites données à transmettre calculée au cours de l'opération , et - un programme permettant de déterminer ledit condensât desdites données.
Au coms d'une opération 929, le système informatique destinataire détermine le condensât desdites données à transmettre calculé au coms de l'opération 913 et utilise la clé publique reçue au coms de l'opération 928 pour déterminer le condensât desdites données qui a servi à générer la trace transmise au cours de l'opération 928. Lorsque les deux condensât sont égaux, l'utilisateur destinataire a l'assmance que c'est l'utilisateur émettem qui a transmis les données à transmettre et que ces domiées n'ont pas été modifiées depuis qu'elles ont été transmises par l'utilisateur émettem.
Selon des variantes, les opérations présentées en figmes 6, 7 ou 8 et les opérations présentées en figure 9 sont combinées de telle manière que, dans ces variantes, une clé jetable est utilisée pour la transmission des doimées d'un système informatique à un autre et une trace qui dépend des données à transmettre et, éventuellement d'une clé privée de l'utilisateur émetteur, est mise en oeuvre. Selon un aspect de la présente invention et dans une variante de chacun des modes de réalisation exposés dans la présente description, l'utilisateur ou client s'identifie, sur le premier support de communication, par exemple Internet, en fournissant un certificat, par exemple conforme à l'infrastructure à clés publique PKI, et ledit certificat comporte l'adresse unique d'mi tenninal dudit utilisatem sur le deuxième support de communication, par exemple un numéro de téléphone mobile de l'utilisateur. Dans des modes de réalisation exemplaires de cette variante, l'adresse unique sur le deuxième support de communication est chiffrée avec une clé publique de telle manière que seuls certains organismes habilités ou certaines autorités de certification peuvent déchiffrer ladite adresse unique. Dans des modes de réalisation exemplaires de cette variante, le certificat qui comporte ladite adresse unique sm le deuxième support de communication pointe sur, c'est-à-dire identifie ou comporte, un autre certificat, par exemple confoπne à l'infrastructure à clé publique PKI qui ne comporte pas ladite adresse unique. Selon un aspect de la présente invention et selon une variante de chacun des modes de réalisation exposés ci-dessus, la signature par la retransmission d'un sceau confidentiel ou d'un condensât provoque l'émission conjointe d'mie clé, par exemple conforme à l'infrastructme à clés publiques PKI.
On observe que tous les aspects de la présente invention exposés dans la présente description et, en particulier, en regard des différentes figmes, ainsi que toutes les variantes et les modes de réalisation exemplaires, peuvent être avantageusement combinées.

Claims

REVENDICATIONS
1. Procédé de paiement comportant une opération d'ouverture d'une session de communication entre un premier terminal d'utilisateur et un serveur de site marchand, sur un premier support de communication, caractérisé en ce qu'il comporte, durant ladite session de communication :
- une opération de transmission par le terminal utilisatem d'mie information d'identification de l'utilisateur,
- une opération de transmission à mi serveur de paiement de rinformation d'identification de l'utilisateur,
- mie opération de constitution par ledit tenninal utilisateur d'un certificat de paiement à usage unique,
- une opération de transmission par le serveur de paiement d'une information confidentielle à un deuxième terminal utilisateur, par inteπnédiaire d'un deuxième support de communication sur lequel chaque adresse est attribuée à au plus un terminal utilisatem,
- une opération de transmission par le premier teirmnal de ladite information confidentielle ;
- une opération de vérification, par le serveur de paiement, de correspondance de information confidentielle reçue de la part du premier terminal sm le premier réseau de communication avec information confidentielle transmise au deuxième terminal utilisatem et,
- en cas de correspondance, une opération de validation de paiement.
2. Procédé selon la revendication 1, caractérisé en ce que l'opération de constitution comporte :
- une opération de réception du nom dudit marchand et du montant du paiement; et
- une opération d'affichage d'une fenêtre sur un écran du premier terminal utilisateur, ladite fenêtre comportant l'affichage du nom du site marchand et du montant de paiement.
3. Procédé selon la revendication 2, caractérisé en ce que :
- au cours de l'opération de réception, le nom de l'utilisateur est reçu et
- au cours de l'opération d'affichage, le nom de l'utilisateur est affiché dans ladite fenêtre.
4. Procédé selon l'une quelconque des revendications 2 ou 3, caractérisé en ce que :
- au coms de l'opération de réception, mi nmnéro de compte attribué à l'utilisateur est reçu et
- au coms de l'opération d'affichage, le numéro de compte est affiché dans ladite fenêtre.
5. Procédé selon l'une quelconque des revendications 2 à 4, caractérisé en ce que :
- au cours de l'opération de réception, le nom d'un organisme payeur est reçu et - au coms de l'opération d'affichage, le nom de l'organisme payeur est affiché dans ladite fenêtre.
6. Procédé selon l'une quelconque des revendications 1 à 5, caractérisé en ce qu'il comporte une opération de transmission par le site marchand d'une demande d'émission du certificat de paiement à un site tiers.
7. Procédé selon l'une quelconque des revendications 1 à 6, caractérisé en ce qu'il comporte une opération d'affectation d'un certificat d'intégrité au certificat de paiement et à l'information confidentielle saisie par l'utilisateur.
8. Procédé selon l'une quelconque des revendications 1 à 7, caractérisé en ce qu'il comporte une opération de transmission d'un montant disponible sur un compte attribué audit utilisatem.
EP01928004A 2000-04-19 2001-04-19 Procede et dispositif de paiement electronique Withdrawn EP1192608A2 (fr)

Priority Applications (1)

Application Number Priority Date Filing Date Title
EP02015506A EP1253564A3 (fr) 2000-04-19 2001-04-19 Procédé et dispositif de paiement électronique

Applications Claiming Priority (7)

Application Number Priority Date Filing Date Title
FR0005025 2000-04-19
FR0005025A FR2804264B1 (fr) 2000-04-19 2000-04-19 Procede et dispositif de paiement electronique
FR0013101 2000-10-04
FR0013101A FR2814879B1 (fr) 2000-10-04 2000-10-04 Procede et dispositif de certification
FR0015215 2000-11-24
FR0015215A FR2814880B1 (fr) 2000-10-04 2000-11-24 Circuit d'inversion pour les conventions directe et indirecte d'un module electronique
PCT/FR2001/001205 WO2001056352A2 (fr) 2000-04-19 2001-04-19 Procede et dispositif de paiement electronique

Related Child Applications (1)

Application Number Title Priority Date Filing Date
EP02015506A Division EP1253564A3 (fr) 2000-04-19 2001-04-19 Procédé et dispositif de paiement électronique

Publications (1)

Publication Number Publication Date
EP1192608A2 true EP1192608A2 (fr) 2002-04-03

Family

ID=27248649

Family Applications (2)

Application Number Title Priority Date Filing Date
EP01928004A Withdrawn EP1192608A2 (fr) 2000-04-19 2001-04-19 Procede et dispositif de paiement electronique
EP02015506A Withdrawn EP1253564A3 (fr) 2000-04-19 2001-04-19 Procédé et dispositif de paiement électronique

Family Applications After (1)

Application Number Title Priority Date Filing Date
EP02015506A Withdrawn EP1253564A3 (fr) 2000-04-19 2001-04-19 Procédé et dispositif de paiement électronique

Country Status (5)

Country Link
US (2) US20020138450A1 (fr)
EP (2) EP1192608A2 (fr)
AU (1) AU5488301A (fr)
CA (1) CA2377626A1 (fr)
WO (1) WO2001056352A2 (fr)

Families Citing this family (67)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8706630B2 (en) 1999-08-19 2014-04-22 E2Interactive, Inc. System and method for securely authorizing and distributing stored-value card data
GB2366432A (en) * 2000-09-04 2002-03-06 Sonera Smarttrust Oy Secure electronic payment system
US6873743B2 (en) 2001-03-29 2005-03-29 Fotonation Holdings, Llc Method and apparatus for the automatic real-time detection and correction of red-eye defects in batches of digital images or in handheld appliances
US20030140252A1 (en) * 2001-07-20 2003-07-24 Martin Lafon Authentication process and device
PT1442404E (pt) 2001-09-24 2014-03-06 E2Interactive Inc Sistema e método para fornecer um serviço de comunicação
NL1019440C2 (nl) * 2001-11-27 2003-06-02 Johan Peter Eilander Werkwijze en systeem voor het verrichten van een creditcardtransactie.
GB0201504D0 (en) * 2002-01-23 2002-03-13 Nokia Corp Method of payment
AU2003212867A1 (en) * 2002-01-30 2003-09-02 Mastercard International Incorporated System and method for conducting secure payment transaction
CN1610918A (zh) * 2002-03-20 2005-04-27 松下电器产业株式会社 移动结算系统及装置
FI117181B (fi) * 2003-01-31 2006-07-14 Qitec Technology Group Oy Menetelmä ja järjestelmä käyttäjän identiteetin tunnistamiseksi
US7765153B2 (en) * 2003-06-10 2010-07-27 Kagi, Inc. Method and apparatus for verifying financial account information
DE10343566A1 (de) * 2003-09-19 2005-05-04 Brunet Holding Ag Verfahren zur Abwicklung einer elektronischen Transaktion
US8655309B2 (en) 2003-11-14 2014-02-18 E2Interactive, Inc. Systems and methods for electronic device point-of-sale activation
US20070094129A1 (en) * 2003-12-19 2007-04-26 E2Interactive, Inc. D/B/A E2Interactive, Inc. System and method for adding value to a stored-value account using provider specific pin
FR2864303B1 (fr) * 2003-12-23 2006-04-07 Elca Inf Sa Procede de generation et de validation de billets imprimables a domicile
EP1547805A1 (fr) * 2003-12-23 2005-06-29 Elca Informatique S.A. Procédé de génération et de validation de billets imprimables à domicile
US7693797B2 (en) * 2004-06-21 2010-04-06 Nokia Corporation Transaction and payment system security remote authentication/validation of transactions from a transaction provider
US20060026097A1 (en) * 2004-07-30 2006-02-02 Kagi, Inc. Method and apparatus for verifying a financial instrument
US7472822B2 (en) 2005-03-23 2009-01-06 E2Interactive, Inc. Delivery of value identifiers using short message service (SMS)
EP1752900A1 (fr) 2005-07-18 2007-02-14 Capricorp Limited Sytème de contrôle d'accès au contenu d'un site web
FI20050777L (fi) * 2005-07-21 2007-01-22 Vesa Juvonen Menetelmä ja järjestelmä palvelujen käyttämiseksi tietoliikenneverkossa
US7588181B2 (en) * 2005-09-07 2009-09-15 Ty Shipman Method and apparatus for verifying the legitamacy of a financial instrument
FR2907288B1 (fr) * 2006-02-03 2008-12-19 Att Sa Procede et dispositif d'authentification
WO2007088288A1 (fr) * 2006-02-03 2007-08-09 Advanced Track & Trace Procede et dispositif d'authentification
US8467766B2 (en) 2006-07-06 2013-06-18 Qualcomm Incorporated Methods and systems for managing payment sources in a mobile environment
US8160959B2 (en) 2006-07-06 2012-04-17 Firethorn Mobile, Inc. Methods and systems for payment transactions in a mobile environment
US8510220B2 (en) 2006-07-06 2013-08-13 Qualcomm Incorporated Methods and systems for viewing aggregated payment obligations in a mobile environment
US9911114B2 (en) 2006-07-06 2018-03-06 Qualcomm Incorporated Methods and systems for making a payment via a stored value card in a mobile environment
US8145568B2 (en) 2006-07-06 2012-03-27 Firethorn Mobile, Inc. Methods and systems for indicating a payment in a mobile environment
US8489067B2 (en) 2006-07-06 2013-07-16 Qualcomm Incorporated Methods and systems for distribution of a mobile wallet for a mobile device
US8121945B2 (en) 2006-07-06 2012-02-21 Firethorn Mobile, Inc. Methods and systems for payment method selection by a payee in a mobile environment
US8676672B2 (en) 2007-08-23 2014-03-18 E2Interactive, Inc. Systems and methods for electronic delivery of stored value
US8837465B2 (en) 2008-04-02 2014-09-16 Twilio, Inc. System and method for processing telephony sessions
US8306021B2 (en) 2008-04-02 2012-11-06 Twilio, Inc. System and method for processing telephony sessions
US8468358B2 (en) 2010-11-09 2013-06-18 Veritrix, Inc. Methods for identifying the guarantor of an application
US8006291B2 (en) 2008-05-13 2011-08-23 Veritrix, Inc. Multi-channel multi-factor authentication
US8516562B2 (en) 2008-05-13 2013-08-20 Veritrix, Inc. Multi-channel multi-factor authentication
US8536976B2 (en) 2008-06-11 2013-09-17 Veritrix, Inc. Single-channel multi-factor authentication
US8166297B2 (en) 2008-07-02 2012-04-24 Veritrix, Inc. Systems and methods for controlling access to encrypted data stored on a mobile device
EP2353125A4 (fr) 2008-11-03 2013-06-12 Veritrix Inc Authentification d'utilisateur pour des réseaux sociaux
US20110137740A1 (en) 2009-12-04 2011-06-09 Ashmit Bhattacharya Processing value-ascertainable items
WO2011084648A2 (fr) * 2009-12-16 2011-07-14 Giftango Corporation Systèmes et procédés pour générer un élément de valeur virtuelle pour une campagne promotionnelle
FR2959896B1 (fr) 2010-05-06 2014-03-21 4G Secure Procede d'authentification d'un utilisateur requerant une transaction avec un fournisseur de service
US10068287B2 (en) 2010-06-11 2018-09-04 David A. Nelsen Systems and methods to manage and control use of a virtual card
US20120084200A1 (en) * 2010-10-01 2012-04-05 Michel Triana Systems and methods for completing a financial transaction
US9483786B2 (en) 2011-10-13 2016-11-01 Gift Card Impressions, LLC Gift card ordering system and method
US9031869B2 (en) 2010-10-13 2015-05-12 Gift Card Impressions, LLC Method and system for generating a teaser video associated with a personalized gift
US8474014B2 (en) 2011-08-16 2013-06-25 Veritrix, Inc. Methods for the secure use of one-time passwords
NO334144B1 (no) 2011-09-12 2013-12-16 Aker Subsea As Roterende undervannsinnretning
NL1039134C2 (nl) * 2011-10-26 2013-05-01 Antonius Johannes Clemens Zon Systeem voor het controleren van een legitimatiebewijs.
US10417677B2 (en) 2012-01-30 2019-09-17 Gift Card Impressions, LLC Group video generating system
US8898799B2 (en) 2012-05-09 2014-11-25 Visa Europe Limited Method and system for establishing trust between a service provider and a client of the service provider
US8737962B2 (en) 2012-07-24 2014-05-27 Twilio, Inc. Method and system for preventing illicit use of a telephony platform
US10229561B2 (en) 2012-09-04 2019-03-12 Linq3 Technologies Llc Processing of a user device game-playing transaction based on location
US10943432B2 (en) 2012-09-04 2021-03-09 E2Interactive, Inc. Processing of a game-playing transaction based on location
EP2893504A4 (fr) 2012-09-04 2016-02-24 Linq3 Technologies Llc Systèmes et procédés pour partie de jeu intégrée par utilisation de codes à barres sur des téléphones intelligents et des dispositifs portatifs
US11219288B2 (en) 2013-02-15 2022-01-11 E2Interactive, Inc. Gift card box with slanted tray and slit
US9565911B2 (en) 2013-02-15 2017-02-14 Gift Card Impressions, LLC Gift card presentation devices
US10115268B2 (en) 2013-03-15 2018-10-30 Linq3 Technologies Llc Systems and methods for integrated game play at payment-enabled terminals
US10217107B2 (en) 2013-05-02 2019-02-26 Gift Card Impressions, LLC Stored value card kiosk system and method
GB2515057B (en) 2013-06-12 2016-02-24 Cryptomathic Ltd System and Method for Obtaining a Digital Signature
US9344419B2 (en) 2014-02-27 2016-05-17 K.Y. Trix Ltd. Methods of authenticating users to a site
US9226217B2 (en) 2014-04-17 2015-12-29 Twilio, Inc. System and method for enabling multi-modal communication
US10262346B2 (en) 2014-04-30 2019-04-16 Gift Card Impressions, Inc. System and method for a merchant onsite personalization gifting platform
US10954049B2 (en) 2017-12-12 2021-03-23 E2Interactive, Inc. Viscous liquid vessel for gifting
US12020309B2 (en) 2018-05-18 2024-06-25 E2Interactive, Inc. Augmented reality gifting on a mobile device
CN113034154B (zh) * 2019-09-17 2024-10-15 创新先进技术有限公司 身份认证方法、实现免登授权组件的方法及各自装置

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5883810A (en) * 1997-09-24 1999-03-16 Microsoft Corporation Electronic online commerce card with transactionproxy number for online transactions

Family Cites Families (18)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5005200A (en) * 1988-02-12 1991-04-02 Fischer Addison M Public key/signature cryptosystem with enhanced digital signature certification
JPH03179863A (ja) * 1989-09-04 1991-08-05 Hitachi Ltd 自動取引方法および装置
DE4003386C1 (fr) * 1990-02-05 1991-05-23 Siemens Ag, 1000 Berlin Und 8000 Muenchen, De
US5537475A (en) * 1994-02-01 1996-07-16 Micali; Silvio Efficient digital signature algorithm and use thereof technical field
US5963924A (en) * 1996-04-26 1999-10-05 Verifone, Inc. System, method and article of manufacture for the use of payment instrument holders and payment instruments in network electronic commerce
US5915022A (en) * 1996-05-30 1999-06-22 Robinson; Rodney Aaron Method and apparatus for creating and using an encrypted digital receipt for electronic transactions
US5739512A (en) * 1996-05-30 1998-04-14 Sun Microsystems, Inc. Digital delivery of receipts
US5983208A (en) * 1996-06-17 1999-11-09 Verifone, Inc. System, method and article of manufacture for handling transaction results in a gateway payment architecture utilizing a multichannel, extensible, flexible architecture
US6023509A (en) * 1996-09-30 2000-02-08 Intel Corporation Digital signature purpose encoding
DE19718103A1 (de) * 1997-04-29 1998-06-04 Kim Schmitz Verfahren zur Autorisierung in Datenübertragungssystemen
CN1322334A (zh) * 1997-05-14 2001-11-14 谢浩强 通用电子交易系统及其方法
US6163771A (en) * 1997-08-28 2000-12-19 Walker Digital, Llc Method and device for generating a single-use financial account number
US6000832A (en) * 1997-09-24 1999-12-14 Microsoft Corporation Electronic online commerce card with customer generated transaction proxy number for online transactions
US6125349A (en) * 1997-10-01 2000-09-26 At&T Corp. Method and apparatus using digital credentials and other electronic certificates for electronic transactions
FR2771875B1 (fr) 1997-11-04 2000-04-14 Gilles Jean Antoine Kremer Procede de transmission d'information et serveur informatique le mettant en oeuvre
EP0917119A3 (fr) * 1997-11-12 2001-01-10 Citicorp Development Center, Inc. Portemonnaie électronique réparti basé sur un reseau
EP0950972A2 (fr) * 1997-11-12 1999-10-20 Citicorp Development Center, Inc. Système et méthode pour le stockage sécurisé de données électroniques
US6394341B1 (en) * 1999-08-24 2002-05-28 Nokia Corporation System and method for collecting financial transaction data

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5883810A (en) * 1997-09-24 1999-03-16 Microsoft Corporation Electronic online commerce card with transactionproxy number for online transactions

Also Published As

Publication number Publication date
US20020138450A1 (en) 2002-09-26
AU5488301A (en) 2001-08-14
EP1253564A2 (fr) 2002-10-30
WO2001056352A3 (fr) 2002-01-10
EP1253564A3 (fr) 2002-12-11
US20020165830A1 (en) 2002-11-07
CA2377626A1 (fr) 2001-08-09
WO2001056352A2 (fr) 2001-08-09

Similar Documents

Publication Publication Date Title
EP1192608A2 (fr) Procede et dispositif de paiement electronique
EP2441207B1 (fr) Procédé cryptographique d'authentification anonyme et d'identification séparée d'un utilisateur
EP1282288A1 (fr) Procédé et dispositif d'authentification
WO2011138558A2 (fr) Procede d'authentification d'un utilisateur requerant une transaction avec un fournisseur de service
US20060123465A1 (en) Method and system of authentication on an open network
EP1459479A2 (fr) Systeme cryptographique de signature de groupe
WO2007012584A1 (fr) Procédé de contrôle de transactions sécurisées mettant en oeuvre un dispositif physique unique à bi-clés multiples, dispositif physique, système et programme d'ordinateur correspondants
FR3075534A1 (fr) Dispositif de stockage de cles numeriques pour signer des transactions sur une chaine de blocs
EP2619941A1 (fr) Procede, serveur et systeme d'authentification d'une personne
WO2007012583A1 (fr) Procede de controle de transactions securisees mettant en oeuvre un dispositif physique unique, dispositif physique, systeme, et programme d'ordinateur correspondants
EP3965361B1 (fr) Echange de données entre un client et un dispositif distant, par exemple un module sécurisé
EP1514377A1 (fr) Procede et dispositif d'interface pour echanger de maniere protegee des donnees de contenu en ligne
EP2306668B1 (fr) Système et procédé de transaction sécurisée en ligne
EP2954449B1 (fr) Authentification de signature manuscrite numérisée
EP2056565A1 (fr) Procédé d'authentification d'un utilisateur accédant à un serveur distant à partir d'un ordinateur
EP3673633B1 (fr) Procédé d'authentification d'un utilisateur auprès d'un serveur d'authentification
EP1535253A1 (fr) Procede et systeme de securisation de transmission d'informations sur des reseaux de telecommunication
FR2814880A1 (fr) Circuit d'inversion pour les conventions directe et indirecte d'un module electronique
EP3570518B1 (fr) Systeme et procede d'authentification utilisant un jeton a usage unique de duree limitee
FR2823929A1 (fr) Procede et dispositif d'authentification
EP4099249A1 (fr) Procédé et dispositif de transmission d'un identifiant d'un utilisateur lors d'un paiement électronique réalisépar l utilisateur
FR2823930A1 (fr) Procede et dispositif de certification
FR2814622A1 (fr) Procede de transaction en ligne comportant une pluralite d'etapes d'echanges de messages entre un emetteur, un destinataire et un serveur de validation

Legal Events

Date Code Title Description
PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

17P Request for examination filed

Effective date: 20020108

AK Designated contracting states

Kind code of ref document: A2

Designated state(s): AT BE CH CY DE DK ES FI FR GB GR IE IT LI LU MC NL PT SE TR

AX Request for extension of the european patent

Free format text: AL;LT;LV;MK;RO;SI

17Q First examination report despatched

Effective date: 20020429

GRAP Despatch of communication of intention to grant a patent

Free format text: ORIGINAL CODE: EPIDOSNIGR1

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE APPLICATION IS DEEMED TO BE WITHDRAWN

18D Application deemed to be withdrawn

Effective date: 20050914