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.

Applications Claiming Priority (1)

Publications (1)

Family

ID=51298782

Family Applications (1)

Country Status (7)

Families Citing this family (16)

Citations (1)

Family Cites Families (13)

• 2014
  • 2014-08-08 US US15/501,467 patent/US20170243410A1/en not_active Abandoned
  • 2014-08-08 MX MX2017001114A patent/MX2017001114A/es unknown
  • 2014-08-08 EP EP14748231.9A patent/EP3178072A1/de not_active Ceased
  • 2014-08-08 WO PCT/EP2014/067132 patent/WO2016020021A1/fr active Application Filing
  • 2014-08-08 CN CN201480081085.9A patent/CN106575453A/zh active Pending
  • 2014-08-08 RU RU2017104303A patent/RU2017104303A/ru not_active Application Discontinuation
  • 2014-08-08 BR BR112017001734-2A patent/BR112017001734A2/pt unknown

Patent Citations (1)

Also Published As

Similar Documents

Legal Events