ES2955077T3 - Transacciones financieras electrónicas - Google Patents

Transacciones financieras electrónicas Download PDF

Info

Publication number
ES2955077T3
ES2955077T3 ES05769671T ES05769671T ES2955077T3 ES 2955077 T3 ES2955077 T3 ES 2955077T3 ES 05769671 T ES05769671 T ES 05769671T ES 05769671 T ES05769671 T ES 05769671T ES 2955077 T3 ES2955077 T3 ES 2955077T3
Authority
ES
Spain
Prior art keywords
terminal
http
host
tml
gateway
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.)
Active
Application number
ES05769671T
Other languages
English (en)
Inventor
Dmitry Barsukov
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Ingenico UK Ltd
Original Assignee
Ingenico UK Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Ingenico UK Ltd filed Critical Ingenico UK Ltd
Application granted granted Critical
Publication of ES2955077T3 publication Critical patent/ES2955077T3/es
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/08—Payment architectures
    • G06Q20/10—Payment architectures specially adapted for electronic funds transfer [EFT] systems; specially adapted for home banking 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/08—Payment architectures
    • G06Q20/20—Point-of-sale [POS] network 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/08—Payment architectures
    • G06Q20/20—Point-of-sale [POS] network systems
    • G06Q20/204—Point-of-sale [POS] network systems comprising interface for record bearing medium or carrier for electronic funds transfer or payment credit
    • 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
    • G06Q20/401—Transaction verification

Landscapes

  • Business, Economics & Management (AREA)
  • Accounting & Taxation (AREA)
  • Finance (AREA)
  • Engineering & Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • Strategic Management (AREA)
  • General Business, Economics & Management (AREA)
  • General Physics & Mathematics (AREA)
  • Theoretical Computer Science (AREA)
  • Economics (AREA)
  • Development Economics (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer And Data Communications (AREA)
  • Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)

Abstract

Se propone un nuevo sistema de transacciones financieras electrónicas (EFT), en el que la lógica empresarial de una transacción se define en una ubicación remota de un terminal de punto de venta seguro, teniendo así un marco en el que la lógica empresarial se puede personalizar o actualizar fácilmente. (Traducción automática con Google Translate, sin valor legal)

Description

DESCRIPCIÓN
Transacciones financieras electrónicas
La presente invención se refiere a transacciones financieras electrónicas, en particular a sistemas de transacciones financieras electrónicas y a métodos y componentes de tales sistemas.
Es bien conocido el uso de sistemas de transacciones financieras electrónicas (EFT) para permitir a los clientes efectuar el pago de bienes y servicios utilizando una variedad de tarjetas de débito y crédito, en lo sucesivo denominadas "tarjetas de transacción" o simplemente "tarjetas", términos en los que se entenderá que incluyen tipos equivalentes de soportes de datos o similares empleados en transacciones EFT, que pueden incluir, por ejemplo, un vale electrónico para transacciones móviles prepago. En tales sistemas, un terminal de punto de venta EFT (POS) (terminal EFTPOS) se comunica con un sistema "adquiriente" remoto, operado generalmente por o en nombre de una institución financiera como un banco, para autorizar y procesar las transacciones.
Generalmente, el terminal EFTPOS obtiene los datos de la tarjeta del cliente (habitualmente mediante lectura de una banda magnética o consulta de un chip de la tarjeta) y otra información, incluyendo al menos el importe de la transacción (habitualmente mediante introducción en el teclado o directamente desde un sistema de caja registradora asociado o similar) y seguidamente se conecta en línea a través de un enlace de telecomunicaciones con el sistema adquiriente para autorizar y/o procesar la transacción. Existen muchas variaciones en la forma en la que se pueden autorizar y procesar las transacciones EFT, incluyendo el uso de "límites mínimos" para determinar si se requiere autorización en línea, procesamiento de transacciones en tiempo real frente a procesamiento por lotes, procesamiento de transacciones por goteo, etc. La presente invención es aplicable a todos estos modos de procesamiento EFT.
Los sistemas y métodos EFT convencionales no se describirán en detalle en el presente documento, ya que tales detalles son bien conocidos por los expertos, pero se debe señalar lo siguiente.
Los sistemas EFT se ajustan generalmente a protocolos estándar para autorizar y procesar transacciones. En el Reino Unido, estos protocolos incluyen APACS 30/50 y APACS 40. En otros lugares se aplican protocolos similares o equivalentes. La presente invención se describirá con especial referencia a protocolos APACS, pero se entenderá que la invención no se limita a los mismos y está concebida para ser utilizable o adaptable para su uso con todos los protocolos EFT.
Los terminales EFTPOS incluyen generalmente uno o más dispositivos lectores de tarjetas o equivalentes, una pantalla, un teclado y/o un teclado numérico y una impresora, y pueden comprender dispositivos autónomos, sistemas POS con múltiples terminales inalámbricos y dispositivos asociados o integrados con cajas registradoras y otros dispositivos y sistemas "locales", etc., como es bien conocido en la técnica, y pueden comunicarse con sistemas adquirientes directamente a través de uno o más sistemas intermediarios, como también es bien conocido. Se entenderá que la presente invención es aplicable a todos estos tipos de terminales EFTPOS y a sistemas asociados. En particular, cuando los sistemas anfitriones remotos o los componentes de tales sistemas, como se describe en el presente documento como parte de los sistemas de la presente invención, se describan en comunicación con sistemas adquirientes, se entenderá que tales comunicaciones pueden implicar sistemas intermediarios adicionales.
También se pretende que la presente invención pueda utilizarse con todos los tipos conocidos y propuestos de verificación de la identidad del cliente, incluyendo verificación de firmas y PIN, tecnologías de verificación biométrica, como reconocimiento de huellas dactilares, reconocimiento de voz y de escaneo de retina.
Está implícito que un terminal EFTPOS es un "terminal seguro", es decir, un terminal que dispone de uno o varios mecanismos de seguridad para impedir la intercepción o la interpretación de comunicaciones, para prevenir el uso de un terminal falso o un host adquiriente falso, o para impedir la manipulación física del terminal. Los mecanismos de seguridad implementados tienen que ser suficientemente rigurosos para proporcionar un nivel de seguridad adecuado dada la naturaleza y el volumen de transacciones realizadas. También está implícito que todos los sistemas de comunicación empleados en los sistemas EFT deben ser seguros. Los sistemas de procesamiento de datos que forman parte de los sistemas EFT diferentes de los terminales de usuario final y de los sistemas locales asociados estarán generalmente localizados en un entorno controlado y seguro y se puede suponer que son "seguros".
En todos los tipos de terminales EFTPOS convencionales descritos anteriormente, la programación del terminal a través de la cual este proporciona su interfaz de usuario lee las tarjetas de transacción, imprime los comprobantes de transacción y se comunica con los adquirientes u otros sistemas locales remotos (alguna o todas estas funciones pueden denominarse "lógica empresarial" del terminal) se escribe en un lenguaje de bajo nivel, como C o C++ y "se codifica de forma fija" en el terminal. Es decir, la programación reside "permanentemente" en el terminal en forma de hardware o firmware; es decir, no cambia durante los ciclos normales de alimentación del terminal o en el uso normal.
Un problema principal de los terminales convencionales codificados consiste en que las modificaciones, actualizaciones, etc. de la programación del terminal requieren (a) habilidades de programación especializadas y (b) reconfiguración in situ de la base de usuario del terminal instalado. Esto significa que la introducción de una lógica empresarial nueva o mejorada o de otras funciones del terminal es compleja, costosa y requiere mucho tiempo. Adicionalmente, estas modificaciones y mejoras deben ser desarrolladas e instaladas, en general, por los fabricantes de equipos originales u otros proveedores altamente especializados y no por los usuarios (en el sentido de organizaciones de usuarios tales como cadenas de tiendas, no usuarios finales individuales), los proveedores de servicios o los adquirientes. Una consecuencia de esto, además de los elevados gastos generales que conllevan el desarrollo y el mantenimiento del sistema, es que la infraestructura de los sistemas EFT es muy inflexible.
Un objeto de la presente invención es proporcionar sistemas EFT mejorados, componentes del sistema (incluyendo terminales) y métodos que faciliten el mantenimiento y el desarrollo de la infraestructura del sistema, incluyendo el desarrollo y la implementación de lógica empresarial nueva y mejorada.
Si bien se puede mostrar claramente que determinadas características de la presente invención son conocidas o tienen homólogos en diversas áreas de la informática general, las redes y la tecnología de la comunicación, es incorrecto suponer que es obvio de algún modo emplear o combinar dichas características en el contexto de sistemas EFT en los que la seguridad es primordial y los usuarios y proveedores de servicios son naturalmente conservadores. Por ejemplo, pueden ser conocidos dispositivos informáticos y de comunicación móviles que emplean un navegador especialmente modificado que permite al usuario acceder a contenidos de Internet de formato especial. Sin embargo, debido a la falta de características de hardware de alta seguridad y detección de manipulaciones, tales como un núcleo de alta seguridad (HSC) y otras características según EMV, no hay una forma efectiva de que un dispositivo móvil convencional de este tipo se pueda considerar para su uso como terminal seguro para transacciones financieras electrónicas.
El documento de patente US2003/217005A1 divulga un sistema de transacciones financieras electrónicas que limita las operaciones en el propio ATM (a través de un servidor local) y permite ofrecer más funcionalidades al usuario. La invención, en sus diversos aspectos y características preferentes, se define en las reivindicaciones adjuntas. Otros aspectos y características preferentes de la invención se desprenderán de la siguiente descripción de sus realizaciones preferentes.
16
En la siguiente descripción se presupone un conocimiento de sistemas EFT, funciones y terminología, así como un conocimiento de la terminología generalmente aceptada en materia de informática, redes informáticas y telecomunicaciones. Esto incluye términos definidos en las normas pertinentes y otros documentos producidos por el IETF, el foro WAP, la organización Unicode, W3C, ISO, ETSI, ITU y otras organizaciones, tanto nacionales como internacionales.
En la técnica anterior se conoce el documento US 2002/095480 A1, que describe máquinas bancarias automatizadas. El aparato mecanizado bancario automático se puede usar en una red de amplio alcance, que proporciona a un usuario una interfaz familiar de su institución de origen en las máquinas bancarias operadas por otras instituciones y que proporciona mayores opciones para salidas de la máquina.
Es un objeto de la invención superar las deficiencias de la técnica anterior. Este objeto de la invención se resuelve mediante las reivindicaciones independientes. Las realizaciones específicas se definen en las reivindicaciones dependientes.
Las realizaciones de la presente invención se describirán a continuación, a modo de ejemplo únicamente con referencia a los dibujos adjuntos, en los que:
la Fig. 1 muestra una vista lógica de un sistema de transacciones financieras según una primera realización de la invención;
la Fig. 2 muestra una vista lógica de aplicación de micronavegador utilizada en la realización ilustrada en la Fig. 1;
la Fig. 3 ilustra la estructura funcional de un sistema host remoto utilizado en el sistema de transacciones financieras electrónicas de la Fig. 1;
la Fig. 4 ilustra los componentes del sistema host remoto mostrado en la Fig. 3;
la Fig. 5 ilustra un ejemplo de despliegue físico de componentes del sistema de transacciones financieras electrónicas mostrado en la Fig. 1;
la Fig. 6 ilustra un flujo de procesos que muestra cómo el sistema de transacciones financieras electrónicas de la Fig. 1 procesa una tarjeta magnética;
la Fig. 7 ilustra un flujo de procesos que muestra cómo el sistema de transacciones financieras electrónicas de la Fig. 1 procesa una tarjeta inteligente;
la Fig. 8 ilustra un flujo de procesos que muestra cómo una página de contenido es descargada por un terminal utilizado en el sistema de transacciones financieras electrónicas de la Fig. 1;
la Fig. 9 ilustra un flujo de proceso de navegación y procesamiento de datos implementado por un terminal utilizado en el sistema de transacciones financieras electrónicas de la Fig. 1;
la Fig. 10 ilustra un proceso de autoconfiguración del terminal;
la Fig. 11 ilustra un primer modo de inicialización del terminal; y
la Fig. 12 ilustra una infraestructura de seguridad aplicable al sistema de transacciones financieras electrónicas de la Fig. 1.
Las Figuras 1-9 y 11 a 12 no son parte de la invención tal como se reivindica en el conjunto de reivindicaciones adjunto.
La presente invención proporciona un nuevo enfoque universal para sistemas EFT (de pago) con el cual la lógica empresarial se retira completamente del terminal a un sistema host remoto.
En el contexto de la presente invención, un terminal se considera como un visor de una aplicación tipo web situada dentro del sistema host remoto. Los datos introducidos por el usuario se procesan del mismo modo para todas las aplicaciones. Estos se envían al sistema host remoto y se procesan en este de forma especifica para la aplicación.
La Fig. 1 ilustra una vista lógica de un sistema según una primera realización. Se proporciona un terminal 10 para la interacción con un usuario final del sistema. en la realización ilustrada, el terminal incluye una pantalla, un teclado, un teclado numérico, una impresora, un lector de tarjetas magnéticas y un lector de tarjetas de circuito integrado (ICC).
El terminal 10 ejecuta una aplicación de software de "micronavegador" (micronavegador) 12 que puede renderizar y navegar por páginas que se describen según un lenguaje de marcado de terminal especificado (TML), que se describe con más detalle a continuación.
El micronavegador 12 se comunica con un sistema host remoto, que comprende un host de puerta de enlace 19, una aplicación de pago 22 y un servicio de configuración 26.
El host de puerta de enlace 19 incluye una aplicación ejecutable de puerta de enlace 14. La aplicación ejecutable de puerta de enlace 14 opera conjuntamente con un convertidor 16 y un proxy HTTP 18. La operación del host de puerta de enlace 19 se describe a continuación.
El proxy HTTP 18 sirve a uno o más servidores HTTP, en este caso un primer servidor HTTP 20 que ejecuta una aplicación de pago TML 22, y un segundo servidor HTTP 24 que ejecuta un servicio WEB 26.
El primer servidor HTTP 20 distribuye y gestiona una aplicación TML 22, que incluye tanto páginas TML estáticas como también el software del host adquiriente. El servidor HTTP 20 es también responsable de proporcionar un acceso privado y autorizado a la aplicación TML. Mientras procesa los envíos de terminal, la parte de host de la aplicación TML puede interaccionar con otros anfitriones. Se puede utilizar cualquier protocolo de transacción electrónica. La elección del protocolo dependerá del tipo de hardware utilizado, del tipo de transacciones implicadas y de los protocolos aprobados o utilizados habitualmente por las instituciones financieras del país en el que se utilice el terminal. Por ejemplo, en el Reino Unido pueden utilizarse los estándares APACS 30/50 y/o APACS 40 para comunicarse con el host de un adquiriente. Además, la aplicación TML puede actualizarse y configurarse mediante una GUI web 28. También utiliza una base de datos 200, que puede utilizarse para mantener una lista de terminales y un registro de comunicaciones. El adquiriente interacciona con una API 202.
Se accede al servicio WEB de configuración 26 a través de un de un marco de llamada a procedimiento remoto (RPC), y puede utilizarse para configurar automáticamente el terminal 10. El servicio web 26 puede actualizarse y configurarse mediante una GUI web 30 y hace uso de la base de datos de servicio de configuración 204, que puede utilizarse para mantener una lista de terminales y un registro de comunicaciones. El micronavegador 12 se ejecuta dentro del terminal 10. En lugar de la implementación real de la lógica empresarial requerida para completar una transacción, puede interpretarse como un intérprete de la lógica empresarial especificada por diferentes aplicaciones TML. El micronavegador 12 es una aplicación de terminal que está configurada específicamente para ser compatible con el TML especificado.
La Fig. 2 muestra detalles de los componentes del micronavegador 12, como sigue.
Una aplicación de micronavegador de terminal 32 es una envoltura para todos los subsistemas implementados según los requisitos del sistema operativo (OS) del terminal. Esta contiene el bucle de procesamiento principal del micronavegador 12 y puede procesar eventos del OS.
Por defecto, el micronavegador 12 se inicia inmediatamente después de cargar el OS. Este recupera un índice o raíz, URI y comienza a navegar por la página. Alternativamente, después de un evento de apagado, se puede restaurar el estado anterior al apagado. Cuando se elige un URI de "salida", el micronavegador 12 sale del bucle principal y pasa el control de flujo al OS.
El micronavegador 12 puede ejecutarse en un modo de aplicación basado en eventos cuando procesa eventos del OS, tales como pasar una tarjeta magnética o una tarjeta inteligente. Cada evento puede asociarse a un URI. El micronavegador 12 inicia entonces el bucle principal con el URI especificado para el evento.
La aplicación del micronavegador del terminal 32 es también responsable de mostrar al usuario la carga de la batería del terminal (cuando proceda, por ejemplo para terminales inalámbricos) y los indicadores de estado de la red.
El micronavegador 12 no requiere menús de configuración. Una aplicación TML puede cambiar la configuración del navegador 12 cambiando los valores de las variables TML o llamando a rutinas. Sin embargo, el micronavegador 12 incluye una página TML incrustada que se usa para cambiar la configuración del navegador.
Además de descargar y navegar por las aplicaciones TML, la aplicación de micronavegador terminal 32 también actualiza periódicamente la memoria caché y los datos de configuración del terminal 10, incluso si no hay datos que enviar.
Ya que no hay menús de configuración y al eliminarse la lógica empresarial del terminal 10, el micronavegador 12 es muy simple desde el punto de vista funcional. Desde la perspectiva de un usuario, esto significa que un usuario final del terminal 10 o un comerciante que quiera utilizar el terminal 10 para procesar pagos puede utilizar el terminal de una forma intuitiva y sencilla. Sin embargo, tal vez lo más importante desde la perspectiva del integrador de sistemas, es que la funcionalidad del terminal puede modificarse y los servicios de asistencia al cliente pueden ejecutarse sin necesidad de un conocimiento significativo de lenguajes de programación complejos. En su lugar, todo lo que se requiere es un conocimiento práctico de TML, que proporciona un entorno fácil de usar.
Para iniciar el terminal se utiliza un módulo de inicialización 34 que incluye la obtención de una contraseña única del terminal y un certificado raíz de seguridad y para comprobar la consistencia de datos después de encender el terminal. A continuación se aportan más detalles sobre el proceso de inicialización del terminal.
Un módulo de configuración 36 es responsable de la autoconfiguración del terminal a través de un marco de llamada a procedimiento remoto (RPC). La configuración puede incluir la sincronización horaria, la actualización de ajustes del terminal (por ejemplo la definición de URIs correspondientes a los eventos para el modo de micronavegador basado en eventos) o la descarga de parámetros para los analizadores de tarjetas. El módulo de configuración 36 trabaja con el cliente HTTP 38 para crear una solicitud HTTP con datos RPC y para recibir una respuesta, que se analiza a continuación para configurar el terminal.
El cliente HTTP 38 carga y analiza recursos, cada uno de los cuales se identifica mediante un URI. El analizador HTTP 40 es responsable de construir y analizar las solicitudes HTTP binarias. Si el recurso solicitado hace referencia a otros recursos, el módulo 38 también los recupera. El cliente HTTP 38 también mantiene una memoria caché de recursos localizada en una memoria permanente del terminal 10. En primer lugar, esta comprueba si el recurso solicitado existe en la memoria permanente y, si no lo encuentra, lo recupera del host de puerta de enlace 19 o a través del mismo.
El cliente HTTP 38 también envía datos al servidor HTTP (20, 24 en la Fig. 1), ya sea fuera de línea o en línea. Puede imprimir todos los envíos aplazados almacenados en la memoria del terminal y puede cancelar envíos. Además, el cliente HTTP 38 puede iniciar la autoconfiguración del terminal 10 cada vez que se conecta al host de puerta de enlace 19. Un conversor de servicios web y los stubs generados para cumplir los requisitos del módulo de configuración se incluyen en una biblioteca de llamada a procedimientos remotos (no mostrada).
El cliente HTTP 38 se comunica a través de una interfaz 42 de protocolo terminal seguro (STP), que puede abrir o cerrar la conexión, enviar una solicitud con varios paquetes HTTP envueltos y recibir respuestas. La interfaz 42 puede utilizar TLS, pila IP y una biblioteca criptográfica (no mostrada).
Se proporciona un analizador TML 44 para analizar páginas TML. Este verifica el formato de la página, declara las variables introducidas en la página y convierte TML al formato apropiado para su renderización y procesamiento (por ejemplo estructuras C).
El analizador TML 44 (entre otros módulos del micronavegador 12) hace uso de una biblioteca variable 46 que asigna espacio para nuevas variables en diferentes ámbitos, crea variables predefinidas, procesa elementos <setvar> asociados a la pantalla, recupera un valor de variable para el nombre de variable y ámbito especificados, cambia valores de variables y elimina todas las variables introducidas en la página especificada por el URI.
La biblioteca de variables 46 también es utilizada por un módulo de renderizado y navegación 48 que es responsable del renderizado de pantallas de visualización incluyendo el desplazamiento hacia arriba y hacia abajo y el resaltado de enlaces activos; la navegación a través de enlaces y elementos de formularios; la impresión de pantallas de impresión; el renderizado de pantallas de mensajes e indicaciones de formularios (en la pantalla del terminal); y el renderizado de formularios con un elemento <input>, incluyendo el renderizado apropiado de elementos de casillas de verificación marcadas y no marcadas y la paginación hacia arriba y hacia abajo.
Se proporciona un módulo de procesamiento de formularios 50 para procesar el formulario y las pantallas de envío. Este acepta y comprueba las entradas del usuario, asigna las entradas a las variables y construye los envíos TML. Los datos no se borran hasta que se envían al servidor HTTP (20,24) y se recibe un acuse de recibo, a menos que un usuario los borre intencionadamente. Hasta que se borren, los datos se pueden almacenar en la memoria permanente del terminal, de modo que no se pierdan en caso de que el terminal 10 se apague. Esto significa también que los formularios pueden procesarse incluso si el host del dominio del cliente es inaccesible. De este modo, un fallo de comunicación no provocará la inmovilización del terminal 10 o del host de puerta de enlace 19.
Las entradas guardadas en la memoria del micronavegador 12 pueden imprimirse, cancelarse o agruparse (en la siguiente conexión que el micronavegador 12 efectúa con el host o a petición de un usuario final). Estas funciones están protegidas por un supervisor a través de un menú de gestión con contraseña. Estas contraseñas se generan aleatoriamente para cada terminal y se almacenan en el host de puerta de enlace 19 en una base de datos con certificados de conexión (como se describe a continuación).
Un módulo analizador de tarjetas 52 es responsable de analizar las pistas magnéticas de las tarjetas y de interpretar la interacción con tarjetas ICC (inteligentes). El módulo analizador de tarjetas puede configurarse durante la autoconfiguración del terminal. La operación de este módulo se describe con más detalle a continuación.
El host de puerta de enlace 19 es una aplicación de host Java, que comprende una aplicación ejecutable de puerta de enlace 14, un proxy HTTP 18 y un conversor 16. La aplicación ejecutable de puerta de enlace 14 proporciona funcionalidades que incluyen la emisión de una contraseña de terminal única (que se utiliza para la autentificación posterior del terminal) para cada nuevo terminal introducido en la red, proporcionando a los terminales un certificado raíz, una autentificación de (los) terminal(es) y servidor(es) HTTP entre sí.
La aplicación ejecutable de puerta de enlace 14, junto con el conversor 16, tardan un máximo de 100 ms en procesar una solicitud en ambas direcciones desde el terminal 10, más la conversación de retorno. El host de puerta de enlace 19 pretende ser suficientemente robusto para estar disponible 99,9 % del tiempo, lo que significa que solo debería haber unas 9 horas de inactividad al año.
El proxy HTTP 18 proporciona funcionalidades que incluyen el establecimiento de conexiones HTTPS o HTTP en nombre del terminal 10 a los servidores HTTP 20,24 que ejecutan la aplicación TML y los servicios de configuración.
El conversor 16 es un componente conectable que convierte datos HTTP y XML de texto a formato binario y viceversa, y convierte imágenes de mapas de bits estándar a un formato que pueda ser renderizado por el terminal 10.
El host de puerta de enlace 19 también permite almacenar en caché páginas TML estáticas y datos de configuración (en la base de datos 54) para aumentar la eficacia del procesamiento de las solicitudes del terminal y mantener las páginas actualizadas.
La Fig. 3 muestra más detalles de la estructura del host de puerta de enlace. La aplicación ejecutable de puerta de enlace 14 se muestra como un oyente TCP/IP. La aplicación ejecutable de puerta de enlace 14 procesa cada sesión de terminal en un hilo separado (sesión STP) para cada conexión TCP/IP entrante. La solicitud STP 56 se transfiere al conversor 16 y se reenvía a uno de los servidores 20, 24 a través del proxy HTTP 18.
La aplicación ejecutable de puerta de enlace 14 llama al convertidor 16 para cada petición HTTP 58 reunida en el paquete STP 56. Como se ha indicado anteriormente, el conversor convierte los datos HTTP y XML de texto a formato binario y viceversa. Sin embargo, el conversor 16 comprende de hecho un número de "sub-converters", incluyendo un conversor HTTP binario, un conversor XML binario genérico (que puede parametrizarse con tablas de códigos), un conversor TML (que es una parametrización del conversor XML genérico para la versión particular de TML), un conversor de imágenes y un conversor RPC de servicios web.
A qué conversor se llame dependerá de la solicitud BHTTP 58 que se extraiga de la petición STP 56.
Para una solicitud STP, el conversor debe determinar el tipo de contenido de cada solicitud BHTTP extraída. Ya que la solicitud procede del terminal 10, el conversor TML se puede utilizar para todas las llamadas que no sean identificadas como llamadas de servicios web, en cuyo caso se utiliza el subconversor de servicios web. Sin embargo, para una respuesta STP, el tipo de contenido puede ser de muchos formatos diferentes, y el subconversor apropiado de cualquiera de los subconversores disponibles debe determinarse antes de empaquetar la respuesta. Como en el caso de las solicitudes STP 56, una respuesta STP puede incluir varias respuestas BHTTP.
Los subcomponentes que se utilizan en el host de puerta de enlace 19 se muestran en la Fig.4, en la que componentes similares se ilustran con números de referencia similares a los observados en la Fig. 1.
Los componentes del host de puerta de enlace 19 están desplegados dentro de una intranet segura. Sin embargo, los demás componentes del sistema pueden estar situados fuera de la intranet y, de este modo, todos los canales de comunicación entre el host de puerta de enlace 19 y estas partes deben protegerse cuidadosamente. Con este fin se puede utilizar una pila de protocolos en la que un terminal 10 utilice HTTP binario para enviar una solicitud 56. Las solicitudes de nivel inferior se empaquetan en STP y después se transfieren a través de TCP/IP con tunelización TLS. Durante la inicialización, el terminal 10 utiliza únicamente el nivel de tunelización seguro más bajo sin BHTTP ni ISTP. Cabe señalar que al establecer una sesión TLS, el host de puerta de enlace 19 envía su certificado de seguridad al terminal 10 para la autentificación. A continuación se proporcionan más detalles sobre medidas de protección apropiadas.
La operación del host de puerta de enlace 19 se describirá con más detalle a continuación.
Los parámetros de configuración del host de puerta de enlace 19 se refieren a la propia aplicación ejecutable de puerta de enlace 14 y son comunes para todos los terminales 10 conectados. Los parámetros de configuración pueden derivarse de archivos de configuración, que se cargan cuando se inicia el host de puerta de enlace 19 o de una interfaz remota, tal como una GUI web 60 (véase la Fig. 1) desde la que el host de puerta de enlace 19 puede recibir instrucciones para cambiar algunos de los ajustes iniciales. Si se modifican los ajustes comunes, estos solo tendrán efecto para terminales 10 que estén conectados después de haberse realizado el cambio.
Una solicitud de inicialización de un nuevo terminal 10 se gestiona (en un hilo separado) a través de un puerto de inicialización 64. Cada terminal tiene un ID de terminal (TID) único asociado, que puede ser, por ejemplo, una serie de ocho dígitos. El TID se envía a la aplicación ejecutable de puerta de enlace 14 con la solicitud de inicialización. La aplicación ejecutable de puerta de enlace 14 compara entonces el TID suministrado del terminal 10 con sus registros para verificar las credenciales del terminal 10 que efectúa la solicitud. Si se verifican, se genera una contraseña única, que se envía al terminal 10 junto con el certificado raíz (descrito a continuación). A continuación, la base de datos 66 se actualiza para registrar el terminal 10 como activado.
La aplicación ejecutable de puerta de enlace 14 escucha solicitudes de terminales 10 inicializados a través de un puerto de intercambio de datos 62. Una sesión de terminal se inicia en cada solicitud de terminal al puerto de intercambio de datos 62 y se ejecuta en un hilo separado. Cada sesión comprende pasos de autentificación del terminal, envío de la solicitud del terminal al servidor HTTP 20,24 y envío de la respuesta de los servidores HTTP 20,24 de vuelta al terminal. También se puede registrar la actividad de la sesión.
El TID del terminal se envía a la aplicación ejecutable de puerta de enlace 14 con la solicitud. A continuación, la aplicación ejecutable de puerta de enlace 14 realiza un número de iteraciones de un algoritmo de cifrado en la contraseña asociada a ese TID. El algoritmo de cifrado utilizado es el algoritmo arcfour y se utilizan cuatro iteraciones. Sin embargo, sería conveniente que pudieran emplearse otros algoritmos y/o un número diferente de iteraciones. La respuesta resultante representa una respuesta de control. A continuación, se solicita al terminal 10 que realice el mismo número de iteraciones del mismo algoritmo de cifrado y lo envíe como respuesta a la aplicación ejecutable de puerta de enlace 14. Si las respuestas no coinciden, la aplicación ejecutable de puerta de enlace 14 cierra la conexión; en caso contrario se crea una nueva sesión y se asigna a un hilo separado ("sesión STP") .
Si se producen errores en cualquier etapa de la transmisión de la solicitud del terminal 10 al servidor HTTP 20,24, o en la transmisión de la respuesta del servidor HTTP 20, 24 al terminal 10, estos se notifican en un paquete de respuesta y también se registran en la base de datos 66. Un informe de fallo podría generarse, por ejemplo, si hay demasiados hilos en procesamiento por la aplicación ejecutable de puerta de enlace 14 en el momento de la solicitud, si hay un tiempo de espera o un fallo de comunicación o si el conversor 16 es incapaz de procesar la solicitud. Si la conexión entre el servidor HTTP 20, 24 y un host de servicios web no se completa con éxito, la conexión STP sigue considerándose exitosa, pero el paquete de respuesta incluye un mensaje de advertencia.
Los informes de fallo y los mensajes de advertencia incluyen texto o un código de error que informa sobre dónde se ha producido el fallo y las razones del fallo.
La información relativa a cada sesión puede registrarse en la base de datos 66 y en la memoria del terminal 10 a través de una interfaz de registro común. La información registrada puede referirse, por ejemplo, a los tiempos de inicio y fin de las sesiones STP y de otro tipo, a la información del terminal, a detalles de los puertos utilizados y a detalles de las solicitudes HTTP. Es evidente que cualquier otra información de registro adecuada puede recopilarse y utilizarse con fines de diagnóstico según las necesidades.
La operación del servidor puede detenerse, ya sea en circunstancias "normales" en las que todas las solicitudes en el sistema global se procesan antes de que se apague el host de puerta de enlace 19, o en circunstancias de "emergencia" , en las que solo se completan las solicitudes STP, es decir, las solicitudes entre los terminales 10 y la aplicación ejecutable de puerta de enlace 14.
La gestión remota está disponible a través de la interfaz remota 60 mediante la invocación de métodos remotos (RMI). Las funciones disponibles a través de la gestión remota incluyen la obtención y la modificación de parámetros de configuración de host de puerta de enlace 19 (incluyendo puertos utilizados, parámetros de sesión STP (tiempo de espera), información sobre el host proxy HTTP y el puerto); la obtención de estadísticas de actividad del host de puerta de enlace 19; y la detención del host de puerta de enlace 19.
La Fig. 5 muestra un ejemplo de despliegue físico de los componentes del sistema descritos anteriormente, con componentes similares identificados con números de referencia similares a los observados en diagramas anteriores. Los componentes se comunican entre sí a través de TCP/IP, con el resto de la funcionalidad, incluyendo mecanismos de seguridad, construida sobre la capa TCP/IP en la pila de protocolos.
El host de puerta de enlace 19 se comunica a través de la aplicación ejecutable de puerta de enlace 14 con una autoridad de certificación 70, como se describe con más detalle a continuación. El primer servidor HTTP 20 y la aplicación TML 22 forman parte de un host de aplicación TML 72, y el segundo servidor 24 y el servicio de configuración 26 forman parte de un host de servicios WEB 74. Cabe señalar que la Fig. 5 no muestra componentes auxiliares, como anfitriones de interfaz web, servidores de bases de datos, etc.
Debe tenerse en cuenta que la implementación mostrada en la Fig. 5 es solo una subsección de un ejemplo particular de implementación. Los componentes del sistema pueden distribuirse en un número de ordenadores mayor o menor. Incluso el micronavegador 12 puede no ejecutarse realmente dentro del terminal, sino emularse utilizando un simulador de terminal.
La preocupación principal que debe considerarse al desplegar el marco es la seguridad. Si no es posible conectar algunos componentes utilizando protocolos de red seguros (por ejemplo la aplicación ejecutable de puerta de enlace 14 y el proxy HTTP 18 se comunican utilizando HTTP en lugar de HTTPS), estos componentes se deben ubicar dentro de una red privada y detrás de un cortafuegos común para reducir el riesgo de ataques externos al sistema.
Como se ha descrito anteriormente, el analizador de tarjetas 52 (un componente del micronavegador 12) es responsable de analizar las pistas de tarjetas magnéticas y de la interacción con tarjetas inteligentes. La operación de este analizador 52 se describirá con más detalle a continuación.
El analizador de tarjetas 52 proporciona un medio sencillo y genérico para que la aplicación TML que se ejecuta en el micronavegador 12 interprete datos procedentes del lector de tarjetas que es parte del terminal 10. El analizador 52 hace uso de una biblioteca 80 (véase la Fig. 2) y funciona para leer y analizar datos de una tarjeta; verificar la tarjeta y el titular de la tarjeta; y aplicar una política de gestión de riesgos. El analizador 52 también puede configurarse durante la autoconfiguración del terminal.
El analizador de tarjetas 52 proporciona únicamente un método de interfaz para la aplicación TML que se ejecuta en el micronavegador, que tiene solo un único parámetro de serie. Esta serie es normalmente solo un comando, que debe ser ejecutado por el analizador 52. Toda la información restante se pasa al analizador 52 o se obtiene a partir del mismo mediante las variables definidas en el TML.
El procesamiento de una tarjeta magnética se ilustra en la Fig. 6. En esencia, los pasos realizados durante el procesamiento de una tarjeta magnética son estándar. Sin embargo, la manera en la que un sistema de transacciones financieras electrónicas implementado según una realización de la invención lleva a cabo esta tarea conocida no es estándar, y se describirá a continuación.
La aplicación TML que se ejecuta en el micronavegador 12 puede utilizar la funcionalidad del analizador a través de una pantalla <tform> con un elemento <card>. El nombre del analizador a llamar se especifica en el atributo parser de estos elementos y el parámetro se especifica en el atributo parser_params.
En el caso de que no se pueda completar el análisis, el analizador 52 rellena una variable baddata_reason y se renderiza el mensaje especificado en un elemento <baddata>, que proporciona al usuario información sobre los motivos del fallo.
En uso, la aplicación TML llama primero al analizador 52 y espera a que se introduzca la tarjeta, se establezca el contexto se lean los datos de la tarjeta y se verifique la propia tarjeta. Después de esto, la aplicación TML puede analizar las variables rellenadas por el analizador y, si es necesario, pedir al usuario datos adicionales correspondientes a la transacción, y llamar de nuevo al analizador 52. Durante otras llamadas, el analizador 52 puede realizar un proceso de gestión de riesgos, realizar otras interacciones con la tarjeta, etc. y rellenar otras variables TML.
Además, puede pedirse al analizador 52 que realice algunas acciones particulares con la tarjeta, por ejemplo verificar el PIN de una ICC (tarjeta inteligente).
El analizador 52 puede estar configurado para soportar un contexto relacionado con la transacción en proceso y debe revisar este contexto para cada nueva tarjeta utilizada.
Adicionalmente, el analizador 52 puede estar soportar estadísticas sobre todas las transacciones (por ejemplo la cantidad actual de transacciones fuera de línea para la gestión de riesgos). El cliente HTTP 38 informa a todos los analizadores (40,44,52) cuando los envíos aplazados se agrupan en el servidor para permitirles restablecer sus contadores.
El analizador de tarjetas 52 comprende actualmente un número de "sub-parsers" para analizar distintos tipos de tarjetas.
Estos subanalizadores incluyen un analizador de tarjetas magnéticas, un analizador ICC EMV y un analizador de inicialización ICC.
El analizador de tarjetas magnéticas trata con tarjetas con pistas ISO estándar. Puede leer pistas de la tarjeta, analizarlas y verificar el número de tarjeta y la fecha de vencimiento de la tarjeta. Adicionalmente, realiza un proceso de gestión de riesgos basado en límites mínimos por esquema (es decir, límites de valor utilizados para determinar qué transacciones deben autorizarse). Para ello, realiza un seguimiento de las operaciones de pago fuera de línea aprobadas.
El analizador de tarjetas magnéticas lee y actualiza variables que son bien conocidas para el análisis de datos de tarjetas magnéticas. Además, se define una variable de serie cardjparser. Cuando se lee una tarjeta magnética, esta variable debe ser rellenada por el analizador 52 a "mag". También puede definirse una variable entera card_input_mode. Por ejemplo, el valor entero 1 podría representar el paso de una tarjeta magnética, 2 podría representar el uso de una ICC y 3 podría utilizarse para representar la introducción de detalles de la tarjeta utilizando el teclado del terminal. Cuando se llama al analizador 52 con el comando "read_data", esta variable debe ajustarse a 1. Si se llama al analizador 52 con el comando "risk_mgmt", esta variable debe comprobarse y si es 3 debe verificarse el número de tarjeta y la fecha de caducidad y debe rellenarse una variable que represente el número parcial de tarjeta a imprimir en el recibo.
Sería conveniente que los nombres dados a estas variables y el número y la asignación de posibles valores variaran sin cambiar la funcionalidad de las variables.
El analizador 52 soporta dos comandos que son visibles para la aplicación TML: un comando "read_data" 90 y un comando "risk_mgmt" 92. Durante el comando "read data" 90, el analizador de tarjetas lee pistas ISO de la tarjeta, las analiza y rellena las variables "card_*" e "iso*', que proporcionan detalles de la tarjeta y la información contenida en las pistas ISO de la tarjeta. Además, el analizador verifica el número de tarjeta y la fecha de vencimiento y, si es necesario, genera una condición de "bad data".
Tras la emisión del comando de lectura 90, la aplicación TML pregunta al comerciante por los importes de transacción y el tipo de transacción. Esta información es necesaria para tomar una decisión sobre el procesamiento en línea, el procesamiento fuera de línea o la declinación de la transacción. La aplicación TML rellena una variable verdict que asigna el modo de procesamiento de la transacción, es decir, fuera de línea o en línea, o rechazada.
Si los datos de la tarjeta se introducen manualmente utilizando el teclado del terminal, no se emite el comando "read_data" 90 y la aplicación TML debe ajustar la variable card_input_mode a 3.
El comando "risk_mgmt" 92 es utilizado por la aplicación TML para pedir al analizador que realice un proceso de gestión de riesgos. Durante este proceso, el analizador 52 analiza los importes y el tipo de transacción, el esquema y el emisor de la tarjeta y sus estadísticas internas y toma una decisión considerando las recomendaciones definidas en la aplicación TML. Por ejemplo, la transacción se puede rechazar si los detalles de la tarjeta introducidos manualmente son incorrectos. El veredicto y la razón del rechazo se devuelven a la aplicación TML.
El comando "risk_mgmt" 92 se utiliza también cuando falla la publicación de datos durante un intento de publicación en línea. El analizador 52 descubre esta situación a través de una variable "econn_reason" 94 que se rellena por el cliente HTTP 38. El proceso de gestión de riesgos se ejecuta de nuevo y la política configurada se utiliza para aprobar el procesamiento fuera de línea o cancelar la transacción.
El analizador ICC EMV está destinado a interaccionar con tarjetas ICC (inteligentes) que soportan la aplicación de pago EMV. Es responsable de la selección de la aplicación; la autentificación estática y dinámica de datos fuera de línea; el descubrimiento de capacidades de la tarjeta; la verificación del PIN fuera de línea; la gestión de riesgos EMV; la generación de TC, AAC, ARQC y otros datos necesarios para realizar las transacciones bajo el protocolo de transacciones financieras electrónicas elegido (tales como APACS); la ejecución del script del emisor y la recuperación de los resultados.
El analizador ICC EMV lee y actualiza variables que son bien conocidas para la interpretación de datos ICC. Además, también se utilizan la variable de serie card_parser y la variable entera card_input_mode cuando son utilizadas por el analizador de tarjetas magnéticas. Siguiendo el ejemplo anterior, la variable entera card_input_mode debe ajustarse a 2, y la variable de serie card_parser debe ser rellenada por el analizador para ser "icc-emv".
La operación del analizador ICC, EMV se ilustra en la Fig. 7. En esencia, los pasos realizados durante el procesamiento de una ICC (tarjeta inteligente) son estándar. Sin embargo, la manera en la que un sistema de transacciones financieras electrónicas implementado según una realización de la invención lleva a cabo esta tarea conocida no es estándar, y se describirá a continuación.
El primer comando emitido por la aplicación TML al analizador de tarjetas ICC EMV es un comando "init_app" 100, utilizado para iniciar la aplicación ICC. Durante el procesamiento de este comando, el analizador debe realizar la selección de la aplicación, leer los datos de la aplicación y realizar la autentificación estática o dinámica de los datos fuera de línea. Como resultado, el analizador debe rellenar las variables TML apropiadas que se refieren a detalles de la tarjeta y de la aplicación ICC.
Ya que otros comandos también interaccionan con la ICC, la tarjeta debe permanecer insertada en el lector de tarjetas durante el procesamiento de la transacción.
Después de la inicialización, la aplicación TML debe verificar el titular de la tarjeta. Pregunta al comerciante por los datos de la transacción (importes y tipo de transacción) y emite un comando para que el analizador recupere de la ICC una lista de métodos de verificación del titular de la tarjeta y almacene estos métodos en una variable "cvm". Por ejemplo, los posibles métodos de verificación de la tarjeta incluyen la verificación del PIN realizada por el host, la verificación del PIN realizada por la propia tarjeta ICC, la verificación del PIN por la ICC junto con la verificación de la firma por el comerciante, o que no se requiera la verificación del titular de la tarjeta. Además, cuando la ICC soporta una verificación del PIN fuera de línea, el analizador recupera la clave a utilizar para el cifrado del PIN y la almacena en una variable específica. También se pueden soportar métodos biométricos de verificación ID.
La aplicación TML rellena entonces una variable de resultado de verificación de la tarjeta, que puede confirmar el éxito, o establecerse en un número de opciones diferentes dando diferentes razones del fallo.
Si se elige un método que implique comprobación de la firma, la aplicación TML pasa a una pantalla <print> para imprimir un recibo con una solicitud de firma. Seguidamente se pide al comerciante que verifique la firma del titular de la tarjeta. Si la firma es incorrecta, se debe preguntar al analizador por el siguiente método de verificación del titular de la tarjeta.
Seguidamente se ejecuta un proceso de gestión de riesgos que, de un modo similar al del analizador de tarjetas magnéticas, decide si realizar la transacción en línea o fuera de línea, o rechazar la transacción en base a los parámetros de configuración. En el ejemplo específico del analizador ICC, EMV, las variables relativas a los números de transacción ICC y los detalles criptográficos, así como los datos sobre la ICC y los resultados de verificación, deben enviarse al host de puerta de enlace 19.
Si el veredicto del proceso de gestión de riesgos es que debe realizarse un envío de datos en línea, la aplicación TML realiza un paso de autorización, obteniendo un criptógrafo de autentificación de la aplicación (AAC) y un contador de transacciones (TC) desde la ICC. Una vez se confirma que el resultado de esta autorización es satisfactorio, se desactiva la tarjeta.
También se proporciona un analizador separado para la interacción con una ICC durante la inicialización del terminal en blanco.
El sistema puede acomodar el uso de un simulador de terminal 110 (véase la Fig. 3). Esto proporciona una herramienta útil para producir demos y depurar aplicaciones TML tanto a los creadores de la aplicación TML como también a los creadores del sistema. Desde el punto de vista de los creadores de la aplicación TML, el simulador se parece a un terminal 10 con una aplicación de micronavegador de terminal 32 cargada. Puede ejecutarse como un archivo ejecutable de Windows e interacciona con el host de puerta de enlace 19 de la misma manera que un terminal normal. Desde el punto de vista de los creadores del sistema, el simulador 110 puede considerarse una biblioteca, que puede vincularse al código de la aplicación del micronavegador, permitiendo de este modo la depuración del micronavegador en una plataforma de PC, y permitiendo también la experimentación para ayudar en el futuro desarrollo.
El simulador 110 no debe emular la arquitectura ni el sistema operativo de los terminales 10. Solo se requiere emular las bibliotecas del OS utilizadas por el micronavegador (responsables de la interacción con periféricos del terminal, la criptografía, la gestión de eventos y mensajes, etc.) e implementar el entorno de tiempo de ejecución de la aplicación del micronavegador del terminal (es decir, la gestión de la aplicación).
TML es un lenguaje basado en XML que comparte algunas características con XHTML y con WAP WML. Se utiliza para definir los contenidos estáticos y dinámicos cargados en el terminal, así como los datos publicados por los terminales al servidor HTTP.
Una aplicación TML puede comprender varias páginas. Normalmente hay una página raíz desde la que se hace referencia a todas las demás páginas utilizando un elemento XHTML <link> estándar. Las páginas estáticas pueden cargarse previamente, lo que evita que el terminal tenga que conectarse al host cada vez que aparece un URI que haga referencia a la información estática. La Especificación de Hojas de Estilo en Cascada (CSS), que se utiliza para renderizar páginas TML, debe ser referenciada desde cada página. Por defecto, se utiliza el CSS integrado. Las imágenes que aparecen en una página concreta también deben referenciarse utilizando el elemento <link>.
Las directivas de estilo y los elementos de agrupación de estilo <span> y <div> no están permitidos preferentemente en TML. Los estilos para un elemento se pueden especificar utilizando los atributos "class" e "id". Tampoco se soportan scripts preferentemente.
Cada página TML consiste en varias pantallas o unidades de procesamiento de navegador. Cada pantalla tiene un URI, que se construye a partir del URI de la página TML y el identificador de pantalla. Las pantallas se introducen para acelerar la descarga de aplicaciones TML al terminal, ya que múltiples pantallas pueden reunirse en una única página TML. Además, cada página restringe el ámbito de variables locales definidas en ella.
Se pueden utilizar diferentes tipos de pantalla, que pueden incluir pantallas de visualización, impresión, mensajes, formularios y llamadas a funciones.
Una pantalla de visualización puede considerarse una página HTML habitual. Puede contener hipervínculos y desplazarse hacia arriba y hacia abajo. Siempre se renderiza en la pantalla del terminal.
El contenido de una pantalla de impresión también es de tipo HTML, pero se imprime utilizando la impresora del terminal integrado. Tras la impresión, el micronavegador pasa al URI especificado. Los hipervínculos se ignoran. Una pantalla de mensajes se utiliza para renderizar mensajes de error, advertencia o éxito. El mensaje se renderiza en la pantalla del terminal durante un número especificado de segundos. Una vez transcurrido este tiempo, el micronavegador pasa al URI especificado. Si el usuario pulsa una tecla, el micronavegador 12 pasa inmediatamente a la siguiente pantalla.
Las pantallas de formularios (o envío) se utilizan para recoger, gestionar y enviar los datos del usuario. Estos se describen a continuación con más detalle.
Se utiliza una pantalla de llamada a funciones para llamar a las funciones C del terminal por su nombre. Esta opción se requiere para páginas TML que contienen menús para la configuración del terminal o del micronavegador.
TML presenta numerosos elementos a nivel de bloque y a nivel de texto, que son similares a los de XHTML. La mayoría de ellos tienen la misma sintaxis y semántica que en XHTML, pero existen algunas restricciones y mejoras importantes. Por ejemplo, preferentemente, los marcos de HTML4 no se soportan en TML. Asimismo, además de los atributos utilizados en HTML4 para el elemento <input> (es decir, texto, contraseña, casilla de verificación, radio, envío, reinicio, botón), se permite un atributo adicional para especificar el dispositivo de entrada, es decir, el habitual teclado del terminal, o un teclado numérico.
Las variables TML pueden estar predefinidas (como fecha y hora) o ser declaradas por el usuario. El ámbito de una variable puede restringirse a una única página TML o puede definirse como global. El tipo de una variable puede definirse como serie, fecha, número entero u opaco (datos binarios).
Las variables TML pueden cambiar sus valores cuando el micronavegador pasa a una nueva pantalla, utilizando un elemento <setvar>. Este elemento se utiliza también para asignar información de datos del usuario a las variables. Las pantallas TML para renderización en la pantalla del terminal o impresión utilizando la impresora integrada pueden incluir referencias a las variables. Durante la renderización o la impresión, las referencias se sustituyen por los valores de las correspondientes variables.
El terminal puede enviar los valores de variables al servidor HTTP, donde son procesados por la aplicación TML. Las variables se utilizan también para almacenar los ajustes del sistema y del micronavegador. La aplicación TML puede cambiar los valores de variables para actualizar la configuración del micronavegador.
El elemento TML <tform> se ha introducido para describir los datos que se pueden introducir por el usuario. Los usuarios pueden introducir los datos pasando una tarjeta magnética, insertando una tarjeta inteligente (ICC), utilizando un teclado numérico o utilizando el teclado del terminal.
Los datos de texto introducidos por el usuario se marcan con elementos XHTML <input> y <textarea>. Los elementos que se utilizan para marcar la entrada del teclado deben estar siempre reunidos en un elemento XHTML <form> simplificado. Esto permite el uso de varios elementos <input>, <textarea> y <number> en un único formulario para situarlos en otros elementos XHTML (tablas, listas, etc.).
Los datos introducidos se asignan a variables predefinidas (por ejemplo "pin", "carholder", etc.) o definidas por el usuario. TML permite la evaluación de los datos introducidos, que puede incluir la coincidencia del valor máximo/mínimo o la longitud de la serie, y también la verificación de detalles de la tarjeta, incluyendo número de tarjeta y/o fecha de vencimiento.
Si los datos son incorrectos, el terminal debe renderizar un mensaje de error, que se especifica mediante un elemento <baddata>, y pasa a la pantalla de formulario.
En lugar de enviarse inmediatamente al servidor HTTP, los datos introducidos por el usuario durante el procesamiento del formulario se envían al servidor utilizando la pantalla de envío. La pantalla de envío especifica los valores de las variables que se enviarán al servidor HTTP, que pueden haberse recogido en múltiples pantallas previas.
Los envíos pueden ser fuera de línea o en línea. El envío en línea supone que el terminal 10 se conecta inmediatamente al host de puerta de enlace 19 y envía los datos. Para el envío fuera de línea, el terminal 10 construye el correspondiente elemento <tmlpost> y lo almacena en la memoria permanente del terminal. Los envíos aplazados se transfieren al host de puerta de enlace 19 durante la siguiente sesión de aplicación ejecutable de terminal/puerta de enlace.
Cada pantalla de envío especifica un URI de destino para envío. Los datos enviados por el terminal 10 son procesados por el host de puerta de enlace 19 antes de ser enviados al servidor HTTP, donde son procesados por la aplicación TML. La aplicación TML valida entonces los datos recibidos y genera una respuesta.
Los elementos de envío incluyen también un URI que especifica la ubicación dentro del código, a la que el micronavegador debe pasar una vez el envío se realiza con éxito. Para envíos en línea, también debe especificarse la URI a la que se debe pasar si el envío falla. Además, la aplicación TML puede generar una respuesta con un código de respuesta "see other" para forzar al micronavegador a pasar a otro URI especificado o para generar una respuesta con un contenido TML dinámico (para envíos fuera de línea, se ignora tal respuesta). Los formularios TML soportan la funcionalidad de dispositivos terminales, incluyendo una pantalla gráfica, un teclado, una impresora integrada, un teclado numérico, un lector de tarjetas magnéticas, un lector de tarjetas inteligentes y la introducción segura de PIN fuera de línea. Para soportar diferentes formatos de tarjetas inteligentes y diferentes modos de análisis de pistas magnéticas, existen tags TML que permiten conectar diferentes rutinas de análisis, por ejemplo para considerar los diferentes tipos de datos que se encuentran en diferentes tipos de tarjetas inteligentes.
Es posible almacenar dinámicamente más de una aplicación TML en la memoria permanente del terminal. La aplicación TML en su forma binaria persiste en la memoria del terminal tras el reinicio. La aplicación TML también se almacena en caché en el micronavegador TML. El micronavegador recarga la página TML almacenada en caché automáticamente si la página TML se ha modificado dentro del contenedor de recursos HTTP o si la página TML ha vencido. El micronavegador TML recarga el contenido estático almacenado en caché cada vez que se conecta al host de puerta de enlace 19 para enviar datos o para obtener contenido TML dinámico.
Cada página que no debe almacenarse en caché o reutilizarse se marca con un atributo "no-cache". Tales páginas se borran de la memoria del terminal en un momento justo antes de que el micronavegador 12 comience a procesar la siguiente página. El atributo "no-cache" es muy similar a la directiva HTTP "no-cache".
Del mismo modo, las páginas que deben almacenarse en caché van acompañadas de la cabecera "ETag" HTTP generada por el host de puerta de enlace 19.
El host de puerta de enlace 19 es responsable de almacenar en caché las páginas TML y de mantener actualizada la memoria caché de todos los recursos cargados en los terminales (incluyendo E-tags generadas). Cada vez que el terminal 10 se conecta al host de puerta de enlace 19, envía una solicitud HTTP GET condicional con ETags para cada recurso cacheable almacenado en la memoria del terminal. El host de puerta de enlace 19 puede responder que el recurso no se ha modificado o enviar una nueva versión del recurso.
Un usuario con derechos administrativos está autorizado para eliminar todos los recursos almacenados en caché dentro del terminal.
La parte de host del software TML representa un conjunto de aplicaciones Java identificadas mediante URIs. Estos URIs deben especificarse como destino para elementos de envío. El servidor HTTP llama a las aplicaciones Java para procesar solicitudes a los puertos especificados recibidas desde los terminales a través del host de puerta de enlace 19. Las aplicaciones procesan las solicitudes y generan las correspondientes respuestas HTTP que se devuelven a los terminales 10.
Mientras procesa las solicitudes, la aplicación TML puede interaccionar con otros anfitriones (por ejemplo con el host de un adquiriente que utilice un protocolo de transacciones financieras electrónicas apropiado, como el estándar APACS 30).
Una aplicación de pago TML básica 22 es un componente del sistema que puede utilizarse como base para desarrollar aplicaciones TML propias. La aplicación comprende varias (2-3) páginas TML y una aplicación de host Java que se comunica con el host del adquiriente. La aplicación tiene preferentemente una interfaz web para la supervisión y el control remotos.
A continuación se describirán con más detalle aspectos del uso y del comportamiento del sistema.
El terminal 10 descarga páginas estáticas de la aplicación TML desde el servidor HTTP 20,24. Estas se almacenan entonces en la memoria caché del terminal, de modo que no sea necesario volver a cargarlas hasta que haya que modificar la aplicación.
La Fig. 8 ilustra cómo el terminal 10 descarga una aplicación TML desde el host de puerta de enlace 19. El terminal 10 se conecta al host de puerta de enlace 19 utilizando un protocolo de transmisión segura (STP).
El micronavegador 12 detecta que falta el recurso solicitado (normalmente tras la carga inicial o al seguir un hipervínculo). El cliente HTTP 38 comprueba si el recurso solicitado existe en la memoria caché del terminal 10 y está actualizado. En caso afirmativo, el recurso se recupera de la memoria caché del terminal 10 y se devuelve al micronavegador 12. En caso negativo, el cliente HTTP 38 construye una solicitud binaria HTTP GET (condicional o incondicional) con el URI especificado y la envía a la aplicación ejecutable de puerta de enlace 14. El conversor 16 traduce entonces la solicitud recibida y la envía de vuelta al servidor HTTP 20, 24 a través del proxy HTTP 18. El proxy 18 recupera el recurso solicitado desde su memoria caché 206 (véase la Fig. 3) utilizando el URI identificado en la solicitud o establece una conexión con el servidor HTTP 20, 24 especificado y remite la solicitud al servidor 20, 24, que responde entonces con la página TML solicitada enviada en formato XMl de texto. El conversor 16 traduce entonces la página XML al formato XML binario y la envía al terminal 10. El terminal 10 analiza el marcado TML y (si es necesario) carga páginas TML enlazadas, CSS, imágenes, etc.
Una vez se ha completado el análisis TML, el terminal 10 pasa a la pantalla especificada por medio del URI en la página TML descargada. La Fig. 9 ilustra el proceso de navegación por la aplicación.
Al pasar de una pantalla a otra, el terminal 10 actualiza los valores de las variables (utilizando elementos <setvar>) asociadas a la pantalla de destino, si estos valores son requeridos para generar el texto. El terminal procesa entonces la pantalla según corresponda al tipo de pantalla.
Para pantallas de visualización, mensajes y formularios, el terminal renderiza el contenido en la pantalla del terminal. El contenido puede incluir hipervínculos. El texto puede desplazarse hacia arriba y hacia abajo y los hipervínculos pueden seleccionarse utilizando el teclado del terminal. Para la ventana del formulario, cuando el usuario señala al elemento del formulario, el terminal está preparado para aceptar la entrada especificada en el formulario (entrada de teclado, paso de tarjeta magnética, entrada de pin, etc.) o para cancelarla. Los datos introducidos por el usuario se almacenan en variables.
Durante el procesamiento de la pantalla de envío, el terminal construye un documento TML (en formato binario) que contiene los valores de variables especificadas y lo envía al servidor HTTP a través del host de puerta de enlace. El URI del host de puerta de enlace también se define en la página TML.
Cuando la pantalla se procesa, el terminal pasa a la siguiente pantalla. Para la pantalla de visualización, esto se hace siguiendo el enlace elegido por el usuario. Para las pantallas de formulario, mensaje e impresión, se sigue el URI especificado en el elemento <new>. Para la pantalla de envío, se sigue el URI especificado en los elementos <new> o <econn>. El servidor HTTP también puede forzar al micronavegador 12 a pasar a otra pantalla o página TML (estática o dinámica). Para la pantalla de llamada a función se sigue el URI especificado en los elementos <new> o <error>.
Para cualquiera de los tipos de pantalla, si se especifica un elemento <cancel> para la pantalla y el usuario pulsa "Cancel", el micronavegador debe pasar a la pantalla identificada por el URI especificado en <cancel>. Cuando se especifica la palabra "exit" en lugar de URI, el terminal sale del micronavegador y pasa el control de flujo al sistema operativo del terminal.
Si se pulsa la tecla "menu" durante el procesamiento de pantallas de visualización o formularios, el micronavegador pasa al URI especificado en el atributo "menu" para esa página TML.
Los elementos <new>, <cancel>, <error> y <econn> permiten identificar explícitamente el URI para la pantalla que se procesa a continuación o que se obtendrá a partir de la variable TML. Además, es posible especificar más de un URI para los elementos anteriores. El URI de la siguiente pantalla se elige tras evaluar las expresiones lógicas especificadas frente a las variables y constantes TML.
A continuación se ilustrará un ejemplo específico de navegación TML. Supongamos que una aplicación comprende las siguientes pantallas:
una pantalla de formulario para el procesamiento de tarjetas magnéticas con la indicación "SWIPE CARD"; un formulario para introducir la cantidad de dinero a pagar con la indicación "ENTER AMOUNT";
una pantalla de visualización para elegir una transacción en línea o fuera de línea;
dos pantallas de envío, una para cada una de las transacciones en línea y fuera de línea;
una pantalla de impresión para imprimir el recibo; y
una pantalla de mensajes para las autorizaciones de pago rechazadas con el mensaje "CALL AUTH CENTER".
En primer lugar, el micronavegador procesa la pantalla del formulario para una tarjeta magnética. Renderiza el mensaje especificado para el formulario y espera a que se pase la tarjeta. Cuando se pasa la tarjeta, el navegador analiza las pistas de lectura y asigna valores a variables globales predefinidas (tales como número de tarjeta, titular de la tarjeta, vencimiento, etc.) y entonces pasa al formulario para introducir la cantidad de dinero. El terminal renderiza una indicación "ENTER AMOUNT" y espera la entrada a través del teclado del terminal. El importe introducido se guarda en la variable con el nombre especificado en el formulario. El navegador pasa entonces a la pantalla de visualización. La pantalla de visualización contiene dos enlaces con los nombres "online" y "offline". El usuario puede utilizar el micronavegador 12 para navegar por la pantalla. Cuando el usuario pulsa "Enter" con un foco en uno de los enlaces, el micronavegador sigue el enlace. Durante el procesamiento de la pantalla de envío, el micronavegador construye los datos que deben enviarse al servidor HTTP (los valores asignados en la pantalla del formulario) y los almacena en la memoria del terminal.
Si el envío es en línea, el cliente HTTP envía los datos inmediatamente. El micronavegador espera la respuesta POST del servidor HTTP antes de pasar páginas. El servidor HTTP puede ordenar al terminal que pase a la pantalla de impresión si la autorización se realizó con éxito, o a la pantalla de mensaje con el mensaje "CALL AUTH CENTER", si la autorización ha fallado.
Si el envío es fuera de línea, los datos permanecen en la memoria del terminal hasta la siguiente sesión con el host de puerta de enlace 19. El navegador pasa inmediatamente a la pantalla de impresión.
Durante el procesamiento de la pantalla de impresión, el terminal imprime el recibo (el cuerpo de impresión puede contener referencias a variables, número de tarjeta, importe, vencimiento, etc.) y pasa a la pantalla de inicio, el formulario "SWIPE CARD", para servir a otro cliente.
A continuación se describirán los métodos de actualización de la aplicación TML.
Cada vez que el terminal interacciona con el host de puerta de enlace, el host de puerta de enlace envía al terminal solicitudes HTTP GET condicionales para cada página TML cacheable almacenada en la memoria permanente del terminal.
El cliente HTTP del terminal responde a la solicitud GET con la correspondiente ETag (es decir, identificador de contenido cacheable) HTTP generada por el proxy HTTP del host de puerta de enlace. La aplicación ejecutable de puerta de enlace evalúa ETags y si estas coinciden no se devuelve ningún contenido al terminal. En caso contrario, la página TML se recarga y se reanaliza.
La Fig. 10 muestra la operación de un proceso de autoconfiguración del terminal. Una autoconfiguración del terminal puede tener lugar cada vez que el terminal 10 se conecta al host de puerta de enlace 19.
Los datos enviados al terminal, así como las respuestas del servicio de configuración 26, se almacenan en caché por el proxy HTTP 18.
La autoconfiguración utiliza llamadas RPC. El cliente HTTP 38 del terminal solicita al módulo de configuración del terminal 36 la construcción de la solicitud binaria y la agrupa en un paquete STP que se envía al host de puerta de enlace 19.
El conversor 16 traduce entonces la solicitud HTTP binaria a forma de texto y la remite al proxy HTTP 18. El proxy HTTP 18 puede recuperar la respuesta de la memoria caché 206 o remitir la solicitud posteriormente al host de servicio web 26 para el procesamiento.
El conversor 16 traduce entonces la respuesta a forma binaria y la envía al cliente HTTP 38 del terminal, que devuelve la respuesta al módulo de configuración 36, que analiza a su vez la respuesta para configurar el terminal 10.
A continuación se discutirá un ejemplo de la autoconfiguración del terminal.
Supongamos que el terminal tiene que actualizar los límites mínimos y la hora. Cada vez que el cliente HTTP 38 establece una sesión con el host de puerta de enlace 19 construye un paquete STP que reúne varias solicitudes. Por ejemplo, cuatro solicitudes POST con envíos fuera de línea; una solicitud POST con envío en línea; y dos solicitudes GET condicionales para una aplicación TML y una hoja de estilo. El cliente HTTP solicita entonces al módulo de configuración la construcción de dos solicitudes HTTP POST con llamadas a procedimientos remotos; una RPC para obtener los límites mínimos y otra para obtener la hora.
El paquete STP con las solicitudes agrupadas se envía al host de puerta de enlace 19. Tanto las solicitudes HTTP POST como también las respuestas con RPC pueden almacenarse en caché, por lo que el proxy HTTP 18 es capaz de responder sin preguntar al servidor HTTP 20,24. No obstante, si la respuesta requerida no se encuentra en la memoria caché, la solicitud HTTP de texto se envía al servidor HTTP 24 que ejecuta el servicio web de configuración 26. El servicio 26 procesa la llamada a procedimiento remoto recuperando los datos requeridos de la base de datos. En este caso, la RPC para obtener la hora no es cacheable (y esto se especifica en la solicitud HTTP), por lo que una de las solicitudes se envía siempre al servidor HTTP 24.
Cuando el cliente HTTP 38 del terminal procesa el paquete STP de respuesta y encuentra la respuesta POST con RPC (se ubica después de las respuestas GET condicionales), solicita al módulo de configuración 36 que la procese. El módulo de configuración 36 procesa la respuesta y actualiza los ajustes de terminal 10.
A continuación se describirán con más detalle los aspectos de seguridad del sistema.
Las amenazas de seguridad a las que se puede enfrentar el sistema incluyen el uso de un terminal falso o de un host de puerta de enlace falso, la intercepción de datos transmitidos, la falsificación de certificados de seguridad, la conexión física a un dispositivo de hardware hostil para acceder a corrientes de información sensible, la conmutación de paquetes de datos en redes conmutadas o el robo de tarjetas inteligentes o terminales. A continuación se describe cómo se reduce a un nivel aceptable el riesgo potencial planteado por estas y otras amenazas.
A un nivel lógico, el mecanismo de seguridad del sistema se basa adecuadamente en una infraestructura de clave pública (PKI) y en u modelo de seguridad de preguntas de control ampliamente utilizado en sistemas financieros. La PKI supone que el servidor es autentificado ante el cliente utilizando un certificado digital firmado con el denominado certificado raíz. En el esquema de seguridad del sistema, el cliente es autentificado a su vez por el servidor respondiendo preguntas de control formuladas por el servidor. Solo un cliente válido puede responder correctamente a las preguntas. Un cliente falso no tiene conocimiento de los acuerdos previos entre un cliente real y el servidor, por lo que probablemente no dará las respuestas correctas.
Los datos procesados por las aplicaciones basadas en la PKI se cifran por medio de un par de claves asimétricas. Los certificados contienen claves públicas que son emitidas y terminadas por un servicio especial llamado Autoridad de Certificación.
La primera tarea a completar en la implementación de la arquitectura de seguridad es configurar el entorno de seguridad del terminal. Antes de la inicialización, el terminal no tiene contraseña del terminal ni certificados raíz. Estos deben cargarse durante la inicialización del terminal.
Hay dos modos posibles de inicialización del terminal: un modo de sobre cerrado con una clave secreta de inicialización impresa en su interior o un modo de tarjeta inteligente. Un terminal nuevo siempre va acompañado del sobre cerrado o de la tarjeta inteligente de inicialización.
El modo de inicialización de sobre cerrado se ilustra en la Fig. 11. El usuario introduce el ITID y la clave inicial (también denominada código PIN) obtenida del sobre. La terminal 10 abre entonces una sesión SSL con el host de puerta de enlace objetivo 19 especificado en la configuración de terminal y envía el ITID. Durante el intercambio SSL, el terminal 10 no valida el certificado del host de puerta de enlace 19. El host de puerta de enlace 19 recibe los datos, extrae el ITID y seguidamente busca en la base de datos de información del terminal (en particular en la tabla de terminales no inicializados) la copia de la clave de inicialización del terminal. El ITID se utiliza para realizar la búsqueda. Si no se encuentra ningún registro de terminal coincidente, el host de puerta de enlace 19 cierra la conexión. En caso contrario, el host de puerta de enlace emite una contraseña única aleatoria para el terminal solicitante.
La contraseña única y el certificado raíz se envían entonces al terminal 10. El terminal 10 almacena las credenciales recibidas en la memoria del terminal para el uso futuro. El terminal borra entonces los datos de seguridad introducidos previamente.
Cuando el host de puerta de enlace 19 recibe una confirmación del terminal 10, también elimina el registro de terminal desactualizado de la base de datos de información del terminal. El host de puerta de enlace 19 crea un nuevo registro de terminal y lo asocia con el mismo host de puerta de enlace 19 que el terminal solicitó para la inicialización. Un nuevo registro incluye el ITID, una flag 'in-service' para indicar que el terminal está activo y una contraseña única del terminal.
El modo de inicialización solo requiere que el operador del terminal introduzca la tarjeta inteligente en un terminal y deje a esta completar el proceso de inicialización automáticamente. La inicialización de la tarjeta inteligente puede ser automática o semiautomática. La inicialización automática requiere que la tarjeta inteligente almacene el certificado raíz junto con la contraseña única y el ITID. De este modo, el terminal se inicia instantáneamente en modo fuera de línea y no se requiere la conexión al host de puerta de enlace. La inicialización semiautomática supone que solo deben almacenarse en la tarjeta la clave de inicialización y el ITID. El terminal 10 se debe conectar al host de puerta de enlace 19 para recibir el certificado y la contraseña única.
La reinicialización del terminal solo se realiza en caso de robo del terminal o sus credenciales o en caso de avería del terminal. En ambos casos, el terminal debe reiniciarse con el mismo ITID pero con un código PIN diferente. Se debe proporcionar un nuevo sobre cerrado o una nueva tarjeta inteligente.
Tras la inicialización, el terminal 10 está preparado para aceptar pagos electrónicos. Para iniciar un pago, el micronavegador 12 llama a la biblioteca SSL del terminal para establecer un canal seguro para el puerto de intercambio de datos 62 del host de puerta de enlace 19.
Tras el intercambio, el terminal y el host de puerta de enlace 19 están conectados a través de un canal seguro y se supone que cualquier solicitud del terminal es segura. No obstante, para evitar la falsificación del terminal 10, el protocolo STP proporciona una comprobación adicional de autentificación del terminal. El host de puerta de enlace 19 busca en la base de datos de información del terminal para comprobar si la flag 'in-service’ está activada para el terminal 10 solicitante. Si no lo está, el terminal se bloquea y el host de puerta de enlace 19 termina la sesión y se desconecta. Si el terminal está en servicio, el host de puerta de enlace recupera la contraseña del terminal y ejecuta un código especial que ejecuta el algoritmo del cifrado ARCFour en bucle unas cuantas veces. Cada bucle del cifrado ARCFour consiste en un número definido de pasadas. El número exacto se elige de manera aleatoria, pero preferentemente no debe ser menor que 256. Los bytes resultantes representan las respuestas de control. El host de puerta de enlace solicita entonces al terminal 10 que ejecute exactamente el mismo procedimiento y devuelva los bytes resultantes. Si tanto el lado del servidor como también el del terminal han procesado las mismas contraseñas únicas, los bytes resultantes coinciden y el terminal se considera autentificado.
Desde este momento, el host de puerta de enlace 19 confía en el terminal 10 y comienza a procesar las solicitudes procedentes del mismo.
La validación de los certificados en la fase de intercambio es la tarea más importante durante la autentificación del terminal. El terminal 10 recupera el certificado del host de puerta de enlace 19 y lo comprueba mediante validación de la cadena CA.
En una realización del sistema, los certificados pueden generarse y firmarse con utilidades de línea de comandos gratuitas y disponibles públicamente. En caso necesario, los usuarios pueden firmar el certificado raíz con una autoridad de certificación conocida.
El cambio de un terminal a otro host de puerta de enlace (migración de terminal) también es fácil y seguro y no compromete la infraestructura de seguridad del sistema. Para conseguir esto solo se utiliza un único servidor de base de datos de información global de terminales.
La Fig. 12 ilustra un ejemplo de infraestructura de seguridad. La biblioteca interna de terminales 120 soporta una parte de cliente del protocolo SSL/TLS. Se supone que todos los servidores pueden desplegarse en cualquier lugar; el usuario posee un número arbitrario de terminales y los servidores del host de puerta de enlace 19 y los servidores 122 de la base de datos de información de terminales están conectados de manera arbitraria. En tal esquema, algunos de los repositorios de seguridad de toda la red pueden distribuirse en diferentes segmentos de red. Téngase en cuenta que la arquitectura de seguridad permite al host de puerta de enlace 19 y a los servidores 122 de la base de datos de información del terminal estén alojados en el mismo ordenador. Este esquema de despliegue es adecuado para usuarios que tienen un único nodo de host de puerta de enlace 19 y quieren minimizar el número de unidades de hardware requeridas en el lado del servidor. El efecto positivo de alojar dos servidores bajo un único techo consiste en que el esquema de despliegue tiene una conexión física menos. Téngase en cuenta también que el host de puerta de enlace 19 y los servidores 122 de la base de datos de información del terminal usan una GUI web para la administración remota de seguridad.
Además de las directrices de seguridad lógica, el sistema puede estar protegido físicamente, por ejemplo evitando el uso de hardware convencional de conmutación de paquetes para reducir el riesgo de rastreo de paquetes; asegurando los cables que conectan los servidores (es decir, utilizando líneas de fibra óptica específicas y bastidores de red bloqueados); bloqueando el acceso a la infraestructura de red a cualquier persona excepto a los administradores del sistema; e informando inmediatamente al administrador del sistema sobre cualquier comportamiento sospechoso del terminal o sobre el robo del terminal o de las claves de seguridad.
El experto en la materia reconocerá ahora que las realizaciones descritas anteriormente y sus modificaciones ofrecen muchas ventajas sobre los sistemas conocidos de transacciones financieras electrónicas.
Un comerciante u otro usuario de terminal requiere que sus sistemas de pago funcionen de manera fiable, segura, conveniente y eficiente. Para estos usuarios, la manera en la que el nuevo sistema procesa las transacciones puede ser similar a la de los sistemas de pago conocidos, siendo capaz de modificarse de manera que responda mejor a las necesidades del usuario.
Los usuarios de terminales dotados de derechos administrativos pueden estar autorizados a realizar acciones avanzadas con los terminales, por ejemplo obtener un acceso con contraseña a un menú de configuración. Esto aumenta la flexibilidad del sistema.
Un integrador de sistemas que posee una aplicación o varias aplicaciones TML y el hardware en el que se ejecuta el software del sistema es responsable de la instalación y la configuración de los terminales y del soporte del software de ayuda. Los integradores del sistema solo necesitan tener conocimientos prácticos de TML en lugar de dominar habilidades de programación complejas, tales como poder programar en C.
Un creador de aplicaciones TML puede ser contratado por la empresa integradora del sistema o por otra empresa externa (por ejemplo el fabricante del terminal). El sistema descrito anteriormente les proporciona una potente biblioteca de programación con una API conveniente. Estos pueden utilizar también el simulador de terminal para probar y depurar la aplicación del terminal.
Pueden realizarse diversas modificaciones y mejoras de las realizaciones descritas anteriormente sin desviarse del ámbito de la presente invención.

Claims (46)

REIVINDICACIONES
1. Un sistema de transacciones financieras electrónicas que comprende:
un terminal seguro (10) que incluye un lector de tarjetas para
leer la información de la tarjeta de transacción de un cliente, medios de entrada para recibir la entrada de un usuario relativa a las transacciones, una pantalla para mostrar información al usuario y medios de comunicación para comunicarse con un host remoto a través de una red de telecomunicaciones; y
un sistema host remoto (19) adaptado para comunicarse de forma segura con el terminal y con un sistema adquiriente para procesar transacciones electrónicas iniciadas por el terminal;
en el que el terminal incluye una aplicación de terminal (12) adaptada para descargar y procesar objetos de código del sistema host remoto, definiendo dichos objetos funciones a realizar por el terminal para el procesamiento de transacciones electrónicas por el terminal;
en el que dicha aplicación de terminal incluye un cliente HTTP capaz de enviar una solicitud HTTP condicional con una identificación de recursos cacheables al sistema host remoto; y
el host remoto incluye un host de puerta de enlace configurado para comprobar cada recurso cacheable contra registros
almacenado en una memoria caché, y devolver al terminal una actualización del recurso o la confirmación de que el recurso no ha cambiado,
estando caracterizado dicho sistema de transacciones electrónicas financieras por que, si el host de puerta de enlace no recibe respuesta de la memoria caché, el host de puerta de enlace envía una solicitud a un
servidor de configuración, y en el que el servidor de configuración es un servidor HTTP y procesa la solicitud recuperando el recurso requerido de una base de datos para cada recurso cacheable, y
devuelve el recurso al
sistema host remoto configurando el terminal de este modo.
2. El sistema de la reivindicación 1, en el que dichos objetos de código comprenden documentos expresados en un lenguaje de marcado de terminal (TML) que soporta variables.
3. El sistema de la reivindicación 2, en el que el TML soporta variables de serie, enteras, de fecha y opacas.
4. El sistema de la reivindicación 2 o 3, en el que dichos documentos TML comprenden documentos XML bien formados.
5. El sistema de alguna de las reivindicaciones 2 a 4, en el que la aplicación de terminal comprende una aplicación de micronavegador.
6. El sistema de alguna de las reivindicaciones 2 a 5, en el que la aplicación del terminal incluye además medios de navegación y medios de análisis de tarjetas adaptados
para interpretar datos leídos de una tarjeta de transacción.
7. El sistema de la reivindicación 6, en el que dicho host de puerta de enlace del sistema host remoto
que comunica
con el terminal, el host de puerta de enlace que comprende
medios de escucha TCP/IP, medios de procesamiento, medios de conversión y un proxy HTTP.
8. El sistema de la reivindicación 7, que incluye además una pila de protocolos utilizada para la comunicación entre el terminal y el host de puerta de enlace, comprendiendo dicha pila de protocolos una capa de protocolo de transmisión segura, una capa TCP/IP y una capa binaria HTTP binaria (BHTTP).
9. El sistema de la reivindicación 8, en el que la capa de protocolo de transmisión segura comprende SSL o TLS.
10. El sistema de cualquiera de las reivindicaciones 7 a 9, en el que el sistema host remoto incluye además un host de aplicación TML que se comunica con el host de puerta de enlace y con el sistema adquiriente y un host de servicios que se comunica con el host de puerta de enlace.
11. El sistema de la reivindicación 10, en el que el proxy HTTP del host de puerta de enlace está dispuesto para servir un primer medio del servidor HTTP del host de aplicación dispuesto para operar con una aplicación de pago y un segundo medio de servidor HTTP del host de servicios web dispuesto para operar con un servicio de configuración.
12. El sistema de la reivindicación 11, en el que las solicitudes del terminal para descargar documentos TML se transmiten desde el cliente HTTP del terminal al host de puerta de enlace como solicitudes HTTP binarias, convertidas a HTTP de texto por el host de puerta de enlace y transmitidas desde el proxy HTTP del host de puerta de enlace al primer o segundo servidor HTTP como solicitudes HTTP de
texto.
13. El sistema de la reivindicación 12, en el que las respuestas a las solicitudes del terminal para descargar documentos TML se transmiten desde el primer o segundo servidor HTTP al proxy HTTP del host de puerta de enlace como solicitudes HTTP de texto
convertidas a texto HTTP por el host de puerta de enlace y transmitidas desde el host de puerta de enlace al cliente HTTP del terminal como solicitudes HTTP
binarias.
14. El sistema de cualquiera de las reivindicaciones anteriores, en el que el terminal y el sistema host remoto son autentificables entre
sí.
15. El sistema de la reivindicación 14, en el que dicha autentificación utiliza una infraestructura de clave pública (PKI).
16. El sistema de la reivindicación 14 o 15, en el que el sistema host remoto se autentifica ante el terminal mediante un certificado digital firmado con un certificado raíz, y en el que el terminal es autentificado ante el sistema host remoto dando respuestas correctas a preguntas de control.
17. El sistema de la reivindicación 16, en el que el certificado digital es un certificado X.509.
18. El sistema de cualquier reivindicación precedente, en el que dichos objetos incluyen un objeto de código que define una pantalla de formulario adecuada para recibir los datos del usuario mediante el paso de una tarjeta magnética, la introducción de una tarjeta ICC, el uso de un teclado numérico o el uso de un teclado de terminal.
19. El sistema de cualquier reivindicación anterior, en el que dichos objetos de código incluyen objetos de código que soportan tipos de pantalla que incluyen una pantalla de visualización, una pantalla de impresión, una pantalla para mostrar mensajes de error o notificación y una pantalla para enviar llamadas a funciones.
20. El sistema de la reivindicación 1, en el que el servidor de configuración está adaptado para ser modificado por un proveedor de servicios utilizando una aplicación web, de modo que la configuración del terminal pueda actualizarse con los ajustes modificados.
21. El sistema de la reivindicación 20,
en el que la solicitud HTTP condicional incluye una llamada a procedimiento remoto (RPC).
22. El sistema de cualquiera de las reivindicaciones 20 a 21, en el que los parámetros configurables del terminal incluyen al menos uno de sincronización horaria, ajustes de terminal y parámetros para analizadores de tarjetas.
23. El sistema de cualquier reivindicación anterior, en el que la configuración del terminal se comprueba y puede configurarse cada vez que se conecta al sistema host remoto.
24. Un método de operación de una transacción financiera electrónica, implementándose dicho código por medio de un sistema de transacciones financieras electrónicas que comprende:
un terminal seguro (10) que incluye un lector de tarjetas para leer la información de la tarjeta de transacción de un cliente, medios de entrada para recibir los datos de un usuario relativa a las transacciones, una pantalla para mostrar información al usuario y medios de comunicación para comunicarse con un host remoto a través de una red de telecomunicaciones; y
un sistema host remoto (19) adaptado para comunicarse de forma segura con el terminal y con un sistema adquiriente para procesar transacciones electrónicas iniciadas por el terminal;
comprendiendo el método de operación de una transacción financiera electrónica
uso del terminal seguro para:
leer información de una tarjeta de transacción del cliente;
recibir datos del usuario relativos a transacciones; mostrar información al usuario; y comunicarse con el host remoto a través de una red de telecomunicaciones;
ejecutar una aplicación del terminal (12) en el terminal, estando adaptada dicha aplicación del terminal para descargar y procesar objetos de código del sistema host remoto, definiendo dichos objetos funciones a realizar por el terminal para el procesamiento de transacciones electrónicas por el terminal;
en el que:
el terminal envía una solicitud HTTP condicional con una identificación de recursos cacheables al sistema host remoto; y
el host remoto, para cada recurso cacheable, comprueba el recurso con los registros almacenados en una memoria caché, y devuelve al terminal una actualización del recurso o confirma que el recurso no ha cambiado, estando caracterizado el método de operación de una transacción financiera electrónica por que:
si el sistema host remoto no recibe respuesta de la memoria caché, el sistema host remoto envía una solicitud a un servidor de configuración, y en el que el servidor de configuración es un servidor HTTP y procesa la solicitud recuperando el recurso requerido de una base de datos para cada recurso cacheable y devuelve el recurso al sistema host remoto configurando el terminal de este modo.
25. El método de la reivindicación 24, en el que dichos objetos de código comprenden documentos expresados en un lenguaje de marcado de terminal (TML) que soporta variables.
26. El método de la reivindicación 25, en el que el TML soporta variables de serie, enteras, de fecha y opacas.
27. El método de la reivindicación 25 o la reivindicación 26, en el que dichos documentos TML comprenden documentos XML bien formados.
28. El método de alguna de las reivindicaciones 25 a 26, en el que la aplicación de terminal comprende una aplicación de micronavegador.
29. El método de alguna de las reivindicaciones 25 a 27, en el que dichas funciones a realizar por el terminal para el procesamiento de transacciones electrónicas por el terminal incluyen la interpretación de datos leídos de una tarjeta de transacción, realizándose dicha interpretación por medios de un cliente HTTP, medios de navegador y medios de análisis de tarjetas.
30. El método de la reivindicación 29, que comprende además el paso de disposición de un host de puerta de enlace que se comunica con el terminal, el host de puerta de enlace que comprende medios de escucha TCP/IP, medios de procesamiento, medios de conversión y un proxy HTTP.
31. El medio de la reivindicación 30, en el que la comunicación entre el terminal y el host de puerta de enlace utiliza una pila de protocolos, comprendiendo dicha pila de protocolos una capa de protocolo de transmisión segura, una capa TCP/IP y una capa binaria HTTP binaria (BHTTP).
32. El método de la reivindicación 31, en el que la capa de protocolo de transmisión segura comprende SSL o TLS.
33. El método de cualquiera de las reivindicaciones 30 a 32, que comprende además los pasos de disposición de un host de aplicación TML que se comunica con el host de puerta de enlace y con el sistema adquiriente y un host de servicios que se comunica con el host de puerta de enlace.
34. El método de la reivindicación 33, en el que el proxy HTTP del host de puerta de enlace está dispuesto para servir un primer medio del servidor HTTP del host de aplicación dispuesto para operar con una aplicación de pago y un segundo medio de servidor HTTP del host de servicios web dispuesto para operar con un servicio de configuración.
35. El método de la reivindicación 34, en el que el cliente HTTP del terminal transmite solicitudes para descargar documentos TML al host de puerta de enlace como solicitudes HTTP binarias; y
el host de puerta de enlace convierte las solicitudes a HTTP de texto y el proxy HTTP del host de puerta de enlace transmite las solicitudes del primer o segundo servidor HTTP como solicitudes HTTP de texto.
36. El método de la reivindicación 35, en el que el primer o segundo servidor HTTP terminal transmite respuestas a solicitudes del terminal para descargar documentos TML al proxy HTTP del host de puerta de enlace como solicitudes HTTP de texto;
el host de puerta de enlace convierte las respuestas a HTTP binario; y
el host de puerta de enlace transmite las respuestas al cliente HTTP del terminal como solicitudes HTTP binarias.
37. El método de cualquiera de las reivindicaciones 24 a 36, que comprende además el paso de autentificación del terminal y el host remoto entre sí.
38. El método de la reivindicación 37, en el que dicha autentificación utiliza una infraestructura de clave pública (PKI).
39. El método de la reivindicación 37 o la reivindicación 38, en el que el sistema host remoto se autentifica ante el terminal mediante un certificado digital firmado con un certificado raíz, y en el que el terminal es autentificado ante el sistema host remoto dando respuestas correctas a preguntas de control.
40. El método de la reivindicación 39, en el que el certificado digital es un certificado X.509.
41. El método de cualquiera de las reivindicaciones 24 a 40, en el que dichos objetos incluyen un objeto de código que define una pantalla de formulario que recibe los datos del usuario mediante cualquiera de: paso de una tarjeta magnética, introducción de una tarjeta ICC, uso de un teclado numérico o uso de un teclado de terminal.
42. El método de cualquiera de las reivindicaciones 24 a 41, en el que dichos objetos de código incluyen objetos de código que soportan tipos de pantalla que incluyen una pantalla de visualización, una pantalla de impresión, una pantalla para mostrar mensajes de error o notificación y una pantalla para enviar llamadas a funciones.
43. El método de cualquiera de las reivindicaciones 24 a 42, en el que la configuración del terminal se comprueba y se configura cada vez que se conecta al sistema host remoto.
44. El método de la reivindicación 24,
en el que la solicitud HTTP condicional incluye una llamada a procedimiento remoto (RPC).
45. El sistema de la reivindicación 1 o el método de la reivindicación 44, en el que los parámetros configurables del terminal incluyen al menos uno de sincronización horaria, ajustes de terminal y parámetros para analizadores de tarjetas.
46. El sistema de la reivindicación 1 o el método de cualquiera de las reivindicaciones 44 y 45, en el que la configuración del terminal se comprueba y puede configurarse cada vez que se conecta al sistema host remoto.
ES05769671T 2004-07-29 2005-07-29 Transacciones financieras electrónicas Active ES2955077T3 (es)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
GBGB0416857.1A GB0416857D0 (en) 2004-07-29 2004-07-29 Electronic financial transactions
PCT/GB2005/002994 WO2006010947A2 (en) 2004-07-29 2005-07-29 Electronic financial transactions

Publications (1)

Publication Number Publication Date
ES2955077T3 true ES2955077T3 (es) 2023-11-28

Family

ID=32947595

Family Applications (1)

Application Number Title Priority Date Filing Date
ES05769671T Active ES2955077T3 (es) 2004-07-29 2005-07-29 Transacciones financieras electrónicas

Country Status (6)

Country Link
US (1) US9785923B2 (es)
EP (1) EP1771801B1 (es)
JP (1) JP5122282B2 (es)
ES (1) ES2955077T3 (es)
GB (1) GB0416857D0 (es)
WO (1) WO2006010947A2 (es)

Families Citing this family (66)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8661477B2 (en) 1994-10-12 2014-02-25 Touchtunes Music Corporation System for distributing and selecting audio and video information and method implemented by said system
ES2143556T3 (es) 1994-10-12 2000-05-16 Touchtunes Music Corp Sistema de reproduccion audiovisual digital inteligente.
US7188352B2 (en) 1995-07-11 2007-03-06 Touchtunes Music Corporation Intelligent digital audiovisual playback system
FR2753868A1 (fr) 1996-09-25 1998-03-27 Technical Maintenance Corp Procede de selection d'un enregistrement sur un systeme numerique de reproduction audiovisuel et systeme pour mise en oeuvre du procede
FR2769165B1 (fr) 1997-09-26 2002-11-29 Technical Maintenance Corp Systeme sans fil a transmission numerique pour haut-parleurs
US7162636B2 (en) 1998-06-22 2007-01-09 Semtek Innovative Solutions, Inc. Method and apparatus for securing and authenticating encoded data and documents containing such data
FR2781591B1 (fr) 1998-07-22 2000-09-22 Technical Maintenance Corp Systeme de reproduction audiovisuelle
FR2781580B1 (fr) 1998-07-22 2000-09-22 Technical Maintenance Corp Circuit de commande de son pour systeme de reproduction audiovisuelle numerique intelligent
US8028318B2 (en) 1999-07-21 2011-09-27 Touchtunes Music Corporation Remote control unit for activating and deactivating means for payment and for displaying payment status
US8726330B2 (en) 1999-02-22 2014-05-13 Touchtunes Music Corporation Intelligent digital audiovisual playback system
FR2796482B1 (fr) 1999-07-16 2002-09-06 Touchtunes Music Corp Systeme de gestion a distance d'au moins un dispositif de reproduction d'informations audiovisuelles
FR2805377B1 (fr) 2000-02-23 2003-09-12 Touchtunes Music Corp Procede de commande anticipee d'une selection, systeme numerique et juke-box permettant la mise en oeuvre du procede
FR2805072B1 (fr) 2000-02-16 2002-04-05 Touchtunes Music Corp Procede d'ajustement du volume sonore d'un enregistrement sonore numerique
FR2805060B1 (fr) 2000-02-16 2005-04-08 Touchtunes Music Corp Procede de reception de fichiers lors d'un telechargement
FR2808906B1 (fr) 2000-05-10 2005-02-11 Touchtunes Music Corp Dispositif et procede de gestion a distance d'un reseau de systemes de reproduction d'informations audiovisuelles
FR2811175B1 (fr) 2000-06-29 2002-12-27 Touchtunes Music Corp Procede de distribution d'informations audiovisuelles et systeme de distribution d'informations audiovisuelles
FR2811114B1 (fr) 2000-06-29 2002-12-27 Touchtunes Music Corp Dispositif et procede de communication entre un systeme de reproduction d'informations audiovisuelles et d'une machine electronique de divertissement
FR2814085B1 (fr) 2000-09-15 2005-02-11 Touchtunes Music Corp Procede de divertissement base sur les jeux concours a choix multiples
US9646339B2 (en) 2002-09-16 2017-05-09 Touchtunes Music Corporation Digital downloading jukebox system with central and local music servers
US10373420B2 (en) 2002-09-16 2019-08-06 Touchtunes Music Corporation Digital downloading jukebox with enhanced communication features
US8332895B2 (en) 2002-09-16 2012-12-11 Touchtunes Music Corporation Digital downloading jukebox system with user-tailored music management, communications, and other tools
US7822687B2 (en) 2002-09-16 2010-10-26 Francois Brillon Jukebox with customizable avatar
US8584175B2 (en) 2002-09-16 2013-11-12 Touchtunes Music Corporation Digital downloading jukebox system with user-tailored music management, communications, and other tools
US11029823B2 (en) 2002-09-16 2021-06-08 Touchtunes Music Corporation Jukebox with customizable avatar
GB0419479D0 (en) * 2004-09-02 2004-10-06 Cryptomathic Ltd Data certification methods and apparatus
US7506812B2 (en) 2004-09-07 2009-03-24 Semtek Innovative Solutions Corporation Transparently securing data for transmission on financial networks
US7309012B2 (en) 2004-09-07 2007-12-18 Semtek Innovative Solutions, Inc. Secure magnetic stripe reader for handheld computing and method of using same
US9123042B2 (en) 2006-10-17 2015-09-01 Verifone, Inc. Pin block replacement
US9361617B2 (en) 2008-06-17 2016-06-07 Verifone, Inc. Variable-length cipher system and method
US8769275B2 (en) 2006-10-17 2014-07-01 Verifone, Inc. Batch settlement transactions system and method
US20080155016A1 (en) * 2006-12-22 2008-06-26 Tsai Wei K Content procurement architecture
US9171419B2 (en) 2007-01-17 2015-10-27 Touchtunes Music Corporation Coin operated entertainment system
US9330529B2 (en) 2007-01-17 2016-05-03 Touchtunes Music Corporation Game terminal configured for interaction with jukebox device systems including same, and/or associated methods
US8355982B2 (en) 2007-08-16 2013-01-15 Verifone, Inc. Metrics systems and methods for token transactions
US8332887B2 (en) 2008-01-10 2012-12-11 Touchtunes Music Corporation System and/or methods for distributing advertisements from a central advertisement network to a peripheral device via a local advertisement server
US20090328184A1 (en) * 2008-06-26 2009-12-31 Utstarcom, Inc. System and Method for Enhanced Security of IP Transactions
US8144940B2 (en) 2008-08-07 2012-03-27 Clay Von Mueller System and method for authentication of data
JP4879259B2 (ja) * 2008-12-19 2012-02-22 株式会社エヌ・ティ・ティ・ドコモ 端末装置及びアプリケーション一覧表示方法
US9292166B2 (en) 2009-03-18 2016-03-22 Touchtunes Music Corporation Digital jukebox device with improved karaoke-related user interfaces, and associated methods
WO2010107490A1 (en) 2009-03-18 2010-09-23 Touchtunes Music Corporation Entertainment server and associated social networking services
US8630907B2 (en) 2009-09-30 2014-01-14 Ebay Inc. Secure transactions using a point of sale device
US8706556B2 (en) * 2009-11-06 2014-04-22 Mastercard International Incorporated Methods for risk management in payment-enabled mobile device
CN105354940A (zh) 2010-01-26 2016-02-24 踏途音乐公司 具有改进的用户界面的数字点播设备和相关方法
US10147077B2 (en) * 2010-09-21 2018-12-04 Mastercard International Incorporated Financial transaction method and system having an update mechanism
US11514451B2 (en) 2011-03-15 2022-11-29 Capital One Services, Llc Systems and methods for performing financial transactions using active authentication
US10089612B2 (en) 2011-03-15 2018-10-02 Capital One Services, Llc Systems and methods for performing ATM fund transfer using active authentication
US9846902B2 (en) * 2011-07-19 2017-12-19 Slice Technologies, Inc. Augmented aggregation of emailed product order and shipping information
US8844010B2 (en) 2011-07-19 2014-09-23 Project Slice Aggregation of emailed product order and shipping information
US9563904B2 (en) 2014-10-21 2017-02-07 Slice Technologies, Inc. Extracting product purchase information from electronic messages
US9875486B2 (en) 2014-10-21 2018-01-23 Slice Technologies, Inc. Extracting product purchase information from electronic messages
CA2849069C (en) 2011-09-18 2017-08-22 Touchtunes Music Corporation Digital jukebox device with karaoke and/or photo booth features, and associated methods
US11151224B2 (en) 2012-01-09 2021-10-19 Touchtunes Music Corporation Systems and/or methods for monitoring audio inputs to jukebox devices
US9842335B2 (en) 2012-03-23 2017-12-12 The Toronto-Dominion Bank System and method for authenticating a payment terminal
US9152957B2 (en) 2012-03-23 2015-10-06 The Toronto-Dominion Bank System and method for downloading an electronic product to a pin-pad terminal after validating an electronic shopping basket entry
US9760939B2 (en) 2012-03-23 2017-09-12 The Toronto-Dominion Bank System and method for downloading an electronic product to a pin-pad terminal using a directly-transmitted electronic shopping basket entry
WO2015004528A2 (en) * 2013-07-08 2015-01-15 Assa Abloy Ab One-time-password generated on reader device using key read from personal security device
CA2925265C (en) * 2013-09-24 2019-03-05 Jcm American Corporation Electronic voucher ticket system
US10235839B2 (en) * 2013-09-24 2019-03-19 Jcm American Corporation Electronic voucher ticket system
US9964994B2 (en) * 2013-10-31 2018-05-08 Ncr Corporation Mobile device conduit for a transaction device
CN106489125B (zh) 2014-03-25 2021-12-21 踏途音乐公司 具有改进的用户界面的数字点播设备和相关方法
JP6327001B2 (ja) * 2014-06-19 2018-05-23 富士ゼロックス株式会社 画像処理装置及びプログラム
US20160019582A1 (en) * 2014-07-16 2016-01-21 Zeta Interactive Corp. Predictive modeling of attribution
US10970967B2 (en) 2014-09-24 2021-04-06 Jcm American Corporation Electronic voucher ticket system
US9928697B2 (en) 2015-03-31 2018-03-27 Toshiba Global Commerce Solutions Holdings Corporation Configuring point-of-sale (POS) applications based on a priority level in order to communicate with peripheral devices in a POS system
US10447635B2 (en) 2017-05-17 2019-10-15 Slice Technologies, Inc. Filtering electronic messages
US11803883B2 (en) 2018-01-29 2023-10-31 Nielsen Consumer Llc Quality assurance for labeled training data

Family Cites Families (34)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
MX174467B (es) * 1986-01-23 1994-05-17 Squibb & Sons Inc 1,4,7-triscarboximetil-1,4,7,10-tetraazaciclodo decano substituido en 1 y compuestos analogos
US5475756A (en) * 1994-02-17 1995-12-12 At&T Corp. Method of authenticating a terminal in a transaction execution system
US5696909A (en) * 1995-01-27 1997-12-09 Hypercom, Inc. Virtual POS terminal
US5742845A (en) * 1995-06-22 1998-04-21 Datascape, Inc. System for extending present open network communication protocols to communicate with non-standard I/O devices directly coupled to an open network
TW400487B (en) * 1996-10-24 2000-08-01 Tumbleweed Software Corp Electronic document delivery system
US6289320B1 (en) * 1998-07-07 2001-09-11 Diebold, Incorporated Automated banking machine apparatus and system
US6705517B1 (en) * 1996-11-27 2004-03-16 Die Old, Incorporated Automated banking machine system and method
US20030217005A1 (en) * 1996-11-27 2003-11-20 Diebold Self Service Systems, Division Of Diebold, Incorporated Automated banking machine system and method
US6052730A (en) * 1997-01-10 2000-04-18 The Board Of Trustees Of The Leland Stanford Junior University Method for monitoring and/or modifying web browsing sessions
US5948066A (en) * 1997-03-13 1999-09-07 Motorola, Inc. System and method for delivery of information over narrow-band communications links
JP3514626B2 (ja) * 1998-04-14 2004-03-31 インクリメント・ピー株式会社 ルート情報提供システム及びそれに用いるｗｗｗサーバ、並びに、ルート情報提供方法及びそれに用いるｗｗｗサーバ
US20030141360A1 (en) * 1999-04-22 2003-07-31 De Leo Stephen L. System and method for providing information and services to and from an automated teller machine
US6721713B1 (en) * 1999-05-27 2004-04-13 Andersen Consulting Llp Business alliance identification in a web architecture framework
AR029173A1 (es) * 1999-07-20 2003-06-18 Diebold Inc Metodo para el desarrollo de cajeros automaticos
CN1385038A (zh) * 1999-09-02 2002-12-11 诺基亚移动电话有限公司 一种用于从服务器存取位置信息的无线通信终端
US20010051876A1 (en) * 2000-04-03 2001-12-13 Seigel Ronald E. System and method for personalizing, customizing and distributing geographically distinctive products and travel information over the internet
US20030041110A1 (en) * 2000-07-28 2003-02-27 Storymail, Inc. System, Method and Structure for generating and using a compressed digital certificate
JP2002074517A (ja) * 2000-08-25 2002-03-15 Trinity Communication Inc Ｐｏｓ端末装置、ｐｏｓシステム用ストアコンピュータ、ｐｏｓシステム用ルータ、ｐｏｓシステム用ホストコンピュータ、ｐｏｓシステム、データ防護処理方法およびその方法をコンピュータに実行させるプログラムを記録したコンピュータ読み取り可能な記録媒体
US6901381B2 (en) * 2001-01-26 2005-05-31 National Railroad Passenger Corporation Method for rolling salable inventory control and system therefor
JP2002251674A (ja) * 2001-02-23 2002-09-06 Sharp Corp Ｐｏｓ端末およびｐｏｓデバイスの制御方法
JP2002279531A (ja) * 2001-03-19 2002-09-27 Toshiba Tec Corp 商品販売データ処理装置、商品販売データ処理方法およびコンピュータプログラム
US7603703B2 (en) * 2001-04-12 2009-10-13 International Business Machines Corporation Method and system for controlled distribution of application code and content data within a computer network
EP1396805A4 (en) * 2001-06-11 2006-11-08 Sony Corp ELECTRONIC MONEY SYSTEM
US20030105977A1 (en) * 2001-12-05 2003-06-05 International Business Machines Corporation Offload processing for secure data transfer
US7231657B2 (en) * 2002-02-14 2007-06-12 American Management Systems, Inc. User authentication system and methods thereof
US20030161265A1 (en) * 2002-02-25 2003-08-28 Jingjun Cao System for end user monitoring of network service conditions across heterogeneous networks
US7707120B2 (en) * 2002-04-17 2010-04-27 Visa International Service Association Mobile account authentication service
US7685287B2 (en) * 2002-05-30 2010-03-23 Microsoft Corporation Method and system for layering an infinite request/reply data stream on finite, unidirectional, time-limited transports
ATE385589T1 (de) * 2002-08-02 2008-02-15 Sap Ag Verfahren und rechnersystem zur behandlung von inkrementalen daten in klient-server kommunikation.
GB2410660B (en) * 2002-10-14 2005-10-19 Toshiba Res Europ Ltd Methods and systems for flexible delegation
GB2412882A (en) * 2002-12-23 2005-10-12 Gametech International Inc Enhanced gaming system
WO2004081756A2 (en) * 2003-03-12 2004-09-23 Nationwide Mutual Insurance Co Trust governance framework
US20040186760A1 (en) * 2003-03-17 2004-09-23 Metzger Tracy Alan System and method for sales and inventory reconciliation
US7394761B2 (en) * 2003-04-29 2008-07-01 Avocent Huntsville Corporation System and method for delivering messages using alternate modes of communication

Also Published As

Publication number Publication date
JP5122282B2 (ja) 2013-01-16
WO2006010947A2 (en) 2006-02-02
US9785923B2 (en) 2017-10-10
EP1771801B1 (en) 2023-07-05
EP1771801A2 (en) 2007-04-11
US20090204545A1 (en) 2009-08-13
GB0416857D0 (en) 2004-09-01
WO2006010947A8 (en) 2007-01-25
WO2006010947A3 (en) 2006-06-22
JP2008508585A (ja) 2008-03-21

Similar Documents

Publication Publication Date Title
ES2955077T3 (es) Transacciones financieras electrónicas
JP6648110B2 (ja) クライアントをデバイスに対して認証するシステム及び方法
US7296160B2 (en) Secure user authentication over a communication network
US7296149B2 (en) Secure user and data authentication over a communication network
RU2252451C2 (ru) Способ проведения трансакций, компьютеризованный способ защиты сетевого сервера, трансакционная система, сервер электронного бумажника, компьютеризованный способ выполнения онлайновых покупок (варианты) и компьютеризованный способ контроля доступа
Elkhodr et al. A proposal to improve the security of mobile banking applications
KR102277060B1 (ko) 암호화 시스템 및 방법
BR112014004374B1 (pt) Método para participação com base em aplicação segura em um processo de autorização de transação de cartão de pagamento por um dispositivo móvel, sistema para participação com base em aplicação segura por um dispositivo móvel em interrogações de ponto de venda
TR201810238T4 (tr) Bir mobil kimlik doğrulama uygulaması kullanarak kullanıcıya uygun kimlik doğrulama yöntemi ve aparatı.
WO2012123727A1 (en) Personal identity control
JP2009117887A (ja) 電子認証装置、電子認証システム、電子認証方法およびこの方法のプログラム
BRPI0919158B1 (pt) Dispositivo de autorização, aparelho para controle de operações de um servidor, servidor para realização de operações e sistema de comunicação de dados
EP3949334A1 (en) System and method for efficient challenge-response authentication
CN108496323A (zh) 一种证书导入方法及终端
KR20090000740A (ko) 증명서 발급 방법 및 시스템과 이를 위한 기록매체
Hamann et al. Securing e-business applications using smart cards
Hutchinson et al. Report
CN115001701B (zh) 用于授权认证的方法及装置、存储介质及电子设备
KR100963917B1 (ko) 그래픽 사용자 인터페이스를 이용한 계좌이체 처리시스템과 이를 위한 프로그램 기록매체
JP7470313B2 (ja) オンラインサービス提供システム
US20210194919A1 (en) System and method for protection against malicious program code injection
Trommler A Formally Verified Digital Signature Device for Smartphones
JP2002342277A (ja) サービス連携システムおよび連携サーバおよびセキュアトークンおよびプログラムおよび記録媒体
KR20070092391A (ko) 닉네임을 이용한 비대면 채널 유저인터페이스 제공방법 및시스템과 이를 위한 프로그램 기록매체
Gunasinghe CLOUD BASED SECURE ELEMENT IMPLEMENTATION FOR ANDROID HOST CARD EMULATION