FI127624B - Transaction arrangement - Google Patents

Abstract

Real-time payment transaction is realized so that when the person requesting a payment receives (1) information about a payment (5) from the payment holder ie. the recipient (2), communicates to the recipient (1) a payment request and the recipient's data (6) with a protected connection to the executor (3) of the transaction, which executor returns the data of a successful transaction (7) to the (1) wants a payment.

Description

Transaktiojärjestely

Field of the Invention

The invention relates to the realization of a real-time transaction for consideration and, in particular, to the transmission of the information required therein.

Background of the Invention

With the advancement of telecommunications technology, a large part of the various transactions for consideration have been transferred electronically. Examples of applications used for consideration transactions are mobile payment applications, such as SMS payment, a mobile wallet, or a mobile credit card operating on smartphones. Typically, in SMS payment, the payment is forwarded to the seller through a mobile phone operator, which in turn adds the bill to the telephone fee. A mobile wallet uses money previously transferred from an online wallet to an electronic wallet, and is paid out of the electronic wallet by texting a keyword to a service number or a close range of 15 miles using, for example, NFC (Near Field Communication) or any other RF1D (Radio Frequency Identification) solution. The mobile credit card application is an example of cloud-based payment and differs from the mobile wallet in that it sends both money directly to the recipient's account and the invoice to the person who registered the smartphone as a mobile credit card. In known solutions, the payee must support the technology used and the payer must either transfer the money to their terminal in advance or the payer must pay through the credit service previously registered with the payer. When transferring money in advance to a terminal or paying through a credit service, the solution is not real-time for the payer, as the actual debit transaction takes place at different times.

Brief Description of the Invention

The object of the invention is to develop a real-time application for executing a transaction for consideration. The object of the invention is achieved by a method, a terminal and a system which are characterized by what is stated in the independent claims. Preferred embodiments of the invention are claimed in the dependent claims.

20165360 prh 26-06-2016

BRIEF DESCRIPTION OF THE DRAWINGS

The invention will now be further described in connection with preferred embodiments, with reference to the accompanying drawings, in which:

Figures IA and IB show simplified generic system5 architectures;

Fig. 2 is a flow chart illustrating exemplary functionality;

Figures 3A and 3B illustrate simplified communication and functionality in one example;

Figure 4 illustrates a simplified communication and functionality in another example;

Figures 5A and 5B illustrate the functionality of different parts of the transaction response recipient system in yet another example

Figure 6 shows an example of a real-time transaction chain for consideration;

Figures 7A-7C illustrate various user interface views; and FIG. 8 is a simplified block diagram of a user terminal; and Figure 9 is a simplified block diagram of a transfer server; and Fig. 10 is a simplified block diagram of the receiver of the transaction response receiver.

DETAILED DESCRIPTION OF THE INVENTION

The following embodiments are exemplary. Although the description may in several places refer to one ", one" or some "embodiment and / or example (s), this does not necessarily mean that each such reference is to the same embodiment (s) and / or example (s) or feature The individual features of the various embodiments and examples may also be combined to provide other embodiments and examples, and it will be appreciated that some of the functions, structures, and elements used to create kon30 text for the embodiments and / or examples described herein may be as such. The structures, words, and expressions in the following description are therefore intended to illustrate and not limit the invention or its embodiments.

20165360 prh 26-06-2016

The invention will now be described, by way of example, without limiting the examples thereof, of a real-time transactional payment system with payment.

Figures 1A and 1B illustrate a general architecture 5 according to one embodiment, showing only some elements and functional units of the communication system 100. The circuits and units shown in Figures IA and IB are logical, functional circuits and units; the actual physical connections and units may be different. It will be apparent to one skilled in the art that the system may include other elements, units, structures and / or subsystems, which need not be described in further detail herein.

In the example of Figure 1A, system 100 comprises a transaction originator as a cash generating device 110, a transaction payer, i.e., a buyer / payer / transaction requester or user terminal 120, a real-time transaction system (transaction real-time provider), i.e., through which the user terminal, the transfer server, and the banking system can communicate.

The cash register 110 may be a traditional cash register or part of a cash register system. It is sufficient that the cash register 110 comprises an invoicing unit (1-y) 111, by means of which it forms an invoice for the user's purchases. Preferably, the invoice includes the transaction value of the transaction for payment (the amount desired for the consideration) and the payee information, i.e. the destination of the counterpart, i.e. at least one or more account numbers to which the payment can be made or similar information such as the payee identifier can be discovered in the banking system. If the seller has an account with several banks, the invoice may contain account information for each bank, or the seller may choose the bank or banks to be invoiced. For example, the seller may ask which bank account the buyer is going to pay for and select the account information to be invoiced based on it. The invoice may also contain other information such as a reference number. The invoice may include or be presented, for example, as one or more bar codes and / or QR codes. The cash terminal may also comprise one or more interfaces (not shown in Figure 1) for transmitting invoice information and / or payment. One interface may be an NFC module, or equivalent short range communication module, through which the invoice may be transmitted electronically to the user terminal 120, if it also has an NFC35 module or equivalent. Alternatively or additionally, the cash register may comprise an interface for displaying invoice information and / or a printer,

20165360 prh 26-0β-2016 with which the invoice and information can be printed. It is also possible to use an Application Programming Interface (API), such as OPOS (Object Linking and Embedding for Retail Point Of Sale), which enables the integration of functionality / functionality directly into the cash terminal system and thus to the cash register5 terminals. In some embodiments, the cash terminal and / or the cash terminal system (as part of a financial management system) may also be configured to perform payment receiving functions such as those illustrated in connection with Figures 4, 5A and 5B.

The transaction trigger (transaction trigger), i.e., the user terminal 120, is configured to communicate with the transaction information transferring server 140 through the communication network 102 and the actual transaction executing system via the communication server 140 through the communication network 102, e.g. smartphone, tablet, laptop, handheld, smart glasses, or any wearable computer, smart suit or similar smart device (a device that is mobile and includes computing power, regardless of where the device is set up]. The user terminal may be wired, connected, or wireless. the terminal may be active or passive. (A passive device, such as an ID tag, can be woken up and powered from another device.) the system can be any operating system (OS) such as Android, iOS, Firefox OS, Windows Phone, Black25 Berry 10, Tizen, Sailfish OS and Ubuntu Touch. In other words, in the example of FIG. 1A, the consumer terminal 120 may be any terminal allowing connection to the banking system 130 via one or more telecommunication networks 102 through the transfer server 140, which terminal 120 may be configured to initiate and participate in a transaction.

To this end, the terminal comprises one or more interfaces (IFs) 123 and a protected portion 122 comprising a transaction for payment transaction (v-tt-y) 122-1, which may be an online banking implementation unit in a direct payment application, and a storage unit (t-yj 122-). 2 for storing the credentials required for a transaction for consideration in secure memory 122-3 and secure memory 122-3.

20165360 prh 26-06-2016 are described in more detail below with reference to Figures 2-4. The storage unit 122-2 is configured to store the key figures required for the online banking function (or the mobile banking function or any function for real-time electronic payment), such as the online banking login5 and any key numbers, or some of the key numbers are protected as described below. Any encryption technology, such as symmetric or asymmetric encryption technology, or technologies utilizing it, a keychain developed by Apple, or a similar solution, or completely new solutions, such as the encryption key purse as disclosed in GB 1507154.1 purse cryptographic key pair is encryption and decryption mechanism, wherein the purse identifier is opened between the two parties.

Protected section 122 is a secured environment isolated from other terminal applications for a real-time transaction application, so that the application can be executed only after the application has been confirmed unchanged and the user has been identified as described below. The protected area can be implemented using, for example, a solution developed by the device manufacturer. One example of this is the Samsung KNOX, which isolates certain applications in its own area and encrypts the data of the isolated application, both in hibernation and in use. Part of the protected area can also be implemented using encryption technology.

The protected section 122 comprises a protected memory 122-3. It can also be validated before or during the launch of the application, as described below. The secure memory 122-3 contains various identification information 122-31 and possibly online banking identification information 122-32 for the direct payment application 25, at least some of which, preferably all encrypted, and possibly partially decrypted during use. Such information is, for example, public key management system (PK1, Key Infrastructure), as well as the identification or information needed to use the application and, preferably, the network address of the transfer server. For example, Samsung KNOX encrypts data in secure memory using the Advanced Encryption Standard (AES) encryption algorithm. Other encryption algorithms, such as Salsa20 and its variants, can also be used. The use of the data is described in more detail below with reference to Figures 2-6. It is obvious to a person skilled in the art that the recording disclosed herein6

20165360 prh 26-0β-2016 can be implemented in many different ways, for example, some data can be stored in public memory encrypted so that only the key (s) in the protected area can decrypt the data.

In the example of Figure 1A, the transaction 130 for consideration is a banking system that enables electronic real-time payment through the electronic payment interface (payment interface unit, m-y) 131 provided by the telecommunication network 102, for example through an online banking application or a mobile banking application. Any present or future banking application can be used in the solutions according to the invention, i.e. the user is free to choose the appropriate source (from which the transaction is executed), ie his transaction bank and his account there, and the invention does not require any changes in the banking solutions. It should also be noted that, for example, the various loyal customer accounts that can be used to pay for their purchases, possibly even by means of payment other than cash, are equal sources of value in this invention, i.e., directly comparable to bank accounts; for example, they can be viewed as accounts and the loyalty system provider can be interpreted as one of the online banks.

In the system of Figure 1A, the transaction information transferring transfer server 140 is configured to transfer, through the communication network 102, the information needed for the transaction to the transaction executing system 130 and the transaction trigger.

120 times. The migration server may be, for example, an application server, which at its simplest is a computer executing an application. In other words, in the example of Figure 1A, the transfer server 140 may be any computer that enables a secure connection to the banking system 130 and the terminal 120 and is configurable to participate in a transaction for consideration. For this purpose, the transfer server comprises one or more interfaces (IFs) 143, a transaction-free data transfer unit (v-t-t-s-y) 141, and memory 142 for storing identification information 142-1 and parsers 142-22 of various network banks. The parsers here show the real-time vendor-specific settings. Bank-specific parsers can account for slightly different online banking implementations, and even country-specific differences. The parsers can be implemented by any known or future parser technique. For example, a Python parser package called Beatiful Soup can be used. Compared to a solution that would store, for example, banks' mobile payment applications in their entirety, saving only parsers saves memory resources. In addition, the server operating system can be freely selected; applications are always made for some operating system, and if they were saved

20165360 prh 26-06-2016 mobile payment applications, it would limit operating system selection. Usability is also better. The functionality of the transaction transaction unit 141 for consideration is described in more detail below, particularly with reference to Figures 3A-3B.

The communication network 102 shown in Figure 1A may comprise one or more networks, each network may be a wireless network or a wired network, or a combination thereof. How the telecommunication network is implemented is irrelevant to the invention. The telecommunications network may be based in whole or in part on, for example, third, fourth or fifth generation wireless communications technology, wireless LANs such as Wi-Fi or Li-Fi, or other wireless localities such as infrared, bluetooth, or Internet, broadband or wireless technology. .

Depending on the embodiment or embodiment, what is stored in the application 120 by the application terminal is different from what is transferred to the transfer server 140.

At one end, the transfer server 140 has only parsers, and other information is stored encrypted in the terminal 120 or else the terminal 120 is adapted to request information from the user, and at the other end, the user terminal 120 contains only information to secure the user's access to the application. stored encrypted on the transfer server

140. In intermediate applications, for example, the persistent IDs can be stored encrypted on the transfer server and the disposable IDs encrypted in the terminal memory. There are other ways to allocate what information is in the terminal and what in the transfer server. It is also possible that the same information is stored encrypted on both the transfer server and the terminal.

A solution where virtually all data is on the transfer server 140 reduces network load when it is not necessary to request and transfer credentials. On the other hand, storing credentials on a user's terminal 120 provides greater security: hacking a single terminal containing one person's data is less interesting than a server containing multiple individuals, since the potential benefits of hacking 30 individual human domains are clearly smaller.

The storage unit 122-2 is adapted to store the online banking identifiers 122-32 preferably on a per-bank basis and depending on the embodiment, encrypted either in parts or as a whole. The storage unit 122-2 can advantageously encrypt the data to be stored not only in the terminal 120 but also on the transfer server 140. The storage unit 122-2 preferably encrypts the data to be stored. Can be used to encrypt data

20165360 prh 26-06-2016 any encryption technology. Preferably, the standard data to be stored is encrypted using a different encryption key or keys than is used to encrypt variable data. Any information so known does not jeopardize all protection. The storage unit 122-2 may be configured to encrypt the data to be stored in the terminal so that it can only be decrypted by the decryption key of the transport server. The terminal and the transfer server may also have encryption key purses (a pair of purses) that can be used to encrypt the data.

For example, when using an encryption key purse, the IDs can be stored in the purse so that when the purse is open, they can all be read, for example, by the key serial number. IDs can also be stored individually encrypted, for example, without having to store its key serial number. With the address space thus obtained, the encrypted identifiers are found and, if stored in the terminal, are transferable depending on the encryption method, encrypted from the terminal to the transfer server or individually decrypted. When the data is encrypted separately, the security of the transfer server will be improved, as there too the data will have to be hacked one by one, and the opened data must also be linked to the correct accounts.

The terminal storage unit 122-2 may obtain information, such as a key list, for example, for the user to enter the information, use the terminal's QR20 scanner or similar scanner, photograph the IDs, obtain them electronically from the bank, and the like.

Apart from the terminal 120, the transfer server 140 can also obtain information directly from the bank 130.

It should also be noted that, in the future, a banking connection may also operate with a cryptographic key purse, in which case its (user-specific) counterpart on either the transfer server or the terminal may replace user-specific bank information. Thus, in a solution using a transfer server, the transfer server may have two pairs of key purse counterparts for the same user - one for use between the transfer server and the terminal and one for use between the transfer server and the bank. It is also possible that in the future, in the future, between the transfer server and the bank, of course, with the consent of the users, one encryption key pair (common encryption key for users) will be used between the bank and the transfer server for all users who have given their consent. In addition to the identifier, the encryption key purse can also have a serial number that identifies which express key purse is in use at any time. The key purse serial number can be pi9

20165360 prh 26-0β-2016 is separate from the key serial number, but the serial numbers can also be combined if desired. It is also possible that the same encryption key wallet is also used by a group of different parties (i.e. the group has a common secret). Salausavainkukkarolla is thus possible to achieve the same purposes as the Diffie-Hellman5 key exchange protocol among several parties, except that the cryptographic key wallet in an encryption process does not slow down, just as the Diffie-Hellman key exchange protocol for running.

The exemplary system 100 of Fig. IB differs from the exemplary system of Fig. 1A in that there is no separate transfer server, but the user terminal 120a is also configured to perform data transmission directly with the payee transaction system, i.e., the banking system 130. To this end, the user terminal 120a comprises an extended fee transaction execution unit (1-ttty) 122-la, which is a combination of the charge transaction implementation unit and charge transaction data transfer unit of the example of Figure IA, and in memory, either protected memory 122 such as FIG. online banking parsers 123-33. Depending on the method of implementation, the memory may be parsers of all online banks, including loyal customer systems, or only those of the accounts from which the user may perform a transaction for payment. The latter solution consumes less muis20 tire resources.

The advantage of using a migration server is that when a bank (or loyal customer system) changes its net banking functionality, the upgrade of the parser is similarly simple: you only need to upgrade the parser to the transfer server. In a non-server solution, upgrading parsers will require more resources, as the parser will need to be updated for each terminal where it is. For this, you need to maintain information about the terminals somewhere, and if the number of parsers stored in the terminal varies by terminal, you need to maintain information about which parsers are in each terminal, or alternatively ask the terminals every time they upgrade.

Figure 2 shows an example, in conjunction with Figures 7A-7C, of the operation of a transaction for payment transaction, which in this example is a real-time payment application using a transfer server. It will be appreciated that the transaction execution unit, for consideration, may be subdivided into sub-units which perform certain functions which form part of a subset. In the example of Figure 2, it is assumed that the application is authentication, memory validation

20165360 prh 26-06-2016 and successful user authentication. If one of them fails, the process will naturally be interrupted.

Referring to Figure 2, when initiating a payment application is detected in step 200, the payment application is verified (authenticated) in step 200. This step may also include identification of the payment application, for example by means of a public key management system. The launch may be touched by the receipt of an invoice electronically from the cash register or by the user input (selection) which launches the application. For example, the user may select, as shown in Fig. 7A, the application (PAYER) 50 on his terminal screen 500. The payment application authentication can be done, for example, by calculating a payment application's checksum or a key created by CRC (Cyclic redundancy check) for example, using a SHA function (SHA, Secure Hash Algorithm) such as SHA-1, SHA-2, or preferably SHA3, and comparing the result of the calculation to the sum of the application check15 in the identification data or to the check key or hash. If they are the same, the application is unchanged, that is, certified. In other words, it virtually verifies that the application code has not been modified and that the application has been downloaded from an identified and trusted entity. In this example, the memory is also authenticated in step 201. The memory can be authenticated in the same way as the application. Typically, the device manufacturer has defined a memory backup method. The user is then authenticated in step 201. The user can be identified, for example, by means of a biometric identifier integrated in the terminal, such as PositivelD, fingerprint or iris, possibly as a two-step authentication with biometric identification associated with the user password or P1N25 Any digital credential can be used in place of or in combination with the biometric sensor. One safe option is to connect the user terminal with integrated fingerprint authentication or other strong authentication to information transmitted by another external route, such as an NFC reader or

Information obtained from a physical ring, watch, implant or key chain transmitted through an RF1D reader. Storing the application in secure memory and strong user authentication prevents potential malware leakage problems.

Once the user has been identified, that is, his / her right to use the accounts has been verified, in step 202 the invoice, i.e. the amount to be paid, and the account or accounts to which payment can be made is read. Other information,

20165360 prh 26-06-2016 such as a reference number or a filing number can be passed. The reading can be performed using any known technique. The reading may be performed using, for example, an NFC reader or other similar short-range reader such as infrared or wi-fi or light, reading the terminal application and the camera using QR code (s) and / or bar code (s). An invoice, or payment, can also be read using a vibration tag with a vibration or with voice recognition using a sound. In this example, the manual entry of invoice data via the terminal user interface is also considered to read the invoice. Data can also be transmitted over a fixed bus, for example via a USB connection.

Once the invoice has been read, it is converted into a payment at step 203, if necessary.

Of course, if the invoice to be read is a direct form of payment, you do not need to do the formatting.

Simultaneously, or thereafter, at step 204, the user accounts and the banks in payment are determined. Of course, accounts that a user has access to may have been previously defined, for example, when they are read from the secure memory at startup. If a user has more than one account (step 205: yes), the user will be prompted to select the account they want to use. In another embodiment, if there is more than one bank on the invoice, the user is also asked to select the bank account to which he wants to pay, no matter how many accounts he has. The user is prompted to select an account by displaying the request and account options on the terminal screen, or by displaying only the accounts. Depending on the embodiment, the accounts can always be displayed in the same order, in the order in which they are most frequently used, in bank-specific order (if there are several accounts in the same bank) and / or in order. in the same bank as what is in the payment, for example in the order in which the payment is made. One example is shown in Figure 7B, where the user terminal user interface application screen 501 displays account selections 51. In the example of Figure 7B, the user has two accounts at bank P3, one account at bank P1 and one account at bank

P2. It should be understood that the above are just a few examples of the basis on which accounts can be displayed to a user. When the user account selection is received in step 207, the payment transaction is then displayed to the user in step 208 along with the payment approval request, or confirmation request. An example is shown in Fig. 7C, in which the application terminal 701 of the user terminal user interface 35 shows a payment transaction 72, that is, an amount and an account from which

20165360 prh 26-06-2016 The amount will be charged as well as the selection keys 72a, 72b which will allow the user to accept or decline the payment. In other words, this step still ensures that the user is willing to pay the bill. If there were no alternatives (step 205: no), you will be taken directly to this step. If the user does not accept the payment (step 209: no), the payment and the application are suspended in step 216.

If the user accepts the payment (step 209: yes), an online payment will be made. The network payment is initiated by establishing in step 210 a secure connection to the transfer server, for example, an HTTPS (HTTPS, Hypertext Transfer Protocol Secure) connection, where the HTTP communication protocol is used with either TLS (Transport Layer Security) or SSL (Secure Sockets Layer) encryption protocol. Use of the latter requires that the parties rely on each other's SSL certificate. The secure connection may also be established in other ways, such as by utilizing the encryption key purse mentioned above. In addition to a secure connection, it is also possible to transmit data in a secure / encrypted manner, for example, with OpenPGP compliant PGP (Pretty Good Privacy). If the data is encrypted so that only the transfer server can decrypt it, the data can be transmitted even over a normal data connection.

When the secure connection is established, in step 211, the payment information, i.e. the account to be paid, the account to be paid and the amount to be paid to the transfer server, is sent. In other words, for example, the payer's account information is never transferred to the cash terminal, so the risk of fraudulent information is lowered and the cash terminal system is thus not required to be as secure as, for example, debit and credit card payments.

When the message is received from the transfer server (step 212), step 213 checks whether it is a request for payment information or not. Examples of different information requests are shown in Figures 3A and 3B. In the case of a request (step 213: yes), in step 214, the requested information is retrieved from the decrypted Netbank IDs and transmitted in step 214, then returned to step 212 to receive the message from the relay server.

If it was not a request (step 213: no), the transaction will be reported as successful and displayed at step 215. If successful, the information will preferably be a receipt or payment details showing the charge, and when displayed, may be displayed to the seller for consideration that is, the goods or goods that were purchased. After that, the application may close automatically or wait for the user to close the "feed" and / or offer the user the opportunity to make another payment. The application may also be arranged to identify a failure

20165360 prh 26-06-2016 payment, possibly also the reason for the failure, such as incorrect ID / ID or insufficient funds in the account. If the user has more than one account, it is possible to return to step 206, for example to display accounts that have not yet been attempted to be paid.

Figures 3A and 3B illustrate in more detail the data transmission associated with the actual network payment between the user terminal (fee-paying transaction execution unit), the transfer server (fee-paying transaction data transfer unit), the online banking (network banking) Figures 3A and 3B assume that payment is successful. In addition, in the figures, data transmitted over a secure connection is encrypted before transmission and decrypted before use, but for the sake of clarity, encryption and decryption, respectively, are not repeated during data exchange. Of course, if for example an identifier or a challenge response pair is incorrect, payment will fail.

It will be appreciated that in some embodiments, the identifier or challenge response pair may be re-requested, for example, once, twice, or three times before payment fails.

Referring to FIG. 3A, when the user terminal has completed (step 3-1) authentication, user authentication, and payment related steps of the application, the transaction execution unit, until payment is accepted, i.e., after step 209 of FIG. 2. A secure connection (messages 3-2) is then established between the terminal and the transfer server. As explained in connection with Figure 2, the connection may be an HTTPS connection, where the data is encrypted prior to transmission, for example, by the TLS protocol. Once the connection is established, the payment information (payer account, seller account and amount) is sent (message 3-3).

Upon receipt of the payment information, the transfer server determines the payer's bank from the payer's account and selects the parser to be used in step 3-4, and establishes a secure connection (messages 3-5, 3-6), such as HTTPS30, to the bank's online bank.

Thereafter, the actual establishment of the Netbank connection with the Netbank login is performed using secure connections.

First, the transfer server requests (message 3-7) from Netbank the hypertext mer35 (HTML) content of its login page (web page, or URL (uniform resource locator)) and upon receiving message 3-8 returns the content returned by the Netbank, looks for the selected bank-specific parser. -9 parser

20165360 prh 26-06-2016 Fields for input elements required for login. Typically, the fields are in the HTML form element specified for your bank login. Once found, the transfer server requests the required information (message 3-10) from the user terminal.

The user terminal retrieves (step 3-11) the information requested from the bank account ID of the selected account and returns it to the relay server in message 312. If the information is stored in parts, the user terminal may unblock either part of this information or the data as a bank-specific entity, all information. Alternatively, the data may be decrypted earlier in the background, for example in response to a payment authorization. Depending on the embodiment, the user may also be asked for this login information, or at least one of them, if more than one login information is required.

Upon receipt of the login information, the transfer server compiles the answer in section 3-13. In other words, in this example, it compiles the fields of the input elements

HTTP POST request and send them (message 3-14) to the URL obtained in message 3-8. (In the example example, the URL is in the action attribute of the form element on the login form.) The example example assumes that the login information was correct, so when the transfer server parser reads the response returned by Netbank (message 3-15), that is, HTML 3. ole20 has logged in to online banking.

After logging in, an online banking session will be activated. First, the Migration Server requests (message 3-17) from the Netbank the HTML content of its session activation form and upon receiving the content returned by the 3-18 Netbank message, the parser looks for the challenge code of the challenge response number 3-19, for example the form element or input element of the activation form -20) challenge code from the user's terminal.

The user terminal (step 3-21) retrieves the challenge code from the bank's Netbank ID information of the selected account and returns it to the transfer server in message 3-22. If the information is stored in parts, the user terminal may decrypt the part containing this information at this stage. Alternatively, depending on the implementation, the challenge code can also be requested from the user.

After receiving the challenge code, the transfer server compiles the answer in step 3-23. In other words, in this example, it compiles the input element fields into an HTTP POST request and sends (message 3-24) the fields of the in35 put element of the filled challenge response code to the URL obtained in message 3-18. (Example of figure 15

20165360 prh 26-06-2016 where the URL is in the action attribute on the form element of the challenge response form.) The example in the graph assumes that the challenge response code was correct, so when the transfer server parser reads the response returned by the netbank (message 3-25). in step 3-26, the online banking session could be act5.

A payment is then posted.

First, the transfer server requests (message 3-27) from the netbank the HTML content of its bill payment form and upon receipt of the content returned by the netbank in message 3-28, the parser searches and fills in the information received in message 3-3, the account number on which the payment is being charged, the name of the beneficiary, the reference number of the invoice, the amount of the invoice, and the beneficiary's account number. Some input elements may be mandatory and some may be optional. Depending on the implementation, the transfer server may request from the UE or via the payee any missing information. Once the details of the input elements required for payment have been determined, the transfer server compiles the payment in step 3-29. In other words, in this example, it compiles the fields of the input elements into an HTTP POST request and sends (message 3-30) the completed bill payment form to the URL obtained in message 3-28. (In the example example, the URL is in the action attribute on the form element of the challenge response form.)

In the example of Figure 3A, it is assumed that there was money in the account, so the online bank will make the initial payment (recording the payment reservation) in step 3-31 and return the counterpart (message 3-32).

When the transfer server parser reads the response returned by Netbank (message 3-32), that is, the HTML content, it detects that a payment has been posted.

After the payment has been posted, the transfer server, or rather the parser of the transfer server, therefore initiates the confirmation and approval of the payment.

First, the transfer server requests (message 3-33) the HTML content of its payment confirmation form from Netbank and receives the content returned by Netbank in message 3-34.

Thereafter, the process of Figure 3A continues in Figure 3B.

Upon receiving the content (message 3-34), in para 3-35, the parser looks for the challenge response code, e.g. the form element or input element of the challenge response form, and requests (message 3-36) the challenge code from the user terminal.

The user terminal retrieves the challenge code (step 3-37) from the bank's Netbank ID of the selected account and returns it to the transfer server in a message

20165360 prh 26-06-2016

3-38. If the information is stored in parts, the user terminal may decrypt the part containing this information at this stage. Alternatively, depending on the implementation, the challenge code can also be requested from the user.

After receiving the challenge code, the transfer server compiles it in step 3-39. In other words, in this example, it will compile the input element fields into an HTTP POST request (request] and send (message 3-40] the fields of the filled challenge response code input element to the URL obtained in message 3-34 (in the example example, in the action attribute of the element.] The example in the figure assumes that the challenge response code was correct, so Netbank makes a payment in step 3-41 and returns the information to the transfer server (message 3-42]. This also means that if the accounts are in the same bank, the payment information (point 3-52) will be received virtually immediately, but for the time being there may be a delay between the different banks in the recipient's banking system, and thus also to the local tax authorities. .

When the transfer server parser reads the response returned by Netbank (message 3-42], that is, the HTML content, it states in step 3-44 that the payment has been made.

After that, payment verification is performed.

First, the transfer server requests (message 3-45] the HTML content of the invoice receipt from the Netbank and upon receiving the content returned by the Netbank message 3-46, the parser looks up the archive ID and uses it to compile a receipt at message 347 to send to the user terminal. in the example, the user terminal is adapted to display the receipt on the terminal display in step 3.49. In another embodiment, the receipt may be sent instead or in addition to the cash terminal, which, if configured, can confirm to the cash user that payment has been made.

In the example of Figure 3B, after the payment is authenticated, the netbank session between the transfer server and the netbank is terminated (messages 3-50] and the secure connection between the transfer server and the user terminal (messages 3-51).

In embodiments where the netbank identifiers are stored encrypted on the transmission server, information can be transmitted in message 3-3 to enable decryption of the netbank identifiers. For example, a shared shared secret or a public key counterpart may be provided with a secret key. A very secure way is also to provide a token that unlocks the key wallet. The transmission of information needed for decryption may also include more

20165360 prh 26-06-2016 sending a message between the relay server and the terminal. In embodiments where the data is stored on the transfer server, messages 3-10, 3-12, 3-20, 3-22, 3-36, and 3-38 are internal transfer data on the transfer server and items 3-11, 3-21, and 3-37 is executed on the transfer server. In embodiments where some of the information is in the relay server and some in the terminal, some of the messages described in connection with FIG. 3 may be internal to the relay server (and the corresponding items are performed at the relay server).

It is also possible that the payee, such as the merchant, will require an electronically signed receipt for the payment made. Any known or future technology can be used for electronic signature, such as using personal bank IDs for electronic signature or the Signom signature service.

In embodiments that do not use a transfer server, the data transfer between the transfer server and the terminal shown in Figures 3A and 3B is internal data transfer performed by the terminal, or rather, by the extended transaction transaction unit.

As can be seen from the examples above, the application functions as an enhanced, for example, more secure digital debit card - paid directly from your own account without sending account information, and the user access is more efficiently authenticated than a traditional debit card.

In the above examples, it is assumed that a cash register system of the prior art is used and that no modifications have been made to it. The advantage of such embodiments is that, since payer and payee devices do not need to support the same application, there is no limitation on the applications and, to obtain a comprehensive coverage, the hardware does not need to support multiple applications. They also avoid problems with billing applications for terminal applications that enable the use of the bank's mobile payment application, provided the invoice is delivered with the same application launching the bank's mobile payment application: the payer must either pre-transfer money to his terminal or register with the same payee .

The above examples can also be applied when a change is made to the cash terminal system which ensures in real time that a payment has been made even when the payee's bank is different from the payer's bank. Also in these embodiments, illustrated by the examples of Figures 4, 5A and 5B, are avoided

20165360 prh 26-06-2016 The above problems, as one application covers all banks, meaning that you get extensive coverage, no need to transfer money in advance and no need for separate registration. Note that the client terminal application need not necessarily be the same application as the application (or pair of application counterparts) in the cash terminal system, but it is sufficient that the applications have sufficient uniform functionality to ensure the functions described below.

The examples of Figures 4, 5A and 5B illustrate the functionality of the invoice management unit (or units). The example in Fig. 4 assumes that authentication is always requested, and in the example of Figs. 5A and 5B, it assumes that authentication is requested only if no real-time information is available through its own bank. Figure 4 also illustrates how, for example, a parser or some other subunit of the transactional transaction processing unit of the user terminal or transfer server is adapted to provide the requested authentication information. 5A and 5B, of course, although not shown separately. For example, the assumption is that the application (billing management unit) in the cash terminal and the application in the terminal / transfer server (for example, subunit in the transaction for payment transaction) are configured to calculate a hash of the sum of money and application secret serial number. unchangeable (true and genuine) and has just been used. In addition, in this example, it is assumed that a reference number is added to a disposable number generated by the application at the cash terminal after the invoice has been generated, and from this sum a second hash is calculated. This ensures the freshness of the event. It should be understood that these are just examples of how verification can be done. It is essential that only trusted applications (or parsers) know how to back up.

In the example of Figure 4, it is assumed that the transfer server is not used. Applying the example to a solution containing a transfer server will be apparent to one skilled in the art. In addition, in the figure, data transmitted over a secure connection is encrypted before transmission and decrypted before use, but for the sake of clarity, encryption and decryption, respectively, are not repeated during data exchange.

Referring to Figure 4, the cash terminal offers the customer many different payment methods, such as proximity payment. However, the customer will select the direct payment application presented in this application. In step 4-1, the cash terminal detects the application selection in step 4-1, generates an invoice, and because the payment method is a direct payment application, in step 4-1 completes a hash of the invoice amount (amount) and

20165360 prh 26-06-2016 from the app's secret serial number. The cash terminal also transmits the invoice electronically (message 4-2] to the user's terminal, for example using NFC technology, as described above. Upon receipt of the invoice, the terminal performs payment operations together with Netbank (messages 4-3, messages 4-4]. suppose that payment was successful and message 4-5 and step 4-6 correspond to message 3-42 and step 3-52 of Figure 3B. In this embodiment, the terminal, having composed a receipt for payment, sends a receipt in message 4-7 to the cash terminal and temporarily maintains the receipt in its memory. is configured to ensure that the correct payment application was used on the terminal and therefore the cashier sends a request to the terminal 4-8 to calculate the hash. a.

The cash register compares the hash obtained in message 4-10 in step 4-11 with the one calculated in step 4-1. If they are the same, the application is genuine. In this ancestor 15, it is assumed that they are the same. (If the terminal application were not genuine, the cash register could inform the user, for example, that the payment failed.) Since the application was authenticated, the cash generator generates a non-reusable number x in step 4-11, calculates a reference numeral for a hash; and sends a disposable number x in message 4-12 to the terminal.

In step 4-13, the terminal calculates a hash from the sum of the disposable number x and the reference number in the receipt and sends it to the cash register 4-14 in a message.

The cash terminal compares the hash calculated in steps 4 to 15 with the hash received in message 4-14. If they are the same, the cash register will trust that the invoice has been paid (transaction completed, match received) and will show the payment made in steps 4 to 15. If it is found that the seals are not the same, payment will be shown as failed.

If no data link is established between the cash terminal and the user terminal, the applications may be arranged to display corresponding data in the interface, allowing the cash terminal user to compare the hash displayed at the cash terminal to the hash displayed by the user terminal. Multiply / Displays the disposable number displayed on the cash register display].

20165360 prh 26-06-2016

Figures 5A and 5B illustrate an embodiment in which the above process is performed only if no real-time confirmation from the bank that the payment has been made. The example of Figures 5A and 5B further assumes that the cash terminal is part of a larger system, so Figure 5A illustrates the functionality of the cash terminal and Figure 5B illustrates the functionality of the cash terminal system that receives real-time information on account transactions. It is referred to as the cash register system in the description of Figures 5A and 5B. In addition, in the figures, data transmitted over a secure connection is encrypted prior to transmission and decrypted before use, but for the sake of clarity, encryption and decryption10 respectively are not repeated during data exchange.

Referring to FIG. 5A, at step 501, the cash terminal generates an invoice with a reference number and sends it to the user terminal at step 502, as described above. In addition, at step 503, the cash terminal transmits at least a reference number, possibly also other information, to the cash register system. Thereafter, the cash terminal waits for a predetermined time t1 whether an acknowledgment is received from the cash system at time t1 (step 504). Time t1 is a relatively short time, but sufficient to complete a transaction and to transmit information about the transaction (payment of a fee).

If, at time t1, no acknowledgment is received from the cash system that payment has been made (step 504: no), the cash terminal in step 505 calculates the hash invoice amount (amount) and application secret serial number from the application secret and verifies in step 506 the user terminal application. Again, this example assumes that the application was authenticated. Thereafter, in step 507, the cash terminal generates a disposable number and sends it to the terminals 25. Simultaneously, in step 508, the cash terminal calculates the hash from the sum of the disposable number and reference number, receives the hash from the terminal and compares them. The conclusion of the comparison result (same hash payment paid, different hash payment failed) is displayed at step 509 to the cash system user.

If at time t1 an acknowledgment was received from the cash system (step 504: yes), in step 510, the cash system user is shown that the payment was successful.

Referring to FIG. 5B, the cash register system receives, at step 511, at least a reference number from the cash terminal and monitors (step 512) whether it receives an acknowledgment from a banking system at time t2. Preferably, the time t2 is the same or slightly shorter than that of Figure 5A. If the acknowledgment is received at time t2 (step 512: yes), then cash register21

20165360 prh 26-06-2016 Based on the reference number in the bank system acknowledgment at step 513, the system deduces a cash terminal to which, in step 514, it sends the payment information. If no acknowledgment is received in time t2 (step 512: no), the cash register system stops checking the reference number in step 515.

Other options to ensure that the direct payment application has just been used can of course be used in addition to or instead of the method described above. One example is that the counting of the seal changes as a function of time, provided that the clocks of the cash register and the user terminal are synchronized with sufficient accuracy, for example a few seconds, preferably not more than every minute. Another example is that the application server is asked to select a hash calculation routine, which then returns either a hash or, for example, a seed number of the routine or the like to produce a hashed backup.

Although the above examples refer to a real-time payment transaction involving payment, it will be apparent to one of ordinary skill in the art that the foregoing is applicable to any real-time transaction for consideration. Figure 6 shows a principled, highly reduced diagram of the transfer of information or supplies for a transaction in exchange for consideration between parties to a transaction.

Referring to FIG. 6, consideration requester 1 (requester of transaction information) shows or otherwise addresses the consideration 4 to the counterparty, i.e., the counterparty 2. The counterparty 2, in turn, transmits to the requester 1 at least information about match 5 and where the match should be executed (or ), that is, other (payee) information. The counterpart information may also indicate the type of transaction or, if necessary, the type of transaction may be otherwise provided. The counterparty 1 forwards at least the counterparty and recipient information 6 to the transferee 3, who, upon completion of the transaction, returns the confirmation 7 of the completed transaction to the counterparty 1. This in turn displays or otherwise indicates confirmation 8 to counterparty 2, which provides or otherwise transmits 9 counterparty 1. Transaction provider 3 also transmits information about transaction 10 to recipient 2, that is, recipient of response, who, depending on communication delays and / or embodiment, can receive information immediately or over time. If the system is such that the information / confirmation is transmitted in real time to the recipient of the response, the recipient of the consideration does not need to show or show confirmation.

Using the examples described above, the consideration is a purchase or purchases, the wish-to-buyer 1 is the buyer's terminal or a combination of the buyer's terminal and the transfer server, the transaction is the transfer of a certain amount of money from buyer to seller,

20165360 prh 26-06-2016 the counterpart 2 is the trade, the counterpart 5 is in the invoice, the information 6 goes mm. trade and counterpart (cash) data to the banking system that executes the transaction 3. It returns 7 confirmation fees and 10 cash credentials as confirmation.

In the second example, the consideration is a loan, the person seeking the consideration 1 is the borrower, the transferee 2 is the bank or other borrower, the counterpart 5 is information about the collateral, information 6 includes e.g. bank and collateral information to the loan system, which executes the transaction 3. It returns 7 confirmation collateral and 10 collateral information.

In another example, the consideration is the material to be borrowed from the library, the wisher 1 is the borrower's terminal, the transferee 2 is the library, the counterpart 5 is the material identification information passing through the data 6. The transactor 3 is a library system that returns 7 quotes and

The steps / paragraphs, messages, and related functions described above in connection with Figures 2-6 are not in absolute chronological order and some steps / paragraphs may be performed simultaneously or in deviation from the given order and / or omitted. Other operations may also be performed between or within the steps / points and other messages may be transmitted between the listed messages. For example, multiple challenge responses may be required to secure a payment and / or make a payment. Another example is that the user terminal beeps when the payment is successful. One example is that the user can only be shown a selection of Fig. 7C from Figs. 7A-7C, or even not. You can also try to resolve a failed transaction or other error automatically, for example, by requesting information again. The functions described illustrate, in the devices concerned, procedures that may be implemented on one or more physical or logical entities. The messages are merely exemplary and may even comprise several separate messages to send the same information. In addition, the messages may contain information other than the above. Other messages can also be sent. For example, if the cash terminal has a connection to a transfer server, the cash terminal may send an invoice which will either be displayed on its screen or transmitted to the user terminal, including the transfer server. The transfer server may be arranged to link this invoice received from the cash terminal and the transaction request from the terminal based on, for example, the reference number 35 and, once the invoice has been paid, also send information about the successful payment to the cash terminal.

20165360 prh 26-06-2016 from a trusted partner and no other backup required. For this purpose, the transfer server may comprise a third pair of encryption key purse (encryption key purse between the cash system and the transfer server). Other server solutions can also be used.

From the examples above, it is clear that a real-time transaction for consideration is safe.

The terminal or transfer server or cash register system or similar device (s) or combination (s) of devices implementing one or more of the functionality described in connection with any one of the preceding embodiments described in Figures 2-6 includes, in addition to prior art means means for implementing the functionality of a terminal, transfer server, or unit described herein in one or more embodiments / examples, and may comprise separate means for each separate function, or means may be configured to perform two or more functions. The terminal and / or the transfer server may be configured as a computer or a microprocessor, such as an element integrated into a single microcircuit containing at least memory to provide a recording area used by the arithmetic operation and an operating processor to perform the arithmetic operation.

FIG. 8 is a simplified block diagram illustrating some of the units 800 configured to be a user terminal, or at least comprising a storage unit and / or a transactional transaction for payment or one of its subunits or a corresponding unit configured to perform such, or some of the features described in the context. In the example of Figure 8, device 800 comprises one or more interfaces (IFs) 801 for communicating with other devices, such as transaction execution system devices and / or transaction target system devices, one or more processors (PROC.) 802 configured to execute a transaction transaction unit and and / or storing30 and / or transaction with the algorithm (s) (ALG.) 803 corresponding to the functionality of the communication unit or at least one of its subunits, and memory (MEM) 804 for use in storing at least the algorithm / algorithms or corresponding set of instructions and providing protected memory for data stored therein; in addition, the interaction of one or more user interfaces (U-1F) 801 'with the user.

20165360 prh 26-06-2016

FIG. 9 is a simplified block diagram illustrating some of the functions described by the device 900 configured to be a transfer server, or at least comprising a transaction data transfer unit or one of its subunits or a similar unit adapted to perform corresponding functions or parts of the functions described in FIGS. . In the example of Figure 9, device 900 comprises one or more interfaces (IFs) 901 for communicating with other devices, such as transaction execution system devices and / or transaction target system devices, one or more processors (PROC.) 902 configured to perform a transaction transaction for consideration. at least one of its subunit functionality corresponding algorithm (s) (ALG.) 903, and memory (MEM) 904 for use in storing at least the algorithm (s) or a corresponding set of instructions. It will be appreciated that the transfer server may also be implemented as a distributed server or as a cloud server.

Fig. 10 is a simplified block diagram illustrating some of the units configured to include an invoice management unit or one of its subunits or a corresponding unit configured to perform either one or more of the device / invoice management unit combinations of Figures 4, 5A; The operations described in connection with 5B20 are zero or part of the functionality. In the example of Figure 10, device 1000 comprises one or more interfaces (IFs) 1001 for communicating with other devices, such as user terminal and hardware mode devices, one or more processors (PROC.) 1002 configured to perform the function of an invoice management unit or at least one of its subunits. a corresponding algorithm (s) (ALG.) 1003, and a memory (MEM) 1004 for use in storing at least the algorithm / algorithm or a corresponding set of instructions. Some of the memory may be protected memory. It will be appreciated that the hardware can also be implemented distributed and / or utilizing a cloud server.

For example, the processor 802, 902, 1002 may be a central processing unit, an operation processor, a logic circuit, an application-specific integrated circuit (ASIC), and a reprogrammable digital logic circuit FPGA (field-programmable gate array).

The memory 804, 904,1004 may be centralized or distributed memory and may be implemented by any memory technology or combination thereof, such as semiconductor memory, flash memory, magnetic memory, and optical memory.

The memory or portion thereof may also be an integral part of device 800, 900, device 1000 or combination of devices, or removable memory or external device memory.

In one embodiment, there is provided a computer program embedded in any processor or computer readable data storage medium 5 and comprising program instructions which, when downloaded to a device containing the processor, are part of a transaction transaction unit and / or storage unit and / or transaction unit or an extended fee transaction unit and / or invoice management unit.

It will be appreciated that other units may also be implemented with various circuits / processors, micro-software / micro-software and / or software / software.

It will be obvious to a person skilled in the art that as technology advances, the basic idea of the invention can be implemented in many different ways. The invention and its embodiments are thus not limited to the examples described above, but may vary within the scope of the claims.

Claims (19)

The claims A method of executing a real-time transaction for payment, comprising: maintaining in memory, for one or more real-time transaction execution system 5, one or more parsers, respectively, to generate transaction-related requests according to the real-time transaction execution system settings and to identify the content of the responses; maintaining, in a secure memory, encrypted requester-specific information needed to perform the transaction; 10 receiving (202, 3-3, 5) the counter value required for the real-time transaction and information on the counterparty; certified (201, 3-1, 3- 2) the right of the requester of the transaction to use the encrypted requester-specific information necessary for carrying out the transaction; if the requester of the transaction has the right to use the 15 encrypted requester-specific information necessary for the execution, the method further comprises: decrypting at least some of the requester-specific information needed to perform a transaction in secure memory; establishing (3-5, 3-6) a secure connection to the real-time transaction execution system; Generating (3-29), using a parser, a transaction request in accordance with the real-time transaction execution system settings including the response, recipient information, and at least one requester-specific information needed to perform the transaction, unencrypted; transmitting (3-30, 6) a transaction request via a secure connection to the real-time transaction execution system; and receiving (3-43, 3-42, 7,10) a transaction response on the secure connection from the real-time transaction execution system indicating whether the transaction request was successfully executed. The method of claim 1, further comprising, if the requester of the transaction has access to the encrypted requester-specific information needed to perform the transaction: receiving (3-34), over a secure connection from the real-time transaction execution system, a request for information comprising one or more specific information requests in accordance with the real-time transaction execution system settings; 20165360 prh 16-Φθ-2018 identifying (3-35) one or more specific information requested using the parser; retrieving one or more specific information requested from the decryptor-specific information required to perform the transaction; Generating (3-39) a response according to the real-time transaction execution system settings using the parser, containing the requested one or more specific information in an unencrypted manner; transmitting (3-40) the response on a secure connection to the real-time execution system. The method of claim 2, further comprising decrypting the requested one or more requester-specific information, if it is still encrypted. 15 The method of any one of the preceding claims, further comprising: maintaining a parser for two or more real-time execution systems for each execution system to generate transaction-related requests in accordance with the real-time transaction execution system settings; and 20 to identify the content of the responses; selecting (3-4) a real-time transaction execution system from two or more real-time transaction execution systems; and using the parser of the selected real-time transaction performer. The method of any one of the preceding claims, further comprising: requesting (209) through the user interface the transaction requester to confirm the transaction; and sending a transaction request only if accessed via the user interface 30 confirmation. The method of any one of the preceding claims, further comprising, if the transaction can be performed from multiple sources: requesting (206) through the user interface the transaction requester to select a source; and 20165360 prh 16-Φθ-2018 establishes a secure connection to the real-time transaction execution system where the selected source is. The method of any one of the preceding claims, further comprising: if the transaction request was successfully executed, (3-48, 10) the transaction success message is also sent to the device that received the required response for the consideration and the recipient information. The method of any one of the preceding claims, further comprising: if the transaction request was successfully executed, (3-42) the transaction success information is also sent to the location indicated by the payee information. A computer software product which, when run on a computer, causes the computer to perform a method according to any one of the preceding claims 1 to 7. A device (120,120a, 140) comprising at least Communication means (123, 143) for communicating with the transaction execution system; characterized in that the device further comprises: memory (122,142) storing at least one parser of transaction-related transaction data according to real-time transaction execution system settings 25 for generating requests and identifying the contents of the responses, and at least a portion of said memory is protected memory (122-3) storing requester-specific information necessary for the transaction; and transaction means (122-1,122-la, 141) for performing the method of any one of claims 17. The device (120,120a, 140) of claim 10 configured to authenticate transaction means prior to performing a method according to any one of claims 1-7. 20165360 prh 16-Φθ-2018 The device (120,120a, 140) of claim 10 or 11 configured to verify that the method of any one of claims 1 to 7 has been performed with the correct application and within a certain time. The device (120,120a) of claim 10, 11 or 12, which is a user terminal, further comprising a user interface for transmitting information to the user and receiving user input. The device (140) of claim 10,11 or 12, which is a transmission top server, wherein the communication means are adapted to communicate with users' terminals over a secure connection. A device (140) comprising at least communication means (143) for communicating with a user terminal (120) and a real-time transaction execution system; characterized in that: the apparatus further comprising a parser (142-2) for each real-time transaction execution system for generating transaction-related requests and identifying the contents of the responses in accordance with the real-time transaction execution system settings; the device (140) being adapted to receive, from the user terminal, the required response, the recipient information and information about the selected real-time transaction execution system that the terminal user wishes to use to execute the response, select a parser based on the selected transaction execution system; retrieve at least one requester-specific information needed to perform a transaction, which is kept encrypted, to generate a transaction request in accordance with the Real-Time Transaction Execution System Settings, which includes a response, recipient information, and at least 30 unencrypted, to send the transaction request to the real-time transaction execution system (130) and to receive a transaction response indicating whether the transaction request was successfully executed. A system (100) comprising at least one user terminal (120); 20165360 prh 16-θθ-2018 at least one transfer server (140); and at least one transaction real-time execution system (130); means (122-2) for encrypting requester-specific information needed to perform the transaction, either at the user's terminal or at the transfer server5, and temporarily decrypting at least some of the requester-specific information needed to perform the transaction; wherein in the system (100), the user terminal (120) includes, in secure memory (122), an application (122-1) for real-time transaction and at least information (122-3) for verifying user access to the application, the user terminal being adapted to transmit user authentication after successful completion, at least the information of the recipient of the required response and the response to the transfer server, characterized in that the transfer server (140) is adapted to communicate with the user terminal device (120) and the real time transaction execution system (130) and comprises a real time transaction execution system for generating transaction-related requests and identifying the contents of the responses in accordance with the settings of the transaction execution system, the transfer server (140) being adapted after receiving a response from the user terminal response and response recipient information to establish a secure connection to the transaction real-time execution system (130), to retrieve at least one requester-specific information needed to perform the transaction, to generate a real-time transaction execution system settings transaction request including response, response recipient information, and 25 unencrypted, to send the transaction request to the real-time transaction execution system (130) and to receive the transaction response indicating whether the transaction request was successfully executed. The system (100) of claim 16, wherein the transfer server (140) is adapted to receive from the real-time transaction execution system (130) one or more requester-specific identifier requests, retrieve the requested identifier (s) from the evening information, and send them to the real-time transaction execution system (130). The system (100) of claim 16 or 17, comprising at least two different real-time transaction execution systems (130); and the user terminal is configured to transmit, in addition to the required counterpart and the recipient information of the counterpart, information about the selected real-time The 5 transaction execution system the terminal user wishes to use to execute a response to the recipient transfer server (140) comprises a parser (142-2) for at least each real-time transaction execution system for generating requests and responses according to the real-time transaction execution system settings. . The system (100) of claim 16,17 or 18, wherein the transaction real-time execution system (130) is an online banking system. 20165360 prh 16-Φθ-2018 20165360 prh 16 -08- 2018 claim 1. Förfarande för att utföra en transaktion mot vederlag i realtid, whistling förfarande innefattar: att i minnet för ett eller flera system upprätthälla för utförande av en 5 transacttion respectful en eller flera parsrar för att generera transaktionsbegäran enligt inställningarna i ett system f ut utförande av en transaktion i realtid och för att identifiera innehället i £ att i ett skyddat where i kiypterad form upprätthälla begär specif data som behövs för utförande av transaktionen; 10 att (202, 3-3, 5) för att utföra en transaction i realtid en ersättning som krävs för vederlag och data av mottagaren av ersättningen; att verifiera (201, 3-1, 3-2) att den som begär transaktionen har rätt att använda krypterad begär specif data som behövs för utförande av transaktionen; ifall den som begär transaktionen har rätt att använda krypterade begär 15 specif data som behövs för utförande, innefattar förfarandet dessutom: att i det skyddade minnet decrypter ätminstone en del av begär spec data som behövs för utförande av transaktionen; att bilda (3-5, 3-6] en skyddad förbindelse account systemet f ut utförande av en transaktion i realtid; 20 att med hjälp av parsern generera (3-29] en transaktionsbegäran enligt inställningarna i systemet för utförande av en transaktion i realtid, I drag begäran innehäller en ersättning, mottagarens data och i okiypterad form ätminstone en begär spec data som behövs för ut. of the transaction; attsända (3-30,6] transaktionsbegäran med en skyddad förbindelse account 25 systemet för utförande av en transaktion i realtid; och att ta emot (3-43,3-42,7,10] med en skyddad förbindelse frän systemet f ut utförande av en transaktion i realtid et transaktionssvar som anger huruvida transaktionsbegäran utfördes med framgäng. 30 2. Förfarande enligt patentkrav 1, som dessutom innefattar, ifall den som begär transaction har rätt att använda krypterade begär spec data som behövs för utförande: att ta emot (3-34] med en skyddad förbindelse frän systemet för utförande av en transaktion i realtid en begäran om tillaggsinformation, som 35 innefattar begäran om en eller flera vissa data enligt inställningarna i systemet för utförande av en transaktion i realtid; 20165360 prh 16 -08- 2018 att identifiera (3-35] parsern med hjälp av de begärda en eller flera vissa data; att bland okrypterade begär spec data som behövs för utförande av transaktionen hämta de begärda en eller flera begärda data; 5 att med hjälp av parsern generera (3-39] et <RTIgt; enligt </RTI> inställningarna i systemet för utförande av en transaction i realtid som innehäller de begärda en eller flera begärda data i okrypterad form; att sända (3-40] pounds med en skyddad förbindelse account systemet för utförande i realtid. 3. Förfarande enligt patentkrav 2, som dessutom innefattar decryptering av de begärda en eller flera begärda begär spec data ifall de fortfarande är krypterade. 15 4. The patent application of the Förfarande enligt verge av föregäende, som dessutom innefattar: att upprätthälla för tvä eller flera system för utförande i realtid för respektive utförandesystem en Parser för att generera transaktionsbegäran enligt inställningarna i systemet f ut utförande av en transaktion i realtid och för att 20 identifiera innehället i pound; att field (3-4) et system för utförande av en transacttion bland ett eller flera system för utförande av en transaction i realtid; och att använän parsern för det Command systemet för utförande av en transaktion i realtid. 5. Förfarande enligt verge av föregäende patentkrav, som dessutom innefattar: att begära (209] via användargränssnittet en bekräftelse av transaktionen av den som begär transaktionen; och 30 att en en transaktionsbegäran about yourself ifall en bekräftelse erhälls via användargränssnittet. 6. Förfarande enligt verge av föregäende patentkrav, som dessutom innefattar, ifall transaktionen kan utföras frän flera olika källor: 35 att begära (206] via användargränssnittet att den som begär transaktionen väljer källan; och 20165360 prh 16 -08- 2018 att bilda en skyddad förbindelse till det system för utförande av en transaktion i realtid där den Valda källan finns. 7. Förfarande enligt Face to face patent for föregäende, som dessutom 5 innefattar: ifall transaktionsbegäran utfördes med framgäng, att sända (3-48, 10) information om den genomförda transaktionen även account den anordning, frän vilken en ersättning som krävs för vederlag och mottagarens data mottagits. 10 8. Förfarande enligt Face to face patent for föregäende, som dessutom innefattar: ifall transaktionsbegäran utfördes med framgäng, att sända (3-42) information om den genomförda transaktionen även account en plats som mottagarens data anger. 9. Dataprogramproduct, som vid datorkörning The computer program attorneys föregäende patentkrav 1-7. 10. Anordning (120,120a, 140), som innefattar ätminstone 20 data-verföringsorgan (123, 143) för att communicator med systemet för utförande av en transaktion i realtid; kännetecknad av att anordningen dessutom innefattar: to where (122, 142), i flash the lags ätminstone en parser för att generera transaktionsbegäran enligt inställningarna i systemet för utförande av en 25 transactions i realtid och för att identifera innehället i pound, och av whiskers ätminstone en del är skyddat minne -3), i flashes lagrats begär spec data som behövs vid transaktionen; och transaktionsorgan (122-1,122-la, 141) för att utföra förfarandet engott face av patentkraven 1-7. 11. Anordning (120,120a, 140) is patent patent 10, som configurator for the verifiers of the transacting organization is first seen in patent patent 1-7 utförs. 20165360 prh 16 -08- 2018 12. Anordning (120,120a, 140) enjoys patent loading 10 eller 11, som configurator att verifiera att et förfarande en avant face avert kraven 1-7 utter the correct program and all the programs. 5 13. Anordning (120,120a) enligt patent krav 10, 11 eller 12, som an anternet terminal a dessutom innefattar et anterdargränssnitt för att överföra data till användaren och för att ta användarens Indata. 14. Anordning (140) en patent patent claim 10, 11 eller 12 som en 10 øverföringsserver, i flashing dataöverföringsorganen anpassats att kommunicera med användarnas terminaler over en skyddad förbindelse. 15. Anordning (140), som innefattar ätminstone dataöverföringsorgan (143) för att kommunicera med användarens 15 terminal (120) och systemet för utförande av en transaktion i realtid; kännetecknad av att: anordningen dessutom innefattar en Parser (142-2) för respektive system för utförande av en transaction i realtid för att generera transaktionsbegäran enligt inställningarna i för utförande av en 20 transactions i realtid och för att identifiera innehället i pound; varvid anordningen (140) anpassats att, efter det den frän användarens terminal mottagit en ersättning som krävs för vederlaget data av mottagaren av ersättningen och data av etvt system för utförande av en transaction i realtid som användare av terminalen vill använda 25 mottagaren, on basis av Command systemet för utförande av en transaction parser, att bilda en skyddad förbindelse account systemet (130) för utförande av en transaction i realtid, att hämta begär spec data som lagras i krypterad form och som behövs för att utföra ätminstone en transaction, att generera en transaktionsbegäran enligt inställningarna i systemet för utförande av en 30 transactions i realtid, som innehäller en ersättning, mottagarens data och ätminstone en okrypterade begär spec data av data som behövs för utförande av en transaction, att hen en transaktionsbegäran account systemet (130) för utförande av en transaktion i realtid och att ta ett transaktionssvar, som anger huruvida transaktionsbegäran utfördes med framgäng. 20165360 prh 16 -08- 2018 System (100), som innefattar ätminstone en användarterminal (120); ätminstone en överföringsserver (140); och ätminstone ett system (130) f ut utförande av en transaktion i realtid; 5 organ (122-2) for att upprätthälla krypterade begär spec data som behövs för utförande av transaktionen antingen i användarens terminal eller i överföringsservern och för att tillfälligt decryptera tarminst en del av begär spec data som behövs för utförande av transaktionen; i flash system (100) 10 användarens terminal (120) i to skyddat where (122) innehäller ett program (122-1) för transaktionen i realtid och ätminstone data (122-3), med vv användarens rättighet att användar programmetkan verifieras, varv användarens terminal anpassats att efter genomförd verifiering av användaren förmedla ätminstone en ersättning som krävs för vederlaget och data av en mottagar av 15 ersättningen account överföringsservern, kännetecknat av att överföringsservern (140) anpassats att reserve i förbindelse account användarens terminal (120) och account systemet (130) för utförande av en transaktion i realtid och innefattar för systemet för utförande av en transac 20 Parser (142-2) för att generera transaktionsbegäran enligt inställningarna i systemet för utförande av en transaction och för att identifier innärvel i på, color överföringsservern (140) anpassats att, sedan den frän användarens terminal tag som en försning vederlaget och data av mottagaren av ersättningen, bilda en skyddad förbindelse account systemet (130) för 25 utförande av en transactional, hämta begär spec data som behövs för utförande av ätminstone en transaktion, generera en transaktionsbegäran enligt inställningarna i systemet, för utförande av en transactional, data av mottagaren ø begär spec data av data som behövs för utförande av en transaktion, sända en 30 transaktionsbegäran account systemet (130) för utförande av en transaktion i realtid och sensing transaktionssvar, som anger huruvida transaktionsbegäran utfördes med framgäng. 17. System (100) enligt patent No. 16, Colors 35 överföringsservern (140) anpassats att frän systemet (130) f ut utförande av en transaktion i realtid ta en enerer flera begär specifika codbegäran, att hämta frän den begär specika data den begärod coden eller coderna och att sänd dem account systemet (130) för utförande av en transaktion i realtid. 5 System (100) enligt patent krav 16 eller 17, innefattande ätminstone tä system (130) f ut utförande av en transaktion i realtid; användarens terminal configurator för att förmedla, utöver ersättningen som krävs för vederlaget och data av mottagaren av ersättningen, data av det 10 av terminal vill använda för utförande av ersättningen account mottagaren, och överföringsservern (140) innefattar ätminstone för respektive system för utförande av en transaction i realtid en parser (142-2) för att generera och sv enligt inställningarna i systemet transactional realts, colors överföringsservern anpassats att field en parser pä basis av mottagarens 15 date. The system (100) encompasses a patent document 16, 17 eller 18, a system system (130) for use in the transaction and the bank system.