EP4367620A1 - Procédé de controle d'une transaction sans contact et objet communicant correspondant - Google Patents

Procédé de controle d'une transaction sans contact et objet communicant correspondant

Info

Publication number
EP4367620A1
EP4367620A1 EP22741348.1A EP22741348A EP4367620A1 EP 4367620 A1 EP4367620 A1 EP 4367620A1 EP 22741348 A EP22741348 A EP 22741348A EP 4367620 A1 EP4367620 A1 EP 4367620A1
Authority
EP
European Patent Office
Prior art keywords
transaction
communicating object
data
request
communication device
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
EP22741348.1A
Other languages
German (de)
English (en)
Inventor
Emmanuel Le Huerou
François Toutain
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Orange SA
Original Assignee
Orange SA
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Orange SA filed Critical Orange SA
Publication of EP4367620A1 publication Critical patent/EP4367620A1/fr
Pending legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; 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 OR CALCULATING; 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 OR CALCULATING; 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 OR CALCULATING; 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 OR CALCULATING; 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 OR CALCULATING; 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)
  • General Business, Economics & Management (AREA)
  • Theoretical Computer Science (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)

Abstract

L'invention concerne un procédé de contrôle d'une transaction sans contact entre un objet communicant (OC) et un dispositif de communication (DC), au cours duquel l'objet communicant reçoit (S1) en provenance du dispositif de communication une requête contenant des données relatives à la transaction, le procédé étant caractérisé en ce que l'objet communicant exécute de manière autonome ce qui suit : - extraire (S2) de ladite requête reçue des informations (DAT1) relatives à la transaction, - comparer (S3) les informations extraites à des données de contexte d'utilisation (DCU) de l'objet communicant qui ont été déterminées par l'objet, - activer (S5) l'envoi au dispositif de communication d'une réponse à la requête autorisant la transaction, quand une concordance existe entre les informations relatives à la transaction et les données de contexte d'utilisation.

Description

Procédé de contrôle d’une transaction sans contact et objet communicant correspondant
Domaine de l'invention
L'invention concerne les communications sans contact, c’est-à-dire sans fil, pour la transmission de données entre un objet communicant et un dispositif de communication. Plus précisément, l'invention porte sur les transactions mises en œuvre lors de ces communications sans contact, telles que notamment les transactions de type bancaire, accès à un moyen de transport ou à un lieu sécurisé, commande de bien(s) ou de service(s), etc... et la façon dont un objet communicant, tel que par exemple un véhicule connecté, un smartphone (« téléphone intelligent »), une montre connectée, contrôle ces transactions sans contact avec un dispositif de communication, typiquement un lecteur, un point de paiement, un portillon d’accès, etc.
Art antérieur
Il est possible actuellement de mettre en œuvre une transaction à l’aide d’un objet communicant ou connecté. Dans le cas par exemple où la transaction est un paiement d’un bien ou d’un service, un utilisateur qui a réalisé un achat peut payer celui-ci en utilisant un objet connecté, tel qu’une carte bancaire, un smartphone (« téléphone intelligent »), une montre connectée, etc. A cet effet, l’utilisateur connaît le contexte de son achat (l’objet de son achat, le lieu de l’achat, le commerçant, etc.). Ainsi, lorsque le commerçant présente à l’utilisateur un terminal de paiement électronique (TPE) sur lequel est affiché le prix correspondant à cet achat et quelquefois l’objet de cet achat, l’utilisateur vérifie ces informations et, si elles lui conviennent, approche son objet connecté du TPE pour autoriser la transaction si celle-ci est sans contact. Dans le cas où la transaction sans contact n’est pas possible, l’utilisateur est obligé de saisir un code sur le TPE pour autoriser la transaction.
Dans le cas où la transaction est l’accès à un local sécurisé ou à un moyen de transport (métro par exemple) via un portillon d’accès, l’utilisateur connaît le lieu et les conditions de cet accès. Ainsi, lorsque l’utilisateur s’approche d’une borne ou d’un portillon, il lui suffit d’approcher son objet connecté (badge d’accès, carte de transport, smartphone, etc.) pour valider l’accès. On voit par ailleurs apparaître depuis quelques années des objets connectés plus sophistiqués, tels que par exemple des véhicules connectés. Ces véhicules connectés sont dotés :
- de moyens de communication sans fil courte ou moyenne portée tel que par exemple Bluetooth, LTE (« Long Term Evolution » en anglais), WiFi DSRC
(« Dedicated Short Range Communication » en anglais), C-V2X (« Cellular Vehicle To Everything » en anglais), etc.
- de moyens de transaction, tels que par exemple une carte eSIM (« Embedded Subscriber Identification Module » en anglais) installée dans le véhicule, un porte- monnaie électronique (« e-wallet » en anglais) embarqué dans l’infrastructure informatique du véhicule et dans lequel a/ont été préchargée(s) une ou plusieurs unités de monnaie numérique (« tokens » en anglais) de carte bancaire, etc.
Grâce à une telle technologie, des transactions sans contact peuvent être mises en œuvre dans le véhicule connecté pour accéder à des biens ou des services qui incluent par exemple le stationnement dans un parking, le paiement d’un péage autoroutier, l’utilisation d’une station-service (essence ou recharge électrique, lavage, ...), une opération de maintenance ou d’entretien, la délivrance d’une commande à un service de type drive-in (fastfood, click & collect...).
Un inconvénient de l’utilisation d’un tel véhicule connecté est que l’utilisateur est obligé, comme dans les cas d’usage précédents, de vérifier toutes les informations relatives à la transaction, lesquelles s’affichent par exemple sur une console du tableau de bord, avant d’autoriser la transaction, en cliquant sur un bouton « valider » affiché sur la console, ou avant de refuser la transaction, en cliquant sur un bouton « annuler » affiché sur la console.
Bien qu’un tel véhicule connecté facilite la mise en œuvre des transactions d’un utilisateur qui se trouve à son bord, l’utilisateur est quand même obligé d’intervenir lors de la transaction pour la vérifier et la valider.
Objet et résumé de l'invention
Un des buts de l'invention est de remédier à des inconvénients de l'état de la technique précité en permettant à un objet connecté de contrôler la mise en œuvre d’une transaction sans contact avec un dispositif de communication de manière complètement autonome et sécurisée, sans qu’un utilisateur de l’objet n’ait besoin d’intervenir sur l’objet connecté ou de le manipuler. A cet effet, un objet de la présente invention concerne un procédé de contrôle d’une transaction sans contact entre un objet communicant et un dispositif de communication, au cours duquel l’objet communicant reçoit en provenance du dispositif de communication une requête contenant des données relatives à la transaction.
Un tel procédé est remarquable en ce que l’objet communicant exécute de manière autonome ce qui suit :
- extraire de la requête reçue des informations relatives à la transaction,
- comparer les informations extraites à des données de contexte d’utilisation de l’objet communicant qui ont été déterminées par l’objet,
- activer l’envoi au dispositif de communication d’une réponse à la requête autorisant la transaction, quand une concordance existe entre les informations relatives à la transaction et les données de contexte d’utilisation.
L’invention permet avantageusement à un objet connecté, apte à communiquer sans contact avec un dispositif de communication dans le cadre de la mise en œuvre d’une transaction, d’être pourvu d’un mécanisme décisionnel permettant de vérifier :
- si une requête contenant des données relatives à la transaction, reçue en provenance du dispositif de communication, est légitime ou non,
- et, dans le cas où cette requête est considérée légitime par l’objet, de répondre favorablement à cette requête afin de mettre en œuvre la transaction.
Un avantage de l’invention est qu’une telle vérification est exécutée de façon complètement autonome par l’objet communicant, tel que par exemple un véhicule connecté, une montre connectée, une carte connectée, c’est-à-dire sans aucune intervention ou manipulation humaine par rapport à l’objet. Ainsi, grâce à l’invention, l’objet connecté décide de sa propre initiative s’il est autorisé à effectuer une transaction sans contact à bon escient avec le dispositif de communication, une telle transaction étant par exemple un paiement, la livraison d’un bien ou d’un service, l’accès à une consigne, un moyen de transport, etc.
Un tel mécanisme décisionnel installé dans l’objet communicant permet par ailleurs d’éviter ou de limiter le développement et le déploiement dans le réseau d’outils de traitement préventifs destinés à vérifier la légitimité d’une requête, ces outils étant complexes techniquement et coûteux. Selon un mode de réalisation particulier, en l’absence d’une concordance entre les informations relatives à la transaction et les données de contexte d’utilisation, l’objet communicant active l’envoi au dispositif de communication d’une réponse à la requête refusant la transaction, ou ne répond pas à la requête.
Grâce à ce mode de réalisation, l’objet communicant est apte à traiter de manière autonome la réception de toute requête contenant des données relatives à une transaction qui ne serait pas destinée à cet objet communicant mais à un autre objet communicant ou bien qui serait destinée à l’objet communicant de manière frauduleuse ou par erreur. A cet effet, l’objet communicant peut envoyer une réponse à la requête refusant la transaction, ce qui met fin à la communication entre l’objet communicant et le dispositif de communication. A titre d’alternative, l’objet communicant peut ignorer cette requête et ne pas y répondre, dans un souci d’économie des ressources de la batterie de l’objet communicant et/ou de la bande passante du réseau de communication sans fil entre l’objet communicant et le dispositif de communication.
Selon un autre mode de réalisation particulier, au cours de la comparaison des informations extraites avec les données de contexte d’utilisation, au moins une donnée complémentaire relative à la transaction est déterminée, ladite au moins une donnée complémentaire étant ajoutée dans la réponse à la requête autorisant la transaction.
Grâce à ce mode de réalisation, l’objet communicant est en mesure :
- de générer de manière autonome une ou plusieurs données complémentaires relatives à la transaction, telles que par exemple un identifiant associé à l’utilisateur de l’objet au moment de la transaction, l’identité de cet utilisateur, le lieu de la transaction, etc..., et
- de communiquer astucieusement cette/ces donnée(s) complémentaire(s) dans la réponse à la requête autorisant la transaction.
La réponse à la requête autorisant la transaction est ainsi avantageusement enrichie de données utiles que le dispositif de communication pourra transmettre au gestionnaire de la transaction ou de l’objet communicant ou encore au fournisseur du bien ou du service, pour un traitement/archivage/traçage des transactions qui ont été effectuées par un utilisateur de l’objet communicant particulier. Selon un autre mode de réalisation particulier, lorsque la transaction est un paiement et que l’objet communicant comprend au moins deux moyens de paiement associés respectivement à deux utilisateurs différents, la au moins une donnée complémentaire est un identifiant du moyen de paiement associé à l’utilisateur de l’objet au moment de la transaction.
Grâce à ce mode de réalisation, dans le cas où l’objet communicant est apte à mettre en œuvre un paiement pour plusieurs utilisateurs potentiels différents, l’objet communicant est avantageusement capable de déduire de manière autonome et automatiquement le moyen de paiement de l’utilisateur réellement concerné par ce paiement.
Selon un autre mode de réalisation particulier, la comparaison des informations extraites avec les données de contexte d’utilisation comprend ce qui suit :
- générer un score de fiabilité de la comparaison,
- comparer le score généré à un seuil,
- en fonction du résultat de la comparaison :
■ activer l’envoi au dispositif de communication d’une réponse à la requête autorisant la transaction,
■ activer l’envoi au dispositif de communication d’une réponse à la requête refusant la transaction ou ne pas répondre à la requête.
Un tel mode de réalisation constitue un mécanisme décisionnel très simple à implémenter et donc adapté à la préservation des ressources en calculs de l’objet communicant qui sont généralement peu élevées. Ce score est alors comparé à un seuil de référence, par exemple 0.5, qui caractérise une situation de transaction par exemple valide au-dessus de ce seuil et une situation de transaction invalide en- dessous de ce seuil (l’inverse est également possible selon la convention de comparaison établie). Si le score attribué est supérieur (ou supérieur ou égal) à ce seuil de référence, l’objet communicant envoie une réponse à la requête autorisant la transaction. Si le score attribué est inférieur (ou inférieur ou égal) à ce seuil de référence, l’objet communicant ne répond pas à la requête ou envoie une réponse à la requête refusant la transaction.
Selon un autre mode de réalisation particulier, les données de contexte d’utilisation de l’objet communicant sont représentatives d’un environnement dans lequel se trouve l’objet communicant ou contiennent au moins une donnée de fonctionnement d’une transaction de l’objet communicant.
De telles données de contexte d’utilisation déterminées en toute autonomie par l’objet communicant sont particulièrement précises et fiables étant donné qu’elles sont liées à l’environnement même dans lequel se trouve l’objet communicant et/ou qu’elles sont basées sur des données de fonctionnement de cet objet.
Selon un autre mode de réalisation particulier, la au moins une donnée de fonctionnement de l’objet communicant est un paramètre de fonctionnement courant relevé par l’objet communicant ou un élément d’un historique des communications effectuées par l’objet communicant.
Selon un autre mode de réalisation particulier, les données de contexte d’utilisation représentatives d’un environnement dans lequel se trouve l’objet communicant sont contenues dans un message reçu par l’objet communicant en provenance du dispositif de communication ou d’un dispositif d’émission de message situé dans ledit environnement.
De telles données de contexte d’utilisation constituent des données pertinentes complémentaires qui peuvent avantageusement être utilisées dans l’étape de comparaison précitée, en sus des données de contexte d’utilisation obtenues dans le mode de réalisation précédent. Il peut s’agir par exemple du nom du fournisseur du bien ou du service faisant l’objet de la transaction, du type de bien ou de service, d’un lieu où se trouve le bien ou le service.
Selon un autre mode de réalisation particulier, les données de contexte d’utilisation représentatives d’un environnement dans lequel se trouve l’objet communicant contiennent une donnée issue d’au moins un capteur appartenant à l’objet communicant.
Les différents modes ou caractéristiques de réalisation précités peuvent être ajoutés indépendamment ou en combinaison les uns avec les autres, au procédé de contrôle d’une transaction sans contact défini ci-dessus.
L'invention concerne également un objet communicant ayant des capacités de contrôle d’une transaction sans contact avec un dispositif de communication, l’objet communicant comprenant un processeur qui est configuré pour recevoir en provenance du dispositif de communication une requête contenant des données relatives à la transaction. Un tel objet communicant est remarquable en ce que le processeur de l’objet communicant exécute de manière autonome ce qui suit :
- extraire de la requête reçue des informations relatives à la transaction,
- comparer les informations extraites à des données de contexte d’utilisation de l’objet communicant qui ont été déterminées par l’objet,
- activer l’envoi au dispositif de communication d’une réponse à la requête autorisant la transaction, quand une concordance existe entre les informations relatives à la transaction et les données de contexte d’utilisation.
L'invention concerne également un système de contrôle d’une transaction sans contact.
Un tel système est remarquable en ce qu’il comprend :
- un objet communicant mettant en œuvre le procédé de contrôle de transaction sans contact précité,
- un dispositif de communication sans contact qui est configuré pour envoyer à l’objet communicant une requête contenant des données relatives à la transaction. L'invention concerne encore un programme d'ordinateur comportant des instructions pour la mise en œuvre du procédé de contrôle d’une transaction sans contact selon l'invention, selon l’un quelconque des modes particuliers de réalisation décrits précédemment, lorsque ledit programme est exécuté par un processeur.
De telles instructions peuvent être stockées durablement dans un support mémoire non transitoire de l’objet communicant mettant en œuvre le procédé de contrôle d’une transaction sans contact selon l’invention.
Ce programme peut utiliser n’importe quel langage de programmation, et être sous la forme de code source, code objet, ou de code intermédiaire entre code source et code objet, tel que dans une forme partiellement compilée, ou dans n’importe quelle autre forme souhaitable.
L’invention vise également un support d’enregistrement ou support d’informations lisible par un ordinateur, et comportant des instructions d’un programme d’ordinateur tel que mentionné ci-dessus.
Le support d'enregistrement peut être n'importe quelle entité ou dispositif capable de stocker le programme. Par exemple, le support peut comporter un moyen de stockage, tel qu'une ROM, par exemple un CD ROM ou une ROM de circuit microélectronique, ou encore un moyen d'enregistrement magnétique, par exemple un support mobile, un disque dur ou un SSD.
D'autre part, le support d'enregistrement peut être un support transmissible tel qu'un signal électrique ou optique, qui peut être acheminé via un câble électrique ou optique, par radio ou par d'autres moyens, de sorte que le programme d’ordinateur qu’il contient est exécutable à distance. Le programme selon l'invention peut être en particulier téléchargé sur un réseau, par exemple un réseau de type Internet. Alternativement, le support d'enregistrement peut être un circuit intégré dans lequel le programme est incorporé, le circuit étant adapté pour exécuter ou pour être utilisé dans l'exécution du procédé de contrôle d’une transaction sans contact précité.
Selon un exemple de réalisation, la présente technique est mise en œuvre au moyen de composants logiciels et/ou matériels. Dans cette optique, le terme "module" peut correspondre dans ce document aussi bien à un composant logiciel, qu'à un composant matériel ou à un ensemble de composants matériels et logiciels.
Brève description des dessins
D'autres caractéristiques et avantages apparaîtront à la lecture de modes de réalisation particuliers de l'invention, donnés à titre d’exemples illustratifs et non limitatifs, et des dessins annexés, parmi lesquels :
La figure 1A représente un système de contrôle de transaction sans contact selon un premier mode de réalisation de l'invention,
La figure 1 B représente un système de contrôle de transaction sans contact selon un deuxième mode de réalisation de l'invention,
La figure 1C représente un système de de contrôle de transaction sans contact selon un troisième mode de réalisation de l'invention,
La figure 2 représente un objet communicant dans un mode de réalisation de l’invention,
La figure 3 représente les principales actions mises en œuvre dans le procédé de contrôle de transaction sans contact, selon un mode de réalisation particulier de l’invention,
La figure 4 représente un mode de réalisation d’une étape de détermination de la légitimité de la transaction ou non, mise en œuvre dans le procédé de contrôle de transaction sans contact selon l’invention.
Description détaillée d’un mode de réalisation de l’invention La figure 1A représente un système de contrôle d’une transaction sans contact selon un premier mode de réalisation de l'invention.
Un tel système comprend :
- un objet connecté ou communicant OC1 associé à un utilisateur UT,
- un dispositif DFi de fourniture d’un bien ou d’un service à l’utilisateur UT,
- un dispositif de communication DCi configuré pour communiquer avec l’objet OC1 pour la mise en œuvre d’une transaction sans contact relative à la fourniture d’un bien ou d’un service par le dispositif DFi.
On appelle objet communicant ou connecté tout objet configuré pour capter des données et pour communiquer avec d’autres objets ou avec des infrastructures dédiées selon la technologie loT (« Internet of Things » en anglais).
Conformément à l’invention, le procédé de contrôle de transaction sans contact est mis en œuvre au niveau de l’objet communicant OC1, de façon complètement autonome, comme cela sera décrit plus loin dans la description.
Dans l’exemple de la figure 1A, l’objet communicant OC1 est par exemple un véhicule, ici une voiture électrique connectée. A ce titre, la voiture OC1 est dotée nativement d’une pluralité de capteurs/détecteurs tels que par exemple une caméra, un capteur qui détecte le niveau de la charge de la batterie, un capteur de vitesse, un dispositif de géolocalisation de type GPS (« Global Positioning System » en anglais), un capteur d’empreinte digitale, etc...
Selon l’invention, la voiture connectée OC1 est dotée :
- d'un module MCO de communication radio sans fil courte ou moyenne portée, tel que par exemple Bluetooth, LTE, WiFi, DSRC, C-V2X, etc.,
- d’un module MT de transaction sans contact, par exemple une carte eSIM
(« Embedded Subscriber Identification Module » en anglais) installée dans la voiture, un porte-monnaie électronique (« e-wallet » en anglais) embarqué dans l’infrastructure informatique de la voiture et dans lequel a/ont été préchargée(s) une ou plusieurs unités de monnaie numérique (« tokens » en anglais) de carte bancaire, etc.
Dans l’exemple de la figure 1 A, le dispositif DFi de fourniture de bien ou de service est une borne de recharge parmi d’autres disponibles d’une station de recharge pour véhicules électriques. Dans l’exemple représenté, la borne de recharge porte le numéro 3. Dans l’exemple de la figure 1A, le dispositif de communication DCi est un serveur de paiement ou un TPE qui peut être compris dans la borne de recharge DFi ou encore dissocié de celle-ci.
Dans ce contexte de transaction sans contact de l’invention, la voiture électrique connecté OC1 commence par s’appairer avec la borne de recharge DFi, via son module de communication MCO, afin d’établir un canal de communication sans contact sécurisé pour mettre en œuvre la transaction sans contact, ici un paiement correspondant à la recharge effectuée. Cette transaction sans contact est contrôlée par la voiture connectée OC1, à partir du moment où l’utilisateur UT a relié le connecteur de charge de la borne DFi à la batterie de la voiture connectée OC1. Si la voiture connectée OC1 estime que la transaction sans contact est valide/légitime, la transaction sans contact débute, puis prend fin une fois que l’utilisateur a remis en place le connecteur de charge sur la borne.
Bien entendu, cet exemple n‘a rien d’exhaustif. En particulier, le dispositif DFi de fourniture de bien ou de service varie en fonction du contexte d’utilisation de la voiture connectée OC1. A cet effet, le dispositif de fourniture de bien ou de service DFi pourrait être alternativement :
- une pompe à essence,
- un guichet de vente de nourriture à emporter,
- un parcmètre,
- une barrière de péage,
- etc.
La figure 1 B représente un système de contrôle d’une transaction sans contact selon un deuxième mode de réalisation de l'invention. Ce deuxième mode de réalisation utilise des éléments communs à ceux de la figure 1A. Pour cette raison, ces éléments sont désignés avec les mêmes références.
Un tel système comprend :
- un objet connecté ou communicant OC2 associé à un utilisateur UT,
- un dispositif DF2 de fourniture d’un bien ou d’un service à l’utilisateur UT,
- un dispositif de communication DC2 configuré pour communiquer avec l’objet OC2 pour la mise en œuvre d’une transaction relative à la fourniture d’un bien ou d’un service par le dispositif DF2. Conformément à l’invention, le procédé de contrôle de transaction sans contact est mis en œuvre au niveau de l’objet communicant OC2, de façon complètement autonome comme cela sera décrit plus loin dans la description.
Dans l’exemple de la figure 1B, l’objet communicant OC2 est un objet porté par l’utilisateur UT, tel que par exemple une montre connectée. Il pourrait bien sûr s’agir d’une tablette, d’un badge, d’un bracelet, de lunettes, etc.
A ce titre, la montre OC2 est dotée nativement d’une pluralité de capteurs/détecteurs tels que par exemple une caméra, un appareil photo, un accéléromètre, un dispositif de géolocalisation de type GPS, un capteur d’empreinte numérique, etc.
Selon l’invention, la montre connectée OC2 est dotée :
- du module de communication MCO précité,
- d’un module MT de transaction sans contact, par exemple un porte-monnaie électronique embarqué dans la montre connectée OC3, dans lequel a/ont été préchargé(s) un ou plusieurs tickets de transport numériques (« tokens » en anglais), un identifiant particulier IDGT associé au porte-monnaie électronique, etc.
Dans l’exemple de la figure 1 B, le dispositif DF2 de fourniture de bien ou de service est un portillon d’accès à un moyen de transport, tel que par exemple le métro, le train, le tramway, etc. Il peut être aussi une borne disposée dans un bus ou un tramway, à proximité d’un quai dans une gare, etc.
Dans l’exemple de la figure 1 B, le dispositif de communication DC2 est un serveur de contrôle d’accès qui peut être compris dans le portillon DF2 ou encore dissocié de celui-ci.
Dans ce contexte de transaction sans contact de l’invention, la montre connectée OC2 commence par s’appairer avec le portillon DF2, via son module de communication MCO, afin d’établir un canal de communication sans contact sécurisé pour mettre en œuvre la transaction sans contact, ici un accès au moyen de transport. Cette transaction sans contact est contrôlée par la montre connectée OC2, à partir du moment où l’utilisateur UT est à quelques centimètres du portillon DF2. Si la montre connectée OC2 estime que la transaction sans contact est valide/légitime, la transaction sans contact débute avec le serveur DC2, ce qui entraîne l’ouverture du portillon DF2 pour laisser passer l’utilisateur UT, puis prend fin une fois que l’utilisateur UT a passé ce portillon. Un tel contrôle d’accès met par exemple en œuvre une décrémentation d’un ou de plusieurs tickets de transport numériques préchargé(s) dans le porte-monnaie électronique de la montre connectée OC2. Selon un autre exemple, un tel contrôle d’accès met par exemple en œuvre une vérification de l’identifiant particulier IDGT associé au porte-monnaie électronique de la montre connectée OC2dans un but de valider automatiquement l’accès au moyen de transport sur la base de cet identifiant particulier.
La figure 1C représente un système de contrôle d’une transaction sans contact selon un troisième mode de réalisation de l'invention. Ce troisième mode de réalisation utilise des éléments communs à ceux des figures 1 A et 1 B. Pour cette raison, ces éléments sont désignés avec les mêmes références.
Un tel système comprend :
- un objet connecté ou communicant OC3 associé à un utilisateur UT,
- un dispositif DF3 de fourniture d’un bien ou d’un service à l’utilisateur UT,
- un dispositif de communication DC3 configuré pour communiquer avec l’objet OC3 pour la mise en œuvre d’une transaction relative à la fourniture d’un bien ou d’un service par le dispositif DF3.
Conformément à l’invention, le procédé de contrôle de transaction sans contact est mis en œuvre au niveau de l’objet communicant OC3, de façon complètement autonome, comme cela sera décrit plus loin dans la description.
Dans l’exemple de la figure 1C, l’objet communicant OC3 est un objet porté par l’utilisateur UT, tel que par exemple un smartphone. Il pourrait bien sûr s’agir en variante d’une tablette, d’un badge, d’un bracelet, etc.
A ce titre, le smartphone OC3 est doté nativement d’une pluralité de capteurs/détecteurs tels que par exemple une caméra, un appareil photo, un accéléromètre, un dispositif de géolocalisation de type GPS, un capteur biométrique, etc.
Selon l’invention, le smartphone OC3 est doté :
- du module de communication MCO précité,
- d’un module MT de transaction sans contact, par exemple une mémoire stockant un identifiant de retrait d’une commande d’un bien ou un service qu’a effectuée au préalable l’utilisateur UT.
Dans l’exemple de la figure 1C, le dispositif DF3 de fourniture du bien ou du service commandé par l’utilisateur UT est une boîte de retrait automatique de colis. Dans l’exemple représenté, cette boîte comprend sept casiers référencés A à G. Dans l’exemple de la figure 1C, le dispositif de communication DC3 est un serveur de commande d’ouverture/fermeture des casiers. Le serveur DC3 peut être compris dans la boîte de retrait DF3 ou encore dissocié de celle-ci.
Dans ce contexte de transaction sans contact de l’invention, le smartphone OC3 commence par s’appairer avec la boîte de retrait DF3, via son module de communication MCO, afin d’établir un canal de communication sans contact sécurisé pour mettre en œuvre la transaction sans contact, ici un retrait d’un colis COL. Cette transaction sans contact est contrôlée par le smartphone OC3, à partir du moment où l’utilisateur UT est à quelques centimètres de la boîte de retrait DF3. Si le smartphone OC3 estime que la transaction sans contact avec le serveur DC3 est valide/légitime, la transaction sans contact débute avec le serveur DC3, ce qui entraîne l’ouverture d’un des casiers qui contient le colis COL, le casier E dans l’exemple représenté. La transaction sans contact prend fin une fois que l’utilisateur UT a retiré le colis COL du casier E et que ce dernier a été refermé. Un tel contrôle d’accès met par exemple en œuvre une vérification que l’identifiant de retrait stocké dans la mémoire du smartphone OC3 correspond bien à l’identifiant du colis COL en attente de retrait dans le casier E, dans le but de provoquer l’ouverture automatique de ce casier, sans que l’utilisateur UT n’ait besoin de manipuler son smartphone OC3.
Description d’un mode de réalisation de l’objet communicant OC La figure 2 présente la structure simplifiée de l’objet communicant OC, tel que par exemple l’objet OC1, OC2OU OC3 des figures 1A à 1C, lequel objet communicant est adapté pour mettre en œuvre le procédé de contrôle d’une transaction sans contact qui va être décrit ci-dessous.
Comme déjà expliqué plus haut, un tel objet communicant comprend classiquement :
- un module de communication MCO adapté pour communiquer, via un réseau RCMP de données sans fil courte ou moyenne portée, tel que par exemple Bluetooth, NFC, LTE, WiFi, DSRC, C-V2X, etc.,
- un ou plusieurs capteurs/détecteurs CAP1, CAP2, ..., CAPs (S>1).
L’objet communicant OC comprend en outre selon l’invention :
- un module de communication MCO’ adapté pour communiquer via un réseau RLP de données longue portée (3G, 4G, 5G, etc.),
- un module REC de réception de messages de diffusion MSG, par exemple de type beacon ou de type V2X (« Vehicle-to-Everything » en anglais) quand l’objet communicant OC est plus particulièrement un véhicule, ces messages de diffusion étant reçus en provenance de différents dispositifs et/ou infrastructures que l’objet communicant rencontre sur son trajet,
- un module de transaction MT tel que par exemple une carte SIM, eSIM, e-wallet, une mémoire dédiée à la transaction sans contact, etc.,
- un module d’analyse ANA configuré pour analyser des données de transaction DAT1 contenues dans les requêtes de transaction que l’objet communicant OC reçoit en provenance d’un dispositif de communication DC, tel que par exemple le dispositif de communication DCi, DC20U DC3 des figures 1A à 1C,
- un module DET configuré pour déterminer au moins une donnée de transaction complémentaire DAT2 en plus de celle(s) déjà contenue(s) dans les requêtes de transaction reçues,
- un module d’accès ACC à une mémoire MEM1 qui contient des données/informations DCU de contexte d’utilisation de l’objet communicant OC, dont des exemples seront donnés plus loin dans la description.
Sur la figure 2, la mémoire MEM1 n’est pas contenue dans l’objet communicant OC afin de préserver les ressources mémoire de celui-ci. A cet effet, la mémoire MEM1 est déportée dans un réseau de communication, un nuage (« cloud » en anglais), etc. et est rendue accessible par l’objet communicant OC, au moyen du module ACC dédié à cet effet. En variante, la mémoire MEM1 ou une partie de celle-ci pourrait être intégrée à l’objet communicant OC.
Bien que sur la figure 2, le module DET de détermination d’au moins une donnée de transaction complémentaire DAT2 soit intégré à l’objet communicant OC, le module DET pourrait être dissocié de cet objet pour préserver les ressources en calculs de ce dernier.
Selon un mode particulier de réalisation de l'invention, les actions exécutées par l’objet communicant OC, dans le cadre de la mise en œuvre du procédé de contrôle d’une transaction sans contact conformément à la présente invention, sont mises en œuvre par des instructions d’un programme d'ordinateur PG. Pour cela, l’objet communicant OC a l'architecture classique d'un ordinateur et comprend notamment une mémoire MEM2, une unité de traitement UTR, équipée par exemple d'un processeur PROC, et pilotée par le programme d'ordinateur PG stocké en mémoire MEM2. Le programme d'ordinateur PG comprend des instructions pour mettre en œuvre les actions exécutées par l’objet communicant OC, lorsque le programme est exécuté par le processeur PROC, selon l'un quelconque des modes particuliers de réalisation de l'invention.
A l'initialisation, les instructions de code du programme d'ordinateur PG sont par exemple chargées dans une mémoire RAM (non représentée) avant d'être exécutées par le processeur PROC. Le processeur PROC de l'unité de traitement UTR met notamment en œuvre les actions de recueil des données issues du et/ou des capteurs CAPi, CAP2,..., CAPs, les actions de réception du et/ou des messages MSG, les actions de réception de requêtes de transaction, les actions d’analyse de ces requêtes, les actions de détermination d’au moins une donnée de transaction complémentaire, les actions d’envoi ou de non envoi d’une réponse à ces requêtes de transaction.
Description d’un mode de réalisation d’un procédé de contrôle de transaction sans contact
On décrit maintenant, en relation avec la figure 3, le déroulement d’un procédé de contrôle d’une transaction sans contact exécuté par un objet communicant OC, tel que par exemple l’objet OC1, OC2OU OC3 des figures 1A à 1C, selon un mode de réalisation de l’invention. Une telle transaction sans contact est établie lors d’une communication sans contact entre l’objet communicant OC et le dispositif de communication DC précité, tel que par exemple le dispositif de communication DC1, DC20U DC3 des figures 1A à 1C. L’objet de la transaction sans contact est par exemple un bien ou un service fourni par un dispositif DF de fourniture de bien ou de service à l’utilisateur UT de l’objet communicant OC, tel que par exemple le dispositif de fourniture de bien ou de service DF1, DF20U DF3 des figures 1A à 1C. Conformément à l’invention, l’objet communicant OC est configuré de telle manière qu’il exécute de manière autonome les différentes actions qui vont être décrites ci- dessous pour contrôler une transaction sans contact avec le dispositif de communication DC, comme si c’était l’utilisateur UT lui-même qui mettait en œuvre un tel contrôle, à savoir vérifier la légitimité de la transaction, comme l’utilisateur le fait habituellement en vérifiant par exemple que l’objet de la transaction est celui qu’il souhaite, que le prix de l’objet, quand celui-ci est payant, est bien le bon, le lieu de la transaction, etc..., et valider la transaction ou non en fonction de cette vérification. En préalable au déroulement du procédé de contrôle de transaction sans contact décrit ci-dessous, on considère que l’utilisateur UT et son objet communicant OC se sont rapprochés du dispositif DF de fourniture de bien ou de service et que l’établissement d’un canal de communication de façon sécurisée a été réalisé pour mettre en œuvre la transaction sans contact entre l’objet communicant OC et le dispositif de communication DC. L’établissement d’un tel canal de communication ou appairage est classique et ne sera pas décrit plus avant. Dans un mode de réalisation particulier, l’établissement d’un tel canal de communication est exécuté de manière autonome par l’objet communicant OC comme décrit dans le document FR2106702 incorporé à titre de référence à la présente description.
Le procédé de contrôle d’une transaction sans contact se déroule alors comme suit : En S1, l’objet communicant OC reçoit, en provenance du dispositif de communication DC, une requête REO_TR contenant des données DAT1 relatives à une transaction. Une telle requête peut être reçue par le module de communication MCO ou MCO’ de la figure 2.
Dans le contexte d’utilisation de la figure 1 A, la requête REO_TR est par exemple une requête de paiement. Il peut s’agir d’une requête par exemple de type SEPA RTP (« Single Euro Payments Area Request to Pay » en anglais), de type Paypal : https://developer.pavpal.com/docs/inteqration/pavpal-plus/mexico-brazii/create-a- pavment-request/. etc., pour laquelle les données DAT1 correspondent par exemple :
- au montant de la transaction, ici le prix de la recharge en électricité,
- au type de bien ou de service concerné par la transaction, ici « recharge batterie »,
- à un identifiant du dispositif DC de fourniture de bien ou de service, ici borne de recharge n°3,
- à la localisation de la transaction, ici les données de géolocalisation de la station de recharge,
- à une quantité ou un volume en lien avec le bien ou le service faisant l’objet de la transaction, ici, la quantité d’électricité consommée pour recharger la batterie de la voiture électrique connectée OCi.
Dans le contexte d’utilisation de la figure 1 B, la requête REO_TR est par exemple une requête d’identification de l’accès au moyen de transport. Une telle requête est par exemple de type Internet. Elle contient des données DAT1 correspondant par exemple :
- à un identifiant du portillon DF2 : par exemple cet identifiant peut commencer par la lettre « M » pour indiquer qu’il s’agit du portillon d’un métro, par la lettre « B » pour indiquer qu’il s’agit de la borne d’accès d’un bus, etc.,
- la catégorie du moyen de transport correspondant au dispositif DF2 : bus, métro, train, tramway, etc.,
- le prix d’un ou de plusieurs tickets de transport,
- l’identifiant particulier IDGT d’accès gratuit aux transports qui est associé au module de transaction MT de la montre connectée OC2,
- etc.
Dans le contexte d’utilisation de la figure 1C, la requête REQ_TR est par exemple une requête d’accès à la boîte DF3 de retrait de colis. Une telle requête est par exemple de type Internet. Elle contient des données DAT1 correspondant par exemple :
- à un identifiant de retrait, tel que par exemple un code de livraison, la lettre « G » du casier qui contient le colis COL,...
- à un identifiant ou un nom de l’enseigne de la boutique d’où provient le colis COL,
- au prix de la commande,
- à la quantité d’articles livrés,
- au lieu où se situe la boîte de retrait de colis,
- etc.
Le procédé de contrôle de la transaction sans contact se poursuit en S2, où l’objet communicant OC extrait les données DAT1 de la requête REQ_TR reçue.
En S3, le module d’analyse ANA de la figure 2 met en œuvre une analyse de ces données DAT1. A cet effet, les données DAT1 sont comparées à des données de contexte d’utilisation DCU de l’objet communicant OC.
Les données/informations de contexte d’utilisation DCU sont des données/informations collectées par l’objet communicant OC lors de son déplacement en direction du dispositif DF de fourniture d’un bien ou d’un service, mais aussi préalablement à ce déplacement.
Dans un mode de réalisation, les données/informations de contexte d’utilisation DCU : - sont des données/informations INF1 représentatives d’un environnement dans lequel se trouve l’objet communicant OC : il peut s’agir par exemple d’une ou plusieurs informations véhiculées dans un message MSG reçu par le module de réception REC de la figure 2, en provenance du dispositif de communication DC ou d’un dispositif d’émission de message situé dans l’environnement de l’objet communicant OC, ou encore d’une ou de plusieurs donnée issues d’au moins un des capteurs CAPi à CAPs de la figure 2 ; et/ou
- contiennent au moins une donnée INF2 de fonctionnement de l’objet communicant OC, telle que par exemple un paramètre de fonctionnement courant relevé par l’objet communicant OC, et/ou
- contiennent au moins un élément INF3 d’un historique des transactions déjà effectuées par l’objet communicant OC, et/ou,
- contiennent un ou des éléments INF4 d’une liste des types de fraudes connues, et/ou
- contiennent un ou des éléments INF5 d’une liste noire de fraudeurs LNF,
- etc.
Au cours ou à l’issue de cette comparaison S3, une ou plusieurs données DAT2 de transaction complémentaires sont déterminées ou identifiées en S4 à l’aide du module DET de la figure 2. Une telle détermination peut être réalisée en local par l’objet communicant OC ou de manière déportée.
Dans le contexte d’utilisation de la figure 1A, les données/informations INF1 représentatives d’un environnement dans lequel se trouve la voiture électrique connectée OCi sont reçues par la voiture OCi, via le module de réception REC de la figure 2. Elles sont véhiculées par exemple dans un message MSG diffusé par exemple par le serveur DCi ou par la borne de recherche DFi, selon le contexte de communication envisagé. Le message MSG peut également être diffusé par toute infrastructure adaptée telle que la station de recharge qui gère l’ensemble des bornes de recharge, un restaurant, un centre routier, une collectivité territoriale, etc... Un tel message MSG est par exemple de type beacon, V2X, UWB (« Ultra wideband » en anglais), WiFi multicast, ou encore LiFi (« Light Fidelity » en anglais), etc...
Typiquement, cette information INF1 désigne par exemple : - le nom de la station de recharge où se trouve la borne de recharge DFi, le numéro de cette borne, etc...
- le type de carburant, par exemple « électricité », associé à la borne de recharge DFi,
- etc.
Les données/informations INF1 peuvent également correspondre à une interprétation faite par la voiture électrique connectée OC1 des données issues de ses différents capteurs CAPi à CAPs, typiquement le niveau de la recharge en électricité de sa batterie, les dimensions ou le type de la voiture OC1, le ou les occupants de la voiture OC1 (biométrie), etc. Les données/informations INF1 peuvent également correspondre par exemple à une enseigne ou un logo de la station de recharge qui ont été reconnus après analyse d’une image ou d’une vidéo capturée par un des capteurs CAPi, CAP2, ..., CAPs de la voiture OC1, typiquement un appareil photo ou une caméra. Il peut s’agir également des métadonnées associées à cette image, telles que par exemple la position géographique de la station de recharge, la date et/ou l’heure de capture de l’image ou de la vidéo. Les données/informations INF1 correspondent également dans ce contexte d’utilisation aux coordonnées géographiques (cartésiennes, polaires, sphériques, etc.) de la voiture OC1 qui sont mesurées par un des capteurs CAPi, CAP2, ..., CAPs de la voiture OC1, typiquement un dispositif GPS.
Dans le contexte d’utilisation de la figure 1A, les données/informations INF2 de fonctionnement de la voiture connectée OC1 correspondent aux paramètres liés à l’infrastructure de la voiture OC1 et remontés via un multiplex ou un bus de données installé dans la voiture. Il s’agit par exemple de la vitesse courante, de l’ouverture/fermeture de la trappe à carburant/recharge électrique, de la diminution/élévation du niveau de carburant/de la batterie, de l’ouverture/fermeture d’une portière, etc...
Dans le contexte d’utilisation de la figure 1A, l’élément INF3 d’un historique des transactions déjà effectuées par la voiture OC1 est typiquement une information relative à des paiements précédemment effectués par la voiture OC1.
Dans le contexte d’utilisation de la figure 1A, les données complémentaires de transaction DAT2 sont par exemple l’identité de la personne qui conduit la voiture OC1, le kilométrage effectué, la localisation de la voiture OC1 au moment du paiement. Dans le cas où la voiture connectée OC1 est partagée par plusieurs personnes ou plusieurs sociétés et contient de ce fait plusieurs modules de transaction MT, ici modules de paiement, les données complémentaires DAT2 correspondent à un identifiant du module de paiement associé à la personne identifiée au préalable par un capteur biométrique de la voiture OC1. Ainsi, l’étape de détermination S4 permet avantageusement de sélectionner automatiquement le module de transaction MT associé à l’utilisateur UT effectif de l’objet communicant OC lorsque plusieurs utilisateurs sont potentiellement aptes à utiliser cet objet.
Dans le contexte d’utilisation de la figure 1B, les données/informations INF1 représentatives d’un environnement dans lequel se trouve la montre connectée OC2 sont reçues via le module de réception REC de la figure 2. Elles sont véhiculées par exemple dans un message MSG diffusé par exemple par le serveur DC2 ou par le portillon DF2 selon le contexte de communication envisagé. Le message MSG peut également être diffusé par un émetteur placé en gare ou en station, dans le métro, dans le bus, etc. Typiquement les données/informations INF1 désignent par exemple le nom d’une station ou d’un arrêt de bus/tramway, l’identifiant d’une ligne de transport, des informations de géolocalisation de la montre connectée OC2 dans la gare ou la station, le type de moyen de transport emprunté, par exemple « métro », associé au portillon DF2, etc. Un tel message MSG est par exemple de type beacon, UWB (« Ultra wideband » en anglais), WiFi multicast, ou encore LiFi (« Light Fidelity » en anglais), etc...
Les données/informations INF1 peuvent également correspondre à une interprétation faite par la montre connectée OC2 des données issues de ses différents capteurs CAP1 à CAPs. Elles correspondent par exemple au nom de la station ou de la gare, à un identifiant de la ligne de transport empruntée par l’utilisateur UT, etc. qui ont été reconnus après analyse d’une image ou d’une vidéo capturée par un des capteurs CAP1, CAP2, ..., CAPs de la montre OC2, typiquement un appareil photo ou une caméra. Il peut s’agir également des métadonnées associées à cette image, telles que la position géographique de la station ou de la gare, la date et/ou l’heure de capture de l’image ou de la vidéo. Les données/informations INF1 peuvent également correspondre, dans ce contexte d’utilisation :
- à une vitesse mesurée par un des capteurs CAP1, CAP2, ..., CAPs de la montre OC2, typiquement un accéléromètre, - aux coordonnées géographiques (cartésiennes, polaires, sphériques, etc.) de la montre OC2 qui sont mesurées par un des capteurs CAP1, CAP2, ..., CAPs de la montre OC2, typiquement un dispositif GPS.
Dans le contexte d’utilisation de la figure 1 B, les données/informations INF2 de fonctionnement de la montre connectée OC2 correspondent par exemple à la date et l’heure courantes.
Dans le contexte d’utilisation de la figure 1 B, l’élément INF3 d’un historique des transactions déjà effectuées par la montre connectée OC2 est typiquement une information relative à des trajets en transport en commun précédemment effectués par l’utilisateur UT.
Dans le contexte d’utilisation de la figure 1 B, les données complémentaires de transaction DAT2 sont par exemple l’identité de l’utilisateur UT qui porte la montre connectée OC2, la localisation de la montre connectée OC2 au moment du passage du portillon DF2 par l’utilisateur UT, le nombre de tickets numériques restants, etc. Dans le cas où la montre connectée OC2 est partagée par différents utilisateurs et contient de ce fait plusieurs modules de transaction, ici des cartes de transport numériques intégrées à la montre OC2, les données complémentaires DAT2 correspondent à un identifiant de la carte de transport associée à la personne identifiée au préalable, par exemple à l’aide d’un capteur biométrique de la montre connectée OC2.
Dans le contexte d’utilisation de la figure 1C, les données/informations INF1 représentatives d’un environnement dans lequel se trouve le smartphone OC3 sont reçues via le module de réception REC de la figure 2. Elles sont véhiculées par exemple dans un message MSG diffusé par exemple par le serveur DC3 ou par la boîte de retrait DF3 selon le contexte de communication envisagé. Le message MSG peut également être diffusé par un émetteur placé à proximité de la boîte de retrait DF3. Typiquement les données/informations INF1 désignent par exemple le nom ou un identifiant de la boîte de retrait DF3, un lieu dans lequel se trouve la boîte de retrait DF3, la localisation du smartphone OC3 par rapport à la boîte de retrait DF3, etc. Un tel message MSG est par exemple de type beacon, « notification push », UWB (« Ultra wideband » en anglais), WiFi multicast, ou encore LiFi (« Light Fidelity » en anglais), etc... Les données/informations INF1 peuvent également correspondre à une interprétation faite par le smartphone OC3 des données issues de ses différents capteurs CAP1 à CAPs. Elles correspondent par exemple au nom ou à un identifiant de la boîte de retrait DF3 qui ont été identifiés après analyse d’une image ou d’une vidéo capturée par un des capteurs CAP1, CAP2, CAPs du smartphone OC3, typiquement un appareil photo ou une caméra. Il peut s’agir également des métadonnées associées à cette image, telles que la position géographique de la boîte de retrait DF3, la date et/ou l’heure de capture de l’image ou de la vidéo. Les données/informations INF1 peuvent également correspondre, dans ce contexte d’utilisation :
- à une vitesse mesurée par un des capteurs CAP1, CAP2, ..., CAPs du smartphone OC3, typiquement un accéléromètre,
- aux coordonnées géographiques (cartésiennes, polaires, sphériques, etc.) du smartphone OC3 qui sont mesurées par un des capteurs CAP1, CAP2, ..., CAPs de la montre OC3, typiquement un dispositif GPS.
Dans le contexte d’utilisation de la figure 1 B, les données/informations INF2 de fonctionnement du smartphone OC3 correspondent par exemple à la date et l’heure courantes, au mode de fonctionnement courant du smartphone OC3 (allumé, éteint, mode avion, en veille, etc.).
Dans le contexte d’utilisation de la figure 1C, l’élément INF3 d’un historique des transactions déjà effectuées par le smartphone OC3 est typiquement une information relative aux différentes commandes de bien ou de service qui ont été effectuées précédemment par l’utilisateur UT avec le smartphone OC3.
Dans le contexte d’utilisation de la figure 1C, les données complémentaires de transaction DAT2 sont par exemple l’identité de l’utilisateur UT qui utilise le smartphone OC3, des données d’un profil de cet utilisateur UT (historique de navigation, répertoire, etc.) chargées dans le smartphone OC3 lors de l’allumage du smartphone OC3 par l’utilisateur UT, la localisation du smartphone OC3 au moment où l’utilisateur UT s’est approché de la boîte de retrait DF3, un logo de l’enseigne de livraison du colis COL, l’opérateur de télécommunications en lien avec la carte eSIM MT, etc. Dans le cas où le smartphone OC3 est partagé par différents utilisateurs et contient de ce fait plusieurs modules de transaction MT intégrés au smartphone OC3, ici carte eSIM, e-wallet, etc., les données complémentaires DAT2 correspondent à un identifiant de la carte eSIM, du e-wallet ou autre associé(e) à la personne identifiée au préalable, par exemple à l’aide d’un capteur biométrique du smartphone OCs.
Dans le cas où une concordance existe entre les données DAT1 et les données de contexte d’utilisation DCU de l’objet communicant OC (O sur la figure 3), l’objet communicant OC identifie la transaction comme valide/légitime. A cet effet, il active en S5 l’envoi au dispositif de communication DC, via son module de communication MCO ou MCO’, d’une réponse REP_TR_AUT à la requête REO_TR, ladite réponse REP_TR_AUT autorisant la transaction entre l’objet communicant OC et le dispositif de communication DC.
Dans un mode de réalisation particulier, la réponse REP_TR_AUT peut être enrichie par au moins une donnée DAT2 qui a été déterminée en S4. Ainsi la et/ou les donnée(s) DAT2 pourra/pourront être transmise(s) par le dispositif de communication DC aussi bien au gestionnaire de la transaction qu’au gestionnaire de l’objet communicant (ex : gestionnaire d’une flotte de véhicules, banque, etc., dans le cas où l’objet communicant OC est une voiture connectée OCi, régie de transport en commun dans le cas où l’objet communicant OC est une montre connectée OC2, opérateur de télécommunications ou enseigne de livraison, dans le cas où l’objet communicant OC est un smartphone OC3), ou encore au fournisseur du bien ou du service faisant l’objet de la transaction (station-service, site Internet marchand, etc.). Cette/ces donnée(s) DAT2 pourra/pourront ainsi être avantageusement exploitée(s) à des fins de traitement/archivage/traçage des transactions qui ont été effectuées par un utilisateur UT de l’objet communicant OC donné, à un instant donné.
Dans le cas où une concordance n’existe pas entre les données DAT1 et les données de contexte d’utilisation DCU de l’objet communicant OC (N sur la figure 3), l’objet communicant OC identifie la transaction comme invalide/illégitime. A cet effet, il active en S6 l’envoi au dispositif de communication DC, via son module de communication MCO ou MCO’, d’une réponse REP_TR_REF à la requête REO_TR, ladite réponse REP_TR_REF désignant un refus de la transaction entre l’objet communicant OC et le dispositif de communication DC. A titre d’alternative, l’objet communicant OC n’envoie aucune réponse à la requête REO_TR et le procédé de transaction prend fin au bout d’un délai fixé au préalable, dont la durée dépend de l’implémentation effectuée. Les étapes du procédé de contrôle d’une transaction sans contact qui viennent d’être décrites ci-dessus permettent avantageusement à tout objet connecté de vérifier si une transaction (paiement, accès, retrait de commande, etc.) avec un dispositif de communication (serveur de paiement, serveur ou portillon de contrôle d’accès, commande d’ouverture/fermeture d’une boîte de retrait de colis, d’une consigne automatique, etc...) est valide/légitime ou non, et ceci de façon complètement autonome et sécurisée.
On va maintenant décrire, en référence à la figure 4, un mode de réalisation de la comparaison mise en œuvre au cours de l’étape S3 de la figure 3 pour caractériser la concordance ou la non concordance entre les données DAT1 et les données de contexte d’utilisation DCU de l’objet communicant OC. Une telle comparaison est mise en œuvre à l’aide d’un outil de traitement informatique, de type intelligence artificielle.
La comparaison S3 comprend à cet effet une sous-étape S30 au cours de laquelle des informations de contexte d’utilisation de référence ICURef sont combinées.
Ces informations de contexte d’utilisation de référence ICURef peuvent prendre différentes formes. Il peut s’agir par exemple :
- d’informations caractérisant une situation de transaction sans contact d’un objet communicant comme étant valide/légitime et qui a été apprise au préalable, par exemple à l’aide d’un réseau de neurones, et/ou
- de règles écrites à priori selon lesquelles les données DAT1 et/ou les données de contexte d’utilisation DCU vont être combinées d’une manière particulière, à l’aide par exemple d’un système expert, et/ou
- d’une mise en commun de situations de transaction sans contact détectées au préalable pour ce qui concerne l’objet communicant OC, dans un contexte de transaction sans contact similaire ou identique (ex : cas où l’objet communicant OC est partagé par d’autres utilisateurs que l’utilisateur UT),
- etc.
A l’issue de la sous-étape S30 est obtenu un score de fiabilité présentant une valeur V.
En S31, les données DAT1 et les données de contexte d’utilisation DCU sont combinées.
En S32, un score de fiabilité SC est attribué au résultat de cette combinaison. En S33, le score SC est comparé à la valeur V obtenue en S30 qui est considérée en tant que valeur de référence.
Selon un mode de réalisation, 0<V<1. D’autres valeurs d’encadrement sont bien entendu possibles en fonction de l’implémentation du procédé de contrôle de transaction sans contact. Une convention établit par exemple que V=0,6 et qu’au- delà de cette valeur de référence V, l’objet communicant OC se trouve dans une situation de transaction valide/légitime.
Si SC>V (ou SC³V selon la convention établie) (O sur la figure 4), l’étape S5 d’activation de réception des requêtes d’appairage est déclenchée. Si SC£V (ou SC<V selon la convention établie) (N sur la figure 4), l’étape S6 de cessation du procédé de contrôle de transaction ou d’envoi d’une réponse REP_TR_REF refusant la transaction est mise en œuvre.
Dans un mode de réalisation particulier, selon la valeur du score SC, et en particulier si la valeur du score SC est très proche de la valeur de référence V, en dessous ou au-dessus, des données complémentaires peuvent être utilisées pour affiner la comparaison S3, telles que par exemple les données d’une base externe de fraudes connues (pour détecter une situation de transaction à risque), des données fournies par l’utilisateur UT s’il est présent au moment de la mise en œuvre de la comparaison S3, des données correspondant à la sélection d’un module de transaction MT spécifique (par exemple un module de transaction bénéficiant d’une assurance particulière, un module de transaction ayant un identifiant particulier IDGT qui autorise la gratuité des transports en commun, etc.).
Dans le contexte de transaction de la figure 1A, où l’objet communicant OC est une voiture électrique connectée OCi qui souhaite payer de manière autonome la recharge de sa batterie, les informations de contexte d’utilisation DCU déterminées sont par exemple :
- la vitesse de la voiture OCi est nulle,
- le moteur de la voiture OCi est coupé,
- le niveau de la batterie est faible,
- la catégorie « borne de recharge » est identifiée dans un message MSG.
Les données DAT1 sont par exemple la date et l’heure de la journée ainsi que le montant du paiement de la recharge. Ces informations sont comparées en S3 à une situation d’apprentissage qui a été modélisée avec des informations de contexte d’utilisation de référence ICllRef du même type ou d’un type similaire aux informations de contexte d’utilisation DCU et aux données DAT1 et qui a déjà été évaluée au préalable dans un contexte d’utilisation identique ou similaire :
- pour la voiture OC1, ou
- pour une autre voiture ou tout autre type de véhicule appartenant par exemple à une flotte de véhicules à laquelle appartient la voiture OC1.
Ainsi, si en S31 , toutes les informations de contexte d’utilisation DCU et les données de transaction DAT1 concordent avec les informations de contexte d’utilisation de référence ICURef, la valeur du score de fiabilité SC affecté en S32 sera supérieure à V ou supérieure ou égale à V.
Si par contre les informations de contexte d’utilisation DCU déterminées sont par exemple :
- la vitesse de la voiture OC1 est nulle,
- le moteur de la voiture OC1 est coupé,
- le niveau du réservoir d’essence est faible,
- la catégorie « parking » est identifiée dans un message MSG, et que les données DAT1 sont par exemple la date et l’heure de la journée, ainsi que le montant du paiement d’une baguette de pain, alors la valeur du score de fiabilité SC affecté en S32 sera inférieure à V ou inférieure ou égale à V pour caractériser le fait qu’il existe une ou plusieurs incohérences entre les informations de contexte d’utilisation DCU et les données DAT1.
Dans le contexte d’utilisation de la figure 1 B, où l’objet communicant OC est une montre connectée OC2, les informations de contexte d’utilisation DCU déterminées sont par exemple :
- le nom de l’arrêt de bus,
- des données de géolocalisation de la montre connectée par rapport à cet arrêt,
- l’identifiant de la ligne qui est indiqué par exemple sur le bus qui s’approche,
- une vitesse de la montre connectée qui décroit,
- etc. Les données DAT1 sont par exemple un identifiant d’un portillon qui commence par la lettre « B » pour indiquer que le moyen de transport emprunté est un bus,
- la catégorie du moyen de transport emprunté : « bus »,
- le prix de l’accès à ce bus.
Ces informations sont comparées à une situation d’apprentissage qui a été modélisée avec des informations de contexte d’utilisation de référence ICllRef du même type ou d’un type similaire aux informations de contexte d’utilisation DCU et qui a déjà été évaluée au préalable dans un contexte d’utilisation d’un moyen de transport identique ou similaire et représentatif des habitudes de déplacement en transport en commun de l’utilisateur UT ou d’un autre utilisateur qui partage la montre connectée OC2 avec l’utilisateur UT.
Ainsi, si en S31 , toutes les informations de contexte d’utilisation DCU et les données de transaction DAT1 concordent avec les informations de contexte d’utilisation de référence ICURef, la valeur du score de fiabilité SC affecté en S32 sera supérieure à V ou supérieure ou égale à V.
Si par contre les informations de contexte d’utilisation DCU déterminées sont par exemple :
- le nom d’une station de métro diffusé dans un message MSG,
- des données de géolocalisation de la montre connectée par rapport à un arrêt de bus,
- l’identifiant d’un bus qui ne passe pas par l’arrêt de bus correspondant aux données de géolocalisation,
- une vitesse de la montre connectée qui décroit,
- etc. et que les données DAT1 sont par exemple la date et l’heure de la journée, ainsi que le montant d’un billet de train, alors la valeur du score de fiabilité SC affecté en S32 sera inférieure à V ou inférieure ou égale à V pour caractériser le fait qu’il existe une ou plusieurs incohérences entre les informations de contexte d’utilisation DCU et les données DAT1.
Dans le contexte d’utilisation de la figure 1C où l’objet communicant OC est un smartphone OC3, les informations de contexte d’utilisation DCU déterminées sont par exemple : - le nom ou un identifiant de la boîte de retrait DF3 diffusé dans un message MSG,
- un logo de l’enseigne de livraison du colis COL,
- des données de l’historique de navigation du smartphone OC3 montrant que l’utilisateur UT a commandé un bien ou un service particulier à une date donnée.
Les données DAT1 sont par exemple la date et l’heure de la journée ainsi que le prix de la commande à retirer et un nombre d’articles correspondant à la commande qui est égal à 3.
Cette ou ces information(s) est/sont comparée(s) à une situation d’apprentissage qui a été modélisée avec une ou des informations de contexte d’utilisation de référence ICURef du même type ou d’un type similaire aux informations de contexte d’utilisation DCU et qui a déjà été évaluée au préalable dans un contexte d’utilisation identique ou similaire qui définit les lieux de retrait de colis où l’utilisateur UT se rend le plus souvent, une cinématique de commande connue de l’utilisateur UT ou d’un autre utilisateur partageant le smartphone OC3 avec l’utilisateur UT, etc.
Ainsi, si en S31 , toutes les informations de contexte d’utilisation DCU et les données DAT1 concordent avec les informations de contexte d’utilisation de référence ICURef, la valeur du score de fiabilité SC affecté en S32 sera supérieure à V ou supérieure ou égale à V.
Si par contre les informations de contexte d’utilisation DCU déterminées sont par exemple :
- le nom ou un identifiant de la boîte de retrait DF3 diffusé dans un message MSG,
- un logo d’une enseigne de livraison du colis COL qui n’est pas habilitée pour livrer dans la boîte de retrait DF3 correspondant à l’identifiant ou au nom précité,
- des données de l’historique de navigation du smartphone OC3 montrant que l’utilisateur UT a effectué la commande d’un unique article.
Les données DAT1 sont par exemple la date et l’heure de la journée ainsi que le prix de la commande à retirer qui correspond à un nombre d’articles égal à 3, alors la valeur du score de fiabilité SC affecté en S32 sera inférieure à V ou inférieure ou égale à V pour caractériser le fait qu’il existe une ou plusieurs incohérences entre les informations de contexte d’utilisation DCU et les données DAT1 .

Claims

REVENDICATIONS
[Revendication 1] Procédé de contrôle d’une transaction sans contact entre un objet communicant (OC) et un dispositif de communication (DC), au cours duquel l’objet communicant reçoit (S1) en provenance du dispositif de communication une requête contenant des données relatives à la transaction, le procédé étant caractérisé en ce que l’objet communicant exécute de manière autonome ce qui suit :
- extraire (S2) de ladite requête reçue des informations (DAT1) relatives à la transaction,
- comparer (S3) les informations extraites à des données de contexte d’utilisation (DCU) de l’objet communicant qui ont été déterminées par l’objet,
- activer (S5) l’envoi au dispositif de communication d’une réponse à la requête autorisant la transaction, quand une concordance existe entre les informations relatives à la transaction et les données de contexte d’utilisation.
[Revendication 2] Procédé de contrôle d’une transaction selon la revendication 1 , dans lequel en l’absence d’une concordance entre les informations relatives à la transaction et les données de contexte d’utilisation, l’objet communicant active (S6) l’envoi au dispositif de communication d’une réponse à la requête refusant la transaction, ou ne répond pas à la requête.
[Revendication 3] Procédé de contrôle d’une transaction selon la revendication 1 ou la revendication 2, dans lequel au cours de la comparaison des informations extraites avec lesdites données de contexte d’utilisation, au moins une donnée complémentaire (DAT2) relative à la transaction est déterminée (S4), ladite au moins une donnée complémentaire étant ajoutée dans la réponse à la requête autorisant la transaction.
[Revendication 4] Procédé de contrôle d’une transaction selon la revendication 3, dans lequel lorsque la transaction est un paiement et que l’objet communicant comprend au moins deux moyens de paiement associés respectivement à deux utilisateurs différents, la au moins une donnée complémentaire est un identifiant du moyen de paiement associé à l’utilisateur de l’objet au moment de la transaction.
[Revendication 5] Procédé de contrôle d’une transaction selon la revendication 1 ou la revendication 2, dans lequel la comparaison des informations extraites avec lesdites données de contexte d’utilisation comprend ce qui suit :
- générer (S32) un score de fiabilité de la comparaison, - comparer (S33) le score généré à un seuil (V),
- en fonction du résultat de la comparaison :
■ activer l’envoi au dispositif de communication d’une réponse à la requête autorisant la transaction,
■ activer l’envoi au dispositif de communication d’une réponse à la requête refusant la transaction ou ne pas répondre à la requête.
[Revendication 6] Procédé selon l’une quelconque des revendications 1 à 5, dans lequel les données de contexte d’utilisation de l’objet communicant sont représentatives d’un environnement dans lequel se trouve l’objet communicant ou contiennent au moins une donnée de fonctionnement de l’objet communicant.
[Revendication 7] Procédé de contrôle d’une transaction selon la revendication 6, dans lequel la au moins une donnée de fonctionnement de l’objet communicant est un paramètre de fonctionnement courant relevé par l’objet communicant ou un élément d’un historique des transactions effectuées par l’objet communicant.
[Revendication 8] Procédé de contrôle d’une transaction selon l’une quelconque des revendications 1 à 5, dans lequel les données de contexte d’utilisation représentatives d’un environnement dans lequel se trouve l’objet communicant sont contenues dans un message reçu par l’objet communicant en provenance du dispositif de communication ou d’un dispositif d’émission de message situé dans ledit environnement.
[Revendication 9] Procédé de contrôle d’une transaction selon l’une quelconque des revendications 1 à 5, dans lequel les données de contexte d’utilisation représentatives d’un environnement dans lequel se trouve l’objet communicant contiennent une donnée issue d’au moins un capteur appartenant à l’objet communicant.
[Revendication 10] Objet communicant (OC) ayant des capacités de contrôle d’une transaction sans contact avec un dispositif de communication, ledit objet communicant comprenant un processeur (PROC) qui est configuré pour recevoir en provenance du dispositif de communication une requête contenant des données relatives à la transaction, caractérisé en ce que le processeur de l’objet communicant exécute de manière autonome ce qui suit :
- extraire de la requête reçue des informations relatives à la transaction, - comparer les informations extraites à des données de contexte d’utilisation de l’objet communicant qui ont été déterminées par l’objet,
- activer l’envoi au dispositif de communication d’une réponse à la requête autorisant la transaction, quand une concordance existe entre les informations relatives à la transaction et les données de contexte d’utilisation.
[Revendication 11] Programme d'ordinateur comportant des instructions de code de programme pour la mise en œuvre du procédé de communication sans contact selon l’une quelconque des revendications 1 à 9, lorsqu'il est exécuté sur un ordinateur.
[Revendication 12] Support d'informations lisible par un ordinateur, et comportant des instructions d'un programme d'ordinateur selon la revendication 11. [Revendication 13] Système de contrôle d’une transaction sans contact, caractérisé en ce qu’il comprend :
- un objet communicant selon la revendication 10,
- un dispositif de communication sans contact qui est configuré pour envoyer à l’objet communicant une requête contenant des données relatives à la transaction.
EP22741348.1A 2021-07-06 2022-06-17 Procédé de controle d'une transaction sans contact et objet communicant correspondant Pending EP4367620A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR2107284A FR3125152A1 (fr) 2021-07-06 2021-07-06 Procédé de contrôle d’une transaction sans contact et objet communicant correspondant
PCT/FR2022/051183 WO2023281178A1 (fr) 2021-07-06 2022-06-17 Procédé de controle d'une transaction sans contact et objet communicant correspondant

Publications (1)

Publication Number Publication Date
EP4367620A1 true EP4367620A1 (fr) 2024-05-15

Family

ID=77180251

Family Applications (1)

Application Number Title Priority Date Filing Date
EP22741348.1A Pending EP4367620A1 (fr) 2021-07-06 2022-06-17 Procédé de controle d'une transaction sans contact et objet communicant correspondant

Country Status (4)

Country Link
US (1) US20240362614A1 (fr)
EP (1) EP4367620A1 (fr)
FR (1) FR3125152A1 (fr)
WO (1) WO2023281178A1 (fr)

Family Cites Families (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
FR2106702A5 (fr) 1970-09-21 1972-05-05 Inst Francais Du Petrole
US7665658B2 (en) * 2005-06-07 2010-02-23 First Data Corporation Dynamic aggregation of payment transactions
FR2892212A1 (fr) * 2005-10-17 2007-04-20 St Microelectronics Sa Lecteur nfc ayant un mode de fonctionnement passif a faible consommation electrique
US7747539B2 (en) * 2006-01-24 2010-06-29 First Data Corporation Contactless-chip-initiated transaction system
US20140095385A1 (en) * 2012-09-28 2014-04-03 Alex Ainslie Selecting merchants for automatic payments
US10810572B1 (en) * 2016-02-16 2020-10-20 State Farm Mutual Automobile Insurance Company Connected car as a payment device
US11113690B2 (en) * 2016-12-22 2021-09-07 Mastercard International Incorporated Systems and methods for processing data messages from a user vehicle
US10917402B2 (en) * 2017-06-29 2021-02-09 Motorola Mobility Llc Sending verification password responsive to mobile device proximity

Also Published As

Publication number Publication date
FR3125152A1 (fr) 2023-01-13
WO2023281178A1 (fr) 2023-01-12
US20240362614A1 (en) 2024-10-31

Similar Documents

Publication Publication Date Title
EP3113099B1 (fr) Conteneur de paiement, procédé de création, procédé de traitement, dispositifs et programmes correspondants
WO2018073104A1 (fr) Système d&#39;acheminement d&#39;objets par des individus d&#39;une communauté, procédant à un contrôle du contenu par imagerie lors du transfert de l&#39;emballage entre individus
FR2940567A1 (fr) Procede de securisation de transactions, dispositif de transaction, serveur bancaire, terminal mobile, et produits programmes d&#39;ordinateur correspondants
EP2537286B1 (fr) Procédé d&#39;authentification biométrique, système d&#39;authentification et programme correspondant
WO2018055156A1 (fr) Système d&#39;acheminement d&#39;objets, mettant en oeuvre un système de diffusion ciblée d&#39;informations
US20210049703A1 (en) Method for subscribing insurance policies from geolocated mobile devices with contracting on a distributed database
EP2929496A2 (fr) Gestion securisee d&#39;une transaction de prestation de service
WO2009056757A2 (fr) Système de transport public urbain
WO2023209302A1 (fr) Procédé et dispositif de contrôles numériques de la livraison d&#39;un objet d&#39;un premier véhicule à un deuxième véhicule
EP4367620A1 (fr) Procédé de controle d&#39;une transaction sans contact et objet communicant correspondant
EP3220328B1 (fr) Système d&#39;acheminement d&#39;objets par des individus d&#39;une communauté, utilisant un signal de prise en responsabilité de l&#39;emballage par un individu
EP4360339B1 (fr) Procédé de communication sans contact entre un objet communicant et un dispositif de communication
FR3052895B1 (fr) Procede d&#39;envoi d&#39;une information de securite
EP3220327B1 (fr) Sytème d&#39;acheminement d&#39;objets par des individus d&#39;une communauté, mettant en oeuvre un système de traçabilité spatiotemporelle
EP3343487A1 (fr) Procédé de contrôle d&#39;habitudes d&#39;utilisation et dispositif électronique apte à mettre en uvre un tel procédé
FR3159847A1 (fr) Procédé de vérification à distance d’une livraison d’objets dans un coffre de véhicule automobile
EP4187468A1 (fr) Gestion d&#39;un portefeuille électronique associé à un équipement connecté partagé
EP4199547A1 (fr) Traitement de données perfectionné pour un covoiturage efficace
WO2001018747A1 (fr) Dispositif electronique portatif avec afficheur et moyens de chargement de messages pour ce dernier
WO2025125604A1 (fr) Procédé de transaction « mains libres » à l&#39;aide d&#39;un terminal mobile
EP4254286A1 (fr) Système d&#39;acheminement d&#39;objets contenus dans des boîtes sur lesquelles sont prévus des moyens d&#39;identification du destinataire
FR3129757A1 (fr) Procédé d’établissement d’une transaction entre un objet communicant et un module de contrôle de la transaction associé à un dispositif de fourniture de bien(s) ou de service(s)
FR3020696A1 (fr) Procede et dispositif d&#39;authentification d&#39;un utilisateur pour l&#39;acces a des ressources distantes
EP4091150A1 (fr) Procede et systeme pour incorporer des positions geographiques de vehicules disponibles a la reservation dans une carte numerique
EP1542169A1 (fr) Procédé et système de contrôle d&#39;un titre d&#39;autorisation d&#39;accès à un service par identification biométrique

Legal Events

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

Free format text: STATUS: UNKNOWN

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

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

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

Free format text: ORIGINAL CODE: 0009012

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

Free format text: STATUS: REQUEST FOR EXAMINATION WAS MADE

17P Request for examination filed

Effective date: 20240124

AK Designated contracting states

Kind code of ref document: A1

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

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

Free format text: STATUS: EXAMINATION IS IN PROGRESS

17Q First examination report despatched

Effective date: 20250317