ES2402005B1 - CUSTOMIZABLE MULTIMEDIA DIGITAL FRAMEWORK BY USER IDENTIFICATION - Google Patents

Abstract

The customizable multimedia digital frame by means of user identification comprises a device capable of displaying in a screen, as a presentation successions of multimedia contents associated with one or more users registered in the device, attending to a presence detection and identification mechanism of users. Through this mechanism, the device determines which users are in the vicinity of the framework and adapts the presentation of content to the preferences of said users. It also includes a management system that allows managing information regarding users and content registered on the device, as well as setting the preferences of different users in relation to the presentation of content. This allows, among other things, to customize the home automation environment and other intelligent environments based on the preferences of the users that are in the environment at all times.

Description

Customizable multimedia digital framework through user identification

SECTOR OF THE TECHNIQUE

This invention falls within the systems of personalization of services for the user in intelligent environments (home automation, inmotic, urbotic, ...), and specifically within the systems for the presentation of successions of multimedia content to users, whose The main exponent today are digital photo frames.

STATE OF THE TECHNIQUE

This chapter describes the background of the invention, both in the general field of personalization of services and in the more specific field of digital photo frames.

Personalization of digital home services

The customization of systems and services is not something new. In fact, most of the work carried out by user agents is focused on the configuration of a software system according to their preferences. These agents can be completely personal, as described in [Müller, H., Hilbrich, T. and Kühnel, R., An Asistant Agent. Fundamenta Informaticae 34, pp1-10, 1999] or adaptable to each user who accesses the system, as in [Pazzani, M.J. and Billsus, D., Adaptive Web Site agents. Autonomous Agents and Multiagent Systems, 5, pp. 205-218, 2002].

Although it is possible to customize the services that a user accesses in any of the surrounding environments, the digital home is undoubtedly the one in which the effect they produce is most closely felt. This does not mean that access to systems and services cannot be customized at work, which is undoubtedly done, but that it is at home when the user feels more likely to enjoy the systems that make him or her the most comfortable life, and therefore, the most studied environment.

In recent years, the concepts of Digital, home automation and home automation home [Lorente, S. and Medina, J.J. The White Book of the Digital Home. Official College of Telecommunications Technical Engineers, 2004]. Until very recently, the digital home has been confused with home automation and has been seen, almost exclusively, as a system, rarely global and usually disaggregated, for controlling various devices in homes and in business environments; fundamentally: sensors, controllers and some appliance.

At the same time, we have endowed our homes with an increasing number of devices: several television sets, several stereo systems, one or several computers, movie recording / playback devices, such as video and DVD, security systems, etc. The number of appliances (from large appliances to small devices) per square meter increases without stopping, which does not mean that our quality of life improves. We have access to more products and services, but at the cost of an increase in complexity in their non-negligible use. For example, in the same way that the number of devices grows, the number of remote controls grows with them. Also, new appliances begin to appear capable of offering multimedia content from a central system.

Finally, in recent years, service personalization architectures have begun to appear that seek to address the problem in a more global way. The objective is to personalize the environment in which the users of a home are located (or, in a broader sense, of a vital space, since most of the ideas that we can apply to the digital home, can be moved to the place of work, to the vehicle, or even to public spaces). The concept of Environmental Intelligence extends the fields of application of technology: it is no longer just a domestic environment, but also includes new spaces: cars, public spaces (airports, stations, highways, etc.). ), service areas (hotels, shopping centers, etc.) and others. However, although many of these architectures have promising results in terms of personalization of services [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., and Velasco, J., “A hierarchical, agent-based service oriented architecture for smart environments”, in Service Oriented Computing and Applications, 2 (4): 167–185 , 2008], the high complexity and high cost of existing solutions means that they are not yet a real possibility for the personalization of services in our homes.

Digital photo frame

At present, we can see digital frames in a multitude of specialized stores. A digital frame is nothing more than a device for homes capable of displaying on a screen, generally LCD (liquid crystal display), a set of images selected by one or several people. Its basic operation consists in providing a succession of the photographs stored in the device as a slide show. This type of device aims to replace the traditional photo frame, on which it provides a greater use of space (the same digital photo frame allows the visualization of a set of photographs) and a saving of resources (photographic paper), in addition to adding certain dynamism to the environment where it is integrated. In some cases, digital photo frames are not only limited to reproducing images, but are also prepared to reproduce video and audio. Virtually all models provide the same services; The main differences between them will be marked by the size of the screen and the features they have. As examples of these features, we can mention the screen resolution, the consumption and the mechanisms available for the transfer or storage of images, which can range from USB ports to Internet connectivity.

Technological advances in the world of photography, the possibility of storing data in smaller and smaller media, and the low price compared to the possibilities they offer, have helped make digital frames increasingly demanded. It can be said that since its origins in the market, about four years ago, the number of sales has increased considerably. However, none of the existing models provide automatic dynamic customization of the services it provides. The set of audiovisual content that is shown to users only changes by manual configuration, and does not respond to the presence or not of users in the immediate vicinity of the device.

DESCRIPTION

The main objective of the invention is to develop a system capable of generating a multi-user, customizable and intelligent multimedia environment. Each user can customize this environment by providing the system with a set of preferred contents and configuration parameters. Using this information and presence detection and user identification mechanisms, the system will determine completely independently how it should behave, acting as an Intelligent Digital Framework (hereinafter, MDI).

This section describes the Intelligent Digital Framework from a functional point of view. It begins by defining the tasks or specification of requirements and user roles through a diagram of Use Cases following the UML notation (Unified Modeling Language). The representation of a generic block diagram is also used, showing the modules in which the MDI is divided in order to diversify functionalities and define development areas, which will facilitate its implementation and elaboration.

Device Use Cases

The following describes the functionality of the Intelligent Digital Framework through Use Cases, which provides a perspective of the problem that the device solves from the user's point of view. The corresponding use case diagram can be seen in Figure 1.

CU-001: Authentication: the MDI verifies the identity of the manager and / or the user by allowing them to access the system. In the case of the manager, to perform any information management operation of the MDI, and in the case of the user being able to view its associated contents. If these identities are wrong, the MDI denies access. The identity verification of the user will be carried out by means of an identification credential, which will depend on the identification mechanism used (e.g. a password, an RFID (Radio Frequency Identification), a fingerprint ...).

CU-002: Change credentials: the manager can modify his identification credentials or those of any other user. The MDI will inform the manager through a message on the management interface if the order was executed successfully or not.

CU-003: Operate with contents: the manager accesses the MDI to execute operations related to multimedia content. Examples of such operations can be: consult existing content, add content to the system, associate a content with a user, delete content, undo user content association.

CU-004: Operate with users: the manager accesses the MDI to execute operations related to the users. Examples of such operations can be: consultation of the users registered in the system, adding users to the system, eliminating users from the system, associating a user with one or more contents, eliminating user-content association.

CU-005: Consult: there are two types of queries. In the case of “Operate with contents”, the MDI will provide the manager with an extract of the information stored about the contents registered in the device. And in the case of “Operate with users”, the MDI will provide the manager with an extract of the information stored about the users registered in the device.

CU-006: Add: The manager can add content and users to the system. In the case of “Operate with contents”, the manager can add contents to the system, and the MDI will adapt the characteristics of the same (eg size and image quality) according to the specifications of the screen where they will be displayed, thus optimizing the storage space. And in the case of "Operate with users", the manager can register new users to the system. In both cases, the MDI notifies the manager if the action was successful or not.

CU-007: Delete: The manager can unsubscribe users, delete content or undo user associations permanently contained in the MDI at any time.

CU-008: Associate: The manager associates existing contents in the system with users registered in it. In this association, the content of the corresponding content in the user interface must be indicated for each content and user. The MDI notifies the manager if the action was successful or not.

CU-009: Reset: The manager deletes all types of information: content, users, associations, ... that has been inserted in the MDI. Returning the system to an initial empty state.

CU-010: Detect presence: The system must constantly search for presence of users within the detection area, in accordance with the identification mechanism used (e.g. RFID, Bluetooth, fingerprint ...). With this, it allows the detected users to receive their associated contents in the user interface.

CU-011: Selection and visualization of contents: The MDI shows through the user interface the contents associated to the user or users detected as a slide according to the display time of each of them. If more than one user has been identified, the MDI will show contents alternately of one and the other following the order of access to the system. If no presence has been detected, the user interface will display default contents, or will remain in a low power state, as configured.

Generic Block Diagram

In this section the components that make up the system object of this invention are described graphically and globally from a logical point of view.

A modular system consisting of three main operating modules and a database is shown in Figure 2. These modules are independent of each other and each one encapsulates a series of tasks and functionalities that differentiate them from the rest, the database being the only link between them. This database will house all the information that is handled in the system, and must manage the requests for sending or receiving data originated by the modules.

Management Module (MG)

The management module is responsible for managing all the information that enters the MDI and its configuration. It communicates with the Manager through the management interface program and with the database through the management logic.

The management interface (IG) is responsible for providing the manager with a visual and intuitive setting and management of the MDI, allowing him to navigate and operate on each of the system's functionalities.

Management logic (LG) is a subsystem that interacts with the management interface and with the database. It receives the information and messages from the management interface to determine the actions to be executed, and sends the data to the database for storage. He is also in charge of making the queries to the database and providing the results to the management interface.

The tasks or actions that the management module must encapsulate for its subsequent implementation within the development of the MDI, correspond to the Use Cases: from CU-001 to CU-009.

Content Provision Module (MPC)

The content provision module is responsible for providing content to users, following a previous configuration of the MDI. This mechanism is carried out through two elements: content provisioning interface and content provisioning logic.

The content provisioning interface (IPC) is responsible for displaying the corresponding contents to users (e.g. image or video on screen, sound through speakers, ...). The contents are displayed for a defined time, as specified by the display time parameter corresponding to said contents and users. The following premises must be met for the content provisioning interface to serve content to users:

•

Users must have been detected within the MDI coverage area, and be registered in the system.

•

There must be content in the MDI and these must be associated with the users. The same content can be assigned to several users, or vice versa.

The content provisioning logic (LPC) is the subsystem responsible for selecting and providing the content provisioning interface with the contents and values of the configuration parameters of each of them.

The tasks to be performed by this module correspond to the use case specification: CU-010.

Identification and Detection Module (MID)

This module is responsible for detecting the proximity of a user to the MDI in a given detection area and to identify said user. The hardware detection and identification mechanisms, as well as the detection area, will depend on the specific technology used. Among the different possible technologies for the detection and identification of users we can mention, by way of example and without excluding others, RFID, NFC (Near Field Communication), Bluetooth, WiFi or biometric techniques.

Identification and detection logic (LID) is the subsystem responsible for making use of identification and detection hardware to detect the presence of users within the detection area. If so, the logic collects the identifiers of the users and authenticates them in the MDI by sending said identifiers to the database. The system can be configured to display default content or not to display any content if no user has been detected.

The tasks to be carried out by this module have been specified in the Use Case: CU-011.

Database Module (MBD)

The database is a crucial element of the system object of the invention, since it is responsible for storing all the information that is generated in the MDI, and serves as a link between all modules. This information can be stored in different ways (e.g. in an organized way following a relational model, where "tables" and "records" are the elements that make up its structure), and in different locations

(e.g. a hard drive on the device itself, an external server, ...).

Access to this information is managed by the DBMS (Database Management System), whose objective is to serve as an interface between the data and the other modules. The modules must make requests for consultation or writing to the DBMS, and the latter is responsible for executing them, extracting or inserting in the database the information that has been requested. One of the most important characteristics of the DBMS is that it solves the cases of concurrence of access to the data by two or more modules, which allows maintaining their integrity.

DESCRIPTION OF THE DRAWINGS

To complement the description that is being made and in order to help a better understanding of the features of the invention, as well as to provide greater detail in the preferred example of practical realization thereof, it is accompanied as an integral part of this description a set of drawings where, for illustrative and non-limiting purposes, the following has been represented:

• Figure 1 - Diagram of Cases of Use of the Digital Framework system: the diagram of Cases of Use of the MD is shown, representing how users with different roles operate on the MD. The diagram consists of three elements: actors, are the different roles that users can adopt and trigger actions; Use Cases, are the specific tasks that are performed after the order of an actor; and the relations between both. There may also be relationships between Use Cases, and these can be of two types:

a) Relationship type <<include>>: indicates that each invocation of the Base Use Case will in turn invoke the case that is “included”.

b) Relationship type <<extends>>: indicates that each invocation of the Base Use Case can start another within it.

•

Figure 2 - Generic block diagram: a modular system consisting of three main operating modules and a database is shown. These modules are independent of each other and each one encapsulates a series of tasks and functionalities that differentiate them from the rest, the database being the only link between them. This database will house all the information that is handled in the system, and must manage the requests for sending or receiving data originated by the modules.

•

Figure 3 - Management system access screen: Shows the aspect of the management interface in the embodiment of the invention when trying to access the management interface.

•

Figure 4 - Flowchart of the access logic to the management system: Shows the flowchart of the verification of access credentials to the management interface.

•

Figure 5 - Change of management password screen: Shows the appearance of the management interface in the embodiment of the invention when trying to change the management interface password.

•

Figure 6 - Flowchart of the management password change logic: Shows the flowchart of the password change for the management interface.

•

Figure 7 - User addition screen: Shows the aspect of the management interface in the embodiment of the invention when trying to add users to the system.

•

Figure 8 - Flowchart of user addition logic: Shows the flowchart of user addition.

•

Figure 9 - Image addition screen: Shows the aspect of the management interface in the embodiment of the invention when trying to add images to the system.

•

Figure 10 - Flowchart of the image addition logic: Shows the flowchart of the image addition.

•

Figure 11 - User image association screen: Shows the aspect of the management interface in the embodiment of the invention when trying to associate images with users.

•

Figure 12 - Flowchart of the association of images to users logic: Shows the flowchart of the association of images to users.

•

Figure 13 - Image query screen: Shows the aspect of the management interface in the example of embodiment of the invention when querying images.

•

Figure 14 - Flowchart of the image query logic: Shows the flowchart of the image query.

•

Figure 15 - User query screen: Shows the aspect of the management interface in the example of realization of the invention when user queries are made.

•

Figure 16 - Disassociation logic flowchart: Shows the flowchart associated with the elimination of associations between users and images.

•

Figure 17 - Flowchart of user and image deletion logic: Shows the flowchart associated with the removal of users and images.

•

Figure 18 - Return to factory configuration screen: Shows the appearance of the management interface in the example of embodiment of the invention when trying to reset the device to its factory configuration.

•

Figure 19 - Flowchart of the logic of return to factory settings: Shows the flowchart of the return to factory settings.

•

Figure 20 - Structure of the pages of the management interface: Shows the arrangement of the different elements that make up the pages of the management interface.

•

Figure 21 - JSRS interaction scheme (JavaScript Remote Scripting, Remote JavaScript Instructions): Shows the relationship between the different JSRS elements to support the content provision module.

•

Figure 22 - JSRS client side flow chart: Shows the JSRS client side flow chart in the content provisioning module.

•

Figure 23 - Flowchart of content sequencing: Shows the flowchart of the content sequencing process in content provisioning module.

•

Figure 24 - Flowchart of user selection: Shows the flowchart of the user selection process referred to in Figure 23.

•

Figure 25 - Image selection flowchart: Shows the flowchart of the image selection process referred to in Figure 23.

•

Figure 26 - Content provisioning interface screen: Shows the appearance of the content provisioning interface in the embodiment of the invention when trying to display an image of a size smaller than the screen resolution.

•

Figure 27 - Flowchart of the detection logic: Shows the flowchart of the process of detection and identification of users.

•

Figure 28 - Integration of the MDI system in a centralized home automation system: It shows an example of distributed deployment of MDIs for a centralized environment, so that the media can be shown to different users through different screens distributed throughout the home.

MODE OF REALIZATION

This chapter describes in detail the implementation of a preferred and non-exclusive embodiment of the invention. In this embodiment of the invention, the use of a hardware support based on a built-in PC with a Linux operating system has been chosen, and the use of Bluetooth as a mechanism for detecting and identifying users through their mobile phones or similar devices. The multimedia contents that have been chosen for this embodiment of the invention are still images that are presented as slides, so that for the service provisioning interface, an LCD screen has been chosen.

This chapter has been divided into four sections, according to the modules that comprise the

embodiment of the invention. The purpose of each of these four sections is briefly summarized below, and

The technologies used in the corresponding module are listed:

1. Design and structure of the Database.

This section defines the structure of the database and its components: tables, fields and relationships between the tables. As stated in the previous chapter, the database will house all the MDI information, so each of the fields must correspond to a type of information managed by the system. In this embodiment of the invention the MySQL database management system has been used, since it is one of the most widespread at the moment, it is available for the different platforms, it is fast and easy to use. To manage MySQL, the Web tool PhpMyAdmin is used.

2. Development of the management module.

This section describes the implementation of all the programs and interfaces that allow the manager to manage the MDI. For the implementation of this module, Web technologies have been used following a client-server architecture, which allows the manager to access the MDI via remote (via WiFi or Ethernet) through a Web browser. In this case, the client corresponds to a Web browser that will serve as a tool for the manager to communicate with the MDI, and as a server, the most widespread Web server at the moment, Apache. The Presentation Layer is developed with HTML and JavaScript code, and the Business Layer with PHP language in its entirety, creating a program or script for each action that the manager wishes to execute. Both HTML-JavaScript and PHP code reside on the Apache Web server. The reason for choosing these technologies is because they are the most widespread and appropriate for these types of applications, and are free to use.

3. Development of the content provision module.

This section describes the implementation of the display mechanism that allows users to view their images. For the implementation of this module, the JSRS Web development technique is used based on a client-server architecture, which allows asynchronous background communication between the client and the server without the need for the client to reload the page. The user interface is implemented with HTML and JavaScript code, using the Opera Web browser as the execution framework for said code, and using the PHP programming language on the server side; As in the previous phase, both codes reside on the Apache Web server.

4. Development of the detection module.

This section describes the implementation of the mechanism responsible for detecting the presence of users in a limited range of coverage. The hardware technology used is Bluetooth, which allows devices to be found at a distance of up to 10 meters. This technology has been chosen because today all mobile phones are equipped with Bluetooth and it does not imply that the user has to purchase any other type of accessory or additional device to interact with the system. As the user credential, therefore, the MAC address of your Bluetooth device will be used. As for the software implementation, it must be said that the Java programming language is used accompanied by the set of Java Bluecove libraries, which contain all the functions defined in the JSR-82 specification, responsible for defining the set of APIs ( Application Programming Interfaces, which generate the environment of

5 development for Bluetooth wireless technology. The JDBC API (Java Database Connection, Java Database Connection) is also used to execute SQL instructions (Structured Query Language) to access the contents of the MySQL database designed in the Data Layer .

Design and structure of the database

10 Structure of the tables

The structure presented in this section is that necessary for the preferred embodiment of the invention.

described in this chapter, and should be adapted for any other embodiment of the invention, according to its

particular characterisitics.

� LOGIN:

15 As the objective is the development of a Web application for the management of the Digital Framework and it will have restricted access to the data, a table will be needed to store the access information: password. The ‘log’ table contains this information.

LOGIN

Field Name

Field type Field description

passwd

 varchar (40) Password of the manager coded in MD5 (PK)

� USERS: Information regarding the users registered in the Digital Framework will be stored in the ‘users’ table.

USERS

Field Name

Field type Field description

mac

 varchar (17) MAC address of the user's bluetooth device (PK)

Name

 varchar (30) user's bluetooth device name

selected

 tinyint (1) selection indicator (default value “0”)

The selected field indicates whether images of the corresponding user have been displayed or not. It is used to set the image display sequence in case there are two or more users detected in the system.

� USERS_DETECTED:

The table ‘detected_ users’ stores the information corresponding to the users that have been detected by the system, and who may or may not be registered.

USERS_DETECTED

Field Name

Field type Field description

mac

 varchar (17) MAC address of the user's bluetooth device (PK)

Name

 varchar (30) user's bluetooth device name

� IMAGES: The information regarding the images stored in the Digital Framework are contained in the ‘images’ table.

Field Name

IMAGES Field Type Field description

Picture_id

 bigint (11) Primary key (PK) (auto_increment, default “NULL”)

Name

 varchar (30) name and format assigned to the image

tamanyo

float size in bytes that each disk image occupies

accountant

bigint (11) Display Counter

The counter field stores the number of times the corresponding image has been displayed per screen.

� RELATIONSHIP:

In this ‘relation’ table, the associations established between the users registered in the ‘users’ table and the images registered in the ‘images’ table will be stored.

RELATIONSHIP

Field Name

Field type Field description

Picture_id

 bigint (11) Primary key (PK) (auto_increment, default “NULL”)

mac

 varchar (17) MAC address of the user's bluetooth device (PK)

weather

 varchar (6) size in bytes that each disk image occupies

view

 tinyint (1) selection indicator (default value “0”)

In this case, there is a primary key composed of the image_id field corresponding to the ‘images’ table and the mac field corresponding to the ‘users’ table. This primary key is unique and cannot be repeated throughout the table. The view field indicates if the image has been displayed, it is used to set the sequence of display of the images of a particular user.

Management module development

Internal structure

The realization of the internal structure of the management module has been based on the client server architecture, where the client (Web browser) will execute HTML and / or JavaScript code and the server will use PHP scripts. These scripts are command files stored in plain text that will be interpreted by the PHP engine hosted on the Apache Web server. When the client makes a request for a PHP page or script, the Web server will be responsible for executing it, processing it and generating the corresponding HTML code to send it in response to the browser. In the scripts in which it is required, PHP will access the MySQL database to perform the appropriate operations (insertion, update or deletion of records) or to consult its data.

SCRIPTS

• AUTHENTICATION:

Authentication is the mechanism that allows the Manager to access the system, and consists of a form implemented in HTML to collect the management password and two PHP scripts:

index.php:

It is the initial page of the Web application, as shown in Figure 3. It is developed entirely with HTML code and contains the form that collects the access password to the management system, and sends it to the script valid_user.php to its validation

valid_user.php:

It is the script responsible for validating the management password. To do this, collect the password sent by the form and compare it with the one stored in the Database. If they are equal, it creates a session and a session variable initialized with the corresponding SID (Session Identifier), and allows navigation through the pages of the Web application, otherwise it does not create any session and redirects to the index.php page. Figure 4 shows a flow chart of said logic.

• CHANGE PASSWORD:

It provides the Manager with the functionality to change the password at any time. It is implemented through an HTML form for data collection and a PHP script:

change_passwd_form.php

It contains the form to collect the current and new password to send to the script change_passwd.php. The new password is requested in duplicate to ensure that there are no errors in writing. Figures 5 and 6 respectively show an image of the visual appearance of the page and the flow chart of the associated logic.

change_passwd.php

The actions carried out in this script are the following:

one.

Collect the three fields sent by the previous page and extract the password value from the Database.

2.

Check that the three fields are not empty.

3.

Evaluate that it is the same as the first field.

Four.

Compare the second and third fields belonging to the new password in duplicate.

5.

Update the ‘log’ table of the Database with the new password.

• ADD USERS:

This set of scripts are responsible for registering users in the MDI. Figures 7 and 8 respectively show an image of the visual appearance of the page and the flow chart of the associated logic.

anadir_user_form.php

It contains the form that collects user registration data and sends it to the script anadir_usuario.php to be processed. It is developed in HTML but part of that code is created dynamically using PHP. This is because to show the list of detected users, you need to access the ‘detected_ users’ table in the Database.

anadir_usuario.php

This script is responsible for collecting the information corresponding to users with the following string format: "name / MAC", and inserts them into the Database. Before performing this last action, evaluate if any option has been selected. In the case of registering a user who was already registered in the system with the same MAC but with a different name, only update the field ‘name’ of the table ‘users’ of the Database.

• ADD IMAGES:

This set of scripts allows adding images to the MDI. The allowed formats are .jpeg or .gif, the maximum size of an image being 5MB. Figures 9 and 10 respectively show an image of the visual appearance of the page and the flow chart of the associated logic.

upload_form.php

It contains the form by which the Manager can enter images into the system. It collects the name and format of up to four images at once and sends them to the upload.php script to process them.

upload.php

This script collects the images sent by the previous page and performs the following actions on them:

one.

Evaluate if any image has been selected, if the format is correct, and if other images with the same name exist in the system.

2.

It stores them in the corresponding directory.

3.

It adapts the images to the resolution of the screen where they are going to be displayed without the quality being affected, only, in the case that these images have a resolution higher than the screen. Otherwise it maintains the original format.

Four.

Create the thumbails (reduced images) of each of them.

5.

Insert in the Database all the information referring to them (name and size).

• ASSOCIATE:

This set of scripts is responsible for establishing relationships between users and images. The method is to associate a user with the desired images, assigning a viewing time to each of them. Figures 11 and 12 respectively show an image of the visual appearance of the page and the flow chart of the associated logic.

associate_form.php

It provides the corresponding form so that the Manager can establish the associations. This page is dynamically generated using PHP code, since you need to display all registered users and all images, stored in the Database. Once the Manager has made his association, it will be sent to the script associater.php to include it in the Database.

associater.php

This script collects the data related to the association: user identifier (MAC), the identifiers of the images and their display times. If the options were selected correctly, the script inserts a new entry in the ‘relations’ table of the database, and if the relationship already exists, it would update the display time.

� CONSULT:

This set of scripts is responsible for consulting the content of the system through access to the Database and showing them to the Manager in a structured way. There are two query options: images or users.

query_img.php

This script is responsible for collecting all the information associated with the images (name, size, number of visualizations and associated users) existing in the system by accessing the Database, structuring it in a table and dynamically generating the HTML code corresponding to the page that the Manager will display. In this case, there is no form element, so this script does not receive any information from outside. This script also provides for each of the images the links to the scripts delete.php and desasociar.php which we will analyze their functionalities in the following section.

Figures 13 and 14 respectively show an image of the visual appearance of the page and the flow chart of the associated logic.

query_user.php

This script is responsible for collecting all the information associated with the users registered in the system (name, MAC address and associated images). At the implementation level it is exactly the same as the previous script but it differs that instead of dealing with images it deals with users. Therefore the flowchart and the code are very similar. An image of the visual appearance of the page is shown in Figure 15.

� DELETE:

As you can see in the previous section, both scripts contain links to desasociar.php and delete.php, this allows the possibility of deleting information from the system. Figures 16 and 17 show, respectively, the flowcharts of the associated logic.

desasociar.php

The mission of this script is to delete records from the ‘relations’ table in the Database. It collects through the POST method the information (user and image identifier, and requesting page) sent by any of the two scripts of the previous section and executes the deletion order on the Database.

remove.php

This script is responsible for deleting users or deleting images from the system. Depending on the page you call you will do one thing or another. The necessary information (user or image identifier, and requesting page) to execute the action is collected by the GET method since it is embedded in the URL.

� RESET:

This set of scripts are responsible for providing the Manager with a system reset mechanism. Figures 18 and 19 respectively show an image of the visual appearance of the page and the flow chart of the associated logic.

reset_form.php

Corresponds to the HTML page containing the form responsible for collecting the system password and then sending it to the reset.php script.

reset.php

This script collects the password of the system sent by the previous page, and checks through a query to the Database if it is correct. If so, remove all existing images and thumbails and empty the contents of the tables from the Database: Base user ’,’ images ’and‘ relation ’, and restore the password to the initial value.

Management Interface

Once the entire internal structure of the Management module has been described, the design elements used to develop the management interface are shown. In the previous section, the screenshots of each of the pages that make up the interface and that allow the Manager to interact with the system were shown, but the design structure was not indicated, the pages, formats, navigation system between the pages, etc. These design elements that have been used in the development of these Web pages that make up the management interface are detailed below.

Page layout

Web layout consists in the proper distribution of the contents that form a Web page. There are several techniques to achieve this goal: traditional layout and style sheet layout.

In traditional layout, which has been used to structure the content of the management module, the tables are used to adjust the position of the elements on the page

The structure designed to contain each of the elements that form the pages of the management interface is the one described below, as shown in Figure 20. This structure is formed by a five-row table, where:

•

 The first row (1), contains the header or lintel common to all pages, and that shows the title of the application with a defined text format and background color.

•

 The second and fourth row (1 and 4), contain a line one pixel high with image format to divide each of the sections that make up the pages.

•

 The third row (3), contains the navigation system menu of the application. It consists of an image map where each area establishes a link to a different page of the system. This row only appears when the Manager has successfully authenticated.

•

 The fifth row (5), is formed by three columns, where the first and the third serve to center the content of the second, since it is the one that contains the main body of the pages; which varies according to the current page where the Manager is located. In most cases it contains the form elements of the application.

Development of the Content Provision module

Internal structure

As discussed in previous chapters, an example of a JSRS code that implements an asynchronous mechanism for remote procedure calls is hidden in a hidden way, that is, that allows the client and Web server to establish a second communication flat without reloading the client page.

JSRS components

The JSRS code is composed of a series of functions implemented in a set of libraries. These libraries can be of two types, depending on the programming language used for their development: JavaScript, designed to run on the client (Web browser) and adopts the name "jsrsClient.js"; and PHP, designed to run on the server and adopt the name "jsrsServer.php.inc" and "jsrsServer.inc". All of them must be included in the main program in order to establish background communication between client and server. The interrelation between these elements is shown in Figure 21.

The main program consists of two scripts: viewer.htm that links the jsrsClient.js library and runs on the client side; and visor_rs.php which includes the jsrsServer.php.inc and jsrsServer.inc libraries and runs on the server side. Between them, there is an exchange of information packaged in WDDX format (XML standard for the exchange of structured information between different programming languages), and that encapsulates, among others, the data stored in the MDI Database.

SCRIPTS

The scripts that implement the MDI display module are detailed below.

viewer.htm

This script runs on the client side. It has been developed with HTML and CSS code to implement the display interface, and JavaScript to implement the slide mechanism and asynchronous communication with the server (script visor_rs.php). The associated flowchart can be seen in Figure 22.

When the browser loads the script for the first time, it displays a black image on the screen, and the indefinite loop is immediately started where the script visor_rs.php is asked for the name and the display time of the next image to be displayed by JSRS corresponding. After obtaining this information, it shows the image on the screen and stops the execution of the program during the associated display time; After that time, the loop is executed again.

The browser chosen for the execution of this script is Opera v8.54, since it is the only one that performs a full fullscreen of the page content. Others such as: Mozilla, Netscape or Internet Explorer, although they have this option, include bars or floating elements on the screen.

visor_rs.php

This script runs on the server side, and is responsible for the sequencing of content, that is, to provide viewer.htm with the name of an image and the display time associated with it. It makes queries to the Database to extract this information and makes use of the libraries "jsrsServer.php.inc" and "jsrsServer.inc", to establish background communication with the previous script. It also implements the image selection mechanism according to: the number of users detected by the MDI and the images shown previously. The associated flowchart can be seen in Figure 23. Figures 24 and 25 detail, respectively, the selection of users and images of said diagram.

The script calls the jsrsDispatch () function to establish background communication with the viewer.htm script. Receive the request for consultation and start the user selection mechanism, which must have been detected by the MDI and be registered in it. In the case of detecting several users, it uses the selected field of the Database to determine if the users have been previously selected or not, and in the case of being all selected, the selected fields of the table 'users' are reset to Start a new selection process. After selecting a user, mark it as selected and extract its MAC address.

Next, start the image selection mechanism, checking, previously, that there are associations of images with the MAC obtained. In the same way as with users, the view field is used to detect if the image has been previously displayed, and if not, it extracts the name and the display time corresponding to the selected image from the Database. Mark the image as displayed and compose the string image_name * time to be returned to the script viewer.htm using the jsrsArrayToString () function.

If the selection criteria of images or users are not met, the script returns through the jsrsArrayToString () function the string: “negro.jpg * 1500”, which is equivalent to the black image shown for a second and a half.

Display interface

The display interface has been implemented in the script visor.htm using HTML code to display the image, and CSS to define the style of the page.

According to the style sheet layout method, two #centrate and #content layers have been defined that establish a horizontal and vertical centering of the image on the screen, and in the body tag the lower and upper margins have been suppressed, and the browser side scroll bar, leaving a black background with the corresponding image in the center.

Figure 26 shows a screenshot of it, where an image appears with a lower resolution than the one set on the screen.

Detection module development

Previous concepts

In this embodiment of the invention, it has been decided to use Bluetooth as a method for the detection and identification of users. Each user registered in the system must carry a personal device with Bluetooth (e.g. a mobile phone). The MDI will use the MAC address of that device to identify the user to the system.

Internal structure

The internal structure of the detection module is formed by a main program or script developed entirely with Java compiled language, which contains the sentences, functions and control structures necessary to implement the objectives of this development phase, which should be remembered are: search for Bluetooth devices near the coverage area, retrieve their name and MAC address, and insert them in the database (database) of the system. These operations must be repeated indefinitely. Figure 27 shows a flow chart of the associated logic.

INDUSTRIAL APPLICATION

The application of the customizable digital photo frame by means of user identification is clearly derived from the description of the invention. It provides added value in terms of flexibility and economy of space and resources compared to traditional photo frames, and provides an additional level of content customization on the existing digital frames in the market by allowing user identification and adaptation of the contents based on the presence of certain users and their preferences.

Additionally, the modular conception of the invention can allow its deployment in a distributed manner, that is, by deploying the different modules by means of different devices connected to each other through a network, which opens up possibilities in the field of home automation. . As a particular case, the use of MDI as customizable interface subsystems for more complex home automation systems can be considered. In the event that a home was automated through a centralized home automation system with a main controller, and it met the software / hardware specifications imposed by the MDI, then MDI devices that showed the images of those users could be distributed for each of the rooms detected individually, establishing communication with the Database and the Web server integrated in said home automation controller. An example of this possibility is shown in Figure 5.1.

Claims (10)

one.

Customizable multimedia digital frame by means of user identification, which comprises a device capable of displaying on a screen, successions of images or video fragments associated with one or several users registered in the device, attending to a presence detection and identification mechanism of users.

2.

Customizable multimedia digital frame by means of user identification according to claim 1, comprising the hardware and software elements necessary to show the user content with sound.

3.

Customizable multimedia digital framework by means of user identification according to any of the preceding claims, which comprises a management system that allows managing information regarding users and contents registered in the device, as well as setting the preferences of the different users in relationship with the presentation of contents.

Four.

Customizable multimedia digital frame by means of user identification according to any one of the preceding claims, comprising user identification mechanisms by detecting Bluetooth devices.

5.

Customizable multimedia digital frame by means of user identification according to any of the preceding claims, which comprises user identification mechanisms by means of detecting WiFi devices.

6.

Customizable multimedia digital frame by means of user identification according to any of the preceding claims, comprising user identification mechanisms by means of RFID tags.

7.

Customizable digital photo frame by means of user identification according to any of the preceding claims, which comprises user identification mechanisms by means of biometric techniques.

8.

Customizable multimedia digital framework by means of user identification according to any of the preceding claims, comprising the hardware and software elements necessary to store the contents to be displayed to users on one or several remote file or media servers.

9.

Customizable multimedia digital frame by means of user identification according to any of the preceding claims, comprising additional distributed interface and detection devices, so that the multimedia contents associated with the users can be served in different interface devices located in different locations of simultaneously depending on the location of the different users registered in the system.

MANAGER

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

DIGITAL FRAME

USERNAME Figure 1  ES 2 402 005 Bl   MBD MANAGER MG USERNAME MPC Figure 2 Figure 3  ES 2 402 005 Bl   NO Figure 4 Figure 5  ES 2 402 005 Bl   change_passwd_form.php: Send current password and new duplicate Call the function Right() Figure 6 Figure 7  ES 2 402 005 Bl   anadir_user_form.php: Send name and MAC, as a formatted string: "name / MAC" Figure 8 Figure 9  ES 2 402 005 Bl   Figure 10 Figure 11  ES 2 402 005 Bl   associate_form.php: Send associations Call the correct function () Figure 12 Figure 13  ES 2 402 005 Bl   . Figure 14  Figure 15 consult_img.php or consult_user.php: Send identifiers Redirect to the page where the request was made  Figure 16  ES 2 402 005 Bl   Figure 17 Figure 18 Call the function Right () Figure 19

one

2

3

4

5

Figure 20 Figure 21 Function call jsrsExecute () Function call myCallback () Sample image Figure 22 Figure 23 Figure 24  ES 2 402 005 Bl   Figure 25 Figure 26 Figure 28 SPANISH OFFICE OF THE PATENTS AND BRAND Application no .: 201131275 SPAIN Application submission date: 07.27.2011 Priority Date: REPORT ON THE STATE OF THE TECHNIQUE 51 Int. Cl.: H04N1 / 00 (2006.01) RELEVANT DOCUMENTS

Category

56 Documents cited Claims Affected

X

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

summary; Figure 1; paragraphs [0055], [0085-0097].

Y

9

X

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

summary; figures 1-2; paragraphs [0015], [0043-0088].

Y

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

column 1, line 55 - column 2, line 15; column 3, line 62 - column 10, line 7.

Category of the documents cited X: of particular relevance Y: of particular relevance combined with other / s of the same category A: reflects the state of the art O: refers to unwritten disclosure P: published between the priority date and the date of priority submission of the application E: previous document, but published after the date of submission of the application

This report has been prepared • for all claims • for claims no:

Date of realization of the report 24.09.2013

Examiner M. Rivas Sáiz Page 1/4

REPORT OF THE STATE OF THE TECHNIQUE Application number: 201131275 Minimum documentation searched (classification system followed by classification symbols) H04N Electronic databases consulted during the search (name of the database and, if possible, terms of search used) INVENES, EPODOC State of the Art Report Page 2/4  WRITTEN OPINION Application number: 201131275 Date of Written Opinion: 24.09.2013 Statement

Novelty (Art. 6.1 LP 11/1986)

Claims Claims 4,5,9 1-3, 6-8 IF NOT

Inventive activity (Art. 8.1 LP11 / 1986)

Claims Claims 4,5,9 IF NOT

The application is considered to comply with the industrial application requirement. This requirement was evaluated during the formal and technical examination phase of the application (Article 31.2 Law 11/1986).  Opinion Base.- This opinion has been made on the basis of the patent application as published. State of the Art Report Page 3/4  WRITTEN OPINION Application number: 201131275  1. Documents considered.- The documents belonging to the state of the art taken into consideration for the realization of this opinion are listed below.

Document

Publication or Identification Number publication date

D01

US 2006 170669 A1 (WALKER JAY S et al.) 03.08.2006

D02

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

 2. Statement motivated according to articles 29.6 and 29.7 of the Regulations for the execution of Law 11/1986, of March 20, on Patents on novelty and inventive activity; quotes and explanations in support of this statement Document D01 is considered the closest in the state of the art to the requested invention. In relation to claim 1, D01 describes a customizable multimedia digital frame by means of user identification (summary). It comprises a device capable of displaying on a screen (figure 1), sequences of images or video fragments associated with one or several users registered in the device according to a presence detection and user identification mechanism (paragraphs 0088 to 0092). Therefore, claim 1 is not new (Article 6 LP.). Document D01 includes the hardware and software elements necessary to show the user content with sound. From the hardware point of view it has a screen, a speaker and a processor and in paragraph 0085 it is described that it shows video stream. Therefore, claim 2 is also not new (Article 6 LP.). In relation to claim 3, D01 discloses a management system that allows managing information regarding users and contents registered in the device (paragraph 0088), as well as setting the preferences of different users in relation to the presentation of content (paragraph 0094). Consequently, claim 3 is not new (Article 6 LP.). In D01 the proposed user identification is by means of RFID tags (paragraph 0088) and also by biometric techniques (paragraph 0089), so claims 6 and 7 are not new (Article 6 LP.). With respect to claims 4 and 5 it should be noted that it is used to identify the user the detection of WiFi and Bluetooth devices. These techniques are not included in D01 but are usual techniques to identify users and therefore, their mere application does not provide inventive activity to the claims. Therefore claims 4 and 5 do not imply inventive activity (Article 8 LP.). Claim 8 is anticipated in D01 in paragraph 0055 where the digital framework comprises the hardware and software elements necessary to store the contents that are to be displayed to users on one or several remote file or media servers and consequently lacks novelty. (Article 6 LP.). In relation to claim 9, document D01 does not have additional distributed interface and detection devices, so that the multimedia contents associated with the users can be served in different interface devices located in different locations simultaneously depending on the location of the different users registered in the system. The technical effect of this difference is to show different content on different devices depending on the location of each user. The technical problem is how to serve the contents to different users simultaneously. Document D02 solves the previous problem (column 9 line 62 to column 10 line 7) where different devices, one of them for example a digital frame, offer different content depending on the preferences of the user located in the room. Therefore, one skilled in the art would combine the features described in D01 with the problem solved by D02 to obtain claim 9 without making use of the inventive activity and therefore, claim 9 does not imply inventive activity (Article 8 LP.). State of the Art Report Page 4/4