EA038252B1 - Method for automatically crediting deposited money funds in case of failures - Google Patents

Abstract

The technical solution, in general, relates to the field of data processing for transactions on depositing money funds (MF) in interaction of users with self-service machines (SSM), and in particular, to methods of performance of transactions on depositing MF in case of various failures in the channel of SSM when exchanging data with a transaction processing server. The technical result is in expansion of the SSM functionality by implementation of the mechanism for automatic processing of transaction requests in case of problems occurring in the channel of a SSM during exchange of data with a transaction processing server. The preferred option of performance of the claimed solving of the problem presents the method of automatic crediting of money funds (MF) in case of failures, which includes the following steps: receiving, in the channel of a self-service machine (SSM), a user request for execution of a transaction for acceptance of MF, which contains transaction parameters; sending a preliminary transaction request to a remote server for verification of the transaction parameters; receiving a response from the server and saving it in the SSM; initiating acceptance of the MF by a SSM according to the transaction parameters; recording, during acceptance, the data about the MF being accepted; recording, with the aid of the SSM, the occurrence of a failure in sending the data for execution of a transaction; transmitting the data to remote server, and saving the transaction parameters; automatically initiating a interrogation to remote server from the SSM; and, upon receipt of a response from the remote server, transmitting the mentioned saved transaction parameters to the above server for its execution.

Description

Technology area

The present invention generally relates to the field of data processing for the implementation of transactions for depositing funds (DS) when users interact with self-service devices (CS), and in particular to methods of performing transactions for depositing DS in the event of various failures in the CS channel when exchanging data with a transaction processing server.

State of the art

A system and method for adaptive diagnostics of failures in a CD channel in a thin client mode is known from the prior art (patent US8108726B2, 01/31/2012, Bank of America Corporation). In this solution, adaptive diagnostics of failures in the RS channel is carried out during the implementation of transactions for the introduction of the DS. A feature of the solution is that the RS includes a thin client and adaptive diagnostics is carried out in the thin client mode. In this solution, in the event of failures in the RS channel, the user is informed about the failure and the reason for the failure is indicated, as well as information about the nearest serviceable RS is given. In addition, the CD can coordinate information about the nearest good CD through the user's mobile phone.

Also known is a system and method for detecting failures in an ATM (application US 2007131757 A1, 14.06.2007, NCR Corporation). In this solution, when carrying out transactions, including transactions for entering the DS, a transaction log is generated, in which all information about the transaction is recorded. Communication is established between the ATM and the computer. The transaction log is generated in XML-based format. In the event of a failure, the transaction is performed based on the transaction information contained in the transaction log.

The background of the claimed invention is based on the need to implement a mechanism of extended functionality when performing transactions for the introduction of DS in the event of various failures. The current drawback in the prior art is the lack of a mechanism that provides automatic enrollment of the entered DS in the event of various failures, which in turn also reduces the time for performing transaction operations using the CA.

Disclosure of invention

The technical problem solved by the claimed invention is to create an effective method and system for automated processing of transactions in the channel of the US in the event of failures of a different nature that lead to delays or refusal to process transactional operations.

The technical result is the expansion of the RS functionality by implementing a mechanism for automated processing of transactional requests in the event of problems in the RS channel when exchanging data with the transaction processing server.

An additional technical result is also an increase in the reliability of processing transactional operations due to the work of internal scripts of the RS, as well as reducing the time for executing transactional requests in the event of failures in the channel of the RS.

In a preferred embodiment of the invention, a method for automatically crediting deposited funds in the event of failures is presented, comprising the steps of receiving in a channel of a self-service device a user request for a transaction to receive a DS containing transaction parameters;

send a preliminary transaction request to the remote server to verify the parameters of the transaction;

receive a response from the server and save it in the US;

initiate the reception of the DC DS according to the parameters of the transaction;

during the reception, the data of the received DS are recorded;

using the CD, the occurrence of a failure to send data to complete a transaction is recorded, the data is transmitted to a remote server, and the parameters of the transaction are saved;

automatically initiate polling of the remote CS server and, upon receiving a response from the remote server, transmit said stored transaction parameters to said server for its execution.

In one of the particular embodiments of the method, when generating a user request, the user of the RS is verified.

In another particular embodiment of the method, verification is performed using a PIN-code, biometric information, graphic information, or a remote user's device, or a combination thereof.

In another particular embodiment of the method, the biometric information is a fingerprint, an image of the retina, voice data, or a combination thereof.

In another particular embodiment of the method, the graphic image is a photographic image of the user.

In another particular embodiment of the method, the data of the received DS is a currency code, the denomination of a currency, the number of monetary units received by the RS, or breakdown data

- 1,038,252 banknotes by groups.

The invention is preferably carried out by means of a system for automatically enrolling the entered DS in the event of failures, which contains the CD and a remote server associated with it, and the CD is configured to receive a user request to perform a transaction to receive the DS;

save information about the received DS;

transfer information about the transaction to a remote server;

the remote server is configured to check the parameters of the transaction received from the RS;

save information about the transaction and received DS and automatically execute the transaction in the event of a failure in the data transmission channel between the RS and the remote server.

In a particular implementation of the system, the RS is an ATM or terminal.

In another particular implementation of the system, the CD is connected to a remote server via a wired or wireless computer network.

In another particular implementation of the system, the wired network is a LAN, WAN, PAN, or Intranet.

In another particular implementation c, the wireless network is WAN, Internet, WLAN, WMAN, or GSM.

In another particular implementation of the system, the remote server is a cloud server.

In another particular implementation, the CD contains means for verifying the user.

In another particular embodiment of the system, the means for verifying the RS are selected from the group: PIN-pad, touchscreen display, camera, biometric scanner, microphone, or their combinations.

Brief Description of Drawings

Features and advantages of the present invention will become apparent from the following detailed description of the invention and the accompanying drawings, in which: FIG. 1 and 2 illustrate a block diagram of the claimed method;

fig. 3 illustrates an example of a data exchange system between a CD and a remote server;

fig. 4 illustrates an example of a CA circuit;

fig. 5 illustrates an example of a remote server diagram.

Implementation of the invention

In the present description, the following terms and definitions will be used.

In this invention, the system means, among other things, a computer system, a computer (electronic computer), a CNC (numerical control), a PLC (programmable logic controller), computerized control systems and any other devices capable of performing a given, well-defined sequence of operations. (actions, instructions).

A command processing device means an electronic unit or an integrated circuit (microprocessor) that executes machine instructions (programs).

A command processor reads and executes machine instructions (programs) from one or more storage devices. The role of data storage devices can be, but are not limited to, hard disks (HDD), flash memory, ROM (read only memory), solid state drives (SSD), optical drives.

TSN (Transaction Serial Number) - the number of the last successfully completed transaction.

NDC protocol (NCR Direct Protocol) is a protocol for data exchange between the US and the transaction processing server.

Cash (DS) is a specific product with the highest liquidity, serving as a measure of the value of other goods and services.

A self-service banking device (CS) is a software and hardware complex designed for automated issuance and / or acceptance of cash by DS both using payment cards and without, as well as performing other operations, including payment for goods and services, drawing up documents confirming corresponding operations. Self-service banking devices are classified into two types depending on whether they support a cash dispensing function or not. If the function is supported, then the CS is an ATM (automated teller machine), or an ATM, otherwise - NCS (non-cash systems), or a terminal for non-cash transactions.

Software (software) or program logic is a program or a set of programs used to control the RS and server facilities to carry out the required operations.

FIG. 1 shows the main steps of the claimed method for the automated introduction of DS (100). At the first stage (101), the RS receives a request from the user to perform a financial transaction to deposit the DS.

The request contains, as a rule, the ID of the account crediting the DS, the amount of the DS, the start time

- 2 038252 requests to perform an operation. The request also contains a Transactional Request Identifier (TrID).

The request may additionally contain the ID (Logical Unit Number), data from the map tracks, data on previous transactions, data from the sum buffers, pin-block, keystrokes (FDK buffer).

The TrID value is unique for each transactional request (the TrID value is updated with each transition to a transactional state in a CA scenario). If a normal transactional request is received in a new format, the TrID field of the request is not empty, its value is stored in the database of the remote server as part of the transactional data of the operations performed.

All transactional requests add a TrID field, for example, ID 3, which is 12 characters long.

For the initial request, these fields are formed as follows: HMMDDHHMMNNN (where G is the last digit of the current year, MM is the month number, DD is the day, HH is the hour, MM is the minute, NNN is the last 3 digits of the current Accumulated Transaction Count value, which ensures uniqueness the TrID value for the given CS). The Accumulated Transaction Count value determines the total number of detected attempts to execute transactions since the installation of the CD or after the non-volatile memory of the CD is completely occupied. The counter resets to 0 after 9999999 transactions.

For a repeated request, the TrID field value must repeat the value generated at the time of the initial request.

At each moment of time, the control system is in one of the following operating modes:

Power Up - loading;

Offline - there is no connection with the server, connection is in progress;

Supervisor - a collector or service engineer is working;

Out of service - the RS does not work due to a malfunction, the exhaustion of funds or the forced transfer of the RS to the specified mode;

In service - the main operating mode of the CS.

In the In service mode, the control system is in one of the states (state), with a number from 001 to 999, and a 25-character description string.

The first character of this line is the state type (denoted by the letters A..Z, as well as a..z and some characters (, '.?)), Which defines the collection. The remaining 24 characters are 8 decimal 3-digit numbers, each of which is a specific state setting (screen number to display, conditions for moving to a state, a list of actions). There can be any number of states of the same type.

Passing through all these states, sooner or later they reach the state of interaction with the remote server - state I (Transaction Request State). On this state, a request is formed from the data collected in previous states and sent to the server. The data is separated by a delimiter character. The remote server receives the request and analyzes the FDK buffer - it is by the contents of this buffer that the remote server determines the necessary operations, the execution of which is requested by the RS. Then, depending on the decision made, it sends a response, which contains the identifier of the action to be performed;

the number of the screen to be shown during this action;

the contents of the check, if the check needs to be printed;

the state to which you want to go after the completion of the action.

After the RS fixes the received DS amount, the following data is determined and saved:

the amount of accepted banknotes;

currency code;

the number of accepted banknotes by type.

The transactional operation data indicated at step (101) is processed by the DC logic (102) and generated for transmission to a remote server for performing the transaction (103).

As shown in FIG. 2, after receiving the DS RS and writing the parameters of the DS sum, the RS logic generates a preliminary transaction request for sending to the server (201).

The entry of the DS into the RS is carried out on a purchase basis and the fixation of the DS data is performed when the DS is received by the cash acceptance module (MPN). MNT can be performed by Escrow type (preliminary deposit of bills).

The generated preliminary request is sent to the server (202) after entering a certain amount of DS. This can occur after processing the parameters of each bill, or after receiving several bills, or after receiving the entire amount of the DS specified in the transaction request at step (101).

This stage allows you to pre-check the stability and operability of the data transmission channel between the US and the server for performing transactions.

The server, in response to receiving data from the US (203) with the current state of the transaction, stores the received parameters. The transaction parameters are also stored in the memory of the DC.

- 3 038252

The server at step (203) also sends a response message confirming the presence of a communication channel suitable for performing a further transaction.

Returning to FIG. 1, in step (104), a communication link check is performed to effect the required transaction entered in step (101).

If communication with the server is present and the RS has received the entire required amount of DS to complete the transaction request, then the transaction data is sent to the server, where it is processed and transferred to the account specified in the request (step 108).

In the case when at step (104) the CD does not receive a response from the server, then the logic of the CD saves the transaction parameters at the time of the absence of a response from the server (105) and activates the program mechanism of the script for automatic crediting of funds (106).

When performing stage (106), as mentioned above, the RS sends and stores the parameters of the preliminary request, which contains the TSN parameter and the parameters of the received response from the server (Transaction Reply) to the request with the corresponding TSN, and the said request is the last one before fixing the presence of a failure in data transmission channel between the US and the server. The execution of step (106) is carried out until a response is received from the server, which makes it possible, without user intervention, to execute a transaction request based on the account identifier received in step (101) to which the DS is to be transferred.

The execution of the stage (106) of activating the automated execution of the transaction is carried out, in particular, if the DC did not receive a response (Transaction Reply) from the server (for example, disconnection of the network connection, power outage of the DC), or could not correctly parse the server response, or an error occurred in the MAC check. transaction signatures. To protect the integrity of the technical solution, a mechanism for makling a transaction with a MAC address is used. To calculate and check the MAC address, a command is used, to the input of which data is supplied, which can change depending on the settings:

a way of calculating MAC, for example, by means of ANSI X9.19;

the type of key used to encrypt the hash, for example ZAK / TAK (it should be possible to select the type of key);

the data on which the hash is calculated (message fields marked with a '6' in the xsd-scheme).

The MAC key must be unique for each CA, and the control of uniqueness is carried out on the server side. When you try to enter a duplicate key into a web form, a mismatch warning should appear.

TSN values at the last attempt to execute a transaction, the amount of accepted banknotes, currency code, the number of accepted banknotes with a breakdown by type at the time of TSN fixing do not change. This information is used for subsequent authorization requests until a correct response is received from the server. This makes it possible to carry out valid processing of the transactional procedure in an automated manner.

The server, for its part, can initiate the sending of current counters by a specialized command, in particular, Send supply counters. If the value of the amount of previously accepted banknotes is greater than zero, then, along with the information provided by the NDC protocol, information with the following values will be sent to the server from the RS: the amount of accepted banknotes, currency code, the number of accepted banknotes, broken down by type. This data is also used to perform a transactional operation after the restoration of the communication channel with the server.

The table below shows an example of data stored in the part of identifying the amount of deposited DCs and confirmed in the received response from the server. The above table shows an example of depositing 1,750 rubles into the RS.

Parameters of the entered DS

Serial number of the bill Denomination Counter of accepted bills 01 RUB10AB 0 02 RUB50AB 1 03 RUB100AB 2 04 RUB500AB 1 05 RUB1000A 1 06 RUB5000A 0

As shown in FIG. 3, the general principle of operation of the claimed method (100) is carried out using a transaction execution system, which is implemented by processing user requests generated in the US channel (300) and their subsequent transmission over a computer network (500) to a remote server (400).

The network (500) can be wired or wireless, for example, Internet, Intranet, LAN, WAN, WLAN, GSM, GPRS, Wi-Fi, etc. FIG. 4 shows a general diagram of the US (300) in the form of an ATM or a payment terminal. US (300) contains components combined by means of a universal bus (310), such as a processor (301), memory (302), a means of network interaction (303), a display (304), controls (305), a means of issuing a DS (306 ) (in the case of an ATM), a means of receiving DS

- 4 038252 (307). The US processor (301) performs all the necessary computational operations when processing transactional requests. Memory (302) can represent one or more devices of different types, such as: RAM, ROM, or combinations thereof. HDD, SSD disks, flash memory, etc. can be used as ROM. The memory (302), as a rule, stores the program logic executed by the processor (301), which is necessary to implement the method of operation of the US (300), and the operating system that organizes the interaction interface and data processing protocols.

As a means of network interaction (303), devices can be used that provide communication with a remote server using a wired or wireless type of communication, for example, an Ethernet card (LAN), a Wi-Fi module, a GSM modem (2G, 3G, 4G, 5G) and etc. Additionally, the means of data exchange between the US (300) and the user (user's device) can be used, for example, a Bluetooth transceiver, NFC module, IrDa, etc.

The US display (304) serves to display a graphical user interface, as well as when it is executed in the form of a touchscreen display, it also provides interaction with the user and receiving control commands from him.

Controls US (305) can be a keyboard, touch display, pin-pad, mechanical and touch buttons.

The DS dispenser (306) is a dispenser. The dispenser (306) can be of various types, such as vacuum, spray type, and the like. Additionally, the CD (300) may comprise means for receiving the DS (307) from a user.

Also, US (300) may contain a bank card reader, a camera, one or more biometric sensors, and a microphone. These devices, both individually and in aggregate, can be used to identify and verify a user. The user can identify the beginning of the transaction request by presenting a bank card to a special US reader (300) and entering a pin code using a keyboard (305) or touch screen (304).

Two-factor user verification can be applied using a camera or biometric sensors, for example, a fingerprint scanner, retina, or by analyzing the user's voice. With the help of the camera, it can capture the user's image of the US (300) for subsequent processing and comparison with the reference identifying information of the account holder when initiating a transaction operation in the US (300).

US (300) can also provide the exchange of identification information in a completely contactless mode, using a pre-created identification token using a user device, for example, a smartphone, tablet or laptop, and its subsequent transmission over a wireless channel of information exchange, for example, Bluetooth, Wi- Fi, NFC, RFID, etc., in US (300) (as an example, this technology is disclosed in the sources US 20110238573, US 20110066552).

To enhance the mode of safe execution of a transaction in the channel US (300), a re-execution counter can be used, which, upon reaching a predetermined threshold, will notify the user that a response from the server (400) has not yet been received and that information about the execution of the transaction request will be sent to the user via its implementation. Data transfer to the user's device, for example, a smartphone or tablet, is carried out using standard means and methods, such as: SMS messages, PUSH notifications, e-mail messages, etc. The predetermined method of notifying the user is selected based on the identification information associated with the user's account, for example, his phone number, card number or biometric information. FIG. 5 shows a general diagram of a remote server (400).

The server (400) is designed to process requests for the execution of transactional requests for enrollment of DSs arriving in the US channel (300). In general, the server (400) contains such components as: one or more processors (401), at least one memory (402), data storage (403), input / output interfaces (404), means of networking (405 ).

The server processor (401) performs the main computational operations when it is working with the US (300). The processor (401) executes the necessary computer readable instructions contained in the memory (402).

Memory (402), as a rule, is made in the form of RAM and contains the necessary logic of the operating system, the reverse mechanism and other program logic that provides the full functionality of the server (400).

The data storage medium (403) can be performed in the form of HDD, SSD disks, array raid, flash memory, optical information storage devices (CD, DVD, MD, Blue-Ray disks), etc. Means (403) allow performing long-term storage of various types of information, for example, the history of processing transactional requests (logs), user identifiers, etc.

Interfaces (404) are standard means for connecting and working with a server (400), for example, USB, RS232, RJ45, LPT, COM, HDMI, PS / 2, Lightning, FireWire, etc.

The choice of interfaces (404) depends on the specific implementation of the server (400), which can be a personal computer, mainframe, server cluster, thin client, etc.

Networking tools (405) are selected from devices that provide network reception and transmission of data, for example, Ethernet card, WLAN / Wi-Fi module, Bluetooth module, BLE module, NFC

- 5 038252 module, IrDa, RFID module, GSM modem, etc. With the help of the means (405), the organization of data exchange between the server (400) and the US (300) is provided via a wired or wireless data transmission channel, for example, WAN, PAN, LAN, Intranet, Internet, WLAN, WMAN or GSM.

Additionally, the server (400) may contain I / O data means such as a keyboard, joystick, display (touchscreen display), projector, touchpad, mouse, trackball, light pen, speakers, microphone, and the like.

In the present materials, the preferred disclosure of the implementation of the claimed invention has been presented, which should not be used as limiting other, particular embodiments of its implementation, which do not go beyond the scope of the claimed scope of legal protection and are obvious to specialists in the relevant field of technology.

Claims (14)

CLAIM 1. A method for automatically crediting deposited funds (DS) in the event of failures, carried out by a processor, including the steps at which a user request to execute a transaction for receiving DS is received in the channel of a self-service device (CS), containing transaction parameters; sending a preliminary transaction request to the remote server to check the parameters of the transaction, which includes the identifier of the user account; receive a response from the server and store it in the CA; initiate the reception of the DS DS according to the parameters of the transaction; during the reception, the data of the received DS are fixed; transmit data to a remote server, record the failure of sending data to execute a transaction using the DC, and store the transaction parameters in the DC memory; the script of automatic funds crediting is activated, which ensures, without the participation of the user, the execution of the transaction request based on the mentioned identifier of the user account; automatically initiate interrogation of the remote server CD and so on, and receiving a response from the remote server, transmit the said stored transaction parameters to the said server for its execution; the DS is credited to the specified user account. 2. The method according to claim 1, characterized in that when the user request is generated, the RS user is verified. 3. The method according to claim 2, characterized in that the verification is carried out using a PIN-code, biometric information, graphic information, or a remote user's device, or a combination thereof. 4. The method according to claim 2, characterized in that the biometric information is a fingerprint, an image of the retina, voice data, or a combination thereof. 5. The method according to claim 2, characterized in that the graphic image is a photographic image of the user. 6. The method according to claim 1, characterized in that the data of the received DS is a currency code, the denomination of a currency, the number of accepted currency units, or the data of a breakdown of banknotes into groups. 7. The system of automatic crediting of the deposited funds in the event of failures, containing the RS and the associated remote server, and The CD is configured to receive a user request to execute a transaction to receive the DS, the request containing transaction parameters including at least an identifier of the user account; save information about the received DS; transmit information about the transaction to the remote server, and in case of failure to send data to complete the transaction to the remote server, activate the script for automatic crediting of funds, which allows you to execute a transaction request without user intervention based on the specified user account identifier; automatically initiate polling of the remote server; upon receiving a response from the remote server, transmit said stored transaction parameters to said server for its execution; the remote server is configured to check the parameters of the transaction received from the RS; save information about the transaction and received DS; to carry out automatic execution of the transaction in case of failure detection in the data transmission channel between the RS and the remote server, and - 6 038252 credit the DS to the specified user account. 8. The system of claim 7, wherein the CS is an ATM or terminal. 9. The system according to claim 7, characterized in that the CD is connected to a remote server via a wired or wireless computer network. 10. The system of claim 7, wherein the wired network is a LAN, WAN, PAN, or Intranet. 11. The system of claim 7, wherein the wireless network is WAN, Internet, WLAN, WMAN, or GSM. 12. The system of claim 7, wherein the remote server is a cloud server. 13. The system according to claim 7, characterized in that the RS contains user verification means. 14. The system according to claim 7, characterized in that the means of verification of the US are selected from the group: PIN-pad, touch display, camera, biometric scanner, microphone, or their combinations.