WO2019098875A1

WO2019098875A1 - Identification and classification of the reasons for user complaints in self-service devices

Info

Publication number: WO2019098875A1
Application number: PCT/RU2017/000986
Authority: WO
Inventors: Валерий Валерьевич ТОЛКАЧЕВ; Марина Игоревна КАЧАЕВА; Сергей Юрьевич САЕНКО; Денис Александрович АРТЮШИН; Екатерина Сергеевна ИВКИНА; Сергей Владимирович АЛПАТОВ
Original assignee: Публичное Акционерное Общество "Сбербанк России"
Priority date: 2017-11-20
Filing date: 2017-12-27
Publication date: 2019-05-23
Also published as: EA201700610A1; EA033174B1; RU2673001C1

Abstract

The invention relates to systems and methods for identifying the causes of complaints and incidents in a network of self-service devices. In a method for identifying and classifying the reasons for user complaints in self-service devices, a set of user complaints is collected in chronological order. A group of complaints is selected for analysis on the basis of a requirement with respect to the type and number of operations. An operation is obtained which corresponds to a complaint from the group of complaints selected in the preceding step, and the operation is analyzed using syntax analysis. A line-by-line reading of the operation is carried out, and a user client session is determined on the basis of the operation. The reason for the occurrence of an error in the user operation is identified, and the user complaints are classified on the basis of user operations in which errors occurred in the self-service device.

Description

DETECTION AND CLASSIFICATION OF CAUSES

OCCURRENCE OF USER CLAIMS IN DEVICES

SELF-SERVICE

TECHNICAL FIELD

This technical solution, in general, relates to the field of computer technology, and in particular to systems and methods for identifying the causes of claims and incidents in the network of self-service devices.

BACKGROUND

Automatic teller machines or self-service devices quickly played a key role in financial transactions. Therefore, the importance of effective management of such banking machines with the ability to identify and classify the causes of user complaints continues to grow. Self-service devices allow customers to carry out various financial transactions, including deposits, money transfers between accounts, payments on bills, balance requests, cash withdrawals, etc.

Self-service devices are usually located in places where self-service device customers can quickly and conveniently complete transactions, including transfer of funds. In some cases, self-service devices are owned by a legal entity (for example, a financial institution), and are managed by another entity, such as a service provider, who has contracted a financial service agency. In this case, the service provider is the operator of the self-service device.

Operators place self-service devices in places where customers can quickly and conveniently complete transactions for a variety of reasons. For example, a restaurant owner may purchase a self-catering unit to place in a restaurant in order to increase profits at a restaurant’s bar. Financial institutions typically operate large networks of self-service devices that allow customers of financial institutions to have more freedom in making financial transactions. Clients of a financial institution that provides such a large network of self-service devices consider a large number of ATMs as the advantage of doing business with a specific financial institution. Financial institutions see ATMs as another source of potential revenue.

Operators of self-service devices (sometimes ATMs from the English Automated teller machine), which may be ATMs, must effectively manage each ATM, in order to justify the reason for placing the ATM in a particular place and to monitor the absence of failures. The operated ATM must function correctly (that is, without mechanical or electrical failures) and contain sufficient cash to process each transaction requested by the ATM client. If the ATM does not work, the customer usually finds the ATM of another financial institution and uses this ATM to complete the transaction. The operator of a non-operational ATM may lose revenue associated with future transactions if the customer does not return to this ATM operator because of a negative operating experience, and therefore identifying and classifying the causes of user complaints in the ATM channel is a very important task in the level of technology.

Modern methods of managing ATMs are expensive to implement and are limited in functionality. Additionally, these methods of managing ATMs are often performed by third-party service providers, which complicates the work of processing user complaints.

The prior art patent application US 20020082994 A1 "patent holder: Efunds Corporation, publication date: 06/27/2002. In this technical solution, an ATM management application is used to provide an ATM operator with a complete set of information about managing an ATM. This information for managing an ATM may allow an ATM operator to increase the profitability of ATMs by increasing availability and reducing ATM funds. The ATM management application can include any number of the following modules: a cash management module, an operation status request module, a courier service module, an automatic balance check module, a deposit check module, a website control module, and a profit management module. SUMMARY OF INVENTION

The technical solution is aimed at eliminating the disadvantages inherent in existing solutions of the prior art.

The technical problem posed in this technical solution is to identify and classify the causes of the claims of users in self-service devices.

The technical result, which manifests itself in solving the above problem, is to improve the quality of the analysis of user complaints that have arisen as a result of errors in the operation of the self-service device.

An additional technical result achieved when solving the above problem is to improve the accuracy of the analysis of user complaints and the speed of analysis of user complaints by using an automated parser for analyzing operations.

This technical result is achieved by implementing a method for identifying and classifying the causes of user complaints in a self-service device, in which they receive a set of user complaints in a chronological order that arose when using a self-service device; allocate a group of users' claims for analysis based on at least one requirement for the type and number of operations, with each claim corresponding to at least one operation; receive at least one operation corresponding to at least one claim from the group of claims selected in the previous step; analyzing at least one operation by applying text syntax, and performing at least one operation line by line; determining at least one client session of the user based on the at least one operation; identify at least one cause of an error in a user operation; Then, users' claims are classified based on user operations for which errors occurred in the self-service device. In some embodiments, a user's photo or video is obtained in conjunction with the user claim set.

In some embodiments, the resulting set of user claims is filtered based on the type of operation that occurred. In some embodiments, upon receipt of a set of user claims, a biometric user identification by voice is used to record his claim.

In some embodiments, upon receipt of a set of user claims, user operations are automatically recorded in the event log.

In some embodiments, a user claims group is identified that relates to failed operations, based on the proportion of affected users or products, or the degree of malfunction.

In some embodiments, a group of user claims related to failed operations is distinguished based on their severity.

In some embodiments, the implementation of the cause of the error is determined by a character or numeric identifier that uniquely corresponds to the type of operation and / or the type of error.

In some embodiments, the implementation of the classification of claims carried out on the basis of errors found on the operating days of the self-service device and / or types of operations and / or types of self-service devices, and / or types of event logs.

BRIEF DESCRIPTION OF THE DRAWINGS

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

FIG. 1 shows a block diagram of a method for identifying and classifying the causes of user complaints in a self-service device; FIG. 2 shows a diagram of the interaction of the nodes of the system for identifying and classifying the causes of user complaints in the self-service device;

FIG. 3 shows an exemplary analysis of claims by applying text syntactic analysis;

FIG. 4 shows an embodiment when several user operations and errors correspond to one user claim.

DETAILED DESCRIPTION OF THE INVENTION

Below will be described the concepts and terms necessary to understand this technical solution.

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

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

The command processing device reads and executes machine instructions (programs) from one or more data storage devices. In the role of a storage device can act, but not limited to, hard drives (HDD), flash memory, ROM (read-only memory), solid-state drives (SSD), optical drives.

A program is a sequence of instructions intended for execution by a computer control device or command processing device.

ATM (Automated Teller Machine) or ATM - a software and hardware complex designed for the automated issuance and / or receipt of cash with or without payment cards also performing other operations, including payment for goods and services, drawing up documents confirming the relevant operations.

Event log (English log) - a standard way for applications and the operating system to record and centrally store information about important software and hardware events. The event log service stores events from various sources in a single event log, which allows the user to monitor the event log, the program interface (API) allows applications to record information in the log and view existing records.

A parser (otherwise a parser) is a program or part of a program that performs parsing. During the syntax analysis, the source text is converted into a data structure, usually a tree, which reflects the syntactic structure of the input sequence of characters and is well suited for further processing.

In some embodiments, a method for identifying and classifying the causes of user complaints in a self-service device shown in FIG. 1 includes the following steps.

Step 101: get a set of user complaints in chronological order, arising from the use of self-service devices;

Pre-user 200, as shown in FIG. 2, accesses the self-service device 201 and performs the banking operations it needs.

As a bank transaction, it may be, without limitation, depositing cash into a card account, payment of services in cash, cash withdrawal.

During the cash deposit operation on the card account, unrecognized bills are returned to the client. If the client did not pick up / was unable to pick up the returned unrecognized bills within a timeout of N seconds, the recognized money is saved in the cassette. In log 206 of the ERL events, the error is fixed as follows:

b

In case of failures in the operation of the self-service device 201, for example, errors or incorrect operation, or hardware failure in accepting notes, the user 200 usually leaves a claim on the operation of the self-service device 201 and the system as a whole.

All user complaints left in the self-service device 201 or by calling the hotline operator come from the self-service device 201 or from the remote server 202 from the user or the hotline operator to the customer complaints and complaints system 203.

In some embodiments, the user uses the 200 biometric identification of the voice to record his claim.

The communication methods described above allow multiple users / customers to access system 203 through a communication network directly from self-service device 201 or connect from remote server 202, which can be a web server. Remote server 202 can be connected to multiple servers 202 a, including, but not limited to, a database server, file server, e-commerce server, content management server, directory server, FTP server, print server, and proxy server with or without a firewall .

In some implementations, together with the claim of the user 200, a photo or video image of the user is received with one of the cameras installed on the self-service device 201 (in the event that a video surveillance system is installed on the ATM). Step 102: allocate a group of user claims for analysis based on at least one requirement for the type and number of operations, with each claim corresponding to at least one operation; Each recorded user claim is associated with at least one operation for which an error occurred (in other words, a failed operation), as shown in FIG. four.

This correspondence may involve recording a claim and an operation into one file, using it with the same numeric or symbol identifier, into a single database entry, etc.

All failed operations are recorded automatically in the event log 206 or a log file, which is the system messages generated as a result of the operations that occurred as a result of user actions 200 (Fig. 2) in the self-service device 201, and this data can be filtered on based on the type of operations that occurred.

Filter criteria may include predefined conditions and / or conditions developed using machine learning or other adaptive methods. Filter criteria can be implemented on server 204 of system 203 based on production rules automatically configured by the user or dynamically configured using software based on machine learning methods (for example, using an artificial neural network).

The event log 206 consists of records stored in the database 205. As the event log 206, you can use, without limitation, PRJ, PRR, PRF and ERL files. In some embodiments, the event log 206 consists of one or more files, each of which includes a specific type of operation or error.

Event logs 206, for example, in the ^* .rg and ^* .prj format are stored in files corresponding to the ATM operating days, in the form of text files with the names YYYYMMDD, where YYYY is the year, MM is the month and DD is the opening day of the corresponding trading day. The * .erl log can be created every day with the name of the same type YYYYMMDD. For example, the file 20170411.rgg contains a copy of client checks for the ATM operating day, opened on April 1, 2017. The retention periods for event logs, print forms used, trace levels and other characteristics of event logs are ATM software configuration parameters and can be changed by the user, who is, for example, an operator.

Records of operations for which errors occurred, can be stored for a predetermined time, and then archived. Briefly summary information on event logs can be presented in the form of a table.

In some implementations, internal fault conditions can be stored in event log 206 that are not related to user complaints for later analysis, even if fault conditions are never transmitted as a failure signal. Self-service device 201 may transmit failure signals corresponding to failure states not satisfying the filter criteria to remote control server 204 in response to a request for these fault signals or on a periodic basis (for example, daily, weekly, monthly, etc.).

A server 204 hosted on the system aggregates information from all testing and user clients that have been configured to use server 204. In one embodiment, one server 204 serves all clients. In another embodiment, a plurality of servers 204 serve a subset of clients. Server 204 also implements functional logic that provides the user with access to the network to provide detailed information about new events and errors, as well as to analyze existing errors. There are a group of claims on the basis of operations, for example, on the basis of their criticality. For example, operations can be grouped into the following categories: the operation cannot be performed; the operation can be performed partially; the operation can be performed on paper, but requires subsequent manual entry into the system; the operation can be performed completely using a workaround; the operation can be performed completely, the speed of the bank employee is reduced; operation is available - request for revision, consultation, etc.

In some embodiments of the technical solution, the operations may be grouped together based on the proportion of affected users or products, or the degree of malfunction, without being limited.

Based on the fact that the operations are grouped together, they single out, on the basis of predetermined requirements, the highest priority claims of users relating to failed operations.

Also allocate a group of claims based on a predetermined requirement for the number of relevant operations.

Step 103: receive at least one operation corresponding to at least one claim from the group of claims outlined in the previous step;

The system 203 for registering and registering complaints and claims of users uses the published API 206. Through this API, which has a graphical interface, complaints, claims, and errors in the self-service device 201, due to which claims originated, are unloaded from the system 203. The advantage of the API is that if the user needs the system 203 to record and register customer complaints and complaints, support other types of devices (such as handlers or other testers), the manufacturer of a particular device only needs to publish its own configuration file. This configuration file for system 203 contains different types of events, errors that occur, and their attributes.

In an exemplary embodiment, the system of accounting and registration of complaints and claims of users 203 uses a “web service”, a well-known universal standard that supports interaction between devices and components in a network. In one embodiment, the Web Service Front End Interface (WSDL) Language is used in conjunction with the Messaging Protocol (SOAP) and Markup Language (XML) to provide web services over the Internet. WSDL describes the open web service interface.

Step 104: analyze at least one operation by applying text syntax;

In this step, the event log 206 is preliminarily checked for completeness: whether all the necessary event log files 206 are received, whether information on claim transactions contains information. For user claims for which an incompletely received / received set of event logs 206 of the self-service device 201, request a repeated collection of event logs.

Step 104a: perform line-by-line reading of at least one operation;

As shown in FIG. 3, the event log 206 is transmitted to the parser 301, which processes the event log 206 to form a final file, for example, in XML format. It should be noted that the parser 301 can also be implemented using the Java programming language. Event log 206 often includes compilation and execution information that is used in debugging and other maintenance operations on self-service device 201. The parser 301 processes this information by using additional information to create the generated report file in XML format. In addition, the parser 301 can extract control characters that are not used during the further steps of the method. The parser 301 is a universal tool that can execute SQL queries for source files (i.e. event logs). In addition, SQL queries allow you to import, parse, present, and export a variety of different data from input event logs in various formats (for example, CSV, XML, txt, W3C, IIS, database table, and other data formats). In addition, the parser 301 provides filtering of event log entries, searching for data and patterns in files of various data formats. Also, the parser 301 converts event logs from one data format to another data format, creates formatted reports and XML files containing data obtained from different log sources, exports data (all or individual parts of event logs) to database tables (for example , SQL tables), data mining, etc.

In addition, the 301 parser supports the SUM, COUNT, AVG, MIN, and MAX aggregated functions. It supports the most common operators, such as more (>), IS NULL, LIKE and IS IN. Also, the 301 parser supports most standard SQL queries: SELECT, WHERE, GROUP BY, HAVING, and ORDER BY.

In some embodiments, the parser 301 allows third-party software developers to add plug-ins to the analyzer 301. For example, to read and analyze the event log 206 of a particular data format, the parser 301 will interact with a plug-in such as a user reader, for example.

Step 104 b: determine at least one client session of the user based on at least one operation;

In the next step, using the parser 301, determine the user's client session and its parameters based on at least one operation. The parameters of the client session can be the beginning of the client session (time of the session beginning), the end of the client session (time of the end of the session). Moreover, the completion of the client session can be caused due to the fact that the operation is terminated (forced termination session) and due to the fact that there was a forced completion of the transaction (the forced completion of the session).

Additionally, at this step, using the parser 301, the number of the self-service device 201, in which the failed operation occurred and the customer complaint, as well as the user's bank card number, are detected.

The table below shows how the event log 206 in PRJ format may look like:

Step 104 c: reveal at least one cause of an error in a user operation;

To generate the parse file, the parser 301 can perform any combination of different operations in the event log 206. These can be filtering operations, searching data and / or templates in files of various data formats, grouping and / or ordering the extracted information in accordance with the conditions specified in the parser 301 request. The parser 301 detects at least one user operation, according to which errors occurred in the self-service device 201, and generates output data based on the results of the query. The output may be the final results of the conversion of the event log 206 from one data format to another data format. It may also be the creation of formatted reports and XML files containing data obtained from different sources of event logs 206. The parser 301 presents the result of its work to end users (for example, through the display module 303), writes the detected operations into one or more database tables, and / or records the identified operations into a data file of the specified data format. The analysis of the 206 event logs of the self-service device 201 for each claim with entering the results into the parsing file can be performed in the following order:

4.1 PRJ - for faulty operations on an ATM;

4.2 ERL - for errors and failures on the part of the ATM; 4.3 NDC - for errors and failures recorded in the exchange of messages ATM-Host;

4.4 PRR - optionally - for the content of the receipt presented to the user for the failed operation;

4.5 HWR - optionally - for the example of errors fixed on an ATM, full information is contained in the ERL-log;

4.6 PPS - optional;

4.7 STF - optional - for tracking the states that the client switched to at the time of the failed operation;

4.8. XML is optional. The parser 301 in this step determines at least one cause of the error in the user's operations.

The cause of the error is determined by a character or numeric identifier that uniquely corresponds to the type of operation, the type of error. An example of displaying a successful cash withdrawal operation in the PRJ journal is as follows:

However, the following errors may be recorded when performing a cash out transaction in the event log: a miscalculation error, a hardware failure of the card reader or a card is delayed by timeout, no funds were taken by the client during the timeout, a hardware dispenser failure, software errors, power failure, etc.

During the deposit operation, unrecognized bills are returned to the user. If the user did not pick up / was unable to pick up the returned unrecognized bills within a timeout of N seconds, the recognized cash is saved in the cassette. In the ERL log, the error is fixed as follows:

The timeout is a configurable parameter of the self-service device 201, therefore the values on various devices self-catering can correlate. On average, the value of a custom parameter is 45 seconds.

Similarly, in the NDC log, the hardware failure of the bill acceptor is displayed in command 12. The following error options are possible: · w3 — device hardware failure;

• w4 — Fatal device failure.

To decipher the error codes, it is necessary to additionally analyze data on the state of the self-service device 201.

In the NDC log, the error is fixed as follows:

Within the client session, the parser 301 searches for the start of the operation, the end of the operation, and also the search for the error string of the operation.

The error string in the approximate embodiments may be as follows: HARDWARE FAILURE AT RECEPTION OF COUPLER [date] [time]

(961) TAYMOUT ON INVITATION OF CUPUR CONTRIBUTION [date] [time] EXCEEDED WAITING TIME FOR EXCESS OF COUPURE [date] [time]

MAP NOT TAKEN BY THE CLIENT AND DETAINED [date] [time]

CUSTOMER MAP CARD [date] [time] ERROR INITIALIZING THE INSERTING OF BANKNOTES! [date Time]

NO RESPONSE FROM HOST [date] [time] STATE FLOW ERROR [date] [time]

(268) MORTGAGE RECIPIENT FAILURE [date] [time]

RECEPTION TRAY IS FULL [date] [time]

Step 105: classify user claims based on user operations for which errors occurred in the self-service device.

In accordance with the present invention, claims from users are automatically classified from the event log file based on the initial rules. Classification of claims can be carried out on the basis of errors found by the operating days of the self-service device and / or by types of operations, or types of self-service devices, or types of event logs.

After classifying user claims based on user operations, a final or resulting file is generated, for example, the csv format. In some embodiments, the result file is archived with or without a password.

This file may contain the beginning of the client session, the end of the client session, the status of the end of the client session, as well as the date / time, terminal, user bank card number, transaction, amount; mistake.

The format of the resulting file may be as follows:

In some embodiments, based on the final file, recommendations are formulated for eliminating detected errors in the ATM based on user complaints. Aspects of the present invention may also be implemented using a data processing device that is a computer from a system (or means such as a central / graphics processor or microprocessor) that reads and executes a program recorded on a memory device to perform the functions of the above-described variant (s). a) implementation, and the method shown in FIG. 1, the steps of which are performed by a computing machine from a system or device by, for example, reading and executing a program recorded on a memory device in order to perform the functions of the above described embodiment (s). To this end, the program is provided to a computer, for example, through a network or from a medium for recording various types, serving as a storage device (for example, a machine-readable medium).

The data processing device may have additional features or functionality. For example, a data processing device may also include additional data storage devices (removable and non-removable), such as magnetic disks, optical disks or tape, for example. Computer storage media may include volatile and nonvolatile, removable and non-removable media implemented in any method or by any technology for storing information, such as computer-readable instructions, data structures, program modules or other data. Storage device, removable storage and non-removable storage are examples of computer storage media. Computer storage media includes, but is not in a limiting sense, random access memory (RAM), read-only memory (ROM), electrically erasable programmable ROM (EEPROM), flash memory or memory made using a different technology, ROM on a CD disk (CD-ROM), digital versatile disks (DVDs) or other optical storage devices, magnetic cassettes, magnetic tapes, storages on magnetic disks or other magnetic storage devices, or any other medium that can be used on to store the desired information and which the data processing device can access. Any such computer storage media can be part of a system for identifying and classifying the causes of user complaints in a self-service device. The data processing device may also include an input device (s), such as a keyboard, a mouse, a pen, a speech input device, a touch input device, and so on. An output device (s) such as a display, speakers, a printer, and the like may also be included in the system.

The data processing device contains communication connections that allow the device to communicate with other computing devices, for example over a network. Networks include local area networks and global networks along with other large scalable networks, including but not limited to corporate networks and extranets. A communication connection is an example of a communication environment. Typically, the communication medium can be implemented using computer-readable instructions, data structures, program modules or other data in a modulated information signal, such as a carrier wave, or in another transport mechanism, and includes any medium of information delivery. The term "modulated information signal" means a signal that has one or more of its characteristics changed or set to encode information in this signal. For example, but without limitation, communication media includes wired environments such as a wired network or direct-wired connection, and wireless environments such as acoustic, radio frequency, infrared, and other wireless environments. The term “computer readable medium”, as used herein, includes both data carriers and communication media. The sequences of the processes described in this document may be performed using hardware, software, or a combination of both. When processes are performed using software tools, the program in which the sequence of processes is recorded can be installed and can be executed in the memory of a computer embedded in the specialized hardware, or the program can be installed and run on a general purpose computer that can perform various processes. .

For example, a program may be pre-recorded on a recording medium, such as a hard disk, or a ROM (read-only memory). Alternatively, the program may be temporarily or permanently stored (recorded) on a removable recording medium, such as a floppy disk, CD-ROM (compact disc intended for playback only), MO (magneto-optical) disc, DVD (digital versatile disk) , magnetic disk or semiconductor memory. Removable recording media can be distributed in the form of so-called, sold through a retail network software.

The program can be installed from a removable recording medium described above to a computer, or it can be transferred by cable from a download site to a computer or it can be transferred to a computer via network data transmission channels, such as a LAN (local area network) or the Internet. A computer can receive a program transmitted in this way and can install it on a recording medium, such as an internal hard disk. The processes described in this document can be performed sequentially in time, as described, or can be executed in parallel or separately, depending on the processing characteristics of the device performing the processes, or according to need. The system described in this document is a logical set of multiple devices and is not limited to the structure in which these devices are installed in a single package.

Claims

FORMULA

1. A method for identifying and classifying the causes of user complaints in self-service devices, including the following steps:

• receive a set of user complaints in chronological order, arising from the use of self-service devices;

• allocate a group of user claims for analysis based on at least one requirement for the type and number of transactions, with each claim corresponding to at least one operation;

• receive at least one operation corresponding to at least one claim from the group of claims selected in the previous step;

• analyze at least one operation by applying text syntax, and

o perform line-by-line reading of at least one operation;

o determine at least one client session of the user based on the at least one operation;

o reveal at least one reason for the error on the user's operation;

• classify user claims based on user operations for which errors occurred in the self-service device.

2. The method according to claim 1, characterized in that, together with the recruitment claim of the user, receive a photo or video image of the user.

3. The method according to claim 1, characterized in that the resulting set of user complaints is filtered based on the type of operations that have occurred.

4. The method according to claim 1, characterized in that, upon receipt of a set of claims, users use the biometric identification of the user by voice to record his claim.

5. The method according to claim 1, characterized in that upon receipt of a set of user complaints, user operations are recorded automatically in the event log.

6. The method according to claim 1, characterized in that it identifies a group of user complaints related to failed operations, based on the proportion of affected users or products, or the degree of malfunction.

7. The method according to claim 1, characterized by the fact that there are a group of users' claims related to failed operations, based on their criticality.

8. The method according to claim 1, characterized in that the cause of the error is determined by a character or numeric identifier that uniquely corresponds to the type of operation and / or the type of error.

9. The method according to claim 1, characterized in that the classification of claims is carried out on the basis of errors found by the operating days of the self-service device and / or by the types of operations and / or self-service devices and / or types of event logs.

10. A system for identifying and classifying the causes of user complaints in self-service devices, containing:

• at least one self-service device;

• at least one data processing device;

• at least one data storage device;

• at least one program

Where one or more programs are stored on one or more data storage devices and executed on one or more data processing devices, with one or more programs including instructions for executing under item 1.