ES2974572T3 - Cartas con medios de autenticación electrónica - Google Patents

Abstract

Algunas realizaciones están dirigidas a un sistema de naipes (100) dispuesto para autenticar un naipe (110) para jugar un juego de cartas. El sistema de naipes que comprende un naipe (110), un dispositivo de autenticación de naipes (200) y un servidor de autenticación de naipes (300). El naipe (110) comprende una memoria electrónica (120) que almacena datos de autenticación (122) y un contador (124). (Traducción automática con Google Translate, sin valor legal)

Description

DESCRIPCIÓN

Cartas con medios de autenticación electrónica

Campo de la Invención

La invención hace referencia a un sistema de juego de cartas, una carta, un dispositivo de autenticación de cartas, un servidor de autenticación de cartas, un método de autenticación de cartas y un soporte legible por ordenador.

Antecedentes

Los juegos de cartas coleccionables (Tradable Card Games - TCG), también conocidos como juegos de cartas coleccionables (collectible card games - CCG), son juegos que se juegan con cartas coleccionables e intercambiables. Estos juegos son cada vez más populares. Por ejemplo, el juego "Magic: the Gathering" (MTG) tiene una gran cantidad de jugadores activos. Otros ejemplos de juegos de cartas coleccionables incluyen: Pokemon TCG, World Of Warcraft TCG, Hearthstone, entre muchos otros. También se conocen formas híbridas de juegos de ordenador y juegos de cartas. Por ejemplo, en el juego "Kantai Collection", los jugadores coleccionan cartas como en un TCG, pero para jugar, las cartas se escanean en una consola de juegos, por ejemplo, una consola arcade. "Sengoku Taisen" es otro ejemplo de juego de ordenador con cartas intercambiables.

En un TCG, los jugadores coleccionan cartas que representan elementos del juego, como personajes, habilidades o similares, los que se pueden utilizar durante la partida. Normalmente, los jugadores pueden adquirir una gran cantidad de cartas al comprar muchas pilas pequeñas de cartas nuevas, lo que se conoce como un sobre o un paquete, a menudo sin saber qué cartas incluirá el sobre. Un jugador reúne de la gran cantidad de cartas un conjunto de cartas, conocido como mazo, con el que puede jugar el juego. Los jugadores cuyo mazo incluye cartas mejores disfrutan de cierta ventaja durante el juego. Por ejemplo, un paquete puede contener 6 cartas más o menos aleatorias, mientras un mazo puede contener 60 cartas seleccionadas.

La fabricación y la venta de las cartas utilizadas en los juegos de cartas intercambiables se ha convertido en un gran negocio. Se calcula que en 2014 había 22 millones de jugadores, con un aumento del 35 % en los últimos cuatro años. Además de la venta de cartas nuevas, existe un mercado secundario activo en el que los jugadores pueden adquirir directamente las cartas que necesitan para sus mazos.

Lamentablemente, la falsificación de cartas es un problema importante en este negocio. Las cartas son cada vez más costosas y el incentivo para falsificarlas aumenta. Es muy difícil distinguir las falsificaciones de las cartas auténticas. Las falsificaciones reducen la confianza de los consumidores. Al reducirse la confianza en la posibilidad de coleccionar el juego, las cartas recuperan su valor intrínseco.

Por consiguiente, se desea diseñar una solución técnica para el problema de la falsificación de cartas.

En el documento US-A1-2012/0214577 se describe una máquina de juego electrónica, por ejemplo, tragaperras.

La máquina tiene un dispositivo de entrada de usuario, por ejemplo, un panel táctil, que acepta lo ingresado por un usuario para desarrollar un juego en el que los resultados del juego responden a una apuesta. Un procesador, es decir, una CPU, proporciona un mecanismo para transmitir mensajes entre la máquina y el dispositivo de entrada en comunicación con la máquina. El procesador transmite un mensaje entre un dispositivo de interacción con tarjeta inteligente y un servidor de alojamiento a través de una interfaz de protocolo de comunicación de mensajería, donde el servidor está en comunicación con la máquina a través de una red de juego basada en servidores, por ejemplo, Internet.

Resumen de la invención

Se aborda el problema con un sistema de cartas, una carta, un dispositivo de autenticación de cartas, un servidor de autenticación de cartas, un método de autenticación de cartas, un medio legible por ordenador, tal como se describe en la presente divulgación.

La carta se dispone para jugar un juego de cartas. La carta comprende una memoria electrónica, una antena y un circuito de procesamiento. La memoria almacena datos y un contador. La antena está dispuesta para comunicación inalámbrica. El circuito de procesamiento está dispuesto para:

- recibir de forma inalámbrica un comando digital a través de la antena procedente de un dispositivo de autenticación de cartas electrónicas,

- crear un token de autenticación en respuesta a la recepción de un comando de autenticación, comprendiendo dicha creación leer los datos de autenticación y el contador de la memoria y aplicar una función criptográfica a los mismos, y

- transmitir de forma inalámbrica el token de autenticación al dispositivo a través de la antena, e

- incrementar el contador almacenado en la memoria.

Se verifica la autenticidad de la carta con un dispositivo de autenticación y un servidor de autenticación. Por ejemplo, el dispositivo de autenticación puede interactuar con la carta local e inalámbricamente. Entonces, es posible verificar el token con el servidor de autenticación, por ejemplo, con la información disponible en el servidor, por ejemplo, datos de autenticación correspondientes y un contador correspondiente. Obsérvese que el token se puede generar en la carta, de modo que no es necesario que los datos de autenticación estén disponibles fuera de la carta, o al menos no todos ellos. Esto dificulta más la falsificación de las cartas, dado que un falsificador no sabe qué información incluir en la carta falsificada.

El contador almacenado en la carta es incrementado después de que la carta cree el token de autenticación. Hay al menos dos opciones diferentes para hacer esto. En una primera opción, el contador en la carta es el principal. Por ejemplo, este contador puede ser incrementado después de cada acción. Por ejemplo, la carta puede estar configurada para que incremente el contador junto con la creación del token de autenticación. Una ventaja de esta opción es, por ejemplo, que no es fácil interrumpir la transacción. Especialmente, no es probable que se produzca exitosamente un token de autenticación en el lado de la carta, pero que no se actualice el contador. Aunque es posible, es más probable que se pueda incrementar el contador en la carta, al tiempo que el contador en el servidor pueda no ser incrementado, por ejemplo, debido a una falla en el dispositivo de autenticación. En esta opción, puede ocurrir que el contador en la carta sea mayor que el contador en el servidor.

En una segunda opción, el contador en el servidor es el principal. Por ejemplo, el contador es incrementado después de que la carta reciba un comando, por ejemplo, una señal, que indica que el contador debe ser incrementado. Cualquiera de las opciones se puede combinar con la actualización de los datos de autenticación en la carta después de una autenticación exitosa. Sin embargo, la segunda opción tiene como ventaja que el comando de incremento del contador se puede combinar con un comando para actualizar la autenticación. Por ejemplo, después de una autenticación exitosa, se envían datos de autenticación nuevos desde el servidor a la carta, posiblemente a través del dispositivo de autenticación, que serán escritos en la carta. Los datos de autenticación nuevos pueden comprender el valor nuevo del contador, pero también pueden comprender un comando para actualizar el contador que está presente en la carta. Los datos de autenticación podrían comprender datos aleatorios. La segunda opción tiene la desventaja de que se podría interrumpir una transacción más fácilmente. Como resultado de esto, es posible que no se actualice el contador en la carta, al tiempo que sí es posible que se actualice el mismo contador almacenado en el servidor. En esta opción, puede ocurrir que el contador en el servidor sea mayor que el contador en la carta.

La carta, el dispositivo de autenticación y el servidor de autenticación son dispositivos electrónicos. En particular, la carta y el dispositivo de autenticación pueden ser dispositivos electrónicos móviles.

En una realización, el servidor de autenticación está configurado para generar una dirección de red informática a través de la cual se puede acceder a una página de información en una red informática. La página de información comprende información que indica el resultado de la autenticación de la carta. Por ejemplo, es posible hacer que la dirección de red informática esté disponible para el dispositivo de autenticación de cartas.

Por ejemplo, el servidor de autenticación puede generar una página web que comprende información sobre la carta. La información puede comprender la autenticidad de la carta y/o su propietario actual. Además, la información puede comprender la fecha y la hora en la que se verificó por última vez la autenticidad de la carta en el servidor de autenticación. La información también puede comprender información adicional sobre la carta, por ejemplo, una imagen, información textual y similares. La dirección de la red informática puede ser una URL. La red informática puede ser la Internet. Se puede hacer referencia a la dirección de la red informática o la URL como un enlace de prueba. El enlace de prueba puede ser válido por una duración de tiempo limitada. Por ejemplo, en una realización, una vez que caduca la validez del enlace de prueba, es posible configurar el servidor de autenticación para que muestre que el enlace caducó, en lugar de mostrar la información de autenticidad. Esta característica reduce adicionalmente la posibilidad de fraude.

Otro aspecto de la invención se refiere a objetos físicos que comprenden una memoria electrónica, como la carta que se describe en la presente divulgación. Al igual que las cartas, los objetos físicos se pueden verificar mediante un servidor de autenticación en línea, a través de un dispositivo de autenticación. Esto puede ser aplicable, por ejemplo, a objetos, tal como zapatos nuevos, perfume y similares. Una realización del método se puede implementar en un ordenador como un método implementado por ordenador, en un hardware dedicado o en una combinación de ambos. El código ejecutable para una realización del método se puede almacenar en un producto de programa informático. Ejemplos de productos de programa informático incluyen dispositivos de memoria, dispositivos de almacenamiento óptico, circuitos integrados, servidores, software en línea, etc. Preferentemente, el producto de programa informático comprende un código de programa no transitorio almacenado en un medio legible por ordenador para llevar a cabo una realización del método cuando dicho producto de programa se ejecuta en un ordenador.

En una realización, el programa informático comprende un código de programa informático adaptado para llevar a cabo la totalidad o parte de los pasos de una realización del método cuando se ejecuta el programa informático en un ordenador. Preferentemente, el programa informático se realiza en un medio legible por ordenador. Otro aspecto de la invención proporciona un método para hacer que el programa informático esté disponible para su descarga. Este aspecto se usa cuando el programa informático está cargado, por ejemplo, en la tienda de aplicaciones de Apple, la tienda de aplicaciones Google Play o la tienda de Microsoft Windows, y cuando el programa informático está disponible para su descarga de tiendas como estas.

Breve descripción de las figuras

A modo de ejemplo, se describirán a continuación detalles, aspectos y realizaciones adicionales de la invención con referencia a las figuras. Los elementos en las figuras se ilustran con fines de simplicidad y claridad y no necesariamente se han dibujado a escala. En las figuras, elementos que corresponden a elementos ya descritos tienen los mismos números de referencia. En las figuras:

la Figura 1 muestra esquemáticamente un ejemplo de una realización un sistema de cartas, la Figura 2 muestra esquemáticamente un ejemplo de una realización un sistema de cartas, la Figura 3a muestra esquemáticamente un ejemplo de una realización de una cadena de bloques, la Figura 3b muestra esquemáticamente un ejemplo de una realización de una red de cadenas de bloques, la Figura 4 muestra esquemáticamente un ejemplo de una realización de un método de autenticación de cartas, la Figura 5a muestra esquemáticamente un medio legible por ordenador que tiene una parte grabable que comprende un programa informático de acuerdo con una realización,

la Figura 5b muestra esquemáticamente una representación de un sistema procesador de acuerdo con una realización,

la Figura 6 muestra esquemáticamente un ejemplo de una realización un sistema de cartas, la Figura 7 muestra esquemáticamente un ejemplo de una realización un sistema de cartas, la Figura 8a muestra esquemáticamente un ejemplo de un modelo de datos de una realización de una aplicación de mercado,

la Figura 8b muestra esquemáticamente un ejemplo de un diagrama de proceso de una realización de la aplicación de mercado,

la Figura 9a muestra esquemáticamente un ejemplo de una realización de una carta,

la Figura 9b muestra esquemáticamente un ejemplo de una realización de un archivador para cartas, la Figura 10 muestra esquemáticamente un ejemplo de una realización de una zapatilla con una etiqueta incrustada en la misma.

Lista de números de referencia en las figuras 1, 2, 3a, 3b, 4, 5a y 5b:

100 un sistema de cartas

110 una carta

120 una memoria electrónica

122 datos de autenticación

124 un contador

130 una antena

140 un circuito de procesamiento

200 un dispositivo de autenticación de cartas

210 una unidad de comunicación

220 una antena

230 un circuito de procesamiento

240 una memoria

250 una pantalla

300 un servidor de autenticación de cartas

310 una memoria electrónica

312 datos de autenticación

314 un contador

320 una unidad de comunicación

330 un circuito de procesamiento

340 una base de datos de cartas

400 un sistema de cartas

410 una carta

411 información impresa

412 un chip

413 una antena

414 texto

414 texto

415 texto adicional

416 una imagen

450 un teléfono móvil

500 una cadena de bloques

511,512 una transacción

521,522 una transacción

510,520 un bloque

519, 529 una evidencia de consenso

530 una red de cadenas de bloques

531-533 un dispositivo de cadena de bloques

1000 un medio legible por ordenador

1010 una parte grabable

1020 un programa informático

1110 circuito(s) integrados(s)

1120 una unidad de procesamiento

1122 una memoria

1124 un circuito integrado dedicado

1126 un elemento de comunicación

1130 una interconexión

1140 un sistema procesador

Descripción detallada de realizaciones

Aunque esta invención es susceptible de realizaciones en muchas formas diferentes, se muestran en las figuras y se describirán en la presente divulgación en detalle una o más realizaciones específicas, y se entenderá que la presente divulgación se debe considerar como ejemplo de los principios de la invención y no pretende limitar la invención a las realizaciones específicas ilustradas y descritas.

A continuación, en aras de la comprensión, se describirán elementos de realizaciones en funcionamiento. Sin embargo, resultará evidente que los elementos respectivos están dispuestos para que lleven a cabo las funciones que se describen como realizadas por los mismos.

Además, la invención no se limita a las realizaciones y la invención se encuentra en cada una de las características novedosas o combinaciones de las mismas descritas en la presente divulgación o mencionadas en reivindicaciones dependientes diferentes entre sí.

Tal como se ha mencionado anteriormente, son necesarias medidas técnicas que dificultarán las falsificaciones. Una posible solución al problema de falsificación es incrustar una etiqueta RFID en las cartas, por ejemplo, una etiqueta de comunicación de campo cercano (NFC). Por ejemplo, la etiqueta RFID puede identificar la carta. Un lector de RFID, por ejemplo, un teléfono móvil, un lector de NFC, etc., puede leer la información de identificación en la etiqueta. Si la información de identificación en la etiqueta se corresponde con la información de identificación visualmente impresa en la carta, se puede concluir que la carta es auténtica. Esta solución dificulta la falsificación de cartas, ya que requiere la incrustación y la escritura de una etiqueta RFID, además de una reproducción visual precisa de una carta con el fin de falsificarla. Por ejemplo, se puede usar una etiqueta NFC para la etiqueta RFID. Por ejemplo, una carta de MTG puede tener su identificador único almacenado en un chip RFID incrustado en la carta. Por ejemplo, si se lee el identificador único 5d8a7f95-ac4c-4113-8bdd- 55336b86b98c, se puede determinar que este identificador corresponde a una carta con un tipo de carta que tiene lo que se conoce como identificador de multiverso 193868 y nombre "Lord of the Pit". También se podría almacenar únicamente el identificador de tipo de carta, o identificador de multiverso, pero esto evita que se agregue información específica de la carta en un servidor, tal como puntos de experiencia o el propietario de la carta. El enlace entre la carta física única y su representación digital con el identificador único se conoce como gemelo digital. Si se determina o se identifica que la carta en cuestión es una "Lord of the Pit", se puede concluir que es probable que sea auténtica. Aunque esta solución es una mejora con respecto a la carta sin un chip RFID incrustado, se observó que esta solución no es adecuada, ya que las etiquetas RFID se pueden copiar con gran facilidad.

En la Figura 1 se muestra esquemáticamente un ejemplo de una realización de un sistema de cartas 100 que aborda este problema. El sistema 100 comprende un dispositivo de autenticación de cartas 200 y un servidor de autenticación 300. El sistema también puede comprender una o más cartas. En la Figura 1 se muestra una carta 110 pero puede haber más cartas.

Por ejemplo, cuando el sistema 100 funciona, el dispositivo de autenticación de cartas 200 puede interactuar de forma inalámbrica con la carta 110. Por ejemplo, un dispositivo de autenticación de cartas 200 puede recibir un token criptográfico derivado de información de autenticación almacenada en la carta 110. El dispositivo de autenticación de cartas 200 y la carta 110 están situados uno cerca del otro, de modo que ambos dispositivos pueden comunicarse a través de una conexión inalámbrica directa. Entonces, el dispositivo de autenticación de cartas 200 puede autenticar la carta 110 con el servidor de autenticación 300. Por ejemplo, el servidor 300 puede verificar el token criptográfico. El resultado de la autenticación se puede presentar como una señal de éxito o fracaso en el dispositivo de autenticación 200. Como parte de la operación de autenticación, es posible modificar la carta 110; por ejemplo, se puede incrementar un contador y/o se pueden modificar los datos de autenticación, por ejemplo, sobre escritos.

La carta 100 comprende una memoria electrónica 120, una antena 130 y un circuito de procesamiento 140. Por ejemplo, la memoria 120, la antena 130 y el circuito 140 se pueden implementar como una etiqueta RFID, por ejemplo, una etiqueta NFC. La antena 130 está dispuesta para comunicación inalámbrica, por ejemplo, una comunicación por RF, por ejemplo, una comunicación NFC. En una realización, la comunicación inalámbrica puede ser de otro tipo, por ejemplo, Bluetooth, ZigBee, Wi-Fi, UHF, etc., pero en este momento se prefiere NFC. La carta puede recibir comandos a través de la antena 130 que el circuito 140 puede ejecutar. El circuito 140 puede ser un circuito simple, configurado únicamente para las funciones específicas de una realización, o puede ser un circuito de propósito general programado en consecuencia. Se puede usar NFC para la comunicación inalámbrica entre un chip en una carta 110 y un dispositivo 200.

La carta 110 puede ser una carta de papel, una carta laminada, una carta de plástico, etc., en la que se incrusta un circuito.

La memoria 120 es legible de forma inalámbrica, por ejemplo, por un dispositivo de autenticación de cartas 200. Por ejemplo, un dispositivo de autenticación de cartas 200 puede enviar un comando de lectura a la antena 130. En una realización, la memoria 120 también es grabable, por ejemplo, enviando un comando de escritura a la antena 130. Sin embargo, la escritura en la memoria 120 es opcional. Por ejemplo, la memoria 120 puede ser de solo lectura. Por ejemplo, el contenido de la memoria 120 puede establecerse durante la fabricación de la carta 110. Por ejemplo, la memoria 120 puede ser una memoria de una sola escritura. Una ventaja de las memorias no grabables es que un falsificador no puede cambiar su contenido. No obstante, como se describe más adelante, algunas realizaciones emplean memorias grabables para tener una ventaja. La memoria 120 comprende al menos datos de autenticación 122 y también un contador 124. Los datos de autenticación 122 se pueden usar en una operación de autenticación que prueba la autenticidad de la carta. Por ejemplo, los datos de autenticación 122 pueden ser un número aleatorio, por ejemplo, seleccionado al azar en el momento de fabricación o durante un operación posterior, por ejemplo, durante una operación de autenticación. Por ejemplo, un número aleatorio es un número que no se puede predecir. Por ejemplo, los datos de autenticación 122 pueden comprender una clave criptográfica, por ejemplo, una clave simétrica, por ejemplo, una clave privada de un par de claves pública y privada. El contador puede ser incrementado cuando los datos de autenticación 122 estén involucrados en una operación, por ejemplo, cuando se lleve a cabo una operación de autenticación y/o cuando se renueven los datos de autenticación. El valor inicial del contador puede ser un número por defecto, por ejemplo, cero, que puede ser el mismo para todas las cartas, por ejemplo, todas las cartas de este tipo; el valor inicial puede ser un valor aleatorio. La memoria 120 puede almacenar un identificador único o información adicional tal como el tipo de carta, por ejemplo, su identificador de multiverso.

El circuito de procesamiento puede estar configurado para recibir comandos digitales a través de la antena procedentes del dispositivo de autenticación de cartas 200. Por ejemplo, el comando puede ser un comando de autenticación que indica que la carta se debe identificar a sí misma para el dispositivo 200. En respuesta a la recepción del comando, el circuito crea un token de autenticación. La creación del token comprende la lectura de los datos de autenticación de la memoria 120 y el contador de la memoria 120 y la aplicación de una función criptográfica a los mismos. Existen varias formas en las que se puede hacer esto, algunos ejemplos de las cuales se describen a continuación. Después de la construcción del token, se transmite el token de autenticación de forma inalámbrica al dispositivo de autenticación 200, por ejemplo, a través de la antena 130. Después de la creación o de la transmisión, por ejemplo, después de una transmisión completa o exitosa, se incrementa el contador 124 en la memoria 120. Por ejemplo, el contador puede ser incrementado directamente después de la lectura de los datos de autenticación o después de la creación del token. Por ejemplo, el contador puede ser incrementado después de recibir un acuse de recibo del dispositivo 200 de que se ha recibido un token con éxito.

La memoria 120 puede almacenar información adicional relevante para la carta 110. Por ejemplo, la memoria 120 puede almacenar un identificador de carta. El identificador de carta puede estar incluido en el token de autenticación o puede ser transmitido junto con el token. Por ejemplo, el identificador de carta puede ser un número único, por ejemplo, un UUID. El identificador de carta puede ser o no ser una entrada en el cálculo del token de autenticación.

El circuito de procesamiento y la memoria pueden estar integrados en un circuito integrado IC, por ejemplo, un IC NFC. El IC puede estar incrustado en la carta. Es posible configurar el IC para que lleve a cabo operaciones criptográficas. El IC puede ejecutar instrucciones informáticas de propósito general, por ejemplo, aplicaciones, pero esto no es necesario. Por ejemplo, el IC puede estar cableado para ejecutar únicamente un conjunto limitado de operaciones. En una realización, es posible leer la memoria de forma inalámbrica. Sin embargo, en una realización, no es posible leer la memoria directamente de forma inalámbrica y solo se puede acceder a ella a través del circuito de procesamiento. Esto tiene una ventaja de seguridad, si no es posible acceder al contenido de la memoria, tampoco se puede copiar. Por ejemplo, el circuito puede estar configurado para leer la memoria, por ejemplo, los datos de autenticación, pero solo para transmitirlos después de que se haya aplicado la función criptográfica a los datos de autenticación, por ejemplo, en forma de un token de autenticación.

El dispositivo de autenticación 200 puede estar configurado para verificar la autenticidad de una carta, en particular, de la carta 110. El dispositivo de autenticación de cartas comprende una antena 220 dispuesta para comunicación inalámbrica con una carta. Por ejemplo, la antena 220 y la antena 130 pueden estar dispuestas para el mismo tipo de comunicación inalámbrica, por ejemplo, el mismo tipo de comunicación por RF, por ejemplo, el mismo tipo de comunicación de campo cercano (NFC).

Además de la antena 220, el dispositivo de autenticación 200 también puede comprender una unidad de comunicación 210 dispuesta para comunicarse a través de una red informática con el servidor de autenticación de cartas 300. Por ejemplo, la unidad de comunicación puede estar configurada para que se comunique a través de Internet. La unidad de comunicación 210 también puede ser inalámbrica, por ejemplo, estar configurada para Wi-Fi, 3G, 5G o similares. El tipo de comunicación inalámbrica de la unidad de comunicación 210 puede ser diferente del tipo de comunicación usado por las antenas 220 y 130.

El dispositivo de autenticación 200 comprende un circuito de procesamiento 230 y una memoria 240. Por ejemplo, se pueden almacenar en la memoria 240 instrucciones informáticas ejecutables por el circuito de procesamiento 230. Por ejemplo, el circuito de procesamiento 230 puede estar configurado para enviar de forma inalámbrica un comando de autenticación digital a través de la antena a la carta 110. Por ejemplo, la carta 110 puede estar dispuesta para cooperar con el dispositivo de autenticación 200 y para transmitir al menos un token de autenticación en respuesta. Por ejemplo, un circuito de procesamiento 230 puede estar configurado para recibir el token de autenticación procedente de la carta 110 en respuesta al comando de autenticación digital. El dispositivo de autenticación 200 puede estar configurado para enviar el token de autenticación al servidor de autenticación a través de la unidad de comunicación y recibir información sobre la autenticidad de la carta procedente del servidor de autenticación. Por ejemplo, el dispositivo de autenticación 200 puede recibir procedente del servidor 300 información sobre si la carta 110 es auténtica, por ejemplo, genuina, o no. El dispositivo 200 también puede recibir procedente del servidor 300 datos de autenticación actualizados a transferir al dispositivo 110.

El dispositivo de autenticación 200 puede comprender una pantalla 250 configurada para mostrar información de la operación de autenticación. Por ejemplo, el dispositivo 200 puede estar configurado para que muestre información sobre el tipo de carta, por ejemplo, recibida procedente de la carta 110 o del servidor de autenticación 300. También se puede usar la pantalla 250 para mostrar el resultado de la operación de autenticación. Antes de enviar la información del token, el dispositivo de autenticación 200 puede agregar información o modificarla. Por ejemplo, el dispositivo de autenticación 200 puede firmar el token con una clave criptográfica, por ejemplo, una clave privada, para indicarle al servidor 300 que el propio dispositivo de autenticación 200 es un dispositivo auténtico.

El servidor de autenticación 300 puede estar configurado para verificar la autenticidad de una carta, en particular, de la carta 110. El servidor de autenticación de cartas 300 también puede comprender una unidad de comunicación 320 dispuesta para comunicarse a través de una red informática con el dispositivo de autenticación de cartas 200. Por ejemplo, la unidad de comunicación 320 puede estar configurada para que use la misma red informática que el dispositivo de autenticación 200, por ejemplo, la Internet.

El servidor de autenticación comprende una memoria 310. La memoria 310 puede estar configurada para almacenar instrucciones informáticas para su ejecución por un circuito de procesamiento 330. Sin embargo, la memoria 310 también puede estar configurada para almacenar datos de autenticación 312 y un contador 314. Por ejemplo, se pueden recuperar los datos de autenticación 312 y un contador 314 de una base de datos de cartas 340. La base de datos de cartas 340 puede ser parte del servidor 300 o puede ser externa al servidor 300. Por ejemplo, la base de datos 340 puede estar almacenada en un servidor externo en comunicación digital con el servidor 300, por ejemplo, en la nube.

Por ejemplo, en la base de datos de cartas 340 se pueden almacenar datos de autenticación 312 y un contador 314 indexados con un identificador de carta, por ejemplo, el identificador de carta de la carta 110.

En una realización, se supone que el contador 314 es igual al contador 124. Una vez que se ha autenticado exitosamente la carta 110, el contador 314 es incrementado, de forma que el contador 124 y el contador 124 se mantengan iguales. Solo si se produjeran problemas o la carta 110 no fuera auténtica, el contador 314 y el contador 124 serían diferentes entre sí.

El incremento del contador 124 en la carta 110 se puede llevar a cabo con una instrucción del servidor 300. En este caso, un problema que se podría producir es que el incremento del contador 124 falle por algún motivo, por ejemplo, porque se ha retirado la carta de un campo cercano antes de que se complete la operación. En ese caso, el contador 314 puede ser mayor que el contador 124. La carta 110 puede estar configurada para incrementar el contador 124 antes de calcular el token de autenticación, para evitar que el contador 124 sea menor que el contador 314 en este escenario.

Por consiguiente, puede ocurrir que el contador en la carta y el contador en el servidor sean diferentes. Se podría aceptar una carta como auténtica si la resta del contador 314 menos el contador 124 fuera menor que un umbral para contrarrestar este problema. Por ejemplo, se podría tener la ecuación: contador 124 cant. de problemas = contador 314, por lo que se podría aceptar si la cantidad de problemas cant. de problemas = contador 314 -contador 124 fuera menor que un umbral, por ejemplo, menor que 10, menor que 100, etc. El umbral se puede determinar empíricamente como una compensación entre seguridad y facilidad de uso.

Por otro lado, por ejemplo, en una realización, el contador puede ser incrementado cuando los datos de autenticación 122 estén involucrados en una operación, por ejemplo, cuando se lleve a cabo una operación de autenticación y/o cuando se renueven los datos de autenticación; independientemente de que se verifique un token resultante en el dispositivo de autenticación o el servidor de autenticación. Este procedimiento tiene como ventaja que reduce la comunicación entre la carta y el dispositivo de autenticación, por ejemplo, no es necesario proporcionar un comando adicional a la carta para que incremente su contador, por ejemplo, después de esperar un acuse de recibo del servidor. La reducción de la comunicación también reduce la probabilidad de corrupción. Podría suceder todavía que el contador en la carta y el contador en el servidor fueran diferentes; por ejemplo, si por algún motivo el dispositivo de autenticación fallara al reenviar el token, el contador podría ser incrementado en la carta, pero no en el servidor. En esta situación, el contador en la carta podría ser mayor que el contador en el servidor. Para contrarrestar este problema, se podría aceptar una carta como auténtica si el contador 124 fuera mayor que el contador 314, por ejemplo, si la resta del contador 124 menos el contador 314 fuera menor que otro umbral. Ambas opciones pueden ser compatibles al mismo tiempo. No es necesario que ambos umbrales sean iguales. Si se acepta un token, aunque los contadores difieran, entonces se puede ajustar el contador en el servidor para que sea igual al contador en la carta.

En una realización, los datos de autenticación 124 y los datos de autenticación 314 son iguales, por ejemplo, números iguales, claves criptográficas iguales, etc. En una realización, los datos de autenticación 124 y los datos de autenticación 314 son miembros correspondientes de un par de claves criptográficas. Por ejemplo, los datos de autenticación 124 pueden ser una clave de firma y los datos de autenticación 314 pueden ser la clave de verificación correspondiente. La clave de firma y la clave de verificación pueden formar un par de claves criptográficas asimétricas, por ejemplo, un par de claves RSA, un par de claves ECDSA, etc.

El servidor de autenticación 300, por ejemplo, el circuito procesador 330, puede estar configurado para recibir un token de autenticación procedente del dispositivo de autenticación de cartas 200. La carta 110 puede crear el token de autenticación a partir de datos de autenticación 122 y, opcionalmente, del contador 124, etc. El token de autenticación se verifica con los datos de autenticación 312 y el contador 314. Si la verificación es exitosa, entonces se puede enviar una señal de éxito al dispositivo de autenticación 200. La señal de éxito puede indicar la autenticidad de la carta 110 al dispositivo de autenticación de cartas 200. Después de la autenticación exitosa de la carta, se incrementa el contador para dicha carta, por ejemplo, el contador 314 y opcionalmente, también en la base de datos. Cuando el contador no es incrementado en caso de una autenticación fallida, se evita que un atacante distorsione los contadores. En una realización, es posible recuperar el contador de un token de autenticación, aunque no es necesario.

El dispositivo de autenticación 200 y el servidor de autenticación 300 se pueden autenticar entre sí para mejorar más la seguridad. Por ejemplo, en una realización, puede haber varios dispositivos de autenticación 200 en el sistema. Por ejemplo, los dispositivos de autenticación 200 se pueden implementar como un teléfono inteligente en el que se ha instalado una aplicación adecuada. Por lo tanto, existe un riesgo de que un atacante utilice un dispositivo de autenticación falso. Es posible reducir este riesgo con la autenticación del dispositivo de autenticación 200 al servidor. Por ejemplo, en una realización, el dispositivo de autenticación de cartas 200 puede estar configurado para autenticar el servidor de autenticación de cartas 300 y/o el servidor de autenticación de cartas 300 puede estar configurado para autenticar el dispositivo de autenticación 200. Por ejemplo, el dispositivo 200 y el servidor 300 pueden estar configurados para realizar un enlace SSL.

A continuación, se proporcionan varios ejemplos de tókenes de autenticación, su creación y su autenticación.

En una realización, los datos de autenticación 122 y 312 son claves criptográficas. Por ejemplo, los datos de autenticación 122 almacenados en la carta pueden ser una clave privada (Priv) de un par de claves pública y privada, y los datos de autenticación 312 almacenados en el servidor de autenticación de cartas pueden ser la clave pública (Pub) del par de claves pública y privada. Por ejemplo, los datos de autenticación 122 almacenados en la carta pueden ser una clave simétrica (K) y los datos de autenticación 312 almacenados en el servidor de autenticación de cartas pueden ser la misma clave (K).

La carta 110, por ejemplo, el circuito 140, puede calcular el token de autenticación usando su clave en una operación criptográfica con clave. Por ejemplo, la operación criptográfica con clave puede ser una operación de firma, una operación de cifrado o una operación de hash con clave. Por ejemplo, es posible calcular el token firmando el contador. Por ejemplo, es posible calcular el token firmando un valor de desafío recibido por la carta 110 procedente del dispositivo 200, por ejemplo, junto con un comando de autenticación. El valor de desafío puede ser un valor nonce, por ejemplo, un número aleatorio. La firma se puede hacer con una clave privada y una clave simétrica; en este último caso, a veces se hace referencia a la operación como el cálculo de un código de autenticación de mensaje.

El servidor de autenticación 300 puede verificar que el token fue creado mediante la aplicación de una función criptográfica con clave a un contador y/o un desafío mediante la recreación del token a partir de los datos de autenticación 312, por ejemplo, si los datos de autenticación 312 y los datos de autenticación 122 son iguales. Por ejemplo, el servidor 300 puede aplicar la misma función criptográfica con clave, por ejemplo, una operación de firma, cifrado o hash con clave, al contador 312 y/o al desafío, y verificar que el servidor 300 calculó el mismo token que el recibido procedente de la carta 110 a través del dispositivo 200. De manera alternativa, si los datos de autenticación 312 y los datos de autenticación 122 son parte de un par de claves criptográficas, el servidor puede llevar a cabo la correspondiente función con clave usando los datos de autenticación 312 como clave. Por ejemplo, realizar una verificación de firma para verificar si el token es una firma válida del contador 312 o una operación de descifrado usando datos de autenticación 312 como clave y verificar que el resultado sea el contador 312.

En una realización, el dispositivo 200 contacta primero con el servidor 300 para solicitar un desafío. Después, el servidor 300 genera un desafío, por ejemplo, un número aleatorio, y lo envía al dispositivo 200. Luego, el dispositivo 200 envía el comando de autenticación junto con el desafío. La carta 110 aplica, a continuación, la función criptográfica al desafío, o al desafío y contador 124. Entonces, el servidor 300 puede verificar que el token corresponde al contador 314, así como al desafío.

La verificación del contador 124 es más sencilla si se requiere que el contador 124 y el contador 314 sean iguales. En la práctica, se puede aceptar una diferencia mediante la verificación del token para el contador 314 menos una cantidad de decrementos pequeños, por ejemplo, menos 1, menos 2, etc., hasta el umbral. De forma adicional o alternativa, se pueden usar incrementos, según sea necesario. Esto hace posible que una autenticación sea exitosa en el dispositivo 200 y el servidor 300, pero el incremento del contador en la carta puede fallar, etc., o si el incremento del contador en la carta tiene éxito, pero falla la autenticación en el dispositivo 200 o el servidor 300. Este enfoque puede hacer que la verificación se lleve a cabo varias veces. En una realización, la función criptográfica es una función biyectiva con clave; por ejemplo, un cifrado o una firma con recuperación de mensaje. Esto tiene como ventaja que es posible recuperar el contador 124 a partir del token mediante la aplicación de la función inversa con clave. En este caso, es posible comparar explícitamente el contador 124 y el contador 314. Esto da mayor flexibilidad para que las autenticaciones procedan incluso si el contador 124 y el contador 314 no son exactamente iguales. Además, no son necesarias verificaciones múltiples para que valores diferentes del contador cubran la eventualidad de una diferencia entre los dos contadores.

En una realización, se calcula un token, por ejemplo, como anteriormente, y lo verifica el servidor 300. Además, el servidor 300 genera y envía nuevos datos de autenticación 122 y actualiza los datos de autenticación 312. El dispositivo 200 recibe los nuevos datos de autenticación y los envía a la carta 110 para su escritura en la memoria 120. Por ejemplo, es posible escribir una nueva clave simétrica o una nueva clave privada en la memoria 120. Los nuevos datos de autenticación también se actualizan en el servidor 300, por ejemplo, los datos de autenticación 314 y/o la base de datos 340. Esto tiene como ventaja que una copia ilegal de la carta 110 tendrá los datos de autenticación viejos. Por ejemplo, en cualquier momento que se autentique una carta, se podrían renovar sus datos de autenticación, con el efecto de que todas las copias anteriores de la carta pasarían a ser inválidas. Si se intentara autenticar una copia ilegal, entonces sus datos de autenticación no se corresponderían con los datos de autenticación almacenados en el servidor 300 y, por lo tanto, la autenticación fallaría.

En una realización, se podría usar una cadena aleatoria para los datos de autenticación, sin aplicación de una función criptográfica, de forma que el token sería igual a los datos de autenticación. Si siempre se actualizaran los datos de autenticación, entonces esta sería una solución particular de bajo coste para la autenticación de cartas. Para verificar el token, el servidor 300 lo compara con los datos de autenticación almacenados.

Una ventaja de la actualización de los datos de autenticación es que se invalidan automáticamente los duplicados de la carta. Si un usuario hiciera una copia no autorizada de una carta, entonces la primera carta que se verifique con el servidor 300 sería la carta válida, al menos en cuanto a lo que puede determinar el servidor. Esto es un incentivo para no permitir que se copien las cartas, ya que si se verificara primero la copia, la original sería invalidada automáticamente.

Por ejemplo, el servidor de autenticación de cartas puede estar dispuesto para generar nuevos datos de autenticación y, si la verificación es exitosa, enviar los nuevos datos de autenticación al dispositivo de autenticación de cartas. Los nuevos datos de autenticación pueden ser una nueva clave o una nueva cadena aleatoria. El dispositivo de autenticación de cartas puede estar dispuesto para recibir los nuevos datos de autenticación a través de la unidad de comunicación y enviar los nuevos datos de autenticación a la carta a través de la antena. La carta puede estar dispuesta para recibir los nuevos datos de autenticación a través de la antena y escribir los nuevos datos de autenticación en la memoria.

En una realización, la memoria 120 puede almacenar una clave. El circuito de procesamiento 140 puede estar configurado para cifrar el contador con la clave. El token puede comprender el contador cifrado. El circuito de procesamiento 140 puede recibir un desafío procedente del dispositivo de autenticación 200. El desafío también puede estar cifrado. En lugar de un cifrado, se puede calcular una firma e incluirla en el token. La firma puede ser una firma asimétrica o una firma simétrica, por ejemplo, un MAC, por ejemplo, un hash con clave, etc. La clave puede ser una clave privada.

En una realización, en la memoria 120 se almacena la clave privada y una clave pública correspondiente. El dispositivo 200 puede recuperar la clave pública del chip. También se puede recuperar el contador. El token puede comprender, o ser, una firma en el contador y/o un desafío. El dispositivo de autenticación 200 puede usar la clave pública para verificar la firma. Por ejemplo, se puede verificar la firma a través del contador y/o el desafío. La clave pública se puede proteger con medios convencionales, por ejemplo, con un certificado firmado, tal como un certificado X.509. Curiosamente, esto permite que se verifique el token localmente, por ejemplo, con la clave leída de la carta, y no localmente, en el servidor 300 con una clave pública almacenada en el servidor 300. En una realización, los datos de autenticación en la carta 110 se actualizan solo si se verifica el token a través del servidor 300, pero no cuando se verifica localmente. Cabe destacar que la actualización de los datos de autenticación es opcional.

En una realización, antes de la autenticación de la carta 110, el dispositivo de autenticación 200 solicita un desafío al servidor 300. El servidor 300 genera el desafío y lo envía al dispositivo de autenticación 200. Entonces, el dispositivo de autenticación 200 solicita un token a la carta 110. La carta 110 puede procesar el desafío, por ejemplo, con el contador, con la clave, por ejemplo, cifrarlo o firmarlo. El token también puede comprender un identificador de la carta 110. El dispositivo de autenticación 200 puede entonces reenviar el token al servidor 300 para su verificación.

Es posible usar el sistema para almacenar uno o más parámetros de juego. Por ejemplo, un parámetro de juego se puede almacenar en la carta 110 y/o en el servidor 300. Cuando el parámetro de juego es necesario, por ejemplo, durante el juego puede ser recuperado de la carta 110 y/o en el servidor 300, por ejemplo, por un dispositivo de autenticación, por ejemplo, un teléfono móvil.

Por ejemplo, la memoria 120 puede comprender un parámetro de juego que puede mejorar el juego en varias formas. Por ejemplo, es posible modificar el parámetro de juego cuando se verifica la autenticidad de la carta. Por ejemplo, si la carta que se verifica correctamente envía un token de autenticación, entonces se puede proporcionar un parámetro de juego modificado. Por ejemplo, se puede proporcionar el parámetro de juego modificado a la carta y almacenarse en la misma. Por ejemplo, el parámetro de juego modificado se puede mostrar en una pantalla del dispositivo de autenticación. El parámetro de juego se puede almacenar en el servidor 300 de forma adicional o alternativa.

Por ejemplo, el parámetro de juego puede representar los denominados puntos de experiencia. Por ejemplo, una carta puede ganar puntos de experiencia, que pueden ser almacenados en una base de datos, por ejemplo, en el servidor 300 y/o la carta 110. Se pueden ganar puntos de experiencia jugando con la carta en un torneo. Las cartas pueden mejorar con el tiempo ganando puntos de experiencia. Esto sería un incentivo para que los jugadores participen de torneos para elevar el nivel de las cartas. Asimismo, el valor monetario de las cartas proviene del juego, no de su uso en una especie de mercado de valores.

En la Figura 2 se muestra esquemáticamente un ejemplo de una realización de un sistema de cartas 400. En la Figura 2 se muestra una carta 410. La carta 410 tiene información impresa 411 visible en la misma. La información impresa 411 puede comprender una imagen 416 y texto 414. Por ejemplo, la imagen puede ilustrar un personaje del juego y el texto puede indicar parámetros del juego, por ejemplo, habilidades, o similares.

La carta 410 puede comprender un chip 412 y una antena 413. El chip y la antena pueden estar configurados tal como se describe en la presente divulgación. Por ejemplo, la antena 413 puede estar dispuesta para comunicación inalámbrica, por ejemplo, con un dispositivo de autenticación. El chip 412 puede estar configurado para:

- recibir de forma inalámbrica un comando digital a través de la antena procedente de un dispositivo de autenticación de cartas electrónicas,

- crear un token de autenticación en respuesta a la recepción de un comando de autenticación, comprendiendo dicha creación leer los datos de autenticación y el contador de la memoria y aplicar una función criptográfica a los mismos,

- transmitir de forma inalámbrica el token de autenticación al dispositivo a través de la antena, e

- incrementar el contador almacenado en la memoria.

En la Figura 2 se muestra también un teléfono móvil 450. El teléfono móvil 450 puede estar configurado como un dispositivo de autenticación. El teléfono móvil 450 puede comprender una unidad de comunicación dispuesta para comunicarse a través de una red informática con un servidor de autenticación de cartas y una antena dispuesta para comunicación inalámbrica con una carta, tal como la carta 410.

El teléfono móvil 450, por ejemplo, una aplicación instalada en el mismo, puede estar configurado para comunicarse con el chip 412 y recibir información. La información puede comprender un identificador que identifica la carta 410. El teléfono móvil 450 puede obtener información con respecto a esta carta y/o este tipo de carta. Por ejemplo, el teléfono 450 puede obtener la información procedente del chip 412 o procedente de un servidor, por ejemplo, tal como el servidor 300. Por ejemplo, el servidor de autenticación de cartas puede estar dispuesto para enviar información con respecto a la carta para su visualización en el dispositivo de autenticación de cartas. Por ejemplo, el servidor 300 puede solicitar la información usando el identificador. El teléfono móvil 450 puede estar configurado para visualizar la información. Por ejemplo, en este caso, el teléfono 450 muestra una imagen, por ejemplo, una imagen 416, texto, por ejemplo, el texto 414, texto adicional 415. Por ejemplo, el texto adicional 415 puede comprender parámetros de juego adicionales. El teléfono 450 puede estar configurado para:

enviar de forma inalámbrica un comando de autenticación digital a través de la antena a la carta, - recibir procedente de la carta un token de autenticación en respuesta al comando de autenticación digital,

- enviar el token de autenticación al servidor de autenticación a través de la unidad de comunicación, y

- recibir información sobre la autenticidad de la carta procedente del servidor de autenticación.

Cuando se usa por primera vez una carta, tal como la carta 410 o 110, el usuario puede reclamarla. Por ejemplo, el dispositivo de autenticación, por ejemplo, 200 o 450, puede comprender un identificador de usuario que identifica un usuario de un servicio adicional del servidor de autenticación de cartas. El dispositivo de autenticación de cartas puede estar configurado para enviar el identificador de usuario con el token de autenticación. El servidor de autenticación de cartas está dispuesto para asociar el identificador de usuario con el identificador de carta en la memoria del servidor de autenticación de cartas, estando dispuesto el servidor de autenticación de cartas para proporcionar acceso a la carta en el servicio adicional. Por ejemplo, después de la fabricación de la carta 110 o 410, se puede registrar su identificador con el servidor. Inicialmente, la carta se puede registrar como no reclamada. Cuando se recibe el token para la carta y es verificado, el servidor puede almacenar un identificador de usuario recibido con el token como el propietario o reclamante de la carta. Por ejemplo, un consumidor puede escanear una carta después de abrir un paquete con el fin de reivindicar su propiedad, por ejemplo, con su teléfono inteligente. El vendedor inicial, tal como el fabricante o un comerciante, puede ser el primer propietario de la carta. En este caso, el vendedor tiene que transferir la propiedad al comprador de la carta. Esto se puede vincular con una caja registradora o con una tienda de comercio electrónico en línea. La tienda puede ser la propietaria actual y después del pago, se transferiría la propiedad o se liberaría el estado de propietario bloqueado, de modo que alguien, por ejemplo, el comprador, podría reclamar la propiedad.

Cuando un usuario adquiere la carta procedente de un propietario anterior, puede enviar un token con el nuevo identificador de usuario para registrar el nuevo usuario o reclamante de la carta. Esto permite que los usuarios manejen su colección de cartas en línea, por ejemplo, a través de un sitio web mantenido por el servidor 300. También permite que el sistema rastree robos, marque una carta como perdida o fije un bloqueo de transferencia en una carta. Por ejemplo, se podría implementar un bloqueo de transferencia almacenando, por ejemplo, en el servidor 300, una lista negra de identificadores de cartas que no se deben transferir. Por ejemplo, si se roba una carta, se puede informar como tal a través de la colección en línea, por ejemplo, el sitio web. Si se recibiera un reclamo de propiedad de la carta, se podría generar una señal para que se pueda tomar una acción adecuada en consecuencia, por ejemplo, requerir que el nuevo propietario se identifique legalmente. En función de la configuración, pueden existir requisitos diferentes para la transferencia de propiedad digital de la carta. Un ejemplo es que el acceso físico a una carta lleve a la transferencia de propiedad, de forma que se pueda usar un token de autenticación para validar la operación. Otro ejemplo es que solo se requiera la propiedad digital para transferir la propiedad. El último ejemplo es que sean necesarias tanto la propiedad física como la digital para la transferencia de la propiedad.

Curiosamente, esto hace posible que un usuario vincule su colección física de cartas con una colección de cartas en línea, a lo que también se hace referencia como “gemelos digitales”. Por ejemplo, el escaneo de una carta con NFC y la transferencia de la propiedad la agrega a la colección en línea de un individuo. Esto puede hacer posible que se juegue un juego tanto en línea como fuera de línea con las cartas que se poseen. Por ejemplo, el servidor 300 puede estar dispuesto para un juego en línea entre dos o más jugadores usando sus colecciones de cartas en línea. Fuera de línea los mismos o diferentes usuarios pueden usar sus cartas físicas para jugar al mismo juego o diferente. Curiosamente, el juego en línea puede permitir que se alteren los parámetros de juego. Cuando se verifica una carta, se puede descargar un parámetro de juego alterado en la carta. Es posible usar un dispositivo de autenticación, por ejemplo, un teléfono móvil, para grabar y/o leer el parámetro de juego. Esto permite el juego fuera de línea usando un parámetro de juego que se alteró mediante el juego en línea. Por ejemplo, el nivel de una carta puede aumentar en línea, lo que puede beneficiar a un usuario fuera de línea cuando usa la carta física, por ejemplo, de papel.

Por ejemplo, el servidor de autenticación de cartas puede mantener una colección de cartas para múltiples usuarios, por ejemplo, jugadores, por ejemplo, en una base de datos en la que se almacenan cartas que han sido autenticadas para un usuario. El servidor puede ofrecer servicios adicionales en varias formas, por ejemplo, el servidor puede proporcionar una interfaz de juego digital configurada para recibir una instrucción de juego que hace referencia a una carta del usuario. Por ejemplo, la instrucción puede ser un movimiento de juego, por ejemplo, recibido del usuario, o de otro usuario. La instrucción puede hacer referencia a una carta de dicho usuario con algunos fines vinculados con el juego. Antes de permitir que se complete la instrucción, por ejemplo, para llevar a cabo un objetivo del juego, el servidor de autenticación de cartas puede verificar que la carta a la que se hace referencia ha sido autenticada para el usuario, por ejemplo, con referencia a la base de datos. El servidor puede operar esta interfaz para su propio fin, por ejemplo, si el servidor también está configurado como un servidor de juego. Sin embargo, el servidor puede llevar a cabo también o alternativamente este servicio para servidores de juegos de terceros. Esta característica hace posible que el juego en línea refleje los juegos que se pueden jugar en la vida real, por ejemplo, con las mismas cartas.

Un posible problema con la actualización de cartas inalámbrica, especialmente si la carta no tiene su propia fuente de alimentación, es la corrupción de la fecha de la carta. Se puede afrontar este problema con una memoria de carta que comprende al menos dos áreas para almacenar datos de autenticación. Estando dispuesto el procesador de la carta para grabar los datos de autenticación en la memoria en un área diferente del área en la que se almacenan los datos de autenticación usados para generar el token de autenticación. Esto garantiza que los datos de autenticación que se usaron para crear un token de forma válida, y que, por lo tanto, no están corruptos, siguen siendo válidos y se mantienen en la carta. Una vez posterior en la que sea necesario un token, se usarán los datos actualizados, de forma que los datos de autenticación viejos serán sobrescritos. Por ejemplo, las áreas pueden incluir los contadores, de manera que inicialmente se use el contador más alto para generar el token, solo si los datos están corruptos o el token resulta ser inválido se crea un token con los datos más antiguos.

Otro problema posible es que alguien puede intentar reclamar la propiedad de una carta sin comprarla, por ejemplo, mientras se encuentra en la tienda, por ejemplo, para reclamarla como el primer propietario. Alguien podría hacer esto para agregar la carta a una colección en línea sin tener que comprarla, por ejemplo, para favorecer una jugada en un juego en línea, o quizás para molestar. Existen varias formas en las que este problema puede ser afrontado.

Por ejemplo, se puede envolver la carta en un sobre, por ejemplo, como parte de un paquete. El sobre puede ser un sobre metálico o puede estar revestido con un material metálico para atenuar la señal inalámbrica hacia y procedente de la antena de la carta.

Por ejemplo, un paquete de cartas puede comprender, además de una o más cartas, una carta adicional, comprendiendo dicha carta adicional una antena dispuesta para comunicación inalámbrica y un circuito de procesamiento dispuesto para distorsionar la señal inalámbrica de la una o más cartas.

Por ejemplo, una carta puede tener como propietario el comerciante que vende la carta. Al hacer la compra, el comerciante debe modificar el propietario de la carta, de forma que su comprador puede reclamarla, porque no está protegida por propiedad alguna, o el comerciante tiene que transferir digitalmente la propiedad de la carta a su comprador. El comprador comunicaría su identificador de jugador al vendedor, por ejemplo, tecleando un código, escaneando un código QR o mediante transferencia inalámbrica con 3G, Wi-Fi o NFC. Entonces, se usa el código para enviar una solicitud al servidor 300, el que actualizará el propietario de la carta.

De manera alternativa, se puede usar un código único, impreso en el interior del paquete o impreso en una carta o tarjeta incluida en el paquete para establecer el propietario de la carta.

En la Figura 3a se muestra esquemáticamente un ejemplo de una realización de una cadena de bloques 500. Se muestran dos bloques de la cadena de bloques: bloque 510 y bloque 520. El bloque comprende una o más transacciones. Se muestran las transacciones 511, 512, 521 y 522 en los bloques 510 y 520, respectivamente. Los bloques también comprenden una prueba de consenso 519 y 529, respectivamente. Un dispositivo de cadena de bloques procesa la prueba de consenso y puede ser, por ejemplo, una prueba de trabajo, una prueba de participación o similares. Las transacciones pueden indicar el reclamo de la propiedad y/o la transferencia de una carta. Una transacción puede indicar una autenticación de una carta.

En la Figura 3b se muestra esquemáticamente un ejemplo de una realización de una red de cadenas de bloques 530. La red de cadenas de bloques 530 comprende dispositivos de cadena de bloques. Se muestran los dispositivos de cadena de bloques 531, 532 y 533. Por ejemplo, una red de cadenas de bloques 530 puede ser una red de igual a igual, en la que se comunican los bloques de la cadena de bloques, las transacciones, etc. Por ejemplo, un dispositivo de autenticación, por ejemplo, el dispositivo 200, 450, etc., o el servidor pueden generar una transacción de cadena de bloques que comprende el identificador de carta y transmitir la transacción de cadena de bloques a una red de cadenas de bloques, de manera que un dispositivo de gestión de cadena de bloques procese la transacción para inclusión en un bloque de la cadena de bloques. La transacción puede comprender el token de autenticación. A menudo se hace referencia a un dispositivo de cadena de bloques como un minero.

En una realización, se puede almacenar una clave pública de una carta en la cadena de bloques, mientras que la clave privada se carga en el chip. Esto se puede hacer cuando se fabrica la carta o cuando se reclama la propiedad de la carta por primera vez, etc. La cadena de bloques puede tomar el lugar de la base de datos 340.

Guardar cartas o transacciones de cartas en la cadena de bloques evita hackeos en el lado del servidor. Por ejemplo, es posible comprobar la ascendencia/historia de la transacción para una transacción. Asimismo, transferir una carta dos veces se vuelve mucho más difícil, dado que se puede verificar en la cadena de bloques quién es el propietario de una carta. En última instancia, los jugadores podrían cubrir el coste de alojar los dispositivos de cadena de bloques. Por ejemplo, un minero de cadenas de bloques podría recibir como compensación puntos que se podrían intercambiar por sobres de minería exclusivos.

En una realización de un método o sistema de cartas, se pueden llevar a cabo una o más de las siguientes acciones:

1. Crear un comando de impresión.

a. Crear un nuevo par de claves, por ejemplo, un par de clave pública y clave privada. Crear un identificador de carta. El identificador de carta puede ser el hash de la clave pública. Firmar el nuevo identificador de carta con una clave privada de una autoridad de cartas. En lugar de un par de claves, se puede usar una clave simétrica. Por ejemplo, se podría almacenar en la carta una clave privada, el identificador de carta. También se podría almacenar la clave pública en la carta para hacer posible la verificación local. La clave pública y el identificador de la carta se pueden almacenar en una base de datos.

b. Las cartas se imprimen con un chip NFC incrustado.

c. La clave pública se puede almacenar en una cadena de bloques o base de datos, etc.

i. Por ejemplo, se puede almacenar cada clave única en una base de datos enriquecida con los datos de la carta.

2. Enviar el comando de impresión y las claves a las imprentas.

3. Cargar la clave privada en el chip, por ejemplo, un chip NFC, incrustado en la carta física. Las cartas terminadas pueden contener un chip NFC con una clave privada única almacenada en la carta y una clave pública correspondiente almacenada en una base de datos.

4. Empaquetar, distribuir y/o vender cartas a consumidores.

5. Reclamar una carta no reclamada, por ejemplo, enviar un comando a la carta para obtener una firma digital, por ejemplo, Sig=sign(private key, message). El mensaje puede comprender un contador y/o un desafío.

6. Verificar la firma digital usando la cadena de bloques correspondiente. La clave pública se puede obtener localmente de la carta, un servidor y una cadena de bloques. Verify(publickey, message, sig) para verificar la autenticidad. Si se tuviera éxito, se podría reclamar la carta. La verificación se puede llevar a cabo en un servidor o en un dispositivo de autenticación.

7. Enviar una respuesta de éxito a la aplicación. La transacción se puede almacenar en la cadena de bloques. Se puede generar y cargar (esto es opcional) una nueva clave privada y pública. Por ejemplo, se puede sobrescribir la clave privada existente en el chip con una nueva clave privada. La transferencia de una carta puede seguir el mismo procedimiento.

Usualmente, cada una de las cartas, los dispositivos de autenticación y los servidores comprende un microprocesador que ejecuta un software adecuado almacenado en el dispositivo. Por ejemplo, ese software se puede haber descargado y/o almacenado en una memoria correspondiente, por ejemplo, una memoria volátil tal como una memoria RAM o no volátil tal como una memoria flash. De manera alternativa, los dispositivos, especialmente las cartas, se pueden implementar, en su totalidad o en parte, como un denominado circuito integrado de aplicación específica (ASIC), por ejemplo, un circuito integrado (IC) adaptado para su uso particular. Por ejemplo, los circuitos se pueden implementar en CMOS, por ejemplo, usando un lenguaje de descripción de hardware tal como Verilog, VHDL, etc.

En una realización, la carta, el dispositivo de autenticación y/o el servidor pueden comprender uno o más circuitos de procesamiento para implementar su funcionalidad. Los circuitos pueden ser un circuito de procesador y un circuito de almacenamiento, ejecutando el circuito de procesador las instrucciones representadas electrónicamente en los circuitos de almacenamiento.

Un circuito de procesador se podría implementar en una forma distribuida, por ejemplo, como múltiples circuitos sub procesadores. Un almacenamiento podría estar distribuido en múltiples sub almacenamientos distribuidos. Parte o la totalidad de la memoria podría ser una memoria electrónica, una memoria magnética, etc. Por ejemplo, el almacenamiento podría tener una parte volátil y una parte no volátil. Parte del almacenamiento puede ser de solo lectura. Los circuitos también pueden ser FPGA, ASIC o similares.

En la Figura 4 se muestra esquemáticamente un ejemplo de una realización de un método de autenticación de cartas 600. El método 600 comprende

- enviar de forma inalámbrica (610) un comando digital a través de una antena al dispositivo de autenticación de cartas para provocar que la carta cree un token de autenticación, comprendiendo la carta una memoria electrónica (120) en la que se almacenan datos de autenticación (122) y un contador (124), y la creación del token de autenticación comprende aplicar una función criptográfica a los datos de autenticación y al contador,

- recibir de forma inalámbrica (620) el token de autenticación procedente del dispositivo a través de la antena,

- hacer que se verifique el token de autenticación (630) con el contador y los datos de autenticación almacenados en la memoria de un servidor de autenticación de cartas.

Son posibles muchas formas diferentes de ejecución del método, tal como resultará evidente a un experto en la técnica. Por ejemplo, los pasos se pueden llevar a cabo en el orden ilustrado, pero se puede modificar el orden de los pasos o algunos pasos se pueden ejecutar en paralelo. Asimismo, se pueden insertar otros pasos del método entre pasos. Los pasos insertados pueden representar refinaciones del método, tal como se describe en la presente divulgación, o pueden no estar relacionados con el método.

Las realizaciones del método se pueden ejecutar usando un software que comprende instrucciones para hacer que un sistema procesador lleve a cabo el método 600. El software puede incluir solo los pasos realizados por una subentidad particular del sistema. El software se puede almacenar en un medio de almacenamiento adecuado, tal como un disco duro, un disquete, una memoria, un disco óptico, etc. El software se puede enviar como una señal a lo largo de un cable, o de forma inalámbrica o usando una red de datos, por ejemplo, la Internet. El software se puede poner a disposición para descarga y/o para uso remoto en un servidor. Las realizaciones del método se pueden ejecutar usando un flujo de bits dispuesto para configurar una lógica programable, por ejemplo, una matriz de puertas programables en campo (FPGA), para realizar el método.

Se observará que la invención también se extiende a programas informáticos, particularmente, programas informáticos en un portador adaptado para poner en práctica la invención. El programa puede estar en forma de código fuente, código objeto, una fuente intermedia de código y un código objeto como forma parcialmente compilada, o en cualquier otra forma adecuada para su uso en la implementación de una realización del método. Una realización relacionada con un producto de programa informático comprende instrucciones ejecutables por ordenador correspondientes a cada uno de los pasos de procesamiento de al menos uno de los métodos establecidos. Estas instrucciones se pueden subdividir en subrutinas y/o almacenar en uno o más archivos que se pueden vincular estadística o dinámicamente. Otra realización relacionada con un producto de programa informático comprende instrucciones ejecutables por ordenador correspondientes a cada uno de los medios de al menos uno de los sistemas y/o productos establecidos.

En la Figura 5a se muestra un medio legible por ordenador 1000 que tiene una parte grabable 1010 que comprende un programa informático 1020, comprendiendo el programa informático 1020 instrucciones para implementar una carta, dispositivo de autenticación y/o servidor en un sistema procesador de acuerdo con una realización. El programa informático 1020 puede estar en el medio legible por ordenador 1000 como marcas físicas o mediante la magnetización del medio legible por ordenador 1000. Sin embargo, también es concebible cualquier otra realización adecuada. Asimismo, se observará que, aunque el medio legible por ordenador 1000 se ilustra como un disco óptico, el medio legible por ordenador 1000 puede ser cualquier medio legible por ordenador, tal como un disco duro, una memoria de estado sólido, una memoria flash, etc., y puede ser grabable o no grabable. El programa informático 1020 comprende instrucciones para hacer que el sistema procesador actúe como una carta, un dispositivo de autenticación y/o un servidor.

En la Figura 5b se muestra una representación esquemática de un sistema procesador 1140 de acuerdo con una realización de una carta, un dispositivo de autenticación y/o un servidor. El sistema procesador comprende uno o más circuitos integrados 1110. La arquitectura de uno o más circuitos integrados 1110 se muestra esquemáticamente en la Figura 5b. El circuito 1110 comprende una unidad de procesamiento 1120, por ejemplo, una CPU, para ejecutar componentes de programa informático para realizar un método de acuerdo con una realización y/o implementar sus módulos o unidades. El circuito 1110 comprende una memoria 1122 para almacenar datos, código de programación, etc. Parte de la memoria 1122 puede ser de solo lectura. El circuito 1110 puede comprender un elemento de comunicación 1126, por ejemplo, una antena, conectores o ambos, y similares. El circuito 1110 puede comprender un circuito integrado dedicado 1124 para llevar a cabo la totalidad o parte del procesamiento definido en el método. El procesador 1120, la memoria 1122, el IC dedicado 1124 y el elemento de comunicación 1126 pueden estar conectados entre sí mediante una interconexión 1130, como un bus. El sistema procesador 1110 puede estar dispuesto para comunicación por contacto y/o sin contacto, con una antena y/o conectores, respectivamente.

Por ejemplo, en una realización, el sistema procesador 1140, por ejemplo, la carta, el dispositivo de autenticación o el servidor de autenticación, puede comprender un circuito de procesador y un circuito de memoria, estando dispuesto el procesador para ejecutar software almacenado en el circuito de memoria. Por ejemplo, el circuito de procesador puede ser un procesador Core i7 Intel, ARM Cortex-R8, etc. En una realización, el circuito de procesador puede ser ARM Cortex M0. El circuito de memoria puede ser un circuito ROM o una memoria no volátil, por ejemplo, una memoria flash. El circuito de memoria puede ser una memoria volátil, por ejemplo, una memoria SRAM. En este último caso, el dispositivo puede comprender una interfaz de software no volátil, por ejemplo, un disco duro, una interfaz de red, etc., dispuesta para proporcionar el software.

En la Figura 6 se muestra esquemáticamente un ejemplo de una realización de un sistema de cartas 600. Además, en la Figura 6 se visualiza el reclamo de un artículo, por ejemplo, el reclamo de propiedad del artículo.

El sistema 600 comprende múltiples cartas. Se muestra una carta 610. La carta 610 puede tener información impresa en la misma. Se muestra una carta cuyo nombre es 'nombre de la carta 1' y una imagen. La carta 610 comprende una etiqueta electrónica 612. La etiqueta 612 puede almacenar un identificador de carta, por ejemplo, un número o similar. En una realización alternativa, se puede usar un identificador legible por ordenador, por ejemplo, un código QR o similar. Sin embargo, se puede simplemente reutilizar un código<q R ,>por lo que no se prefiere.

El sistema 600 comprende un dispositivo de escaneo móvil 620, por ejemplo, un dispositivo de autenticación de cartas. El sistema 600 comprende una plataforma de autenticación 630, por ejemplo, un servidor de autenticación de cartas. El dispositivo de escaneo móvil 620 está configurado para leer la etiqueta 612 y comunicarse con la plataforma de autenticación 630. Por ejemplo, la plataforma de autenticación 630 puede estar configurada para almacenar información relacionada con las cartas, por ejemplo, la carta 610. Por ejemplo, en la plataforma de autenticación 630 se pueden almacenar registros de identificador y artículo. En la plataforma de autenticación 630 también se puede almacenar información sobre propiedad, por ejemplo, un identificador de un usuario que actualmente es propietario de una carta en particular, por ejemplo, quien la reclamó más recientemente.

En la Figura 6 se muestra que el dispositivo de escaneo móvil 620 y la plataforma de autenticación 630 están configurados para dos protocolos. Un protocolo para verificar la autenticidad de la carta 610 y un protocolo para reclamar la propiedad de la carta 610.

En la Figura 7 se muestra esquemáticamente un ejemplo de una realización de un sistema de cartas 600 en más detalle, en particular se muestra un ejemplo de una realización del protocolo para verificar la autenticidad de la carta 610. En respuesta a una solicitud procedente del dispositivo de escaneo móvil 620 para verificar la autenticidad de la carta 610, la plataforma de autenticación 630 puede generar una página web que se puede descargar de la plataforma de autenticación 630 mediante la solicitud de una dirección de red informática particular, por ejemplo, una dirección web, por ejemplo, una URL. Por ejemplo, se puede generar una URL de prueba en respuesta a la solicitud. Cuando se visita la URL, por ejemplo, con un navegador web, se puede obtener el estado de la carta.

Se muestran tres respuestas posibles en la figura 7. Por ejemplo, de acuerdo con la página web 641, la página contiene la información de si la carta es auténtica, por ejemplo, incluida en la base de datos del servidor 630. La información adicional puede ser cuándo se validó la carta.

Opcionalmente, un enlace de prueba, tal como la URL a la página web 641, puede ser válido durante un tiempo limitado. Aunque en la página 641 se muestra cuándo se comprobó la autenticidad por última vez, algunos consumidores pueden no tener en cuenta este punto y así abrir una ventana para transacciones fraudulentas. Un enlace de prueba a esta opción solo es válido durante un tiempo limitado. Por ejemplo, en la página web 642 se muestra que el enlace de prueba caducó. Por ejemplo, de acuerdo con la página web 643, el enlace puede no ser válido. Por ejemplo, se puede mostrar esta página cuando no fue posible autenticar la carta.

Por consiguiente, en esta realización, se pueden generar enlaces de prueba, por ejemplo, la generación de un enlace posiblemente temporal, por ejemplo, una URL, basada en un escaneo de la carta y con lo que se podrían probar la autenticidad y el acceso físico.

Por ejemplo, en una realización, un usuario podría escanear su carta con su teléfono móvil y recibir un enlace de prueba en respuesta. Entonces, se podría enviar el enlace de prueba, por ejemplo, una URL, a otra persona, por ejemplo, a través de una aplicación de chat, aplicación de mercado, correo electrónico o similar. Por ejemplo, se podría incluir el enlace cuando se hace referencia a la carta en línea, tal como en una página web, por ejemplo, el enlace se podría incluir cuando se pone la carta a la venta en eBay o similar.

El otro usuario podría verificar la información, por ejemplo, la autenticidad de la carta por sí mismo. Por ejemplo, esto se podría usar durante la negociación de una venta, durante un juego o similar.

En una realización, el sistema está configurado para un método para comprobar de forma remota la posesión física de un artículo físico, tal como una carta. Por ejemplo, escanear una carta y obtener un código único procedente del servidor de autenticación. El código se puede verificar en el servidor. El código único puede comprender una dirección de red informática, por ejemplo, una URL, aunque no es necesario. Se puede enviar el código único o URL a un tercero, por ejemplo, una contraparte, otro dispositivo o al mercado en línea. Es posible comprobar este token para probar si alguien tuvo físicamente el producto y, opcionalmente, cuándo. El mercado se basa en el registro de propiedad de artículos físicos autenticados como cartas. El mercado se puede implementar en un servidor o una nube, etc., como una entidad hacia y desde la cual enviar mensajes a través de una red informática. Por ejemplo, el mercado puede comprender un ordenador. Por ejemplo, el mercado puede comprender un servidor web. El mercado puede estar integrado en, por ejemplo, comprendido en, el servidor de autenticación.

En una realización, se proporciona un sistema en línea en el que las personas registran artículos que poseen y que se pueden verificar con un método de autenticación. En el mercado, se puede considerar a los propietarios como vendedores potenciales, ya que tienen artículos que pueden vender si el precio o las circunstancias son correctas. Por ejemplo, cada vez que un propietario escanea o verifica el artículo, se puede actualizar un campo con la última vez que alguien interactuó con el mismo y en qué momento el propietario actual interactuó con el mismo.

Los compradores que deseen comprar un tipo determinado de producto pueden consultar el servidor, que tiene todos los artículos registrados. El comprador puede indicar un rango de precio y una distancia en el mercado. Entonces, el mercado encontrará vendedores potenciales. Los resultados de la consulta se pueden calificar basándose en uno o más de los siguientes parámetros:

- la proximidad o distancia entre el comprador y el vendedor potencial,

- el tiempo desde la última vez que el vendedor potencial interactuó con el artículo,

- el tiempo desde la primera vez que el vendedor potencial interactuó con el artículo,

- el tiempo desde la primera vez que el vendedor potencial se convirtió en el propietario registrado del artículo,

- la cantidad de veces que el vendedor potencial ha respondido a una oferta por un artículo,

- la cantidad de veces que el vendedor potencial aceptó una oferta por un artículo,

- el porcentaje de ofertas aceptadas por el vendedor potencial,

- la última vez que el vendedor potencial estuvo activo en el mercado, por ejemplo, usando una aplicación o sitio web,

- si el sistema lo conoce, el precio que el vendedor potencial pagó por el artículo,

- si el sistema lo conoce, el precio de venta histórico del artículo,

- si el sistema lo conoce, el precio de venta actual del artículo,

- si el sistema lo conoce, el precio de mercado actual del artículo,

- si se hubiera fijado, el precio de venta que el vendedor potencial indicó para el artículo.

El mercado puede agregar vendedores potenciales a una lista. Se pueden agregar periódicamente nuevos vendedores potenciales a esta lista mientras que la consulta se encuentre activa. El comprador puede indicar manualmente interés en un vendedor específico de los presentados en la lista de vendedores potenciales. Luego, el vendedor puede recibir una notificación, por ejemplo, una notificación push, un correo electrónico, etc., del mercado que indique que alguien está interesado en comprar uno de sus artículos. Si el vendedor indica que también tiene interés en vender, el comprador y el vendedor pueden ya sea:

- negociar manualmente para discutir el estado del artículo y los términos del acuerdo o

- aceptar el acuerdo y recibir información sobre envío y pago.

Es posible configurar el mercado para encontrar automáticamente en paralelo los vendedores potenciales con calificaciones más elevadas y notificar sobre el interés en ellos. Puede haber una cantidad máxima de ofertas pendientes simultáneas, por ejemplo, configurada para paralelismo. Se podría revisar periódicamente la lista de ofertas pendientes para determinar ofertas caducadas. Si aún no se hubiera llegado al paralelismo máximo, el mercado agregará la oferta con la calificación más elevada siguiente a la lista actual.

Al aceptar un trato, el sistema actualiza el campo de propietario del artículo. A partir de ese momento, el comprador es el propietario registrado del artículo.

Es posible configurar el mercado con un sistema de recomendación de gemelos digitales, artículos coleccionables, etc. Por ejemplo, se puede configurar el mercado con un algoritmo informático que analiza los gemelos digitales registrados por usuarios de propietarios de artículos físicos de una base de datos o un subconjunto de gemelos digitales y propietarios para detectar la pertenencia a una clase latente o no latente del objeto con el fin de recomendar otros objetos, como cartas, que se deben adquirir para completar un conjunto manifiesto de objetos, como una lista de mazos o la expansión de un juego, o una clase latente, como cartas sinérgicas que se asocian frecuentemente entre sí. Un ejemplo de clase latente serían "Brainstorm" y "Fetchlands", aunque no están directamente relacionados entre sí, la adquisición de "Brainstorm", que es una sinergia conocida en el juego de cartas Magic: the Gathering beneficiaría a los propietarios de "Fetchlands". El sistema de recomendación cuantifica otras sinergias no evidentes. Se mapean las asociaciones detectadas con los artículos relacionados en una base de datos y se recomiendan al usuario si ya fuera propietario de parte del conjunto. Cuanto más del conjunto poseyera, más elevada sería la clasificación de la carta en el orden de recomendaciones.

En la Figura 8a se muestra esquemáticamente un ejemplo de un modelo de datos de una realización de una aplicación de mercado. En la Figura 8b se muestra esquemáticamente un ejemplo de un diagrama de proceso de una realización de la aplicación de mercado. Curiosamente, debido a que los artículos tienen un propietario, la aplicación de mercado tiene información que indica quién es el propietario de una carta en particular. El mercado permite que un posible comprador de una carta pregunte a los propietarios si quieren venderla.

Por ejemplo, la calificación se puede dar con base en la información indicada en la figura 8a, pero también en la ubicación, por ejemplo, ubicación en GPS, por ejemplo, distancia, y una calificación de usuario como comprador y/o vendedor. Es posible guardar la lista de artículos que están disponibles junto con su calificación. Los vendedores potenciales pueden ser notificados en paralelo, por ejemplo, con un máximo, por ejemplo, un máximo de 5 a la vez. Estas ofertas se pueden aceptar, se pueden rechazar, pueden caducar o se puede iniciar una negociación, etc. La lista de órdenes activas se puede actualizar cada vez que no se llega al paralelismo máximo.

En la Figura 8b se muestra un ejemplo del proceso de búsqueda, aceptación y ejecución de un acuerdo en una realización de la aplicación de mercado. En una realización, la aplicación de mercado mantiene una cola de consultas activas. Por ejemplo, un comprador puede empezar por crear una consulta en el mercado. La consulta se puede agregar a una lista de consultas activas en el mercado, por ejemplo, la cola de consultas activas. La cola de consultas activas se puede ejecutar periódicamente y/o como una respuesta al agregado de una consulta a la cola, y/o al uso de un corredor de colas de tareas. La consulta activa se puede ejecutar con respecto al sistema con parámetros que puede fijar el usuario, por ejemplo, con base, por ejemplo, en una carta, una distancia, un precio, etc. Por ejemplo, cada resultado puede tener una calificación y se puede agregar a una oferta vinculada a la consulta.

Las ofertas con la calificación más elevada agregadas a una consulta se pueden activar y presentar al propietario del artículo asociado con la oferta. Se hace referencia a esta persona como un vendedor potencial. Por ejemplo, esto se puede llevar a cabo mediante un proceso diferente, el que se puede ejecutar periódicamente en respuesta al agregado de una oferta a una consulta, en respuesta al rechazo de otra oferta y/o con el uso de un corredor de colas de tareas, etc. En una realización, la cantidad máxima de ofertas simultáneamente activas se puede limitar, por ejemplo, para reducir la cantidad de órdenes aceptadas o realizadas que se presentan a los vendedores potenciales. Si un vendedor recibe demasiadas ofertas que no puede aceptar porque ya fueron aceptadas por alguien más, es posible que el vendedor potencial considere que las notificaciones son menos valiosas e incluso puede sentirse decepcionado y no responder a las ofertas.

Cuando se activa una oferta, se envía una notificación al vendedor potencial. Esta notificación puede ser una notificación push, un correo electrónico, un SMS, etc. El vendedor potencial puede abrir la oferta en el mercado con una aplicación o una aplicación web. El vendedor potencial puede tener varias opciones para responder a esta oferta. Por ejemplo, sus opciones pueden incluir uno o más de:

- el vendedor potencial puede aceptar la oferta. La propiedad del artículo se puede transferir directamente o cuando se ha confirmado el pago, de acuerdo con los términos usados para la transacción. Si el comprador pagó de forma anticipada por el artículo, una vez que se conozcan los detalles de pago del comprador o cuando el comprador tenga suficiente crédito en su cuenta, se debe confirmar inmediatamente el pago;

- el vendedor potencial puede rechazar la oferta y fijar las condiciones en las que estaría interesado en vender. Esto puede ser un precio mínimo, una distancia o que no desee vender. Esta información se usará después en consultas posteriores;

- el vendedor potencial puede comenzar una negociación. Esto no es un resultado permanente, pero permitirá que ambas partes establezcan términos y condiciones y luego acepten o rechacen la oferta.

Si el vendedor potencial no responde en un plazo de tiempo determinado, la oferta se puede marcar como "caducada". La relación o cantidad de ofertas caducadas se puede usar para mejorar los resultados de emparejamiento en el futuro. Si otro vendedor potencial aceptara una oferta de una consulta, todas las otras ofertas de esa consulta se marcarían como "aceptada". Este estado no penaliza al vendedor potencial en el algoritmo de calificación y emparejamiento.

Si el comprador decide cancelar su consulta, todas las ofertas abiertas se marcarán como "cancelada". Este estado no penaliza al vendedor potencial, pero puede penalizar al comprador en el algoritmo de calificación y emparejamiento. Un ejemplo puede ser la limitación de la cantidad de ofertas abiertas simultáneamente para una consulta.

En la Figura 9a se muestra esquemáticamente un ejemplo de una realización de una carta. Por ejemplo, la etiqueta puede estar incrustada en la carta.

La tecnología descrita en la presente divulgación para la carta también se puede aplicar a otros objetos físicos. En la Figura 9b se muestra esquemáticamente un ejemplo de una realización de un archivador para cartas. Por ejemplo, una etiqueta como la usada en una carta se puede incrustar en una cubierta, por ejemplo, una cubierta delantera o una cubierta interna, etc. Esto permite la verificación o la transferencia de archivadores de cartas. Se podría escanear una carpeta con la misma tecnología. En la Figura 10 se muestra esquemáticamente un ejemplo de una realización de un zapato, en este caso, una zapatilla deportiva, con una etiqueta incrustada en este. Todas las realizaciones descritas para cartas se podrían modificar para zapatillas deportivas o archivadores.

Se debería tener en cuenta que las realizaciones anteriormente mencionadas ilustran, en lugar de limitar, la invención y los expertos en la técnica podrán diseñar muchas realizaciones alternativas.

En las reivindicaciones, cualesquiera indicaciones de referencia entre paréntesis no se deben interpretar como limitantes de la reivindicación. El uso del verbo 'comprender' y sus conjugaciones no excluye la presencia de elementos o pasos diferentes de los mencionados en una reivindicación. Los artículos "el" o "la" antes de un elemento no excluyen la presencia de una pluralidad de dichos elementos. Las expresiones como "al menos uno de" antes de una lista de elementos representa una selección de la totalidad o cualquier subconjunto de elementos de la lista. Por ejemplo, se debe entender que la expresión "al menos uno de A, B y C" incluye solo A, solo B, solo C, tanto A como B, tanto A como C, tanto B como C, o A, B y C. La invención se puede implementar mediante hardware que comprende elementos diferentes y mediante un programa informático adecuado. En el dispositivo reivindicado se mencionan varios medios, varios de los cuales pueden ser el mismo artículo de hardware. El solo hecho de que se mencionen ciertas medidas en reivindicaciones mutuamente dependientes diferentes no es indicativo de que no sea posible usar una combinación de estas medidas de forma beneficiosa.

En las reivindicaciones, las referencias entre paréntesis se refieren a señales de referencia en dibujos que ejemplifican realizaciones o a fórmulas de las realizaciones, aumentando así la inteligibilidad de la reivindicación. No se debe interpretar que estas referencias limitan la reivindicación.

Claims (21)

REIVINDICACIONES

1. Un sistema de cartas (100) dispuesto para autenticar una carta para jugar a un juego de cartas, comprendiendo el sistema de cartas una carta (110), un dispositivo de autenticación de cartas (200) y un servidor de autenticación de cartas (300), en el que

A: la carta (110) comprende

- una memoria electrónica (120) en la que se almacenan datos de autenticación (122), y un contador (124),

- una antena (130) dispuesta para comunicación inalámbrica,

- un circuito de procesamiento (140) dispuesto para

- recibir de forma inalámbrica un comando digital a través de la antena procedente del dispositivo de autenticación de cartas electrónicas,

- crear un token de autenticación en respuesta a la recepción de un comando de autenticación, comprendiendo dicha creación leer los datos de autenticación y el contador de la memoria y aplicar una función criptográfica a los mismos,

- transmitir de forma inalámbrica el token de autenticación al dispositivo a través de la antena, e

- incrementar el contador almacenado en la memoria,

B: el dispositivo de autenticación de cartas (200) está dispuesto para verificar la autenticidad de la carta, comprendiendo el dispositivo de autenticación de cartas

- una unidad de comunicación (210) dispuesta para comunicarse a través de una red informática con el servidor de autenticación de cartas,

- una antena (220) dispuesta para comunicarse de forma inalámbrica con la carta,

- un circuito de procesamiento (230) dispuesto para

- enviar de forma inalámbrica un comando de autenticación digital a través de la antena a la carta,

- recibir procedente de la carta un token de autenticación en respuesta al comando de autenticación digital,

- enviar el token de autenticación al servidor de autenticación a través de la unidad de comunicación, y

- recibir información sobre la autenticidad de la carta procedente del servidor de autenticación,

C: el servidor de autenticación de cartas (300) está dispuesto para verificar la autenticidad de la carta, comprendiendo el servidor de autenticación de cartas

- una memoria electrónica (310) para almacenar datos de autenticación y un contador,

- una unidad de comunicación (320) dispuesta para comunicarse a través de la red informática con el dispositivo de autenticación de cartas,

- un circuito de procesamiento (330) dispuesto para

- recibir el token de autenticación procedente del dispositivo de autenticación de cartas, - verificar el token de autenticación con el contador y los datos de autenticación almacenados en la memoria del servidor de autenticación de cartas, y

- si dicha verificación fuera exitosa, enviar información que indique la autenticidad al dispositivo de autenticación de cartas e incrementar el contador en la memoria del servidor de autenticación de cartas.

2. Una carta dispuesta para jugar un juego de cartas, comprendiendo dicho juego de cartas

- una memoria electrónica en la que se almacenan datos de autenticación y un contador,

- una antena dispuesta para comunicación inalámbrica,

- un circuito de procesamiento dispuesto para

- recibir de forma inalámbrica un comando digital a través de la antena procedente de un dispositivo de autenticación de cartas electrónicas,

- crear un token de autenticación en respuesta a la recepción de un comando de autenticación, comprendiendo dicha creación leer los datos de autenticación y el contador de la memoria y aplicar una función criptográfica a los mismos, y

- transmitir de forma inalámbrica el token de autenticación al dispositivo a través de la antena, - incrementar el contador almacenado en la memoria.

3. Un dispositivo de autenticación de cartas y la carta según la reivindicación 2 para verificar la autenticidad de la carta, comprendiendo el dispositivo de autenticación de cartas

- una unidad de comunicación dispuesta para comunicarse a través de una red informática con un servidor de autenticación de cartas,

- una antena dispuesta para comunicarse de forma inalámbrica con la carta,

- un circuito de procesamiento dispuesto para

- enviar de forma inalámbrica un comando de autenticación digital a través de la antena a la carta, - recibir procedente de la carta un token de autenticación en respuesta al comando de autenticación digital,

- enviar el token de autenticación al servidor de autenticación a través de la unidad de comunicación, y

recibir información sobre la autenticidad de la carta procedente del servidor de autenticación.

4. Un servidor de autenticación de cartas para verificar la autenticidad de una carta, comprendiendo el servidor de autenticación de cartas

- una memoria electrónica para almacenar datos de autenticación y un contador,

- una unidad de comunicación dispuesta para comunicarse a través de una red informática con un dispositivo de autenticación de cartas,

- un circuito de procesamiento dispuesto para

- recibir un token de autenticación procedente del dispositivo de autenticación de cartas, - verificar el token de autenticación con el contador y los datos de autenticación almacenados en la memoria del servidor de autenticación de cartas, y

- si dicha verificación fuera exitosa, enviar información que indique la autenticidad al dispositivo de autenticación de cartas e incrementar el contador en la memoria del servidor de autenticación de cartas.

5. Una carta, un dispositivo de autenticación de cartas y/o un servidor de autenticación de cartas según una cualquiera de las reivindicaciones anteriores, en el que

- los datos de autenticación almacenados en la carta son una clave privada de un par de claves pública y privada, y los datos de autenticación almacenados en el servidor de autenticación de cartas es la clave pública del par de claves pública y privada, o

- los datos de autenticación almacenados en la carta son una clave simétrica y los datos de autenticación almacenados en el servidor de autenticación de cartas es la misma clave simétrica.

6. Un dispositivo de autenticación de cartas y/o un servidor de autenticación de cartas según una cualquiera de las reivindicaciones anteriores, en el que el dispositivo de autenticación de cartas está dispuesto para autenticar el servidor de autenticación de cartas.

7. Un servidor de autenticación de cartas según una cualquiera de las reivindicaciones 4 a 6, en el que el circuito de procesamiento está dispuesto para

- generar una página de información, por ejemplo, una página web, que comprende el resultado de verificar el token de autenticación,

- generar un identificador, por ejemplo, una dirección de red informática, a través de la cual se pueda acceder a la página de información a través de una red informática,

- poner el identificador a disposición del dispositivo de autenticación de cartas.

8. Una carta, un dispositivo de autenticación de cartas y/o un servidor de autenticación de cartas según una cualquiera de las reivindicaciones anteriores, en el que

- el circuito procesador del servidor de autenticación de cartas está dispuesto para

- generar nuevos datos de autenticación,

- si la verificación fuera exitosa, enviar los nuevos datos de autenticación al dispositivo de autenticación de cartas,

- el circuito procesador del dispositivo de autenticación de cartas está dispuesto para

- recibir los nuevos datos de autenticación a través de la unidad de comunicación y enviar los nuevos datos de autenticación a la carta a través de la antena,

- el circuito procesador de la carta está dispuesto para

- recibir los nuevos datos de autenticación a través de la antena y escribir los nuevos datos de autenticación en la memoria.

9. Una carta según la reivindicación 8, en el que

- la memoria comprende al menos dos áreas para almacenar datos de autenticación, estando dispuesto el procesador de la carta para grabar los datos de autenticación en la memoria en un área diferente del área en la que se almacenan los datos de autenticación usados para generar el token de autenticación.

10. Una carta, un dispositivo de autenticación de cartas y/o un servidor de autenticación de cartas, según una cualquiera de las reivindicaciones anteriores, en el que la memoria de la carta comprende un identificador de carta y el token de autenticación comprende el identificador de carta.

11. Un dispositivo de autenticación de cartas y/o un servidor de autenticación de cartas según una cualquiera de las reivindicaciones anteriores, en el que el servidor de autenticación de cartas está dispuesto para enviar información con respecto a la carta para que su visualización en el dispositivo de autenticación de cartas.

12. Una carta según una cualquiera de las reivindicaciones anteriores, en el que la antena está configurada para comunicación NFC.

13. Una carta según una cualquiera de las reivindicaciones anteriores envuelta en un sobre, en el que el sobre es un sobre de papel metálico o está revestido con un material metálico para atenuar la señal inalámbrica hacia y procedente de la antena.

14. Un dispositivo de autenticación de cartas y/o un servidor de autenticación de cartas según una cualquiera de las reivindicaciones anteriores, en el que la memoria comprende un parámetro de juego para la carta, modificándose dicho parámetro de juego al recibir un token de autenticación que se verifica correctamente y dicho parámetro de juego se envía con la información que indica la autenticidad.

15. Un servidor de autenticación de cartas según una cualquiera de las reivindicaciones anteriores, en el que la memoria comprende un identificador de usuario que identifica un usuario de un servicio adicional del servidor de autenticación de cartas,

- enviando el dispositivo de autenticación de cartas el identificador de usuario con el token de autenticación,

- estando dispuesto el servidor de autenticación de cartas para asociar el identificador de usuario con el identificador de carta en la memoria del servidor de autenticación de cartas, estando dispuesto el servidor de autenticación de cartas para proporcionar acceso a la carta en el servicio adicional.

16. Un servidor de autenticación de cartas según una cualquiera de las reivindicaciones anteriores, que está dispuesto para

- generar una transacción de cadena de bloques que comprende el identificador de carta, - transmitir la transacción de cadena de bloques a una red de cadenas de bloques de manera que un dispositivo de gestión de cadenas de bloques procese la transacción para incluirla en un bloque de la cadena de bloques.

17. Un paquete de cartas que comprende una o más cartas según una cualquiera de las reivindicaciones anteriores, comprendiendo el paquete una carta adicional, comprendiendo la carta adicional una antena dispuesta para comunicación inalámbrica y un circuito de procesamiento dispuesto para distorsionar la señal inalámbrica de la una o más cartas.

18. Un servidor de autenticación de cartas según una cualquiera de las reivindicaciones anteriores que comprende

- una base de datos en la que se almacenan cartas que se han autenticado para un usuario, - una interfaz de juego digital configurada para recibir una instrucción de juego que hace referencia a una carta del usuario, estando configurado el servidor de autenticación de cartas para

- verificar que la carta referenciada ha sido autenticada para el usuario antes de permitir que se procese la instrucción de juego.

19. Un método de autenticación de cartas (600) para autenticar una carta electrónica, comprendiendo el método

- enviar de forma inalámbrica (610) un comando digital a través de una antena a un dispositivo de autenticación de cartas para provocar que la carta cree un token de autenticación, comprendiendo la carta una memoria electrónica (120) en la que se almacenan datos de autenticación (122) y un contador (124), y la creación del token de autenticación comprende aplicar una función criptográfica a los datos de autenticación y al contador, - recibir de forma inalámbrica (620) el token de autenticación procedente del dispositivo a través de la antena,

- hacer que se verifique el token de autenticación (630) con el contador y los datos de autenticación almacenados en la memoria de un servidor de autenticación de cartas.

20. Un medio legible por ordenador (1000) que comprende datos transitorios o no transitorios (1020) que representan instrucciones para hacer que un sistema procesador lleve a cabo el método de acuerdo con la reivindicación 19.

21. Un sistema de autenticación (100) dispuesto para autenticar un objeto físico para jugar a un juego de cartas, comprendiendo el sistema de autenticación un objeto físico (110), un dispositivo de autenticación de objetos físicos (200) y un servidor de autenticación de objetos físicos (300), en el que

A: el objeto físico (110) comprende

- una memoria electrónica (120) en la que se almacenan datos de autenticación (122), y un contador (124),

- una antena (130) dispuesta para comunicación inalámbrica,

- un circuito de procesamiento (140) dispuesto para

- recibir de forma inalámbrica un comando digital a través de la antena procedente del dispositivo de autenticación de objetos físicos electrónicos,

- crear un token de autenticación en respuesta a la recepción de un comando de autenticación, comprendiendo dicha creación leer los datos de autenticación y el contador de la memoria y aplicar una función criptográfica a los mismos,

- transmitir de forma inalámbrica el token de autenticación al dispositivo a través de la antena, e

- incrementar el contador almacenado en la memoria,

B: el dispositivo de autenticación de objetos físicos (200) está dispuesto para verificar la autenticidad del objeto físico, comprendiendo el dispositivo de autenticación de objetos físicos

- una unidad de comunicación (210) dispuesta para comunicarse a través de una red informática con el servidor de autenticación de objetos físicos,

- una antena (220) dispuesta para comunicarse de forma inalámbrica con el objeto físico, - un circuito de procesamiento (230) dispuesto para

- enviar de forma inalámbrica un comando de autenticación digital a través de la antena al objeto físico,

- recibir procedente del objeto físico un token de autenticación en respuesta al comando de autenticación digital,

- enviar el token de autenticación al servidor de autenticación a través de la unidad de comunicación, y

- recibir información sobre la autenticidad del objeto físico procedente del servidor de autenticación,

C: el servidor de autenticación de objetos físicos (300) está dispuesto para verificar la autenticidad del objeto físico, comprendiendo el servidor de autenticación de objetos físicos

- una memoria electrónica (310) para almacenar datos de autenticación y un contador,

- una unidad de comunicación (320) dispuesta para comunicarse a través de la red informática con el dispositivo de autenticación de objetos físicos,

- un circuito de procesamiento (330) dispuesto para

- recibir el token de autenticación procedente del dispositivo de autenticación de objetos físicos,

- verificar el token de autenticación con el contador y los datos de autenticación almacenados en la memoria del servidor de autenticación de objetos físicos, y

- si dicha verificación fuera exitosa, enviar información que indique la autenticidad al dispositivo de autenticación de objetos físicos e incrementar el contador en la memoria del servidor de autenticación de objetos físicos.