ES2402005B1 - Marco digital multimedia personalizable por medio de identificación de usuarios - Google Patents

Abstract

El marco digital multimedia personalizable por medio de identificación de usuarios comprende un dispositivo capaz de mostrar en una pantalla, a modo de presentación sucesiones de contenidos multimedia asociados a uno o varios usuarios registrados en el dispositivo, atendiendo a un mecanismo de detección de presencia e identificación de usuarios. Mediante este mecanismo, el dispositivo determina qué usuarios se encuentran en la vecindad del marco y adapta la presentación de contenidos a las preferencias de dichos usuarios. Comprende además un sistema de gestión que permite administrar la información referente a usuarios y contenidos dados de alta en el dispositivo, así como configurar las preferencias de los diferentes usuarios en relación con la presentación de contenidos. Esto permite, entre otras cosas, personalizar el ambiente de viviendas domóticas y otros entornos inteligentes en función de las preferencias de los usuarios que se encuentren en el entorno en cada momento.

Description

Marco digital multimedia personalizable por medio de identificación de usuarios

SECTOR DE LA TÉCNICA

Esta invención se encuadra dentro de los sistemas de personalización de servicios para el usuario en entornos inteligentes (domótica, inmótica, urbótica, ...), y en concreto dentro de los sistemas para la presentación de sucesiones de contenidos multimedia a los usuarios, cuyo principal exponente hoy día son los marcos de fotos digitales.

ESTADO DE LA TÉCNICA

En éste capítulo se exponen los antecedentes de la invención, tanto en el ámbito general de la personalización de servicios como en el ámbito más concreto de los marcos de fotos digitales.

Personalización de servicios en el hogar digital

La personalización de sistemas y servicios no es algo novedoso. De hecho, la mayor parte de los trabajos que desarrollan agentes de usuario se enfocan hacia la configuración de un sistema software de acuerdo con sus preferencias. Estos agentes pueden ser completamente personales, como los descritos en [Müller, H., Hilbrich, T. and Kühnel, R., An Asistant Agent. Fundamenta Informaticae 34, pp1-10, 1999] o adaptables a cada usuario que accede al sistema, como en [Pazzani, M.J. and Billsus, D., Adaptive Web Site agents. Autonomous Agents and Multiagent Systems, 5, pp. 205-218, 2002].

Aunque es posible personalizar los servicios a los que accede un usuario en cualquiera de los entornos que le rodean, el hogar digital es, sin duda, aquel en el que se siente más de cerca el efecto que producen. No significa esto que no pueda personalizarse el acceso a los sistemas y servicios en el trabajo, que sin duda sí se hace, sino que es en el hogar el momento en el que el usuario se siente más propenso a disfrutar de los sistemas que le hacen la vida más cómoda, y por tanto, el entorno más estudiado.

En los últimos años se ha hablado y escrito ampliamente sobre los conceptos de Hogar digital, domótica e inmótica [Lorente, S. y Medina, J.J. El libro blanco del Hogar Digital. Colegio Oficial de Ingenieros Técnicos de Telecomunicación, 2004]. Hasta muy recientemente, el hogar digital se ha confundido con la domótica y ha sido visto, casi exclusivamente, como un sistema, pocas veces global y normalmente desagregado, de control de diversos dispositivos en las viviendas y en los entornos empresariales; fundamentalmente: sensores, controladores y algún electrodoméstico.

Al mismo tiempo, hemos dotado a nuestros hogares con un número de dispositivos cada vez mayor: varios aparatos de televisión, varios equipos de música, uno o varios ordenadores, dispositivos de grabación/reproducción de películas, como video y dvd, sistemas de seguridad, etc. El número de electrodomésticos (desde grandes aparatos hasta pequeños dispositivos) por metro cuadrado aumenta sin parar, lo que no significa que nuestra calidad de vida mejore. Tenemos acceso a más productos y servicios, pero a costa de un incremento de la complejidad en su uso no despreciable. Por ejemplo, de la misma manera que crece el número de aparatos, el número de mandos a distancia crece con ellos. Asimismo, comienzan a aparecer nuevos electrodomésticos capaces de ofrecer contenidos multimedia desde un sistema central.

Finalmente, en los últimos años han empezado a aparecer arquitecturas de personalización de servicios que buscan abordar el problema de un modo más global. El objetivo es personalizar el entorno en el que se encuentran los usuarios de una vivienda (o, en un sentido más amplio, de un espacio vital, ya que la mayor parte de las ideas que podamos aplicar al hogar digital, pueden trasladarse al lugar de trabajo, al vehículo, o incluso a espacios públicos). El concepto de Inteligencia Ambiental amplía los ámbitos de aplicación de la tecnología: ya no se trata sólo de un entorno doméstico, sino que también se incluyen otros espacios nuevos: el automóvil, los espacios de uso público (aeropuertos, estaciones, autopistas, etc.), zonas de servicios (hoteles, centros comerciales, etc.) y otros. No obstante, aunque muchas de estas arquitecturas presentan resultados prometedores en cuanto a personalización de servicios [B. Johanson, A. Fox, and T. Winograd, “The interactive workspaces project: Experiences with ubiquitous computing rooms,” IEEE Pervasive Computing, pp. 67–74, 2002; J. Yura, J. Nakazawa, and H. Tokuda, “Galaxy ds: Directory service for service composition based on smart space structure,” in Proceedings of the 19th International Conference on Advanced Information Networking and Applications (AINA’05), 2005; Marsa-Maestre, I., Lopez-Carmona, M., y Velasco, J., “A hierarchical, agent-based service oriented architecture for smart environments”, in Service Oriented Computing and Applications, 2(4):167–185, 2008], la alta complejidad y elevado coste de las soluciones existentes hace que aún no sean una posibilidad real para la personalización de servicios en nuestros hogares.

Marco de fotos digitales

En la actualidad, podemos ver marcos digitales en multitud de comercios especializados. Un marco digital no es más que una dispositivo para los hogares capaz de mostrar en una pantalla, generalmente LCD (pantalla de cristal líquido), un conjunto de imágenes seleccionadas por una o varias personas. Su funcionamiento básico consiste en proporcionar una sucesión de las fotografías almacenadas en el dispositivo a modo de presentación de diapositivas. Este tipo de dispositivos pretende reemplazar al marco de fotos tradicional, sobre el que aporta un mayor aprovechamiento del espacio (un mismo marco de fotos digital permite la visualización de un conjunto de fotografías) y un ahorro de recursos (papel fotográfico), además de añadir cierto dinamismo al entorno donde se integra. En algunos casos, los marcos de fotos digitales no sólo se limitan a reproducir imágenes, sino que vienen preparados para reproducir video y audio. Prácticamente todos los modelos proporcionan los mismos servicios; las principales diferencias entre unos y otros vendrán marcadas por el tamaño de la pantalla y las prestaciones de que disponen. Como ejemplos de dichas prestaciones pueden citarse la resolución de la pantalla, el consumo y los mecanismos disponibles para la transferencia o almacenamiento de las imágenes, que pueden ir desde puertos USB a conectividad a Internet.

Los avances tecnológicos en el mundo de la fotografía, la posibilidad de almacenamiento de datos en soportes cada vez más pequeños, y el bajo precio frente a las posibilidades que ofrecen, han ayudado a que los marcos digitales sean cada vez más demandados. Se puede decir que desde sus orígenes en el mercado, hace unos cuatro años, el número de ventas ha aumentado de forma considerable. No obstante, ninguno de los modelos existentes proporciona personalización dinámica automática de los servicios que proporciona. El conjunto de contenidos audiovisuales que se muestran a los usuarios sólo cambia por configuración manual, y no responde a la presencia o no de usuarios en las inmediaciones del dispositivo.

DESCRIPCIÓN

El objetivo principal de la invención es desarrollar un sistema capaz de generar un entorno multimedia multiusuario, personalizable e inteligente. Cada usuario podrá personalizar dicho entorno facilitando al sistema un conjunto de contenidos preferidos y parámetros de configuración. Haciendo uso de esta información y de mecanismos de detección de presencia e identificación de usuarios, el sistema determinará de forma completamente autónoma cómo deberá comportarse, actuando como un Marco Digital Inteligente (en adelante, MDI).

En esta sección se describe desde un punto de vista funcional el Marco Digital Inteligente. Se comienza definiendo las tareas o especificación de requisitos y roles de usuario mediante un diagrama de Casos de Uso siguiendo la notación UML (Unified Modelling Language, Lenguaje Unificado de Modelado). También se recurre a la representación de un diagrama de bloques genérico donde se muestran los módulos en los que se divide el MDI con el objetivo de diversificar funcionalidades y definir áreas de desarrollo, lo que facilitará la implementación y elaboración del mismo.

Casos de Uso del dispositivo

A continuación se describen la funcionalidad del Marco Digital Inteligente por medio de Casos de Uso, lo que proporciona una perspectiva del problema que resuelve el dispositivo desde el punto de vista del usuario. El diagrama de casos de uso correspondiente puede verse en la Figura 1.

CU-001: Autenticación: el MDI comprueba la identidad del gestor y/o del usuario permitiéndoles acceder al sistema. En caso del gestor, para realizar cualquier operación de gestión de la información del MDI, y en caso del usuario poder visualizar sus contenidos asociados. Si dichas identidades son erróneas, el MDI deniega el acceso. La comprobación de identidad del usuario se realizará por medio de una credencial de identificación, que dependerá del mecanismo de identificación utilizado (e.g. una contraseña, un RFID (Radio Frequency Identification, Identificación por Radiofrecuencia), una huella dactilar...).

CU-002: Cambiar credenciales: el gestor puede modificar sus credenciales de identificación o las de cualquier otro usuario. El MDI informará al gestor mediante un mensaje por el interfaz de gestión si se ha ejecutado la orden satisfactoriamente o no.

CU-003: Operar con contenidos: el gestor accede al MDI para ejecutar operaciones relacionadas con los contenidos multimedia. Ejemplos de dichas operaciones pueden ser: consultar los contenidos existentes, añadir contenidos al sistema, asociar un contenido con un usuario, eliminar contenidos, deshacer asociación contenidousuario.

CU-004: Operar con usuarios: el gestor accede al MDI para ejecutar operaciones relacionadas con los usuarios. Ejemplos de dichas operaciones pueden ser: consulta de los usuarios dados de alta en el sistema, añadir usuarios al sistema, eliminar usuarios del sistema, asociar un usuario con uno o varios contenidos, eliminar asociación usuariocontenido.

CU-005: Consultar: se distinguen dos tipos de consultas. En el caso de “Operar con contenidos”, el MDI proporcionará al gestor un extracto de la información almacenada acerca de los contenidos dados de alta en el dispositivo. Y en el caso de “Operar con usuarios”, el MDI proporcionará al gestor un extracto de la información almacenada acerca de los usuarios dados de alta en el dispositivo.

CU-006: Añadir: El gestor podrá añadir contenidos y usuarios al sistema. En el caso de “Operar con contenidos”, el gestor podrá añadir contenidos al sistema, y el MDI adaptará las características de los mismos (e.g. tamaño y calidad de imagen) según las especificaciones de la pantalla donde van a ser visualizadas, optimizando así el espacio de almacenamiento. Y en el caso de “Operar con usuarios”, el gestor podrá dar de alta nuevos usuarios al sistema. En ambos casos, el MDI notifica al gestor si la acción se ha realizado con éxito o no.

CU-007: Eliminar: El gestor puede dar de baja a usuarios, eliminar contenidos o deshacer las asociaciones usuariocontenido de forma permanente del MDI cuando desee.

CU-008: Asociar: El gestor asocia contenidos existentes en el sistema con usuarios dados de alta en el mismo. En dicha asociación debe indicarse por cada contenido y usuario el tiempo que se mostrará el contenido correspondiente en la interfaz de usuario. El MDI notifica al gestor si la acción se ha realizado con éxito o no.

CU-009: Resetear: El gestor elimina todo tipo de información: contenidos, usuarios, asociaciones, … que se haya insertado en el MDI. Devolviendo al sistema a un estado inicial de vacío.

CU-010: Detectar presencia: El sistema deberá realizar constantes búsquedas de presencia de usuarios dentro del área de detección, de acuerdo con el mecanismo de identificación que se emplee (e.g. RFID, Bluetooth, huella digital...). Con ello, permite que los usuarios detectados reciban sus contenidos asociados en la interfaz de usuario.

CU-011: Selección y visualización de contenidos: El MDI muestra a través de la interfaz de usuario los contenidos asociados al usuario o usuarios detectados a modo de diapositivas atendiendo al tiempo de visualización de cada uno de ellos. En caso de haberse identificado a más de un usuario el MDI mostrará contenidos alternativamente de unos y de otros siguiendo el orden de acceso al sistema. En caso de no haberse detectado presencia la interfaz de usuario mostrará contenidos por defecto, o permanecerá en estado de bajo consumo, según se haya configurado.

Diagrama de Bloques genérico

En este apartado se describen de forma gráfica y global los componentes que conforman el sistema objeto de esta invención desde un punto de vista lógico.

En la Figura 2 se muestra un sistema modular formado por tres módulos principales de operación y una base de datos. Dichos módulos son independientes entre sí y cada uno encapsula una serie de tareas y funcionalidades que las diferencia del resto, siendo la base de datos el único nexo de unión entre ellos. Dicha base de datos albergará toda la información que se maneje en el sistema, y deberá gestionar las solicitudes de envío o recepción de datos originadas por los módulos.

Módulo de Gestión (MG)

El módulo de gestión es el encargado de gestionar toda la información que entra en el MDI y la configuración del mismo. Se comunica con el Gestor mediante el programa interfaz de gestión y con la base de datos mediante la lógica de gestión.

La interfaz de gestión (IG) se encarga de facilitar al gestor un entorno visual e intuitivo de configuración y gestión del MDI, permitiéndole navegar y operar sobre cada una de las funcionalidades del sistema.

La lógica de gestión (LG) es un subsistema que interactúa con la interfaz de gestión y con la base de datos. Recibe la información y los mensajes de la interfaz de gestión para determinar las acciones que debe ejecutar, y envían los datos a la base de datos para su almacenamiento. También es el encargado de realizar las consultas a la base de datos y proporcionar los resultados a la interfaz de gestión.

Las tareas o acciones que deberá encapsular el módulo de gestión para su posterior implementación dentro del desarrollo del MDI, corresponden a los Casos de Uso: del CU-001 al CU-009.

Módulo de Provisión de Contenidos (MPC)

El módulo de provisión de contenidos se encarga de proporcionar contenidos a los usuarios, atendiendo a una configuración previa del MDI. Dicho mecanismo se lleva a cabo mediante dos elementos: interfaz de provisión de contenidos y lógica de provisión de contenidos.

La interfaz de provisión de contenidos (IPC) se encarga de mostrar los contenidos correspondientes a los usuarios (e.g. imagen o video por pantalla, sonido a través de unos altavoces, ...). Los contenidos se muestran durante un tiempo definido, según lo especifique el parámetro de tiempo de visualización correspondiente a dichos contenidos y usuarios. Se deben cumplir las siguientes premisas para que la interfaz de provisión de contenidos sirva contenidos a los usuarios:

•

Los usuarios deberán haber sido detectados dentro del área de cobertura del MDI, y estar dados de alta en el sistema.

•

Debe haber contenidos en el MDI y éstos deben estar asociados a los usuarios. Puede asignarse el mismo contenido a varios usuarios, o viceversa.

La lógica de provisión de contenidos (LPC) es el subsistema encargado de seleccionar y proporcionar a la interfaz de provisión de contenidos los contenidos y los valores de los parámetros de configuración de cada uno de ellos.

Las tareas que debe realizar este módulo se corresponden con la especificación del Caso de Uso: CU-010.

Módulo de Identificación y Detección (MID)

Este módulo es el encargado de detectar la proximidad de un usuario al MDI en un área de detección determinada y de identificar a dicho usuario. Los mecanismos hardware de detección e identificación, así como el área de detección, dependerán de la tecnología específica que se emplee. Entre las diferentes tecnologías posibles para la detección e identificación de usuarios podemos citar, a modo de ejemplo y sin excluir otras, RFID, NFC (Near Field Communication, Comunicación de Campo Cercano), Bluetooth, WiFi o técnicas biométricas.

La lógica de identificación y detección (LID) es el subsistema encargado de hacer uso del hardware de identificación y detección para detectar la presencia de los usuarios dentro del área de detección. En caso afirmativo, la lógica recopila los identificadores de los usuarios y los autentica en el MDI enviando dichos identificadores a la base de datos. El sistema podrá configurarse para mostrar contenidos por defecto o para no mostrar contenido alguno si no se ha detectado ningún usuario.

Las tareas que debe llevar a cabo este módulo se han especificado en el Caso de Uso: CU-011.

Módulo Base de Datos (MBD)

La base de datos es un elemento crucial del sistema objeto de la invención, ya que se encarga de almacenar toda la información que se genere en el MDI, y sirve como nexo de unión entre todos los módulos. Dicha información puede ser almacenada de diferentes formas (e.g. de forma organizada siguiendo un modelo relacional, donde las “tablas” y los “registros” son los elementos que componen su estructura), y en diferentes localizaciones

(e.g. un disco duro en el propio dispositivo, un servidor externo, ...).

El acceso a dicha información es gestionado por el SGBD (Sistema de Gestión de Base de Datos), cuyo objetivo es servir de interfaz entre los datos y el resto de módulos. Los módulos deben realizar las peticiones de consulta o escritura al SGBD, y éste se encarga de ejecutarlas, extrayendo o insertando en la base de datos la información que le haya sido solicitada. Una de las características más importantes del SGBD, es que soluciona los casos de concurrencia de acceso a los datos por parte de dos o más módulos, lo que permite conservar la integridad de los mismos.

DESCRIPCIÓN DE LOS DIBUJOS

Para complementar la descripción que se es fl realizando y con objeto de ayudar a una mejor comprensión de las características de la invención , así como para proporcionar un mayor detalle en el ejemplo preferente de realización práctica de la misma , se acompaña como parte integrante de esta descripción un juego de dibujos en donde, con carácter ilustrativo y no limitativo, se ha representado lo siguiente:

• Figura 1 - Diagrama de Casos de Uso del sistema Marco Digital: se muestra el diagrama de Casos de Uso del MD que representa cómo los usuarios con distintos roles operan sobre el MD. El diagrama consta de tres elementos: actores, son los distintos roles que pueden adoptar los usuarios y que desencadenan las acciones; Casos de Uso, son la tareas específicas que se realizan tras la orden de algún actor; y las relaciones entre ambos. Entre los Casos de Uso también puede haber relaciones, y estas pueden ser de dos tipos:

a) Relación tipo <<include>>: indica que cada invocación del Caso de Uso base invocará a su vez al caso que se “incluye”.

b) Relación tipo <<extends>>: indica que cada invocación del Caso de Uso base puede comenzar otro dentro de aquel mismo.

•

Figura 2 - Diagrama de bloques genérico: se muestra un sistema modular formado por tres módulos principales de operación y una base de datos. Dichos módulos son independientes entre sí y cada uno encapsula una serie de tareas y funcionalidades que las diferencia del resto, siendo la base de datos el único nexo de unión entre ellos. Dicha base de datos albergará toda la información que se maneje en el sistema, y deberá gestionar las solicitudes de envío o recepción de datos originadas por los módulos.

•

Figura 3 - Pantalla de acceso al sistema de gestión: Muestra el aspecto de la interfaz de gestión en el ejemplo de realización de la invención cuando se intenta acceder a la interfaz de gestión.

•

Figura 4 - Diagrama de flujo de la lógica de acceso al sistema de gestión: Muestra el diagrama de flujo de la comprobación de credenciales de acceso a la interfaz de gestión.

•

Figura 5 - Pantalla de cambio de contraseña de gestión: Muestra el aspecto de la interfaz de gestión en el ejemplo de realización de la invención cuando se intenta cambiar la contraseña interfaz de gestión.

•

Figura 6 - Diagrama de flujo de la lógica de cambio de contraseña de gestión: Muestra el diagrama de flujo del cambio de contraseña para la interfaz de gestión.

•

Figura 7 - Pantalla de adición de usuarios: Muestra el aspecto de la interfaz de gestión en el ejemplo de realización de la invención cuando se intenta añadir usuarios al sistema.

•

Figura 8 - Diagrama de flujo de la lógica de adición de usuarios: Muestra el diagrama de flujo de la adición de usuarios.

•

Figura 9 - Pantalla de adición de imágenes: Muestra el aspecto de la interfaz de gestión en el ejemplo de realización de la invención cuando se intenta añadir imágenes al sistema.

•

Figura 10 - Diagrama de flujo de la lógica de adición de imágenes: Muestra el diagrama de flujo de la adición de imágenes.

•

Figura 11 - Pantalla de asociación de imágenes a usuarios: Muestra el aspecto de la interfaz de gestión en el ejemplo de realización de la invención cuando se intenta asociar imágenes a usuarios.

•

Figura 12 - Diagrama de flujo de la lógica de asociación de imágenes a usuarios: Muestra el diagrama de flujo de la asociación de imágenes a usuarios.

•

Figura 13 - Pantalla de consulta de imágenes: Muestra el aspecto de la interfaz de gestión en el ejemplo de realización de la invención cuando se realizan consultas relativas a imágenes.

•

Figura 14 - Diagrama de flujo de la lógica de consulta de imágenes: Muestra el diagrama de flujo de la consulta de imágenes.

•

Figura 15 - Pantalla de consulta de usuarios: Muestra el aspecto de la interfaz de gestión en el ejemplo de realización de la invención cuando se realizan consultas relativas a usuarios.

•

Figura 16 - Diagrama de flujo de la lógica de desasociación: Muestra el diagrama de flujo asociado a la eliminación de asociaciones entre usuarios e imágenes.

•

Figura 17 - Diagrama de flujo de la lógica de eliminación de usuarios e imágenes: Muestra el diagrama de flujo asociado a la eliminación de usuarios e imágenes.

•

Figura 18 - Pantalla de retorno a configuración de fábrica: Muestra el aspecto de la interfaz de gestión en el ejemplo de realización de la invención cuando se intenta resetear el dispositivo a su configuración de fábrica.

•

Figura 19 - Diagrama de flujo de la lógica de retorno a configuración de fábrica: Muestra el diagrama de flujo del retorno a configuración de fábrica.

•

Figura 20 - Estructura de las páginas de la interfaz de gestión: Muestra la disposición de los diferentes elementos que conforman las páginas de la interfaz de gestión.

•

Figura 21 - Esquema de interacción JSRS (JavaScript Remote Scripting, Instrucciones Remotas de JavaScript): Muestra la relación entre los diferentes elementos JSRS para dar soporte al módulo de provisión de contenidos..

•

Figura 22 - Diagrama de flujo del lado de cliente JSRS: Muestra el diagrama de flujo del lado del cliente JSRS en el módulo de provisión de contenidos.

•

Figura 23 - Diagrama de flujo de la secuenciación de contenidos: Muestra el diagrama de flujo del proceso de secuenciación de contenidos en módulo de provisión de contenidos.

•

Figura 24 - Diagrama de flujo de la selección de usuarios: Muestra el diagrama de flujo del proceso de selección de usuarios al que se alude en la figura 23.

•

Figura 25 - Diagrama de flujo de la selección de imágenes: Muestra el diagrama de flujo del proceso de selección de imágenes al que se alude en la figura 23.

•

Figura 26 - Pantalla de la interfaz de provisión de contenidos: Muestra el aspecto de la interfaz de provisión de contenidos en el ejemplo de realización de la invención cuando se intenta mostrar una imagen de un tamaño inferior al de la resolución de la pantalla.

•

Figura 27 - Diagrama de flujo de la lógica de detección: Muestra el diagrama de flujo del proceso de detección e identificación de usuarios.

•

Figura 28 - Integración del sistema MDI en un sistema domótico centralizado: Muestra un ejemplo de despliegue distribuido de MDIs para un entorno centralizado, de forma que los medios puedan mostrarse a los diferentes usuarios a través de diferentes pantallas distribuidas por toda la vivienda.

MODO DE REALIZACIÓN

En este capítulo se describe con detalle la implementación de un modo de realización preferente y no exclusivo de la invención. En esta realización de la invención se ha optado por el uso de un soporte hardware basado en un PC empotrado con sistema operativo Linux, y por el uso de Bluetooth como mecanismo de detección e identificación de usuarios a través de sus teléfonos móviles o dispositivos similares. Los contenidos multimedia que se han escogido para este modo de realizaión de la invención son imágenes fijas que se presentan a modo de diapositivas, por lo que para la interfaz de provisión de servicios se ha optado por una pantalla LCD.

Este capítulo se ha dividido en cuatro secciones, de acuerdo con los módulos que comprenden la

realización de la invención. A continuación se resume brevemente el objeto de cada una de esas cuatro secciones, y

se enumeran las tecnologías empleadas en el módulo correspondiente:

1. Diseño y estructura de la Base de Datos.

En esta sección se define la estructura de la base de datos y sus componentes: tablas, campos y relaciones entre las tablas. Como se ha dicho en el capítulo anterior, la base de datos albergará toda la información del MDI, por lo que cada uno de los campos debe corresponderse a un tipo de información manejada por el sistema. En esta realización de la invención se ha empleado el sistema de gestión de base de datos MySQL, ya que es uno de los más extendidos por el momento, está disponible para las distintas plataformas, es rápido y fácil de usar. Para gestionar MySQL se utiliza la herramienta Web PhpMyAdmin.

2. Desarrollo del módulo de gestión.

En esta sección se describe la implementación de todos los programas e interfaces que permiten al gestor administrar el MDI. Para la implementación de este módulo se han utilizado tecnologías Web siguiendo una arquitectura cliente-servidor, lo que permite al gestor acceder al MDI vía remota (por WiFi o Ethernet) mediante un navegador Web. En este caso, el cliente corresponde a un navegador Web que servirá de herramienta al gestor para comunicarse con el MDI, y como servidor, el servidor Web más extendido por el momento, Apache. La Capa de Presentación se desarrolla con código HTML y JavaScript, y la Capa de Negocio con lenguaje PHP en su totalidad, creándose un programa o script por cada acción que el gestor desee ejecutar. Tanto el código HTML-JavaScript como PHP residen en el servidor Web Apache. El motivo de escoger estas tecnologías es porque son las más extendidas y apropiadas para este tipo de aplicaciones, y son de uso gratuito.

3. Desarrollo del módulo de provisión de contenidos.

En esta sección se describe la implementación del mecanismo de visualización que permite a los usuarios ver sus imágenes. Para la implementación de este módulo se usa la técnica de desarrollo Web JSRS basada en una arquitectura cliente-servidor, y que permite una comunicación asíncrona en segundo plano entre el cliente y el servidor sin necesidad que el cliente recargue la página. La interfaz de usuario se implementa con código HTML y JavaScript, usando el navegador Web Opera como marco de ejecución de dicho código, y empleando el lenguaje de programación PHP del lado del servidor; como en la fase anterior, ambos códigos residen en el servidor Web Apache.

4. Desarrollo del módulo de detección.

En esta sección se describe la implementación del mecanismo encargado de detectar la presencia de los usuarios en un rango de cobertura limitado. La tecnología hardware que se usa es Bluetooth, la cual permite encontrar dispositivos a una distancia de hasta 10 metros. Se ha escogido esta tecnología porque hoy en día todos los teléfonos móviles vienen equipados con Bluetooth y no supone al usuario tener que adquirir ningún otro tipo de accesorio o dispositivo adicional para interactuar con el sistema. Como credencial de usuario, por tanto, se empleará la dirección MAC de su dispositivo Bluetooth. En cuanto a la implementación software, hay que decir que se usa el lenguaje de programación Java acompañado del conjunto de librerías Bluecove de Java, las cuales, contienen todas las funciones definidas en la especificación JSR-82, encargada de definir el conjunto de APIs (Application Programming Interfaces, Interfaz de Programación de Aplicaciones) que generan el entorno de

5 desarrollo para la tecnología inalámbrica Bluetooth. También se utiliza la API JDBC (Java Database Connection, Conexión a Bases de Datos mediante Java) que permite ejecutar instrucciones SQL (Structured Query Language, Lenguaje Estructurado de Peticiones) para acceder al contenido de la base de datos MySQL diseñada en la Capa de Datos.

Diseño y estructura de la base de datos

10 Estructura de las tablas

La estructura que se presenta en esta sección es la necesaria para la realización preferente de la invención

descrita en este capítulo, y deberá adaptarse para cualquier otra realización de la invención, según sus

características particulares.

� LOGIN:

15 Como el objetivo es el desarrollo de una aplicación Web para la gestión del Marco Digital y ésta tendrá un acceso restringido a los datos, se necesitará una tabla donde almacenar la información de acceso: password. La tabla ‘log’ contiene dicha información.

LOGIN

Nombre del campo

Tipo de campo Descripción del campo

passwd

varchar (40) Password del gestor codificado en MD5 (PK)

� USUARIOS: La información referente a los usuarios registrados en el Marco Digital se almacenará en la tabla ‘usuarios’.

USUARIOS

Nombre del campo

Tipo de campo Descripción del campo

mac

varchar (17) dirección MAC del dispositivo bluetooth del usuario (PK)

nombre

varchar (30) nombre del dispositivo bluetooth del usuario

selec

tinyint (1) indicador de selección (valor predeterminado “0”)

El campo selec indica si se han mostrado imágenes del usuario correspondiente o no. Se emplea para establecer la secuencia de visualización de imágenes en caso de haber dos o más usuarios detectados en el 25 sistema.

� USUARIOS_DETECTADOS:

En la tabla ‘usuarios_detectados’ se almacena la información correspondiente a los usuarios que han sido detectados por el sistema, y que pueden estar dados de alta o no.

USUARIOS_DETECTADOS

Nombre del campo

Tipo de campo Descripción del campo

mac

varchar (17) dirección MAC del dispositivo bluetooth del usuario (PK)

nombre

varchar (30) nombre del dispositivo bluetooth del usuario

� IMAGENES: La información referente a las imágenes almacenadas en el Marco Digital figuran en la tabla ‘imagenes’.

Nombre del campo

IMAGENES Tipo de campo Descripción del campo

Id_imagen

bigint (11) Clave primaria (PK) (auto_increment, valor predeterminado “NULL”)

nombre

varchar (30) nombre y formato asignado a la imagen

tamanyo

float tamaño en bytes que ocupa cada imagen en disco

contador

bigint (11) Contador de visualizaciones

El campo contador almacena el número de veces que se ha visualizado la imagen correspondiente por pantalla.

� RELACION:

En esta tabla ‘relacion’ se almacenarán las asociaciones establecidas entre los usuarios registrados en la tabla ‘usuarios’ y las imágenes registradas en la tabla ‘imagenes’.

RELACION

Nombre del campo

Tipo de campo Descripción del campo

Id_imagen

bigint (11) Clave primaria (PK) (auto_increment, valor predeterminado “NULL”)

mac

varchar (17) dirección MAC del dispositivo bluetooth del usuario (PK)

tiempo

varchar (6) tamaño en bytes que ocupa cada imagen en disco

view

tinyint (1) indicador de selección (valor predeterminado “0”)

En este caso, existe una clave primaria compuesta por el campo id_imagen correspondiente a la tabla ‘imagenes’ y el campo mac correspondiente a la tabla ‘usuarios’. Dicha clave primaria es única y no puede repetirse en toda la tabla. El campo view indica si se ha mostrado la imagen, se emplea para establecer la secuencia de visualización de las imágenes de un usuario determinado.

Desarrollo del módulo de Gestión

Estructura interna

La realización de la estructura interna del módulo de gestión se ha basado en la arquitectura clienteservidor, donde el cliente (navegador Web) ejecutará código HTML y/o JavaScript y el servidor los scripts PHP. Dichos scripts son archivos de órdenes almacenados en texto plano que serán interpretados por el motor PHP alojado en el servidor Web Apache. Cuando el cliente realiza una petición de una página o script PHP, el servidor Web será el encargado de ejecutarlo, procesarlo y generar el código HTML correspondiente para enviarlo como respuesta al navegador. En los scripts en los que se requiera, PHP accederá a la base de datos MySQL para realizar las operaciones oportunas (inserción, actualización o borrado de registros) o para consultar sus datos.

SCRIPTS

• AUTENTICACIÓN:

La autenticación es el mecanismo que permite al Gestor acceder al sistema, y está formado por un formulario implementado en HTML para recoger el password de gestión y dos scripts PHP:

index.php:

Es la página inicial de la aplicación Web, tal y como se muestra en la Figura 3. Está desarrollada íntegramente con código HTML y contiene el formulario que recoge el password de acceso al sistema de gestión, y se lo envía al script valido_usuario.php para su validación.

valido_usuario.php:

Es el script encargado de validar la contraseña de gestión. Para ello recoge el password enviado por el formulario y lo compara con el almacenado en la Base de Datos. Si son iguales crea una sesión y una variable de sesión inicializada con el SID (Identificador de Sesión) correspondiente, y permite la navegación por las páginas de la aplicación Web, en caso contrario no crea ninguna sesión y redirige a la página index.php. La Figura 4 muestra un diagrama de flujo de dicha lógica.

• CAMBIAR PASSWORD:

Proporciona al Gestor la funcionalidad de cambiar el password en el momento que desee. Se implementa mediante un formulario en HTML para recogida de datos y un script en PHP:

cambiar_passwd_form.php

Contiene el formulario para recoger el password actual y el nuevo para enviárselos al script cambiar_passwd.php. El password nuevo lo solicita por duplicado para asegurarse que no haya fallos en la escritura. En las figuras 5 y 6 se muestra, respectivamente, una imagen del aspecto visual de la página y el diagrama de flujo de la lógica asociada.

cambiar_passwd.php

Las acciones que lleva a cabo en este script son las siguientes:

1.

Recoge los tres campos enviados por la página anterior y extrae el valor del password de la Base de Datos.

2.

Comprueba que los tres campos no están vacíos.

3.

Evalúa que sea igual que el primer campo.

4.

Compara el segundo y el tercer campo pertenecientes al nuevo password por duplicado.

5.

Actualiza la tabla ‘log’ de la Base de Datos con el nuevo password.

• AÑADIR USUARIOS:

Este conjunto de scripts se encargan de dar de alta usuarios en el MDI. En las figuras 7 y 8 se muestra, respectivamente, una imagen del aspecto visual de la página y el diagrama de flujo de la lógica asociada.

anadir_usuario_form.php

Contiene el formulario que recoge los datos de registro de usuarios y se los envía al script anadir_usuario.php para ser procesados. Está desarrollado en HTML pero parte de dicho código se crea dinámicamente mediante PHP. Esto es porque para mostrar el listado de los usuarios detectados se necesita acceder a la tabla ‘usuarios_detectados’ de la Base de Datos.

anadir_usuario.php

Este script se encarga de recoger la información correspondiente a los usuarios con el siguiente formato de cadena: “nombre/MAC”, y los inserta en la Base de Datos. Antes de realizar esta última acción, evalúa si se ha seleccionado alguna opción. En el caso de darse de alta un usuario que ya estaba registrado en el sistema con la misma MAC pero con distinto nombre, actualiza únicamente el campo ‘nombre’ de la tabla ‘usuarios’ de la Base de Datos.

• AÑADIR IMÁGENES:

Este conjunto de scripts permiten añadir imágenes al MDI. Los formatos permitidos son .jpeg o .gif, siendo el tamaño máximo de una imagen de 5MB. En las figuras 9 y 10 se muestra, respectivamente, una imagen del aspecto visual de la página y el diagrama de flujo de la lógica asociada.

upload_form.php

Contiene el formulario por el cuál el Gestor puede introducir imágenes en el sistema. Recoge el nombre y el formato de hasta cuatro imágenes a la vez y se las envía al script upload.php para procesarlas.

upload.php

Este script recoge las imágenes enviadas por la página anterior y realiza las siguientes las siguientes acciones sobre las mismas:

1.

Evalúa si se ha seleccionado alguna imagen, si el formato es el correcto, y si existe en el sistema otras imágenes con el mismo nombre.

2.

Las almacena en el directorio correspondiente.

3.

Adapta las imágenes a la resolución de la pantalla donde van a ser visualizadas sin que la calidad se vea afectada, únicamente, en el caso que dichas imágenes tengan una resolución mayor que la pantalla. En caso contrario mantiene el formato original.

4.

Crea los thumbails (imágenes reducidas) de cada una de ellas.

5.

Inserta en la Base de Datos toda la información referente a las mismas (nombre y tamaño).

• ASOCIAR:

Este conjunto de scripts se encargan de establecer las relaciones entre los usuarios y las imágenes. El método es asociando a un usuario las imágenes deseadas, asignando un tiempo de visualización a cada una de ellas. En las figuras 11 y 12 se muestra, respectivamente, una imagen del aspecto visual de la página y el diagrama de flujo de la lógica asociada.

asociar_form.php

Proporciona el formulario correspondiente para que el Gestor pueda establecer las asociaciones. Esta página se genera dinámicamente mediante código PHP, ya que necesita mostrar todos los usuarios dados de alta y todas las imágenes, almacenados en la Base de Datos. Una vez el Gestor haya hecho su asociación, se la enviará al script asociar.php para incluirla en la Base de Datos.

asociar.php

Este script recoge los datos relacionados con la asociación: identificador de usuario (MAC), los identificadores de las imágenes y sus tiempos de visualización. En el caso de haberse seleccionado las opciones correctamente, el script inserta una nueva entrada en la tabla ‘relaciones’ de la base de datos, y si ya existiese la relación, actualizaría el tiempo de visualización.

� CONSULTAR:

Este conjunto de scripts se encargan de consultar el contenido del sistema mediante accesos a la Base de Datos y mostrárselos al Gestor de forma estructurada. Hay dos opciones de consulta: imágenes o usuarios.

consulta_img.php

Este script se encarga de recopilar toda la información asociada con las imágenes (nombre, tamaño, número de visualizaciones y usuarios asociados) existentes en el sistema mediante el acceso a la Base de Datos, estructurarla en una tabla y generar dinámicamente el código HTML correspondiente a la página que visualizará el Gestor. En este caso, no existe ningún elemento de formulario, por lo que este script no recibe ninguna información del exterior. Este script también proporciona por cada una de las imágenes los enlaces a los scripts eliminar.php y desasociar.php los cuales analizaremos sus funcionalidades en el siguiente apartado.

En las figuras 13 y 14 se muestra, respectivamente, una imagen del aspecto visual de la página y el diagrama de flujo de la lógica asociada.

consulta_user.php

Este script se encarga de recopilar toda la información asociada con los usuarios dados de alta en el sistema (nombre, dirección MAC e imágenes asociadas). A nivel de implementación es exactamente igual que el script anterior pero se diferencia que en vez de tratar con imágenes trata con usuarios. Por lo tanto el diagrama de flujo como el código es muy similar. En la figura 15 se muestra una imagen del aspecto visual de la página.

� BORRAR:

Como se ha podido ver en el apartado anterior, ambos scripts contienen enlaces a desasociar.php y eliminar.php, esto permite la posibilidad de borrar información del sistema. En las figuras 16 y 17 se muestran, respectivamente, los diagramas de flujo de las lógicas asociadas.

desasociar.php

La misión de este script es eliminar registros de la tabla ‘relaciones’ de la Base de Datos. Recoge mediante el método POST la información (identificador de usuario y de imagen, y página solicitante) enviada por cualquiera de los dos scripts del apartado anterior y ejecuta la orden de borrado sobre la Base de Datos.

eliminar.php

Este script se encarga de dar de baja usuarios o borrar imágenes del sistema. Dependiendo de la página que le llame hará una cosa u otra. La información necesaria (identificador de usuario o imagen, y página solicitante) para ejecutar la acción la recoge mediante el método GET ya que está embebida en la URL.

� RESETEAR:

Este conjunto de scripts son los encargados de proporcionar al Gestor un mecanismo de reseteo del sistema. En las figuras 18 y 19 se muestra, respectivamente, una imagen del aspecto visual de la página y el diagrama de flujo de la lógica asociada.

reset_form.php

Corresponde a la página HTML que contiene el formulario encargado de recoger el password del sistema para posteriormente enviárselo al script reset.php.

reset.php

Este script recoge el password del sistema enviado por la página anterior, y comprueba mediante una consulta a la Base de Datos si es correcto. En caso afirmativo, elimina todas las imágenes y thumbails existentes y vacía de la Base de Datos el contenido de las tablas: ‘usuario’,’imagenes’ y ‘relacion’, y restaura el password al valor inicial.

Interfaz de Gestión

Una vez descrita toda la estructura interna del módulo de Gestión, se pasa a ver los elementos de diseño empleados para desarrollar la interfaz de gestión. En el apartado anterior, se mostraron las capturas de pantalla de cada una de las páginas que componen dicha interfaz y que permiten al Gestor interaccionar con el sistema, pero no se indicó la estructura del diseño se las páginas, formatos, sistema de navegación entre las páginas, etc. A continuación se detallan estos elementos de diseño que se han empleado en el desarrollo de dichas páginas Web que conforman la interfaz de gestión.

Maquetación de las páginas

La maquetación Web consiste en la distribución de manera adecuada de los contenidos que forman una página Web. Existen varias técnicas para conseguir este objetivo: la maquetación tradicional y la maquetación con hojas de estilos.

En la maquetación tradicional, que se ha utilizado para estructurar el contenido del módulo de gestión, se utilizan las tablas para ajustar la posición de los elementos en la página

La estructura diseñada para contener cada uno de los elementos que forman las páginas de la interfaz de gestión es la que se describe a continuación, tal y como se muestra en la figura 20. Esta estructura está formada por una tabla de cinco filas, donde:

•

La primera fila (1), contiene la cabecera o dintel común a todas las páginas, y que muestra el título de la aplicación con un formato de texto y color de fondo definido.

•

La segunda y cuarta fila (1 y 4), contienen una línea de un píxel de alto con formato de imagen para dividir cada una de las secciones que componen las páginas.

•

La tercera fila (3), contiene el menú del sistema de navegación de la aplicación. Está formado por un mapa de imágenes donde cada área establece un enlace a una página distinta del sistema. Esta fila sólo aparece cuando el Gestor se ha autenticado correctamente.

•

La quinta fila (5), está formada por tres columnas, donde la primera y la tercera sirven para centrar el contenido de la segunda, ya que es la que contiene el cuerpo principal de las páginas; el cuál varía según la página actual donde se encuentre el Gestor. En la mayoría de los casos contiene los elementos de formulario de la aplicación.

Desarrollo del módulo de Provisión de Contenidos

Estructura interna

Como se comentó en capítulos anteriores, para el desarrollo de este módulo se ha adaptado un ejemplo de código JSRS que implementa un mecanismo asíncrono de llamadas a procedimiento remoto de manera oculta, esto es, que permite al cliente y servidor Web establecer una comunicación en segundo plano sin necesidad de recargar la página del cliente.

Componentes JSRS

El código JSRS está compuesto por una serie de funciones implementadas en un conjunto de librerías. Estas librerías pueden ser de dos tipos, según el lenguaje de programación empleado para su desarrollo: JavaScript, diseñada para ejecutarse en el cliente (navegador Web) y adopta el nombre de “jsrsClient.js”; y PHP, diseñadas para ejecutarse en el servidor y adoptan el nombre de “jsrsServer.php.inc” y “jsrsServer.inc”. Todas ellas deben ser incluidas en el programa principal para poder establecerse la comunicación en segundo plano entre cliente y servidor. La interrelación entre estos elementos se muestra en la figura 21.

El programa principal está compuesto por dos scripts: visor.htm que enlaza la librería jsrsClient.js y se ejecuta del lado del cliente; y visor_rs.php que incluye las librerías jsrsServer.php.inc y jsrsServer.inc y se ejecuta del lado del servidor. Entre ambos, existe un intercambio de información empaquetada con formato WDDX (estándar XML para el intercambio de información estructurada entre distintos lenguajes de programación), y que encapsula, entre otros, los datos almacenados en la Base de Datos del MDI.

SCRIPTS

A continuación se detallan los scripts que implementan el módulo de visualización del MDI.

visor.htm

Este script se ejecuta del lado del cliente. Se ha desarrollado con código HTML y CSS para implementar la interfaz de visualización, y JavaScript para implementar el mecanismo de diapositivas y comunicación asíncrona con el servidor (script visor_rs.php). El diagrama de flujo asociado puede verse en la figura 22.

Cuando el navegador carga por primera vez el script muestra por pantalla una imagen en negro, y al instante se inicia el bucle indefinido donde se solicita al script visor_rs.php el nombre y el tiempo de visualización de la siguiente imagen a mostrar mediante las funciones JSRS correspondientes. Tras obtener dicha información, muestra por pantalla la imagen y detiene la ejecución del programa durante el tiempo de visualización asociado; transcurrido ese tiempo, se vuelve a ejecutar del bucle.

El navegador elegido para la ejecución de este script es Opera v8.54, ya que es el único que realiza un fullscreen completo del contenido de la página. Otros como: Mozilla, Netscape o Internet Explorer, aunque tienen esta opción, incluyen barras o elementos flotantes en la pantalla.

visor_rs.php

Este script se ejecuta del lado del servidor, y se encarga de la secuenciación de contenidos, es decir, de proporcionar a visor.htm el nombre de una imagen y el tiempo de visualización asociado a la misma. Realiza consultas a la Base de Datos para extraer dicha información y hace uso de las librerías “jsrsServer.php.inc” y “jsrsServer.inc”, para establecer la comunicación en segundo plano con el script anterior. También implementa el mecanismo de selección de imágenes según: el número de usuarios detectados por el MDI y las imágenes mostradas con anterioridad. El diagrama de flujo asociado puede verse en la figura 23. Las figuras 24 y 25 detallan, respectivamente, la selección de usuarios y de imágenes de dicho diagrama.

El script llama a la función jsrsDispatch() para establecer la comunicación en segundo plano con el script visor.htm. Recibe la solicitud de consulta e inicia el mecanismo de selección de usuarios, los cuales deben haber sido detectados por el MDI y estar dados de alta en el mismo. En el supuesto de detectar varios usuarios, emplea el campo selec de la Base de Datos para determinar si los usuarios han sido seleccionados con anterioridad o no, y en el caso de encontrarse todos seleccionados se resetean los campos selec de la tabla ‘usuarios’ para iniciar un nuevo proceso de selección. Tras la selección de un usuario, lo marca como seleccionado y extrae su dirección MAC.

A continuación, inicia el mecanismo de selección de imágenes comprobando, previamente, que existen asociaciones de imágenes con la MAC obtenida. De la misma forma que con los usuarios, se emplea el campo view para detectar si la imagen se ha visualizado con anterioridad, y en caso negativo extrae de la Base de Datos el nombre y el tiempo de visualización correspondiente a la imagen seleccionada. Marca la imagen como visualizada y compone la cadena nombre_imagen*tiempo para ser retornada al script visor.htm mediante la función jsrsArrayToString().

En caso no cumplirse las premisas de selección de imágenes o usuarios, el script retorna mediante la función jsrsArrayToString() la cadena: “negro.jpg*1500”, que equivale a la imagen en negro mostrada durante un segundo y medio.

Interfaz de visualización

La interfaz de visualización se ha implementado en el script visor.htm usando código HTML para mostrar la imagen, y CSS para definir el estilo de la página.

Según el método de maquetación por hojas de estilo, se han definido dos capas #centrar y #contenido que establecen un centrado horizontal y vertical de la imagen en la pantalla, y en la etiqueta body se han suprimido los márgenes inferior y superior, y la barra de desplazamiento lateral del navegador, quedando un fondo negro con la imagen correspondiente en el centro.

En la figura 26 se muestra una captura de pantalla de la misma, donde aparece una imagen con menor resolución que la establecida en la pantalla.

Desarrollo del módulo de detección

Conceptos previos

En esta realización de la invención, se ha decidido emplear Bluetooth como método para la detección e identificación de usuarios. Cada usuario dado de alta en el sistema deberá portar un dispositivo personal con Bluetooth (e.g. un teléfono móvil). El MDI empleará la dirección MAC de ese dispositivo para identificar al usuario ante el sistema.

Estructura interna

La estructura interna del módulo de detección lo forma un programa o script principal desarrollado íntegramente con lenguaje compilado Java, el cuál contiene las sentencias, funciones y estructuras de control necesarias para implementar los objetivos de esta fase de desarrollo, que conviene recordar son: búsqueda de los dispositivos bluetooth próximos a la zona de cobertura, recuperar su nombre y su dirección MAC, e insertarlos en la BD (base de datos) del sistema. Estas operaciones deben repetirse de forma indefinida. La figura 27 muestra un diagrama de flujo de la lógica asociada.

APLICACIÓN INDUSTRIAL

La aplicación del marco de fotos digital personalizable por medio de identificación de usuarios se deriva de forma evidente de la descripción de la invención. Aporta un valor añadido en cuanto a flexibilidad y economía de espacio y recursos frente a los marcos de fotos tradicionales, y aporta un nivel adicional de personalización de contenidos sobre los marcos digitales existentes en el mercado al permitir la identificación de los usuarios y la adaptación de los contenidos en base a la presencia de determinados usuarios y a sus preferencias.

De forma adicional, la concepción modular de la invención puede permitir el despliegue de la misma de forma distribuida, es decir, desplegando los diferentes módulos mediante distintos dispositivos conectados entre sí por medio de una red, lo que abre posibilidades en el campo de la domótica. Como caso particular, cabe plantearse el uso de MDI como subsistemas de interfaz personalizable para sistemas domóticos más complejos. En el caso de que una vivienda estuviera automatizada mediante un sistema domótico centralizado con un controlador principal, y éste reuniese las especificaciones software/hardware impuestas por el MDI, entonces podrían distribuirse por cada una de las estancias dispositivos MDI que mostrasen las imágenes de aquellos usuarios detectados de forma individual, estableciendo una comunicación con la Base de Datos y el servidor Web integrados en dicho controlador domótico. Un ejemplo de esta posibilidad se muestra en la figura 5.1.

Claims (10)

1. REIVINDICACIONES

   1.

   Marco digital multimedia personalizable por medio de identificación de usuarios, que comprende un dispositivo capaz de mostrar en una pantalla, sucesiones de imágenes o fragmentos de video asociadas a uno o varios usuarios registrados en el dispositivo, atendiendo a un mecanismo de detección de presencia e identificación de usuarios.

2. 2.

   Marco digital multimedia personalizable por medio de identificación de usuarios según reivindicación 1, que comprende los elementos hardware y software necesarios para mostrar al usuario contenidos con sonido.

3. 3.

   Marco digital multimedia personalizable por medio de identificación de usuarios según cualquiera de las reivindicaciones anteriores, que comprende un sistema de gestión que permite administrar la información referente a usuarios y contenidos dados de alta en el dispositivo, así como configurar las preferencias de los diferentes usuarios en relación con la presentación de contenidos.

4. 4.

   Marco digital multimedia personalizable por medio de identificación de usuarios según cualquiera de las reivindicaciones anteriores, que comprende mecanismos de identificación de usuarios mediante detección de dispositivos Bluetooth.

5. 5.

   Marco digital multimedia personalizable por medio de identificación de usuarios según cualquiera de las reivindicaciones anteriores, que comprende mecanismos de identificación de usuarios mediante detección de dispositivos WiFi.

6. 6.

   Marco digital multimedia personalizable por medio de identificación de usuarios según cualquiera de las reivindicaciones anteriores, que comprende mecanismos de identificación de usuarios mediante tags RFID.

7. 7.

   Marco de fotos digital personalizable por medio de identificación de usuarios según cualquiera de las reivindicaciones anteriores, que comprende mecanismos de identificación de usuarios mediante técnicas biométricas.

8. 8.

   Marco digital multimedia personalizable por medio de identificación de usuarios según cualquiera de las reivindicaciones anteriores, que comprende los elementos hardware y software necesarios para almacenar los contenidos que han de mostrarse a los usuarios en uno o varios servidores remotos de ficheros o de medios.

9. 9.

   Marco digital multimedia personalizable por medio de identificación de usuarios según cualquiera de las reivindicaciones anteriores, que comprende dispositivos adicionales de interfaz y de detección distribuidos, de forma que puedan servirse los contenidos multimedia asociados a los usuarios en diferentes dispositivos de interfaz situados en diferentes ubicaciones de forma simultánea en función de la localización de los diferentes usuarios dados de alta en el sistema.

   GESTOR

   CU-004CU-003 CU-001 CU-002 CU-005 CU-007 CU-006 CU-008 CU-010 CU-011 <<extends>> <<extends>> <<include>>

   CU-009 <<include>>

   MARCO DIGITAL

   USUARIO

   Figura 1

   ES 2 402 005 Bl

   MBD

   GESTOR

   MG

   USUARIO

   MPC

   Figura 2

   Figura 3

   ES 2 402 005 Bl

   NO

   Figura 4

   Figura 5

   ES 2 402 005 Bl

   cambiar_passwd_form.php: Envía password actual y el nuevo duplicado

   Llama a la función

   correcto()

   Figura 6

   Figura 7

   ES 2 402 005 Bl

   anadir_usuario_form.php: Envía nombre y MAC, como una cadena con formato: ”nombre/MAC”

   Figura 8

   Figura 9

   ES 2 402 005 Bl

   Figura 10

   Figura 11

   ES 2 402 005 Bl

   asociar_form.php: Envía las asociaciones

   Llama a la función correcto()

   Figura 12

   Figura 13

   ES 2 402 005 Bl

   .

   Figura 14

   Figura 15

   consultar_img.php ó consultar_user.php: Envían identificadores

   Redirige a la página donde se realizó la petición

   Figura 16

   ES 2 402 005 Bl

   Figura 17

   Figura 18

   Llama a la función

   correcto ()

   Figura 19

   1

   2

   3

   4

   5

   Figura 20

   Figura 21

   Llamada a la función

   jsrsExecute()

   Llamada a la función

   myCallback()

   Muestra imagen

   Figura 22

   Figura 23

   Figura 24

   ES 2 402 005 Bl

   Figura 25

   Figura 26

   Figura 28

   OFICINA ESPAÑOLA DE PATENTES Y MARCAS

   N.º solicitud: 201131275

   ESPAÑA

   Fecha de presentación de la solicitud: 26.07.2011

   Fecha de prioridad:

   INFORME SOBRE EL ESTADO DE LA TECNICA

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

   DOCUMENTOS RELEVANTES

   Categoría

   56 Documentos citados Reivindicaciones afectadas

   X

   US 2006170669 A1 (WALKER JAY S et al.) 03.08.2006, 1-8

   resumen; figura 1; párrafos [0055],[0085-0097].

   Y

   9

   X

   US 2011102444 A1 (MATSUMOTO TOMOKO) 05.05.2011, 1-8

   resumen; figuras 1-2; párrafos [0015],[0043-0088].

   Y

   US 7796190 B2 (AT&T LABS, INC.) 14.09.2010, 9

   columna 1, línea 55 – columna 2, línea 15; columna 3, línea 62 – columna 10, línea 7.

   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 24.09.2013

   Examinador M. Rivas Sáiz Página 1/4

   INFORME DEL ESTADO DE LA TÉCNICA

   Nº de solicitud: 201131275

   Documentación mínima buscada (sistema de clasificación seguido de los símbolos de clasificación) H04N 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

   Informe del Estado de la Técnica Página 2/4

   OPINIÓN ESCRITA

   Nº de solicitud: 201131275

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

   Declaración

   Novedad (Art. 6.1 LP 11/1986)

   Reivindicaciones Reivindicaciones 4,5,9 1-3, 6-8 SI NO

   Actividad inventiva (Art. 8.1 LP11/1986)

   Reivindicaciones Reivindicaciones 4,5,9 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.

   Informe del Estado de la Técnica Página 3/4

   OPINIÓN ESCRITA

   Nº de solicitud: 201131275

   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

   US 2006170669 A1 (WALKER JAY S et al.) 03.08.2006

   D02

   US 7796190 B2 (AT&T LABS, INC.) 14.09.2010

10. 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

    El documento D01 se considera el más próximo del estado de la técnica a la invención solicitada. Con relación a la reivindicación 1, D01 describe un marco digital multimedia personalizable por medio de la identificación de usuarios (resumen)., Comprende un dispositivo capaz de mostrar en una pantalla (figura 1), sucesiones de imágenes o fragmentos de video asociadas a uno o varios usuarios registrados en el dispositivo atendiendo a un mecanismo de detección de presencia e identificación de usuarios (párrafos 0088 a 0092). Por tanto, la reivindicación 1 no es nueva (Artículo 6 LP.).

    El documento D01 comprende los elementos hardware y software necesarios para mostrar al usuario contenidos con sonido. Desde el punto de vista hardware dispone de una pantalla, un altavoz y procesador y en el párrafo 0085 se describe que muestra flujo de vídeo. Por consiguiente, la reivindicación 2 tampoco es nueva (Artículo 6 LP.). Con relación a la reivindicación 3, D01 divulga un sistema de gestión que permite administrar la información referente a usuarios y contenidos dados de alta en el dispositivo (párrafo 0088), así como configurar las preferencias de los diferentes usuarios en relación con la presentación de contenidos (párrafo 0094). En consecuencia, la reivindicación 3 carece de novedad (Artículo 6 LP.).

    En D01 la identificación de usuarios propuesto es mediante tags RFID (párrafo 0088) y también mediante técnicas biométricas (párrafo 0089) por lo que las reivindicaciones 6 y 7 no son nuevas (Artículo 6 LP.).

    Con respecto a las reivindicaciones 4 y 5 cabe indicar que se utiliza para identificar al usuario la detección de dispositivos WiFi y Bluetooth. Estas técnicas no están recogidas en D01 pero son técnicas habituales para identificar usuarios y por tanto, su mera aplicación no dota de actividad inventiva a las reivindicaciones. Por tanto las reivindicaciones 4 y 5 no implican actividad inventiva (Artículo 8 LP.).

    La reivindicación 8 está anticipada en D01 en el párrafo 0055 donde el marco digital comprende los elementos hardware y software necesarios para almacenar los contenidos que han de mostrarse a los usuarios en uno o varios servidores remotos de ficheros o de medios y en consecuencia carece de novedad (Artículo 6 LP.).

    Con relación a la reivindicación 9, el documento D01 no dispone de dispositivos adicionales de interfaz y de detección distribuidos, de forma que puedan servirse los contenidos multimedia asociados a los usuarios en diferentes dispositivos de interfaz situados en diferentes ubicaciones de forma simultánea en función de la localización de los diferentes usuarios dados de alta en el sistema. El efecto técnico de esta diferencia es mostrar contenidos diferentes en distintos dispositivos en función de la ubicación de cada usuario. El problema técnico es como servir los contenidos a usuarios diferentes de manera simultánea. El documento D02 resuelve el problema anterior (columna 9 línea 62 a columna 10 línea 7) donde distintos dispositivo, uno de ellos por ejemplo un marco digital, ofrecen contenido diferente en función de las preferencias del usuario localizado en la habitación. Por tanto, un experto en la materia combinaría las características descritas en D01 con el problema resuelto por D02 para obtener la reivindicación 9 sin hacer uso de la actividad inventiva y por tanto, la reivindicación 9 no implica actividad inventiva (Artículo 8 LP.).

    Informe del Estado de la Técnica Página 4/4