ES3059332T3 - Access management system and associated computer-implemented methods - Google Patents

Abstract

Se proporciona un sistema de gestión de acceso para controlar el acceso a un recurso electrónico, donde el recurso electrónico es accesible en una dirección de recurso y es proporcionado por un proveedor de servicios que tiene asociada una dirección de proveedor electrónico. El sistema comprende: un módulo de gestión de solicitudes, configurado para determinar si una solicitud de registro recibida en la dirección del proveedor electrónico es una solicitud de registro válida, donde: la solicitud de registro incluye una clave pública o datos que identifican la clave pública, asociada con un dispositivo cliente o usuario del mismo desde el cual se recibe la solicitud de registro; y un módulo de gestión de clientes autorizados configurado para agregar la clave pública del usuario, o los datos que identifican la clave pública, a una lista autorizada, si el módulo de gestión de solicitudes determina que la solicitud de registro es una solicitud de registro válida, donde: cuando una clave pública o datos que identifican la clave pública del dispositivo cliente se encuentran en la lista autorizada, el dispositivo cliente o usuario del mismo está autorizado a acceder al recurso electrónico. También se proporciona otro sistema de gestión de acceso similar y los métodos informáticos asociados implementados. (Traducción automática con Google Translate, sin valor legal)

Description

[0001] DESCRIPCIÓN

[0002] Sistema de gestión de acceso y procedimientos asociados implementados por ordenador

[0003] Campo técnico de la invención

[0004] La presente invención se refiere a un sistema de gestión de acceso para controlar el acceso a un recurso electrónico. También se proporcionan procedimientos asociados implementados por ordenador.

[0005] Antecedentes de la invención

[0006] Cuando un usuario desea registrarse en un nuevo servicio, tal como un foro de Internet, un sitio web o un nuevo producto, el proveedor del servicio exige invariablemente que el usuario registre una nueva cuenta. Generalmente, esto requiere que el usuario proporcione una dirección de correo electrónico personal (válida), un nombre de usuario adecuado y una contraseña. A menudo, el usuario también debe recibir un código de autenticación por correo electrónico. El usuario debe recordar el nombre de usuario y la contraseña para posteriores accesos. A menudo, el usuario también tiene que facilitar un número de teléfono móvil válido, los datos de su tarjeta de crédito e incluso una copia de su ID o un justificante de domicilio. Esto es engorroso para el usuario y el proveedor de servicios, y exige que el usuario exponga sus datos personales. Esto no es deseable para la normativa sobre privacidad, y también representa una responsabilidad para el proveedor de servicios.

[0007] Se han presentado alternativas a este enfoque "tradicional". Hoy en día, muchos sitios web ofrecen inicios de sesión universales, tales como los conocidos "Iniciar sesión con Facebook" o "Iniciar sesión con Google". Esto resuelve parcialmente el problema invocando a un tercero de confianza, y estos sistemas suelen estar diseñados con técnicas avanzadas de preservación de la privacidad (por ejemplo, conocimiento-cero, atestación remota). Sin embargo, los sistemas siguen dependiendo de una autoridad central para funcionar, lo que conlleva sus propias desventajas. Por ejemplo, si el portal del autenticador de Google está desconectado, un usuario no podrá acceder al servicio de esta forma aunque el servicio esté disponible. Además, este enfoque impone una dependencia sistémica de estos terceros, que se convierten en un único punto de fallo, a menudo para servicios críticos y sin una supervisión reguladora adecuada. Y lo que es más importante, estos sistemas alternativos:

[0008] ● no eliminan el requisito de un engorroso procedimiento de registro, sólo lo limitan a una única configuración inicial;

[0009] ● no eliminan la responsabilidad de estas autoridades centrales, que acaban recopilando una gran cantidad de datos personales y, por tanto, se exponen a ataques selectivos; y

[0010] ● no eliminan el riesgo para los usuarios, que siguen teniendo que compartir información personal con terceros, y sin más garantías y salvaguardas que las meramente dadas por dispositivos legales limitados y difíciles de aplicar tales como el GDPR.

[0011] Estos sistemas no abordan la cuestión de por qué el proveedor de servicios debe tener siempre el control de la identidad del usuario que solicita un servicio. Este no es el caso de la mayoría de los servicios cotidianos del mundo real: no tenemos que facilitar el ID cuando compramos comida en un supermercado; cuando compramos alcohol, sólo tenemos que facilitar el ID como prueba de la edad; el resto de nuestros datos son irrelevantes y no se almacenan. Por lo general, a un proveedor de servicios sólo le importa si un usuario paga por el servicio, y su información personal es accesoria.

[0012] La presente invención pretende resolver estos problemas.

[0013] Además, es bien sabido tanto por los usuarios como por los proveedores de servicios que el valor de un determinado servicio puede fluctuar con el tiempo como consecuencia de la oferta frente a la demanda. Sin embargo, para el proveedor de servicios no es trivial ajustar los precios en tiempo real y, al mismo tiempo, ofrecer garantías fiables de disponibilidad del servicio a los clientes que pagan. Por ejemplo, si un cliente paga por adelantado una cuota anual para acceder a un determinado recurso, pero luego el precio del recurso sube debido a las fluctuaciones del mercado, el proveedor de servicios tiene pérdidas. Del mismo modo, si el precio baja, el cliente sale perdiendo. Una posible solución que se ha adoptado para determinados servicios es la de utilizar una cuenta de prepago: el cliente deposita una determinada cantidad de fondos, y esos fondos se agotan con el tiempo a un ritmo que depende del valor de mercado del recurso. Sin embargo, a diferencia de los depósitos normales, en los sistemas de contabilidad de facturas prepagadas no hay forma de que el usuario recupere los fondos sobrantes si decide cancelar la suscripción antes de que finalice.

[0014] Ciertos aspectos de la presente invención pretenden abordar también esta cuestión.

[0015] La US2006/248600 se refiere a un procedimiento para impedir el acceso fraudulento a cuentas de Internet y se basa en una lista autorizada que comprende direcciones de red preautorizadas. La US 2019/342085 está dirigida al seguimiento de productos e información de productos durante una cadena de suministro.

[0016] Sumario de la invención

[0017] A un alto nivel, la presente invención aborda los problemas descritos anteriormente proporcionando sistemas y procedimientos en los que, cuando se valida una solicitud, la clave pública de un usuario (o la información que identifica la clave pública) se coloca en una lista de claves públicas autorizadas, en la que los usuarios cuyas claves públicas están en la lista pueden acceder a un recurso electrónico. Otros aspectos de la invención proporcionan sistemas y procedimientos que se modifican para permitir una capacidad de subasta que aborda las cuestiones asociadas con las variaciones en el coste de un recurso. Estos temas se tratan más adelante en esta aplicación.

[0018] Un sistema de gestión de acceso para controlar el acceso a un recurso electrónico, el recurso electrónico accesible en una dirección de recurso, y proporcionado por un proveedor de servicios que tiene asociada una dirección de proveedor electrónico, el sistema comprende: un módulo de gestión de solicitudes, configurado para determinar si una solicitud de registro recibida en la dirección de proveedor electrónico es una solicitud de registro válida, en la que: la solicitud de registro incluye una clave pública o datos identificativos de la clave pública, asociados a un dispositivo cliente o usuario del mismo del que se recibe la solicitud de registro; un módulo de gestión de clientes autorizados, configurado para añadir la clave pública del usuario, o datos identificativos de la clave pública, a una lista autorizada, si el módulo de gestión de solicitudes determina que la solicitud de registro es una solicitud de registro válida, en la que: cuando una clave pública o datos identificativos de la clave pública del dispositivo cliente se encuentra en la lista autorizada, el dispositivo cliente o usuario del mismo tiene permitido el acceso al recurso electrónico. En el presente documento, la clave pública mencionada en el presente documento puede ser una clave de verificación pública que se utiliza para identificar al usuario mediante la validación de una firma generada utilizando una clave de firma privada del usuario (o dispositivo cliente). En algunos casos, la clave pública a la que se hace referencia en el presente documento puede ser una clave de encriptación pública que se utiliza para encriptar una clave de sesión (de la que se hablará en detalle más adelante en esta solicitud). Este tema se trata con más detalle más adelante.

[0019] A lo largo de esta solicitud, cuando se haga referencia a un "dispositivo cliente", se entenderá que se trata de "un dispositivo cliente o un usuario del mismo". Del mismo modo, cuando nos referimos a un "ID de clave pública", debe entenderse "una clave pública o datos que identifiquen la clave pública". Estas abreviaturas se utilizan para mejorar la claridad y concisión de la siguiente divulgación.

[0020] De este modo, nunca se transmite ni almacena información personal relacionada con un usuario de un dispositivo cliente que desee acceder al recurso electrónico. Esto permite a un usuario acceder a un recurso electrónico, tal como un recurso en línea, sin riesgo de que sus datos personales sean obtenidos por agentes malintencionados.

[0021] En algunos casos, la dirección del proveedor electrónico puede ser una dirección de blockchain. En concreto, la dirección del proveedor electrónico puede ser una dirección de una cartera de blockchain, a la que se pueden transferir fondos, que está asociada con el proveedor de servicios. En el caso particularmente preferido, la transacción se realizaría utilizando una criptomoneda con características de anonimato, añadiendo aún más a la seguridad proporcionada por la invención. Un ejemplo de una criptomoneda que puede utilizarse en implementaciones de la presente invención es Monero. En algunos casos, en particular los que implican la transferencia de fondos utilizando una cadena de bloques, la solicitud de registro incluye preferiblemente una firma que se genera utilizando una clave de firma privada asociada al dispositivo cliente desde el que se recibe la solicitud de registro. Esto puede hacerse para que el módulo de gestión de solicitudes o el software de gestión del monedero blockchain pueda confirmar que el usuario que envía la solicitud de registro a la dirección del proveedor electrónico es realmente quien dice ser. En estos casos en los que la solicitud de registro adopta la forma de una transacción de blockchain, es preferible incluir en la solicitud la clave pública de verificación (es decir, la clave pública de verificación complementaria a la clave privada que se utiliza para generar la firma). Es esta clave pública de verificación (o un ID relacionado de la misma) la que puede añadirse a la lista autorizada, si se determina que la solicitud de registro es una solicitud válida. Esto es conveniente, porque significa que la identificación única se puede extraer directamente de la solicitud de registro cuando se determina que es válida, sin requerir ninguna información personal sobre el usuario.

[0022] Por lo tanto, la información personal del usuario permanece totalmente segura.

[0023] En algunos casos, la solicitud de registro puede incluir además una clave de cifrado pública asociada al dispositivo cliente. En estos casos, cuando los datos se cifran utilizando la clave de cifrado pública asociada al dispositivo cliente, pueden descifrarse utilizando una clave de descifrado privada a la que sólo tiene acceso el dispositivo cliente en cuestión.

[0024] Veamos ahora cómo se desarrolla el procedimiento de validación. En concreto, el módulo de gestión de solicitudes puede estar configurado para determinar si la solicitud de registro recibida en la dirección electrónica del proveedor cumple un criterio de validación, en el que: si el módulo de gestión de solicitudes determina que la solicitud recibida en la dirección electrónica del proveedor cumple el criterio de validación, se determina que la solicitud es una solicitud válida; y si el módulo de gestión de solicitudes determina que la solicitud recibida en la dirección electrónica del proveedor no cumple el criterio de validación, se determina que la solicitud no es una solicitud válida. En algunos casos, el sistema de gestión de solicitudes puede estar configurado para determinar si una cantidad asociada a la solicitud de registro recibida en la dirección del proveedor electrónico es mayor o igual que un valor predeterminado, en donde: si el sistema de gestión de solicitudes determina que la cantidad asociada a la solicitud de registro recibida en la dirección del proveedor electrónico es mayor o igual que el valor predeterminado, se determina que la solicitud de registro es una solicitud de registro válida; y si el sistema de gestión de solicitudes determina que la cantidad asociada a la solicitud de registro recibida en la dirección del proveedor electrónico es menor que el valor predeterminado, se determina que la solicitud de registro no es una solicitud de registro válida. En estos casos, el criterio de validación es que la cantidad asociada a la solicitud de registro sea mayor o igual que el valor predeterminado. Los sistemas según este ejemplo son útiles para permitir transacciones comerciales, por ejemplo, a través de una cadena de bloques (blockchain), como se ha comentado anteriormente.

[0026] El sistema de gestión de acceso no sólo puede estar configurado para procesar una única solicitud de registro. En concreto, el módulo de gestión de solicitudes puede estar configurado para determinar si cada solicitud de una pluralidad de solicitudes de registro recibidas en la dirección electrónica del proveedor es una solicitud de registro válida, incluyendo cada una de las solicitudes de registro un ID de clave pública respectivo asociado con el dispositivo cliente desde el que se recibe la solicitud de registro. Además, el módulo de gestión de clientes autorizados puede estar configurado para añadir el ID de clave pública respectivo del dispositivo cliente asociado con cada una de las solicitudes válidas a la lista de autorizados. En algunos casos, si no se concede la solicitud de registro de un dispositivo cliente, dicho dispositivo cliente puede ser colocado en una lista de espera (por ejemplo, en caso de que se reduzca un requisito de umbral para ser colocado en la lista autorizada). De este modo, el sistema de gestión de accesos puede atender una pluralidad de solicitudes de registro. El sistema de gestión de acceso puede estar configurado para tratar las solicitudes de una en una, o simultáneamente en una única operación paralela.

[0028] La divulgación anterior se refiere a un procedimiento de registro, mediante el cual un dispositivo cliente se registra o suscribe esencialmente a un recurso electrónico. Ejemplos de recursos son servicios de streaming tales como Netflix o Spotify, juegos online tales como World of Warcraft y Fortnite, periódicos online y cualquier otro contenido online que esté asociado a una suscripción.

[0030] A continuación, estudiamos cómo el dispositivo cliente accede realmente al recurso electrónico, utilizando un módulo de autorización. Específicamente, el sistema de gestión de acceso puede comprender además un módulo de autorización, que preferiblemente está equipado para tratar las solicitudes de acceso de los dispositivos cliente. En el presente documento, una solicitud de acceso, es una solicitud para acceder realmente al recurso electrónico, en lugar de simplemente registrarse para poder acceder al recurso. El módulo de autorización (o, alternativamente, el módulo de gestión de solicitudes) puede estar configurado para recibir una solicitud de acceso de un dispositivo cliente, la solicitud de acceso, como se ha comentado, indicando que el dispositivo cliente desea acceder al recurso electrónico almacenado en la dirección del recurso. Dicha solicitud de acceso puede incluir el ID de clave pública asociado al dispositivo cliente desde el que se recibe la solicitud de acceso. Además, la solicitud de acceso puede incluir una clave de cifrado pública asociada al dispositivo cliente. Incluir la clave de cifrado en la solicitud de acceso es ventajoso en algunas circunstancias porque minimiza la cantidad de metadatos que es necesario transmitir en la solicitud de registro inicial. La estructura de la solicitud de registro se explica con más detalle más adelante en la solicitud con referencia a la Fig.3, que debería aclarar aún más esta ventaja. En respuesta a la recepción de la solicitud de acceso del dispositivo cliente, el módulo de autorización puede estar configurado para determinar si el ID de clave pública que se incluye en la solicitud de acceso está incluido en la lista autorizada. En otras palabras, el módulo de autorización verifica si el remitente de la solicitud de acceso está realmente registrado para acceder al recurso electrónico. En aquellos casos en los que el módulo de autorización determina que el ID de clave pública está incluido en la lista autorizada, el módulo de autorización se configura posteriormente para conceder al dispositivo cliente acceso al recurso electrónico.

[0032] El acceso al recurso electrónico se concede preferiblemente proporcionando al dispositivo cliente una clave de sesión que puede utilizarse para acceder al recurso electrónico. Por supuesto, es deseable no simplemente difundir libremente la clave de sesión, en caso de que dicha señal sea interceptada. En consecuencia, el módulo de autorización puede estar configurado para conceder al dispositivo cliente acceso al recurso electrónico cifrando una clave de sesión con una clave de cifrado pública asociada al dispositivo cliente, para generar una clave de sesión cifrada, y enviando la clave de sesión cifrada al dispositivo cliente, siendo la clave de sesión cifrada descifrable por un usuario utilizando una clave de descifrado privada complementaria a la clave de cifrado pública, y siendo la clave de sesión descifrada utilizable para acceder al recurso electrónico en la dirección del recurso. Cabe señalar que la clave de cifrado puede recuperarse a partir de la solicitud de acceso o de la solicitud de registro original, en cuyo caso se almacena preferiblemente en una memoria del sistema de gestión de acceso para su posterior recuperación.

[0034] La clave de sesión puede ser de un solo uso, lo que permite al usuario acceder al recurso electrónico una sola vez. Por ejemplo, después de que la clave de sesión se utilice una vez, puede caducar. En algunos casos, para aumentar aún más la seguridad, y también para aumentar el control sobre quién puede acceder al recurso electrónico, la clave de sesión puede ser una clave de sesión rotatoria. En otras palabras, la clave de sesión puede actualizarse de forma regular (preferiblemente periódica). Específicamente, la clave de sesión puede ser una clave de sesión rotativa que cambia a una nueva clave de sesión después de un período de tiempo predeterminado; y en el que, cuando la clave de sesión cambia, el módulo de autorización está configurado para cifrar la nueva clave de sesión con la clave de cifrado de cada dispositivo cliente cuyo ID de clave pública está incluido en la lista autorizada para generar una nueva clave de sesión cifrada, y para enviar la nueva clave de sesión cifrada al o a cada dispositivo cliente.

[0036] En algunos casos, el criterio de validación que determina qué subconjunto de dispositivos cliente que han realizado solicitudes de registro se colocan en la lista autorizada puede ser variable. En concreto, el módulo de gestión de solicitudes puede estar configurado para cambiar el criterio de validación. Un cambio de este tipo puede provocar que determinados dispositivos cliente (o, en concreto, su solicitud de registro) cumplan ahora el criterio, cuando antes no lo cumplían, o que determinados dispositivos cliente cuyas solicitudes de registro cumplían antes el criterio dejen de cumplirlo. Una vez modificado el criterio de validación, el módulo de gestión de solicitudes puede estar configurado para determinar si las solicitudes de registro de los dispositivos cliente cuyos IDs de clave pública están incluidos en la lista autorizada cumplen el criterio de validación actualizado, y para identificar las que no lo cumplen, es decir, las solicitudes de registro que ya no son válidas. A continuación, el módulo de gestión de solicitudes puede estar configurado para generar instrucciones configuradas para hacer que el módulo de gestión de clientes autorizados elimine de la lista autorizada los ID de clave pública asociados a los dispositivos cliente cuyas solicitudes de registro ya no son válidas. Por otra parte, el módulo de gestión de solicitudes también puede estar configurado para determinar si la solicitud de registro de los dispositivos cliente que se han colocado en la lista de espera (véase anteriormente) cumple el criterio de validación actualizado. Para aquellos que lo hacen, el módulo de gestión de solicitudes puede estar configurado para generar instrucciones configuradas para hacer que el módulo de gestión de clientes autorizados añada los ID de clave pública asociados con esos dispositivos cliente a la lista de autorizados. De esta manera, la presente invención proporciona un sistema de gestión de acceso que es capaz de gestionar dinámicamente los dispositivos cliente que son capaces de acceder a un recurso electrónico específico, mientras que no requiere que los individuos tengan que presentar ninguna información personal en absoluto, ni registrarse con el proveedor de servicios en sí.

[0038] Un segundo aspecto de la invención proporciona un procedimiento implementado por ordenador para controlar el acceso a un recurso electrónico, el recurso electrónico accesible en una dirección de recurso, y proporcionado por un proveedor de servicios que tiene asociada una dirección de proveedor electrónico, el procedimiento comprende: determinar si una solicitud de registro recibida en la dirección de proveedor electrónico es una solicitud de registro válida, incluyendo la solicitud un ID de clave pública asociado a un dispositivo cliente desde el que se recibe la solicitud de registro; si se determina que la solicitud de registro es una solicitud de registro válida, añadir el ID de clave pública asociado al dispositivo cliente a una lista autorizada, en la que cuando un ID de clave pública del usuario está en la lista autorizada, se permite al dispositivo cliente acceder al recurso electrónico. Las características opcionales expuestas anteriormente, con referencia al primer aspecto de la invención, también se aplican igualmente bien al segundo aspecto de la invención.

[0040] Un tercer aspecto de la invención que es similar al primero aborda la situación en la que se recibe una pluralidad de solicitudes de registro y, a continuación, se toma una decisión relativa a los resultados de las solicitudes de registro "en bloque". Como demostramos, los sistemas de gestión de acceso del tercer aspecto de la invención pueden utilizarse para implementar una función de subasta. Específicamente, un tercer aspecto de la invención proporciona: un sistema de gestión de acceso para controlar el acceso a un recurso electrónico, el recurso electrónico disponible en una dirección de recurso, y proporcionado por un proveedor de servicios que tiene asociada una dirección de proveedor electrónico, el sistema que comprende: un módulo de gestión de solicitudes configurado para procesar una pluralidad de solicitudes de registro recibidas en la dirección de proveedor electrónico, cada una de las solicitudes de registro incluye un ID de clave pública respectivo asociado con el dispositivo cliente desde el que se recibe la solicitud, en el que el procesamiento de la pluralidad de solicitudes de registro comprende: seleccionar únicamente aquellas solicitudes de registro de la pluralidad de solicitudes que cumplen un criterio de validación predeterminado; y/o clasificar las solicitudes de registro basándose en datos de clasificación contenidos en la solicitud de registro, y seleccionar una o más de las solicitudes de registro basándose en un criterio de selección; un módulo de gestión de usuarios autorizados configurado para añadir los ID de clave pública asociados con los dispositivos cliente desde los que se recibieron las solicitudes de registro seleccionadas a una lista autorizada, en la que: cuando un ID de clave pública de un dispositivo cliente está en la lista autorizada, dicho dispositivo cliente puede acceder al recurso electrónico. Se observará que las características opcionales expuestas anteriormente en esta solicitud con respecto al primer aspecto de la invención se aplican igualmente bien a este tercer aspecto de la invención, a menos que sean claramente incompatibles, o cuando el contexto dicte lo contrario. En particular, el funcionamiento del módulo de gestión de solicitudes (específicamente en lo que respecta a determinar cómo se cumple un criterio de validación, y el módulo de autorización puede ser como se ha expuesto anteriormente.

[0041] En algunos casos, el módulo de gestión de solicitudes, u otro componente, puede estar configurado para cambiar el criterio de validación, el criterio de selección y/o los datos de clasificación. Un cambio de este tipo puede provocar que determinados dispositivos cliente (o, en concreto, su solicitud de registro) cumplan ahora un criterio, cuando antes no lo cumplían, o que determinados dispositivos cliente cuyas solicitudes de registro cumplían antes un criterio dejen de cumplirlo. Una vez modificado el criterio de validación, el módulo de gestión de solicitudes puede estar configurado para determinar si las solicitudes de registro de los dispositivos cliente cuyos IDs de clave pública están incluidos en la lista autorizada cumplen los criterios actualizados, y para identificar las que no los cumplen, es decir, las solicitudes de registro que ya no son válidas. A continuación, el módulo de gestión de solicitudes puede estar configurado para generar instrucciones configuradas para hacer que el módulo de gestión de clientes autorizados elimine de la lista autorizada los ID de clave pública asociados a los dispositivos cliente cuyas solicitudes de registro ya no son válidas. Por otra parte, el módulo de gestión de solicitudes también puede estar configurado para determinar si la solicitud de registro de los dispositivos cliente que se han colocado en la lista de espera (véase anteriormente) cumple el criterio actualizado. Para aquellos que lo hacen, el módulo de gestión de solicitudes puede estar configurado para generar instrucciones configuradas para hacer que el módulo de gestión de clientes autorizados añada los ID de clave pública asociados con esos dispositivos cliente a la lista de autorizados. De esta manera, la presente invención proporciona un sistema de gestión de acceso que es capaz de gestionar dinámicamente los dispositivos cliente que son capaces de acceder a un recurso electrónico específico, mientras que no requiere que los individuos tengan que presentar ninguna información personal en absoluto, ni registrarse con el proveedor de servicios en sí.

[0043] Un cuarto aspecto de la invención proporciona un procedimiento implementado por ordenador para controlar el acceso a un recurso electrónico, el recurso electrónico disponible en una dirección de recurso, y proporcionado por un proveedor de servicios que tiene asociada una dirección de proveedor electrónico, el procedimiento comprende: procesar una pluralidad de solicitudes de registro recibidas en la dirección de proveedor electrónico, cada una de las solicitudes de registro incluye un ID de clave pública respectivo asociado con el dispositivo cliente desde el que se recibe la solicitud de registro, en el que el procesamiento de la pluralidad de solicitudes de registro comprende: seleccionar únicamente aquellas solicitudes de registro de la pluralidad de solicitudes de registro que cumplen un criterio de validación predeterminado; y/o clasificar las solicitudes de registro basándose en datos de clasificación contenidos en la solicitud de registro, y seleccionar una o más de las solicitudes de registro basándose en un criterio de selección; añadir los ID de clave pública asociados con los dispositivos cliente de los que se recibieron las solicitudes de registro seleccionadas a una lista autorizada, en la que cuando un ID de clave pública de un dispositivo cliente está en la lista autorizada, dicho dispositivo cliente puede acceder al recurso electrónico. Las características opcionales expuestas anteriormente en relación con los aspectos primero y tercero de la invención se aplican igualmente bien al cuarto aspecto de la invención, excepto cuando son claramente incompatibles o el contexto dicta lo contrario.

[0045] Aspectos adicionales de la invención proporcionan: un programa informático (o producto de programa informático) que comprende instrucciones que, cuando el programa es ejecutado por un ordenador, hacen que el ordenador lleve a cabo el procedimiento del segundo y/o cuarto aspecto de la invención; un medio legible por ordenador que tiene almacenado en él el programa informático (o producto de programa informático) del aspecto anterior de la invención.

[0047] La invención incluye la combinación de los aspectos y características preferentes descritos, excepto cuando dicha combinación sea claramente inadmisible o se evite expresamente.

[0049] Breve descripción de los dibujos

[0051] A continuación se describirán las realizaciones de la presente invención con referencia a los dibujos adjuntos, en los que:

[0053] - La Fig.1 muestra un diagrama de sistema de alto nivel que incluye un sistema de gestión de accesos según un primer aspecto o tercer aspecto de la presente invención.

[0054] - La Fig. 2 es un diagrama de flujo que ilustra un proceso de registro según los aspectos primero y segundo de la invención.

[0055] - La Fig.3 es un ejemplo de solicitud de registro que puede recibir el sistema de gestión de acceso. - La Fig. 4 es un diagrama de flujo que ilustra algunas de las funciones del módulo de gestión de solicitudes.

[0056] - La Fig.5A es un diagrama de flujo que ilustra algunas de las funciones realizadas por el módulo de autorización.

[0057] - La Fig.5B es un ejemplo de una solicitud de acceso que puede ser recibida por el sistema de gestión de acceso.

[0058] - La Fig.6 es un diagrama de flujo que ilustra cómo se concede el acceso al recurso electrónico. - La Fig.7 es un diagrama de flujo que ilustra el procedimiento mediante el cual se cambia la clave de sesión y se actualizan los dispositivos cliente autorizados.

[0059] - La Fig. 8 es un diagrama de flujo que ilustra un procedimiento en el que se modifica el criterio de validación y se eliminan de la lista autorizada los IDs de clave pública de algunos dispositivos cliente. - La Fig.9 es un diagrama de flujo que ilustra un proceso de registro según los aspectos tercero y cuarto de la invención.

[0060] - La Fig.10 es un diagrama de flujo que ilustra un procedimiento en el que se modifican el criterio de validación/el criterio de selección/los datos de clasificación.

[0062] Descripción detallada de los dibujos

[0063] Aspectos y realizaciones de la presente invención se discutirán ahora con referencia a las figuras adjuntas. Otros aspectos y realizaciones serán evidentes para los expertos en la técnica.

[0065] En al menos un aspecto, la presente invención se refiere a un sistema de gestión de acceso capaz de garantizar que los usuarios puedan acceder a un recurso electrónico sin necesidad de facilitar datos personales al proveedor de servicios. La Fig.1 muestra un diagrama de sistema de alto nivel de un sistema global que ilustra la funcionalidad de la presente invención. El sistema incluye un sistema 100 de gestión de acceso, un dispositivo 200 cliente, un recurso 300 electrónico (ubicado en una dirección de recurso electrónico) y una dirección 400 de proveedor electrónico. El dispositivo 200 cliente (o, dependiendo del contexto, un usuario del dispositivo 200 cliente) puede desear acceder a un recurso 300 electrónico, que se encuentra en una dirección de recurso electrónico. Para ello, el dispositivo 200 cliente puede enviar primero una solicitud de registro al sistema 100 de gestión de acceso o a la solicitud 400 de proveedor electrónico. En función del resultado de dicha solicitud de registro, el dispositivo 200 cliente puede ser incluido en una lista 112 autorizada. A continuación, el dispositivo 200 cliente puede enviar una solicitud de acceso al sistema 100 de gestión de acceso. Estos procedimientos se explican con más detalle a lo largo de esta solicitud. El sistema 100 de gestión de acceso, el dispositivo 200 cliente, el recurso 300 electrónico y la dirección 400 electrónica del proveedor pueden estar conectados a través de una red 500. La red 500 puede ser una red cableada, pero en los casos preferidos, la red 500 es una red inalámbrica, tal como una red Wi-Fi, una red celular, o más preferiblemente, Internet. Debe tenerse en cuenta que aunque la Fig.1 muestra todos los componentes conectados a través de la red 500, en algunos casos, pueden estar conectados por más de una red (por ejemplo, cada par de componentes puede estar conectado a través de una red separada).

[0067] Antes de hablar de su funcionamiento, describiremos con más detalle la estructura del sistema 100 de gestión de accesos. El sistema 100 de gestión de acceso puede incluir un procesador 102 y una memoria 104. El procesador 102 puede incluir un módulo 105 de gestión de solicitudes, un módulo de gestión de clientes autorizados 106 y un módulo de autorización 108. La memoria 104 puede incluir una lista 110 de autorizados, y datos 112 de registro.

[0069] La Fig.2 es un diagrama de flujo que ilustra, a alto nivel, un proceso de registro según el primer aspecto de la invención. En un primer paso S20, puede recibirse una solicitud 30 de registro del dispositivo 200 cliente en la dirección 300 electrónica del proveedor. En la Fig. 3 se muestra un ejemplo de solicitud 10 de registro. La solicitud 10 de registro puede incluir una carga útil 12, una firma 14 y metadatos 16. Los metadatos 16 pueden incluir una dirección 18 de cliente, que indica al módulo 105 de gestión de solicitudes dónde deben enviarse, por ejemplo, las notificaciones y otros datos destinados a un dispositivo 200 cliente determinado. Los metadatos pueden incluir además un ID relativo a la clave 20 pública. Se trata de una característica importante, ya que es el ID relativo a la clave 20 pública el que se almacena en la lista 110 autorizada con el fin de confirmar que el dispositivo 200 cliente asociado a dicho ID está autorizado a acceder al recurso 300 electrónico. En casos alternativos, en lugar de que los metadatos 16 de la solicitud 10 de registro incluyan un ID relacionado con la clave pública del dispositivo 200 cliente, pueden incluir la propia clave pública - ambos enfoques son válidos, y a lo largo de esta aplicación, cuando nos refiramos a un ID relacionado con la clave 20 pública, un ID de clave pública, o similar, debe entenderse que el término es intercambiable con sólo la clave pública, a menos que el contexto dicte lo contrario. Por último, los metadatos 16 pueden incluir una clave 22 de cifrado. En los casos en que la solicitud 10 de registro incluya una clave 22 de cifrado, ésta se almacena preferiblemente, por ejemplo, por el módulo de solicitud 105 de registro en los datos 112 de registro de la memoria 104 del sistema 100 de gestión de acceso en asociación con el ID relacionado con la clave 20 pública.

[0071] La firma 14 se genera preferiblemente utilizando una clave de firma privada asociada al dispositivo 200 cliente o a un usuario del mismo. Esto significa que la firma puede verificarse mediante una clave pública de verificación que se envía, por ejemplo, a la dirección 400 electrónica del proveedor o, por ejemplo, al módulo 105 de gestión de solicitudes del sistema 100 de gestión de acceso, en la solicitud 10 de registro. La naturaleza de la carga útil 12 se discute en breve, con referencia a la Fig.4.

[0073] Al recibir la solicitud de registro, el módulo 105 de gestión de solicitudes puede determinar si la solicitud 10 de registro es una solicitud válida, en el paso de decisión S22. En el caso de que la solicitud 10 de registro sea válida, el módulo de gestión de clientes autorizados 106 puede entonces añadir la clave 20 pública asociada al dispositivo 200 cliente desde el que se recibió la solicitud 10 de registro a la lista 110 de autorizados. La lista 110 autorizada incluye preferiblemente una lista de dispositivos 200 cliente a los que se permite acceder al recurso 300 electrónico basándose en los resultados de la determinación del paso S22. Si en el paso S22 se determina que la solicitud 10 de registro no es una solicitud válida, el dispositivo 200 cliente del que se recibió la solicitud 10 de registro puede no ser registrado, es decir, la ID de clave pública no se añadirá a la lista 110 autorizada. Entonces, en ambos casos (es decir, registrado y no registrado), el usuario puede ser notificado del resultado en el paso S26, en la dirección del cliente 18 en los metadatos 16 de la solicitud 10 de registro.

[0074] La Fig.4 muestra con más detalle el procedimiento realizado por el módulo 105 de gestión de solicitudes. En el paso S40, puede recibirse la solicitud 10 de registro, por ejemplo, en la dirección 400 electrónica del proveedor o en el propio módulo 105 de gestión de solicitudes. A continuación, en el paso S42, el módulo 105 de gestión de solicitudes puede determinar si la carga útil 12 de la solicitud 10 de registro cumple algún criterio de validación predeterminado. En algunas implementaciones de esta invención, la dirección del proveedor electrónico 400 puede ser la dirección de un monedero blockchain asociado con el proveedor de servicios electrónicos. En tales casos, la carga útil 12 puede indicar la cantidad de fondos a transferir desde el dispositivo 200 cliente al monedero blockchain del proveedor de servicios. En tales casos, el criterio de validación puede incluir un coste asociado al acceso al recurso 300 electrónico, y el módulo 105 de gestión de solicitudes puede estar configurado para comparar la cantidad de fondos indicada en la carga útil 12 con el coste. Si se determina que la carga útil 12 no coincide con el criterio de validación, el dispositivo 200 cliente desde el que se recibió la solicitud 10 de registro puede no ser registrado en el sistema, y puede ser notificado en consecuencia en el paso S43. A la inversa, si se determina que la carga útil 12 cumple el criterio de validación, entonces el módulo de gestión de peticiones 105 puede, en el paso S44, generar instrucciones que hagan que el módulo de cliente autorizado 106 añada el ID de clave 20 pública de la petición de registro a la lista 110 autorizada de la memoria 104, y transmita las instrucciones en consecuencia en el paso S46. El módulo 105 de gestión de solicitudes puede entonces notificar al usuario en consecuencia. En algunos casos, el módulo 105 de gestión de solicitudes, o el procesador 102 del módulo de gestión de acceso 100 de forma más general, puede incluir un módulo de notificación (no mostrado) que puede estar configurado para generar y transmitir notificaciones.

[0075] Los procedimientos descritos anteriormente se refieren al registro inicial de un dispositivo 200 cliente con el proveedor de servicios electrónicos a través del módulo de gestión de acceso 100. Una vez registrado un dispositivo 200 cliente, el usuario del mismo (o, para el caso, un usuario que no esté registrado) puede entonces desear acceder al recurso 300 electrónico. Para ello, se genera una solicitud de acceso y se envía al sistema 100 de gestión de acceso. La Fig. 5A muestra un ejemplo de un procedimiento que puede realizarse para procesar la solicitud de acceso. En el paso S50, el sistema 100 de gestión de acceso, preferiblemente el módulo de autorización 108 del mismo, puede recibir la solicitud de acceso 20. La Fig. 5B muestra un ejemplo de solicitud de acceso 50, que puede incluir datos 52 que identifican el recurso 300 electrónico, un ID de clave 20 pública asociado al dispositivo 200 cliente y una clave 22 de cifrado asociada al dispositivo 200 cliente. En los casos en que la clave 22 de cifrado se incluye en la solicitud de registro original 10 del dispositivo 200 cliente, no es necesario que la solicitud de acceso 50 incluya la clave 22 de cifrado. Cabe señalar que la Fig.5B no es exhaustiva: la solicitud de acceso 50 también puede incluir otros datos. En el paso S52 de la Fig.5A, el módulo de autorización 108 puede determinar si la ID de clave pública incluida en la solicitud de acceso 50 está presente en la lista 110 autorizada. Si no es así, se impide el acceso del dispositivo 200 cliente al recurso 300 electrónico en el paso S54, y en el paso S56 se envía una notificación en consecuencia. Si la clave pública ID 20 está incluida en la lista 110 autorizada, entonces el módulo de autorización 108 concede al dispositivo 200 cliente acceso al recurso electrónico en el paso S58, y se lo notifica en consecuencia en el paso S59.

[0077] Ahora consideraremos cómo el dispositivo 200 cliente puede ser autorizado a acceder al recurso 300 electrónico, y cómo se concede realmente el acceso. En la Fig. 6 se muestra un procedimiento ejemplar. Esencialmente, cuando un dispositivo 200 cliente obtiene acceso al recurso 300 electrónico, se le proporciona una clave de sesión que le da acceso al mismo. En el paso S60, se identifica la clave 22 de cifrado asociada al dispositivo 200 cliente en cuestión. Por ejemplo, si la clave 22 de cifrado se entregó inicialmente en la solicitud 10 de registro, y se almacenó en los datos de la solicitud de registro 112, entonces el módulo de autorización 108 puede realizar una búsqueda en los datos de la solicitud de registro 112 para identificar la clave 22 de cifrado asociada con la ID de clave 20 pública que estaba presente en la solicitud de acceso 50. Alternativamente, en un caso más sencillo, si la clave 22 de cifrado formaba parte de la solicitud de acceso 50, entonces la clave 22 de cifrado puede simplemente recuperarse de la misma. Una vez identificada la clave 22 de cifrado, el módulo de autorización 108 (u opcionalmente un módulo de cifrado, no mostrado, del mismo) puede entonces cifrar la clave de sesión utilizando la clave 22 de cifrado en el paso S62. Cabe señalar, para completar, que los datos cifrados mediante la clave 22 de cifrado pueden descifrarse mediante una clave de descifrado privada que sólo posee el dispositivo 200 cliente, a fin de garantizar que sólo dicho dispositivo 200 cliente pueda acceder a la clave de sesión cifrada mediante su propia clave 22 de cifrado (pública). Una vez que se ha cifrado la clave de sesión, la clave de sesión cifrada puede entonces, en el paso S64, transmitirse al dispositivo 200 cliente, en cuyo momento el dispositivo 200 cliente puede descifrar la clave de sesión, y utilizar la clave de sesión para acceder al recurso 300 electrónico. De este modo, se concede acceso al recurso 300 electrónico. En algunos casos, como ya se ha comentado, en lugar de generar claves de sesión cifradas utilizando la respectiva clave 22 de cifrado de cada dispositivo 200 cliente, puede utilizarse un esquema de cifrado de difusión.

[0079] Para mayor seguridad, la clave de sesión puede cambiar de forma regular, preferiblemente periódica. La clave de sesión puede cambiar cada minuto, cada hora o varias veces al día. Puede cambiar a diario, puede cambiar cada 2, 3, 4, 5 o 6 días. La clave de sesión puede cambiar semanal o mensualmente. La frecuencia con la que cambia la clave de sesión se basa preferiblemente en la aplicación prevista. Por supuesto, si la clave de sesión cambia, es necesario mantener actualizados también los dispositivos 200 cliente registrados, para garantizar que siguen pudiendo acceder al recurso electrónico. Este procedimiento se ilustra en la Fig.7. En un primer paso, el módulo de autorización 108 puede recibir la clave de sesión actualizada. Alternativamente, el módulo de autorización 108 puede generar por sí mismo la clave de sesión actualizada. El procedimiento por el que se genera la clave de sesión es preferiblemente aleatorio. A continuación, en el paso S72, el módulo de autorización 108 puede identificar todos los dispositivos 200 cliente autorizados, es decir, aquellos dispositivos 200 cliente cuya ID de clave 20 pública está presente en la lista 110 de autorizados. Una vez que estos dispositivos cliente autorizados 200 han sido identificados, el módulo de autorización 108, para cada dispositivo cliente autorizado 200, puede encriptar la clave de sesión actualizada en el paso S74, utilizando la clave de encriptación 22 del dispositivo cliente (ésta puede obtenerse como se describe en el párrafo anterior).

[0081] Por último, en el paso S76, la clave de sesión cifrada actualizada puede transmitirse al dispositivo cliente autorizado 200. En algunos casos, como ya se ha comentado, en lugar de generar claves de sesión cifradas actualizadas utilizando la respectiva clave 22 de cifrado de cada dispositivo cliente autorizado 200, se puede utilizar un esquema de cifrado de difusión.

[0083] En algunos casos, puede ser conveniente modificar el criterio de validación. Por ejemplo, en un entorno comercial, esto puede hacerse para modificar el precio de acceso al recurso electrónico. La presente invención proporciona un medio para hacerlo. La Fig.8 muestra un esquema de un procedimiento mediante el cual la lista 110 autorizada puede actualizarse en función de un cambio en un criterio de validación. En un primer paso S80, el criterio de validación puede ser actualizado, por ejemplo, por el módulo 105 de gestión de solicitudes. Esto puede corresponder a un aumento del precio del recurso 300 electrónico proporcionado. A continuación, en el paso S82, se identifican los dispositivos 200 cliente cuyo contenido de las solicitudes 10 de registro ya no cumple los criterios de validación. Esto puede lograrse, por ejemplo, mediante la reevaluación por parte del módulo de gestión de inscripciones 105 de todas las solicitudes de inscripción 10 (preferiblemente las cargas útiles 12 de las mismas), que pueden almacenarse, por ejemplo, en los datos de solicitud de inscripción 112 en asociación con el ID de clave pública. Una vez identificados los IDs de clave 20 pública de los dispositivos 200 cliente que ya no están autorizados, el módulo de gestión de clientes autorizados 106 puede entonces eliminar estos IDs de clave 20 pública de la lista 110 de autorizados. Entonces, ¿cómo pierden realmente estos dispositivos 200 cliente el acceso al recurso 300 electrónico? En algunos casos, por ejemplo, el dispositivo 200 cliente puede enviar una solicitud de acceso 50, que será denegada por el módulo de autorización 108 porque el ID de clave pública ya no está en la lista autorizada. Alternativamente, en los casos en que la clave de sesión cambie, no se enviará al dispositivo 200 cliente una clave de sesión actualizada porque sólo se envían a los dispositivos 200 cliente de la lista 110 autorizada.

[0085] La divulgación anterior se refiere al primer aspecto de la invención, que se centra en los aspectos de registro y autorización del sistema 100 de gestión de acceso. La última característica de la invención, descrita en el párrafo anterior, se refiere al cambio de un criterio de validación y, al hacerlo, al cambio automático de los dispositivos 200 cliente que pueden acceder a un recurso 300 electrónico. Otro aspecto de la invención prevé un procedimiento en el que, en lugar de decidirse una por una, un sistema 100 de gestión de acceso puede recibir una pluralidad de solicitudes 10 de registro, pero sólo puede aceptar un subconjunto de ellas. La presente invención permite así una especie de puja, o funcionalidad de subasta. Cabe destacar aquí que la invención reside en la novedosa implementación de un procedimiento de subasta, más que en el propio procedimiento de subasta.

[0087] La Fig. 9 muestra un diagrama de flujo que ilustra un procedimiento de registro en el que se selecciona un subconjunto de dispositivos 200 cliente a partir de una pluralidad de solicitudes 10 de registro. En un primer paso, S90 se recibe una pluralidad de solicitudes 10 de registro en la dirección 400 electrónica del proveedor. Estas solicitudes no se reciben necesariamente al mismo tiempo, es decir, en una sola transmisión. Más bien, la pluralidad de solicitudes 10 de registro puede comprender todas las solicitudes 10 de registro que se reciban antes de un plazo predeterminado, o puede incluir un número predeterminado de solicitudes 10 de registro. Hay dos enfoques diferentes que pueden adoptarse en estos casos en los que una pluralidad de solicitudes 10 de registro se procesan simultáneamente. El primer enfoque se muestra en la rama izquierda del diagrama de flujo de la Fig.9. Aquí, en el paso S91, las peticiones de registro 10 se clasifican basándose en algunos datos de clasificación contenidos en la petición de registro 10, por ejemplo, por el módulo de gestión de peticiones 105, o un módulo de clasificación (no mostrado) del mismo. Los datos de clasificación pueden ser un valor incluido en la solicitud 10 de registro, por ejemplo, la carga útil 12 de la misma. Alternativamente, los datos podrían representar una hora, una fecha o una ubicación - no es importante para los propósitos de la invención. En algunos casos, después de que la clasificación haya tenido lugar en el paso S91, toda la información aparte de los IDs de clave 20 pública puede ser descartada. Alternativamente, los datos (por ejemplo, uno o más de la carga útil 12, la dirección del cliente 18, el ID de clave 20 pública y la clave 22 de cifrado) pueden almacenarse en los datos 112 de solicitud de registro. En el paso S92, un subconjunto de las solicitudes 10 de registro (o IDs de clave 20 pública de las mismas) son seleccionadas en base a algún criterio de selección, por el módulo 105 de gestión de solicitudes, o un módulo de selección (no mostrado) del mismo. Este criterio de selección puede especificar cuántas de las solicitudes 10 seleccionar (por ejemplo, las 10 principales, las 100 principales), un valor mínimo o máximo de un elemento de datos en una carga útil (por ejemplo, todas las solicitudes 10 de registro con un valor de carga útil de 10 o más, o un valor de carga útil no superior a 100). Sea cual sea el criterio de selección, el resultado es el mismo: un subconjunto de solicitudes 10 de registro que han sido clasificadas y cumplen algún criterio de selección. En un caso alternativo, aunque similar, que se muestra en la rama derecha de la Fig. 9, el módulo 105 de gestión de solicitudes puede identificar un subconjunto de las solicitudes 10 de registro recibidas que cumplan un criterio de validación. Este procedimiento puede realizarse de la misma manera que en el paso S42 de la Fig.4, explicado anteriormente en esta solicitud. En un ejemplo no limitativo, la dirección 400 electrónica del proveedor puede ser un monedero blockchain. En ese caso, este procedimiento puede utilizarse únicamente para seleccionar el subconjunto de dispositivos 200 cliente que hayan presentado una oferta suficientemente alta, o que hayan presentado una de las N mejores ofertas. Una vez seleccionado el subconjunto adecuado en el paso S92 o en el paso S93, en el paso S94, el módulo de gestión de clientes autorizados 106 añade a la lista 112 autorizada los ID de clave 20 pública asociados con los dispositivos 200 cliente seleccionados (es decir, los que se han seleccionado en los pasos anteriores). Los dispositivos 200 cliente pueden entonces ser notificados en el paso S95. En el contexto de los usuarios que pujan por un servicio, es factible que aparezcan licitadores posteriores y presenten una oferta más alta que, por ejemplo, la oferta más baja que ya se ha obtenido. Como resultado, el licitador más tardío debería poder adelantar en la clasificación al licitador registrado más bajo. En consecuencia, el procedimiento mostrado en la Fig.9 puede repetirse periódicamente, con el fin de garantizar que la lista 110 autorizada de ID de clave 20 pública refleja con precisión el subconjunto de licitadores que realizaron las ofertas más altas (u ofertas que superan un valor umbral). Las repeticiones del procedimiento se basan preferiblemente en las nuevas solicitudes 10 de registro que se reciban, así como en los datos 112 de solicitud de registro almacenados en la memoria 104 del módulo de gestión de acceso 100.

[0088] En estos casos, una vez generada o actualizada la lista 110 autorizada, el procedimiento mediante el cual los dispositivos 200 cliente solicitan acceso al recurso 300 electrónico puede ser el mismo que el mostrado en las Figs.5 y 6 La clave de sesión también puede actualizarse del mismo modo que se muestra en la Fig.7. Además de actualizar la lista 110 autorizada en función de las nuevas solicitudes de registro entrantes 10, el criterio de validación o los criterios de selección también pueden actualizarse, cambiando esencialmente el umbral en función del cual los dispositivos 200 cliente están autorizados. En algunos casos, durante el procedimiento de registro de la Fig. 9, algunos de los dispositivos 200 cliente no entrarán en la lista 110 de autorizados. En los casos preferidos, estas solicitudes 10 de registro infructuosas se colocarán en una lista de espera, que puede almacenarse en la memoria 104 del sistema 100 de gestión de acceso. La lista de espera puede adoptar una forma similar a la de los datos 112 de solicitud de registro, salvo que sólo contiene datos relativos a los dispositivos 200 cliente cuyos IDs de clave 20 pública asociados no están presentes en la lista 110 autorizada. En el paso S100 de la Fig.10, uno o más de los criterios de validación, los criterios de selección y/o los datos de clasificación son actualizados, por ejemplo, por el módulo 105 de gestión de solicitudes. En el presente documento, cuando nos referimos a la actualización de los "datos de clasificación", podemos referirnos a los datos contenidos en la solicitud de registro que se tienen en cuenta durante la clasificación (por ejemplo, el cambio a la clasificación por hora/fecha de una solicitud, en lugar de por ubicación geográfica). Existen dos escenarios: en algunos casos, las solicitudes 10 de registro previamente rechazadas pueden cumplir ahora los criterios, y en otros casos, las solicitudes 10 de registro previamente permitidas pueden dejar de cumplir los criterios. Estos se consideran en ramas separadas de la Fig.10. En el paso S102, el módulo de solicitud 105 de registro (u otro componente) puede determinar si hay algún dispositivo 200 cliente en la lista de espera que cumpla los criterios actualizados. En los casos en que los criterios se refieran, por ejemplo, a un N superior de solicitudes 10 de registro, entonces puede ser necesario considerar los dispositivos 200 cliente tanto en la lista 110 autorizada y/o los datos 112 de solicitud de registro como en la lista de espera, porque si un nuevo dispositivo 200 cliente debe cumplir los criterios, entonces se deduce que uno de los dispositivos 200 cliente de la lista 110 autorizada ya no cumple los criterios. A continuación, para todos los dispositivos 200 cliente cuyas solicitudes 10 de registro ahora se considera que cumplen los criterios actualizados, sus respectivos ID de clave 20 pública pueden añadirse a la lista 110 autorizada en el paso S104. Por otra parte, en el paso S106, el módulo de registro 105 (u otro componente) puede determinar si hay dispositivos 200 cliente (o ID de clave 20 pública correspondientes a dispositivos 200 cliente) que ya no cumplen los criterios actualizados. Una vez más, en los casos en que los criterios se refieran, por ejemplo, a un top N de solicitudes 10 de registro, puede ser necesario tener en cuenta tanto la lista 110 autorizada como la lista de espera. A continuación, en el paso S108, esos dispositivos 200 cliente determinados, más específicamente los ID de clave pública asociados a los mismos, pueden ser eliminados de la lista 110 autorizada. Posteriormente, en el paso S110, se informa de los cambios a todos los dispositivos 200 cliente afectados.

[0089] Aunque la invención se ha descrito en conjunción con las realizaciones ejemplares descritas anteriormente, muchas modificaciones y variaciones serán evidentes para los expertos en la técnica cuando se les dé esta divulgación. En consecuencia, las realizaciones ejemplares de la invención expuestas anteriormente se consideran ilustrativas y no limitativas.

[0090] Para evitar cualquier duda, cualquiera de las explicaciones teóricas que se proporcionan en el presente documento tienen por objeto mejorar la comprensión del lector. Los inventores no desean ceñirse a ninguna de estas explicaciones teóricas.

[0091] Los encabezamientos de sección utilizados en el presente documento tienen una finalidad meramente organizativa y no deben interpretarse como una limitación de la materia descrita.

[0092] A lo largo de esta memoria descriptiva, incluyendo las reivindicaciones que siguen, a menos que el contexto requiera lo contrario, la palabra "comprende" e "incluye", y variaciones tales como "que comprende", "comprendiendo", e "incluyendo" se entenderán que implican la inclusión de un número entero o paso o grupo de números enteros o pasos, pero no la exclusión de cualquier otro número entero o paso o grupo de números enteros o pasos.

[0093] Cabe señalar que, tal como se utilizan en la memoria descriptiva y en las reivindicaciones adjuntas, las formas singulares "un", "uno" y "el/la" incluyen referentes plurales a menos que el contexto indique claramente lo contrario. Los intervalos pueden expresarse en el presente documento como desde "aproximadamente" un valor particular, y/o hasta "aproximadamente" otro valor particular. Cuando se expresa un intervalo de este tipo, otra realización incluye desde un valor particular y/o hasta otro valor particular. De forma similar, cuando los valores se expresan como aproximaciones, mediante el uso del antecedente "aproximadamente", se entenderá que el valor concreto constituye otra realización. El término "aproximadamente" en relación con un valor numérico es opcional y significa, por ejemplo, /- 10%.

Claims (15)

1. REIVINDICACIONES

1. Un sistema (100) de gestión de acceso para controlar el acceso a un recurso (300) electrónico, el recurso (300) electrónico accesible en una dirección de recurso, y proporcionado por un proveedor de servicios que tiene asociada una dirección (400) de proveedor electrónico, el sistema (100) de gestión de acceso que comprende:

un módulo (105) de gestión de solicitudes, configurado para determinar si una solicitud (10) de registro recibida en la dirección (400) electrónica del proveedor es una solicitud de registro válida, en la que: la solicitud (10) de registro incluye una clave (20) pública o datos de identificación de la clave pública, asociados a un dispositivo (200) cliente o usuario del mismo desde el que se recibe la solicitud (10) de registro; y

un módulo de gestión de clientes (106) autorizados configurado para añadir la clave pública del usuario, o los datos (20) que identifican la clave pública, a una lista (110) autorizada, si el módulo (105) de gestión de solicitudes determina que la solicitud (10) de registro es una solicitud de registro válida, en la que: cuando la clave pública o los datos que identifican la clave pública del dispositivo (200) cliente se encuentran en la lista (110) autorizada, se permite al dispositivo (200) cliente o a su usuario acceder al recurso (300) electrónico.

2. El sistema (100) de gestión de acceso según la reivindicación 1, en el que: el módulo (105) de gestión de solicitudes está configurado para determinar si la solicitud (10) de registro recibida en la dirección (400) electrónica del proveedor cumple un criterio de validación, en el que:

si el módulo (105) de gestión de solicitudes determina que la solicitud (10) de registro recibida en la dirección (400) electrónica del proveedor cumple el criterio de validación, se determina que la solicitud (10) de registro es una solicitud de registro válida; y

si el módulo (105) de gestión de solicitudes determina que la solicitud (10) de registro recibida en la dirección (400) electrónica del proveedor no cumple el criterio de validación, se determina que la solicitud (10) de registro no es una solicitud de registro válida.

3. El sistema (100) de gestión de acceso según la reivindicación 1 o la reivindicación 2, en el que:

el módulo (105) de gestión de solicitudes está configurado para determinar si cada solicitud (10) de registro de una pluralidad de solicitudes (10) de registro recibidas en la dirección (400) electrónica del proveedor es una solicitud de registro válida, incluyendo cada una de las solicitudes (10) de registro un ID de clave (20) pública respectivo asociado con el dispositivo (200) cliente desde el que se recibe la solicitud (10) de registro; y

el módulo de gestión de clientes (106) autorizados está configurado para añadir a la lista (110) de autorizados el respectivo ID de clave (20) pública del dispositivo (200) cliente asociado a cada una de las solicitudes de registro válidas.

4. El sistema (100) de gestión de acceso según cualquiera de las reivindicaciones 1 a 3, en el que:

el sistema (100) de gestión de acceso comprende además un módulo (108) de autorización; y el módulo (105) de gestión de solicitudes o el módulo (108) de autorización está configurado para recibir una solicitud (50) de acceso de un dispositivo (200) cliente, indicando la solicitud (50) de acceso que el dispositivo cliente desea acceder al recurso (300) electrónico almacenado en la dirección del recurso e incluyendo el ID de clave (20) pública asociado al dispositivo (200) cliente del que se recibe la solicitud (50) de acceso;

el módulo (108) de autorización está configurado para determinar si el ID de clave (20) pública que se incluye en la solicitud (50) de acceso está incluido en la lista (110) autorizada; y

si el módulo (108) de autorización determina que el ID de clave (20) pública está incluido en la lista (110) autorizada, el módulo (108) de autorización está configurado además para conceder al dispositivo (200) cliente asociado acceso al recurso (300) electrónico.

5. El sistema (100) de gestión de acceso según la reivindicación 4, en el que: el módulo (108) de autorización está configurado para conceder al dispositivo (200) cliente acceso al recurso (300) electrónico cifrando una clave de sesión con una clave (22) de cifrado pública asociada al dispositivo cliente, para generar una clave de sesión cifrada, y enviando la clave de sesión cifrada al dispositivo (200) cliente, la clave de sesión cifrada puede ser descifrada por un dispositivo (200) cliente utilizando una clave de descifrado privada complementaria a la clave (22) de cifrado pública, y la clave de sesión descifrada puede utilizarse para acceder al recurso (300) electrónico en la dirección del recurso, en el que: la clave pública de cifrado (22) se obtiene a partir de la solicitud (50) de acceso o de la solicitud (10) de registro recibida del dispositivo (200) cliente.

6. El sistema (100) de gestión de acceso según la reivindicación 5, en el que:

el dispositivo (200) cliente sólo puede utilizar la clave de sesión una vez para acceder al recurso (300) electrónico; o bien

la clave de sesión es una clave de sesión rotatoria que cambia a una nueva clave de sesión tras un periodo de tiempo predeterminado; y

cuando cambia la clave de sesión, el módulo (108) de autorización está configurado para cifrar la nueva clave de sesión con la clave (22) de cifrado de cada dispositivo (200) cliente cuyo ID de clave (20) pública está incluido en la lista (110) autorizada para generar una nueva clave de sesión cifrada, y para enviar la nueva clave de sesión cifrada a cada dispositivo (200) cliente.

7. Un sistema (100) de gestión de acceso para controlar el acceso a un recurso (300) electrónico, el recurso (300) electrónico disponible en una dirección de recurso, y proporcionado por un proveedor de servicios que tiene asociada una dirección (400) de proveedor electrónico, el sistema (100) de gestión de acceso que comprende:

un módulo (105) de gestión de solicitudes configurado para procesar una pluralidad de solicitudes (10) de registro recibidas en la dirección (400) electrónica del proveedor, incluyendo cada una de las solicitudes (10) de registro un ID de clave (20) pública respectivo asociado con el dispositivo (200) cliente desde el que se recibe la solicitud (10) de registro, en el que el procesamiento de la pluralidad de solicitudes de registro comprende:

seleccionar únicamente aquellas solicitudes (10) de registro de la pluralidad de solicitudes (10) de registro que cumplan un criterio de validación predeterminado; y/o clasificar las solicitudes (10) de registro basándose en los datos de clasificación contenidos en la solicitud (10) de registro , y seleccionar una o más de las solicitudes (10) de registro basándose en un criterio de selección; y

un módulo (106) de gestión de usuarios autorizados configurado para añadir los IDs de clave (20) pública asociados a los dispositivos (200) cliente desde los que se recibieron las solicitudes (10) de registro seleccionadas a una lista (110) autorizada,

en el que: cuando un ID de clave (20) pública de un dispositivo (200) cliente está en la lista (110) autorizada, ese dispositivo (200) cliente puede acceder al recurso (300) electrónico.

8. El sistema (100) de gestión de acceso según la reivindicación 7, en el que:

el sistema (100) de gestión de acceso comprende además un módulo (108) de autorización; y el módulo (105) de gestión de solicitudes o el módulo (108) de autorización está configurado para recibir una pluralidad de solicitudes (50) de acceso de una pluralidad respectiva de dispositivos (200) cliente, indicando cada solicitud (50) de acceso que un dispositivo (200) cliente respectivo desearía acceder al recurso (300) electrónico almacenado en la dirección del recurso e incluyendo el ID de clave (20) pública asociado a dicho dispositivo (200) cliente;

el módulo (108) de autorización está configurado para determinar si un ID de clave (20) pública que se incluye en cada solicitud de acceso respectiva (50) está incluido en la lista (110) autorizada; y si el módulo (108) de autorización determina que un ID de clave (20) pública respectivo está incluido en la lista (110) autorizada, el módulo (108) de autorización está configurado además para conceder al dispositivo (200) cliente asociado acceso al recurso (300) electrónico.

9. El sistema (100) de gestión de acceso según la reivindicación 8, en el que: el módulo (108) de autorización está configurado para conceder a cada dispositivo (200) cliente acceso al recurso (300) electrónico cifrando una clave de sesión con una clave (22) de cifrado pública asociada al respectivo dispositivo (200) cliente, para generar una clave de sesión cifrada, y enviando la clave de sesión cifrada al dispositivo (200) cliente, la clave de sesión cifrada puede ser descifrada por el respectivo dispositivo (200) cliente utilizando una clave de descifrado privada complementaria a la clave (22) de cifrado pública, y la clave de sesión descifrada puede utilizarse para acceder al recurso (300) electrónico en la dirección del recurso, en la que: las claves (20) de cifrado públicas se recuperan a partir de la solicitud (50) de acceso o de la solicitud (10) de registro recibidas del respectivo dispositivo (200) cliente.

10. El sistema (100) de gestión de acceso según cualquiera de las reivindicaciones 7 a 9, en el que: el módulo de gestión de clientes (106) autorizados está configurado para colocar en una lista de espera los IDs de clave (20) pública de los dispositivos (200) cliente cuyos IDs de clave (20) pública no se han añadido a la lista (110) autorizada.

11. El sistema de gestión de acceso según la reivindicación 10, en el que:

el módulo (105) de gestión de solicitudes está configurado para modificar el criterio de validación, los datos de clasificación y/o el criterio de selección;

el módulo (105) de gestión de solicitudes está configurado para determinar si las solicitudes (10) de registro de los dispositivos (200) cliente cuyos IDs de clave (20) pública están incluidos en la lista (110) autorizada cumplen los criterios actualizados, y para identificar aquellas que no los cumplen; y el módulo (105) de gestión de solicitudes está configurado para generar instrucciones configuradas para hacer que el módulo de gestión de clientes (106) autorizados elimine de la lista (110) autorizada los IDs de clave (20) pública asociados con los dispositivos (200) cliente cuyas solicitudes (10) de registro ya no son válidas de la lista (110) autorizada.

12. El sistema (100) de gestión de acceso según la reivindicación 11, en el que:

el módulo (105) de gestión de solicitudes está configurado para modificar el criterio de validación, los datos de clasificación y/o el criterio de selección;

el módulo (105) de gestión de solicitudes está configurado para determinar si la solicitud (10) de registro de los dispositivos (200) cliente que se han colocado en la lista de espera cumple el criterio actualizado; y

el módulo (105) de gestión de solicitudes está configurado para generar instrucciones configuradas para hacer que el módulo de gestión de clientes (106) autorizados añada los IDs de clave (10) pública asociados a esos dispositivos (200) cliente a la lista (110) de autorizados.

13. El sistema (100) de gestión de acceso según cualquiera de las reivindicaciones 1 a 12 en el que:

la dirección (400) electrónica del proveedor es una dirección blockchain;

la solicitud (10) de registro incluye una firma generada utilizando una clave (14) de firma privada del dispositivo (200) cliente desde el que se recibe la solicitud (10) de registro; y

la clave pública es una clave de verificación pública complementaria de la clave de firma privada.

14. Un procedimiento implementado por ordenador para controlar el acceso a un recurso (300) electrónico, el recurso (300) electrónico accesible en una dirección de recurso, y proporcionado por un proveedor de servicios que tiene asociada una dirección (400) de proveedor electrónico, el procedimiento implementado por ordenador que comprende:

determinar si una solicitud (10) de registro recibida en la dirección (400) electrónica del proveedor es una solicitud de registro válida, la solicitud (10) de registro incluye un ID de clave (20) pública asociado a un dispositivo (200) cliente desde el que se recibe la solicitud (10) de registro; y

si se determina que la solicitud (10) de registro es una solicitud de registro válida, añadir el ID de clave (20) pública asociado con el dispositivo (200) cliente a una lista (110) autorizada, en la que cuando un ID de clave (20) pública del usuario está en la lista (110) autorizada, se permite al dispositivo (200) cliente acceder al recurso (300) electrónico.

15. Un procedimiento implementado por ordenador para controlar el acceso a un recurso (300) electrónico, el recurso (300) electrónico disponible en una dirección de recurso, y proporcionado por un proveedor de servicios que tiene asociada una dirección (400) de proveedor electrónico, el procedimiento implementado por ordenador que comprende:

procesar una pluralidad (100) de solicitudes de registro recibidas en la dirección (400) electrónica del proveedor, incluyendo cada una de las solicitudes (10) de registro un ID de clave (20) pública respectivo asociado con el dispositivo (200) cliente desde el que se recibe la solicitud (10) de registro, en la que el procesamiento de la pluralidad de solicitudes (10) de registro comprende:

seleccionar únicamente aquellas solicitudes (10) de registro de la pluralidad de solicitudes (10) de registro que cumplan un criterio de validación predeterminado; y/o clasificar las solicitudes (10) de registro basándose en los datos de clasificación contenidos en la solicitud (10) de registro, y seleccionar una o más de las solicitudes (10) de registro basándose en un criterio de selección; y

añadir a una lista (110) autorizada los IDs de clave (20) pública asociados a los dispositivos (200) cliente de los que se han recibido las solicitudes (10) de registro seleccionadas,

en el que: cuando un ID de clave (20) pública de un dispositivo (200) cliente está en la lista (110) autorizada, ese dispositivo (200) cliente puede acceder al recurso (300) electrónico.