SISTEMA Y MÉTODO DE PUBLICACIÓN AUTOMÁTICA DE INFORMACIÓN DE ESTADO ACTUALIZADA DE UN USUARIO EN UNA APLICACIÓN

INFORMÁTICA

D E S C R I P C I Ó N

CAMPO DE LA INVENCIÓN

La presente invención se aplica al campo de las telecomunicaciones, y más concretamente, a la actualización automática de información en aplicaciones informáticas como redes sociales.

ANTECEDENTES DE LA INVENCIÓN

En la actualidad, se han iniciado numerosas iniciativas de microblogging (publicación de pequeños textos que informan del estado actual de una persona y lo que hace en su día a día) por parte de diferentes compañías. Este fenómeno está superando en uso al clásico blogging, en el que las personas publican textos más detallados sobre temas concretos u opiniones varias. De los productos actualmente en el mercado, se encuentran alternativas ideadas tanto para plataformas de redes sociales Web como para móviles.

Una red social, en este contexto, es una herramienta informática a la que se accede habitualmente por una interíaz Web aunque también hay redes sociales accesibles desde teléfonos móviles. Las redes sociales permiten a sus usuarios mantenerse en contacto con sus amigos y conocidos, compartir contenidos multimedia, publicar el estado, intercambiar mensajes, etc., ya sea con fines lúdicos, laborables o de cualquier tipo.

Posiblemente uno de los primeros en facilitar microblogging fueron los sistemas de mensajería instantánea como MSN Messenger, que en sus últimas versiones permite a cada usuario publicar un pequeño texto con el estado actual, que posteriormente se verá junto al apodo (nombre elegido por el usuario).

Respecto a versiones puramente Web, el producto más emblemático es Twitter (http://twitter.com), uno de los pioneros y el más popular en el mundo del microblogging. Posibilita publicar pequeños mensajes de alrededor de 150 caracteres que describen esencialmente qué se está haciendo en cada momento. La página también permite hacer seguimiento de otros usuarios para recibir sus nuevos mensajes.

La creación de Twitter supuso un éxito rotundo y un cambio en la manera en que usuarios publican su estado. El éxito se ha hecho tan grande que se comienza a hablar de un tipo especial de blog llamado tumblelog. En el tumblelog la entrada de texto es más corta que un blog y usualmente mucho más aleatoria, expresa los pensamientos en un momento dado del autor, sin que por ello el texto tome forma de artículo o post. Debido a esta tendencia que empieza a consolidarse, numerosas redes sociales como Facebook (http://www.facebook.com/) o Hi5 (http://www.hi5.com/) han incluido opción de microblogging en sus perfiles.

La alta popularidad de este fenómeno y el hecho de que sus mensajes sean cortos y rápidos de escribir, ha posibilitado que el microblogging se expanda hacia los terminales móviles. Dadas las características de éstos, los mensajes de estado pueden ser enviados desde cualquier parte y casi cualquier situación, sin ser necesario que una persona acceda a un PC de sobremesa u ordenador portátil. Este entorno parece el más adecuado para escribir microblogs. Otra característica que se está aprovechando en la actualidad es la capacidad del móvil para obtener información de localización.

Así, los productos existentes como Facebook, Twitter y otros han adaptado versiones móviles para que sus usuarios puedan acceder desde sus teléfonos móviles y PDAs en cualquier lugar, actualizando su información de estado a cualquier hora.

Además, la tendencia de llevar el microblogging al mundo móvil ha abierto el camino a aplicaciones especialmente ideadas para estos dispositivos, como por ejemplo Radar (http://radar.net), una aplicación móvil que forma una red social en la que sus usuarios publican comentarios (con o sin fotos) y comparten experiencias entre ellos, todo ello a través de una interíaz en un teléfono móvil.

Por otra parte, los terminales móviles actuales disponen de una serie de prestaciones añadidas, como por ejemplo posibilidades de localización (mediante GPS u otras opciones) o de acceso a información externa a través de una conexión a Internet.

Servicios como Loopt (http://www.loopt.com) aprovechan parte de estas posibilidades al permitir ver en su pantalla la situación de unos contactos en un mapa, así como ver el estado actual de cada uno. Permite publicar el propio estado desde el propio teléfono para que el resto de contactos se actualice.

No obstante, este tipo de servicios utilizan información básica extraída por el móvil, principalmente referida a la localización, por lo que no aprovechan toda la capacidad de obtención de información del mismo, requiriendo en todos los casos la intervención del usuario a la hora de publicar información sobre el estado del mismo.

RESUMEN DE LA INVENCIÓN

La presente invención resuelve el problema anterior mediante un método y sistema que permiten automatizar la publicación de entradas sobre estados del usuario en aplicaciones informáticas (como microblogs, redes sociales, etc), mediante la aplicación de inteligencia artificial a información obtenida por un dispositivo móvil sobre la situación y el entorno del usuario. Se consigue, de este modo, la actualización automática de los estado más habituales del usuario (por ejemplo, estar trabajando, en casa, o de viaje), sin que el usuario tenga que dedicar tiempo a esta tarea.

En un primer aspecto de la presente invención, se presenta un sistema que actualiza información de estado a partir de información de entorno obtenida por un dispositivo móvil del propio usuario. Dicha información de entorno varía dependiendo de las capacidades de cada dispositivo móvil (sensores incluidos y opciones de conectividad), siendo ejemplos de la misma la localización, temperatura, información metereológica obtenida a través de Internet...

El sistema comprende para ello:

-Medios de almacenamiento para conservar información necesaria para el funcionamiento del sistema según se describe posteriormente.

-Medios de recopilación configurados para almacenar en los medios de almacenamiento la información del entorno. Dichos medios de recopilación suponen el interíaz entre el sistema y las fuentes de información del dispositivo móvil.

-Medios de personalización que permiten al usuario dotar inicialmente significado a parte de la información del entorno. El sistema realiza así un aprendizaje (que puede depurarse posteriormente aportando más información semántica por parte del usuario) que posteriormente le permite obtener conclusiones automáticas sobre el estado del usuario. Los medios de personalización también permiten al usuario imponer condiciones sobre qué información de usuario es finalmente publicada en la aplicación con el fin de mantener el control sobre el grado de privacidad de las mismas.

-Medios de inteligencia artificial, que generan automáticamente información inferida a partir de la información del entorno, considerando la información semántica de la que dispone y, preferentemente, de información de estado de usuario anterior. Existen dos opciones preferentes, para dichos medios de inteligencia artificial:

-Medios de inferencia de predicados lógicos basados en reglas y condiciones -Redes bayesianas, las cuales se entrenan para adaptar su salida a la información semántica introducida por el usuario para las distintas combinaciones de información de entorno (y en su caso, de estados anteriores)

-Medios de distribución, que suponen el interfaz con la aplicación. Los medios de distribución conectan con la aplicación informática y publican en ella la información de estado de usuario actualizada a partir de la información del entorno y la información inferida, siempre y cuando no entren en conflicto con las opciones de privacidad introducidas por el usuario.

En otro aspecto de la invención, se presenta un método para la actualización de dicha información de estado mediante la obtención de información del entorno e información semántica, su análisis para generar información inferida, y su posterior publicación en la aplicación.

Estos y otros aspectos de la invención serán aparentes a partir de las realizaciones descritas posteriormente en el presente documento.

BREVE DESCRIPCIÓN DE LAS FIGURAS

Con objeto de ayudar a una mejor comprensión de las características del invento de acuerdo con un ejemplo preferente de realización práctica del mismo y para complementar esta descripción, se acompaña como parte integrante de la misma la siguiente figura, cuyo carácter es ilustrativo y no limitativo:

La figura 1 ilustra el sistema de la invención según una realización práctica del mismo.

DESCRIPCIÓN DETALLADA DE LA INVENCIÓN

En este texto, el término "comprende" y sus derivaciones (como "comprendiendo", etc.) no deben entenderse en un sentido excluyente, es decir, estos términos no deben interpretarse como excluyentes de la posibilidad de que lo que se describe y define pueda incluir más elementos, etapas, etc.

En la figura 1 se presenta una realización preferente del sistema, mediante un modelo de arquitectura que cubre las características anteriormente expuestas para dar servicio a aplicaciones de microblogging automático.

Esta arquitectura, debido a sus características móviles y los servicios que requiere, es válida por ejemplo para plataformas como .NET o J2ME (Plataforma Java

2, Edición Micro). Esta última resulta más adecuada por su mayor aceptación en teléfonos móviles, su soporte en PDAs y su facilidad para ejecutar en servidores.

Esta arquitectura tiene una división global en diferentes capas o elementos: Medios de recopilación 3, que comprenden:

- Plugins de Contexto

- Capa de Sensorización

Medios de almacenamiento 4 o Capa de Almacenamiento

Medios de Inteligencia artificial 5 o Capa de Razonamiento

Medios de distribución 6 o Capa de Distribución

Medios de personalización 7 o Capa de Perfil y Preferencias

Servicios de Seguridad y Privacidad 8

En este texto, se entiende como contexto primario o de bajo nivel cualquier información del entorno 9 que llega al sistema a través de los medios de recopilación

3, independientemente de su origen y naturaleza; y como contexto de alto nivel la información inferida 10 generada por los medios de inteligencia artificial, es decir, información que no se obtiene directamente del entorno sino como resultado de la combinación y análisis del contexto primario. Se entiende por tanto, información de contexto como el conjunto de contexto primario y de alto nivel.

PLUGINS DE CONTEXTO

Esta parte de la arquitectura es la más cercana a la capa física del sistema. La arquitectura en esta altura está compuesta de diferentes plugins que se adhieren al sistema para adquirir información del entorno 9 (contexto primario). Cada plugin representa un tipo de información del entorno que puede obtenerse a través de un sensor 2 (entendiendo por sensor cualquier fuente de información, ya sean sensores lógicos, físicos o virtuales, y ya estén integrados en el propio dispositivo móvil o envíen información a través de una red de comunicaciones)

Cada plugin está compuesto de dos partes. La primera es la parte que lidia directamente con la fuente de información. Cada sensor tiene sus peculiaridades y necesita de un plugin específico para extraer la información de contexto primario pertinente. En la segunda parte se realiza el pre-proceso necesario para dejar la información del entorno en un formato que la aplicación puede manejar.

Los plugins son módulos independientes, que pueden añadirse o retirarse según las necesidades de la arquitectura. De esta forma se detectan los plugins de que se dispone y se cargan solamente los necesarios. Además, es posible extender las capacidades de sensorización añadiendo o creando plugins nuevos para nuevos sensores y tipos de información del entrono. Es una forma dinámica de adaptar la sensorización a la inmensa variedad de tipos de sensores que cada dispositivo en particular posee o tiene acceso.

Cada plugin puede acceder a la capa de comunicación a través de los servicios que le provee la capa de sensorización que lo alberga. Esto es muy útil sobre todo en sensores lógicos o virtuales que han de extraer el contexto primario de fuentes de información externas.

Estos plugins pueden ser capaces tanto de responder a peticiones de consulta, como notificar los cambios de estado que se den en ellos.

La implementación de cada plugin es dependiente de la naturaleza de la información de contexto primaria, con lo cual es diferente dependiendo del sensor o fuente de información a tratar. Debe cumplimentar, no obstante, una interfaz que describe:

-SupportsNotification: Define si el plugin soporta el mecanismo de notificación.

-RegisterNotification: Método utilizado para obtener notificaciones de cambios de valores en la información de contexto primaria.

-GetType: Obtiene el tipo de la información de contexto primaria que obtiene el sensor.

-RequiresInternetAccess: Define si el plugin necesita de acceso a la red para poder funcionar correctamente.

-Actívate: Activa el plugin y lo pone en funcionamiento.

-Deactivate: Para el funcionamiento y desactiva el plugin. -IsActive: Define si el plugin se encuentra activo y trabajando en el momento de la llamada.

-GetData: Obtiene la información de contexto primaria que el plugin es capaz de ofrecer.

-CanWork: Define si el plugin tiene todo lo necesario para poder activarse y trabajar adecuadamente.

Ejemplos de diferentes plugins pueden ser obtención de localización por GPS, obtención de localización por celda de cobertura, tiempo, temperatura actual, estado del tráfico, etc.

CAPA DE SENSORIZACION

Esta capa posee una visión general de todos los medios de captación de contexto primario de que se dispone. Puede activar o desactivar plugins a petición para mantener en memoria los necesarios. De esta manera la memoria se mantiene optimizada y se ofrecen sólo los servicios que realmente se piden. Esta capa es la encargada de comprobar el buen funcionamiento de los plugins (por ejemplo, comprobar que existe hardware y capa física suficiente para activar un plugin) y darles capacidades de comunicación. La capa de sensorizacion está preparada para hacer consultas a los plugins y recibir notificaciones de ellos de ser necesario.

La capa activa los plugins de contexto y se ofrece como receptora de su información. Una vez activos, existen dos formas en las que esta capa es capaz de extraer la información de contexto primaria:

-Consulta: Los plugins que así lo solicitan (o no son capaces de hacerlo de otra manera) ofrecen una interfaz para ser consultados, que es la misma independientemente del tipo de plugin. La capa accede a la interfaz de cada uno de los plugins, realiza la consulta y recoge la información de contexto primaria que ellos devuelven. Con dicha información de contexto primaria, accede a su vez a la capa de almacenamiento para almacenarlos.

-Notificación: Los plugins que son capaces de realizar este mecanismo de notificación, además de la interfaz de consulta proveen una interfaz de notificación; también idéntica independientemente del tipo de plugin. Bajo este método, la capa accede a cada plugin y se registra en él de tal forma que cuando dicho plugin sufre un cambio, varía el contenido de su información de contexto primaria o simplemente lo desea, avisa a la capa y ofrece la información de contexto primaria que ha obtenido. Así, se evita consultar periódicamente al plugin, y solamente es avisada cuando hay un cambio relevante del que informar. Como en el caso anterior, una vez obtenido la nueva información de contexto primaria se accede a la capa de almacenamiento.

Los plugins deben proveer obligatoriamente del mecanismo de consulta y tienen que informar a la capa de sensorizacion de si son capaces de realizar notificaciones. Ello también se realiza a través de su interfaz.

La forma en la que se accede a la capa de almacenamiento está descrita posteriormente.

Un caso de uso del funcionamiento de esta capa de sensorizacion, es elegir qué plugin de localización (GPS, célula de cobertura, etc.) tiene disponible y cuál activar dependiendo del hardware y los recursos en el dispositivo. Para averiguar si el hardware necesario está disponible, esta capa hace una petición de disponibilidad a cada plugin, el cual responde si tiene todo lo necesario. Esta capa intenta accionar un mecanismo de notificaciones a cada plugin. Si no es posible hacerlo, calcula una forma adecuada de frecuencia de consulta y se encarga de propagar el cambio a la capa de almacenamiento.

CAPA DE ALMACENAMIENTO

Esta capa es la base donde se almacena toda la información de contexto. Las consultas de información desde cualquier punto del sistema llegan a esta capa. La arquitectura está preparada para la posibilidad de generar notificaciones a otras capas en el momento en el que cierta información cambia de estado. La capa de sensorizacion almacenará aquí la información de contexto primaria obtenida y la capa de razonamiento se nutre de este nivel para realizar sus tareas.

Esta es la altura en la arquitectura donde se tiene la visión general de la información de contexto, ya que en las capas inferiores la información es sólo parcial. La información de contexto almacenada en la capa de almacenamiento puede venir de dos diferentes fuentes:

-Sensores de la capa de sensorizacion, ya sean físicos, lógicos o virtuales.

-Contexto de alto nivel generado por la capa de razonamiento Esta capa también contiene un Agente de Almacenamiento, al que se accede para recoger la información de contexto que se necesiten y para almacenar los que se hayan conseguido. Este agente recibe las consultas y comandos y devuelve las respuestas bien en forma de retorno normal (petición-consulta) o bien en forma de notificación si fuese necesario, siendo por tanto el encargado de transmitir las notificaciones de cambios de estado dentro de la capa es este módulo.

A través de este agente se realizan todos los accesos a la capa de almacenamiento. Es quien comprueba las políticas de acceso a la información (descrito en los servicios de seguridad y privacidad) y también quien notifica los cambios en la misma. El agente provee de métodos para realizar consultas de información y también para almacenar información de contexto. En el agente se centraliza el flujo de información hacia los demás elementos de la arquitectura.

La capa de sensorización accede al agente para almacenar la información de contexto primario y la capa de razonamiento lo utilizará para almacenar el contexto de alto nivel.

La forma preferente de implementación de la infraestructura de almacenamiento a la que el agente accede es una Base de Datos, aunque es perfectamente viable la alternativa de utilizar mecanismos de almacenamiento distribuido.

Si se solicita, se puede requerir al agente un almacenamiento cifrado de la información, quien entonces accede a los servicios de Privacidad y Seguridad 8 para cifrar los datos y descifrarlos en el momento de consulta. Si se ha solicitado el cifrado de los datos, en la consulta además de comprobarse los permisos de acceso, se piden las claves necesarias para descifrarlos.

CAPA DE RAZONAMIENTO

Esta capa realiza todo el razonamiento que se da lugar en la arquitectura. Utiliza para ello toda la información de contexto, tanto la que se ha conseguido localmente en el dispositivo (contexto primario) como la obtenida de alto nivel. Para ello, se abstrae de los sensores, siendo su única fuente de información la capa de almacenamiento. Esta capa hace uso del Agente de Almacenamiento para recuperar la información y para almacenar la que infiere.

El razonamiento de esta capa puede ser de distinta índole:

-Obtener nuevo contexto: El motor de razonamiento obtiene contexto de alto nivel a través de contexto de bajo nivel u otro contexto de alto nivel almacenado en la capa de almacenamiento.

-Reaccionar y tener un comportamiento específico sobre el contexto: Esto proporciona la posibilidad de razonar sobre la información de contexto no para obtener nueva, sino para decidir qué acciones tomar, por ejemplo si se ha llegado a obtener una información de microblogging relevante para publicar. La implementación de esta capa de razonamiento es preferentemente de inferencia de predicados lógicos, en la que la información de contexto se almacene en la capa de almacenamiento y además ello existen almacenadas en esta misma capa una serie de condiciones y reglas. El razonamiento lógico trata la información de contexto disponible y los somete a las reglas y condiciones almacenadas. Si las condiciones se cumplen, se llega a las conclusiones esperadas y se obtienen mensajes de estado automáticos.

Existe también otra posible implementación a través de Redes Bayesianas, en la que se crea una red y se entrena de tal forma que aprende a obtener las conclusiones deseadas a partir de la información de contexto que se da como entrada. Una vez entrenada, sirve para extraer las entradas de microblog automáticas dado un conjunto de información de contexto.

CAPA DE DISTRIBUCIÓN

Una vez la capa de razonamiento ha obtenido conclusiones relevantes, es decir, contexto de alto nivel, las almacena en la capa de almacenamiento. Como se ha dicho anteriormente, lo hace a través del agente de almacenamiento.

La capa de sensorización también utiliza el agente para almacenar la información de contexto primaria.

Como consecuencia, el agente de almacenamiento, al canalizar los accesos es capaz de detectar todos los cambios en la información de contexto. De esta manera es capaz de realizar notificaciones a su vez hacia la capa de distribución.

La capa de distribución es la encargada de distribuir la información a la aplicación o aplicaciones 1 usuarias de la arquitectura. También supone un intermediario si una aplicación quiere consultar la capa de almacenamiento. Por lo tanto, al existir tanto consulta como notificación a las aplicaciones, esta capa dispone de los dos mismos métodos de consulta y notificación descritos en la capa de sensorización. Al ser notificada nueva información de contexto, generalmente creada por la capa de razonamiento, la capa de distribución informa de ello a las aplicaciones interesadas y entrega el la información de contexto.

De la misma forma, las aplicaciones pueden consultar a la capa de distribución por información de contexto de un determinado tipo.

Para conseguir un nivel de abstracción entre la información concreta de contexto y el tipo de información que se envía a las aplicaciones, los niveles superiores desconocen si una información de contexto proviene de un sensor o un razonamiento. Tampoco saben de qué sensores concretos se dispone. Por lo tanto, una aplicación se puede mostrar interesada por tipos de información. Puede hacer consultas o suscribirse a notificaciones de tipos de información concretos. La arquitectura (concretamente el agente de almacenamiento) es capaz de ver si se pueden obtener estos tipos de información o el sistema en cambio es incapaz de obtenerlos.

Cuando se detecta un cambio y se quiere enviar una notificación del mismo, la capa de distribución examina primero el tipo de información de que se trata y con ello contrasta si la aplicación está interesada en él. Esta forma de contrastar viene descrita en los servicios de perfil y preferencias.

Como anteriormente se ha dicho, el contexto y sus tipos de información son muy amplios. Por tanto, se da la libertad de consultar por tipos de información sin restricciones, así como se da la oportunidad a cada plugin de contexto de definir qué tipo de información es capaz de obtener. La capa de razonamiento, junto con la capa de almacenamiento, pueden definir el tipo de información concluida. Así, toda información es almacenada junto con su tipo, que viene directamente dictado por la fuente que lo ha conseguido.

De esta forma es posible abstraer a los elementos externos de la arquitectura de las particularidades de la información interna. Como ejemplo, un tipo de información puede ser "localización" y muchos plugins de contexto pueden obtenerla, por GPS (Global Positioning System), por cercanía a otra persona u otros métodos. La capa de razonamiento también puede almacenar una información inferida del tipo "localización" si ha concluido que el lugar actual es "Museo del Prado".

SERVICIOS DE SEGURIDAD Y PRIVACIDAD

Trabajar con información de contexto de un usuario significa procesar e incluso llegar a almacenar información sensible y privada. Por ello es necesario que la arquitectura proteja al máximo posible la información con la que trabaja.

Para ello existen los servicios de privacidad y seguridad, que protegen la información de atacantes e intenciones maliciosas. Estos servicios son globales para toda la arquitectura, pudiendo usarse por los componentes que lo necesiten. Los servicios varían desde el cifrado de datos y la protección de la información, hasta la creación de políticas de acceso a la información de contexto para todos aquellos que quieran acceder a la información o el aseguramiento de las diferentes leyes de protección de datos.

Una política de acceso a datos es una serie de permisos grabados de forma persistente que dictan reglas de acceso a la información: quién puede acceder a qué datos. Pueden asignarse de forma manual dando permisos uno por uno a usuarios, o puede haber políticas predefinidas que contengan un conjunto de permisos. Estos permisos describen si se tiene acceso o no de lectura o escritura a los datos. Al agrupar permisos en un conjunto obtenemos una serie de autorizaciones predefinidas a un conjunto de datos. Asignárselas a un usuario es asignarle directamente permisos a un conjunto de datos.

Los servicios de seguridad y privacidad actúan de capa protectora de acceso a la información, y proveen de políticas de acceso para que sólo las entidades autorizadas puedan acceder a los datos pertinentes.

Los servicios de seguridad y privacidad almacenan la información de autenticación y las políticas de acceso que tiene cada usuario, aplicación o entidad que vaya a utilizar los datos de alguna manera.

De esta manera, las aplicaciones acceden a los servicios para autenticar a un usuario o aplicación. De forma interna, las propias entidades que usan la información de contexto pueden autenticarse de la misma forma. En el acceso a la capa de almacenamiento se accede a estos servicios para comprobar si el peticionario se ha autenticado, consultar sus permisos en sus políticas de acceso y contrastarlos con los permisos de que disponen los datos que va a pedir. Si todo es correcto, se procede al acceso a los datos, de otra manera se denegaría el acceso.

Las funciones de estos servicios son:

-Autenticación: Se autentica a las entidades y aplicaciones que usen los componentes de la arquitectura, para comprobar que son quien dicen ser. Este mecanismo viene dado por un método de nombre y contraseña. -Registro de permisos y políticas de acceso a datos: Cada usuario que se autentica tiene almacenados los tipos de datos a los que tiene acceso.

-Comprobación de permisos de acceso a datos: No se deben proporcionar datos a los que no se tiene acceso, con lo cual se provee de métodos para comprobar si un usuario tiene permiso de acceso a un tipo de dato concreto. -Cifrado de datos: Mecanismos de cifrado de datos disponibles mediante solicitud. Normalmente el solicitante es el agente de almacenamiento.

-Configuración: Servicios para borrar y dar de alta usuarios, además de modificación de permisos y políticas de acceso. A estos servicios sólo tienen acceso los usuarios del tipo Administrador.

SERVICIOS DE PERFIL Y PREFERENCIAS

La capa de perfil y preferencias permite conseguir un equilibrio entre la libertad y la automaticidad del sistema. Por una parte, la información que se consigue obtener se contrastará primero con el perfil que el usuario ha definido, y que sirve para marcar si realmente es de relevancia para ser publicada, al menos en ese momento.

Por otra parte, la forma en la que se publican los microblogs debe estar equilibrada con las preferencias de cada usuario. Para no interponerse con las intenciones de cada persona que utilice el microblogging automático, cada microblog se contrasta con las preferencias para ver si es posible su publicación y si es así, de qué forma ha de ser publicado.

El hecho de que la capa de perfil y preferencias sea parte de la arquitectura posibilita la reutilización de perfiles entre varias aplicaciones. Es posible para un mismo usuario tener perfiles de preferencias distintos en diferentes aplicaciones, pero también es posible de esta manera utilizar exactamente el mismo. Así, la lógica de contraste entre la información obtenida y el deseo del usuario de obtenerla se define una vez en la arquitectura y no una vez por aplicación.

En cuanto la información es obtenida por la capa de razonamiento, el siguiente paso es distribuirla por parte de la capa de distribución, quien como ya se ha mencionado, comprueba las preferencias de un usuario en cuanto a qué tipos de información desea recibir. Para ello accede a estos servicios de preferencias donde por usuario está registrada qué información es la deseada y cuál no se considera relevante.

Si los servicios no retornan una compatibilidad entre el tipo de información obtenida y la deseada, no se pasan al usuario.

Las funciones de estos servicios de perfil y preferencias son:

-Registro de preferencias de un usuario con respecto a tipos que está interesado en recibir.

-Comprobación de preferencias: Servicios para comprobar si un usuario está interesado en recibir un tipo concreto de datos.

FLUJO DE INFORMACIÓN A TRAVÉS DE LA ARQUITECTURA

Se ha descrito por separado el funcionamiento de cada capa en la arquitectura dada. Para obtener una visión más global se procede a describir cómo fluye la información a lo largo de las diferentes capas.

La información comienza a fluir en los plugins de contexto, que recogen la información de contexto primaria de los diferentes sensores o fuentes de información. Esta información de contexto primaria es entonces pasada a la capa de sensorización, a través de los citados mecanismos de consulta o notificación. La capa de sensorización accede a los servicios de preferencias para obtener una visión global de todos los tipos de información en los que los usuarios están interesados y con ello activa los plugins oportunos. De esta forma se evita tener activos plugins que no se necesitan. Al activar los plugins, envía una referencia a la capa de comunicación, permitiendo comunicarse con la red en caso de que ser necesario.

Esta capa de sensorización revisa también la corrección de la información de contexto primaria y si la información pasada por los plugins es válida para el sistema. Si es así, accede al agente de almacenamiento para almacenar la información de contexto primaria recibida, con lo cual la información podrá fluir hacia la capa de almacenamiento.

El agente de almacenamiento lanza un aviso a la capa de distribución por si es necesario notificar a las aplicaciones de información de contexto básico proveniente de sensores. También procede a almacenar la información de contexto primaria en la infraestructura de almacenamiento. Al tratar esta información, el agente accede a los servicios de Seguridad y Privacidad para comprobar los permisos y las políticas de acceso de cada componente a los datos.

Este flujo de información nutre la capa de almacenamiento con contexto primario, permitiendo a la capa de razonamiento realizar el análisis pertinente. Dicha capa de razonamiento accede al agente de almacenamiento para realizar consultas de información. Cuando el proceso de razonamiento infiere nuevo contexto de alto nivel, utiliza también el agente para almacenarlos. La capa de razonamiento puede incluso volver a pedir información de contexto de alto nivel en caso de necesitarlos de nuevo en otros procesos de inferencia.

De la misma forma que ocurre en la creación de contexto primario, la creación de contexto de alto nivel pasa por el agente de almacenamiento, quien tiene la oportunidad de notificar el nuevo contexto de alto nivel hacia la capa de distribución. De esta forma la capa de distribución recibe notificaciones de ambos tipos de información de contexto y puede pasarlos a las aplicaciones. Estas aplicaciones, previamente autenticadas utilizando los servicios de Seguridad y Privacidad, registran sus preferencias en los Servicios de Preferencias. La capa de distribución puede comprobar dichas preferencias (utilizando los Servicios de Preferencias) y los permisos de acceso a la información (utilizando los servicios de Privacidad y Seguridad). Si todo es correcto y coincide con las preferencias, la información pasa hacia las aplicaciones usuarias de la arquitectura.

La información que se transmite a las aplicaciones son las entradas automáticas de microblogging, o información muy cercanamente relacionada con ellas.

Si una aplicación decide consultar un tipo de información de contexto, accede a la capa de distribución, donde se autentica a través de los servicios de Seguridad mencionados. La capa comprueba los permisos para la aplicación y el tipo de información consultado. Si los tiene, se accede al agente de almacenamiento para obtener la información de contexto.

A la vista de esta descripción y figuras, el experto en la materia podrá entender que la invención ha sido descrita según algunas realizaciones preferentes de la misma, pero que múltiples variaciones pueden ser introducidas en dichas realizaciones preferentes, sin salir del objeto de la invención tal y como ha sido reivindicada.