Procedimiento y sistema de gestión de operaciones en un terminal de telecomunicaciones con máquina de estados.

Un procedimiento para gestionar una operación en un terminal de servicio (201,

301) mediante un servidor remoto (202, 302), en el que dicho terminal de servicio (201, 301) comprende una pluralidad de módulos (203, 303), una máquina de estados (210, 310), configurada para cargar algoritmos correspondientes a aplicaciones y ejecutar dichas aplicaciones, y, una interfaz de comunicaciones (204, 304) configurada para comunicarse con dicho servidor remoto (202, 302), en el que dicho servidor remoto (202, 302) comprende una interfaz de comunicaciones (207, 307) configurada para comunicarse con dicho terminal de servicio (201, 301) y una pluralidad de aplicaciones (209, 309) en el que cada una de dichas aplicaciones (209, 309) comprende un algoritmo (208, 308) definido de tal forma que sus estados, transiciones entre estados y condiciones pueden ser transmitidos mediante dicha interfaz de comunicaciones (207, 307),

estando el procedimiento caracterizado por las etapas de:

- enviar una petición desde dicho terminal de servicio (201, 301) a dicho servidor remoto (202, 302) para descargar, al menos, un algoritmo (208, 308) de, al menos, una aplicación (209, 309);

- transmitir dicho, al menos un algoritmo (208, 308) desde dicho servidor (202, 302) al terminal de servicio (201, 301) y cargarlo en dicha máquina de estados (210, 310);

- generar un evento como respuesta a una interacción de usuario con uno de dichos módulos (203, 303) del terminal de servicio (201, 301);

- asociar a dicho evento una información y enviarla a la máquina de estados (210, 310);

- procesar dicha información en la máquina de estados (210, 310) y obtener al menos una operación a realizar sobre cualquiera de los módulos (203, 303) del terminal de servicio (201, 301) utilizando dicho, al menos un algoritmo (208, 308) ya cargado en la máquina de estados (210, 310);

- identificar el módulo (203, 303) sobre el que dicha al menos una operación está destinada a ser realizada e interactuar con dicho módulo (203, 303) realizando dicha al menos una operación en el terminal de servicio (201, 301).

Procedimiento y sistema de gestión de operaciones en un terminal de telecomunicaciones con máquina de estados Campo de la invención La presente invención se refiere al campo de las telecomunicaciones y, más en particular, se refiere al campo de los terminales de servicio conectados a un servidor remoto.

Estado de la técnica

Concretamente, un Punto de Venta (TPV) (en inglés Point of sale POS) es un sistema que gestiona el proceso de venta mediante una interfaz accesible para vendedores, pero en términos generales se aplica a cualquier aplicación desde la que se facilita un proceso de venta. Por ello se puede realizar una clasificación:

! Aplicaciones completas para PC, cuyas funciones básicas son típicamente la creación e impresión del recibo, ticket

o factura de venta, que comprende las referencias y precios detallados de los artículos vendidos, actualizar el nivel

de existencias y mercancías en la base de datos y permitir la autorización para el pago con tarjetas de

crédito/débito que posteriormente es transferida a las entidades bancarias.

! Puede haber enfoques compactos, donde todos los elementos necesarios están integrados en el terminal (CPU,

impresora, pantalla, teclado) en una sola máquina, así como enfoques modulares, basados en un PC convencional,

donde se conectan los distintos periféricos, junto con un software instalado sobre un sistema operativo

convencional, lo cual permite el uso de funciones típicas de un PC.

! Datafonos, dispositivos de pequeño tamaño, basados en un teclado reducido, varios tipos de lector de tarjetas

(banda magnética, tarjeta inteligente, sin contacto) y un software de aplicación que se comunica con la parte

servidora remota.

! WebPOS, donde el acceso por un navegador de internet y una aplicación Web a los procedimientos necesarios

para realizar la venta está garantizado, típicamente con cargo a una tarjeta de crédito/débito.

! mPOS (mobile POS) , en dónde el teléfono se convierte en el dispositivo para realizar las transacciones de venta.

Pueden ser variantes de los casos anteriores: un webPOS que se ejecuta en el teléfono o añadiendo un

componente capaz de leer cualquier tipo de tarjeta, actuando como un datafono.

Dentro de esta clasificación, centrándose en los datafonos, el modelo de operación actual es que las aplicaciones se ejecutan en el dispositivo y cuando finaliza la operación se envían los datos de la transacción al servidor con el que se comunica, para consolidar los datos, utilizando para ello cualquier tecnología de transmisión de datos.

El panorama de este tipo de dispositivos se caracteriza por la diversidad de fabricantes y porque los desarrollos son realizados a medida por cada fabricante: no son sistemas abiertos en el que quien quiera pueda hacer desarrollos, no es habitual que para un TPV puedan realizarse fácilmente desarrollos por terceros.

Han surgido varias iniciativas para lograr la estandarización de los dispositivos, de forma que, con independencia del fabricante, los dispositivos expongan un API común y los desarrollos puedan trasladarse de forma transparente de un dispositivo a otro, de un fabricante a otro, sin ningún problema. Dentro de estas iniciativas destacan STIP (Small Terminal Interoperable Platform) , de GlobalPlatform [http://www.globalplatform.org/] o UnifiedPOS [http://www.nrfarts.org/UnifiedPOS/]

STIP es el acrónimo de Small Terminal Interoperability Platform (“Plataforma de interoperabilidad de terminales pequeños”) . El consorcio STIP es un grupo de proveedores de soluciones de transacciones seguras, lo cual incluye, fabricantes de terminales, fabricantes de tarjetas inteligentes y otros. Fue formado para definir una especificación Java para terminales pequeños y dispositivos orientados a transacciones.

En la figura 1 se muestra la arquitectura subyacente a la tecnología STIP. La plataforma 11 expone a través de sus interfaces software 15 las capacidades de interacción sobre ella de los diferentes elementos que la componen 13, tales como la impresora, el lector de banda magnética, lector de tarjetas sin contacto … Una aplicación 12 incluye un elemento principal 16 que controla la operación de la misma, así como un conjunto de servicios intermedios 14, que permitan interactuar con la plataforma 11 y sus elementos 13.

Las interfaces 15 expuestas tanto por los elementos 13 de la plataforma como por los servicios intermedios de la aplicación 14 siguen un modelo en el que los servicios generan eventos ante cambios en el estado de los componentes, mientras que la aplicación realiza peticiones a los servicios 14 para controlar su operación.

El objetivo de STIP es especificar una plataforma software que proporcione lo siguiente:

! soporte para múltiples aplicaciones de transacciones seguras en un terminal, ! interoperabilidad para que las aplicaciones puedan ser ejecutadas en un amplio rango de dispositivos, ! un procedimiento de gestión del ciclo de vida de aplicación que pueda ser implementado en dispositivos de

pequeño tamaño, con recursos limitados, algo habitual en el entorno de dispositivos de tarjetas.

La tecnología STIP satisface los requisitos funcionales anteriores a través de las siguientes características:

! Lenguaje de programación de alto nivel común: la base de interoperabilidad de aplicaciones en diferentes plataformas hardware es utilizar un lenguaje de programación común con independencia del hardware subyacente. La solución de STIP confía en el uso de lenguajes orientados a objetos como Java. Además, la tecnología STIP ha definido un subconjunto de la base más común del API de Java para proporcionar un subconjunto común utilizable en todas las plataformas, independientemente de la versión del lenguaje implementado. ! Definición de los accesos a los recursos y periféricos comunes en terminales pequeños de forma portable: el acceso a todos los recursos se realiza mediante controles de servicio.

La principal dificultad es proporcionar un API flexible que permita varias configuraciones de periféricos y, al mismo tiempo, no comprometer e incluso reforzar la seguridad y la interoperabilidad. La solución se apoya en el siguiente enfoque: cada posible recurso de la plataforma (periféricos, almacenamiento…) es considerado como un servicio 14, que es implementado por una biblioteca software si está presente en la plataforma. El API de STIP no proporciona ningún acceso directo a esas bibliotecas.

Por otra parte, una aplicación puede, únicamente, acceder a un interfaz de control de servicio 15 estandarizado para cada servicio. Para acceder y utilizar un servicio, la aplicación debe solicitar la apertura de un canal de comunicación entre el control del servicio que maneja y el servicio real escondido tras él.

Además, para obtener un objeto de control de servicio de un tipo concreto, la aplicación debe primero solicitar al gestor de control de servicios un objeto de control de servicio del mismo tipo. Hay ciertas ventajas que surgen al utilizar este enfoque:

! Cuando un tipo particular de servicio no está presente en una plataforma determinada, no es necesario que la plataforma implemente el control de servicio relacionado. La plataforma STIP sólo define la declaración del interfaz del control de servicio pero no su implementación. De este modo, la interoperabilidad es posible sin sacrificar la flexibilidad.

! Las aplicaciones no tratan con APIs de servicio específicas sino con API de control de servicio estandarizados. Esto es importante para la interoperabilidad puesto que las bibliotecas pueden ser específicas de la plataforma pero el interfaz puede ser común para todas las plataformas. ! La seguridad se maneja de una forma cómoda por parte de la plataforma, puesto que no se puede acceder a ningún recurso sin dos solicitudes específicas desde la aplicación. Estas solicitudes se utilizan para obtener la instancia del control de servicio y para abrir a través de este control de servicio un canal de comunicación con el servicio específico. De este modo, las implementaciones de servicios reales están automáticamente protegidas por la plataforma.

Resumiendo, STIP satisface las necesidades de flexibilidad, seguridad e interoperabilidad.

El enfoque de STIP se sustenta en el uso sistemático de un estilo de programación basado en eventos. La maquinaria subyacente para solicitar eventos es simple, completamente especificada e independiente de la implementación. Esto mejora la programación de aplicaciones altamente reactivas a la vez que refuerza la seguridad e interoperabilidad de aplicaciones.

El modelo de operación habitual es que las diferentes... [Seguir leyendo]

1. Un procedimiento para gestionar una operación en un terminal de servicio (201, 301) mediante un servidor remoto (202, 302) , en el que dicho terminal de servicio (201, 301) comprende una pluralidad de módulos (203, 303) , una máquina de estados (210, 310) , configurada para cargar algoritmos correspondientes a aplicaciones y ejecutar dichas aplicaciones, y, una interfaz de comunicaciones (204, 304) configurada para comunicarse con dicho servidor remoto (202, 302) , en el que dicho servidor remoto (202, 302) comprende una interfaz de comunicaciones (207, 307) configurada para comunicarse con dicho terminal de servicio (201, 301) y una pluralidad de aplicaciones (209, 309) en el que cada una de dichas aplicaciones (209, 309) comprende un algoritmo (208, 308) definido de tal forma que sus estados, transiciones entre estados y condiciones pueden ser transmitidos mediante dicha interfaz de comunicaciones (207, 307) ,

estando el procedimiento caracterizado por las etapas de:

-enviar una petición desde dicho terminal de servicio (201, 301) a dicho servidor remoto (202, 302) para descargar, al menos, un algoritmo (208, 308) de, al menos, una aplicación (209, 309) ;

-transmitir dicho, al menos un algoritmo (208, 308) desde dicho servidor (202, 302) al terminal de servicio (201, 301) y cargarlo en dicha máquina de estados (210, 310) ;

-generar un evento como respuesta a una interacción de usuario con uno de dichos módulos (203, 303) del terminal de servicio (201, 301) ;

-asociar a dicho evento una información y enviarla a la máquina de estados (210, 310) ;

-procesar dicha información en la máquina de estados (210, 310) y obtener al menos una operación a realizar sobre cualquiera de los módulos (203, 303) del terminal de servicio (201, 301) utilizando dicho, al menos un algoritmo (208, 308) ya cargado en la máquina de estados (210, 310) ;

-identificar el módulo (203, 303) sobre el que dicha al menos una operación está destinada a ser realizada e interactuar con dicho módulo (203, 303) realizando dicha al menos una operación en el terminal de servicio (201, 301) .

2. El procedimiento de la reivindicación 1, en el que dicha información asociada a un evento comprende: un identificador del módulo (203, 303) que ha generado dicho evento y un identificador de operación que representa el evento particular generado por dicho módulo (203, 303) .

3. El procedimiento de la reivindicación 2, en el que dicha información asociada comprende, además, una pluralidad de parámetros que representan datos adicionales de información de dicho evento.

4. El procedimiento de cualquiera de las reivindicaciones anteriores, en el que cada uno de dichos módulos (203, 303) comprendidos en dicho terminal de servicio (201, 301) es un módulo periférico que comprende un módulo de control (205, 305) .

5. El procedimiento de cualquiera de las reivindicaciones anteriores en el que dicha petición para descargar, al menos, un algoritmo (208, 308) de, al menos, una aplicación (209, 309) es enviada cuando se enciende el terminal de servicio (201, 301) .

6. El procedimiento de cualquiera de las reivindicaciones 1 a 4 en el que dicha petición para descargar, al menos, un algoritmo (208, 308) de, al menos, una aplicación (209, 309) es enviada en determinados momentos del día.

7. El procedimiento de cualquiera de las reivindicaciones 1 a 4 en el que dicha petición para descargar, al menos, un algoritmo (208, 308) de, al menos, una aplicación (209, 309) la realiza el usuario de forma manual mediante el terminal de servicio (201, 301) .

8. El procedimiento de cualquiera de las reivindicaciones 1 a 4 en el que dicha petición para descargar, al menos, un algoritmo (208, 308) de, al menos, una aplicación (209, 309) es enviada por el terminal de servicio (201, 301) a través de un puerto de conexión también utilizado por el servidor remoto (202, 302) en un momento diferido en el tiempo.

9. El procedimiento de cualquiera de las reivindicaciones 1 a 4 en el que dicha petición para descargar, al menos, un algoritmo (208, 308) de, al menos, una aplicación (209, 309) es enviada en el momento de la ejecución de una operación en el terminal de servicio (201, 301) por lo que se necesita, al menos, una aplicación (209, 309) .

10. Un sistema que comprende una pluralidad de terminales de servicio (201, 301) y un servidor remoto (202, 302) , estando la pluralidad de terminales de servicio (201, 301) adaptada para realizar una gestión de las operaciones de acuerdo con los pasos del procedimiento de cualquier reivindicación anterior.

11. El sistema de la reivindicación 10, en el que cada uno de dichos terminales de servicio (301) comprende, además, un almacén de aplicaciones (311) configurado para almacenar los algoritmos (308) de las aplicaciones

(309) transmitidos desde el servidor remoto (302) al terminal de servicio (301) previamente a la carga de dichos algoritmos (308) en la máquina de estados (310) .

12. Un programa de ordenador que comprende medios de código de programa de ordenador adaptados para llevar a cabo el procedimiento según cualquiera de las reivindicaciones 1 a 9, cuando dicho programa se ejecuta en un ordenador, un procesador de señal digital, una matriz de puertas programable en campo, un circuito integrado de aplicación específica, un microprocesador, un microcontrolador, y cualquier otra forma de hardware programable.