ITMI20092355A1 - Metodo per gestire transazioni commerciali on-line - Google Patents
Metodo per gestire transazioni commerciali on-line Download PDFInfo
- Publication number
- ITMI20092355A1 ITMI20092355A1 IT002355A ITMI20092355A ITMI20092355A1 IT MI20092355 A1 ITMI20092355 A1 IT MI20092355A1 IT 002355 A IT002355 A IT 002355A IT MI20092355 A ITMI20092355 A IT MI20092355A IT MI20092355 A1 ITMI20092355 A1 IT MI20092355A1
- Authority
- IT
- Italy
- Prior art keywords
- transaction
- payment card
- confirmation
- computer system
- user
- Prior art date
Links
- 238000000034 method Methods 0.000 title claims description 24
- 238000012790 confirmation Methods 0.000 claims description 107
- 238000004891 communication Methods 0.000 claims description 12
- 238000012545 processing Methods 0.000 claims description 11
- 230000008569 process Effects 0.000 claims description 7
- 230000001413 cellular effect Effects 0.000 description 7
- 238000007726 management method Methods 0.000 description 6
- 230000004044 response Effects 0.000 description 6
- 230000008901 benefit Effects 0.000 description 5
- 125000002066 L-histidyl group Chemical group [H]N1C([H])=NC(C([H])([H])[C@](C(=O)[*])([H])N([H])[H])=C1[H] 0.000 description 3
- 238000012546 transfer Methods 0.000 description 2
- 239000012190 activator Substances 0.000 description 1
- 238000013475 authorization Methods 0.000 description 1
- 230000004888 barrier function Effects 0.000 description 1
- 230000005540 biological transmission Effects 0.000 description 1
- 238000010295 mobile communication Methods 0.000 description 1
- 238000012544 monitoring process Methods 0.000 description 1
- 230000009467 reduction Effects 0.000 description 1
- 238000011144 upstream manufacturing Methods 0.000 description 1
- 238000012795 verification Methods 0.000 description 1
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/38—Payment protocols; Details thereof
- G06Q20/42—Confirmation, e.g. check or permission by the legal debtor of payment
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/08—Payment architectures
- G06Q20/12—Payment architectures specially adapted for electronic shopping systems
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
- G06Q20/32—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using wireless devices
- G06Q20/325—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using wireless devices using wireless networks
- G06Q20/3255—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using wireless devices using wireless networks using mobile network messaging services for payment, e.g. SMS
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
- G06Q20/32—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using wireless devices
- G06Q20/326—Payment applications installed on the mobile devices
- G06Q20/3263—Payment applications installed on the mobile devices characterised by activation or deactivation of payment capabilities
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/38—Payment protocols; Details thereof
- G06Q20/40—Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check credit lines or negative lists
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q30/00—Commerce
- G06Q30/06—Buying, selling or leasing transactions
Landscapes
- Business, Economics & Management (AREA)
- Accounting & Taxation (AREA)
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Physics & Mathematics (AREA)
- General Business, Economics & Management (AREA)
- General Physics & Mathematics (AREA)
- Strategic Management (AREA)
- Finance (AREA)
- Computer Networks & Wireless Communication (AREA)
- Computer Security & Cryptography (AREA)
- Development Economics (AREA)
- Economics (AREA)
- Marketing (AREA)
- Telephonic Communication Services (AREA)
- Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)
- Hardware Redundancy (AREA)
- Debugging And Monitoring (AREA)
Description
DESCRIZIONE
La presente invenzione si riferisce in generale al settore delle telecomunicazioni ed in particolare alle problematiche connesse alla sicurezza nel cosiddetto “commercio elettronico†(“e-commerce†) che, come noto, si avvale delle infrastrutture di reti di telecomunicazione, ed in particolare di Internet.
Il commercio elettronico offre notevoli agevolazioni e vantaggi ai consumatori, permettendo ad esempio a questi ultimi di effettuare transazioni (ad esempio acquisto di beni e/o servizi) con offerenti anche remoti, senza barriere geografiche, anche in quei casi in cui non sarebbe materialmente possibile per i consumatori recarsi presso i punti vendita degli offerenti stessi. Inoltre, il commercio elettronico riduce i costi sostenuti dagli offerenti, ai quali non à ̈ richiesto di istituire punti vendita dislocati sul territorio geografico, e ciò può riflettersi in risparmi economici anche per i consumatori.
A dispetto degli indubitabili vantaggi che derivano dal commercio elettronico, quest’ultimo ha sempre stentato a prendere piede in maniera diffusa fra i consumatori, fra l’altro per timore di truffe informatiche. Difatti, la forma più naturale ed immediata di pagamento del bene/servizio acquistato dal consumatore “on-line†à ̈ attraverso l’utilizzo di carte di credito: il consumatore visita il sito Internet dell’offerente, sul quale sono offerti in vendita i rispettivi prodotti/servizi; scelti i beni/servizi che desidera comprare, il consumatore, sempre “on-line†, emette un ordine di acquisto, e di norma l’offerente chiede al consumatore di fornire i dati (tipicamente il numero, la scadenza, l’intestazione, un codice di sicurezza) della propria carta di credito. Ricevute queste informazioni, il sito dell’offerente contatta il sistema informatico della società emettitrice della carta di credito per avere la conferma della veridicità delle informazioni ricevute dall’acquirente e per perfezionare la transazione finanziaria. Il sistema informatico della società emettitrice della carta di credito verifica la congruità delle informazioni che l’acquirente ha fornito, verifica che la carta di credito sia attiva (ad esempio, che non risulti bloccata a seguito di una denuncia di furto o smarrimento), eventualmente verifica che il massimale di spesa attribuito all'acquirente non sia già stato raggiunto, e se tutte le verifiche danno esito positivo, invia la conferma dell’avvenuta transazione al sito dell’offerente, il quale à ̈ in questo modo garantito che il corrispettivo per i beni/servizi ordinati gli verrà riconosciuto e provvede a fornire all’acquirente quanto ordinato.
Tale formula, se da un lato dà all’offerente/venditore “onesto†una certa garanzia che il pagamento della prestazione corrisposta avverrà regolarmente, dall’altro espone il consumatore ai ben noti rischi di truffa, tipicamente frodi di identità : ad esempio una terza persona potrebbe essere entrata in possesso dei dati della carta di credito del legittimo proprietario (addirittura potrebbe averli “sniffati†monitorando le comunicazioni fra l’elaboratore dati dell’acquirente ed il sistema informatico del venditore) ed usarli per fare acquisti che poi verranno addebitati sul conto dell’ignaro legittimo proprietario.
Numerosissime sono state le proposte per rendere questo genere di transazioni più sicure. In particolare, alcune soluzioni proposte tendono ad evitare che il consumatore debba fornire “on-line†i dati (tipicamente il numero) della propria carta di pagamento (ad esempio, carta di credito oppure carta di debito. Sono anche state proposte soluzioni che si appoggiano alle reti di telefonia, in particolare alle reti di telefonia mobile quali la rete GSM o UMTS, e che implicano una richiesta di conferma della transazione inviata all’acquirente attraverso il telefono cellulare di quest’ultimo.
La domanda di brevetto WO 2008/047330 descrive un metodo di transazione finanziaria che comprende il passo di selezionare un prodotto o servizio per l'acquisto; trasmettere un numero di riferimento della transazione ad un'istituzione finanziaria mediante una rete senza fili; ricevere una richiesta di conferma della transazione dall'istituzione finanziaria mediante una rete senza fili e trasmettere un messaggio di conferma all'istituzione finanziaria mediante la rete senza fili. La Richiedente ha osservato che questo metodo richiede all'acquirente di acquisire da un sito web, e trasmettere attraverso un suo dispositivo di comunicazione mobile tramite un messaggio USSD, un codice di riferimento della transazione. Questa operazione può risultare complicata per gli utenti e può dare luogo ad errori di inserimento.
La domanda di brevetto US 2005/0215231 descrive un metodo per effettuare una transazione commerciale nella quale un cliente dotato di un computer collegato ad una rete pubblica (quale la rete Internet) e di un terminale SMS à ̈ in grado di ricevere e trasmettere messaggi SMS su una rete telefonica e può ordinare un articolo, tramite il computer, ad un server commerciale collegato alla rete pubblica. Il metodo prevede: (1) la trasmissione di un messaggio SMS dal sito commerciale al cliente attraverso la rete cellulare - il messaggio SMS comprende l'indirizzo all'interno della rete cellulare di un server di pagamento; (2) l'invio al server di pagamento da parte del cliente, dopo aver ricevuto il messaggio SMS sul terminale SMS, di un messaggio SMS modificato con l'aggiunta almeno dell'informazione che consente l'identificazione di mezzi di pagamento del cliente.
La domanda di brevetto WO 03/036575 descrive un attivatore universale di pagamenti che utilizza la rete telefonica mobile. L'utente può addebitare un acquisto su una carta di pagamento. Allo scopo l'utente deve fornire il numero telefonico per ogni acquisto, in modo che l'operazione possa essere approvata in un centro di processo. Il centro di processo telefona all'utente per richiedere l'autorizzazione al pagamento dopo che l'utente à ̈ stato identificato con un codice segreto. La soluzione proposta in questa domanda di brevetto consiste in una carta di pagamento che comprende le sedici cifre standard, delle quali le prime sei corrispondono al BIN (Numero di Identificazione della Banca) della società di processo, le successive nove cifre corrispondono al numero di telefono mobile dell'utente e l'ultima cifra corrisponde ad una cifra di controllo per le precedenti quindici cifre.
La Richiedente ha osservato che in molti casi le soluzioni proposte impattano in modo considerevole sulla architettura di sistema esistente, prevedendo ad esempio l’esistenza di soggetti “certificatori†con i quali deve interagire il sistema informatico del consumatore e/o del venditore e/o delle società emettitrici delle carte di credito, cosa che costringe di volta in volta gli uni o le altre a modificare pesantemente le procedure precedentemente in essere. Tutto ciò, a giudizio della Richiedente, à ̈ fortemente sgradito, al punto da dissuadere i soggetti coinvolti dall’implementare le nuove procedure, a dispetto dalla maggior sicurezza che verrebbe garantita.
In vista dello stato della tecnica precedentemente delineato, la Richiedente si à ̈ posta l’obiettivo di trovare una soluzione che permetta di incrementare la sicurezza contro frodi nel commercio elettronico, e che al contempo sia di facile e sostanzialmente immediata implementazione.
In sostanza, secondo un aspetto della presente invenzione, Ã ̈ fornito un metodo per gestire transazioni commerciali on-line fra un utente ed un offerente beni/servizi che interagiscono mediante rispettivi sistemi di elaborazione dati comunicanti attraverso una rete telematica.
Il metodo comprende:
- alla ricezione, da parte di un sistema informatico di un istituto emettitore di carte di pagamento, di una richiesta di transazione con addebito su carta di pagamento dell’utente proveniente dall’offerente i beni/servizi, fare sì che detto sistema informatico dell’istituto emettitore di carte di pagamento preliminarmente richieda all’acquirente una conferma della transazione attraverso un terminale di telefonia mobile dell’acquirente, e, in caso la conferma della transazione venga ricevuta, fare sì che detto sistema informatico dell’istituto emettitore di carte di pagamento proceda ad elaborare la transazione, mentre in caso la conferma della transazione venga negata, non procedere ad elaborare la transazione ed informare l’offerente. La richiesta di conferma della transazione o la conferma della transazione o entrambe sono inviate mediante comunicazione tramite un canale dati con il terminale di telefonia mobile dell'acquirente.
L'utente può comunicare, attraverso il rispettivo sistema di elaborazione dati ed attraverso la rete telematica, al sistema di elaborazione dati dell'offerente informazioni di una rispettiva carta di pagamento o in alternativa un numero di terminale di telefonia mobile.
Detto fare sì che il sistema informatico dell’istituto emettitore di carte di pagamento preliminarmente richieda all’acquirente una conferma della transazione può comprendere:
- fare sì che il sistema informatico dell'istituto emettitore di carte di pagamento contatti un sistema informatico di un gestore di conferme di transazioni;
- fare sì che il sistema informatico del gestore di conferme di transazioni richieda all’acquirente la conferma della transazione attraverso il terminale di telefonia mobile dell’acquirente, e, in caso la conferma della transazione venga ricevuta dal sistema informatico del gestore di conferme di transazioni, fare sì che quest'ultimo comunichi al sistema informatico dell’istituto emettitore di carte di pagamento la conferma della transazione, mentre in caso la conferma della transazione venga negata, fare sì che il sistema informatico del gestore di conferme di transazioni comunichi al sistema informatico dell'istituto emettitore di carte di pagamento un diniego della transazione.
la richiesta di conferma della transazione o la conferma della transazione o entrambe sono inviate mediante almeno uno fra: un messaggio SMS, il protocollo WAP, il protocollo HTTP, il protocollo HTTPS.
Secondo un altro aspetto della presente invenzione, à ̈ fornito un sistema di gestione di transazioni commerciali on-line fra un utente ed un offerente beni/servizi che interagiscono mediante rispettivi sistemi informatici comunicanti attraverso una rete telematica. Il sistema comprende un sistema informatico di un istituto emettitore di carte di pagamento in relazione di comunicazione con il sistema informatico dell’offerente e configurato per ricevere dal sistema informatico dell’offerente richieste di transazione monetaria mediante carta di pagamento dell’utente ed effettuare o negare le transazioni richieste sulla base di verifiche condotte sui dati identificativi della carta di pagamento dell’utente.
E' previsto un sistema informatico di gestione di conferme delle transazioni, in relazione di comunicazione con il sistema informatico dell’istituto emettitore di carte di pagamento, e configurato per:
- ricevere dal sistema informatico dell’istituto emettitore di carte di pagamento richieste di ottenimento della conferma delle transazioni monetarie richieste dal sistema informatico dell’offerente;
- interagire con l’utente attraverso un rispettivo terminale di telefonia mobile per ottenere dall’utente stesso conferme o negazioni delle transazioni;
- comunicare al sistema informatico dell’istituto emettitore di carte di pagamento le conferme o negazioni delle transazioni ottenute dall’utente,
ed in cui il sistema informatico dell’istituto emettitore delle carte di pagamento à ̈ configurato in modo tale che, alla ricezione di una richiesta di transazione monetaria da parte del sistema informatico dell’offerente, proceda ad elaborare tale transazione monetaria solo a condizione di aver preliminarmente ottenuto la conferma dell’utente. La richiesta di conferma della transazione o la conferma della transazione o entrambe sono inviate mediante comunicazione tramite un canale dati con il terminale di telefonia mobile dell'acquirente.
L'utente può comunicare, attraverso il rispettivo sistema di elaborazione dati ed attraverso la rete telematica, al sistema di elaborazione dati dell'offerente informazioni di una rispettiva carta di pagamento o in alternativa un numero di terminale di telefonia mobile.
Il sistema informatico dell'istituto emettitore di carte di pagamento à ̈ preferibilmente configurato per contattare un sistema informatico di un gestore di conferme di transazioni, ed il sistema informatico del gestore di conferme di transazioni à ̈ configurato per richiedere all’acquirente la conferma della transazione attraverso il terminale di telefonia mobile dell’acquirente, e, in caso la conferma della transazione venga ricevuta dal sistema informatico del gestore di conferme di transazioni, per comunicare al sistema informatico dell’istituto emettitore di carte di pagamento la conferma della transazione, mentre in caso la conferma della transazione venga negata, per comunicare al sistema informatico dell'istituto emettitore di carte di pagamento un diniego della transazione.
la richiesta di conferma della transazione o la conferma della transazione o entrambe sono inviate mediante almeno uno fra: un messaggio SMS, il protocollo WAP, il protocollo HTTP, il protocollo HTTPS. Queste ed altre caratteristiche ed i vantaggi della presente invenzione saranno resi maggiormente evidenti dalla seguente descrizione dettagliata di sue possibili forme di realizzazione pratica, e di alcune possibili varianti, descrizione che peraltro viene fornita a puro titolo di esempio non limitativo, e che verrà condotta facendo riferimento agli uniti disegni, nei quali:
la Figura 1 mostra schematicamente il contesto architetturale tradizionale in cui si effettuano transazioni di commercio elettronico;
la Figura 2 mostra sempre schematicamente una soluzione in accordo con una forma di realizzazione della presente invenzione;
la Figura 3 esemplifica le principali azioni svolte da un sistema server di un istituto erogatore di carte di pagamento e da un sistema server di gestione di operazioni relative all’ottenimento da parte dell’acquirente di una conferma della transazione, in accordo con una forma di realizzazione della presente invenzione.
Con riferimento ai disegni, in Figura 1 Ã ̈ schematicamente mostrato il classico contesto architetturale in cui si effettuano transazioni di commercio elettronico, in particolare con pagamento mediante carta di credito.
Utenti 105a, 105b,…, equipaggiati di rispettivi elaboratori dati, quali ad esempio Personal Computer (PC) o smart-phone o un telefono cellulare, hanno accesso ad Internet 115 attraverso rispettivi punti di accesso 110. La connessione ad Internet può avvenire attraverso la rete telefonica fissa e/o la rete di telefonia mobile e/o "hot-spot" WiFi.
Gli utenti 105a, 105b,…accedono a siti Internet di soggetti offerenti in vendita beni e/o servizi, tali siti essendo tipicamente ospitati su sistemi server (Web server o Application server) 120a, 120b,…connessi ad Internet. Su tali siti dei venditori, gli utenti possono sfogliare cataloghi di prodotti/servizi offerti on-line, scegliere i prodotti/servizi di interesse, ed effettuare acquisti dei prodotti/servizi prescelti, compilando, sempre on-line, opportuni ordini di acquisto, secondo le modalità stabilite dallo specifico venditore. Normalmente, quando l’utente effettua un acquisto, gli/le viene richiesto di specificare una forma di pagamento, e la forma più naturale ed immediata di pagamento à ̈ mediante carta di credito (spesso questa può anche essere l’unica forma accettata dal venditore, oppure può essere la forma di pagamento che, fra le altre possibili, consente all’utente di ottenere sconti sul prezzo o riduzioni sulle spese di consegna del prodotto acquistato). Per effettuare il pagamento mediante carta di credito, l’utente deve fornire al venditore i dati della propria carta di credito, tipicamente il numero della carta, il nominativo dell’intestatario, la data di scadenza della carta, eventualmente un codice identificativo di sicurezza della carta; tutti questi dati sono comunicati al venditore on-line, compilando opportuni moduli virtuali.
Ricevuto l’ordine di acquisto ed i dati della carta di credito dell’acquirente, il sistema server 120a, 120b,… che ospita il sito Internet del venditore contatta, attraverso Internet oppure attraverso una connessione di altro tipo, ad esempio telefonicamente, un sistema server 125 dell’istituto emettitore della carta di credito dell’acquirente. Il sistema server 125 dell’istituto emettitore della carta di credito verifica la congruità dei dati immessi dall’acquirente e comunicatigli dal sistema server del venditore, verifica che la carta di credito sia attiva (ad esempio, verifica che essa non sia stata bloccata a seguito di una denuncia di smarrimento o furto), verifica che il massimale di spesa mensile consentito all'acquirente non sia stato superato e, se tutte le verifiche danno esito positivo, il sistema server 125 dell’istituto emettitore della carta di credito dell’acquirente comunica il buon esito della transazione al sistema server 120a, 120b,… che ospita il sito Internet del venditore, ed inoltre comunica (nei tempi previsti dal contratto di emissione della carta di credito, ad esempio alla fine del mese solare) all’istituto di credito/bancario (ad esempio ad un sistema server 130a, 130b,… dell’istituto bancario) presso il quale l’acquirente ha appoggiato la propria carta di credito l’addebito dell’importo della transazione sul conto corrente dell’acquirente. Il venditore, ricevuta dall’istituto emettitore della carta di credito la conferma del buon esito della transazione, ed avendo così garanzia che il pagamento avverrà regolarmente, provvedere a fornire all’acquirente la prestazione richiesta (ad esempio inviandogli/le, il/i prodotto/i acquistati, per posta o in altro modo, anche in funzione della natura del/i prodotti).
Questo sistema espone l’acquirente ed il venditore ai rischi discussi in precedenza.
La Figura 2 mostra schematicamente una soluzione in accordo con una forma di realizzazione della presente invenzione, in grado di aumentare la sicurezza nelle transazioni di commercio elettronico.
In accordo con una forma di realizzazione della presente invenzione, il sistema server 225 dell’istituto emettitore della carta di pagamento (ad esempio, carta di credito oppure di debito) dell’acquirente à ̈ configurato in modo da interagire non solo con il sistema server 120a, 120b,… che ospita il sito Internet del venditore e con il sistema server 130a, 130b… dell’istituto di credito/bancario presso il quale l’acquirente ha appoggiato la propria carta di pagamento, ma anche con un sistema server 205 di un soggetto preposto a gestire operazioni di conferma delle transazioni da parte degli acquirenti stessi. Il sistema server 205, per la gestione delle operazioni di conferma della transazione, interagisce con i sistemi di un operatore di rete di telefonia mobile (reale o virtuale), oppure il sistema server 205 può essere gestito direttamente da un operatore di rete di telefonia mobile (reale o virtuale), per consentire di contattare l’acquirente attraverso il proprio telefono cellulare 210a, 210b,… (che potrebbe essere il medesimo terminale attraverso il quale gli utenti 105a, 105b,… si connettono attraverso Internet 115 ai siti dei venditori 120a, 120b,…). La conferma della transazione da parte degli utenti 105a, 105b,… avviene ad esempio mediante scambio di messaggi SMS o MMS 215a, 215b tra il sistema server di conferma transazioni 205 ed i telefoni cellulari 210a, 210b,… degli utenti 105a, 105b,…., come descritto in maggior dettaglio nel prosieguo.
Il generico utente 105a, 105b,… che desideri usufruire del servizio di conferma delle transazioni on-line con carta di pagamento deve innanzitutto registrarsi presso il fornitore di tale servizio e sottoscrivere il servizio medesimo. La sottoscrizione del servizio può avvenire in un qualsiasi modo, per esempio attraverso un sito Web del gestore delle operazioni di conferma delle transazioni o del gestore della rete di telefonia cellulare. La sottoscrizione del servizio può comportare il rilascio all’utente che lo sottoscrive di una nuova scheda SIM (Subscriber Identity Module), con memorizzato uno specifico software applicativo (ad esempio, un software applicativo SIM Application Toolkit), eseguibile dal telefono cellulare dell’utente, per gestire le operazioni relative alla conferma delle transazioni (come descritto in dettaglio nel seguito), oppure, alla sottoscrizione del servizio, e se la scheda SIM lo permette, l’utente può ricevere il software applicativo da installare sulla scheda SIM da una piattaforma del gestore delle operazioni di conferma delle transazioni o del gestore della rete di telefonia cellulare, mediante messaggi SMS (come nel caso della piattaforma “InteracTIM†di Telecom Italia), o ancora, nel caso l’utente possegga un telefono cellulare (tipicamente uno smart-phone) dotato di sistema operativo “aperto†(quale ad esempio Symbian, Windows Mobile, iPhone, BlackBerry), il software applicativo può essere scaricato da un sito Web del gestore delle operazioni di conferma delle transazioni o del gestore della rete di telefonia cellulare, mediante protocollo WAP (Web Application Protocol).
Una volta che il generico utente ha sottoscritto il servizio, un rispettivo profilo utente viene creato presso il sistema server 205 del gestore delle operazioni di conferma delle transazioni. Il profilo utente comprende in particolare i dati anagrafici dell’utente ed il numero di telefono cellulare. Il gestore del servizio di conferma delle transazioni comunica inoltre l’avvenuta registrazione dell’utente al rispettivo istituto emettitore della carta di pagamento posseduta dall’utente.
Con riferimento alla Figura 3, si supponga che l’utente 105a desideri effettuare un acquisto di prodotti/servizi offerti in vendita on-line da un venditore attraverso il sistema server 120a. Come di consueto, l’utente 105a accede attraverso il proprio PC od il proprio smart-phone o telefono cellulare al sito Internet del venditore ospitato sul sistema server 120a, sceglie il(i) prodotto(i)/servizi(o) di interesse, e compila on-line l’ordine di acquisto, specificando come forma di pagamento quella mediante carta di pagamento. Su richiesta del venditore, l’utente fornisce allo stesso, sempre on-line, i dati della propria carta di pagamento, tipicamente il numero della carta, il nominativo dell’intestatario, la data di scadenza della carta, eventualmente un codice identificativo di sicurezza della carta.
Ricevuto l’ordine di acquisto ed i dati della carta di pagamento dell’acquirente 105a, il sistema server 120a che ospita il sito Internet del venditore contatta il sistema server 225 dell’istituto emettitore della carta di pagamento dell’acquirente 105a e fornisce allo stesso i dati immessi dall’acquirente 105a. Tutte queste operazioni si svolgono come di consueto.
Il sistema server 225 dell’istituto emettitore della carta di pagamento come prima cosa accerta se l’acquirente 105a à ̈ registrato al servizio di conferma delle transazioni on-line (blocco 305). Tale controllo viene effettuato sulla base di dati quali il numero di carta di pagamento ed il nominativo dell’intestatario della stessa forniti dall’acquirente 105a e ricevuti dal sistema server 120a del venditore; per effettuare tale controllo, il sistema server 225 può ad esempio avvalersi della consueta base dati di utenti titolari di carte di pagamento, integrata con informazioni circa il fatto se il generico titolare di carta di pagamento à ̈ anche registrato al servizio di conferma delle transazioni.
Se l’acquirente 105 non risulta registrato al servizio di conferma delle transazioni (ramo di uscita NO del blocco 305), le operazioni svolte dal sistema server 225 sono quelle tradizionali (il tradizionale sistema server 125 dell’istituto emettitore della carta di pagamento verifica la congruità dei dati immessi dall’acquirente, verifica che la carta di pagamento sia attiva - ad esempio, verifica che essa non sia stata bloccata a seguito di una denuncia di smarrimento o furto -, verifica che il massimale di spesa mensile non sia stato superato; se tutte le verifiche danno esito positivo, il tradizionale sistema server 125 dell’istituto emettitore della carta di pagamento dell’acquirente comunica il buon esito della transazione al sistema server 120a, 120b,… che ospita il sito Internet del venditore, ed inoltre comunica al sistema server 130a, 130b dell’istituto di credito/bancario presso il quale l’acquirente ha appoggiato la propria carta di pagamento l’addebito dell’importo della transazione sul conto corrente dell’acquirente. Il venditore, ricevuta dall’istituto emettitore della carta di pagamento la conferma del buon esito della transazione, provvedere a fornire all’acquirente la prestazione richiesta).
Se viceversa l’utente 105a risulta iscritto al servizio di conferma delle transazioni (ramo di uscita SI del blocco 305), il sistema server 225 dell’istituto emettitore della carta di pagamento dell’acquirente 105a avvia una procedura di richiesta ed ottenimento di una conferma della transazione da parte dell’acquirente 105a (blocco 310). Tale procedura prevede che il sistema server 225 dell’istituto emettitore della carta di pagamento contatti 315 il sistema server 205 del gestore del servizio di conferma delle transazioni, fornendogli i dati anagrafici dell’acquirente. Il sistema server 205 del gestore del servizio di conferma delle transazioni verifica in primo luogo che l’utente 105a sia effettivamente iscritto al servizio di conferma delle transazioni (blocco 320); a tal fine, viene condotta una ricerca nella base dati dei profili degli utenti registrati, sfruttando come chiave di ricerca i dati anagrafici dell’acquirente.
Se l’utente 105a non risulta registrato al servizio (ramo di uscita NO del blocco 320), il sistema server 205 del gestore della conferma delle transazioni ne dà comunicazione 325 al sistema server 225 dell’istituto emettitore della carta di pagamento. L'utente può non risultare registrato al servizio di conferma delle transazioni – dal punto di vista del sistema server 205 del gestore del servizio di conferma delle transazioni - perché in quel momento egli/ella non ha il proprio telefono cellulare acceso oppure à ̈ fuori copertura. Ad esempio, la comunicazione 325 data al sistema server 225 dell’istituto emettitore della carta di pagamento corrisponde ad una notifica di “transazione non confermata da parte dell’acquirente†.
Se viceversa l’utente 105a risulta registrato al servizio (ramo di uscita SI del blocco 320), viene inviata al telefono cellulare 210a dell’utente 105a una richiesta di conferma della transazione. A tal fine, viene creato (blocco 330) un SMS con opportuna formattazione, e, attraverso un Centro servizi SMS (SMS Center o SMSC) 335 dell’operatore di telefonia cellulare a cui risulta abbonato l’utente 105a, l’SMS 215a viene inviato al telefono cellulare 210a dell’utente 105a. L’SMSC 335, sebbene raffigurato come parte del sistema server 205 del gestore del servizio di conferma delle transazioni, non necessariamente deve essere tale, cosa vera in particolare nel caso in cui il gestore del servizio di conferma delle transazioni non sia un operatore di rete telefonica cellulare.
In particolare, l’SMS 215a che viene inviato al telefono cellulare dell’utente 105a può essere un SMS recante dati e che, una volta ricevuto dal telefono cellulare 210a, attiva il software applicativo installato sul telefono cellulare 210a o sulla SIM inserita nello stesso. L’SMS 215a, che conterrà anche i dettagli della transazione di cui viene richiesta la conferma (ad esempio, l'importo in denaro della transazione, un codice identificativo della transazione o un identificativo del venditore), può essere cifrato, ad esempio con cifratura 3DES, per garantire la riservatezza dei dati.
Alla ricezione dell’SMS 215a, il software applicativo residente sul telefono cellulare 210a dell’utente 105a interpreta il messaggio (se il messaggio à ̈ cifrato, prima lo decifra), e richiede all’utente 105a una conferma della transazione, ad esempio mediante una finestra “pop-up†che viene mostrata sullo schermo del telefono cellulare 210a, nella quale sono ad esempio riportati i dettagli della transazione, e che invita l’utente 105a a confermare o meno la transazione stessa. Per confermare o negare la transazione, l’utente potrà avvalersi della tastiera del telefono cellulare 210a, eventualmente di tasti †virtuali†(“soft-key†) “SI†e “NO†nel caso il telefono cellulare 210a sia di tipo “touch screen†.
Per esempio, l’utente 105a, verificata la corrispondenza dei dettagli sulla transazione di cui viene chiesta conferma con i dati della transazione che egli/ella intende effettuare, può confermare la transazione stessa. Viceversa, se l’utente 105a si vede pervenire una richiesta di conferma di una transazione che egli/ella non ha mai inteso effettuare (cosa che può ad esempio avvenire qualora un terzo, fraudolentemente entrato in possesso dei dati della carta di pagamento dell’utente 105a, o addirittura della carta di pagamento stessa, tenti di utilizzarli per effettuare transazioni senza il consenso del legittimo titolare), l’utente 105a potrà non confermare la transazione.
Il software applicativo residente sul telefono cellulare 210a “cattura†la scelta compiuta dall’utente 105a, e compila un SMS di ritorno, che pure potrà essere cifrato come l’SMS di andata 215a a garanzia della riservatezza delle informazioni. L’SMS di ritorno 215b viene poi inviato dal telefono cellulare 210a al sistema 205 del gestore del servizio di conferma delle transazioni, in particolare ad un server di gestione delle risposte 350; vantaggiosamente, il server di gestione delle risposte può essere associato ad un cosiddetto “Large Account†, ovverosia ad un numero telefonico breve associato, dal gestore della rete di telefonia cellulare, al servizio di conferma delle transazioni.
Il server di gestione delle risposte 350 riceve il messaggio, eventualmente lo decifra e quindi lo interpreta per stabilire se l’utente 105a ha confermato o meno la relativa transazione on-line.
La risposta da parte dell’utente 105a viene passata al sistema server 225 dell’istituto emettitore della carta di pagamento dell’acquirente 105a (blocco 310), che à ̈ così in grado di stabilire se l’acquirente 105a ha confermato o meno la transazione. In caso negativo (ramo di uscita NO del blocco 310), il sistema server 225 dell’istituto emettitore della carta di pagamento dell’acquirente 105a comunica 340 al sistema server 120a che ospita il sito del venditore che la transazione richiesta non à ̈ stata confermata dall’acquirente 105a. La notifica al sistema server 120a che ospita il sito Internet del venditore può ad esempio essere una generica notifica di transazione negata, oppure potrà specificare che la transazione à ̈ stata negata in seguito a mancata conferma da parte dell’acquirente 105a titolare della carta di pagamento. La stessa comunicazione di non-conferma della transazione viene ad esempio data nel caso il sistema 205 del gestore del servizio di conferma delle transazioni stabilisca che l’utente 105a non à ̈ registrato al servizio. Se invece l’utente 105a ha confermato la transazione (ramo di uscita SI del blocco 310), il sistema server 225 dell’istituto emettitore della carta di pagamento dell’acquirente 105a effettua le consuete operazioni: il tradizionale sistema server 125 dell’istituto emettitore della carta di pagamento verifica la congruità dei dati immessi dall’acquirente, verifica che la carta di pagamento sia attiva - ad esempio, verifica che essa non sia stata bloccata a seguito di una denuncia di smarrimento o furto -, verifica che il massimale di spesa mensile non sia stato superato; se tutte le verifiche danno esito positivo, il tradizionale sistema server 125 dell’istituto emettitore della carta di pagamento dell’acquirente comunica il buon esito della transazione al sistema server 120a, 120b,… che ospita il sito Internet del venditore, ed inoltre comunica al sistema server 130a, 130b dell’istituto di credito/bancario presso il quale l’acquirente ha appoggiato la propria carta di pagamento l’addebito dell’importo della transazione sul conto corrente dell’acquirente. Il venditore, ricevuta dall’istituto emettitore della carta di pagamento la conferma del buon esito della transazione, provvedere a fornire all’acquirente la prestazione richiesta.
Varie sono le possibili alternative alla forma di realizzazione sopra descritta. Per esempio, anziché tramite SMS, la richiesta di conferma della transazione, e/o la conseguente risposta da parte dell’acquirente 105a, può avvenire attraverso comunicazione su un diverso canale dati tra il telefono cellulare 210a dell’acquirente 105a ed il sistema server 205 del gestore del servizio di conferma delle transazioni, ad esempio sfruttando il protocollo WAP (Wireless Application Protocol), HTTP (Hyper Text Transfer Protocol) o HTTPS (Hyper Text Transfer Protocol over Secure socket layer). Per esempio, il sistema server 205 del gestore del servizio di conferma delle transazioni può inviare al telefono cellulare 210a dell’acquirente 105a un WAP-Push che determina l’apertura del client browser residente sul telefono cellulare 105a su una pagina corrispondente ad una specifica URL (Universal Resource Locator) che corrisponde al server di gestione delle risposte 350; l’utente 105a potrà quindi, interagendo col browser in esecuzione sul proprio telefono cellulare 210a, immettere direttamente la risposta desiderata (“SI†: conferma della transazione – “NO†: transazione non confermata).
Come à ̈ possibile apprezzare dalla descrizione dettagliata sopra fornita, l’implementazione della soluzione secondo la presente invenzione à ̈ del tutto trasparente per il (sistema server che ospita il sito Internet del) venditore, il quale interagisce in maniera del tutto tradizionale con il sistema server dell’istituto emettitore delle carte di pagamento. Ciò à ̈ un significativo vantaggio poiché l’implementazione della soluzione secondo la presente invenzione non costringe i venditori on-line a modificare i propri sistemi.
Anche dal punto di vista degli istituti emettitori delle carte di pagamento, l’implementazione della soluzione secondo la presente invenzione ha un impatto minimo, in quanto prevede l’aggiunta di minime funzionalità a monte delle funzionalità già tradizionalmente implementate.
Grazie a tutto ciò, la Richiedente ritiene che la soluzione secondo la presente invenzione, che introduce un elevato grado di sicurezza nelle transazioni di ecommerce, potrà essere accolta senza resistenze e con favore dai vari soggetti coinvolti in quel genere di transazioni.
In una forma di realizzazione alternativa della presente invenzione, al fine di garantire una ancora maggior sicurezza per gli utenti, quando un utente desidera effettuare un acquisto di beni/servizi offerti in vendita da un venditore attraverso un proprio sito Internet (ospitato sul sistema server 120a, 120b,...), all''utente stesso può essere richiesto di specificare se egli/ella à ̈ iscritto al servizio di conferma delle transazioni, nel qual caso, in luogo di inserire i dati della propria carta di pagamento, l'utente potrà inserire soltanto il proprio numero di telefono cellulare (il numero che risulta registrato presso il sistema 205 del gestore delle conferme delle transazioni). Il sistema server 120a, 120b,... del venditore comunicherà in tal caso al sistema server 225 dell'istituto che ha emesso la carta di pagamento dell'acquirente il numero di telefono cellulare dell'acquirente, e tale numero di telefono cellulare verrà comunicato al sistema 205 del gestore di conferme delle transazioni. Quest'ultimo, verificato che il numero di telefono cellulare immesso dall'acquirente corrisponde ad un utente registrato al servizio di conferma delle transazioni, effettuerà le medesime operazioni sopra descritte.
Questa forma di realizzazione, rispetto a quella precedentemente descritta, ha l'ulteriore vantaggio che l'utente non deve inserire i dati sensibili della propria carta di pagamento, senza dunque correre il rischio che tali dati possano essere "sniffati" abusivamente.
La presente invenzione à ̈ stata qui descritta facendo riferimento ad alcune sue possibili forme di realizzazione pratica, che devono intendersi come puramente esemplificative e non limitative. I tecnici del ramo saranno in grado, sulla base degli insegnamenti qui forniti, di escogitare diverse forme di realizzazione, o varianti alle forme di realizzazione descritte, senza per questo fuoriuscire dall'ambito di tutela dell'invenzione definito nelle seguenti rivendicazioni.
* * * * *
Claims (10)
- RIVENDICAZIONI 1. Metodo per gestire transazioni commerciali on-line fra un utente (105a) ed un offerente beni/servizi (120a) che interagiscono mediante rispettivi sistemi di elaborazione dati comunicanti attraverso una rete telematica (115), il metodo essendo caratterizzato dal fatto di comprendere: - alla ricezione, da parte di un sistema informatico (225) di un istituto emettitore di carte di pagamento, di una richiesta di transazione con addebito su carta di pagamento dell’utente proveniente dall’offerente i beni/servizi, fare sì che detto sistema informatico dell’istituto emettitore di carte di pagamento preliminarmente richieda all’acquirente una conferma della transazione attraverso un terminale di telefonia mobile (210a) dell’acquirente, e, in caso la conferma della transazione venga ricevuta, fare sì che detto sistema informatico dell’istituto emettitore di carte di pagamento proceda ad elaborare la transazione, mentre in caso la conferma della transazione venga negata, non procedere ad elaborare la transazione ed informare l’offerente, in cui la richiesta di conferma della transazione o la conferma della transazione o entrambe sono inviate mediante comunicazione tramite un canale dati con il terminale di telefonia mobile dell'acquirente.
- 2. Il metodo di rivendicazione 1, in cui l'utente comunica, attraverso il rispettivo sistema di elaborazione dati ed attraverso la rete telematica, al sistema di elaborazione dati dell'offerente informazioni di una rispettiva carta di pagamento o in alternativa un numero di terminale di telefonia mobile.
- 3. Il metodo di rivendicazione 1 o 2, in cui detto fare sì che il sistema informatico dell’istituto emettitore di carte di pagamento preliminarmente richieda all’acquirente una conferma della transazione comprende: - fare sì che il sistema informatico dell'istituto emettitore di carte di pagamento contatti un sistema informatico (205) di un gestore di conferme di transazioni; - fare sì che il sistema informatico del gestore di conferme di transazioni richieda all’acquirente la conferma della transazione attraverso il terminale di telefonia mobile dell’acquirente e, in caso la conferma della transazione venga ricevuta dal sistema informatico del gestore di conferme di transazioni, fare sì che quest'ultimo comunichi al sistema informatico dell’istituto emettitore di carte di pagamento la conferma della transazione, mentre in caso la conferma della transazione venga negata, fare sì che il sistema informatico del gestore di conferme di transazioni comunichi al sistema informatico dell'istituto emettitore di carte di pagamento un diniego della transazione.
- 4. Il metodo di una qualunque delle rivendicazioni precedenti, in cui la richiesta di conferma della transazione o la conferma della transazione o entrambe sono inviate mediante almeno uno fra: un messaggio SMS, il protocollo WAP, il protocollo HTTP, il protocollo HTTPS.
- 5. Il metodo di rivendicazione 4, in cui la richiesta di conferma della transazione à ̈ inviata al terminale di telefonia mobile dell’utente in modalità “push†.
- 6. Un sistema di gestione di transazioni commerciali on-line fra un utente (105a) ed un offerente beni/servizi (120a) che interagiscono mediante rispettivi sistemi informatici comunicanti attraverso una rete telematica, il sistema comprendendo: - un sistema informatico (225) di un istituto emettitore di carte di pagamento in relazione di comunicazione con il sistema informatico dell’offerente e configurato per ricevere dal sistema informatico dell’offerente richieste di transazione monetaria mediante carta di pagamento dell’utente ed effettuare o negare le transazioni richieste sulla base di verifiche condotte sui dati identificativi della carta di pagamento dell’utente, caratterizzato dal fatto di comprendere: - un sistema informatico (205) di gestione di conferme delle transazioni, in relazione di comunicazione con il sistema informatico dell’istituto emettitore di carte di pagamento, e configurato per: - ricevere dal sistema informatico dell’istituto emettitore di carte di pagamento richieste di ottenimento della conferma delle transazioni monetarie richieste dal sistema informatico dell’offerente; - interagire con l’utente attraverso un rispettivo terminale di telefonia mobile (210a) per ottenere dall’utente stesso conferme o negazioni delle transazioni; - comunicare al sistema informatico dell’istituto emettitore di carte di pagamento le conferme o negazioni delle transazioni ottenute dall’utente, ed in cui il sistema informatico dell’istituto emettitore delle carte di pagamento à ̈ configurato in modo tale che, alla ricezione di una richiesta di transazione monetaria da parte del sistema informatico dell’offerente, proceda ad elaborare tale transazione monetaria solo a condizione di aver preliminarmente ottenuto la conferma dell’utente, in cui la richiesta di conferma della transazione o la conferma della transazione o entrambe sono inviate mediante comunicazione tramite un canale dati con il terminale di telefonia mobile dell'acquirente.
- 7. Il sistema di rivendicazione 6, in cui l'utente comunica, attraverso il rispettivo sistema di elaborazione dati ed attraverso la rete telematica, al sistema di elaborazione dati dell'offerente informazioni di una rispettiva carta di pagamento o in alternativa un numero di terminale di telefonia mobile.
- 8. Il sistema di rivendicazione 6 o 7, in cui il sistema informatico dell'istituto emettitore di carte di pagamento à ̈ configurato per contattare un sistema informatico (205) di un gestore di conferme di transazioni, ed il sistema informatico del gestore di conferme di transazioni à ̈ configurato per richiedere all’acquirente la conferma della transazione attraverso il terminale di telefonia mobile dell’acquirente, e, in caso la conferma della transazione venga ricevuta dal sistema informatico del gestore di conferme di transazioni, per comunicare al sistema informatico dell’istituto emettitore di carte di pagamento la conferma della transazione, mentre in caso la conferma della transazione venga negata, per comunicare al sistema informatico dell'istituto emettitore di carte di pagamento un diniego della transazione.
- 9. Il sistema di una qualunque delle rivendicazioni 6, 7, 8, in cui la richiesta di conferma della transazione o la conferma della transazione o entrambe sono inviate mediante almeno uno fra: un messaggio SMS, il protocollo WAP, il protocollo HTTP, il protocollo HTTPS.
- 10. Il sistema di rivendicazione 9, in cui la richiesta di conferma della transazione à ̈ inviata al terminale di telefonia mobile dell’utente in modalità “push†. * * * * *
Priority Applications (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| ITMI2009A002355A IT1397373B1 (it) | 2009-12-30 | 2009-12-30 | Metodo per gestire transazioni commerciali on-line. |
| US12/982,525 US10614466B2 (en) | 2009-12-30 | 2010-12-30 | Method for managing on-line commercial transactions |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| ITMI2009A002355A IT1397373B1 (it) | 2009-12-30 | 2009-12-30 | Metodo per gestire transazioni commerciali on-line. |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| ITMI20092355A1 true ITMI20092355A1 (it) | 2011-06-30 |
| IT1397373B1 IT1397373B1 (it) | 2013-01-10 |
Family
ID=42320972
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| ITMI2009A002355A IT1397373B1 (it) | 2009-12-30 | 2009-12-30 | Metodo per gestire transazioni commerciali on-line. |
Country Status (2)
| Country | Link |
|---|---|
| US (1) | US10614466B2 (it) |
| IT (1) | IT1397373B1 (it) |
Families Citing this family (6)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US9984375B2 (en) | 2013-08-15 | 2018-05-29 | Teleperformance Se | Client for securely and efficiently transferring sensitive information via a telephone |
| US9992337B2 (en) | 2013-08-15 | 2018-06-05 | Teleperformance Se | Securely and efficiently transferring sensitive information via a telephone |
| US9026464B2 (en) * | 2013-08-15 | 2015-05-05 | Teleperformance SA | Securely and efficiently processing telephone orders |
| US20160366110A1 (en) * | 2015-05-15 | 2016-12-15 | Manouchehr Shahbaz | Secured cell phone communication system |
| SG10201510507PA (en) * | 2015-12-21 | 2017-07-28 | Mastercard International Inc | Methods and systems for making a payment |
| US11636220B2 (en) * | 2019-02-01 | 2023-04-25 | Intertrust Technologies Corporation | Data management systems and methods |
Family Cites Families (31)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US5991749A (en) * | 1996-09-11 | 1999-11-23 | Morrill, Jr.; Paul H. | Wireless telephony for collecting tolls, conducting financial transactions, and authorizing other activities |
| US6327578B1 (en) * | 1998-12-29 | 2001-12-04 | International Business Machines Corporation | Four-party credit/debit payment protocol |
| IL150428A0 (en) * | 2000-03-17 | 2002-12-01 | Tradesafely Com Ltd | Payment authorisation method and apparatus |
| GB2369711A (en) * | 2000-11-14 | 2002-06-05 | Vcheq Com Pte Ltd | An electronic funds transfer system for processing multiple currency transactions |
| WO2003036575A1 (es) | 2001-10-26 | 2003-05-01 | Servicios Para Medios De Pago, S.A. | Activador universal de pagos a traves de telefonia movil |
| US20060253335A1 (en) * | 2003-01-22 | 2006-11-09 | Gerard Keena | Cash based purchasing using mobile communication |
| US7139372B2 (en) * | 2003-03-07 | 2006-11-21 | July Systems, Inc | Authorized distribution of digital content over mobile networks |
| US7826828B2 (en) * | 2003-04-29 | 2010-11-02 | Comverse, Ltd. | Method and system for detecting availability of a wireless device |
| CN1635525A (zh) * | 2003-12-31 | 2005-07-06 | 中国银联股份有限公司 | 一种安全的网上支付系统及安全的网上支付认证方法 |
| US8468093B2 (en) | 2004-03-25 | 2013-06-18 | International Business Machines Corporation | Method and system for performing a commercial transaction by using a short message service terminal |
| US7451921B2 (en) * | 2004-09-01 | 2008-11-18 | Eric Morgan Dowling | Methods, smart cards, and systems for providing portable computer, VoIP, and application services |
| US8639629B1 (en) * | 2005-02-02 | 2014-01-28 | Nexus Payments, LLC | System and method for accessing an online user account registry via a thin-client unique user code |
| EP2667345A3 (en) * | 2005-10-06 | 2014-08-27 | C-Sam, Inc. | Transactional services |
| US7543182B2 (en) * | 2006-01-12 | 2009-06-02 | International Business Machines Corporation | Automated failover system for logical partitions |
| US7873573B2 (en) * | 2006-03-30 | 2011-01-18 | Obopay, Inc. | Virtual pooled account for mobile banking |
| US8467766B2 (en) * | 2006-07-06 | 2013-06-18 | Qualcomm Incorporated | Methods and systems for managing payment sources in a mobile environment |
| US8510223B2 (en) * | 2006-08-03 | 2013-08-13 | The Western Union Company | Money transfer transactions via pre-paid wireless communication devices |
| US8909553B2 (en) * | 2006-09-06 | 2014-12-09 | Transaction Wireless, Inc. | Payment card terminal for mobile phones |
| WO2008047330A2 (en) | 2006-10-19 | 2008-04-24 | Firstrand Bank Limited | Financial transaction system and method |
| US7600676B1 (en) * | 2006-12-26 | 2009-10-13 | Cellco Partnership | Two factor authentications for financial transactions |
| US20080229098A1 (en) * | 2007-03-12 | 2008-09-18 | Sips Inc. | On-line transaction authentication system and method |
| US20080294556A1 (en) * | 2007-05-24 | 2008-11-27 | Jim Anderson | Mobile commerce service |
| US9141435B2 (en) * | 2007-07-30 | 2015-09-22 | Sybase, Inc. | System and methodology providing workload management in database cluster |
| US20090063312A1 (en) * | 2007-08-28 | 2009-03-05 | Hurst Douglas J | Method and System for Processing Secure Wireless Payment Transactions and for Providing a Virtual Terminal for Merchant Processing of Such Transactions |
| CN101458794A (zh) * | 2007-12-10 | 2009-06-17 | 国际商业机器公司 | 增强支付安全性的系统及其方法以及支付中心 |
| US8788414B2 (en) * | 2007-12-21 | 2014-07-22 | Metabank | Transfer account systems, computer program products, and computer-implemented methods to prioritize payments from preselected bank account |
| SK50042008A3 (sk) * | 2008-01-04 | 2009-09-07 | Logomotion, S. R. O. | Spôsob a systém autentifikácie najmä pri platbách, identifikátor totožnosti a/alebo súhlasu |
| US8412625B2 (en) * | 2008-08-25 | 2013-04-02 | Bruno Pilo' & Associates, Llc | System and methods for a multi-channel payment platform |
| US8245044B2 (en) * | 2008-11-14 | 2012-08-14 | Visa International Service Association | Payment transaction processing using out of band authentication |
| US8996065B2 (en) * | 2008-12-24 | 2015-03-31 | Telecom Italia S.P.A. | Method for automatically transferring an application in a mobile communication terminal of telecommunication networks |
| US20130018779A1 (en) * | 2011-07-14 | 2013-01-17 | Bank Of America Corporation | Alias-based merchant transaction system |
-
2009
- 2009-12-30 IT ITMI2009A002355A patent/IT1397373B1/it active
-
2010
- 2010-12-30 US US12/982,525 patent/US10614466B2/en active Active
Non-Patent Citations (1)
| Title |
|---|
| The only identifiable technical aspects of the claimed invention relate to the use of conventional, general-purpose data processing technology for processing data of an inherently non-technical nature. The notoriety of such prior art cannot reasonably be contested. cf. Official Journal 11/2007, 592. * |
Also Published As
| Publication number | Publication date |
|---|---|
| US20110289000A1 (en) | 2011-11-24 |
| IT1397373B1 (it) | 2013-01-10 |
| US10614466B2 (en) | 2020-04-07 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US10275760B2 (en) | Method and apparatus for authorizing a payment via a remote device | |
| KR100344114B1 (ko) | 단문 메세지 서비스를 이용한 전자결제 승인방법 및 시스템 | |
| KR100466400B1 (ko) | 단문 메시지 서비스를 이용한 전자결제 승인방법 및 시스템 | |
| KR100368600B1 (ko) | 무선망 기반 결제승인장치 및 결제승인방법 | |
| US20050080634A1 (en) | Method and network element for paying by a mobile terminal through a communication network | |
| US20150199658A1 (en) | System and method for electronic payment, and server, communication terminal and program therefor | |
| US20020049914A1 (en) | Electronic service system using safe user information management scheme | |
| JP2001512872A (ja) | 広域ネットワーク上の小売り方法 | |
| JP2007109014A (ja) | 短文メッセージサービスを用いた電子決済承認方法及びシステム | |
| US20160125407A1 (en) | Systems and Methods for Secure Remote Payments | |
| ITMI20092355A1 (it) | Metodo per gestire transazioni commerciali on-line | |
| JP3590588B2 (ja) | 電子商取引のための方法及びシステム | |
| KR20030082090A (ko) | 전자 지불 결제 방법 및 시스템 | |
| JP2011044151A (ja) | 安全な携帯端末支払いのための方法とシステム | |
| KR101439136B1 (ko) | 결제 채널 관리 시스템 | |
| KR20020032821A (ko) | 이동통신 단말기를 이용한 전자상거래 결제 시스템 및 그방법 | |
| WO2003005270A1 (en) | System and procedure for mobile electronic commerce | |
| WO2014077770A1 (en) | Method for making a payment using a portable communication device | |
| KR20100132325A (ko) | 휴대폰 번호 기반 결제에서의 보안 시스템 및 방법, 그리고 이에 적용되는 장치 | |
| KR20170024518A (ko) | 디지털 콘텐츠를 제공하는 방법, 서버 및 시스템 | |
| EP2958043B1 (en) | Method for the recognition of user profiles | |
| KR20000054200A (ko) | 신용카드 결제시스템을 이용한 인터넷 광고방법 | |
| KR101548200B1 (ko) | 모바일 Push를 이용한 충전식 전자상거래시스템 | |
| KR20060055671A (ko) | 현금 영수증 발급 시스템 | |
| KR20030065962A (ko) | 가상 무선 단말기를 이용한 전자 결제 방법 및 시스템 |