uniXchange
Remote file management system for kiosks, ATMs
Application sphere
Under direct control of almost each bank or a specialized outsource-company there
are from several hundred to several thousand of territorially allocated ATMs,
informational and payment kiosks which totality build a network of specialized
terminal devices for clients’ self-servicing (ATMs).
ATMs are connected to bank control servers via secure communication channels with
different transport protocols.
ATMs operate under different operating systems control using various software from
different vendors.
Such operations as ATM advertising banner files change, ATM work log-files
download, devices reboot, kiosk application version update, etc. are manually done
by maintenance staff either remotely for each device or directly at the place of the
ATM location.
uniXchange system provides
Centralized modification of advertising banner files on ATMs and kiosks.
ATMs grouping.
Each group can include ATMs which use different software for their work. The change
of advertising files is done for the whole group.
Access to ATM folder structure and file names inside these folders.
Access to the content of any ATM selected file located at the place indicated by an
operator.
Terminal part self-updating procedure support.
Access control.
Only properly authorized users have access to the system.
Support of ATMs performance via GPRS.
Absence of the static IP does not influence effective system performance as ATM itself
calls the update server and the size of a package transferred during one session is
adapted to a channel capacity as well as the time period between connection sessions.
1
uniXchange main features
Security
uniXchange uses existing secure communication channel between ATM and entire
bank network and does not require any additional protection for management
protocol layer.
All connections and information exchange between uniXchange client- and server
subsystems are executed separately and independently of corresponding ATM
software processes and does not influence them.
The client subsystem connects only to a bank server using the path specified in the
setup .ini file and does not accept any other connections outside of the local network
The client subsystem works only in the background mode and does not display any
information on the ATM screen. Graphic files transferred to an ATM are displayed only
using applied ATM software.
Virus control is done by an employee responsible for uploading the files to
uniXchange system.
ATM initiates communication session with the control server.
ATM reboot is initiated and done only by uniXchange system operator.
uniXchange system performs no other actions to the ATM software except saving the
image package to the definite folder, reading the folders structure and file content
specified by an operator.
The client subsystem saves only the following information to an ATM operating
computer disk to the specified folder: own setup .ini file, updated versions of the
code and image packages.
Obligatory login/password identification procedure for each uniXchange system user.
The rights to each user are assigned accordingly to his/her role in the system. A user
can have only one role.
Any activity in uniXchange system can be done only if a registered use obtains the
rights for this activity. Other activities are prohibited to be performed by the user.
uniXchange system logs all user activities applied to the subsystem server interface.
Log-files cannot be edited or cleared via subsystem server interface. ATM agent does
not keep any log-files.
Flexibility
uniXchange supports ATMs with the following operating systems:
Windows 2000, Windows NT4, OS/2 and Linux.
Windows XP,
Server subsystem with minimum configuration can be installed on a regular
workstation (PC) with Windows XP or Linux operating systems.
Design changing is done by uploading the image package directly to the definite
folder of ATM operating computer (the path depends on the ATM software) and by
sending the reboot command.
A package of images of new design is prepared externally and then is uploaded to
uniXchange system by an operator. A package can be simultaneously uploaded to
several ATMs chosen in the list with the help of filters.
2
System architecture
uniXchange is a client-server solution:
The client subsystem operates separately of ATM software and consists of two
modules: transport and operation.
The transport module connects the server and receives data and commands.
The operation module processes the received commands and data.
Server subsystem consists of administration and transport modules.
The administration module implements the user interface that allows managing the
ATM groups, uploading advertising banners packages to ATMs, reading out folder
structure and file content and rebooting ATM operating system. Activities applied to
the interface which influence ATMs are transformed into commands coming to a
transport module and being assigned to be sent to the ATMs.
The transport module receives ATMs requests and sends corresponding commands
and data packages assigned to the ATMs.
3
Main functions
ATM database maintenance
ATM adding into / delete out of the base
ATM activation / deactivation
ATM parameters control
Browsing the ATMs list with basic information (advertising banners package,
uniXchange system version, date of the last connection session, etc.)
ATM-matching search
ATMs grouping
Create / delete / change of a group description
ATM adding into / delete out of a group
Design management
Advertising banners package load / remove from the system
Operations with files
Browsing the selected ATM folder structure
Access to a file content inside the particular ATM folder
Updates management
New client code version upload to uniXchange system
Communications with ATMs
Sending the command to reboot an ATM or a group of ATMs
Sending the command to upload an advertising banner package to an ATM or a
group of ATMs
Sending the command to transfer file and subdirectory names inside the particular
ATM directory to the server (this command cannot be given to a group of ATMs)
Sending the command to transfer file content inside the particular ATM directory to
the server
Sending the command to update uniXchange system for an ATM or a groups of ATMs
Cancellation of the earlier sent command.
4
Main system objects and meanings
ATM ID
The identifier that defines the ATM being under the Company control.
ATM software ID
The identifier that defines ATM operating software type.
Software type influences the location of the folder to which the image package for
design changing must be uploaded. In the current uniXchange system version all
software types and corresponding paths are strictly specified with no ability for the end
user to manage the structure and the objects configuration.
One software type identifier is assigned to each ATM
Client subsystem version ID
The identifier that defines uniXchange® system client part version.
Design package
A set of images which form ATM software design is archived to one file.
Design package ID
The identifier that defines the particular design package.
Command type ID
The identifier that defines a client subsystem command type.
Command ID
The identifier that defines the particular command sent to an ATM (or a group of ATMs).
Interaction between server and client subsystems
Interaction between ATM and the server is managed via one command channel and
several data transfer channels.
Command channel
The command channel is managed the following way: periodically the client subsystem
initiates connection to the server, transfers ATM ID and receives the command to be
executed for the ATM (or a message with no commands).
Data transfer from the server to ATM channel
When receiving the command of data loading from the server (for example, a design
package uploading to ATM command), the client subsystem opens a separate
connection (physically, it may be a connection with a separate special data storage
server) and sends a request with command ID and ATM ID to the server.
In return, the server starts data transfer accordingly to the command.
Once the data transfer is completed and the command is executed, the client
subsystem reports the successful command execution results via the command
channel.
5
The performance confirmation is sent immediately after the successful performance
for the commands which do not require the data transfer. ATM reboot command
execution is successful, when the reboot is completed.
If the command is not executed successfully (for example, the data package is not
received or HDD writing fails), a failure report with a brief error description is sent via
the command channel.
Data transfer from ATM to a server channel
When receiving a command of the data loading from ATM (for example, file content
reading command), the client sub-system opens a separate connection (physically, it
may be a connection which has a separate special data storage server) and sends a
request with command ID, ATM ID and the requested data to the server.
In return, the server sends a confirmation of successful accepting or an error message.
Cancellation command
During the transfer process by the data channel, the cancellation command with
command ID, which has initiated the data transfer, can be transmitted by the
command channel. When this occurs, the client subsystem ceases the data receiving
and closes the corresponding data transfer channel.
The cancellation command may fail if the command being cancelled succeeded to
be executed on the ATM or if its execution has failed.
Contact for more details
Tel / Fax: +7 (495) 987 19 60
E-mail: contact@unitecsys.com
www.unitecsys.com
6