ES2599985T3

ES2599985T3 - Validación en cualquier momento para los tokens de verificación

Info

Publication number: ES2599985T3
Application number: ES15151322.3T
Authority: ES
Inventors: Simon Hurry; Ayman Hammad
Original assignee: Visa International Service Association
Current assignee: Visa International Service Association
Priority date: 2010-01-12
Filing date: 2011-01-12
Publication date: 2017-02-06
Anticipated expiration: 2031-01-12
Also published as: US8528067B2; AU2011205391A1; EP2927836A1; EP2927836B1; CN102713922A; AU2011205391B2; CA2786271A1; EP2524471A4; CA3045817A1; EP2524471B1; EP2524471A2; US10586229B2; WO2011088109A2; WO2011088109A3; CA2786271C; BR112012017000A2; CN105243313A; US20110173684A1; CN102713922B; CN105243313B

Abstract

Un método para generar un token de verificación por un fabricante de token de verificación, el método que comprende: generar un número de serie para un token de verificación; generar un par de claves específicas de token de verificación que incluye un componente público y un componente privado con base en una clave maestra del fabricante de token de verificación; asociar el número de serie con el par de claves específicas de token de verificación; y almacenar el componente privado del par de claves específicas de token de verificación a una memoria en el token de verificación, validar el token de verificación por un servidor de validación, en donde el componente privado del par de claves específicas de token de verificación se usa por el token de verificación para generar una respuesta a un mensaje de cuestionamiento firmado desde el servidor de validación por desencriptar el mensaje de cuestionamiento firmado mediante el uso del componente privado, y la clave maestra del fabricante de token de verificación se usa por el servidor de validación para desencriptar aún más la respuesta recibida del token de verificación para determinar que el token de verificación es de un fabricante de token de verificación de confianza.

Description

5

10

15

20

25

30

35

40

45

50

55

60

65

DESCRIPCION

Validacion en cualquier momento para los tokens de verificacion Referencias cruzadas a solicitudes relacionadas

Esta solicitud se basa y reivindica la prioridad a una Solicitud de Patente Provisional de Estados Unidos num. 61/294,338, titulada "Anytime Reader Device Validation Service for Contactless Verification Tokens", presentada el 12 de enero del 2010, y tambien se relaciona con la Solicitud de Patente Provisional de Estados Unidos num. 61/178,636 , titulada "Dynamic Data Authentication" presentada el 15 de mayo, 2009.

Antecedentes

A medida que aumentan los metodos y dispositivos para realizar transacciones financieras, persisten los viejos problemas como el fraude y la falsificacion.

Una de las fuentes primarias de fraude, que es frecuente en la industria de tarjetas de credito, es la duplicacion. La duplicacion se refiere a la copia electronica de los datos almacenados electronicamente de una tarjeta para crear tarjetas falsas. Una vez hecha la tarjeta falsa, existe la posibilidad de que pueda usarse con impunidad durante el tiempo que el usuario o la entidad emisora no se da cuenta o reporte que la informacion de la tarjeta de transacciones se ha visto comprometida. Este problema es particularmente frecuente en las transacciones sin presencia ffsica de la tarjeta, como las compras y transacciones en lmea, donde un falsificador no tiene por que identificarse a traves de una identificacion con foto que coincide con la informacion impresa o almacenada en la tarjeta de transaccion u otro dispositivo de consumo portatil.

Para combatir tal falsificacion u otro uso no autorizado de las transacciones sin presencia ffsica de tarjeta en lmea o tradicionales de otro tipo, algunas entidades emisoras han comenzado a emitir tokens de verificacion de tarjetas de contacto y sin contacto, tambien conocidos como tokens de verificacion, para usarse junto con una computadora del usuario. El token de verificacion de tarjeta puede verificar que el usuario que realiza la transaccion esta en posesion ffsica de la tarjeta de transaccion. Esto evita posibles fraudes en los que los estafadores obtienen solamente la informacion y no la tarjeta de transaccion misma. Sin embargo, incluso el uso de unos tokens de verificacion puede permitir diferentes formas de fraude.

Un metodo potencial de fraude tal es fabricar por los falsificadores o estafadores, su propia version de los dispositivos lectores de tarjetas o tokens de verificacion que son ffsica y funcionalmente similares a las versiones autorizadas a fin de no levantar las sospechas de los usuarios finales. El estafador puede entonces distribuir estos dispositivos lectores de tarjetas fraudulentas o tokens de verificacion a los usuarios que se configuran para duplicar los datos de usuario de las tarjetas de transaccion siempre que se use en una transaccion y que tenga los datos enviados a un sitio web o servidor operado por el falsificador. Como tal, existe una necesidad de verificar que los dispositivos de lectura de tarjeta o tokens de verificacion son dispositivos autorizados fabricados por una fuente de confianza y no un dispositivo de duplicado fraudulento fabricado y distribuido por un falsificador o estafador.

La Patente de los Estados Unidos num. 2009/0031131 describe un sistema para la gestion basada en token de un proceso de personalizacion PKI que incluye un sistema de peticion y manejo de tokens (TRMS) configurado para recoger informacion de un solicitante; y un sistema de personalizacion de tokens (TPS) configurado para personalizar un token de hardware de manera que el uso del token de hardware se limita por la informacion solicitada. Un metodo para la gestion basada en tokens de un proceso de personalizacion de PKI incluye: solicitar un token de hardware; personalizar un token de hardware de manera que el token de hardware se limita a la operacion dentro de los parametros de limitacion; vincular el token de hardware a una estacion de trabajo que se configura para recibir el token de hardware y usar las credenciales dentro del token de hardware para solicitar y descargar los datos PKI desde un servidor PKI, la estacion de trabajo que se configura, ademas, para personalizar un producto de usuario final mediante la carga de los datos de PKI en la memoria interna contenida dentro del producto de usuario final; y monitorear el uso del token de hardware y los datos PKI.

Las modalidades de la invencion se dirigen a abordar estas y otras cuestiones.

Breve resumen

Las modalidades de la presente invencion incluyen metodos para autenticar y registrar un fabricante de token de verificacion que incluyen recibir una solicitud de registro de un fabricante de token de verificacion en una computadora servidor y recuperar la informacion relacionada con el fabricante de token de verificacion a partir de una base de datos y generar un par de claves espedficas del fabricante mediante el uso de la computadora servidor. Otras modalidades pueden incluir realizar una revision de riesgo con base en la informacion relacionada con el fabricante de token de verificacion.

Otras modalidades de la presente invencion, incluyen tanto metodos asimetricos como simetricos para validar, autenticar y registrar un fabricante de token de verificacion que incluye generar un par de claves espedficas del

5

10

15

20

25

30

35

40

45

50

55

60

65

fabricante para el fabricante de token de verificacion (asimetricas) o generar una clave maestra (simetrica).El par de claves espedficas del fabricante puede comprender un componente publico y uno privado. Las modalidades tambien pueden incluir firmar el componente publico del par de claves espedficas del fabricante con el uso de la autoridad de certificacion de regimen de pago (CA) y el envfo del par de claves de fabricante de token de verificacion con el componente publico firmado al fabricante de token de verificacion. Tales metodos tambien pueden incluir asociar el par de claves espedficas de fabricante, la clave publica rafz de la CA y el componente publico firmado del par de claves espedfica del fabricante con un identificador del fabricante de token de verificacion y almacenar el identificador de fabricante del dispositivo lector asociado en una base de datos.

Otras diversas modalidades de la presente invencion incluyen metodos para validar un token de verificacion antes de que pueda usarse para iniciar una transaccion. Tales metodos pueden incluir recibir una solicitud de validacion a partir de un token de verificacion y determinar un numero de serie del token de verificacion con base en la solicitud de validacion. Tales modalidades pueden incluir determinar un estado de registro del numero de serie del token verificacion, determinar un identificador de fabricante de token de verificacion con base en la solicitud de validacion, y determinar un primer componente de un par de claves espedficas del fabricante con base en el identificador de fabricante de token de verificacion. Tales modalidades tambien pueden incluir recuperar un segundo componente de la clave espedfica de fabricante y una clave maestra de fabricante de token de verificacion de una base de datos con base en el identificador del fabricante de token de verificacion y realizar una autenticacion mutua con el token de verificacion. Las modalidades tambien pueden incluir realizar una autenticacion mutua que comprende determinar una clave del token de verificacion con base en el numero de serie del token de verificacion y la clave maestra del fabricante de token de verificacion y establecer una sesion de clave del token de verificacion con base en la clave del token de verificacion. Establecer una sesion de clave del token de verificacion tambien puede incluir generar un tercer componente de la clave espedfica de fabricante con base en el numero de serie del token de verificacion y una clave maestra asociada con la computadora servidor.

Otras modalidades de la presente invencion incluyen metodos para producir un token de verificacion autentico. Tales metodos incluyen generar un numero de serie para un token de verificacion, generar un par de claves que incluye un componente publico y un componente privado, firmar el componente publico del par de claves con una clave privada espedfica del fabricante, almacenar el componente publico firmado del par de claves en una memoria en el token de verificacion junto con la clave rafz de la entidad emisora de certificados (CA) y asociar el numero de serie con el par de claves, el componente publico firmado. Tales modalidades pueden comprender ademas almacenar el numero de serie, un identificador de fabricante, el codigo ejecutable en un procesador en la memoria del token de verificacion. El codigo puede incluir instrucciones para que un procesador establezca una conexion con un servidor de verificacion a traves de una sesion de comunicacion mediante el uso de una instalacion de comunicacion de una computadora a la que se conecta el token de verificacion.

Breve descripcion de los dibujos

La Fig. 1 es un esquema de un sistema que puede beneficiarse de diferentes modalidades de la presente invencion en el contexto de una transaccion de tarjeta de pago realizada en lmea.

La Fig. 2 muestra una configuracion ilustrativa que pueden implementar diversas modalidades de la presente invencion.

La Fig. 3 es un esquema de un sistema para producir tokens de verificacion de acuerdo con diversas modalidades de la presente invencion.

La Fig. 4 es un diagrama de flujo de un metodo de validacion y registro de un fabricante de token de verificacion de acuerdo con una modalidad de la presente invencion.

La Fig. 5 es un diagrama de flujo de un metodo para producir tokens de verificacion de acuerdo con diversas modalidades de la presente invencion.

La Fig. 6 es un esquema de un sistema para validar tokens de verificacion de acuerdo con diversas modalidades de la presente invencion.

La Fig. 7 es un diagrama de flujo de un metodo de validacion de tokens de verificacion de acuerdo con diversas modalidades de la presente invencion.

La Fig. 8 es un esquema de un sistema para validar tokens de verificacion de acuerdo con diversas modalidades de la presente invencion.

La Fig. 9 es un diagrama de flujo de un metodo de validacion de tokens de verificacion de acuerdo con diversas modalidades de la presente invencion.

La Fig. 10 es un diagrama de flujo de un metodo de validacion de tokens de verificacion de acuerdo con diversas modalidades de la presente invencion.

5

10

15

20

25

30

35

40

45

50

55

60

65

La Fig. 11 es un sistema informatico que se usa para implementar diversas modalidades de la presente invencion. Descripcion detallada

Las modalidades de la presente invencion se dirigen hacia dispositivos, sistemas y metodos para la autenticacion de dispositivos de lectura de tarjetas de transaccion o tokens de verificacion para su uso en un sistema de transacciones. Como se usa en la presente descripcion, los terminos dispositivos de lectura de token de usuario, dispositivos de lectura de token y tokens de verificacion, pueden usarse indistintamente para referirse a cualquier dispositivo que puede usarse para leer la informacion y verificar la presencia o autenticidad de los dispositivos portatiles de consumo, tokens de usuario, o tarjetas de transaccion. Un token de verificacion puede incluir cualquier combinacion de hardware, firmware y software adecuado para leer, procesar o enviar datos hacia y desde un dispositivo portatil del consumidor. Los tokens de verificacion pueden incluir dispositivos integrados, tales como componentes internos, circuitos integrados, y tarjetas de computadora en una computadora o dispositivo de comunicacion o dispositivos perifericos, tales como los dispositivos USB o dispositivos de seguridad que se conectan o comunican con un dispositivo de computacion o comunicacion a traves de una interfaz periferica. Un dispositivo de comunicacion puede incluir cualquier dispositivo adecuado para enviar, recibir y procesar datos, que incluye pero no se limita a los telefonos moviles, telefonos inteligentes, PDAs, etc.

Los dispositivos portatiles de consumo, tokens de usuario o tarjetas de transaccion comprenden dispositivos que contienen o almacenan informacion de identificacion correspondiente a una cuenta mantenida por un usuario con otra entidad, que suele ser una entidad que mantiene, extiende, o acredita artmulos de valor al usuario (por ejemplo, fondos monetarios, creditos, deudas, etc.). El termino dispositivo portatil de consumo, token de usuario o tarjeta de transaccion puede usarse indistintamente para referirse a diversos tipos de tarjetas de credito, tarjetas de carga, tarjetas de debito, tarjetas bancarias, tarjetas de prepago, tarjetas de acceso, tarjetas de seguridad, y otras tarjetas que identifican una cuenta abierta por un usuario con otra entidad. Los dispositivos portatiles de consumo son capaces de existir tanto en forma pasiva (por ejemplo, tarjeta con una banda magnetica o componentes RFID) y formas activas (por ejemplo, tarjetas de circuitos integrados, tarjetas inteligentes) y, ademas, incluyen los dispositivos electronicos portatiles que, en su totalidad o en parte, funcionan como tales tarjetas. Tales dispositivos electronicos portatiles pueden incluir tarjetas de memoria, tokens de cuenta, llaveros, dispositivos RFID, etiquetas engomadas, telefonos celulares (que incluyen el telefono de comunicaciones de campo cercano), y dispositivos de llavero (tal como el Speedpass™ disponible comercialmente de Exxon-Mobil Corp. o payWave™ comercialmente disponible de Visa, Inc.), asistentes digitales personales, otros dispositivos electronicos moviles, transpondedores, soportes inteligente, y localizadores.

La informacion de identificacion contenida por (por ejemplo, integrada en) un dispositivo de consumo portatil comprende, al menos, un numero de cuenta u otro identificador, tal como un nombre de cuenta o un numero de serie del dispositivo portatil de consumo. El numero de cuenta puede comprender caracteres alfanumericos. La informacion de identificacion puede comprender, ademas, el nombre del titular de la cuenta (por ejemplo, el usuario), la fecha de caducidad de la tarjeta, los codigos de servicio, y los datos discrecionales. A modo de ejemplo, la informacion de identificacion puede incluir los "datos de pago" convencionales almacenados en las pistas de la banda magnetica de una tarjeta de credito convencional (por ejemplo, Pista 1, Pista 2, y/o la Pista 3).

La informacion de identificacion de un dispositivo de consumo portatil se lee por un lector, que es un componente electrico de un token de verificacion que puede leer la informacion de identificacion desde un dispositivo de consumo portatil y proporcionar la informacion de identificacion a otro componente electrico. Un lector puede comprender uno o mas de los siguientes: un lector de banda magnetica, un lector de tarjeta de contacto, y un lector sin contacto, el ultimo de los cuales se conoce comunmente como un lector RFID (RFID que es un acronimo de identificacion por radio frecuencia).Los lectores se encuentran predominantemente en las ubicaciones de punto de venta de los comerciantes. Sin embargo, cada vez mas, los lectores se incluyen como parte de un token de verificacion dado a los usuarios para su uso en una computadora personal para usar en las transacciones en lmea u otras actividades en las que un emisor, adquiriente, comerciante u otra entidad no puede comprobar personalmente la identidad del usuario autorizado o la autenticidad del dispositivo de consumo portatil. Esta tendencia representa una oportunidad para los estafadores y un correspondiente riesgo de un posible fraude a los usuarios, emisores y adquirentes.

La Fig. 1 ilustra un sistema ilustrativo que puede beneficiarse de diferentes aspectos de la invencion y se describe en detalle para dar contexto a diversas modalidades, pero no debe considerarse limitante de ninguna manera. El sistema en la Fig. 1 se ilustra y describe en el contexto de una compra en lmea.

Los sistemas de transaccion, como el que se muestra en la Fig. 1, que usan dispositivos portatiles de consumo pueden ser susceptibles a los fabricantes fraudulentos que hacen e introducen tokens de verificacion no autorizados en el flujo comercial para duplicar la informacion de usuario, tal como los numeros de tarjeta de credito, de los usuarios desprevenidos. Para evitar la posibilidad de que un fabricante no autorizado duplique la informacion de usuario durante una transaccion realizada con un token de verificacion no autorizado, es deseable la previa autentificacion o registro de un token de verificacion antes de permitir su uso para completar cualquier transaccion. Asf, las modalidades proporcionan una mayor seguridad, y por lo tanto una mayor probabilidad, de que los usuarios hagan transacciones en lmea mediante el uso de dispositivos portatiles de consumo.

5

10

15

20

25

30

35

40

45

50

55

60

65

En la Fig. 1 se muestran iconos para un usuario 1, un dispositivo de consumo portatil 5, un dispositivo de comunicacion 7 (tal como un telefono celular), una computadora 10, el sitio web de un comerciante 20, y una primera red de comunicaciones 31 que permite a la computadora del usuario y el sitio web del comerciante comunicarse entre sf La primera red de comunicaciones 31 puede incluir Internet, una red de telecomunicaciones (por ejemplo, una red inalambrica, red de telefoma celular, una red telefonica, una red por cable, o cualquier combinacion de las mismas), una red de area extendida (WAN), una red de area local (LAN), un router o puerta de enlace acoplado a una de las redes anteriores, o cualquier combinacion de lo anterior. Tambien en la Fig. 1 se muestra un banco adquirente 50 para el comerciante, un banco emisor 60 para el dispositivo portatil de consumo 5, una red de procesamiento de pagos 70, y una segunda red de comunicaciones 32 que permite a la red de procesamiento de pagos 70 comunicarse con cada uno de los bancos 50 y 60.

La segunda red de comunicaciones 32 puede comprender Internet (y, por tanto, puede solaparse y compartir instalaciones con la primera red de comunicaciones 31), o puede comprender una o mas redes privadas, o la combinacion de una o mas redes privadas con la Internet. Una red privada puede comprender una red de telecomunicaciones, una red de area extendida (WAN), una red de area local (LAN), o cualquier combinacion de las mismas. En algunos casos, las primera y segunda redes de comunicaciones 31 y 32 pueden ser las mismas (tal como una red que usa la Internet como red principal).Una red de comunicaciones comprende, generalmente, una red de uno o mas enlaces de comunicaciones y dos o mas nodos que pasan mensajes de una parte de la red a la otra parte. Cada nodo comprende una o mas piezas de maquinaria electrica, y cada enlace puede comprender uno o mas de los siguientes: fibras opticas, enlaces opticos, enlaces de radio, y cables electricos. Los componentes descritos hasta ahora son, en su mayor parte, convencionales y se disponen de manera convencional.

Diversas modalidades de la presente invencion pueden usarse para autenticar, registrar u opcionalmente actualizar un token de verificacion integrado o periferico 40 antes de que se use por primera vez en un sistema de transacciones tal como el que se muestra en la Fig. 1. En algunas modalidades, el registro o autenticacion previa de los tokens de verificacion puede completarse sin necesidad de introducir, enviar, o de cualquier otra manera usar dispositivos portatiles de consumo de un usuario, tal como una tarjeta RFID, o liberar cualquier otra informacion del usuario. En algunas modalidades, un token de verificacion puede autenticarse por tener el token de verificacion en comunicacion con un servidor host a traves de cualquier medio de comunicacion adecuado y la implementacion de un esquema de autenticacion mutua simetrico o asimetrico. En tales modalidades, sin embargo, es necesario asegurar que la tecnologfa del token de verificacion o el esquema de autenticacion no pueden fabricarse, reproducirse, o distribuirse por un fabricante no autorizado de manera que los token de verificacion fraudulenta no pueden introducirse en el mercado para duplicar datos de usuario y transmitirlos a los estafadores. Puesto que es diffcil mantener tales tecnologfa y esquemas sin ser hackeados o copiados, es ventajoso tomar precauciones adicionales. Otros aspectos de la Fig. 1 se describiran con mas detalle a continuacion en referencia a modalidades de la presente invencion.

La Fig. 2 muestra una configuracion de una computadora 10, varios tokens de verificacion 40A, 40B, y 40C, y un dispositivo de consumo portatil 5 que puede usarse en implementaciones de diversas modalidades de la presente invencion. La computadora 10 puede incluir dispositivos de interfaz de usuario, tales como el teclado 250 y la pantalla 260.Los tokens de verificacion 40A, 40B, 40C pueden tener una interfaz USB u otra interfaz periferica que puede conectarse a una interfaz periferica 16 en la computadora 10.La interfaz periferica 16 en la computadora 10 puede implementarse como varios protocolos de interfaz periferica estandar o propietarios adecuados para conectar un token de verificacion a la computadora 10.Mediante la autenticacion o registro previo de los fabricantes del token de verificacion y exigir practicas y protocolos espedficos para los fabricantes en la elaboracion de tokens de verificacion autenticos, diversas modalidades de la presente invencion proporcionan niveles adicionales de seguridad contra posibles estafadores que duplican informacion personal o de cuenta de usuario sensible mediante tokens de verificacion fraudulenta, falsificados o de cualquier otra manera no autorizados.

Los tokens de verificacion 40A, 40B, y 40C pueden tener interfaces USB u otra interfaz periferica 46 que puede conectarse a una interfaz periferica 16 en la computadora 10.Como se muestra en la Fig. 2, la computadora 10 puede incluir una pantalla 260 y un dispositivo de entrada 250 como el teclado que se muestra.

La interfaz periferica 16 en la computadora 10 puede implementarse como varios protocolos de interfaz periferica estandar o propietarios adecuados para conectar un token de verificacion a la computadora 10.Estas normas pueden incluir USB, uSb 2.0, FireWire™ (IEEE 1394), puertos serie y paralelo, etc. Por ejemplo, el token de verificacion 40A puede ser un lector de banda magnetica de contacto basada en USB, el token de verificacion 40B puede ser un lector RFID basado en USB o FireWire™, mientras el token de verificacion 40C puede ser algun otro tipo de lector de dispositivo de consumo portatil inalambrico que se integra dentro de la computadora de hardware 10 o se conecta internamente a la placa base o el bus interno.

El usuario puede entonces presentar el dispositivo de consumo portatil 5 a uno o mas de los tokens de verificacion compatibles para iniciar, procesar, o de cualquier otra manera completar una transaccion mediante el uso de la computadora 10.Sin embargo, antes de usar el token de verificacion en una solicitud de transaccion o autenticacion real, la entidad/servidor de autenticacion o validacion puede exigir que el token de verificacion se autentifique mediante el uso de diversos sistemas y metodos de acuerdo con modalidades de la presente invencion. La base de los sistemas y metodos para la autenticacion de un token de verificacion puede incluir los procesos, metodos y sistemas para el

5

10

15

20

25

30

35

40

45

50

55

60

65

registro o autenticacion previa de un fabricante de token de verificacion y la fabricacion y programacion actual de los tokens de verificacion, que se describira con mas detalle abajo.

Como se muestra en la Fig. 1, la computadora 10 puede comprender una computadora de sobremesa, una computadora portatil, o cualquier dispositivo electronico portatil que tiene una instalacion de red y una interfaz periferica para la comunicacion con uno o mas dispositivos perifericos. La computadora 10 tiene uno o mas procesadores 11, un medio legible por computadora tangible 12 acoplado al(los) procesador(es) 11 que almacena codigos de instruccion (software) que controla el(los) procesador(es) 11 y que almacena los datos usados por el(los) procesador(es) 11, y una interfaz de usuario 13 acoplada al(los) procesador(es) 11.La instalacion de red 14 y la interfaz periferica 16 tambien pueden acoplarse al(los) procesador(es) 11, con la instalacion de red 14 que tambien se acopla a la primera red de comunicaciones 31.La interfaz de usuario 13 comprende uno o mas dispositivos de salida de video (por ejemplo, pantallas, visualizadores) y uno o mas dispositivos de entrada (por ejemplo, teclado, raton, raton de bola, etc.)para que el usuario 1 reciba informacion desde la computadora 10, y para proporcionar informacion a la computadora 10.

El medio legible por computadora 12 puede comprender una combinacion de memoria de semiconductores y de almacenamiento no volatil, tal como una o mas unidades de disco y/o la memoria no volatil. El medio legible por computadora 12 almacena un sistema operativo para la computadora 10, que permite que los procesos y aplicaciones se ejecuten por el(los) procesador(es) 11.El sistema operativo proporciona servicios a estos procesos y aplicaciones, y permite que estos procesos y aplicaciones accedan a los componentes de la interfaz de usuario 13, las porciones del medio legible por computadora 12, la instalacion de red 14, la interfaz periferica 16, y otros componentes de la computadora 10.El sistema operativo puede ser complejo y completo, tal como se encuentra en las computadoras de sobremesa, o simplificado, tal como se encuentra en los telefonos celulares, PDAs, y muchos otros tipos de dispositivos electronicos portatiles.

El servicio de red 14 de la computadora 10 puede comprender software y hardware que permiten que un proceso que se ejecuta en la computadora 10 se comunique con una red de comunicaciones, tal como la red 31, para enviar y recibir mensajes, datos, y similares, a una o mas entidades acopladas a la red de comunicaciones. El hardware de la instalacion 14 puede comprender hardware dedicado separado del/de los procesador(es) 11, o el uso compartido del(de los) procesador(es) 11, o una combinacion de los mismos. El software de la instalacion 14 puede comprender firmware, software almacenado en un medio legible por computadora 12 u otro medio legible por computadora, porciones del sistema operativo, o una combinacion de cualquiera de los elementos anteriores.

La instalacion de red 14 es preferentemente un recurso no exclusivo, que permite el acceso a la red de comunicaciones por otros procesos y aplicaciones que se ejecutan por la computadora 10.La interfaz periferica 16 de la computadora 10 comprende una conexion por cable o inalambrica que permite a un dispositivo periferico (separado de la computadora 10) comunicarse con la computadora. Las conexiones cableadas convencionales incluyen conectores de bus serie universal (USB) ("puertos USB"), puertos serie, puertos paralelos y puertos PCMCIA. Las conexiones inalambricas convencionales incluyen estaciones de base de infrarrojos (IR) y estaciones de base Bluetooth™ que se incorporan en la computadora 10 o que se acoplan a una interfaz periferica de la computadora 10.

Ademas del lector 44 y la interfaz periferica 46, el token de verificacion 40 comprende ademas un procesador 41, un medio legible por computadora tangible 42 acoplado al procesador 41 que almacena los datos y los codigos que dirigen el funcionamiento del procesador 41, un modulo de seguridad 43 acoplado al procesador 41 y adaptado para almacenar de manera segura una o mas claves de encriptacion y para encriptar y desencriptar los datos para el token de verificacion 40, un lector 44 acoplado al procesador 41 y adaptado para leer los dispositivos portatiles de consumo 5, y una interfaz periferica 46 acoplada al procesador 41 y adaptada para comunicarse a la computadora 10 por medio de la interfaz periferica 16.

El procesador 41 puede comprender un microprocesador convencional, y el medio legible por computadora 42 puede comprender una combinacion de memoria de semiconductores y de almacenamiento no volatil, tal como memoria no volatil. El medio legible por computadora 42 puede incluir el almacenamiento de varios elementos de datos, codigos de procesador que dirigen el funcionamiento del procesador 41 y la memoria del procesador que el procesador 41 puede usar en la realizacion de sus tareas. Con referencia de nuevo a la Fig. 1, el modulo de seguridad 43 puede comprender el circuito de encriptado y desencriptado (que puede incluir uno o mas procesadores), y puede comprender una o mas claves de encriptado almacenadas en una memoria protegida. El modulo de seguridad 43 tambien puede incluir un circuito de seguridad cortafuegos que protege el token de verificacion 40 de ataques de piratas informaticos realizados a traves de la interfaz periferica 16.

El lector 44 puede comprender un lector de convenciones. La interfaz periferica 46 puede comprender una conexion por cable o inalambrica adaptada para comunicar con la interfaz periferica 16 de la computadora 10.Las conexiones cableadas convencionales incluyen conectores de bus serie universal ("puertos USB"), puertos serie, puertos paralelos y puertos PCMCIA. Las conexiones inalambricas convencionales pueden incluir estaciones remotas de infrarrojos y Bluetooth™. Cuando se usa una conexion por cable convencional con interfaz periferica 46, el token de verificacion 40 puede acoplarse de manera desmontable a la computadora 10 en la interfaz periferica 16, tal como en un conector de puerto USB.

5

10

15

20

25

30

35

40

45

50

55

60

65

El token de verificacion 40 tambien puede incluir varios codigos integrados en el medio legible por computadora 42 que dirigen al procesador de datos 41 para llevar a cabo las acciones respectivas. Un primer codigo puede dirigir al procesador de datos 41 para comunicarse con la computadora 10 por medio de la interfaz periferica 46 a fin de obtener las instalaciones de redes de acceso 14 de computadora 10.El primer codigo puede comprender el codigo que dirige al procesador de datos 41 para enviar un controlador de dispositivo a la computadora 10 y una instruccion para instalar el controlador de dispositivo en el sistema operativo de la computadora, en donde el controlador de dispositivo es una coleccion de instrucciones a ejecutar por la computadora 10 que permite a la computadora 10 reconocer el token de verificacion y comunicarse con el token de verificacion 40, y permite al procesador de los datos del token 41 hacer llamadas de funcion a diferentes (API) del sistema operativo de la computadora, tales como las relacionadas con las redes y el acceso a la instalacion de red 14.

Asf los llamados controladores de "auto-instalacion" se conocen en la tecnica, y pueden usarse en la presente descripcion. Ellos comprenden una o mas llamadas de funcion a una interfaz de programacion de aplicaciones (API) del sistema operativo de la computadora, tal como la API del administrador de dispositivos. El primer codigo puede configurarse para funcionar con un sistema operativo seleccionado, como Windows o Symbian OS, o puede configurarse para trabajar con varios sistemas operativos. En este ultimo caso, el primer codigo puede incluir varios controladores de dispositivo para los diferentes sistemas operativos, y las instrucciones que consultan a la computadora 10 por su tipo de sistema operativo y seleccionan (e instalan) el controlador mas apropiado para el sistema operativo de la computadora. Los controladores de dispositivos pueden almacenarse en una seccion del medio legible por computadora 42.

Un segundo codigo de token de verificacion 40 dirige al procesador 41 para recibir informacion de identificacion que se lee desde el dispositivo portatil de consumo 5 por el lector 44.El segundo codigo puede incluir codigo que dirige al procesador 41 para recibir un identificador universal de recursos (URID) de una entidad/servidor de validacion 80, como se lee desde el dispositivo portatil de consumo 5 por el lector 44.Estas instrucciones pueden incluir instrucciones de E/S convencionales que dirigen las comunicaciones con lector 44.El dispositivo portatil de consumo 5 diferente, puede almacenar y proporcionar URID diferentes a diferentes entidades de validacion 80.Un identificador de recursos uniforme (URID) puede comprender un localizador de recursos uniforme (URL), una direccion de protocolo de Internet (direccion IP), o cualquier otro tipo de identificador que puede identificar una entidad en una red de comunicaciones.

Si un dispositivo de consumo portatil 5 no proporciona un URID para la entidad/servidor de validacion 80, el token de verificacion 40 puede almacenar un URID para una entidad/servidor de validacion 80, espedfica o por defecto, de un fabricante. En algunas configuraciones, algunos tokens de verificacion 40 pueden ser de marca compartida con los respectivos bancos emisores y solamente trabajan para los dispositivos portatiles de consumo que son de marca compartida con los mismos bancos emisores, y cada banco emisor puede tener su propia entidad/servidor de validacion 80 con su URID propia. En tal configuracion, estos tokens de verificacion 40 pueden almacenar los URID para sus respectivas entidades de validacion 80 de marca compartida. En lugar, o ademas de esta configuracion, algunos tokens de verificacion 40 pueden asociarse con las redes de procesamiento de pago 70 respectivas, y cada una de tales redes puede tener su propia entidad/servidor de validacion 80.En tal configuracion, estos tokens de verificacion 40 pueden almacenar los URID para sus respectivas entidades de validacion asociadas 80.

En consecuencia, el segundo codigo del token de verificacion 40 puede configurarse ademas para dirigir el procesador de datos 41 a usar solamente un URID predeterminado almacenado por el token de verificacion 40, o usar un URID predeterminado si el dispositivo de consumo portatil 5 no proporciona el token de verificacion 40 con un URID para la entidad/servidor de validacion 80.Como otra implementacion, el token de verificacion 40 puede incluir codigo que dirige al procesador 41 para seleccionar uno de una serie de URID almacenados en el token de verificacion 40 con base en un numero de banco proporcionado en la informacion de identificacion o integrado en el numero de cuenta. La direccion y los codigos mas arriba pueden implementarse con las instrucciones convencionales de E/S, instrucciones de acceso a memoria, y las instrucciones logicas y de control de la CPU. Uno o mas URID para entidades de validacion pueden almacenarse en la memoria legible por computadora 42.

Un tercer codigo de token de verificacion 40 dirige al procesador de datos 41 para establecer la comunicacion con la entidad/servidor de validacion 80 mediante el uso de la instalacion de red 14 de la computadora 10.El sistema operativo de la computadora 10 comprende uno o mas modulos de software y programas de aplicacion, genericamente llamados "modulos de servicios de la red" en la presente descripcion, que pueden acceder a la instalacion de red 14 y establecer sesiones de comunicacion con las entidades en la red de comunicaciones 31.Tales modulos de servicios de red incluyen Microsoft's Windows Communications Foundation (por ejemplo, .NET 3.0, .NET 4.0, etc.), Apple's CFNetwork Framework, la seccion de redes de los nucleos de los sistemas operativos UNIX y Linux, la capa de servicios del sistema operativo y la capa base de servicios del sistema operativo Symbian, los navegadores de Internet, y similares. Cada uno de estos modulos de servicios de red es no exclusivo (por ejemplo, capaz de servir a mas de un procesador, y mas de un proceso/aplicacion) y proporcionan una interfaz de programacion de aplicaciones (API) para un conjunto de funciones que un procesador puede acceder mediante el llamado de funcion respectivo. Con estas prestaciones de la API, una coleccion de las llamadas de funcion puede construirse facilmente para ejecutar por un procesador, que permiten al procesador establecer un canal de comunicacion con una entidad en una red de comunicaciones acoplada a una instalacion de red 14, y para el intercambio de mensajes y datos con la entidad.

5

10

15

20

25

30

35

40

45

50

55

60

65

El tercer codigo del token de verificacion 40 comprende una coleccion tal de llamados de funcion a la API de un modulo de servicios de red de la computadora 10, que incluye una o mas llamadas de funcion que proporcionan el identificador universal de recursos (URID) para la entidad/servidor de validacion 80 y una instruccion para establecer una sesion con la entidad de validacion. La sesion puede ser una sesion de capa de conexion segura (o capa de transporte seguro) (por ejemplo, una sesion SSL) con autenticacion mutua. Como parte del establecimiento de la sesion en algunas implementaciones, el tercer codigo del token de verificacion 40 puede incluir dirigir al procesador de datos 41 para proporcionar, o para que se proporcione, una direccion de red para el token al modulo de servicios de red de la computadora y a la entidad/servidor de validacion 80.La direccion de red puede ser estatica o dinamica, la ultima de las cuales puede obtenerse a traves de la llamada de funcion de la API al modulo de servicios de red de la computadora. La direccion de red puede ser una direccion IP.

Si el token de verificacion 40 se configura para usar un navegador de Internet para un modulo de servicios de red, este puede comprender, ademas, llamadas de funcion de la API para que el sistema operativo de la computadora inicie una instancia del navegador y lo proporcione con acceso a la instancia del navegador. En algunas implementaciones, tal como cuando la entidad de verificacion 40 almacena el URID de la entidad/servidor de validacion 80, el tercer codigo puede dirigir al procesador de datos 41 para establecer la comunicacion con la entidad/servidor de validacion 80 mucho antes de que el usuario 1 presente el dispositivo de consumo portatil 5 al lector 44.La verificacion 40 y la validacion 80 pueden mantener la sesion de comunicacion activa hasta que el dispositivo 5 se presenta al lector 44, y en los intervalos que el dispositivo 5 se presenta al lector 44, mediante el intercambio de mensajes de "pulsacion" de forma intermitente. Por ejemplo, el token de verificacion 40 puede periodica, no periodica, o aleatoriamente enviar mensajes a la entidad/servidor de validacion 80 que confirman su presencia en la sesion, y la entidad/servidor de validacion 80 puede enviar un mensaje de respuesta que confirma su presencia en la sesion.

Un cuarto codigo del token de verificacion 40 dirige al procesador de datos 41 para transmitir al menos una porcion de la informacion de identificacion a la entidad/servidor de validacion 80 por medio de las prestaciones de red 14 de la computadora 10, en donde la informacion de identificacion se transmite en forma encriptada. Si se establece una sesion SSL, el cuarto codigo puede dirigir al procesador de datos 41 para pasar la informacion de identificacion al modulo de servicios de red de la computadora mediante el uso de la llamada de funcion apropiada a la API para el modulo de servicios de red y la informacion de identificacion puede transmitirse en la sesion sSl, donde los datos transmitidos y recibidos se encriptan por una clave de sesion. Para una capa adicional de seguridad, el cuarto codigo puede comprender ademas un codigo que dirige al procesador 41 para cifrar la informacion de identificacion con la ayuda del modulo de seguridad 43 mediante el uso de una clave de encriptacion almacenada en el token 40 antes de proporcionarla a la instalacion de red 14.Estas instrucciones pueden incluir instrucciones de E/S convencionales que dirigen las comunicaciones con el modulo de seguridad 43 para pasar la informacion de identificacion al modulo 43 y para recibir de vuelta la informacion encriptada. Una clave de encriptacion para esto puede almacenarse en un medio legible por computadora 42 o en el modulo de seguridad 43.

El uso de llamadas de funcion a diversas interfaces de programacion de aplicaciones (API) del sistema operativo de la computadora 10 sus modulos de soporte, prestaciones, y sus aplicaciones se conocen bien en la tecnica de software, y un experto en la tecnica sera capaz de construir instrucciones y la llamadas de funcion de la API para implementar los codigos y las tareas anteriormente descritos en vista de esta descripcion sin la experimentacion excesiva.

La Fig. 3 es un esquema de un sistema 300 para el registro y la autenticacion de los fabricantes de token de verificacion de acuerdo con una modalidad de la presente invencion. El sistema 300 puede incluir una entidad/servidor de validacion 80 conectada a una red de comunicacion, tal como la primera red de comunicacion 31.A traves de la red de comunicacion 31, la entidad/servidor de validacion 80 tambien puede acoplarse a una base de datos 303, banco emisor 60, y un numero de fabricantes de token de verificacion 305, 307, y 309.La entidad/servidor de validacion 80 puede operarse por el emisor, el adquirente, un comerciante o una red de procesamiento de pagos 70, tales como Visa Net™.

La entidad/servidor de validacion 80 puede configurarse y/o programarse para requerir que un fabricante de token de verificacion que desea fabricar tokens de verificacion autenticos o de cualquier otra manera aprobados para presentar una solicitud de registro o validacion. En algunas modalidades, la entidad/servidor de validacion 80 puede alojar un sitio web u otra interfaz de usuario para que los fabricantes de tokens de verificacion 305, 307, o 309 puedan descargar los formularios y/o especificaciones apropiadas respecto a la informacion que la entidad/servidor de validacion 80 requiere para validar o registrar, en ultima instancia, un fabricante de token de verificacion.

Los fabricantes de tokens de verificacion pueden reunir toda la informacion necesaria y luego presentar una solicitud de registro o validacion a la entidad/servidor de validacion 80 en la accion 1.Los formularios, instrucciones o especificaciones proporcionadas por la entidad/servidor de validacion 80 pueden exigir que las solicitudes de registro incluyan informacion espedfica del fabricante de token de verificacion, tales como el nombre, ubicacion, referencias comerciales del fabricante, o cualquier otra informacion que la entidad/servidor de validacion 80 puede usar para acceder a la informacion respecto al fabricante de token de verificacion solicitante o para evaluar la legitimidad del fabricante de token de verificacion solicitante. La entidad/servidor de validacion 80 puede usar la informacion presentada en la solicitud de registro para recopilar y evaluar la informacion respecto al fabricante de token de verificacion solicitante para determinar si el fabricante de token de verificacion solicitante es una entidad de confianza o legftima.

5

10

15

20

25

30

35

40

45

50

55

60

65

En algunas modalidades, la determinacion en cuanto a la confiabilidad o la legitimidad de un fabricante de token de verificacion solicitante puede basarse en protocolos de analisis de riesgos internos de la entidad que opera la entidad/servidor de validacion 80 en la accion 2.Por ejemplo, una red de procesamiento de pagos, tal como una red de procesamiento de pagos de tarjetas de credito, puede aplicar sus propios protocolos de gestion de riesgos y fraudes desarrollados internamente para evaluar cada fabricante de token de verificacion solicitante. En algunas modalidades, cuando la entidad/servidor de validacion 80 recibe una solicitud de registro de un fabricante de token de verificacion, puede analizar la informacion de la solicitud de registro para construir consultas y/o solicitudes propias con el proposito de recopilar informacion de antecedentes respecto al fabricante de token de verificacion solicitante. En algunas modalidades, la entidad/servidor de validacion 80 puede consultar diversas bases de datos tales como la base de datos 303 para obtener informacion de antecedentes respecto al fabricante de token de verificacion solicitante.

En modalidades en las que la entidad/servidor de validacion 80 se opera por una entidad que no tenga su propio protocolo de gestion de riesgo o fraude, la entidad/servidor de validacion 80 puede enviar las solicitudes de registro para la informacion de la solicitud de registro a un servicio o entidad de analisis externo, para determinar si se registra o valida el fabricante de token de verificacion solicitante en la accion 2. Por ejemplo, la entidad/servidor de validacion 80 puede enviar informacion de solicitud de registro, o una solicitud o consulta que contiene informacion de solicitud de registro, a la base de datos 303 para determinar si el fabricante de token de verificacion solicitante aparece con un estado o denominacion particular.

Espedficamente, la base de datos 303 puede ser una base de datos de ejecucion de la ley o la industria que enumera los estafadores o falsificadores conocidos con base en una conducta criminal, quejas de los consumidores o los informes de litigio civil. Como alternativa, la base de datos 303 tambien puede enumerar las entidades con base en su confiabilidad, calificacion crediticia, clasificacion o calificacion en el sector u otros indicios reveladores de que el fabricante de token de verificacion solicitante es probable que sea un fabricante confiable o legttima. En otras modalidades, la base de datos 303 puede construirse, operarse y mantenerse por la misma entidad que opera la entidad/servidor de validacion 80.

Con base en los resultados de los protocolos de gestion de riesgos o fraude, internos o externos, la entidad/servidor de validacion 80 puede determinar si el fabricante de token de verificacion solicitante se considerara confiable y, en consecuencia, se registrara como un fabricante de token de verificacion de confianza en la accion 3. Una vez que se hace la determinacion de si el fabricante de token de verificacion solicitante se registrara como un fabricante de confianza o legttimo, la entidad/servidor de validacion 80 puede enviar un mensaje de respuesta o el mensaje de registro al fabricante de token de verificacion solicitante en la accion 4. En el caso de que la entidad/servidor de validacion 80 determina que el fabricante de token de verificacion solicitante no representa un riesgo adecuado de acuerdo con las tolerancias al riesgo de la entidad/servidor de validacion 80, el banco que opera, la red de procesamiento de pagos, el emisor etc., la entidad/servidor de validacion 80 puede enviar un mensaje de respuesta que incluye una indicacion de que la solicitud de registro se deniega.

En tales modalidades, el mensaje de respuesta que incluye una indicacion de denegacion tambien puede incluir una explicacion u otra indicacion de por que se denego la solicitud de registro. Ademas, la entidad/servidor de validacion 80 puede registrar un identificador asociado con el fabricante de token de verificacion denegado como un fabricante de token de verificacion denegado anterior o actualmente. En tales modalidades, una lista fabricantes de tokens de verificacion denegados puede almacenarse en una tabla o en la base de datos 303.Tales listas de los fabricantes de token de verificacion denegados tambien pueden incluir las razones o deficiencias por las que se denego al fabricante de token de verificacion. Si un fabricante de token de verificacion denegado presenta una nueva solicitud de validacion, la entidad/servidor de validacion 80 puede hacer referencia a la lista de los fabricantes de token de verificacion denegados ademas o en sustitucion de la aplicacion de los protocolos de gestion de riesgos o fraude.

En el caso de que el mensaje de respuesta o de registro incluye una aprobacion o validacion del fabricante de token de verificacion solicitante, el mensaje de respuesta o de registro tambien puede incluir informacion adicional respecto al fabricante, los estandares y la programacion de los tokens de verificacion registrados o validados. Por ejemplo, el mensaje de registro puede incluir un identificador del fabricante de token de verificacion, una clave espedfica de token de verificacion, la clave puede incluir un par de claves simetricas, un par de claves asimetricas, la clave o codigo semilla que debe usarse en la fabricacion y configuracion de los tokens de verificacion. En algunas modalidades, los componentes del par de claves simetricas, el par de claves asimetricas, la clave o el codigo semilla pueden firmarse por un certificado de autenticacion maestro a nombre de la entidad/servidor de validacion 80, un banco emisor 60 u otra entidad que opera la entidad/servidor de validacion 80. Por ejemplo, el fabricante de token de verificacion 305 puede recibir un mensaje de respuesta de registro que indica un identificador espedfico del fabricante, un par de claves asimetricas de los cuales el componente publico se firma por los certificados maestros a nombre de la entidad/servidor de validacion 80.El mensaje de respuesta de registro tambien puede incluir un conjunto, intervalo, o algoritmo de numeros de serie aprobados que el fabricante de token de verificacion puede asignar a los tokens de verificacion que fabrica.

En otras modalidades, el mensaje de respuesta o registro puede incluir instrucciones, direcciones, URL u otras direcciones con las que el fabricante de token de verificacion solicitante puede acceder u obtener los requisitos y especificaciones para la fabricacion de tokens de verificacion autorizados. Los requisitos, especificaciones, o

5

10

15

20

25

30

35

40

45

50

55

60

65

instrucciones pueden ser generales y aplicables a todos los fabricantes de tokens de verificacion autorizados, o pueden ser espedficos de un fabricante de token de verificacion particular. En otras modalidades, los requisitos, las especificaciones y las instrucciones enviadas o de cualquier otra manera proporcionadas a un fabricante de token de verificacion autorizado puede ser una combinacion de requisitos, especificaciones e instrucciones generales y espedficos.

Una vez que un fabricante de token de verificacion autorizado recibe un mensaje de respuesta de registro aprobado y accede a los requisitos, especificaciones e instrucciones para producir tokens de verificacion, puede comenzar a fabricar tokens de verificacion. Por ejemplo el fabricante de token de verificacion 305 puede producir tokens de verificacion de lector de banda magnetica basado en contacto 311 en la accion 5.Similarmente, los fabricantes de tokens de verificacion 307 y 309 pueden producir tokens de verificacion RFID sin contacto, asf como tambien otros tokens de verificacion inalambricos 313 y 315 de acuerdo con los requisitos, especificaciones e instrucciones espedficos proporcionados para cada fabricante de token de verificacion individual.

Por ejemplo, puede exigirse a cada fabricante de token de verificacion imprimir, grabar, almacenar, o de cualquier otra manera incluir un identificador espedfico del fabricante en cada token de verificacion que produce. Ademas, cada token de verificacion puede incluir un numero de serie del que otra informacion, tal como la informacion de encriptado, puede derivarse, o determinarse. En algunas modalidades, el numero de serie de un token de verificacion en particular puede asociarse con un algoritmo criptografico espedfico o par de claves. Los fabricantes de token de verificacion pueden compartir dicha informacion con la entidad/servidor de validacion 80.En tales modalidades, el token de verificacion, como se produce por el fabricante de token de verificacion y la entidad/servidor de validacion 80 pueden compartir informacion secreta diversa para producir, determinar, cuestionar y responder uno al otro mediante el uso de la informacion criptografica.

Cuando se fabrican los tokens de verificacion, los tokens de verificacion pueden distribuirse a los usuarios para usar con sus dispositivos portatiles de consumo compatibles, tales como tarjetas de credito, tarjetas de debito, llaveros, etc.

Una vez distribuido a un usuario, el token de verificacion puede requerirse para autenticarse por la entidad/servidor de validacion 80 antes de que pueda usarse junto con un dispositivo de consumo portatil o en cualquier tipo de transaccion sin validacion. El codigo puede incluirse en el medio legible por computadora 42 para solicitar al usuario o instruir al procesador 11 para usar y autenticar el token de verificacion. Las instrucciones, que pueden ser en soporte de papel o electronico, pueden dirigir al usuario para acoplar el token de verificacion al dispositivo de computacion del usuario, tal como una computadora portatil o de sobremesa. Una vez que el token de verificacion se acopla al dispositivo de computacion personal del usuario, el codigo ejecutable que puede incluirse en un medio legible por computadora 42 en el token de verificacion 40 puede ejecutarse por el procesador 11 de la computadora 10.En otras modalidades, el codigo ejecutable puede incluirse en un medio legible por computadora independiente, tal como una unidad basada en electromagnetica, optica, o flash, entregada junto con el token de verificacion. En otras modalidades, el codigo ejecutable puede descargarse desde la entidad/servidor de validacion 80 u otro servidor asociado con la entidad/servidor de validacion 80.En algunas modalidades, el sitio de descarga puede proporcionarse por un sitio web alojado en la entidad/servidor de validacion 80 u otro servidor asociado con la entidad/servidor de validacion 80.

En algunas modalidades, el codigo ejecutable puede incluir instrucciones para las prestaciones de red 14 de la computadora 10 para conectar con la entidad/servidor de validacion 80 sobre una o mas redes de comunicacion, tal como Internet. En tales modalidades, el codigo ejecutable puede ejecutarse de forma local en dispositivo de computacion del usuario o en un servidor remoto, tal como la entidad/servidor de validacion 80 para completar uno o mas programas o protocolos de validacion iniciales o posteriores. El codigo ejecutable puede incluir un protocolo de validacion completamente automatizado o un protocolo que requiere varias entradas de usuario o la interaccion.

Por ejemplo, el codigo ejecutable puede incluir instrucciones para proporcionar una interfaz de usuario que solicita al usuario que introduzca informacion espedfica del usuario o del token de verificacion para su presentacion a la entidad/servidor de validacion 80.En otras modalidades, el token de verificacion puede completar una validacion automatizada en un segundo plano, sin la necesidad de interaccion, interferencia, o entrada del usuario. En cualquiera de tales modalidades, los dispositivos de computacion de los usuarios pueden enviar y recibir informacion o validacion de acuerdo con los requisitos de la entidad/servidor de validacion 80 para la validacion del token de verificacion.

La Fig. 4 es un diagrama de flujo de un metodo de acuerdo con una modalidad de la presente invencion para el registro de un fabricante de token de verificacion para reducir o eliminar la posibilidad de que un fabricante de token de verificacion no autorizado duplique la informacion de la cuenta de usuario de un dispositivo de consumo portatil sin el conocimiento del usuario. Todos los fabricantes de tokens de verificacion autorizados, independientemente de que el token de verificacion se integra en un dispositivo informatico o de comunicacion o se anade como un dispositivo periferico, tal como un dispositivo USB, puede requerirse que se registren a sf mismos como fabricantes con una entidad/servidor de validacion 80 que opera dentro o en cooperacion con uno o mas sistemas de transaccion. Esta fase de configuracion y proceso de registro puede incluir las acciones descritas anteriormente en referencia a la Fig. 3.

En la accion 410 del metodo 400 que se muestra en la Fig. 4, la entidad/servidor de validacion 80 puede recibir una solicitud de un fabricante de token de verificacion para registrarse en la entidad/servidor de validacion 80 o el operador

5

10

15

20

25

30

35

40

45

50

55

60

65

de sistema de transacciones, tal como una red de procesamiento de pagos 70.A continuacion, en la accion 420, la entidad/servidor de validacion 80 o el operador del sistema de transaccion puede realizar una revision de riesgo de los fabricantes de acuerdo con varios protocolos de riesgo internos y externos. Estas revisiones pueden incluir referencias a ambas bases de datos internas y bases de datos externas o fuentes de datos tales como agencias de informes de credito, de informes de fraude, y de orden publico. Si la revision de riesgo es satisfactoria para el operador del sistema de transaccion o servidor principal, a continuacion, un par de claves espedficas del fabricante puede asignarse a cada fabricante en la accion 430.En algunas modalidades, el fabricante de token de verificacion puede generar la clave espedfica del fabricante, mientras que en otras modalidades, el operador de la entidad/servidor de validacion 80 o el sistema de transaccion puede generar la clave espedfica del fabricante. La clave espedfica del fabricante puede ser o bien un par de claves simetricas o un par de claves asimetricas.

El operador de la entidad/servidor de validacion 80 o el sistema de transaccion puede crear la clave maestra del fabricante de token de verificacion (KMC) que puede compartirse entre el fabricante y la entidad/servidor de verificacion durante el registro en la accion 440.Las claves y los pares de claves descritas en la presente descripcion pueden incluir claves simetricas, asimetricas, o de otro tipo de criptograffa.

En la accion 450, la entidad/servidor de validacion 80 puede firmar uno de los componentes del par de claves del fabricante de token de verificacion para proporcionar un nivel adicional de verificacion cuando se comunica con el token de verificacion. El fabricante de token de verificacion puede enviar una parte del par de claves espedficas del fabricante, es decir, la mitad publica del par de claves a la entidad/servidor de validacion 80 para obtener una clave espedfica del fabricante o el certificado de clave publica para vincular la clave o clave publica al fabricante de token de verificacion. El certificado de clave o clave publica puede incluir informacion espedfica del fabricante diversa. Por ejemplo, el certificado de clave publica o clave puede incluir el nombre del fabricante o identificador, direccion, numero de telefono o cualquier otra informacion que puede usarse para verificar que la clave o clave publica pertenecen al fabricante.

En tales modalidades, la entidad/servidor de verificacion 80 o el fabricante de token de verificacion 305, 307, o 309 o el token de verificacion comparten un secreto. La entidad/servidor de validacion 80 puede entonces enviar la clave espedfica del fabricante de token de verificacion, con o sin el componente firmado, al fabricante de token de verificacion registrado/aprobado. Opcionalmente, la entidad/servidor de validacion 80 puede enviar las especificaciones de fabricacion, requisitos o numeros de serie a los fabricantes de token de verificacion registrados de acuerdo con los cuales los fabricantes de token de verificacion registrados pueden producir tokens de verificacion.

Una vez que se registra un fabricante, puede empezar a crear tokens de verificacion. La Fig. 5 es un diagrama de flujo de un metodo 500 para la fabricacion de tokens de verificacion de acuerdo con una modalidad de la presente invencion. El metodo 500 puede realizarse por un fabricante de token de verificacion que se registra o de cualquier otra manera se aprueba por una entidad/servidor de validacion. Para cada token de verificacion, el fabricante de token de verificacion puede generar o producir un numero de serie en la accion 510.En algunas modalidades, los numeros de serie pueden generarse o de cualquier otra manera seleccionar de un conjunto de numeros de serie asignados al fabricante de token de verificacion. En tales modalidades, el conjunto de numeros de serie puede representarse por un conjunto finito de numeros, un algoritmo para la produccion de numeros de serie al azar o casi al azar u otra metodologfa para la produccion de numeros de serie que pueden o no, estar asociados con el fabricante de token de verificacion. En modalidades en las que el conjunto de numeros de serie se asocian con el fabricante de token de verificacion, la entidad/servidor de validacion 80 puede usar el numero de serie del token de verificacion para determinar el fabricante de token de verificacion y/o la informacion espedfica del token de verificacion, tal como el par de claves espedficas de token de verificacion o la clave maestra del fabricante de token de verificacion (KMC) o certificado que puede usarse para cifrar o descifrar la informacion enviada entre el fabricante de token de verificacion y el token de verificacion.

Algunas modalidades pueden usar un requisito de certificado estandar PKCS, el certificado/firma puede incluir (1) un numero de serie de token de verificacion y (2) un nombre de fabricante o identificador. Ademas, el fabricante puede derivar una clave con base en el KMC y el numero de serie del token de verificacion y estos pueden almacenarse en el medio legible por computadora 42 en el token de verificacion. Los tokens de verificacion pueden enviarse y distribuirse.

En la accion 520, el fabricante de token de verificacion puede generar un par de claves para cada token de verificacion, sus fabricantes o emisores. El par de claves puede incluir un componente publico y uno privado. El par de claves puede ser un par de claves simetricas o asimetricas. El par de claves puede ser el token de verificacion espedfico y unico para el fabricante de token de verificacion que hizo el token de verificacion. En otras modalidades, el par de claves para un token de verificacion en particular puede ser unico en todos los tokens de verificacion, independientemente del fabricante de token de verificacion que hizo el token de verificacion.

Para obtener un nivel adicional de seguridad, cada componente del par de claves del token de verificacion escrita o almacenada en el token de verificacion puede firmarse por un certificado CA o maestro o una clave privada en la accion 530 para crear el certificado publico del token de verificacion. Espedficamente, la clave publica del token de verificacion puede firmarse por la clave privada del fabricante de token de verificacion. En tales modalidades, el certificado publico del token de verificacion puede incluir el numero de serie del token de verificacion u otro identificador.

En algunas modalidades, la clave rafz de CA o maestra se asocia con el fabricante de token de verificacion, mientras

11

5

10

15

20

25

30

35

40

45

50

55

60

65

que en otras modalidades, la clave ra^z de CA o maestra puede asociarse con una entidad/servidor de validacion. En tales modalidades, la componte publica firmada de la clave rafz de CA o maestra del par de claves del token de verificacion puede verificarse y/o desencriptarse por una entidad/servidor de validacion.

Una vez que el par de claves, numero de serie y/o el certificado de clave publica se generan para el token de verificacion, todos o algunos componentes del par de claves, numero de serie y/o el certificado publico pueden almacenarse o escribirse en una memoria en el token de verificacion en la accion 540.Similarmente, el certificado publico del token de verificacion y/o la clave publica del fabricante tambien pueden almacenarse en el token de verificacion. En algunas modalidades, solo un componente del par de claves se almacena o se escribe en el token de verificacion. En tales modalidades, es ventajoso para escribir y/o almacenar el componente publico o el componente publico firmado del par de claves en el token de verificacion, mientras se mantiene secreto el componente privado. El almacenamiento de los componentes del par de claves, u otra informacion, en el token de verificacion puede incluir almacenar informacion en una memoria o memoria protegida.

Una vez que se genera el par de claves y se escribe o se almacena en el token de verificacion, los componentes privados del par de claves pueden compartirse entre el fabricante de token de verificacion, la entidad/servidor de validacion u otra entidad de confianza. En algunas modalidades, la informacion compartida puede incluir una asociacion del par de claves al numero de serie, el fabricante de verificacion o un identificador del fabricante de token de verificacion.

Opcionalmente, el numero de serie y un identificador del fabricante pueden almacenarse/ escribirse en la memoria en el token de verificacion en la accion 55o.Por ultimo, en la accion 560, el fabricante de token de verificacion puede tambien escribir/almacenar software de validacion ejecutable y/o una direccion web para un servidor de validacion de autenticacion en la memoria o la memoria protegida del token de verificacion. El codigo de software ejecutable puede incluir instrucciones para dirigir un procesador en una computadora en la que el token de verificacion puede conectarse para iniciar cada sesion de comunicacion sobre un medio de comunicacion a traves de las prestaciones de comunicacion de la computadora para validar el token de verificacion.

Cada vez que un usuario elige, pero sobre todo en la recepcion de un nuevo token de verificacion, el o ella pueden iniciar uno o mas procesos para registrar y/o validar el token de verificacion. La Fig. 6 es un esquema de un sistema 600 que puede usarse para validar y/o autenticar un token de verificacion 40.Antes de que el dispositivo de consumo portatil 5 se presenta al token de verificacion 40 para iniciar una transaccion, el usuario puede obligarse, o elegir primero validar y/o autenticar el token de verificacion 40 en la entidad/servidor de validacion 80.

En algunas modalidades, para validar el token de verificacion 40 el usuario puede (1) iniciar sesion en un sitio web operado por la entidad/servidor de validacion 80; (2) usar HTTPS u otro protocolo de seguridad, el sitio web puede indicar al usuario que introduzca el token de verificacion si el usuario no lo ha hecho ya; (3) el sitio web puede solicitar y validar la certificacion del token de verificacion o el par de claves/componentes del par de claves mediante el uso de las claves del fabricante; (4) a continuacion, el sitio web puede generar un numero aleatorio y solicitar el token de verificacion para firmar este numero; (5) el sitio web puede validar la firma y mostrar un mensaje al usuario de que el token de verificacion es valido; y (6) el sitio web tambien puede mostrar el numero de serie del token de verificacion que puede grabarse en el propio token de verificacion.

En otras modalidades, el usuario puede instruirse para ir a un sitio web de validacion. La sugerencia puede venir en forma de una carta, un correo electronico, un SMS o mediante un codigo ejecutable o archivo estatico almacenado en el token de verificacion. La instruccion puede o no incluir un hiperenlace a la web. Es ventajoso que la instruccion no incluya un hiperenlace o URL y simplemente un mensaje que indica al usuario iniciar sesion en un sitio web de confianza en el que el usuario ya puede tener una cuenta registrada. Este aspecto manual de navegar a la pagina web de validacion ayuda a evitar que los estafadores o los fabricantes de tokens de verificacion fraudulentos dirijan a los usuarios a una pagina web falsa o fraudulenta y enganen a los usuarios para "validar" el token de verificacion fraudulento con el sitio web falso para duplicar la informacion confidencial del usuario. Mientras se visualiza el sitio web de validacion, puede solicitarse al usuario que introduzca un numero aleatorio o semialeatorio. El numero aleatorio puede generarse por el servidor de validacion, el sitio web, la computadora del usuario, el token de verificacion o simplemente ser un numero de eleccion del usuario.

El numero aleatorio puede enviarse al lector de token de verificacion y firmarse por una de las claves de token de verificacion, es decir, la clave privada. Entonces, el lector puede devolver el numero firmado, el certificado publico del lector y el certificado de clave publica del fabricante a la entidad/servidor de 80.La entidad/servidor de validacion 80 puede validar a continuacion, el certificado de clave publica del fabricante mediante el uso de la clave maestra o rafz de la entidad/servidor de validacion 80.La entidad/servidor de validacion 80 tambien puede extraer y validar la clave publica del lector mediante el uso de la clave publica del fabricante. La entidad/servidor de validacion 80 puede entonces validar el numero de serie y el nombre o el identificador del fabricante contra el registro de los fabricantes de tokens de verificacion autenticados o registrados. Finalmente, la entidad/servidor de validacion 80 puede validar el numero aleatorio firmado mediante el uso de la clave publica del token de verificacion.

En otra modalidad, el usuario puede conectar el token de verificacion 40 a la computadora 10 a traves de una interfaz periferica. Una vez conectado a la computadora 10, el token de verificacion 40 automaticamente o incitado por el

5

10

15

20

25

30

35

40

45

50

55

60

65

usuario puede iniciar uno o mas segmentos de codigo ejecutable mediante el uso del procesador de la computadora 10 o un procesador incorporado en el token de verificacion 40.En cualquiera de tales modalidades, la computadora 10 puede enviar una solicitud de validacion a la entidad/servidor de validacion 80 mediante el uso de sus prestaciones de comunicaciones sobre un medio de comunicacion, tal como Internet, en la accion 1.La solicitud de validacion puede incluir informacion publica y secreta diversa respecto al token de verificacion 40.Por ejemplo, la solicitud de validacion puede incluir el componente publico del par de claves espedficas del token de verificacion 40, el numero de serie del token de verificacion 40, un numero aleatorio generado y/o firmado por el token de verificacion 40 la computadora 10 o una consulta de cuestionamiento.

La entidad/servidor de validacion 80 puede recibir la solicitud de validacion de la computadora 10 en la accion 2.La entidad/servidor de validacion 80 puede recibir la solicitud de validacion a traves de cualquier medio de comunicacion adecuado que conecta la computadora 10 a la entidad/servidor de validacion 80.En algunas modalidades, la entidad/servidor de validacion 80 puede analizar varias piezas de informacion a partir de la solicitud de validacion. Por ejemplo, la entidad/servidor de validacion 80 puede analizar el componente publico del par de claves espedficas del token de verificacion 40, el numero de serie del token de verificacion 40, un numero aleatorio generado y/o firmado por el token de verificacion 40 o la computadora 10 o una consulta de cuestionamiento. Con base en la informacion analizada a partir de la solicitud de validacion, la entidad/servidor de validacion 80 puede recuperar o de cualquier otra manera producir la informacion asociada con el token de verificacion 40.

Por ejemplo, la entidad/servidor de validacion 80 puede usar el numero de serie del token de validacion 40 para producir, determinar y/o recuperar un componente privado de un par de claves asociadas con el token de verificacion 40.En otras modalidades, la entidad/servidor de validacion 80 puede usar un identificador de fabricante analizado a partir de la solicitud de validacion para determinar si el numero de serie en la solicitud de validacion es consistente con los numeros de serie asignados y/o producidos por ese fabricante de token de verificacion. La entidad/servidor de validacion 80 puede usar cualquier y toda la informacion analizada a partir de la solicitud de validacion para recuperar toda la informacion asociada a un token de verificacion particular 40, el fabricante del token de verificacion o un usuario asociado con el token de verificacion 40.

En algunas modalidades, la entidad/servidor de validacion 80 puede analizar un identificador de token de verificacion o el numero de serie para el token de verificacion 40 a partir de la solicitud de validacion en la accion 2.La entidad/servidor de validacion 80 puede comprobar si el identificador de token de verificacion o el numero de serie analizado se valida previamente en la accion 3.En algunas modalidades, si el identificador de token de verificacion o numero de serie analizado se valida previamente, la entidad/servidor de validacion 80 puede devolver un mensaje de validacion a la computadora 10 en la accion 4, en cuyo punto, el usuario puede presentar un dispositivo de consumo portatil 5 a un token de verificacion 40 para iniciar una transaccion. En otras modalidades, la entidad/servidor de validacion 80 puede, junto con el mensaje de validacion, enviar la instruccion de actualizacion de informacion del token de verificacion.

En algunas modalidades, la instruccion de actualizacion de informacion del token de verificacion puede incluir el codigo legible por computadora para instruir al procesador de computadora 10 para volver a escribir una parte o toda la informacion almacenada en el token de verificacion 40.Por ejemplo, uno o mas componentes de la pareja de claves asociadas con el token de verificacion 40 pueden reemplazarse con los nuevos componentes de un par de claves reden asociados con el token de verificacion 40.Las actualizaciones de la informacion del token de verificacion almacenada en el token de verificacion 40 puede permitirse o limitarse solamente a la entidad/servidor de validacion 80 cuando pueda establecer una sesion de comunicacion de sesion de clave segura.

En algunas modalidades, en la accion 3, la entidad/servidor de validacion 80 puede realizar una autenticacion mutua y establecer una sesion de clave con la computadora 10.La clave de sesion entre la computadora 10 y la entidad/servidor de validacion 80 puede establecerse por la entidad/servidor de validacion 80 al generar un numero aleatorio u otro mensaje de cuestionamiento, firmar ese numero al azar o mensaje de cuestionamiento con el componente del par de claves asociado con el token de verificacion 40 y enviar la informacion firmada de vuelta al token de verificacion 40.El token de verificacion 40 puede descifrar la informacion firmada y enviar de vuelta la respuesta correcta de acuerdo con la desencriptacion mediante el uso del componente del par de claves almacenado en el token de verificacion 40.

En algunas modalidades, el componente del par de claves almacenado en el token de verificacion 40 se firma por una clave rafz de CA o maestra asociada con el fabricante de token de verificacion o la entidad/servidor de validacion 80. En tales modalidades, la respuesta desencriptada recibida del token de verificacion 40 debe entonces desencriptarse mediante el uso de la clave rafz de CA o maestra para autenticar aun mas la autenticidad del token de verificacion 40. En cualquiera de estas modalidades, la entidad/servidor de validacion 80 puede recibir la respuesta del token de verificacion 40.Con base en la respuesta recibida del token de verificacion 40, la entidad/servidor de validacion 80 puede determinar si el token de verificacion 40 es autentico, valido o de cualquier otra manera producido por un fabricante de token de verificacion de confianza que experimenta y recibe la autorizacion para producir tokens de verificacion. Si se determina que el token de verificacion 40 es valido, entonces puede usarse con el dispositivo portatil de consumo 5 para iniciar las transacciones. Un mensaje a este efecto puede enviarse a la computadora 10 desde la entidad/servidor de validacion 80 para ademas activar el token de verificacion 40 o instruir la computadora 10 para usar posteriormente el token de verificacion 40 para iniciar una transaccion, en la accion 4.

En los eventos que el token de verificacion 40 se determina que es fraudulento o de cualquier otra manera invalido, ese

13

5

10

15

20

25

30

35

40

45

50

55

60

65

token de verificacion, o cualquier informacion asociada a este, tales como el numero de serie o identificacion del token de verificacion, puede enumerarse como un token de verificacion potencialmente fraudulento y se bloquea para su uso para las transacciones.

En el caso de que el token de verificacion 40 no se ha validado previamente por la entidad/servidor de validacion 80, la entidad/servidor de validacion 80 puede almacenar el numero de serie o identificador del token de verificacion recien validado en una base de datos 603 para su posterior recuperacion y confirmacion de la validacion previa del token de verificacion 40 en la accion 5.En algunas modalidades, la entidad/servidor de validacion 80 puede informar a la entidad bancaria emisora 60 que el token de verificacion 40 se ha validado exitosamente por la entidad/servidor de validacion 80 para iniciar transacciones mediante el uso del dispositivo portatil de consumo 5 en la accion 6.Alternativamente, el banco emisor 60 puede informarse de que un token de verificacion portatil potencialmente fraudulento intenta validarse.

Los metodos, sistemas y servidores de acuerdo con diversas modalidades de la presente invencion incluyen ventajas sobre los medios existentes para disuadir o detener los estafadores de introducir tokens de verificacion fraudulentos en el flujo comercial para duplicar la informacion sensible del usuario. Diversas modalidades de la presente invencion incluyen los esquemas de validacion de multiples capas o de multiples partes para impedir a los estafadores producir y validar tokens de verificacion fraudulentos que podnan enganar a una entidad/servidor de validacion, lo que reduce asf, aun mas, la posibilidad de duplicar la informacion del usuario. Por ejemplo, el certificado publico del fabricante producido por la entidad/servidor de validacion y almacenado en el token de verificacion puede ayudar a asegurarse mejor de que la entidad/servidor de validacion tiene una interaccion de autenticacion previa con el fabricante del token de verificacion en particular. Entonces solamente la entidad/servidor de validacion que tiene acceso a la clave rafz de CA o maestra espedfica del fabricante o el certificado rafz de CA puede recuperar, desencriptar o de cualquier otra manera extraer la clave publica del token de verificacion del certificado publico del token de verificacion mediante el uso de la clave publica del fabricante recuperada/generada con base en la validacion del certificado de clave publica del fabricante.

El certificado de clave publica del fabricante, o los medios para generar uno, es decir, la clave rafz de CA o maestra o el certificado de la entidad/servidor de validacion, no estana disponible para un fabricante de token de verificacion no autenticado, y asf, tal fabricante fraudulento no podna generar un certificado que podna usarse para generar/validar un certificado publico de token de verificacion autentico o la clave publica de token de verificacion que coincidina con la clave privada almacenada en el token de verificacion. Sin tal informacion, un usuario que visita un sitio web de confianza para validar un token de verificacion no podna ser enganado en la validacion de un token de verificacion fraudulento, o de cualquier otra manera no autentico. Estas caractensticas aumentan en gran medida la seguridad de los tokens de verificacion usados para realizar transacciones financieras y de otro tipo mediante el uso de dispositivos portatiles de consumo, es decir, las tarjetas de credito y de debito, iniciadas desde un terminal de usuario en un lugar separado de un establecimiento comercial u otra entidad que de cualquier otra manera podnan verificar la autenticidad del dispositivo de consumo portatil o usuario. Estas caractensticas pueden ademas mejorarse al requerir que el usuario manualmente o de cualquier otra manera navegue independientemente a un sitio web para iniciar el proceso de validacion a fin de reducir la posibilidad de que un token de verificacion fraudulento navegue automaticamente a un sitio web de validacion fraudulento.

La Fig. 7 es un diagrama de flujo de un metodo 700 para realizar un primer uso o registro de un token de verificacion. Durante el proceso descrito anteriormente, la entidad/servidor de validacion puede comprobar si el token de verificacion se valida previamente. Si el numero de serie no esta en una base de datos de tokens de verificacion previamente validados, el siguiente procedimiento puede realizarse antes de usarlo por primera vez.

En la accion 710 la entidad/servidor de validacion puede obtener la clave del token de verificacion mediante el numero de serie y la clave rafz de CA o maestra registrada en la entidad/servidor de validacion para ese fabricante de token de verificacion. En la accion 720, la entidad/servidor de validacion puede realizar una autenticacion mutua y establecer una clave de sesion mediante el uso ya sea de una clave de token de verificacion derivada o un procedimiento estandar con base en Global Platform SCPOI o 02 o el estandar de personalizacion de tarjetas EMVCO.A continuacion, en la accion 730, si la autenticacion mutua es exitosa, entonces el token de verificacion puede permitir el acceso de lectura, escritura y actualizacion.

En la accion 740, bajo la clave de sesion, la entidad/servidor de validacion puede reemplazar el componente clave existente almacenado en el token de verificacion con un nuevo componente clave derivado mediante el uso del numero de serie del token de verificacion y una clave maestra (MDK).Cualquier otro dato necesario puede escribirse en este punto y el usuario puede registrarse opcionalmente en este momento. En la accion 750, el token de verificacion puede permitir el acceso de escritura/actualizacion si tiene lugar la autenticacion mutua con el nuevo componente clave. Por ultimo, en la accion 760, la entidad/servidor de validacion puede registrar el numero de serie del token de verificacion en la base de datos de token de verificacion.

La respuesta a una solicitud de validacion inicial o primera puede ser una primera prueba de validacion o registro para validar el token de verificacion 40.Para iniciar la validacion o solicitud de registro, el token de verificacion 40 puede enviar su numero de serie a la entidad/servidor de validacion 80, junto con un mensaje o a solicitud de validacion encriptada por una clave, con el mensaje y la clave que son un secreto compartido entre el token de verificacion 40 y la entidad/servidor de validacion 80 (es decir, no se conoce publicamente).En algunas modalidades, la clave puede

5

10

15

20

25

30

35

40

45

50

55

60

65

asociarse unicamente con el numero de serie del token. La clave puede ser una clave de encriptacion simetrica que incluye una o un par de claves asimetricas.

La entidad/servidor de validacion 80 puede tener o tener acceso a una base de datos de numeros de serie y las claves asociadas correspondientes o algoritmos almacenados para generar las claves, y puede validar que el token de verificacion 40 envfa el mensaje correcto para el numero de serie. Para ello, el token de verificacion 40 puede comprender un numero de serie y la clave unica integrada en un medio legible por computadora o memoria, la clave unica que es unica para el token de verificacion 40, y el codigo que dirige al procesador de datos 41 para enviar el numero de serie y un mensaje encriptado por la clave unica a la entidad/servidor de validacion 80.

El mensaje puede almacenarse previamente en el medio legible por computadora, o derivable/determinable a partir de la informacion conocida tanto por el token de verificacion 40 como por la entidad/servidor de validacion 80, tal como un mensaje derivado a partir de un algoritmo aplicado a la fecha actual, el numero de serie del token 40, y/o la clave de sesion de la sesion de comunicacion entre el token 40 y la entidad/servidor de validacion 80.De esta manera, el mensaje enviado por el token 40 a la entidad/servidor de validacion 80 es verificable por la entidad/servidor de validacion 80 mediante el uso de la informacion almacenada en la entidad de validacion. El medio legible por computadora o memoria para las tareas anteriores pueden situarse en el medio legible por computadora 42 y/o el modulo de seguridad 43.Los codigos anteriores pueden incluir instrucciones de E/S en el modulo de seguridad 43, y las llamadas de funcion a la API del modulo de servicios de red de la computadora.

Opcionalmente, el token de verificacion 40 puede enviar, de manera ocasional, una o mas piezas de informacion unica de maquina de la computadora 10 a la entidad/servidor de validacion 80, que puede comprobar esta informacion contra una base de datos de informacion de computadora asociada con los estafadores conocidos. Dicha informacion unica de maquina puede incluir los numeros de serie de los procesadores, las unidades de disco y los sistemas operativos de la computadora 10.El token de verificacion 40 puede comprender codigo que dirige al procesador de datos 41 para obtener una o mas piezas de informacion unica de maquina de la computadora 10, y enviar la informacion espedfica de maquina a la entidad/servidor de validacion 80.Este codigo puede incluir llamadas de funcion a la API del sistema operativo del equipo para obtener la informacion, y la llamada de funcion a la API del modulo de servicios de red de la computadora para enviar la informacion a la entidad/servidor de validacion 80.

Como otra opcion, el token de verificacion 40 puede configurarse para solicitar al usuario 1 una contrasena para activar una o mas caractensticas del token 40.La contrasena puede almacenarse en un medio legible por computadora situado en el modulo de seguridad 43 o en un medio legible por computadora 42.La contrasena puede proporcionarse al usuario 1 en un pedazo de papel por el fabricante del token de verificacion, proveedor o vendedor del token 40. El token 40 puede enviarse al usuario 1 a traves del correo, por o en nombre de un banco emisor, o puede comprarse por el usuario 1 en una tienda. El token 40 puede configurarse para requerir que se escriba la contrasena cada vez que el usuario desea presentar un dispositivo de consumo portatil 5, y/o cada vez que el token 40 se acopla a un computadora 10.Para ello, el token de verificacion 40 puede comprender, ademas, codigo incorporado en el medio legible por computadora 42 que dirige al procesador de datos 41 para solicitar al usuario que introduzca una contrasena en un teclado de computadora 10, leer una contrasena introducida por el usuario, y comparar la contrasena introducida con una contrasena almacenada incorporada en el medio legible por computadora. Este codigo puede comprender las llamadas de funcion de la API a la interfaz grafica de usuario del sistema operativo de la computadora 10 para abrir un cuadro de visualizacion en la interfaz de usuario 13 para solicitar y recibir una contrasena del usuario 1, las instrucciones de E/S, las instrucciones de acceso a memoria, y las instrucciones logicas y de control de la CPU. El token de verificacion 40 puede comprender ademas uno o mas de los siguientes:

(1) el codigo incorporado en un medio legible por computadora 42 que dirige al procesador de datos 41 para iniciar y/o permitir la comunicaciones descritas anteriormente con la computadora 10 en respuesta a una contrasena introducida que coincide con la contrasena almacenada;

(2) el codigo incorporado en un medio legible por computadora 42 que dirige al procesador de datos 41 para iniciar y/o permitir las comunicaciones descritas anteriormente con la entidad/servidor de validacion 80 en respuesta a una contrasena introducida que coincide con la contrasena almacenada;

(3) el codigo incorporado en un medio legible por computadora 42 que dirige al procesador de datos 41 para activar el lector 44 y/o para aceptar la informacion de identificacion del lector 44 en respuesta a una contrasena introducida que coincide con la contrasena almacenada; y

(4) el codigo incorporado en un medio legible por computadora 42 que dirige al procesador de datos 41 para iniciar y/o permitir la transmision descrita anteriormente de la informacion de identificacion a la entidad/servidor de validacion 80 en respuesta a la contrasena introducida que coincide con la contrasena almacenada.

Estos codigos pueden incluir instrucciones de E/S, instrucciones de acceso a memoria, y las instrucciones logicas y de control de la CPU. Las instrucciones, solas o en combinacion, evitan la transmision de la informacion de identificacion a la entidad/servidor de validacion 80 cuando la contrasena introducida no es la misma que la contrasena almacenada, y de esta manera comprenden codigo incorporado en el medio legible por computadora que dirige al procesador de datos para hacerlo. Un experto en la tecnica sera capaz de construir las instrucciones y las llamadas de funcion de la API para

5

10

15

20

25

30

35

40

45

50

55

60

65

implementar los codigos descritos anteriormente en vista de esta descripcion sin experimentacion excesiva. Como proteccion adicional, el token de verificacion 40 puede comprender ademas el codigo integrado en el medio legible por computadora 42 que dirige al procesador de datos 41 para establecer un nombre de usuario para el token mediante la presentacion al usuario 1 de un cuadro de dialogo para recibir la entrada que designa un nombre de usuario, y mediante el almacenamiento del nombre de usuario en el medio legible por computadora 42.

Los codigos anteriores para el procesamiento de la contrasena pueden aumentarse aun mas para incluir solicitar un nombre de usuario para el token y comparar el nombre de usuario recibido con el nombre de usuario almacenado para una coincidencia, y que incluye una coincidencia como una condicion que debe cumplirse en cada uno de los cuatro codigos anteriores que inician o permiten que se realicen diversas acciones. Estos codigos pueden incluir instrucciones de E/S, instrucciones de acceso a memoria, y instrucciones logicas y de control de la CPU.

En cada una de las modalidades descritas en la presente descripcion relativo al token de verificacion 40, el token de verificacion 40 puede enviar la informacion de identificacion correspondiente al dispositivo de consumo portatil 5 de la computadora l0 en un numero de formas, que incluyen:(1) la forma inalterada ( "forma clara"), (2) la forma encriptada, (3) formada con HASH (por ejemplo, codificada), (4) la forma firmada, (5) o cualquier combinacion de estas formas. Estas formas pueden generarse por el dispositivo portatil de consumo 5, el token de verificacion 40, la computadora 10, o cualquier combinacion de los mismos. Ademas, el token de verificacion 40 y la entidad/servidor de validacion 80 pueden realizar un proceso de autenticacion mutua antes de que el token de verificacion 40 envfe la informacion de identificacion.

En cada una de las modalidades descritas en la presente descripcion relativas al token de verificacion 40, los codigos anteriores del token 40 y la informacion de identificacion lefdos del dispositivo 5 por el token 40 pueden almacenarse independientemente de la computadora 10 y pueden protegerse de programas (como software espfa y otros programas maliciosos) que se ejecutan en la computadora 10.En tales implementaciones, la informacion de identificacion se pone en forma segura (por ejemplo, encriptada, con HASH, firmada, o combinacion de las mismas) mediante el token de verificacion 40 antes de que la informacion se proporcione a la computadora 10.

En consecuencia, proteger la informacion no depende de la seguridad de la computadora 10.Las claves simetricas o asimetricas pueden usarse para el encriptado y firma. Las claves para un token de verificacion 40 pueden ser unicas con respecto a otros tokens de verificacion (es decir, las claves para un token pueden ser unicas para ese token). Las claves para un token, y particularmente las claves simetricas, pueden basarse en un numero de serie asignado unicamente para el token de verificacion, que el token puede comunicar a la entidad/servidor de validacion 80 en una comunicacion inicial. Tanto el token de verificacion como la entidad/servidor de validacion pueden tener un secreto compartido sobre la manera de obtener una clave a partir del numero de serie del token, tal como mediante la manipulacion y/o el reemplazo de dfgitos seleccionados del numero de serie. Un numero de claves puede derivarse del numero de serie unico mediante el uso de los respectivos secretos compartidos. Asf, los mensajes de cuestionamiento y respuesta usados en un proceso de autenticacion mutua entre un token de verificacion y una entidad/servidor de validacion pueden firmarse mediante el uso de las claves derivadas respectivas del numero de serie del token de verificacion.

La Fig. 8 es un esquema de un sistema para la actualizacion de la informacion almacenada en un medio legible por computadora o la memoria en el token de verificacion 40. En la accion 1, token de verificacion 40 puede conectarse a la computadora 10 a traves de un usuario. Una vez que el token de verificacion 40 se conecta a la computadora 10, a traves de una interfaz periferica u otra interfaz de comunicacion, el token de verificacion 40 puede establecer un enlace de comunicaciones con la computadora 10.En algunas modalidades, la interfaz periferica puede incluir una interfaz USB o FireWire™, asf como tambien cualquier otra interfaz de bus periferica o interna adecuada para el establecimiento de la comunicacion y la transferencia de informacion entre el token de verificacion 40 y la computadora 10.

Mediante el uso del enlace de comunicacion entre el token de verificacion 40 y la computadora 10, el token de verificacion 40, o el procesador incluido afu, puede instruir a la computadora 10 para establecer una sesion de comunicacion entre el token de verificacion y una entidad/servidor de validacion mediante el uso de la interfaz de red de la computadora en la accion 920.En tales modalidades, la interfaz/instalacion de red de la computadora 10 puede conectarse a traves del medio de comunicacion tal como una red informatica privada o la Internet. En tales modalidades, el token de verificacion 40 puede comprender el codigo ejecutable que incluye instrucciones para el procesador del token de verificacion 40 o el procesador de la computadora 10 para establecer la comunicacion mediante el uso de la interfaz de red de la computadora 10.En algunas modalidades, el codigo puede incluir una URL u otra direccion para ponerse en contacto con un sitio web u otro servicio operado por la entidad/servidor de validacion 80.

Una vez que se establece el enlace de comunicacion entre el token de verificacion 40 y la entidad/servidor de validacion 80, la computadora 10 puede descargar el codigo ejecutable desde la entidad/servidor de validacion 80 que incluye instrucciones para proporcionar a un usuario diversas indicaciones que aparecen en la pantalla de la computadora 10 en la accion 930.El codigo ejecutable puede incluir HTML u otro codigo universalmente ejecutable en una computadora mediante el uso de un navegador web u otra aplicacion de comunicacion basada en la web. Las instrucciones para el usuario pueden incluir instrucciones para el usuario para iniciar, continuar o concluir una solicitud de validacion del token de verificacion 40.Ejemplo, la computadora 10 puede pedir al usuario que introduzca el numero de serie del token de verificacion 40 impreso en el exterior del token de verificacion 40.En algunas modalidades, el numero de serie impreso,

5

10

15

20

25

30

35

40

45

50

55

60

65

grabado o estampado en el token de verificacion 40 es el mismo que un numero de serie almacenado en el medio legible por computadora o la memoria en el token de verificacion 40.En otras modalidades, el numero de serie impreso, grabado o estampado en el token de verificacion 40 es diferente o una variacion de un numero de serie almacenado en el medio legible por computadora o la memoria en el token de verificacion 40.

Si el usuario entra la entrada apropiada para la(s) solicitud(es) y la entrada, o una version cifrada de la entrada, coincide con la informacion almacenada en el token de verificacion 40 y/o la entidad/servidor de validacion 80, a continuacion, una clave de sesion puede establecerse entre el token de verificacion 40 y la entidad/servidor de validacion 80.En algunas modalidades, la entrada en respuesta al pedido puede incluir una contrasena conocida solo por el(los) usuario(s) autorizado(s) y la entidad/servidor de validacion 80, mientras que en otras modalidades, la entrada en respuesta al pedido puede incluir algunos o todos los numero de serie lefdos desde el exterior o en la memoria del token de verificacion 40.Una vez establecida la clave de sesion, la entidad/servidor de validacion 80 puede iniciar el reemplazo de la clave existente u original derivada del numero de serie del token de verificacion y/o la clave maestra de la entidad/servidor de validacion o el certificado en la accion 940.Si, bajo la sesion de clave, el token de verificacion 40 y la entidad/servidor de validacion 80 pueden realizar una autenticacion mutua, entonces el token de verificacion puede permitir a la entidad/servidor de validacion 80 reemplazar la clave original con una nueva clave en la accion 950.En algunas modalidades, puede solicitarse al usuario que permita o deniegue el reemplazo de la clave existente en el token de verificacion 40 con la nueva clave de la entidad/servidor de validacion 80.Por ultimo, la entidad/servidor de validacion 80 puede registrar el numero de serie del token de verificacion 40 con la base de datos del token de verificacion para la referencia futura y el token de verificacion 40 enviar otra solicitud de validacion de vez en cuando en la etapa 960.La base de datos del token de verificacion puede incluir asociaciones entre el numero de serie original, la clave original, y cada iteracion o clave de reemplazo se asocia o se ha asociado al token de verificacion 40.

La Fig. 10 es un diagrama de flujo de un metodo 1000 de un metodo para usar una entidad/servidor de validacion 80 para validar un token de verificacion 40 de acuerdo con diversas modalidades de la presente invencion. El metodo 1000 comienza en la accion 1010, en la que la entidad/servidor de validacion 80 establece un enlace de comunicacion con un token de verificacion mediante el uso de una instalacion de red de la entidad/servidor de validacion 80.En algunas modalidades, se establece el enlace de comunicacion entre las entidades/servidores de validacion 80 y la computadora 10 a la que se conecta el token de verificacion 40.En otras modalidades, el token de verificacion 40 y la entidad/servidor de validacion 80 se conectan directamente a traves de una conexion ffsica o una conexion inalambrica, tal como WiFi™, Bluetooth™, GSM, CDMA, 3G, 4G, u otros datos inalambricos o protocolo de comunicacion. En el enlace de comunicacion establecido, la entidad/servidor de validacion 80 puede recibir una informacion de identificacion encriptada y/o la informacion del token de verificacion enviada por un token de verificacion 40 en la accion 1020.Como se describio anteriormente, la informacion de identificacion encriptada o sin encriptar y/o la informacion del token de verificacion puede incluir un numero de serie, mensaje de autenticacion, un identificador de fabricante de token de verificacion y cualquier otra informacion que puede usarse por la entidad/servidor de validacion 80 para realizar una autenticacion mutua con el token de verificacion 40.

En la accion 1030, la entidad/servidor de validacion 80 puede analizar o desencriptar la informacion de identificacion recibida y/o la informacion del token de verificacion. Para analizar la informacion recibida, la entidad/servidor de validacion 80 puede usar la informacion asociada al token de verificacion del que se recibio la informacion. En algunas modalidades, la informacion asociada al token de verificacion incluye una clave de delimitacion que indica a la entidad/servidor de validacion como analizar la informacion recibida en segmentos de datos constitutivos. Por ejemplo, la informacion asociada puede incluir una lista de segmentos de datos constitutivos, delimitadores, y la forma de los datos, es decir, una tabla de cadenas delimitado con coma. En otras modalidades, la informacion asociada al token de verificacion puede incluir una clave simetrica o asimetrica correspondiente que se empareja con la clave asimetrica almacenada o enviada desde el token de verificacion. La informacion asociada puede incluir tambien una clave maestra espedfica del fabricante que se uso para firmar el componente de clave almacenado en el token de verificacion. La clave maestra puede usarse, en combinacion con el componente clave correspondiente asociado con el token de verificacion que no se almacena en el token de verificacion, para descifrar la informacion firmada por el componente clave almacenado en el token de verificacion.

La entidad/servidor de validacion puede aplicar al menos una de las pruebas de validacion descritas anteriormente para la informacion desencriptada en la etapa 1040.Con base en los resultados de la prueba o pruebas de validacion, la entidad/servidor de validacion puede comprobar el valor/mensaje para el token de verificacion. Si se pasan las pruebas o de cualquier otra manera se consideran satisfactorias, entonces el valor/mensaje de verificacion puede indicar al token de verificacion que la entidad/servidor de validacion es de confianza y debe permitirse el acceso de lectura, escritura o reemplazo de la informacion almacenada en el token de verificacion. En otras modalidades, el valor/mensaje de verificacion puede incluir informacion que puede usarse para anadir, modificar o reemplazar la informacion almacenada en el token de verificacion. En diversas modalidades, un procesador incluido en el token de verificacion o la computadora a la que se conecta puede iniciar la lectura, escritura o el reemplazo de la informacion almacenada en el token de verificacion. En tales modalidades, la informacion puede incluir un reemplazo o un nuevo componente clave que se puede usar para futuras transacciones y la solicitud de validacion enviada mediante el uso del token de verificacion. En las modalidades correspondientes, el reemplazo o nuevo componente clave y el nuevo componente clave correspondiente, es decir, los pares de claves simetricas o asimetricas, pueden almacenarse para futuras referencias en las solicitudes de validacion o de transaccion.

5

10

15

20

25

30

35

40

45

50

55

60

65

Al tener diversas modalidades e implementaciones de token de verificacion 40 descritas, se describen ahora diversas modalidades e implementaciones de la entidad/servidor de validacion. La entidad/servidor de validacion 80 comprende un sistema que tiene uno o mas servidores acoplados a una red de comunicaciones que puede recibir una solicitud de un token de verificacion 40 para procesar (por ejemplo, para validar) la informacion del token de verificacion y la informacion que el token lee a partir de un dispositivo portatil 5, y para proporcionar un valor de verificacion del dispositivo (dCvV2) al token y a la red de procesamiento de pagos 70 si la informacion de identificacion pasa una o mas pruebas de validacion.

Un servidor ilustrativo de la entidad/servidor de validacion 80 se muestra en la Fig. 1. El servidor comprende uno o mas procesadores 81 acoplado a cada uno de un medio tangible legible por computadora 82, una interfaz de usuario 83, una o mas bases de datos 86, y una instalacion de red 84, el ultimo de los cuales se acopla a las primera y segunda redes de comunicaciones 31 y 32. La interfaz de usuario 83 comprende uno o mas dispositivos de salida de video (por ejemplo, pantallas, visualizadores) y uno o mas dispositivos de entrada (porejemplo, teclado, raton, raton de bola, etc.), que permiten a un administrador de la entidad/servidor de validacion 80 recibir informacion del servidor y para proporcionar entrada al servidor. El medio legible por computadora 82 puede comprender una combinacion de memoria de semiconductores y de almacenamiento no volatil, tal como una o mas unidades de disco y/o la memoria no volatil.

El medio legible por computadora 82 almacena un sistema operativo para el servidor, que permite que los procesos y aplicaciones se ejecuten por el(los) procesador(es) 81, y permite que se ejecuten los codigos para dirigir el funcionamiento del(los) procesador(es) 81.El sistema operativo proporciona servicios a estos procesos y aplicaciones, y permite que estos procesos y aplicaciones accedan a los componentes de interfaz de usuario 83, las porciones del medio legible por computadora 82, las prestaciones de red 84, y otros componentes de la entidad/servidor de validacion 80.

El sistema operativo puede ser completo. Espedficamente, el sistema operativo proporciona uno o mas modulos de comunicaciones de E/S que permiten que el(los) procesador(es) 81 se comuniquen con la interfaz de usuario 83 y las bases de datos 86.Cada modulo de comunicaciones de E/S tiene una interfaz de programacion de aplicaciones (API) con un conjunto de funciones que un procesador 81 puede llamar con el fin de acceder a los componentes. El sistema operativo de la entidad/servidor de validacion 80 tambien puede comprender uno o mas modulos de servicios de red que pueden acceder a la instalacion de red 84 y establecer las sesiones de comunicacion a las entidades en las redes de comunicacion 31 y 32, y con el servidor de transmision de SMS 35.

Tales modulos de servicios de red incluyen la Fundacion de Microsoft's Windows Communications Foundation (por ejemplo, .NET 3.0, .NET 4.0, etc.), Apple's CFNetwork Framework, la seccion de conexion en red de los nucleos del sistema operativo Unix y Linux, y la capa de servicios del sistema operativo y la capa de servicios base del sistema operativo Symbian™, y lo similar. Cada uno de estos modulos de servicios de red pueden ser no exclusivos (por ejemplo, capaz de servir a mas de un procesador y mas de un proceso/aplicacion) y cada uno proporciona una interfaz de programacion de aplicaciones (API), que tiene una coleccion de funciones que un procesador 81 puede llamar con el fin de gestionar las comunicaciones con otra entidad. Con estas prestaciones de la API, una coleccion de llamadas de funcion de la API puede construirse facilmente para que ejecute un procesador, que permite al procesador establecer un canal de comunicacion con una entidad en una red de comunicacion acoplada a la instalacion de red 84, y para el intercambio de mensajes y datos con la entidad. El sistema operativo anterior, los modulos y las API, todas incluyen instrucciones que dirigen el funcionamiento del(los) procesador(es) 81.

Una o mas bases de datos 86 pueden configurarse como servidores de base de datos, que el(los) procesador(es) 81 puede(n) acceder a traves de las prestaciones de red 84 a traves de una red de comunicaciones privada 87, que se ilustra por la lmea discontinua en la Fig. 1. La entidad/servidor de validacion 80 tiene convencionalmente un reloj 88 para el seguimiento de tiempo y fechas para diversas aplicaciones. El reloj 88 puede ser un simple contador de segundos o fracciones de los mismos, que puede leerse por el procesador 81 por una operacion de E/S, o puede comprender una disposicion mas compleja de hardware o firmware que puede proporcionar los diversos componentes de la fecha y tiempo actual (ano, mes, dfa, hora, minuto y segundo) en diferentes registros que pueden leerse por el procesador 81 a traves de la ejecucion de una o mas operaciones de E/S.

La entidad/servidor de validacion 80 puede procesar informacion de identificacion transmitida desde una pluralidad de diferentes tokens de verificacion 40 (por ejemplo, millones de tokens), y puede procesar cualquier numero de transmisiones por un token 40 particular. La entidad/servidor de validacion 80 aplica una o mas pruebas de validacion al token de verificacion 40.Para estas tareas, la entidad/servidor de validacion 80 puede comprender codigo incorporado en un medio legible por computadora 82 que dirige al procesador de datos 81 para comunicarse con la computadora 10 y el token de verificacion 40 mediante el uso de una instalacion de red 84 sobre la red de comunicaciones 31.Este codigo puede incluir instrucciones que establecen una sesion de comunicaciones con la computadora 10, que incluye la opcion de establecer una sesion SSL con autenticacion mutua y encriptado con base en un algoritmo triple DES, e instrucciones para enviar y recibir mensajes al token de verificacion 40 a traves de la sesion de comunicaciones.

La entidad/servidor de validacion 80 puede comprender ademas el codigo incorporado en un medio legible por computadora 82 que dirige al procesador de datos 81 para recibir informacion de identificacion encriptada enviada por el token de verificacion 40, y el codigo que dirige al procesador de datos 81 para desencriptar la informacion de

5

10

15

20

25

30

35

40

45

50

55

60

65

identificacion encriptada. La informacion de identificacion puede encriptarse por una clave de sesion de una sesion SSL o mediante una clave de encriptacion almacenada en el token de verificacion 40 y que se conoce para la entidad/servidor de validacion 80, o puede encriptarse doblemente por ambas teclas. La ultima clave puede asignarse unicamente al token. La entidad/servidor de validacion 80 puede comprender ademas el codigo incorporado en un medio legible por computadora 82 que dirige al procesador de datos 81 para aplicar una o mas pruebas de validacion como se describe anteriormente arriba. El procesador de datos 81 puede acceder a las bases de datos 86 en la realizacion de una o mas pruebas de validacion. Las pruebas de validacion y los codigos, por lo tanto se describen a continuacion en mayor detalle. Estos codigos y los codigos descritos a continuacion para la entidad/servidor de validacion 80 pueden implementarse en cualquier numero de lenguajes de programacion. Ademas, un experto en la tecnica sera facilmente capaz de construir instrucciones para implementar estos codigos en vista de esta descripcion sin excesiva experimentacion.

Como se describe anteriormente, una primera prueba de validacion que puede aplicar la entidad/servidor de validacion

80 se refiere a la verificacion de que el token de verificacion 40 es autentico. Para esto, el token de verificacion 40 puede enviar su numero de serie a la entidad/servidor de validacion 80, junto con un mensaje de prueba encriptado por una clave de encriptacion, con el mensaje de prueba y la clave de encriptacion que se conocen para el token 40 y la entidad/servidor de validacion 80 (pero no el publico en general), y con la clave de encriptacion que se asigna ademas unicamente al numero de serie del token.

La entidad/servidor de validacion 80 puede acceder a una base de datos de numeros de serie de tokens y las claves de encriptacion correspondientes asociadas unicamente en una de las bases de datos 86, y puede determinar si el token de verificacion 40 envfa un mensaje de prueba correcto para el numero de serie que el token proporcionado. El mensaje de prueba puede ser fijo o variable; en el ultimo caso puede generarse sobre la base de informacion conocida por ambos el token 40 y la entidad/servidor de validacion 80.El mensaje de prueba puede encriptarse y desencriptarse por un algoritmo triple DES, que puede implementarse por un numero de conjuntos de instrucciones de computadora bien conocidos.

Si el mensaje de prueba enviado es correcto, puede considerarse que se pasa la primera prueba de validacion. Para ello, la entidad/servidor de validacion 80 puede comprender codigo integrado en el medio legible por computadora 82 que dirige al procesador de datos 81 para recibir uno o mas mensajes del token de verificacion 40 a traves de la instalacion de red 84 que tiene numero de serie del token y el mensaje de prueba encriptado, el codigo que dirige al procesador de datos 81 para desencriptar el mensaje de prueba encriptado, el codigo que dirige al procesador de datos

81 para obtener uno o mas mensajes aceptables que pueden aceptarse como el mensaje de prueba correcto de una de las bases de datos 86, y el codigo que dirige al procesador de datos 81 para comparar el mensaje de prueba desencriptado con uno o mas mensajes aceptables para determinar si se pasa la primera prueba de validacion (en el caso de una coincidencia entre el mensaje de prueba desencriptado y un mensaje aceptable), o se falla (en el caso de que no coincidan).Un mensaje aceptable puede obtenerse mediante el acceso directamente desde una de las bases de datos 86, o mediante la generacion a partir de informacion almacenada en una o mas de las bases de datos 86.Los codigos anteriores pueden implementarse con las instrucciones de E/S convencionales, las llamadas de funcion de la API para las bases de datos, las instrucciones de acceso a memoria, las instrucciones aritmeticas y logicas de la CPU, y las instrucciones de control de la CPU. En vista de esta descripcion, los codigos pueden implementarse por un experto en la tecnica sin experimentacion excesiva.

En una segunda prueba de validacion, la entidad/servidor de validacion 80 puede tener una base de datos en las bases de datos 86 que realiza el seguimiento de los numeros de serie de los tokens de verificacion que se usan en actividades fraudulentas, y la entidad/servidor de validacion 80 puede comprobar el numero de serie del token de verificacion 40 contra esta base de datos. Si una comprobacion de esta base de datos indica que el token de verificacion 40 no se involucro en actividades fraudulentas, puede considerarse que se pasa la segunda prueba de validacion.

Para implementar la segunda prueba de validacion, la entidad/servidor de validacion 80 puede comprender codigo incorporado en el medio legible por computadora 82 que dirige al procesador de datos 81 para recibir un mensaje del token de verificacion 40 a traves de la instalacion de red 84 que tiene el numero de serie del token, el codigo que dirige al procesador de datos 81 para tener el numero de serie recibido comparado con los numeros de serie almacenados en una base de datos de las bases de datos 86 que almacena numeros de serie de tokens usados en transacciones fraudulentas para determinar si se pasa la segunda prueba de validacion (sin actividad fraudulenta), o se falla (actividad fraudulenta).Los codigos anteriores pueden implementarse con las instrucciones de E/S convencionales, las llamadas de funcion de la API para las bases de datos, las instrucciones de acceso a memoria, las instrucciones logicas de la CPU, y las instrucciones de control de la CPU. En vista de esta descripcion, los codigos pueden implementarse por un experto en la tecnica sin experimentacion excesiva.

Como una tercera prueba de validacion, la entidad/servidor de validacion 80 puede enviar un mensaje al token de verificacion 40 que solicita a ese token 40 enviar una o mas piezas de informacion espedfica de computadora acerca de la computadora 10, tales como los numeros de serie de uno o mas de los siguientes: el procesador de la computadora, una o mas de las unidades de disco de la computadora, el sistema operativo de la computadora. La entidad/servidor de validacion 80 puede recibir esta informacion y comprobarla contra una base de datos que almacena la informacion espedfica de computadora de las computadoras que se sabe se han involucrado en actividades fraudulentas. Si una

5

10

15

20

25

30

35

40

45

50

55

60

65

comprobacion de esta base de datos indica que la computadora 10 usada por el token de verificacion 40 no se ha involucrado en actividades fraudulentas, puede considerarse que pasa la tercera prueba de validacion.

Para llevar a cabo la tercera prueba de validacion, la entidad/servidor de validacion 80 puede comprender codigo incorporado en un medio legible por computadora 82 que dirige al procesador de datos 81 para enviar un mensaje al token de verificacion 40 que solicita informacion espedfica de la computadora (si el token de verificacion 40 no ha enviado dicha informacion de antemano sin solicitarla), codigo que dirige al procesador de datos 81 para recibir uno o mas mensajes de datos del token de verificacion 40 a traves de la instalacion de red 84 que tiene el numero de serie del token y la informacion espedfica de la computadora, y el codigo que dirige al procesador de datos 81 para tener la informacion espedfica de la computadora recibida en comparacion con la informacion espedfica de la computadora almacenada en una base de datos (de las bases de datos 86) que almacena informacion espedfica de la computadora de computadoras usadas en transacciones fraudulentas para determinar si se pasa la tercera prueba de validacion (sin actividad fraudulenta), o se falla (actividad fraudulenta).Los codigos anteriores pueden implementarse con las instrucciones de E/S convencionales, las llamadas de funcion de la API para bases de datos, instrucciones de acceso a memoria, instrucciones logicas de la CPU, y las instrucciones de control de la CPU. En vista de esta descripcion, los codigos pueden implementarse por un experto en la tecnica sin experimentacion excesiva.

La entidad/servidor de validacion 80 puede comprender un sitio web accesible para el usuario 1 que permite al usuario:(1) crear una cuenta protegida por contrasena asociada con el numero de serie del token, el ultimo de los cuales puede proporcionarse en un pedazo de papel enviado originalmente con el token; (2) asociar una direccion de correo electronico a usar por una o mas de las alertas descritas anteriormente; (3) asociar un numero de telefono movil y/o URID (porejemplo, direccion de red) del dispositivo de comunicaciones del usuario 5 para usarse por una o mas de las alertas descritas anteriormente; y (4) seleccionar una o mas de las condiciones de alerta descritas anteriormente. El sitio web tambien puede permitir que el usuario proporcione y asocie los numeros de cuenta de uno o mas de los dispositivos del usuario 5 con la cuenta protegida por contrasena, y puede ademas permitir al usuario asociar los mensajes de correo electronico y numeros de telefonos para las alertas a dispositivos 5 en particular, de acuerdo con sus numeros de cuenta. Una de las bases de datos 86 puede asignarse para mantener las cuentas protegidas por contrasena de los usuarios. Cuando la entidad/servidor de validacion 80 recibe una solicitud de validacion del token de verificacion 40, puede consultarse esta base de datos para encontrar la cuenta protegida por contrasena del usuario (por ejemplo, identificar al usuario a partir del numero de serie del token y/o el numero de cuenta enviado en la informacion de identificacion), y determinar que alertas de mensaje de texto deben generarse y enviarse en base a los parametros almacenados en la cuenta protegida por contrasena. Los codigos y las acciones anteriores pueden implementarse con los codigos HTML de la pagina (por ejemplo, paginas web), instrucciones de E/S convencionales, instrucciones de acceso a memoria, llamadas de funcion de la API de base de datos, instrucciones aritmeticas de la CPU, instrucciones logicas de la CPU, y las instrucciones de control de la CPU. En vista de esta descripcion, los codigos pueden implementarse por un experto en la tecnica sin experimentacion excesiva.

Puede apreciarse que algunas implementaciones de token de verificacion 40 pueden configurarse para trabajar con dispositivos de pago de consumo seleccionados 5, tales como los emitidos por un banco seleccionado, o configurarse para trabajar con un sitio Web del comerciante seleccionado 20.

Todavfa en otras implementaciones, el token de verificacion 40 puede contener el URID de la entidad/servidor de validacion 80, que gestiona las solicitudes de validacion para varios dispositivos portatiles de consumo 5 de marca compartida, diferentes. Ademas, cada uno de estos dispositivos 5 de marca compartida puede contener un URID para un comerciante de marca compartida. El URID de comerciante se lee por el token de verificacion 40 y se proporciona a una entidad/servidor de validacion junto con la informacion de identificacion del dispositivo. La entidad/servidor de validacion 80 puede enviar la informacion de identificacion validada a la URID del comerciante.

Las modalidades de la invencion no se limitan a sistemas de autenticacion que implican transacciones. El mismo enfoque podna aplicarse a otros sistemas de autenticacion. Por ejemplo, las modalidades podnan usarse para autenticar a un usuario mediante el uso de una aplicacion de banca en lmea. Un titular de la tarjeta puede introducir su ID de usuario en un sitio web bancario. El titular de la tarjeta puede entonces presentar su dispositivo de consumo portatil a un token de verificacion. El sitio web bancario puede validar el ID de usuario y las credenciales del token mediante la comunicacion con una entidad de validacion.

Las modalidades de la invencion no se limitan a las modalidades descritas anteriormente. Por ejemplo, aunque se muestran los bloques funcionales separados para un emisor, sistema de procesamiento de pago, y adquirente, algunas entidades realizan todas estas funciones y pueden incluirse en modalidades de la invencion.

La Fig. 11 es un diagrama de bloques del sistema de computadora tfpico 1100 configurado para ejecutar codigo legible por computadora para implementar varias funciones y acciones de acuerdo con diversas modalidades de la presente invencion.

El sistema 1100 es representativo de un sistema informatico capaz de realizar la presente invencion. El sistema informatico puede estar presente o usarse para poner en practica cualquiera de los metodos o las modalidades de computadora o computadora servidor en las Figs.1 a 10.Sera facilmente evidente para un experto en la tecnica que

5

10

15

20

25

30

35

40

45

50

55

60

65

muchas otras configuraciones de hardware y software son adecuadas para usar con la presente invencion. Por ejemplo, la computadora puede ser una configuracion de escritorio, portatil, montada en bastidor o de tableta. Ademas, la computadora puede ser una serie de computadoras conectadas en red. Ademas, se contempla el uso de otros microprocesadores, tales como los microprocesadores Xeon™, Pentium™ o Core™; los microprocesadores Turion™ 64, Opteron™ o Athlon™ de Advanced Micro Devices, Inc; y similares. Ademas, se contemplan otros tipos de sistemas operativos, como Windows, WindowsXP®, WindowsNT®, o similar de Microsoft Corporation, Solaris de Sun Microsystems, Linux, Unix, y similares. Todavfa en otras modalidades, las tecnicas descritas anteriormente pueden implementarse en un chip o una placa de procesamiento auxiliar. Varias modalidades pueden basarse en sistemas proporcionados por daVinci, Pandora, Silicon Color, u otros proveedores.

En una modalidad, el sistema informatico 1100 incluye tfpicamente una pantalla 1110, la computadora 1120, un teclado 1130, un dispositivo de entrada de usuario 1140, la comunicacion o interfaz de red 1150, y similares. En diversas modalidades, la pantalla (monitor) 1110 puede llevarse a la practica como una pantalla CRT, una pantalla LCD, una pantalla de plasma, una proyeccion directa o retroproyeccion DLP, una micropantalla, o similares. En diversas modalidades, la pantalla 1110 puede usarse para mostrar interfaces de usuario y las imagenes renderizadas.

En diversas modalidades, el dispositivo de entrada de usuario 1140 se lleva a la practica tfpicamente como un raton de computadora, un raton de bola, un panel tactil, una palanca de mando, un mando a distancia inalambrico, tableta de dibujo, el sistema de comando de voz, y similares. El dispositivo de entrada de usuario 1140 tfpicamente permite a un usuario seleccionar objetos, iconos, texto y similares que aparecen en la pantalla 1111 a traves de un comando como un clic de un boton o similar. Un dispositivo de entrada de usuario especializado adicional 1145, tal como una banda magnetica, transceptor RFID o lector de tarjetas inteligentes tambien puede proporcionarse en diversas modalidades. En otras modalidades, el dispositivo de entrada de usuario 1145 incluye pantallas del sistema informatico adicionales (por ejemplo, monitores multiples).Ademas el dispositivo de entrada de usuario 1145 puede implementarse como una o mas interfaces de usuario graficas en una pantalla tal.

Las modalidades de las interfaces de computadora 1150 incluyen tfpicamente una tarjeta Ethernet, un modem (telefono, satelite, cable, ISDN), una unidad de lmea de abonado digital (DSL) (asmcrona), la interfaz FireWire, la interfaz USB, y similares. Por ejemplo, las interfaces de computadora 1150 pueden acoplarse a una red informatica, a un bus FireWire, o similares. En otras modalidades, las interfaces de computadora 1150 pueden integrarse ffsicamente en la placa base de la computadora 1120, pueden ser un programa de software, tal como el software de DSL, o similares.

La RAM 1170 y el disco duro 1180 son ejemplos de medios tangibles legibles por computadora configurados para almacenar datos tales como usuario, la cuenta y el nivel de transaccion de datos, datos agregados calculados, super claves, subclaves y otro codigo de computadora ejecutable, codigo legible por humanos, o similares. Otros tipos de medios tangibles incluyen medios de almacenamiento magneticos, tal como disquetes, discos duros en red o discos duros extrafbles; medios de almacenamiento opticos tal como CD-ROM, DVD, memorias holograficas, o codigos de barras; medios semiconductores tales como memorias flash, memorias de solo lectura (ROM); memorias volatiles respaldada por batena; dispositivos de almacenamiento en red, y similares.

En la presente modalidad, el sistema de computadora 1100 tambien puede incluir software que permite comunicaciones a traves de una red tal como los protocolos HTTP, TCP/IP, RTP/RTSP, y similares. En modalidades alternativas de la presente invencion, tambien pueden usarse otros softwares de comunicaciones y protocolos de transferencia, por ejemplo IPX, UDP o similares.

En diversas modalidades, la computadora 1120 incluye tfpicamente componentes de computadora familiares, tales como un procesador 1160, y dispositivos de almacenamiento de memoria, tales como una memoria de acceso aleatorio (RAM) 1170, unidades de disco 1180, y el bus del sistema 1190 que interconectan los componentes anteriores.

En algunas modalidades, la computadora 1100 incluye uno o mas microprocesadores Xeon de Intel. Ademas, en la presente modalidad, la computadora 1120 incluye tfpicamente un sistema operativo basado en UNIX.

Debe entenderse que las modalidades de la presente invencion como se describe anteriormente pueden implementarse en forma de logica de control mediante el uso de software de computadora de una manera modular o integrada. Sobre la base de la descripcion y ensenanzas proporcionadas en la presente descripcion, un experto en la tecnica conocera y apreciara otras formas y/o metodos para implementar la presente invencion mediante el uso del hardware y una combinacion de hardware y software

Cualquiera de los componentes de software o funciones descritas en esta solicitud, pueden implementarse como codigo de software para ejecutarse por un procesador mediante el uso de cualquier lenguaje de programacion adecuado tal como, por ejemplo, Java, C ++ o Perl mediante el uso, por ejemplo, de tecnicas orientadas a objetos o convencionales. El codigo de software puede almacenarse como una serie de instrucciones o comandos en un medio legible por computadora, tal como una memoria de acceso aleatorio (RAM), una memoria de solo lectura (ROM), un medio magnetico tal como una unidad de disco duro o un disquete, o un medio optico, tal como un CD-ROM. Cualquier medio legible por computadora tal puede residir en o dentro de un unico aparato computacional, y puede estar presente o dentro de diferentes aparatos computacionales dentro de un sistema o red.

La descripcion anterior es ilustrativa y no es restrictiva. Muchas variaciones de la invencion seran evidentes para los expertos en la tecnica tras la revision de la descripcion. El alcance de la invencion debe, por lo tanto, determinarse no con referencia a la descripcion anterior, sino que debe determinarse con referencia a las reivindicaciones pendientes junto con todo su alcance, o equivalentes.

5

Una o mas caractensticas de cualquier modalidad pueden combinarse con una o mas caractensticas de cualquier otra modalidad sin apartarse del alcance de la invencion.

Una relacion de "uno", "un" o "la" se entiende que significa "uno o mas" salvo que se indique espedficamente lo 10 contrario.

Claims

5

10

15

20

25

30

35

40

45

50

Reivindicaciones

1. Un metodo para generar un token de verificacion por un fabricante de token de verificacion, el metodo que comprende:

generar un numero de serie para un token de verificacion;

generar un par de claves espedficas de token de verificacion que incluye un componente publico y un componente privado con base en una clave maestra del fabricante de token de verificacion; asociar el numero de serie con el par de claves espedficas de token de verificacion; y

almacenar el componente privado del par de claves espedficas de token de verificacion a una memoria en el token de verificacion,

validar el token de verificacion por un servidor de validacion, en donde el componente privado del par de claves espedficas de token de verificacion se usa por el token de verificacion para generar una respuesta a un mensaje de cuestionamiento firmado desde el servidor de validacion por desencriptar el mensaje de cuestionamiento firmado mediante el uso del componente privado, y la clave maestra del fabricante de token de verificacion se usa por el servidor de validacion para desencriptar aun mas la respuesta recibida del token de verificacion para determinar que el token de verificacion es de un fabricante de token de verificacion de confianza.
2. El metodo de la reivindicacion 1 que comprende ademas almacenar el numero de serie en la memoria en el token de verificacion.
3. El metodo de la reivindicacion 1 en donde generar el par de claves espedficas del token de verificacion comprende firmar el componente publico del par de claves con la clave maestra espedfica del fabricante para generar un certificado publico del token de verificacion.
4. El metodo de la reivindicacion 3 que comprende ademas el almacenamiento del certificado publico del token de verificacion en la memoria del token de verificacion.
5. El metodo de la reivindicacion 1 que comprende ademas almacenar un identificador de fabricante en la memoria del token de verificacion.
6. El metodo de la reivindicacion 1 que comprende ademas almacenar, en el token de verificacion, el codigo ejecutable para establecer una conexion con un servidor de verificacion a traves de una sesion de comunicacion mediante el uso de una instalacion de comunicacion de un dispositivo de computacion al que se conecta el token de verificacion.
7. El metodo de la reivindicacion 1 que comprende ademas: enviar una solicitud de registro a una computadora servidor; y

recibir la clave maestra del fabricante de token de verificacion desde la computadora servidor.
8. El metodo de la reivindicacion 7 en donde la computadora servidor lleva a cabo una revision del riesgo con base en la informacion relacionada con el fabricante de token de verificacion.
9. El metodo de la reivindicacion 7, que comprende ademas la recepcion de un certificado de clave de fabricante de token de verificacion desde la computadora servidor.
10. Un equipo que comprende: un procesador; y

un codigo que se almacena en memoria, que cuando se ejecuta por el procesador, provoca que el procesador realice el metodo de las reivindicaciones 1-9.
11. Un programa de computadora que comprende instrucciones legibles por maquina que cuando se ejecutan por un aparato de calculo causa que este realice el metodo de cualquiera de las reivindicaciones 1-9.