WO2012005617A1 - Residential multiple-play device control for integrated multi-protocol and multi-device communication system, and operation method thereof - Google Patents

Abstract

The present invention pertains to the fields of telecommunications and electronic systems, namely in providing for highly integrated communications and services in a device or system, namely at home or other residential settings. It comprises a main server, a multi-protocol and multi-equipment layer, physical subsystems user interface, and abstracts divisions and respective hierarchy, devices, routines and respective actions and trigger conditions, environments and respective hierarchy of actions. The invention comprises an xml file generator and parameter verifier able to export a set of rules, said file describing address, display and action properties of a specific device. The data converter and distributor module, namely from said rules, selects the necessary code for runtime execution by the main server and filters a set of rules for the client specification module. In other words, this module converts the filtered xml content into a format especially adapted to devices attached to the main server.

Description

D E S C R I P T I O N

"RESIDENTIAL MULTIPLE-PLAY DEVICE CONTROL FOR INTEGRATED MULTI-PROTOCOL AND MULTI-DEVICE COMMUNICATION SYSTEM, AND

OPERATION METHOD THEREOF"

Technical field

The present invention pertains to the fields of telecommunications and electronic systems, namely in providing for highly integrated communications and services in the same device or system, namely at home or other residential settings.

Background art

In telecommunications, a triple-play service is a marketing term in which voice, video and data are all provided in a single access subscription. The most common applications are telephony, community antenna television and high-speed Internet service. The triple-play transmission medium is usually fiber optic, conventional cable or satellite and it focuses on a combined business model rather than solving any technical issues. However home users who subscribe to triple-play networks enjoy the fact that they have to pay only one bill each month and can deal with a single entity to resolve problems with their telephone, TV or Internet connections .

The patented document "US 2007/0290882" relates to a novel centralized domotic system able to remote control and manage household appliances, apparatuses, installations, devices, machines, etc. existing in a dwelling-house. Another objective of the invention is at the same time to allow each manufacturer of the household appliances, apparatuses, etc. provided with specific software to update such software easily, continuously, remotely and automatically. They achieve such goals by providing a domotic system to carry out drive, control and centralized management which essentially consists of a remote logic drive, control and management unit installed in a dwelling- house .

In summary, and in one hand, this previous document bestows a way to manage the house content, providing the system integrator with a tool, that allows to interact with the physical system without being present but it does not provide a specific interface embraced with a dynamic description of both display and action properties of all the attached devices, which allows the final user to interact with that same physical system in a functional and consistent way.

On the other hand, previous inventions do not provide consistency, fundamental to assure full unification of usability and control of all the available elements in the house .

Disclosure of the invention

i

Triple-play is mainly seen as a commodity with the intention to simplify the home users' life. For a considerable amount of years that the home commodity issue has been approached through several perspectives and often a new solution appears to improve the home life. Being the Triple-play concept an end-user home oriented package, how can we improve this same concept to unify all available elements in a house? The answer is quite simple; expand Triple-play to n-play.

Consumers are becoming highly dependent on new and improved gadgets to simplify their everyday life. As the world gets more and more technologically advanced, we find new technology coming in deeper and deeper into our personal lives especially at home. Telephone, TV, Internet, Security, Intercom, Climate control etc. are already common on a home environment as standalone solutions. The main goal is to consolidate all of these solutions into a single fully functional solution and therefore conceiving the n- play package which fundamentally assures a complete unification of usability and control of all existing elements in the end-users home.

n-play as a fully scalable end-user oriented solution can evolve to accommodate all technological tendencies and domotics is becoming more and more popular around the world and is becoming a common practice. Domotics (also called Home Automation) designates an emerging practice of increased automation of household appliances and features in residential dwellings, particularly through electronic means that allow for things^■ impracticable, overly expensive or simply not possible in recent past decades. The term may be used in contrast to the more mainstream "building automation", which refers to industrial uses of similar technology, particularly the automatic or semi-automatic control of lighting, doors and windows, Heating, Ventilation and Air Conditioning, and security and surveillance systems .

The process of home automation works by making everything in the house automatically controlled using technology to control and do the jobs that one would normally do manually. As the amount of controllable fittings and domestic appliances in the home rises, the ability of these devices to interconnect and communicate with each other digitally becomes a useful and desirable feature. The consolidation of control or monitoring signals from appliances, fittings or basic services is an aim of Home automation .

A home automation project foresees a wide range of control points including internet, telephone, television, home theater, apparatuses, etc. It will combine the advantages of informatics and electronics to obtain an integrated management over all control points making life easier, more comfortable and even enjoyable. Home users can interact with all control points through an ample variety of gadgets such as mobile devices, computers, etc. These gadgets are provided with specific control access interfaces that ensure that the users "intensions" are transmitted to the system.

An interface in computer science refers to a set of named operations that can be invoked by clients. Interface generally refers to an abstraction that an entity provides of itself to the outside. This separates the methods of external communication from internal operation, and allows it to be internally modified without affecting the way outside entities interact with it, as well as provide multiple abstractions of itself. It may also provide a means of translation between entities which do not speak the same language, such as between a human and a computer. Because interfaces are a form of indirection, some additional overhead is incurred versus direct communication. The interface between a human and a computer is called a user interface.

In the industrial design field of human-machine interaction, the user interface is where interaction between humans and machines occurs. The goal of interaction between a human and a machine at the user interface is effective operation and control of the machine, and feedback from the machine which aids the operator in making operational decisions. Examples of this broad concept of user interfaces include the interactive aspects of computer operating systems, hand tools, heavy machinery operator controls and process controls. The user interface includes hardware (physical) and software (logical) components. User interfaces exist for various systems, and provide a means of both Input and Output. Input allows the user to manipulate a system and output allows the system to indicate the effects of the users' manipulation.

Typically, the goal of human-machine interaction engineering is to produce a user interface which makes it easy, efficient and enjoyable to operate a machine in the way which produces the desired result. This generally means that the operator needs to provide minimal input to achieve the desired output, and also that the machine minimizes undesired outputs to the human.

One of the main objectives of this invention is to fully overcome the limitations of interactions with the home environment. This invention will abolish such boundaries based upon a plug and play environment, built on top of an open architecture, flexible enough to be easy and dynamically adapted to an n-play telecommunication offer. For many years people tend to set boundaries to which they consider acceptable and non-acceptable when someone bothers them at home. It is not by any means reasonable that a system integrator periodically schedules a routine inspection to update the installed system in the users' house. It is mandatory to develop a concept that allows such updates to be automatically performed with a minimal effort for both user and system integrator. Nowadays with the increasing development of the new technologies and the internet, it is possible to create a centralized access point in every users' home that allows such adjustments to be made not only whenever necessary, but also according to extra equipments and functionalities that the user may acquire. This generic plug-and-play" way of doing things will create a non-intrusive way to keep the system and every component updated. Whenever there is a need to enhance the software or the hardware the interface will adjust itself attenuating as possible any entropy created by such changes to the user. This is one of the main objectives of the present invention.

One particular platform that supports the home environment is domotics . There are several ways to represent the devices used in a domotic installation due to the fact that different components possess different control interfaces. Sometimes this situation can be a liability to the user that should preferably be completely avoided. For instance, if we take in consideration two sets of surveillance cameras with distinct control interfaces, the user will have to imbibe distinct ways of interaction instead of a single, natural and standard way. One of the main goals of this interface is to abstract the hardware components in such a way that will allow them to be represented as standard and custom objects. Each component will keep their control options, but to the final user it will be as if they all belonged to the same sub system. Therefore there is no need for the user to adapt to the hardware because the hardware will be "adapted" to the user .

Just abstracting hardware components is insufficient. There is also a need to represent them in a proper and functional mode providing the user with a tool to more efficiently interact with them. The interaction with the interface is demanded to be intuitive, in case that any new component is appended to the system the user needs to be capable to adapt to its control functions. All components need a structural order and a set of actions, which will provide the user the possibility to fully experience them. The insertion of filters over these components will contribute to the flexibility and indexation of all members allowing the user to more efficiently and easily react to a given situation .

Each and every attribute of the installed hardware components are needed for a better interaction with the house and incrementing more options to those attributes increases the quality of the system. This invention provides a practical and intuitive mechanism to create personalized sets of actions over those components attributes, enhancing the overall potential of the entire system.

Nowadays, there is a considerable variety of gadgets being continuously developed and each one of them possesses a collection of particular properties that make them unique. Often called smart devices, this kind of gadgets evolves regularly and distinctively from each other and their features and usability are exclusive to their brand/model. Despite these different features and usability, a considerable amount of software developers conceive their products with generic and conventional characteristics. A good example of this tendency is the generalization of web interfaces which are commonly and purposely engineered to function in every gadget that possesses a web browser. This "webization" makes sense from an engineering point of view, but often results in a complete loss of the gadget's usability .

It is so definitely important to point out that despite the different ways to interplay with each gadget this invention assembles, in one hand, in its core both the gadgets usability and the intended standard approach. On the other hand, the invention accommodates an adaptive system that will automatically accustom to the physical and logical changes made by the user or by the system integrator. This allows a clean and efficient connection between two specific worlds, the hardware and the software.

Summary

The present invention describes a consolidated residential device control and communication system comprising: a main server (50) ; a multi-protocol and multi-equipment layer (1A, IB); physical subsystems (40, 41, 42, 43, 44, 45); a common user interface (30B, 31B, 32B) , and is able to abstract divisions (10) and respective hierarchy, devices (12), routines (13) and respective actions (14) and trigger (15) conditions, environments (11) and respective hierarchy of actions ( 14 ) .

In a preferred embodiment, the multi-protocol and multi- equipment layer (1A, IB) comprises: an xml file (54) generator module (60) and parameter verifier module (20), said xml file (54) being able to describe address, display and action properties of a specific device (12); said parameter verifier module (20) being able to export a set of rules (200) to the data converter and distributor module (21); a data converter and distributor module (21) able to select the necessary code for runtime execution by main server (50) and also able to filter a set of rules (200) to the client specification module (22); a client specification module (22) able to convert the filtered xml content (201) into a xml format especially adapted to the devices (12); said xml file or files (54) also being able to describe routines for a routine module (23) , environments for an environment module (24), device rules for a server device module (25) , through the data converter and distributor module (21) which is also able to validate and filter the data (202, 203, 204); a virtual device representation module (25), able to virtually represent said devices (12); a device control module (26) able to filter unnecessary data to said virtual device representation module (25) .

In another preferred embodiment, said main server (50) comprises: a communication module (51) for user interface (30B, 31B, 32B) and communication (30D, 31D, 32D) devices; communication module (52) for devices (40, 41, 42, 43, 44, 45); cache (53) of filtered (201) xml content (54) in a format especially adapted to the devices (12); execution capabilities for said multi-protocol and multi-equipment layer (IB) .

In yet another preferred embodiment, said virtual device representation module (25) comprises: a division filter comprising its name and its parent filters; a list of data types comprising its name, type and optionally user symbol, decimal digits, minimum and maximum values; device abstraction interface comprising its name, members and respective data types, and optionally respective descriptions; a list of device types, comprising its name and the respective device abstraction interface; a device list comprising the respective device identifier and type, and its members and the respective device abstraction interface, which in turn comprises properties and the respective data type. In another but also preferred embodiment, said environment module (24) comprises an environment list, comprising for each environment its identifier, name and access, respective action device identifiers, members, values and delays, and respective executable environment identifiers and states.

In yet another but also preferred embodiment, said environment module (23) comprises a routine list, comprising for each routine its identifier, name and access, respective trigger device identifiers, members, values, operations, dates, time and days of the week, respective action device identifiers, members, values and delays, and respective executable environment identifiers and states.

In a preferred embodiment, said virtual device representation module (25) device list comprises device identifier, name, divisions where it is to be accessed, device type, group, actionable status, user visibility and respective members comprising names, addresses, output and input capabilities, and command strings.

The present invention also describes an operation method for a consolidated residential device control and communication system, comprising the steps of:

abstracting divisions (10) and respective hierarchy, devices (12), routines (13) and respective actions (14) and trigger (15) conditions, environments (11) and respective hierarchy of actions (14);

generating (60), inputting and verifying parameters (20) of an xml file (54), said file comprising address, display and action properties of a specific device (12); exporting by a parameter verifier (20) a set of rules (200) to a data converter and distributor module (21);

selecting by the data converter and distributor module (21) the necessary code for runtime execution by main server (50) ;

filtering a set of rules (200) to the client specification module (22 ) ;

converting by the client specification module (22) the filtered xml content (201) into a xml format especially adapted to the devices (12) ;

validating and filtering the data (202, 203, 204) through the data converter and distributor module (21) of said xml file or files (54) which comprise the description of routines for a routine module (23) , environments for an environment module (24) and/or device rules for a server device module (25) .

In another embodiment it further comprises the steps of: virtually representing said devices (12) by a virtual device representation module (25) ;

filtering unnecessary data to said virtual device representation module (25) by a device control module (26) .

In another but also preferred embodiment, it further comprises the following steps for device (12) interaction: changing (70) device (12) state;

providing new data (701) to the main server (50), specifically to the device control module (26) , through the device communication module (52) ;

sending the data to the virtual device representation module (25) ;

verifying existence of new information, if not quit processing; validating of routine triggers and respective client updating (30C, 31C, 32C) .

In yet another but also preferred embodiment, the client updating (30C, 31C, 32C) comprises the steps of:

sending an update message to each client (30C, 31C, 32C) ; requesting by the clients (30C, 31C, 32C) to main serve server (50) of the new information;

validating received data by a multi-protocol and multi- equipment layer (1A);

updating (71) interfaces (30B, 31B, 32B) .

In another preferred embodiment, the trigger validation comprises the steps of :

receiving (703) necessary data from the virtual device representation module (25) ;

searching by the routine module (23) , for the respective triggers of the device in question;

verifying if all triggers for the routine are satisfied; if positive, then executing the routine actions by its commands (705) to affected devices (72);

if negative (704), verifying remaining routines and when all done, quit processing;

returning to the initial step of changing (70) device (12) state .

In another embodiment, further comprising the following steps when adding a new device to the system:

replacing (60) said xml file (54) with updated xml (80); verifying new information by the parameter verifier module (20) ;

exporting a set of rules (200) to the data converter and distributor module (21) ; verifying runtime needed code by the data converter and distributor module (21);

converting by the client specification module (22) the filtered xml content (201) into a xml format especially adapted to the devices (12), and storing (53) it;

sending (800) updated information to all active (81) clients (30A, 31A, 32A) ;

validating and filtering the data (202, 203, 204) through the data converter and distributor module (21) of said xml file or files (54) which comprise the description of routines for a routine module (23) , environments for an environment module (24) and/or device rules for a server device module (25) ;

filtering unnecessary data to said virtual device representation module (25) by the device control module (26) ;

validating communications (801) between main server (50) and the newly added device (82) .

Description of the figures

The attached figures represent preferred embodiments are not to be considered in any way restrictive of the present invention .

FIG. 1 is a schematic view of a software layer 1A present in the core of several software applications 30.A, 30. B, 30. C.

FIG. 2 is a schematic view of the software layer IB present in the core of the main server 50.

FIG. 3 is a schematic view of the system and its interrelations 1C. FIG. 4 is a schematic view of the changes that occur when a component 40, 41, 42, 43, 44, 45, etc. is interacted with (cameras, alarms, video door phones, domotic protocols, intercoms, health monitoring, respectively) .

FIG. 5 is a schematic view of the changes that occur when a component 40, 41, 42, 43, 44, 45, etc. is added to the main server 50.

Detailed Description

Since one of the main objectives of this invention is to fully overcome the limitations of interactions with the home environment by providing standard, non-intrusive and practical interfaces, several base concepts need to be established. Further down the document it will be shown that only four abstract concepts (division, device, environment and routine) are needed to grant the interface its full functionality.

Before thinking in any functional increments, first we need to focus in four main elements of a house environment: the house itself, the household chores, the people that live in the house and the way they interact with it .

Taking these four factors in consideration it is easily noticeable that a house has specific divisions to cumulate specific actions. By definition a division "is something that divides or separates; a partition". In the context of architecture, a division is something that divides the house logically over several partitions such as bedroom, kitchen, etc. In this invention, a division is exactly the same thing; it divides the concept of house/system in several fragments, providing a way of grouping all the other objects in a logical way.

A division can contain other divisions, so it can represent the existence of several nested levels in the house. Considering a division as a complete abstract member allows us to embody the entire house as a division. The house "being a division" concept can be exemplified considering the first nested level of divisions to be the house floors and the second level the rooms (bedroom, kitchen, etc.) . Inside every room in a house there are always several apparatuses that can be controlled by domotic systems. Those apparatuses can be represented by devices. Usually, the concept of device integrates at least two different perspectives: the system integrator perspective, to which each device expose its concrete behavior and data types, and the final user perspective, to which each device expose its abstract behavior and general functionality. These two "points of view" are crucial and critical to provide the necessary flexibility to represent and interact with a large number of devices, from different categories and continuously available in the home automation market. The big challenge is then how to represent and aggregate these huge sets of devices in a way that the final user understands, giving him a modular, scalable and easy way of interacting with his/her home environment.

For the final user a device basically consists of a name and one or more behaviors. For example, a light can have the name "bedroom ceiling light" and the associated behaviors are "Turn on" and "Turn off". On one hand, such a concept needs to be completely easy to figure to keep the interface as functional and standard as possible. On the other hand the concept of behavior needs to be more dynamic for the system integrator due to the vast amount of physical domotic components. Internally the concept of behavior is used to link these two worlds allowing an abstraction over the system network enabling the possibility to create a multi-protocol and multi-equipment layer. This layer interacts with various physical subsystems but it is presented to the final user as a standard interface removing the ambiguity of the entire physical system.

Divisions and devices are considered the basic structures of the invention and they are the platform that allows us to reach the next level of automation control which is commonly referred as ambient intelligence.

The quality of life and enjoyment that a person feels heavily depends on efficiency, comfort and confines of the place the final user calls home. Ambient intelligence is an idea that aims to provide an easy way of living, while the actual technology stays in the background, integrated in a non-intrusive way. In order to better achieve the ambient intelligence vision, there is a need to integrate all technology in the house and to also go one step further in order to give the final user that special feel of comfort and quality of live.

There are basic behaviors in our daily lives at home that can be easily pointed as common and necessary, like turning all lights on or opening all shades of a room. These behaviors are usually repeated in a daily basis and it is possible to find a pattern in them, leading us to search for a concept in which an automated group of actions can be represented as an abstract element called environment . In the interface, environments are complex elements that can be easily and intuitively defined/created directly by the user to automate a set of tasks/chores and execute them with the simple and well known "push of a button". It is also important to fact that an environment must preferably be able to execute other environments to remove the need to replicate groups of actions allowing the user to more efficiently manipulate the house tasks. A set of behaviors in the everyday life can also be triggered by specific conditions. For instance, if it starts to rain the common action to take is to close all windows. · This kind of action can also be simulated as an automated response from the system enabling a more efficient response to a situation and releasing the user from the need to manually react to that specific issue. The goal is to define an abstract element named routine that acts (performs a group of "Actions") when certain conditions are met (when all "Triggers" are validated) .

A system routine is composed by two distinct sub elements named "Triggers" and "Actions". These "Triggers" are logical expressions (propositions) which can be composed using the logical operators "AND", "OR" and "NOT" over a certain and specific type of environment variables (i.e. day/hour, device state, temperature, email received, Mp3 player connected, etc.) . Routine "Actions" are the same as Environment "Actions". They can execute an environment or a direct action over some behavior of a specific device.

In summary, divisions, devices, environments and routines are the four basic concepts needed to model a standard, easy-to-use and fully functional interface for any home environment equipped with domotics, security, video doorphone, HVAC, etc. In other words, these four basic concepts are sufficient to model an entire ambient intelligence system and to provide to the final user an extended control over any home automated system/apparatuses existing in a dwelling-house.

FIG. 1 is a schematic view of a software layer 1A present in the core of several software applications 30.A, 30. B, 30. C. The layer 1A has four specific base elements 10, 11, 12 and 13. These elements will be manipulated in each interface to provide the user a clear view of the available components of the house.

Element 10, labeled "Divisions", can contain a variable number of the other elements (10, 11, 12 and 13) . This element works as a container to filter information for the user. It represents a real division of the house or a generic space to band the elements for an easier access. In a dwelling house the several components such as 40, 41, 42, 43, 44, 45, etc. can be virtually represented in 12 to allow the interface 30. B, 31. B, 32. B to show them to the user in a functional way. These virtual objects will provide a bridge from the interfaces to the main server 50 allowing several operations to take place with minimal effort for the user.

Some of the house components can receive specific orders on how to act and these actions are represented in 14. 14 is a group of commands that can be applied to the house components 12 (represented by the connection 104) , to other specific virtual components 11 (represented by the connection 100) and to any other generic entity (like playing a music file) .

Environments 11 is a group of 14 (represented by 101) , these are defined by the user allowing him to interact with several components at the same time with minimal effort. Standard behaviors from our daily life can be represented in 11 which allow a more efficient reaction to a desired state on the house content .

A variety of actions can be executed when certain and specific conditions are met, these condition evaluators are called triggers 15 and they can be triggered by a specific device 12 (a set of 12 is represented by 105) , a day, an hour, etc. depending on the user needs. With this we can define a routine 13 that is basically a set of actions 14 (a set of 14 is represented by 103) and a set of triggers 15 (a set of 15 is represented by 102) . A routine allows the user to automatically execute his chosen actions 14 without the need of him being present at the time.

FIG. 2 is a schematic view of the software layer IB present in the core of the main server 50.

When there is a need to add new components 40, 41, 42, 43, 44, 45, etc. to the main server 50, an xml file 54 is generated in 60 and uploaded into 50 with a list of addresses, display properties and action properties for that component. This file 54 is going to be verified in 20 in order to automatically validate the received data and generate sets of rules on how the component will be displayed to the user and also which actions will be available (turning it on/off, etc.) . By the same means (using a file 54) system routines 23 and system environments 24 can be uploaded to the main server 50.

The approved generated rules 200 will be sent to a data conversion and distributor object 21 which will dictate which is the necessary code to be executed in runtime. This object 21 has the most critical role in the entire design since it will dictate what will be ran in the server 50 and what will be shown to the user in the interfaces 30. B, 31.B, 32. B. Since only the necessary code is executed in runtime there is no waist of the main server 50 resources allowing a more efficient control over the house components 40, 41, 42, 43, 44, 45, etc.

A client is a gadget 30.A, 31.A, 32.A, etc. (computer, touch pad, smart phone, respectively) that runs a specific software 30. C, 31. C, 32. C, etc. which connects to the main server 50 to provide an interaction with the house components 40, 41, 42, 43, 44, 45, etc. The generated rules 200 will be filtered by 21 and the ones aimed for the clients 30.A, 31.A, 32.A (the client rules are represented by 201) will be converted in 22 to a specific formatted Xml object. The Xml object generated in 22 as a unique standard format (described further down) that allows the interfaces 30.B, 31.B, 32. B to shape themselves to the house components 40, 41, 42, 43, 44, 45, etc. This object will be stored in a file 53 for a faster access to its contents and will update when new information is inserted (using 54) in the main server 50. An Xml file was used due to its versatility and to preserve the platform independence between all communications but a similar format with equivalent characteristics could be used as is obvious to any person of knowledge in the subject. Also memory issues become more limited because the file is stored and there is only the need to assure that it is not corrupted. This might not be the fastest way because direct memory access is much faster but it is the safest way to prevent any distorted data.

Routines 13 and environments 11 are shown to the user in 30. B, 31.B, 32.B, etc. but they are executed and verified in the server 50, also some routines and environments are restricted and are only available to server 50. Both the restricted and unrestricted routines/environments are allocated in the same virtual space (23 and 24) and both are generated by 21 after a thorough examination. All routines that satisfy all validation criteria's 202 (such as; a component exists and a device 25 is correctly associated to it, etc) are sent to 23 for coordination and management. The information generated in 23 is shared to the user if needed otherwise all actions are silent. This also applies to 203 (environments that satisfy all validation criteria's) in 24. Routines 23 and Environments 24 are defined as 11 and 13.

Rules 200 regarding house components 40, 41, 42, 43, 44, 45, etc. are created assuming that the received information 54 is accurate accordingly to the components settings. The valid components rules 204 are sent to 25 which will embody a virtual element to represent each component 40, 41, 42, 43, 44, 45, etc. Their state is always supervised and when any changes occur all clients' software 30. C, 31. C, 32. C, etc. are alerted of that fact.

When a component 40, 41, 42, 43, 44, 45, etc. communicates by 52 with the main server 50 its data is sent to the devices control 26 area that sends the data 205 to the intended virtual representation 25 of that component. The control area 26 works as a bridge, filtering unnecessary data to the virtual components 25.

FIG. 3 is a schematic view of the system and its interrelations 1C.

Nowadays in every house exists a wide variety of components 40, 41, 42, 43, 44, 45, etc. that enhance a person's way of life. Every house component that is able to communicate with another entity can be connected to the main server 50 throw 52. This connection can differ from component to component, it can be an infra-red port, Bluetooth access, WAN, LAN, SMS's, etc. From now on a connection let's call "COMS" a connection between a component 40, 41, 42, 43, 44, 45, etc. and the main server 50.

"COMS" is variable, if a new connection type is needed the proper hardware/software is added to 50 to allow this "COMS" to happen with the intended component. Also "COMS" isn't limited to one type of connection several can take place at the same time for an instance we can have a LAN and a Bluetooth connection at the same time.

Any gadget that can execute software and are able to communicate with other entities is applicable to use this invention. The gadgets described in 30.A, 31.A, 32.A are a small example of a wide variety of possible host for the client software. Desktops, laptops, Ipods, Ipads, Pocket pes, cellular phones and many others, all belong to this bundle of gadgets. More Eg. HP Touch smart, iphone, Asus Touch, Notebooks, etc.

Unless the gadget as a limited software capability like an old cellular phone (in this case the communication in by SMS's), a specific software package 30. C, 31. C, 32. C etc. will be installed with custom components to allow all its unique features to be reflected in the interface 30. B,

31. B, 32. B, etc. Every interface is built with a specific intended goal, enhance the user experience and maximize the possible interactions with the house components.

Every gadget will need to have means to receive/send information, allowing the main server 50 to communicate the status of the house components 40, 41, 42, 43, 44, 45, etc., from now on let's call this mean "COM 2 " (communication between gadgets and the main server 50) . "COM 2 " 30. D, 31. D, 32. D, etc. can differ from gadget to gadget and it can be an infra-red port, Bluetooth access, WAN, LAN, SMS's, etc. but for a "COM 2" to established the same communication mean must preferably be present in the main server 50 (the communication access is referenced as 51) . The main server 50 is adaptable when a new "COM 2 " is needed its added in 51.

When new or updated data is sent from 51 to 30. D, 31. D,

32. D, etc. this information is verified by 1A and the necessary adjustments are made. Transparent changes (not relevant to the user) will only occur at the 1A level, other changes will also take effect in 30. B, 31. B, 32. B, etc. allowing an automatic update of the interface for a more efficient control.

The main server 50 is a custom made piece of hardware; the software IB needs to be able to run in the selected equipment and for that some minimal requirements are necessary. A 32Mz processor, 16 Mb of RAM memory and 5Mb of free disc space are the minimal requirements for the server 50 to work properly and efficiently. Currently, the main server was built using a Marvell/Intel ARM Xscale PXA300 embedded microcomputer that runs at 208MHz, 32Mb SDRAM memory and 8Mb NOR Flash disk.

Generic equipment 60 is needed for an easier access to the xml file 54. This file will be transferred from 60 by a specific software that will replace the old file 54 with a new one, by replacing the file 54 an internal event will be triggered in IB (more specifically in 20) that will update the main server 50 data and content. After updating the content in IB and if necessary to change data in each clients 30.A, 31.A, 32.A, etc. software 30. C, 31. C, 32. C, etc. another Xml file is generated 53. An event will be sent to 51 which in turn will be transmitted to every "COM 2" (30. D, 31. D, 32. D, etc.) and 1A will take the necessary actions to retrieve 53.

The file 53 needs to implement a specific structure that allows 1A schema to be established. This structures needs to be standard which will allow the clients software 30. C, 31. C, 32. C, etc. to interpret it and dynamic in order to accustom any component 40, 41, 42, 43, 44, 45, etc. added to the server.

As seen before the filter 10 allows an accommodation of 11, 12 and 13 in an orderly manner and therefore a node containing this filter information is needed; the following xml node exposes an example of such information.

<divisions>

<division id="" name=" " path=" "/>

</divisions>

ID - Allows to unequivocal identify each filter 10;

NAME - If a name needs to be shown to the user in 30. B,

31. B, 32. B, etc. this will be the value used;

PATH - A filter 10 can contain other filters 10, this attribute show the current filter parents;

The data received by 26 when new information is sent from the house components 40, 41, 42, 43, 44, 45, etc. isn't standard and the clients software 30. C, 31. C, 32. C, etc. is expecting information that can be translated to the user. In the main server 50, the "server devices" 25 are responsible to convert that data into a specific standard format which allows a more efficient communication between both parties.

The following list of xml nodes shows, as an example, the current data types and new types can be added when needed at any moment .

<datatypes>

<datatype name= ="Generic" symbol="" basetype= "numeric" decimals=" 0 " min=" -2147483647" max="21474 83647"/>

<datatype name ="OnOff" symbol="" basetype= "numeric" decimals=" 0 " min=" 0" max="l"/>

<datatype name= "Percent" symbol="%" basetype= "numeric" decimals=" 0 " min=" 0" max="100"/>

<datatype name= "Tristate" symbol="" basetype= "numeric" decimals=" 0 " min=" -1" max="l"/> <datatype name="DateTime" symbol="" basetype="datetime" />

<datatype name="Semaphore" symbol="" basetype="numeric" decimals="0" min="0" max="5"/>

<datatype name="Seconds" symbol="s" basetype="numeric" decimals="0" min="-2147483647" max="2147483647"/>

<datatype name="Lux" symbol="Lux" basetype="numeric" decimals="0" min="-2147483647" max="2147483647"/>

<datatype name="Fahrenheit " symbol="°F" basetype="numeric" decimals="2" min="-2147483647" max="2147483647"/>

<datatype name="Celsius " symbol="°C" basetype="numeric" decimals="2" min="-2147483647" max="2147483647"/>

<datatype name="Kelvin" symbol="K" basetype="numeric" decimals="2" min="-2147483647" max="2147483647"/>

</datatypes>

NAME - A generic name to differ every data type, this value is only used internally;

SYMBOL - If a specific symbol is needed to be shown to the user in 30. B, 31. B, 32. B, etc. when this data type is used it will be placed here. The symbol intends to give a meaning to the value shown;

BASETYPE - Used to distinguish between numerical values and data/time values;

DECIMALS - In a numerical value this attribute specifies how many decimals will be regarded;

MIN - The minimal possible value for the numerical value; MAX - The maximal possible value for the numerical value;

House components 40, 41, 42, 43, 44, 45, etc. can differ from each but also can have similar functions. Grouping different components into a single one to allow the user to interact with them as if only one raises the need to define an abstract concept and therefore the interface conceit was implemented. An interface is an abstract type that exposes specific members that can receive or send information. Several devices 12 are bundled into one allowing a more efficient way to control the entire group and for that purpose each one of those devices 12 need to implement the same interface. New interfaces can be added at any moment, as an example, the following xml list shows the currently used ones .

<interfaces>

<interface name="ButtonReading" desc="ButtonReading">

<member name="pressed" desc="" datatype="OnOff" /> <member name="released" desc="" datatype="OnOff" />

</ interface>

<interface name="ButtonReadingExt" desc="ButtonReadingExt">

<member name="pressed" desc="" datatype="OnOff" /> <member name="released" desc="" datatype="OnOff" /> <member name="click" desc="" datatype="OnOff" />

<member name="doubleclick" desc="" datatype="OnOff" /> <member name="longclick" desc="" datatype=" " />

</interface>

<interface name="DetectorReading" desc=" ">

<member name="idle" desc="" datatype="OnOff" />

<member name="detect" desc="" datatype="OnOff" />

</interface>

<interface name="EnergyMeter" desc=" ">

<member name="consumpt ion" desc="Corrent consumption" datatype="Generic" />

<member name="maxconsumption" desc="Max. allowed power (watts)" datatype="Generic" />

</interface>

<interface name="LuxReading" desc=" "> <member name="lux" desc="" datatype="Lux" />

</ interface>

<interface name="OnOffAutoControl" desc=" ">

<member name="enabled" desc="" datatype="OnOff" /> <member name="control" desc="" datatype="OnOff" /> <member name="state" desc="" datatype="OnOff" />

<member name="lock" desc="" datatype="Semaphore" />

</ interface>

<interface name="OnOffControl" desc=" ">

<member name="cont rol" desc="" datatype="OnOff" /> <member name="lock" desc="" datatype="Semaphore" />

</interface>

<interface name="PercentControl" desc=" ">

<member name="control" desc="Device On/Off control" datatype="OnOff" />

<member name="percentcontrol" desc="Device percent control" datatype="Percent" />

<member name="lock" desc="" datatype="Semaphore" /> </ interface>

<interface name="RGBControl" desc=" ">

<member name="redcont rol" desc="Red on/off control" datatype="OnOff" />

<member name="redpercent" desc="Red percent control" datatype="Percent" />

<member name="greencont ol" desc="Green on/off control" datatype="OnOff" />

<member name="greenpercent " desc="Green percent control" datatype="Percent" />

<member name="bluecont rol" desc="Blue on/off control" datatype="OnOff" />

<member name="bluepercent " desc="Blue percent control" datatype="Percent" /> <member name="whitecontrol" desc="White on/off control" datatype="OnOff" />

<member name="whitepercent " desc="White percent control" datatype="Percent " />

<member name="lock" desc="" datatype="Semaphore" /> </interface>

<interface name="Signal" desc=" ">

<member name="control" desc="" datatype="Generic" /> </interface>

<interface name="TemperatureReading" desc=" ">

<member name="imperial" desc="" datatype="Fahrenheit "

/>

<member name="met ric" desc="" datatype="Celsius" /> </ interface>

<interface name="TristateCont rol" desc=" ">

<member name="control" desc="" datatype="Tristate" /> <member name="lock" desc="" datatype="Semaphore" />

</interface>

<interface name="TristatePercentControl" desc=" ">

<member name="control" desc="Device direct control" datatype="Tristate" />

<member name="percentcont rol" desc="Device percent control" datatype="Percent " />

<member name="progress" desc="Device current percent state" datatype="Percent" />

<member name="calibrate" desc="Start tristate position calibration" datatype="OnOff" />

<member name="lock" desc="" datatype="Semaphore" /> </interface>

</ interfaces>

Interface NAME - A name to distinguish each interface; Interface DESC - An attribute to add extra information if needed;

Member NAME - A name to identify the member inside an interface, also this field can be easily accessed by "Interface NAME" . "Member NAME";

Member DESC - An attribute to add extra information if needed;

Member DATATYPE - The type of the data used by this member. It needs to be one of the "datatypes" previously defined and this linkage needs to be assured by IB;

For a more efficient filtering the devices 12 are provided with a specific type which also assigns them a specific interface (previously described) . This not only works as a more precise filter for the house components 40, 41, 42, 43, 44, 45, etc. but also enables an easier grouping of the devices 12. A device type can be added at any moment and as seen below they can implement the same interface. The following list shows as an example the currently used devices types .

<devtypes>

<devtype name="Button" iface="ButtonReading" desc=""/>

<devtype name="ButtonExt " iface="ButtonReadingExt " desc=" "/>

<devtype 'Light Dimmer" iface="PercentControl " desc=" "/>

<devtype 'Light On/Off" iface="OnOffControl" desc=" "/>

<devtype name="Leds RGB" iface="RGBControl" desc=""/> <devtype name="Power Plug" iface="OnOffControl" desc=""/> <devtype name=" Siren" iface="OnOffControl" desc=""/> <devtype name=¹¹Water Pum On/Off" iface="OnOffControl " desc=" "/>

<devtype name=" Irrigation" iface="OnOffControl" desc=""/> <devtype name="Heating On/Off" iface="OnOffAutoControl" desc=" "/>

<devtype name="Blinds " iface="TristateControl" desc=""/> <devtype name="Blinds Percent" iface="TristatePercentControl" desc=" " />

<devtype name="Curtains " iface="TristateControl" desc=" "/>

<devtype name="Curtains Percent" iface=" ristatePercentControl" desc=" "/>

<devtype name="Motion Sensor" iface="DetectorReading" desc=" "/>

<devtype name="Smoke Sensor" iface="DetectorReading" desc=" "/>

<devtype name="Flood Sensor" iface="DetectorReading" desc=" "/>

<devtype name=" Temperature Sensor" iface="TemperatureReading" desc=" " />

<devtype name="Lux Sensor" iface="LuxReading" desc=""/> <devtype name="Energy Meter" iface="EnergyMeter" desc=" "/>

<devtype name="Virtual Signal" iface="Signal" desc=""/> <devtype name="Door Contact" iface="DetectorReading" desc=" "/>

<devtype name="Window Contact" iface="DetectorReading" desc=" "/>

<devtype name="Gas Detector" iface="DetectorReading" desc=" "/>

<devtype name="Gas Valve" iface="OnOffControl " desc=""/> <devtype name="Water Valve" iface="OnOffControl" desc=" "/> <devtype name="Door Bell" iface="OnOffControl" desc=""/> <devtype name="Door" iface="OnOffControl" desc=""/>

<devtype name="Gate" iface="OnOffControl" desc=""/>

<devtype name="Door Percent" iface="TristatePercentControl" desc=" "/>

<devtype name="Gate Percent" iface="TristatePercentControl" desc=" "/>

<devtype name="Door Tristate" iface="TristateCont rol ¹¹ desc=" "/>

<devtype name="Gate Tristate" iface="TristateControl " desc=" "/>

</devtypes>

NAME - A name to differentiate each device type;

IFACE - The selected "interface" to interact with this type of device. It needs to be one of the "interfaces" previously defined and this linkage needs to be assured by

IB;

A "device" (shown below) represents a house component 40, 41, 42, 43, 44, 45, etc. There are several prerequisites that are needed to allow an improved interaction with those components. Each "member" of the "device" expands a property that receives and/or sends information to the main server 50. For an instance if the "member" name was "percentcontrol" (appears in the "interfaces" above) , this member would allow the user to see or set the percentage value for a component, in a blind, zero would be the state closed and one hundred would be the state completely open, also in a dimming lamp, zero would be the state off and on hundred the light would be completely on.

All "devices" must preferably belong to a specific device type ("devtype") and this means they will have a specific "interface". The members that an "interface" possesses will be bestowed to the "device" allowing it to be controlled in a specific group. A device that is a group will be a virtual representation of several house components 40, 41, 42, 43, 44, 45, etc. and not an actual component itself. The "device" can support more "members" besides the ones used by the interface allowing a more precise control when the user specifically intends to interact with that component .

<devices>

<device id="" idname="" name="" desc="" divisions=" ¹¹ devtype="" group="" stateless="" visible="">

<member name="" address="" basetype=" "/>

</device>

</devices>

Device ID - An identifier to distinguish each device, this value will also be used in 25;

Device IDNAME - Another identifier to distinguish each device, this value will also be used in 25;

Device NAME - If a name needs to be shown to the user in 30. B, 31. B, 32. B, etc. this will be the value used;

Device DESCR - An attribute to add extra information if needed;

Device DIVISIONS - The several divisions 10 where this device can be seen;

Device DEVTYPE - The type of the device that component belongs to. It needs to be one of the "devtypes" previously defined and this linkage needs to be assured by IB;

Device GROUP - If this device belongs to a group, values used are true and false; Device STATELESS - If this device will show any information to the user in 30. B, 31. B, 32. B, etc., values used are true and false;

Device VISIBLE - If the device will be shown to the user in 30. B, 31. B, 32. B, etc., values used are true and false;

Member NAME - The name of the member, this member can belong to the subscribed "interface" or it can be a new one;

Member ADDRESS - An address used to communicate in 26 with the specific component that this device 25 represents;

Member BASETYPE - Used to distinguish between numerical values and data/time values that this member can have;

The file 54 injected in 50 also needs to comply with a specific structure when providing data for new environments 24, routines 23 and components 40, 41, 42, 43, 44, 45, etc.

Environments need to have specifics actions defined to generically simulate almost every day to day situation. Those actions can be over a specific device 25, environment 24 or also the imposition of a delay between actions, this can be really useful, for an instance if a "water the front lawn" environment is created the user can activate a sprinkler and then wait a set amount of time before activating the next one preventing the grass from being too dank. Some environments are aimed to the maintenance of the system and they can't be shown to the user. Taking all these facts in considerations the basic environment structure as an example was defined as follows;

<environments>

<environment id="" name="" access="">

<actions>

<device id="" member="" value="" /> <delay timespan="" />

<environment id="" state="" />

</actions>

</environment>

</environments >

Environment ID - An identifier to distinguish each environment, this value will also be used in 24;

Environment NAME - If a name needs to be shown to the user in 30. B, 31. B, 32. B, etc. this will be the value used;

Environment ACCESS - Declares if the environment is accessible by the users or if it is only a system environment ;

Actions Device ID - Identifies which device will be executed;

Actions Device MEMBER - The member that will be modified by this action;

Actions Device VALUE - The value applied to the device member;

Actions Delay TIMESPAN - Delineates a delay between actions, this field represents a time value which will need to be abide before the following action can be executed; Actions Environment ID - Identifies which environment will be executed;

Actions Environment STATE - Activates or deactivates the environment, usually it is only used to activate the environment but can also be used to set the environments devices to their previous states;

A routine is basically an environment that does not need a direct action overt it. Routines 23 can execute themselves whenever there triggers conditions are met, since routines 23 are self sufficient they validate themselves in the main server 50. Being extremely similar to environments only the triggers differ in their structure. Devices 25 states and dates are basic elements for a routine to execute and accordingly to that the next structure was generated, as an example :

<routines>

<routine id="" name="" access="">

<triggers>

<device id="" member="" value="" operation="" />

<datetime dayofweek="" time="" date="" />

</ triggers >

<actions>

<device id="" member="" value="" />

<delay timespan="" />

<environment id="" state="" />

</actions>

</routine>

</routines >

Routine ID - An identifier to distinguish each routine, this value will also be used in 23;

Routine NAME - If a name needs to be shown to the user in 30.B, 31. B, 32. B, etc. this will be the value used;

Routine ACCESS - Declares if the routine is accessible by the users or if it is only a system routine;

Triggers Device ID - Identifies which device will be checked for any changes in its members;

Triggers Device MEMBER - The member that will be verified; Triggers Device VALUE - The value expected to activate the trigger;

Triggers Device OPERATION - Can have several options which will compare if the current device value is "Equal", "Lesser Then", "Lesser or Equal", "Bigger Then", "Bigger or Equal" and "Different" to the triggers value;

Triggers Datetime DAYOFWEEK - The days of the week in which the routine can take effect;

Triggers Datetime TIME - The hours of the day in which the routine can take effect;

Triggers Datetime DATE - The date in which the routine can take effect;

Actions Device ID - Identifies which device will be executed;

Actions Device MEMBER - The member that will be modified by this action;

Actions Device VALUE - The value applied to the device member;

Actions Delay TIMESPAN - Delineates a delay between actions, this field represents a time value which will need to be abide before the following action can be executed; Actions Environment ID - Identifies which environment will be executed;

Actions Environment STATE - Activates or deactivates the environment, usually it is only used to activate the environment but can also be used to set the environments devices to their previous states;

The devices structure resembles with the one previously exposed by the xml file 53 since its important all the information about the house components 40, 41, 42, 43, 44, 45, etc. Both structures basically mainly differ in their members because the first one (file 53) is designed for the interfaces 30. B, 31. B, 32. B, etc. to communicate with the main server 50 (which is already standardized) and this one is targeted to the house components 40, 41, 42, 43, 44, 45, etc (they differ from each other) . Every member has an address to communicate with the component, also what defines if that data should preferably be sent, received or even both must preferably be specified in it. Since all components 40, 41, 42, 43, 44, 45, etc. are independent they have their own communication protocol, consequently, a generic approach must preferably be taken to provide a concise and flexible way to relate all of them and that leads to the use of regular expressions to match every protocol specifications. Some protocols are simpler which eliminates the necessity to generalize the command to be sent or received therefore each member can either have a static command or a regular expression depending on the protocol requirements.

<devices>

<device id="" name="" divisions="" devtype="" group="" stateless="" visible="">

<member name="" address="" outputinput=" " command=""/>

</device>

</devices>

Device ID - An identifier to distinguish each device, this value will also be used in 25;

Device NAME - If a name needs to be shown to the user in 30. B, 31. B, 32. B, etc. this will be the value used;

Device DIVISIONS - The several divisions 10 where this device can be seen;

Device DEVTYPE - The type of the device that component belongs to. It needs to be one of the "devtypes" previously defined and this linkage needs to be assured by IB;

Device GROUP - If this device belongs to a group, values used are true and false; Device STATELESS - If this device will show any information to the user in 30.B, 31. B, 32. B, etc., values used are true and false;

Device VISIBLE - If the device will be shown to the user in 30.B, 31.B, 32. B, etc., values used are true and false;

Member NAME - The name of the member, this member can belong to the subscribed "interface" or it can be a new one;

Member ADDRESS - An address used to communicate in 26 with the specific component that this device 25 represents;

Member OUTPUTINPUT - Discloses if the member is used to receive data, send data or both;

Member COMMAND - A regular expression or a direct command to allow the communication between 26 and the respective component 40, 41, 42, 43, 44, 45, etc.

FIG. 4 is a schematic view of the changes that occur when a component 40, 41, 42, 43, 44, 45, etc. is interacted with. When a component 40, 41, 42, 43, 44, 45, etc. state is changed, either by user interaction, programmed task, etc. (represented by 70) that data is provided to the main server 50 through 52 (all new data sent is represented by 701) which will deliver it to 26. After receiving any valid data, 26 sends it to 25 in order to determine if the data contains new relevant values to be stored. If the data does not contain any new information all activity will end here otherwise two steps will be taken; validation of the routine triggers and the update of all clients 30. C, 31. C, 32. C, etc.

To perform all necessary changes to the clients 30. C, 31. C, 32. C, etc. a message is sent to each one reporting the existence of new information, every active client will then request the latest data to the main server 50 (represented by 702) . The received data will be verified again in 1A because communication breaks can occur due to several factors (e.g. LAN connections failed, etc.), after validated, if interface changes need to occur (in this case a device state changed), 30. B, 31. B, 32. B, etc. will update themselves as less intrusively as possible (all these steps are represented as 71) .

All routine triggers are listed in 23 and after receiving the necessary data from 25 (represented by 703) a fast search will take place in order to find the triggers that use the device in question. If a trigger is satisfied with the data from the device 25 and all other triggers of the same routine 23 are also satisfied, the routine 23 will execute by sending its device related actions to 25

(represented by 704) . The actions sent to 25 will be addressed to 26 which will send the proper command

(represented by 705) to the respective component 40, 41, 42, 43, 44, 45, etc. (72 represents all components that will be changed) .

By executing a routine 23 the components 72 will be changed and therefore a cycle begins because this will lead us back to 70. The cycle will end if 704 does not happen which means that no routine triggers where validated and no further actions are needed.

FIG. 5 is a schematic view of the changes that occur when a component 40, 41, 42, 43, 44, 45, etc. is added to the main server 50.

To add a new cDomponent to the main server 50 it is necessary to replace 54 using 60. Specific information must preferably be filled for the proper xml to be generated. The following basic example will be taken in consideration and the xml code below will be referenced as 80 from now on . <device id="0000001" name="Table Light" divisions="Living Room" devtype="Light On/Off " group=" false" stateless=" false" visible="true">

<member name="control" address=" 192.168.1.100 " outputinput="both" command="0 | l"/>

<member name="lock" address="" outputinput=" " command=" " />

</device>

A simple light (only uses On and Off commands) will be added to the main server 50, as it can be seen the light is named "Table Light" and will be place in a division called "Living Room". To manage the new light 26 will have to connect to the address "192.168.1.100" and send either the value "1" or "0", also 26 will be expecting a value "1" or "0" if any communication is received from that component because as it can be seen the option "outputinput" exposes that this is a two way communication component (unmatched commands are ignored) .

Taking this example in consideration, after 60 generates 80, it will replace the file 54 with an updated one, also do note that old data must preferably be repeated otherwise 50 would assume that the previous data was discarded. When 54 is changed 20 will take notice that new parameters where added or removed and the proper rules 200 will be generated and sent to 21.

The distributor object 21 will verify if any code needs to be loaded to execute in runtime and in case that another "Light On/Off" was already in the main server no changes will be made. Both 23 and 24 will be disregarded because no environments or routines where added or removed from 54.

Since this is a light that is going to be visible to the user ( visible="true") the necessary rules will be sent to 22 for it to create the specific formatted xml 53 intended for the clients 30.A, 31.A, 32.A, etc. A communication addressed to 30. C, 31. C, 32. C, etc. will be made to announce that new parameters where added and all the active clients 30.A, 31.A, 32.A, etc. (the active clients are represented by 81) will retrieve this new data to update their 1A (the communications made are represent by 800) . The new added component will also be represented as a virtual device in 25 when the proper component rules 204 are sent. After generating the device in 25 the necessary data is assigned to 26 for it to make an initial validation of the communications between the main server 50 and the new added component 82 (the communications are represented by 801) . All the communications 801 may fail if 82 is not currently available or properly installed. Such failures does not affect the system behavior because both the main server 50 and the components 40, 41, 42, 43, 44, 45, etc. may work independently. Allowing such a process raises the possibility to pre-configure the main server 50 before installing it in the users' house. This also promotes and ensures the so much intended non intrusion.

The following claims set out particular embodiments of the invention .

Claims

C L A I M S

Residential multiple-play device control integrated communication system comprising:

main server (50) ;

multi-protocol and multi-equipment layer (1A, IB);

physical subsystems (40, 41, 42, 43, 44, 45);

common user interface (30B, 31B, 32B) ;

able to abstract divisions (10) and respective hierarchy, devices (12), routines (13) and respective actions (14) and trigger (15) conditions, environments (11) and respective hierarchy of actions (14) .

The system according to the previous claim where the multi-protocol and multi-equipment layer (1A, IB) comprises :

an xml file (54) generator module (60) and parameter verifier module (20), said xml file (54) being able to describe address, display and action properties of a specific device (12), said parameter verifier module (20) being able to export a set of rules (200) to the data converter and distributor module (21);

a data converter and distributor module (21) able to select the necessary code for runtime execution by main server (50) and also able to filter a set of rules (200) to the client specification module (22);

a client specification module (22) able to convert the filtered xml content (201) into a xml format especially adapted to the devices (12), said xml file or files (54) also being able to describe routines for a routine module (23) , environments for an environment module (24), device rules for a server device module (25), through the data converter and distributor module (21) which is also able to validate and filter the data (202, 203, 204);

a virtual device representation module (25) , able to virtually represent said devices (12);

a device control module (26) able to filter unnecessary data to said virtual device representation module (25) .

3. The system according to the previous claims wherein said main server (50) comprises:

communication module (51) for user interface (30B, 31B, 32B) and communication (30D, 31D, 32D) devices;

communication module (52) for devices (40, 41, 42, 43, 44, 45);

cache (53) of filtered (201) xml content (54) in a format especially adapted to the devices (12);

execution capabilities for said multi-protocol and multi-equipment layer (IB) .

The system according to the previous claims wherein said virtual device representation module (25) comprises: a division filter comprising its name and its parent filters ;

a list of data types comprising its name, type and optionally user symbol, decimal digits, minimum and maximum values;

device abstraction interface comprising its name, members and respective data types, and optionally respective descriptions;

a list of device types, comprising its name and the respective device abstraction interface;

a device list comprising the respective device identifier and type, and its members and the respective device abstraction interface, which in turn comprises properties and the respective data type.

The system according to the previous claims wherein said environment module (24) comprises an environment list, comprising for each environment its identifier, name and access, respective action device identifiers, members, values and delays, and respective executable environment identifiers and states.

The system according to the previous claims wherein said environment module (23) comprises a routine list, comprising for each routine its identifier, name and access, respective trigger device identifiers, members, values, operations, dates, time and days of the week, respective action device identifiers, members, values and delays, and respective executable environment identifiers and states.

The system according to the previous claims wherein said virtual device representation module (25) device list comprises device identifier, name, divisions where it is to be accessed, device type, group, actionable status, user visibility and respective members comprising names, addresses, output and input capabilities, and command strings .

8. Residential multiple-play device control integrated communication system operation method comprising the steps of:

abstracting divisions (10) and respective hierarchy, devices (12), routines (13) and respective actions (14) and trigger (15) conditions, environments (11) and respective hierarchy of actions (14);

generating (60), inputting and verifying parameters (20) of an xml file (54), said file comprising address, display and action properties of a specific device (12); exporting by a parameter verifier (20) a set of rules (200) to a data converter and distributor module (21); selecting by the data converter and distributor module (21) the necessary code for runtime execution by main server ( 50 ) ;

filtering a set of rules (200) to the client specification module (22);

converting by the client specification module (22) the filtered xml content (201) into a xml format especially adapted to the devices (12);

validating and filtering the data (202, 203, 204) through the data converter and distributor module (21) of said xml file or files (54) which comprise the description of routines for a routine module (23) , environments for an environment module (24) and/or device rules for a server device module (25) .

9. The method according to the previous claim further comprising the steps of:

virtually representing said devices (12) by a virtual device representation module (25) ;

filtering unnecessary data to said virtual device representation module (25) by a device control module (26) .

10. The method according to the claims 8 - 9 wherein it further comprises the following steps for device (12) interaction : changing (70) device (12) state;

providing new data (701) to the main server (50), specifically to the device control module (26) , through the device communication module (52);

sending the data to the virtual device representation module (25) ;

verifying existence of new information, if not quit processing;

validating of routine triggers and respective client updating (30C, 31C, 32C) .

11. The method according to the previous claim wherein the client updating (30C, 31C, 32C) comprises the steps of:

sending an update message to each client (30C, 31C, 32C) ;

requesting by the clients (30C, 31C, 32C) to main serve server (50) of the new information;

validating received data by a multi-protocol and multi- equipment layer (1A);

updating (71) interfaces (30B, 31B, 32B) .

12. The method according to the previous claim wherein the trigger validation comprises the steps of:

receiving (703) necessary data from the virtual device representation module (25) ;

searching by the routine module (23) , for the respective triggers of the device in question;

verifying if all triggers for the routine are satisfied; if positive, then executing the routine actions by its commands (705) to affected devices (72);

if negative (704), verifying remaining routines and when all done, quit processing; returning to the initial step of changing (70) device (12) state.

13. The method according to the claims 8 - 12 comprising the following steps when adding a new device to the system:

replacing (60) said xml file (54) with updated xml (80); verifying new information by the parameter verifier module (20) ;

exporting a set of rules (200) to the data converter and distributor module (21) ;

verifying runtime needed code by the data converter and distributor module (21);

converting by the client specification module (22) the filtered xml content (201) into a xml format especially adapted to the devices (12), and storing (53) it;

sending (800) updated information to all active (81) clients (30A, 31A, 32A) ;

validating and filtering the data (202, 203, 204) through the data converter and distributor module (21) of said xml file or files (54) which comprise the description of routines for a routine module (23) , environments for an environment module (24) and/or device rules for a server device module (25) ;

filtering unnecessary data to said virtual device representation module (25) by the device control module (26) ;

validating communications (801) between main server (50) and the newly added device (82) .

14. The method of operating a data processing system comprising the steps of any of the preceding claims 8 - 13. A computer program comprising code means adapted perform all the steps of claim 14 when said program run on a data processing system.

The computer program according to the previous cl embodied on a computer-readable medium.