ES2313770T3 - Maquina bancaria automatica con acceso a datos basandose en entradas de cliente que incluyen la identificacion biometrica del cliente y la produccion de visualizaciones seleccionadas basandose en la identidad del cliente (bean de perfil). - Google Patents

Maquina bancaria automatica con acceso a datos basandose en entradas de cliente que incluyen la identificacion biometrica del cliente y la produccion de visualizaciones seleccionadas basandose en la identidad del cliente (bean de perfil). Download PDF

Info

Publication number
ES2313770T3
ES2313770T3 ES99303413T ES99303413T ES2313770T3 ES 2313770 T3 ES2313770 T3 ES 2313770T3 ES 99303413 T ES99303413 T ES 99303413T ES 99303413 T ES99303413 T ES 99303413T ES 2313770 T3 ES2313770 T3 ES 2313770T3
Authority
ES
Spain
Prior art keywords
machine
data
server
transaction
user
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Expired - Lifetime
Application number
ES99303413T
Other languages
English (en)
Inventor
Jay Paul Drummond
Dale Blackson
Bob A. Cichon
Mark S. Covert
Mark A. Moales
Mark D. Smith
Joseph C. Ess
David W. Weis
James Church
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.)
Diebold Nixdorf Inc
Original Assignee
Diebold Inc
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
Priority claimed from US09/193,623 external-priority patent/US6598023B1/en
Application filed by Diebold Inc filed Critical Diebold Inc
Application granted granted Critical
Publication of ES2313770T3 publication Critical patent/ES2313770T3/es
Anticipated expiration legal-status Critical
Expired - Lifetime legal-status Critical Current

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/34—Network arrangements or protocols for supporting network services or applications involving the movement of software or configuration parameters 
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
    • G06F3/01—Input arrangements or combined input and output arrangements for interaction between user and computer
    • G06F3/048—Interaction techniques based on graphical user interfaces [GUI]
    • G06F3/0487—Interaction techniques based on graphical user interfaces [GUI] using specific features provided by the input device, e.g. functions controlled by the rotation of a mouse with dual sensing arrangements, or of the nature of the input device, e.g. tap gestures based on pressure sensed by a digitiser
    • G06F3/0489—Interaction techniques based on graphical user interfaces [GUI] using specific features provided by the input device, e.g. functions controlled by the rotation of a mouse with dual sensing arrangements, or of the nature of the input device, e.g. tap gestures based on pressure sensed by a digitiser using dedicated keyboard keys or combinations thereof
    • G06F3/04895—Guidance during keyboard input operation, e.g. prompting
    • 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
    • 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/04—Payment circuits
    • G06Q20/042—Payment circuits characterized in that the payment protocol involves at least one cheque
    • 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/18—Payment architectures involving self-service terminals [SST], vending machines, kiosks or multimedia terminals
    • G—PHYSICS
    • G07—CHECKING-DEVICES
    • G07F—COIN-FREED OR LIKE APPARATUS
    • G07F19/00—Complete banking systems; Coded card-freed arrangements adapted for dispensing or receiving monies or the like and posting such transactions to existing accounts, e.g. automatic teller machines
    • G07F19/20—Automatic teller machines [ATMs]
    • G—PHYSICS
    • G07—CHECKING-DEVICES
    • G07F—COIN-FREED OR LIKE APPARATUS
    • G07F19/00—Complete banking systems; Coded card-freed arrangements adapted for dispensing or receiving monies or the like and posting such transactions to existing accounts, e.g. automatic teller machines
    • G07F19/20—Automatic teller machines [ATMs]
    • G07F19/201—Accessories of ATMs
    • G—PHYSICS
    • G07—CHECKING-DEVICES
    • G07F—COIN-FREED OR LIKE APPARATUS
    • G07F19/00—Complete banking systems; Coded card-freed arrangements adapted for dispensing or receiving monies or the like and posting such transactions to existing accounts, e.g. automatic teller machines
    • G07F19/20—Automatic teller machines [ATMs]
    • G07F19/206—Software aspects at ATMs
    • G—PHYSICS
    • G07—CHECKING-DEVICES
    • G07F—COIN-FREED OR LIKE APPARATUS
    • G07F19/00—Complete banking systems; Coded card-freed arrangements adapted for dispensing or receiving monies or the like and posting such transactions to existing accounts, e.g. automatic teller machines
    • G07F19/20—Automatic teller machines [ATMs]
    • G07F19/211—Software architecture within ATMs or in relation to the ATM network
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/0861—Network architectures or network communication protocols for network security for authentication of entities using biometrical features, e.g. fingerprint, retina-scan
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/12—Applying verification of the received information
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/02—Protocols based on web technology, e.g. hypertext transfer protocol [HTTP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/12—Protocols specially adapted for proprietary or special-purpose networking environments, e.g. medical networks, sensor networks, networks in vehicles or remote metering networks
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/56—Provisioning of proxy services
    • H04L67/563—Data redirection of data network streams
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/30—Definitions, standards or architectural aspects of layered protocol stacks
    • H04L69/32—Architecture of open systems interconnection [OSI] 7-layer type protocol stacks, e.g. the interfaces between the data link level and the physical level
    • H04L69/322—Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions
    • H04L69/329—Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions in the application layer [OSI layer 7]

Abstract

MAQUINA BANCARIA AUTOMATIZADA (12) OPERATIVA PARA LLEVAR A CABO TRANSACCIONES EN RESPUESTA A DOCUMENTOS HTML Y MENSAJES TCP/IP INTERCAMBIADOS CON UN SISTEMA INFORMATICO LOCAL (14) A TRAVES DE UNA INTRANET (16), ASI COMO EN RESPUESTA A LOS MENSAJES INTERCAMBIADOS CON SERVIDORES EXTERNOS (20,22,24,26,28) EN UNA RED DE AREA AMPLIA (18). LA MAQUINA INCLUYE UN ORDENADOR QUE TIENE UNA PARTE PARA MANEJAR DOCUMENTOS. ESTA PARTE SE COMUNICA A TRAVES DE UN SERVIDOR PROXY CON UN SERVIDOR HTTP DE INICIO EN LA INTRANET O EN LOS SERVIDORES EXTERNOS EN LA RED DE AREA AMPLIA. EL ORDENADOR ADEMAS INCLUYE UNA PARTE DE APLICACIONES DE DISPOSITIVOS QUE CONECTA CON LA PARTE PARA MANEJAR DOCUMENTOS HTML Y ENVIA MENSAJES PARA HACER FUNCIONAR LOS DISPOSITIVOS EN LA MAQUINA BANCARIA AUTOMATIZADA. LOS DISPOSITIVOS INCLUYEN UN MECANISMO DISPENSADOR DE HOJAS QUE DISPENSA BILLETES, ASI COMO OTROS DISPOSITIVOS DE TRANSACCIONES. LA PARTE DE APLICACIONES DE DISPOSITIVOS SE COMUNICA CON LA PARTE DE SOFTWARE DE INTERFAZ DEDISPOSITIVOS EN LA MAQUINA BANCARIA A TRAVES DE UN SERVIDOR DEL DISPOSITIVO EN LA INTRANET. EL SERVIDOR DEL DISPOSITIVO MANTIENE EL CONTROL LOCAL SOBRE LOS DISPOSITIVOS DE LA MAQUINA BANCARIA, INCLUIDO EL DISPENSADOR DE BILLETES. LA MAQUINA BANCARIA SE PONE EN MARCHA PARA LEER SIGNOS EN LA TARJETA DEL USUARIO QUE CORRESPONDEN A UNA DIRECCION DEL SISTEMA. EL ORDENADOR FUNCIONA PARA CONECTAR LA MAQUINA BANCARIA AL SERVIDOR DE INICIO O EXTERNO CORRESPONDIENTE A LA DIRECCION DEL SISTEMA Y ESTE SERVIDOR CONECTADO HACE FUNCIONAR LA MAQUINA BANCARIA HASTA QUE EL USUARIO TERMINE LAS TRANSACCIONES.

Description

Máquina bancaria automática con acceso a datos basándose en entradas de cliente que incluyen la identificación biométrica del cliente y la producción de visualizaciones seleccionadas basándose en la identidad del cliente (bean de perfil).
La presente invención se refiere a máquinas bancarias automáticas.
Las máquinas bancarias automáticas son bien conocidas. Un tipo común de máquinas bancarias automáticas utilizado por clientes es una máquina de cajero automático ("ATM", automated teller machine). Las ATM permiten a los clientes llevar a cabo transacciones bancarias. Transacciones bancarias comunes que pueden llevarse a cabo con las ATM incluyen la dispensación de efectivo, la forma de realización de ingresos, la transferencia de fondos entre cuentas, el pago de facturas y consultas de saldo de cuenta. El tipo de transacciones bancarias que un cliente puede llevar a cabo se determina mediante capacidades de la máquina bancaria particular y la programación del organismo que opera la máquina. Otros tipos de máquinas bancarias automáticas pueden permitir a los clientes hacer cargos a cuentas o transferir fondos. Otros tipos de máquinas bancarias automáticas pueden imprimir o distribuir artículos de valor tal como cupones, entradas, billetes de apuestas, justificantes, cheques, vales de comida, giros postales, vales o cheques de viaje. Para fines de esta descripción, una máquina bancaria automática o máquina de transacción automatizada abarcará cualquier dispositivo, que lleve a cabo transacciones incluyendo transferencias de valor.
Actualmente, las ATM se operan en redes de comunicaciones propietarias. Estas redes interconectan las ATM operadas por organismos financieros y otras entidades. La interconexión de las redes a menudo permite a un usuario utilizar una máquina bancaria operada por otro organismo si la máquina bancaria del organismo externo está interconectada con la red que incluye el organismo del usuario. Sin embargo, cuando el cliente opera la máquina del organismo externo el cliente debe operar la máquina utilizando la interfaz de cliente que se ha establecido por el organismo externo para sus máquinas bancarias. Adicionalmente el usuario está limitado a las opciones de transacción proporcionadas por el organismo externo.
Un cliente puede encontrar dificultades cuando utiliza la máquina de un organismo externo. Pueden producirse problemas porque el usuario no esté familiarizado con el tipo de máquina operada por el organismo externo. Puede darse confusión porque el cliente no conozca qué botones u otros mecanismos accionar para llevar a cabo las transacciones deseadas. El flujo de transacción para un cliente en una máquina de organismo externo puede ser significativamente diferente de las máquinas operadas por el organismo de origen del usuario. Esto puede ser un problema particularmente cuando el usuario es de otro país y no está familiarizado con el tipo de máquina bancaria o el idioma de la interfaz proporcionada por el organismo externo. Asimismo, los documentos que se imprimen por impresoras en una máquina bancaria automática se limitan generalmente a un grupo limitado de formatos definidos en un único idioma.
Un organismo externo puede proporcionar también diferentes tipos de transacciones a aquellas con las que el usuario está familiarizado en su organismo de origen. Por ejemplo el organismo de origen del usuario puede permitir la transferencia de fondos entre cuentas a través de sus máquinas bancarias automáticas, para permitir al usuario mantener fondos cuentas que rinden intereses mayores hasta que no se necesiten. Si el organismo externo no proporciona esta capacidad, el usuario no podrá hacer esto cuando esté funcionando la máquina externa. La incapacidad de un usuario en una máquina externa para realizar las transacciones a las que está acostumbrado puede presentar problemas.
Las redes que hacen funcionar máquinas bancarias automáticas y otros tipos de máquinas bancarias automáticas generalmente funcionan redes propietarias a las cuales el acceso está restringido. Esto es necesario para impedir el fraude o alteración con la red o las cuentas del usuario. Las redes propietarias también se utilizan generalmente para la transmisión de mensajes de tarjeta de crédito y otros mensajes de transacción financieros. El acceso a tales sistemas de procesamiento de tarjeta de crédito también se restringe principalmente para fines de mantenimiento de la seguridad.
La comunicación sobre redes de área amplia permite que se comuniquen mensajes comunicarse entre ubicaciones distantes. La red de área amplia mejor conocida es Internet, que puede utilizarse para proporcionar comunicación entre ordenadores por todo el mundo. Internet no se utiliza mucho para mensajes de transacción financieros porque no es un sistema seguro. Los mensajes previstos para su recepción en una dirección de ordenador particular pueden interceptarse en otras direcciones sin detección. Puesto que los mensajes pueden interceptarse en ubicaciones que distan en el mundo del destinatario previsto, son posibles el fraude y la corrupción.
Las empresas están empezando a proporcionar enfoques para una transmisión de mensajes en Internet más segura. Se están aplicando también técnicas de encriptación a mensajes de Internet. Sin embargo la transparencia de Internet ha limitado su utilidad para fines de mensajes financieros, particularmente mensajes financieros asociados con el funcionamiento de máquinas bancarias automáticas.
Los mensajes en redes de área amplia pueden comunicarse utilizando el protocolo de control de transmisión/pro-
tocolo de Internet ("TCP/IP", Transmission Control Protocol/Internet Protocol). La patente estadounidense número 5.706.422 muestra un ejemplo de un sistema en el que se accede a información financiera almacenada en bases de datos a través de una red de área amplia privada utilizando mensajes TCP/IP. Los mensajes transmitidos en tales redes que utilizan TCP/IP pueden incluir "documentos" (también llamados "páginas"). Tales documentos se producen en lenguaje de marcado de hipertexto ("HTML", Hipertext Markup Language) que es una referencia a un tipo de lenguaje de programación utilizado para producir documentos con órdenes o `etiquetas' en el mismo. Las etiquetas son códigos que definen características y/u operaciones del documento tales como fuentes, distribución, gráficos embebidos y enlaces de hipertexto. Los documentos HTML se procesan o leen mediante la utilización de un programa informático denominado como un "navegador". Las etiquetas le dicen al navegador cómo procesar y controlar lo que se ve en una pantalla y/o se oye en unos altavoces conectados al ordenador que ejecuta el navegador cuando se procesa el documento. Los documentos HTML pueden transmitirse sobre una red a través del protocolo de transferencia de hipertexto ("HTTP", Hypertext Transfer Protocol). El término "hipertexto" es una referencia a la capacidad para embeber enlaces dentro del texto de un documento que permite la comunicación con otros documentos a los que puede accederse en la red.
El documento WO98/19278 describe un procedimiento de fin de sistema de entrega que permite a un organismo financiero proporcionar servicios financieros a una pluralidad de dispositivos remotos, tal como ordenadores personales (PC, Personal Computer), asistentes de datos personales (PDA, Personal Data Assistant), y teléfonos con pantalla. Adicionalmente a proporcionar servicios a estos dispositivos remotos, el sistema y procedimiento proporcionan servicios a máquinas expendedoras de billetes (ATM), proveedores de servicios externos, e internamente dentro del organismo financiero a terminales de personal y a las sucursales individuales del organismo financiero.
Por lo tanto, existe una necesidad de una máquina bancaria automática y sistema bancario automatizado que pueden utilizarse en una red de área amplia tal como Internet mientras proporcionan un alto nivel de seguridad.
Aspectos de la invención se definen en las reivindicaciones adjuntas.
Las formas de realización de la invención pueden proporcionar:
una máquina bancaria automática y sistema bancario automatizado que proporcionan a un usuario la interfaz y opciones de transacción familiares de su organismo de origen cuando opera máquinas de organismos externos;
una máquina bancaria automática que puede proporcionar más opciones de transacción y tipos de materiales promocionales e impresos a los usuarios;
una máquina bancaria automática en la que un usuario puede realizar transacciones;
una máquina bancaria automática que puede operarse a través de conexión a una red de área amplia;
una máquina bancaria automática que proporciona más opciones para salidas de máquina;
una máquina bancaria automática que se comunica utilizando documentos HTML y mensajes TCP/IP;
una máquina bancaria automática que permite la conexión de la máquina bancaria a un organismo de origen del usuario a través de mensajes TCP/IP y documentos y IITMI generados en respuesta a marcas en una tarjeta introducida por un usuario;
una máquina bancaria automática y sistema bancario automatizado que llevan a cabo transacciones sobre una red de área amplia mientras mantiene un alto nivel de seguridad;
una máquina bancaria automática y sistema bancario automatizado que controlan la conexión de la máquina bancaria a direcciones externas a través de un servidor proxy;
una máquina bancaria automática que limita la operación de dispositivos en la máquina a través de un servidor de dispositivo local;
una máquina bancaria automática y sistema bancario automatizado que se operan a través de conexión a Internet;
una máquina bancaria automática que puede utilizarse para proporcionar a un usuario más tipos de mensajes incluyendo mensajes destinados a usuarios particulares;
una máquina bancaria automática que puede proporcionar a usuarios una amplia variedad de documentos impresos;
una máquina bancaria automática que proporciona opciones adicionales para identificar a usuarios autorizados;
una máquina bancaria automática que puede utilizarse en conexión con sistemas de transacción existentes mientras proporciona funcionalidad mejorada;
una máquina bancaria automática que proporciona capacidades de servicio y diagnóstico mejoradas;
una máquina bancaria automática que realiza transacciones a un ritmo rápido;
sistemas mejorados en los que se utilizan máquinas bancarias automáticas; y/o
procedimientos de funcionamiento mejorados para máquinas bancarias automáticas y sistemas bancarios automatizados.
\vskip1.000000\baselineskip
Según una forma de realización de la invención se proporciona una máquina bancaria automática que incluye un dispositivo de salida tal como una pantalla de visualización, y un dispositivo de entrada tal como una pantalla táctil o un teclado. La máquina bancaria incluye además dispositivos tales como un mecanismo expendedor para billetes bancarios, un mecanismo de impresión, un medio de lectura/escritura de tarjetas, un mecanismo de depósito y otros dispositivos de función de transacción física que se utilizan por la máquina para llevar a cabo transacciones bancarias.
La máquina bancaria incluye además un ordenador. El ordenador está en conexión funcional con los dispositivos de salida y los dispositivos de entrada, así como con el mecanismo expendedor de billetes, lector de tarjetas y otros dispositivos de función de transacción física en la máquina bancaria. El ordenador incluye programas de software que son ejecutables en el mismo. Los programas de software incluyen una parte de manipulación de documento HTML. La parte de manipulación de documento HTML opera para enviar y recibir documentos HTML y mensajes HTTP. La parte de manipulación de documento HTML está preferentemente en conexión con el dispositivo de salida para visualizar pantallas que incluyen indicadores de enlace de hipertexto. La parte de manipulación de documento HTML está también preferentemente en conexión con el dispositivo de entrada que permite la sección por parte del usuario y la generación de mensajes de respuesta desde el ordenador. La parte de manipulación de documento HTML opera preferentemente en conexión con un entorno de software JAVA y presenta la capacidad de ejecutar instrucciones en JAVAScript transmitidas con documentos HTML.
El software en el ordenador incluye además preferentemente una parte de aplicación de dispositivo. La parte de aplicación de dispositivo incluye software que se encuentra operativo para controlar el expendedor de billetes y otros dispositivos. En una forma de realización de la invención la parte de aplicación de dispositivo incluye una pluralidad de applets de Java para operar los dispositivos en la máquina.
El ordenador en la máquina bancaria automática incluye además un parte software de interconexión de dispositivos. La parte software de interconexión de dispositivos opera para recibir mensajes desde la parte de aplicación de dispositivo y para hacer que los dispositivos operen a través de interfaces hardware apropiadas. En una forma preferida de la máquina bancaria automática, la parte de manipulación de documento HTML, la parte de aplicación de dispositivo y la parte software de interconexión de dispositivos residen cada una en el mismo ordenador y se comunican por puertos IP diferentes.
La máquina bancaria automática en una configuración se comunica utilizando mensajes TCP/IP en una intranet que incluye una pluralidad de tales máquinas. La intranet está a su vez conectada a por lo menos un ordenador que se opera por un organismo de origen. El organismo de origen es la entidad que opera las máquinas bancarias.
El ordenador del organismo de origen incluye preferentemente un servidor HTTP de origen, un servidor proxy y un servidor de dispositivo. El servidor proxy se comunica a través de la intranet con la parte de manipulación de documento HTML del software en cada una de las máquinas bancarias. El servidor proxy también puede conectarse a una red de área amplia, tal como Internet, a la que se conectan servidores externos. El servidor de dispositivo se encuentra operativo para pasar mensajes entre la parte de aplicación de dispositivo y la parte software de interconexión de dispositivos de las máquinas bancarias. El servidor de dispositivo puede incluir software de monitorización que monitoriza y limita selectivamente la utilización y operación de los dispositivos en la máquina bancaria. Esto proporciona un nivel de seguridad.
La máquina bancaria automática y sistema bancario automatizado se encuentran operativos para poner a un usuario en conexión con el organismo en la que tiene sus cuentas. Este puede ser o bien el organismo de origen que opera la máquina bancaria en la que el usuario está presente, o un organismo externo que está conectado a la red de área amplia. Para operar la máquina bancaria un usuario proporciona entradas que corresponden a una dirección, tal como una dirección URL, a través de un dispositivo de entrada de dirección. La parte de manipulación de documento HTML opera para conectar la máquina bancaria al servidor correspondiente a esa dirección. Esto se lleva a cabo preferentemente por el usuario que tiene marcas representativas de la dirección en una tarjeta que se lee por un lector de tarjetas en la máquina bancaria, u otro dispositivo de entrada que identifica al usuario o a un organismo o entidad con el que el usuario tiene cuentas.
La parte de manipulación de documento HTML es sensible a la dirección en la tarjeta u otros datos de entrada para conectarse a través del servidor proxy al organismo del usuario. Si la dirección del organismo de origen del usuario corresponde al servidor de origen, la máquina bancaria opera en respuesta a mensajes desde el servidor de origen. Sin embargo, si la dirección de entrada del usuario corresponde a una dirección de un servidor externo, el servidor proxy se encuentra operativo para comunicarse a través de la red de área amplia con el servidor externo en el organismo de origen del cliente. Si el cliente hace que la máquina se conecte a un servidor operado por un organismo externo, los documentos HTML enviados desde el organismo externo corresponden a los proporcionados normalmente por el organismo externo. Como resultado el cliente está familiarizado con la interfaz producida por estos documentos y podrá operar más fácilmente la máquina bancaria de archivos.
El servidor externo o el servidor de origen operan la máquina bancaria enviando documentos HTML que incluyen instrucciones para operar los dispositivos en la máquina bancaria. Las instrucciones se transmiten desde la parte de manipulación de documento HTML a la parte de aplicación de dispositivo del software, que opera los dispositivos en respuesta a las instrucciones. Las instrucciones desde la parte de aplicación de dispositivo a los dispositivos en la máquina bancaria automática se pasan a través del servidor de dispositivo del organismo de origen. Esto ayuda a mantener la seguridad. Adicionalmente, el servidor proxy incluye software de filtrado que limita a los servidores externos que pueden conectarse a y operar la máquina bancaria. Se hace referencia a esto como un "cortafuegos".
Algunas formas de realización de la presente invención proporcionan también interfaces de usuario mejoradas y para la impresión de una amplia variedad de documentos con la máquina bancaria. Algunas formas de realización permiten conseguir una funcionalidad mejorada mientras se utilizan redes de transición y máquinas de transacción automatizadas existentes.
Breve descripción de los dibujos
La figura 1 es una vista esquemática de una configuración de red que incluye un aparato y sistema de máquina bancaria automática.
La figura 2 es una vista esquemática de una forma de realización de una máquina bancaria automática.
Las figuras 3 a 24 muestran vistas esquemáticas de la máquina bancaria automática, conectando una intranet la máquina bancaria a un sistema informático de un banco de origen y conectando una red de área amplia el sistema informático del banco de origen a un banco externo.
Las figuras 3 a 18 representan esquemáticamente etapas en una transacción llevada a cabo en la máquina bancaria con el sistema informático del banco de origen.
Las figuras 19 a 24 representan esquemáticamente etapas en una transacción llevada a cabo en la máquina bancaria con el sistema informático del banco externo.
La figura 25 es una vista esquemática de una configuración de red que incluye una forma de realización alternativa de una máquina bancaria automática.
La figura 26 es una vista esquemática de marcos en la parte de manipulación de documento HTML de la forma de realización alternativa de la máquina bancaria automática mostrada en la figura 25.
La figura 27 es una vista esquemática de una interfaz de cliente de una máquina bancaria automática y teclas de función y teclas de teclado numérico incluidas en la interfaz.
Las figuras 28 a 30 representan esquemáticamente a modo de ejemplo etapas en la conversión de entradas de tecla de función y tecla de teclado numérico a entradas de flujo de teclado y flujo de ratón.
La figura 31 representa esquemáticamente etapas a modo de ejemplo en la impresión de documentos con la máquina bancaria automática.
Haciendo referencia a continuación a los dibujos y particularmente a la figura 1, se muestra en la misma una configuración de red indicada esquemáticamente por 10, que incluye el aparato y sistema de máquina bancaria automática de una forma de realización preferida de la presente invención. La red 10 incluye una pluralidad de cajeros 12 automáticos que en esta forma de realización de la invención son ATM. Las ATM 12 están conectadas a un sistema informático de un banco de origen indicado esquemáticamente por 14. El sistema informático del banco de origen 14 es el sistema informático que se opera por el banco u otro organismo que es el responsable principal de las ATM 12. El sistema informático del banco de origen 14 está conectado a las ATM 12 a través de una intranet 16. La intranet 16 es preferentemente una red local o propietaria que proporciona comunicación entre el sistema informático 14 y las máquinas 12 bancarias utilizando mensajes en el formato de protocolo de control de transmisión/protocolo de Internet ("TCP/IP").
Los mensajes que se comunican a través de la intranet 16 son preferentemente mensajes TCP/IP y documentos de lenguaje de marcado de hipertexto ("HTML"). En una forma de realización preferida de la invención los documentos HTML enviados a través de la intranet 16 incluyen instrucciones de programación orientada a objetos embebidas, preferentemente en el formato JAVA® que ha desarrollado Sun Microsystems. Los mensajes enviados a través de la intranet 16 pueden enviarse en una forma encriptada o no encriptada dependiendo de la naturaleza de los sistemas y las necesidades de seguridad del banco de origen.
Debe entenderse que las formas de realización de la invención pueden procesar otras formas de documentos que incluyen etiquetas o instrucciones en los mismos. Por ejemplo se ha propuesto recientemente una forma de HTML "extendido" que puede utilizarse en formas de realización de la invención. Para fines de este documento deberá hacerse referencia a todas tales formas de lenguajes y variantes que incluyen documentos, documentos que incluyen instrucciones en los mismos como documentos HTML. Asimismo, aunque se utiliza JAVA® en la forma de realización descrita, pueden utilizarse otros lenguajes de programación. Por ejemplo, puede utilizarse Active-X^{TM} desarrollado por Microsoft Corporación u otros lenguajes en otras formas de realización. Además debe entenderse que las instrucciones incluidas en documentos pueden encontrarse operativas para hacer que un ordenador acceda a otros documentos, registros o archivos en otras direcciones para conseguir que un programa lleve a cabo una operación.
El sistema informático del banco de origen 14 también puede conectarse como se muestra a una red de área amplia 18. En algunas formas de realización de la invención la red de área amplia 18 es Internet. En otras formas de realización de la invención, pueden utilizarse otras redes de área amplia. La red de área amplia comunica preferentemente mensajes en TCP/IP entre numerosos sistemas informáticos conectados a la red de área amplia. Estos sistemas informáticos externos se representan esquemáticamente por los servidores 20, 22, 24, 26 y 28. Debe entenderse que los servidores 20 a 28 pueden operarse por o conectarse a otros organismos financieros por todo el mundo. Los servidores 20 a 28 operan preferentemente comunicando documentos HTML y otros mensajes HTTP.
La figura 2 muestra una vista esquemática de la ATM 12 utilizado en conexión con una forma de realización preferida de la invención. La ATM 12 incluye una pantalla táctil 30. La pantalla táctil 30 incluye una pantalla de visualización que sirve como un dispositivo de salida para la comunicación con un usuario de la máquina. La pantalla táctil 30, debido a que es una pantalla táctil, también sirve como un dispositivo de entrada para recibir instrucciones de entrada desde un usuario. La pantalla táctil 30 está conectada a través de una interfaz 32 a un ordenador 34 que está alojado preferentemente dentro de la máquina. Formas de realización alternativas de la invención pueden incluir otros dispositivos de salida tales como altavoces de audio.
El ordenador 34 está también en conexión con una pluralidad de dispositivos de función de transacción 36 que están incluidos en la ATM 12. Los dispositivos 36 incluyen por ejemplo, un mecanismo de lectura/escritura de tarjetas 38 y un teclado 40. Los dispositivos 36 incluyen además un mecanismo expendedor de billetes 42 que se encuentra operativo para distribuir billetes, que en algunas formas preferidas de la invención son notas o billetes bancarios. Los dispositivos 36 también incluyen un depósito 44 para aceptar ingresos dentro de una ubicación segura en la máquina. Una impresora de comprobantes 46 para proporcionar comprobantes de transacción a clientes se incluye también entre los dispositivos 36. Una impresora de registro diario 48 se incluye también entre los dispositivos para guardar un registro de copia en papel de la información de transacción. En otras formas de realización pueden utilizarse otros dispositivos de función de transacción o adicionales que llevan a cabo otras funciones de transacción. Otras formas de realización pueden incluir menos dispositivos de función de transacción. Debe entenderse además que aunque la forma de realización descrita de la invención es una máquina bancaria automática, pueden emplearse los mismos principios en muchos tipos de máquinas de transacción que no llevan a cabo necesariamente transacciones bancarias.
Cada uno de los dispositivos está conectado operativamente a un bus 50 de control interno dentro de la máquina 12 bancaria. El bus 50 de control emite los mensajes internos a los dispositivos particulares. Cada dispositivo presenta una interfaz hardware apropiada que permite al dispositivo particular operar para llevar a cabo su función respectiva en respuesta a los mensajes transmitidos al mismo en el bus 50 de control. El medio de lectura/escritura de tarjetas 38 tiene una interfaz hardware que se muestra esquemáticamente como 52. Las interfaces hardware 54, 56, 58, 60 y 62 están operativas respectivamente para conectar el teclado 40, el mecanismo expendedor de billetes 42, el mecanismo de depósito 44, el mecanismo de impresión de comprobante 46 y el mecanismo de impresión de registro diario 48 al bus 50 de control.
El ordenador 34 tiene varios programas de software que son ejecutables en el mismo. En la forma de realización preferida de la invención estos programas de software incluyen un parte software de interconexión de dispositivos indicada en general por 64. La parte software de interconexión de dispositivos 64 incluye preferentemente una interfaz de dispositivo de software 66 que comunica mensajes electrónicos con el bus 50 de control. La parte software de interconexión de dispositivos 64 incluye también preferentemente un administrador 68 de dispositivos. El administrador de dispositivos se encuentra preferentemente operativo para administrar los diversos dispositivos 36 y para controlar sus diversos estados para garantizar que operan en secuencia apropiadamente. El administrador de dispositivos puede operarse también preferentemente para crear objetos de dispositivo en el software para permitir una operación de los dispositivos por por lo menos un programa orientado a objetos 70. La parte software de interconexión de dispositivos 64 incluye también la parte de programa orientado a objetos 70, que en una forma de realización preferida es una aplicación escrita en el lenguaje JAVA. El programa 70 trabaja en conjunción con el administrador de dispositivos para recibir mensajes orientados a objetos JAVA que hacen que los dispositivos operen, y para transmitir mensajes de operación de dispositivo indicativos de una manera en la que los dispositivos están operando y/o están recibiendo datos de entrada.
La parte software de interconexión de dispositivos 64 en la forma de realización descrita opera en un ordenador 34 y se comunica a través de una conexión 72 física TCP/IP con la intranet 16. La conexión física puede ser por vía telefónica analógica, puerto serie, conexión RDSI u otra conexión adecuada. En la configuración del sistema como se muestra, la parte software de interconexión de dispositivos 64 se comunica con la dirección IP de ordenador 34 y con un puerto IP o socket indicado por 74 que es diferente de las otras aplicaciones de software. En otras formas de realización de la invención, la parte software de interconexión de dispositivos 64 puede operar en un ordenador diferente de las otras aplicaciones de software de la invención.
Debe entenderse además que aunque en la presente forma de realización de la invención la parte de interconexión de dispositivos 64 es software, en otras formas de realización de la invención todo o partes de las etapas de instrucción ejecutadas por la parte software 64 puede residir en firmware o en otro medio de programa en conexión con uno o más ordenadores, que están operativos para comunicarse con los dispositivos 36. Para fines de este documento deberá hacerse referencia a todas tales formas de instrucciones ejecutables como software.
En el ordenador 34 opera también otro software. Este software incluye software de manipulación de documento HTML que incluye un navegador, indicado esquemáticamente por 76. En la presente forma de realización de la invención el software de manipulación de documento HTML incluye un navegador proporcionado por Netscape®. Sin embargo en otras formas de realización puede utilizarse otro software de manipulación de documento HTML y comunicación y software de navegador, tal como Hot JAVA® de Sun Microsystems o Internet Explorer^{TM} de Microsoft. El navegador 76 se comunica con el ordenador 34 en un puerto IP indicado por 78.
El navegador 76 está en conexión funcional con software de entorno JAVA 80 que permite al ordenador 34 ejecutar programas en lenguaje JAVA. Los programas en lenguaje JAVA tienen la ventaja de que operan de igual forma en una variedad de plataformas hardware sin modificación. Esta capacidad de "escribir una vez/ejecutar en cualquier parte" hace al entorno JAVA apropiado para la presente forma de realización de la invención. Sin embargo otras formas de realización pueden utilizar diferentes tipos de programas de software.
El software de entorno Java 80 permite al ordenador 34 ejecutar instrucciones en JAVAScript, indicado esquemáticamente por 82. Las instrucciones que se ejecutan mediante el ordenador en JAVAScript son preferentemente órdenes de JAVAScript embebido que se incluyen en los documentos HTML que se reciben a través del navegador 76. El navegador 76 en conexión con el software de entorno JAVA 80 que ejecuta instrucciones en el JAVAScript embebido 82, sirve como una parte software de manipulación de documento HTML para transmitir y recibir documentos HTML y mensajes TCP/IP a través del puerto IP indicado por 78.
El ordenador 34 también tiene software ejecutable en el mismo que presenta una parte de aplicación de dispositivo 84. La parte de aplicación de dispositivo 84 contiene instrucciones ejecutables relacionadas con la operación de los dispositivos 36. En la forma de realización preferida de la invención, la parte de aplicación de dispositivo consiste en una pluralidad de applets de JAVA. En la forma de realización descrita los applets son también preferentemente programas operables para controlar y realizar el seguimiento del estado de los dispositivos con los que están asociados. Ciertos applets son también preferentemente operables para configurar el navegador para comunicar mensajes. Ciertos applets administran la seguridad y autentican a las entidades que utilizan la ATM.
En la forma de realización descrita de la invención, los applets de JAVA están asociados con funciones tales como habilitar el mecanismo lector de tarjetas, notificar al navegador cuando se han introducido datos de tarjeta del usuario, operar el mecanismo de impresión de comprobante, operar el mecanismo de impresión de registro diario, habilitar el teclado de cliente y recibir datos introducidos a través del teclado, operar el mecanismo expendedor de billetes, operar el depósito, navegar a direcciones de documento, sincronizar funciones de dispositivo, verificar firmas digitales, manejar la encriptación de mensajes, controlar la mezcla de billetes distribuidos desde múltiples mecanismos expendedores de billetes, calcular cambio de divisas, y finalizar una transacción y dar instrucciones al navegador para volver a la comunicación con el servidor de origen. Por supuesto, en otras formas de realización, pueden utilizarse otros applets para controlar dispositivos y utilizar datos para llevar a cabo diversas funciones deseadas con la máquina. La parte de aplicación de dispositivo 84 se comunica con el ordenador 34 en un puerto IP indicado por 86.
En la forma de realización descrita de la invención, la parte de aplicación de dispositivo 84 del software no comunica sus mensajes directamente a la parte software de interconexión de dispositivos 64. Como se explicará posteriormente, esto proporciona seguridad reforzada. Sin embargo debe entenderse que las formas de realización de la invención pueden proporcionar que la parte de aplicación de dispositivo 84 comunique directamente mensajes de operación de dispositivo al programa de dispositivo 70. Esto puede hacerse o bien internamente utilizando TCP/IP, mediante la entrega de mensajes de una manera convencional a través de una cola establecida en el sistema operativo del ordenador que está asociado con el software que se interconecta con los dispositivos, o bien por llamada directa a este software.
A partir de la discusión anterior se apreciará también que ciertos applets en la parte de aplicación de dispositivo 84 pueden corresponder a dispositivos que no están presentes en todas las máquinas de cajero automático. Por ejemplo, una máquina de cajero automático que funciona solamente como un expendedor de efectivo no incluye un mecanismo de depósito como el depósito 44. Para tener en cuenta la situación en la que un usuario solicita una transacción que no es físicamente posible con la ATM 12, la parte software de interconexión de dispositivos 64 puede programarse para proporcionar un mensaje de respuesta apropiado para indicar que la función no está disponible.
Alternativamente, la parte software de interconexión de dispositivos puede incluir una función que compruebe la presencia o ausencia de cada tipo de dispositivo físico dentro de la ATM. Puede incluirse información indicativa de los dispositivos presentes en la ATM como parte de los mensajes generados por la ATM. Por ejemplo, puede incluirse información indicativa de los dispositivos que están operativos en la ATM como una parte o varias partes de las direcciones URL a las que la ATM dirige los mensajes. De esta forma, el URL en el servidor al que se conecta la ATM puede configurarse para proporcionar solamente documentos HTML que corresponden a los tipos de transacciones que la ATM puede realizar. Como resultado el navegador evita visualizar documentos que incluyen referencias a tipos de transacción que la máquina no puede realizar. Por tanto, por ejemplo, una máquina puede evitar mostrar una visualización en respuesta a un documento que incluye una referencia a una transacción de ingreso si la máquina no incluye un depósito.
Alternativamente la máquina puede incluir en memoria, datos representativos de los dispositivos funcionales incluidos en la máquina. Estos pueden incluir por ejemplo datos representativos de una pluralidad de dispositivos en la máquina y las configuraciones de tales dispositivos, o alternativamente, un elemento de designación tal como un número de máquina suficiente para identificar las capacidades de la máquina. Los datos de dispositivo indicativos de los dispositivos funcionales en la máquina se comunican a un servidor y el servidor se encuentra operativo para entregar los documentos HTML apropiados para los dispositivos presentes en la máquina. Esto puede hacerse basándose en los datos correspondientes a los datos de dispositivo desde la máquina o puede resolverse desde una memoria que contiene datos representativos de los dispositivos funcionales en una máquina asociada con un dispositivo de designación particular. Documentos entregados selectivamente por el servidor al navegador de la máquina incluirán las referencias apropiadas a los dispositivos funcionales presentes en la máquina. Estos documentos pueden ser documentos estáticos o pueden generarse en tiempo de ejecución a partir de subdocumentos o de otro modo, para proporcionar las salidas e instrucciones apropiadas a los dispositivos de salida de la máquina de transacción.
La figura 3 muestra la ATM 12 en comunicación a través de la intranet 16 con el sistema informático del banco de origen 14. El sistema informático 14 incluye un servidor proxy 88. El sistema 14 incluye además un servidor HTTP de origen 90. El sistema informático 14 incluye además un servidor de dispositivo 92. El servidor proxy, el servidor HTTP de origen y el servidor de dispositivo pueden incluirse en un único ordenador como se muestra, o en otras formas de realización pueden ser ordenadores separados. Servidores adicionales pueden estar operativos en otras formas de realización.
El servidor HTTP de origen 90 está preferentemente en comunicación con un almacenamiento de datos y está en comunicación electrónica con un sistema informático de oficina interna, indicado esquemáticamente por 94. El sistema informático de oficina 94 interna se encuentra operativo para realizar el seguimiento o realizar cobros a crédito o a débito de las cuentas de los clientes cuando realizan transacciones en las máquinas bancarias automáticas. Adicionalmente la oficina 94 interna está también operativa preferentemente para seguir las transacciones para fines de conseguir acuerdos con otros organismos que participan en el sistema y cuyos clientes realizan transacciones en las ATM 12.
Como se explicará posteriormente, el servidor proxy 88 está también operativo en la forma de realización descrita para comunicarse a través de la red de área amplia 18 con el servidores externos tales como el servidor externo 96. El servidor externo 96 es un ejemplo de un servidor operado por un organismo o entidad diferente del organismo que opera el sistema informático 14. Debe entenderse que aunque se indica el servidor externo 96 como operado por un organismo "externo", esto no es necesariamente indicativo de que el organismo esté ubicado en un país diferente del país del organismo que opera el sistema informático 14. Sin embargo, es posible que el servidor externo 96 pudiera ubicarse en tal país extranjero, que incluye un país en que el idioma hablado es diferente del que generalmente se utiliza en el país en el que está ubicado la ATM 12.
La forma de realización de transacciones utilizando la ATM 12 se explica ahora con referencia a las figuras 3 a 24. Debe entenderse que los siguientes flujos de transacción descritos son meramente ejemplos del funcionamiento del aparato y sistema, y el aparato y sistema pueden configurarse y operarse de numerosas formas para llevar a cabo transacciones.
Al inicio de una transacción a modo de ejemplo, como se representa esquemáticamente en la figura 3, el navegador 76 se comunica a través de la intranet 16 con el servidor proxy 88. La comunicación se establece preferentemente de una manera de tal modo que los documentos HTML previstos para atraer clientes a la ATM 12 se visualizan en la pantalla táctil 30. Se hace referencia a esto como el "modo de atracción". Estos documentos HTML que se procesan en el navegador dos producen las salidas en la forma de pantallas en la pantalla táctil 30 (y/o salidas a través de otros dispositivos de salida incluidos en la máquina) pueden originarse desde el servidor HTTP de origen 90 que se encuentra operativo para entregar los documentos HTML al servidor proxy. El servidor HTTP de origen envía los mensajes direccionados al puerto IP asociados con el navegador 76, para provocar su visualización en la máquina ATM apropiada. Debe entenderse que aunque en este ejemplo, el servidor de origen 90 se describe como comunicándose con las ATM a través del servidor proxy 88, el servidor 90 puede en otros sistemas abarcados por la invención el servidor 90 comunicarse directamente con las ATM.
Una ventaja fundamental del sistema es que el servidor HTTP de origen 90 puede entregar documentos selectivamente a las ATM 12 conectadas a la intranet 16. Estos documentos pueden incluir mensajes o material adaptado a la ubicación particular en que está ubicada una ATM 12. Ejemplos de pantallas particularmente adaptadas pueden incluir mensajes bilingües en ciertas zonas o información relativa a cambio de moneda en diversos puertos de entrada. El material o mensajes podrían incluir publicidad para diversos productos o servicios u otro material destinados a ubicaciones de máquina particulares. Los applets de JAVA y JAVAScript se cargan desde una ubicación central que proporciona distribución de software selectiva en las ATM que puede utilizarse también para adaptar la ATM a su entorno haciendo que acceda a documentos que incluyen material previsto para ser útil en esa ubicación, y que no se suministra en documentos entregados a por lo menos algunas otras máquinas en el sistema. Pueden configurarse sistemas de formas de realización de la invención para tener seleccionados.
Pueden configurarse sistemas de formas de realización de la invención para tener seleccionadas máquinas de acceso a documentos HTML en diferentes direcciones, de tal modo que los documentos particulares a los que se accede incluyan el material destinado a usuarios de la máquina particular. Alternativamente, una máquina puede comunicar datos de máquina indicativos de su identidad y/o ubicación a un servidor. A partir de los datos de máquina, y datos almacenados en un almacenamiento de datos en conexión con el servidor, el servidor opera para entregar los documentos que incluyen el material destinado. Esto puede llevarse a cabo ensamblando los subdocumentos, o de otro modo, generando los documentos que se entregarán al navegador de la máquina particular. Adicionalmente debe entenderse que aunque en la forma de realización mostrada se accede a los documentos HTML a través de un servidor de un organismo asociado con la máquina, se puede acceder a los documentos utilizados para el modo de atracción desde otros servidores operados por otras entidades.
La pantalla táctil 30 en esta secuencia de transacción a modo de ejemplo visualiza una pantalla que incluye un icono que indica en uno o más idiomas que para comenzar una transacción un usuario debe tocar la pantalla. Si un usuario toca la pantalla en el área del icono se genera una señal de entrada. La señal de entrada o mensaje HTTP se transmite a través del navegador 76 a la dirección de origen del servidor HTTP de origen 90 con el que la ATM 12 está actualmente en comunicación. El mensaje, generado de vuelta al servidor HTTP de origen se representa por las flechas dirigidas desde el navegador 76 a la intranet 16, desde la intranet 16 al servidor proxy 88, y desde el servidor proxy al servidor HTTP 90 en la figura 3.
En respuesta a que servidor HTTP de origen 90 reciba el mensaje que indica que un cliente ha tocado el icono en la pantalla, el servidor de origen se encuentra operativo en respuesta a la dirección a la que se ha accedido para enviar un mensaje a través del servidor proxy 88 (o en otras formas de realización directamente) al navegador 76. Este mensaje preferentemente incluye un documento HTML que cuando se procesa a través del navegador produce una pantalla que da instrucciones al cliente de insertar su tarjeta dentro del mecanismo lector de tarjetas 38. El flujo del documento HTML que se representa gráficamente en la figura 4, también incluye preferentemente JAVAScript embebido u otras instrucciones que operan en el entorno JAVA para comunicar un mensaje al applet de JAVA responsable de habilitar el lector de tarjetas en la parte de aplicación de dispositivo 84. En una forma de realización preferida las instrucciones proporcionan un puntero o etiqueta al applet que se ejecuta en respuesta a la recepción de instrucciones de documento. Por supuesto, en otras formas de realización puede utilizarse otro software y otros enfoques.
Como se muestra en la figura 5, en respuesta a que el JAVAScript embebido active el applet de JAVA asociado con la función de habilitación del lector de tarjetas, el applet de JAVA en la parte de aplicación de dispositivo 84 se comunica con el servidor de dispositivo 92. El servidor de dispositivo 92 incluye un programa de servidor de dispositivo 98 que en la forma de realización preferida es un programa JAVA que permite la comunicación con los applets de Java y la aplicación de servidor de dispositivo 100. El servidor de dispositivo 92 incluye preferentemente además una aplicación de software de monitorización 102 que se encuentra operativa para monitorizar instrucciones de operación de dispositivo. El software de monitorización minimiza el riesgo o fraude o abuso de una manera explicada posteriormente.
Volviendo a la transacción de muestra, en respuesta a recibir el mensaje de habilitación del lector de tarjetas desde la parte de aplicación de dispositivo 84, el servidor de dispositivo 92 se encuentra operativo para generar un mensaje a través de la intranet 16 a la parte software de interconexión de dispositivos 64 de la ATM 12. Este mensaje que comprende un registro HTTP que incluye instrucciones para operar el lector de tarjetas, se dirige al puerto IP indicado por 74 que es en el que se comunica la parte software de interconexión de dispositivos 64. En respuesta a recibir este mensaje, la parte software 64 se encuentra operativa para enviar un mensaje o mensajes a través del bus 50 de control que habilita el mecanismo lector de tarjetas 38.
Continuando con la transacción como se muestra en la figura 6, la introducción de la tarjeta por el cliente al lector de tarjetas 38 está operativa para hacer que se lean los datos de tarjeta y que la parte de programa de interconexión de dispositivos 64 envíe un mensaje al servidor de dispositivo 92 que indica que se han leído los datos de tarjeta. El servidor de dispositivo transmite este mensaje a través de la intranet 16 a la parte de aplicación de dispositivo 84. La parte de aplicación de dispositivo entonces envía un mensaje al servidor de dispositivo solicitando los datos de tarjeta. El servidor de dispositivo 92 transmite un mensaje con instrucciones para entregar los datos de tarjeta desde la parte software de interconexión de dispositivos 64 que responde con un mensaje que envía los datos de tarjeta a través de la intranet al servidor de dispositivo. El servidor de dispositivo, si no hay razones para detener la transacción, transmite un registro HTTP que incluye datos de tarjeta de vuelta a través de la intranet 16 a la parte de aplicación de dispositivo 84.
En una forma de realización preferida de la invención, la tarjeta introducida por un usuario o cliente incluye marcas que corresponden a una dirección asociada con el usuario en la red. En tal forma de realización las marcas corresponden a una dirección de localizador uniforme de recursos ("URL", Uniform Resource Locator) que proporciona información sobre el ordenador donde reside la información de usuario, así como un directorio o subdirectorio que incluye la información de usuario y el nombre del documento o recurso que incluye la información de usuario. La dirección URL puede codificarse en una tarjeta del cliente. La dirección puede codificarse en una pista 3 de una banda magnética, en otras ubicaciones dentro de los datos de la banda magnética o a través de la codificación de otras marcas legibles en la tarjeta. Alternativamente, si la tarjeta del cliente es una tarjeta "inteligente" que incluye almacenamiento semiconductor en la misma, la dirección URL asociada con el cliente puede incluirse como parte de los datos almacenados en el chip de circuito integrado en la tarjeta de cliente. Alternativamente, podría derivarse una URL a partir de otros datos en la tarjeta accediendo a una base de datos en la que los datos de dirección se correlacionan con otros datos leídos de la tarjeta. Los datos necesarios para derivar la dirección para acceder a documentos asociados con un cliente también podrían derivarse a partir de entradas a dispositivos de entrada diferentes de o adicionalmente a datos de tarjeta, incluyendo por ejemplo datos biométricos que un cliente introduce a través de un dispositivo de lectura biométrica. Tales datos biométricos pueden incluir por ejemplo, datos correspondientes a una o más huellas dactilares, datos de la apariencia del usuario o combinaciones de los mismos.
Por ejemplo y sin limitación, los datos introducidos por un cliente tal como a través de una tarjeta introducida a un lector de tarjetas pueden corresponder a una dirección para acceder a un registro HTTP, que puede ser un archivo o documento que incluye información que puede utilizarse para verificar la identidad de un usuario. Este registro podría incluir datos correspondientes a un número PIN. La información puede incluir datos biométricos correspondientes al usuario autorizado de la tarjeta. El navegador puede acceder al registro y utilizar los contenidos del registro tal como datos y/o instrucciones para verificar que las marcas correspondientes a datos biométricos en el registro corresponden a los datos biométricos del usuario que introduce la tarjeta. Alternativamente, pueden utilizarse datos de entrada representativos de apariencia, voz, otras características (o combinaciones de las mismas) u otros datos de entrada, para generar una o más direcciones que corresponden a un usuario, y utilizarse el contenido del registro en la dirección a la que se accede para verificar que el usuario en la máquina corresponde con el usuario asociado con el registro. Pueden utilizarse numerosos enfoques dentro del alcance de la invención. La información en el registro correspondiente a un usuario puede asimismo utilizarse para autorizar a ciertos dispositivos funcionales en la máquina operar para el usuario mientras otros dispositivos no pueden. Por ejemplo, un usuario que está en números rojos puede tener información en el registro al que se accede que le impida accionar el expendedor de efectivo, mientras que usuarios que no están en números rojos pueden incluir información que permita tal operación. Alternativamente, la ausencia de información en un registro correspondiente puede habilitar operaciones, mientras que la inclusión de información limita selectivamente la operación de dispositivos.
Volviendo a la transacción modo de ejemplo, la entrega de los datos de tarjeta desde una tarjeta leída satisfactoriamente se entrega en respuesta a la programación de la parte de aplicación de dispositivo 84 a un applet de JAVA asociado con la notificación de que se han introducido los datos de tarjeta. En respuesta, el applet de Java opera para generar un JAVAScript que configura el navegador con la dirección URL correspondiente a los datos leídos de la tarjeta. El applet de JAVA está preferentemente operativo también para abrir un registro indicado esquemáticamente por 104 en relación a la transacción, que incluye la dirección URL del usuario, la hora y otros datos de tarjeta. En una forma de realización preferida este registro puede almacenarse en memoria como datos en un objeto en software. El objeto se utiliza preferentemente para reunir datos a medida que avanza la transacción. Los datos almacenados en el objeto de datos de transacción incluyen preferentemente datos introducidos a través de dispositivos de entrada por el usuario así como datos representativos de operaciones llevadas a cabo por dispositivos de función de transacción.
El registro u objeto de datos de transacción proporciona persistencia a través de lo que pueden ser varias etapas de transacción diferentes ejecutadas por el cliente. La capacidad para utilizar y compartir los datos en varias operaciones diferentes evita la necesidad de derivarlos u obtenerlos de un cliente más de una vez en el transcurso de una sesión de usuario que implica varias etapas de transacción. La utilización de un objeto de datos de transacción permite a los applets ejecutarse en gran medida de manera independiente, obteniendo datos necesarios a partir del objeto de transacción. El enfoque también permite al registro u objeto de datos utilizarse para producir un registro apropiado al final de la sesión de transacción. Este registro puede almacenarse, reunirse dentro de un lote o entregarse a direcciones seleccionadas en una red local o de área amplia.
Como se muestra esquemáticamente en la figura 7, en respuesta a que el navegador 76 reciba los datos de dirección URL, el navegador se encuentra operativo para transmitir un mensaje a través de la intranet 16 al servidor proxy 88. Para fines de este ejemplo, la dirección URL asociada con los datos de tarjeta es la de un cliente asociado con el banco de origen que opera el sistema 14. Como resultado, la dirección URL del cliente hará que el mensaje se dirija desde el servidor proxy 88 al servidor HTTP de origen 90 y acceda al documento correspondiente en la dirección en el mismo. Alternativamente, la conexión puede realizarse en otros sistemas directamente con el servidor 90 sin la intervención del servidor proxy 88. Como se explicó anteriormente, la dirección URL puede incluir también datos representativos de los dispositivos que están operativos en la ATM.
En respuesta a recibir el mensaje, el servidor HTTP de origen 90 encuentra los datos correspondientes a los datos de dirección URL del cliente en su memoria asociada y entrega al navegador un documento HTML en su puerto IP. Este documento HTML puede incluir una pantalla saludando al cliente particular por su nombre así como con el nombre del organismo bancario u otra entidad que opera el sistema informático del banco de origen 14.
Adicionalmente, el documento HTML incluye preferentemente JAVAScript embebido que presenta una firma digital o medios para obtener una firma digital asociada con el servidor HTTP de origen 90. La instrucción de script incluida en el documento en ciertas formas de realización hace que la parte de aplicación de dispositivo acceda a una dirección HTTP en un servidor, que en la forma de realización descrita es el servidor 90. La dirección HTTP corresponde a un registro HTTP que incluye por lo menos una instrucción e incluye preferentemente un programa tal como un applet de JAVA o archivo Active-X. La instrucción se utiliza para operar el dispositivo de función de transacción apropiado. El registro HTTP incluye preferentemente datos representativos de una firma, tal como una firma digital. Esta firma digital se recibe en respuesta al JAVAScript 82 y se procesa en la parte de aplicación de dispositivo 84. Un applet de JAVA procesa la firma digital para autenticarla y si es una firma admisible autoriza la operación de la máquina bancaria. En ciertas formas de realización el applet puede comparar la firma con los datos de firma almacenados en memoria para una relación predeterminada, tal como una coincidencia.
Después de que el applet verifica que el servidor HTTP 90 u otro registro HTTP al que se ha accedido ha enviado una firma digital adecuada, se permitirá que la transacción continúe. Si por algún motivo no se ha enviado una firma digital adecuada, el applet de JAVA detendrá la transacción y devolverá la máquina 12 bancaria de vuelta a la condición anterior al inicio de la transacción conectando la ATM a la dirección asociada con el modo de atracción en el servidor de origen 90. La utilización de instrucciones firmadas puede utilizarse para garantizar que los diversos dispositivos de función de transacción se operan solamente en respuesta a mensajes apropiados. La utilización de instrucciones firmadas puede ser particularmente apropiada para instrucciones que ejecutan el expendedor de billetes o de otro modo proporcionan valor al usuario de la máquina.
En el ejemplo se supondrá que la firma digital recibida es una firma adecuada, en cuyo caso se devolverá un mensaje desde el navegador 76 al servidor de origen 90 indicando que la transacción puede continuar. Como se muestra en la figura 8, en esta transacción a modo de ejemplo el servidor de origen HTTP 90 opera entonces para enviar un documento HTML al navegador 76 que incluye instrucciones que cuando se procesan producen una página o pantalla que da instrucciones al cliente para introducir su número de identificación personal o PIN. Este documento HTML incluye preferentemente instrucciones JAVA embebidas que operan para hacer que la parte de aplicación de dispositivo 84 habilite el teclado 40 de la ATM para que la máquina pueda recibir el número PIN. Tal mensaje se muestra esquemáticamente en la figura 8 con el JAVAScript 82 señalando al applet de Java responsable del teclado al que se ha solicitado habilitar al teclado. En respuesta el applet de Java en la parte de aplicación de dispositivo 84 envía un mensaje a través de la intranet 16 al servidor de dispositivo 92. El servidor de dispositivo 92 envía un mensaje de vuelta a través de la intranet al parte software de interconexión de dispositivos 64 en la ATM. Las instrucciones en este mensaje hacen que el dispositivo software habilite el teclado 40. El applet de Java responsable de habilitar el teclado está preferentemente operativo también para actualizar el registro 104 de transacción para indicar que se solicitó el PIN.
Como se muestra en la figura 9, el PIN introducido a través del teclado 40 se transmite en un mensaje desde la parte software de interconexión de dispositivos 64 al servidor de dispositivo 92. El servidor de dispositivo 92 devuelve un mensaje al applet de Java responsable en la parte de aplicación de dispositivo. El applet de JAVA opera entonces para enviar un mensaje de vuelta a través de la parte de manipulación de documento HTML y el navegador 76 a la dirección HTTP del servidor de origen 90. Este mensaje incluye datos representativos del PIN introducido por el cliente. En algunas formas de realización no es deseable visualizar el PIN del cliente en la pantalla. En tales formas de realización el applet de teclado puede estar operativo para visualizar un carácter por defecto en la pantalla de archivo tal como un símbolo "*" u otro símbolo en lugar de los dígitos del PIN. Además como se comentará posteriormente puede ser deseable evitar la transmisión del PIN u otros datos a través del navegador, en cuyo caso los datos del PIN pueden manejarse como un mensaje HTTP separado o de otra manera para reducir el riesgo de revelación.
El software que opera en conexión con el servidor HTTP 90 está entonces operativo para o bien verificar el propio PIN o bien para verificar el número PIN y número de cuenta del cliente enviándolo a la oficina 94 interna y esperando una respuesta. Alternativamente, la verificación del PIN de cliente puede llevarse a cabo en la ATM a través de un applet apropiado. Esto puede hacerse en situaciones en las que los datos en una tarjeta del cliente, tal como un número de cuenta, pueden correlacionarse con el número PIN del cliente a través de un algoritmo. El JAVAScript embebido en los mensajes HTML puede incluir o apuntar a una dirección para obtener los datos y/o instrucciones que el applet utiliza para realizar esta función de verificación, incluyendo ciertos datos de clave de encriptación. Esto puede incluir información de usuario en el documento HTML u otros datos de registro a los que se accedió en respuesta a los datos de tarjeta del usuario. Como se muestra esquemáticamente en la figura 9, el objeto de datos de transacción 104 también se actualiza apropiadamente por el applet para indicar la entrada del PIN del cliente.
En formas de realización alternativas la máquina puede incluir a dispositivo lector biométrico u otro dispositivo de entrada para aceptar datos desde un usuario. El usuario puede introducir datos a través de un dispositivo de este tipo que pueden utilizarse en lugar de, o adicionalmente a, los datos de PIN para verificar que el usuario es un usuario autorizado. Esto puede hacerse por ejemplo comparando los datos de entrada del usuario con información correspondiente al usuario autorizado de la tarjeta incluida en un registro o un documento que presenta una dirección HTTP y al que se accede por un navegador o por una aplicación cliente HTTP a través de un servidor HTTP en respuesta a datos de tarjeta. Alternativamente los datos de entrada pueden utilizarse para generar direcciones para documentos o registros a los que se accede por el navegador o cliente, registros o documentos que contienen información que se utiliza para verificar la identidad del usuario. Por ejemplo, datos en relación a usuarios pueden almacenarse en un almacenamiento de datos en conexión con un servidor HTTP, que entrega datos desde un registro en respuesta a los datos de usuario, que se utilizan para verificar la identidad del usuario.
Debe observarse que la página o pantalla que solicita al cliente introducir su PIN se muestra generada desde el servidor HTTP de origen 90. Ésta es preferentemente una pantalla que está asociada con la dirección URL del cliente particular. Ésta será la interfaz del banco de origen del cliente y será familiar para el cliente. Alternativamente, la dirección del cliente puede acceder a lo que puede ser esencialmente la "página de inicio" personal del cliente con el organismo que opera el sistema informático 14. Como tal, esto no es solamente algo con lo que el usuario está familiarizado, sino que está adaptado idealmente a las necesidades de transacción particulares del usuario.
Alternativamente, el/los documento(s) o registro(s) que contiene(n) datos de cliente puede(n) utilizarse para generar las direcciones para otros documentos. La información puede utilizarse también para generar un documento para el cliente particular en las circunstancias particulares. Este enfoque puede ser útil para reducir el esfuerzo asociado con desarrollar por adelantado un documento o página visual personal para cada cliente.
Los enfoques para llevar a cabo esto pueden implicar incluir diversos tipos o categorías de información de usuario en el/los documento(s) o registro(s) que se refiere(n) a un cliente particular. Esto puede incluir informaciones tales como sexo, parientes, tipos de cuenta, transacciones permitidas, preferencias de cliente, intereses del cliente, saldos de cuenta, ofertas previas rechazadas o aceptadas y otra información. Esta información de cliente puede utilizarse por un applet apropiado entre los applets 86 para tratar y/o desarrollar un documento apropiado para que el navegador acceda basándose en el "perfil" de cliente. Adicionalmente, el applet de perfil puede tener en cuenta los dispositivos de transacción presentes en la máquina particular, información que se almacena en un almacenamiento de datos en la máquina o en cualquier otro lugar en el sistema, así como otro factores tales como el día de la semana y hora del día basándose en un reloj de sistema. De esta forma la máquina determina el documento apropiado al que acceder o generar para el cliente particular bajo las circunstancias particulares.
La lógica utilizada en el applet de perfil puede actuar para hacer que se construyan o se acceda a documentos para el cliente que incluye opciones de transacción basándose en la información de cliente, información acerca del terminal y otros factores. El applet de perfil puede operar para ofrecer información u opciones de transacción selectivamente basándose en las informaciones de cliente. Por ejemplo, el operador de la máquina puede ofrecer incentivos, primas, opciones adicionales de transacción o información de publicidad selectivamente a los clientes. Ciertos tipos de clientes del organismo que opera la máquina pueden recibir salidas de pantalla con opciones que les animen a hacer más negocios o diferentes tipos de negocios con el organismo. Asimismo, pueden proporcionarse incentivos a clientes que se identifican como clientes de organismos externos para hacer negocios con el organismo que opera la
máquina.
El applet de perfil puede operar para hacer que el ordenador acceda a otros documentos en otros servidores, tales como datos de mercado de acciones, y proporcionárselos selectivamente a los clientes. Debe entenderse que el applet de perfil puede operar para determinar una dirección o generar documentos para producir pantallas de visualización iniciales de una secuencia de transacción. El applet de perfil puede operar también para proporcionar información o acceso o producir documentos para generar salidas visuales al cliente en otros puntos en una transacción o entre transacciones. Esto puede utilizarse además en sistemas en los que el operador de la máquina puede vender publicidad pagada a terceros y acceder entonces a los registros HTTP tales como archivos HTML para aquellos productos o servicios de terceros. Tal acceso puede hacerse de forma periódica o de otra forma, pero puede hacerse seleccionando efectivamente el registro HTTP para que acceda en respuesta al perfil del cliente particular.
La continuación del flujo de transacción para esta transacción a modo de ejemplo por un cliente del organismo que opera la red informática 14, se muestra esquemáticamente en la figura 10. El servidor HTTP de origen 90 se encuentra operativo en respuesta a que el cliente introduzca el PIN correcto para enviar documentos HTML a la parte de manipulación de documento HTML del software en el ordenador que opera la ATM. Estos mensajes pueden incluir información utilizada para generar pantallas que le piden al cliente que seleccione una transacción. Para fines de este ejemplo, se supondrá que el cliente introduce en la pantalla táctil 30 una selección que corresponde a la dispensación de efectivo, que es una transacción común en una máquina bancaria automática.
La selección del cliente a través del dispositivo de entrada de la pantalla táctil se comunica de vuelta a través de la parte de manipulación de documento HTML que comunica un mensaje HTTP al servidor HTTP de origen 90. El servidor 90 responde entonces enviando otro documento HTML a la máquina bancaria que le pide al cliente que seleccione una cantidad. De nuevo el cliente puede introducir una selección en la pantalla táctil que indica la cantidad de efectivo solicitada por el cliente. Este mensaje HTTP pasa a través de la parte de manipulación de documento HTML y el navegador 76 al servidor de origen 90.
En respuesta a la recepción de datos de cantidad desde el cliente, el servidor de origen 90 está preferentemente operativo para comunicarse electrónicamente con la oficina 94 interna para verificar que el cliente tiene la cantidad solicitada en su cuenta. Esto se lleva a cabo preferentemente a través de una interfaz de entrada común (CGI, Common Gateway Interfaz) 106 que está en conexión funcional con el servidor de origen 90. Para fines de esta transacción se supondrá que la oficina 94 interna indica que el dinero está disponible en la cuenta del cliente y envía un mensaje a través de la CGI 106 al servidor de origen 90 que indica que ésta puede continuar.
Como se representa esquemáticamente en la figura 11, el servidor de origen 90 opera entonces para enviar un documento de vuelta a la parte de manipulación de documento HTML en el software de ATM. Este mensaje hará preferentemente que la información se visualice en la pantalla que notifica al cliente que la transacción se está procesando. Adicionalmente el documento HTML devuelto incluye preferentemente JAVAScript que incluye instrucciones embebidas que se ejecutan y se comunican a un applet de Java asociado con la operación del mecanismo expendedor de billetes 42.
El documento devuelto desde el servidor de origen 90 puede incluir publicidad u otra información en vez de o adicionalmente al mensaje de cliente. El documento devuelto también puede incluir una instrucción que hace que la máquina acceda a o genere otro documento. Estas instrucciones pueden invocar procedimientos en el applet de perfil que dependen de las propiedades asociadas con el cliente, la máquina, la hora actual y/u otras circunstancias. Esto permite acceder a documentos que proporcionan mensajes promocionales tales como publicidad u otra información al cliente mientras el cliente está esperando a que la máquina opere. Debe entenderse que puede accederse a estos documentos en cualquier parte, incluyendo desde Internet. Esto hace posible presentar selectivamente una amplia gama de materiales a los clientes. Esto también permite a los operadores de las ATM y otras máquinas de transacción presentar publicidad a clientes, de manera general, o destinada a categorías de clientes o incluso destinada a clientes individuales de manera personalizada, Ésta podría ser publicidad del operador de la máquina tal como un banco, o publicidad referente a casi cualquier tipo de bienes o servicios. La publicidad puede también presentarse selectivamente basándose en el dispositivo de transacción particular que se opera, la cantidad de fondos implicados u otros parámetros. Los documentos HTML también permiten la presentación de vídeo y sonido al cliente, lo que puede mejorar la efectividad de las promociones.
El mensaje al applet de JAVA en la parte de aplicación de dispositivo 84 del software para iniciar la operación del expendedor de billetes da como resultado la generación de un mensaje al servidor de dispositivo 92. El mensaje al servidor de dispositivo 92 de distribuir efectivo se analiza preferentemente por el software de monitorización 102 para verificar si el mensaje es apropiado. Por ejemplo el software de monitorización 102 está preferentemente operativo para garantizar que la cantidad de efectivo que se solicita no excede una cantidad preestablecida. También puede verificar opcionalmente que la cantidad proporcionada a este cliente dentro de un período anterior no ha excedido una cantidad. Esto puede hacerse por el servidor de dispositivo enviando un mensaje a la oficina interna que incluye los datos de tarjeta que ha recibido anteriormente desde este cliente. Este mensaje puede pasar a través del servidor 90 y su CGI asociado, u otra conexión. Suponiendo que la instrucción de dispensación no se impide por un mensaje desde la oficina interna o el software de monitorización, el servidor de dispositivo 92 se encuentra operativo para enviar un mensaje de dispensación a la parte software de interconexión de dispositivos 64 en la ATM. La parte software 64 esta a partir de entonces operativa en respuesta al mensaje para operar el mecanismo expendedor de billetes 42 para distribuir la cantidad de efectivo solicitada por el cliente.
El software de monitorización 102 realiza preferentemente funciones adicionales en el servidor de dispositivo. Por ejemplo, normativas gubernamentales o buena práctica de negocios pueden requerir limitar el tamaño y cantidades de ingresos que pueden realizarse en una ATM. Esto puede ser aconsejable para impedir el "blanqueo de dinero" u otras actividades sospechosas. El software de monitorización opera preferentemente para limitar la cantidad de cualquier ingreso único por debajo de un límite establecido. Éste opera además comunicándose con el sistema de oficina 94 interna del banco de origen para impedir que una serie de ingresos dentro de un tiempo preestablecido exceda un cierto límite. El software de monitorización también puede trabajar en conexión con el servidor proxy para limitar ciertas transacciones que pueden realizarse en la máquina bancaria en respuesta a instrucciones desde servidores externos como se comentará posteriormente.
Debe observarse que en una forma de realización preferida de la invención el applet de JAVA que se encuentra operativo para enviar el mensaje que hace que se dispense el efectivo, trabaja en conexión con otro applet que controla la mezcla de billetes distribuidos a un cliente. Muchas máquinas expendedoras de billetes tienen la capacidad de distribuir dos o más denominaciones de billetes bancarios. Es deseable controlar la mezcla de billetes distribuidos a un cliente para adaptarse a lo que está disponible en la máquina y evitar que una denominación de billetes se agote de antes que otra. El applet de mezcla de billetes se encuentra preferentemente operable para controlar la mezcla de billetes según los deseos del organismo que opera la máquina ATM así como según las capacidades de la máquina ATM. Alternativamente, un applet de JAVA para controlar la mezcla de billetes puede residir en el programa de dispositivo 70 en la parte software de interconexión de dispositivos 64.
Como apreciarán los expertos en la materia, los applets de JAVA y/o datos de configuración particulares en la máquina pueden cargarse selectivamente desde el servidor de origen 90 en la puesta en marcha de la máquina o en otros momentos. Puesto que los applets y datos de configuración pueden entregarse selectivamente a máquinas particulares, las máquinas pueden adaptarse específicamente a la dispensación de efectivo y otras capacidades de la ATM particular. Por ejemplo, la ATM puede configurarse de tal modo que ciertos applets o grupos de applets deban estar presentes para permitir operar a la máquina. Un enfoque para cargar tales datos o programas es proporcionar valores de dirección en el software de terminal para indicar dónde pueden obtenerse las instrucciones necesarias para adquirir los applets o datos. Si los applets o grupos de applets ya no están presentes en la memoria del terminal ATM en la puesta en marcha, el software se encuentra operativo para acceder a las direcciones de sistema para los documentos que contienen los registros o instrucciones requeridos que harán que la máquina cargue los registros requeridos. El navegador puede utilizarse para acceder a las direcciones y el software carga datos correspondientes a las instrucciones desde los documentos a los que se accede en una memoria en el terminal ATM de tal modo que el terminal tenga los applets y datos requeridos. Puede accederse a tales direcciones de documento a través del servidor de origen 90. Alternativamente las direcciones pueden estar en un servidor de desarrollo separado conectado a la intranet 16. De esta forma cada máquina de transacción puede cargar los applets y datos que incluyen el código operativo que necesita para operar los dispositivos de transacción en la máquina. Alternativamente, los documentos pueden proporcionarse a través de un servidor de desarrollo u otro servidor que esté accesible para la máquina a través de una red de área amplia. Los documentos pueden proporcionarse en el servidor de desarrollo para proporcionar a la máquina instrucciones sobre cómo adquirir el código operativo para llevar a cabo una amplia variedad de funciones. Las instrucciones pueden indicar a la máquina que adquiera los datos y el código necesarios desde direcciones accesibles a través de servidores HTTP por un cliente HTTP en la máquina. Los datos y el código pueden adquirirse en respuesta a instrucciones en uno o varios documentos. La máquina puede también requerir que los applets cargados de esta manera sean applets firmados que incluyen firmas digitales u otras características de autenticación para conseguir la operación de ciertos dispositivos en las máquinas.
Alternativamente, formas de realización de la invención pueden adquirir los applets y datos necesarios desde un almacenamiento de datos remoto. El almacenamiento de datos incluye preferentemente los datos y/o programas que permiten a la máquina operar según se desee o tener instrucciones en las que la máquina puede adquirir las instrucciones y datos necesarios para su funcionamiento. Los datos pueden estar accesibles desde un servidor de bases de datos. La máquina de transacción direcciona una consulta al servidor de bases de datos. La consulta incluye o se acompaña de marcas de la máquina que identifican la máquina. Ésta puede ser la máquina particular tal como un número de máquina, y/o puede incluir marcas representativas del tipo o capacidades de dispositivo funcional de la máquina.
El almacenamiento de datos incluye preferentemente registros que presentan los datos o programas que han de transmitirse a la máquina. En respuesta a la consulta al servidor, el servidor recupera registros desde el almacenamiento de datos y en respuesta a los mismos entrega uno o más mensajes al cliente HTTP en la máquina de transacción. Este/estos mensaje(s) incluye(n) la configuración datos o applets para permitir a la máquina operar de la manera deseada o puede incluir instrucciones que indican cómo va a adquirir la máquina tales programas desde servidores conectados en el sistema.
En el ejemplo mostrado el servidor de configuración y el almacenamiento de datos pueden operar en el mismo ordenador como servidor de banco de origen 90. En otras formas de realización el servidor de bases de datos puede residir en cualquier lugar en las redes a las que se conecta la máquina.
Una ventaja de las máquinas y sistemas que emplean tales características es la flexibilidad para cambiar el funcionamiento e interfaz de cliente de la máquina para responder a condiciones cambiantes. Esto puede incluir un cambio en un dispositivo de función de transacción. Las condiciones pueden cambiar de modo que ciertas transacciones estén limitadas o no estén disponibles. Por ejemplo, una máquina normalmente puede aceptar ingresos pero su depósito está lleno. En esa situación la máquina puede cambiar los documentos a los que accede para presentar mensajes a usuarios a través de sus dispositivos de salida de modo que la opción de ingreso ya no se ofrece más. Esto puede llevarse a cabo por los applets y datos cargados en la máquina inicialmente, que proporcionan instrucciones cuando tal caso se detecta. Alternativamente, puede modificarse la programación de la máquina cargando nuevos applets y/o datos desde un servidor HTTP en respuesta entonces a su estado actual. Este puede hacerse en respuesta a una consulta a un servidor de bases de datos que incluye o se lleva a cabo por datos representativos de las capacidades o condiciones cambiadas de la máquina. En respuesta el servidor entrega el/los applet(s), datos y/o instrucciones que operarán la máquina en el modo modificado.
Este enfoque elimina la situación con máquinas de transacción convencionales en las que la presentación de interfaz estática sobre dispositivos de salida ofrece una opción de transacción a un cliente. Algunas veces, después de que el cliente ha realizado la selección se da una indicación de que la opción de transacción seleccionada no está disponible. El enfoque descrito en la presente memoria puede utilizarse con numerosas opciones de transacción y variaciones de transacciones. Las opciones de transacción pueden cambiarse fácilmente desde el servidor de bases de datos máquina a máquina o incluso cliente a cliente como se comentó anteriormente, basándose en los deseos de la entidad que opera la máquina de transacción.
A continuación, se continuará la descripción de la transacción a modo de ejemplo. En respuesta a que el expendedor 42 de efectivo dispense la cantidad de efectivo solicitada, el programa de software de interconexión de dispositivos 64 opera preferentemente para enviar un mensaje de operación de dispensación que confirma la dispensación de vuelta al applet de JAVA responsable de la dispensación en el programa de aplicación de dispositivos 84. Como se representa en la figura 12, el applet particular se encuentra operativo para actualizar el registro 104 de transacción para indicar al cliente la dispensación de moneda en la cantidad particular. Las instrucciones JAVAScript embebido que se encontraban operativas para provocar la dispensación de moneda al cliente, también incluyen preferentemente instrucciones para enviar un mensaje de confirmación de vuelta al servidor de origen 90 de que la dispensación está completa. La recepción del mensaje de operación de dispensación que indica que se dispensó el efectivo provoca que los applets de JAVA configuren la parte de manipulación de documento HTML para enviar un mensaje de respuesta de dispositivo de vuelta al servidor de origen. El servidor de origen entonces se opera preferentemente según su programación para indicar a la oficina 94 interna que el cliente recibió la cantidad de fondos distribuida. Esta cantidad se resta de la cuenta del cliente en los registros mantenidos por el sistema de oficina interna.
Generalmente durante una transacción es común preguntar al cliente si desea tener un comprobante para la transacción. Esto puede hacerse en diversos tiempos durante el flujo de transacción. En el presente ejemplo, después de que se ha distribuido el efectivo se envía al cliente que opera la máquina un mensaje de este tipo como se refleja en la figura 13. El servidor de origen 90 se encuentra operativo para enviar un documento HTML que incluye una pantalla que pregunta al cliente si desearía un comprobante. Este mensaje se visualiza como parte de una página en la pantalla táctil 30 en respuesta a la recepción del mensaje a través del navegador 76. Alternativamente el documento puede generarse mediante la máquina. En respuesta a que el cliente indique que quiere o no quiere un comprobante, se devuelve un mensaje al servidor de origen. De nuevo, debe entenderse que las pantallas visualizadas al cliente son preferentemente aquellas a las que el cliente está acostumbrado en su organismo de origen, y puede ser una parte de su página de inicio única.
Suponiendo que el cliente desea recibir un comprobante de transacción, el servidor de origen 90 opera como se muestra en la figura 14 para enviar un documento de vuelta a la ATM con JAVAScript embebido que indica que ha de imprimirse un comprobante de transacción. Estas instrucciones en JAVAScript se comunican con la parte de aplicación de dispositivo 84 que envía un mensaje TCP/IP a través de la intranet al servidor de dispositivo 92. El servidor de dispositivo 92 comunica a su vez un mensaje con instrucciones a la parte de software de interconexión de dispositivos 64 en la ATM. En respuesta a la recepción del mensaje, la parte de software 64 se encuentra operativa para hacer que la impresora 46 imprima el comprobante de transacción del cliente. El applet de JAVA responsable de habilitar la impresora se encuentra también preferentemente operativo para actualizar el registro 104 u objeto de datos de transacción. Como se comenta posteriormente, el applet que controla la impresión del comprobante puede obtener los datos utilizados en la impresión del comprobante desde el objeto de datos de transacción.
Debe entenderse que incluso si el cliente no desea tener un comprobante es deseable imprimir un registro de la transacción en copia en papel mediante la impresora de registro diario 48. Esto puede llevarse a cabo en respuesta a instrucciones embebidas que son parte del mismo documento del servidor de origen 90, lo que hace que se imprima el comprobante de transacción para el cliente, o puede ser parte de un documento separado que indica que el cliente ha rechazado la opción de recibir un comprobante de transacción. Alternativamente, la impresora de registro diario puede accionarse en respuesta a otros applets tal como el applet que provoca que la dispensación de efectivo, o de otra manera elegida por el operador de la ATM. Como se apreciará a partir de la descripción anterior el funcionamiento de la presente forma de realización de la ATM es flexible y programable de manera inherente para cumplir las necesidades del operador del sistema.
Como se muestra en la figura 15 tras completar la impresión del comprobante de transacción, la parte de software 64 se encuentra preferentemente operativa para enviar un mensaje de operación de dispositivo al servidor de dispositivo 92 que es indicativo de que se llevó a cabo satisfactoriamente la función de dispositivo solicitada. El servidor de dispositivo 92 se encuentra operativo para enviar un mensaje de operación de dispositivo correspondiente a la parte de aplicación de dispositivo 84, y en la forma de realización preferida al applet de JAVA particular responsable de la impresión del comprobante. El applet de JAVA a su vez configura la parte de manipulación de documento HTML para generar un mensaje de vuelta al servidor de origen en la forma de un mensaje de respuesta de dispositivo para indicar que se imprimió el comprobante para el cliente.
Habiendo recibido el efectivo y un comprobante, se pide al cliente mediante una pantalla generada a partir de un documento HTML desde el servidor de origen 90, que indique si desea realizar otra transacción. La pantalla o página visual que pregunta al cliente a este respecto se visualiza sobre la pantalla táctil 30. Para fines de este ejemplo se supondrá que el cliente no quiere otra transacción y se devuelve un mensaje a ese efecto a través de la parte de manipulación de documento HTML de vuelta al servidor de origen 90.
Como se muestra esquemáticamente en la figura 17 en respuesta a recibir un mensaje que el cliente ha realizado, el servidor de origen 90 se encuentra operativo para enviar un mensaje "ir al origen" a la ATM. Este mensaje incluye preferentemente un documento HTML que produce una visualización de pantalla dando las gracias al cliente. Este mensaje también incluye preferentemente JAVAScript embebido que llama al applet de Java que finalmente devuelve la parte de manipulación de documento HTML de la ATM de vuelta hacia la conexión con la dirección URL en el servidor de origen 90 u otra dirección que proporciona los documentos que se utilizan para emitir los mensajes para el denominado "modo de atracción". Debería recordarse que el script en algunas formas de realización puede operar para hacer que se envíe un mensaje desde la parte de manipulación de documento a una dirección en el servidor de origen que hace que se cargue un registro HTTP correspondiente que incluye las instrucciones que comprenden el applet deseado.
Como se indica esquemáticamente en la figura 18, el applet de orden "ir al origen" se encuentra operativo para configurar el navegador 76. Después de que la parte de manipulación de documento HTML se configura por el applet de JAVA para volver al origen, el applet de JAVA puede configurarse para entregar al servidor de origen 90 información desde el registro 104 de transacción en relación a la transacción que acaba de completarse. Debido a que la transacción a modo de ejemplo era con un cliente del organismo que opera el sistema informático 14, todos los datos relativos a esa transacción ya deberían estar registrados en la oficina 94 interna. Sin embargo se apreciará que este no será el caso si la transacción se efectuara en respuesta a mensajes desde un servidor operados por un organismo diferente. Por lo tanto, toda o una parte de la información desde el registro 104 de transacción puede entregarse en respuesta a una orden "ir al origen" al servidor de origen 90 y a través de la CGI al sistema 94 de oficina interna donde puede identificarse como información duplicada y desecharse Esto puede hacerse utilizando invocación de procedimiento remota (RMI, Remote Method Invocation) para pasar o entregar el objeto al servidor 90 y luego transmitir los datos a través de mensajes desde el servidor a la oficina interna o a través de mensajes u otras técnicas.
Por supuesto en otras formas de realización la información de transacción puede almacenarse en una base de datos durante periodos prolongados en lugar de devolverse después de cada transacción. Alternativamente la ATM 12 puede incluir applets que se encuentran operables para entregar información de registro de transacción a direcciones diferentes a la del servidor de origen, si el operador del sistema 14 lo desea.
El funcionamiento del sistema informático cuando un usuario "externo" utiliza la ATM 12 se representa gráficamente con respecto a las figuras 19 a 24. Una transacción con un usuario externo que no es un cliente del organismo que opera la ATM 12 y el sistema informático 14, se operará bajo el control del servidor de origen 90 y continuará de la manera del ejemplo anterior a través del punto en el que cliente introduce su tarjeta. El cliente introduce una tarjeta que tiene marcas correspondientes a una dirección URL que no corresponde con el servidor de origen 90. La parte de manipulación de documento HTML se encuentra operativa para configurar un mensaje direccionado a una dirección URL que corresponde con las marcas en la tarjeta del cliente u otra dirección en respuesta a tales marcas. Este mensaje se entrega al servidor proxy 88 que a su vez pasa el mensaje a la red de área amplia 18. Desde la red de área amplia el mensaje continúa hacia el servidor externo correspondiente a la dirección URL del cliente. Para fines de este ejemplo, el servidor externo se corresponde con el servidor 96 que está conectado a Internet.
En la forma de realización preferida de la invención el servidor proxy 88 incluye software de filtrado indicado gráficamente por 107. El software de filtrado preferentemente se encuentra operable para comprobar las direcciones a las que se dirigen los mensajes mediante el archivo ATM y para impedir selectivamente el envío de mensajes a direcciones particulares. Esto sirve como un "cortafuegos" y es deseable para fines de impedir el fraude en el sistema.
Como se muestra en la figura 20, el servidor externo 96 preferentemente se opera para comunicar mensajes HTTP, que incluyen documentos HTML, a la ATM 12 de vuelta a través de la red de área amplia 18. Esto puede hacerse utilizando una conexión de socket segura ("SSC", Secure Socket Connection) para minimizar el riesgo de intercepción de los mensajes. Por supuesto, pueden utilizarse otras técnicas, incluyendo técnicas de mensajes de encriptación para minimizar el riesgo de intercepción de los mensajes.
Como se representa esquemáticamente en la figura 20 el documento de respuesta desde el servidor externo 96 incluye preferentemente JAVAScript embebido que es representativo de o se corresponde con una firma digital que identifica al servidor externo 96. Esto puede llevarse a cabo cargando un registro HTTP que incluye un applet firmado, como se comentó anteriormente. Un applet en la parte de aplicación 84 en la ATM opera preferentemente para verificar la firma digital de la manera descrita en el ejemplo anterior, y envía un mensaje que indica que se ha autorizado la transacción. La identidad digital del organismo externo se almacenará en memoria en la ATM y finalmente se registrará en la oficina 94 interna.
Debería observarse que los documentos HTML desde el servidor externo 96 producen las pantallas o páginas visuales del organismo externo que el cliente externo está acostumbrado a ver. Estas páginas pueden corresponderse con la "página de inicio" del usuario externo que está adaptada específicamente a las necesidades del usuario
particular.
La figura 21 muestra un ejemplo de un documento al que se accede a través del servidor externo 96 a la ATM 12. El documento desde el servidor externo puede incluir JAVAScript embebido que permite la operación de los applets de JAVA de la manera comentada anteriormente para operar los dispositivos 36 en la ATM. Como se muestra en la figura 21 los mensajes TCP/IP a los dispositivos desde los applets de JAVA pasan desde la parte de aplicación de dispositivo 84 al servidor de dispositivo 92, y las instrucciones desde el mismo a la parte de software de interconexión de dispositivos 64 en la ATM. Los mensajes de operación de dispositivo toman una trayectoria inversa. Como estos mensajes pasan a través del servidor de dispositivo 92, el software de monitorización 102 los monitoriza para minimizar el riesgo de fraude o abuso.
Como se indica en la figura 21, los documentos desde el servidor externo 96 pueden estar operativos para visualizar en la pantalla táctil 30 una solicitud para que el cliente introduzca su PIN. Las instrucciones JAVAScript embebido incluirían, como en la transacción de muestra comentada anteriormente, instrucciones que permiten que el teclado 40 acepte el PIN del cliente. Como en el ejemplo anterior, un registro 104 de transacción que incluye un objeto de datos compartidos en relación a esta transacción se abriría por la parte de software de aplicación de dispositivo. Como se comentó anteriormente, pueden realizarse previsiones para impedir el paso de datos de PIN a través del navegador si se desea.
La figura 22 indica la vuelta del mensaje de operación de dispositivo y datos de PIN al applet de Java, que a su vez transmite los datos de vuelta al servidor externo 96 a través de la red de área amplia 18 utilizando la conexión de socket segura. Desde este punto la transacción continúa generalmente como se describió anteriormente, excepto que el servidor externo 96 envía los registros HTTP, que incluyen documentos HTML, y recibe los mensajes desde la parte de manipulación de documento de la ATM. El servidor externo 96 incluye el software de aplicación Java necesario para incluir el JavaScript embebido en los documentos que se envían a la ATM para operar los dispositivos 36 en la máquina.
Como el servidor externo 96 funciona la máquina, el software de monitorización 102 en el servidor de dispositivo 92 se encuentra operativo para monitorizar los mensajes de la manera comentada anteriormente. Tal monitorización podría operar, por ejemplo, para impedir la dispensación de cantidades de efectivo demasiado grandes fuera de la máquina. El software de monitorización también puede operar para restringir a ciertos organismos externos a un subconjunto de capacidades o dispositivos de máquina de transacción. Esto se realiza basándose en datos almacenados en memoria que limitan los dispositivos o actividades que pueden llevarse a cabo a partir de documentos en ciertas direcciones. Esto puede conseguirse por ejemplo a través de la utilización de plug-ins de código que implementan una clase de los objetos de transacción que limita las operaciones que pueden realizarse. Por ejemplo, las operaciones que permiten la conexión al servidor externo pueden instanciar los objetos que proporcionan capacidades limitadas especificadas para mensajes recibidos desde el servidor externo. Esto puede limitar por ejemplo la cantidad de dinero distribuida, impedir la operación de un dispositivo de aceptación de cheques, limitar la dispensación para documentos impresos tales como entradas, impedir la operación del expendedor de efectivo o limitar la utilización de la máquina de otras maneras apropiadas. Esto puede realizarse basándose en las direcciones o partes de direcciones para documentos.
Si las capacidades de la máquina para el cliente externo están limitadas, puede proporcionarse al cliente externo una interfaz visual desde el banco externo basándose en las transacciones que la máquina puede realizar y que permitirá el propietario de la máquina. Como resultado los documentos a los que se accede en el servidor de banco externo pueden ser una variación de los que se le proporcionarían al cliente en una máquina operada por el banco externo. Esto podría basarse en documentos desarrollados específicamente para operar máquina externas, o podría ser una variante de la interfaz de banco externo habitual con indicaciones visuales de que no están disponibles ciertas transacciones. En algunos casos la interfaz puede indicar que están disponibles algunas transacciones con un cobro por servicio
asociado.
La ATM de la forma de realización descrita puede mejorar la seguridad limitando las direcciones a las que puede acceder el navegador. Esto puede realizarse manteniendo una lista de en la memoria de la máquina. Esta lista puede mantenerse en el/los registro(s) HTTP (que incluye(n) documentos) accesible(s) a través de la intranet del banco de origen. La máquina puede acceder al registro periódicamente y actualizar los datos de memoria. Este registro puede requerir él mismo una firma digital correspondiente a una firma en la memoria del terminal antes de que se carguen los datos en la memoria del terminal. Esta información puede incluir también las instrucciones e información para la ATM para verificar que los mensajes que recibe mediante acceso a los documentos en el servidor externo son auténticos. Esto puede incluir firmas digitales que cuando se transfieren utilizando técnicas de encriptación de clave pública o clave privada verifican los mensajes como auténticos. La máquina comprueba para garantizar que la firma en los registros a los que se ha accedido desde el servidor externo se corresponde con la firma digital para esa dirección almacenada en memoria, y permite el funcionamiento de dispositivos de transacción, tales como el expendedor de efectivo, sólo cuando está presente tal correspondencia. Por supuesto, pueden utilizarse diversos enfoques para verificar y encriptar mensajes en diversas formas de realización. Como se utiliza en la presente memoria firmas o registro firmado abarcan cualquier marca que esté incluida en o pueda derivarse de un registro que sea indicativa de que está autorizada.
Como puede apreciarse también a partir de la descripción anterior, el servidor externo 96 puede comunicarse con el usuario a través de la pantalla táctil en un idioma que es diferente del utilizado normalmente por los clientes del organismo que opera el sistema informático 14. Como resultado los documentos HTML pueden visualizar solicitudes para distribuir efectivo de un tipo o en una cantidad que no está incluida en la ATM. Para tener en cuenta esta situación se incluye preferentemente un applet en la parte de aplicación de dispositivo 84 para ocuparse de solicitudes para efectivo extranjero. El applet de efectivo extranjero hace que la ATM envíe un mensaje de vuelta a su servidor de origen para fines de calcular una cantidad más próxima que puede proporcionarse al cliente en el efectivo disponible en la ATM que corresponde con lo que solicitó el cliente. Como se apreciará, este applet se encontrará operativo para llamar a la dirección de función particular dentro del servidor de origen 90 que puede proporcionar esta función. Cuando se realiza la dispensación el applet también se encuentra operativo para indicar al servidor 96 que la cantidad distribuida defiere en algo de la cantidad que solicitó el cliente. Por supuesto, en otras formas de realización, pueden utilizarse otros enfoques. Alternativamente un applet en la máquina puede generar visualizaciones que muestran equivalentes en efectivo local cuando se visualizan o procesan cantidades de efectivo extranjero. Esto puede incluir presentar ambas cantidades en visualizaciones presentadas a un usuario.
Como se representa en la figura 23, cuando el cliente externo ha completado sus transacciones tal como se indica a través de la pantalla táctil 30, el servidor externo 96 se encuentra operativo para enviar el mensaje "ir al origen" de vuelta a la ATM. La recepción de este mensaje se encuentra operativa de la manera descrita previamente para hacer que la parte de aplicación de dispositivo 84 opere en respuesta a las instrucciones JAVAScript embebido para configurar la parte de manipulación de documento HTML para hacer que el navegador 76 reestablezca la comunicación con el servidor de origen 90, u otra dirección de documento designada.
Como se indica en la figura 24 el applet en la parte de aplicación de dispositivo 84 que procesa el mensaje "ir al origen" se encuentra preferentemente operativo para reconectarse al servidor de origen 90 así como para enviar la información de registro de transacción en el registro 104. Esta información de registro de transacción que está empaquetada preferentemente en un objeto de datos, incluye el nombre del cliente, el nombre del organismo externo, identificador digital, información de cantidad en relación a cantidades distribuidas, transferidas o ingresadas, y todos los demás datos de transacción pertinentes. Los datos de transacción se utilizan por los applets al realizar etapas de transacción en las que se requiere alguna parte de los datos. Cuando se completa la actividad del cliente en la máquina un applet proporciona un mensaje de datos de transacción que incluye por lo menos una parte de los datos recopilados. Estos datos se comunican desde el servidor 90 a través de la CGI 106 a la oficina 94 interna del banco de origen. Esta información se almacena en la oficina interna para su utilización posterior para fines de acuerdo con el banco externo que opera el servidor externo 96. Alternativamente o adicionalmente, pueden registrarse datos de transacción en el terminal en memoria así como en copia en papel en una impresora de registro diario. Pueden almacenarse datos de transacción para la descarga en un lote o pasando objetos que incluyen datos desde muchas transacciones. Los datos de lotes pueden comunicarse en momentos y a direcciones así como pueden almacenarse en memoria en los datos de configuración de terminal.
Una ventaja de algunas formas de realización de la invención es que pueden entregarse datos de transacción a direcciones en una red de área local o en una red de área amplia tal como Internet. Esto facilita el llevar a cabo amplias variedades de transacciones y permite dirigir mensajes relacionados con la utilización de seguimiento (tal como para tarjetas inteligentes de tipo monedero electrónico) o para el acuerdo de diversos tipos de transacción para una dirección de sistema seleccionada.
Se apreciará que la forma de realización descrita de la máquina bancaria automática y sistema bancario automatizado pueden proporcionar una ventaja de que cuando la máquina está conectada a una red de área amplia tal como Internet, los clientes pueden llevar a cabo sus transacciones bancarias prácticamente en cualquier parte en el mundo. Además, a pesar de las amplias capacidades del sistema, debido a que la máquina puede monitorizarse localmente, tanto en cuanto a conexión como a actividad, se minimiza el riesgo de fraude.
Las formas de realización de la invención pueden incluir una característica adicional para facilitar el acceso a documentos en la red a la que está conectada la máquina. Esta característica se encuentra operativa para determinar si está accesible un registro HTTP tal como un documento HTML u otro artículo en una dirección para la descarga antes de que el ordenador intente acceder al registro. Esto evita los tiempos de espera que podrían producirse de otro modo como resultado de no poder acceder a un registro debido a que esté caído el servidor a través del cual se accede normalmente al registro. Otras formas de realización pueden considerar tanto el tamaño del registro como la tasa de transferencia y determinar que una velocidad de transferencia para el registro no es suficientemente rápida, de modo que debería transferirse un registro alternativo.
En una forma de realización esta característica se consigue mediante la utilización de un programa o applet separado que verifica si está activo un servidor al que el ordenador querrá acceder posteriormente. El applet opera en respuesta a la recepción de una dirección o parte de la misma, con la que se realizará una conexión. El applet opera para realizar una conexión de socket a la dirección y carga una cantidad pequeña pero suficiente del registro u opera de otro modo para determinar que el servidor a través del cual debe accederse al registro está activo. En respuesta a que el applet verifique la operación del servidor remoto, o determine de otro modo esas condiciones indicativas de que puede accederse a o cargarse el registro, el ordenador opera entonces de modo que el navegador o componente de software similar está habilitado para navegar a la dirección en el momento apropiado en la secuencia de transacción. Si el applet no puede detectar que el servidor remoto está activo, o determina que no aparece el registro al que puede accederse o cargarse satisfactoriamente, deben realizarse etapas para acceder a direcciones alternativas o para suspender la transacción. Las direcciones alternativas a las que acceder pueden basarse en datos almacenados en la memoria del terminal o pueden obtenerse accediendo a documentos o bien local o bien remotamente que incluyen datos a partir de los que pueden obtenerse o derivarse direcciones alternativas. Las direcciones alternativas se comprueban de manera similar para tomar una determinación de que puede accederse a los registros antes de que se realicen intentos de acceder a los registros alternativos. Este enfoque evita retardos al llevar a cabo transacciones.
Las formas de realización alternativas pueden emplear otros enfoques para determinar si puede accederse satisfactoriamente a y/o descargarse adecuadamente los registros HTTP deseados antes de que el navegador que proporciona la interfaz de cliente intente acceder al documento. Tales formas de realización pueden considerar al determinar si se puede acceder satisfactoriamente al documento, la velocidad de transferencia u otras condiciones relacionadas con el funcionamiento del sistema o contenido de documento. Por ejemplo, el applet que realiza pruebas para determinar que puede accederse al registro HTTP, o un applet adicional, puede determinar la tasa de transferencia a la que puede transferirse el registro al ordenador. La tasa a la que pueden transferirse los datos puede compararse con datos almacenados en memoria, y si la tasa es más lenta que los datos representativos de la tasa almacenada deseada se accede a un registro alternativo. Este puede ser por ejemplo un documento HTML almacenado localmente en la máquina. Otras formas de realización pueden incluir programas que consideran el tamaño del registro HTTP y la tasa de transferencia al determinar una velocidad de transferencia. Tales programas determinan entonces si puede transferirse el registro lo suficientemente rápido para adecuarse a los parámetros establecidos en la configuración en memoria, y si no es así, se accede a direcciones alternativas. Tales registros alternativos pueden probarse de manera similar para velocidad de transferencia antes de transferirse.
Los programas pueden considerar también otros factores al decidir acceder a una dirección particular, tales factores pueden incluir por ejemplo información de día y hora, o información de sensores tales como sensores en el suelo que indican que otras personas están esperando para utilizar la máquina. De esta forma puede evitarse el acceso a documentos que tienen salidas exhaustivas que pueden tender a prolongar las transacciones incluso cuando pueden cargarse registros a una velocidad adecuada.
Aunque la forma de realización descrita de la máquina bancaria automática y sistema bancario automatizado de la presente invención se muestra con respecto a un tipo particular de máquina que se fabrica específicamente para conectividad con redes de área local o amplia, también pueden adaptarse máquinas bancarias automáticas convencionales para incluir tal capacidad. Específicamente la parte de manipulación de documento HTML y las partes de aplicación de dispositivo pueden incluirse con otro software convencional que opera dentro de una máquina bancaria automática. Esto permite a tales ATM operar o bien en la red propietaria convencional o como parte de una red de área amplia. Adicionalmente, pueden configurarse máquinas bancarias automáticas para operar sus dispositivos a través de la parte de software de interconexión de dispositivos descrita en la presente memoria o a través de una interfaz de software diferente cuando opera en una red convencional. Tales máquinas pueden conmutar para requerir que se pasen mensajes de dispositivo a través de un servidor de dispositivo cuando opera bajo el control de un servidor dentro de la red de área amplia para mantener seguridad dentro del sistema. De esta forma una única ATM podría operar en redes propietarias de la manera de las ATM actuales así como en la configuración de red del sistema descrito en la presente memoria.
Las formas de realización alternativas de la invención operan para comunicar mensajes de transacción utilizados en una red de ATM propietaria. Esto puede llevarse a cabo utilizando una CGI en conexión con o bien la parte de manipulación de documento HTML de la ATM o bien el servidor de origen HTTP u otro servidor. La CGI opera en conexión con un programa de conversión de mensajes y base de datos para escoger los datos necesarios de los documentos HTML y mensajes de respuesta y generar los mensajes solicitud de transacción definida apropiados para la red de transacción propietaria. Asimismo, el programa de conversión de mensajes y la CGI operan para recibir menajes de orden de función desde la red propietaria y convertirlos y generar documentos HTML y/o mensajes TCP/IP apropiados para su utilización por la ATM. Debido a que estos formatos de red propietaria están definidos y los datos necesarios para producir e interpretar los mensajes son conocidos, se consigue la utilización de la ATM 12 directamente en una red de ATM propietaria convencional.
Los mensajes de transacción de ATM convencionales se definen como mensajes de distribución que no incluyen documentos HTML en mensajes HTTP. Un ejemplo de mensajes convencionales conocidos utilizados para operar una ATM son los mensajes Diebold 91X. Tales mensajes implican generalmente la transmisión de un mensaje de solicitud desde una ATM en una distribución definida que incluye datos de entrada de cliente (cuenta/pin) y una indicación del tipo y cantidad de la transacción solicitada. El mensaje de solicitud se recibe por un ordenador central de ATM que envía de vuelta un mensaje de respuesta con una distribución definida que incluye una indicación de si se autoriza la transacción. La ATM entonces devuelve otro mensaje al ordenador central que indica si la máquina pudo llevar a cabo la transacción. Los mensajes utilizados en tales redes propietarias convencionales ocupan generalmente relativamente poco ancho de banda.
Al conectar una ATM según una forma de realización de la invención a una red de este tipo, se proporciona un servidor. El servidor está en conexión funcional con una memoria que incluye una base de datos relacional que contiene datos de creación de documento y conversión de mensajes. En una configuración, el servidor está conectado a la parte de manipulación de documento a través de una red, o pueden residir en el ordenador de la ATM. El servidor produce los documentos a los que accede el navegador y que incluyen las instrucciones de dispositivo de transacción. El servidor (o un servidor conectado) comunica los mensajes convencionales al ordenador central. Un servidor puede proporcionar una interfaz para varias ATM conectadas al mismo en una LAN, o alternativamente, cada ATM puede presentar su propio servidor operando en la misma.
La capacidad de la ATM 12 para comunicarse en una red propietaria también permite el funcionamiento de la ATM de una manera en la que la interfaz se genera por un organismo de origen del usuario de la manera descrita anteriormente, pero en la que se autorizan transacciones a través de mensajes dirigidos a través de una red de ATM propietaria. Esto consigue la seguridad de utilizar la red propietaria mientras que proporciona al cliente las ventajas de la interfaz de banco de origen familiar y/o interfaz de "página de inicio personal".
En una configuración de este tipo los dispositivos de función de transacción ATM pueden operarse de una manera convencional en respuesta a mensajes de transacción de ATM tales como mensajes Diebold 91X, en la red propietaria. Los dispositivos de salida de cliente, tales como la pantalla (y altavoces si se proporcionan) se comunican a través de un navegador conectado a una red de área local o amplia. El navegador accede a documentos para preguntar a un cliente a través de la operación de una transacción, pero los documentos no incluyen instrucciones que provoquen el funcionamiento de dispositivos tales como el expendedor de efectivo.
En una configuración el navegador puede operarse por el ordenador en respuesta del estado de dispositivos en la máquina, puesto que los dispositivos se operan en respuesta a mensajes de ATM convencionales. De esta manera puede guiarse el navegador a direcciones seleccionadas, incluyendo direcciones que están asociadas con el cliente basándose en datos de entrada de cliente. Sin embargo, puesto que los documentos recibidos por el navegador no operarán los dispositivos de función de transacción, hay menos necesidad de medidas de seguridad al acceder a documentos. Como resultado, el cliente todavía puede operar la máquina en respuesta a una interfaz única y familiar, y puede presentarse información de marketing tal como publicidad u otro material en la secuencia de transacción.
En otras formas de realización las máquinas pueden realizar algunas funciones de dispositivo basándose en mensajes convencionales, aunque pueden realizarse otras en respuesta a instrucciones en documentos HTML u otros mensajes HTTP. Por ejemplo los documentos HTML pueden proporcionar datos considerables para su utilización por impresoras u otros dispositivos de salida. Algunas formas de realización pueden acceder a documentos con instrucciones, pero pueden ignorar algunos y actuar en respuesta a otros. El enfoque puede seleccionarse por el operador del sistema configurando el software en base a sus requisitos.
Una ventaja adicional de la configuración de sistema de una forma de realización preferida es que presenta flexibilidad mejorada para comunicar mensajes asociados con la ATM. El administrador de dispositivos 68 genera preferentemente mensajes de estado asociados con el estado de dispositivos 36. Estos mensajes de estado pueden representar comúnmente información acerca de condiciones que existen en los dispositivos. Tales mensajes pueden indicar que los suministros de papel para impresoras o efectivo están bajos o se han agotado. Otros mensajes pueden indicar que los dispositivos no están funcionando apropiadamente. A menudo tales mensajes indican que la ATM requiere puesta en servicio. Todos los tales tipos de mensajes se denominan en la presente memoria de manera intercambiable como mensajes de estado o fallo.
\newpage
La parte de software de interconexión de dispositivos 64 se comunica a través de la intranet 16 utilizando mensajes TCP/IP. Aunque los mensajes asociados con transacciones descritos previamente se dirigen al servidor de dispositivo 92, la parte de software 64 puede incluir un servidor y configurarse para direccionar mensajes de fallo y estado a otras direcciones en la intranet o Internet. Por ejemplo, tales mensajes de fallo o estado pueden dirigirse a una aplicación de software que entregue mensajes a un proveedor de servicio. Además, los mensajes de fallo pueden dirigirse selectivamente basándose en la naturaleza del fallo indicado. Por ejemplo, los mensajes de fallo indicativos de una necesidad de reponer efectivo o suministros pueden dirigirse a una dirección en la intranet asociada con una entidad que tiene responsabilidad de reponer los suministros. Alternativamente, los mensajes de fallo que indican una necesidad de otros tipos de puesta en servicio pueden dirigirse a una dirección asociada con una entidad que puede proporcionar el tipo de puesta en servicio requerida.
Alternativamente, la distribución selectiva de mensajes de fallo a direcciones en la intranet 16 puede llevarse a cabo configurando apropiadamente el servidor de dispositivo 92. Adicionalmente, o bien la parte de software 64 o bien el servidor de dispositivo 92 puede dirigir mensajes de fallo desde las ATM a un sistema de tratamiento de fallos tal como un ordenador que opera el software Event Management System^{TM} disponible de Diebold, Incorporated. Tal software se encuentra operativo para resolver la naturaleza de la condición de fallo y para notificar al personal apropiado la acción correctiva que ha de tomarse.
La ATM 12 puede incluir además una función de software para ayudar en problemas de diagnóstico y proporcionar servicio de recuperación. Como se representa gráficamente en la figura 2, formas de realización alternativas de la ATM 12 pueden incluir un servidor mini-HTTP 109 que está en comunicación con la parte de software de interconexión de dispositivos 64. El servidor 109 está configurado para recibir mensajes de estado de dispositivo y para producir registros HTTP que incluyen documentos HTML en respuesta a los mismos, que proporcionan datos representativos del estado de dispositivo a un dispositivo de diagnóstico 110 tal como un terminal de ordenador de mano. El servidor 109 incluye una CGI para la interconexión con el software de dispositivo de modo que un técnico puede acceder a la información en los registros accesibles en las direcciones HTTP relacionadas con mensajes de estado e introducir instrucciones de prueba y correctivas a través del dispositivo de diagnóstico 110. Los registros HTTP y/o documentos HTML generados por el servidor 109 pueden incluir preferentemente instrucciones gráficas y de audio indicativas de condiciones tales como problemas, así como datos de acción correctiva e instrucciones de reparación.
En versiones alternativas de la invención las funciones del mini-servidor HTTP 109 pueden residir en el servidor de dispositivo 92. Esto puede particularmente apropiado si la función del servidor de dispositivo reside en el ordenador en la ATM. Independientemente de donde resida la función la utilización de las componentes visual o de audio de documentos HTML asociados con mensajes de mantenimiento y diagnóstico facilita la puesta en servicio de la ATM.
Estos registros entregados a través del mini-servidor HTTP incluyen instrucciones que corresponden a las condiciones de estado o fallo. Puede accederse a tales registros o documentos localmente como se comentó anteriormente, o de manera remota. Un técnico que utiliza un ordenador de mano que incluye un navegador u otro software operativo para acceder a los registros HTTP puede acceder a los documentos localmente para fines de mantenimiento, diagnóstico y puesta en servicio. En algunas situaciones la interfaz de cliente y el navegador asociado con la misma pueden utilizarse para acceder al mini-servidor HTTP, o un puede utilizarse un navegador separado, dispositivos de visualización y entrada en la máquina y destinados para su utilización en actividad de puesta en servicio. Alternativamente, los mensajes de fallo y estado pueden monitorizarse desde terminales en ubicaciones en cualquier lugar que están conectados en la red. Los mensajes de estado y fallo de manipulación de mini-servidor también pueden configurarse para enviar un correo electrónico o mensaje similar a una dirección seleccionada siempre que exista una condición o grupo de condiciones particulares.
Una ventaja adicional de esta característica es que también pueden enviarse mensajes HTTP al mini-servidor HTTP para intentar corregir problemas. Tales mensajes pueden incluir ejecutar pruebas de diagnóstico y recibir resultados. También pueden incluir operar dispositivos para probar o intentar despejar atascos y otros funcionamientos incorrectos. Esto puede realizarse a menudo desde ubicaciones remotas. Por supuesto, cuando hay un riesgo significativo de acceso no autorizado al servidor que maneja mensajes por defecto o de dispositivo, deberían tomarse medidas de seguridad apropiadas.
Los registros HTTP que indican el estado de los dispositivos de función de transacción pueden presentar diferentes formas dependiendo de la configuración de software y las necesidades del operador del sistema. En algunas formas de realización la información de estado de dispositivo para uno o más dispositivos puede representarse mediante marcas contenidas dentro de un objeto de datos. El objeto de datos puede transferirse a otros ordenadores conectados para proporcionar los datos de estado. La transferencia del objeto de datos puede llevarse a cabo por ejemplo mediante invocación de procedimiento remota (RMI). Los datos en el objeto de datos transferido pueden utilizarse entonces para generar un mensaje y/o salidas deseados por el operador del sistema. Esta técnica puede ser particularmente útil cuando el operador desea conectar la máquina a un sistema de monitorización existente y pueden utilizarse marcas incluidas en el objeto de datos para generar salidas o mensajes indicativos del estado de dispositivo que pueden procesarse por el sistema existente. Pueden utilizarse adicionalmente plug-ins para conseguir la comunicación entre máquinas de transacción y sistemas de monitorización existentes que presentan diferentes tipos de condiciones de estado o diferentes tipos de formatos de mensaje. Esto incluye máquinas que presentan diferentes tipos de dispositivos de función de transacción y capacidades.
La técnica de transferir un objeto de datos puede utilizarse también para llevar a cabo prueba o modificación de dispositivos de función de transacción. Por ejemplo, pueden modificarse marcas en el objeto de datos por un empleado de puesta en servicio y pasarse el objeto de vuelta a la máquina. El software en la máquina puede hacer que los dispositivos de función de transacción operen o cambien condiciones o se programen en respuesta al objeto de datos modificado. Esto puede incluir por ejemplo borrar una indicación de fallo o hacer que un dispositivo opere para despejar un atasco o para realizar una prueba. Los resultados de tal actividad pueden reflejarse en marcas modificadas en el objeto de datos que puede transferirse entonces al ordenador en el terminal de diagnóstico. Por supuesto, los enfoques comentados en la presente memoria se proporcionan a título de ejemplo y otros enfoques se pondrán de manifiesto para los expertos en la materia a partir de la descripción en la presente memoria.
La figura 25 muestra una vista esquemática de una configuración de red para una forma de realización alternativa de la máquina bancaria automática.
La forma de realización mostrada en la figura 25 incluye una máquina bancaria automática adaptada específicamente para operar en conexión con sistemas de máquina bancaria automática convencionales tales como sistemas que operan utilizando formatos de mensaje de ATM Diebold 91 X u otros formatos convencionales distintos a HTTP. Un ordenador central 120 es un ordenador central de ATM convencional que se comunica utilizando tales mensajes. El ordenador central se comunica con un servidor de interfaz indicado esquemáticamente por 122. El servidor de interfaz 122 opera de la manera comentada anteriormente y está en conexión funcional con una memoria que incluye la información necesaria para convertir mensajes HTTP que pertenecen a una solicitud de transacción para un mensaje de solicitud 91 X u otro mensaje convencional, que puede manejarse por el ordenador central 120. Asimismo el servidor de interfaz 122 y las instrucciones y datos almacenados en memoria se encuentran operativos para convertir un mensaje de orden 91 X convencional u otro mensaje de orden convencional del ordenador central 120 en mensajes HTTP que pueden utilizarse por la máquina bancaria automática para llevar a cabo la orden. De manera similar el servidor de interfaz 122 se encuentra operativo para recibir los mensajes HTTP que corresponden a la respuesta de la máquina bancaria automática a las órdenes y para producir un mensaje de respuesta 91X u otro mensaje de respuesta convencional para el ordenador central. Al llevar a cabo estas funciones el servidor de interfaz se comunica con una interfaz cliente 124 que en la forma de realización preferida es un plug-in COMM en el que opera el terminal de máquina bancaria bajo un entorno operativo Windows NT®. El servidor de interfaz 122 incluye también una pasarela 126 de orden/estado. La pasarela de orden/estado se encuentra operativa para recibir mensajes de orden y estado desde las partes de software que manejan los dispositivos funcionales dentro de la máquina. Los mensajes referentes a los dispositivos se utilizan al producir mensajes de transacción para enviar de vuelta al ordenador central 120. Adicionalmente, la parte de pasarela de orden estado también produce mensajes de estado indicativos del estado de dispositivos que también pueden comunicarse al ordenador central.
El servidor de interfaz 122, la parte de pasarela de orden estado 126 y la interfaz cliente 124 pueden residir en software en el terminal de máquina bancaria automática. En esta configuración el terminal parece ser para el ordenador central una máquina convencional. Alternativamente el servidor de interfaz 122 y la parte de pasarela de orden estado 126 pueden residir en un servidor separado, mientras que la parte de interfaz cliente 124 puede residir en el terminal. Esto permite al servidor de interfaz 122 manejar varias máquinas bancarias automáticas conectando las máquinas al servidor de interfaz a través de una red.
La configuración alternativa del sistema de máquina bancaria automática mostrado en la figura 25 está adaptada particularmente para su utilización en conexión con sistemas de ATM existentes. La máquina incluye una parte de manipulación de documento HTML 128 que incluye un navegador que opera de la manera de las formas de realización descritas anteriormente. Se hace referencia a la parte de manipulación de documento HTML alternativamente como un navegador en la presente memoria para fines de simplicidad. La parte de manipulación de documento HTML opera en conexión con una red 130 para acceder a registros HTTP en la forma de documentos HTML a través de los servidores 132, 134 y 136. Para fines de este ejemplo el servidor 132 se considerará el servidor del banco de origen que opera la máquina bancaria automática. La parte de navegador 128 está habilitada para acceder a documentos de su banco de origen para fines de obtener contenido e instrucciones para fines de emitir información a clientes así como para operar dispositivos en la máquina. Los servidores 134 y 136 son representativos de otros servidores a los que se puede indicar que acceda la máquina bancaria automática para fines de descargar documentos que incluyen información o instrucciones. A menudo tales documentos desde servidores que no son del banco de origen incluirán información que va a presentarse a clientes tales como publicidad, material promocional, cotizaciones de acciones u otros tipos de información. Debe entenderse que los servidores 134 y 136 pueden conectarse directamente a una red 130 o puede accederse a ellos a través de otras redes y servidores. En algunas formas de realización puede accederse a tales servidores a través de Internet para fines de proporcionar documentos a la máquina bancaria automática.
La parte de manipulación de documento 128 incluye una parte de software de teatro de terminal indicada esquemáticamente por 138. La parte de teatro de terminal 138 se muestra esquemáticamente con mayor detalle en la figura 26. La parte de teatro de terminal 138 incluye un marco de zona entre bastidores 140 y un marco de teatro 142. El marco de zona entre bastidores 140 aunque reside en el navegador, no es visible en la pantalla de la máquina bancaria automática. El marco de teatro 142 es un marco visible y controla lo que se muestra al cliente.
Como se representa esquemáticamente en la figura 25 la parte de manipulación de documento HTML incluye también una parte de controlador de terminal 144. La parte de controlador de terminal incluye controladores que son instancias relacionadas de applets que se utilizan al llevar cabo tipos de transacciones particulares. Los controladores de terminal generalmente corresponden a la operación de los applets de JAVA en la forma de realización descrita anteriormente.
La máquina bancaria automática de la forma de realización alternativa incluye además una aplicación de servicios de transacción (TSA, Transaction Services Application) indicada esquemáticamente por 146. La aplicación de servicios de transacción proporciona seguridad, condición del terminal, autorización del terminal y servicios de administración de claves dentro de la máquina bancaria automática. La aplicación de servicios de transacción incluye una función para comunicar mensajes HTTP con el servidor de interfaz 122. La aplicación de servicios de transacción también puede comunicarse a través de una red tal como red 130 de una manera explicada posteriormente. La aplicación de servicios de transacción también proporciona una función de servidor que permite a la aplicación de servicios de transacción llevar a cabo las funciones del servidor de dispositivo 92 en la forma de realización descrita
anteriormente.
La máquina bancaria automática de la forma de realización alternativa incluye además interfaces de dispositivo común JAVA indicadas esquemáticamente por 148. Las interfaces de dispositivo común JAVA en la forma de realización preferida son instancias relacionadas de applets que controlan y coordinan el funcionamiento de los dispositivos funcionales 150 de las máquinas que realizan funciones de transacción. Los dispositivos funcionales pueden incluir dispositivos de los tipos descritos en conexión con la forma de realización anterior u otros tipos de dispositivos que operan para llevar a cabo una función relacionada con una transacción. Las interfaces de dispositivo común JAVA 148 se comunican con los dispositivos funcionales a través interfaces de dispositivo común representadas esquemáticamente por 152. Las interfaces de dispositivo común (CDI, Common Device Interfaces) proporcionan una interfaz que controla los módulos electromecánicos en los dispositivos funcionales incluidos en la máquina bancaria automática. Las interfaces de dispositivo común se muestran esquemáticamente en conexión con un servidor de diagnóstico 154. El servidor de diagnóstico opera de una manera similar al servidor 109 de la forma de realización descrita anteriormente. El servidor de diagnóstico 154 es útil para diagnosticar el estado y para corregir problemas con los dispositivos en la máquina bancaria automática.
Haciendo referencia de nuevo a la figura 26 el marco de zona entre bastidores 140 dentro de la parte de teatro de terminal 138 es un componente llamado el applet de zona entre bastidores 156. El applet de zona entre bastidores 156 es preferentemente un componente relativamente sencillo. Las instrucciones denominadas como script incluidas en documentos a los que se accede por el navegador hacen selectivamente que el applet de zona entre bastidores notifique a un controlador de terminal cuando ha de tener lugar una acción en respuesta a las instrucciones incluidas en el documento al que se ha accedido. El applet de zona entre bastidores también opera para solicitar que se acceda a un nuevo documento HTML. El applet de zona entre bastidores también proporciona acceso al objeto de datos de transacción compartido comentado previamente que contiene datos de transacción.
El marco de teatro 142 controla la interfaz de usuario como se ve por el usuario del terminal de máquina bancaria automática. El cliente HTML representado esquemáticamente por 158 en el marco de teatro 142 define las marcas de identificación asociadas con eventos enviados a un administrador controlador a través del applet de zona entre bastidores y proporciona una interfaz para los procedimientos públicos del administrador controlador. El administrador controlador indicado esquemáticamente por 160 en la figura 26, tiene una clase que reside en la aplicación de servicios de transacción (TSA) 146 tal como se muestra. La clase administrador controlador que reside en el proceso TSA se encuentra operativa para cargar los controladores de terminal 144 a la parte de manipulación de documento HTML. El administrador controlador también incluye una clase applet de zona entre bastidores que reside en el marco de zona entre bastidores 140. La clase applet de zona entre bastidores del administrador controlador proporciona una interfaz para el cliente HTML para realizar solicitudes en el administrador controlador. Las instrucciones en documentos HTML pueden pasar eventos a través del applet de zona entre bastidores 156 al administrador controlador. Tales eventos incluyen una solicitud para autorizar una transacción. Tales solicitudes pueden incluir también indicaciones de que el cliente ha completado una transacción o de que un documento cargado por el navegador incluye instrucciones que solicitan que se termine la sesión. Otros eventos que pueden pasarse a través del administrador controlador incluyen eventos de impresión. Otros eventos que pueden pasarse a través del applet de zona entre bastidores al administrador controlador incluyen una indicación de que se canceló una entrada, u otros eventos de usuario definidos.
En respuesta a recibir eventos el administrador controlador de la forma de realización mostrada responde a instrucciones en documentos a los que se accede mediante el navegador para realizar funciones que incluyen cambiar el contenido del marco de teatro 142. El administrador controlador en respuesta a tales instrucciones, también cambia la clase controlador de terminal activa. El administrador controlador también almacena en memoria caché las clases controlador de terminal para su utilización posterior o carga las clases controlador de terminal y documentos HTML de una lista de servidores disponibles. El administrador controlador también proporciona acceso al objeto de datos de transacción compartido que contiene datos de transacción para una transacción particular. El administrador controlador también envía eventos de teatro de terminal a la clase control de zona entre bastidores del controlador de terminal actual y proporciona un temporizador de tiempo de espera de pantalla. Por supuesto en otras formas de realización el controlador de terminal puede llevar a cabo otras funciones.
En el funcionamiento de la forma de realización alternativa mostrada en la figura 25 los controladores de terminal 144 en la aplicación de servicios de transacción 146 permiten selectivamente acceder a documentos con la parte de manipulación de documento HTML 128. Los documentos a los que se accede pueden incluir instrucciones que se utilizan para operar la máquina bancaria automática y los dispositivos funcionales en el mismo. La aplicación de servicios de transacción 146 se encuentra operativa además para comunicar los mensajes HTTP que se pasan al servidor de interfaz 122 y que se utilizan para generar mensajes de ATM convencionales que pueden manejarse por el ordenador central 120. La dispensación de efectivo y otras transferencias de valor se llevan a cabo en respuesta la aprobación desde el ordenador central 120, mientras que la interfaz y otras funciones se controlan a través de instrucciones en documentos a los que se accede a través del navegador.
En una forma de realización preferida la ATM u otra máquina de transacción se comunica con el ordenador central de ATM convencional para pasar el objeto de datos de transacción entre el ordenador en la ATM y el servidor de interfaz. Esta transferencia se lleva a cabo preferentemente mediante la característica de invocación de mensajes remota (RMI) de software tal como JAVA. Por supuesto pueden utilizarse otros procedimientos para transferir el archivo de objeto de datos utilizando HTTP.
Como se comentó anteriormente, el objeto de datos de transacción contiene datos de transacción. La máquina adquiere datos pertinentes para la transacción tales como datos de cuenta a partir de una tarjeta, un número PIN del cliente, transacción/transacciones solicitada(s) y cantidad(es), e incluye estos datos entre los datos de transacción.
Una vez que los datos necesarios para generar una transacción de ATM convencional se representan en los datos de transacción, el objeto de datos se transfiere al servidor de interfaz. El servidor de interfaz se encuentra en conexión funcional con una base de datos 123 u otro elemento que contiene datos de conversión como se indica esquemáticamente. Los datos de conversión se utilizan por el software asociado con el servidor para generar un mensaje de solicitud de transacción de ATM convencional para el ordenador central 120. El mensaje convencional puede formatearse como un mensaje 91X convencional u otro mensaje de transacción distinto de HTTP convencional.
Tras el procesamiento el ordenador central 120 responde con un mensaje de respuesta convencional. Los componentes del mensaje de respuesta se reciben en el servidor y se procesan en respuesta a los datos de conversión para producir datos de transacción modificados en el objeto de datos. Estos datos de transacción modificados incluyen preferentemente datos indicativos de si se autoriza o deniega la transacción solicitada, así como otros datos. Por ejemplo, si se deniega la transacción puede incluir datos que sean indicativos del motivo para la denegación.
El objeto de datos de transacción con los datos de transacción modificados se transfiere entonces al ordenador que opera la ATM mediante RMI u otro procedimiento de transferencia. La aplicación de servicios de transacción 146 que opera en el software recibe el objeto de datos y opera los dispositivos de función de transacción en respuesta a los datos de transacción modificados. El objeto de datos de transacción presenta los datos de transacción en el mismo modificados adicionalmente por la inclusión de información relativa a funcionamiento de los dispositivos. Tras haber operado los dispositivos, el objeto de datos de transacción con los datos de transacción modificados adicionalmente se pasa de vuelta al servidor de interfaz 122. Los datos de transacción modificados se utilizan entonces para generar un mensaje para el ordenador central de ATM. El mensaje para el ordenador central incluye datos correspondientes a los datos de transacción modificados. Normalmente este mensaje es un mensaje de finalización distinto de HTTP convencional que indica si se llevó a cabo satisfactoriamente la transacción por los dispositivos de función de transacción.
El formato de los mensajes de transacción convencionales distintos a HTTP puede cambiarse fácilmente en la forma de realización descrita. Esto puede conseguirse a través de la utilización de plug-ins. Los plug-ins se encuentran operativos para colocar datos dentro de, y para extraer datos desde, el objeto de datos de transacción. El plug-in consigue la conversión entre los datos de transacción y mensajes convencionales distintos a HTTP deseados. La utilización de plug-ins permite utilizar más fácilmente la ATM de la forma de realización descrita en conexión con tipos variados de redes de transacción convencionales.
Los datos de transacción en el objeto de datos de transacción se encuentran preferentemente operativos también para hacer que el ordenador opere el navegador para acceder a documentos HTML seleccionados. Esto puede hacerse para indicar que la transacción se autoriza o deniega, así como para acceder a documentos específicos en respuesta a componentes del mensaje. Por ejemplo, pueden concederse a los clientes de bancos diferentes del que opera la ATM ciertas promociones que no se presentan a los clientes existentes del banco. Los datos de transacción indicativos de porqué se deniega una transacción pueden utilizarse para acceder a documentos que proporcionan una explicación, o pueden animar al cliente a realizar otra acción, tal como realizar un anticipo de efectivo en una tarjeta de crédito o pedir un préstamo.
El sistema mostrado esquemáticamente en la figura 25 es un ejemplo de un sistema de máquina bancaria automática que consigue la amplia variedad de opciones de interfaz disponibles a través de la utilización de una interfaz HTML mientras mantiene la compatibilidad con sistemas de máquina bancaria existentes y las técnicas de seguridad asociadas con los mismos. Por supuesto en otras formas de realización pueden utilizarse enfoques y configuraciones alternativos.
Una ventaja adicional incorporada en el sistema que se representa esquemáticamente en la figura 25 es la capacidad para operar los componentes de software de la forma de realización descrita de la presente invención en máquinas bancarias automáticas existentes. Como se apreciará, la manipulación de documentos HTML en ordenadores convencionales requiere entradas a través de un teclado de tipo QWERTY así como clics de ratón en ubicaciones correspondientes a iconos u otras características en documentos HTML para navegar y utilizar tales documentos satisfactoriamente. Las máquinas bancarias automáticas convencionales generalmente no incluyen un ratón o teclado completo. Más bien las máquinas bancarias automáticas convencionales incluyen generalmente un teclado alfanumérico similar al que se utiliza en teléfonos, así como teclas de función. Las formas de realización de la presente invención permiten que la operación del sistema con terminales que tienen tales interfaces se realice de una manera que logre beneficios tal como se describe en cualquier otro lugar.
La figura 27 muestra un ejemplo de una interfaz de máquina bancaria automática convencional 162. La interfaz 162 incluye un dispositivo de salida que incluye una pantalla 164. La pantalla 164 puede ser un CRT, LCD u otra pantalla de visualización convencional. En la forma de realización mostrada la pantalla 164 no es una pantalla táctil como en la forma de realización descrita anteriormente. Una pluralidad de teclas 166 de función están dispuestas en ubicaciones adyacentes a la pantalla 104. Un teclado numérico 168 se incluye también en la interfaz 162. El teclado numérico 168 incluye teclas alfanuméricas así como ciertas otras teclas dedicadas tales como "cancelar", "corregir" y "ok". Otras teclas en el teclado numérico están generalmente en blanco pero en algunos casos pueden utilizarse.
En la operación de una máquina bancaria automática convencional, los datos de pantalla que se generan a partir de información almacenada en la memoria del terminal producen pantallas de transacción definidas que se presentan gráficamente en la pantalla 164. Las pantallas aparecen en una secuencia en respuesta a la función de transacción seleccionada por el cliente. Las pantallas convencionales también incluyen generalmente texto o gráficos representativos de selecciones que el cliente puede hacer. Estas opciones de texto o gráficas incluyen generalmente líneas u otras marcas que se extienden hasta los bordes de la pantalla adyacentes a una de las teclas 166 de función. Se permite a un usuario seleccionar las opciones presionando la tecla de función a la que apunta la selección. Asimismo en la operación de la máquina bancaria automática se permite a un usuario introducir los caracteres alfanuméricos que comprenden el número PIN así como información de cantidades numéricas y otras instrucciones presionando las teclas en el teclado numérico 168.
En una forma de realización de la presente invención el software operado en la máquina bancaria automática opera para convertir entradas de teclas de ATM estándar a eventos de sistema operativo tal como un clic de ratón en una ubicación deseada o una entrada desde un teclado de tipo QWERTY. Los componentes de software que permiten llevar a cabo esta función se muestran en las figuras 28 a 30. Estas funciones incluyen un applet de teclado numérico 170. El applet de teclado numérico 170 en la forma de realización descrita se incluye entre los applets en los controladores de terminal 144. El applet de teclado numérico 170 soporta un subconjunto de la funcionalidad de la interfaz de dispositivo común (CDI, Common Device Interface) del teclado.
El applet de teclado numérico 170 se coordina con un servidor de órdenes de teclado que opera en la aplicación de servicios de transacción 146. El servidor en la aplicación de servicios de transacción se comunica con la interfaz de dispositivo común para el teclado numérico y teclas de función, indicados esquemáticamente por 172. La CDI de teclas en la forma de realización preferida es un programa JAVA que se denomina como un envoltorio para la interfaz de dispositivo común asociada con las teclas de función y el teclado numérico.
El software incluye además un programa mapeador de teclado indicado esquemáticamente por 174. El mapeador de teclado en la forma de realización preferida está en conexión con una base de datos 176 que almacena una pluralidad de configuraciones de mapeo. En la forma de realización preferida el mapeador de teclado es una extensión de la clase teclado de objetos utilizada para operar el teclado. El mapeador de teclado opera para almacenar configuraciones de mapas de teclas en la base de datos 176. Esto se lleva a cabo leyendo la información en una base de datos de configuración para la ATM para obtener los mapas de teclas que se operan en la máquina particular. Durante la operación, el mapeador de teclado selecciona uno de los mapas de teclas como la configuración actual. Esto se hace en respuesta al applet de teclado numérico y se basa en instrucciones en registros HTTP a los que se accede selectivamente. El mapeador de teclado puede seleccionar mapas de teclas en respuesta a instrucciones en documentos HTML cargados a través del navegador. El mapeador de teclado se encuentra también operativo para habilitar al teclado numérico y teclas de función apropiados para la configuración de mapa particular seleccionada. El mapeador de teclado se encuentra además operativo en respuesta a la configuración de mapa seleccionada para traducir una señal de entrada de teclado numérico o una señal de entrada de tecla de función a una señal de entrada de teclado o ratón respectiva que se entrega entonces al flujo de entrada del teclado o el flujo de entrada del ratón del sistema operativo del ordenador en que opera el software.
En la forma de realización preferida las configuraciones de mapa están compuestas cada una por tablas hash. Los objetos de mapa de teclas se almacenan como valores en las tablas hash de tal manera que cada objeto incluye los valores y operaciones necesarios para convertir cualquier evento de tecla de ATM apropiado a un evento de entrada de sistema operativo.
Como puede apreciarse en el caso de teclas de función adyacentes a la pantalla del ATM puede ser deseable para proporcionar una entrada de ratón al flujo de entrada del ratón que corresponde a una ubicación de coordenadas particular para la entrada de ratón. El mapeador de teclado proporciona esto utilizando la configuración de mapa de teclas seleccionada. Las diversas configuraciones de mapa de teclas permiten a las diferentes teclas de función proporcionar diferentes tipos de entradas al sistema operativo informático en respuesta al documento HTML visualizado en el navegador. Además el mapeador de teclado hace que la pulsación de una tecla seleccionada produzca una entrada correspondiente a un clic de ratón en una posición de coordenadas x,y seleccionada en la pantalla. Debe entenderse que o bien las teclas de teclado numérico o bien las teclas de función pueden utilizarse para producir entradas de ratón. Asimismo las entradas de tecla de función pueden convertirse a entradas de teclado. Sin embargo, en algunas formas de realización será deseable deshabilitar el indicador de ratón en la pantalla de tal manera que el usuario no perciba un icono de ratón habitual. Tal deshabilitación puede incluir en algunas formas de realización reducir el tamaño del icono de ratón de tal manera que sea tan pequeño que no pueda verse fácilmente por un usuario de la máquina.
Durante partes de algunas transacciones puede ser innecesario que el usuario presione ninguna tecla. En tales situaciones algunas formas de realización preferidas de la invención operan para deshabilitar las teclas de teclado numérico y/o teclas de función. Debido a que los recursos del ordenador se utilizan sondeando tales teclas para entradas, el cese de tal sondeo durante los tiempos apropiados permite que los recursos del ordenador se dediquen a llevar a cabo otras funciones. Esto aumentará la velocidad con la que pueden llevarse a cabo otras actividades. Esto puede llevarse a cabo en algunas formas de realización por el applet de teclado numérico que opera para eliminar los dispositivos de tecla de una lista de sondeo.
Las figuras 28 a 30 incluyen representaciones esquemáticas de ejemplos de la operación del mapeador de teclado y el applet de teclado numérico. La figura 29 muestra un ejemplo de una entrada al teclado numérico 168. En este ejemplo el applet de teclado numérico 170 generalmente en respuesta a instrucciones en un registro HTTP tal como un documento HTML u otros eventos, transmite y permite eventos para la aplicación de servicios de transacción 146. En respuesta se selecciona una configuración de mapa de la base de datos 176 correspondiente al nombre de mapa particular. El servidor de órdenes de teclado se encuentra operativo además para habilitar las teclas apropiadas de la ATM.
En este ejemplo, en respuesta al que el cliente presione la tecla "OK" en el teclado numérico el CDI genera una señal apropiada a la aplicación de servicios de transacción. Como se observará a partir de la figura 27 se hace referencia por convención a una tecla "OK" como la tecla "J" de la interfaz del ATM. La aplicación de servicios de transacción transmite la señal generada por la presión de la tecla "J" por el cliente al mapeador de teclado 174. En respuesta a recibir la señal, el mapeador de teclado opera para resolver el objeto en la configuración de mapa correspondiente al nombre de mapa que convertirá la señal de entrada de tecla de función a una señal de entrada de teclado que se reconozca por el sistema operativo. Llamando al objeto seleccionado desde la configuración de mapa, se produce y entrega una señal de entrada de teclado al flujo de teclado del ordenador. Esto se representa por el flujo de teclado 178. En la forma de realización mostrada el flujo de teclado es una entrada al sistema operativo Windows NT®. El applet de teclado numérico 170 opera para detectar la entrada a través de su correspondiente dispositivo de escucha de teclas. El applet 170 se encuentra operativo también para recibir el evento y puede operar para visualizar un icono u otro gráfico correspondiente a lo que el cliente ha introducido.
La figura 28 muestra la operación del mapeador de teclado en situaciones en las que la aplicación de servicios de transacción opera para impedir transmitir los datos introducidos por el cliente al applet 170. Esto puede ser deseable por ejemplo, en situaciones en las que la entrada por el cliente es el PIN del cliente u otros datos que no han de visualizarse. En estas circunstancias la aplicación de servicios de transacción 146 opera para mantener los datos introducidos por el cliente y enviar solamente una señal representativa de un carácter comodín, en este caso un símbolo "*" de vuelta al navegador. Esto se hace selectivamente en respuesta a las instrucciones contenidas en documentos a los que se accede por el navegador o en otros registros HTTP a los que se accede por el ordenador que indica que la entrada por el cliente corresponde a su PIN u otros datos que no han de enviarse al navegador. En el ejemplo mostrado en la figura 28 solamente se pasa el carácter comodín a través del mapeador de teclado al navegador. En situaciones en las que el registro HTTP al que se accede invoca procedimientos en los que han de enviarse valores numéricos al navegador y/o visualizarse en la pantalla (tales como la cantidad de una transacción de retirada) la señal enviada por la aplicación de servicios de transacción al navegador es indicativa del valor numérico asociado con la tecla presionada.
La figura 30 es un ejemplo adicional de la operación del mapeador de teclado, en este caso la entrada corresponde a una tecla 166 de función. En este caso la entrada se provoca presionando la tecla de función "A" que se muestra adyacente a la esquina superior derecha de la pantalla como se muestra en la figura 27. La señal generada en respuesta a presionar la tecla de función se pasa al mapeador de teclado que en respuesta a los datos obtenidos desde el almacenamiento 176 de datos envía una entrada de ratón correspondiente a un clic de ratón. La entrada de ratón incluye datos representativos de las coordenadas x e y en la pantalla donde ha de proporcionarse el clic de ratón. Esta señal de entrada de ratón se pasa a la entrada del flujo de ratón representada esquemáticamente en 180.
Como se apreciará para permitir a la máquina bancaria automática que procesa documentos HTML operar utilizando una interfaz de ATM convencional la entrada de ratón incluirá generalmente ubicaciones de coordenadas que corresponden a una ubicación en la pantalla adyacente a la tecla de función particular. Esto es porque el icono, línea, texto u otras marcas que el cliente selecciona presionando la tecla aparecerá o se ampliará preferentemente en la pantalla adyacente a la tecla. De esta forma el cliente es consciente a través de la presentación visual de qué tecla presionar para realizar una selección correspondiente. Varias teclas de función adyacentes a la pantalla pueden estar operativas en un momento cualquiera. El cliente puede realizar selecciones presionando una tecla de función en una ubicación y luego una tecla de función en otra ubicación dispuesta a partir de la primera posición. Esto dará como resultado que se envían señales al flujo de ratón correspondientes a clics de ratón en coordenadas en la pantalla adyacentes a los botones de función presionados por el cliente. Durante las transacciones pueden estar operativas diversas combinaciones de teclas de función y teclado numérico y amalearse con diversas entradas de teclado y ratón tal como determinen las configuraciones de mapa seleccionadas. Adicionalmente los desarrollares pueden desarrollar configuraciones de mapa especiales correspondientes a los gráficos particulares en los documentos HTML que se visualizan.
\newpage
De la manera anterior las entradas de teclado numérico a una ATM convencional u otro teclado numérico de máquina bancaria automática pueden traducirse a entradas de teclado o ratón convencionales que pueden identificarse y procesarse en un flujo de entrada del teclado o flujo de entrada del ratón convencionales para un ordenador. Asimismo las teclas de función pueden traducirse a entradas de ratón en ubicaciones seleccionadas y entregarse al flujo de entrada del ratón para su procesamiento por el ordenador o pueden convertirse a entradas de teclado y entregarse al flujo de entrada del teclado. Una ventaja adicional de la configuración de terminal descrita es que las teclas pueden deshabilitarse selectivamente excepto cuando son necesarias. Esto puede reducir los casos en que se intenta acceder de forma inapropiada a la máquina presionando teclas en el teclado. Además como se comentó anteriormente pueden también tomarse etapas para deshabilitar teclas cuando éstas no son necesarias para aumentar las velocidades de procesamiento de transacción.
Otra ventaja adicional que puede obtenerse con algunas formas de realización de la presente invención es la capacidad de la máquina bancaria automática para proporcionar documentos impresos basándose en instrucciones en documentos HTML. Tales artículos impresos pueden incluir entradas, cheques de viaje, giros postales, cheques bancarios, vales u otros tipos de documentos. La capacidad de las formas de realización preferidas para acceder a y procesar documentos HTML permite la impresión de gráficos y otras marcas que pueden producir documentos impresos que tienen características de apariencia seleccionadas y diseños decorativos seleccionados. Esto puede reducir la necesidad de utilizar formularios preimpresos y también permite la impresión de una mayor variedad de formatos impresos. Además la configuración de algunas formas de realización de la máquina permite imprimir solamente partes seleccionadas de información de transacción para fines de mantenimiento de registros dentro de la máquina mientras se proporcionan versiones que incluyen gráficos mejorados u otras características atractivas para los clientes.
La figura 31 es una representación esquemática de la operación del sistema al imprimir formularios utilizando una impresora en una máquina de transacción automatizada. La forma preferida de la invención utiliza los servicios de impresión WIN32 que operan bajo Windows NT® 4.0. En la transacción a modo de ejemplo mostrada, la clase 180 administrador controlador que opera en la parte de teatro de terminal 138 inicia una transacción de impresión de comprobante solicitando a un controlador de impresora 182 imprimir un comprobante. El controlador de impresora en una forma de realización preferida es una recopilación de instancias de JAVA beans relacionados que operan para llevar a cabo las actividades de impresión, y es uno de los controladores entre los controladores de terminal 144. El controlador de impresora incluye una clase impresión que se muestra esquemáticamente por separado que se encuentra operativa para invocar un procedimiento de imprimir URL. La clase impresora en la forma de realización preferida incluye acceso al objeto de datos de transacción compartido que incluye la información específica del cliente en relación a la transacción que incluye marcas representativas de información que ha de imprimirse. En el caso de una máquina bancaria automática esto puede incluir por ejemplo información representativa de marcas que se lee des una tarjeta del cliente introducida a la máquina y leída por un lector de tarjetas. Esto incluiría por ejemplo el nombre y número de cuenta del cliente. La otra información de transacción puede incluir los tipos de transacciones realizadas tales como un ingreso, retirada o consulta así como la cantidad implicada en cada transacción respectiva.
La aplicación de servicios de transacción 146 recibe la solicitud de impresión y pasa la cadena URL al objeto impresora WIN 184 mediante el procedimiento imprimir URL. La dirección URL en una forma de realización preferida es la dirección de un registro HTTP tal como un documento HTML que se utilizará para formatear el documento que ha de imprimirse, en este caso un comprobante. Este documento HTML contiene el JAVAScript embebido que procesa datos de transacción a partir del objeto de datos de transacción. La dirección URL del documento puede estar en una máquina local o puede recuperarse desde otro servidor tal como a través de una red indicada esquemáticamente por 186. La red 186 puede ser una red de área local o una red de área amplia dependiendo de la configuración de la máquina.
El objeto impresora WIN 184 a continuación navega a la dirección del documento al que ha de accederse. Esto se hace en la forma de realización preferida utilizando el control ActiveX C Web Browser2 de Microsoft. Cuando se ha cargado el documento HTML el control ActiveX empieza automáticamente a procesar el contenido del documento al que se ha accedido. La aplicación de servicios de transacción 146 invoca el procedimiento imprimir URL del objeto impresora WIN 184. El objeto impresora WIN utiliza el control ActiveX para imprimir el documento HTML actual. Esta impresión se procesa mediante la cola de impresión y componentes gráficos de Windows NT®.
La CDI JAVA recibe un evento desde el componente 192 monitor de impresión que indica la finalización del envío a la cola de impresión. Esto indica que un archivo está ahora disponible para leerse y enviarse a la interfaz de dispositivo común (CDI) 188 de la impresora de comprobantes.
A continuación un objeto impresora 190 invoca una función leer datos en el monitor 192 de impresión para determinar la ubicación y tamaño del archivo de datos de impresión. El objeto imprimir 190 envía los datos o la ruta del archivo de datos a la CDI de impresora 188. La CDI de impresora 188 entonces pasa los datos de impresión al hardware de la impresora. Esto da como resultado la impresión del documento.
Una vez que se imprime el comprobante el applet desde el controlador de impresora 182 emite una solicitud para entregar el comprobante impreso. La solicitud de entrega se pasa a través de la aplicación de servicios de transacción 146 al objeto impresora 190. El objeto impresora 190 invoca el procedimiento entregar en la CDI de impresora 188 para hacer que el comprobante se entregue al usuario de la máquina. La operación de los componentes de software permite el acceso a formatos de documento de forma selectiva así como el uso de instrucciones contenidas en los documentos para incluir datos de transacción dentro de los documentos impresos. Esto permite la producción de documentos de tipos variados. Adicionalmente permite proporcionar la impresión de diferentes tipos de documentos para clientes diferentes. Esto puede ser deseable cuando se proporciona información de marketing, cupones o marcas similares en comprobantes de transacción. Este enfoque simplifica además proporcionar formatos impresos en diversos idiomas desarrollando documentos HTML que proporcionan formularios impresos en diferentes idiomas. Adicionalmente los procedimientos descritos en la presente memoria pueden utilizarse para proporcionar marketing a clientes por perfil o tipos de categorías de cliente, así como de manera personalizada.
Aunque el procedimiento de impresión descrito anteriormente se comenta en conexión con la entrega de comprobantes de transacción, pueden invocarse procedimientos similares para la impresión de comunicados para clientes así como para imprimir un registro diario de transacción en la máquina bancaria automática. Además accediendo a documentos seleccionados que controlan el formato de impresión puede proporcionarse a los registros diarios información consolidada de una manera que permite ahorrar papel de registro diario en la máquina no imprimiendo información promocional u otros tipos de información que se proporcionan en documentos de cliente.
El procedimiento de impresión descrito en la presente memoria también permite imprimir diversos tipos de marcas ópticas tales como código de barras u otros tipos de marcas legibles por máquina que pueden utilizarse para imprimir cupones, cheques o artículos similares. Tal codificación puede facilitar el seguimiento de la utilización de tales artículos por clientes para fines de evaluar la efectividad de diversos esfuerzos de marketing. Adicionalmente pueden utilizarse marcas legibles por máquina para imprimir en artículos tales como sobres de ingreso y/o en registros diarios de transacción. Tal impresión puede facilitar la lectura de tales artículos por máquina para verificar los contenidos de los ingresos.
Las capacidades de impresión conseguidas a través de los procedimientos descritos presentemente también habilitan la impresión de materiales gráficos seleccionados. Esto puede incluir por ejemplo materiales que incluyen firmas digitales embebidas que pueden utilizarse para verificar la autenticidad de los artículos impresos. Esto puede ser particularmente útil por ejemplo en situaciones en las que la máquina de transacción se utiliza para imprimir vales, cheques de viaje, billetes de apuestas u otros artículos que tienen valor independiente. Adicionalmente pueden producirse documentos impresos a todo color incluyendo una impresora a color en la máquina de transacción.
El software informático utilizado en la operación de las máquinas de transacción automatizadas que implementan la presente invención y en los ordenadores conectados puede cargarse desde artículos de diversos tipos dentro de los respectivos ordenadores. Tal software informático puede incluirse en y cargarse desde uno o más artículos tal como disquetes o discos compactos. Tal software puede también incluirse en artículos tales como unidades de disco duro, cintas o dispositivos de memoria de sólo lectura. Otros artículos que incluyen datos representativos de las instrucciones para operar ordenadores de la manera descrita en la presente memoria son adecuados para utilizar en conseguir la operación de sistemas y máquinas de transacción según formas de realización de la presente invención.
Las formas de realización a título de ejemplo de las máquina bancarias automáticas y sistemas bancarios automatizados descritos en la presente memoria se han descrito con referencia a características y componentes de software particulares. Otras formas de realización de la invención pueden incluir otros o diferentes componentes de software que proporcionan funcionalidad similar.
En la descripción anterior ciertos términos se han utilizado con fines de brevedad, claridad y comprensión. Sin embargo no han de suponerse limitaciones innecesarias a partir de los mismos porque tales términos son para fines descriptivos y se han previsto para interpretarse ampliamente. Además, las descripciones e ilustraciones en la presente memoria se proporcionan a título de ejemplos y la invención no está limitada a los detalles mostrados y descritos.
En las siguientes reivindicaciones, cualquier característica descrita como medios para realizar una función deberá interpretarse que comprende cualquier medio que pueda realizar la función descrita y no deberá considerarse limitada a los medios particulares mostrados en la descripción anterior o meros equivalentes de los mismos.

Claims (11)

1. Aparato que comprende:
una máquina de transacción automatizada (12) que comprende:
un distribuidor de billetes bancarios (42),
un dispositivo lector de tarjetas (38), en el que el dispositivo lector de tarjetas (38) funciona para leer datos de tarjeta desde una tarjeta introducida por un usuario de la máquina (12),
un dispositivo de lectura biométrica que funciona para recibir del usuario datos biométricos a partir de los que puede derivarse una dirección HTTP asociada con el usuario; y
un ordenador (34) en conexión funcional con el dispositivo lector de tarjetas (38), el dispositivo de lectura biométrica y el distribuidor de billetes bancarios (42),
en el que, utilizando datos biométricos recibidos en el dispositivo de lectura biométrica, el ordenador funciona para derivar una dirección HTTP asociada con el usuario,
en el que el ordenador (34) funciona asimismo para acceder a la dirección HTTP derivada a partir de los datos biométricos, en el que la dirección HTTP es una dirección de un registro HTTP que comprende información que identifica unívocamente al usuario, y
en el que el distribuidor de billetes bancarios (42) funciona para distribuir por lo menos un billete bancario desde la máquina (12) en respuesta a una determinación de que una entrada de usuario a la máquina (12) corresponde a la información que identifica unívocamente al usuario.
2. Aparato según la reivindicación 1, en el que el ordenador funciona para derivar la dirección HTTP a partir de los datos biométricos y los datos de tarjeta.
3. Aparato según la reivindicación 1 ó 2, en el que el ordenador funciona para derivar la dirección HTTP accediendo a una base de datos.
4. Aparato según la reivindicación 1, en el que la información que identifica unívocamente al usuario en el registro HTTP incluye información correspondiente a datos biométricos del usuario.
5. Aparato según la reivindicación 4,
en el que el expendedor de billetes bancarios funciona para distribuir un papel en respuesta a la entrada de datos biométricos al dispositivo de lectura biométrica correspondiente a los datos biométricos en la información que identifica unívocamente al usuario en el registro HTTP.
6. Aparato según cualquiera de las reivindicaciones anteriores, en el que la máquina incluye asimismo una pluralidad de dispositivos de transacción, y un almacenamiento de datos, en el que el almacenamiento de datos incluye datos de dispositivo representativos de los dispositivos de transacción, y en el que la dirección HTTP se deriva a partir de los datos biométricos y los datos de dispositivo.
7. Aparato según cualquiera de las reivindicaciones anteriores, en el que la máquina incluye un dispositivo de reloj, y en el que la dirección HTTP se deriva a partir de los datos biométricos y el dispositivo de reloj.
8. Procedimiento para hacer funcionar una máquina de transacción automatizada (12), comprendiendo la máquina (12) un distribuidor de billetes bancarios (42), un dispositivo lector de tarjetas (38), un dispositivo de lectura biométrica y un ordenador (34) en conexión funcional con el dispositivo lector de tarjetas (38), el dispositivo de lectura biométrica y el distribuidor de billetes bancarios (42), comprendiendo el procedimiento las etapas siguientes
recibir desde el usuario, con el dispositivo de lectura biométrica, datos biométricos a partir de los cuales puede derivarse una dirección HTTP asociada con el usuario de la máquina (12),
derivar, con el ordenador (34), una dirección HTTP asociada con el usuario a partir de los datos biométricos; y
acceder, con el ordenador (34), a la dirección HTTP derivada a partir de los datos de entrada, en el que la dirección HTTP es una dirección de un registro HTTP que comprende información que identifica unívocamente al usuario;
\newpage
leer, con el dispositivo lector de tarjetas (38), datos de tarjeta desde una tarjeta introducida por un usuario de la máquina; y
distribuir, con el distribuidor de billetes bancarios (42), por lo menos un billete bancario desde la máquina en respuesta a una determinación de que una entrada de usuario a la máquina corresponde a la información que identifica unívocamente al usuario.
9. Procedimiento según la reivindicación 8, en el que la derivación comprende derivar, con el ordenador, la dirección HTTP a partir de los datos biométricos y los datos de tarjeta.
10. Procedimiento según la reivindicación 8 ó 9, en el que la derivación comprende derivar, con el ordenador, la dirección HTTP accediendo a una base de datos.
11. Programa informático que implementa el procedimiento según cualquiera de las reivindicaciones 8 a 10.
ES99303413T 1998-05-27 1999-04-30 Maquina bancaria automatica con acceso a datos basandose en entradas de cliente que incluyen la identificacion biometrica del cliente y la produccion de visualizaciones seleccionadas basandose en la identidad del cliente (bean de perfil). Expired - Lifetime ES2313770T3 (es)

Applications Claiming Priority (10)

Application Number Priority Date Filing Date Title
US7733798A 1998-05-27 1998-05-27
US77337 1998-05-27
US9188798P 1998-07-07 1998-07-07
US91887P 1998-07-07
US9562698P 1998-08-07 1998-08-07
US95626P 1998-08-07
US9890798P 1998-09-02 1998-09-02
US98907P 1998-09-02
US09/193,623 US6598023B1 (en) 1996-11-27 1998-11-17 Automated banking machine system using internet address customer input
US193623 1998-11-17

Publications (1)

Publication Number Publication Date
ES2313770T3 true ES2313770T3 (es) 2009-03-01

Family

ID=27536134

Family Applications (1)

Application Number Title Priority Date Filing Date
ES99303413T Expired - Lifetime ES2313770T3 (es) 1998-05-27 1999-04-30 Maquina bancaria automatica con acceso a datos basandose en entradas de cliente que incluyen la identificacion biometrica del cliente y la produccion de visualizaciones seleccionadas basandose en la identidad del cliente (bean de perfil).

Country Status (6)

Country Link
EP (1) EP0961251B1 (es)
BR (1) BR9901657B1 (es)
CA (1) CA2271214C (es)
DE (1) DE69939634D1 (es)
ES (1) ES2313770T3 (es)
MX (1) MXPA99004932A (es)

Families Citing this family (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CA2276637A1 (en) 1999-06-30 2000-12-30 Alan A. Mcnaughton Multipersonality automated transaction execution system
GB9928733D0 (en) * 1999-12-03 2000-02-02 Ncr Int Inc Self-service terminal
US7085774B2 (en) 2001-08-30 2006-08-01 Infonox On The Web Active profiling system for tracking and quantifying customer conversion efficiency
KR100869902B1 (ko) * 2007-01-26 2008-11-24 삼성에스디에스 주식회사 통합관리 시스템 환경에서의 장애 및 성능정보 통합모니터링 방법 및 그 시스템
CH707488B1 (it) * 2013-01-25 2020-06-30 Blindata Ltd Sistema e procedimento per effettuare operazioni digitali telematche.
US9811815B2 (en) * 2014-10-09 2017-11-07 Ncr Corporation Dynamic replacement of self-service terminal (SST) states flow and screens handling

Family Cites Families (18)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US4314352A (en) * 1972-04-12 1982-02-02 Docutel Corporation Banking machine
US4636622A (en) * 1985-05-06 1987-01-13 Clark Clement P Card user identification system
JPH0771106B2 (ja) 1989-12-30 1995-07-31 株式会社日立製作所 通信システム
US5764789A (en) * 1994-11-28 1998-06-09 Smarttouch, Llc Tokenless biometric ATM access system
JPH08320838A (ja) * 1995-05-26 1996-12-03 Fujitsu Ltd 端末管理方法並びにそのためのホスト計算機及びフロントエンドプロセッサ
WO1997018636A2 (en) * 1995-11-13 1997-05-22 Webtronics, Inc. Control of remote devices using http protocol
GB9523922D0 (en) * 1995-11-23 1996-01-24 At & T Global Inf Solution Method of authenticating an application program and a system therefor
US5754830A (en) * 1996-04-01 1998-05-19 Openconnect Systems, Incorporated Server and web browser terminal emulator for persistent connection to a legacy host system and method of operation
EP0894315A2 (en) * 1996-04-18 1999-02-03 Citibank, N.A. An improved method and system for performing banking transactions, including home banking
EP0935785A2 (en) * 1996-06-17 1999-08-18 Verifone, Inc. A system, method and article of manufacture for managing transactions in a high availability system
US5938726A (en) * 1996-10-04 1999-08-17 Motorola, Inc. Apparatus for reading an electronic network navigation device and a peripheral for use therewith
US5931917A (en) * 1996-09-26 1999-08-03 Verifone, Inc. System, method and article of manufacture for a gateway system architecture with system administration information accessible from a browser
GB2317723A (en) * 1996-09-30 1998-04-01 Viewinn Plc Caching system for information retrieval
SE9603753L (sv) * 1996-10-14 1998-04-06 Mirror Image Internet Ab Förfarande och anordning för informationsöverföring på Internet
US5956487A (en) * 1996-10-25 1999-09-21 Hewlett-Packard Company Embedding web access mechanism in an appliance for user interface functions including a web server and web browser
US5933816A (en) * 1996-10-31 1999-08-03 Citicorp Development Center, Inc. System and method for delivering financial services
US5905872A (en) * 1996-11-05 1999-05-18 At&T Corp. Method of transferring connection management information in world wideweb requests and responses
GB2319102B (en) * 1998-01-30 1998-12-23 Ibm A security system for a transaction processing system

Also Published As

Publication number Publication date
MXPA99004932A (es) 2005-07-25
EP0961251B1 (en) 2008-10-01
EP0961251A3 (en) 2004-06-30
BR9901657B1 (pt) 2010-07-13
DE69939634D1 (de) 2008-11-13
BR9901657A (pt) 2000-02-01
CA2271214C (en) 2002-12-17
CA2271214A1 (en) 1999-11-27
EP0961251A2 (en) 1999-12-01

Similar Documents

Publication Publication Date Title
ES2313769T3 (es) Configuracion del sistema en la que se ejecutan ciertos dispositvos de transaccion a traves de una interfaz de navegador con http y se ejecutan otros dispositivos en respuesta a mensajes en un sistemas de legado de cajeros automaticos.
ES2313767T3 (es) Maquina bancaria automatica con una caracteristica de impresion url.
US6289320B1 (en) Automated banking machine apparatus and system
US6598023B1 (en) Automated banking machine system using internet address customer input
US7062464B1 (en) Automated banking machine and system
EP0961250A2 (en) Method of delivering different documents for producing displays at different machines (multilingual, special features, advertising, etc.)
US20050182723A1 (en) Server software adapted to covert messages to enable ATM and ATM host communication
US20050086146A1 (en) Cash dispensing automated banking machine system and method
US20050289055A1 (en) Automated banking machine apparatus and system
US20050273427A1 (en) Automated banking machine apparatus and system
ES2313768T3 (es) Procedimientos mediante los que un cajero automatico accede selectivamente a documentos basandose en los dispositivos de funcion de transacion presentes en la maquina.
ES2315001T3 (es) Maquina automatizada de transacciones que funciona en respuesta a documentos html a los cuales se accede a traves de un navegador.
ES2313770T3 (es) Maquina bancaria automatica con acceso a datos basandose en entradas de cliente que incluyen la identificacion biometrica del cliente y la produccion de visualizaciones seleccionadas basandose en la identidad del cliente (bean de perfil).
ES2315000T3 (es) Bean de prenavegacion (incluyendo la comprobacion de la velocidad de descarga para determinar la posibilidad de acceder a los registros http).
US7634433B1 (en) Automated banking machine and system
EP1030276A2 (en) Using server ATM to present device status messages and accessing/operating devices for service activity with browser interface
EP1030277A2 (en) Legacy interface for communication with existing host systems (including passing object features)
EP1030275A2 (en) Terminal configuration methods
EP0961195A2 (en) Function for mapping the keys of a keypad
EP0961252A2 (en) Automated banking machine with selective accessing of HTML documents and other promotional information during dwell time in the machine transaction sequence
EP0961248A2 (en) Automated banking terminal with security features such as for example signed applets
EP0964374A2 (en) Transaction data object features including persistence, passing object and using object data for printing