ITTO20120636A1 - Procedimento per il pagamento tramite un dispositivo mobile, relativo dispositivo mobile e prodotto informatico - Google Patents

Description

DESCRIZIONE dell’invenzione industriale dal titolo:

“Procedimento per il pagamento tramite un dispositivo mobile, relativo dispositivo mobile e prodotto informaticoâ€

TESTO DELLA DESCRIZIONE

Campo dell’invenzione

La presente invenzione riguarda le tecniche per l’acquisto e l’autorizzazione di pagamenti tramite dispositivi mobili, quali ad esempio cellulari.

L’invenzione à ̈ stata in particolare sviluppata al fine di migliorare la sicurezza e l’esperienza utente di tali pagamenti.

Descrizione della tecnica nota

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.

Inoltre, sarebbe opportuna un’architettura che permettesse la gestione di una pluralità di esercenti e una pluralità di operatori di pagamento.

Scopo e sintesi dell’invenzione

Lo scopo dell’invenzione à ̈ quello di realizzare un’architettura che risulti sicura, semplice, efficiente ed interoperabile per l’utilizzatore (acquirente), rivolta ad una molteplicità di utilizzatori con investimenti contenuti per gli esercenti (venditori) e conforme alle norme nazionali ed internazionali per le banche.

Al fine di raggiungere il suddetto scopo, l’invenzione ha per oggetto un procedimento per il pagamento tramite un dispositivo mobile dotato delle caratteristiche specificate nell’annessa rivendicazione 1. L’invenzione riguarda anche il relativo dispositivo mobile, 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, lo scopo dell’invenzione à ̈ quello di realizzare un’architettura che risulti sicura, semplice, efficiente ed interoperabile. In varie forme di attuazione, l’esercente può verificare l’avvenuto pagamento direttamente tramite il dispositivo mobile dell’utente.

Ad esempio, in varie forme di attuazione, l’utente invia tramite il suo dispositivo mobile un messaggio elettronico che autorizza il pagamento di almeno un prodotto e/o servizio. In particolare tale messaggio viene inviato ad un sistema di pagamento che gestisce i pagamenti dell’esercente che offre i prodotti e può comprendere, ad esempio, un sistema informatico dell’esercente, un sistema informatico dell’istituto di pagamento dell’utente e un sistema di gestione che gestisce i pagamenti tra più esercenti e più istituti di pagamento.

In varie forme di attuazione, l’utente, ossia il dispositivo mobile, riceve dal sistema di pagamento un messaggio elettronico di conferma indicativo del risultato dell’autorizzazione del pagamento, ossia un messaggio che approva o nega l’autorizzazione.

In varie forme di attuazione, nel caso in cui il messaggio à ̈ un messaggio di approvazione, il dispositivo mobile genera e visualizza una schermata che contiene un riepilogo dei prodotti e/o servizi pagati.

In varie forme di attuazione, l’esercente può controllare il riepilogo, convalidare l’acquisto e erogare il prodotto e/o servizio.

Di conseguenza, in varie forme di attuazione, il dispositivo mobile à ̈ configurato per rilevare un evento che convalida il pagamento dei prodotti e/o servizi, quale ad esempio l’azionamento di un tasto di convalida e/o il movimento di un dito sullo schermo del dispositivo mobile in una direzione diagonale.

In seguito, il dispositivo mobile classifica il messaggio di approvazione come convalidato. Ad esempio, in varie forme di attuazione, il messaggio di conferma ricevuto dal sistema di pagamento viene inizialmente archiviato, ovvero salvato, in un primo registro di messaggi, e quando viene convalidato un messaggio di approvazione, tale messaggio viene archiviato, ovvero spostato, in un secondo registro di messaggi che possono essere visualizzati ma non più convalidati.

In varie forme di attuazione, per assicurare che il messaggio di approvazione à ̈ autentico, il dispositivo mobile visualizza e/o riproduce un elemento grafico, sonore e/o altri effetti visivi, quali ad esempio una parola, un numero, una sequenza alfanumerica, un’immagine, un suono e/o una sequenza video. Preferibilmente tale elemento viene visualizzato e/o riprodotto quando il pagamento viene convalidato.

Ad esempio, in varie forme di attuazioni, l’elemento viene ricevuto dal sistema di pagamento insieme al messaggio di approvazione.

Invece in altre forme di attuazioni, il dispositivo mobile ricevere dal sistema di pagamento, ad esempio insieme al messaggio di approvazione, un codice univoco che à ̈ associato allo specifico pagamento. In questo caso, quando viene convalidato il pagamento, il dispositivo mobile invia tale codice univoco al sistema di pagamento e ricevere soltanto in questo momento l’elemento da visualizzare e/o riprodurre.

Di conseguenza, conoscendo l’elemento che dovrebbe essere visualizzato e/o riprodotto, l’esercente à ̈ in grado di verificare la correttezza del pagamento direttamente sul dispositivo mobile dell’utente.

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:

- la Figura 1 à ̈ stata descritta già in precedenza; - le Figure 2 e 3 mostrano forme di attuazione di sistemi di pagamento secondo la presente invenzione;

- le Figure 4, 6, 7 e 8 sono diagrammi di flusso che illustrano dettagli dei sistemi di pagamento delle Figure 2 e 3; e

- la Figura 5 mostra un forma di attuazione di un’interfaccia d’utente per il pagamento tramite un dispositivo mobile.

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.

La Figura 2 mostra una forma di attuazione del sistema di pagamento secondo la presente invenzione.

Nella forma di attuazione considerata, il sistema comprende 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 forma di attuazione considerata, sono mostrati due esercenti 1a e 1b, e due operatori di pagamento 3a e 3b.

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, in varie forme di attuazione, 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).

Nella forma di attuazione considerata, 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.

In varie forme di attuazione, 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, nella forma di attuazione considerata, 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.

Nella forma di attuazione considerata, per identificare l’operatore di pagamento associato ad uno specifico dispositivo mobile o utente 2, il sistema di gestione 4 comprende una banca dati 40 che contiene dati che associano ad ogni dispositivo mobile o utente un rispettivo operatore di pagamento.

Di conseguenza, nella forma di attuazione considerata, il sistema di gestione 4 à ̈ configurato per ricevere 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, in una forma di attuazione, il dato che permette di identificare l’utente à ̈ 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 invia 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.

In una forma di attuazione à ̈ inoltre previsto che l’operatore di pagamento 3 invia 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 che contiene un riepilogo sulla somma addebitata e gli estremi dell’esercente che ha richiesto il pagamento.

Come menzionato in precedenza, in una forma di attuazione, il sistema di gestione 4 comprende una banca dati 40 che contiene dati che permettono di associare ai vari dispositivi mobili o utenti 2 i rispettivi operatori di pagamento 3.

In una forma di attuazione, tale associazione viene creata tramite un’iscrizione al servizio di pagamento. Ad esempio, in una forma di attuazione, tale iscrizione viene effettuata presso l’operatore di pagamento 3 che comunica i dati di iscrizione al sistema di gestione 4. Ad esempio, tale iscrizione potrebbe essere effettuata sotto una voce corrispondente all’interno di un servizio di internet banking, che associa uno specifico numero telefonico ad un conto corrente, una carta di credito o altri strumenti di pagamento.

Di conseguenza, le forme di attuazioni descritte in precedenza permettono di offrire prodotti di una pluralità di esercenti 1 ad una pluralità di utenti 2 tramite un semplice sistema di gestione centralizzato 4. In questo modo il sistema di pagamento à ̈ aperto e nuovi esercenti 1 o operatori di pagamenti 3 possono essere aggiunti facilmente.

In una forma di attuazione, per aumentare la sicurezza del sistema, à ̈ 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, in una forma di attuazione, l’utente riceve 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 una forma di attuazione à ̈ inoltre previsto che tale codice di sicurezza viene inviato in forma criptata, ad esempio utilizzando l’algoritmo MD5, AES o altri codici di criptazione simmetrici o asimmetrici.

In una forma di attuazione, per evitare che l’esercente 1 (o un’altra persona che ha intercettato la richiesta di pagamento) possa riutilizzare il codice di sicurezza per un altro addebito, ogni richiesta di pagamento ha un nuovo codice di transazione (ad esempio un numero consecutivo di richieste di acquisti) e il codice di sicurezza viene criptato insieme al codice di transazione. Pertanto, la sequenza di caratteri del codice criptato può variare per ogni transazione ed à ̈ utilizzabile soltanto una volta, e soltanto l’operatore di pagamento 3 à ̈ in grado di verificare la correttezza del codice di sicurezza.

Tuttavia, come menzionato in precedenza, à ̈ necessario che l’utente 2 invii una prima richiesta di acquisto ad un esercente 1 per richiedere un prodotto o un servizio desiderato.

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.

L’inventore ha osservato che tale problema potrebbe essere 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.

L’inventore ha osservato che i problemi sopra menzionati possono anche essere risolti tramite un’unica applicazione configurabile offerta ad esempio direttamente dal gestore del sistema di gestione 4. Tuttavia, come menzionato in precedenza, in questo caso à ̈ opportuno un meccanismo che permette di verificare l’attendibilità dell’esercente e del bene/servizio venduto.

La Figura 3 mostra una modifica del sistema secondo la Figura 2 che permette di utilizzare un’applicazione generica 20 sul dispositivo mobile 2.

Nella forma di attuazione considerata, l’esercente 1 applica ad un oggetto 10, quale ad esempio l’oggetto in vendita, un codice 100 che permette di identificare l’esercente e il prodotto/servizio offerto.

Invece, il dispositivo mobile 2 comprende un sensore 22 per rilevare tale codice identificativo per l’esercente 1.

In generale, il sensore 22 può essere qualsiasi sensore, quale ad esempio un sensore ottico, magnetico o meccanico. Tale sensore 22 può anche essere un ricetrasmettitore, quale ad esempio un ricetrasmettitore RF-ID (Radio Frequency IDentification) o Bluetooth configurato per rilevare un codice da un transponder o ricetrasmettitore applicato all’oggetto 10.

Ad esempio, in una forma di attuazione attualmente preferita, il codice 100 à ̈ un codice QR, ovvero un codice a barre bidimensionale, che à ̈ applicato ad una etichetta. In questo caso, il sensore 22 può essere una telecamera o fotocamera all’interno del dispositivo mobile 2 che inquadra l’etichetta per rilevare il codice QR.

Di conseguenza, il dispositivo 2 à ̈ in grado di rilevare tramite il sensore 22 il codice identificativo per l’esercente 1 ed anche un codice che identifica il prodotto/servizio.

Tale codice potrebbe quindi anche identificare direttamente l’indirizzo elettronico o numero telefonico dell’esercente 1 a cui inviare la richiesta di acquisto. Di conseguenza, l’utente 2 potrebbe mandare direttamente una richiesta di acquisto all’indirizzo o numero telefonico dell’esercente 1.

Tuttavia, qualsiasi codice applicato all’oggetto 10 potrebbe essere falsificato da un soggetto estraneo al sistema di pagamento. Pertanto, l’utente 2 potrebbe inviare una richiesta di acquisto comprendente eventualmente anche il suo codice di sicurezza ad un soggetto non autorizzato. Di conseguenza, tale soggetto non autorizzato potrebbe riutilizzare i dati trasmessi anche in maniera impropria, ad esempio per danneggiare l’utente.

In una forma di attuazione, per evitare questo problema, il codice 100 applicato all’oggetto 10 non viene utilizzato direttamente per inviare la richiesta di acquisto all’esercente 1, ma à ̈ previsto un ulteriore passaggio per verificare l’attendibilità del presunto esercente e del relativo prodotto/servizio venduto.

Ad esempio, in una forma di attuazione, il codice applicato all’oggetto 10 comprende un campo che identifica un’esercente e un campo che identifica l’oggetto venduto.

La Figura 4 mostra un diagramma di flusso che riassume le principali operazioni che vengono effettuate da un’applicazione 20 installata sul dispositivo mobile 2. Dopo un passo iniziale 2000, l’applicazione rileva ad un passo 2002 tramite la telecamera 22 del dispositivo mobile 2 il codice QR 100 applicato all’oggetto 10.

Ad un passo 2004, l’applicazione analizza il codice QR 100 à ̈ determina il codice identificavo per l’esercente ed il codice identificativo per il prodotto/servizio.

Ad un passo 2006, l’applicazione invia il codice dell’esercente ed il codice del prodotto/servizio al sistema di gestione 4. Ad esempio, a tale scopo il dispositivo mobile 2 può comprendere un ricetrasmettitore WiFi (Wireless Fidelity) e/o un modem UMTS (Universal Mobile Telecommunications System), HSPA (High-Speed Packet Access), o LTE (Long Term Evolution), e la comunicazione con il sistema di gestione 4 può essere effettuato tramite una connessione internet.

Il sistema di gestione 4 riceve quindi il codice dell’esercente ed il codice del prodotto/servizio. Successivamente, il sistema di gestione 4 confronta questi codici con una banca dati 42 che contiene informazioni sugli esercenti che sono ritenuti attendibili. Ad esempio, i dati in tale banca dati 42 possono essere creati tramite l’iscrizione e verifica degli esercenti. Nel caso in cui l’esercente sia stato ritenuto attendibile e il prodotto/servizio sia effettivamente vendibile, il sistema di gestione restituisce l’insegna dell’esercente, il suo numero telefonico, o in generale un dato che permette di indirizzare correttamente l’ordine all’esercente 1 ed infine una descrizione del prodotto/servizio. Nel caso contrario, il sistema di gestione 4 invia un messaggio che indica che l’esercente 1 non à ̈ attendibile o che il prodotto/servizio non à ̈ disponibile per la vendita.

In generale, l’applicazione 20 riceve dal sistema di gestione 4 informazioni che permettono di verificare il fatto se l’esercente 1 sia attendibile e se il prodotto o servizio sia vendibile. Tali informazioni comprendono:

- nel caso in cui l’esercente 1 sia attendibile, un indirizzo internet e/o un numero telefonico dell’esercente 1 che consentano di indirizzare correttamente la richiesta di acquisto, e

- nel caso in cui detto prodotto o servizio sia vendibile, informazioni descrittive e di configurazione sul prodotto o servizio, che consentano all’utente di verificare le caratteristiche del prodotto/servizio e all’applicazione 20 di auto-configurare le informazioni che saranno visualizzate (e/o richieste) all’utente per il perfezionamento dell’acquisto.

Di conseguenza, l’applicazione riceve la risposta dal sistema di gestione 4 ad un passo 2008, e può verificare ad un passo 2010 se l’esercente sia attendibile ed il prodotto/servizio vendibile.

Nel caso in cui l’esercente non sia attendibile o il prodotto/servizio non vendibile (uscita “N†del passo di verificare 2010), l’applicazione mostra ad un passo 2030 una notifica sullo schermo del dispositivo mobile 2 e la procedura termina ad un passo 2020.

Invece, nel caso in cui l’esercente sia attendibile e il prodotto/servizio disponibile (uscita “Y†del passo di verificare 2010), l’applicazione mostra sullo schermo del dispositivo 2 ad un passo 2012 una schermata che riassume la descrizione del prodotto/ servizio. Ad esempio, l’applicazione potrebbe ricevere dal sistema di gestione 4 anche altre informazioni, quale ad esempio il prezzo del prodotto, la quantità di pezzi contenuti in una unità di prodotto, il prezzo di un’eventuale spedizione, un immagine del prodotto, un logo del venditore, etc. La Figura 5 mostra in questo contesto una possibile schermata che potrebbe essere visualizzata su uno schermo 24 del dispositivo mobile 2.

Nella forma di attuazione considerata, la schermata contiene:

- un campo 242 per visualizzare il nome dell’esercente 1 (ad esempio “TaxiCode†, in sede del nome della Cooperativa RadioTaxi);

- uno spazio 244 per visualizzare il logo dell’esercente o l’immagine del prodotto;

- un campo 248 per visualizzare il nome del prodotto (ad esempio il codice del taxi);

- un campo 252 per visualizzare o inserire l’importo del prodotto (il prezzo della corsa nell’esempio);

- un campo 256 per l’inserimento del codice di sicurezza dell’utente;

- un pulsante 258 per confermare l’invio della richiesta di pagamento; e

- eventualmente campi fissi 246, 250 e 254, che contengono testi configurabili per un certo prodotto.

In varie forme di attuazione, la disposizione dei vari campi potrebbe essere anche configurabile e le rispettive informazioni d’impostazione possono essere ricevuti dal sistema di gestione del servizio 4.

L’applicazione controlla quindi ad un passo di verifica 2014 se l’utente approva l’acquisto. Ad esempio, l’utente può approvare l’acquisto tramite l’inserimento del suo codice di sicurezza nel campo 256 e la conferma tramite il tasto 258.

In generale, l’applicazione 20 visualizza quindi a un utente su uno schermo 22 una schermata in funzione delle informazioni sul prodotto e raccoglie gli eventuali dati necessari per il perfezionamento dell’acquisto (ad esempio il prezzo, la quantità, l’indirizzo di consegna o il codice di sicurezza).

Nel caso in cui l’utente interrompe la procedura (uscita “N†del passo di verificare 2014), l’applicazione termina la procedura al passo 2020.

Invece, nel caso in cui l’utente approva l’acquisto (uscita “Y†del passo di verificare 2014), l’applicazione invia ad un passo 2016 la richiesta di acquisto all’indirizzo elettronico o numero telefonico dell’esercente 1 come indicato dal sistema di gestione 4 e termina al passo 2020.

In generale, l’applicazione 20 invia quindi all’indirizzo elettronico o al numero telefonico dell’esercente 1 un messaggio che autorizza il pagamento, ovvero un messaggio che richieda l’acquisto e il conseguente pagamento. Ad esempio, tale messaggio può essere inviato all’indirizzo elettronico o numero telefonico dell’esercente 1 tramite un flusso di dati su una portante telefonica, quale ad esempio un messaggio del servizio SMS o una sessione dati univocamente identificata dall’operatore telefonico o un flusso che comprenda dati identificativi univoci dell’apparato, da cui possa essere rilevato automaticamente l’identificativo dell’utente ordinante.

Pertanto, il codice QR non viene utilizzato per inviare direttamente un richiesta d’acquisto ad un esercente, ma viene aggiunto un addizionale passo che rende il codice QR dinamico e l’acquisto sicuro. Infatti, il codice QR (comprendente un codice esercente ed un codice prodotto) viene utilizzato come puntatore per individuare nella banca dati 42 sia i dati di contatto per l’invio del messaggio di acquisto sia i parametri di configurazioni per l’applicazione 20 installata sul dispositivo mobile dell’utente.

Infatti, come descritto con riferimento alla Figura 5, tutti i campi della schermata 24 possono essere configurabili per ogni combinazioni di codice esercente e codice prodotto. In generale, ogni campo può essere previsto o non previsto per la specifica configurazione e ove previsto, potrà essere un dato visualizzato non modificabile preimpostato con un valore fisso o variabile, oppure richiesto come dato di input all’utente (eventualmente con un valore di default modificabile). Ad esempio, per prodotti con prezzo fisso potrebbe essere richiesta soltanto la quantità, mentre per certi servizi, quale ad esempio il servizio di un taxi, potrebbe essere richiesto l’inserimento dell’importo della corsa ma non la quantità. In modo sostanzialmente analogo, per certi esercenti e/o prodotti/servizi potrebbe essere attivato un campo per l’inserimento di un indirizzo di spedizione. Per l’indirizzo di spedizione o per altri dati personali attinenti alle modalità di consegna, ad es. giorni o orari preferiti per la consegna, o ad altre preferenze dell’utente, sarà possibile attivare un profilo da parte dell’utente, che potrà essere utilizzato, su sua richiesta, per centralizzare queste informazioni e fornirle in modo automatico in fase di check-out a tutti gli esercenti che porranno in vendita beni/servizi acquistabili attraverso l’applicazione 20;

Inoltre, nel caso in cui l’operatore di pagamento supporti tale funzionamento, anche il codice di sicurezza potrebbe non essere richiesto (e quindi anche non trasmesso all’esercente) per micro-pagamenti, ovvero pagamenti con basso prezzo. Invece, per certi esercenti che richiedono un alto livello di sicurezza, potrebbe essere prevista una verifica dell’utente. Ad esempio, per alcuni prodotti destinati ad un certo gruppo di utenti, potrebbe essere previsto che l’utente riceva informazioni su tali prodotti soltanto a seguito di un’autentificazione, ad esempio tramite il suo numero telefonico e codice di sicurezza. Quindi, in generale, anche il livello di sicurezza potrebbe essere impostabile per ogni esercente.

In generale, non à ̈ necessario che nella banca dati 42 siano salvati i dati di configurazioni per tutte le combinazioni di codice esercente e codice prodotti. Ad esempio, per certi esercenti potrebbe essere previsto un unico insieme di parametri di configurazioni per tutti i prodotti. Inoltre, potrebbe anche essere previsto un codice che indichi all’applicazione 20 installata sul dispositivo mobile 2 di selezionare uno specifico insieme di parametri di configurazioni preinstallato. Infine, potrebbe essere previsto che tali parametri di configurazione per l’applicazione 20 vengono gestiti direttamente tramite una banca dati presso l’esercente 1. Ad esempio, in questo caso, il sistema di gestione 4 potrebbe verificare soltanto l’esistenza di un esercente 1 e inoltrare una richiesta contenete il codice di prodotto al rispettivo esercente 1. Successivamente, ricevuti i rispettivi parametri di controllo per lo specifico prodotto, il sistema di gestione 4 potrebbe inoltrare tali parametri di configurazione al dispositivo mobile 2.

In varie forme di attuazione, il sistema di gestione 4 può anche effettuare altri controlli. Ad esempio, in una forma di attuazione, l’esercente 1 potrebbe configurare per certi prodotti una data di scadenza del periodo di vendita. In tale caso, il sistema di gestione 4 potrebbe verificare se tale offerta sia ancora valida o già scaduta.

In varie forme di attuazione, per permettere una personalizzazione dei dati da inviare all’esercente 1, il sistema di gestione 4 invia al dispositivo mobile informazioni che specificano la sintassi della richiesta di acquisto per lo specifico esercente.

Ad esempio, per prodotti con prezzi fissi, la richiesta potrebbe avere il seguente formato:

<RES>;<CP>;<Q>;<CV2>

dove il parametro <RES> indica un campo con testo configurabile, il parametro <CP> indica il codice del prodotto, il parametro <Q> indica la quantità richiesta dall’utente e il parametro <CV2> indica il codice di sicurezza eventualmente criptato.

Invece, per prodotti con prezzo variabile, quale ad esempio il servizio di un taxi, la richiesta potrebbe avere il seguente formato:

<RES>;<TOT>;<CV2>

dove il parametro <RES> indica un campo con testo configurabile, il parametro <TOT> indica l’importo come inserito dall’utente e il parametro <CV2> indica il codice di sicurezza eventualmente criptato.

Infine, l’esercente 1 riceve la richiesta di acquisto à ̈ può inviare la rispettiva richiesta di addebito attraverso il sistema di gestione 4 al rispettivo operatore di pagamento 3.

La Figura 6 mostra una possibile attuazione dello scambio di informazioni tra l’esercente 1, il sistema di gestione 4, e l’operatore di pagamento 3.

Come menzionato in precedenza, l’utente, attraverso l’utilizzo dell’applicazione 20 installata sul dispositivo mobile 2, quale ad esempio un telefono cellulare, invia ad un passo 2016 un messaggio contenente una richiesta di acquisto ad un esercente 1.

Ad un passo di verifica 1002, L’applicazione dell’esercente analizza il messaggio ricevuto al fine di verificare l’esattezza della sintassi.

Nel caso in cui il messaggio contenesse errori di sintassi (uscita “N†del passo di verificare 1002), l’applicazione dell’esercente 1 invia all’utente 2 un messaggio di errore ERR1, ad esempio tramite SMS.

Invece, nel caso in cui la sintassi sia corretta(uscita “Y†del passo di verificare 1002), l’applicazione dell’esercente 1 effettua ad un passo di verifica 1004 la verifica di disponibilità del bene/servizio e dell’importo da addebitare.

Nel caso in cui la disponibilità non sia sufficiente (uscita “N†del passo di verificare 1004), l’applicazione dell’esercente 1 invia all’utente 2 un messaggio di errore ERR2.

Invece, nel caso in cui vi sia la disponibilità del bene/servizio richiesto dall’utente (uscita “Y†del passo di verificare 1004), l’applicazione dell’esercente 1 invia ad un passo 1006 un messaggio contenente una richiesta d’autorizzazione al pagamento per l’importo verificato al sistema di gestione 4.

Ad un passo 4002, il sistema di gestione 4 riceve tale messaggio ed elabora la richiesta, verificando l’iscrizione dell’utente al servizio di pagamento, individuando l’operatore di pagamento associato all’utente ed effettuando eventuali controlli necessari per l’inoltro della transazione all’operatore di pagamento. Preferibilmente, l’applicazione del sistema di gestione 4 verifica se i messaggi contenenti richieste d’autorizzazione al pagamento possano arrivare soltanto da specifici indirizzi, ad esempio nel caso in cui le comunicazioni tra l’esercente 1, il sistema di gestione 4 e l’operatore di pagamento 3 siano scambiati attraverso internet, tali indirizzi possono essere gli indirizzi IP degli esercenti iscritti al servizio.

Qualora l’utente non sia iscritto al servizio di pagamento (uscita “N†del passo di verificare 4002), ovvero l’applicazione del sistema di gestione 4 non sia in grado di trovare l’identificazione del utente nella banca dati 40, l’applicazione del sistema di gestione 4 notifica tale errore all’esercente 1, e ad un passo 1008 l’applicazione dell’esercente 1 può inviare all’utente 2 un messaggio di errore ERR3 che indica il fatto che l’utente non à ̈ iscritto al servizio.

Nel caso in cui l’utente sia iscritto al servizio di pagamento (uscita “Y†del passo di verificare 4002), ovvero l’applicazione del sistema di gestione 4 sia stata in grado di trovare l’identificazione del utente e il rispettivo operatore di pagamento nella banca dati 40, l’applicazione del sistema di gestione 4 registra l’operazione da autorizzare in stato pendente ed inoltra ad un passo 4004 la richiesta di autorizzazione all’operatore di pagamento 3 associato all’utente.

Ad un passo 3002, l’applicazione dell’operatore di pagamento 3 processa la richiesta di autorizzazione, inoltrandola ove necessario ai circuiti autorizzativi, e comunica l’esito dell’operazione al sistema di gestione 4.

Ad un passo di verifica 4006, l’applicazione del sistema di gestione 4, ricevuto l’esito dell’operazione, verifica il risultato della autorizzazione.

Nel caso in cui l’autorizzazione sia stata negata (uscita “N†del passo di verificare 4006), l’applicazione del sistema di gestione 4 notifica tale errore all’esercente 1, e ad un passo 1010 l’applicazione dell’esercente 1 può inviare all’utente 2 un messaggio di errore ERR4 che indica il fatto che l’autorizzazione à ̈ stata negata.

Invece, nel caso in cui l’autorizzazione sia stata confermata (uscita “Y†del passo di verificare 4006), l’applicazione del sistema di gestione 4 effettua l’aggiornamento dello stato della transazione da pendente in autorizzata e comunica l’esito all’esercente 1.

Ad un passo 1012, ricevuto l’esito positivo della richiesta di autorizzazione, l’applicazione dell’esercente 1 richiede la contabilizzazione inviando all’sistema di gestione 4 una richiesta di contabilizzazione.

Ad un passo 4008, ricevuta la richiesta di contabilizzazione, l’applicazione del sistema di gestione 4 inserisce l’operazione da contabilizzare in stato pendente, e la inoltra all’operatore di pagamento 3.

Ad un passo 3004, l’applicazione dell’operatore di pagamento elabora la richiesta di contabilizzazione e comunica l’esito di tale operazione al sistema di gestione 4.

Ad un passo di verifica 4010, l’applicazione del sistema di gestione 4, ricevuto l’esito della contabilizzazione, verifica il risultato della autorizzazione.

Nel caso in cui la contabilizzazione sia stata negata (uscita “N†del passo di verificare 4010), l’applicazione del sistema di gestione 4 notifica tale errore all’esercente 1, e ad un passo 1014 l’applicazione dell’esercente 1 può inviare all’utente 2 un messaggio di errore ERR5 che indica il fatto che la contabilizzazione à ̈ stata negata.

Invece, nel caso in cui la contabilizzazione sia stata confermata (uscita “Y†del passo di verificare 4010), l’applicazione del sistema di gestione 4 effettua l’aggiornamento dell’operazione di contabilizzazione da pendente in contabilizzata e comunica l’esito all’esercente 1.

Di conseguenza, nel caso di esito positivo della contabilizzazione, l’applicazione dell’esercente 1 invia ad un passo 1016 un messaggio di conferma dell’acquisto OK1 all’utente ed autorizza l’erogazione del bene/servizio. In una forma di attuazione esiste la possibilità di effettuare una contabilizzazione “esplicita†, in cui viene rilasciato il prodotto direttamente a fronte dell’autorizzazione 3002 e la contabilizzazione potrebbe essere effettuata in un secondo momento. Pertanto i passi 1012, 4008, 3004, 4010, e 1014 sono puramente opzionali e l’uscita “Y†del passo di verifica 4006 potrebbe portare direttamente al passo 1016.

In una forma di attuazione, per consentire l’acquisto di più prodotti tramite un’unica richiesta d’acquisto, il sistema di vendita à ̈ configurato per gestire un carello di acquisto virtuale.

La Figura 7 mostra in questo contesto un diagramma di flusso che riassume le principali operazioni. Il diagramma di flusso à ̈ basato sostanzialmente sul diagramma di flusso mostrato nella Figura 4 e pertanto non verranno ripetuti tutti i passi che sono stati descritti già in precedenza.

Anche in questo caso, l’applicazione rileva ad un passo 2002 tramite la telecamera 22 del dispositivo mobile 2 il codice QR 100 applicato all’oggetto 10 e ad un passo 2004, l’applicazione analizza il codice QR 100 à ̈ determina il codice identificavo per l’esercente ed il codice identificativo per il prodotto/servizio.

Ad un passo 2006, l’applicazione invia il codice dell’esercente ed il codice del prodotto/servizio al sistema di gestione 4 e l’applicazione riceve la risposta dal sistema di gestione 4 ad un passo 2008.

Di conseguenza, l’applicazione 20 può verificare ad un passo di verificare 2010 se l’esercente sia attendibile ed il prodotto/servizio vendibile.

Nel caso in cui l’esercente sia attendibile (uscita “Y†del passo di verificare 2010), l’applicazione mostra sullo schermo del dispositivo 2 ad un passo 2012 una schermata che riassume la descrizione del prodotto/ servizio.

Mentre nella forma di attuazione descritta con riferimento alla Figura 4 era previsto soltanto un unico tasto per inviare il messaggio di acquisto all’esercente 1, in questo caso sono previsti due tasti, ad esempio un tasto con la scritta “Aggiungere al carello†ed un tasto con la scritta “Comprare†.

L’applicazione 20 controlla quindi ad un passo di verifica 2040 l’azione dell’utente.

Nel caso in cui l’utente interrompe la procedura (uscita “EXIT†del passo di verificare 2040), l’applicazione termina la procedura al passo 2020.

Invece, nel caso in cui l’utente preme il tasto “Aggiungere al carello†e aggiunge un prodotto al suo carello (uscita “CAR†del passo di verificare 2040), l’applicazione invia ad un passo 2042 al sistema di gestione 4 un messaggio contenente il codice del prodotto, ed eventualmente il suo prezzo o la quantità. Il sistema di gestione 4 inizializza al primo inserimento un elenco temporaneo di prodotti dell’utente e aggiunge il prodotto selezionato a tale elenco. In alternativa, l’utente potrebbe inviare anche direttamente il testo della richiesta di acquisto con il formato specificato dall’esercente e il sistema di gestione 4 potrebbe salvare nell’elenco di prodotti il testo dei vari messaggi di acquisto.

Successivamente, il sistema di gestione 4 restituisce un codice che identifica l’elenco di prodotti dell’utente. Di conseguenza, l’applicazione riceve tale codice ad un passo 2044 e torna al passo 2002 in modo tale che l’utente possa riprendere altri codici QR e aggiungere altri prodotti all’elenco.

Infine, nel caso in cui l’utente preme il tasto “Comprare†e approva l’acquisto (uscita “BUY†del passo di verificare 2040), l’applicazione invia ad un passo 2046 la richiesta di acquisto all’indirizzo elettronico o numero telefonico dell’esercente 1 come indicato dal sistema di gestione 4 e termina al passo 2020. Tuttavia, in questo caso, il messaggio non contiene il codice del prodotto ma il codice dell’elenco di prodotti dell’utente come memorizzato nel sistema di gestione 4.

Di conseguenza, l’applicazione dell’esercente 1 contatta il sistema di gestione 4 à ̈ richiede l’elenco dei prodotti per il codice ricevuto dall’utente 2.

L’esperto del ramo apprezzerà che le forme di attuazioni descritte in precedenza hanno numerosi vantaggi, soprattutto la sicurezza e l’interoperabilità, che consente l’iscrizione da parte dell’utente presso un unico operatore di pagamento à ̈ l’possibilità di operare con un’unica applicazione su qualsiasi esercente aderente.

Tuttavia, l’inventore ha osservato che le soluzioni descritte in precedenza (sia le soluzioni che utilizzano applicazione dedicate sia quelle che utilizzano una applicazione generica) hanno lo svantaggio che l’esercente 1 può erogare il bene o servizio soltanto quando viene ricevuto un messaggio di approvazione dal sistema di gestione 4 all’passo 1016. Pertanto, à ̈ richiesto che l’esercente 1 abbia accesso ad un elaboratore, quale ad esempio un computer fisso o un dispositivo mobile, che à ̈ in grado di ricevere e/o visualizzare il messaggio generato dal sistema di gestione al passo 4010.

In varie forme di attuazione, per evitare questo problema, l’esercente può visualizzare il messaggio di conferma dell’acquisto tramite il dispositivo mobile dell’utente, quale ad esempio l’applicazione 20 utilizzata per acquisire il bene.

La Figura 8 mostra una forma di attuazione di un procedimento che permette di effettuare e verificare un acquisto tramite un’applicazione installata sul dispositivo dell’utente 2. Come menzionato in precedenza, tale procedimento potrebbe essere implementato anche nell’applicazione 20.

Dopo un passo iniziale 2000, l’utente 2 richiede il pagamento di un bene o servizio ad un passo 2060. In particolare, durante tale fase 2060, l’utente seleziona almeno un prodotto e autorizza il pagamento del relativo prezzo tramite il suo dispositivo mobile. Ad esempio, in una forma di attuazione, l’utente 2 seleziona uno o più prodotti e/o servizi attraverso un’applicazione dedicata o mediante un codice QR e invia una richiesta che autorizza il pagamento al sistema dell’esercente 1, ossia il passo 2060 può includere i passi 2002 a 2016 mostrati nella Figura 4 o i passi 2002 a 2046 mostrati nella Figura 7.

In seguito, il sistema dell’esercente 1 e/o il sistema di gestione 4 elabora la richiesta di autorizzazione e invia il risultato della richiesta al dispositivo del utente 2. Ad esempio, l’autorizzazione dell’acquisto può essere effettuata tramite il procedimento descritto con riferimento alla Figura 6, ossia i passi 1002-1016, 4002-4010 e 3002-3004.

In alternative potrebbe anche essere utilizzato il procedimento di pagamento che viene descritto nella domanda di brevetto italiano TO2011A000861, il cui contenuto à ̈ incorporato qui per riferimento. Ad esempio, in tale domanda di brevetto l’utente riceve ad un passo indicato con il numero “2014†un messaggio che indica l’esito dell’autorizzazione di pagamento.

In generale, alla fine dell’autorizzazione, l’utente 2 riceve ad un passo 2062 attraverso il suo dispositivo mobile un messaggio OK1 indicativo dell’approvazione dell’acquisto. Tale messaggio può essere ricevuto direttamene dal sistema di gestione 4 o tramite il sistema dell’esercente 1. In generale, il messaggio di approvazione OK1 può essere qualsiasi messaggio elettronico, quale ad esempio un messaggio del servizio SMS o un’e-mail.

Ad un passo 2064, l’utente 2 mostra il messaggio di approvazione OK1 all’esercente 1 (o ad una figura preposta all’erogazione del bene/servizio). Ad esempio, in varie forme di attuazione, l’utente mostra al passo 2064 attraverso l’applicazione installata sul dispositivo 2 una schermata che contiene un riepilogo degli articoli acquisti. Pertanto, in generale, il contenuto della schermata visualizzata al passo 2064 à ̈ determinata in funzione del contenuto del messaggio di approvazione OK1.

In seguito, ad un passo 2066, l’esercente 1 può verificare sul dispositivo dell’utente 2 la validità del acquisto e può erogare il bene o servizio ad un passo 2074.

Infine il procedimento termina ad un passo 2020.

In varie forme di attuazione, per garantire che lo stesso messaggio di approvazione OK1 può essere utilizzato soltanto per un singolo acquisto, à ̈ previsto che l’esercente 1 può convalidare l’acquisto mediante l’applicazione installata sul dispositivo dell’utente 2. Ad esempio, in varie forme di attuazione, l’esercente 1 controlla al passo 2066 l’elenco dei prodotti e convalida ad un passo 2068 l’acquisto, ad esempio, premendo un tasto apposito sulla schermata del dispositivo mobile e/o strappando virtualmente il biglietto, ad esempio, passando il dito sul display del dispositivo mobile dell’utente 2 in direzione diagonale, ossia da angolo a angolo.

Pertanto, in varie forme di attuazione, l’applicazione 20 à ̈ configurata per rilevare al passo 2068 un evento che indica la convalida dell’acquisto e l’applicazione può registrare l’acquisto come convalidato ad un passo 2070. Ad esempio, in una forma di attuazione, quando viene ricevuto un messaggio di approvazioni OK1, tale messaggio viene salvato (eventualmente insieme all’riepilogo del acquisto) in un registro di messaggi non convalidati. In particolare, in questo caso, l’applicazione permette soltanto la convalida dei titoli in tale registro. Una volta convalidato un acquisto, i titoli utilizzati vengono caricati in un secondo archivio o registro all’interno dell’applicazione 20 e possono essere soltanto visualizzati ma non più convalidati. Preferibilmente, tale convalida viene anche comunicata al sistema dell’esercente 1 per segnalare che il prodotto o servizio à ̈ stato fruito.

Ad esempio, il procedimento descritto in precedenza può essere utilizzato per pagare una corsa di un taxi. Come descritto in precedenza, l’utente 2 potrebbe rilevare tramite il suo dispositivo mobile un codice QR che identifica il numero di un taxi e la relativa cooperativa, ossia un codice esercente e un codice prodotto. In seguito, l’applicazione 20 potrebbe richiedere dal sistema di gestione 4 i dati di contatti della cooperativa, e l’utente 2 potrebbe inserire il prezzo richiesto per la corsa e autorizzare il pagamento tramite l’inserimento del suo codice di sicurezza (passo 2060). Alla fine dell’autorizzazione l’applicazione 20 riceve il messaggio OK1 che conferma l’autorizzazione del pagamento (passo 2062), e l’utente 2 mostra la schermata che visualizza il riepilogo dell’acquisto al tassista (passo 2064). Il tassista a sua volta controlla il riepilogo (passo 2066) e convalida l’acquisto premendo un tasto appositamente collocato sulla schermata del dispositivo mobile 2 (passo 2068). Infine, l’applicazione registra la corsa come convalidata e invia un messaggio di conferma al sistema dell’esercente 1 (passo 2070), ad esempio, tramite un messaggio, quale ad esempio un messaggio del servizio SMS, che viene inviato all’indirizzo elettronico dell’esercente 1 ricevuto in precedenza.

L’inventore ha osservato che le soluzioni descritte in precedenza hanno l’inconveniente che la schermata che viene visualizzata al passo 2066 per convalidare l’acquisto potrebbe essere falsificata. Ad esempio, un’applicazione appositamente sviluppata potrebbe riprodurre tutti i passi dell’applicazione originale tranne i passi che interagiscono con il sistema dell’esercente 1 e/o il sistema di gestione 4, ossia i passi richiesti per autorizzare il pagamento.

In una forma di attuazione, per evitare questo problema, l’applicazione 20 riceve insieme al messaggio OK1 che approva l’acquisto un elemento che certifica la validità del acquisto, ossia il sistema che genera il messaggio OK1 allega a tale messaggio anche un elemento di certificazione.

Ad esempio, tali elementi di certificazioni possono essere uno o più elementi grafici, sonori e/o altri effetti visivi, e sono conosciuti soltanto dall’esercente 1 stesso. Ad esempio, l’elemento di certificazione potrebbe essere almeno uno fra:

- una parola, un numero o in generale una sequenza alfanumerica;

- un’immagine, un suono e/o una sequenza video;

- altri effetti visivi, quale ad esempio un cambiamento del colore dello sfondo della schermata.

In una forma di attuazione, l’applicazione visualizza questo elemento di certificazione al passo 2066, preferibilmente soltanto ad un passo 2072 quando la convalida à ̈ avvenuta. Pertanto, l’esercente 1 può verificare immediatamente se viene visualizzato o riprodotto l’elemento corretto.

In una forma di attuazione, l’elemento di certificazione viene cambiato regolarmente dopo certi intervalli temporanei. Ad esempio, nel caso del servizio taxi, l’elemento di certificazione potrebbe essere valido per un giorno, mentre per altri esercizi, quali ad esempio ristoranti o cinema, l’elemento potrebbe essere valido soltanto per un’ora.

In una forma di attuazione, l’elemento di certificazione à ̈ un codice che non viene visualizzato direttamente, quale ad esempio un codice univoco associato allo specifico pagamento. In questo caso, al passo 2066, ad esempio quando l’esercente 1 convalida l’acquisto (passo 2068) o quando la applicazione invia il messaggio di conferma al sistema dell’esercente 1 (passo 2070), l’applicazione 20 invia tale codice al sistema dell’esercente 1 e/o al sistema di gestione 4, e riceve in risposta un rispettivo elemento da visualizzare e/o riprodurre. Questa forma di attuazione ha il vantaggio che l’utente 2 può ritirare il prodotto anche dopo molto tempo e il codice di certificazione à ̈ comunque valido.

Pertanto, nelle soluzioni descritte in precedenza l’acquisto può essere effettuato e verificato tramite il dispositivo mobile dell’utente 2 e non sono richiesti ulteriori dispositivi per il controllo, quali ad esempio lettori o scanner di codice a barre/QR che vengono utilizzati, ad esempio, ad aeroporti per verificare un biglietto di volo. Infatti, la validità dell’acquisto può essere verificato semplicemente mediante il dispositivo mobile dell’utente 2 che mostra o riproduce elementi grafici, sonori e/o visivi che certificano la validità del titolo.

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 pagare tramite un dispositivo mobile (2) almeno un prodotto e/o servizio offerta da un esercente (1), comprendente le fasi di: - inviare (2060) ad un sistema di pagamento (1, 3, 4) che gestisce i pagamenti di detto esercente (1) un messaggio elettronico che autorizza il pagamento di detto almeno un prodotto e/o servizio; - ricevere (2062) da detto sistema di pagamento (1, 3, 4) un messaggio elettronico di conferma (ERR1-ERR5, OK1) indicativo del risultato dell’autorizzazione del pagamento, e - nel caso in cui detto messaggio di conferma (ERR1-ERR5, OK1) à ̈ un messaggio di approvazione (OK1) che indica l’autorizzazione del pagamento: a) generare (2064) una schermata che contiene un riepilogo dei prodotti e/o servizi pagati, b) rilevare (2068) un evento che convalida il pagamento di detti prodotti e/o servizi, e c) classificare (2070) detto messaggio di approvazione (OK1) come messaggio di approvazione convalidato.
2. 2. Il procedimento secondo la rivendicazione 1, in cui: - detto ricevere (2062) da detto sistema di pagamento (1, 3, 4) un messaggio elettronico di conferma (ERR1-ERR5, OK1) indicativo del risultato dell’autorizzazione del pagamento comprende archiviare detto messaggio elettronico di conferma (ERR1-ERR5, OK1) in un primo registro di messaggi, e - detto classificare (2070) detto messaggio di approvazione (OK1) come messaggio di approvazione convalidato comprende archiviare detto messaggio di approvazione (OK1) in un secondo registro di messaggi che possono essere visualizzati ma non più convalidati.
3. 3. Il procedimento secondo la rivendicazione 1 o la rivendicazione 2, in cui detto classificare (2070) detto messaggio di approvazione (OK1) come messaggio di approvazione convalidato comprende: - inviare a detto sistema di pagamento (1, 3, 4) un messaggio elettronico che indica il fatto che detto messaggio di approvazione (OK1) Ã ̈ stato convalidato.
4. 4. Il procedimento secondo una delle precedenti rivendicazioni, comprendente: - nel caso in cui detto messaggio di conferma (ERR1-ERR5, OK1) à ̈ un messaggio di approvazione (OK1): d) visualizzare e/o riprodurre almeno un elemento grafico, sonore e/o altri effetti visivi, quali ad esempio una parola, un numero, una sequenza alfanumerica, un’immagine, un suono e/o una sequenza video.
5. 5. Il procedimento secondo la rivendicazione 4, in cui detto almeno un elemento viene visualizzato e/o riprodotto quando detto evento che convalida il pagamento di detti prodotti e/o servizi à ̈ stato rilevato.
6. 6. Il procedimento secondo la rivendicazione 4 o la rivendicazione 5, comprendente ricevere detto almeno un elemento da detto sistema di pagamento (1, 3, 4) insieme a detto messaggio di approvazione (OK1).
7. 7. Il procedimento secondo la rivendicazione 4 o la rivendicazione 5, comprendente: - ricevere da detto sistema di pagamento (1, 3, 4) un codice univoco insieme a detto messaggio di approvazione (OK1), - quando detto evento che convalida il pagamento di detti prodotti e/o servizi à ̈ stato rilevato, inviare detto codice univoco a detto sistema di pagamento (1, 3, 4) e ricevere da detto sistema di pagamento (1, 3, 4) detto almeno un elemento.
8. 8. Il procedimento secondo una delle precedenti rivendicazioni, in cui detto rilevare (2068) un evento che convalida il pagamento di detti prodotti e/o servizi comprende: - rilevare l’azionamento di un tasto di convalida, e/o - rilevare il movimento di un dito sullo schermo di detto dispositivo mobile in una direzione diagonale.
9. 9. Il procedimento secondo una delle precedenti rivendicazioni, in cui detto inviare (2060) ad un sistema di pagamento (1, 3, 4) che gestisce i pagamenti di detto esercente (1) un messaggio elettronico che autorizza il pagamento di detto almeno un prodotto e/o servizio comprende: - rilevare (2002, 2004) tramite un sensore (22) un codice esercente identificativo per un esercente (1) ed un codice prodotto identificativo per un prodotto o servizio; - inviare (2006) detto codice esercente e detto codice prodotto ad un sistema di gestione (4), in cui detto sistema di gestione (4) gestisce i pagamenti tra una pluralità di esercenti (1) ed una pluralità di utenti; - ricevere (2008) da detto sistema di gestione (4) informazioni che permettono di verificare il fatto se detto esercente (1) sia attendibile e se detto prodotto o servizio sia vendibile, in cui dette informazioni comprendono: a) nel caso in cui detto esercente (1) sia attendibile, un indirizzo elettronico e/o un numero telefonico di detto esercente (1), e b) nel caso in cui detto prodotto o servizio sia vendibile, informazioni descrittive e di configurazione di detto prodotto o servizio; e - verificare (2010) se detto esercente (1) sia attendibile e se detto prodotto o servizio sia vendibile, e nel caso in cui detto esercente (1) sia attendibile e detto prodotto o servizio sia vendibile: a) visualizzare (2012) a un utente su uno schermo (22) una schermata in funzione di dette informazioni di detto prodotto o servizio, b) verificare (2014, 2040) se detto utente autorizza il pagamento, e c) nel caso in cui detto utente autorizzi il pagamento, inviare (2016, 2046) a detto indirizzo elettronico o a detto numero telefonico di detto esercente (1) un messaggio che autorizza il pagamento.
10. 10. Un dispositivo mobile, caratterizzato dal fatto che detto dispositivo mobile (2) Ã ̈ configurato per implementare il procedimento secondo una delle rivendicazioni 1 a 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 9.