EP3178072A1 - Methode de gestion de transaction par reconnaissance d'immatriculation d'un vehicule - Google Patents

Methode de gestion de transaction par reconnaissance d'immatriculation d'un vehicule

Info

Publication number
EP3178072A1
EP3178072A1 EP14748231.9A EP14748231A EP3178072A1 EP 3178072 A1 EP3178072 A1 EP 3178072A1 EP 14748231 A EP14748231 A EP 14748231A EP 3178072 A1 EP3178072 A1 EP 3178072A1
Authority
EP
European Patent Office
Prior art keywords
transaction
customer
client
vehicle
terminal
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Ceased
Application number
EP14748231.9A
Other languages
German (de)
English (en)
Inventor
Santiago CABALLERO
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Oney Servicios Financieros Efc SAU
Original Assignee
Oney Servicios Financieros Efc SAU
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 Oney Servicios Financieros Efc SAU filed Critical Oney Servicios Financieros Efc SAU
Publication of EP3178072A1 publication Critical patent/EP3178072A1/fr
Ceased legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G07—CHECKING-DEVICES
    • G07C—TIME OR ATTENDANCE REGISTERS; REGISTERING OR INDICATING THE WORKING OF MACHINES; GENERATING RANDOM NUMBERS; VOTING OR LOTTERY APPARATUS; ARRANGEMENTS, SYSTEMS OR APPARATUS FOR CHECKING NOT PROVIDED FOR ELSEWHERE
    • G07C5/00—Registering or indicating the working of vehicles
    • G07C5/008—Registering or indicating the working of vehicles communicating information to a remotely located station
    • 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
    • G06Q10/00—Administration; Management
    • G06Q10/08—Logistics, e.g. warehousing, loading or distribution; Inventory or stock management
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/08—Payment architectures
    • G06Q20/10—Payment architectures specially adapted for electronic funds transfer [EFT] systems; specially adapted for home banking systems
    • G06Q20/102—Bill distribution or payments
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/08—Payment architectures
    • G06Q20/12—Payment architectures specially adapted for electronic shopping systems
    • G06Q20/127—Shopping or accessing services according to a time-limitation
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/32—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using wireless devices
    • G06Q20/322—Aspects of commerce using mobile devices [M-devices]
    • G06Q20/3224—Transactions dependent on location of M-devices
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/32—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using wireless devices
    • G06Q20/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/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/4014—Identity check for transactions
    • 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
    • G06Q30/00—Commerce
    • G06Q30/06—Buying, selling or leasing transactions
    • G—PHYSICS
    • G07—CHECKING-DEVICES
    • G07B—TICKET-ISSUING APPARATUS; FARE-REGISTERING APPARATUS; FRANKING APPARATUS
    • G07B15/00—Arrangements or apparatus for collecting fares, tolls or entrance fees at one or more control points
    • G07B15/06—Arrangements for road pricing or congestion charging of vehicles or vehicle users, e.g. automatic toll systems
    • G07B15/063—Arrangements for road pricing or congestion charging of vehicles or vehicle users, e.g. automatic toll systems using wireless information transmission between the vehicle and a fixed station
    • G—PHYSICS
    • G07—CHECKING-DEVICES
    • G07C—TIME OR ATTENDANCE REGISTERS; REGISTERING OR INDICATING THE WORKING OF MACHINES; GENERATING RANDOM NUMBERS; VOTING OR LOTTERY APPARATUS; ARRANGEMENTS, SYSTEMS OR APPARATUS FOR CHECKING NOT PROVIDED FOR ELSEWHERE
    • G07C9/00—Individual registration on entry or exit
    • G07C9/30—Individual registration on entry or exit not involving the use of a pass
    • G07C9/38—Individual registration on entry or exit not involving the use of a pass with central registration
    • G—PHYSICS
    • G07—CHECKING-DEVICES
    • G07F—COIN-FREED OR LIKE APPARATUS
    • G07F13/00—Coin-freed apparatus for controlling dispensing or fluids, semiliquids or granular material from reservoirs
    • G07F13/02—Coin-freed apparatus for controlling dispensing or fluids, semiliquids or granular material from reservoirs by volume
    • G07F13/025—Coin-freed apparatus for controlling dispensing or fluids, semiliquids or granular material from reservoirs by volume wherein the volume is determined during delivery
    • G06Q50/40—

Definitions

  • the invention relates to the field of securing and simplifying payment methods offered to customers. More particularly, the invention relates to payment methods offered in sales locations likely to accommodate vehicles, such as service stations.
  • place of sale is understood to mean any place that may offer a customer a service or an object of sale by establishing a transaction with the customer.
  • Service stations are the most visible final destination of petroleum products offered to customers, whether private or professional, by fuel distributors. For example, service stations can be set up by fuel distributors, near shopping centers (eg supermarkets, hypermarkets), these distributors being sometimes themselves the managers of said businesses.
  • self-service distribution of fuels with automatic card payment has now been offered to customers for many years. It is thus possible to directly settle a transaction to a fuel pump when it is associated with an electronic payment terminal, via the use of a credit card or a specific card proposed by the fuel distributor to the customer. (private card).
  • These payment methods generally require the physical introduction of the customer's card into a card reader of an electronic payment terminal.
  • the usual procedure for the customer is to insert his card in the reader, wait several seconds during the establishment of a connection between the electronic payment terminal and a remote authorization server, insert the personal code associated with the card and finally withdraw his card once it accepted and start filling the tank of his vehicle.
  • the smooth running of a transaction is conditioned by various physical parameters such as the state of the magnetic strip of the card used (guarantor of its reading), the physical state of the card reader, or the availability of the connection between the electronic payment terminal and the authorization server. So, only one malfunction such as unreadable magnetic stripe, hardware or software malfunction on the drive, or an unavailable connection, prevents any transaction from occurring.
  • Alternative, simplified and user-friendly automated payment solutions for the customer would therefore be particularly advantageous.
  • the present invention aims to meet the aforementioned drawbacks.
  • a first goal is to provide a simplified automated payment method for customers.
  • a second objective is to provide an automated payment method to overcome the physical constraints of a card or an electronic payment terminal disposed at a point of sale.
  • a third objective is to propose an automated payment method that offers improved security conditions for transactions offered to customers.
  • a fourth objective is to propose an automated payment method, allowing the customer to easily manage his / her preferential payment method (s).
  • a fifth objective is to propose an automated payment method adapted to the customer's vehicle.
  • a method of transaction management by recognition of registration of a vehicle of a customer comprising the following steps: - a step of pre-registration by the customer in a data platform via a first terminal of personal identification data, payment data and identification data of at least one vehicle;
  • the data platform offers the customer a fleet management service, this service being provided by
  • the termi nal used for the authentication of the client is a mobile terminal comprising a mobile application, the mobile application being able to propose to the client the update of the data that it has prerecorded, the inputting its personal identification number, display, pre-authorization, status, consultation, recording of transaction history and location of at least one of the closest sales locations the location of the mobile terminal.
  • the data platform comprises
  • a customer management module able to
  • any terminal with an appropriate graphical interface for the pre-registration and / or updating of data by the client in a database
  • the identification of a private card added by the customer in the graphical interface of the client management module is communicated to a private card authentication server interfaced with the client management module and the management module of the client management module.
  • transaction a transaction via a private card is carried out by sending a processing request transaction management module to a private card transaction authorization server, followed by a private card transaction authorization server response to the transaction management module.
  • a first terminal capable of pre-registering in a data platform, personal identification data, payment data and identification data of at least one vehicle entered by the customer in the terminal;
  • the detection and reading means being deployed at a point of sale hosting the vehicle;
  • the data platform being able to
  • o Authenticate the customer by comparing a personal identification number transmitted by the first or second terminal, the terminal used for the authentication of the customer being present at the point of sale;
  • the terminal used for the authentication of the client being able to propose to the client
  • the data platform being further capable of sending an authorization request for the transaction pre-authorized by the client to a transaction authorization server;
  • the transaction authorization server being able to authorize the transaction by transmitting a response to the data platform;
  • the terminal used for client authentication being further able to receive the transaction authorization transmitted by the data platform and inform the client of the transaction authorization.
  • the data platform is able to offer the customer a fleet management service, this service being provided by
  • this information comprising for each vehicle a registration, the make and model of the vehicle, the type of fuel consumed, a budget limit of consumption for one or more vehicles over a configurable period, the combination of each vehicle with one or more pre-registered customers;
  • the customer information of the transactions and the remaining budget for each vehicle via an appropriate display on the first terminal or a message pushed to the terminal used for the authentication of the customer.
  • the terminal used for the authentication of the client is a mobile terminal comprising a mobile application, the mobile application being able to propose to the client the updating of the data that he has pre-recorded, the input of his personal identification number, display, pre-authorization, status, consultation, transaction history record and the location of at least one location closest to the location of the mobile terminal .
  • the data platform comprises
  • a customer management module able to
  • o propose to any terminal an appropriate graphical interface for the data entry and recording by the client in a database; o propose the addition of a bank payment card in the graphical interface, the validation of a bank payment card being carried out by a transaction proposed to the customer and carried out via exchanges between the customer management module and the server of the bank. transaction authorization;
  • this system also comprises
  • a private card authentication server interfaced with the customer management module and the transaction management module, able to receive the identification of a private card added by the customer in the graphical interface of the customer management module;
  • a private card transaction authorization server capable of receiving a transaction request from the transaction management module for a private card and sending a response concerning the request to the transaction management module.
  • Figure 1 is a representation of the automated payment system according to one embodiment
  • Figure 2 is a representation of a portion of the automated payment system according to one embodiment
  • FIG. 3 is a figure illustrating the steps of an automated payment method according to one embodiment.
  • FIG. 1 shows an automated payment system 100 that can be offered to a customer 1 at a given place of sale, involving the presence of at least one vehicle 2.
  • the determined location described in the following this document is a service station.
  • any other place likely to accommodate vehicles 2, to propose to a customer 1 a service or object of sale and to accommodate such a system 100 may be envisaged (ex: toll, parking area, parking).
  • the system 100 is compatible with any registered vehicle 2 and comprises the following elements:
  • detection and reading means 3 capable of capturing and identifying the alphanumeric characters of a vehicle registration plate 2.
  • detection and reading means 3 capable of capturing and identifying the alphanumeric characters of a vehicle registration plate 2.
  • one or more cameras disposed near a fuel pump of the service station, for capturing the images of the front and / or rear license plates of a vehicle 2 ;
  • a terminal 4 present near the place of sale here a fuel pump of the service station, this terminal 4 being able to offer the means to the customer 1 to perform the transaction.
  • the terminal 4 is
  • An electronic payment terminal comprising a touch screen, provided with an internet connection, arranged in a fixed manner near the fuel pump and offering the client 1 a selection interface, and transaction management.
  • Such an interface is for example made by a human interface
  • HMI Touch machine
  • this terminal comprising means of data communications via a wireless network, for example a tablet or a smartphone with a data link Wifi, Bluetooth, 2G, 3G or 4G;
  • a wireless network for example a tablet or a smartphone with a data link Wifi, Bluetooth, 2G, 3G or 4G;
  • a server a set of servers or more generally a data platform 5 (described later), including in particular data relating to the client 1 and its vehicle 2, the data platform 5 being able to exchange data via a pre-established connection with the terminal 4; a transaction authorization server 6, allowing to authorize or refuse a transaction, based for example on the bank balance of a customer 1 or its presence in a list of customers 1 authorized or prohibited.
  • the automated payment system 100 allows a transaction to be conducted, from initiation to validation (or prohibition), as follows:
  • a customer 1 with his vehicle 2 arrives at a place of sale, here a service station provided with at least one gas pump;
  • the data platform 5 then performs a comparison step between the registration of the vehicle 2 and the pre-recorded vehicle information in the data platform 5, in order to identify the vehicle 2 corresponding to this registration as well as the customer (s) (s) 1 using this vehicle 2; the data platform 5 transmits (arrow 103) then back to the terminal 4, according to the identified vehicle 2, a client identification request 1;
  • the terminal 4 then invites the client 1 to enter a personal password or a personal identification number ("PIN" code) previously known, it then returns to the data platform 5 for verification;
  • PIN personal identification number
  • the data platform 5 transmits to the terminal 4 preconfigured transaction information relating to the client 1, for example a theoretical value and preconfigured transaction function of customer 1 and his vehicle the terminal 4 proposes (arrow 103) then to the client 1 a transaction via an appropriate display, the displayed transaction being a function of the information transmitted by the data platform 5;
  • the client 1 validates it via a selection menu displayed on the terminal 4.
  • the client 1 can also, if necessary, modify some of the parameters of the transaction via a selection menu, then validate that one. here or cancel it;
  • the terminal 4 transmits (arrow 103) then the selected transaction to the data platform 5;
  • the data platform 5 interrogates (arrow 104) then the transaction authorization server 6 in order to authorize or not the transaction;
  • the client 1 is then informed by the terminal 4 (arrow 103) whether or not it is authorized to perform an action relating to the transaction.
  • the customer 1 is informed by the terminal 4 that he can use an authorized and unlocked fuel pump, in order to fill the tank of his vehicle 2 with fuel;
  • the point of sale here the fuel pump
  • This amount may, for example, slightly differ from the theoretical amount of the proposed transaction, because of the fuel dispensing accuracy of the fuel pump;
  • the data platform 5 retransmits (arrow 104) the actual amount of the transaction to the transaction authorization server 6 in order to bill the customer 1.
  • the automated payment system 100 allows both the support of specific payment cards proposed by a predetermined seller (private cards), for example a fuel distributor, as well as any bank payment card.
  • the data platform 5 comprises a customer management module 7, enabling the customer 1 to provide information concerning its payment means and its vehicle (s) 2.
  • the customer management module 7 proposes a graphical interface allowing the client 1 to provide this information.
  • Such a graphical interface may, for example, be accessible from a predefined internet address, and allows data exchanges (arrow 200) according to the HTTPS secure hypertext transfer protocol, between any terminal 8 having a network connection and the customer management module 7.
  • the terminal 8 may be an example of a computer, a smartphone, a tablet, or the terminal 4 disposed near the point of sale.
  • the graphical interface of the customer management module 7 offers to any customer 1 the possibility of creating a user account.
  • a customer 1 is invited to enter the following information:
  • o his identity (surname, first name for an individual, name of the company for a professional client);
  • o contact information (email, phone number);
  • a user-specific identification code for example a personal identification number PIN (acronym of "Personal Identification Number”);
  • the amount of fuel proposed by default by the fuel pump for each vehicle 2 for example the choice of a desired fixed price associated with the type of fuel or the choice of a desired fixed volume of fuel; the choice of the desired payment method, for example an immediate debit, deferred, or monthly payments;
  • all the information entered by the client 1 in the graphical interface of the client management module 7 is stored in a database 9 constituting, or interfaced externally, with this module.
  • the client management module 7 is able both to complete / retrieve (arrow 201) any data provided by the client / prerecorded in the database 9.
  • the information provided to database 9 may subsequently be modified or supplemented by client 1.
  • the customer 1 identifies himself beforehand via a specific identification code, for example via his personal PIN identification number that he has previously chosen, as well as information relating to his identity (eg email, or name user).
  • any individual customer 1 or professional having a plurality of vehicles 2 can then use the graphical interface of the customer management module 7, such as a vehicle fleet management service 2.
  • a vehicle fleet management service 2 such as a vehicle fleet management service 2.
  • an administrator using this interface is able to register a specific number of employees and assign them a specific vehicle 2.
  • the graphical interface of the client management module 7 also makes it possible to configure expenditure thresholds.
  • the expenditure thresholds defined by a user apply during a configurable time period via the graphical interface.
  • the graphical interface of the customer management module 7 proposes to choose one (or more) date of "recharge” periodic (ex: every 5 and / or 20 of the month), to reset after said period elapsed, the balance of expenses remaining authorized relative to the maximum threshold preconfigured.
  • the interface of the client management module 7 proposes to a client 1, after selecting a payment card, to set a maximum threshold of expenditure, for example a vehicle-specific expense threshold 2, and / or a "global" spending threshold, ie shared with a set of vehicles 2.
  • the interface of the customer management module 7 proposes to the administrator to set a maximum threshold of expenditure per user for a user. configurable period.
  • the customer management module 7 is able to calculate the remaining balance with respect to the preconfigured maximum expenditure threshold, to communicate it to the customer 1 via the graphical interface, and possibly to send push notifications (ex SMS text messages, email on a mobile terminal 4) to the client 1 if the remaining balance is below an alert threshold, which can also be preconfigured by the user by means of the graphical interface of the module.
  • customer management 7. In the example of a company, each employee can be communicated by the administrator, an identifier (eg email, encrypted sequence of identification) and a password / specific code by default, for example a personal identification number PIN, allowing access to the vehicle fleet management interface 2.
  • Access to this interface is then performed for the employee as a simple user (limitation configurable parameters), allowing it to possibly reconfigure its personal PIN identification number, choose an available car from the company's fleet of vehicles 2, consult its consumption including its remaining balance, or consult a prerecorded history of transactions that he has previously performed.
  • the personal identification number configurable for each user of a same vehicle 2 is unique. This allows, in particular, to discriminate transactions for customers 1 sharing in turn the same vehicle 2.
  • the vehicle fleet management 2 proposed by the graphical interface of the customer management module 7 also allows a supplier of a client company, for example an oil company supplying hypermarket chains with fuel, to ensure that each of its client companies proposes payment guarantees.
  • the client management module 7 can provide a graphical interface separated from the graphical interface proposed to the clients 1, and accessible from an Internet address that is distinct from the address of the graphical interface proposed to the clients 1.
  • Such an interface allows, for example, a supplier to add as many client companies as needed, by entering in the graphical interface for each company a customer name, a unique ID, and the tax number of the company. After this addition, it is then possible for him to supervise the data provided by the client companies, for example
  • the registration of a bank payment card for a client 1 is as follows: a client 1 performs a prior connection step to the graphical interface of the customer management module 7 ;
  • the client 1 selects in the interface a menu for managing payment cards, made for example via the implementation in the interface g graphic of a button "adding payment cards";
  • the customer management module 7 then asks the user to enter his card number said PAN (acronym for
  • a server 6 for authorization of transaction able to decrypt through the same algorithm this information and validate or not transactions for this card.
  • the validation of a transaction by the server 6 is based in particular on a list of authorized cards, the balance of the bank card of the customer 1, as well as the state of the information
  • the transaction authorization server 6 proposes to the customer 1 a first transaction, via the collection of charges on the customer's account 1.
  • the transaction authorization server 6 then transmits a challenge in accordance with the 3D-Secure protocol to the client management module 7, the latter proposing it to the client 1 via the graphical interface.
  • the client validates the proposed transaction by entering in the graphical interface the correct answer to this challenge, this response being retransmitted from the client management module 7 to the transaction authorization server 6;
  • the transaction authorization server 6 validates the transaction and authorizes the bank card. Once the credit card validated, the server 6 then generates a unique identification token (“token”) specific to the added credit card, then returns this authentication token to the customer management module 7;
  • the information relating to the added card as well as the corresponding generated authentication token are then stored encrypted by the customer management module 7 in a table of the database 9.
  • such a method makes it possible during subsequent requests for transaction to the transaction authorization server 6, after prior identification of the client 1 and validation of one of its payment cards, to communicate during exchanges between the client management module. 7 and the transaction authorization server 6 that the authentication token corresponding to this card, and this without transmission of sensitive information (eg PAN, CVC) related to the customer's bank card 1.
  • sensitive information eg PAN, CVC
  • a communication mechanism (arrow 202) is used between the client management module 7 and the transaction authorization server 6 in accordance with the PCI / DSS (acronym for "Payait Card Industry Data Security Standard") standards.
  • P2PE an end-to-end encryption
  • P2PE an end-to-end encryption
  • the private card authentication server 10 is then able to manage only this type of card, and is for example realized via an existing proprietary server solution, 7.
  • the client management module 7 and the private card authentication server 10 exchange (arrow 203) a set of data depending on the deployed proprietary solution.
  • the customer management module 7 communicates to the private card authentication server 10, one or more encrypted information relating to the private card entered by the client 1, for example the card number, as well as information concerning the identity of the client 1. This information is also stored in the database 9, the latter being accessible by the private card authentication server 10 ( arrow 201).
  • the data communication between the client management module 7 and the private card authentication server 10 is performed via the secure hypertext transfer protocol HTTPS combined with the advanced encryption standard (encryption algorithm) AES, acronym for "Advanced Encryption Standard".
  • the data platform 5 further comprises a transaction management module 11 interfaced with the private card authentication server 10.
  • the transaction management module 11 and the private card authentication server 10 are capable to establish a communication (arrow 204) allowing the exchange of data, via the secure hypertext transfer protocol HTTPS combined with the advanced encryption standard (encryption algorithm) AES.
  • the transaction management module 11 is able to exchange data with
  • a private card transaction authorization server 12 (arrow 205). Like the private card authentication server 10, the private card transaction authorization server 12 is deployed as needed to handle the transactions with the privative cards. Such a server can also be realized via a proprietary solution.
  • the transaction management module 11 then communicates with the private card transaction authorization server 12 via the MPLS data transport protocol, the acronym for "MultiProtocol Label Switching".
  • the private card transaction authorization server 12 is in charge of managing only the transactions carried out with privative cards, whereas the transaction authorization server 6 is in charge of managing the transactions. made via bank cards.
  • the transaction management module 11 also comprises an interface for exchanging data (arrow 206) with the detection and reading means 3, able to capture and identify the alphanumeric characters of the license plate of the vehicle 2.
  • a transaction according to the proposed automated payment system 100 indeed requires the identification of the vehicle 2 and therefore the transmission of the registration of the vehicle 2 to the platform 5 of data.
  • the communication of the data between the transaction management module 11 and the detection and reading means 3 is for example carried out via the HTTPS secure hypertext transfer protocol combined with the encryption standard. advanced (encryption algorithm) AES.
  • the transaction management module 11 offers a client 1 a graphical interface, allowing it to participate in a transaction, by displaying selected preconfigured transaction information (eg: proposed fuel quantity, proposed transaction price), this information. which can be modified by the customer 1. So that the client 1 can interact with the transaction management module 1 1, the graphical interface of this module is accessible from a predefined internet address, and allows data exchange (arrow 206) according to the secure hypertext transfer protocol HTTPS from any terminal 4 present near the point of sale. Such a graphical interface is therefore also accessible by a touch screen deployed by the distributor at the point of sale, than from a smartphone in possession of the customer 1 present at the point of sale.
  • preconfigured transaction information eg: proposed fuel quantity, proposed transaction price
  • HTTPS secure hypertext transfer protocol
  • the graphical interface associated with the client management module 7 previously described can be implemented in different forms.
  • the graphical interface is in the form of a website accessible from any terminal provided with an internet connection, and / or is also implemented as a mobile application offered to mobile terminals such as Smartphones or tablets.
  • a customer 1 with a Smartphone can optionally create an account via the mobile application or a website.
  • the use of the mobile application after authentication, then allows him to update the information he has provided (eg personal data, the vehicle, means of payment) and take part in transactions on a place. of sales, via a graphical interface specific to the mobile application.
  • a mobile application offers the client 1 at least the same services as those offered by the graphical interfaces of the client management module 7 and the transaction management module 11.
  • Other services may also be offered to the client 1 by this application, for example the possibility of consult a personal history of transactions;
  • push type push method, for example via SMS or email, a message comprising information relating to each transaction made by the client 1;
  • FIG. 3 illustrates, in agreement with the elements previously described, the various steps relating to a transaction conducted between a client 1 and the automated payment system 100.
  • the step (300) relates to a pre-registration step of the client 1.
  • This pre-registration step is performed by the client 1 by connecting to a pre-established internet site via a terminal 8 or by using a mobile application previously downloaded and installed on a mobile terminal in his possession.
  • the website and the mobile application offer the client 1 a graphical interface suitable for entering this information;
  • the customer 1 arrives with his vehicle 2 at a point of sale, for example a service station.
  • the place of sale comprises a terminal 4 which may be a fixed terminal arranged by the seller at the point of sale, or a mobile terminal in the possession of the customer 1.
  • the terminal 4 includes a secure connection with the transaction management module 11, the latter managing an interface This connection can be preconfigured in the case of a fixed terminal, or established by the user for a mobile terminal via the opening of the mobile application.
  • the client 1 has the possibility of selecting, on the graphical interface of the terminal 4 (managed by the transaction management module 11), a "conventional" payment method (physical reading of a card in its entirety). possession), the proposed automated payment method described in the following steps;
  • detection and reading means 3 such as cameras arranged in the vicinity of the place of sale, capture and recognize (“reading") the registration data of the vehicle 2 (step 302);
  • the registration data of the vehicle 2 are communicated in a message by the detection and reading means 3 to the transaction management module 11 (step 303).
  • the detection and reading means 3 additionally add, for purposes of identification in the transmitted message, the date and time of reading of the registration of the vehicle 2, as well as the number of the fuel pump where the vehicle 2; in step (304) the transaction management module 11 seeks to identify, via a step of comparison with the prerecorded data in database 9, the identity of the vehicle 2 and its user. If the vehicle 2 does not appear in the database 9, this means that the user has not prerecorded data relating to this vehicle 2.
  • the transaction management module 11 transmits an error message to be displayed on the terminal 4 and / or a message inviting the client 1 to perform the pre-registration step (300) if it wishes to use the proposed self-payment service (step 305). ;
  • the client 1 is then invited to enter via the terminal 4 an identification code, for example a PIN code (step 306) that it prerecorded in database 9;
  • an identification code for example a PIN code (step 306) that it prerecorded in database 9;
  • the terminal 4 displays a transaction proposal (step 307), in according to the data provided by the client 1 during the pre-registration step (300).
  • the proposed transaction is for example a quantity of fuel given for a predefined price, it may also be a function of the expenditure thresholds that the client 1 will preconfigured;
  • the client 1 then has the possibility via the graphical interface of the terminal 4 to validate the transaction (step 308) directly, or modify it (step 309) before validating it, if it wishes for example to perform a transaction at a price lower.
  • the transaction validation step (308) by the client 1 may possibly be seen as a pre-authorization step, the transaction authorization server 6 being solely responsible for the final authorization;
  • the transaction amount validated by the client 1 on the terminal 4 is transmitted transaction management module 11, which then verifies whether such a transaction is possible.
  • the transaction management module module 11 interrogates (step 310) via a transaction request, the transaction authorization server 6, on the possibility of such a bank transaction;
  • the transaction authorization server 6 notifies the transaction management module 11.
  • the transaction management module 11 then sends jointly (step 311)
  • the transaction management module 11 o an authorization message to an entity, provided with means of communication with the transaction management module 11, present at the point of sale and allowing the client 1 to access the transaction object.
  • the transaction management module 11 sends a control message to a fuel dispensing pump lock device, enabling the pump of the fuel specified in the transaction to be automatically unlocked;
  • the fuel pump informs the transaction management module 11 and he transmits the actual amount of fuel dispensed as well as the final amount of the transaction.
  • the transaction management module 11 transmits the final amount of the transaction to the transaction authorization server 6 to debit the client 1 (step 312);
  • the terminal 4 displays the details of the transaction for the client 1 (step 314).
  • the details of this transaction can be for example, displayed on a fixed screen deployed by the seller at the end of the transaction, printed by selecting a menu on the fixed terminal, pushed by SMS or email to the mobile terminal of the client 1, or still displayed by the mobile application of the mobile terminal of the client 1, which can also access, download and / or record the history of the transactions made by the customer 1.
  • the transactions carried out for private cards follow the same steps as those described above with the exception that the exchanges made between the transaction management module 11 and the transaction authorization server 6 are replaced by exchanges between the transaction management module 11 and a private card transaction authorization server 12.
  • the previously described embodiments make it possible to propose a payment solution based on the automatic recognition of the vehicle plates 2, and apply equally to the payment of fuel in service stations or in any other place likely to propose a solution.
  • automated payment system for vehicles for example a road toll zone, a parking zone or a parking lot.
  • Another advantage is the simplicity of the payment method offered to the client 1, allowing it to carry out transactions much faster than with existing methods, such as those involving physical use of a payment card.
  • the proposed embodiments also allow each client 1 to manage their own electronic wallet, via the addition and use of one or more payment cards, which may as well be private cards distributed by a specific seller (ex. hypermarket) than bank credit cards. The integration of new cards does not affect the user experience.
  • a terminal 4 is then specific to each client 1 and no longer shared between several clients 1, thus greatly limiting the possible impacts on a set of clients 1 in the event of hacking of a terminal 4.
  • the identification of a Client 1 results both from the recognition of the registration of his vehicle 2 combined with the entry by the customer of a password or PIN. A transaction can therefore be performed only after a preauthorization of the client 1, requiring in advance a step of authentication of said client 1;
  • the client 1 to manage (eg consult, modify, delete) personally his own identifiers and data from a single mobile application;
  • Customer 1 to receive push notifications, such as a summary of an SMS finalized transaction, targeted advertising, and manage personal discount coupons.
  • Another advantage of the automated payment system 100 described above is the implementation of a service for managing information relating to a fleet of vehicles 2.
  • a service may, by way of example, be a seller providing his services to a plurality of client companies (ex: fuel distribution), a company to manage the fleet of vehicles 2 made available to its employees, an individual / a professional with a plurality of vehicles he wants to manage the mode of consumption.

Abstract

Méthode de gestion de transaction par reconnaissance d'immatriculation d'un véhicule (2) cette méthode comprenant: - une étape de pré-enregistrement par un client (1) de données d'identification personnelles, de paiements et d'identification d'au moins un véhicule (2); - une étape de lecture de l'immatriculation d'un véhicule (2); - une étape de transmission de l'immatriculation du véhicule (2) à une plateforme (5) de données; - une étape d'identification du véhicule (2) par la plateforme (5) de données; - une étape d'authentification du client (1) par la saisie d'un numéro personnel d'identification; - une étape de proposition de transaction au client (1) authentifié; - une étape de pré-autorisation par le client (1) de la transaction; - une étape d'autorisation de transaction par un serveur (6) d'autorisation de transaction; - une étape d'information du client (1) de l'autorisation de transaction.

Description

METHODE DE GESTION DE TRANSACTION PAR RECONNAISSANCE D'IMMATRICULATION D'UN VEHICULE
L'invention a trait au domaine de la sécurisation et de la simplification des méthodes de paiement proposées aux clients. Plus particulièrement, l'invention a trait aux méthodes de paiement proposées dans les lieux de ventes susceptibles d'accueillir des véhicules, tels des stations services.
On entend par la suite par lieu de vente, tout lieu susceptible de proposer à un client un service ou un objet de vente, via l'établissement d'une transaction avec le client.
Les stations services constituent le lieu d'acheminement final le plus visible des produits pétroliers proposés aux clients, particuliers ou professionnels, par les distributeurs de carburants. A titre d'exemple, des stations services peuvent être implantées par des distributeurs de carburants, à proximité de lieux de commerces (ex : supermarchés, hypermarchés), ces distributeurs étant parfois eux-mêmes les gérants desdits commerces. Par ailleurs, la distribution libre-service de carburants avec paiement automatique par carte est maintenant proposée aux clients depuis de nombreuses années. Il est ainsi possible de régler directement une transaction à une pompe à carburant lorsque celle-ci est associée à un terminal de paiement électronique, via l'utilisation d'une carte bancaire ou d'une carte spécifique proposée par le distributeur de carburants au client (carte privative). Ces modes de paiements nécessitent généralement l'introduction physique de la carte du client dans un lecteur de cartes d'un terminal de paiement électronique. La procédure, classique pour le client, consiste à insérer sa carte dans le lecteur, patienter plusieurs secondes durant l'établissement d'une connexion entre le terminal de paiement électronique et un serveur d'autorisation distant, insérer le code personnel associé à la carte et enfin retirer sa carte une fois celle-ci acceptée et commencer à remplir le réservoir de son véhicule. Ainsi, le bon déroulement d'une transaction est conditionné par divers paramètres physiques tels que l'état de la bande magnétique de la carte utilisée (garante de sa lecture), l'état physique du lecteur de carte, ou encore la disponibilité de la connexion entre le terminal de paiement électronique et le serveur d'autorisation. Ainsi, un seul dysfonctionnement tel qu'une bande magnétique illisible, une anomalie matérielle ou logicielle sur le lecteur, ou une connexion indisponible, empêche toute réalisation de transaction. Des solutions de paiements automatisés alternatives, simplifiées et conviviales pour le client seraient donc particulièrement avantageuses.
La présente invention a pour objectif de répondre aux inconvénients précités.
Un premier objectif est de proposer une méthode de paiement automatisée simplifiée pour les clients.
Un deuxième objectif est de proposer une méthode de paiement automatisée permettant de s'affranchir des contraintes physique d'une carte ou d'un terminal de paiement électronique disposé sur un lieu de vente.
Un troisième objectif est de proposer une méthode de paiement automatisée proposant des conditions de sécurité améliorées lors des transactions proposées aux clients.
Un quatrième objectif est de proposer une méthode de paiement automatisée, permettant au client de gérer facilement son/ses mode(s) de paiement(s) préférentiel(s).
Un cinquième objectif, est de proposer une méthode de paiement automatisée, adaptée en fonction du véhicule du client.
A cet effet, il est proposé, selon un premier aspect, une méthode de gestion de transaction par reconnaissance d'immatriculation d'un véhicule d'un client, cette méthode comprenant les étapes suivantes : - une étape de pré-enregistrement par le client dans une plateforme de données via un premier terminal de données d'identification personnelles, de données de paiements et de données d'identification d'au moins un véhicule ;
une étape de lecture de l'immatriculation d'un véhicule du client par des moyens de détection et de lecture déployés sur un lieu de vente accueillant le véhicule ;
une étape de transmission de l'immatriculation du véhicule lue par les moyens de détection et de lecture à la plateforme de données ; une étape d'identification du véhicule par la plateforme de données, en comparant l'immatriculation lue du véhicule et les données d'identification d'au moins un véhicule préenregistré ; une étape d'authentification du client par la saisie d'un numéro personnel d'identification propre au client, dans le premier ou dans un deuxième terminal, le terminal utilisé pour l'authentification du client étant présent sur le lieu de vente ;
- une étape de proposition de transaction au client authentifié, par le terminal utilisé pour l'authentification du client, la transaction proposée étant fonction des informations des données préenregistrées par le client et du véhicule identifié ;
une étape de pré-autorisation par le client de la transaction proposée ;
une étape d'envoi à un serveur d'autorisation de transaction d'une requête d'autorisation par la plateforme de données pour la transaction pré-autorisée par le client ;
une étape d'autorisation de transaction par le serveur d'autorisation de transaction, via la transmission d'une réponse à la plateforme de données ;
une étape de transmission de l'autorisation de transaction par la plateforme de données au terminal utilisé pour l'authentification du client ;
- une étape d'information du client de l'autorisation de transaction, par le terminal utilisé pour l'authentification du client.
Avantageusement, dans cette méthode, la plateforme de données propose au client un service de gestion de flottes de véhicules, ce service étant réalisé par
- la saisie par le client dans le premier terminal d'un ensemble d'informations relatives à une pluralité de véhicules, ces informations comprenant pour chaque véhicule une immatriculation, la marque et le modèle du véhicule, le type de carburant consommé, un budget limite de consommation pour un ou plusieurs véhicules sur une période configurable, l'association de chaque véhicule à un ou plusieurs clients préenregistrés ;
un calcul par la plateforme de données du budget de consommation restant pour chaque véhicule ou chaque client, en fonction des transactions effectuées par chaque client ;
- l'information du client des transactions et du budget restant pour chaque véhicule via un affichage approprié sur le premier terminal ou un message poussé vers le terminal utilisé pour l'authentification du cl ient.
Avantageusement, dans cette méthode, le termi nal utilisé pour l'authentification du client est u n terminal mobile comportant une application mobile, l'application mobile étant apte à proposer a u client la m ise à jour des données q u'il a préenregistré, la saisie de son nu méro personnel d'ide ntification, l'affichage, la pré-autorisation , le statut, la consultation , l'enreg istrement de l'historique de transactions et la localisation d'au moins un lieu de vente le plus proche de la loca lisation du terminal mobile.
Avantageusement, dans cette méth ode, la plateforme de données comprend
un module de gestion client apte à
o proposer à tout terminal une interface graphique appropriée pour le pré-enregistrement et/ou la mise à jour de données par le client dans une base de données ;
o proposer l'ajout et la validation d'une carte de paiem ent banca ire dans l'interface graphique, la validation de la carte de paiement bancaire étant réalisée par une transaction ;
- un module de gestion de transaction apte
o à fournir à tout terminal présent sur le l ieu de vente , une interface graphique apte à authentifier le client, afficher la proposition de transaction , permettre au client de pré-autoriser cette transaction , informer le client du déroulement de la transaction ;
o à envoyer au serveu r d'autorisation de transaction une req uête d'autorisation pour la transaction pré-autorisée par le client et recevoir la réponse du serveur d'autorisation de transaction.
Avantageusement, dans cette méthode,
- l'identification d'une carte privative ajoutée par le client dans l'interface g raphique du module de gestion client est communiq uée à un serveur d 'authentification de carte privative interfacé avec le module de gestion client et le modu le de gestion de transaction ; une transaction via une carte privative est réalisée par l'envoi d'une req uête de tra nsaction du module de gestion de transaction à un serveur d 'autorisation de transactions de carte privative, suivie d'une réponse serveur d'autorisation de transactions de carte privative au module de gestion de transaction.
Il est proposé, selon un deuxième aspect, un système de paiement automatisé par reconnaissance d'immatriculation d'un véhicule d'un client, ce système comprenant
un premier terminal apte à préenregistrer dans une plateforme de données, des données d'identification personnelles, des données de paiements et des données d'identification d'au moins un véhicule saisies par le client dans le terminal ;
- des moyens de détection et de lecture aptes
o à lire l'immatriculation d'un véhicule du client, les moyens de détection et de lecture étant déployés sur un lieu de vente accueillant le véhicule ;
o à transmettre l'immatriculation du véhicule lue à la plateforme de données ;
la plateforme de données étant apte à
o identifier le véhicule, en comparant l'immatriculation lue du véhicule et les données d'identification d'au moins un véhicule préenregistré ;
o authentifier le client par comparaison d'un numéro personnel d'identification transmis par le premier ou un deuxième terminal, le terminal utilisé pour l'authentification du client étant présent sur le lieu de vente ;
le terminal utilisé pour l'authentification du client étant apte à proposer au client
o la saisie du numéro personnel d'identification propre au client ; o une transaction fonction des informations des données préenregistrées par le client et du véhicule identifié ;
o une pré-autorisation de la transaction proposée ;
- la plateforme de données étant en outre apte à envoyer à un serveur d'autorisation de transaction une requête d'autorisation pour la transaction pré-autorisée par le client ;
le serveur d'autorisation de transaction étant apte à autoriser la transaction par la transmission d'une réponse à la plateforme de donnée; le terminal (utilisé pour l'authentification du client étant en outre apte à recevoir l'autorisation de transaction transmise par la plateforme de données et informer le client de l'autorisation de transaction.
Avantageusement, dans ce système, la plateforme de données est apte à proposer au client un service de gestion de flottes de véhicules, ce service étant réalisé par
la saisie par le client dans le premier terminal d'un ensemble d'informations relatives à une pluralité de véhicules, ces informations comprenant pour chaque véhicule une immatriculation, la marque et le modèle du véhicule, le type de carburant consommé, un budget limite de consommation pour un ou plusieurs véhicules sur une période configurable, l'association de chaque véhicule à un ou plusieurs clients préenregistrés ;
- un calcul par la plateforme de données du budget de consommation restant pour chaque véhicule ou chaque client, en fonction des transactions effectuées par chaque client ;
l'information du client des transactions et du budget restant pour chaque véhicule via un affichage approprié sur le premier terminal ou un message poussé vers le terminal utilisé pour l'authentification du client.
Avantageusement, dans ce système, le terminal utilisé pour l'authentification du client est un terminal mobile comportant une application mobile, l'application mobile étant apte à proposer au client la mise à jour des données qu'il a préenregistré, la saisie de son numéro personnel d'identification, l'affichage, la pré-autorisation, le statut, la consultation, l'enregistrement de l'historique de transactions et la localisation d'au moins un lieu de vente le plus proche de la localisation du terminal mobile.
Avantageusement, dans ce système, la plateforme de données comprend
un module de gestion client apte à
o proposer à tout terminal une interface graphique appropriée pour la saisie et l'enregistrement de données par le client dans une base de données ; o proposer l'ajout d'une carte de paiement bancaire dans l'interface graphique, la validation d'une carte de paiement bancaire étant réalisée par une transaction proposée au client et réalisée via des échanges entre le module de gestion client et le serveur d'autorisation de transaction ;
un module de gestion de transaction apte
o à proposer tout terminal utilisé pour l'authentification du client, une interface graphique appropriée pour l'affichage, la modification, la pré-autorisation de la transaction proposée au client ;
o communiquer avec le serveur d'autorisation de transaction, via l'envoi d'une requête d'autorisation pour la transaction préautorisée par le client ;
Avantageusement, ce système, comprend en outre
- un serveur d'authentification de carte privative interfacé avec le module de gestion client et le module de gestion de transaction, apte à recevoir l'identification d'une carte privative ajoutée par le client dans l'interface graphique du module de gestion client ;
un serveur d'autorisation de transactions de carte privative apte à recevoir une requête de transaction du module de gestion de transaction pour une carte privative et envoyer une réponse concernant la requête au module de gestion de transaction.
D'autres objets et avantages de l'invention apparaîtront à la lumière de la description de modes de réalisation, faite ci-après en référence aux dessins annexés dans lesquels :
la figure 1 est une représentation du système de paiement automatisé selon un mode de réalisation ;
la figure 2 est une représentation d'une partie du système de paiement automatisé selon un mode de réalisation ;
- la figure 3 est une figure illustrant les étapes d'une méthode de paiement automatisé selon un mode de réalisation.
Sur la figure 1 est représenté un système 100 de paiement automatisé pouvant être proposé à un client 1 sur un lieu de vente déterminé impliquant la présence d'au moins un véhicule 2. A titre d'exemple, le lieu déterminé décrit dans la suite de ce document est une station service. Cependant tout autre lieu susceptible d'accueillir des véhicules 2, de proposer à un client 1 un service ou un objet de vente et accueillir un tel système 100 peut être envisagé (ex : péage, zone de stationnement, parking). Avantageusement, le système 100 est compatible avec tout véhicule 2 immatriculé et comprend les éléments suivants :
des moyens 3 de détection et de lecture, aptes à capturer et identifier les caractères alphanumériques d'une plaque d'immatriculation du véhicule 2. Ces moyens 3 sont par exemple réalisés par un système comprenant
o une ou plusieurs caméras (ou tout autre dispositif de capture d'image) disposées à proximité d'une pompe à carburant de la station service, permettant de capturer les images des plaques d'immatriculation avant et/ou arrière d'un véhicule 2 ;
o une méthode implémentée dans un micrologiciel permettant de déterminer l'immatriculation du véhicule 2 à partir d'une ou plusieurs images capturées;
un terminal 4 présent à proximité du lieu de vente, ici une pompe à carburant de la station service, ce terminal 4 étant apte à proposer des moyens au client 1 pour effectuer la transaction. A titre d'exemple, le terminal 4 est
o un terminal de paiement électronique comprenant un écran tactile, muni d'une connexion internet, disposé de manière fixe à proximité de la pompe à essence et proposant au client 1 une interface de sélection, et de gestion de transaction. Une telle interface est par exemple réalisée par une Interface Homme
Machine (IHM) tactile ;
o tout terminal mobile en possession du client 1, ce terminal comprenant des moyens de communications de données via un réseau sans fil, par exemple une tablette ou un Smartphone muni d'une liaison de données Wifi, Bluetooth, 2G, 3G ou 4G ;
un serveur, un ensemble de serveurs ou plus généralement une plateforme 5 de données (décrite ultérieurement), comprenant notamment des données relatives au client 1 et à son véhicule 2, la plateforme 5 de données étant apte à échanger des données via une connexion préétablie avec le terminal 4 ; un serveur 6 d'autorisation de transaction, permettant d'autoriser ou refuser une transaction, en fonction par exemple du solde bancaire d'un client 1 ou de sa présence dans une liste de clients 1 autorisés ou interdits.
Le fonctionnement du système 100 est maintenant décrit de manière simplifiée et sera d'avantage détaillé par la suite. Dans un mode de réalisation, le système 100 de paiement automatisé permet le déroulement d'une transaction, de son initiation jusqu'à sa validation (ou son interdiction), de la manière suivante :
un client 1 muni de son véhicule 2 arrive sur un lieu de vente, ici une station service munie d'au moins une pompe à essence ;
des moyens 3 de détection et de lecture de caractères alphanumériques, déployés sur le lieu de vente, par exemple une ou plusieurs caméras, « lisent » (pointillés 101) la plaque d'immatriculation du véhicule 2 et transmettent (flèche 102) ensuite à la plateforme 5 de données l'information d'immatriculation du véhicule 2 identifiée;
la plateforme 5 de données effectue ensuite une étape de comparaison entre l'immatriculation du véhicule 2 et des informations de véhicules préenregistrées dans la plateforme 5 de données, en vue d'identifier le véhicule 2 correspondant à cette immatriculation ainsi que le(s) client(s) 1 utilisant ce véhicule 2 ; la plateforme 5 de donnée transmet (flèche 103) alors en retour au terminal 4, en fonction du véhicule 2 identifié, une requête d'identification du client 1 ;
le terminal 4 invite alors le client 1 à saisir un mot de passe personnel ou un numéro personnel d'identification (code « PIN ») préalablement connu, qu'il retourne ensuite à la plateforme 5 de données pour vérification ;
si l'identification relative au client 1 est effective (ex : code PIN saisi correct), la plateforme 5 de données transmet alors au terminal 4 des informations de transactions préconfigurées et relatives au client 1, par exemple une valeur théorique et préconfigurée de transaction fonction du client 1 et de son véhicule le terminal 4 propose (flèche 103) alors au client 1 une transaction via un affichage approprié, la transaction affichée étant fonction des informations transmises par la plateforme 5 de données ;
si la transaction proposée convient au client 1, ce dernier la valide via un menu de sélection affiché sur le terminal 4. Le client 1 peut aussi, au besoin, modifier certains des paramètres de la transaction via un menu de sélection, valider ensuite celle-ci ou encore l'annuler ;
après validation d'une transaction par le client 1, le terminal 4 transmet (flèche 103) alors la transaction sélectionnée à la plateforme 5 de données ;
la plateforme 5 de données interroge (flèche 104) ensuite le serveur 6 d'autorisation de transaction en vue d'autoriser ou non la transaction ;
- en fonction de la réponse du serveur 6 d'autorisation de transaction (flèche 104), le client 1 est alors informé par le terminal 4 (flèche 103) s'il est ou non autorisé à effectuer une action relative à la transaction. Par exemple, le client 1 est informé par le terminal 4 qu'il peut utiliser une pompe à essence autorisée et déverrouillée, afin de remplir le réservoir de son véhicule 2 en carburant ;
lorsque le client 1 a terminé l'action relative à la transaction, ici remplir de carburant le réservoir de son véhicule 2, le point de vente, ici la pompe à carburant, transmet alors à la plateforme 5 de données le montant réel de la transaction. Ce montant peut, à titre d'exemple, légèrement différer du montant théorique de la transaction proposée, du fait de la précision de distribution de carburant par la pompe à carburant ;
la plateforme 5 de données retransmet (flèche 104) alors le montant réel de la transaction au serveur 6 d'autorisation de transaction en vue de la facturation du client 1.
Divers modes de réalisations plus détaillés sont maintenant décrits en référence à la figure 2.
Dans un mode de réalisation, le système 100 de paiement automatisé permet à la fois la prise en charge de cartes de paiements spécifiques proposées par un vendeur prédéterminé (cartes privatives), par exemple un distributeur de carburants, ainsi que toute carte de paiement bancaire. Pour ce faire, la plateforme 5 de données comprend un module de gestion client 7, permettant au client 1 de fournir des informations concernant ses moyens de paiements et son/ses véhicules(s) 2. Avantageusement, le module de gestion client 7 propose une interface graphique permettant au client 1 de fournir ces informations. Une telle interface graphique, peut à titre d'exemple, être accessible depuis une adresse internet prédéfinie, et permet des échanges de données (flèche 200) selon le protocole de transfert hypertexte sécurisé HTTPS, entre tout terminal 8 disposant d'une connexion réseau et le module de gestion client 7. Le terminal 8 peut être à titre d'exemple, un ordinateur, un Smartphone, une tablette, ou encore le terminal 4 disposé à proximité du lieu de vente.
Ainsi, pour une première utilisation, l'interface graphique du le module de gestion client 7 propose à tout client 1 la possibilité de création d'un compte utilisateur. Lors de la création d'un compte, un client 1 est notamment invité à saisir les informations suivantes :
des informations personnelles
o son identité (nom, prénom pour un particulier, nom de l'entreprise pour un client professionnel) ;
o ses coordonnées (courriel, numéro de téléphone) ;
o son numéro fiscal ;
o les numéros d'une ou plusieurs cartes de paiement (carte spécifique d'un vendeur et/ou carte bancaire) ;
o choix d'un code d'identification spécifique à l'utilisateur, par exemple d'un numéro personnel d'identification PIN (acronyme anglais de « Personal Identification Number ») ;
des informations concernant son/ses véhicule(s) 2
o le numéro d'immatriculation de chaque véhicule 2 qu'il souhaite utiliser avec le service de paiement proposé par le système
100 de paiement automatisé ;
o la marque et le modèle de chacun de ces véhicules 2 ;
o le type de carburant utilisé par chacun de ces véhicules 2 ;
o la quantité de carburant proposée par défaut par la pompe à essence pour chaque véhicule 2, par exemple le choix d'un prix fixe souhaité associé au type de carburant ou le choix d'un volume fixe de carburant souhaité ; le choix du mode de paiement souhaité, par exemple un débit immédiat, différé, ou des mensualisations ;
la sélection d'un moyen de paiement préférentiel par défaut, via la sélection d'un numéro de carte préenregistré auparavant par le client 1.
Selon divers modes de réalisations, l'ensemble des informations saisies par le client 1 dans l'interface graphique du module de gestion client 7 est enregistré dans une base de données 9 constitutive, ou interfacée de manière externe, avec ce module. Ainsi, le module de gestion client 7 est apte à la fois à compléter/récupérer (flèche 201) toute donnée fournie par le client/ préenregistrée dans la base de données 9.
Notamment, lors d'utilisations ultérieures de l'interface graphique du module de gestion client 7 par le client 1, les informations fournies à la base de données 9, peuvent être par la suite, modifiées ou complétées par le client 1. Pour ce faire, le client 1 s'identifie au préalable via un code d'identification spécifique, par exemple via son numéro personnel d'identification PIN qu'il aura auparavant choisi, ainsi qu'une information relative à son identité (ex : courriel, ou nom d'utilisateur).
Avantageusement, tout client 1 particulier ou professionnel (ex : entreprise), disposant d'une pluralité de véhicules 2 peut alors utiliser l'interface graphique du module de gestion client 7, comme un service de gestion de flotte de véhicules 2. Par exemple, dans le cadre de la gestion de flotte de véhicules 2 d'une entreprise, un administrateur utilisant cette interface, est capable d'enregistrer un nombre déterminé d'employés et leur assigner un véhicule 2 spécifique. Pour un tel service, l'interface graphique du module de gestion client 7, permet en outre de configurer des seuils de dépenses.
Avantageusement, les seuils de dépenses définis par un utilisateur s'appliquent durant une période temporelle configurable via l'interface graphique. Pour ce faire, l'interface graphique du module de gestion client 7 propose de choisir une (ou plusieurs) date de « recharge » périodique (ex : tous les 5 et/ou 20 du mois), permettant de réinitialiser après ladite période écoulée, le solde de dépenses restant autorisé par rapport au seuil maximal préconfiguré. Ainsi, dans un mode de réalisation, l'interface du module de gestion client 7 propose à un client 1, après sélection d'une carte de paiement, de fixer un seuil maximal de dépense, par exemple un seuil de dépense propre à un véhicule 2, et/ou un seuil de dépenses « global », c'est à dire partagé avec un ensemble de véhicules 2. Dans un autre mode de réalisation, afin d'assurer la gestion de plusieurs utilisateurs par un administrateur, l'interface du module de gestion client 7 propose à l'administrateur de fixer un seuil maximal de dépense par utilisateur pour une période configurable.
Ainsi, dans les modes de réalisations précédents, le module de gestion client 7 est apte à calculer le solde restant par rapport au seuil de dépense maximal préconfiguré, le communiquer au client 1 via l'interface graphique, et éventuellement envoyer des notifications poussées (ex : par messages textes SMS, courriel sur un terminal 4 mobile) au client 1 si le solde restant se situe en dessous d'un seuil d'alerte, pouvant aussi être préconfiguré par l'utilisateur au moyen de l'interface graphique du module de gestion client 7. Dans l'exemple d'une entreprise, chaque employé pourra se voir communiquer par l'administrateur, un identifiant (ex : courriel, séquence chiffrée d'identification) et un mot de passe/code spécifique par défaut, par exemple un numéro personnel d'identification PIN, lui permettant d'accéder à l'interface de gestion de flotte des véhicules 2. L'accès à cette interface, s'effectue alors pour l'employé en tant que simple utilisateur (limitation des paramètres configurables), lui permettant de reconfigurer éventuellement son numéro personnel d'identification PIN, choisir une voiture disponible parmi la flotte de véhicules 2 de l'entreprise, consulter sa consommation notamment son solde restant, ou encore consulter un historique préenregistré des transactions qu'il a auparavant effectué. Avantageusement, le numéro personnel d'identification configurable pour chaque utilisateur d'un même un véhicule 2 est unique. Ceci permet notamment, de discriminer les transactions pour des clients 1 partageant à tour de rôle un même véhicule 2.
Avantageusement, la gestion de flotte de véhicules 2 proposée par l'interface graphique du module de gestion client 7 permet aussi à un fournisseur d'une compagnie cliente, par exemple une compagnie pétrolière fournissant en carburant des chaînes d'hypermarché, de s'assurer que chacune de ses entreprises clientes propose des garanties de paiement. Pour ce faire, le module de gestion client 7 peut proposer une interface graphiq ue séparée de l' interface graphique proposée aux clients 1 , et accessible depuis une adresse internet distincte de l'adresse de l'interface graphique proposée aux clients 1 . Une telle interface permet par exemple, à un fournisseur, d 'ajouter autant d'entreprises clientes que nécessa ire, en saisissant dans l'interface graphiq ue pour chaque entreprise cl iente u n nom , un identifiant I D unique, ainsi que le numéro fiscal de l'entreprise. Après cet ajout, il lui est alors possible de superviser les données fournies par les entreprises clientes, par exemple
les seuils de dépenses maximum préconfigurés, définissant la garantie financière de chaque entreprise cliente ;
le solde courant disponible de l 'entreprise cliente pour led it servie proposé ;
- la date de réi nitialisation périodique du so lde de l'entreprise cliente ;
l'historique des transactions de l'entreprise cliente ;
les véhicules 2 et utilisateurs déclarés par l'entreprise cli ente afin de bénéficier dudit service.
Dans un mode de réalisation , l'en registrement d'u ne carte de paiement bancaire pour un client 1 s'effectue de la manière suivante : un client 1 effectue une étape de connexion préalable à l'interface graphique du module de gestion client 7 ;
lors de la création d'un nouveau compte, ou de la mise à jour de ses informations personnelles, le client 1 sélectionne dans l'interface un menu de gestion des cartes de paiement, réalisé par exemple via l' implémentation dans l'interface g raphique d'un bouton « ajout de cartes de paiements » ;
le module de gestion client 7 demande alors à l'utilisateur de renseigner son numéro de carte dit PAN (acronyme anglais de
« Primary Account Number ») , la date d'expiration de sa carte , ainsi que son cryptogramme visuel, par exem ple le code de vérification de carte dit CVV2 (acronyme anglais de « Card Vérification Value») ;
- l'ensemble de ces données sont alors transmises de m anière cryptée via un algo rithme à un serveur 6 d 'autorisation de transaction, apte à décrypter via le même algorithme ces informations et valider ou non des transactions pour cette carte. A titre d'exemple, la validation d'une transaction par le serveur 6 est fonction notamment d'une liste de cartes autorisées, du solde de la carte bancaire du client 1, ainsi que de l'état des informations
(correctes ou erronées) saisies par le client 1 et transmises par le module de gestion client 7;
avantageusement, afin de valider la carte ajoutée, le serveur 6 d'autorisation de transaction propose au client 1 une première transaction, via le prélèvement de frais sur le compte du client 1.
Le serveur 6 d'autorisation de transaction transmet alors un challenge en accord avec le protocole 3D-Secure au module de gestion client 7, ce dernier le proposant au client 1 via l'interface graphique. Le client valide alors la transaction proposée en saisissant dans l'interface graphique la réponse correcte à ce challenge, cette réponse étant retransmise du module de gestion client 7 au serveur 6 d'autorisation de transaction ;
si la réponse au challenge retournée est correcte, le serveur 6 d'autorisation de transaction valide la transaction et autorise la carte bancaire. Une fois la carte bancaire validée, le serveur 6 génère alors un jeton d'identification (« token ») unique et spécifique à la carte bancaire ajoutée, puis retourne ce jeton d'authentification au module de gestion client 7 ;
les informations relatives à la carte ajoutée ainsi que le jeton d'authentification généré correspondant sont alors stockés de manière encryptée par le module de gestion client 7 dans une table de la base de données 9.
Avantageusement, une telle méthode permet lors de requêtes ultérieures de transaction au serveur 6 d'autorisation de transaction, après identification préalable du client 1 et validation d'une de ses cartes de paiements, de ne communiquer lors des échanges entre le module de gestion client 7 et le serveur 6 d'autorisation de transaction que le jeton d'authentification correspondant à cette carte, et ce sans transmission d'informations sensibles (ex : PAN, CVC) liées à la carte bancaire du client 1. Un tel mécanisme renforce donc la sécurité des transactions. Il est entendu que toute communication entre le module de gestion client 7 et le serveur 6 d'autorisation de transaction est aussi sécurisée. Ainsi, on utilise entre le module de gestion client 7 et le serveur 6 d'autorisation de transaction, un mécanisme de communication (flèche 202) en accord avec les normes PCI/DSS (acronyme anglais de « Payaient Card Industry Data Security Standard »). A titre d'exemple, on utilise pour les échanges de données entre le module de gestion client 7 et le serveur 6 d'autorisation de transaction, un chiffrement bout en bout dit P2PE (acronyme anglais de « Point-to-Point Encryption »).
En outre, si besoin de séparer la gestion (par exemple l'ajout et l'authentification) de cartes bancaires des cartes privatives, c'est-à-dire des cartes distribuées et spécifiques à un vendeur, ces dernières peuvent dans un mode de réalisation, être supervisées par un serveur d'authentification de carte privative 10. Avantageusement, le serveur d'authentification de carte privative 10 est alors apte à gérer uniquement ce type de carte, et est par exemple réalisé via une solution propriétaire existante de serveur, interfacée avec le module de gestion client 7. Ainsi, selon divers modes de réalisations, pour toute utilisation d'une carte privative, par exemple lors d'un premier enregistrement de la carte ou lors d'une demande de transaction via cette carte, le module de gestion client 7 et le serveur d'authentification de carte privative 10 échangent (flèche 203) un ensemble de données fonction de la solution propriétaire déployée. A titre d'exemple, lors du premier enregistrement par un client 1 d'une carte privative, le module de gestion client 7 communique au serveur d'authentification de carte privative 10, une ou plusieurs informations encryptées relatives à la carte privative saisie par le client 1, par exemple le numéro de carte, ainsi que des informations concernant l'identité du client 1. Ces informations sont elles aussi stockées dans la base de données 9, cette dernière étant accessible par le serveur d'authentification de carte privative 10 (flèche 201).
Avantageusement, la communication de données entre le module de gestion client 7 et le serveur d'authentification de carte privative 10 est réalisée via le protocole de transfert hypertexte sécurisé HTTPS combiné avec le standard de chiffrement avancé (algorithme de chiffrement) AES, acronyme anglais de « Advanced Encryption Standard ». La plateforme 5 de données comprend, en outre, un module de gestion de transaction 11 interfacé avec le serveur d'authentification de carte privative 10. Avantageusement, le module de gestion de transaction 11 et le serveur d'authentification de carte privative 10 sont aptes à établir une communication (flèche 204) permettant l'échange de données, via le protocole de transfert hypertexte sécurisé HTTPS combiné avec le standard de chiffrement avancé (algorithme de chiffrement) AES. En outre, le module de gestion de transaction 11 est apte à échanger des données avec
- le module de gestion client 7 et la base de données 9 de la plateforme 5 de données (flèche 201) ;
tout terminal 4 présent à proximité du lieu de vente ;
en accord avec les normes PCI/DSS, par exemple en utilisant le un chiffrement bout en bout P2PE (flèche 202) ;
- un serveur d'autorisation de transactions de carte privative 12 (flèche 205). Tout comme le serveur d'authentification de carte privative 10, le serveur d'autorisation de transactions de carte privative 12 est déployé si besoin pour gérer les transactions avec les cartes privatives. Un tel serveur peut lui aussi être réalisé via une solution propriétaire. Avantageusement, le module de gestion de transaction 11 communique alors avec le serveur d'autorisation de transactions de carte privative 12 via le protocole de transport de données MPLS, acronyme anglais de « MultiProtocol Label Switching ». Ainsi, dans un mode de réalisation, le serveur d'autorisation de transactions de carte privative 12 est en charge de gérer uniquement les transactions effectuées avec des cartes privatives, tandis que le serveur 6 d'autorisation de transaction est en charge de gérer les transactions effectuées via des cartes bancaires.
Le module de gestion de transaction 11 comprend par ailleurs une interface permettant d'échanger des données (flèche 206) avec les moyens 3 de détection et de lecture, aptes à capturer et identifier les caractères alphanumériques de la plaque d'immatriculation du véhicule 2. Une transaction selon le système 100 de paiement automatisé proposé, nécessite en effet l'identification du véhicule 2 et donc la transmission de l'immatriculation du véhicule 2 à la plateforme 5 de données. Afin de garantir l'intégrité des données échangées, la communication des données entre le module de gestion de transaction 11 et les moyens 3 de détection et de lecture, est par exemple réalisée via le protocole de transfert hypertexte sécurisé HTTPS combiné avec le standard de chiffrement avancé (algorithme de chiffrement) AES.
Avantageusement, le module de gestion de transaction 11 propose à un client 1 une interface graphique, lui permettant de participer à une transaction, en affichant des informations de transactions préconfigurées sélectionnâmes (ex : quantité de carburant proposée, prix de transaction proposé) , ces informations pouvant être modifiées par le client 1 . Afin que le client 1 puisse interagir avec le module de gestion de transaction 1 1 , l'interface graphique de ce module est accessible depuis une adresse internet prédéfinie, et permet des échanges de données (flèche 206) selon le protocole de transfert hypertexte sécurisé HTTPS depuis tout terminal 4 présent à proximité du lieu de vente. Une telle interface graphique est donc aussi bien accessible par un écran tactile déployé par le distributeur sur le lieu de vente, que depuis un Smartphone en possession du client 1 présent sur le lieu de vente.
Par ailleurs, l'interface graphique associée au module de gestion client 7 précédemment décrite peut être réalisée sous différentes formes. Selon divers modes de réalisations, l'interface graphique se présente sous la forme d'un site internet accessible depuis tout terminal muni d'une connexion internet, et/ou est aussi réalisée sous forme d'application mobile proposée à des terminaux mobiles tels que des Smartphones ou des tablettes .
Ainsi, un client 1 muni d'un Smartphone peut au choix créer un compte via l'application mobile ou un site internet. L'utilisation de l'application mobile, après authentification, lui permet alors par la suite de mettre à jour les informations qu'il a fourni (ex : données personnelles, du véhicule, moyens de paiements) et prendre part aux transactions sur un lieu de vente, via une interface graphique propre à l'application mobile. Avantageusement, une telle application mobile propose au client 1 au moins les mêmes services que ceux proposés par les interfaces graphiques du module de gestion client 7 et le module de gestion de transaction 11 . D'autres services peuvent par ailleurs être proposés au client 1 par cette application , par exem ple la possibilité de consulter un historique personnel des transactions ;
tirer profit des moyens de géo-localisations embarqués dans le terminal mobile utilisateur, pour proposer au moins un lieu de vente, ici une station service, identifié comme le plus proche par rapport à la localisation du terminal ;
recevoir selon une méthode poussée dite de type « push », par exemple via SMS ou courriel, un message comprenant des informations relatives à chaque transaction effectuée par le client 1 ;
- recevoir de la publicité personnalisée ;
pouvoir gérer un ensemble de coupons électroniques, d'offres de promotions, de programmes de fidélité, fournissant ainsi une ludification de l'expérience client.
La figure 3 illustre, en accord avec les éléments précédemment décrits, les différentes étapes se rapportant à une transaction conduite entre un client 1 et le système 100 de paiement automatisé.
l'étape (300) se rapporte à une étape de pré-enregistrement du client 1. Un client 1 muni d'un véhicule 2, et souhaitant bénéficier d'un service d'auto-paiement par reconnaissance d'immatriculation du véhicule 2, fournit au module de module de gestion client 7 des informations relatives à son identité, à son véhicule 2, ses modes de consommations préférés, le mode de transaction souhaité, et choisit un code PIN. Cette étape de pré-enregistrement est effectuée par le client 1 en se connectant à un site internet préétabli via un terminal 8 ou en utilisant une application mobile préalablement téléchargée et installée sur un terminal mobile en sa possession. Avantageusement, le site internet et l'application mobile proposent au client 1 une interface graphique appropriée à la saisie de ces informations ;
- à l'étape (301) le client 1 arrive avec son véhicule 2 sur un lieu de vente, par exemple une station service. Avantageusement, le lieu de vente comprend un terminal 4 qui peut être un terminal fixe disposé par le vendeur sur le lieu de vente, ou un terminal mobile en possession du client 1. Afin d'effectuer une transaction, le terminal 4 comprend une connexion sécurisée avec le module de gestion de transaction 11, ce dernier gérant une interface graphique affichée sur le terminal 4. Une telle connexion peut être préconfigurée dans le cas d'un terminal fixe, ou établie par l'utilisateur pour un terminal mobile via l'ouverture de l'application mobile. Optionnellement, le client 1 a la possibilité de sélectionner au choix sur par l'interface graphique du terminal 4 (gérée par le module de gestion de transaction 11), soit une méthode de paiement « classique » (lecture physique d'une carte en sa possession), soit la méthode de paiement automatisé proposée, décrite dans les étapes suivantes ;
- dans ce dernier cas, des moyens 3 de détection et de lecture, tels des caméras disposées au voisinage du lieu de vente, capturent et reconnaissent (« lecture ») les données d'immatriculation du véhicule 2 (étape 302) ;
une fois reconnues, les données d'immatriculation du véhicule 2 sont communiquées dans un message par les moyens 3 de détection et de lecture au module de gestion de transaction 11 (étape 303). Les moyens 3 détection et de lecture ajoutent par ailleurs, à des fin d'identification dans le message transmis, la date et l'heure de lecture de l'immatriculation du véhicule 2, ainsi que le numéro de pompe à carburant où se situe le véhicule 2 ; à l'étape (304) le module de gestion de transaction 11 cherche à identifier, via une étape de comparaison avec les données préenregistrées dans base de données 9, l'identité du véhicule 2 et de son utilisateur. Si le véhicule 2 ne figure pas dans la base de données 9, cela signifie que l'utilisateur n'a pas préenregistré des données relatives à ce véhicule 2. Le module de gestion de transaction 11 transmet alors un message d'erreur à afficher sur le terminal 4 et/ou un message invitant le client 1 à effectuer l'étape (300) de pré-enregistrement s'il souhaite utiliser le service d'auto- paiement proposé (étape 305). ;
si le véhicule 2 est identifié par le module de gestion client 7 dans la base de données 9, le client 1 est alors invité à saisir via le terminal 4 un code d'identification, par exemple un code PIN (étape 306) qu'il a préenregistré dans la base de données 9 ;
- si le code d'identification saisi par le client 1 est valide, le terminal 4 affiche alors une proposition de transaction (étape 307), en fonction des données fournies par le client 1 lors de l'étape (300) de pré-enregistrement. La transaction proposée est par exemple une quantité de carburant donnée pour un prix prédéfini, celle-ci pouvant être aussi fonction des seuils de dépenses que le client 1 aura préconfiguré ;
le client 1 a alors soit la possibilité via l'interface graphique du terminal 4 de valider la transaction (étape 308) directement, soit la modifier (étape 309) avant de la valider, s'il souhaite par exemple effectuer une transaction à un prix moins élevé. L'étape de validation (308) de transaction par le client 1, peut éventuellement être vue comme une étape de pré-autorisation, le serveur 6 d'autorisation de transaction étant seul responsable de l'autorisation finale ;
le montant de transaction validé par le client 1 sur le terminal 4 est transmis module de gestion de transaction 11, qui vérifie ensuite si une telle transaction est possible. Pour ce faire le module de module de gestion de transaction 11 interroge (étape 310) via une requête de transaction, le serveur 6 d'autorisation de transaction, sur la possibilité d'une telle transaction bancaire ;
si une telle transaction est autorisée, le serveur 6 d'autorisation de transaction en notifie le module de gestion de transaction 11. Le module de gestion de transaction 11 envoie alors conjointement (étape 311 )
o un message d'autorisation à une entité, munie de moyens de communication avec le module de gestion de transaction 11, présente sur le lieu de vente et permettant au client 1 d'accéder à l'objet de transaction. Par exemple le module de gestion de transaction 11 envoie un message de commande à un dispositif de verrouillage de pompe de distribution de carburant, permettant de déverrouiller automatiquement la pompe du carburant spécifié dans la transaction ;
o un message au terminal 4 informant le client 1 qu'il peut maintenant accéder à l'objet de sa transaction, par exemple un message l'informant que la pompe correspondante est déverrouillée et qu'il peut maintenant remplir le réservoir de son véhicule 2 ; lorsque le client 1 a terminé de procéder à l'accès de l'objet de la transaction, par exemple terminé de remplir son réservoir de carburant, le point de vente, ici la pompe à essence informe le module de gestion de transaction 11 et lui transmet la quantité réelle de carburant distribuée ainsi que le montant final de la transaction. Le module de gestion de transaction 11 transmet alors le montant final de la transaction au serveur 6 d'autorisation de transaction pour débiter le client 1 (étape 312) ;
les détails de la transaction sont alors enregistrés par le module de gestion de transaction 11 dans la base de données 9 (étape
313). Le terminal 4 affiche alors les détails de la transaction à destination du client 1 (étape 314). Les détails de cette transaction peuvent être par exemple, affichés sur un écran fixe déployé par le vendeur à la fin de la transaction, imprimés en sélectionnant un menu sur le terminal fixe, poussés par SMS ou courriel vers le terminal mobile du client 1, ou encore affichés par l'application mobile du terminal mobile du client 1, pouvant par ailleurs accéder, télécharger et/ou enregistrer l'historique des transactions effectuées par le client 1.
Dans un mode de réalisation, les transactions effectuées pour des cartes privatives suivent les mêmes étapes que celles précédemment décrites à la différence que les échanges réalisés entre le module de gestion de transaction 11 et le serveur 6 d'autorisation de transaction, sont remplacés par des échanges entre le module de gestion de transaction 11 et un serveur d'autorisation de transactions de carte privative 12.
Avantageusement, les modes de réalisations précédemment décrits permettent de proposer une solution de paiement basée sur la reconnaissance automatique des plaques de véhicules 2, et s'appliquent aussi bien au paiement de carburant dans les stations services que dans tout autre lieu susceptible de proposer une solution de paiement automatisé pour des véhicules, par exemple une zone de péage routier, une zone de stationnement ou un parking.
Un autre avantage est la simplicité de la méthode paiement proposée au client 1, lui permettant ainsi d'effectuer des transactions bien plus rapidement qu'avec les méthodes existantes, telles celles impliquant une utilisation physique d'une carte de paiement. Les modes de réalisations proposés permettent par ailleurs à chaque client 1 de gérer son propre portefeuille électronique, via l'ajout et l'utilisation d'une ou plusieurs cartes de paiement, pouvant aussi bien être des cartes privatives distribuées par un vendeur spécifique (ex : hypermarché) que des cartes de crédit bancaire. L'intégration de nouvelles cartes n'affecte en rien l'expérience utilisateur.
Avantageusement, la possibilité pour un client 1 d'utiliser un terminal mobile avec le système 100 de paiement automatisé précédemment décrit permet en outre
- au client 1 d'interagir avec la plateforme 5 de données sans avoir nécessairement besoin d'utiliser un terminal déployé par un vendeur sur un lieu de vente ;
à tout vendeur d'effectuer des économies financières, en évitant d'avoir à déployer nécessairement de nouveaux terminaux 4 interactifs sur leurs points de ventes ;
de renforcer le niveau de sécurité du service proposé pour chaque utilisateur. Un terminal 4 est alors propre à chaque client 1 et non plus partagé entre plusieurs clients 1, limitant ainsi fortement les éventuels impacts sur un ensemble de clients 1 en cas de piratage d'un terminal 4. De plus, l'identification d'un client 1 résulte à la fois de la reconnaissance de l'immatriculation de son véhicule 2 combiné avec la saisie par le client d'un mot de passe ou code PIN. Une transaction ne peut donc être effectuée qu'après une préautorisation du client 1, nécessitant au préalable une étape d'authentification dudit client 1 ;
au client 1 de gérer (ex : consulter, modifier, supprimer) personnellement ses propres identifiants et données depuis une unique application mobile ;
au client 1 de recevoir des notifications poussées, par exemple un résumé d'une transaction finalisée par SMS, de la publicité ciblée et gérer des coupons de réductions personnels.
Un autre avantage, du système 100 de paiement automatisé précédemment décrit, est l'implémentation d'un service permettant de gérer des informations relatives à une flotte de véhicules 2. Un tel service peut, à titres d'exemples, aussi bien être proposé à un vendeur fournissant ses services à une pluralité d'entreprises clientes (ex : distribution de carburant), une entreprise afin de gérer la flotte des véhicules 2 mis à disposition de ses employés, un particulier/un professionnel possédant une pluralité de véhicules dont il souhaite gérer le mode de consommation.

Claims

REVENDICATIONS
1. Méthode de gestion de transaction par reconnaissance d'immatriculation d'un véhicule (2) d'un client (1), cette méthode comprenant les étapes suivantes :
une étape de pré-enregistrement (300) par le client (1) dans une plateforme (5) de données via un premier terminal (4), (8), de données d'identification personnelles, de données de paiements et de données d'identification d'au moins un véhicule (2) ;
- une étape de lecture (302) de l'immatriculation d'un véhicule (2) du client (1) par des moyens (3) de détection et de lecture déployés sur un lieu de vente accueillant le véhicule (2) ;
une étape de transmission (303) de l'immatriculation du véhicule (2) lue par les moyens (3) de détection et de lecture à la plateforme (5) de données ;
une étape d'identification (304) du véhicule (2) par la plateforme (5) de données, en comparant l'immatriculation lue du véhicule (2) et les données d'identification d'au moins un véhicule (2) préenregistré ;
- une étape d'authentification (306) du client (1) par la saisie d'un numéro personnel d'identification propre au client (1), dans le premier ou dans un deuxième terminal (4), (8), le terminal (4), (8) utilisé pour l'authentification du client (1) étant présent sur le lieu de vente ;
- une étape de proposition (307) de transaction au client (1) authentifié, par le terminal (4), (8) utilisé pour l'authentification du client (1), la transaction proposée étant fonction des informations des données préenregistrées par le client (1) et du véhicule (2) identifié ;
- une étape de pré-autorisation (308) par le client (1) de la transaction proposée ;
une étape d'envoi (310) à un serveur (6) d'autorisation de transaction d'une requête d'autorisation par la plateforme (5) de données pour la transaction pré-autorisée par le client (1) ; une étape d'autorisation de transaction par le serveur (6) d'autorisation de transaction, via la transmission d'une réponse à la plateforme de données (5) ;
une étape de transmission de l'autorisation de transaction par la plateforme (5) de données au terminal (4), (8) utilisé pour l'authentification du client (1) ;
une étape d'information du client (1) de l'autorisation de transaction, par le terminal (4), (8) utilisé pour l'authentification du client (1).
2. Méthode selon la revendication 1, dans laquelle la plateforme (5) de données propose au client (1) un service de gestion de flottes de véhicules (2), ce service étant réalisé par
la saisie par le client (1) dans le premier terminal (4), (8) d'un ensemble d'informations relatives à une pluralité de véhicules (2), ces informations comprenant pour chaque véhicule (2) une immatriculation, la marque et le modèle du véhicule (2), le type de carburant consommé, un budget limite de consommation pour un ou plusieurs véhicules (2) sur une période configurable, l'association de chaque véhicule (2) à un ou plusieurs clients (1) préenregistrés ;
un calcul par la plateforme (5) de données du budget de consommation restant pour chaque véhicule (2) ou chaque client (1), en fonction des transactions effectuées par chaque client (1) ; - l'information du client (1) des transactions et du budget restant pour chaque véhicule (2) via un affichage approprié sur le premier terminal (4), (8) ou un message poussé vers le terminal (4), (8) utilisé pour l'authentification du client (1).
3. Méthode selon la revendication 1 ou 2, dans laquelle le terminal (4), (8) utilisé pour l'authentification du client (1) est un terminal mobile comportant une application mobile, l'application mobile étant apte à proposer au client (1) la mise à jour des données qu'il a préenregistré, la saisie de son numéro personnel d'identification, l'affichage, la pré-autorisation, le statut, la consultation, l'enregistrement de l'historique de transactions et la localisation d'au moins un lieu de vente le plus proche de la localisation du terminal mobile.
4. Méthode selon l'une quelconque des revendications 1 à 3, dans laquelle la plateforme (5) de données comprend
un module de gestion client (7) apte à
o proposer à tout terminal (4), (8) une interface graphique appropriée pour le pré-enregistrement et/ou la mise à jour de données par le client (1) dans une base de données (9) ;
o proposer l'ajout et la validation d'une carte de paiement bancaire dans l'interface graphique, la validation de la carte de paiement bancaire étant réalisée par une transaction ;
un module de gestion de transaction (11) apte
o à fournir à tout terminal (4), (8) présent sur le lieu de vente, une interface graphique apte à authentifier le client (1), afficher la proposition de transaction, permettre au client (1) de préautoriser cette transaction, informer le client du déroulement de la transaction ;
o à envoyer au serveur (6) d'autorisation de transaction une requête d'autorisation pour la transaction pré-autorisée par le client (1) et recevoir la réponse du serveur (6) d'autorisation de transaction.
5. Méthode selon la revendication 4, dans laquelle
l'identification d'une carte privative ajoutée par le client (1) dans l'interface graphique du module de gestion client (7) est communiquée à un serveur d'authentification de carte privative (10) interfacé avec le module de gestion client (7) et le module de gestion de transaction (11) ;
une transaction via une carte privative est réalisée par l'envoi d'une requête de transaction du module de gestion de transaction
(11) à un serveur d'autorisation de transactions de carte privative
(12) , suivie d'une réponse serveur d'autorisation de transactions de carte privative (12) au module de gestion de transaction (11).
6. Système (100) de paiement automatisé par reconnaissance d'immatriculation d'un véhicule (2) d'un client (1), ce système comprenant
un premier terminal (4), (8) apte à préenregistrer dans une plateforme (5) de données, des données d'identification personnelles, des données de paiements et des données d'identification d'au moins un véhicule (2) saisies par le client (1) dans le terminal (4), (8) ;
des moyens (3) de détection et de lecture aptes
o à lire l'immatriculation d'un véhicule (2) du client (1), les moyens
(3) de détection et de lecture étant déployés sur un lieu de vente accueillant le véhicule (2) ;
o à transmettre l'immatriculation du véhicule (2) lue à la plateforme (5) de données ;
- la plateforme (5) de données étant apte à
o identifier le véhicule (2), en comparant l'immatriculation lue du véhicule (2) et les données d'identification d'au moins un véhicule (2) préenregistré ;
o authentifier le client (1) par comparaison d'un numéro personnel d'identification transmis par le premier ou un deuxième terminal
(4) , (8), le terminal (4), (8) utilisé pour l'authentification du client (1) étant présent sur le lieu de vente ;
le terminal (4), (8) utilisé pour l'authentification du client étant apte à proposer au client (1)
o la saisie du numéro personnel d'identification propre au client (1); o une transaction fonction des informations des données préenregistrées par le client (1) et du véhicule (2) identifié ;
o une pré-autorisation de la transaction proposée ;
la plateforme (5) de données étant en outre apte à envoyer à un serveur (6) d'autorisation de transaction une requête d'autorisation pour la transaction pré-autorisée par le client (1) ;
le serveur (6) d'autorisation de transaction étant apte à autoriser la transaction par la transmission d'une réponse à la plateforme (5) de donnée;
- le terminal (4), (8) utilisé pour l'authentification du client étant en outre apte à recevoir l'autorisation de transaction transmise par la plateforme (5) de données et informer le client (1) de l'autorisation de transaction.
7. Système selon la revendication 6, dans lequel la plateforme (5) de données est apte à proposer au client (1) un service de gestion de flottes de véhicules (2), ce service étant réalisé par
la saisie par le client (1) dans le premier terminal (4), (8) d'un ensemble d'informations relatives à une pluralité de véhicules (2), ces informations comprenant pour chaque véhicule (2) une immatriculation, la marque et le modèle du véhicule (2), le type de carburant consommé, un budget limite de consommation pour un ou plusieurs véhicules (2) sur une période configurable, l'association de chaque véhicule (2) à un ou plusieurs clients (1) préenregistrés ;
un calcul par la plateforme (5) de données du budget de consommation restant pour chaque véhicule (2) ou chaque client (1), en fonction des transactions effectuées par chaque client (1) ; l'information du client (1) des transactions et du budget restant pour chaque véhicule (2) via un affichage approprié sur le premier terminal (4), (8) ou un message poussé vers le terminal (4), (8) utilisé pour l'authentification du client.
8. Système selon la revendication 6 ou 7, dans lequel le terminal (4), (8) utilisé pour l'authentification du client est un terminal mobile comportant une application mobile, l'application mobile étant apte à proposer au client (1) la mise à jour des données qu'il a préenregistré, la saisie de son numéro personnel d'identification, l'affichage, la préautorisation, le statut, la consultation, l'enregistrement de l'historique de transactions et la localisation d'au moins un lieu de vente le plus proche de la localisation du terminal mobile.
9. Système selon l'une quelconque des revendications 6 à 8, dans lequel la plateforme (5) de données comprend
un module de gestion client (7) apte à o proposer à tout terminal (4), (8) une interface graphique appropriée pour la saisie et l'enregistrement de données par le client (1) dans une base de données (9) ;
o proposer l'ajout d'une carte de paiement bancaire dans l'interface graphique, la validation d'une carte de paiement bancaire étant réalisée par une transaction proposée au client (1) et réalisée via des échanges entre le module de gestion client (7) et le serveur (6) d'autorisation de transaction ;
un module de gestion de transaction (11) apte
o à proposer tout terminal (4), (8) utilisé pour l'authentification du client, une interface graphique appropriée pour l'affichage, la modification, la pré-autorisation de la transaction proposée au client (1 ) ;
o communiquer avec le serveur (6) d'autorisation de transaction, via l'envoi d'une requête d'autorisation pour la transaction préautorisée par le client (1).
10. Système selon la revendication 9, comprenant en outre un serveur d'authentification de carte privative (10) interfacé avec le module de gestion client (7) et le module de gestion de transaction (11), apte à recevoir l'identification d'une carte privative ajoutée par le client (1) dans l'interface graphique du module de gestion client (7) ;
un serveur d'autorisation de transactions de carte privative (12) apte à recevoir une requête de transaction du module de gestion de transaction (11) pour une carte privative et envoyer une réponse concernant la requête au module de gestion de transaction (11).
EP14748231.9A 2014-08-08 2014-08-08 Methode de gestion de transaction par reconnaissance d'immatriculation d'un vehicule Ceased EP3178072A1 (fr)

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/EP2014/067132 WO2016020021A1 (fr) 2014-08-08 2014-08-08 Methode de gestion de transaction par reconnaissance d'immatriculation d'un vehicule

Publications (1)

Publication Number Publication Date
EP3178072A1 true EP3178072A1 (fr) 2017-06-14

Family

ID=51298782

Family Applications (1)

Application Number Title Priority Date Filing Date
EP14748231.9A Ceased EP3178072A1 (fr) 2014-08-08 2014-08-08 Methode de gestion de transaction par reconnaissance d'immatriculation d'un vehicule

Country Status (7)

Country Link
US (1) US20170243410A1 (fr)
EP (1) EP3178072A1 (fr)
CN (1) CN106575453A (fr)
BR (1) BR112017001734A2 (fr)
MX (1) MX2017001114A (fr)
RU (1) RU2017104303A (fr)
WO (1) WO2016020021A1 (fr)

Families Citing this family (16)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9858627B2 (en) * 2016-02-01 2018-01-02 Oracle International Corporation Fuel distribution system with correction mechanism
AU2017252185B2 (en) * 2016-04-21 2023-06-29 Wayne Fueling Systems Llc Intelligent fuel dispensers
WO2017209310A1 (fr) * 2016-06-03 2017-12-07 株式会社ミックウェア Système de traitement d'informations, terminal de traitement d'informations, procédé de traitement d'informations et programme de traitement d'informations
WO2017223039A1 (fr) * 2016-06-20 2017-12-28 Visa International Service Association Système de fournisseur de ressource efficace
CN108022311A (zh) * 2016-10-27 2018-05-11 英业达科技有限公司 场地管理方法与场地管理系统
CN107958379A (zh) * 2017-11-20 2018-04-24 深圳市小猫信息技术有限公司 一种加油费用结算方法、装置及系统
WO2019095395A1 (fr) * 2017-11-20 2019-05-23 深圳市小猫信息技术有限公司 Procédé, dispositif et système de règlement de frais de ravitaillement
US11657404B2 (en) * 2018-04-25 2023-05-23 Tanku LTD. System and method for authenticating a location for performing powering operations
US10676342B2 (en) * 2018-06-20 2020-06-09 Walmart Apollo, Llc Systems and methods for automatically refueling vehicles of customers of a retailer
US10679430B2 (en) * 2018-08-03 2020-06-09 Ca, Inc. Toll booth added security to code scanner
US10507795B1 (en) * 2018-08-06 2019-12-17 Ford Global Technologies, Llc Vehicle-based password
US11250437B2 (en) * 2018-11-08 2022-02-15 Capital One Services, Llc Systems and methods for mobile pre-authorization of a credit transaction
US11087577B2 (en) * 2018-12-14 2021-08-10 Johnson Controls Tyco IP Holdings LLP Systems and methods of secure pin code entry
CN110111495A (zh) * 2019-04-29 2019-08-09 上海申诺伟电子商务有限公司 加油方法及加油系统
US11520480B2 (en) 2020-04-15 2022-12-06 Tekion Corp Physical lock electronic interface tool
WO2023047210A1 (fr) * 2021-09-22 2023-03-30 Chetan Rajendra Walunj Procédé et système de distribution de carburant à partir d'un distributeur automatique de données principal

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2007030446A2 (fr) * 2005-09-07 2007-03-15 Rent-A-Toll, Ltd. Systeme, procede et support lisible par ordinateur de facturation de peages

Family Cites Families (13)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5859416A (en) * 1996-05-01 1999-01-12 Gatto; James G. Fuel pump system with automated transaction processing
US6374240B1 (en) * 1998-10-05 2002-04-16 Walker Digital, Llc Method and apparatus for maintaining a customer database using license plate scanning
JP2003228663A (ja) * 2002-02-04 2003-08-15 Fujitsu Ltd サービス提供支援システム、サーバ、およびコンピュータプログラム
KR20040054022A (ko) * 2002-12-16 2004-06-25 (주)아이디어 오케이 차량번호를 이용한 신용카드 결제 시스템 및 그 방법
US9792632B2 (en) * 2007-02-23 2017-10-17 Epona Llc System and method for processing vehicle transactions
US20130262275A1 (en) * 2010-08-24 2013-10-03 Chris Outwater System and Method for providing Internet-based vehicle registration and transactions
KR20120036734A (ko) * 2010-10-08 2012-04-18 한영수 주유고객 관리장치 및 방법
CN111899355B (zh) * 2011-08-29 2021-12-17 张忠义 可以无障碍进出的汽车费用支付系统与方法
US9324002B2 (en) * 2012-02-22 2016-04-26 Paypal, Inc. User identification and personalization based on automotive identifiers
US10719785B2 (en) * 2012-03-13 2020-07-21 Zipcar, Inc. System for improved vehicle late return prediction and detection
US20150178640A1 (en) * 2012-07-19 2015-06-25 Jegathisvaran Balakrishnan Automated vehicle parking management system
CN103700149B (zh) * 2012-09-27 2016-08-17 中国银联股份有限公司 基于lbs的高速公路收费系统及基于lbs的高速公路收费方法
CN103839300A (zh) * 2014-03-27 2014-06-04 张忠义 基于车牌识别的停车场自动收费系统

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2007030446A2 (fr) * 2005-09-07 2007-03-15 Rent-A-Toll, Ltd. Systeme, procede et support lisible par ordinateur de facturation de peages

Also Published As

Publication number Publication date
CN106575453A (zh) 2017-04-19
RU2017104303A (ru) 2018-08-09
RU2017104303A3 (fr) 2018-08-09
WO2016020021A1 (fr) 2016-02-11
US20170243410A1 (en) 2017-08-24
BR112017001734A2 (pt) 2018-02-14
MX2017001114A (es) 2017-08-10

Similar Documents

Publication Publication Date Title
EP3178072A1 (fr) Methode de gestion de transaction par reconnaissance d'immatriculation d'un vehicule
US20180246623A1 (en) Secure transaction interfaces
JP2020173823A (ja) モバイルデバイスを通じて自動小売機の提案を提供する方法およびシステム
US20180232713A1 (en) Banking Systems Controlled by Data Bearing Records
US11443301B1 (en) Sending secure proxy elements with mobile wallets
CA2407549C (fr) Systeme de transaction avec dispositif personnel portatif d'identification et de controle de transaction
EP1709598A2 (fr) Dispositif transactionnel a pre-traitement anticipe
WO2009026450A1 (fr) Procédés et systèmes de pré-autorisation de comptes de crédit basé sur le lieu
CA2960088C (fr) Mecanisme pour autoriser des transactions effectuees au niveau de terminaux sans surveillance
WO2013045832A1 (fr) Procede et systeme de signalisation de paiement, application a la location automatisee de vehicules
US20190272524A1 (en) Method and System for One-Touch Fueling Authorization
EP2824625B1 (fr) Méthode de réalisation de transaction, terminal et programme d'ordinateur correspondant
FR3080934A1 (fr) Procede et systeme pour effectuer un echange de donnees securise
EP2724305B1 (fr) Procede de transaction dematerialisee
FR3024793A1 (fr) Methode de gestion de transaction par reconnaissance d'immatriculation d'un vehicule
WO2013045831A1 (fr) Procede et systeme de paiement, application a la location automatisee de vehicules
EP2800072A2 (fr) Procédé de délivrance par un automate de cartes de téléphonie mobile SIM à abonnement prépayé ou postpayé
FR3011111A1 (fr) Securisation d'une transmission de donnees d'identification
FR2945881A1 (fr) Procede et systeme de transaction de biens et/ou de services au moyen d'un terminal via un reseau de communication
FR2858441A1 (fr) Systeme et procede de paiement electronique
FR2976385A1 (fr) Procede pour definir une transaction a effectuer au moyen d'un serveur
WO2013045833A1 (fr) Procede et systeme de paiement de consommations repetees dans le temps et application a la location de vehicules
FR2963975A1 (fr) Systeme de paiement en ligne
WO2006000860A1 (fr) Dispositif et procede de gestion d'un service telephonique prepaye avec une procedure d’identification simple
FR2912579A1 (fr) Procede de transfert securise via un reseau de communication d'un flux monetaire, systeme de transfert et produit programme correspondants

Legal Events

Date Code Title Description
STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE INTERNATIONAL PUBLICATION HAS BEEN MADE

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

Free format text: ORIGINAL CODE: 0009012

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

Free format text: STATUS: REQUEST FOR EXAMINATION WAS MADE

17P Request for examination filed

Effective date: 20170109

AK Designated contracting states

Kind code of ref document: A1

Designated state(s): AL AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HR HU IE IS IT LI LT LU LV MC MK MT NL NO PL PT RO RS SE SI SK SM TR

AX Request for extension of the european patent

Extension state: BA ME

DAX Request for extension of the european patent (deleted)
STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: EXAMINATION IS IN PROGRESS

17Q First examination report despatched

Effective date: 20180214

REG Reference to a national code

Ref country code: DE

Ref legal event code: R003

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

Free format text: STATUS: THE APPLICATION HAS BEEN REFUSED

18R Application refused

Effective date: 20200813