EA018591B1 - The method of payment transactions performance by user of electronic communication mobile devices and computer based system for noncash transfers therefor - Google Patents

Abstract

The invention relates to information technologies, in particular to systems of noncash transfers to improve protected payment transaction by user(s) of electronic communication mobile devices. In such method it is necessary to register private number of user's mobile device - MSISDN Client, and in the presence and with a participation of user to form (individual) protected space of user's payments including, at least, one number of an account, at least, from one payment recipient. Payment transactions (payments) should be made upon receiving of payment instructions from registered private number of user's mobile telephone - MSISDN Client. CBR system can involve several financial operators, but CBR system by itself can own some gateways with several OMCC operators. To perform payment transactions by user of electronic communication mobile devices in CBR system, the number of server for payments authorization is equal to the number of financial operations connected to the system, wherein each server for payments authorization should be connected to one financial operator, where each server of payment authorization includes personal user management block. The system additionally includes central routing server connecting user interface server with payment authorization servers, where central routing server is executed making it possible to control information exchange between user interface server and payment authorization servers. The technical result is aimed at improving the reliability and safety of payment transactions providing with a simple, comfortable and understandable interface for users simultaneously.

Description

The present invention relates to the field of information technology, in particular to cashless payment systems for secure payment transactions by the user (s) of mobile communication devices.

State of the art

The rapid growth of information technology in the second half of the 20th century contributed to the emergence of a variety of computer systems using wired and wireless communication systems, on the basis of which, among other things, cashless payment systems were implemented. Recently, the development of cashless payment systems focused on the use of electronic communication devices such as mobile phones or handheld computers (Ret§opa1 Ωίβίΐαΐ ΛδδίδΙαηΙ or ΡΌΑ) as user terminals has begun.

One of the technical solutions in this area describes the methods of offering for sale, placing orders and selling goods and services using an offer server associated with computer terminals of sellers of goods or services (patent of the Russian Federation No. 2191482, IPC Н04М 3/50, Н04О 7/22 O06B 17/60, publ. 2002.10.20). According to this document, the seller or the offer server forms the identification of offers for the sale of goods or services, which is a combination of alphanumeric characters, that is, a conditional index that carries information about the seller, the offered product, as well as possible other information. Such indexes are distributed among users of mobile electronic communications devices. A user who decides to use the offer, enters the appropriate index on his mobile electronic communications device and, on its basis, transmits a request to order or purchase the corresponding product or service to the offer server. If the specified product is available, a special marker is sent to the user's mobile electronic communication device confirming the order process. This marker, which corresponds to a specific sample of the product, is stored in the memory of a mobile electronic communication device so that it can subsequently be presented, for example, as proof of payment for receiving the corresponding product or as an entrance ticket to some event. The use of markers according to this patent allows you to streamline the process of placing orders by creating a mechanism to control the availability of a particular type of goods or services. However, this patent does not provide technical means that would insure the user against fraud or errors in entering the offer index. In particular, when entering the offer index on a mobile electronic communication device, the user is forced to act blindly, since from the side of the cashless payment system (or offer server) he does not receive information about what exactly and to whom he pays, because the offer index is a code , clear only to the offer server. As a result, a situation may arise when the user receives incorrect information about the offer index or simply makes an input error, and the incorrectly entered index may correspond to another offer. In both cases, in the well-known system, the order will be placed and the sale completed, and the user, initiating the payment, is not able to verify whether the goods that he wants to buy, the seller from whom he wants to buy these goods, and the amount that he is ready to pay. Moreover, a token received from the server of the system and displayed on the screen of a mobile electronic communication device cannot be considered as legally valid proof of payment, which can be especially important in disputed situations.

A known method of electronic payment using a mobile terminal (RF patent No. 2273049, C06O 30/00, publ. 2001.07.26). In accordance with the invention provides for the implementation of electronic payment transactions using a mobile terminal, such as, for example, a mobile phone. In this case, first, a request for payment is sent from the mobile terminal to the payment center. At the same time or after sending the request for payment from the mobile terminal to the payment center, the payment conditions are sent. Terms of payment may include, for example, the payee, the number of the credit card used, the amount of the payment, etc. Each payment procedure is assigned an individual transaction code or permission code characterizing it, which is sent to the mobile terminal and / or to the payment destination.

A known method of carrying out non-cash payments using the transmission of information using wireless communications (RF patent No. 2246757, O06E 17/60, publ. 2003.06.19). In the proposed method, the client opens a current account, selects the necessary goods and / or services, an order is formed in the seller’s block. When the customer confirms the payment, they reserve the selected goods and / or services and transfer the order information to the processing center, where they register the order, assign it the order identifier included in the order information and transfer it to the seller’s block. The client connects via mobile phone to the processing center, where the client's phone is identified. Then the client enters his ρίη-code in this system for personification, after a positive result of which the client passes the order identifier, upon receipt of which within a specified time the processing center identifies the order identifier, checks the client’s solvency, transfers the necessary amount to the settlement account of the trade institution.

- 1 018591

A known method of making payment transactions by users of mobile electronic communication devices and a computer system of cashless payments for its implementation (RF patent No. 2263347, IPC C06E 17/60, publ. 2005.10.27). According to the method, the conditions of the type of payment and the condition for the amount of payment are generated and stored in the server, each type of payment is assigned a unique index, which is entered via a mobile electronic communication device before making the payment, and in accordance with the entered index, a payment request is sent to the system server before by initiating a payment in response to a specified request, the conditions of the specified type of payment are transmitted from the system server to the mobile electronic communications device with these conditions displayed on the screen m of a plentiful electronic communication device, after which a confirmed payment order is sent to the server from the mobile electronic communication device, after receipt, the payment is initiated by contacting the server of the corresponding payment organization. The system comprises a unit for working with payees, a terminal for a payee, a unit for working with users, a unit for working with payment operations, a unit for generating and comparing pseudo-random codes for payment transactions, a storage device.

The development of computer technology has also led to a huge increase in the number of cybercrimes. It is impossible to ignore this threat today - it is believed that back in 2004, cybercrime earned $ 105 billion (more than the entire drug business). Statistics show that the number of cybercrimes doubles every year. Almost all computer systems of cashless payments become targets of attacks by computer attackers (hackers). Moreover, according to statistics, about 80% of cases of hacking of computer systems are accounted for by insiders. Therefore, a promising system of cashless payments should have a significantly higher level of security.

It is believed that every fifth transaction remains vulnerable to scammers. Even the use of one-time ZMZ passwords sent to the client’s mobile phone does not give the desired result, since customers rarely pay attention to changing the bank account specified in the ZMZ (for more details: 1 Shr: //yiete.sot.ia/3 5894.1It1) .

Information security experts believe that it is impossible to significantly increase the security of financial transactions without hardware keys, but the use of special hardware keys and additional programs installed on mobile communication devices (the so-called 12Medlets) is not supported by users, reduces the potential customer audience, requires additional costs, creates additional administrative and technical difficulties in the implementation and distribution of the system.

A survey conducted by the English bank ABLeu among 1000 of its customers showed that only 1 out of 3 clients (32%) wants to use special devices that could provide increased security for more transactions (for more details: L1p: //www.go/aFs1e. а8р? у1ете = 15795).

There is a paradox - the efforts of commercial banks, which seek to make their transactions safer, do not find support among bank customers who do not want (at their own expense) to purchase and use special hardware keys, without which it is impossible to significantly increase transaction security.

Therefore, the majority of modern technical solutions designed to make mobile financial transactions safer (81M-Baiksd, 1aaa-Baiksd, technology ΝΡΟ - Geag Ieb Sottisayoik) remain uncommon, and the 8M8-Baiksd implemented on the basis of 8M8 technology remains the most widespread type for mobile banking. , which is the basic service of the standard C8M. In turn, the C8M standard is the most widespread and popular standard for digital mobile cellular communications.

In 2008, the share of С8М in the global cellular communications market was estimated at 85% (for more details: Y1Р: //^^^.ТЬ^1еάеν^се.^и/С8М-υМΤ8-Iηίо^та-Τе1есот8-Меά^-аηа1у8е -Η8 ^ ΡА-Η8υΡА-8ίаί ^ 8ί ^ ка-ά.а8рx).

In accordance with the S8M standard, all S8M terminals (mobile phones) support the 8M8 service. Therefore, to create a mass and affordable service, it is desirable that the developed method and system of a cashless payment system be implemented on the basis of standard technologies of the S8M standard - 8M8 and IZZI.

To implement mobile banking on the basis of ZMZ technology, a financial operator (FO) must be connected to at least one gateway of at least one mobile cellular operator (OMSC). The exchange of information between users of mobile electronic communication devices and FD is carried out through the network and gateway (s) of the OMSS.

The main drawbacks of the current ZMZ banking implementations are the low level of information security (information is transmitted in unencrypted form, therefore it can be intercepted using radio equipment and / or read by insiders on the side of the mobile cellular operator) and the complexity of the commands and interface using which payments are made.

It is believed that it is the complexity of the teams used that limits the popularity and growth of this type of service. Consider this problem on the example of the ZMZ-banking system, which offers

- 2 018591 Belarusian BPS Bank to its customers (for more details: yyr: //tetete.b8b.yu/bapk/gi.sagb8.abb.8 SH8baik1id.yt1.).

To make payments, users are offered to use the following command format: ORELTL <password> <amount> <payment code> <individual payment data>.

Moreover, the reference code of payments only in Minsk contains 32 payees. Here are examples of commands and their meaning:

op1a1a] k3 ^ b 10,000 b 7770000 Payment of MT5 company for a phone number 7770000. The payment amount is 10000 VUK. op1a1a] short circuit; De 10000 νείεοιη 6000190 Payment by UESOM for the phone number 6000190. The payment amount is 10,000 VUK. op1a1a (k3 ^ b 85380 gklsh 70000000116 Payment for the rent to the CUP Center company to the personal account No. 70000000116. The payment amount is 85380 VUK.

Obviously, without instructions and a memo with personal account numbers, it is extremely difficult and inconvenient to make such payments. Making them fast and on the go is almost impossible.

Therefore, the most popular service in 8M8 banking today is the so-called 8M8 notification, when the user receives more than one notification of changes in his accounts in the form of 8Sh8 messages.

The company 1pGogta Te1esotz & Meb1a 03.03.2009 published a report in which it predicts a 12-fold increase in the mobile payments market in the next 5 years (more: Ir: //shoeieuieta.ts./ts/node/11476/). Obviously, new methods and systems for protecting mobile payments will be required that can provide users with the necessary level of security.

The popularity of mobile payments is associated with a high level of penetration of mobile cellular communications (approximately 45-95% in the CIS countries) and the convenience of their use - a mobile phone is always at hand. There are a significant number of domestic and foreign non-cash payment systems using mobile electronic communications devices.

As the closest analogue of the proposed technical solution, the Method of making payment transactions by users of mobile electronic communication devices and a computer-based cashless payment system for its implementation was selected (patent of the Russian Federation No. 2263347, IPC O06P 17/60, publ. 2005.10.27). The present invention describes a method and system for making payment transactions by users of mobile electronic communication devices. According to the known method, the conditions of the type of payment and the condition for the amount of payment are generated and stored in the system server, and each type of payment is assigned a unique index, which is entered through the mobile electronic communication device before making the payment and, in accordance with the entered index, send a request to the system server making a payment. In response to the specified request, the (previously saved) conditions of the specified type of payment are transmitted from the system server to the mobile electronic communication device with the display of these conditions on the screen of the mobile electronic communication device, after which the confirmed payment order is transferred from the mobile device to the server, and upon receipt, the payment is initiated access to the server of the relevant payment organization. The system comprises a unit for working with payees, terminals for payees, a unit for working with users, a unit for working with payment operations, a unit for generating and comparing pseudo-random codes for payment transactions, and a storage device. To ensure greater security of payment transactions in the closest analogue, it is proposed, after receiving a request, to generate and send from the server of the system to the terminal of the payee a pseudo-random code of the payment transaction that is transmitted directly to the user. The user enters and transmits (returns) the received code via the mobile electronic communication device back to the system server, in which the value of the payment transaction code received from the user and the value of the payment transaction code transmitted to the terminal of the payee are compared. If the specified values match, the system initiates the payment by contacting the server of the corresponding payment organization through the system’s server. It is proposed to additionally use a personal identification number (ΡΙΝ-code) or a one-time authentication code that can be transferred to the system using the 12ME application installed on the mobile device (the so-called Ш1б1е1 - midlet) or using the ^ LR protocol.

The disadvantage of the closest analogue is the lack of security of the basic configuration of the method and system from unauthorized use. Attackers can steal a mobile electronic communication device and make a payment using it if its owner does not notice the loss in time and does not block the use of the mobile device. Such a scenario is also possible even in the case of a short-term loss of control over a mobile electronic communications device. And for greater security, a software modification of the mobile mouth is required.

- 3 018591 electronic communication facilities - installation of 12ME midlet, which complicates the use of the analogue by unprepared users and narrows the audience of potential users of the system.

From the description of the closest analogue, it also follows that the analogue is more focused on organizing payments in retail (presence of payment recipients in the system of terminals) and on payments with a fixed amount of payment (condition on the amount of payment or the range of acceptable values).

The limitations and disadvantages of the known method and system described above can be removed and eliminated by various embodiments of the invention.

The present invention is the development of a more secure method and system of cashless payments, focused on making regular payments for utilities, as well as for making money transfers with an arbitrary amount of payment that do not require software and / or hardware modification of a mobile electronic communication device to ensure the necessary security.

To ensure greater security and ease of making payments, the possible actions of the attackers were analyzed. As a rule, using insiders, radio equipment, and computer tools, attackers first gain access to users ’personal data (settlement account number, c-mail, mobile phone number, password, and код code), and then acting on behalf of users and using them ΡΙΝ -codes and passwords, transfer funds from the customer’s current account to the transit account, which is under their control.

Thus, the ultimate goal of the attackers is precisely the withdrawal (transfer) of funds from the user's current account to a transit account controlled by them. If such a transfer is not possible, any actions of fraudsters will not give the result they need.

The problem of the present invention is solved due to the fact that when the method is implemented in the cashless payment system (RBU), the personal mobile number of the user Μ8Ι8ΌΝ C11ei1 is registered, in the presence and with the participation of the user, they form a (individual) secure user payment space (STD), including at least one account number with at least one payee. Payment operations (payments) are made upon receipt of payment instructions from the registered personal mobile number of the user Μ8Ι8ΌΝ С11ei1. In addition, the details of the user’s current account opened with a financial operator (FS) are recorded in the cashless payment system. When registering a personal mobile number of the user Μ8Ι8ΌΝ in the specified system, the user additionally reports an RGY2 code, with which he confirms the payment instructions sent from the personal number of the mobile phone Μ8Ι8ΌΝ С11ei1. In the RBU system, each authorized payee (ANN) is assigned a unique code (CC), with which an authorized payee is identified and used as a short number to receive payment instructions from a user using at least one operator υδδΌ and / or 8М8 services mobile cellular. To make money transfers to users of the system, they use the mobile phone numbers of the users to whom the payments are intended. Additionally, during registration, the user provides at least one backup mobile phone number for managing a current account and receiving emergency notifications.

Several financial operators can be connected to the SBR system, and the SBR system itself can have gateways with several OMSS operators.

Coordination of work with financial operators, mobile cellular operators (OMCC) and authorized payees (ANN) is performed by the (only) system operator (OS).

In the SBR system, for the user to make payment transactions with mobile electronic communication devices, the number of payment authorization servers (SAP) is equal to the number of financial operators (FOs) connected to the system, and each SAP server is connected to one server of the financial operator (SFD), and each SAN server corresponds to its own block of work with users (PDU). In addition, a central routing server (CMS) has been introduced into the system, connecting the user interface server (CPS) with SAP servers, while the CMS server is configured to control the exchange of information between the CPS server and CAP servers.

The technical result is to increase the reliability and security of payment transactions while providing a simple and convenient, user-friendly interface.

The implementation of the proposed method of payment transactions by the user of mobile electronic communication devices through the RRF system is illustrated by the accompanying drawings, where in FIG. 1 shows a block diagram of an algorithm corresponding to the proposed method;

in FIG. 2 - a structural diagram of a computer system of the RRF in the basic version - with the connection of a single FD;

in FIG. 3 is a structural diagram of a computer system of the SBR in another embodiment, with the connection of several financial operators, each of which has its own SAP server;

in FIG. 4 is a block diagram of a SAP server.

- 4 018591

The following examples of the description of the proposed method of payment transactions and a computer system of cashless payments with reference to the accompanying drawings only illustrate, but do not limit, many aspects of the invention set forth in the claims.

Let us consider in more detail presented in FIG. 1 is a block diagram of an algorithm corresponding to the proposed method. To implement the method, the user of a mobile electronic communications device must simultaneously be a client of a financial operator (have an active current account from which payments will be covered) and an OMSC subscriber. A financial operator may be a commercial bank, microcredit organization, payment organization, processing center or other financial organization licensed to provide settlement and cash services to the population. The operator of the public limited liability can also act as the operator of the public financial service if he supports the provision of financial services to his subscribers and covers payments from personal accounts of subscribers in the billing system, and his activity does not contradict (local) legislation.

The personal mobile number of the user !,δΙδΌΝ Syeyi !, obtained by him when concluding a contract with the OMSC, is used as the main identifier for remote authentication of the user, and the δΙΜ card received by the user from the operator OMSS, with which the received mobile number of the ΜδΙδΌΝ Syey !, is uniquely associated It is used as a personal user dongle protected by personal ΡΙΝ and RIC codes, without which it is impossible to enter the operator’s network OMSS.

All further payment operations (payments) will be made only upon receipt of payment instructions (orders) from the registered personal mobile number of the user ΜδΙδΌΝ Syeya! and provided that they are confirmed by the correct P1I2 code registered in the RRF system.

At the beginning of the process (block (1)), the user is checked for the availability of a personal mobile phone number Μ8Ι8ΌΝ Syey! (see block (2)). If there is no number, then the user is registered with the OMCC operator, as a result of which the user receives a personal mobile number СС8Ι8ΌΝ Syeya from the OMCC operator! and δΙΜ-map (see block (3)). Then, it is checked whether the user has a current account opened with one of the financial operators connected to the system (see block (4)). If there is no current account, it is opened (registered) with one of the FI operators connected to the SBR system (see block (5)). Only after this is the user registered in the SBR-block system (6). When registering in the SBR system, the user reports his passport data (name, surname, identity number or passport). Within the framework of the SBR system, one number is ΜδΙδΌΝ Syeya! can be used by only one user and to manage only one account.

Immediately after registration in the SBR system, the user forms his personal space Z1IP1 (see block (7). In this case, the system operator creates and maintains a single Register of authorized payees (RANN), in favor of which payments are allowed under this SBR system. And to each authorized the payee (ANN) is assigned a unique code (CC) within the framework of this system.The RAPP registry and codes of authorized payees are provided by the system operator to users in hard copy (instructions, brochures, memos) and through Get it !. It should be noted that each specific user can select from the general Register (RAPP) and allow payment only to those recipients of payments (APP) whom he himself will choose in the process of forming his STD space. The STD space should be formed at the time of user registration in SBR system - in his presence and with his participation, and any remote modification of records recorded during registration should be prohibited. Moreover, all subsequent payments should be made only within the framework of the user-approved STD space. All other payment instructions sent even from the correct ΜδΙδΌΝ Syeya number! will be ignored - an error message will be sent to the user, and the security services of the OS and the corresponding FD will receive notifications from the SBR system.

The created STD space must be printed (at least) in 2 copies, with each copy being signed by the user and an authorized representative of the financial operator. One copy remains with the user, and the second with the financial operator. As a result, each side receives a certified copy of the current version of the STD space. The created STD space can also be authenticated by the FI and the user in electronic form - if there is a law on electronic signature. In this case, the document must be signed with digital signatures and / or certified by digital certificates issued by an authorized certification authority (CA). Based on existing legal practice, the availability of this document will more clearly determine the responsibility of the parties - the user will be able to challenge any payment made by a financial operator outside the approved Z1PP1 space. This increases the real legal liability of the FI to the user for unauthorized payments, protects the rights of the user and at the same time makes the service more understandable and safe for users.

- 5 018591

Using block (9), a financial operator can interrupt or stop the process of providing a service to a user (is the Service allowed FD criterion?).

If the service is enabled, then the user enters payment instructions and / or commands in block (10). If the user himself wants to stop the process of receiving the service and enters the appropriate command, then such a check is performed in block (11) (criterion Refusal of the service?). In block (12), the received payment instructions are checked for compliance with the current version of the ZINI space of this user. If the received instructions do not correspond to the STD space, then in block (13) the user and security services are notified of an attempt to make an incorrect payment. If the payment instruction corresponds to the STD space, then in block (14) the availability of funds is checked in the registered current account of the user (is the criterion of funds sufficient?). If there are enough funds, then in block (15) a payment is made in accordance with the data of the verified payment instruction. In block (16), the user is notified of the payment results or the reasons for the refusal of payment.

If the user wants to upgrade the STD space, then this check is performed in block (17) (criterion Change STD?). If the space Z1PP1 is not modernized, then the transition to the block (9) is made - at the beginning of the service cycle. If the user upgrades the STD space, then the transition to block (7) is made, where the STD space is modernized, and then reapproved in block (8). As a result, both the financial operator and the user have certified copies of all versions of the STD space - with the dates of their formation and approval.

Both the user and the financial operator can at any time interrupt the cycle as they wish - see blocks (9) and 11), thereby moving to block (18) - End - Exit the algorithm.

Since the SBR system, in which the formation of the STD space will take place, will be isolated from the automated banking system (ABS), this will isolate the data on the STD space from most employees of the Federal District (commercial bank) and personalize the responsibility of administrators and operators serving the SBR system.

To protect the ZP1P1 space from possible insider actions, financial operators and the system operator must log the actions of operators and administrators with access to the RRF system and its components. The work of the OS and FD operators should be strictly personalized, and the change in critical parameters should be distributed among several system roles.

Any attempt to fake ZMZ and / or IZZI messages (on behalf of the user and from the number Μ8Ι8ΌΝ C11sp1) by malefactors (insiders) from among the technical personnel of the OMSS operator who have access to IZBS and / or 8M8C centers is meaningless, since the formed space of the STD is under the control of the FI, and the actions of the employees of the FS who have access to the RRF system are strictly personalized and monitored (logged). Such fake ZMZs will be blocked by the SAP server system, and a message will be sent to users about an attempt of unauthorized payment from their mobile phone number. Similar messages will be received by the security services of the FD and the system operators. Analysis of archival records and actions of employees of the Federal District, the system operator and the operator OMSS will quickly determine the circle of suspects and find the attackers.

The second object of the invention is a computer system of cashless payments (SBR) for making payment transactions and money transfers by users of mobile electronic communication devices, including a central routing server containing a central database (CBD), user interface server (s) (IZBS, ZMZS, 12ME, No. AR, etc.), SAP server (s) associated with mobile electronic communication devices and the server of at least one financial operator.

The difference between the proposed computer system of cashless payments for making payment transactions from the closest analogue of the invention lies in the fact that the computer system has a distributed architecture. So, an SAP server containing a PDU block, a block for working with payees (BPP), a block for working with payment transactions (BPO), a block for generating authentication codes (BGKA), a block for generating and comparing payment transaction codes (BGSCPO), as well as a memory a device (memory) can have several implementations (copies or copies (1p§! apse) - according to the number of FIs connected to the system. Each of the financial operators has its own payment authorization server, and therefore its own registry of users and their personal data, which are stored and are processed in the block of work with users.

The SBR system can be implemented in various configurations.

In FIG. Figure 2 shows the system configuration (SBR), where a single payment authorization server 19 is connected to a single operator server 20. The SAP server communicates with users' (MT) 23 mobile phones through the network and gateway (s) of the OMCC 22 operator via at least one user interface server 21. In this case, the proposed SBR system can be used by the corresponding FD to organize its own payment processing center, and the financial operator itself will act as the system operator. In this case, there is no need

- 6 018591 a bridge in the central routing server.

In FIG. Figure 3 shows the structural diagram of the SBR computer system in another embodiment, which differs from the one discussed above in that instead of one financial operator, several financial operators (ФО1, ФО2, ..., ФОК) are connected to the system, each of which has its own SAP payment authorization server (19, 19.1, ..., 19.p), which are associated with the corresponding (paired) servers of financial operators (20, 20.1, ..., 20.p), and to control the exchange of information between SAP servers (19, 19.1, ..., 19.p) and the user interface server SPI 21 add The central routing server of CMS 24 was introduced. The interaction between mobile phones (MT) 23 and SAP servers (19, 19.1, ..., 19. p) provides the user interface server SPI 21, which acts as a gateway.

In contrast to the previous configuration with a single FD, when registering a new user in the SBR system, each of the financial operators (FO1, FO2, ..., ΦΟΝ), in addition to registering the user on its SAP server, additionally registers the user's mobile phone number ΜδΙδΌΝ SNep1 under its code - the code of the financial operator (CFD).

In turn, SPI 21 is connected to MT 23 through the network of the OMSS 22 operator. For implementing various user interfaces using different technologies (BMB, IBBB, 12ΜΕ, \ ULR, etc.), more than one SPI 21 server can be used.

The arrows indicate the communication channels between the components and the preferred direction of information flows. The main elements of the SBR computer system are SAP servers (19, 19.1, ..., 19.p), FD servers (20, 20.1, ..., 20.p) (in particular, a commercial bank server), the TsSM 24 server, server (gateway) SPI 21, a mobile electronic communications device (MUES), in particular a mobile phone (MT) 23.

Payment orders sent by a user via a mobile phone (MT) 23 through the network and the operator’s gateway (OMCC) 22 are initially sent to SPI 21, and from it to the FMC 24.

FMC 24 of the RRF system contains a central database (CBD) (eng. Vooypd Иа1а Ваке, КИВ), in which, by the mobile phone number of the user ΜБИБ ^ N СНеп1, the CMC searches for the code of a financial operator (CFO) that registered this user in the system, and then forwards the received payment order to the SAP server of the corresponding FD. Further verification and execution of the request is carried out by the SAP server of a specific financial operator.

The SAP server (one of 19, 19.1, ..., 19.p) by the mobile phone number (MT) ΜБИБ ^ N SIep1 searches for the corresponding STD space. If the payment order received from the user corresponds to his STD space, then the SAP server sends it for execution to the server of the financial operator FD (one of 20, 20.1, ..., 20.p). Otherwise, the SAP server blocks an incorrect payment order and informs the user about this by sending an BMB message, as well as the OS and FD security services, about an incorrect payment attempt.

For example, if the user was registered with FO No. 2, then the payment order will be first forwarded to the SAP server 19.1, and after checking for compliance with the STD space, to the server of the financial operator No. 2 (server 20.1).

In FIG. Figure 4 shows the block diagram of the SAP server (19, 19.1, ..., 19.p), which are the main element of the proposed cashless payment system and in which the STD space is formed. Each SAP server contains a block for working with users (PDU) 25, a block for working with payees (BIP) 26, which is connected to the terminal of the payee (CCI) 31, a block for working with payment transactions (BRPO) 27, a block for generating and comparing payment codes operations (BGSCPO) 28, the authentication code generation unit (BGCA) 29, as well as a storage device (memory) 30. Each SAP server (one of 19, 19.1, ..., 19.p) contains its own register of users, their personal data and STD spaces that are stored and processed in the user work block mi (PDU) 25.

Example 1. Consider the implementation of the proposed method using a system for a user who uses a mobile electronic communication device connected to the network of a mobile cellular operator (OMCC) standard OBM in the Republic of Kazakhstan.

Suppose that a system operator (OS) authorized five payees and assigned them the following codes:

0701 - C. Ce11;

0777 - Ве1ше.К2 (К-МоЫ1е);

0380 - L1sha-TU;

0999 - Ka / ak111e1esot;

1111 - ALSECO (utility bills);

0100 - an additional code that the system operator (OS) allocated for the organization of money transfers.

When registering in the system through a financial operator (FO) 1, user 1 excludes the company Вееше.К2 (К-МоЫ1е) from his STD space and forms his STD space, co

- 7 018591 operating OS of the number of their personal accounts with selected payment operators - K.Се11, Л1та-ТУ, 1 <а / ак111с1ссот, ALSEKO:

l / s # 7011110000 - К-Се11 (corresponds to the ΜδΙδΌΝ number of User 1 with the mobile operator (ОМСС) К-Се11);

l / s # 1111877-in L1ta-TU;

l / s # 2076581 - in Ka / Ak1ie1esot;

l / s # 3549701 - in ALSECO;

and also approves the numbers of settlement accounts (RS) and the corresponding public numbers of mobile phones of User 2 and User 3, to which User 1 agrees to make transfers from his current account (RS):

701.111-00-02 (ΜδΙδΌΝ ikeg 2) and the settlement account of User 2 No. 19392210101 with a financial operator (FO) 2 (including all bank details necessary for the transfer of money);

701.111-00-03 (ΜδΙδΌΝ ikeg 3) and the account of User 3 No. 39398210783 with the financial operator (FO) 3 (including all bank details necessary for the transfer of money).

Additionally, during registration, User 1 informs the financial operator (FO) 1 that he will use the number +77011110000 as his personal registered mobile phone number ΜδΙδΌΝ SB-,, and he chose the combination of numbers 1234 as his personal ΡΙΝΣ-code.

Having received the necessary information from User 1, the financial operator (FO) 1 informs the system operator (OS) that he assumes the service of the User using the number +77011110000. In accordance with this instruction, the system operator (OS) will forward all payment instructions received from the number +77011110000 to execute ФО 1.

Using the STD space allows you to abandon the use of the 12ME application (midlet) and use the basic services of the ΟδΜ standard: δΜδ and υδδΌ to enter payment instructions. Consider, within the framework of this example, making payments and money transfers using the υδδΌ service.

Let the system operator (OS) lease the short number # 555 from υδδΌΤ ’and # 0555 by 8Μ8Ο from the OMCC operator. Then the payment instructions about payments and money transfers will have the following format:

1) * 555 # 0701 # 5000 # 1234 # □ means a transfer in ΚΖΤ 5,000.00 - (five thousand tenge) - to the personal account of l / s No. 701.111-00-00 to the mobile communication operator K-Ce11;

2) * 555 # 0380 # 7450 # 1234 # □ means the transfer ΚΖΤ 7.450 - (seven thousand four hundred and fifty tenge) - to the personal account No. 1111877 of the cable television operator ΛΕΜΆ-Τν;

3) * 555 # 0999 # 5350 # 1234 # □ means transfer ΚΖΤ 5,350 - (five thousand three hundred and fifty tenge) - to the personal account No. 2076581 in Kazakhtelecom;

4) * 555 # 1111 # 10500 # 1234 # □ means transfer ΚΖΤ 10,500 - (ten thousand five hundred tenge) - to the personal account No. 3549701 to the utility payment operator ALSECO;

5) * 555 # 0100 # 20000 # 7011110002 # 1234 # □ means transfer ΚΖΤ 20,000- (twenty thousand tenge) - to the account of User 2 No. 19392210101 opened with a financial operator (FO) 2;

In this case, the mobile phone number 701.111-00-02 (ΜδΙδΌΝ ikeg 2) is used as a key identifying the payee (User 2) and his bank details.

The operator of the system (OS) received the payment instructions received from the user forwards to the financial operator for execution 1.

Example 2

Consider the format of payment instructions when using the δΜδ service. For this, the system operator leases a series of short numbers at δ оператораδΟ corresponding to the codes of authorized payees from the operator ОМСС:

# 0701 - for payments in K.Ce11;

# 0380 - for payments in Λ1ιη; · ι-Τν;

# 0999 - for payments in Ka / ak1ie1esot;

# 1111 - for payments to ALSECO (utility bills);

# 0100 - for money transfers.

Then the format of the payment instructions in the δΜδ message will be as follows:

1) 5000 1234 (send to number) 0701 means transfer to ΕΖΤ 5,000 - (five thousand tenge) - to the personal account of l / s # 701.111-00-00 to the operator

- 8 018591 mobile cellular communication K-Ce11;

2) 7450 1234 (send to number) 0380 means transfer ΚΖΤ 7.450 - (seven thousand four hundred and fifty tenge) - to the personal account No. 1111877 to the cable television operator LML-TU;

3) 5350 1234 (send to the number) 0999 means transfer ΚΖΤ 5.350 - to the personal account No. 2076581 in Kazakhtelecom;

4) 10500 1234 (send to the number) 1111 means transfer ΚΖΤ 10,500 - (ten thousand five hundred tenge) - to the personal account No. 3549701 to the operator of utility payments ALSECO;

5) 20000 7011110003 1234 (send to the number) 0100 means transfer ΚΖΤ 20,000 - (twenty thousand tenge) - to the account of User 3 No. 39398210783 opened with a financial operator (ФО) 3.

In this case, the mobile phone number 701.111-00-03 (Μ8Ι8ΌΝ Izeg 3) is used as a key identifying the payee (User 3) and his bank details.

Here it is necessary to pay attention that such encoding of payment recipients will allow users of the system to save codes of authorized payment recipients from the Z1PP1 space in the phone book of a mobile electronic communications device under the corresponding names. For example, the number # 0701 should be saved as ΡΕΑΤΆ - тоα toY1iu1 Τе1еίοη, and # 0999 - as ΡΕΑΤΆ - ΚΖΤе1есот.

It should be noted that the loss of the phone will not lead to the loss of confidential financial information about the user - only payment recipient codes will be stored in the phone memory. It is also obvious that using the STD space makes it possible to simplify the command format and the number of input parameters as much as possible. In the optimal format, it contains only two variables - the sum and the RS2 code, of which the user only needs to remember the RS2 code.

This eliminates the need for the user to remember the complex command format and the codes of authorized payees required by him. It is enough for the user to enter the payment amount and his personal RS2 code, and then send 8M8 to the corresponding short number, while the desired short number will be stored in advance by the user in the memory of the mobile electronic communications device. In fact, the user only needs to remember his personal RS2 code, since the required payment amount is determined by the invoice (receipt) from the payee or by the user.

In this system, the RS2 code is only necessary to protect against accidental input of payment orders and erroneous user actions (protection against a fool).

Continuation of examples 1 and 2.

Having received a payment execution request from the user υ88Ό or 8М8, the system operator (OS) forwards it to the financial operator (ФО) 1, since payment instructions were sent from the number +77011110000, which was registered in the system through the financial operator (ФО) 1. ФО 1, in response, sends through the system operator an 8M8 message indicating the payment amount, purpose of payment (for example, ΖΑ δΑΈΤ) and the registration number of the received payment instruction (for example, ΚΕΘ1 2302938№01). This is necessary so that the user can save the registration number of the payment instruction (order), double-check the correctness of the sent instruction and, if necessary, cancel the payment order. For example, to refuse a request for payment execution, the user must send

1) * 555 # 00 # 1234 # Call - using the service υδδΌ; or

2) 00 1234 (send to the number) 0555 - using the 8M8 service.

The system operator can provide an additional service for authorized payees and provide them with the opportunity to receive a certificate of payments by the registration number of the payment instruction. Then, having received from the user a notification of payment of the invoice / receipt and the registration number of the payment, the payee will be able to check the status of the payment with the system operator (OS). By informing the system operator (OS) of the payment registration number, the payee will be able to receive and verify the following information:

whether payment with such registration number was made;

whether the given payment was addressed to the given payee;

when it was produced;

to which personal account should the received payment be attributed.

Such a targeted information service can be implemented on the Internet and / or using the 8M8 service. In the second case, each payee will need to register with the operator (OS) a number of service numbers of mobile phones from which he will be able to send requests to a special short number allocated by the system (OS) operator to work with payees.

The presence of such a service will allow you to refuse from paper copies of payment orders certified by the financial operator. If necessary, the FI can send a printout of all payment operations to the user's mail or electronic mailbox.

- 9 018591

Conclusions.

Using the basic services of the S8M standard - 8M8 and I88I - will allow us to offer a simple cashless payment system to almost all S8M standard mobile users. And the use of ZIIII is to provide a simple convenient interface and the necessary security for payment transactions. The presence of the ZIIII space allows providing a greater level of security, since even in the event of theft of a user's mobile phone and personal RGY2 code, attackers will not be able to ensure the withdrawal of funds outside the ZIIII space, and this makes the theft of money practically impossible. Attackers will also not be able to pay with users' money their personal accounts with authorized payees, since they are not declared in the ZIIII space.

Using the ZIIII space will also allow ensuring the necessary confidentiality, since when making payments personal information about the user is not transmitted (personal and settlement account numbers, addresses of real estate objects, state registration numbers of vehicles, passport details of the owner, numbers of his credit cards and settlement accounts). Even in case of interception of the payment instruction, the attackers will be able to find out only РГЫ2-code, amount and code of the payee. And they will not be able to use the РГЫ2-code, since the list of personal and settlement accounts that form the user’s Z111 space is already defined and approved by the user - knowledge of the РГЫ2-code will not allow them to change the ZIIII space of this user.

This architecture of the proposed system allows you to store anonymized information about users of the system on the central routing server (CMS) (only the mobile phone numbers of users and paired codes of financial operators (CFOs) are stored in the DBMS, and confidential user information is entered and stored only on authorization servers payments (AIS), which are controlled and managed by financial operators, which is in the interest of all parties and complies with the requirements of the Banking Law second secret: confidential information about users is stored only at those financial operators (FD) through which they registered in the SBR system; only the user knows which FD and with what numbers Μ8Ι8ΌΝ Cisp! (1..Ν) accounts and associated ZIIII spaces; the system operator minimizes possible risks and does not store confidential and personal information about users of RRF.

Additionally, this architecture of the proposed system allows protecting the interests of users in case of disputes with financial operators, since copies of all payment orders sent by users are stored on the central routing server (CMS). In this case, the system operator acts as an independent party (arbitrator), which can confirm or refute the claims of one of the parties.

Such an architecture strictly complies with the regulatory requirements of most countries, since a license for settlement and cash transactions from the Central Bank of the respective country is usually required to receive payments from individuals. The storage and processing of confidential information about users and the execution of payment orders is carried out only by authorized authorized companies - financial operators, and the system operator and the SBR system only transport information from users to the financial operator and back.

The proposed method and system provides a high degree of utilization of the existing infrastructure of financial operators and OMCC operators, which allows implementing the RRF system with minimal investments and in the shortest possible time.

According to the Iareto principle, it can be argued that 80% of all payments for any user are typical, that is, they can be described using the ZIIII space. These are utility bills, taxes for specific real estate and motor vehicles, payments for mobile and fixed-line communications, and cable and satellite television services. To pay the remaining 20% of irregular payments, the user can open a separate bank account and make accruals on it from the main (secure) account immediately before the payment transaction, thereby reducing the risk and the amount of possible losses.

Claims (7)

1. A method of carrying out payment transactions by a user of mobile electronic communication devices through a computer-based non-cash payment system (SBR) for making payment transactions with the formation of payment conditions, characterized in that the personal mobile phone number of the user Μ8Ι8ΌΝ Say !, in the presence and with the participation of the user, they form an (individual) secure user payment space (ZIIII), which includes at least one account number at least at least one payee, and payment operations (payments) are made upon receipt of payment instructions from the registered personal mobile number of the user Μ8Ι8ΌΝ Sorry !. 2. The method according to claim 1, characterized in that in the cashless payment system additionally register the details of the user’s current account opened with a financial operator (FO). - 10 018591 3. The method according to claims 1 and 2, characterized in that when registering the personal mobile phone number of the user ΜδΙδΌΝ SNsSCh in the specified system, the user additionally reports the RS2 code. by which he confirms the payment instructions. sent from the personal mobile number ΜδΙδΌΝ Syep1. 4. The method of claim 1. characterized in that. that in the cashless payment system (SBR), each payee is assigned a unique code (CC). by means of which the payee is identified and which is used as a short number for receiving payment instructions from the user using ϋδδΌ and / or δΜδ services of at least one mobile cellular communication operator (OMCC). 5. The method according to claim 1. characterized in that. that in the cashless payment system (SBR) for the use of money transfers to users of the system, users use mobile phone numbers. which payments are intended. 6. A computer system of cashless payments (RRB) for making payment transactions by a user of mobile electronic communication devices. Including payment authorization server (SAP). containing a unit for working with users (PDU) and connected with mobile electronic communication devices through at least one server user interface (SPI) and the server of at least one financial operator (SFD). characterized in that. that the number of payment authorization servers (SAP) is equal to the number of financial operators (FD). connected to the system. in addition, each server authorization payments (SAP) is associated with one server of a financial operator (SFD). Moreover, each server authorization payments (SAP) corresponds to its own block of work with users (PDU). 7. The computer system according to claim 5. characterized in that. which additionally introduced a central routing server (CMS). connecting user interface server (SPI) with payment authorization servers (SAP). at the same time, the central routing server (CMS) is made with the possibility of controlling the exchange of information between the user interface server (SPI) and payment authorization servers (SAP).