EP4348459A1

EP4348459A1 - Method for processing a transaction, device and corresponding program

Info

Publication number: EP4348459A1
Application number: EP22734521.2A
Authority: EP
Inventors: Pierre Quentin; Arnaud DUBREUIL
Original assignee: Banks and Acquirers International Holding SAS
Current assignee: Banks and Acquirers International Holding SAS
Priority date: 2021-06-04
Filing date: 2022-06-03
Publication date: 2024-04-10
Also published as: WO2022254002A1; FR3123741A1; CA3220060A1

Abstract

The invention relates to a method for executing a transaction between a transaction implementation terminal (TProf) and a communication device (Dton) which is located near the transaction implementation terminal (TProf ). Such a method comprises a step of preparing (A10) the transaction to be executed within the transaction implementation terminal (TProf), thereby outputting a set of intermediate transaction execution data; a step of transmitting (A20) the intermediate transaction execution data to the communication device (Dton); and a step of executing (A30) the transaction by the communication device (Dton) using the at least one item of intermediate transaction execution data and at least one item of personal data (Sgn, PIN) of the user who holds the communication device (Dton), such execution thereby outputting an execution result that is transmitted (A40) to the transaction implementation terminal (TProf).

Description

DESCRIPTION

Title: transaction processing method, device and corresponding program.

1. Field of the invention

The invention relates to the field of securing computer processing. The field of the invention relates more specifically to the securing of processing carried out at least in part by means of two separate computer devices, respectively owned by two equally separate entities. The invention aims more particularly to secure the implementation of a processing of confidential data, for example during a transaction carried out between a device initiating the transaction and a device for executing, at least partially, the transaction. . The transactions referred to herein may be of various types, such as electronic signatures, access validations, payment transactions, data validation transactions.

2. Prior Art

Previously, when a transaction must be carried out for a beneficiary (i.e. merchant, notary, etc.), who is often a professional, this beneficiary requires the use, by a person (often a natural person), of a dedicated terminal to the deal. This terminal is used by the person to confirm the transaction that is carried out, for example by affixing a signature to this terminal or by entering a secret code, and this, often, after the insertion, in this dedicated terminal, of a transaction device owned by the user (payment card, access card).

This way of implementing transactions is problematic. On the one hand, it poses a problem of security of the data processed: there are few terminals really able to guarantee the security of the data provided by the user: both those provided by the transactional device (payment card, access card ) when it is inserted in the terminal of the professional beneficiary, than those entered by the user himself to confirm his authorization or his authentication, confirmation necessary for the implementation of the transaction. Among the terminals that guarantee this security, we can mainly think of payment terminals that comply with PCI standards.

However, due in particular to digitization, both of the economy and of the actions carried out in everyday life, more and more acts and transactions are carried out on terminals which are not necessarily secure on the one hand and which are not basically terminals provided or designed to carry out such transactions on the other hand. For example, for signing notarial deeds, it is more and more common to use digitized signatures, made by the user on a data entry tablet (such as Wacom™ for example) directly connected to the notary. Similarly, for the delivery of parcels, it is common to have to affix his signature on a deliveryman's terminal to validate the good reception of the parcel or the envelope which is delivered, and this without the user being aware or aware of the degree of security of the terminal presented to him. This is all the more true as the massive arrival of low-cost terminals, from production countries with little regard for the quality of manufacture or security (software and hardware) of the terminals sold, exposes more and more people to attempts at fraud or scams by ill-intentioned individuals: these individuals take advantage of the weak security of terminals in circulation to inject malicious applications into them, with the aim of obtaining personal or confidential data.

To these data security problems, we can also add recent problems related to health security: the use of devices provided by professional beneficiaries requires that the latter put in place protocols to ensure the safety of people. These protocols are often cumbersome and increase the time needed to implement the transaction. For example, in the case of a notary, the latter is obliged to clean the stylus used for the signature before use by any signatory. Similarly, the professional with a payment terminal, or a signature terminal for the delivery of letters or parcels, theoretically has the obligation to apply a disinfectant solution to the terminal between each customer. In practice, these obligations are not necessarily fulfilled and they add a feeling of health insecurity to the real presence of a certain transaction insecurity, depending on the situations encountered.

There is therefore a need to provide users with a method of carrying out a transaction which makes it possible to respond to the problems posed, while ensuring the security of the data exchanged.

Solutions have been proposed, particularly in the field of payment. For example, the document US10147094B2 pursues the objective of proposing a payment method based on the connectivity of a communication network to which a communication terminal of a user is connected, to allow this user to validate a transaction by entering a code personal identification associated with his communication terminal. The problem with this method is that it does not allow the use of a means of payment (eg credit card) to carry out the transaction with the professional (eg the merchant). The document US10127532B1, for its part, describes a method of carrying out a payment transaction in which the user's communication terminal is used to detect a payment intention and to implement the transaction. However, this method of transaction completion is based solely on the user's ability to want to initiate a payment transaction.

None of these solutions, however, solves both the problem of securing the implementation of the transaction from the point of view of the beneficiary professional (in particular, to return to the example of payment, so that the natural person merchant ensures that the user has the ability to carry out the transaction) while guaranteeing this user that the device used by the beneficiary professional is not unnecessarily exposed to confidential data (e.g. digitized signatures, confidential codes, etc.).

3. Summary of the invention

The invention has been made taking into account these problems of the prior art. More particularly, the present disclosure relates to a method of executing a transaction between a professional's transaction implementation terminal and a user communication device which is located near the transaction implementation terminal. professional transaction. Such a method comprises a step of preparing the transaction to be executed within the professional's transaction implementation terminal, delivering at least one intermediate transaction execution datum; a step of transmitting said at least one intermediate transaction execution datum to the user communication device; and a step of executing the transaction by the user communication device using said at least one intermediate transaction execution datum and at least one personal datum of the user who holds the user communication, said execution delivering an execution result transmitted to the transaction implementation terminal of a professional.

Thus, unlike the prior art, the professional is able to verify, during the construction, implementation and execution of the transaction, that the user has the capacity to and the means to complete this transaction. For his part, the user is able to ensure that the professional's terminal does not come into possession of personal information, in particular for example digitized signatures or passwords or confidential codes. According to a particular characteristic, the step of executing the transaction by the user communication device using said at least one intermediate transaction execution datum and at least one personal datum of the user which holds the user communication device comprises a step of obtaining, by the user communication device, at least one datum originating from an additional transactional device in the possession of the user.

Thus, the user is able to use his payment card directly on his communication terminal, in front of the merchant, who is able to verify that his customer is making a payment using this payment card.

According to a particular characteristic, the step of obtaining, by the user communication device, said at least one datum coming from the additional transactional device in the possession of the user comprises: a step of sending, by the device for user communication, of a request for obtaining transactional data, said transmitting step using a near-field communication interface of the user communication device; a step of reception, by the user communication device, of a response to said request for obtaining transactional data via the near-field communication interface of the user communication device.

Thus, the user's communication terminal plays an active role in the implementation of the transaction, by itself requesting the transactional data.

According to a particular characteristic, the step of executing the transaction by the user communication device using said at least one intermediate transaction execution datum and at least one personal datum of the user which holds the user communication device comprises: a step of receiving said at least one intermediate transaction execution datum by the user communication device; a step of dynamic configuration of the user communication device, as a function of said at least one intermediate execution datum, said step of dynamic configuration step comprising a step of execution, within a dedicated memory space of said device user communication, a validation application for the entering said at least one personal datum of the user who owns the user communication device; a step of reception, by the validation application, of at least one datum entered by said user; a validation step, by the validation application, of the transaction according to said at least one datum entered by said user and said intermediate data, delivering a validation result.

Thus, the user is able to enter the PIN code of his bank card, directly on his communication terminal.

According to a particular characteristic, after the validation step, by the validation application, of the transaction as a function of said at least one datum entered by said user and of said intermediate data, the method comprises: a step of transmitting said data intermediates and said validation result, to a transactional server to which the user communication device is connected via the validation application, a step of validation, by the transactional server, of said intermediate data and of said validation result , comprising a verification of the validation cryptographic operations carried out by said validation application; a step of transmitting, to the transaction implementation terminal of a professional, said transaction validation result, when verification of the validation cryptographic operations delivers a positive result.

Thus, the transaction is processed in complete security, for example via the banking server corresponding to the user's bank or that of the merchant, and this transaction can be processed immediately, without delay.

According to one particular characteristic, the step of preparing the transaction to be executed within the professional's transaction implementation terminal comprises: a step of obtaining, from an additional transactional device in the possession of the user, at least one encryption key intended to be transmitted to the user communication device; and a step of inserting, within said at least one intermediate execution datum, said at least one encryption key obtained. Thus, the user can also choose to insert his bank card into the merchant's payment terminal, when possible. The entry of the pin code of the bank card is still carried out on the user's communication terminal from data from his bank card, transmitted from the merchant's payment terminal, which is technically reassuring for the trader.

According to a particular characteristic, the step of transmitting said at least one intermediate transaction execution datum to the user communication device comprises: a step of activating a communication interface of the transaction implementation terminal d a professional, for transmission via a main channel; a step of transmitting, via the communication interface, a file comprising said at least one intermediate datum.

According to a particular characteristic, the communication interface activated for the transmission of the file comprising said at least one intermediate datum belongs to the group comprising: a sound interface, configured to transmit the file previously encoded in the form of an ultrasonic signal; a screen of a professional's transaction implementation terminal, configured to display the file previously encoded in the form of a two-dimensional code; a data transmission interface via a communication network, configured to transmit the previously encoded file in the form of a message. According to another aspect, the invention also relates to a system for executing a transaction, the system comprising a transaction implementation terminal of a professional and a user communication device which is located close to the professional's transaction implementation terminal. Such a system comprises means for preparing the transaction to be executed implemented within the professional's transaction implementation terminal, delivering at least one intermediate transaction execution datum; means for transmitting said at least one intermediate transaction execution datum to the user communication device; and means for executing the transaction implemented within the user communication device using said at least one intermediate transaction execution datum and at least one personal datum of the user who holds the user communication device, said execution delivering an execution result and means for transmitting the execution result to the transaction implementation terminal of a professional.

According to a preferred implementation, the various steps of the methods according to the invention are implemented by one or more software or computer programs, comprising software instructions intended to be executed by a data processor of an execution device according to the invention and being designed to control the execution of the various steps of the methods, implemented at the level of a communication terminal, of an electronic execution device and/or of a control device, within the framework a distribution of the processing to be performed and determined by a scripted source code and/or a compiled code.

Consequently, the invention also relates to programs capable of being executed by a computer or by a data processor, these programs comprising instructions for controlling the execution of the steps of the methods as mentioned above.

A 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 an information medium readable by a data processor, and comprising instructions of a program as mentioned above.

The information carrier can be any entity or device capable of storing the program. For example, the medium may include a storage medium, such as a ROM, for example a CD ROM or a microelectronic circuit ROM, or else a magnetic recording medium, for example a mobile medium (memory card) or a hard drive or SSD.

On the other hand, the information 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. The program according to the invention can in particular be downloaded from an Internet-type network.

Alternatively, the information carrier may be an integrated circuit in which the program is incorporated, the circuit being adapted to execute or to be used in the execution of the method in question.

According to an exemplary embodiment, the invention is implemented by means of software and/or hardware components. In this context, the term "module" may correspond in this document both to a software component, to a hardware component or to a set of hardware and software components.

A software component corresponds to one or more computer programs, one or more sub-programs of a program, or more generally to any element of a program or software capable of implementing a function or a set of functions, as described below for the module concerned. Such a software component is executed by a data processor of a physical entity (terminal, server, gateway, set-top-box, router, etc.) and is likely to access the hardware resources of this physical entity (memories, recording media, communication bus, electronic input/output cards, user interfaces, etc.).

In the same way, a hardware component corresponds to any element of a hardware assembly (or hardware) able to implement a function or a set of functions, according to what is described below for the module concerned. It can be a hardware component that can be programmed or has an integrated processor for executing software, for example an integrated circuit, a smart card, a memory card, an electronic card for executing firmware ( firmware), etc

Each component of the system described above naturally implements its own software modules.

The various embodiments mentioned above can be combined with each other for the implementation of the invention.

4. Brief description of figures

Other characteristics and advantages of the invention will appear more clearly on reading the following description of a preferred embodiment, given by way of a simple illustrative and non-limiting example, and the appended drawings, among which:

[fig 1] Figure 1 depicts a system in which the disclosure can be implemented;

[fig 2] figure 2 describes the general principle of the method that is the subject of the disclosure;

[fig 3] figure 3 illustrates an architecture of a professional electronic terminal capable of implementing a method that is the subject of the disclosure.

5. Description of an embodiment As indicated previously, the disclosure describes a method consisting in requiring, from a communication device of a user, the at least partial implementation of a transaction which must be carried out on behalf of an initiator (he can be a merchant, a notary, a delivery person, an access validation device, etc.), which has or implements a user communication device (payment device, signature, access control terminal, etc.), considered for various reasons as involving a security issue. In other words, a transaction execution dissociation technique is proposed: the transaction is initialized on a terminal of a professional and is completed (executed, finalized) on a terminal of a user, so that the latter ci can securely enter the confidential data used to validate this transaction.

Thus, in order to allow the professional to ensure the user's ability to carry out the transaction while allowing the user not to provide the professional with personal and/or confidential data, the method consists of using a communication terminal of the user (typically his smartphone or tablet type mobile communication terminal) to execute a portion of the transaction initiated by the professional's terminal. To do this, according to the present disclosure, the professional's terminal transmits specific data to the user's terminal, allowing the user terminal to continue the execution of the transaction. This continuation of the execution of the transaction can consist of a validation of the latter (for example by performing a signature operation and/or one or more cryptographic operations), or even in a verification of the validation of confidential data.

Be that as it may, the main problem in the proposed protocol modification consists in particular of: ensuring the security of the data exchanged (in order to avoid their interception); to ensure the non-repudiation of the data exchanged (in order to avoid any unwanted modification, both on the side of the professional's terminal and on the user's terminal). Indeed, it is essential that the protocol modification does not induce a security breach allowing the transaction to be modified.

Figure 1 describes a system in which the proposed technique can be implemented. Such a system (SystET) comprises a professional's terminal (TProf), the professional's terminal comprising transaction execution means. Such a terminal (TProf) is described in relation to FIG. 3. Such a system also comprises a user communication device (DTon), a physical device belonging to a user, and generally taking the form of a tablet or a smartphone, this device being portable and to the user's device when he is physically at the home or in the presence of the professional who uses the professional terminal (TProf). This system may also include, depending on the embodiment, a transactional server (ServT). The transactional server is in this case at least accessible via a communication network for the professional terminal (TProf) and/or the user communication device (DTon). Depending on the embodiments, the system also comprises an additional transactional device (DTa) (access card, credit card) in particular when the implementation of the transaction requires the use of such an additional transactional device (transaction to access premises, payment transaction by bank card, credit card).

Figure 2 describes the general principle of the method object of the disclosure. More particularly, the method for performing a transaction comprises: a step for preparing (A10) the transaction, implemented within the professional's terminal (TProf); this transaction preparation step includes, in particular, obtaining a (unique) identifier for the professional's terminal; this unique identifier serves as the basis for initializing the transaction (it is stored/obtained within the professional's terminal (TProf), or transmitted to the professional's terminal (TProf) via the transactional server (ServT)); this step of preparing the transaction can also include obtaining data from an additional transactional device (DTa) when such a device is necessary for carrying out the transaction (this step of obtaining data includes for example inserting a card in the user's possession into the professional's terminal or obtaining contactless data between this card in the user's possession and the professional's terminal); the preparation of the transaction may also include the generation of a unique (pre)transaction identifier, making it possible to trace and locate it; the set {“(unique) identifier of the professional's terminal”; “(pre)unique transaction identifier”} forms intermediate data (IntDat); they can be secured through encryption; the preparation of the transaction also includes, depending on the operational implementation, other steps, as explained in the embodiments below, which may include the implementation of other data to be transmitted to the communication device of user (DTon), these other data being added to the set of intermediate data (IntDat); intermediate data (IntDat) can be received, by the user communication device (DTon), either from the professional terminal (TProf) or via the transactional server (ServT); once the transaction has been prepared (to varying degrees, depending on the operational implementation), the user's user communication device (DTon) is dynamically configured (A20), using the set of intermediate data (IntDat), received on the user communication device (DTon) of the user; to then validate (A30) this transaction (eg execute/close it); the validation of the transaction includes, for the user, the interaction with an AppVT transaction validation application installed on his terminal: this interaction may include in particular the entry of one or more confidential data on the validation application of the transaction (digitized signature Sgn, confidential code PIN, etc.) and/or the use on the user communication device (DTon), of the additional transactional device (DTa) to obtain data from the latter , when such a device is necessary for carrying out the transaction (whether or not this additional transactional device (DTa), when such a device is necessary for carrying out the transaction, was used to prepare the transaction); the AppVT transaction validation application installed on the terminal is preferentially executed in a secure space of the memory of the user communication device (DTon) and preferentially this application is downloaded from a communication network only on request , as a function of the intermediate data received (ie the intermediate data received determine at least in part the configuration and the execution of the AppVT transaction validation application) and is executed immediately after downloading into the random access memory of the communication device of user (DTon); according to a variant, when the AppVT transaction validation application is already present (pre-downloaded by the user), the latter is configured according to the intermediate data received; preferentially, this AppVT transaction validation application blocks the use of the user communication device (DTon) by obtaining exclusive access to the execution resources of the user communication device (DTon) and limits the use of that -ci to input on the touch screen and optionally, to obtaining data via a near-field communication interface, when such an interface is necessary for the execution (validation) of the transaction ; configuring the transaction validation application AppVT is carried out according to the intermediate data received: the intermediate data make it possible to build a data structure loaded in RAM which constrains the execution of the transaction validation application, in particular in terms of communication interfaces to be used (ultrasound , camera, near field, WAN, WLAN): the operation of the application is simple and straightforward and allows entry, validation, correction and cancellation - cancellation for example causes the application to be closed and the unloading data from RAM; the AppVT transaction validation application is built by the manufacturer of the professional terminal (TProf) (or an affiliate or a partner) to meet the specific validation needs that this manufacturer wishes to address: the application will of course not be the even for a parcel receipt validation or for an access transaction validation or a payment transaction; The application implements cryptographic operations (which are described below) and in particular an encryption of the data entered by the user according to the intermediate data (which can include encryption keys) or according to the keys contained in the configuration of the application when the latter is downloaded and executed on the fly by the communication terminal.

Once the transaction has been validated, the user communication device (DTon) of the user communicates (A40) this validation information (InfoVal) to the professional's terminal (TProf), either directly, by transmitting validation data in direction to it, or indirectly, via the transactional server (ServT) which then communicates the validation data to the professional's terminal. When a transactional server is used (which is not mandatory), validation includes a step of transmitting intermediate data and the validation result to the transactional server to which the user communication device (Dton) is connected via the validation application (AppVT), then a step of validation, by the transactional server, of the intermediate data and of the validation result, comprising a verification of the cryptographic validation operations carried out by said validation (AppVT) and a step of transmitting, to a professional's transaction implementation terminal (TProf), the transaction validation result, when verification of the validation cryptographic operations delivers a positive result. These four steps, implemented in an orderly manner within the system presented in figure 1, make it possible to ensure both the security of the data entered by the user (these data are not provided as such to the professional), while assuring the professional, present at the time of the implementation of these steps, that the user is indeed able to carry out this transaction (ie that he has the capacity to do so and possibly the necessary tools, ie the du additional transactional device (DTa)). In addition, in a sensitive health context, this implementation prevents the user from coming into contact with the professional's equipment.

In relation to FIG. 3, a simplified architecture of a professional electronic terminal (TProf) capable of carrying out the transaction initiation processing as presented above is presented. A professional electronic terminal comprises a first electronic module comprising a memory 31, a processing unit 32 equipped for example with a microprocessor, and controlled by a computer program 33. The professional electronic terminal can also comprise a second electronic module comprising a secure memory 34, which can be merged with the memory 31 (as indicated in dotted lines, in this case the memory 31 is a secure memory), a secure processing unit 35 equipped for example with a secure microprocessor and physical measurement protection (physical protection around the chip, by trellis, vias, etc. and protection on the data transmission interfaces), and controlled by a computer program 36 specifically dedicated to this secure processing unit 35, this program computer 36 implementing all or part of the process for processing a transaction as previously described. The group composed of the secure processing unit 35, the secure memory 34 and the dedicated computer program 36 constitutes the secure module (PS) of the electronic device. In at least one exemplary embodiment, the present technique is implemented in the form of a set of programs installed in part or in whole on this secure portion of the transaction processing or initialization terminal. In at least one other exemplary embodiment, the present technique is implemented in the form of a dedicated component (CpX) capable of processing data from the processing units and installed in part or in whole on the secure portion of the electronic terminal of professional. Furthermore, the professional electronic terminal also comprises means of communication (CIE) for example in the form of network components (WiFi, 3G/4G/5G, wired) which allow the professional electronic terminal to receive data ( I) from entities connected to one or more communication networks and to transmit processed data (T) to such entities. Such a professional electronic terminal comprises, depending on the embodiments: means for obtaining data from transactional devices presented to users (access card, transaction card, etc.; these means may be presented, for example, in the form of a smart card reader, or even contactless card readers of the NFC type or of the RFID type); input means, allowing the professional to input one or more data for the implementation of the transaction, when necessary (physical input keyboard, screen, virtual input keyboard); means for processing the data obtained by the means for obtaining data from the transactional devices and means for processing the data entered by the professional; these means are materialized for example in the form of a specific component; means for processing a transaction, comprising means for initializing the transaction; means for supplying data to one or more transactional servers connected to the electronic professional terminal: these means are typically in the form of network communication interfaces, of the wired interface type (RTC, Ethernet) or wireless interface (3G/ 4G, Wi-Fi); means for supplying data to a device for implementing a transaction, belonging to a user (eg smartphone, tablet): these means for supplying data can take the form, for example, of a screen, on which these data are displayed, or even an ultrasound emission component (ultrasonic buzzer), or even a near-field radio data emission component;

As explained previously, these means are implemented by means of modules and/or components, for example, but not necessarily secured. They thus make it possible to ensure the security of the transactions carried out while guaranteeing greater maintainability of the device.

The user communication device (DTon), for its part, is generally presented as a mobile-type communication terminal (ie smartphone, tablet) which is in the possession of the user at the time of carrying out the transaction in the presence of the professional. Such device comprises, in addition to the usual means, means for implementing a transaction, according to the method previously described. These means are in the form of an application executed on the terminal, giving it the quality of user communication device (DTon). In a particular exemplary embodiment, this application is an application configured dynamically on the user's terminal. More particularly, this application is configured dynamically upon receipt, on the transaction implementation device, of intermediate data comprising the unique identifier of the professional's terminal and the unique (pre)transaction identifier and; when necessary, instantiation data. Upon receipt of this data, the application is dynamically configured and executed. It displays, for the user, the data relating to the transaction (such as for example an identifier or a name of the professional concerned or other as described in the following embodiments).

Several embodiments of the method that is the subject of the disclosure are described below Example of embodiment 1: delivery of a package by a deliverer

In this exemplary embodiment, the execution of a separate transaction in the context of a delivery of a parcel made by a deliverer (professional) to an individual (user) is described. The deliverer is equipped with an electronic delivery terminal (this is the professional's terminal). In this exemplary embodiment, once the administrative steps have been completed (i.e. verification of the user's identity by the delivery person, in particular, inspection of the state of the package by the user), the dissociated transaction processing process is implemented, according to the steps previously described in relation to Figure 2.

More specifically, in this embodiment: the preparation of the transaction by the terminal of the professional (delivery person) comprises obtaining the identifier of the terminal within a memory of this terminal of the professional and the preparation, by the processor processing, a transaction identifier; In addition, data representative of a location address (on the communication network or in an application store) of an instant application to be instantiated on the user's communication device (ie the mobile terminal or the tablet) of the user is obtained, for example within the memory of the professional's terminal, forming the set of intermediate data; A step for protecting at least some of these data is implemented: the identifier of the terminal and the transaction identifier are encrypted; From the set of intermediate data, a transmission file of these data is built ; the file for transmitting these data can take the form: of an image file, comprising a QR Code or ink of a modulated ultrasound sequence; The image file is displayed on the professional's terminal; the ultrasonic sequence is emitted from the professional's terminal (it should be noted that these two forms of transmission of information to the user communication device can be implemented simultaneously); The preparation of the transaction is thus finalized; In this exemplary embodiment, the QR-Code or the modulated ultrasonic sequence represents the main transmission channel for the intermediate data;

The user's communication device (the mobile terminal or the tablet) of the user receives the intermediate data file from the professional's terminal (either by reading the QR-Code, or by receiving the ultrasound sequence); The data is decoded (depending on the data encoding format used) and the user's user communication device (DTon) is configured (dynamic configuration): a request is transmitted by the user's device to the the location address of an instant application with the identifier data of the professional's terminal and transaction identifier as parameters; the instant application is immediately downloaded and executed on the user communication device (DTon); This instant application displays a user interface including: parcel information, obtained from a transactional server (ServT) of the delivery company (or another transactional server) and a signature zone (allowing the user to sign with his finger or with a stylus on the touch screen of his terminal) and a triplet of buttons (“cancellation”, “correction”, “validation”); This completes the end of the dynamic configuration of the user device;

This is followed by the validation step of the transaction, consisting of the user signing on the screen of his device (with a finger or with a stylus), then validating this entry by selecting the "validation" button. ; A message is displayed to the user to inform him of the entry;

Once this input/validation is performed by the user, the instant application performs a validation of the transaction by calculating a hash of the user's signature, encoding the image of the signature using a key , obtained for example from the hash produced, then by adding this data (hash of the signature, image of the signature) to the data intermediaries; The resulting data set is transmitted to the transactional server (ServT), and the instant application is uninstalled; The transactional server (ServT) receives the data transmitted by the instantaneous application and sends a message to the deliverer's terminal informing it of the validation of the transaction.

Thus, thanks to this implementation, the user was able to receive his package, while avoiding on the one hand entering sensitive information on the professional's terminal and on the other hand by securing the transmission of this data. , notably by means of encryption, to the transactional server. The user also did not need to come into physical contact with the professional's terminal, preserving health security. Also, no application is permanently installed on the user's device, the instantaneous application residing only in the volatile memory of the user's device.

Example of embodiment 2: access to premises protected by an access terminal This example of embodiment describes the execution of a dissociated transaction in the context of access to protected premises, via a an access terminal (professional terminal) with card, by a person wishing to access these premises (user). The professional's terminal is equipped with a smart card reader, which is used by the user to access the premises. The access terminal can be connected to a communication network (for example a mobile network) and it has data relating to the user (in particular a telephone number, which it can use to transfer a notification to the terminal of the 'user).

The dissociated transaction processing process is implemented, according to the steps previously described in relation to FIG. 2, after the request for access to the premises made by the user (for example by inserting his access card into the reader of the access terminal, or by any means usable on the access terminal, such as a physical button for example): the preparation of the transaction by the access terminal includes obtaining the identifier of the terminal access within a memory of this terminal and the preparation, by the processing processor, of a transaction identifier; In addition, if not already done, an access card insertion message is displayed to the user; the latter then inserts his access card into the smart card reader; the preparation of the transaction then continues with an interrogation of the access card by the access terminal, in order to obtain a public key of the access card in particular; this public key is inserted into the intermediate data set; the intermediate data set, after possible additional control operations (in particular control of the validity of the access card), is then encrypted using a private key of the access terminal; a file for transmitting these encrypted intermediate data is constructed, and the file is transmitted to the user's terminal via the communication network to which the access terminal is connected; In this exemplary embodiment, the communication network represents the main transmission channel for intermediate data; the user's device DTon receives the intermediate data file from the access terminal, for example via an SMS or another message transmitted over the communication network; The file data is decrypted using the public key of the access terminal (this public key was transmitted to the Dton device elsewhere, as explained below) and the user communication device (DTon) of the The user is dynamically configured: a PIN code entry application, with the data identifier of the terminal of the access terminal and transaction identifier as a parameter, is executed on the user communication device (DTon); This application displays a PIN code entry user interface including: access information, obtained from the intermediate data and a PIN code entry area (allowing the user to enter the PIN code of the credit card) he has inserted into the access terminal) and a triplet of buttons (“cancellation”, “correction”, “validation”); This input application is for example preinstalled by the user or else available natively on the user communication device (DTon); This completes the dynamic configuration of the user device;

This is followed by the transaction validation step, consisting of the user entering the PIN code on the screen of his device, then validating this entry by selecting the “validation” button; A message is displayed to the user to inform him of the entry; Once this entry/validation has been performed by the user, the application validates the transaction by performing an operation of encrypting the PIN code entered using the public key of the card present in the intermediate data received; this encrypted PIN is added to the decrypted intermediate data initially received and encryption of the whole is then carried out with the public key of the access terminal; All of the resulting data is transmitted to the access terminal, for example via an SMS type message, and the PIN code entry application is stopped; The access terminal receives the data transmitted by the application, decrypts it using its private key, verifies that the intermediate data is correct and transmits the encrypted PIN code to the smart card inserted in the card reader. access terminal chip; the user's smart card decrypts the PIN code using its private key and checks its validity: if the PIN code entered is valid, the smart card can form a certificate intended for the terminal d access in response to the validation request; the access terminal receives this certificate, verifies it and authorizes access to the premises.

Thus, thanks to this implementation, the user was able to access the premises protected by the access terminal, while on the one hand avoiding entering sensitive information on the access terminal itself. and on the other hand by securing the transmission of these data, in particular by means of encryption, to the access terminal. The user also did not need to come into physical contact with the access terminal, preserving health security.

For this implementation, it is assumed that the user's terminal has the public key of the access terminal, a key which is communicated to it separately. To do this, several variants are envisaged. A first variant consists in installing the public key of the access terminal when configuring the user's communication terminal: this configuration can be carried out by the authority which manages access to the premises protected by the access terminal. . This public key can be registered within a certificate which is installed in a protected memory area of the user's communication terminal. The advantage of this implementation is that it allows the authority managing access to protected premises to ensure that each user terminal is identified and that the public key of the access terminal does not circulate not unnecessarily.

A second variant consists in broadcasting the public key of the access terminal at the time of the implementation of the dissociated transaction. In this case, the public key of the access terminal is transmitted to the communication terminal of the user using a transmission channel different from that used for the transmission of the intermediate data. This transmission channel is called an auxiliary channel and it is used to secure the transmission of this public key. This auxiliary transmission channel can typically take the form of a modulated ultrasonic signal, the signal encoding a data record comprising on the one hand the public key of the access terminal (this public key can be a session key, temporary) and on the other hand a conformity verification data item. In this second variant, the method for transmitting this public key is as follows: when the user inserts his access card into the card reader of the access terminal, the access terminal, during the transaction preparation step, broadcasts, using the auxiliary channel (ie by ultrasound), the data record comprising the public key of the access terminal. This dissemination is only carried out after the access card has been inserted into the reader of the access terminal and the access terminal has checked the validity of this access card (for example that it not part of a banned list, or not disabled - too old). The user's communication terminal picks up this broadcast and acquires the data record comprising the public key of the access terminal and the compliance verification data. This broadcasting, by the access terminal, can be cyclical (that is to say be repeated), until the transmission, by the access terminal, of the intermediate data of the transaction to the communication terminal of the user (via the main channel, ie SMS or other type of transmission on the communication network). The advantage of this implementation is that it allows the access terminal to define temporary keys whose use is limited to a single transaction: in fact, the public key of the terminal is then a session key and the corresponding private key is also a session key. Moreover, the transmission of this key being initiated only from the moment when the user's access card is inserted in the reader of the access terminal, this key can be specifically dedicated to the access card. user access.

Depending on the variant embodiments, it may be envisaged to reverse the roles of the communication channels: the main channel may be the ultrasonic channel, used to transmit the intermediate transaction data and the secondary channel may be the communication network, used to transmit the public key of the access terminal.

Example of realization 3: payment using a payment terminal

We describe, in this exemplary embodiment, the execution of a dissociated transaction in the context of a payment, via a payment terminal (professional terminal) with a card, by a person wishing to make a payment of goods or services (user) at a merchant. The professional's terminal (payment terminal) is generally equipped with a chip card reader, the use of which is not necessary in the context of this embodiment. The payment terminal is connected to a communication network (for example a mobile network or the commercial communication network, eg Wifi network, Ethernet) and it may have data relating to the user (in particular a telephone number, in as part of a loyalty account, for example). Depending on the variants, the insertion of the user's payment card into the payment terminal may be required: in which case, the processing implemented are identical to the second exemplary embodiment and the chip of the payment card is used in the chip card reader of the payment terminal to carry out a payment transaction instead of an access transaction. In this third exemplary embodiment, the insertion of the payment card into the payment terminal is not necessary: the payment card is used by the communication terminal of the Dton user, as described below. .

The dissociated transaction processing process is implemented, according to the steps previously described in relation to FIG. 2, after the payment request made by the merchant (for example by requesting payment for goods or services from the user ): the preparation of the transaction by the payment terminal includes obtaining the identifier of the payment terminal (within a memory of this terminal or via the transactional server to which the payment terminal is connected, described below) and the preparation, by the secure processing processor of the payment terminal, of a transaction identifier; the preparation of the transaction also includes the addition, to the intermediate data, of purchase amount data, date, time, etc. ; the set of intermediate data, after any additional control operations, is then encrypted using a private key of the payment terminal; a file for transmitting these encrypted intermediate data is constructed, and the file is transmitted to the user's Dton terminal via the communication network to which the payment terminal is connected; In this exemplary embodiment, the communication network represents the main transmission channel for intermediate data; the user's Dton device receives the intermediate data file from the payment terminal, for example via an SMS or another message transmitted over the communication network; The file data is decrypted using the public key of the payment terminal (this public key was transmitted to the Dton device moreover, as explained in the second embodiment) and the user communication device (DTon ) of the user is dynamically configured: a payment transaction validation application (for example the user's banking application, preinstalled on his terminal), with as a parameter the data identifying the terminal of the payment terminal and pre- transaction identifier is executed on the user communication device (DTon); This application displays the transaction data to the user, as if the user were viewing the payment terminal screen; This input application is for example preinstalled by the user or else available natively on the user communication device (DTon); This completes the dynamic configuration of the user device;

This is followed by the validation step of the transaction, consisting for the user in:

Affix his payment card to the back of his communication terminal, which in this embodiment is a contactless card (NFC); this affixing leads to the reading of the bank card data on the user's communication terminal (card number, date, CVV, name) and triggers the display of a PIN code entry user interface comprising: the information relating to access, obtained from intermediate data and a PIN code entry zone (allowing the user to enter the confidential code of his payment card) and a triplet of buttons ("cancellation", "correction" , “validation”);

Enter the PIN code on the screen of his device, then validate this entry by selecting the "validation" button; A message is displayed to the user to inform him of the entry;

Optionally, affix his payment card again to the back of his communication terminal, so that the card checks the validity of the PIN code entered and provides a transaction certificate.

Once this entry/validation has been made by the user, the application validates the transaction by generating a transaction certificate using the bank card data, and depending on the number of times the card has been affixed to the back of the user's communication terminal; the transaction data and the transaction certificate are then transmitted to the transactional server;

The transactional server validates the transaction received from the user's communication terminal and transmits transaction confirmation data to the merchant's payment terminal;

The payment terminal receives the data transmitted by the transactional server: the merchant is then informed of the validation of the transaction. Thus, thanks to this implementation, the user was able to make payment for his purchases, while on the one hand avoiding entering sensitive information on the payment terminal itself (which as was mentioned above can be a simple communication terminal comprising payment functions for the merchant, such as communication terminals with additional card readers of the Square™ type, plugging into the communication terminal) and on the other hand securing the transmission of this data, in particular by means of encryption, directly to the transactional server, without going through the merchant's terminal. The user also did not need to come into physical contact with the merchant's terminal, preserving health security.

Example of embodiment 4: payment using a payment terminal As in the previous example of embodiment, the principle here again is to dissociate the execution of the transaction by using three separate entities, as explained previously. The method is again intended to make it possible to make a payment between a physical merchant (i.e. being in a shop) and a customer (user), who is also physically in the merchant's shop and who wishes to make a payment for goods or of the services it purchases.

The dissociated transaction processing process is implemented, according to the steps previously described, after the payment request made by the merchant (for example by requesting payment for goods or services from the user)

The payment terminal obtains, from the transactional server, data relating to the banking establishment with which the merchant is registered, in particular, an identifier linked to the payment terminal, from an account of the merchant;

The merchant's payment terminal transmits, to the Dton device, at least "one secure activation key" (or an activation key pair) which form the intermediate data, obtained in particular from the identifier linked to the payment terminal ; The transmission of this key is carried out, according to a first exemplary embodiment, via a signal transmitted from the merchant's payment terminal to the Dton device, which is physically next to the merchant (and his payment) (ie QR-Code or Ultrasound or “cloud transactional proxy, transactional server”, ie data transmission network); o The receipt of this (these) key(s), acting as intermediate data, leads to the activation of the AppV application on the user's communication terminal. This application is pre-installed by the user, or it is the application of his bank, or it is a single-use instant application, as in the case of the receipt of a package presented previously;

In addition to receiving the secure activation key, the AppV application of the user's communication terminal receives "the merchant's parameters", to be used to carry out the transaction (which include, for example, a "floor limit" ); o A "floor limit" is an amount, for example in euros, above which credit card transactions must be authorized (i.e. be authorized by the bank card network ). o in this embodiment, the transaction is required to be authorized by the network;

An acquisition mechanism (“acquiring service”) operates the transaction from a transactional merchant account server (therefore coming from the bank) in connection with the user's communication terminal and the AppV application, such as previously explained;

A clearing service identifies, from the transaction data obtained, a method that allows the transaction to be validated; the status of the transaction is communicated to the merchant's (payment) terminal and the credit (i.e. the amount of money) is posted to the merchant's bank account; This compensation mechanism is operated from a transactional server of the merchant's bank;

The merchant's terminal receives, from the transactional server that executed the transaction (i.e. the server implementing the compensation mechanism), a result of this transaction (in the form of an encrypted message). The result of the transaction is secured by the use of the activation key(s) which have been transmitted to the communication terminal by the payment terminal.

Thus, in this exemplary embodiment, the consolidated method implemented is as follows:

A (prior) subscription step is implemented by the merchant (optional for the user, in particular for Instant App on the client side);

The merchant selects the appropriate payment method on the payment terminal (and enters or receives the amount to be paid from the cash register); depending on the operational implementation conditions, the user can insert his card into the payment terminal (ie for example depending on the amount of the transaction to be executed); the mechanism implemented allows the customer to enter his PIN on his communication terminal;

The payment terminal receives information from the transactional server, in particular the identifier of the transaction and the key(s) for the transaction validation process; it requests this data from the transactional server;

The user's communication terminal application is activated (and downloaded or if it is an instant application) - the activation can be manual (start by the user or automatic (notification, i.e. application in background, with the data network of the communication terminal) or be subsequent to the transmission of information by the merchant's payment terminal (QR scanned by the user, on payment terminal screen ultrasound emitted from the buzzer payment terminal and received by the communication terminal, NFC). o At the same time as it is activated, the user's communication terminal application receives the transaction identifier and the key(s). (s) (either from the merchant's payment terminal or from the transactional server: when it is the transactional server, the latter is informed of the communication terminal via the identifier of the communication terminal of the user (for example his telephone number).

Based on the transaction identifier and the key (or keys), the user's communication terminal transmits a request for obtaining transaction data and payment parameters (from the merchant) to the payment mechanism. acquisition (in order to receive the floor limit in particular) of the transactional server; o The Dton device then has the amount to be paid and the identification of the merchant: this ensures that the information displayed on the merchant's terminal (and/or the cash register) is identical to that displayed on the communication terminal of the user; o In other words, the transactional server comprises means for determining the transaction identifier and means for generating the key to be able to exchange data in a secure manner with the communication terminal of the user on behalf of the merchant and has a backup of the merchant's settings, as associated with the latter's payment terminal; the additional advantage provided is that the merchant's terminal can be devoid of complex transaction processing functions, these complex functions being managed at the level of the transactional server on the one hand and of the user's communication terminal on the other hand;

Then, the application of the communication terminal carries out the implementation of the transaction (as explained in the second and third example embodiments). The communication terminal application and the transactional server complete the EMV transaction.

Then, payment network processing is implemented (card network): the transactional server transmits a transaction completion message to the clearing mechanism (which is responsible for transferring the amount of the transaction to the merchant's account); - The clearing mechanism transmits the transaction completion message to the merchant's payment terminal;

The transactional server also informs the application of the communication terminal that the transaction is completed.

Claims

1. Method for executing a transaction between a trader's transaction implementation terminal (TProf) and a user communication device (Dton) which is located near the transaction implementation terminal of the professional (TProf), method characterized in that it comprises a step of preparing (A10) the transaction to be executed within the professional's transaction implementation terminal (TProf), delivering at least one intermediate execution data transaction; a step of transmitting (A20) said at least one intermediate transaction execution datum to the user communication device (Dton); and a step of executing (A30) the transaction by the user communication device (Dton) using said at least one intermediate transaction execution datum and at least one personal datum (Sgn, PIN) of the user who holds the user communication device (Dton), said execution delivering an execution result transmitted (A40) to the professional's transaction implementation terminal (TProf).

2. Method according to claim 1, characterized in that the step of executing (A30) the transaction by the user communication device (Dton) with the aid of said at least one intermediate data execution of transaction and at least one personal datum (Sgn, PIN) of the user who holds the user communication device (Dton) comprises a step of obtaining, by the user communication device (Dton), at least one datum originating from an additional transactional device (DTa) in the possession of the user.

3. Method according to claim 2, characterized in that the step of obtaining, by the user communication device (Dton), said at least one datum coming from the additional transactional device (DTa) in possession of the user comprises: a step of sending, by the user communication device (Dton), a request for obtaining transactional data, said step of sending using a near field communication (NFC) interface of the user communication device (Dton); a step of reception, by the user communication device (Dton), of a response to said request for obtaining transactional data via the near field communication (NFC) interface of the communication device of user (Dton).

4. Method according to claim 1, characterized in that the step of executing (A30) the transaction by the user communication device (Dton) with the aid of said at least one intermediate data execution of transaction and at least one personal datum (Sgn, PIN) of the user who holds the user communication device (Dton) comprises: a step of receiving said at least one intermediate transaction execution datum by the user communication device (Dton); a step of dynamic configuration of the user communication device (Dton), as a function of said at least one intermediate execution datum, said step of dynamic configuration step comprising an execution step, within a memory space dedicated to said user communication device (Dton), a validation application (AppVT) for entering said at least one personal datum (Sgn, PIN) of the user who holds the user communication device (Dton); a step of reception, by the validation application (AppVT), of at least one datum entered by said user; a validation step, by the validation application (AppVT), of the transaction as a function of said at least one datum entered by said user and of said intermediate data, delivering a validation result.

5. Execution method according to claim 4, characterized in that after the validation step, by the validation application (AppVT), of the transaction according to said at least one datum entered by said user and said intermediate data, the method comprises: a step of transmitting said intermediate data and said validation result to a transactional server to which the user communication device (Dton) is connected via the validation application (AppVT) , a validation step, by the transactional server, of said intermediate data and of said validation result, comprising verification of the cryptographic validation operations performed by said validation application (AppVT); a step of transmitting, to a professional's transaction implementation terminal (TProf), said transaction validation result, when verification of the validation cryptographic operations delivers a positive result.

6. Execution method according to claim 1, characterized in that the step of preparing (A10) the transaction to be executed within the professional's transaction implementation terminal (TProf) comprises: a step of obtaining , from an additional transactional device (DTa) in the possession of the user, at least one encryption key intended to be transmitted to the user communication device; and a step of inserting, within said at least one intermediate execution datum, said at least one encryption key obtained.

7. Execution method according to claim 1, characterized in that the step of transmitting (A20) said at least one intermediate transaction execution datum to the user communication device (Dton) comprises: a step of activating a communication interface of the professional's transaction implementing terminal (TProf), for transmission via a main channel; a step of transmitting, via the communication interface, a file comprising said at least one intermediate datum.

8. Execution method according to claim 7, characterized in that the communication interface activated for the transmission of the file comprising said at least one intermediate datum belongs to the group comprising: a sound interface, configured to transmit the file previously encoded under the shape of an ultrasound signal; a screen of the professional transaction implementation terminal (TProf), configured to display the file previously encoded in the form of a two-dimensional code; a data transmission interface via a communication network, configured to transmit the previously encoded file in the form of a message.

9. System for executing a transaction, system comprising a trader's transaction implementation terminal (TProf) and a user communication device (Dton) which is located near the implementation terminal professional's transaction (TProf), system characterized in that it comprises means for preparing the transaction to be executed implemented within the professional's transaction implementation terminal (TProf), delivering at least one intermediate execution datum transaction; means for transmitting said at least one intermediate transaction execution datum to the user communication device (Dton); and transaction execution means implemented within the user communication device (Dton) using said at least one intermediate transaction execution datum and at least one personal datum (Sgn, PIN ) of the user who holds the user communication device (Dton), said execution delivering an execution result and means for transmitting the execution result to the professional's transaction implementation terminal (TProf).

10. Computer program product downloadable from a communication network and/or stored on a computer-readable medium and/or executable by a microprocessor, characterized in that it comprises program code instructions for the execution of a method of executing a transaction according to one of claims 1 to 8, when executed on a computer.