IT201800010314A1 - Sistema e metodo di bigliettazione elettronica virtuale - Google Patents

Description

Domanda di brevetto per invenzione industriale dal titolo

“SISTEMA E METODO DI BIGLIETTAZIONE ELETTRONICA VIRTUALE.”

Campo dell’invenzione

La presente invenzione si riferisce in generale all'emissione di biglietti elettronici, e più in particolare a sistemi, metodi e programmi per computer atti a gestire l’emissione, il controllo e la validazione di biglietti elettronici per l’acquisto e la fruizione di servizi. In particolare l’invenzione si riferisce ad un Sistema di Bigliettazione Elettronica (SBE) “astratto” che realizza un Sistema di Virtual Ticketing System (VTS) totalmente indipendente dal sistema di bigliettazione “fisico”.

Stato della tecnica

Alcuni dei sistemi di bigliettazione più evoluti prevedono l’utilizzo di supporti leggibili e scrivibili in forma elettronica. Questi supporti, fra i quali occupano una posizione di preminente importanza le cd. smart card, hanno costituito un’importante evoluzione della tecnologia: grazie alla loro possibilità di memorizzazione di dati e informazioni hanno permesso di ottenere un grande numero di funzionalità accompagnate ad elevati livelli di sicurezza.

In questi sistemi di bigliettazione, basati sull’utilizzo di un supporto fisico e detti pertanto sistemi “card-centrici” o sistemi di Card Based Ticketing (CBT), i diritti del viaggiatore sono registrati sul supporto medesimo. Durante il processo di convalida, un terminale validatore elettronico verifica che la carta sia autentica e che siano presenti diritti o valore adeguati. Se i controlli preliminari danno esito positivo, il terminale validatore elettronico consuma opportunamente il valore o i diritti del viaggiatore, aggiorna i dati sulla carta e segnala che la transazione è valida, segnalando l’esito con un messaggio di conferma che può essere semplicemente un segnale acustico o luminoso offerto all’utente.

Le convalide, usando le smart card, risultano molto veloci e sicure e non richiedono alcun accesso ad un back-office remoto con il quale scambiare dati e informazioni. I sistemi card-centrici, pertanto, restano operativi anche nel caso di impossibilità di accesso alle reti di comunicazione, in quanto tutte le informazioni necessarie al processo della transazione sono contenute localmente tra il terminale validatore e la smart card.

I principali svantaggi dei sistemi card-centrici risiedono nei terminali validatori elettronici che devono essere provvisti di un certo livello di intelligenza e quindi di complessità. In particolare, i terminali validatori devono essere in possesso di tutte le informazioni necessarie a processare i Titoli Di Viaggio (TDV) e richiedono di essere periodicamente sincronizzati con un back-office remoto in modo da aggiornare e sincronizzare dati quali transazioni, impostazioni, software etc. Ciò comporta un grado di flessibilità piuttosto limitato e una complessità notevole, specie per ciò che riguarda la sincronizzazione tra back-office e terminali validatori elettronici e in particolare nel caso in cui si vogliano integrare più Sistemi di Bigliettazione Elettronica SBE diversi.

I sistemi cd. Account Based Ticketing (ABT) apportano alcune soluzioni ai problemi connessi all’uso dei sistemi Card Based Ticketing (CBT). Nei sistemi Account Based Ticketing (ABT), infatti, il trattamento dei dati avviene in un sistema centrale di backoffice remoto che risiede, ad esempio, in un server remoto. Le smart card sono ancora utilizzate, ma servono esclusivamente ad identificare in modo sicuro l’utente e non memorizzano altre informazioni.

Nei sistemi di tipo Account Based Ticketing (ABT), quando l’utente presenta la propria smart card al terminale validatore elettronico, vengono effettuate le seguenti operazioni: si autentica la carta per verificare l’identità dell’utente; si comunica al server remoto di back-office il codice di identificazione della carta; si eseguono, nel back-office remoto, le operazioni necessarie ad autorizzare ed effettuare la transazione richiesta dall’utente; si comunica l’esito della transazione all’utente. Nei sistemi di tipo Account Based Ticketing (ABT), dunque, sono trasferiti ad un server remoto sia l’archiviazione dei dati che nei sistemi Card Based Ticketing (CBT) sono memorizzati sulla smart card, sia le operazioni di elaborazione dei suddetti dati. L’inconveniente dei sistemi Account Based Ticketing (ABT) è che necessitano di connessione dati. Se, ad esempio, è ipotizzabile una connessione dati sempre attiva in un varco di metropolitana collegato ad una rete dati fissa, non altrettanto può dirsi per un autobus che lungo il suo percorso può venire a trovarsi anche in zone non coperte dalla connessione dati. È quindi indispensabile ricorrere, anche nel caso dei sistemi Account Based Ticketing (ABT), a soluzioni tecniche che prevedano comunque qualche forma di elaborazione da parte del terminale validatore in modo da consentire un corretto funzionamento anche in tutti quei casi in cui la connettività sia disponibile soltanto a tratti.

I sistemi Account Based Ticketing (ABT) semplificano le operazioni relative alla smart card che viene ridotta ad un mero strumento di identificazione dell’utente. Si parla in questo caso di smart card come Portable Object (PO), cioè oggetti portatili atti ad effettuare l’identificazione dell’utente. I Portable Object PO possono essere costituiti da smart card dedicate, ma anche da smart card relative ad altri servizi come ad esempio le tessere sanitarie, le carte d’identità, le carte bancarie etc. I Portable Object PO possono anche essere costituiti da dispositivi quali gli smartphone o tablet grazie alla tecnologia Near Field Communication (NFC).

Con la comunicazione di tipo Near Field Communication (NFC) uno smartphone può effettivamente emulare una smart card relativa ad un sistema di bigliettazione automatica. L’emulazione delle smart card da parte degli smartphone non è diretta - in quanto lo smartphone non dispone di un archivio sicuro per le chiavi crittografiche necessarie per superare i controlli di sicurezza richiesti – ma avviene attraverso tecniche dette di Host Card Emulation (HCE) in cui le chiavi crittografiche sono memorizzate su un server remoto, come nel caso delle carte bancarie.

Nel panorama attuale in cui operano le compagnie, pubbliche e private, di trasporto passeggeri, vige la più completa incompatibilità tra i diversi sistemi di gestione della bigliettazione elettronica di cui le suddette compagnie di trasporto si servono, siano essi di tipo Card Based Ticketing CBT o di tipo Account Based Ticketing ABT. A causa di una storica consuetudine, ogni compagnia, e ogni fornitore di servizi che opera in un certo segmento di mercato, realizza o si dota di soluzioni che tendono ad escludere altri soggetti dal realizzare applicazioni che possano essere integrate con le proprie e, ancor di più, che possano interagire con apparati di differente origine. Di conseguenza, l’integrazione con compagnie diverse, operanti nello stesso settore o in settori vicini risulta tutt’altro che agevole.

Questa consuetudine è a volte giustificata da ragioni commerciali, altre volte da ragioni tecniche e di sicurezza. Ad esempio nel campo dei Sistemi di Bigliettazione Elettronica (SBE) delle compagnie di trasporto passeggeri, uno scenario in cui, con le tecnologie oggi in uso, compagnie diverse provassero a sviluppare applicazioni che possano garantire l’interoperabilità e la compatibilità con altri attori dello stesso settore dovrebbe necessariamente implicare l’interazione e la modifica del Card Data Model (CDM), cioè della struttura logica dei dati dei Titoli Di Viaggio TDV codificati sulla Carta - comprendenti, ad esempio, la struttura dei record, il formato e il significato dei singoli campi registrati - con ovvie ripercussioni sulla sicurezza. Ogni sistema di bigliettazione, infatti, ha un proprio Card Data Model (CDM), di solito proprietario, e il Card Data Model è progettato per essere compatto e per rendere il più possibile incomprensibile a terzi il contenuto della carta. In particolare il Card Data Model CDM descrive le informazioni contenute e la struttura con cui tali informazioni sono memorizzate all’interno della card stessa. Le difficoltà di un approccio di questo tipo sono molteplici, soltanto le procedure di test delle eventuali modifiche da implementare, procedure da ripetere dopo ogni variazione, sarebbero molto impegnative e complesse.

Ad esempio, nel campo dei trasporti regionali Italiani, la gestione di queste procedure prevede l’istituzione di un’apposita commissione, dotata di un’adeguata piattaforma di test inter-sistema, chiamata a testare e approvare gli apparati o i sistemi integrandi prima della loro messa in servizio.

In conclusione, anche quando la progettazione di sistemi incompatibili con altri simili non è intenzionale, l'integrazione non viene mai o quasi mai concepita all'origine e risulta quindi soggetta a difficoltà, tempi e costi di realizzazione elevati.

Esiste pertanto, allo stato dell’arte, una chiara esigenza di sistemi di autenticazione e di determinazione della validità di un titolo in possesso di un utente, ad esempio un Titolo Di Viaggio (TDV), che siano interoperabili e atti a gestire titoli emessi da enti diversi, in modo da semplificare e razionalizzare non soltanto l’utilizzo da parte dell’utente, ma anche la gestione e il controllo da parte delle compagnie operanti in un dato settore, o in settori contigui, e aventi le medesime problematiche.

Il mondo moderno impone sempre più spesso alle aziende la necessità di operare in maniera sinergica per far fronte alle sfide del mercato. Può quindi essere opportuno per una Compagnia di Trasporto avvalersi di reti di vendita di altre Compagnie, commercializzare i titoli di viaggio di altre Compagnie, e offrire a più fornitori la possibilità di integrare le loro soluzioni nel Sistema di Bigliettazione Elettronica.

Sommario dell’invenzione

Sono pertanto forniti nella presente domanda di brevetto un sistema e un metodo che includono forme di realizzazione che risolvono i suddetti e altri limiti dell'approccio convenzionale alla gestione della bigliettazione elettronica.

Il Sistema di Bigliettazione Elettronica (SBE) secondo la presente invenzione è progettato per essere astratto, immateriale ed indipendente dall’architettura dell’hardware (ovvero dal SBE fisico) a cui si appoggia per operare.

Il Sistema secondo la presente invenzione, indicato nel seguito per brevità come sistema VTS, dall’acronimo dell’espressione Virtual Ticketing System, è fondato in particolare su due concetti innovativi che agiscono in sinergia: la completa smaterializzazione del supporto, ad esempio una smart card o un biglietto senza contatto o contactless, e la definizione di una interfaccia generica e ad oggetti (detti oggetti essendo, ad esempio i contratti o i titoli di viaggio, le linee di trasporto, le località e le famiglie tariffarie, le fermate etc.) con la quale viene interconnesso il Sistema di Bigliettazione Elettronica SBE fisico con il Sistema Virtual Ticketing System VTS.

Alcuni esempi di Smartcard sono la Calypso, per applicazioni complesse (ha un microprocessore a bordo), la Mifare 1k, la GTML (è una carta vecchia ma ancora in uso, ad esempio a Milano, e appartiene alla famiglia delle carte Calypso: Calypso cards were native products: CD97, CD Light, GTML, CD21, Tango), etc.

Esempi di biglietti senza contatto sono ad esempio Mifare Ultralight, Mifare EV1, etc.

La completa smaterializzazione del supporto si ottiene emulando il contenuto a basso livello della smart card o del biglietto senza contatto (ovvero il file system), all'interno di un contenitore sicuro, una smart card virtuale detta Virtual Token o V-Token.

Il V-Token ha una struttura comprendente: un header che permette a chiunque di capire il tipo di contenuto, le regole per verificare l'autenticità etc.; un payload che permette di gestire tipi di smart card e di Card Data Model CDM, anche molto diversi tra loro; un record standard ed indipendente dal Card Data Model CDM che contiene le informazioni di ultima validazione; un record che contiene una "firma" (anche multipla) che permette di stabilire l'autenticità dei dati. Grazie alla sua struttura, in pratica il V-Token è il “sostituto” funzionale della smart card e del biglietto senza contatto.

Il suddetto V-Token può essere creato ex-novo, e in questo caso il supporto è totalmente virtuale, oppure può essere derivato da un supporto fisico reale come ad esempio una smart card. In quest’ultimo caso il periferico (rappresentato da un apparato come un validatore a bordo di un mezzo di trasporto, lo smartphone di un utente, una macchina bigliettatrice automatica oppure da un applicativo come un sito di e-commerce, una biglietteria aziendale etc.) deve limitarsi a “ricopiare” il contenuto fisico di una carta ad esempio all'interno di un V-Token, in un campo chiamato Payload, senza entrare mai nel merito di come sono codificate le informazioni.

Per evitare frodi il V-Token viene firmato e verificato con lo stesso modulo SAM, (Secure Access Module SAM) che i Sistemi di Bigliettazione Elettronica SBE già gestiscono.

Un modulo Secure Access Module SAM può contenere più chiavi per effettuare differenti operazioni. Esistono ad esempio diversi tipi di moduli di accesso sicuro SAM.

Ad esempio, nei Sistemi di Bigliettazione Elettronica SBE, esistono:

● un modulo SAM usato per il validatore;

● un modulo SAM per le ricariche dei titoli di viaggio;

● un modulo SAM per il controllo;

● dei moduli SAM usati per la personalizzazione della tessera;

● dei moduli SAM usati per la validazione della tessera e dei dati;

● dei moduli SAM usati per l’inizializzazione e la personalizzazione di altri moduli SAM (i moduli SAM sono realizzati a partire da altri moduli SAM utilizzati appositamente).

L’applicazione che deve interagire con il sistema Virtual Ticketing System VTS, ad esempio per decodificare il contenuto di una smartcard, deve leggere in maniera generica, cioè senza conoscerne il Card Data Model CDM, la smartcard e deve passare la lettura al sistema Virtual Ticketing System VTS effettuando la richiesta di ottenere la decodifica del contenuto in un formato standard e comprensibile a tutti, ad esempio in formato XML (eXtensible Markup Language).Il sistema Virtual Ticketing System VTS che riceve la suddetta richiesta di decodifica di cui sopra non è in grado di comprendere il significato di quanto contenuto nel campo Payload in quanto, essendo questo contenuto generico ed indipendente dal Sistema di Bigliettazione Elettronica SBE, non conosce i criteri e il Card Data Model con il quale è stata scritta la smart card che viene ora letta. Il Sistema Virtual Ticketing System VTS, quindi, non sarebbe in grado di soddisfare la richiesta pervenuta dall'Applicativo senza il secondo contenuto innovativo della presente invenzione che entra in gioco a questo punto. Il Sistema Virtual Ticketing System VTS utilizza una libreria esterna, un cd. plugin, scritta ad hoc per il Sistema di Bigliettazione Elettronica SBE fisico all'interno del quale il contenuto della smartcard appena letta ha un preciso significato. È compito di questo plugin soddisfare la richiesta di decodifica dopodiché sarà compito del sistema Virtual Ticketing System VTS veicolare la risposta in maniera sicura ed affidabile al chiamante, cioè all’applicazione che ha effettuato la richiesta di decodifica.

Sia il formato interno di codifica del V-Token che l'interfaccia ad oggetti di cui il suddetto plugin è provvisto, possono essere standardizzate e rese pubbliche in modo da permettere ai gestori dei Sistema di Bigliettazione Elettronica SBE di poter scrivere dei propri plugin VTS per interfacciare il proprio Sistema di Bigliettazione Elettronica SBE al sistema Virtual Ticketing System VTS oggetto della presente invenzione senza dover esporre dettagli riservati interni, e a chi scrive applicazioni di poterlo fare una volta per tutte in modo tale da potersi interfacciare con Sistemi di Bigliettazione Elettronica SBE multipli e diversi tra loro.

Tutto questo perché secondo la presente invenzione l’applicazione che deve interagire con il sistema Virtual Ticketing System VTS non ha bisogno di conoscere i dettagli di come vengono gestiti i supporti specifici del Sistema di Bigliettazione Elettronica SBE (es. vendita, rinnovo, validazione, verifica, etc.), ma vede tutti i Sistemi di Bigliettazione Elettronica SBE nello stesso modo, utilizzando lo stesso linguaggio.

In sintesi il sistema Virtual Ticketing System VTS secondo la presente invenzione definisce una sorta di piattaforma generica ed aperta che permette agli utilizzatori di potersi interfacciare con molti Sistemi di Bigliettazione Elettronica SBE diversi e ai gestori di questi Sistemi di Bigliettazione Elettronica SBE di poter offrire i propri servizi ad una moltitudine di applicazioni terze.

Inoltre, il sistema Virtual Ticketing System VTS non si limita alla sola definizione di interfacce, ma le correda di tecnologie atte a ridurre o eliminare i rischi dovuti alle frodi ed ai malfunzionamenti, utilizzando il meglio delle tecniche crittografiche oggi disponibili.

Grazie al sistema e al metodo secondo la presente invenzione, è possibile, ad esempio, realizzare una completa interoperabilità tra una pluralità di titoli di accesso a servizi diversi semplificando la loro gestione da parte degli utenti.

Gli utenti, infatti, saranno messi nelle condizioni di accedere ai diversi servizi, fruibili normalmente con un diverso sistema di autenticazione ciascuno, tramite l’utilizzo del proprio smartphone.

Nel campo della bigliettazione elettronica (ad esempio per la gestione dei Titoli Di Viaggio TDV nel trasporto passeggeri pubblico e privato, per la gestione del pagamento della sosta in aree parcheggio etc.) la presente invenzione consente di raggiungere i seguenti traguardi: sportelli di biglietteria multi-compagnia; portali di e-Commerce multi-compagnia; rivendite multi-compagnia; emettitrici automatiche self-service multi-compagnia; App per smartphone multi-compagnia; applicativi di controlleria multi-compagnia etc.

Gli applicativi legati al sistema Virtual Ticketing System VTS secondo la presente invenzione (ad esempio siti di e-commerce, biglietterie online, portali di società di trasporti etc.) sono in grado di operare con qualunque Sistema di Bigliettazione Elettronica SBE dotato di interfaccia Virtual Ticketing System VTS senza dover conoscere nessuna delle sue particolarità come, ad esempio, la struttura del sistema tariffario, le regole di rinnovo, il Card Data Model, le tariffe etc. Una ipotetica nuova compagnia che volesse entrare a fare parte del sistema per beneficiare dell’interoperabilità con altre compagnie del settore verrebbe quindi semplicemente e direttamente innestata nell'applicativo legato al sistema Virtual Ticketing System VTS e diventerebbe immediatamente operativa, senza la necessità di effettuare modifiche dal lato dell’applicativo stesso.

All’interno del sistema Virtual Ticketing System VTS, infine, detti applicativi possono essere realizzati dalle compagnie interessate o da Terze Parti, grazie a Software Developer Kit SDK che verranno resi disponibili. La realizzazione di nuovi applicativi, quindi (o l’estensione di quelli esistenti), risulta favorita dalla possibilità di utilizzare detti applicativi su più sistemi; chi svilupperà applicativi compatibili con il sistema Virtual Ticketing System VTS secondo l’invenzione potrà proporli a tutte le compagnie dotate del sistema Virtual Ticketing System VTS senza dover effettuare modifiche o incorrere in lunghe procedure di test e validazione. Il costo di realizzazione di nuovi applicativi Virtual Ticketing System VTS potrà pertanto essere distribuito tra più compagnie, abbassandone l’impatto economico dello sviluppo. Breve descrizione delle figure

Ulteriori caratteristiche e vantaggi dell’invenzione risulteranno evidenti dalla lettura della descrizione seguente fornita a titolo esemplificativo e non limitativo, con l’ausilio delle figure illustrate nelle tavole allegate, in cui:

Fig. 1 illustra uno schema a blocchi del sistema secondo la presente invenzione; Fig. 2 illustra le diverse interazioni tra i blocchi che compongono il sistema VTS; Fig. 3 illustra l’impiego della libreria VTS Plugin,

Fig. 4 illustra l’architettura di comunicazione e i protocolli utilizzati in una forma di realizzazione, e

Fig. 5 illustra l’architettura del sistema nel caso di app per smartphone.

Le parti componenti dell’apparato secondo la presente descrizione sono stati rappresentati nei disegni, ove opportuno, con simboli convenzionali, mostrando solo quei dettagli specifici che sono pertinenti alla comprensione delle forme di realizzazione della presente invenzione, in modo da non evidenziare dettagli che saranno immediatamente evidenti, ai tecnici esperti dell'arte, in riferimento alla descrizione qui riportata.

Descrizione dettagliata dell’invenzione

Il sistema oggetto della presente invenzione impiega una combinazione di Account Based Ticketing ABT e Host Card Emulation HCE in modo da migliorare le caratteristiche offerte dalle due suddette tecnologie.

In riferimento alla Fig. 1 allegata, l’architettura di un esempio del sistema Virtual Ticketing System VTS 1 secondo la presente descrizione comprende un server remoto 10 associato ad opportuni mezzi di memorizzazione di dati MEM in forma digitale e collegato ad una rete di comunicazione dati NET come ad esempio la rete Internet. Il sistema Virtual Ticketing System 1 comprende una pluralità di Sistemi di Bigliettazione Elettronica SBE, indicati con il riferimento 11, atti a controllare e verificare la validità di Titoli Di Viaggio TDV su richiesta di un utente. Il sistema 1 comprende inoltre una pluralità di apparati 12 per l’acquisto e la vendita di titoli di viaggio, detti apparati 12 essendo provvisti di programmi SoftWare SW applicativi atti a comunicare con detto server remoto 10 per l’acquisto e l’utilizzo di titoli di viaggio elettronici in mobilità. Esempi di questi apparati 12 comprendono gli apparecchi per la bigliettazione automatica 12a, ad esempio le vending machine che vengono installate nelle stazioni ferroviarie, dei bus e della metropolitana; gli apparecchi per la validazione dei titoli di viaggio 12b che vengono ad esempio installati nelle stazioni ferroviarie, spesso in prossimità dei binari, oppure a bordo dei mezzi di trasporto (tram, autobus); e i dispositivi elettronici di elaborazione e comunicazione 12c quali personal computer, tablet, smartphone etc.

Detto server remoto 10 è associato ad una libreria 15, detta Virtual Ticketing System Plugin o VTS Plugin. Detta libreria Virtual Ticketing System Plugin 15 viene installata anche a bordo dei Sistemi di Bigliettazione Elettronica (SBE) 11 che fanno parte del sistema Virtual Ticketing System VTS 1.

Questa libreria Virtual Ticketing System Plugin 15 serve a disaccoppiare il sistema Virtual Ticketing System VTS 1 dal Sistema di Bigliettazione Elettronica SBE 11 a cui si interfaccia.

Di solito, i servizi espongono funzioni che hanno un accoppiamento stretto con il sistema che interfacciano. La libreria VTS Plugin 15 permette di utilizzare la stessa infrastruttura (Server VTS 10, Software Development Kit SDK, protocolli, etc) potendo semplicemente cambiare tecnologia di Sistema di Bigliettazione Elettronica SBE 11 e fornitore con un file di configurazione 25 posto sul Server VTS. Il file di configurazione 25 contiene il Pathname 25a della Dynamic-Link Library DLL da caricare all'avvio e altri campi 25b, 25c. Il Server VTS 10 può gestire in contemporanea più librerie dinamiche DLL anche su sistemi o fornitori diversi. Anche il Card Data Model CDM è noto solo alla libreria DLL. Il Server VTS (o il Software Development Kit SDK) non conosce nessun dettaglio del data model DM (o delle tariffe, dei prezzi...).

La libreria VTS Plugin 15 è atta a tradurre la comunicazione tra il server remoto 10, i vari Sistemi di Bigliettazione Elettronica SBE 11 e i vari apparati 12 per l’acquisto, la validazione, l’elaborazione e la vendita di titoli di viaggio TDV, in un linguaggio comune, a oggetti e descritto in XML. Il linguaggio comune è stato definito per permettere la realizzazione della libreria dinamica DLL, qui definita come VTS Plugin 15, anche a diversi fornitori (anche concorrenti). Essendo formalizzata l'interfaccia, chiunque può fornire e integrare nel sistema una nuova libreria Plugin, anche il cliente stesso. Tale linguaggio comune viene poi utilizzato dagli attori (Applicazioni) per comunicare con i vari Sistemi di Bigliettazione Elettronica SBE 11 senza dover necessariamente utilizzare i loro protocolli nativi e proprietari. La libreria VTS Plugin 15, una volta resa disponibile per un generico Sistema di Bigliettazione Elettronica SBE 11, è poi utilizzabile sia direttamente (es. per applicazioni “off-line”) oppure tramite la mediazione del Server VTS 10. In particolare la libreria VTS Plugin 15 permette di svincolarsi dal Sistema di Bigliettazione Elettronica SBE 11 selezionato e permette al cliente di eseguire le operazioni desiderate senza preoccuparsi dei dettagli implementativi. In particolare, la libreria VTS Plugin 15 permette agli utenti di vedere i diversi sistemi SBE 11 come se fossero tutti uguali, ovvero permette una interazione ad alto livello slegata dai dettagli implementativi. Pertanto, il sistema VTS 1 realizza una interfaccia verso l’utente che “uniforma” i diversi sistemi SBE 11.

Il sistema VTS 1 prevede inoltre una libreria VTS-Lib 20 da installare sui diversi apparati 12.

La libreria VTS-Lib 20 deve essere utilizzabile in vari contesti, sia in versione “online” che “off-line”. Il sistema VTS 1 utilizza un file “ServiceVtsFrontend.wsdl” che descrive il formato delle chiamate Web Service WS che dovranno essere utilizzate dalla Libreria VTS-Lib 20.

Pertanto, la libreria VTS-Lib 20 e l’interfaccia Web Services Description Language WSDL sono praticamente identiche ed equivalenti. In particolare hanno gli stessi metodi e gli stessi parametri delle chiamate.

Nel caso di utilizzo solamente on-line della libreria, la libreria VTS-Lib 20 deve poter essere utilizzabile in modalità completamente on-line. In questo caso le librerie di monetica (il termine monetica, ovvero "moneta automatica", designa l'insieme dei trattamenti elettronici, informatici e telematici necessari alla gestione dei pagamenti tramite carte di credito e affini; più in generale si occupa della gestione automatica, cioè informatizzata, del denaro) e tutta l’elaborazione dei dati e delle tariffe avviene “lato server”. In locale non viene elaborato e/o prodotto nessun dato.

Questo permette di sviluppare una applicazione leggera che non necessita di dati in locale e che non produce dati che poi devono essere spediti al server centrale, pena la loro perdita.

Nella soluzione qui proposta non esiste alcun Wallet locale per memorizzare dati sensibili quali i V-Token e/o i dati di configurazione. È compito della applicazione salvare e/o proteggere queste informazioni.

I V-Token in formato binario sono prelevati e forniti, tramite appositi metodi, alla libreria VTS-Lib 20, direttamente dalla applicazione chiamante che deve saper utilizzare queste informazioni (saper leggere e scrivere i V-Token).

Inoltre è compito della applicazione interagire direttamente con le periferiche per la gestione dei supporti RFID, come ad esempio i lettori contactless. È compito quindi della applicazione leggere e scrivere (a basso livello) i supporti fisici come ad esempio le Smartcard e/o i Biglietti senza contatto. In particolare è compito della applicazione convertire un supporto fisico in un V-Token e viceversa. Ovviamente la libreria VTS-Lib 20 “entra in gioco” ogni volta che occorre gestire il Card Data Model (ad esempio Info card, aggiunta contratto su carta, validazione carta, verifica carta, etc.).

Diversamente, nel caso in cui vi sia un meccanismo di caching locale (serializzazione oggetti), per limitare il traffico dati verso il Server VTS 10, ogni volta che vengono richieste informazioni frequenti e comuni, la libreria VTS-Lib 20 deve permettere all’applicazione di salvare in locale (su file system) la risposta o gli oggetti restituiti dal Server VTS 10 ogni volta che questo viene interrogato. Questo per poterli riutilizzare al prossimo riavvio senza dover attendere la “sincronizzazione” dei dati. Ad esempio la lista degli operatori di trasporto, le località tariffarie, l’elenco delle fermate etc.

Dato che è compito della applicazione effettuare/decidere tale salvataggio, la libreria VTS-Lib 20 deve permettere la serializzazione e il successivo caricamento di qualsiasi oggetto o lista di oggetti.

Nel caso di utilizzo solamente off-line della libreria, la libreria VTS-Lib 20 deve poter essere utilizzabile in modalità completamente off-line. In questo caso le librerie di monetica e tutta l’elaborazione dei dati e delle tariffe avviene in locale.

Questa modalità permette all’applicazione di lavorare sconnessa dal centro. Ovviamente alcune delle chiamate alla libreria VTS-Lib 20 potranno comunque richiede la connessione con il centro, ovvero con il server VTS 10. In questo caso se la connessione è assente la libreria VTS-Lib 20 restituirà un errore sulla specifica chiamata.

Tutte le funzioni o metodi che non prevedono l’interrogazione esplicita del centrale, ovvero il server VTS 10, potranno essere eseguite dall’applicazione anche in modalità sconnessa. In questo caso la libreria VTS-Lib 20 utilizza un componente ad-hoc, chiamato VTS Plugin 15 che è quello che permette alla Libreria VTS-Lib 20 di interagire con le librerie di monetica e con i dati locali (es. file con i Parametri Tariffari e file di Activity).

Dato che il VTS Plugin 15 necessita, di tanto in tanto, di comunicare con il proprio Sistema di Bigliettazione Elettronica SBE 11 per aggiornare tali file, la Libreria VTS-Lib 20 espone un metodo apposito (Synchronize) che deve essere chiamato dall’applicazione ogni tanto. Pertanto sarà disponibile sul server VTS 10 una libreria VTS Plugin 15 per ogni tipologia di Sistema di Bigliettazione Elettronica SBE 11 considerato e supportato dal sistema VTS 1. Si consiglia di creare un Thread parallelo dedicato, per svolgere tale compito, in modo tale da scambiare dati con il Server SBE 11 in parallelo alle normali richieste (es. query dati).

Nel caso invece di utilizzo “on-line” della Libreria VTS-Lib 20, mediata dal VTS Plugin 15, essa ha il controllo completo delle periferiche di monetica ed espone metodi per interagire direttamente con il lettore RFID (ad esempio) manlevando l’applicazione da tale compito. Ovviamente in questo caso saranno gestibili solo lettori e/o apparati supportati.

Vi è poi un ultimo caso, di utilizzo della libreria in modalità ibrida. La libreria VTS-Lib 20 deve poter essere utilizzabile in modalità ibrida (on-line e off-line). Questo è reso possibile grazie al fatto che i Web Service esposti dal VTS Server 10 e l’interfaccia “C” del VTS Plugin 15 sono praticamente identici. Questo approccio permette la creazione di applicazioni SAM-less che possono comunque operare in locale sconnesse (Smartcard lette fuori da una sessione sicura e verifica firma non fatta). Se serve utilizzare un Hardware Security Module HSM al centro, ovvero al server VTS 10, l’applicazione può ritornare on-line e quindi utilizzare tale feature. Il Sistema VTS 1 qui descritto ha lo scopo di fare da Interfaccia applicativa tra un generico client, sia esso di tipo “orientato al pubblico” (ad esempio un sito di ecommerce, una APP su smartphone, le colonnine di parcheggio, i Ticket Vending Machine TVM di terze parti etc.) oppure “orientato ad operatori interni”, (come ad esempio biglietterie aziendali, rivendite, terminali di controlleria, etc.), e uno più Sistemi di Bigliettazione Elettronica SBE 11, anche diversi tra loro, senza mai entrare “nel merito” del loro funzionamento interno (ad esempio del card data model, delle politiche tariffarie, degli algoritmi di calcolo dei prezzi delle tariffe, etc.).

Il Server VTS 10 astrae i concetti di tariffazione ed offre un’interfaccia semplice, stabile ed astratta a chiunque si debba interfacciare con esso.

La Applicazione “terza” interagisce con il sistema SBE 11 in maniera del tutto generica e indipendente dal particolare impianto, fornitore del SBE 11 o tecnologia adottata.

Il server centrale VTS 10, che è l’entità che permette l’interazione astratta tra sistemi SBE 11 eterogenei, non ha al suo interno nessuna implementazione di un Sistema di Bigliettazione Elettronica SBE 11, ma utilizza la libreria esterna detta VTS Plugin 15.

Tale libreria VTS Plugin 15 è l’unica che poi dialoga in maniera nativa con il Sistema di Bigliettazione Elettronica SBE 11 al quale si interfaccia. Per questo, sul server centrale VTS 10 sono presenti diverse librerie VTS Plugin 15, una per ogni Sistema di Bigliettazione Elettronica SBE 11 supportato dal sistema e in esso integrato. In Figura 2 sono illustrati tre Sistemi di Bigliettazione Elettronica diversi SBE “A”, SBE “B” e SBE “C”, indicati tutti con il riferimento generale 11. Il Sistema VTS 1 mette in comunicazione i Sistemi di Bigliettazione Elettronica 11 con i diversi apparati 12. In particolare gli apparati 12 possono essere ad esempio i siti di ecommerce, le biglietterie, le app direttamente su smartphone, oppure gli apparecchi per la bigliettazione automatica detti vending machine che vengono installate nelle stazioni ferroviarie, dei bus e della metropolitana, gli apparecchi per la validazione dei titoli di viaggio che vengono ad esempio installati nelle stazioni ferroviarie, spesso in prossimità dei binari, oppure a bordo dei mezzi di trasporto (tram, autobus), e i dispositivi elettronici di elaborazione e comunicazione quali personal computer, tablet, smartphone etc.

La libreria VTS Plugin 15 si occupa di tradurre in un “linguaggio comune”, a oggetti e descritto in XML. Tale linguaggio viene poi utilizzato dagli attori (Applicazioni) per comunicare con i vari Sistemi di Bigliettazione Elettronica SBE 11 senza dover necessariamente utilizzare i loro protocolli nativi e proprietari.

La libreria VTS Plugin 15, una volta resa disponibile per un generico Sistema di Bigliettazione Elettronica SBE 11, è poi utilizzabile sia direttamente (ad esempio per applicazioni “off-line”) oppure tramite la mediazione del Server VTS 10.

La Figura 3 illustra come il Server VTS 10 dialoga con le applicazioni e utilizza le librerie VTS Plugin 15 per interfacciarsi con i vari Sistemi di Bigliettazione Elettronica 11.

Il Server centrale VTS 10 è, a sua volta, diviso in due macro-componenti: un processo front-end 16 e un processo back-end 17 che si occupa della gestione vera e propria del sistema VTS 1 (chiamato per semplicità VTS Server).

Il VTS Server 10, cuore del sistema VTS 1, è in grado di dialogare contemporaneamente con uno (o più) front-end 16 e una applicazione esterna (o server esterno 18) utilizzando il protocollo nativo (VTS Native Protocol), questo in parallelo. In alternativa o in affiancamento è possibile istallare due (o più) Server VTS in parallelo, uno dedicato al front-end 16 e l’altro dedicato al dialogo con il server esterno 18.

Il VTS Server 10, a sua volta, dialoga con il sistema Sistema di Bigliettazione Elettronica SBE 11 (ad esempio il BIP) tramite una libreria di interfaccia esterna detta appunto VTS Plugin 15.

Questo permette di cambiare Sistemi di Bigliettazione Elettronica SBE 11 utilizzando librerie VTS Plugin 15 differenti, in questo caso i processi VTS Server 10 e front-end 16 sono gli stessi e il protocollo esposto è identico. In particolare il client (vedi ad esempio Smartphone) ignora totalmente se sta parlando con il sistema SBE “A” o “B”.

La Figura 4 mostra l’architettura di comunicazione e i protocolli utilizzati nel sistema VTS 1 nel caso del progetto BIP Piemonte.

In particolare, la centrale BIP 100 comprende un modulo Centro di Controllo Aziendale CCA 102 in comunicazione con i server VTS 104 e 106. I server VTS 104 e 106 sono in comunicazione con il resto del sistema tramite dei firewall interni 108 che permettono la comunicazione con la zona demilitarizzata DMZ 110 e con un sistema esterno 120. La comunicazione tra il modulo Centro di Controllo Aziendale CCA 102 e i server VTS 104 e 106 avviene tramite protocollo AFCS BIP. All’interno della zona demilitarizzata DMZ 110 è presente il modulo servizio VTS-WS 112. Questo modulo servizio VTS-WS 112 dialoga con l’esterno attraverso firewall esterni 114 che permettono la comunicazione con la rete internet 130 e con il sistema esterno 120. Le comunicazioni tra i server VTS 104 e 106 e il modulo servizio VTS-WS 112 o il sistema esterno 120 avvengono tramite il protocollo VTS nativo. Alla rete internet 130 sono collegati vari smartphone 116 e pc 118 che possono acquistare Titoli Di Viaggio TDV. Il sistema esterno 120 può contenere un server 124 e delle vending machine 122. Le comunicazioni che passano attraverso i firewall esterni 114 utilizzano il protocollo WS (ad esempio SOAP - Simple Object Access Protocol).

Il server remoto 10 può comprendere due parti distinte: un front-end che espone metodi WebServer WS e che viene solitamente istallato su di un server nella zona demilitarizzata DMZ chiamato VTS-WS front-end 16 (o VTS-WS), e un back-end che si occupa della gestione vera e propria del sistema VTS, detto VTS server 17. Il VTS WS front-end 16 ha l’unico compito di tradurre le chiamate WebServer WS (protocollo Simple Object Access Protocol SOAP) nel protocollo nativo del server remoto 10. Se necessario, per aumentare le performance, è disponibile il protocollo nativo VTS Native Protocol direttamente.

Il VTS Server 17 è in grado di dialogare contemporaneamente con uno o più VTS-WS 16 e con una o più applicazioni SW esterne, o con un ulteriore server esterno 18, utilizzando il protocollo nativo (VTS Native Protocol). In particolare, si possono montare "M" front-end (VTS-WS) 16 e "N" back-end (Server VTS) 17 in modo da bilanciare il traffico e creare architetture di tipo "fail-over". In alternativa o in affiancamento è possibile istallare due o più VTS server 17 in parallelo, uno dedicato al VTS-WS 16 e l’altro dedicato al dialogo con eventuali, ulteriori server esterni 18. Il VTS Server 17, a sua volta, dialoga con i Sistemi di Bigliettazione Elettronica SBE (come ad esempio il Biglietto Integrato Piemonte BIP) tramite detta libreria di interfaccia esterna VTS Plugin 15.

Questo permette di cambiare Sistema di Bigliettazione Elettronica SBE 11 (ad esempio Automatic Fare Collection System AFCS, Easy Ticketing ET, Sistema integrato di Bigliettazione Magnetica ed Elettronica SBME, …) utilizzando librerie differenti, in questo caso il VTS server 17 e il VTS-WS 16 sono gli stessi e il protocollo esposto è identico. Considerando ad esempio un Sistema di Bigliettazione Elettronica SBE 11 costituito da uno smartphone, abbiamo quindi che detto smartphone, nella comunicazione col sistema secondo l’invenzione ignora totalmente se sta comunicando con Automatic Fare Collection System AFCS, Easy Ticketing ET oppure Sistema integrato di Bigliettazione Magnetica ed Elettronica SBME.

Detto server remoto 10, inoltre, è associato ad un Hardware Security Module modulo HSM 14, un dispositivo di elaborazione fisico (ovvero hardware) che salvaguarda e gestisce le chiavi digitali per un'autenticazione forte (strong authentication) e fornisce la necessaria crittazione ai dati gestiti e trasmessi. Questi moduli Hardware Security Module HSM 14, disponibili allo stato dell’arte in varie versioni, si presentano tradizionalmente sotto forma di una scheda plug-in o di un dispositivo esterno che può collegarsi direttamente a detto server remoto 10.

Detto server remoto 10, inoltre, è atto a gestire delle smart card virtuali che replicano esattamente le smart card fisiche. In ulteriore dettaglio, il server remoto 10 provvede a creare e conservare in detti mezzi di memorizzazione una smart card virtuale ogni volta che i suddetti programmi Server Web SW applicativi lo richiedono, ad esempio quando un utente acquista un titolo di viaggio dal proprio smartphone.

In particolare, questo tipo di applicazione viene detto Account Based Ticketing ABT mentre quello che usa la carta fisica o il V-Token nello Smartphone viene detto Card Based Ticketing CBT. Il sistema VTS permette di gestire entrambe le modalità'. Detto server remoto 10, inoltre, aggiorna le smart card conservate, sia in tempo reale - ogni volta che detti Sistemi di Bigliettazione Elettronica SBE 11 e detti apparati 12 svolgono operazioni on-line, ossia in presenza di connessione col server remoto 10 - sia in tempo differito, quando cioè le suddette operazioni vengono eseguite off-line, ossia in assenza di connessione col server remoto 10.

Per poter effettuare operazioni sulle smart card virtuali conservate nel server remoto 10 è necessario poter identificare e localizzare univocamente ciascuna delle smart card virtuali. Al momento della creazione di una nuova smart card virtuale, quindi, il server remoto 10 provvede ad associare ad essa uno o più numeri identificativi virtuali, Virtual Unique Identification Number VUID. Tramite il numero Virtual Unique Identification Number VUID, detti Sistemi di Bigliettazione Elettronica SBE 11 e detti apparati 12, grazie ai programmi SoftWare SW applicativi di cui sono provvisti, possono effettuare qualunque operazione tra quelle disponibili (ad esempio una convalida), sulla smart card virtuale individuata.

Detto Virtual Unique Identification Number VUID viene preferibilmente prodotto da un modulo detto VUID Resolution Plug-In VRP 13 associato a detto server remoto 10 e atto a convertire un numero identificativo ID qualsiasi di un utente (ad esempio un codice digitato manualmente; il numero di serie (Serial Number S/N) di una carta di tipo MIFARE per l’accesso ad un servizio pubblico o ad un trasporto pubblico; il Serial Number S/N di una carta Calypso per l’accesso ad un trasporto pubblico; il Primary Account Number PAN - - di una carta bancaria; il codice contenuto in un QR-code che può anche essere generato dal sistema secondo l’invenzione etc.) in un codice Virtual Unique Identification Number VUID univoco e atto ad evitare possibili conflitti di numerazione all’interno del sistema.

Detto modulo VUID Resolution Plug-In VRP 13 è dunque atto ad effettuare l’autenticazione del supporto, ove la semplice identificazione non fosse sufficiente e risolvere l’ID del Cliente in un nuovo numero identificativo detto Virtual Unique Identification Number VUID.

Di solito per autenticare si utilizzano metodi nativi del supporto, ad esempio una carta Calypso ha modo di essere verificata (verifica sessione con la SAM) altre carte hanno meccanismi di encryption in hardware. In generale l'autenticazione viene fatta usando metodi “nativi” del supporto utilizzato.

Il modulo VUID Resolution Plug-In VRP 13 può essere realizzato come SoftWare SW o come modulo HardWare HW e può avere struttura e complessità varie rendendo possibile sia l’importazione diretta e trasparente dell’ID utente, sia la sua modifica tramite l’aggiunta di cifre corrispondenti al tipo di carta, sia la generazione di un nuovo VUID Resolution Plug-In VUID tramite operazioni crittografiche (es. MIFARE) oppure tramite autenticazione di una carta, ad esempio di tipo Calypso attraverso il modulo SAM, oppure ancora tramite la generazione di un token generato attraverso un processo in ambiente sicuro Payment Card Industry (PCI) PIN Transaction Security (PTS), PCI-PTS del Primary Account Number PAN di una carta bancaria. Il Primary Account Number, è il numero identificativo di una carta di debito (es. il Bancomat) e di una carta di credito associato a queste fin dall'emissione. Un algoritmo associato al Primary Account Number PAN genera il Personal Identification Number PIN, che invece è l'identificativo dell'utente.

La Fig.5 mostra l’architettura del sistema nel caso di utilizzo di uno smartphone 12 per memorizzare i Titoli Di Viaggio TDV. In questo caso sul telefonino viene scaricata la App che permette tramite la libreria VTS-Lib 20 di dialogare con il sistema VTS 1 e il Sistema di Bigliettazione Elettronica SBE 11 selezionato.

Claims (11)

1. Rivendicazioni 1. Sistema di bigliettazione elettronica virtuale (VTS) comprendente: - un server remoto (10), associato a mezzi di memorizzazione di dati (MEM) e collegato ad una rete di comunicazione dati (INTERNET), - una pluralità di Sistemi di Bigliettazione Elettronica SBE (11) atti a controllare e verificare la validità di Titoli Di Viaggio (TDV), - una pluralità di apparati (12) provvisti di programmi software (SW) applicativi atti a comunicare con detto server remoto (10) per l’acquisto e la validazione di detti Titoli Di Viaggio (TDV), - una pluralità di dispositivi smartphone associati ad utenti, - una libreria Virtual Ticketing System Plugin (15), associata a detto server remoto (10) e atta a tradurre la comunicazione tra detto server remoto (10), detti Sistemi di Bigliettazione Elettronica SBE (11) e detti apparati (12), - un modulo VUID Resolution Plug-In VRP (13) associato a detto server remoto (10) e atto a convertire una smart card fisica o un identificativo ID di un utente in un codice univoco (VUID) atto ad evitare possibili conflitti di numerazione all’interno del sistema, generando pertanto smart card virtuali, in cui detta smart card virtuale e detto codice univoco (VUID) sono memorizzati in detti mezzi di memorizzazione di dati (MEM), - una pluralità di smart card virtuali emulate da detti dispositivi smartphone tramite tecniche di Host Card Emulation HCE, in cui dette smart card virtuali sono atte a memorizzare detti Titoli Di Viaggio (TDV), in cui detta pluralità di apparati (12) e detti smartphone comprendono a loro volta una Libreria VTS-Lib (20), e in cui detto sistema tramite detta libreria Virtual Ticketing System Plugin (15) e/o tramite detta Libreria VTS-Lib (20) gestisce le smart card virtuali per l’acquisto e la validazione di detti Titoli Di Viaggio (TDV) tramite detti apparati (12).
2. 2. Sistema di bigliettazione elettronica virtuale (VTS) secondo la rivendicazione 1, in cui detta libreria Virtual Ticketing System Plugin (15) è atta a tradurre la comunicazione tra detto server remoto (10), i Sistemi di Bigliettazione Elettronica SBE (11) e gli apparati (12) per l’acquisto, la validazione, l’elaborazione e la vendita di titoli di viaggio, in un linguaggio comune a oggetti e descritto in XML.
3. 3. Sistema di bigliettazione elettronica virtuale (VTS) secondo la rivendicazione 1 o la rivendicazione 2, in cui detta libreria Virtual Ticketing System Plugin (15) realizza una interfaccia che permette di vedere i diversi Sistemi di Bigliettazione Elettronica SBE (11) come se fossero tutti uguali, realizzare una interazione ad alto livello slegata dai dettagli implementativi, e dialogare in maniera “nativa” con i diversi Sistemi di Bigliettazione Elettronica SBE (11).
4. 4. Sistema di bigliettazione elettronica virtuale (VTS) secondo una o più delle precedenti rivendicazioni, in cui detta libreria VTS-Lib (20) utilizza detta libreria Virtual Ticketing System Plugin (15) per interagire con le librerie di monetica.
5. 5. Sistema di bigliettazione elettronica virtuale (VTS) secondo una o più delle precedenti rivendicazioni, in cui detti apparati (12) sono siti di e-commerce, biglietterie, app su smartphone, apparecchi per la bigliettazione automatica, apparecchi per la validazione dei titoli di viaggio, dispositivi elettronici di elaborazione e comunicazione quali personal computer, tablet, smartphone etc.
6. 6. Sistema di bigliettazione elettronica virtuale (VTS) secondo una o più delle precedenti rivendicazioni, in cui detto server remoto (10) comprende un front-end che espone metodi WebServer WS chiamato VTS-WS front-end (16) e un back-end che si occupa della gestione vera e propria del sistema VTS, detto VTS server (17).
7. 7. Sistema di bigliettazione elettronica virtuale (VTS) secondo la rivendicazione 6, in cui detto VTS-WS front-end (16) ha il compito di tradurre le chiamate WebServer WS nel protocollo nativo del server remoto (10) e detto VTS Server (17) è in grado di dialogare contemporaneamente con uno o più VTS-WS front-end (16) e con una o più applicazioni SW esterne, o con un ulteriore server esterno (18), utilizzando il protocollo nativo.
8. 8. Sistema di bigliettazione elettronica virtuale (VTS) secondo la rivendicazione 7, in cui detto VTS Server (17) dialoga con i Sistemi di Bigliettazione Elettronica SBE (11) tramite detta libreria di interfaccia esterna VTS Plugin (15).
9. 9. Sistema di bigliettazione elettronica virtuale (VTS) secondo una o più delle precedenti rivendicazioni, in cui detto server remoto (10) comprende un modulo Hardware Security Module HSM (14) che salvaguarda e gestisce le chiavi digitali per un'autenticazione forte (strong authentication) e fornisce la necessaria crittazione ai dati gestiti e trasmessi.
10. 10. Metodo di bigliettazione elettronica virtuale (VTS) comprendente i passi di: - predisporre un server remoto (10), - associare a detto server remoto (10) mezzi di memorizzazione di dati (MEM), - collegare detto server remoto (10) ad una rete di comunicazione dati (INTERNET), - predisporre una pluralità di Sistemi di Bigliettazione Elettronica SBE (11), - utilizzare detti Sistemi di Bigliettazione Elettronica SBE (11) per emettere Titoli Di Viaggio (TDV), - predisporre una pluralità di apparati (12) provvisti di programmi software (SW) applicativi atti a comunicare con detto server remoto (10) per l’acquisto e la validazione di detti Titoli Di Viaggio (TDV), - predisporre una pluralità di dispositivi smartphone associati ad utenti, - predisporre una libreria Virtual Ticketing System Plugin (15), associata a detto server remoto (10) e atta a tradurre la comunicazione tra detto server remoto (10), detti Sistemi di Bigliettazione Elettronica SBE (11) e detti apparati (12), - predisporre un modulo VUID Resolution Plug-In VRP (13) associato a detto server remoto (10) e atto a convertire una smart card fisica o un identificativo ID di un utente in un codice univoco (VUID) atto ad evitare possibili conflitti di numerazione, generando pertanto smart card virtuali, - memorizzare detta smart card virtuale e detto codice univoco (VUID) in detti mezzi di memorizzazione di dati (MEM), - predisporre una pluralità di smart card virtuali emulate da detti dispositivi smartphone tramite tecniche di Host Card Emulation HCE, - memorizzare detti Titoli Di Viaggio (TDV) in dette smart card virtuali, - predisporre una Libreria VTS-Lib (20) in detta pluralità di apparati (12) e detti smartphone, e - gestire le smart card virtuali per l’acquisto e la validazione di detti Titoli Di Viaggio (TDV) tramite detti apparati (12) per mezzo di detta libreria Virtual Ticketing System Plugin (15) e/o detta Libreria VTS-Lib (20).
11. 11. Metodo di bigliettazione elettronica virtuale (VTS) secondo la rivendicazione 10, in cui detta libreria Virtual Ticketing System Plugin (15) è atta a tradurre la comunicazione tra detto server remoto (10), i Sistemi di Bigliettazione Elettronica SBE (11) e gli apparati (12) per l’acquisto, la validazione, l’elaborazione e la vendita di titoli di viaggio, in un linguaggio comune a oggetti e descritto in XML.