ES2592931T3

ES2592931T3 - Sistema y procedimiento de terminal de usuario

Info

Publication number: ES2592931T3
Application number: ES10727115.7T
Authority: ES
Inventors: Richard Swinfen; Ralph Hasselgren
Original assignee: I Desing Multi Media Ltd
Current assignee: I Desing Multi Media Ltd
Priority date: 2009-05-29
Filing date: 2010-05-28
Publication date: 2016-12-02
Anticipated expiration: 2030-05-28
Also published as: EP2435996B1; BRPI1013199A2; US20120117577A1; CA2763343A1; GB0909277D0; PL2435996T3; WO2010136767A1; CA2763343C; EP2435996A1; US9659464B2

Abstract

Un sistema de monitorización para un cajero automático, ATM, (2), en el que el ATM (2) comprende: una pluralidad de dispositivos de hardware, incluyendo la pluralidad de dispositivos de hardware un dispositivo (8) de visualización; una capa de aplicación que comprende una aplicación (21) de ATM para controlar un procedimiento de transacción o de interacción de usuario del ATM (2); una capa de interfaz de programación de aplicaciones (API); una capa de plataforma de hardware específico que comprende controladores de dispositivos de hardware para controlar la operación de los dispositivos de hardware; y un almacén de datos que almacena una pluralidad de archivos de datos de pantalla, en el que el procedimiento de transacción o de interacción de usuario que comprende proporcionar bajo control los datos de visualización de aplicaciones de ATM representados por los archivos de datos de pantalla al dispositivo (8) de visualización del ATM (2) para reproducirse por el dispositivo (8) de visualización, los datos de visualización comprenden unos elementos de datos de píxel representativos de los píxeles que representan pantallas de visualización para la visualización en el dispositivo (8) de visualización, y el sistema de monitorización comprende: una aplicación (90) adicional en la capa de aplicación; medios para modificar un al menos uno seleccionado de los archivos de datos de pantalla almacenados por el almacén de datos para incluir en el o en cada archivo de datos de pantalla seleccionado un identificador codificado, codificándose el identificador con el valor de al menos un elemento de datos de píxel representado por el al menos un archivo de datos de pantalla e identificándose una pantalla de visualización representada por el archivo de datos de pantalla; y un medio (84, 90) de monitorización para monitorizar durante el procedimiento de transacción o de interacción de usuario los datos de visualización proporcionados al dispositivo (8) de visualización y para determinar a partir del identificador codificado con el valor de dicho al menos un elemento de datos de píxel si los datos de visualización corresponden a una pantalla de visualización predeterminada, en el que la aplicación adicional está configurada para reemplazar o superponer dicha pantalla de visualización predeterminada con un contenido adicional o alternativo en respuesta a la determinación de los medios de monitorización de que los datos de visualización corresponden a la pantalla de visualización predeterminada.

Description

imagen1

imagen2

imagen3

imagen4

imagen5

5

10

15

20

25

30

35

40

45

50

La al menos una aplicación puede ser para proporcionar una funcionalidad básica del terminal de usuario, y la al menos una aplicación adicional puede ser para proporcionar una funcionalidad adicional.

La al menos una aplicación adicional puede configurarse para proporcionar un mensaje adicional a los medios de interceptación en dependencia del mensaje interceptado o los datos incluidos en el mensaje interceptado.

El mensaje puede comprender además una modificación del mensaje o una instrucción para modificar el mensaje.

El mensaje puede comprender además una modificación del al menos un comando incluido en el mensaje o una instrucción para modificar el al menos un comando incluido en el mensaje.

La al menos una aplicación puede configurarse para controlar al menos un procedimiento del terminal de usuario, y el sistema puede comprender además unos medios para proporcionar el contenido a un usuario que es alternativo o adicional a cualquier contenido proporcionado a un usuario por la al menos una aplicación en el al menos un procedimiento.

Los medios de suministro de contenido pueden configurarse para proporcionar el contenido alternativo o adicional a un usuario en respuesta a la recepción del mensaje interceptado o los datos incluidos en el mensaje interceptado.

El sistema puede comprender además unos medios para seleccionar el contenido alternativo o adicional en dependencia del mensaje interceptado o los datos incluidos en el mensaje interceptado.

Los datos incluidos en el mensaje interceptado pueden comprender los datos de tarjeta o de usuario y los medios de selección pueden configurarse para seleccionar el contenido alternativo o adicional en dependencia de los datos de tarjeta o de usuario. Por lo tanto, el contenido alternativo o adicional puede adaptarse al usuario. Una publicidad específica del usuario u otro contenido puede proporcionarse a un usuario.

Los medios de selección pueden configurarse para determinar al menos una propiedad del usuario en dependencia de los datos de tarjeta o de usuario y para seleccionar el contenido en dependencia de la al menos una propiedad del usuario.

El contenido alternativo o adicional puede comprender el contenido publicitario. El mensaje que comprende los datos de usuario o de tarjeta puede destinarse a la al menos una aplicación, y los medios de interceptación pueden configurarse para proporcionar los datos de tarjeta a la o a al menos una aplicación adicional.

Los medios de suministro de contenido pueden configurarse para proporcionar el contenido alternativo o adicional mediante la modificación del mensaje por los medios de modificación.

El suministro de contenido alternativo o adicional al usuario puede comprender la impresión del material alternativo o adicional en un recibo o visualizar el material alternativo o adicional en un dispositivo de visualización asociado con el terminal de usuario. El dispositivo de visualización puede incluirse en el terminal de usuario. Los medios de interceptación pueden configurarse para proporcionar una instrucción para el dispositivo de visualización para visualizar el contenido. El mensaje puede comprender una instrucción de la al menos una aplicación al dispositivo de visualización para visualizar los datos y los medios de interceptación pueden configurarse para modificar la instrucción para hacer que el dispositivo de visualización visualice el material alternativo o adicional en el dispositivo de visualización.

El sistema puede comprender además unos medios de monitorización para monitorizar el estado del terminal de usuario, en el que los medios de suministro de contenido pueden configurarse para proporcionar el contenido alternativo o adicional en dependencia del estado del terminal de usuario.

Al menos uno de entre los medios de suministro de contenido, los medios de selección y los medios de monitorización puede estar comprendido en la al menos una aplicación adicional.

Los medios de monitorización pueden configurarse para monitorizar los datos de salida a emitirse por un dispositivo de hardware y para determinar el estado del terminal de usuario de los datos de salida.

En otro aspecto independiente de la invención, se proporciona un procedimiento para controlar un terminal de autoservicio que comprende al menos una aplicación y una interfaz de programación de aplicaciones (API) que comprende una interfaz para al menos un dispositivo de hardware del terminal de usuario, en el que el procedimiento comprende interceptar un mensaje enviado a la al menos una aplicación o a la API.

El procedimiento puede comprender interceptar el mensaje con al menos una API de intermediario.

Dicha una de entre la aplicación y la API puede configurarse para enviar el mensaje a un destino representado por los datos de destino, y el procedimiento puede comprender modificar los datos de destino. Los datos de destino pueden comprender al menos una entrada de registro.

imagen6

5

10

15

20

25

30

35

40

45

50

55

la figura 3 es una ilustración esquemática de un ejemplo de un sistema de procesamiento de ATM; la figura 4 es una ilustración esquemática de un sistema de procesamiento de ATM en otro ejemplo; la figura 5 es una ilustración esquemática de unos aspectos adicionales de un sistema de procesamiento de ATM en una realización; y la figura 6 es un diagrama de flujo que ilustra un modo de operación de la realización de la figura 5.

Descripción detallada de las realizaciones

Diversos componentes de un ATM 2 se ilustran esquemáticamente en la figura 1. El ATM 2 incluye un procesador 4 conectado a un almacén 6 de datos y diversos dispositivos de hardware, por ejemplo, un dispositivo 8 de visualización, un teclado 10, un dispositivo 12 lector de tarjetas y una impresora 14 de recibos. El ATM 2 también incluye un dispositivo de dispensación de efectivo (no mostrado) y una ranura (no mostrada) a través de la que se dispensa el efectivo por el dispositivo de dispensación de efectivo. El ATM 2 también incluye una ranura (no mostrada) que también puede usarse para dispensar un recibo impreso por la impresora 14 de recibos. El dispositivo 12 lector de tarjetas puede leer bandas magnéticas y/o chips de tarjetas inteligentes.

En la realización de la figura 1, el procesador es un procesador de 233 MHz compatible P1 de Intel con 64 MB de RAM configurado para funcionar en cualquier sistema operativo Windows de 32 bits. La memoria 6 comprende un disco duro de 100 Mb, el dispositivo 8 de visualización es un dispositivo de pantalla de color de 16 bits y la impresora 14 de recibos es una impresora con capacidad térmica. El teclado 10 comprende una teclado numérico y unos botones de control (por ejemplo, anular y aceptar) y también puede incluir botones de función a cada lado de la pantalla para controlar la interfaz.

El ATM 2 también incluye una circuitería 3 de comunicaciones de red y un software (no mostrado) que le permite comunicarse con un servidor 5 a través de una red segura. El servidor 5 es capaz de proporcionar datos al ATM 2, y a otros ATM en la red, y proporcionar autorización para las transacciones de usuario, por ejemplo, las transacciones financieras, de acuerdo con las técnicas conocidas. El servidor también es capaz de descargar e instalar el software en forma remota y de monitorizar la operación del ATM 2 y otros ATM de la red.

Cualquier servidor 5 adecuado puede usarse. En un ejemplo, el servidor 5 comprende un procesador de doble núcleo Intel Xeon serie 5100 de 2 GHz (o Intel compatible con un rendimiento equivalente), 2 GB de RAM, 2 x 140 GB discos duros (en espejo) con la base de datos de SQL Server, Microsoft Windows 2003 Server, Microsoft SQL Server 2000 SP2 o acceso a 2005 a la base de datos de SQL Server, SQL Server BCP, ADO 2.8, MSXML 3.0, DirectX 9.0c, IIS 6.0 y un software anti-virus.

En operación, el procesador 4 es capaz de comunicarse con y controlar la operación de los diversos dispositivos de hardware, bajo el control de aplicaciones que se ejecutan en el procesador. Tras el encendido del ATM 2 un sistema de entrada-salida básico (BIOS) se inicia desde un almacenamiento no volátil (no mostrado) incluido en el procesador 4, y el sistema operativo, las aplicaciones, los componentes API y los controladores de dispositivos se instalan a continuación desde la memoria 6 por el procesador 4 para formar un sistema de procesamiento de ATM.

El sistema de procesamiento de ATM se ilustra esquemáticamente en la visión general de la figura 2, y comprende una capa 20 de aplicación, un gestor 22 de XFS, una capa API en forma de una capa 24 de XFS, una capa 26 de hardware y un registro 28.

La capa de aplicación comprende una pluralidad de módulos de aplicación y tres módulos 32, 34, 36 de aplicación que forman una aplicación 21 de ATM se muestran a modo de ejemplo, junto con una aplicación 38 adicional. En la realización de la figura 2, los módulos 32, 34, 36 de aplicación proporcionan parte de la funcionalidad básica del ATM, y la aplicación 38 proporciona una funcionalidad adicional, como se describe en más detalle a continuación. En un modo de operación, se proporciona y se instala la aplicación 38 por un tercero en lugar de por el fabricante del ATM o un administrador. Los módulos de aplicación se proporcionan bajo cualquier entorno de aplicación XFS compatible, por ejemplo, Kalignite, NCR APTRA o un entorno de aplicación Wincor, tal como WincorProTopas. Unos ejemplos de aplicaciones de ATM incluyen NCR Avance NDC o Edge, Wincor ProCash NDC, y Diebold Agilis.

La capa 24 de XFS comprende una pluralidad de módulos de proveedor de servicios, y se ilustran tres módulos 40, 42, 44 de proveedor de servicios a modo de ejemplo. Los módulos 40, 42, 44 de proveedor de servicios ilustrados soportan la comunicación con y el control del teclado 10 específico, un dispositivo 12 lector de tarjetas y una impresora 14 de recibos incluidos en los cajeros automáticos 2. Otros módulos de proveedor de servicios, no mostrados, se incluyen en la capa de XFS para soportar la comunicación con y el control de otros dispositivos de hardware incluidos en el ATM 2. Una capa de software intermedio adicional (no mostrada), por ejemplo, KAL Kalignite, Pheonix VISTAatm, o Nexus, se proporciona también en algunas variantes para simplificar la implementación de la aplicación de ATM.

Unos módulos de proveedor de servicios adicionales, no mostrados, también se incluyen normalmente en la capa 24 de XFS que son capaces de soportar la comunicación con los dispositivos de hardware de otros fabricantes, por ejemplo, teclados, dispositivos lectores de tarjetas e impresoras de recibos de otros tipos o de otros fabricantes, pero por lo general solo se usa si un dispositivo de hardware, por ejemplo, el teclado 10, se sustituye con un dispositivo de hardware de otro tipo o de otro fabricante, por ejemplo, un teclado de otro tipo.

5

10

15

20

25

30

35

40

45

50

55

El sistema también incluye en general una capa de plataforma de hardware y/o de fabricante específicos (no mostrada), que puede considerarse que forma parte de la capa 26 de hardware, y comprende los diversos controladores u otros componentes necesarios para controlar la operación de los dispositivos de hardware físicos. Los módulos 40, 42, 44 de proveedor de servicios son en general compatibles con un solo tipo de capa de plataforma, pero los mensajes XFS enviados desde la capa de aplicación son no específicos de la plataforma y por lo tanto los módulos 40, 42, 44 de proveedor de servicios son capaces de comunicarse con y recibir instrucciones de cualquier aplicación de ATM.

En operación, los módulos 32, 34, 36 de aplicación en la capa de aplicación controlan la funcionalidad básica del ATM 2. Por ejemplo, los módulos de aplicación controlan la secuencia de operaciones necesarias para la retirada de dinero en efectivo por un usuario, u otras funciones de usuario. Cada secuencia de operaciones puede requerir, por ejemplo, una o más lecturas de la tarjeta de un usuario, la entrada y la comprobación del PIN de un usuario, la entrada y la comprobación de unos detalles personales y financieros del usuario, tales como el saldo de la cuenta y el límite de retirada, la recuperación de la información solicitada, y la dispensación de dinero en efectivo. Cada secuencia de operaciones requiere también por lo general la visualización de pantallas predeterminadas que incluyen instrucciones u otra información en puntos predeterminados en el procedimiento.

La combinación de los módulos 32, 34, 36 de aplicación que proporciona la funcionalidad básica del ATM también se denomina en el presente documento como la aplicación 21 de ATM. Como se ha mencionado anteriormente, también se proporciona una aplicación 38 adicional que proporciona una funcionalidad adicional.

Con el fin de realizar la secuencia de operaciones, los módulos de aplicación dan instrucciones a los dispositivos de hardware para realizar acciones solicitadas y recibir datos desde los dispositivos de hardware. Los mensajes entre la capa de aplicación y la capa de hardware se envían a través del gestor 22 de XFS y la capa 24 de XFS.

El registro 28 almacena claves, también denominadas como cadenas, que mapean las llamadas del dispositivo de hardware a los módulos de proveedor de servicios específicos en la capa de proveedor de servicios. El gestor 22 de XFS está en comunicación con el registro 28, y tras la inicialización del sistema o la aplicación 21 de ATM, el gestor 22 de XFS lee las claves apropiadas del registro 28 para los dispositivos de hardware instalados y proporciona las claves a la capa de aplicación, de manera que los mensajes de dispositivo de hardware posteriores de la aplicación 21 de ATM están dirigidos al proveedor de servicios identificado por la clave apropiada.

Como puede verse en la figura 2, el sistema de procesamiento incluye un componente adicional en la ruta entre el gestor 22 de XFS y la capa API, en este caso la capa 24 de proveedor de servicios. El componente adicional está dispuesto para interceptar los mensajes entre la capa de aplicación y la capa de XFS. En la realización de la figura 2, el componente adicional es una API 52 de intermediario y se localiza en la ruta entre el gestor 22 de XFS y la capa 24 de proveedor de servicios. La API 52 de intermediario es un proveedor de servicios de pasarela compatible CEN XFS SPI.

Un intermediario en este contexto puede considerarse como un programa de reemplazo (por ejemplo, una DLL) para una parte específica de una aplicación, una API u otro software. El intermediario puede proporcionar al menos algunas de las funcionalidades que la aplicación, la API u otro software dispone en su operación normal. Además, puede ser capaz de observar los flujos de datos, o si es necesario modificar un procedimiento o unos datos para satisfacer un objetivo. En el ejemplo de la figura 2, la API 52 de intermediario comprende una DLL que se usa como un reemplazo para el módulo 44 proveedor de servicios XFS lector de tarjetas (que, como se ha tratado es una API convencional que controla el comportamiento del controlador de lector de tarjetas específico para la plataforma ATM).

En el ejemplo de la figura 2, la API 52 de intermediario está instalada en un sistema existente y está dirigida al control de y la comunicación con uno de los dispositivos de hardware, en este caso el lector de tarjetas 12. Con el fin de garantizar que los mensajes de la capa 20 de aplicación se dirigen a la API 52 de intermediario en lugar de ir directamente desde el gestor 22 de XFS al módulo 44 de proveedor de servicios existente, se altera la clave almacenada en el registro 28 para el dispositivo de hardware.

Por ejemplo, la clave apropiada puede ser:

HKLM\SOFTWARE\XFS\SERVICE-PROVIDERS\IDC\DLLNAME

en la que el lector de tarjetas se conoce como el dispositivo XFS IDC. En este caso, DLLNAME es la clave y el valor de cadena de la clave es el nombre del archivo de la DLL. El valor de cadena de la clave se altera en este ejemplo para hacer referencia al nombre de archivo de la API 52 de intermediario.

En las realizaciones alternativas, la interceptación de mensajes por la API de intermediario u otro dispositivo de interceptación se obtiene sin la modificación de las claves de registro. Por ejemplo, el dispositivo de interceptación puede monitorizar los mensajes en la ruta de comunicación entre la aplicación y el módulo de proveedor de servicios, e interceptarlos en un punto adecuado en la ruta durante el procedimiento de comunicación. Como alternativa, un archivo DLL de intermediario de la API de intermediario puede colocarse en una carpeta más arriba en la jerarquía de búsqueda usada por la aplicación para cargar el módulo 44 de proveedor de servicios o DLL,

forzando de este modo al archivo DLL de intermediario a cargarse en su lugar.

Al reemplazar el módulo 44 de proveedor de servicios existente o DLL, podría parecer que es necesario implementar todas las funciones normales del módulo 44 de proveedor de servicios en la API 52 de intermediario con el fin de controlar el lector 12 de tarjetas de hardware específico de ATM. Sin embargo, en la realización de la figura 2 se

5 evita garantizando que en respuesta a cada llamada a una función en la API 52 de intermediario, se llaman a las funciones originales del módulo 44 de proveedor de servicios original por la API 52 de intermediario, y la API 52 de intermediario solo procesa los datos o modifica el comportamiento donde sea necesario para proporcionar la funcionalidad adicional deseada.

En la realización de la figura 2, la API 52 de intermediario pasa todos los mensajes, por ejemplo, todos los

10 comandos recibidos de la capa de aplicación al módulo 44 de proveedor de servicios compatible IDC CEN XFS del proveedor de hardware existente, que pasa los comandos al dispositivo de tarjeta 12. Los mensajes del dispositivo 12 lector de tarjetas en respuesta a los comandos se pasan de nuevo al módulo 44 de proveedor de servicios, que a su vez los pasa de nuevo a la aplicación 21 de ATM a lo largo de la ruta de vuelta a la capa de aplicación. En este caso, la ruta pasa a través de la API 52 de intermediario. En variantes de la realización, los mensajes se envían

15 entre la API 52 de intermediario y la capa de hardware sin pasar a través de, o sin llamar a las funciones de, el módulo 44 de proveedor de servicios.

La API 52 de intermediario es capaz de procesar la información recibida y otros mensajes y pasar los datos incluidos en los mensajes a la aplicación 38 adicional, además de a la aplicación 21 de ATM. En este ejemplo, los datos son datos de tarjeta leídos por el dispositivo 12 lector de tarjetas e incluyen uno o más de, por ejemplo, el nombre del

20 titular de la tarjeta, el número de cuenta principal (PAN) y la "aplicación" de tarjeta (es decir, el emisor/la institución responsable del procesamiento del crédito/débito, tal como Mastercard o Visa).

Los datos proporcionados a la aplicación 38 adicional pueden usarse para cualquier fin deseado o para proporcionar cualquier funcionalidad deseada. En el ejemplo de la figura 2, la aplicación 38 adicional procesa los datos para extraer información relevante para el marketing dirigido, y selecciona y proporciona el contenido de marketing al

25 usuario a través del ATM. Un ejemplo de funciones de marketing dirigidas que pueden proporcionarse por la aplicación 38, se describen con más detalle a continuación.

No se necesitan cambios en la aplicación para instalar la API 52 de intermediario.

Las etapas sucesivas de un ejemplo de un flujo de procedimiento que se realiza por la realización de la figura 2 con el fin de leer los datos de banda magnética de una tarjeta se resumen a continuación en la Tabla 1.

30 Tabla 1

Etapa: Componente Datos recibidos Acción Datos enviados

1: Aplicación 21 de ATM Estado inactivo de accesos internos Solicitar datos de tarjeta Comando IDC XFS para solicitar los datos de banda magnética

2: API 52 de intermediario Comando IDC XFS para solicitar los datos de banda magnética Enviar al módulo 44 de proveedor de servicios Comando IDC XFS para solicitar los datos de banda magnética

3: Usuario - Introducir tarjeta Datos leídos desde la banda magnética

4: Módulo 44 de proveedor de servicios Datos de banda magnética del hardware Notificar a la aplicación Datos de banda magnética empaquetados como una respuesta XFS

5: API 52 de intermediario Datos de banda magnética de respuesta XFS Enviar a la aplicación 38 adicional y a continuación a la aplicación 21 de ATM Datos de banda magnética procesados para la aplicación 38 adicional. Respuesta XFS original a la aplicación 21 de ATM

6: Aplicación 38 adicional Datos de banda magnética procesados - -

(continuación)

Etapa: Componente Datos recibidos Acción Datos enviados

7: Aplicación 21 de ATM Datos de banda magnética de respuesta XFS Iniciar transacción (por lo general leer el chip en esta etapa) Comando IDC XFS para leer el chip

8: API 52 de intermediario Comando IDC XFS para leer los datos del chip Grabar algunos detalles del comando enviado al chip Enviar al módulo 44 de proveedor de servicios Comando IDC XFS para leer los datos del chip

9: Módulo 44 de proveedor de servicios Datos de chip leídos de la tarjeta inteligente Notificar a la aplicación Datos de chip empaquetados como respuesta XFS

10: API 52 de intermediario Datos de chip de respuesta XFS Enviar a la aplicación 38 adicional y a continuación a la aplicación 21 de ATM Datos de chip procesados para la aplicación 38 adicional. Respuesta XFS original a la aplicación de ATM

11: Aplicación 38 adicional Datos de chip procesados Seleccionar publicidad u otro contenido -

12: Aplicación 21 de ATM Datos de chip de respuesta XFS Continuar la transacción (tal como solicitar PIN) -

Los formatos de datos de los diversos datos que se mencionan en la Tabla 1, en un modo de operación, se proporcionan a continuación en la Tabla 2.

Tabla 2

Tipo de datos: Formato

Comando IDC XFS para solicitar los datos de banda magnética: El comando WFS_CMD_IDC_READ_RAW_DATA como se detalla en el Doc1, sección 5.7. Los datos específicos son dependientes de la aplicación de ATM (tal como que hace un seguimiento para leer, etc.)

Datos leídos de la banda magnética por el hardware: Específico del fabricante

Datos de banda magnética empaquetados como una respuesta XFS: La estructura WFSIDCCARDDATA en respuesta al comando WFS_CMD IDC_READ_RAW_DATA como se detalla en el Doc1, sección 5.7. Los datos específicos devueltos son dependientes de la aplicación de ATM y de las tarjetas de clientes

Los datos de banda magnética procesados a la aplicación 38: De acuerdo con la respuesta prefijada del comando WFS_CMD_IDC_READ_RAW_DATA con: DWORD dwMessage = ePipePlayerMsg_CardRawData = 10 DWORD dwRecords = n.º de registros WFSIDCCARDDATA

Comando IDC XFS para leer los datos de chip: El comando WFS_CMD_IDC_CHIP_IO como se detalla en el Doc1, sección 5.9. Los datos específicos son dependientes de la aplicación de ATM dependiente y define el protocolo de comunicación entre la aplicación de ATM y la aplicación de tarjeta inteligente

(continuación)

Tipo de datos: Formato

Datos de chip empaquetados como respuesta XFS: Estructura WFSIDCCHIPIO en respuesta al comando WFS_CMD_IDC_CHIP_IO como se detalla en el Doc1, sección 5.9

Datos de chip: La API 52 de intermediario mapea esta estructura para al elemento

procesados para la: IpbChipData de la estructura de datos WFS_CMD_IDC_CHIP_IO enviada

aplicación 38: por la aplicación 21 de ATM al chip de tarjeta inteligente. Representa la cabecera de un comando APDU (véase el Doc2, sección 6 para detalles de la norma):

struct sChipCmd { BYTE bCla; BYTE blns; BYTE bP1; BYTE bP2; BYTE bP3; }; A continuación, el elemento blns identifica la instrucción que se envía. Si se trata de un comando de ‘leer registro’ (Doc2, sección 6.5.11) entonces se graba el ID de referencia del comando XFS Cuando la respuesta regresa del módulo 44 de proveedor de servicios, la API 52 de intermediario recibe los datos, los identifica por el ID de referencia grabada y así tiene acceso a los datos devueltos por el chip de tarjeta inteligente en el elemento IpbChipData de la estructura WFSIDCCHIPIO. Se identifica el registro como que es de un tipo ‘leer registro’ y se envían los datos de registro a la aplicación 38 para su procesamiento A continuación, la aplicación 38 procesa los datos usando un algoritmo para procesar una estructura BER-TLV (véase el Doc2, anexo B para detalles de la norma). A partir de aquí la aplicación 38 obtiene (todo el texto ASCII en bruto) los datos de nombre de titular de la tarjeta, el número de cuenta primario (PAN) y el nombre de la aplicación de ATM usando las etiquetas definidas en el Doc2, anexo A.

Los documentos Doc1 y Doc2 mencionados en la Tabla 2 son los siguientes:

Doc1: La norma XFS IDC SP API (referencia CEN CWA 15748-04, Julio de 2008), que incluye comandos, 5 estructuras de datos y el archivo de inclusión de C.

Doc2: Las especificaciones EMV 4.2 de Junio de 2008, que incluyen el protocolo APDU y el formato de datos BER-TLV. (http://www.emvco.com/specifications.aspx?id=155).

En un modo alternativo de operación, la aplicación 38 adicional no usa la API 52 de intermediario y en su lugar usa los proveedores de servicios XFS existentes en la capa 24 de proveedor de servicios para acceder a los dispositivos

10 de hardware de ATM (por ejemplo, para enviar comandos al lector de tarjetas 12 para adquirir datos de la tarjeta).

Sin embargo, en este caso, puede llevar más tiempo la lectura de la tarjeta, ya que tanto la aplicación 21 de ATM como la aplicación 38 adicional deben leer la tarjeta y la tarjeta solo puede leerse por una aplicación a la vez. Esto puede resultar en un retraso para el usuario y, en el caso en el que la aplicación 38 se use para proporcionar el contenido de marketing directo al usuario, en un retraso en seleccionar y proporcionar el contenido de marketing

15 basándose en la información adquirida a partir de los datos de la tarjeta.

Por otra parte, si las comunicaciones con la tarjeta no están coordinadas entre las dos aplicaciones (por ejemplo, la aplicación 21 de ATM y la aplicación 38 adicional), una aplicación (por lo general la aplicación 21 de ATM) pueden dejarse en un estado incorrecto dando como resultado que fallan las comunicaciones posteriores (y en última instancia las transacciones).

20 Sin embargo, el modo alternativo de operación en el que la aplicación 38 adicional no usa la API 52 de intermediario, puede usarse para algunas configuraciones de ATM y para algunas aplicaciones.

imagen7

5

10

15

20

25

30

35

’IDC30 > ATMAD_IDCardUnit1, IDC30 > IDCardUnit1,PRR30 > ATMAD_ReceiptPrinter1, PRR30 > ReceiptPrinter1,...’.

Una característica de este enfoque es que, si el procedimiento de configuración Wincor se vuelve a ejecutar (tal como por la herramienta MvDetect), se auto configurará de manera automática para usar las API 52, 60 de intermediario ya que estas se identificarán como válidas y satisfacen los criterios requeridos.

La API 60 de intermediario adicional está configurada para reenviar a la aplicación 38 adicional instrucciones de la aplicación 21 de ATM, o al menos algunos de los contenidos de tales instrucciones, que están destinadas a la impresora 14 de recibos. La aplicación 38 adicional procesa las instrucciones o los contenidos, selecciona el contenido gráfico u otro adicional o alternativo para adjuntarse al recibo o para incluirse en el recibo mediante la modificación del contenido original, y determina la localización en el recibo donde debe adjuntarse el contenido gráfico u otro adicional.

A continuación, la aplicación 38 adicional envía una instrucción adicional a la API 60 de intermediario adicional para dar instrucciones a la modificación de las instrucciones de impresora de recibos para incluir el contenido gráfico u otro adicional a adjuntarse en el recibo en la localización seleccionada. A continuación, la API 60 de intermediario adicional pasa las instrucciones modificadas a la impresora 14 de recibos a través del proveedor 42 de servicios. La impresora 14 de recibos imprime el recibo de acuerdo con las instrucciones mediante la aplicación 21 de ATM, pero con el contenido gráfico u otro adicional añadido al recibo, o con el contenido del recibo modificado.

Las etapas sucesivas de un ejemplo de un flujo de procedimiento que se realiza por la realización de la figura 2 con el fin de imprimir el contenido en un recibo, se describen a continuación en resumen en la Tabla 3.

Tabla 3

Etapa: Componente Datos recibidos Acción Datos enviados

1: Aplicación 21 de ATM Estado de impresión de recibo de accesos internos Enviar datos de recibo en bruto a la impresora 14 Comando IDC XFS para enviar los datos en bruto a la impresora 14 de recibos

2: API 60 de intermediario Comando IDC XFS para enviar los datos en bruto a la impresora de recibos Procesar datos en bruto y si la imagen adjunta y los datos de imagen de referencia/en bruto son apropiados. Enviar al módulo 42 de proveedor de servicios Comando IDC XFS para enviar datos en bruto potencialmente aumentados a la impresora 14 de recibos

3: Módulo 42 de proveedor de servicios Comando IDC XFS para enviar los datos en bruto a la impresora de recibos Enviar datos en bruto a la impresora 14 para imprimir el recibo Estructura específica de hardware de vendedor que contiene datos de impresión en bruto

Las etapas enumeradas en la Tabla 3 pueden repetirse varias veces para una sola transacción de impresión. Esto es debido al hecho de que puede haber diversos fragmentos de datos para enviar a la impresora antes de que el recibo se expulse para el cliente. Durante la etapa 2, el contenido se procesa para determinar si este es el último comando de impresión que se envía a la impresora para la transacción independiente. Esto se determina por la existencia de un código de escape de avance de página en los datos en bruto, o un comando de ‘expulsión’ XFS específico.

En la práctica, el procedimiento de impresión de recibos de transacción puede ser más complejo que como se resume en la Tabla 3 en algunos escenarios. Sin embargo, la API 60 de intermediario es capaz de hacer frente a tales escenarios más complejos.

En algunos casos, en lugar de enviar el ASCII en bruto y los códigos de escape a la impresora, se envían datos diferente a la capa de proveedor de servicios que formatean el contenido de la impresora usando una metodología XFS conocida como "formularios". Los formularios son estructuras de datos que definen el diseño del contenido impreso usando unas plantillas predefinidas con los campos que pueden sustituirse con los datos en el momento de la impresión. Imprimir usando este procedimiento requiere una mayor participación de la API de intermediario. Las etapas sucesivas de un flujo de procedimiento que se realiza por la realización de la figura 2 con el fin de imprimir el contenido de un recibo en tres escenarios diferentes se describen a continuación en resumen en las Tablas 4 a 6.

En el primer escenario, que es el objeto de la Tabla 4, el comando de formulario de impresión final contiene un comando de control de medios de avance de página integrado.

Tabla 4

Etapa: Componente Datos recibidos Acción Datos enviados

1: Aplicación 21 de ATM Estado de impresión de recibo de accesos internos Enviar datos de recibo en bruto a la impresora 14 Comando IDC XFS para enviar datos de formulario a la impresora 14 de recibos

2: API 60 de intermediario Comando IDC XFS para enviar los datos de formulario a la impresora 14 de recibos Procesar datos de formulario analizar y decidir si incluir la imagen de recibo. Si los datos incluyen un comando de avance de página y se va a añadir una imagen, suprimirla por ahora pero enviar el resto de datos de formulario al módulo 42 de proveedor de servicios. Repetir este paso para cada formulario de impresión que comprende el recibo de transacción Comando IDC XFS para enviar datos de formulario a la impresora 14 de recibos

3: Módulo 42 de proveedor de servicios Comando IDC XFS para enviar los datos de formulario a la impresora 14 de recibos Procesar los datos de formulario en los datos en bruto y enviar al hardware para el recibo de impresión. Notificar a la aplicación cuando finalice Datos específicos de hardware de vendedor

4: API 60 de intermediario Notificación de la finalización del comando de formulario de impresión Suprimir la notificación a la aplicación 21 de ATM y en su lugar, enviar un nuevo comando de datos en bruto de impresión XFS para imprimir la imagen y el terminador de avance de página al módulo 42 de proveedor de servicios Comando IDC XFS para imprimir la imagen y avanzar página (expulsar) el papel de impresora de recibos

5: Módulo 42 de proveedor de servicios Comando IDC XFS para imprimir la imagen y avanzar página (expulsar) el papel de impresora de recibos Procesar los datos de hardware en bruto y enviar al hardware para imprimir los contenidos de imágenes y expulsar el recibo. Notificar a la aplicación cuando finalice Datos específicos de hardware de vendedor

6: API 60 de intermediario Notificación de la finalización del comando de impresión de formulario Modificar los datos de respuesta para representar el comando de impresión de formulario original y notificar a la aplicación 21 de ATM original Datos de respuesta XFS para el comando de impresión de formulario (final) original

En el segundo escenario, que es el objeto de la Tabla 5, el comando de impresión de formulario final se sigue por un comando XFS explícito para expulsar el papel de recibo.

Tabla 5

Etapa: Componente Datos recibidos Acción Datos enviados

1: Aplicación 21 de ATM Estado de impresión de recibo de accesos internos Enviar datos de formulario de recibo a la impresora 14 Comando IDC XFS para enviar datos de formulario a la impresora 14 de recibos

2: API 60 de intermediario Comando IDC XFS para enviar datos de formulario a la impresora 14 de recibos Procesar datos de formulario analizar y decidir si incluir la imagen de recibo. Este paso se repite para cada formulario impreso que comprende el recibo de transacción Comando IDC XFS para enviar datos de formulario a la impresora 14 de recibos

3: Módulo 42 de proveedor de servicios Comando IDC XFS para enviar datos de formulario a la impresora 14 de recibos Procesar los datos de formulario en los datos en bruto y enviar al hardware para imprimir el recibo. Notificar a la aplicación cuando finalice Datos específicos de hardware de vendedor

4: API 60 de intermediario Notificación de la finalización del comando de impresión de formulario Enviar a la aplicación 21 de ATM Notificación de la finalización del comando de impresión de formulario

5: Aplicación 21 de ATM Notificación de la finalización del comando de impresión de formulario Enviar el comando de expulsión de control de medio final Comando de control de medios IDC XFS para expulsar el papel impresora de recibos

6: API 60 de intermediario Comando de control de medios IDC XFS para expulsar el papel impresora de recibos Modificar el comando XFS para enviar en su lugar los datos en bruto que incluyen la imagen y un terminador de avance de página Comando de impresión en bruto IDC XFS de datos de imagen y terminador de avance de página

7: Módulo 42 de proveedor de servicios Comando de impresión en bruto IDC XFS de datos de imagen y terminador de avance de página Procesar los datos en los datos en bruto y enviar al hardware para imprimir la imagen y expulsar el papel. Notificar a la aplicación cuando finalice Datos específicos de hardware de vendedor

8: API 60 de intermediario Notificación de la finalización del comando de impresión en bruto Modificar la respuesta de nuevo para solo el comando de control de medios y devolver al módulo 42 de proveedor de servicios Comando de control de medios IDC de datos de respuesta

En el tercer escenario, que es el objeto de la Tabla 6, el comando de impresión de formulario final se sigue por un comando de impresión en bruto XFS para algunos códigos de texto en bruto finales o de comando y por la expulsión del papel de recibo.

Tabla 6

Etapa: Componente Datos recibidos Acción Datos enviados

2: API 60 de intermediario Comando IDC XFS para enviar datos de formulario a la impresora 14 de recibos Procesar datos de formulario -analizar y decidir si incluir la imagen de recibo. Este paso se repite para cada formulario impreso que comprende el recibo de transacción Comando IDC XFS para enviar datos de formulario a la impresora 14 de recibos

5: Aplicación 21 de ATM Notificación de la finalización del comando de impresión de formulario Enviar comando de impresión en bruto final que incluye un terminador de avance de página Comando de impresión en bruto IDC XFS para imprimir algunos datos en bruto y expulsar el papel impresora de recibos

6: API 60 de intermediario Comando de impresión en bruto IDC XFS para imprimir algunos datos en bruto y expulsar el papel impresora de recibos Añadir los datos de imagen a los datos en bruto Comando de impresión en bruto IDC XFS que incluye los datos de imagen y terminador de avance de página

7: Módulo 42 de proveedor de servicios Comando de impresión en bruto IDC XFS que incluye los datos de imagen y terminador de avance de página Procesar los datos en los datos en bruto y enviar al hardware para imprimir la imagen y expulsar el papel. Notificar a la aplicación cuando finalice Datos específicos de hardware de vendedor

5

10

15

20

25

30

Los formularios de datos de los diversos datos mencionados en las tablas 4 a 6, en un modo de operación, se proporcionan a continuación en la Tabla 7.

Tabla 7

Tipo de datos: Formato

Comando IDC XFS para enviar los datos en bruto a la impresora 14 de recibos: El comando WFS_CMD_PTR_RAW_DATA como se detalla en el Doc3, sección 8.4. Los datos incluyen los códigos ASCII y de escape para definir el contenido y controlar el comportamiento y los modos de la impresora. '0x0c' es el código de escape de terminador de avance de página

Comando IDC XFS para enviar los datos de formulario a la impresora 14 de recibos: El comando WFS_CMD_PTR_PRINT_FORM como se detalla en el Doc3, sección 8.2. Los datos incluyen el nombre del formulario (que especifica el formulario predefinido a usar -detallado en la sección 10) y los valores de campo de formulario. Además, existe un comando de control de medios que puede, por ejemplo, desencadenar la expulsión del papel después de la impresión

Comando IDC XFS para controlar los medios impresión de recibos: El comando WFS_CMD_PTR_CONTROL_MEDIA como se detalla en el Doc3, sección 8.1. Los datos incluyen el comando de control, por ejemplo WFS_PTR_CTRLEJECT

Notificación de la finalización de los comandos XFS PTR: La estructura WFSRESULT convencional que contiene la referencia para solicitar el ID y el código de comando usado (detallado en la sección 9.1 del Doc4)

Los documentos Doc3 y Doc4 mencionados en la Tabla 7 son los siguientes:

Doc3: La norma XFS PTR SP API (referencia CEN CWA 15748-3, Julio de 2008), que incluye comandos, estructuras de datos y el archivo de inclusión de C.

Doc4: La norma XFS API y SPI (referencia CEN CWA 15748-3, Julio de 2008) que incluye comandos generales, estructuras de datos y el archivo de inclusión de C.

La aplicación 38 adicional puede monitorizar donde se reproduce la imagen gráfica u otro contenido adicional o alternativo en el recibo. En algunos modos de operación, la aplicación adicional sustituye, elimina o reformatea algunos de los contenidos originales del recibo antes de imprimir. Por ejemplo, el contenido original puede reformatearse para hacer espacio para la imagen gráfica a adjuntarse.

La aplicación 38 adicional, en ciertos modos de operación, también analiza el contenido original a incluirse en el recibo para determinar si incluir o no cualquier contenido adicional. La aplicación 38 adicional puede realizar una búsqueda de cadena de expresión normal en el contenido original para determinar si incluir cualquier contenido adicional. Por ejemplo, la aplicación 38 adicional podría configurarse para incluir contenido adicional en el recibo solo si el recibo es un recibo de retirada, y no incluir ningún contenido adicional si el recibo es un recibo que indica que un usuario está en descubierto. La búsqueda de cadena de expresión normal podría a continuación buscar expresiones tales como "cantidad retirada", "nuevo saldo", "en descubierto", o "denegado" para determinar qué tipo de recibo debe imprimirse y si se debe incluir el contenido adicional.

Los tipos de recibos, o contenidos, que desencadenan el adjuntado de la imagen gráfica u otro contenido en el recibo y/o la modificación del contenido original del recibo, pueden diferir entre los ATM o entre las aplicaciones de ATM, y puede determinarse en una base de caso por caso.

En un modo alternativo de operación, la aplicación 38 adicional envía unos comandos a la impresora 14 de recibos usando el módulo 42 de proveedor de servicios XFS convencional. Sin embargo, esto no permite que el contenido gráfico se añada al contenido existente impreso en los recibos de transacciones de ATM. En cambio un recibo individual que contiene la imagen gráfica u otro contenido adicional se imprimiría después del recibo transaccional.

En algunos ATM, la aplicación de ATM se comunica por lo general con la impresora 14 de recibos a través de un dispositivo de impresora GDI de Windows, por ejemplo, un monitor 70 de puerto GDI de impresora de recibos, en lugar de a través de un proveedor de servicios XFS. Un ejemplo alternativo de un sistema de procesamiento de ATM para su uso en tales ATM se ilustra en la figura 4.

imagen8

5

10

15

20

25

30

35

40

basándose en el contenido que está presentándose al usuario durante la operación empleando una técnica de codificación/decodificación o 'codec'. La codificación se aplica a los archivos de datos de pantalla que se usan por la aplicación 21 de ATM. La aplicación 90 está configurada para realizar la codificación modificando los archivos de pantalla de tal manera que cuando la aplicación 21 de ATM los reproduce, puede detectarse una diferencia por la aplicación 90 adicional casi instantáneamente. Cada uno de los archivos de pantalla puede codificarse para incluir los datos de identificación, por ejemplo, un identificador que permite la identificación de la pantalla de visualización representada por ese archivo de pantalla.

El operador es capaz de predeterminar qué archivos representan etapas específicas de la interacción o transacción, y qué información puede descargarse al ATM 2 desde el servidor 5. La aplicación 90 recibe la información desde el servidor y la usa para codificar las pantallas especificadas usando un algoritmo que da como resultado una modificación específica pero pequeña de lo que se reproducirá en la visualización.

El procedimiento para codificar los archivos de pantalla es específico para cada formato de archivo. Sin embargo, para cada formato de archivo el algoritmo implementado por la realización de la figura 5 es similar y comprende modificar los primeros pocos píxeles (por ejemplo, en la esquina superior izquierda) de la imagen para contener unos píxeles de colores que representan un código de cadena ASCII. El código comprende dos partes, un valor de cabecera de 16 bits y un valor de clave de 32 bits. La cabecera de 16 bits es un valor fijo usado para evitar falsos positivos cuando se decodifica la imagen de visualización de consumidor. El valor de clave de 32 bits es una versión comprimida sin pérdida de una cadena ASCII de 6 caracteres. Los caracteres están restringidos a letras de caso único del alfabeto para fines prácticos, y como tal pueden comprimirse en fragmentos de 5 bits del valor de clave de 32 bits (se usan 30 bits). A continuación, se codifican cuatro píxeles de 24 bits para representar el código de 48 bits, como tal.

Los números y componentes de píxel y las partes de código correspondientes se enumeran para un modo de operación en la Tabla 8.

Tabla 8

Píxel (componente): Parte de código de bit:a bit (inclusive)

1 (azul): Cabecera 3:0

1 (verde): Cabecera 7:4

1 (rojo): Cabecera 11:8

2 (azul): Cabecera 15:12

2 (verde): Clave 3:0

2 (rojo): Clave 7:4

3 (azul): Clave 11:8

3 (verde): Clave 15:12

3 (rojo): Clave 19:16

4 (azul): Clave 23:20

4 (verde): Clave 27:24

4 (rojo): Clave 31:28

Cada uno de los 4 bits superiores (más importantes) de cada componente se codifica con cada parte de código de 4 bits. Esto permite una cierta reducción de la profundidad de bit de color de la visualización cuando la imagen se reproduce (por ejemplo, tal como en un ordenador de sobremesa de 16 bits).

A continuación, cada formato de archivo de pantalla se codifica cargando el archivo en la memoria, descomprimiéndole para producir una imagen de color en bruto de 24 bits, codificando los 4 píxeles, a continuación, recomprimiendo la imagen de nuevo en su formato original y sustituyendo el archivo original en el disco 6 duro.

Para codificar los formatos de imágenes gráficas como JPEG o PCX, el algoritmo necesita simplemente modificar los cuatro píxeles de 24 bits contenidos en la memoria como partes de componentes contiguos de píxeles, cada uno de 8 bits. Sin embargo, para los archivos HTML, los píxeles se codifican sumando un nuevo 'div' en la secuencia de comandos HTML en el archivo, que describe los píxeles que pueden dibujarse en la esquina superior izquierda.

La detección de la aparición de los píxeles durante una transacción o interacción se realiza posteriormente en tiempo real mediante la aplicación 90 adicional, leyendo regularmente los píxeles reproducidos por Windows en la esquina superior izquierda de la pantalla de visualización del dispositivo 8 de visualización. Los cuatro píxeles leídos se decodifican en sus partes constitutivas cadena de cabecera y de clave. Si la cadena de cabecera coincide con una cadena de claves almacenada por la aplicación 90 y que representa un estado específico, la cadena de clave se usa por la aplicación 90 para identificar el estado.

5

10

15

20

25

30

35

40

45

50

55

El procedimiento de decodificación se realiza (normalmente) cada 50 ms durante la operación. Cada periodo, la aplicación usa las llamadas de API Win32 al sistema 86 operativo Windows para recuperar los datos de píxel de los píxeles reproducidos en la visualización de cliente en la esquina superior izquierda (o ligeramente desplazados como se necesite en función del comportamiento de la aplicación de ATM). A continuación, los datos de píxel se descodifican usando un inverso del algoritmo de codificación para producir los valores de cabecera y clave. La cabecera se comprueba con el valor fijo para garantizar que la clave es válida y la clave se comprueba con unas opciones conocidas predefinidas.

Si hay una coincidencia, entonces se toma la acción apropiada para esa clave codificada. Por ejemplo, la aplicación 90 puede determinar basándose en las condiciones predefinidas si el estado identificado es uno para el que el contenido debería enviarse al dispositivo 8 de visualización para reemplazar o superponer la pantalla visualizada.

Usando la codificación de píxel descrita anteriormente, puede realizarse la detección de estado de una manera oportuna por la realización de la figura 5, de manera que la presentación de marketing u otro contenido se realiza dentro de un retardo imperceptible después de la reproducción de una pantalla de interfaz de ATM. En variantes de la realización, para las etapas seleccionadas la aplicación 90 adicional espera durante un período de retardo predeterminado después de la detección del cambio a un estado específico antes de presentar el contenido de marketing u otro.

Todas las aplicaciones de ATM reproducen pantallas, pero en formatos diferentes. La codificación de píxel puede aplicarse a todos los formatos conocidos y puede proporcionar la detección de estado independiente de la plataforma, sin necesidad de conocimientos específicos del flujo de estado de la aplicación de ATM, el procedimiento de reproducción o el sincronismo. Los flujos de estado pueden cambiar sin la necesidad de reconfigurar las codificaciones.

Las técnicas de codificación y decodificación no se limitan a las descritas anteriormente en relación con la figura 5. Por ejemplo, en el modo de operación descrito anteriormente, el módulo de detección de estado solicita los datos de pantalla reproducidos a través de llamadas API de Win32 al sistema operativo Windows, por ejemplo, a la API DirectX o GDI del sistema operativo Windows, mientras que en unos modos alternativos de operación, el módulo de detección de estado puede interceptar los datos de visualización antes de que se reproduzcan, y después del procesamiento adecuado para extraer los valores de los píxel codificados a partir de los datos no reproducidos. Este procedimiento es, en general, menos eficiente que la extracción de los valores de píxel a partir de los datos reproducidos. En otros modos de operación, el módulo de detección de estado puede dirigir los componentes del sistema por debajo del sistema operativo con el fin de obtener los valores de píxel. El número y la posición de los píxeles también pueden variarse. En muchas realizaciones, se seleccionan el número y la posición de los píxeles para codificar de manera que la codificación, o las diferencias en la codificación entre diferentes pantallas, no afecte sustancialmente a la apariencia de la visualización y/o sea sustancialmente imperceptible para el usuario. Por ejemplo, puede usarse un pequeño número de píxeles, y los píxeles pueden localizarse en o cerca de un borde o una esquina de la pantalla.

Como se ha mencionado anteriormente, la aplicación adicional en las realizaciones de las figuras 1 a 5 es una aplicación para proporcionar unos contenidos de marketing u otros a un usuario. El contenido de marketing u otros es un contenido que suele ser adicional a cualquier contenido que se proporciona por la aplicación 21 de ATM. La aplicación 38 adicional también puede proporcionar unos procedimientos de interacción de usuario adicionales, y el procedimiento y el almacenamiento de usuario responden a tales procedimientos. Como se describe en el presente documento, la aplicación adicional puede recibir datos desde y controlar dispositivos de hardware a través de las API de intermediario, los proveedores de servicios de XFS, u otras API y controladores de dispositivos existentes.

La aplicación adicional se descarga desde el servidor 5, o desde un servidor de terceros, al ATM 2 y se instala.

El contenido de marketing y otros a proporcionarse a un usuario también se descargan desde el servidor 5, o desde un servidor de terceros, y se almacenan en el almacén 6 de datos. El contenido puede empaquetarse y comprimirse en un solo archivo para su distribución. En las realizaciones alternativas, el contenido de marketing y otros pueden transmitirse desde el servidor a la aplicación 38 adicional cuando sea necesario.

Tras la instalación, la aplicación adicional genera e instala una o más de las API del intermediario o las API 52, 60, 72 cuando sea necesario.

La aplicación adicional puede hacerse funcionar para visualizar el vídeo en pantalla completa o las imágenes fijas en el dispositivo 6 de visualización en cualquier formato adecuado. La aplicación adicional incluye unos componentes de detección de estado que detectan las configuraciones y el estado de visualización del ATM 2, y opcionalmente informan al servidor 5. La aplicación adicional y/o el servidor 5 posteriormente proporcionan un contenido en el formato de archivo y resolución correctos para el ATM 2, y en particular para el dispositivo de visualización y la impresora de recibos del ATM 2, basándose en las configuraciones detectadas y el estado de visualización.

imagen9

imagen10

Claims

imagen1

imagen2