ES2357269B1 - Procedimiento de identificacion a nivel de servicio web de un usuario basado en llamada para acceso movil - Google Patents

Abstract

La presente invención se refiere a un procedimiento de identificación de un usuario de un terminal móvil (10) a nivel de un servicio web ofrecido a dicho usuario, comprende:#- registrarse (101) dicho usuario en una red de acceso de datos en la que un servidor web (30) ofrece dicho servicio web (3) estableciéndose una sesión HTTP, y registrarse (102) en una red conmutada de circuitos (50);#- acceder a dicho servicio web mediante el terminal móvil (10);#- dicho servidor web en su respuesta http al terminal móvil incluye. un identificador de dicho servicio web (Service_ID) y una clave de sesión de usuario (TOKEN) generada para dicha sesión HTTP en curso;#- generar (105) el terminal móvil una llamada a través de la red de circuitos encaminada (106) al número compuesto por el identificador de servicio seguido de dicha clave;#- encaminar dicha llamada hacia un nodo de servicio (60) conectado a la red de circuitos con capacidad de recibir llamadas donde se identifica (107) el número de teléfono del usuario;#- dicho nodo de servicio envía (108) al servidor web una notificación que incluye el número de teléfono del usuario y la clave de sesión de usuario, dando por identificado (109) al usuario.

Description

Procedimiento de identificación a nivel de servicio web de un usuario basado en llamada para acceso móvil. Campo de la invención

La presente invención tiene su aplicación en el campo de las telecomunicaciones móviles con acceso a red conmutada de circuitos y conexión de datos. Más en concreto, la invención está orientada a la identificación de usuario en el acceso, desde un terminal móvil, a servicios en red. Antecedentes de la invención

Tradicionalmente se ofrecen servicios web a terminales fijos en los que la identificación de usuario se realiza de manera independiente de las credenciales de registro del terminal en la red de acceso. De este modo el usuario se ve obligado a realizar varios procesos de autenticación de manera secuencial.

Este hecho se presenta esquemáticamente en la Figura 1.

Cada vez es más habitual que los terminales móviles tengan capacidades de conectividad de datos, y la variedad de servicios accesibles a través de una interfaz web es cada vez más común.

Esa secuencia de autenticaciones constituyen normalmente un problema, y más especialmente si el uso del teclado es dificultoso, como es el caso de los terminales móviles, de menor tamaño que una plataforma de tipo PC en la que se dispone de un teclado completo y una pantalla de gran tamaño para insertar el usuario y la clave que sean necesarios.

Así, para acceder a los servicios personalizados de manera segura, el usuario normalmente se ve obligado a manejar diferentes claves de acceso cuya escritura en el caso de un terminal móvil puede resultar complicada y constituir una importante barrera para el usuario a la hora de utilizar un servicio, impactando de manera especialmente relevante en los modelos de negocio a considerar.

Por otro lado, al acceder a una sesión web a través de un navegador (browser) ejecutado en un terminal de usuario, se identifica la sesión mediante un identificador generado por el servidor, incluido en la respuesta HTTP del servidor al cliente, en concreto en la cookie HTTP.

Estas cookies son utilizadas normalmente para ser intercambiadas entre el cliente y el servidor para aspectos como identificación de la sesión a nivel HTTP así como gestión del estado de la misma.

La invención está orientada a la identificación de usuario desde un terminal móvil a nivel de sesión HTTP. Es decir, no está relacionada con procedimientos de autenticación a nivel radio desde el terminal móvil tanto en fase de registro del terminal en la red móvil como durante el establecimiento de una sesión de datos desde el terminal móvil a nivel físico.

En el documento 3GPP, 3GPP TSG SA WG3 Security -S3#28 (S3-030198) 6-9 May 2003, Berlin. “EAP support in smartcards and security requirements in WLAN authentication” se realiza una propuesta basada en la implementación en smartcards de procedimientos de tipo EAP, orientadas a autenticar la identidad del usuario en fase de registro contra la red de acceso mediante el intercambio de claves. No se trata de un procedimiento de autenticación a nivel de servicio, sino de registro en la red de acceso autenticando de manera segura al usuario.

La propuesta del documento de patente TW252649-B (“A convenient and secure wireless LAN authentication method and system based on SMS mechanism of GSM”) está orientada al acceso durante la fase de conexión o registro de un terminal en la red WLAN. Presenta un procedimiento de verificación de la identidad del usuario accediendo a la conexión mediante un terminal dual WiFi-GSM con la que se realiza el acceso. Esto se consigue con la generación de una clave de usuario desde la red asociada al número móvil que se envía por SMS al mismo. Esta clave se utiliza después para acceder al servicio vía WiFi, verificándose de este modo la identidad del usuario.

En el documento de patente RU-2295200 (“Method and system for GSM-authentication during roaming in wireless local networks”) se describe la utilización del identificador IMSI en los accesos a la red a través de un elemento mobileIP. Se trata de una autenticación a nivel de red para otorgar accesos a los terminales, no a nivel de servicio. Descripción de la invención

La invención se refiere a un procedimiento de identificación de un usuario de un terminal móvil de acuerdo con la reivindicación 1. Realizaciones preferidas del procedimiento se definen en las reivindicaciones dependientes.

La presente invención tiene como objetivo un procedimiento de identificación de un usuario que accede a un servicio web a través de un terminal móvil con conectividad a la red pública conmutada de tráfico de circuitosyalared de datos con acceso web.

Un primer aspecto de la invención se refiere a un procedimiento de identificación de un usuario de un terminal móvil a nivel de un servicio web ofrecido a dicho usuario, que comprende:

-

registrarse dicho usuario en una red de acceso de datos en la que un servidor web ofrece dicho servicio web estableciéndose una sesión HTTP, y registrarse en una red conmutada de circuitos;

-

acceder a dicho servicio web mediante el terminal móvil;

-

dicho servidor web en su respuesta http al terminal móvil incluye un identificador de dicho servicio web y una clave de sesión de usuario generada para dicha sesión HTTP en curso;

-

generar el terminal móvil una llamada a través de la red conmutada de circuitos encaminada al número compuesto por el identificador de servicio seguido de dicha clave;

-

encaminar dicha llamada hacia un nodo de servicio conectado a la red de circuitos con capacidad de recibir llamadas donde se identifica el número de teléfono del usuario;

-

dicho nodo de servicio envía al servidor web una notificación que incluye el número de teléfono del usuario y la clave de sesión de usuario, dando por identificado al usuario.

Dicha llamada generada por el terminal móvil puede llegar a establecerse o no, según implementación. De hecho, no es imprescindible completar el establecimiento de llamada entre ambos extremos (terminal móvil del usuario y el nodo de servicios conectado a la red conmutada de circuitos), ya que el nodo de servicio en la red conmutada de circuitos es capaz de obtener la información necesaria para continuar con la identificación del usuario sin establecer la misma. El impacto de señalización en la red es por tanto mínimo (y para el usuario es un procedimiento gratuito).

La clave de sesión de usuario es generada por un generador de claves de sesión de usuario que puede ser externo al servidor web, o también puede estar implementado dentro del servidor web.

La clave de sesión de usuario o token generada por el servicio web preferiblemente tiene una validez temporal limitada.

La identificación se realiza preferiblemente en base al número de teléfono del usuario, MSISDN en el caso móvil.

El servicio Web publicado por el servidor puede tratarse de una página web o de otro tipo de servicio accesible por HTTP.

El procedimiento de identificación de la presente invención resulta particularmente interesante en los entornos en los que el usuario se ve obligado a autenticarse repetidamente al acceder a un servicio web desde un acceso de tipo móvil con limitaciones en teclado, display, etc. Como se ha comentado anteriormente, estas dificultades en la identificación de usuario en el navegador (browser) del terminal móvil para acceder a un servicio web constituyen una importante barrera de usabilidad para conseguir el éxito de un servicio.

También es de especial aplicación cuando el acceso se realiza desde una red de datos fuera del control del operador del terminal móvil (por ejemplo, acceso mediante red WiFi o WiMAX privada).

Es decir, de cara a que el servidor web verifique la identidad del usuario que accede al servicio, en el procedimiento de la invención se incluye en la respuesta HTTP un identificador del servicio web junto con una clave de validez temporal generada por el mismo servicio web y asociada a la sesión HTTP. Ambos identificadores (de servicio y token asociado a la sesión HTTP) constituyen preferiblemente una TEL URI (Identificador Uniforme de Recurso o Uniform Resource Identifier) rutable en una llamada, de modo que se accede a un sistema en red que recibe la llamada y verifica la transacción con el servicio web, validando éste último la identidad del usuario sin necesidad de solicitar claves de acceso.

Dichos identificador de servicio y clave de sesión de usuario que se incluyen en la respuesta HTTP pueden incluirse en el cuerpo o en la cabecera, quedando el modo concreto de transportar esta información sujeto a diferentes implementaciones.

De esta forma, con la presente invención se facilita la identificación de un usuario que busca acceder a un servicio web, haciendo que la aceptación de los diferentes servicios web sea mucho mejor por parte del usuario final y, por tanto, su éxito se traduzca directamente en mayores beneficios. Breve descripción de los dibujos

Para complementar la descripción que se está realizando y con objeto de ayudar a una mejor comprensión de las características de la invención, a continuación se pasa a describir de manera breve un modo de realización de la invención, como ejemplo ilustrativo y no limitativo de ésta.

En la Figura 1 muestran los procedimientos tradicionales de registro a nivel de red de acceso y de servicio.

En la Figura 2 se muestra la arquitectura propuesta de identificación del usuario basada en llamada sobre la red conmutada de circuitos.

El diagrama de señalización propuesto se representa en la Figura 3. Descripción de una realización preferida de la invención

En la Figura 1 se representan los procedimientos tradicionales de registro de un terminal 1 a nivel de red de acceso2yde servicio web 3. Estos dos procedimientos diferenciados se realizan de manera desacoplada, ejecutándose en primer lugar un proceso de registro 4 del terminal 1 sobre la capa de acceso que puede requerir un usuario/contraseña. Una vez que el usuario está registrado en la red de acceso, se obtiene la conectividad necesaria para acceder al servicio Web e iniciar otro proceso de autenticación 5 contra dicho servicio Web. Para este segundo procedimiento se solicitará otro usuario/contraseña.

En la figura 2 se representa un esquema básicos de los diferentes elementos que intervienen en el procedimiento de identificación basado en llamada de la presente invención.

Así, se muestra un terminal móvil 10 que posee dos tipos de interfaz diferenciadas:

-

Una interfaz de tipo IP para acceder por medio de una red IP 20 a un servidor web y mantener una sesión HTTP. Esta interfaz puede ser establecido sobre una conexión de tipo WiFi, WiMAX, 3G, etc.

-

Una interfaz con la red conmutada de circuitos 50 para cursar llamadas en la red pública.

Se muestra también la red IP 20 a través de la cual el terminal establece una conexión de tipo HTTP con un servidor web 30 (o WebServer), que está en conexión HTTP con la red IP.

Este servidor web 30 publica un servicio web de tipo genérico, que puede tratarse de páginas HTML/WML/XML o bien de otros servicios accesibles desde el exterior.

En el procedimiento de la invención también interviene un generador de claves de sesión de usuario

o tokens 40. Se trata de un elemento funcional (puede ser externo al servidor web 30 o estar incluido en sus capacidades) encargado de generar una clave de sesión de usuario o token que identifica una sesión de usuario, de mantener una tabla en la que cada token esté asociada a una sesión http concreta, de gestionar el período de validez de las claves y de dar aceptación del registro del usuario.

La red (pública) conmutada de circuitos 50 debe tener la configuración adecuada para encaminar adecuadamente una llamada con un número B (o número destino llamado) que esté prefijado con un identificador asociado unívocamente al servicio Web dado de alta en el servicio de autenticación. De este modo la red conmutada de circuitos encamina de manera inteligente la llamada en base a este prefijo concreto hacia el nodo de servicio 60.

A la red conmutada de circuitos está conectado un nodo de servicio 60 que recibe la llamada del usuario que desea identificarse para un servicio web. Este nodo de servicio recibe la señalización de establecimiento de llamada y preferiblemente no la completa a fin de ofrecer un servicio gratuito a los usuarios y minimizar el impacto en la red. Así, en el caso ISUP (Parte de Usuario de Servicios Integrados, o Integrated Services User Part), este nodo recibe el comando IAM (Mensaje de Destino Inicial o Initial Address Message) pero no devuelve un ACM (Mensaje de Destino Completado o Address Complete Message) al origen para establecer la llamada.

En cualquier caso, si es necesario en función de la implementación particular, es posible completar el establecimiento de la llamada por parte de este nodo de servicios (en caso de que, por ejemplo, un IVR o Servicio de Respuesta de Voz Interactiva (Interactive Voice Response), deba devolver una locución con confirmación de la transacción).

Al recibir el generador de tokens 40 la notificación de parte del nodo de servicio 60 con el número de teléfono del usuario que se identifica, la tabla que mantiene el generador de claves se complementa con este número de teléfono y quedan, por tanto, asociados los tres valores: número de teléfono del usuario, clave de sesión de usuario e identificador de sesión http.

Al nodo de servicio 60 está asociada una base de datos 7, en la que se mantiene una tabla de prefijos de numeración de identificadores de servicio y de las identidades/direcciones IP de los servicios correspondientes a los que enviar las notificaciones de autenticación con el número de teléfono del usuario. Esta base de datos también puede estar incluida en la funcionalidad del nodo de servicio 60.

En la figura 3 se representa el diagrama de flujo de la implementación propuesta.

En primer lugar, el terminal 10 del usuario se registra tanto en la red de datos (paso 101) como en la red conmutada de circuitos 50 (paso 102) a través de las interfaces que el terminal posee.

Una vez que el registro tanto en la red de datos como en la red conmutada de circuitos se ha efectuado, el usuario accede a un servicio web (que puede tratarse de una página web o de otro tipo de servicio accesible por HTTP).

Al acceder el usuario a un servicio web a través de la conexión de datos, el terminal de usuario envía un HTTP GET (paso 103) a la URL correspondiente al servicio web (publicado por el servidor web 30) al que el usuario desea acceder.

El servicio web devuelve una respuesta afirmativa (HTTP 200 OK, paso 104). Debido a que el servicio web requiere de una autenticación de usuario, el servidor web 30 incluye en la respuesta HTTP los datos necesarios para realizar la identificación por llamada sobre la red conmutada de circuitos, en concreto, una TEL URI compuesta por el identificador del servicio web (Service_ID) y una clave de sesión de usuario (TOKEN) previamente generado por el generador de tokens 40 (implementado en este caso dentro del servidor web). El token es generado en tiempo real y está asociado a la sesión HTTP establecida con el usuario. Por ejemplo, la respuesta incluye “tel: 22221234567”, donde 2222 es el identificador de servicio (Service_ID), y la cadena numérica 1234567 es el token generado por el servidor web para la sesión HTTP en curso. Esta información puede estar incluida tanto en la cabecera de la respuesta HTTP como en el cuerpo de la misma, siendo este hecho una cuestión de implementación.

El terminal 10 del usuario recibe esta información (la TEL URI enviada por el servidor web) y genera una llamada (paso 105) a través de la red conmutada de circuitos 50 encaminada al número compuesto por el identificador de servicio (Service_ID) seguido del token asociado a la sesión HTTP, ambos incluidos en la respuesta HTTP del servicio web.

Esta información proporcionada por el servidor puede ser encriptada si fuera necesario por razones de incremento de la seguridad, sin embargo este aspecto constituye un detalle de implementación compatible en cualquier caso con la propuesta detallada en este documento.

En el caso particular de que la respuesta HTTP contenga una página web, el terminal móvil (a través de su navegador) reconoce esta TEL URI y la presenta al usuario de manera adecuada, que puede variar en función del tipo de sistema operativo o navegador de que se trate. El usuario puede seleccionar o hacer click en el navegador del móvil sobre la TEL URI concreta, y se genera la llamada hacia el nodo de servicio conectado a la red conmutada de circuitos, posiblemente con una solicitud intermedia de confirmación por parte del usuario (lo cual no es excluyente ya que se trata de una opción de implementación).

Aunque no es necesaria a priori la inclusión de una aplicación concreta en el terminal móvil de usuario para el tratamiento de la TEL URI en el caso HTML/HTTP, si en la respuesta HTTP del servidor Web se incluye otro tipo de información (XML, JSON, ASN.1, etc.), puede ser necesaria la ejecución en el terminal móvil de un software de parseado u obtención de la TEL URI para poder generar la llamada sobre la red conmutada de circuitos al destino adecuado, es decir, al nodo de servicios de identificación de usuario.

Una vez generada la llamada (Llamada a “Servi-ce_ID+TOKEN”, paso 106), ésta es encaminada por la red (pública) conmutada de circuitos 50, que identifica el tipo de llamada a partir de la TEL URI a la que va dirigida, y encamina la llamada hacia un nodo de servicio conectado a la red de circuitos con capacidad de recibir llamadas (puede tratarse de un IVR o de un nodo de servicios) donde se identifica el número llamante del usuario.

Este nodo de servicio 60 identifica el servicio web a través del identificador de servicio incluido en el destino de la llamada, captura el número de teléfono del usuario (paso 107) y envía una notificación al servicio web correspondiente (paso 108), incluyendo el número de teléfono del usuario capturado y el token recibido durante el proceso de llamada generada por el terminal del usuario.

El servicio web devuelve una respuesta positiva (OK, paso 109) de identificación de usuario y el usuario queda de ese modo identificado en el servicio web (paso 110) a través de su número de teléfono, quedando éste asociado a la sesión a nivel HTTP, manteniéndose esta identificación a lo largo de toda la vida de la sesión entre el terminal móvil de usuario y el servidor Web a través del intercambio de cookies HTTP de manera estándar.

Como se ha indicado anteriormente, en el caso de un servidor web que publique páginas HTML, esta TEL URI se puede incluir como parte del código HTML, soportándose esta inclusión de numeración telefónica como URLs según la RFC 2806 del IETF.

Como también se ha señalado antes, no es imprescindible completar el establecimiento de la llamada entre ambos extremos (terminal móvil del usuario y el nodo de servicios conectado a la red conmutada de circuitos), ya que el nodo de servicio en la red conmutada de circuitos es capaz de obtener la información necesaria para continuar con la identificación del usuario sin establecer la misma. El impacto de señalización en la red es por tanto mínimo, y para el usuario es un procedimiento gratuito. El hecho de establecer o no la llamada de identificación es un detalle de implementación.

La clave de sesión de usuario o token generado por el servicio web tiene una validez temporal limitada, de modo que una vez expirada la misma, no es posible realizar autenticaciones utilizando ese TOKEN (hasta que sea reasignado). El manejo de este tiempo de validez es una cuestión de implementación, de modo que si es necesario incluir el tiempo de validez del TOKEN en la respuesta HTTP por parte del servidor web, se puede incluir como un atributo mas en la mensajería HTTP que genere el servidor web hacia el cliente.

Asimismo, la validez del token generado expira una vez que haya sido utilizado para identificar un usuario concreto y asociar el número de teléfono del mismo a una sesión HTTP concreta.

En cualquier caso esta propuesta es compatible con cualquier tiempo de validez que pueda ser implementado, teniendo en cuenta el hecho de que un menor tiempo de validez puede dificultar la ejecución del proceso por parte del usuario, y un mayor tiempo de validez compromete la seguridad del proceso.

Este período de validez limitado, unido al hecho de que el TOKEN puede incluir un número de dígitos potencialmente alto (lo que dificulta el descubrimiento de la misma por “fuerza bruta” en el tiempo limitado de validez del TOKEN) confiere al sistema un nivel de seguridad muy alto frente a los recursos de procesamiento requeridos para su implementación.

Estas transacciones se realizan de manera sencilla por parte del usuario, mediante el manejo básico del terminal de usuario, sin necesidad de introducir usuario/contraseña de manera textual.

Adicionalmente, esta propuesta es válida en entornos en los que el usuario se encuentra en roaming, pudiendo en ese caso acceder al nodo de servicio conectado a la red conmutada para identificarse contra él como una llamada internacional normal.

El procedimiento de la invención puede ser llevado por el operador o no.

En el caso de que el procedimiento se implemente en un servicio proporcionado por el operador, la numeración empleada para esta funcionalidad puede ser encaminada a un único nodo de servicio de identificación de usuarios en la red conmutada de circuitos, mediante el análisis del número destino de la llamada generada.

Si se trata de un servicio ofrecido por un proveedor de servicios ajeno al operador, se debe reservar un rango de numeración suficiente de modo que sea posible aceptar las solicitudes de identificación de usuarios. En este caso la TEL URI proporcionada por el servicio Web al terminal móvil es uno de los números incluidos en ese rango al que generar la llamada.

La invención ha sido descrita según realizaciones preferentes de la misma, pero para el experto en la materia resultará evidente que múltiples variaciones pueden ser introducidas en dichas realizaciones preferentes sin exceder el objeto de la invención reivindicada.

Claims (11)

1. REIVINDICACIONES

   1. Procedimiento de identificación de un usuario de un terminal móvil (10) a nivel de un servicio web

   (3) ofrecido a dicho usuario, que comprende:

   -

   registrarse (101) dicho usuario en una red de acceso de datos en la que un servidor web (30) ofrece dicho servicio web (3) estableciéndose una sesión HTTP, y registrarse (102) en una red conmutada de circuitos (50);

   -

   acceder a dicho servicio web (3) mediante el terminal móvil (10);

   -

   dicho servidor web (30) en su respuesta http al terminal móvil incluye un identificador de dicho servicio web (Service_ID) y una clave de sesión de usuario (TOKEN) generada para dicha sesión HTTP en curso;

   -

   generar (105) el terminal móvil una llamada a través de la red conmutada de circuitos (50) encaminada (106) al número compuesto por el identificador de servicio (Service_ID) seguido de dicha clave (TO-KEN);

   -

   encaminar dicha llamada hacia un nodo de servicio (60) conectado a la red de circuitos con capacidad de recibir llamadas donde se identifica (107) el número de teléfono del usuario;

   -

   dicho nodo de servicio envía (108) al servidor web una notificación que incluye el número de teléfono del usuario y la clave de sesión de usuario;

   -

   dicho servicio web identifica (109) al usuario.

2. 2. Procedimiento según la reivindicación 1, en el que dicha llamada generada por el terminal móvil no llega a establecerse.
3. 3. Procedimiento según la reivindicación 1, en el que dicha llamada realizada por el terminal móvil sí llega a establecerse.

4. 4.

   Procedimiento según cualquiera de las reivindicaciones 1-3, en el que la clave de sesión de usuario es generada por un generador de claves de sesión de usuario (40).

5. 5.

   Procedimiento según la reivindicación 4, en el que dicho generador de claves de sesión de usuario

   (40) es externo al servidor web (30).
6. 6. Procedimiento según la reivindicación 4, en el que dicho generador de claves de sesión de usuario

   (40) está implementado dentro del servidor web (30).

7. 7.

   Procedimiento según cualquiera de las reivindicaciones 1-6, en el que dicho identificador de dicho servicio web (Service_ID) y dicha clave de sesión de usuario (TOKEN) están incluidos en la cabecera de la respuesta http.

8. 8.

   Procedimiento según cualquiera de las reivindicaciones 1-6, en el que dicho identificador de dicho servicio web (Service_ID) y dicha clave de sesión de usuario (TOKEN) están incluidos en el cuerpo de la respuesta http.

9. 9.

   Procedimiento según cualquiera de las reivindicaciones 1-8, en el que la clave de sesión de usuario (TOKEN) generada por el servicio web tiene una validez temporal limitada.

10. 10.

    Procedimiento según cualquiera de las reivindicaciones 1-9, en el que si dicho servicio web ofrecido por el servidor web es una página HTML, dicho identificador de dicho servicio web (Service_ID) y dicha clave de sesión de usuario (TOKEN) están incluidos como parte del código HTML, soportándose esta inclusión de numeración telefónica como URLs según la RFC 2806 del IETF.

    OFICINA ESPAÑOLA DE PATENTES Y MARCAS

    N.º solicitud: 200900524

    ESPAÑA

    Fecha de presentación de la solicitud: 25.02.2009

    Fecha de prioridad:

    INFORME SOBRE EL ESTADO DE LA TECNICA

    51 Int. Cl. : G06F21/00 (2006.01)

    DOCUMENTOS RELEVANTES

    Categoría

    Documentos citados Reivindicaciones afectadas

    X

    Sola, O.M. et al. A Security Model Proposal fora Social Communications Broker.Consumer Communicationsand Networking Conference, 2009. CCNC 2009. 6thIEEE DOI10.1109/CCNC.2009.4784909 paginas 1 -5; 1-10

    Categoría de los documentos citados X: de particular relevancia Y: de particular relevancia combinado con otro/s de la misma categoría A: refleja el estado de la técnica O: referido a divulgación no escrita P: publicado entre la fecha de prioridad y la de presentación de la solicitud E: documento anterior, pero publicado después de la fecha de presentación de la solicitud

    El presente informe ha sido realizado • para todas las reivindicaciones • para las reivindicaciones nº:

    Fecha de realización del informe 04.04.2011

    Examinador J. Santaella Vallejo Página 1/5

    INFORME DEL ESTADO DE LA TÉCNICA

    Documentación mínima buscada (sistema de clasificación seguido de los símbolos de clasificación) G06F Bases de datos electrónicas consultadas durante la búsqueda (nombre de la base de datos y, si es posible, términos de

    búsqueda utilizados) INVENES, EPODOC

    OPINIÓN ESCRITA

    Fecha de Realización de la Opinión Escrita: 04.04.2011

    Declaración

    Novedad (Art. 6.1 LP 11/1986)

    Reivindicaciones Reivindicaciones 2,3 y 10 1,4-9 SI NO

    Actividad inventiva (Art. 8.1 LP11/1986)

    Reivindicaciones Reivindicaciones 1-10 SI NO

    Se considera que la solicitud cumple con el requisito de aplicación industrial. Este requisito fue evaluado durante la fase de examen formal y técnico de la solicitud (Artículo 31.2 Ley 11/1986).

    Base de la Opinión.-

    La presente opinión se ha realizado sobre la base de la solicitud de patente tal y como se publica.

    OPINIÓN ESCRITA

    1. Documentos considerados.-

    A continuación se relacionan los documentos pertenecientes al estado de la técnica tomados en consideración para la realización de esta opinión.

    Documento

    Número Publicación o Identificación Fecha Publicación

    D01

    Sola, O.M. et al. A Security Model Proposal fora Social Communications Broker.Consumer Communicationsand Networking Conference, 2009. CCNC 2009. 6thIEEE DOI10.1109/CCNC.2009.4784909 paginas 1 -5; 10-13.01. 2009

11. 2. Declaración motivada según los artículos 29.6 y 29.7 del Reglamento de ejecución de la Ley 11/1986, de 20 de marzo, de Patentes sobre la novedad y la actividad inventiva; citas y explicaciones en apoyo de esta declaración

    Para la realización de esta opinión escrita se han utilizado las reivindicaciones contenidas en la solicitud.

    La invención reivindicada divulga un procedimiento de identificación de un usuario. Consistente en que el usuario se registrar en la red de telefonía móvil y en un servidor web. El servidor web le pasa un “token” y se encamina a un nodo de servicio donde se identifica con el número de usuario de telefonía y el “token” proporcionado por el servidor

    El documento del estado de la técnica más próximo a la invención es D01 trata sobre modelo de seguridad en las redes sociales. En este modelo se introduce un “Broker social” entre el operador de red y las redes sociales. El articulo estable dos formas alternativas para intercambiar token entre el usuario y la red social

    Para mayor claridad, y en la medida de lo posible, se emplea la misma redacción utilizada en la reivindicación primera. Las referencias entre paréntesis corresponden al D01. Las características técnicas que no se encuentran en el documento D01 se indican entre corchetes.

    Reivindicación 1 Procedimiento de identificación de un usuario de un terminal móvil nivel de un servicio web (sección “II Social Communications”; figura 3) ofrecido a dicho usuario, que comprende: -[registrarse dicho usuario en una red de acceso de datos] en la que un servidor web ofrece dicho servicio web estableciéndose una sesión HTTP, [registrarse en una red conmutada de circuitos] (secciones: “II Social Communications” -“IV The Security Model:A. Autheticating the link”; figura 1 y 3);

    -

    acceder a dicho servicio web mediante el terminal móvil (figura 3);

    -

    dicho servidor web en su respuesta http al terminal móvil incluye un identificador de dicho servicio web y una clave de sesión de usuario generada para dicha sesión HTTP en curso (“IV The Security Model:A. Autheticating the link”; figura 2.b y 3)

    -

    generar el terminal móvil una llamada a través de la red conmutada de circuitos encaminada al número compuesto por el identificador de servicio seguido de dicha clave (“IV The Security Model:A. Autheticating the link”; figura 2.b y 3);

    -

    encaminar dicha llamada hacia un nodo de servicio conectado a la red (Social Broker) de circuitos con capacidad de recibir llamadas donde se identifica el número de teléfono del usuario (“IV The Security Model: A. Autheticating the link”; figura 2.b y 3);

    -

    dicho nodo de servicio envía al servidor web una notificación que incluye el número de teléfono del usuario y la clave de sesión de usuario (“IV The Security Model:A. Autheticating the link”; figura 2.b y 3);

    La diferencia que aparece entre D01 y la solicitud es que no aparece de forma explícita el registro a la red de acceso de datos y de conmutación de circuitos. Este hecho se considera implícito ya que en el documento D01 aparece en la sección V” Movistar Contacta” en el apartado: “A Authenticating the link”. El terminal móvil debe de estar conectado a la red y para que esté conectado debe de haber un registro tanto de la red de datos como la de conmutación de circuitos.

    Por lo tanto a la luz de D01, la reivindicación 1 no es nueva tal como se establece en el artículos 6 de la Ley de Patentes 1986.

    OPINIÓN ESCRITA

    Reivindicaciones 2 y 3 La llamada generada por el terminal móvil puede o no llegar a establecerse.

    Estas reivindicaciones son obvias para un experto en la materia y por lo tanto carecen de actividad inventiva.

    Por lo tanto a la luz de D01, las reivindicaciones 2 y 3 son nuevas pero carecen de actividad inventiva tal como establece en los artículos 6 y 8 de la Ley de Patentes 1986.

    Reivindicaciones 4-9 La clave de sesión de usuario es generada por un generador de claves siendo este generador de claves externo o interno al servidor web y con una validez temporal. La clave se sitúa en la cabecera o en el cuerpo de la respuesta http (“IV The Security Model:A. Autheticating the link”; y sección VI User Experience apartado: “A. Autentication the link”).

    Por lo tanto a la luz de D01, las reivindicaciones 4-9 no son nuevas tal como se establece en el artículos 6 de la Ley de Patentes 1986.

    Reivindicación 10 El servicio web ofrecido por el servidor web es una página HTML, dicho identificador de dicho servicio web y dicha clave de sesión de usuario están incluidos como parte del código HTML, [soportándose esta inclusión de numeración telefónica como URLs según la RFC 2806 del IETF].

    El objeto en las reivindicación 10 comprende sólo modos de realización y no se puede considerar que implique actividad inventiva

    Por lo tanto a la luz de D01, las reivindicación 10 es nueva pero carece de actividad inventiva tal como establece en los artículos 6 y 8 de la Ley de Patentes 1986.