Technology

The invention refers to a method that enables execution of cashless payments, person-to-person or person-to-merchant money transfers where a cashless transfer is credited to the recipient ^' s account using a payment cryptogram generated by the payer's mobile phone. The method enables immediate payment processing and basically the money received is credited immediately to the recipient ^' s account.

Certain hardware components of this invention relate to the already filed patent applications SK PP 32-2009 dated 3 May 2009 (EMV terminal on SD card) and SK PP 50016-2010 dated 19 April 2010 (Payment Button).

Present technology

There are several known P2P (person-to-person) payment systems built around the mobile phone. According to the published international application WO 2008/027620 there is a system enabling P2P or P2M (person-to-merchant) payments, where the involved payers and/or payment recipients have a mobile phone, the phone number of which or other identifier serves the purpose of allocating the participant in the system. This particular system like a huge number of other similar configurations such as KR 2001 -25740 uses the mobile phone only as a tool for controlling payment applications operated in the settlement centre. In these systems, the mobile phone is basically a mere interface for controlling of payments. Such setup brings in problems related to overall security of payments as the communication path between the mobile phone and the settlement centre does not meet e.g. the EMV (Europay MasterCard VISA) standards. Another setback relates to the fact that solutions designed in this manner require a complete changeover of payment applications on the part of the recipient bank and/or card issuer.

What is needed is a technical solution with high EMV payment application security generating ultimate payment cryptograms in the EMV standards format using the structure of cryptograms already utilized in processing of payments from POS (point of sale) terminals. Such solution has not yet been identified and/or inherits security risks related to the fact that during the transfer of data from the customer's payment card to the remote POS terminal or virtual POS terminal of the merchant, the data being communicated in this way can be detected and misused. Subject matter of the invention

The above setbacks are to a great extent eliminated in the mobile person-to-person cashless transfer, where the payment cryptogram is created with the structure corresponding to the POS terminal payment cryptogram as designed in the invention, the basis of which is that the payer's mobile phone requests the configuration data of the payment terminal corresponding to the payment recipient and using these configuration data, the payment terminal is configured and launched within the mobile phone. The payer's mobile phone therefore includes an "indifferent" POS terminal, which, based on configuration of respective data, can behave like a terminal owned by various persons. The initial "indifferent" setup of the terminal makes it possible to include various in the system various banks of the recipient. For the purposes of the presented description, we understand any mobile communication device, so even PDA (personal digital assistant), tablets, notebooks equipped with a corresponding modem and similar to be a mobile phone.

Following the configuration of the respective payment terminal, the payment-terminal application will run in principle identically to the payment executed in the conventional POS terminal in a physical shop. Communication between the selected payment card and the configured POS terminal can be designed in the manner that the payment card can be directly embedded in the payer's mobile phone. In such case, the security risk arising from reading of the card in an unknown terminal or from sending of payment card data over the mobile network or the internet is eliminated.

In suitable configuration, that is based on hardware components described in Logomotion earlier patent applications, the payment will run in such a way that the payment- terminal application will be stored on a removable memory card, e.g. in the form of the micro SD card where one or more payment cards will be stored, too. The payment-terminal application as well as payment cards can be stored on separate Secure Elements of a removable memory card or in separate domains of a single Secure Element.

The payer must have a phone supporting the payment-terminal application and also he also must be registered in his bank as a P2P system client as described in this invention. The payment recipient may but does not need to have a mobile phone supporting the payment-terminal application however he also must register in his bank as a P2P system client as described in this invention giving his phone number and/or email address.

The centre equipped with the corresponding server connects and routes information flows from individual participants in the system. After launching the payment application, the payer's mobile phone sends a request to the center in order to get configuration data corresponding to the respective recipient. Based on the specified recipient ^' s phone number or his name, the centre first checks the payment recipient ^' s registration in the P2P system. Subsequently, the configuration data of the recipient ^' s bank are paired with this request and they are sent to the payer's mobile phone. The payer's mobile phone can assign the data to the payment recipient ^' s name in the phone directory, which is normally stored in the mobile phone. In such case, repeated payments to the same payment recipient can be executed without requesting configuration data of the recipient ^' s bank.

Following the configuration of the "indifferent" POS terminal in the payer ^' s mobile phone, the payment- terminal application is launched in such a way that the mobile phone becomes a POS terminal administrated by the corresponding bank of the recipient. The payer enters the amount to be sent to the payment recipient and the EMV processor processes the request; the outcome of the operation is a cryptogram in the TC(Transaction Certificate) structure saying that the off-line payment is approved or AAC (Application Authentication Cryptogram) saying that the payment is rejected or ARQC (Authorization Request Cryptogram) on-line payment. From recipient ^' s bank's perspective, the output of the payment application sent from the mobile phone has a standard structure that is same as in case of other operations made on any terminal of the bank. The mobile phone sends out the cryptogram via the GSM communication channel to the centre. Here, the cryptogram is temporarily stored in case the request for money transfer fails due to an error on the transmission route. The centre's server decrypts the cryptogram and based on the recipient ^' s bank code sends the cryptogram to the respective bank of the recipient.

The recipient ^' s bank verifies in its database the existence of the payment recipient ^' s phone number or email and allocates the real payment recipient ^' s account to it. Subsequently, the transaction is processed identically as in case of a physical POS terminal at the bank counter. In case of the ARQC cryptogram, on-line authorization is requested in the bank that issued the payer's payment card. In case of the TC cryptogram, the payment is authorized as off-line.

The recipient ^' s bank notifies the payment recipient by SMS that the payment was received to his account. In case the payment recipient also has in his mobile phone a removable memory card with a structure similar to the payer's, he can receive the money and directly "top up" his removable memory card.

In case the recipient ^' s bank database does not recognize the respective payment recipient ^' s phone number or email and the payment cryptogram was of the TC type, i.e. the money has already been debited from the payer's account, the recipient ^' s bank will request a reverse payment operation from the payer's card issuer aimed at returning the money back to the payer's card as it cannot be transferred to the designated payment recipient. In this case, the AAR cryptogram is used, which is sent from the centre to the payer's phone together with the correct data of the recipient bank ensuring that the payer can use the right configuration data in case of another attempt.

In case of successful payment processing, the response of the recipient ^' s bank in the

ARQC format is sent to the payer's phone, which transfers it to the removable memory card. Here, the cryptogram is decrypted and the result of the transaction is stored to the database. This step will make it possible to erase the temporarily erased ARQC cryptogram. The payer's mobile phone displays the outcome of the whole payment process.

If the mobile phone awaits the ARQC reply in vain and receives none within the preset time, it asks the payer to confirm whether he wishes to repeat the transaction. If yes, it sends the temporarily stored ARQC again to the centre. Such stored ARQC makes it possible for the recipient bank to verify that the case is a repeated attempt of already started payment application. If the recipient ^' s bank identifies that the same ARQC cryptogram was already successfully used for payment execution, this finding is repeatedly sent to the payer's phone; if it is found out that the ARQC cryptogram in question has not been subject to processing yet, the given transaction is executed as a new one. These feedbacks help eliminate unfinished operations in case of failure of information flow in any part of the payment transaction.

Overview of Diagram Pictures

The invention is explained in detail in the Picture 1 to 8.

The Picture 1 depicts a block scheme of relationships between P2P system participants even with a possibility of a direct loading of configuration data from the recipient's bank.

The Picture 2 there is the data structure in case of individual P2M system participants and some static relationships between the participants.

The Picture 3 and 4 show the flow of tasks and data in the P2P/P2M system. The diagram is interrupted for clarity reasons; it is divided into two parts using A - in the meaning of flow interruption and designation A ^' - in the meaning of flow continuation.

The Picture 5 shows the activity of the configured POS terminal within a removable memory card of the microSD format. The ratio of the sizes of the removable memory card and the mobile phone is not subject to protection; the size ration is not correct as it ^' s only goal is to increase clarity of the scheme and therefore cannot be explained in a narrow sense from the protection extent point of view.

On the figure 6 there is the course of person registration that is to say of the payer and payment recipient registration in the center using the bank of the respective participants itself as a preparation to realize payment method according to this invention. On the figure 7 there is the course of tasks between individual participants of the system in case of an EMV payment using ACQ configuration data of the recipient.

In comparison to figure 7, on the figure 8 there is a changed course of tasks and that from the task number 53, when the recipient ^' s configuration ACQ data are used in EMV payment between indivuidual system participants and the confirmation of the payment is realized as a second EMV transaction. Realization examples

Example 1

The example in the figures 1 through 5 describes a system with one centre 1_, a server, several payment card 9 issuers 5, several recipient 7 banks 2 and a group of users who can be both payers 6 or payment recipients 7.

The majority of users have Logomotion microSD cards inserted in their mobile phones. This card comprises, among other things, a secure element with indifferent payment- terminal application and several secure elements with separate payment cards 9. The described hardware configuration gives the user an EMV processor that cooperates with his payments cards 9 in a contact way. All users are registered in their banks as P2P system users and they provided their phone number or at least their email contact details.

The recipient ^' s 7 bank 2 sets configuration data for the creation of a POS terminal 8 for a specific transfer to the account of its client. Based on a contract, the data are shared between the bank and the centre 1 where the phone numbers and/or emails are allocated to the respective configuration data. The system also comprises a data link of the phone operating on the basis of GPRS or SMS.

The payer 6 starts the money transfer application on his mobile phone 4 using GUI (Graphical user interface). He enters the payment recipient ^' s phone number, email or name in his phone 4. The mobile phone 4 sends the payment recipient ^' s 7 identity to the centre 1_, where in the first step, the server database checks whether the payment recipient 7 is registered as a system user. If this is the case, the centre 1 sends information about the payment recipient ^' s 7 bank 2, which also is a part of the P2P system, back to the mobile phone 4. In this case, the bank can be referred to as XYZ. The payer's 6 mobile phone 4 equipped with a Logomotion microSD card sends to the server of the recipient 7 bank a request for configuration data for the specific payment that should be executed for the benefit of the payment recipient 7. The centre1 adds the bank code to the configuration data.

The configuration data send out to the payer's 6 mobile phone 4 will initiate the creation of a specific POS terminal 8, in this case a terminal belonging to the XYZ bank. The configuration parameters are 3DES encrypted and the decryptions is in this case executed on the encryption block in the secure element on the removable memory card 3. A one-time key is used for decryption. In principle, in this particular transaction the mobile phone 4 acts in the position of and appears as a POS terminal 8 operated by the payment recipient 7 although it is in fact a mobile phone 4 owned by the payer 6 who actually also operates it.

The payer 6 enters the amount to be transferred to the payment recipient ^' s account using a keypad. Based on the amount and the risk management arrangements pertaining to the payment card 9 it is decided whether the payment will be off-line or on-line. The payer 6 can choose among several payment cards 9 stored on his removable memory card 3 in the mobile phone 4. The outcome of the payment-terminal application running on the removable memory card 3 is a cryptogram in the form of TC (accepted off-line payment), ARQC when on-line authorization is required or AAC in case the payment is rejected. The resulting cryptogram encrypted on the encryption block directly on the removable memory card 3 is stored in the memory and the POS terminal 8 discontinues its payment-terminal application until the moment when the ARPC cryptogram is receive.

The interface installed in the mobile phone 4 will retrieve the cryptogram from the removable memory card 3 and send it in a data SMS or using GPRS to the centre 1 where the cryptogram is stored in the memory at least temporarily just in case there the communication flow is disrupted. The centre's 1 server decrypts the received cryptogram and sends it for processing to the respective bank according to the recipient ^' s 7 bank 2 code. The bank decrypts the cryptogram and allocates the real account to the payment recipient 7 based on the phone number included in the cryptogram. The bank notifies the payment recipient 7 in an SMS that his account received the payment and sends the reply in the form of the ARPC cryptogram to the centre 1_. At the centre 1_, the reply is encrypted and sent to the payer's 6 mobile phone 4. The cryptogram is decrypted on the removable memory card 3 and the second phase of the transaction is concluded with erasure of the temporarily stored ARQC. The outcome is stored to the memory on the removable memory card 3 and the payer

6 is informed about the successful money transfer on his mobile phone 4 display.

Example 2

The payer 6 sends the money to the recipient 7 using the P2P system. In this case, both payer 6 and the recipient 7 have the LGM removable card 3 of the micro SD format and both are registered in the P2P system belonging to their bank, which issued them the payment card 9 and which also sent the data to the center with their approval. The application in the payer ^' s 6 mobile phone 4 is supplemented for functionalities of P2P payments (registration, sending of payments, reception of payments).

In this example payments are executed as EMV transactions using EMV processor set for the benefit of the payment recipient 7. For each LGM card there is an account at the issuer ^' s 5 in favor of the cardholder. The (executed) money transfers are done from (to) this account.

The course of the registrations is shown on the figure 6. The payer 6 and the recipient

7 (PERSON 1 , PERSON 2) are registered in the step 21 in their issuer bank 5 using their phone number. The issuer bank 5 administers the table of issued LGM cards including these data:

the account corresponding to the card (Card account), from which (to which) the money are being transferred, identification of the person (Person ID), which is used as an additional identification of the payer 6 when he is confirming payments,

acquirer (bank 2 of the recipient 7) with which the Issuer has got a contract on operation of P2P payments. It is possible that the acquiring activities are ensured for the recipient ^' s 7 bank 2 by some contractual partner payment processor,

phone number that is used as a basic identifier in the P2P system,

symbol of successful registration to P2P payments (P2P allowed).

In the step 22, the issuer sends information received during registration to its contractual acquirer: the phone number, the identification of the person, account. The acquirer stores and administers these data.

The center labeled as the LGM P2P has the function of a routing table between individual acquirers. In the step 23, the LGM P2P center get the following data during registration: phone number, identification of the person and the URL address of the Acquirer (ACQ URL). ACQ URL is an address to which the payer 6 is redirected to get configuration data for the EMV process for the benefit of the recipient 7. In configuration according to this example the LGM P2P center does not administer any sensitive data nor it is connected to any financial transaction directly.

The course of the payment, in one of the possible versions, is shown on the figure 7. The procedure is based on sending the payment, confirming the reception of the payment and the transfer of money itself. The process is the following:

The sender of the payment launches the LGM Card application. He selects the P2P payments, enters the recipient ^' s 7 phone number either directly or selecting it from a phone directory, he enters the amount directly or selects it from the amounts commonly send and presses "Send" The communication as shown in steps 31 through 39 is executed. By this, the payment is sent.

The payment is authorized offline in case the circumstances enable it or it is authorized on-line. The on-line authorization in the bank 5 that issuer the card belonging to the payer 6 enables to send the command, the script belonging to the issuer ^' s bank 5 to the card on the removable memory card 3 e.g. for the reset of the payment card 9 counter. The payment itself will run on the EMV processor using configuration data of the payment recipient ^' s 7 bank 2 (in a similar way as in case of LCT or m-payments).

In the second part can the recipient ^' s 7 bank 2 ask for the confirmation of payment. The recipient 7 is informed about who sends him the payment through payer ^' s 6 Person ID and he is also informed about the amount being send. In case the recipient 7does not confirm the reception of the payment within certain period of time (e.g. within 3 days), the transaction is automatically cancelled. The confirmation of the payment reception is not necessary in principle in other example; it runs in the sets 40 to 43. After the successful confirmation by the payment recipient 7 the prepared transaction is sent for further processing (clearing and settlement). The payment is received to a special (Jumbo) account of the recipient ^' s 7 bank 2 and within the bank 2 it is transferred to the recipient ^' s 7 account. Because the acquirer can work for several issuer banks 5, there is a Jumbo account for each issuer.

Because the bank received a confirmation saying that the transaction was approve, the bank 2 can credit the money to the recipient ^' s 7 account sooner than the money is received physically by the bank. E.g. the bank can make P2P payments between its clients more advantageous. The money transfer itself is described in steps 44 to 48.

The payer 6 (PERSON 1 ) is connected to the LGM P2P center 1_, its URL address is stored in the application. In the step 31 , the system will verify whether the payer 6 and recipient 7 (PERSON 2) are registered for P2P payments on the basis of phone numbers Phone nr 1 and Phone nr 2. In case he is, in the step 32, the LGM P2P center returns the URL address to the payment recipient 7 Acquirer (ACQ URL 2) that corresponds to the recipient ^' s 7 phone number (Phone nr 2). In case he is not, the payer 6 will be informed that the payment cannot be sent. In the step 33 the payer 6 is in redirected to the URL address of the Acquirer - payment recipient 7.

Acquirer, the recipient ^' s 7 bank 2 send configuration data for EMV processor for the transfer of payment (ACQ2 config data) in the step 34. The communication is assured in a standard way as in case of other use cases (handshake). In step 35 the EMV processor of payer 6 is configured and the transaction is generated - the payment of a given amount. The result can be TC (offline authorization successful) or ARQC (request for online authorization). In case the card rejects the transaction (AAC), the process ends unsuccessfully. The result (TC/ARQC) is sent to the acquirer, the recipient ^' s 7 bank 2 in the step 36. The record with the transaction is supplemented for a unique identification of the payer 6 and of the payment recipient 7 (Phone nr1 , Phone nr 2) - for further processing. The recipient ^' s 7 bank 2 had a gate for reception of payments and a system for the authorization of payments (ACQ2 P2P payment gate, ACQ2 P2P authorization). In case online authorization is required, in the step 37 there will be a standard verification in the payer ^' s 6 card issuer system. The result can also contain a script for the execution of the necessary operation on the payer ^' s 6 card (e.g. the off-line counter can be reset in this way).

In step 38, the record about the transaction is stored by the Acquirer 2 in its storage of P2P transactions (ACQ2 P2P TRX store) where it waits to be confirmed by the payment recipient 7. At this point, the transaction is not sent for further processing. It is an analogy to blocking an amount in case of a common card payment at the merchant. In case everything runs correctly, in step 39 the Acquirer 2 confirms to the payer 6 that he has successfully received the request to send the P2P payment. The script that is sent by the issuer can be part of the ARPC response (in case online authorization). The EMV processor finishes the transaction and the user is informed that the money was sent successfully. In step 40, the recipient ^' s 7 bank 2 - acquirer 2 needs to send information to the payment recipient 7. However, it only knows the payer ^' s 6 phone number (he can be a client of a different bank). In order the Acquirer 2 could inform the recipient 7 even about the sender ^' s name (Person 1 ID) he uses the LGM P2P center 1 service. In step 41 the LGM P2P center 1 returns the Person ID to the payer ^' s 6 phone number (Phone nr 1 ). The fact that it exist was already verified in the step 31 .

In the step 42 the recipient ^' s 7 bank 2 - acquirer 2 sends information about a waiting payment to the recipient 7 e.g. using an SMS. The identification of the payer 6 (Person ID), amount and a confirmation request are part of the information. In principle, this step is not necessary, as an alternative, the application in the recipient ^' s 7 phone can request the waiting incoming payment e.g. every time after being launched.

In the step 43 the payment recipient 7 confirms back that he approves the reception of money. He does it using and SMS or preferably using the LGM Card mobile application by asking the recipient ^' s 7 bank 2 for a list of incoming payments to be approved and he approves them. The corresponding URL of the recipient ^' s 7 bank 2 will be stored in his configuration data (it is "his" Acquirer). In case the recipient 7 does not confirm the payment within the preset time limit, the transaction is cancelled. Or, the Acquirer 2 can inform the payer 6 of the payment, since he has the payer ^' s 6 phone number stored along with the transaction.

After the payment is confirmed successfully by the payment recipient 7, in the step 44, the recipient ^' s 7 bank 2 - Acquirer 2 sends the transaction for processing (clearing + settlement). In the step 45 as the result of the processing, the corresponding amount is transferred from the payer ^' s 6 account (Card account 1 ) to the Jumbo account belonging to the recipient ^' s 7 bank 2 - acquirer 2. In the step 46, the amount is sent to the recipient ^' s 7 account within the bank. The amount is credited to the recipient ^' s 7 account (Card account 2) in the step 47. In the step 48, the card issuer 5 or the recipient ^' s 7 bank 2 - acquirer 2 can inform the recipient 7 about the end of the transfer.

There is another possible procedure version - in which the LGM P2P center administers the configuration data of the individual recipient ^' s 7 banks 2 directly. The advantage of this configuration would be not having to go through 2 steps - steps 32 and 33 namely and deletion of one task - sending the configuration data - from the recipient ^' s 7 bank 2 system. In that kind of case the center administers the sensitive data of individual recipient ^' s 7 banks 2. Example 3

The procedure version according to this example shown on the figure 8 has common steps with the example 2 - these are the steps 31 to 42. What is different is the way how the payer 6 confirms the payment, which is executed as a second EMV transaction. That can have a positive influence on trustworthiness of payment confirmation and by that also on the quickness with which the recipient ^' s 7 bank 2 credits the money to the recipient 7. Moreover, in case of a second transaction the issuer 2 can sent a script to the payment recipient ^' s 7 to his LGM Card e.g. to reset the offline counter.

The first EMV transaction generated by payer 6 is in the form the money being sent from the payer ^' s 6 account to the Jumbo account in the recipient ^' s 7 bank 2. The second transaction, generated by the recipient ^' s 7 bank 2 and confirmed by the recipient 7 is in the form of the money being sent from the Jumbo account in the recipient ^' s 7 bank 2 to the recipient ^' s 7 account (reverse transaction). These two transactions are paired and sent to be processed at the same time. The adjusted part of the corresponding scheme is shown on the figure 8.

The confirmation of the given recipient ^' s 7 payment starts in the step 53 by a request to send the Acquirer 2 configuration data. He has the corresponding URL of the Acquirer stored in his configuration data. In the step 54 the Acquirer 2 returns the configuration data ACQ2 config data.

The EMV processor of the recipient 7 is configured in the step 55 and the transaction is run - payment of the given amount, however with a negative sign. So the money goes from the Acquirer, from his Jumbo account to the recipient 7. It is an analogy of returning money to the merchant ^' s card e.g. in case of the replacement claim - reverse transaction.

The result (TC/ARQC) is sent to the Acquirer in the step 56. In case online authorization is required, the verification in the Issuer 2 system takes place in the step 57. The result can also contain a script that should be executed on the recipient ^' s 7 card e.g. reset of the offline counter. The record about the TRX2 transaction is stored in the step 58 by the Acquirer in his storage of P2P transaction (ACQ P2P TRX store), where the original TRX1 transaction is already waiting for processing. Both transactions can be sent immediately for further processing. In the step 59 the Acquirer 2 confirms the successful reception of the transaction that confirms the reception of the P2P payment to the payment recipient 7. Even a script that is being sent by the card issuer 5 can be part of the ARPC response (in case of online authorization). The EMV processor finishes the transaction and the recipient 7 is informed about the successful reception of money. In the step 60, the Acquirer 2 sends both transactions to be processed at the same time (clearing + settlement). The result of the processing in the step 61 is the crediting of the account to the payment recipient ^' s 7 account (Card account 2). The status of the Acquirer ^' s Jumbo account remains unchanged since the amount is first credited and then deducted. The Issuer 2 or the Acquirer 2 can inform the recipient 7 about the finalization of the transfer in the step 62.

With respect to symmetrical system of generation of two transactions this option enables even a reverse procedure: the payment recipient 7 asks for money, generates the first transaction, subsequently the payer 6 is informed that there is a request to send money and by confirming the request the payer 6 sends money. So, besides the Send money service an analogical Receive money service is possible.

Industrial Applicability

Industrial applicability is apparent. Using the invention, it is possible to repeatedly transfer money between system participants; it is also possible to set up various P2P or P2B structured payment systems.

List of References and Acronyms

1 - centre

2- recipient bank

3- removable memory card

4- payer's mobile phone

5- bank/ payment card issuer

6- payer

7- payment recipient

8- POS payment terminal

9- payment card

P2P - person to person

P2M - person to merchant

EMV - Europay MasterCard VISA

POS - point of sale

PDA - personal digital assistant

TC - Transaction Certificate

GPRS - General packet radio service

AAC - Application Authentication Cryptogram

ARQC - Authorization Request Cryptogram

ARPC - Authorization Response Cryptogram

TC - Transaction Certificate

GUI - Graphical user interface

SIM - subscriber identity module