ES2204242A1

ES2204242A1 - Sistema para realizar transacciones de pagos mediante telefonia movil.

Info

Publication number: ES2204242A1
Application number: ES200101490A
Authority: ES
Inventors: Carlos Vila Vergara; Angel Luis Solla Hernandez; Carlos Portasany Sanchez; Javier Santamaria Navarrete; Ignacio Bas Soria; Jose Luis Martinez Dalmau
Original assignee: Mobipay Espana SA
Current assignee: Mobipay Espana SA
Priority date: 2001-06-28
Filing date: 2001-06-28
Publication date: 2004-04-16
Anticipated expiration: 2021-06-28
Also published as: ES2204242B1

Abstract

Sistema para realizar transacciones de pagos mediante telefonía móvil. La presente invención consiste en un sistema de pagos mediante la red de telefonía móvil, basado en un servicio de mensajes cortos y en un conjunto de aplicaciones informáticas residentes en el terminal de punto de venta y en la tarjeta de identificación del usuario del terminal móvil del comprador o vendedor. El sistema soporta distintas formas de pago a efectuar en distintas entidades financieras, y contempla diversas transacciones como: selección del modo de pago, anulación/devolución, consulta de última operación, movimientos, totales o saldos, duplicados de operación, configuración del modo de pago por defecto o cambio del número de identificación personal. El sistema ofrece máxima seguridad pues: el comprador no precisa facilitar ningún dato personal al vendedor, no se precisa enviar el número de identificación personal (empleado solamente para cifrar y descifrar transacciones) y dichas transacciones son procesadaspor una entidad autorizadora que hace de intermediario entre comprador, vendedor y la entidad financiera.

Description

Sistema para realizar transacciones de pagos mediante telefonía móvil.

Objeto de la invención

El objeto de la invención es implementar un sistema de pagos mediante la red de telefonía móvil, basado en un "SMS" (Servicio de Mensajes Cortos) y en un "SIM Toolkit" (estándar GSM 11.14 que permite definir a los operadores de telefonía móvil un conjunto de aplicaciones informáticas residentes en la tarjeta SIM del "TPV" (Terminal de Punto de Venta) y en la tarjeta "SIM" de identificación del usuario del Terminal Móvil del comprador o vendedor). El sistema soporta distintas formas de pago a efectuar en distintas Entidades Financieras, y contempla diversas transacciones como: selección del modo de pago, anulación/devolución, consulta de última operación, movimientos, totales o saldos, duplicados de operación, configuración del modo de pago por defecto o cambio del "NIP" (Número de Identificación Personal).

El sistema ofrece además máxima seguridad pues: el comprador no precisa facilitar ningún dato personal al vendedor, no se precisa enviar el "NIP" (empleado solamente para cifrar y descifrar transacciones) y dichas transacciones son procesadas por una Entidad Autorizadora que hace de intermediario entre comprador, vendedor y la Entidad Financiera.

La presente invención ha sido desarrollada en base a los siguientes requerimientos:

-: Vocación de convertirse en un estándar: debe ser completamente abierto para cualquier entidad financiera u Operador de telefonía.

-: El teléfono móvil no se convierte en un medio de pago en sí mismo, sino en un canal seguro para la realización de pagos en entornos físicos y digitales que respeta las reglas de negocio actuales.

-: Su manejo debe ser sencillo y "natural" tanto para los usuarios como los comerciantes.

-: El usuario debe poder asociar a su teléfono móvil tantos medios de pago como necesite.

-: El usuario no debe proporcionar ningún dato personal al comerciante: máxima seguridad.

-: Permitir una mayor eficiencia en costes y ofrecer mayores cotas de seguridad para todos los participantes: usuarios, comerciantes y Entidades Financieras.

-: Realizar pagos tanto en entornos físicos como virtuales.

-: Ofrecer un nuevo canal de pago a comercios, profesionales independientes, grandes adquirientes y procesadores de transacciones, etc.

-: Habilitar un nuevo canal a otros servicios: salud, mecanismos de fidelización, tarjetas privadas, etc.

-: Proporcionar mecanismos que faciliten el control y gestión del medio de pago más allá de los actuales.

-: Operar en diferentes monedas.

-: Extenderse a operación internacional.

-: El sistema es totalmente abierto y flexible, en vistas de que:

-: el medio o medios de pago se asocia en la entidad financiera y es propiedad de ésta. Esto hace posible utilizar: tarjetas de crédito, débito y "cash" (o calderilla) especificas para este canal; tarjetas de crédito, débito y "cash" (o calderilla) existentes; tarjetas privadas, tarjetas de fidelización, cargos directos en cuenta bancaria, "Pay-per-View" (o pago por visión); cualquier producto que decida el emisor del medio de pago;

-: una entidad financiera que desee utilizar este canal, sólo debe implementar el protocolo propuesto y realizar un acuerdo comercial con el titular de la invención y los operadores que desee.

-: La seguridad del sistema ha sido el principal condicionante del diseño:

-: todos los mensajes enviados y recibidos por clientes y comerciantes son cifrados 3XDES extremo a extremo (desde el "SIM" (Módulo de Identidad del Suscriptor) hasta la entidad financiera);

-: el cliente sólo puede utilizar la tarjeta "SIM" asociada al medio de pago;

-: el "NIP" (o Número de Identificación Personal) es entregado por la entidad financiera directamente al cliente;

-: el "NIP" no viaja cifrado ni se valida localmente: simplemente, las claves utilizadas para el cifrado se derivan a partir de dicho "NIP";

-: el sistema garantiza la privacidad e integridad de los datos de la transacción, incluido el comercio, importe y medio de pago de la transacción;

-: como mecanismo de seguridad adicional, se comprueba la identidad de los elementos de red;

-: el centro o centros servidores de mensajes cortos (o "SMSC") son de uso exclusivo para el medio de pago: sólo las entidades financieras tienen acceso al mismo;

-: adicionalmente, toda la seguridad "GSM" (estándar del Sistema Global para comunicaciones Móbiles) está presente en todo momento;

-: el sistema se somete a auditoría y certificación de seguridad por las entidades financieras.

La invención aporta significativas ventajas para los usuarios:

-: Seguridad: en ningún momento se facilita ningún dato personal al comerciante (número de teléfono, de tarjeta, etc.) tanto en entornos físicos como digitales).

-: Conveniencia y facilidad de uso: entrada de datos sencilla y guiada por la aplicación, sin necesidad de encontrarse junto al "TPV" (Terminal de Punto de Venta) y sin necesidad de entregar nada al comerciante.

-: Posibilidad de reemplazar todas las tarjetas de plástico por el teléfono móvil.

-: Control sobre los gastos más sencillo, rápido e inmediato.

-: Permite extender los pagos electrónicos a sectores de actividad no cubiertos por los medios tradicionales.

-: Permite acceder a los medios de pago electrónicos a jóvenes y adolescentes.

ventajas para los comerciantes:

-: Aporta un nuevo canal con medios extendidos de seguridad.

-: Mayor facilidad de uso y gestión.

-: Valor añadido: extremadamente potente en el entorno de compras telefónicas y no presenciales.

-: Dirigido a la totalidad de usuarios de telefonía móvil.

-: Permite acceder a los medios de pago electrónico a sectores no cubiertos por los medios actuales (quioscos, bares, venta a domicilio, etc.).

-: Utiliza el mecanismo más adecuado en cada caso, desde los "TPVs" (Terminales de Punto de Venta) existentes a un simple teléfono móvil sin pérdida de funcionalidad.

y ventajas para los emisores de los medios de pago:

-: No rompe las actuales reglas del juego.

-: No requiere modificar los flujos financieros establecidos.

-: Aporta un nuevo canal con ventajas extendidas de seguridad: el usuario lleva consigo un teclado para la introducción de su Número de Identificación Personal.

-: No requiere cambios significativos en la gestión de los clientes o del medio de pago.

-: Permite ofrecer cualquier producto de pago de la entidad.

-: Permite disponer de una red de medios de pago con una inversión mínima a aquellas entidades que no disponen de ellas.

-: Permite extender el uso y funcionalidad de las tarjetas privadas u de fidelización.

-: No existe limitación ni exclusividad de ningún tipo.

Antecedentes de la invención

Se conocen procedimientos y sistemas de pagos mediante telefonía móvil que se basan en el empleo de un terminal de vendedor, al que se añade un teléfono móvil para efectuar las transacciones.

También cabe señalar procedimientos en los que el pago se efectúa mediante la identificación del comprador, que consiste en asegurarse de que dicho comprador es un abonado inscrito regularmente en una lista de abonados de la red de comunicación. Estos procedimientos presentan la desventaja de que la confirmación de la transacción se produce primero del servidor de pagos al servidor del comercio y después del servidor del comercio al comprador, con lo que el servidor de pagos no puede certificar que la confirmación de la transacción sea enviada al comprador. Además se conocen sistemas en los que el teléfono móvil no forma parte únicamente de un terminal punto de venta, sino que mediante dicho terminal se efectúa el pago, para lo que es necesario modificar el terminal de telefonía móvil para que se puedan efectuar transacciones seguras.

Otros sistemas se basan en efectuar el envío del número de cuenta bancaria del comprador al vendedor sobre una conexión desde el móvil del vendedor al banco. Estos sistemas presentan el inconveniente de que el usuario debe entregar su número de cuenta a una persona que pudiera no conocer, lo cual representa un riesgo muy alto.

Además, tras la decisión de compra por parte del comprador, las comunicaciones sólo se efectúan entre el servidor del medio de pago y el servidor del vendedor, con lo que se supone que el comprador y vendedor son clientes del servidor de la forma de pago para que éste pueda compensar entre sus cuentas.

Otros sistemas del estado de la técnica se refieren a un método para llevar a cabo una transacción entre un comprador, que dispone de un terminal de telefonía móvil, y un vendedor, estando ambos dados de alta en una plataforma de autorización. Para realizar la transacción, se establece un contacto entre el comprador y el vendedor, y se llega a un acuerdo de compra; luego, el comprador envía un mensaje de confirmación que incorpora la identificación del comprador. Una copia de confirmación de compra se envía, de forma automática, a la plataforma de autorización, desde el comprador o desde el vendedor.

También se puede citar un sistema para activar un surtidor mediante un terminal de telefonía móvil. Para repostar combustible, el comprador dirige una llamada desde su teléfono móvil a una unidad, e introduce un primer código de seguridad. La unidad comprueba el número de teléfono del comprador y el primer código de seguridad, comprueba que el código corresponde al número de teléfono y comprueba si el comprador así verificado está en una lista negra. Si el comprador verificado no está en la lista negra, se le concede acceso al sistema y el comprador puede introducir el código identificador de un surtidor en concreto y repostar combustible.

Asimismo, se puede citar un sistema para avisar a un propietario de una tarjeta de pago, tarjeta de crédito, teléfono móvil o similar, acerca de un uso fraudulento. Por ejemplo, cuando se intenta realizar una transacción utilizando una tarjeta de crédito en un terminal de un punto de venta, el sistema detecta que se intenta utilizar la tarjeta de crédito y envía un aviso a un dispositivo de telecomunicaciones, tal como un terminal de telefonía móvil, del propietario de la tarjeta, con el fin de que éste pueda autorizar o desautorizar la transacción, o simplemente para que éste quede informado sobre las transacciones efectuadas.

También se puede citar un sistema de comercio electrónico que incluye un teléfono móvil, el cual puede estar provisto con medios para realizar una amplia gama de operaciones (tarjeta telefónica, tarjeta de pago, entrada electrónica para acceder a espectáculos, etc.).

También se puede citar un sistema de pago utilizando un terminal de telefonía móvil. En este caso el comprador envía al centro de transacciones, información que le identifique, e información sobre el importe de la transacción y un identificador del vendedor.

También se puede citar una forma de operar una máquina expendedora mediante un terminal de telefonía móvil.

También se puede citar un sistema de pago por un terminal de telefonía móvil, que incluye el envío, desde un terminal de telefonía móvil de un comprador, de datos que identifican a un vendedor.

Descripción de la invención

El sistema para realizar transacciones de pagos mediante telefonía móvil entre:

-: al menos un comprador provisto con un terminal de telefonía móvil en cuya "SIM" (Módulo de Identificación de Usuario) reside al menos una aplicación informática para compradores;

-: al menos una entidad autorizadora de la transacción de pago; y

-: al menos un vendedor, provisto con un terminal de vendedor seleccionado entre: un terminal de punto de venta GSM y un terminal de telefonía móvil, estando conectado dicho terminal de vendedor a un dispositivo "SIM" (Módulo de Identificación de Usuario), en donde reside al menos una aplicación informática para vendedores;

donde dicho sistema de transacción de pagos comprende, al menos:

-: una primera etapa, consistente en una generación de al menos un mensaje de telefonía móvil por parte de la aplicación de compradores residente en el terminal de telefonía móvil del comprador, conteniendo dicho mensaje al menos un dato relativo a una compra efectuada por el comprador;

-: una segunda etapa, en donde tras recibir dicho mensaje telefonía móvil con los datos de la compra, la entidad autorizadora genera al menos un mensaje que contiene al menos, un dato relativo a la autorización de la transacción del pago de la compra, y cuyo destinatario está seleccionado entre el vendedor, el comprador y ambos; y

-: una tercera etapa, en la que al menos una aplicación informática, seleccionada entre la aplicación informática de comprador, la aplicación informática de vendedor y ambas, recibe, procesa y muestra el mensaje generado por la entidad autorizadora;

en cuyo sistema la aplicación informática para compradores comprende medios para mostrar en una pantalla del terminal de telefonía móvil del comprador:

-: al menos una opción de acceso a un módulo de pagos por telefonía móvil, estando dicha opción de acceso provista con medios de selección por parte del comprador de dicho módulo de pagos;

-: dentro de dicho módulo de pagos y formando parte integrante del mismo:

-: al menos una opción de acceso a un menú de entidades financieras activas para dicho comprador, estando dicho menú provisto con medios de selección por parte del comprador, de una de las entidades financieras mostradas en el menú;

-: al menos una opción de acceso a un menú de formas de pago activas para dicho comprador en la entidad financiera seleccionada, estando dicho menú de formas de pago provisto con medios de selección por parte del comprador, de uno de los medios de pago mostrados en el menú;

-: al menos un mensaje de petición de identificación de una compra seleccionada entre: referencia de la compra, importe de la compra y combinaciones de los mismos, estando dicha petición provista con medios para la introducción de la identificación de la compra por parte del comprador;

-: al menos un mensaje de petición de identificación del vendedor, estando dicha petición provista con medios para la introducción de la identificación del vendedor por parte del comprador;

-: al menos un mensaje de petición de un código de seguridad del propio comprador, estando dicha petición provista con medios para la introducción del código de seguridad del comprador por parte de dicho comprador;

-: medios de generación de al menos un mensaje saliente de telefonía móvil, conteniendo dicho mensaje al menos un dato relativo a la compra seleccionado entre: la entidad financiera seleccionada, la forma de pago seleccionada, identificación de la compra, identificación del vendedor y combinaciones de los mismos;

-: medios de cifrado de dicho mensaje saliente de telefonía móvil que emplean el código de seguridad del comprador para realizar dicho cifrado.

En una realización de la invención, el sistema para realizar transacciones de pagos mediante telefonía móvil está caracterizado porque la aplicación informática para compradores, adicionalmente comprende medios para mostrar en la pantalla del terminal de telefonía móvil del comprador:

-: al menos una opción de acceso a un módulo de lectura de comprobantes de compra recibidos en el terminal de telefonía móvil del comprador por medio de mensajes entrantes de telefonía móvil, estando dicha opción de acceso provista con medios de selección por parte del comprador, del módulo de lectura de comprobantes de compra;

-: dentro de dicho módulo de lectura de comprobantes de compra y formando parte integrante del mismo:

-: al menos un mensaje de petición del código de seguridad del comprador, estando dicha petición provista con medios para la introducción del código de seguridad del comprador por parte de dicho comprador;

-: medios de descifrado de mensajes entrantes de telefonía móvil correspondientes a comprobantes de compra, que emplean el código de seguridad del comprador para descifrar el mensaje;

-: medios de extracción y de presentación en la pantalla del terminal móvil del comprador, de al menos un dato contenido en el mensaje descifrado, siendo dicho dato seleccionado entre: texto explicativo del comprobante de compra, entidad financiera, forma de pago, identificación de la compra, identificación del vendedor, código asignado a la transacción, fecha, hora y combinaciones de los mismos.

En otra realización de la invención, el sistema para realizar transacciones de pagos mediante telefonía móvil está caracterizado porque la aplicación informática para vendedores comprende medios para mostrar en una pantalla del terminal del vendedor:

-: al menos una opción de acceso a un módulo de lectura de comprobantes de venta seleccionados entre: comprobantes generados por una operación de compra realizada por un comprador y comprobantes de operaciones de vendedor, siendo recibidos dichos comprobantes en el terminal del vendedor por medio de mensajes entrantes al terminal del vendedor, estando dicha opción de acceso provista con medios de selección por parte del vendedor, del módulo de lectura de comprobantes de venta;

-: dentro de dicho módulo de lectura de comprobantes de venta y formando parte integrante del mismo:

-: al menos un mensaje de petición del código de seguridad del vendedor, estando dicha petición provista con medios para la introducción del código de seguridad del vendedor por parte de dicho vendedor;

-: medios de descifrado de mensajes entrantes de al terminal del vendedor correspondientes a comprobantes de venta, que emplean el código de seguridad del vendedor para descifrar el mensaje;

-: medios de extracción y de presentación en la pantalla del terminal del vendedor de al menos un dato contenido en el mensaje descifrado, siendo dicho dato seleccionado entre: texto explicativo del comprobante de venta, entidad financiera, forma de pago, identificación de la venta, identificación del vendedor, código asignado a la transacción, fecha, hora y combinaciones de los mismos.

En todavía otra realización de la invención, el sistema para realizar transacciones de pagos mediante telefonía móvil está caracterizado porque la aplicación informática para vendedores, adicionalmente comprende medios para mostrar en la pantalla del terminal del vendedor:

-: al menos una opción de acceso a un módulo de punto de venta, estando dicha opción de acceso provista con medios de selección por parte del vendedor de dicho módulo de punto de venta;

-: dentro de dicho módulo de punto de venta y formando parte integrante del mismo:

-: al menos una opción de acceso a un menú de operaciones de vendedor en el que se muestra al menos una operación seleccionada entre: devolución de la venta, duplicado de transacción de venta y consulta de totales de venta, estando dicho menú provisto con medios de selección por parte del vendedor, de una de las operaciones de vendedor mostradas en el menú;

En una ulterior realización de la invención, el sistema para realizar transacciones de pagos mediante telefonía móvil está caracterizado porque cuando el vendedor selecciona la opción de devolución de venta en el menú de operaciones de vendedor, la aplicación informática para vendedores comprende medios para mostrar en la pantalla del terminal del vendedor:

-: al menos un mensaje de petición del importe de la venta, estando dicha petición provista con medios para la introducción del importe de la venta por parte del vendedor;

-: al menos un mensaje de petición de un código asignado a la transacción a devolver, estando dicha petición provista con medios para la introducción por parte del vendedor del código de la transacción a devolver;

-: al menos un mensaje de petición de un código de seguridad del vendedor, estando dicha petición provista con medios para la introducción del código de seguridad del vendedor por parte de dicho vendedor;

-: medios de generación de al menos un mensaje saliente del terminal del vendedor, conteniendo dicho mensaje al menos un dato relativo a la devolución de venta seleccionado entre: el importe de la venta, el código asignado a la transacción a devolver y combinaciones de los mismos;

-: medios de cifrado de dicho mensaje saliente del terminal del vendedor, que emplean el código de seguridad del vendedor para realizar dicho cifrado.

En otra realización más de la invención, el sistema para realizar transacciones de pagos mediante telefonía móvil está caracterizado porque cuando el vendedor selecciona la opción de duplicado de transacción de venta en el menú de operaciones de vendedor, la aplicación informática para vendedores comprende medios para mostrar en la pantalla del terminal del vendedor:

-: al menos un mensaje de petición de un código asignado a la transacción de venta a duplicar, estando dicha petición provista con medios para: la introducción por parte del vendedor de un código seleccionado entre:

-: la introducción por parte del vendedor del código de la transacción de venta a duplicar; y

-: la no introducción por parte del vendedor de ningún código determinado, indicando de este modo que la transacción de venta a duplicar corresponde a la última venta realizada;

-: medios de generación de al menos un mensaje saliente del terminal del vendedor, conteniendo dicho mensaje al menos el código asignado a la transacción de venta a duplicar;

En otra ulterior realización de la invención, el sistema para realizar transacciones de pagos mediante telefonía móvil está caracterizado porque cuando el vendedor selecciona la opción de consulta de totales de venta en el menú de operaciones de vendedor, la aplicación informática para vendedores comprende medios para mostrar en la pantalla del terminal del vendedor:

-: al menos un mensaje de petición de al menos una fecha sobre la que el vendedor desea realizar la consulta de totales de venta, estando dicha petición provista con medios para la introducción por parte del vendedor de la fecha sobre la cual desea realizar la consulta de totales de venta;

-: medios de generación de al menos un mensaje saliente del terminal del vendedor, conteniendo dicho mensaje al menos una fecha relativa a la consulta de totales de venta;

En una otra realización adicional de la invención, el sistema para realizar transacciones de pagos mediante telefonía móvil está caracterizado porque la aplicación informática para compradores incluye en el menú de formas de pago:

-: al menos una opción de acceso a una forma de pago establecida por defecto y activa para dicho comprador en la entidad financiera seleccionada; y

-: al menos una opción de acceso a un menú en el que se muestran el resto de formas de pago activas para dicho comprador en la entidad financiera seleccionada, estando dicho menú de resto de formas de pagos provisto con medios de selección por parte del comprador, de uno de los medios de pago mostrados en el menú;

En una realización adicional de la invención, el sistema para realizar transacciones de pagos mediante telefonía móvil está caracterizado porque tras la selección de una entidad financiera en el menú de entidades financieras, la aplicación informática para compradores incluye:

-: al menos una opción de acceso a un menú de operaciones de comprador relativas a la entidad financiera seleccionada, en el que se muestra al menos una operación de comprador seleccionada entre: consulta de saldo, consulta de compra, cambio del código de seguridad del comprador, configuración de la forma de pago seleccionada por defecto, configuración de una moneda a emplear por defecto y combinaciones de los mismos, estando dicho menú provisto de con medios de selección por parte del comprador, de una de las operaciones de comprador mostradas en el menú.

En otra realización de la invención, el sistema para realizar transacciones de pagos mediante telefonía móvil está caracterizado porque cuando el comprador selecciona la opción de consulta de saldo en el menú de operaciones de comprador, la aplicación informática para compradores comprende medios para mostrar en la pantalla del terminal del comprador:

-: medios de generación de al menos un mensaje saliente del terminal de telefonía móvil del comprador, conteniendo dicho mensaje al menos un dato relativo a la consulta de saldo seleccionado entre: la entidad bancaria seleccionada, la forma de pago seleccionada y combinaciones de las mismas;

-: medios de cifrado de dicho mensaje saliente del terminal de telefonía móvil del comprador, que emplean el código de seguridad del comprador para realizar dicho cifrado.

En otra realización más de la invención, el sistema para realizar transacciones de pagos mediante telefonía móvil está caracterizado porque cuando el comprador selecciona la opción de consulta de compra en el menú de operaciones de comprador, la aplicación informática para compradores comprende medios para mostrar en la pantalla del terminal del comprador:

-: al menos un mensaje de petición de al menos una fecha sobre la que el comprador desea realizar la consulta de compra, estando dicha petición provista con medios para la introducción por parte del comprador de la fecha sobre la cual desea realizar la consulta de compra;

-: medios de generación de al menos un mensaje saliente del terminal de telefonía móvil del comprador, conteniendo dicho mensaje al menos un dato relativo a la consulta de compra seleccionado entre: la entidad bancaria seleccionada, identificación del vendedor, la forma de pago seleccionada, la fecha de consulta y combinaciones de los mismos;

Adicionalmente, en otra realización de la invención, el sistema para realizar transacciones de pagos mediante telefonía móvil está caracterizado porque cuando el comprador selecciona la opción de cambio del código de seguridad del comprador en el menú de operaciones de comprador, la aplicación informática para compradores comprende medios para mostrar en la pantalla del terminal del comprador:

-: al menos un mensaje de petición de un código de seguridad ya existente del comprador, estando dicha petición provista con medios para la introducción del código de seguridad ya existente del comprador por parte de dicho comprador;

-: al menos un mensaje de petición de un nuevo código de seguridad del comprador, estando dicha petición provista con medios para la introducción del nuevo código de seguridad del comprador por parte de dicho comprador;

-: al menos un mensaje de petición de confirmación del nuevo código de seguridad del comprador, estando dicha petición provista con medios para la introducción de la confirmación del nuevo código de seguridad del comprador por parte de dicho comprador;

-: medios de generación de al menos un mensaje saliente del terminal de telefonía móvil del comprador, conteniendo dicho mensaje al menos un dato relativo al cambio del código de seguridad del comprador;

También, de acuerdo con una ulterior realización de la invención, el sistema para realizar transacciones de pagos mediante telefonía móvil está caracterizado porque cuando el comprador selecciona la opción de configuración de la forma de pago seleccionada por defecto en el menú de operaciones de comprador, la aplicación informática para compradores comprende medios para mostrar en la pantalla del terminal del comprador:

-: medios de almacenamiento de la forma de pago seleccionada en la aplicación informática para compradores;

En otra realización más de la invención, el sistema para realizar transacciones de pagos mediante telefonía móvil está caracterizado porque cuando el comprador selecciona la opción de configuración de la moneda a emplear por defecto en el menú de operaciones de comprador, la aplicación informática para compradores comprende medios para mostrar en la pantalla del terminal del comprador:

-: al menos una opción de acceso a un menú de monedas a ser empleadas, estando dicho menú provisto con:

-: medios de selección por parte del comprador, de una de las monedas mostradas en el menú,

-: medios de almacenamiento de la moneda seleccionada en la aplicación informática para compradores;

En otra realización de la invención, el sistema para realizar transacciones de pagos mediante telefonía móvil está caracterizado porque con anterioridad al mensaje de petición del código de seguridad del comprador, la aplicación informática para compradores comprende medios para mostrar en la pantalla del terminal de telefonía móvil del comprador, al menos un dato del conjunto de datos seleccionados e introducidos anteriormente por el comprador.

En todavía otra realización de la invención, el sistema para realizar transacciones de pagos mediante telefonía móvil está caracterizado porque con anterioridad al mensaje de petición del código de seguridad del vendedor, la aplicación informática para vendedores comprende medios para mostrar en la pantalla del terminal del vendedor, al menos un dato del conjunto de datos seleccionados e introducidos anteriormente por el vendedor.

En todavía otra realización más de la invención, el sistema para realizar transacciones de pagos mediante telefonía móvil está caracterizado porque con anterioridad al mensaje de petición del código de seguridad del comprador, la aplicación informática para compradores comprende medios para mostrar en la pantalla del terminal del comprador:

-: al menos una opción de acceso a un menú de monedas, estando dicho menú de monedas provisto con medios de selección por parte del comprador, de una de las monedas mostradas en el menú, en la cual dicho comprador solicita recibir los importes relativos a la consulta;

También, de acuerdo con otra realización de la invención, el sistema para realizar transacciones de pagos mediante telefonía móvil está caracterizado porque con anterioridad al mensaje de petición del código de seguridad del vendedor, la aplicación informática para vendedores comprende medios para mostrar en la pantalla del terminal del vendedor:

-: al menos una opción de acceso a un menú de monedas, estando dicho menú de monedas provisto con medios de selección por parte del vendedor, de una de las monedas mostradas en el menú, en la cual dicho vendedor solicita recibir los importes relativos a la consulta;

En otra realización de la invención, el sistema para realizar transacciones de pagos mediante telefonía móvil está caracterizado porque con anterioridad al mensaje de petición del importe de la venta, la aplicación informática para vendedores comprende medios para mostrar en la pantalla del terminal del vendedor:

-: al menos una opción de acceso a un menú de monedas, estando dicho menú de monedas provisto con medios de selección por parte del vendedor, de una de las monedas mostradas en el menú, en la cual dicho vendedor introducirá el importe de la venta devolver;

En otra realización de la invención, el sistema para realizar transacciones de pagos mediante telefonía móvil está caracterizado porque la aplicación informática para compradores comprende medios para verificar criterios de validez en los dígitos, caracteres y símbolos introducidos por el comprador, así como medios mostrar en la pantalla del terminal del comprador mensajes informativos relativos a la introducción inválida de dichos dígitos, caracteres y símbolos.

En otra realización de la invención, el sistema para realizar transacciones de pagos mediante telefonía móvil está caracterizado porque la aplicación informática para vendedores comprende medios para verificar criterios de validez en los dígitos, caracteres y símbolos introducidos por el vendedor, así como medios mostrar en la pantalla del terminal del vendedor mensajes informativos relativos a la introducción inválida de dichos dígitos, caracteres y símbolos.

En otra realización de la invención, el sistema para realizar transacciones de pagos mediante telefonía móvil está caracterizado porque la aplicación informática para compradores comprende medios para mostrar en la pantalla del terminal del comprador mensajes informativos de error cuando cualquier proceso de dicha la aplicación informática para compradores no pueda ejecutarse, bien por causas internas a dicha aplicación, o bien por causas externas relativas a mensajes entrantes al terminal del comprador.

En otra realización de la invención, el sistema para realizar transacciones de pagos mediante telefonía móvil está caracterizado porque la aplicación informática para vendedores comprende medios para mostrar en la pantalla del terminal del vendedor mensajes informativos de error cuando cualquier proceso de la aplicación informática para vendedores no pueda ejecutarse, bien por causas internas a dicha aplicación, o bien por causas externas relativas a mensajes entrantes al terminal del vendedor.

En otra realización de la invención, el sistema para realizar transacciones de pagos mediante telefonía móvil está caracterizado porque los medios de selección y de introducción de información, de la aplicación informática para compradores, comprenden al menos un interfaz seleccionado entre: teclado, pantalla táctil, elemento giratorio, reconocimiento de voz y combinaciones de los mismos.

En otra realización de la invención, el sistema para realizar transacciones de pagos mediante telefonía móvil está caracterizado porque los medios de selección y de introducción de información, de la aplicación informática para vendedores, comprenden al menos un interfaz seleccionado entre: teclado, pantalla táctil, elemento giratorio, reconocimiento de voz y combinaciones de los mismos.

En otra realización de la invención, el sistema para realizar transacciones de pagos mediante telefonía móvil está caracterizado porque la aplicación informática para compradores está implementada conforme un estándar GSM definido para "SIM Toolkit" (estándar que permite definir a operadores de telefonía móvil un conjunto de aplicaciones residentes en el módulo de identificación del usuario).

En otra realización de la invención, el sistema para realizar transacciones de pagos mediante telefonía móvil está caracterizado porque la aplicación informática para vendedores está implementada conforme un estándar GSM definido para "SIM Toolkit" (estándar que permite definir a operadores de telefonía móvil un conjunto de aplicaciones residentes en el módulo de identificación del usuario).

En otra realización de la invención, el sistema para realizar transacciones de pagos mediante telefonía móvil está caracterizado porque el comprador tiene asignados códigos de seguridad no necesariamente coincidentes entre sí, para cada una de las entidades financieras que se encuentran activas para dicho comprador.

En otra realización de la invención, el sistema para realizar transacciones de pagos mediante telefonía móvil está caracterizado porque el vendedor tiene asignados códigos de seguridad no necesariamente coincidentes entre sí, para cada una de las entidades financieras que se encuentran activas para dicho vendedor.

En otra realización de la invención, el sistema para realizar transacciones de pagos mediante telefonía móvil está caracterizado porque el término "vendedor" es equivalente al menos, a un término seleccionado entre: persona vendedora, comercio vendedor físico, empresa vendedora física, comercio vendedor virtual, empresa vendedora virtual y combinaciones de los mismos.

Descripción una realización de la invención Aplicaciones informáticas de comprador

Al introducir una tarjeta SIM que lleve cargada estas aplicaciones SIM Toolkit en un terminal Fase 2+, aparecerá una nueva opción dentro del menú principal del terminal de telefonía móvil.

Las aplicaciones informáticas de comprador tendrán como entrada una opción de entrada al "aplicaciones de comprador", en el menú principal del terminal de telefonía móvil.

Esta opción será la cabecera de la aplicación informática SIM Toolkit. Al acceder a ella se abrirá un submenú con al menos dos opciones: "módulo de pagos" y "módulo de lectura de comprobantes de compra":

\dotable{\tabskip6pt\hfil#\hfil\tabskip0ptplus1fil\dddarstrut\cr}{
   \uh{aplicaciones de comprador}  \cr   módulo de
compras \cr   módulo de lectura de comprobantes de
compra \cr}

La primera opción permitirá al comprador realizar pagos de una manera sencilla y fiable en todos aquellos establecimientos que posean la aplicación Toolkit de vendedor cuyo funcionamiento se describe más adelante.

La segunda opción permite acceder a los mensajes informativos recibidos a consecuencia de realizar alguna operación con la opción módulo de pagos. Dichos mensajes se reciben cifrados y no es posible visualizar su contenido a través del editor de mensajes propio del terminal de telefonía móvil aunque sí borrarlos.

Estas aplicaciones estarán activas por defecto en la tarjeta SIM, es decir, el fabricante entregará las tarjetas con las aplicaciones cargadas y listas para funcionar.

Será necesario además disponer en las SIMs de la funcionalidad Data Download activada y de la aplicación de gestión remota de ficheros asociada cargada y activada. Debido al gran número de aplicaciones que es necesario cargar en estas SIMs el tamaño mínimo recomendado de EEPROM es de 32K.

Módulo de compras

Al seleccionar esta opción, se verificará que el comprador tiene al menos una entidad financiera cargada en su fichero de entidades financieras. Si no es así, se mostrará brevemente el mensaje:

\dotable{\tabskip6pt\hfil#\hfil\tabskip0ptplus1fil\dddarstrut\cr}{
  Aplicación no activada. Visite su
banco .\cr}

Tanto si el comprador confirma como si cancela este mensaje, la aplicación volverá al menú "aplicaciones de comprador".

Si el comprador dispone de al menos dos entidades financieras dadas de alta, se presentará en pantalla la lista de entidades financieras con las que ha contratado el servicio de pago. Si sólo dispone de una entidad financiera, no se mostrará esta lista, dando por sentado que será este la entidad financiera con la que se van a realizar las transacciones. Esta información se encuentra almacenada en el fichero de entidades financieras.

\dotable{\tabskip6pt\hfil#\hfil\tabskip0ptplus1fil\dddarstrut\cr}{
   \uh{entidades financieras}  \cr   banco A \cr 
 banco
B \cr}

Si el comprador pulsa la tecla de retroceso, la aplicación regresará al menú "APLICACIONES DE COMPRADOR". (Tecla de Retroceso: Tecla de un terminal móvil que permite ir hacia atrás durante la navegación en un menú SIM Toolkit. En la mayoría de los casos, no será una tecla especial sino una de las teclas utilizadas de modo usual en el teléfono, por ejemplo, "Cancelar una llamada" (a la que se añade una nueva funcionalidad).

Si el comprador selecciona uno de las entidades financieras activadas, la aplicación comprobará que existe una tarjeta marcada como predeterminada para este banco en el fichero de tarjetas. En caso de no existir, se avisará al comprador del error mostrando brevemente el mensaje:

\dotable{\tabskip6pt\hfil#\hfil\tabskip0ptplus1fil\dddarstrut\cr}{
  Error en datos .\cr   Visite una tienda de su Operador de
Telefonía \cr}

Tanto si el comprador confirma como si cancela este mensaje, la aplicación volverá al menú "aplicaciones de comprador". Realizaremos la misma verificación en el caso en el que no se muestra el menú de entidades financieras por existir sólo una activada.

Caso de existir la opción predeterminada, la aplicación mostrará un menú con las siguientes opciones:

\dotable{\tabskip6pt\hfil#\hfil\tabskip0ptplus1fil\dddarstrut\cr}{
   \uh{Banco A}  \cr   Pago Habitual \cr 
 Otros Pagos \cr   Saldo \cr   Consultas \cr 
 Cambio NIP \cr 
 Configurar \cr}

(NIP bancario: Clave de 4 dígitos asociada a una tarjeta de entidad financiera. En la aplicación SIM Toolkit se asociará un NIP a una entidad financiera y no a una forma de pago. El comerciante también dispondrá de un NIP asociado a su TPV).

Los NIPs de cliente no deben almacenarse nunca en la SIM.

Como título del menú, se presentará el nombre de la entidad financiera que el cliente haya seleccionado previamente o del existente, caso de disponer de una sola entidad financiera dada de alta.

Si el comprador dispone de una sola entidad financiera activada, será esta la pantalla que se muestre directamente obviando la que mostraba la lista de entidades financieras.

Si el comprador decide cancelar este menú utilizando la tecla de retroceso, la aplicación volverá al menú "entidades financieras", caso de disponer de más de una entidad financiera cargada, en caso contrario (sólo se dispone de una entidad financiera), volverá al menú "aplicaciones de comprador".

Pago habitual

Si se selecciona esta opción, la aplicación preguntará al comprador por el importe. A través de la opción "Configurar" será posible seleccionar la moneda preferida (Euro o Peseta) a la hora de realizar las compras. Al entregar la tarjeta al cliente la moneda predeterminada será la peseta. Si la moneda preferida es la peseta, se mostrará el mensaje:

\dotable{\tabskip6pt\hfil#\hfil\tabskip0ptplus1fil\dddarstrut\cr}{
   \uh{Importe: Pts}  \cr  - - - - - -
-\cr}

\newpage

Si la moneda preferida es el Euro, el mensaje mostrado será:

\dotable{\tabskip6pt\hfil#\hfil\tabskip0ptplus1fil\dddarstrut\cr}{
   \uh{Importe: E}  \cr 
  \uh{0*00E}  \cr  - - - - - - - -
-\cr}

En ambos casos, el comprador podrá teclear un máximo de 12 y un mínimo de 1 dígito.

Si el comprador pulsa la tecla de retroceso, la aplicación regresará al menú "Banco A" (en este ejemplo concreto).

En el caso de que la moneda predeterminada sea la peseta, la aplicación validará que el comprador no introduzca los caracteres `*', `#' y `+' como parte del importe. En caso de hacerlo, se advertirá de ello mostrando brevemente el mensaje:

\dotable{\tabskip6pt\hfil#\hfil\tabskip0ptplus1fil\dddarstrut\cr}{
  Introduzca sólo
dígitos \cr}

Tanto si el comprador confirma como cancela el mensaje, se volverá a solicitar al mismo el importe.

En el caso de que la moneda predeterminada sea el Euro, la aplicación validará que el comprador no introduzca más de 9 dígitos en la parte entera. En caso de que esto ocurra, la aplicación mostrará el mensaje:

\dotable{\tabskip6pt\hfil#\hfil\tabskip0ptplus1fil\dddarstrut\cr}{
  Longitud excede
límite \cr}

Una vez introducido correctamente el importe, se solicitará al comprador la referencia de su compra:

\dotable{\tabskip6pt\hfil#\hfil\tabskip0ptplus1fil\dddarstrut\cr}{
   \uh{Referencia?}  \cr  - - - - - - -
-\cr}

El comprador podrá bien teclear el código numérico correspondiente a la referencia (hasta 16 dígitos), o bien aceptar el mensaje sin introducir ninguna información. Se trata, por tanto, de un campo opcional.

Si el comprador pulsa la tecla de retroceso, se volverá a solicitar al mismo el importe del pago. En caso contrario, confirma o introduce correctamente un valor de referencia, se solicitará el identificador del comercio con el mensaje:

\dotable{\tabskip6pt\hfil#\hfil\tabskip0ptplus1fil\dddarstrut\cr}{
   \uh{Id. Comercio?}  \cr  - - - - - - -
-\cr}

Si el comprador pulsa la tecla de retroceso, la aplicación volverá a solicitar la referencia.

Dicho código tendrá una longitud mínima de 2 dígitos y máxima de 9. Tras introducir el código de comercio, se rellenará a ceros por la izquierda hasta completar los 9 dígitos y la aplicación procederá a su verificación utilizando el algoritmo de Luhn. En caso de no ser correcto, la aplicación mostrará brevemente el mensaje:

\dotable{\tabskip6pt\hfil#\hfil\tabskip0ptplus1fil\dddarstrut\cr}{
  Código de comercio
incorrecto \cr}

Transcurrido el tiempo preciso, se volverá a solicitar al cliente el número de comercio. Si el comprador pulsa la tecla de retroceso o de OK antes de que transcurra este tiempo, de igual modo, la aplicación solicitará el código de comercio.

Introducidos correctamente todos los datos necesarios para realizar un pago, la aplicación procederá a mostrar los mismos para su confirmación por parte del comprador. En este caso, el mensaje no deberá mostrarse brevemente si no hasta que el comprador desee:

\dotable{\tabskip6pt\hfil#\hfil\tabskip0ptplus1fil\dddarstrut\cr}{
  Id. Comercio: \cr   <comercio> \cr 
 Referencia: \cr   <referencia> \cr 
 Importe: \cr   <impor>PTS/E \cr 
 <banco> \cr   <tarjeta> \cr 
 Ok? \cr}

donde:

<comercio>: Será el valor del comercio introducido por el comprador previamente relleno a ceros por la izquierda hasta 9 dígitos

<referencia>: Valor de la referencia introducida por el comprador previamente

<impor>: Valor del importe introducido por el comprador previamente. En el caso de que la moneda predeterminada sea el Euro, será posible por parte del comprador la utilización de los caracteres `*', `+' y `#' para la separación de los decimales pero la aplicación formateará este campo antes de su presentación mostrando siempre dos decimales (*)

<banco>: Literal del banco seleccionado al entrar en la aplicación. La información se encuentra en el fichero de bancos.

<tarjeta>: Literal de la tarjeta marcada como predeterminada para el banco seleccionado. Por defecto, se marcará como predeterminada la primera tarjeta que se dé de alta para un banco. Su valor puede ser modificado a través de la opción de Configuración.

(*) La aplicación buscará en el campo importe empezando por la izquierda el separador decimal (`*', `+' o `#'), lo sustituirá por el carácter `,' y se asegurará que detrás del mismo aparezcan dos decimales, en base a lo siguiente:

1.-: Si el comprador no introduce ningún decimal, se añadirán dos ceros detrás de la `,': Por ej.:

\dotable{\tabskip6pt\hfil#\hfil\+\hfil#\hfil\tabskip0ptplus1fil\dddarstrut\cr}{
 123* \+  \hskip2cm  123,00\cr  123 \+  \hskip2cm 
123,00\cr}

2.-: El comprador sólo introduce un decimal, se añadirá un cero al final del importe:

\dotable{\tabskip6pt\hfil#\hfil\+\hfil#\hfil\tabskip0ptplus1fil\dddarstrut\cr}{
 123*1 \+  \hskip2cm 
123,10\cr}

3.-: El comprador introduce los dos decimales, tan sólo sustituiremos el separador introducido por el carácter `,':

\dotable{\tabskip6pt\hfil#\hfil\+\hfil#\hfil\tabskip0ptplus1fil\dddarstrut\cr}{
 123+12 \+
 \hskip2cm 123,12\cr}

4.-: El comprador introduce más de dos decimales, se truncará el importe:

\dotable{\tabskip6pt\hfil#\hfil\+\hfil#\hfil\tabskip0ptplus1fil\dddarstrut\cr}{
 123 \# 1234 \+  \hskip2cm 
123,12\cr}

5.-: Si el comprador comete algún error, p.ej. introduce más de un separador en el importe, la aplicación actuará como si de un dígito se tratase teniendo sólo validez el primer separador encontrado por la izquierda.

6.-: En el caso de que el comprador omita la parte entera del importe, p.ej. *12, la aplicación considerará dicha parte entera con valor cero, pero mostrará en pantalla la cadena: ,12.

Si una vez mostrado este mensaje de confirmación, el comprador pulsa la tecla de retroceso, la aplicación solicitará de nuevo el identificador del comercio.

Antes de pasar a solicitar el NIP, se llevará a cabo el siguiente procedimiento, con el fin de avisar al comprador sobre el estado de su fichero de mensajes cortos y evitar que no se reciba el mensaje de confirmación de compra por encontrarse este fichero lleno.

Una vez confirmados los datos de la operación, se verificará el número de registros libres en el fichero de mensajes cortos a través del fichero EFstatus. Dicho fichero debe actualizarse cada vez que un mensaje sea almacenado o borrado en el fichero EFSMS y deberá indicar en todo momento cuál es el número de registros libres que posee el fichero de mensajes cortos.

Si queda 1 registro o ninguno, la aplicación mostrará brevemente el siguiente mensaje:

\dotable{\tabskip6pt\hfil#\hfil\tabskip0ptplus1fil\dddarstrut\cr}{
  SIM llena. Imposible enviar el
mensaje \cr}

Sea cual sea la tecla pulsada por el comprador, la aplicación regresará al menú "APLICACIONES DE COMPRADOR".

Si quedan 2 ó 3 registros libres, la aplicación mostrará brevemente el siguiente mensaje:

\newpage

\dotable{\tabskip6pt\hfil#\hfil\tabskip0ptplus1fil\dddarstrut\cr}{
  SIM llena. Debe borrar algún
mensaje \cr}

Si el comprador pulsa la tecla de retroceso, la aplicación mostrará de nuevo el mensaje de confirmación de datos. En caso de no ser así, la aplicación solicitará el NIP.

Si quedan más de 3 registros, la aplicación procederá a solicitar el NIP directamente.

\dotable{\tabskip6pt\hfil#\hfil\tabskip0ptplus1fil\dddarstrut\cr}{
   \uh{NIP?}  \cr  - - - -
-\cr}

El NIP introducido tendrá una longitud mínima y máxima de 4 dígitos y el terminal móvil no revelará el valor del mismo.

Si el comprador pulsa la tecla de retroceso, se mostrará de nuevo el mensaje de confirmación de los datos introducidos. Si no es así, el comprador introduce el NIP y confirma, se procederá al envío de un mensaje corto con los datos descritos.

\nobreak\vskip.5\baselineskip\centering\begin{tabular}{|l|l|l|l|}\hline
 Campo  \+  Long  \+ Long.  \+ Valor \\   \+ mín.  \+ máx. \+
\\\hline  Comando  \+ 1  \+ 1  \+  P  \\\hline  0x01  \+ 1  \+
1  \+ Separador \\\hline  Banco  \+ 6  \+6  \+ Código asociado al
banco \\   \+  \+  \+ seleccionado. Su valor se \\   \+  \+  \+
encuentra en el fichero de bancos. \\\hline  0x01  \+ 1  \+ 1  \+
Separador \\\hline  Id. de  \+ 16  \+ 16  \+ Compuesto de 8
caracteres ASCII de \\  aplicación  \+  \+  \+ valor fijo:  BANCO
A0100  (4 de \\   \+  \+  \+ aplicación + 4 de versión) + un \\  
\+  \+  \+ número secuencial de 8 bytes \\   \+  \+  \+ codificado
en ASCII que será \\   \+  \+  \+ incrementado con el envío de cada
\\   \+  \+  \+ mensaje (1) \\\hline  0x01  \+ 1  \+ 1  \+ Separador
\\\hline  N° de  \+ 9  \+ 9  \+ Código de comercio la Entidad \\ 
Comercio  \+  \+  \+ Autorizadora. Tecleado 9 dígitos. \\\hline 
0x01  \+ 1  \+ 1  \+ Separador \\\hline  Importe  \+ 1  \+ 12  \+
Tecleado por el comprador (2) \\\hline  0x01  \+ 1  \+ 1  \+
Separador \\\hline  Moneda  \+ 1  \+ 1  \+ Seleccionado en la opción
\\   \+  \+  \+  Configurar . \\   \+  \+  \+ P (PTS) \\   \+ 
\+  \+ E (EUR) \\\hline  0x01  \+ 1  \+ 1  \+ Separador \\\hline 
Tarjeta  \+ 7  \+ 7  \+ Seleccionado en la opción \\   \+  \+  \+
 Configurar . Contendrá un código \\   \+  \+  \+ numérico de 7
dígitos en formato \\   \+  \+  \+ ASCII correspondientes a la \\  
\+  \+  \+ tarjeta seleccionada como forma de \\   \+  \+  \+ pago.
Esta información será \\   \+  \+  \+ proporcionada a la SIM en el
\\   \+  \+  \+ mensaje de activación de una \\   \+  \+  \+ tarjeta
de pago. \\\hline  0x01  \+ 1  \+ 1  \+ Separador \\\hline 
Referencia  \+ 0  \+ 16  \+ Solicitada al comprador \\\hline  0x01 
\+ 1  \+ 1  \+ Separador
\\\hline\end{tabular}\par\vskip.5\baselineskip

(1) El número secuencial se compondrá de 8 dígitos ASCII comenzando en el 0, es decir, el primer mensaje incluirá el número "00000000", el segundo "00000001",

\trama

Al llegar el número máximo "99999999", el número volverá al valor 0.

(2) En el caso de los Euros, no aparecerán los caracteres de separación `*', `+' o `#'. Este campo se enviará tal cual fue formateado antes de ser mostrado en la ventana de confirmación pero sin el carácter `,'. Es decir, si el comprador introdujo 12*5 E, la aplicación le mostrará para confirmar 12,50 E y se enviará 1250.

Dado que el mensaje corto se compone de campos de longitud variable, se utilizará para delimitar cada uno de estos campos el valor 0x01 como separador.

Este mensaje llevará cifrados los campos no sombreados con una clave obtenida a partir del NIP correspondiente al banco con el que se realiza el pago y el IMSI de la SIM. El algoritmo de cifrado será el 3XDES.

Si el comprador pulsa la tecla de retroceso, se volverá a solicitar el NIP.

Si el envío se realiza con éxito, la aplicación mostrará brevemente el mensaje:

\dotable{\tabskip6pt\hfil#\hfil\tabskip0ptplus1fil\dddarstrut\cr}{
  Petición
realizada \cr}

Si por cualquier circunstancia, el envío no puede realizarse, la aplicación mostrará el mensaje:

\dotable{\tabskip6pt\hfil#\hfil\tabskip0ptplus1fil\dddarstrut\cr}{
  Petición no
realizada \cr}

Si el comprador pulsa cualquier tecla mientras se muestra este mensaje, sea la de retroceso o no, la aplicación volverá al menú "APLICACIONES DE COMPRADOR".

Una vez enviado el mensaje corto, se recibirá de la Entidad Autorizadora un mensaje corto de confirmación de la compra conteniendo los siguientes campos:

\nobreak\vskip.5\baselineskip\centering\begin{tabular}{|l|l|l|l|}\hline
 Campo  \+ Long  \+ Long.  \+ Valor \\   \+mín  \+ max. \+ \\\hline 
Comando  \+ 2  \+ 2  \+  P1  /  P2  \\\hline  Código  \+ 6
 \+ 6  \+ Código del banco con el que se \\  Banco  \+  \+  \+
realizó la operación \\\hline  Id. de  \+ 4  \+ 4  \+  BANCO A 
\\  aplicación \+ \+ \+ \\\hline  Datos del  \+ 1  \+ 124  \+
Contenido del mensaje de \\  mensaje \+   \+  \+confirmación del
pago
\\\hline\end{tabular}\par\vskip.5\baselineskip

Otros pagos

Si se selecciona esta opción, la aplicación preguntará al comprador por la moneda en la que desea realizar el pago mostrando la siguiente lista de opciones:

\dotable{\tabskip6pt\hfil#\hfil\tabskip0ptplus1fil\dddarstrut\cr}{
   \uh{MONEDA}  \cr  Pesetas\cr 
Euros\cr}

Si el comprador pulsa la tecla de retroceso, la aplicación regresará al menú "BANCO A" (caso de que este hubiera sido el banco seleccionado). Al seleccionar una de las monedas, la aplicación solicitará el importe. Si la moneda seleccionada es la peseta, se mostrará el mensaje:

\dotable{\tabskip6pt\hfil#\hfil\tabskip0ptplus1fil\dddarstrut\cr}{
  \uh{Importe: Pts}  \cr  - - - - -
-\cr}

Si la moneda seleccionada es el Euro, el mensaje mostrado será:

\dotable{\tabskip6pt\hfil#\hfil\tabskip0ptplus1fil\dddarstrut\cr}{
   \uh{Importe: E}  \cr 
  \uh{(0*00)}  \cr  - - - - - -
-\cr}

Si el comprador pulsa la tecla de retroceso, la aplicación regresará al menú "MONEDA".

Sólo en el caso de que la moneda seleccionada sea la peseta, la aplicación validará que el comprador no introduzca los caracteres `*', `#' y `+' como parte del importe. En caso de hacerlo, se advertirá de ello mostrando brevemente el mensaje:

\dotable{\tabskip6pt\hfil#\hfil\tabskip0ptplus1fil\dddarstrut\cr}{
  Introduzca sólo dígitos
(0  -  9) \cr}

Tanto si el comprador confirma como si cancela el mensaje, se volverá a solicitar al mismo el importe.

\dotable{\tabskip6pt\hfil#\hfil\tabskip0ptplus1fil\dddarstrut\cr}{
  Longitud excede
límite \cr}

\dotable{\tabskip6pt\hfil#\hfil\tabskip0ptplus1fil\dddarstrut\cr}{
   \uh{Referencia?}  \cr  - - - - -
-\cr}

Si el comprador pulsa la tecla de retroceso, se volverá a solicitar al mismo el importe del pago. En caso contrario, se solicitará al comprador el identificador del comercio con el mensaje:

\dotable{\tabskip6pt\hfil#\hfil\tabskip0ptplus1fil\dddarstrut\cr}{
   \uh{Id. Comercio?}  \cr  - - - - - -
-\cr}

Dicho código tendrá una longitud mínima de 2 dígitos y máxima de 9 dígitos. Tras introducir el código de comercio, la aplicación lo rellenará con ceros por la izquierda hasta completar las 9 dígitos y procederá a su verificación utilizando el algoritmo de Luhn. En caso de no ser correcto, la aplicación mostrará brevemente el mensaje:

\dotable{\tabskip6pt\hfil#\hfil\tabskip0ptplus1fil\dddarstrut\cr}{
  Código de comercio
incorrecto \cr}

A continuación del comercio se solicitará al comprador la selección de uno de los formas de pago que tiene disponibles para el banco seleccionado previamente. La aplicación recorrerá el fichero de tarjetas filtrando las asociadas al banco seleccionado y mostrará una lista de las mismas al comprador con el formato:

\dotable{\tabskip6pt\hfil#\hfil\tabskip0ptplus1fil\dddarstrut\cr}{
   \uh{MODO DE PAGO}  \cr  Débito\cr 
Crédito\cr}

Si el comprador pulsa la tecla de retroceso, la aplicación solicitará de nuevo el identificador de comercio. Si, por el contrario, se selecciona uno de los modos de pago disponibles, la aplicación procederá a mostrar los datos de la transacción para su confirmación por parte del comprador. En este caso, el mensaje no deberá mostrarse brevemente si no hasta que el comprador lo confirme:

\dotable{\tabskip6pt\hfil#\hfil\tabskip0ptplus1fil\dddarstrut\cr}{
  Id. Comercio: \cr   <comercio> \cr 
 Referencia: \cr   <referencia> \cr 
 Importe: \cr   <imp><moneda> \cr 
 <banco> \cr   <tarjeta> \cr 
 Ok? \cr}

Donde:

<comercio> Código introducido por el comprador previamente relleno a ceros por la izquierda hasta 9 dígitos.

<referencia> Valor de la referencia introducida por el comprador previamente

<imp> Valor del importe introducido por el comprador previamente. En el caso de que la moneda seleccionada sea el Euro, será posible por parte del comprador la utilización de los caracteres `*', `+' y `#' para la separación de los decimales pero la aplicación formateará este campo antes de su presentación mostrando siempre dos decimales (*)

<moneda> Si el comprador seleccionó "Pesetas" como moneda, se mostrará el literal "PTS". Si seleccionó "Euros", se mostrará el literal "E".

<banco> Literal del banco seleccionado al entrar en la aplicación. La información se encuentra en el fichero de bancos

<tarjeta> Literal del modo de pago seleccionado. Esta información se encuentra en el fichero de tarjetas.

\dotable{\tabskip6pt\hfil#\hfil\+\hfil#\hfil\tabskip0ptplus1fil\dddarstrut\cr}{
 123* \+  \hskip2cm  123,00\cr  123 \+  \hskip2cm 
123,00\cr}

\dotable{\tabskip6pt\hfil#\hfil\+\hfil#\hfil\tabskip0ptplus1fil\dddarstrut\cr}{
 123*1 \+  \hskip2cm 
123,10\cr}

3.-: El comprador introduce los dos decimales, tan sólo sustituiremos el separador introducido por el carácter

\dotable{\tabskip6pt\hfil#\hfil\+\hfil#\hfil\tabskip0ptplus1fil\dddarstrut\cr}{
 123+12 \+  \hskip2cm 
123,12\cr}

4.-: El comprador introduce más de dos decimales, se truncará el importe:

\dotable{\tabskip6pt\hfil#\hfil\+\hfil#\hfil\tabskip0ptplus1fil\dddarstrut\cr}{
 123 \# 1234 \+  \hskip2cm 
123,12\cr}

Si una vez mostrado este mensaje de confirmación, el comprador pulsa la tecla de retroceso, la aplicación solicitará de nuevo el modo de pago.

Si no es así, antes de pasar a solicitar el NIP, se llevará a cabo el siguiente procedimiento, con el fin de avisar al comprador sobre el estado de su fichero de mensajes cortos y evitar que no se reciba el mensaje de confirmación de compra por encontrarse este fichero lleno.

Si queda 1 registro libre o ninguno, la aplicación mostrará brevemente el siguiente mensaje:

\dotable{\tabskip6pt\hfil#\hfil\tabskip0ptplus1fil\dddarstrut\cr}{
  SIM llena. Imposible enviar el
mensaje \cr}

Si quedan 2 ó 3 registros libres, la aplicación mostrará brevemente el mensaje:

\dotable{\tabskip6pt\hfil#\hfil\tabskip0ptplus1fil\dddarstrut\cr}{
  SIM llena. Debe borrar algún
mensaje \cr}

Si quedan más de 3 registros libres, la aplicación procederá a solicitar el NIP directamente.

\dotable{\tabskip6pt\hfil#\hfil\tabskip0ptplus1fil\dddarstrut\cr}{
   \uh{NIP?}  \cr  - - -
-\cr}

Si el comprador pulsa la tecla de retroceso, se mostrará de nuevo el mensaje de confirmación de los datos introducidos. Si no es así, el comprador introduce el NIP y confirma, se procederá al envío de un mensaje corto con los datos descritos a continuación.

\begin{longtable}{|l|l|l|l|}\hline  Campo \+ Long \+ Long \+
Valor\\  \+ min. \+ máx.\+\\\hline  Comando \+ 1 \+ 1 \+
 P \\\hline  0x01 \+ 1 \+ 1 \+ Separador\\\hline  Banco \+ 6 \+
6 \+ Código asociado al banco\\  \+ \+ \+ seleccionado. Su valor
se\\  \+ \+ \+ encuentra en el fichero de bancos.\\\hline  0x01 \+ 1
\+ 1 \+ Separador\\\hline  Id. de \+ 16 \+ 16 \+ Compuesto de 8
caracteres ASCII de\\  aplicación \+ \+ \+ valor fijo:  BANCO
A0100  (4 de\\  \+ \+ \+ aplicación + 4 de versión) + un\\  \+ \+
\+ número secuencial de 8 bytes\\  \+ \+ \+ codificado en ASCII que
será\\  \+ \+ \+ incrementado con el envío de cada\\  \+ \+ \+
mensaje (1)\\\hline  0x01 \+ 1 \+ 1 \+ Separador\\\hline  Nº de \+ 9
\+ 9\+ Código de comercio la Entidad\\  Comercio \+ \+ \+
Autorizadora. Tecleado 9 dígitos.\\\hline  0x01 \+ 1 \+ 1 \+
Separador\\\hline  Importe \+ 1 \+ 12 \+ Tecleado por el comprador.
(2)\\\hline  0x01 \+ 1 \+ 1 \+ Separador\\\hline  Moneda \+ 1 \+ 1
\+ Seleccionada por menú:\\  \+ \+ \+ P (PTS)\\  \+ \+ \+ E
(EUR)\\\hline  0x01 \+ 1 \+ 1 \+ Separador\\\hline  Tarjeta \+ 7 \+
7 \+ Seleccionado por menú. Contendrá\\  \+ \+ \+ un código numérico
de 7 dígitos en\\  \+ \+ \+ formato ASCII correspondientes a\\  \+
\+ \+ la tarjeta seleccionada como forma\\  \+ \+ \+ de pago. Esta
información será\\  \+ \+ \+ proporcionada a la SIM en el\\  \+ \+
\+ mensaje de activación de una\\  \+ \+ \+ tarjeta de pago y se
encontrará\\  \+ \+ \+ almacenada en el fichero de\\  \+ \+ \+
tarjetas\\\hline  0x01 \+ 1 \+ 1 \+ Separador\\\hline  Referencia \+
0 \+ 16 \+ Solicitado al comprador\\\hline  0x01 \+ 1 \+ 1 \+
Separador\\\hline\end{longtable}

\trama

Al llegar el número máximo "99999999", el número volverá al valor 0.

(2) En el caso de los Euros, no aparecerán los caracteres de separación `*', `+' o `#'. Este campo se enviará tal cual fue formateado antes de ser mostrado en la ventana de confirmación pero sin el carácter ",". Es decir, si el comprador introdujo 12*5 E, la aplicación le mostrará para confirmar 12,50 E y se enviará 1250.

Este mensaje llevará cifrados los campos no sombreados con una clave obtenida a partir del NIP correspondiente al banco con el que se realiza el pago y el IMSI de la SIM. El algoritmo de cifrado utilizado será el 3XDES.

Si el comprador pulsa la tecla de retroceso, se volverá a solicitar el NIP.

\dotable{\tabskip6pt\hfil#\hfil\tabskip0ptplus1fil\dddarstrut\cr}{
  Petición
realizada \cr}

\dotable{\tabskip6pt\hfil#\hfil\tabskip0ptplus1fil\dddarstrut\cr}{
  Petición no
realizada \cr}

\nobreak\vskip.5\baselineskip\centering\begin{tabular}{|l|l|l|l|}\hline
 Campo  \+ Long  \+ Long  \+ Valor \\   \+ min.  \+ máx. \+ \\\hline
 Comando  \+ 2  \+ 2  \+  P1  /  P2  \\\hline  Código  \+
6  \+ 6  \+ Código del banco con el que se \\  Banco  \+  \+  \+
realizó la operación \\\hline  Id. de  \+ 4  \+ 4  \+  BANCO A 
\\  aplicación \+ \+ \+ \\\hline  Datos del  \+ 1  \+ 124  \+
Contenido del mensaje de \\  mensaje  \+  \+  \+ confirmación del
pago
\\\hline\end{tabular}\par\vskip.5\baselineskip

Los datos no sombreados se recibirán cifrados con el algoritmo 3XDES usando como clave el IMSI de la SIM y el NIP correspondiente al banco con el que se realizó el pago.

Saldo

Al seleccionar esta opción se solicitará al comprador la selección de la tarjeta a la quiere referir la consulta de saldo. Dicha información se encuentra en el fichero de tarjetas. Se mostrará en pantalla la lista de tarjetas asociadas al banco seleccionado previamente.

\dotable{\tabskip6pt\hfil#\hfil\tabskip0ptplus1fil\dddarstrut\cr}{
   \uh{FORMA DE PAGO}  \cr   Crédito \cr 
 Débito \cr 
 Prepago \cr}

Si el comprador pulsa la tecla de retroceso, la aplicación volverá al menú "BANCO A" (en este caso concreto).

Una vez seleccionada la tarjeta a consultar, y antes de pasar a solicitar el NIP, se llevará a cabo el siguiente procedimiento, con el fin de avisar al comprador sobre el estado de su fichero de mensajes cortos y evitar que no se reciba el mensaje de consulta de saldo por encontrarse este fichero lleno. Se verificará el número de registros libres en el fichero de mensajes cortos a través del fichero EFstatus. Dicho fichero debe actualizarse cada vez que un mensaje sea almacenado o borrado en el fichero de mensajes cortos y deberá indicar en todo momento cuál es el número de registros libres que posee el fichero de mensajes cortos.

\dotable{\tabskip6pt\hfil#\hfil\tabskip0ptplus1fil\dddarstrut\cr}{
  SIM llena. Imposible enviar el
mensaje \cr}

Si quedan 2 ó 3 registros, la aplicación mostrará brevemente el mensaje:

\dotable{\tabskip6pt\hfil#\hfil\tabskip0ptplus1fil\dddarstrut\cr}{
  SIM llena. Debe borrar algún
mensaje \cr}

Si el comprador pulsa la tecla de retroceso, la aplicación mostrará de nuevo el menú "MODO DE PAGO". En caso de no ser así, la aplicación solicitará el NIP.

Si quedan más de 3 registros libres, la aplicación procederá a solicitar directamente el NIP.

\dotable{\tabskip6pt\hfil#\hfil\tabskip0ptplus1fil\dddarstrut\cr}{
   \uh{NIP?}  \cr  - - - -
-\cr}

Si el comprador pulsa la tecla de retroceso, se preguntará de nuevo por la tarjeta asociada a la consulta. Si no es así, el comprador introduce el NIP y confirma, se procederá al envío de un mensaje corto con los datos descritos a continuación.

\nobreak\vskip.5\baselineskip\centering\begin{tabular}{|l|l|l|l|}\hline
 Campo  \+ Long  \+ Long  \+ Valor \\   \+ min.  \+ máx. \+ \\\hline
 Comando  \+ 1  \+ 1  \+ ``S'' \\\hline  0x01  \+ 1  \+ 1  \+
Separador \\\hline  Banco  \+ 6  \+ 6  \+ Código asociado al banco
\\   \+  \+  \+ seleccionado. Su valor se \\   \+  \+  \+ encuentra
en el fichero de bancos. \\\hline  0x01  \+ 1  \+ 1  \+ Separador
\\\hline  Id. de  \+ 16  \+ 16  \+ Compuesto de 8 caracteres ASCII
de \\  aplicación  \+  \+  \+ valor fijo:  BANCO A0100  (4 de
\\   \+  \+  \+ aplicación + 4 de versión) + un \\   \+  \+  \+
número secuencial de 8 bytes \\   \+  \+  \+ codificado en ASCII que
será \\   \+  \+  \+ incrementado con el envío de cada \\   \+  \+ 
\+ mensaje \\\hline  0x01  \+ 1  \+ 1  \+ Separador \\\hline 
Tarjeta  \+ 7  \+ 7  \+ Contendrá un código numérico de 7 \\   \+ 
\+  \+ dígitos en formato ASCII \\   \+  \+  \+ correspondientes a
la tarjeta \\   \+  \+  \+ seleccionada como forma de pago, \\   \+ 
\+  \+ esta información se encuentra en \\   \+  \+  \+ el fichero
de tarjetas y será \\   \+  \+  \+ proporcionada a la SIM en el \\  
\+  \+  \+ mensaje de activación de una \\   \+  \+  \+ tarjeta de
pago. \\\hline  0x01  \+ 1  \+ 1  \+ Separador
\\\hline\end{tabular}\par\vskip.5\baselineskip

\trama

Al llegar el número máximo "99999999", el número volverá al valor 0.

Este mensaje llevará cifrados los campos no sombreados con una clave obtenida a partir del NIP correspondiente al banco sobre el que se realiza la consulta y el IMSI de la SIM. El algoritmo de cifrado implementado será el 3XDES. Si el comprador pulsa la tecla de retroceso, se volverá a solicitar el NIP.

\dotable{\tabskip6pt\hfil#\hfil\tabskip0ptplus1fil\dddarstrut\cr}{
  Petición
realizada \cr}

\dotable{\tabskip6pt\hfil#\hfil\tabskip0ptplus1fil\dddarstrut\cr}{
  Petición no
realizada \cr}

Si el comprador pulsa cualquier tecla, sea la de retroceso o no, la aplicación volverá al menú "APLICACIONES DE COMPRADOR".

Una vez enviado el mensaje corto, se recibirá de la Entidad Autorizadora un mensaje con el saldo del cliente conteniendo los siguientes campos:

\nobreak\vskip.5\baselineskip\centering\begin{tabular}{|l|l|l|l|}\hline
 Campo  \+  Long  \+ Long.  \+ Valor \\   \+ mín.  \+ máx. \+
\\\hline  Comando  \+ 2  \+ 2  \+  S1 /  S2  \\\hline 
Código  \+ 6  \+ 6  \+ Banco utilizado en la operación \\  Banco \+
\+ \+ \\\hline  Id. de  \+ 4  \+ 4  \+  BANCO A  \\  aplicación
\+ \+ \+ \\\hline  Datos del  \+ 1  \+ 124  \+ Contenido del mensaje
de consulta \\  mensaje  \+  \+  \+ de saldo
\\\hline\end{tabular}\par\vskip.5\baselineskip

Los campos no sombreados del mensaje se recibirán cifrados con el algoritmo 3XDES usando como clave el IMSI de la SIM y el NIP correspondiente al banco al que se consulta el saldo.

Consultas

Al seleccionar esta opción, se solicitará al comprador el identificador del comercio con el mensaje:

\dotable{\tabskip6pt\hfil#\hfil\tabskip0ptplus1fil\dddarstrut\cr}{
   \uh{Id. Comercio?}  \cr  - - - -
-\cr}

El comprador deberá teclear el código numérico correspondiente al comercio sobre el que se va a realizar la consulta. Dicho código tendrá una longitud mínima de 2 dígitos y máxima de 9 dígitos. Tras introducir el código de comercio, la aplicación procederá a su verificación utilizando el algoritmo de Luhn. En caso de no ser correcto, la aplicación mostrará brevemente el mensaje:

\dotable{\tabskip6pt\hfil#\hfil\tabskip0ptplus1fil\dddarstrut\cr}{
  Código de comercio
incorrecto \cr}

Una vez introducido correctamente el comercio, se mostrará en pantalla la lista de tarjetas asociadas al banco seleccionado previamente.

\dotable{\tabskip6pt\hfil#\hfil\tabskip0ptplus1fil\dddarstrut\cr}{
   \uh{MODO DE PAGO}  \cr   Crédito \cr 
 Débito \cr 
 Prepago \cr}

Si el comprador pulsa la tecla de retroceso, la aplicación volverá a solicitar el identificador del comercio. En caso contrario, se selecciona una de las tarjetas, la aplicación solicitará al comprador la fecha de la consulta con el mensaje:

\dotable{\tabskip6pt\hfil#\hfil\tabskip0ptplus1fil\dddarstrut\cr}{
   \uh{Fecha:ddmmaa?}  \cr  - - - - -
-\cr}

Si el comprador pulsa la tecla de retroceso, se le interrogará de nuevo por el modo de pago.

En caso contrario, el comprador deberá introducir los 6 dígitos de la fecha a la que quiere referir la consulta en el formato "ddmmaa". Una vez introducida la fecha, antes de pasar a solicitar el NIP, se llevará a cabo el siguiente procedimiento con el fin de avisar al comprador sobre el estado de su fichero de mensajes cortos y evitar que no se reciba el mensaje de consulta de movimientos por encontrarse este fichero lleno. Se verificará el número de registros libres en el fichero de mensajes cortos a través del fichero EFstatus. Dicho fichero debe actualizarse cada vez que un mensaje sea almacenado o borrado en el fichero de mensajes cortos y deberá indicar en todo momento cuál es el número de registros libres que posee el fichero de mensajes cortos.

\dotable{\tabskip6pt\hfil#\hfil\tabskip0ptplus1fil\dddarstrut\cr}{
  SIM llena. Imposible enviar el
mensaje \cr}

Si quedan 2 ó 3 registros, la aplicación mostrará brevemente el siguiente mensaje:

\dotable{\tabskip6pt\hfil#\hfil\tabskip0ptplus1fil\dddarstrut\cr}{
  SIM llena. Debe borrar algún
mensaje \cr}

Si el comprador pulsa la tecla de retroceso, la aplicación solicitará de nuevo la fecha de la consulta. En caso de no ser así, la aplicación solicitará el NIP.

\dotable{\tabskip6pt\hfil#\hfil\tabskip0ptplus1fil\dddarstrut\cr}{
   \uh{NIP?}  \cr  - - -
-\cr}

Si el comprador pulsa la tecla de retroceso, se preguntará de nuevo por la fecha de la consulta. Si no es así, se procederá al envío de un mensaje corto con los datos descritos a continuación.

\nobreak\vskip.5\baselineskip\centering\begin{tabular}{|l|l|l|l|}\hline
 Campo  \+ Long  \+ Long.  \+ Valor \\   \+ min.  \+ máx. \+
\\\hline  Comando  \+ 1  \+ 1  \+  M  \\\hline  0x01  \+ 1  \+
1  \+ Separador \\\hline  Banco  \+  6  \+ 6  \+ Código asociado al
banco \\   \+  \+  \+ seleccionado. Su valor se \\   \+  \+  \+
encuentra en el fichero de bancos. \\\hline  0x01  \+ 1  \+ 1  \+
Separador \\\hline  Id. de  \+ 16  \+ 16  \+ Compuesto de 8
caracteres ASCII de \\  aplicación  \+  \+  \+ valor fijo:  BANCO
A0100  (4 de \\   \+  \+  \+ aplicación + 4 de versión) + un \\  
\+  \+  \+ número secuencial de 8 bytes \\   \+  \+  \+ codificado
en ASCII que será \\   \+  \+  \+ incrementado con el envío de cada
\\   \+  \+  \+ mensaje (1) \\\hline  0x01  \+ 1  \+ 1  \+ Separador
\\\hline  Comercio  \+ 9  \+ 9  \+ Valor introducido por el
comprador \\\hline  0x01  \+ 1  \+ 1  \+ Separador \\\hline  Tarjeta
 \+ 7  \+ 7  \+ Contendrá un código numérico de 7 \\   \+  \+  \+
dígitos en formato ASCII \\   \+  \+  \+ correspondientes a la
tarjeta \\   \+  \+  \+ seleccionada como forma de pago. \\   \+  \+
 \+ Esta información será \\   \+  \+  \+ proporcionada a la SIM en
el \\   \+  \+  \+ mensaje de activación de una \\   \+  \+  \+
tarjeta de pago y se encontrará en \\   \+  \+  \+ el fichero de
tarjetas \\\hline  0x01  \+ 1  \+ 1  \+ Separador \\\hline  Fecha 
\+ 6  \+ 6  \+ Introducida por el comprador. \\   \+  \+  \+ Formato
ddmmaa \\\hline  0x01  \+ 1  \+ 1  \+ Separador
\\\hline\end{tabular}\par\vskip.5\baselineskip

(1)El número secuencial se compondrá de 8 dígitos ASCII comenzando en el 0, es decir, el primer mensaje incluirá el número "00000000", el segundo "00000001",

\trama

Al llegar el número máximo "99999999", el número volverá al valor 0.

Este mensaje llevará cifrados los campos no sombreados con una clave obtenida a partir del NIP correspondiente al banco sobre el que se realiza la consulta y el IMSI de la SIM. El algoritmo de cifrado será el 3XDES.

Si el comprador pulsa la tecla de retroceso, se volverá a solicitar el NIP.

\dotable{\tabskip6pt\hfil#\hfil\tabskip0ptplus1fil\dddarstrut\cr}{
  Petición
realizada \cr}

\dotable{\tabskip6pt\hfil#\hfil\tabskip0ptplus1fil\dddarstrut\cr}{
  Petición no
realizada \cr}

Una vez enviado el mensaje corto, se recibirá de la Entidad Autorizadora un mensaje corto con los últimos movimientos del cliente para el comercio, la fecha y el modo de pago indicados, conteniendo los siguientes campos:

\nobreak\vskip.5\baselineskip\centering\begin{tabular}{|l|l|l|l|}\hline
 Campo  \+ Long  \+ Long.  \+ Valor \\   \+ min.  \+ máx. \+
\\\hline  Comando  \+ 2  \+ 2  \+  M1  /  M2  \\\hline 
Código  \+ 6  \+ 6  \+ Banco utilizado en la operación \\  Banco \+
\+ \+ \\\hline  Id. de  \+ 4  \+ 4  \+  BANCO A  \\  aplicación
\+ \+ \+ \\\hline  Datos del  \+ 1 \+ 124  \+ Contenido del mensaje
de consulta \\  mensaje  \+  \+  \+ de movimientos
\\\hline\end{tabular}\par\vskip.5\baselineskip

Los datos no sombreados del mensaje se recibirán cifrados con el algoritmo 3XDES usando como clave el IMSI de la SIM y el NIP correspondiente al banco sobre el que se realizó la consulta.

Cambio NIP

Al seleccionar esta opción, se llevará a cabo el siguiente procedimiento, con el fin de avisar al comprador sobre el estado de su fichero de mensajes cortos y evitar que no se reciba el mensaje de confirmación de cambio por encontrarse este fichero lleno.

Antes de solicitar el NIP, se verificará el número de registros libres en el fichero de mensajes cortos a través del fichero EFstatus. Dicho fichero debe actualizarse cada vez que un mensaje sea almacenado o borrado en el fichero EFSMS y deberá indicar en todo momento cuál es el número de registros libres que posee el fichero de mensajes cortos.

\dotable{\tabskip6pt\hfil#\hfil\tabskip0ptplus1fil\dddarstrut\cr}{
  SIM llena. Imposible enviar el
mensaje \cr}

\dotable{\tabskip6pt\hfil#\hfil\tabskip0ptplus1fil\dddarstrut\cr}{
  SIM llena. Debe borrar algún
mensaje \cr}

Si el comprador pulsa la tecla de retroceso, la aplicación regresará al menú "APLICACIONES DE COMPRADOR".

En caso de no ser así, la aplicación solicitará el NIP.

\newpage

Si quedan más de 3 registros libres, la aplicación solicitará al comprador el valor del actual NIP.

\dotable{\tabskip6pt\hfil#\hfil\tabskip0ptplus1fil\dddarstrut\cr}{
   \uh{NIP?}  \cr  - - -
-\cr}

Si el comprador pulsa la tecla de retroceso, la aplicación regresará al menú "BANCO A" (en este caso concreto), en caso contrario solicitará al comprador el valor del nuevo NIP con el mensaje:

\dotable{\tabskip6pt\hfil#\hfil\tabskip0ptplus1fil\dddarstrut\cr}{
   \uh{Nuevo NIP?}  \cr  - - -
-\cr}

El valor de este nuevo NIP no será revelado por el terminal. El comprador deberá introducir los 4 dígitos que como NIP desea asignar al banco seleccionado previamente.

Si el comprador pulsa la tecla de retroceso, la aplicación volverá a solicitar el actual NIP. De no ser así, la aplicación solicitará la confirmación del nuevo NIP:

\dotable{\tabskip6pt\hfil#\hfil\tabskip0ptplus1fil\dddarstrut\cr}{
   \uh{Confirme nuevo NIP?}  \cr  - - -
-\cr}

El comprador deberá introducir de nuevo el NIP tecleado en el paso anterior. Tampoco esta entrada será revelada.

Si el comprador pulsa la tecla de retroceso, la aplicación volverá a solicitar el nuevo NIP. En caso contrario, se procederá a validar el NIP introducido con respecto al obtenido en el paso anterior. Si ambos NIP no son iguales, la aplicación mostrará brevemente el mensaje:

\dotable{\tabskip6pt\hfil#\hfil\tabskip0ptplus1fil\dddarstrut\cr}{
  Error de
confirmación \cr}

Tanto si el comprador presiona la tecla de retroceso como si confirma dicho mensaje, la aplicación volverá a solicitar la confirmación del NIP.

Si la confirmación es correcta, se procederá a enviar un mensaje corto con el formato descrito más abajo.

\nobreak\vskip.5\baselineskip\centering\begin{tabular}{|l|l|l|l|}\hline
 Campo  \+ Long.  \+ Long.  \+ Valor \\   \+ min.  \+ máx. \+
\\\hline  Comando  \+ 1  \+ 1  \+  N  \\\hline  0x01  \+ 1  \+
1  \+ Separador \\\hline  Banco  \+ 6  \+ 6  \+ Código asociado al
banco \\   \+  \+  \+ seleccionado. Su valor se \\   \+  \+  \+
encuentra en el fichero de bancos. \\\hline  0x01  \+ 1  \+ 1  \+
Separador \\\hline  Id. de  \+ 16  \+ 16  \+ Compuesto de 8
caracteres ASCII de \\  aplicación  \+  \+  \+ valor fijo:  BANCO
A0100  (4 de \\   \+  \+  \+ aplicación + 4 de versión) + un \\  
\+  \+  \+ número secuencial de 8 bytes \\   \+  \+  \+ codificado
en ASCII que será \\   \+  \+  \+ incrementado con el envío de cada
\\   \+  \+  \+ mensaje (1) \\\hline  0x01  \+ 1  \+ 1  \+ Separador
\\\hline  NIP nuevo *  \+ 8  \+ 8  \+ Valor introducido por el
comprador \\   \+  \+  \+ modificado según se indica a \\   \+  \+ 
\+ continuación \\\hline  0x01  \+ 1  \+ 1  \+ Separador
\\\hline\end{tabular}\par\vskip.5\baselineskip

\trama

Al llegar el número máximo "99999999", el número volverá al valor 0.

* El campo NIP nuevo que aparece en el mensaje resulta del cifrado del nuevo NIP introducido por el comprador conforme al siguiente esquema:

1.-: Los 8 bytes a cifrar se obtendrán anteponiendo al NIP el byte 0x04, a continuación se incluirá el NIP en formato BCD y se rellenará después hasta 8 con el byte 0xFF. Por ejemplo, si el NIP es "1234", el buffer de 8 bytes a cifrar contendría:

\nobreak\vskip.5\baselineskip\centering\begin{tabular}{|l|l|l|l|l|l|l|l|}\hline
 0x0  \+ 0x1  \+ 0x3  \+ 0xF  \+ 0xF  \+ 0xF  \+ 0xF  \+ 0xF \\  4 
\+ 2  \+ 4  \+ F  \+ F  \+ F  \+ F  \+ F
\\\hline\end{tabular}\par\vskip.5\baselineskip

2.-: El algoritmo de cifrado a utilizar será también el algoritmo 3XDES salvo que en este caso la clave a utilizar se invertirá, es decir, se utilizará como parte izquierda el NIP viejo y como clave derecha el IMSI de la SIM.

Este mensaje llevará cifrados los campos no sombreados con una clave obtenida a partir del NIP (viejo) correspondiente al banco sobre el que se realiza el cambio de NIP y el IMSI de la SIM. El algoritmo de cifrado será el 3XDES.

Si el comprador pulsa la tecla de retroceso, se volverá a solicitar la confirmación del nuevo NIP.

\dotable{\tabskip6pt\hfil#\hfil\tabskip0ptplus1fil\dddarstrut\cr}{
 Petición
realizada \cr}

\dotable{\tabskip6pt\hfil#\hfil\tabskip0ptplus1fil\dddarstrut\cr}{
  Petición no
realizada \cr}

Una vez enviado el mensaje corto, se recibirá de la Entidad Autorizadora un mensaje corto estándar confirmando o denegando el cambio.

Configurar

Al seleccionar esta opción, aparecerá en pantalla brevemente el siguiente mensaje:

\dotable{\tabskip6pt\hfil#\hfil\tabskip0ptplus1fil\dddarstrut\cr}{
  Configurar el Pago
Habitual \cr}

Si el comprador pulsa la tecla de retroceso, la aplicación volverá al menú "BANCO A".

Transcurrido el tiempo preciso, se mostrará un menú con dos opciones:

\dotable{\tabskip6pt\hfil#\hfil\tabskip0ptplus1fil\dddarstrut\cr}{
   \uh{CONFIGURAR}  \cr   Forma de pago \cr 
 Moneda \cr}

Modo de pago

Al seleccionar esta opción aparecerá una lista con las tarjetas grabadas en el fichero de tarjetas asociadas al banco seleccionado previamente:

\dotable{\tabskip6pt\hfil#\hfil\tabskip0ptplus1fil\dddarstrut\cr}{
   \uh{MODO DE PAGO}  \cr   Crédito \cr 
 Débito \cr 
 Prepago \cr}

El comprador deberá seleccionar la tarjeta con la que se realizarán los pagos habituales hasta nueva modificación, es decir, se almacenará como predeterminada para el banco seleccionado. Por defecto, se marcará como tarjeta predeterminada para un banco concreto, la primera en darse de alta para dicho banco.

Si el comprador pulsa la tecla de retroceso, la aplicación volverá al menú "CONFIGURAR".

Al seleccionar una de las opciones, se mostrará al comprador brevemente el mensaje:

\dotable{\tabskip6pt\hfil#\hfil\tabskip0ptplus1fil\dddarstrut\cr}{
  Configuración
actualizada \cr}

Sea cual sea la tecla pulsada por el comprador, confirmación o retroceso, la aplicación regresará al menú "APLICACIONES DE COMPRADOR". Este mensaje es meramente informativo. Si el comprador erró en su selección deberá volver a entrar de nuevo en esta opción para modificar el valor predeterminado de la tarjeta.

Moneda

Al seleccionar esta opción aparecerá un menú con dos opciones:

\dotable{\tabskip6pt\hfil#\hfil\tabskip0ptplus1fil\dddarstrut\cr}{
   \uh{MONEDA}  \cr   Pesetas \cr 
 Euros \cr}

El comprador deberá seleccionar la moneda en la que se realizarán los pagos habituales hasta nueva modificación, es decir, se almacenará como predeterminada. Por defecto, al emitir la aplicación, se configurará la peseta como moneda predeterminada.

Al seleccionar una de las dos opciones, se mostrará al comprador brevemente el mensaje:

\dotable{\tabskip6pt\hfil#\hfil\tabskip0ptplus1fil\dddarstrut\cr}{
  Configuración
actualizada \cr}

Sea cual sea la tecla pulsada por el comprador, confirmación o retroceso, la aplicación regresará al menú "APLICACIONES DE COMPRADOR". Este mensaje es meramente informativo. Si el comprador erró en su selección deberá volver a entrar de nuevo en esta opción para modificar el valor predeterminado de la moneda.

Módulo de lectura de comprobantes de compra

Al seleccionar esta opción, se llevará a cabo el siguiente procedimiento:

1.- Se recorrerá el fichero de mensajes cortos buscando mensajes recibidos que cumplan los siguientes requisitos:

: DCS del mensaje. Valor correcto: mensaje de Clase 2 "SIM specific" y de 8 bits.

: SMSC válido. Los primeros seis dígitos del mismo deben corresponderse con: 607-003.

El código del banco enviado en claro en el mensaje debe coincidir con alguno de los almacenados en el fichero de bancos del comprador.

El estado del mensaje (borrado, leído, etc.) no será relevante permitiendo así recuperar incluso mensajes que hayan sido borrados por el comprador.

En caso de cumplirse los requisitos, la aplicación solicitará al comprador el NIP del banco asociado al mensaje mostrando:

\dotable{\tabskip6pt\hfil#\hfil\tabskip0ptplus1fil\dddarstrut\cr}{
   \uh{NIP Banco}  \cr  - - -
-\cr}

Donde el literal del banco asociado será extraído del fichero de bancos del comprador.

En caso de introducirse un NIP, la aplicación descifrará el contenido cifrado del mensaje utilizando el algoritmo 3XDES y una clave doble generada a partir del NIP introducido y el IMSI de la SIM.

Si tras descifrar el mensaje, los cuatro primeros bytes contienen el literal "BANCO A", el NIP introducido será válido. El contenido del mensaje, eliminando el identificador de aplicación anterior ("BANCO A"), será almacenado en el fichero de Comprobantes y se mostrará al comprador su contenido.

Se mostrarán estos mensajes con la opción "esperar a que el comprador limpie el mensaje".

Si el comprador pulsa la tecla de retroceso, la aplicación regresará al menú "APLICACIONES DE COMPRADOR", en caso contrario, se continuará la exploración del fichero de mensajes cortos del modo descrito.

El comprador dispone de tres intentos por mensaje para introducir correctamente el NIP. Los intentos no se inicializarán cada vez que se entre en esta opción. Es decir, un comprador que entra a leer sus comprobantes nuevos, no introduce correctamente el NIP para un mensaje concreto y abandona la opción, al volver a entrar en la misma debe disponer de tan sólo 2 intentos para el mismo mensaje.

Si el comprador introduce un NIP erróneo, la aplicación mostrará brevemente el mensaje:

\dotable{\tabskip6pt\hfil#\hfil\tabskip0ptplus1fil\dddarstrut\cr}{
  NIP
incorrecto \cr}

Si el comprador pulsa la tecla de retroceso, la aplicación regresará al menú "APLICACIONES DE COMPRADOR", en caso contrario, se volverá a solicitar el NIP al comprador.

Tras tres intentos fallidos, el comprador perderá su comprobante que no podrá ya ser recuperado del fichero de mensajes cortos (no se almacenará en el fichero de Comprobantes. Cuando esto ocurra, la aplicación mostrará al comprador el mensaje:

\dotable{\tabskip6pt\hfil#\hfil\tabskip0ptplus1fil\dddarstrut\cr}{
  NIP incorrecto, comprobante
perdido \cr}

En caso de que el comprador pulse la tecla de retroceso, la aplicación regresará al menú "APLICACIONES DE COMPRADOR". De no ser así, la aplicación continuará la exploración del fichero de mensajes cortos.

Una vez se finalice la exploración del fichero de mensajes cortos, esta opción mostrará al comprador los comprobantes ya almacenados en el fichero de comprobantes en el orden inverso a como fueron almacenados, es decir, primero los almacenados más recientemente.

Si el comprador presiona la tecla de retroceso, la aplicación mostrará el mensaje anterior, en caso contrario, dado que se trata del último de los mensajes, la aplicación regresará al menú "APLICACIONES DE COMPRADOR".

En el caso del primero de los mensajes ya almacenados, si el comprador presiona la tecla de retroceso y al entrar en la opción el comprador no tenía mensajes nuevos (no se encontró ningún mensaje sin leer en el fichero de mensajes cortos), la aplicación volverá al menú "APLICACIONES DE COMPRADOR". Si por el contrario el comprador descifró (presentando el NIP) y leyó mensajes nuevos al entrar en la opción, estos mensajes ya habrán sido almacenados en el fichero de Comprobantes, por tanto, al pulsar la tecla de retroceso la aplicación deberá mostrar el contenido del mensaje descifrado en último lugar y así sucesivamente si el comprador lo requiere hasta llegar al principio cronológico del fichero.

En caso de que el comprador no disponga de comprobantes almacenados ni tampoco de comprobantes nuevos sin leer, la aplicación mostrará el mensaje:

\dotable{\tabskip6pt\hfil#\hfil\tabskip0ptplus1fil\dddarstrut\cr}{
  Lista
vacía \cr}

Tanto si el comprador presiona la tecla de retroceso como la tecla OK, la aplicación volverá al menú "APLICACIONES DE COMPRADOR".

Esta aplicación debe mostrar todos los comprobantes recibidos hasta el momento que no hayan sido extraídos ya del fichero de Comprobantes (dado que se trata de un fichero cíclico) y que no hayan sido eliminados manualmente por el usuario del fichero de mensajes cortos antes de proceder a su recuperación a través de esta opción.

Recepción de comprobantes de compra

A la recepción de cualquier mensaje corto, se deberán hacer las siguientes validaciones para determinar si se trata de un mensaje perteneciente al sistema de Aplicaciones Informáticas de Comprador: mensajes de gestión (alta, baja,

\trama

) o mensajes de operativa (comprobante de compra, de consulta de saldo,

\trama

).

1.-: Se comprobará el campo DCS del mensaje. Valor correcto: mensaje de Clase 2 "SIM specific" y con datos de 8 bits.

2.-: Se comprobará que el mensaje proceda de un SMSC válido. Los primeros seis dígitos del mismo deben corresponderse con: 607-003.

3.-: Se verificará la dirección origen del mensaje. Caso de tratarse de un mensaje de gestión, la dirección origen deberá ser 4650. Caso de tratarse de un mensaje comprobante de transacción la dirección origen no será verificada.

4.-: Caso de tratarse de un comprobante de transacción se verificará además que el código del banco enviado en claro en el mensaje coincide con alguno de los almacenados en el fichero de bancos del comprador.

5.-: En el caso de los mensajes de gestión, su contenido se descifrará con la clave ADM4 y en sus primeros 5 bytes deberá aparecer el identificador de aplicación "AIR01".

Si se trata finalmente de un comprobante de transacción, la aplicación mostrará brevemente el mensaje:

\dotable{\tabskip6pt\hfil#\hfil\tabskip0ptplus1fil\dddarstrut\cr}{
  Se ha recibido un mensaje de
pagos \cr}

En caso de tratarse de un mensaje de gestión, la aplicación mostrará el mensaje:

\dotable{\tabskip6pt\hfil#\hfil\tabskip0ptplus1fil\dddarstrut\cr}{
  Se ha recibido un mensaje de
Gestión \cr}

Cifrado y descifrado de mensajes

1. Se parte de una clave doble de 16 bytes. Esta clave se compone:

-: Parte Izquierda (clave 8 bytes): Bloque IMSI

-: Parte derecha (clave 8 bytes): Bloque NIP=LL PPPP FFFFFFFFFF, donde:

\dotable{\tabskip6pt#\hfil\+#\hfil\tabskip0ptplus1fil\dddarstrut\cr}{
 LL: Longitud de NIP (04) \+ - 1 byte\cr  PPPP: 4 dígitos del NIP \+
- 2 bytes\cr  FF's: Bloques de relleno a dígitos Fh \+ - 5
bytes\cr}

2. Notación:

: B' = DES<K>B

: B' es el bloque B cifrado con DES utilizando la clave K

: B = DDES<K>B'

: B es el bloque B' cifrado con DDES (descifrado con DES) utilizando la clave K.

: C = A XOR B

: C es el bloque obtenido haciendo un XOR byte de A con bytes de B

3. Proceso de Cifrado/Descifrado de un Bloque de 8 bytes con 3DES:

: 3DES<Kizq,Kdcha>Bloque =

DES<Kizq>(DDES<Kdcha>(DES<Kizq>Bloque))

: R1 = DES<Kizq>Bloque

: R2 = DDES<kdcha>R1

: Bloque' = DES<Kizq>R2

: 3DDES<Kizq,Kdcha>Bloque'=

DDES<Kizq>(DES<Kdcha>(DDES<Kizq>Bloque'))

: R1 = DDES<Kizq>Bloque'

: R2 = DES<kdcha>R1

: Bloque = DDES<Kizq>R2

4. Proceso de Cifrado de N Bloques de 8 bytes con 3XDES:

Esta operación cifra con 3DES el primer bloque para obtener el primer bloque cifrado, el bloque i-ésimo cifrado se obtiene cifrando con 3DES el resultado del XOR (OR-eXclusive) del bloque i-ésimo con el bloque anterior cifrado.

: 3XDES<Kizq,Kdcha>B1,...,BN =

: B1' = 3DES<Kizq,Kdcha>B1

: Bi' = 3DES<Kizq,Kdcha>(Bi XOR Bi-1') con i = 2..N

5. Proceso de Descifrado de N Bloques de 8 bytes con 3XDDES:

Esta operación descifra con 3DDES el primer bloque para obtener el primer bloque descifrado, el bloque i-ésimo descifrado se obtiene descifrando con 3DDES el bloque i-ésimo y con su resultado se hace un XOR (OR-Exclusive) con el bloque anterior cifrado.

: 3XDDES<Kizq,Kdcha>B1',...,BN' =

: B1 = 3DES<Kizq,Kdcha>B1'

: Bi = (3DES<Kizq,Kdcha>Bi') XOR Bi-1' con i = 2..N

Check del código de comercio

Sea cual sea la longitud (entre 2 y 9) del código de comercio introducido, deberá rellenarse siempre con ceros por la izquierda de modo que al aplicar este algoritmo se haga siempre sobre 9 dígitos. El último corresponderá al dígito de Luhn que deberá ser calculado y verificado utilizando el algoritmo que pasamos a describir a continuación:

1.-: Se duplica el valor de los dígitos de las posiciones impares comenzando por la derecha.

2.-: Se suman los valores de los dígitos que componen los productos obtenidos en el punto 1 y los dígitos pares del número original.

3.-: Se restan a 10 el dígito de unidades del total obtenido en el punto 2. Si el total obtenido en el punto 2 terminase en cero (30, 40, etc.), el dígito de control sería cero.

Activación/desactivación/modificación de formas de pago

Cada vez que un comprador desee darse de alta en un nuevo medio de pago y así se lo haga saber a su entidad bancaria, recibirá un mensaje corto activando dicho medio en su tarjeta y otro mensaje corto informándole del estado de dicha activación (se produjo un error o se realizó correctamente) Lo mismo ocurrirá cuando el comprador desee darse de baja en un medio de pago.

El segundo de los mensajes cortos que recibirá el comprador será meramente informativo, el primero será encaminado directamente a la SIM (mensajes enviados con Clase 2: "SIM specific message").

Cada medio de pago irá asociado a un banco y, así, podremos recibir 6 mensajes diferentes requiriendo una operación concreta por parte de la SIM:

Mensaje de Alta de Banco y Tarjeta

El servidor de Gestión de Medios de Pago detecta que el Banco asociado al medio de pago aún no ha sido dado de alta en la SIM y procede a la misma junto al alta de la tarjeta seleccionada.

\nobreak\vskip.5\baselineskip\centering\begin{tabular}{|l|l|l|l|}\hline
 Nombre de  \+ Tipo  \+ Longitud  \+ Observaciones \\  campo \+ \+
\+ \\\hline  Identificador  \+ ASCII  \+ 5  \+ 3 bytes de aplicación
y 2 \\  del tipo de  \+  \+  \+ bytes de versión: AIR01 \\  mensaje
\+ \+ \+ \\\hline  Tipo de  \+ ASCII  \+ 1  \+ `A' \\  operación \+
\+ \+ \\\hline  Indice  \+ N  \+ 1  \+ Identificador corto del \\  
\+  \+  \+ banco que asocia éste a \\   \+  \+  \+ cada medio de
pago dado de \\   \+  \+  \+ alta. \\\hline  Código de  \+ ASCII  \+
6  \+ Código del banco, \\  banco  \+  \+  \+ identificará el banco
en \\   \+  \+  \+ las transacciones \\\hline  Mnemónico de  \+
ASCII  \+ 12  \+ Texto utilizado para \\  banco  \+  \+  \+
describir el banco \\\hline  Centro  \+ ASCII  \+ 12 \+ Número de
teléfono del \\  Autorizador  \+  \+  \+ Centro Autorizador en el \\
  \+  \+  \+ mismo formato que el \\   \+  \+  \+ utilizado para los
campos \\   \+  \+  \+ de dirección en los \\   \+  \+  \+ mensajes
cortos(*) \\\hline  Código de  \+ ASCII  \+ 7  \+ Código de tarjeta,
\\  tarjeta  \+  \+  \+ identificará la tarjeta en \\   \+  \+  \+
las transacciones \\\hline  Mnemónico de  \+ ASCII  \+ 12  \+ Texto
utilizado para \\  tarjeta  \+  \+  \+ describir el medio de pago
\\\hline\end{tabular}\par\vskip.5\baselineskip

Mensaje de Alta de Tarjeta

Se envía el alta de tarjeta únicamente, porque su banco asociado ya fue dado de alta.

\nobreak\vskip.5\baselineskip\centering\begin{tabular}{|l|l|l|l|}\hline
 Nombre de  \+ Tipo  \+ Longitud  \+ Observaciones \\  campo \+ \+
\+ \\\hline  Identificador  \+ ASCII  \+ 5  \+ 3 bytes de aplicación
y 2 \\  del tipo de  \+  \+  \+ bytes de versión: AIR01 \\  mensaje
\+ \+ \+ \\\hline  Tipo de  \+ ASCII  \+ 1  \+ `B' \\  operación \+
\+ \+ \\\hline  Indice  \+ N  \+ 1  \+ Identificador corto del \\  
\+  \+  \+ banco que asocia éste a \\   \+  \+  \+ cada medio de
pago dado de \\   \+  \+  \+ alta. \\\hline  Código de  \+ ASCII  \+
7  \+ Código de la tarjeta, \\  tarjeta  \+  \+  \+ identificará la
tarjeta en \\   \+  \+  \+ las transacciones \\\hline  Mnemónico de 
\+ ASCII  \+ 12  \+ Texto utilizado para \\  tarjeta  \+  \+  \+
describir el medio de pago
\\\hline\end{tabular}\par\vskip.5\baselineskip

Mensaje Baja de Tarjeta y de Banco

El servidor del Operador de Telefonía Móvil detecta que el producto a dar de baja es el único que tiene cargado la tarjeta asociado a ese banco y procede a dar de baja a ambos, banco y tarjeta.

\nobreak\vskip.5\baselineskip\centering\begin{tabular}{|l|l|l|l|}\hline
 Nombre de  \+ Tipo  \+ Longitud  \+ Observaciones \\  campo \+ \+
\+ \\\hline  Identificador  \+ ASCII  \+ 5  \+ 3 bytes de aplicación
y 2 \\  del tipo de  \+  \+  \+ bytes de versión: AIR01 \\  mensaje
\+ \+ \+ \\\hline  Tipo de  \+ ASCII  \+ 1  \+ `C' \\  operación \+
\+ \+ \\\hline  Indice de  \+ N  \+ 1  \+ Indice del banco que \\ 
banco  \+  \+  \+ identificará también la \\   \+  \+  \+ última
tarjeta del mismo.
\\\hline\end{tabular}\par\vskip.5\baselineskip

Mensaje de Baja de Tarjeta

Este mensaje es enviado cuando el producto que quiere dar de baja el comprador no es el único asociado al banco al que pertenece.

\nobreak\vskip.5\baselineskip\centering\begin{tabular}{|l|l|l|l|}\hline
 Nombre de  \+ Tipo  \+ Longitud  \+ Observaciones \\  campo \+ \+
\+ \\\hline  Identificador  \+ ASCII  \+ 5  \+ 3 bytes de aplicación
y 2 \\  del tipo de  \+  \+  \+ bytes de versión: AIR01 \\  mensaje
\+ \+ \+ \\\hline  Tipo de  \+ ASCII  \+ 1  \+ `D' \\  operación \+
\+ \+ \\\hline  Indice Banco  \+ N  \+ 1  \+ Asocia la tarjeta a un
\\   \+  \+  \+ banco determinado (1) \\\hline  Código de  \+ ASCII 
\+ 7  \+ Código de tarjeta, \\  tarjeta  \+  \+  \+  identificará la
tarjeta en \\   \+  \+  \+ las transacciones
\\\hline\end{tabular}\par\vskip.5\baselineskip

(1) El código de tarjeta no tiene porque ser único en el fichero de tarjetas, asocia un medio de pago y como tal será único para cada banco, por esta razón necesitamos asociar un índice de banco a un código de tarjeta para identificarla unívocamente.

Mensaje de Modificación de Banco

Cuando el mnemónico asociado al banco es modificado por alguna causa, será necesario enviar a todos aquellos compradores que posean productos de este banco un mensaje de modificación. Lo mismo ocurrirá cuando sea el número del Centro Autorizador el que cambie.

\nobreak\vskip.5\baselineskip\centering\begin{tabular}{|l|l|l|l|}\hline
 Nombre de campo  \+ Tipo  \+ Longitud  \+ Observaciones \\\hline 
Identificador  \+ ASCII  \+ 5  \+ 3 bytes de aplicación y 2 \\  del
tipo de  \+  \+  \+ bytes de versión: AIR01 \\  mensaje \+ \+ \+
\\\hline  Tipo de  \+ ASCII  \+ 1  \+ `E' \\  operación \+ \+ \+
\\\hline  Indice  \+ N  \+ 1  \+ Identificador común para \\   \+ 
\+  \+ el banco y los formas de \\   \+  \+  \+ pago asociados
\\\hline  Mnemónico de  \+ ASCII  \+ 12  \+ Nuevo texto a utilizar
\\  banco nuevo  \+  \+  \+ para describir el banco \\\hline  Centro
 \+ ASCII  \+ 12  \+ Número de teléfono del \\  Autorizador  \+  \+ 
\+ Centro Autorizador en el \\  nuevo  \+  \+  \+ mismo formato que
el \\   \+  \+  \+ utilizado para los campos \\   \+  \+  \+ de
dirección en los \\   \+  \+  \+ mensajes cortos(*)
\\\hline\end{tabular}\par\vskip.5\baselineskip

Mensaje de Modificación de Tarjeta

Este mensaje es enviado cuando se desea modificar el literal asociado a una tarjeta concreta.

\nobreak\vskip.5\baselineskip\centering\begin{tabular}{|l|l|l|l|}\hline
 Nombre de campo  \+ Tipo  \+ Longitud  \+ Observaciones \\\hline 
Identificador  \+ ASCII  \+ 5  \+ 3 bytes de aplicación y 2 \\  del
tipo de  \+  \+  \+ bytes de versión: AIR01 \\  mensaje \+ \+ \+
\\\hline  Tipo de  \+ ASCII  \+ 1  \+ `F' \\  operación \+ \+ \+
\\\hline  Indice Banco  \+ N  \+ 1  \+ Identificador común para \\  
\+  \+  \+ el banco y los formas de \\   \+  \+  \+ pago asociados
\\\hline  Código de  \+  ASCII  \+ 7  \+ Código de tarjeta, \\ 
tarjeta  \+  \+  \+  identificará la tarjeta en \\   \+  \+  \+ las
transacciones \\\hline  Mnemónico de  \+ ASCII  \+ 12  \+ Nuevo
texto a utilizar \\  tarjeta nuevo  \+  \+  \+ para describir el
medio de \\   \+  \+  \+ pago
\\\hline\end{tabular}\par\vskip.5\baselineskip

La longitud de la dirección, que también irá incluida en el campo Centro Autorizador indicará el número de semi-octetos útiles en el campo Address-Value, es decir, se excluye cualquier semi-octeto que contenga sólo bits de relleno. Se reservarán 12 octetos para este campo dado que esta es la longitud máxima permitida.

El contenido de estos mensajes irá cifrado con DES utilizando como clave la ADM4, cuarta clave administrativa asociada a cada SIM en cuestión. Para facilitar la gestión de dicha clave, ésta se copiará en personalización en un fichero protegido bajo el directorio de aplicación. Ambos, fichero y directorio, serán descritos más abajo.

Una vez recibido este mensaje la SIM y determinado que se trata de uno de los mensajes de gestión de los formas de pago, deberá actualizar varios ficheros dedicados a tal efecto, consecuentemente con la acción a realizar. En el punto siguiente se describe el contenido de tales ficheros y los procedimientos de actualización asociados.

Con la finalidad de proteger el contenido del mensaje, antes del cifrado se intercalará entre cada dos bytes de datos, un número aleatorio. Es decir, si el contenido del mensaje es:

`A' `I' `R' 0x00 0x01 `B' 0x00 0x01 0x02 0x03 0x04 0x05 0x06 0x07 "Crédito"

Antes de cifrar el mensaje quedaría:

`A' Rnd `I' Rnd `R' Rnd 0x00 Rnd 0x01 Rnd `B' Rnd 0x00 Rnd 0x01 Rnd 0x02 Rnd 0x03 Rnd 0x04 Rnd 0x05 Rnd 0x06 Rnd 0x07 Rnd `C' Rnd `r' Rnd `e' Rnd `d' Rnd `i' Rnd `t' Rnd `o' Rnd ` ` Rnd ` ` Rnd ` ` Rnd ` ` Rnd ` ` Rnd

Procedimientos

Existirán seis procedimientos en SIM según se comentó más arriba. Como primer paso de todos ellos, la SIM mostrará en pantalla el mensaje tras realizar las verificaciones comentadas.

\dotable{\tabskip6pt\hfil#\hfil\tabskip0ptplus1fil\dddarstrut\cr}{
  Se ha recibido un mensaje de
Gestión \cr}

Tanto si el comprador presiona la tecla de retroceso como si no, el procedimiento continuará.

Procedimiento de alta de banco y tarjeta

El procedimiento de activación de una nueva tarjeta cuyo banco asociado aún no ha sido dado de alta, queda como sigue:

1.-: La SIM debe seleccionar el fichero de bancos.

2.-: Comprueba que no se hubiera dado de alta previamente un banco con el mismo índice de banco. No comprobará que exista ya el código del banco, de ello se ocupará el servidor Gestor de Medios de Pago.

3.-: Busca un registro vacío o borrado previamente por orden creciente en cuanto al número de registros, esto es, la SIM comenzará buscando por el registro 1 en adelante un registro borrado o vacío. Se cargará el contenido del mensaje en el mismo.

4.-: La SIM selecciona el fichero de tarjetas.

5.-: Busca un registro vacío o borrado previamente por orden creciente en cuanto al número de registros, esto es, la SIM comenzará buscando por el registro 1 en adelante un registro borrado o vacío. Se cargará el contenido del mensaje en el mismo.

6.-: Se busca en el fichero comenzando de nuevo por el registro 1, el registro marcado como predeterminado para el banco en cuestión, en caso de no encontrarlo, se marcará como tal, el primer registro inicializado encontrado perteneciente al banco marcado como predeterminado. Bastaría con marcar el modo de pago como predeterminado sabida cuenta de que es el primer medio de pago del banco, sin embargo, el procedimiento descrito nos permite tratar las altas y bajas de tarjetas de manera más general.

7.-: Al terminar el procedimiento, la SIM enviará al servidor Gestor de Medios de Pagos un mensaje corto de un solo byte informando del estado final del procedimiento.

Procedimiento de alta de tarjeta

El procedimiento de activación de una nueva tarjeta queda como sigue:

1.-: La SIM debe seleccionar el fichero de tarjetas.

2.-: Busca un registro vacío o borrado previamente por orden creciente en cuanto al número de registros, esto es, la SIM comenzará buscando por el registro 1 en adelante un registro borrado o vacío. Se cargará el contenido del mensaje en el mismo.

3.-: Se busca en el fichero comenzando de nuevo por el registro 1, el registro marcado como predeterminado para el banco en cuestión, en caso de no encontrarlo, se marcará como tal, el primer registro inicializado encontrado perteneciente al banco marcado como predeterminado.

4.-: Al terminar el procedimiento, la SIM enviará al servidor Gestor de Medios de Pagos un mensaje corto de un solo byte informando del estado final del procedimiento

Procedimiento de baja de banco y tarjeta

El procedimiento de desactivación de una tarjeta y su banco asociado queda como sigue:

1.-: La SIM debe seleccionar el fichero de bancos.

2.-: Busca un registro que contenga el mismo índice de banco que el recibido en el mensaje corto.

3.-: Marca el primer nibble de dicho registro con el estado 0xF, registro vacío.

4.-: La SIM selecciona el fichero de tarjetas.

5.-: Busca un registro que contenga el mismo índice de banco asociado que el recibido en el mensaje corto.

6.-: Marca el primer nibble de dicho registro con el estado 0xF, registro vacío. La SIM no verificará que éste sea la última tarjeta del banco en el fichero.

Procedimiento de baja de tarjeta

El procedimiento de desactivación de una tarjeta queda como sigue:

1.-: La SIM debe seleccionar el fichero de tarjetas.

2.-: Busca un registro que contenga el mismo código de tarjeta y el mismo índice de banco que el recibido en el mensaje corto.

4.-: Se busca en el fichero comenzando de nuevo por el registro 1, el registro marcado como predeterminado, en caso de no encontrarlo, se marcará como tal, el primer registro inicializado encontrado perteneciente al banco marcado como predeterminado.

5.-: Al terminar el procedimiento, la SIM enviará al servidor Gestor de Medios de Pagos un mensaje corto de un solo byte informando del estado final del procedimiento.

Procedimiento de modificación de banco

El procedimiento de modificación queda como sigue:

1.-: La SIM debe seleccionar el fichero de bancos.

3.-: Modifica los datos del registro: mnemónico y Centro Autorizador con los datos recibidos en el mensaje corto.

4.-: Al terminar el procedimiento, la SIM enviará al servidor Gestor de Medios de Pagos un mensaje corto de un solo byte informando del estado final del procedimiento.

Procedimiento de modificación de tarjeta

El procedimiento de modificación queda como sigue:

1.-: La SIM debe seleccionar el fichero de tarjetas.

2.-: Busca un registro que contenga el mismo índice de banco y código de tarjeta que los recibidos en el mensaje corto.

3.-: Modifica los datos del registro: mnemónico de la tarjeta con los datos recibidos en el mensaje corto.

Códigos de estado

La tabla siguiente contiene los códigos de resultado generados por la SIM a consecuencia de la recepción de un mensaje de gestión de medio de pago:

\nobreak\vskip.5\baselineskip\centering\begin{tabular}{|l|l|}\hline
 Código  \+ Descripción \\\hline  0x00  \+ OK. Procedimiento
realizado con éxito \\\hline  0x01  \+ Problema de memoria con la
tarjeta SIM. La tarjeta \\   \+ está defectuosa \\\hline  0x02  \+
No se encontró el código de la tarjeta a la que se \\   \+ refiere
la operación. El cliente no tiene activada \\   \+ esa tarjeta o los
datos enviados sobre la misma \\   \+ (código + índice) están
equivocados. \\\hline  0x03  \+ No se encontró el código del banco
al que se \\   \+ refiere la operación. El cliente no tiene activado
\\   \+ ningún producto con ese banco o los datos enviados \\   \+
sobre el mismo (índice) están equivocados. \\\hline  0x04  \+ Código
de operación inválido. No se halló en el \\  mensaje  \+  A ,
 B ,  C ,  D ,  E  o  F . \\\hline  0x05 
\+  El mensaje contiene un número de bytes diferente \\   \+ de los
necesarios para llevar a cabo la operación. \\\hline  0x06  \+ Error
de índice. El índice ya está utilizado. \\\hline  0x07  \+ No hay
espacio suficiente para llevar a cabo la \\   \+ operación
\\\hline\end{tabular}\par\vskip.5\baselineskip

Aplicaciones informáticas de vendedor

Al introducir una tarjeta SIM que lleve cargada estas aplicaciones SIM Toolkit en un terminal Fase 2+, aparecerá una nueva opción dentro del menú principal del terminal.

La aplicaciones tendrán como entrada una opción denominada "Aplicaciones de Vendedor" en el menú principal del teléfono.

Esta opción será la cabecera de la aplicación SIM Toolkit. Al acceder a ella se abrirá un sub-menú con al menos dos opciones: "Módulo de Ventas" y "Módulo de Lectura de Comprobantes.".

\dotable{\tabskip6pt\hfil#\hfil\tabskip0ptplus1fil\dddarstrut\cr}{
   \uh{Aplicaciones de vendedor}  \cr   Módulo de
Ventas \cr   Módulo de Lectura de
Comprobantes \cr}

La primera permitirá al vendedor, que posea un establecimiento, implementar un medio de pago sencillo y fiable para todos aquellos clientes que dispongan de una tarjeta De Aplicaciones de Vendedor con la aplicación Nformática de comprador.

La segunda permite al vendedor la lectura en claro de los mensajes generados a consecuencia del uso de la aplicación informática de vendedor: comprobantes de anulaciones, duplicados, etc., y los comprobantes de ventas iniciadas por los clientes con la aplicación informática de comprador de sus SIMs.

Debido al gran número de aplicaciones que es necesario cargar en estas SIMs el tamaño mínimo recomendado de EEPROM es de 32K.

Módulo de ventas

Al seleccionar la opción "aplicaciones de vendedor", se presentará un menú con las siguientes opciones:

\dotable{\tabskip6pt\hfil#\hfil\tabskip0ptplus1fil\dddarstrut\cr}{
   \uh{Módulo de Ventas}  \cr   Devolución \cr 
 Duplicado de Operaciones \cr   Consulta de
Totales \cr}

Si el vendedor pulsa la tecla de retroceso, la aplicación volverá al menú "APLICACIONES DE VENDEDOR". Si elige cualquiera de estas opciones, procederá como se indica a continuación.

(Tecla de Retroceso: Tecla en un terminal móvil que permite ir hacia atrás durante la navegación en un menú SIM Toolkit. En la mayoría de los casos, no será una tecla especial sino una de las teclas utilizadas de manera común en el teléfono, por ejemplo, "Cancelar una llamada", a la que se añade una nueva funcionalidad).

Devolución

Si se selecciona esta opción, la aplicación preguntará al vendedor por la moneda en la que desea realizar la devolución mostrando la siguiente lista de opciones:

\dotable{\tabskip6pt\hfil#\hfil\tabskip0ptplus1fil\dddarstrut\cr}{
   \uh{MONEDA}  \cr   Pesetas \cr 
 Euros \cr}

Si el vendedor pulsa la tecla de retroceso, la aplicación regresará al menú "aplicaciones de vendedor". Al seleccionar una de las monedas, la aplicación solicitará el importe. Si la moneda solicitada es la peseta, se mostrará el mensaje:

\dotable{\tabskip6pt\hfil#\hfil\tabskip0ptplus1fil\dddarstrut\cr}{
   \uh{Importe: Pts}  \cr  - - - - - - - - -
-\cr}

Si la moneda seleccionada es el Euro, el mensaje mostrado será:

\dotable{\tabskip6pt\hfil#\hfil\tabskip0ptplus1fil\dddarstrut\cr}{
   \uh{Importe: E}  \cr   (0*00E) \cr  - - - - -
- - - -
-\cr}

En ambos casos, el vendedor podrá teclear un máximo de 12 y un mínimo de 1 dígito.

Si el vendedor pulsa la tecla de retroceso, la aplicación regresará al menú "MONEDA"

Sólo en el caso de que la moneda seleccionada sea la peseta, la aplicación SIM Toolkit validará que el vendedor no introduzca los caracteres `*', `#' y `+' como parte del importe. En caso de hacerlo, se advertirá de ello mostrando brevemente el mensaje:

\dotable{\tabskip6pt\hfil#\hfil\tabskip0ptplus1fil\dddarstrut\cr}{
  Introduzca sólo dígitos
(0  -  9) \cr}

Tanto si el vendedor confirma como si cancela el mensaje, se volverá a solicitar al mismo el importe.

En el caso de que la moneda predeterminada sea el Euro, la aplicación validará que el vendedor no introduzca más de 9 dígitos en la parte entera. En caso de que esto ocurra, la aplicación mostrará el mensaje:

\dotable{\tabskip6pt\hfil#\hfil\tabskip0ptplus1fil\dddarstrut\cr}{
  Longitud excede
límite \cr}

Una vez introducido correctamente el importe, se solicitará al vendedor la operación que identifica la devolución con el mensaje:

\dotable{\tabskip6pt\hfil#\hfil\tabskip0ptplus1fil\dddarstrut\cr}{
   \uh{TXN?}  \cr  - - - - - - -
-\cr}

El vendedor deberá introducir los 10 dígitos que identifican la devolución. Si, por el contrario, se presiona la tecla de retroceso, la aplicación solicitará de nuevo el importe.

Una vez introducida la operación, y antes de proceder al envío del mensaje corto con los datos, se solicitará al vendedor el NIP de comercio con el mensaje:

\dotable{\tabskip6pt\hfil#\hfil\tabskip0ptplus1fil\dddarstrut\cr}{
   \uh{NIP?}  \cr  - - - - - - - - -
-\cr}

El NIP introducido tendrá una longitud mínima y máxima de 4 dígitos y el terminal móvil no revelará el valor del mismo. La introducción de este NIP será siempre obligatoria.

(NIP bancario: Clave de 4 dígitos asociada a una tarjeta bancaria. (Número de Identificación Personal). El comerciante también dispondrá de un NIP).

El NIP de comerciante se grabará sólo entre encendidos, esto es, será necesario introducirlo una sola vez en cada encendido para poder leer mensajes recibidos. Pero será siempre obligatorio para realizar una transacción: Devolución, duplicado, etc.

Si el vendedor pulsa la tecla de retroceso, se solicitará de nuevo el valor de la transacción. Si no es así, se procederá al envío de un mensaje corto con los datos descritos a continuación.

\nobreak\vskip.5\baselineskip\centering\begin{tabular}{|l|l|l|l|}\hline
 Campo  \+ Long  \+ Long  \+ Valor \\   \+ min.  \+ máx. \+ \\\hline
 Comando  \+ 1  \+ 1  \+  D  \\\hline  0x01  \+ 1  \+ 1  \+
Separador \\\hline  Id. de  \+ 16  \+ 16  \+ Compuesto de 8
caracteres ASCII de \\  aplicación  \+  \+  \+ valor fijo:  BANCO
A0100  (4 de \\   \+  \+  \+ aplicación + 4 de versión) + un \\  
\+  \+  \+ número secuencial de 8 bytes \\   \+  \+  \+ codificado
en ASCII que será \\   \+  \+  \+ incrementado con el envío de cada
\\   \+  \+  \+ mensaje (1) \\\hline  0x01  \+ 1  \+ 1  \+ Separador
\\\hline  Importe  \+ 1  \+ 12  \+ Tecleado por el vendedor \\\hline
 0x01  \+ 1  \+ 1  \+ Separador \\\hline  Moneda  \+ 1  \+ 1  \+
Seleccionada por el vendedor. \\   \+  \+  \+ P (PTS) \\   \+  \+ 
\+ E (EUR) \\\hline  0x01  \+ 1  \+ 1  \+ Separador \\\hline 
Operación  \+  10  \+ 10  \+ Solicitado al vendedor \\\hline  0x01 
\+ 1  \+ 1  \+ Separador
\\\hline\end{tabular}\par\vskip.5\baselineskip

\trama

Al llegar el número máximo "99999999", el número deberá volver al 0.

(2) En el caso de los Euros, no aparecerán los caracteres de separación `*', `+' o `#'. Este campo se enviará formateado con dos decimales pero sin el carácter de separación en base a lo siguiente:

1.-: Si el vendedor no introduce ningún decimal, se añadirán dos ceros. Por ej.:

\dotable{\tabskip6pt\hfil#\hfil\+\hfil#\hfil\tabskip0ptplus1fil\dddarstrut\cr}{
 123* \+  \hskip2cm  12300\cr  123 \+
 \hskip2cm 12300\cr}

2.-: El vendedor sólo introduce un decimal, se añadirá un cero al final del importe:

\dotable{\tabskip6pt\hfil#\hfil\+\hfil#\hfil\tabskip0ptplus1fil\dddarstrut\cr}{
 123*1 \+  \hskip2cm 
12310\cr}

3.-: El vendedor introduce los dos decimales, tan sólo eliminaremos el separador introducido:

\dotable{\tabskip6pt\hfil#\hfil\+\hfil#\hfil\tabskip0ptplus1fil\dddarstrut\cr}{
 123+12 \+  \hskip2cm 
12312\cr}

4.-: El vendedor introduce más de dos decimales, se truncará el importe:

\dotable{\tabskip6pt\hfil#\hfil\+\hfil#\hfil\tabskip0ptplus1fil\dddarstrut\cr}{
 123 \# 1234  \+  \hskip2cm 
12312\cr}

5.-: Si el vendedor comete algún error, p.ej. introduce más de un separador en el importe, la aplicación actuará como si de un dígito se tratase teniendo sólo validez el primer separador encontrado por la izquierda.

6.-: En el caso de que el vendedor omita la parte entera del importe, p.ej. *12, la aplicación considerará dicha parte entera con valor cero pero enviará únicamente la parte decimal 12.

Este mensaje llevará cifrados los campos no sombreados con una clave obtenida a partir del NIP de comercio y el IMSI de la SIM. El algoritmo de cifrado será el 3XDES.

Si el vendedor pulsa la tecla de retroceso, se volverá a solicitar el NIP.

\dotable{\tabskip6pt\hfil#\hfil\tabskip0ptplus1fil\dddarstrut\cr}{
  Petición
realizada \cr}

\dotable{\tabskip6pt\hfil#\hfil\tabskip0ptplus1fil\dddarstrut\cr}{
  Petición no
realizada \cr}

Si el vendedor pulsa cualquier tecla mientras se muestra este mensaje, sea la de retroceso o no, la aplicación volverá al menú "APLICACIONES DE VENDEDOR".

Una vez enviado el mensaje corto, se recibirá de la Entidad Autorizadora un mensaje corto de confirmación de la devolución conteniendo los siguientes campos:

\nobreak\vskip.5\baselineskip\centering\begin{tabular}{|l|l|l|l|}\hline
 Campo  \+ Long  \+ Long  \+ Valor \\   \+ mín.  \+ máx. \+ \\\hline
 Comando  \+ 2  \+ 2  \+  D1  /  D2  \\\hline  Id. de  \+
4  \+ 4  \+  BANCO A  \\  aplicación \+ \+ \+ \\\hline  Datos
del  \+ 1  \+ 132  \+ Contenido del mensaje de \\  mensaje  \+  \+ 
\+  confirmación de la devolución
\\\hline\end{tabular}\par\vskip.5\baselineskip

La parte no sombreada del mensaje vendrá cifrada con el algoritmo 3XDES usando como clave el IMSI de la SIM y el NIP de comercio.

El titular al que hace referencia la devolución también recibirá un mensaje de respuesta en el caso de ser aceptada la transacción con los siguientes campos:

\nobreak\vskip.5\baselineskip\centering\begin{tabular}{|l|l|l|l|}\hline
 Campo  \+ Long  \+ Long.  \+ Valor \\   \+ min.  \+ máx. \+
\\\hline  Comando  \+ 2  \+ 2  \+  D3  \\\hline  Banco  \+ 6 
\+ 6  \+ Código del banco con el que \\   \+  \+  \+ realizó la
venta que ahora se \\   \+  \+  \+ devuelve. \\\hline  Id. de  \+ 4 
\+ 4  \+  BANCO A  \\  aplicación \+ \+ \+ \\\hline  Datos del 
\+ 1  \+ 124  \+ Contenido del mensaje de \\   \+  \+  \+ mensaje
confirmación de la devolución.
\\\hline\end{tabular}\par\vskip.5\baselineskip

Este mensaje llevará cifrados los campos no sombreados con una clave obtenida a partir del NIP correspondiente al banco con el que se realizó el pago y el IMSI de la SIM.

Duplicado

Al seleccionar esta opción se solicitará al vendedor el número de transacción con el siguiente mensaje:

\dotable{\tabskip6pt\hfil#\hfil\tabskip0ptplus1fil\dddarstrut\cr}{
   \uh{TXN?}  \cr  - - - - - - - -
-\cr}

Si el vendedor pulsa la tecla de retroceso, la aplicación volverá de nuevo al menú "aplicaciones de vendedor".

\newpage

Este campo también es opcional, así pues, el vendedor podrá introducir 0 ó 10 dígitos. En caso de que el vendedor introduzca de 1 a 9 dígitos, la aplicación mostrará brevemente el siguiente mensaje de error:

\dotable{\tabskip6pt\hfil#\hfil\tabskip0ptplus1fil\dddarstrut\cr}{
  Longitud válida 0 ó
10 \cr}

Sea cual sea la tecla pulsada por el vendedor (a no ser que se trate de la tecla de cancelación total), la aplicación volverá a solicitar la transacción.

Una vez introducida correctamente la transacción, la aplicación solicitará el NIP. La petición del NIP en este caso es siempre obligatoria:

\dotable{\tabskip6pt\hfil#\hfil\tabskip0ptplus1fil\dddarstrut\cr}{
   \uh{NIP?}  \cr  - - - - - - -
-\cr}

Si el vendedor pulsa la tecla de retroceso, se solicitará de nuevo el valor de la operación. Si no es así, se procederá al envío de un mensaje corto con los datos descritos a continuación.

\nobreak\vskip.5\baselineskip\centering\begin{tabular}{|l|l|l|l|}\hline
 Campo  \+ Long  \+ Long  \+ Valor \\   \+ mín.  \+ máx. \+ \\\hline
 Comando  \+ 1  \+ 1  \+  R  \\\hline  0x01  \+ 1  \+ 1  \+
Separador \\\hline  Id. de  \+ 16  \+ 16  \+ Compuesto de 8
caracteres ASCII de \\  aplicación  \+  \+  \+  valor fijo:  BANCO
A0100  (4 de \\   \+  \+  \+ aplicación + 4 de versión) + un \\  
\+  \+  \+ número secuencial de 8 bytes \\   \+  \+  \+ codificado
en ASCII que será \\   \+  \+  \+ incrementado con el envío de cada
\\   \+  \+  \+ mensaje (1) \\\hline  0x01  \+ 1  \+ 1  \+ Separador
\\\hline  0x01  \+ 1  \+ 1  \+ Separador (2) \\\hline  Operación  \+
0  \+ 10  \+ Tecleado por el vendedor \\\hline  0x01  \+ 1  \+ 1  \+
Separador
\\\hline\end{tabular}\par\vskip.5\baselineskip

\trama

Al llegar el número máximo "99999999", el número deberá volver al 0.

(2) Se incluye este campo separador, por compatibilidad de los mensajes de duplicado con la versión anterior de comercio en la que se incluía el campo "Referencia".

Este mensaje llevará cifrados los campos no sombreados con una clave obtenida a partir del NIP de comercio. El algoritmo de cifrado será el 3XDES.

Si el vendedor pulsa la tecla de retroceso, se volverá a solicitar el NIP.

\dotable{\tabskip6pt\hfil#\hfil\tabskip0ptplus1fil\dddarstrut\cr}{
  Petición
realizada \cr}

\dotable{\tabskip6pt\hfil#\hfil\tabskip0ptplus1fil\dddarstrut\cr}{
  Petición no
realizada \cr}

Una vez enviado el mensaje corto, se recibirá de la Entidad Autorizadora un mensaje corto con el duplicado conteniendo los siguientes campos:

\nobreak\vskip.5\baselineskip\centering\begin{tabular}{|l|l|l|l|}\hline
 Campo  \+ Long  \+ Long.  \+ Valor \\   \+ mín.  \+ máx. \+
\\\hline  Comando  \+ 2  \+ 2  \+  R1  /  R2  \\\hline 
Id. de  \+ 4  \+ 4  \+  BANCO A  \\  aplicación \+ \+ \+
\\\hline  Datos del  \+ 1  \+ 132  \+ Contenido del mensaje de \\ 
mensaje  \+  \+  \+ confirmación del pago
\\\hline\end{tabular}\par\vskip.5\baselineskip

La parte no sombreada del mensaje vendrá cifrada con el algoritmo 3XDES usando como clave el IMSI de la SIM y el NIP del comercio.

Consulta de Totales de Venta

Esta opción permitirá al vendedor de la aplicación hacer una consulta de totales (número de ventas, importe ventas,

\trama

) de un día determinado.

Al seleccionar esta opción, se solicitará al vendedor la fecha sobre la que desea realizar la consulta, con el mensaje:

\dotable{\tabskip6pt\hfil#\hfil\tabskip0ptplus1fil\dddarstrut\cr}{
   \uh{Fecha:ddmmaa?}  \cr  - - -
-\cr}

El vendedor deberá introducir los 6 dígitos correspondientes a la fecha en el formato indicado "ddmmaa".

Si el vendedor pulsa la tecla de retroceso, la aplicación regresará al menú "aplicaciones de vendedor". Si introduce la fecha y confirma su entrada la aplicación le solicitará la moneda en la que desea recibir los datos:

\dotable{\tabskip6pt\hfil#\hfil\tabskip0ptplus1fil\dddarstrut\cr}{
   \uh{MONEDA}  \cr   Pesetas \cr 
 Euros \cr}

En este caso, si se pulsa la tecla de retroceso, la aplicación volverá a pedir la fecha. Si, por el contrario, el vendedor selecciona una de las monedas, se solicitará el NIP de comercio. En este punto, la introducción del NIP es siempre obligatoria:

\dotable{\tabskip6pt\hfil#\hfil\tabskip0ptplus1fil\dddarstrut\cr}{
   \uh{NIP}  \cr  - - -
-\cr}

Si durante la solicitud del NIP, es pulsada la tecla de retroceso, la aplicación volverá a interrogar al vendedor por la moneda.

\newpage

Una vez introducido el NIP, la aplicación enviará un mensaje corto con el formato de datos descrito más abajo y los valores de configuración.

\nobreak\vskip.5\baselineskip\centering\begin{tabular}{|l|l|l|l|}\hline
 Campo  \+ Long  \+ Long  \+ Valor \\   \+ mín.  \+ máx. \+ \\\hline
 Comando  \+ 1  \+ 1  \+  T  \\\hline  0x01  \+ 1  \+ 1  \+
Separador \\\hline  Id. de  \+ 16  \+ 16  \+ Compuesto de 8
caracteres ASCII de \\  aplicación  \+  \+  \+ valor fijo:  BANCO
A0100  (4 de \\   \+  \+  \+ aplicación + 4 de versión) + un \\  
\+  \+  \+ número secuencial de 8 bytes \\   \+  \+  \+ codificado
en ASCII que será \\   \+  \+  \+ incrementado con el envío de cada
\\   \+  \+  \+ mensaje (1) \\\hline  0x01  \+ 1  \+ 1  \+ Separador
\\\hline  Moneda  \+ 1  \+ 1  \+ Seleccionada al vendedor \\   \+ 
\+  \+ P (PTS) \\   \+  \+  \+ E (EUR) \\\hline  0x01  \+ 1  \+ 1 
\+ Separador \\\hline  Fecha  \+ 6  \+ 6  \+ Solicitada al vendedor
\\\hline  0x01  \+ 1  \+ 1  \+ Separador
\\\hline\end{tabular}\par\vskip.5\baselineskip

\trama

Al llegar el número máximo "99999999", el número deberá volver al 0.

Este mensaje llevará cifrados los campos no sombreados con una clave obtenida a partir del NIP del comercio y el IMSI de la SIM. El algoritmo de cifrado será el 3XDES.

Si el vendedor pulsa la tecla de retroceso, se volverá a solicitar el NIP.

\dotable{\tabskip6pt\hfil#\hfil\tabskip0ptplus1fil\dddarstrut\cr}{
  Petición
realizada \cr}

\dotable{\tabskip6pt\hfil#\hfil\tabskip0ptplus1fil\dddarstrut\cr}{
  Petición no
realizada \cr}

Una vez enviado el mensaje corto, se recibirá de la Entidad Autorizadora un mensaje corto de respuesta de la consulta conteniendo los siguientes campos:

\nobreak\vskip.5\baselineskip\centering\begin{tabular}{|l|l|l|l|}\hline
 Campo  \+ Long  \+ Long.  \+ Valor \\   \+ mín.  \+ máx. \+
\\\hline  Comando  \+ 2  \+ 2  \+  T1  /  T2  \\\hline 
Id. de  \+ 4   \+ 4  \+  BANCO A  \\  aplicación \+ \+ \+
\\\hline  Datos del  \+ 1  \+ 130  \+ Contenido del mensaje de
respuesta \\  mensaje  \+  \+  \+ a la consulta.
\\\hline\end{tabular}\par\vskip.5\baselineskip

La parte no sombreada del mensaje vendrá cifrada con el algoritmo 3XDES usando como clave el IMSI de la SIM y el NIP del comerciante.

Módulo de lectura de comprobantes Comprobantes Generados por una Compra

Esta opción permite visualizar todos los comprobantes recibidos en el terminal de venta, tanto comprobaciones de ventas como comprobantes sobre consulta de movimientos o de totales. Dichos comprobantes se encuentran almacenados en el fichero de comprobantes.

Al seleccionar la opción, se llevará a cabo el siguiente procedimiento:

Se recorrerá el fichero de mensajes cortos buscando mensajes recibidos no borrados que cumplan los siguientes requisitos:

DCS del mensaje. Valor correcto: mensaje de Clase 2 "SIM specific" y de 8 bits.

SMSC válido. Los primeros seis dígitos del mismo deben corresponderse con: +34 607-003

Cualquier mensaje no borrado encontrado que no cumpla estos requerimientos, será eliminado.

Para cualquier mensaje encontrado que sí cumpla los requerimientos, se procederá de la siguiente forma:

Si el NIP fue introducido por el vendedor correctamente para la lectura de mensajes recibidos, éste no se volverá a pedir. Los mensajes serán descifrados, almacenados en claro en el fichero de Comprobantes eliminando el identificador de aplicación "BANCO A" y borrados del fichero de mensajes cortos.

A continuación, el contenido del mensaje almacenado en el fichero de Comprobantes será mostrado al vendedor utilizando la opción "esperar a que el vendedor limpie el mensaje".

Tanto si el vendedor confirma el mensaje como si lo cancela, la aplicación continuará con el proceso de recuperación.

Si el vendedor decide finalizar la sesión Toolkit, tampoco se abandonará dicho proceso.

Si el NIP no fue introducido correctamente en esta misma sesión para la lectura de mensajes recibidos, se solicitará al vendedor con el mensaje:

\dotable{\tabskip6pt\hfil#\hfil\tabskip0ptplus1fil\dddarstrut\cr}{
   \uh{NIP?}  \cr  - - - -
-\cr}

Si el vendedor pulsa la tecla de retroceso o de cancelación, no se abandonará el proceso de recuperación del mensaje.

Una vez introducido el NIP, la aplicación descifrará el contenido del mensaje utilizando el algoritmo 3XDES y una clave doble generada a partir del NIP introducido y el IMSI de la SIM.

Si tras descifrar el mensaje, los cuatro primeros bytes contienen el literal "BANCO A", el NIP introducido será válido y quedará presentado para la lectura de los mensajes hasta que sea apagado el terminal. El contenido del mensaje descifrado, eliminando el identificador de aplicación ("BANCO A"), será almacenado en el fichero de Comprobantes y eliminado del fichero de mensajes cortos.

A continuación, y del mismo modo que el descrito previamente, el contenido del mensaje almacenado en el fichero de Comprobantes será mostrado al vendedor utilizando la opción "esperar a que el vendedor limpie el mensaje".

El vendedor dispone de tres intentos por mensaje para introducir correctamente el NIP.

Si el vendedor introduce un NIP erróneo, la aplicación mostrará brevemente el mensaje:

\dotable{\tabskip6pt\hfil#\hfil\tabskip0ptplus1fil\dddarstrut\cr}{
  NIP
incorrecto \cr}

Tanto si el vendedor pulsa la tecla de retroceso como la de cancelación, la aplicación continuará con el procedimiento volviendo a solicitar el NIP.

Tras tres intentos fallidos, el vendedor perderá su comprobante que no podrá ya ser recuperado del fichero de mensajes cortos (se eliminará del mismo) y almacenará en un registro del fichero de Comprobantes el literal: "COMPROBANTE PERDIDO DEBIDO A NIP INCORRECTO". En pantalla, se mostrará al vendedor el siguiente mensaje:

\dotable{\tabskip6pt\hfil#\hfil\tabskip0ptplus1fil\dddarstrut\cr}{
  NIP incorrecto, comprobante
perdido \cr}

En caso de que el vendedor pulse la tecla de retroceso o de cancelación, la aplicación regresará al menú "APLICACIONES DE VENDEDOR".

En caso contrario, se continuará la exploración del fichero de mensajes cortos siguiendo el mismo procedimiento.

Una vez finalizada la exploración, se procederá a mostrar los mensajes almacenados del fichero.

En caso de que el vendedor no disponga de comprobantes almacenados, la aplicación mostrará el mensaje:

\dotable{\tabskip6pt\hfil#\hfil\tabskip0ptplus1fil\dddarstrut\cr}{
 Lista
vacía \cr}

Tanto si el vendedor presiona la tecla de retroceso como la tecla OK, la aplicación volverá al menú "APLICACIONES DE VENDEDOR".

A la hora de mostrar por pantalla los comprobantes se utilizará la opción "limpiar pasado un tiempo" del comando DISPLAY TEXT.

Si una vez mostrado un comprobante, el vendedor presiona la tecla de retroceso, la aplicación mostrará de nuevo el comprobante inmediatamente anterior, es decir, el mostrado en último lugar antes de éste. En caso de presionar la tecla de retroceso sobre el primer mensaje de la lista, la aplicación regresará también al menú "APLICACIONES DE VENDEDOR".

Los comprobantes se mostrarán en el orden inverso a como fueron almacenados, es decir, primero los almacenados más recientemente. Una vez mostrado el último o si el vendedor decide finalizar la sesión Toolkit, la aplicación repetirá de nuevo el proceso de exploración del fichero de mensajes cortos. Se persigue con ello recuperar los mensajes de Comprobantes recibidos mientras se mostraban los que ya se encontraban en el fichero. El procedimiento a seguir será prácticamente el mismo que el llevado a cabo al entrar en la opción "Leer Mensajes" con pequeñas modificaciones.

DCS del mensaje. Valor correcto: mensaje de Clase 2 "SIM specific" y de 8 bits.

SMSC válido. Los primeros seis dígitos del mismo deben corresponderse con: +34 607-003.

\dotable{\tabskip6pt\hfil#\hfil\tabskip0ptplus1fil\dddarstrut\cr}{
  \uh{NIP?}  \cr  - - - -
-\cr}

\dotable{\tabskip6pt\hfil#\hfil\tabskip0ptplus1fil\dddarstrut\cr}{
  NIP
incorrecto \cr}

\dotable{\tabskip6pt\hfil#\hfil\tabskip0ptplus1fil\dddarstrut\cr}{
 NIP incorrecto, comprobante
perdido \cr}

Esta aplicación debe mostrar todos los comprobantes recibidos hasta el momento que no hayan sido extraídos ya del fichero de Comprobantes (dado que se trata de un fichero cíclico).

Comprobantes de operaciones de compra

A la recepción de cualquier mensaje corto, se deberán hacer las siguientes validaciones para determinar si se trata de un mensaje perteneciente al sistema de aplicaciones informáticas de comprador: comprobantes de venta, de consulta de totales,

\trama

de gestión del propio sistema.

2.-: Se comprobará que el mensaje proceda de un SMSC válido. Los primeros seis dígitos del mismo deben corresponderse con: +34 607-003.

5.-: En el caso de los mensajes de gestión, su contenido se descifrará con la clave ADM4 y en sus primeros 5 bytes deberá aparecer el identificador de aplicación "AIR02".

Si realizadas dichas validaciones, se determina que el mensaje no pertenece al sistema de aplicaciones informáticas de comprador, se eliminará directamente del fichero de mensajes cortos. Se pretende con esta medida evitar que el fichero de mensajes cortos del comercio sea llenado de manera fraudulenta y esto le impida recibir los mensajes propios del sistema.

Mensaje comprobante de transacción

En caso de que se trate de un mensaje del sistema referente a un comprobante de transacción y no a un mensaje de gestión:

1. Si el NIP no había sido ya introducido correctamente en esta sesión (entre encendidos) con el fin de leer un mensaje recibido (aunque el comercio haya introducido el NIP previamente para realizar una de las operaciones de comercio, éste no se considerará presentado), se solicitará al vendedor con el mensaje:

\dotable{\tabskip6pt\hfil#\hfil\tabskip0ptplus1fil\dddarstrut\cr}{
  \uh{NIP?}  \cr  - - - -
-\cr}

Si el vendedor pulsa la tecla de retroceso o de cancelación, no se abandonará el proceso de lectura del mensaje.

Si tras descifrar el mensaje, los cuatro primeros bytes contienen el literal "BANCO A", el NIP introducido será válido y quedará presentado para la lectura de los mensajes hasta que sea apagado el terminal. El contenido del mensaje descifrado, eliminando el identificador de aplicación anterior ("BANCO A"), será almacenado en el fichero de Comprobantes y se mostrará al vendedor su contenido.

La opción utilizada en el comando DISPLAY TEXT para mostrar este mensaje debe ser: "esperar a que el vendedor limpie el mensaje".

Tras ser almacenado en el fichero de Comprobantes, el mensaje se eliminará del fichero de mensajes cortos.

\dotable{\tabskip6pt\hfil#\hfil\tabskip0ptplus1fil\dddarstrut\cr}{
  NIP
incorrecto \cr}

Tras tres intentos fallidos, el vendedor perderá su comprobante que no podrá ya ser recuperado del fichero de mensajes cortos (se eliminará del mismo) y almacenará en un registro del fichero de Comprobantes el literal: "COMPROBANTE PERDIDO DEBIDO A NIP INCORRECTO", y el NIP no será almacenado, volviéndose a demandar su presentación en la recepción del siguiente comprobante. En pantalla, se mostrará al vendedor el siguiente mensaje:

\dotable{\tabskip6pt\hfil#\hfil\tabskip0ptplus1fil\dddarstrut\cr}{
  NIP incorrecto, comprobante
perdido \cr}

2. Si el NIP ya estaba presentado, la aplicación descifrará el contenido cifrado del mensaje utilizando el algoritmo 3XDES y una clave doble generada a partir del NIP almacenado y el IMSI de la SIM.

Si tras descifrar el mensaje, los cuatro primeros bytes contienen el literal "BANCO A", el contenido del mensaje descifrado, eliminando el identificador de aplicación anterior ("BANCO A"), será almacenado en el fichero de Comprobantes y se mostrará al vendedor su contenido. La opción utilizada en el comando DISPLAY TEXT para mostrar este mensaje debe ser: "esperar a que el vendedor limpie el mensaje", igual que en el caso anterior.

Si los cuatro primeros bytes no contienen el literal "BANCO A", el mensaje no será considerado como válido y será eliminado del fichero de mensajes cortos, mostrando al vendedor el mensaje:

\dotable{\tabskip6pt\hfil#\hfil\tabskip0ptplus1fil\dddarstrut\cr}{
  NIP incorrecto, comprobante
perdido \cr}

En el fichero de Comprobantes, se almacenará el literal: "COMPROBANTE PERDIDO DEBIDO A NIP INCORRECTO".

Es importante anotar, que al tratarse ésta de una aplicación Toolkit asociada al evento "UPDATE SMS" podría no saltar si el usuario se encontrase navegando por el menú Toolkit. Será necesario proveer a la SIM de los mecanismos necesarios para que ninguno de los comprobantes recibidos, se pierda.

Mensajes de Operaciones de Vendedor

Una vez identificado un mensaje de Gestión aplicando las validaciones indicadas anteriormente, la aplicación mostrará brevemente al vendedor el mensaje:

\dotable{\tabskip6pt\hfil#\hfil\tabskip0ptplus1fil\dddarstrut\cr}{
  Terminal inicializado
correctamente \cr}

Una vez mostrado y sea cual sea la tecla pulsada por el vendedor, la aplicación realizará el procedimiento necesario para actualizar el contenido del fichero de Centro Autorizador, enviará al Servidor de Gestión del Operador de Telefonía Móvil un mensaje corto conteniendo en un byte el resultado del procedimiento y eliminará el mensaje del fichero de mensajes cortos.

Modificación del número del centro autorizador

El número destino al que el comercio enviará los mensajes, se encontrará almacenado en el fichero de Centro Autorizador y inicializado por el suministrador con el valor indicado. Ahora bien, si el comercio solicita un cambio de Centro Autorizador recibirá un mensaje corto que actualizará dicho número, será encaminado directamente a la SIM (mensajes enviados con Clase 2: "SIM specific message").

El formato de dicho mensaje será:

\nobreak\vskip.5\baselineskip\centering\begin{tabular}{|l|l|l|l|}\hline
 Nombre de  \+ Tipo  \+ Longitud  \+ Observaciones \\  campo \+ \+
\+ \\\hline  Identificador  \+ ASCII  \+ 5  \+ 3 bytes de aplicación
y 2 \\  del tipo de  \+  \+  \+ bytes de versión: `AIR02' \\ 
mensaje \+ \+ \+ \\\hline  Tipo de  \+ ASCII  \+ 1  \+ `G' \\ 
operación \+ \+ \+ \\\hline  Centro  \+ ASCII  \+ 12  \+ Número de
teléfono del \\  Autorizador  \+  \+  \+  Centro Autorizador en el
\\   \+  \+  \+ mismo formato que el \\   \+  \+  \+  utilizado para
los campos \\   \+  \+  \+ de dirección en los \\   \+  \+  \+
mensajes cortos(*)
\\\hline\end{tabular}\par\vskip.5\baselineskip

La longitud de la dirección, que también irá incluida en el campo Centro Autorizador indicará el número de semi- octetos útiles en el campo Address-Value, es decir, se excluye cualquier semi-octeto que contenga sólo bits de relleno. Se reservarán 12 octetos para este campo dado que esta es la longitud máxima permitida.

El contenido de estos mensajes irá cifrado con DES utilizando como clave la ADM4 cuarta clave administrativa asociada a cada SIM en cuestión. Para facilitar la gestión de dicha clave, ésta se copiará en personalización en un fichero protegido bajo el directorio de aplicación. Ambos, fichero y directorio, serán descritos más abajo.

`A' `I' `R' 0x00 0x01 `G' 0x01 0x23 0x45 0x67 0x89 0x10 0x11 0x12 0x13 0x14 0x15 0x16

Antes de cifrar el mensaje quedaría:

`A' Rnd `I' Rnd `R' Rnd 0x00 Rnd 0x01 Rnd `G' Rnd 0x01 Rnd 0x23 Rnd 0x45 Rnd 0x67 Rnd 0x89 Rnd 0x10 Rnd 0x11 Rnd 0x12 Rnd 0x13 Rnd 0x14 Rnd 0x15 Rnd 0x16 Rnd

Una vez realizada la actualización del fichero, la aplicación enviará un mensaje al número 4650 indicando con un byte el estado de la actualización según se indica en la tabla adjunta:

\nobreak\vskip.5\baselineskip\centering\begin{tabular}{|l|l|}\hline
 Código  \+ Descripción \\\hline  0x00  \+ OK. Procedimiento
realizado con éxito \\\hline  0x01  \+ Problema de memoria con la
tarjeta SIM. La tarjeta \\   \+ está defectuosa \\\hline  0x02  \+
Código de operación inválido. No se halló en el \\   \+ mensaje
 G . \\\hline  0x03  \+ El mensaje contiene un número de bytes
diferente \\   \+ de los necesarios para llevar a cabo la operación.
\\\hline\end{tabular}\par\vskip.5\baselineskip

Cifrado y descifrado de mensajes

Se parte de una clave doble 3DES de 16 bytes. Esta clave se compone:

-: Parte Izquierda (clave DES 8 bytes): Bloque IMSI

-: Parte derecha (clave DES de 8 bytes): Bloque NIP=LL PPPP FFFFFFFFFF, donde:

\dotable{\tabskip6pt#\hfil\+#\hfil\tabskip0ptplus1fil\dddarstrut\cr}{
 LL: Longitud de NIP (04) \+ - 1 byte\cr  PPPP: 4 dígitos del NIP \+
- 2 bytes\cr  FF's: Bloques de relleno a dígitos Fh \+ - 5
bytes\cr}

Notación:

: B' = DES<K>B

: B' es el bloque B cifrado con DES utilizando la clave K

: B = DDES<K>B'

: C = A XOR B

: C es el bloque obtenido haciendo un XOR byte de A con bytes de B

Proceso de Cifrado/Descifrado de un Bloque de 8 bytes con 3DES:

: 3DES<Kizq,Kdcha>Bloque =

DES<Kizq>(DDES<Kdcha>(DES<Kizq>Bloque))

: R1 = DES<Kizq>Bloque

: R2 = DDES<kdcha>R1

: Bloque' = DES<Kizq>R2

: 3DDES<Kizq,Kdcha>Bloque'=

DDES<Kizq>(DES<Kdcha>(DDES<Kizq>Bloque'))

: R1 = DDES<Kizq>Bloque'

: R2 = DES<kdcha>R1

: Bloque = DDES<Kizq>R2

Proceso de Cifrado de N Bloques de 8 bytes con 3XDES:

: 3XDES<Kizq,Kdcha>B1,...,BN =

: B1' = 3DES<Kizq,Kdcha>B1

: Bi' = 3DES<Kizq,Kdcha>(Bi XOR Bi-1') con i = 2..N

Proceso de Descifrado de N Bloques de 8 bytes con 3XDDES:

: 3XDDES<Kizq,Kdcha>B1',...,BN' =

: B1 = 3DES<Kizq,Kdcha>B1'

: Bi = (3DES<Kizq,Kdcha>Bi') XOR Bi-1' con i = 2..N

Requisitos técnicos de la aplicación Comandos Proactivos

Con el fin de intentar evitar en la medida de lo posible las diferencias entre aplicaciones implementadas por distintos suministradores de tarjeta SIM, a continuación, se indican los requerimientos básicos para la codificación de los comandos proactivos que constituyen la base de la aplicación descrita en este documento.

- Send Short Message

Los valores de configuración aplicables a los mensajes cortos serán:

Identificador del protocolo: PID = `00'

Esquema de codificación de los datos: DCS = `04'. Será preciso indicar como calificador del comando: "Packing not required"

Número del Centro Servidor de Mensajes Cortos: +34.607.00.31.41, TON&NPI = '91'

- Número destino

El número destino de cada mensaje corto enviado será obtenido del fichero de bancos y modificado en función de la operación realizada por el comprador según se explica a continuación. En el fichero de bancos se encuentra grabado para cada uno de ellos la dirección del Centro Autorizador que le corresponde. Una vez seleccionado el banco con el que realizar la transacción, podremos obtener la dirección base a la que enviar el mensaje. Esta dirección base debe modificarse en función de la operación a realizar. Los dos dígitos correspondientes a las posiciones tercera y cuarta comenzando a contar por detrás (p. ej. en un número de 9 dígitos las correspondientes a las letras CD: 607 12 CD 56) deben modificarse conforme a lo siguiente:

CD=00 \rightarrow Pago habitual

CD=01 \rightarrow Otros pagos

CD=02 \rightarrow Saldo

CD=03 \rightarrow Consultas

CD=04 \rightarrow Cambio NIP

- Display Text

Esquema de codificación de los datos DCS = '04'.

La prioridad del comando será siempre alta.

El mensaje se limpiará pasado un tiempo, a no ser que se indique la necesidad de que el mensaje sea limpiado por el comprador.

- Get Input

Esquema de codificación de los datos: DCS = '04'.

El alfabeto a utilizar será siempre el alfabeto SMS.

El ME podrá hacer eco de la entrada del comprador en el display salvo que se indique lo contrario.

La entrada del comprador se enviará siempre a la SIM en formato desempaquetado.

No se indicará la disponibilidad de ayuda al comprador.

- Finalizar una sesión

Siempre que el comprador presiona la tecla Cancelar, es decir, cuando el comprador decida terminar la sesión Toolkit, ésta finalizará volviendo al menú "APLICACIONES DE VENDEDOR".

- Procedimiento de error

Cualquier error producido durante la ejecución de la aplicación que resulte en un mal funcionamiento de la misma de cara al comprador será informado mostrando brevemente en pantalla el siguiente mensaje:

\dotable{\tabskip6pt\hfil#\hfil\tabskip0ptplus1fil\dddarstrut\cr}{
  Error! Visite la tienda más cercana de su Operador de \cr 
 Telefonía \cr}

Tras mostrar el mensaje, la aplicación se abortará regresando al menú "APLICACIONES DE VENDEDOR."

Claims

1. Sistema para realizar transacciones de pagos mediante telefonía móvil entre:

-: al menos una entidad autorizadora de la transacción de pago; y

donde dicho sistema de transacción de pagos comprende, al menos:

estando dicho sistema de transacción de pagos, caracterizado porque la aplicación informática para compradores comprende medios para mostrar en una pantalla del terminal de telefonía móvil del comprador:

-: dentro de dicho módulo de pagos y formando parte integrante del mismo:

2. Sistema para realizar transacciones de pagos mediante telefonía móvil, según la reivindicación 1, caracterizado porque la aplicación informática para compradores, adicionalmente comprende medios para mostrar en la pantalla del terminal de telefonía móvil del comprador:

-: medios de descifrado de mensajes entrantes de telefonía móvil correspondientes a comprobantes de compra, que emplean el código de seguridad del comprador para descifrar el mensaje.

3. Sistema para realizar transacciones de pagos mediante telefonía móvil, según la reivindicación 1, caracterizado porque la aplicación informática para vendedores comprende medios para mostrar en una pantalla del terminal del vendedor:

-: medios de descifrado de mensajes entrantes de al terminal del vendedor correspondientes a comprobantes de venta, que emplean el código de seguridad del vendedor para descifrar el mensaje.

4. Sistema para realizar transacciones de pagos mediante telefonía móvil, según la reivindicación 1, caracterizado porque la aplicación informática para vendedores, adicionalmente comprende medios para mostrar en la pantalla del terminal del vendedor:

-: al menos una opción de acceso a un menú de operaciones de vendedor en el que se muestra al menos una operación seleccionada entre: devolución de la venta, duplicado de transacción de venta y consulta de totales de venta, estando dicho menú provisto con medios de selección por parte del vendedor, de una de las operaciones de vendedor mostradas en el menú.

5. Sistema para realizar transacciones de pagos mediante telefonía móvil, según la reivindicación 4, caracterizado porque cuando el vendedor selecciona la opción de devolución de venta en el menú de operaciones de vendedor, la aplicación informática para vendedores comprende medios para mostrar en la pantalla del terminal del vendedor:

6. Sistema para realizar transacciones de pagos mediante telefonía móvil, según la reivindicación 4, caracterizado porque cuando el vendedor selecciona la opción de duplicado de transacción de venta en el menú de operaciones de vendedor, la aplicación informática para vendedores comprende medios para mostrar en la pantalla del terminal del vendedor:

7. Sistema para realizar transacciones de pagos mediante telefonía móvil, según la reivindicación 4, caracterizado porque cuando el vendedor selecciona la opción de consulta de totales de venta en el menú de operaciones de vendedor, la aplicación informática para vendedores comprende medios para mostrar en la pantalla del terminal del vendedor:

8. Sistema para realizar transacciones de pagos mediante telefonía móvil, según la reivindicación 1, caracterizado porque la aplicación informática para compradores incluye en el menú de formas de pago:

-: al menos una opción de acceso a un menú en el que se muestran el resto de formas de pago activas para dicho comprador en la entidad financiera seleccionada, estando dicho menú de resto de formas de pagos provisto con medios de selección por parte del comprador, de uno de los medios de pago mostrados en el menú.

9. Sistema para realizar transacciones de pagos mediante telefonía móvil, según la reivindicación 1, caracterizado porque tras la selección de una entidad financiera en el menú de entidades financieras, la aplicación informática para compradores incluye:

10. Sistema para realizar transacciones de pagos mediante telefonía móvil, según la reivindicación 9, caracterizado porque cuando el comprador selecciona la opción de consulta de saldo en el menú de operaciones de comprador, la aplicación informática para compradores comprende medios para mostrar en la pantalla del terminal del comprador:

11. Sistema para realizar transacciones de pagos mediante telefonía móvil, según la reivindicación 9, caracterizado porque cuando el comprador selecciona la opción de consulta de compra en el menú de operaciones de comprador, la aplicación informática para compradores comprende medios para mostrar en la pantalla del terminal del comprador:

12. Sistema para realizar transacciones de pagos mediante telefonía móvil, según la reivindicación 9, caracterizado porque cuando el comprador selecciona la opción de cambio del código de seguridad del comprador en el menú de operaciones de comprador, la aplicación informática para compradores comprende medios para mostrar en la pantalla del terminal del comprador:

13. Sistema para realizar transacciones de pagos mediante telefonía móvil, según la reivindicación 9, caracterizado porque cuando el comprador selecciona la opción de configuración de la forma de pago seleccionada por defecto en el menú de operaciones de comprador, la aplicación informática para compradores comprende medios para mostrar en la pantalla del terminal del comprador:

-: medios de almacenamiento de la forma de pago seleccionada en la aplicación informática para compradores.

14. Sistema para realizar transacciones de pagos mediante telefonía móvil, según la reivindicación 9, caracterizado porque cuando el comprador selecciona la opción de configuración de la moneda a emplear por defecto en el menú de operaciones de comprador, la aplicación informática para compradores comprende medios para mostrar en la pantalla del terminal del comprador:

-: medios de almacenamiento de la moneda seleccionada en la aplicación informática para compradores.

15. Sistema para realizar transacciones de pagos mediante telefonía móvil, según la reivindicación 1, caracterizado porque con anterioridad al mensaje de petición del código de seguridad del comprador, la aplicación informática para compradores comprende medios para mostrar en la pantalla del terminal de telefonía móvil del comprador, al menos un dato del conjunto de datos seleccionados e introducidos anteriormente por el comprador.

16. Sistema para realizar transacciones de pagos mediante telefonía móvil, según cualquiera de las reivindicaciones 5-7, caracterizado porque con anterioridad al mensaje de petición del código de seguridad del vendedor, la aplicación informática para vendedores comprende medios para mostrar en la pantalla del terminal del vendedor, al menos un dato del conjunto de datos seleccionados e introducidos anteriormente por el vendedor.

17. Sistema para realizar transacciones de pagos mediante telefonía móvil, según cualquiera de las reivindicaciones 10 y 11, caracterizado porque con anterioridad al mensaje de petición del código de seguridad del comprador, la aplicación informática para compradores comprende medios para mostrar en la pantalla del terminal del comprador:

-: al menos una opción de acceso a un menú de monedas, estando dicho menú de monedas provisto con medios de selección por parte del comprador, de una de las monedas mostradas en el menú, en la cual dicho comprador solicita recibir los importes relativos a la consulta.

18. Sistema para realizar transacciones de pagos mediante telefonía móvil, según la reivindicación 7, caracterizado porque con anterioridad al mensaje de petición del código de seguridad del vendedor, la aplicación informática para vendedores comprende medios para mostrar en la pantalla del terminal del vendedor:

-: al menos una opción de acceso a un menú de monedas, estando dicho menú de monedas provisto con medios de selección por parte del vendedor, de una de las monedas mostradas en el menú, en la cual dicho vendedor solicita recibir los importes relativos a la consulta.

19. Sistema para realizar transacciones de pagos mediante telefonía móvil, según la reivindicación 5, caracterizado porque con anterioridad al mensaje de petición del importe de la venta, la aplicación informática para vendedores comprende medios para mostrar en la pantalla del terminal del vendedor:

-: al menos una opción de acceso a un menú de monedas, estando dicho menú de monedas provisto con medios de selección por parte del vendedor, de una de las monedas mostradas en el menú, en la cual dicho vendedor introducirá el importe de la venta devolver.

20. Sistema para realizar transacciones de pagos mediante telefonía móvil, según cualquiera de las reivindicaciones 1-2, 8-15 y 17, caracterizado porque la aplicación informática para compradores comprende medios para verificar criterios de validez en los dígitos, caracteres y símbolos introducidos por el comprador, así como medios mostrar en la pantalla del terminal del comprador mensajes informativos relativos a la introducción inválida de dichos dígitos, caracteres y símbolos.

21. Sistema para realizar transacciones de pagos mediante telefonía móvil, según cualquiera de las reivindicaciones 3-7, 16 y 18-19, caracterizado porque la aplicación informática para vendedores comprende medios para verificar criterios de validez en los dígitos, caracteres y símbolos introducidos por el vendedor, así como medios mostrar en la pantalla del terminal del vendedor mensajes informativos relativos a la introducción inválida de dichos dígitos, caracteres y símbolos.

22. Sistema para realizar transacciones de pagos mediante telefonía móvil, según cualquiera de las reivindicaciones 1-2, 8-15, 17 y 20, caracterizado porque la aplicación informática para compradores comprende medios para mostrar en la pantalla del terminal del comprador mensajes informativos de error cuando cualquier proceso de dicha la aplicación informática para compradores no pueda ejecutarse, bien por causas internas a dicha aplicación, o bien por causas externas relativas a mensajes entrantes al terminal del comprador.

23. Sistema para realizar transacciones de pagos mediante telefonía móvil, según cualquiera de las reivindicaciones 3-7, 16, 18-19 y 21, caracterizado porque la aplicación informática para vendedores comprende medios para mostrar en la pantalla del terminal del vendedor mensajes informativos de error cuando cualquier proceso de la aplicación informática para vendedores no pueda ejecutarse, bien por causas internas a dicha aplicación, o bien por causas externas relativas a mensajes entrantes al terminal del vendedor.

24. Sistema para realizar transacciones de pagos mediante telefonía móvil, según cualquiera de las reivindicaciones 1-2, 8-15, 17, 20 y 22, caracterizado porque los medios de selección y de introducción de información, de la aplicación informática para compradores, comprenden al menos un interfaz seleccionado entre: teclado, pantalla táctil, elemento giratorio, reconocimiento de voz y combinaciones de los mismos.

25. Sistema para realizar transacciones de pagos mediante telefonía móvil, según cualquiera de las reivindicaciones 3-7, 16, 18-19, 21 y 23, caracterizado porque los medios de selección y de introducción de información, de la aplicación informática para vendedores, comprenden al menos un interfaz seleccionado entre: teclado, pantalla táctil, elemento giratorio, reconocimiento de voz y combinaciones de los mismos.

26. Sistema para realizar transacciones de pagos mediante telefonía móvil, según cualquiera de las reivindicaciones 1-2, 8-15, 17, 20, 22 y 24, caracterizado porque la aplicación informática para compradores está implementada conforme un estándar GSM definido para "SIM Toolkit" (estándar que permite definir a operadores de telefonía móvil un conjunto de aplicaciones residentes en el módulo de identificación del usuario).

27. Sistema para realizar transacciones de pagos mediante telefonía móvil, según cualquiera de las reivindicaciones 3-7, 16, 18-19, 21, 23 y 25, caracterizado porque la aplicación informática para vendedores está implementada conforme un estándar GSM definido para "SIM Toolkit" (estándar que permite definir a operadores de telefonía móvil un conjunto de aplicaciones residentes en el módulo de identificación del usuario).

28. Sistema para realizar transacciones de pagos mediante telefonía móvil, según cualquiera de las reivindicaciones 1-2, 8-15, 17, 20, 22, 24 y 26, caracterizado porque el comprador tiene asignados códigos de seguridad no necesariamente coincidentes entre sí, para cada una de las entidades financieras que se encuentran activas para dicho comprador.

29. Sistema para realizar transacciones de pagos mediante telefonía móvil, según cualquiera de las reivindicaciones 3-7, 16, 18-19, 21, 23, 25 y 27, caracterizado porque el vendedor tiene asignados códigos de seguridad no necesariamente coincidentes entre sí, para cada una de las entidades financieras que se encuentran activas para dicho vendedor.

30. Sistema para realizar transacciones de pagos mediante telefonía móvil, según cualquiera de las reivindicaciones 3-7, 16, 18-19, 21, 23, 25, 27 y 29, caracterizado porque el término "vendedor" es equivalente al menos, a un término seleccionado entre: persona vendedora, comercio vendedor físico, empresa vendedora física, comercio vendedor virtual, empresa vendedora virtual y combinaciones de los mismos.