WO2013054058A1 - Procede de realisation d'une transaction electronique - Google Patents

Procede de realisation d'une transaction electronique Download PDF

Info

Publication number
WO2013054058A1
WO2013054058A1 PCT/FR2012/052328 FR2012052328W WO2013054058A1 WO 2013054058 A1 WO2013054058 A1 WO 2013054058A1 FR 2012052328 W FR2012052328 W FR 2012052328W WO 2013054058 A1 WO2013054058 A1 WO 2013054058A1
Authority
WO
WIPO (PCT)
Prior art keywords
terminal
server
transaction
electronic transaction
electronic
Prior art date
Application number
PCT/FR2012/052328
Other languages
English (en)
Inventor
Julien DAUPHANT
Antoine SAKHO
Valentin LAUTIER
Original Assignee
Skimm!
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 Skimm! filed Critical Skimm!
Publication of WO2013054058A1 publication Critical patent/WO2013054058A1/fr

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/32—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using wireless devices
    • G06Q20/327—Short range or proximity payments by means of M-devices
    • G06Q20/3276—Short range or proximity payments by means of M-devices using a pictured code, e.g. barcode or QR-code, being read by the M-device
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/32—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using wireless devices
    • G06Q20/326—Payment applications installed on the mobile devices
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/385—Payment protocols; Details thereof using an alias or single-use codes
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/40—Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check credit lines or negative lists
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/40—Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check credit lines or negative lists
    • G06Q20/401—Transaction verification
    • G06Q20/4012—Verifying personal identification numbers [PIN]

Definitions

  • the present invention relates to a method for performing an electronic transaction of a service.
  • a method of performing a transaction of a service uses bank cards and payment terminals to perform the transactions. .
  • a disadvantage of this state of the art is that in many countries, bank cards used do not need to enter a personal identification number, commonly called PIN, to validate the transaction, either because the credit card does not include chip to implement the functionality of the PIN either because the payment terminal used does not offer this feature. Only the magnetic tape is used. In this case, a signature of the cardholder is sufficient, which leads to many cases of fraud. Also, transactions are not secure.
  • PIN personal identification number
  • the present invention aims at a method of performing an electronic transaction of a service between a server, a first terminal and a second terminal, which makes it possible to carry out secure electronic transactions, especially for users who do not carry secure bank cards. .
  • This object is achieved by a method of performing an electronic transaction of a service between a server, a first terminal and a second terminal, the method comprising the steps of:
  • the url of the transaction code includes the identifier of said transaction.
  • the method may further comprise one or more additional characteristics among the following:
  • the method further comprising the additional steps of:
  • the method further comprises an additional step of crediting the transaction amount with a first vendor electronic money account linked to the first terminal and debiting from the transaction amount a second buyer electronic money account linked to the second terminal.
  • the method further comprises an additional step of transmitting from the server a transaction order corresponding to the electronic transaction validated in the server to appropriate bank servers for managing accounts to be credited and debited relating to said electronic transaction.
  • the generated transaction code is a QR-Code®.
  • the first terminal is:
  • the first information received by the first terminal includes an identifier of the electronic transaction.
  • the first information received by the first terminal further comprises:
  • the invention also relates to a first terminal adapted to cooperate with at least one server and at least one second terminal for implementing the method of performing an electronic transaction according to any one of the preceding features, said first terminal comprising a first processor suitable for:
  • the invention also relates to a payment server of a service adapted to cooperate with at least a first terminal and at least a second terminal for implementing the method of performing an electronic transaction according to any one of the preceding features, said server comprising a second processor adapted for:
  • the second processor is further adapted to credit the transaction amount a first seller electronic money account linked to the first terminal and to debit the transaction amount a second buyer electronic money account linked to the first transaction. second terminal.
  • the second processor is further adapted to transmit a transaction order corresponding to the electronic transaction validated in the server to appropriate bank servers for managing accounts to be credited and debited relating to said electronic transaction.
  • the invention also relates to a second terminal adapted to cooperate with at least one server and at least one first terminal for implementing the method of performing an electronic transaction according to any one of the preceding characteristics, said first terminal comprising a third processor suitable for:
  • the invention also relates to a system for performing an electronic transaction of a service between a server, a first terminal and a second terminal, the system comprising:
  • - Fig.1 is a first flowchart of the method of performing an electronic transaction according to the invention according to a first non-limiting embodiment
  • FIG. 2 is a second flowchart of the method for performing an electronic transaction of FIG. 1 illustrating additional steps;
  • FIG. 3 is a diagram showing the steps of the method of FIG. 1 performed by a first terminal, a second terminal and a server;
  • FIG. 4 is a schematic representation of a system for carrying out an electronic transaction according to an embodiment for implementing the method of carrying out an electronic transaction of FIG. 1.
  • Service S means the purchase of goods such as a product, an application, a ticket, or a discount coupon in non-limiting examples.
  • the method of performing an electronic transaction MTH between a server Sk, a first terminal Tm and a second terminal Tu comprises the following steps, as illustrated in FIG. 1.
  • QR-C transaction code comprising an identifier Id of said electronic transaction Tr (step illustrated GENERAT_QRC (ld));
  • step RX_TR PIN, IVAL
  • the process further comprises the additional steps of:
  • Tu terminal illustrated step SCAN (QR-C)
  • step illustrated RX_TR I2, QR-C
  • step TX_TR PIN, IVAL
  • the method further comprises an additional step of crediting the amount Mt of the transaction with a first seller's electronic money account Cpt1 linked to the first terminal Tm and debiting from the amount Mt of the transaction a second account of Cpt2 buyer electronic money linked to the second terminal Tu (illustrated step CRED_DEB (Mt, Cpt1, Cpt2).
  • the method further comprises an additional step of transmitting from the server Sk a transaction order corresponding to the electronic transaction saved in the server Sk to bank servers Sbq adapted for managing accounts to be credited and debited relating to said electronic transaction Tr (illustrated step OT_CRED_DEB (Mt, Cpt1 ⁇ Cpt2 ')).
  • the method comprises these non-limiting embodiments.
  • the method of performing an electronic transaction is triggered as follows.
  • the method of performing an electronic transaction is triggered by a manual entry on the first terminal Tm of a transaction amount Mt and a manual support on means for selecting the method for producing a transaction.
  • an electronic transaction such as for example a button.
  • This first mode is realized for example in the case where the first terminal Tm is a portable tablet.
  • the method of performing an electronic transaction is triggered by an automatic entry on the first terminal Tm of a transaction amount Mt and a manual support on means for selecting the method for producing a transaction.
  • an electronic transaction such as for example a button.
  • This first mode is realized for example in the case where the first terminal Tm is a cash register or automatic cash register (automated control terminal).
  • the automatic entry of the amount of the transaction is for example by scanning the bar code where is indicated the price of the service S.
  • the method of performing a transaction is triggered by the validation on the internet (through a web page) of the purchase of the service S.
  • the user can thus connect to the application corresponding to the payment method via a first terminal Tm which is for example a personal computer.
  • a token (called token) is created by the server Sk. This token makes it possible to open a session between the first terminal Tm and the server Sk;
  • the first terminal Tm authenticates to the server Sk.
  • the authentication is performed by means of a private key and an identifier associated with the first terminal. This embodiment is applied when the first terminal Tm is a cash register or automatic pay station (automated control terminal) for example.
  • the authentication is performed using the name of the selling user owner of the first terminal Tm and its password. This embodiment is applied when the first terminal Tm is a portable tablet for example. Note that a session is open for a sales user. One could also have a session for each first terminal Tm.
  • the first terminal Tm connects to the server Sk to communicate with it and will use the token issued for all of its communications with said server Sk.
  • timeout when a timeout ("timeout" in English) is exceeded because no transaction has been made since the last, for example for twenty minutes;
  • a first step 1) (illustrated step TX_CREAT (TR))
  • the first terminal Tm sends to the server Sk the electronic transaction creation request Tr corresponding to a requested service S
  • the server Sk receives from the first terminal Tm the request for electronic transaction creation Tr corresponding to a requested service S (step n)
  • the first terminal Tm is:
  • the first terminal may also be a workstation. (through a dedicated program on the computer or a web service);
  • a second step 2) (illustrated step SAV_TR (I1)), the server Sk saves the first information 11 of said electronic transaction Tr.
  • the first information received by the first terminal Tm comprises an identifier Id of the electronic transaction Tr. This identifier will enable the first terminal Tm to ask the server Sk to generate a QR-C transaction code. as described later.
  • the first information 11 further comprises:
  • a state St of the electronic transaction This status can include the values "in progress”, “canceled”, “validated”.
  • the state takes the value "in progress”;
  • the type may include the following indications:
  • the type is thus used during a reading of the transaction history by the owner of the first terminal Tm and / or the owner of the second terminal Tu.
  • a description Ds of the electronic transaction For example, as a description we can have "payment of 10 euros from Mr X to the merchant Y". This field is also used when reading the transaction history;
  • a date Dt of creation This field is also used when reading the transaction history. It is also compared to a current date. Thus, if the creation date is earlier than a certain time in relation to the current date, and the transaction has been waiting since that time, it can not be validated anymore because it is considered too old.
  • the following additional information 11 'of the transaction is saved in the server Sk:
  • This unique fingerprint includes codified information on the transaction to limit data loss, such as the type of the transaction, the identifier of the debtor;
  • This field makes it possible to ask the server Sk for information on a debtor who owns the debtor account (last name) and also allows to have a better traceability and to make data analysis (frequency of purchase, average basket, etc. of the user). It should be noted that this field is also present in an electronic money account described below; - an identifier of an account to be credited ld_Cc (e-money account, virtual bank account, virtual credit card account);
  • ld_Cd an identifier of an account to be debited ld_Cd (electronic money account, virtual bank account, virtual credit card account);
  • a third step 3) (illustrated step TX_TR (I1)), the server Sk sends the first terminal Tm first information 11 on said electronic transaction Tr and the first terminal Tm receives the first information 11 on said electronic transaction Tr sent by the Sk server (step 3 ').
  • step 4 step illustrated GENERAT_QRC (ld)
  • the server Sk generates a QR-C transaction code comprising an identifier Id of said electronic transaction Tr.
  • the QR-C transaction code is generated on the fly, namely whenever a transaction is created. It does not need to be saved in the Sk server. However, it can be saved in the second terminal Tu.
  • the QR-C transaction code is generated on request Rq of the first terminal Tm which has requested a transaction creation Tr.
  • the request Rq of the first terminal Tm comprises the identifier Id of the transaction Tr Note that in this case, the QR-C transaction code is generated if an electronic transaction is in a "running" state.
  • the QR-C transaction code is automatically generated by the server Sk, as soon as receipt of a transaction creation request Tr.
  • the step of generating the code is performed before step 2) of receiving the first information 11 by the first terminal Tm, and the first information comprises the code generated QR-C, the latter being thus sent in this information 11, or it is sent at the same time.
  • the transaction ID Id is still needed in the information 11 sent because of the notification in the confirmation step described below.
  • the generated transaction code is a QR-Code®. It has an url of the type https: // url corresponding to the payment / transactions / ld method. This url is recognized by the second terminal Tu (by scanning the transaction code) if the latter can use the method of performing an electronic transaction MTH. Otherwise, when the transaction code is scanned, but the process of performing an electronic transaction is not known, a web page corresponding to the URL is displayed and explains how to install the product computer program corresponding to the method of performing an electronic transaction on the second terminal Tu on said second terminal Tu.
  • the generation of the transaction code is done by means of a code generation library.
  • the generated transaction code is:
  • step 5 step illustrated TX_QRC
  • Step 5 ' sends the QR-C transaction code to the first terminal Tm and the first terminal Tm receives the QR-C transaction code generated by the server Sk (step 5 ').
  • this step can be performed at the same time as the third step 3) sending the first information 11 when the code is generated automatically by the server Sk.
  • the information 11 of the third step include generated code QR-C.
  • a second terminal Tu scans said QR-C transaction code.
  • the QR-C transaction code is scanned on the screen of the first terminal Tm.
  • a second terminal Tu is a mobile phone or a portable tablet.
  • the second terminal Tu comprises means for scanning this QR-C transaction code, namely in particular a camera.
  • the second terminal Tu scans the QR-C transaction code, it recognizes the url contained in said code because it contains the application corresponding to the payment method. At this time, the following steps are performed:
  • the second terminal Tu connects to the server Sk to communicate with him;
  • the second terminal You send a request to the server Sk for the issue of a token.
  • the server Sk issues a token that allows to open a session between the second terminal Tu and the server Sk. Note that a token is issued for each second terminal Tu. We have one session per terminal. Thus, the same buyer can use several second terminals to perform his electronic transactions. There will therefore be a plurality of chips. Each second terminal You will use the issued token for all its communications with said server Sk.
  • a web page of the application is displayed on the screen of the second terminal Tu and explains the installation procedures of the application corresponding to the payment method.
  • a web page of the application is displayed on the screen of the second terminal which makes it possible to carry out an electronic transaction directly.
  • the web page then contains the information on the transaction: name of the merchant, image (logo), amount Mt, field to connect with the electronic money account by authenticating with the username and password for the account, or via the social network account, and finally by entering the PIN code. Subsequently a payment confirmation message is returned.
  • timeout when a timeout ("timeout" in English) is exceeded because no transaction has been made since the last, for example for twenty minutes;
  • a seventh step 7 (illustrated step TX_TR (I2, QR-C)), the server Sk sends to the second terminal Tu second information 12 of said electronic transaction from the scanned transaction code QR-C and the second terminal Tu receives the second information 12 of said electronic transaction from the scanned transaction code QR-C sent by the server Sk (step 7 ').
  • the server Sk With the identifier ID of the electronic transaction in the QR-C transaction code, the server Sk will retrieve the information of said transaction that has been previously saved in a data repository of said server Sk.
  • the second information 12 of the electronic transaction is then displayed on the screen of the second terminal Tu.
  • the second information 12 includes the first information 11 plus the seller's name and an associated image (logo).
  • step 8 (illustrated step TX_TR (PIN, IVAL)), the second terminal Tu sends to the server Sk a personal identification number PIN and an IVAL validation information of the electronic transaction Tr and the server Sk receives from the second terminal You have the personal identification number PIN and the IVAL validation information of the electronic transaction (step 8 ').
  • the user of the second terminal Tu (the person who thus purchases the service S) has verified on the screen of his terminal the information of the electronic transaction and in particular the amount Mt, he enters his PIN and presses for example on a button on his terminal to indicate to the server that he has verified the transaction and that he agrees with the transaction.
  • a "valid" IVAL1 information is sent.
  • the transaction is validated and secured. If he does not want to validate the transaction, another button is used for example.
  • Invalid IVAL2 information is sent.
  • a ninth step 9 step illustrated TX_CONF (Conf)
  • the server Sk sends an electronic transaction confirmation to the first terminal Tm and the second terminal Tu and the first terminal Tm and the second terminal Tu receive the confirmation Conf of electronic transaction Tr sent from the server Sk (step 9 ').
  • the value of the status is set to "canceled".
  • the confirmation is a notification sent by the server Sk comprising the identifier Id of the transaction Tr.
  • the notification protocol APN (Apple TM Push Notifications"). ") is used.
  • the Android TM C2DN notification protocol can be used or any other proprietary notification protocol.
  • the first terminal Tm compares the identifier received in the notification with the identifiers of the transactions it has created to check whether the desired transaction is validated.
  • a second terminal Tu accepts the transaction (when the buyer user has validated the transaction) and receives a confirmation message of its acceptance from the server Sk.
  • confirmation can also be done for example by longpolling, shortpolling and / or any other method of notification based on open source or proprietary protocols.
  • the server Sk credits from the amount Mt of the transaction a first electronic money account seller Cpt1 linked to the first terminal Tm and debits the amount Mt of the transaction a second user electronic money account Cpt2 linked to the second terminal Tu.
  • the association between an electronic money account seller CPt1 and a first terminal Tm is done during a creation of a user profile Upf seller 1 in the server Sk.
  • Associated electronic money accounts are then created and are linked with the profile by their identifiers, an account that does not change ownership.
  • a user profile Upf seller 1 includes the following information:
  • association between a buyer's electronic money account Cpt2 and a second terminal Tu is done during a creation of a user profile Upf2 buyer in the server Sk.
  • An associated electronic money account is then created and is connected with the profile by its identifier, an account that does not change ownership.
  • a user user profile Upf2 includes the following information:
  • a password for the application corresponding to the method of performing an electronic transaction corresponding to the method of performing an electronic transaction. Note that if a social network is used, the social network password will be used to start the process.
  • the identifier attributes of a virtual account of a bank account and identifier of a virtual bank card account enables a user of the second terminal Tu to recharge his e-money account from a virtual card account.
  • bank declared in the Sk server or bank account declared in the server Sk and therefore to credit / debit virtually his credit card and bank account and have a reflection of his debits / credits through virtual credit card accounts bank account on the Sk server. Following the credits / virtual debits are of course transcribed on the real bank accounts and bank cards of the user.
  • a first seller electronic money account Cpt1 is created by an administrator of the payment server Sk.
  • a first seller account Cpt1 is created and associated with the user profile Upf seller 1 and comprises in a non-limiting embodiment the following information:
  • a second electronic money buyer account Cpt2 is created by the buyer himself when he creates his user profile Upf2 from the url of the application corresponding to the payment method.
  • the creation of the user profile is done by entering the data manually or by retrieving it from a user's page on a social network.
  • a second buyer account Cpt2 is created and associated with the user profile Upf2 buyer and comprises in a non-limiting embodiment the following information:
  • the server cooperates with means of secure payment over the Internet.
  • These means are either internal or external to the payment server Sk.
  • the means are, for example, third-party servers Str that belong to third-party organizations authorized to manage electronic money, namely to validate the management of electronic currency accounts and transactions. The transactions validated by these organizations are authentic.
  • the servers of an organization such as Leetchi TM are in a non-limiting example used.
  • the first and second terminals comprise for this purpose an internet access by which the seller and / or the buyer can enter his credit card number or accept a credit card recharge.
  • an authorized electronic money account Cpt1 'corresponding to the first account Cpt1 and an authorized electronic money account Cpt2' corresponding to the second account Cpt2 are automatically created on the third servers Str.
  • the server when crediting or debiting an electronic account Cpt1, Cpt2, the server cooperates with these means of secure payment by internet.
  • Such accounts Cpt1 'and Cpt2' include in a non-limiting embodiment the following information: - Account identifier;
  • - Type defines membership in a third party organization
  • the server Sk comprises a single electronic money account Cpt2 assigned to a user of a second terminal Tu.
  • the server Sk comprises either a single electronic money account Cpt1 for a seller who has a first terminal Tm or an electronic money account Cpt1 for each first terminal Tm that the seller owns.
  • the server Sk saves the bank details (IBAN) of the seller. For the buyer, this is optional. Indeed, the buyer has the opportunity to enter his IBAN in the server Sk to withdraw his electronic money from his electronic account, but this use is not common.
  • IBAN bank details
  • step 11 the server Sk transmits a transaction order Ot corresponding to the electronic transaction validated in the server sk to Sbq banking servers adapted to manage accounts to be credited and to debit relating to said electronic transaction Tr.
  • transaction orders Ot are issued periodically between the server Sk and the bank servers Sbq.
  • orders are issued weekly.
  • the seller can transfer the money collected on his e-money account to his bank account.
  • a transaction code for an electronic transaction Tr is performed using the protocol https ("HyperText Transfer Protocol Secured") based on a secure exchange protocol on the Internet for example TLS ("Transport Layer Security”) ).
  • HTTP HyperText Transfer Protocol Secured
  • TLS Transport Layer Security
  • An electronic transaction can be carried out between a mobile phone user and a merchant with a cash register or automatic pay station (automated control post) or a portable tablet, or between two users of mobile phones, or between two users portable tablets etc.
  • the method of performing an electronic transaction between a server Sk, a first terminal Tm and a second terminal Tu is implemented by a system for performing an electronic transaction of a service S between a server Sk, a first terminal Tm and a second terminal Tu illustrated in FIG. 4.
  • the SYS system includes:
  • At least one first terminal Tm comprising a first processor UC1 adapted to:
  • the server Sk comprising a second processor UC2 adapted to:
  • At least one second terminal Tu comprising a third processor UC3 adapted to:
  • the second processor UC2 of the server Sk is further adapted to credit the amount Mt of the transaction a first seller's electronic money account Cpt1 linked to first terminal Tm and debiting the amount Mt of the transaction a second electronic money account buyer Cpt2 linked to the second terminal Tu.
  • the second processor UC2 of the server Sk is further adapted to transmit from the server Sk a transaction order Ot corresponding to the electronic transaction validated in the server Sk to bank servers Sbq adapted to manage accounts to be credited and debited with respect to said electronic transaction Tr.
  • the server Sk comprises a data repository Bdd, illustrated in FIG. 4 in which:
  • the database Bdd includes an electronic money account associated at least with each user (buyer, seller), and where appropriate with each first terminal Tm, the application implementing the method of performing a transaction described.
  • the data repository Bdd comprises:
  • Obj objects related to the transaction can be performed by means of a programmed micro device "software", of wired logic and / or hardware electronic components.
  • the system for performing a SYS electronic transaction may comprise one or more computer program products. comprising one or more sequences of instructions executable by an information processing unit such as a microprocessor, or a processing unit of a microcontroller, an ASIC, a computer etc., the execution said instruction sequences for implementing the described method.
  • an information processing unit such as a microprocessor, or a processing unit of a microcontroller, an ASIC, a computer etc.
  • Such a computer program can be written in ROM type writable nonvolatile memory or EEPROM or FLASH type rewritable non-volatile memory.
  • the said computer program can be registered in the factory or loaded into memory or downloaded remotely in memory.
  • the instruction sequences can be sequences of machine instructions, or sequences of a control language interpreted by the processing unit at the time of their execution.
  • a first computer program PG1 is written in a memory of the first terminal Tm
  • a second computer program PG2 is written in a memory of the payment server Sk
  • a third computer program PG3 is written in a memory of the second terminal Tu.
  • the first computer program product PG1 comprises one or more instruction sequences executable by an information processing unit, the execution of said instruction sequences allowing implementation of the steps of the payment method, when it is loaded on a computer, previously described steps performed by the first terminal T.
  • the second computer program product PG2 comprises one or more instruction sequences executable by an information processing unit, the execution of said instruction sequences enabling implementation of the steps of the payment method, when it is loaded on a computer, previously described steps performed by the server Sk.
  • the third computer program product PG3 comprises one or more instruction sequences executable by an information processing unit, the execution of said instruction sequences enabling implementation of the steps of the payment method, when it is loaded on a computer, previously described steps performed by the second terminal Tu.
  • the method of performing an electronic transaction can be used as part of a purchase of a service that takes into account discount coupons or ticket / prepaid ticket.
  • the sending / receiving of a request for the creation of a transaction, information, an order Ot, a transaction code relating to an electronic transaction Tr can occur. perform using other protocols such as Remote Procedure Call (RPC), Common Object Request Broker Architecture (CORBA), or proprietary TCP-based protocol. These protocols being well known to those skilled in the art, they are not described here.
  • the disclosed invention has the following advantages in particular: it enables electronic transactions to be dematerialized, that is to say without the use of bank cards and without conventional payment terminals, the electronic transaction being carried out between two terminals via a payment server;
  • second terminals such as commonly used mobiles
  • the transaction method according to the invention can be implemented by sending the personal identification code PIN of the second terminal Tu to the server Sk before the step of reception by the server of the first terminal of an electronic transaction creation request corresponding to a requested service; if this step is carried out correctly, the transmission of the PIN code becomes optional in the validation of the transaction Tr during a determined duration (typically several minutes, 10 minutes for example).
  • the method according to the invention then becomes a method of performing an electronic transaction of a service between a server, a first terminal and a second terminal, the method comprising the steps of:
  • the step of sending by the server Sk to the first terminal Tm of the transaction code QR- C then becomes a step of sending by the server Sk to the second terminal Tu of the transaction identifier Id and a url.
  • This sending can be done for example (and in a non-limiting manner) using one of the following technologies: Apple Push Notification, Android Cloud to Device Messaging, email, SMS, facebook message, longpolling, shortpolling and / or any other notification method based on opensource or proprietary protocols.
  • the method according to the invention then becomes a method of performing an electronic transaction of a service between a server, a first terminal and a second terminal, the method comprising the steps of:
  • the transaction information may contain the following elements associated with the first and / or second terminal: the IP address, the User Agent, the DNS address of the server Sk used, the token ...

Abstract

La présente invention concerne un procédé de réalisation d'une transaction électronique d'un service. Le procédé comportant les étapes de : - recevoir par un serveur d'un premier terminal une demande de création de transaction électronique correspondant à un service demandé; - sauvegarder dans le serveur des premières informations (I1) de ladite transaction électronique; - envoyer à partir du serveur au premier terminal les premières informations (I1) sur ladite transaction électronique; - générer par le serveur un code de transaction (QR-C) comprenant un identifiant (Id) de ladite transaction électronique; - envoyer par le serveur au premier terminal le code de transaction (QR-C); - scanner ledit code de transaction (QR-C) au moyen d'un deuxième terminal; - envoyer du serveur au deuxième terminal des secondes informations (I2) de ladite transaction électronique à partir du code de transaction scanné (QR-C); - recevoir par le serveur un numéro d'identification personnelle (PIN) et une information de validation (IVAL) de la transaction électronique envoyées par le deuxième terminal; - envoyer une confirmation de transaction électronique depuis le serveur vers le premier terminal et vers le deuxième terminal.

Description

PROCEDE DE REALISATION D'UNE TRANSACTION
ELECTRONIQUE
DOMAINE TECHNIQUE DE L'INVENTION
La présente invention concerne un procédé de réalisation d'une transaction électronique d'un service.
Elle trouve une application particulière, mais non limitative, dans le domaine des transactions électroniques dématérialisées.
AR R I È R E- P LAN TECH NOLOG I Q U E D E L' I NV ENTI ON Un procédé de réalisation d'une transaction d'un service, connu de l'homme du métier, utilise des cartes bancaires et des terminaux de paiement pour effectuer les transactions.
Un inconvénient de cet état de la technique est que dans de nombreux pays, les cartes bancaires utilisées ne nécessitent pas d'entrer un numéro d'identifiant personnel, couramment appelé PIN, pour valider la transaction, soit parce que la carte bancaire ne comporte pas de puce pour mettre en œuvre la fonctionnalité du PIN soit parce que le terminal de paiement utilisé ne propose pas cette fonctionnalité. Seule la bande magnétique est utilisée. Dans ce cas, une signature du porteur de la carte suffit, ce qui entraîne de nombreux cas de fraude. Aussi, les transactions ne sont pas sécurisées.
D ESC R I PTI ON G E N E RALE D E L' I NVE NTI ON
La présente invention a pour but un procédé de réalisation d'une transaction électronique d'un service entre un serveur, un premier terminal et un deuxième terminal, qui permette d'effectuer des transactions électroniques sécurisées notamment pour des utilisateurs non porteurs de cartes bancaires sécurisées. Ce but est atteint par un procédé de réalisation d'une transaction électronique d'un service entre un serveur, un premier terminal et un deuxième terminal, le procédé comportant les étapes de :
- recevoir par le serveur du premier terminal une demande de création de transaction électronique correspondant à un service demandé ;
- sauvegarder dans le serveur des premières informations de ladite transaction électronique ;
- envoyer à partir du serveur au premier terminal les premières informations sur ladite transaction électronique ;
- générer par le serveur un code de transaction comprenant un identifiant de ladite transaction électronique et une url ;
- envoyer par le serveur au premier terminal le code de transaction ;
- envoyer du serveur au deuxième terminal des secondes informations de ladite transaction électronique à partir du code de transaction scanné par le deuxième terminal, une page Web s'affichant sur l'écran dudit deuxième terminal lorsque ce dernier ne reconnaît pas ladite url ;
- recevoir par le serveur un numéro d'identification personnelle et une information de validation de la transaction électronique envoyées par le deuxième terminal ;
- envoyer une confirmation de transaction électronique depuis le serveur vers le premier terminal et vers le deuxième terminal.
Comme on va le voir en détail par la suite, le fait d'utiliser un terminal utilisateur avec un code d'identification permet d'obtenir des transactions électroniques sécurisées sans nécessiter de cartes bancaires.
On notera que, de manière préférentielle, l'url du code de transaction inclut l'identifiant de ladite transaction.
Selon des modes de réalisation non limitatifs, le procédé peut comporter en outre une ou plusieurs caractéristiques supplémentaires parmi les suivantes :
Le procédé comportant en outre les étapes supplémentaire de :
- envoyer du premier terminal vers le serveur la demande de création de transaction électronique correspondant à un service demandé ; - recevoir par le premier terminal des premières informations sur ladite transaction électronique envoyées par le serveur ;
- recevoir par le premier terminal le code de transaction généré par le serveur ;
- scanner ledit code de transaction au moyen du deuxième terminal ;
- recevoir par le deuxième terminal des secondes informations de ladite transaction électronique à partir du code de transaction scanné envoyées par le serveur ;
- envoyer du deuxième terminal au serveur un numéro d'identification personnelle et une information de validation de la transaction électronique ;
- recevoir par le premier terminal et vers le deuxième terminal une confirmation de transaction électronique envoyée depuis le serveur.
Le procédé comporte en outre une étape supplémentaire de créditer du montant de la transaction un premier compte de monnaie électronique vendeur lié au premier terminal et de débiter du montant de la transaction un deuxième compte de monnaie électronique acheteur lié au deuxième terminal.
Le procédé comporte en outre une étape supplémentaire de transmettre à partir du serveur un ordre de transaction correspondant à la transaction électronique validée dans le serveur à des serveurs bancaires adaptés pour gérer des comptes à créditer et à débiter relatifs à ladite transaction électronique.
Le code de transaction généré est un QR-Code®. Le premier terminal est :
- une caisse enregistreuse ou caisse automatique ; ou
- un ordinateur personnel ; ou
- un téléphone portable ; ou
- une tablette portable ;
et le deuxième terminal est :
- un téléphone mobile : ou
- une tablette portable. Les premières informations reçues par le premier terminal comportent un identifiant de la transaction électronique.
Les premières informations reçues par le premier terminal comportent en outre :
- un état de la transaction électronique ;
- un type de la transaction électronique ;
- le montant de la transaction électronique ;
- une description de la transaction électronique ;
- une date de création. L'invention concerne également un premier terminal adapté pour coopérer avec au moins un serveur et au moins un deuxième terminal pour mettre en œuvre le procédé de réalisation d'une transaction électronique selon l'une quelconque des caractéristiques précédentes, ledit premier terminal comportant un premier processeur adapté pour :
- envoyer une demande de création de transaction électronique à un serveur correspondant à un service demandé ;
- recevoir des premières informations sur ladite transaction électronique à partir du serveur ;
- recevoir un code de transaction généré par le serveur ;
- recevoir une confirmation de transaction électronique du serveur.
L'invention concerne également un serveur de paiement d'un service adapté pour coopérer avec au moins un premier terminal et au moins un deuxième terminal pour mettre en œuvre le procédé de réalisation d'une transaction électronique selon l'une quelconque des caractéristiques précédentes, ledit serveur comprenant un deuxième processeur adapté pour :
- recevoir du premier terminal une demande de création de transaction électronique correspondant à un service demandé ;
- sauvegarder des premières informations de ladite transaction électronique ;
- envoyer à partir du serveur au premier terminal les premières informations sur ladite transaction électronique ; - générer un code de transaction comprenant un identifiant de ladite transaction électronique ;
- envoyer au premier terminal le code de transaction ;
- envoyer au deuxième terminal des secondes informations de ladite transaction électronique à partir du code de transaction scanné par le deuxième terminal ;
- recevoir d'un deuxième terminal un numéro d'identification personnelle et une information de validation de la transaction électronique ;
- envoyer une confirmation de transaction électronique vers le premier terminal et vers le deuxième termina.
Dans un mode de réalisation non limitatif, le deuxième processeur est en outre adapté pour créditer du montant de la transaction un premier compte de monnaie électronique vendeur lié au premier terminal et de débiter du montant de la transaction un deuxième compte de monnaie électronique acheteur lié au deuxième terminal.
Dans un mode de réalisation non limitatif, le deuxième processeur est en outre adapté pour transmettre un ordre de transaction correspondant à la transaction électronique validée dans le serveur à des serveurs bancaires adaptés pour gérer des comptes à créditer et à débiter relatifs à ladite transaction électronique.
L'invention concerne également un deuxième terminal adapté pour coopérer avec au moins un serveur et au moins un premier terminal pour mettre en œuvre le procédé de réalisation d'une transaction électronique selon l'une quelconque des caractéristiques précédentes, ledit premier terminal comportant un troisième processeur adapté pour :
- scanner ledit code de transaction ;
- recevoir des secondes informations de ladite transaction électronique du serveur à partir du code de transaction scanné ;
- envoyer vers le serveur un numéro d'identification personnelle et une information de validation de la transaction électronique ;
- recevoir une confirmation de transaction électronique du serveur. L'invention concerne également un système de réalisation d'une transaction électronique d'un service entre un serveur, un premier terminal et un deuxième terminal, le système comprenant :
- un premier terminal selon la caractéristique précédente ;
- un serveur selon l'une quelconque des caractéristiques précédentes ; et
- un deuxième terminal selon la caractéristique précédente.
L'invention et ses différentes applications seront mieux comprises à la lecture de la description qui suit et à l'examen des figures qui l'accompagnent.
BREVE DESCRIPTION DES FIGURES
Celles-ci ne sont présentées qu'à titre indicatif et nullement limitatif de l'invention.
- La Fig.1 est un premier organigramme du procédé de réalisation d'une transaction électronique selon l'invention selon un premier mode de réalisation non limitatif ;
- La Fig.2 est un second organigramme du procédé de réalisation d'une transaction électronique de la Fig. 1 illustrant des étapes supplémentaires ;
- La Fig.3 est un schéma représentant les étapes du procédé de la Fig. 1 effectuées par un premier terminal, un deuxième terminal et un serveur ; et
- La Fig.4 est une représentation schématique d'un système de réalisation d'une transaction électronique selon un mode de réalisation pour mettre en œuvre le procédé de réalisation d'une transaction électronique de la Fig. 1 .
DESCRIPTION DE MODES DE REALISATION DE L'INVENTION
Le procédé de réalisation d'une transaction électronique MTH d'un service S entre un serveur Sk, un premier terminal Tm et un deuxième terminal Tu, est décrit dans un mode de réalisation non limitatif aux figures 1 à 4.
Par service S, on entend, achat de marchandise tel qu'un produit, une application, un billet, ou un coupon de réduction dans des exemples non limitatifs.
Le procédé de réalisation d'une transaction électronique MTH entre un serveur Sk, un premier terminal Tm et un deuxième terminal Tu comporte les étapes suivantes, telles qu'illustrées à la Fig. 1 .
- recevoir par un serveur Sk d'un premier terminal Tm une demande de création de transaction électronique Tr correspondant à un service demandé S (étape illustrée RX_CREAT(TR)) ;
- envoyer à partir du serveur Sk au premier terminal Tm des premières informations 11 sur ladite transaction électronique Tr (étape illustrée TX_TR(I1 )) ;
- générer par le serveur un code de transaction QR-C comprenant un identifiant Id de ladite transaction électronique Tr (étape illustrée GENERAT_QRC(ld)) ;
- envoyer par le serveur Sk au premier terminal Tm le code de transaction QR-C (étape illustrée TX_QRC) ;
- sauvegarder dans le serveur Sk les premières informations 11 de ladite transaction électronique (étape illustrée SAV_TR(I1 )) ;
- envoyer du serveur Sk au deuxième terminal Tu des secondes informations 12 de ladite transaction électronique Tr à partir du code de transaction scanné QR-C scanné par le deuxième terminal Tu (étape illustrée TX_TR(I2, QR-C)) ;
- recevoir par le serveur Sk un numéro d'identification personnelle PIN et une information de validation IVAL de la transaction électronique envoyées par le deuxième terminal Tu (étape illustrée RX_TR(PIN, IVAL)) ;
- envoyer une confirmation Conf de transaction électronique depuis le serveur Sk vers le premier terminal Tm et vers le deuxième terminal Tu (étape illustrée TX_CONF(Conf)).
Dans un mode de réalisation non limitatif illustré à la Fig. 2, le procédé comporte en outre les étapes supplémentaires de :
- envoyer du premier terminal Tm vers le serveur Sk la demande de création de transaction électronique Tr correspondant à un service demandé S (étape illustrée TX_CREAT(TR)) ;
- recevoir par le premier terminal Tm des premières informations 11 sur ladite transaction électronique Tr envoyées par le serveur Sk (étape illustrée RX_TR(I1 )) ;
- recevoir par le premier terminal Tm le code de transaction QR- C généré par le serveur Sk (étape illustrée RX_QRC) ;
- scanner ledit code de transaction QR-C au moyen du deuxième
terminal Tu (étape illustrée SCAN(QR-C)) ;
- recevoir par le deuxième terminal Tu des secondes informations 12 de ladite transaction électronique à partir du code de transaction scanné QR-C envoyées par le serveur Sk (étape illustrée RX_TR(I2, QR-C)) ; - envoyer du deuxième terminal Tu au serveur Sk un numéro d'identification personnelle PIN et une information de validation IVAL de la transaction électronique Tr (étape illustrée TX_TR(PIN, IVAL)) ;
- recevoir par le premier terminal Tm et par le deuxième terminal Tu une confirmation Conf de transaction électronique Tr envoyée depuis le serveur Sk (étape illustrée RX_CONF(Conf)).
On notera que la présentation des étapes ci-dessus ne présupposent pas qu'elles soient séquentielles. Dans un mode de réalisation non limitatif, le procédé comporte en outre une étape supplémentaire de créditer du montant Mt de la transaction un premier compte de monnaie électronique vendeur Cpt1 lié au premier terminal Tm et de débiter du montant Mt de la transaction un deuxième compte de monnaie électronique acheteur Cpt2 lié au deuxième terminal Tu (étape illustrée CRED_DEB(Mt, Cpt1 , Cpt2).
Dans un mode de réalisation non limitatif, le procédé comporte en outre une étape supplémentaire de transmettre à partir du serveur Sk un ordre de transaction correspondant à la transaction électronique sauvegardée dans le serveur Sk à des serveurs bancaires Sbq adaptés pour gérer des comptes à créditer et à débiter relatifs à ladite transaction électronique Tr (étape illustrée OT_CRED_DEB(Mt, Cpt1 \ Cpt2')).
Pour la suite de la description, dans le mode de réalisation non limitatif du procédé décrit, le procédé comprend ces modes de réalisation non limitatifs.
Le procédé de réalisation d'une transaction électronique est déclenché de la manière suivante. Dans un premier mode de réalisation non limitatif, le procédé de réalisation d'une transaction électronique est déclenché par une entrée manuelle sur le premier terminal Tm d'un montant de transaction Mt et un appui manuel sur des moyens de sélection du procédé de réalisation d'une transaction électronique tel que par exemple un bouton. Ce premier mode est réalisé par exemple dans le cas où le premier terminal Tm est une tablette portable.
Dans un deuxième mode de réalisation non limitatif, le procédé de réalisation d'une transaction électronique est déclenché par une entrée automatique sur le premier terminal Tm d'un montant de transaction Mt et un appui manuel sur des moyens de sélection du procédé de réalisation d'une transaction électronique tel que par exemple un bouton. Ce premier mode est réalisé par exemple dans le cas où le premier terminal Tm est une caisse enregistreuse ou caisse automatique (borne de commande automatisée). On notera que l'entrée automatique du montant de la transaction s'effectue par exemple en scannant le code barre où est indiqué le prix du service S.
Dans un troisième mode de réalisation non limitatif, le procédé de réalisation d'une transaction est déclenché par la validation sur internet (au travers une page web) de l'achat du service S. L'utilisateur peut ainsi se connecter à l'application correspondant au procédé de paiement via un premier terminal Tm qui est par exemple un ordinateur personnel.
Lorsque le premier terminal Tm appelle le procédé de paiement, préalablement à l'exécution du procédé de paiement, les étapes initiales suivantes sont effectuées : - i) un jeton (appelé en anglais « token ») est créé par le serveur Sk. Ce jeton permet d'ouvrir une session entre le premier terminal Tm et le serveur Sk ;
- ii) le premier terminal Tm s'authentifie au serveur Sk. Dans un premier mode de réalisation, l'authentification s'effectue au moyen d'une clef privée et d'un identifiant associé au premier terminal. Ce mode de réalisation est appliqué lorsque le premier terminal Tm est une caisse enregistreuse ou caisse automatique (borne de commande automatisée) par exemple. Dans un deuxième mode de réalisation, l'authentification s'effectue au moyen du nom de l'utilisateur vendeur propriétaire du premier terminal Tm et de son mot de passe. Ce mode de réalisation est appliqué lorsque le premier terminal Tm est une tablette portable par exemple. On notera qu'une session est ouverte pour un utilisateur vendeur. On pourrait également avoir une session pour chaque premier terminal Tm.
- iii) si l'authentification réussie, le premier terminal Tm se connecte au serveur Sk pour communiquer avec lui et va utiliser le jeton émis pour l'ensemble de ses communications avec ledit serveur Sk.
Par la suite, le procédé de réalisation d'une transaction électronique s'exécute.
On notera qu'une session vendeur se termine lorsque le jeton est invalidé. Ce dernier peut être invalidé dans les cas suivants :
- lorsqu'une temporisation (« timeout » en anglais) est dépassée car aucune transaction n'a été effectuée depuis la dernière, par exemple depuis vingt minutes ;
- lorsqu'il n'est plus valide car a atteint une durée déterminée, par exemple d'un jour ;
- lorsque l'utilisateur vendeur change son mot de passe et son nom d'utilisateur.
Les étapes du procédé de réalisation d'une transaction électronique sont décrites en détail ci-après en se référant à la Fig. 2. Dans une première étape 1) (étape illustrée TX_CREAT(TR)), le premier terminal Tm envoie vers le serveur Sk la demande de création de transaction électronique Tr correspondant à un service demandé S et le serveur Sk reçoit du premier terminal Tm la demande de création de transaction électronique Tr correspondant à un service demandé S (étape n
Dans des modes de réalisation non limitatifs, le premier terminal Tm est :
- une caisse enregistreuse ou caisse automatique (borne de commande automatisée) ; ou
- un ordinateur personnel (au travers d'un programme dédié sur l'ordinateur ou d'un service web); ou
- un téléphone portable ; ou
- une tablette portable.
On notera que le premier terminal peut également être une station de travail. (au travers d'un programme dédié sur l'ordinateur ou d'un service web);
Dans une deuxième étape 2) (étape illustrée SAV_TR(I1 )), le serveur Sk sauvegarde des premières informations 11 de ladite transaction électronique Tr.
Dans un mode de réalisation non limitatif, les premières informations reçues 11 par le premier terminal Tm comportent un identifiant Id de la transaction électronique Tr. Cet identifiant va permettre au premier terminal Tm de demander au serveur Sk de générer un code de transaction QR-C comme décrit plus loin. Dans un mode de réalisation non limitatif, les premières informations 11 comportent en outre :
- un état St de la transaction électronique. Cet état peut comporter les valeurs « en cours », « annulé », « validée ». A cette étape, l'état prend la valeur « en cours » ;
- un type Ty la transaction électronique. Le type peut comporter les indications suivantes :
- transaction marchande (acheteur vers vendeur) - remboursement (vendeur vers acheteur)
- rechargement carte bleue
- virement IBAN vers compte bancaire
Le type est ainsi utilisé lors d'une lecture de l'historique des transactions par le propriétaire du premier terminal Tm et/ou le propriétaire du deuxième terminal Tu.
le montant Mt de la transaction électronique ;
une description Ds de la transaction électronique. Par exemple comme description on peut avoir « paiement de 10 euros de Mr X au commerçant Y ». Ce champ est également utilisé lors d'une lecture de l'historique des transactions ;
une date Dt de création. Ce champ est également utilisé lors d'une lecture de l'historique des transactions. Il est par ailleurs comparé à une date courante. Ainsi, si la date de création est antérieure d'un certain temps par rapport à la date courante, et que la transaction est en attente depuis ce temps, elle ne peut plus être validée car considérée comme trop ancienne.
Dans un mode de réalisation non limitatif, les informations 11 ' supplémentaires suivantes de la transaction sont sauvegardées dans le serveur Sk :
- une empreinte Tg de la transaction électronique. Cette empreinte unique comporte des informations codifiées sur la transaction pour limiter des pertes de données, telles que le type de la transaction, l'identifiant du débiteur ;
- la devise Dv de la transaction électronique ;
- un identifiant du débiteur ld_Db de la transaction électronique ;
- un identifiant du créditeur ld_Dc de la transaction électronique ;
Ce champ permet de demander au serveur Sk les informations sur un débiteur qui possède le compte débiteur (nom prénom) et permet également d'avoir une meilleure traçabilité et de faire de l'analyse de donnée (fréquence d'achat, panier moyenne, etc. de l'utilisateur). On notera que ce champ est également présent dans un compte de monnaie électronique décrit plus loin ; - un identifiant d'un compte à créditer ld_Cc (compte de monnaie électronique, compte virtuel bancaire, compte virtuel de carte bleue);
- un identifiant d'un compte à débiter ld_Cd (compte de monnaie électronique, compte virtuel bancaire, compte virtuel de carte bleue) ;
- des informations I Pt (telles que un identifiant de transaction, des informations d'erreurs de transaction) sur des serveurs tiers Str coopérant avec le serveur de paiement Sk. Ces serveurs tiers fournissent des services de gestion de monnaie électronique ;
Dans une troisième étape 3) (étape illustrée TX_TR(I1 )), le serveur Sk envoie au premier terminal Tm des premières informations 11 sur ladite transaction électronique Tr et le premier terminal Tm reçoit les premières informations 11 sur ladite transaction électronique Tr envoyées par le serveur Sk (étape 3').
Dans une quatrième étape 4) (étape illustrée GENERAT_QRC(ld)), le serveur Sk génère un code de transaction QR-C comprenant un identifiant Id de ladite transaction électronique Tr.
On notera que le code de transaction QR-C est généré à la volée, à savoir à chaque fois qu'une transaction est créée. Il n'a donc pas besoin d'être sauvegardé dans le serveur Sk. Il peut cependant être sauvegardé dans le deuxième terminal Tu.
Dans un premier mode de réalisation non limitatif, le code de transaction QR-C est généré sur requête Rq du premier terminal Tm qui a demandé une création de transaction Tr. La requête Rq du premier terminal Tm comporte l'identifiant Id de la transaction Tr. On notera que dans ce cas, le code de transaction QR-C est généré si une transaction électronique est dans un état « en cours ».
Dans un deuxième mode de réalisation non limitatif, le code de transaction QR-C est généré automatiquement par le serveur Sk, dès réception d'une demande de création de transaction Tr. Dans ce cas, l'étape de génération du code est effectuée avant l'étape 2) de réception des premières informations 11 par le premier terminal Tm, et soit les premières informations comportent le code généré QR-C, ce dernier étant ainsi envoyé dans ces informations 11 , soit il est envoyé en même temps. On notera que dans ce cas, l'identifiant de transaction Id est toujours nécessaire dans les informations 11 envoyées du fait de la notification dans l'étape de confirmation décrite plus loin.
Dans un mode de réalisation non limitatif, le code de transaction généré est un QR-Code®. Il comporte une url du type https://url correspondant au procédé de paiement/transactions/ld. Cette url est reconnue par le deuxième terminal Tu (en scannant le code de transaction) si ce dernier peut faire appel au procédé de réalisation d'une transaction électronique MTH. Dans le cas contraire, lorsque le code de transaction est scanné, mais le procédé de réalisation d'une transaction électronique n'est pas connu, une page web correspondant à l'url s'affiche et explique comment installer le produit programme d'ordinateur correspondant au procédé de réalisation d'une transaction électronique côté deuxième terminal Tu sur ledit deuxième terminal Tu.
On notera que la génération du code de transaction se fait au moyen d'une bibliothèque de génération de code.
Dans d'autres modes de réalisation non limitatifs, le code de transaction généré est :
- un datamatrix (code barre 2D) ;
- un code barre 1 D classique ;
- toute autre image comprenant l'url du procédé de réalisation d'une transaction électronique MTH ;
- une image aléatoire liée à la transaction électronique. Dans une cinquième étape 5) (étape illustrée TX_QRC), le serveur
Sk envoie le code de transaction QR-C au premier terminal Tm et le premier terminal Tm reçoit le code de transaction QR-C généré par le serveur Sk (étape 5'). On notera que cette étape peut être effectuée en même temps que la troisième étape 3) d'envoi des premières informations 11 lorsque le code est généré automatiquement par le serveur Sk. Dans une variante de réalisation, les informations 11 de la troisième étape comprennent ce code généré QR-C.
Dans une sixième étape 6) (étape illustrée SCAN(QR-C)), un deuxième terminal Tu scanne ledit code de transaction QR-C.
Le code de transaction QR-C est scanné sur l'écran du premier terminal Tm.
Dans des exemples de réalisation non limitatifs, un deuxième terminal Tu est un téléphone mobile ou une tablette portable.
Bien entendu, le deuxième terminal Tu comporte des moyens pour scanner ce code de transaction QR-C, à savoir notamment une caméra.
Dans un premier mode de réalisation, lorsque le deuxième terminal Tu scanne le code de transaction QR-C, il reconnaît l'url contenu dans ledit code car il contient l'application correspondant au procédé de paiement. A ce moment, les étapes suivantes sont effectuées :
- i) le deuxième terminal Tu s'authentifie avec le serveur Sk via son code PIN et son identifiant utilisateur ;
- ii) si l'authentification réussie, le deuxième terminal Tu se connecte au serveur Sk pour communiquer avec lui ;
- iii) le deuxième terminal Tu envoie une requête au serveur Sk pour l'émission d'un jeton.
- I) le serveur Sk émet un jeton qui permet d'ouvrir une session entre le deuxième terminal Tu et le serveur Sk. On notera qu'un jeton est émis pour chaque deuxième terminal Tu. On a ainsi une session par terminal. Ainsi, un même acheteur peut utiliser plusieurs deuxièmes terminaux pour effectuer ses transactions électroniques. Il y aura donc une pluralité de jetons. Chaque deuxième terminal Tu va utiliser le jeton émis pour l'ensemble de ses communications avec ledit serveur Sk.
Par la suite, les étapes suivantes sont exécutées. Dans un deuxième mode de réalisation, lorsque le deuxième terminal Tu scanne le code de transaction QR-C, il ne reconnaît pas l'url contenu dans ledit code.
A ce moment, dans une première variante de réalisation, une page web de l'application s'affiche sur l'écran du deuxième terminal Tu et explique les modalités d'installation de l'application correspondant au procédé de paiement.
A ce moment, dans une deuxième variante de réalisation, une page web de l'application s'affiche sur l'écran du deuxième terminal qui permet d'effectuer directement une transaction électronique. La page web contient alors les informations sur la transaction : nom du commerçant, image (logo), montant Mt, champ pour se connecter avec le compte de monnaie électronique en s'authentifiant avec le nom utilisateur et mot de passe pour le compte, ou via le compte du réseau social, et enfin en entrant le code PIN. Par la suite un message de confirmation de paiement est retourné.
On notera qu'une session acheteur se termine lorsque le jeton est invalidé. Ce dernier peut être invalidé dans les cas suivants :
- lorsqu'une temporisation (« timeout » en anglais) est dépassée car aucune transaction n'a été effectuée depuis la dernière, par exemple depuis vingt minutes ;
- lorsqu'il n'est plus valide car a atteint une durée déterminée, par exemple d'un jour ;
- lorsque l'utilisateur acheteur demande à révoquer tous ses jetons ;
- lorsque l'utilisateur acheteur change son mot de passe ;
- lorsque l'utilisateur acheteur entre 3 fois de suite un code PIN erroné ;
- lorsque l'utilisateur acheteur bloque son compte à distance (après perte de téléphone par exemple) depuis son espace de gestion privé accessible depuis le site web.
Dans une septième étape 7) (étape illustrée TX_TR(I2, QR-C)), le serveur Sk envoie au deuxième terminal Tu des secondes informations 12 de ladite transaction électronique à partir du code de transaction scanné QR-C et le deuxième terminal Tu reçoit les secondes informations 12 de ladite transaction électronique à partir du code de transaction scanné QR- C envoyées par le serveur Sk (étape 7').
Grâce à l'identifiant Id de la transaction électronique se trouvant dans le code de transaction QR-C, le serveur Sk va récupérer les informations de ladite transaction qui ont été sauvegardées préalablement dans un référentiel de données dudit serveur Sk.
Les deuxièmes informations 12 de la transaction électronique sont alors affichées sur l'écran du deuxième terminal Tu.
On notera que les secondes informations 12 comprennent les premières informations 11 plus le nom du vendeur et une image (logo) associée.
Dans une huitième étape 8) (étape illustrée TX_TR(PIN, IVAL)), le deuxième terminal Tu envoie au serveur Sk un numéro d'identification personnelle PIN et une information de validation IVAL de la transaction électronique Tr et le serveur Sk reçoit du deuxième terminal Tu le numéro d'identification personnelle PIN et l'information de validation IVAL de la transaction électronique (étape 8').
Ainsi, lorsque l'utilisateur du deuxième terminal Tu (la personne qui achète donc le service S) a vérifié sur l'écran de son terminal les informations de la transaction électronique et notamment son montant Mt, il entre son PIN et appuie par exemple sur un bouton de son terminal pour indiquer au serveur qu'il a vérifié la transaction et qu'il est d'accord avec la transaction. Une information « valide » IVAL1 est envoyée. La transaction est ainsi validée et sécurisée. S'il ne veut pas valider la transaction, un autre bouton est par exemple utilisé. Une information « invalide » IVAL2 est envoyée.
On notera que lorsque le serveur Sk coopère avec un serveur tiers Str d'agrément d'un organisme agréé de gestion de monnaie électronique, la validation de la transaction électronique Tr côté deuxième terminal Tu entraîne une vérification automatique côté serveur tiers et une validation/invalidation par ledit serveur tiers. Le deuxième terminal Tu est alors informé si la transaction électronique a été validée ou invalidée par l'organisme agréé. Dans une neuvième étape 9) (étape illustrée TX_CONF(Conf)), le serveur Sk envoie une confirmation de transaction électronique vers le premier terminal Tm et vers le deuxième terminal Tu et le premier terminal Tm et le deuxième terminal Tu reçoivent la confirmation Conf de transaction électronique Tr envoyée depuis le serveur Sk (étape 9').
Les terminaux sont ainsi avertis que la transaction s'est bien passée.
L'état de la transaction électronique est alors changé et mis à la valeur « validée ».
Si l'utilisateur a annulé la transaction, la valeur de l'état est mis à « annulé ».
On notera que dans le cas d'un premier terminal Tm, la confirmation est une notification envoyée par le serveur Sk comprenant l'identifiant Id de la transaction Tr. Dans un exemple non limitatif, le protocole de notification APN (« Apple™ Push Notifications ») est utilisé.
Dans d'autres exemples, le protocole de notification d'Android™ C2DN peut être utilisé ou tout autre protocole de notification propriétaire.
Le premier terminal Tm compare l'identifiant reçu dans la notification avec les identifiants des transactions qu'il a créées pour vérifier si la transaction souhaitée est validée.
Dans le cas d'un deuxième terminal Tu, ce dernier accepte la transaction (lorsque l'utilisateur acheteur a validé la transaction) et reçoit un message de confirmation de son acceptation de la part du serveur Sk.
On notera que la confirmation peut aussi se faire par exemple par longpolling, shortpolling et/ou toute autre méthode de notification sur base de protocoles open source ou propriétaire.
Dans une dixième étape 10) (étape illustrée CRED_DEB(Mt, Cpt1 ,
Cpt2)), le serveur Sk crédite du montant Mt de la transaction un premier compte de monnaie électronique vendeur Cpt1 lié au premier terminal Tm et débite du montant Mt de la transaction un deuxième compte de monnaie électronique utilisateur Cpt2 lié au deuxième terminal Tu. On notera que l'association entre un compte de monnaie électronique vendeur CPt1 et un premier terminal Tm se fait lors d'une création d'un profil utilisateur vendeur Upf 1 dans le serveur Sk. Des comptes de monnaie électronique associés sont alors créés et sont reliés avec le profil par leurs identifiants, un compte ne changeant pas de propriétaire.
Dans un mode de réalisation non limitatif, un profil utilisateur vendeur Upf 1 comporte les informations suivantes :
- le nom du vendeur (nom commercial s'il existe) ;
- le secteur d'activité. Cette information permet d'effectuer des comparaisons par rapport aux autres vendeurs utilisant le procédé de réalisation d'une transaction électronique ;
- le pays ;
- l'adresse ;
- l'email ;
- le numéro de téléphone ;
- l'url du site du vendeur s'il existe ;
- la page d'un réseau social si elle existe ;
- un identifiant vendeur ;
- un identifiant de compte de monnaie électronique ;
- un identifiant de rechargement de compte ;
- une date de création ;
- une dernière date de connexion ;
- un identifiant de compte agréé ;
- un mot de passe pour l'application correspondant au procédé de réalisation d'une transaction électronique.
On notera que l'association entre un compte de monnaie électronique acheteur Cpt2 et un deuxième terminal Tu se fait lors d'une création d'un profil utilisateur acheteur Upf2 dans le serveur Sk. Un compte de monnaie électronique associé est alors créé et est relié avec le profil par son identifiant, un compte ne changeant pas de propriétaire.
Dans un mode de réalisation non limitatif, un profil utilisateur acheteur Upf2 comporte les informations suivantes :
- le nom et prénom de l'acheteur ; - la date de naissance ;
- l'email ;
- le sexe ;
- le pays ;
- la nationalité ;
- le code PIN ;
- un identifiant de compte de monnaie électronique
- un identifiant d'un compte virtuel pour carte bancaire ;
- un identifiant acheteur ;
- une date d'inscription.
Optionnellement les champs suivants peuvent être ajoutés :
- un identifiant d'un compte virtuel d'un compte bancaire ;
- la langue ;
- un champ confidentialité pour indiquer si le profil utilisateur est public ;
- un champ notification pour indiquer si le deuxième terminal associé à l'utilisateur reçoit des notifications comme décrites ci- dessus :
- un numéro de téléphone ;
- un mot de passe pour l'application correspondant au procédé de réalisation d'une transaction électronique. On notera que si un réseau social est utilisé, le mot de passe du réseau social sera utilisé pour lancer le procédé.
On notera que les attributs identifiant d'un compte virtuel d'un compte bancaire et identifiant d'un compte virtuel pour carte bancaire permet à un utilisateur du deuxième terminal Tu de recharger son compte de monnaie électronique à partir d'un compte virtuel de carte bancaire déclarée dans le serveur Sk ou d'un compte virtuel bancaire déclaré dans le serveur Sk et donc de créditer/débiter virtuellement sa carte bancaire et son compte bancaire et d'avoir un reflet de ses débits/crédits grâce aux comptes virtuels de carte bancaire et de compte bancaire se trouvant sur le serveur Sk. Par la suite les crédits/débits virtuels sont bien entendus retranscrits sur les véritables comptes bancaires et cartes bancaires de l'utilisateur.
Dans un mode de réalisation non limitatif, un premier compte de monnaie électronique vendeur Cpt1 est créé par un administrateur du serveur de paiement Sk.
Un premier compte vendeur Cpt1 est créé et associé au profil utilisateur vendeur Upf 1 et comporte dans un mode de réalisation non limitatif les informations suivantes :
- nom du propriétaire du compte ;
- organisme bancaire affilié ;
- adresse ;
- IBAN ;
- BIC ;
- Identifiant compte ;
- Description de compte ;
- Type ;
- Devise ;
- Etat ;
- Identifiant vendeur ;
- Date de création.
Dans un mode de réalisation non limitatif, un deuxième compte de monnaie électronique acheteur Cpt2 est créé par l'acheteur lui-même lorsqu'il crée son profil utilisateur Upf2 à partir de l'url de l'application correspondant au procédé de paiement. La création du profil utilisateur se fait en entrant les données manuellement ou en les récupérant à partir d'une page de l'utilisateur sur un réseau social.
Un deuxième compte acheteur Cpt2 est créé et associé au profil utilisateur acheteur Upf2 et comporte dans un mode de réalisation non limitatif les informations suivantes :
- nom du propriétaire du compte ;
- organisme bancaire affilié ;
- adresse ;
- IBAN ; - BIC ;
- Identifiant compte ;
- Description de compte ;
- Type ;
- Devise ;
- Etat ;
- Identifiant acheteur ;
- Date de création. On notera que grâce à ce compte Cpt2, un utilisateur acheteur peut effectuer un paiement ou recharger son compte Cpt2.
Dans un mode de réalisation non limitatif, le serveur coopère avec des moyens de paiement sécurisé par internet. Ces moyens sont soit internes soit externes au serveur de paiement Sk. Les moyens sont par exemple des serveurs tiers Str qui appartiennent à des organismes tiers agréés pour gérer la monnaie électronique, à savoir pour valider la gestion des comptes de monnaies électroniques et les transactions. Les transactions validées par ces organismes font foi. Les serveurs d'un organisme tel que Leetchi™ sont dans un exemple non limitatif utilisés. On notera que dans ce cas, les premier et deuxième terminaux comportent à cet effet un accès internet par lequel le vendeur et/ou l'acheteur peut entrer son numéro de carte bancaire ou accepter un rechargement par carte bancaire.
Dans ce cas, un compte de monnaie électronique agréé Cpt1 ' correspondant au premier compte Cpt1 et un compte de monnaie électronique agréé Cpt2' correspondant au deuxième compte Cpt2 sont automatiquement créés sur les serveurs tiers Str.
Ainsi, lors du crédit ou du débit d'un compte électronique Cpt1 , Cpt2, le serveur coopère avec ces moyens de paiement sécurisé par internet. Les comptes de monnaie électroniques agréés Cpt1 ', Cpt2' sur les serveurs tiers Str reflètent les transactions (débit/crédit) effectuées sur les comptes Cpt1 , Cpt2 respectivement.
De tels comptes Cpt1 ' et Cpt2' comportent dans un mode de réalisation non limitatif les informations suivantes : - Identifiant compte ;
- Identifiant compte correspondant Cpt1 /Cpt2 ;
- Description compte ;
- Type : permet de définir l'appartenance à un organisme tiers ;
- Devise ;
- Etat : ouvert, fermé, frauduleux ;
- Identifiant du propriétaire ;
- Date de création. Dans un mode de réalisation non limitatif, le serveur Sk comprend un unique compte de monnaie électronique Cpt2 attribué à un utilisateur d'un deuxième terminal Tu.
Dans un mode de réalisation non limitatif, le serveur Sk comprend soit un unique compte de monnaie électronique Cpt1 pour un vendeur qui possède un premier terminal Tm, soit un compte de monnaie électronique Cpt1 pour chaque premier terminal Tm que possède le vendeur.
On notera que le serveur Sk sauvegarde les coordonnées bancaires (IBAN) du vendeur. Pour l'acheteur, cela est facultatif. En effet, l'acheteur a la possibilité d'entrer son IBAN dans le serveur Sk afin de retirer son argent électronique de son compte électronique, mais cet usage n'est pas fréquent.
Dans une onzième étape 11) (étape illustrée OT_CRED_DEB(Mt, Cpt1 , Cpt2)), le serveur Sk transmet un ordre de transaction Ot correspondant à la transaction électronique validée dans le serveur sk à des serveurs bancaires Sbq adaptés pour gérer des comptes à créditer et à débiter relatifs à ladite transaction électronique Tr.
On notera que les ordres de transaction Ot sont émis périodiquement entre le serveur Sk et les serveurs bancaires Sbq.
Ainsi, cela permet de créditer le compte bancaire du vendeur qui vend le service S et de débiter le compte bancaire de l'utilisateur qui achète le service S.
Dans un exemple non limitatif, les ordres sont émis toutes les semaines. Le vendeur peut ainsi transférer l'argent collecté sur son compte de monnaie électronique sur son compte bancaire. Dans toutes les étapes du procédé de réalisation d'une transaction électronique décrites précédemment, dans un mode de réalisation non limitatif, l'envoi/la réception de données telles que d'une demande de création d'une transaction, des informations, d'un ordre Ot, d'un code de transaction concernant une transaction électronique Tr s'effectue au moyen du protocole https (« HyperText Transfer Protocol Secured») basé sur un protocole de sécurisation des échanges sur Internet par exemple TLS (« Transport Layer Security »). Ainsi, le procédé de réalisation d'une transaction électronique permet à des utilisateurs de terminaux mobiles d'effectuer des paiements sécurisés de leur achat sans avoir besoin d'utiliser leur carte de crédit.
Une transaction électronique peut s'effectuer entre un utilisateur de téléphone mobile et un commerçant possédant une caisse enregistreuse ou caisse automatique (borne de commande automatisée) ou une tablette portable, ou encore entre deux personnes utilisateurs de téléphones mobiles, ou encore entre deux personnes utilisateurs de tablettes portables etc. Le procédé de réalisation d'une transaction électronique entre un serveur Sk, un premier terminal Tm et un deuxième terminal Tu est mis en œuvre par un système de réalisation d'une transaction électronique d'un service S entre un serveur Sk, un premier terminal Tm et un deuxième terminal Tu illustré à la Fig. 4.
Le système SYS comprend :
- au moins un premier terminal Tm comprenant un premier processeur UC1 adapté pour :
- envoyer une demande de création de transaction électronique Tr à un serveur Sk correspondant à un service demandé S ;
- recevoir des premières informations 11 sur ladite transaction électronique Tr à partir du serveur Sk ;
- recevoir un code de transaction QR-C généré par le serveur Sk ;
- recevoir une confirmation Conf de transaction électronique du serveur Sk ;
- le serveur Sk comprenant un deuxième processeur UC2 adapté pour :
- recevoir du premier terminal Tm une demande de création de transaction électronique Tr correspondant à un service demandé
S ;
- envoyer au premier terminal Tm des premières informations 11 sur ladite transaction électronique Tr ;
- générer un code de transaction QR-C comprenant un identifiant Id de ladite transaction électronique Tr ;
- envoyer au premier terminal Tm le code de transaction QR-C ;
- sauvegarder les premières informations 11 de ladite transaction électronique Tr ;
- envoyer au deuxième terminal Tu des secondes informations 12 de ladite transaction électronique Tr à partir du code de transaction scanné QR-C par le deuxième terminal Tu ;
- recevoir d'un deuxième terminal Tu un numéro d'identification personnelle PIN et une information de validation IVAL de la transaction électronique Tr ;
- envoyer une confirmation Conf de transaction électronique Tr vers le premier terminal Tm et vers le deuxième terminal Tu.
- au moins un deuxième terminal Tu comprenant un troisième processeur UC3 adapté pour :
- scanner ledit code de transaction QR-C ;
- recevoir des secondes informations 12 de ladite transaction électronique du serveur Sk à partir du code de transaction scanné QR-C ;
- envoyer vers le serveur Sk un numéro d'identification personnelle et une information de validation de la transaction électronique ; - recevoir une confirmation Conf de transaction électronique du serveur Sk.
Dans un mode de réalisation non limitatif, le deuxième processeur UC2 du serveur Sk est en outre adapté pour créditer du montant Mt de la transaction un premier compte de monnaie électronique vendeur Cpt1 lié au premier terminal Tm et de débiter du montant Mt de la transaction un deuxième compte de monnaie électronique acheteur Cpt2 lié au deuxième terminal Tu.
Dans un mode de réalisation non limitatif, le deuxième processeur UC2 du serveur Sk est en outre adapté pour transmettre à partir du serveur Sk un ordre de transaction Ot correspondant à la transaction électronique validée dans le serveur Sk à des serveurs bancaires Sbq adaptés pour gérer des comptes à créditer et à débiter relatifs à ladite transaction électronique Tr.
Dans un mode de réalisation non limitatif, le serveur Sk comporte un référentiel de données Bdd, illustré à la Fig. 4 dans lequel :
- on enregistre les transactions électroniques Tr effectuées entre un premier terminal Tm et un deuxième terminal Tu, que les transactions soient en cours, annulées ou validées ;
- on enregistre les codes de transaction QR-C générés ;
- on enregistre les comptes de monnaie électroniques vendeur Cpt1 et acheteur Cpt2. Ainsi, la base de donnée Bdd comporte un compte de monnaie électronique associé au moins à chaque utilisateur (acheteur, vendeur), et le cas échéant à chaque premier terminal Tm, de l'application mettant en œuvre le procédé de réalisation d'une transaction électronique décrit.
Dans un mode de réalisation non limitatif, le référentiel de données Bdd comporte :
- un log Lg de toutes les actions effectuées par les premiers Tm et deuxièmes Tu terminaux ;
- les objets Obj liés à la transaction (les articles achetés) On notera que la mise en œuvre du procédé de réalisation d'une transaction électronique exposé ci-dessus peut être effectuée au moyen d'un dispositif micro programmé « software », d'une logique câblée et/ou de composants électroniques « hardware ».
Ainsi, le système de réalisation d'une transaction électronique SYS peut comporter un ou plusieurs produits programmes d'ordinateur comportant une ou plusieurs séquences d'instructions exécutables par une unité de traitement d'information telle qu'un microprocesseur, ou d'une unité de traitement d'un microcontrôleur, d'un ASIC, d'un ordinateur etc., l'exécution desdites séquences d'instructions permettant une mise en œuvre du procédé décrit.
Un tel programme d'ordinateur peut être inscrit en mémoire non volatile inscriptible de type ROM ou en mémoire non volatile réinscriptible de type EEPROM ou FLASH. Ledit programme d'ordinateur peut être inscrit en mémoire en usine ou encore chargé en mémoire ou téléchargé à distance en mémoire. Les séquences d'instructions peuvent être des séquences d'instructions machine, ou encore des séquences d'un langage de commande interprétées par l'unité de traitement au moment de leur exécution.
Dans l'exemple non limitatif de la Fig. 3, un premier programme d'ordinateur PG1 est inscrit dans une mémoire du premier terminal Tm, un deuxième programme d'ordinateur PG2 est inscrit dans une mémoire du serveur de paiement Sk et un troisième programme d'ordinateur PG3 est inscrit dans une mémoire du deuxième terminal Tu.
Ainsi, le premier produit programme d'ordinateur PG1 comporte une ou plusieurs séquences d'instructions exécutables par une unité de traitement d'information, l'exécution desdites séquences d'instructions permettant une mise en œuvre des étapes du procédé de paiement, lorsqu'il est chargé sur un ordinateur, étapes décrites précédemment effectuées par le premier terminal T.
Ainsi, le deuxième produit programme d'ordinateur PG2 comporte une ou plusieurs séquences d'instructions exécutables par une unité de traitement d'information, l'exécution desdites séquences d'instructions permettant une mise en œuvre des étapes du procédé de paiement, lorsqu'il est chargé sur un ordinateur, étapes décrites précédemment effectuées par le serveur Sk.
Ainsi, le troisième produit programme d'ordinateur PG3 comporte une ou plusieurs séquences d'instructions exécutables par une unité de traitement d'information, l'exécution desdites séquences d'instructions permettant une mise en œuvre des étapes du procédé de paiement, lorsqu'il est chargé sur un ordinateur, étapes décrites précédemment effectuées par le deuxième terminal Tu.
Bien entendu la description n'est pas limitée à l'application, aux modes de réalisation et aux exemples décrits ci-dessus.
Ainsi, dans un mode de réalisation non limitatif, le procédé de réalisation d'une transaction électronique peut être utilisé dans le cadre d'un achat d'un service qui tient compte de coupons de réduction ou de ticket/billet prépayé. Ainsi, dans un mode de réalisation non limitatif, l'envoi/la réception d'une demande de création d'une transaction, des informations, d'un ordre Ot, d'un code de transaction concernant une transaction électronique Tr peut s'effectuer au moyen d'autres protocoles tels que RPC (« Remote Procédure Call), CORBA (« Common Object Request Broker Architecture ») ou un protocole propriétaire basé sur TCP. Ces protocoles étant bien connus de l'homme du métier, ils ne sont pas décrits ici.
Ainsi, l'invention décrite présente notamment les avantages suivants : elle permet d'avoir des transactions électroniques dématérialisées, c'est- à-dire sans utilisation de cartes bancaires et sans terminaux de paiement classiques, la transaction électronique s'effectuant entre deux terminaux via un serveur de paiement;
elle permet de diminuer les frais transactionnels, liés aux commissions interbancaires classiques, et ainsi d'augmenter la marge opérationnelle de nos partenaires ;
- elle permet aux commerçants de bénéficier d'un reversement plus rapide qu'en cas de transaction effectuée au travers de d'un terminal de paiement électronique ;
elle permet de lutter contre la fraude fiscale puisque toutes les transactions sont enregistrées et donc déclarées ; elle permet d'effectuer une transaction électronique même en cas de perte de carte bancaire ;
elle utilise des deuxièmes terminaux tels que des mobiles couramment utilisés ;
elle permet de :
- payer en caisse chez un commerçant - rembourser un ami
- payer sur internet
elle permet à un utilisateur acheteur de s'enregistrer (création de son profil) directement sur son terminal ;
- elle permet à un commerçant de recevoir un paiement sur une tablette ou un smartphone par exemple ;
elle est sécurisée du fait de l'utilisation du PIN ;
elle permet aux commerçants de récupérer et de croiser des données sur les habitudes de consommation de sa clientèle ;
- elle permet d'avancer la lutte contre la fraude monétique, puisque personne ne peut procéder à une transaction sans le code PIN, contrairement aux cartes bancaires, dont les coordonnées peuvent être volées pour payer sur des sites n'utilisant pas le protocole 3D Secure ; elle permet aux commerçants de récupérer et de croiser des données sur les profils de sa clientèle ;
elle permet aux utilisateurs de procéder à des virements instantanément, sans frais aucun ;
elle permet aux utilisateurs inscrits de procéder à des virements instantanément, sans avoir à renseigner plusieurs fois leur RIB
- elle permet aux utilisateurs inscrits de procéder à des virements instantanément, sans frais aucun ;
elle permet de remédier à l'absence de DAB dans certaines zones urbaines ou rurales ;
elle permet à des utilisateurs de prépayer et créditer des comptes de monnaie électronique et pas uniquement de payer à l'acte. Les utilisateurs ont un solde dans leur compte de monnaie électronique. Ils peuvent donc recréditer leur solde sur leur compte bancaire,
elle permet de faire transiter la monnaie électronique via le système de réalisation de la transaction dans des comptes séquestres (via les serveurs tiers de l'organisme agréé).
Selon une alternative possible, le procédé de transaction selon l'invention peut être mis en œuvre en envoyant le code d'identification personnel PIN du second terminal Tu au serveur Sk avant l'étape de réception par le serveur du premier terminal d'une demande de création de transaction électronique correspondant à un service demandé ; si cette étape est réalisé correctement, la transmission du code PIN devient facultative dans la validation de la transaction Tr pendant une durée déterminée (typiquement plusieurs minutes, 10 minutes par exemple). Le procédé selon l'invention devient alors un procédé de réalisation d'une transaction électronique d'un service entre un serveur, un premier terminal et un deuxième terminal, le procédé comportant les étapes de :
- envoyer par le deuxième terminal vers le serveur Sk d'un numéro d'identification personnel PIN ;
- recevoir par le serveur du premier terminal une demande de création de transaction électronique correspondant à un service demandé ;
- sauvegarder dans le serveur des premières informations de ladite transaction électronique ;
- envoyer à partir du serveur au premier terminal les premières informations sur ladite transaction électronique ;
- générer par le serveur un code de transaction comprenant un identifiant de ladite transaction électronique et une url ;
- envoyer par le serveur au premier terminal le code de transaction ; - envoyer du serveur au deuxième terminal des secondes informations de ladite transaction électronique à partir du code de transaction scanné par le deuxième terminal, une page Web s'affichant sur l'écran dudit deuxième terminal lorsque ce dernier ne reconnaît pas ladite url ;
- recevoir par le serveur une information de validation de la transaction électronique envoyées par le deuxième terminal ;
- envoyer une confirmation de transaction électronique depuis le serveur vers le premier terminal et vers le deuxième terminal. Une autre possibilité est d'inclure une identification utilisateur
(exemple non limitatif : numéro de téléphone, identifiant utilisateur, adresse email et/ou identifiant facebook) dans la demande de création de transaction électronique Tr. L'étape d'envoi par le serveur Sk au premier terminal Tm du code de transaction QR-C devient alors une étape d'envoi par le serveur Sk au second terminal Tu de l'identifiant de transaction Id et une url. Cette envoi peut se faire par exemple (et de manière non limitatif) en utilisant l'une des technologies suivantes : Apple Push Notification, Android Cloud to Device Messaging, email, SMS, message facebook, du longpolling, du shortpolling et/ou tout autre méthode de notification sur base de protocoles opensource ou propriétaire. Le procédé selon l'invention devient alors un procédé de réalisation d'une transaction électronique d'un service entre un serveur, un premier terminal et un deuxième terminal, le procédé comportant les étapes de :
- recevoir par le serveur du premier terminal une demande de création de transaction électronique correspondant à un service demandé, cette demande incluant une identification de l'utilisateur ;
- sauvegarder dans le serveur des premières informations de ladite transaction électronique incluant un identifiant de transaction généré par le serveur ;
- envoyer à partir du serveur au premier terminal les premières informations sur ladite transaction électronique ;
- envoyer par le serveur au second terminal ledit identifiant de transaction et une url;
- envoyer du serveur au deuxième terminal des secondes informations de ladite transaction électronique à partir de l'identifiant de transaction reçu du serveur par le deuxième terminal, une page Web s'affichant sur l'écran dudit deuxième terminal lorsque ce dernier ne reconnaît pas ladite url ;
- recevoir par le serveur un numéro d'identification personnelle PIN et une information de validation de la transaction électronique envoyées par le deuxième terminal ;
- envoyer une confirmation de transaction électronique depuis le serveur vers le premier terminal et vers le deuxième terminal. On notera que cette dernière alternative peut être combinée avec la précédente en envoyant le code d'identification personnel PIN du second terminal Tu au serveur Sk avant l'étape de réception par le serveur du premier terminal d'une demande de création de transaction électronique correspondant à un service demandé. Une autre situation peut être celle où le premier terminal Tm est aussi le deuxième terminal Tu. Cela peut arriver dans les cas non limitatif où l'utilisateur parcourt un site web mobile ou est sur une application mobile sur le premier terminal Tm. Dans ce cas, il n'y a pas de code de transaction généré ni de scan dudit code mais une étape de transmission d'un identifiant transmis au sein du premier Terminal confondu avec le deuxième terminal. Cette transmission peut se faire par exemple non limitatif au travers l'ouverture d'un schéma/URI sur le premier/deuxième terminal. Selon un mode de réalisation, les informations de transaction peuvent contenir les éléments suivants associés au premier et/ou deuxième terminal: l'adresse IP, l'User Agent, l'adresse DNS du serveur Sk utilisé, le token...

Claims

REVENDICATIONS
1 . Procédé de réalisation d'une transaction électronique d'un service (S) entre un serveur (Sk), un premier terminal (Tm) et un deuxième terminal (Tu), le procédé comportant les étapes de :
- recevoir par le serveur (Sk) du premier terminal (Tm) une demande de création de transaction électronique (Tr) correspondant à un service demandé (S) ;
- sauvegarder dans le serveur (Sk) des premières informations (11 ) de ladite transaction électronique (Tr) ;
- envoyer à partir du serveur (Sk) au premier terminal (Tm) les premières informations (11 ) sur ladite transaction électronique (Tr) ;
- générer par le serveur un code de transaction (QR-C) comprenant un identifiant (Id) de ladite transaction électronique (Tr) et une url ;
- envoyer par le serveur (Sk) au premier terminal (Tm) le code de transaction (QR-C) ;
- envoyer du serveur (Sk) au deuxième terminal (Tu) des secondes informations (12) de ladite transaction électronique à partir du code de transaction scanné (QR-C) par le deuxième terminal (Tu), une page
Web s'affichant sur l'écran dudit deuxième terminal lorsque ce dernier ne reconnaît pas ladite url ;
- recevoir par le serveur (Sk) un numéro d'identification personnelle (PIN) et une information de validation (IVAL) de la transaction électronique (Tr) envoyées par le deuxième terminal (Tu) ;
- envoyer une confirmation de transaction électronique (Tr) depuis le serveur (Sk) vers le premier terminal (Tm) et vers le deuxième terminal (Tu).
2. Procédé selon la revendication 1 , le procédé comportant en outre les étapes supplémentaire de :
- envoyer du premier terminal (Tm) vers le serveur (Sk) la demande de création de transaction électronique (Tr) correspondant à un service demandé (S) ; - recevoir par le premier terminal (Tm) des premières informations (11 ) sur ladite transaction électronique (Tr) envoyées par le serveur (Sk);
- recevoir par le premier terminal (Tm) le code de transaction (QR- C) généré par le serveur (Sk);
- scanner ledit code de transaction (QR-C) au moyen du deuxième terminal (Tu) ;
- recevoir par le deuxième terminal (Tu) des secondes informations (12) de ladite transaction électronique à partir du code de transaction scanné (QR-C) envoyées par le serveur (Sk);
- envoyer du deuxième terminal (Tu) au serveur (Sk) un numéro d'identification personnelle (PIN) et une information de validation (IVAL) de la transaction électronique (Tr) ;
- recevoir par le premier terminal (Tm) et vers le deuxième terminal (Tu) une confirmation de transaction électronique (Tr) envoyée depuis le serveur (Sk).
Procédé selon la revendication 1 ou la revendication 2, selon lequel le procédé comporte en outre une étape supplémentaire de créditer du montant (Mt) de la transaction un premier compte de monnaie électronique vendeur (Cpt1 ) lié au premier terminal (Tm) et de débiter du montant (Mt) de la transaction un deuxième compte de monnaie électronique acheteur (Cpt2) lié au deuxième terminal (Tu).
Procédé selon l'une quelconque des revendications précédentes, selon lequel le procédé comporte en outre une étape supplémentaire de transmettre à partir du serveur (Sk) un ordre de transaction (Ot) correspondant à la transaction électronique validée dans le serveur (Sk) à des serveurs bancaires (Sbq) adaptés pour gérer des comptes à créditer et à débiter relatifs à ladite transaction électronique (Tr).
Procédé selon l'une quelconque des revendications précédentes, selon lequel le code de transaction généré est un QR-Code®.
Procédé selon l'une quelconque des revendications précédentes, selon lequel le premier terminal (Tm) est :
- une caisse enregistreuse ou caisse automatique ; ou
- un ordinateur personnel ; ou - un téléphone portable ; ou
- une tablette portable ;
et le deuxième terminal (Tu) est :
- un téléphone mobile : ou
- une tablette portable.
Procédé selon l'une quelconque des revendications précédentes, selon lequel les premières informations reçues (11 ) par le premier terminal (Tm) comportent un identifiant (Id) de la transaction électronique (Tr).
Procédé selon l'une quelconque des revendications précédentes, selon lequel les premières informations reçues (11 ) par le premier terminal (Tm) comportent en outre :
- un état (St) de la transaction électronique ;
- un type (Ty) de la transaction électronique ;
- le montant (Mt) de la transaction électronique ;
- une description (Ds) de la transaction électronique ;
- une date (Dt) de création.
Premier terminal (Tm) adapté pour coopérer avec au moins un serveur (Sk) et au moins un deuxième terminal (Tu) pour mettre en œuvre le procédé de réalisation d'une transaction électronique selon l'une quelconque des revendications 1 à 8, ledit premier terminal comportant un premier processeur (UC1 ) adapté pour :
- envoyer une demande de création de transaction électronique (Tr) à un serveur (Sk) correspondant à un service demandé (S) ;
- recevoir des premières informations (11 ) sur ladite transaction électronique (Tr) à partir du serveur (Sk) ;
- recevoir un code de transaction (QR-C) généré par le serveur (Sk) ;
- recevoir une confirmation de transaction électronique (Tr) du serveur (Sk).
10. Serveur (Sk) de paiement d'un service (S) adapté pour coopérer avec au moins un premier terminal (Tm) et au moins un deuxième terminal (Tu) pour mettre en œuvre le procédé de réalisation d'une transaction électronique selon l'une quelconque des revendications 1 à 8, ledit serveur (Sk) comprenant un deuxième processeur (UC2) adapté pour : recevoir du premier terminal (Tm) une demande de création de transaction électronique (Tr) correspondant à un service demandé (S) sauvegarder des premières informations (11 ) de ladite transaction électronique (Tr) ;
envoyer à partir du serveur (Sk) au premier terminal (Tm) les premières informations
(11 ) sur ladite transaction électronique (Tr) ; générer un code de transaction (QR-C) comprenant un identifiant (Id) de ladite transaction électronique (Tr) ;
envoyer au premier terminal (Tm) le code de transaction (QR-C) ; envoyer au deuxième terminal (Tu) des secondes informations
(12) de ladite transaction électronique à partir du code de transaction scanné (QR-C) par le deuxième terminal (Tu) ;
recevoir d'un deuxième terminal (Tu) un numéro d'identification personnelle (PIN) et une information de validation (IVAL) de la transaction électronique (Tr) ;
envoyer une confirmation de transaction électronique (Tr) vers le premier terminal (Tm) et vers le deuxième terminal (Tu).
1 . Serveur (Sk) selon la revendication précédente, selon lequel le deuxième processeur (UC2) est en outre adapté pour créditer du montant (Mt) de la transaction un premier compte de monnaie électronique vendeur (Cpt1 ) lié au premier terminal (Tm) et de débiter du montant (Mt) de la transaction un deuxième compte de monnaie électronique acheteur (Cpt2) lié au deuxième terminal (Tu).
2. Serveur (Sk) selon la revendication précédente 12 ou 13, selon lequel le deuxième processeur (UC2) est en outre adapté pour transmettre un ordre de transaction correspondant à la transaction électronique validée dans le serveur (Sk) à des serveurs bancaires (Sbq) adaptés pour gérer des comptes à créditer et à débiter relatifs à ladite transaction électronique (Tr).
13. Deuxième terminal (Tu) adapté pour coopérer avec au moins un serveur (Sk) et au moins un premier terminal (Tm) pour mettre en œuvre le procédé de réalisation d'une transaction électronique selon l'une quelconque des revendications 1 à 8, ledit premier terminal comportant un troisième processeur (UC3) adapté pour :
- scanner ledit code de transaction (QR-C) ;
- recevoir des secondes informations (12) de ladite transaction électronique du serveur à partir du code de transaction scanné (QR- C) ;
- envoyer vers le serveur (Sk) un numéro d'identification personnelle (PIN) et une information de validation (IVAL) de la transaction électronique (Tr) ;
- recevoir une confirmation de transaction électronique (Tr) du serveur (Sk).
14. Système de réalisation d'une transaction électronique d'un service (S) entre un serveur (Sk), un premier terminal (Tm) et un deuxième terminal (Tu), le système comprenant :
- un premier terminal (Tm) selon la revendication 9 ;
- un serveur (Sk) selon l'une quelconque des revendications 10 à
12 ; et
- un deuxième terminal (Tu) selon la revendication 13.
15. Procédé de réalisation d'une transaction électronique d'un service entre un serveur, un premier terminal et un deuxième terminal, le procédé comportant les étapes de :
- envoyer par le deuxième terminal vers le serveur d'un numéro d'identification personnel ;
- recevoir par le serveur du premier terminal une demande de création de transaction électronique correspondant à un service demandé ;
- sauvegarder dans le serveur des premières informations de ladite transaction électronique ;
- envoyer à partir du serveur au premier terminal les premières informations sur ladite transaction électronique ; - générer par le serveur un code de transaction comprenant un identifiant de ladite transaction électronique et une url ;
- envoyer par le serveur au premier terminal le code de transaction ;
- envoyer du serveur au deuxième terminal des secondes informations de ladite transaction électronique à partir du code de transaction scanné par le deuxième terminal, une page Web s'affichant sur l'écran dudit deuxième terminal lorsque ce dernier ne reconnaît pas ladite url ;
- recevoir par le serveur une information de validation de la transaction électronique envoyées par le deuxième terminal ;
- envoyer une confirmation de transaction électronique depuis le serveur vers le premier terminal et vers le deuxième terminal.
16. Procédé de réalisation d'une transaction électronique d'un service entre un serveur, un premier terminal et un deuxième terminal, le procédé comportant les étapes de :
- recevoir par le serveur du premier terminal une demande de création de transaction électronique correspondant à un service demandé, cette demande incluant une identification de l'utilisateur ;
- sauvegarder dans le serveur des premières informations de ladite transaction électronique incluant un identifiant de transaction généré par le serveur ;
- envoyer à partir du serveur au premier terminal les premières informations sur ladite transaction électronique ;
- envoyer par le serveur au second terminal ledit identifiant de transaction et une url ;
- envoyer du serveur au deuxième terminal des secondes informations de ladite transaction électronique à partir de l'identifiant de transaction reçu du serveur par le deuxième terminal, une page Web s'affichant sur l'écran dudit deuxième terminal lorsque ce dernier ne reconnaît pas ladite url ;
- recevoir par le serveur un numéro d'identification personnelle et une information de validation de la transaction électronique envoyées par le deuxième terminal ; envoyer une confirmation de transaction électronique dep serveur vers le premier terminal et vers le deuxième terminal.
PCT/FR2012/052328 2011-10-13 2012-10-12 Procede de realisation d'une transaction electronique WO2013054058A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR1159280 2011-10-13
FR1159280A FR2981479A1 (fr) 2011-10-13 2011-10-13 Procede de realisation d'une transaction electronique

Publications (1)

Publication Number Publication Date
WO2013054058A1 true WO2013054058A1 (fr) 2013-04-18

Family

ID=47116078

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/FR2012/052328 WO2013054058A1 (fr) 2011-10-13 2012-10-12 Procede de realisation d'une transaction electronique

Country Status (2)

Country Link
FR (1) FR2981479A1 (fr)
WO (1) WO2013054058A1 (fr)

Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP1513120A2 (fr) * 2003-09-04 2005-03-09 fun communications GmbH Méthode pour initier une procédure de paiement pour des produits et un système pour effectuer une telle procédure de paiement
EP2088549A1 (fr) * 2008-02-11 2009-08-12 Accenture Global Services GmbH Procédé de paiement initié par le client
EP2128809A1 (fr) * 2008-05-30 2009-12-02 Luc Stals Dispositif de serveur pour contrôler une transaction, entité principale et entité secondaire
US20100211506A1 (en) * 2009-02-19 2010-08-19 Simpleact Incorporated Mobile transaction system and method
US20100320266A1 (en) * 2009-06-23 2010-12-23 At&T Mobility Ii Llc Devices, Systems and Methods for Wireless Point-of-Sale
US20110176705A1 (en) * 2010-01-19 2011-07-21 Felica Networks, Inc. Information processing device, information processing system and program

Patent Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP1513120A2 (fr) * 2003-09-04 2005-03-09 fun communications GmbH Méthode pour initier une procédure de paiement pour des produits et un système pour effectuer une telle procédure de paiement
EP2088549A1 (fr) * 2008-02-11 2009-08-12 Accenture Global Services GmbH Procédé de paiement initié par le client
EP2128809A1 (fr) * 2008-05-30 2009-12-02 Luc Stals Dispositif de serveur pour contrôler une transaction, entité principale et entité secondaire
US20100211506A1 (en) * 2009-02-19 2010-08-19 Simpleact Incorporated Mobile transaction system and method
US20100320266A1 (en) * 2009-06-23 2010-12-23 At&T Mobility Ii Llc Devices, Systems and Methods for Wireless Point-of-Sale
US20110176705A1 (en) * 2010-01-19 2011-07-21 Felica Networks, Inc. Information processing device, information processing system and program

Also Published As

Publication number Publication date
FR2981479A1 (fr) 2013-04-19

Similar Documents

Publication Publication Date Title
JP6717823B2 (ja) モバイルデバイスを通じて自動小売機の提案を提供する方法およびシステム
US8639602B2 (en) System for agent assisted mobile funds transfer and mobile banking
US20080017702A1 (en) System and Method for Conducting Electronic Account Transactions
CN101454795A (zh) 移动的个人之间支付系统
WO2015023172A2 (fr) Systemes et procedes de paiement mobile interpersonnel instantane (p2p)
TW201005667A (en) Cell phone transaction system and method
CN102934133A (zh) 用于计算装置的商务窗口应用的系统和方法
EP1360665A1 (fr) Procede et systeme de telepaiement
CA2552257A1 (fr) Dispositif transactionnel a pre-traitement anticipe
WO2018154082A1 (fr) Système et procédé de traitement d'une transaction bancaire
WO2013001072A1 (fr) Procede de compensation securise de ventes promotionnelles groupees a taux variable et systeme pour le mettre en oeuvre
GB2506421A (en) Electronic receipt
US20150278782A1 (en) Depositing and withdrawing funds
EP3142054A1 (fr) Procédé de transmission de données, dispositifs et programmes d'ordinateur correspondants
EP2824625B1 (fr) Méthode de réalisation de transaction, terminal et programme d'ordinateur correspondant
EP1428183B1 (fr) Procede et systeme permettant de valider, en mettant en oeuvre un objet portable d'un utilisateur, une requete aupres d'une entite
EP1323140B1 (fr) Procede pour fournir des donnees d'identification d'une carte de paiement a un usager
WO2019002703A1 (fr) Contrôle de validité d'une interface de paiement à distance
EP1354288B1 (fr) Procede utilisant les cartes de paiement electroniques pour securiser les transactions
WO2013054058A1 (fr) Procede de realisation d'une transaction electronique
EP2800072A2 (fr) Procédé de délivrance par un automate de cartes de téléphonie mobile SIM à abonnement prépayé ou postpayé
EP3382628A1 (fr) Procédé de traitement de données par un terminal de paiement, terminal de paiement et programme correspondant
FR2815439A1 (fr) Procede pour effectuer une transaction commerciale sur reseau
FR2981480A1 (fr) Procede de realistion d'une transaction electronique
EP4348459A1 (fr) Procédé de traitement d'une transaction, dispositif et programme correspondant

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 12780248

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

32PN Ep: public notification in the ep bulletin as address of the adressee cannot be established

Free format text: CONSTATATION DE LA PERTE D UN DROIT CONFORMEMENT A LA REGLE 112(1) CBE (OEB FORM 1205A EN DATE DU 05/08/2014)

122 Ep: pct application non-entry in european phase

Ref document number: 12780248

Country of ref document: EP

Kind code of ref document: A1