ITTO20110575A1 - Procedimento per autorizzare un pagamento tramite un dispositivo mobile, relativo procedimento per gestire un pagamento, dispositivo mobile, sistema per gestire un pagamento e prodotto informatico - Google Patents

Description

"Procedimento per autorizzare un pagamento tramite un dispositivo mobile, relativo procedimento per gestire un pagamento, dispositivo mobile, sistema per gestire un pagamento 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 procedimento per gestire un pagamento, dispositivo mobile, e sistema per gestire un 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, lo scopo dell'invenzione à ̈ quello di realizzare un'architettura che risulti sicura, semplice, efficiente ed interoperabile.

In varie forme di attuazione, per rendere il servizio semplice, il dispositivo mobile à ̈ configurato per rilevare codici che identificano un esercente e un prodotto/servizio venduto. Ad esempio, in varie forme di attuazione, tale codice à ̈ un codice a barre monodimensionale o bidimensionale, quale ad esempio un codice QR (Quick Response code) o un Data Matrix.

In varie forme di attuazione, il dispositivo mobile analizza il codice rilevato e identifica l'esercente e il prodotto o servizio in vendita.

In varie forme di attuazione, il dispositivo invia una richiesta d'acquisto all'esercente identificato. Ad esempio, in varie forme di attuazione, tale richiesta di acquisto viene inviata tramite un messaggio di tipo Short Message Service (SMS).

L'inventore ha osservato che tale passaggio può essere esposto a problemi di sicurezza, perché un codice statico, anche nel caso in cui il codice sia criptato, può essere copiato e falsificato. Pertanto, l'utente potrebbe autorizzare un pagamento non voluto.

Per evitare questo problema, in varie forme di attuazione, il sistema di pagamento comprende una banca dati contenente un elenco d'esercenti autorizzati con i relativi prodotti venduti. Tale banca dati può risiedere in locale o può essere frutto di un'interrogazione diretta ad una banca dati remota del singolo esercente secondo un protocollo predefinito (casi con elevata numerosità o dinamicità dei prodotti venduti).

Ad esempio, in varie forme di attuazione, il dispositivo mobile à ̈ configurato per inviare il codice dell'esercente e del prodotto rilevato a tale banca dati per verificare l'esistenza e/o validità del venditore e del prodotto oggetto della vendita.

Ad esempio, in varie forme di attuazione, la banca dati restituisce alcuni dati di controllo che permettono di identificare l'esercente e il prodotto/servizio venduto, quale ad esempio l'esistenza dello specifico codice esercente, l'indirizzo elettronico, quale ad esempio un indirizzo IP o un numero telefonico, a cui mandare la richiesta di acquisto, il logo del esercente, la validità del prodotto/servizio oggetto di vendita e la relativa configurazione di vendita.

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.

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 e 6 sono diagrammi di flusso che illustrano dettagli dei sistemi di pagamento delle Figura 2 e 3; e

- la Figura 4 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 eco. 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 la e lb, 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 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 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 oqni transazione ed à ̈ utilizzabile soltanto una volta, e soltanto l'operatore di paqamento 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 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à del 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 quale ad esempio un

RF-ID (Radio Frequency IDentification ) o Bluetooth configurato per 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/ servi zio.

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 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 del 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 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 del 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 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 d esistenze 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 ERRI, 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 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 OKI 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 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 qestione 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 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 gualsiasi esercente aderente.

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 autorizzare un pagamento tramite un dispositivo mobile comprendente le fasi di: - 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.
2. 2. Procedimento secondo la rivendicazione 1, in cui detto sensore à ̈ un sensore ottico, ed in cui detto codice esercente e detto codice prodotto sono codificati all’interno di un codice Quick Response o una Data Matrix.
3. 3. Procedimento secondo la rivendicazione 1 o la rivendicazione 2, in cui detto inviare (2016, 2046) a detto indirizzo elettronico o a detto numero telefonico di detto esercente (1) un messaggio che autorizza il pagamento comprende inviare a detto numero telefonico di detto esercente (1) un messaggio del servizio SMS.
4. 4. Procedimento secondo una delle precedenti rivendicazioni, in cui detto utente autorizza il pagamento tramite l’inserimento di un solo codice di sicurezza, e in cui detto procedimento comprende: - criptare detto codice di sicurezza, e - inviare (2016, 2046) detto codice di sicurezza criptato con detto messaggio che autorizza il pagamento.
5. 5. Procedimento secondo una delle precedenti rivendicazioni, in cui detto procedimento comprende: - verificare (2040) se detto utente vuole aggiungere un prodotto o servizio a un carello di acquisto virtuale; - nel caso in cui detto utente vuole aggiungere un prodotto o servizio a un carello di acquisto virtuale, inviare (2042) a detto sistema di gestione (4) un messaggio che contiene il codice di detto prodotto e ricevere da detto sistema di gestione (4) un messaggio che contiene un codice che identifica un elenco di prodotti memorizzato in detto sistema di gestione (4); in cui detto messaggio che autorizza il pagamento contiene detto codice che identifica detto elenco di prodotti memorizzato in detto sistema di gestione (4).
6. 6. Procedimento per gestire un pagamento tra una pluralità di esercenti (1) ed una pluralità di utenti comprendete le fasi di: - ricevere (2006) da un dispositivo mobile (2) un codice esercente identificativo per un esercente e un codice prodotto identificativo per un prodotto o servizio; - verificare se l’esercente (1) identificato da detto codice esercente sia attendibile tramite le fasi di: a) determinare se una banca dati (42) comprende detto codice esercente, e b) nel caso in cui detta banca dati (42) comprenda detto codice esercente, rilevare da detta banca (42) un indirizzo elettronico e/o un numero telefonico di detto esercente (1); - verificare se il prodotto o servizio identificato da detto codice prodotto sia vendibile tramite le fasi di: a) determinare se una banca dati (42) comprende detto codice prodotto, e b) nel caso in cui detta banca dati (42) comprenda detto codice prodotto, rilevare da detta banca dati informazioni descrittive e di configurazione di detto prodotto; e - inviare (2008) a detto dispositivo mobile (2) 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 ) si a attendibile, detto indirizzo elettronico e/o detto numero telefonico di detto esercente (1), e b) nel caso in cui detto prodotto o servizio sia vendibile, dette informazioni di detto prodotto.
7. 7. Procedimento secondo la rivendicazione 6, comprendete: - ricevere da un esercente (1) di detta pluralità di esercenti (1) una richiesta di autorizzazione di un pagamento, detta richiesta di autorizzazione comprendente un codice utente che identifica un utente (2) che autorizza il pagamento, - determinare (4002) l’operatore di pagamento di detto utente (2) che autorizza il pagamento tramite le fasi di: a) determinare se una banca dati (40) comprende detto codice utente, e b) nel caso in cui detta banca dati (40) comprenda detto codice utente, rilevare da detta banca dati (40) l’operatore di pagamento (3) di detto utente (2); - inviare (4004) detta richiesta di autorizzazione all’operatore di pagamento di detto utente; - ricevere (4006) da detto operatore di pagamento (3) di detto utente (2) informazioni che permettano di verificare se detta richiesta di autorizzazione à ̈ stata autorizzata, e - trasmettere dette informazioni che permettano di verificare se detta richiesta di autorizzazione à ̈ stata autorizzata a detto esercente (1) di detta pluralità di esercenti (1).
8. 8. Procedimento secondo una delle precedenti rivendicazioni in cui dette informazioni su detto prodotto contengono il logo dell’esercente (1), un’immagine del prodotto, una descrizione del prodotto, il prezzo del prodotto, la quantità di pezzi contenuti in un’unità di prodotto, informazioni che identificano se il prodotto viene spedito e eventualmente il prezzo della spedizione, e/o informazioni che specificano il formato di detto messaggio che autorizza il pagamento.
9. 9. Un dispositivo mobile, caratterizzato dal fatto che detto dispositivo mobile (2) Ã ̈ configurato per implementare il procedimento secondo una delle rivendicazioni 1 a 5.
10. 10. Un sistema per gestire (4) pagamenti tra una pluralità di esercenti (1) ed una pluralità di utenti (2), caratterizzato dal fatto che detto sistema (4) à ̈ configurato per implementare il procedimento secondo una delle rivendicazioni 6 o 7.
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.