SI22595A - Procedure and system for safe and simple paying by way of mobile terminal - Google Patents

Abstract

Subject of the invention is a system for safe and simple paying by way of mobile terminal which provides the user of a mobile phone or similar terminal (even the most basic one) capable of receiving and sending standardised messages (SMS, MMS, USSD and similar) that with it he can authorise and complete a credit payment in favour of the goods or service provider. The subject of invention enables simple payments by a mobile terminal which is enabled by implementing the procedure where the seller sends (step 1) the buyer (payee) to his mobile phone a draft of the original invoice (m-invoice) which includes at least the beneficiary's account as well as total amount for payment with the option of displaying some other data like for example due date and purpose so that the client can more easily identify the payment. After that the client with his private key, stored on the smart SIM card digitally signs the corresponding money order and sends the signed money order (m-payment) to the payment service provider who maintains his debit account specified in the payment instructions (step 2). After the completion of payment the payment service provider (usually a bank) sends a confirmation on the completed transaction to the buyer (step 3a) and another one to the seller (step 3b).

Description

(57) The object of the invention is a system for secure and easy payment with a mobile terminal, which enables the user (also a completely ordinary) mobile phone or similar mobile terminal to receive and send standardized messages (SMS, MMS, USSD and the like) with authorize and make a credit payment to the provider of the goods or services. The subject of the invention makes it easy to pay with a mobile terminal, the realization of which enables the execution of a process whereby the seller sends (step 1) to the buyer (payer) an extract of the original invoice (m-invoice) containing at least an approval account and a total payment amount on his mobile phone , but may also include some other information, such as the date of the currency and the purpose of making it easier for the buyer to recognize the payment. The buyer then digitally signs the corresponding payment order with his private key stored on the smart SIM card and sends the signed payment order (m-payment) to the payment service provider with the debit account specified in the payment order (step 2). After the payment is made, the payment service provider (usually a bank) sends a receipt to the buyer (step 3a) and the seller (step 3b) a receipt for the transaction.

SECURITY AND EASY PAYMENT PROCEDURE AND SYSTEM

WITH MOBILE TERMINAL

The subject of the invention is a method and system for secure and easy payment with a mobile terminal, which enables the user of a mobile terminal (usually a mobile phone) to receive and send standardized messages (for example SMS, MMS, USSD and the like), which we will hereafter called short messages to authorize a credit payment to a provider of goods or services. The invention belongs to the class G 06 F 17/60 of the international patent classification and belongs to the systems for secure and easy remote payment, which in order to maintain the confidentiality, integrity and authenticity of the payment order for transferring money from the payer's account and held with the payment service provider ( usually a bank) and will hereinafter be referred to as a bank account, using the Public Key Infrastructure (PKI) of the recipient's bank account, whereby the buyer (payer) has his private key inalienably stored on his Subscriber Identification Module (SIM) card. mobile terminal, and communication between the customer and the payment system is via the PLMN Public Land Mobile Netvork via a short message exchange.

The technical problem that the present procedure and system for secure and easy payment with the mobile terminal according to the invention solves satisfactorily, is the setting up and realization of such payment system for making payments with the mobile terminal, which enables the customer to pay for goods and services easily and securely directly with your bank without using other payment instruments (such as payment cards).

There are 5 known solutions for payment using a mobile terminal. Most solutions use the mobile terminal only as a payment authorization channel for payment cards, such as US Patent Document US2003069792A1 and US Patent Document US2003171993A1, and are therefore primarily intended to make payments for online purchases. Such solutions do not allow for (remote) payment directly from the customer's account held with the payment service provider and require (at least indirectly) the use of other means of payment (eg payment cards) and / or internet usage to make the payment. The non-payment card payment version of the online payment solution is the solution described in patent document WO2006128215A1. The solution is limited to internet shopping only, and its drawback is the rather complicated use of technology that is not supported by all mobile terminals (java technology).

The second group of mobile terminal payment solutions focuses on payments for recharging a prepaid account, which then serves to pay for mobile telephony services. This method of payment can only be used to a limited extent (ie micropayments) to pay for goods and services of other vendors or providers other than the mobile operator, especially due to limited funds in the user's prepaid account and relatively low security standards for making the payment. For example, the paybox TopUp Mobiliser solution from paybox.net AG.

Furthermore, there are solutions (such as M-Pay or EP 1 777 972 A1) where the buyer credits the provider of the goods or services through the mobile terminal and credits the user with the mobile operator's credit for the mobile telephony service mobile operator. Because these solutions carry the risk of operator default, this mobile payment group is also intended to pay only small amounts.

There is also a solution according to patent document W003107288A1, which provides for the settlement of a payment directly from a user's account with an io payment service provider, and which is not intended solely for payment for purchases made online. This mobile payment solution has user and security flaws, as the user must enter the type of data himself, and identification and authorization can only be misused by calling a number (CLIP) and using a PIN, no matter how well the user takes care of his or her security.

The subject of the invention is a system for secure and easy payment with a mobile terminal, the realization of which enables the implementation of a procedure whereby the seller sends to the buyer (payer) on his mobile phone an extract of the original invoice (m-invoice) containing at least the approval account number and the total amount for payment, but also some other information, e.g. debit account, currency date, and purpose to make it easier for the buyer to recognize the payment. The buyer then digitally signs the payment order with his or her private key stored on the SIM card and sends it to the payment service provider (usually the bank). After the payment is made, the payment service provider sends the buyer and the seller a confirmation of the transaction.

The invention will be explained in more detail on the basis of the implementation process and pictures, of which it shows:

Figure 1: Flow of document exchange between participants in the proposed process for secure and easy payment with the mobile terminal according to the invention Figure 2: depiction of the system for performing the procedure for secure and easy payment with the mobile terminal according to the invention with individual units and connections between them Figure 3: View system for performing the procedure for secure and easy payment with the mobile terminal according to the invention with a single unit for receiving and distributing both m-bills and m-payments

The purpose of the present invention is to introduce a new approach to mobile payment, which eliminates or at least minimizes exposure / risk while making it much easier and more affordable to pay. Risk exposure and / or complexity and accessibility, especially on the buyer side, are further characteristic of systems and approaches known to date, some of which are listed in this application.

The specificity of the present invention is that it provides a new process and are an appropriate implementation system for connecting several appropriately adapted units to a payment system that introduces a new approach to mobile payment. This approach and the associated mobile payment has all the features of a secure credit payment, in which the account holder submits a signed payment order to his account with the payment service provider (e.g.

bank) with which he has an account.

The payment procedure and the relationships between payment entities are shown in Figure 1 and show the flow of document exchange between participants in the proposed process for secure and easy payment with the mobile terminal of the invention:

- the payment is initiated by the seller by sending (directly or indirectly) the payment elements to the buyer's mobile terminal (step 1). These payment elements are part of or an extract of the original invoice and are hereinafter referred to as the "m-invoice";

the buyer at the mobile terminal confirms that he wants to pay the bill, determines the io account from which he wants to pay the payment, and by entering a password to access his private key, he initiates the process of digitally signing the payment order on the SIM card. Hereinafter, such digitally signed payment order is labeled "m-payment"; After the signing is completed, the m-payment is sent to the payment and service provider (for example, the bank), where the buyer has a debit account (step 2). When the payment is made with the provider, the payment service provider sends a payment notification to the buyer at the mobile terminal (step 3a) and the seller to the system where the payment is initiated (step 3b). The following is a payment between

2O settles buyer and seller payment service providers according to the applicable settlement rules in the financial space (eg interbank clearing systems) (step 4), which causes the seller to receive a paper / electronic inflow notification from his bank (step 5).

The present invention also addresses mobile payments for certain pre-scheduled transactions (eg, prepaid billing for telephone service users), for which vendors send / configure payment items (bill) in advance at customers' mobile terminals. In this case, the customer only chooses the appropriate service (m-invoice) when he / she needs it, and then proceeds as described above.

The procedure described above also applies to the filling of an Near Field Communication account. The user can securely confirm with a mobile terminal the transfer of funds from his account with a payment service provider (eg from his bank account) to his NFC account, from which draws funds when making payments using said technology.

The proposed mobile payment is equivalent to a cash payment at a cashier, a credit payment at a bank window, or a secure one, i.e. digitally signed payment via the Internet, and of course the advantage is that the buyer can sign the payment at any time and everywhere where he has an accessible mobile network service for the exchange of (short) messages. In doing so, it is independent of the location of the merchant and the location of its payment service provider and does not require access to any additional devices (such as a computer with Internet access, a POS device, and more).

The proposed payment system is based on the method of secure mobile payment using appropriate computer, communication and

2o of the software and the ordinary and mobile telecommunication networks according to Figure 2 and Figure 3. As shown in Figures 2 and 3, the proposed payment system consists of m-invoicing units (la and / or Ib), receiving and distribution units m-invoices (II), units for preparing and signing m-payments (III), units for receiving and distributing m-payments (IV), and units for executing and settling m-payments (V). Understandably, content-related units and equipment are taken care of by their owners (seller for units la and Ib, buyer for units III, banks for units V). Specialized infrastructure units may, however, be set up with the above entities (units II at the vendor, units IV at the buyer's bank), and more rationally and efficiently set up as infrastructure by trusted business entities, similar to the practice of certification agencies for issuing digital certificates.

The units for issuing m-invoices (la and Ib) are upgrades of sales systems that enable the selection of goods or services, the issuance of original invoices, the execution of payment and, in certain cases, the issue of goods. Each m-invoicing unit (la and Ib) has a module for creating an account statement, a module for defining the customer's mobile terminal number to which the m-invoice is intended, and a module for digitally signing the m-invoice (if such legislation or if this is the practice or if this is the way of identifying the seller in the unit for receiving and distributing m-invoices (II). The m-invoicing unit (la and Ib) connects to the m-invoice receiving and distribution unit (II) with the m-invoice delivery module and the payment status feedback module linked to a particular m-invoice .

According to the present invention, the original invoice extract contains at least an approval account, that is, the invoice to which the seller wishes to receive funds, and a total amount for payment.

Optionally, a short payment purpose is included in the abstract, which makes it easier for the buyer to recognize the payment at the mobile terminal. Other optional data are also possible, including the debit account, which is the account from which the buyer wishes to pay, and the date of the payment currency, which is the date when the payment should be settled. The payment currency date is usually used only in automatic m-invoicing units (the description is given below).

The present invention addresses two different ways of linking m-invoicing units 5 (la and Ib) with m-account receiving and distribution units (II).

Stationary invoicing units (1a) connect to the m-invoice reception and distribution units (II) through a fixed telecommunications network (eg, local area network, VPN, Internet) and are further subdivided into t.i.

automatic and interactive systems.

Automatic stationary invoicing units (la) include units where m-invoices are issued to sellers in relevant applications based on the customer register, which contains a link between the buyer's number and the number of his mobile terminal and, in certain embodiments, also the number buyer's bank account. Such automatic units are usually used by sellers who have a large number of regular customers and are therefore also suitable for paying regular obligations (eg utilities, electricity). Automatic units most often operate in i.e. batch mode in the m-invoicing phase and in the acceptance phase of payment statuses that are

2o related to issued m-bills.

Interactive stationary units for issuing m-invoices (la) are units where the information for issuing and routing m-invoices is entered interactively in the relevant application. The feature of the interactive units is that, after confirming the correctness of the entry, they immediately issue an m-invoice by sending the m25 invoice immediately to the unit for receiving and distributing the m-invoices (II) and to wait for payment information in the same session. Interactive units can be direct, that is, the data is entered by the seller itself, or indirect, that is, they are integrated into the seller's online store, which allows the data to be entered by the buyer. Such interactive systems are usually implemented on the seller's websites.

Mobile m-invoicing units (Ib) connect to the m-invoice receiving and distribution unit (II) through a mobile telecommunications network (PLMN). Basically, these are interactive units that allow you to enter the elements of an m-invoice and enter the number of its mobile terminal, review the entered data, issue an m-invoice (if necessary digital signature) and send an m-invoice to the unit for receiving and distributing m-invoices (II) via the mobile telecommunications network. The payment status related to the issued m-invoice is returned via the mobile telecommunication network to the number that the m-invoice has forwarded as soon as the payment is made.

The m-invoice receiving and distribution unit (II) is the intermediary between the m-invoicing unit (la and Ib) and the m-payment preparation and signature unit (III). The unit for receiving and distributing m-invoices (II) has a module for receiving m-invoices, a module for identifying the sender of the m-invoice, a module for checking the integrity of the m-invoice (usually via a digital signature of the issuer), a module for sending the m-invoice to the mobile terminal customer, module for taking over and further forwarding the status of payments related to the m-invoices sent. The unit for receiving and distributing m-invoices (II) contains a register of vendors and their ace identification elements (usually digital certificates, which need to be validated in this case) and a database of issued m-invoices and payment statuses, which are linked to issued m-bills. The unit also has access to local or external registers of valid and revoked digital certificates.

The M-invoice Receiving and Distribution Unit (II) typically has 5 additional modules, which, in conjunction with the M-Payments Preparation and Signing Unit (III), allow payment of those m-invoices that are still valid (have not expired yet) value date) and which were not paid as soon as the customer received a notification to their mobile terminal.

The unit for preparation and signature of m-payments (III) is connected via the mobile 10 telecommunication network to the unit for receiving and distributing m-invoices (II) and to the unit for receiving and distribution of m-payments (IV). The unit for preparing and signing m-payments (lil) has a module for receiving m-invoices, a module for selecting a debit account if multiple accounts are possible, a module for preparing and digitally signing a payment order, a module for sending m-payments and is a module for assuming payment execution status. The M-Payment Receipt and Distribution Unit (IV) contains a register of possible debit accounts if the implementation is such that the debit account is not part of the m-account.

The m-payment (lil) preparation and signature unit typically has an optional module that allows this unit (III) to postpone those m-invoices that

2o were not paid as soon as the customer received a notification to their mobile terminal.

The special unit of the preparation and signature unit of m-payments (III) is considered to be the unit containing the module for payment of prepaid services. This module is closely linked to the register of prepaid services, such as the filling of a prepaid account for mobile telephony. Pre-prepared services include the so-called. topping up the invoice that the customer uses to make payments with NFC. In addition to the NFC account replenishment module, in the proposed system and in the lil preparation and signature unit, in this case, there are also modules for actually updating the balance of funds in the NFC account in the database and mobile terminal, when the amount of available funds store there too.

The M-Payment Preparation and Signing Unit (III) may also include infrastructure modules (Digital Certificate Acceptance and Renewal Module, Registry of Potential Billing Accounts and Module for Maintenance and Addition of New Prepared Services). units at a distance.

The unit for receiving and distributing m-payments (IV) is connected via the mobile network to the unit for preparing and signing m-payments (lil), and via the fixed telecommunications network to the unit for execution and settlement of payments (V). The unit for receiving and distributing m-payments (IV) has a module for receiving m-payments, a module for authenticating m-payments (customer), a module for verifying the integrity of m-payments (based on digital signature verification), a module for sending m - payments to the unit for execution and settlement of payments, module for accepting and further forwarding the status of execution of payments. The unit for receiving and distributing m-invoices (II) contains a register of payment service providers (including their communication specifics), as well as a database of accepted m-payments and associated payment execution statuses. The unit also has access to local or external registers of valid and revoked digital certificates.

Each M-Payment Execution and Settlement Unit (V) integrates the M-Payment Receipt and Distribution Unit (IV) with existing complex payment order reception, execution, and settlement systems with payment service providers (eg banks). It shall contain at least an module for receiving m-payments, a module for verifying the authority of the signatory on a defined debit account, and a module for making a payment that verifies that there is sufficient funds in the account, make a payment, and return the status of payment execution to the receiving and distribution unit of m-payments . The payment execution and settlement unit (V) with the payment service provider shall at least contain a register of customers (customers), their digital certificates and their authorizations.

The advantage of the present invention is first of all the fact that all the information about the payment order is only merged in the buyer's mobile terminal and that it is also digitally signed in such a way that in the continuation of the payment process ensures the unambiguous authentication of the signatory and the integrity and security of the payment order. In other words, this means that a digitally signed payment order can only be issued with a properly owned and adapted mobile terminal owned by the customer and is one of the units of the system used in the described procedure. If the buyer does not sign the payment order with his / her mobile terminal, the payment order cannot be issued in this way in any other way, thus it is practically impossible to embezzle or invade the system.

2o There is no risk even in case of loss / alienation of the mobile terminal, as access to the private key on the SIM card is actively protected. If someone enters the wrong password (such as a 6-digit PIN or other alphanumeric code, for example) to access their private key several times in a row (eg three times), the signing function in the mobile as terminal is blocked and can no longer be used to use.

Another advantage of the present invention is the ease of use, which is particularly important for the buyer or payer included in the payment chain with the mobile terminal. The technical characteristics of mobile terminals, which are primarily meant by a small screen and lowercase letters on the screen and 5 keyboards, are not comparable to other interactive computing devices, so it is a proposed solution that requires only the customer to review the m-invoice and, in the basic version, a single entry , this is to enter your password to access your private key, the simplest possible solution.

Last but not least, the proposed method of mobile payment can be realized at any mobile terminal that supports short messaging technology (for example SMS), which is why this method of payment is available today to practically all holders of mobile phones, PDAs or other mobile terminals that use wireless communication network.

is The digital signature of the m-invoice or m-payment guarantees the integrity and integrity of the document on the go, while audit-safe archiving guarantees the integrity and integrity of the document during the statutory retention period. Audit-safe archiving can be established with an individual business entity (archive of m-invoices at vendors, archive of m-invoices at payment service providers). It is most rational and efficient to set up secure audit archiving as an infrastructure for trusted business entities, since in this case the same archive can be used by all entities in the mobile payment chain: seller, buyer and payment service providers.

Assuming that digital certificate holders whose private key is stored on the SIM card of the mobile terminal and actively protected behave like prudent masters and in accordance with the policy of the digital certificate issuer, the proposed payment system is completely secure as it prevents anyone with came up with information that could have authorized the payment order.

The confidentiality of documents on the go is ensured by the use of appropriate encryption methods (eg 3DES / AES symmetric encryption systems and PKI technology).

The present invention is understandably related to the proposed units and their connection 10 and also defines the method of how these units operate and interconnect.

According to the invention, an invoice is prepared in the m-invoicing unit (la and Ib) on the basis of the original invoice containing at least the approval account and the amount, usually the purpose, and optionally also the date from the currency and other information. This account extract shall be signed, where necessary (depending on the law or practice or arrangement), with the appropriate digital certificate and equipment (HSM or smart card; the server certificate on the disk only if the access to the server is properly protected) and shall be accompanied by a telephone number the customer 's mobile terminal is forwarded by

2On a local or telecommunications network, a unit for receiving and distributing m-invoices.

The M-invoice Reception and Distribution Unit (II) picks up and verifies the invoice and the identity of its issuer. If the issuer is included in the proposed payment system and everything is OK with the m-account, it sends the m-account through the mobile communication network to the unit for preparation and signature of payments (lil).

The unit for preparation and signature of m-payments (lil) is realized in a mobile terminal containing an appropriate smart card, e.g. SIM (Subscriber ldentity Module 5). When this unit (III) receives an m-payment, it offers the buyer the opportunity to pay for it. When the buyer confirms that he wants to pay the invoice, he programmatically determines the invoice from which he wants to pay the payment. If the debit account is already defined in the payment, this is the default debit account. Otherwise, the account is determined based on configured accounts in the mobile terminal. If more than one possible debit account is configured, the buyer must choose which one to pay from. Otherwise, the buyer does not enter anything, since the only configured account defaults to the debit account. The customer then enters a password (for example, a PIN - Personal Identification Number) to access his private key, which triggers a process that, in a smart card, such as a smart card. It builds a payment order and digitally signs the SIM card.

The password to access your private key is different from the PIN code to secure your phone and thus access normal mobile services. The PKI (Public Key Infra raster) signing process is based on a digital certificate and a private key on the card that is actively secured. The private key is actually the only really secret information and is unknown to anyone (not even the owner).

After the signing is completed, the m-payment containing the digitally signed payment order is sent to the unit for receiving and distributing m-payments (IV) via the mobile telecommunication network. It verifies the m-payment and customer identity. If the customer has a valid digital certificate and everything is OK with the m-payment, he sends the m-payment to the m-payments (V) execution and settlement unit, which is the entry channel for mobile payments from the payment service provider where the customer is open an account listed as an debit account in m-payment.

The M-Payment Execution and Settlement Unit (V), based on the digital certificate of the buyer who has signed the m-payment, first checks that this person is indeed authorized to make payments on the specified debit account. If it is, it sends the payment for execution. The m-payment (V) execution and settlement unit of a particular payment service provider is usually common to all channels (bank box, electronic bank) and makes payment if there is sufficient funds in the account, otherwise the payment is declined.

If payment is made to the payment service provider, then the payment service providers of the buyer and the seller are subsequently settled according to the applicable settlement rules in the financial space (eg interbank clearing systems), which causes the seller to receive paper / electronic from his payment service provider inflow notification.

The payment service provider shall notify the payment execution status unit of m-payments (V), which, in conjunction with other units in the mobile payment chain, may provide that status feedback is payment executions related to a specific m- transfer the invoice to the buyer at the mobile terminal and the seller to the system where the payment was initiated.

In embodiments where the proposed payment system has a m-payment (lil) preparation and signature system, i.e., pre-scheduled transactions are set up at the customer's mobile terminal (eg, filling in a prepaid account for users of telephone services or an NFC account) and for which Sellers send / configure payment elements (m-invoice) in advance, and the buyer simply selects the desired transaction from the menu, and consequently also the invoice, if necessary, selects a debit account and enters a password to access his private key, which triggers payment preparation, digital signing and sending m-payment.

One of the predefined payments is the filling of an NFC account, which, in addition to the procedures listed in conventional m-payments, also requires an update of the NFC account balance in the NFC provider's database and the amount of balance at the mobile terminal when stored. even there. The amount of available funds in the NFC account is refreshed in the database via a network connection immediately after the payment or transfer of funds, and at the mobile terminal through the feedback received by the software at the terminal via the mobile network or via the NFC channel when mobile the terminal is also attached to the appropriate NFC reader / transmitter.

In the present invention, the issuance and maintenance of a digital certificate database can be implemented by the individual entities involved in the payment (seller and payment service provider of the buyer), by trusted business entities where it is implemented e.g. the unit for receiving and distributing m-invoices (II) and / or the unit for receiving and distributing m-payments (IV), or at already existing certification agencies (CA). In case the certification agencies are outside the systems described, it is necessary to implement the appropriate interfaces in the units that need information on the issued / revoked digital certificates.

The present invention is similar to audit-safe archiving, which can be implemented with individual entities involved in payment (seller and buyer payment service provider), with trusted business entities where it is implemented e.g. the receiving and distribution unit of m-invoices (II) and / or the receiving and distribution unit of m-payments (IV), or with existing archiving agencies. In case the archiving agencies are outside the system described, it is necessary to implement the appropriate interfaces for the transfer of documents, which must be kept in the long-term audit.

The present invention provides a number of advantages in mobile payment compared to other systems and methods. No sensitive information is transmitted through public networks (such as credit card number; the only truly secret information, that is, the private key is unknown and not even accessible to the owner). The highest possible and commercially available level of mobile payment security is ensured, as the integrity and security of the mobile payment and, if necessary, the mobile account are ensured at the time of payment and within the statutory time limit, provided that these mobile documents are archived securely in the long term. The data is encrypted during transmission over public networks, which means that confidentiality of the data is also ensured. It is quite easy to pay by the described procedure, since in the basic version you need to enter a single data, that is, passwords to access your private key. Last but not least, the use of text messaging technology, which is supported by virtually all mobile terminals today, makes payment with the proposed systems and methods accessible to virtually anyone.

The proposed payment system with the units included therein, the characteristics of these units and the links between them are described in detail below with the respective schemes in Figure 2 and Figure 3. Of course, it should be borne in mind that the schemes are merely illustrative and given for ease of understanding .

from the Schemes, however, they do not define the limits of the invention defined by the claims.

Each m-invoice directed to the user's mobile terminal is created in the m-invoicing unit (la and / or Ib). The module for creating an account summary is responsible for the preparation of basic m-account information such as the amount, purpose and approval account. In preparing the abstract, the module uses the appropriate w electronic invoice format when it comes to automatic stationary units for issuing m-invoices (la), otherwise the invoice data is determined interactively by entering it in the appropriate software solution.

The module for defining the customer's mobile terminal number in the m-invoicing unit (la and / or Ib) adds the telephone number from the customer's mobile terminal to the account information. The module uses the PTN user telephone number register when it comes to automatic stationary units for issuing m-invoices (la), otherwise the telephone number is entered into the m-invoice at the time of purchase.

The digital signature module, however, makes sure that the m-invoice is digitally signed 20, if so provided in the specific m-invoicing unit (la and / or Ib).

An M-invoice can be automatically created and digitally signed in back-office processing by a large provider (large providers) or data and m-invoices can be prepared interactively and digitally signed at the time of purchase using the appropriate equipment (eg, online store, call center for catalog sales, mobile m-invoicing unit (Ib)).

The m-invoicing units (la and Ib) forward the prepared m-invoices to the m-invoice receiving and distribution unit (II) (step 1). The information is exchanged over the public fixed telecommunications network NET (unit la) or the public mobile telecommunications network PLMN (unit Ib) via the m-invoice delivery module in the m-invoicing units (la and lb) and the m-invoice receiving module in the bill receipt and distribution unit (II).

io When a module for receiving m-invoices in the unit for receiving and distributing mcats (II) successfully receives a new m-invoice, it transmits it to the module for identifying the sender or issuer of the m-invoice. The sender identification module uses the MTP Registered Issuers Database, which, based on the identification data from the m-invoicing unit (la and Ib), finds the appropriate record and verifies that the unit is authorized to submit m-invoices. Issuer identity verification is typically performed on the basis of a digital certificate that connects the m-invoicing unit to the m-invoice receiving and distribution unit (II). Where legislation or the environment requires that the m-invoices issued are digitally signed, the identification shall also be verified on the basis of the digital certificate with which the m-invoice was signed.

The authenticity of the digital certificates used in the m-invoice receiving and distribution unit (II) is also previously verified in the directory of valid digital certificates of the CDR. In addition to the authentication of the certificate, the validity of the certificate as well as the status of the certificate in the list of revoked digital certificates CRLs published by the digital certificate issuer on the system or by an independent external certification authority (CA) shall also be verified.

The identity of the issuer using a mobile unit for issuing m-invoices that does not support the use of PKI functionality is performed on the basis of terminal identification (SIM card serial number and telephone number), shared secrets between the terminal and the m- (II) accounts, and MAC (Message verification codes)

Authentication Code).

All of the above mechanisms (digital certificates and digital signatures, directory of 10 digital CDR certificates, certificate validity, MAC codes) ensure that the m-invoice receiving and distribution unit (II) can authentically verify the issuer identity of each m-invoice transmitted to system, thus ensuring the authenticity of the m-account and, consequently, the payment information.

In addition to the issuer's authentication, the m15 invoice (II) receiving and distributing unit in the m-invoice integrity module using a digital signature or MAC verification code also authentically verifies the integrity of the accepted m-invoice, which together with the authenticity means that each invoice was created in the authorized m-invoicing unit (la and Ib) that the information was entered into the m-invoice by an authorized issuer and that no one changed it on the route.

After verifying the authenticity and integrity of the m-invoices, the m-invoices are stored in the MBA m-accounts database. If necessary (regulatory or regulatory requirement), these m-accounts can also be archived in an audit-safe manner over the long term. In this case, the authenticity and integrity of the archived m-invoices is ensured by digital signature technology, time stamping, audit trail retention and access control to the archive.

After verifying the identity of the issuer, verifying the integrity of the m-invoice and storing the m-invoice in the database, the unit for receiving and distributing ms invoices (II) sends the m-invoice via the PLMN public mobile telecommunication network to the customer's mobile terminal via the m-invoicing module, that is, the M-Payment Preparation and Signing Unit (III), where it is accepted by the module for receiving m-invoices (step 1a).

The module for receiving m-invoices in the unit for preparing and signing m-payments (III) 10, using cryptographic algorithms, first verifies that the m-invoice is submitted by an authorized unit for receiving and distributing m-invoices (II). In the M-Payments Preparation and Signing Unit (III), all relevant m-account information is then combined into a payment order, which also defines a debit account (eg, a user's bank account). When the debit account information is not part of the mi5 account, in the debit account selection module, the account is read from the DAC debit account register. if there is only one debit account in the registry. If there are more than one account in the DAC register, the debit account selection module displays to the user on the terminal screen a menu where the user selects the appropriate account.

When the payment order is fully prepared, it contains at least the amount, the approval account and the debit account, and optionally the purpose of the payment and the date of payment when it comes to payment with a future currency date. The module for preparing and digitally signing a payment order displays a summary of the order to the user and offers him the option to confirm or decline the payment. If the payment is confirmed, it allows the user to enter a password (for example, a PIN), which unlocks the private key on the SIM card, thus allowing the payment to be digitally signed in the security module of the card. The digital signature operation is performed in the security module so that the user's private key never leaves the protected space on the SIM card and remains secret throughout the process.

The M-Payment Preparation and Signing Unit (lil) has a storage space on the SIM card for storing predefined invoices (eg, filling in a prepaid account with a mobile operator, filling an NFC account) in the CPY prepaid services register.

Pre-stored m-invoices from the CPY register behave similarly to eclipses sent to the mobile terminal by the invoice receiving and distribution unit (II), except that they are processed by the prepaid payment module instead of the m-invoice receiving module. The M-account in this case also contains all the information needed to make the m-payment and can be considered as a regular m-account in all subsequent modules. The debit account is thus read / selected from the DAC register in the debit account selection module, and the display, confirmation and signature of the payment is performed in the module for preparing and digitally signing the payment order according to the procedure already described.

When the module for preparing and digitally signing a payment order in the preparation and signing unit of the m-payment (III) prepares an m-payment, it transmits it to the module for sending m-payments, which it transmits to the module for receiving m-payments via the public mobile telecommunication network PLMN in the M-Payment Receiving and Distribution Unit (IV) (Step 2).

The m-payment acceptance module in the m-payment (IV) receiving and distribution unit, after successful acceptance, submits the m-payment to the m-payment authentication module.

The m-payment authentication module, based on the identification data of the sender of the m-invoice, that is, the serial number of the SIM card or mobile phone number of the CDR directory, looks for the corresponding digital certificate of each unit for preparation and signature of m-payments (lil) and authenticates the certificate, verifying the validity of the certificate as well as the status of the certificate in the canceled digital certificate list

CRLs published by the system's digital certificate issuer or independent external certification authority (CA).

After verifying the listed security elements and consequently ensuring the authentication of the m-payment, the module for checking the integrity and non-repudiation of the m-payment takes over. The module checks the digital signature of the m-payment, which ultimately ensures that the m-payment came from an authentic source, that the data can only be entered by the owner of the private key in the unit for preparation and signature of the m-payment (III) and that m - No one changed the payment on the way.

The M-payment, for which authenticity, integrity and 20 fail-safe have been verified, is stored in the MPA's m-payments database in the M-Payment (IV) receiving and distribution unit. If necessary (regulator or legal requirement), these m-payments can also be archived in an audit-safe manner over the long term. In this case, the authenticity and integrity of the archived m-invoices is additionally ensured by time stamping technology and audit trail tracking and access control to the archive.

The verified m-payment is finally handed over to the module for sending m-payments to the payment execution and settlement unit (V) at the receiving and distributing unit of m-payments (IV). First, this module identifies the payment service provider with the debit account and the registry of payment service providers npr (eg banks that support the payment method mentioned) with which the debit account is opened and transmits the m-account to the unit via the fixed communication network NET. execution and settlement of m-payments (V) (step 2a).

The m-payment acceptance module in the m-payment execution and settlement unit w (V) accepts and verifies the m-payment data. The module can once again verify the authenticity and integrity of the m-payment, or trust the m-payment (IV) receiving and distribution unit when this system is installed with a trusted partner or payment service provider. Upon successful acceptance, it sends the m-payment to the signatory verification module.

The Signatory Authorization Verification Module in the M-Payment Execution and Settlement Unit (V) verifies that the M-Payment Signatory has the appropriate authority to manage the funds in the debit account specified in the M-Payment. User search is performed on the basis of the information in the digital certificate of the signatory or the certificate itself in the register of customers (customers) of MPC using the mobile payment system. After successful authorization verification, the module submits an m-payment to the module to execute the payment.

The Payment Execution Module in the M-Payment Execution and Settlement Unit (V) checks the general business conditions required to make a payment (such as the balance of funds in the account) and sends the m-payment for actual execution and settlement. Once the payment is made, the funds from the debit account are transferred to the approval account through established financial channels (eg interbank clearing system), and feedback on the status of the specific m-payment (executed, declined, error) is sent to the unit for payment by acceptance and distribution of m-payments (IV) (step 3). This feedback is transmitted over the public fixed telecommunications network NET and contains all the information necessary to determine the final status of a particular m-payment and the associated m-bill.

Feedback on the status of m-payments is received by the module for receiving and further forwarding the status of payment execution in the unit for receiving and distributing m-payments (IV). The module indicates the status of the specific m-payment in the MPA's m-payments database, and if necessary, this status can also be archived securely. This same module may be responsible for forwarding the payment status information back to the m-payment processing unit (lil) (step 3a) and to the m-invoice receiving and distribution unit (II) (step

3bi in Fig. 2).

If the status forwarding is implemented and used for a specific m-payment, the module for assuming the status of payment execution in the unit for

2o the preparation of m-payments (lil) checks the authenticity of the m-payment status and shows the user feedback on the payment (executed, declined, error) on the screen of the mobile terminal. The status is stored on the mobile terminal in the form of a short message so that the user can store it for their own record of m-payments.

The m-payment status is a data that directly determines the final status of an individual m-account. Therefore, the module for receiving and distributing the invoices (II) may also implement a module for accepting and further transmitting payment status. This module verifies the authenticity and integrity of the m-payment status, indicates the status of the associated m-account in the MBA m-accounts database (this status can also be safely archived), and passes the m-account status to the issuer of the m-account (step

3b).

Interactive m-invoice issuers receive m-invoice status and 10 m-related payments in response to the m-invoice sent from the m-invoice receiving and distribution unit (II). However, m-invoicing units operating in automatic mode can, at the same time, take on several m-invoice statuses previously sent to the m-invoice receiving and distribution unit (II). The m-invoicing units (Ib) realized with modified mobile terminals may also use the information from the status of the account to print a material payment receipt that is submitted to the customer for record keeping and proof of payment made.

When the m-payment (III) preparation and signature unit does not make and dispatch an m-payment at the time of receipt of the m-invoice, the m-invoices

2o are stored in the unit for receiving and distributing m-invoices (II), where they wait for the request of the unit for preparing and signing m-payments (III). At the request of the payer, the unit for preparing and signing the m-payments (lil) may send to the unit for receiving and distributing m-invoices (II) via the PLMN public mobile telecommunication network a request for re-sending of pending m-invoices (step R). These m-invoices are then forwarded to the receiving and distribution unit of the m-invoices (II) in the same manner as to the unit for preparing and signing the m-invoices (III) as at the first sending of the m-invoices (step 1a).

Claims (10)

1. The procedure for secure and easy payment by mobile phone, 5, characterized in that the relations between the entities are carried out in the following order: the payment is initiated by the seller by sending (directly or indirectly) the payment elements to the buyer's mobile terminal (step 1), where these payment elements are part of or an extract of the original invoice and are in io, hereinafter referred to as "m-account"; a pre-prepared m-invoice can issue and thus initiate payment also by the buyer or the user of the mobile phone himself (step 1 in this case is performed in the mobile terminal) when he wants to transfer funds from his account with and to the payment provider by means of an appropriate function at the mobile terminal. service (e.g., a bank) to another account that is either intended to pay for certain services and / or products (such as a prepaid user account to pay for mobile carrier services) or for a particular payment method (such as an NFC - Near Field payment account Communication); 20 the buyer at the mobile terminal confirms that he wants to pay the bill, determines the account from which he wants to pay the payment, and by entering a password to access his private key, he initiates the process of digitally signing the payment order on the SIM card, which is labeled »m -payment "; after the signing is completed, the m-payment is sent (step 2) to the payment service provider (eg bank) with which the customer has an debit account; when the payment is made with the provider, the customer's payment service provider 5 sends a payment notification to the buyer at the mobile terminal (step 3a) and to the seller at the system where the payment is initiated (step 3b); payment between the payment service providers of the buyer and the seller is settled according to the applicable settlement rules in the financial space (eg interbank clearing systems) (step 4); io the seller receives a paper / electronic inflow notification from his bank (step 5); 2. Mobile and secure payment system according to the procedure of claim 1, characterized in that it comprises m-invoicing units (la and / or Ib), a m-invoice receiving and distribution unit (II ), the payment preparation and signature unit (lil), the m-payment reception and distribution unit (IV), and the m-payment execution and settlement unit (V), the stationary units being the 20 invoicing (la) with the units for receiving and distributing m-invoices (II) are connected via a fixed telecommunication network (eg local area network, VPN, Internet), and mobile units for issuing m-invoices (Ib) with the receiving unit and the distribution of m-invoices (II) are connected via a mobile telecommunications network (PLMN) such that the unit for 25 receiving and distributing m-invoices (II) mediator between m-invoicing units (la and / or Ib) and the m-payment preparation and signature unit (lil); that the unit for preparing and signing m-payments (lil) via the mobile telecommunications network is connected to the unit for receiving and distributing m-invoices (II) and to the unit for receiving and distributing m-payments (IV); that the unit for receiving and distributing m-payments (IV) via a mobile network is connected to a unit for preparing and signing m-payments (III) and through a fixed telecommunications network to a unit for executing and settling payments (V), each unit for execution and settlement of m-payments (V) connects the unit for reception and distribution of m-payments (IV) with the existing complex systems of reception, execution and settlement of electronic payment orders with payment service providers (eg banks). 3. The mobile and secure payment system according to claim 2, characterized in that the m-invoicing unit (la and / or Ib) has an account extraction module, a customer terminal mobile number definition module, a module for digitally signing an m-invoice (if such is a regulation or if it is such a practice, or if this is a way of identifying the seller in the unit for receiving and distributing m-invoices (II)) and two modules (the module for submitting the m-invoice and the module for receiving feedback on payment status linked to a particular m-account) to exchange information with the unit for receiving and distributing m-invoices (II); that in certain embodiments, the unit contains a customer register. Mobile and secure payment system according to claim 2, characterized in that the unit for receiving and distributing m-invoices (II) comprises a module for receiving m-invoices, a module for identifying the sender of the m-invoice, a module for checking the integrity of the m-invoice, module for sending the m-invoice to the customer's mobile terminal, module for accepting and further forwarding the status of payments related to the m-invoices sent, the register of io vendors and their identification elements and the database of issued invoices and statuses payments linked to issued m-invoices; that the unit has access to local or external registers of valid and revoked digital certificates; that the unit usually contains an additional module which, in conjunction with the unit for preparation and signature of m-payments (lil), enables the payment of those m-bills that are still valid (have not yet expired) and which were not paid as soon as the customer has received a notification to their mobile terminal .. 5. System for safe and easy payment by mobile phone, after 20 of claim 2, characterized in that the unit for preparing and signing the m-payments (lil) is a module for receiving bills, a module for selecting a debit account, if multiple accounts are possible, a module for preparing and digitally signing a payment order, a module 25 for sending m-payments and a module for assuming payment execution status and a register of possible debit accounts, if the implementation is such that the debit account is not part of the m-account; that the unit usually contains an additional module which, in conjunction with the receipt and distribution unit (II), allows the postpayment of those m-invoices that have not been paid 5 as soon as the customer has received a notification to their mobile terminal; that special unit versions also contain a module for the payment of prepaid services and an associated register of prepaid services (eg for filling a prepaid account for mobile telephony); that if the unit has an invoice recharge service used by the customer for 10 payment by NFC technology, the unit contains, in addition to the NFC account replenishment module, a module for actually updating the balance of funds in an NFC account in a mobile terminal when the amount of available funds is also stored there; that the unit may also include infrastructure modules (module for receiving and extending the digital certificate, module for maintaining the register of possible load accounts, and module for maintaining and adding new pre-prepared services), which allow the unit to be remotely maintained. Mobile and secure payment system according to claim 2, characterized in that the unit for receiving and distributing m-payments (IV) has a module for receiving m-payments, a module for verifying the authenticity of m-payments (customer) ), m-payment integrity verification module (based on digital signature), module 25 for sending m-payments to the unit for execution and settlement of payments, module for accepting and further forwarding the status of payment execution, register of payment service providers and a database of received m-payments and associated status of payment execution; that the unit has access to local or external registers of valid and revoked digital certificates. 7. Mobile and secure payment system according to claim 2, characterized in that the unit for execution and settlement of m-payments (V) contains at least an io module for receiving m-payments, a module for verifying the authority of the signatory on a defined account debits, payment execution module and register of customers (customers), their digital certificates and their authorizations. 8. Mobile and secure payment system according to claim 2, characterized in that the m-invoice receiving and distribution unit (II) described in claim 4 and the receiving and distribution unit m - payments (IV) described in claim 6, functionally and / or organizationally combined into one 20 unit. 9. Mobile and secure payment system according to claim 2, characterized in that the m-invoicing units (1a and / or Ib) described in claim 2 and the receiving and distribution unit m - the accounts (II) described in claim 4, functionally and / or organizationally combined into one unit. 10. Mobile and secure payment system according to claim 2, characterized in that the m-payment (IV) receiving and distribution unit described in claim 6 and the execution and settlement unit can be m -the payments (V) described in claim 7 are functionally and / or organizationally combined into one unit.