ITTO20130459A1 - Procedimento per acquisire e validare un titolo, relativo dispositivo mobile, sistema di pagamento e prodotto informatico - Google Patents

Description

“Procedimento per acquisire e validare un titolo, relativo dispositivo mobile, sistema di pagamento e prodotto informaticoâ€

TESTO DELLA DESCRIZIONE

Campo dell’invenzione

La presente invenzione riguarda le tecniche per acquistare e validare un titolo, quale ad esempio un biglietto elettronico, tramite dispositivi mobili, quali ad esempio cellulari.

Sfondo tecnologico

La Figura 1 mostra una generica architettura di un sistema per l’acquisto tramite dispositivi mobili.

Nell’esempio considerato, un esercente 1 offre certi prodotti o servizi e un utente desidera comprare alcuni di questi prodotti tramite il suo dispositivo mobile 2.

Tipicamente, tale pagamento non viene effettuato direttamente tramite l’operatore telefonico sulla bolletta telefonica o sul traffico residuo di una scheda prepagata, ma il pagamento viene gestito tramite un operatore di pagamento 3, quale ad esempio il servizio bancario che gestisce il conto corrente o la carta di credito del utente.

Di conseguenza, à ̈ di notevole importanza come vengono effettuate le varie comunicazioni tra questi partecipanti alla vendita, in modo tale che l’operazione sia semplice e sicura. Infatti, nell’ambito dei pagamenti tramite dispositivi mobili à ̈ indispensabile autenticare il numero telefonico del dispositivo mobile 2. Tuttavia, anche se gli attuali standard di comunicazione mobile, quale ad esempio Global System for Mobile Communications (GSM) o Universal Mobile Telecommunications System (UMTS), prevedono meccanismi per autenticare il numero telefonico di un dispositivo mobile 2, tali meccanismi non sono resi disponibile all’utenza, ad esempio all’esercente 1 o l’operatore di pagamento, dagli operatori mobili.

La Figura 2 mostra una tipica soluzione di un sistema di pagamento che à ̈ in grado di gestire una pluralità di esercenti 1 che offrono prodotti e/o servizi e una pluralità di operatori di pagamento 3, quale ad esempio istituti bancari. Ad esempio, nella Figura 2, sono mostrati due esercenti 1a e 1b, e due operatori di pagamento 3a e 3b.

Nell’esempio considerato, il sistema comprende inoltre un sistema di gestione del pagamento 4 che interfaccia la pluralità di esercenti 1 con la pluralità di operatori di pagamento 3.

L’esperto del ramo apprezzerà che alcuni di questi aspetti del sistema di pagamento possono essere realizzati tramite hardware dedicata o tramite software. Ad esempio, le operazioni del sistema di gestione del pagamento possono essere implementate tramite porzioni di codice software che vengono eseguite tramite un computer o una sistema di elaborazione con architettura distribuita (detto cloud computing).

Nell’esempio considerato, il sistema di gestione 4 à ̈ responsabile di convertire le comunicazioni ricevute dai vari esercenti 1 ed inviarle ai rispettivi operatori di pagamento 3. In questo modo, non à ̈ necessario che ciascun esercente 1 debba essere compatibile con i vari protocolli di comunicazioni degli operatori di pagamento 3, ma à ̈ sufficiente che gli esercenti 1 implementino soltanto un unico protocollo di comunicazione, ovvero il protocollo di comunicazione del sistema di gestione 4.

Nell’esempio considerato, l’operatore non à ̈ necessariamente direttamente l’istituto bancario dell’utente, ma potrebbe anche essere un altro operatore di pagamento abilitato che consente l’iscrizione ed il conseguente utilizzo del servizio a clienti di banche non aderenti. Ad esempio, l’utente potrebbe registrare i dati della sua carta di credito e il servizio di pagamento potrebbe utilizzare il circuito di pagamento della carta di credito.

Di conseguenza, nell’esempio considerato, il dispositivo mobile 2 invia, ad esempio tramite un messaggio del servizio SMS, una richiesta di acquisto ad un esercente 1. In seguito, l’esercente 1 inoltra tale richiesta al sistema di gestione 4 che converte la richiesta e inoltra la richiesta convertita al corretto operatore di pagamento 3.

Ad esempio, per identificare l’operatore di pagamento associato ad uno specifico dispositivo mobile o utente 2, il sistema di gestione 4 può comprendere una banca dati 40 che contiene dati che associano ad ogni dispositivo mobile o utente un rispettivo operatore di pagamento.

Di conseguenza, nell’esempio considerato, il sistema di gestione 4 riceve da un esercente 1 una richiesta di pagamento che contiene dati che permettono di identificare il dispositivo o l’utente che richiede un acquisto. Ad esempio, tale dato che permette di identificare l’utente può essere il numero del cellulare o dispositivo mobile 2 che ha inviato il SMS con la richiesta di acquisto, o il suo codice IMEI (International Mobile Equipment Identity). Una volta individuato tramite la banca dati 40 il rispettivo operatore di pagamento 3, il sistema di gestione 4 può inviare la richiesta di pagamento al rispettivo operatore di pagamento 3.

L’operatore di pagamento 3 a sua volta può quindi autorizzare o negare il pagamento. Ad esempio, l’operatore di pagamento 3 può verificare se l’utente abbia sufficiente credito. Di conseguenza, l’operatore di pagamento 3 invia all’esercente 1 attraverso il sistema di gestione 4 un messaggio che conferma o nega il pagamento e l’esercente 1 può eventualmente consegnare/erogare il prodotto/servizio richiesto. Inoltre, anche l’operatore di pagamento 3 può inviare una conferma di avvenuto pagamento all’utente 2. Ad esempio, l’operatore 3 può inviare a tale scopo all’utente 2 un messaggio del servizio SMS o una e-mail che contiene un riepilogo sulla somma addebitata e gli estremi dell’esercente che ha richiesto il pagamento.

Come menzionato in precedenza, il sistema di gestione 4 comprende tipicamente una banca dati 40 che contiene dati che permettono di associare ai vari dispositivi mobili o utenti 2 i rispettivi operatori di pagamento 3. Ad esempio, tale associazione può essere creata tramite un’iscrizione al servizio di pagamento. Ad esempio, tale iscrizione potrebbe essere effettuata presso l’operatore di pagamento 3 che comunica i dati di iscrizione al sistema di gestione 4.

In generale, per aumentare la sicurezza del sistema, può anche essere previsto che l’utente debba autorizzare ogni pagamento tramite l’inserimento di un codice di sicurezza. Ad esempio, tale meccanismo può essere utile per evitare pagamenti in caso di furti del dispositivo mobile 2 o richieste di pagamenti non volute. Ad esempio, l’utente potrebbe specificare un ricevere questo codice di sicurezza durante l’iscrizione presso l’operatore di pagamento 3. In questo caso, l’utente inserisce lo stesso codice di sicurezza per autorizzare il pagamento, e il codice viene inoltrato insieme al messaggio di acquisto all’esercente 1. In modo simile, l’esercente 1 invia tale codice insieme con la richiesta di addebito attraverso il sistema di gestione 4 all’operatore di pagamento 3, che verifica la correttezza del codice di sicurezza. In generale, tale codice di sicurezza potrebbe essere inviato anche in forma criptata, ad esempio utilizzando l’algoritmo MD5, AES o altri codici di criptazione simmetrici o asimmetrici.

Pertanto, nell’esempio considerato, l’utente 2 invia una richiesta di acquisto ad un esercente 1 per richiedere un prodotto o un servizio desiderato, e l’esercente 1 conferma l’acquisto tramite un messaggio di conferma. Di conseguenza, il dispositivo 2 deve conoscere l’indirizzo elettronico, quale ad esempio un indirizzo IP, un indirizzo e-mail, un indirizzo di un sito web o un altro indirizzo che permette di contattare l’esercente elettronicamente, o il numero telefonico a cui mandare la richiesta d’acquisto.

Ad esempio, tale problema viene tipicamente risolto tramite specifiche applicazioni. Ad esempio, ogni esercente 1 potrebbe sviluppare a tale scopo una specifica applicazione che conosce l’indirizzo elettronico o il numero telefonico dell’esercente 1. Da un lato, questo richiede che l’utente 2 debba scaricare anticipatamente le applicazioni sul suo cellulare e ogni esercente 1 à ̈ tenuto a sviluppare applicazioni per i principali sistemi operativi dei cellulari, quale ad esempio Symbian, iOS, Android, o un generica applicazione Java. Ogni utente deve scaricare per ogni esercente 1 una specifica applicazione.

Dall’altro lato, questo approccio migliora la sicurezza del sistema. Infatti, come menzionato in precedenza, il pagamento viene normalmente autorizzato tramite un codice di sicurezza. Tuttavia, spesso non à ̈ possibile criptare questo codice insieme ad un codice di transazione, ad esempio per permettere l’utilizzo di diversi dispositivi mobile. Pertanto, l’esercente riceve un codice di sicurezza (eventualmente anche criptato) che potenzialmente potrebbe essere riutilizzabile per altri pagamenti. Di conseguenza, esiste la necessità di evitare che soggetti non autorizzati possono ottenere accesso a questi codici di sicurezza. Tuttavia, proprio in questo contesto aiuta il fatto che l’utente debba scaricare l’applicazione sul suo dispositivo mobile, perché l’utente può verificare immediatamente l’attendibilità dell’esercente. Inoltre, moderni cellulari sono di solito configurati per permettere soltanto l’installazione di applicazioni certificate e pertanto l’esercente deve essere un soggetto attendibile.

In questo contesto, le domande di brevetto italiano TO2011A000575 e TO2011A000861, i cui contenuti sono qui incorporati per riferimento, descrivono altri possibili procedimenti per autorizzare pagamenti tramite un dispositivo mobile.

Ad esempio il documento TO2011A000575 descrive una soluzione, in cui il dispositivo mobile 2 può selezionare il prodotto o servizio da acquistare tramite un codice a barre monodimensionale o bidimensionale, quale ad esempio un codice QR (Quick Response code) o un Data Matrix. In particolare, il dispositivo mobile 2 rileva, ad esempio tramite una telecamera, un codice a barre che identifica un esercente 1 e un prodotto/servizio venduto. Successivamente, per verificare l’attendibilità dei codici rilevati, il dispositivo mobile 2 invia il codice dell’esercente 1 e del prodotto rilevato al sistema di gestione 4 per verificare l’esistenza e/o validità del venditore e del prodotto oggetto della vendita. In particolare, il sistema di gestione 4 restituisce alcuni dati di controllo che permettono di identificare l’esercente e il prodotto/servizio venduto e l’indirizzo elettronico, quale ad esempio un indirizzo IP o un numero telefonico, a cui mandare la richiesta di acquisto. Di conseguenza, il dispositivo mobile e/o l’utente sono in grado di verificare la correttezza dell’offerta di vendita e autorizzare il pagamento soltanto se il prodotto offerto corrisponda a quello desiderato.

Invece il documento TO2011A000861 descrive una soluzione “web-based†, in cui l’utente 2 seleziona i prodotti desiderati su un sito internet di un esercente 1. Successivamente, per avviare il pagamento ed essere riconosciuto come cliente iscritto al servizio di pagamento, l’utente 2 inserisce in un apposito campo non il suo codice di sicurezza ma un codice che identifica l’utente 2, quale ad esempio il suo numero telefonico o un altro codice associato all’utente 2 durante la registrazione all’servizio di vendita. Di conseguenza, l’esercente 1 o l’utente 2 invia al sistema di gestione 4 una richiesta di pagamento contenente il codice dell’esercente 1 e il codice dell’utente 2, ovvero il sistema di gestione 4 riceve una richiesta di pagamento contenente il codice esercente e il codice utente. Una volta verificata la validità dei codici, il sistema di gestione 4 genera un messaggio elettronico, preferibilmente un messaggio del servizio SMS che contiene un link univoco ad un sito gestito dal sistema di gestione 4. Ad esempio, in una forma di attuazione, il sistema di gestione trasmette all’utente 2 un messaggio del servizio SMS contenente un link ad un sito web, in cui il link comprende un codice univoco. Pertanto, l’utente 2 riceve tale messaggio contenente il link al sito del sistema di gestione e aprendo il link indicato nel messaggio elettronico, il browser del dispositivo mobile 2 apre una pagina web che contiene il riepilogo della spesa nella quale viene richiesto l'inserimento del codice di sicurezza. Inoltre, aprendo il link indicato nel messaggio del servizio SMS l’utente 2 autentica implicatamene il numero telefonico del dispositivo mobile 2. Di conseguenza, il sistema di gestione 4 riceve dall’utente 2 una richiesta di accesso al sito web identificato tramite il link inviato all’utente 2, e verifica se la richiesta di accesso comprenda il codice univoco. Inoltre, nel caso in cui la richiesta di accesso comprenda il codice univoco, il sistema di gestione 4 trasmette all’utente una pagine web che contiene il riepilogo del pagamento da autorizzare e un campo per l’inserimento del codice di sicurezza dell’utente. L’utente 2 autorizza quindi l’acquisto inserendo il suo codice di sicurezza. Di conseguenza, il sistema di gestione 4 riceve tramite la pagina web il codice di sicurezza dell’utente 2 e può trasmette la richiesta di autorizzazione del pagamento all’operatore di pagamento dell’utente 2. Di conseguenza, in questa soluzione, l’esercente non ottiene accesso al codice di sicurezza dell’utente ma riceve dal sistema di gestione soltanto un messaggio che conferma o nega il pagamento.

Le soluzioni descritte in precedenza permettono quindi di acquistare in modo semplice prodotti o servizi offerti da una pluralità di esercenti. Sostanzialmente, le soluzioni descritte in precedenza hanno in comune che tipicamente uno dei messaggi che vengono scambiati tra il dispositivo mobile 2 e l’esercente 1 e/o il sistema di gestione 4 à ̈ un messaggio SMS che pertanto contiene il numero del dispositivo mobile come mittente o come destinatario. Pertanto, soltanto l’utente che à ̈ in possesso del dispositivo mobile 2 può effettuare un pagamento.

Tuttavia, l’inventore ha osservato che le soluzioni descritte in precedenza non risolvono in modo sodisfacente la vendita e convalida di biglietti, quali ad esempio biglietti per il trasporto pubblico, oltre a non risolvere i problemi relativi a frodi, evasione e controllo sociale. Ad esempio, spesso i biglietti per il trasporto pubblico hanno solo validità per un’unica corsa o per una certa zona dell’intera rete. Ad esempio, tradizionalmente, questo problema viene affrontato tramite una operazione di convalida del biglietto, ad esempio mediante una macchina montata in un posto noto, ad esempio all’interno di una stazione della metropolitana o direttamente a bordo di un veicolo.

Scopo e sintesi dell’invenzione

Lo scopo dell’invenzione à ̈ quello di realizzare un’architettura che affronta le problematiche legate alla vendita e validazione di biglietti, in particole biglietti per il trasporto.

Al fine di raggiungere il suddetto scopo, l’invenzione ha per oggetto un procedimento per acquistare e validare un biglietto elettronico tramite un dispositivo mobile dotato delle caratteristiche specificate nell’annessa rivendicazione 1. L’invenzione riguarda anche un relativo dispositivo mobile e sistema di pagamento, nonché un prodotto informatico, caricabile nella memoria di almeno un elaboratore e comprendente parti di codice software suscettibili di realizzare le fasi del procedimento quando il prodotto à ̈ eseguito su almeno un elaboratore. Così come qui utilizzato, il riferimento ad un tale prodotto informatico à ̈ inteso essere equivalente al riferimento ad un mezzo leggibile da elaboratore contenente istruzioni per il controllo del sistema di elaborazione per coordinare l’attuazione del procedimento secondo l'invenzione. Il riferimento ad "almeno un elaboratore" à ̈ evidentemente inteso a mettere in luce la possibilità che la presente invenzione sia attuata in forma modulare e/o distribuita.

Ulteriori caratteristiche vantaggiose dell’invenzione formano oggetto delle annesse rivendicazioni dipendenti.

Tutte le rivendicazioni annesse vanno intese come parte integrante dell’insegnamento tecnico qui fornito in relazione all’invenzione.

Come menzionato in precedenza, la presente descrizione fornisce soluzioni che affrontano le problematiche legate alla vendita e validazione di titoli che autorizzano l’accesso ad un bene/servizio.

In varie forme di attuazione tale problema viene risolto sostanzialmente tramite un dispositivo mobile, ad esempio mediante una applicazione installata sul dispositivo mobile, che gestisce sia l’acquisto sia la validazione del titolo di accesso/legittimazione a un bene/servizio.

In varie forme di attuazione, il dispositivo mobile permette di selezionare almeno un titolo da un elenco di titoli acquistabili da un esercente. In varie forme di attuazione, il dispositivo mobile può anche gestire una pluralità di esercenti, e l’elenco di esercenti e l’elenco di titoli acquistabili potrebbero essere aggiornabili.

In varie forme di attuazione, una volta selezionato almeno un titolo, il dispositivo mobile invia un messaggio elettronico contenente una richiesta di acquisto del titolo ad un server dell’esercente.

In varie forme di attuazione, il server dell’esercente elabora la richiesta di acquisto e, nel caso in cui la richiesta di pagamento viene confermato, il server dell’esercente invia al dispositivo mobile un messaggio elettronico contenente una conferma di acquisto. Ad esempio, come descritto in precedenza, per effettuare il pagamento, il server dell’esercente potrebbe calcolare l’importo totale dei titoli richiesti e inviare una richiesta di pagamento ad un sistema di gestione del pagamento che a sua volta inoltra la richiesta di pagamento all’operatore di pagamento dell’utente. Nel caso in cui tali importi sono bassi potrebbe anche non essere previsto l’inserimento di un codice di sicurezza da parte dell’utente. Pertanto, nel caso in cui il pagamento viene approvato, il dispositivo mobile riceve dal server dell’esercente un messaggio elettronico contenente una conferma dell’acquisto. Ad esempio, in varie forme di attuazione, una volta ricevuto la conferma del acquisto, il dispositivo salva i titoli acquistati in un elenco di titoli non convalidati.

Successivamente, il dispositivo mobile permette di validare un titolo selezionando un titolo non convalidato tra i titoli acquistati. Ad esempio, il dispositivo mobile potrebbe mostrare a tale scopo i titoli che sono memorizzati nell’elenco di titoli non convalidati.

In varie forme di attuazione, l’operazione di validazione viene anche segnalata al server dell’esercente, ad esempio per verificare la disponibilità del titolo. Ad esempio, il dispositivo mobile può inviare a tale scopo un messaggio elettronico contenente una richiesta di convalida al server dell’esercente che contiene informazioni che identificano il titolo da convalidare, e il server dell’esercente, una volta verificata la disponibilità del titolo per l’utente, può inviare un messaggio elettronico contenente un messaggio di conferma della convalida. Ad esempio, tale messaggio di conferma può comprende un codice univoco che identifica il titolo convalidato.

In varie forme di attuazione vengono rilevati informazioni che permettono di identificare la posizione del utente al momento dell’convalidazione. Ad esempio, il dispositivo mobile può rilevare la posizione dell’utente mediante un ricevitore GPS, o può rilevare un identificatore di un trasmettitore senza fili installato in un posto noto, o preferibilmente può rilevare mediante la telecamera del dispositivo mobile un codice a barre bidimensionale che identifica un posto noto, quale ad esempio una stazione della metropolitana o un mezzo di trasporto. Preferibilmente, tale posizione o identificatore che indica un posto noto viene anche inviato al server dell’esercente insieme con la richiesta di convalida.

In varie forme di attuazione, una volta un titolo à ̈ stato convalidato, tale titolo viene rimosso dall’elenco di titoli non convalidati e salvato in un elenco di titoli convalidati. Inoltre, una volta un titolo à ̈ stato convalidato, può essere riprodotto un effetto visivo e/o acustico.

Breve descrizione dei disegni

La presente invenzione verrà ora descritta dettagliatamente con riferimento ai disegni allegati, dati a puro titolo di esempio non limitativo, in cui:

- le Figure 1 e 2 sono stata descritte già in precedenza;

- la Figura 3 à ̈ un schema a blocchi che illustra l’architettura generale di un sistema di pagamento secondo la presente descrizione;

- le Figure 4 a 6 illustrano varie dettagli del funzionamento di un dispositivo mobile che viene utilizzato nel sistema della Figura 3.

Descrizione particolareggiata di forme di attuazione Nella seguente descrizione sono illustrati vari dettagli specifici finalizzati ad un’approfondita comprensione delle forme di attuazione. Le forme di attuazione possono essere realizzate senza uno o più dei dettagli specifici, o con altri metodi, componenti, materiali ecc. In altri casi, strutture, materiali o operazioni noti non sono mostrati o descritti in dettaglio per evitare di rendere oscuri vari aspetti delle forme di attuazione.

Il riferimento ad “una forma di attuazione†nell’ambito di questa descrizione sta ad indicare che una particolare configurazione, struttura o caratteristica descritta in relazione alla forma di attuazione à ̈ compresa in almeno una forma di attuazione. Quindi, frasi come “in una forma di attuazione†, eventualmente presenti in diversi luoghi di questa descrizione, non sono necessariamente riferite alla stessa forma di attuazione. Inoltre, particolari conformazioni, strutture o caratteristiche possono essere combinati in un modo adeguato in una o più forme di attuazione.

I riferimenti qui utilizzati sono soltanto per comodità e non definiscono dunque l’ambito di tutela o la portata delle forme di attuazione.

Come menzionato in precedenza, la presente descrizione fornisce soluzioni che affrontano le problematiche legate alla vendita e validazione di biglietti o altri titoli che autorizzano l’accesso ad un bene/servizio.

La Figura 3 mostra una possibile forma di attuazione di un’architettura secondo la presente descrizione.

Nella forma di attuazione considerata, il dispositivo mobile 20 ha installato una applicazione 20 che permette di acquistare un biglietto elettronico, ovvero un titolo di accesso/legittimazione a un bene/servizio.

Sostanzialmente, tale applicazione permette di gestire l’acquisto del titolo e la convalida del titolo.

La Figura 4 mostra i principali passi che vengono gestiti tramite l’applicazione 20.

Dopo un passo iniziale 2000, l’applicazione 20 mostra ad un passo 2002 una pagina iniziale che permette di selezione il modo di funzionamento della applicazione 20.

Ad esempio, la Figura 5a mostra una possibile schermata 24 della pagina iniziale che comprende tre possibili tasti 2402, 2404 e 2406 con rispettivi scritture “BUY†, “VALID†e “EXIT†. Ad esempio, nella forma di attuazione considerata, premendo il tasto 2402 l’utente può selezionare una modalità di acquisto di un nuovo titolo e premendo il tasto 2404 l’utente può selezionare una modalità di convalida di un titolo acquisito in precedenza.

Invece, il tasto 2406 chiude l’applicazione e pertanto non verrà descritto esplicitamente.

Pertanto, ad un passo di verifica 2004, l’applicazione 20 può verificare la scelta dell’utente.

Ad esempio, nel caso in cui l’utente vuole acquistare un nuovo titolo (uscita “BUY†del passo di verifica 2004), l’applicazione mostra ad un passo 2008 l’elenco di titoli che possono acquisiti.

Ad esempio, la Figura 5b mostra una possibile schermata 24 della pagina che permette di selezionare diversi titoli. Ad esempio, nella forma di attuazione considerata, la schermata può comprendere un titolo 2408 che mostra il nome (“NAME†) e/o il logo dell’esercente. Inoltre, la pagina può comprendere una pluralità di tasti 2410, 2412 e 2414 che identifico i rispettivi titoli acquistabili, ad esempio “TICKET 1†, “TICKET 2†e “TICKET 3†,e che permettono di selezionare uno dei titolo. Ad esempio i tasti 2410, 2412 e 2414 possono corrispondere rispettivamente ad un biglietto unico, un biglietto settimanale, un biglietto mensile. Inv arie forme di attuazione, la pagina può anche comprendere un tasto 2414 che torna alla schermata precedente.

In varie forme di attuazione, l’elenco di titoli acquistabili à ̈ memorizzato localmente, ovvero direttamente nella applicazione 20. Tuttavia, tale elenco può essere aggiornabile, ad esempio scaricando queste informazioni attraverso una connessione dati da un server remoto, quale ad esempio un server dell’esercente 1 o un server del sistema di gestione 4. Invece in altre forme di attuazione, l’elenco à ̈ soltanto memorizzato su un server remoto, e l’applicazione accede a tale server remoto.

In generale, l’applicazione 20 può anche essere in grado di gestire una pluralità di esercenti 1. Per questo motivo, l’applicazione può selezionare a un passo 2006 un esercente 1, e l’applicazione 20 può mostrare al passo 2008 soltanto i titoli di tale esercente.

Ad esempio, in varie forme di attuazione, l’applicazione mostra al passo 2006 un elenco di esercenti e l’utente può selezionare uno degli esercenti. Ad esempio, sostanzialmente la stessa schermata mostrata nella Figura 5b potrebbe essere utilizzato anche per la selezione del o degli esercenti.

In generale, l’applicazione potrebbe anche selezionare automaticamente il o gli esercenti che sono più appropriati. Ad esempio, l’applicazione potrebbe rilevare la posizione dell’utente, ad esempio utilizzando un ricevitore GPS o basandosi sulle identificazioni delle stazioni base della rete radiomobile. Pertanto, conoscendo la posizione dell’utente, l’applicazione potrebbe seleziona direttamente l’esercente responsabile per la rispettiva area o mostrare solo l’elenco degli esercenti che servono la rispettiva area. In generale, anche l’elenco degli esercenti 1 e/o i rispettivi dati di contatti che servono per avviare il pagamento potrebbero essere aggiornabili, ad esempio scaricando tale elenco da un server del sistema di gestione 4. Infatti, questa soluzione permette che nuovi esercenti possono essere aggiunti anche successivamente e garantisce che soltanto esercenti attendibili possono offrire i loro prodotti/servizi.

Pertanto, l’utente può selezionare ad un passo 2010 attraverso l’applicazione 20 uno o eventualmente anche più titoli che desidera di acquistare.

Infine, l’utente acquisisce ad un passo 2016i titoli selezionati. Ad esempio, tale pagamento potrebbe essere gestito direttamente tramite l’applicazione 20 o l’applicazione potrebbe comportarsi come un browser web che permette di effettuare il pagamento su un sito remoto dell’esercente.

Ad esempio, in varie forme di attuazione, l’applicazione potrebbe inviare la richiesta di pagamento direttamente all’esercente 1 seguendo sostanzialmente il diagramma di flusso mostrato nella Figura 6 del documento TO2011A000575. Pertanto, la relativa descrizione del documento TO2011A000575 non verrà ripetuta qui per semplicità, ma si intende incorporato qui per riferimento.

Invece, in altre forme di attuazione, l’acquisto potrebbe essere web-based e l’applicazione potrebbe funzionare come un semplice browser web che segue il funzionamento descritto nel documento TO2011A000861.

In generale, una volta completato l’acquisto, l’applicazione 20 riceve ad un passo 2018 dall’esercente (o eventualmente dal sistema di gestione 4) un messaggio che conferma o nega l’acquisto (ad esempio i messaggi “ERR1..ERR5†e “OK1†mostrati nella Figura 6 del documento TO2011A000575).

In varie forme di attuazione, l’applicazione 20 memorizza al passo 2020 i titoli acquisiti in un elenco di titoli non convalidati TNV, la cui funzione verrà descritto in seguito, e torna alla schermata iniziale, ovvero al passo 2002. Ad esempio, anche in questo caso potrebbe essere utilizzato sostanzialmente la schermata mostrata nella Figura 5b.

Invece, nel caso in cui l’utente vuole convalidare un titolo acquisito in precedenza (uscita “VALID†del passo di verifica 2004), l’applicazione mostra ad un passo 2022 l’elenco di titoli che l’utente ha acquisito in precedenza e che non sono ancora convalidati.

Ad esempio, l’applicazione potrebbe mostrare a tale scopo i titoli che sono stati memorizzati al passo 2020 memorizzati nell’elenco di titoli non convalidati TNV.

Tuttavia, come spiegato in precedenza, la memorizzazione in locale à ̈ soltanto opzionale e tale elenco potrebbe essere memorizzato solo remoto, ad esempio su un server dell’esercente 1. In questo caso, l’applicazione 20 potrebbe collegarsi al server dell’esercente, autorizzandosi ad esempio tramite un codice di identificazione dell’utente e/o della applicazione 20, e scaricare tale elenco di titoli non convalidati. Tuttavia, in generale à ̈ preferibile che l’elenco di titoli non convalidati e l’elenco dei titoli convalidati siano memorizzati sia nell’applicazione 20 sia nel server dell’esercente.

Ad un passo 2024, l’utente può selezionare un titolo dall’elenco mostrato al passo 2022, ovvero l’applicazione 20 rileva la selezione di uno dei titoli dell’elenco di titoli non convalidati.

Una volta selezionato un titolo dell’elenco di titoli non convalidati, l’applicazione convalida tale titolo ad un passo 2026.

Come spiegato in precedenza, l’inventore ha osservato che tale operazione di convalida dovrebbe essere legata alla posizione attuale dell’utente.

Per questo motivo, l’applicazione può rilevare ad un passo 2028 informazioni che permettono di identificare la posizione dell’utente al momento della convalida del titolo. Ad esempio, in una forma di attuazione, l’applicazione 20 rileva la posizione dell’utente mediante un ricevitore GPS.

In generale, l’applicazione potrebbe anche rilevare soltanto un codice che identifica la posizione attuale dell’utente. Ad esempio, tale codice potrebbe corrispondere all’identificazione della stazione base della rete radiomobile a cui à ̈ associato il dispositivo mobile, o un identificatore di un altro trasmettitore senza fili installato in un posto noto, quale ad esempio un trasmettitore WiFi, RF-ID (Radio Frequency IDentification) o Bluetooth che à ̈ installato nella stazione della metropolitano o a bordo di un pullman o altro mezzo di trasporto.

Invece, in una forma di attuazione attualmente preferita, tale codice à ̈ memorizzato all’interno di un codice a barre bidimensionale 100, quale ad esempio un codice QR o una Datamatrix.

Ad esempio, come mostrato anche nella Figura 3, in una forma di attuazione, un codice a barre 100 à ̈ fissato in un posto conosciuto 10, quale ad esempio all’ingresso di una stazione della metropolitano o a bordo di un pullman, ad esempio vicino alla porto d’ingresso. In questo caso, l’applicazione si collega ad una telecamere 22 del dispositivo mobile 2 ed elaborare l’immagine per rilevare un codice a barre. Ad esempio, una volta rilevato un codice a barre, l’applicazione può elabora anche il codice a barre à ̈ determina il codice che identifica la posizione. In particolare, il codice può identificare univocamente una posizione, ma anche solo un’area, o identificare un numero del mezzo di trasporto o il codice della linea. Infatti, anche una pluralità di identici codice a barre potrebbero essere installati nello stesso luogo, ad esempio nello stesso pullman, o alla fermata del pullman.

Pertanto, una volta rilevato la posizione dell’utente, o il codice che identifica la posizione dell’utente, l’applicazione 20 convalida il titolo.

Ad esempio, l’applicazione può inviare ad un passo 2030 un messaggio al server dell’esercente 1, segnalando il fatto che un titolo à ̈ stato validato. Successivamente, server dell’esercente 1 elabora il messaggio e conferma la convalida inviando un messaggio di conferma. Preferibilmente, l’applicazione 20 inviare al passo 2030 anche la posizione e/o il codice univoco che identifica la posizione dell’utente al server dell’esercente 1.

Pertanto, ad un passo 2032, l’applicazione 20 può ricevere il messaggio della conferma di convalida dal server dell’esercente 1. Ad esempio, il messaggio di conferma può essere un messaggio SMS e/o il messaggio può contenere un codice univoco che identifica il titolo convalidato. Ad esempio, tale messaggio di conferma della convalida potrebbe essere mostrato in caso di controlli.

In varie forme di attuazione, nel caso in cui l’elenco di titoli non convalidati TNV à ̈ memorizzato nell’applicazione, l’applicazione 20 può identificare il titolo come convalidato, ad esempio rimuovendo il titolo dall’elenco di titoli non convalidati TVC e memorizzare il titolo convalidato in un elenco di titoli convalidati TV. L’applicazione può anche memorizzare la posizione e/o il codice univoco che identifica la posizione dell’utente in tale elenco di titoli convalidati. Inoltre, l’applicazione potrebbe anche salvare il messaggio di conferma di convalida in tale elenco TV e associarlo al rispettivo titolo convalidato. Ad esempio, tale elenco di titoli convalidato potrebbe essere mostrato in caso di controlli.

Infine, l’applicazione 20 può informare l’utente dell’avvenuta convalida del titolo, ad esempio riproducendo un effetto visivo e/o acustico al passo 2036, e tornare alla schermata iniziale, ovvero al passo 2002. Ad esempio la riproduzione di un effetto acustico à ̈ particolarmente utile per evidenziare agli altri utenti l’effettiva convalida di un titolo di viaggio valido ad innescare così meccanismi di controllo sociale.

Pertanto, in generale l’acquisto di un titolo viene avviato attraverso l’applicazione 20 installata sul dispositivo mobile 2 dell’utente (passi 2006-2016). Invece, il server dell’esercente 1 invia un messaggio che indica l’avvenuto acquisto del titolo (passo 2018) e registra le informazioni del titolo, ad esempio in una banca dati. Preferibilmente anche l’applicazione 2 registra in parallelo i titoli acquisiti in un elenco di titoli non convalidati TNV (passo 2020).

Successivamente, l’utente può convalidare un titolo non convalidato (passi 2022-2026). Preferibilmente, l’applicazione 20 rileva la posizione dell’utente e invia anche un messaggio di convalida di un titolo all’esercente 1 (passi 2028-2030). Pertanto, il server dell’esercente 1 riceve un messaggio, ad esempio tramite un flusso dati proveniente dall’applicazione 2, che indica la richiesta di convalida di un dato titolo, identificato ad esempio tramite un codice che identifica l’utente e un codice che identifica il tipo del titolo, o un codice univoco associato con il titolo al momento del acquisito.

Preferibilmente, il server dell’esercente 1 riceve anche informazioni che identificano la posizione dell’utente, ad esempio il codice a barre bidimensionali finalizzato alla validazione. Pertanto, il server dell’esercente 1 può ricevere una pluralità di informazioni, quali ad esempio il codice identificativo del titolo di accesso/legittimazione, il codice memorizzato all’interno del codice a barre bidimensionale che indica un mezzo, una linea o un luogo oltre che le coordinate GPS e altre informazioni disponibili. Il server dell’esercente 1 può elaborare queste informazioni, ad esempio verificando la presenza del titolo nel elenco di titoli non convalidati e, se disponibile, segnalarlo come convalidato e invia un messaggio di conferma, quale ad esempio un SMS o flusso dati, al dispositivo mobile 2 (passo 2032). Tale messaggio può anche contenere un codice che indentifica in modo univoco il titolo convalidato e che pertanto non à ̈ riutilizzabile. Tale codice univoco può avere anche solo una validità temporale.

In seguito verrà ora descritto un possibile uso delle soluzione descritte in precedenza all’esempio di un acquisto di un biglietto dell’autobus.

Inizialmente, l’utente apre l’applicazione 20 per selezionare un titolo da acquistare (passi 2006-2010). In questo contesto, l’applicazione potrebbe rilevare la posizione dell’utente e mostrare solo i titoli di viaggio acquistabili in quella determinata area geografica per una determinata azienda di trasporto pubblico locale.

Successivamente, l’utente acquista il titolo di suo interesse e il server dell’esercente 1 conferma l’acquisto inviando la ricevuta di acquisto del titolo alla applicazione 20 che memorizza la conferma nell’elenco di titoli non convalidati (passi 2016-2020).

In un secondo momento, l’utente sale sull’autobus e seleziona il titolo di viaggio da validare dall’elenco di titoli non convalidati e clicca su un tasto per convalidare il titolo (passi 2022-2024). Per convalidare il titolo, l’applicazione si configura come lettore di codici a barre bidimensionali ed eventualmente effettua anche una geolocalizzazione per rilevare la posizione esatta del utente (passo 2028). L’utente legge il codice a barre bidimensionali di validazione che dovrebbe essere disponibile in posizioni prestabilite e facilmente accessibili, come ad esempio, all’interno dell’autobus. Una volta rilevata il codice a barre, l’applicazione 20 invia un flusso dati al server dell’esercente 1 contenente l’identificazione del titolo da validare, il codice memorizzato nel codice a barre bidimensionale, ad esempio il codice del autobus su cui si à ̈ salito, eventualmente le informazioni della geo-localizzazione ed altre eventuali informazioni richieste dall’azienda di trasporto pubblico locale (passo 2030). Il server dell’esercente, a sua volta verifica la presenza delle informazioni relative all’identificazione del titolo e se disponibile, valida il titolo dell’utente. Infine, il server dell’esercente invia un messaggio, ad esempio un SMS o un flusso dati, che contiene il titolo di accesso debitamente validato all’utente eventualmente anche in termini di validità temporale, quale ad esempio un codice univoco. A sua volta, il dispositivo mobile riceve il messaggio con il titolo validato da poter mostrare all’eventuale controllore in caso di controllo passo (2034-2034).

La Figura 6 illustra una forma di attuazione che comprende anche una modalità di rivalidazione di un titolo. Pertanto, le modalità di acquisto (“BUY†) e di validazione (“VALID†) non verranno ripetute ma si applica il funzionamento descritto con riferimento alla Figura 4. Ad esempio, la modalità di rivalidazione può essere utile nel caso in qui l’utente deve cambiare il mezzo di trasporto e dovrebbe verificare il fatto che il titolo à ̈ ancora valido.

Ad esempio, in questo caso, la schermata mostrato al passo 2002 può comprendere un ulteriore tasto 2418, ad esempio con la scrittura “CHECK†, che permette di verificare la validità di un titolo.

Pertanto, nel caso in cui l’utente vuole rivalidare un titolo che à ̈ stato convalidato in precedenza (uscita “CHECK†del passo di verifica 2004), l’applicazione può cercare automaticamente l’ultimo titolo convalidato. Ad esempio, nel caso in cui l’elenco dei titoli convalidati sia memorizzato anche localmente, l’applicazione può reperire questo titolo dall’elenco TV, altrimenti l’applicazione 20 può contattore il server dell’esercente 1 à ̈ richiedere le informazioni sull’ultimo titolo convalidato, eventualmente autorizzandosi tramite un codice di identificazione dell’utente e/o della applicazione.

Successivamente, l’applicazione 20 può rivalidare il titolo ad un passo 2042 seguendo sostanzialmente i passi che vengono eseguito per la validazione di un titolo non convalidato.

Ad esempio, anche in questo caso, l’applicazione può rilevare ad un passo 2044 informazioni che permettono di identificare la posizione dell’utente al momento della rivalida del titolo. Ad esempio, l’applicazione può collegarsi alla telecamera 22 del dispositivo mobile 2 ed elaborare l’immagine per rilevare un codice a barre che identifica, ad esempio, il mezzo di trasporto.

Successivamente, l’applicazione può inviare ad un passo 2046 un messaggio al server dell’esercente 1, segnalando il fatto che un titolo deve essere rivalidato e il server dell’esercente 1 può elaborare il messaggio e conferma la rivalida inviando un messaggio che conferma o nega la rivalidazione. Ad esempio, l’esercente può verificare se il titolo continua ad avere caratteristiche di validità, come ad esempio si trova ancora all’interno del periodo di validità temporale. Preferibilmente, l’applicazione 20 invia al passo 2046 anche la posizione e/o il codice univoco che identifica la posizione dell’utente al server dell’esercente 1. Pertanto, ad un passo 2048, l’applicazione 20 può ricevere il messaggio della conferma di rivalida dal server dell’esercente 1. L’applicazione 20 può segnalare ad un passo 2050 il risultato della rivalidazione anche all’utente, ad esempio riproducendo effetti visivi e/o acustici che sono diversi per i casi di conferma e di rifiuto della rivalidazione.

Infine, l’applicazione 20 può tornare alla schermata iniziale, ovvero al passo 2002.

Naturalmente, fermo restando il principio dell’invenzione, i particolari di costruzione e le forme di realizzazione potranno essere ampiamente variati rispetto a quanto descritto ed illustrato a puro titolo di esempio, senza per questo uscire dall'ambito della presente invenzione, così come definito dalle rivendicazioni che seguono.

Claims (11)

1. RIVENDICAZIONI 1. Procedimento per acquistare e validare un biglietto elettronico, ovvero un titolo di accesso a un bene/servizio, tramite un dispositivo mobile (2) comprendente le fasi di: - selezionare (2006-2010) almeno un titolo da un elenco di titoli acquistabili da un esercente (1); - inviare (2016) un messaggio elettronico contenente una richiesta di acquisto di detto almeno un titolo ad un server di detto esercente (1); - ricevere (2018) da detto server di detto esercente (1) un messaggio elettronico contenente una conferma dell’acquisto di detto almeno un titolo; - selezionare (2022-2024) un titolo non convalidato tra i titoli acquistati; e - convalidare (2026) detto titolo non convalidato.
2. 2. Procedimento secondo la rivendicazione 1, comprendente gestire (2020) in una memoria di detto dispositivo mobile (2) un elenco di titoli non convalidati (TNV) ed un elenco di titoli convalidati (TV); in cui detto almeno un titolo acquistato viene salvato in detto elenco di titoli non convalidati (TNV); ed in cui detto convalidare (2026) detto titolo non convalidato comprende rimuovere (2034) il rispettivo titolo da detto elenco di titoli non convalidati (TNV) e salvare il rispettivo titolo nel elenco di titoli convalidati (TV).
3. 3. Procedimento secondo la rivendicazione 2, in cui detto selezionare (2022-2024) un titolo non convalidato tra i titoli acquistati comprende visualizzare (2022) i titoli che sono salvati in detto elenco di titoli non convalidati (TNV).
4. 4. Procedimento secondo una delle precedenti rivendicazioni, in cui detto convalidare (2026) un titolo non convalidato comprende rilevare (2028) informazioni che permettono di identificare la posizione del dispositivo mobile.
5. 5. Procedimento secondo la rivendicazioni 4, in cui detto rilevare (2028) informazioni che permettono di identificare la posizione del dispositivo mobile comprende almeno uno fra: - rilevare la posizione del dispositivo mobile mediante un ricevitore GPS; - rilevare un identificatore di un trasmettitore senza fili installato in un posto noto, quale ad esempio l’identificazione della stazione base della rete radiomobile a cui à ̈ associato il dispositivo mobile, o l’identificatore di un trasmettitore WiFi, RF-ID o Bluetooth; e/o - rilevare tramite una telecamera (22) del dispositivo mobile (2) un codice a barre bidimensionale (100), quale ad esempio un codice QR o una Datamatrix, in cui il codice identificato tramite detto codice a barre bidimensionale (100) identifica un posto noto.
6. 6. Procedimento secondo una delle precedenti rivendicazioni, in cui detto convalidare (2026) un titolo non convalidato comprende: - inviare (2030) un messaggio elettronico contenente una richiesta di convalida a detto server di detto esercente (1) che contiene informazioni che identificano il titolo da convalidare; - ricevere (2032) da detto server di detto esercente (1) un messaggio elettronico contenente un messaggio di conferma della convalida.
7. 7. Procedimento secondo la rivendicazioni 6, in cui detto messaggio elettronico contenente un messaggio di conferma della convalida comprende un codice univoco che identifica il titolo convalidato.
8. 8. Procedimento secondo una delle precedenti rivendicazioni, comprendente, nel caso in cui un titolo sia stato convalidato, riprodurre (2036) un effetto visivo e/o acustico.
9. 9. Un dispositivo mobile, caratterizzato dal fatto che detto dispositivo mobile (2) Ã ̈ configurato per implementare il procedimento secondo una delle rivendicazioni 1 a 8.
10. 10. Un sistema di pagamento comprendente almeno un server di un esercente (1) e un dispositivo mobile secondo la rivendicazione 9.
11. 11. Prodotto informatico caricabile in una memoria di almeno un processore e comprende porzioni di codice software per implementare il procedimento secondo una delle rivendicazioni 1 a 8.