EP4437479A1 - Procédé d'établissement d'une transaction entre un objet communicant et un module de controle de la transaction associé à un dispositif de fourniture de bien(s) ou de service(s) - Google Patents

Procédé d'établissement d'une transaction entre un objet communicant et un module de controle de la transaction associé à un dispositif de fourniture de bien(s) ou de service(s)

Info

Publication number
EP4437479A1
EP4437479A1 EP22813331.0A EP22813331A EP4437479A1 EP 4437479 A1 EP4437479 A1 EP 4437479A1 EP 22813331 A EP22813331 A EP 22813331A EP 4437479 A1 EP4437479 A1 EP 4437479A1
Authority
EP
European Patent Office
Prior art keywords
transaction
reader
communicating object
control module
identifier
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
EP22813331.0A
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 EP4437479A1 publication Critical patent/EP4437479A1/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/388—Payment protocols; Details thereof using mutual authentication without cards, e.g. challenge-response
    • 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/401—Transaction verification
    • 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/325—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using wireless devices using wireless networks
    • 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
    • G06Q20/3278—RFID or NFC 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/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/34—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using cards, e.g. integrated circuit [IC] cards or magnetic cards
    • G06Q20/353—Payments by cards read by M-devices
    • G—PHYSICS
    • G07—CHECKING-DEVICES
    • G07F—COIN-FREED OR LIKE APPARATUS
    • G07F7/00—Mechanisms actuated by objects other than coins to free or to actuate vending, hiring, coin or paper currency dispensing or refunding apparatus
    • G07F7/08—Mechanisms actuated by objects other than coins to free or to actuate vending, hiring, coin or paper currency dispensing or refunding apparatus by coded identity card or credit card or other personal identification means
    • G07F7/0873—Details of the card reader
    • G07F7/0893—Details of the card reader the card reader reading the card in a contactless manner
    • G—PHYSICS
    • G07—CHECKING-DEVICES
    • G07B—TICKET-ISSUING APPARATUS; FARE-REGISTERING APPARATUS; FRANKING APPARATUS
    • G07B15/00—Arrangements or apparatus for collecting fares, tolls or entrance fees at one or more control points
    • G—PHYSICS
    • G07—CHECKING-DEVICES
    • G07B—TICKET-ISSUING APPARATUS; FARE-REGISTERING APPARATUS; FRANKING APPARATUS
    • G07B15/00—Arrangements or apparatus for collecting fares, tolls or entrance fees at one or more control points
    • G07B15/02—Arrangements or apparatus for collecting fares, tolls or entrance fees at one or more control points taking into account a variable factor such as distance or time, e.g. for passenger transport, parking systems or car rental systems

Definitions

  • the invention generally relates to the field of technologies used for the implementation of transactions such as, for example, banking transactions carried out within the framework of payment services which use payment terminals with or without contact, control transactions access carried out within the framework of access services, for example access to a means of transport or to a secure place, which use access control terminals with or without contact, etc.
  • Such terminals are configured to accept a means of access to the service implementing a transaction.
  • such an access means can communicate, for example by contact, with the payment terminal, said access means typically being a smart bank card, or can communicate without contact with the payment terminal, said means of access then typically being a contactless bank card, for example of the NFC (Near Field Communication) type, a mobile telephone provided with an NFC device, etc.
  • such an access means can communicate, for example, by contact with the access control terminal, said access means typically being a badge or a smart card, or can communicate without contact with the access control terminal, said access means then typically being an NFC-type card or badge, a mobile telephone provided with an NFC device, etc.
  • the invention relates to the pairing between a communication terminal of the aforementioned type and a communicating object provided with a means of access to a transaction service of the aforementioned type, such a communicating object being for example a connected vehicle , a smartphone (“smartphone”), a connected watch, etc.
  • the communicating object is for example a smartphone used as a means of payment
  • the user of the smartphone who wishes to interact with a payment terminal accessible from the supplier of the good or service to be paid for is systematically obliged to perform certain actions to bring your smartphone closer to the payment terminal reader.
  • Such actions become more complicated when the user is an occupant of a vehicle, for example the driver, the user being obliged:
  • TPE electronic payment terminal
  • a motorway toll payment terminal for example, a motorway toll payment terminal; a merchant TPE attached to the counter or tended by the attendant when paying for a drive-in good or service (open-air cinema, take-out sale, etc.).
  • the communication terminals used for the implementation of a transaction of the aforementioned type are hardware and integrate or are associated with a reader of means of access to a transaction service, these terminals represent significant costs for suppliers of good(s) or service(s) in terms of investment, maintenance, renewal, breakdowns, damage, etc.
  • One of the aims of the invention is to remedy the drawbacks of the aforementioned state of the art by allowing a communicating or connected object to carry out a transaction using a means of access to the service in which the transaction is implemented, in the absence of any physical transaction control terminal, such as a payment terminal of the TPE type, a hardware access control device associated with a terminal or an access gate to a means of transport or to a secure or unsecured place, etc.
  • an object of the present invention relates to a process for establishing a transaction using a communicating object for the implementation of a supply of a good or a service to a user. , during which the communicating object receives a request containing data relating to the transaction originating from a device for supplying the good or service or from a transaction control module associated with the device.
  • a reader being associated with the communicating object, read identification data of a means of access to said service, using the reader,
  • the invention advantageously proposes to carry out a communication between a reader associated with the communicating object and a transaction control module associated with the supplier of the good or the service, which allows the supplier of the good or the service to do without a physical terminal provided with a reader and configured to accept a means of access to the service implementing a transaction, which is much less expensive for this supplier.
  • the invention makes it possible to reconstitute on the fly a payment terminal of the TPE type for which the software part which processes the payment is associated with the device for supplying the good or the service.
  • an access terminal for which the software part which processes the access authorization is associated with the supply of the good or service (e.g.: a bus, an access gate to a library, an access barrier to a car park, etc.), and the part that deals with the reading of a means of access with or contactless is associated with the communicating object.
  • the software part which processes the access authorization is associated with the supply of the good or service (e.g.: a bus, an access gate to a library, an access barrier to a car park, etc.)
  • the part that deals with the reading of a means of access with or contactless is associated with the communicating object.
  • the transaction is much easier for the user to implement than in the prior art, since it is no longer necessary for the user to go to the reader to implement the transaction, given that this reader is associated with the communicating object with which the user is equipped.
  • the method implements a mutual authentication step between the reader associated with the communicating object and the transaction control module.
  • the method for establishing a transaction comprises the following, at the level of the reader associated with the communicating object, during the execution of said authentication step:
  • the invention also relates to a communicating object for establishing a transaction implementing a supply of a good or a service to a user, said communicating object comprising a processor which is configured to receive a request containing data relating to the transaction originating from a device for providing the good or service or from a transaction control module associated with said device.
  • Such a communicating object is remarkable in that the processor of the communicating object implements the following:
  • a reader being associated with the communicating object, read identification data of a means of access to the service, using the reader,
  • the invention also relates to a system for establishing a transaction.
  • a system for establishing a transaction is remarkable in that it includes:
  • a transaction control module which is associated with a device for supplying goods or services.
  • the invention also relates to a computer program comprising instructions for the implementation of the method for establishing a transaction according to the invention, according to any one of the particular embodiments described above, 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 process for setting up a 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 (“Read Only Memory”), for example a CD ROM (“Compact Disc Read-Only Memory”) or a microelectronic circuit ROM , or even a magnetic recording medium, for example a mobile medium, a hard disk or an SSD (“Solid State-Drive”).
  • 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 suitable for executing or for being used in the execution of the aforementioned method of establishing a transaction.
  • 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. 1 represents an example of architecture in which the method for establishing a transaction according to the invention is implemented
  • FIG. 2 represents a communicating object in one embodiment of the invention
  • FIG. 3 represents the main actions implemented in the process for establishing a transaction, according to a particular embodiment of the invention.
  • FIG. 4A represents an embodiment of an authentication step implemented in the method for establishing a transaction according to the invention
  • FIG. 4B represents another embodiment of an authentication step implemented in the method for establishing a transaction according to the invention
  • FIG. 5A represents a system for establishing a transaction according to a first embodiment of the invention
  • FIG. 5B represents a system for establishing a transaction according to a second embodiment of the invention
  • FIG. 5C represents a system for establishing a transaction according to a third embodiment of the invention.
  • a transaction establishment system includes:
  • a communicating or connected object OC is any object configured to capture data and to communicate with other objects or with dedicated infrastructures according to loT (Internet of Things) technology.
  • such a communicating object OC comprises a short or medium range wireless radio communication module COMo, such as for example Bluetooth, LTE (“Long Term Evolution”), WiFi, DSRC
  • the communicating object OC is associated with a reader LECT which is configured to read identification data from a means MAST access to a transaction implementation service.
  • the MAST means of access may be a physical medium carried by the user UT (e.g. bank card, transport badge, package delivery label, etc.) or a software medium integrated into the communicating object OC (e.g. : dematerialized payment card, dematerialized transport card, electronic purse, etc.).
  • the LECT reader is also configured to communicate with the COMo communication module.
  • the EVF environment for supplying goods or services comprises, in a manner corresponding to the communicating object OC, a module COMF for short or medium range wireless radio communication, such as for example Bluetooth , LTE, Wi-Fi, DSRC, C-V2X, etc.
  • a module COMF for short or medium range wireless radio communication such as for example Bluetooth , LTE, Wi-Fi, DSRC, C-V2X, etc.
  • the EVF environment further includes:
  • a MET module for recording and processing the transaction for the supply of good(s) or service(s),
  • the transaction control module MCT is associated with the device DF for supplying goods or services and/or with the module MET for recording and processing the transaction, in the sense that it can be either integrated into the DF device for supplying the good(s) or service(s) or into the MET module for recording and processing the transaction, or located in a virtualization environment made available to the supplier of the good(s) or service(s) by a telecommunications operator, for example using MEC (Mobile Edge Computing) technology.
  • MEC Mobile Edge Computing
  • the transaction control module MCT the device DF for providing goods or services, the module MET for recording and processing the transaction, are configured to communicate with each other.
  • the transaction control module MCT is also configured to communicate, using any suitable type of communication and via the transaction recording and processing module MET, with a transaction management environment EGT which , in the example shown, is symbolized by a transaction management server SERV.
  • a transaction management server SERV a transaction management server
  • FIG. 2 presents the simplified structure of the communicating object OC configured to implement the process for setting up a transaction which will be described below.
  • Such a communicating object comprises according to the invention:
  • COMo 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.,
  • a user interface IU configured to receive information from the user UT or to restore information to the user in textual, visual and/or sound form: it may be for example a display screen, a keyboard and/or a speaker built into the communicating object OC,
  • a HARD material part such as for example an opening capable of receiving a MAST access means, as well as possibly a keyboard or an interface with the keyboard of the user interface UI, or even a contactless communication surface , for example of the NFC type,
  • an authentication module AUT which is configured to authenticate the transaction control module MCT of the EVF environment for the supply of good(s) or service(s) with which the communicating object OC wishes to implement the transaction
  • module ACC for accessing a memory MEMi which contains data for identifying means of access MAST to a service for implementing the transaction, in the case where such means are envisaged in digital or dematerialized form.
  • the SOFT software part of the LECT reader can be:
  • this secure element may for example take the form of an eSIM (“Embedded Subscriber Identification Module”) which is provided by a telecommunications operator or the manufacturer of the the communicating object OC; a secure application, for example of the SAM (“Secured Applications for Mobile”) type offered by the GSM Association (“Global System for Mobile Communications”).
  • eSIM embedded Subscriber Identification Module
  • SAM Secured Applications for Mobile
  • the reader LECT is associated with the communicating object OC in the sense that the HARD part of the reader LECT can be integrated into the communicating object OC or be an autonomous part which is connected to the communicating object OC by any suitable connection means , wired or wireless.
  • the memory MEMi is not necessarily contained in the communicating object OC in order to preserve its memory resources.
  • the memory MEMi can be deported in a secure communication network, a secure cloud, etc. and is made accessible by the communicating object OC, by means of the module ACC dedicated to this purpose.
  • the memory MEMi or part of it could be integrated into the communicating object OC.
  • the actions executed by the communicating object OC are implemented by instructions of 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 computer program PG comprises instructions for implementing 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 of contactless communication via the module COMo, the actions of reading identification data of the means of access MAST via the reader LECT, the actions of authentication using the AUT authentication module. Description of an embodiment of a method for establishing a transaction
  • Such a transaction is established during a prior contactless communication between the communicating object OC and the device DF for supplying the aforementioned good(s) or service(s).
  • the object of the transaction is for example a good or a service supplied by the device DF for supplying good(s) or service(s) to the user UT of the communicating object OC.
  • the transaction control module MCT and/or the transaction recording and processing module MET verify in S1 that the device DF for supplying the good(s) or service(s) is operational.
  • the transaction control module MCT or the device DF for providing good(s) or service(s) sends to the communicating object OC, via the secure channel established in S0, a request REQ LECT asking whether the communicating object OC contains a reader LECT.
  • the communicating object OC receives the REQ_LECT request in S3.
  • the communicating object OC containing such a reader LECT a mutual authentication is then executed in S4, via the authentication module AUT of FIG. 2, between the transaction control module MCT and reader LECT.
  • a mutual authentication is then executed in S4, via the authentication module AUT of FIG. 2, between the transaction control module MCT and reader LECT.
  • Such a step S4 is implemented depending on the more or less secure nature of the transaction.
  • step S4 is mandatory.
  • step S4 may be optional.
  • the transaction control module MCT or the device DF for supplying the good(s) or service(s) then sends to the communicating object OC, via the secure channel established in S0, a request REQ_TR containing DAT data relating to a transaction. It can be a message asking the user UT to present his means of access MAST to the reader LECT and/or a message containing the type of good and/or service, its value, its amount, etc
  • the communicating object OC receives the request REQ_TR in S6.
  • the UI user interface is then activated to inform the UT user about the content of the DAT data and request the UT user to interact with the LECT reader, via an available MAST access means.
  • the reader LECT reads in S8 identification data IDMAST of the access means MAST.
  • Such reading is implemented for example following a contactless communication, for example NFC, between the access means MAST and the reader LECT.
  • a contactless communication for example NFC
  • such reading is implemented following the introduction of the access means MAST into a dedicated opening of the reader LECT and the possible entry by the user UT of a password MP by means of the keyboard of the user interface UI or the keyboard integrated into the HARD hardware part of the LECT player.
  • such reading S8 is implemented following access, via the access module ACC of FIG. 2, to this means MAST access, in the memory MEMi of the communicating object OC.
  • the communicating object OC sends to the transaction control module MCT, via the secure channel established in S0, a response REP_TR to the request REQ_TR, said response REP_TR containing the identification data IDMAST of the access means MAST .
  • the transaction control module MCT receives the response REP TR and the transaction is then validated in a conventional manner on the basis of the identification data IDMAST of the access means MAST which have been received, and in conjunction with the EGT environment for managing the transaction, via the MET module for recording and processing the transaction.
  • the invention makes it possible, when a user UT, having a communicating object OC, is in a transaction situation with a supply environment of good(s) or service(s) EVF, to generate an assembly of a reader LECT of the means of access MAST, associated with the communicating object OC, with a transaction control module MCT which is available in the EVF environment for the supply of good(s) or service(s).
  • a transaction control module MCT which is available in the EVF environment for the supply of good(s) or service(s).
  • such a reader LECT can be used to constitute a multitude of transaction terminals according to the transactions carried out by the user with different suppliers of good(s) or service(s).
  • the transaction control module MCT which is instantiated in an EVF environment for the provision of given good(s) or service(s) can be assembled with a multitude of readers LECT presented by different users UT.
  • the connection of a transaction control MCT module with different LECT readers can be simultaneous to allow the execution of transactions in parallel, which is not necessarily the case when it comes to the connection of an LECT reader with different transaction control MCT modules simultaneously.
  • authentication is requested at the initiative of the MCT module controlling the transaction.
  • the authentication step S4 then takes place as follows:
  • the transaction control module MCT sends to the reader LECT, via the secure channel established in S0, an authentication request REQ_AUT1 which includes an identifier IDMC ⁇ of the module MCT .
  • the sending step S40 can be executed, for example following the reception of a confirmation message from the reader LECT indicating that the communicating object OC has such a reader LECT.
  • the request REQ AUT1 could be transmitted simultaneously with the request REQ LECT sent in S2 (FIG. 3) asking whether the communicating object OC contains a reader LECT.
  • the communicating object OC receives the REQ_AUT1 request in S41.
  • the reader LECT verifies whether the identifier IDMCT received is valid. If the received IDMCT identifier is invalid, authentication fails.
  • the reader LECT If the identifier IDMCT received is valid, in S43, the reader LECT in turn sends to the transaction control module MCT, via the secure channel established in S0, an authentication request REQ_AUT2 which includes an identifier IDLEC ⁇ of the reader LECT.
  • the MCT module receives the REQ_AUT2 request at S44.
  • the MCT module checks whether the IDiECT identifier received is valid. If the lÜLECT identifier received is not valid, the authentication fails.
  • the mutual authentication between the module MCT and the reader LECT is established, which makes it possible to constitute a transaction terminal distributed between the environment for the supply of goods or service(s) and the communicating object OC.
  • step S42 of verification of the identifier IDMCT the reader LECT verifies that this identifier is part of a list of identifiers previously stored for example in the memory MEMi of FIG. 2 or in any other suitable memory integrated into the communicating object OC or connected to the latter.
  • the MCT module verifies that this identifier is part of a list of identifiers previously stored in a memory (not shown) accessible by the MCT module in the EVF environment for supplying goods or services.
  • the mutual authentication step S4 uses an encryption mechanism.
  • the IDMCT identifier of the MCT module is transmitted in encrypted form using an encryption key associated with a digital certificate CERTMCT; - During the aforementioned sending step S43, the identifier IDLEC ⁇ du reader LECT is transmitted in encrypted form using an encryption key associated with a digital certificate CERTLECT.
  • the digital certificates CER ⁇ MCT and CERTLECT are issued by a trusted third-party authority and stored respectively in a memory (not shown) accessible by the module MCT in the EVF environment for the supply of goods or services ( s) and in the memory MEMi of FIG. 2 or in any other suitable memory integrated into the communicating object OC or connected to the latter.
  • the authentication step S4 then proceeds as follows: In S40', the reader LECT of the communicating object OC sends to the transaction control module MCT, via the secure channel established in S0, an authentication request REQ_AUTT which includes an identifier IDLEC ⁇ du reader LECT.
  • the sending step S40′ can be executed for example following the reception S3 of the request REQ_LECT asking whether the communicating object OC contains a reader LECT or simultaneously with the sending to the module MCT of a confirmation message indicating that the communicating object OC does have a reader LECT.
  • the MCT module receives the REQ_AUTT request in S4T.
  • the MCT module verifies whether the received identifier lÜLECT is valid. If the lÜLECT identifier received is not valid, the authentication fails.
  • the module MCT If the identifier lÜLECT received is valid, in S43′, the module MCT in turn sends to the reader LECT, via the secure channel established in S0, an authentication request REQ_AUT2′ which includes an identifier lÜMCT of the module MCT.
  • the reader LECT receives the request REQ_AUT2' at S44'.
  • the reader LECT verifies whether the received identifier 1MCT is valid. If the received lÜMCT identifier is not valid, the authentication fails.
  • step S46′ mutual authentication between the module MCT and the reader LECT is established, which makes it possible to constitute a transaction terminal distributed between the environment EVF for supplying goods or service(s) and the communicating object OC.
  • the module MCT verifies that this identifier is part of a list of identifiers previously stored in a memory (not shown ) accessible by the MCT module in the EVF environment for the supply of goods or services.
  • step S45′ of verifying the identifier IDMCT the reader LECT verifies that this identifier is part of a list of identifiers previously stored for example in the memory MEMi of FIG. 2 or in any another suitable memory integrated in the communicating object OC or connected to the latter.
  • the mutual authentication step S4 uses an encryption mechanism.
  • the IDLECT identifier of the LECT reader is transmitted in encrypted form using an encryption key associated with a CERT’LECT digital certificate;
  • the IDMCT identifier of the MCT module is transmitted in encrypted form using an encryption key associated with a digital certificate CERT'MCT.
  • the CERT'LECT and CERT'MCT digital certificates are issued by a trusted third-party authority and stored respectively in a memory (not shown) accessible by the MCT module in the EVF environment for supplying goods ) or service(s) and in the memory MEMi of FIG. 2 or in any other suitable memory integrated into the communicating object OC or connected to the latter.
  • FIG. 5A represents a system for setting up a transaction according to a first embodiment, for which the transaction is of the banking type.
  • the communicating object OC is for example a vehicle, here a connected electric car.
  • the OC car is natively equipped with a plurality of sensors/detectors such as for example a camera, a sensor which detects the level of the battery charge, a speed sensor, a geolocation device such as GPS ("Global Positioning System" in English), a fingerprint sensor, etc...
  • the OC connected car is equipped with:
  • a reader LECT which, in the example shown, is configured to read identification data from a MAST payment card, whether physical or dematerialized.
  • the reader LECT is embedded in the connected vehicle OC.
  • HARD material part is an integral part of the passenger compartment (area marked on the dashboard for example), or added to the vehicle (equipment as retrofit).
  • the HARD part can also be independent equipment provided by the UT user and paired with the vehicle information system.
  • the SOFT software part is implemented within the computer processing infrastructure deployed in the vehicle (vehicle operating system and applications deployed on it). This infrastructure offers performance and security compatible with the Payment Card Industry Data Security Standard (PCI DSS).
  • PCI DSS Payment Card Industry Data Security Standard
  • the LECT reader can exploit the UI user interface of the vehicle information system, for example using the console screen integrated into the dashboard, as well as the means of input offered to the user (touch screen, wheel to interact with the screen, voice command, etc).
  • the device DF for supplying goods or services is one charging station among others available from a charging station for electric vehicles.
  • the charging station is number 3.
  • the device DF for providing good(s) or service(s) varies according to the context of use of the connected car OC.
  • the device for supplying DF good(s) or service(s) could alternatively be:
  • the DF charging station communicates in the EVF environment for the supply of goods or services, via any suitable means of communication, with:
  • the DF charging station is also equipped with a COMF module for short or medium range wireless radio communication, such as for example Bluetooth, LTE, WiFi, DSRC, C-V2X, etc.
  • a COMF module for short or medium range wireless radio communication, such as for example Bluetooth, LTE, WiFi, DSRC, C-V2X, etc.
  • the MET cash register system is configured to record transactions and initiate a payment operation to the MCT payment kernel.
  • the MCT payment kernel is connected to the MET cash register system and has outward connectivity to communicate with the EGT environment for managing the transaction, and in particular with the BF server of the goods supplier's bank ( s) or service(s), here the manager of the charging station.
  • This server BF is here part of the transaction management server SERV, the server BF being in communication with the server RC of the bank card network which itself communicates with the server BU of the bank of the user UT.
  • This kernel component can be implemented in a virtualized way, in software form, hosted by a cloud or telecom operator in a hardware and software environment compatible with the aforementioned PCI DSS standard.
  • the payment kernel is of the EMV (Europay, Mastercard and Visa) type.
  • the connected electric car OC begins by pairing up in S0 with the charging station DF, via the respective communication modules MCOo and MCOF, in order to establish a channel secure contactless communication to implement the transaction, here a payment corresponding to the recharge made.
  • the successful pairing signal is then transmitted to the MET cash register system and to the MCT payment kernel.
  • the payment kernel MCT and/or the cash register system MET verify in S1 that the charging station DF is operational.
  • the payment kernel MCT or the charging station DF sends to the connected car OC, via the secure channel established in S0, a request REQ LECT asking whether the connected car OC contains a reader LECT.
  • the connected car OC receives the request REQ LECT in S3.
  • the connected car OC containing such a reader LECT a mutual authentication is then executed in S4 between the payment kernel MCT and the reader LECT, so as to emulate a payment terminal of the TPE type.
  • Step S4 can be followed by a pre-authorization step required by the payment terminal thus emulated.
  • the payment kernel MCT or the charging station DF sends a request REQ_TR to the user UT asking him to present his means of payment MAST, either by means of a sound message DAT delivered on an in-car speakerphone, or using a DAT text message displayed on the console screen.
  • the connected car OC receives the request REQ_TR in S6.
  • the UI user interface is then activated to ask the user UT to present his MAST payment card to the LECT reader.
  • the reader LECT then reads in S8 identification data IDMAST of the payment card MAST.
  • the user UT approaches his card in S8 to the NFC surface of the reader LECT.
  • the UT user may be asked to enter a secret code MP on the keyboard of the car console OC.
  • the user UT inserts the latter into a dedicated opening of the LECT reader and enters his secret code MP on the console keyboard.
  • the payment card MAST is virtualized
  • such reading S8 is implemented following access, via the access module ACC of FIG. 2, to the virtualized payment card MAST, in the memory MEMi of the OC connected car. If there are several virtualized cards in memory, the access is executed following a selection by the user UT of the virtualized card to be used for the transaction.
  • the connected car OC transmits to the payment kernel MCT, via the secure channel established in S0, the identification data IDMAST.
  • the payment kernel makes the pre-authorization request to the server BU of the user's bank UT. This request is processed in the conventional way, that is to say that the request is routed from the server BF of the bank of the service station, via the server RC of the bank card network, to the server BU of the bank of the UT user.
  • the payment kernel MCT transmits a signal to the charging station DF to authorize it to supply electricity to the connected car OC.
  • the payment kernel MCT or the charging station DF communicates the amount DAT to be debited to the connected car OC, via the secure channel established in S0.
  • the payment kernel MCT performs the debit in S10 via the servers BU, RC and BF, then transmits to the reader LECT the end of transaction information, for display on the screen of the connected car OC or for listening via the loudspeaker(s). connected car speakers OC.
  • FIG. 5B represents a system for establishing a transaction according to a second embodiment of the invention, for which the transaction is an access control to a secure or unsecured premises, a means of transport, etc.
  • This second embodiment uses elements common to those of FIG. 5A. For this reason, these elements are designated with the same references.
  • the communicating object OC is for example 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 OC 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 OC is equipped with:
  • COMo module for short or medium range wireless radio communication, such as for example Bluetooth, LTE, WiFi, DSRC, C-V2X, etc.,
  • a reader LECT which, in the example shown, is configured to read identification data from a MAST transport badge, whether physical or dematerialized.
  • the LECT reader is associated with the connected watch OC.
  • Its HARD material part is an integral part of the case of the OC watch or connected to the latter.
  • the SOFT software part is for its part implemented within the operating system of the watch OC.
  • the LECT player can exploit the watch's UI user interface (keyboard, screen, speaker, haptics (vibration)).
  • the device DF for supplying good(s) or service(s) is an access gate to a means of transport, such as for example the metro, the train, the tramway, etc It can also be a terminal located in a bus or tram, near a platform in a station, etc.
  • the DF gate communicates in the EVF environment for the supply of goods or services, via any suitable means of communication, with:
  • the DF gate is also equipped with a COMF module for short or medium range wireless radio communication, such as for example Bluetooth, LTE, WiFi, DSRC, C-V2X, etc.
  • a COMF module for short or medium range wireless radio communication, such as for example Bluetooth, LTE, WiFi, DSRC, C-V2X, etc.
  • the MET transaction recording and processing system is configured to record transactions and initiate an access operation to the MCT access control server.
  • the access control server MCT is linked to the transaction registration and processing system MET and is equipped with outward connectivity to communicate with the transaction management environment EGT, and in particular with a transaction management server SERV which is held for example by a transport authority.
  • the connected watch OC begins by pairing up in S0 with the gate DF, via the respective communication modules MCOo and MCOF, in order to establish a communication channel without secure contact to implement the transaction, here access to public transport.
  • the successful pairing signal is then transmitted to the transaction recording and processing system MET and to the access control server MCT.
  • the access control server MCT and/or the transaction recording and processing system MET verify in S1 that the gate DF is operational.
  • the access control server MCT or the gate DF sends to the connected watch OC, via the secure channel established in S0, a request REQ LECT asking whether the connected watch OC contains a reader LECT.
  • the connected watch OC receives the request REQ LECT in S3.
  • the connected watch OC containing such a reader LECT, a mutual authentication in accordance with the invention is then executed in S4 between the access control server MCT and the reader LECT, so as to emulate an access control terminal.
  • the access control server MCT or the gate DF sends a request REQ_TR to the user UT asking him to present his transport badge MAST, either by means of a sound message DAT delivered on the loudspeaker OC watch speaker, or using a DAT text message displayed on the watch screen.
  • the DAT data can contain the type of the transaction, for example an identifier of the transport line and/or a number of tickets to be validated.
  • the connected watch OC receives the request REQ_TR in S6.
  • the UI user interface is then activated to ask the user UT to present his transport badge MAST to the reader LECT.
  • the reader LECT then reads in S8 identification data IDMAST from the MAST transport badge.
  • the transport badge MAST is a contactless smart card, for example of the NFC type
  • the user UT approaches his badge in S8 to the NFC surface of the reader LECT.
  • the user UT may be asked to enter a secret code MP on the keyboard of the connected watch OC.
  • such a reading S8 is implemented following access, via the access module ACC of FIG. 2, to the MAST badge, in the memory MEMi of the watch OC . If there are several transport badges in memory, the access is executed following a selection by the user UT of the badge to be used to access the means of transport.
  • the watch OC transmits to the access control server MCT, via the secure channel established in S0, the identifier IDiwxsT of the badge MAST.
  • the access control server MCT decrements one or more digital transport tickets preloaded in the transport badge MAST or in the memory MEMi of the connected watch OC when the badge MAST is in dematerialized form.
  • the access control server MCT checks in S10 with the management server SERV that the identifier IDiwxsT of the badge MAST is indeed valid.
  • the access control server MCT commands the opening of the gate DF to let the user UT pass, then commands its closing after a predetermined period.
  • the transaction is then recorded in the transaction recording system MET which communicates the information of this transaction to the server SERV.
  • the access control server MCT transmits to the reader LECT the end of transaction information, for example the number of tickets used, for display on the screen of the connected watch OC or for listening via the loudspeaker(s) of the OC smartwatch.
  • FIG. 5C represents a system for establishing a transaction according to a third embodiment of the invention, for which the transaction is a command for the opening/closing of a locker of a box, terminal or cabinet of automatic parcel pick-up.
  • This third embodiment uses elements common to those of FIGS. 5A and 5B. For this reason, these elements are designated with the same references.
  • the communicating object OC is for example 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 OC 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 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 OC smartphone is equipped with:
  • a COMo module for short or medium range wireless radio communication, such as for example Bluetooth, LTE, WiFi, DSRC, C-V2X, etc.
  • a reader LECT which, in the example shown, is configured to read identification data from a MAST label for picking up a COL package, such as for example a barcode or a QR ("Quick Response” in English) code which was previously transmitted to the smartphone OC by the brand which sold the goods contained in the package or by the carrier which transported the package.
  • the MAST tag could be a physical tag available to the user UT and bearing the aforementioned barcode or QR code.
  • the HARD hardware part of the LECT reader is an integral part of the OC smartphone.
  • the hardware part HARD can be equipment that the user UT connects beforehand to the smartphone OC, by a wired link or a wireless connection.
  • the SOFT software part of the LECT reader is implemented within the operating system of the smartphone OC.
  • the LECT player can exploit the OC smartphone UI user interface (keyboard, screen, speaker).
  • the device DF for supplying goods or services is an automatic parcel pick-up box.
  • this box comprises seven compartments referenced A to G.
  • the DF withdrawal box communicates in the EVF environment for the supply of goods or services, via any suitable means of communication, with:
  • an MCT server for opening/closing a locker.
  • the DF box is also equipped with a COMF module for short or medium range wireless radio communication, such as for example Bluetooth, LTE, WiFi, DSRC, C-V2X, etc.
  • a COMF module for short or medium range wireless radio communication, such as for example Bluetooth, LTE, WiFi, DSRC, C-V2X, etc.
  • the MET transaction recording system is configured to record transactions, here package withdrawals, and initiate a package withdrawal operation to the MCT server for opening/closing a locker.
  • the locker opening/closing control server MCT is linked to the transaction recording and processing system MET and equipped with outward connectivity to communicate with the EGT environment for managing the transaction. transaction, and in particular with a transaction management server SERV which includes a management server SEN belonging to the brand which sold the goods contained in the package COL, which server SEN communicates with a STR management server belonging to the carrier that routed the package to the DF pick-up box.
  • a transaction management server SERV which includes a management server SEN belonging to the brand which sold the goods contained in the package COL, which server SEN communicates with a STR management server belonging to the carrier that routed the package to the DF pick-up box.
  • the smartphone OC begins by pairing up in S0 with the withdrawal box DF, via the respective communication modules MCOo and MCOF, in order to establish a secure contactless communication channel to implement the transaction, here a command to open/close a locker.
  • the successful pairing signal is then transmitted to the MET system for recording and processing the transaction and to the MCT server for controlling the opening/closing of the locker E containing the package COL to be collected.
  • the locker opening/closing control server MCT or the withdrawal box DF sends to the smartphone OC, via the secure channel established in S0, a request REQ_LECT asking whether the smartphone OC contains a reader LECT.
  • the smartphone OC receives in S3 the request REQ_LECT
  • the smartphone OC containing such a reader LECT a mutual authentication in accordance with the invention is then executed in S4 between the server MCT and the reader LECT, so as to emulate a locker opening or closing control terminal.
  • the server MCT or the withdrawal box DF sends a request REQ_TR to the user UT asking him to present his withdrawal label MAST, either using a sound message DAT delivered on the loudspeaker of the smartphone OC , or using a DAT text message displayed on the smartphone screen.
  • the DAT data may contain an identifier, a logo or a name of the sign of the shop from which the COL package comes, the price of the order, an identifier of the locker which contains the COL package, etc. .
  • the UI user interface is then activated to ask the user UT to present his MAST withdrawal tag to the reader LECT.
  • the reader LECT then reads in S8 identification data IDMAST of the MAST label, here the barcode or the QR code.
  • the MAST tag is a physical medium, for example a sheet of paper, a sticker or the like
  • the user UT approaches the MAST tag in S8 to the surface of the reader LECT which is suitable for reading such codes .
  • such reading S8 is implemented following access, via the access module ACC of FIG. 2, to the MAST tag, in the memory MEMi of the OC smartphone. If there are several tags stored in memory, the access is executed following selection by the user UT of the MAST tag to be read.
  • the smartphone OC transmits to the MCT server, via the secure channel established in S0, the identifier IDiwxsT of the MAST tag.
  • the MCT server checks with the carrier's STR server that the identifier IDiwxsT of the MAST label is indeed valid. This identifier being valid, the server MCT commands the opening of one of the lockers which contains the package COL, the locker E in the example represented, then once the locker E has been emptied, orders its closing after a period predetermined. The transaction is then recorded in the transaction recording and processing system MET, which communicates the information of this transaction to the SEN and STR servers.
  • the access control server MCT transmits end-of-transaction information to the reader LECT, for example the number of packages withdrawn, for display on the screen of the smartphone OC or for listening via the speaker(s) of the smartphone OC.

Landscapes

  • Business, Economics & Management (AREA)
  • Engineering & Computer Science (AREA)
  • Accounting & Taxation (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • General Business, Economics & Management (AREA)
  • Strategic Management (AREA)
  • Theoretical Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Finance (AREA)
  • Computer Security & Cryptography (AREA)
  • Microelectronics & Electronic Packaging (AREA)
  • Control Of Vending Devices And Auxiliary Devices For Vending Devices (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)
  • Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)

Abstract

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) Procédé d'établissement d'une transaction à l'aide d'un objet communicant (OC), ledit objet recevant (S6) une requête contenant des données relatives à la transaction, d'un dispositif de fourniture d'un bien ou d'un service ou d'un module (MCT) de contrôle de la transaction associé audit dispositif, caractérisé en ce que ledit objet réalise ce qui suit : - recevoir (S3) dudit module ou dudit dispositif, un message requérant si un lecteur d'un moyen d'accès à un service de mise en œuvre de ladite transaction est associé audit objet, - un lecteur étant associé audit objet, lire (S8) des données d'identification d'un moyen (MAST) d'accès audit service, à l'aide dudit lecteur, - transmettre (S9) les données d'identification au module (MCT) pour valider la transaction.

Description

DESCRIPTION
Titre : 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)
Domaine de l'invention
L'invention se rapporte de manière générale au domaine des technologies utilisées pour la mise en œuvre de transactions telles que par exemple des transactions bancaires effectuées dans le cadre de services de paiement qui utilisent des terminaux de paiement avec ou sans contact, des transactions de contrôle d’accès effectuées dans le cadre de services d’accès, par exemple d’accès à un moyen de transport ou à un lieu sécurisé, qui utilisent des terminaux de contrôle d’accès avec ou sans contact, etc. De tels terminaux sont configurés pour accepter un moyen d’accès au service mettant en œuvre une transaction. Dans le cadre d’une transaction bancaire par exemple, un tel moyen d’accès peut communiquer, par exemple par contact, avec le terminal de paiement, ledit moyen d’accès étant typiquement une carte bancaire à puce, ou peut communiquer sans contact avec le terminal de paiement, ledit moyen d’accès étant alors typiquement une carte bancaire sans contact, par exemple de type NFC (de l’anglais « Near Field Communication »), un téléphone mobile muni d’un dispositif NFC, etc. De manière analogue, dans le cadre d’une transaction de contrôle d’accès, un tel moyen d’accès, peut communiquer par exemple par contact avec le terminal de contrôle d’accès, ledit moyen d’accès étant typiquement un badge ou une carte à puce, ou peut communiquer sans contact avec le terminal de contrôle d’accès, ledit moyen d’accès étant alors typiquement une carte ou un badge de type NFC, un téléphone mobile muni d’un dispositif NFC, etc.
Plus précisément, l'invention porte sur l’appairage entre un terminal de communication du type précité et un objet communicant doté d’un moyen d’accès à un service de transaction du type précité, un tel objet communicant étant par exemple un véhicule connecté, un smartphone (« téléphone intelligent »), une montre connectée, etc.
Art antérieur Actuellement, pour payer un bien ou un service à l’aide d’un objet communicant du type précité, il est nécessaire de se rapprocher physiquement d’un lecteur de moyens de paiement associé au terminal de paiement, de manière à ce que le lecteur puisse lire le moyen de paiement utilisé, qu’il soit sans contact ou non.
Ainsi, lorsque l’objet communicant est par exemple un smartphone utilisé en tant que moyen de paiement, l’utilisateur du smartphone qui souhaite interagir avec un terminal de paiement accessible du fournisseur du bien ou du service à payer est systématiquement obligé de faire certaines actions pour rapprocher son smartphone du lecteur du terminal de paiement. De telles actions se compliquent lorsque l’utilisateur est un occupant d’un véhicule, par exemple le conducteur, l’utilisateur étant obligé :
- soit de sortir du véhicule, lorsque par exemple le terminal de paiement est intégré à un automate de pompe à essence par exemple,
- soit de baisser la vitre de son véhicule pour interagir avec un terminal de paiement électronique (TPE) qui est disposé ou manipulé pour être accessible à l’utilisateur conducteur (par exemple, une borne de paiement de péage autoroutier ; un TPE marchand fixé au comptoir ou tendu par le préposé lors du paiement d’un bien ou d’un service en drive-in (cinéma en plein air, vente à emporter, etc.).
De telles interactions avec les terminaux de paiement présentent les inconvénients suivants :
- un manque d’ergonomie, puisqu'il est parfois nécessaire de sortir du véhicule pour présenter son moyen de paiement, ou de manœuvrer le véhicule de façon assez précise pour pouvoir atteindre ensuite le TPE (faute de quoi il faut pouvoir ouvrir la portière pour sortir et accéder difficilement au TPE),
- un manque de sécurité, car un automate de paiement disposé dans un espace public peut être observé pour intercepter un code secret par exemple, et peut être plus facilement piraté par une personne malintentionnée pour intercepter des secrets échangés lors de la transaction.
Dans le cas d’un service de contrôle d’accès, ce manque d’ergonomie et de sécurité est également constaté. En effet, dans le cas par exemple de l’accès à un bus ou à un tramway, il est parfois difficile, notamment en cas d’affluence ou pour une personne à mobilité réduite, d’accéder au lecteur du terminal de contrôle d’accès, généralement installé dans le bus ou le tramway, pour présenter sa carte de transport et ainsi valider son trajet. Et comme il s’agit de transports publics, le piratage précité peut également être mis en œuvre de manière similaire à un service de paiement.
Par ailleurs, compte tenu du fait que les terminaux de communication utilisés pour la mise en œuvre d’une transaction du type précité sont matériels et intègrent ou sont associés à un lecteur de moyens d’accès à un service de transaction, ces terminaux représentent des coûts importants pour les fournisseurs de bien(s) ou de service(s) en termes d’investissement, de maintenance, de renouvellement, de pannes, de dégradations, etc.
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 communicant ou connecté d’effectuer une transaction à l’aide d’un moyen d’accès au service dans lequel la transaction est mise en œuvre, en l’absence de tout terminal physique de contrôle de la transaction, tel qu’un terminal de paiement du type TPE, un dispositif matériel de contrôle d’accès associé à une borne ou à un portillon d’accès à un moyen de transport ou à un lieu sécurisé ou non, etc.
A cet effet, un objet de la présente invention concerne un procédé d’établissement d’une transaction à l’aide d’un objet communicant pour la mise en œuvre d’une fourniture d’un bien ou d’un service à un utilisateur, au cours duquel l’objet communicant reçoit une requête contenant des données relatives à la transaction en provenance d’un dispositif de fourniture du bien ou du service ou d’un module de contrôle de la transaction associé au dispositif.
Un tel procédé est remarquable en ce que l’objet communicant met en œuvre ce qui suit :
- recevoir en provenance du module ou du dispositif, un message requérant si un lecteur d’un moyen d’accès à un service de mise en œuvre de la transaction est associé à l’objet communicant,
- un lecteur étant associé à l’objet communicant, lire des données d’identification d’un moyen d’accès audit service, à l’aide du lecteur,
- transmettre les données d’identification lues au module logiciel de contrôle de ladite transaction pour valider la transaction. L’invention propose avantageusement de réaliser une communication entre un lecteur associé à l’objet communicant et un module de contrôle de transaction associé au fournisseur du bien ou du service, ce qui permet au fournisseur du bien ou du service de se passer d’un terminal physique muni d’un lecteur et configuré pour accepter un moyen d’accès au service mettant en œuvre une transaction, ce qui est beaucoup moins coûteux pour ce fournisseur. Ainsi, par exemple, lors d’une transaction de type bancaire, l’invention permet de reconstituer à la volée un terminal de paiement du type TPE pour lequel la partie logicielle qui traite le paiement est associée au dispositif de fourniture du bien ou du service (ex : une pompe à essence, un guichet de vente à emporter, etc.) et la partie qui traite la lecture d’un moyen de paiement avec ou sans contact est associée à l’objet communicant. Selon un autre exemple, dans le cas d’une transaction de type contrôle d’accès, il est possible de reconstituer à la volée une borne d’accès pour laquelle la partie logicielle qui traite l’autorisation d’accès est associée au dispositif de fourniture du bien ou du service (ex : un bus, un portillon d’accès à une bibliothèque, une barrière d’accès à un parking, etc.), et la partie qui traite la lecture d’un moyen d’accès avec ou sans contact est associée à l’objet communicant.
Par ailleurs, la transaction est beaucoup plus facile à mettre en œuvre pour l’utilisateur que dans l’art antérieur, puisqu’il n’est plus nécessaire que l’utilisateur se déplace vers le lecteur pour mettre en œuvre la transaction, étant donné que ce lecteur est associé à l’objet communicant dont l’utilisateur est doté.
Selon un mode de réalisation particulier, avant l’étape de lecture, le procédé met en œuvre une étape d’authentification mutuelle entre le lecteur associé à l’objet communicant et le module de contrôle de la transaction.
Une telle authentification mutuelle revient à réaliser avantageusement, à chaque transaction, un appairage dynamique entre le lecteur côté objet communicant et le module logiciel de contrôle de transaction instancié côté fournisseur de bien(s) ou de service(s). La transaction est ainsi beaucoup plus flexible pour l’utilisateur que dans l’art antérieur, puisque l’objet communicant dont il dispose est associé à un lecteur générique qui est configuré pour lire différents types de moyens d’accès à un service de mise en œuvre d’une transaction, tels que des cartes de paiement, des cartes de transport, etc. et qui est apte à fonctionner indépendamment du type de fournisseur de bien(s) ou de service(s) (une station-service, une enseigne de vente à emporter, un parking privatif, etc.), grâce à cet appairage dynamique avec un module de contrôle de la transaction associé au dispositif de fourniture du bien ou du service et non avec ce dispositif lui-même.
Selon un autre mode de réalisation particulier, le procédé d’établissement d’une transaction selon l’invention comprend ce qui suit, au niveau du lecteur associé à l’objet communicant, lors de l’exécution de ladite étape d’authentification :
- recevoir, en provenance du module de contrôle de la transaction, un identifiant dudit module,
- vérifier la validité de l’identifiant,
- l’identifiant étant valide, transmettre un identifiant du lecteur au module de contrôle de transaction,
- l’identifiant dudit lecteur ayant été reconnu comme valide par le module de contrôle de la transaction, authentifier mutuellement le lecteur et le module de contrôle de la transaction.
Dans ce mode de réalisation, c’est le module de contrôle de la transaction côté fournisseur du bien ou du service qui est à l’initiative de l’appairage avec le lecteur associé à l’objet communicant.
Selon un autre mode de réalisation particulier, le procédé d’établissement d’une transaction selon l’invention comprenant ce qui suit, au niveau du lecteur associé à l’objet communicant, lors de l’exécution de l’étape d’authentification :
- transmettre au module de contrôle de la transaction un identifiant du lecteur,
- l’identifiant du lecteur ayant été reconnu comme valide par le module de contrôle de la transaction, recevoir, en provenance du module, un message contenant un identifiant du module,
- vérifier la validité de l’identifiant du module,
- l’identifiant du module étant valide, authentifier mutuellement le lecteur et le module de contrôle de la transaction.
Dans ce mode de réalisation, c’est le lecteur côté objet communicant qui est à l’initiative de l’appairage avec le module de contrôle de la transaction côté fournisseur du bien ou du service.
Selon un autre mode de réalisation particulier, l’identifiant du lecteur ainsi que l’identifiant du module de contrôle de la transaction sont transmis à l’aide d’un mécanisme de chiffrement. Un tel mode de réalisation permet d’optimiser la sécurité de l’appairage entre le lecteur côté objet communicant et le module de contrôle de la transaction côté fournisseur du bien ou du service.
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é d’établissement d’une transaction défini ci-dessus.
L'invention concerne également un objet communicant pour l’établissement d’une transaction mettant en œuvre une fourniture d’un bien ou d’un service à un utilisateur, ledit objet communicant comprenant un processeur qui est configuré pour recevoir une requête contenant des données relatives à la transaction en provenance d’un dispositif de fourniture du bien ou du service ou d’un module de contrôle de la transaction associé audit dispositif.
Un tel objet communicant est remarquable en ce que le processeur de l’objet communicant met en œuvre ce qui suit :
- recevoir en provenance du module ou du dispositif, un message requérant si un lecteur d’un moyen d’accès à un service de mise en œuvre de la transaction est associé à l’objet communicant,
- un lecteur étant associé à l’objet communicant, lire des données d’identification d’un moyen d’accès au service, à l’aide du lecteur,
- transmettre les données d’identification lues au module logiciel de contrôle de la transaction pour valider la transaction.
L'invention concerne également un système d’établissement d’une transaction. Un tel système est remarquable en ce qu’il comprend :
- un objet communicant mettant en œuvre le procédé d’établissement d’une transaction précité,
- un module de contrôle de la transaction qui est associé à un dispositif de fourniture de bien(s) ou de service(s).
L'invention concerne encore un programme d'ordinateur comportant des instructions pour la mise en œuvre du procédé d’établissement d’une transaction 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é d’établissement d’une transaction 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 (« Read Only Memory » en anglais), par exemple un CD ROM (« Compact Disc Read-Only Memory » en anglais) 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 (« Solid State-Drive » en anglais). 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 un 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é d’établissement d’une transaction 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 1 représente un exemple d’architecture dans laquelle le procédé d’établissement d’une transaction selon l’invention est mis en œuvre,
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é d’établissement d’une transaction, selon un mode de réalisation particulier de l’invention,
La figure 4A représente un mode de réalisation d’une étape d’authentification mise en œuvre dans le procédé d’établissement d’une transaction selon l’invention, La figure 4B représente un autre mode de réalisation d’une étape d’authentification mise en œuvre dans le procédé d’établissement d’une transaction selon l’invention, La figure 5A représente un système d’établissement d’une transaction selon un premier mode de réalisation de l'invention,
La figure 5B représente un système d’établissement d’une transaction selon un deuxième mode de réalisation de l'invention,
La figure 5C représente un système d’établissement d’une transaction selon un troisième mode de réalisation de l'invention.
Description détaillée de modes de réalisation de l’invention
En référence à la figure 1 , est décrit un exemple d’architecture dans laquelle le procédé d’établissement d’une transaction selon l’invention est mis en œuvre. Selon cette architecture, un système d’établissement d’une transaction comprend :
- un objet connecté ou communicant OC associé à un utilisateur UT,
- un environnement EVF de fourniture de bien(s) ou de service(s) à l’utilisateur UT. On appelle objet communicant ou connecté OC 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, un tel objet communicant OC comprend un module COMo de communication radio sans fil courte ou moyenne portée, tel que par exemple Bluetooth, LTE (« Long Term Evolution » en anglais), WiFi, DSRC
(« Dedicated Short Flange Communication » en anglais), C-V2X (« Cellular Vehicle To Everything » en anglais), etc.
De façon particulièrement avantageuse, l’objet communicant OC est associé à un lecteur LECT qui est configuré pour lire des données d’identification d’un moyen MAST d’accès à un service de mise en œuvre de la transaction. Le moyen d’accès MAST peut-être un support physique porté par l’utilisateur UT (ex : carte bancaire, badge de transport, étiquette de livraison de colis, etc.) ou un support logiciel intégré à l’objet communicant OC (ex : carte de paiement dématérialisée, carte de transport dématérialisée, porte-monnaie électronique, etc.). Le lecteur LECT est par ailleurs configuré pour communiquer avec le module de communication COMo.
L’environnement EVF de fourniture de bien(s) ou de service(s) comprend quant à lui, de manière correspondante à l’objet communicant OC, un module COMF de communication radio sans fil courte ou moyenne portée, tel que par exemple Bluetooth, LTE, WiFi, DSRC, C-V2X, etc.
L’environnement EVF comprend en outre :
- un dispositif DF de fourniture d’un bien ou d’un service à l’utilisateur UT,
- un module MET d’enregistrement et de traitement de la transaction pour la fourniture de bien(s) ou de service(s),
- un module MCT de contrôle de la transaction associé au dispositif DF de fourniture de bien(s) ou de service(s).
Le module MCT de contrôle de la transaction est associé au dispositif DF de fourniture de bien(s) ou de service(s) et/ou au module MET d’enregistrement et de traitement de la transaction, en ce sens qu’il peut être soit intégré au dispositif DF de fourniture de bien(s) ou de service(s) ou au module MET d’enregistrement et de traitement de la transaction, soit situé dans un environnement de virtualisation mis à disposition du fournisseur du bien ou du service par un opérateur de télécommunications, selon par exemple la technologie MEC (« Mobile Edge Computing » en anglais).
Le module MCT de contrôle de la transaction, le dispositif DF de fourniture de bien(s) ou de service(s), le module MET d’enregistrement et de traitement de la transaction, sont configurés pour communiquer entre eux.
Le module MCT de contrôle de la transaction est par ailleurs configuré pour communiquer, à l’aide de tout type de communication adapté et via le module MET d’enregistrement et de traitement de la transaction, avec un environnement EGT de gestion de la transaction qui, dans l’exemple représenté, est symbolisé par un serveur SERV de gestion de la transaction. Bien entendu, il peut s’agir de plusieurs serveurs en réseau en fonction du type de transaction mise en œuvre. 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 configuré pour mettre en œuvre le procédé d’établissement d’une transaction qui va être décrit ci- dessous.
Un tel objet communicant comprend selon l’invention :
- un module de communication COMo 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.,
- une interface utilisateur IU configurée pour recevoir des informations en provenance de l’utilisateur UT ou restituer des informations à l’utilisateur sous forme textuelle, visuelle et/ou sonore : il peut s’agir par exemple d’un écran d’affichage, d’un clavier et/ou d’un haut-parleur intégré à l’objet communicant OC,
- un lecteur LECT du type précité qui comporte :
-- une partie matérielle HARD, telle que par exemple une ouverture apte à recevoir un moyen d’accès MAST, ainsi qu’éventuellement un clavier ou une interface avec le clavier de l’interface utilisateur IU, ou encore une surface de communication sans contact, par exemple de type NFC,
-- une partie logicielle SOFT apte à communiquer avec :
- un module d’authentification AUT qui est configuré pour authentifier le module MCT de contrôle de la transaction de l’environnement EVF de fourniture de bien(s) ou de service(s) avec lequel l’objet communicant OC souhaite mettre en œuvre la transaction,
- un module ACC d’accès à une mémoire MEMi qui contient des données d’identification de moyens d’accès MAST à un service de mise en œuvre de la transaction, dans le cas où de tels moyens sont envisagés sous forme numérique ou dématérialisée.
A titre d’exemples non exhaustifs, la partie logicielle SOFT du lecteur LECT peut être :
- un élément sécurisé (« Secure Element » en anglais) : cet élément sécurisé peut se présenter par exemple sous la forme d’une eSIM (« Embedded Subscriber Identification Module » en anglais) qui est fournie par un opérateur de télécommunications ou le fabricant de l’objet communicant OC ; - une application sécurisée par exemple du type SAM (« Secured Applications for Mobile » en anglais) proposé par la GSM Association (« Global System for Mobile Communications » en anglais).
Le lecteur LECT est associé à l’objet communicant OC en ce sens que la partie HARD du lecteur LECT peut être intégrée à l’objet communicant OC ou être une partie autonome qui est reliée à l’objet communicant OC par tout moyen de connexion adapté, filaire ou sans fil.
Sur la figure 2, la mémoire MEMi n’est pas obligatoirement contenue dans l’objet communicant OC afin de préserver les ressources mémoire de celui-ci. A cet effet, la mémoire MEMi peut être déportée dans un réseau de communication sécurisé, un nuage (« cloud » en anglais) sécurisé, etc. et est rendue accessible par l’objet communicant OC, au moyen du module ACC dédié à cet effet. En variante, la mémoire MEMi ou une partie de celle-ci pourrait être intégrée à l’objet communicant OC.
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é d’établissement d’une transaction 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 communication sans contact via le module COMo, les actions de lecture de données d’identification du moyen d’accès MAST via le lecteur LECT, les actions d’authentification à l’aide du module d’authentification AUT. Description d’un mode de réalisation d’un procédé d’établissement d’une transaction
On décrit maintenant, en relation avec la figure 3, le déroulement d’un procédé d’établissement d’une transaction exécuté par un objet communicant OC tel qu’illustré en figure 2.
Une telle transaction est établie lors d’une communication préalable sans contact entre l’objet communicant OC et le dispositif DF de fourniture de bien(s) ou de service(s) précité. L’objet de la transaction est par exemple un bien ou un service fourni par le dispositif DF de fourniture de bien(s) ou de service(s) à l’utilisateur UT de l’objet communicant OC.
En préalable au déroulement du procédé d’établissement d’une transaction 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(s) ou de service(s) et que l’établissement d’un canal de communication de façon sécurisée a été réalisé en S0 pour mettre en œuvre la transaction entre l’objet communicant OC et l’environnement EVF de fourniture de bien(s) ou de service(s). L’établissement d’un tel canal de communication sécurisée est mis en œuvre à l’aide des modules de communication COMret COMo illustrés à la figure 1 . 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é d’établissement d’une transaction se déroule alors comme suit.
Dans l’environnement EVF, le module MCT de contrôle de la transaction et/ou le module MET d’enregistrement et de traitement de la transaction vérifient en S1 que le dispositif DF de fourniture de bien(s) ou de service(s) est opérationnel.
En S2, le module de contrôle de la transaction MCT ou le dispositif DF de fourniture de bien(s) ou de service(s) envoie à l’objet communicant OC, via le canal sécurisé établi en S0, une requête REQ LECT demandant si l’objet communicant OC contient un lecteur LECT.
L’objet communicant OC reçoit la requête REQ_LECT en S3.
L’objet communicant OC contenant un tel lecteur LECT, une authentification mutuelle est alors exécutée en S4, via le module d’authentification AUT de la figure 2, entre le module MCT de contrôle de la transaction et le lecteur LECT. Une telle étape S4 est mise en œuvre en fonction de la nature plus ou moins sécurisée de la transaction.
Elle est donc optionnelle. Dans le cas d’une transaction du type paiement, l’étape S4 est obligatoire. Pour d’autres types de transaction, par exemple l’accès à un local non sécurisé, l’étape S4 peut être optionnelle.
En S5, le module MCT de contrôle de la transaction ou le dispositif DF de fourniture de bien(s) ou de service(s) envoie alors à l’objet communicant OC, via le canal sécurisé établi en S0, une requête REQ_TR contenant des données DAT relatives à une transaction. Il peut s’agir d’un message demandant à l’utilisateur UT de présenter son moyen d’accès MAST au lecteur LECT et/ou d’un message contenant le type de bien et/ou de service, sa valeur, son montant, etc.
L’objet communicant OC reçoit la requête REQ_TR en S6.
En S7, l’interface utilisateur IU est alors activée pour informer l’utilisateur UT sur le contenu des données DAT et demander à l’utilisateur UT d’interagir avec le lecteur LECT, via un moyen d’accès MAST disponible.
Au cours de cette interaction, le lecteur LECT lit en S8 des données d’identification IDMAST du moyen d’accès MAST.
Une telle lecture est mise en œuvre par exemple suite à une communication sans contact, par exemple NFC, entre le moyen d’accès MAST et le lecteur LECT.
Dans un autre exemple, une telle lecture est mise en œuvre suite à l’introduction du moyen d’accès MAST dans une ouverture dédiée du lecteur LECT et à la saisie éventuelle par l’utilisateur UT d’un mot de passe MP au moyen du clavier de l’interface utilisateur IU ou du clavier intégré à la partie matérielle HARD du lecteur LECT.
Selon encore un autre exemple, dans le cas où le moyen d’accès MAST est numérique ou dématérialisé, une telle lecture S8 est mise en œuvre suite à l’accès, via le module d’accès ACC de la figure 2, à ce moyen d’accès MAST, dans la mémoire MEMi de l’objet communicant OC.
En S9, l’objet communicant OC envoie au module MCT de contrôle de la transaction, via le canal sécurisé établi en S0, une réponse REP_TR à la requête REQ_TR, ladite réponse REP_TR contenant les données d’identification IDMAST du moyen d’accès MAST. En S10, le module MCT de contrôle de la transaction reçoit la réponse REP TR et la transaction est alors validée de manière classique sur la base des données d’identification IDMAST du moyen d’accès MAST qui ont été reçues, et en liaison avec l’environnement EGT de gestion de la transaction, via le module MET d’enregistrement et de traitement de la transaction.
Grâce au procédé d’établissement d’une transaction qui vient d’être décrit ci-dessus, l’invention permet, lorsqu’un utilisateur UT, disposant d’un objet communicant OC, est dans une situation de transaction avec un environnement de fourniture de bien(s) ou de service(s) EVF, de générer un assemblage d’un lecteur LECT du moyen d’accès MAST, associé à l’objet communicant OC, avec un module MCT de contrôle de la transaction qui est disponible dans l’environnement EVF de fourniture de bien(s) ou de service(s). Un tel assemblage a pour effet de reconstituer un terminal de transaction complet qui permet de réaliser la transaction.
De façon particulièrement avantageuse, un tel lecteur LECT peut servir à constituer une multitude de terminaux de transaction au gré des transactions réalisées par l’utilisateur auprès de différents fournisseurs de bien(s) ou de service(s). De façon symétrique, le module MCT de contrôle de la transaction qui est instancié dans un environnement EVF de fourniture de bien(s) ou de service(s) donné peut s’assembler avec une multitude de lecteurs LECT présentés par différents utilisateurs UT. La connexion d’un module MCT de contrôle de la transaction avec différents lecteurs LECT peut être simultanée pour permettre l’exécution de transactions en parallèle, ce qui n’est pas forcément le cas s’agissant de la connexion d’un lecteur LECT avec différents modules MCT de contrôle de transaction en simultané.
On décrit maintenant, en référence à la figure 4A, l’étape d’authentification mutuelle S4 précitée, selon un premier mode de réalisation de l’invention.
Dans l’exemple illustré, l’authentification est requise à l’initiative du module MCT de contrôle de la transaction. L’étape d’authentification S4 se déroule alors comme suit : En S40, le module MCT de contrôle de la transaction envoie au lecteur LECT, via le canal sécurisé établi en S0, une requête d’authentification REQ_AUT1 qui comprend un identifiant IDMCïdu module MCT.
L’étape d’envoi S40 peut être exécutée, par exemple suite à la réception d’un message de confirmation en provenance du lecteur LECT indiquant que l’objet communicant OC dispose d’un tel lecteur LECT. Selon un autre mode de réalisation, la requête REQ AUT1 pourrait être transmise simultanément à la requête REQ LECT envoyé en S2 (figure 3) demandant si l’objet communicant OC contient un lecteur LECT.
L’objet communicant OC reçoit la requête REQ_AUT1 en S41 .
En S42, le lecteur LECT vérifie si l’identifiant IDMCT reçu est valide. Si l’identifiant IDMCT reçu n’est pas valide, l’authentification échoue.
Si l’identifiant IDMCT reçu est valide, en S43, le lecteur LECT envoie à son tour au module MCT de contrôle de la transaction, via le canal sécurisé établi en S0, une requête d’authentification REQ_AUT2 qui comprend un identifiant IDLECïdu lecteur LECT.
Le module MCT reçoit la requête REQ_AUT2 en S44.
En S45, le module MCT vérifie si l’identifiant IDiECT reçu est valide. Si l’identifiant lÜLECT reçu n’est pas valide, l’authentification échoue.
Si l’identifiant IDiECT reçu est valide, en S46, l’authentification mutuelle entre le module MCT et le lecteur LECT est établie, ce qui permet de constituer un terminal de transaction réparti entre l’environnement de fourniture de bien(s) ou de service(s) et l’objet communicant OC.
Lorsque le niveau de sécurité de la transaction est bas, lors de l’étape S42 de vérification de l’identifiant IDMCT, le lecteur LECT vérifie que cet identifiant fait partie d’une liste d’identifiants préalablement stockés par exemple dans la mémoire MEMi de la figure 2 ou dans tout autre mémoire adaptée intégrée à l’objet communicant OC ou reliée à ce dernier. De manière correspondante, lors de l’étape S45 de vérification de l’identifiant IDLECT, le module MCT vérifie que cet identifiant fait partie d’une liste d’identifiants préalablement stockés dans une mémoire (non représentée) accessible par le module MCT dans l’environnement EVF de fourniture de bien(s) ou de service(s).
Lorsque le niveau de sécurité de la transaction est élevé, l’étape d’authentification mutuelle S4 utilise un mécanisme de chiffrement.
A cet effet :
- au cours de l’étape d’envoi S40 précitée, l’identifiant IDMCT du module MCT est transmis de manière chiffrée à l’aide d’une clé de chiffrement associée à un certificat numérique CERTMCT ; - au cours de l’étape d’envoi S43 précitée, l’identifiant IDLECïdu lecteur LECT est transmis de manière chiffrée à l’aide d’une clé de chiffrement associée à un certificat numérique CERTLECT.
De manière connue en soi, les certificats numériques CERÏMCTet CERTLECT sont délivrés par une autorité tierce de confiance et stockés respectivement dans une mémoire (non représentée) accessible par le module MCT dans l’environnement EVF de fourniture de bien(s) ou de service(s) et dans la mémoire MEMi de la figure 2 ou dans tout autre mémoire adaptée intégrée à l’objet communicant OC ou reliée à ce dernier.
On décrit maintenant, en référence à la figure 4B, l’étape d’authentification mutuelle S4 précitée, selon un deuxième mode de réalisation de l’invention.
Dans l’exemple illustré, l’authentification est requise à l’initiative du lecteur LECT de l’objet communicant OC. L’étape d’authentification S4 se déroule alors comme suit : En S40’, le lecteur LECT de l’objet communicant OC envoie au module MCT de contrôle de la transaction, via le canal sécurisé établi en S0, une requête d’authentification REQ_AUTT qui comprend un identifiant IDLECïdu lecteur LECT. L’étape d’envoi S40’ peut être exécutée par exemple suite à la réception S3 de la requête REQ_LECT demandant si l’objet communicant OC contient un lecteur LECT ou simultanément à l’envoi au module MCT d’un message de confirmation indiquant que l’objet communicant OC dispose bien d’un lecteur LECT.
Le module MCT reçoit la requête REQ_AUTT en S4T.
En S42’, le module MCT vérifie si l’identifiant lÜLECT reçu est valide. Si l’identifiant lÜLECT reçu n’est pas valide, l’authentification échoue.
Si l’identifiant lÜLECT reçu est valide, en S43’, le module MCT envoie à son tour au lecteur LECT, via le canal sécurisé établi en S0, une requête d’authentification REQ_AUT2’ qui comprend un identifiant lÜMCTdu module MCT.
Le lecteur LECT reçoit la requête REQ_AUT2’ en S44’.
En S45’, le lecteur LECT vérifie si l’identifiant lÜMCT reçu est valide. Si l’identifiant lÜMCT reçu n’est pas valide, l’authentification échoue.
Si l’identifiant lÜMCT reçu est valide, en S46’, l’authentification mutuelle entre le module MCT et le lecteur LECT est établie, ce qui permet de constituer un terminal de transaction réparti entre l’environnement EVF de fourniture de bien(s) ou de service(s) et l’objet communicant OC. Lorsque le niveau de sécurité de la transaction est bas, lors de l’étape S42’ de vérification de l’identifiant IDLECT, le module MCT vérifie que cet identifiant fait partie d’une liste d’identifiants préalablement stockés dans une mémoire (non représentée) accessible par le module MCT dans l’environnement EVF de fourniture de bien(s) ou de service(s). De manière correspondante, lors de l’étape S45’ de vérification de l’identifiant IDMCT, le lecteur LECT vérifie que cet identifiant fait partie d’une liste d’identifiants préalablement stockés par exemple dans la mémoire MEMi de la figure 2 ou dans tout autre mémoire adaptée intégrée à l’objet communicant OC ou reliée à ce dernier.
Lorsque le niveau de sécurité de la transaction est élevé, l’étape d’authentification mutuelle S4 utilise un mécanisme de chiffrement.
A cet effet :
- au cours de l’étape d’envoi S40’ précitée, l’identifiant IDLECT du lecteur LECT est transmis de manière chiffrée à l’aide d’une clé de chiffrement associée à un certificat numérique CERT’LECT ;
- au cours de l’étape d’envoi S43’ précitée, l’identifiant IDMCT du module MCT est transmis de manière chiffrée à l’aide d’une clé de chiffrement associée à un certificat numérique CERT’MCT.
De manière connue en soi, les certificats numériques CERT’LECT et CERT’MCT sont délivrés par une autorité tierce de confiance et stockés respectivement dans une mémoire (non représentée) accessible par le module MCT dans l’environnement EVF de fourniture de bien(s) ou de service(s) et dans la mémoire MEMi de la figure 2 ou dans tout autre mémoire adaptée intégrée à l’objet communicant OC ou reliée à ce dernier.
Description détaillée d’exemples d’applications de l’invention
On décrit maintenant en référence aux figures 5A à 5C, ensemble la figure 3, trois modes de réalisation différents de mise en œuvre du procédé d’établissement d’une transaction tel que décrit ci-dessus.
La figure 5A représente un système d’établissement d’une transaction selon un premier mode de réalisation, pour lequel la transaction est de type bancaire. Dans cet exemple, l’objet communicant OC est par exemple un véhicule, ici une voiture électrique connectée. A ce titre, la voiture OC 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 OC est dotée :
- d'un module COMo de communication radio sans fil courte ou moyenne portée, tel que par exemple Bluetooth, LTE, WiFi, DSRC, C-V2X, etc.,
- d’un lecteur LECT qui, dans l’exemple représenté, est configuré pour lire des données d’identification d’une carte de paiement MAST qu’elle soit physique ou dématérialisée.
Le lecteur LECT est embarqué dans le véhicule connecté OC. Sa partie matérielle HARD est partie intégrante de l'habitacle (zone matérialisée sur la planche de bord par exemple), ou ajoutée au véhicule (équipement en seconde monte). La partie HARD peut être aussi un équipement indépendant apporté par l’utilisateur UT et appairé avec le système d’information du véhicule. La partie logicielle SOFT est quant à elle mise en œuvre au sein de l'infrastructure de traitement informatique déployée dans le véhicule (système d'exploitation automobile et applications déployées sur celui-ci). Cette infrastructure offre les performances et la sécurité compatibles avec la norme de sécurité de l'industrie des cartes de paiement PCI DSS (« Payment Card Industry Data Security Standard » en anglais).
Le lecteur LECT peut exploiter l’interface utilisateur IU du système d’information du véhicule, par exemple utiliser l’écran de console intégré au tableau de bord, ainsi que les moyens de saisie offerts à l’utilisateur (écran tactile, molette pour interagir avec l’écran, commande vocale, etc...).
Dans l’exemple de la figure 5A, le dispositif DF de fourniture de bien(s) ou de service(s) 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.
Bien entendu, cet exemple n‘a rien d’exhaustif. En particulier, le dispositif DF de fourniture de bien(s) ou de service(s) varie en fonction du contexte d’utilisation de la voiture connectée OC. A cet effet, le dispositif de fourniture de bien(s) ou de service(s) DF pourrait être alternativement :
- une pompe à essence,
- un guichet de vente de nourriture à emporter, - un parcmètre,
- une barrière de péage,
- etc.
La borne de recharge DF communique dans l’environnement EVF de fourniture de bien(s) ou de service(s), via tout moyen de communication adapté, avec :
- un système de caisse MET,
- un kernel de paiement MCT.
La borne de recharge DF est également dotée d'un module COMF de communication radio sans fil courte ou moyenne portée, tel que par exemple Bluetooth, LTE, WiFi, DSRC, C-V2X, etc.
Le système de caisse MET est configuré pour enregistrer les transactions et initier une opération de paiement vers le kernel de paiement MCT.
Le kernel de paiement MCT est relié au système de caisse MET et doté d'une connectivité vers l'extérieur pour communiquer avec l’environnement EGT de gestion de la transaction, et en particulier avec le serveur BF de la banque du fournisseur de bien(s) ou de service(s), ici le gestionnaire de la station de rechargement. Ce serveur BF est ici une partie du serveur de gestion de transaction SERV, le serveur BF étant en communication avec le serveur RC du réseau de cartes bancaires qui lui-même communique avec le serveur BU de la banque de l’utilisateur UT.
Ce composant kernel peut être mis en œuvre de façon virtualisée, sous forme logicielle, hébergé par un opérateur de cloud ou télécom dans un environnement matériel et logiciel compatible avec la norme PCI DSS précitée.
Typiquement, le kernel de paiement est du type EMV (« Europay, Mastercard and Visa » en anglais).
Dans ce contexte de l’établissement de la transaction de l’invention, la voiture électrique connectée OC commence par s’appairer en S0 avec la borne de recharge DF, via les modules de communication MCOo et MCOF respectifs, afin d’établir un canal de communication sans contact sécurisé pour mettre en œuvre la transaction, ici un paiement correspondant à la recharge effectuée.
Le signal d’appairage réussi est alors transmis au système de caisse MET et au kernel de paiement MCT.
Le kernel de paiement MCT et/ou le système de caisse MET vérifient en S1 que la borne de recharge DF est opérationnelle. En S2, le kernel de paiement MCT ou la borne de recharge DF envoie à la voiture connectée OC, via le canal sécurisé établi en S0, une requête REQ LECT demandant si la voiture connectée OC contient un lecteur LECT.
La voiture connectée OC reçoit la requête REQ LECT en S3.
La voiture connectée OC contenant un tel lecteur LECT, une authentification mutuelle est alors exécutée en S4 entre le kernel de paiement MCT et le lecteur LECT, de manière à émuler un terminal de paiement de type TPE.
L’étape S4 peut être suivie d’une étape de pré-autorisation requise par le terminal de paiement ainsi émulé. A cet effet, en S5, le kernel de paiement MCT ou la borne de recharge DF envoie une requête REQ_TR à l’utilisateur UT lui demandant de présenter son moyen de paiement MAST, soit à l’aide d’un message sonore DAT délivré sur un haut-parleur dans la voiture, soit à l’aide d’un message textuel DAT qui s’affiche sur l’écran de la console.
La voiture connectée OC reçoit la requête REQ_TR en S6.
En S7, l’interface utilisateur IU est alors activée pour demander à l’utilisateur UT de présenter sa carte de paiement MAST au lecteur LECT.
Le lecteur LECT lit alors en S8 des données d’identification IDMAST de la carte de paiement MAST.
Dans le cas où la carte de paiement MAST est une carte à puce sans contact, par exemple de type NFC, l’utilisateur UT approche en S8 sa carte de la surface NFC du lecteur LECT. Afin d’augmenter le niveau de sécurité de la transaction, il peut être demandé à l’utilisateur UT de saisir un code secret MP sur le clavier de la console de la voiture OC.
Dans le cas où la carte de paiement à puce MAST n’est pas sans contact, l’utilisateur UT insère cette dernière dans une ouverture dédiée du lecteur LECT et saisit son code secret MP sur le clavier de la console.
Dans le cas où la carte de paiement MAST est virtualisée, une telle lecture S8 est mise en œuvre suite à l’accès, via le module d’accès ACC de la figure 2, à la carte de paiement virtualisée MAST, dans la mémoire MEMi de la voiture connectée OC. S’il existe plusieurs cartes virtualisées en mémoire, l’accès est exécuté suite à une sélection par l’utilisateur UT de la carte virtualisée à utiliser pour la transaction. En S9, la voiture connectée OC transmet au kernel de paiement MCT, via le canal sécurisé établi en S0, les données d’identification IDMAST. Le kernel de paiement réalise la demande de pré-autorisation auprès du serveur BU de la banque de l’utilisateur UT. Cette demande est traitée de façon classique, c’est- à-dire que la demande est acheminée du serveur BF de la banque de la station- service, via le serveur RC de réseau de cartes bancaires, jusqu'au serveur BU de la banque de l’utilisateur UT.
Dans le cas où l’autorisation est validée, le kernel de paiement MCT transmet un signal à la borne de recharge DF pour l'autoriser à fournir de l’électricité à la voiture connectée OC.
Une fois que le plein est effectué, le kernel de paiement MCT ou la borne de recharge DF communique le montant DAT à débiter à la voiture connectée OC, via le canal sécurisé établi en S0.
Le kernel de paiement MCT réalise le débit en S10 via les serveurs BU, RC et BF, puis transmet au lecteur LECT les informations de fin de transaction, pour affichage sur l'écran de la voiture connectée OC ou pour écoute via le ou les haut-parleurs de la voiture connectée OC.
La figure 5B représente un système d’établissement d’une transaction selon un deuxième mode de réalisation de l'invention, pour lequel la transaction est un contrôle d’accès à un local sécurisé ou non, un moyen de transport, etc. Ce deuxième mode de réalisation utilise des éléments communs à ceux de la figure 5A. Pour cette raison, ces éléments sont désignés avec les mêmes références.
Dans cet exemple, l’objet communicant OC est par exemple 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 OC 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 OC est dotée :
- d'un module COMo de communication radio sans fil courte ou moyenne portée, tel que par exemple Bluetooth, LTE, WiFi, DSRC, C-V2X, etc.,
- d’un lecteur LECT qui, dans l’exemple représenté, est configuré pour lire des données d’identification d’un badge de transport MAST qu’il soit physique ou dématérialisé. Le lecteur LECT est associé à la montre connectée OC. Sa partie matérielle HARD est partie intégrante du boîtier de la montre OC ou reliée à ce dernier. La partie logicielle SOFT est quant à elle mise en œuvre au sein du système d’exploitation de la montre OC.
Le lecteur LECT peut exploiter l’interface utilisateur IU de la montre (clavier, écran, haut-parleur, haptique (vibrations)).
Dans l’exemple de la figure 5B, le dispositif DF de fourniture de bien(s) ou de service(s) 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.
Le portillon DF communique dans l’environnement EVF de fourniture de bien(s) ou de service(s), via tout moyen de communication adapté, avec :
- un système MET d’enregistrement et de traitement de la transaction,
- un serveur de contrôle d’accès MCT.
Le portillon DF est également doté d'un module COMF de communication radio sans fil courte ou moyenne portée, tel que par exemple Bluetooth, LTE, WiFi, DSRC, C- V2X, etc.
Le système MET d’enregistrement et de traitement de la transaction est configuré pour enregistrer les transactions et initier une opération d’accès vers le serveur de contrôle d’accès MCT.
Le serveur de contrôle d’accès MCT est relié au système MET d’enregistrement et de traitement de la transaction et est doté d'une connectivité vers l'extérieur pour communiquer avec l’environnement EGT de gestion de la transaction, et en particulier avec un serveur SERV de gestion de la transaction qui est détenu par exemple par une régie de transport.
Dans ce contexte de l’établissement de la transaction de l’invention, la montre connectée OC commence par s’appairer en S0 avec le portillon DF, via les modules de communication MCOo et MCOF respectifs, afin d’établir un canal de communication sans contact sécurisé pour mettre en œuvre la transaction, ici un accès à un transport en commun.
Le signal d’appairage réussi est alors transmis au système MET d’enregistrement et de traitement de la transaction et au serveur MCT de contrôle d’accès. Le serveur MCT de contrôle d’accès et/ou le système MET d’enregistrement et de traitement de la transaction vérifient en S1 que le portillon DF est opérationnel.
En S2, le serveur MCT de contrôle d’accès ou le portillon DF envoie à la montre connectée OC, via le canal sécurisé établi en S0, une requête REQ LECT demandant si la montre connectée OC contient un lecteur LECT.
La montre connectée OC reçoit la requête REQ LECT en S3.
La montre connectée OC contenant un tel lecteur LECT, une authentification mutuelle conforme à l’invention est alors exécutée en S4 entre le serveur MCT de contrôle d’accès et le lecteur LECT, de manière à émuler un terminal de contrôle d’accès.
En S5, le serveur MCT de contrôle d’accès ou le portillon DF envoie une requête REQ_TR à l’utilisateur UT lui demandant de présenter son badge de transport MAST, soit à l’aide d’un message sonore DAT délivré sur le haut-parleur de la montre OC, soit à l’aide d’un message textuel DAT qui s’affiche sur l’écran de la montre. En complément ou alternativement, les données DAT peuvent contenir le type de la transaction, par exemple un identifiant de la ligne de transport et/ou un nombre de tickets à valider.
La montre connectée OC reçoit la requête REQ_TR en S6.
En S7, l’interface utilisateur IU est alors activée pour demander à l’utilisateur UT de présenter son badge de transport MAST au lecteur LECT.
Le lecteur LECT lit alors en S8 des données d’identification IDMAST du badge de transport MAST.
Dans le cas où le badge de transport MAST est une carte à puce sans contact, par exemple de type NFC, l’utilisateur UT approche en S8 son badge de la surface NFC du lecteur LECT. Afin d’augmenter le niveau de sécurité de la transaction, il peut être demandé à l’utilisateur UT de saisir un code secret MP sur le clavier de la montre connectée OC.
Dans le cas où le badge de transport MAST est dématérialisé, une telle lecture S8 est mise en œuvre suite à l’accès, via le module d’accès ACC de la figure 2, au badge MAST, dans la mémoire MEMi de la montre OC. S’il existe plusieurs badges de transport en mémoire, l’accès est exécuté suite à une sélection par l’utilisateur UT du badge à utiliser pour accéder au moyen de transport. En S9, la montre OC transmet au serveur MCT de contrôle d’accès, via le canal sécurisé établi en S0, l’identifiant IDiwxsTdu badge MAST.
En S10, le serveur de contrôle d’accès MCT décrémente un ou plusieurs tickets de transport numériques préchargé(s) dans le badge de transport MAST ou dans la mémoire MEMi de la montre connectée OC lorsque le badge MAST est sous forme dématérialisée. En variante, dans le cas d’un abonnement au moyen de transport, le serveur de contrôle d’accès MCT vérifie en S10 auprès du serveur de gestion SERV que l’identifiant IDiwxsTdu badge MAST est bien valide. Dans ce cas, le serveur de contrôle d’accès MCT commande l’ouverture du portillon DF pour laisser passer l’utilisateur UT, puis en commande la fermeture au bout d’une durée prédéterminée. La transaction est alors enregistrée dans le système MET d’enregistrement de la transaction qui communique les informations de cette transaction au serveur SERV. Le serveur de contrôle d’accès MCT transmet au lecteur LECT les informations de fin de transaction, par exemple le nombre de tickets utilisés, pour affichage sur l'écran de la montre connectée OC ou pour écoute via le ou les haut-parleurs de la montre connectée OC.
La figure 5C représente un système d’établissement d’une transaction selon un troisième mode de réalisation de l'invention, pour lequel la transaction est une commande de l’ouverture/fermeture d’un casier d’une boîte, borne ou armoire de retrait automatique de colis. Ce troisième mode de réalisation utilise des éléments communs à ceux des figures 5A et 5B. Pour cette raison, ces éléments sont désignés avec les mêmes références.
Dans cet exemple, l’objet communicant OC est par exemple 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 OC 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, le smartphone OC est doté :
- d'un module COMo de communication radio sans fil courte ou moyenne portée, tel que par exemple Bluetooth, LTE, WiFi, DSRC, C-V2X, etc., - d’un lecteur LECT qui, dans l’exemple représenté, est configuré pour lire des données d’identification d’une étiquette MAST de retrait d’un colis COL, telles que par exemple un code-barres ou un QR (« Quick Response » en anglais) code qui a été préalablement transmis au smartphone OC par l’enseigne qui a vendu la marchandise contenue dans le colis ou par le transporteur qui a acheminé le colis. Alternativement, l’étiquette MAST pourrait être une étiquette physique à la disposition de l’utilisateur UT et portant le code-barres ou le QR code précité.
La partie matérielle HARD du lecteur LECT est partie intégrante du smartphone OC. En variante, la partie matérielle HARD peut être un équipement que l’utilisateur UT connecte au préalable au smartphone OC, par une liaison filaire ou une connexion sans fil. La partie logicielle SOFT du lecteur LECT est quant à elle mise en œuvre au sein du système d’exploitation du smartphone OC.
Le lecteur LECT peut exploiter l’interface utilisateur IU du smartphone OC (clavier, écran, haut-parleur).
Dans l’exemple de la figure 5C, le dispositif DF de fourniture de bien(s) ou de service(s) 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.
La boîte de retrait DF communique dans l’environnement EVF de fourniture de bien(s) ou de service(s), via tout moyen de communication adapté, avec :
- un système MET d’enregistrement et de traitement de la transaction,
- un serveur MCT de commande d’ouverture/fermeture d’un casier.
La boîte de retrait DF est également dotée d'un module COMF de communication radio sans fil courte ou moyenne portée, tel que par exemple Bluetooth, LTE, WiFi, DSRC, C-V2X, etc.
Le système MET d’enregistrement de la transaction est configuré pour enregistrer les transactions, ici les retraits de colis, et initier une opération de retrait de colis vers le serveur MCT de commande de l’ouverture/fermeture d’un casier.
Le serveur MCT de commande de l’ouverture/fermeture d’un casier est relié au système MET d’enregistrement et de traitement de la transaction et doté d'une connectivité vers l'extérieur pour communiquer avec l’environnement EGT de gestion de la transaction, et en particulier avec un serveur SERV de gestion de la transaction qui comprend un serveur de gestion SEN appartenant à l’enseigne qui a vendu la marchandise contenue dans le colis COL, lequel serveur SEN communique avec un serveur de gestion STR appartenant au transporteur ayant acheminé le colis jusqu’à la boîte de retrait DF.
Dans ce contexte de l’établissement de la transaction de l’invention, à l’approche de l’utilisateur UT de la boîte de retrait DF, le smartphone OC commence par s’appairer en S0 avec la boîte de retrait DF, via les modules de communication MCOo et MCOF respectifs, afin d’établir un canal de communication sans contact sécurisé pour mettre en œuvre la transaction, ici une commande d’ouverture/fermeture d’un casier. Le signal d’appairage réussi est alors transmis au système MET d’enregistrement et de traitement de la transaction et au serveur MCT de commande de l’ouverture/fermeture du casier E contenant le colis COL à retirer.
Le serveur MCT de commande de l’ouverture/fermeture de casier et/ou le système MET d’enregistrement et de traitement de la transaction vérifient en S1 que la boîte de retrait DF est opérationnelle.
En S2, le serveur MCT de commande de l’ouverture/fermeture de casier ou la boîte de retrait DF envoie au smartphone OC, via le canal sécurisé établi en S0, une requête REQ_LECT demandant si le smartphone OC contient un lecteur LECT.
Le smartphone OC reçoit en S3 la requête REQ_LECT
Le smartphone OC contenant un tel lecteur LECT, une authentification mutuelle conforme à l’invention est alors exécutée en S4 entre le serveur MCT et le lecteur LECT, de manière à émuler un terminal de commande d’ouverture ou de fermeture de casier.
En S5 le serveur MCT ou la boîte de retrait DF envoie une requête REQ_TR à l’utilisateur UT lui demandant de présenter son étiquette de retrait MAST, soit à l’aide d’un message sonore DAT délivré sur le haut-parleur du smartphone OC, soit à l’aide d’un message textuel DAT qui s’affiche sur l’écran du smartphone. En complément ou alternativement, les données DAT peuvent contenir un identifiant, un logo ou un nom de l’enseigne de la boutique d’où provient le colis COL, le prix de la commande, un identifiant du casier qui contient le colis COL, etc.
En S7, l’interface utilisateur IU est alors activée pour demander à l’utilisateur UT de présenter son étiquette de retrait MAST au lecteur LECT.
Le lecteur LECT lit alors en S8 des données d’identification IDMAST de l’étiquette MAST, ici le code-barres ou le QR code. Dans le cas où l’étiquette MAST est un support physique, par exemple une feuille de papier, un autocollant ou autres, l’utilisateur UT approche en S8 l’étiquette MAST de la surface du lecteur LECT qui est adapté pour lire de tels codes.
Dans le cas où l’étiquette MAST a été transmise au smartphone OC, une telle lecture S8 est mise en œuvre suite à l’accès, via le module d’accès ACC de la figure 2, à l’étiquette MAST, dans la mémoire MEMi du smartphone OC. S’il existe plusieurs étiquettes stockées en mémoire, l’accès est exécuté suite à une sélection par l’utilisateur UT de l’étiquette MAST à lire.
En S9, le smartphone OC transmet au serveur MCT, via le canal sécurisé établi en S0, l’identifiant IDiwxsTde l’étiquette MAST.
En S10, le serveur MCT vérifie auprès du serveur STR du transporteur que l’identifiant IDiwxsTde l’étiquette MAST est bien valide. Cet identifiant étant valide, le serveur MCT commande l’ouverture d’un des casiers qui contient le colis COL, le casier E dans l’exemple représenté, puis une fois le casier E vidé, en commande la fermeture au bout d’une durée prédéterminée. La transaction est alors enregistrée dans le système MET d’enregistrement et de traitement de la transaction qui communique les informations de cette transaction aux serveurs SEN et STR. Le serveur de contrôle d’accès MCT transmet au lecteur LECT les informations de fin de transaction, par exemple le nombre de colis retirés, pour affichage sur l'écran du smartphone OC ou pour écoute via le ou les haut-parleurs du smartphone OC.

Claims

REVENDICATIONS
[Revendication 1] Procédé d’établissement d’une transaction à l’aide d’un objet communicant (OC) pour la mise en œuvre d’une fourniture d’un bien ou d’un service à un utilisateur, au cours duquel l’objet communicant reçoit (S6) une requête contenant des données relatives à la transaction en provenance d’un dispositif (DF) de fourniture du bien ou du service ou d’un module (MCT) de contrôle de la transaction associé audit dispositif, le procédé étant caractérisé en ce que l’objet communicant met en œuvre ce qui suit :
- recevoir (S3) en provenance dudit module ou dudit dispositif, un message (REQ_LECT) requérant si un lecteur d’un moyen d’accès à un service de mise en œuvre de ladite transaction est associé à l’objet communicant,
- un lecteur étant associé à l’objet communicant, lire (S8) des données d’identification d’un moyen (MAST) d’accès audit service, à l’aide dudit lecteur,
- transmettre (S9) les données d’identification lues au module de contrôle de ladite transaction pour valider la transaction.
[Revendication 2] Procédé d’établissement d’une transaction selon la revendication 1 , dans lequel avant ladite étape de lecture, le procédé met en œuvre une étape (S4) d’authentification mutuelle entre le lecteur associé à l’objet communicant et le module de contrôle de la transaction.
[Revendication 3] Procédé d’établissement d’une transaction selon la revendication 2, comprenant ce qui suit, au niveau du lecteur associé à l’objet communicant, lors de l’exécution de ladite étape d’authentification :
- recevoir (S41 ), en provenance du module de contrôle de la transaction, un identifiant dudit module,
- vérifier (S42) la validité dudit identifiant,
- ledit identifiant étant valide, transmettre (S43) un identifiant dudit lecteur au module de contrôle de transaction,
- l’identifiant dudit lecteur ayant été reconnu comme valide par le module de contrôle de la transaction, authentifier (S46) mutuellement le lecteur et le module de contrôle de la transaction.
[Revendication 4] Procédé d’établissement d’une transaction selon la revendication 2, comprenant ce qui suit, au niveau du lecteur associé à l’objet communicant, lors de l’exécution de ladite étape d’authentification :
- transmettre (S40’) au module de contrôle de la transaction un identifiant dudit lecteur,
- l’identifiant dudit lecteur ayant été reconnu comme valide par le module de contrôle de la transaction, recevoir (S44’), en provenance dudit module, un message contenant un identifiant dudit module,
- vérifier (S45’) la validité de l’identifiant dudit module,
- l’identifiant dudit module étant valide, authentifier (S46’) mutuellement le lecteur et le module de contrôle de la transaction.
[Revendication 5] Procédé d’établissement d’une transaction selon l’une quelconque des revendications 2 à 4, dans lequel l’identifiant du lecteur ainsi que l’identifiant du module de contrôle de la transaction sont transmis à l’aide d’un mécanisme de chiffrement.
[Revendication 6] Objet communicant (OC) pour l’établissement d’une transaction mettant en œuvre une fourniture d’un bien ou d’un service à un utilisateur, ledit objet communicant comprenant un processeur (PROC) qui est configuré pour recevoir une requête contenant des données relatives à la transaction en provenance d’un dispositif de fourniture du bien ou du service ou d’un module de contrôle de la transaction associé audit dispositif, caractérisé en ce que le processeur de l’objet communicant met en œuvre ce qui suit :
- recevoir en provenance dudit module ou dudit dispositif, un message requérant si un lecteur d’un moyen d’accès à un service de mise en œuvre de ladite transaction est associé à l’objet communicant,
- un lecteur étant associé à l’objet communicant, lire des données d’identification d’un moyen d’accès audit service, à l’aide dudit lecteur,
- transmettre les données d’identification lues au module de contrôle de ladite transaction pour valider la transaction.
[Revendication 7] Programme d'ordinateur comportant des instructions de code de programme pour la mise en œuvre du procédé d’établissement d’une transaction selon l’une quelconque des revendications 1 à 5, lorsqu'il est exécuté sur un ordinateur.
[Revendication 8] Support d'informations lisible par un ordinateur, et comportant des instructions d'un programme d'ordinateur selon la revendication 7.
[Revendication 9] Système d’établissement d’une transaction, caractérisé en ce qu’il comprend :
- un objet communicant (OC) selon la revendication 6,
- un module (MCT) de contrôle de la transaction qui est associé à un dispositif de fourniture de bien(s) ou de service(s).
EP22813331.0A 2021-11-26 2022-11-03 Procédé d'établissement d'une transaction entre un objet communicant et un module de controle de la transaction associé à un dispositif de fourniture de bien(s) ou de service(s) Pending EP4437479A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR2112578A FR3129757A1 (fr) 2021-11-26 2021-11-26 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)
PCT/FR2022/052072 WO2023094744A1 (fr) 2021-11-26 2022-11-03 Procédé d'établissement d'une transaction entre un objet communicant et un module de controle de la transaction associé à un dispositif de fourniture de bien(s) ou de service(s)

Publications (1)

Publication Number Publication Date
EP4437479A1 true EP4437479A1 (fr) 2024-10-02

Family

ID=80122792

Family Applications (1)

Application Number Title Priority Date Filing Date
EP22813331.0A Pending EP4437479A1 (fr) 2021-11-26 2022-11-03 Procédé d'établissement d'une transaction entre un objet communicant et un module de controle de la transaction associé à un dispositif de fourniture de bien(s) ou de service(s)

Country Status (4)

Country Link
US (1) US20250014034A1 (fr)
EP (1) EP4437479A1 (fr)
FR (1) FR3129757A1 (fr)
WO (1) WO2023094744A1 (fr)

Family Cites Families (10)

* 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
US7292999B2 (en) * 2001-03-15 2007-11-06 American Express Travel Related Services Company, Inc. Online card present transaction
FR2950768A1 (fr) * 2009-09-30 2011-04-01 Xiring Sa Systeme et procede de transaction securisee en ligne
US20110136429A1 (en) * 2009-12-04 2011-06-09 Gm Global Technology Operations, Inc. Vehicular wireless payment authorization method
KR102158055B1 (ko) * 2012-02-29 2020-09-21 모비웨이브 시스템즈 유엘씨 디바이스로 보안 금융 거래를 행하는 방법, 디바이스 및 보안 요소
US10592890B2 (en) * 2014-09-03 2020-03-17 Intel Corporation Methods and arrangements to complete online transactions
US10949830B1 (en) * 2016-02-16 2021-03-16 State Farm Mutual Automobile Insurance Company Merchant terminal for receiving payment from a vehicle
US20180365679A1 (en) * 2017-06-19 2018-12-20 Nxp B.V. Merchant authenication to vehicle based personal point of sale (ppos) device that provides for card present e-commerce transaction
WO2021065929A1 (fr) * 2019-10-04 2021-04-08 パナソニック インテレクチュアル プロパティ コーポレーション オブ アメリカ Station de charge, système de gestion de batterie et procédé de charge
US20220258639A1 (en) * 2021-04-27 2022-08-18 Atlis Motor Vehicles, Inc. Methods and Apparatus for Charging Station Identification, Authentication and Energy Delivery

Also Published As

Publication number Publication date
FR3129757A1 (fr) 2023-06-02
US20250014034A1 (en) 2025-01-09
WO2023094744A1 (fr) 2023-06-01

Similar Documents

Publication Publication Date Title
EP2455923B1 (fr) Serveur de transaction NFC
CA2971670C (fr) Procede de traitement d'une transaction a partir d'un terminal de communication
EP3113099B1 (fr) Conteneur de paiement, procédé de création, procédé de traitement, dispositifs et programmes correspondants
EP2873045B1 (fr) Entite electronique securisee pour l'autorisation d'une transaction
EP2950256B1 (fr) Méthode d'identification, dispositif et programme correspondant
WO2016034810A1 (fr) Gestion de ticket électronique
EP1709598A2 (fr) Dispositif transactionnel a pre-traitement anticipe
CA2946143A1 (fr) Procede de traitement de donnees transactionnelles, dispositif et programme correspondant
WO2008065271A2 (fr) Procede et systeme de retrait d'argent a l'aide d'un telephone mobile
EP1724720B1 (fr) Procédé de paiement de service d'affranchissement dans une machine de traitement de courrier en libre accès
EP4437479A1 (fr) Procédé d'établissement d'une transaction entre un objet communicant et un module de controle de la transaction associé à un dispositif de fourniture de bien(s) ou de service(s)
WO2008104704A1 (fr) Systeme de paiement electronique comportant un terminal mobile incorporant un porte-monnaie electronique et un serveur
EP3142054A1 (fr) Procédé de transmission de données, dispositifs et programmes d'ordinateur correspondants
EP2257936A1 (fr) Procede et systeme de distribution de billets de banque a partir d'un distributeur automatique de billets
EP3215991A1 (fr) Transaction simplifiee a l'aide d'un dispositif de paiement et d'un terminal de communication
EP1354288A1 (fr) Procede utilisant les cartes de paiement electroniques pour securiser les transactions
FR2962830A1 (fr) Serveur, terminal et procede de transaction securisee
FR2885246A1 (fr) Terminal nomade de transactions electroniques securise et systeme de transactions electroniques securise
FR3004276A1 (fr) Dispositif, systeme et procede de gestion partagee de droits a un titre
CA3161315A1 (fr) Procede et systeme, dispositif et terminal de paiement utilisant des donnees personnelles
WO2022269156A1 (fr) Procédé de communication sans contact entre un objet communicant et un dispositif de communication
CA2946145A1 (fr) Procedes de traitement de donnees transactionnelles, dispositifs et programmes correspondants
EP1371036A2 (fr) Systeme et methode de renouvellement de donnees d'identification sur un dispositif de transaction portatif
FR3067488A1 (fr) Procede de gestion d'identifiants de fidelite, procede de traitement de donnees de fidelite, serveur, dispositif de transaction et programmes correspondants
WO2007071573A2 (fr) Systeme de transactions securisees d'unites de valeur portees par des cartes

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: 20240603

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 ME 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)