ES2402005A2 - Customizable multimedia digital framework by user identification - Google Patents

Customizable multimedia digital framework by user identification Download PDF

Info

Publication number
ES2402005A2
ES2402005A2 ES201131275A ES201131275A ES2402005A2 ES 2402005 A2 ES2402005 A2 ES 2402005A2 ES 201131275 A ES201131275 A ES 201131275A ES 201131275 A ES201131275 A ES 201131275A ES 2402005 A2 ES2402005 A2 ES 2402005A2
Authority
ES
Spain
Prior art keywords
users
user identification
means
user
cu
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Granted
Application number
ES201131275A
Other languages
Spanish (es)
Other versions
ES2402005R1 (en
ES2402005B1 (en
Inventor
Iván MARSÁ MAESTRE
Juan Ramón VELASCO PÉREZ
Víctor BREA LUJÁN
Miguel Ángel LÓPEZ CARMONA
Enrique De La Hoz De La Hoz
Antonio José De VICENTE RODRÍGUEZ
Bernardo ALARCOS ALCÁZAR
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Universidad de Alcala de Henares (UAH)
Original Assignee
Universidad de Alcala de Henares (UAH)
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Universidad de Alcala de Henares (UAH) filed Critical Universidad de Alcala de Henares (UAH)
Priority to ES201131275A priority Critical patent/ES2402005B1/en
Publication of ES2402005A2 publication Critical patent/ES2402005A2/en
Publication of ES2402005R1 publication Critical patent/ES2402005R1/en
Application granted granted Critical
Publication of ES2402005B1 publication Critical patent/ES2402005B1/en
Application status is Active legal-status Critical
Anticipated expiration legal-status Critical

Links

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 using the JSRS functions 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 (9)

  1.  CLAIMS
    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. 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. 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.
  4. 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. 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. 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. 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. 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. 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
    MBD
    MANAGER
    MG
    USERNAME
    MPC
    Figure 2
    Figure 3
    NO
    Figure 4
    Figure 5 Figure 6
    Figure 7
    change_passwd_form.php: Send current password and new duplicate
    Call the function
    Right()
    anadir_user_form.php: Send name and MAC, as a formatted string: "name / MAC"
    Insert $ name and $ mac in ‘users’
    Figure 8
    Figure 9 Figure 10
    Figure 11
    associate_form.php: Send associations
    Call the correct function ()
    Figure 12
    Figure 13
    .
    Figure 14
     Figure 15
    consult_img.php or consult_user.php: Send identifiers
    Redirect to the page where the request was made
     Figure 16
    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 Figure 25
    Figure 26
    Figure 28
ES201131275A 2011-07-26 2011-07-26 Customizable multimedia digital framework by user identification Active ES2402005B1 (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
ES201131275A ES2402005B1 (en) 2011-07-26 2011-07-26 Customizable multimedia digital framework by user identification

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
ES201131275A ES2402005B1 (en) 2011-07-26 2011-07-26 Customizable multimedia digital framework by user identification

Publications (3)

Publication Number Publication Date
ES2402005A2 true ES2402005A2 (en) 2013-04-26
ES2402005R1 ES2402005R1 (en) 2013-10-08
ES2402005B1 ES2402005B1 (en) 2014-05-14

Family

ID=48050994

Family Applications (1)

Application Number Title Priority Date Filing Date
ES201131275A Active ES2402005B1 (en) 2011-07-26 2011-07-26 Customizable multimedia digital framework by user identification

Country Status (1)

Country Link
ES (1) ES2402005B1 (en)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
ES2723898A1 (en) * 2018-02-27 2019-09-03 Happy Punt S L U Product identifier system and procedure

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20060170669A1 (en) * 2002-08-12 2006-08-03 Walker Jay S Digital picture frame and method for editing
US7796190B2 (en) * 2008-08-15 2010-09-14 At&T Labs, Inc. System and method for adaptive content rendition
US20110102444A1 (en) * 2009-04-20 2011-05-05 Tomoko Matsumoto Information display device and information display method

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20060170669A1 (en) * 2002-08-12 2006-08-03 Walker Jay S Digital picture frame and method for editing
US7796190B2 (en) * 2008-08-15 2010-09-14 At&T Labs, Inc. System and method for adaptive content rendition
US20110102444A1 (en) * 2009-04-20 2011-05-05 Tomoko Matsumoto Information display device and information display method

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
ES2723898A1 (en) * 2018-02-27 2019-09-03 Happy Punt S L U Product identifier system and procedure

Also Published As

Publication number Publication date
ES2402005R1 (en) 2013-10-08
ES2402005B1 (en) 2014-05-14

Similar Documents

Publication Publication Date Title
Steglich I-centric user interaction.
US7970791B2 (en) Re-ranking search results from an enterprise system
US8725770B2 (en) Secure search performance improvement
US8595255B2 (en) Propagating user identities in a secure federated search system
CN103930897B (en) Mobile solution, single-sign-on management
JP6272933B2 (en) Remote browsing session management
CN100435141C (en) Method and system for automating internet interactions using recorded data
CN100492355C (en) Method and apparatus for enabling associated portlets of a web portal to collaborate for synchronized content display
CN1271535C (en) Method for making data and movement synchronous in wireless apparatus, and data storage system
CN101939736B (en) System and method for developing rich internet applications for remote computing devices
US8595186B1 (en) System and method for building and delivering mobile widgets
JP5205965B2 (en) Computer system, server processing apparatus, terminal apparatus and method
KR20140108159A (en) Apparatus and method for processing a multimedia commerce service
CN103119557B (en) Pattern-based construction and extension of enterprise applications in a cloud computing environment
US10257196B2 (en) Access control for a document management and collaboration system
US20070208713A1 (en) Auto Generation of Suggested Links in a Search System
US8966023B2 (en) Adjusting software settings
US20140089786A1 (en) Automated Processor For Web Content To Mobile-Optimized Content Transformation
US20140114946A1 (en) Search hit url modification for secure application integration
US8027982B2 (en) Self-service sources for secure search
US9443016B2 (en) System and method for generating and interacting with a contextual search stream
US7653001B2 (en) Managing differences in user devices when sharing content on mobile devices
TW576982B (en) Programmatic management of software resources in a content framework environment
US7853988B2 (en) State saver/restorer for a geospatial decision management system
US20100313252A1 (en) System, method and apparatus for creating and using a virtual layer within a web browsing environment

Legal Events

Date Code Title Description
FG2A Definitive protection

Ref document number: 2402005

Country of ref document: ES

Kind code of ref document: B1

Effective date: 20140514