Anotácia:Annotation:
V rámci mobilného telefónu (4) platcu (6) je umiestnená indiferentná platobno-terminálová aplikácia. Na pokyn platcu (6) si jeho mobilný telefón (4) z centrály (1) vyžiada konfiguračné dáta platobného terminálu prislúchajúce určenému príjemcovi (7) peňazí, následne sa pomocou prijatých konfiguračných dát vytvorí z indiferentného platobného terminálu konkrétny POS (8) platobný terminál banky (2) príjemcu (7) platby. Takto vytvorený POS (8) kontaktne komunikuje s platobnou kartou umiestnenou v rámci obvodov mobilného telefónu (4) platcu (6) a následne je platobný kryptogram odoslaný mobilným telefónom (4) platcu (6) do centrály (1) na spracovanie v banke (2) príjemcu (7) platby. POS (8) terminál v rámci platobno-terminálovej aplikácie vytvorí kryptogram v tvare TC alebo ARQC alebo AAC a okrem odoslania do centrály (1) ho uloží aj do pamäte v rámci mobilného telefónu (4), pričom bez rešetu pozastaví priebeh platobno-terminálovej aplikácie až do príchodu odpovede v tvare ARPC.Within the mobile phone (4) of the payer (6) an indifferent payment-terminal application is located. At the instruction of the payer (6), his mobile phone (4) from the central office (1) requests the payment terminal configuration data belonging to the designated cash recipient (7), then the specific POS (8) of the bank payment terminal is created from the indifferent payment terminal. (2) the payee (7) of the payment. The POS (8) thus formed communicates in contact with a payment card located within the payer's mobile phone (4) circuits and then the payment cryptogram is sent by the payer's mobile phone (4) to the central office (1) for processing at the bank (2). ) of the payee (7). The POS (8) terminal within the payment-terminal application creates a cryptogram in the form TC or ARQC or AAC and, in addition to sending it to the central office (1), also stores it in memory within the mobile phone (4). until the ARPC response arrives.
SK 50020-2011 A3SK 50020-2011 A3
////
Spôsob bezhotovostného prevodu peňazí z osoby na osobu prostredníctvom mobilného telefónuMethod of cashless transfer of money from person to person via mobile phone
Oblasť technikyTechnical field
Vynález sa týka spôsobu, ktorým je možné uskutočňovať bezhotovostné platby, prevody peňazí z osoby na osobu alebo z osoby na obchodníka, pričom bezhotovostný prevod je zúčtovaný na účet príjemcu pomocou platobného kryptogramu, ktorý je vytvorený v rámci mobilného telefónu platcu. Spôsob umožňuje okamžité spracovanie platby, a v podstate okamžité pripísanie prijatých peňazí na účet príjemcu.The invention relates to a method by which non-cash payments, money-to-person or person-to-merchant transfers can be made, the cashless transfer being accounted to the payee's account using a payment cryptogram that is generated within the payer's mobile phone. The method allows the payment to be processed immediately and, in principle, to immediately receive the money received to the recipient's account.
Niektoré hardvérové prvky tohto vynálezu nadväzujú na skôr prihlásené patentové prihlášky SK PP 32-2009 z 3.5.2009 (EMV terminál na SD karte), SK PP 50016-2010 z 19.4.2010 (Payment Button).Some hardware elements of the present invention follow the previously filed patent applications SK PP 32-2009 of May 3, 2009 (EMV terminal on SD card), SK PP 50016-2010 of April 19, 2010 (Payment Button).
Doterajší stav technikyBACKGROUND OF THE INVENTION
Existujú viaceré známe systémy platieb P2P (person to person), ktoré používajú mobilný telefón. Podľa zverejnenej medzinárodnej prihlášky WO 2008/027620 je známy systém, ktorý umožňuje platby P2P alebo P2M (person to merchant), pri ktorom majú zúčastnení platcovia alebo príjemcovia platby mobilný telefón, ktorého telefónne číslo alebo iný identifikátor slúži na priraďovanie účastníka v systéme. Tento systém ako tiež veľké množstvo iných podobných usporiadaní, napr. KR 2001-25740, používa mobilný telefón len ako nástroj na ovládanie platobných aplikácií, ktoré prebiehajú v zúčtovacom centre. V týchto systémoch je mobilný telefón v podstate len rozhraním na ovládanie platieb. Takéto usporiadanie prináša problémy s celkovou bezpečnosťou vykonávaných platieb, kde komunikačná cesta medzi mobilným telefónom a zúčtovacím centrom nedosahuje napríklad štandardy EMV (Europay MasterCard VISA). Tiež je nevýhodou, že takto koncipované riešenia si vyžadujú úplnú zmenu platobných aplikácií na strane prijímacej banky, prípadne vydavateľa karty.There are several known P2P (person to person) payment systems that use a mobile phone. According to published international application WO 2008/027620, a system is known which enables P2P or P2M (person to merchant) payments in which the payers or payees involved have a mobile phone whose telephone number or other identifier is used to assign a subscriber in the system. This system as well as a large number of other similar arrangements, e.g. KR 2001-25740, uses the mobile phone only as a tool to control the payment applications that take place in the clearing center. In these systems, a mobile phone is essentially just a payment control interface. Such an arrangement raises problems with the overall security of the payments made, where the communication path between the mobile phone and the clearing center does not reach, for example, the EMC (Europay MasterCard VISA) standards. It is also a disadvantage that the solutions thus conceived require a complete change of payment applications on the part of the receiving bank or the card issuer.
Je žiadané také technické riešenie, ktoré bude mať vysokú bezpečnosť EMV platobnej aplikácie, bude produkovať výsledné platobné kryptogramy práve vo formáteIt is required such a technical solution that will have high security EMV payment application, will produce the resulting payment cryptograms just in the format
EMV štandardov, bude využívať štruktúru kryptogramov, ktoré sa už využívajú pri spracovaní platieb z POS (point of sále) terminálov. Takéto riešenie zatiaľ nie je známe alebo má bezpečnostné riziká, ktoré spočívajú v tom, že pri prenose údajov z platobnej karty platiaceho zákazníka do vzdialeného POS terminálu alebo virtuálneho POS terminálu obchodníka môže dôjsť k odhaleniu a zneužitiu takto komunikovaných dát.EMV standards, will use the structure of cryptograms, which are already used in processing payments from POS (point of hall) terminals. Such a solution is not yet known or has security risks that transferring data from a paying customer's payment card to a remote POS terminal or a merchant's virtual POS terminal may reveal and misuse the data thus communicated.
Podstata vynálezuSUMMARY OF THE INVENTION
Uvedené nedostatky v podstatnej miere odstraňuje spôsob bezhotovostného prevodu peňazí z osoby na osobu prostredníctvom mobilného telefónu, pri ktorom sa tvorí platobný kryptogram so štruktúrou zodpovedajúcou platobnému kryptogramu POS terminálu podľa tohto vynálezu, ktorého podstata spočíva vtom, že mobilný telefón platcu si z centrály vyžiada konfiguračné dáta platobného terminálu prislúchajúce príjemcovi platby a pomocou týchto konfiguračných dát sa v rámci mobilného telefónu nakonfiguruje a spustí platobný terminál. Mobilný telefón platcu v sebe teda zahŕňa indiferentný POS terminál, ktorý sa môže po nakonfigurovaní príslušných dát navonok správať ako terminál v držbe rôznych osôb. Počiatočná indiferentnosť terminálu umožňuje zahrnúť do systému rôzne banky príjemcu. Pod pojem mobilný telefón je potrebné pre účely predloženého opisu a nárokov zahrnúť akékoľvek mobilné komunikačné zariadenie, teda aj PDA (personál digital assistant), tablety, notebooky opatrené príslušným modemom a podobne.The aforementioned drawbacks are substantially eliminated by the method of cashless transfer of money from person to person via a mobile phone, which creates a payment cryptogram with a structure corresponding to the payment cryptogram of a POS terminal according to the invention, which consists in requiring the payer's mobile phone the payment terminal belonging to the payee and using this configuration data, the payment terminal is configured and executed within the mobile phone. The payer's mobile phone thus comprises an indifferent POS terminal which, after configuring the relevant data, may behave externally as a terminal held by different persons. The initial terminal indifference makes it possible to include different recipient banks in the system. For the purposes of the present description and claims, the term mobile phone is intended to include any mobile communication device, including PDAs, tablets, laptops provided with a corresponding modem, and the like.
Po nakonfigurovaní príslušného platobného terminálu bude prebiehať platobnoterminálová aplikácia v princípe tak, akoby sa jednalo o platbu v klasickom POS terminály kamennej predajne. Komunikácia medzi vybranou platobnou kartou a nakonfigurovaným POS terminálom môže prebiehať tak, že platobná karta je priamo obsiahnutá v rámci mobilného telefónu platcu. V takom prípade sa vylúči bezpečnostné riziko vyplývajúce z načítavania platobnej karty v neznámom terminály, prípadne zasielanie údajov o platobnej karte cez mobilnú sieť alebo internet.After configuring the respective payment terminal, the payment terminal application will operate as if it were a payment in a classic POS terminal of a brick and mortar store. The communication between the selected payment card and the configured POS terminal may be such that the payment card is directly contained within the payer's mobile phone. In this case, the security risk resulting from reading the payment card in an unknown terminal or sending the payment card data via the mobile network or the Internet is excluded.
Vo výhodnom usporiadaní, ktoré pramení z hardvérových prvkov podľa skorších patentových prihlášok Logomotion, bude platba prebiehať tak, že platobno-terminálová aplikácia bude uložená na vyberateľnej pamäťovej karte, napríklad formátu micro SD karty, kde bude tiež uložená jedna alebo viacero platobných kariet. Platobnoterminálová aplikácia a platobné karty môžu byť uložené na samostatných SecureIn a preferred arrangement that stems from the hardware elements of earlier Logomotion patent applications, payment will be effected by the payment terminal application being stored on a removable memory card, for example a micro SD card format, where one or more payment cards will also be stored. The payment terminal application and payment cards can be stored on separate Secure
Elementoch vyberateľnej pamäťovej karty alebo na oddelených doménach jedného Secure Elementu.Removable memory card elements or on separate domains of a single Secure Element.
Platca musí mať mobilný telefón schopný vykonávať platobno-terminálovú aplikáciu a platca sa tiež musí zaregistrovať vo svojej banke ako klient systému P2P podľa tohto vynálezu. Príjemca platby môže, ale nemusí mať mobilný telefón schopný vykonávať platobno-terminálovú aplikáciu, musí sa však tiež zaregistrovať vo svojej banke ako klient systému P2P podľa tohto vynálezu, kde tiež poskytne údaje o svojom telefónnom čísle a/alebo aj e-maily.The payer must have a mobile phone capable of executing the payment-terminal application and the payer must also register with his bank as a P2P client according to the present invention. The payee may or may not have a mobile phone capable of executing a payment-terminal application, but must also register with his bank as a P2P client according to the present invention, where he will also provide his telephone number and / or e-mail information.
Centrála vybavená príslušným serverom spája a smeruje informačné toky od jednotlivých účastníkov systému. Po spustení platobnej aplikácie prichádza do centrály z mobilného telefónu platcu vyžiadanie konfiguračných dát, ktoré prislúchajú zvolenému príjemcovi. V centrále sa na základe zadaného telefónneho čísla príjemcu alebo jeho mena najskôr skontroluje príslušnosť zadaného príjemcu do systému P2P. Potom sa k tomuto vyžiadaniu priradia konfiguračné dáta banky príjemcu a zašlú sa do mobilného telefónu platcu. V mobilnom telefóne platcu sa môžu tieto konfiguračné dáta uchovať kmeňu príjemcu v telefónnom zozname, ktorý je bežne uložený v rámci mobilného telefónu. V takom prípade sa opakované platby rovnakému príjemcovi môžu uskutočniť už bež vyžiadania konfiguračných dát banky príjemcu.The central office equipped with the appropriate server connects and routes information flows from individual system participants. After the payment application is started, the payee's mobile phone requests the configuration data that belongs to the selected payee. At the headquarters, the recipient's phone number or name is first checked to identify the recipient's affiliation with P2P. The recipient's bank configuration data is then associated with this request and sent to the payer's mobile phone. In the payer's mobile phone, these configuration data can be stored in the payee tribe in a phonebook that is normally stored within the mobile phone. In this case, recurring payments to the same payee can already be made by requesting the payee bank configuration data.
Po nakonfigurovaní indiferentného POS terminálu v rámci mobilného telefónu platcu sa rozbehne platobno-terminálová aplikácia tak, že mobilný telefón sa stáva POS terminálom v správe príslušnej banky príjemcu. Platca zadá sumu, ktorú chce príjemcovi poslať a EMV procesor požiadavku spracuje, pričom výsledkom spracovania je kryptogram štruktúry TC (Transaction Certificate) off-linová platba povolená alebo AAC (Application Authentication Cryptogram) platba zamietnutá, prípadne ARQC (Authorization Request Cryptogram) on-linová platba. Výsledok platobnej aplikácie na výstupe z mobilného telefónu platcu má z pohľadu banky príjemcu štandardnú štruktúru ako majú aj iné operácie na ktoromkoľvek jej terminály. Mobilný telefón odošle kryptogram cez GSM komunikačný kanál na centrálu. Tu sa kryptogram dočasne uloží pre prípad, že požiadavka o prevod peňazí zlyhá v dôsledku poruchy na prenosovej trase. Server centrály kryptogram dekryptuje a podľa kódu banky príjemcu odošle tento kryptogram k príslušnej banke príjemcu.After configuring the indifferent POS terminal within the payer's mobile phone, the payment-terminal application is started so that the mobile phone becomes the POS terminal in the message of the respective payee bank. The payer enters the amount he wants to send to the recipient and the EMV processor processes the request, resulting in a processing cryptogram of the TC (Transaction Certificate) off-line payment enabled or AAC (Application Authentication Cryptogram) payment declined or ARQC (Authorization Request Cryptogram) online payment. From the perspective of the payee's bank, the result of the payment application on the payer's mobile phone output has a standard structure, as do other operations at any of its terminals. The mobile phone sends the cryptogram via the GSM communication channel to the central office. Here the cryptogram is temporarily stored in case the money transfer request fails due to a transmission line failure. The headquarters server decrypts the cryptogram and sends the cryptogram to the recipient bank according to the recipient's bank code.
Banka príjemcu si vo svojej databáze overí existenciu telefónneho čísla alebo emailu príjemcu a priradí k nemu skutočný účet príjemcu. Zároveň pokračuje spracovanie transakcie rovnakým spôsobom ako v prípade fyzického POS terminálu na pulte banky. V prípade kryptogramu ARQC požiada o on-line autorizáciu v banke vydavateľa platobnej karty platcu. V prípade kryptogramu TC je platba autorizovaná ako off-line.The recipient's bank verifies the existence of the recipient's phone number or email in its database and associates it with the actual recipient's account. At the same time, transaction processing continues in the same way as in the case of a physical POS terminal on the bank's counter. In the case of the ARQC cryptogram, it asks for online authorization at the bank of the payer's credit card issuer. In the case of the TC cryptogram, the payment is authorized off-line.
Banka príjemcu oznámi príjemcovi cez SMS, že na jeho účet prišla platba. V prípade, že aj príjemca má v mobilnom telefóne vyberateľnú pamäťovú kartu podobnej štruktúry ako platca, môže si príjemca tieto peniaze prevziať a dobiť priamo na vyberateľnú pamäťovú kartu.The beneficiary's bank will notify the beneficiary via SMS that a payment has arrived on his account. If the recipient also has a removable memory card similar in structure to the payer in the mobile phone, the recipient can take the money and recharge it directly to the removable memory card.
Ak nastane situácia, že v databáze banky príjemcu sa nenachádza príslušné telefónne číslo alebo email príjemcu a platobný kryptogram bol typu TC, čiže peniaze už boli odčítané z karty platcu, tak banka príjemcu požiada vydavateľa karty platcu o reverznú platobnú operáciu, aby sa peniaze vrátili späť na kartu platcu, keďže ich nie je možné previesť určenému príjemcovi. Vtedy sa využije kryptogram tvaru AAR, ktorý z centrály odíde na mobilný telefón platcu spolu aj so správnymi údajmi o banke príjemcu, aby platca pri druhom pokuse mal už správne konfiguračné dáta.If the payee's bank database does not contain the recipient's phone number or email and the payment cryptogram was TC, so the money has already been debited from the payer's card, the payee's bank will ask the card issuer for a reverse payment transaction to return the money to the payer card as they cannot be transferred to the designated payee. In this case, the AAR-shaped cryptogram is used, which is sent from the central office to the payer's mobile phone, together with the correct payee bank details, so that the payer has the correct configuration data on the second attempt.
V prípade úspešného spracovania platby sa odpoveď banky príjemcu v tvare ARQC zašle do mobilného telefónu platcu, ktorý ho posunie na vyberateľnú pamäťovú kartu. Tam sa kryptogram dešifruje a výsledok spracovania sa zapíše do databázy. Tento krok umožní vymazať dočasne vymazaný kryptogram ARQC. Platcovi sa na mobilnom telefóne zobrazí výsledok celého platobného procesu.If the payment is successfully processed, the ARQC recipient's bank response is sent to the payer's mobile phone, which sends it to a removable memory card. There the cryptogram is decrypted and the result of the processing is written to the database. This step allows you to clear the temporarily deleted ARQC cryptogram. The payer will see the result of the entire payment process on their mobile phone.
V prípade, že mobilný telefón máme očakáva odpoveď ARQC a v nastavenom Časovom limite ju neobdrží, vyzve platcu, aby zadal, či si praje transakciu zopakovať. Ak áno, odošle dočasne uchované ARQC ešte raz do centrály. Toto uchovanie umožní, že na strane banky príjemcu sa dá overiť, že sa jedná o opakovaný priebeh už raz rozbehnutej platobnej aplikácie. Ak sa v banke príjemcu zistí, že zhodný kryptogram ARQC bol už úspešne použitý na vykonanie platby, oznámi tento výsledok ešte raz tento výsledok do mobilného telefónu platcu, ak sa naopak zistí, že tento kryptogram ARQC ešte nebol spracovávaný, uskutoční túto transakciu ako novú. Tieto spätné väzby umožňujú vyhnúť sa nedokončeným operáciám pri zlyhaní informačného toku v ktorejkoľvek časti platobnej transakcie.If the mobile phone has an ARQC response and does not receive it within the set time limit, it will ask the payer to specify whether it wishes to repeat the transaction. If so, he will send the temporarily stored ARQC to the headquarters again. This preservation will allow the payee bank to verify that the payment application is running again. If the beneficiary's bank finds that the same ARQC cryptogram has already been successfully used to make a payment, it will report this result once more to the payer's mobile phone, but if it is found that the ARQC cryptogram has not yet been processed, it will execute the transaction as new. These feedbacks help to avoid unfinished operations in the case of a failure of the information flow in any part of the payment transaction.
Prehľad obrázkov na výkresochBRIEF DESCRIPTION OF THE DRAWINGS
Vynález je bližšie vysvetlený pomocou obrázku 1 až 8.The invention is explained in more detail by means of Figures 1 to 8.
Na obrázku 1 je znázornená bloková schéma vzťahov medzi účastníkmi systému P2P aj s možnosťou priameho načítavania konfiguračných dát z banky príjemcu.Figure 1 shows a block diagram of relationships between P2P participants, with the possibility of directly retrieving configuration data from the recipient's bank.
Na obrázku 2 je znázornená štruktúra dát u jednotlivých účastníkov systému P2M a niektoré statické vzťahy medzi účastníkmi.Figure 2 illustrates the data structure of individual P2M subscribers and some static subscriber relationships.
Na obrázkoch 3 a 4 je znázornený priebeh úloh a tok dát v systéme P2P / P2M. Schéma je prehľadnosť prerušená, rozdelená na dve strany prostredníctvom označenia A - prerušenie toku a označenia A' - pokračovanie toku.Figures 3 and 4 show the flow of tasks and data flow in the P2P / P2M system. The diagram is broken, divided into two pages by means of the designation A - flow interruption and the designation A '- continuation of the flow.
Na obrázku 5 je znázornená činnosť nakonfigurovaného POS terminálu v rámci vyberateľnej pamäťovej karty microSD formátu. Zobrazený pomer veľkostí medzi vyberateľnou pamäťovou kartou a mobilným komunikačným prostriedkom nie je predmetom ochrany, nie je v mierke, má za úlohu zvýšiť jasnosť zobrazenia a nie je ho preto možné z hľadiska rozsahu ochrany vysvetľovať zužujúco.Figure 5 shows the operation of the configured POS terminal within a removable microSD format memory card. The size ratio displayed between the removable memory card and the mobile communication device is not subject to protection, is not to scale, is intended to increase display clarity and is therefore not to be construed narrowly in terms of the scope of protection.
Na obrázku 6 je vyobrazený priebeh registrácie osôb platcu a príjemcu v centrále cez vlastnú banku účastníkov ako predpríprava na vykonávanie spôsobu podľa tohto opisu. Na obrázku 7 je priebeh úloh medzi jednotlivými účastníkmi systému pri EMV platbe s využitím konfiguračných ACQ údajov príjemcu.Figure 6 illustrates the course of registration of payer and payee persons at headquarters through their own subscriber bank as a preparation for performing the method of the present disclosure. Figure 7 shows the progress of tasks between individual system participants in an EMV payment using the recipient ACQ configuration data.
Na obrázku 8 je vyobrazený pozmenený priebeh úloh predchádzajúceho obrázku 7 a to od úlohy č. 53, kedy sa medzi jednotlivými účastníkmi systému pri EMV platbe využívajú konfiguračné ACQ údaje príjemcu a potvrdenie platby platcom je zrealizované ako druhá EMV transakcia.Figure 8 shows the modified flow of the tasks of Figure 7, starting from task no. 53, where the recipient's ACQ configuration data is used for the EMV payment between individual participants in the system and the payment confirmation by the payer is executed as a second EMV transaction.
Príklady uskutočnenia vynálezuDETAILED DESCRIPTION OF THE INVENTION
Príklad 1Example 1
V tomto príklade podľa obrázkov 1 až 5 je opísaný systém s jednou centrálou so serverom, s viacerými vydavateľmi 5 platobných kariet 9, s viacerými bankami 2 príjemcov 7 a skupinou užívateľov, ktorí môžu byť platcami 6 alebo aj príjemcami 7 peňazí.In this example of Figures 1 to 5, there is described a single-headed server system, multiple card issuers 5, multiple payee banks 2, and a group of users who may be payers 6 or even payees 7 of money.
Väčšina užívateľov má vo svojich mobilných telefónoch vložené Logomotiom microSD karty, na ktorých je okrem iného secure element s indiferentnou platobnoterminálovou aplikáciou a viaceré secure elementy so samostatnými platobnými kartami 9. Užívateľ týmto hardvérovým zapojením získa EMV procesor kontaktne spolupracujúci s jeho platobnými kartami 9. Všetci užívatelia sú vo svojej banke prihlásení ako užívatelia P2P systému, kde poskytli údaj o svojom telefónom čísle alebo aspoň e-maily.Most users have in their mobile phones embedded Logomotiom microSD cards, which include, among other things, a secure element with indifferent payment terminal application and several secure elements with separate payment cards 9. The user gets this hardware connection EMV processor cooperating with his payment cards 9. All users they are logged in to their bank as P2P users, providing their phone number or at least emails.
Banka 2 na strane príjemcu 7 platby stanovuje konfiguračné dáta pre vytvorenie POS terminálu 8 pre konkrétny prevod na účet svojho klienta. S bankou tieto dáta na základe zmluvy zdieľa centrála i, kde sú telefónne čísla, prípadne e-maily priradené k príslušným konfiguračným dátam. Súčasťou systému je dátové spojenie, ktoré zabezpečuje mobilný telefón na báze GPRS alebo SMS.On the payee side 7, the bank 2 determines the configuration data for creating a POS terminal 8 for a specific transfer to its client's account. Based on the agreement, the central office shares this data with the bank, where the telephone numbers and / or e-mails are assigned to the respective configuration data. Part of the system is a data connection, which provides a mobile phone based on GPRS or SMS.
Platca 6 si na svojom mobilnom telefóne 4 cez GUI (Graphical user interface) spustí aplikáciu na prevod peňazí. Do mobilného telefónu 4 zadá telefónne číslo, prípadne e-mail alebo meno príjemcu 7. Mobilný telefón 4 odošle identifikáciu príjemcu 7 do centrály £, kde sa na v databáze servera v prvom kroku najskôr overí, či príjemca 7 je registrovaný ako užívateľ tohto systému. Ak áno, centrála £ zašle do mobilného telefónu 4 informáciu, akú má príjemca 7 banku 2, ktorá je zároveň súčasťou tohto P2P systému. V tomto príklade to môže byť banka označená ako XYZ. Mobilný telefón 4 platcu 6 opatrený microSD kartou Logomotion vyšle na server banky 2 príjemcu 7 vyžiadanie konfiguračných dát pre konkrétnu platbu v prospech príjemcu 7. K týmto konfiguračným dátam centrála £ priradí kód banky.Payer 6 launches a money transfer application on his mobile phone 4 via a GUI (Graphical user interface). The mobile phone 4 sends the identification number of the recipient 7 to the central office 6, where it is first verified in the server database that the recipient 7 is registered as a user of the system. If so, the central office 4 sends to the mobile phone 4 information such as the recipient 7 has a bank 2 which is also part of this P2P system. In this example, it could be a bank labeled XYZ. The payee mobile phone 4 provided with the Logomotion microSD card sends to the payee bank server 2 a request for configuration data for a specific payment to the payee 7. The central office 8 assigns the bank code to these configuration data.
Zaslanie konfiguračných dát do mobilného telefónu 4 platcu 6 spustí vytvorenie konkrétneho POS terminálu 8, teraz terminálu banky XYZ. Konfiguračné parametre sú zakryptované 3DES a dekryptovanie v tomto prípade prebieha na šifrovacom bloku v secure elemente na vyberateľnej pamäťovej karte 3. Na dešifrovanie sa použije jednorazový kľúč. V podstate sa pre túto platobnú transakciu mobilný telefón 4 správa a navonok javí ako POS terminál 8 v držbe príjemcu 7 platby, aj keď je v skutočnosti mobilný telefón 4 vlastnený platcom 6 a platca 6 ho aj obsluhuje.Sending the configuration data to the payer 6 mobile phone 4 will trigger the creation of a particular POS terminal 8, now the XYZ bank terminal. The configuration parameters are encrypted by 3DES and in this case the decrypting takes place on the encryption block in the secure element on the removable memory card 3. A one-time key is used for decryption. Essentially, for this payment transaction, the mobile phone 4 is managed and externally appears as a POS terminal 8 held by the payee 7, even though the mobile phone 4 is in fact owned by the payer 6 and the payer 6 also operates it.
Teraz platca 6 zadá prostredníctvom klávesnice sumu peňazí, ktorú chce previesť na účet príjemcu 7. Podľa zvolenej sumy peňazí a risk manažmentu platobnej karty 9 sa rozhodne, či bude táto platba off-linová alebo on-linová. Platca 6 má možnosť vybrať si z viacerých platobných kariet 9, ktoré sú uložené na jeho vyberateľnej pamäťovej karte 3 v mobilnom telefóne 4. Výsledkom platobno-terminálovej aplikácie prebiehajúcej na vyberateľnej pamäťovej karte 3 je kryptogram v tvare TC (akceptovaná off-line platba) alebo ARQC, kedy je potrebná on-line autorizácia, prípadne v tvare AAC, kedy je platba zamietnutá. Výsledný kryptogram šifrovaný v bloku šifrovania priamo na vyberateľnej pamäťovej karte 3 sa uloží do pamäti a POS terminál 8 pozastaví svoju platobnoterminálovú aplikáciu až do momentu prijatia kryptogramu ARPC.Now the payer 6 enters the amount of money he wishes to transfer to the payee's account 7 via the keypad. Depending on the amount of money and the risk management of the payment card 9, it is decided whether the payment will be off-line or on-line. The payer 6 has the possibility to choose from several payment cards 9 stored on his removable memory card 3 in the mobile phone 4. The payment terminal application running on the removable memory card 3 results in a TC-shaped cryptogram (accepted off-line payment) or ARQC when online authorization is needed, or in the form of AAC when payment is declined. The resulting cryptogram encrypted in the encryption block directly on the removable memory card 3 is stored and the POS terminal 8 suspends its payment terminal application until it receives the ARPC cryptogram.
Rozhranie nainštalované v mobilnom telefóne 4 prevezme z -vyberateľnej pamäťovej karty 3 kryptogram a odošle ho prostredníctvom dátovej SMS alebo pomocou prenosu GPRS do centrály i, kde sa tento kryptogram uchová v pamäti a to aspoň dočasne pre prípad zlyhania komunikačných tokov. Server centrály i dekryptuje prevzatý kryptogram a podľa kódu banky 2 príjemcu 7 odošle na spracovanie príslušnej banke. Tá kryptogram dešifruje a podľa telefónneho čísla obsiahnutého v kryptograme priradí príjemcovi 7 jeho skutočný účet. Banka oznámi príjemcovi 7 cez SMS, že na jeho účet prišla platba a odošle odpoveď v tvare kryptogramu ARPC do centrály L V centrále 1 sa odpoveď zašifruje a odošle platcovi 6 na jeho mobilný telefón 4. Tam sa kryptogram dešifruje na vyberateľnej pamäťovej karte 3 a dokončí sa druhá fáza transakcie, kedy sa zmaže dočasne uchované ARQC. Výsledok sa zapíše do pamäti na vyberateľnej pamäťovej karte 3 a o úspešnom prevode peňazí je platca 6 informovaný na displeji mobilného telefónu 4.The interface installed in the mobile phone 4 takes the cryptogram from the removable memory card 3 and sends it via data SMS or GPRS transmission to the central office 1, where the cryptogram is stored in memory at least temporarily in case of communication flow failure. The central server 1 decrypts the downloaded cryptogram and sends it to the appropriate bank for processing according to the bank code 2 of the recipient 7. The cryptogram decrypts and assigns the recipient 7's real account to the recipient 7 according to the phone number contained in the cryptogram. The bank notifies the recipient 7 via SMS that a payment has arrived on his account and sends an ARPC cryptogram reply to the LV headquarters 1, the response is encrypted and sent to payer 6 on his mobile phone 4. There the cryptogram is decrypted second phase of the transaction, where the temporarily retained ARQC is deleted. The result is stored in the removable memory card 3 and the payer 6 is informed on the successful transfer of money on the mobile phone display 4.
Príklad 2Example 2
Platca 6 posiela peniaze príjemcovi 7 cez systém P2P. V tomto príklade platca 6 i príjemca 7 majú LGM vyberateľnú kartu 3 formátu micro SD a obaja sú registrovaní v systéme P2P u svojej banky, ktorá im vydala platobnú kartu 9, a ktorá tiež s ich súhlasom zaslala ich údaje do centrály i. Aplikácia v mobilnom telefóne 4 platcu 6 je doplnená o funkčnosti P2P platieb (registrácia, posielanie platieb, príjem platieb).Payer 6 sends money to recipient 7 via P2P. In this example, payer 6 and payee 7 both have a LGM removable micro SD card 3 and are both registered in P2P with their bank that issued the payment card 9 and who also sent their data to headquarters i with their consent. The application in the mobile phone 4 of the payer 6 is completed with the functionality of P2P payments (registration, sending payments, receiving payments).
V tomto príklade sa platby budú realizovať ako EMV transakcie s využitím EMV procesora nastaveného v prospech príjemcu 7 platby. Ku každej LGM karte existuje účet u vydavateľa 5 v prospech držiteľa karty. Z tohto účtu (na tento účet) sú prevádzané (uskutočňované) prevody peňazí.In this example, payments will be made as EMV transactions using the EMV processor set up for the payee 7. For each LGM card there is an account with the issuer 5 in favor of the cardholder. Money transfers are being made to this account.
Priebeh registrácie je zobrazený na obrázku 6. Platca 6 aj príjemca 7 (PERSON 1, PERSON 2) sa v kroku 21 registrujú u svojej issuerskej, vydavateľskej banky 5 pomocou svojho telefónneho čísla. Issuerská, vydavateľská banka 5 spravuje tabuľku vydaných LGM kariet vrátane týchto údajov:The progress of the registration is shown in Fig. 6. Both the payer 6 and the payee 7 (PERSON 1, PERSON 2) are registered with their issuing bank 5 in step 21 using their telephone number. Issuer Bank 5 maintains a table of issued LGM cards, including the following:
- účet príslušný ku karte (Card account), z ktorého (na ktorý) sú peniaze prevádzané,- the card account from which the money is transferred,
- identifikácia osoby (Person ID), ktorá slúži k dodatočnej identifikácii platcu 6 pri potvrdzovaní platieb,- the Person ID used to identify the payer 6 additionally when confirming payments,
- acquirer (banka 2 príjemcu 7), s ktorým má Issuer, vydavateľ dohodu o prevádzke P2P platieb. Pritom je možné, aby pre banku 2 príjemcu 7 acquirerské, nadobúdateľské činnosti zabezpečoval zmluvný platobný procesor partnera,- the acquirer (bank 2 of the recipient 7) with which the Issuer, the publisher, has an agreement to operate P2P payments. At the same time, it is possible for the beneficiary's bank 2 to acquire the acquirer's acquisition activities by a partner's payment processor,
- telefónne číslo, ktoré slúži ako základný identifikátor v systéme P2P,- A phone number that serves as the base identifier in P2P
- príznak úspešnej registrácie pre P2P platby (P2P allowed).- flag of successful registration for P2P payments (P2P allowed).
V kroku 22 issuer, vydavateľ posiela informácie získané pri registrácii svojmu zmluvnému acquirerovi, nadobúdateľovi: telefónne číslo, identifikáciu osoby, účet. Acquirer, nadobúdateľ tieto údaje uchováva a spravuje.In step 22, the issuer sends the information obtained upon registration to its contracting acquirer, the acquirer: telephone number, person identification, account. Acquirer, the Acquirer shall store and manage this data.
Centrum označené ako LGM P2P slúži ako smerovacia, routovacia tabuľka medzi jednotlivými acquirermi. V kroku 23 centrum LGM P2P získa pri registrácii nasledujúce údaje: telefónne číslo, identifikáciu osoby a URL adresu Acquirera (ACQ URL). ACQ URL je adresa, kam presmeruje platcu 6 pre získanie konfiguračných dát pre EMV proces v prospech príjemcu 7. LGM P2P Centrum v usporiadaní podľa tohto príkladu nespravuje žiadne citlivé údaje ani nie je priamo zapojené do vlastnej finančnej transakcie.The center designated as LGM P2P serves as a routing table between the acquirers. In step 23, LGM P2P will receive the following information when registering: phone number, person ID, and Acquirera URL (ACQ URL). The ACQ URL is the address where it redirects the payer 6 to obtain configuration data for the EMV process to the benefit of the recipient 7. The LGM P2P Center in this example does not manage any sensitive data or is not directly involved in its own financial transaction.
Priebeh platby v jednej z možných verzií je vyobrazený na obrázku 7. Postup sa skladá z odoslania platby, potvrdenia prijatia platby a vlastného prevodu peňazí. Postup je nasledujúci:The payment process in one of the possible versions is shown in Figure 7. The procedure consists of sending the payment, confirming the receipt of the payment and the actual money transfer. Here's how:
Odosielateľ platby spustí LGMCard aplikáciu. Vyberie P2P platby, zadá telefónne číslo príjemcu 7 a to priamo alebo výberom z telefónneho zoznamu, zadá čiastku priamo alebo ponukou z bežne zasielaných čiastok a zvolí „Odoslať“. Prebehne komunikácia v krokoch 31 až 39. Tým je platba odoslaná.The payer will launch the LGMCard app. It selects P2P payments, enters the recipient's phone number 7 directly or by selecting it from the phone book, enters the amount directly or by offering from the amounts normally sent and selects "Send". Communicate in steps 31 through 39. This sends the payment.
Platba je autorizovaná offline, pokiaľ to umožňuje okolnosti a nastevenia alebo on-line. On-line autorizácia v banke 5 vydavateľa karty platcu 6 súčasne umožní zaslanie pokynu, skriptu banky 5 vydavateľa karty do karty na vyberateľnej pamäťovej karte 3, napr. pre reset počítadla platobnej karty 9. Vlastná platba prebehne na EMV procesore s využitím konfiguračných dát banky 2 príjemcu 7 platby (obdobne ako napr. u LCT alebo m-platieb).Payment is authorized offline if circumstances and settings allow or online. At the same time, on-line authorization in the card issuer bank 5 of the payer card 6 allows for sending an instruction, a script of the card issuer bank 5 to the card on a removable memory card 3, e.g. to reset the credit card counter 9. The actual payment will be made on the EMV processor using the configuration data of the bank 2 of the payee 7 (similar to, for example, LCT or m-payments).
V druhej časti môže banka 2 príjemcu 7 vyzvať k potvrdeniu platby. Príjemca 7 je informovaný o tom, kto mu platbu zasiela prostredníctvom Person ID platcu 6 a tiež je informovaný o zasielanej čiastke. Pokiaľ príjemca 7 do stanovenej doby (napr. do 3 dní) prijatie platby nepotvrdí, transakcia sa automaticky zruší. Potvrdenie prijatia platby nie je v princípe v inom príklade nevyhnutné, prebieha v krokoch 40 až 43.In the second part, the bank 2 may ask the beneficiary 7 to confirm the payment. The payee 7 is informed of who sends the payment via the Payee's Person ID 6 and is also informed of the amount sent. If the payee 7 does not acknowledge receipt of the payment within a specified period (eg within 3 days), the transaction is automatically canceled. Confirmation of receipt of payment is not in principle necessary in another example, it proceeds in steps 40 to 43.
Po úspešnom potvrdení príjemcom 7 platby je pripravená transakcia posunutá na ďalšie spracovanie (clearing + settlement). Platba príde na špeciálny (Jumbo) účet banky 2 príjemcu 7 a je prevedená v rámci banky na účet príjemcu 7. Pretože Acquirer môže pracovať pre viacero vydavateľských issuerských bánk 5, má zriadený Jumbo účet pre každého vydavateľa, issuera.After successful confirmation by the payee 7, the prepared transaction is postponed for further processing (clearing + settlement). The payment comes to a special (Jumbo) account of the beneficiary's bank 2 and is transferred within the bank to the beneficiary's account 7. Since Acquirer can work for several issuing issuing banks 5, it has a Jumbo account for each issuer, the issuer.
Pretože banka má potvrdené, že transakcia je schválená, môže banka 2 peniaze príjemcovi 7 pripísať skôr, než peniaze fyzicky dostane na účet. Napr. môže zvýhodniť P2P platby medzi účtami vlastných klientov. Samotný presun peňazí je opísaný v krokoch 44 až 48.Since the bank has confirmed that the transaction is approved, the bank 2 can credit the money to the recipient 7 before it physically receives the account. E.g. can favor P2P payments between accounts of its own clients. Money transfer itself is described in steps 44 to 48.
Platca 6 (PERSON 1) je spojený s centrálou j. LGM P2P, jeho URL adresa je uložená v aplikácii. Systém v kroku 31 preverí, či sú platca 6 a príjemca 7 (PERSON 2) registrovaní pre P2P platby na základe telefónnych čísiel Phone nr 1 a Phone nr 2. Pokiaľ áno, v kroku 32 centrála i LGM P2P vracia URL adresu Acquirera príjemcu 7 platby (ACQ URL 2) prislúchajúcu telefónnemu číslu príjemcu 7 (Phone nr 2). Pokiaľ nie, platca 6 je informovaný, že platba sa nedá odoslať. Platca 6 je v kroku 33 presmerovaný na URL adresu Acquirera príjemcu 7 platby.Platter 6 (PERSON 1) is connected to headquarters j. LGM P2P, its URL is stored in the application. The system checks in step 31 that Payer 6 and Payee 7 (PERSON 2) are registered for P2P payments based on the Phone nr 1 and Phone nr 2 phone numbers. If so, in step 32 the LGM P2P headquarters returns the URL of Acquirer 7 (ACQ URL 2) corresponding to the recipient's phone number 7 (Phone nr 2). If not, the payer 6 is informed that the payment cannot be sent. In step 33, the payer 6 is redirected to the Acquirer URL of the payee 7.
Acquirer, banka 2 príjemcu 7 zasiela v kroku 34 konfiguračné dáta pre EMV procesor na prevedenie platby (ACQ2 confíg data). Komunikácia je zabezpečená štandardným spôsobom ako u ostatných use čase (handshake). V kroku 35 sa EMV procesor platcu 6 nakonfiguruje a vygeneruje sa transakcia - platba danej čiastky. Výsledok môže byť TC (offline autorizace úspešná) alebo ARQC (žiadosť o online autorizáciu). Pokiaľ karta transakciu odmietne (AAC), proces sa končí neúspešne.Acquirer, bank 2 of the recipient 7 sends in step 34 configuration data for the EMV processor to carry out the payment (ACQ2 config data). Communication is ensured in a standard way as with other use time (handshake). In step 35, the payer EMV processor 6 is configured and a transaction - payment of the amount is generated. The result can be TC (offline authorization successful) or ARQC (online authorization request). If the card declines the transaction (AAC), the process ends unsuccessfully.
Výsledok (TC/ARQC) je zaslaný v kroku 36 acquirerovi, banke 2 príjemcu 7. Záznam s transakciou je doplnený o jednoznačnú identifikáciu platcu 6 a príjemcu 7 platby (Phone nr 1, Phone nr 2) - na ďalšie spracovanie. Banka 2 príjemcu 7 má zriadenú bránu na prijímanie platieb a systém na autorizáciu platieb (ACQ2 P2P payment gate, ACQ2 P2P authorization). V prípade, že je požadovaná online autorizácia, prebehne v kroku 37 štandardné overenie v systéme vydavateľa karty platcu 6. Výsledok môže tiež obsahovať skript na vykonanie potrebnej operácie na karte platcu 6 (napr. sa dá takto vynulovať off-line počítadlo).The result (TC / ARQC) is sent in step 36 to the acquirer, bank 2 of the payee 7. The transaction record is accompanied by a unique identification of payer 6 and payee 7 (Phone nr 1, Phone nr 2) - for further processing. The payee bank 2 has a payment receiving gateway and a payment authorization system (ACQ2 P2P payment gateway). If online authorization is required, step 37 performs standard verification in the card issuer system 6. The result may also include a script to perform the necessary operation on the card 6 (e.g., an off-line counter can be reset).
Záznam o transakcii uloží Acquirer 2 v kroku 38 vo svojom úložisku P2P transakcií (ACQ2 P2P TRX store), kde čaká na potvrdenie príjemcom 7 platby. Zatiaľ nie je transakcia odoslaná k ďalšiemu spracovaniu. Ide o analógiu zablokovania čiastky pri bežnej platbe kartou u obchodníka. Pokiaľ všetko prebehne v poriadku, potvrdí Acquirer 2 v kroku 39 platcovi 6, že úspešne prijal požiadavku na odoslanie P2P platby. Súčasťou odpovede ARPC (u online autorizácie) môže byť skript, ktorý zasiela Issuer. EMV procesor dokončí transakciu a užívateľ je informovaný o úspešnom odoslaní peňazí. Banka 2 príjemcu 7 - acquirer 2 potrebuje v kroku 40 zaslať informáciu príjemcovi 7 platby. Pozná ale len telefónne číslo platcu 6 (môže byť klientom inej banky). Aby mohol príjemcu 7 informovať aj o mene odosielateľa (Person 1 ID), využije službu centrály ILGM P2P. Centrála 1LGM P2P vracia v kroku 41 k telefónnemu číslu platcu 6 (Phone nr 1) jeho Person ID 1. To, že existuje, už bolo overené v kroku 31.The transaction record is stored by Acquirer 2 in step 38 in its P2P transaction store (ACQ2 P2P TRX store) where it waits for confirmation by the payee 7. The transaction is not yet submitted for further processing. This is an analogy of blocking the amount for a normal card payment at a merchant. If all goes well, Acquirer 2 will confirm to step 6 in step 39 that it has successfully received a P2P payment request. The ARPC response (for online authorization) may include a script sent by the Issuer. The EMV processor completes the transaction and the user is informed of the successful sending of the money. The beneficiary bank 2 - the acquirer 2 needs to send information to the payee 7 in step 40. However, he only knows the payer's telephone number 6 (he may be a client of another bank). In order to inform the recipient 7 about the name of the sender (Person 1 ID), it uses the ILGM P2P headquarters service. In step 41, P2P P2P headquarters returns its Person ID 1 to Payer 6 (Phone nr 1). That existence has already been verified in step 31.
Banka 2 príjemcu 7 - acquirer 2 zasiela v kroku 42 informáciu príjemcovi 7 o čakajúcej platbe a to napríklad pomocou SMS. Súčasťou informácie je identifikácia platcu 6 (Person ID 1), čiastka a žiadosť o potvrdenie. Tento krok nie je v princípe nutný, alternatívne sa môže aplikácia v telefóne príjemcu 7 dopytovať na čakajúce prichádzajúce platby napr. vždy po spustení aplikácie.In step 42, the bank 2 of the recipient 7 - the acquirer 2 sends information to the recipient 7 about the pending payment, for example by SMS. The information includes payer identification 6 (Person ID 1), amount and confirmation request. This step is not necessary in principle; alternatively, the application on the recipient's phone 7 may request pending incoming payments e.g. every time you start the app.
Príjemca 7 platby v kroku 43 potvrdí späť, že súhlasí s prijatím peňazí. Vykoná tak pomocou SMS alebo výhodnejšie pomocou LGMCard mobilnej aplikácie, kedy si od banky 2 príjemcu 7 vyžiada a zobrazí zoznam prichádzajúcich platieb na schválenie a vykoná schválenie. Príslušnú URL banky 2 príjemcu 7 bude mať v tomto prípade uložené vo svojich konfiguračných dátach (je to Jeho“ Acquirer). Pokiaľ do stanoveného limitu príjemca 7 platbu nepotvrdí, transakcia je zrušená. Acquirer 2 môže prípadne informovať platcu 6, má u transakcie uložené jeho telefónne číslo.The payee 7 confirms back in step 43 that he agrees to receive the money. This is done by SMS or more preferably using the LGMCard mobile application, requesting from the bank 2 of the payee 7 and displaying a list of incoming payments for approval and executing the approval. In this case, the recipient 7's bank URL 2 will be stored in its configuration data (this is His Acquirer). If the payee 7 does not confirm the payment within the set limit, the transaction is canceled. Acquirer 2 may optionally inform the payer 6, having a phone number stored on the transaction.
Po úspešnom potvrdení príjemcom 7 platby v kroku 44 posunie banka 2 príjemcu 7 - Acquirer 2 transakciu na spracovanie (clearing + settlement). Výsledkom spracovania v kroku 45 je prevod príslušnej čiastky z účtu platcu 6 (Card account 1) na Jumbo účet banky 2 príjemcu 7 - acquirera 2. V kroku 46 je čiastka zaslaná v rámci banky na účet príjemcu 7 (Card account 2). Čiastka je pripísaná na účet príjemcu 7 (Card account 2) v kroku 47. Vydavateľ 5 karty - issuer 2 alebo banka 2 príjemcu 2 - acquirer 2 môžu informovať príjemcu 7 o dokončení prevodu v kroku 48.Upon successful confirmation by the payee 7 in step 44, the bank 2 of the payee 7 - Acquirer 2 shifts the clearing + settlement transaction. The processing in step 45 results in the transfer of the relevant amount from the card account 1 to the Jumbo account 2 of the acquirer 7 of the acquirer 2. In step 46, the amount is sent within the bank to the card account 2. The amount is credited to the Card account 2 in step 47. The card issuer 5 or the bank 2 of the acquirer 2 may inform the recipient 7 of the completion of the transfer in step 48.
Je možná tiež verzia postupu, kedy centrála i LGM P2P spravováva priamo konfiguračné dáta jednotlivých bánk 2 príjemcov 7. Výhodou by bola úspora 2 krokov a to krokov 32 a 33 a odohranie jednej úlohy - zasielanie konfiguračných dát - zo systému banky 2 príjemcu 7. V takom prípade centrála i spravuje citlivé dáta jednotlivých bánk 2 príjemcov 7.It is also possible to version the procedure where both the headquarters and LGM P2P directly manage the configuration data of each bank 2 recipients 7. The advantage would be saving 2 steps and steps 32 and 33 and playing one task - sending configuration data - from the system of 2 recipient bank 7. in this case, the head office i manages the sensitive data of the individual beneficiary banks 7.
Príklad 3Example 3
Verzia postupu podľa tohto príkladu zobrazeného na obrázku 8 má s príkladom 2 spoločné kroky 31 až 42. Odlišný je spôsob potvrdenia platby platcom 6, ktoré je realizované ako druhá EM V transakcia. To môže mať pozitívny vplyv na dôveryhodnosť potvrdenia platby a tým na rýchlosť, za ako dlho banka 2 príjemcovi 7 pripíše peniaze na účet. Navyše, pri druhej transakcii môže vydavateľ, issuer 2 poslať skript na LGMCard príjemcovi 7 platby, napr. na vynulovanie offline počítadla.The version of the procedure of this example shown in Figure 8 has common steps 31 to 42 with Example 2. The method of confirming the payment by the payer 6 is different as the second EM V transaction. This can have a positive effect on the credibility of the payment receipt and hence the rate at which the bank 2 will credit the beneficiary 7 with the money in the account. In addition, in the second transaction, the issuer 2 may send the script to the LGMCard recipient 7 of the payment, e.g. to reset the offline counter.
Prvá EMV transakcia generovaná platcom 6 je poslanie peňazí z účtu platcu 6 na Jumbo účet banky 2 príjemcu 7. Druhá transakcia, generovaná bankou 2 príjemcu 7 a potvrdená príjemcom 7, je poslanie peňazí z Jumbo účtu banky 2 príjemcu 7 na účet príjemcu 7 (reverzná transakcia). Tieto dve transakcie sa spárujú a posúvajú na spracovanie súčasne. Upravená časť príslušnej schémy je práve na obrázku 8.The first EMV transaction generated by payer 6 is the sending of money from the payer's account 6 to the Jumbo account of the beneficiary's bank 2. The second transaction generated by the bank of payee 7 and confirmed by the beneficiary 7 is the sending of money from the Jumbo account of beneficiary's bank 2 to the beneficiary 7 transaction). The two transactions are paired and pushed for processing at the same time. A modified part of the scheme is shown in Figure 8.
nn
Potvrdenie danej platby príjemca 2 začína v kroku 53 žiadosťou o zaslanie konfiguračných dát Acquirera 2. Príslušnú URL Acquirera má uloženú v svojich konfiguračných dátach. Acquirer 2 v kroku 54 vracia konfiguračné dáta ACQ2 confíg data.The payment confirmation of the payee 2 begins at step 53 with a request to send the Acquirer 2 configuration data. The respective Acquirer URL is stored in its configuration data. Acquirer 2 at step 54 returns ACQ2 config data.
EMV procesor príjemcu 7 sa nakonfíguruje v kroku 55 a prebehne transakcia platba danej čiastky, ale so záporným znamienkom. Peniaze teda potečú od Acquirera, z jeho Jumbo účtu k príjemcovi 7. Je to analógia vracania peňazí na kartu obchodníkom, napr. pri reklamácii tovaru - reverzná transakcia.The recipient's EMV processor 7 is configured in step 55 and a transaction of payment of the given amount takes place, but with a negative sign. So the money will flow from Acquirer, from his Jumbo account to the recipient 7. It is an analogy of returning a card to a merchant, e.g. in case of goods claim - reverse transaction.
Výsledok (TC/ARQC) je zaslaný Acquirerovi v kroku 56. V prípade, že je požadovaná Online autorizácia, prebehne v kroku 57 overenie v systéme Issuera 2. Výsledok môže tiež obsahovať skript na vykonanie na karte príjemcu 7, napr. vynulovanie offline počítadla. Záznam o transakcii TRX2 uloží v rámci kroku 58 Acquirer 2 v svojom úložisku P2P transakcií (ACQ2 P2P TRX store), kde už čaká na spracovanie pôvodná transakcia TRX1. Obe transakcie môžu byť ihneď odoslané k ďalšiemu spracovaniu. Acquirer 2 potvrdí príjemcovi 2 platby v kroku 59, že úspešne prijal transakciu potvrdzujúcu prijatie P2P platby. Súčasťou odpovede ARPC (u Online autorizácie) môže byť skript, ktorý zasiela vydavateľ 5 karty, issuer. EMV procesor dokončí transakciu a príjemca 2 je informovaný o úspešnom potvrdení prijatia peňazí. Obe transakcie posunie Acquirer 2 v kroku 60 na spracovanie súčasne (clearing + settlement). Výsledkom spracovania v kroku 61 je pripísanie čiastky na účet príjemcu 2 platby (Card account 2). Stav Jumbo účtu Acquirera se nezmení, keďže čiastka sa pripočíta a hneď zas odpočíta. Issuer 2 alebo Acquirer 2 môžu informovať príjemcu 2 θ dokončení prevodu a to v rámci kroku 62.The result (TC / ARQC) is sent to Acquirer in step 56. If Online authorization is required, verification is performed in step 57 of the Issuer 2 system. The result may also include a script for execution on the recipient card 7, e.g. reset offline counter. The transaction record of TRX2 saves in step 58 of Acquirer 2 in its P2P transaction store (ACQ2 P2P TRX store), where the original transaction TRX1 is already pending. Both transactions can be sent immediately for further processing. Acquirer 2 confirms to the payee 2 in step 59 that it has successfully received a P2P acknowledgment transaction. The ARPC response (for Online Authorization) may include a script sent by the issuer 5 card. The EMV processor completes the transaction and the recipient 2 is informed of the successful receipt of the money. Both transactions will shift Acquirer 2 at step 60 for processing simultaneously (clearing + settlement). The processing of step 61 results in the amount being credited to the card account 2. The status of the Acquirer's Jumbo account will not change as the amount is added and deducted immediately. Issuer 2 or Acquirer 2 can inform the recipient 2 θ of the completion of the transfer within step 62.
S ohľadom na symetrický systém generovania dvoch transakcií umožňuje tento variant i obrátený postup: príjemca 2 platby požiada o peniaze, vygeneruje prvú transakciu, následne je platca 6 upozornený na požiadavku o zaslaní peňazí a potvrdením požiadavky pošle peniaze. Teda okrem služby Send money je analogicky možná i služba Receive money.With respect to a symmetrical system of generating two transactions, this variant also allows the reverse procedure: the payee 2 requests the money, generates the first transaction, then the payer 6 is notified of the request to send money and sends money by confirming the request. Thus, in addition to the Send money service, the Receive money service is similarly possible.
Priemyselná využiteľnosť je zrejmá. Podľa tohto vynálezu je možné opakovane prevádzať peniaze medzi účtami účastníkov systému aje tiež možné zostavovať rôzne štruktúrované platobné systémy P2P alebo P2M.Industrial applicability is obvious. According to the present invention, it is possible to repeatedly transfer money between the accounts of the participants in the system, and it is also possible to construct various structured payment systems P2P or P2M.
Priemyselná využiteľnosťIndustrial usability
13-1¼ pr bDo^o -M)13-1¼ pr bDo ^ o -M)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| SK50020-2011ASK500202011A3 (en) | 2011-04-22 | 2011-04-22 | Method of cashless transfer money from person to person through mobile phone |
| EP12724399.6AEP2702572A1 (en) | 2011-04-22 | 2012-04-22 | The method of cashless person-to-person money transfer of using a mobile phone |
| PCT/IB2012/052017WO2012143911A1 (en) | 2011-04-22 | 2012-04-22 | The method of cashless person-to-person money transfer of using a mobile phone |
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| SK50020-2011ASK500202011A3 (en) | 2011-04-22 | 2011-04-22 | Method of cashless transfer money from person to person through mobile phone |
| Publication Number | Publication Date |
|---|---|
| SK500202011A3true SK500202011A3 (en) | 2013-05-03 |
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| SK50020-2011ASK500202011A3 (en) | 2011-04-22 | 2011-04-22 | Method of cashless transfer money from person to person through mobile phone |
| Country | Link |
|---|---|
| EP (1) | EP2702572A1 (en) |
| SK (1) | SK500202011A3 (en) |
| WO (1) | WO2012143911A1 (en) |
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| GB2536012A (en)* | 2015-03-03 | 2016-09-07 | iAXEPT Ltd | Remote transaction system, method and point of sale terminal |
| GB2519143A (en)* | 2013-10-11 | 2015-04-15 | Mastercard International Inc | Virtual POS System and Method |
| US20170103396A1 (en)* | 2015-10-13 | 2017-04-13 | Mastercard International Incorporated | Adaptable messaging |
| US11683325B2 (en)* | 2020-08-11 | 2023-06-20 | Capital One Services, Llc | Systems and methods for verified messaging via short-range transceiver |
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| KR0125740Y1 (en) | 1995-08-31 | 1998-12-15 | 배순훈 | Structure for bracket printed circuit board |
| EP1828998A2 (en)* | 2004-02-05 | 2007-09-05 | A Little World Private Limited | Inter-operable, multi-operator, multi-bank, multi-merchant mobile payment method and a system therefor |
| US20050250538A1 (en)* | 2004-05-07 | 2005-11-10 | July Systems, Inc. | Method and system for making card-based payments using mobile devices |
| WO2008027621A1 (en) | 2006-03-30 | 2008-03-06 | Obopay Inc. | Mobile person-to-person payment system |
| US20090063312A1 (en)* | 2007-08-28 | 2009-03-05 | Hurst Douglas J | Method and System for Processing Secure Wireless Payment Transactions and for Providing a Virtual Terminal for Merchant Processing of Such Transactions |
| US20100299212A1 (en)* | 2008-08-27 | 2010-11-25 | Roam Data Inc | System and method for a commerce window application for computing devices |
| CN102460520B (en)* | 2009-05-03 | 2015-01-21 | 洛格摩提公司 | A payment terminal using a mobile communication device, such as a mobile phone, and method for directly debit payment transaction |
| Publication number | Publication date |
|---|---|
| EP2702572A1 (en) | 2014-03-05 |
| WO2012143911A1 (en) | 2012-10-26 |
| Publication | Publication Date | Title |
|---|---|---|
| US11694200B2 (en) | Secure account creation | |
| CA3011012C (en) | Generating and sending encrypted payment data messages between computing devices to effect a transfer of funds | |
| US10311433B2 (en) | Secure authorizations using independent communications and different one-time-use encryption keys for each party to a transaction | |
| CN107087432B (en) | Remote server encrypted data reservation system and method | |
| RU2518680C2 (en) | Verification of portable consumer devices | |
| EP3848874B1 (en) | Systems and methods for facilitating a transaction using a virtual card on a mobile device | |
| US10614457B2 (en) | Secure authorizations using independent communications and different one-time-use encryption keys for each party to a transaction | |
| EP2701415A1 (en) | Mobile electronic device and use thereof for electronic transactions | |
| AU2019240563A1 (en) | Mobile device payments | |
| US20160148203A1 (en) | Mobile commerce payment system | |
| WO2017160877A1 (en) | Technical architecture supporting tokenized payments | |
| JP2018525758A (en) | System and method for promoting secure transactions in non-financial institution systems | |
| CN107004195A (en) | The safe handling of data | |
| JP6667498B2 (en) | Remote transaction system, method and POS terminal | |
| JP2012165356A (en) | System and method for establishing communication session between communication device | |
| TW201317911A (en) | Cloud credit card transaction system and transaction method thereof | |
| SK500202011A3 (en) | Method of cashless transfer money from person to person through mobile phone | |
| TWM557399U (en) | 2D barcode scan and transfer system | |
| RU2696953C1 (en) | Method of using unique number of mobile telephone subscriber for payments using payment systems | |
| KR20250105401A (en) | System and method for processing transactions from a cryptocurrency wallet | |
| WO2016166715A1 (en) | Systems and methods for executing payment transactions | |
| WO2014019026A1 (en) | Electronic transction system and method | |
| EA041883B1 (en) | SYSTEM AND METHOD FOR CONDUCTING REMOTE TRANSACTIONS USING POINT OF SALE PAYMENT TERMINAL | |
| HK1152438A (en) | Transaction server configured to authorize payment transactions using mobile telephone devices | |
| HK1152405A (en) | Mobile telephone transaction systems and methods |
| Date | Code | Title | Description |
|---|---|---|---|
| PC4A | Assignment and transfer of rights | Owner name:SMK-LOGOMOTION CORPORATION, TOKYO, JP Free format text:FORMER OWNER: LOGOMOTION, S. R. O., PIESTANY, SK Effective date:20150611 | |
| PC4A | Assignment and transfer of rights | Owner name:SMK CORPORATION, TOKYO, JP Free format text:FORMER OWNER: SMK-LOGOMOTION CORPORATION, TOKYO, JP Effective date:20150917 | |
| FC9A | Refused patent application |