ES2714377T3 - Procedimiento de seguridad en la red y de detección de fraude - Google Patents

Abstract

Un procedimiento implementado por ordenador (220) para detectar fraude durante una conexión de un dispositivo de red no registrado (22) a un proveedor de servicios de red (24), en el que un cliente de software (54) se ejecuta (222) en el dispositivo de red (22), comprendiendo el procedimiento: determinar (224), mediante el cliente de software, que el dispositivo de red no está registrado con un sistema de detección de fraude (26); asignar, mediante el sistema de detección de fraude (26), un identificador de dispositivo de red único al dispositivo de red no registrado (22) y enviar (226) el identificador de dispositivo de red al dispositivo de red (22); generar (228), mediante el cliente de software (54) que se ejecuta en el dispositivo de red (22), una huella digital de dispositivo de red para el dispositivo de red (22) en función de una o más características de dispositivo; reenviar (230), mediante el cliente de software (54), la huella digital de dispositivo de red al sistema de detección de fraude (26); comparar (230), mediante el sistema de detección de fraude (26), la huella digital de dispositivo de red con una base de datos (30) de dispositivos de red registrados; y verificar (232, 236), mediante el sistema de detección de fraude (26), que la huella digital de dispositivo de red no está duplicada con el fin de impedir un fraude.

Description

DESCRIPCION

Procedimiento de seguridad en la red y de deteccion de fraude

Campo de la invencion

La presente invencion se refiere, en general, al campo de la seguridad en la red, incluidas la deteccion y prevencion de transacciones fraudulentas y la usurpacion de identidad. Al compartir informacion acerca de asociaciones entre usuarios finales y dispositivos de red espedficos, la presente invencion tiene otros usos potenciales que incluyen, pero no se limitan a, la distribucion de contenido, la autenticacion de hardware, la proteccion contra la piratena de software y otros medios electronicos, vigilar el comportamiento del consumidor, la segmentacion del mercado y la gestion de relaciones con consumidores.

Antecedentes de la invencion

El continuo crecimiento de la infraestructura de las telecomunicaciones y la proliferacion de dispositivos de red, proveedores de servicios, tecnologfa inalambrica y productos de software relacionados han transformado Internet en una herramienta de uso diario. Las empresas utilizan cada vez mas Internet como un procedimiento de comunicacion con los consumidores, proveedores, empleados y accionistas, y de realizacion de transacciones comerciales. En teona, la realizacion de negocios en Internet es a menudo eficaz y rentable, sobre todo cuando los productos y servicios pueden distribuirse de forma electronica. En la practica, los danos causados por los piratas informaticos, la usurpacion de identidad, las tarjetas de credito robadas y otras actividades fraudulentas puede ser enormemente costoso y diffcil de manejar. Como mmimo, estas realidades aumentan significativamente los riesgos y costes asociados a la realizacion de negocios a traves de Internet espedficamente y, en general, a traves de cualquier tipo de red.

Aunque varios procedimientos se utilizan comunmente para hacer mas seguro el uso de Internet y facilitar las transacciones de comunicacion y de negocios, todos ellos tienen debilidades inherentes y explotables. Los nombres de usuario y las contrasenas son una de las formas de seguridad basica en la red mas ampliamente utilizadas y aceptadas, donde el acceso esta limitado a una coincidencia exacta de una combinacion de nombre de usuario y contrasena. La identificacion de nombres de usuario validos es a menudo trivial, sobre todo en redes en las que los nombres de usuario son visibles para los observadores y en organizaciones en las que los usuarios tienen un formato de nombre de usuario comun, tal como "pnmemInidal_apellido". Dado que los usuarios finales suelen utilizar contrasenas comunes, simples y por defecto, comparten contrasenas y anotan las contrasenas mas complicadas, y las contrasenas se pueden adivinar, solicitar u observar. Por lo tanto, la combinacion del nombre de usuario y la contrasena solo proporciona un nivel basico de seguridad del que no se debe confiar exclusivamente, sobre todo para proteger redes accesibles a traves de Internet.

Un sistema de autenticacion de usuario secundaria va un paso mas alla en la fiabilidad con un solo nombre de usuario y contrasena y puede aumentar en gran medida la seguridad. La autenticacion secundaria se basa en algo que el usuario tiene en su poder, como por ejemplo un dispositivo de hardware de proposito especial. Por ejemplo, despues de introducir un nombre de usuario y una contrasena validos para acceder a una red, un usuario puede recibir un codigo como parte del proceso de inicio de sesion. El usuario introduce el codigo en un dispositivo dentro de una cantidad de tiempo especificada, y el dispositivo proporciona un codigo/contrasena secundarios que el usuario introducira como parte del proceso de inicio de sesion. Aunque mucho mas seguros, estos sistemas no son perfectos. Mas importante aun, estos sistemas pueden ser poco practicos en la proteccion de grandes redes accesibles por el publico en general, y crean importantes barreras de entrada.

Una clave de hardware, denominada en ocasiones llave USB (dongle), que puede conectarse a un ordenador mediante un puerto USB, se utiliza en ocasiones para identificar usuarios finales que se conectan desde un dispositivo particular. Un numero de serie de componente de sistema fijo y otros procedimientos de hardware utilizados para identificar de manera unica un dispositivo de red espedfico tambien se usan para limitar el acceso a dispositivos 'conocidos'. Desafortunadamente, estos procedimientos se pueden copiar y simular en software. Estos sistemas tambien crean barreras y pueden ser poco practicos en la proteccion de grandes redes accesibles por el publico en general.

El uso de certificados digitales y de Autoridades de Certificacion de Terceras Partes de Confianza son procedimientos cada vez mas populares que garantizan que la parte que se conecta a una red es realmente quien dice ser. Desafortunadamente, los certificados se pueden copiar e incluso robar de forma remota. Ademas, debe confiarse en gran medida en grupos de verificacion de terceras partes que no tengan un interes directo en las redes que conffan en ellos. El requisito de que los usuarios de red utilicen certificados tambien puede crear una barrera importante, sobre todo para grandes redes accesibles por el publico en general, y crear importantes barreras de entrada.

Una direccion de Protocolo de Internet (IP) y servicios de localizacion geografica que dependen de la direccion IP se utilizan algunas veces para verificar los usuarios finales o, al menos, para cruzar una ubicacion de referencia, probablemente ffsica, con informacion conocida acerca de un usuario. Estos procedimientos estan limitados por el hecho de que muchos usuarios de Internet obtienen una nueva direccion IP temporal cada vez que se conectan a Internet. Ademas, el uso de direcciones IP para determinar la ubicacion real de un dispositivo conectado es inherentemente deficiente por el modo en que se distribuyen bloques de numeros IP y la relativa facilidad de suplantacion de direcciones IP, una tecnica usada por intrusos de la red para que parezca que se estan conectando desde una direccion IP de confianza u otra diferente.

Las bases de datos de tarjetas de credito no validas y las listas de identidades utilizadas en actividades fraudulentas son herramientas de verificacion razonables y se deben utilizar en la medida en que sean rentables. Sin embargo, nunca se puede confiar exclusivamente en tales listas porque es practicamente imposible que tales listas esten actualizadas y sean exhaustivas. Ademas, estas listas no ofrecen ninguna proteccion contra las denominadas 'devoluciones amistosas', pagos rechazados por los titulares de tarjetas de credito que hacen compras utilizando su propia tarjeta de credito valida y quienes, posteriormente, sostienen que no hicieron la compra.

Servicios de verificacion, tales como RiskGardian proporcionado por TrustMarque, y otros servicios de evaluacion de riesgos tambien son herramientas de verificacion razonables y se deben utilizar en la medida en que sean rentables. Estos servicios utilizan poca informacion concreta acerca de un usuario o dispositivo espedfico y solo asignan riesgos relativos asociados a una transaccion particular basandose en la informacion general y en tendencias. Por ultimo, tales servicios se basan exclusivamente en historiales de tendencias y son deficientes en la identificacion de nuevos problemas y areas de riesgo emergentes.

Las huellas digitales, el reconocimiento de voz, el escaner de retina, el reconocimiento facial, el ADN y otros procedimientos de identificacion biometrica seran cada vez mas comunes. En este momento, estos procedimientos de identificacion de usuario tienen un precio muy elevado. Ademas, uno o mas de estos procedimientos deben ser ampliamente distribuidos y generalmente aceptados por los usuarios finales para su consideracion y su uso por la mayona de las organizaciones que realizan negocios a traves de Internet. Incluso si un procedimiento de este tipo estuviera disponible y fuese rentable, una vez que los identificadores biometricos unicos se conviertan en informacion electronica, tambien pueden ser robados, copiados y verse comprometidos de otro modo.

Aunque todos estos procedimientos, y otros, tienen puntos debiles que pueden ser explotados, cada uno ocupa un lugar en la seguridad de las redes. Los tipos de acceso, el nivel de seguridad, la naturaleza de las poblaciones de usuarios y otros factores determinaran que grupo de procedimientos servira mejor a cada aplicacion. La presente invencion no pretende sustituir ninguno de estos medios de proteccion de redes y de descarte de usuarios no autorizados. Las organizaciones deben utilizar todo tipo de medios rentables a su disposicion para regular el acceso a la red. La presente invencion mejora la seguridad al proporcionar capacidades no ofrecidas por ninguno de los sistemas y procedimientos ffpicos anteriores. Por lo tanto, es deseable proporcionar un sistema y un procedimiento de seguridad en la red y de deteccion de fraudes, siendo este el fin al que esta dirigida la presente invencion.

El documento US 2002/073046A1 da a conocer un sistema para permitir una transaccion electronica segura en una red, donde la red presenta un dispositivo de usuario que dispone de huella digital, un servidor y medios para proporcionar la identidad del usuario. El documento US 2003/005287A1 da a conocer un sistema y un procedimiento que proporcionan seguridad electronica por medio de una red a traves de un identificador de cliente positivo extensible, que funciona con un sistema de perfiles de informacion positiva, localizadores de recursos seudouniformes para ayudar a proporcionar integridad de datos, un sistema de publicacion de paginas virtuales y un respondedor de seguridad activo. El documento US2002/035622A1 da a conocer un proceso de recopilacion y archivo de datos de maquina en lmea que genera un perfil de datos de maquina del ordenador de un consumidor que accede a un formulario de transaccion de un sitio web comercial y que vincula el perfil de datos de maquina y un registro de transaccion con informacion de identificacion de consumidor usando una cadena de identificacion de transaccion unica.

Resumen de la invencion

Estos y otros objetos se consiguen mediante un procedimiento segun la reivindicacion 1 que permite identificar de manera unica dispositivos de red que se conectan a una red, y correlacionar inicios de sesion con cada dispositivo de red utilizado.

Esta informacion puede utilizarse para observar un comportamiento de inicio de sesion, tales como cuentas que se conectan desde 'demasiados' dispositivos, o 'demasiadas' cuentas que se conectan desde el mismo dispositivo. Ademas, esta informacion puede utilizarse para una referencia cruzada entre dispositivos ffsicos utilizados por cuentas fraudulentas conocidas, y para una referencia cruzada con otras cuentas utilizadas por dispositivos espedficos. Puede evitarse que dispositivos ffsicos implicados en una actividad sospechosa o fraudulenta, o que dispositivos asociados a cuentas implicadas en actividades sospechosas, se conecten a una red. Por ultimo, esta informacion puede ser compartida con otras redes que utilizan el sistema. De esta manera, a los dispositivos ffsicos asociados con la actividad sospechosa o fraudulenta en una red se les puede denegar el acceso a otras redes, de acuerdo con las reglas de negocio y los parametros de tolerancia al riesgo de cada red individual.

El procedimiento de la invencion permite proporcionar una herramienta avanzada de prevencion y deteccion de fraude que puede reducir significativamente el riesgo de fraude de identidad y de transaccion en Internet al permitir que una empresa evite 'consumidores problematicos' identificados por otras empresas participantes antes de que empiecen a crear problemas en ese negocio, y facilita el proceso de identificacion de posibles reincidentes antes de que creen mas problemas. Para lograr este objetivo, la herramienta prevencion y deteccion de fraude identifica de manera unica los clientes finales, asf como su mutua asociacion. Realiza un seguimiento de la conducta de consumidores finales en el tiempo, identifica un comportamiento 'sospechoso' basandose en parametros establecidos por los proveedores de servicios de red, y mantiene el estado de las asociaciones entre dispositivos y usuarios finales. Esta informacion es compartida por todas las empresas participantes, de manera que una empresa puede tomar las decisiones mas educadas acerca de nuevos y actuales consumidores en funcion de los dispositivos de red que utilizan y el historial de esos dispositivos con otras empresas. En una forma de realizacion, el procedimiento de la invencion funciona con un sistema de prevencion y de deteccion de fraude que comprende tres componentes principales en tiempo real que incluyen un servidor, un cliente y un conjunto de interfaces de programacion de aplicaciones (API). El servidor contiene una base de datos centralizada del historial de fraude que se mantiene. El cliente es un pequeno programa ejecutable (que tiene una pluralidad de lmeas de codigo) que 'registra' un dispositivo de red con el servidor. El cliente puede estar incluido dentro de un programa distribuido por un proveedor de servicios de red que debe utilizarse para conectarse a la red. El cliente tambien puede suministrarse a traves de una aplicacion independiente, integrada en un producto de software comun, tal como un navegador web, o incluso integrada en el hardware o la memoria, siendo necesario que cualquiera de tales formas este en ejecucion cuando se autentica una conexion a una red mediante un proveedor de servicios de red protegido por este sistema. El cliente tambien podna suministrarse bajo demanda, a traves de JavaScript, un control ActiveX u otra tecnologfa similar cuando un usuario se conecta a un proveedor de servicios de red a traves de su navegador web favorito. Por ejemplo, un sitio de apuestas podna hacer que un nuevo usuario se descargue una aplicacion de software que genere una logica y una interfaz de usuario de mesa de poquer, y el cliente del sistema de prevencion y deteccion de fraude es parte de esa aplicacion de software descargada. La API ('ieSnAPi' en una forma de realizacion preferida) es un conjunto de herramientas que un sistema de procesamiento de un proveedor de servicios de red (que utiliza el sistema de prevencion y de deteccion de fraude) utiliza para comunicarse con el sistema. Ademas de los tres componentes en tiempo real, el sistema comprende ademas dos componentes administrativos, incluidas paginas de administracion de sitios web y un modulo de informes. Las paginas de administracion de sitios web pueden permitir a un usuario del sistema ajustar sus niveles de tolerancia al fraude, inspeccionar y cambiar el estado de fraude de consumidores individuales y comprobar las relaciones de los consumidores entre sf. Los informes mantendran un negocio al tanto de los consumidores existentes que realicen una nueva actividad fraudulenta, asf como del uso del sistema.

De este modo, de acuerdo con los ejemplos dados a conocer en el presente documento, un sistema de prevencion y deteccion de fraude y de seguridad en la red puede requerir que uno o mas proveedores de servicios de red que proporcionan un servicio y que un dispositivo de red que se conecta a al menos uno de los proveedores de servicios de red a traves de una red de comunicaciones utilicen el servicio prestado. Al menos uno de los proveedores de servicios de red tiene un detector de fraude que comprende un cliente que se descarga en el dispositivo de red cuando el dispositivo de red se conecta con el proveedor de servicios de red en el que el cliente recopila informacion acerca del dispositivo de red para generar una huella digital que identifica al dispositivo de red. El detector de fraude tambien tiene una base de datos y un modulo que recibe la huella digital, almacena la huella digital en la base de datos y asocia la huella digital con informacion de usuario. De acuerdo con la invencion, la huella digital y la informacion de usuario se comparten entre el uno o mas proveedores de servicios de red para detectar fraude usando el dispositivo de red a traves de los proveedores de servicios de red. De acuerdo con otro aspecto de la invencion se valida un identificador de dispositivo de red asignado al dispositivo de red y se valida la combinacion del identificador de dispositivo de red y una huella digital de dispositivo de red para el dispositivo de red. Ademas, el estado del identificador de dispositivo de red y la huella digital de dispositivo de red para el dispositivo de red se verifican como aceptables para el proveedor de servicios de red en funcion de las reglas de estado del proveedor de servicios de red. A continuacion, el estado del identificador de dispositivo de red y la huella digital de dispositivo de red para el dispositivo de red se verifican como aceptables para los proveedores de servicios de red asociados. De acuerdo con otro aspecto de la invencion, se proporciona un procedimiento para detectar fraudes durante una conexion de un dispositivo de red desconocido con un proveedor de servicios de red. Utilizando el procedimiento, se activa una aplicacion en un dispositivo de red, que a su vez activa un cliente de deteccion de fraude en el dispositivo de red. El cliente determina entonces que el dispositivo de red es un dispositivo de red no registrado y recibe un identificador de dispositivo de red solicitado desde un sistema de deteccion de fraude. El cliente genera entonces una huella digital basandose en caractensticas del dispositivo de red, la cual se reenvfa al sistema de deteccion de fraude. El sistema de deteccion de fraude verifica entonces que la huella digital del dispositivo de red no este duplicada y, a continuacion, proporciona un cuadro de dialogo de inicio de sesion al dispositivo de red si la huella digital no esta duplicada.

Breve descripcion de las figuras

La Figura 1 es un diagrama que ilustra una red de transacciones electronicas implementada por ordenador que tiene uno o mas dispositivos de red que estan conectados a uno o mas proveedores de servicios de red que comparten informacion de fraude con un servidor de deteccion de fraude que es parte del sistema de deteccion de fraude segun la invencion.

La Figura 2 es un diagrama que ilustra un ejemplo de un dispositivo de red segun la invencion.

La Figura 3 es un diagrama que ilustra un ejemplo de un proveedor de servicios de red segun la invencion.

La Figura 4 es un diagrama que ilustra un ejemplo del servidor de deteccion de fraude segun la invencion.

La Figura 5 ilustra ejemplos de una parte de una base de datos para cada proveedor de servicios de red.

La Figura 6 es un diagrama que ilustra un ejemplo de una base de datos de registro de dispositivo de red segun la invencion.

La Figura 7 es un procedimiento para etiquetar un dispositivo de red segun la invencion.

La Figura 8A es un diagrama que ilustra las tablas de una base de datos relacional de un ejemplo de una forma de realizacion preferida de un esquema de base de datos para un sistema de deteccion de fraude segun la invencion. Las Figuras 8B a 8E son diagramas que ilustran detalles adicionales de las tablas de base de datos mostradas en la Figura 8A.

Las Figuras 9A y 9B son un diagrama de flujo que ilustra un procedimiento preferido para la validacion de una cuenta usando el sistema de prevencion y deteccion de fraude segun la invencion.

Las Figuras 9C y 9D son un diagrama de flujo que ilustra un procedimiento preferido para la validacion de un nuevo usuario/dispositivo usando el sistema de prevencion y deteccion de fraude segun la invencion.

Las Figuras 9E y 9F son un diagrama de flujo que ilustra un procedimiento preferido para la validacion de un usuario/dispositivo existente.

Descripcion detallada de una forma de realizacion preferida

La invencion es particularmente aplicable a un sistema y procedimiento de deteccion de fraude de transacciones electronicas y es en este contexto en que se describira la invencion. Se apreciara, sin embargo, que el sistema y procedimiento segun la invencion tiene una mayor utilidad, tal como en cualquier tipo de transaccion en la que pueda ser deseable detectar fraude llevado a cabo por uno o mas dispositivos de red y cuentas de usuario a traves de una red de comunicaciones, o incluso detectar e impedir posibles fraudes o usurpaciones de identidad por personas que tratan de finalizar una transaccion de forma remota por telefono o correo, o incluso en persona. Un aspecto importante de este sistema y procedimiento consiste en asociar dos elementos de informacion acerca de una transaccion, supervisar estas asociaciones para todos los consumidores y compartir informacion de estado acerca de estas asociaciones con otras empresas. A continuacion se ilustra el uso de este sistema para correlacionar un dispositivo ffsico y un usuario. De acuerdo con la invencion, el asociar cualquier combinacion de identificador de consumidor, numero de telefono, numero de permiso de conducir, numero de la seguridad social, direccion postal, direccion de entrega, numero de tarjeta de credito, direccion de correo electronico, dispositivo de red, ubicacion de compra al por menor y cualquier otra informacion capturada como parte de una compra podna utilizarse para identificar y minimizar el fraude en una transaccion y la usurpacion de identidad. Uno de los aspectos mas importantes de la invencion es la creacion de asociaciones, el seguimiento del comportamiento en el tiempo y el intercambio de informacion con multiples redes o empresas que se benefician de compartir este tipo de informacion. De esta manera, una actividad fraudulenta puede ser identificada y detenida dentro de una red/empresa e impedirse en otras que compartan informacion a traves de este sistema de prevencion de fraude. Con fines ilustrativos se describira un ejemplo espedfico del sistema de deteccion de fraude en el contexto de un sitio web de apuestas en lmea. Segun la invencion, el sistema segun la invencion puede utilizar 1) tanto un identificador de dispositivo de red (NDI) como una huella digital de dispositivo de red (NDF) para identificar un dispositivo de red; 2) solo un NDI para identificar un dispositivo de red; 3) solamente una NDF para identificar un dispositivo de red; o 4) cualquier otro dato que pueda utilizarse para identificar de manera unica un dispositivo de red. La informacion utilizada para identificar un dispositivo de red puede conocerse como identificador de dispositivo. En algunas situaciones, puede que sea imposible extraer datos de un dispositivo de red, de forma que solo el NDI se utiliza para identificar el dispositivo de red. En otras situaciones, los demas datos que se utilizan para identificar el dispositivo de red pueden ser un numero de telefono de una persona que llama a un sistema de pedidos telefonico o un identificador de un telefono celular. En el ejemplo descrito a continuacion, un NDI y una NDF se utilizan conjuntamente para identificar un dispositivo de red.

La Figura 1 es un diagrama que ilustra una red de transacciones electronicas 20 implementada por ordenador que tiene uno o mas dispositivos de red (ND1,..., NDn) 22 que estan conectados a uno o mas proveedores de servicios de red (NSP1,..., NSPn) 24, tambien denominados ordenadores centrales, que comparten informacion de fraude con un servidor de deteccion de fraude 26 que es parte del sistema de deteccion de fraude segun la invencion. Como se muestra en la Figura 1, el servidor de deteccion de fraude 26 puede estar interconectado con los proveedores de servicios de red a traves de una red privada o puede estar interconectado con los proveedores de servicios de red a traves de una red de comunicaciones 28, tal como Internet, o World Wide Web, o cualquier otra red que sea capaz de comunicar datos digitales, tal como una red inalambrica o celular. Si el servidor de deteccion de fraude 26 esta conectado a la red de comunicaciones 28, entonces los datos entre los proveedores de servicios de red 24 y el servidor de deteccion de fraude 26 pueden cifrarse o transmitirse a traves de una red privada virtual para garantizar la privacidad y la seguridad. Como se muestra en la Figura 1, cada dispositivo de red puede conectarse a cualquier proveedor de servicios de red 24 a traves de la red de comunicaciones 28 utilizando protocolos de datos ampliamente conocidos, tales como HTTP, HTTPS y similares. En el sistema mostrado en la Figura 1, cada proveedor de servicios de red puede proporcionar un servicio a cada dispositivo de red conectado al mismo y puede llevar a cabo una transaccion electronica con cada dispositivo de red, tal como una apuesta en juegos de azar o la compra de un producto. Segun la invencion, cada transaccion electronica es susceptible de fraude y cada dispositivo de red y su usuario deben ser identificados de manera unica para reducir el riesgo de fraude. Por lo tanto, el servidor de deteccion de fraude 26 puede recibir informacion unica de identificacion de usuario desde cada proveedor de servicios de red, asf como generar un identificador unico de dispositivo de red que identifica de manera unica cada dispositivo de red. Usando la informacion unica de identificacion de usuario y la huella digital unica de dispositivo de red segun la invencion, el servidor de deteccion de fraude 26 es capaz de detectar actividades fraudulentas a traves de la red de transacciones electronicas 20. En particular, el servidor de fraude 26 puede proporcionar un servicio centralizado que utiliza esta invencion para identificar de manera unica dispositivos ffsicos, registrar dispositivos unicos, realizar un seguimiento de inicios de sesion de usuario final, asociar una cuenta de usuario final con uno o mas dispositivos espedficos, asociar un dispositivo con una o mas cuentas de usuario final, y compartir esta informacion con cada proveedor de servicios de red. El servidor de deteccion de fraude 26 puede incluir una base de datos de registro de dispositivos de red (NDRD) 30 centralizada. Mas detalles del servidor de deteccion de fraude y del sistema de deteccion de fraude segun la invencion se describiran posteriormente con referencia a las Figuras 4 a 7.

El dispositivo de red 22, por ejemplo, puede ser un ordenador personal, un ordenador de tipo servidor, un ordenador portatil, un asistente personal digital (PDA), tal como un dispositivo basado en Palm o un dispositivo CE de Windows, un telefono celular, un dispositivo inalambrico, tal como un dispositivo inalambrico de correo electronico u otro dispositivo capaz de comunicarse de forma inalambrica con una red de ordenadores o cualquier otro recurso informatico que tenga un procesador, memoria y capacidades de entrada/salida para poder comunicarse con una red de ordenadores y manejar transacciones electronicas. El dispositivo de red puede ser tambien un telefono de un usuario utilizado, por ejemplo, para encargar artfculos de un catalogo de venta por correo. En funcionamiento, un dispositivo de red, tal como ND1, puede solicitar acceso a la red de transacciones electronicas 20 y a un proveedor de servicios de red particular, tal como NSP1 en este ejemplo. Para obtener acceso al NSP, completar una transaccion o acceder a una parte en particular de la red, un usuario debe iniciar sesion a traves de un dispositivo de red. El NSP puede pasar entonces un identificador de cuenta de usuario final (EAI) al servidor de deteccion de fraude 26. Un programa cliente en el dispositivo de red puede generar una huella digital de dispositivo de red (NDF) para el dispositivo de red (a menos que una huella digital ya se haya asignado a ese dispositivo de red) y envfa esa NDF al servidor de deteccion de fraude. El servidor de deteccion de fraude almacena el EAI y la NDF en la NDRD 30. En funcion del EAI y la NDF, como se describe posteriormente con mas detalle, se determina la probabilidad de que el usuario final particular cometa fraude con el dispositivo de red ND1, y se lleva a cabo una accion apropiada. Suponiendo que el dispositivo de red ND1 obtiene acceso a la red 20, el dispositivo de red realiza su transaccion electronica. Si se produce una actividad fraudulenta durante esa transaccion electronica, esa informacion tambien se almacena en la NDRD 30. De esta manera, el uno o mas proveedores de servicios de red 24 comparten informacion de fraude entre sf de forma selectiva (como se describe posteriormente con mas detalle) de manera que un fraude cometido contra un proveedor de servicios de red se registra en y es rastreado por el sistema de deteccion de fraude segun la invencion. Por lo tanto, se hace un seguimiento de un dispositivo de usuario o de red que haya cometido actividades fraudulentas, incluso cuando el dispositivo de usuario o de red se conecta a un proveedor de servicios de red diferente. Por lo tanto, se realiza un seguimiento de las actividades fraudulentas de un dispositivo de usuario o de red en todo el sistema de transacciones electronicas 20. A continuacion se describira cada dispositivo de red con mayor detalle.

La Figura 2 es un diagrama que ilustra un ejemplo de un dispositivo de red 22 segun la invencion. En este ejemplo, el dispositivo de red es un ordenador personal. En este ejemplo, el dispositivo de red tiene un dispositivo de visualizacion 32, tal como una pantalla de tubo de rayos catodicos o de cristal lfquido, para mostrar informacion y (opcionalmente imagenes) al usuario del dispositivo de red, un chasis 34 y uno o mas dispositivos de entrada/salida para permitir al usuario comunicarse con el dispositivo de red y permitir que el dispositivo de red se comunique con el mundo exterior, tales como un teclado 36, un raton 38 y un dispositivo 40 para la conexion y comunicacion con una red de comunicaciones, tal como una tarjeta de interfaz de red, un modem por cable, un modem DSL, un modem inalambrico, un modem de lmea telefonica, etc. El dispositivo de red 22 comprende ademas uno o mas procesadores 42, un dispositivo de almacenamiento persistente 44, tal como una unidad de cinta optica, una unidad optica, una unidad de disco duro, memoria flash, etc., que almacena datos incluso cuando el sistema informatico esta apagado, y una memoria 46, tal como SRAM, DRAM, SDRAM, etc., que almacena temporalmente datos que estan siendo ejecutados por el procesador y que, por lo general, pierden los datos cuando el sistema informatico se apaga. Normalmente, cuando el procesador esta ejecutando las instrucciones de un programa de ordenador o procesando datos en base a dichas instrucciones, las instrucciones y los datos se cargan en la memoria 46. De este modo, cuando el dispositivo de red esta comunicandose con el sistema de transacciones electronicas 20, la memoria puede almacenar un sistema operativo (OS) 48, una aplicacion de navegador 50 y un paquete de software descargado 52, donde cada uno de estos son un programa de software que tiene una pluralidad de lmeas de instrucciones que hacen que el dispositivo de red lleve a cabo una funcion particular. Por ejemplo, el sistema operativo 48, tal como Windows 2000, puede funcionar para mostrar al usuario una interfaz grafica de usuario y permitir al usuario ejecutar otros programas de ordenador, tales como la aplicacion de navegador 50 y uno o mas paquetes de software descargados 52. La aplicacion de navegador, tal como Netscape Navigator o Microsoft Internet Explorer, cuando es ejecutada por el procesador, permite al usuario acceder a la World Wide Web como es bien sabido. En este ejemplo, el dispositivo de red 22 puede conectarse a los proveedores de servicios de red (tambien conocidos como ordenadores centrales) utilizando la aplicacion descargable 52 distribuida por cada ordenador central. Por ejemplo, para conectarse al ordenador central 1, los usuarios deben iniciar sesion a traves del paquete de software de cliente 1, y para conectarse al ordenador central 2, los usuarios deben iniciar sesion a traves del paquete de cliente de software 2, etc. Segun la invencion, cada paquete de software descargado puede incluir un pequeno programa cliente 54 que se ejecuta en el dispositivo de red y que, entre otras cosas, realiza algunas funciones de prevencion y de deteccion de fraude y genera la huella digital de dispositivo de red segun la invencion como se describe posteriormente.

Segun la invencion, cada paquete de software de cliente incluye un pequeno elemento de software que realiza una parte de un procedimiento de registro de dispositivo red (NDRM) comun que se describe con mayor detalle posteriormente con referencia a la Figura 7. En el ejemplo mostrado en la Figura 1, cada ordenador central representa un entorno de red privada diferente utilizado por organizaciones independientes que no comparten identidades de usuario final. Tambien en este ejemplo, la NDRD centralizada 30 utilizada por cada ordenador central esta ubicada de forma remota en el servidor de deteccion de fraude 26 y es un servicio proporcionado por un tercero. Los expertos en la tecnica apreciaran que el NDRM puede implementarse de varias maneras diferentes que estan dentro del alcance de esta invencion. Por ejemplo, el NDRM puede estar distribuido a traves de una pluralidad de dispositivos informaticos (sin ningun servidor central de deteccion de fraude 26 y ninguna NDRD central), donde cada dispositivo informatico, tales como una combinacion de los dispositivos de red y de proveedores de servicios de red, realiza parte de las funciones del sistema de prevencion y de deteccion de fraude segun la invencion. Como alternativa, el NDRM puede estar incluido en una aplicacion personalizada, integrado en la aplicacion del navegador u otra aplicacion/aplicaciones comun(es) o en el firmware. Ademas, el NDRM puede ser una aplicacion independiente o ejecutarse de forma remota, y todos estos ejemplos del NDRM estan dentro del alcance de la invencion. Ademas, el NDRM puede ejecutarse antes, despues y/o durante la conexion a una red o a intervalos periodicos, donde todas las combinaciones de esto estan dentro del alcance de la invencion.

El NDRM segun la invencion puede personalizarse para diferentes tipos de dispositivos de red. Por ejemplo, con un ordenador personal que se conecta a un NSP, el NDRM puede utilizar el NDI y la NDF para identificar el dispositivo de red. Con un telefono celular, normalmente es posible extraer datos del telefono celular, tal como su numero de serie, de modo que una NDF solo puede utilizarse para identificar el dispositivo de red de telefoma celular. En cuanto a un dispositivo de red de tipo asistente personal digital (PDA), normalmente es posible introducir datos/informacion en el PDA solamente para que el NDI pueda utilizarse para identificar el PDA. Como otro ejemplo, un PC que utiliza Linux necesitara un cliente diferente al de un PC basado en Windows. Segun la invencion, el NDRM tambien se puede llevar a la practica en una situacion en la que puede usarse un dispositivo de hardware, tal como una tarjeta inteligente o una tarjeta PCMCIA, con un modulo cliente contra el fraude precargado en la tarjeta, donde la tarjeta tiene su propio identificador unico que puede utilizarse para identificar de manera unica la tarjeta. Por lo tanto, el NDRM segun la invencion puede implementarse de varias maneras diferentes. A continuacion se describiran mas detalles de un proveedor de servicios de red (NSP) a modo de ejemplo.

La Figura 3 es un diagrama que ilustra un ejemplo de un proveedor de servicios de red 24 segun la invencion. En este ejemplo, el proveedor de servicios de red puede ser uno o mas ordenadores de tipo servidor basado en web, tal como un servidor web, un servidor de aplicaciones, un servidor de base de datos, etc., que son capaces de comunicarse con un dispositivo de red a traves una red de comunicaciones, tales como Internet o una red inalambrica, y son capaces de descargar paginas web o una aplicacion de software en el dispositivo de red. El proveedor de servicios de red 24 comprende en este ejemplo uno o mas procesadores 60, uno o mas dispositivos de almacenamiento persistente 62, tales como los descritos anteriormente, y una memoria 64, tal como se describio anteriormente. Para que el proveedor de servicios de red 24 proporcione los servicios a los dispositivos de red, la memoria puede almacenar (y el/los procesador(es) puede(n) ejecutar) un sistema operativo de servidor 64 y un sistema de software de procesamiento de transacciones 68 para facilitar una transaccion electronica entre el proveedor de servicios de red 24 y uno o mas dispositivos de red. Por ejemplo, el procesador de transacciones puede procesar apuestas en un sitio de juegos de azar o compras en un sitio de comercio electronico. El proveedor de servicios de red 24 puede comprender ademas un paquete de software cliente 70 que se almacena en el proveedor de servicios de red y que despues se descarga en cada dispositivo de red que quiera llevar a cabo una transaccion con el proveedor de servicios de red particular. Por ejemplo, el paquete de software cliente puede ser un juego de mesa virtual de poquer, un juego de blackjack virtual, una maquina tragaperras virtual, una interfaz de usuario de comercio electronico, etc. Segun la invencion, cada paquete de software cliente puede incluir un modulo cliente de deteccion de fraude 72 (que puede ser, preferiblemente, una pluralidad de lmeas de codigo y datos) que es ejecutado por cada dispositivo de red para implementar el sistema de prevencion y de deteccion de fraude en este ejemplo. Cada proveedor de servicios de red 24 puede comprender ademas una base de datos 74, tal como un servidor de base de datos o una estructura de datos almacenada en la memoria del proveedor de servicios de red, que almacena los datos de transacciones electronicas ampliamente conocidos para el proveedor de servicios de red. En una forma de realizacion utilizada como ejemplo, el sistema utiliza un cliente de deteccion de fraude 72 integrado. En una implementacion del sistema, el cliente esta integrado en una aplicacion de software propietaria, por ejemplo para que el cliente pueda estar incluido dentro de un programa distribuido por un proveedor de servicios de red que se debe utilizar para conectarse a la red. En otra forma de realizacion, el cliente tambien puede suministrarse a traves de una aplicacion independiente, estar integrado en un producto de software comun, tal como un navegador web, o incluso estar integrado en hardware o memoria, siendo necesario que, de cualquiera de las maneras, este en ejecucion cuando se autentica una conexion a una red mediante un proveedor de servicios de red protegido por este sistema. En otra forma de realizacion, el cliente tambien podna suministrarse bajo demanda, a traves de JavaScript, un control ActiveX u otra tecnologfa similar cuando un usuario se conecta a un proveedor de servicios de red a traves de su navegador web favorito. Segun la invencion, el sistema puede implementarse sin ningun cliente en el dispositivo de red. Por ejemplo, en un sistema de pedidos telefonico o por correo, el sistema puede establecer un identificador unico del usuario en base a un numero de telefono mediante el cual el operador de venta por correo puede llamar al usuario para verificar ese numero de telefono y luego usar ese numero de telefono como identificador unico del usuario. En este caso, el sistema utiliza una NDF (el numero de telefono). Despues, segun la invencion, el numero de telefono puede almacenarse en la base de datos y despues usarse como se describe posteriormente.

Por tanto, segun la invencion, el cliente 72, para el dispositivo en el que esta instalado, determina el estado del dispositivo (puesto que ya tiene un identificador unico, o no) y controla la conexion del dispositivo al proveedor de servicios de red. El proveedor de servicios de red controla cada dispositivo y/o el acceso de cada usuario a los recursos del proveedor de servicios de red, por ejemplo denegando el acceso a un usuario o dispositivo, tal como se describe posteriormente. Por lo tanto, el proveedor de servicios de red utiliza el estado de dispositivo/usuario proporcionado por el cliente con el fin de controlar eficazmente la seguridad de la red y evitar el fraude. A continuacion se describira un ejemplo del servidor de deteccion de fraude.

La Figura 4 es un diagrama que ilustra un ejemplo del servidor de deteccion de fraude 26 segun la invencion. En este ejemplo, el servidor de deteccion de fraude 26 es un recurso informatico independiente, tal como un ordenador de tipo servidor, con la NDRD 30, aunque las funciones del servidor de deteccion de fraude 26 y la NDRD 30 pueden estar distribuidas, como se ha descrito anteriormente. El servidor de deteccion de fraude 26 puede incluir uno o mas procesadores 80, uno o mas dispositivos de almacenamiento persistente 82, como los descritos anteriormente, y una memoria 84, como se describio anteriormente. El servidor de deteccion de fraude puede incluir ademas un servidor/gestor de base de datos 86 que almacena la NDRD 30 segun la invencion. La estructura y el funcionamiento del procesador, del dispositivo de almacenamiento persistente y de la memoria se han descrito anteriormente. La memoria puede almacenar un sistema operativo de servidor 88, un modulo de software de administracion 90, un modulo de software de deteccion de fraude 92, un modulo de software de informes 94 y un modulo de software de etiquetado 96, donde cada modulo comprende una pluralidad de instrucciones (y datos asociados) que son ejecutados por el procesador para implementar el sistema de prevencion y deteccion de fraude. Segun la invencion, el cliente 72 descargado en el dispositivo puede realizar el "etiquetado" de cada dispositivo, donde el cliente puede determinar si el dispositivo ya tiene un identificador unico del servidor 26 o si solicitara un nuevo identificador unico. El sistema operativo del servidor es ampliamente conocido. El modulo de administracion 90, en una forma de realizacion preferida, puede generar paginas web de administracion que permiten al usuario del sistema de prevencion y de deteccion de fraude interactuar con el sistema usando las paginas web y configurar el sistema. Por ejemplo, las paginas web de administracion pueden permitir al usuario configurar elementos del sistema, ajustar elementos de consulta y actualizar elementos. En la configuracion de los elementos del sistema, el usuario puede activar/desactivar la verificacion maestra, donde el estado desactivo siempre aceptara que un nuevo dispositivo de usuario o de red acceda a la red. El usuario tambien puede configurar el numero maximo de usuarios (nombres de usuario diferentes, distintos) que pueden compartir un determinado dispositivo de red/resultados y el numero maximo de dispositivos de red que un solo usuario puede utilizar. Si se excede el umbral maximo antes establecido y la verificacion maestra esta activada, entonces el sistema de prevencion y de deteccion de fraude puede restringir el acceso para el dispositivo de red o usuario que haya superado los valores umbral. El usuario tambien puede establecer si un estado de cada usuario de un proveedor de servicios de red particular puede influir en las operaciones de deteccion de fraude, tal como permitir la creacion de cuentas, permitir el inicio de sesion, permitir un deposito en una cuenta o permitir abandonar una cuenta. El modulo de administracion tambien permite al usuario configurar los elementos de consulta que extraen informacion de la base de datos del sistema de prevencion y deteccion de fraude. Por ejemplo, el usuario puede generar una consulta de, dado un dispositivo de red particular, que usuarios han usado ese dispositivo de red o una consulta que solicita, dado un usuario particular, que dispositivos de red han sido utilizados por el usuario particular. El usuario tambien puede configurar una consulta que solicita, dado un dispositivo de red particular, que otros proveedores de servicios de red configuraron este dispositivo de red para asociar usuarios/ordenadores a un numero predeterminado de niveles de profundidad o, dado un usuario en particular, cual es el estado actual de ese usuario en el sistema. El modulo de administracion tambien permite la configuracion de los elementos de actualizacion. Por ejemplo, el usuario puede establecer que siempre se acepte que un dispositivo de red particular acceda al sistema, establecer que un determinado dispositivo de red sea aceptado en el sistema, establecer que un determinado dispositivo de red sea atrapado por el sistema (para determinar ademas las intenciones del dispositivo de red), establecer que un determinado dispositivo de red debe sea rechazado por el sistema o establecer que un usuario dado sea siempre aceptado por el sistema (por ejemplo, todos los dispositivos de red asociados al usuario siempre seran aceptados). El usuario tambien puede establecer que un usuario dado sea aceptado durante un intervalo predeterminado o un intento de acceso predeterminado (los dispositivos de red asociados al usuario son aceptados), establecer que un usuario dado (y todos los dispositivos de red asociados al usuario) sean atrapados o establecer que un usuario dado (y todos los dispositivos de red asociados al usuario) sean rechazados. Los ordenadores centrales pueden fijar cualquier numero de niveles de estado de dispositivo y de usuario, y establecer cualquier numero de patrones de comportamiento, cada uno de los cuales podna requerir una accion diferente, tales como notificar una direccion de correo electronico particular, localizar un numero particular, denegar el acceso a la red, permitir el acceso pero cambiar el estado del dispositivo, etc.

El modulo de software de informes 94 permite a un usuario configurar y generar informes acerca del sistema de prevencion y de deteccion de fraude y su base de datos. Por ejemplo, el sistema puede generar un informe que muestra un informe de cambios diario (con una lista de los dispositivos de red cuyo estado ha cambiado), un informe de fraude de terceros que enumera los dispositivos de red que otros proveedores de servicios de red conocen y su estado, o un informe de ordenadores compartidos que enumera todos los dispositivos de red que tienen varias cuentas de usuario asociadas a los mismos. El modulo de informes tambien puede generar un informe de multiples ordenadores que enumera los usuarios que han utilizado varios dispositivos de red y los dispositivos de red utilizados por cada usuario, y un informe de uso que enumera el numero de consultas de administrador, actualizaciones de administrador, consultas de la API y el numero de dispositivos de red que estan siendo rastreados por el sistema de deteccion de fraude. El modulo de software de deteccion de fraude 92 contiene las instrucciones y la logica, en base a los datos de los dispositivos de red y los usuarios, para determinar el estado apropiado de un dispositivo de usuario/red particular y su estado de acceso en el sistema de transacciones electronicas. Segun la invencion, cada proveedor de servicios de red puede establecer sus propias reglas de estado. Por ejemplo, un proveedor de servicios de red particular puede establecer un "SP' o un "No" para la conexion con el proveedor de servicios de red. Como otro ejemplo, un proveedor de servicios de red particular puede tener un estado "Sf para conectarse, pero generar una puntuacion para el dispositivo de red particular", o un estado "Sf, pero capturar la informacion acerca del dispositivo de red". Posteriormente se describira con mas detalle la logica de deteccion de fraude.

El modulo de software de etiquetado 96 contiene la variedad de software, logica y datos para identificar de manera unica cada dispositivo de red (generar el identificador para un dispositivo de red particular) que esta estableciendo una conexion con el sistema de transacciones electronicas. La conexion con el sistema puede incluir, pero sin limitarse a, una conexion inicial con la red, una configuracion de cuenta, un inicio de sesion, un cambio en la informacion de cuenta, un deposito, un reintegro, una compra, una conexion totalmente aleatoria a la red, etc. Segun la invencion, el procedimiento real para el etiquetado de cada dispositivo de red puede variar, como se describe posteriormente. Segun la invencion, cada dispositivo de red se identifica de manera unica de forma que se hace un seguimiento de cada dispositivo en el sistema, incluso cuando un usuario diferente inicia sesion en un ordenador central con el mismo dispositivo de red. El etiquetado de dispositivos de red individuales permite que el sistema de deteccion de fraude deniegue el acceso a un ordenador central a un usuario particular (independientemente del dispositivo de red que se utilice), a un dispositivo de red particular (independientemente del usuario que este utilizando el dispositivo de red), a la combinacion de un usuario particular con un dispositivo de red particular, o a cualquier combinacion de usuarios y dispositivos. A continuacion se describiran con mas detalle ejemplos de la base de datos de usuario en cada proveedor de servicios de red y la base de datos de registro de dispositivos de red del sistema de deteccion de fraude.

La Figura 5 ilustra ejemplos de una parte de una base de datos 100i, 1002, IOO3, IOO4 para cada proveedor de servicios de red (NSP 1, NSP 2, NSP 3 y NSP 4) en un sistema de transacciones electronicas que tiene cuatro proveedores de servicios de red. Segun la invencion, la informacion contenida en estas bases de datos se reenvfa al sistema de deteccion de fraude para que el sistema de deteccion de fraude pueda distinguir los usuarios de cada proveedor de servicios de red con respecto a los usuarios de otros proveedores de servicios de red. Cada proveedor de servicios de red tiene un identificador de cuenta de usuario final (EAI), tales como EA11 - EAlni, EAI12- EAIn2, EAI 13 - EAI n3 y EAI 14 - EAI n4. En este ejemplo, NSP 1, NSP 2 y NSP 3 usan un EAI individual que no proporciona ninguna informacion acerca de la cuenta del usuario, mientras que NSP 4 utiliza el ID de usuario real del usuario final ("Tim1" y "Smurf') como EAI. Todo lo que el sistema de fraude necesita es que cada ordenador central proporcione un EAI que tenga una relacion directa con una cuenta unica en ese ordenador central.

La Figura 6 es un diagrama que ilustra un ejemplo de una base de datos de registro de dispositivo de red rellenada 110. En este ejemplo, la base de datos es una tabla de base de datos que contiene la informacion pertinente. Sin embargo, los datos pueden almacenarse en diferentes bases de datos y diferentes estructuras de datos de base de datos que esten dentro del alcance de esta invencion. En este ejemplo, la NDRD 110 puede incluir una columna de ordenador central 112, una columna de EAI 114 y una columna de identificador de dispositivo de red (NDI) 116 que permite al sistema de deteccion de fraude asociar un ordenador central particular a un usuario particular y a un dispositivo de red particular. Como se describio anteriormente, los EAI representan cuentas de usuario final que son unicos para cada ordenador central. Los identificadores de dispositivo de red (NDI) representan dispositivos de red unicos que se han conectado a al menos un ordenador central. Las filas individuales de la tabla de base de datos representan combinaciones unicas de ordenador central, EAI y NDI. Por ejemplo, una primera fila 118 que representa un EAI11 para el ordenador centrah a partir del NDI1 representa una cuenta procedente de un dispositivo espedfico (NDI) y que intenta conectarse al ordenador central 1. Si esta misma cuenta se conectase al ordenador central 1 desde un dispositivo diferente, se creara una nueva fila 120, por ejemplo EAI11 para el ordenador centrah a partir del NDI2, de modo que el acceso por parte del mismo usuario a traves de dos dispositivos de red diferentes es rastreado y registrado en el sistema. Si el usuario final representado por el EAI11 en el ordenador centrah tiene una cuenta en el ordenador centra^ (mostrado como EAI12 ya que cada ordenador central tiene sus propios EAI unicos) y se conecta al ordenador centra^ a partir del NDI2, se creara una nueva entrada 122, tal como el EAI12 para el ordenador centra^con el NDI2, de modo que el mismo usuario que se conecta a un proveedor de servicios de red diferente con el mismo dispositivo de red es rastreado y registrado en el sistema de fraude. Puede mantenerse una gran cantidad de informacion adicional, tal como la fecha y hora del ultimo inicio de sesion con exito, la fecha y hora del ultimo inicio de sesion fallido, los inicios de sesion con exito totales, los inicios de sesion fallidos totales, etc. A continuacion se describe con mayor detalle un procedimiento para el registro de dispositivos de red segun la invencion.

La Figura 7 es un procedimiento 130 para etiquetar un dispositivo de red (procedimiento de registro de dispositivo de red) segun la invencion. El procedimiento logra el objetivo de identificar de manera unica cada dispositivo de red que se conecta al sistema de transacciones electronicas que el sistema de prevencion y de deteccion de fraude esta vigilando. Idealmente, este procedimiento se lleva a cabo cada vez que un dispositivo se conecta a un ordenador central protegido por este sistema, y tambien puede llevarse a cabo en varios puntos e intervalos a lo largo de una sesion. Por ejemplo, el sistema puede realizar periodicamente el procedimiento para comprobar periodicamente cada dispositivo conectado a la red. Por lo tanto, en la etapa 132, el procedimiento determina si el dispositivo de red es nuevo (por ejemplo, si el dispositivo de red ya esta registrado en la NDRD y ya tiene asignado un identificador unico). Si el dispositivo de red es nuevo y no tiene una huella digital unica, entonces, en la etapa 134, el procedimiento genera una huella digital unica (etiqueta) para el dispositivo de red. La huella digital unica puede ser generada por el programa cliente 54 en cada dispositivo de red (en el ejemplo mostrado en la Figura 2) o por otros medios, tales como el servidor de deteccion de fraude 26 que genera una huella digital para cada dispositivo de red basandose en informacion recibida desde el dispositivo de red o cualquier combinacion. La huella digital unica se almacena despues en la base de datos en la etapa 136 y el procedimiento se completa de modo que cada dispositivo de red unico en el sistema es identificado de manera unica.

Por lo tanto, cuando un dispositivo de red intenta conectarse a una red por primera vez, el procedimiento garantiza que el dispositivo esta registrado (y por tanto, rastreado) al menos de dos maneras diferentes. En primer lugar, el procedimiento solicita un identificador de dispositivo de red (NDI) unico a partir de la NDRD 30 a traves del ordenador central. El procedimiento almacena de manera fehaciente el NDI cifrado en al menos dos elementos; por ejemplo, la parte A en el registro y la Parte B en un archivo. Los NDI son distribuidos por la NDRD y se garantiza que sean unicos. El procedimiento tambien genera una huella digital de dispositivo de red (NDF) para cada dispositivo recopilando discretamente informacion acerca del dispositivo, como los numeros de serie de hardware, los numeros de serie de software, fechas de instalacion y otra informacion, y envfa la NDF resultante a la NDRD a traves del ordenador central (el proveedor de servicios de red). Aunque no se garantiza que los componentes individuales de una NDF sean unicos, el aumento del tamano de la NDF o del numero de elementos de informacion utilizados para crear la NDF aumenta la probabilidad de que la NDF resultante sea unica y aumenta su valor para su identificacion positiva. Segun la invencion, la combinacion del NDI y la NDF es unica y permite que cada dispositivo de red se identifique de manera unica. Por lo tanto, el NDI mostrado en la Figura 6 incluye la NDF ya que la combinacion identificara de manera unica un dispositivo de red.

La metodologfa exacta para el registro de un dispositivo no es cntica, siempre que identifique de manera unica los dispositivos con una probabilidad extremadamente alta. Por ejemplo, diversos procedimientos para identificar dispositivos de manera unica pueden ser ligeramente diferentes para adaptar aspectos unicos de clientes ligeros, ordenadores de mano, telefonos celulares, terminales de juego y otros tipos de dispositivos. Segun la invencion, el programa cliente 54 puede recopilar informacion para cada dispositivo de red con el fin de generar la NDF. Es muy probable que los ordenadores centrales que utilizan este sistema puedan distribuir un procedimiento de registro comun de diferentes maneras, dependiendo de las caractensticas de usuario final y las plataformas tfpicas usadas para conectarse a su red, o incluso ejecutar el procedimiento de registro de forma remota.

Ademas de facilitar la comunicacion entre el NDRM y la NDRD, el ordenador central de tipo proveedor de servicios de red tambien transmite un identificador de cuenta de usuario final (EAI) a la NDRD asociada a la cuenta espedfica de usuario final que esta intentando acceder/conectarse al proveedor de servicios de red. Este identificador puede ser un numero de cuenta de cliente u otro valor unico asociado a una cuenta de usuario final espedfica que no se utiliza en el sistema de ordenador central para ningun otro proposito. Dependiendo de la relacion comercial entre el ordenador central y el proveedor de servicios NDRM, la informacion real del consumidor puede registrarse o no. Sin embargo, el que se proporcione o no informacion real de un consumidor no cambia sustancialmente el proceso. Segun la invencion, la NDRD realiza un seguimiento de cada dispositivo de red (que tenga un NDI unico) que trata de conectarse a un ordenador central, junto con su NDF correspondiente. La NDRD tambien mantiene una asociacion para cada EAI que se conecta desde cada dispositivo de red unico. La NDRD tambien rastrea informacion tal como la primera conexion, la ultima conexion, las conexiones totales, la ultima conexion fallida, las conexiones totales fallidas, el estado de NDI por ordenador central y el estado de NDF por ordenador central. Segun la invencion, el sistema puede utilizar el NDI, la NDF, la combinacion del NDI y la NDF u otra informacion con el fin de validar un usuario/dispositivo. Por ejemplo, la otra informacion puede ser un numero de serie de un telefono celular. A continuacion se describira con mayor detalle un ejemplo del esquema de base de datos preferido del sistema de deteccion de fraude.

La Figura 8A es un diagrama que ilustra las tablas de base de datos relacional para un ejemplo de una forma de realizacion preferida de un esquema de base de datos 140 (para el producto ieSnare de lovation, inc.) para un sistema de deteccion de fraude segun la invencion, y las Figuras 8B a 8E son diagramas que ilustran detalles adicionales de las tablas de base de datos mostradas en la Figura 8A. Como se muestra en la Figura 8A, el esquema de base de datos 140 puede incluir una pluralidad de tablas de base de datos que incluye una tabla SNARE_USER_TOKEN_ACTIVITY 141, una tabla SNARE_USER_TOKEN 142, una tabla SNAREJJSER 143, una tabla SNARE^j AFFILIATE 144, una tabla SNARE_SOAPD_AJDIT 145, una tabla SNARE_ACTIVITY_TYPE 146, una tabla SNARE_TOKEN_ACTIVITY 147, una tabla SNARE_TOKEN 148, una tabla SNARE_TOKEN_NJID 149, una tabla SNARE_AFFIL_TOKEN 150 y una tabla SNARE_TOKEN_STATJS 151 que estan vinculadas entre sf por al menos una clave primaria, tal como SNAREjJSRjTKN_2jJSRjTKNjACTjFK, como se muestra. Las diversas claves primarias entre cada tabla en el esquema de base de datos no se describen aqrn, pero aparecen en la figura 8A. En estas tablas de bases de datos, la variable TOKEN corresponde al NDI descrito en otra parte de este documento, y la variable NJID corresponde a la NDF descrita en otra parte de este documento.

La Figura 8B ilustra mas detalles de la tabla SNARE_JSER_TOKEN 142 y de la tabla SNAREj JSERj TOKENj ACTIVITY 141 junto con una tabla SNAREj TOKEN_NJID_HIST 152 y una tabla SNAREj AFFILj TOKENj HIST 153 que no se muestran en la Figura 8A. Como se muestra en la Figura 8B, se muestra cada campo de datos 154 de cada tabla, donde cada campo de datos contiene varias caractensticas, tales como el tipo de datos almacenados en el campo, etc. Segun la invencion, cada usuario del sistema puede tener una o mas credenciales (identificadores) que se almacenan en la tabla SNARE_JSER_TOKEN 142, y cualquier evento relacionado con una credencial particular de un usuario particular se almacena en la tabla SNAREj JSERj TOKENj ACTIVITY 141. Las tablas HIST 152, 153 contienen datos historicos acerca de las credenciales y las credenciales de afiliacion. La Figura 8C ilustra mas detalles de la tabla SNARE_JSER 143 (que contiene datos sobre cada usuario del sistema), la tabla SNARE_SOAPD_AJDIT 145 (que contiene informacion de depuracion del sistema) y la tabla SNARE_AFFIL_TOKEN 150 que contiene la una o mas credenciales (identificadores) para cada afiliado del sistema, donde el afiliado es un proveedor de servicios de red particular. La Figura 8D ilustra mas detalles de la tabla SNARE_AFFILIATE 144 (que contiene datos acerca de cada afiliado asociado al sistema), la tabla SNARE_TOKEN_ACTIVITY 147 (que contiene datos acerca de cualquier evento relacionado con una credencial particular) y la tabla SNARE_TOKEN_NJID 149, que contiene datos acerca de la huella digital para un dispositivo de red para un dispositivo con una credencial / un NDI particular. Finalmente, la Figura 8E ilustra mas detalles de la tabla SNARE_ACTIVITY_TYPE 146 (que contiene datos acerca de cada actividad rastreable unica/distinta que se produce en el sistema), la tabla SNARE_TOKEN 148 (que contiene datos acerca de cada credencial almacenada en el sistema) y la tabla SNARE_TOKEN_STATJS 151, que contiene estados unicos/distintos para cada credencial en el sistema.

Las Figuras 9A y 9B son un diagrama de flujo que ilustra un procedimiento preferido 200 para la validacion de un dispositivo y una correlacion dispositivo/cuenta, donde un ordenador central esta usando el sistema de prevencion y deteccion de fraude segun la invencion. Las Figuras 9C a 9F ilustran procedimientos para la validacion de un nuevo usuario/dispositivo y de un usuario/dispositivo existente segun la invencion. Las etapas descritas posteriormente pueden implementarse mediante instrucciones de ordenador en un modulo de software ejecutado por un ordenador central particular de un proveedor de servicios de red o mediante instrucciones de ordenador en un modulo de software ejecutado por el servidor de deteccion de fraude. La invencion no esta limitada a ninguna ubicacion particular de las instrucciones de ordenador que implementan el procedimiento de validacion. En funcionamiento, antes de que una cuenta (un dispositivo de red particular con un identificador de cuenta de usuario final particular) este autorizada por un ordenador central particular (proveedor de servicios de red), una serie de etapas de validacion se producen cada vez. Si el dispositivo de red particular o la correlacion dispositivo/cuenta que esta probandose no satisface ninguna de las etapas de validacion descritas a continuacion, la validacion se aborta y se impide que el dispositivo/cuenta acceda al ordenador central particular. Las etapas de validacion pueden ser iniciadas por ordenadores centrales en cualquier numero de puntos de interaccion con el consumidor, incluyendo, pero sin limitarse a, una conexion inicial con la red, una configuracion de cuenta, un inicio de sesion, un cambio en la informacion de cuenta, un deposito, un reintegro, una compra, una conexion totalmente aleatoria con la red, etc. En mas detalle, en la etapa 202, se determina si el identificador de dispositivo de red (NDI) es valido. Con mas detalle, el NDI no debe aparecer modificado, con el valor emitido originalmente por la NDRD, y no parecer que ha iniciado sesion actualmente en el mismo ordenador central. A un NDI no valido no se le permitira conectarse al ordenador central, como se muestra en la etapa 203. Si el NDI es valido, entonces, en la etapa 204, se determina si el par NDI / huella digital de dispositivo de red (NDF) coinciden. En particular, la NDF proporcionada en el inicio de sesion debe coincidir con el valor de NDF asociado originalmente con el NDI del dispositivo de red que trata de conectarse al ordenador central. Sin embargo, se permite un cierto cambio en la NDF. Por ejemplo, una 'variacion de NDF' debe considerarse como elementos individuales que se utilizan para calcular una NDF que puede cambiar con el tiempo. Generalmente, elementos adicionales no presentes en la NDF original, tales como un nuevo elemento de software o hardware que se ha instalado, no son preocupantes. En estos casos, la NDF se actualiza y los cambios se anotan. Sin embargo, cambios en los valores de NDF individuales existentes son mas preocupantes. Segun la invencion, cada ordenador central puede establecer reglas para la variacion del sistema y que uno o mas elementos de la NDF perciben como cnticas y, por lo tanto, no deben ser modificadas sin generar un mensaje de excepcion/error. Por ejemplo, el numero de serie de la unidad central de procesamiento puede ser considerado cntico y, por tanto, se generara un mensaje de error (un par NDI/NDF incompatible), mientras que un cambio en la cantidad de memoria en el dispositivo de red no puede causar por sf solo un par NDI/NDF incompatible. Como otro ejemplo, varios elementos no cnticos del dispositivo de red pueden ser modificados, pero se seguira considerando que el par NDF/NDI coincide. Asf, dependiendo de las reglas establecidas y mantenidas por cada ordenador central, puede considerarse que un par NDl/NDF no coincide y no se le permite conectarse al ordenador central en la etapa 203.

En la etapa 206, si el par NDI/NDF coincide, se determina si el estado de NDI es aceptable para el ordenador central particular. En particular, un dispositivo de red individual puede conectarse a varias redes protegidas por este sistema y, por lo tanto, el NDI particular puede estar asociado a varios ordenadores centrales. Segun la invencion, cada NDI tiene un estado para cada ordenador central que usa la NDRD, y cada ordenador central define cualquier numero de estados para los NDI. Cuando un dispositivo de red esta intentando conectarse al ordenador central 1, la NDRD sigue cualquier regla asociada al estado de NDI para el ordenador central 1. Por ejemplo, el ordenador central 1 puede establecer solamente dos niveles de estado, uno para permitir el acceso y uno para denegar el acceso. El ordenador central 2 puede establecer un unico conjunto de varios niveles de estado, donde cada estado tiene un conjunto diferente de criterios y donde cada estado determina a que area de su red puede acceder un dispositivo/una cuenta. El ordenador central 3 puede tener varios conjuntos de estados, donde el conjunto 1 se aplica a la conexion con la red, el conjunto 2 se aplica para acceder a diversas areas de la red, y el conjunto 3 se aplica a diversas actividades en la red (tal como establecer una nueva cuenta, cambiar la informacion de una cuenta, compras, etc.) y donde cada estado tiene un unico criterio establecido y mantenido por el ordenador central 3. Si el estado de NDI no es aceptable para el ordenador central particular, el procedimiento se interrumpe en la etapa 203 y se deniega el acceso. En la etapa 208, si el estado de NDI es aceptable para el ordenador central, se determina si el estado de NDF para el dispositivo de red particular es aceptable para el ordenador central particular. En particular, cada NDF tiene tambien un estado para cada ordenador central que usa la NDRD, y cada ordenador central define cualquier numero de estados para las NDF. Cuando un dispositivo de red esta intentando conectarse al ordenador central 1, la NDRD sigue cualquier regla asociada al estado de NDF para el ordenador central 1. Al igual que con los niveles de estado y las reglas asociadas de los NDI, los ordenadores centrales pueden establecer cualquier numero de niveles de estado para NDF apropiadas a su fin. Si el estado de NDF no es aceptable para el ordenador central particular, el procedimiento se interrumpe en la etapa 203 y se deniega el acceso. Estas dos etapas (206, 208) son una lmea de defensa contra los piratas informaticos que eliminan todo rastro de los NDI e intentan conectarse a una red protegida. En casos extremos, un nuevo NDI podna ser emitido a un dispositivo de red, pero el acceso a la red podna aun denegarse en funcion del estado de la NDF controlada por cada ordenador central, tanto de forma manual como por las reglas establecidas con la NDRD.

En la etapa 210, si el estado de NDF para el dispositivo de red es aceptable para el ordenador central particular, se determina si el estado de NDI para el dispositivo de red particular es aceptable para cualquier otro ordenador central identificado como de confianza por el ordenador central particular. En particular, dispositivos de red individuales pueden conectarse a varias redes protegidas por este sistema y, por lo tanto, el NDI puede estar asociado a varios ordenadores centrales. Al tratar de conectarse al ordenador central 1, el estado de NDI del ordenador central 1 puede ser valido, mientras que el estado de NDI para otros ordenadores centrales esta marcado como 'malo'. Segun la invencion, cada ordenador central puede identificar otros ordenadores centrales que son 'de confianza', por lo que si el estado de NDI es 'malo' para cualquier otro ordenador central de confianza, el acceso a la red se denegara independientemente del estado de NDI para el ordenador central 1. Esta etapa evita el fraude por un usuario que pueda tener un estado malo en un primer proveedor de servicios de red, pero no en un segundo proveedor de servicios de red y, por lo tanto, comparte informacion acerca de un dispositivo de red "malo" identificado por un NDI particular. Si el estado de NDI no es aceptable para ningun ordenador central de confianza, el procedimiento se interrumpe en la etapa 203 y se deniega el acceso.

En la etapa 212, si el NDI es aceptable para todos los ordenadores centrales de confianza, se determina si el estado de NDF es aceptable para cualquier otro ordenador central considerado como "de confianza" por el ordenador central particular. En particular, dispositivos de red individuales pueden conectarse a varias redes protegidas por este sistema y, por lo tanto, una NDF particular puede estar asociada a varios ordenadores centrales. Al tratar de conectarse al ordenador central 1, el estado de NDF del ordenador central 1 puede ser valido, mientras que el estado de NDF para otros ordenadores centrales esta marcado como 'malo'. Cada ordenador central puede identificar otros ordenadores centrales que son 'de confianza', por lo que si el estado de NDF es 'malo' para cualquier otro ordenador central de confianza, el acceso a la red se denegara independientemente del estado de NDI para el ordenador central 1. Esta etapa comparte informacion acerca de los estados de NDF de dispositivos de red a traves del sistema de transacciones electronicas. Si la NDF del dispositivo de red particular no es aceptable para un ordenador central de confianza, a la cuenta con la NDF se le niega el acceso. En la etapa 214, si la NDF es aceptable para todos los ordenadores centrales de confianza, entonces se determina si el numero de identificadores de cuenta de usuario final (EAI) por NDI esta dentro del intervalo aceptable para el ordenador central particular. En particular, cada ordenador central establece reglas para la pluralidad de EAI permitidos por NDI o, dicho de otro modo, la pluralidad de usuarios que pueden utilizar un dispositivo de red individual. Por ejemplo, el ordenador central 1 puede no estar preocupado por 3, o menos, cuentas procedentes de un PC individual, puede que quiera ser advertido acerca de 4-6 cuentas procedentes de un PC, y puede desear denegar el acceso a red a cualquier intento de inicio de sesion en el que 7 o mas cuentas procedan del mismo PC. Para cada conjunto de reglas pueden introducirse diferentes niveles de preocupacion y diferentes remedios (ninguna accion, advertencia o denegacion de acceso), y los niveles particulares de preocupacion y remedios pueden ajustarse por cada ordenador central segun la invencion. Como otro ejemplo, otro ordenador central puede permitir solamente una cuenta por dispositivo de red y denegar el acceso a cualquier intento de inicio de sesion en el que mas de una cuenta haya tratado de conectarse desde el mismo dispositivo de red.

En la etapa 216 se determina si el numero de NDI por cada EAI esta dentro del intervalo aceptable para el ordenador central particular. En particular, cada ordenador central tambien establece reglas para la pluralidad de NDI a partir de los cuales cada ^eA ⁱ esta autorizado a conectarse o, dicho de otro modo, la pluralidad de dispositivos de red diferentes a partir de los cuales una cuenta individual esta autorizada a conectarse. Por ejemplo, el ordenador central 1 puede no estar preocupado por una cuenta que procede de 5, o menos, PC, puede que quiera ser avisado de una cuenta que utiliza entre 6 y 10 PC, y puede desear denegar el acceso a red a cualquier inicio de sesion que haya intentado conectarse desde 11 o mas PC. Otro ordenador central puede permitir solamente una cuenta por PC y denegar el acceso a cualquier intento de inicio de sesion procedente de un segundo dispositivo de red. Por lo tanto, estos niveles de preocupacion y remedios pueden ajustarse por cada ordenador central segun la invencion. En la etapa 218, la cuenta identificada por el par de NDI y EAI particular (que ha superado todas las pruebas descritas anteriormente) puede acceder al sistema del proveedor de servicios de red particular, y los datos acerca de la transaccion/conexion se introducen en la NDRD.

Las Figuras 9C y 9D son un diagrama de flujo que ilustra un procedimiento preferido 220 para la validacion de un nuevo usuario/dispositivo usando el sistema de prevencion y deteccion de fraude segun la invencion. Las etapas descritas posteriormente pueden implementarse mediante instrucciones de ordenador en un modulo de software ejecutado por un ordenador central particular de un proveedor de servicios de red o mediante instrucciones de ordenador en un modulo de software ejecutado por el servidor de deteccion de fraude. La invencion no esta limitada a ninguna ubicacion particular de las instrucciones de ordenador que implementan el procedimiento de validacion. En la etapa 222, un usuario inicia una aplicacion (despues de descargar la aplicacion desde el proveedor de servicios de red en la forma de realizacion en la que el cliente esta integrado en una aplicacion) y la aplicacion inicia automaticamente el cliente. En la etapa 224, el cliente determina si el dispositivo esta registrado con el sistema de deteccion de fraude. Si el dispositivo ya esta registrado, entonces el procedimiento finaliza y el procedimiento para la validacion de un usuario existente se describe en las Figuras 9E y 9f . Si el cliente no detecta que el dispositivo ya esta registrado, entonces, en la etapa 226, el cliente solicita un nuevo NDI (identificador/credencial/numero de serie) desde el proveedor de servicios de red, que reenvfa la solicitud al servidor de deteccion de fraude 26. El servidor genera un NDI unico y lo pasa al proveedor de servicios de red que, posteriormente, reenvfa el NDI al cliente. Despues, el cliente almacena el n Di en su disco y en su registro. En la etapa 228, el cliente recopila datos del dispositivo, genera una NDF y reenvfa esa NDF al proveedor de servicios de red. En la etapa 230, el proveedor de servicios de red reenvfa la n Df al servidor que almacena la NDF y comprueba la NDF con datos de n Df existentes para el estado de la NDF particular.

En la etapa 232, el servidor determina si la NDF esta duplicada, tal como si un pirata informatico hubiera eliminado el NDI anterior en el dispositivo, pero la NDF era identica a una NDF existente. Si hay una NDF duplicada, entonces el proveedor de servicios de red es notificado en la etapa 234 y la sesion de usuario finaliza. En la etapa 236, si la NDF no esta duplicada (lo que indica un nuevo dispositivo), el servidor devuelve un mensaje de acuse de recibo de proceso de validacion al proveedor de servicios de red. En la etapa 238, el proveedor de servicios de red presenta al usuario un cuadro de dialogo de inicio de sesion. En la etapa 240, el proveedor de servicios de red determina si se proporcionan un nombre de usuario y una contrasena validos. Si se proporciona un nombre de usuario o una contrasena no validos, la sesion de usuario finaliza en la etapa 242. En la etapa 244, si se proporcionan un nombre de usuario y una contrasena validos, el proveedor de servicios de red envfa el NDI del dispositivo y la informacion de cuenta de usuario final (EAI) generada por el proveedor de servicios de red al servidor. En la etapa 246, el servidor registra la asociacion de NDI y EAI en su base de datos y actualiza diversa informacion para el dispositivo, tal como la fecha/hora del ultimo inicio de sesion con exito, los inicios de sesion totales y otros datos sobre el dispositivo. En la etapa 250, el servidor comprueba el estado de NDI y EAI con los parametros del proveedor de servicios de red. En la etapa 252, basandose en las reglas del proveedor de servicios de red, el servidor envfa el estado de NDI/EAI al proveedor de servicios de red. En la etapa 254, el proveedor de servicios de red termina/continua la sesion del usuario en funcion del estado de NDI/EAI devuelto por el servidor. A continuacion se describira con mayor detalle un procedimiento para la validacion de un usuario/dispositivo existente.

Las Figuras 9E y 9F son un diagrama de flujo que ilustra un procedimiento preferido 260 para la validacion de un usuario/dispositivo existente usando el sistema de prevencion y deteccion de fraude segun la invencion. Las etapas descritas posteriormente pueden implementarse mediante instrucciones de ordenador en un modulo de software ejecutado por un ordenador central particular de un proveedor de servicios de red o mediante instrucciones de ordenador en un modulo de software ejecutado por el servidor de deteccion de fraude. La invencion no esta limitada a ninguna ubicacion particular de las instrucciones de ordenador que implementan el procedimiento de validacion. En la etapa 262, un usuario inicia una aplicacion (despues de descargar la aplicacion desde el proveedor de servicios de red en la forma de realizacion en la que el cliente esta integrado en una aplicacion) y la aplicacion inicia automaticamente el cliente. En la etapa 264, el cliente determina si el dispositivo esta registrado con el sistema de deteccion de fraude. Si el dispositivo no esta registrado aun, entonces el procedimiento finaliza y el procedimiento para la validacion de un nuevo usuario se describe en las Figuras 9C y 9D. Si el dispositivo ya esta registrado, entonces, en la etapa 266, el cliente recopila datos del dispositivo, genera una NDF y reenvfa esa NDF y el NDI ya asignado al proveedor de servicios de red. El proveedor de servicios de red reenvfa entonces la NDF y el NDI al servidor, que almacena la NDF y comprueba la NDF con datos de NDF existentes para el estado de la NDF particular.

En la etapa 268, el servidor determina si existe el par NDF/NDI en la base de datos. Si no hay ninguna coincidencia en la base de datos, entonces el proveedor de servicios de red es notificado en la etapa 270 y la sesion de usuario finaliza. En la etapa 272, el servidor determina si el estado de NDI o NDF es malo y, si el estado de alguno de ellos es malo, el proveedor de servicios de red es notificado y la sesion de usuario finaliza en la etapa 274. Si los estados del NDI y la NDF son buenos, entonces, en la etapa 276, el proveedor de servicios de red presenta al usuario un cuadro de dialogo de inicio de sesion. Segun la invencion, el cliente y/o el sistema de validacion tambien puede presentar el inicio de sesion al usuario y realizar el proceso de inicio de sesion de usuario, ademas de los procesos de validacion. En la etapa 278, el proveedor de servicios de red determina si se proporcionan un nombre de usuario y una contrasena validos. Si se proporciona un nombre de usuario o una contrasena no validos, la sesion de usuario finaliza en la etapa 280. En la etapa 282, si se proporcionan un nombre de usuario y una contrasena validos, el proveedor de servicios de red envfa el NDI del dispositivo y el EAI al servidor. En la etapa 284, el servidor registra la asociacion de NDI y EAI en su base de datos y actualiza diversa informacion para el dispositivo, tal como la fecha/hora del ultimo inicio de sesion con exito, los inicios de sesion totales y otros datos sobre el dispositivo. En la etapa 286, el servidor comprueba el estado de NDI y EAI con los parametros del proveedor de servicios de red. En la etapa 288, basandose en las reglas del proveedor de servicios de red, el servidor envfa el estado de NDI/EAI al proveedor de servicios de red. En la etapa 290, el proveedor de servicios de red termina/continua la sesion de usuario en funcion del estado de NDI/EAI devuelto por el servidor.

A continuacion se proporcionan varios ejemplos del funcionamiento del procedimiento anterior. Como se ha descrito anteriormente, cada ordenador central establecera sus propias reglas personalizadas para cada aspecto del presente procedimiento de validacion. Debido a esto, las mismas circunstancias que dan lugar a la negacion del acceso a un usuario final en un ordenador central pueden no dar como resultado un acceso denegado en otro ordenador central. Por lo tanto, los siguientes ejemplos estan destinados simplemente a ilustrar algunas de las maneras en las que podna utilizarse la presente invencion.

El ordenador central 1 identifica un problema con una cuenta identificada por un EAI de EAI2004. Despues de cerrar la cuenta en el sistema del ordenador central 1, un administrador del ordenador central 1 inicia sesion en la NDRD y busca en la NDRD utilizando una interfaz de usuario para identificar cuatro NDI adicionales utilizados por EAI2004, y cambia el estado de cada NDI de tal forma que jamas se les permitira conectarse con el ordenador central 1. Ademas, el administrador identifica otros dos EAI que han utilizado estos NDI para conectarse al ordenador central 1. Despues de investigar las cuentas recien identificadas, se determina que son potencialmente fraudulentas y tambien se cierran. De este modo, el usuario es capaz de identificar una cuenta, sus dispositivos de red asociados y otros EAI asociados a los dispositivos de red identificados a los que se les niega el acceso al sistema. En un primer ejemplo, un usuario final intenta conectarse al ordenador central 1 desde un NDI que ha sido identificado por el ordenador central 1 como que se ha utilizado en una transaccion fraudulenta. Basandose en el estado establecido por el ordenador central 1, el usuario no podra acceder a la red. En un segundo ejemplo, un usuario final intenta conectarse al ordenador central 1 a partir de un NDI que ha sido identificado por el ordenador central 1 como que se ha utilizado de manera sospechosa. Basandose en el estado establecido por el ordenador central 1, al usuario se le permite el acceso a la red, pero por cada combinacion de nombre de usuario y contrasena validos proporcionada por el usuario final, esa cuenta se desactiva automaticamente en el sistema del ordenador central 1 y se pide al usuario que introduzca un nombre de usuario y contrasena diferentes.

En un tercer ejemplo, un usuario final intenta conectarse al ordenador central 1 a partir de un NDI que ha sido identificado por el ordenador central 2 como que se ha utilizado en una transaccion fraudulenta. Basandose en el estado de NDI establecido por el ordenador central 2 y por el hecho de que el ordenador central 1 ha identificado el ordenador central 2 como de confianza, el usuario no podra acceder a la red. Ademas, el estado de NDI para el ordenador central 1 se cambia a 'malo' y la cuenta del usuario final se cierra en el sistema del ordenador central 1. En un cuarto ejemplo, un usuario final intenta conectarse al ordenador central 1 a partir de un NDI que ha sido identificado por el ordenador central 3 como que se ha utilizado en una transaccion fraudulenta. Puesto que el ordenador central 3 no ha sido identificado como de confianza por el ordenador central 1, esta condicion se ignora y se permite al usuario que acceda a la red.

En otro ejemplo, periodicamente, un administrador del ordenador central 1 recibe un informe desde la NDRD referente a todos los NDI identificados por los ordenadores centrales de confianza como 'malos' que tienen un estado para el ordenador central 1 de 'bueno', incluyendo todos los EAI para el ordenador central 1 asociado a estos NDI. El administrador investiga estas cuentas para determinar la medida apropiada. El administrador puede entonces, por ejemplo, cambiar el estado de los NDI y los EAI a "malo" e investigar cuentas de usuario asociadas dentro de su sistema para identificar posibles cuentas fraudulentas.

En otro ejemplo, el ordenador central 1 verifica de manera proactiva informacion de cuenta para todas las cuentas identificadas a traves de la NDRD como que comparten el mismo NDI, y cuentas sospechosos son identificadas para su posterior investigacion. Por ejemplo, tres cuentas con direcciones indicadas en tres pafses diferentes que han iniciado sesion desde el mismo dispositivo de red senan identificadas como sospechosas. Como alternativa, el sistema de prevencion de fraude puede generar de forma automatica y periodica informacion a partir de la NDRD basandose en las solicitudes de un ordenador central particular. A continuacion se proporcionara un ejemplo del funcionamiento de una implementacion del sistema de deteccion de fraude segun la invencion.

Una vez que un proveedor de servicios de red particular (NSP1) ha integrado el cliente y el sistema de deteccion de fraude en su sistema, el sistema de proveedor de servicios de red puede solicitar automaticamente informacion, etc. desde el sistema de deteccion de fraude. La solicitud de informacion puede ocurrir por varias razones, tales como una nueva instalacion del consumidor, un inicio de sesion del consumidor, un intento de compra/deposito del consumidor y un intento reembolso/reintegro del consumidor. En cada situacion, el software de cliente del proveedor de servicios de red puede invocar al cliente de deteccion de fraude, que puede devolver un conjunto de informacion que el software cliente pasara a un sistema de procesamiento. En una implementacion del sistema, el sistema de procesamiento del proveedor de servicios de red puede pasar 1) un identificador unico (que sera proporcionado al proveedor de servicios de red que se registra para el servicio) que identifica de forma unica al proveedor de servicios de red particular al sistema de deteccion de fraude y permite que la NDRD almacene datos de acuerdo con el proveedor de servicios de red particular; 2) un unico "identificador de sesion" para identificar la sesion de acceso de usuario particular al proveedor de servicios de red particular; 3) un identificador de consumidor unico para el consumidor espedfico (si esta disponible, el cual debena estarlo en todos los casos excepto en una nueva instalacion del consumidor), tal como el EAI; 4) un "codigo de accion" que identifica el tipo de cuenta de usuario (ver mas abajo); y 5) la informacion que el cliente proporciono a traves de la API al servidor. El servidor puede entonces responder a traves de la API con una "respuesta de accion" que indica una medida sugerida para la cuenta particular, la informacion que desea pasar a traves del cliente, tal como el cliente ieSnare en una forma de realizacion preferida de la invencion, o ambas cosas. A continuacion se describira con mayor detalle un ejemplo de la API para el sistema de deteccion de fraude.

En una forma de realizacion preferida, la API utiliza lenguaje de marcado extensible ("XML") para pasar informacion entre el sistema de procesamiento del proveedor de servicios de red y el servidor de deteccion de fraude. La API es una manera simple pero potente de automatizar consultas comunes e interpretar sus respuestas.

Las solicitudes de la API tienen normalmente el siguiente formato:

<ieRequest>

<SnareID>NumeroConsumidorSnare</Snare ID>

<SeasionID> Numero de sesion </SessionID>

<CustomerID> Su identificador de consumidor unico (si no estuviera disponible, dejar en bianco) </CustoraerID>

< A c t io n > N u m e ro de codigo de a c c id n < /A c t iO P >

<Data> informacion de cliente ieSnare proporcionada </Data>

</ieRequest>

Las respuestas de la API tienen normalmente el siguiente formato:

<ieResponse>

<SnareID>NumeroConsumidorSnare</SnareID>

<Ses5ionID> Numero de sesion </SessionID>

<CustOroerID>Su identificador de consumidor unico (o en bianco si no aplicable) </Cus tomerID> <CoraputerID> Su identificador de ordenador unico </ComputerID>

<Ke5ponse>N cEm tfo do codigo do re sp u o sta < /R e sp o n se >

<Fieaso n>N um ero de codigo de m o tivo < /R e a so n >

<PassData> Informacion que transmitir ai cliente ieSnare (optional) </PassData> </ieResponse>

donde los numeros de codigo de accion actualmente admitidos son:

1000 - creacion de cuenta nueva

2000 - intento de inicio de sesion

3000 - intento de compra/deposito

4000 - intento de reembolso/reintegro

y los numeros de codigo de respuesta actualmente admitidos son:

0 - ACEPTAR

1 - ATRAPAR

2 - RECHAZAR

y los numeros de codigo de motivo actualmente admitidos son:

0 - reglas estandar

1 - ajustar manualmente a siempre para este usuario/ordenador

2 - asociacion con otro usuario/ordenador

3 - numero de otros usuarios que comparten ordenador

4 - numero de ordenadores que esta usando este usuario

Aunque lo anterior se ha descrito con referencia a una forma de realizacion particular de la invencion, los expertos en la tecnica apreciaran que pueden realizarse cambios en esta forma de realizacion sin apartarse de la invencion, cuyo alcance esta definido por las reivindicaciones adjuntas.

Claims (13)

REIVINDICACIONES

1. Un procedimiento implementado por ordenador (220) para detectar fraude durante una conexion de un dispositivo de red no registrado (22) a un proveedor de servicios de red (24), en el que un cliente de software (54) se ejecuta (222) en el dispositivo de red (22), comprendiendo el procedimiento:

determinar (224), mediante el cliente de software, que el dispositivo de red no esta registrado con un sistema de deteccion de fraude (26);

asignar, mediante el sistema de deteccion de fraude (26), un identificador de dispositivo de red unico al dispositivo de red no registrado (22) y enviar (226) el identificador de dispositivo de red al dispositivo de red (22);

generar (228), mediante el cliente de software (54) que se ejecuta en el dispositivo de red (22), una huella digital de dispositivo de red para el dispositivo de red (22) en funcion de una o mas caractensticas de dispositivo;

reenviar (230), mediante el cliente de software (54), la huella digital de dispositivo de red al sistema de deteccion de fraude (26);

comparar (230), mediante el sistema de deteccion de fraude (26), la huella digital de dispositivo de red con una base de datos (30) de dispositivos de red registrados; y

verificar (232, 236), mediante el sistema de deteccion de fraude (26), que la huella digital de dispositivo de red no esta duplicada con el fin de impedir un fraude.

2. El procedimiento segun la reivindicacion 1, que comprende ademas asociar (246) el identificador de dispositivo de red con informacion de cuenta de usuario final.

3. El procedimiento segun la reivindicacion 1, que comprende ademas:

verificar (202) que el identificador de dispositivo de red es valido;

verificar (206 - 208) que un estado de dispositivo de red del identificador de dispositivo de red y la huella digital de dispositivo de red es aceptable para el sistema de deteccion de fraude (26) de acuerdo con un conjunto de reglas de estado; y

verificar (210 - 212) que el estado de dispositivo de red del identificador de dispositivo de red y la huella digital de dispositivo de red es aceptable para ordenadores centrales de confianza.

4. El procedimiento segun la reivindicacion 1, en el que el dispositivo de red (22) esta conectado al proveedor de servicios de red (24), y el procedimiento comprende ademas:

verificar (214) que una pluralidad de cuentas de usuario por identificador de dispositivo de red es aceptable para el proveedor de servicios de red (24), y

verificar (216) que una pluralidad de identificadores de dispositivo de red por cuenta de usuario es aceptable para el proveedor de servicios de red (24).

5. El procedimiento segun la reivindicacion 1, en el que el dispositivo de red esta conectado al proveedor de servicios de red, y el procedimiento comprende ademas al menos una de las siguientes etapas:

proporcionar (238) un cuadro de dialogo de inicio de sesion al dispositivo de red (22); y

verificar (240, 244) que un nombre de usuario y una contrasena proporcionados por un usuario del dispositivo de red (22) son validos, proporcionando (244) el identificador de dispositivo de red y un identificador de usuario final al sistema de deteccion de fraude desde el proveedor de servicios de red (24), y

comprobar (250) un estado del identificador de dispositivo de red y el identificador de usuario final en funcion de un conjunto de reglas del proveedor de servicios de red (24).

6. El procedimiento segun la reivindicacion 1, que comprende ademas proporcionar (238) un cuadro de dialogo de inicio de sesion al dispositivo de red.

7. El procedimiento segun la reivindicacion 1, en el que el dispositivo de red (22) esta conectado al proveedor de servicios de red (24), y el procedimiento comprende ademas:

verificar (240, 244) que un nombre de usuario y una contrasena proporcionados por un usuario del dispositivo de red (22) son validos,

proporcionar (244) el identificador de dispositivo de red y un identificador de usuario final al sistema de deteccion de fraude (26) desde el proveedor de servicios de red (24), y

comprobar (250) un estado del identificador de dispositivo de red y el identificador de usuario final en funcion de un conjunto de reglas del proveedor de servicios de red (24).

8. El procedimiento segun la reivindicacion 1, en el que el sistema de deteccion de fraude (26) comprende el cliente de software (54), la base de datos (30) y un modulo de software (96),

el cliente de software (54) se descarga automaticamente en el dispositivo de red (22) y recopila automaticamente informacion de identificacion de dispositivo desde y acerca del dispositivo de red (22) para generar la huella digital de dispositivo de red,

el modulo de software (96) recibe la huella digital de dispositivo de red, almacena la huella digital de dispositivo de red en la base de datos (30) y asocia la huella digital de dispositivo de red con informacion de cuenta de usuario final proporcionada por el proveedor de servicios de red (24), y

la huella digital de dispositivo de red y la informacion de cuenta de usuario final son compartidas entre un grupo selecto de proveedores de servicios de red participates (24) para realizar un seguimiento del comportamiento sospechoso y de este modo detectar y evitar un fraude cometido usando el dispositivo de red (22).

9. El procedimiento segun la reivindicacion 8, en el que la base de datos (30) comprende ademas una pluralidad de registros (118 -122), donde cada registro comprende ademas:

un campo de ordenador central (112) que contiene un identificador de un proveedor de servicios de red particular (24),

un campo de informacion de cuenta de usuario (114) que contiene informacion del proveedor de servicios de red particular (24) que identifica un usuario particular, y

el identificador de dispositivo de red (116).

10. El procedimiento segun la reivindicacion 8, en el que el sistema de deteccion de fraude (26):

valida cada dispositivo de red (22) de manera aleatoria y periodica, o

valida cada dispositivo de red (22) despues de la conexion del dispositivo de red con el proveedor de servicios de red (24), o

valida cada dispositivo de red (22) cuando el dispositivo de red inicia sesion en el proveedor de servicios de red (24), o

valida cada dispositivo de red (22) cuando el dispositivo de red realiza una transaccion con el proveedor de servicios de red (24), o

valida cada dispositivo de red (22) cada vez que el dispositivo de red vuelve a conectarse con el proveedor de servicios de red (24).

11. El procedimiento segun la reivindicacion 8, en el que el cliente de software (54):

esta integrado en una aplicacion de software que se descarga en el dispositivo de red (22) desde el proveedor de servicios de red (24), o

es una aplicacion de software independiente que se descarga en el dispositivo de red (22) desde el proveedor de servicios de red (24), o

es un elemento de codigo que se descarga automaticamente en el dispositivo de red (22) desde el proveedor de servicios de red (24), o

se descarga en el dispositivo de red (22) cuando el dispositivo de red se conecta al proveedor de servicios de red (24).

12. El procedimiento segun la reivindicacion 8, en el que el proveedor de servicios de red (24) comprende el sistema de deteccion de fraude (26).

13. El procedimiento segun la reivindicacion 1, en el que el dispositivo de red (22) comprende un telefono celular, un asistente personal digital, un ordenador portatil, un ordenador personal o un telefono.