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/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/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
  • G06Q20/32—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using wireless devices
  • G06Q20/327—Short range or proximity payments by means of M-devices
• • 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/18—Payment architectures involving self-service terminals [SST], vending machines, kiosks or multimedia terminals
• • 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/308—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using the Internet of Things
• • 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/321—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using wireless devices using wearable devices
• • 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/20—Individual registration on entry or exit involving the use of a pass
  • G07C9/29—Individual registration on entry or exit involving the use of a pass the pass containing active electronic elements, e.g. smartcards
• • 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
• • G—PHYSICS
  • G07—CHECKING-DEVICES
  • G07F—COIN-FREED OR LIKE APPARATUS
  • G07F15/00—Coin-freed apparatus with meter-controlled dispensing of liquid, gas or electricity
  • G07F15/003—Coin-freed apparatus with meter-controlled dispensing of liquid, gas or electricity for electricity
  • G07F15/005—Coin-freed apparatus with meter-controlled dispensing of liquid, gas or electricity for electricity dispensed for the electrical charging of vehicles
• • G—PHYSICS
  • G07—CHECKING-DEVICES
  • G07F—COIN-FREED OR LIKE APPARATUS
  • G07F17/00—Coin-freed apparatus for hiring articles; Coin-freed facilities or services
  • G07F17/10—Coin-freed apparatus for hiring articles; Coin-freed facilities or services for means for safe-keeping of property, left temporarily, e.g. by fastening the property
  • G07F17/12—Coin-freed apparatus for hiring articles; Coin-freed facilities or services for means for safe-keeping of property, left temporarily, e.g. by fastening the property comprising lockable containers, e.g. for accepting clothes to be cleaned
  • G07F17/13—Coin-freed apparatus for hiring articles; Coin-freed facilities or services for means for safe-keeping of property, left temporarily, e.g. by fastening the property comprising lockable containers, e.g. for accepting clothes to be cleaned the containers being a postal pick-up locker
• • 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
  • G06Q2240/00—Transportation facility access, e.g. fares, tolls or parking

Definitions

• the invention relates to contactless communications, that is to say wireless, for the transmission of data between a communicating object and a communication device. More specifically, the invention relates to the transactions implemented during these contactless communications, such as in particular banking-type transactions, access to a means of transport or to a secure place, ordering of goods or services (s), etc... and the way in which a communicating object, such as for example a connected vehicle, a smartphone (“smartphone”), a connected watch, controls these contactless transactions with a communication device, typically a reader, payment point, fare gate, etc.
• a communicating object such as for example a connected vehicle, a smartphone (“smartphone”), a connected watch, controls these contactless transactions with a communication device, typically a reader, payment point, fare gate, etc.
• a transaction using a communicating or connected object.
• a connected object such as a bank card, a smartphone (“ smartphone”), a connected watch, etc.
• the user knows the context of his purchase (the object of his purchase, the place of purchase, the merchant, etc.).
• TPE electronic payment terminal
• the user verifies this information and, if it suits him, approaches his connected object to the TPE to authorize the transaction if it is contactless.
• the contactless transaction is not possible, the user is obliged to enter a code on the TPE to authorize the transaction.
• Bluetooth Long Term Evolution
• WiFi DSRC short or medium range wireless communication means
• - transaction means such as for example an eSIM card ("Embedded Subscriber Identification Module” in English) installed in the vehicle, an electronic purse (“e-wallet” in English) embedded in the computer infrastructure of the vehicle and in which has/have been preloaded one or more units of digital currency (“tokens” in English) from a bank card, etc.
• eSIM card embedded Subscriber Identification Module
• e-wallet embedded in the computer infrastructure of the vehicle and in which has/have been preloaded one or more units of digital currency (“tokens” in English) from a bank card, etc.
• contactless transactions can be implemented in the connected vehicle to access goods or services that include, for example, parking in a car park, paying a motorway toll, using a service station (petrol or electric charging, washing, etc.), a maintenance or upkeep operation, delivery of an order to a drive-in type service (fast food, click & collect, etc.) .
• a service station petrol or electric charging, washing, etc.
• a maintenance or upkeep operation delivery of an order to a drive-in type service (fast food, click & collect, etc.) .
• a disadvantage of the use of such a connected vehicle is that the user is obliged, as in the previous use cases, to verify all the information relating to the transaction, which is displayed for example on a console of the dashboard board, before authorizing the transaction, by clicking on a "validate” button displayed on the console, or before refusing the transaction, by clicking on a "cancel” button displayed on the console.
• an object of the present invention relates to a method for controlling a contactless transaction between a communicating object and a communication device, during which the communicating object receives from the communication device a request containing data relating to the transaction.
• the invention advantageously allows a connected object, able to communicate without contact with a communication device within the framework of the implementation of a transaction, to be provided with a decision-making mechanism making it possible to verify:
• An advantage of the invention is that such a verification is carried out completely independently by the communicating object, such as for example a connected vehicle, a connected watch, a connected card, that is to say without any intervention or human manipulation in relation to the object.
• the connected object decides on its own initiative if it is authorized to carry out a contactless transaction wisely with the communication device, such a transaction being for example a payment, the delivery of a good or a service, access to a locker, a means of transport, etc.
• Such a decision-making mechanism installed in the communicating object also makes it possible to avoid or limit the development and deployment in the network of preventive processing tools intended to verify the legitimacy of a request, these tools being technically complex and costly.
• the communicating object activates the sending to the communication device of a response to the request refusing the transaction, or failing to respond to the request.
• the communicating object is capable of autonomously processing the reception of any request containing data relating to a transaction which would not be intended for this communicating object but for another communicating object or which would be intended to the communicating object fraudulently or by mistake.
• the communicating object can send a response to the request refusing the transaction, which puts an end to the communication between the communicating object and the communication device.
• the communicating object can ignore this request and not respond to it, for the sake of saving the resources of the battery of the communicating object and/or the bandwidth of the wireless communication network between the communicating object and the communication device.
• At least one additional datum relating to the transaction is determined, said at least one additional datum being added in the response to the request authorizing the transaction.
• the communicating object is able to:
• - autonomously generate one or more additional data relating to the transaction such as for example an identifier associated with the user of the object at the time of the transaction, the identity of this user, the place of the transaction, etc., and
• the response to the request authorizing the transaction is thus advantageously enriched with useful data that the communication device can transmit to the manager of the transaction or of the communicating object or even to the supplier of the good or service, for processing/archiving/tracing transactions that have been performed by a user of the particular communicating object.
• the transaction is a payment and the communicating object comprises at least two means of payment associated respectively with two different users
• the at least one additional piece of data is an identifier of the means of payment associated with the user of the object at the time of the transaction.
• the communicating object in the case where the communicating object is able to implement a payment for several different potential users, the communicating object is advantageously capable of independently and automatically deducing the means of payment from the user actually affected by this payment.
• the comparison of the extracted information with the usage context data comprises the following:
• Such an embodiment constitutes a decision-making mechanism that is very simple to implement and therefore suitable for preserving the computational resources of the communicating object, which are generally low.
• This score is then compared to a reference threshold, for example 0.5, which characterizes a valid transaction situation above this threshold and an invalid transaction situation below this threshold (the reverse is also possible depending on established comparison convention). If the assigned score is greater than (or greater than or equal to) this reference threshold, the communicating object sends a response to the request authorizing the transaction. If the assigned score is lower (or lower or equal) to this reference threshold, the communicating object does not respond to the request or sends a response to the request refusing the transaction.
• the context data of use of the communicating object are representative of an environment in which finds the communicating object or contain at least one operating datum of a transaction of the communicating object.
• Such context of use data is particularly accurate and reliable given that it is linked to the very environment in which the communicating object is located and/or that it is based on the operating data of this object.
• the at least one operating datum of the communicating object is a current operating parameter noted by the communicating object or an element of a history of the communications carried out by the communicating object.
• the usage context data representative of an environment in which the communicating object is located are contained in a message received by the communicating object from the communication device or from a device message transmission located in said environment.
• Such usage context data constitutes additional relevant data which can advantageously be used in the aforementioned comparison step, in addition to the usage context data obtained in the previous embodiment. It may be, for example, the name of the supplier of the good or service that is the subject of the transaction, the type of good or service, a place where the good or service is located.
• the usage context data representative of an environment in which the communicating object is located contain data coming from at least one sensor belonging to the communicating object.
• the invention also relates to a communicating object having capabilities for controlling a contactless transaction with a communication device, the communicating object comprising a processor which is configured to receive from the communication device a request containing data relating to the transaction.
• a communicating object is remarkable in that the processor of the communicating object executes the following autonomously:
• the invention also relates to a contactless transaction control system.
• Such a system is remarkable in that it includes:
• the invention also relates to a computer program comprising instructions for implementing the method for controlling a contactless transaction according to the invention, according to any one of the particular embodiments described previously, when said program is executed by a processor.
• Such instructions can be stored durably in a non-transitory memory medium of the communicating object implementing the method for controlling a contactless transaction according to the invention.
• This program may 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 partially compiled form, or in any other desirable form.
• the invention also relates to a recording medium or information medium readable by a computer, and comprising instructions of a computer program as mentioned above.
• the recording medium can be any entity or device capable of storing the program.
• the medium may comprise a storage means, such as a ROM, for example a CD ROM or a circuit ROM microelectronics, or even a magnetic recording medium, for example a mobile medium, a hard disk or an SSD.
• the recording medium can be a transmissible medium such as an electrical or optical signal, which can be conveyed via an electrical or optical cable, by radio or by other means, so that the program of computer it contains is executable remotely.
• the program according to the invention can in particular be downloaded onto a network, for example an Internet-type network.
• the recording medium 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 aforementioned contactless transaction control method.
• the present technique is implemented by means of software and/or hardware components.
• module may correspond in this document to a software component, a hardware component or a set of hardware and software components.
• FIG. 1A represents a contactless transaction control system according to a first embodiment of the invention
• FIG. 1B represents a contactless transaction control system according to a second embodiment of the invention
• FIG. 1C represents a contactless transaction control system according to a third embodiment of the invention
• FIG. 2 represents a communicating object in one embodiment of the invention
• FIG. 3 represents the main actions implemented in the contactless transaction control method, according to a particular embodiment of the invention.
• FIG. 4 represents an embodiment of a step for determining the legitimacy of the transaction or not, implemented in the contactless transaction control method according to the invention.
• FIG. 1A represents a contactless transaction control system according to a first embodiment of the invention.
• Such a system includes:
• a communication device DCi configured to communicate with the object OC1 for the implementation of a contactless transaction relating to the supply of a good or a service by the DFi device.
• a communicating or connected object is any object configured to capture data and to communicate with other objects or with dedicated infrastructures according to loT (Internet of Things) technology.
• the contactless transaction control method is implemented at the level of the communicating object OC1, completely autonomously, as will be described later in the description.
• the communicating object OC1 is for example a vehicle, here a connected electric car.
• the OC1 car is natively equipped with a plurality of sensors/detectors such as for example a camera, a sensor which detects the battery charge level, a speed sensor, a GPS-type geolocation device (“Global Positioning System”), a fingerprint sensor, etc.
• sensors/detectors such as for example a camera, a sensor which detects the battery charge level, a speed sensor, a GPS-type geolocation device (“Global Positioning System”), a fingerprint sensor, etc.
• the connected car OC1 is equipped with:
• an MCO module for short or medium range wireless radio communication, such as for example Bluetooth, LTE, WiFi, DSRC, C-V2X, etc.,
• a contactless transaction MT module for example an eSIM card
• the DFi device for supplying goods or services is one charging station among others available from a charging station for electric vehicles.
• the charging station bears the number 3.
• the communication device DCi is a payment server or a TPE which can be included in the charging station DFi or even separated from it.
• the connected electric car OC1 begins by pairing with the DFi charging station, via its communication module MCO, in order to establish a secure contactless communication channel to set up implements the contactless transaction, here a payment corresponding to the recharge made.
• This contactless transaction is controlled by the connected car OC1, from the moment the user UT has connected the charging connector of the DFi terminal to the battery of the connected car OC1. If the connected car OC1 considers that the contactless transaction is valid/legitimate, the contactless transaction begins, then ends once the user has replaced the charging connector on the terminal.
• the DFi device for providing goods or services varies according to the context of use of the connected car OC1.
• the device for supplying DFi goods or services could alternatively be:
• FIG. 1B represents a contactless transaction control system according to a second embodiment of the invention.
• This second embodiment uses elements common to those of FIG. 1A. For this reason, these elements are designated with the same references.
• Such a system includes:
• a communication device DC2 configured to communicate with the object OC2 for the implementation of a transaction relating to the supply of a good or a service by the device DF2.
• the contactless transaction control method is implemented at the level of the communicating object OC2, completely autonomously as will be described later in the description.
• the communicating object OC2 is an object worn by the user UT, such as for example a connected watch. It could of course be a tablet, a badge, a bracelet, glasses, etc.
• the OC2 watch is natively equipped with a plurality of sensors/detectors such as, for example, a camera, a camera, an accelerometer, a GPS-type geolocation device, a digital fingerprint sensor, etc.
• sensors/detectors such as, for example, a camera, a camera, an accelerometer, a GPS-type geolocation device, a digital fingerprint sensor, etc.
• the connected watch OC2 is equipped with:
• a contactless transaction module MT for example an electronic purse embedded in the connected watch OC3, in which has/have been preloaded one or more digital transport tickets (“tokens” in English), a particular identifier IDGT associated with the electronic purse, etc.
• the device DF2 for providing goods or services is an access gate to a means of transport, such as for example the metro, train, tramway, etc. It can also be a terminal located in a bus or tram, near a platform in a station, etc.
• the communication device DC2 is an access control server which can be included in the gate DF2 or even separated from it.
• the connected watch OC2 begins by pairing with the gate DF2, via its communication module MCO, in order to establish a secure contactless communication channel to implement the transaction. without contact, here an access to the means of transport.
• This contactless transaction is controlled by the connected watch OC2, from the moment the user UT is a few centimeters from the gate DF2. If the connected watch OC2 judges that the contactless transaction is valid/legitimate, the contactless transaction begins with the server DC2, which causes the gate DF2 to open to let the user UT pass, then ends once the UT user passed this gate.
• Such access control implements for example a decrementation of one or more digital transport tickets preloaded in the electronic wallet of the OC2 connected watch.
• such an access control implements for example a verification of the particular identifier IDGT associated with the electronic purse of the connected watch OC2 for the purpose of automatically validating access to the means of transport on the basis of that particular identifier.
• FIG. 1C represents a contactless transaction control system according to a third embodiment of the invention.
• This third embodiment uses elements common to those of FIGS. 1 A and 1 B. For this reason, these elements are designated with the same references.
• Such a system includes:
• a communication device DC3 configured to communicate with the object OC3 for the implementation of a transaction relating to the supply of a good or a service by the device DF3.
• the contactless transaction control method is implemented at the level of the communicating object OC3, completely autonomously, as will be described later in the description.
• the communicating object OC3 is an object carried by the user UT, such as for example a smartphone. It could of course also be a tablet, a badge, a bracelet, etc.
• the OC3 smartphone is natively equipped with a plurality of sensors/detectors such as, for example, a camera, a camera, an accelerometer, a GPS-type geolocation device, a biometric sensor, etc.
• sensors/detectors such as, for example, a camera, a camera, an accelerometer, a GPS-type geolocation device, a biometric sensor, etc.
• the OC3 smartphone is equipped with:
• a contactless transaction module MT for example a memory storing an identifier for withdrawing an order for goods or a service that the user UT has previously made.
• the device DF3 for supplying the good or the service ordered by the user UT is an automatic parcel pick-up box.
• this box comprises seven compartments referenced A to G.
• the communication device DC3 is a locker opening/closing control server. The DC3 server can be included in the DF3 withdrawal box or even separated from it.
• the smartphone OC3 begins by pairing with the withdrawal box DF3, via its communication module MCO, in order to establish a secure contactless communication channel to implement the contactless transaction, here a withdrawal of a COL package.
• This contactless transaction is controlled by the OC3 smartphone, from the moment the UT user is a few centimeters from the DF3 withdrawal box. If the OC3 smartphone considers that the contactless transaction with the DC3 server is valid/legitimate, the contactless transaction begins with the DC3 server, which leads to the opening of one of the lockers which contains the package COL, locker E in the example shown. The contactless transaction ends once the user UT has removed the package COL from the locker E and the latter has been closed.
• Such access control implements for example a verification that the withdrawal identifier stored in the memory of the smartphone OC3 corresponds to the identifier of the package COL awaiting withdrawal in the locker E, in order to cause the automatic opening of this locker, without the UT user having to handle his OC3 smartphone.
• FIG. 2 presents the simplified structure of the communicating object OC, such as for example the object OC1, OC2 OR OC3 of FIGS. 1A to 1C, which communicating object is suitable for implement the method of controlling a contactless transaction which will be described below.
• such a communicating object typically includes:
• an MCO communication module adapted to communicate via an RCMP short or medium range wireless data network, such as for example Bluetooth, NFC, LTE, WiFi, DSRC, C-V2X, etc.,
• the communicating object OC further comprises according to the invention:
• an MCO communication module suitable for communicating via a long-range data RLP network (3G, 4G, 5G, etc.),
• a module REC for receiving broadcast messages MSG for example of the beacon type or of the V2X type ("Vehicle-to-Everything" in English) when the object communicating object OC is more particularly a vehicle, these broadcast messages being received from different devices and/or infrastructures that the communicating object encounters on its journey,
• a transaction module MT such as for example a SIM card, eSIM, e-wallet, a memory dedicated to the contactless transaction, etc.
• an analysis module ANA configured to analyze transaction data DAT1 contained in the transaction requests that the communicating object OC receives from a communication device DC, such as for example the communication device DCi, DC20U DC3 figures 1A to 1C,
• module DET configured to determine at least one additional transaction data DAT2 in addition to that (s) already contained in the transaction requests received
• the memory MEM1 is not contained in the communicating object OC in order to preserve its memory resources.
• the memory MEM1 is remote in a communication network, a cloud, etc. and is made accessible by the communicating object OC, by means of the module ACC dedicated to this purpose.
• the memory MEM1 or part of it could be integrated into the communicating object OC.
• the module DET for determining at least one complementary transaction datum DAT2 is integrated into the communicating object OC, the module DET could be dissociated from this object to preserve the calculation resources of the latter.
• the actions executed by the communicating object OC within the framework of the implementation of the method for controlling a contactless transaction in accordance with the present invention, are implemented by instructions from a PG computer program.
• the communicating object OC has the conventional architecture of a computer and comprises in particular a memory MEM2, a processing unit UTR, equipped for example with a processor PROC, and controlled by the computer program PG stored in memory MEM2.
• the PG computer program includes instructions for setting up implements the actions executed by the communicating object OC, when the program is executed by the processor PROC, according to any one of the particular embodiments of the invention.
• the code instructions of the computer program PG are for example loaded into a RAM memory (not shown) before being executed by the processor PROC.
• the processor PROC of the processing unit UTR notably implements the actions for collecting data from the and/or sensors CAPi, CAP2,..., CAPs, the actions for receiving the and/or messages MSG, the actions for receiving transaction requests, actions for analyzing these requests, actions for determining at least one complementary transaction datum, actions for sending or not sending a response to these transaction requests.
• FIG. 3 the progress of a method for controlling a contactless transaction executed by a communicating object OC, such as for example the object OC1, OC2 OR OC3 of FIGS. 1A to 1C, according to an embodiment of the invention.
• a contactless transaction is established during a contactless communication between the communicating object OC and the aforementioned communication device DC, such as for example the communication device DC1, DC20U DC3 of FIGS. 1A to 1C.
• the object of the contactless transaction is for example a good or a service supplied by a device DF for supplying goods or services to the user UT of the communicating object OC, such as for example the device for supplying goods or service DF1, DF20U DF3 of Figures 1A to 1C.
• the communicating object OC is configured in such a way that it autonomously executes the various actions which will be described below to control a contactless transaction with the communication device DC, as if it was the UT user himself who implemented such a control, namely to verify the legitimacy of the transaction, as the user usually does by verifying for example that the object of the transaction is the one he wants, that the price of the object, when this one is paying, is the good one, the place of the transaction, etc..., and to validate the transaction or not according to this verification.
• the user UT and his communicating object OC Prior to the execution of the contactless transaction control process described below, it is considered that the user UT and his communicating object OC have approached the device DF for the supply of goods or services and that the establishment of a communication channel in a secure way has been created to implement the contactless transaction between the communicating object OC and the communication device DC.
• the establishment of such a communication channel or pairing is conventional and will not be described further.
• the establishment of such a communication channel is executed autonomously by the communicating object OC as described in the document FR2106702 incorporated by way of reference in the present description.
• the method of controlling a contactless transaction then takes place as follows:
• the communicating object OC receives, from the communication device DC, a request REO_TR containing data DAT1 relating to a transaction.
• a request can be received by the communication module MCO or MCO’ of figure 2.
• the REO_TR request is for example a payment request.
• This may be a request for example of the SEPA RTP type (“Single Euro Payments Area Request to Pay”), of the Paypal type: https://developer.pavpal.com/docs/inteqration/pavpal-plus /mexico-brazii/create-a-pavment-request/. etc., for which the DAT1 data corresponds for example:
• the location of the transaction here the geolocation data of the charging station
• the request REO_TR is for example a request for identification of access to the means of transport.
• a request is for example of the Internet type. It contains DAT1 data corresponding for example:
• this identifier may begin with the letter "M” to indicate that it is a metro gate, with the letter "B” to indicate that it is the access terminal of a bus, etc.,
• the request REQ_TR is for example a request for access to the parcel collection box DF3.
• a request is for example of the Internet type. It contains DAT1 data corresponding for example:
• a withdrawal identifier such as for example a delivery code, the letter "G" of the locker which contains the COL package,...
• the contactless transaction control process continues in S2, where the communicating object OC extracts the data DAT1 from the request REQ_TR received.
• the ANA analysis module in Figure 2 implements an analysis of this DAT1 data.
• the data DAT1 are compared with context of use data DCU of the communicating object OC.
• the context of use data/information DCU is data/information collected by the communicating object OC during its movement towards the device DF for supplying a good or service, but also prior to this movement.
• the DCU usage context data/information: - are data/information INF1 representative of an environment in which the communicating object OC is located: it may be for example one or more information conveyed in a message MSG received by the reception module REC of the figure 2, coming from the communication device DC or from a message transmission device located in the environment of the communicating object OC, or even from one or more data coming from at least one of the sensors CAPi at Figure 2 CAPs; and or
• At least one operating data item INF2 of the communicating object OC such as for example a current operating parameter recorded by the communicating object OC, and/or
• INF4 elements from a list of known types of fraud, and/or
• one or more complementary transaction data DAT2 are determined or identified in S4 using the module DET of FIG. 2. Such a determination can be carried out locally by the object communicating OC or remotely.
• the data/information INF1 representative of an environment in which the connected electric car OCi is located are received by the car OCi, via the reception module REC of FIG. 2. They are conveyed for example in a message MSG broadcast for example by the server DCi or by the search terminal DFi, depending on the communication context envisaged.
• the MSG message can also be broadcast by any suitable infrastructure such as the charging station which manages all the charging terminals, a restaurant, a road centre, a local authority, etc.
• Such an MSG message is for example type beacon, V2X, UWB ("Ultra wideband" in English), WiFi multicast, or even LiFi ("Light Fidelity" in English), etc...
• this information INF1 designates for example: - the name of the charging station where the DFi charging station is located, the number of this station, etc...
• the data/information INF1 can also correspond to an interpretation made by the connected electric car OC1 of the data coming from its various sensors CAPi to CAPs, typically the level of the electricity recharge of its battery, the dimensions or the type of the car OC1 , the occupant(s) of the car OC1 (biometrics), etc.
• the data/information INF1 can also correspond, for example, to a sign or logo of the charging station which has been recognized after analysis of an image or a video captured by one of the sensors CAPi, CAP2, ..., CAPs of the OC1 car, typically a camera or camcorder. It can also be the metadata associated with this image, such as for example the geographical position of the charging station, the date and/or time of capture of the image or video.
• the data/information INF1 also correspond in this context of use to the geographical coordinates (Cartesian, polar, spherical, etc.) of the car OC1 which are measured by one of the sensors CAPi, CAP2, ..., CAPs of the car OC1 , typically a GPS device.
• geographical coordinates Cartesian, polar, spherical, etc.
• the operating data/information INF2 of the connected car OC1 correspond to the parameters linked to the infrastructure of the car OC1 and fed back via a multiplex or a data bus installed in the car. These are for example the current speed, the opening/closing of the fuel flap/electric charging, the decrease/rise of the fuel/battery level, the opening/closing of a door , etc...
• the element INF3 of a history of transactions already carried out by the car OC1 is typically information relating to payments previously carried out by the car OC1.
• the additional transaction data DAT2 are for example the identity of the person driving the car OC1, the mileage traveled, the location of the car OC1 at the time of the payment.
• the additional data DAT2 correspond to an identifier of the payment module associated with the person identified at the previously by a biometric sensor of the car OC1.
• the determination step S4 advantageously makes it possible to automatically select the transaction module MT associated with the effective user UT of the communicating object OC when several users are potentially able to use this object.
• the data/information INF1 representative of an environment in which the connected watch OC2 is located are received via the reception module REC of FIG. 2. They are conveyed for example in a message MSG broadcast for example by the server DC2 or by the gate DF2 depending on the communication context envisaged.
• the MSG message can also be broadcast by a transmitter placed in a station or station, in the metro, on the bus, etc.
• the data/information INF1 designate for example the name of a station or a bus/tram stop, the identifier of a transport line, geolocation information of the connected watch OC2 in the station or the station , the type of means of transport used, for example "metro", associated with the DF2 gate, etc.
• Such a MSG message is for example of the beacon, UWB (“Ultra Wideband”), WiFi multicast, or even LiFi (“Light Fidelity”) type, etc.
• the data/information INF1 can also correspond to an interpretation made by the connected watch OC2 of the data coming from its various sensors CAP1 to CAPs. They correspond for example to the name of the station or station, to an identifier of the transport line taken by the UT user, etc. which have been recognized after analysis of an image or a video captured by one of the CAP1, CAP2, ..., CAPs sensors of the OC2 watch, typically a camera or a video camera. It can also be the metadata associated with this image, such as the geographical position of the station or station, the date and/or time of capture of the image or video.
• the data/information INF1 may also correspond, in this context of use:
• CAPs of the watch OC2 typically an accelerometer, - to the geographical coordinates (Cartesian, polar, spherical, etc.) of the watch OC2 which are measured by one of the sensors CAP1, CAP2, ..., CAPs of the watch OC2, typically a GPS device.
• the operating data/information INF2 of the connected watch OC2 correspond for example to the current date and time.
• the element INF3 of a history of transactions already carried out by the connected watch OC2 is typically information relating to public transport journeys previously carried out by the user UT.
• the additional transaction data DAT2 are for example the identity of the user UT who wears the connected watch OC2, the location of the connected watch OC2 at the time of passing the gate DF2 by the user UT, the number of remaining digital tickets, etc.
• the additional data DAT2 correspond to an identifier of the transport card associated with the person previously identified, for example using a biometric sensor of the OC2 connected watch.
• the data/information INF1 representative of an environment in which the smartphone OC3 is located are received via the reception module REC of FIG. 2. They are conveyed for example in a message MSG broadcast for example by the server DC3 or by the withdrawal box DF3 depending on the communication context envisaged.
• the MSG message can also be broadcast by a transmitter placed close to the DF3 withdrawal box.
• the data/information INF1 designate for example the name or an identifier of the withdrawal box DF3, a location in which the withdrawal box DF3 is located, the location of the smartphone OC3 with respect to the withdrawal box DF3, etc.
• the data/information INF1 can also correspond to an interpretation made by the smartphone OC3 of the data coming from its various sensors CAP1 to CAPs. They correspond for example to the name or an identifier of the DF3 collection box which have been identified after analysis of an image or a video captured by one of the sensors CAP1, CAP2, CAPs of the smartphone OC3, typically a camera or a camera. It can also be the metadata associated with this image, such as the geographical position of the DF3 withdrawal box, the date and/or time of capture of the image or video.
• the data/information INF1 may also correspond, in this context of use:
• CAPs sensors of the OC3 smartphone typically an accelerometer
• the operating data/information INF2 of the smartphone OC3 correspond, for example, to the current date and time, to the current operating mode of the smartphone OC3 (on, off, airplane mode, standby, etc.).
• the element INF3 of a history of transactions already carried out by the smartphone OC3 is typically information relating to the various orders for goods or services which have been carried out previously by the user UT with the OC3 smartphone.
• the additional transaction data DAT2 are for example the identity of the user UT who uses the smartphone OC3, data from a profile of this user UT (browsing history, directory , etc.) loaded into the OC3 smartphone when the UT user turned on the OC3 smartphone, the location of the OC3 smartphone at the time the UT user approached the DF3 pick-up box, a logo of the delivery sign of the COL parcel, the telecommunications operator in connection with the MT eSIM card, etc.
• the additional data DAT2 corresponds to an identifier of the eSIM card , e-wallet or other associated with the person identified beforehand, for example using a biometric sensor of the OCs smartphone.
• the communicating object OC identifies the transaction as valid/legitimate. To this end, it activates in S5 the sending to the communication device DC, via its communication module MCO or MCO', of a response REP_TR_AUT to the request REO_TR, said response REP_TR_AUT authorizing the transaction between the communicating object OC and the DC communication device.
• the REP_TR_AUT response can be enriched by at least one data item DAT2 which was determined in S4.
• the DAT2 data and/or data may be transmitted by the communication device DC both to the transaction manager and to the manager of the communicating object (e.g. manager of a fleet of vehicles, bank, etc., in the case where the communicating object OC is a connected car OCi, public transport company in the case where the communicating object OC is a connected watch OC2, telecommunications operator or delivery sign, in the case where the communicating object OC is an OC3 smartphone), or even to the supplier of the good or service that is the subject of the transaction (service station, merchant website, etc.).
• This/these DAT2 data(s) may thus be advantageously used for the purposes of processing/archiving/tracing transactions that have been carried out by a user UT of the given communicating object OC, at a given time.
• the communicating object OC identifies the transaction as invalid/illegitimate. To this end, it activates in S6 the sending to the communication device DC, via its communication module MCO or MCO', of a response REP_TR_REF to the request REO_TR, said response REP_TR_REF designating a refusal of the transaction between the object communicating OC and the communicating device DC.
• the communicating object OC sends no response to the REO_TR request and the transaction process ends after a period fixed beforehand, the duration of which depends on the implementation carried out.
• the steps of the contactless transaction control method which have just been described above advantageously allow any connected object to check whether a transaction (payment, access, order withdrawal, etc.) with a communication device ( payment server, access control server or gate, command to open/close a parcel collection box, an automatic locker, etc.) is valid/legitimate or not, and this in a way completely autonomous and secure.
• a transaction payments, access, order withdrawal, etc.
• a communication device payment server, access control server or gate, command to open/close a parcel collection box, an automatic locker, etc.
• step S3 of FIG. 3 an embodiment of the comparison implemented during step S3 of FIG. 3 to characterize the match or lack of match between the data DAT1 and the context data of use DCU of the communicating object OC.
• Such a comparison is implemented using a computer processing tool, of the artificial intelligence type.
• the comparison S3 for this purpose comprises a sub-step S30 during which reference usage context information ICURef is combined.
• This ICURef reference usage context information can take different forms. It can be for example:
• a reliability score SC is assigned to the result of this combination.
• the score SC is compared with the value V obtained in S30 which is considered as a reference value.
• Other framing values are of course possible depending on the implementation of the contactless transaction control method.
• step S5 for activating reception of pairing requests is triggered. If SC£V (or SC ⁇ V according to the established convention) (N in FIG. 4), step S6 of ceasing the transaction control method or of sending a response REP_TR_REF refusing the transaction is implemented .
• additional data can be used to refine the comparison S3, such as for example data from an external database of known frauds (to detect a risky transaction situation), data provided by the user UT if he is present at the time the comparison is implemented S3, data corresponding to the selection of a specific transaction module MT (for example a transaction module benefiting from a particular insurance, a transaction module having a particular identifier IDGT which authorizes free public transport, etc. ).
• a specific transaction module MT for example a transaction module benefiting from a particular insurance, a transaction module having a particular identifier IDGT which authorizes free public transport, etc.
• the usage context information DCU determined is for example:
• the data DAT1 are for example the date and the time of the day as well as the amount of the payment of the recharge. This information is compared in S3 with a learning situation which has been modeled with reference usage context information ICllRef of the same type or of a type similar to the DCU usage context information and the DAT1 data and which has already been assessed beforehand in an identical or similar context of use:
• the value of the reliability score SC assigned in S32 will be greater than V or greater or equal to V.
• the DCU usage context information determined is for example:
• the "parking" category is identified in an MSG message, and the data DAT1 are for example the date and time of day, as well as the payment amount for a baguette, then the value of the score of reliability SC assigned in S32 will be less than V or less than or equal to V to characterize the fact that there are one or more inconsistencies between the usage context information DCU and the data DAT1.
• the determined context of use information DCU is for example:
• the DAT1 data is for example an identifier of a gate which begins with the letter "B" to indicate that the means of transport used is a bus,
• This information is compared to a learning situation which has been modeled with reference use context information ICllRef of the same type or of a type similar to the DCU use context information and which has already been evaluated beforehand in a context of use of an identical or similar means of transport and representative of the public transport travel habits of the user UT or of another user who shares the connected watch OC2 with the user UT.
• the value of the reliability score SC assigned in S32 will be greater than V or greater or equal to V.
• the DCU usage context information determined is for example:
• the value of the reliability score SC assigned in S32 will be less than V or less than or equal to V to characterize the fact that there is one or more inconsistencies between the usage context information DCU and the data DAT1.
• the usage context information DCU determined is for example: - the name or an identifier of the DF3 withdrawal box broadcast in an MSG message,
• the DAT1 data are, for example, the date and time of day as well as the price of the order to be withdrawn and a number of items corresponding to the order which is equal to 3.
• This or these pieces of information is/are compared to a learning situation which has been modeled with one or more ICURef reference context of use information of the same type or of a type similar to the context information of use DCU and which has already been evaluated beforehand in an identical or similar context of use which defines the places for picking up parcels where the user UT goes most often, a control kinematics known to the user UT or another user sharing the OC3 smartphone with the UT user, etc.
• the value of the reliability score SC assigned in S32 will be greater than V or greater than or equal to to V.
• the DCU usage context information determined is for example:
• the data DAT1 are for example the date and time of day as well as the price of the order to withdraw which corresponds to a number of items equal to 3, then the value of the reliability score SC assigned in S32 will be less than V or less than or equal to V to characterize the fact that there is one or more inconsistencies between the usage context information DCU and the data DAT1.

Landscapes

• Business, Economics & Management (AREA)
• Engineering & Computer Science (AREA)
• General Physics & Mathematics (AREA)
• Physics & Mathematics (AREA)
• Accounting & Taxation (AREA)
• Theoretical Computer Science (AREA)
• General Business, Economics & Management (AREA)
• Strategic Management (AREA)
• Computer Networks & Wireless Communication (AREA)
• Finance (AREA)
• Computing Systems (AREA)
• Development Economics (AREA)
• Economics (AREA)
• Computer Security & Cryptography (AREA)
• Management, Administration, Business Operations System, And Electronic Commerce (AREA)
• Computer And Data Communications (AREA)

Applications Claiming Priority (2)

Publications (1)

Family

ID=77180251

Family Applications (1)

Country Status (4)

Family Cites Families (4)

• 2021
  • 2021-07-06 FR FR2107284A patent/FR3125152A1/fr not_active Withdrawn
• 2022
  • 2022-06-17 US US18/573,957 patent/US20240362614A1/en active Pending
  • 2022-06-17 EP EP22741348.1A patent/EP4367620A1/de active Pending
  • 2022-06-17 WO PCT/FR2022/051183 patent/WO2023281178A1/fr active Application Filing

Also Published As

Similar Documents

Legal Events