ITTO20110861A1 - Procedimento per gestire pagamenti tra una pluralita' di esercenti ed una pluralita' di utenti, relativo sistema per gestire pagamenti e prodotto informatico - Google Patents

Procedimento per gestire pagamenti tra una pluralita' di esercenti ed una pluralita' di utenti, relativo sistema per gestire pagamenti e prodotto informatico Download PDF

Info

Publication number
ITTO20110861A1
ITTO20110861A1 IT000861A ITTO20110861A ITTO20110861A1 IT TO20110861 A1 ITTO20110861 A1 IT TO20110861A1 IT 000861 A IT000861 A IT 000861A IT TO20110861 A ITTO20110861 A IT TO20110861A IT TO20110861 A1 ITTO20110861 A1 IT TO20110861A1
Authority
IT
Italy
Prior art keywords
user
code
payment
merchant
request
Prior art date
Application number
IT000861A
Other languages
English (en)
Inventor
Enrico Sponza
Original Assignee
Movincom Servizi S P A
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Movincom Servizi S P A filed Critical Movincom Servizi S P A
Priority to IT000861A priority Critical patent/ITTO20110861A1/it
Priority to EP12183535A priority patent/EP2575098A1/en
Publication of ITTO20110861A1 publication Critical patent/ITTO20110861A1/it

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/32—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using wireless devices
    • G06Q20/325—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using wireless devices using wireless networks
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/32—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using wireless devices
    • G06Q20/325—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using wireless devices using wireless networks
    • G06Q20/3255—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using wireless devices using wireless networks using mobile network messaging services for payment, e.g. SMS
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/32—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using wireless devices
    • G06Q20/326—Payment applications installed on the mobile devices
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/385—Payment protocols; Details thereof using an alias or single-use codes
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/386—Payment protocols; Details thereof using messaging services or messaging apps
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/40—Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check credit lines or negative lists
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/42—Confirmation, e.g. check or permission by the legal debtor of payment
    • G06Q20/425—Confirmation, e.g. check or permission by the legal debtor of payment using two different networks, one for transaction and one for security confirmation

Landscapes

  • Business, Economics & Management (AREA)
  • Engineering & Computer Science (AREA)
  • Accounting & Taxation (AREA)
  • General Physics & Mathematics (AREA)
  • Physics & Mathematics (AREA)
  • General Business, Economics & Management (AREA)
  • Strategic Management (AREA)
  • Theoretical Computer Science (AREA)
  • Finance (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Computer Security & Cryptography (AREA)
  • Coin-Freed Apparatuses For Hiring Articles (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)
  • Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)

Description

DESCRIZIONE dell’invenzione industriale dal titolo:
“Procedimento per gestire pagamenti tra una pluralità di esercenti ed una pluralità di utenti, relativo sistema per gestire pagamenti 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 dell’utente.
Di conseguenza, à ̈ di notevole importanza come vengono effettuate le varie comunicazioni tra questi partecipanti alla vendita, in modo tale che l’operazione sia semplice e sicura. Infatti, nell’ambito dei pagamenti tramite dispositivi mobili à ̈ indispensabile autenticare il numero telefonico del dispositivo mobile 2. Tuttavia, anche se gli attuali standard di comunicazione mobile, quale ad esempio Global System for Mobile Communications (GSM) o Universal Mobile Telecommunications System (UMTS), prevedono meccanismi per autenticare il numero telefonico di un dispositivo mobile 2, tali meccanismi non sono resi disponibile all’utenza, ad esempio all’esercente 1 o l’operatore di pagamento, dagli operatori mobili.
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 gestire pagamenti tra una pluralità di esercenti ed una pluralità di utenti dotato delle caratteristiche specificate nell’annessa rivendicazione 1. L’invenzione riguarda anche un relativo sistema per gestire pagamenti, 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. Secondo la presente descrizione, tale scopo viene raggiunto tramite un sistema di gestione che gestisce i pagamenti tra una pluralità di esercenti ed una pluralità di utenti.
In varie forme di attuazione, ad ogni esercente à ̈ associato un codice esercente ed ad ogni utente à ̈ associato un codice utente. Ad esempio, tali codici possono essere salvati in una banca dati che viene gestita dal sistema di gestione del pagamento.
In varie forme di attuazione, l’utente seleziona i prodotti desiderati su un sito internet di un esercente. Successivamente, per avviare il pagamento ed essere riconosciuto come cliente iscritto al servizio di pagamento, l’utente inserisce in un apposito campo non il suo codice di sicurezza ma un codice che identifica l’utente, quale ad esempio il suo numero telefonico o un altro codice associato all’utente durante la registrazione all’servizio di vendita.
Di conseguenza, l’esercente o l’utente invia al sistema di gestione una richiesta di pagamento contenente il codice dell’esercente e il codice dell’utente, ovvero il sistema di gestione riceve una richiesta di pagamento contenente il codice esercente e il codice utente. A tale scopo, il sistema di gestione può comprendere un’interfaccia di comunicazione per ricevere richieste di pagamento. Ad esempio, tale interfaccia di comunicazione può essere configurata per ricevere messaggi del servizio SMS (Short Message Service), e-mail, o una richiesta di accesso a un sito web.
In varie forme di attuazione, il sistema di gestione verifica se l’esercente sia attivo e se l’utente sia iscritto al servizio di pagamento. Ad esempio, in varie forme di attuazioni il sistema di gestione determina se la banca dati comprende il codice esercente e il codice utente.
Una volta verificata la presenza dei codici nella banca dati, il sistema di gestione genera un messaggio elettronico, preferibilmente un messaggio del servizio SMS che contiene un link univoco ad un sito gestito dal sistema di gestione. Ad esempio, in una forma di attuazione, il sistema di gestione trasmette all’utente un messaggio del servizio SMS contenente un link ad un sito web, in cui il link comprende un codice univoco.
In varie forme di attuazione, l’utente riceve tale messaggio contenente il link al sito del sistema di gestione e aprendo il link indicato nel messaggio elettronico, il browser del dispositivo mobile apre una pagina web che contiene il riepilogo della spesa nella quale viene richiesto l'inserimento del codice di sicurezza. Inoltre, aprendo il link indicato nel messaggio del servizio SMS l’utente autentica implicatamene il numero telefonico del dispositivo mobile. Di conseguenza, il sistema di gestione riceve dall’utente una richiesta di accesso al sito web identificato tramite il link inviato all’utente, e verifica se la richiesta di accesso comprenda il codice univoco. Inoltre, nel caso in cui la richiesta di accesso comprenda il codice univoco, il sistema di gestione trasmette all’utente una pagine web che contiene il riepilogo del pagamento da autorizzare e un campo per l’inserimento del codice di sicurezza dell’utente.
In varie forme di attuazione, l’utente autorizza quindi l’acquisto inserendo il suo codice di sicurezza. Di conseguenza, il sistema di gestione riceve tramite la pagina web il codice di sicurezza dell’utente. Successivamente, il sistema di gestione rileva dalla banca dati l’operatore di pagamento dell’utente, e trasmette una richiesta di autorizzazione del pagamento all’operatore di pagamento dell’utente.
In varie forme di attuazione tale richiesta di autorizzazione comprende il codice di sicurezza dell’utente.
Di conseguenza, secondo la presente descrizione, l’esercente non ottiene accesso al codice di sicurezza dell’utente ma riceve dal sistema di gestione soltanto un messaggio che conferma o nega il pagamento.
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;
- la Figura 2 mostra una forma di attuazione di un sistemi di pagamento secondo la presente invenzione; e
- le Figure 3 a 5 sono diagrammi di flusso che illustrano dettagli del sistema di pagamento della Figura 2.
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 per 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 di pagamento non à ̈ necessariamente direttamente l’istituto bancario dell’utente, ma potrebbe anche essere un 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.
In seguito verrà descritto un possibile funzionamento del sistema di pagamento della Figura 2.
Nell’esempio considerato, il dispositivo mobile 2 invia, ad esempio tramite un messaggio del servizio SMS, una richiesta di acquisto ad un esercente 1. In seguito, l’esercente 1 inoltra tale richiesta al sistema di gestione 4 che converte la richiesta e inoltra la richiesta convertita al corretto operatore di pagamento 3. Pertanto, l’esercente 1 può autenticare tramite la ricezione del messaggio del servizio SMS in modo esplicito il numero telefonico del dispositivo mobile 2 che manda la richiesta.
Nell’esempio considerato, 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. Ad esempio, tale associazione può essere creata tramite un’iscrizione al servizio di pagamento. Ad esempio, tale iscrizione potrebbe essere effettuata presso l’operatore di pagamento 3 che comunica i dati di iscrizione al sistema di gestione 4. 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, il sistema di gestione 4 riceve da un esercente 1 una richiesta di pagamento che contiene dati che permettono di identificare il dispositivo o l’utente che richiede un acquisto. Ad esempio, 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.
Di conseguenza, tale architettura permette 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.
Nell’esempio considerato, per aumentare la sicurezza del sistema, potrebbe essere previsto che l’utente debba autorizzare ogni pagamento tramite l’inserimento di un codice di sicurezza. Ad esempio, tale meccanismo può essere utile per evitare pagamenti in caso di furti del dispositivo mobile 2 o richieste di pagamenti non volute.
Ad esempio, l’utente potrebbe ricevere questo codice di sicurezza durante l’iscrizione presso l’operatore di pagamento 3. In questo caso, l’utente inserisce lo stesso codice di sicurezza per autorizzare il pagamento, e il codice viene inoltrato insieme al messaggio di acquisto all’esercente 1. In modo simile, l’esercente 1 invia tale codice eventualmente criptato 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.
Tuttavia, in questo caso, à ̈ necessario che l’utente 2 invii all’esercente 1 una richiesta di acquisto contenente il codice di sicurezza. Di conseguenza, l’utente 2 deve conoscere l’indirizzo elettronico dell’esercente 1, 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. Inoltre, à ̈ di notevole importanza che tale indirizzo sia affidabile per evitare che soggetti non autorizzati possono ottenere accesso a questo codice di sicurezza. Infatti, tale codice di sicurezza (eventualmente anche criptato) potrebbe essere riutilizzabile per altri pagamenti.
L’inventore ha osservato che tali problemi potrebbero essere risolti 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. Inoltre, ogni utente deve scaricare per ogni esercente 1 una specifica applicazione.
Dall’altro lato, questo approccio migliora la sicurezza del sistema, 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 opportuno sistema di pagamento in cui l’utente utilizza un dispositivo mobile 2 dotato di un browser internet ed una connettività internet. Tuttavia, come menzionato in precedenza, in questo caso à ̈ opportuno un meccanismo che garantisca che il codice di sicurezza dell’utente rimanga protetto.
La Figura 3 mostra un diagramma di flusso che riassume le principali operazioni che vengono effettuate dall’utente o dispositivo mobile 2.
Dopo un passo iniziale 2000, l’utente accede ad un passo 2002 tramite il suo browser web al sito internet dell’esercente 1 e seleziona ad un passo 2004 i prodotti desiderati. Ad esempio, l’utente potrebbe aprire il browser web del suo dispositivo mobile 2 ed inserire manualmente l’indirizzo web dell’esercente 1. 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 sito dell’esercente 1 può essere effettuata tramite una connessione internet. L’utente potrebbe anche aprire un’applicazione dedicata che ha salvato un indirizzo web predeterminato o che rileva, ad esempio, mediante una telecamera del dispositivo mobile 2 un codice identificativo per l’indirizzo del sito web dell’esercente 1, quale ad esempio un codice QR (Quick Response code) o un Data Matrix.
Ad un passo 2006, per avviare il pagamento ed essere riconosciuto come cliente iscritto al servizio di pagamento, l’utente inserisce in un apposito campo non il suo codice di sicurezza ma un codice che identifica l’utente, quale ad esempio il suo numero telefonico o un altro codice associato all’utente durante la registrazione all’servizio di vendita.
Nella forma di attuazione considerata, l’esercente 1 invia tale codice identificativo per l’utente insieme con un riepilogo della spesa contenente, ad esempio, il prezzo totale al sistema di gestione 4.
Nella forma di attuazione considerata, il sistema di gestione 4 verifica se l’utente sia iscritto al servizio di pagamento. Ad esempio, per verificare se l’utente sia iscritto al servizio di pagamento à ̈ sufficiente verificare la presenza del codice utente nella banca dati 40. Una volta verificata la presenza del codice utente nella banca dati 40, il sistema di gestione 4 genera un messaggio elettronico, preferibilmente un messaggio del servizio SMS che contiene un link univoco ad un sito gestito dal sistema di gestione 4 (e non dall’esercente 1). Ad esempio, in una forma di attuazione, tale messaggio elettronico viene inviato direttamente al numero telefonico segnalato dall'utente in precedenza.
Di conseguenza, ad un passo 2008, l’utente riceve tale messaggio contenente il link al sito del sistema di gestione 4.
Ad un passo 2010, aprendo il link indicato nel messaggio elettronico, il browser del dispositivo mobile 2 apre una pagina web che contiene il riepilogo della spesa, definita Check-Out-Page, nella quale viene richiesto l'inserimento del codice di sicurezza. Preferibilmente tale pagina à ̈ un sito criptato, ad esempio secondo il protocollo Hypertext Transfer Protocol over Secure Socket Layer (HTTPS).
Ad un passo 2012, l’utente autorizza quindi l’acquisto inserendo il suo codice di sicurezza eventualmente oscurata da asterischi.
Infine, ad un passo 2014, l’utente riceve dal sistema di gestione 4 (o eventualmente dal server dell’esercente 1) un messaggio che indica l’esito dell’autorizzazione di pagamento, e la procedura termina ad un passo 2016. Ad esempio, in una forma di attuazione, una volta terminate le operazioni di pagamento, il browser viene indirizzato di nuovo sul sito dell’esercente 1 dove à ̈ possibile proseguire la navigazione utente.
Di conseguenza, in varie forme di attuazione, tale Check-Out-Page non à ̈ gestito dall’esercente 1 ma dal sistema di gestione 4. Pertanto l’utente può verificare immediatamente la correttezza del link e l’esercente non ottiene accesso al codice di sicurezza dell’utente ma riceve dal sistema di gestione soltanto un messaggio che conferma o nega il pagamento. Inoltre, aprendo il link indicato nel messaggio del servizio SMS l’utente autentica implicitamente il numero telefonico del dispositivo mobile 2.
In varie forme di attuazione, il sistema di vendita 4 può anche essere configurato per visualizzare su tale Check-Out-Page altri dati salvati nella banca dati 40 ed associati all’utente e/o numero telefonico. Preferibilmente tali dati sono dati che non sono stati inseriti presso il sito dell’esercente. Ad esempio, la Check-Out-Page potrebbe contenere un campo per visualizzare il nome dell’utente. In questo modo, l’utente può anche verificare ulteriormente l’attendibilità del sito.
La Figura 4 mostra un diagramma di flusso che riassume le principali operazioni che vengono effettuate dal sistema di pagamento per generare il messaggio contenente il link al sito del sistema di gestione 4.
Come menzionato in precedenza, l’utente accede ad un passo 2002 al sito web di un esercente 1.
Al passo 2004, l’utente seleziona attraverso il sito dell’esercente 1 il o i prodotti desiderati. Ad esempio, in una forma di attuazione, il server web dell’esercente 1 à ̈ configurato per gestire ad un passo 1002 un carello di acquisti virtuali, ovvero un elenco in cui vengono salvati per ogni prodotto selezionato, ad esempio, il codice del prodotto, la quantità e il prezzo.
Al passo 2006, l’utente 2 avvia l’acquisto. Ad esempio in una forma di attuazione l’utente inserisce in un apposito campo sul sito dell’esercente 1 il numero telefonico del dispositivo mobile o un altro codice che permette di identificare l’utente. Di conseguenza, il server dell’esercente riceve ad un passo 1004 il codice identificativo per l’utente.
Di conseguenza, nella forma di attuazione considerata, le fasi di scelta del carrello e l’inserimento del numero telefonico avvengono totalmente nel sito internet dell'esercente 1. L’esperto del ramo apprezzerà che il numero telefonico, o in generale il codice identificato per l’utente, può anche essere precompilato tramite il browser web del dispositivo mobile 2 o essere precompilato dall’esercente 1 nel caso in cui l'utente 2 sia già stato riconosciuto dall'esercente stesso, ad esempio tramite un login al sito dell’esercente 1.
Successivamente, l’esercente 1 trasferisce la richiesta d’acquisto al sistema di gestione 4. Ad esempio, tale trasferimento può essere effettuato direttamente a livello di server, ovvero il server dell’esercente 1 invia la richiesta direttamente al sistema di gestione 4, o indirettamente a livello di client, ovvero i server dell’esercente 1 indica al dispositivo mobile 2 che successivi comunicazioni devono essere indirizzati ad un sito gestito del sistema di gestione 4. Ad esempio, in una forma di attuazione, cliccando su un pulsante “Prosegui†o “Acquista†, il server dell’esercente 1 redirige il browser del dispositivo mobile 2 con il commando “HTTP GET†o “HTTP POST†verso il sistema di gestione 4 allegando il codice dell’utente, quale ad esempio il numero telefono dell’utente, e altri dati che permettono di identificare l’acquisto. Tuttavia, l’inventore ha osservato che per motivi di sicurezza à ̈ opportuno che tali parametri vengano scambiati a livello di server. Infatti, in questo modo, il sistema di gestione 4 può comprendere anche opportuni mezzi, quali ad esempio una firewall, che permettono soltanto accessi da indirizzi IP autenticati, quale ad esempio gli indirizzi IP degli esercenti 1 iscritti all’servizio di pagamento.
Ad esempio, in una forma i parametri possono includere i seguenti dati: - un codice identificativo di transazione e/o un codice identificativo per il carrello di acquisto; almeno il codice di transazione à ̈ un codice univoco per ogni esercente 1 che permette di identificare univocamente l’ordine da processare;
- un codice univoco identificativo per l’esercente;
- il codice identificativo per l’utente, quale ad esempio il numero telefonico del dispositivo mobile 2; e
- l’importo dell’acquisto da autorizzare presso l’operatore di pagamento dell’utente 2.
Preferibilmente, i parametri possono anche includere il tipo di contabilizzazione, quale ad esempio implicita nella richiesta di autorizzazione o esplicita, la data e ora della richiesta, e/o un indirizzo web sul quale inoltrare gli esiti della transazione.
In una forma di attuazione, i parametri includono anche un codice identificativo della tipologia di canale di provenienza della transazione. Ad esempio, in questo caso il sistema di gestione 4 può comprendere un’interfaccia di comunicazione che à ̈ in grado di gestire diversi tipi di richieste di pagamento. Ad esempio, in una forma di attuazione il sistema di gestione può essere configurato per gestire anche richieste di pagamento, in cui l’utente 2 invia all’esercente 1 un messaggio del servizio SMS contenente la richiesta di pagamento.
Ad un passo 4002, il sistema di gestione 4 riceve la richiesta d’acquisto ed elabora la richiesta, verificando i dati ricevuti. Ad esempio, il sistema di gestione 4 può controllare il codice identificativo per l’esercente e/o il codice identificativo per l’utente. Ad esempio, in una forma di attuazione, il sistema di gestione 4 controlla se l’esercente identificato tramite il codice esercente sia attivo. Ad esempio, anche i codici esercenti potrebbero essere salvati nella banca dati 40 e il sistema di gestione potrebbe verificare se la banca dati contenesse il codice esercente. Inoltre, il sistema di gestione 4 può verificare l’iscrizione dell’utente al servizio di pagamento, ad esempio verificare se la banca dati 40 contenesse il numero telefonico indicato dall’utente 2 o un numero telefonico associato al codice utente.
In generale, la banca dati 40 può essere realizzata tramite una singola struttura dati, ad esempio un singola tabella, o potrebbe comprendere una pluralità di tabelle. Inoltre, la banca dati 40 può essere accessibile tramite un unico computer o applicazione per la gestione di banche dati, o può essere distribuita su diversi computer o applicazioni per la gestione di banche dati.
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 dell’utente nella banca dati 40, l’applicazione del sistema di gestione 4 notifica tale errore all’esercente 1, e ad un passo 1006 l’applicazione dell’esercente 1 può inviare all’utente 2 un messaggio di errore ERR1 che indica il fatto che l’utente non sia iscritto al servizio. L’esperto del ramo apprezzerà che anche in questo caso il messaggio può essere trasmesso dal sistema di gestione 4 all’esercente 1 direttamente a livello di server o indirettamente a livello di client, ad esempio reindirizzando il browser dell’utente 2 di nuovo al sito dell’esercente 1. In generale, à ̈ preferibile che tale tipo di trasferimento corrisponda al tipo di trasferimento utilizzato per trasferire i dati tra i passi 1004 e 4002. Ad esempio, in una forma di attuazione, tale messaggio di errore ERR1 può essere visualizzato mediante un sito internet che contiene anche un indirizzo web per l’iscrizione al servizio di pagamento e/o una richiesta di reinserire il codice utente o numero telefonico. Di conseguenza, il server dell’esercente potrebbe ricevere ad un passo 1008 anche un nuovo numero telefonico e la procedura potrebbe proseguire di nuovo al passo di verifica 4002.
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 dell’utente ed eventualmente il suo numero telefonico, l’applicazione del sistema di gestione 4 registra l’operazione da autorizzare in stato pendente ed invia ad un passo 4004 un messaggio, quale ad esempio un messaggio del servizio SMS, al numero telefonico dell’utente, in cui il messaggio comprende un link ad un site internet gestito dal sistema di gestione 4.
Inoltre, in varie forme di attuazione, tale link contiene dati che permettono di identificare il codice di transazione e/o il codice del carrello di acquisto. Preferibilmente, il link contiene anche un codice univoco temporaneo generato dal sistema di gestione 4. Ad esempio, tale codice temporaneo può essere valido solo per un periodo limitato (ad esempio 5 minuti) per evitare che vi siano tentativi di pagamento troppo distanti dalla richiesta dell'ordine.
Di conseguenza, il dispositivo mobile 2 può ricevere al passo 2008 tale link e l’utente può controllare l’indirizzo del link. Inoltre, tale operazione garantisce che l’utente sia realmente in possesso del dispositivo mobile. Infatti, aprendo il link indicato nel messaggio del servizio SMS l’utente autentica implicatamene il numero telefonico del dispositivo mobile 2.
La Figura 5 mostra un diagramma di flusso che riassume le principali operazioni che vengono eseguite dal sistema di pagamento per effettuare il pagamento richiesto.
Come menzionato in precedenza, aprendo il link all’interno del SMS, l’utente viene indirizzato al passo 2010 alla pagina web del sistema di gestione 4.
In una forma di attuazione, tale sito non à ̈ statico ma viene generato in modo dinamico. Ad esempio, il sistema di gestione 4 può essere configurato per analizzare ad un passo 4006 il link ricevuto e controllare, ad esempio, la presenza del codice di transazione e/o del codice del carrello di acquisto, e la presenza del codice univoco temporaneo. Inoltre, in una forma di attuazione, il sistema di gestione 4 controlla se sia stata registrata in precedenza (vedere passo 4004) una rispettiva operazione pendente per il codice di transazione e/o il codice del carrello di acquisto indicato nel link. Il sistema può anche effettuare altri controlli, ad esempio può verificare se il codice temporaneo sia ancora valido o verificare che uno specifico codice carrello sia processato soltanto una volta.
Inoltre, in una forma di attuazione, il sistema di gestione 4 monitora il numero di transazioni associate ad un certo numero telefonico. Ad esempio, all’arrivo di una richiesta di acquisto, il sistema di gestione 4 verifica quanti “record pending†esistono per il numero telefonico, al fine di bloccare provvisoriamente l’account. Ad esempio, un utente potrebbe essere bloccato provvisoriamente se venissero effettuate più di 5 richieste in 5 minuti o più di 10 richieste in una giornata solare, e l’account dell’utente potrebbe tornare attivo soltanto 24 ore dopo. Inoltre, in seguito ad una pluralità di blocchi provvisori potrebbe anche scattare un blocco definitivo dell’account, che potrebbe essere riattivato soltanto con l’intervento “manuale†di un operatore.
Qualora il link inserito non sia valido (uscita “N†del passo di verificare 4006), l’applicazione del sistema di gestione 4 notifica tale errore all’utente 2 inviando all’utente 2 un messaggio di errore ERR2 che indica il fatto che il link non sia valido. Ad esempio, tale messaggio potrebbe essere visualizzato come contenuto della pagina web dinamica, o nel caso in cui l’utente sia stato riconosciuto, il messaggio potrebbe anche essere inviato tramite un messaggio del servizio SMS.
Nel caso in cui il link sia valido (uscita “Y†del passo di verificare 4006), il sistema di gestione 4 genera ad un passo 4008 la pagina di check-out. In varie forme di attuazione, tale pagina visualizza il riepilogo di acquisto contenente, ad esempio, il nome dell’esercente 1 e l’importo totale dell’acquisto. Ad esempio, il sistema di gestione 4 può salvare tali dati relativi al riepilogo di acquisto durante il passo 4004 quando l’operazione da autorizzare viene registrata in stato pendente. In varie forme di attuazione, tale Check-Out-Page viene dimensionata ad hoc a seconda del terminale che va collegandosi al sito. Ad esempio, attraverso la lettura del campo “user-agent†à ̈ possibile rilevare le dimensioni del display e di conseguenza scegliere le impostazioni più adatte al dispositivo mobile dell’utente.
Inoltre viene richiesta la digitazione del codice di sicurezza nella pagina di check-out. Di conseguenza, tale pagine web à ̈ preferibilmente un sito criptato, ad esempio secondo il protocollo HTTPS.
Di conseguenza, ad un passo 4010, il sistema di gestione 4 riceve il codice di sicurezza (inserito dall’utente al passo 2012) ed inoltra la richiesta di autorizzazione all’operatore di pagamento 3 associato all’utente 2. Ad esempio, una volta individuato il codice utente, il sistema di gestione 4 può individuare nella banca dati 40 l’operatore di pagamento associato al rispettivo utente. L’esperto del ramo apprezzerà che l’operatore di pagamento 4 potrebbe anche essere verificato e un rispettivo codice operatore potrebbe essere salvato già al passo 4004.
Di conseguenza, 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. 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 della somma addebitata e gli estremi dell’esercente che ha richiesto il pagamento.
Ad un passo di verifica 4012, 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 4012), l’applicazione del sistema di gestione 4 notifica tale errore all’utente 2, ad esempio inviando un messaggio di errore ERR3 che indica il fatto che l’autorizzazione sia stata negata. Preferibilmente, tale errore viene anche notificato all’applicazione dell’esercente 1. Ad esempio, nella forma di attuazione considerata, l’applicazione del sistema di gestione 4 indirizza l’utente di nuovo al server dell’esercente 1, e ad un passo 1010 il server dell’esercente 1 visualizza una pagine web che contiene il messaggio di errore ERR3. Ad esempio, il browser dell’utente può essere indirizzato mediante i comandi HTTP POST/GET al sito indicato dall'esercente al passo 1004.
Invece, nel caso in cui l’autorizzazione sia stata confermata (uscita “Y†del passo di verificare 4012), l’applicazione del sistema di gestione 4 effettua l’aggiornamento dello stato della transazione da pendente in autorizzata.
Nel caso in cui sia stata richiesta una contabilizzazione implicita (vedere passo 1004), il sistema di gestione 4 inserisce ad un passo 4014 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 3 elabora la richiesta di contabilizzazione e comunica l’esito di tale operazione al sistema di gestione 4.
Ad un passo di verifica 4016, l’applicazione del sistema di gestione 4, ricevuto l’esito della contabilizzazione, verifica il risultato della contabilizzazione.
Nel caso in cui la contabilizzazione sia stata negata (uscita “N†del passo di verificare 4016), l’applicazione del sistema di gestione 4 notifica tale errore all’utente 2, ad esempio tramite un messaggio di errore ERR4 che indica il fatto che la contabilizzazione sia stata negata. Preferibilmente, tale errore viene anche notificato all’applicazione dell’esercente 1. Ad esempio, nella forma di attuazione considerata, l’applicazione del sistema di gestione 4 indirizza l’utente di nuovo al server dell’esercente 1, e ad un passo 1012 il server dell’esercente 1 visualizza una pagine web che contiene il messaggio di errore ERR4.
Invece, nel caso in cui la contabilizzazione sia stata confermata (uscita “Y†del passo di verificare 4016), 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 1014 un messaggio di conferma dell’acquisto all’utente ed autorizza l’erogazione del bene/servizio. Ad esempio, nella forma di attuazione considerata, l’applicazione del sistema di gestione 4 indirizza l’utente di nuovo al server dell’esercente 1, e ad un passo 1014 il server dell’esercente 1 visualizza una pagina web che contiene un riepilogo dettagliato dell’acquisto. Di conseguenza, nella forma di attuazione considerata, la fase di notifica, e quindi di delivery del pagamento o dell'acquisto, à ̈ completamente a carico dell'esercente 1, il quale, dopo aver visualizzato l'esito della transazione, potrebbe anche provvedere all'invio di una ricevuta tramite un messaggio del servizio SMS e/o un’e-mail.
Come menzionato in precedenza, in una forma di attuazione esiste anche 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 4014, 3004, 4016, e 1012 sono puramente opzionali e l’uscita “Y†del passo di verifica 4014 potrebbe portare direttamente al passo 1014.
Inoltre, nella forma di attuazione considerata, la richiesta di pagamento può avere diversi esiti. In una forma di attuazione, tali esiti vengono comunicati all’utente 2 tramite l’esercente 1. Ad esempio, in una forma di attuazione, l’esercente 1 specifica al passo 1004 un singolo indirizzo web sul quale inoltrare l’esito della transazione, e i messaggi dei passi 4002, 4006, 4012, 4016 vengono inviati tutti a tale indirizzo web, ad esempio utilizzando i comandi “HTTP GET†o “HTTP POST†. Ad esempio, in una forma di attuazione i seguenti dati vengono restituiti all’esercente 1:
- il codice identificativo per l’esercente;
- il codice identificativo di transazione e/o il codice identificativo per il carrello di acquisto;
- il codice identificativo per l’utente, quale ad esempio il numero telefonico del dispositivo mobile 2; e
- l’esito dell’autorizzazione.
Preferibilmente vengono anche trasmessi altri dati, quali ad esempio, l’importo dell’acquisto, la data e l’ora della risposta, il tipo della contabilizzazione, e/o l’esito della contabilizzazione.
Preferibilmente, ogni esito comprende un codice identificativo per l’esito, eventualmente la categoria dell’errore, e/o la descrizione dell’esito, quale ad esempio i testi dei messaggi di errore ERR1, ERR2, ERR3, e ERR4.
In una forma di attuazione, per aumentare la sicurezza del sistema, gli esiti della richiesta di pagamento vengono comunicati direttamente a livello server all’esercente 1. Ad esempio, una volta ricevuta una richiesta di pagamento al passo 4002, il sistema di gestione 4 potrebbe notificare in modo asincrono lo stato della richiesta di pagamento. Tali notifiche possono includere, ad esempio, gli esiti positivi e/o negativi, ad esempio, dei passi 4004, 4006, 4010, 4012, 4016. In questo modo, non à ̈ necessario restituire dati alla pagina web indicata, ma l’esercente 1 potrebbe creare il contenuto della pagina web finale in base alle notifiche ricevute dal sistema di gestione 4.
Ad esempio, in una forma di attuazione, soltanto un esisto positivo finale potrebbe essere notificato a livello di server (passo 1014), e il dettaglio di un eventuale esito negativo potrebbe essere comunicato a livello client come descritto in precedenza.
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 à ̈ la possibilità di operare su qualsiasi esercente aderente con un dispositivo mobile dotato di un semplice browser mobile.
Inoltre, nelle forme di attuazione descritte in precedenza, la Check-Out-Page non viene gestita dall’esercente 1, ma dal sistema di gestione 4. Infatti, nella soluzione descritta, il sistema di gestione 4 riceve al passo 1002 una richiesta di pagamento contenente un codice esercente e un codice utente, e determina al passo 4002 se la banca dati 40 comprenda tali codici. Nel caso in cui la banca dati 40 comprenda i codici, il sistema di gestione 4 trasmette al passo 4004 al utente 2 un messaggio del servizio SMS contenente un link con un codice univoco.
Successivamente, ricevuta al passo 2010 una richiesta di accesso al rispettivo sito web, il sistema di gestione 4 può verificare al passo 4006 se la richiesta di accesso comprenda il codice univoco, e nel caso in cui la richiesta di accesso comprenda il codice univoco, il sistema di gestione può visualizzare la Check-Out-Page che contiene un campo per l’inserimento del codice di sicurezza.
Infine, quando il sistema di gestione 4 riceve al passo 2012 il codice di sicurezza, il sistema di gestione 4 può trasmettere la richiesta di autorizzazione all’operatore di pagamento 3 dell’utente 2.
Tuttavia, per esercenti con un certo numero di clienti e operazioni di pagamento, potrebbe essere opportuno che l’utente 2 non lasci mai il sito web gestito dall’esercente 1, ad esempio per aumentare la esperienza utente durante il pagamento. Per questo motivo, parte delle operazioni descritte in precedenza possono anche essere eseguite dall’esercente 1 in collaborazione con il sistema di gestione 4. Ad esempio, a tale scopo possono essere fornite alcuni API (application programming interface) che realizzano parte delle funzioni del sistema di gestione 4 direttamente sui server dell’esercente 1.
Tuttavia, come menzionato in precedenza, in questo modo l’esercente 1 può ottenere accesso al codice di sicurezza dell’utente 2 e pertanto tale soluzione à ̈ consigliabile soltanto per esercenti 1 aventi un certo livello di attendibilità e affidabilità.
Ad esempio, in una forma di attuazione, l’esercente 1 potrebbe inviare direttamente il messaggio del servizio SMS contente il link alla Check-Out-Page, ovvero il passo 4004, e/o gestire la Check-Out-Page, ovvero i passi 4006, 4008 e 4010.
Ad esempio, in una forma di attuazione, per inviare il messaggio del servizio SMS all’utente 2, l’esercente 1 invia una richiesta di pagamento contenente il suo codice esercente e il codice dell’utente che richiede un pagamento al sistema di gestione 4.
Il sistema di gestione 4, ricevuta la richiesta di pagamento, determinare al passo 4002 se la banca dati 40 comprenda il codice esercente e il codice utente.
Tuttavia, in questo caso, il sistema di gestione 4 notifica soltanto l’esito della verifica all’esercente 1 (comprendente eventualmente il numero telefonico dell’utente) e l’esercente 1 trasmette all’utente 2 il messaggio del servizio SMS contenente il link alla Check-Out-Page gestita questa volta dall’esercente 1 stesso. Comunque anche in questo caso, il link comprende un codice univoco.
Pertanto, ricevuta una richiesta di accesso alla Check-Out-Page, l’esercente 1 può verificare se la richiesta di accesso comprenda il codice univoco, e nel caso in cui la richiesta di accesso comprenda il codice univoco, l’esercente 1 può visualizzare la Check-Out-Page che contiene il campo per l’inserimento del codice di sicurezza.
Infine, quando l’esercente 1 riceve il codice di sicurezza tramite la Check-Out-Page, l’esercente 1 inoltra la richiesta di autorizzazione al sistema di gestione 4. Il sistema di gestione 4 può rilevare a sua volta dalla banca dati 40 l’operatore di pagamento 3 dell’utente e trasmettere la richiesta di autorizzazione all’operatore di pagamento 3 dell’utente 2. Preferibilmente, prima di trasmettere la richiesta di autorizzazione all’operatore di pagamento 3, il sistema di gestione 4 verifica se sia stata richiesta un pagamento per la specifica combinazione di codice esercente e codice utente.
Pertanto, in questo caso, la comunicazione à ̈ sincrona e viene avviata dall’esercente 1 che rimane in attesa dell’esito dell’operazione richiesta, ad esempio la richiesta di pagamento che richiede la verifica del codice utente (ovvero il numero telefonico dell’utente 2) e la richiesta di autorizzazione del pagamento.
Infine, anche parte delle operazioni descritte in precedenza con riferimento all’esercente 1 possono essere eseguite dal sistema di gestione 4. Ad esempio, in una forma di attuazione, il sistema di gestione 4 potrebbe gestire soltanto il carello di acquisto (passo 1002) e avviando il pagamento l’utente potrebbe essere indirizzato già al sistema di gestione 4, ovvero l’utente potrebbe inserire il suo codice utente o numero telefonico già su una pagine web gestita dal sistema di gestione 4. Di conseguenza, i passi 1004, 1006 e/o 1008 potrebbero essere eseguiti anche dal sistema di gestione 4.
Naturalmente, fermo restando il principio dell’invenzione, i particolari di costruzione e le forme di realizzazione potranno essere ampiamente variate 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 (10)

  1. RIVENDICAZIONI 1. Procedimento per gestire pagamenti tra una pluralità di esercenti (1) ed una pluralità di utenti comprendete le fasi di: - ricevere (1002) una richiesta di pagamento contenente un codice esercente identificativo per detto esercente (1) e un codice utente identificativo per l’utente (2) che richiede il pagamento; - determinare (4002) se una banca dati (40) comprende detto codice esercente e detto codice utente; - nel caso in cui detta banca dati (40) comprenda detto codice esercente e detto codice utente, trasmettere (4004) a detto utente (2) un messaggio del servizio Short Message Service contenente un link ad un sito web, in cui detto link comprende un codice univoco; - ricevere (2010) da detto utente (2) una richiesta di accesso a detto sito web identificato tramite detto link inviato a detto utente (2); - verificare (4006) se detta richiesta di accesso a detto sito web comprenda detto codice univoco; - nel caso in cui detta richiesta di accesso a detto sito web comprenda detto codice univoco, trasmettere (4008) a detto utente (2) una pagina web che contiene un riepilogo del pagamento da autorizzare, in cui detta pagina web contiene un campo per l’inserimento di un codice di sicurezza associato a detto utente (2); - ricevere (2012) da detto utente (2) tramite detta pagina web il codice di sicurezza associato a detto utente (2); e - recuperare (4010) da detta banca dati (40) un operatore di pagamento (3) associato a detto codice utente, e trasmettere una richiesta di autorizzazione a detto operatore di pagamento (3), in cui detta richiesta di autorizzazione comprende detto codice di sicurezza associato a detto utente (2).
  2. 2. Procedimento secondo la rivendicazione 1, comprendente le fasi di: - ricevere (3002) da detto operatore di pagamento (3) informazioni che permettono di verificare se detta richiesta di autorizzazione à ̈ stata autorizzata, e - trasmettere (4016) dette informazioni che permettono di verificare se detta richiesta di autorizzazione à ̈ stata autorizzata a detto esercente (1).
  3. 3. Procedimento secondo la rivendicazione 1 o la rivendicazione 2, in cui detto codice utente à ̈ un numero telefonico, ed in cui il procedimento include: - trasmettere detto messaggio del servizio Short Message Service a detto numero telefonico.
  4. 4. Procedimento secondo la rivendicazione 1 o la rivendicazione 2, comprendente le fasi di: - recuperare (4010) da detta banca dati (40) un numero telefonico associato a detto codice utente, e - trasmettere detto messaggio del servizio Short Message Service a detto numero telefonico associato a detto codice utente.
  5. 5. Procedimento secondo una delle precedenti rivendicazioni, in cui detta richiesta di pagamento comprende: - un codice identificativo di transazione e/o un codice identificativo per un carrello di acquisto virtuale; - l’importo dell’acquisto da autorizzare presso l’operatore di pagamento dell’utente (2).
  6. 6. Procedimento secondo una delle precedenti rivendicazioni, in cui detta richiesta di pagamento comprende: - un indirizzo web gestito da detto esercente (1) sul quale inoltrare gli esiti della transazione, in cui detti esiti comprendente dette informazioni che permettono di verificare se detta richiesta di autorizzazione à ̈ stata autorizzata.
  7. 7. Procedimento secondo una delle precedenti rivendicazioni, comprendente: - assegnare ad ogni codice univoco una scadenza, e - verificare se il codice univoco compreso in detta richiesta di accesso a detto sito web à ̈ ancora valido.
  8. 8. Procedimento secondo una delle precedenti rivendicazioni, comprendente: - monitorare il numero di richiesta di pagamento che sono associati ad un certo codice utente.
  9. 9. 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 1 a 8.
  10. 10. 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.
IT000861A 2011-09-28 2011-09-28 Procedimento per gestire pagamenti tra una pluralita' di esercenti ed una pluralita' di utenti, relativo sistema per gestire pagamenti e prodotto informatico ITTO20110861A1 (it)

Priority Applications (2)

Application Number Priority Date Filing Date Title
IT000861A ITTO20110861A1 (it) 2011-09-28 2011-09-28 Procedimento per gestire pagamenti tra una pluralita' di esercenti ed una pluralita' di utenti, relativo sistema per gestire pagamenti e prodotto informatico
EP12183535A EP2575098A1 (en) 2011-09-28 2012-09-07 Method for managing payments between a plurality of merchants and a plurality of users, corresponding system for managing payments, and computer program product

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
IT000861A ITTO20110861A1 (it) 2011-09-28 2011-09-28 Procedimento per gestire pagamenti tra una pluralita' di esercenti ed una pluralita' di utenti, relativo sistema per gestire pagamenti e prodotto informatico

Publications (1)

Publication Number Publication Date
ITTO20110861A1 true ITTO20110861A1 (it) 2013-03-29

Family

ID=45373775

Family Applications (1)

Application Number Title Priority Date Filing Date
IT000861A ITTO20110861A1 (it) 2011-09-28 2011-09-28 Procedimento per gestire pagamenti tra una pluralita' di esercenti ed una pluralita' di utenti, relativo sistema per gestire pagamenti e prodotto informatico

Country Status (2)

Country Link
EP (1) EP2575098A1 (it)
IT (1) ITTO20110861A1 (it)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP2924661A1 (en) 2014-03-25 2015-09-30 Movincom Servizi S.p.A. Method for managing issue of an electronic ticket and corresponding system

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
ITUB20160721A1 (it) * 2016-02-12 2017-08-12 Progress Consultant Srl Un metodo per effettuare pagamenti in modo sicuro.

Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP1104973A1 (en) * 1999-12-03 2001-06-06 First Hop Oy A method and a system for obtaining services using a cellular telecommunication system
WO2003014995A1 (en) * 2001-08-07 2003-02-20 Wedison Technologies, Inc. Accounting method by authentication of mobile telecommunication company
FR2844126A1 (fr) * 2002-08-30 2004-03-05 Over The Air Ota Systeme de"jetons"electroniques permettant l'utilisation, l'acces et l'adaptation des services en ligne sur les reseaux de telephones mobiles
GB2399209A (en) * 2003-03-06 2004-09-08 Fortunatus Holdings Ltd Secure transaction system
WO2010004576A1 (en) * 2008-06-13 2010-01-14 Shourabh Shrivastav Real time authentication of payment cards
US20100332391A1 (en) * 2009-06-30 2010-12-30 Khan Khurram Secure authentication between multiple parties

Patent Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP1104973A1 (en) * 1999-12-03 2001-06-06 First Hop Oy A method and a system for obtaining services using a cellular telecommunication system
WO2003014995A1 (en) * 2001-08-07 2003-02-20 Wedison Technologies, Inc. Accounting method by authentication of mobile telecommunication company
FR2844126A1 (fr) * 2002-08-30 2004-03-05 Over The Air Ota Systeme de"jetons"electroniques permettant l'utilisation, l'acces et l'adaptation des services en ligne sur les reseaux de telephones mobiles
GB2399209A (en) * 2003-03-06 2004-09-08 Fortunatus Holdings Ltd Secure transaction system
WO2010004576A1 (en) * 2008-06-13 2010-01-14 Shourabh Shrivastav Real time authentication of payment cards
US20100332391A1 (en) * 2009-06-30 2010-12-30 Khan Khurram Secure authentication between multiple parties

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP2924661A1 (en) 2014-03-25 2015-09-30 Movincom Servizi S.p.A. Method for managing issue of an electronic ticket and corresponding system

Also Published As

Publication number Publication date
EP2575098A1 (en) 2013-04-03

Similar Documents

Publication Publication Date Title
EP3198907B1 (en) Remote server encrypted data provisioning system and methods
US9760886B2 (en) Device provisioning using partial personalization scripts
CN106716916B (zh) 认证系统和方法
US20170046696A1 (en) Automated account provisioning
KR20140125449A (ko) 거래 프로세싱 시스템 및 방법
TW201516904A (zh) 線上結算的方法、裝置及系統
TR201808160T4 (tr) Açık iletişim ağları üzerinden iletime yönelik ödeme verilerinin güvence altına alınmasına yönelik yöntem, cihaz ve sistem.
CN112508548A (zh) 数据交互方法及装置、离线信用支付方法及装置
US20140344157A1 (en) Method and device for carrying out cashless payment
WO2012109184A2 (en) Systems and methods for establishing a communication session between communication devices
JP2008529172A (ja) インターネットベースおよび非インターネットベース取引間の変換システムおよびその方法
WO2017020618A1 (zh) 一种电子资源处理方法、设备
CN111861457B (zh) 支付令牌申请方法、设备、系统和服务器
KR101136509B1 (ko) 결제자의 사전 승인을 이용하는 무선 단말 결제 시스템 및 무선 단말 결제 방법
EP2824628A1 (en) Direct debit procedure
US11023880B2 (en) Online mobile payment system and method using authentication codes
CN102968722B (zh) 一种交易确认的方法和系统
US20150058962A1 (en) System and method of authentication of a first party respective of a second party aided by a third party
ITTO20110861A1 (it) Procedimento per gestire pagamenti tra una pluralita' di esercenti ed una pluralita' di utenti, relativo sistema per gestire pagamenti e prodotto informatico
TWI528302B (zh) System and Method of Application for Wallet
WO2017054050A1 (en) Method for authenticating and authorising a transaction using a portable device
KR20120076654A (ko) 개인 휴대폰 번호를 기반으로 한 카드결제 중계 시스템 및 그 방법
WO2014048319A1 (zh) 安全性信息交互系统、设备及方法
KR20180039470A (ko) 보안 환경 및 보안 암호화 소프트웨어 솔루션 기반 온라인 결제 시스템 및 방법
KR20200135245A (ko) 무선 간편 결제 방법