MXPA01001964A - Bridging multiple home network software architectures - Google Patents

Abstract

Home networks of different software architectures are integrated with each other. References to software representations of devices and services on a first one of the networks are automatically created. The references are semantically sufficient to enable automatic creation of at least partly functionally equivalent software representations for a second oneof the networks so as to make the devices and services of the first network accessible from the second network.

Description

Bridge of multiple home network software architectures FIELD OF THE INVENTION The invention relates to a system and a method that allows the cooperation of networks that are of possibly different software architectures, such as the HA Vi home network and a Home API or JINI base network.

BACKGROUND Home networks and related software architectures, such as JINI of Microsostemas Sun, Ine, (http: // www sun com < nn, HA Vi (http: // www haví orqj, Home API (http, ',' wwv, homeapi.org), Universal-plug and-play (UPnP) from Microsoft (http.///v?- w.upnp.org). They are now available to the application developers, device manufacturers and service providers.

Software architecture HAVi HAVi is related to the API = s center (application programming interfaces) for digital consumer electronics in a home network as well as to provide a standard for audio and video electronic devices and multimedia industries. API specifies the method that is required to make requests to an operation system or an application program. The home network is considered a distributed computing platform. The main objective of the standard, which is referred to as the HAVi (domestic audio / video interoperability) architecture, is to ensure that the products of different vendors can interoperate, that is, cooperate to perform application tasks. The current CE devices (electronic controller), such as domestic entertainment equipment (DVD, video camera DV, digital TV equipment, etc.) are digital processing and storage systems. Connecting these devices in networks makes it possible to share processing and storage resources, which makes it possible to coordinate the control of several CE devices at the same time and simplifies user interaction. For example, a first apparatus can record a particular example in a second apparatus, while having access to an EPG (electronic program guide) in a third apparatus. The home network provides the structure to connect the CE devices, which allows connected devices to exchange control (one device sending an order to another) and video audio data (one device sending an audio or video stream to another device) . The network has to meet several requirements to achieve all of the above. It must support constant transfer of AV (audio / video) currents of aita data rate. The network must support auto configuration, self-management and connection and intense work. Requires inexpensive wiring and interfaces. The HAVi software architecture has an independent platform and is based on Java. HAVi uses the bus protocol of the IEEE 1394 high-performance series for control and content transport between devices connected to the network. The IEEE 1394 standard is a digital network with a low cost and dynamic configuration that defines both the physical layer of the posterior plane and the implementations of the virtual collective conductor connected to the cable from point to point. The version of the backplane operates at 12.5, 25 or 50 Mbits / sec. The cable version supports data rates of 100, 200 and 400 Mbps. The standard specifies the medium, the topology and the protocol. The 1394 transport protocol of the IEEE is very useful to support the audio and video communication protocols due to its large capacity of data proportion.

The HAVi architecture controls the EC devices in the network through abstract representations of the CE devices. The abstract representations are operated by a controller and hide the idiosyncrasies of the real CE devices associated. In this way, the abstract representation provides a uniform interface for higher software levels. Abstract representations are recorded with their control properties and reflect those of the represented apparatus. The abstract representations expose their interoperability API = s towards the applications and collectively form a group of services for the construction of portable applications distributed in the domestic network. The architecture allows a device to send a command or control information to another device in the home network. A docile HAVi device contains data (above abstract representation, referred to as the device control model or DCM, see below) that relate to the user interface (eg, GUI) and control capabilities. The data includes HAVi bytecode (Java) that can be loaded and executed by other devices in the network. A docile HAVi device has, at least, sufficient functionality to communicate with other devices in the system. During the interaction, the devices can exchange control and data as equals, which ensures that at the level of communication, it is not necessary for any of the devices to act as the master or controller of the system. On the other hand, this allows a logic master or controller to impose a control structure on the basic peer-to-peer communication model. HAVi distinguishes between controllers and controlled devices as will be explained later. A controller is a device that acts as a host for the controlled device. The controller offers the abstract representation for the controlled device. The control interface is exposed through the abstract representation API. This API is the access point of the applications to control the device.

The docile CE HAVi devices are devices that are classified as follows: total AV devices (FAV = s), intermediate AV devices (IAV = s) and base AV devices (BAV = s). An FAV contains a complete set of software components of the HAVi software architecture (see below). An FAV is characterized because it has an operating time environment for the HAVi bytecode, which allows an FAV to load the bytecode from other devices, for example, it provides better capabilities for its control. A FAV can be formed with a docile HAVi Set Top box, a docile HAVi digital TV receiver, and a home PC. For example, an intelligent TV receiver can be the HAVi controller of other devices connected to the network. The receiver obtains a loaded bytecode from another device to create an Ul for this device and to provide external control of this device. It is possible to present an icon of this device that appears on the TV screen and the interaction of the user with the icon may cause the elements of the control program to operate the apparatus represented in a previously specified manner. An IAV does not provide an operating time environment for the HAVi bytecode, but can provide native support for the control of specific appliances in the home network. An IAV comprises inserted software elements that provide an interface for controlling the general functions of specific devices. It is necessary that these software elements are not HAVi bytecode and can be implemented as native applications in the IAV that uses native interfaces to access other devices. A BAV can provide a rechargeable HAVi bytecode but does not offer any of the software-elements of the HAVi architecture. A BAV can be controlled with an FAV by means of the current loaded bytecode. A BAV can be controlled with an IAV using the native code. The communication between a FAV or IAV, on the one hand, and a BAV on the other side requires that the HAVi bytecode be translated to and from the command protocol used by the BAV.

The main elements of the software included in the specification of the center of the HAVi architecture are the ones listed below. For a more detailed explanation of these elements, please see the HAVi specifications, which will be included as a reference. 1) A 1394 media manager (CMM) - acts as an interface between the other elements of the software and 1934 of the IEEE. 2) An Event Manager (EM) - informs the various software elements of events on the network, such as changes in the network configuration that occur when devices are added or removed from the network . 3) A registry - keeps information about the devices connected to the network and the functions they offer. Applications can obtain this information from the registry. 4) A message system (SM) - serves as an API that facilitates communication between the software elements of the various devices in the network. The message system provides the elements of the HAVi software with communication facilities. It is independent of the network and transport layers. Any FAV and IAV has the message system, which is responsible for assigning identifiers for abstract representations in the FAV or IAV. These identifiers are used first by abstract representations to register in the AVF or IAV. Then, abstract representations use them to identify each other within the home network. When a first abstract representation wants to send a message to another abstract representation, it has to use the latter's identifier while invoking the message API. 5)? N device control module (DCM) - represents a network device. The application programs can interact directly with the DCM, which protects them from the idiosyncrasies of each individual device. 6) A DCM administrator - install the DCMs. Reacts automatically to changes in the network when installing new DCMs for new devices. 7) A data management interaction controller (DDI) - gives a GUI (graphical user interface) in the presentation of a device = s in favor of a HAVi software element. It supports a variety of presentations, which vary from graphics to text only. A DCM can provide a user interface (Ul). The DCM can present the Ul to one or more devices in the network that have a presentation. One mechanism to achieve this is called DDI (data management interaction). When using this mechanism, a DCM can offer a description of the DD1 of its Ul. Any docile HAVi device with presentation can retrieve the description. The user can interact with the Ul through the local presentation. A user interaction results in messages sent to the associated DCM for control of the physical apparatus represented by the DCM. 8) A current manager (SMGR) - creates connections and real-time routes of AV currents between two or more devices in the network. The HAVi architecture specifies at least two interoperability levels, which are referred to as level 1 and level 2. Interoperability level 1 addresses the general need to allow existing devices to communicate at a basic level of functionality. To achieve this, interoperability level 1 defines and uses a generic group of control messages (commands) that allows one device to communicate with another, and a group of event messages that are expected from a given device. (TV, VCR, DVD player, etc.). To support this method, a basic set of mechanisms is required: device discovery; communication; and a HAVi message team. Respected the discovery of the device: each device in the home network needs a well-defined method that allows it to announce its capabilities to others. The HAVi method is to use the so-called SDD data: self-description of data. SDD data is required on all devices in the network. The SDD data contains information about the device that other devices can access. The data of SDD contain, at least, enough information that allows the concrete exemplification of the control module of the inserted device (DCM inserted). An inserted DCM is a piece of code previously installed in an IAV or control FAV in a platform-dependent code that uses native interfaces to access the resources of IAV = s or FAV = s. As already referred to, a DCM for a device is a software element that provides an interface to control the general functions of the device. The installation of an inserted DCM results in the registration of the device properties with a register. The registry provides a directory service and allows any object on the network to locate another object within the network. The registry allows the applications to infer the basic group of command messages that can be sent to a specific device in the network. Regarding communication: once an application has determined the capabilities of a device, the application needs to have access to those capabilities. It requires a general communication fadiidad that allows applicadones issue requests to appliances. The HAVi message systems and the DCMs provide this service. The application sends HAVi messages to the DCMs, then the DCMs engage in a patented conversation with the devices. Regarding HAVi message groups: to support interoperability level 1, a well-defined group of messages is required, which must be supported by all devices of a particular known type (for example, the data of the TV receivers, the VCR = s, the data of the DVD players, etc.). This ensures that an appliance can work with existing appliances, as well as with future appliances, regardless of the manufacturer. These three basic requirements support the minimum level of interoperability. Because any device can challenge the other's capabilities through registration, any device can determine the group of messages that another device supports.

Since the applications have access to the message system, any device can interact with another device. Interoperability level 1 ensures that the apparatus can interoperate at the basic level of strength. However, a more extended mechanism is needed so that an apparatus also communicates with other apparatuses with any adidonal fonnality that is not present in the DCM = s inserted in an FAV. For example, the DCM = s inserted may not support all the characteristics of the existing products and is unlikely to support the totally new of future product categories. Level 2 of interoperability is the purpose of this mechanism. To achieve this, the HAVi architecture allows DCM = s rechargeable as an alternative for the DCM = s inserted beforehand. The loaded DCM can replace an existing DCM in an FAV. Any suitable source can provide a rechargeable DCM, but a probable technique is to place the rechargeable DCM in the HAVi SDD data of the BAV device, and load from the BAV to the FAV device when the BAV is connected to the home network. Because the HAVi architecture is vendor-neutral, it is necessary that the loaded DCM is based on a variety of FAV devices that have potentially different hardware architectures. To achieve this, the loaded DCMs are implanted in the HAVi (Java) bytecode. The HAVi bytecode operation time environment in the FAV devices supports the specific exemplification and execution of the loaded DCMs. Once it is created and built into an FAV device, the DCM communicates with the BAV devices in the same way as described above. The efficiency of level 2 interoperability will be given when it is considered that sources are needed to have access to the strength of a specific device. Level 2 allows a device to be controlled by a charged DCM that presents all the capabilities offered by the device, while, to achieve similar functionality at level 1, this DCM should be inserted somewhere in the network . For example, when a new device is added to the network, level 1 requires that at least one other device have an inserted DCM that is compatible with the new device. In comparison, level 2 only requires that an apparatus provide an operating time environment for the charged DCM that is obtained from the new apparatus. The concept of loading and executing the bytecode also provides the possibility for specific applications of the device called appliance control applications. Through these applications, the manufacturer of a device can provide the user with a way to control specific features of an appliance without having to standardize all the features in HAVi. The application is provided by a DCM in HAVi bytecode and can be loaded and installed by each FAV device in the network. For more information, the reference is made for the HAVi specification and the 1394 IEEE specification that are in the public domain. The HAVi center specification is available on the network, for example at http: www.sv phiHips.com/news/press, and appears here as a reference.

Home API architecture A Home API system is made up of software services and application programming interfaces (APNs) that allow software applications to be based on a PC to discover and interact with controllable devices registered with the system. . The domestic environment can include devices such as TV = s, VCR = s, set top boxes, home security systems, lights, etc. The Home APNs have an independent protocol and hidden differences in the underlying networks and transparent apparatus-level communication protocols from the software applications. The way in which the application has access to a device is uniform and independent of the underlying protocol used for communicating with the device. The applications of the software interact with the devices when establishing or obtaining properties of the software objects created to represent those devices. Applications can also subscribe for events that involve changes in ownership of the device = s in order to notify such changes. The Home API architecture consists of components called service providers. These components are dedicated to underlying devices and networks and are used to translate high-level operations into the properties of software objects into commands that are sent to associated devices through the network. Service providers implement the Home API software objects. The component of the service provider is also responsible for generating the events of the change of ownership for the objects associated with the service provider. In detail, the Home API uses a computer model that is based on the technology of the model object component (COI DCOM, for its acronym in English) of Microsoft. For more information, see the Specification of the model object of the component version 0.9 of October of 1995 that Microsoft supplied, here it is incorporated as reference. COM is oriented to the object. An object has properties that represent control functionalities of an associated electronic device as set forth for a software application. A change of state of an object as a result of an external event is passed to the software application. The application manipulates the objects when changing or establishing their properties. When the application modifies the ownership of an object associated with a certain physical device, a command is sent to the associated device. COM is a generic mechanism that allows applications to communicate in a consistent manner and is a structure to develop and support objects of the program component. It provides capabilities similar to those defined in CORBA (common object request agent architecture), the structure for the interoperation of distributed objects in a network. OLE (connected and inserted object) provides services for the composite document that. users see in the presentation, COM provides the underlying services of the negotiation of the interface and the services of the events (puts an object in the service as a result of an event that has happened to another object). In this implementation, clients are modeled as OLE automation objects (abstract representations) that use the properties to expose controls and events to signal state changes. OLE automation is a COM technology that allows the preparation in advance and the subsequent joining of the clients to the servers. OLE automation provides communication with other programs through feature calls (commands and issues) that programs have available for external use. Before using an object, the client application must first get the suggestion of the interface of the object = s. The suggestion of the interface is obtained through the directory of the network when joining the name of the object = s or when listing the devices. You can use the standard COM APNs to join the moniker. Object references can be obtained by calling GetObject or CoGetObject specifying the name or device identification desired. Then, the application can manipulate the object when establishing or recovering its properties when calling the property --- asset (Asset) for the appropriate properties. When an application establishes or modifies the property of an object that corresponds to the appliance, the operation that establishes the property or modification operation becomes a command that is sent through the network to the relevant appliance. The objects may differ in the implementation, but they expose a model based on similar properties for the client's applications to work in the controller, for example, a PC with a Windows-based operating system.

JINI architecture JINI simplifies the interconnection of devices in the network. In conventional systems, adding an appliance to a PC or a network requires installation and restarting. In JINI, the device declares its presence and provides information about its functionalities.

There, the device becomes accessible to other resources on the network. This technology allows distributed computing: the capabilities are shared among the resources of the network. JINI focuses on the process of adding a device to the network and transmitting information about the device to other machines. In this way, JINI provides a search service that allows applications on other machines to use the new devices. The JINI method assumes the network and the operating system has already been configured so that each computer knows about the other computers. The JINI functionality occurs to a layer below the network. For example, it does not solve the problems of automatic configuration of the network over connection, disconnection or reconnection. It is assumed that the network goes up and down, regardless of J INI. JINI relieves the services provided by the network to implement its own services. More specifically, the infrastructure of the JINI network provides resources to execute Java programming language objects, the facilities for communication between those objects and the ability to find and exploit services on the network. By using remote invocation of the Java method (RMITM), JINI provides communication between objects across the boundaries of the device, thus allowing those objects to work together. RMI allows the activation of objects and the use of multiple molds to contact duplicate objects, provides objects of great availability and high dependence so that they are easily implanted in the JINI structure. RMI is an extension for the traditional remote procedure call mechanisms. RMI not only allows data to pass from object to object around the network, but also entire objects, including code. Much of the simplicity of the JINI system is based on this ability to move the code around the network in a way that is encapsulated as an object. JINI provides a search service that allows connected services to be found through the communication infrastructure. In addition, JINI provides a mechanism, which is referred to as Discovery / Join - for devices allowed by JINI (for example, disk drives, printers, and computers) to discover the right search service and unite the entire system. When a device joins a JINI base system, its services are added to this search service. Similarly, when a JINI enabled device leaves the system, for example, when it is removed or becomes unstable, its services are removed from the search service. For more information on home networks, especially in HAVi, the use of COM and OLE automation objects and Home API, and in JINI, reference is made to the following documents, here are incorporated as reference: the publicly available specifications of the HAVi architecture (version 0.86), the specification of the model object of the component (version 0.9), the white paper Home API of March 1999 that provides the Home API working group, the general perspective of the JINI architecture of Sun Microsystems, Inc. (includes the Java Remote Invocation Specification, the Java Object Specification Specification, the Java Spaces Specification, etc.). Each of the specific software architectures HAVi, Home API, JINI, etc., has its own advantages and disadvantages. For example, JINI allows Java objects to be transferred from the platform environment of one network to another to work locally. It has the disadvantage that it does not always cover the characteristics of the specific platform. Also, since JINI is based on Java, which is an interpreted language, it can not perform as well as with the native code. HAVi is designed to handle high bandwidth audio and video equipment 1394 of the IEEE. It provides extensibility, through the software components (DDI, Java, etc) that can be downloaded from the devices, and other useful features. On the other hand, devices that do not have a 1394 connection from the IEEE or an interface can not be easily controlled with a HAVi application.

Home API covers the architecture and software services COM DCOM Windows, but it does not have as much availability in other operating systems as in UNIX, LINUX, Apple Mac OS, etc. Because consumers acquire computer or control devices, such as PC = s, Set top boxes, digital TV = s, VCR = s, X10 modules, etc., at different times and for different purposes, it has become important to develop solutions to join home networks and architectures. It is very likely that such software solutions appear on relatively rich computing platforms such as PC = s, Set top boxes, video game machines, etc. Within this context, PC = s that are worth $ 1,000 or less have continued to dominate retail PC sales in 1998 and 1999, with the broadest growth in the segment with prices below $ 600. At present (1999), PC producers Emachines, Packard-Bell and NEC are the main suppliers of this segment of the market. For example, Emachines provides PCs under $ 600 that have features such as DVD, fast Intel 400MHz processors and RAM = s of 32MB. Similar cases are occurring in the segment of video games, where Sega and others have planned to offer 64-bit gaming machines. Most new devices have modems or other connection options in order to allow them to be part of a network. Each of the known software architectures mentioned above provides a service that allows discovering devices or services in the network, from the abstract point of view in a more or less similar mode. As a final result of a discovery process, the software representation of an appliance or service is placed in the search service (or-registry or directory). The HAVi architecture registers discovered devices or registry services, the JINI architecture registers them with the search service, Home API refers to the service as a directory. Registered devices or services appear available for software applications that operate on the host. An application locates the representation of the software or the object and uses it to access the interfaces and reservation procedures of a particular software architecture.

OBJECT OF THE INVENTION Problems arise when a control device houses more than one network environment. For example, a PC with 1394 connection from the IEEE can be part of HAVi as well as the Home API environment. Therefore, there are great possibilities that HAVi audio and video devices are accessible for Home API applications and vice versa, which devices that control Home API can be controlled with HAVi applications, etc. If this potential were noticed in practice, users could perceive these two domestic environments of the network as one, increase the ease of use and improve accessibility options. It would also allow those who develop the software to create applications with a wider range of controllable devices than has been possible at this time. In addition, it is necessary to provide such functionality in order to accommodate the existing architectures and applications of the home network and those that arise. Accordingly, an object of the invention is to provide a method that allows connection between different home network environments and thus increase the functionality of the home network in general.

SUMMARY OF THE INVENTION The method of the invention uses a software component (reference factory) in a network environment. ? I component detects software representations of devices or services available in a first environment network. This can be done by enumerating and / or monitoring a Home API directory, HAVi record, JINI record or service related to the equivalent inventory of the first network. Upon the detection of a new software representation made by the reference factory, the latter creates a reference that is associated with the software representation detected in the first network. Said reference consists of necessary information, for example, a URL, a unique object identifier, an XML or DDI descriptor, etc., for the creation of a representation at least partially functional of the device or service within another software environment. network. Another software component (object factory) capable of creating such software representations (objects) has access to the reference information and makes it available to the other network. If necessary, the object factory creates an object, or retrieves a prefabricated one from a network site given its URL, or passes the reference according to the rules and / or preferences of the network environment with which it interacts. For example, these preferences reflect patterns of general architecture or specific interests of the user. For example, the user is only interested in a certain type of device. Another example is the HAVi environment in which, based on the configuration of the network, only DDI representations are accepted. Multiple reference factories can be presented in a particular software architecture of the network. Each of them is responsible for certain types of references, as well as other network software environments (JINI, HAVi, Home API, UpnP) or other representations of objects within that network (for example, for HAVi: Java DCM, native DDI or DCM data), or a class of appliances / services (data storage, home automation, A / V command group, etc.). The invention is based on the understanding of the two processes of couple: on the one hand, the analysis of the software configuration of the network, and on the other, the creation of the software representations (objects) necessary for the control and / or the interaction. The factory methods of the creation of objects are known in art. For example, see A Design Patterns: Elements of Reusable Object-Oriented Software = -, Addison-Wesley Professional Computing, by Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides, October 1994, Addison-Wesley Pub Co; ISBN: 0201633612, especially pages 81 -1 16.

In particular, the invention relates to a method that allows a first network of a first software architecture to interact with a second network of a second software architecture. The method consists of the following steps: an authorization to detect a first software representation of an appliance or a service in the first network; an authorization to form a reference for the first detected software representation; and an authorization to create a second software representation at least partially and functionally equivalent that is based on the reference created and to which it is possible to have access from the second network. The first and second networks can have identical software architectures, that is, both can be based on HAVi, or they can have different software architectures: for example, one of the two networks can be based on the HAVi architecture and the other on the Home API architecture; one of the two networks can be based on the HAVi architecture and the other on the JINI architecture; one of the two networks can be based on the HAVi architecture and the other on the UPnP architecture; one of the two networks can be based on the JINI architecture and the other on the Home API architecture; one of the two networks can be based on the JINI architecture and the other on the UPnP architecture; one of the two networks can be based on the UPnP architecture and the other on the Home API architecture, etc., etc. Each of the examples of software architectures mentioned above has a discovery service that allows creating an inventory of devices and / or services registered with the relevant network. The method of the invention uses this discovery service and the Registry / Directory / Search functionality that allows detecting what is available when questioning this inventory. Thus, the authorization to form comprises a permission to extract information., About the first software representation relevant to its functionality from the point of view of the second network; and the authorization to create comprises the construction of a second software representation based on the information extracted. The following patent documents are incorporated herein by reference: - Serial number 09 / 146,020 (attorney's note PHA 23,492) filed on 09/02/1998 by Yevgenity Shteyn entitled LOW SPEED DATA NETWORK REPRESENTED ON A HIGH SPEED HAVi NETWORK . This document refers to a home automation system that is based on a PC that uses a low speed data transport layer and COM base software components, such as in Home API, to control devices in a home automation network. The domestic automation system emerges with a HAVi network that is based on messages using the IEEE 1394 as a high-speed data transport layer. The HAVi network controls the audio / video equipment in a home entertainment system. The services and devices of the domestic automation are registered as docile HAVi elements with the FAV or IAV controllers of the network = s HAVi. The resources of the domestic automation (appliances and services) have OLE COM automation interfaces and docile HAVi interfaces that allow control of the domestic automation system from the HAVi network. - Serial number 09 / 107,525 (lawyer's PHA 23,438) filed on 06/30/98 by Yevgenity Shteyn and Gregory Gewickey entitled RETIREMENT OF REGISTRATION DYNAMIC OF APPARATUS IN A SYSTEM WITH MULTIPLE COMMUNICATION PROTOCOLS. This document relates to an information processing system having first and second electronic subsystem, and control means for controlling the subsystems. At least, the first subsystem has a software representation registered with the control means. The control means changes a state of the first subsystem by interaction with the software representation. The first and second subsystems are also capable of interacting directly with one another without involving the means of control. To avoid conflicts, at least the first subsystem is able to remove the record with the control means, as well as to cancel its software representation in the control means. - Serial number 08/731, 624 (lawyer's report PHA 23,169) filed on /15/96 by Paul Chambers and Saurabh Srivastava entitled SYSTEM TASK DRIVEN DISTRIBUTED MULTIMEDIA CONSUMER. This document refers to a control system with multiple consumer electronic devices and task-driven control means coupled to the apparatuses to control an interaction between the apparatuses. The control means act on the respective software representations of each respective consumer device. By encapsulating the variable complexity of the task within a software representation, it can be made as simple or as sophisticated as needed to bring the capabilities to a common level. Since the level of the interface is common to appliances, applications can uniformly manipulate appliances that have very different levels of sophistication. - Serial number 09 / 222,402 (lawyer's report PHA 23,405) filed on 12/29/98 by Paul Chambers and Steven Curry entitled VERIFICATION OF ACTIVE NODES IN OPEN NETWORKS. This document refers to a network interrogation protocol which treats the network as a logical or linear ring sequence of nodes together. A polling request simply propagates one node at a time down or around the network until it achieves a full inventory of active nodes. The protocols also include procedures to cure or repair breaks in the connection protocol and to add new nodes to the connection protocol. The connection protocol can also be used to establish hierarchies in connected networks, where the highest hierarchical level includes addresses for permanent members of a connected network and the lowest hierarchical level is a given connected network. - Serial number 09 / 133,622 (lawyer's PHA 23,488) filed on 08/13/98 by Freeman entitled SELF-CONFIGURATION OF THE DOMESTIC NETWORK. This document refers to the automatic configuration of two PC = s in a network in order to share resources registered in individual PC = s. The local services and resources for a PC are registered with the other PC and vice versa. The record hides whether a service or resource is remote or local. In operational use of the network, a local resource or service for a PC is treatable from the remote PC as if it were local to the latter. A PC = s home network is automatically configured in this way. - Serial number 09 / 165,683 (attorney's note PHA 23,483) filed on 02/10/98 by Yevgenity Shteyn titled SCENARIO IDENTIFIER CALLS TO CONTROL SOFTWARE OBJECTS THROUGH THE PROPERTY ROUTES. This document refers in particular, but not exclusively, to Home API and relates to an information processing system with first and second physical components, represented by the first and second software objects. Both objects have properties that can be changed by calling the objects. The system allows registering a property route connecting a first object to a second property of the second object, so that a change in the first property causes the second call issued to the second object when invoking the property route. The incoming call for the first object consists of an identifier that allows to invoke the route conditionally. In this way, the routes belonging to different scenarios are kept independent so that the system operates with more confidence than without the scenario identifiers. - Serial number 09 / 165,682 (lawyer's PHA 23,484) filed on 02/10/98 by Yevgenity Shteyn entitled THE CONTROL PROPERTY IS LOCATED IN THE COMPATIBLE MODE WITH THE ELEMENT. This document refers in particular, but not exclusively, to Home API and refers to a system that processes information that is composed of an electronic device and a controller to control a functionality of the device. The controller is provided with an abstract representation of the functionality. The abstract representation exposes. one-way to control the functionality. The controller allows to control the functionality through the interaction with the abstract representation. The mode controls the association of the functionality control with a compatible control capability in the controller mode. The exposed mode can be, for example, ABooiean = -, Afloat- =, Ainteger array =.

- Serial number 09 / 176,171 (attorney's note PHA 23,503) filed on 10/21/98 by Doreen Cheng, entitled DISTRIBUTED SOFTWARE THAT CONTROL THE DETECTION OF THEFT. This document is related to providing a structure for a specific property security system. The structure consists of a controlled and distributed software security system that monitors and calculates the status of individual property devices. The activation of an alarm and the action taken in response to the alarm are determined by the state of the insured property apparatus and the rules associated with each state of combination of states. The security features are distributed among the devices depending on the capabilities of the individually owned devices. In the preferred incoforation, the communication of messages between the components of the system is in accordance with the HAVI and Home API standards, thus allowing interoperability between the components of several vendors. - Serial number 09 / 160,490 (attorney's note PHA 23,500) filed on 09/25/98 by Adrián Turner et al., Entitled PERSONALIZED IMPROVEMENT OF INTERNET PERMITTED DEVICES BASED ON THE USER'S PROFILE. This document refers to a server system that maintains a user profile of a particular user of electronic equipment that allows the consumer's network, and a database of new technical characteristics for this type of equipment, such as a home network. If there is a similarity between the user's profile and a new technical characteristic, and the user indicates that he receives information about updated offers and sales, the user receives a notification via the network of the option to obtain the characteristic. - Serial number 09 / 189,535 (lawyer's report PHA 23,527) filed on 1 1/10/98 by Yevgenity Eugene Shteyn titled ELEVATION OF THE SYNERGIC ASPECTS OF DOMESTIC NETWORKS. This document refers to a system with a server that has access to an inventory of devices and capabilities in the user's home network. For example, inventory is a search service provided by the HAVi, JINI and Home API architectures. The server also has access to a database with feature information for a network. The server determines if the synergy of the device present in the user's network = s can be processed based on the inventory list and user profile = s. If there are relevant characteristics for the synergy, based on these criteria, the user is notified. - Serial number 09 / 189,534 (lawyer's PHA 23,528) filed on 11/10/98 by Yevgenity Shteyn entitled CONTENT PROVIDED AS OBJECTS SOFTWARE FOR THE PROTECTION OF RESERVED RIGHTS. This document refers to a provision of content information, such as a movie, an audio file or a text message for an end user. The content information consists of a software object that has an encapsulated procedure for end user access to the content information in an operating time environment. The object can specify the time frame and the manner in which the content information will be accessed. Because the process is encapsulated in the object together with the content data, and since the transport of the object on the Internet is done after serialization, an adequate degree of security is provided against data deployment or unauthorized copying . - Serial number 09 / 213,527 (lawyer's note PHA 23,529) filed on 12/17/98 by Yevgenity Shteyn entitled SYNCHRONIZATION OF CHANGES IN PROPERTY TO ALLOW MULTI-CONTROL OPTIONS. This document refers in particular, but not exclusively, to Home API and is responsible for a system that processes information, such as a home network. The components in the network are represented by software objects whose properties can be changed by function calls (see COM mentioned above). Setting the ownership of an object controls the associated component. Properties are connected through routes that propagate state changes through the system without the need for a client function application. Paths of ownership of two paths are used to maintain consistency between a controlled object and multiple control objects without the risk of endless loops. To make it, the two-way route is executed to change the state of some specific property on a change of state of another specific property, if the change of state of another property was caused by another effect than that of the same route. This mechanism allows to synchronize components automatically from the multiple control inputs. The invention also allows those who develop the software to believe. applications with a range of controllable devices wider than was possible so far, for example, in a customized application of the network as discussed in serial number 09 / 160,490 (lawyer's PHA 23,500) filed on 9/25 / 98 by Adrián Turner et al., And serial number 09 / 189,535 (attorney's note PHA 23,527) filed on 11/10/98 by Yevgenity Eugene Shteyn entitled ELEVATION OF THE SYNERGIC ASPECTS OF DOMESTIC NETWORKS, mentioned above. For personalization service also see serial number 09 / 283,545 (attorney's note PHA 23,633) filed on 4/1/99 entitled Yevgenity Eugene Shteyn entitled TV OF DRIVING TIME AND PERSONALIZED PLACE, listed here as a reference. This document refers to a system and a server method that allows a subscriber to select a specific transmission program to record it and a specific time and place frame to present the recorded program.

BRIEF DESCRIPTION OF THE DRAWINGS The invention is explained by means of examples and with reference to the accompanying drawings, in which: The Figural is a synoptic scheme of a system illustrating the invention; Figure 2 is a synoptic diagram of the HAVi / Home API hardware configuration; and Figs. 3 and 4 are synoptic diagrams illustrating the software configurations for a HAVi-Home API system. In all figures, the same reference numbers indicate similar or corresponding characteristics.

PREFERENTIAL INCORPORATIONS The invention allows domestic networks of different software architectures to integrate with each other. The references of the software representations of devices and services are created automatically in the first of the networks. The references are semantically sufficient to allow the automatic creation of at least partially functional equivalent software representations for the second network, as well as to have access to the devices and services of the first network from the second network.

Concepts of the synoptic scheme Figure 1 is a synoptic scheme of a system 100 to illustrate the invention. The system 100 is composed of the first 102 and second 104 networks having different software architectures. For example, the network 102 has a HAVi-based architecture and the network 104 has an architecture based on Home API, or the network 102 has a JINI-based architecture and the network 104 has an architecture based on HAVi, etc. The first network 102 has a service 106 that allows to question the software representations 108, 1 10, ..., 1 12 of resources (devices and services) that were registered with the network 102. The questionnaire explores the attributes of the representations 108- 112 The service 106 allows registering, not registering and questioning the resources that can be controlled and performed to interact. The registration of a resource requires a series of attributes and a reference for representation. Non-registration requires that the same reference be provided and that access to the reference be canceled through software applications or other software objects. The challenge is to provide a complete or partial series of attributes against which there are similarities to the recorded entries. Similarly, the network 104 has a service 14 that allows discovering and controlling resources having their software representations 1 16, 18, 120 registered therewith. The system 100 has means 122 which connect the networks 102 and 104 and serves for the network 102 to have control over one or more resources registered with the network 104. The means 122 consist of a software module (an object or an application) 124 , called Reference factory. The reference factory 124 is installed in the network 104 and has access to any of the software representations 116-120 through the service 114. The reference factory 124 is able to challenge the service inventory 114 or to receive notification of a new one. software representation according to the software architecture methods of the network 104. E? In this sense, the factory 124 is specific to the network 104. When the reference factory 124 finds an object of interest, for example, a software representation 1 16, the factory 124 creates a reference or group of references for the representation 1 16 The means 122 furthermore has an association container 126, a software representation for storing the references created by the factory 122 in order to be available to all the clients of the network 104. The means 122 also has a software element factory. 128 installed in the network 102. The factory 128 selects references from the container 126 and creates or retrieves prefabricated software representations based on the information contained in the chosen references and which are suitable for being installed in the network 102, for example, by registering them or placing them with the service 106 according to the rules specified by the software architecture of the network 102. When registering with the service 106, the resources of the network 104 become accessible and controllable from the network 102.

The factory 124 can use the rules of the software architecture of the network 104 in order to access the service 14 and extract information to create the references. Factory 128 may use the software architecture rules of network 102 to access service 106 to register newly created software representations based on store references 126. Factory 124 and factory 128 are connected through store 126 Therefore, the store 126 should be able to communicate the information content of the references created by the factory 124 to the factory 128. One possible mechanism to achieve this is to have the factories 124 and 128 set up an interface for the warehouse 126 based on the same language, as XML. That is, the references that the factory 124 is provided as outputs are used directly as inputs for the factory 128. Another mechanism is that the store 126 be able to translate or convert the information it received from the factory 124 into a properly formatted output for the factory 128 using a conversion protocol. Within this context, see Serial Number 09 / 165,682 (attorney's note PHA 23,484) referred to above, which illustrates a generic class map protocol. Alternatively, it is possible to insert specific conversion stages between the store 126 on the one hand, and the networks 102 and 104 on the other. A similar means 130, Mutatis mutandis, consisting of a reference factory 132, a container 134 and a software element factory 136 can be added to make the resources of the network 102 controllable from the network 104. The multiple reference factories network reference 104 may be installed, for example, a reference factory 136 to provide specific reference information that allows a third network (not shown) of another software architecture to control one or more features registered with network 104 in a manner similar to control from network 102. Each of these multiple reference factories may be responsible for certain types of references, such as another software environment (HAVi, JINI, Home API), or other object representation within such network (Java DCM for FAV , DDI data for GUI, native DCM for IAV, etc.), or a class of resources (devices / services), such as data storage, home automation, group of commands A / V, etc. The warehouse 126 can be accessible to a subsequent software element factory 138 for a fourth network, the subsequent factory is able to directly or indirectly handle the references in the warehouse 126.

Synoptic diagram of the hardware configuration HAVi-Home API Figure 2 illustrates the physical configuration of an integrated home network system 200 consisting of a network based on HAVi 202 and a network 204 based on Home API. The 202 network consists of a HAVi 206 set top box with FAV capabilities (see the HAVi discussion above), a docile HAVi 208 TV that serves as a BAV (see the HAVi discussion above) and a docile D-VCR HAVi 210 that It also serves as a BAV. The apparatuses 206, 208 and 210 are interconnected by the IEEE 1394, which allows the set top box 206 to control the TV 208 and the D-VCR 210. The network 204 consists of a PC 212 that is configured to control the lights 214 by means of an X-10 connection, lawn sprinklers 216 by means of an IR connection and other apparatuses (not shown) by associated connections. Set top box 206 and PC 212 are interconnected via a 1394 bus from the IEEE. The IEEE 1394 connection allows PC 212 to access the IEEE 1394 compliant devices. In order to take advantage of this capability, a Home API 218 service provider for HAVi is installed on the PC 204. The HAVi 218 dedicated service provider has access to the FAV application environment of the HAVi-based PC or the environment of the IAV application of the PC based on HAVi. You can also implement or install your own FAV or IAV environment, if one is not available. The service provider 218 populates the Home API 220 directory with COM objects that represent HAVi devices, such as the 206-210 devices. This allows the Home API applications of the PC 212 to control the HAVi 206-210 devices.

However, this configuration does not allow FAV 206 HAVi-based applications to access Home API software objects such as lights 214, lawn sprinklers 216 or other devices registered in directory 220. To achieve control from the HAVi network 202, it is necessary to install docile software elements HAVi (such as DCM = S, FCM = s) in a HAVi register 222. The invention proposes to introduce the concepts of reference factory and software element factory to allow this installation as discussed with reference to Figure 1. This control capability allows the user to turn lights 214 on and off through his HAVi 206 set top box and to stop or reprogram 216 showers to avoid noise while watching an interesting movie , etc.

Synoptic diagrams of the creation of the HAVi-Home software configuration API Figure 3 is a first synoptic diagram illustrating a software configuration 300 of a HAVi-Home API bridge. The configuration 300 consists of a PC 302 with Home API 304 control environment and a HAVi software implementation lAV / FAV 306. Configuration 300 also consists of a HAVi 308 network and a Home API 310 network. The dedicated HAVi software elements that interact with the Home API 304 environment they allow the devices or services of the network 310, registered with the Home API 304 environment, to be controlled from the HAVi network 308. As already explained above, the invention provides a method that allows the connection between environments of different home network, here the HAVi 308 network and the Home API 310 network. The environment ^ Home API 304 consists of a software component 312, which is an application or a software object and calls a reference factory, which detects software representations of devices and services available in the environment 304, as an object 314. This detection can be done by enumeration and / or monitoring of the Home API 316 directory or access to the root Home API or to another container. Based on the capabilities of the reference factory 312 and / or user preferences, a reference or group of references associated with the software representation of the detected appliance or service is created. Said reference has necessary information about the software representation, for example, type of object, property descriptor, class ID, URL, unique object identifier, XML card, DDI descriptor, etc., for the creation of an equivalent software representation of the same device or service, but now to be used within another network, here environment HAVi 304 and network 310. Factory 312 uses Home API notification mechanisms, such as event subscriptions or property routes, to detect software objects that are added to the environment 304. When a software object is added to the Home API 304 environment, the reference factory 312 is notified and, if necessary, references are created and placed in the reference container 318 associated with the object that was added. In this example, container 318 makes the references available to all Home API clients. For example, the reference factory 312 accesses objects of interest, such as those specified by the user, through the Home API 316 directory. For example, the user specified that he is interested in objects ALuces = 214. The user's preferences can be obtained through a guide / configuration application. For example, the application or guide lists all the devices or types of devices available in a network environment. Gather the user's entries as to which one (s) of them is accessible through another network. The reference factory 312 identifies the software objects of interest in the directory 310 and creates a reference group for the HAVi software elements, such as, ones that have DDI data, DCM Java reference, or native DCM (binary). These references are placed in the reference container 318 for ALuces = 214. After the reference factory 312 is installed, subscribes to the Home API root through the Home API event mechanism. The installer can subscribe factory 312 to a specific container or to part of the Home API 316 directory, such as Asala =, to be able to control the lights in the room only. When a new light object is added to network 310, factory 312 creates a new reference, such as the DDI descriptor and a URL for a Java package to represent the new light. Then those references are added to the container 318 of the new light. A software element factory HAVi 320 is the software component responsible for accessing the Home API objects of interest. In this example, choose the appropriate references from container 318 for the object ALuces =. Factory 320 creates HAVi software elements based on retrieved references and using internal and external resources (for example, Internet). See the infrastructure discussed in the serial number 09 / 160,490 (PHA 23,500) and serial number 09 / 189,535 (PHA 23,527) mentioned above. PC 302 has a DCM 322 administrator and a 324 register as part of the HAVi lAV / FAV implementation on PC 302. The factory 320 interacts with the DCM HAVi 322 administrator and the HAVi 324 registry according to the rules of the HAVi architecture. and / or the preferences of the element factory. For example, factory 320 creates DDI data to make the functionality of the Alucess Home API object accessible through a HAVi application and data deployment that hosts the HAVi network. Alternatively or subsidiary, factory 320 creates or retrieves a DCM Java from the Internet (via a URL) and registers it with register 324 to allow HAVi applications or other DCMs to interact with the software representation of Aluces = 214. the installation of the reference factory 302, the manufacturer of the device can provide it during the installation of the device to the network. For example, philips lights may come packaged with PC software that has reference factory software object 302 to allow HAVi access. The installation can be carried out by a service provider, the user or a third party as part of the PC software functionality improvement. Regarding the installation of the software element factory 320, the installation may be carried out by a HAVi service provider or a third party, the user himself or a service provider to improve an existing element factory.

Figure 4 is a second synoptic scheme illustrating a software configuration 400 of a HAVi-Home API bridge. Configuration 400 consists of a PC 302 with Home API 304 control environment and Home API 310 network. Configuration 400 is also composed of a HAVi 308 network that includes a HAVi FAV 402. Now, PC 302 has a 404 software module that represents the Home API 304 control environment in the HAVi 308 network. The 404 module is a HAVi BAV that is composed of the software element factory 320, which interacts with other BAV software components in order to represent the Home API 314 object as a DCM 406 (or an FCM) in the HAVi 308 network. The DCM administrator (s) (not shown) in the FAV or IAV HAVi devices interact with the BAV 404 software in order to make the Home API 314 object available on network 308 through DCM 406. For this configuration, also see serial number 09 / 146,020 (attorney's note PHA 23,492) named above. Within the context of installing software elements, the reference is made in serial number 09 / 160,490 (lawyer's PHA 23,500) filed on 09/25/1998 by Adrián Turner et al., Entitled PERSONALIZED IMPROVEMENT OF INTERNET ALLOWED APPLIANCES BASED ON THE USER PROFILE, mentioned above, and serial number 09 / 189,535 (lawyer's PHA 23,527) filed on 11/10/1998 by Yevgeniy Eugene Shteyn titled IMPROVING THE SYNERGIC ASPECTS OF DOMESTIC NETWORKS, mentioned above. As another example, a HAVi- UpnP bridge is constructed by exposing HAVi software elements to the UPnP network and vice versa. XML is the basis for the representation of devices in UpnP. To participate in a HAVi software of the UpnP network, the elements need to have an XML representation associated with them. Said representation can be created "at the races", that is, each time per connection / enumeration request, or, preferably, once and placed in the register as an attribute of the software element or as a separate software element associated with the first for a unique software ID element. If a direct translation to the XML of a specific HAVi software element is an impossible functionality (for example, a software element is represented by the Java object of a third party, etc.), a generic XML representation can be created. The software element manufacturer (DCM, FCM) can provide a preferred XML representation of the component, if it is intended to participate in the UPnP network. Similarly, the HAVi DDI interface can be tr --- ci --- BÍ~ etßn - íél | -? Art- basß fe the published elements of the user's DDI interface (for more details, see section 4 of the HAVi specification). The Java reflection mechanism can be used to challenge the interfaces of a particular Java object and an equivalent XML model can be created if the interface is known.

Claims (10)

CHAPTER CLAIMING Having described the invention, it is considered as a novelty and, therefore, the content is claimed in the following: CLAIMS:

1. A method that allows a first home network (104) of a first software architecture to interact with a second home network (102) of a second software architecture, the method:

2. The method of claim 1, wherein the first and the second network (202, 204) have different software architectures. The method of claim 2, wherein: - one of the two networks is based on the JINI architecture; and - the other network is based on the HAVi architecture. The method of claim 2, wherein: - one of the two networks is based on the JINI architecture; and - the other network is based on the UPnP architecture. The method of claim 2, wherein: - one of the two networks is based on the UPnP architecture; and - the other network is based on the HAVi architecture. The method of claim 1, wherein: - the first network has an inventory of apparatuses and services registered with the first network; - the detection permit includes the questioning of the inventory; - the training permit allows extracting information about the first software representation relevant to the second network; - the creation permission provides a second software representation based on the information extracted. 7. A system that processes information (100) is composed of: - a first home network (104) of a first software architecture; and - a second home network (102) of a second software architecture different from the first software architecture; wherein: - the first home network has a search service (114) that allows to detect a first software representation (116, 118, 120) of a first device or of a first service in the first network; - the system has a reference generator (124) to create a reference for the first software representation by means of interaction with the search service; - the system has a software element generator (128) that allows to create a second equivalent software representation that is at least partially functional based on the reference and that is accessible from the second network. 8. A software component (reference factory) (122) for use in a home environment system (100), wherein: - the system consists of a first network (104) of a first software architecture, and a second one home network (102) of a second software architecture different to the first software architecture; the first network has a search service (114) that allows detecting a first software representation (1 16, 1 18, 120) of a first device or a first service in the first network; - the component has a reference generator (124) to create a reference for the first software representation by means of the interaction with the search service; and - the component has a container (126) for storing the reference. 9. The component of claim 8, consists of: a software element generator (128) that allows creating a second equivalent software representation that is at least partially functional based on the reference and that is accessible from the second network. 10. A software component (object factory) for use in a home environment system (100), wherein: the system consists of a first network (104) of a first software architecture, and a second home network (102) ) of a second software architecture different from the first software architecture; the first network has a search service (1 14) which allows detecting a first software representation (1 16, 1 18, 120) of a first device or a first service in the first network; the first network has a reference for the first software representation; and - the component has a software element generator (128) that allows to create a second equivalent software representation that is at least partially functional based on the reference and that is accessible from the second network.