IT201800010197A1 - Metodo e sistema per effettuare pagamenti elettronici in modalità Cash On Delivery - Google Patents

Description

DESCRIZIONE DI INVENZIONE INDUSTRIALE

TITOLO: Metodo e Sistema per effettuare pagamenti elettronici con modalità Cash On Delivery

CAMPO TECNICO

La presente invenzione riguarda un metodo e sistema per effettuare transazioni (e.g. pagamenti) elettroniche mediante un codice di sicurezza, più in particolare un metodo e sistema per realizzare una rete di pagamenti a seguito di acquisti remoti (e.g. acquisti on-line) facendo in modo che le parti (chi emette il pagamento e chi lo riceve) vengano garantite sulla correttezza delle transazioni. RETROSPETTIVA TECNICA

L’E-commerce si sta diffondendo sempre di più come mezzo per acquistare in modo facilitato e conveniente da una parte (quella dell’acquirente) e per raggiungere mercati sempre più ampi e senza confini (sia geografici che sociali) dall’altra parte, quella del venditore. Uno dei fattori che ancora ne frena l’ulteriore sviluppo è la fiducia da parte del consumatore medio che è ancora piuttosto bassa.

Tecnicamente ci sono tutti i requisiti per garantire la sicurezza di qualsiasi transazione. Stiamo assistendo per esempio 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.

Quando però l’acquirente e il venditore si trovano fisicamente distanti o anche solo non in contatto diretto, è necessario un livello ancora più elevato di garanzia per fugare i timori residui sia di chi mette a disposizione i propri prodotti a un acquirente sconosciuto sia a chi acquista da un venditore un prodotto che vede solo sulla carta (o meglio sul video di un dispositivo elettronico). Il primo vuole essere sicuro di ricevere il pagamento concordato, il secondo vuole verificare che il prodotto sia consegnato e che risponda alle aspettative, prima di autorizzare definitivamente il pagamento.

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 una transazione elettronica di valori finanziari da un acquirente a un venditore per mezzo di un sistema distribuito comprendente un server per la gestione di pagamenti online, il server avendo accesso a un data base contenente informazioni su almeno un venditore registrato, ognuno dell’almeno un venditore registrato essendo associato a un profilo contenente almeno uno strumento finanziario abilitato a ricevere pagamenti, il server essendo predisposto per stabilire comunicazioni con il gestore dell’almeno uno strumento finanziario, il metodo comprendendo i seguenti passi:

- il server riceve da parte dell’acquirente la richiesta di acquisto di un prodotto selezionato tra una pluralità di prodotti associati all’almeno un venditore registrato, la richiesta contenendo l’autorizzazione ad addebitare un prezzo di vendita associato al prodotto selezionato mediante l’almeno uno strumento finanziario associato all’almeno un venditore;

- il server verifica con il gestore dell’almeno uno strumento finanziario la disponibilità dell’importo corrispondente al prezzo di vendita e istruisce il gestore dell’almeno uno strumento finanziario di bloccare la disponibilità dell’importo; - a seguito di un esito positivo della verifica della disponibilità, il server genera e invia all’acquirente un codice univoco di acquisto e lo memorizza in una lista di codici autorizzati per controlli futuri;

- a seguito di una richiesta da parte di un delegato dell’almeno un venditore e a seguito della ricezione da parte del delegato di un codice di acquisto, il server verifica la corrispondenza del codice ricevuto con uno dei codici memorizzati nella lista;

- a seguito di un esito positivo della verifica della corrispondenza del codice ricevuto con uno dei codici memorizzati nella lista, il server autorizza il gestore dell’almeno uno strumento finanziario a effettuare il pagamento all’almeno un venditore registrato dell’importo bloccato a completamento della transazione elettronica.

In una realizzazione preferita della presente invenzione il codice univoco di acquisto viene generato mediante una tecnologia basata su funzioni di tipo HASH.

Il passo di verifica della corrispondenza del codice ricevuto con uno dei codici memorizzati nella lista avviene preferibilmente mediante collegamento con il server, ma è possibile l’alternativa che la verifica avvenga offline mediante un device mobile su cui il server ha precedentemente memorizzato la lista di codici autorizzati.

Preferibilmente, a seguito dell’autorizzazione a effettuare il pagamento all’almeno un venditore registrato dell’importo bloccato a completamento della transazione elettronica, il server autorizza un delegato dell’almeno un venditore alla consegna del prodotto selezionato.

In una realizzazione preferita, l’autorizzazione al gestore dell’almeno uno strumento finanziario a effettuare il pagamento all’almeno un venditore registrato dell’importo bloccato a completamento della transazione elettronica è condizionata al ricevimento di una conferma di soddisfazione da parte dell’acquirente.

Le comunicazioni tra il server e l’acquirente, tra il server e l’almeno un venditore registrato, tra il server e il gestore dell’almeno uno strumento finanziario, tra il server e il delegato dell’almeno un venditore registrato avvengono preferibilmente attraverso uno dei seguenti mezzi di comunicazione o una combinazione degli stessi: rete telefonica mobile, Internet, Wi-Fi, BlueTooth, Contactless. La transazione elettronica può essere di tipo “Person to Person” (da privato a privato) oppure “Person to Business” (da privato a impresa commerciale) oppure “Business to Person” (da impresa commerciale a privato) e l’almeno uno strumento finanziario può comprendere una o più delle seguenti categorie: conto corrente bancario, Carte di Credito/Debito, Pre-pagate, Credito telefonico, Coupon, Cash-back, Charity Cash-back, Virtual Currency (e.g. Blockchain).

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 garantite e sicure sia per chi vende che per chi acquista. Si superano in questo modo alcuni svantaggi dei sistemi disponibili allo stato dell’arte per i servizi di pagamento on line (e-payment).

Un altro vantaggio derivante dalla presente invenzione è quello di permettere lo sfruttamento di componenti esistenti attraverso la loro integrazione con la piattaforma di pagamenti certificati sopra descritta.

BREVE DESCRIZIONE DELLE FIGURE

Questi e ulteriori vantaggi, scopi e caratteristiche della presente invenzione saranno meglio compresi da ogni tecnico esperto nel ramo 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 alcune delle fasi di un metodo di pagamento secondo una realizzazione preferita della presente invenzione;

- la Figura 4 è una rappresentazione delle fasi successive a quelle rappresentate in Figura 3 di un metodo di pagamento secondo una realizzazione preferita della presente invenzione;

- la Figura 5 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 di acquisti effettuati in remoto, per esempio attraverso il web, su siti e-commerce, ma si estende a tutti quei casi in cui l’acquirente non è fisicamente presente nel luogo di vendita e non salda direttamente il costo della transazione. Si tratta principalmente di acquisto di prodotti, ma potrebbe anche comprendere il pagamento di servizi, con la consegna per esempio di un biglietto al recapito indicato dall’acquirente.

Le finalità che questa piattaforma vuole raggiungere sono le seguenti:

- garantire la tranquillità dell’acquirente che potrà ricevere, visionare e controllare il prodotto acquistato prima di confermare il pagamento;

- garantire la tranquillità del venditore che avrà la sicurezza del pagamento, anche se l’effettiva transazione avverrà solo dopo che l’acquirente ha confermato la corretta ricezione.

Va notato che l’aumentata tranquillità dell’acquirente è anche, indirettamente, un grande beneficio per il venditore che può più facilmente superare la diffidenza di eventuali acquirenti verso i pagamenti in ambito e-commerce.

Nel sistema mostrato in Figura 1, un acquirente 101, si collega a un sito di ecommerce 103 (come accennato sopra, nel presente esempio ci riferiamo a siti di e-commerce e ad acquisti effettuati su Internet, ma l’applicazione si estende a qualsiasi metodo di acquisto in remoto) per effettuare un acquisto di un prodotto (o servizio) offerto da un venditore 105. Per confermare l’acquisto, l’acquirente dovrà completare la procedura di pagamento, attraverso la procedura prevista dal sito (o selezionando una della pluralità di procedure disponibili). Il server 103 è collegato a un server 106 per la gestione dei pagamenti collegato a sua volta a un sistema di controllo finanziario 107 per il collegamento verso una banca o una società di gestione di carte di credito. L’importo della transazione viene a questo punto garantita sul server 106 tramite le verifiche di controllo finanziario, ma non viene messa a disposizione del venditore. Un codice univoco, generato dal server 106, chiamato nel prosieguo della presente descrizione Token Cash On Delivery (o Token C.O.D.) viene comunicato all’acquirente 101. Tale codice Token C.O.D. dovrà essere comunicato al fattorino o corriere 109 al momento della consegna del prodotto acquistato. Il corriere 109, disporrà di un terminale (per esempio un terminale mobile 111) collegato con il server 106, sul quale il corriere potrà inserire il codice Token C.O.D. per verificare la correttezza del pagamento. La comunicazione del codice Token C.O.D. dall’acquirente 101 al corriere 109 e la conferma da parte del server 106, attraverso il terminale 111, della sua correttezza, completano il processo di acquisto. Coloro esperti del ramo apprezzeranno facilmente che i vari passi della presente procedura potranno essere implementati con numerose varianti, tutte rientranti nell’ambito di protezione della presente invenzione. Per esempio le modalità di pagamento del prodotto al momento dell’acquisto, potrà essere selezionata tra le numerose disponibili sul mercato (carta di credito, carta di pagamento, carta prepagata, valute digitali, Virtual Currency (e.g. Blockchain), coupon, buoni sconto, bonifico bancario, electronic wallet etc) a scelta dell’esercente 105 e dell’acquirente 101. Le comunicazioni tra acquirente 101, sito e-commerce 103, server 106, venditore 105, modulo di controllo finanziario 107 e terminale 111 potranno avvenire per mezzo di una qualsiasi delle tecnologie disponibili, tra cui rete telefonica mobile e/o fissa, Internet, Wi-Fi, BlueTooth, Contact-Less. Il terminale 111 potrà essere collegato in diretta (per esempio tramite connessione Internet) al server 106 al momento del controllo del codice Token C.O.D. oppure, per esempio in caso di assenza di connettività (e.g. zone geografiche non coperte dal servizio Internet), aver scaricato in precedenza le informazioni necessarie al controllo della correttezza del codice.

Per il corretto funzionamento del sistema di pagamento, ogni venditore 105 dovrà essere registrato presso il server 106 che dovrà conoscere i dettagli di almeno uno strumento finanziario del venditore 105. Più in generale, mentre il venditore 105 deve essere registrato al servizio e al server 106, l’acquirente 101 sarà noto al server 106 in toto o limitatamente ai recapiti necessari per l’inoltro della messaggistica elettronica inerente il codice Token C.O.D..

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 dischi CD-ROM e/o dischi ottici (e.g. DVD o BlueRay) oppure 274. Inoltre il computer 250 può comprendere dispositivi di input 277 (e.g. tastiera, mouse, track point, porte USB) e di output 280 (e.g. schermo, stampante, porte USB). 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.).

Le Figure 3 e 4 mostrano schematicamente una possibile implementazione pratica del sistema di pagamento secondo una realizzazione preferita della presente invenzione. Le varie fasi vengono rappresentate in ordine cronologico, seguendo le fasi di una tipica vendita on-line.

Un server controlla tutte le operazioni e comprende un modulo di comunicazione che permette il collegamento attraverso una rete (e.g. Rete telefonica mobile, Internet, LAN o una combinazione di queste).

L’invenzione risolve, attraverso l’utilizzo combinato di tecnologie innovative e quindi con la creazione di un nuovo e originale processo di pagamento, le problematiche legate ai “pagamenti in contrassegno”, o anche “Cash-On-Delivery”, per gli acquisti e-commerce, e riassumibili su tre livelli:

1. Rischio per il merchant nel recapito della merce e nell’accettazione della stessa da parte del buyer, derivante dai costi di mancata consegna o rifiuto ritiro non giustificato (es. non sono presenti/rilevabili danni della merce). Rischi legati inoltre a frodi derivanti da denaro falso o assegni non capienti.

2. Rischio sicurezza e frode per il vettore/driver nella gestione di contanti e assegni

3. Rinuncia/Diffidenza dei buyer verso gli acquisti e-commerce (con conseguente rinuncia all’acquisto stesso o scelta della formula “pagamento in contrassegno”). Il vantaggio essenziale per il buyer, al netto degli extra-costi che tale modalità di pagamento prevede, è che egli potrà pagare solo nel caso in cui: • gli venga effettivamente consegnata la merce;

• la merce corrisponda a quanto ordinato;

• la merce sia priva di danni.

In una possibile forma di realizzazione della presente invenzione, il buyer oltre a poter selezionare tra più forme di pagamento, potrà selezionare un “Punto CashCOD” a cui appoggiarsi per il pagamento in contanti

Con i sistemi attuali, in maniera trasversale, tutti gli attori coinvolti sostengono costi elevati derivanti dalla complessità e rischiosità del processo stesso, riconducibili anche alla gestione fisica dello strumento di pagamento, contante o assegno che sia (incasso, contabilizzazione, bonifico di trasferimento, …)

Per i merchant, questa forma di pagamento, oltre a comportare i rischi così come riportati precedentemente, lo obbliga a sostenere costi significativi per l’incasso, compresi tra il 5% e il 10% del valore della merce. Costi che in parte ripropongono verso il buyer attraverso una “commissione”, che è specifica ed aggiuntiva rispetto ad altre modalità di pagamento.

L’adozione di un codice elettronico univoco e segreto secondo una realizzazione preferita della presente invenzione (il Token C.O.D., ovvero il Token a supporto del “Cash-On-Delivery”) permette di garantire la sicurezza dell’intero processo, dalla fase di acquisto sul sito e-commerce (momento della generazione del codice Token C.O.D. da parte per esempio di una piattaforma “cloud” che chiameremo TCOD e notifica al buyer tramite canali elettronici, quali per esempio e-mail, sms, push notitication) fino alla consegna fisica della merce (convalida del codice Token C.O.D. comunicato alla piattaforma TCOD da parte del buyer). Solo in caso di convalida positiva il vettore/driver consegnerà la merce al buyer.

In pratica, solo colui che è a conoscenza del codice Token C.O.D. generato in fase di acquisto, può ottenere la consegna della merce.

In termini di opportunità per i merchant, oltre a risolvere le problematiche di cui sopra, si creano le condizioni per incrementare i volumi nel segmento “lusso”, attraverso la certificazione del bene (per il tramite dei sistemi di notarizzazione e sicurezza impliciti nelle reti di Virtual Currency (e.g. Blockchain-DLT) a garanzia della originalità.

In una realizzazione preferita della presente invenzione, il codice univoco TCOD sarà una stringa binaria come risultato ("dato di output") di una operazione di HASH, funzione crittografica irreversibile in generazione ricorsiva utilizzando per esempio MD4, MD5, SHA-1, SHA-2,... o eventualmente algoritmi proprietari, applicata a una combinazione complessa dei cosiddetti "dati di input" quali per esempio i dati identificativi univoci del sistema generante, dati temporali istantanei della sessione di generazione, codice della transazione di ecommerce in corso, id del merchant, id del cliente...:

Il codice TCOD pertanto è preferibilmente un codice unidirezionale (one-way), ovvero una funzione non invertibile e pertanto non duplicabile, a garanzia della sua autenticità.

Sempre tramite una rete Blockchain-DLT Token C.O.D. potrà essere governato “super-partes” il ciclo di vita del “contratto” di acquisto (smart-contract) al fine di garantire a tutte le controparti la corretta ed automatica esecuzione degli impegni assunti a fronte di determinati eventi (es. operazioni di storno su importi prenotati a fronte di merce respinta)

In una possibile realizzazione della presente invenzione possono essere introdotti due moduli a complemento:

• Certified Delivery: a garanzia che chi ritira la merce sia autorizzato a farlo • Certified Shipment: a garanzia che il bene in consegna corrisponda a quanto spedito dal merchant

DETTAGLI DELLA SOLUZIONE TOKEN C.O.D.

Secondo una realizzazione preferita della presente invenzione, nelle Figure 3 e 4 viene rappresentato un sistema di pagamento sicuro: il Token C.O.D. è un codice univoco e segreto di cui solo il buyer è al corrente. Il vettore/driver e il merchant non hanno possibilità di accedere a tale codice.

Di seguito, forniamo un esempio del ciclo di vita del processo d’acquisto tramite Token C.O.D., con:

• qualsiasi strumento di pagamento tra quelli previsti (e.g. carte di credito, prepagate, P2P, P2B)

• spedizione unica di tutti i beni, non frammentata

Percorrendo la linea temporale dell’acquisto su E-store, si possono identificare in Figura 3 le seguenti fasi da 1 a 5:

- 1) Buyer

1.a. Selezione dei prodotti e inserimento nel “carrello”

1.b. Decisione di acquisto, e inserimento dati di acquisto (es. fatturazione, domicilio, coupon, …)

1.c. Selezione del metodo di pagamento: il cliente procede con la scelta del metodo di pagamento “Token C.O.D.”, secondo lo strumento preferito (es. Carta di Credito, Mobile Payment, …).

- 2) Merchant

2.a. Il merchant avvia la transazione di vendita verso la Piattaforma TCOD

- 3) Piattaforma TCOD

3.a. Verifica disponibilità: a seconda dello strumento di pagamento selezionato, viene interrogato, per il tramite di un Gateway di Pagamento 107, il conto di pagamento corrispondente (es. circuito carte, wallet, oppure P2B tipo Jiffy) per verificarne la capienza rispetto all’importo richiesto per l’acquisto (vedi tabella successiva).

3.b. Esito disponibilità: in caso di esito positivo, la Piattaforma TCOD procede con lo step 3c. In caso di esito negativo, ovvero assenza di capienza, la transazione viene interrotta, con notifica esito al Merchant e quindi al Buyer. 3.c. Richiesta impegno: la piattaforma TCOD invia al Gateway di Pagamento la richiesta di impegno per il dato importo

3.d. Esito Impegno: viene confermato l’impegno, ovvero viene bloccato/prenotato l’importo richiesto per l’acquisto e attivato lo step 3e. L’impegno dell’importo si rinnoverà automaticamente al prolungarsi dei tempi di consegna del bene (es. se superiore a 15 gg). In caso di esito negativo, ovvero impegno non confermato, la transazione viene interrotta, con notifica esito al Merchant e quindi al Buyer.

3.e. Generazione e Notifica codice Token C.O.D.: a seguito della conferma dell’impegno, viene generato il Codice Token C.O.D., che verrà notificato in chiaro al buyer (es. SMS, Push su APP del Merchant, …). Il Token potrà essere generato sulla base delle esigenze del singolo merchant (es. un Token per prodotto oppure per spedizione, oppure per ordine, oppure per una combinazione specifica; le logiche di impegno/addebito delle somme saranno coerenti con la modalità di generazione del Token)

3.f.Esito transazione di vendita: a seguito della generazione del Codice Token C.O.D. il merchant riceve la notifica autorizzativa all’evasione dell’ordine. L’evento viene notificato anche al buyer secondo i canali previsti (mail, sms, push, web pop-up, …).

- 4) Merchant

4.a. Lavorazione/preparazione: sono le operazioni di recupero dei prodotti, imballaggio etc.

4.b. Spedizione: i beni vengono spediti al buyer secondo le preferenze espresse in fase di acquisto (1.b)

- 5) Vettore/Driver

5.a. Presa in carico merce, trasporto

La Figura 6 rappresenta invece le fasi da 6 a 10, come segue:

- 6) Vettore/Driver e Buyer

6.a. Arrivo a destinazione della merce

6.b. Invio del codice Token C.O.D.: il vettore/driver richiede al buyer il codice alfanumerico, il Bar Code, QR Code del codice Token C.O.D.

6.b.i. “modalità online”: in caso di connettività mobile, il vettore/driver o lo stesso buyer inviano il codice alla piattaforma TCOD per la verifica

6.b.ii. “modalità offline”: in caso di assenza di connettività mobile (es. zone remote o isolate) la verifica avviene localmente sul palmare del vettore/driver (il buyer deve digitare il codice o farne scansionare il Bar Code o QR Code)

- 7) Piattaforma TCOD

7.a. Verifica validità codice Token C.O.D.

7.a.i. “modalità online”: in caso di connettività mobile la piattaforma TCOD verifica la corrispondenza tra il prodotto in consegna e il Codice Token C.O.D.

ricevuto e restituisce l’esito

7.a.ii. “modalità offline”: Il driver, prima di iniziare le consegne, effettua sempre il download sul proprio dispositivo della lista dei codici Token C.O.D. criptati appartenenti alle spedizioni a lui assegnate

- 8) Vettore/Driver

8. a. A seguito di esito positivo della verifica sul codice Token C.O.D., viene consegnata la merce al buyer. In caso di esito negativo, la merce non viene consegnata (nel qual caso, richiesta di supporto al Call Center per dirimere il caso)

- 9) Piattaforma TCOD

9.a. A seguito della verifica positiva di cui sopra, il vettore/driver notifica alla piattaforma TCOD l’avvenuta consegna e ritiro da parte del buyer; la piattaforma TCOD notifica al merchant l’avvenuta consegna

9.b. Eliminazione impegno

9.c. Addebito: addebito sul conto di pagamento. L’importo che viene effettivamente addebitato al buyer potrà essere uguale o minore rispetto all’importo impegnato a seconda dei seguenti casi:

• Accettazione della merce: importo è pari a quanto stabilito al momento dell’acquisto, ovvero all’importo impegnato

• Rifiuto ante consegna entro data x: x% dell’importo impegnato

• Rifiuto ante consegna entro data y: y% dell’importo impegnato

• Rifiuto ante consegna entro data z: z% dell’importo impegnato

• Rifiuto della merce o mancato ritiro: viene addebitato il costo della logistica/trasporto come stabilito in fase di acquisto

• Merce danneggiata: non viene addebitato alcun importo; la causale (reason code) viene gestita solo dal driver

• Ritardata consegna: in caso di superamento della data massima stabilita di consegna per colpa del merchant, può essere gestito un importo di rimborso, in abbattimento all’addebito di cui sopra. In questo caso, all’effettiva consegna del bene la procedura scarica l’intero impegno e addebiterà la differenza tra importo di acquisto e importo del rimborso

- 10) Ricezione conferma addebito: il buyer riceve la notifica di avvenuto addebito sul proprio conto di pagamento.

Supporto della Carta di Identità Elettronica – C.I.E.

In tal caso la consegna del bene avviene attraverso la comparazione tra:

• codice fiscale inserito dal buyer al momento dell’ordine

• codice fiscale acquisito dal Vettore/Driver dalla Carta di Identità Elettronica – C.I.E - in modalità contact-less (cless) al momento della consegna (con APP stand alone o con integrazione nell’applicazione del Vettore/Driver stesso)

Il servizio può essere attivato dal merchant indipendentemente:

- dalla forma/sistema di pagamento (con o senza TokenCOD)

- dalla spedizione unica o frammentata dei beni

Percorrendo la linea temporale dell’acquisto su E-store, si possono identificare le seguenti fasi:

1. Buyer

a. Selezione dei prodotti e inserimento nel “carrello”

b. Decisione di acquisto e inserimento dati di acquisto (es. fatturazione, domicilio, coupon,

c. Selezione del metodo di pagamento

d. Selezione della scelta per la consegna certificata “Certified Delivery” con C.I.E

e. inserimento del codice fiscale del Delegato al Ritiro che riceverà/ritirerà il bene (può essere il proprio e/o di altra persona in funzione delle eventuali restrizioni di sicurezza che il merchant potrebbe applicare).

f. la procedura esegue il controllo formale del codice fiscale

NB: il sistema può accettare per ogni ordine fino a “n” possibili codici fiscali abilitati al ritiro

2. Merchant

a. Il merchant avvia la transazione di vendita nelle modalità previste

3. Piattaforma TCOD – Modulo “Certified Delivery”

a. Viene creata una relazione fra codici fiscali inseriti e il codice dell’ordine b. La piattaforma gestisce i servizi di verifica (online e batch) per il controllo crittografico della/e coppia/e codice/i fiscale/i acquisito verso codice ordine; storicizzazione del dato (data e ora consegna, codici fiscali inseriti nell’ordine, codice ordine, codice fiscale del ritirante, …)

4. Merchant

a. Lavorazione/preparazione: sono le operazioni di recupero dei prodotti, imballaggio etc.

b. Spedizione: i beni vengono spediti al buyer secondo le preferenze espresse in fase di acquisto

5. Vettore/Driver

a. Presa in carico merce, trasporto

6. Vettore/Driver e Delegato al Ritiro

a. Arrivo a destinazione della merce

b. Controllo codice fiscale tramite C.I.E.: il vettore/driver richiede al Delegato al Ritiro di avvicinare al device cless la C.I.E

i. “modalità online”: in caso di connettività mobile, l’applicativo effettua l’invio del codice crittografato alla piattaforma TCOD “Certified Delivery” per la verifica ii. “modalità offline”: in caso di assenza di connettività mobile (es. zone remote o isolate) la verifica avviene localmente sul palmare del vettore/driver (o tramite app standalone)

7. Piattaforma TCOD – Modulo “Certified Delivery”

a. Verifica validità C.I.E

i. “modalità online”: in caso di connettività mobile la piattaforma TCOD verifica la corrispondenza tra il prodotto in consegna e il codice fiscale della C.I.E e restituisce l’esito

ii. “modalità offline”: Il driver, prima di iniziare le consegne, effettua sempre il download sul proprio dispositivo della lista dei codici fiscali, criptati, appartenenti alle spedizioni a lui assegnate

b. Esito verifica negativo, ovvero codice fiscale non autorizzato o mancato ritiro, la transazione viene interrotta, con notifica esito al Merchant e quindi al Buyer (mail, sms, push, web pop-up,...).

c. Esito verifica positivo: a seguito della lettura di codice fiscale positivo dalla C.I.E. l’evento viene notificato al Merchant e quindi al Buyer (mail, sms, push, web pop-up, ...).

8. Vettore/Driver

a. In caso di esito positivo della verifica

i. la merce viene consegnata al Delegato al Ritiro

ii. il vettore/driver notifica alla piattaforma TCOD l’avvenuta consegna e ritiro b. In caso di esito negativo, la merce non viene consegnata

9. Piattaforma TCOD – Modulo “Certified Delivery”

In caso di esito positivo della verifica la piattaforma TCOD notifica al merchant e al buyer l’avvenuta consegna e ritiro da parte del Delegato al Ritiro

Il Modulo TokenCOD “Certified Shipment”

Questo modulo opzionale prevede, indipendentemente dalla forma/sistema di pagamento, la certezza che il bene in consegna sia effettivamente quello spedito dal merchant.

Il bene viene collocato all’interno di un involucro blindato (plastiche dure, acciaio, …) protetto da serratura elettronica e corredato di un chip trasmissivo programmabile (es. Bluetooth).

In analogia ad una Carta di Identità Elettronica di cui al caso precedente, la trasmissione riporta un codice crittografato “ID Certified Shipment Box”, che identifica univocamente la scatola. Questo codice viene generato in fase di acquisto del bene e noto solo a Merchant, Buyer, Delegato al Ritiro.

Se previsto dal dispositivo di apertura, i tentativi di apertura verranno registrati e il dispositivo trasmissivo invierà data e ora dell’evento a corredo del proprio identificativo “ID Certified Shipment Box”.

La persona delegata al ritiro, una volta riconosciuta per il tramite del sistema di “Certified Delivery” (in una delle due forme previste codice Token C.O.D. o Carta d’Identità Elettonica), riceverà in APP una notifica con la password per poter agganciare il dispositivo trasmissivo della scatola. La APP acquisirà “ID Certified Shipment Box” e ne verificherà, tramite il modulo TokenCOD - Certified Shipment, la corrispondenza con il codice generato in fase di acquisto.

In caso di esito positivo sia del “Certified Delivery” che del “Certified Shipment”, la combinazione di apertura della scatola sarà comunicata attraverso una notifica al buyer (es. in funzione delle policy di sicurezza stabilite dal merchant più persone possono ritirare, solo una può aprire).

L’involucro potrà essere del tipo usa e getta o da restituire al merchant tramite drop-point del vettore e/o di altri partner (es. Sisal Point, Tabaccherie, Uffici Postali, …).

Altre possibili opzioni supportate

Gli esempi seguenti sono propedeutici e non limitativi di altre possibili combinazioni. A titolo di esempio:

Pagamento in Contanti

La Selezione del metodo di pagamento “Token C.O.D.”, da parte del Buyer offre anche l’opzione per prenotazione-pagamento in contanti presso un “Punto CashCOD”.

Tramite questa opzione il sistema Token C.O.D. genera un Codice identificativo della Transazione di acquisto che verrà notificato in chiaro al buyer (es. SMS, Push su APP del Merchant, …) e con cui potrà effettuare la prenotazionepagamento presso un “Punto CashCOD”.

Completato il versamento, il “Punto CashCOD” notificherà alla piattaforma Token COD l’avvenuta prenotazione dell’importo di acquisto. L’importo verrà trasferito su un conto convenzionato Token C.O.D. che ne regolerà l’utilizzo in funzione dell’esecuzione dello “smart-contract”

A seguito della conferma dell’impegno, viene generato il codice Token C.O.D., che verrà notificato in chiaro al buyer (es. SMS, Push su APP del Merchant, …).

Il processo rimane invariato fino al suo completamento. Le eventuali operazioni di storno/riaccredito verranno effettuate su un IBAN definito dal buyer nel proprio profilo.

Frazionamento della spedizione

Come anticipato, il codice Token C.O.D. potrà essere generato sulla base delle esigenze del singolo merchant (es. un codice Token C.O.D. per prodotto oppure per spedizione, oppure per ordine, oppure per una combinazione specifica; le logiche di impegno/addebito delle somme saranno coerenti con la modalità di generazione del Token)

La gestione del “contratto”

Viene di seguito fornito un esempio implementativo di gestione del contratto che regoli i rapporti tra esercente e acquirente, utilizzando la soluzione secondo una realizzazione della presente invenzione. Deciso l’acquisto, viene di fatto sottoscritto un “contratto elettronico” o “smart-contract”, governato tramite la rete Blockchain DLT TokenCOD.

L’esecuzione delle condizioni del contratto (vedi sotto) ovvero il regolamento degli importi (accrediti, addebiti, storni, …) è regolata automaticamente e “super-partes” dai macro-eventi che caratterizzano il ciclo di vita del processo di acquisto. Ciò svincola le singole controparti da conflittualità nell’esecuzione del contratto stesso in quanto governato elettronicamente.

A titolo di esempio il contratto conterrà:

o Dati del Merchant e del Cliente

o Identificativi ordine

o Dati di spedizione

o Dati di pagamento

o Elenco e descrizione dei beni, ID_bene, importo (es.700 Euro)

o Condizioni o Eventi del contratto (a discrezione del Merchant)

฀ Accettazione consegna, importo (es. -700 Euro)

฀ Rifiuto ante consegna entro data x (es. produzione), importo (es. -50 Euro) ฀ Rifiuto ante consegna entro data y (es. preparazione), importo (es. -100 Euro)

฀ Rifiuto ante consegna entro data z (es. spedizione), importo (es. -200 Euro) ฀ Rifiuto alla consegna/Mancata consegna, importo (es. -250 Euro)

฀ Ritardata consegna, importo (Es. 50 Euro)

฀ Danneggiato, importo (es.0 Euro)

In Figura 5 viene mostrata 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 (pagamenti) da parte di un acquirente a seguito di acquisti effettuati in remoto (e.g. online shopping) presso un venditore. Il metodo è implementato e funziona su un sistema distribuito incentrato su un server 106 che riceve le richieste ed effettua le operazioni. Il server 106 gestisce per conto di almeno un venditore la vendita di una pluralità di prodotti e ha accesso: ai dati dell’almeno un venditore; a un modulo di controllo finanziario 107 che garantisca autonomamente la gestione dei pagamenti, senza che possa essere controllato dall’almeno un venditore. Il metodo inizia con il passo 501 in cui il venditore riceve una richiesta da parte di un acquirente di effettuare un acquisto e di pagare il costo corrispondente. Il controllo a questo punto passa al server 106 che gestisce la procedura di pagamento online (passo 503). All’acquirente verranno chieste le informazioni necessarie a effettuare il pagamento, in base alle condizioni stabilite dal venditore selezionato (505), per mezzo di uno strumento finanziario, per esempio una carta di credito appartenente a un circuito accettato dal venditore selezionato. Il server verificherà con il modulo di controllo finanziario 107 se lo strumento finanziario fornito dall’acquirente garantisce la necessaria disponibilità monetaria (passo 507). In caso di rifiuto (509) da parte del modulo di controllo finanziario 107, la transazione viene rifiutata e l’acquisto non può essere completato, a meno che l’acquirente non fornisca un altro strumento finanziario idoneo e accettato dal venditore selezionato. Se invece la transazione viene accettata (passo 511), il server 106 emette un codice univoco (Token C.O.D.) e lo comunica all’acquirente. Quando il prodotto acquistato viene inviato per mezzo di un corriere dal venditore all’acquirente, per poter ricevere fisicamente il prodotto, l’acquirente dovrà fornire il codice Token C.O.D. al corriere, il quale, per mezzo di un terminale mobile richiederà l’autorizzazione alla consegna mediante la comunicazione del codice Token C.O.D. (passo 513). Il server verificherà che il codice fornito è corretto (passo 515) e autorizzerà la consegna del prodotto all’acquirente e il completamento del pagamento al venditore (passo 517) oppure, in caso il codice non risulti corretto, negherà la consegna del prodotto. In caso di esito negativo, dovrà essere seguita una procedura da parte del corriere e di tutte le parti in causa che dipenderà dagli accordi contrattuali sottoscritti in fase di acquisto (passo 519).

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 (10)

1. RIVENDICAZIONI 1. Metodo per effettuare transazioni elettroniche di valori finanziari da un acquirente a un venditore per mezzo di un sistema distribuito comprendente un server per la gestione di pagamenti online, il server avendo accesso a un data base contenente informazioni su almeno un venditore registrato, ognuno dell’almeno un venditore registrato essendo associato a un profilo contente almeno uno strumento finanziario abilitato a ricevere pagamenti, il server essendo predisposto per stabilire comunicazioni con il gestore dell’almeno uno strumento finanziario, il metodo comprendendo i seguenti passi: - il server riceve da parte dell’acquirente la richiesta di acquisto di un prodotto selezionato tra una pluralità di prodotti associati all’almeno un venditore registrato, la richiesta contenendo l’autorizzazione ad addebitare un prezzo di vendita associato al prodotto selezionato mediante un titolo di pagamento dell’acquirente riconosciuto dall’almeno uno strumento finanziario associato all’almeno un venditore; - il server verifica con il gestore dell’almeno uno strumento finanziario la disponibilità dell’importo corrispondente al prezzo di vendita e istruisce il gestore dell’almeno uno strumento finanziario di bloccare la disponibilità dell’importo sul titolo di pagamento dell’acquirente; - a seguito di un esito positivo della verifica della disponibilità, il server genera e invia all’acquirente un codice univoco di acquisto e lo memorizza in una lista di codici autorizzati per controlli futuri; - a seguito di una richiesta da parte di un delegato dell’almeno un venditore e a seguito della ricezione da parte del delegato di un codice di acquisto, viene verificata la corrispondenza del codice ricevuto con uno dei codici memorizzati nella lista; - a seguito di un esito positivo della verifica della corrispondenza del codice ricevuto con uno dei codici memorizzati nella lista, il server autorizza il gestore dell’almeno uno strumento finanziario a effettuare il pagamento all’almeno un venditore registrato dell’importo bloccato a completamento della transazione elettronica.
2. 2. Metodo secondo la rivendicazione 1, in cui il codice univoco di acquisto viene generato mediante una tecnologia basata su funzioni HASH.
3. 3. Metodo secondo una delle rivendicazioni precedenti, in cui il passo di verifica della corrispondenza del codice ricevuto con uno dei codici memorizzati nella lista avviene mediante collegamento con il server.
4. 4. Metodo secondo una delle rivendicazioni 1 o 2, in cui il passo di verifica della corrispondenza del codice ricevuto con uno dei codici memorizzati nella lista avviene offline mediante una device mobile su cui il server ha precedentemente memorizzato la lista di codici autorizzati.
5. 5. Metodo secondo una delle rivendicazioni precedenti, comprendente inoltre i passi di: - a seguito dell’autorizzazione a effettuare il pagamento all’almeno un venditore registrato dell’importo bloccato a completamento della transazione elettronica il server autorizza il delegato dell’almeno un venditore alla consegna del prodotto selezionato.
6. 6. Metodo secondo una delle rivendicazioni precedenti, in cui l’autorizzazione al gestore dell’almeno uno strumento finanziario a effettuare il pagamento all’almeno un venditore registrato dell’importo bloccato a completamento della transazione elettronica è condizionata al ricevimento di una conferma di soddisfazione da parte dell’acquirente.
7. 7. Metodo secondo una delle rivendicazioni precedenti, in cui le comunicazioni tra il server e l’acquirente, tra il server e l’almeno un venditore registrato, tra il server e il gestore dell’almeno uno strumento finanziario, tra il server e il delegato dell’almeno un venditore registrato avvengono attraverso uno dei seguenti mezzi di comunicazione o una combinazione degli stessi: rete telefonica mobile, Internet, Wi-Fi, BlueTooth, Contactless.
8. 8. Metodo secondo una delle rivendicazioni precedenti, in cui la transazione elettronica è di tipo “Person to Person” (da privato a privato) oppure “Person to Business” (da privato a impresa commerciale) oppure “Business to Person” (da impresa commerciale a privato) e l’almeno uno strumento finanziario comprende una o più delle seguenti categorie: conto corrente bancario, Carte di Credito/Debito, Pre-pagate, Credito telefonico, Coupon, Cash-back, Charity Cash-back, Virtual Currency (e.g. Blockchain).
9. 9. 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.
10. 10. Un sistema comprendente uno a più componenti atti a implementare un metodo per effettuare transazioni elettroniche, secondo una delle rivendicazioni da 1 a 8.