ES2895493T3 - Copia de seguridad de datos de histórico en un dispositivo destinado a procesar transacciones - Google Patents

Copia de seguridad de datos de histórico en un dispositivo destinado a procesar transacciones Download PDF

Info

Publication number
ES2895493T3
ES2895493T3 ES18215118T ES18215118T ES2895493T3 ES 2895493 T3 ES2895493 T3 ES 2895493T3 ES 18215118 T ES18215118 T ES 18215118T ES 18215118 T ES18215118 T ES 18215118T ES 2895493 T3 ES2895493 T3 ES 2895493T3
Authority
ES
Spain
Prior art keywords
data
historization
transaction
file
recording
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
ES18215118T
Other languages
English (en)
Inventor
Pierre Vaures
Antoine Vilain
Benoit Mouroux
Francis Chamberot
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Idemia France SAS
Original Assignee
Idemia France SAS
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Idemia France SAS filed Critical Idemia France SAS
Application granted granted Critical
Publication of ES2895493T3 publication Critical patent/ES2895493T3/es
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00Payment architectures, schemes or protocols
    • G06Q20/38Payment protocols; Details thereof
    • G06Q20/389Keeping log of transactions for guaranteeing non-repudiation of a transaction
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00Payment architectures, schemes or protocols
    • G06Q20/30Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/34Payment architectures, schemes or protocols characterised by the use of specific devices or networks using cards, e.g. integrated circuit [IC] cards or magnetic cards
    • G06Q20/341Active cards, i.e. cards including their own processing means, e.g. including an IC or chip
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00Payment architectures, schemes or protocols
    • G06Q20/38Payment protocols; Details thereof
    • G06Q20/40Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check credit lines or negative lists
    • G06Q20/405Establishing or using transaction specific rules

Landscapes

  • Business, Economics & Management (AREA)
  • Accounting & Taxation (AREA)
  • Engineering & Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • Theoretical Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • General Business, Economics & Management (AREA)
  • Strategic Management (AREA)
  • Finance (AREA)
  • Computer Security & Cryptography (AREA)
  • Economics (AREA)
  • Development Economics (AREA)
  • Microelectronics & Electronic Packaging (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)

Abstract

Procedimiento de procesamiento puesto en práctica por un dispositivo electrónico (2) adecuado para procesar transacciones, comprendiendo dicho procedimiento: - recepción de datos de transacción (DN) procedentes de un terminal (T) con el que actúa conjuntamente el dispositivo electrónico para procesar una transacción actual (TR1); - obtención, a partir de los datos de transacción recibidos, de nuevos datos de historización representativos de la transacción actual; y - grabación de los nuevos datos de historización, según un primer formato de datos (FT1), como nueva entrada (RC) en un primer archivo de historización (LG1); y caracterizado por que, previamente a dicha grabación, el procedimiento comprende: - verificación de que dicha grabación cumple al menos una condición predeterminada que indica que dicha grabación es crítica respecto a datos de historización antiguos almacenados como entrada anterior (RC) según el primer formato de datos en el primer archivo de historización (LG1), siendo dicha grabación crítica si corre el riesgo de provocar la pérdida de dichos datos de historización antiguos en el primer archivo de historización; y - en caso afirmativo, transferencia de los datos de historización antiguos a un segundo archivo de historización (LG2) para hacer una copia de seguridad de los mismos, según un segundo formato de datos (FT2), de tamaño reducido con respecto al primer formato de datos (FT1).

Description

DESCRIPCIÓN
Copia de seguridad de datos de histórico en un dispositivo destinado a procesar transacciones
Antecedentes de la invención
La presente invención se encuentra en el campo general de los dispositivos electrónicos y se refiere, más particularmente, a un dispositivo electrónico, tal como una tarjeta inteligente, por ejemplo, configurada para actuar conjuntamente con un terminal externo para realizar una transacción, por ejemplo, en el campo bancario.
La invención se aplica, más particularmente, pero de manera no exclusiva, a las tarjetas inteligentes (o tarjetas de microcircuito), por ejemplo, de acuerdo con la norma ISO7816. La invención se dirige, concretamente, a la protección de una tarjeta inteligente que funciona según el protocolo EMV (por “ Europay MasterCard Visa").
De manera general, una tarjeta inteligente está diseñada para comunicarse con un dispositivo externo a esta tarjeta, también denominado terminal o lector. Estas tarjetas permiten efectuar diversos tipos de transacciones, tales como, por ejemplo, transacciones de pago, de cargo o incluso de autenticación del portador. Las tarjetas inteligentes para aplicaciones bancarias (tarjeta de crédito, tarjeta de débito, etc.), por ejemplo, son adecuadas para actuar conjuntamente con terminales de pago o cajeros automáticos (por sus siglas en francés, DAB) para realizar diversas operaciones financieras.
EMV es el protocolo normalizado usado mayoritariamente en la actualidad en el mundo para proteger, concretamente, las transacciones de pago efectuadas con tarjetas inteligentes.
El protocolo EMV se ha diseñado para disminuir los riesgos de fraudes durante una transacción de pago, permitiendo, concretamente, la autenticación tanto de la tarjeta inteligente como de su portador. Este proceso de autenticación recurre a una combinación de criptogramas (o claves cifradas) y firmas digitales, y, eventualmente, requiere la introducción de un código secreto (denominado, habitualmente, código PIN) por parte del portador de la tarjeta.
A lo largo de una transacción, una tarjeta bancaria obtiene un determinado número de datos representativos de esta transacción, como, por ejemplo, la fecha de la transacción, la divisa usada, el importe de la transacción o incluso los controles de seguridad realizados por la tarjeta, así como los resultados obtenidos. De manera conocida, pueden grabarse datos, denominados datos de historización, representativos de una transacción, en una memoria de la tarjeta bancaria, con el fin de conservar un histórico de las transacciones realizadas. Los tipos de datos de historización que conserva una tarjeta bancaria en memoria en cada transacción están definidos por determinadas normas (VISA o MASTERCARD, por ejemplo).
El documento WO2017/203146 A1 (Oberthur Tech. [FR]) describe un mecanismo de seguridad que permite proteger una tarjeta inteligente de EMV contra comportamientos anómalos que se produzcan, concretamente, durante transacciones fuera de línea. Para ello, se prevé que la tarjeta inteligente seleccione en un archivo de historización de las transacciones antiguas realizadas en una ventana temporal, después analice un riesgo de uso anómalo a partir de los datos de historización grabados en el archivo de historización para las transacciones seleccionadas.
No obstante, se plantea un problema porque los recursos en memoria de los dispositivos electrónicos, tales como las tarjetas inteligentes, son limitados. Además, cuando la memoria del histórico está llena, la tarjeta bancaria destruye, generalmente, los datos de historización de la transacción más antigua con los nuevos datos de historización de la transacción actual. Se trata de un sistema de grabación cíclico. Este sistema permite usar la memoria conservando el mayor tiempo posible los datos de historización de una transacción dada.
Ahora bien, la grabación cíclica presenta el inconveniente de que, algunas veces, los datos que se destruyen siguen siendo pertinentes: pueden ser útiles para la tarjeta bancaria o el emisor de la tarjeta, por ejemplo. Si se suprimen datos de historización en la memoria antes de que la tarjeta haya podido transmitirlos, durante una transacción, por ejemplo, el emisor de la tarjeta no podrá recuperarlos. No obstante, los datos de historización son muy útiles, concretamente, para el seguimiento de las transacciones, la detección de fraudes, el seguimiento de comportamiento de los usuarios, etc. En determinados casos, estos datos de historización son necesarios para que la tarjeta bancaria realice controles de seguridad internos, durante el procesamiento de una transacción, por ejemplo.
Por tanto, en la actualidad existe una necesidad de una solución que permita una mejor gestión de la grabación del histórico de transacciones en una tarjeta inteligente (tarjeta bancaria, tarjeta de pago, ...), y, de manera más general, un dispositivo electrónico destinado a actuar conjuntamente con un terminal externo para realizar cualquier transacción.
Objeto y resumen de la invención
Para ello, la presente invención se refiere a un procedimiento de procesamiento puesto en práctica por un dispositivo electrónico adecuado para procesar transacciones según la reivindicación 1.
La presente invención permite optimizar el uso de la memoria del dispositivo electrónico para almacenar datos de histórico propios de las transacciones procesadas por dicho dispositivo. Como ya se ha indicado, los recursos en la memoria de una tarjeta inteligente son limitados. El dispositivo electrónico según la invención puede transferir, si es necesario, determinados datos de histórico que se consideran pertinentes, desde un primer archivo de historización hacia un segundo archivo de historización, de manera que se realiza una copia de seguridad en forma comprimida de datos de historización.
Según un modo de realización particular, el segundo formato de datos está reducido por que permite la grabación de una cantidad inferior de datos con respecto al primer formato de datos.
Según un modo de realización particular, el primer formato de datos define una pluralidad de tipos de datos que van a grabarse, mientras que el segundo formato de datos define una selección de entre dicha pluralidad de tipos de datos excluyendo al menos uno de entre dicha pluralidad de tipos de datos.
Según un modo de realización particular, dicha verificación comprende:
- determinación de que la grabación de los nuevos datos de historización, según el primer formato de datos en el primer archivo de historización, conduce a una destrucción de una entrada anterior, representativa de una transacción anterior, ya grabada en el primer archivo de historización según el primer formato de datos; y
- detección de que la grabación es crítica si la transacción anterior, definida por la entrada anterior en el primer archivo de historización, cumple una primera condición temporal.
Según un modo de realización particular, la primera condición temporal se cumple si un instante previo a lo largo del cual se ha realizado la transacción anterior, según dicha entrada anterior, se encuentra en un periodo de tiempo, de una duración predefinida, que termina en un instante actual a lo largo del cual se realiza o se ha realizado la transacción actual.
Según un modo de realización particular, dicha verificación comprende:
- determinación, a partir de los datos de transacción recibidos, del instante actual que caracteriza a la transacción actual; y
- cálculo de un segundo instante previo correspondiente al inicio del periodo de tiempo, a partir del instante actual y de la duración predefinida atribuida a dicho periodo de tiempo,
encontrándose el primer instante previo en el periodo de tiempo si es posterior al segundo instante previo.
Según un modo de realización particular, el procedimiento de procesamiento comprende, previamente a dicha grabación de los nuevos datos de historización según el primer formato de datos en el segundo archivo de historización:
- selección, de entre tipos de datos de historización definidos por el primer formato de datos, de un subconjunto de tipos de datos de historización de conformidad con al menos una regla de selección predefinida; y
- conversión de los datos de historización antiguos, según el segundo formato de datos, con vistas a transferirse al segundo archivo de historización, en la que solamente el o los tipos de datos de historización seleccionados se conservan en los datos de historización antiguos durante dicha conversión.
Según un modo de realización particular, previamente a dicha selección, el segundo archivo de historización ya comprende al menos una entrada de la que se ha hecho una copia de seguridad según el segundo formato de datos, siendo dicha entrada, de la que se ha hecho una copia de seguridad, representativa de una transacción anterior previa a la transacción actual. Durante dicha selección, el dispositivo electrónico selecciona un primer tipo de datos de historización predefinido solamente si la entrada más reciente de la que se ha hecho una copia de seguridad en el segundo archivo de historización que incluye el primer tipo de dato de historización especifica, para dicho primer tipo de datos de historización, un valor diferente del definido por dicha entrada anterior
Según un modo de realización particular, durante dicha verificación, el dispositivo electrónico detecta sistemáticamente que la grabación no es crítica si la transacción actual es una transacción sin contacto.
Según un modo de realización particular, si la transacción actual es una transacción por contacto con el terminal, el dispositivo electrónico detecta sistemáticamente durante dicha verificación que la grabación es crítica si se cumple la siguiente condición:
detección de que dicha grabación de los nuevos datos de historización, según el primer formato de datos en el primer archivo de historización, conduce a que el primer archivo de historización contenga un número, superior o igual a un valor umbral predeterminado, de entradas de transacciones que satisfacen una segunda condición temporal.
Según un ejemplo particular, la segunda condición temporal es idéntica a la primera condición temporal definida anteriormente.
Según un modo de realización particular, si se detecta durante dicha verificación que dicha grabación no es crítica, el dispositivo electrónico no transfiere los datos de historización antiguos al segundo archivo de historización según el segundo formato de datos previamente a dicha grabación.
Según un modo de realización particular, el dispositivo electrónico detecta durante dicha verificación que dicha grabación es crítica únicamente con la detección de que la transacción actual pasa satisfactoriamente.
Según un modo de realización particular, el procedimiento de procesamiento comprende, después de dicha transferencia de los datos de historización antiguos según el segundo formato de datos en el segundo archivo de historización:
- conversión de los datos de historización antiguos desde el segundo formato de datos a un formato modificado a partir del contenido de una entrada anterior en el segundo archivo de historización; y - transmisión de los datos de historización antiguos en el formato modificado de datos a un terminal.
En un modo particular de realización, las diferentes etapas del procedimiento de procesamiento se determinan mediante instrucciones de programas de ordenadores.
Por consiguiente, la invención también se dirige a un programa de ordenador en un soporte de información (o soporte de grabación), siendo este programa susceptible de ponerse en práctica en un dispositivo electrónico o en un ordenador, incluyendo este programa instrucciones adaptadas para la puesta en práctica de las etapas de un procedimiento de procesamiento, tal como se define en este documento.
Este programa puede utilizar cualquier lenguaje de programación y presentarse en forma de código fuente, código objeto o de código intermedio entre código fuente y código objeto, tal como en una forma parcialmente compilada, o en cualquier otra forma deseable.
La invención también se dirige a un soporte de información (o soporte de grabación) legible por un ordenador y que incluye instrucciones de un programa de ordenador, tal como se mencionó anteriormente.
El soporte de información puede ser cualquier entidad o dispositivo que pueda almacenar el programa. Por ejemplo, el soporte puede incluir un medio de almacenamiento, tal como una ROM, por ejemplo, un CD ROM o una ROM de circuito microelectrónico o incluso un medio de grabación magnético, por ejemplo, un disquete (floppy disc) o un disco duro. Por otra parte, el soporte de información puede ser un soporte transmisible, tal como una señal eléctrica u óptica, que pueda dirigirse a través de un cable eléctrico u óptico, por radio o mediante otros medios. En particular, el programa según la invención puede descargarse en una red de tipo Internet.
Como alternativa, el soporte de información puede ser un circuito integrado en el que está incorporado el programa, estando el circuito adaptado para ejecutar o para usarse en la ejecución del procedimiento en cuestión. La invención se refiere, igualmente, a un dispositivo electrónico configurado para poner en práctica el procedimiento de procesamiento de la invención, tal como se definió anteriormente.
Más particularmente, la invención se dirige a un dispositivo electrónico adecuado para procesar transacciones según la reivindicación 15.
Según un ejemplo particular, el dispositivo electrónico es una tarjeta inteligente, por ejemplo, de tipo EMV (tarjeta de pago u otra).
Se observará que los diferentes modos de realización mencionados anteriormente en relación con el procedimiento de procesamiento de la invención, así como las ventajas asociadas, se aplican de manera análoga al dispositivo electrónico de la invención.
Según un modo de realización, la invención se pone en práctica por medio de componentes de software y/o de hardware. En este sentido, el término “ módulo” puede corresponder en este documento tanto a un componente de software como a un componente de hardware o a un conjunto de componentes de hardware y de software.
Un componente de software corresponde a uno o varios programas de ordenador, uno o varios subprogramas de un programa o, de manera más general, a cualquier elemento de un programa o de un software adaptado para poner en práctica una función o un conjunto de funciones, según lo que se describe, a continuación, para el módulo en cuestión. Un componente de software de este tipo puede ejecutarse por un procesador de datos de una entidad física (terminal, tarjeta inteligente, etc.) y es susceptible de acceder a los recursos de hardware de esta entidad física (memorias, soportes de grabación, bus de comunicación, tarjetas electrónicas de entradas/salidas, interfaces de usuario, etc.).
De la misma manera, un componente de hardware corresponde a cualquier elemento de un conjunto material (o hardware) adecuado para poner en práctica una función o un conjunto de funciones, según lo que se describe, a continuación, para el módulo en cuestión. Puede tratarse de un componente de hardware programable o con un procesador integrado para la ejecución de software, por ejemplo, un circuito integrado.
Breve descripción de los dibujos
Otras características y ventajas de la presente invención se desprenderán de la descripción realizada a continuación con referencia a los dibujos adjuntos que ilustran ejemplos de realización de la misma desprovistos de cualquier carácter limitativo. En las figuras:
- la Figura 1 representa esquemáticamente un entorno que comprende un dispositivo electrónico adecuado para actuar conjuntamente con un terminal, según un modo de realización particular de la invención;
- las Figuras 2A y 2B representan esquemáticamente datos de historización de acuerdo, respectivamente, con un primer formato de datos y con un segundo formato de datos, según un modo de realización particular de la invención;
- la Figura 3 representa esquemáticamente módulos funcionales puestos en práctica por un dispositivo electrónico, según un modo de realización particular de la invención
- las Figuras 4A y 4B representan esquemáticamente datos de historización grabados, respectivamente, en un primer archivo de historización y en un segundo archivo de historización, según un modo de realización particular de la invención;
- la Figura 5 representa, en forma de un diagrama, las etapas de un procedimiento de procesamiento, según un modo de realización particular de la invención;
- la Figura 6 representa, en forma de un diagrama, las etapas de un procedimiento de procesamiento, según un modo de realización particular de la invención;
- las Figuras 7A y 7B representan esquemáticamente el procesamiento en el tiempo de transacciones mediante un dispositivo electrónico, según un modo de realización particular de la invención;
- la Figura 8 representa, en forma de un diagrama, las etapas de un procedimiento de procesamiento, según un modo de realización particular de la invención; y
- la Figura 9 representa, en forma de un diagrama, las etapas de un procedimiento de procesamiento, según un modo de realización particular de la invención.
Descripción detallada de varios modos de realización
Como se indicó anteriormente, la presente invención se refiere a los dispositivos electrónicos, tales como las tarjetas inteligentes, por ejemplo, configurados para actuar conjuntamente con un terminal externo para realizar una transacción, por ejemplo, en el campo bancario.
La invención propone un procedimiento de procesamiento que permite la gestión del almacenamiento de un histórico de transacciones en una tarjeta inteligente (de tipo EMV, por ejemplo) y, de manera más general, en un dispositivo electrónico, con el fin de optimizar el uso de los recursos de memoria del dispositivo electrónico y de manera que se limitan los riesgos de que se pierdan datos de histórico pertinentes. Para ello, la invención prevé la grabación mediante un dispositivo electrónico de nuevos datos de historización (o datos de histórico), representativos de una transacción actual, según un primer formato de datos en un primer archivo de historización. Además, si esta grabación corre el riesgo de provocar la pérdida de datos de historización antiguos ya presentes en este primer archivo de historización, la invención prevé la transferencia de estos datos de historización antiguos a un segundo archivo de historización, según un segundo formato de datos, de tamaño reducido con respecto al primer formato, con el fin de hacer una copia de seguridad de una versión comprimida de estos datos antiguos en la memoria del dispositivo electrónico.
Pueden aplicarse diversas condiciones predefinidas para determinar si debe activarse un mecanismo de copia de seguridad de este tipo por el dispositivo electrónico.
En particular, según diferentes modos de realización, el procedimiento de procesamiento de la invención, puesto en práctica por un dispositivo electrónico, tal como una tarjeta inteligente, por ejemplo, comprende: recepción de datos de transacción procedentes de un terminal; obtención, a partir de los datos de transacción recibidos, de nuevos datos de historización representativos de una transacción actual; y grabación de los nuevos datos de historización según un primer formato de datos en un primer archivo de historización. Además, previamente a dicha grabación, el procedimiento comprende: verificación de que dicha grabación cumple al menos una condición predeterminada que indica que dicha grabación es crítica respecto a datos de historización antiguos ya almacenados en el primer archivo de historización; y, en caso afirmativo, transferencia (o copia de seguridad) de los datos de historización antiguos en un segundo archivo de historización, según un segundo formato de datos, comprimido o de tamaño reducido con respecto al primer formato de datos.
La invención trata, igualmente, sobre un dispositivo electrónico configurado para poner en práctica un procedimiento de procesamiento, como se definió anteriormente.
En la presente descripción, se describen ejemplos de puesta en práctica de la invención en relación con una tarjeta inteligente de tipo EMV. Se comprenderá que la invención no se limita exclusivamente a las tarjetas inteligentes de EMV, sino que se aplica, de manera más general, a cualesquiera dispositivos electrónicos configurados para poner en práctica una transacción, incluidos dispositivos distintos de las tarjetas inteligentes y que usan la norma EMV y dispositivos electrónicos que usan otras normas de transacción.
Igualmente, puede indicarse que, en el presente documento, la noción de transacción se entiende en el sentido amplio y comprende, por ejemplo, en el campo bancario, tanto una transacción de pago o de transferencia, como una transacción de consulta de una cuenta bancaria en un terminal bancario. Los diversos modos de realización de la invención se describen en el presente documento en el contexto de una tarjeta de pago destinada a realizar transacciones bancarias. Se comprende que pueden preverse otros tipos de transacciones u operaciones en el contexto de la invención. La invención puede aplicarse, por ejemplo, al almacenamiento de datos de historización representativos de transacciones de autenticación.
Salvo que se indique lo contrario, los elementos comunes o análogos a varias figuras llevan los mismos símbolos de referencia y presentan características idénticas o análogas, de manera que generalmente estos elementos comunes o análogos no se describen de nuevo por motivos de simplicidad.
La Figura 1 representa esquemáticamente un entorno que incluye un dispositivo electrónico 2 de un usuario UR1 y un terminal (o lector) T de un usuario UR2. El dispositivo electrónico 2 está configurado para actuar conjuntamente con el terminal T para procesar una transacción TR1, denominada transacción actual.
Como ya se indicó, en el presente documento se supone que el dispositivo electrónico 2 es una tarjeta inteligente de EMV, tal como una tarjeta de pago, por ejemplo. La tarjeta bancaria 2 es, por ejemplo, de acuerdo con la norma ISO 7816. En un ejemplo particular, el portador UR1 usa su tarjeta bancaria para realizar un pago con la ayuda del terminal T de un punto de venta (o comerciante) indicado con UR2.
El terminal T permite, dado el caso, hacer la interfaz entre la tarjeta bancaria 2 y un servidor remoto SV de una entidad de terceros IS (por ejemplo, un organismo bancario emisor de la tarjeta inteligente 2). Este servidor remoto SV interviene, eventualmente, para realizar controles de seguridad complementarios durante un procesamiento en línea de la transacción actual TR1.
Conviene indicar que determinados elementos, generalmente presentes en una tarjeta inteligente de EMV, se han omitido voluntariamente, dado que no son necesarios para la comprensión de la presente invención. Igualmente, debe indicarse que la tarjeta inteligente 2 representada en la Figura 1 sólo constituye un ejemplo de realización, siendo posibles otras puestas en práctica en el contexto de la invención. El experto en la técnica comprende, en particular, que determinados elementos de la tarjeta inteligente 2 sólo se describen en este documento para facilitar la comprensión de la invención, no siendo estos elementos necesarios para poner en práctica la invención.
Más precisamente, la tarjeta inteligente 2 comprende, en este ejemplo, contactos externos 4 configurados para actuar conjuntamente con el lector T, un procesador 6, una memoria volátil regrabable 8 (de tipo RAM) y una memoria no volátil regrabable 10 (de tipo Flash, por ejemplo).
La memoria no volátil 10 constituye, en este ejemplo, un soporte de grabación (o soporte de información) de acuerdo con un modo de realización particular, legible por la tarjeta inteligente 2, y en el que está grabado un programa de ordenador PG1 de acuerdo con un modo de realización particular. Este programa de ordenador PG1 incluye instrucciones para la ejecución de las etapas de un procedimiento de procesamiento según un modo de realización particular. Las etapas de este procedimiento se describen posteriormente en modos de realización particulares de la invención.
En un ejemplo particular, la tarjeta inteligente 20 es de acuerdo con la norma ISO 7816. En este caso, los contactos externos 4 presentan características de acuerdo con esta norma. No obstante, se comprende que son posibles otros modos de realización sin usar contactos externos de este tipo. La tarjeta inteligente 2 puede estar configurada, por ejemplo, para actuar conjuntamente con el lector T en modo sin contacto a través de una antena RF (no representada) integrada en la tarjeta 2.
Todavía en el ejemplo considerado en el presente documento, la memoria no volátil regrabable 10 está configurada para almacenar datos de historización (o datos de histórico) DH representativos de transacciones procesadas por la tarjeta inteligente 2 a lo largo del tiempo. Para ello, la memoria 10 comprende dos archivos de historización, a saber, un primer archivo de historización (o archivo primario de historización) LG1 configurado para grabar datos de historización DH según un primer formato de datos FT1 y un segundo archivo de historización (o archivo secundario de historización) LG2 configurado para grabar datos de historización DH según un segundo formato de datos FT2, distinto del primer formato FT1. Como se explica a continuación, el segundo formato de datos FT2 tiene un tamaño reducido (comprimido) con respecto al primer formato de datos FT1. De este modo, el segundo formato FT2 sólo permite almacenar algunos de los datos de historización definidos por el primer formato de datos FT1.
Según un ejemplo de realización, los archivos de historización primero y segundo LG1, LG2 son (o corresponden a) zonas de memorias distintas.
Estos archivos de historización LG1 y LG2 (también denominados “ transaction Log file” en inglés) se describen en más detalle a continuación, haciendo referencia, concretamente, a las Figuras 4A-4B. Los datos de historización DH se graban en formas de entradas sucesivas en los archivos de historización primero y segundo LG1 y LG2, siendo cada entrada representativa de una transacción procesada por la tarjeta inteligente 2. Los datos de historización DH se almacenan en estos archivos LG1 y LG2, respectivamente, según formatos de datos diferentes FT1 y FT2, de manera que pueden consultarse posteriormente por la tarjeta inteligente 2 o transmitirse hacia un terminal externo, tal como el terminal T, por ejemplo.
Como se explica, a continuación, el segundo archivo de historización LG2 sirve de archivo de copia de seguridad para datos de historización DH transferidos, dado el caso, desde el primer archivo de historización LG1. Esta transferencia de copia de seguridad se activa por la tarjeta inteligente 2 cuando detecta que una grabación inminente de nuevos datos de historización DH representativos de una transacción actual es crítica, es decir, que esta grabación corre el riesgo de provocar la pérdida de datos de historización antiguos en el primer archivo de historización LG1. Esta transferencia constituye un mecanismo de copia de seguridad en el sentido de la invención.
Como se representa en la Figura 1, la memoria no volátil 10 puede almacenar, igualmente, al menos una condición predefinida CD que define si la grabación de datos de historización DH de una transacción actual TR1 en el primer archivo de historización LG1, según el primer formato FT1, es crítica o no.
La memoria no volátil 10 también puede almacenar al menos una regla predefinida RL que define el o los tipos de datos de historización de los que debe hacerse una copia de seguridad en el segundo archivo de historización LG2, de conformidad con el segundo formato FT2, cuando se transfieren datos de historización antiguos desde el primer archivo de historización LG1. Como se describe a continuación, la tarjeta inteligente 2 determina, a partir de la o de las reglas predefinidas RL, los datos de historización DH que deben transferirse de conformidad con el segundo formato FT2 al segundo archivo de historización LG2 y los que deben excluirse de esta transferencia de copia de seguridad.
La naturaleza de las condiciones CD y de las reglas RL, así como su uso, se describen posteriormente en más detalle.
Como ya se indicó, la tarjeta inteligente 2 está configurada para memorizar datos de historización DH según un primer formato de datos FT 1 en el primer archivo de historización LG1 y para hacer una copia de seguridad, si es necesario, de los datos de historización DH en el segundo archivo de historización LG2 según un segundo formato de datos FT2, estando este formato FT2 comprimido (o de tamaño reducido) con respecto al formato FT1. A continuación, se describen ejemplos de puesta en práctica de estos formatos FT1 y FT2.
Las Figuras 2A y 2B representan esquemáticamente datos de historización DH de acuerdo, respectivamente, con el primer formato de datos FT1 y con el segundo formato de datos FT2.
Como se ilustra, los datos de historización DH, según el primer formato FT1 (Figura 2A), incluyen diferentes tipos de datos indicados DH1 a DH6 que caracterizan a una misma transacción procesada por la tarjeta inteligente 2. Cada tipo de dato corresponde a una característica de la transacción en cuestión y presenta un valor particular. Estos tipos de datos DH1 a DH6 pueden comprender, por ejemplo, al menos uno de entre los siguientes tipos de datos:
- punto en el tiempo (es decir, fecha y/u hora) a lo largo del cual se ha procesado la transacción;
- la divisa de la transacción;
- el importe de la transacción;
- al menos un criptograma predefinido;
- controles de seguridad realizados por la tarjeta inteligente;
- los resultados de los controles de seguridad; y
- el resultado (o estado) de la transacción (aceptada, rechazada, ...).
Según un ejemplo particular, los tipos de datos previstos por el primer formato de datos FT1 están definidos por la norma aplicable V iSa o MASTERCARD.
Según un ejemplo particular, el primer formato de datos FT1 (o “ Log formar en inglés) es de acuerdo con la siguiente norma para un producto de CPA (por “ Common Payment Application” ):, “ e m v Integrated Circuit Card, Specifications for Payment Systems, Common Payment Application Specification” , Versión 1.0, diciembre de 2005.
No obstante, el experto en la técnica puede adaptar, concretamente, el número y la naturaleza de los tipos de datos incluidos en el formato FT1 según el caso específico.
De conformidad con la invención, el segundo formato de datos FT2 tiene un tamaño reducido con respecto al primer formato de datos FT1. Dicho de otro modo, el segundo formato FT2 es un formato comprimido con respecto al primer formato FT1. El segundo formato de datos FT2 está reducido (o comprimido), porque permite la grabación de una cantidad inferior de datos con respecto al primer formato de datos FT1. El tipo de compresión usado para pasar del primer formato FT1 al segundo formato FT2 puede adaptarse por el experto en la técnica según cada caso específico.
Como se ilustra en la Figura 2B , en los ejemplos descritos en el presente documento, los datos de historización DH según el segundo formato FT2 incluyen solamente algunos de entre los tipos de datos indicados DH1 a DH6 que caracterizan a una misma transacción procesada por la tarjeta inteligente 2. Cada tipo de dato corresponde a una característica de la transacción en cuestión y presenta un valor particular. En este ejemplo, los datos de historización DH según el segundo formato FT2 incluyen los tipos de datos DH1, DH2 y DH6, pero no contienen los tipos de datos DH3, DH4 y DH5 previstos por el primer formato FT1.
En este ejemplo, todos los tipos de datos DH1, DH2 y DH6 incluidos en el segundo formato FT2 están presentes, igualmente, en el primer formato FT1, aunque son posibles variantes. De manera general, el primer formato de datos FT1 define, por ejemplo, una pluralidad de tipos de datos (DH1-DH6, por ejemplo), mientras que el segundo formato de datos FT2 define una selección (DH1, DH2, DH6, por ejemplo) de entre dicha pluralidad de tipos de datos excluyendo al menos uno de entre dicha pluralidad de tipos de datos. No obstante, son posibles otros modos de realización.
El procesador 6 controlado por el programa de ordenador PG1, pone el presente documento en práctica un determinado número de módulos representados en la Figura 3 , a saber: un módulo de recepción MD2, un módulo de obtención MD4, un módulo de grabación MD6, un módulo de verificación MD8, un módulo de copia de seguridad MD10 y, eventualmente, también un módulo de conversión MD12 y un módulo de procesamiento MD14.
Como se ilustra en las Figuras 1-3, el módulo de recepción MD2 está configurado en este ejemplo para recibir datos de transacción DTR procedentes del terminal T con el que actúa conjuntamente la tarjeta inteligente 2 para procesar una transacción actual TR1. Estos datos de transacción DTR pueden comprender diversos tipos de datos (punto actual en el tiempo, importe de la transacción, divisa, ...) representativos de la transacción actual TR1.
El módulo de obtención MD4 está configurado para obtener, a partir de los datos de transacción DTR recibidos, nuevos datos de historización DH representativos de la transacción actual TR1. Estos datos de historización DH pueden comprender datos complementarios con respecto a los datos DTR proporcionados por el terminal T, tales como el tipo de controles de seguridad efectuados por la tarjeta inteligente 20 para verificar la validez de la transacción actual TR1 o incluso los resultados de estos controles de seguridad o el resultado final de la transacción (aceptada o rechazada). En un ejemplo particular, los datos de transacción DTR recibidos por el módulo de recepción MD2 y los datos de historización DH obtenidos por el módulo de obtención MD4 son idénticos.
El módulo de grabación MD6 está configurado para grabar los nuevos datos de historización DH, según el primer formato de datos FT1, en el primer archivo de historización LG1.
El módulo de verificación MD8 está configurado para verificar, previamente a la grabación por el módulo de grabación MD6 de los nuevos datos de historización D según el primer formato de datos FT1, en el primer archivo de historización LG1, que dicha grabación cumple al menos una condición predeterminada que indica que dicha grabación es crítica respecto a datos de historización antiguos DH almacenados como entrada anterior en el primer archivo de historización LG1.
El módulo de copia de seguridad MD10 está configurado, si se detecta que la grabación es crítica por el módulo de verificación MD8, para transferir (o hacer una copia de seguridad de) los datos de historización antiguos al segundo archivo de historización LG2 según el segundo formato de datos FT2, de tamaño reducido con respecto al primer formato de datos FT1. Para ello, el módulo de copia de seguridad MD10 comprime estos datos de historización antiguos según al menos una regla de selección predefinida RL.
Por otro lado, el módulo de conversión MD12 está configurado para interpretar, si es necesario, datos de historización DH de los que se ha hecho una copia de seguridad según el segundo formato de datos FT2 en el segundo archivo de historización LG2. Para ello, el módulo de conversión MD12 puede convertir datos de historización DH, de los que se ha hecho una copia de seguridad según el segundo formato FT2, en el segundo archivo de historización LG2 a una forma modificada más fácilmente aprovechable por una entidad de terceros, tal como el terminal T o el servidor remoto SV. Esta conversión puede realizarse a partir de dicha al menos una regla de selección predefinida RL usada previamente por el módulo de copia de seguridad MD10.
El módulo de transmisión MD14 puede estar configurado para transmitir datos de historización DH a un terminal externo, tal como el terminal T, por ejemplo. En particular, el módulo de transmisión MD12 puede transmitir datos de historización DH de acuerdo con el formato FT2 o, eventualmente, datos de este tipo previamente convertidos a una forma modificada por el módulo de conversión MD12.
La configuración y el funcionamiento de los módulos MD2-MD14 de la tarjeta inteligente 2 se presentan más precisamente en los ejemplos de realización descritos a continuación, haciendo referencia, concretamente, a las Figuras 4A-4B, 5-6, 7A-7B y 8-9. No obstante, se comprenderá que los módulos MD2-MD14, tales como se representan en la Figura 3, sólo representan un ejemplo de puesta en práctica no limitativo de la invención.
La actuación conjunta entre una tarjeta inteligente y un lector externo apropiado para realizar una transacción de tipo EMV se conoce en sí misma y, por tanto, no se desarrollará en detalle en la presente descripción por motivos de simplicidad.
En los modos de realización descritos, a continuación, se supone que el modo de grabación de las entradas en el primer archivo de historización LG1 (Figura 1) es cíclico. Dicho de otro modo, si el primer archivo de historización LG1 está lleno (contiene el número máximo de entradas grabables en LG1), entonces cada nueva entrada representativa de una transacción actual se graba en el archivo LG1 en lugar de la entrada más antigua en el archivo LG1, es decir, mediante destrucción de la entrada correspondiente a la transacción más antigua. Como ya se indicó, esta destrucción puede tener un carácter crítico si se considera que los datos de historización de este modo suprimidos siguen siendo pertinentes.
La Figura 4A representa el contenido del primer archivo de historización LG1, según un ejemplo particular. De conformidad con la invención, los datos de historización DH grabados en el primer archivo de historización LG1 son de acuerdo con el primer formato de datos FT1. En este ejemplo, el primer archivo de historización LG1 puede incluir datos de historización DH en forma de entradas distintas RC (también denominadas entradas de histórico), siendo cada una de ellas representativa de una transacción respectiva procesada por la tarjeta inteligente 2.
En el ejemplo considerado en el presente documento, el primer archivo de historización LG1 incluye las entradas de histórico RC1-RC10 representativas de transacciones previas a la transacción actual TR1, procesadas por la tarjeta inteligente 2. De conformidad con el primer formato FT1, las entradas RC1 a RC10 comprenden, cada una, los tipos de datos DH1 a DH6, como ya se describió anteriormente. En el presente documento, se supone que el primer archivo de historización LG1 puede contener un número máximo n1 de 10 entradas de datos de historización RC correspondientes a 10 transacciones respectivas, aunque evidentemente son posibles variantes.
Según un ejemplo particular, el primer archivo de historización LG1 es de acuerdo con la norma ISO/IEC 7816-4 (véase “ EMV 4.3 Book 3” , sección 4). La entrada RC1 es la entrada más reciente, la entrada RC2 es la segunda transacción más reciente, etc.
La Figura 4B representa el contenido del segundo archivo de historización LG2 según un ejemplo particular. De conformidad con la invención, los datos de historización DH, de los que se hace una copia de seguridad en el segundo archivo de historización LG2, son de acuerdo con el segundo formato de datos FT2. En este ejemplo, el segundo archivo de historización LG2 puede incluir datos de historización DH en forma de entradas distintas RD -indicadas en el presente documento RD1-RD20-, siendo cada una de ellas representativa de una transacción respectiva procesada por la tarjeta inteligente 2. Cada entrada RD (también denominada entrada de copia de seguridad) presente en el archivo LG2 corresponde en el presente documento a una entrada antigua RC que se ha transferido previamente por medida de copia de seguridad desde el primer archivo de historización LG1, de conformidad con la invención. En el presente documento, se supone que el segundo archivo de historización LG2 puede contener un número máximo n2 de 20 entradas de datos de historización RD correspondientes a 20 transacciones respectivas, aunque evidentemente son posibles variantes.
De conformidad con el segundo formato FT2, cada entrada RD de la que se hace una copia de seguridad en el segundo archivo de historización LG2, comprende una selección (o subconjunto) de entre los tipos de datos DH1 a DH6, de manera que se excluye al menos uno de entre los tipos DH1 a DH6. A título de ejemplo, las entradas RD1 y RD2 incluyen datos de historización DH de tipo DH1, DH2 y DH6, mientras que la entrada RD3 incluye únicamente datos de historización DH de tipo DH2 y DH6 (Figura 4B).
Por tanto, los datos de historización DH en el segundo formato FT2 constituyen una versión comprimida o aligerada con respecto a los datos de historización DH en el primer formato FT1. En este ejemplo, la compresión realizada para pasar del formato FT1 al formato FT2, implica una pérdida de datos, es decir, la exclusión de al menos un tipo de datos durante la copia de seguridad en el segundo archivo de historización LG2. No obstante, son posibles otros tipos de compresión.
La Figura 5 representa las etapas realizadas por la tarjeta inteligente 2 ilustrada en las Figuras 1-3 y 4A-4B durante un procedimiento de procesamiento, de acuerdo con un modo de realización particular de la invención. Más precisamente, la tarjeta inteligente 2 pone en práctica el procedimiento de procesamiento ejecutando el programa PG1, según un modo de realización particular de la invención.
Se supone que el procesamiento de una transacción TR1, denominada transacción actual, se inicia (S2) por la tarjeta inteligente 2 actuando conjuntamente con el terminal T. Como ya se indicó, en el presente documento se supone que esta transacción es de tipo EMV (una transacción de pago, por ejemplo).
A lo largo del procesamiento de esta transacción TR1, la tarjeta inteligente 2 recibe (S4) diversos datos de transacción DTR representativos de la transacción actual TR1, de conformidad con el protocolo EMV (fecha, divisa, importe de la transacción, ...).
A lo largo de una etapa de obtención S6, la tarjeta inteligente 2 obtiene, a partir de los datos de transacción recibidos DTR, nuevos datos de historización (o datos de histórico) DH que van a grabarse como nueva entrada en su memoria 10, siendo estos nuevos datos de historización DH representativos de la transacción actual TR1. Como ya se explicó, estos nuevos datos de historización pueden comprender la totalidad o partes de los datos de transacción recibidos DTR en S4 y, eventualmente, datos complementarios determinados por la tarjeta inteligente 2, realizando un procesamiento cualquiera apropiado a partir de los datos de transacción TR1. En un ejemplo particular, los datos de transacción recibidos DTR en S4 y los nuevos datos de historización obtenidos DH en S6 son idénticos.
En el presente documento, se supone que la tarjeta inteligente 2 obtiene en S6 todos los tipos de datos DH1 a DH6, tales como se describieron anteriormente haciendo referencia, concretamente, a la Figura 2A. Estos nuevos datos de historización DH comprenden, concretamente, el tipo de los controles de seguridad realizados por la tarjeta inteligente 2 durante el procesamiento de la transacción actual TR1 o incluso el estado (aceptado, rechazado) de esta transacción TR1.
Como se indica a continuación, la tarjeta inteligente 2 está a punto de grabar (etapa S12 inminente) los nuevos datos de historización obtenidos DH en S6 en el primer archivo de historización LG1 según el primer formato de datos FT1. No obstante, esta grabación S12 inminente puede ser crítica si provoca la pérdida de datos de historización antiguos DH ya presentes en el primer archivo de historización LG1 en el momento de la grabación S12. También, previamente a la etapa de grabación S12 en el primer archivo de historización LG1, la tarjeta inteligente realiza la etapa de verificación S8 y, eventualmente, también la etapa de transferencia S10, como se describe a continuación.
A lo largo de la etapa de verificación S8, la tarjeta inteligente 2 verifica que la grabación S12 inminente de los nuevos datos de historización DH en el primer archivo de historización LG1 según el primer formato FT1, cumple al menos una condición predeterminada CD que indica que dicha grabación S12 es crítica respecto a datos de historización antiguos DH almacenados como entrada anterior RC (representativa de una transacción previa a la transacción actual TR1) en el primer archivo de historización LG1. Como se indica a continuación, el experto en la técnica puede adaptar la o las condiciones CD que van a tenerse en cuenta en S8 para determinar si la grabación S8 que va a realizarse es crítica o no. Según un ejemplo particular, se considera que la grabación S8 de los nuevos datos de historización DH es crítica, si esta grabación en el primer archivo de historización LG1 provoca la supresión (o pérdida) de cualquier entrada antigua RC ya presente en ese archivo LG1 antes de la grabación S12.
La definición de las condiciones CD permite adaptar en qué casos debe hacerse una copia de seguridad de datos de historización antiguos DH, según el segundo formato de datos FT2, en el segundo archivo de historización LG2. En particular, se considera que la grabación S12 inminente es crítica si hay un riesgo suficiente de que provoque la pérdida inmediata, o eventual próxima, de datos de historización antiguos DH pertinentes almacenados en el primer archivo de historización LG1, según el primer formato de datos FT1.
Una condición CD aplicada en S8 puede comprender, concretamente, una condición temporal como se describe a continuación.
Si no se detecta que la grabación S12 inminente es crítica en S8, la tarjeta inteligente 2 procede a esta etapa de grabación S12 que se describe a continuación. En este caso, la tarjeta inteligente 2 no transfiere datos de historización antiguos DH desde el primer archivo de historización LG1 al segundo archivo de historización LG2. Dicho de otro modo, entonces no se activa el mecanismo de copia de seguridad de la invención por la tarjeta inteligente 2.
En cambio, si se detecta en S8 que la grabación S12 inminente es crítica respecto a datos de historización antiguos DH almacenados como entrada anterior RC en el primer archivo de historización LG1, la tarjeta inteligente 2 realiza una etapa de transferencia S10 a lo largo de la cual transfiere (o hace una copia de seguridad de) dichos datos de historización antiguos DH al segundo archivo de historización LG2, según el segundo formato de datos FT2. Estos datos de historización antiguos DH se graban como nueva entrada de copia de seguridad RD en una ubicación libre del segundo archivo de historización LG2 o, a menos que se indique lo contrario, en el lugar de la entrada de copia de seguridad más antigua RD presente en el segundo archivo de historización LG2 (grabación cíclica). Como ya se indicó, el segundo formato FT2 tiene un tamaño reducido (comprimido) con respecto al primer formato de datos FT1. Esta transferencia S10 se realiza previamente a la grabación S12 de los nuevos datos de historización DH en el primer archivo de historización LG1, con el fin de evitar cualquier riesgo de pérdida de datos de historización antiguos DH pertinentes.
Como se describe en más detalle a continuación, la etapa de transferencia S10 (o etapa de copia de seguridad) necesita la conversión previa de los datos de historización DH al segundo formato FT2, de manera que al menos uno de los tipos de datos definidos por el primer formato FT1 se excluya de los datos de historización Dh de los que se hace una copia de seguridad en el segundo archivo de historización FT2. La conversión al formato FT2 se realiza en el presente documento excluyendo al menos una regla de selección predefinida RL, indicando esta regla el o los tipos de datos seleccionados con vistas a hacer una copia de seguridad de los mismos en el segundo archivo de historización LG2.
Como se ilustra en la Figura 4B, en el presente documento se supone, por ejemplo, que, durante la etapa de transferencia S10, se hace una copia de seguridad de datos de historización antiguos DH del archivo LG1, según el segundo formato FT2, como nueva entrada RD2 en el segundo archivo de historización LG2, comprendiendo esta nueva entrada RD2 los tipos de datos DH1, DH2 y DH6. Dicho de otro modo, la transferencia S10 conduce en este ejemplo a la exclusión de los tipos de datos DH3, DH4 y DH5 de los datos de historización antiguos DH de los que se hace una copia de seguridad (S10) antes de la grabación S12 de los nuevos datos de historización en el primer archivo de historización LG1.
Como se representa en la Figura 5 , a lo largo de la etapa de grabación S12, la tarjeta inteligente 2 graba a continuación los nuevos datos de historización DH (obtenidos en S6), según el primer formato de datos FT1, en el primer archivo de historización LG1. Estos nuevos datos de historización DH se graban como nueva entrada RC en una ubicación libre del primer archivo de historización LG1 o, a menos que se indique lo contrario, en el lugar de la entrada más antigua RC presente en el primer archivo de historización LG1 (grabación cíclica). En el caso en el que se haya detectado que la grabación S12 es crítica en S8, es susceptible de provocar la pérdida inmediata o posterior de una entrada anterior RC correspondiente a una transacción previa a la transacción actual TR1.
La presente invención permite optimizar el uso de la memoria de la tarjeta inteligente para almacenar datos de histórico propios de las transacciones procesadas por la tarjeta. Como ya se ha indicado, los recursos en la memoria de una tarjeta inteligente son limitados. La tarjeta inteligente según la invención puede realizar una clasificación inteligente para transferir, si es necesario, determinados datos de histórico desde un primer archivo de historización hacia un segundo archivo de historización, de manera que se realiza una copia de seguridad en forma comprimida de datos de historización.
Este mecanismo de transferencia permite limitar los riesgos de que se pierdan datos de histórico antiguos, que se considera que todavía son pertinentes, tras la grabación de nuevos datos de histórico en la memoria de la tarjeta inteligente y ello al tiempo que se garantiza que se hace una copia de seguridad de un mínimo de información útil, con el fin de ahorrar espacio de memoria.
La copia de seguridad puede ponerse en práctica en un segundo archivo de histórico dedicado de la tarjeta inteligente, sin que sea necesario ejecutar un algoritmo de compresión complejo, facilitando de este modo la protección de los datos de historización.
En particular, la invención permite determinar si deben transferirse datos de historización antiguos desde el primer archivo de historización hacia un segundo archivo de historización, en función del carácter crítico o no de una grabación inminente de nuevos datos de historización en el primer archivo de historización. Si una grabación inminente de este tipo es crítica, la tarjeta inteligente detecta que datos de historización antiguos almacenados en el primer archivo de historización corren el riesgo de perderse y, por consiguiente, transfiere los mismos al segundo archivo de historización en un formato comprimido. Aunque determinados datos de historización no se conserven durante esta transferencia de copia de seguridad debido al uso del segundo formato, esto permite garantizar que la tarjeta inteligente conserva en memoria al menos determinados tipos de datos que se consideran importantes para un aprovechamiento posterior por la tarjeta inteligente o una entidad de terceros.
Por tanto, la tarjeta inteligente 2 puede acceder posteriormente a los datos de historización DH grabados tanto en el primer archivo de historización LG1 en el formato FT1 como en el segundo archivo de historización LG2 en el formato FT2.
En particular, a lo largo de una etapa de lectura S14 (Figura 5), la tarjeta inteligente 2 puede leer posteriormente los datos de historización DH almacenados en el segundo archivo de historización LG2, según el formato FT2, y usar estos datos de manera apropiada. Concretamente, la tarjeta inteligente 2 puede usar estos datos DH para realizar un control de seguridad, concretamente, durante el procesamiento de una transacción posterior a la transacción TR1, o puede incluso transmitir estos datos a un terminal externo, por ejemplo, durante el procesamiento de una transacción posterior.
De este modo, la tarjeta inteligente 2 puede usar ventajosamente todos los datos de historización DH de los que se ha hecho una copia de seguridad en el segundo archivo de historización para proteger el procesamiento de transacciones. El emisor IS de la tarjeta inteligente 2 puede recibir, igualmente, estos datos, durante el procesamiento en línea de una transacción, por ejemplo, para realizar todos los tipos de procesamiento apropiados: controles de seguridad a distancia de la transacción en curso, análisis del comportamiento del portador de la tarjeta,
Como ya se indicó, las condiciones predefinidas CD aplicadas a la etapa S8 para determinar si la grabación S12 inminente es crítica o no, pueden adaptarse según el caso.
En un ejemplo de realización particular, la tarjeta inteligente 2 detecta sistemáticamente en S8 que la grabación S12 inminente de los nuevos datos de historización DH de la transacción actual TR1 no es crítica si esta transacción actual TR1 es una transacción sin contacto. Dicho de otro modo, la tarjeta inteligente 2 bloquea sistemáticamente el mecanismo de copia de seguridad de la invención en el caso en el que la transacción actual TR1 se procese sin contacto por la tarjeta inteligente 2. Para ello, la tarjeta inteligente 2 detecta previamente si la transacción actual TR1 es una transacción sin contacto o no. Cuando se realiza una transacción sin contacto, es importante que la tarjeta inteligente 2 procese la transacción rápidamente, debido, concretamente, a restricciones de tiempo impuestas por esta operación o por una norma aplicable. Por tanto, resulta ventajoso evitar poner en práctica el mecanismo de copia de seguridad de la invención, con el fin de garantizar un procesamiento rápido de las transacciones sin contacto.
En un ejemplo de realización particular, la tarjeta inteligente 2 detecta en S8 que la grabación S12 inminente de los nuevos datos de historización DH de la transacción actual TR1 es crítica, solamente si la transacción actual TR1 pasa satisfactoriamente. Para ello, la tarjeta inteligente 2 detecta previamente si se ha obtenido un criptograma TC (por “ Transaction Certifícate’’), que indica que se ha aprobado la transacción, para la transacción actual TR1. La tarjeta inteligente 2 consulta, por ejemplo, los datos de historización obtenidos DH en S6 y determina si contienen el criptograma TC de acuerdo con la norma EMV. Esta variante permite limitar el espacio de memoria usado en la tarjeta inteligente, al transferir al archivo de historización secundario sólo los datos de historización que se considera que son los más pertinentes, a saber, los que se refieren a transacciones aprobadas por la tarjeta inteligente 2.
La Figura 6 representa las etapas realizadas por la tarjeta inteligente 2 ilustradas en las Figuras 1-3 y 4A-4B durante un procedimiento de procesamiento de acuerdo con un modo de realización particular de la invención. Más precisamente, la tarjeta inteligente 2 pone en práctica el procedimiento de procesamiento ejecutando el programa PG1, según un modo de realización particular de la invención.
Se supone que la tarjeta inteligente 2 realiza las etapas S2, S4 y S6 de manera idéntica a lo que se describió anteriormente haciendo referencia a la Figura 5 y que la tarjeta inteligente 2 está a punto de grabar (etapa S12 inminente) los nuevos datos de historización obtenidos DH en S6 en el primer archivo de historización LG1. según el primer formato de datos FT1, como ya se describió haciendo referencia a la Figura 5.
La tarjeta inteligente 2 realiza, a continuación, la etapa de verificación S8, como ya se describió haciendo referencia a la Figura 5 , para verificar si la grabación S12 inminente de los nuevos datos de historización DH en el primer archivo de historización LG1 es crítica respecto a datos de historización antiguos DH almacenados como entrada anterior RC en el primer archivo de historización LG1.
Para ello, a lo largo de la etapa de verificación S8, la tarjeta inteligente 2 realiza en este ejemplo una etapa de determinación S20 para determinar si la grabación S12 inminente de los datos de historización DH, según el primer formato de datos FT1. en el primer archivo de historización LG1 conduce (una vez realizada) a una destrucción o supresión de una entrada anterior RC, representativa de una transacción anterior, ya grabada en el primer archivo de historización LG1 según el primer formato de datos FT1. Se detecta un riesgo de destrucción, por ejemplo, si no existen más ubicaciones o zonas de memoria libre (no ocupada) en el primer archivo de historización LG1 o incluso si este archivo LG1 ya incluye un número máximo predefinido n1 de entradas correspondientes a transacciones previas a la transacción actual TR1.
Si la etapa de determinación S20 proporciona un resultado negativo (sin riesgo de destrucción de una entrada antigua en LG1), entonces la tarjeta inteligente 2 procede a la etapa de grabación S12, de manera idéntica a lo que se describió anteriormente en la Figura 5, de manera que se graban los nuevos datos de historización obtenidos Dh en S6 en el primer archivo de historización LG1 según el primer formato de datos FT1. En este caso, la tarjeta inteligente 2 no transfiere datos de historización antiguos DH desde el primer archivo de historización LG1 al segundo archivo de historización LG2. Dicho de otro modo, no se activa el mecanismo de copia de seguridad de la invención por la tarjeta inteligente 2.
En cambio, si la etapa de determinación S20 proporciona un resultado positivo que indica un riesgo de destrucción de una entrada anterior RC en el primer archivo de historización LG1, entonces la tarjeta inteligente 2 continúa la etapa de verificación S8 realizando una detección S22.
A título de ejemplo a continuación, se supone que, durante la etapa de determinación S20, la tarjeta inteligente 2 determina que la grabación S12 inminente de los datos de historización DH, según el primer formato de datos FT1, en el primer archivo de historización LG1 conduce a la destrucción de la entrada anterior RC2, representativa de una transacción anterior TR2, ya grabada en el primer archivo de historización LG1 según el primer formato de datos FT1 (Figura 4A). Esto se explica en el presente documento por el hecho de que la entrada anterior RC2 constituye, en este ejemplo, la entrada más antigua grabada en el archivo LG1 en el momento de la ejecución de la etapa de determinación S20.
A lo largo de la etapa de detección S22, la tarjeta inteligente 2 detecta que la grabación S8 inminente de los datos de historización DH de la transacción actual TR1 es crítica si la transacción anterior TR2, definida por dicha entrada anterior DH2 que corre el riesgo de destruirse, cumple una primera condición temporal CD1.
Son posibles diversas condiciones temporales para definir en S22 si una grabación mediante destrucción en el primer archivo de historización LG1, constituye una grabación crítica o no en el sentido de la invención. Igualmente, es posible una combinación de condiciones temporales y no temporales. En el ejemplo considerado en el presente documento, la verificación de la primera condición temporal se ilustra haciendo referencia a las Figuras 7A y 7B .
Se supone que la transacción actual TR1 se procesa (o se ha procesado) a lo largo de un instante actual PC que está representado en una línea de tiempo en las Figuras 7A y 7B .
El término “ instante” designa en este documento una fecha y/o una hora o, más generalmente, una indicación cualquiera de una posición en el tiempo (indicación temporal). Se supone que cada transacción considerada en este documento está caracterizada por un instante t dado, que está definido en los datos de histórico correspondientes. En este documento, un instante puede estar caracterizado por una fecha y/o una hora, por ejemplo.
El instante actual PC caracteriza el instante a lo largo del cual se realiza el procedimiento de la invención, dejándose a libre elección del experto en la técnica la manera en la que se determina este instante actual por el terminal T. En un ejemplo particular, la tarjeta inteligente 2 recupera una indicación del instante actual PC desde el terminal T (etapa S4) en los datos de transacción DTR.
Según el ejemplo considerado en el presente documento, PC designa, por tanto, el instante actual a lo largo del cual se realiza o se ha realizado la transacción actual TR1 por la tarjeta inteligente 2. Se indica, por otro lado, como PA1 un primer instante, previo en el tiempo al instante actual PC, a lo largo del cual se ha realizado la transacción anterior TR2, como se define por la entrada anterior RC2. En S22 se detecta que se cumple la primera condición temporal CD1, si este primer instante previo PA1, a lo largo del cual se ha realizado la transacción anterior TR2 según la entrada anterior RC2, se encuentra en un periodo de tiempo PD, de una duración predefinida, que termina en el instante actual PC. Este periodo de tiempo PD es, en el presente documento, un periodo de tiempo deslizante que presenta una duración predefinida y se acaba en el instante actual PC de la transacción actual TR1 procesada por la tarjeta inteligente 2. La duración predefinida del periodo PD está fijada, por ejemplo, a 1 mes, pudiendo adaptarse este valor según el caso.
La Figura 7A representa un primer caso en el que, según la entrada RC2 almacenada en el archivo de historización LG1, la transacción anterior TR2 está asociada a un instante previo PA1 que se encuentra en el periodo de tiempo PD. Por tanto, en este caso, se cumple la primera condición temporal CD1.
La Figura 7B representa un segundo caso en el que, según la entrada RC2 almacenada en el archivo de historización LG1, la transacción anterior TR2 está asociada a un instante previo PA1 que es previo al periodo de tiempo PD. Por tanto, en este caso, no se cumple la primera condición temporal CD1.
La verificación realizada por la tarjeta inteligente 2 para determinar en S22 si se cumple la primera condición temporal CD1, se describe en más detalle a continuación, en un ejemplo particular presentado en la Figura 9.
Haciendo todavía referencia a la Figura 6 , si en S22 se detecta que no se cumple la primera condición temporal CD1 (caso de la Figura 7B), entonces la tarjeta inteligente 2 procede a la etapa de grabación S12, de manera idéntica a lo que se describió anteriormente en la Figura 5 , de manera que se graban los nuevos datos de historización obtenidos DH en S6 en el primer archivo de historización LG1 según el primer formato de datos FT1. En este caso, la tarjeta inteligente 2 no transfiere datos de historización antiguos DH desde el primer archivo de historización LG1 al segundo archivo de historización LG2. Dicho de otro modo, no se activa el mecanismo de copia de seguridad de la invención por la tarjeta inteligente 2. En este caso particular, la grabación S12 de los nuevos datos de historización DH representativos de la transacción actual TR1 conlleva, por consiguiente, la supresión, en el primer archivo de historización LG1, de la entrada RC2 correspondiente a la transacción anterior TR2.
Esta destrucción de datos en S12 se justifica, en el presente documento, por el hecho de que se estima que la entrada anterior RC2 ya no es pertinente debido a que corresponde a una transacción suficientemente antigua, ya que es previa a la ventana temporal PD que termina en el punto actual PC. Por tanto, en el presente documento, la tarjeta inteligente 2 considera que ya no resulta útil hacer una copia de seguridad de una versión comprimida de esta entrada anterior RC2 en el segundo archivo de historización LG2, lo cual permite evitar el uso superfluo de recursos de la tarjeta inteligente 2.
Por el contrario, si en S22 se detecta que se cumple la primera condición temporal CD1 (caso de la Figura 7A), entonces se detecta que la grabación S12 inminente es crítica (S8) y la tarjeta inteligente 2 realiza una copia de seguridad de la entrada RC2 en el segundo archivo de historización LG2 de conformidad con la invención (Figura 6).
En este ejemplo, se supone que la tarjeta inteligente 2 realiza la copia de seguridad de la entrada antigua RC2 representativa de la transacción antigua TR2, transfiriendo los datos de historización correspondientes DH al segundo archivo de historización LG2 según el segundo formato de datos FT2. Para ello, la tarjeta inteligente 2 procede en este ejemplo a las etapas S24, S26 y S10, como se describe a continuación, previamente a la etapa de grabación S12.
Más particularmente, a lo largo de una etapa de selección S24, la tarjeta inteligente 2 selecciona, de entre los tipos de datos de historización DH1-DH6 definidos por el primer formato de datos FT1, un subconjunto de tipos de datos de historización de conformidad con al menos una regla de selección predefinida RL. La tarjeta inteligente 2 puede seleccionar, por ejemplo, en S24 los tipos de datos DH1, DH2 y DH6 de entre los tipos de datos DH1-DH6, como se ilustra en las Figuras 2A-2B. Estos tipos de datos son, por ejemplo, tales como:
- DH1 define un instante (fecha y/u hora) que caracteriza a la transacción actual TR1;
- DH2 define el importe de la transacción actual TR1; y
- DH3 define la divisa usada en la transacción actual TR1.
Debe observarse que las reglas predefinidas RL aplicadas en la etapa S24, para determinar qué tipos de datos deben seleccionarse, pueden adaptarse según el caso.
Según un ejemplo particular, las reglas predefinidas RL definen siempre los mismos tipos de datos de los que va a hacerse una copia de seguridad como nueva entrada en el segundo archivo de historización LG2. Las reglas RL prevén, por ejemplo, la selección sistemática de los tipos de datos DH1, DH2 y DH6 durante la etapa de selección S24, provocando, de este modo, la exclusión de los tipos de datos DH3-DH5.
Según otro ejemplo, la tarjeta inteligente 2 puede adaptar, igualmente, los tipos de datos de historización seleccionados DH en S24, en función de las entradas anteriores de copia de seguridad RD ya almacenadas en el segundo archivo de historización LG2 en el momento de iniciar la etapa de selección S24. Haciendo variar los tipos de datos seleccionados en S24, es posible limitar aún más el espacio de memoria necesario para almacenar los datos de historización DH.
Más particularmente, en el momento de iniciar la etapa de selección S24, el segundo archivo de historización LG2 ya comprende, por ejemplo, al menos una entrada antigua RD de la que se ha hecho una copia de seguridad según el formato FT. Esta entrada antigua RD es representativa de una transacción anterior previa a la transacción TR2 que es el objeto del mecanismo de copia de seguridad. En el presente documento se supone, por ejemplo, que el segundo archivo de historización LG2 sólo incluye, en el momento de iniciar la etapa de selección S24, las entradas antiguas RD1 y RD2 de las que se ha hecho una copia de seguridad correspondientes a las transacciones respectivas TR3 y TR4 previas a la transacción TR2 (Figura 4B). En este caso, la tarjeta inteligente 2 selecciona en S24, de conformidad con una regla de selección predefinida RL, el primer tipo DH1 de datos de historización solamente si la entrada más reciente RD de la que se ha hecho una copia de seguridad en el segundo archivo de historización LG2 que incluye dicho primer tipo de dato de historización DH1 especifica, para dicho primer tipo de datos de historización DH1, un valor diferente del definido por la entrada RC2 para la transacción TR2. Dicho de otro modo, suponiendo, por ejemplo, que DH1 corresponde al instante (la fecha, por ejemplo) de una transacción, la tarjeta inteligente 2 sólo selecciona el tipo DH1 en S24 si la entrada anterior RD2 que incluye el primer tipo DH1 en el archivo LG2 especifica, para ese tipo DH1, una fecha diferente de la definida por la entrada RC2 en el archivo LG1 para la transacción TR2. En la hipótesis en la que la entrada RD2 no incluyera el tipo DH1, la tarjeta inteligente 2 consulta la entrada anterior de copia de seguridad RD1 que incluye el tipo DH1, de manera que el tipo DH1 sólo se selecciona en S24 si la entrada anterior RD1 en el archivo LG2 especifica, para ese tipo DH1, una fecha diferente de la definida por la entrada RC2 en el archivo LG1 para la transacción TR2.
De esta manera, es posible, por ejemplo, adaptar el contenido de cada nueva entrada RD de la que se hace una copia de seguridad en el segundo formato FT2, de manera que se satisface al menos una de las siguientes condiciones:
- el importe de la transacción TR2 de la que va a hacerse una copia de seguridad en LG2 siempre se selecciona en S24;
- la fecha de la transacción TR2 de la que va a hacerse una copia de seguridad se selecciona en S24 solamente si es diferente de la fecha de la transacción más reciente de la que ya se ha hecho una copia de seguridad en el segundo archivo de historización LG2;
- la divisa de la transacción TR2 de la que va a hacerse una copia de seguridad se selecciona en S24 solamente si es diferente de la divisa de la transacción más reciente de la que ya se ha hecho una copia de seguridad en el segundo archivo de historización LG2.
Dicho de otro modo, al menos una entrada RD de la que se ha hecho una copia de seguridad en el segundo archivo de historización LG2 puede codificarse a partir del contenido de la entrada inmediatamente anterior RD en el segundo archivo de historización LG2 o a partir del contenido de otra entrada anterior RD en el segundo archivo de historización LG2.
Si la tarjeta inteligente graba un tipo de tipos de dato en el segundo archivo de historización LG2 durante la copia de seguridad de una transacción antigua, únicamente cuando el valor correspondiente difiere con respecto a otra transacción de la que se ha hecho anteriormente una copia de seguridad en el segundo archivo de historización LG2, es posible ganar aún más espacio de memoria sin perder información útil. Como varias transacciones sucesivas presentan con frecuencia características comunes (misma fecha, misma divisa, ...), se evita almacenar información redundante en el archivo de historización secundario LG2 de la tarjeta inteligente 2. Una entrada de copia de seguridad RD almacenada en el segundo archivo de historización LG2 puede interpretarse a partir de la entrada inmediatamente anterior o a partir de otra entrada anterior en ese archivo LG2.
En particular, cuando los tipos de los datos de historización en el segundo archivo de historización LG2 son susceptibles de variar, resulta ventajoso hacer constar en cada entrada RD un campo (no representado en las figuras) que indica los tipos de datos que se hacen constar (por ejemplo, en un encabezado de la entrada). Este campo permite, concretamente, interpretar más fácilmente los datos de historización que se hacen constar en una entrada RD, por ejemplo, durante una etapa de interpretación S28 descrita a continuación.
A continuación, en este ejemplo representado en la Figura 6 , se supone que sólo se seleccionan los tipos de DH2 y DH6 durante la etapa de selección S24 en el contexto de la copia de seguridad de la entrada RC2 del archivo LG1 correspondiente a la transacción antigua TR2.
Una vez realizada la etapa de selección S24, la tarjeta inteligente 2 convierte (etapa S26) los datos de historización DH de la entrada RC2 desde el primer formato FT1 al segundo formato FT2, de manera que se forma una nueva entrada de copia de seguridad RD3 en la que sólo se conservan el o los tipos de datos de historización seleccionados en S24. Dicho de otro modo, en el ejemplo considerado en el presente documento, la nueva entrada de copia de seguridad RD3 comprende los datos DH2 y DH6 de la entrada antigua RC2. En cambio, los datos DH1, DH3, DH4 y DH5 de la entrada antigua RC2 se excluyen de la copia de seguridad.
A lo largo de una etapa de transferencia S10, la tarjeta inteligente 2 transfiere (o hace una copia de seguridad de) la nueva entrada de copia de seguridad RD3 en el segundo archivo de historización LG2 según el segundo formato de datos FT2, como ya se describió haciendo referencia a la Figura 5. Más particularmente, en el ejemplo considerado en el presente documento, la nueva entrada RD3 se graba en el segundo archivo de historización LG2 después de la entrada anterior RD2.
Tras esta etapa de transferencia S10, la tarjeta inteligente 2 realiza la etapa de grabación S12 a lo largo de la cual graba los nuevos datos de historización DH, correspondientes a la transacción en curso TR1, en el primer archivo de historización LG1 según el primer formato FT1. En el caso en el que se haya detectado que la grabación S12 es crítica por adelantado en S8, puede provocar la pérdida inmediata o posterior de una entrada anterior RC correspondiente a una transacción previa a la transacción actual TR1, tal como, por ejemplo, la entrada RC2 de la transacción anterior TR2.
La tarjeta inteligente 2 puede consultar posteriormente los datos de historización DH grabados en el formato FT2 en el segundo archivo de historización LG2.
Como se representa en la Figura 6 , la tarjeta inteligente 2 puede interpretar posteriormente (etapa S28), si es necesario, la entrada de copia de seguridad RD2 almacenada en el segundo archivo de historización LG2 a partir de la entrada de copia de seguridad inmediatamente anterior RD o a partir de otra entrada de copia de seguridad anterior RD. La tarjeta inteligente 2 puede hacer referencia, dado el caso, al campo de la entrada RD2 para determinar los tipos de datos que se hacen constar en esta entrada. En el ejemplo considerado en el presente documento (Figura 4B), la tarjeta inteligente 2 convierte la entrada de copia de seguridad RD3 en un formato modificado, más fácilmente aprovechable por una entidad de terceros, haciendo constar en la misma el dato de historización DH1 representativo de la transacción antigua TR2. La tarjeta inteligente 2 recupera el dato DH1 de la transacción TR2 a partir del dato DH1 de la entrada anterior RD2 en el segundo archivo de historización LG2.
La tarjeta inteligente 2 puede transmitir a continuación (S30), la entrada RD3 en este formato modificado (o en su formato FT2 de origen) a una entidad de terceros, tal como el banco IS, por medio de un terminal de lectura, lo cual permite que el emisor IS de la tarjeta inteligente 2 recopile la información de histórico pertinente. La interpretación S28 eventualmente efectuada por la tarjeta inteligente 2, permite hacer que la manera en la que se ha codificado una entrada de copia de seguridad RD en el segundo archivo de historización LG2 a partir de una entrada anterior de copia de seguridad RD, sea transparente para el emisor IS.
Por otro lado, como ya se indicó, las condiciones predefinidas CD aplicadas en la etapa S8 (Figuras 4-5) para determinar si una grabación S2 que va a realizarse es crítica o no, pueden adaptarse según el caso.
En un ejemplo de realización particular, la tarjeta inteligente 2 detecta sistemáticamente en S22 (Figura 6) que la grabación de los datos de historización DH de la transacción actual TR1 no es crítica, si la transacción actual TR1 es una transacción sin contacto. Para ello, la tarjeta inteligente 2 detecta previamente si la transacción actual TR1 es una transacción sin contacto o no.
Cuando se realiza una transacción sin contacto, es importante que la tarjeta inteligente 2 procese la transacción rápidamente, debido, concretamente, a restricciones de tiempo impuestas por esta operación o por una norma aplicable. Por tanto, resulta ventajoso evitar poner en práctica el mecanismo de almacenamiento en forma comprimida en el archivo de historización secundario, con el fin de garantizar un procesamiento rápido de las transacciones sin contacto.
Además, siempre con el objetivo de facilitar el procesamiento de las transacciones sin contacto, puede resultar ventajoso activar el mecanismo de copia de seguridad de la invención, transfiriendo datos de historización antiguos DH al segundo archivo de historización LG2, según el segundo formato FT2, cuando la transacción actual TR1 se procesa por la tarjeta inteligente 2 mediante contacto y ello, aunque no haya un riesgo inmediato de suprimir datos de historización anteriores DH en el primer archivo de historización LG1 (Figura 1).
Por ejemplo, puede configurarse la tarjeta inteligente 2 para que detecte en S8 (Figuras 4 y 5) que la grabación S12 inminente de los datos de transacción DH de la transacción actual TR1 en el primer archivo LG1 es crítica en cuanto existe un número insuficiente de espacios vacantes en el primer archivo de historización LG1 para que datos de historización de próximas transacciones sin contacto puedan almacenarse rápidamente en el primer archivo de historización LG1, sin necesitar la copia de seguridad S10 de datos de historización antiguos DH en el segundo archivo de historización LG2.
De este modo, según un ejemplo particular representado en la Figura 8 , la tarjeta inteligente 2 realiza las etapas S2 a S6 como ya se describió anteriormente. A lo largo de la etapa de verificación S8, la tarjeta inteligente 2 determina en S50 si la transacción actual TR1 se realiza por contacto. En caso negativo (realización sin contacto), la tarjeta inteligente 2 detecta (S8) que la grabación S12 inminente de los nuevos datos de historización DH en el primer archivo de historización LG1 no es crítica y, por consiguiente, procede directamente a la etapa de grabación S12, de manera idéntica a lo que se describió anteriormente haciendo referencia a las Figuras 4 y 5.
En cambio, si la tarjeta inteligente 2 determina en S50 que la transacción actual TR1 se realiza mediante contacto con el terminal T, entonces la tarjeta inteligente 2 procede a la etapa de determinación S52 a lo largo de la cual detecta sistemáticamente que la grabación S12 inminente es crítica si se cumple la siguiente condición:
detección de que dicha grabación S12 de los nuevos datos de historización DH, según el primer formato FT1, en el primer archivo de historización LG1 conduce a que dicho archivo LG1 contenga un número, superior o igual a un valor umbral k predeterminado, de entradas RC de transacciones que satisfacen una segunda condición temporal CD2. Si se cumple esta última condición CD2, esto significa que existe un número demasiado importante (> k) de entradas pertinentes en el primer archivo de historización LG1 y que, por tanto, hay un riesgo de que ya no sea posible almacenar los nuevos datos de historización de una transacción posterior realizada sin contacto en el primer archivo de historización LG1, sin activar el mecanismo de copia de seguridad (S10), al tiempo que se evita la pérdida de datos de historización antiguos pertinentes. Dicho de otro modo, el bloqueo sistemático del mecanismo de copia de seguridad S10 en el caso de las transacciones por contacto, corre entonces el riesgo de provocar la supresión de datos de historización antiguos pertinentes en el primer archivo de historización LG1.
En un ejemplo particular, la segunda condición temporal CD2 es idéntica a la primera condición temporal CD1, tal como se describió anteriormente.
Si se detecta que la grabación S12 inminente es crítica en S52 (Figura 8), la tarjeta inteligente 2 realiza la etapa de transferencia S10 de datos de historización antiguos desde el primer archivo LG1 al segundo archivo LG2 según el formato FT2, después realiza la etapa de grabación S12 de los nuevos datos de historización DH de la transacción actual TR1 en el primer archivo LG1, de manera idéntica a lo que se describió anteriormente haciendo referencia a las Figuras 4 y 5. Para ello, la tarjeta inteligente 2 realiza, por ejemplo, las etapas S24 y S26, como ya se describieron haciendo referencia a la Figura 5.
En cambio, si se detecta que la grabación S12 inminente no es crítica en S52 (condición temporal CD2 no cumplida), entonces la tarjeta inteligente 2 procede directamente a la etapa de grabación S12, de manera idéntica a lo que se describió anteriormente haciendo referencia a las Figuras 4 y 5.
Por otro lado, como se indicó anteriormente, la Figura 9 representa la verificación realizada por la tarjeta inteligente 2 para determinar en S22 (Figuras 6 y 7A-7B) si se cumple la primera condición temporal CD1, según un ejemplo de realización particular.
A lo largo de una etapa de determinación S40, la tarjeta inteligente 2 determina, a partir de los datos de transacción recibidos DTR en S4, el instante actual PC que caracteriza a la transacción actual TR1.
La tarjeta inteligente 2 calcula (S42), a continuación, un segundo instante PA2 previo al instante actual PC, correspondiendo este segundo instante PA2 al inicio del periodo de tiempo predefinido PD. Este cálculo S42 se realiza a partir del instante actual PC y de la duración predefinida atribuida a dicho periodo de tiempo predefinido PD (PA2 = PC -PD).
La tarjeta inteligente 2 detecta (S44) que el primer instante PA1, que caracteriza a la transacción TR2, se encuentra en el periodo de tiempo PD, si es posterior al segundo instante PA2 que marca el inicio del periodo PD.
Un experto en la técnica comprenderá que los modos de realización y variantes descritos anteriormente sólo constituyen ejemplos no limitativos de puesta en práctica de la invención. En particular, el experto en la técnica podrá prever cualquier adaptación o combinación de los modos de realización y variantes descritos anteriormente con el fin de responder a una necesidad muy particular.

Claims (15)

  1. REIVINDICACIONES
    i. Procedimiento de procesamiento puesto en práctica por un dispositivo electrónico (2) adecuado para procesar transacciones, comprendiendo dicho procedimiento:
    - recepción de datos de transacción (DN) procedentes de un terminal (T) con el que actúa conjuntamente el dispositivo electrónico para procesar una transacción actual (TR1);
    - obtención, a partir de los datos de transacción recibidos, de nuevos datos de historización representativos de la transacción actual; y
    - grabación de los nuevos datos de historización, según un primer formato de datos (FT1), como nueva entrada (RC) en un primer archivo de historización (LG1);
    y caracterizado por que, previamente a dicha grabación, el procedimiento comprende:
    - verificación de que dicha grabación cumple al menos una condición predeterminada que indica que dicha grabación es crítica respecto a datos de historización antiguos almacenados como entrada anterior (RC) según el primer formato de datos en el primer archivo de historización (LG1), siendo dicha grabación crítica si corre el riesgo de provocar la pérdida de dichos datos de historización antiguos en el primer archivo de historización; y
    - en caso afirmativo, transferencia de los datos de historización antiguos a un segundo archivo de historización (LG2) para hacer una copia de seguridad de los mismos, según un segundo formato de datos (FT2), de tamaño reducido con respecto al primer formato de datos (FT1).
  2. 2. Procedimiento según la reivindicación 1, en el que el segundo formato de datos está reducido por que permite la grabación de una cantidad inferior de datos con respecto al primer formato de datos.
  3. 3. Procedimiento según la reivindicación 2, en el que el primer formato de datos define una pluralidad de tipos de datos que van a grabarse, mientras que el segundo formato de datos define una selección de entre dicha pluralidad de tipos de datos excluyendo al menos uno de entre dicha pluralidad de tipos de datos.
  4. 4. Procedimiento según una cualquiera de las reivindicaciones 1 a 3, en el que dicha verificación comprende:
    - determinación de que la grabación de los nuevos datos de historización según el primer formato de datos en el primer archivo de historización, conduce a una destrucción de una entrada anterior (RC), representativa de una transacción anterior, ya grabada en el primer archivo de historización (LG1) según el primer formato de datos (FT1); y
    - detección de que la grabación es crítica si la transacción anterior, definida por la entrada anterior en el primer archivo de historización (LG1), cumple una primera condición temporal (CD).
  5. 5. Procedimiento según la reivindicación 4, en el que la primera condición temporal se cumple si un instante previo (PA1) a lo largo del cual se ha realizado la transacción anterior (TR2) según dicha entrada anterior, se encuentra en un periodo de tiempo (PD), de una duración predefinida, que termina en un instante actual a lo largo del cual se realiza o se ha realizado la transacción actual (TR1).
  6. 6. Procedimiento según la reivindicación 5, en el que dicha verificación comprende:
    - determinación, a partir de los datos de transacción recibidos (DH), del instante actual (PC) que caracteriza a la transacción actual (TR1); y
    - cálculo de un segundo instante previo (PA2) correspondiente al inicio del periodo de tiempo (PD), a partir del instante actual (PC) y de la duración predefinida atribuida a dicho periodo de tiempo,
    encontrándose el primer instante previo (PA1) en el periodo de tiempo (PD), si es posterior al segundo instante previo (PA2).
  7. 7. Procedimiento según una cualquiera de las reivindicaciones 1 a 6, que comprende, previamente a dicha grabación de los nuevos datos de historización según el primer formato de datos en el segundo archivo de historización:
    - selección, de entre los tipos de datos de historización (DH1-DH6) definidos por el primer formato de datos (FT1), de un subconjunto (DH1, DH2, DH6) de tipos de datos de historización de conformidad con al menos una regla de selección predefinida (RL); y
    - conversión de los datos de historización antiguos (DH) según el segundo formato de datos (FT2), con vistas a transferirse al segundo archivo de historización (LG2), en la que solamente el o los tipos de datos de historización seleccionados se conservan en los datos de historización antiguos durante dicha conversión.
  8. 8. Procedimiento según la reivindicación 7, en el que, previamente a dicha selección, el segundo archivo de historización (LG2) ya comprende al menos una entrada (RD) de la que se ha hecho una copia de seguridad según el segundo formato de datos (FT2), siendo dicha entrada de la que se ha hecho una copia de seguridad representativa de una transacción anterior previa a la transacción actual (TR1), y
    en el que, durante dicha selección, el dispositivo electrónico (2) selecciona un primer tipo de datos de historización predefinido, solamente si la entrada más reciente de la que se ha hecho una copia de seguridad en el segundo archivo de historización que incluye el primer tipo de dato de historización especifica, para dicho primer tipo de datos de historización, un valor diferente del definido por dicha entrada anterior (RC).
  9. 9. Procedimiento según una cualquiera de las reivindicaciones 1 a 8, en el que, durante dicha verificación, el dispositivo electrónico detecta sistemáticamente que la grabación no es crítica si la transacción actual es una transacción sin contacto.
  10. 10. Procedimiento según la reivindicación 9, en el que, si la transacción actual es una transacción por contacto con el terminal, el dispositivo electrónico detecta sistemáticamente durante dicha verificación que la grabación es crítica si se cumple la siguiente condición:
    - detección de que dicha grabación de los nuevos datos de historización según el primer formato de datos (FT1) en el primer archivo de historización (LG1), conduce a que el primer archivo de historización (LG1) contenga un número, superior o igual a un valor umbral predeterminado, de entradas de transacciones que satisfacen una segunda condición temporal.
  11. 11. Procedimiento según una cualquiera de las reivindicaciones 1 a 10, en el que, si se detecta durante dicha verificación que dicha grabación no es crítica, el dispositivo electrónico no transfiere los datos de historización antiguos al segundo archivo de historización (LG2) según el segundo formato de datos (FT2), previamente a dicha grabación.
  12. 12. Procedimiento según una cualquiera de las reivindicaciones 1 a 11, el dispositivo electrónico detecta durante dicha verificación que dicha grabación es crítica únicamente con la detección de que la transacción actual (TR1) pasa satisfactoriamente.
  13. 13. Procedimiento según una cualquiera de las reivindicaciones 1 a 12, que comprende, después de dicha transferencia de los datos de historización antiguos según el segundo formato de datos (FT2) en el segundo archivo de historización (LG2):
    - conversión de los datos de historización antiguos desde el segundo formato de datos a un formato modificado a partir del contenido de una entrada anterior en el segundo archivo de historización (LG2); y
    - transmisión de los datos de historización antiguos en el formato modificado de datos a un terminal.
  14. 14. Programa de ordenador (PG1) que incluye instrucciones que provocan la ejecución de las etapas de un procedimiento de procesamiento según una cualquiera de las reivindicaciones 1 a 13, cuando dicho programa se ejecuta por un ordenador.
  15. 15. Dispositivo electrónico adecuado para procesar transacciones, que comprende:
    - un módulo de recepción (MD2) configurado para recibir datos de transacción (DN) procedentes de un terminal (T) con el que actúa conjuntamente el dispositivo electrónico para procesar una transacción actual (TR1);
    - un módulo de obtención configurado para obtener, a partir de los datos de transacción recibidos, nuevos datos de historización que van a grabarse como nueva entrada (RC) en el dispositivo electrónico, siendo dichos nuevos datos de historización representativos de la transacción actual; y - un módulo de grabación configurado para grabar los nuevos datos de historización según un primer formato de datos (FT1), en un primer archivo de historización (LG1);
    el dispositivo caracterizado por que comprende, además:
    - un módulo de verificación configurado para verificar, previamente a la grabación por el módulo de grabación de los nuevos datos de historización según el primer formato de datos (FT1) en el primer archivo de historización (LG1), que dicha grabación cumple al menos una condición predeterminada que indica que dicha grabación es crítica respecto a datos de historización antiguos almacenados como entrada anterior (RC), según el primer formato de datos, en el primer archivo de historización (LG1), siendo dicha grabación crítica si corre el riesgo de provocar la pérdida de dichos datos de historización antiguos en el primer archivo de historización; y
    - un módulo de copia de seguridad configurado, si se detecta que la grabación es crítica por el módulo de verificación, para transferir los datos de historización antiguos a un segundo archivo de historización (LG2) para hacer una copia de seguridad de los mismos según un segundo formato de datos (FT2), de tamaño reducido con respecto al primer formato de datos (FT1).
ES18215118T 2017-12-22 2018-12-21 Copia de seguridad de datos de histórico en un dispositivo destinado a procesar transacciones Active ES2895493T3 (es)

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
FR1763191A FR3076026B1 (fr) 2017-12-22 2017-12-22 Sauvegarde de donnees d'historique dans un dispositif destine a traiter des transactions

Publications (1)

Publication Number Publication Date
ES2895493T3 true ES2895493T3 (es) 2022-02-21

Family

ID=62092013

Family Applications (1)

Application Number Title Priority Date Filing Date
ES18215118T Active ES2895493T3 (es) 2017-12-22 2018-12-21 Copia de seguridad de datos de histórico en un dispositivo destinado a procesar transacciones

Country Status (3)

Country Link
EP (1) EP3502997B1 (es)
ES (1) ES2895493T3 (es)
FR (1) FR3076026B1 (es)

Family Cites Families (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20090012975A1 (en) * 2007-07-03 2009-01-08 Kabushiki Kaisha Toshiba Portable electronic device and file management method for use in portable electronic device
FR3051579B1 (fr) * 2016-05-23 2021-11-19 Oberthur Technologies Procede de securisation d'un dispositif electronique, et dispositif electronique correspondant

Also Published As

Publication number Publication date
EP3502997A1 (fr) 2019-06-26
EP3502997B1 (fr) 2021-09-01
FR3076026A1 (fr) 2019-06-28
FR3076026B1 (fr) 2019-11-29

Similar Documents

Publication Publication Date Title
US8583561B2 (en) Apparatus, method, and computer program product for providing a quality control mechanism for the contactless interface of a dual-interface card
US10672214B2 (en) Method for securing an electronic device, and corresponding electronic device
US20080126262A1 (en) System and Method for Secure Transactions
KR20140108666A (ko) 스마트 카드의 비휘발성 메모리에 데이터 쓰기
CN106340312A (zh) 磁盘装置及磁盘装置的控制方法
EP4187466A1 (en) Systems and methods for point-to-point encryption compliance
ES2895493T3 (es) Copia de seguridad de datos de histórico en un dispositivo destinado a procesar transacciones
EP3365833B1 (en) A method performed by an electronic device capable of communicating with a reader with improved self-testing
KR101312293B1 (ko) Ic 칩 및 이에 대한 데이터 검증 방법
US9798904B2 (en) IC card reader and operating method thereof
US11151338B2 (en) Securing a transaction by means of a smart card and smart card
JP6182940B2 (ja) Icカード、ステータスワード出力方法、及びステータスワード出力処理プログラム
US20180183597A1 (en) Method for the security of an electronic operation with a chip card
US10853476B2 (en) Method for the security of an electronic operation
US9659425B2 (en) Electronic key for authentication
JP5306079B2 (ja) Icカード、icカード処理装置、及びicカード処理システム
JP3195122B2 (ja) Icカードに与える命令フォーマットのチェック方法
Kose et al. A SECURE DESIGN ON MIFARE CLASSIC CARDS FOR ENSURING CONTACTLESS PAYMENT AND CONTROL SERVICES
JP5233521B2 (ja) Icチップ、データ読出し方法、データ読出しプログラム及び記録媒体等
EP3514749B1 (fr) Procede de controle de regles de dependances d'objets mis a jour dans un microcircuit, et dispositif correspondant
JP5131378B2 (ja) 携帯用セキュリティデバイス
EP2499642B1 (en) Method of analyzing the wear of a non volatile memory embedded in a secure electronic token
Kose et al. ADVANCES IN CYBER-PHYSICAL SYSTEMS Vol. 7, Num. 1, 2022 A SECURE DESIGN ON MIFARE CLASSIC CARDS FOR ENSURING CONTACTLESS PAYMENT AND CONTROL SERVICES
TW200536339A (en) Transaction system
JP5293113B2 (ja) 半導体装置、半導体装置の制御方法および半導体装置の制御プログラム