Classifications

• • G—PHYSICS
  • G06—COMPUTING; CALCULATING OR COUNTING
  • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
  • G06Q20/00—Payment architectures, schemes or protocols
  • G06Q20/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
  • 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/405—Establishing or using transaction specific rules
• • 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/108—Remote banking, e.g. home banking
• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
  • H04L63/00—Network architectures or network communication protocols for network security
  • H04L63/10—Network architectures or network communication protocols for network security for controlling access to devices or network resources
  • H04L63/105—Multiple levels of security
• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
  • H04L67/00—Network arrangements or protocols for supporting network services or applications
  • H04L67/50—Network services
  • H04L67/52—Network services specially adapted for the location of the user terminal

Definitions

• the invention relates to securing payments. More particularly, the invention relates to securing payments made online.
• Online payments represent a growing share of payments made daily around the world. They can be made either through payment providers, such as Paypal TM, or by making use of traditional banking organizations.
• This method suffers from two disadvantages: on the one hand it forces the customer to provide his telephone number to the bank before any transaction and in a secure manner (this is done mostly visually with a bank advisor); on the other hand, this method only works if the customer's bank is also the bank that manages the transaction on behalf of the merchant. This is rarely the case, especially abroad. Indeed, a large part of fraud is carried out abroad. Thus, the aforementioned method is not very effective in this case.
• the method proposed by the inventors does not pose these problems of the prior art. Indeed, it is proposed a method of locating a user making a payment in CNP mode.
• the invention relates to a method for providing a location assertion of a transactional device, having requested, from a server, via a communication network, an acceptance of a financial transaction involving the use of bank details.
• this process comprises: a step of receiving a transactional request, resulting from said transactional device, comprising at least one identifier of a user to whom said bank details are associated;
• the invention makes it possible to validate a bank transaction (such as an online payment) on the basis of the location of the terminal performing the transaction, by using the IP address of this terminal.
• the proposed method is therefore much simpler and less restrictive to implement than authorization methods based on a MAC address.
• said method further comprises: a step of obtaining a route taken by data packets to reach said IP address associated with said transactional device, issuing a list of borrowed IP addresses;
• the invention makes it possible to trace the path taken by a data packet that wishes to join the IP address associated with the terminal. This provides additional data to protect against theft or theft of IP address.
• said method further comprises:
• the invention makes it possible to classify the locations at risk and to define thresholds below which transactions are not accepted.
• said step of issuing the location assertion is performed when none of the transport locations is part of a prohibited location list.
• said method further comprises: a step of obtaining a current location of a mobile terminal associated with said user;
• the invention makes it possible to couple the location of the transaction terminal to the location of another device in the possession of the user. It is therefore a double control that is effective because in most cases, transactions are passed from the user's home. At this home, the probability that the user's mobile terminal is connected to the residential home gateway is strong. In this case, the location of the terminals will be identical and will be obtained very quickly.
• the invention also relates to a server for providing a location assertion of a transactional device, which has requested, from a server, through a communication network, an acceptance of a financial transaction involving the use of bank details.
• a server for providing a location assertion of a transactional device, which has requested, from a server, through a communication network, an acceptance of a financial transaction involving the use of bank details.
• a server comprises:
• the various steps of the methods according to the invention are implemented by one or more software or computer programs, comprising software instructions intended to be executed by a data processor of a relay module according to the invention. invention and being designed to control the execution of the various process steps.
• the invention is also directed to a program that can be executed by a computer or a data processor, which program includes instructions for controlling the execution of the steps of a method as mentioned above.
• This program can use any programming language, and be in the form of source code, object code, or intermediate code between source code and object code, such as in a partially compiled form, or in any other form desirable shape.
• the invention also provides a data carrier readable by a data processor, and including instructions of a program as mentioned above.
• the information carrier may be any entity or device capable of storing the program.
• the medium may comprise storage means, such as a ROM, for example a CD ROM or a microelectronic circuit ROM, or a magnetic recording medium, for example a floppy disk or a disk. hard.
• the information medium may be a transmissible medium such as an electrical or optical signal, which may be conveyed via an electrical or optical cable, by radio or by other means.
• the program according to the invention can be downloaded in particular on an Internet type network.
• the information carrier may be an integrated circuit in which the program is incorporated, the circuit being adapted to execute or to be used in the execution of the method in question.
• the invention is implemented by means of software and / or hardware components.
• module may correspond in this document as well to a software component, a hardware component or a set of hardware and software components.
• a software component corresponds to one or more computer programs, one or more subroutines of a program, or more generally to any element of a program or software capable of implementing a function or a program. set of functions, as described below for the module concerned.
• Such a software component is executed by a data processor of a physical entity (terminal, server, gateway, set-top-box, router, etc.) and is capable of accessing the hardware resources of this physical entity (memories, supports recording, communication bus, input / output electronic boards, user interfaces, etc.).
• a hardware component corresponds to any element of a hardware set (or hardware) able to implement a function or a set of functions, as described below for the module concerned. It can be a programmable hardware component or with an integrated processor for executing software, for example an integrated circuit, a smart card, a memory card, an electronic card for executing a firmware, etc.
• Figure 1 depicts an embodiment of the location assertion delivery method
• Figure 2 depicts an embodiment derived from the location assertion delivery method
• FIG. 3 depicts a complementary embodiment of the location assertion delivery method
• FIG. 4 illustrates an architecture of a server able to implement a location assertion delivery method
• FIG. 5 illustrates an architecture of a client capable of implementing a location assertion issuing method.
• the purpose of the proposed method is to ensure that, when using credit card data in CNP mode, it is still possible to obtain information on the holder of the payment card.
• the goal is to move from a CNP mode to a mode where the carrier map is located without changing the habits of the cardholder and in any discretion.
• the IP address from which the transaction is initiated is obtained.
• this IP address is compared to a list of allowed IP addresses, list maintained by the entity in charge of carrying out the payment transactions (it can be a bank, an institution or an intermediary institution, such as a payment service manager).
• the IP address is not the data to validate the transaction.
• the data validating or not the transaction is a location.
• the IP address of the terminal from which the transaction is made is always obtained, but this IP address serves only as a means of obtaining a location.
• the location becomes the information to deliver the transaction authorization (that is, to validate that a transaction can be performed).
• This embodiment has several advantages. In the first place, this embodiment makes it possible to overcome the problems of address translations. Indeed, it is very common that the device that is used to perform a bank transaction be behind a gateway or a proxy. However, it can be complex to recover an IP address that is exploitable. In general, the IP address retrieved is the IP address of the gateway, but this is not assured.
• this embodiment makes it possible not to limit the number of devices that can be used to carry out transactions. More specifically, unlike a MAC address, for example, an IP address is often shared by multiple devices (for example, the address of a home gateway is shared by all user devices connected to that home gateway. ). It is therefore not necessary to retrieve all the MAC addresses of the devices that can be used.
• the location used is that of the city of the IP address. In other embodiments, the location may be more precise, like for example a street in the city. The accuracy obtained depends on the one hand on the available databases and on the other hand on the legal constraints in force in the geographical areas where the invention is implemented.
• the IP address (@IP) of the terminal (Dt) from which the transaction is performed is used.
• the terminal from which the transaction is made is not a payment terminal (in the sense of a terminal in which the bank card is inserted and in which a PIN code is entered). It is a terminal such as a computer or a tablet or a smartphone and not a payment terminal such as those installed at merchants.
• the method implemented comprises:
• a step of receiving (10) a transaction request (q), resulting from a transactional device (Dt), comprising at least one identifier (id) of a user; it is not necessary, in this embodiment, that the query in question includes the bank data (card number, transaction amount, etc.), or even that it comes directly from the transaction terminal.
• LOCC current location
• LOCAs authorized location
• the location assertion (Al) is then provided to validate the bank transaction (this bank transaction validation is performed up to the other parameters and values entering the validation process, of course) to an entity.
• This bank transaction validation is performed up to the other parameters and values entering the validation process, of course.
• the entity in question may very well be one that implements the method just described.
• the method makes it possible to compare the location of the IP address of the terminal that initiates the payment with an authorized location list.
• These locations can be defined by the user's bank, automatically. Indeed, it is very traditional for users to connect to their online bank account management systems from several different locations. Among the favorite locations of users, two are extremely common: this is on the one hand the user's home and on the other hand his place of work.
• the proposed method it is possible to retrieve the IP addresses of users when connecting to their online banking.
• this recovery is not sufficient, as such. It is necessary, after an IP address retrieval, to obtain a more or less precise location of this address and to keep this location as an authorized location.
• This conservation can be implemented according to several criteria. For example, when an identified location corresponds to more than twenty or thirty percent of all locations of the user (these percentages are given for information only), it can be considered that this location can be preserved.
• this location when a location does not correspond to a usual location of the user, this location can be excluded from the locations authorized by the bank or the payment institution or the payment service manager. In this embodiment of the invention, the location is a country, a city or a street (or a combination of these data).
• the current location of the transactional device is further completed by the implementation of a "trace route" type request.
• a "trace route” type request makes it possible to follow the path taken by an IP packet to reach a given address.
• at least some of the IP addresses obtained via the "trace route" request are used to obtain “intermediate” locations.
• This embodiment of the invention although more or less significantly lengthening the delivery process of the location assertion, makes it possible to evaluate the path traversed by packets to reach the IP address of the transactional device. This gives a list of IP addresses at least some of which are associated with a location (for example country, city or street or a combination of these data). This list is ordered, in order to be able to evaluate the route taken by the packets.
• the locations of the different IP addresses of the list are not in adequacy with the IP address as received from the transactional device (the location of the IP address of the transactional device indicates France while the list of successive locations are outside France such as in Russia, Bulgaria, India, China, etc.), it is possible to modulate the delivery of the location assertion.
• This modulation can take several forms: either the location assertion is not delivered at all and the process is stopped, or a technique based on confidence coefficients is introduced.
• countries or regions of a country or even cities and streets are assigned levels of trust. It is a coefficient less than or equal to the value 1.
• Each location of the list of successive locations is assigned a coefficient.
• the coefficients of the locations of the list are multiplied to obtain a level of confidence.
• the confidence level is below a predetermined confidence level, the location assertion is not delivered.
• This confidence threshold may for example be a function of the number of banking incidents linked to the user or also of the frequency with which the bank has found that the user was moving (according to the withdrawals made in different countries or in different cities).
• the method therefore comprises:
• security is enhanced. Indeed, in addition to the location of the place where the transaction is carried out (for example by using the IP address of the terminal from which this transaction is initiated), we use the locating a mobile terminal (for example a smartphone or tablet) in the possession of the user to determine the location of this terminal. In other words, in this embodiment, in addition to the location of the terminal from which the transaction is made, it also seeks to locate a mobile device that is in the possession of the user so as to correlate this location mobile device with that of the device from which the transaction is made.
• a mobile terminal for example a smartphone or tablet
• the location assertion is not provided and the transaction can not continue.
• the method further comprises, in relation to FIG.
• the step of obtaining a current location of a mobile terminal associated with said user may comprise, depending on the embodiments, a direct transmission of a location by the terminal itself, if the terminal is able to make this transmission (for example via a dedicated application - see below).
• the obtaining of the location can also be implemented via the communication network to which the communication terminal is connected. As a general rule, this implies implementation through the intermediary of the telecommunication operator to which the user is subscribed (this can cause problems since the operators are generally reluctant to provide this kind of data, which they prefer to keep for their own purposes or for uses imposed by the laws of the Member States. different countries).
• the method is implemented via a mobile terminal, which terminal is assumed to be in the possession of the user. Unlike known techniques, the method does not include transmitting information to the mobile terminal to verify that the cardholder has its terminal to perform the transaction. On the contrary, the method consists in obtaining information from the terminal, which on the one hand is more discreet and on the other hand makes it possible not to solicit the user unnecessarily.
• the information obtained can be of several types.
• the information can be a geographical position obtained via a geolocation module (GPS type, GLONASS, GALILEO, etc.).
• the information can also be an IP address.
• This IP address can be the IP address of the gateway to which the terminal is connected, for example in WiFi, when this terminal is at the user's home.
• This IP address can be the one provided by an access provider in case of connection to the Internet via a 3G / 4G network.
• the information can still be a base station identifier, to which the terminal is connected (for example on a 2G / 3G / 4G network).
• this implementation is provided by a mobile application. More particularly, according to a preferred implementation, this application is the user's banking application. It is indeed very common for users to have an application allowing them to manage their account from their mobile terminal. In general, this type of application enjoys enhanced security. More specifically, this type of application often uses a session data encryption protocol (SSL or TLS), which ensures a certain confidentiality of the transmitted data.
• SSL session data encryption protocol
• the mobile application transmits, upon request, the data necessary for a bank server, which retransmits this data (or data transformed into location data) to the third party server (for example to the transactional server).
• the method described is implemented via a transactional server, presented in connection with FIG. 4.
• a transactional server may, as desired, be implemented by a banking organization, a payment service provider or provider acting as an intermediary between one or more banks or payment institutions.
• Such a management server comprises a memory 41, a processing unit 42 equipped for example with a microprocessor, and driven by the computer program 43, implementing the method according to the invention.
• the invention is implemented in the form of a bank server, a payment system.
• a server includes:
• connection interface means for receiving a transaction request, from said transactional device, comprising at least one identifier of a user to which said bank details are associated;
• connection interface means for receiving a transaction request, from said transactional device, comprising at least one identifier of a user to which said bank details are associated;
• These means can be embodied in the form of a connection interface (I) to one or more communication networks. They may be software interfaces or hardware interfaces (network card type or network communication hardware modules).
• connection interface I
• network card type or network communication hardware modules
• means for determining a current location associated with said IP address means for comparing said current location with at least one authorized location, according to said identifier of said user;
• These means can be embodied in the form of a connection interface to one or more communication networks. They may be software interfaces or hardware interfaces (network card type or network communication hardware modules).
• such a server also comprises means for obtaining at least one piece of information coming from a mobile terminal that is supposed to be in the possession of the user whose transaction is to be validated.
• this server may for example transmit a request to obtain this information to the mobile terminal.
• it can implement several techniques, the first being for example the transmission of an SMS-type message to an application installed on the terminal (see Application and Mobile Terminal).
• the server Upon receipt of the location information, the server performs a concordance check between the location previously obtained (that of the terminal to which the user is connected) and the location obtained via the mobile terminal. When these locations are not matched, the transactional server does not provide a location assertion and the transaction is rolled back.
• a simplified architecture of a mobile device capable of transmitting its position is presented.
• a mobile device comprises a memory 51, a processing unit 52 equipped for example with a microprocessor, and driven by the computer program 53, implementing the method according to the invention.
• the invention is implemented in the form of a mobile application installed on a mobile device in the possession of the user.
• a mobile device comprises:
• connection interface I
• networks may be software interfaces or hardware interfaces (network card type or network communication hardware modules);
• transmission means said server, said at least one position.
• These means can be embodied in the form of a connection interface to one or more communication networks. They may be software interfaces or hardware interfaces (network card type or network communication hardware modules).

Landscapes

• Business, Economics & Management (AREA)
• Accounting & Taxation (AREA)
• Engineering & Computer Science (AREA)
• Finance (AREA)
• Computer Security & Cryptography (AREA)
• Theoretical Computer Science (AREA)
• Strategic Management (AREA)
• Physics & Mathematics (AREA)
• General Business, Economics & Management (AREA)
• General Physics & Mathematics (AREA)
• Economics (AREA)
• Development Economics (AREA)
• Computer Networks & Wireless Communication (AREA)
• Signal Processing (AREA)
• Computer Hardware Design (AREA)
• Computing Systems (AREA)
• General Engineering & Computer Science (AREA)
• Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)
• Mobile Radio Communication Systems (AREA)

Applications Claiming Priority (2)

Publications (1)

Family

ID=48741370

Family Applications (1)

Country Status (8)

Families Citing this family (4)

Citations (2)

Family Cites Families (37)

• 2013
  • 2013-03-28 FR FR1352846A patent/FR3003976B1/fr active Active
• 2014
  • 2014-03-28 WO PCT/EP2014/056377 patent/WO2014154902A1/fr active Application Filing
  • 2014-03-28 CA CA2907630A patent/CA2907630C/en active Active
  • 2014-03-28 RU RU2015146303A patent/RU2015146303A/ru not_active Application Discontinuation
  • 2014-03-28 AU AU2014242913A patent/AU2014242913A1/en not_active Abandoned
  • 2014-03-28 US US14/780,935 patent/US20160063495A1/en not_active Abandoned
  • 2014-03-28 BR BR112015024761A patent/BR112015024761A2/pt not_active IP Right Cessation
  • 2014-03-28 EP EP14713484.5A patent/EP2979237A1/de not_active Ceased

Patent Citations (2)

Non-Patent Citations (1)

Also Published As

Similar Documents

Legal Events