WO2013156076A1

WO2013156076A1 - Transfer connector

Info

Publication number: WO2013156076A1
Application number: PCT/EP2012/057254
Authority: WO
Inventors: Mikhail KOLATCHEV
Original assignee: Payfair International Gmbh
Priority date: 2012-04-20
Filing date: 2012-04-20
Publication date: 2013-10-24

Abstract

A connector for coupling a transfer request terminal to a transfer confirming server, the connector comprising: - Input means adapted for receiving user identification data and a transfer request in a format incompatible with the server; - Authentication means for authenticating the user making the transfer request; - Convertor adapted for generating a further transfer request based on the received user identification data and transfer request, the further transfer request having a predetermined format acceptable to the server; - Output means for sending the further transfer request to the transfer confirming server.

Description

Transfer connector

The present invention relates to a connector and a method for coupling a transfer request terminal to a

transfer confirming server.

Transfer request terminals, preferably payment terminals, are conventionally connected to a transfer confirming server, a bank. Thereby, sensitive identification information such as a bankcard number, is provided to the terminal together with a security code. The bank checks whether the bankcard number matches with the security code, and if it does, the bank confirms the requested transfer.

In the past years, a wide variety of transfer request terminals have been installed, such as payment terminals in stores, ATM (automatic teller machine) cash machines, but also online payment terminals for paying goods and services delivered via websites. Not all of the places, websites where these payment terminals have been installed have a good reputation, particularly on the internet.

Therefore a user might not always be keen to give sensitive identification information such as a bankcard number.

It is an object of the present invention to provide an alternative to a user making a transfer that provides an acceptable sense of security and protects privacy.

To this end, the invention provides in a connector for coupling a transfer request terminal to a transfer confirming server, the connector comprising:

Input means adapted for receiving user identification data and a transfer request in a format incompatible with the server;

Authentication means for authenticating the user making the transfer request;

Convertor adapted for generating a further transfer request based on the received user identification data and transfer request, the further transfer request having a predetermined format acceptable to the server; Output means for sending the further transfer request to the transfer confirming server

The convertor generates a further transfer request with a predetermined format acceptable to the server.

Thereby, more flexibility is created regarding the first transfer request made by the user, which does not

necessarily need to be acceptable to the server. Because of the more flexibility, the user can identify himself with non-critical identification data such as an email address or a telephone number, or other types of identification data. This information is generally considered less sensitive information as for example bankcard numbers. Additionally, the user may opt for using its identification data which is already available in a given channel (e.g. Internet or mobile communication channel) . Doing such, the user does not need to reveal any personal information which is not already available in a given channel. Therefore the burden for entering such non-critical identification data is lower particularly on websites, mobile communication channels, etc. Despite the transfer request is accompanied with non- critical identification data, the security level remains high because of the authentication step. In this manner, an alternative is provided for requesting transfers whereby the high security level is maintained but whereby there is no need for the user to give sensitive identification

information .

Preferably, the connector comprises a memory with a database wherein for a plurality of users identification data, corresponding authentication data and corresponding transfer related data is stored, the authentication means and/or convertor being connected to the memory to have access to the data stored in the database. Such database in a memory in the connector provides the coupling between the user's identification data and the data required by the transfer server, which requires transfer related data (such as a bankcard number) . Also the authentication means have access to the database in the memory so that the

authentication of the user is executed using data (for example a telephone number) particularly provided to the authentication means for this purpose.

Preferably, input means and output means are formed as one or several internet connection ports. Although other connection means might also be technically suitable for supporting the present invention, an internet connection port is preferred because of the wide use of the internet and corresponding ease of connectivity and compatibility.

Preferably, the authentication means comprise a phone for authenticating the user via the user's mobile phone. Telephone authentication is highly reliable for following reasons. Studies have shown that a user detects the loss of his mobile phone four times faster than he detects the loss of his wallet. Conventionally,

identification and authentication is performed by bankcard number and corresponding PIN code. Thereby it is noted that the bankcard number is usually retrievable from the wallet. Because the user is statistically more likely to have his mobile phone with him, using this mobile phone for

authentication is safer.

Preferably, the authentication means comprise a sound signal generator provided for generating a sound signal and sending the sound signal to the terminal.

Terminals are conventionally provided with, or at least can be provided with one or several loudspeakers. Sending a sound signal to the terminal for authentication purposes via the user's mobile phone is a technical solution that

requires no substantial modifications to existing systems. It is therefore easy to implement such system in existing terminals and/or transfer systems. The invention further provides in a method for establishing a coupling between a transfer requesting terminal and a transfer confirming server via a connector, the method comprising the subsequent steps of:

- receiving at the connector user identification data and a transfer request in a format incompatible with the server ;

authenticating the user making the transfer request; generating a further transfer request based on the received user identification data and transfer request, the further transfer request having a predetermined format acceptable to the server;

sending the further transfer request to the transfer confirming server.

The method allows the user to send a transfer request using non-critical identification data. Such

transfer request is incompatible with the server which validates transfers. However the step of generating a further transfer request generates a request that is

acceptable to the server so that the request can be

validated. To enhance the safety, an authentication step is added to authenticate the user making the request at the transfer request terminal.

Preferably, the method further comprises at least one of the steps:

accessing a memory with a database and retrieving authentication data corresponding to the received user identification data before the authenticating step; and accessing the memory with the database and retrieving user's corresponding transfer related data

corresponding to the received user identification data before the generating step.

By accessing the database in the memory for the authentication step and/or for the generating step has as a result that these steps are not directly, but indirectly based on the identification data. Thereby, an extra security step is added by using information related to, and not directly retrievable from the provided data.

Preferably, the authentication step comprises the following steps:

Generating a sound signal;

Sending the sound signal to the terminal to be played by the terminal;

Establishing a connection line between a telephone and a mobile phone of the user;

Retrieving via the established connection line the sound played by the terminal and picked up by the mobile phone of the user;

Checking whether the retrieved sound matches with the generated sound signal

Sound authentication via a user's mobile phone is a reliable authentication method because as explained above studies have shown that a user detects the loss of his mobile phone four times faster than he detects the loss of his wallet. Furthermore mobile phones are technically

equipped to pick up sounds, so no modification is required. Terminals, particularly internet-based terminals are

consulted via a computer, which can be assumed to have loudspeakers, or can at least be easily equipped with

loudspeakers. Therefore no substantial technical

modification is needed to the existing elements to make the system according to an embodiment of the invention work.

The invention will now be described in more details with respect to the drawings illustrating some preferred embodiments of the invention. In the drawings:

Figure 1 shows the participants in the invention; Figure 2 shows the interactions with the connector according to an embodiment of the invention;

Figure 3 shows a database present in the connector; and Figure 4 shows a connector according to an

embodiment of the invention.

In the drawings a same reference number has been allocated to a same or analogous element.

Figure 1 shows the participants in the invention, and shows on the left hand side transfer request terminals 1, and the right hand side transfer confirming servers 3. The transfer request terminals are coupled to the transfer confirming servers via a connector 2. This connector performs the routing from a terminal to a specific one of the transfer confirming servers. The connector 2 further serves as a service provider for the servers, and it can perform tasks for the servers.

In the context of the invention, transfer request terminals are preferably interpreted as payment terminals. Such payment terminals can be in the form of a physical terminal located at a store, a bank, or other place where a payment can be made, or can be in the form of an application running on a home computer, on a website, or on another device where payments can be made.

A wide application of transfer request terminals according to the prior art, is hindered by the safety requirements and trust of users, which is essential for these terminals to be used. Particularly for web

application, the burden for a user to enter his bank card number and corresponding code, to validate a transfer, is very high. Furthermore, fraud with bank card numbers is quite common and relatively easy. If a malicious user gets access to a bank card number (which is printed on a

bankcard) , and gains knowledge of a corresponding private code, he can use this information to request a transfer at any transfer request terminal.

In the context of the invention, transfer confirming servers are preferably interpreted as servers owned by a bank or digital wallet company. There are many banks, however certain services provided by these bank are standardized. A bank card and bank card number and private code which relates to this bank card, is standardized. A user, who is customer at a bank, receives a bank card with a bank card number, to which a private code is linked. When the user requests a transfer at the bank, he identifies himself by providing to the bank the bank card number and the private code, so that the bank can validate the

transfer. Digital wallet companies use a pre-paid bankcard whereby a predetermined value is loaded onto the pre-paid bankcard, whereby the loaded money is prepaid or is

guaranteed (like a creditcard) by a bank account number.

In prior art systems, a connector couples transfer request terminals to transfer confirming servers, as is shown in figure 1. The prior art connector only serves to route a transfer request to the correct transfer confirming server. Therefore, the router according to the prior art extracts from the bank card number the identity of the bank, and routes the request to the identified bank. In practice, the first six digits of the bank card number are indicative of the identity of the bank.

The connector 2 according to the invention allows a user to make a transfer request using non-critical

identification data, while a high security level is

maintained. Such connector thereby widens the application possibilities for transfer request terminals, as the burden for a user for entering non-critical identification data, for example an e-mail address or a telephone number, is less sensitive .

Figure 2 shows how the connector 2 interacts with the transfer request terminal 1 and the transfer confirming server 3. The transfer request terminal 1 sends a transfer request 4 to the connector 2. The transfer request contains, besides the request for a transfer, identification data from the user requesting the transfer. Typically a transfer request contains three main items: from-information, to- information, and how-much-information. Typically "from- information" is linked to the user requesting the transfer and his bank account number of this user. "To-information" is typically a third party to which the transfer is made.

"How-much-information" defines the amount of the payment. If a transfer request is made for example at a website, the "how-much-information" and the "to-information" is

predefined by the website as respectively the amount to be paid and the bank account number of the website. In such case, all a user has to do is fill in his identification data so that the request can be completed using the

identification data of the user as "from-information" .

It is not essential according to the invention that the identification data and the transfer data is sent from the transfer request terminal in one package. The invention can be implemented to first identify the user (and

authenticate the user) after which the authenticated user sends the transfer request to the connector.

According to the invention, the identification data does not need to be a bank card number. Any identification data can be used, for example an e-mail address, a name, a telephone number, and further identification data. A

transfer request based on such non-critical identification information (a bank card number is considered critical identification data) , is typically not accepted by a bank to validate the transfer because it is not in the format prescribed by the bank. The bank prescribes a format wherein a bank card number is used to identify the user, preferably together with a private code to enhance security.

After the transfer request has been made to the connector, the connector retrieves user information from a database, as is illustrated with reference number 5. To this end, the connector comprises a memory with a database, which will be described in relation to figure 3. Based on the retrieved data, and/or based on the received transfer request, the connector can decide on how to perform an authentication step. The authentication is preferably conducted using different identification data than the identification data received in the transfer request. For example, if the transfer request identifies the data based on an e-mail address, the authentication is preferably not conducted via this e-mail address but for example via a phone number retrieved from the database in the connector. On the other hand, if the user is identified via a telephone number, the authentication is preferably conducted via the e-mail address which is retrieved from the database in relation to this telephone number. Such authentication based on information retrieved from a database in the connector enhances the security level. Furthermore, the database in the connector may contain information that the user prefers not to be authenticated via e-mail. In such case the user is identified via for example his telephone number. The origin of the transfer request can also be determining in the choice of authentication that is conducted. In some cases, for example where a transfer request has been made from a bank terminal using the bank card number and the private code, an authentication step is not necessary, and the connector can assume correctness of the transfer requests, based on the critical identification data and the

trustworthiness of the bank terminal.

In step 6, the connector runs an authentication procedure to authenticate that the user making the request is authorized and recognized as the user who has authority to make the request. An authentication procedure preferably requires an interaction between the connector and the user. Different sorts of interactions can be established, which authenticate the user. In a first example, the connector sends an e-mail to the e-mail address of the user that is stored in, and retrieved from the database based on the transfer request. When the user replies to this e-mail, preferably mentioning a private code, the user is

authenticated. In a second example, authentication is conducted via the mobile phone of the user. The mobile phone number is retrieved from the database based on the transfer request. The connector calls to the mobile phone number, to establish a telephone connection between the connector and the mobile phone of the user. Via a separate connection line, the connector is connected to the terminal where the transfer request has been made, for example via the

internet. Via the latter connection, the connector sends a sound signal to the terminal, to be played by the terminal. When the terminal plays the sound, the connector can listen via the first established telephone connection whether the sound is picked up by the mobile phone. It can be

furthermore checked whether the sound signal sent to the terminal, and the sound picked up by the mobile phone of the user, matches. If the sound signal matches, it is considered confirmed that the user is present at the terminal where he requests the transfer, and thereby the user is

authenticated. Telephone authentication is preferred over other authentication means because statistics have shown that a user detects the absence of his mobile phone way faster than he detects for example loss of his wallet.

After the user has been authenticated, the

connector generates a further transfer request, in a format that is acceptable by the transfer confirming server, and sends this further request to the transfer confirming server, shown in the figure with reference number 7.

Preferably the further transfer request is generated based on the data retrieved from the database retrieved in the connector, and data in the first data request number 4. To this end the database in the connector preferably contains bank card numbers and, if necessary, private keys, so that the transfer request which is nowadays generated by the terminal and directly sent to the bank, can be generated in the connector. The generation of this further transfer code in the connector makes it easy to implement the present invention in currently working systems. Prior art transfer confirming server require the transfer request to be made in the predetermined format, for example comprising bank card number, private key, "how-much"-information "to"-information and "from"-information . If the connector builds a further transfer request in the same format as it is currently acceptable by the request confirming servers, the servers will not notice whether the request is made directly from a terminal, or via a connector according to the invention. Therefore no amendment in the transfer confirming server must be made to be able to implement the current system.

After the transfer request has been made to the transfer confirming server 3, the transfer confirming server 3 sends a transfer validation message 8 to the connector 2 (if the transfer is accepted by the server) . The connector 2 at its turn, validates the transfer to the transfer request terminal 1, shown with reference number 9. Thereby the connector 2 serves as a convertor for converting a transfer request that is not in accordance with the predetermined format required by the transfer confirming server 3, to a request that is in an acceptable format.

Figure 3 shows a database that is used by a connector to retrieve authentication data, and to build the further transfer request. The database comprises a number of users 1, 2, ... , n and for each user a card number (CN1, CN2, ... , n) , a phone number (PN1, PN2, ... , PNn) , an e-mail address (EMI, EM2, ... , EMn) , and/or further identification data is stored. When a transfer request comes in at the connector, the connector identifies the user making the request and retrieves the identification data linked to this user. Via this retrieved data, the connector establishes whether an authentication is required and how the user is authenticated (e-mail, phone, ...) . Furthermore via the retrieved data, the connector is able to build a further transfer request in a predetermined format.

Figure 4 shows a connector 2, which comprises multiple communication ports 11, 12, 13, a processor 17, and a database 10. The database 10 is explained in relation to figure 3. Via communication port 12, which can be an

internet communication port, the connector is connected to a terminal 1 via connection line 15. Upon receipt of a

transfer request from the terminal 1 via communication line 15, the processor 17 retrieves data from the database 10, to set up an authentication communication line 14, which is a separate communication line than communication line 15. This separate communication line 14 is set up via communication port 11, which can be a telephone. The telephone calls the mobile phone of the user to establish a further

communication line 14 via a sound authentication mechanism, explained above. The connector 2 authenticates the user making the request at the terminal 1. After authentication, the connector sets up yet another communication line 16 between the connector 2 and the transfer confirmation server 3. This connection line is set up via communication port 13 in the connector. This communication port 13 can be formed as an internet port, and communication ports 13 and 12 can be integrated into one physical internet port whereby two connection lines 15 and 16 are set up via this one internet port .

Preferably the connector comprises at least two different types of communication ports, for example an internet port and a telephone. However a connector according to the invention can also be implemented using only one communication port being an internet communication port. In the latter case, the internet communication port is

configured to set up three communication lines 14, 15 and 16, whereby the communication port can communicate with three different entities, being a personal device of the user such as a mobile phone, a personal computer or a personal e-mail account, a transfer request terminal 1 and a transfer confirmation server 3.

Two examples will be described with reference to figure 2, the examples showing how the invention can be applied in practice. In the first example, the transfer request terminal is a cash machine located at a premise of a bank. A user who wants to get an amount of money out of the cash machine, enters his telephone number and the amount he wishes to receive into the cash machine. The cash machine sends a message 4 to the connector. Preferably this message is encrypted and sent via a secure connection line to the connector, to enhance the security of the data of the user. At the connector, the message is received, upon which the connector looks up into the database the corresponding identification data of the user, such as the card number and possibly also the pin code corresponding to the bank card number. The connector further performs an authentication step 6 by sending a sms message to the mobile phone of the user, in which a secret code is shown. This secret code can be entered into the cash machine, upon which the cash machine informs the connector of the entered private code, so that the connector can decide to accept or to reject the authentication of the user. If the authentication of the user is accepted, the connector builds a new message in a predetermined form, and sends it to the bank of the user. The bank of the user can be identified either by analyzing the bank card number, which starting digits are indicative of the bank to which the card number belongs, or can be retrieved directly from the database in the connector. The predetermined format of the message sent to the bank, is determined by the security standard of the bank, and can besides informational requirements, also require a certain encryption or other security measurements. Preferably the message 7 is sent via a secure connection line. The bank 3 checks whether the requested amount is owned by the user, and sends a confirmation message 8 to the connector, if the user is allowed to transfer that amount. The connector on its turn sends a confirmation message to the cash machine, after which the money can be given to the user by the cash machine and the transfer can be finished.

In a second example of the invention, the transfer request terminal is a website where items are sold, and transfer confirming server 3 is a wallet company, where a user has a wallet. Thereby, the wallet company identifies a user via his mobile phone number. The user, wanting to purchase an item via the website, enters his e-mail address into to website and indicates the item he wants to purchase. Then the website sends a message 4 to the connector 2, identifying the user via his e-mail address to the connector and indicating the amount that the user must pay (being the value of the item to be purchased) . When the connector locks up via the e-mail address in its database, the other

identification data relating to this user. Thereby, he retrieves the user's mobile phone number. Using this mobile phone number, the connector can set up an authentication step via telephone authentication. Alternatively, the connector could send an e-mail to the user, to which e-mail the user must send an e-mail response. If the user is authenticated, the connector builds a further message in a predetermined format and sends it to the wallet company 3. Thereby the predetermined format is defined as the format that is accepted by the wallet company. The wallet company confirms to the connector via a confirming message 8 that the user can spend the requested amount. Then, the connector confirms the purchase to the website, thereby finishing the transaction .

These examples show how using non-critical identification data, a user can make a payment request without having to comply directly to the security standard of the validator of the request. Namely, the connector converts the request into a further request can be accepted by the validator of the request, after having authenticated the user. Thereby security is maintained while the burden to the user and merchant is lower.

The present inventions may be embodied in other specific apparatus and/or methods. The described embodiments are to be considered in all respects as only illustrative and not restrictive. In particular, the scope of the

invention is indicated by the appended claims rather than by the description and figures herein. All changes that come within the meaning and range of equivalency of the claims are to be embraced within their scope.

A person of skill in the art would readily recognize that steps of various above described methods can be performed by programmed computers. Herein, some

embodiments are also intended to cover program storage devices, e.g., digital data storage media, which are machine or computer readable and encode machine executable or computer-executable programs of instructions, wherein said instructions perform some or all of the steps of said above- described methods. The program storage devices may be, e.g., digital memories, magnetic storage media such as a magnetic disks and magnetic tapes, hard drives, or optically readable digital data storage media. The embodiments are also

intended to cover computers programmed to perform said steps of the above-described methods.

The description and drawings merely illustrate the principles of the invention. It will thus be appreciated that those skilled in the art will be able to devise various arrangements that, although not explicitly described or shown herein, embody the principles of the invention and are included within its spirit and scope. Furthermore, all examples recited herein are principally intended expressly to be only for pedagogical purposes to aid the reader in understanding the principles of the invention and the concepts contributed by the inventor (s) to furthering the art, and are to be construed as being without limitation to such specifically recited examples and conditions. Moreover, all statements herein reciting principles, aspects, and embodiments of the invention, as well as specific examples thereof, are intended to encompass equivalents thereof.

Claims

1. A connector for coupling a transfer request terminal to a transfer confirming server, the connector comprising :

- Input means adapted for receiving user identification data and a transfer request in a format incompatible with the server;

Authentication means for authenticating the user making the transfer request;

- Convertor adapted for generating a further transfer

request based on the received user identification data and transfer request, the further transfer request having a predetermined format acceptable to the server; Output means for sending the further transfer request to the transfer confirming server.

2. The connector according to claim 1, wherein the connector comprises a memory with a database wherein for a plurality of users identification data, corresponding authentication data and corresponding transfer related data is stored, the authentication means and/or convertor being connected to the memory to have access to the data stored in the database.

3. The connector according to claim 1 or 2, wherein input means and output means are formed as one or several internet connection ports.

4. The connector according to any of the previous claims, wherein the authentication means comprise a phone for authenticating the user via the user's mobile phone.

5. The connector according to claim 4, wherein the authentication means comprise a sound signal generator provided for generating a sound signal and sending the sound signal to the terminal.

6. The connector according to any of the previous claims and claim 2, wherein the authentication step is conducted using information only indirectly retrievable from the transfer request by using the database.

7. Method for establishing a coupling between a transfer requesting terminal and a transfer confirming server via a connector, the method comprising the steps of: receiving at the connector user identification data and a transfer request in a format incompatible with the server ;

sending the further transfer request to the transfer confirming server.

8. Method according to claim 7, wherein the method further comprises at least one of the steps:

9. Method according to claim 7 or 8, wherein the authentication step comprises the following steps:

Generating a sound signal;

Sending the sound signal to the terminal to be played by the terminal;

Retrieving via the established connection line the sound picked up by the mobile phone of the user; Checking whether the retrieved sound matches with the generated sound signal.