Field of the invention

The present invention in general relates to the issue of electronic tickets, and more specifically to systems, methods and computer programs adapted to manage the issue, check and validation of electronic tickets for purchasing and benefitting from services. The invention in particular relates to an “abstract” Electronic Ticketing System (ETS) which creates a Virtual Ticketing System (VTS) which is completely independent of the“physical” ticketing system.

Background art

Certain more evolved ticketing systems provide using electronic readable and writable mediums. These mediums, among which the so-called smart cards hold a prominent position of importance, have been part of an important evolution of technology: they have allowed a large number of functionalities accompanied by increased security levels to be obtained due to the possibility thereof to store data and information.

The rights of the traveler are recorded on the medium itself in these ticketing systems, which are based on the use of a physical medium and therefore are called “card-centric” or Card Based Ticketing (CBT) systems. During the validation process, an electronic validator terminal verifies the card authenticity and that there are adequate rights or value. If the results of the preliminary checks are positive, the electronic validator terminal conveniently uses the traveler’s value or rights, updates the data on the card and indicates the transaction is valid by indicating the results with a confirmation message which may simply be an acoustic signal or light provided to the user.

Validations using smart cards are very quick and secure and do not require any access to a remote back-office with which data and information are to be exchanged. Thus, card-centric systems remain operational also when it is impossible to access communication networks because all the information required for the transaction process are locally contained between the validator terminal and the smart card.

The main disadvantages of card-centric systems lie in the electronic validator terminals which are to be provided with a given level of intelligence, and therefore of complexity. The validator terminals in particular are to have all the information required to process the Travel Tickets (TDV) and periodically require being synchronized with a remote back-office so as to update and synchronize data such as transactions, settings, software, etc. This results in a rather limited level of flexibility and a significant complexity, especially concerning the synchronization between back-office and electronic validator terminals and in particular when several different ETS Electronic Ticketing Systems are to be integrated.

The so-called Account Based Ticketing systems (ABT) provide certain solutions to the problems associated with the use of the Card Based Ticketing systems (CBT). Indeed in the Account Based Ticketing systems (ABT), the software is processed in a main remote back-office system which resides for example, in a remote server. Smart cards are still used but solely serve to identify the user in a secure manner and do not store other information.

In the Account Based Ticketing type systems (ABT), when the user has his/her own smart card, the following transactions are performed on the electronic validator terminal: the card is authenticated to verify the identity of the user; the card identification code is reported to the back-office remote server; the transactions required to authorize and carry out the transaction required by the user are executed in the remote back-office, the results of the transaction are reported to the user. Therefore, both the archiving of the data which are stored on the smart card in the Card Based Ticketing (CBT) and the processing transactions of the aforesaid data are transferred to a remote server in the Account Based Ticketing type systems (ABT).

The drawback of the Account Based Ticketing systems (ABT) is that they require data connection. If for example, an always-connected data connection is assumable in a metropolitan gate connected to a fixed data network, the same cannot be said for a bus which may also be in areas along its route not covered by the data connection. It therefore is indispensable, also in the case of Account Based Ticketing (ABT), to make use of technical solutions which in any case provide some sort of processing by the validator terminal so as to allow a proper operation also in all those cases in which connectivity is only available at times.

The Account Based Ticketing systems (ABT) simplify the transactions related to the smart card which is reduced to a mere user identification tool. The smart card is spoken of here as a Portable Object (PO), that is portable objects adapted to identify the user. PO Portable Objects may consist of dedicated smart cards, but also of smart cards related to other services such as for example, health cards, identity cards, bank cards etc. PO Portable Objects may also consist of devices such as smartphones or tablets due to the Near Field Communication technology (NFC).

A smartphone may actually emulate a smart card related to an automated ticketing system with Near Field Communication type communication (NFC). The emulation of smart cards by smartphones is not direct - because the smartphone does not have a secure archive for the encryption keys required to pass the required security checks - but rather it occurs through techniques called Flost Card Emulation techniques (FICE) in which the encrypted keys are stored on a remote server, as in the case of bank cards.

In the current panorama in which public and private passenger transport companies operate, there is the utmost complete incompatibility between the various systems for managing electronic ticketing used by the aforesaid transport companies, whether they are of the CBT Card Based Ticketing type or of the ABT Account Based Ticketing type.

Due to an historic habit, every company and service provider operating in a certain market segment creates or adopts solutions which tend to exclude other subjects from creating applications which may be integrated with its own, and even more, which may interact with apparatuses of different origin. Accordingly, the integration with various companies operating in the same field or in close fields is anything but easy.

This habit at times is explained by commercial reasons, other times by technical and security reasons. For example, in the field of Electronic Ticketing Systems (ETS) of passenger transport companies, a scenario in which various companies could attempt to develop applications with the technology used today which can ensure the interoperability and compatibility with other actors in the same field should necessarily imply the interaction and modification of the Card Data Model (CDM), that is the logical structure of the data of the TDV Travel Tickets coded on the card comprising for example, the structure of the records, the format and the meaning of the individual fields registered, with obvious repercussions for security.

Indeed, all ticketing systems have their own Card Data Model (CDM), usually a proprietary model, and the Card Data Model is designed to be compact and to make the contents of the card as incomprehensible as possible to third parties. The CDM Card Data Model in particular describes the information contained and the structure with which such information is stored in the card itself. There are a number of difficulties in this type of approach; just the test procedures of the possible modifications to be implemented - procedures to be repeated after each variation - would be highly demanding and complex.

For example, the management of these procedures in the field of Italian regional transportation provides establishing a specific committee provided with an adequate inter-system testing platform called upon to test and approve the apparatuses or systems being integrated prior to the commissioning thereof.

In conclusion, also when the design of systems which are incompatible with other similar ones is not intentional, the integration is never or almost never conceived at the origin and therefore is subject to increased difficulties, manufacturing times and costs.

Therefore, there is an apparent need in the prior art for systems for authenticating and determining the validity of a ticket held by a user, for example a Travel Ticket (TDV), which are interoperable and adapted to manage tickets issued by various bodies so as to simplify and rationalize not only the use by the user, but also the management and control by the companies operating in a given field, or in contiguous fields, and having the same problems.

The modern world increasingly obligates companies to operate in a synergistic manner to face the market challenges. It may therefore be suitable for a transport company to take advantage of sales networks of other companies, market travel tickets of other companies and offer more suppliers the possibility of integrating their solutions in the Electronic Ticketing System.

Summary of the invention

Therefore, the present patent application provides a system and a method which include embodiments that resolve the aforesaid limits and other limits of the conventional approach to managing electronic ticketing. The Electronic Ticketing System (ETS) according to the present invention is designed to be abstract, immaterial and independent of the architecture of the hardware (i.e. from the physical ETS) on which it is based in order to operate.

The system according to the present invention, indicated hereinafter in short as VTS (from the acronym Virtual Ticketing System) is based in particular on two innovative concepts which act in synergy: the complete dematerialization of the medium, for example a smart card or a contactless ticket, and the definition of a general object interface (said objects being for example, the contracts or travel tickets, the transport lines, the locations and the rate groups, the stops, etc.) with which the physical ETS Electronic Ticketing System is interconnected with the VTS Virtual Ticketing System.

Certain examples of smart card are the Calypso for complex applications (it has an on-board microprocessor), MIFARE 1 k, GTML (it is an old card but is still in use for example, in Milan, and belongs to the Calypso group of cards: Calypso cards were native products: CD97, CD Light, GTML, CD21 , Tango), etc.

Examples of contactless tickets are for example, MIFARE Ultralight, MIFARE EV1 , etc.

The complete dematerialization of the medium is obtained by emulating the low- level contents of the smart card or of the contactless ticket (i.e. the file system) in a secure container, a virtual smart card called Virtual Token or V-Token.

The V-Token has a structure comprising: a header which allows anyone to understand the type of contents, the rules for verifying authenticity, etc.; a payload which allows managing types of smart cards and CDM Card Data Models which are also very different from one another; a standard record which is independent of the CDM Card Data Model containing the last validation information; a record containing a “signature” (also multiple) which allows the authenticity of the data to be established. Due to the structure thereof, the V-Token practically is the functional “replacement” of the smart card and the contactless ticket.

The aforesaid V-Token may be created from scratch, and here the medium is completely virtual, or it may originate from an actual physical medium, such as a smart card for example. In this last case, the peripheral device (an apparatus such as an on-board validator of a means of transport, the smartphone of a user, an automatic ticketing machine or an application such as an e-commerce site, a company ticket office, etc.) is to limit itself to“recopying” the physical content of a card for example, into a V-Token, in a field called payload, without ever going into detail of how the information is coded.

To avoid fraud, the V-Token is signed and verified with the same SAM module (SAM Secure Access Module) that the ETS Electronic Ticketing Systems already manage. A SAM Secure Access Module may contain several keys for carrying out different transactions. There are for example, various types of SAM Secure Access Modules. For example, in ETS Electronic Ticketing Systems, there are:

· a SAM module used for the validator;

• a SAM module for reloading travel tickets;

• a SAM module for the check;

• SAM modules used for the personalization of the card;

• SAM modules used for the validation of the card and the data;

· SAM modules used for the initialization and personalization of other SAM modules (the SAM modules are made from other specifically used SAM modules).

The application which is to interact with the VTS Virtual Ticketing System, for example for decoding the content of a smart card, must read the smart card in a general manner, that is without knowing the CDM Card Data Model thereof, and must pass the reading to the VTS Virtual Ticketing System by making the request to obtain the decoding of the content in a standard format which is comprehensible to everyone, for example in XML format (extensible markup language). The VTS Virtual Ticketing System which receives the aforesaid above decoding request is not capable of comprehending the meaning of the content of the payload field because since this is general content and is independent of the ETS Electronic Ticketing System, it does not know the criteria and the Card Data Model with which the smart card now being read, was written. Therefore, the VTS Virtual Ticketing System would not be capable of satisfying the request from the application without the second innovative content of the present invention, which comes into play at this point. The VTS Virtual Ticketing System uses an external library, a so-called plugin, which was written ad hoc for the physical ETS Electronic Ticketing System inside of which the content of the smart card just read has a precise meaning. It is the task of this plugin to satisfy the decoding request, after which it is the task of the VTS Virtual Ticketing System to convey the response to the caller in a secure and reliable manner, that is to the application which made the decoding request.

Both the internal coding format of the V-Token and the object interface with which the aforesaid plugin is provided may be standardized and made public so as to allow the managers of the ETS Electronic Ticketing System to write their own VTS plugins for interfacing their own ETS Electronic Ticketing System with the VTS Virtual Ticketing System of the present invention without having to expose confidential internal data, and those who write applications to be able to do it once and for all in such a manner as to be able to interface with multiple ETS Electronic Ticketing Systems that are different from one another.

All this because according to the present invention, the application which is to interact with the VTS Virtual Ticketing System does not need to know the details of how the specific mediums of the ETS Electronic Ticketing System are managed (i.e. sale, renewal, validation, verification, etc.), rather it sees all the ETS Electronic Ticketing Systems in the same manner, using the same language.

In brief, the VTS Virtual Ticketing System according to the present invention defines a kind of general and open platform which allows the users to interface with many different ETS Electronic Ticketing Systems and the managers of these ETS Electronic Ticketing Systems to be able to offer their services to a multitude of third- party applications.

Moreover, the VTS Virtual Ticketing System is not limited to solely defining interfaces, rather it provides them with technologies adapted to reduce or eliminate the risks due to fraud and malfunctions using the best encryption techniques available today.

Due to the system and the method according to the present invention, a complete interoperability may be obtained between a plurality of access tickets to the various services by simplifying the management thereof by the users.

Indeed, it will be possible for the users to access the various services, which normally may each be taken advantage of with a different authentication system, by means of the use of one’s own smartphone. In the field of electronic ticketing (for example, for the management of TDV Travel Tickets in the public and private transport of passengers, for the management of the payment of parking in parking areas, etc.), the present invention allows the following goals to be met: multi-company ticket offices; multi-company e-commerce portals; multi-company resale; multi-company automatic self-service ticket issuing machines; multi-company smartphone apps; multi-company checking applications etc.

The applications associated with the VTS Virtual Ticketing System according to the present invention (for example, e-commerce sites, on-line ticket offices, transport company portals, etc.) are capable of operating with any ETS Electronic Ticketing System provided with a VTS Virtual Ticketing System interface without needing to know any of the particularities thereof such as for example, the structure of the rate system, the renewal rules, the Card Data Model, the rates, etc. A hypothetical new company that wants to become part of the system to benefit from the interoperability with other companies in the field would therefore be simply and directly connected to the application associated with the VTS Virtual Ticketing System and would immediately become operational, without the need to make modifications on the side of the application itself.

Finally, said applications within the VTS Virtual Ticketing System may be made by interested companies or by Third Parties due to SDK Software Developer Kits which will be made available. Making new applications (or the extension of existing ones) thus is promoted by the possibility of using said applications on several systems; those who develop applications compatible with the VTS Virtual Ticketing System according to the invention may propose them to all the companies provided with the VTS Virtual Ticketing System without making modifications or running into lengthy test and validation procedures. The cost of making new VTS Virtual Ticketing System applications may therefore be distributed between several companies, thus lowering the economic impact of the development thereof.

Brief description of the drawings

Further features and advantages of the invention will be more apparent from reading the following description provided by way of a non-limiting example, with the aid of the figures shown in the accompanying drawings, in which: Fig. 1 shows a block diagram of the system according to the present invention;

Fig. 2 shows the various interactions between the blocks forming the VTS;

Fig. 3 shows the use of the VTS Plugin Library;

Fig. 4 shows the communication architecture and the protocols used in an embodiment, and

Fig. 5 shows the system architecture in the case of smartphone apps.

The parts forming the apparatus according to the present description have been depicted in the drawings, where suitable, with conventional symbols, showing only those specific details which are pertinent to comprehending the embodiments of the present invention, so as not to highlight details which are immediately apparent, to those skilled in the art, with reference to the description herein indicated.

Detailed description of the invention

The system of the present invention uses a combination of ABT Account Based Ticketing and FICE Flost Card Emulation so as to improve the features offered by the two aforesaid technologies.

With reference to accompanying Fig. 1 , the architecture of an example of the VTS Virtual Ticketing System 1 according to the present description comprises a remote server 10 associated with suitable MEM Data Storage Means in digital format and connected to a NET Data Communication Network such as for example, the Internet. The Virtual Ticketing System 1 comprises a plurality of ETS Electronic Ticketing Systems, indicated with numeral 1 1 , adapted to check and verify the validity of TDV Travel Tickets upon request by a user. System 1 further comprises a plurality of apparatuses 12 for the purchase and sale of travel tickets, said apparatuses 12 being provided with SW Application Software Programs adapted to communicate with said remote server 10 for the mobile purchase and use of electronic travel tickets. Examples of these apparatuses 12 comprise automatic ticketing equipment 12a, for example vending machines which are installed in train, bus and subway stations; the equipment for the validation of travel tickets 12b which is for example installed in train stations, often close to the tracks, or on-board means of transport (trams, buses); and electronic processing and communication devices 12c such as personal computers, tablets, smartphones, etc.

Said remote server 10 is associated with a Library 15, called Virtual Ticketing System Plugin or VTS Plugin. Said Virtual Ticketing System Plugin Library 15 is also installed on board Electronic Ticketing Systems (ETS) 1 1 which form part of the VTS Virtual Ticketing System 1 .

This Virtual Ticketing System Plugin Library 15 serves to uncouple the VTS Virtual Ticketing System 1 from the ETS Electronic Ticketing System 1 1 with which it interfaces.

The services usually expose functions which have a tight pairing with the system they interface with. The VTS Plugin Library 15 allows using the same infrastructure (VTS Server 10, SDK Software Development Kit, protocols, etc.) by simply changing ETS Electronic Ticketing System 1 1 technology and supplier with a configuration file 25 arranged on the VTS Server. The configuration file 25 contains the Pathname 25a of the DLL Dynamic-Link Library to be loaded at startup and other fields 25b, 25c. The VTS Server 10 may simultaneously manage several DDL Dynamic Libraries, also on different systems or suppliers. The CDM Card Data Model is also known only to the DLL Library. The VTS Server (or the SDK Software Development Kit) does not know any detail of the DM Data Model (or of the rates, prices...).

The VTS Plugin Library 15 is adapted to translate the communication between the remote server 10, the various ETS Electronic Ticketing Systems 1 1 and the various apparatuses 12 for the purchase, validation, processing and sale of TDV Travel Tickets, into a common object-oriented language described in XML. The common language was defined to allow creating the DLL Dynamic Library, herein defined as VTS Plugin 15, also by various suppliers (also competitors). Since the interface is formalized, anyone may provide and integrate a new Plugin Library into the system, also the client. Such a common language is then used by the actors (applications) to communicate with the various ETS Electronic Ticketing Systems 1 1 without necessarily needing to use the native and proprietary protocols thereof. Once made available for a general ETS Electronic Ticketing System 1 1 , the VTS Plugin Library 15 is then usable both directly (e.g. for“off-line” applications) or by means of the mediation of the VTS Server 10. The VTS Plugin Library 15 in particular allows being free of the ETS Electronic Ticketing System 1 1 selected and allows the client to carry out the desired transactions without worrying about the implementation details. The VTS Plugin Library 15 in particular allows the users to see the various ETS systems 1 1 as though they were all the same, i.e. allows a high-level interaction unbound from the implementation details. Thus, the VTS 1 creates an interface towards the user which“standardizes” the various ETS systems 1 1.

The VTS 1 also provides a VTS-Lib Library 20 to be installed on the various apparatuses 12.

The VTS-Lib Library 20 is to be usable in various contexts, both in“on-line” and“off line” version. The VTS 1 uses a“ServiceVtsFrontend.wsdl” file which describes the format of the WS Web Service calls which are to be used by the VTS-Lib Library 20. Thus, the VTS-Lib Library 20 and the WSDL Web Services Description Language Interface are practically identical and equivalent. In particular, they have the same methods and the same parameters as the calls.

When the library is only used online, the VTS-Lib Library 20 is to be usable in completely on-line mode. Here, the e-currency libraries (the term e-currency, i.e. “automatic currency”, designates the group of electronic, computer and telematic processing required for managing payments by means of credit cards and the like; more generally, it concerns the automatic - that is computerized - management of money) and all the processing of the data and rates occur on the“server side”. No datum is processed and/or generated locally.

This allows developing a light application which does not require local data and which does not generate data which then are to be sent to the main server, under penalty of the loss thereof.

In the solution herein proposed, there is no local wallet for storing sensitive data such as V-Tokens and/or the configuration data. It is the task of the application to save and/or protect this information.

The V-Tokens in binary format are taken and supplied, by means of specific methods, to the VTS-Lib Library 20, directly from the calling application which is to know how to use this information (know how to read and write the V-Tokens).

Moreover, it is the task of the application to directly interact with the peripheral devices for the management of the RFID mediums such as the contactless readers, for example. It therefore is the task of the application to read and write (at low level) the physical mediums such as the smart cards and/or contactless tickets, for example. In particular, it is the task of the application to convert a physical medium into a V-Token and vice versa. Obviously, the VTS-Lib Library 20“gets involved” every time there is a need to manage the Card Data Model (for example, Info card, additional contract on card, card validation, card verification, etc.).

Contrarily, if there is a local caching mechanism (object serialization), every time frequent and common information is requested, the VTS-Lib Library 20 is to allow the application to save the response or objects returned by the VTS Server 10 locally (on system files) each time it is queried in order to limit the data traffic towards the VTS Server 10. This is in order to use it at the next startup without having to wait for the“synchronization” of the data; for example, the list of transport operators, the rate towns, the list of stops, etc.

Since it is the task of the application to carry out/decide on such a saving, the VTS- Lib Library 20 is to allow the serialization and the successive loading of any object or list of objects.

When the library is only used off-line, the VTS-Lib Library 20 is to be usable in completely off-line mode. Here, the e-currency libraries and all the processing of the data and the rates occur locally.

This mode allows the application to work disconnected from the center. Obviously, certain calls to the VTS-Lib Library 20 may in any case require the connection with the center, i.e. with the VTS Server 10. If the connection is absent here, the VTS- Lib Library 20 returns an error on the specific call.

All the functions or methods which do not provide the express querying of the main server, i.e. the VTS Server 10, may be executed by the application also in disconnected mode. Here, the VTS-Lib Library 20 uses an ad-hoc component called VTS Plugin 15, which is the one that allows the VTS-Lib Library 20 to interact with the e-currency libraries and with the local data (e.g. file with the rate parameters and activity file).

Since the VTS Plugin 15 requires communicating with its own ETS Electronic Ticketing System 1 1 from time to time to update such files, the VTS-Lib Library 20 exposes a specific method (synchronize) which is to be called by the application every once in a while. Thus, a VTS Plugin Library 15 for each type of ETS Electronic Ticketing System 1 1 considered and supported by the VTS 1 is available on the VTS Server 10. It is recommended to create a dedicated parallel thread to carry out such a task so as to exchange data with the ETS Server 1 1 in parallel to the normal requirements (e.g. data query).

Instead, in the case of the“on-line” use of the VTS-Lib Library 20 by means of the VTS Plugin 15, it has the complete control of the e-currency peripherals and exposes methods for directly interacting with the RFID reader (for example) by freeing the application from such a task. Obviously, only supported readers and/or apparatuses are manageable here.

Then there is a last case of use of the library in hybrid mode. The VTS-Lib Library 20 is to be usable in hybrid (on-line and off-line) mode. This is made possible due to the fact that the Web Services exposed by the VTS Server 10 and the“C” interface of the VTS Plugin 15 are practically identical. This approach allows creating SAM-less applications which in any case may locally operate disconnected (smart cards read outside a secure session and signature verification not carried out). If the center, i.e. the VTS Server 10, requires using an HSM Hardware Security Module, the application may return online and therefore use such a feature.

The object of the VTS 1 herein described is to serve as application interface between a general client, whether it is of the “public-oriented” type (for example an e- commerce site, a smartphone app, parking meters, third-party TVM Ticket Vending Machines, etc.) or of the“internal-operator oriented” type (such as for example, company ticket offices, resales, controller terminals, etc.), and one or more ETS Electronic Ticketing Systems 1 1 , which are also different from one another, without ever“going into the detail” of the internal operation thereof (for example, of the card data model, rate policies, calculation algorithms of the prices of the rates, etc.).

The VTS Server 10 abstracts the rate concepts and provides a simple, stable and abstract interface to anyone having to interface therewith.

The “third-party” application interacts with the ETS system 1 1 in a completely general and independent manner from the particular system, supplier of the ETS 1 1 or technology implemented.

The VTS Main Server 10, which is the entity that allows the abstract interaction between heterogeneous ETS systems 1 1 , does not have an implementation therein of an ETS Electronic Ticketing System 1 1 , rather uses the external library called VTS Plugin 15. Such a VTS Plugin Library 15 is the only one which then dialogs in a native manner with the ETS Electronic Ticketing System 1 1 with which it interfaces. For this reason, there are various VTS Plugin Libraries 15 on the VTS Main Server 10, one for each ETS Electronic Ticketing System 1 1 supported by the system and integrated therein. Figure 2 shows three different Electronic Ticketing Systems, ETS“A”, ETS“B” and ETS “C”, all indicated with general reference numeral 1 1 . The VTS 1 puts the Electronic Ticketing Systems 1 1 into communication with the various apparatuses 12. The apparatuses 12 in particular may be for example, e-commerce sites, ticket offices, apps directly on smartphones, or the automatic ticketing equipment called vending machines which are installed in train, bus and subway stations, the equipment for the validation of travel tickets which are for example installed in train stations, often close to the tracks, or on-board means of transport (trams, buses), and the electronic processing and communication devices such as personal computers, tablets, smartphones, etc.

The VTS Plugin Library 15 is responsible for translating into a“common object- oriented language” described in XML. Such a language is then used by the actors (applications) to communicate with the various ETS Electronic Ticketing Systems 1 1 without necessarily needing to use the native and proprietary protocols thereof. Once made available for a general ETS Electronic Ticketing System 1 1 , the VTS Plugin Library 15 is then usable both directly (for example, for“off-line” applications) or by means of the mediation of the VTS Server 10.

Figure 3 shows how the VTS Server 10 dialogs with the applications and uses the VTS Plugin Libraries 15 to interface with the various Electronic Ticketing Systems 1 1 .

The VTS Main Server 10 is in turn divided into two macro-components: a front-end process 16 and a back-end process 17 which takes care of the actual management of the VTS 1 (for simplicity called VTS Server).

The VTS Server 10, which is the heart of the VTS 1 , is capable of simultaneously dialoging with one (or more) front-end processes 16 and an external application (or external server 18) using the native protocol (VTS Native Protocol) in parallel. Two (or more) VTS Servers may alternatively or additionally be installed in parallel, one dedicated to the front-end 16 and the other dedicated to the dialog with the external server 18.

The VTS Server 10 in turn dialogs with the ETS Electronic Ticketing System 1 1 (for example, the BIP) by means of an external interface library called VTS Plugin 15. This allows changing ETS Electronic Ticketing Systems 1 1 using different VTS Plugin Libraries 15; here the VTS Server 10 and front-end 16 processes are the same and the exposed protocol is identical. In particular, the client (see for example, smartphone) completely ignores whether or not it is speaking with the ETS“A” or “B” system.

Figure 4 shows the communication architecture and the protocols used in the VTS 1 in the case of the BIP Piemonte project.

In particular, the BIP Main Server 100 comprises a CCC Company Control Center 102 in communication with the VTS Servers 104 and 106. The VTS Servers 104 and 106 are in communication with the rest of the system by means of internal firewalls 108 which allow the communication with the DMZ Demilitarized Area 1 10 and with an external system 120. The communication between the CCC Company Control Center 102 and the VTS Servers 104 and 106 occurs by means of BIP AFCS protocol. The VTS-WS Service Module 1 12 is inside the DMZ Demilitarized Area 1 10. This VTS-WS Service Module 1 12 dialogs with the outside through external firewalls 1 14 which allow the communication with the Internet Network 130 and with the external system 120. The communications between the VTS Servers 104 and 106 and the VTS-WS Service Module 1 12 or the external system 120 occur by means of the VTS Native Protocol. Various smartphones 1 16 and PCs 1 18 which may purchase TDV Travel Tickets are connected to the Internet Network 130. The external system 120 may contain a server 124 and vending machines 122. The communications passing through the external firewalls 1 14 use the WS protocol (e.g. SOAP - Simple Object Access Protocol).

The remote server 10 may comprise two separate parts: a front-end which exposes WS Webserver methods and which is usually installed on a server in the DMZ Demilitarized Area called VTS-WS front-end 16 (or VTS-WS), and a back-end which deals with the actual management of the VTS, called VTS Server 17.

The VTS WS front-end 16 has the sole task of translating the WS Webserver calls (SOAP Simple Object Access Protocol) into the native protocol of the remote server 10. The VTS Native Protocol is directly available to increase performance, if required.

The VTS Server 17 is capable of simultaneously dialoging with one or more VTS- WS 16 and with one or more external SW Applications, or with a further external server 18, using the native protocol (VTS Native Protocol). In particular,“M” front- ends (VTS-WS) 16 and“N” back-ends (VTS Server) 17 may be mounted so as to balance the traffic and create “fail-over” type architectures. Two or more VTS Servers 17 may alternatively or additionally be installed in parallel, one dedicated to the VTS-WS 16 and the other dedicated to the dialog with possible further external servers 18.

The VTS Server 17 in turn dialogs with the ETS Electronic Ticketing Systems (for example, the BIP Piemonte Integrated Ticket) by means of said VTS Plugin External Interface Library 15.

This allows changing ETS Electronic Ticketing Systems 1 1 (e.g. AFCS Automatic Fare Collection System, ET Easy Ticketing, METS Magnetic and Electronic Integrated Ticketing System...) using different libraries; here the VTS Server 17 and the VTS-WS 16 are the same and the exposed protocol is identical. Considering for example, an ETS Electronic Ticketing System 1 1 consisting of a smartphone, said smartphone completely ignores whether or not it is communicating with AFCS Authentic Fare collection System, ET Easy Ticketing or METS Magnetic and Electronic Integrated Ticketing System, when communicating with the system according to the invention.

Moreover, said remote server 10 is associated with an FISM Hardware Security Module 14, a physical processing device (i.e. hardware) which safeguards and manages the digital keys for a strong authentication and provides the encryption required for processed and transmitted data. These HSM Hardware Security Models 14, which are available in various versions in the prior art, traditionally are in the form of a plugin board or an external device which may be directly connected to said remote server 10.

Moreover, said remote server 10 is adapted to manage virtual smart cards which exactly replicate the physical smart cards. In further detail, the remote server 10 creates and stores a virtual smart card in said storage means every time the aforesaid SW Server Web Application Programs require it, for example when a user purchases a travel ticket from his/her smartphone.

This type of application in particular is called ABT Account Based Ticketing, while the one that uses the physical card or V-Token in the smartphone is called CBT Card Based Ticketing. The VTS allows both modes to be managed.

Said remote server 10 also updates the stored smart cards, both in real time, every time said ETS Electronic Ticketing Systems 1 1 and said apparatuses 12 perform on-line transactions - i.e. in the presence of a connection with the remote server 10

- and in deferred time, that is when the aforesaid transactions are carried out off line, i.e. in the absence of a connection with the remote server 10.

In order to carry out transactions on the virtual smart cards stored in the remote server 10, there is a need to unequivocally identify and localize each of the virtual smart cards. Thus, when a new virtual smart card is created, the remote server 10 associates it with one or more VUID Virtual Unique Identification Numbers. Due to the SW Application Software Programs with which they are provided, said ETS Electronic Ticketing Systems 1 1 and said apparatuses 12 can carry out any transaction among the available ones (e.g. a validation) on the virtual smart card identified by means of the VUID Virtual Unique Identification Number.

Said VUID Virtual Unique Identification Number is preferably generated by a module called VUID VRP Resolution Plugin 13 associated with said remote server 10 and adapted to convert any ID identifier number of a user (for example, a manually entered code; the Serial Number (S/N) of a MIFARE type card for accessing a public service or public transport; the Serial Number (S/N) of a MIFARE type card for accessing a public service or public transport; the PAN Primary Account Number -

- of a bank card; the code contained in a QR-code which may also be generated by the system according to the invention, etc.) into an unequivocal VUID Virtual Unique Identification Number adapted to avoid possible numbering conflicts within the system.

Said VRP VUID Resolution Plugin Module 13 therefore is adapted to carry out the authentication of the medium, where the simple identification not sufficient, and to resolve the Client ID in a new identification number called VUID Virtual Unique Identification Number. Native methods of the medium usually are used for authenticating, for example a Calypso card can be verified (session verification with the SAM); other cards have encryption in hardware mechanisms. The authentication is generally carried out using“native” methods of the medium used.

The VRP VUID Resolution Plugin Module 13 may be made as a SW Software or as a HW Hardware module and may have varied structure and complexity, thus making possible the direct and transparent importing of the User ID setting and the modification thereof possible by means of adding numbers corresponding to the type of card, and the generation possible of a new VUID Resolution Plugin by means of encrypted transactions (e.g. MIFARE) or by means of the authentication of a card, for example of Calypso type, through the SAM module, or again by means of generating a token generated through a process in the secure environment Payment Card Industry (PCI) PIN Transaction Security (PTS), PCI-PTS of the PAN Primary Account Number of a bank card. The Primary Account Number is the identification number of a debit card (cash card) and a credit card associated therewith from the time of issue. An algorithm associated with the PAN Primary Account Number generates the PIN Personal Identification Number, which instead is the user identification.

Fig. 5 shows the system architecture in the case of use of a smartphone 12 for storing the TDV Travel Tickets. Here, the app is downloaded onto the smartphone which allows dialoging with the VTS 1 and the selected ETS Electronic Ticketing System 1 1 by means of the VTS-Lib Library 20.