NL1044276B1

NL1044276B1 - Remote device driving platform for self service terminals (SST)

Info

Publication number: NL1044276B1
Application number: NL1044276A
Authority: NL
Inventors: Shternshis Alexey
Original assignee: Globalcloudpayments B V
Priority date: 2022-04-04
Filing date: 2022-04-04
Publication date: 2023-10-25

Abstract

A remote device driving platform for self-service terminals is provided. A set of SST driving applications packaged in containers is instantiated on a remote cloud/server for each SST 5 connecting to the platform. SST software is designed in a thin client paradigm where peripheral devices are connected to remote device drivers residing inside the containers on a remote cloud/server. On the SST there is an open standard Operating System running the thin client, and exceptions handling mechanism is provided to handle network disruptions and complete unavailability of the remote services. All the SST vendor specific driving software is 10 deployed on the cloud/server side.

Description

Remote device driving platform rv & es & eed r oy | C Bae € Se r & & 8 | 5 8 Holl & (S ST 5

Inventor: Alexey Shternshis, residing at Dorpsstraat 27 A, 5061 HJ, Oisterwijk, Netherlands, whom made the invention on behalf of the patent owner as named below.

Patent owner: GlobalCloudPayments B.V, registered with the Dutch Chamber of Commerce under registration number 57732663, having its office at de Gruiter 5, 5253 RM, Nieuwkuijk, Netherlands.

Description

In the banking and retail environment, Self Service Terminals (SST) are used to automate processes in the cash cycle, examples include but are not limited to cash machines, self check- out devices in supermarkets. Cash machines are the largest type of SSTs with approximately 3.5 million devices installed globally, the typical life expectancy is between 5 and 15 years which is longer than the life of an operating system.

Where the SST runs on a Windows Operating System, it must be upgraded typically once in 5 years with a new operating system. Android and IOS devices need more frequent updates. In most cases the processing capabilities need an upgrade as the new Operating System does not work on the old hardware, becomes too slow or lacks support from the Operating System vendor. Application software is typically amended in case of a new Operating System to take advantage of new features or advanced performance.

All OS providers want shorter lifecycles, which catches out the SST operators that are faced with more change and more hardware changes. The requestor has an alternative approach to solve this problem: a An open source Operating System with a long support contract ® Small-sized computer/processor rather than a full-blown industrial PC $ The SST application software is operated not from the SST but from central cloud based servers.

Further below, the invention shall be described through the usage of diagrams.

Figure 1 is a general diagram of a system for a remote device driving platform for SST according to the designed concept.

Figure 2 is a diagram of a system designed to handle exceptional conditions where remote server is inaccessible or communication with the remote server is erratic and unstable.

Figure 1 is a high level diagram of a system 100 for a remote device driving platform for SST.

Only the components that are relevant to understanding of the embodiments are present on the diagram.

The system 100 is designed in the Thin Client paradigm where the terminal's processing unit {hardware and software} is optimized for establishing a connection to a remote server. i0 Terminal driving logic is kept to the minimum. The remote server 139 handles amongst others the following tasks: software updates, peripherals driving, transaction processing, SST monitoring, and other typical SST handling activities.

The system 100 consists of SSTs 110, network connections 120, remote server 130 {one or more or a cloud environment) and Administrative GUI 150.

SST 119 includes open standard terminal OS 111, web browser 112 with GUI 118 to interact with the terminal user, forwarding proxy 114 and a watchdog application 113 processing the commands to/from peripherals 115 within the logic as explained below.

Remote server 130 includes server OS 131 that provides common services for SST driving applications including (but not limited to) device drivers 133, SST Core 134, adapter application 135, SST log manager 136, monitoring agent 137. To simplify and automate server 130 administration and multiple SST driving container software 132 can be used. Such containers isolate each set of applications required to drive a single SST and provide a standardized approach for multiple SST: driving, without the need for any hypervisor software to be created, to be instantiated and to be run.

In an embodiment, administrative UI 150 and transaction participant Ul 160 are thin client Uls that can be accessed by means of any computing device such as mobile phone, a tablet, a laptop, a wearable processing device, a personal digital assistant (PDA) or a personal computer,

When terminal OS 111 loads on a SST 110 and connect via a Network 120, to a remote server 130, a Server OS 131 via the initialization mechanism loads a dedicated container 132 with a pre-configured set of SST driving applications. Container-wrapper 132 is optional. A dedicated set of SST driving applications 133-137 drives a single SST 110.

Transaction states that require input from SST user or transaction data to be shown to the customer are to be displayed via the Web Browser 112 and/or Transaction participant Ul 160.

Alf the transaction participant{s} inputs are to be captured by the Web Browser 112 and/or

Transaction participant UI 160 and transmitted to 5ST Core 134 via network 120.

SST Core 134 orchestrates the transaction flow as per the transaction scenario programmed/configurad within it. input/output from transaction participants via the Web browser 112 and Transaction participant U! 180 aswell as peripheral devices 115 is being processed by SST Core 134 and the commands are generated and sent to peripheral devices 145 if and when required.

All the administrative actions with the terminal to be performed via the Administrative Ul 150 that sends/receives messages to/from SST terminal 110 and its peripherals 115 through the

SST Core 134 to device drivers 133 and further to adapter 135, and finally to the forwarding proxy 1314.

All the activities performed on the SST and its peripherals are captured and stored by the 557 iS Log manager 138,

Monitoring agent 137 reports metrics and transaction logs to external monitoring systems.

In an embodiment, self-service terminal 130 is a device such as an ATM or a kiosk.

Figure 2 is a diagram of an exceptions handling system 200 that catches and processes exceptional conditions where remote server 130 is inaccessible far an SST 110 or communication between an SST 119 and a remote server 130 is erratic and unstable.

Forwarding proxy 114 buffers the input/output operations with the connected peripheral device 115 and makes the communication behave indistinguishable from the local one in terms of raw streaming performance. The input/output is local on SST 130, but it is still driven remotely by Remote Device Drivers 133. Such a scheme also prevents possible false triggering of security mechanism {if any embedded in peripherals 115).

Forwarding proxy 114 reads the data immediately to the buffer 116 and writes the date from this buffer 116 to the device port on demand. But at the same time everything is still driven by a server-side high level logic residing in SST Core 134, and the actual data is coming from and to the remote server 130,

Watchdog 113 monitors the connectivity metrics and makes decisions based on the level of network connection stability.

Watchdog 113 is preloaded with critical fixed scenarios to abort an ongoing transaction in case network connectivity metrics are not satisfactory to perform a normal transaction. Such a critical fixed scenario consists of minimum possible set of commands to abort the transaction to exclude unsafe states of SST 110. The scenario is specific to the set of peripheral devices and is being uploaded through the initialization process when Watchdog 113 connects to the SST core 134.

In an embodiment, a buffer 116 keeps only the io operations of the last transaction to secure the data. In a normal flow of events when SST core 134 fully completes the transaction without any exceptions the data is removed from the buffer 116.

In case of exceptional conditions, the SST core 134 restores the complete state of the transaction from the buffer upon reconnecting to the 55T 110.

Claims

Conclusions Dutch

Conclusion 1:

A system, consisting of this:

e a Self Service Terminal consisting of a computer (hardware and software) 5 with a set of executable instructions in a thin-client paradigm, and;

® peripherals of the Self Service Terminal, and;

® a set of applications installed on an SST computer to perform transaction processing, consisting of: o initializing a client operating system (OS} and application environment;

o forwarding the input and output commands from/to the peripheral devices to/from the drivers for external devices located in the server/cloud environment;

o displaying the transaction screens generated by the external web server assigned to the SST;

o maintaining the completeness and integrity of the transaction in exceptional circumstances, and;

a set of applications deployed on a server/cloud environment to perform transaction processing, consisting of: o processing the requests/responses generated by the peripherals when interacting with the SST user and generating the commands addressed to the peripheral equipment;

o processing and generating the transaction statuses according to the transaction scenarios located on the server/cloud side;

o providing the transaction screens to the SST display;

o monitoring and logging the 5ST status;

o providing the user interface to different user types through the terminal screens and external devices;

& The system according to claim 1, wherein applications that maintain the completeness and integrity of the transaction further include a buffer subsystem that locates the input/output operations to/from the peripherals. conclusion 1

Claim 3: The system according to claim 1, wherein applications that maintain the completeness and integrity of the transaction further include the watchdog subsystem that monitors connectivity parameters and locates transaction termination steps in the event that remote cloud/server applications become unavailable, claim 1 Conclusion 4: The system according to claim 1, wherein the self-service terminal contains: an ATM {ATM}, a self-service terminal {SST}, a self-service kiosk, a vending machine, an interactive terminal that facilitates an action or displays information for the customer to complete a retail transaction to automate and/or streamline, claim 1 claim 5: The system according to claim 1, wherein an external device through which a user manages the 587 or participates in a transaction is a personal computing device, such as a mobile phone, a tablet, a laptop, a portable processing device, a personal digital assistant {PDA] or a personal computer. conclusion 1

Conclusion 6:

A method, consisting of:

& initiating a special container and/or a set of applications. with SST control application for each connecting SST client operating system {05}, and;

8 linking each type of peripheral device to the corresponding device driver through adapter application and forwarding proxy, and;

® remote processing of transactions by the cloud/server applications by processing the data received from peripheral devices and controlling the peripheral devices by issuing the commands to the devices via the adapter application and a forwarding proxy, and; ® handling exceptions during transaction processing.

Claim 7: The method of claim 6, wherein exception handling further includes buffering incoming and outgoing messages to/from the peripherals from/to device drivers within the forwarding proxy. conclusion 6 Conclusion &:

The method according to claim 6, wherein exception handling further includes preloading the cloud/server application assigned to the SST into the watchdog of parts of transaction scenarios to abort the ongoing transaction in a controlled manner in the event of exceptions that occurred. conclusion 6 Conclusion 9:

The method according to claim 6, wherein exception handling further includes monitoring a network connection by a watchdog application and aborting the transaction locally in the event of a lost or interrupted connection. conclusion 6