ITMI20131126A1 - Metodo e sistema per la gestione di transazioni elettroniche - Google Patents

Description

CAMPO TECNICO

La presente invenzione riguarda un metodo e sistema per effettuare transazioni (e.g. pagamenti) elettroniche anche mediante dispositivi mobili, più in particolare un metodo e sistema per realizzare una rete di pagamenti immediati senza la necessità che le due parti (chi emette il pagamento e chi lo riceve) conoscano i dettagli del conto o dello strumento finanziario dell’altra parte.

RETROSPETTIVA TECNICA

Stiamo assistendo a una sempre più massiccia affermazione e diffusione del cosiddetto mobile payment, vale a dire di quei metodi di pagamento istantaneo senza utilizzo di denaro contante, in cui due parti si scambiano un valore finanziario per beni o servizi, tramite un terminale mobile. La diffusione ulteriore di tali metodi di pagamento trova qualche difficoltà per i pagamenti di piccola entità a causa del costo relativamente elevato della transazione rispetto al valore della stessa e alla complessità del meccanismo di pagamento. I tentativi di semplificazione di tali meccanismi devono fare i conti con le esigenze di sicurezza e di affidabilità legate alla trasmissione dei dati.

I tentativi di implementare e diffondere servizi di transazioni elettroniche con autenticazione, accesso e scambio dati si basano solitamente su protocolli universalmente accettati come sicuri (e.g. NFC forum, GSM association, SEPA). Allo stato dell’arte attuale ogni fornitore di servizi deve procedere con un progetto di una specifica di utilizzo e una realizzazione di un client specifico per i terminali mobili (applicazione residente nel terminale mobile); devono inoltre essere predisposti un server (ovvero un’applicazione controparte residente nel sistema di distribuzione del servizio) e un protocollo di comunicazione applicativa tra i componenti sviluppati. Tale approccio può essere dispersivo in termini di risorse e di investimenti, perché è necessario replicare elementi comuni per ogni singola applicazione: sarebbe invece auspicabile strutturare processi d’uso a partire da una base comune (framework proposto) che permetterebbe di ridurre i costi generali e i tempi di implementazione.

Un altro problema degli attuali metodi di pagamento mobile è che non viene prevista una modalità di scambio di denaro (o meglio del suo corrispondente valore) o altri valori finanziari, tra utenti individuali, vale a dire il cosiddetto C2C (“consumer to consumer”), contrapposto al più abituale B2C (“business to consumer”). Per tali scambi è necessario l’intervento di un intermediario finanziario, e.g. banche, carte di credito, circuiti di pagamento. Vanno anche considerati i vincoli normativi imposti dalle varie legislazioni nazionali e le difficoltà derivanti da un’armonizzazione di tali vincoli che permetta al sistema di operare su più nazioni.

Il documento WO2013/028910 descrive un sistema per il trasferimento di fondi dall’utente di un dispositivo mobile a un altro (inclusa la possibilità di trasferimenti C2C). Tale sistema prevede però che i dispositivi mobili (o almeno uno dei due tra pagante e ricevente) siano legati a un operatore di rete mobile che dovrà presumibilmente essere una banca o un provider di servizi telefonici, imponendo in questo modo delle restrizioni e dei requisiti che limitano la flessibilità del sistema.

Lo scopo della presente invenzione è quello di fornire una tecnologia che superi, almeno in parte, gli svantaggi dei sistemi attualmente disponibili.

SOMMARIO DELL’INVENZIONE

A questo risultato si è pervenuti, in conformità della presente invenzione, attraverso la realizzazione di un metodo per effettuare transazioni elettroniche di valori finanziari da un utente richiedente a un destinatario per mezzo di un sistema distribuito comprendente un server, il server avendo accesso a un data base contenente una pluralità di utenti registrati, ognuno degli utenti registrati essendo associato a un profilo contente almeno un identificativo dell’utente e almeno uno strumento finanziario, il server essendo predisposto per stabilire comunicazioni con gli utenti registrati e con i gestori degli strumenti finanziari associati agli utenti registrati, il metodo comprendendo i seguenti passi: il server riceve da parte di un utente richiedente registrato una richiesta di effettuare una transazione finanziaria, la richiesta contendo l’entità della transazione finanziaria e almeno un codice identificativo di un destinatario; il server verifica l’esistenza tra gli utenti registrati di un utente registrato associato all’almeno un codice identificativo di destinatario; a seguito di un esito positivo della verifica, il server invia al gestore dello strumento finanziario dell’utente richiedente registrato l’istruzione di predisporre la transazione finanziaria richiesta a favore dello strumento finanziario associato all’utente destinatario; a seguito di esito negativo della verifica, il server analizza l’almeno un codice identificativo dell’utente destinatario per determinare un indirizzo valido per l’invio di un messaggio automatico; a seguito della determinazione della validità di almeno un indirizzo valido, il server notifica al destinatario i dettagli della richiesta di transazione finanziaria a favore del destinatario.

Vantaggiosamente, il messaggio automatico comprende un’email o un SMS o un messaggio vocale pre-registrato e il passo di determinare un indirizzo valido comprende l’analisi dell’almeno un codice identificativo per verificare se contiene un indirizzo email valido o un numero di telefono valido.

In una realizzazione della presente invenzione a seguito dell’avvenuto invio dell’istruzione di predisporre la transazione finanziaria richiesta, il server invia all’utente registrato destinatario la notifica dell’avvenuta istruzione.

Le comunicazioni con gli utenti registrati avvengono attraverso uno dei seguenti mezzi di comunicazione o una combinazione degli stessi: rete telefonica mobile, Internet, Wi-Fi, BlueTooth, RFID, NFC.

Una volta inviata al gestore dello strumento finanziario dell’utente richiedente registrato l’istruzione di predisporre la transazione finanziaria richiesta, il server può notificare al destinatario l’avvenuta istruzione. Tale notifica può essere effettuata subito oppure solo dopo aver ricevuto conferma dal gestore dello strumento finanziario.

In una realizzazione della presente invenzione, nel caso in cui il destinatario non sia un utente registrato, il server, insieme alla notifica dei dettagli della richiesta di transazione finanziaria a favore del destinatario, offre la possibilità al destinatario di registrarsi come utente registrato per completare la transazione.

Vantaggiosamente il profilo associato a ogni utente registrato contiene una o più delle seguenti informazioni: codice di autorizzazione che il server deve chiedere all’utente richiedente per effettuare una transazione, limite massimo di valore finanziario, disposizioni specifiche legate a tempi e/o destinatari predefiniti.

Le transazioni realizzabili per mezzo del metodo secondo una realizzazione preferita della presente invenzione possono essere di tipo “Consumer to Consumer” (da privato a privato) oppure “Consumer to Business” (da privato a impresa commerciale) oppure “Business to Consumer” (da impresa commerciale a privato). Quando la transazione elettronica è di tipo “Business to Consumer” (da impresa commerciale a privato) il valore finanziario transato può comprendere uno o più delle seguenti categorie: buono sconto, offerte commerciali, cash-back, e-coupon, charity cash-back.

Inoltre, vantaggiosamente, l’utente richiedente è dotato di terminale mobile predisposto per comunicare con il server, direttamente o attraverso dispositivi intermedi, attraverso un canale a grande capacità per lo scambio di dati (e.g. Bluetooth, RFID, Wi-Fi, GSM/GPRS/UMTS) e la connessione avviene attraverso uno di questi canali.

Secondo un’ulteriore realizzazione vantaggiosa della presente invenzione, gli strumenti finanziari comprendono il riferimento a una carta di credito o altre carte di pagamento o un conto corrente bancario. Altri possibili strumenti finanziari comprendono carte prepagate, credito telefonico, coupon, cashback, charity cash-back.

Secondo la presente invenzione si realizzano inoltre un programma per computer, un applicativo software o un prodotto programma che implementino il metodo suddetto, quando vengono eseguiti su un computer, un telefono o qualsiasi apparecchio dotato di capacità di elaborazione dati. Si realizza inoltre un sistema distribuito che implementi il metodo suddetto. Grazie alla presente invenzione è possibile realizzare un sistema flessibile e di facile utilizzo che permetta agli utenti di effettuare transazioni finanziarie veloci e sicure, senza dover conoscere i dettagli del destinatario della transazione. Si superano in questo modo alcuni svantaggi dei sistemi disponibili allo stato dell’arte per i servizi di mobile payment (m-payment), domestico e internazionale, che offrono soluzioni prive di respiro globale (in analogia all’ecosistema di un Circuito carte vero e proprio), non pervasive (quindi delimitate a strumenti specifici, a uno specifico contesto aziendale, o tali da forzare l’adozione di strumenti proprietari quali i wallet o borsellini virtuali), non integrate (intera catena Consumer-Merchant-Banche-Circuiti) e parziali (es. focus sul pagamento e non sull’intero ciclo di vita del processo commerciale).Tipicamente i trasferimenti avvengono con meccanismi «a tempo» (es. bonifici t+1; carta di credito t+n; …) non immediati; al contempo, strumenti innovativi come Paypal rendono necessaria la creazione di borsellini virtuali come meccanismo di pagamento. Un altro vantaggio derivante dalla presente invenzione è quello di permettere lo sfruttamento di componenti esistenti e di non richiedere la predisposizione di una infrastruttura dedicata.

BREVE DESCRIZIONE DELLE FIGURE

Questi e ulteriori vantaggi, scopi e caratteristiche della presente invenzione saranno meglio compresi da ogni tecnico dalla descrizione che segue e dai disegni allegati, relativi a esempi di realizzazione aventi carattere esemplificativo, ma da non intendersi in senso limitativo, nei quali:

- la Figura 1 rappresenta l’architettura generale di un sistema secondo una realizzazione preferita della presente invenzione;

- la Figura 2 mostra schematicamente un computer generico utilizzato nel sistema secondo una realizzazione preferita della presente invenzione;

- la Figura 3 rappresenta schematicamente il modulo principale del sistema secondo una realizzazione preferita della presente invenzione;

- la Figura 4 è una rappresentazione del “villaggio virtuale” secondo una realizzazione preferita della presente invenzione;

- le Figure 5-13 rappresentano schematicamente 9 esempi di possibili utilizzi e implementazioni del sistema secondo la presente invenzione; - la Figura 14 rappresenta schematicamente i passi di un metodo secondo una realizzazione preferita della presente invenzione.

DESCRIZIONE DETTAGLIATA DI REALIZZAZIONI DELL’INVENZIONE Il sistema secondo una realizzazione preferita della presente invenzione comprende una piattaforma per pagamenti e servizi a valore aggiunto che analogamente a un «hub», integra pagamenti e servizi a valore aggiunto erogati dalle Banche aderenti, dal Circuito Interbancario, dai Processor di carte di credito e debito, dagli operatori telefonici, dai Merchant e/o da altri «service provider», al fine di permettere l’erogazione di nuovi servizi in modo semplice e sicuro tramite e.g. pc, smartphone e tablet o altri dispositivi, attraverso e.g. pagine web, «app» o altre interazioni.

In una forma di realizzazione preferita, la piattaforma implementa un «Super-Circuito di pagamento» che affianca e integra i sistemi di pagamento tradizionali veicolando le transazioni per mezzo di un unico dispositivo e consentendo la gestione della disponibilità in «real-time» degli importi movimentati. In una forma di realizzazione preferita lo strumento principale di pagamento è il Conto Corrente bancario, per operazioni sulla stessa banca o da/per banche diverse, ma la piattaforma prevede e integra altri strumenti di pagamento quali Carte di Credito/Debito, Pre-pagate, Credito telefonico, Coupon, Cash-back, Charity Cash-back, etc. Gli utenti del servizio pertanto potranno continuare a utilizzare gli strumenti di pagamento già in uso senza bisogno di sottoscriverne di nuovi e/o specifici.

In una forma di realizzazione preferita, la piattaforma tecnologica è pertanto costituita dai seguenti componenti:

•Impianto tecnologico data center

•Network di connessioni telematiche sicure verso gli aderenti •Sistemi di sicurezza

•Connettori software con i Circuiti Interbancari, i Processor delle carte di credito e i Merchant

•Specifici componenti applicativi («app», Portale, CRM, Gateway, …) Per il corretto funzionamento del sistema, sarà necessario realizzare una opportuna rete di impianti contrattuali e convenzioni commerciali tra gli aderenti all’ecosistema. L’integrazione avviene attraverso modelli architetturali e tecnologie standard, secondo protocolli pre-codificati, che permettono di abbattere i tempi e i costi di attivazione presso le controparti aderenti (Banche, Processor, …).

La piattaforma ha il vantaggio di permettere lo scambio di valori finanziari (e.g. denaro) tra due individui, contrariamente a quanto di solito avviene con i modelli di mobile payment noti allo stato dell’arte e attualmente implementati. Non è però ovviamente escluso il più classico utilizzo tra consumatore ed esercente.

La piattaforma, secondo una forma di realizzazione preferita, prevede due principali ambiti di utilizzo nel proprio ecosistema:

• «C2C» (Consumer-to-Consumer), per il trasferimento di somme di denaro tra Consumer e relativa disponibilità immediata al destinatario

• «C2B» (Consumer-to-Business) per consentire l’acquisto di prodotti e servizi, senza la presenza di un POS fisico, anche tramite pagamento parziale/totale con coupon elettronici; in prima istanza riferito allo «Small Business» (es. piccoli commercianti, professionisti, …) e a grandi operatori «verticali» (es. GDO, Compagnie Petrolifere, …).

Come mostrato schematicamente nella Figura 1 l’architettura secondo una realizzazione preferita della presente invenzione comprende un modulo principale di gestione delle transazioni finanziarie 101 che permette di mettere in relazione tra loro un primo utente 103 (che definiamo richiedente) e un secondo utente 105 (definito destinatario) tra i quali debba intercorrere uno scambio di valori finanziari (e.g. denaro, ma potrebbe anche essere per esempio un buono sconto oppure un coupon di servizi, un biglietto ferroviario o della metropolitana, la prenotazione di un evento teatrale, un ticket sanitario, il pagamento di una bolletta o di un abbonamento/biglietto per servizi di mobilità quale ZTL o parcheggi, il pagamento di un abbonamento periodico (e.g. giornaliero, settimanale, annuale) o “pay per use” di un comprensorio sciistico con verifica e prenotazione contestuale degli importi). Ciascun utente 103 e 105 è associato a uno strumento finanziario (rispettivamente 107 e 109) e tale connessione è conosciuta (o comunque rintracciabile) dal modulo principale 101. Quando l’utente 103 vuole effettuare la transazione finanziaria verso l’utente 105, può semplicemente impartire l’ordine al sistema (o meglio al modulo principale 101, la cui composizione vedremo più avanti), senza dover conoscere gli estremi dello strumento finanziario dell’utente 105, vale a dire l’utente destinatario della transazione finanziaria. L’utente richiedente 103 dovrà semplicemente conoscere l’identificativo con cui l’utente destinatario 105 è conosciuto dal sistema. E’ possibile che l’utente 105 abbia più di un identificativo associato (e.g. numero di telefono, email o anche solo un nickname) che permetteranno al sistema di stabilire univocamente di che utente si tratta e di effettuare la transazione verso lo strumento finanziario precedentemente scelto dall’utente destinatario 105 (e.g. un conto corrente bancario, una carta di credito). A sua volta l’utente richiedente 103 dovrà essere conosciuto dal sistema per mezzo di un identificativo (e possibilmente un mezzo di certificazione, e.g. password) e dovrà avere uno strumento di pagamento (o di emissione del valore da trasmettere) a esso associato, dal quale il sistema possa attingere i fondi necessari per effettuare la transazione.

In un’implementazione preferita della presente invenzione, all’utente 103 potrà essere associato un modulo client che permetta l’interazione con il sistema e con il modulo principale 101; tale modulo client potrebbe per esempio essere un’App installata su un dispositivo portatile (e.g. telefono portatile). Altre realizzazioni sono però possibili: per esempio l’ordine di pagamento potrebbe essere immesso per mezzo di un messaggio (e.g. SMS) o di un’email; un’altra possibilità è che l’evento scatenante la transazione sia il verificarsi di una situazione attesa, per esempio il passaggio di un trasmettitore RFID nelle vicinanze di un ricetrasmettitore abilitato (si veda più avanti l’esempio del pagamento di ski-pass o di parcheggio). Anche l’utente 105 può essere associato a un modulo client (e.g. un telefono portatile) in modo che la transazione gli venga opportunamente notificata: va tenuto presente però che tale passaggio non è strettamente necessario per la riuscita dell’operazione, in altre parole non è indispensabile che il destinatario 105 sia collegato al modulo principale 101 nel momento in cui avviene il trasferimento (in tal caso però ovviamente non può verificare immediatamente l’avvenuto completamento della transazione). Il modulo principale 101 dovrà comprendere una opportuna rete di comunicazione che permetta di interagire con gli utenti (almeno l’utente richiedente 103) e con gli strumenti finanziari 107 e 109; il sistema 101 comprenderà inoltre mezzi per il riconoscimento dell’utente richiedente e l’identificazione dell’utente destinatario (e.g. un data base accessibile online) in modo da poter “prelevare” i fondi dallo strumento associato al richiedente 103 e trasferirli allo strumento associato al destinatario 105. Nell’ipotesi sopra descritta, sia l’utente richiedente 103 che il destinatario105 sono registrati al servizio e noti al sistema 101. Più in generale, mentre il richiedente 103 deve obbligatoriamente essere registrato al servizio e conosciuto dal sistema 101, il destinatario può anche essere sconosciuto al sistema 101: come vedremo in dettaglio più avanti, in tale caso (destinatario sconosciuto), il sistema 101 utilizzerà le informazioni fornite dal richiedente per cercare di mettersi in contatto con il destinatario (e.g. determinando un valido indirizzo email o numero di telefono) e per offrirgli la possibilità di completare la transazione e/o di registrarsi al sistema.

La Figura 2 rappresenta un computer generico utilizzato nel sistema secondo la forma di realizzazione preferita della presente invenzione. Tale descrizione generica comprende qualsiasi apparecchiatura dotata di capacità elaborative, pur con diversi livelli di sofisticatezza e di funzionalità (e.g. computer, terminali mobili, server, router di rete, proxy server). Il computer 250 è composto da diverse unità che sono connesse in parallelo a un bus di sistema 253. In dettaglio, uno o più microprocessori 256 controllano le operazioni del computer; una memoria RAM 259 è utilizzata direttamente come memoria di lavoro dai microprocessori 256, mentre una memoria ROM 262 contiene il codice base per le attività di caricamento iniziale del sistema (bootstrap). Diverse unità periferiche sono connesse a un bus locale 265 per mezzo di interfacce adeguate. In particolare tali unità periferiche possono comprendere una memoria di massa costituita da hard-disk 271 e un lettore per dischetti CD-ROM e/o dischi ottici (e.g. DVD o BlueRay) 274. Inoltre il computer 250 può comprendere dispositivi di input 277 (e.g. tastiera, mouse, track point) e di output 280 (e.g. schermo, stampante). Una scheda di rete (Network Interface Card) 283 è utilizzata per connettere il computer 250 a una rete. Un’unità ponte 286 costituisce l’interfaccia tra il bus di sistema 253 e il bus locale 265. Ogni microprocessore 256 e l’unità ponte 256 possono operare come “master agent” e richiedere l’accesso esclusivo al bus di sistema 253 per trasmettere informazioni. Un arbitro 289 gestisce le richieste di accesso al bus di sistema 253, evitando conflitti tra i richiedenti. Considerazioni simili si applicano a sistemi leggermente diversi o basati su diversi configurazioni di rete. Altre componenti oltre a quelle descritte possono essere presenti in casi specifici e per implementazioni particolari (e.g. computer palmari, telefoni portatili etc.).

La Figura 3 mostra schematicamente la composizione del modulo principale 101 secondo una forma di realizzazione preferita della presente invenzione. Un server controlla tutte le operazioni e comprende un modulo di comunicazione che permette il collegamento attraverso una rete (e.g. GSM, Internet, LAN o una combinazione di queste) con gli utenti: nel caso illustrato in Figura 1 il collegamento è attivo con il richiedente 103 e con il destinatario 105. Il server ha accesso a un database sul quale può reperire tutte le informazioni necessarie ad associare l’identificativo degli utenti con i loro dati che possono comprendere per esempio: numero di telefono, indirizzo email, numero IBAN di conto corrente, numero di carta di credito, eventuali parametri o limiti di utilizzo, istruzioni predefinite, numero di emergenza, password. Gli esperti nel ramo non avranno difficoltà a capire che numerosi accorgimenti e misure di sicurezza potranno essere messe in atto per proteggere i dati dei singoli utenti e per garantire che tali dati non siano accessibili da terzi non autorizzati oltre a rispettare le norme vigenti sulla privacy e sulla riservatezza dei dati. Il server avrà inoltre modo di collegarsi agli strumenti finanziari necessari per completare la transazione, come descritto in riferimento alla Figura 1.

Tale collegamento può essere realizzato in molti modi disponibili allo stato dell’arte; per esempio il collegamento può avvenire tramite rete GSM, UMTS, HSDPA, Wi-Fi, Wi-Fi max, rete cablata, ADSL; un’altra possibilità ancora è l’utilizzo delle cosiddette “drop call”.

Gli utenti per poter utilizzare il metodo secondo una realizzazione preferita della presente invenzione, dovranno registrarsi e fornire uno o più dei dati sopra citati. I singoli utenti si potranno identificare presso il sistema mediante un nome predefinito (nickname) che potrà anche corrispondere al numero di telefono dell’apparato mobile dal quale viene impartito l’ordine o all’indirizzo email dal quale viene inviata la comunicazione. Una volta espletate le procedure di identificazione (che possono anche comprendere la richiesta di una password o di un numero PIN che permetta di convalidare l’identità dell’utente) l’utente che desidera effettuare una transazione (e.g. un trasferimento di denaro) verso un altro utente, dovrà fornire i dettagli della transazione (e.g. importo in denaro) e un dato che permetta di identificare l’utente destinatario della transazione. L’inserimento dei dati potrà avvenire attraverso un terminale (e.g. un computer) anche mobile (e.g. un telefono cellulare o un palmare o tablet) collegato attraverso la rete sopra menzionata al server. Tale identificazione potrà avvenire con varie modalità e potrà anche essere assistita da una possibile interfaccia grafica sul terminale utilizzato che permetta, per esempio, di selezionare un utente tra un numero di possibili utenti. Per fare un esempio tra i tanti possibili, se l’utente richiedente inserisce il cognome del destinatario (assumendo che il destinatario sia una persona fisica registrata e nota al sistema con nome e cognome), l’interfaccia grafica potrebbe fornire una scelta tra possibili soluzioni tra cui l’utente può selezionare il destinatario desiderato. Le possibili combinazioni per l’associazione tra un identificativo e un utente sono numerosissime: la flessibilità che si vuole dare al sistema può essere modificata dall’amministratore del sistema stesso e dipende da quali dati sono disponibili per ogni utente. In una possibile realizzazione della presente invenzione si può prevedere la possibilità di effettuare una transazione (e.g. inviare una somma di denaro) a favore di un utente destinatario che non sia registrato e non sia noto al sistema: in tal caso l’utente richiedente fornirà un contatto (e.g. un numero telefonico o un indirizzo email) con cui comunicare al destinatario l’intenzione del richiedente di effettuare tale transazione (pagamento). Il destinatario potrà decidere se iscriversi al servizio o di aderire una tantum fornendo i dati per il completamento della transazione.

In ogni caso i dati necessari per effettuare la transazione a favore del destinatario devono comprendere uno strumento finanziario che può essere per esempio un conto corrente identificato per mezzo del codice univoco identificativo (e.g. IBAN). Altre possibilità comprendono: carta di credito e debito, carta di credito ricaricabile, SIM ricaricabile, wallet elettronico, voucher e coupon, credito riveniente da “cash back” e da programma di fidelizzazione (“loyalty program”).

Il sistema secondo una realizzazione preferita della presente invenzione abilita la creazione di un «villaggio virtuale» esteso entro cui il Consumer può vivere un’esperienza innovativa di pagamento in aggiunta a convenzioni commerciali particolari. La Figura 4 mostra schematicamente una rappresentazione di questo “villaggio Virtuale”. Con la presente soluzione vengono superate le limitazioni delle attuali soluzioni di mercato, attraverso: - Aggregazione e fruizione da un’unica «app» delle diverse linee di servizio in modo veloce, trasparente e sicuro

- Regolamento immediato in dare/avere su conti, carte di credito, carte di debito, carte prepagate

- Disponibilità immediata dei fondi per il destinatario a fronte della transazione - Utilizzo di strumenti finanziari pre-esistenti (conti correnti Bancari, carte di debito, carte di debito prepagate, carte di credito) in possesso del Consumer e del Merchant senza necessità di introdurre strumenti aggiuntivi (es. borsellino virtuale)

- Trasformazione del conto corrente del Merchant in un «POS virtuale» con in più la disponibilità immediata degli importi e della relativa rendicontazione: transazioni B2C avvengono quindi senza necessità di POS fisico (e dei relativi costi)

Tipologie di servizi possibili

La piattaforma secondo una forma di realizzazione preferita della presente invenzione può essere adattata per innumerevoli utilizzi.

Solo come esempio segnaliamo le seguenti «linee» di servizi che possono essere realizzati e offerti in modo integrato e trasparente:

•pagamenti tra privati con trasferimento di importi tra privati;

•pagamenti e servizi a valore aggiunto con i Merchant per i pagamenti di acquisto di prodotti/servizi verso un Merchant

•pagamenti di acquisto di prodotti/servizi su un sito di e-commerce di un Merchant aderente

•gestione e fruizione di buoni sconto elettronici (e-coupon) emessi dai Merchant convenzionati nel contesto di promozioni commerciali gestite attraverso la piattaforma, fruibili in modalità georeferenziale dai Consumer nel contesto del pagamento di prodotti/servizi verso il Merchant

• versamento di contanti da parte di un Consumer presso uno dei Merchant convenzionati, analogamente a quanto avverrebbe in uno sportello Bancario, con la possibilità innovativa di gestirne l’eventuale storno

•Pagamenti di ticket per servizi basati su ticketing (es. trasporti, parcheggi, ZTL, parco divertimenti)

• pagamento di skipass presso gli ski-resort convenzionati in modalità innovativa («pay-per-use», abbonamenti, …) e di valore aggiunto per l’utente (es. assenza code).

Vantaggi principali del sistema secondo una forma di realizzazione preferita della presente invenzione dal punto di vista del «Consumer»:

•Iscrizione al servizio per il tramite di una «app» o del portale dove vengono indicati e certificati in modo sicuro gli strumenti finanziari per il regolamento dei pagamenti (es. conti correnti Bancari e carte)

•Il funzionamento avviene in modo sicuro attraverso la «app» che consente di effettuare le disposizioni di pagamento identificando il destinatario attraverso il numero di telefono ed evitando pertanto al mittente di dover conoscere e digitare le coordinate degli strumenti di pagamento del destinatario; per conseguenza, tali informazioni non transitano in rete •Semplicità del pagamento con pochi dati essenziali: nel caso di pagamento cash, è sufficiente selezionare il destinatario dalla propria rubrica, digitare l’importo (ed eventualmente una nota) e il PIN dispositivo. Altri servizi di pagamento (es. ticket e ski) richiedono dati aggiuntivi necessari allo specifico ambito di utilizzo

•Gli importi trattati sono di entità limitata e secondo un numero massimo di operazioni giornaliere, in funzione anche del servizio utilizzato (es. cash vs. ski)

Vantaggi principali del sistema secondo una forma di realizzazione preferita della presente invenzione nell’ambito «Merchant»:

•Per il Consumer:

•Opzione di acquisizione automatica dei dati del destinatario (es. lettura Bar Code, QR Code o Matrix Code, Tag NFC, …) contestualmente all’operazione (es. pagamento taxi)

•Per il Merchant:

•Virtualizzazione del POS, data dalla trasformazione del conto corrente in strumento virtuale

•Apertura a nuovi servizi per la clientela

•Disponibilità per lo small business di strumenti per la promozione commerciale (CRM) con logiche di georeferenziazione (es. e-coupon, campagne, …) a oggi non sostenibili per la loro dimensione, aprendo di fatto un nuovo Circuito di opportunità commerciali; per i grandi operatori verticali gli strumenti si limitano alla gestione/fruizione degli e-coupon (in quanto per dimensione, già beneficiano di strumenti propri di CRM) •L’ adozione dei canali social, offre l’opportunità di incrementare la propria base clienti secondo il principio del passa-parola esponenziale (es. un Consumer con 100 contatti in rubrica, per ogni contatto può a sua volta generarne altri 100 e così via; in un passaggio in cascata su tre contatti tra Consumer, il potenziale è di 100x100x100, quindi 1M di potenziali clienti) Verranno ora forniti i dettagli di un’implementazione particolare del sistema secondo la presente invenzione. Tale sistema è stato denominato Piattaforma di Pagamento (o anche solo Piattaforma) e per comodità ci si riferirà a esso in questo modo nel prosieguo della descrizione. Resta inteso che i dettagli implementativi sono riferiti a una delle tante possibili realizzazioni del metodo e sistema della presente invenzione.

Le Figure 5-13 illustrano la sequenza di attività di una possibile applicazione del metodo secondo una forma di realizzazione preferita della presente invenzione.

Gli esempi di seguito riportati rappresentano alcuni «casi d’uso» significativi per la comprensione delle capacità e potenzialità della Piattaforma. In particolare:

•Esempio 1 – Piattaforma-cash illustrato in Figura 5: come avviene un trasferimento di denaro tra privati:

Passo 1: L’utente richiedente seleziona dalla propria rubrica il destinatario del trasferimento;

Passo 2: Il sistema recupera in automatico i dati anagrafici corrispondenti al numero di telefono del destinatario selezionato;

Passo 3: L’utente richiedente conferma la prosecuzione dell’operazione e inserisce importa, una nota e il PIN;

Passo 4: Il sistema esegue la disposizione e invia l’esito tramite un messaggio di notifica sia all’utente richiedente sia al destinatario;

Passo 5: L’utente richiedente riceve conferma dell’avvenuta disposizione di pagamento con esito positivo; il destinatario riceve la notifica dell’avvenuto accredito.

•Esempio 2 – Piattaforma-cash illustrato in Figura 6: come avviene un trasferimento di denaro tra privati, dove però il destinatario non ha ancora aderito al servizio

Passo 1: L’utente richiedente seleziona dalla propria rubrica il destinatario del trasferimento;

Passo 2: Il sistema verifica il numero telefonico selezionato, ma segnala che il destinatario non è registrato al servizio;

Passo 3: L’utente richiedente conferma la prosecuzione dell’operazione e inserisce importa, una nota e il PIN;

Passo 4: Il sistema esegue la disposizione trasferendo l’importo su un conto temporaneo (per un periodo max e.g. 5 giorni). Contestualmente invia un messaggio con l’esito dell’operazione all’utente richiedente e un SMS di invito al destinatario per aderire al servizio a seguito dell’importo accreditatogli; Passo 5: L’utente richiedente riceve conferma dell’avvenuta disposizione di pagamento con esito positivo; il destinatario riceve la notifica dell’avvenuto accredito e l’invito ad aderire al servizio entro un periodo prestabilito (e.g. 5 giorni). Se il destinatario non aderisce al servizio, l’importo viene riaccreditato all’utente richiedente, con relativo messaggio di notifica per entrambi.

•Esempio 3 - Piattaforma-e-commerce illustrato in Figura 7: come avviene il pagamento di un prodotto acquistato su Internet dal sito e-commerce di un Merchant convenzionato

Passo 1: L’utente richiedente seleziona un prodotto da acquistare sul sito di un Merchant convenzionato e richiede Piattaforma come metodo di pagamento, unitamente al proprio numero di telefono;

Passo 2: Il sito del Merchant invia a Piattaforma i dati della transazione (numero di telefono utente, ID Merchant, ID transazione, importo, data, articolo). Piattaforma verifica i dati e invia una notifica di pagamento all’utente richiedente;

Passo 3: L’utente richiedente conferma la prosecuzione e il sistema gli invia i dati completi della transazione;

Passo 4: Viene visualizzata all’utente richiedente una pagina completa di tutti i dati della transazione; l’utente richiedente inserisce il PIN e conferma l’operazione;

Passo 5: Il sistema esegue la disposizione e invia l’esito tramite un messaggio di notifica sia all’utente che al destinatario (il Merchant);

Passo 6: il sito visualizza l’avvenuta transazione con esito positivo, dando seguito all’ordine; l’utente richiedente riceve conferma dell’avvenuta disposizione di pagamento con esito positivo.

•Esempio 4 – Piattaforma-coupon illustrato in Figura 8: come avviene la produzione, distribuzione di buoni sconto verso due Consumer che hanno aderito al servizio e-coupon in modo differenziato

Passo 1: L’utente richiedente (il Merchant in questo caso) configura e richiede al sistema l’emissione di un set di e-coupon valido per tutti i punti vendita di Milano e Cagliari;

Passo 2: Il sistema processa l’e-coupon e lo confronta con le regole dei Consumer che aderiscono al servizio per valutarne la distribuzione; il servizio lo invia a <Consumer 1> (e.g. match su residenza a Milano), ma non a <Consumer 2> (nessun match);

Passo 3: Consumer 1 (destinatario) riceve la notifica della disponibilità di un buono sconto;

Passo 4: Nel frattempo Consumer 2 (destinatario) si reca da Verona a Milano e invia una richiesta al sistema con le proprie coordinate geografiche per verificare quali e-coupon siano disponibili sulla specifica tipologia di Merchant nel raggio di 10 Km; il sistema invia i dati e le informazioni georeferenziali; Passo 5: Consumer 2 visualizza in “augmented reality” e poi su mappa le coordinate per l’utilizzo del buono sconto.

•Esempio 5 – cash-me e Piattaforma-coupon illustrato in Figura 9: come avviene il pagamento di un prodotto con l’utilizzo combinato cash e buono sconto

Passo 1: L’utente richiedente seleziona dalla propria rubrica il destinatario del pagamento che era anche stato segnalato per la presenza di un buono sconto in scadenza;

Passo 2: Il sistema recupera in automatico i dati anagrafici corrispondenti al numero telefonico del destinatario selezionato;

Passo 3: L’utente richiedente conferma la prosecuzione dell’operazione e inserisce l’importo della spesa di 100€, seleziona l’uso del buono da 20€, digita il PIN e conferma il pagamento di 80€;

Passo 4: Il sistema esegue l’annullo del buono sconto e la disposizione di pagamento; invia l’esito tramite un messaggio di notifica sia all’utente richiedente sia al destinatario;

Passo 5: L’utente richiedente riceve conferma dell’avvenuta disposizione di pagamento con esito positivo; Il destinatario riceve la notifica dell’avvenuto accredito.

•Esempio 6 – Piattaforma-ski illustrato in Figura 10: come avviene il pagamento di una giornata sulle piste da sci di uno Ski Resort;

Passo 1: Il cliente (utente richiedente) accede immediatamente ai gate con la propria carta Skipass ed effettua il primo passaggio;

Passo 2: Il gate tramite il server del gestore impianto (destinatario) chiama Piattaforma-ski chiedendo l’autorizzazione ad addebitare la carta per l’importo max convenzionato di uno skipass giornaliero;

Passo 3: Se la risposta di Piattaforma-ski è OK viene creato un impegno per bloccare sul rapporto l’importo. Vengono aggiornati i gate dell’impianto per consentire il passaggio dell’utente richiedente;

Passo 4: A fine giornata l’applicazione del gestore impianto chiama Piattaforma-ski per comunicare l’effettivo utilizzo dello skipass (es.3 ore); Passo 5 Piattaforma-ski provvede a cancellare l’impegno e ad addebitare il rapporto con l’importo dovuto per l’effettivo utilizzo degli impianti; invio di un messaggio di notifica all’utente richiedente dell’avvenuto addebito;

Passo 6: L’utente richiedente riceve il messaggio di avvenuto addebito.

•Esempio 7 – Piattaforma-ticket illustrato in Figura 11: come avviene il pagamento di una giornata in un Parco Natura per una famiglia

Passo 1: Dalla rubrica dei servizi Piattaforma-ticket l’utente richiedente seleziona l’ingresso al Parco Natura (destinatario);

Passo 2: Piattaforma-ticket comunica con l’applicativo di biglietteria del parco e restituisce le informazioni per l’acquisto dei biglietti di ingresso;

Passo 3: L’utente richiedente seleziona i biglietti e conferma l’acquisto;

Passo 4: Piattaforma-ticket regola il pagamento sui rapporti e conferma l’operazione inviando anche un messaggio all’utente richiedente; l’applicativo del parco invia i 3 QR CODE per l’ingresso;

Passo 5: Utente richiedente riceve messaggio: “Hai ricevuto un addebito di 35€ per l’ingresso al Parco Natura”;

Passo 6: L’utente richiedente accede immediatamente ai gate e visualizza i QR Code che consentono l’ingresso al Parco.

•Esempio 8 – Piattaforma-ticket illustrato in Figura 12: come avviene il pagamento della sosta in un parcheggio convenzionato

Passo 1: Per fruire del servizio, l’utente richiedente deve avere preventivamente abbinato il proprio profilo Piattaforma-ticket a una o più targhe.

Dalla rubrica dei servizi Piattaforma-ticket l’utente richiedente digita il codice identificativo del parcheggio (destinatario), oppure lo acquisisce tramite lettura di QR code o NFC, seleziona la vettura e l’ora di fine sosta;

Passo 2: Piattaforma-ticket richiede al server del gestore del Parcheggio il costo della sosta e quindi regola il pagamento sui rapporti e conferma l’operazione inviando un messaggio all’utente richiedente;

Passo 3: Dieci minuti prima del termine della sosta, Piattaforma-ticket avvisa l’utente richiedente della scadenza proponendo un eventuale rinnovo per il “Parcheggio1”.

•Esempio 9 – cash-me illustrato in Figura 8: come avviene il versamento di contanti presso un Merchant convenzionato

Passo 1: L’utente richiedente si reca presso un Merchant convenzionato (destinatario) per il versamento di contanti;

Passo 2: Il Merchant registra l’utente richiedente sulla propria rubrica e chiede i dati anagrafici a Piattaforma;

Passo 3: Il sistema recupera in automatico i dati anagrafici corrispondenti al numero telefonico del destinatario selezionato;

Passo 4: Il Merchant verifica la corrispondenza dei dati anagrafici rispetto al documento di identità dell’utente richiedente e inserisce importo, una nota e il PIN;

Passo 5: Il sistema esegue la disposizione, trasferendo l’importo dal conto/carta del Merchant al conto/carta dell’utente richiedente. Invia l’esito tramite un messaggio di notifica sia al Merchant sia all’utente richiedente; Passo 6: Il Merchant riceve la notifica dell’avvenuta disposizione con esito positivo; L’utente richiedente riceve conferma dell’avvenuta disposizione di accredito con esito positivo.

Il diagramma di Figura 14 mostra schematicamente la sequenza di passi del metodo secondo una forma di realizzazione preferita della presente invenzione. Il metodo è volto all’effettuazione di transazioni elettroniche di valori finanziari (e.g. denaro, ma non solo come già accennato sopra) da un utente richiedente a un destinatario (normalmente entrambi sono iscritti a un servizio, ma per il destinatario ciò non è indispensabile); il metodo è implementato e funziona su un sistema distribuito incentrato su un server che riceve le richieste ed effettua le operazioni. Il server deve avere accesso a un data base in cui sono registrati gli utenti (almeno quelli richiedenti): sul data base a ogni utente registrato viene associato un profilo che deve comprendere un identificativo (ci possono essere più identificativi per uno stesso utente, ma non più utenti con uno stesso identificativo) e uno strumento finanziario su cui addebitare o accreditare i valori finanziari oggetto della transazione. Il server è predisposto per comunicare con gli utenti registrati e con i gestori degli strumenti finanziari (e.g. banche, istituti di carte di credito). Il metodo inizia con il passo 1401 in cui il server riceve una richiesta da parte di un utente registrato (se non è registrato, la richiesta non può essere soddisfatta) di effettuare una transazione finanziaria dallo strumento finanziario associato al richiedente (e.g. conto corrente) verso un destinatario: la richiesta deve contenere l’entità della transazione finanziaria da effettuare e un codice che permetta di identificare il destinatario. Nel caso più semplice, il destinatario sarà un utente registrato del metodo di pagamento secondo una realizzazione della presente invenzione: il server quindi esegue una verifica (scelta 1403) e, in caso dia esito positivo (1405), recupera i dati del destinatario (e.g. il codice IBAN del conto corrente) e invia (passo 1407) al gestore dello strumento finanziario del richiedente (una banca nell’esempio presente) la richiesta di effettuare un bonifico sul conto del destinatario. Più in generale, viene istruito il gestore dello strumento finanziario associato al richiedente di effettuare la transazione finanziaria richiesta, verso lo strumento finanziario associato al destinatario (che in questo caso è utente registrato al pari del richiedente). Se invece la verifica dell’esistenza del destinatario tra gli utenti registrati desse esito negativo, si va al passo 1409, in cui il server cerca di estrarre dall’identificativo del destinatario le informazioni necessarie per inviare una comunicazione che notifichi al destinatario i dettagli della richiesta di transazione finanziaria a suo favore emessa dal richiedente. Ci possono essere varie modalità per l’effettuazione di questa notifica e dipendono da come è stato predisposto il sistema. L’identificativo può includere un indirizzo email o un numero di telefono o entrambi. In ogni caso il server verifica (scelta 1411) la validità dell’indirizzo o numero di telefono (o altra modalità per inviare un messaggio): se non è in grado di inviare una comunicazione al destinatario, la transazione non può essere completata e una comunicazione potrebbe essere inviata al richiedente per informarlo dell’impossibilità di completare la transazione e di contattare il destinatario. Nel caso invece il destinatario possa essere raggiunto, il messaggio potrebbe contenere l’invito a registrarsi al sistema di cui alla presente invenzione per completare la transazione e ricevere i valori finanziari in questione (passo 1413). In ogni caso il metodo si conclude con la comunicazione dell’esito della transazione al richiedente e, se possibile, al destinatario (passo 1415).

Nel seguito vengono analizzati alcuni aspetti specifici legati a una o più implementazioni particolari o vengono ipotizzate alcune soluzioni che sono fornite solo a titolo di esempio.

Profili contrattuali e di compliance della Piattaforma

•L’utente sottoscriverà una accettazione del servizio nei confronti di Piattaforma inclusivo dei termini della privacy relativi all’acquisizione delle coordinate GPS (Global Positioning System, necessario per le operazioni di tipo georeferenziale);

•Le regole proprie di utilizzo dei rapporti che prendono parte alla transazione (carte credito, debito, rapporto di conto corrente, …) rimangono invariate e sono «trasparenti» a Piattaforma, essendo a carico del detentore del rapporto Bancario (Banca o Circuito) che ne conserva la titolarità, i controlli di compliance dal punto di vista normativa antiriciclaggio relativamente all’adeguata verifica della controparte e agli adempimenti segnaletici di carattere obbligatorio.

La Sicurezza di Piattaforma

•Garantisce la sicurezza dei dati relativi ai propri strumenti di pagamento; •Consente l’esecuzione sicura delle transazioni con verifica univoca del dispositivo e del destinatario contestualmente all’esecuzione della transazione stessa;

•Monitoraggio continuo della sicurezza 24x7 tramite Nucleo Operativo Sicurezza Piattaforma e meccanismi di Alert (es. a fronte di eventi di pagamento o di superamento di soglie di importo su un determinato periodo di riferimento);

L’ecosistema «Piattaforma-village» è caratterizzato dalla presenza dei seguenti attori:

•Consumer e Merchant che effettuano e ricevono pagamenti tramite la «app»;

•Il Service Provider, responsabile dell’erogazione del servizio, della gestione tecnica, operativa, commerciale e della sicurezza. Veicola le transazioni di pagamento ai Circuiti di destinazione e/o alle Banche aderenti. Questo ruolo può essere svolto da soggetti diversi:

•NewCo: nasce con la specifica finalità di erogare i servizi Piattaforma;

•Processor Carte: estende il proprio ambito di intervento ai servizi Piattaforma, beneficiando di infrastrutture tecnologiche, accordi e convenzioni già in essere;

•Operatori Telco: estensione del proprio business ai servizi innovativi e pervasivi di pagamento Piattaforma, beneficiando delle infrastrutture e delle competenze tecnologiche già in essere;

•Le Controparti Convenzionate, ovvero le controparti finanziarie (Banche, Circuiti, …) che si convenzionano sul Circuito Piattaforma e le cui architetture informatiche vengono integrate per l’esecuzione delle transazioni di pagamento.

I pagamenti vengono estremamente semplificati con la Piattaforma e possono essere effettuati mediante la propria rubrica telefonica senza dover conoscere le coordinate Bancarie/PAN del destinatario.

Questi sono alcuni dei vantaggi realizzabili con la Piattaforma:

•Trasferimento di una somma di denaro tramite «app» sul proprio smartphone con accredito immediato del denaro;

•Pagamento del prodotto/servizio in un negozio tramite «app» sul proprio smartphone e fruizione di uno sconto ricevuto nell’ambito di una promozione virtuale dell’esercente;

•Disponibilità di buoni sconto «intelligenti» effettivamente fruibili che tengono conto del luogo in cui ci si trova, del giorno, della tipologia di acquisto che il Consumer deve fare;

•Creazione di promozioni virtuali per commercianti che non dispongono di sistemi informativi e CRM avanzati;

•Accessi ad aree (es. parcheggi, ZTL, …) attraverso gate di riconoscimento e addebito automatico in logica «pay-per-use»;

•Accesso immediato agli impianti sciistici senza code, e con pagamento del solo effettivo utilizzo;

•Reintegro automatico di disponibilità (es. biglietti mezzi pubblici) a fronte del raggiungimento di una soglia (es. sono rimasti solo 2 biglietti); Piattaforma: Modulo Consumer

L’utente Consumer ha a disposizione le seguenti funzioni, sia «core» che di tipo «accessorio»:

1)Tramite la «app»:

2) Tramite Social Network

3) Tramite Portale Piattaforma

Piattaforma: Modulo Merchant

L’utente «Merchant» oltre alle funzioni disponibili per l’utente Consumer (in quanto a sua volta può essere anche Consumer) ha a disposizione le seguenti funzioni:

1) Funzione social shopping mediante e-coupon

2) Funzione e-commerce

3) Funzione advertising

4) Statistiche commerciali

5) Profili tariffari

6) Consultazione estratto conto servizi

Piattaforma: Modulo Service Provider

Il Service Provider ha a disposizione, in aggiunta agli strumenti tipici per la gestione aziendale, tutti quelli necessari per l’erogazione del servizio, la gestione operativa dell’intera piattaforma, il presidio della sicurezza e lo sviluppo commerciale, secondo i seguenti macro-moduli principali:

1) Gestione del Servizio

2) Gestione della Sicurezza

3) Gestione Commerciale e Customer Care

4) Gestione Amministrativa

5) Monitoraggio e Controllo del servizio

Piattaforma: Modulo Social

E’ un modulo applicativo aggiuntivo opzionale e complementare di gestione cash-back (anche nella forma couponing) e Charity Cash-Back attraverso movimenti effettuati avvalendosi dei servizi di base Piattaforma-cash e Piattaforma-ecommerce, ovvero in modo complementare attraverso movimenti di moneta elettronica effettuati su banca issuer, acquiring o circuito con utilizzo di apposite «app» appoggiate a uno o più social network

Piattaforma: gestione disponibilità e regolamento contabile

Il regolamento può avvenire in modo interscambiabile tra le seguenti tipologie di strumenti:

•Conto Corrente (rif. IBAN);

•Carta di Credito/Pre-Pagata/Debito su Circuito internazionale (rif. PAN) La Ricarica Telefonica, alla data, può essere solo beneficiaria di un trasferimento. Da valutare con gli Operatori Telco l’opportunità di utilizzare la carta telefonica come mittente di un trasferimento.

Il «borsellino e-coupon», alimentato dai diversi Merchant convenzionati, può essere solo mittente, ovvero pagamento in toto o in parte di un prodotto/servizio dello specifico Merchant o di raggruppamenti di Merchant (es. complementary coalition)

La gestione disponibilità e regolamento contabile , avviene sempre in 4 Fasi principali:

•Fase 1: Ordine di pagamento

•Fase 2: Verifica della Disponibilità

•Fase 3: Notifica esito operazione

•Fase 4: Regolamento Contabile (tramite flussi SETIF)

Piattaforma: la sicurezza della piattaforma

La sicurezza complessiva della piattaforma viene garantita secondo i seguenti princìpi cardine:

•Nel contesto della sottoscrizione del servizio:

1. Controllo della veridicità degli strumenti di pagamento

•Nel contesto della disposizione di pagamento:

2. Controllo dell’identità del mittente attraverso l’abbinamento smartphone/legittimo proprietario: per esempio il sistema genera una chiave univoca «client» data dall’ID utente e di un token associato al dispositivo. Permetterà il riconoscimento dell’utente-device nello scambio dati con la piattaforma Piattaforma. Un determinato utente può quindi operare solo da un dato device (a meno di nuova sottoscrizione al servizio). Analogamente, il sistema genera un token «server» che verrà abbinata al token «device». Permetterà il riconoscimento univoco del server Piattaforma nello scambio dati con il device.

3. Disposizioni di pagamento con identificazione del destinatario attraverso il numero di telefono, evitando pertanto al mittente di doverne conoscere e digitare le coordinate di pagamento. Inoltre le coordinate del mittente e del destinatario non transitano in rete.

4. Controllo sulla correttezza del numero telefonico del destinatario:

5. Digitazione di un PIN memorizzato nella «app» solo localmente sullo smartphone:

6.Monitoraggio e controllo del servizio.

In pratica i particolari di esecuzione possono comunque variare in maniera equivalente per ciò che attiene ai singoli elementi costruttivi descritti e illustrati e alla natura dei materiali indicati senza per questo uscire dall’idea di soluzione adottata e perciò restando nei limiti della tutela conferita dal presente brevetto. Un esperto tecnico del ramo può apportare alla soluzione sopra descritta molte modifiche al fine di soddisfare requisiti locali o specifici. In particolare, dovrebbe essere chiaro che, pur avendo fornito dettagli implementativi riferiti a una o più forme di realizzazione preferite, possano essere applicate omissioni, sostituzioni o variazioni di alcune caratteristiche specifiche o di alcuni passi del metodo descritto a seguito di esigenze di progettazione o di realizzazione.

A titolo d’esempio le strutture hardware possono assumere sembianze diverse o comprendere diversi moduli; con il termine computer si ricomprende qualsiasi apparato (e.g. telefoni, palmari) dotato di una capacità elaborativa per l’esecuzione di programmi software o di parti di essi. I programmi possono essere strutturati in maniera diversa o essere implementati in qualsiasi forma. Allo stesso modo le memorie possono assumere molteplici forme realizzative o essere sostituite da entità equivalenti (non necessariamente costituite da supporti tangibili). I programmi possono assumere qualsiasi forma adatta a eseguire le relative funzioni e possono essere scritti in qualsiasi linguaggio di programmazione o presentati in forma di software, firmware o microcode, sia in codice oggetto che in codice sorgente. I programmi stessi possono essere immagazzinati su qualsiasi tipo di supporto purché sia leggibile da computer; a titolo di esempio i supporti possono essere: dischi fissi, dischi rimovibili (e.g. CD-ROM, DVD o Blue Ray Disc), nastri, cartucce, connessioni wireless, reti, onde di telecomunicazione; i supporti possono essere per esempio di tipo elettronico, magnetico, ottico, elettromagnetico, meccanico, a infrarossi o semiconduttori. In ogni caso la soluzione secondo la presente invenzione si presta a essere implementata per mezzo di software, di hardware (anche integrato in chip o materiali semiconduttori) oppure una combinazione di hardware e software.

Claims (14)

1. RIVENDICAZIONI 1. Metodo per effettuare transazioni elettroniche di valori finanziari da un utente richiedente a un destinatario per mezzo di un sistema distribuito comprendente un server, il server avendo accesso a un data base contenente una pluralità di utenti registrati, ognuno degli utenti registrati essendo associato a un profilo contente almeno un identificativo dell’utente e almeno uno strumento finanziario, il server essendo predisposto per stabilire comunicazioni con gli utenti registrati e con i gestori degli strumenti finanziari associati agli utenti registrati, il metodo comprendendo i seguenti passi: - il server riceve da parte di utente richiedente registrato una richiesta di effettuare una transazione finanziaria, la richiesta contendo l’entità della transazione finanziaria e almeno un codice identificativo di un destinatario; - il server verifica l’esistenza tra gli utenti registrati di un utente registrato associato all’almeno un codice identificativo di destinatario; - a seguito di un esito positivo della verifica, il server invia al gestore dello strumento finanziario dell’utente richiedente registrato l’istruzione di predisporre la transazione finanziaria richiesta a favore dello strumento finanziario associato all’utente destinatario; - a seguito di esito negativo della verifica, il server analizza l’almeno un codice identificativo dell’utente destinatario per determinare un indirizzo valido per l’invio di un messaggio automatico; - a seguito della determinazione della validità di almeno un indirizzo valido, il server notifica al destinatario i dettagli della richiesta di transazione finanziaria a favore del destinatario.
2. 2. Metodo secondo la rivendicazione 1, in cui il messaggio automatico comprende un’email e il passo di determinare un indirizzo valido comprende l’analisi dell’almeno un codice identificativo per verificare se contiene un indirizzo email valido.
3. 3. Metodo secondo una delle rivendicazioni precedenti, in cui il messaggio automatico comprende un SMS o un messaggio vocale preregistrato e il passo di determinare un indirizzo valido comprende l’analisi dell’almeno un codice identificativo per verificare se contiene un numero di telefono valido.
4. 4. Metodo secondo una delle rivendicazioni precedenti, ulteriormente comprendente il passo di: - a seguito dell’avvenuto invio dell’istruzione di predisporre la transazione finanziaria richiesta, il server invia all’utente registrato destinatario la notifica dell’avvenuta istruzione.
5. 5. Metodo secondo una delle rivendicazioni precedenti, in cui le comunicazioni con gli utenti registrati avvengono attraverso uno dei seguenti mezzi di comunicazione o una combinazione degli stessi: rete telefonica mobile, Internet, Wi-Fi, BlueTooth, RFID, NFC.
6. 6. Metodo secondo una delle rivendicazioni precedenti, in cui il server, una volta inviata al gestore dello strumento finanziario dell’utente richiedente registrato l’istruzione di predisporre la transazione finanziaria richiesta, notifica al destinatario l’avvenuta istruzione.
7. 7. Metodo secondo la rivendicazione 6 in cui la notifica al destinatario dell’avvenuta istruzione viene effettuata solo dopo aver ricevuto conferma dal gestore dello strumento finanziario.
8. 8. Metodo secondo una delle rivendicazioni precedenti in cui il server, insieme alla notifica al destinatario dei dettagli della richiesta di transazione finanziaria a favore del destinatario, offre la possibilità al destinatario di registrarsi come utente registrato per completare la transazione.
9. 9. Metodo secondo una delle rivendicazioni precedenti, in cui il profilo associato a ogni utente registrato contiene una o più delle seguenti informazioni: codice di autorizzazione che il server deve chiedere all’utente richiedente per effettuare una transazione, limite massimo di valore finanziario, disposizioni specifiche legate a tempi e/o destinatari predefiniti.
10. 10. Metodo secondo una delle rivendicazioni precedenti, in cui la transazione elettronica è di tipo “Consumer to Consumer” (da privato a privato) oppure “Consumer to Business” (da privato a impresa commerciale) oppure “Business to Consumer” (da impresa commerciale a privato).
11. 11. Metodo secondo una delle rivendicazioni da 1 a 9, in cui la transazione elettronica è di tipo “Business to Consumer” (da impresa commerciale a privato) e il valore finanziario transato comprende uno o più delle seguenti categorie: buono sconto, offerte commerciali, cash-back, e-coupon, charity cash-back.
12. 12. Metodo secondo una delle rivendicazioni precedenti, in cui lo strumento finanziario associato agli utenti registrati comprende una o più delle seguenti categorie: conto corrente bancario, Carte di Credito/Debito, Pre-pagate, Credito telefonico, Coupon, Cash-back, Charity Cash-back.
13. 13. Un programma per elaboratore per l’implementazione di un metodo per effettuare transazioni elettroniche, secondo una delle rivendicazioni precedenti, quando il programma è eseguito su un sistema di elaborazione dati.
14. 14. Un sistema comprendente uno a più componenti atti a implementare un metodo per effettuare transazioni elettroniche, secondo una delle rivendicazioni da 1 a 12.