WO2002023497A1 - Billet electronique de valeur fiduciaire, protocole de paiement d'achats par commerce electronique et systeme serveur correspondant - Google Patents

Billet electronique de valeur fiduciaire, protocole de paiement d'achats par commerce electronique et systeme serveur correspondant Download PDF

Info

Publication number
WO2002023497A1
WO2002023497A1 PCT/FR2001/001912 FR0101912W WO0223497A1 WO 2002023497 A1 WO2002023497 A1 WO 2002023497A1 FR 0101912 W FR0101912 W FR 0101912W WO 0223497 A1 WO0223497 A1 WO 0223497A1
Authority
WO
WIPO (PCT)
Prior art keywords
electronic
ticket
value
transaction
seller
Prior art date
Application number
PCT/FR2001/001912
Other languages
English (en)
Inventor
François POURBAGHER
Richard Lavaur
Original Assignee
Pourbagher Francois
Richard Lavaur
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
Application filed by Pourbagher Francois, Richard Lavaur filed Critical Pourbagher Francois
Priority to AU2001269192A priority Critical patent/AU2001269192A1/en
Publication of WO2002023497A1 publication Critical patent/WO2002023497A1/fr

Links

Classifications

    • 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
    • G07F7/10—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 together with a coded signal, e.g. in the form of personal identification information, like personal identification number [PIN] or biometric data
    • G07F7/1016—Devices or methods for securing the PIN and other transaction-data, e.g. by encryption
    • 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/22—Payment schemes or models
    • G06Q20/29—Payment schemes or models characterised by micropayments

Definitions

  • the invention relates to an electronic note of fiduciary value, a payment protocol for purchases by electronic commerce, using one or more of these notes, and a corresponding server system.
  • a bank card is generally a microprocessor card, also known as a smart card, to which are assigned, in addition to a confidential four-digit access code, a card number, generally comprising a set of digits, 16 digits most of the time .
  • the card number is, of course, associated with a bank account opened in the name of the holder, this bank account being able to be the subject of deposits or withdrawals by the holder, regardless of the use of the card.
  • the confidential access code allows the card holder, whether or not a bank account holder, to carry out any cash withdrawal operation from, in particular, bank terminals designated by ATM cash dispenser terminals.
  • the communication of the bank card number of the buyer to the seller authorizes the latter to collect the amount of the transaction from the buyer's bank account manager.
  • the object of the present invention is to remedy the aforementioned drawbacks by implementing an electronic payment means in which any reference and any communication of place to the bank account of the owner of this means of payment is deleted.
  • Another object of the present invention is the implementation of an electronic note of fiduciary value comprising attributes substantially comparable to those of a paper currency note.
  • Another object of the present invention is also the implementation of an electronic note of fiduciary value having a level of confidence comparable to or greater than that of a paper money note.
  • Another object of the present invention is, consequently, the implementation of a payment protocol for purchases of products or services by electronic commerce by exchange of electronic tickets in accordance with the object of the present invention, in l absence of any reference or any link to the identity of the buyer or to a bank account of which the latter is the holder.
  • Another object of the present invention is, also, the implementation of a server managing transactions carried out by means of electronic tickets conforming to the object of the present invention, this server, placed under the authority of any entity d 'authorized issue, allowing the implementation of the purchase payment protocol, object of the invention, according to a procedure substantially equivalent to that of the simple exchange of paper money notes.
  • Another object of the present invention is, finally, the implementation of a network access terminal, wide area network and / or local network, allowing the implementation of the payment protocol for purchases of products or services by electronic commerce by exchanging electronic tickets in accordance with the subject of the present invention.
  • the electronic banknote of fiduciary value, object of the present invention is remarkable in that it comprises at least one field representative of a unique number representative of a monetary equivalent established in a monetary unit of account by an entity of 'program.
  • the server system managing transactions carried out by means of electronic banknotes of fiduciary value, object of the present invention, these transactions being carried out between a buyer and a seller, is remarkable in that it comprises at least one module for storing a set of accredited sellers, authorized to conclude one or more transactions by means of these electronic tickets, a module for memorizing lists of electronic tickets issued valid respectively invalid, for a period of emptiness, an access control and authentication module to this server system of any seller accredited for the purpose of collecting electronic banknotes of fiduciary value exchanged during at least one transaction, a module for verifying the validity of the unique number of each electronic ticket exchanged at from at least a list of valid electronic tickets issued and a module notification to the accredited seller of a transaction validation message between the seller and any buyer allowing the seller to send a validation message transaction, upon positive verification of the validity of the unique number of each electronic note of fiduciary value exchanged.
  • FIG. 2a represents, by way of illustration, a specific embodiment of an electronic ticket in accordance with the subject of the present invention in which the field relating to a single number representative of a monetary counter value consists of a numerical value of any length, depending on the unique number representing this monetary equivalent and other fields of the same electronic ticket and / or of external variables;
  • FIG. 2a represents, by way of illustration, a specific embodiment of an electronic ticket in accordance with the subject of the present invention in which the field relating to a single number representative of a monetary counter value consists of a numerical value of any length, depending on the unique number representing this monetary equivalent and other fields of the same electronic ticket and / or of external variables;
  • FIG. 1 represents, by way of illustration, a specific embodiment of an electronic ticket in accordance with the subject of the present invention in which the field relating to a single number representative of a monetary counter value consists of a numerical value of any length, depending on the unique number representing this monetary equivalent and other fields of the same electronic ticket and / or
  • FIG. 2b represents, by way of illustration, another specific embodiment of an electronic ticket conforming to the object of the invention in which the field relating to a single number representative of a monetary counter value, is constituted by a fixed length electronic signature value, this signature value being established from this unique number and from a plurality of other fields of this same electronic ticket and / or of external variables;
  • FIG. 2c represents, by way of illustration, an operating mode making it possible to obtain the encrypted value of any length of the electronic ticket shown in FIG. 2a by encryption from a secret key;
  • FIG. 2d represents, by way of illustration, an operating mode allowing the issuing entity to operate on any electronic ticket of its choice, as shown in FIG.
  • FIG. 2a an authentication operation of non-repudiation thanks to an operation decryption from the secret key used during encryption
  • FIG. 2e represents, by way of illustration, an operating mode making it possible to obtain the signature value of fixed length of the electronic ticket represented in FIG. 2b by signature using a signature key
  • FIG. 2f represents, by way of illustration, an operating mode allowing the issuing entity to operate on any electronic ticket of its choice, such as represented in FIG. 2b, an authentication and non-repudiation operation thanks to a decryption operation from a signature verification key, distinct from the signature key
  • FIG. 3a represents, by way of illustration, a block diagram relating to a server managing transactions carried out by means of electronic tickets conforming to the object of the present invention
  • FIG. 3b represents, by way of illustration, a functional flowchart of the manager server object of the invention as shown in FIG. 3a;
  • FIG. 4a represents, by way of illustration, a flow diagram relating to a payment protocol for purchases of products or services by electronic commerce between a client terminal and a seller terminal, in accordance with the object of the present invention;
  • FIG. 4b represents, by way of illustration, an alternative implementation of the payment protocol object of the present invention of FIG. 4a in which a security measure consisting in temporarily inhibiting the subsequent use of electronic tickets, following a first use is introduced;
  • FIG. 4c represents, purely by way of illustration, an alternative implementation of the payment protocol object of the present invention in which a security measure is introduced, following the reception by the client terminal of an acknowledgment message of receipt of validation of the transaction, via the seller terminal, all electronic tickets, medium of the transaction, being deleted in this customer terminal;
  • FIG. 4d represents, by way of illustration, an example of specific implementation of the introduction, by the issuing entity, at the level of the managing server, of a timeout for one or more electronic tickets, '' a transaction, this emptiness period consisting of an invalidation simply internal to the server of the electronic ticket (s), during their period of validity, in the absence of collection of this or these electronic tickets by their holder, this period of On the contrary, emptiness consisting of an internal invalidation at the server level and external to this server of this or these electronic tickets during a period of emptiness much greater than the period of validity of this or these electronic tickets.
  • FIG. 5 represents, by way of illustration, a non-limiting variant of implementation of the protocol, object of the invention in which a procedure for returning money is introduced.
  • FIGS. 1a, 1c, 2a to 2f A more detailed description of an electronic note of fiduciary value in accordance with the object of the present invention will now be given in conjunction with FIGS. 1a, 1c, 2a to 2f.
  • the electronic note of fiduciary value is implemented in the form of a message or an electronic file intended for an exchange between terminals and / or server and, more specifically, as part of a transaction between a client terminal, noted TC, and a seller terminal which may, if necessary, be constituted by a server, noted TV.
  • the latter comprises at least a representative field of a unique number.
  • This unique number is itself representative of a monetary equivalent established in a monetary unit of account by an issuing entity.
  • the field representing the unique number is denoted NU. It can be associated with a monetary equivalent field, denoted CVM and with a monetary unit of account field, denoted UMC.
  • CVM monetary equivalent field
  • UMC monetary unit of account field
  • the NU field representative of a unique number
  • the number of alphanumeric characters in this set of alphanumeric characters can advantageously be a function of the monetary equivalent CVM attributed to the corresponding unique NU numbers.
  • a note whose monetary equivalent, that is to say the face value, is established at 50 F comprises a unique number NU comprising twelve alphanumeric characters
  • a ticket with a face value of 100 FF may advantageously comprise a unique number comprising 15 alphanumeric characters and an electronic ticket with a face value 500 F may advantageously include a unique number NU comprising 18 alphanumeric characters.
  • the electronic ticket, object of the present invention can be provided with various auxiliary fields which will be explained later in the description.
  • the electronic ticket which is the subject of the present invention can be implemented from a unique NU number constituted by a set of alphanumeric characters comprising at least a determined number of digits (a digit indicates a number or a letter) depending on the monetary equivalent attributed to the unique monetary number. These digits being representative of a single number linked to the aforementioned monetary equivalent.
  • a determined number of alphanumeric characters less than the number of digits can be planned. One or more alphanumeric characters being inserted between two digits.
  • FIG. 1a an electronic ticket with a monetary value CVM equal to 50 has been shown for a monetary unit of account UMC expressed by a code such as the code BF for French francs for example.
  • the unique NU number consisting of a series of alphanumeric characters: 8, 9A, 254, 1B6, P44 for example.
  • a note of 50 F for example is represented by a series of twelve characters plus one or more auxiliary fields specifying the monetary unit of account, ie the currency, as will be described later in the description.
  • the unique NU number formed by the twelve alphanumeric characters is made up of nine digits and three letters.
  • the three letters or alphanumeric characters being chosen from the twenty-six letters of the European alphabet or, where appropriate, the 256 ASCII characters for example.
  • Alphanumeric characters can be placed randomly at locations of random position between two successive digits of the determined number depending on the monetary equivalent attributed to the unique number. The aforementioned nine digits already provide a billion possibilities in choosing a specific unique number assigned to the corresponding monetary equivalent.
  • the alphanumeric characters allow for 17,576 different combinations and, due to the random location of the above characters between two successive digits, a factor of 1,320 additional combinations due to the placement of the aforementioned alphanumeric characters in the aforementioned series of digits.
  • any other monetary unit of account UMC can be used according to the authorization received by the national or regional authorities controlling the issue of fiduciary securities.
  • the first example of an electronic ticket represented in FIG. 1b repeats the example given in FIG. 1a for a note with a face value of 50 F.
  • the second example of an electronic ticket represented in FIG. 1b corresponding to that of an electronic ticket with a face value 100 F for example.
  • the unique number NU can comprise 15 alphanumeric characters, that is to say 12 digits and 03 alphanumeric characters for example.
  • the unique number NU is written:
  • the issuing entity therefore has the possibility of issuing in monetary unit of account 47,982,480 times one trillion X 100 monetary units of account that is, French francs in the example shown in the second example in Figure 1b.
  • the issuing entity can choose a valid digit corresponding to the unique number NU represented in the second example of FIG. 1b from which the issuing entity could emit 100,000,000,000,000 (one hundred thousand billion) units UMC account money, i.e. francs in the example used.
  • a counterfeiter on the other hand, must make 47,000,000 combinations to find the corresponding combination.
  • the third example in FIG. 1b includes a unique number NU represented by:
  • the issuing entity has, for example, a random choice algorithm between one of the above combinations and the facial value allocated to the selected combination makes it possible to ensure the one-to-one correspondence between one of the combinations, function of the determined number of digits of the number of alphanumeric characters and of the relative position of these latter with respect to the digits and the face value or monetary equivalent attributed to this combination.
  • the aforementioned algorithm is preferably a non-linear algorithm which, thanks to a random drawing, makes it possible to ensure the aforementioned one-to-one mapping.
  • the table below indicates the issuing capacities for the issuing entity expressed for each face value, ie each CVM monetary equivalent in number of maximum notes that can be issued for a number of alphanumeric characters. in parentheses and in available virtual money supply as shown below:
  • the face value of each virtual ticket is expressed in monetary unit of UMC account.
  • this monetary unit of account being capable, of course, of being issued and of corresponding to any monetary unit of account such as the franc, dollar, euro or other legal monetary unit of account.
  • the last column represents the probability of discovery of the combination for a counterfeiter for example, taking into account the indications given in connection with FIGS. 1a and 1b. This probability is noted Prc / f.
  • an electronic note of fiduciary value in accordance with the object of the present invention comprising, of course, the fields previously described in connection with FIGS.
  • auxiliary field denoted EE representative of the issuing entity, this field being noted EE and being deemed to correspond to an identification code of a bank or any company authorized to play the role of an issuing entity, as well as a field representative representative of the host country of this sending entity.
  • EE auxiliary field
  • the nonlimiting example corresponds to a bank in France, BNP, the country being France, denoted FR.
  • the electronic note of fiduciary value, object of the present invention may comprise, in a particularly advantageous manner, in addition, an auxiliary field representative of the period of validity of the aforementioned electronic ticket.
  • This field is noted DV in the figure le. It can include a value of date of issue of the electronic ticket by the issuing entity, value denoted X and a value Y of date of end of validity of the ticket electronics considered.
  • the X and Y values can be conventionally expressed in years YY, month MM, day DD, hour HH, minute mn and second ss.
  • the period of validity of the latter can be varied as a function of the face value, that is to say of the monetary counter value CVM allocated to each of these.
  • the period of validity DV can be established at two months for example;
  • the validity period DV can be established at one month;
  • the validity period DV can be reduced to 3 days for example.
  • each electronic ticket in addition to the unique number NU may advantageously include, in plain text, the face value of the ticket or monetary equivalent value CVM, the corresponding monetary unit of account UMC, the issuing entity EE and, of course, the host country of the issuing entity for example.
  • any information that is to say any field of the electronic ticket, object of the invention other than the previously mentioned fields containing information in clear can advantageously consist of an encrypted value or a signature value not accessible to the authorized user and therefore to third parties, to ensure better security of transactions.
  • the field representing the unique number can advantageously be constituted by a value encrypted from a plurality of variables of the electronic ticket comprising at least the unique number NU, the issuing entity EE, the face value, ie the CVM monetary counter value of the ticket as well as, for example, the monetary unit of account UMC.
  • the field relating to the unique encrypted number CNU can represent a variable length, that is to say not constant for each successive electronic ticket as a function of the encryption process used by the issuing entity. .
  • the field relating to the encrypted unique number CNU can have a fixed length, that is to say constant, regardless of the type of ticket issued when a specific encryption process by electronic signature is used. starting from a hash function for example is implemented as will be described later in the description.
  • the face value of the ticket can be constituted by a dedicated value, this dedicated value 550.09 monetary units of account having been established at the request of a user, that is to say a client terminal TC, by the sending entity to carry out a particular transaction whose amount corresponds exactly to the aforementioned dedicated value.
  • the electronic ticket object of the present invention has a degree of security and authenticity comparable to that of a certified cashier's check for the amount corresponding to the value of the aforementioned notes. It is obviously understood that the certification of the value of the tickets, and of course of the electronic ticket carrying the corresponding face value, is given by the issuing entity under the conditions which will be described below in conjunction with FIGS. 2c, 2d and 2e, 2f.
  • an encrypted unique number value CNU of variable length can, for example, be obtained from encryption process from a secret key denoted KS by the technique of disposable mask for example or a steganography technique.
  • KS secret key
  • a step CH1 is carried out in a concatenation of the fields of useful number NU, of issuing entity EE, of monetary equivalent CVM, of monetary unit of account UMC to obtain a string noted $.
  • Concatenation means either the simple concatenation of the aforementioned fields, or a so-called scrambled concatenation according to a specific algorithm for mixing the consecutive characters of each field.
  • At least one external field can be added to the values of the fields of the aforementioned electronic ticket such as for example the electronic address of the creditor terminal, ie of the seller terminal TV in the 'example of transactions previously mentioned in the description, this address being noted ATV for example.
  • an external value field such as the address of the seller terminal ATV makes it possible to diversify the length of the field of the useful number encrypted CNU, this therefore not being of constant length as a function the length of the aforementioned seller terminal address.
  • this read operation making it possible to restore, either by direct reading when the concatenation has been carried out as a direct concatenation, or after descrambling and reading when the concatenation has been preceded by a scrambling operation, to restore the candidate fields NQ *, EE *, CVM *, UMC * and ATV *.
  • These candidate fields being fields obtained from the decryption operation performed in step DCH1.
  • the sending entity then proceeds in a step DCH3 to compare the equality of each candidate field NQ *, EE *, CVM *, UMC * with the original unencrypted fields NU, EE, CVM, UMC respectively.
  • step DCH3 On a positive response to all of the equality comparison operations carried out in step DCH3, the electronic ticket is authenticated and not repudiated by the issuing entity in step DCH5.
  • FIG. 2e a hash function H as well as shown in Figure 2e.
  • the values of the fields of useful numbers NU, issuing entity EE, monetary equivalent CVM, monetary unit of account UMC and, where appropriate, values external to electronic tickets such as the address of the terminal seller ATV and, for example, a random variable VA can be subjected to a concatenation under the conditions as previously mentioned in the description in a step CH3, to obtain a character string denoted $$.
  • the aforementioned concatenation step can be followed by calculation via a hash function of a hash value of fixed normalized length, this operation being noted:
  • S SKPR (N $) to obtain the signed value, ie the CNU field of fixed length.
  • S designates the signature value actually obtained
  • S KPR designates the signature operation from the aforementioned RSA algorithm and from the private key KPR.
  • the issuing entity has the field of useful numbers encrypted CNU corresponding to the aforementioned signature value of fixed length.
  • a step DCH6 it is then able, in a step DCH6, to carry out a verification of the aforementioned signature from a signature verification key denoted KPU, this key constituting an asymmetric key vis-à-vis the calculation key of KPR signature.
  • the DCH6 operation is then followed by a verification operation by equality comparison of the aforementioned candidate fields NU *, EE *, CVM *, UMC * and VA * for example, as well as, if necessary, of the candidate field ATV * to the original field values NU, EE, CVM, if applicable, VA and ATV.
  • step DCH8 On negative response to one of the equality comparisons of the BCH7 test, the sending entity invalidates in step DCH8. On the contrary, on positive response to all the equality comparisons of the stage DCH7, the issuing entity authenticates the electronic ticket considered in step DCH9 without repudiating it.
  • FIGS. 3a and 3b A more detailed description of a server system managing transactions carried out by means of electronic banknotes of fiduciary value, in accordance with the object of the present invention, will now be described in conjunction with FIGS. 3a and 3b.
  • the server system comprises a storage module denoted HDD1 of a set of accredited sellers empowered to conclude one or more transactions by means of electronic notes of fiduciary value described previously in the description.
  • HDD1 a storage module denoted HDD1 of a set of accredited sellers empowered to conclude one or more transactions by means of electronic notes of fiduciary value described previously in the description.
  • the HDD1 storage module advantageously consists of an autonomous hard disk making it possible to store all of the accredited sellers in the form of a list or, if necessary, a table, the list or the table being made up of entities or variables corresponding to the seller's name, the electronic address of his terminal and an accreditation access code for the seller with the ticket management server system electronics as shown in Figure 1 for example.
  • the server system, object of the invention comprises a module denoted HDD2 for memorizing lists of electronic banknotes of fiduciary value issued valid respectively invalid during a period of emptiness.
  • the HDD2 module for > memorizing the lists of aforementioned electronic tickets consists of an independent hard disk making it possible to store these lists in the form of separate lists comprising at least the number of the ticket considered in a directory of tickets issued valid respectively a directory of tickets issued invalid.
  • HDD1 and HDD2 modules in the form of an independent hard disk makes it possible to apply particularly draconian access security conditions with regard to the HDD2 module for memorizing lists of valid and respectively invalid electronic tickets. These particularly severe access conditions may, if necessary, not be applied as strictly to the storage module HDD1.
  • the corresponding access control processes which may correspond to conventional access control processes will not be described in detail in the description for this reason.
  • a simple authentication protocol can consist, upon access of an accredited seller presenting his access code, in a comparison of this access code with respect to the reference access code stored in the module HDD1.
  • the conditions for implementing the access control protocol corresponding to usual conditions taking into account the security rules imposed will not be described in the description for this reason.
  • the server system which is the subject of the present invention also includes a module 2 for verifying the validity of the unique number of each electronic ticket NU of fiduciary value exchanged from at least one list of valid and invalid electronic tickets of fiduciary value.
  • This verification module 2 can consist of a software module type module allowing verification according to the comparison test DCH3 represented in FIG. 2d or DCH7 represented in FIG. 2f, depending on the type of encryption or calculation of signature value. used.
  • the electronic tickets put into circulation do not include an encrypted unique number field, the unique clear number being only transmitted, the operation performed by the module 2 for checking the validity of the unique number of each electronic ticket comes down to the equality comparison of candidate fields received in clear, vis-à-vis the reference fields read on the HDD2 storage module.
  • the server system comprises a module 3 for notifying the accredited seller, that is to say the seller TV terminal, of a transaction validation message between the seller and any buyer.
  • This module 3 allows the seller to send a transaction validation message on positive verification of the validity of the unique number of each electronic note of fiduciary value exchanged, as explained above in the description.
  • the module 2 for verifying the unique number can, as shown in FIG. 3a, also be accompanied by a module 4 for counting the number of errors in verifying the validity of the unique number of each electronic note of fiduciary value exchanged, as well as a module 5 for comparing the number of errors in verifying the validity of the unique number with a threshold value.
  • the modules 4 and 5 for counting the number of errors and for comparing the number of errors with a threshold value are represented by the same element so as not to unnecessarily overload the drawing.
  • this can be contained and stored on the HDD2 module.
  • the comparison module 4.5 makes it possible to control the notification module 3 and allows the sending of a transaction invalidation message to the accredited seller when the number of verification errors is greater than or equal at the threshold value Vseuil considered.
  • the operating mode of the server represented in FIG. 3a will now be described in conjunction with FIG. 3b.
  • the entity issuing that manages and control system transaction manager server performed using electronic tickets, according to the object of the present invention, control via this server two main tasks: it consisting in validating the unique numbers presented and that consisting in carrying out the corresponding banking operations.
  • This accreditation code allows him to identify himself at each connection for request for validation of a transaction, that is to say for a payment, and, if necessary, for request for collection of any corresponding virtual ticket. .
  • the numerical references designate operations carried out by the corresponding number modules in FIG. 3a.
  • the access control module 1 From a BEGINNING step, the, corresponding to a waiting position at a step lb of the access control module 1, the aforementioned access control module 1 communicates the accreditation number and operates in one step verifying access control by reading the list of LVA accredited sellers stored on the HDD1 module.
  • the access control module 1 allows, of course, to check the adequacy between the accreditation code presented and the IP address for example as well as the different identifiers of the Internet network when the latter is used.
  • the access control module ensures the verification, the correspondence between all the parameters of the TV vendor terminal.
  • the access control module 1 communicates the unique numbers of the electronic tickets to the module 2 for verifying the unique NU number.
  • the server actually has the exact list of valid electronic tickets and therefore knows whether a single number is valid or not. This operation carried out in step 2a in FIG. 3b can correspond to that already mentioned in the description in conjunction with FIGS. 2d and 2f.
  • step 2a If in step 2a the unique electronic ticket number is valid, then the module 2 transmits an execution order to the validation message notification module 3 which in step 3a sends a transaction validity message by the intermediary of the connection of the server to the wide area network for example, the server returning to the start position in order to allow, if necessary, to credit the seller's account and to invalidate the corresponding unique number for a period of emptiness, as will be described later in the description.
  • the module 2 initiates a command to the module 4 for counting comparison of the number of errors, which, in operation 4a during detection of three successive errors for example, ensures the disconnection and invalidation of the accreditation as well as, if necessary, the storage of the seller's references in a list of identified fraudsters.
  • the seller must establish a recovery connection which makes it possible to check that the identity of this requester has not been usurped by an unauthorized person and that these errors then come from a customer of this seller, customer identified or not.
  • the seller must then disconnect from his client, identify him before disconnection and, of course, communicate this identification to the managing server system shown in FIG. 3a.
  • the client terminal TC is the holder of electronic banknotes of fiduciary value as described previously in the description.
  • These electronic tickets can be distributed by a specific server or, if necessary, by any means as will be described later in the description.
  • the specific server and the distribution bodies for these electronic tickets are controlled by the issuing entity.
  • Electronic tickets are stored in the client terminal TC.
  • the TV vendor terminal is managed and controlled by an approved vendor, who has been assigned an accreditation number or code allowing the latter access to the managing server, as described above and under the conditions described in connection with the figure. 3a and Figure 3b.
  • an approved vendor who has been assigned an accreditation number or code allowing the latter access to the managing server, as described above and under the conditions described in connection with the figure. 3a and Figure 3b.
  • ST in FIG. 4a relating the server S, the client terminal TC, the vendor terminal TV.
  • This starting situation ST corresponds to that in which, when conducting a purchase-sale agreement for products or services for a determined purchase price PA, the customer has established a set of electronic tickets, each Bi ticket having a face value or monetary equivalent CVMi, the customer having chosen in his tickets a set of notes noted [Bi]) ⁇ k P whose sum of the face value covers the purchase price PA.
  • the payment protocol, object of the invention consists of at least one step A to be transmitted, as transaction payment, from the client terminal TC to the seller TV terminal, a set of electronic tickets, the set [Bj]
  • step A This operation in step A is noted transmission of:
  • step B consisting in transmitting, from the vendor terminal TV to the specific server organization S, the set of electronic tickets, support of the transaction for authentication.
  • This operation is carried out in step B by means of a substep B1 which is followed by a substep B2 of authentication of the unique number ⁇ Ui * candidate for the unique number ⁇ Ui of reference stored in the HDD2 module, as mentioned in connection with Figure 3a. This operation is performed for all Bi tickets.
  • step B is then followed by a step C consisting in transmitting from the specific server organization S to the seller terminal TV a payment validation message noted MVP_V.
  • step C is then advantageously followed by a step D consisting in invalidating at least at the specific server S any electronic ticket Bi of the set of electronic tickets, support of the transaction, during a specific emptiness period.
  • a step D consisting in invalidating at least at the specific server S any electronic ticket Bi of the set of electronic tickets, support of the transaction, during a specific emptiness period.
  • the payment protocol, object of the invention consists of a step J to be transmitted, from the specific server organization S to the terminal TV seller, a message noted MIVP of payment invalidation and non validation of the transaction.
  • FIG. 4b represents an alternative implementation of the protocol which is the subject of the present invention as shown in FIG. 4a.
  • the protocol which is the subject of the invention in this embodiment consists, in a sub-step A2, of inhibiting, at least temporarily at the level of the client terminal TC, the use by this client terminal of any electronic ticket belonging to the set of electronic tickets supporting this transaction.
  • This temporary inhibition can advantageously be maintained at least until the invalidation, at least at the level of the specific server S of any electronic ticket of this set of electronic tickets during the period of emptiness on successful authentication procedure.
  • the temporary inhibition sub-step A2 thus makes it possible to eliminate any risk of successive multiple use of electronic tickets comprising the same unique number for separate transactions, whether this successive use is fraudulent on the part of the user of the TC client terminal or fortuitous.
  • This temporary inhibition can then make it possible to reinforce the security of third parties in the conduct of transactions with respect to a transaction already carried out by the client terminal TC.
  • the operation carried out in sub-step A2 of temporary inhibition may consist in the client terminal TC of causing the memorization of any electronic ticket used for a specific transaction in a list or in an archived file, the read access of which is made conditional on authorization by the server via the vendor terminal, for example, as will be described later in the description.
  • the protocol which is the subject of the present invention may consist of step C consisting in transmitting from the specific server organization S to the approved selling terminal TV a payment validation message, to further carry out an operation E of transmitting from the approved selling terminal TV to the client terminal TC a message of acknowledgment of payment of transaction, then, on receipt of the message of acknowledgment of payment by the client terminal TC, to delete in the customer terminal TC each electronic ticket from the set of electronic tickets noted [BiJÎ ⁇ k P object or medium of the transaction.
  • erasure step F can be carried out on the list of electronic tickets subject to temporary inhibition and stored in a specific file as mentioned previously in the description.
  • the protocol which is the subject of the present invention may consist, following step C, transmission of the specific server member S to the vendor terminal TV of a message of validation of payment, to be carried out, moreover, on the initiative of the approved seller, user of the seller terminal, a step G consisting in transmitting from the seller terminal to the specific server organization S a request for accreditation of a bank account noted REQ_AC_CB, bank account in the name of the authorized seller for an amount corresponding to the amount of the transaction.
  • step G consisting in transmitting from the seller terminal to the specific server organization S a request for accreditation of a bank account noted REQ_AC_CB, bank account in the name of the authorized seller for an amount corresponding to the amount of the transaction.
  • step G On acceptance of the REQ_AC_CB accreditation request, step G is then followed by a step H of return of an acknowledgment of receipt and validation of the request to the approved seller terminal TV, the acknowledgment of receipt being noted MACK_V .
  • Step H is then followed by a step I consisting in erasing, at the level of the approved seller terminal TV, any electronic ticket from this set of electronic tickets, the set [ B i]
  • k + P ' su PP or of a transaction, and have been the subject of a assessed.
  • This specific management mode takes into account a starting situation ST in which the server S has been notified of all the electronic tickets, medium of a transaction, the set [BiJ j I j -, and where a payment validation message MVP_V was transmitted in step C to the vendor terminal TV.
  • FIG. 4d represents a non-limiting mode of implementation of step D of FIG. 4a.
  • This implementation mode takes into account the existence or non-existence of a bank account accreditation request at the initiative of the seller terminal in step G.
  • the server S performs a step of verification Dl consisting in verifying the existence of a request for accreditation REQ_AC_CB of the bank account on the initiative of the seller.
  • a step D4 is carried out by the server consisting in carrying out an internal and external invalidation of any set of tickets, support of a transaction, the set [Bj] - ⁇ k + p , the internal invalidation consisting in the server in assigning an emptying time DVi to each Bi ticket much greater than the validity period DVIDi of each of the corresponding Bi tickets.
  • the duration of DVIDi emptiness can correspond to the duration of two or three years mentioned previously in the description.
  • sub-step B2 then allows the server, in the absence of a request for accreditation of a bank account in the name of the seller, to ensure the exchange of electronic tickets between different sellers or, if necessary, between sellers and third parties during the validity period DVi allocated to each Bi ticket.
  • this exchange step can be carried out independently of the server S during the aforementioned period of validity in step D3, each holder of a ticket whose validity period is then displayed being able to continue the exchange during this period of validity or, if necessary, proceed to a request for accreditation of a bank account according to steps G, H, I described previously in FIG. 4a.
  • the unidentified third party may declare themselves to the server or to any server authorized to carry out a bank account accreditation on behalf of the third-party user.
  • a more detailed description of a non-limiting preferential embodiment of the payment protocol for the purchase of products or services by electronic commerce, which is the subject of the present invention, will now be given in conjunction with FIG. 5.
  • the aforementioned embodiment allows, for a sum of the transmitted face value greater than the purchase price PA, sum intended to effect the settlement of the purchase price, to introduce a procedure for returning money in monetary unit of account.
  • the change-over procedure can be implemented after step A of FIG. 4a.
  • the protocol which is the subject of the present invention consists at least, in a step B'1), of transmitting, from the vendor terminal TV to the specific server organization S, the set [ B j ] - ⁇ k + p virtual tickets, support of the transaction, as well as, of course, the value of the purchase price PA for authentication.
  • the above-mentioned step B'1 is then followed by the authentication step B'2, which can be identical to step B2 in FIG. 4, to constitute step B 'similar to step B of the Figure 4a above.
  • the authentication step B'2 can include, in addition to checking the equality of the candidate fields NUi * and the original fields Ui for each of the banknotes of index i, checking the superiority of the sum of the face value of all the tickets transmitted Bi, support of the transaction at the purchase price PA.
  • Step B ′ on successful authentication procedure and on each ticket of the set of electronic tickets, support of the transaction, being recognized the facial value assigned to it, is followed by a step C consisting in transmitting, from the specific server organization system S to the vendor terminal TV, the payment validation message MVP_V as well as a subset of electronic tickets, set noted [SB j ] j ⁇ TM + n , the sum of the face value of which covers the difference between the amount of face value transmitted and the PA price.
  • each note of the subset of electronic tickets is established in the same monetary unit of account as that of the tickets of the set of electronic tickets transmitted, support of the transaction and that, in this way, the currency can be returned in the corresponding monetary unit of account.
  • Step C is then followed by a step E'1 consisting in transmitting, from the vendor terminal TV to the customer terminal TC, the subset of electronic tickets in the form of money returned and noted
  • each note of the subset of returned money notes can also be assigned, as an auxiliary variable, the address of the client terminal TC in a manner similar to the embodiment already described previously in the description for the terminal transaction. customer, seller terminal.
  • step E'1 of FIG. 5 the step consisting in transmitting from the vendor terminal TV to the client terminal TC the subset of electronic tickets in the form of returned money, represented in step E'1 of FIG. 5, may be followed by an erasure step, denoted E'2, in the vendor terminal TV of each electronic ticket of the subset of electronic tickets in the form of returned money [SBj ⁇ TM + n .
  • steps E'1 and E'2 are deemed to define a step E ', which appears as an improved step with respect to step E in FIG. 4a.
  • Step E ′ is then followed by step F of FIG. 4a consisting in erasing all of the electronic tickets, transaction support [B j ] j ⁇ k + P in the TC client terminal.
  • this acquisition by the aforementioned customer can be carried out for example in three different ways:
  • the virtual tickets which may be in the form of plastic cards comprising at least one registration of one or more virtual tickets.
  • the zone for recording the aforementioned virtual tickets can be constituted by an erasable zone, which allows the customer in question to introduce, for example, virtual tickets into his client terminal TC, the first introduction ensuring the deletion of the aforementioned recording area on the plastic card, for example.
  • the aforementioned customer may also purchase virtual banknotes of fiduciary value in accordance with the subject of the present invention in an automatic teller machine, designated as an ATM.
  • the customer introduces for example a bank card, of the smart card type, into the slot of the ATM machine, chooses to purchase electronic tickets of fiduciary value.
  • the ATM machine connects to the specific server and performs the request to transfer virtual tickets to the customer's bank card.
  • an automatic debit from the bank card account of the corresponding amount is made and a ticket or invoice corresponding to the transaction is issued to the customer. It is understood in particular that the edition of this ticket amounts to printing the receipt of the current withdrawal issued during transactions from bank cards.
  • the customer can also buy tickets on the Internet by connection to the specific server site S, the transaction can also be carried out from a bank card reader terminal for example.
  • the virtual tickets are then directly downloaded to their client terminal TC, a specific management program that can be implemented on the aforementioned TC client terminal.
  • Virtual tickets and the purchase payment protocol, objects of the present invention make it possible, unlike the current electronic payment system by bank card, to make purchase payments very close to making purchase payments from paper money for the following reasons: “first, the owner of virtual tickets is the owner of these tickets under the same conditions as the owner of paper money tickets;” the exchange of virtual tickets between users is carried out in a similar way to the exchange of paper tickets currency, any exchange being carried out completely anonymously for the customer and for any successive customer, only the recipient, that is to say the seller can, if necessary, appear as the holder of the tickets he owns, which is good heard does not add any information on the transaction carried out;

Landscapes

  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Business, Economics & Management (AREA)
  • Accounting & Taxation (AREA)
  • Strategic Management (AREA)
  • General Business, Economics & Management (AREA)
  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)

Abstract

L'invention concerne un billet électronique de valeur fiduciaire comprenant au moins un champ (NU) représentatif d'un numéro unique représentatif d'un numéro unique représentatif d'une contre-valeur monétaire (CVM) établie en une unité monétaire de compte (UMC). Le numéro unique (NU) est fonction de la valeur monétaire du billet électronique. Application du commerce électronique par échange anonyme de billets électroniques.

Description

BILLET ELECTRONIQUE DE VALEUR FIDUCIAIRE, PROTOCOLE DE PAIEMENT D'ACHATS PAR COMMERCE ELECTRONIQUE ET SYSTEME
SERVEUR CORRESPONDANT.
L'invention concerne un billet électronique de valeur fiduciaire, un protocole de paiement d'achats par commerce électronique, au moyen d'un ou plusieurs de ces billets, et un système serveur correspondant.
L'avènement, récent, du commerce électronique laisse présager des perspectives de développement très important du volume des transactions réalisées par commerce électronique, dans un avenir proche.
Un obstacle à un tel développement semble résider dans le manque de souplesse, au moins apparent, du paiement des transactions sur les produits ou services proposés .
A l'heure actuelle, le paiement des transactions précitées est réalisé, de manière quasi exclusive, par 1 ' intermédiaire du système des cartes bancaires . Une carte bancaire est, de manière générale, une carte à microprocesseur, encore désignée carte à puce, à laquelle sont attribués, outre un code confidentiel d'accès à quatre chiffres , un numéro de carte, comportant généralement un ensemble de chiffres, 16 chiffres le plus souvent .
Le numéro de la carte est, bien entendu, associé à un compte bancaire ouvert au nom du titulaire, ce compte bancaire pouvant faire d'ailleurs l'objet de dépôts ou de retraits par le titulaire, indépendamment de l'utilisation de la carte. Le code confidentiel d'accès permet au détenteur de la carte, titulaire ou non du compte bancaire, d'effectuer toute opération de retrait d'argent liquide à partir notamment de terminaux bancaires désignés par terminaux DAB distributeurs automatiques de billets.
Dans un passé récent, le titulaire de la carte, et du compte bancaire, était en outre en mesure de régler directement tout achat de produits ou service par simple mention sur le document d'achat-vente du numéro de carte bancaire et apposition de sa signature personnelle manuscrite, le compte bancaire du titulaire étant débité du montant de la transaction sur la base de ce document .
Une telle pratique tend à disparaître sous l'impulsion de l'avènement du commerce électronique en raison de l'impossibilité matérielle de réaliser l'appositon de la signature personnelle manuscrite sur un document d' achat-vente .
Sous la pression de l'attrait du commerce électronique, les procédures de signature électronique de documents, notamment de documents d' achat-vente, n'étant à l'heure actuelle pas encore totalement admises par les législations nationales ou considérées trop lourdes pour la majorité des transactions, une pratique de règlement des transactions de commerce électronique s'est développée, laquelle consiste pour le titulaire de la carte, acheteur, à communiquer au vendeur son numéro de carte bancaire .
De convention expresse entre le "vendeur et l'acheteur, et bien entendu les organismes bancaires gestionnaires des comptes bancaires de l'acheteur et du vendeur, la communication du numéro de carte bancaire de l'acheteur au vendeur vaut autorisation à ce dernier de mise en recouvrement du montant de la transaction auprès du gestionnaire de compte bancaire de l'acheteur.
Une telle pratique présente toutefois un inconvénient majeur inhérent à la nature humaine.
L'interception du numéro de carte bancaire par des tiers peu scrupuleux, au cours de la communication de ce numéro au vendeur, permet à ces derniers de faire honorer toute transaction fictive, au préjudice du titulaire de la carte bancaire et du compte bancaire qui lui est associé. Alors que dans beaucoup de cas, l'honnêteté et l'intégrité du vendeur ne peuvent être suspectées, certains vendeurs indélicats peuvent toutefois être tentés d'utiliser le numéro de carte bancaire communiqué à d'autres fins que le seul paiement de la transaction réalisée.
Enfin, même en dehors de toute utilisation frauduleuse, la détention même licite par un vendeur d'un certain nombre de numéros de cartes bancaires de clients en vue de ou ayant servi à réaliser des transactions expose ces derniers à des risques de piratage par intrusion sur le site du vendeur.
Les risques d'utilisation frauduleuses d'un numéro de carte bancaire, lien direct avec le compte bancaire du titulaire de celle-ci, communiqué en réseau sont donc réels et non négligeables, même en présence d'une communication sécurisée.
La présente invention a pour objet de remédier aux inconvénients précités par la mise en œuvre d'un moyen de paiement électronique dans lequel toute référence et toute communication de lieu au compte bancaire du possesseur de ce moyen de paiement est supprimé.
En conséquence, un autre objet de la présente invention est la mise en œuvre d'un billet électronique de valeur fiduciaire comportant les attributs sensiblement comparables à ceux d'un billet en papier-monnaie.
Un autre objet de la présente invention est également la mise en œuvre d'un billet électronique de valeur fiduciaire présentant un niveau de confiance comparable ou supérieur à celui d'un billet en papier- monnaie .
Un autre objet de la présente invention est, en conséquence, la mise en œuvre d'un protocole de paiement d'achats de produits ou de services par commerce électronique par échange de billets électroniques conformes à l'objet de la présente invention, en l'absence de toute référence ou de tout lien à l'identité de l'acheteur ou à un compte bancaire dont ce dernier est titulaire . Un autre objet de la présente invention est, également, la mise en œuvre d'un serveur gestionnaire de transactions réalisées au moyen de billets électroniques conformes à l'objet de la présente invention, ce serveur, placé sous l'autorité de toute entité d'émission habilitée, permettant la mise en œuvre du protocole de paiement d'achats, objet de l'invention, selon une procédure sensiblement équivalente à celle du simple échange de billets en papier-monnaie.
Un autre objet de la présente invention est, enfin la mise en œuvre d'un terminal d'accès en réseau, réseau étendu et/ou réseau local, permettant la mise en œuvre du protocole de paiement d'achats de produits ou de services par commerce électronique par échange de billets électroniques conformes à l'objet de la présente invention. Le billet électronique de valeur fiduciaire, objet de la présente invention, est remarquable en ce qu'il comprend au moins un champ représentatif d'un numéro unique représentatif d'une contre-valeur monétaire établie dans une unité monétaire de compte par une entité d'émission.
Le système serveur gestionnaire de transactions réalisées au moyen de billets électroniques de valeur fiduciaire, objet de la présente invention, ces transactions étant réalisées entre un acheteur et un vendeur, est remarquable en ce qu'il comporte au moins un module de mémorisation d'un ensemble de vendeurs accrédités, habilités à conclure une ou plusieurs transactions au moyen de ces billets électroniques, un module de mémorisation de listes de billets électroniques émis valides respectivement invalides, pendant une durée de viduité, un module de contrôle et d' authentification d'accès à ce système serveur de tout vendeur accrédité en vue d'une opération de mise en recouvrement de billets électroniques de valeur fiduciaire échangés au cours d'au moins une transaction, un module de vérification de la validité du numéro unique de chaque billet électronique échangé à partir d'au moins une liste des billets électroniques émis valides et un module de notification au vendeur accrédité d'un message de validation de transaction entre le vendeur et un acheteur quelconque permettant l'envoi au vendeur d'un message de validation de transaction, sur vérification positive de la validité du numéro unique de chaque billet électronique de valeur fiduciaire échangé.
Le protocole de paiement d'achats de produits ou de services par commerce électronique entre un terminal client et un terminal vendeur de produits ou services, ce terminal client étant détenteur de billets électroniques de valeur fiduciaire distribués par un organisme serveur spécifique entité d' émission et mémorisés dans ce terminal client, conformes à l'objet de la présente invention, ce terminal vendeur étant géré et contrôlé par un vendeur agréé auprès de cet organisme serveur spécifique, est remarquable en ce que, lors de la conduite d'un accord d'achat/vente de produits ou services pour un prix déterminé, ce protocole consiste au moins à transmettre, à titre de paiement de transaction du terminal client au terminal vendeur un ensemble de billets électroniques dont la somme de la valeur faciale couvre le prix d'achat déterminé, à transmettre du terminal vendeur à l'organisme serveur spécifique cet ensemble de billets électroniques support de cette transaction pour authentification, et, sur procédure d' authentification réussie, à chaque billet électronique de cet ensemble de billets électroniques support de cette transaction étant reconnue la valeur faciale qui lui est dévolue, à transmettre de l'organisme serveur spécifique au terminal vendeur un message de validation de paiement, à invalider au moins, au niveau de cet organisme serveur spécifique, tout billet électronique de cet ensemble de billets électroniques support de cette transaction pendant un délai de viduité, et, sur procédure d' authentification non réussie, à transmettre de l'organisme serveur spécifique à ce terminal vendeur un message d'invalidation de paiement et de non validation de la transaction.
Le billet électronique de valeur fiduciaire, le système serveur gestionnaire de transactions réalisées au moyen de ces billets électroniques et le protocole de paiement d'achats de produits ou de services par commerce électronique correspondant, objets de la présente invention, trouvent application à toute opération de transaction en ligne par commerce électronique telle que, notamment, paiement d'un prix de cession fixé par contrat, achat d'objets de grande diffusion, souscription d'abonnements ou autres.
Ils seront mieux compris à la lecture de la description et à l'observation des dessins ci-après dans lesquels :
- la figure la, représente, à titre illustratif, un billet électronique de valeur fiduciaire, conforme à l'objet de la présente invention, réalisé sous forme de message électronique ;
- les figures lb et le représentent, à titre illustratif, différentes variantes de réalisation du billet électronique de valeur fiduciaire, objet de l'invention tel que représenté en figure la ; - la figure 2a représente, à titre illustratif, un mode de réalisation spécifique d'un billet électronique conforme à l'objet de la présente invention dans lequel le champ relatif à un numéro unique représentatif d'une contre-valeur monétaire est constitué par une valeur chiffrée de longueur quelconque, en fonction du numéro unique représentatif de cette contre-valeur monétaire et d'autres champs de ce même billet électronique et/ou de variables externes ; la figure 2b représente, à titre illustratif, un autre mode de réalisation spécifique d'un billet électronique conforme à l'objet de l'invention dans lequel le champ relatif à un numéro unique représentatif d'une contre- valeur monétaire, est constitué par une valeur de signature électronique de longueur fixe, cette valeur de signature étant établie à partir de ce numéro unique et d'une pluralité d'autres champs de ce même billet électronique et/ou de variables externes ; la figure 2c représente, à titre illustratif, un mode opératoire permettant l'obtention de la valeur chiffrée de longueur quelconque du billet électronique représenté en figure 2a par chiffrement à partir d'une clé secrète ; la figure 2d représente, à titre illustratif, un mode opératoire permettant à l'entité d'émission d'opérer sur tout billet électronique de son choix, tel que représenté en figure 2a, une opération d' authentification de non répudiation grâce à une opération de déchiffrement à partir de la clé secrète utilisée lors du chiffrement ; la figure 2e représente, à titre illustratif, un mode opératoire permettant l'obtention de la valeur de signature de longueur fixe du billet électronique représenté en figure 2b par signature à partir d'une clé de signature ; -la figure 2f représente, à titre illustratif, un mode opératoire permettant à l'entité d'émission d'opérer sur tout billet électronique de son choix, tel que représenté en figure 2b, une opération d' authentification et de non répudiation grâce à une opération de déchiffrement à partir d'une clé de vérification de signature, distincte de la clé de signature ; la figure 3a représente, à titre illustratif, un schéma synoptique relatif à un serveur gestionnaire de transactions réalisées au moyen de billets électroniques conformes à l'objet de la présente invention ; la figure 3b représente, à titre illustratif, un organigramme fonctionnel du serveur gestionnaire objet de l'invention tel que représenté en figure 3a ; la figure 4a représente, à titre illustratif, un organigramme relatif à un protocole de paiement d'achats de produits ou services par commerce électronique entre un terminal client et un terminal vendeur, conforme à l'objet de la présente invention ; la figure 4b représente, à titre illustratif, une variante de mise en œuvre du protocole de paiement objet de la présente invention de la figure 4a dans lequel une mesure de sécurité consistant à inhiber temporairement l'utilisation ultérieure de billets électroniques, suite à une première utilisation est introduite ; la figure 4c représente, à titre purement illustratif, une variante de mise en œuvre du protocole de paiement objet de la présente invention dans lequel une mesure de sécurité est introduite, suite à la réception par le terminal client d'un message d'accusé de réception de validation de la transaction, par l'intermédiaire du terminal vendeur, l'ensemble des billets électroniques, support de la transaction, étant effacé dans ce terminal client ; la figure 4d représente, à titre illustratif, un exemple de mise en œuvre spécifique de l'introduction , par l'entité d'émission, au niveau du serveur gestionnaire, d'un délai de viduité pour un ou plusieurs billets électroniques, supports d'une transaction, ce délai de viduité consistant en une invalidation simplement interne au serveur du ou des billets électroniques, pendant leur durée de validité, en l'absence de mise en recouvrement de ce ou de ces billets électroniques par leur détenteur, ce délai de viduité consistant au contraire en une invalidation interne au niveau du serveur et externe à ce serveur de ce ou de ces billets électroniques pendant un délai de viduité très supérieur à la durée de validité de ce ou de ces billets électroniques. ; la figure 5 représente, à titre illustratif, une variante non limitative de mise en œuvre du protocole, objet de l'invention dans laquelle une procédure de rendu de monnaie est introduite. ^
Une description plus détaillée d'un billet électronique de valeur fiduciaire conforme à l'objet de la présente invention sera maintenant donnée en liaison avec les figures la, le, 2a à 2f.
D'une manière générale, on indique que le billet électronique de valeur fiduciaire, objet de la présente invention, est mis en œuvre sous forme d'un message ou d'un fichier électronique destiné à un échange entre terminaux et/ou serveur et, de manière plus particulière, dans le cadre d'une transaction entre un terminal client, noté TC, et un terminal vendeur pouvant, le cas échéant, être constitué par un serveur, noté TV.
En référence à la figure la, on indique que selon un aspect particulièrement remarquable du billet électronique, objet de la présente invention, celui-ci comprend, au moins, 'un champ représentatif d'un numéro unique. Ce numéro unique étant lui-même représentatif d'une contre-valeur monétaire établie dans une unité monétaire de compte par une entité d'émission.
Sur la figure la, le champ représentatif du numéro unique est noté NU. Il peut être associé à un champ de contre-valeur monétaire, noté CVM et à un champ d'unité monétaire de compte, noté UMC. En ce qui concerne la notion d'entité d'émissions, on indique que dans le cadre de mise en œuvre des billets électroniques de valeur fiduciaire, du système serveur gestionnaire de transactions réalisées au moyen de billets électroniques de valeur fiduciaire correspondants et du protocole de paiement d'achats de produits ou de services par commerce électronique entre terminal client et un terminal vendeur de produits ou services, conformément à l'objet de la présente invention, concerne tout organisme, toute société commerciale et/ou financière habilitée par les autorités d'un Etat souverain ou d'un groupe d'Etats souverains à émettre et à distribuer des billets électroniques conformes aux billets électroniques, objets de la présente invention.
D'une manière générale, on indique que le champ NU, représentatif d'un numéro unique est avantageusement constitué par un ensemble de caractères alphanumériques. Le nombre de caractères alphanumériques de cet ensemble de caractères alphanumériques peut avantageusement être fonction de la contre-valeur monétaire CVM attribuée aux numéros uniques NU correspondants . Dans un exemple de mise en œuvre spécifique non limitatif et pour une unité monétaire de compte telle que le franc français, un billet dont la contre-valeur monétaire, c'est à dire la valeur faciale, est établie à 50 F comporte un numéro unique NU comprenant douze caractères alphanumériques, un billet de valeur faciale 100 FF peut comprendre avantageusement un numéro unique comprenant 15 caractères alphanumériques et un billet électronique de valeur faciale 500 F peut comprendre avantageusement un numéro unique NU comportant 18 caractères alphanumériques .
Bien entendu, le billet électronique, objet de la présente invention peut être muni de différents champs auxiliaires lesquels seront explicités ultérieurement dans la description. Dans un mode de réalisation non limitatif ainsi que représenté en figure la ou lb, le billet électronique objet de la présente invention peut être mis en œuvre à partir d'un numéro unique NU constitué par un ensemble de caractères alphanumériques comportant au moins un nombre déterminé de digits (un digit désigne un chiffre ou une lettre) fonction de la contre-valeur monétaire attribuée au numéro monétaire unique. Ces digits étant représentatifs d'un nombre unique lié à la contre-valeur monétaire précitée. En outre, un nombre déterminé de caractères alphanumériques inférieur au nombre de digits peut être prévu. Un ou plusieurs caractères alphanumériques étant insérés entre deux digits.
Sur la figure la, on a représenté un billet électronique de contre-valeur monétaire CVM égal à 50 pour une unité monétaire de compte UMC exprimé par un code tel que le code BF pour des francs français par exemple. Le numéro unique NU étant constitué par une suite de caractères alphanumériques : 8, 9A, 254, 1B6, P44 par exemple . Dans ces conditions, un billet de 50 F par exemple est représenté par une série de douze caractères plus un ou plusieurs champs auxiliaires spécifiant l'unité monétaire de compte, c'est à dire la monnaie, ainsi qu'il sera décrit ultérieurement dans la description. Dans ces conditions, le numéro unique NU formé par les douze caractères alphanumériques est composé de neuf chiffres et trois lettres. Les trois lettres ou caractères alphanumériques étant choisis parmi les vingt -six lettres de l'alphabet européen ou, le cas échéant, les 256 caractères ASCII par exemple. Des caractères alphanumériques peuvent être placés au hasard à des emplacements de position aléatoire entre deux digits successifs du nombre déterminé fonction de la contre- valeur monétaire attribuée au numéro unique. Les neufs digits précités procurent déjà un milliard de possibilités dans le choix d'un numéro unique spécifique attribué à la contre-valeur monétaire correspondante. Les caractères alphanumériques permettent d'effectuer 17 576 combinaisons différentes et en raison de l'emplacement aléatoire des caractères précités entre deux digits successifs, on obtient ainsi un facteur de 1 320 combinaisons supplémentaires en raison du placement des caractères alphanumériques précités dans la série de digits précités.
Pour le codage d'une première contre-valeur monétaire CVM de 50 F par exemple, on dispose ainsi d'un nombre de possibilités correspondant : à 1 000 000 000 x 17 576 caractères alphanumériques x 1 320 positions pour ces caractères, soit 23 200 320 milliards de combinaisons de chiffrages différents.
Si l'on suppose donc que l'entité d'émission ne valide qu'une combinaison sur les vingt-trois millions, il est alors possible, pour cette dernière, de mettre en circulation 50 000 000 000 de francs français sous forme de monnaie virtuelle en billets électroniques par l'intermédiaire de coupures de 50 F.
Il est bien entendu que toute autre unité monétaire de compte UMC peut être utilisée en fonction de l'autorisation reçue par les autorités nationales ou régionales contrôlant l'émission des valeurs fiduciaires.
Pour retrouver la bonne combinaison, un faussaire doit, non seulement, pouvoir essayer 23 millions de combinaisons en moyenne pour un billet de valeur faciale
50 F mais, en outre, satisfaire au critère de contrôle strict, d' authentification et de non répudiation de billets imposé par l'entité d'émissions et en particulier par tout serveur, gestionnaire de transactions réalisées au moyen de billets électroniques, objets de la présente invention dans le cadre d'un protocole spécifique, lesquelles seront décrites ultérieurement dans la description. Sur la figure lb, on a représenté différents modes de réalisation de billets électroniques conformes à l'objet de la présente invention pour différentes valeurs, de contre-valeurs monétaires et donc de valeurs faciales de ces billets électroniques.
Le premier exemple de billet électronique représenté en figure lb reprend l'exemple donné en figure la pour un billet de valeur faciale 50 F.
Le deuxième exemple de billet électronique représenté en figure lb correspondant à celui d'un billet électronique de valeur faciale 100 F par exemple. Dans ce cas, et pour la valeur faciale c'est à dire la contre- valeur monétaire CVM est égale à 100 F, le numéro unique NU peut comporter 15 caractères alphanumériques c'est à dire 12 digits et 03 caractères alphanumériques par exemple. Sur la figure lb dans le deuxième exemple, le numéro unique NU s'écrit :
585 / 46A / 222 / R48 / W12.
On dispose dans ces conditions de mille milliards de combinaisons en raison de l'existence de 12 digits, ce nombre de combinaisons étant multiplié par 263 = 17 576 combinaisons pour les 03 caractères alphanumériques et encore multiplié par 15 x 14 x 13 = 2 730 combinaisons pour la position aléatoire des caractères alphanumériques entre les digits précités c'est à dire un total de 47 982 480 fois mille milliards.
Dans ces conditions, l'entité d'émission a donc la possibilité d'émettre en unité monétaire de compte 47 982 480 fois mille milliards X 100 unités monétaires de compte c'est à dire francs français dans l'exemple représenté au deuxième exemple de la figure lb.
Ainsi, l'entité d'émission peut choisir un chiffre valide correspondant au numéro unique NU représenté au deuxième exemple de la figure lb à partir duquel l'entité d'émission pourrait émettre 100 000 000 000 000 (cent mille milliards) d'unités monétaires de compte UMC c'est à dire de francs dans l'exemple retenu. Un faussaire doit, par contre, effectuer 47 000 000 de combinaisons pour trouver la combinaison correspondante.
Dans le troisième exemple de la figure lb, on a représenté, pour un billet de 500 F, un nombre de 15 digits auxquels sont ajoutés 03 caractères alphanumériques . A titre d'exemple dans l'imitative, le troisième exemple de la figure lb comporte un numéro unique NU représenté par :
T52 / 562 / 789 / GH1 / 459 / 770.
Dans ces conditions, il existe pour l'entité d'émission 1 million de milliards de combinaisons en chiffres x 263 = 17 576 caractères alphanumériques placés indifféremment soit en fait 18 x 17 x 16 = 4 896 combinaisons de placement différentes pour un nombre total de combinaisons de 86 052 096 de combinaisons différentes de 1 000 000 de milliards.
Pour assurer la mise en correspondance bi-univoque entre un billet et la valeur faciale ou contre-valeur monétaire qui est associée au numéro unique de celui-ci, l'entité d'émission dispose, par exemple, d'un algorithme de choix aléatoire entre l'une des combinaisons précitées et la valeur faciale allouée à la combinaison retenue permet d'assurer la mise en correspondance bi-univoque entre l'une des combinaisons, fonction du nombre déterminé de digits du nombre de caractères alphanumériques et de la position relative de ces derniers par rapport aux digits et de la valeur faciale ou contre-valeur monétaire attribuée à cette combinaison.
L'algorithme précité est, de préférence, un algorithme non linéaire lequel, grâce à un tirage aléatoire, permet d'assurer la mise en correspondance bi- univoque précitée.
Dans ces conditions, le tableau ci-après indique les capacités d'émission pour l'entité d'émission exprimées pour chaque valeur faciale c'est à dire chaque contre-valeur monétaire CVM en nombre de billets maximum émissibles pour un nombre de caractères alphanumériques entre parenthèses et en masse monétaire virtuelle disponible ainsi que représenté ci-après :
Figure imgf000018_0001
Dans le tableau précité, la valeur faciale de chaque billet virtuel est exprimée en unité monétaire de compte UMC. Il en est de même pour la masse monétaire virtuelle susceptible d'être mise en circulation par l'entité d'émission, cette unité monétaire de compte étant susceptible, bien entendu, d'être émise et de correspondre à toute unité monétaire de compte telle que le franc, le dollar, l'euro ou autre unité monétaire de compte légal. En outre, dans le tableau précité, la dernière colonne représente la probabilité de découverte de la combinaison pour un faussaire par exemple, compte tenu des indications données en liaison avec les figures la et lb . Cette probabilité est notée Prc/f. Sur la facture le, on a représenté un billet électronique de valeur fiduciaire conforme à l'objet de la présente invention comportant, bien entendu, les champs précédemment décrits en liaison avec les figures la et lb mais également au moins un champ auxiliaire noté EE, représentatif de l'entité d'émission, ce champ étant noté EE et étant réputé correspondre à un code d' identification d'une banque ou de toute société habilitée à jouer le rôle d'une entité d'émission, ainsi qu'un champ auxiliaire représentatif du pays hôte de cette entité d'émission. Dans le cas de la figure le, l'exemple non limitatif correspond à une banque en France, la BNP, le pays étant la France, notée FR.
Enfin, ainsi que représenté en figure le, le billet électronique de valeur fiduciaire, objet de la présente invention peut comporter, de manière particulièrement avantageuse, en outre, un champ auxiliaire représentatif de la durée de validité du billet électronique précité. Ce champ est noté DV sur la figure le. Il peut comprendre une valeur de date d'émission du billet électronique par l'entité d'émission, valeur notée X et une valeur Y de date de fin de la validité du billet électronique considéré. Les valeurs X et Y peuvent être exprimées de manière classique en années YY, mois MM, jour DD, heure HH, minute mn et seconde ss.
Selon une caractéristique avantageuse de chaque billet électronique, objet de la présente invention, la durée de validité de ces derniers peut être modulée en fonction de la valeur faciale c'est à dire de la contre- valeur monétaire CVM allouée à chacun de ces derniers. Ainsi, " pour des billets de valeur faciale peu élevée c'est à dire inférieure à 50 unités monétaires de compte, par exemple 50 F, la durée de validité DV peut être établie à deux mois par exemple ; " pour des billets électroniques de valeur faciale moyenne comprise entre 50 et 500 unités monétaires de compte, la durée de validité DV peut être établie à un mois ; " pour des billets électroniques de valeur faciale supérieure à 500 F, UMC, la durée de validité DV peut être réduite à 3 jours par exemple.
On comprend, en particulier, que la faible durée allouée aux billets électroniques de valeur faciale la plus élevée permet de réduite le risque d'interception et de décodage des numéros uniques associés à chacun d'eux lors de la transmission de ces derniers sur le réseau par des utilisateurs indélicats dans un temps raisonnable, alors que la durée de validité plus importante allouée aux billets électroniques de valeur la plus faible permet d'utiliser ceux-ci pendant cette durée à des fins d'échanges de manière très semblable à des billets en papier-monnaie, ainsi qu'il sera décrit ultérieurement dans la description.
D'une manière générale, on indique que les billets électroniques, objets de la présente invention, sont destinés à être utilisés par tout utilisateur qui en a fait régulièrement l'acquisition auprès de l'entité d'émission dans des conditions qui seront explicitées ultérieurement dans la description.
A ce titre, et de manière non limitative, on indique que chaque billet électronique outre le numéro unique NU, peut comporter avantageusement, en clair, la valeur faciale du billet ou contre-valeur monétaire CVM, l'unité monétaire de compte correspondante UMC, l'entité d'émission EE et, bien entendu, le pays hôte de l'entité d'émission par exemple.
Toutefois, et afin de sécuriser non plus le billet en tant que tel c'est à dire le numéro unique NU mais toute transaction réalisée à partir d'un billet ou d'un ensemble de billets électroniques, objets de la présente invention, toute information c'est à dire tout champ du billet électronique, objet de l'invention autre que les champs précédemment cités contenant des informations en clair, peut avantageusement être constitué par une valeur chiffrée ou une valeur de signature non accessible à l'utilisateur habilité et donc au tiers, afin d'assurer une meilleure sécurité des transactions.
Dans ce but, ainsi que représenté en figure 2a, le champ représentatif du numéro unique peut avantageusement être constitué par une valeur chiffrée à partir d'une pluralité de variables du billet électronique comprenant au moins le numéro unique NU, l'entité d'émission EE, la valeur faciale c'est à dire la contre-valeur monétaire CVM du billet ainsi par exemple que l'unité monétaire de compte UMC.
On comprend en particulier que dans ces conditions, le champ de numéro unique lorsque celui-ci est représenté par une valeur chiffrée est désigné par CNU pour désigner cette valeur.
Ainsi que représenté sur la figure 2a, on indique que le champ relatif au numéro unique chiffré CNU peut représenter une longueur variable c'est à dire non constante pour chaque billet électronique successif en fonction du processus de chiffrement utilisé par l'entité d' émission.
Au contraire, ainsi que représenté en figure 2b, le champ relatif au numéro unique chiffré CNU peut présenter une longueur fixe, c'est à dire constante, quel que soit le type de billet émis lorsqu'un processus de chiffrement spécifique par signature électronique à partir d'une fonction de hachage par exemple est mis en œuvre ainsi qu'il sera décrit ultérieurement dans la description.
En outre, sur la figure 2b, on indique que la valeur faciale du billet peut être constituée par une valeur dédiée, cette valeur dédiée 550,09 unités monétaires de compte ayant été établie à la demande d'un utilisateur, c'est à dire d'un terminal client TC, par l'entité d'émission pour réaliser une transaction particulière dont le montant correspond exactement à la valeur dédiée précitée. Dans ces conditions, on comprend que le billet électronique objet de la présente invention présente un degré de sécurité et d'authenticité comparable à celui d'un chèque de banque certifié pour le montant correspondant à la valeur des billets précités. On comprend évidemment que la certification de la valeur des billets, et bien entendu du billet électronique porteur de la valeur faciale correspondante, est donnée par l'entité d'émission dans les conditions qui seront décrites ci- après en liaison avec les figures 2c, 2d et 2e, 2f .
D'une manière générale, on indique que l'établissement d'une valeur de numéro unique chiffré CNU de longueur variable peut, par exemple, être obtenue à partir de processus de chiffrement à partir d'une clé secrète notée KS par la technique du masque jetable par exemple ou une technique de stéganographie. Dans ce but, ainsi que représenté en figure 2c l'on procède à une étape CH1 à une concaténation des champs de numéro utile NU, d'entité d'émission EE, de contre-valeur monétaire CVM, d'unité monétaire de compte UMC pour obtenir une chaîne de caractères notée $ . La concaténation s'entend soit de la concaténation simple des champs précités, soit d'une concaténation dite embrouillée selon un algorithme spécifique de mélange des caractères consécutifs de chaque champ.
En outre et de manière non limitative, aux valeurs des champs du billet électronique précité peut être ajouté au moins un champ externe à celui-ci tel que par exemple l'adresse électronique du terminal créancier c'est à dire du terminal vendeur TV dans l'exemple de transactions précédemment mentionnées dans la description, cette adresse étant notée ATV par exemple. On comprend en particulier que l'introduction d'un champ de valeur externe telle que l'adresse du terminal vendeur ATV permet de diversifier la longueur du champ du numéro utile chiffré CNU, celui-ci n'étant donc pas de longueur constante en fonction de la longueur de l'adresse du terminal vendeur précité. En outre, l'introduction d'une telle adresse lors de l'exécution d'une transaction permet, d'une part, de justifier de la possession du billet par le terminal créancier c'est à dire le terminal vendeur et par le destinataire c'est à dire par le vendeur agréé suite à une validation de la transaction précitée et, d'autre part, d'assurer un échange sécurisé du même billet électronique au cours de transactions successives par simple remplacement dans la pluralité de variables de l'adresse électronique du terminal vendeur c'est à dire le terminal créancier destinataire de ce billet électronique. La chaîne de caractères $ ainsi obtenue est alors soumise à une étape CH2 à une opération de chiffrement à partir de la clé secrète KS . Cette opération est notée : C = Cκs($) = CNU.
Dans la relation précédente CKs($) désigne l'opération de chiffrement de la chaîne de caractères dollar et C désigne la valeur chiffrée ainsi obtenue et correspondant à la valeur du champ CNU. Les opérations précitées permettent à l'entité d'émission d'assurer sur tout billet des opérations d' authentification et de non répudiation que cette dernière juge nécessaires.
Dans ces conditions, sur réception d'un billet comportant un champ de numéro unique chiffré CNU et lorsque ce champ a été obtenu à partir du chiffrement par l'intermédiaire d'une clé secrète KS, ces opérations, ainsi que représentées en figure 2d, peuvent consister à effectuer un déchiffrement du champ CNU, cette opération étant notée : Dκs(CNU) => $ et permettant de restituer la chaîne de caractères non chiffrés obtenue par l'opération de concaténation précédemment mentionnée en liaison avec la figure 2c. L'opération de déchiffrement DCH1 est alors suivie d'une opération de lecture de la chaîne de caractères dollar, opération notée. DCH2 , cette opération de lecture permettant de restituer, soit par lecture directe lorsque la concaténation a été effectuée comme une concaténation directe, soit après désembrouillage et lecture lorsque la concaténation a été précédée d'une opération d' embrouillage, de restituer les champs candidats NQ*, EE*, CVM*, UMC* et ATV*. Ces champs candidats étant des champs obtenus de par l'opération de déchiffrement réalisée à l'étape DCH1.
L'entité d'émission procède alors en une étape DCH3 en une comparaison d'égalité de chaque champ candidat NQ*, EE*, CVM*, UMC* avec les champs d'origine non chiffrés NU, EE, CVM, UMC respectivement.
Sur réponse positive à l'ensemble des opérations de comparaison d'égalité réalisées à l'étape DCH3 , le billet électronique est authentifié et non répudié par l'entité d'émission à l'étape DCH5.
Au contraire, sur réponse négative à l'une des comparaisons d'égalité réalisées à l'étape DCH3 , le billet électronique est invalidé à l'étape DCH4 par l'entité d'émission. Les figures 2e et 2f concernent des opérations comparables de calcul de signature pour constituer un champ de numéro unique chiffré CNU de longueur fixe tel que représenté en figure 2b. Pour obtenir un champ de numéro unique correspondant à une valeur de signature de longueur fixe ou constante quel que soit le billet, une telle opération peut être réalisée par le calcul d'une valeur de signature à partir d'une fonction de hachage H ainsi que représentée en figure 2e.
Les valeurs des champs de numéros utiles NU, d'entité d'émission EE, de contre-valeur monétaire CVM, d'unité monétaire de compte UMC et, le cas échéant, de valeurs externes aux billets électroniques tel que l'adresse du terminal vendeur ATV et, par exemple, une variable aléatoire VA peuvent être soumis à une concaténation dans les conditions telles que précédemment mentionnées dans la description à une étape CH3 , pour obtenir une chaîne de caractères notée $$. L'étape de concaténation précitée peut être suivie du calcul par l'intermédiaire d'une fonction de- hachage d'une valeur hachée de longueur normalisée fixe, cette opération étant notée :
H $$ => N$. La chaîne de caractères de longueur normalisée N$ est alors soumise à signature à partir d'une clé privée KPR à partir d'un algorithme tel que l'algorithme RSA par exemple. Cette opération est notée :
S = SKPR (N$) pour obtenir la valeur signée, c'est à dire le champ CNU de longueur fixe. Dans la relation précédente, S désigne la valeur de signature effectivement obtenue et SKPR désigne l'opération de signature à partir de l'algorithme RSA précité et de la clé privée KPR. Pour réaliser les opérations d' authentification et de non répudiation d'un billet électronique, l'entité d'émission est alors en mesure de procéder ainsi que représenté à la figure 2f.
L'entité d'émission dispose du champ de numéros utiles chiffrés CNU correspondant à la valeur de signature précitée de longueur fixe.
Elle est alors en mesure, en une étape DCH6, de procéder à une vérification de la signature précitée à partir d'une clé de vérification de signature notée KPU, cette clé constituant une clé dissymétrique vis-à-vis de la clé de calcul de signature KPR. L'opération de vérification est effectuée à partir de l'algorithme RSA par exemple et est notée : pυ ( CNU) = ' KPU ( SKPR {N$ } ) Cette opération permet d'obtenir les champs candidats NU*, EE*, CVM*, UMC*, ATV* et bien entendu VA*. L'opération DCH6 est alors suivie d'une opération de vérification par comparaison d'égalité des champs candidats précités NU*, EE*, CVM*, UMC* et VA* par exemple , ainsi que, le cas échéant, du champ candidat ATV* aux valeurs de champs d'origine NU, EE, CVM, le cas échéant, VA et ATV.
Sur réponse négative à l'une des comparaisons d'égalité du test BCH7 , l'entité d'émission procède à une invalidation à l'étape DCH8. Au contraire, sur réponse positive à toutes les comparaisons d'égalité de l'étape DCH7, l'entité d'émission procède à une authentification à une non-répudiâtion du billet électronique considéré à l'étape DCH9.
Une description plus détaillée d'un système serveur gestionnaire de transactions réalisées au moyen de billets électroniques de valeur fiduciaire, conformes à l'objet de la présente invention, sera maintenant décrit en liaison avec les figures 3a et 3b.
D'une manière générale, on indique que les transactions prises en considération interviennent entre un acheteur et un vendeur, ces transactions étant réalisées à partir d'un terminal client acheteur noté TC et un terminal vendeur noté TV, ce terminal vendeur pouvant bien entendu consister en un serveur assurant les opérations de commerce électronique adéquates .
Ainsi que représenté sur la figure 3a, le système serveur comprend un module de mémorisation noté HDD1 d'un ensemble de vendeurs accrédités habilités à conclure une ou plusieurs transactions au moyen des billets électroniques de valeur fiduciaire décrites précédemment dans la description.
D'une manière générale, on indique que le module de mémorisation HDD1 est constitué avantageusement par un disque dur autonome permettant de mémoriser l'ensemble des vendeurs accrédités sous forme d'une liste ou, le cas échéant, d'un tableau, la liste ou le tableau étant constitué par des entités ou des variables correspondant au nom du vendeur, à l'adresse électronique de son terminal et à un code d'accès d'accréditation du vendeur auprès du système serveur gestionnaire de billets électroniques tels que représentés en figure 1 par exemple .
En outre, le système serveur, objet de l'invention comprend un module noté HDD2 de mémorisation de listes de billets électroniques de valeur fiduciaire émis valides respectivement invalides pendant une durée de viduité.
Dans un mode de réalisation simplifié, le module HDD2 de > mémorisation des listes de billets électroniques précités est constitué par un disque dur indépendant permettant de mémoriser ces listes sous forme de listes distinctes comportant au moins le numéro du billet considéré dans un répertoire de billets émis valides respectivement un répertoire de billets émis invalides.
On comprend bien entendu que la réalisation des modules HDD1 et HDD2 sous forme de disque dur indépendant permet d'appliquer des conditions de sécurité d'accès particulièrement draconiennes en ce qui concerne le module HDD2 de mémorisation de listes de billets électroniques valides respectivement invalides. Ces conditions d'accès particulièrement sévères peuvent, le cas échéant, ne pas être appliquées de manière aussi stricte au module de mémorisation HDD1. Les processus de contrôle d'accès correspondants qui peuvent correspondre à des processus de contrôle d'accès classiques ne seront pas décrits en détail dans la description pour cette raison.
En outre, ainsi que représenté en figure 3a, le système serveur, objet de la présente invention comprend un module 1 de contrôle et d' authentification d'accès au système serveur de tout vendeur accrédité en vue d'une opération soit d' authentification de transactions et en particulier d' authentification du paiement réalisé au moyen d'un ou plusieurs billets électroniques précédemment décrits dans la description, soit de mise en recouvrement de billets électroniques de valeur fiduciaire échangés au cours de cette transaction. Un protocole simple d' authentification peut consister, sur accès d'un vendeur accrédité présentant son code d'accès, en une comparaison de ce code d'accès vis-à- vis du code d'accès de référence mémorisé dans le module HDD1. Bien entendu, les conditions de mise en œuvre du protocole de contrôle d'accès correspondant à des conditions habituelles compte tenu des règles de sécurité imposées ne sera pas décrit dans la description pour cette raison.
Le système serveur objet de la présente invention comporte également un module 2 de vérification de la validité du numéro unique de chaque billet électronique NU de valeur fiduciaire échangé à partir d'au moins une liste de billets électroniques de valeur fiduciaire valides et invalides. Ce module de vérification 2 peut consister en un module de type module logiciel permettant d'assurer la vérification selon le test de comparaison DCH3 représenté en figure 2d ou DCH7 représenté en figure 2f, en fonction du type de chiffrement ou de calcul de valeur de signature utilisé . Lorsque les billets électroniques mis en circulation ne comportent pas de champ de numéro unique chiffré, le numéro unique en clair étant seul transmis, l'opération réalisée par le module 2 de vérification de la validité du numéro unique de chaque billet électronique se résume à la comparaison d'égalité des champs candidats reçus en clair, vis-à-vis des champs de référence lus sur le module de mémorisation HDD2.
Enfin, le système serveur comporte un module 3 de notification au vendeur accrédité, c'est à dire au terminal vendeur TV, d'un message de validation de transaction entre le vendeur et un acheteur quelconque. Ce module 3 permet l'envoi au vendeur d'un message de validation de transaction sur vérification positive de la validité du numéro unique de chaque billet électronique de valeur fiduciaire échangé, ainsi qu'il a été explicité précédemment dans la description.
Le module 2 de vérification du numéro unique peut, ainsi que représenté en figure 3a, être en outre accompagné d'un module 4 de comptage du nombre d'erreurs de vérification de la validité du numéro unique de chaque billet électronique de valeur fiduciaire échangé, ainsi que d'un module 5 de comparaison du nombre d'erreurs de vérification de la validité du numéro unique à une valeur de seuil. Sur la figure 3a, les modules 4 et 5 de comptage du nombre d'erreurs et de comparaison du nombre d'erreurs à une valeur de seuil sont représentés par un même élément afin de ne pas surcharger inutilement le dessin.
En ce qui concerne la valeur de seuil précitée, celle-ci peut être contenue et mémorisée sur le module HDD2.
Dans un mode de réalisation particulier le module 4,5 de comparaison permet de piloter le module de notification 3 et permet l'envoi d'un message d'invalidation de transaction au vendeur accrédité lorsque le nombre d'erreur de vérification est supérieur ou égal à la valeur de seuil Vseuil considéré. Le mode opératoire du serveur représenté en figure 3a sera maintenant décrit en liaison avec la figure 3b. L'entité d'émission qui assure la gestion et le contrôle du système ' serveur gestionnaire de transaction réalisée au moyen de billets électroniques, conformes à l'objet de la présente invention, contrôle par l'intermédiaire de ce serveur deux tâches principales : celle consistant à valider les numéros uniques présentés et celle consistant à procéder aux opérations bancaires correspondantes .
Chaque vendeur souhaitant proposer le mode de paiement, objet de la présente invention, au moyen des billets électroniques correspondants, doit au préalable remplir un dossier d'affiliation et ainsi obtenir un numéro ou code d'accréditation ainsi que mentionné précédemment dans la description.
Ce code d'accréditation lui permet de s'identifier à chaque connexion pour demande de validation d'une transaction, c'est à dire d'un paiement, et, le cas échéant, pour demande de mise en recouvrement de tout billet virtuel correspondant.
Sur la figure 3b, les références chiffrées désignent des opérations réalisées par les modules de numéros correspondants sur la figure 3a. A partir d'une étape DEBUT, la, correspondant à une position d'attente à une étape lb du module de contrôle d'accès 1, le module de contrôle d'accès 1 précité communique le numéro d'accréditation et opère en une étape le une vérification du contrôle d'accès par lecture de la liste des vendeurs accrédités LVA mémorisés sur le module HDD1. Le module de contrôle d'accès 1 permet, bien sûr, de vérifier l'adéquation entre le code d'accréditation présenté et l'adresse IP par exemple ainsi que les différents identificateurs du réseau Internet lorsque ce dernier est utilisé . En cas de difficulté, il est possible de rendre ce numéro ou code d'accréditation variable et ainsi de fournir au vendeur accrédité une disquette contenant un programme non lisible permettant de fournir un code différent à chaque accès selon la date, l'heure ou tout autre paramètre. Le module de contrôle d'accès assure la vérification, la correspondance entre tous les paramètres du terminal vendeur TV.
Dans le cas où le code d'accréditation n'est pas valide à l'étape le, l'accès est refusé et le serveur est replacé en position de DEBUT la.
Si au contraire l'accès est accepté, le module de contrôle d'accès 1 procède à la communication des numéros uniques des billets électroniques au module 2 de vérification du numéro unique NU. Le serveur dispose en fait de la liste exacte des billets électroniques valides et connaît, en conséquence, si un numéro unique est valide ou non. Cette opération réalisée à l'étape 2a sur la figure 3b peut correspondre à celle déjà mentionnée dans la description en liaison avec les figures 2d et 2f.
Si à l'étape 2a le numéro unique de billet électronique est valide, alors le module 2 transmet un ordre d'exécution au module 3 de notification de message de validation lequel à l'étape 3a envoie un message de validité de transaction par l'intermédiaire de la liaison du serveur au réseau étendu par exemple, le serveur revenant en position de début afin de permettre, le cas échéant, de créditer le compte du vendeur et d'invalider le numéro unique correspondant pendant une durée de viduité, ainsi qu'il sera décrit ultérieurement dans la description. Si au contraire, le numéro unique à l'étape 2a n'est pas reconnu comme valide, le module 2 lance une commande au module 4 de comptage de comparaison du nombre d'erreurs, lequel, à l'opération 4a lors de la détection de trois erreurs successives par exemple, assure la déconnexion et l'invalidation de l'accréditation ainsi que, le cas échéant, la mise en mémoire des références du vendeur dans une liste de fraudeurs identifiés.
Dans un tel cas, le vendeur doit établir une connexion de rétablissement qui permet de bien contrôler que l'identité de ce demandeur n'a pas été usurpée par une personne non habilitée et que ces erreurs proviennent alors d'un client de ce vendeur, client identifié ou non.
Le vendeur doit alors se déconnecter de son client, l'identifier avant déconnexion et, bien entendu, communiquer cette identification au système serveur gestionnaire représenté en figure 3a.
La mise en œuvre de la procédure d' identification et de contrôle sur un nombre d'erreurs successives puis ré-accréditation du vendeur permet de supprimer tout risque de fraude sensible.
Un protocole spécifique de paiement d'achat de produits ou services par commerce électronique entre un terminal client TC, un terminal vendeur TV de produits ou services et, bien entendu, le serveur S gestionnaire de transactions réalisées au moyen de billets électroniques de valeur fiduciaire, conformes à l'objet de la présente invention, sera maintenant décrit en liaison avec les figures 4a à 4b.
D'une manière générale, on indique que le terminal client TC est détenteur de billets électroniques de valeur fiduciaire tel que décrit précédemment dans la description .
Ces billets électroniques peuvent être distribués par un serveur spécifique ou, le cas échéant, par tout moyen ainsi qu'il sera décrit ultérieurement dans la description. Bien entendu, le serveur spécifique et les organes de distribution de ces billets électroniques sont contrôlés par l'entité d'émission. Des billets électroniques sont mémorisés dans le terminal client TC.
Le terminal vendeur TV est géré et contrôlé par un vendeur agréé, lequel s'est vu attribuer un numéro ou code d'accréditation permettant à ce dernier un accès au serveur gestionnaire, tel que décrit précédemment et dans les conditions décrites en liaison avec la figure 3a et la figure 3b. On se trouve ainsi dans une situation de départ notée ST à la figure 4a mettant en relation le serveur S, le terminal client TC , le terminal vendeur TV.
Cette situation de départ ST correspond à celle dans laquelle, lors de la conduite d'un accord d'achat- vente de produits ou services pour un prix d'achat déterminé PA, le client a établi un ensemble de billets électroniques, chaque billet Bi ayant une valeur faciale ou contre-valeur monétaire CVMi, le client ayant choisi dans ses billets un ensemble de billets noté [Bi])~ k P dont la somme de la valeur faciale couvre le prix d'achat PA. Suite à l'accord d'achat-vente entre le terminal client et le terminal vendeur, le protocole de paiement, objet de l'invention, consiste au moins en une étape A à transmettre, à titre de paiement de transaction, du terminal client TC au terminal vendeur TV, un ensemble de billets électroniques, l'ensemble [Bj]|~ k p précité dont la somme de la valeur faciale couvre le prix d'achat PA.
Cette opération à l'étape A est notée transmission de :
Figure imgf000036_0001
L'étape A précitée est alors suivie d'une étape B consistant à transmettre, du terminal vendeur TV à l'organisme serveur spécifique S, l'ensemble de billets électroniques, support de la transaction pour authentification. Cette opération est réalisée à l'étape B par l'intermédiaire d'une sous étape Bl laquelle est suivie d'une sous étape B2 d' authentification du numéro unique ΝUi* candidat au numéro unique ΝUi de référence mémorisé au niveau du module HDD2 , ainsi que mentionné en liaison avec la figure 3a. Cette opération est réalisée pour tous les billets Bi .
Sur procédure d' authentification réussie à la sous étape B2 , cette procédure d' authentification étant représentée de manière simplifiée par la relation :
ViΝUi* = ΝUi, à chaque billet de l'ensemble de billets électroniques, support de la transaction étant reconnue la valeur faciale qui lui est dévolue, l'étape B est alors suivie d'une étape C consistant à transmettre de l'organisme serveur spécifique S au terminal vendeur TV un message de validation de paiement noté MVP_V.
L'étape C précitée est alors suivie avantageusement d'une étape D consistant à invalider au moins au niveau du serveur spécifique S tout billet électronique Bi de l'ensemble de billets électroniques, support de la transaction, pendant un délai de viduité spécifique. On comprend en particulier que l'invalidation des billets électroniques de l'ensemble de billets électroniques, support de la transaction, pendant ce délai de viduité, lequel peut être pris égal à un, deux ou trois ans, permet en fait de ne pas réutiliser le numéro unique attribué à chacun des billets pendant ce délai, afin de ne pas rediffuser les codes correspondants des numéros uniques pendant le délai de viduité précité. Ceci permet de réduire la vulnérabilité des billets électroniques, objets de la présente invention, aux attaques des fraudeurs intempestifs sur le réseau.
Sur réponse négative aux tests à la sous étape B2, 1 ' authentification du numéro unique n'étant pas réussie, le protocole de paiement, objet de l'invention consiste à une étape J à transmettre, de l'organisme serveur spécifique S au terminal vendeur TV, un message noté MIVP d'invalidation de paiement et de non validation de la transaction. La figure 4b représente une variante de mise en œuvre du protocole, objet de la présente invention tel que représenté en figure 4a.
Dans la variante précitée, suite à l'étape A consistant à transmettre à titre de paiement de transaction un ensemble de billets électroniques, support de la transaction, l'ensemble [Bj]~, P, cette étape étant représentée à l'étape effective Al de la figure 4b, le protocole objet de l'invention dans ce mode de réalisation consiste, en une sous étape A2 , à inhiber, au moins temporairement au niveau du terminal client TC, l'utilisation par ce terminal client de tout billet électronique appartenant à l'ensemble de billets électroniques support de cette transaction. Cette inhibition temporaire peut être maintenue avantageusement au moins jusqu'à l'invalidation, au moins au niveau du serveur spécifique S de tout billet électronique de cet ensemble de billets électroniques pendant le délai de viduité sur procédure d' authentification réussie.
On comprend en particulier que la sous-étape d'inhibition temporaire A2 permet ainsi de supprimer tout risque d'utilisation multiple successive de billets électroniques comportant un même numéro unique pour des transactions distinctes, que cette utilisation successive soit frauduleuse de la part de l'utilisateur du terminal client TC ou fortuite. Cette inhibition temporaire peut alors permettre de renforcer la sécurité des tiers dans la conduite des transactions vis-à-vis d'une transaction déjà réalisée par le terminal client TC . A titre d'exemple non limitatif, on indique que l'opération réalisée à la sous-étape A2 d'inhibition temporaire peut consister dans le terminal client TC à provoquer la mémorisation de tout billet électronique utilisé pour une transaction spécifique dans une liste ou dans un fichier archivé et dont l'accès en lecture est rendu conditionnel à une autorisation du serveur par l'intermédiaire du terminal vendeur par exemple, ainsi qu'il sera décrit ultérieurement dans la description. En outre, ainsi que représenté également en figure 4, le protocole, objet de la présente invention, peut consister suite à l'étape C consistant à transmettre de l'organisme serveur spécifique S au terminal vendeur agréé TV un message de validation de paiement, à réaliser en outre une opération E de transmission du terminal vendeur agréé TV au terminal client TC un message d'accusé de réception de paiement de transaction, puis, sur réception du message d'accusé de réception de paiement par le terminal client TC, à effacer dans le terminal client TC chaque billet électronique de l'ensemble de billets électroniques noté [BiJÎ≈k P objet ou support de la transaction.
On comprend en particulier que l'étape F d'effacement précité peut être réalisée sur la liste de billets électroniques soumis à inhibition temporaire et mémorisés dans un fichier spécifique tel que mentionné précédemment dans la description.
Enfin, ainsi que représenté en figure 4a, le protocole, objet de la présente invention, peut consister, suite à l'étape C, transmission de l'organe serveur spécifique S au terminal vendeur TV d'un message de validation de paiement, à réaliser, en outre, à l'initiative du vendeur agréé, utilisateur du terminal vendeur, une étape G consistant à transmettre du terminal vendeur à l'organisme serveur spécifique S une requête d'accréditation de compte bancaire notée REQ_AC_CB, compte bancaire au nom du vendeur agréé pour un montant correspondant du montant de la transaction. Sur la figure 4a, en raison de la réalisation de l'étape G conditionnelle à l'initiative du vendeur, le lien entre l'étape C et l'étape G est représentée en traits mixtes.
Sur acceptation de la requête d'accréditation REQ_AC_CB, l'étape G est alors suivie d'une étape H de renvoi d'un accusé de réception et de validation de la requête au terminal vendeur agréé TV, l'accusé de réception étant noté MACK_V.
L'étape H est alors suivie d'une étape I consistant à effacer, au niveau du terminal vendeur agréé TV, tout billet électronique de cet ensemble de billets électroniques, l'ensemble [Bi]|=k +P ' suPPor de la transaction, et ayant fait l'objet d'une mise en recouvrement .
Un mode de mise en œuvre spécifique non limitatif de l'attribution de délai de viduité à l'un des billets électroniques par l'organisme serveur spécifique S conformément au protocole de paiement, objet de la présente invention, sera maintenant décrit en liaison avec la figure 4d.
Ce- mode de gestion spécifique prend en compte une situation de départ ST dans laquelle le serveur S s'est vu notifier l'ensemble des billets électroniques, support d'une transaction, l'ensemble [BiJjIj- , et où un message de validation de paiement MVP_V a été transmis à l'étape C vers le terminal vendeur TV.
En conséquence, la figure 4d représente un mode de mise en œuvre non limitatif de l'étape D de la figure 4a.
Ce mode de mise en œuvre prend en compte l'existence ou la non-existence d'une requête d'accréditation de compte bancaire à l'initiative du terminal vendeur à l'étape G. Dans ce but, le serveur S réalise une étape de vérification Dl consistant à vérifier l'existence d'une requête d'accréditation REQ_AC_CB du compte bancaire à l'initiative du vendeur. Sur réponse positive à l'étape de vérification Dl, une étape D4 est réalisée par le serveur consistant à effectuer une invalidation interne et externe de tout ensemble de billets, support d'une transaction, l'ensemble [Bj]-~ k +p, l'invalidation interne consistant dans le serveur à attribuer un délai de viduité DVi à chaque billet Bi très supérieur à la durée de validité DVIDi de chacun des billets Bi correspondant. La durée de viduité DVIDi peut correspondre à la durée de deux ou trois ans mentionnée précédemment dans la description.
En ce qui concerne l'invalidation externe de chacun des billets Bi précités, on indique que cette invalidation est effectuée suite à l'étape C et parallèlement à l'invalidation interne réalisée à l'étape B, et en particulier à la sous-étape D4 précitée par l'intermédiaire des étapes E et F dans le terminal client, ainsi bien entendu qu'à l'étape I dans le terminal vendeur TC, ainsi que décrit précédemment dans la description en liaison avec la figure 4a.
Au contraire, sur réponse négative à l'étape de vérification Dl , une étape D2 d'invalidation interne seule de l'ensemble des billets électroniques, support de la transaction l'ensemble
Figure imgf000042_0001
effectuée dans le serveur S, cette étape D2 pouvant consister dans le serveur à mémoriser la liste des billets constitutifs de cet ensemble de billets dans un répertoire spécifique auquel est allouée une durée de viduité DVIDi correspondant à la durée de validité de chacun des billets DVIDi au maximum.
L'opération réalisée à la sous étape B2 permet alors au serveur, en l'absence de requête d'accréditation de compte bancaire au nom du vendeur, d'assurer l'échange de billets électroniques entre différents vendeurs ou, le cas échéant, entre vendeurs et tiers pendant la durée de validité DVi allouée à chaque billet Bi. On comprend bien sûr que cette étape d'échange peut être réalisée indépendamment du serveur S pendant la durée de validité précitée à l'étape D3 , chaque possesseur d'un billet dont la durée de validité est alors affichée pouvant continuer l'échange pendant cette durée de validité ou, le cas échéant, procéder à une demande d'accréditation de compte bancaire selon les étapes G, H, I décrites précédemment en figure 4a.
Pour réaliser une telle demande d'accréditation, le tiers non identifié peut se déclarer auprès du serveur ou de tout serveur habilité à réaliser une accréditation de compte bancaire au nom de l'utilisateur tiers. Une description plus détaillée d'un mode de réalisation préférentiel non limitatif du protocole de paiement d'achat de produits ou services par commerce électronique, objet de la présente invention, sera maintenant donnée en liaison avec la figure 5.
Le mode de réalisation précité permet, pour une somme de la valeur faciale transmise supérieure au prix d'achat PA, somme visant à effectuer le règlement du prix d'achat, d'introduire une procédure de rendu de monnaie en unité monétaire de compte.
L'introduction d'une telle procédure apparaît particulièrement remarquable en raison du fait que celle- ci permet alors de rapprocher de manière quasi parfaite le protocole de paiement, objet de la présente invention, dans le cadre du commerce électronique, de celui d'un paiement classique par échange de papier monnaie entre le vendeur et l'acheteur.
En référence à la figure 5 précitée, la procédure de rendu de monnaie peut être mise en œuvre après l'étape A de la figure 4a.
Dans ces conditions, ainsi que représenté à la figure 5, le protocole objet de la présente invention consiste au moins, en une étape B'1), à transmettre, du terminal vendeur TV à l'organisme serveur spécifique S, l'ensemble [Bj]-~ k +p des billets virtuels, support de la transaction, ainsi que, bien entendu, la valeur du prix d'achat PA pour authentification. L'étape B'1 précitée est alors suivie de l'étape d' authentification B'2, laquelle peut être identique à l'étape B2 de la figure 4, pour constituer l'étape B' semblable à l'étape B de la figure 4a précitée. En outre, et de manière non limitative, on indique que l'étape B'2 d' authentification peut comporter, outre la vérification de l'égalité des champs candidats NUi* et des champs d'origine Ui pour chacun des billets d'indice i, la vérification de la supériorité de la somme de la valeur faciale de l'ensemble des billets transmis Bi, support de la transaction au prix d'achat PA.
L'étape B' , sur procédure d' authentification réussie et à chaque billet de l'ensemble de billets électroniques, support de la transaction, étant reconnue la valeur faciale qui lui est dévolue, est suivie d'une étape C consistant à transmettre, du système organisme serveur spécifique S au terminal vendeur TV, le message de validation de paiement MVP_V ainsi qu'un sous ensemble de billets électroniques, ensemble noté [SBj]j^™+n , dont la somme de la valeur faciale couvre la différence entre la somme de valeur faciale transmise et le prix PA. On comprend, bien entendu, que chaque billet du sous ensemble de billets électroniques est établi dans la même unité monétaire de compte que celle des billets de l'ensemble de billets électroniques transmis, support de la transaction et que, de cette manière, la monnaie peut être rendue en unité monétaire de compte correspondante. La notion de sous ensemble de billets électroniques dont la somme de la valeur faciale couvre la différence entre la somme de valeur faciale transmise et le prix d'achat désigne tout sous ensemble de billets électroniques de la classe des billets électroniques définis précédemment dans la description pour les billets de valeur faciale différente précédemment décrits . L'étape C est alors suivie d'une étape E'1 consistant à transmettre, du terminal vendeur TV au terminal client TC, le sous ensemble de billets électroniques au titre de monnaie rendue et noté
On indique de manière non limitative que la transmission du terminal vendeur TV au terminal client TC du sous-ensemble de billets électroniques au titre de monnaie rendue [SBj]j~™+n peut être effectuée, ainsi que représenté sur la figure 5, simultanément à la transmission du message MVPT_C de validation de paiement. De préférence, à chaque billet du sous-ensemble de billets de monnaie rendue peut également être affectée, au titre de variable auxiliaire, l'adresse du terminal client TC de manière analogue au mode de réalisation déjà décrit précédemment dans la description pour la transaction terminal client, terminal vendeur.
En outre, ainsi que représenté en figure 5, l'étape consistant à transmettre du terminal vendeur TV au terminal client TC le sous-ensemble de billets électroniques au titre de monnaie rendue, représentée à l'étape E'1 de la figure 5, peut être suivie d'une étape d'effacement, notée E'2, dans le terminal vendeur TV de chaque billet électronique du sous-ensemble de billets électroniques au titre de monnaie rendue [SBj ~™+n . Sur la figure 5, de manière non limitative, les étapes E'1 et E'2 sont réputées définir une étape E' , laquelle apparaît comme une étape perfectionnée par rapport à l'étape E de la figure 4a. L'étape E' est alors suivie de l'étape F de la figure 4a consistant en un effacement de l'ensemble des billets électroniques, support de la transaction [Bj]j~ k +P dans le terminal client TC.
Différentes indications seront maintenant données en ce qui concerne le mode d'acquisition par un client quelconque muni d'un terminal client TC de billets électroniques permettant à ce dernier de mettre en œuvre le protocole, objet de la présente invention.
En ce qui concerne l'acquisition de billets virtuels, cette acquisition par le client précité peut être réalisée par exemple de trois manières différentes :
" dans un commerce quelconque, les billets virtuels pouvant se présenter sous forme de cartes plastifiées comportant au moins un enregistrement d'un ou plusieurs billets virtuels. De préférence, la zone d'enregistrement des billets virtuels précités peut être constituée par une zone effaçable, laquelle permet au client considéré d'introduire par exemple les billets virtuels dans son terminal client TC, la première introduction assurant l'effacement de la zone d'enregistrement précitée sur la carte plastifiée par exemple .
" Le client précité peut également acheter des billets virtuels de valeur fiduciaire conformes à l'objet de la présente invention dans un guichet distributeur automatique de billets, désigné guichet DAB.
Dans ces conditions, le client introduit par exemple une carte bancaire, de type carte à puce, dans la fente du guichet DAB, choisit l'achat de billets électroniques de valeur fiduciaire. Le guichet DAB se connecte au serveur spécifique et réalise l'opération de demande de transfert de billets virtuels vers la carte bancaire du client. Lorsque les billets virtuels sont acquis par ce dernier, un débit automatique du compte de la carte bancaire de la somme correspondante est effectué et un ticket ou facturette correspondant à la transaction est délivré (e) au client. On comprend en particulier que l'édition de ce ticket revient à l'impression du reçu du retrait actuel délivré lors de transactions à partir de cartes bancaires. Bien entendu, et comme dans le cas du papier monnaie, le client, acheteur des billets virtuels, possesseur de ces billets, est responsable, non seulement de l'utilisation de ces billets virtuels, mais également de leur reproduction et de toute contribution à la reproduction de ces billets, de la même manière que dans le cas de billets en papier.
" Le client peut également acheter des billets sur Internet par connexion au site serveur spécifique S, la transaction pouvant également être réalisée à partir d'un terminal lecteur de carte bancaire par exemple. Les billets virtuels sont alors directement téléchargés sur son terminal client TC, un programme de gestion spécifique pouvant être implanté sur le terminal client TC précité.
Les billets virtuels et le protocole de paiement d'achat, objets de la présente invention, permettent, contrairement au système de paiement électronique actuel par carte bancaire, de réaliser des paiements d'achats très proches de la réalisation de paiements d'achats à partir de papier monnaie pour les raisons ci-après : " en premier lieu, le possesseur de billets virtuels est possesseur de ces billets dans les mêmes conditions que le possesseur de billets en papier monnaie ; " l'échange de billets virtuels entre utilisateurs est réalisé de manière semblable à l'échange de billets en papier monnaie, tout échange étant réalisé de manière totalement anonyme pour le client et pour tout client successif, seul le destinataire c'est-à-dire le vendeur pouvant, le cas échéant, apparaître comme titulaire des billets qu'il possède, ce qui bien entendu n'ajoute aucune information sur la transaction réalisée ;
" la perte ou la substitution, frauduleuse ou non, d'un billet électronique de valeur fiduciaire a pour conséquence la perte ou la substitution de la valeur faciale en unité monétaire de compte correspondante comme dans le cas d'un billet en papier monnaie ;
" la sécurisation des billets électroniques virtuels peut être rendue supérieure à celle des billets en papier monnaie en raison, d'une part, de l'existence d'un codage spécifique entre le numéro unique représentatif d'une contre valeur monétaire particulière, et, d'autre part, de la protection d'un tel codage par un procédé de chiffrement, ce qui bien entendu rend d'autant plus délicat toute tentative de percement et de reproduction de l'ensemble ; toute tentative apparaît d'autant plus illusoire que les moyens informatiques nécessaires à leur mise en œuvre représentent un investissement sans commune mesure avec la valeur du billet virtuel, objet de l'attaque.

Claims

REVENDICATIONS
1. Billet électronique de valeur fiduciaire, caractérisé en ce qu'il comprend au moins un champ représentatif d'un numéro unique représentatif d'une contre-valeur monétaire, établie dans une unité monétaire de compte, par une entité d'émission, ledit numéro unique codé selon une combinaison de caractères en fonction de la contre-valeur monétaire présentant une probabilité de découverte de ladite combinaison liée à cette contre- valeur monétaire.
2. Billet selon la revendication 1, caractérisé en ce que le champ représentatif d'un numéro unique est constitué par un ensemble de caractères alphanumériques, le nombre de caractères alphanumériques de cet ensemble de caractères alphanumériques étant fonction de ladite contre-valeur monétaire attribuée audit numéro unique.
3. Billet selon la revendication 2, caractérisé en ce que ledit ensemble de caractères alphanumériques comporte au moins : - un nombre déterminé de digits fonction de ladite contre-valeur monétaire attribuée audit numéro unique, lesdits digits étant représentatifs d'un nombre unique lié à ladite contre-valeur monétaire ; un nombre déterminé de caractères alphanumériques, inférieur au nombre de digits, au moins un caractère alphanumérique étant inséré entre deux digits .
4. Billet selon la revendication 3, caractérisé en ce que lesdits caractères alphanumériques sont insérés à des emplacements de position aléatoire entre deux digits successifs.
5. Billet selon l'une des revendications précédentes, caractérisé en ce que celui-ci comprend en outre un champ auxiliaire représentatif de l'entité d'émission et du pays hôte de cette entité d'émission.
6. Billet selon l'une des revendications précédentes, caractérisé en ce que celui-ci comprend en outre un champ auxiliaire représentatif de la durée de validité dudit billet.
7. Billet selon l'une des revendications précédentes, caractérisé en ce que ledit billet comprend en outre un champ auxiliaire représentatif de la valeur faciale dudit billet.
8. Billet selon l'une des revendications précédentes, caractérisé en ce que le champ représentatif dudit numéro unique est constitué par une valeur chiffrée à partir d'une pluralité de variables comprenant au moins ledit numéro unique, l'entité d'émission, la valeur faciale et l'unité monétaire de compte, ce qui permet, à partir d'une opération de déchiffrement, d'effectuer toute opération d' authentification et de non répudiation dudit billet par ladite entité d'émission.
9. Billet selon l'une des revendications 1 à 8, caractérisé en ce que ladite valeur faciale du billet est une valeur dédiée, établie à la demande d'un utilisateur par ladite entité d'émission.
10. Billet selon l'une des revendications 8 ou 9, caractérisé en ce que ladite pluralité de variables comprend en outre l'adresse électronique du terminal créancier, destinataire de ce billet électronique en exécution d'une transaction, ce qui permet, d'une part, de justifier de la possession dudit billet par ce terminal créancier et ce destinataire suite à une validation de cette transaction, et, d'autre part, d'assurer un échange sécurisé d'un même billet électronique au cours de transactions successives par simple remplacement dans ladite pluralité de variables de l'adresse électronique du terminal créancier destinataire de ce billet électronique.
11. Système serveur gestionnaire de transactions réalisées au moyen de billets électroniques de valeur fiduciaire selon les revendications 1 à 10, entre un acheteur et un vendeur, caractérisé en ce qu'il comporte au moins : des moyens de mémorisation d'un ensemble de vendeurs accrédités, habilités à conclure une ou plusieurs transactions au moyen desdits billets électroniques de valeur fiduciaire ; des moyens de mémorisation de listes de billets électroniques de valeur fiduciaire émis valides, respectivement invalides, pendant une durée de viduité ; - des moyens de contrôle et d' authentification d' accès- audit système serveur de tout vendeur accrédité en vue d'une opération de mise en recouvrement de billets électroniques de valeur fiduciaire échangés au cours d'au moins une transaction ; - des moyens de vérification de la validité du numéro unique de chaque billet électronique de valeur fiduciaire échangé à partir d'au moins une liste des billets électroniques de valeur fiduciaire électroniques émis valides ,- - des moyens de notification audit vendeur accrédité d'un message de validation de transaction entre ledit vendeur et un acheteur quelconque, permettant l'envoi audit vendeur d'un message de validation de transaction sur vérification positive de la validité du numéro unique de chaque billet électronique de valeur fiduciaire échangé.
12. Système selon la revendication 11, caractérisé en ce que celui-ci comporte en outre : des moyens de comptage du nombre d ' erreurs de vérification de la validité du numéro unique de chaque billet électronique de valeur fiduciaire échangé ; des moyens de comparaison du nombre d'erreurs de vérification de la validité dudit numéro unique à une valeur de seuil, lesdits moyens de comparaison pilotant lesdits moyens de notification et permettant l'envoi d'un message d'invalidation de transaction audit vendeur accrédité lorsque ce nombre d'erreurs de vérification est supérieur ou égal à ladite valeur de seuil .
13. Protocole de paiement d'achats de produits ou de services par commerce électronique entre un terminal client et un terminal vendeur de produits ou services, le terminal client étant détenteur de billets électroniques de valeur fiduciaire selon l'une des revendications 1 à 10, distribués par un organisme serveur spécifique, entité d'émission, et mémorisés dans ce terminal client, le terminal vendeur étant géré et contrôlé par un vendeur agréé auprès dudit organisme serveur spécifique, caractérisé en ce que, lors de la conduite d'un accord d'achat/vente de produits ou services pour un prix déterminé, ce protocole consiste au moins : a) à transmettre à titre de paiement de transaction du terminal client au terminal vendeur un ensemble de billets électroniques dont la somme de la valeur faciale couvre le prix d'achat déterminé ; b) à transmettre dudit terminal vendeur audit organisme serveur spécifique ledit ensemble de billets électroniques support de ladite transaction pour authentification par vérification de la validité du numéro unique de ces billets électroniques, et, sur procédure d' authentification réussie, à chaque billet électronique de cet ensemble de billets électroniques support de ladite transaction étant reconnue la valeur faciale qui lui est dévolue, c) à transmettre dudit organisme serveur spécifique audit terminal vendeur un message de validation de paiement, d) à invalider au moins, au niveau dudit organisme serveur spécifique, tout billet électronique de cet ensemble de billets électroniques support de cette transaction pendant un délai de viduité, et, sur procédure d' authentification non réussie, e) à transmettre dudit organisme serveur spécifique audit terminal vendeur un message d'invalidation de paiement et de non validation de la transaction.
14. Protocole selon la revendication 13, caractérisé en ce que, suite à l'étape a) consistant à transmettre à titre de paiement de transaction un ensemble de billets électroniques support de la transaction, celui- ci consiste à inhiber, au moins temporairement, au niveau dudit terminal client, l'utilisation par ce terminal client de tout billet électronique appartenant à cet ensemble de billets électroniques support de cette transaction, ladite inhibition temporaire étant maintenue au moins jusqu'à l'invalidation, au moins au niveau dudit serveur spécifique, de tout billet électronique de cet ensemble de billets électroniques pendant le délai de viduité sur procédure d' authentification réussie.
15. Protocole selon les revendications 13 et 14, caractérisé en ce que, suite à l'étape c) consistant à transmettre dudit organisme serveur spécifique audit terminal vendeur agréé un message de validation de paiement, celui-ci consiste en outre : à transmettre dudit terminal vendeur agréé audit terminal client un message d'accusé de réception de paiement de transaction, et, sur réception dudit message d'accusé de réception de paiement par ledit terminal client, à effacer dans ledit terminal client chaque billet électronique de cet ensemble de billets électroniques objet de ladite transaction.
16. Protocole selon l'une des revendications 13 à 15, caractérisé en ce que, suite à l'étape c) consistant à transmettre dudit organisme serveur spécifique audit terminal vendeur un message de validation de paiement, celui-ci consiste en outre, à l'initiative du vendeur agréé utilisateur dudit terminal vendeur : - à transmettre dudit terminal vendeur audit organisme serveur spécifique une requête d'accréditation de compte bancaire au nom dudit vendeur agréé pour un montant correspondant au paiement de ladite transaction, et, sur acceptation de ladite requête et renvoi d'un accusé de réception et de validation de ladite requête audit terminal vendeur agréé, à effacer, au niveau du terminal vendeur agréé, tout billet électronique de cet ensemble de billets électroniques objet de la transaction ayant fait l'objet d'une mise en recouvrement.
17. Protocole selon l'une des revendications 13 à
16, caractérisé en ce que, pour une somme de la valeur faciale transmise supérieure audit prix d'achat, celui-ci comprend en outre une procédure de rendu de monnaie en unité monétaire de compte.
18. Protocole selon la revendication 17, caractérisé en ce que, suite à l'étape a) de transmission à titre de paiement de transaction de ladite somme de valeur faciale transmise, ladite procédure de rendu de monnaie consiste au moins : b' ) à transmettre dudit terminal vendeur audit organisme serveur spécifique ledit ensemble de billets électroniques support de ladite transaction et ledit prix d'achat pour authentification, et, sur procédure d' authentification réussie, à chaque billet électronique de cet ensemble de billets électroniques support de ladite transaction étant reconnue la valeur faciale qui lui est dévolue ; c') à transmettre dudit organisme serveur spécifique audit terminal vendeur un message de validation de paiement et un sous-ensemble de billets électroniques dont la somme de la valeur faciale couvre la différence entre ladite somme de valeur faciale transmise et ledit prix d'achat, et e'1) à transmettre dudit terminal vendeur audit terminal client ledit sous ensemble de billets électroniques au titre de monnaie rendue.
19. Protocole selon la revendication 18, caractérisé en ce que à l'étape consistant à transmettre dudit terminal vendeur au terminal client ledit sous ensemble de billets électroniques au titre de monnaie rendue est associée une étape d'effacement, dans ledit terminal vendeur, de chaque billet électronique dudit sous ensemble de billets électroniques au titre de monnaie rendue .
PCT/FR2001/001912 2000-09-15 2001-06-19 Billet electronique de valeur fiduciaire, protocole de paiement d'achats par commerce electronique et systeme serveur correspondant WO2002023497A1 (fr)

Priority Applications (1)

Application Number Priority Date Filing Date Title
AU2001269192A AU2001269192A1 (en) 2000-09-15 2001-06-19 Electronic note of fiduciary value, protocol for payment of electronic commerce purchases and corresponding server system

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR0011828A FR2814261B1 (fr) 2000-09-15 2000-09-15 Billet electronique de valeur fiduciaire, protocole de paiement d'achats par commerce electronique et systeme serveur correspondant
FR00/11828 2000-09-15

Publications (1)

Publication Number Publication Date
WO2002023497A1 true WO2002023497A1 (fr) 2002-03-21

Family

ID=8854371

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/FR2001/001912 WO2002023497A1 (fr) 2000-09-15 2001-06-19 Billet electronique de valeur fiduciaire, protocole de paiement d'achats par commerce electronique et systeme serveur correspondant

Country Status (3)

Country Link
AU (1) AU2001269192A1 (fr)
FR (1) FR2814261B1 (fr)
WO (1) WO2002023497A1 (fr)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN114514124A (zh) * 2019-09-30 2022-05-17 德国捷德进步52有限公司 卡和用于制造卡的方法

Citations (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
FR2605429A2 (fr) * 1982-06-08 1988-04-22 Grafeille Jean Marie Procede de controle de l'usage d'un document et documents pour sa mise en oeuvre
EP0574990A2 (fr) * 1992-06-17 1993-12-22 Philips Patentverwaltung GmbH Procédé et agencement de circuit pour tester une carte de crédit
EP0788066A2 (fr) * 1991-11-15 1997-08-06 Citibank, N.A. Système monétaire électronique
GB2317790A (en) * 1996-09-26 1998-04-01 Richard Billingsley Electronic money transactions
WO1998022915A1 (fr) * 1996-11-20 1998-05-28 British Telecommunications Public Limited Company Systeme de transaction
EP0865010A1 (fr) * 1997-03-13 1998-09-16 France Telecom Systéme de paiement électronique sécurisé et procédé de mise en oeuvre
WO1998043211A1 (fr) * 1997-03-26 1998-10-01 British Telecommunications Public Limited Company Systeme transactionnel
WO1998044429A1 (fr) * 1997-04-01 1998-10-08 Cardis Enterprise International N.V. Systeme et procede monetaires electroniques denombrables
US5872844A (en) * 1996-11-18 1999-02-16 Microsoft Corporation System and method for detecting fraudulent expenditure of transferable electronic assets
US5999625A (en) * 1997-02-27 1999-12-07 International Business Machines Corporation Method for electronic payment system with issuer control

Patent Citations (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
FR2605429A2 (fr) * 1982-06-08 1988-04-22 Grafeille Jean Marie Procede de controle de l'usage d'un document et documents pour sa mise en oeuvre
EP0788066A2 (fr) * 1991-11-15 1997-08-06 Citibank, N.A. Système monétaire électronique
EP0574990A2 (fr) * 1992-06-17 1993-12-22 Philips Patentverwaltung GmbH Procédé et agencement de circuit pour tester une carte de crédit
GB2317790A (en) * 1996-09-26 1998-04-01 Richard Billingsley Electronic money transactions
US5872844A (en) * 1996-11-18 1999-02-16 Microsoft Corporation System and method for detecting fraudulent expenditure of transferable electronic assets
WO1998022915A1 (fr) * 1996-11-20 1998-05-28 British Telecommunications Public Limited Company Systeme de transaction
US5999625A (en) * 1997-02-27 1999-12-07 International Business Machines Corporation Method for electronic payment system with issuer control
EP0865010A1 (fr) * 1997-03-13 1998-09-16 France Telecom Systéme de paiement électronique sécurisé et procédé de mise en oeuvre
WO1998043211A1 (fr) * 1997-03-26 1998-10-01 British Telecommunications Public Limited Company Systeme transactionnel
WO1998044429A1 (fr) * 1997-04-01 1998-10-08 Cardis Enterprise International N.V. Systeme et procede monetaires electroniques denombrables

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN114514124A (zh) * 2019-09-30 2022-05-17 德国捷德进步52有限公司 卡和用于制造卡的方法

Also Published As

Publication number Publication date
FR2814261B1 (fr) 2003-01-24
AU2001269192A1 (en) 2002-03-26
FR2814261A1 (fr) 2002-03-22

Similar Documents

Publication Publication Date Title
US5956699A (en) System for secured credit card transactions on the internet
US6119229A (en) Virtual property system
WO2002005152A1 (fr) Systeme et procede de gestion de transactions de micropaiement, terminal de client et equipement de marchand correspondants
CA2398317A1 (fr) Systeme et procede de securisation des transmissions d'informations
EP1451783B1 (fr) Procede, systeme et dispositif permettant d'authentifier des donnees transmises et/ou recues par un utilisateur
EP1323140B1 (fr) Procede pour fournir des donnees d'identification d'une carte de paiement a un usager
EP1354288B1 (fr) Procede utilisant les cartes de paiement electroniques pour securiser les transactions
WO2002023497A1 (fr) Billet electronique de valeur fiduciaire, protocole de paiement d'achats par commerce electronique et systeme serveur correspondant
FR2810759A1 (fr) Procede pour effectuer une transaction commerciale en ligne par l'intermediaire d'un reseau de communication et dispositif electronique pour passer des commandes commerciales en ligne
EP1415283A2 (fr) Procede et systeme permettant de garantir formellement un paiement, en mettant en oeuvre un telephone portable
FR2823882A1 (fr) Procede et systeme de validation de paiement
FR2914763A1 (fr) Cryptogramme dynamique
WO2002005226A1 (fr) Systeme et procede de gestion de transaction de micropaiement dispositifs client, marchand et intermediaire financier
WO2022096841A1 (fr) Procede d'authentification securise par le decouplage structurel des identifiants personnels et de services
EP4074005A1 (fr) Procede, serveur et systeme d'authentification de transaction utilisant deux canaux de communication
FR2828966A1 (fr) Procede pour communiquer de facon securisee des donnees d'identification d'une carte de paiement
AU721052C (en) Virtual property system
CA2285642A1 (fr) Procede de certification d'un cumul dans un lecteur
FR2808144A1 (fr) Procede et systeme de paiement electronique
FR2750275A1 (fr) Procede de gestion dans un systeme telematique distribue et systeme de mise en oeuvre de ce procede
EP2133847A1 (fr) Procédé et système pour contrôler l'accès à des sites ou contenus, tels que des jeux en ligne, et supports de contrôle d'accès pour la mise en oeuvre de ce procédé
FR2804229A1 (fr) Procede d'identification et de paiement

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A1

Designated state(s): AE AG AL AM AT AU AZ BA BB BG BR BY BZ CA CH CN CO CR CU CZ DE DK DM DZ EC EE ES FI GB GD GE GH GM HR HU ID IL IN IS JP KE KG KP KR KZ LC LK LR LS LT LU LV MA MD MG MK MN MW MX MZ NO NZ PL PT RO RU SD SE SG SI SK SL TJ TM TR TT TZ UA UG US UZ VN YU ZA ZW

AL Designated countries for regional patents

Kind code of ref document: A1

Designated state(s): GH GM KE LS MW MZ SD SL SZ TZ UG ZW AM AZ BY KG KZ MD RU TJ TM AT BE CH CY DE DK ES FI FR GB GR IE IT LU MC NL PT SE TR BF BJ CF CG CI CM GA GN GW ML MR NE SN TD TG

DFPE Request for preliminary examination filed prior to expiration of 19th month from priority date (pct application filed before 20040101)
121 Ep: the epo has been informed by wipo that ep was designated in this application
REG Reference to national code

Ref country code: DE

Ref legal event code: 8642

122 Ep: pct application non-entry in european phase
NENP Non-entry into the national phase

Ref country code: JP