WO2015015406A1

WO2015015406A1 - System for distributing software applications to pos payment terminals

Info

Publication number: WO2015015406A1
Application number: PCT/IB2014/063498
Authority: WO
Inventors: Pierluigi SIMONETTA
Original assignee: PAYBAY NETWORKS Srl
Current assignee: PAYBAY NETWORKS Srl
Priority date: 2013-07-30
Filing date: 2014-07-29
Publication date: 2015-02-05
Anticipated expiration: 2016-01-30
Also published as: ITGE20130075A1

Abstract

The invention relates to a system for distributing software applications on POS payment terminals through an architecture of the client- server type wherein the POS terminal is the client and it comprises an interpreter for a high-level programming language not related to the type of POS used, which client is able to communicate with the peripherals of the terminal, by using specific libraries of the terminal itself, and with the server by means of procedures allowing remote processing requests to be sent, the server comprising software applications that can access a database interfaced or interfaceable with said server directly or through suitable gateways and that are able to receive and process the requests of the client for providing structured data as a response, the client- server communication being possible to be sporadic and limited only to the exchange of said requests and the relevant data.

Description

Paybay Networks S . r .1.

SYSTEM FOR DISTRIBUTING SOFTWARE APPLICATIONS TO POS PAYMENT TERMINALS

The invention relates to a system for distributing software applications to POS payment terminals.

POS terminals for the payment by debit or credit cards are very widespread devices (they are present in many stores or shops) which are more and more used also for providing VASs (Value Added Services) such as, for example loyalty programs such as earning points, discount vouchers and the like.

The most widespread POS terminals in the market, such as for example those provided by Ingenico and Verifone, use proprietary operating systems thus providing APIs different from each other for accessing the hardware .

This leads to a great heterogeneity of operating systems and of APIs that forces software developers to rewrite applications for each type of platform. VAS applications in the market are developed for a specific terminal type and are not portable to other terminals, it results in the lack of a common software application distribution system for the different existing platforms .

Therefore an aim of the present invention is to provide a system able to distribute VAS applications as independently as possible from the type of POS device on which they will be used. As an example and not as a limitation, such VASs can comprise:

• applications for distributing loyalty points related to a specific purchase or to specific purchased items;

• applications for distributing discount vouchers related to a specific purchase or to specific purchased items;

• prize competitions that in connection with a purchase allow a game to be played, which may result in a win or not ;

• electronic management of arrangements signed by the retailers, such as lunch vouchers, electronic ticketing, discounts for facilitations;

· management of prepaid reloadable cards (e.g. cards given at the cinema) and not reloadable cards (gift cards) that allow goods and services to be purchased at reduced prices, active on the individual shop and/or on the whole network (e.g. cards usable in different cinemas of the same manager) ;

• integrated management on the same terminal of the payment by credit and debit cards.

It has to be noted that the security requirements have led all terminal providers to have a payment application certified and separated from any other applications present in the POS. The only functionality provided by the certified payment application is the management of a payment by receiving an amount as the input parameter and at the end by giving a result of the transaction performed. Considering this, one of the aims of the present invention is to provide a distribution system able to manage the payment application as one of the several applications for being able to guarantee a greater interoperability among the VAS applications and the payment application itself .

A very important problem is the update of the software on installed terminals. Usually the number of installed terminals is considerable (in the order of some thousands) and very often it is necessary to update the software contemporaneously on all the installed terminals.

Usually the software is provided to be updated such that the user of the terminal does not suffer from any inefficiency. Very often the updating of an application software takes a considerable period of time for each terminal, due to:

• the size of the application software;

· the reduced bandwidth of the used communication channel.

Usually therefore the update of the software is provided to take place in the period of time when the terminal is not used. However the stores tend to remain open all day with "extended" time therefore more and more often the time ranges when the terminals are not used are reduced to the night hours.

A very common problem is related to the fact that during the night retailers very often do not power the terminals in order to allow software to be updated, therefore a complete update of all the installed terminals could be completed even in the space of some months .

Therefore a further aim of the present invention is to provide a system for distributing software in a POS environment that is able to manage the relevant updates on the terminals in an optimized manner.

The invention achieves such aims by providing a system for distributing POS applications of the client- server type within a particularly advantageous arrangement .

Software distribution comprises sending, configuration, installation and maintenance of a particular software version.

Within an application context of a client-server architecture the functional requirements that software distribution must have are the following:

• versioning management

• automatic installation and configuration;

· incremental update.

All this by considering security and the good scalability of the system.

Applications are developed by using existing libraries and frameworks that have a life cycle independent from the one of the application. It is necessary for the solution to manage the library versioning in a transparent manner.

The installation and configuration have to be automatic avoiding any problems deriving from an intervention from the outside. The release of new versions that correct or introduce new functionalities has to correspond with the update of only the modified components. The importance of such requirement increases as the size (footprint) of the application increases and as the number of devices to be updated increases, this is mainly due to the limit in the available network bandwidth.

Security has to be met in order that only the authorized devices can install the application and in order that the installed application is the one desired to be installed, and therefore it is not modified in a non-authorized manner.

The increase in the number of devices or in the size of the application has not to be a problem for the whole system that has to be planned and designed for being scaled as the requests increase.

Below there are shown various types of architectures used for distributing the software in systems of the client-server type, characterized by how the work load is divided between client and server.

This division results in providing various types of clients, such as:

• Thick client;

· Thin client;

• browser based client;

• Smart client.

As regards the software in a Thick client the application is run by using the resources of the client system, with no need to continuously communicate with the server. The server is mainly used as data storage.

On the contrary in a Thin client the application is run by the server and the client contains only the bare necessities for providing the interaction with the end user.

In order to better understand this difference, we can consider an application software as composed of the following three levels:

• Presentation: it is the displaying part and interacting with the user (View) ;

• Logic: it contains the business logic, that is the part of algorithms that evaluates, takes the decisions and carries out the computations; it acts as an intermediary between presentation and data levels;

· Data: it represents information contained in a persistent storage (e.g. file system or database) .

In such characterization a Thick client implements the two first levels and potentially a portion of the third level. In the case of a Thin client on the contrary it only implements the first level and the second and third levels are assigned to the server.

The difference between thin and thick clients is:

• thick clients do not require a permanent connection to the server, therefore they can work offline, while thin clients require a permanent connection;

• thick clients require fewer server requirements or equivalently one server can handle several clients; • thin clients require a higher network bandwidth;

• thick clients can run applications that require high graphic performances .

In the last years the web-based model is increasingly developing besides the client-server architecture. In this model the applications become web applications, that can be accessed by the users through internet network or intranet network. We can consider web applications as a variant of the client- server architecture wherein the software (web page) is downloaded by the browser that deals with interpreting the code and with displaying it, actually acting as a thin client. Web applications are coded by the javascript programming language or by the HTML markup language, which are languages that are supported by a wide number of web browsers.

The advantage and disadvantages of such model are the same as the thin clients and in addition:

· they have the advantage of exploiting the diffusion of web browsers on many platforms, thus making the application a cross-platform one;

• they can perform simple computations by means of Javascript language, which is used to make the pages as dynamic, by modifying, adding, hiding and validating elements of the page;

• it increases the security level, by interposing between the application and the underlying operating system a software layer (the browser) that limits/controls the access.

A limit of web applications is the fact of being bound by the document oriented model typical of the HTML markup language, limiting the potentialities of the common graphic interfaces of the applications.

The needs of inserting features that are typical of thick clients such as:

• to run applications requiring high graphic performances ;

· not require a permanent connection to the server,

however without losing the advantages of the web applications, has led to the generation of RIA applications (Rich Internet Applications) .

The installation of a framework in the form of a plugin for the browser allows applications typical of desktop environments to be run, leading to the creation of those that are called as Smart Clients. The most popular languages/frameworks are: Adobe Flash, JavaFX, Microsoft Silverlight, even if all leads to think that they will be replaced by alternatives based on HTML5/JavaScript standards.

As regards the problems related to installation and update, the client-server systems described above have the following characteristics.

THICK CLIENT

In a software architecture of the thick client type, the application is directly installed in the client device. It will use the resources and it will exploit the typical characteristics of the device and the communication with the server will be sporadic.

A software distribution model that meets the characteristics outlined above has to provide ad hoc functionalities on the client and server sides.

The requirement of versioning management requires the knowledge of the version currently installed by each client.

If information is kept by the client, for example as a parameter directly in the application, it will have to communicate to the server the version currently therein. This can happen by means of an ad hoc communication performed in predetermined specific moments, or as additional information provided in each communication made by the client to the server, or finally by a combined handling, both at each communication and at specific moments.

If information is kept by the server, it will have to arrange a table containing information about the version installed on each client and it will have to keep it updated after each update of the client. In this case a logic has further to be arranged allowing the occurred and correct installation of the application to be confirmed. This can be achieved by an ad hoc message or as additional information in a client-server communication (for example the first) .

The differences between a solution where information is kept by the client with respect to a solution where it is kept by the server are:

• a greater use of the communication bandwidth, due to the transmission of the version at each connection;

• simplification of the handling on the server side .

The fact that the server identifies the need for a software update for one, or most likely, a group of clients brings the system in the condition "handling the retrieval of the automatic installation package" .

The package retrieval can occur:

• within a single connection or split in several blocks on several connections;

• within an ad hoc connection or within a general communication.

Let us consider the advantages and disadvantages of all the four possible combinations.

The case of retrieving the package in a single connection within an ad hoc connection provides the server to inform the client about the need for a software update. As in the previous case, this can occur as additional information as a reply to one of the client-server messages, in an ad hoc connection (for example joining it to the possible transmission of the current version) or within the same package retrieval connection.

By considering that the whole installation package is sent, the problem of a contemporaneous request made by several devices can become a problem for band occupancy. In order to overcome such problem it is necessary to carry out a scheduling plan, and causing the server to arrange a configuration for each client defining the day and the time of the connection. The decision of how to make the package retrieval becomes an important choice. If the retrieval is made in the period when the device is used (e.g. during the day) , this can affect the normal activity; at best leading to a slowing down of the performances due to the use of the band if the retrieval takes place in background or even worse with a temporary stop of the activities if the retrieval takes place in foreground.

If on the contrary the retrieval is made during the period of non operation (e.g. during the night) there may be the problem that in such period the device is off and therefore the download (and the following installation) is postponed, resulting in the device using for long periods a non-updated version.

The case of the package retrieval split in several blocks (chunks) on several connections within a general communication tries to solve the problems deriving from the scheduling for the package retrieval.

This solution provides the client to carry out a procedure for reconstructing the complete package as a union of the individual blocks, paying particular attention to the handling of the corruption and duplication of the blocks, providing the request of transmitting again individual blocks.

The main problem of such solution is to find the proper size of the individual blocks, which has to be a good balance between:

• not too much big in order not to affect the normal activities;

· not too much small in order not to run the risk for the complete update to take a very long period of time.

All this depending on the available bandwidth, the number of the generic connections performed and the complete size of the package.

Moreover it has to be noted that splitting the package in several blocks leads to an increase in the transmitted data, considering that each block needs additional information such as :

· version of the package to which it refers

• offset of the block in the entire package

• control of the block correctness

The case of the package retrieval in a single connection within a generic communication has the advantage of allowing the device to be updated as soon as possible but it has the problem of making the device non usable during the normal activity.

Finally the retrieval of the package split in several blocks in an ad hoc connection could, even if for short periods, led the performances to slow down due to the use of the band if the retrieval takes place in background or it could led to a temporary stop of the activities if the retrieval takes place in foreground. There is still the problem of determining the size of the blocks typical of the cases of splitting the package and of the overall increase of the transmitted data. In addition there is also the problem that in order to end the complete update of the package multiple connections are necessary, which could led to an additional cost. In order to meet the automatic installation and configuration requirement suitable functionalities are necessary on the client side, and in many cases a close interaction with the procedures made available by the operating system or with the possible framework is necessary.

The incremental update requires the software to be structured such that it can be divided in parts. The mode used for dividing the software has a close relation with the programming language used and with the functionalities made available by the operating system or the possible framework.

For example by using the C or C++ language this can be implemented by the use of dynamic libraries, but if we think of Java language, executed in a Java

Virtual Machine, it is possible to update the individual classes that compose the application.

This leads to a more fine versioning system, that keeps information about the version and the confirmation of the real update not only of the application but of all the parts it will be composed of.

As regards the security a mutual authentication and an encryption of the transmitted package are necessary.

THIN CLIENT

In a software architecture of the thin client type, the application is run on the server that communicates to the client the result of the computation. The client has a software installed therein which acts an intermediary between the server and the device to allow the interaction with the end user.

The client will communicate the operations made by the user to the server that depending on the application logic will provide the result of the computation.

This architecture involves a continuous communication with the server that will use the device as a Terminal.

Now let us analyze the requirements of the application to be distributed. As regards the requirement for the versioning management, the application is kept and run in the server, therefore the client will always use the most updated version, or at least the most suitable one on the basis of the logics implemented in the server. It is not necessary to keep information about the version in the client, but the server keeps the track of the version to be used.

The requirements of automatic installation and configuration of the application to be distributed are always met since no installation or configuration is required on the client side, as well as an incremental update has no more sense in a context where the client acts as a Terminal .

A different matter regards the software installed in the thin client which acts as an intermediary between server and device. Even if such software is not affected by the particular application or version of the application that will be used, it is important to consider that an update thereof can be necessary for correcting or introducing new functionalities. Therefore even for such software it is necessary to arrange a distribution model, with considerations similar to those made about the thick client.

In this model security considerations have to consider all the communications from and to the server, with algorithms for the mutual authentication and encoding of data.

By means of this model and therefore by means of the separation between logic (server side) and display (client side) , there is the possibility of developing the application (server side) by using a programming language different from the language used for developing the software on the client, or more generally it is possible to use a language not supported by the client. The main aspect is to have an encoding shared by the client and the server. A further consequence is a simplification of the portability process of applications with respect to a thick client model. In the case of a thin client it is necessary to make the porting only of the software on the client, and not of each application.

In the case of thick client the portability can be guaranteed only on condition that the application is developed in a common framework or that the application is run in a virtual machine. In the first case it is necessary to keep a different version for each system, while in the second case it is necessary to have a virtual machine for each system.

It is important to point out the difference in the complexity between software of the thin client and a virtual machine. The software for thin client has to be able to receive and display information sent by the server and to be able to send the data entered and the actions made by the user to the server. On the contrary a virtual machine is a programme that creates a virtual environment wherein an application can be executed as it were in the real machine.

From such considerations it may be deduced that this model is better not only because it considerably simplifies the problems related to the management of the software distribution but also because it involves advantages, such as those about the use of different client-server programming languages and a more easy implementation of the portability.

The critical aspect of such model is the need for a continuous connection with the server and a band occupancy that increases as the number of connected clients increases. In this context the choice of the encoding to be used for the client-server communication becomes essential, it has to be a compromise between versatility and amount of transmitted data.

BROWSER BASED CLIENT

The feature that characterizes the browser based model is the use, on the client side, of an application called as web browser. The basic functionalities of a web browser are:

· recovering a resource that is at an address provided as an input parameter and specified according to URI format (Uniform Resource Identifier) by using network protocols such as HTTP , HTTPS, FTP , ...

• displaying information contained in the recovered resource by a rendering process.

HTML is the main markup language used by the browser for creating web pages.

A HTML document is composed of a series of tags allowing the following to be specified:

• the structure of the document, by diving the document in several sections;

• the appearance of the text such as bold, italics , ... ;

• the structure of the text, defining header, paragraphs , ... ;

• lists, repertories, tables;

• fields that allow the user to enter data;

• the insertion of images, audio, video;

• description of the formatting by a language of Cascading Style Sheet (CSS) type;

• hyperlinks for creating a reference between documents;

• references to external applications developed with script languages.

The script language used by most browsers, and in many cases the only one supported, is Javascript, a language :

• imperative: it shares with C language much of the structured programming syntax; • object-based dynamic: properties and values can be added, modified and deleted at runtime;

• dynamic typing: typical of scripting languages, wherein the data type is associated with the value and not with the variable;

• functional, with first-class functions, nested functions with lexical closures: functions can be assigned to variables, passed as argument or returned to other functions; it is possible to define functions inside other functions wherein the local variables of the outer function become part of the inner function;

• prototype-based: there are no classes and the inheritance among classes is implemented by a cloning process .

Javascript engine is a Javascript interpreter that allows Javascript code to be executed. A web browser comprises a javascript interpreter and it creates objects in Javascript that represent the Document Object Model (DOM) of the HTML page. This allows Javascript code to be developed which interacts with information contained in HTML page, by allowing for example :

• to hide, display, dynamically inserting parts of the displayed web page;

· validation of the inserted input;

• animation of the components of a page, by moving them, resizing them, ... ;

All the above without communicating with the Server, but by executing the code directly on the clien .

In this context it is important to point out that the browser creates a protected environment wherein the Javascript code cannot access directly to I/O resources of the system. Scripts are run in a "sandbox" that allows only "web-related" actions to be performed, and the data that can access depend on the script origin, therefore the script obtained from one domain cannot access information sent to another domain.

The definition of "web-related actions" is certainly generic, but it follows the web evolution and consequently the standards developed by the World Wide Web Consortium (W3C) . For example the access to the file system in a web application currently is not allowed, but there is a suggestion for a specification for HTML5 that provides the possibility for a web application to create, read, write in a "sandbox" section of the local file system of the user.

We can believe, at a first analysis, that the considerations about the software updating models are the same as those in the discussion about Thin clients.

However the possibility, by using Javascript language, of creating application logics directly on the client side allows the continuous communication between browser and server web to be avoided. Moreover it is possible to create an application that does not need any communication with the server, therefore leading to a Thick client context with the portability guaranteed by the browser web.

There is still the problem that, both in the case of an application divided on several resources and, even more, on complete applications, each time the browser accesses the resource, it has to completely recover it . In order to try to overcome such problem, the browser webs are equipped with a cache functionality called "web cache" . This functionality allows a copy of the data sent by the server to be kept as local (on the client) , such not to require it every time. There are several mechanisms for verifying that the copy present in the cache is not obsolete; these methods are part of the HTTP protocol .

A method provides to indicate in the HTTP response sent by the server the validity time of the resource, in the form of expiry date rather than time expressed in seconds within which the resource can be considered as valid.

More complicated methods provide a handling called "web cache validation", wherein the client is allowed to make conditional requests avoiding downloading the resource if it is still valid (that is if it has not been modified) .

The most widespread method relies on the date of the last modification of the resource and it provides the client to send a request of the "If-modified-Since" type indicating the date shown in the "Last-Modified" field present when it has received the resource (information stored in the cache) . The server can reply with a "Not Modified" if the contents has not changed or with the updated resource.

An alternative method, introduced in HTTP 1.1 and called as ETag, is to create unique identifiers, ETag, generated by the server as a function of the page to be sent. They have been introduced to overcome the problems deriving from the dynamic creation of resources (e.g. resources containing data read by a database) . There is no specification about how to create the ETag, but it is not recommended to use simple methods such as CRC32/64 checksum methods that are not "collision resistant" .

SMART CLIENT

Smart clients use the diffusion of browser webs to make web applications still more · similar to desktop ones .

Netscape Plugin API is a cross-platform plugin architecture used by many web browsers. It allows the resources of the machine to be accessed with the same privileges with which the browser is run. Therefore the application is not run in the sandbox.

The considerations about the software updating model are the same as those mentioned in the discussion about Browser based client.

By considering software distribution models of the client- server type described above and the requirements of POS system already pointed out above and shown below for a better interpretation:

• possibility of handling applications online and offline on different POS terminal models.

• applications have to be compatible with all the terminal models without the need of being recompiled/rewritten; • possibility of handling the payment application as one of the several applications in order to guarantee a greater interoperability between VAS applications and the payment application;

· making available for the end user a "store" of existing applications such to market and distribute the services on the customer request;

• making available for the developer a simple development environment with a rapid learning object language to allow the APP store to be used as much as possible,

the following solutions are possible:

a first solution belongs to the thick client model. For example this is the case of the Ingenico system called as Sfinge (INGEnico loyalty system) , which is characterized by a completely configurable application loaded in the terminals.

Sfinge is a loyalty and electronic payment system, suitable for private circuits. It allows effective commercial promotions to be made and it allows customers to be handled in a valid manner.

The system is based on smart cards that can work as payment cards (pre-paid cards) or as a simple collection of points or discount management. It uses Ingenico terminals suitably equipped with the Sfinge management application and it is joined by a central system with a detailed database that enables accounting and specific marketing actions.

The modularity of Sfinge allows the installation in several application environments: from the single shop to great chains of shops coordinated by a single Terminal Manager or networks of only one retailer with several stores.

This system, even if it is very powerful since it is able to work completely offline, however suffers from the problem related to the software update.

A second solution belongs to the thin client model. The acceptance device is considered as a Terminal and all the logic is on the server side such that the device has to be always online. This solution has the considerable advantage of simplifying the application update handling, typical of thin client models, but it has the disadvantage of not being able to be used in an offline solution. This limit does not meet the required requirements, making this solution not acceptable.

A third solution provides to insert functionalities on the client side that incorporate logics (for example the control of the flow for navigating among the several screens) suitably studied with the aim of running parts of the application or, depending on the type of application, also the entire application, without a constant communication with the server. This solution is similar to the one suggested by Ingenico with the Incendo product. Incendo follows the Thin Client model and for many aspects it is similar to the Smart Client concept. It is characterized by a browser application loaded on POS terminals that provides the possibility of downloading a part of application logic in order to use it in offline mode.

Incendo is a solution allowing payment and loyalty applications to be used on Service Providers of the customer that through the Incendo online gateway communicate with the Client Incendo application loaded in POS terminals.

There is provided the possibility of monitoring/handling POS terminals by customizable web applications that are interfaced with gateway Incendo Online.

Ingenico further manages a web store for Incendo applications, where the service Providers publish their developed applications and the customers therefore can acquire the service provided by a list of services published on the web store.

The service providers develop their applications by using the normal web programming languages, Applications are sent to Incendo Client in the form of Terminal markup Language (T L) pages, an extension/customization of the XHTML markup language allowing interaction with the typical peripherals of the POS terminals.

The Incendo client is able to keep the cache of the downloaded pages such to handle in offline mode or in a mixed online/offline mode the downloaded application. A possible update of the application can be made by downloading only the modified page leaving the other already downloaded pages unchanged.

This solution therefore allows, even if with considerable limits, an application to be handled offline by trying at the same time to reduce the size of the downloaded software in case of update.

The advantage of this solution therefore is the simplification of the handling of the application update, which can be compared to the thin client model. As regards the offline management, it is possible, but it is bound by the type of application and more precisely by the functionalities required by the application. From the technical point of view it is possible to provide ad hoc functionalities that allow applications described in offline mode to be implemented, but it is immediately evident that the plurality of requests necessary for VAS applications is so wide that this model cannot offer a solution that can be easily adapted to the different needs.

The solution taken in the present invention, described in claim 1, exploits the characteristics both of system of the "Thick client" type in order to allow application to be run without a constant communication with the server, and those of "Thin client" type, for optimizing the update handling. This is due to the use, on the client side, of a programming language interpreter that enables both the application portability and the incremental update thereof in a native manner, particularly by dividing the applications into modules handled by a central server by means of a RPC system.

Among the several possible options ranging from the use of a web based solution by the implementation of an interpreter for the HTML markup language and the Javascript programming language to the use of virtual machines with Java, or to the creation of an ad hoc framework, the inventors have verified how the use of the Python interpreter developed for the several platforms is the optimal solution due to the fact that the Python language is already naturally prepared for the module handling of the applications and, therefore, for the incremental update.

Further characteristics and improvements are the subject of the subclaims.

Characteristics of the invention and advantages deriving therefrom will be more clear from the following detailed description of the annexed figures wherein:

- fig.l is a block diagram of a system according to the invention

fig.2 is the several levels forming the software structure of the multi -terminal platform of the system according to the invention.

In order to best understand the invention, an outline of the prior art of the main acceptance devices and of the relevant development tools is disclosed below.

Acceptance device means all those devices meeting the following requirements:

• data entry allowed

• data materialization allowed (e.g. printer) ;

• connection with a remote system allowed

• handling transactions of electronic payment. Under such characteristics we find all those devices that are classified as payment terminals. In this field there are two companies that compete for the Italian and global market: VeriFone and Ingenico. For each manufacturer we analyze the offered products, pointing out both hardware and software characteristics. We particularly focus our attention on the operating system, the programming language and the development environment used.

VERIFONE

VeriFone is a multinational company whose business is based on the management of payment solutions and relevant services .

It was founded in the United States in 1981, it operates in more than 110 countries and its offices are spread in more than 45 countries.

VeriFone Italia was founded in 2004 and it has sold in the national territory more than 500.000 terminals and payment solutions for the bank field, retail field, large enterprise retail field, transport field, public administration.

VeriFone offers two terminal lines dedicated to services characterized by two software platforms (VX evolution and Linux embedded) .

VX520, VX680 terminals and VX820 Pin pad are part of the conventional, high-performance terminal line, based on the VX evolution software platform.

They are equipped with an ARM 11 32 -bit processor, operating at 400 MHz, 32MB of RAM memory and 128 MB of Flash memory. While VX520 terminal rises as a countertop terminal, with optional battery compartment and GPRS module it can be converted in a portable terminal. Also VX820 Pin Pad in Duet configuration can use a thermal printer on the base thus making it possible to become a real terminal. VX680 and VX820 terminals further distinguish themselves by the provision of a color touch- screen display with the capability of signature capture.

The development environment provided by VeriFone is Eclipse equipped with a suitable plugin, that allows applications to be developed by using C/C++ language for the VX evolution operating system.

MX800, MX860, MX870 terminals by VeriFone are part of the line of multimedia terminals, based on Linux embedded software platform. They have an ARM 32 -bit processor, operating at 200 MHz, 64MB of RAM memory and 64MB of Flash memory. They are terminals dedicated to shops able to offer in addition to the management of payments, a series of value added functionalities by means of their wide touch screen display with possibility of signature capture and to optional devices such as scanners, bcr and printer.

The development environment provided by VeriFone is Eclipse equipped with a suitable plugin, that allows applications to be developed by using C/C++ language for Linux embedded operating system.

VX evolution

VX evolution operating system is an evolution of the previous Verix operating system used in conventional terminal lines. It is compatible with the previous version, allowing all the applications developed for Verix operating system not to be rewritten.

As regards the sw architecture an application can be developed to operate in stand-alone mode or in shared mode with other applications by the use of the suitable "manager" application that allows the irralti- application functionalities of the terminal to be managed.

The security on software side is managed by a software signature system. The software can be installed on the terminal only after having being signed by VeriFone.

Linux embedded

Linux embedded operating system is based on standard linux kernel to which improvements have been made by VeriFone as regards security related aspects .

INGENICO

Ingenico is a worldwide company whose business is based on the complete management of payment solutions and relevant services.

In 2008 it acquired Sagem, acquiring its new family of terminals and the relevant development environment .

In 2009 together with its two main competitors (Hypercom and VeriFone) it founded the Secure POS Vendor Alliance organization, whose target is to improve security of the payment solutions.

Ingenico has sold more than 17 million of terminals in the world in more than 125 different countries. From October 2000 the Italian affiliate Ingenico Italia is present in Italy which since 2011 coordinates also the activities of the Central Europe area (Czech Republic, Slovakia, Poland, Hungary and Baltic States) .

Ingenico offers three terminal families characterized by different software platforms (Unicapt, Telium and Telium 2) .

Ingenico i5100, Ϊ7780 and i7910 terminals are part of the family of conventional terminals, based on Unicapt software platform. They have a 32 bit ARM processor, 2 MB of RAM memory and 4 MB of Flash memory. The development environment provided by Ingenico is IngeDev, an extension of Eclipse, that allows applications to be developed by using C/C++ language for the Unicapt operating system.

EFT930S/B/G terminals are part of the family of high-performance terminals, based on Telium software platform. They have a 32 -bit ARM9 processor (named Thunder) , running at 200 MIPS, joined by a security 32- bit ARM7 processor (named Booster) , running at 50 MIPS, 8/16MB of RAM memory and 16/32MB of Flash memory. They have also the possibility of being equipped with a higher resolution color display (320x240 pixels compared to standard 128x64 pixel displays) . Moreover in comparison with standard terminals they have a USB connectivity as slave or master, therefore they have the possibility of connecting USB peripherals. The development environment provided by Ingenico is IngeDev, an extension of Eclipse, that allows applications to be developed by using C/C++ language for Telium operating system.

iCT200 and iWL200 terminals are part of the family of high-performance terminals, based on Telium2 software platform. They have a 32 -bit ARM9 processor (named Thunder) , running at 450 MIPS, joined by a security 32 -bit ARM7 processor (named Booster) , running at 50 MIPS, 8/16MB of RAM memory and 16/128MB of Flash memory. In addition to the system memory they can be equipped with a MicroSD reader. They have the possibility of being equipped with a higher resolution color display (320x240 pixels in comparison to standard 128x64 displays) . In comparison with standard terminals they further have the USB connectivity as slave or master, therefore they have the possibility of connecting USB peripherals. The development environment provided by Ingenico is IngeDev, an extension of Eclipse, that allows applications to be developed by using C/C++ language for Telium2 operating system.

Unicapt

Unicapt operating system is used in old generation conventional hardware platforms. Although applications for Unicapt can be developed by IngeDev environment, it is completely not compatible with Telium and Telium 2 operating systems. It requires the installation of a suitable SDK.

Telium/Telium2

Telium operating system and the most recent Telium 2, are provided in new high-performance terminals acquired from Sagem. The applications written for the two Telium operating systems are compatible, in the compiling step it is sufficient to select the reference platform for creating an executable that can be installed on EFT930 terminals or on iCT/iWL terminals.

Hardware Architecture

Telium is developed for managing the hardware architecture based on Thunder processor for running applications with a direct handling of non secure peripherals, that provides the Booster processor to be joined for managing security schemes and secure peripherals (display, keyboard, cards) .

For each peripheral of the terminal there is an identification id, a communication channel, events, common interfaces and synchronous and asynchronous functions for its use.

Software architecture.

The first software level, directly communicating with the hardware, is Telium operating system. The system provides always to install a basic application called as Telium manager that allows the several applications to be managed with specific priorities and it allows applications to communicate. At a higher level there are the user applications that can use Telium manager for exchanging data with other applications or Telium operating system for interacting with security module or hardware. Applications can use proprietary or ingenico add-on (static libraries) and dynamic libraries. Moreover there are ingenico support applications, such as for example Link Layer application dedicated to the management of the communication channel that can be used for delegating all the part of configuration and communication with communication hardware modules.

The framework provides a management of events based on the transmission by Telium manager of specific massages (button pushed, card slid, etc..) . The application can record its own managers of the event in the start step indicating a priority. This allows a chain of applications to be created for managing a specific event.

Telium operating system provides APIs for managing the memory areas by means of a file system. This allows files to be stored in separated application contexts.

IDE (Integrated Development Environment)

IDE for the application development is IngeDev, an extension of eclipse with all the plugins necessary to automatically run ingenico tools for software debug, trace, signature and uploading.

Operating system APIs

APIs provided by the operating system are divided in two categories.

The first category contains a series of C standard routines .

The second category contains all the specific routines for telium for managing the peripherals, the memory and specific security and platform functionalities :

• management of events

• management of display, text and graphic

• management of printer text and graphic

· management of keyboard • management of magnetic stripe cards

• management of chip cards

• management of communication modules in a direct manner

· management of communication modules by link layer

• management of stack tcp

• management of calendar

• management of usb ports

· management of MMC/SD/MicroSD;

• management of backlightening and buzzer

• management of tasks

• management of events and semaphores among tasks;

· management of communication between tasks by mailbox (FIFO message queues) ;

• delay management

• management of memory areas and file systems in RAM/Flash

· management of dynamic libraries (DLL) ;

• management of communication between applications (IAC) ;

• management of file systems by VFS driver on MMC/SD/MicroSB/USBDisk;

· management of software download

• diagnostic functionalities;

• additional libraries (management of TLV data, printing BCR codes, management of black lists) . Security

The terminals are PCI certified.

The HW of the terminal, the case, as well as the security module therefore allow operation in compliance with the specifications defined by PCI Concilium to be carried out.

The terminal has Tamper Detection characteristics typical of all the POS terminals dedicated to payments:

• detection of terminal opening

• detection of security module opening

• detection of keyboard membrane removal;

• detection of electronic card perforation;

• detection of change in supply voltage

• detection of change in room temperature.

In the case of the detection of one of the conditions above the terminal eliminates the contents of the secure memory, and it puts itself in a condition visually indicating (by a suitable flashing message) the "Alert irruption" condition.

Security on software side is managed by a software signature system.

Software can be installed in the terminal only after having been signed by a suitable tool which is provided by a specific request traced by Ingenico.

The signature software identifies the signing user by a card provided by Ingenico, signature policies are related to the card and cause the applications signed by the user to run only on the terminals defined by the policy. The security module provides operations by means of a DLL delegated to converse with the module. The module has to be configured by suitable security software (called as schemes) which is signed too. Functionalities provided by the security module therefore depend on the security scheme loaded therein.

Telium Manager

Telium Manager is the application operating with the terminal in the "idle" condition. It manages the configuration of the common parameters of the terminals, maintenance functionalities, dispatching of events to the loaded applications as well as the communication between applications.

The interception of an event in the idle condition is managed by Telium Manager that on the basis of the priorities, defined by the applications upon their registration, dispatches the event to the applications.

Therefore when turned on it interrogates all the installed applications for requiring a list of the events managed by the applications and the requested priority. Moreover it takes further information such as the name of the application and the required configuration functionalities.

The events managed by Telium Manager dispatched to the applications are:

· request of the massage to be displayed in the idle condition;

• request of common configuration functionalities to be activated;

• indication of software or hardware reboot;

· request of the application name • request of the application state

• indication of task button pushed (for managing the menu) ;

• indication of button pushed

· request of printing the ticket with application information;

• request of printing the ticket with totalization;

• request of printing the ticket with configuration of call scheduling;

• request of control and execution of automatic procedures;

• request of confirmation of the change of the configuration of common data;

· indication of the change of the configuration of common data;

• request of confirmation for starting the remote management with TMS;

• request of application removal;

· indication of reception of files from TMS:

• indication of reception of IAC messages from another application;

• indication of chip/magnetic stripe card insertion.

As regards the distribution of the applications, the company Ingenico uses the solution called as Incendo .

Incendo follows the Thin Client model and for many- aspects it is similar to the Smart Client concept. It is characterized by a browser application loaded on POS terminals that provides the possibility of downloading a logic application part such to use it in Offline mode .

Incendo is a solution allowing payment and loyalty applications to be managed on service Providers of the customers that by the Incendo Online gateway communicate with the Incendo Client application loaded on POS terminals.

There is the possibility of monitoring/managing the installed POS terminals by customizable Web applications interfacing with Incendo Online gateway.

Ingenico further manages a Web Store for Incendo applications, where the service Providers publish the developed applications and therefore the customers can acquire the service provided by a list of services published in the Web Store.

Service Providers develop their applications by using the normal web programming languages. Applications are sent to Incendo Client as Terminal Markup Language (TML) pages, an extension/customization of the XHTML markup language allowing interaction with the typical peripherals of POS terminals.

The Incendo client is able to maintain the cache of the downloaded pages such to manage in offline mode or in a mixed online/offline mode the downloaded application. A possible updating of the application can be made by downloading only the modified page by leaving the other pages already downloaded as unchanged. This solution therefore, even if with considerable limits, allows an application to be managed offline contemporaneously trying to reduce the size of the downloaded software in case of updating.

A very important characteristic that allows the interaction with payment systems is the PCI-PTS v2 and v3 certification obtained by Incendo system.

Incendo client

The client loaded on POS terminals is the browser (called as MicroBrowser) that interprets the pages in TML format provided by VAS service Provider through the Incendo Online gateway. The Microbrowser by using suitable plugins is able to exchange information with the application loaded in the terminal (such as for example ABI2 certified payment application) . Similarly the plugins allow the bidirectional communication with hardware components not natively supported by the MicroBrowser .

An example of the use of the plugin for a payment request by a TML application is as follows:

• the online application is run (by means of TML pages) on the terminal;

• during the application flow a payment is requested; the TML page calls the plugin giving it some parameters (amount, payment type, etc..) ;

• the plugin calls the payment application initializing it with the parameters given by the browser;

• the payment application gives the control back to the plugin by giving the payment result; • the plugin suitably formats information and activates again the browser, allowing the application flow to go on.

A very important characteristic is the management of the cache by the MicroBrowser that allows all the static pages, the dynamic pages for which caching is enabled, the style sheets CSS and images to be kept in the memory, avoiding all such information to be downloaded from the service provider.

Terminal Markup Language

The TML language is a XML language based on a proprietary schema and it is used for developing applications for Incendo system. The TML language for MicroBrowser is comparable to HTML language for a web browser.

It is used for defining not only the contents that has to be displayed on the terminal display but also for defining the contents that has to be printed with the thermal printer of the terminal and it defines all the data that have to be sent from the terminal to the service Provider.

It is based on XHTML, thus certain code portions, especially those related to data to be displayed and printed, can be written in XHTML. Not all of the XHTML elements are supported, while new elements have been added for managing the peculiarities of a POS terminal.

The common concepts for reduced size monitors of the POS terminals derive from WAP WML, for example the pages and TML screens are similar to WML documents and pages, even if these concepts have been generalized for matching the specifications of Ingenico POS terminals and the specifications of payment cards.

TML language has been designed for supporting also the payments. It provides specific functionalities in order to work with the most widespread types of payment cards in the market. It supports magnetic stripe cards and EMV chip cards. By using the TML language it is easy to develop applications supporting transaction flows for cards of both the types. The specific elements <card> and <pinentry> of TML language provide the interaction with card readers and PIN pad. Thus the application can read the data of the card, manage the risk management (EMV) and can verify the PIN and authorize the transactions using these two elements. The specific element <card> allows standard magnetic stripe and EMV payment flows to be managed by using parametrizations required to the service Provider in a specific session. By the element <card> it is therefore possible to manage the payment steps by using the certified functionalities of the MicroBrowser . It is further possible to read proprietary magnetic stripe cards, taking the contents of the ISO traces of the cards .

TML language supports also the CSS for describing how the documents are displayed on the monitor by the MicroBrowser. By using the CSS the developers therefore can control the look of the pages displayed on the terminal. The TML CSS is a subset of CSS standard adapted for reduced size monitors. An advantage of using CSS in addition to separate the logic from the look of the displaying is the possibility for the MicroBrowser to store in the cache the style sheet and therefore not to require it to be loaded when each page is displayed.

In order to enable a logic for managing the flow of offline TML screens the language provides tags for managing :

• valorization of volatile and non-volatile variables containing the user input or explicitly assigned;

• the management of the flow conditioned to the value of the variables;

• the management of the flow conditioned by the Boolean return value of the functions made available by MicroBrowser;

• storing offline posts to be sent once connected with the service Provider;

• storing log, identified by its own id, as groups of variables, to be sent once connected to the service Provider.

The functions made available by the MicroBrowser, with Boolean return value, allow:

• to cancel all offline posts;

• to print all offline posts;

· to cancel the cache;

• to cancel one long by indicating its id;

• to require the connection to the service provider further requiring to update the cache, to send the offline post or to require the configuration for managing the payment by tag <card>;

• to require the disconnection to service Provider.

Definition of TML screens

TML language is very similar to XHTML. A difference with XHTML language is that a TML page can define several screens processed as different entities by the MicroBrowser . This is for reducing the traffic between the MicroBrowser and the service Provider. A TML screen defines data that can be displayed on the display, printed on the printer or sent to the service provider. Each screen is identified by a URI and it is used for explicitly defining the management flow of the screens . The type of screens managed by TML language are:

• Display: they are displayed on the terminal display, they can contain graphical objects, links and forms for accepting the data input;

• Print: they are printed on the terminal printer;

• Terminal form: it is used for the input of secure data such as card and user PIN data;

• Submit: it is used for sending the input data sent by the user to the service provider;

· Functional: it is used for defining the calls to the routines of the MicroBrowser.

The exchange of data between the various screens and the storage of the data occur by means of the volatile and non-volatile variables (saved in Flash and available also after restarting the terminal) managed by the MicroBrowser .

Therefore the structure of the application provides a flow managing the screens dedicated to the displaying and printing, with the addition of auxiliary screens for example used for setting the variables and for reading the card data.

Even in this case, the advantage of such solution is the simplification in the management of the application update, which can be compared with the thin client model. As regards the offline management, it is possible but it depends on the type of application, and more precisely on the functionalities required by the application. As regards the technical point of view it is possible to provide ad hoc functionalities that allow the described applications to be implemented in offline mode, but it is immediately clear that the variety of the requests required by VAS applications is such wide that this model cannot offer a solution adaptable to the different needs. This results in the activity of the inventors that have solved the problem of the distribution of application to POS terminals by using, on the client side, an interpreter for a programming language allowing applications both to be portable and to be incrementally natively updated, particularly by diving the applications into modules managed by a central server by means of a RPC system.

According to a particularly advantageous embodiment, the invention provides the development of the client server applications distributed in the POS field in Python language.

Python language developed by Guido van Rossum in 1991, is a high level programming language designed such that its code could be the most readable one. It is a multi -paradigm language, mainly oriented to objects, imperative, structured, functional, with a dynamic typing system.

In comparison with other languages it is more easily suitable for being spread among developers thus actually increasing the number of persons that can create applications in the APPstore.

Client side

The client part of the application is composed of software packages developed with Python, each package is composed of a set of Python modules. Each package is a unit that can be updated individually from the rest of the application allowing the incremental update.

For each POS architecture it is necessary to develop a Python interpreter and a set of libraries allowing the specific peripherals of these terminals to be used. Considering that the systems treated in this study are based on C programming language, the implementation will be based on Python interpreter called as CPython. CPython is a bytecode interpreter, and it is the default implementation. It further provides an interface for entering functionalities developed with C/C++ language. The core of Python interpreter is joined by the Python standard library.

The library contains functionalities that can be grouped in the following issues: • text processing functionalities;

• data type such as date time, calendar, collections , ... ;

• mathematical modules;

• file and directory access;

• data persistence;

• data compression and archiving;

• file formats;

• cryptographic services;

• generic operating system services, such as io streams, command line options, ...

• concurrent execution;

• interprocess communication;

• internet data handling such as email, json, mailbox, ...

• Xml processing;

• internet protocols, http, smpt,.../

• multimedia services, for manipulating audio, images , ...

• internationalization support;

• programming frameworks, such as syntaxes analyzers;

• graphical interface with Tk;

• development tools, for generating documents, for uniitest, ... ;

• debugging, trace and timer functions,

• runtime services, such as interface of garbage collector, inspect of objects,... This list can be divided in two categories, one representing the modules that provide access to system functionalities and another one that provides standard solutions for frequent problems in programming.

This aspect is important as regards the considerations related to library portability. All the libraries that are developed with no relations to the underlying system are easily portable, for all the other ones this leads the modules (written in C) to be rewritten for the access to the underlying platform. Fig.2 shows schematically the level structure used in one embodiment. The POS terminal has a hardware to which a structure called as Application Framework is interfaced through the operating system with the related libraries. The application developers work at a high level without the need of worrying about what platform will be used by the terminal since an intermediate platform is provided called as PMP (POS Market Place) able to interface with the terminal through specific libraries depending on the type of terminal .

In order to keep the size of the footprint of the library as small as possible, it is advantageous to identify all and only the modules necessary for developing applications on POS terminals, finding a proper balance allowing the access to all the most important functionalities to be guaranteed.

From the list above we can immediately understand how the functionalities such as multimedia services, audio manipulation, image manipulation, programming frameworks, such as syntaxes analyzers, the graphical interface with Tk, a part of the general operating system services, such command line options, the concurrent execution, interprocess communication are not necessary.

Functionalities like the file and directory access and general operating system services such as input output streams have to be rewritten depending on the underlying platform.

Besides the standard Python library it is necessary to provide libraries that allow the communication with specific peripherals of POS terminals implementing the following functionalities identified as:

· display management;

• print management;

• chip card and stripe card management;

• management of the communication with a possible payment application

· management of the communication with existing proprietary applications.

As regards the display management, the development of a library containing the following graphical components is provided:

· Container with horizontal queueing

• Container with vertical queueing

• Label

• Numerical input

• Alphanumeric input • Password input

• Decimal numeric input

• Confirmation input

• Multiple selection input

Print management on text ticket with:

• indication of normal print;

• indication of double height print;

• indication of bold print.

The management of the communication with stripe cards and chip cards, for cards:

• synchronous (eg. SLE4442) ;

• asynchronous (IS07816) .

The payment application is managed as one of the normal application managed by the toolkit. The toolkit has to provide commands for managing the several payment steps related to security:

• request of starting card payment application;

• request of user pin entry

• request of payment authorization/online management/payment denial (first generate AC)

• request for payment confirmation / payment denial (second generate AC) .

These functionalities will be implemented and managed in a secure manner such that an application managed by third parties can use such functionalities for better integrating the payments through the normal debit and credit cards.

Server side

On the server side the Python application is run in servers that allow the access to persistent storage systems, such as for example relational databases.

An essential aspect is to define the communication model between client and server. The model has to rely on a system that allows the "Remote Procedure Call", wherein the code on the server side is called by the client that will receive the response of the computation in a synchronous or asynchronous manner.

Among the possible models we have:

· XML-RPC and JSON-RPC protocols;

• webservices;

• web server gateway interface

The XML-RPC protocol describes a remote procedure call method using the HTTP protocol as a means of transport for information in XML format. A client can call a method with parameters on a remote server and can get back structured data. The server is identified by a URI. The JSON-RPC protocol is like the operation described for the XML-RPC protocol, except for the data encoding, which are encoded according to JSON (Javascript Object Notification) format. JSON is a text encoding standard developed for the exchange of data derived from the Javascript language for allowing structured data to be represented. This encoding is a more compact alternative to XML representation, mainly due to the absence of closing tags.

Python implements XML-RPC in xmlrpc package of the standard library, containing the following modules:

• client modules: xmlrpc . client ; • server modules; xmlrpc . server .

The xmlrpc . client package allows XML-RPC client code to be developed, by handling all the details of translating between Python objects and XML elements. The connection to the server allows the URI to be specified and HTTP and HTTPS connections to be handled. The identification of the clients can be obtained by means of security methods typical of HTTP. The types of data that can be specified as arguments and returned as return value comprise the type of Boolean datum, integers, floating point numbers, strings, arrays, dictionary (key-value pairs) , dates, binary data and all the classes directly or indirectly composed of these data types. By means of MultiCall objects it is possible to encapsulate multiple calls to the remote server into a single request. The result will be provided as an iteratable object containing all the results .

The xmlrpc . server package provides a framework for XML-RPC servers developed in Python. Servers can be embedded in a CGI environment, therefore by using for example a web server for the handling of the connections, or they can handle the connections as free standing.

There are many implementations of the JSON-RPC protocol in Python, some are contained into frameworks, such as for example:

• Django JSAON-RPC, server implementation for Django

· Zope 3, client and server implementation for Zope

• Tornadorpc, server implementation for Tornado. Other one are independent, such as:

• Jsonrpclib, client implementation;

• Jsonrpc, client and server implementation on CGI or standalone;

• Bjsonrpc, standalone server and client implementation.

A model based on webservices defines a standard for the interoperability among software applications executed on different platforms and/or frameworks. A webservice provides to use an interface described in a machine-processable format, specifically WSDL (Web services description language)

W3C identifies two classes of Web services:

• REST-compliant : the aim is to manipulate XML representations by using the following "stateless" operations: create, retrieve, update, delete;

• Generic: the service exposes a set of arbitrary operations.

Both of them use the URI format for identifying the resources and use Web protocols such as HTTP.

The most widespread protocol that allows the format and semantics of the exchanged messages to be defined is definitely the SOAP protocol (Simple Object Access Protocol) . SOAP relies on XML metalanguage and the structure of a massage is composed of an "envelope" that identifies the XML document as a SOAP message, a "header" containing the base information of the massage, a "body" containing call and response information and a "fault" element containing the errors and information about the message status.

There are several libraries that implement webservice by using the SOAP protocol in Python, some of them are:

• soaplib: it allows web service soap to be developed and called;

• suds: it implements the SOAP protocol on client side;

• pysimplesoap: client server library that allows WSDL files to be created;

• Ladon: is allows a service to be exposed in several protocols, among which SOAP.

The Web server gateway interface defines an interface for web servers specific for the Python programming language. The need has arisen in order to provide a common interface between web server and web applications that supports the Python language. WSGI interface is composed of two parts, one is the server or gateway, and one is the application or framework. The server side invokes an object that is provided by the application. The advantages of such solution are to allow the application to use one of the many WSGI compatible frameworks, such as:

• CherryPy

• Django;

• Turbogears ;

• Tornado; • webapp2 ;

• Pyramid.

It has to be noted that these frameworks have been developed in the light of their use in web applications, but they can be simply adapted for being used as a system for handling RPC between the POS client and the server.

A second essential aspect it the protection of the server on which the applications are run.

Inside the server the Python interpreter is run in a secure "sandbox" environment that allows the application to be isolated. This causes the server to handle multiple applications without them interfering and without them affecting the scalability and the performances of the other applications.

This puts some limits to the functionalities allowed by the interpreter, above all as regards the I/O handling. It is believed appropriate for the application not to have the possibility of accessing the local file system, but to have the possibility of storing the data through the access to suitably created persistent storage systems.

Therefore it is necessary to provide a customized python library where the functionalities considered as not secure are removed and it is necessary to arrange additional functionalities for the access to the available resources.

PAYMENT APPLICATION

In this paragraph we deal with the need of developing a payment application that meets CBl and CB2 specifications described by COGEBAN by using the distribution model suggested above.

We analyze an architecture of the system that provides POS terminals wherein the client modules of the payment application are installed, which communicate through a RPC system with the server wherein the server modules of the payment application are provided which communicate with the authorizing Terminal Manager (TM) .

In this model the main choice is about which modules, and therefore which functionalities, have to be installed on the terminals and which one on the server, that is which are the programme parts that are "client side" and which are "server side".

A first consideration is about the offline payment mode for EMV transactions . It has to be noted that in this mode the payment application authorizes a payment without requesting the authorization to the TM and it has nothing to do with the communication between client and server in the distributed payment application. Despite this, the reasons that lead to perform a EMV offline transaction, as a function of a risk algorithm, are mainly due to the need of making the payment operation as quick as possible. It will not be possible to meet, or at least not completely, such need if the application is composed of a "server side" part also for EMV offline transactions, therefore imposing a communication between terminal and server.

From this consideration derives the need of implementing all the modules that allow the offline authorization as exclusively "client side" modules.

The remaining functionalities, and particularly the handling of the communication with TM, can be developed as "server side" . This because as already said many times, one of the targets in developing "server side" functionalities is to reduce the number and the size of the modules present on the terminal, making the application update step more quick.

Finally it has to be noted that the certification will involve the whole distributed application.

Functionalities necessary for the development of an application for the system according to the invention are:

• development environment

· handling of Multiple versioning SDK

• handling of application debug

• handling of the application modularization. DEVELOPMENT ENVIRONMENT

As regards the development environment the possibilities are to:

• create a dedicated development environment;

• use an existing development environment not related to a particular programming language that can allow to integrate our SDK.

Among the existing multilanguage development environments Eclipse stands out for its use and flexibility. Eclipse is an integrated multi -platform and multilanguage development environment. By the use of plugins its functionalities can be extended for supporting new languages and tools. Many companies, working in the POS field such as Ingenico and Verifone, and companies such as Google use Eclipse as the development environment by means of plugins suitably written for extending its functionalities.

HANDLING OF SDK VERSIONS

The handling of multiple versions of SDK is an important functionality, due to the need of:

• handling applications developed of different SDKs;

• handling possible incompatibilities between different SDKs;

• having available the most updated SDKs that can contain bug fixing.

It has to be considered that SDK will always evolve. As regards the evolution perspective of SDK there are different ways that can be followed:

• always keeping the compatibility among the versions in an incremental manner;

· not keeping the compatibility;

• backporting implementations on older versions. Even if the choice of always keeping the compatibility among the versions seems to be the most proper choice, in some cases the choice of not keeping the compatibility could be imposed, for example, by the functionality that is necessary to be inserted in the SDK or by considerations dependent on the greater space used by the SDK in the device. It is also possible to provide to backport implementations on older versions of the SDK, by the use of libraries. This choice for example has been made by Google for the Android system by writing a Support Package for the backporting of functionalities such as Fragments and Loaders.

For managing the several versions of the SDK we need a SDK manager that downloads and installs the required versions.

APPLICATION DEBUGGING

The developed application will use the libraries of the framework provided by the SDK. In order to test the applications in the development step we need:

• a client simulator where hardware characteristics to be simulated can be configured (e.g. size of the display, presence of printer, card reader, ...) ;

• a simulator of the server environment and particularly of the "sandbox" where the modules of the server side and of the persistent storage system are run;

· a debugger allowing breakpoints to be used and the value of variables at run-time to be viewed.

At the end of the debugging and of the test on the simulator there are two possibilities for the test on the real device:

· providing a browser on the device that handles the debugging mode such to debug the application directly on the device;

• distributing the signed application for the operation on production terminals, where debugging cannot be performed.

In the case of a browser directly handling the debug modes it must have specific characteristics:

• when running in debug mode it cannot handle the application update, in order to avoid installing terminals in the field in the debug mode by-passing the software signature;

• when running in production mode it is not possible to run unsigned applications;

· it must be possible to convert the browser from debug mode to production mode, this does not affect the security since it is related to the signature of the application to be run on the browser.

In this arrangement it has to be noted that the browser application will run in the debug mode and production mode, the terminal will not more have debug and production characteristics.

MODULARIZATION OF THE APPLICATION

The system managing the application update provides the client part of the application to be divided in modules. The division in modules is determined by the desired granularity.

From the solution with a minimum granularity wherein a single module containing the whole the application is provided, to the solution with the maximum granularity providing one module for each source file of the application.

In the first case we have an evident simplification as regards the versioning of the software modules, it being necessary to version only one of them, but also an evident problem related to the software update that provides to completely download the whole application.

In the second case the higher granularity allows the software update to be managed in a more focused manner by downloading the lowest amount of data but it provides an evident encumbrance in managing software modules versioning.

The optimal management provides a granularity compatible both with the requests of software update of limited size and with a management of the versioning not too much split.

In order to achieve the above the best solution is to use of a programming language that natively provides the software to be divided in modules. As regards the choice of the division in modules two modes can be provided:

• defining a base path, the application domain, where each created folder is a software module, therefore assignment automatically performed by the tools provided by the SDK;

• manually defining the belonging of a source file to a specific software module, therefore the assignment is performed by the developer.

Application download

The download of the application on the terminal can follow two principles:

• completely downloading the application, by downloading all the software modules composing it, upon the installation on the terminal; • downloading the main software module upon the installation on the terminal, and downloading the necessary software modules "on demand" when the application is running.

Moreover a system updating the software modules downloaded and obsolete has to be provided.

The "on demand" download provides lower band occupancy during the installation step of the terminal . In this case the division of the software modules by functionality is better for optimizing the request of software modules when running. The language interpreter has to be able to recognize the use of an "external" module and it has to request it to be downloaded if it is not present in the cache. However the solution of the "on demand" download involves some exceptions that cannot be managed by the application if:

• a software module is not present in the cache and there is no connectivity by the terminal such as no GPRS field, no LAN connectivity,...;

· a software module is not present in the cache and the communication channel of the terminal is already used by the application that is running.

In these cases the interpreter is not able to continue to run the application since it cannot download the requested module and consequently since it has to go on by taking unavoidable choices such as closing the application by displaying an error message.

The complete download of the application upon the installation provides at the beginning a higher band occupancy but it solves the problems described above about the "on demand" download therefore it does not generate exceptions by the interpreter.

Regardless of the selected model for downloading the application however it is important to manage the update of the software modules present in the cache in order to avoid obsolete applications from running. In order to overcome such problem an update of the software modules is provided with a predetermined time schedule, such as for example a night day scheduling, managed by the browser application that automatically updates only the obsolete software modules of the installed applications.

When selecting the complete download of the application upon the installation the granularity of the software can be even higher than the "on demand" download in order to optimize the amount of data to be downloaded in the application update step.

Since the application is divided into modules it is essential to manage the versioning of the application and of the modules, such to avoid the cases when it is possible to have a "partially" updated application with the presence in the cache of obsolete modules and of updated modules potentially not compatible with each other.

In order to overcome such problem both the deploy step and the software module download step have to be

"atomic" operations .

The solution taken according to one embodiment of the present invention provides to use Eclipse as the development environment wherein a plugin is provided containing:

• SDK Manager;

• project configuration manager;

• Python language support;

• server environment and client simulator;

• deploy manager.

The SDK Manager allows the version to be downloaded and installed by selecting it from the list of the available versions.

The creation of a project initializes the base structure, providing the selection of the SDK version to be used, among those currently downloaded by means of the SDK Manager.

The Python programming language allows the application to be divided in modules (called as packages in Python language) , by placing the sources on the file system in different paths. Therefore by defining a base path, the application domain, each created folder will be what will become a module in the deploy step.

The language support will be based on the open source PyDev plugin, that enables also the debug.

The simulator allows the hardware characteristics to be configured such as the size of the display, the presence of the printer and the type of the card reader .

The deploy step can take place directly on the device or on an external system managing the applications (see appstore) . In the case of deploy directly on the device the browser is in debug mode and it will communicate with the modules on the server side present in the local simulation environment. In the case of deploy on an external system managing the applications, the browser is in the production mode and it will download the software and it will communicate with the modules present in the remote system.

In the case of the management of the applications by an external centralized system, the plugin will send all the modules composing the application, both the client part and the server part. The central system will recognize by means of a hash functionality which are the actually modified client modules that it will send in the update step.

The first installation step provides the application to be completely downloaded. An external application management system then will allow only updated modules to be downloaded.

According to one embodiment, the system according to the invention provides a Market comprising all the applications available for the multi -platform toolkit. In figure 1 this is denoted by the acronym PMP (POS Market Place) .

The Market, which can be consulted by a web portal, has to provide an access both for the customers providing the applications that therefore can acquire the published applications to be installed at their customers, and for the developers that therefore can manage their applications for being published on the Market .

WEB STORE

The Web Store is the section of the Market available for the customers, that therefore can consult all the available applications for the purchase by- indicating:

• version of the application;

• description of the application equipped with presentation images representing the most significant screens of the applications;

• compatibility with the different terminal models for which the toolkit is available;

• minimum necessary version of the browser in the terminal .

By means of such characteristics the provider has immediately available all information necessary for knowing the compatibility of the applications on the basis of the terminals the provider has installed at its customers.

When acquiring an application the Web Store will provide some functionalities to the provider in order to manage the application on the terminals registered in the system. The Web Store will enable to:

• manage an activation date of the application or of the new version of the application in order to plan an update of the terminals at suitably selected dates ;

• manage an update or installation of the application only on specific terminals specified by a univocal id of the terminal such as the terminal serial number;

• manage the database containing the data of all the terminals and of the installed applications (versions, dates of activation, ...) .

Therefore when the application has to be activated on a specific terminal the Web Store will simply enable the application if it is a completely on-line application, or it will request the download of the necessary software modules on the terminal if the application provides off-line modules.

WEB DEVELOPER CONSOLE

The Web Developer Console is the section of the Market available to developers, that therefore can manage the publication of all their applications. The Web Developer Console will have to provide to the developers the tools for:

• managing several applications with the dependencies, if any;

· managing for each application the version of the application and of all the individual modules (online and off-line) composing it;

• managing in an automated manner the module versioning during the deploy of the application by the developer;

• managing the insertion of all the data provided by the Web Store for the application in the publication step.

During the application deploy the developer is provided to send always to the Web Developer Console all the client and server modules that compose the application with the simple indication of the version of the application upon the publication. The Web Developer Console will deal with the automatic versioning of all the modules by verifying the modules updated with respect to the previous version of the application by means of a hashing algorithm such as for example md5.

The advantages of the present invention are various and they are summarized below for descriptive convenience .

The solutions taken by the most famous terminal manufacturers, besides having an inherent limit in the fact of being single-platform, they do not provide a system for developing distributed applications. It results the idea to define a complete system allowing the software developers to create multi -platform distributed programs, giving the possibility of developing them with a high level programming language such as for example Python, by providing client server RPC communication system, ad hoc libraries for the communication to the peripherals typical of POS terminals, and moreover by providing a debug environment, a client terminal simulation, a server environment simulation and the deploy of the applications .

Moreover the system according to the invention solves the problem of the software distribution as regards the limits traditionally imposed by the software update in POS terminals, by providing a modular incremental update system that meets the available reduced communication band and the need for applications always updated with the requirement that it has to be possible to run them also offline.

Finally the system according to the invention allows companies providing the terminals to access a application store selecting which applications fit best the needs of their customers.

Obviously the invention is not limited to the embodiments described and shown above, but it can be widely changed above all from a constructional point of view. All this without departing from the teaching principle disclosed above and claimed below.

Claims

1. System for distributing software applications on POS payment terminals through an architecture of the client-server type wherein the POS terminal is the client, characterized in that the client comprises an interpreter for a high-level programming language not related to the type of POS used, which client is able to communicate with the peripherals of the terminal, by using specific libraries of the terminal itself, and with the server by means of procedures, particularly RPC, that allow remote processing requests to be sent, the server comprising software applications that can access a database interfaced or interfaceable with said server directly or through suitable gateways and that are able to receive and process the requests of the client for providing structured data as a response, the client-server communication being possible to be sporadic and limited only to the exchange of said requests and the relevant data.

2. System according to claim 1, wherein the software on the client side is structured by modules for the incremental update thereof .

3. System according to claim 1 or 2, wherein the software on the client side is in Python language, the interpreter for the commands being CPython, the core of the Python interpreter comprising a standard Python library reduced such to exclude the functionalities not strictly necessary for the operation of POS, such as, for example, multimedia services, programming frameworks, synthaxe analyzers, graphical interface with Tk, command line options, the concurrent execution, interprocess communication.

4. System according to one or more of the preceding claims, wherein libraries are provided for the communication with the specific peripheral of the POS terminals implementing one or more of the following functionalities :

- display management;

- print management;

- chip card and stripe card management;

- management of the communication with a possible payment application

- management of the communication with existing proprietary applications,

wherein the display management provides to develop a library containing the following graphical components :

- Container with horizontal queueing

- Container with vertical queueing

- Label

- Numerical input

- Alphanumeric input

- Password input

- Decimal numeric input

- Confirmation input

- Multiple selection input.

5. System according to one or more of the preceding claims, characterized in that the payment application is managed as one of the other applications wherein commands are provided for managing the several security-related payment steps:

- request of starting card payment application;

- request of user pin entry

- request of payment authorization/online management/payment denial;

- request for payment confirmation/payment denial.

6. System according to one or more of the preceding claims, wherein the software on the server side is a Python application that accesses local or remote files, particularly relational databases.

7. System according to one or more of the preceding claims, wherein the code on the server side is called by the client in a synchronous or asynchronous manner for generating a response of the server to the client.

8. System according to one or more of the preceding claims, wherein a client- server communication protocol is used which is selected in the group composed of: XML-RPC, JSON-RPC, webservices, web server gateway interface.

9. System according to one or more of the preceding claims, characterized in that it comprises a development environment containing the following resources:

- SDK Manager;

- project configuration manager;

- Python language support;

- server environment and client simulator;

- deploy manager, wherein the SDK manager allows the software version to be downloaded and installed from a list of the available versions, the programming language used allowing each application to be divided into modules by placing the sources on the file system in different paths for the incremental update on the client.

10. System according to one or more of the preceding claims, characterized in that it provides a market comprising the available multi-platform applications, said market being accessible both by the users of said applications and by the developers, the application available for the purchase being consultable in a section called as Web Store arranged for:

- managing an activation date of the application or of the new version of the application in order to plan an update of the terminals at suitably selected dates;

managing an update or installation of the application only on specific terminals specified by a univocal id of the terminal such as the terminal serial number;

- managing the database containing the data of all the terminals and of the installed applications.