WO2019112471A1

WO2019112471A1 - Performing transactions in the event of failures in a connection channel of a self-service machine

Info

Publication number: WO2019112471A1
Application number: PCT/RU2017/000987
Authority: WO
Inventors: Валерий Валерьевич ТОЛКАЧЕВ; Сергей Юрьевич САЕНКО; Дмитрий Борисович ЕМЕЛЬЯНОВ; Михаил Алексеевич КОНДРАТЬЕВ; Алексей Сергеевич АСКЕРКО; Александр Сергеевич СЫСУЕВ; Денис Васильевич ТОПЧАК
Original assignee: Публичное Акционерное Общество "Сбербанк России"
Priority date: 2017-12-04
Filing date: 2017-12-27
Publication date: 2019-06-13
Also published as: EA201700603A1; RU2673982C1; EA034122B1

Abstract

The invention relates to the field of processing data for carrying out transactions with respect to delivering monetary funds upon interaction of users with self-service machines. A method for performing a transaction with respect to monetary funds in the event of failures in a connection channel of a self-service machine comprises stages in which an initial user request for performing a transaction is received in a channel of the self-service machine, a transaction request containing information about the type, amount, details and identifier of the transaction is then generated and stored in the memory of the self-service machine, after which the availability of a connection between the self-service machine and a remote server is checked, during the course of which an attempt to perform the transaction request of the client is initiated, and a failure in performing the above-mentioned transaction during an attempt of connection to the remote server is determined in the channel of the self-service machine. Furthermore, information about receipt of a response from the remote server is received in the self-service machine, a second transaction request is generated on the basis of the data of the initial transaction request and a second attempt to perform the transaction request is carried out, and then the transaction is performed.

Description

IMPLEMENTATION OF TRANSACTIONS IN CREATION OF FAILURES IN THE COMMUNICATION CHANNEL

SELF-SERVICE DEVICES

TECHNICAL FIELD

[1] This technical solution, in general, relates to the field of data processing for the implementation of cash delivery (DS) transactions when users interact with self-service devices (CS), and in particular, to methods of conducting DS delivery transactions when a failure occurs communication channel US

BACKGROUND

[2] The patent N ° US8108726B2 "System and method for adaptive diagnostics of failures in the ATM channel in the thin client mode" is known from the state of the art, patentee: Bank of America Согр, publication date: 31.01.2012. In this solution, adaptive diagnostics of failures in the channel of the automated banking machine are carried out when carrying out transactions for the delivery of DS. A feature of the solution is that the CSS includes a thin client and adaptive diagnostics, which is carried out in the thin client mode. In this technical solution, if there are failures in the channel of the automated banking machine, the user is informed about the failure and indicates the cause of the failure, and also gives information about the nearest operational automatic banking machines. In addition, the address of the nearest location of an operational ATM can be transferred by the ATM in thin client mode to the user's mobile phone.

[3] The prerequisites for creating the claimed technical solution are based on the need to implement the extended functionality mechanism when performing DS delivery transactions in the event of faults in the CSS channel. The current deficiency in the level of technology is the lack of a mechanism for guaranteed delivery of DS when performing transactions for delivery of DS in the event of failures in the CSS channel. ESSENCE OF TECHNICAL SOLUTION

[4] The claimed technical solution is aimed at solving the problem of creating a mechanism for guaranteed delivery of DS in the event of errors in the channel of the CS without re-authorization and without re-entering the parameters of the transaction.

[5] The technical result of the claimed technical solution is the extension of the functional capabilities of the CB, due to the implementation of the mechanism of guaranteed delivery of the DS in the event of malfunctions in the CSS channel.

[6] An additional technical result, manifested when solving the above task, is to increase the reliability of the CSS operation by implementing a guaranteed delivery of the DS in the event of failures in the CSS channel.

[7] Additionally, the number of customer inquiries in the implementation of this technical solution is reduced.

[8] The technical result is achieved due to the implementation of the method of guaranteed performance of the transaction for the delivery of DS in the event of a failure in the communication channel CSS, in which

- receive in the channel CSS primary user request to perform a transaction for the delivery of DS;

- form and save in the memory of the US transaction request containing at least information about the type of transaction, transaction amount, transaction details and transaction identifier;

- check the connection between the CSS and the remote server, during which they initiate an attempt to perform a transactional client request;

- it is determined in the channel of the USB that the execution of the mentioned transaction fails while trying to communicate with the remote server;

- receive on the US information about receiving a response from a remote server;

- form a repeated transactional request based on the data of the primary transactional request and re-attempt the execution of the transactional request;

- perform a transaction.

[9] When implementing a technical solution, if a failure occurs in the communication channel between the CSS and the remote server, a timer is set, determines the amount of time to restore communication between the CSS and the remote server.

[10] When implementing a technical solution, the MAC address of the US is additionally taken into account when requesting a transaction.

[11] When implementing a technical solution, when a failure in communication with the server is detected during the processing of a primary transactional request, a time interval parameter is generated for performing a repeated transactional request.

[12] When implementing a technical solution, a remote server is polled for a specified time parameter to activate a re-request for a response to complete the transaction.

[13] When implementing a technical solution, within a specified time parameter, an attempt is made to send a transactional request to a remote server, taking into account the number of attempts to send a transactional request;

[14] - 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 CA and the remote server, and the number of attempts to send a transactional request;

[15] - perform a user request;

[16] When implementing a technical solution, when creating a user request, the user of the CSS is verified.

[17] When implementing a technical solution, verification is performed using a PIN code, biometric information, graphic information or a remote user device, or a combination of both.

[18] When implementing a technical solution, biometric information is a fingerprint, a retinal image, voice data, or combinations thereof.

[19] When implementing a technical solution, the graphic image is a photograph of the user.

[20] Also, the technical result is achieved due to the implementation of the system of guaranteed performance of the delivery transaction of the DS in case of failures in the communication channel of the self-service device US, which contains the CSS and the associated remote server, with the US performed with the ability to receive a primary user request for a transaction for the delivery of DS;

save information about the accepted DS;

send transaction information to a remote server;

the remote server is designed with the ability to save information about the transaction received and delivered DS.

[21] When implementing a technical solution, a CSS is an ATM or an information and payment terminal.

[22] When implementing a technical solution, the USB is connected to the remote server via a wired or wireless computer network.

[23] When implementing a technical solution, a wired network is a LAN (LAN), WAN, PAN, or Intranet.

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

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

[26] When implementing a technical solution, the CSS contains the means of user verification.

[27] When implementing a technical solution, the verification tools are selected from the group: a PIN-pad, a touchscreen display, a camera, a biometric scanner, a microphone, or combinations thereof.

BRIEF DESCRIPTION OF THE DRAWINGS

[28] FIG. 1 illustrates the process of performing the claimed method.

[29] FIG. 2 illustrates the process of guaranteed delivery of DS in general.

[30] FIG. 3 illustrates a general view of the system implementing the method.

[31] FIG. 4 illustrates the DC scheme.

[32] FIG. 5. illustrates the server request processing from CSS.

DETAILED DESCRIPTION OF THE TECHNICAL SOLUTION

[33] The concepts and definitions required for the detailed disclosure of the claimed technical solution will be described below. [34] Cash (DS) is a specific product with the highest liquidity that serves as a measure of the value of other goods and services.

[35] A self-service banking device (CS) is a software and hardware complex designed for the automated issuance and / or receipt of cash DSs both with and without payment cards, as well as other operations, including payment for goods and services, documents confirming the relevant operations. Banking self-service devices are divided into two types, depending on whether they support the cash out function or not. If the function is supported, the CM is an ATM (English automated teller machine), or an ATM, otherwise - NCS (non-cash systems), or a terminal for cashless transactions.

[36] Software (software) - a program or a variety of programs used to control CSS.

[37] Preliminary on the CSS they can enable the guaranteed execution of the transaction for delivery of the DS or turn it off with the standard configuration tools of the CSS. Moreover, if the mode is turned off, the CSS operates in full accordance with the NDC format.

[38] At any time, the CSS is in one of the following modes of operation:

Power Up - download;

Offline — no connection to the server, connecting;

Supervisor— the collector or service engineer is working;

Out of service— CM is not working due to a malfunction, depletion of funds, or compulsory transfer of a CSS to the specified mode;

In service — the main mode of operation of CSS.

[39] In the In service mode, the US is in one of the states (state), with the number from 001 to 999, and 25 character string description.

[40] The first character of this line is the type of the state (denoted by the letters A..Z, as well as a..z and some characters (, '.?)), Which defines the set. The remaining 24 characters are 8 decimal 3-digit numbers, each of which is a specific setting of the state (screen number for display, conditions for transition to state, list of actions). There can be any number of states of one type. [41] Going through all these states, sooner or later they reach the state of interaction with the remote server — State I (Transaction Request State). On this steve, a request is formed from data collected on past steates and sent to the server. The request is a CSS identifier (Logical Unit Number), data from map tracks, data about previous transactions, data from amount buffers, pin-block, function key presses (FDK buffer). Data is separated by a separator character. The remote server receives the request and analyzes the FDK buffer - it is by the contents of this buffer that the remote server understands what the CSS wants. Then, depending on the decision, sends the answer which contains:

• ID 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;

• State to which you need to go on completion of the action.

[42] As represented in FIG. 1, the claimed method of guaranteed performance of a DS delivery transaction in case of failures in the communication channel (100) is initiated by receiving and processing the initial user request for performing a DS delivery transaction (101).

[43] The initial user request for the execution of a transaction can be formed in the US memory after the client selects a banking operation. The user can select a banking operation by using the graphical user interface (GUI) of the CSS. As a bank transaction can be used to issue cash or depositing a DS on a bank card (request for crediting of funds deposited).

[44] The primary user request is formed using the user interaction with a CSS, for example, an ATM or a terminal for cashless transactions. The primary user request contains at least information about the user's intention to carry out the transaction for the delivery of the DS.

[45] When a primary user request to execute a transaction is received in the system, a transactional request (102) is formed and stored in the US memory, containing at least information on the type of transaction, amount of transaction, transaction details depending on the type of transaction and unique identifier transactions (TrlD). In some embodiments The transaction identifier is a numeric or character value.

[46] The value of the TT must be unique for each transactional request (the value of the TT is updated each time it transitions to the transaction state in the CSS scenario). If the usual transactional request is received in the new format, the request field is not empty; its value must be stored in the remote server database as part of the transactional data.

[47] The field “TransactionlD” is added to all transactional requests, for example, with the identifier “3”, consisting of 12 characters.

[48] For the primary request, these fields are formed as follows: TMMflflMMMMNNN (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, which ensures the uniqueness of the TransactionlD value for a given terminal).

[49] To re-request, the value of the “TransactionlD” field must repeat the value generated at the time of the initial request.

[50] After forming a transactional request (102) and storing it in the US memory, the CA generates and sends a message containing the above transactional request containing at least information on the type of transaction, transaction amount, transaction details and unique transaction identifier to the remote server.

[51] In the process of sending a message, the CS determines whether there is a connection in the channel between the CS and the remote server, and in case of a failure in the communication channel between the CSS and the remote server, the CS prompts the user to cancel the transaction or continue the transaction in the DS guaranteed delivery mode .

[52] In other embodiments, the implementation prompts the user to abandon the transaction or continue the transaction in the mode of guaranteed delivery of the DS in the event of a timeout of the response of the remote server to the transaction message.

[53] If it hits state I, the US performs the following check:

[54] If no authorization requests were made from the moment of entering the client session, or the requests were made, but the mode of guaranteed execution of the transaction on delivery of DS was not activated by calling the special state f-032, the CS generates a new transaction identifier (TrlD). Additionally, the CSS forms the “TransactionRequest” request in full accordance with the NDC format, complementing it with a field, for example, with id = “3” containing this identifier.

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

• if all the parameters of the ready-to-send request match the parameters passed in the previous request, the CS generates a second request. At the same time, the current transaction identifier (TrlD) 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 request ready for sending does not match the parameters passed in the previous request, it is considered that a new transaction has been started. The CS generates a new transaction identifier (TrlD) and forms a TransactionRequest request in full compliance with the NDC format, adding a field with id = “3” containing this identifier.

[56] In case of communication errors and errors in the message format, the CSS transitions from state I to the number of the state specified in “Central Response TimeOut Next State”.

[57] If there is a connection in the communication channel between the CD and the remote server and no failures were detected during the transfer of information, the CD sends a message containing a transactional request containing at least information on the type of transaction, transaction amount, transaction details and a unique identifier transactions to a remote server using data from the original transactional message.

[58] When processing a re-request by a CS, re-authorization on the card is not performed.

[59] Sending a second request is controlled at the CSS script level. To enable / disable processing of repeated requests on a remote server, a special module attribute is used. An attribute can be managed using a SQL script or a web form, while not introducing a web form is a stop factor for replicating the functionality of guaranteed delivery of DS to the entire CSS network. [60] In this technical solution, the repeated request is ignored if the remote server sent a response to the original request. The US has sent a message acknowledging receipt of the response from the remote server.

[61] In some embodiments, the implementation ignores the repeated request if the remote server sent a response to the original request from the CSS that sent the message about switching to the Supervisor Mode or a Power Up message.

[62] In some embodiments, the implementation ignores the repeated request if the card numbers or transaction amounts, or transaction types (OPCODE buffer) in the original and repeated requests are different.

[63] In some embodiments, the re-request is ignored if an error occurs in the re-request format, including an empty TrlD.

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

[65] The remote server, after receiving a message from the CA containing a transactional request for delivery of DS, verifies the correctness of the information contained in the transactional request. The remote server checks the correctness of the specified type of transaction, transaction details, a unique transaction identifier, and whether there is enough DS in the DS account for delivery of the DS.

[66] In some embodiments, if the remote server responds to a timeout, the CS re-establishes the connection with the remote server, according to the current settings of the network of the CS bank.

[67] Additionally, the remote server checks the MAC of the transactional request, and also if this request was previously processed.

[68] If all the specified parameters are correct, then the remote server generates and sends a transactional response to the MS indicating that the delivery of the DS has been completed.

[69] If the transactional response of the remote server to the original transactional message of the CSS is not formed, the remote server completes the processing of the original message and generates a response to the repeated transactional message from the CS. The response to the original message from the CSS is not formed. If, due to the peculiarities of paralleling the processing of requests, the CSS on the remote server will be sent to the CSS and the response to the original request, and to re-request, this situation is not an error. The CS should ignore the response to the original request, since at the time of the re-request formation in the CM, the actual values of the MCN and TVN transactions have changed.

[70] If the response of the remote server to the original transactional message of the CSS was formed, on its basis a response to the repeated message is formed, and no new authorizations are made on the card.

[71] The message will have the new TVN and MCN values from the repeated query of the CSS.

[72] FIG. 2 shows the principle of operation of the mechanism for guaranteed delivery of DS (200). Upon detection of failures in the communication channel between the CS and the remote server (201), the CS starts the guaranteed delivery mode of the DS. In this mode, the CSS sets a timer, which determines the amount of time to restore communication between the CSS and the remote server, sets the time interval parameter for performing a repeated transactional query (202).

[73] The CS, during a specified time parameter, polls the remote server to activate a re-request to receive a response to complete the transaction and attempts to send a transactional request to the remote server, taking into account the number of attempts to send a transactional request (203).

[74] 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 can be carried out the following checks.

[75] If a CS with the off mode of guaranteed execution of a delivery transaction for a DS enters the f-032 state, then processing is performed in the same way as if the maximum number of repeated requests were exceeded (the client session is terminated due to a technical failure).

[76] If the number of attempts to repeat requests is equal to or exceeds the maximum specified in unit f-032, the client session is terminated due to a technical failure.

[77] If the number of attempts to repeat requests is less than the maximum set in the stack, the count of attempts increases and the AC goes to “Next State”. [78] If the limit of the number of repeated requests is not exceeded, the CSS at the number of the state specified in the Next State field of the f-032 state enters a dialogue with the client, implying confirmation of a repeated request to the remote server. This dialogue is organized by standard means of NDC.

[79] 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 transactional request remain unchanged.

[80] Upon receiving the transactional response (204) from the remote server, check the MAC of the transactional response, the amount of time it took to reestablish the connection between the CS and the remote server and the number of attempts to send a transactional request, and if all data is correct, perform a user request.

[81] As represented in FIG. 3, the general principle of operation of the system for carrying out transactions for the delivery of DS is carried out when processing user requests formed in the US channel (300) and their subsequent transfer over the network (500) to the remote server (400) using the method (100) disclosed above.

[82] FIG. 4 shows the general scheme of CS (300) in the form of an ATM or a terminal for cashless transactions. US (300) contains the components integrated via the bus, such as: processor (301), memory (302), network interconnection tool (303), display (304), controls (305), DS issuance tool (306). Additionally, the DS reception tool (307) may also be used.

[83] The CSS 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. HDDs, SSDs, flash memory, etc. can be used as ROMs. The memory (302), as a rule, stores the program logic executed by the processor (301), which is necessary for implementing the operating mode of the CSS (300), and the operating system organizing the interaction interface and data processing protocols.

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

[85] The CSS display (304) serves to display the graphical user interface, as well as when it is executed as a touchscreen display, it also provides user interaction and control commands from it.

[86] The controls of the CSS (305) can be a keyboard, touchscreen, pin-pad, mechanical, and touch buttons.

[87] The DS dispenser (306) is a dispenser. Dispenser

(306) may be of various types, for example, friction or vacuum.

[88] Additionally, CS (300) may contain a means for receiving DS

(307) from the user.

[89] Also, CSS (300) may contain a bank card reader, a camera, one or more biometric sensors, and 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 transactional request by submitting a bank card to a special reader US (300) and entering the pin code using the keyboard (305) or the touch display (304).

[90] In some embodiments of the technical solution, two-factor user verification can be applied using a camera or biometric sensors, for example, a fingerprint scanner, a retina, or using a user's voice analysis. With the help of the camera, the image of the user of the DC (300) can be fixed for further processing and comparison with the reference identifying information of the account holder when initiating a transactional operation in the CSS (300).

[91] The CS (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 over a wireless channel of information exchange, such as Bluetooth , Wi-Fi, NFC, RFID, etc., in the CSS (300).

[92] FIG. 5 shows the general scheme of a remote server (400). Server (400) is designed to process execution requests transactional requests to the channel CSS (300). Also, the server (400) implements a mechanism for guaranteed delivery of the DS in the event of a failure in the CSS channel without re-authorization and without re-entering the transaction parameters.

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

[94] The processor (401) of the server performs the basic computational operations during its operation with CSS (300). The processor (401) executes the necessary computer readable instructions contained in the memory (402).

[95] 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 the full functionality of the server (400).

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

[97] 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.

[98] 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.

[99] Networking tools (405) are selected from devices providing network data reception and transmission, for example, Ethernet card, WLAN / Wi-Fi module, Bluetooth module, BLE module, NFC module, IrDa, RFID module, GSM modem, and t .P. By means of (405), the organization of data exchange between the server (400) and US (300) is provided via a wired or wireless data transmission channel, for example, WAN, PAN, LAN (LAN), Intranet, Internet, WLAN, WMAN or GSM. [101] In addition, the server (400) may contain data input / output facilities, such as a keyboard, joystick, display (touchscreen), projector, touchpad, manipulator, computer mouse, trackball, light pen, speakers, microphone, etc.

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

Claims

FORMULA

1. The method of guaranteed execution of the transaction for the delivery of funds (DS) in case of failures in the communication channel of the self-service device (CS), which includes the steps of:

- receive in the channel (CS) the primary user request to complete the transaction;

- perform a transaction.

2. The method according to claim 1, characterized in that when a failure occurs in the communication channel between the CSS and the remote server, a timer is set that determines the amount of time to restore communication between the CSS and the remote server.

3. The method according to claim 1, characterized in that it additionally takes into account the MAC address of the CSS when requesting a transaction.

4. The method according to claim 1, characterized in that when a failure in communication with a remote server is detected during the processing of the primary transactional request, a time interval parameter is generated for performing a repeated transactional request.

5. The method according to claim 4, characterized in that during a given parameter of the time interval, the remote server is polled to activate a repeated request for a response to complete the transaction.

6. The method according to claim 4, characterized in that during a given parameter of the time interval, an attempt is made to send a transactional request to a remote server, taking into account the number of attempts to send a transactional 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 CA and the remote server, and the number of attempts to send a transactional request;

- perform a user request;

7. The method according to claim 1, characterized in that during the formation of the primary user request, the user of the CSS is verified.

8. The method according to claim 7, characterized in that the verification is carried out using a PIN code, biometric information, graphic information, a remote user device, or a combination thereof.

9. The method according to claim 8, characterized in that the biometric information is a fingerprint, an image of the retina, voice data, or combinations thereof.

10. The method according to claim 8, characterized in that the graphic image is a photographic image of the user.

11. The system of guaranteed execution of a cash delivery (DS) transaction in case of failures in the communication channel of a self-service device (CS) containing a CSS and an associated remote server, and

• CS is designed with the ability to receive the primary user request to complete a transaction for the delivery of DS;

• save information about the received DS;

• transmit transaction information to a remote server;

• the remote server is designed with the ability to save information about the transaction and the received DS.

12. The system of claim 11, characterized in that the CS is an ATM.

13. The system according to claim 11, characterized in that the CD is connected to the remote server via a wired or wireless computer network.

14. The system of claim 11, characterized in that the wired network is a LAN (LAN), WAN, PAN, or Intranet.

15. The system of claim 11, characterized in that the wireless network is a WAN, Internet, WLAN, WMAN or GSM.

16. The system of claim 11, characterized in that the remote server is a cloud server.

17. The system of claim 11, characterized in that the CS contains user verification means.

18. The system of claim. 11, characterized in that the means of verification of the US are selected from the group: PIN-pad, touch screen, camera, biometric scanner, microphone, or combinations thereof.