MX2012010195A - Metodo y sistema de gestion de operaciones en un terminal de telecomunicaciones. - Google Patents

Abstract

Un método para gestionar una operación en un terminal de servicio a través de un servidor remoto, donde dicho terminal de servicio comprende una pluralidad de módulos, y una interfaz de comunicaciones configurada para que dicho terminal de servicio se comunique con dicho servidor remoto, donde dicho servidor remoto comprende una pluralidad de aplicaciones. El método comprende las etapas de: generar un evento como respuesta a una interacción de un usuario con uno de dichos módulos del terminal de servicio; asociar a dicho evento una información; enviar dicha información al servidor remoto a través de dicha interfaz de comunicaciones; procesar dicha información recibida en el servidor remoto y ejecutar una aplicación que obtiene una respuesta a la información asociada a dicho evento; enviar dicha respuesta al terminal de servicio a través de dicha interfaz de comunicaciones; procesar dicha respuesta e identificar el módulo del terminal de servicio afectado por la misma; interactuar con dicho módulo realizando una operación en el terminal de servicio.

Description

MÉTODO Y SISTEMA DE GESTIÓN DE OPERACIONES EN UN TERMINAL DE TELECOMUNICACIONES CAMPO DE LA INVENCIÓN La presente invención se engloba en el campo de las telecomunicaciones y, concretamente, en el campo de los terminales de servicio conectados a un servidor remoto.

ANTECEDENTES DE LA INVENCIÓN Se conoce como Terminal Punto de Venta (TPV) (en inglés Point of sale POS) a un sistema que gestiona el proceso de venta mediante una interfaz accesible para los vendedores, pero por generalización 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, con los detalles de las referencias y precios de los artículos vendidos, actualizar los cambios en el nivel de existencias de mercancías (stock) 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 aproximaciones tanto compactas, que integran todos los elementos necesarios en el terminal (CPU, impresora, pantalla, teclado) en una sola máquina, como modulares, basados en un PC convencional, donde se conectan los distintos periféricos, con un software instalado sobre un sistema operativo convencional, permitiendo el uso para funciones típicas de un PC.

• Datáfonos, dispositivos de pequeño tamaño, basados en un teclado reducido, un lector de tarjetas, de diferentes tipos (banda magnética, smart card, contactless) y un software de aplicación que se comunica con la parte Servidora remota.

• WebPOS, se accede por un navegador de internet y una aplicación Web a los procedimientos para la realizar la venta, típicamente con cargo a una tarjeta. · mPOS (mobile POS), en dónde el móvil 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 móvil o añadiendo un componente capaz de leer algún tipo de tarjeta, actuar como un datáfono.

Dentro de esta clasificación, centrándose en los datáfonos, el modelo de funcionamiento 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.

En este entorno han surgido 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. nrf-arts. 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, de contacless, ...

Una aplicación 12 incluye un elemento principal 16 que controla el funcionamiento 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 funcionamiento.

El objetivo de STIP es especificar una plataforma software que proporcione lo siguiente: • soporte para múltiples aplicaciones de transacciones seguras en un terminal, • ¡nteroperabilidad para que las aplicaciones puedan ser ejecutadas en un amplio rango de dispositivos, · un método 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 ¡nteroperabilidad 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. Más allá, 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 dificultad central 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 la siguiente aproximación: cada posible recurso de la plataforma (periféricos, almacenamiento...) es considerado como un servicio, que es implementado por una librería software si está presente en la plataforma. El API de STIP no proporciona ningún acceso directo a esas librerías.

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 esta aproximación: • 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 APIs de control de servicio estandarizados. Esto es importante para la interoperabilidad puesto que las librerías 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.

En conclusión, STIP satisface tanto la necesidad de flexibilidad, seguridad e interoperabilidad.

La aproximación 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 funcionamiento habitual es que las diferentes opciones de ejecución se encuentran en la aplicación existente en el propio dispositivo, y para actualizar la aplicación es necesario realizar un mantenimiento dispositivo por dispositivo. Este mantenimiento, bien se realice de forma remota o de forma local, es necesario hacerlo para cada dispositivo, con una complejidad en el proceso de actualización y un incremento en coste de acuerdo con la planta instalada.

Por ello es de especial interés simplificar la actualización de las aplicaciones que se ejecutan en el TPV. En esta línea el camino tomado ha sido trasladar la lógica de las aplicaciones desde el TPV al servidor, de tal forma que en vez de conectarse al servidor únicamente al finalizar la transacción, el TPV se conecta al servidor en pasos intermedios, con lo que el TPV puede ser más simple y se pueden implementar aplicaciones con una flexibilidad que de otra forma no sería posible. Esta es la idea fundamental de la patente US 5696909.

En la actualidad se han propuesto aproximaciones relacionadas que trasladan el modelo de aplicaciones web para Internet al funcionamiento para un TPV; de esta forma, el TPV se convierte en un browser, con capacidades para interpretar un lenguaje de marcas y gestionar los recursos del dispositivo, realizando peticiones para descargarse las nuevas páginas según se necesiten.

Estas propuestas suponen un avance en la idea de trasladar el control de la aplicación al servidor pero siguen presentando limitaciones: La patente US 5696909 establece un modelo general basado en crear un elemento intermedio que asuma parte de las capacidades hardware y software del TPV y un conjunto de transacciones predeterminadas. Esto no permite realmente un control completo desde el servidor de las aplicaciones que se ejecutan en el TPV. Además, la interacción frecuente con el servidor puede no ser asumible en escenarios en los que las comunicaciones planteen problemas, bien por las prestaciones (tiempos de respuesta) de los dispositivos, bien por el coste de las mismas.

Por su parte, una de las mencionadas propuestas ya existentes lleva aparejada una fuerte restricción de que los TPV sean capaces de interpretar su lenguaje de marcas, lo que implica una importante capacidad de cálculo que supone una limitación para TPV básicos.

BREVE DESCRIPCIÓN DE LA INVENCIÓN La ¡dea fundamental de la presente invención es trasladar la lógica de las aplicaciones que corren en un terminal de servicio o TPV para que sean controladas por un servidor de forma completa. Para ello, el modelo se basa en STIP, en donde cada elemento del terminal de servicio o TPV lleva asociado un módulo que lo controla y es capaz de generar los eventos correspondientes a cada cambio de estado.

El modelo de funcionamiento es que cada evento generado por un elemento del terminal de servicio o TPV, junto con toda la información asociada al evento, son enviados al servidor para que determine la siguiente acción a realizar. Por tanto, la respuesta del servidor contendrá la información para que los módulos de control de cada elemento del terminal de servicio o TPV modifiquen su estado según sea necesario.

Con este modelo de funcionamiento, el control completo de la ejecución se realiza en el servidor, encargándose el terminal de servicio o TPV exclusivamente de capturar los eventos que en él se producen, transmitirlos al servidor y modificar su estado en base a la respuesta producida. De esta forma se superan totalmente las limitaciones de las soluciones actuales.

En un primer aspecto de la presente invención, se proporciona un método para gestionar una operación en un terminal de servicio a través de un servidor remoto, donde dicho terminal de servicio comprende una pluralidad de módulos, y una interfaz de comunicaciones configurada para comunicarse con dicho servidor remoto, donde dicho servidor remoto comprende una pluralidad de aplicaciones y una interfaz de comunicaciones. El método comprende las etapas de: -generar un evento como respuesta a una interacción de un usuario con uno de dichos módulos del terminal de servicio; -asociar a dicho evento una información; -enviar dicha información al servidor remoto a través de dicha interfaz de comunicaciones; -procesar dicha información recibida en el servidor remoto y ejecutar una aplicación que obtiene una respuesta a la información asociada a dicho evento; -enviar dicha respuesta al terminal de servicio a través de la interfaz de comunicaciones; -procesar dicha respuesta e identificar el módulo del terminal de servicio afectado por la misma; -e interactuar con dicho módulo realizando una operación en el terminal de servicio.

Preferentemente, la información asociada a un evento comprende: un identificador del terminal de servicio, un identificador del módulo que ha generado dicho evento y un identificador de operación que representa el evento particular generado por dicho módulo.

Dicha información asociada a un evento comprende además una pluralidad de parámetros que representan datos adicionales de información de dicho evento.

La respuesta obtenida tras la ejecución de una aplicación en el servidor remoto comprende la siguiente información: un identificador del módulo sobre el que se actúa y un identificador de la operación que se quiere realizar sobre dicho módulo.

Dicha respuesta obtenida tras la ejecución de una aplicación en el servidor remoto comprende además una pluralidad de parámetros que representan datos adicionales de información de la operación que se quiere realizar.

Las interfaces de comunicaciones entre dicho terminal de servicio y dicho servidor remoto se pueden establecer con cualquier tecnología inalámbrica o cableada.

En una realización preferente, cada una de las aplicaciones comprendidas en dicho servidor remoto, se basa en un conjunto de estados y transiciones entre dichos estados, en función de los cuales se determina un nuevo estado y un evento que se envía como dicha respuesta al evento generado en el terminal de servicio. Y cada uno de los módulos comprendidos en dicho terminal de servicio es un módulo periférico que comprende un módulo de control.

En otro aspecto de la invención se proporciona un sistema que comprende una pluralidad de terminales de servicio y un servidor remoto, donde la gestión de las operaciones entre cada terminal de servicio se lleva a cabo mediante el método descrito previamente.

Finalmente se proporciona un programa informático que comprende medios de código de programa informático adaptados para realizar las etapas del método descrito anteriormente, cuando dicho programa se ejecuta en un ordenador, un procesador de señal digital, una disposición de puertas de campo programable, un circuito integrado de aplicación específica, un microprocesador, un microcontrolador, y cualquier otra forma de hardware programable.

BREVE DESCRIPCION DE LOS DIBUJOS A continuación se pasa a describir de manera muy breve una serie de dibujos que ayudan a comprender mejor la invención, presentados como ejemplos ilustrativos y no limitativos de ésta.

La figura 1 ilustra un esquema de la arquitectura de un TPV con tecnología STIP.

La figura 2 ilustra un esquema de la arquitectura de un terminal punto de venta y un servidor remoto de acuerdo con una realización de la presente invención.

DESCRIPCIÓN DETALLADA DE LA INVENCIÓN La figura 2 ilustra un esquema de la arquitectura de una implementación de la invención. En concreto, en la figura 2 se representa un terminal de servicio o terminal punto de venta 21 y un servidor remoto 22.

De acuerdo con la Plataforma de Interoperabilidad de Terminales Pequeños (Small Terminal Interoperability Platform, STIP), es posible la representación de un terminal de servicio o terminal punto de venta (TPV) 21 como un conjunto de módulos 23, cada uno de ellos con un elemento de control y un elemento de gestión de los eventos. Ejemplos no limitativos de módulos 23 que pueden incluirse en un TPV 21 son: lector de tarjetas sin contacto, diodos emisores de luz, lectores de cinta magnética, ranuras para lectura de tarjeta inteligente (del inglés, Smart Card Slot), teclado, impresora, interfaces de usuario, beeper, tarjeta de transporte, verificación de poseedor de tarjeta (del inglés, Card Holder Verification), comunicaciones, criptografía, fecha, fuente de alimentación, temporizador, fichero, Http, servidor de http y XML.

Como puede observarse, el terminal de servicio o terminal punto de venta 21 comprende también una interfaz de comunicaciones 24 configurada para comunicarse con el servidor remoto 22, es decir, para gestionar las comunicaciones con el mismo. La figura 2 muestra también un elemento de control 25, para interaccionar y controlar los módulos 23 del TPV 21 , y un elemento 26 para capturar los eventos que generan los módulos. Estos dos elementos 25 26 se asocian a cada uno de los módulos 23.

Por su parte, el servidor 22 alberga un elemento o interfaz 27 para gestionar las comunicaciones con el terminal de servicio o TPV 21. Además, el servidor 22 comprende la lógica 28 de todas las aplicaciones 29 que se quieran ejecutar en él. El servidor 22, por tanto, alberga distintas aplicaciones 29, en donde cada una de ellas implementa su propio algoritmo, permitiendo total flexibilidad.

Cuando una aplicación 29 recibe un nuevo evento, determina qué evento de respuesta debe de generar. Para ello se basa en una serie de estados y transiciones: cada aplicación 29 crea los estados que considera necesarios y las transiciones entre estos estados. En función del estado de la aplicación 29 y del evento recibido, se determina el nuevo estado y el evento que se envía al terminal de servicio o TPV 21.

Por tanto, para cada terminal de servicio o TPV 21 se crean en el servidor 22 instancias de una aplicación 29, de cara a almacenar el estado de la misma; es decir, además del algoritmo que define el funcionamiento de una aplicación 29, con sus estados posibles y transiciones, se controla el estado de una aplicación 29 para un terminal de servicio o TPV 21 en particular.

De esta forma, el método de gestión de una operación en el terminal de servicio o terminal punto de venta 21 propuesto comprende los siguientes pasos: En primer lugar, cuando sucede algún tipo de interacción por parte de un usuario con alguno de los módulos 23 que componen el terminal de servicio o TPV 21 , se genera un evento que es capturado por el elemento de gestión de los eventos 26. Por ejemplo, si se pulsa una tecla o si se pasa una tarjeta por el lector de tarjetas.

A continuación, el elemento de gestión de los eventos 26 caracteriza el evento, asociándole cierta información. Preferentemente, esta información comprende un identificador del módulo 23 o periférico del TPV 21 del que proviene, un identificador del terminal (TPV) 21 para poder discriminar el TPV 21 que está invocando y un identificador de operación que representa el evento particular generado por el módulo 23(cada módulo 23 o periférico puede generar distintos tipos de eventos). Si es necesario, comprende también parámetros o datos adicionales correspondientes al evento capturado, particulares del mismo. Por ejemplo, los datos leídos de la tarjeta.

Después, haciendo uso del elemento o interfaz de comunicaciones 24, esa información es enviada al servidor remoto 22. Para establecer esta comunicación, puede usarse cualquier tecnología cableada o inalámbrica.

A continuación, el elemento o interfaz de comunicaciones 27 del servidor 22 procesa la información recibida y, en base al TPV 21 origen de la petición, recupera la aplicación 29 correspondiente que se ejecuta en dicho terminal de servicio o TPV 21 ; esta aplicación 21 , que contiene una lógica de aplicación particular 28, recibe la información del evento generado en el TPV 21 y de acuerdo con el identificador del módulo 23, los datos adicionales si los hubiera y el estado de la aplicación 29, obtiene una respuesta a la información asociada al evento, determinando cuál es el siguiente paso que debe realizarse en el TPV 21. Este paso es definido en términos de una operación a realizar sobre alguno de los módulos 23 del TPV 21.

Haciendo uso de los elementos o interfaces de comunicaciones 27 24, esta respuesta es enviada desde el servidor 22 al TPV 21. Preferentemente, esta información comprende: un identificador del módulo 23, que representa el periférico sobre el que se quiere actuar; una operación, que representa la operación particular que se quiere realizar sobre el periférico, desde el elemento de control (sobre cada periférico se pueden generar distintos tipos de operaciones) y, si es necesario, parámetros de la operación, que representa los datos adicionales particulares de la operación a realizar.

En el TPV 21 se procesa esta información y se identifica el módulo 23 afectado por la operación a ejecutar, así como los posibles parámetros que influyen en la misma.

Por último, el elemento de control 25 se encarga de interactuar con el módulo 23, desencadenando la operación que se ha determinado en el servidor 22.

Este método permite que, haciendo uso recurrentemente de estos pasos, cualquier aplicación 29 pueda ser definida con control absoluto de su comportamiento desde el servidor 22.

En suma, se propone una arquitectura y un procedimiento que permiten total flexibilidad en la definición de aplicaciones que sean ejecutadas en un TPV 21 , evitando el problema de tener que hacer modificaciones en el software del TPV 21.

La arquitectura propuesta es totalmente genérica, apoyada en la generación de eventos y elementos de control sobre los periféricos, lo que permite la incorporación a medida de los periféricos que sean precisos para cada escenario.

Además, al ser procesado cada evento de cada periférico en el servidor 22, se permite un control absoluto de la operativa que se desee ejecutar en el TPV 21. Es de destacar que con esto se consigue una personalización total para cada TPV 21 : se puede pensar en que cada TPV 21 o grupos de TPVs pueden tener una configuración particular disponiendo de operaciones diferenciadas a otros TPVs 21 /grupos de TPVs. La flexibilidad es total.

Otra ventaja, consecuencia de tener el control de la aplicación 29 en el servidor 22, es que éstas se pueden conectar a sistemas externos para recuperar valores o realizar transacciones que desde el propio TPV 21 sería complicado que pudieran realizarse, lo que es de especial interés en aplicaciones financieras y, en general, para plataformas comerciales.

Claims (10)

REIVINDICACIONES

1. Un método para gestionar una operación en un terminal de servicio (21 ) a través de un servidor remoto (22), donde dicho terminal de servicio (21 ) comprende una pluralidad de módulos (23), y una interfaz de comunicaciones (24) configurada para comunicarse con dicho servidor remoto (22), donde dicho servidor remoto (22) comprende una pluralidad de aplicaciones (29) y una interfaz de comunicaciones (27), dicho método caracterizado porque comprende las las etapas de: -generar un evento como respuesta a una interacción de un usuario con uno de dichos módulos (23) del terminal de servicio (21); -asociar a dicho evento una información; -enviar dicha información al servidor remoto (22) a través de dicha interfaz de comunicaciones (24); -procesar dicha información recibida en el servidor remoto (22) y ejecutar una aplicación (29) que obtiene una respuesta a la información asociada a dicho evento; -enviar dicha respuesta al terminal de servicio (21) a través de la interfaz de comunicaciones (27); -procesar dicha respuesta e identificar el módulo (23) del terminal de servicio (21) afectado por la misma; e -interactuar con dicho módulo (23) realizando una operación en el terminal de servicio (21 ).

2. El método de conformidad con la reivindicación 1 , caracterizado porque dicha información asociada a un evento comprende: un identificador del terminal de servicio (21 ), un identificador del módulo (23) que ha generado dicho evento y un identificador de operación que representa el evento particular generado por dicho módulo (23).

3. El método de conformidad con la reivindicación 2, caracterizado porque dicha información asociada a un evento comprende además una pluralidad de parámetros que representan datos adicionales de información de dicho evento.

4. El método de conformidad con cualquiera de las reivindicaciones anteriores, caracterizado porque dicha respuesta obtenida tras la ejecución de una aplicación (29) en dicho servidor remoto (22) comprende la siguiente información: un identificador del módulo (23) sobre el que se actúa y un identificador de la operación que se quiere realizar sobre dicho módulo (23).

5. El método de conformidad con la reivindicación 4, caracterizado porque dicha respuesta obtenida tras la ejecución de una aplicación (29) en dicho servidor remoto (22) comprende además una pluralidad de parámetros que representan datos adicionales de información de dicha operación que se quiere realizar.

6. El método de conformidad con cualquiera de las reivindicaciones anteriores, caracterizado porque dichas interfaces de comunicaciones (24) (27) entre dicho terminal de servicio (21) y dicho servidor remoto (22) se establecen con cualquier tecnología inalámbrica o cableada.

7. El método de conformidad con cualquiera de las reivindicaciones anteriores, caracterizado porque cada una de dicha pluralidad de aplicaciones (29) comprendidas en dicho servidor remoto (22), se basa en un conjunto de estados y transiciones entre dichos estados, en función de los cuales se determina un nuevo estado y un evento que se envía como dicha respuesta al evento generado en el terminal de servicio (21).

8. El método de conformidad con cualquiera de las reivindicaciones anteriores, caracterizado porque cada uno de dichos módulos (23) comprendidos en dicho terminal de servicio (21) es un módulo periférico que comprende un módulo de control (25).

9. Un sistema que comprende una pluralidad de terminales de servicio (21) y un servidor remoto (22), donde la gestión de las operaciones entre cada terminal de servicio (21 ) se lleva a cabo mediante el método como el que se reclama en cualquiera de las reivindicaciones anteriores.

10. Un programa informático que comprende medios de código de programa informático adaptados para realizar las etapas del método como el que se reclama en cualquiera de las reivindicaciones 1 a 8, cuando dicho programa se ejecuta en un ordenador, un procesador de señal digital, una disposición de puertas de campo programable, un circuito integrado de aplicación específica, un microprocesador, un microcontrolador, y cualquier otra forma de hardware programable.