ES2340466T3 - Procedimiento para ejecutar transacciones de pago en una red de datos. - Google Patents
Procedimiento para ejecutar transacciones de pago en una red de datos. Download PDFInfo
- Publication number
- ES2340466T3 ES2340466T3 ES02018744T ES02018744T ES2340466T3 ES 2340466 T3 ES2340466 T3 ES 2340466T3 ES 02018744 T ES02018744 T ES 02018744T ES 02018744 T ES02018744 T ES 02018744T ES 2340466 T3 ES2340466 T3 ES 2340466T3
- Authority
- ES
- Spain
- Prior art keywords
- server
- payment
- transaction
- consumer
- merchant
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Lifetime
Links
Classifications
-
- G—PHYSICS
- G06—COMPUTING OR CALCULATING; 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/04—Payment circuits
-
- G—PHYSICS
- G06—COMPUTING OR CALCULATING; COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/38—Payment protocols; Details thereof
- G06Q20/385—Payment protocols; Details thereof using an alias or single-use codes
Landscapes
- Business, Economics & Management (AREA)
- Accounting & Taxation (AREA)
- Strategic Management (AREA)
- Physics & Mathematics (AREA)
- General Business, Economics & Management (AREA)
- General Physics & Mathematics (AREA)
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Finance (AREA)
- Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)
- Management, Administration, Business Operations System, And Electronic Commerce (AREA)
Abstract
Procedimiento para la ejecución de transacciones de pago en una red de datos, con un sistema de administración (10), que presenta al menos un servidor de base de datos con al menos una base de datos con cuentas numéricas anónimas, a las que está asociado en cada caso al menos un código de acceso, y al menos con una base de datos con informaciones de comerciantes, en el que en una transacción de pago: a) a través de un Cliente (aplicación informática) (12) del consumidor se selecciona un producto y/o prestación de servicio en un servidor de comerciantes (14), b) el Cliente (12) del consumidor transmite al sistema de administración (10) un conjunto de datos de la transacción, que presenta un importe de pago, c) el sistema de administración (10) liquida el importe de pago desde una cuenta numérica por medio de un procedimiento de autenticación con el Cliente (12) del consumidor; d) en el que se inicia una transacción de pago desde un Cliente (12, 16) del consumidor a través de una entrada, con lo que se establece una comunicación con un servidor de la aplicación (36, 38) del sistema de administración (10), e) así como el servidor de la aplicación (36, 38) verifica el conjunto de datos de la transacción después de la recepción de la totalidad, determinando sui todos los campos del conjunto de datos de la transacción presentan datos, caracterizado porque f) el conjunto de datos de la transacción presenta un código de identidad del comerciante y el sistema de administración (10) verifica, después de la recepción del conjunto de datos de la transacción, si el código de identidad del comerciante está registrado en la base de datos con informaciones del comerciante, g) el sistema de administración (10) transmite una consulta al servidor de comerciantes (14) para la confirmación de la transacción de pago, en el caso de que el código de identidad del comerciante esté contenido en la base de datos con informaciones del comerciante; h) el sistema de administración (10) liquida el importe de pago desde la cuenta numérica después de la confirmación de la consulta a través del servidor de comerciantes (14) por medio del procedimiento de autenticación con el Cliente (12) del consumidor, i) porque durante la transacción de pago se genera desde el servidor de la aplicación (36, 38) una identificación unívoca para la transacción de pago así como se genera un conjunto de datos de la transacción en el Cliente (12, 16) del consumidor y se transmite codificada al servidor de la aplicación (36, 38), j) en caso de integridad del conjunto de datos de la transacción, se verifica la autenticidad de los datos, estableciendo una comunicación codificada con el servidor de comerciantes (14) e iniciando en el servidor de la aplicación (36, 38) un programa que evalúa un conjunto de datos del resultado de la verificación desde el servidor de comerciantes (14), k) y porque se realiza una ejecución central de transacciones de pago a través del sistema de administración, de tal manera que dentro de un periodo de tiempo predeterminado se registran todas las transacciones de pago desde el sistema de administración y se transmiten a un fichero, de manera que el fichero es transmitido a continuación al menos a un servidor de un sistema de liquidación.
Description
Procedimiento para ejecutar transacciones de
pago en una red de datos.
La invención se refiere a un procedimiento para
ejecutar transacciones de pago en una red de datos del tipo indicado
en la reivindicación 1 así como a un dispositivo para la realización
del procedimiento según la reivindicación 10.
Para la ejecución de transacciones de pago en la
red de datos mundial Internet se emplean siempre todavía de una
manera predominante los procedimientos de pago clásicos sin dinero
como tarjeta de crédito, factura, cargo en cuenta o reembolso. La
tarjeta de crédito ofrece en este caso la ventaja de que un vendedor
de productos o de prestaciones de servicio recibe su dinero de
manera relativamente segura. Si embargo, el comprador corre un
riesgo que no se puede subestimar, puesto que sus datos de la
tarjeta de crédito pueden ser espiados en Internet y pueden ser
utilizados abusivamente por terceros. Aunque los datos de las
tarjetas de crédito son intercambiados, en general, entre el
ordenador del comprador y el ordenador del vendedor o bien del
comerciante a través de una conexión segura, es decir, codificada
según la Norma SSL (Secure Sockets Layer), todavía siempre muchos
usuarios de Internet recelan de seguir esta vía de pago.
Además, con frecuencia no es posible el pago de
importes pequeños por medio de tarjeta de crédito, puesto que no es
atractivo para el comerciante en virtud de sus provisiones para la
empresa de tarjetas de crédito. Por lo tanto, han sido
desarrollados los llamados sistemas de micropago para el pago de
importes pequeños o mínimos.
En los sistemas de micropago se han implantado
entretanto esencialmente tres procedimientos diferentes:
- 1.
- Los sistemas basados en el teléfono utilizan la conexión de la red fija o de teléfono móvil de un consumidor para la identificación y liquidación. Con frecuencia, el pago se realiza también a través de números de teléfono de prima caros como números 0190, a los que el consumidor debe llamar para el pago. Un sistema de este tipo se conoce, por ejemplo, bajo el nombre "Paybox".
- 2.
- Los sistemas basados en crédito se basan, en principio, en cuentas existentes de un comprador, por ejemplo su cuenta corriente. El ejemplo más conocido es probablemente la tarjeta de crédito, que se carga a través de la cuenta corriente de un comprador.
- 3.
- Por último, existen los llamados Sistemas Trusted-Third-Party, en los que un tercero acreditado asume la ejecución del pago. A tal fin, el tercero acumula los importes de pago de un consumidor durante un periodo de tiempo determinado y los liquida o bien desde la tarjeta de crédito o desde la cuenta corriente del consumidor.
\vskip1.000000\baselineskip
En los sistemas conocidos es un inconveniente la
ausencia de anonimato del comprador, es decir, que el comprador se
puede identificar, en principio, en parte incluso debe ser
identificado. De esta manera, se abre, en principio, la posibilidad
de seguir el comportamiento de compra de un comprador, es decir,
conocer detalles privados del consumidor. Este problema es
discutido entretanto en la opinión pública bajo la palabra clave
"consumidor vidrioso".
Por lo tanto, desde el punto de vista del
usuario o bien del consumidor sería deseable, por una parte, un
anonimato, como ofrece el tráfico de pago sin dinero actual y, por
otra parte, una posibilidad de pago sencilla, en particular
técnicamente sencilla, para redes de datos.
Un procedimiento del tipo indicado al principio,
que comprende todas las características del preámbulo de la
reivindicación 1, para la ejecución de transacciones de pago en una
red de datos, que ofrece un anonimato comparable al tráfico sin
dinero, se publica en el documento WO 01 15 045 A1.
La invención tiene el problema de proponer un
procedimiento para la ejecución de transacciones de pago en una red
de datos así como un dispositivo para la realización del
procedimiento, que garantizan el anonimato para un comprador o
consumidor y, sobre todo, se pueden manejar de forma sencilla.
Este problema se soluciona para el procedimiento
a través de las características de la reivindicación 1 y para el
dispositivo a través de la reivindicación 10.
La invención se basa en la idea de instalar
cuentas numéricas anónimas, a las que se puede acceder, en
principio, desde un ordenador discrecional en una red de datos. La
"apertura" de una cuenta numérica de este tipo se realiza de
forma anónima, como se explica todavía a continuación. La ejecución
de transacciones de pago se realiza de forma centralizada desde un
sistema de administración, sin que éste reciba informaciones sobre
el consumidor, como nombre, dirección o datos similares. Los
comerciantes, que ofrecen sus productos y/o prestaciones de
servicio en la red de datos, no tienen que preparar ninguna
tecnología costosa. Además, el procedimiento de acuerdo con la
invención, debe poder integrarse fácilmente en redes de datos
convencionales como con preferencia Internet.
Para posibilitar el anonimato, se utiliza
esencialmente el sistema de Pre-pago conocido a
partir del campo de las telecomunicaciones y muy difundido. Por
ejemplo, se puede adquirir una tarjeta telefónica
pre-pagada sin indicación de datos personales en
puntos de venta y de esta manera se puede consultar por teléfono
desde cualquier teléfono a través de la selección de un número de
teléfono predeterminado y la entrada de un código, que está impreso
en la tarjeta telefónica, el saldo en la tarjeta telefónica.
Para posibilitar ahora un procedimiento basado
en esta idea para el pago en una red de datos son necesarios
esencialmente dos componentes. Por una parte, un sistema de
administración para cuentas numéricas anónimas, a las que está
asociado en cada caso al menos un código de acceso. Estas cuentas
numéricas están llenas con saldos predeterminados. Por otra parte,
un soporte para al menos un código de acceso, por ejemplo una
especie de tarjeta telefónica o un medio comparable. Un consumidor
puede adquirir el soporte en un punto de venta. A tal fin paga el
importe monetario que corresponde al saldo en la cuenta numérica. El
consumidor puede obtener acceso a su cuenta numérica ahora a través
del soporte que contiene al menos un código de acceso.
Los comerciantes pueden posibilitar a sus
consumidores el pago a través del procedimiento de acuerdo con la
invención cerrando un contrato con el operador del procedimiento,
dicho más exactamente, del sistema de administración. De esta
manera, son registrados en una base de datos con comerciantes
autorizados.
Los consumidores solamente necesitan un acceso a
la red de datos y un programa de acceso a la red, como por ejemplo
un navegador en el caso de Internet como red de datos. Para poder
utilizar, por ejemplo, Internet para fines de compra, se presupone
en el consumidor o comprador un navegador de Internet convencional.
No es necesario un fabricante especial, puesto que la comunicación
se basa solamente en el Protocolo Secure Hyper Text Transfer
(https) y las ventanas representadas al comprador utilizan el
lenguaje Hyper Text Markup Language (html).
Para realizar el proceso de pago de forma
sencilla y segura para el comprador y sin administración de sus
ajustes de navegador, debería prescindirse de la utilización de
Cookies en la ejecución de la transacción de pago entre el
comprador y el sistema de administración. No obstante, se pueden
programar algunas facilidades para la entrada, entre otros, con
lenguajes Skript. En la invención tampoco es necesario instalar un
software adicional en el Cliente (aplicación informática) del
consumidor, por ejemplo en el ordenador personal de un consumidor,
para poder utilizar procedimientos de acuerdo con la invención.
A través de la ejecución central de
transacciones de pago, que se realiza esencialmente a través del
sistema de administración, se garantiza una transacción de pago
segura.
En concreto, la invención se refiere a un
procedimiento para la ejecución de transacciones de pago en una red
de datos, con un sistema de administración, que presenta al menos un
servidor de base de datos con al menos una base de datos con
cuentas numéricas anónimas, a las que está asociado en cada caso al
menos un código de acceso, y al menos con una base de datos con
informaciones de comerciantes. Una transacción de pago se realiza de
la siguiente manera:
- a)
- a través de un Cliente (aplicación informática) del consumidor se selecciona un producto y/o prestación de servicio en un servidor de comerciantes;
- b)
- el Cliente del consumidor transmite al sistema de administración un conjunto de datos de la transacción, que presenta un importe de pago y un código de identidad del comerciante;
- c)
- el sistema de administración verifica, después de la recepción del conjunto de datos de la transacción, si el código de identidad del comerciante está registrado en la base de datos con informaciones del comerciante;
- d)
- el sistema de administración transmite una consulta al servidor de comerciantes para la confirmación de la transacción de pago, en el caso de que el código de identidad del comerciante esté contenido en la base de datos con informaciones del comerciante;
- e)
- por ultimo, el sistema de administración liquida el importe de pago desde una cuenta numérica después de la confirmación de la consulta a través del servidor de comerciantes por medio de un procedimiento de autenticación con el Cliente del consumidor.
\vskip1.000000\baselineskip
El procedimiento de autenticación comprende, en
una forma de realización concreta del procedimiento, las etapas
siguientes:
- f)
- transmisión de una consulta para la entrada de un código de acceso a la cuenta numérica en el Cliente del consumidor;
- g)
- transmisión del código de acceso al sistema de administración;
- h)
- representación del estado de la cuenta numérica antes y después de la ejecución de la transacción de pago en el Cliente del consumidor;
- i)
- confirmación o interrupción de las transacciones de pago a través del Cliente del consumidores el sistema de administración.
\vskip1.000000\baselineskip
Con preferencia, dentro de un periodo de tiempo
predeterminado se registran todas las transacciones de pago por el
sistema de administración y se transmiten a un fichero. El fichero
se transmite a continuación al menos a un servidor de un sistema de
liquidación.
El sistema de liquidación puede preparar
entonces las transacciones de pago contenidas en el fichero recibido
y transmitirlas al menos a un servidor de un sistema financiero. El
sistema financiero ocasiona de nuevo pagos a comerciantes de acuerdo
con las transacciones de pago preparadas.
Con preferencia, la consulta del estado de una
cuenta numérica se realiza a través de un Cliente, siendo
transmitida una consulta al sistema de administración para la
representación del estado de la cuenta y siendo representado el
estado de cuenta en el Cliente después de la entrada del código de
acceso a la cuenta numérica.
En una configuración preferida actualmente del
procedimiento, se inicia una transacción de pago desde un Cliente
del consumidor a través de una entrada, especialmente un clic del
ratón, con lo que se establece una comunicación con un servidor de
la aplicación del sistema de administración. El servidor de la
aplicación genera a continuación una identificación unívoca para la
transacción de pago. En el Cliente del consumidor se genera un
conjunto de datos de la transacción y se transmite codificado al
servidor de la aplicación.
En este caso, se puede transmitir el conjunto de
datos de la transacción por medio de un formulario HTML con la
consulta-GET o POST al servidor de la aplicación.
Esto se ofrece sobre todo en Internet como red de datos, el campo
de aplicación preferido del procedimiento de acuerdo con la
invención. Con preferencia, el servidor de la aplicación evalúa la
consulta-GET o POST, verificando si el conjunto de
datos de la transacción transmitido presenta una cabecera y la
cabecera presenta un campo determinado de cabecera.
Además, el servidor de la aplicación puede
verificar la integridad del conjunto de datos de la transacción
después de la recepción, determinando si todos los campos del
conjunto de datos de la transacción presentan datos.
En caso de integridad del conjunto de datos de
la transacción se verifica con preferencia la autenticidad de los
datos, estableciendo una comunicación codificada con el servidor de
comerciantes e iniciando en el servidor de la aplicación un
programa, especialmente un Java-Servlet, que evalúa
un conjunto de datos del resultado de la verificación desde el
servidor de comerciantes.
El programa puede recibir desde el servidor de
comerciantes, como conjunto de datos del resultado de la
verificación, un formulario HTML, que presenta los datos asociados
al conjunto de datos de la transacción y registrados en el servidor
de comerciantes y, además, presenta un valor lógico para la
autenticidad.
Con preferencia, el servidor de la aplicación
emite, en paralelo a la verificación de la autenticidad, una
consulta sobre la entrada del al menos un código de acceso a una
cuenta numérica en el Cliente del consumidor.
Por último, el servidor de la aplicación,
después de la recepción del al menos un código de acceso y del
conjunto de datos del resultado de la verificación, puede comparar
el conjunto de datos de la transacción recibido por el Cliente del
consumidor con el conjunto de datos del resultado de la verificación
y en caso de igualdad de los datos, puede verificar el al menos un
código de acceso con la ayuda de la al menos una base de datos con
cuentas numéricas.
Un dispositivo para la realización del
procedimiento de acuerdo con la invención comprende un sistema de
administración, que presenta al menos un servidor de la base de
datos con al menos una base de datos con cuentas numéricas
anónimas, a las que está asociado en cada caso al menos un código de
acceso, y con al menos una base de datos con informaciones de
comerciantes.
El sistema de administración presenta con
preferencia al menos un servidor de la aplicación para la ejecución
de las transacciones de pago.
Para garantizar una alta seguridad contra fallos
del dispositivo, en una forma de realización preferida, están
previstos exactamente dos servidores de la aplicación, que trabajan
de forma redundante.
El al menos un servidor de la aplicación puede
estar conectado a través de al menos un cortafuegos con la red de
datos, especialmente Internet. De esta manera, se consigue una alta
seguridad, sin la que el dispositivo alcanza, dado el caso,
solamente una aceptación reducida en consumidores preocupados por la
seguridad.
El sistema de administración está conectado con
preferencia con al menos un servidor de un sistema de liquidación
para la preparación de transacciones de pago.
El sistema de liquidación puede estar conectado
de nuevo con al menos un servidor de un sistema financiero para la
provocación de pagos de acuerdo con transacciones de pago
preparadas.
Con preferencia, el sistema de administración
y/o el sistema de liquidación y/o el sistema financiero están
conectados entre sí a través de una Intranet.
En una fase de ampliación imaginaria del
dispositivo, el sistema de administración y/o el sistema de
liquidación y/o el sistema de finanzas están dispuestos adyacentes
entre sí en el espacio, especialmente están alojados en un
edificio.
Por último, el sistema de administración está
conectado con un sistema telefónico para llamadas telefónicas de
pre-pago, con lo que se consigue la doble función
mencionada al principio -pago y teléfono-.
La Tarjeta "MicroMoney" es el soporte del
código de acceso para telecomunicaciones y pago electrónico
(e-Payment) a través de un saldo adquirido
prepagado. El código de acceso es independiente del soporte; también
se pueden concebir otras formas de los soportes, como por ejemplo
un bolígrafo o botellas de bebida.
Con la invención, el consumidor obtiene, por lo
tanto, la posibilidad de utilizar/pagar de forma anónima
prestaciones de telecomunicaciones, función de pago electrónico
(e-Payment) así como todas las prestaciones
posibles en-línea (a través de la conexión a un
puesto de control de números, con un saldo obtenido por medio de
pre-pago.
Las prestaciones de telecomunicaciones se
realizan de manera similar a las tarjetas actuales de llamadas de
pre-pago, por ejemplo la T-Card de
la Telekom AG. La selección se puede realizar, por ejemplo, a
través de un número de llamada gratuito 0800.
En el caso del pago electrónico
(e-Payment), el procedimiento de acuerdo con la
invención se emplea para pagar importes pequeños y mínimos por
productos, prestaciones de servicios y/o contenidos. El código de
acceso sirve para la autenticación en el sistema de administración.
Se necesitan dos tarjetas para no generar importes residuales en
tarjetas y para realizar importes de máximo 200,00 DM con dos
tarjetas individuales de 100,00 DM.
Otras ventajas, características y posibilidades
de aplicación de la presente invención para la ejecución de
transacciones de pago en una red de datos resultan a partir de la
descripción siguiente en combinación con el ejemplo de realización
representado en el dibujo.
A continuación se describe en detalle la
invención con la ayuda del ejemplo de realización representado en
el dibujo. En la descripción, en las reivindicaciones de la patente,
en el resumen y en el dibujo se utilizan los conceptos utilizados
en la lista de los signos de referencia indicada más adelante y los
signos de referencia asociados. En el dibujo:
La figura 1 muestra un diagrama de bloques de un
ejemplo de realización de la arquitectura de un dispositivo para la
realización del procedimiento de acuerdo con la invención; y
La figura 2 muestra el desarrollo de un
establecimiento de la comunicación a través de Internet para la
ejecución de una transacción de pago de acuerdo con el procedimiento
según la invención.
En la figura 1 se representa la arquitectura de
un dispositivo para la realización del procedimiento de acuerdo con
la invención.
Un sistema de administración está conectado a
través de Internet 18 con Clientes 12 y 16 de consumidores así como
con un servidor de comerciantes 14.
El sistema de administración 10 está conectado,
además, a través de una Intranet 24 con una central de servicios de
tarjetas de llamada 26, un sistema de liquidación 28 y un sistema de
finanzas 30 así como un sistema telefónico 40.
El sistema de administración 10 está asegurado
frente a Internet 18 y frente a la Intranet 24 por medio de
cortafuegos 32 y 34, respectivamente. Además, presenta un primero y
un segundo servidor de la aplicación 36 y 38, respectivamente, que
trabajan ambos de forma redundante. De esta manera se consigue una
seguridad contra fallos del sistema de administración y de accesos
electrónicos al sistema de administración. Las comunicaciones entre
Clientes 12 y 16 del consumidor y el servidor de comerciantes 14 con
el sistema de administración 10 se realizan a través del Protocolo
HTTPS, es decir, codificadas.
El sistema de administración 10 se puede
comunicar, además, por medio de Invocación de Método remoto (RMI)
con el sistema telefónico.
El sistema telefónico 40 está conectado a través
de una red de telecomunicaciones 22 con terminales de
telecomunicaciones como el teléfono 20 representado. Sirve para la
liquidación d4e llamadas telefónicas por medio de una tarjeta de
llamada pre-pago, es decir, que ofrece un acceso
pre-pagado a la PSTN (Red Telefónica Pública
Conmutada). A tal fin, presenta un conmutador 42 para la conexión
de comunicaciones en la PSTN y un ordenador de base de datos 44,
que verifica códigos de acceso de la tarjeta de llamada
pre-pago y lleva a cabo la liquidación de tarifas.
El sistema telefónico está conectado, además, con la Central de
Servicio de Tarjetas de Llamada 26 a través de una comunicación
HTTPS.
Las siguientes explicaciones/consideraciones se
refieren solamente a la función de pago para Internet; aquí no se
describe la posibilidad de utilización para telefonía. A
continuación se describe la ejecución de una transacción de pago de
acuerdo con la invención a través de Internet 18 como red de datos.
Cuando a continuación de habla de comprador o cliente, se entiende
por ello un Cliente 12, 16 del consumidor, es decir, un ordenador,
que actúa como Cliente en la red de datos. En el Cliente 12, 16 del
consumidor se ejecuta un programa, que posibilita a un consumidor
comprar productos y/o prestaciones de servicios a través de Internet
18 desde un servidor de comerciantes 14.
El comprador llena a tal fin una cesta de
productos en un comerciante, que pone a disposición, para el pago,
un enlace con el sistema de administración 10, Dicho más
exactamente, el comprador se encuentra en el lado de Internet del
comerciante y selecciona productos y/o prestaciones de servicio para
la compra, con lo que éstos son colocados en la cesta
"virtual" de productos. El comprador llama, después de
seleccionar los productos y/o prestaciones de servicio, el enlace
para pagar, por ejemplo a través de un clic en un icono
correspondiente. Para el seguimiento de las señalizaciones que se
ejecutan en este caso a través de Internet se remite al diagrama de
secuencias de la figura 2.
Internet 18 está conectada través de una zona
"desmilitarizada", el sistema de administración 10, con la red
interna de la Firma, la Intranet 24. Por zona "desmilitarizada"
se entiende especialmente una zona especialmente asegurada, por
ejemplo a través de cortafuegos 32, 34.
En el sistema de administración 10 se realiza
una verificación de si el comerciante puede utilizar, en general,
el sistema de administración 10 para la ejecución. Si existe una
regulación contractual entre comerciantes y el operador del sistema
de administración 10, entonces se ofrece al comprador la posibilidad
de realizar el proceso de pago.
Este proceso de pago conduce a una reducción de
la cuenta numérica del comprador. La cuenta numérica es administrada
por el sistema de administración 10. La cuenta numérica se puede
identificar unívocamente con la ayuda del código de acceso, que
tiene por ejemplo 15 posiciones, es numérico y está aplicado en la
tarjeta, el PAN de Internet (Primery Account Number, 16 posiciones,
alfanumérico) y el PAN telefónico (12 posiciones, numérico).
Por razones de redundancia, en la zona
"desmilitarizada" están constituidos dos servidores de la
aplicación 36, 38, que ejecutan las secuencias de pago conectadas
con las transacciones de pago entre las partes (comprador,
comerciante, operador del sistema de administración). En este
hardware está instalado como software, respectivamente, un servidor
de la Web. Éste servidor sirve para la comunicación con el comprador
y los comerciantes. Adicionalmente, en el servidor de la aplicación
36, 38 está localizado un software de la aplicación, especialmente
una aplicación de base de datos.
Los datos individuales de la transacción de los
procesos de pago son acumulados diariamente por el sistema de
administración 10 y son transmitidos a un fichero. Este fichero es
transmitido, en el marco de una transferencia, a otro sistema de
ordenador 28, dicho más exactamente, a un servidor. Las
informaciones son preparadas allí según los contratos respectivos
de los comerciantes y son transmitidas una vez al mes al sistema
financiero 30, que organiza la transferencia de dinero necesaria al
comerciante.
Los siguientes conjuntos de datos contienen las
informaciones decisivas del proceso de pago:
- Identificación del comerciante
- Información sobre la transacción
- Información sobre el producto y/o prestación de servicio
- Identificación de la moneda
- Importe
- Sello de tiempo
\vskip1.000000\baselineskip
El comerciante recibe desde el operador del
sistema de administración 10 un identificador unívoco -la
identificación del comerciante (designada a continuación también de
forma abreviada como ID del comerciante). Sin esta información, que
se da al comerciante en la firma del contrato, el comerciante no
tiene ninguna posibilidad de utilizar el procedimiento de acuerdo
con la invención.
A través del sitio Web del sistema de
administración 10 se ofrece al comprador la posibilidad de
supervisar transacciones de pago y telefónicas iniciadas por él
mismo. Aquí se realiza la representación de las transacciones en
forma de una visión de conjunto de la comunicación individual,
ordenada por fechas. Para garantizar que también sólo el titular de
la cuenta puede acceder a estas informaciones, el titular de la
cuenta debe introducir el PAN de Internet así como las últimas 5
cifras del código de acceso de su cuenta numérica con el fin de la
identificación en el sistema de administración 10.
En el marco de la representación del estado de
la cuenta numérica, el comprador dispone de la posibilidad de
visualizar en cualquier momento las transacciones realizadas por él.
Se representan tanto procesos de pago como también las actividades
telefónicas cumpliendo las disposiciones de protección de datos.
Esta función ofrece al comprador la posibilidad de documentar las
acciones realizadas por él.
Al final de paseo de compra virtual existe una
cesta de compra más o menos llena, que se representa al comprador o
bien al consumidor en el navegador de la Web (Punto 1 en la Figura
2).
El proceso de pago se puede activar a través de
botones, iconos, imágenes o enlaces. Si se hace un clic con el ratón
sobre el botón de pago, se establece una comunicación con el sistema
de administración 10, dicho más exactamente con el servidor de la
aplicación 36, 38 (Punto 2 en la Figura 2).
Detrás del botón de pago se esconde el siguiente
formulario HTML:
Aquí se transmiten los parámetros "ocultos"
al servidor de la Web o bien de la aplicación 36, 37 en el sistema
de administración 10 a través de una sesión SSL.
- 1.
- mlD = ID del comerciante
- 2.
- tlD = ID de la transacción, es decir, el número de factura del proceso
- 3.
- clD = tipo de producto
- 4.
- importe = precio total
- 5.
- moneda = identificación de la moneda
\vskip1.000000\baselineskip
El sistema de administración 10 soporta tanto
peticiones-GET como también POST. El origen de la
consulta debe venir de un servidor de la Web 14. Para determinarlo,
se evalúa en primer lugar la cabecera y se busca el campo de la
cabecera "Referente".
En el caso de una consulta simulada, que se
activa, por ejemplo, a través de la línea de la dirección de un
navegador, la cabecera no existe. El sistema de administración 10
reacciona a ello con un mensaje de interrupción.
Si se abandona el proceso, se termina la sesión
y se transfiere al consumidor a la página de inicio (Homepage) del
operador del sistema de administración 10.
Para cada inicio de una transacción de
liquidación se genera desde el servidor de la aplicación una
identificación de la sesión (sessionID) unívoca interna (sID). Esta
sID sirve para la identificación de cada transacción de pago
individual. Puesto que no se puede excluir que el navegador del
consumidor no acepte Cookies, se asegura la identificación de cada
transacción de pago a través de una Reescritura URL.
A continuación se verifica si los datos
relevantes de la liquidación han sido transmitidos completos. Es
decir, ¿se han transmitido para las variables mID, tID, cID,
importe, moneda también datos realmente correspondientes?.La Tabla
siguiente muestra el contendí de la consulta de la identificación
del comerciante (merchantID-Request) (Punto 2 en la
Figura 2):
La Tabla siguiente muestra el contenido de la
respuesta de la ID del comerciante
(marchantID-Response) (Punto 3 en la Figura 2):
\vskip1.000000\baselineskip
En caso afirmativo, se verifica con la ayuda de
una base de datos lo siguiente: ¿Existe realmente el comerciante
con la identidad del comerciante (merchantID) transmitida?. La mID
se considera válida cuando el sistema de administración 10
suministra el código de error = 0. Es decir, que si el código de
error es distinto a 0, se trata de un comerciante no válido o bien
"falso". De acuerdo con el código de error aparecido se emiten
mensajes de error correspondientes, por ejemplo:
- El conjunto de datos de la transacción está incompleto.
- ¡Por favor, actualice su cesta de productos!
- Cierre para ello el diálogo y haga clic de nuevo en el botón de pago.
\vskip1.000000\baselineskip
Después de que se han transmitido los datos
relevantes, debe verificarse la autenticidad. En este caso, se
establece una comunicación SSL fuerte de 128 bits con el servidor
del comerciante 14. Éstas, como posteriormente todas las otras
consultas todavía siguientes al (en la comunicación con el) servidor
de comerciantes 14, utilizan igualmente la codificación fuerte
SSL.
Se transmite la siguiente consulta al servidor
de comerciantes 14: ¿Existe en el comerciante con mID actual un
proceso con esta tID? Con respecto al servidor de comerciantes 14,
se verifica por medio de la marchantURL determinada con
anterioridad.
La consulta al servidor de comerciantes 14 es
iniciada por el sistema de administración 10 a través de un
Java-Servlet. No se espera la respuesta del servidor
de comerciantes 14. El contenido se obtiene a través de la sID. El
Jave-Servlet recibe del servidor de comerciantes 14
como respuesta un formulario HTML. Además de los datos sobre la
cesta de productos, se transmite también un indicador del tipo
booleano. El valor verdadero o falso representa una tID válida o no
válida, respectivamente.
El resultado de la verificación se escribe por
la aplicación en una Tabla. Esta tabla es parte de la base de datos
de comerciantes. Los datos no se mantienen, por lo tanto, en el
servidor de la Web en el sistema de administración 10. La clave
principal para el acceso de lectura es la sID.
\newpage
La Tabla siguiente muestra el contenido de la
repuesta transactionID-Response (Punto 3 en la
figura 2):
En paralelo con la consulta anterior se emite un
diálogo de entrada al navegador de la Web del consumidor. El tiempo,
que el consumidor necesita para introducir el PAN alfanumérico de 16
posiciones y para activar su entrada con el botón OK, está a la
disposición del servidor de comerciantes 14, para responder a la
consulta del sistema de administración. Para el caso de que el
consumidor haya terminado con la entrada del PAN antes de que el
sistema de administración 10 reciba la respuesta desde el servidor
de comerciantes 14, se representa al consumidor la siguiente
indicación:
- Sus datos de la transacción son verificados en este momento. Por favor, tenga paciencia.
\vskip1.000000\baselineskip
Si el servidor de comerciantes 14 no está
accesible, o bien el Jave-Servlet no recibe ninguna
respuesta (expiración del tiempo), esto es señalizado por medio de
un código de error o texto de error correspondiente. También aquí se
transmite el mensaje correspondiente al consumidor, es decir, se
representa en el Cliente del consumidor. En este caso de error, se
emite el siguiente mensaje de error:
- El comerciante no es accesible en este momento. Por favor, inténtelo de nuevo más tarde. Para ello, cierre el diálogo y haga clic de nuevo en el botón de pago.
\vskip1.000000\baselineskip
Después de la activación del botón OK después de
la entrada del PAN, se sincroniza el proceso. A tal fin, se verifica
en primer lugar la igualdad de la cesta de productos, que ha sido
transmitida a través del navegador del cliente al sistema de
administración 10, con la respuesta del servidor de comerciantes 14
(conjunto de datos de la Tabla).
En el caso de cestas de productos diferentes, se
emite el siguiente mensaje de error:
- La cesta de productos no es válida.
- ¡Por favor, actualice su cesta de productos!
- Para ello, cierre el diálogo y haga clic de nuevo en el botón de pago.
\vskip1.000000\baselineskip
Si se abandona la sesión a través del botón de
Terminar, la sesión obtiene el estado de no válido. A continuación,
se remite al consumidor a la página de llamada del servidor del
comerciante 14.
En caso de coincidencia de las cestas de
productos, se puede comenzar ahora con la verificación del PAN. En
este caso, se verifica la longitud correcta de la entrada del
consumidor -ya en el servidor de la aplicación. En caso de error, se
emite el mismo mensaje, que se suministra también durante la
verificación contra la base de datos de la cuenta numérica:
- Solamente cuando el PAN tiene 16 posiciones de longitud, se verifica contra la base de datos de la cuenta numérica.
\vskip1.000000\baselineskip
Si no existe el PAN, se emite el siguiente
mensaje de error (PAN indicado a modo de ejemplo):
- ¡No se ha encontrado el PAN!
- Ud. ha introducido el siguiente PAN no válido: 1234 5678 90ab CdeF
\vskip1.000000\baselineskip
Si el PAN es válido, pero la ID de la
transacción es no válida, se emite el siguiente mensaje de error de
la ID de la transacción:
- La cesta de productos no es válida.
- ¡Por favor, actualice su cesta de productos!
- Para ello, cierre el diálogo y haga clic en el botón de pago.
\vskip1.000000\baselineskip
Si el PAN y la ID de la transacción no son
válidos, se emite el siguiente mensaje de error de la ID de la
transacción:
- La cesta de productos no es válida.
- ¡Por favor, actualice su cesta de productos!
- Para ello, cierre el diálogo y haga clic en el botón de pago.
\vskip1.000000\baselineskip
Ambos eventos -la consulta al servidor de
comerciantes 14 y la entrada del PAN del consumidor- deben
proporcionar resultados positivos. Solamente entonces se verifica el
PAN frente al sistema de administración.
La Tabla siguiente muestra el contenido de la
consulta del PAN (PAN-Request) (Punto 4 en la Figura
2).
\vskip1.000000\baselineskip
La Tabla siguiente muestra el contenido de la
respuesta del PAN (PAN-Res) (Punto 4 en la Figura
2)
\newpage
La verificación positiva del PAN suministra
datos, a partir de los cuales se genera una máscara de diálogo con
todos los datos asegurados hasta ahora. En la máscara de diálogo, el
cliente puede hacer clic sobre el botón "otros PAN" - para el
caso de que el saldo de la cuenta numérica, que está enlazada con el
primer PAN, sea insuficiente para el proceso de pago. De esta
manera, llega a la máscara de entrada del PAN. En cambio, si
selecciona el botón "Sí", el consumidor inicia sólo
indirectamente el proceso de pago. En primer lugar, el sistema de
administración 10 informa al servidor de comerciantes 14 que el
consumidor tiene liquidez. Ya en este instante, el comerciante
podría atender al consumidor.
El sistema de administración 10 recibe como
respuesta la petición de transacción representada en la Tabla
siguiente:
\vskip1.000000\baselineskip
El sistema de administración 10 activa a
continuación el adeudo. Después de la transacción con éxito, el
servidor de comerciantes 14 así como el consumidor reciben una
confirmación del adeudo, que está codificado en la Tabla
siguiente:
\vskip1.000000\baselineskip
Por último, el servidor de comerciantes 14
confirma el reconocimiento, el consumidor termina el proceso a
través del cierre de la ventana del navegador (Punto 10 en la Figura
29.
La invención se caracteriza porque posibilita un
pago sencillo y anónimo a través de redes de datos como Internet,
con un gasto técnico reducido para un usuario.
\vskip1.000000\baselineskip
- 10
- Sistema de administración
- 12
- Cliente del comprador
- 14
- Servidor de comerciantes
- 16
- Cliente del comprador
- 18
- Internet
- 20
- Teléfono
- 22
- Red de telecomunicaciones
- 24
- Intranet
- 26
- Central de servicio de tarjetas de llamadas
- 28
- Sistema de liquidación
- 30
- Sistema financiero
- 32
- Cortafuegos
- 34
- Cortafuegos
- 36
- Primer servidor de la aplicación
- 38
- Segundo servidor de la aplicación
- 40
- Sistema telefónico
- 42
- Conmutador
- 44
- Ordenador de la base de datos
Claims (19)
1. Procedimiento para la ejecución de
transacciones de pago en una red de datos, con un sistema de
administración (10), que presenta al menos un servidor de base de
datos con al menos una base de datos con cuentas numéricas anónimas,
a las que está asociado en cada caso al menos un código de acceso, y
al menos con una base de datos con informaciones de comerciantes, en
el que en una transacción de pago:
- a)
- a través de un Cliente (aplicación informática) (12) del consumidor se selecciona un producto y/o prestación de servicio en un servidor de comerciantes (14),
- b)
- el Cliente (12) del consumidor transmite al sistema de administración (10) un conjunto de datos de la transacción, que presenta un importe de pago,
- c)
- el sistema de administración (10) liquida el importe de pago desde una cuenta numérica por medio de un procedimiento de autenticación con el Cliente (12) del consumidor;
- d)
- en el que se inicia una transacción de pago desde un Cliente (12, 16) del consumidor a través de una entrada, con lo que se establece una comunicación con un servidor de la aplicación (36, 38) del sistema de administración (10),
- e)
- así como el servidor de la aplicación (36, 38) verifica el conjunto de datos de la transacción después de la recepción de la totalidad, determinando sui todos los campos del conjunto de datos de la transacción presentan datos,
caracterizado porque
- f)
- el conjunto de datos de la transacción presenta un código de identidad del comerciante y el sistema de administración (10) verifica, después de la recepción del conjunto de datos de la transacción, si el código de identidad del comerciante está registrado en la base de datos con informaciones del comerciante,
- g)
- el sistema de administración (10) transmite una consulta al servidor de comerciantes (14) para la confirmación de la transacción de pago, en el caso de que el código de identidad del comerciante esté contenido en la base de datos con informaciones del comerciante;
- h)
- el sistema de administración (10) liquida el importe de pago desde la cuenta numérica después de la confirmación de la consulta a través del servidor de comerciantes (14) por medio del procedimiento de autenticación con el Cliente (12) del consumidor,
- i)
- porque durante la transacción de pago se genera desde el servidor de la aplicación (36, 38) una identificación unívoca para la transacción de pago así como se genera un conjunto de datos de la transacción en el Cliente (12, 16) del consumidor y se transmite codificada al servidor de la aplicación (36, 38),
- j)
- en caso de integridad del conjunto de datos de la transacción, se verifica la autenticidad de los datos, estableciendo una comunicación codificada con el servidor de comerciantes (14) e iniciando en el servidor de la aplicación (36, 38) un programa que evalúa un conjunto de datos del resultado de la verificación desde el servidor de comerciantes (14),
- k)
- y porque se realiza una ejecución central de transacciones de pago a través del sistema de administración, de tal manera que dentro de un periodo de tiempo predeterminado se registran todas las transacciones de pago desde el sistema de administración y se transmiten a un fichero, de manera que el fichero es transmitido a continuación al menos a un servidor de un sistema de liquidación.
\vskip1.000000\baselineskip
2. Procedimiento de acuerdo con la
reivindicación 1, caracterizado porque el procedimiento de
autenticación a partir de la etapa d) comprende las siguientes
etapas:
- 1.
- en el Cliente (12) del consumidor, transmisión de una consulta sobre la entrada de un código de acceso a la cuenta numérica en el Cliente (12) del consumidor,
- 2.
- transmisión del código de acceso al sistema de administración (10),
- 3.
- representación del estado de la cuenta numérica antes y después de la ejecución de la transacción de pago,
- 4.
- confirmación o interrupción de las transacciones de pago a través del Cliente (12) del consumidor en el sistema de administración (10).
\vskip1.000000\baselineskip
3. Procedimiento de acuerdo con las
reivindicaciones 1 y 2, caracterizado porque se transmite el
conjunto de datos de la transacción por medio de un formulario HTML
con la consulta-GET o POST al servidor de la
aplicación (36, 38).
4. Procedimiento de acuerdo con la
reivindicación 3, caracterizado porque el servidor de la
aplicación (36, 38) evalúa la consulta-GET o POST,
verificando si el conjunto de datos de la transacción transmitido
presenta una cabecera y la cabecera presenta un campo determinado de
cabecera.
5. Procedimiento de acuerdo con la
reivindicación 1, caracterizado porque el programa recibe
desde el servidor de comerciantes (14), como conjunto de datos del
resultado de la verificación, un formulario HTML, que presenta los
datos asociados al conjunto de datos de la transacción y registrados
en el servidor de comerciantes (14) y, además, un valor lógico para
la autenticidad.
6. Procedimiento de acuerdo con la
reivindicación 5, caracterizado porque el servidor de la
aplicación (36, 38) emite, paralelamente a la verificación de la
autenticidad, una consulta sobre la entrada del al menos un código
de acceso a una cuenta numérica en el Cliente (12, 16) del
consumidor.
7. Procedimiento de acuerdo con la
reivindicación 6, caracterizado porque el servidor de la
aplicación (36, 38), después de la recepción del al menos un código
de acceso y del conjunto de datos del resultado de la verificación,
compara el conjunto de datos de la transacción recibido desde el
Cliente (12, 16) del consumidor con el conjunto de datos del
resultado de la verificación y, en caso de igualdad de los datos,
verifica el al menos un código de acceso con la ayuda de la al menos
una base de datos con cuentas numéricas.
8. Procedimiento de acuerdo con una de las
reivindicaciones anteriores, caracterizado porque el sistema
de liquidación (28) prepara las transacciones de pago contenidas en
el fichero recibido y las transmite al menos a un servidor de un
sistema financiero (30) y el sistema financiero (30) ocasiona pagos
a cuentas de comerciantes de acuerdo con las transacciones de pago
preparadas.
9. Procedimiento de acuerdo con una de las
reivindicaciones anteriores, caracterizado porque la consulta
del estado de una cuenta numérica se realiza a través de un Cliente
(12, 16), siendo transmitida la consulta al sistema de
administración (10) para la representación del estado de la cuenta y
el sistema de administración (10) representa el estado de la cuenta
en el Cliente (12, 16) después de la entrada del código de acceso a
la cuenta numérica.
10. Dispositivo con una arquitectura adaptada
para la realización de un procedimiento de acuerdo con una de las
reivindicaciones anteriores, con un sistema de administración (10)
para la ejecución central de las transacciones de pago, que presenta
al menos un servidor de bases de datos con al menos una base de
datos con las cuentas numéricas anónimas, a las que está asociado en
cada caso al menos un código de acceso, con al menos una base de
datos con las informaciones de comerciantes y con al menos un
servidor de la aplicación (36, 38) adaptada para la ejecución de las
transacciones de pago de acuerdo con el procedimiento según una de
las reivindicaciones anteriores, en el que la arquitectura presenta
un sistema de liquidación para la recepción del fichero del sistema
de administración (10).
11. Dispositivo de acuerdo con la reivindicación
10, caracterizado porque están previstos exactamente dos
servidores de la aplicación (36, 38), que trabajan de forma
redundante.
12. Dispositivo de acuerdo con la reivindicación
10 u 11, caracterizado porque el al menos un servidor de la
aplicación (36, 38) está conectado a través de al menos una
cortafuegos (32, 34) con la red de datos, especialmente Internet
(18).
13. Dispositivo de acuerdo con una de las
reivindicaciones anteriores, caracterizado porque el sistema
de liquidación (28) está conectado con al menos un servidor de un
sistema financiero (30) para la provocación de pagos de acuerdo con
las transacciones de pago preparadas.
14. Dispositivo de acuerdo con la reivindicación
12 ó 13, caracterizado porque el sistema de administración
(10) y/o el sistema de liquidación (28) y/o el sistema de finanzas
(30) están conectados entre sí a través de una Intranet (24).
15. Dispositivo de acuerdo con una de las
reivindicaciones 12 a 14, caracterizado porque el sistema de
administración (10) y/o el sistema de finanzas (30) están dispuestos
adyacentes entre sí en el espacio, especialmente están alojados en
un edificio.
16. Dispositivo de acuerdo con una de las
reivindicaciones 10 a 15, caracterizado porque el sistema de
administración (10) está conectado con un sistema telefónico (40)
para llamadas telefónicas de pre-pago.
Applications Claiming Priority (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| DE10147651A DE10147651C1 (de) | 2001-09-27 | 2001-09-27 | Verfahren zum Abwickeln von Zahlungstransaktionen in einem Datennetz |
| DE10147651 | 2001-09-27 |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| ES2340466T3 true ES2340466T3 (es) | 2010-06-04 |
Family
ID=7700481
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| ES02018744T Expired - Lifetime ES2340466T3 (es) | 2001-09-27 | 2002-08-22 | Procedimiento para ejecutar transacciones de pago en una red de datos. |
Country Status (4)
| Country | Link |
|---|---|
| EP (1) | EP1298613B1 (es) |
| AT (1) | ATE459060T1 (es) |
| DE (1) | DE10147651C1 (es) |
| ES (1) | ES2340466T3 (es) |
Families Citing this family (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| EP1497763A2 (en) * | 2002-03-28 | 2005-01-19 | Burrows, Colin Cyril | Administration of transactions with pre-payment debit and credit cards |
Family Cites Families (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| DE19723479A1 (de) * | 1997-06-04 | 1998-12-10 | Dci Datenbank Fuer Wirtschafts | Verfahren zum Datenaustausch in einem Netzwerk |
| DE19716068A1 (de) * | 1997-04-17 | 1998-10-22 | Giesecke & Devrient Gmbh | Verfahren zur Erzeugung eines Guthabens mittels eines vorausbezahlten Wertgutscheins |
| DE10022973A1 (de) * | 1999-06-15 | 2001-02-08 | Pan Amp Gmbh | Verfahren zur Abwicklung von Geldgeschäften über elektronische Übertragungsmedien |
| WO2001015045A1 (en) * | 1999-08-20 | 2001-03-01 | Ecatalystone.Com, Inc. | Methods and apparatus for managing prepaid transactions over a network |
| DE10023251A1 (de) * | 2000-05-12 | 2001-12-20 | Logo Hardware & Internet Servi | Zahlungskarte und Verfahren zum Bezahlen unter Verwendung einer Zahlungskarte |
-
2001
- 2001-09-27 DE DE10147651A patent/DE10147651C1/de not_active Expired - Lifetime
-
2002
- 2002-08-22 AT AT02018744T patent/ATE459060T1/de active
- 2002-08-22 EP EP02018744A patent/EP1298613B1/de not_active Expired - Lifetime
- 2002-08-22 ES ES02018744T patent/ES2340466T3/es not_active Expired - Lifetime
Also Published As
| Publication number | Publication date |
|---|---|
| ATE459060T1 (de) | 2010-03-15 |
| DE10147651C1 (de) | 2002-11-21 |
| EP1298613B1 (de) | 2010-02-24 |
| EP1298613A3 (de) | 2006-01-11 |
| EP1298613A2 (de) | 2003-04-02 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| AU2006100814C4 (en) | Transaction System | |
| US6805289B2 (en) | Prepaid card payment system and method for electronic commerce | |
| US10275760B2 (en) | Method and apparatus for authorizing a payment via a remote device | |
| AU2009201395B2 (en) | Mobile account authentication service | |
| USRE43440E1 (en) | Method for performing a transaction over a network | |
| US20020120587A1 (en) | System and method for performing secure user account purchases | |
| US20020069158A1 (en) | Method and system for providing a secured multi-purpose electronic account | |
| RU2449481C2 (ru) | Способы и системы усовершенствованного осуществления платежа покупателями | |
| CZ20004781A3 (cs) | Ověřený platební systém | |
| MX2010010810A (es) | Servidor de transaccion configurado para autorizar transacciones de pago usando dispositivos de telefonos celulares. | |
| US7593870B2 (en) | Method for telephone-based authenticated authorization of transactions | |
| WO2000075843A1 (en) | Internet payment system | |
| EP1234223A2 (en) | System and method for secure electronic transactions | |
| US20040068465A1 (en) | Electric commerce credit processing method and electric commerce system | |
| KR20030082090A (ko) | 전자 지불 결제 방법 및 시스템 | |
| KR20030068603A (ko) | 휴대폰을 이용한 대금 결재 시스템 및 그 방법 | |
| WO2000075749A2 (en) | Internet payment system | |
| US8521643B2 (en) | System and method for on-line payment transactions | |
| TW200805186A (en) | Method and apparatus for payment without payment card infrastructure | |
| ES2340466T3 (es) | Procedimiento para ejecutar transacciones de pago en una red de datos. | |
| KR20020000911A (ko) | 이동통신망을 이용한 직불 거래 서비스 시스템과 그서비스 방법 | |
| KR100394041B1 (ko) | 소액 전자상거래 방법 | |
| KR20170102848A (ko) | 계좌 브릿지를 이용한 거래 운영 방법 | |
| ES2293908T3 (es) | Procedimiento para realizar transacciones de compra en linea. | |
| KR20010091827A (ko) | 통신 단말 번호를 이용한 송금 시스템 및 송금 방법 |