EA034122B1 - Method and system of performing transactions for money delivery in case of failures in the telecommunication channel of self-service device - Google Patents

Abstract

The technical solution in general relates to the field of data processing to carry out transactions in cash delivering when users interact with self-service machines (SSM), and in particular, to methods of transactions to deliver cash in case of failures in the communication channel of SSM. The method to perform transaction with respect to cash delivery in case of failures in the communication channel of a self-service machine (SSM) comprises the stages in which an initial user request for performing a transaction is received in the channel of SSM, then a transaction request containing at least the information about the type, amount, details and identifier of a transaction is generated and stored in the memory of SSM, after which the presence of a connection between a SSM and a remote server is checked, during such test an attempt to perform a transaction request of client is initiated; then, a failure in performing the above-mentioned transaction during an attempt of connection to the remote server is determined in the channel of SSM; information about receipt of a response from the remote server is received by the SSM; a second transaction request is generated on the basis of the data of initial transaction request and a second attempt to perform a transaction request is taken, the transaction is performed. The technical result is expansion of the functionality of SSM due to realization of the mechanism of guaranteed delivery of cash in case of failures in the channel of SSM.

Description

Technical field

The technical solution, in General, relates to the field of data processing for transactions on the delivery of funds (DS) in the interaction of users with self-service devices (CSS), and in particular, to methods of transactions for the delivery of DS in the event of failures in the communication channel of the CSS.

State of the art

Patent No. US 8108726 B2 is known from the prior art. B2 System and method for adaptive diagnostics of failures in a channel of an automated teller machine in a thin client mode, patent holder: Bank of America Corp, publication date: 01/31/2012. In this solution, adaptive diagnostics of failures in the channel of the automated banking machine is carried out during transactions for the delivery of DS. A feature of the solution is that the OS includes a thin client and adaptive diagnostics, which are carried out in the thin client mode. In this technical solution, if a malfunction occurs in the channel of the automated teller machine, the user is notified of the failure and the reason for the failure is indicated, as well as information about the closest operational automated teller machines. In addition, the address of the nearest location of a working ATM can be transmitted by the ATM in thin client mode to the user's mobile phone.

The prerequisites for the creation of the claimed technical solution are based on the need to implement an extended functionality mechanism when performing transactions for the delivery of DS in case of failures in the DC channel. The current drawback in the prior art is the lack of a mechanism for guaranteed delivery of DS when performing transactions for the delivery of DS in the event of failures in the US channel.

The essence of the technical solution

The claimed technical solution is aimed at solving the problem of creating a mechanism for guaranteed delivery of DS in case of failures in the US channel without re-authorization and without re-entering the transaction parameters.

The technical result of the claimed technical solution is to expand the functionality of the DC due to the implementation of the mechanism of guaranteed delivery of DS in case of failures in the channel of the DC.

An additional technical result that manifests itself in solving the above problem is to increase the reliability of the DC due to the guaranteed delivery of DS in case of failures in the channel of the DC.

Additionally, the number of customer requests is reduced in the implementation of this technical solution.

The technical result is achieved through the implementation of a method of guaranteed execution of a transaction for the delivery of DS in the event of a malfunction in the communication channel of the CA, in which the channel receives the US initial user request to complete the transaction for the delivery of DS;

generating and storing in the memory of the DC a transaction request containing at least information about the type of transaction, the amount of the transaction, the details of the transaction and the transaction identifier;

check the connection between the CA and the remote server, during which they initiate an attempt to complete the transaction request of the client;

determine in the channel US failed execution of said transaction when trying to communicate with a remote server;

receive information on the response from the remote server on the DC;

form a repeated transaction request based on the data of the initial transaction request and make a second attempt to complete the transaction request;

perform a transaction.

When implementing a technical solution in the event of a malfunction in the communication channel between the USB and the remote server, a timer is set that determines the amount of time to restore communication between the USB and the remote server.

When implementing a technical solution, the MAC MAC address is additionally taken into account when requesting a transaction.

When implementing a technical solution when a communication failure with the server is detected during the processing of the initial transaction request, a parameter of the time interval is formed for performing a repeated transaction request.

When implementing a technical solution within a given time parameter, a remote server is polled to activate a repeated request for a response to complete the transaction.

When implementing a technical solution within a given time parameter, an attempt is made to send a transaction request to a remote server, while taking into account the number of attempts to send a transaction request;

when receiving a response from a remote server, check the MAC of the transactional response, the number

- 1 034122 of the time required to restore communication between the DC and the remote server and the number of attempts to send a transaction request;

perform a user request.

When implementing a technical solution when generating a user request, the verification of the user is carried out.

When implementing a technical solution, verification is carried out using a PIN code, biometric information, graphic information or a user's remote device, or a combination thereof.

When implementing a technical solution, biometric information is a fingerprint, image of the retina, voice data, or a combination thereof.

When implementing a technical solution, the graphic image is a photo image of the user.

Also, the technical result is achieved due to the implementation of the system of guaranteed execution of a transaction for the delivery of DS in the event of a malfunction in the communication channel of the self-service device of the CA, which contains the CA and the associated remote server, and the CA is configured to receive a primary user request for a transaction for the delivery of DS;

save information about the received DS;

transmit transaction information to a remote server;

the remote server is configured to save transaction information of the received and delivered DS.

When implementing a technical solution, the DC is an ATM or information and payment terminal.

When implementing a technical solution, the control unit is connected to a remote server via a wired or wireless computer network.

When implementing a technical solution, a wired network is a LAN, WAN, PAN, or Intranet.

When implementing a technical solution, a wireless network is a WAN, Internet, WLAN, WMAN or GSM.

When implementing a technical solution, the remote server is a cloud server.

When implementing a technical solution, the CSS contains user verification tools.

When implementing a technical solution, the verification tools of the US are selected from the group: PINpad, touch display, camera, biometric scanner, microphone, or a combination thereof.

Brief Description of the Drawings

FIG. 1 illustrates the process of performing the claimed method;

FIG. 2 - the process of guaranteed delivery of DS in general;

FIG. 3 is a general view of a system implementing the method;

FIG. 4 - scheme of CSS;

FIG. 5 is a diagram of the server processing requests from the CSS.

Detailed description of the technical solution

Below will be described the concepts and definitions necessary for the detailed disclosure of the claimed technical solution.

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

Self-service banking device (CSS) - a software and hardware complex designed for the automated issuance and / or reception of cash DS both with and without payment cards, as well as other operations, including payment for goods and services, preparation of documents confirming corresponding operations. Banking self-service devices are divided into two types, depending on whether they support the function of issuing cash or not. If the function is supported, then the DC is an ATM (English automated teller machine), or an ATM, otherwise - NCS (non-cash systems), or a terminal for non-cash transactions.

Software (software) - a program or many programs used to control the CSS.

Previously, they can enable the guaranteed execution of a transaction for the delivery of DSs on the DC or turn off the standard means of configuration of the DC. Moreover, if the mode is off, the unit operates in full accordance with the NDC format.

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

Power Up - download;

Offline - there is no connection with the server, the connection is made;

Supervisor - a collector or service engineer is working;

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

In service - the main mode of operation of the CSS.

- 2 034122

In the In service mode, the device 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 type of state (indicated by the letters A..Z, as well as a..z and some characters (, '.?)), Which defines the population. The remaining 24 characters are 8 decimal 3-digit numbers, each of which is a specific state setting (screen number for display, conditions for switching to the state, list of actions). There can be any number of states of one 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 story, a request is formed from the data collected on past states and sent to the server. The request is a Logical Unit Number identifier, data from the card's tracks, data on previous transactions, data from the sum buffers, pin block, function key presses (FDK buffer). Data is separated by a delimiter character. The remote server receives the request and analyzes the FDK buffer - it is from the contents of this buffer that the remote server understands what the CSS wants. Then, depending on the decision made, it sends a response that contains the identifier of the action to be performed;

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

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

the state to which you need to go at the end of the action.

As shown in FIG. 1, the claimed method of guaranteed execution of a transaction for the delivery of DS in the event of a failure in the communication channel US (100) is initiated by receiving and processing an initial user request to complete a transaction for the delivery of DS (101).

The initial user request for the transaction can be generated in the memory of the US after the client selects a banking operation. The user can select a banking operation by using the graphical user interface (GUI) of the US. As a banking operation, cash dispensing or depositing funds to a bank card (request for crediting deposited funds) can be used.

The initial user request is formed using user interaction with the operating system, for example, an ATM or terminal for non-cash transactions. The initial user request contains at least information about the user's intention to carry out a transaction for the delivery of DS.

Upon receipt of the initial user request for the transaction in the system, a transaction request (102) is generated and stored in the memory of the system unit, which contains at least information about the type of transaction, the amount of the transaction, details of the transaction depending on the type of transaction and a unique transaction identifier (TrID) . In some embodiments, the transaction identifier is a numerical or symbolic value.

The TrID value must be unique for each transaction request (the TrID value is updated every time you switch to the transaction state in the US script). If the usual transaction request is received in a new format, the TrID field of the request is not empty, its value must be stored in the database of the remote server as part of the transaction data.

The TransactionID field is added to all transactional requests, for example, with identifier 3, consisting of 12 characters.

For the initial request, these fields are formed as follows: GMMDDHHMMINK (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 TransactionID values for this terminal).

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

After the transaction request (102) is generated and stored in the memory of the DC, the USB generates and sends a message containing the aforementioned transaction request containing at least information about the type of transaction, the amount of the transaction, transaction details and a unique transaction identifier to the remote server.

In the process of transmitting a message, the UE determines whether there is communication in the channel between the UE and the remote server and, in the event of a failure in the communication channel between the UE and the remote server, the UI offers the user to refuse to complete the transaction or continue the transaction in the guaranteed delivery mode of the DS.

In other embodiments, the implementation prompts the user to refuse to complete the transaction or to continue the transaction in the guaranteed delivery mode in the event of a timeout of the response of the remote server to the transaction message.

If it falls into state I, the system performs the following check.

If, from the moment of entering the client session, authorization requests have not been made, or requests have been made, but the guaranteed execution mode of a transaction for delivery of a call has not been activated by calling the special state f-032, the system generates a new transaction identifier (TrID).

- 3 034122

Additionally, the CA generates a TransactionRequest request in full accordance with the NDC format, supplementing it with a field, for example, with id = 3, containing this identifier.

If, from the moment of entering the client session, an authorization request has been made, and after it the mode of guaranteed execution of the transaction for the delivery of DS by calling the special state f-032 has been activated, the following is checked:

if all the parameters of the ready-to-send request match the parameters passed in the previous request, the CA generates a second request. At the same time, the current transaction identifier (TrID) is saved, but the MessageSubclass field, instead of the value 1 (Transaction Request Message), takes the special value D (Dublicate Transaction Request);

if at least one parameter of the ready-to-send request does not match the parameters passed in the previous request, it is considered that a new transaction has been started. The system generates a new transaction identifier (TrID) and generates a TransactionRequest request in full accordance with the NDC format, supplementing it with the field with id = 3 containing this identifier.

If communication errors and message format errors occur, the US switches from state I to the state number specified in Central Response TimeOut Next State.

If there is communication in the communication channel between the DC and the remote server and there are no failures in the process of transmitting information, the USB transmits a message containing a transaction request containing at least information about the type of transaction, the amount of the transaction, transaction details and a unique transaction identifier for the remote server using data from the original transactional message.

When processing a repeated request for the USB, repeated authorization on the card is not performed.

Sending a second request is controlled at the CSS scenario level. To enable / disable the processing of repeated requests on a remote server, a special module attribute is used. You can control the attribute using an SQL script or web form, while not introducing a web form is a stop factor for replicating the functionality of guaranteed delivery of DS to the entire network of CSS.

In this technical solution, the repeated request is ignored if the remote server sent a response to the original request. CSS sent a message confirming receipt of a response from a remote server.

In some embodiments, a second request is ignored if the remote server sends a response to the original CSS request that sent a message about switching to Supervisor Mode or a Power Up message.

In some embodiments, a re-request is ignored if the card numbers or transaction amounts, or transaction types (OPCODE buffer) in the original and re-requests are different.

In some embodiments, a re-request is ignored if a re-request format error occurs, including an empty TrID.

If you ignore the repeated request, the corresponding attribute is added to the database of the remote server of this CSS.

The remote server, having received from the DC a message containing a transaction request for DS delivery, checks the correctness of the information contained in the transaction request. The remote server checks the correctness of the specified transaction type, transaction details, a unique transaction identifier, and also whether there is enough DS on the account to deliver the DS.

In some embodiments, in the case of a response timeout of the remote server, the CA re-establishes a connection with the remote server according to the current network settings of the bank's CA.

Additionally, the remote server checks the MAC of the transaction request, as well as whether the request was previously processed.

If all of the specified parameters are correct, then the remote server generates and sends to the CA a transactional response indicating the delivery of the DS.

If the transactional response of the remote server to the original transactional message of the message has not been generated, the remote server completes the processing of the original message, and generates a response to the repeated transaction message from the message. The answer to the original message from the CSS is not formed. If, due to the peculiarities of parallelizing the processing of CSS requests on a remote server, both the response to the original request and to the repeated request will be sent to the CSS, this situation is not an error. CSS should ignore the response to the original request, because at the time of the formation of the repeated request, the current MCN and TVN values of the transaction have changed.

If the response of the remote server to the original transactional message of the CA was generated, a response to the repeated message is generated on its basis, and no new authorizations are made on the card.

The message will have new values TVN and MCN from the repeated request of the CSS.

In FIG. 2 shows the principle of operation of the mechanism for guaranteed delivery of DS (200). When a failure is detected in the communication channel between the DC and the remote server (201), the USB starts the guaranteed delivery mode of the DS. In this mode, the user agent sets a timer that determines the amount of time to restore communication between the user agent and the remote server, sets the time interval for executing a repeated transaction request (202).

The DC during a given time parameter polls the remote server to activate a repeated request for a response to complete the transaction and attempts to send a transaction request to a remote server, taking into account the number of attempts to send a transaction request (203).

The state also allows you to limit the maximum number of repeated requests for a response to complete a transaction. In the process of its implementation, the following checks can be carried out.

If the DC with the guaranteed mode of execution of the transaction for the delivery of the DS is turned off in the state f-032, then the processing is carried out similarly to the case when the maximum number of repeated requests is exceeded (the end of the client session due to a technical failure is assumed).

If the number of attempts to conduct repeated requests is equal to or exceeds the maximum specified in article f-032, the end of the client session is carried out due to a technical failure.

If the number of attempts to conduct repeated requests is less than the maximum set in the state, then the attempt counter increases and the CA switches to Next State.

If the limit of the number of repeated requests is not exceeded, the unit will go to the dialogue with the client by the state number specified in the Next State field of the state f-032, which implies confirmation of the repeated request to the remote server. This dialogue is organized by standard NDC tools.

If the request is confirmed, then control should be transferred to state I. It is very important that between the end of the previous state I on the Central Response TimeOut Next State branch and the call of the new state I, the contents of the transaction request remains unchanged.

Upon receipt of the transactional response (204) from the remote server, the MAC of the transactional response is checked, the amount of time it took to restore communication between the DC and the remote server and the number of attempts to send the transaction request and, if all the data is correct, execute the user request.

As shown in FIG. 3, the general principle of the operation of the transaction delivery system for DS delivery is carried out when processing user requests generated in the US channel (300) and their subsequent transmission over the network (500) to the remote server (400) using the method (100) described above.

In FIG. 4 shows the general scheme of the CSS (300) in the form of an ATM or terminal for non-cash transactions. The control unit (300) contains bus-connected components, such as a processor (301), memory (302), a network interaction tool (303), a display (304), controls (305), and a dispenser for issuing a DS (306). Additionally, a DS receiving means (307) may also be used.

The US processor (301) performs all the necessary computational operations when processing transactional requests. The memory (302) may represent one or more devices of various types, such as RAM, ROM, or a combination thereof. As ROM can be used HDD, SSD drives, flash memory, etc. The memory (302), as a rule, stores the program logic executed by the processor (301), which is necessary to implement the CSS (300) operation method, 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 communicate 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, communication tools between the CSS (300) and the user (user device) can be used, for example, Bluetooth transceiver, NFC module, IrDa, etc.

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

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

The dispenser DS (306) is a dispenser. Dispenser (306) can be of various types, for example, friction or vacuum.

Additionally, CSS (300) may include means for receiving DS (307) from the user.

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

In some embodiments of the technical solution, two-factor verification of the user using a camera or biometric sensors, such as a fingerprint scanner, retina or using voice analysis of the user, can be applied. Using the camera, the image of the user of US (300) can be captured for subsequent processing and comparison with the reference identifying information of the account holder when initiating a transaction in US (300).

US (300) can also provide for the exchange of identification information in a completely non-contact mode, using a pre-created identification token using a user device, such as a smartphone, tablet or laptop, and its subsequent transmission via a wireless data exchange channel, for example, Bluetooth, Wi-Fi, NFC, RFID, etc., in CSS (300).

In 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 received in the channel US (300). Also, the server (400) implements a mechanism for guaranteed DS delivery in case of failures in the DC channel without re-authorization and without re-entering the transaction parameters.

In general, the server (400) contains components such as: at least one processor (401), at least one memory (402), data storage means (403), input / output interfaces (404), network interaction means ( 405).

The processor (401) of the server performs basic computational operations when it works 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 mechanism for guaranteed delivery of DS and other program logic that provides full functionality of the server (400).

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

Interfaces (404) are standard tools 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 execution of the server (400), which can be a personal computer, mainframe, server cluster, thin client, etc.

Network communication tools (405) are selected from devices that provide network reception and data transfer, for example, an Ethernet card, WLAN / Wi-Fi module, Bluetooth module, BLE module, NFC module, IrDa, RFID module, GSM modem, etc. Using means (405), the organization of data exchange between the server (400) and the USB (300) is provided via a wired or wireless data channel, for example, WAN, PAN, LAN, Intranet, Internet, WLAN, WMAN or GSM.

Additionally, the server (400) may include data input / output means, for example, a keyboard, joystick, display (touch screen), projector, touchpad, pointing device, computer mouse, trackball, light pen, speakers, microphone, etc.

The application materials presented the preferred disclosure of the implementation of the claimed technical solution, which should not be used as limiting other, private embodiments of its implementation, which do not go beyond the requested scope of legal protection and are obvious to specialists in the relevant field of technology.

Claims (16)

CLAIM 1. A method of guaranteed execution of a transaction for the delivery of funds (DS) in the event of a malfunction in the communication channel of a self-service device (CS), which includes the steps of receiving a primary user request to complete a transaction in the channel (CS); generating and storing in the memory of the DC a transaction request containing at least information about the type of transaction, the amount of the transaction, the details of the transaction and the transaction identifier; check the connection between the CA and the remote server, during which they initiate an attempt to complete the transaction request of the client; determining in the UE channel the failure of said transaction when trying to communicate with a remote server, and when the mentioned communication failure with the remote server is detected during the processing of the initial transaction request, a time interval parameter is generated for performing the repeated transaction request, during which the remote server is polled to activate the repeated request receiving a response to complete a transaction; receive information on the response from the remote server on the DC; form a repeated transaction request based on the data of the initial transaction request and make a second attempt to complete the transaction request; perform a transaction. 2. The method according to claim 1, characterized in that when a failure occurs in the communication channel between the CA and the remote server, a timer is set that determines the amount of time to restore communication between the US and the remote server. 3. The method according to claim 1, characterized in that it additionally takes into account the MAC address of the DC when requesting to complete a transaction. - 6 034122 4. The method according to claim 1, characterized in that during a given parameter of the time interval, an attempt is made to send a transaction request to a remote server, taking into account the number of attempts to send a transaction request; when receiving a response from a remote server, check the MAC of the transactional response, the amount of time it took to restore communication between the DC and the remote server, and the number of attempts to send a transaction request; perform a user request. 5. The method according to claim 1, characterized in that during the formation of the initial user request, the verification of the user is carried out. 6. The method according to claim 5, characterized in that the verification is carried out using a PIN code, biometric information, graphic information, a remote user device, or a combination thereof. 7. The method according to claim 6, characterized in that the biometric information is a fingerprint, an image of the retina, voice data, or a combination thereof. 8. The method according to claim 7, characterized in that the graphic image is a photo image of the user. 9. A system for guaranteed execution of a transaction for the delivery of funds (DS) in the event of a malfunction in the communication channel of a self-service device (CSS), containing the CSS and a remote server associated with it, in which CSS is configured to receive in its channel a primary user request for a transaction; generating and storing in the memory of the DC a transaction request containing at least information about the type of transaction, the amount of the transaction, the details of the transaction and the transaction identifier; checking the connection between the DC and the remote server, during which an attempt to execute a client transaction request is initiated; determining in the CSS channel a failure to complete the said transaction when trying to communicate with a remote server, moreover, when the mentioned communication failure with the remote server is detected during processing of the initial transaction request, a time interval parameter is generated for performing the repeated transaction request; polling the remote server for the said time period to activate a repeated request for a response to complete the transaction; receiving a response from the remote server during the survey; generating a repeated transaction request based on the data of the initial transaction request and making a second attempt to execute the transaction request; the remote server is configured to process the transaction upon receipt of a repeated transaction request from the CA. 10. The system according to claim 9, characterized in that the CS is an ATM. 11. The system according to claim 9, characterized in that the CSS is connected to a remote server via a wired or wireless computer network. 12. The system according to claim 9, characterized in that the wired network is a LAN (WAN), WAN, PAN or Intranet. 13. The system according to claim 9, characterized in that the wireless network is a WAN, Internet, WLAN, WMAN or GSM. 14. The system according to claim 9, characterized in that the remote server is a cloud server. 15. The system according to claim 9, characterized in that the CSS contains means for verifying the user. 16. The system according to claim 9, characterized in that the verification means of the US are selected from the group: PIN pad, touch screen, camera, biometric scanner, microphone, or a combination thereof.