EP3405918A1

EP3405918A1 - Method for performing a bank transfer

Info

Publication number: EP3405918A1
Application number: EP17706530.7A
Authority: EP
Inventors: Jean-Luc Grimault; Franck GRUPELI; Pascal Peschet
Original assignee: Orange SA
Current assignee: Orange SA
Priority date: 2016-01-18
Filing date: 2017-01-13
Publication date: 2018-11-28
Also published as: WO2017125666A1; FR3046869A1

Abstract

The invention relates to a method for performing a transfer of units (TB) between a first entity (BA) and a second entity (BB) managing user accounts including respective value units, it being possible to command operations on the value units by devices including a first device (DA) and a second device (DB), characterised in that the method comprises the following steps, in the second device (DB), while performing of a transfer: a. a step of obtaining first data (DT), termed transaction data (DT), by the second device (DB); b. a step of transmitting, to the first entity (BA), a command to carry out the transaction, the command including all or part of the transaction data DT and second data (TK) obtained beforehand from the second entity (BB).

Description

Method of making a bank transfer

Technical area

The invention relates to a method for performing a transfer of value units between entities of a computer system. A transfer can concern a payment relating to a purchase, a donation, etc.

A unit can be money, points such as loyalty points, etc.

The entities in question manage the units of value and may effect unit transfers between them. These entities generally belong to financial institutions, especially banks.

State of the art

The exchange of value units, more specifically money, between user accounts currently rests mainly on three simple and known means: cash, check or transfer. The check has two major disadvantages:

- the money is not immediately available,

- the check may not be provisioned.

The transfer is little used in France. It is furthermore inconvenient, because of the need to enter the information elements of the bank account of the account of the user on which a banking operation must be performed, which is tedious. He must also enter the amount of the transfer and often the object, or even a reference of the transfer.

At the same time, telecommunication operators offer financial services that make it possible to transfer money between individuals via communication devices, typically smartphones. The techniques used are based on network signaling elements mobile. The general operation is in fact to transfer money from a first account linked to a first telephone number to a second account linked to a second telephone number. The accounts are managed by one and the same entity, namely the operator. But a current need is to make a transfer between different entities.

In addition, the money transfer implements both the donor and the receiver telephone number. However, for reasons of confidentiality, the donor or recipient may very well not wish to disclose his or her telephone number. The invention offers a solution that does not have the drawbacks of the state of the art.

The invention

For this purpose, according to a functional aspect, the invention relates to a method of realizing a transfer of units of value between a first entity and a second entity managing user accounts including units of respective values, operations on the units of values that can be controlled by devices including a first device and a second device, characterized in that it comprises the following steps, in the second device, when making a transfer: a. a step of obtaining first data, said transaction from the first device; b. a step of transmission to the first entity of a transfer realization order, the order including all or part of the transaction data and a second data previously obtained from the second entity.

The invention implements two devices belonging to users and two entities managing user accounts. In this system, the second device receives transaction data from the first device. The user of the second device does not have to enter data relating to the transaction. Then, the first entity transmits a transfer request to the second entity if it receives from the second device the transaction data, and another data, namely the data obtained from the second entity.

The method of the invention therefore offers the possibility of making transfers between entities in a simple manner, particularly for the user of the second device because the latter does not have data capture related to the transaction; and securely through the use of the data obtained from the second entity, hereinafter referred to as the "token".

Note that the transmission step to the first entity of a transaction realization order can be carried out directly or indirectly. In the latter case, the command can be received by the first device and transmitted to the first entity. According to a particular mode of implementation of the invention, which can be implemented alternately or cumulatively with the previous one, the received transaction data includes an address, and in that the command is transmitted to this address. This mode avoids the second device a step of sending a request to obtain the address that add an additional step in the process. The address in question is indifferently the address of the first entity or of an intermediate entity.

According to yet another particular embodiment of the invention, which can be implemented alternatively or cumulatively with the previous ones, the reception of the data by the second device triggers the step of transmitting an order for obtaining the the second data from the second entity. This mode makes it possible to automate the step of obtaining the second datum, namely the token, and thus to make the corresponding steps transparent.

According to another particular mode of implementation of the invention, which can be implemented alternatively or cumulatively with the previous, the step of obtaining the first data comprises a step of reading a code displayed on a screen of the first device. This mode prevents both the sender and the code receiver from disclosing their respective phone numbers. Indeed, the second device photographs the code displayed on the screen without having to provide its telephone number to the second device. Then, the read code can be transmitted to the first entity to obtain the code defined above. according to another functional aspect, the invention relates to a method of performing a transfer of units between a first entity and a second entity managing respective user accounts including respective value units, operations on the units of values. controllable by devices including a first device and a second device, characterized in that it comprises the steps on the first entity: a. a step of receiving a command for obtaining transaction data relating to a transfer to be made; b. a step of providing first data, said transaction, to the first device; vs. a step of receiving a realization order of the transfer, the order including all or part of the transaction data and a second data previously obtained by the second device from the second entity; d. a step of transmitting to the second entity all or part of the received transaction data, and the second data item for verification; e. a step of performing the transfer according to the verification.

According to a first hardware aspect, the invention relates to a device, said second device, comprising a communication module for communicating with a first entity and a second entity managing user accounts including respective units of values, a module of command capable of controlling a transfer of units between entities, characterized in that it comprises: a. a module for obtaining first data, called transaction data, from a first device, b. a control module adapted to transmit to the first entity a transfer realization order, the order including all or part of the transaction data and a second data previously obtained from the second entity.

According to a second hardware aspect, the invention relates to an entity, said first entity, able to communicate with a second entity for performing a transfer of units of value between user accounts including respective units of values managed by the entities respectively, operations on the units of value that can be controlled by devices including a first device and a second device, characterized in that it comprises c. a first receiving module adapted to receive a command for obtaining transaction data relating to a transfer to be made from the first device; d. a module for supplying first data, referred to as transaction data, to the first device; e. a second receiving module adapted to receive a transfer realization order, the order including all or part of the transaction data and a second data previously obtained by the second device from the second entity;

According to a third material aspect, the invention relates to a computer program capable of being implemented on the second device as defined above, the program comprising code instructions which, when the program is executed by a processor, performs the steps executed on the second device.

According to a third hardware aspect, the invention relates to a computer program capable of being implemented on an entity as defined above, the program comprising code instructions which, when the program is executed by a processor , performs the steps performed on the first entity.

The invention will be better understood on reading the description which follows, given by way of example and with reference to the appended figures in which:

FIG. 1 represents a computer system on which is illustrated an exemplary embodiment of the invention. This figure also shows the steps of an embodiment of the method of the invention.

Figure 2 is a schematic view of the various circuits included in the first device and the second device.

Detailed description of an exemplary embodiment illustrating the invention

FIG. 1 shows a SYS system comprising two data processing devices, namely a first device DA and a second device DB belonging respectively to two users, namely a first user UTA and a second user UTB; the set comprising the second device DB and the second user UTB is referenced UTDB.

The SYS system also includes two BA and BB representative entities of unit account managers, typically bank account managers, namely banks; these entities have physical and software resources capable of making bank transfers between CA and CB bank accounts, in particular between the CA and CB bank accounts of the UTA and UTB users, respectively. Entities BA and BB are generally respective computer systems including several servers connected to each other for making bank transfers during a bank transaction. To simplify the presentation, the two entities BA and BB will be illustrated by means of two servers, respectively.

In a manner known per se, the devices and servers have the hardware architecture of a computer that is to say having resources for data processing, namely at least one processor, a read-only memory, a random access memory and means of communication. Figure 2 is a view of the architecture of the two devices. To simplify the presentation, only certain circuits described below are shown in the figure.

The DA and DB devices respectively include CPUA and CPUB processors, MEMA and MEMB ROMs, I / OA and I / OB outputs for communicating with a RES1 network such as the internet network without being limited thereto. This network will be used in our example of communication realization during steps ET1, ET2, ET3, ET5, ET7, ET8 and ET9 which will be described below.

In our example, the read-only memories include respective computer programs including instructions for executing process steps with reference to FIG.

In our example, the CPUA processor of the first device DA is connected to a rendering module RST for the return of a digital code such as a bar code as will be explained below; the rendering module is a screen. The invention is not limited to this type of rendering module but to all other rendering means such as a transmitter of its ability to emit a signal representative of a code.

The CPUB processor of the DB device is able to communicate with a processing module TRT connected to a CPT signal receiving module such as means of shooting; the receiving module is for example a camera.

Figure 1 illustrates an embodiment of the method of the invention. This mode comprises several steps referenced ETn. In this figure, a step ETn implementing a data exchange is symbolized by an arrow having an origin and an end, the origin being associated with the sender of a message, the end being associated with the recipient of the message. Also, the steps that do not implement a communication but an internal processing are referenced in the device concerned by the processing; these steps are steps ET4 and ET6.

In this mode, a particular user (who could also be a merchant) UTA wants to receive money from a particular UTB user.

During a first step ET1, the user UTA requires from his bank BA, by sending an order, or from an intermediary of the bank, the creation of the so-called transaction data related to a transfer to achieve.

The transaction data contain data that will later allow the bank's BA server to recognize the transfer, in case of receipt of a request for validation of a transfer. The transaction data therefore contain at least one NUM information identifying the transfer in progress. The data may comprise other information such as a URL (Uniform Resource Locator) address in the case where the issuer of the validation request does not know the address of the BA server. Note that, as above, this URL may be the address of the server BA or another server for example that of an intermediary of the bank.

Recall that a URL is a universal naming format for a resource on the Internet. This address is an ASCII character string including useful information allowing software to access a resource on the network RES1 namely the Internet. In our example, the transaction data also includes an amount K € (K designating any value), a name designating the user UTA, the object OBJ of the transaction, optionally other information as a sponsor if it is is a gift, etc. In a second step ET2, the first server BA, or an intermediary of the server BA, responds by providing the device DA transaction data DT (URL, NUM, K €, A, OBJ, DAT) including the address of URL type, a NUM transaction number, the amount K €, the name designating A, the object OBJ of the transaction, a date of expiry DAT of the transaction, date beyond which the transaction can not be realized.

In our example, the set of transaction data DT are encoded by means of a barcode, designated by the expression "QR Code" in the remainder of the description. Any QR code technology can be used, such as ISO / IEC 18004: 2006 compliant codes, Datamatrix codes, Aztec codes, or any other equivalent code.

Recall here that a bar code, or barcode, is the representation of a numeric or alphanumeric data in the form of a symbol consisting of bars and spaces whose thickness varies according to the symbology used and encoded data. There are thousands of different barcodes; these are intended for automated reading by an electronic sensor, the barcode reader. The QR code (Anglo-Saxon Quick Response) is a type of two-dimensional bar code (or datamatrix matrix code) consisting of black modules arranged in a square with a white background. The arrangement of these points defines the information contained in the code. In a third step ET3, after receiving the data set, the first device DA makes the QR code available to the user UTB; this provision can be various, for example:

by sending an email to the user UTB on a device of the user UTB other than the second device DB, a computer for example, by sending an email transmitted to the DB device itself,

- by displaying the QR code on a screen accessible to the UTB user,

- by printing on a paper medium accessible to the UTB user or sent by paper mail to the UTB user, - etc.

In FIG. 1, the end of the representative arrow of the third step ET3 points to the set UTDB meaning that the provision is made indifferently for the second device DB or for the user UTB. This set may include other devices such as the computer referred to above with reference to the first example of provision described above.

During a fourth step ET4, regardless of the mode of the provision of the QR code to the user UTB, the received QR code is analyzed by the second device DB.

As indicated above, the receipt of the QR code can be done in several ways, including by capture or by sending an email.

If the chosen mode is capture, the second DB device captures the image of the QR code. The second device DB may be for example a smartphone with a camera; the captured QR code is then analyzed.

If the chosen mode is the email, the QR code is received directly on the second DB device in step ET4; in this case, there is no actual graphic capture phase, but only a content analysis phase.

The ability to analyze the content of a QR code can be basic in the second DB device or provided by a dedicated computer application installed in memory of the DB device.

Incidentally, the application on the second device DB displays information about the current transaction. For example, are displayed the amount K € of the transaction, the name of the user UTA, the object OBJ of the transaction and possibly other information related to the transaction. This display allows the UTB user to be informed of the details of the current transaction. At this point, the UTB user can validate the displayed data. According to one variant, the method does not require validation at the second device DB.

During a fifth step ET5, following the analysis of the QR code, and possibly following the validation made by the user UTB, the second device DB connects to the server BB to request data called "token" (token in English) in this text. This TK token will allow the continuation of the realization of the transfer.

This connection phase between the second device DB and the second server BB can be carried out by a request of the type http (English acronym of HyperText Transfer Protocol) or HTTPS (Anglo-Saxon name of HyperText Transfer Protocol Secure).

Also, preferably, before a communication with the second server BB, the user UTB authenticates with the server BB. The authentication mode is arbitrary. A mode will be described in the following description without being limited to it.

In the request transmitted to the server BB, the second device DB transmits the transaction data DT contained in the QR code or only a part of this data. In our example, the set of transaction data DT are transmitted to the server BB accompanied for example by an identifier linked to the device DB, and therefore indirectly to the user UTB.

Optionally, so as to secure this fifth step ET5, in addition to the authentication already performed, the second server BB may require a personal code entry (example 4 digits) and / or a password by the second DB device. This additional security can be justified, for example, with regard to the amount K €, the beneficiary UTA or the object OBJ of the transaction displayed on the screen of the smartphone.

In a sixth step ET6, the second server BB generates a token TK and associates it with the transaction data DT in progress; the second server BB keeps this association (TK / DT) in memory. The created TK token is a unique reference created for the current transfer.

Preferably, this token TK, or more generally the association created, has a lifetime limited in time. In a seventh step ET7, the second server BB returns the token

TK to the DB device; preferably the sending of this token TK is secure; the HTTP (S) protocol can be used for this purpose.

During an eighth step ET8, the second device DB then connects to the server BA through the URL encoded in the QR code. All or part of the DT transaction data contained in the QR Code is transmitted. The second device DB also transmits, simultaneously or independently in a separate message, the token TK. This connection phase is typically performed by an HTTP (or HTTPS) request.

Recall that the URL is the address provided by the first server BA and that this URL may be the address of the server BA or that of another server for example that of an intermediary of the bank.

During a ninth step ET9, the two servers BA and BB then communicate and interact to validate the transfer. During this interaction, the token TK and the transaction data DT are transmitted from the server BA to the server BB; allowing the server BB to verify that the token TK is the one that was emitted in step E7 and that the received association exists: for this the second server BB verifies that the transaction data DT associated with this token TK are correct , in particular that they conform to the values of the data DT validated by the user UTB on the second device DB during from step ET4 and received from the DB device during step ET6; for example the second server BB verifies in the transaction data DT, the name of the beneficiary A, the amount K € and the OBJ object of the transaction.

The server BB also checks, in the case where a lifetime has been defined, if it has expired. If yes, the transfer is not validated. If not, the process continues.

If the verification proves positive, the transfer of money is validated. Depending on the use case, the first device DA can be notified; At this moment, if the object of the transaction is the sale of a good, the merchant may return the purchased object; if the object of the transaction is a donation, the second server BB can proceed to the donation.

The security of the verification is based on the fact that the TK token is a single-use reference composed of a byte string and generated by the second BB server for the transaction. In our example, this token TK is known only from the server BB. In addition, if a malicious third party wanted to associate this TK token with other (wrong) transaction data when the ET8 step is raised, the verification by the second BB server in step ET9 would invalidate such fraud: the second server BB would indicate that the association does not match the association stored by the second server BB in step ET6.

In step ET8, remember that the second device DB connects to the BA server through the URL encoded in the QR code and that are transmitted all or part of DT transaction data contained in the QR Code. According to a variant, the transmission of all or part of the transaction data DT contained in the QR Code and the token TK can be made to the first server BA by means of a second QR code. In this variant, the second QR code is a concatenation of all or part of the transaction data DT contained in the first QR Code and the TK token; this second code is generated for example by the second server BB and transmitted to the DB device; generated by the second DB device itself (also by concatenation of DT data and TK token), or any other device connected to the second DB device. Then, the second device DB displays on its screen this second QR code which is read by a reader of QR codes, for example a reader installed on the first device DA of the user UTA; the first device DA then transfers this second QR code to the server BA. In this configuration, the step of transmitting to the first entity of a transaction realization command is carried out indirectly; the command being received by the first device DA and then transmitted to the first server BA.

According to a preferred embodiment, the second server BB is a transaction server belonging to a telecommunication operator managing a plurality of subscriptions including the subscription of the device DB. Remember that a subscription subscribed with an operator allows the use of the telecommunication network managed by this operator. In this configuration, the operator, upon receipt of the HTTP request received from the DB device via the network, identifies the concerned subscription linked to the device DB, or more precisely linked to a security module present in the second device DB such that a SIM card (acronym for Subscriber Identity Module). The operator thus provides an additional guarantee by his knowledge of the user at the origin of the request during step ET5, ensuring secure authentication. Ultimately, the issuance of the TK token to the second DB device will be transmitted after authentication.

According to another embodiment, the second server BB is a transaction server that is not managed by a telecommunication operator. In this other mode, the HTTP (or HTTPS) request of the step ET5 is transmitted to a server of the telecommunication operator, capable of guaranteeing the identity of the user at the origin of the request. The HTTP (or HTTPS) request is then processed by the operator's server to add a parameter guaranteeing the origin of the request, typically by adding an element identifying the user UTB. This request thus completed (or put in a form other than HTTP) is then transmitted by the operator server to the second server BB. According to another embodiment, the authentication performed in step ET5 may be based on a particular use of the personal code or the password. In this other mode, a program installed in a memory of the DB device uses a cryptographic mechanism to encrypt the data to be transmitted to the second server BB. The program is for example an AES type encryption function operating with a 256-bit (or 128-bit) key. The AES encryption function uses a 256-bit intermediate key (or 128, we will choose 256 bits later) stored in the same encryption software. This intermediate key is known to the BB server who also knows the personal code of the client.

This intermediate key is usually installed beforehand on the second DB device.

This embodiment with encryption of the personal code comprises the following steps: Client B enters his personal code. The personal code is then combined with the intermediate key by the encryption function; the following mathematical operation is performed between the intermediate key and the personal code:

[256-bit middle key] Xor [256-bit reformatted personal code]

Xor being the "or exclusive" function.

This operation results in an encryption key.

Then, the set including the QR Code master data and the client ID are encrypted by the AES encryption function in the second DB device with the encryption key. Thus encrypted, the whole thing is then sent to the server BB accompanied by the UTB client identifier. The second server BB then finds the client's encryption key with the UTB client identifier. It decrypts the received encrypted data namely the set

{[the QR Code master data] and the client ID} encrypted with the encryption key.

If the decryption gives {[QR Code master data] + client ID} and the [QR Code master data] is understandable, the second BB server generates and sends the requested TK token to the DB device. This other mode provides additional security because, to validate the transaction at the BB server and obtain a TK token, it is necessary at the same time necessarily:

- that the second device DB has the intermediate key in its software AES - know the personal code of the user UTB.

Thus, the unfortunate disclosure of the UTB client identifier and its personal code will not suffice for a malicious third party to obtain a TK token. It will be necessary that the malicious third party also has the intermediate key in its device. It should be noted here that the term module can correspond to a software component as well as a hardware component or a set of hardware and software components, a software component itself corresponding to one or more computer programs or subprograms. more generally, any element of a program capable of implementing a function or a set of functions as described for the modules concerned. In the same way, a hardware component corresponds to any element of a hardware set (or hardware) able to implement a function or a set of functions for the module concerned (integrated circuit, smart card, memory card, etc.) -

Claims

A method of performing a transfer of value units (TB) between a first entity (BA) and a second entity (BB) managing user accounts including respective value units, operations on the controllable units of values by devices including a first device (DA) and a second device (DB), characterized in that it comprises the following steps, in the second device (DB), when making a transfer: a. a step of obtaining (ET3, ET4) first data (DT), said transaction from the first device (DA); b. a step of transmission (ET8) to the first entity (BA) of a transfer realization order, the order including all or part of the transaction data (DT) and a second data item (TK) previously obtained from the second entity (BB).

Method of performing a transfer of units according to claim 1, characterized in that the transaction data (DT) received include an address (URL), and in that the command is transmitted to this address (URL).

A method of performing a transfer of units according to claim 2, characterized in that the address (URL) is the address of the first entity (BA).

A method of performing a transfer of units according to claim 1, characterized in that the reception of the data by the second device (DB) triggers the step of transmitting a command to obtain the second data (TK) with the second entity (BB).

A method of performing a transfer of units according to claim 1, characterized in that the obtaining step comprises a step of reading a code (QR or others) displayed on a screen of the first device. A method of performing a transfer of units between a first entity (BA) and a second entity (BB) managing respective user accounts including respective value units, operations on the units of values that can be controlled by devices of which a first device (DA) and a second device (DB), characterized in that it comprises the steps on the first entity (BA): a. a step of receiving (ET1) a command for obtaining transaction data relating to a transfer to be made b. a step of supplying (ET2) first data (DT), referred to as transaction data, to the first device (DA); vs. a step of receiving (ET8) a transfer realization command, the command including all or part of the transaction data (DT) and a second data item (TK) previously obtained by the second device (DB) from the second entity (BB); d. a step of transmitting (ET9) to the second entity (BB) all or part of the transaction data (DT) received, and the second data item (TK) for verification; e. a step of performing the transfer according to the verification.

Device (DB), said second device, comprising a communication module for communicating with a first entity (BA) and a second entity (BB) managing user accounts including respective units of values, a control module able to control a transfer units (TB) between entities, characterized in that it comprises: a. a module for obtaining first data (DT), said transaction, from a first device, b. a control module able to transmit to the first entity (BA) a command for performing the transfer, the command including all or part of transaction data DT and a second data (TK) previously obtained from the second entity (BB).

8. Entity (BA), called first entity, able to communicate with a second entity (BB) for performing a transfer of units of value between user accounts including respective units of values managed by the entities respectively, operations on the units of value that can be controlled by devices including a first device (DA) and a second device (DB), characterized in that it comprises a. a first receiving module able to receive a command for obtaining transaction data relating to a transfer to be made from the first device (DA) b. a module for supplying first data (DT), referred to as transaction data, to the first device (DA); vs. a second receiving module able to receive a command for performing the transfer, the command including all or part of the transaction data (DT) and a second data item (TK) previously obtained by the second device (DB) from the second entity (BB);

9. Computer program adapted to be implemented on a device (DB) as defined in claim 7, the program comprising code instructions which, when the program is executed by a processor, performs the steps defined in the claim 1.

An implementable computer program on an entity (BA) as defined in claim 8, the program comprising code instructions which, when the program is executed by a processor, performs the steps as defined in claim 6.