RU2677384C1 - Way of automatic calculation of the included money in case of failures - Google Patents

Abstract

FIELD: processes automation devices.SUBSTANCE: invention relates to a method and system for automatically crediting deposited funds in case of failures. Method includes the steps in which receive in the channel of the self-service device (SSD) user request to perform a transaction to receive funds, send a preliminary transactional request to a remote server to check the transaction parameters, including the user account identifier, receive a response from the server and save it to the SSD, initiate the reception of funds into SSD, fix the data of the received funds, transfer the data to the remote server, fix with the help of the SSD the occurrence of data sending failure to complete the transaction, save the transaction parameters in the SSD memory, activate the automatic transfer of funds, ensuring the execution of a transactional request without user participation on the basis of the user account identifier mentioned, automatically initiate a poll of the remote server SSD, when receiving a response from a remote server, the above-mentioned saved transaction parameters are transmitted to the server for its execution, the funds is credited to the specified user account.EFFECT: technical result consists in automating the processing of transactional requests in case of failures in the channel of the self-service device.14 cl, 5 dwg, 1 tbl

Description

FIELD OF TECHNOLOGY

[0001] This technical solution, in General, relates to the field of data processing for transactions on making money (DS) in the interaction of users with self-service devices (CSS), and in particular, to methods of transactions on making a DS in the event of various failures in the US channel when exchanging data with a transaction processing server.

BACKGROUND

[0002] The prior art system and method for adaptive diagnostics of failures in the channel US in the thin client mode (patent US 8108726B2, 01/31/2012, Bank of America Corporation). In this solution, adaptive diagnostics of failures in the DC channel is carried out during transactions for making DS. A feature of the solution is that the OS includes a thin client and adaptive diagnostics is performed in the thin client mode. In this solution, if a malfunction occurs in the DC channel, the user is informed about the failure and the reason for the failure is indicated, and information about the nearest operational CSS is also given. In addition, the CSS can coordinate information about the nearest operational CSS via the user's mobile phone.

[0003] Also known is a system and method for detecting failures in an ATM (application US 2007131757 A1, 06/14/2007, NCR Corporation). In this solution, when carrying out transactions, including transactions for depositing money, a transaction log is generated, in which all transaction information is written. A connection 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 based on the transaction information contained in the transaction log.

[0004] The prerequisites for the creation of the claimed technical solution are based on the need to implement an extended functionality mechanism when performing transactions on making a DS in the event of various failures. The current drawback in the prior art is the lack of a mechanism for automatically crediting the entered DS in the event of various failures, which in turn also reduces the time for transactional transactions using the CSS.

SUMMARY OF THE INVENTION

[0005] A technical problem solved by the claimed technical solution is to create an effective method and system for processing transactions in an automated channel in an automated mode when various types of failures occur, which lead to delays or refusal to process transaction operations.

[0006] The technical result is the expansion of the functionality of the CA, through the implementation of a mechanism for the automated processing of transaction requests in case of problems in the channel of the CA when exchanging data with the transaction processing server.

[0007] An additional technical result is also an increase in the reliability of processing transactional operations due to the operation of internal scenarios of the CA, as well as a reduction in the time to complete transaction requests in the event of failures in the channel of the CA

[0008] In a preferred embodiment of the claimed solution, there is provided a method for automatically crediting deposited funds (DS) in the event of a malfunction, including the steps of:

- receive in the channel of the self-service device (CSS) a user request for execution of a receive transaction (DS) containing transaction parameters;

- send a preliminary transaction request to a remote server to verify transaction parameters;

- receive a response from the server and save it in the CSS;

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

- record during reception the data of the received DS;

- fix with the help of the US the occurrence of a failure in sending data to complete a transaction, transfer data to a remote server and save the transaction parameters;

- automatically initiate a poll of the remote server;

and

- upon receipt of a response from the remote server, the mentioned saved transaction parameters are transferred to the said server for its execution.

[0009] In one of the private options for implementing the method when generating a user request, the verification of the user is carried out.

[0010] In another particular embodiment of the method, verification is carried out using a PIN code, biometric information, graphic information, or a remote user device, or a combination thereof.

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

[0012] In another particular embodiment of the method, the graphic image is a photo image of a user.

[0013] In another particular embodiment of the method, the data of received DSs is a currency code, a nominal value of a monetary unit, the number of accepted monetary units or a breakdown of banknotes into groups.

[0014] The claimed solution is preferably carried out by the system of automatic crediting the entered DS in the event of a malfunction, which contains the CSS and the associated remote server, moreover

CSS made with the possibility

receive a user request to complete a transaction for receiving a DS;

save information about the received DS;

transmit transaction information to a remote server;

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

save information about the transaction and accepted DS;

and carry out automatic transaction in the event of a failure in the data transmission channel between the DC and the remote server.

[0015] In a private embodiment of the system, the CSS is an ATM or terminal.

[0016] In another particular embodiment of the system, the CSS is connected to a remote server via a wired or wireless computing network.

[0017] In another particular embodiment of the system, the wired network is a LAN, WAN, PAN, or Intranet.

[0018] In another particular embodiment, the C wireless network is a WAN, Internet, WLAN, WMAN or GSM.

[0019] In another particular embodiment of the system, the remote server is a cloud server.

[0020] In another private embodiment, the implementation of C US contains means of verification of the user.

[0021] In another particular embodiment of the system, the verification means of the USB are selected from the group: PIN pad, touch screen, camera, biometric scanner, microphone, or combinations thereof.

BRIEF DESCRIPTION OF THE DRAWINGS

[0022] The features and advantages of this technical solution will become apparent from the following detailed description of the invention and the accompanying drawings, in which:

[0023] FIG. 1 illustrates a flowchart of the claimed method.

[0024] FIG. 2 illustrates

[0025] FIG. 3 illustrates an example of a system for exchanging data between a USB and a remote server.

[0026] FIG. 4 illustrates an example of a DC circuit.

[0027] FIG. 5 illustrates an example remote server diagram.

DETAILED DESCRIPTION OF THE INVENTION

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

[0029] In this technical solution, a system is meant, including a computer system, a computer (electronic computer), CNC (numerical program control), PLC (programmable logic controller), computerized control systems, and any other devices capable of performing a given , clearly defined sequence of operations (actions, instructions).

[0030] An instruction processing device is understood to mean an electronic unit or an integrated circuit (microprocessor) executing machine instructions (programs).

[0031] The command processing device reads and executes machine instructions (programs) from one or more data storage devices. Hard disk drives (HDD), flash memory, ROM (read only memory), solid state drives (SSD), optical drives can be used as storage devices.

[0032] TSN (Transaction Serial Number) is the number of the last successfully completed transaction.

[0033] NCR Direct Protocol (NCR Direct Protocol) - a data exchange protocol between the CSS and the transaction processing server.

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

[0035] Self-service banking device (CSS) is 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 documents confirming the relevant 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.

[0036] Software (software) or software logic - a program or a variety of programs used to control the CSS and server tools to perform the required operations.

[0037] In FIG. 1 presents the main steps of the claimed method of automated introduction of DS (100). At the first stage (101), the CA receives a request from the user for the implementation of a financial transaction for making a DS. The request contains, as a rule, the identifier of the account of enrollment of DS, the amount of DS, the time of the start of the request for the operation. The request also contains a Transactional Request Identifier (TrID).

[0038] The request may further comprise a Logical Unit Number identifier, data from map tracks, data on previous transactions, data from sum buffers, pin block, function key presses (FDK buffer).

[0039] The TrID value is unique for each transaction request (the TrID value is updated each time a transaction state is transitioned 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 is stored in the remote server database as part of the transaction data of the operations performed.

[0040] A “TrID” field is added to all transactional requests, for example, with an identifier of “3”, consisting of 12 characters.

[0041] For the initial request, these fields are generated as follows: ГММДДЧЧMMNNN (where Г 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 the uniqueness of the TrID value for this CSS). The Accumulated Transaction Count value determines the total number of detected attempts to execute transactions since the installation of the USB or after the non-volatile memory of the USB is fully occupied. The counter is reset to 0 after 9999999 transactions.

[0042] For a repeated request, the value of the “TrID” field should repeat the value generated at the time of the initial request.

[0043] At each point in time, the CSS is in one of the following modes of operation:

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;

[0044] In service - the main mode of operation of the CSS. 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.

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

[0046] Moving 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. 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 determines the necessary operations, the execution of which is requested by the CSS. Then, depending on the decision made, it sends a response that contains:

^~ identifier of the action to be performed;

^{~ the} number of the screen to be shown with this action;

^~ check contents, if the check needs to be printed;

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

[0047] After the CA records the received DS amount, the following data are determined and stored:

^{~ the} amount of accepted banknotes;

^~ currency code;

^{~ the} number of accepted banknotes by type.

[0048] The data of the transaction operation indicated in step (101) are processed by the control unit logic (102) and are generated for transmission to a remote server to complete the transaction (103).

[0049] Referring to FIG. 2, after receiving the DC of the DC and recording the parameters of the sum of the DC, the logic of the DC generates a preliminary transaction request for sending to the server (201).

[0050] The entry of the DS into the CA is carried out in cash and the data of the DS are recorded when the DS is received by the cash receiving module (MPN). MPN can be performed by Escrow type (preliminary deposit of notes).

[0051] The generated preliminary request is sent to the server (202) after making a certain amount of DS. This can happen after processing the parameters of each banknote, or after receiving several banknotes or after receiving the entire amount of the transaction information specified in the transaction request at step (101).

[0052] This step allows you to pre-verify the stability and performance of the data channel between the CSS and the server to complete transactions.

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

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

[0055] Returning to FIG. 1, at step (104), a check of the communication channel is performed to carry out the necessary transaction introduced at step (101).

[0056] If communication with the server is present and the CA has received the entire necessary amount of DS to complete the transaction request, then these transactions are sent to the server, where they are processed and transferred to the account indicated in the request (step 108).

[0057] In the case when, at step (104), the CA does not receive a response from the server, the US logic saves the transaction parameters when there is no response from the server (105) and activates the program mechanism of the automatic funds transfer script (106).

[0058] When performing step (106), as indicated above, the CA 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 above-mentioned request is the last before commit the presence of a failure in the data transmission channel between the CSS and the server.

[0059] The execution of step (106) is carried out until a response is received from the server, which allows the user to complete a transaction request based on the account identifier obtained in step (101), to which the DS should be transferred.

[0060] The execution of step (106) of activating the automated execution of a transaction is carried out, in particular, if the CA did not receive a response (Transaction Reply) from the server (for example, disconnecting the network connection, powering off the DC), or could not correctly parse the server response, or an error occurred verification of the MAC signature of the transaction. To protect the integrity of the technical solution, a transaction mocking mechanism is used by the MAC address. To calculate and verify the MAC address, a command is used, at the input of which data is supplied, which can vary depending on the settings:

- MAC calculation method, for example, by means of ANSI X9.19;

- the type of key with which the hash is encrypted, for example, ZAK / TAK (it should be possible to select the type of key).

).- data on which the hash is calculated (message fields marked in the xsd-scheme by

)

[0061] The MAC key must be unique for each CSS, and the uniqueness control is carried out on the server side. When you try to enter a duplicate key in a web form, a warning about mismatch should appear.

[0062] TSN values for the last transaction attempt, the amount of banknotes received, currency code, the number of banknotes received by type at the time the TSN is committed does not change. This information is used for subsequent authorization requests until the correct response is received from the server. This allows you to validate the transaction procedure in an automated manner.

[0063] The server, for its part, can initiate the sending of current meters by a specialized team, 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 US with the values: the sum of the accepted banknotes, currency code, the number of banknotes received, broken down by type. This data is also used to perform transactional operations after restoring the communication channel with the server.

[0064] The following table 1 shows an example of data stored in the identification part of the amount of the entered DS and confirmed in the received response from the server. The indicated table shows an example of making 1750 rubles in the unitary enterprise.

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

[0066] The network (500) may be a wired or wireless type, such as the Internet, Intranet, LAN, WAN, WLAN, GSM, GPRS, Wi-Fi, and the like.

[0067] FIG. Figure 4 shows the general scheme of CSS (300) in the form of an ATM or payment terminal. The control unit (300) contains components integrated using a universal bus (310), such as: a processor (301), memory (302), a network interaction tool (303), a display (304), control elements (305), and a DS output means ( 306) (in the case of an ATM), a means of receiving DS (307).

[0068] The processor US (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 US (300) operating method, and the operating system that organizes the interaction interface and data processing protocols.

[0069] As a means of network communication (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), etc. Additionally, communication tools between the CSS (300) and the user (user device) can be used, for example, Bluetooth transceiver, NFC module, irDa, etc.

[0070] The US display (304) is used to display the graphical user interface, and when executed as a touch display, it also provides interaction with the user and control commands received from him.

[0071] The controls US (305) may be a keyboard, touch screen, pin pad, mechanical and touch buttons.

[0072] The dispenser DS (306) is a dispenser. Dispenser (306) can be of various types, for example, vacuum, spray type, etc.

[0073] Additionally, CSS (300) may include means for receiving a DS (307) from a user.

[0074] Also, 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).

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

[0076] CSS (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 communication channel, for example, Bluetooth , Wi-Fi, NFC, RFID, etc., in the US (300) (as an example, this technology is disclosed in the sources US 20110238573, US 20110066552).

[0077] In order to enhance the safe transaction mode in the US channel (300), a counter of repeated operations may be used, which, upon reaching the specified 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 for its implementation.

[0078] Data is transmitted to a user's device, such as a smartphone or tablet, by standard means and methods, such as: SMS messages, PUSH notifications, e-mail letters, etc. The specified method of notifying the user is selected based on the identification information associated with the user account, for example, his phone number, card number or biometric information.

[0079] In FIG. 5 shows a general diagram of a remote server (400). Server (400) is designed to process requests for the execution of transactional requests for crediting DS entering the US channel (300).

[0080] In general, the server (400) comprises components such as: one or more processors (401), at least one memory (402), data storage means (403), input / output interfaces (404), network means interactions (405).

[0081] The processor (401) of the server performs basic computing operations when it is operated with the US (300). The processor (401) executes the necessary computer-readable instructions contained in the memory (402).

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

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

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

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

[0086] Network communication tools (405) are selected from devices providing network reception and data transmission, for example, an Ethernet card, WLAN / Wi-Fi module, Bluetooth module, BLE module, NFC module, IrDa, RFID module, GSM modem, etc. .P. 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.

[0087] Additionally, the server (400) may comprise I / O means, for example, a keyboard, joystick, display (touch screen), projector, touchpad, mouse, trackball, light pen, speakers, microphone, and the like.

[0088] The present application materials provided a 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 (35)

1. A method for automatically crediting deposited funds (DS) in the event of a malfunction, carried out by the processor, which includes the steps in which: - receive in the channel of the self-service device (CSS) a user request to complete a transaction for receiving a DS containing transaction parameters; - send a preliminary transaction request to a remote server to verify the transaction parameters, which includes the user account identifier; - receive a response from the server and save it in the CSS; - initiate the reception of DC DS according to the parameters of the transaction; - record during reception the data of the received DS; - transmit data to a remote server, record with the help of the USB the failure of sending data to complete the transaction, and save the transaction parameters in the memory of the USB; - activate a script for automatic crediting of funds, which ensures without a user performing a transaction request based on the said user account identifier; - automatically initiate a poll of the remote server; and - upon receipt of a response from the remote server, the mentioned saved transaction parameters are transferred to the said server for its execution; - credited DS to the specified user account. 2. The method according to p. 1, characterized in that when the user request is generated, the 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 device, or a combination thereof. 4. The method according to p. 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 p. 2, characterized in that the graphic image is a photo image of the user. 6. The method according to p. 1, characterized in that the data received DS represent the currency code, face value of the monetary unit, the number of accepted US currency units or data breakdown of banknotes into groups. 7. A system for automatically crediting deposited funds (DS) in the event of a malfunction, comprising a CA and a remote server associated with it, moreover CSS made with the possibility receive a user request to complete a transaction for receiving a DS, and the request contains transaction parameters, including at least the user account identifier; 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 an automatic funds transfer script that allows you to execute a transaction request without user intervention based on the said user account identifier; Automatically initiate polling of a remote server upon receipt of a response from a remote server, transmit the mentioned saved transaction parameters to the said server for its execution; the remote server is configured to check the parameters of the transaction received from the CA; save information about the transaction and accepted DS; to carry out automatic transaction in the event of a failure in the data transmission channel between the DC and the remote server; and credit DS to the specified user account. 8. The system according to p. 7, characterized in that the CS is an ATM or terminal. 9. The system according to claim 7, characterized in that the communication system 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 according to claim 7, characterized in that the wireless network is a WAN, Internet, WLAN, WMAN or GSM. 12. The system according to claim 7, characterized in that the remote server is a cloud server. 13. The system according to p. 7, characterized in that the CSS contains means of verification of the user. 14. The system according to claim 7, characterized in that the verification means of the USB are selected from the group: PIN pad, touch screen, camera, biometric scanner, microphone, or a combination thereof.

Images