Classifications

• • G—PHYSICS
  • G06—COMPUTING; CALCULATING OR COUNTING
  • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
  • G06Q20/00—Payment architectures, schemes or protocols
  • G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
  • G06Q20/32—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using wireless devices
  • G06Q20/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/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

Definitions

• the present invention relates to verification of the validity of a transaction. It may be for example a bank transaction during a payment by credit card, a payment terminal requesting authorization of the transaction from a server entity that verifies the validity of this transaction.
• the authentic holder of the credit card may not have his mobile terminal at the time of the transaction, which generates a false alert leading to a negative verification of the validity of the transaction.
• the present invention improves the situation.
• a requested transaction request at a current location for a user of a mobile terminal, the request comprising a data function of an identifier of the terminal, depending on the identifier of the terminal, consulting a database storing data of previous locations of the terminal,
• server entity means one or more server devices operatively connected to one another, typically via a network, but capable of being arranged in different locations.
• the present invention provides to rely on a history of previous locations of the mobile terminal, to check consistency with the location of the current transaction. Therefore, the transaction is not necessarily rejected if the authentic user (for example of a bank card) does not have his mobile terminal on him. In addition, if both the bank card and the mobile terminal have been stolen by the same person, taking into account a history of previous locations makes it possible to check compatibility between the current location of the transaction (possibly by a user). malicious) and previous locations (for example, usual locations of the authentic user of the map). In case of non-correspondence, typically, it may be determined that the holder of the bank card for the current transaction is not located at a location already listed for the mobile terminal, which may lead to a rejection of the request. transaction.
• the transaction request can be issued from a second terminal (for example a payment terminal reading a bank card, or a personal computer of the cardholder issuing a payment order, or others).
• the transaction request includes a datum of the current location, corresponding to a geographical position of the second terminal. This provision can be implemented at the second terminal (for example the aforementioned payment terminal), advantageously, to insert in the transaction request the current location of the current transaction.
• the server entity obtains a current geolocation data from the mobile terminal. For this purpose, it can be expected to generate an event via the cellular network (call, or SMS message notification) to create a current location data.
• the server may, for example, request the operator of the cellular network used by the mobile terminal to generate an event (incoming telephone call on the mobile terminal, or notification of an SMS message) creating a location data item, which enables the mobile terminal to server entity to obtain the data of the current location.
• the server entity can send a notification to the terminal to receive, in response, the current geolocation data.
• the aforementioned notification invites the user of the terminal to enter an identification code personal, this code, once received from the terminal, being checked with the server entity.
• the database may store a plurality of previous location data sets of a respective plurality of terminals, and, with the server entity connected to said database, the server entity transmits to the database. the identifier of the mobile terminal and in return obtains the data set of previous locations of this mobile terminal.
• the terminal can store in memory the aforementioned database, and, from the identifier of the terminal, the server entity contacts the terminal for the consistency check between the current location and previous locations of the terminal.
• the terminal can itself compare the current location transmitted by the server entity to a previous location history already stored in the terminal, and transmit the result of this comparison to the server entity to decide to a verified consistency or not of this current location.
• the consistency is checked if the current location corresponds to at least one of said previous locations of the mobile terminal.
• the data of previous locations comprise one or more means of previous locations.
• each average can be estimated on a group of locations spaced geographically from a difference below a predetermined threshold.
• the coherence can be verified if the current location is around one of the aforementioned means, in a radius corresponding for example to the predetermined threshold.
• the previous location data can be obtained from location information given at the initiative of the user, for example to a social network server (for example checkins on Facebook® or other social networks). Such an embodiment ensures confidentiality at the location of the user's terminal, these locations are not obtained without his knowledge.
• the previous location data stored in the database can be stored at the initiative of the user, by means of a notification sent by the server entity, for example by a message of the type SMS on the mobile terminal, after a validated transaction and asking the user if he accepts that this location is stored for subsequent transactions. These locations stored at the initiative of the user are stored as usual (without special risk), which then determines the level of risk associated with a future transaction.
• the action in response to the transaction request may, by way of example, include one of at least one rejection of the transaction, a favorable sequence to give to the transaction (it being understood that other subsequent controls such as that of the bank card itself or the user's bank account), or the issuing of a notification inviting the user to give personal information (for example to enter a personal code on its mobile terminal or to enter a code received on its mobile terminal in an SMS message on the payment terminal (process known as "3DSecure"), or to enter a biometric fingerprint, or to present a piece of identification, or other).
• a favorable sequence to give to the transaction it being understood that other subsequent controls such as that of the bank card itself or the user's bank account
• the issuing of a notification inviting the user to give personal information for example to enter a personal code on its mobile terminal or to enter a code received on its mobile terminal in an SMS message on the payment terminal (process known as "3DSecure"), or to enter a biometric fingerprint, or to present a piece of identification, or other).
• the present invention also aims at such an application in the form of a computer program, comprising instructions for implementing the method described above. before, when this program is executed by a processor, for example a processor that includes the aforementioned server entity.
• the invention further aims at the server entity for verifying the validity of a transaction, comprising:
• a communication interface for receiving a requested transaction request at a current location for a user of a mobile terminal, the request comprising a data function of an identifier of the terminal,
• a verification module cooperating with the communication interface for:
• the abovementioned verification module may comprise software elements (typically the computer program in the sense of the invention) and hardware elements such as for example a processor with which a working memory is associated, as will be seen later with reference to FIG. FIG. 3 schematically representing, by way of example, a server entity within the meaning of the invention.
• FIG. 1 illustrates a system including in particular an ES server entity for the implementation of the invention
• - Figure 2 illustrates the main steps of the method in the sense of the present invention, in an exemplary embodiment
• Figure 3 schematically illustrates elements of the invention.
• a server entity in the sense of the present invention in an exemplary embodiment
• Figure 4 illustrates a location position processing, in a particular embodiment.
• a payment terminal TER2 (the "second terminal” above), able to read a bank card CB and thus require a transaction, a transaction request message then being transmitted via a network RES to an ES server entity, for verification of the validity of the transaction.
• the server entity ES refers to a database DB of previous locations of a mobile terminal TER of the US user who is the authorized holder of the bank card CB.
• the server entity only refers to a history of previous locations, without any need for the presence of the TER terminal at the time of the transaction.
• the server entity ES interprets that the current holder of the bank card CB is positioned at a location that does not correspond to the habits of its authentic holder, which can be concluded by a rejection of the transaction, or by an additional verification requested to the holder of the credit card.
• the authentic user of the bank card is usually located by his mobile terminal in the Paris region, while the location of the current transaction is located on Marseille (without any occurrence in the history of previous locations do not mentioned Marseilles as previous location), it can be interpreted that the credit card is located in Marseille, which can generate from the ES server entity an additional verification routine (for example by asking the user to enter a code particular personal identification on his mobile terminal, or others).
• FIG. 2 shows the main steps of such a method, which begins at step S1 by a request REQ that the payment terminal TER2 issues and typically includes a current location LOC of this terminal TER2.
• the request further includes an identifier of its authentic user ID-US.
• This request REQ is sent to the server entity ES which thus finds, from the identifier of the user, an identifier ID-TER of its mobile terminal TER, in step S2.
• the process may continue with any additional verification, such as for example the entry of an additional personal identifier. in step S7.
• the server entity ES refers to the database DB, at step S3 to obtain the history of the previous locations of the TER terminal.
• the database DB previous locations can be stored in a memory that can access the ES server entity, as shown in Figure 1. In this regard, this memory can be directly integrated with the server entity.
• the server entity ES itself, can be in the form of one or more server devices connected to each other and each typically having a processor and a working memory, as well as a communication interface, for receiving queries, process them and send an answer.
• the database DB is stored in a memory that includes one of these server devices.
• the database of the previous locations DB can be stored in a memory of the terminal itself, as explained later in one embodiment.
• the server entity determines whether the current location LOC is compatible with the previous locations.
• the current localization LOC can be included in the request REQ, as indicated previously with reference to the step S1.
• the current location can be determined by a simple interrogation of the terminal TER, at the same time. step S5.
• the location of the terminal can be obtained spontaneously by a triangulation technique on several base stations.
• the location of the terminal can usually be obtained in a simple manner and can be exploited directly when the terminal is directly requested by the network RES, for example by sending a notification by SMS short messages, or by telephone call. (at step S5 of Figure 2). It can be taken advantage of the notification of an SMS message for the user to enter a personal code on his mobile terminal, to overcome the case for example where the bank card was stolen at the same time as the mobile terminal of the user .
• the technique for transmitting notification to the mobile terminal can be considered intrusive if it is to build the history of the previous locations, and it may be preferable to obtain successive information of TER terminal location, by simple choice its user (information given by the user on a social network for example, or after acceptance of the given user to the server entity to store a current location data after validation of a transaction).
• the history of the previous locations can be generated (for example over a chosen period of one year or six months) and then stored in the database DB.
• the database DB can be stored at a memory of the server entity ES, as explained above, or be stored at the mobile terminal itself, if typically it is desired to maintain confidentiality on the movements of the user of the mobile terminal.
• the comparison between the current location of the transaction and the history of the previous locations can be performed with the mobile terminal, itself, while the compatibility check decision, which follows this comparison, can be taken from the server entity ES that receives from the mobile terminal positive or negative information on the aforementioned comparison.
• the entity server may decide to perform in step S7 additional security before validating the transaction (for example asking the user to enter an additional personal code on the payment terminal TER2, or to request the user to enter a personal code specific to banking transactions on his mobile terminal TER).
• FIG. 3 shows an exemplary structure of an ES server entity.
• This typically comprises a communication interface INT, able to cooperate with a processor PROC with which is associated a working memory MEM.
• the server entity can cooperate directly with a mass storage memory hosting the database of the histories of the previous locations of one or more mobile terminals, this memory being addressable from an ID-TER mobile terminal identifier for retrieving the history of the previous locations of this mobile terminal.
• this DB database is stored at the mobile terminal directly, this addressing feature according to an identifier becomes unnecessary.
• the comparison between the current location LOC and one of the preceding locations can lead to a positive consistency check between the location of the current transaction and the history of the previous locations.
• this information does not mean that the place of the current transaction should be invalidated.
• a user living in the Paris region can move and be in a neighborhood of the Paris region in which it has never been previously located.
• FIG. 4 shows such an embodiment in which an average point A is established between several previous locations A1, A2, A3, A4 and which are not separated by more than a predetermined threshold SP.
• a second average represented by the point B of FIG. 4 can be identified, grouping several previous locations B 1, B 2, B 3 which are not separated by more than the aforementioned predetermined threshold SP.
• a time criterion may correspond to positions having been occupied over the same relatively short observation period (for example 15 days or one month).
• transaction encompasses any type of transaction, including authentication during an access control, for example a website or any computer application.
• an embodiment has been described above in which it is carried out simple average of the various previous locations of the mobile terminal.
• sophisticated models can be provided, for example with a weighted average estimate as a function of the time elapsed since a location time stamp.

Landscapes

• Business, Economics & Management (AREA)
• Engineering & Computer Science (AREA)
• Accounting & Taxation (AREA)
• General Business, Economics & Management (AREA)
• Theoretical Computer Science (AREA)
• General Physics & Mathematics (AREA)
• Strategic Management (AREA)
• Physics & Mathematics (AREA)
• Computer Networks & Wireless Communication (AREA)
• Economics (AREA)
• Finance (AREA)
• Computer Security & Cryptography (AREA)
• Development Economics (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=49998311

Family Applications (1)

Country Status (4)

Cited By (1)

Families Citing this family (1)

Citations (1)

Family Cites Families (5)

• 2013
  • 2013-06-27 FR FR1356178A patent/FR3007870A1/fr not_active Withdrawn
• 2014
  • 2014-06-24 EP EP14742264.6A patent/EP3014542A1/de not_active Ceased
  • 2014-06-24 US US14/901,594 patent/US20160371676A1/en not_active Abandoned
  • 2014-06-24 WO PCT/FR2014/051565 patent/WO2014207364A1/fr active Application Filing

Patent Citations (1)

Non-Patent Citations (1)

Also Published As

Similar Documents

Legal Events