RU2371877C2 - System allowing operator to render services of financial transactions, and methods of implementing such transactions - Google Patents

Abstract

FIELD: information technologies.

SUBSTANCE: system allows the subscribers of the wireless communication operator to perform financial transactions by means of a mobile phone or and electronic device which can be connected to the wireless communication network. System consists of a transaction processing platform which is installed on communication operator computers, connected to wireless communication network, interacts with other elements of the communication operator, manages financial transaction accounts, and checks/performs financial transactions sent by subscribers. System also contains the client software which can be activated in the subscriber mobile phone or its related electronic device or in the subscriber identification module which is inserted in the mobile phone or the related electronic device. That client software allows the subscriber to prepare, certify and send transaction commands via wireless communication network to the transaction processing platform. Method describes the system operation.

EFFECT: enlarging functional capabilities.

46 cl, 4 dwg

Description

Technical field

The invention relates to a wireless communication system and, in particular, to a system that allows a wireless operator to provide financial transaction services; and methods for implementing such transactions through a wireless network.

State of the art

The development of networks, such as the Internet, was a prerequisite for the emergence of new technologies such as e-commerce. However, electronic payment systems lag behind the latest achievements, and currently efforts to implement electronic digital payment systems are aimed at ensuring their simplicity, efficiency, user convenience, security, extensibility, ease of deployment, etc. In most cases, digital payment systems require the implementation of a complex architecture and the participation of many parties, especially financial institutions, including banks, etc. In addition, the implementation of such a system usually requires the installation of specialized infrastructure, which complicates its mass distribution among consumers. Digital systems are already very successful in the field of communications and, in particular, in mobile telephony systems, such as GSM, CDMA and W-CDMA, CDMA2000, etc. These systems provide consumers with enhanced capabilities and increased productivity. Therefore, such systems have become very popular in recent years, and a significant part of the population currently uses digital mobile phones not only for voice communications, but also for data transfer. For many people, a digital mobile phone has become a natural and even indispensable companion; and this invention provides for the expansion of its scope.

SUMMARY OF THE INVENTION

The objective of the invention is to create a solution to the complex problem of the implementation of electronic financial transactions.

This invention provides a new system that allows a telecom operator to provide its customers with financial transaction services. The invention is characterized in that the system does not require the participation of any financial institutions (bank, savings bank, credit card organization, etc.); It does not require the installation of specialized network infrastructure, does not need to use other traditional means of payment, such as credit cards or debit cards; does not require the use of special devices by subscribers; but, on the contrary, allows the full use of the existing wireless communication network and operator’s communication system, as well as existing mobile phones. It differs in that the telecom operator opens and manages financial transactions accounts of its subscribers, and also provides subscribers with tools and rights to carry out financial transactions from their mobile phones or connected electronic devices.

Since a single person, a telecom operator, operates and manages financial transaction accounts, methods and relevant tools, the system and architecture of its protection are greatly simplified. It also allows you to avoid conflicts, otherwise, multiple parties.

The system contains a transaction processing platform that is installed on the telecom operator’s computers, connected to a wireless communication network, interacts with other elements of the telecom operator’s system (subscriber database, authentication center, accounting system, etc.), manages financial transaction accounts, certifies / performs financial transactions sent by subscribers and performs other tasks, such as confirming transactions, preparing an account statement, preparing reports, etc. This platform implements the financial transaction methods described in this invention.

The system also includes client software that runs on the subscriber’s mobile phone, or on his plug-in electronic device, or on the subscriber’s identification module (SIM for GSM, UIM for CDMAO, USIM for 3G UMTS, etc.), which is inserted into the mobile phone or plug-in electronic device. Such client software allows the subscriber to prepare, authenticate, send transaction orders to the transaction processing platform over the wireless network according to the methods described in this invention.

This system allows subscribers to carry out transactions, for example, payment to another person, payment to the seller, etc., in a simple, secure and user-friendly way using their digital mobile phone or electronic equipment connected to a wireless network. The advantages of such a system are obvious. It provides new features that are currently not yet available, for example:

- instant payments by millions of people to one single organization, which would be useful in the case of a charity event organized on a TV show, seeing on a television screen a single account number (for donations), a large number of viewers can use their mobile phones to make a donation, while the organizer of a charity event can track the results in real time;

- the possibility of anonymous payment;

- the possibility of making a payment to an unknown party that is identified only by a number.

These systems and methods of financial transactions represent a new alternative to existing means of payment, namely cash payment, credit or debit cards, checks, money transfers, as they include in one single solution the advantages of all these funds.

Brief Description of the Drawings

The following is a more detailed description of the invention with reference to the accompanying drawings, in which:

figure 1 is a General diagram of a system where it is shown how the transaction processing platform is connected to a wireless communication network and interacts with subsystems of a communication operator;

FIG. 2 is a flowchart of a transaction scenario 1, described in detail below; different stages are shown; the icons on the right indicate where the tasks are performed: mobile phone, POT;

figure 3 - various images on the screen of a mobile phone payer according to the steps shown in figure 2;

figure 4 - various images on the screen of the mobile phone of the payee according to the steps shown in figure 2.

Detailed Description of Preferred Embodiments

This invention is characterized in that the telecom operator provides subscribers with a financial transaction account (SFT). This financial transaction account is in many ways similar to a current bank account and allows its owner to make deposits, receive payments and money transfers from third parties, make payments to third parties, use an overdraft, receive loans, etc. The subscriber and the telecom operator sign an agreement on SFT, which specifies the terms and conditions of use. These conditions may include, but are not limited to: the general terms and conditions of using the CFT, the minimum balance, credit or overdraft limits, interest on loans, interest on deposits, limits on transaction amounts, payment for services and transactions, billing conditions, discounts on transaction volumes, confidentiality, anonymity of payments, loan repayment procedure, loan renewal procedure, prepayment procedure, etc.

Opening a financial transaction account is a simple process, since each subscriber is already clearly identified by the operator’s system through a combination of personal data, such as name, address, ID card number, bank account number, etc.

Having concluded the contract, the subscriber receives a unique mobile phone number directly connected to his telephone personal account in the tariffication and accounting system of the telecom operator.

This invention is characterized in that the “mobile phone number” of the subscriber is also used to identify his financial transaction account. Thus, in order to receive payment transactions from third parties directly to their SFT, the subscriber only needs to indicate his mobile phone number.

According to an alternative embodiment of the invention, the telecom operator provides a special number (different from the mobile phone number) for the financial transaction account “CFT number”. This is especially convenient when the subscriber wants to maintain a certain level of confidentiality, does not want to give too many his mobile number.

Thus, the subscriber who wants to register in the financial transaction service will have two accounts, one is the telephone account where his telephone activity is recorded, and the other is the financial transaction account intended for his deposits and financial transaction settlements.

According to an alternative embodiment, the telephone account and the financial transaction account are combined into one single account. This is especially useful for prepaid phone bills. This allows the telecom operator to provide the prepaid subscriber with a “pure debit” financial transaction service.

This makes it easier for the subscriber to carry out financial transactions using their mobile phone in the ways described later in this document.

According to an alternative embodiment of the invention, the subscriber may use other mobile equipment in addition to the mobile phone; this equipment can be, but without limitation: a personal computer, PDA (personal digital assistant), electronic notebook, PDA, digital camera or any other electronic equipment that can be identified on the network and connected to the operator’s wireless network. This equipment is hereinafter referred to as “plug-in electronic devices”.

According to figure 1, the invention also differs in that the system consists of the following elements or subsystems:

Software Platform: Transaction Processing Platform 10 (POT)

The invention is characterized in that this platform works either on existing computers of a telecom operator or on a specialized computer. It is connected to some of the basic elements of the operator’s wireless system and interacts with them, and such elements include, for example, but without limitation: subscribers database 12, authentication module 14, various data transmission channels 16, charging system 18, accounting system 20, Internet 22, etc.

This platform is the core of the system and performs a number of functions, including but not limited to:

Reception via data transmission channel 16 and interpretation of transaction orders from mobile phones 24 or connected electronic devices 26

Reception on channel 16 of data transmission and interpretation of information or requests about the status of the account

Transaction processing (performing important, credit and debit operations on various accounts)

Transaction Settlement

Selecting the appropriate data channel 16 for sending and / or receiving data to or from mobile phones 24

Sending transaction notifications, confirmations, or denials to relevant parties

Sending the status of SFT to its owner

Regulation, updating, change of conditions and parameters of SFT as a result of commercial conditions established between the telecom operator and the subscriber

Charging, invoicing, processing transaction fees for the relevant parties and in accordance with the terms and conditions of each TFT

Creating statements with SFT

Creating an account book and billing

Providing an online report for CFT owners

Automatic generation of alerts and notifications

Generation and sending of printed reports, for example, an account status report, transaction notices, accounting reports, etc.

Client Software Program: Mobile Transaction Management Software (PUMT)

This invention is characterized in that the client software is stored either in the memory of the mobile phone 24 or the connected electronic device 26, or in the memory of the subscriber identity module 28 (SIM card for GSM, UIM card for CDMA, USIM card for 3G UMTS or equivalent device) and can be performed by one of the microprocessors of a mobile phone or connected electronic device, or by a microcontroller SIM, or both SIM, and the processor of a mobile phone or connected electronic device.

This client software enables financial transactions from a mobile phone 24 or a plug-in electronic device 26 according to the methods described below. It also allows you to receive information about the status and situation of the financial transaction account. To do this, it performs a number of functions, in particular, but without limitation:

Display of information in a structured form on the screen of a mobile phone or connected electronic device to invite the subscriber to actions

Generation of screens and fields for entering transaction data

Password prompt

Subscriber Authentication

Preparing a Transaction Data File

Encryption (if necessary) of transaction related data files

Generation of digital signature of transaction related data files

Detection of the most suitable data channel to be used according to the capabilities of a mobile phone or connected electronic device and characteristics of transaction data (size, priority, etc.)

Sending on the selected channel 16 data of the transaction data file to the transaction processing platform 10

Managing the parameters of financial transaction services at the level of a mobile phone or connected electronic device

Managing the activation or deactivation of a financial transaction service on a mobile phone or connected mobile device

Reception, interpretation, decryption of transaction related data files

Digital signature verification

Display of data and information received from the POT, in particular, but without limitation, confirmation of the transaction, cancellation of the transaction, balance or status of the TFT, response to the request, update of the TFT parameters, client software updates, etc.

The invention is also characterized in that this software is loaded into the memory of a mobile phone 24 or a plug-in electronic device 26, or into a SIM 28 (or UIM or USIM) memory after a subscriber is registered in a financial transaction service. This is usually done at the point of sale (PP) of the telecom operator through an appropriate connecting device between the PP and the mobile phone or connected electronic device; or, in the case of a SIM (or UIM or USIM), by means of a card reader connected to the PCB.

According to another embodiment of the invention, this software is already pre-loaded into the memory of a mobile phone, or a connected electronic device, or SIM (or UIM, or USIM); in this case, you only need to activate the use of this software after registration. This is done either directly at the point of sale by manually entering the activation code, or by sending this activation code over the air from the POT to a mobile phone.

According to another embodiment of the invention, this software is downloaded over the air from the POT directly to a mobile phone, or a connected electronic device, or SIM (or UIM, or USIM) and is automatically activated after a subscriber registers in a financial transaction service.

The invention is characterized in that the PUMT contains a file or manages a parameter file that represents the terms and conditions specified in the SFT agreement, as well as the current balance and / or SFT loan limit.

The invention is also characterized in that the PUMT compares the transaction data with these parameters before the transaction order is sent to the POT.

This file can be updated regularly, in particular, when changing the parameters or the remainder of the SFT.

This is especially beneficial, since the PUMT can perform a series of validation checks on the transaction during its preparation by the subscriber and invite the subscriber to make changes if the transaction data that he entered is incompatible with the state of his TFT. It also provides an advantage in reducing the load on the data network and the POT by preventing invalid transactions from being sent to the POT.

Transmission of data and information related to a transaction

This invention is characterized in that the transfer of data related to financial transactions and information between the POT and mobile phones or connected electronic devices (in any way) is carried out using one or more types of data channels that exist in wireless networks.

Digital wireless communication systems have several data channels, and in the future there will be even more. To illustrate and simplify, consider the GSM example.

A GSM or UMTS system can provide several data channels, namely:

USSD: Unstructured Service Support Data

HSCSD: High Speed Dial-up Data

SMS: short message service

GPRS: general-purpose packet radio system

EMS: Advanced Messaging Service

MMS: multimedia messaging service

All these data channels have different characteristics, capabilities, advantages and disadvantages. In addition, mobile phones do not necessarily support all six of the above channels; Currently, all GSM mobile phones support USSD and SMS, and only the latest or promising phones support GPRS, EMS or MMS.

This invention is characterized in that whenever a POT needs to send data or information related to a transaction to a mobile phone or connected electronic device, it must select the most suitable channels for use. The system can use one or more data transmission channels for one transfer, and the choice of data channels depends on a number of considerations, in particular, but without limitation:

Type and capabilities of a mobile phone or plug-in electronic device

Mobile phone on or off

Time

Data or network link loads

The actual location of the mobile phone

Priority

Data volume or file size

Data is encrypted or not

The present invention is also characterized in that whenever a transaction data or a data request needs to be sent to a mobile phone or connected electronic device, the PUMT selects the most suitable data transmission channel for use. The choice of data channel depends on a number of considerations, in particular, but without limitation:

Type and capabilities of a mobile phone or plug-in electronic device

Time

POT Teams

Data or network link loads

Priority

Data volume or file size

Data is encrypted or not

Ways to complete financial transactions

This invention is characterized in that financial transactions are initiated and / or performed by a subscriber using a mobile phone or a plug-in electronic device into which the above-described software (MTMS) is properly downloaded, using the methods described below.

The main types of financial transactions are, in general, payment transactions; These transactions can be implemented and executed in a large number of ways. In order to understand the invention, the following description is limited to only a few methods, which are called transactional scenarios and possibly represent the most common situations.

Transaction scenarios

In each scenario, the payer (B) is involved who wants to send the payment to the payee (A) who receives this payment. In some cases, “A” initiates the process by sending “B” a payment request.

Scenario 1: the payer (B) generates a payment order (PP) in favor of the payee (A) without intervention from “A”.

Scenario 2: the payee (A) generates and sends a payment request (PO) to the payer (B); “B” receives a PO and, if it agrees with it, generates a payment order (PP) in favor of “A”.

The payer and the payee have signed an agreement with the same telecom operator, have their own financial transaction account and can use the financial transaction service provided by the telecom operator. “A” and “B” can be individuals, shops or organizations (companies, associations, clubs, etc.)

Transaction process

For purposes of illustration and simplicity, a process using the GSM system, which is currently the most common digital mobile telephony system in the world, is described below.

Scenario 1: simple payment scenario

The payer (B) wants to pay the recipient (A) the amount of X $ using his mobile phone or a connected electronic device and through the financial transaction service. Since “B” knows “A” or is able to identify “A” by its mobile phone number or its SFT number, “B” generates and sends “A” a payment order (PP) in the amount of X $.

This is a very common scenario when someone wants to send money to a parent or relative; or wants to pay the bill (for electricity, telephone, rent, etc.); or wishes to make a donation, as mentioned above.

This invention is distinguished by the method of generating a payment order directly from a mobile phone or a connected electronic device, sending a payment order to a transaction processing platform, and the POT process makes a payment in favor of “A”, confirms the execution of this payment “A” and “B”. The method can be represented as a sequence of steps, which are described below and presented in the form of a flowchart in figure 2.

The invention is also characterized in that the payment transaction can be carried out anonymously. In this case, the payee receives the payment without knowing who the payer is. The advantages of this feature are obvious.

This invention is also characterized in that the payer can select the date and time of payment.

Stage 1: “B” prepares and signs a payment order (PP)

For this purpose, “B” activates the “financial transaction” function on its mobile phone by selecting from the menu. This is easily done using the SIM function menu (STK) in the GSM system.

According to figure 3 on the screen of the mobile phone displays a prompt "B" to enter the following data:

Payee number: mobile phone number “A” or SFT number “A” (15812345678 in FIG. 3)

Amount $: X (1,238.88 in FIG. 3)

Anonymous: Y or N (Yes or No)

Priority: (priority level)

Purpose: (optional)

Comments: (optional)

After entering all the necessary data, “B” presses the YES button on his mobile phone to finish entering the software. Then PUMT performs a number of checks, in particular, but without limitation:

Checking the format of a mobile phone number or SFT number

Reconciliation of the amount X of the payment with the balance of the CFT and / or credit limit, as well as other parameters of the CFT agreement.

If PUMT finds that the data entered by “B” is valid, then the mobile phone displays a new screen with the data corresponding to the software, and adds the number “wxyz” of the software, then invites “B” to verify, confirm and sign.

Otherwise, the PUMT displays a warning or generates a listened message requiring “B” to change its PP. This can be, for example, the amount of X $, which is outside the scope of the authorized agreement of the CFT, etc.

Verification / confirmation / signing is done by entering a password (a string of alphabetic and / or numeric characters), which “B” keeps secret. According to another embodiment of the invention, the verification / confirmation / signing of the UI is triggered using another authentication means, depending on the capabilities of the mobile phone or the connected electronic device. Such a tool may be:

Fingerprint recognition if the mobile phone is equipped with a fingerprint sensor;

Voice authentication, if the voice authentication algorithm works on the mobile phone;

Face recognition if the mobile phone is equipped with a digital camera and a face authentication algorithm is installed;

You can also provide any other authentication method using biometric or other means. After Verification / Confirmation / Signing, nothing is required from “B”.

Stage 2: Sending a payment order to POT

This invention is characterized in that after “B” has verified / confirmed / signed, the PUMT in the mobile phone generates the BP data file _B (x, A) with the BOP data and the date and time when it was checked.

This invention is also characterized in that the PUMT generates a digital signature of the CPU (PP _V ) for the PP _B (x, A) using a cryptographic algorithm and a secret key that is stored in the memory of a mobile phone or a connected electronic device. It can be an algorithm and a secret key that are used by the communication network to authenticate a mobile phone; it can also be an algorithm and a key allocated for a financial transaction.

According to another embodiment of the invention, the telecom operator uses a public key infrastructure (PKI) and provides each SFT subscriber with secret and public keys, which are stored securely in the memory of a mobile phone or connected electronic device or in SIM memory. The public key algorithm is used by PUMT and POT in order to generate digital signatures, encrypt transaction data files, decrypt the same files, verify digital signatures, etc.

According to another embodiment of the invention, the cryptographic algorithm and the key are stored in the protected SIM memory, and the SIM processor generates and / or verifies the digital signature.

After generating a digital signature, the PUMT selects the most suitable data transmission channel (as noted above), formats the file according to the selected data transmission channel, and sends the data file _B (x, A) along with the digital signature of the CPU ( _B ) to the platform transaction processing (POT).

According to another embodiment of the invention, the PP data file _B (x, A) is encrypted using the same algorithm and key that are used in generating the digital signature; or in the case of using the PKI, the data file is encrypted using the POT public key.

At the same time, the PP data file _B (x, A) is stored in the memory of the mobile phone or in the SIM memory.

Stage 3: processing the payment order via POT

After the data file PP _B (x, A) with the corresponding digital signature of the CPU (PP _B ) arrives at the POT, the latter can identify the sender as "B".

The POT certifies the digital signature of the CPU (PP _B ) (generated by "B" and attached to the PP _B (x, A)), which allows you to authenticate "B" as the actual sender of the PP.

POT adds a time stamp (date and time) generated by POT's own internal clock and highlights the data of the payment order sent by “B”.

The POT sends back a confirmation message to “B”, the appearance of which depends on the priority chosen by “B”. The following is an example of a sent message that is displayed on the screen of a mobile phone: “Your PP No. wxyz has been received, soon the result of the execution will be sent to you. Thank you. ”If the data file has been encrypted, then the first operation that the POT performs is to decrypt the file using the appropriate algorithm and key.

The POT then performs a series of checks to verify and complete the transaction.

POT checks whether the payee “A”, identified by his mobile phone number or CFT number, is really a CFT subscriber or not. Then POT checks the status of the TFT “B” parameters contained in the TFT agreement with the amount of X $ payable “A” (current balance, overdraft, credit limit, transaction limit, etc.).

After these validation checks have been performed for the software sent by “B” in favor of “A”, the POT can authorize or cancel the transaction, and therefore, two situations can arise:

- transaction authorized

- transaction canceled

1. Transaction authorized

This invention is characterized in that the POT processes the transaction and performs the following operations:

POT deducts the amount of PP, i.e. X $, with SFT "B".

POT deducts the amount of Y $ ($ 1.24 in figure 3, screen 8), corresponding to the transaction fee (if any) from SFT "B". This transaction fee is determined by the SFT agreement between the telecom operator and B.

POT credits the amount of X $ to SFT "A".

POT deducts the amount of Z $ (1.48 $ in figure 4, screen 11), corresponding to the transaction fee, from SFT "A". This transaction fee is determined by the SFT agreement between the telecom operator and “A”.

After these debit and credit operations, the balances on each CFT are as follows:

For "B" - Residue B2 = Residue B1 - X - Y.

For "A" - Residue A2 = Residue A1 + X - Z.

The POT generates a transaction number identifying this transaction.

POT credits Y + Z to the transaction fees of the carrier.

According to yet another embodiment of the invention, the fees Y and / or Z are paid to the respective telephone bills of “B” and / or “A”.

Stage 4: transaction confirmation for "B"

This invention is characterized in that the POT generates a transaction confirmation message for "B" containing the following data:

Transaction Number (B21669 in Figure 3, Screen 6)

PP number

The date and time of the transaction (2002.04.28-18: 58: 48 in figure 3, screens 6, 7)

Recipient of payment: mobile phone number or SFT "A" number

Amount: X $

Transaction Fee: Y $

New SFT residue: Residue B2 ($ 4,512.12 in figure 3, screen 8)

Is the payment anonymous: yes or no

Purpose of payment: (as indicated in B)

Comments (as indicated by B)

The data related to this transaction confirmation notice is formatted by the POT in accordance with the data channel used and sent to payer “B”.

According to another embodiment of the invention, this data is encrypted using the appropriate algorithm and key and sent to “B”.

“B” may display this notice on the screen of its mobile phone or connected electronic device. This notice is also recorded in the memory of his mobile phone or in the SIM memory; the record of the payment order is then deleted.

The memory of the mobile phone or SIM is configured so that it is possible to record several transactions made by “B” into it. This allows "B" to verify the accuracy of the certificate of account status provided to him by the telecom operator on a regular basis.

Stage 5: sending payment notice “A”

The invention is characterized in that the POT generates a payment notice for "A" containing the following data:

Transaction number

Date and time of transaction

Amount received: X $

Transaction Fee: Z $

New SFT residue: Residue A2 ($ 11,236.40 in figure 4, screen 11)

Payer: mobile phone number or SFT "B" number or not specified (in case of anonymous payment)

Appointment: (according to the specified "B")

Comments: (as indicated by "B")

First, the POT sends “A” a warning informing “A” about the receipt of payment. The following is an example of a warning: “Your SFT received a payment in the amount of X $. Details of the transaction are contained in the payment notice. ”

The data related to this payment notification is formatted by the POT in accordance with the data channel used and is sent to the payee “A”.

According to another embodiment, this data is encrypted using the appropriate algorithm and key and sent to “A”, after which it is decrypted on the mobile phone “A” by means of a PUMT.

As shown in FIG. 4, “A” may display this notice on the screen of his mobile phone. This notification is also recorded in the memory of his mobile phone or SIM.

The memory of the mobile phone or SIM is configured so that it is possible to record several transactions received by “A” into it. This allows "A" to verify the accuracy of the certificate of account status provided to him by the telecom operator on a regular basis.

Stage 6: registration of transaction on POT

This invention is distinguished by the fact that the POT records in the transaction log all transaction details (transaction number, date and time of receipt of the software from "B", PR number, date and time of the transaction, mobile number or payer's TFT number (B), mobile number the telephone number or SFT number of the payee (A) of the payment, the amount X $ paid, whether the payment is anonymous or not, priority, purpose of payment (according to B), comments (according to B), transaction fee from “B”: Y $, transaction fee from "A": Z $, date and time confirm waiting for “B” and the used data channel, the date and time of confirmation for “A” and the used data channel, digital signature).

This journal is especially useful for managing all financial transaction accounts and for accounting purposes.

2. Transaction rejected

This invention is characterized in that the POT immediately sends a “B” warning on the fastest data transmission channel, notifying him that his payment order No. wxyz has been rejected and indicating the reason for the refusal. A warning is displayed on the payer's mobile phone (B).

For example, such a warning might look like this:

“Your OL No. wxyz in the amount of $ X rejected. Reason: Your overdraft limit will be exceeded. Please contact your SFT consultant. ”

With accounts of financial transactions “B” and “A” no debit and credit operations are performed; no invitation for “A” is sent.

The software recorded in the memory of the mobile phone "B" or in the SIM memory is updated with a note; "Rejected: date and time."

PP details are recorded in the rejected transaction log.

Scenario 2: payment with a preliminary request from the payee

In this scenario, the payee (A) of the payment addresses the payer (B) with a request for payment (PO) via POT.

This can happen, for example, in a retail store, where the seller is interested in receiving a payment directly to his SFT.

This obviously implies that “B” previously somehow informed “A” of its mobile phone number or SFT number.

To generate a payment request, “A” activates the corresponding function on his mobile phone by selecting a menu. In a GSM system, this is usually done using the SIM function menu (STK).

The mobile phone displays a screen and prompts “A” to enter the following data:

Payer number: mobile phone number or SFT number

Amount $: X

Purpose: (optional)

Comments (optional)

At the end of the input, PO “A” activates the send command. PUMT mobile phone "A" selects the most suitable data transfer channel, creates a file formatted for this data transfer channel, and sends the file to the POT. Upon receiving this file, the POT recognizes that it is a payment request sent by “A” to “B”. The POT performs a preliminary check to determine whether such a potential transaction can be authorized and sends a warning to “B”.

If the transaction can be authorized: this warning contains all data regarding the RFP and a note that the relevant payment may be authorized. Then the warning is sent to "B" on the appropriate data channel and displayed on the mobile phone "B".

For example, this warning might look like this:

Payment Request:

From: mobile phone number “A” or number of SFT “A”

Amount: X $

PO Number: abcde

Appointment: "text"

Comments: "text"

This transaction may be authorized! If you want to pay, press YES

By pressing YES, “B” automatically receives a payment order on your mobile phone or electronic device that is fully ready for verification / confirmation / signing, as described in scenario 1 earlier. Then, the process continues as described in scenario 1.

If the transaction cannot be authorized: warnings are sent immediately to “A” and “B” stating that the payment transaction corresponding to the RFP that sent “A” cannot be authorized.

For example, a warning might look like this:

Warning for “A”: “Sorry, the transaction relating to your RFP number abcde to address“ B ”cannot be authorized!”

Warning for “B”: “You received from“ A ”ZP No. abcde at X $. This transaction cannot be authorized. Reason: not enough funds on your SFT. ”

This method has several advantages for both the payer and the payee.

It provides the payee with direct feedback from the POT, allowing him to find out if the payer can actually pay the required amount.

It is also convenient for the payer, since the payment order can be generated automatically, using the data received from the payroll. Thus, the payer does not need to spend time on entering data to prepare the software; he only needs to verify / confirm / sign it.

According to another embodiment of the invention, a payment request (PO) can be sent directly from “A” to “B” via a messaging service (SMS, EMS, MMS or other) without transferring via POT. In this case, a preliminary check by the POT is not required; also no alerts can be sent.

In this case, “A” generates a specially structured message using the corresponding PUMT feature.

The message may look like this:

Hello, please pay: "X $"

To: mobile phone number or SFT number

PO Number: abcde

In order: “purpose of payment”

Comments: “text, if necessary”

This message is sent directly to "B".

Upon receiving this message, the PUMT of the mobile phone “B” recognizes it as a payment request and displays it in such a way that “B” can simply and quickly respond to it. “B” you only need to press the YES or NO button on your mobile phone to start generating the appropriate payment order in favor of “A”.

If “B” agrees, it can generate a payment order in the same way as in scenario 1; but in this case, “B” does not need to enter all the data necessary to generate the payment order, since they can be extracted from the message containing the payment request sent by “A”.

Other transaction scenarios

For purposes of illustration and for a better understanding of the invention, two main transaction scenarios are described in detail above. This invention is characterized in that it allows you to implement other transaction scenarios, for example, but without limitation:

Deferred payment, transaction scenario: it is similar to scenario 1, but the actual payment (i.e. debit and credit transactions) is executed at a later date than the payment order. In this case, the payer adds to his software the due date when the payment is due. This can be beneficial for paying bills on a fixed date (electricity bill, apartment rental, telephone bill, etc.)

Deferred payment request payment transaction scenario: It is similar to scenario 2, but with a deferred payment described above.

Conditional payment, transaction scenario: this is, in general, a deferred payment scenario, when a payment is actually made when a number of conditions are met. The conditions may be met by “A” and / or “B” or by a third party “C”. This can be beneficial in situations where the payer agrees to pay only after the successful delivery of goods or services.

This can be illustrated by the following example:

“B” buys books from “A”; books will be delivered by mail, and “B” agrees to pay only upon receipt of the books. Thus, the payment condition is confirmation of delivery by the post office (C). In this case, “A” issues an RFP, which will be accepted by “B”, which will issue the corresponding RFP in the same manner as described in scenario 2. However, the payment will be made by POT only after confirming receipt of books. Upon delivery, "C" sends the POT delivery confirmation notice (SDI) containing the following data:

IPD No: 123456

Sender: mobile phone number and SFT "A" number

RFP: abcde

Recipient: mobile phone number “B” or number of SFT “B”

Goods received: date and time

Upon receipt of the POT, it sends the IPD “V”. “B” receives this notice, which he can display on his mobile phone or connected electronic device and, if agreed, verify / confirm / sign by entering his password in the same way as for the PC, this is the same as generating a digital signature for SPD. “B” sends the IPD together with the digital signature back to the POT. Having received it, POT sends a message “C” and “A” and makes a payment in favor of “A”.

Special lines and accounts

For sellers and store owners who are interested in providing their customers with the opportunity to pay through the financial transaction services provided by the telecom operator, it may be undesirable to pay for one or more mobile communications contracts and the corresponding financial transaction accounts, which in reality will never be used for voice calls.

This invention is characterized in that the telecom operator can provide mobile telephone lines on which voice services are blocked, and only data channels can be used. These mobile phone lines can also have numbers that make them easy to distinguish as lines intended only for data transfer, or even as lines intended only for financial transactions. For example, in China, mobile phone numbers often start with three distinctive numbers, such as 139, 138, etc. Mobile phone numbers intended only for data transmission could start with three digits like 839, 838, etc.

In general, trading terminals in stores only accept payments (this is their main function) and rarely or never make payments. It can also be very convenient for the store owner that the financial transaction accounts associated with the trading terminal are set up so that they can only accept payments and are not able to make any payments.

This invention is characterized in that the telecom operator limits the capabilities of certain financial transaction accounts, for example, but without limitation: it allows you only to receive payments from third parties, but not to make payments to third parties.

Obviously, the described invention can be modified in many different ways. Such changes should not be construed as a departure from the scope of the invention, and it will be apparent to those skilled in the art that all of these modifications are to be included in the scope defined by the appended claims.

Claims (46)

1. A system that allows subscribers of a wireless operator to carry out financial transactions using a mobile phone, in which the subscriber has one or more open financial transaction accounts that are managed by the said telecom operator, each of these financial transaction accounts is associated with one wireless telephone line and has the ability receive cash deposits and be used for debit and credit operations, and the system contains:
a transaction processing platform, which is a software system operating on the telecom operator’s computers and which interacts with at least a subscriber database, a wireless telephone network, an accounting system and other elements of a telecom operator’s infrastructure, while the transaction processing platform receives and interprets financial transaction orders transmitted over a wireless telephone network via a mobile phone and carries out financial transactions corresponding to the orders transactions and manages movements and operations, including debiting and / or lending related to financial transaction accounts, confirming transactions, issuing bank statements, sending transaction reports to financial transaction account holders, completing and receiving transaction related data via a wireless telephone network to / from mobile phones; and
a client software program that authenticates a subscriber by entering a password through a mobile phone, allows the subscriber to receive or authenticate data related to a financial transaction, and display it on a mobile phone, allows to send or receive data related to financial transactions using a mobile phone, or financial transaction account information via a wireless telephone network, with financial transactions being performed between mobile phones and at least two users connected to the system via a wireless telephone network, and transaction processing platform. 2. The system according to claim 1, characterized in that each financial transaction account has an account number that matches the subscriber’s mobile phone number. 3. The system according to claim 1, characterized in that each financial transaction account has an account number that is different from the subscriber’s mobile phone number. 4. The system according to claim 3, characterized in that the financial transaction account is limited to accepting payments, and making payments is prohibited. 5. The system according to claim 1, characterized in that on the wireless telephone line associated with the financial transaction account, the possibility of voice communication is blocked and only data channels are supported. 6. The system according to claim 2, characterized in that the financial transaction account is combined with the personal account of the mobile phone subscriber in a single account. 7. The system according to claim 1, characterized in that the client software program is preloaded or exists in advance in the subscriber’s mobile phone memory. 8. The system according to claim 1, characterized in that the client software program is downloaded to the subscriber’s mobile phone memory after the subscriber opens the financial transaction account. 9. The system according to claim 1, characterized in that the client software program is preloaded into the memory of the subscriber identity module. 10. The system according to claim 1, characterized in that the client software program is loaded into the memory of the subscriber identity module after the subscriber opens the financial transaction account. 11. The system of claim 8, characterized in that the client software program is downloaded over the air via a wireless telephone network. 12. The system according to claim 1, characterized in that the client software program is activated or unlocked after the subscriber opens the financial transaction account. 13. The system according to p. 12, characterized in that the activation of the client software program is implemented by entering a specific code. 14. The system according to item 13, wherein the specific code for activating client software is sent over the air via a wireless telephone network. 15. The system according to claim 1, characterized in that the client software program is executed by the microprocessor of the subscriber’s mobile phone. 16. The system according to claim 1, characterized in that the client software program is executed by the microprocessor of the subscriber identity module. 17. The system according to claim 1, characterized in that the client software program is executed partially on the microprocessor of the mobile phone and partially on the microprocessor of the subscriber identity module. 18. The system of clause 15, wherein the client software program contains or activates an encryption algorithm and / or digital signature algorithm using a unique subscriber encryption key. 19. The system of clause 15, wherein the client software program, operations related to encryption / decryption, or the generation / verification of digital signatures are performed by the microprocessor of the subscriber identity module. 20. The system of claim 18, wherein the subscriber’s encryption key is unique to the subscriber and the subscriber’s financial transaction account. 21. The system of clause 15, wherein the client software program is designed to create, read or update a data file stored in the memory of a mobile phone or in the memory of a subscriber’s personal module and containing parameters related to the terms and conditions of use of the financial account subscriber transactions. 22. The system according to item 21, wherein the data file contains at least one of the following financial transaction account data of the subscriber: current balance, credit limit, minimum amount of debit operation, maximum amount of debit operation. 23. The method used by a subscriber in the system according to claim 1, for preparing or certifying a financial transaction order on a mobile phone and for sending it via a wireless network to a beneficiary's (payee's) mobile phone via a wireless telephone network to confirm the order by the beneficiary and to the platform processing transactions to execute an order, the method comprising the following steps:
receive the transaction data together with at least the beneficiary (payee) number and the transaction amount, verify the transaction data by entering a password using a mobile phone or using another subscriber authentication means, send the transaction data to the beneficiary’s mobile phone via a wireless telephone network, and
perform the transaction after being certified by the beneficiary through the beneficiary’s mobile phone. 24. The method according to item 23, wherein the transaction data is received from the beneficiary. 25. The method according to item 23, wherein the transaction data is perceived from the voice. 26. The method according to item 23, wherein the authentication is carried out by means of a fingerprint authentication mechanism of a subscriber in a mobile phone. 27. The method according to item 23, wherein the authentication is carried out by means of a subscriber authentication mechanism by voice. 28. The method according to item 23, wherein the certificate is produced through the authentication mechanism of the subscriber by face. 29. The method according to p. 23, characterized in that it further comprises a step at which the subscriber indicates the priority level. 30. The method according to item 23, wherein it further comprises the step of the subscriber indicating a choice to remain anonymous. 31. The method according to item 23, characterized in that it further comprises a step on which the subscriber indicates the date and time of the transaction. 32. The method according to p. 23, characterized in that it further comprises a step on which the subscriber indicates the conditions that must be implemented to complete the transaction. 33. The method according to item 23, wherein the identity initiates the generation of a digital signature of transaction data. 34. The method according to item 23, wherein the authentication initiates the encryption of transaction data. 35. The method according to p. 23, characterized in that it further comprises the step of selecting one data channel for sending transaction data over a wireless telephone network from several available channels. 36. The method according to clause 35, wherein the choice of a data transmission channel for sending transaction data is carried out taking into account at least one of the following parameters: type and capabilities of the mobile phone, current date and time, commands from the transaction processing platform , load of data transmission channels or network, priority level, amount of transaction data, presence or absence of data encryption. 37. The method according to clause 36 for processing financial transactions made by the owner of the financial transaction account (payer) in favor of another owner of the financial transaction account (payee), on the transaction processing platform, and comprising the following steps:
receive transaction orders data verified and sent from the payer's mobile phone or connected electronic device via a wireless telephone network,
analyze and compare this data with the state of the payer's financial transaction account and terms and conditions of use,
determine whether to authorize or cancel the transaction,
authorize or cancel the transaction,
execute a transaction, if authorized, debiting the transaction amount from the payer's financial transaction account and crediting the transaction amount to the financial transaction account of the payee,
or cancel the transaction and send the cancellation notice to the payer,
Log transaction details in the transaction log. 38. The method according to clause 37, wherein the transaction fee is deducted from the financial transaction account of the payer and / or payee. 39. The method according to § 38, wherein the transaction fee is paid to the telephone bill of the payer and / or payee. 40. The method according to § 38, characterized in that the payer is sent via a wireless network confirmation of the transaction. 41. The method according to § 38, wherein the payment is sent to the payee via a wireless network or the Internet transaction notification. 42. The method according to § 38, characterized in that upon receipt of the transaction order, a time stamp is added to the transaction data. 43. The method according to § 38, characterized in that each completed transaction is assigned a unique number. 44. The method according to § 38, wherein the decryption of the transaction order data and / or verification of the attached digital signature is performed using the corresponding key. 45. The method according to claim 38, characterized in that some data sent by the transaction processing platform to the owners of financial transaction accounts is encrypted and / or electronically signed. 46. The method according to item 45, wherein the public key infrastructure is used to encrypt / decrypt and / or generate / verify a digital signature.

Images