MXPA00010914A - Method and apparatus for universally accessible command and control information in a network - Google Patents

Abstract

A method and system for performing a service on a home network, by:connecting a first and a second home device to the home network;providing a database including a plurality of application interface description data objects, where each application interface description data object includes information in a structured format for commanding and controlling of a home device by one or more other home device connected to the network;the second home device accessing a first application interface description object for the first home device in the database;the first home device accessing a second application interface description object for the second home device in the database;sending control and command data from the first home device to the second home device utilizing the second application interface description object over the network;and sending control and command data from the second home device to the first home device utilizing the first application interface description object over the network. Whereby, the first and second home devices perform said service.

Description

APPLIC TION PL LISHI U ?? LR IHC PVIL? I Í 11041 METHOD AND APPARATUS FOR COMMAND AND CONTROL INFORMATION UNIVERSALLY ACCESSIBLE WITHIN A NETWORK Technical Field The present invention relates to the field of network systems and more particularly, to a home network that has multiple devices connected to it.

Background In Art A network generally includes a communication link and several devices with a communication capability, connected to the communication link. The devices include computers, peripheral devices, routers, storage devices and devices with processors and communication interfaces, an example of a network is a home network for home use, in which several devices are interconnected. A usual home may contain several devices, including personal computers and home devices that are typically found in a home. The term "device" as such, typically includes logical devices and other units that Ref. 124591 They have the functionality and the ability to exchange data and can not only include all devices in the home, but also universal computers. Domestic devices include electronic devices such as security systems, home theater equipment, televisions, video recorders, stereo equipment and direct broadcasting satellite services (DBSS), also known as digital satellite services (DSS), watering systems , lighting systems, microwave ovens, dishwashers, ovens / stoves, washers / dryers and a processing system inside a car. In general, domestic devices are used to perform tasks that improve the lifestyle of the homeowner and the standard of living. For example, a dishwasher performs the task of washing dirty dishes and frees the owner of the house from having to wash the dishes by hand. A VCR can record a television program to allow the owner of a house to watch a particular program at a later time. The security systems protect the values of the owner of a house and can reduce the fear of the owner of unwanted infiltrations to his home.

Home devices, such as home theater equipment, are frequently controlled using a single common control unit, call a remote control device. This single common control unit allows the owner to control and command several different household devices, using a single interface. Consequently, manufacturers have developed control units to control and command domestic devices from a single interface. A disadvantage associated with the use of a remote control unit for controlling and controlling home devices is that it provides a static logic and commands to control and command each home device. Another disadvantage associated with using remote control units is that the known remote control units can not control a plurality of diverse devices, and more particularly, they can not control a plurality of devices having different capacities to communicate with each other, with the objective to perform tasks or provide a service. In conventional network systems, a user provides commands using a remote control unit or a device control panel. Once the user ends, there is no controller unit or device within the network, which provides commands for automatic operation. After the user initially controls and commands a first set of devices, conventional systems do not provide a mechanism for the first set of devices to automatically communicate with a second set of devices within the network, as necessary, with the objective of performing tasks without the command and direct control of the user, of the second set of devices. Additionally, conventional systems do not provide an efficient method for various network devices to obtain information about other network devices, within the network for the AND control command. There is, therefore, a need for a method and a system that provides dynamic control and command devices within a home network. There is also a need for such a method and system, which provide the ability to control a plurality of diverse devices having different capabilities to communicate with each other, for the purpose of performing tasks or providing a service. There is also a need for a method and a such system, to provide the capability for several network devices to command and control several different network devices. There is also a need for such a method and system, which provide universally accessible command and control information for communication between devices.

Brief Compendium of the Invention The present invention satisfies these needs. In one embodiment, the present invention provides a method and system for performing a service on a home network, by: connecting a first and a second home device to the home network; providing a database that includes a plurality of description interface objects of the application interface, wherein each application interface description data object includes information in a structured format, for command and control of a home device by means of one or more different household devices, connected to the network; the second home device accessing a first description object of the application interface for the first home device, within the database; the first domestic device accessing a second description object of the application interface for the second home device within the database; sending control and command data from the first home device to the second home device, using the description object of the application interface on the network; and sending control and command data from the second home device, to the first home device, using the first description object of the application interface on the network. Accordingly, the first and second domestic devices perform the service. In a version of the invention, the first home device stores the first data of the application interface within it, and the second home device stores the second data of the application interface within it. The database is formed by consulting the first and second home devices, to transfer said data from the application interface for the first and second home devices, to the database device. The database can be stored in a database device and be connected to the network, to be accessed universally, by means of network devices. In this case, the first object of description of the application interface can be provided from the database, up to the second domestic device on the network. Additionally, the second object of description of the application interface can be provided from the database, to the first domestic device on the network. Additionally, three or more devices may be connected to the network, wherein at least one domestic device accesses the database to query the description objects of the application interface of a plurality of domestic devices, to send command data and control towards the plurality of home devices over the network, each object of description of the application interface can include data in a structured format. The structured format can include the XML format.

Brief Description of the Drawings These and other aspects, features and advantages of the present invention will be better understood with respect to the following description, appended claims and accompanying drawings in which: Fig. 1 shows a block diagram in a network mode according to an aspect of the present invention; Fig. 2 shows a block diagram of Fig. 1, in an exemplary scenario of control and communication of the device; Fig. 3 shows block diagram of an exemplary home network system in accordance with the present invention, which includes a plurality of client devices and servers; Fig. 4 shows a block diagram of exemplary embodiments of the client device and the server device of Fig. 3; Fig. 5 shows exemplary embodiments of client devices; Fig. 6 shows exemplary embodiments of server devices; Fig. 7 shows a block diagram of two exemplary network server devices, capable of communicating and controlling each other; Fig. 8 shows a block diagram of an exemplary architecture of an audio / video model (A / V) including examples of a source server device, an acceptor server device and a client device within a network; Fig. 9 shows another example of the audio / video model (A / V); Fig. 10 shows an exemplary capability data table for a network device; Fig. 11 shows an exemplary attribute data table for a network device; Fig. 12 shows an exemplary configuration of building blocks for generating command messages between the networked devices; Fig. 13 shows another exemplary configuration of the building blocks of Fig. 12, for generating command messages; Fig. 14 shows three examples of the interaction between client devices and network servers; Fig. 15 shows an exemplary block diagram of the API extensions definitions of network device interfaces; Fig. 16 shows an exemplary architecture of an application of the server device that accesses the network document description of the interface of another server device; Fig. 17 shows another example of the control architecture between devices, between a device controller server and a controller server device; Fig. 18 shows a modality of a protocol XML that provides a common and standard intermediate program layer for the Web, in a communication stack at the API level between networked devices; Fig. 19 shows another embodiment of the command and control architecture from server to server device; Fig. 20 shows the relationship that exists between a device interface library and a consumer electronics definition database for home devices; Fig. 21 shows a hierarchical form of a modality of a device interface definition; Fig. 22 shows an example of layers in the interface definition of the device of Fig. 21; Fig. 23 shows a process of transmitting command interpretation between a sending device and a receiving device; and Fig. 24 shows an example table of a partial list of types and packet formats for providing translation services, in accordance with an aspect of the present invention.

Detailed description of the invention In one aspect, the present invention provides communication between devices within a network, such as a home network. While domestic devices have become increasingly intelligent and can share information, communication between devices allows a user to interconnect devices within a network, to take advantage of the information sharing capabilities of those devices. As such, communication between devices plays a crucial role in allowing a user to have the ability to widely and flexibly use networked devices. Referring to FIG. 1, in one embodiment of the present invention, a network 10 includes at least one client device 12 and at least one server device 14 interconnected via a communication link 16. The communication link 16 can include a 1394 serial bus that provides a physical (medium) layer to send and receive data between the different connected household devices. The 1394 serial bus supports both audio / video (A / V) trains multiplexed in time, and communications in Internet protocol (IP) standard. In certain For example, a home network uses an IP network layer as the communication layer for the home network. However, other communication protocols may be used to provide communication from the home network. Each client device 12 can communicate with one or more server devices 14 within the network 10. In addition, each server device 14 can communicate with one or more server devices 14 and one or more client devices 12, within the network 10. Each device client 12 may include a communication interface that includes input devices such as a mouse and a keyboard for receiving user inputs and a screen for providing a user interface control for a user to interact with the networked devices. The user interface may include a graphical user interface (GUI) screen 18 to provide information to the user. Referring to Fig. 2, as defined herein, each server device 14 provides a service to the user, except the control user interface, and each client device 12 provides a control user interface for user interaction with the network 10. As such, only the client devices 12 interact directly with the users, and server devices 14 interact only with client devices 12 and other server devices 14. Exemplary services may include deployment and source / mpeg acceptor services. Fig. 3 shows a block diagram of an example house network 10, which includes a plurality of client devices 12 and a plurality of server devices 14. Each server device 14 can include the physical equipment as a resource within the network , to provide services are user. In addition, each server device 14 can store a server or service control program 20 to control the physical equipment of the server and include an interface description of the graphical control object (GCO) user 22 for the user's interface with the program server control 20, as shown in Fig. 4. To have control between a client controller device 12 and a controlled server device 14, the client device 12 accesses the graphic control object 22 of the server device 14 by means of transferring , for example, the graphical control object 22 from the server device 14 to the client device 12, over the network. The client device 12 then uses the graphic control object 22 transferred to create a GUI control user interface 18, for the user to communicate with the control program 20 of the server device 14, from the client device 12 that is in the network. The user provides the command and control for, at least, the control program 20 of the server device 14, from the client device 12. By storing the graphic control object 22 of each server device 14 within the server device itself, it can reducing the processing and storage requirements of the client devices 12, in networks with many server devices 14. Moreover, by storing the graphic control objects 22 in the server devices 14, it can allow each server device 14 to provide its own design and detail of the graphical user interface, and allow the modification or updating of the graphic control objects 22, without making any modification to the client devices 12. Referring to Fig. 4, to provide the command and control between the client device 12 and the server device 14, in one embodiment, the client device 12 may include a player 24 for displaying a graphic interface of the user 18 using a graphic control object 22 stored in the client device 12 or transferred to the client device 12 over the network in which a desired server device 14 is located. For example, in an initial device selection phase, the client device 12 can bring to the graphic control object 22 of at least one server device 14 that is on the network and the player 24 displays a user control interface 18 using to the graphic control object 22 for controlling the server device 14. Preferably, the user control interface 18 is customized for the server device 14 and may include a set of built-in commands to control the server device 14. In addition, the graphic interfaces of the user 18 of various server devices 14 may include common features such as: (1) a common graphical control object model type for the client device player 24 to deploy user graphical interfaces 18, (2) common protocols of communication to transfer the graphic control objects 22 from various server devices 14 to the the client device 12, and (3) common communication protocols for the interaction that exists between the graphical user interface from the client device 12, to the control program 20 of the corresponding server device 14, wherein the client device 12 does not require a built-in knowledge of a particular server device 14, that is being controlled. Referring still to FIG. 4, a server device 14 may include one or more server control programs 20 to control the physical equipment of the server to provide a service. The user control interface 18 from the graphic control object 22 of the server device 14, provides an interface for the control programs of the server device 20. The server device 14 may also include control status data 26 indicating the status of control of the server device 14 and of the physical equipment of the server device, by providing a service already required. For example, the control status data 26 may include the status of the control information of the user control interface 18 for the server device 14, such as the configuration of a timer for a recording action on a server device. video recorder. The control status data 26 is stored in the device server 14 controlled and deployed to a user through the user device control interface 18 of server device 14 in the client device 12 controller, for the user to control the server device 14. Preferably, the client device 12 controller to deploy to the user control interface 18 of the server device 14, does not require any knowledge of the control status data 26 for the controlled server device 14. Each server device 14 can be controlled by one or more client devices 12. Thus, the control status data 26 stored in the server device 14 includes the state of the information that is in the user control interface 18 of the server device. 14, on each of the client devices 12 controllers. For example, when the user controls a server device 14 using a first client device 12, the information found in the user control interface 18 of the server device 14 in the first client device 12 is stored by the server device 14 within of the control status data 26 of the server device 14, until the conclusion of user control.

Alternatively, while the user is interacting with the user control interface 18 of the server device 14, in the first client device 12, the control status data 26 of the server device 14 is updated with the information found in the interface user control 18 of the server device 14 on the first client device 12, and until the conclusion of user control, the control status data 26 is retained on the server device 14. When the user controls the server device 14 using a second client device 12, the control status data 26 is made available to the user, through the user control interface 18 of the server device 14 on the second client device 12, for additional control. The user may also use the first client device 12 at a later time, to control the server device 14, until the control status data 26 becomes available to the user through the user control interface 18 of the server device. 14 on the first client device 12, for additional control. The server device 14 may also include a clock 28, or maintain the current schedule, to allow a time delay action, based on entry of a user's schedule or clock, as will be described later. A client device 12 and a server device 14 can be physically grouped together, as a single unit, such as a DTV (digital television). In this case, the server device 14 includes a control program 20 for controlling the physical equipment of the server and the client device 12 provides a user control interface for the server control program 20, to command and control to, so less, the physical equipment of the server. Fig. 5 shows examples of client devices 12 which may include: (1) a PDA (personal digital assistant) (C Remote) to display a graphical user interface, (2) a DTV (STB, multimedia adaptation box) for displaying a graphical user interface and including an acceptor server comprising a target audio and / or video program destination server; and (3) a personal computer for displaying a user's graphical interface and including at least one device server to provide multiple services. Physical equipment and executables within a digital TV or personal computer client device can also be controlled by other client devices. Fig. 6 shows example 14 server devices, including: (1) a smart card DVDP as a source server device, (2) an Audio Amplifier as an acceptor server device, (3) a Digital Video Recorder in the form of a server device, either, acceptor or source, and (4) a Management Server to manage the remote server devices. The Management Server may be included within a DBS-STB, a cable TV STB, or an AT? C STB, for example. These devices include a Management Server to locally control or manage the internal workings of the STB. Additionally, external servers accessed through an external network can be used, through local client devices for services such as Video on Demand, Enhanced Television and Internet commerce, for example. Referring to Fig. 7, communication and control between the server devices 14 is performed by means of the control programs 20 of the server devices 14, which communicate the command and control data between them. A server device 14 can control one or more different server devices 14, which are on a network. Thus, a server device 14 can be controlled by means of one or more server devices 14, and by one or more client devices 12. Additionally, a user may use a client device 12 to command and control a first set of server devices 14, and the first set of server devices 14 can automatically command and control a second set of server devices 14, without the need to involve the user, as necessary, to perform services for the user. For example, for an automatic time delay operation, the user can "log into the system" on the client device 12 to control a first set of server devices 14 and specify the desired services. The user then "leaves the system" of the client device 12. The first set of server devices 14 performs communication and control between themselves and at a later time, one or more of the server devices 14 which is in the first set , automatically control a second set of server devices 14, as necessary, to collectively provide the desired services, without involving the user.

Fig. 7 shows exemplary embodiments of the server devices 14, capable of communicating and controlling each other. Each server device 14 includes a control program 20, a clock 28 and the control status data 26, described above. Each server device 14 may also include a graphic control object 22 so that the server device 14 is directly controlled by means of a client device 12. However, a graphic control object 22 need not be included within a server device 14 that is not directly controlled by the client device 12 and only communicates with other server devices 14. Each server device 14 also includes a command language interface (CL) 30 and a command library. The command library includes the commands that the server device 14 uses to send and receive information in order to provide its service. However, a command language is not necessary for user control, as shown in Fig. 4 and as described above. Fig. 8 shows an example of an exemplary audio / video (A / V) model including a source server device 14, an acceptor server device 14 and a client device 12 within the network.

The source server device 14 includes a control program 20 for controlling the physical source equipment of data stream 32 of the source server device 14, and the acceptor server device 14 includes a control program 20 for controlling the physical equipment acceptor of the data stream. 34 of the acceptor server device 14. In an example operation, a user uses the client device 12 to control the source server device 14, to start the physical equipment source of the data stream 32, and to control the acceptor server device 14, to initiate the physical host acceptor device. data stream 34. Until the initialization of the data transfer, from the physical data source source 32, to the physical data acceptor 34, the user can leave the client device 12. Alternatively, the user can program the initialization of the data transfer at a later time and can leave the client device 12. from here on, the physical source equipment of data stream 32 of the source server device 14 and the physical equipment acceptor of data stream 34 of the server device 14 acceptor, automatically start the data transfer at the time programmed by the user.

For example, the physical data source equipment 32 may include a Tuner Access Device, such as a Via Satellite Direct Broadcasting (DBS). A DBS transmission is a multi-channel alternative to cable television and provides cable-type television programming directly from satellites to small parabolic antennas (from 45 to 90 cm). In direct satellite broadcasting, several standard analog television signals are digitally compressed into a single satellite transponder, thus allowing up to 200 or more channels that can be received with a parabolic antenna focused to a fixed position in the sky. The physical data train acceptor 34 may include a Digital Video Recorder (DVCR) comprising a digital video recorder that is capable of decoding compressed digital video signals upon playback. The user provides command and control data including "time-delayed recording" event data for the digital video recorder and data from the "delayed time program selection" event for the Tuner Access Device. After the time delay, the Tuner Access Device selects the desired program and provides program data to the VCR digital, which receives and records the program data without any additional control action by the user. Fig. 9 shows another example of an audio / video (A / V) model that includes at least one source server device 14 ERVER1, one server device 14 acceptor SERVER2 and one client device 12 on network 10. The client device 12 includes a session manager 36 with a user interface for displaying selection information for a user to select - and control the server devices 14 SERVER1, SERVER2 and other server devices 14, such as SERVER3 and SERVER4 (not shown). The selection information may include icon symbols designated as Serv, Serv2, Serv3 and Serv4 in the session manager 36, for a user to select the server devices 14 SERVER1, SERVER2,? ERVER3 and SERVER4, respectively. The SERVER1 source server device 14 may include a digital video recorder and the SERVER2 acceptor server device 14 may include a digital television. In an example operation, up to the selection of the server devices 14 SERVER1 and SERVER2, the client device 12 transfers the graphic control object 22 of each server device 14 to the client device and displays a corresponding user control interface 18 for each of the server devices 14 SERVER1 and SERVER2. The user may interact with the user control module 18 of each server device 14 to provide commands and control for the corresponding server device 14, to provide service. Each of the server devices 14 may provide a single service or in combination with other server devices 14. The session manager 36 transfers the control status data 26 from the user's graphical interfaces 18 of the server devices 14 within the device. client 12, as necessary, so that the corresponding server devices 14 perform a service. Based on the user command and control information, two or more server devices 14 can communicate the command and control information among themselves, to provide a service required by the user. The session manager 36 may include a software agent that functions to access and display the available services of the home network, provided by various server devices 14 within the network. The software agent may additionally match the capabilities of several server devices 14 within the network 10 and display the selection information for only those server devices 14 having compatible capabilities. In addition, the session manager 36 may match the selections made in the user control interface 18 of a server device 14, with the selections of the user control interface 18 of another server device 14 to assist the user in providing information of command and control significant to the server devices 14. In another example operation, the session manager 36 executes the software agent searching the network and discovers the server devices 14 connected to the network. The software agent also accesses the capacity data stored in each server device 14, to determine the capabilities of the server devices 14 and provides information about those user capabilities. The session manager 36 then displays the selection icons Serv, Serv2, Serv3 and Serv4 to allow the user to select from among the four selection icons. After the user selects the SERVER1 server device by clicking on the Serví selection icon, the session manager 36 determines that SERVER3 and SERVER4 server devices are not compatible in their capabilities with the SERVERl server device. A) Yes, the session manager 36 disables the Serv3 and Serv4 selection icons for the SERVER3 and SERVER4 server devices, respectively. The user can then click on the Serv2 icon to command and control the SERVER2 server device. While the user interacts with the user control module 18 of a selected server device 14, the input of control and command information made by the user in each user control module 18, provides information of additional capabilities, which affect to future selections made by the user of server devices. For example, if a VCR server device 14 is selected, the additional action performed by the session manager 36 in enabling or disabling selection icons for other server devices 14 is affected by a user's decision to play or record. Each server device 14 that is on the network has one or more service capabilities, such as those discussed above by way of example, with reference to the server devices of Fig. 9. Each service capacity includes performing the source or acceptor action of the information. For example, a television has the ability to accept trains of audio and video, a VCR device can be a source (transmit and be acceptor (receive) video and audio signals and a personal computer can be able to transmit and receive data, audio and video, each capability of being a source has the capacity to be a complementary and compatible acceptor, and each ability to be an acceptor has the capacity to be a complementary and compatible source, for example, the device video output capability is complemented for the video input capability of another device, since each device 14 can be a source or acceptor for several different services on the network, each device 14 stores a table of capacity data (Capacities Table 1), as shown by the example of Fig. 10. The first column of Table 10 identifies the service capabilities of a device 14, and the second column identifies whether it is that the device 14 is a source or acceptor for a corresponding service in the first column. By using Table 1 of capacity data, new services can be implemented, while maintaining the compatibility with older devices. For example, if a new service is developed that is compatible with an older service, both new and old services can be entered into Table 1 of the capacity data, so that a device implements the new service, thereby making the device implements remains compatible with older devices that use the old service. In one implementation, a Device Manager conducts a matching or comparison operation of source and acceptor device services. For example, the Device Manager can be implemented as a software agent to compare the capabilities or properties of various devices 14 and locate devices 14 with matching capabilities. For example, in a case where the service is a media stream from a first device 14 along a network, to a second device 14, the Device Manager compares the capabilities of the first and second devices 14 to help the user to make a more accurate selection of the second device 14, which will be compatible with the capabilities of the first device 14. The following is an example list of Service capabilities for a mode of a server device 14: Stream_format_video_dv Stream_format_video_m? Eg2tpt Streanr._format_video_dsstpt St.eam_format_video_mpeg2pes Str eam_for mat_video_mpeg210801 -tpt Each device 14 may additionally store an attribute data table (Table 2 of Attributes) including relevant attributes of the device, shown as an example in Fig. 11. A name and a value define each attribute found within the Table. 2, although the lengths of characters shown in Table 2 are not required. The attribute data is available to other devices 14 that are on the network 10, to facilitate interoperability and to store device information. For example, a Device Sheet like the one that will be described later, uses Table 2 of Attributes to store the name of the device. Other fields can be added to Table 2 of attribute data when necessary. In the user-to-client device control model described above, attribute data can be displayed on the user's page. graphical user interface of the server device 14, on the client device 12. Alternatively, a second level device information start page may be used to display said attribute data. Additionally, the attributes data in the form of text or in an XML file (Extensible Labeling Language) can be accessed by means of a software agent. For the device-to-device control model, the attribute data for the controlled device is stored in the application interface of the device interface. The Device Location attribute field (Devi ceLocation) in Table 2 of Attributes is used to store the location or group of each device 14. The Devi attribute field ceType specifies the type of device, such as a VCR, a DVD, a Digital Television, a Video Camera, a Personal Computer, a Security System, etc., for the device 14 in particular. The Device Type attribute field is used to select a default device icon, to represent the device within the Devices Page, if the device itself does not supply one. Table 2 of Attributes may include multiple entries for attribute fields Default Source and Default Acceptor. Each input of these represents a different source or acceptor device 14 for each of the data types handled by the device 14. Preferably, the capacity and attribute data are packaged in structured data, using a hierarchical language. This provides a common method for removing the data of capabilities and attributes that are used for other purposes such as transfer of graphic control object and control of server device to server device. As an example, attribute data can include the following structured data format: < DEVICEATTRIBUTES > < ATTRIBUTE name = Dev¡ceMapufactu.er value- 'Samsung lnc. "< ATTRIBUTE name = anu.acturer URL value = www.samsupg.com > < ATTRIBUTE name = anufacturerlcon value = "logo.gif" > < ATTRIBUTE name = DeviceName valué- 'Samsung DSS'> <ATTRIBUTE name = DeviceModel va! Ue = "SCH1900"> <ATTRIBUTE name = DeviceType value = DDS> <ATTRIBUTE pame = DeviceLocation value = "Lvvingroom "< ATTRIBUTE pame = Devicel with value =" device.gif "> <ATTRIBUTE pame = DeviceAddress value = 105.144.30.17> / DEVICEATTRIBUTES> As an example, the capability data may include the following format structured: An application interface language is used to allow different server devices 14 to perform device-to-device control, including control from server to server device. The application interface language includes command languages and can be described using XML, as will be detailed later. The control program 20 of a server device 14 remotely controls the control program of another server device 14 that is on the network, without using the graphical interfaces of the user 18 or without involving the user. An example of device-to-device control is an operation automatic A user initially provides a control through a client device 12 for a desired service, and subsequently two or more server devices 14 automatically communicate and control each other, without additional user interaction to provide the service. Referring to Figs. 12 and 13, a standard application interface language is preferably used, to allow interoperability between several control programs 20, in several server devices 14. In another embodiment, the standard application interface language includes the following building blocks: (1) service functional specification 40 such as database services of service functions, (2) a block where the elements of a message are composed 42, (3) standard format in industry 44, (4) compression of messages 46, and (5) construction of message chains 48 to output structured message data. Fig. 12 shows an exemplary configuration of the block construction to perform the function of generating command messages. Each message element is composed from the functional specification of the service and is standardized by selecting a label in compressed form, standard in the industry (Hex), for the message element. A group of such message elements is assembled to create a complete chain of commands. Existing command languages such as CAL and AV / C, operate as shown in Fig. 12. However, such command language mechanisms specify messages and system operation in binary or hexadecimal code on physical devices in the physical interface and they are based on specifications of the physical equipment. Accordingly, such command languages may be less desirable for a network layer based on control mechanisms where the specification of the control system includes naming, locating, discovering device capabilities, communication language and command messages at the application level software level, wherein a software application program 20 within the controller device 14, locates and controls another software program. software application 20, within a controlled device 14 that is on a network 10. Said control mechanism is especially appropriate for devices such as digital apparatus, including apparatus (e.g., a digital video recorder), as well as devices of multiple purposes and multiple applications, such as computers.

Fig. 13 shows a preferred example configuration of the building blocks of Fig. 12, to perform the function of generating the command messages. In Fig. 13, the industry standard format positions 44 and the message compression 46 are different than in Fig. 12. A number of textual standard forms are selected from the functional specification service 40, to form a full message Then, the message can be compressed by means of a lower layer of the protocol stack. Fig. 13 -represents a method to perform services, or command and control of devices for consumer electronic devices (CE). The composition of the message can be defined by the standard syntax in the XML format and the compression can be done by means of another protocol layer, such as HTTP. A command interface language is used at the interface level of the application software 20, instead of lower levels of physical equipment. As such, the protocol stack of the network is governed by means of commands in the aforementioned language and each of the control devices 14 can be seen as an integrated component to the network, for the transmission of messages among themselves.

Referring to Fig. 14, three different instances of the interaction between the client devices 12 and the server devices 14 are shown. In the first instance "A", a human user communicates with a remote service application "S" and receives response in HTML (Hypertext Labeling Language) or XML formats. A secondary server with the browser is included to accept messages sent by asynchronous commands based on XML, for example, on a digital video recorder, the secondary server 14 can accept command messages such as "VIDEO RECORDER FAULT: DAMAGED CASET." A software agent may be used that includes a browser to display the command messages to a user who is in the graphic user interface of the browser, to capture the user's after-care and control the digital video recorder. Preferably, a client device 12 based on XML includes the HTTP1.1 server capability to respond to a command initiated elsewhere, for command and control from server to server device. At the second distance "B", the user is replaced by a software client control program 50. The client control program of Software 50 generates XML-based command sends to the "S" service application and receives returns of XML commands. Thus, in the third instance "C", the software client control program 50 is replaced by an application, such as a server device control program 20, where the commands and responses are exchanged between two service applications 20. In this regard, instance "B" is a special case of instance "C" with a null service. An XML-based application interface language is used to control between a first server device 14 and a second server device 14 (device to device or service to service) for devices or services that are enabled in the worldwide network (WEB) or enabled on the Internet. The application interface language is based on the Web standard, the intermediate program layer. In one embodiment, the device-to-device control includes remotely controlling the control program 20 or Application, in a server device 14 from another server device 14, which is in the network 10. Thus, the interfaces (API) for said Applications 20, are made available over the network using API extensions (program interface of application) . Preferably the API extersions use a standard format, such as an XML-based interface, to provide total interoperability. Referring now to Fig. 15, block diagram definitions of API extensions are shown for a first Application A, designated as a Service A and a second Application B, designated as Servi ci or B, communicating on network 10. By For example, the service A may be the control program for a first server device A within the network and the service B may be the control program for a second server device B within the network. The server device B sends commands to the server device A. For this example, the first and second service devices A and B may include consumer electronics (CE) devices. Referring to API extensions for Servi ci or A, the first block above 52, provides a comprehensive definition of the database of consumer electronics objects and methods that use English words to describe consumer electronic devices. The integral definition or database can also be in C, XML or in other formats capable of representing objects and their methods respective. The integral definition or database that uses XML, is called XCE definition. The second block 54 provides a format for the representation of an application program interface (API) in XML format for all devices 14, designated as an INTERFACE interface data type definition. DTD. A software agent, designated as Tools in A, uses a subset of the XCE definition for Service A, and uses the interface of the INTERFACE data type. DTD for Servi ci or A, to create a document in XML format, INTERFACE-A. XML The document INTERFACE-A. XML describes the objects and methods supported by the Servi ci or A, according to the definition of the INTERFACE document type. DTD for Servi ci o A. Other data type definitions can also be used to create the INTERFACE-A.XML document. The software tool also creates a check table 56 for converting from XML messages from Service B over the network interface, to API definitions for Service A, programmed in C for example, and compiled to run binarily . Preferably, the verification table 56 is created at the time of compilation, where during the At the moment of running, the messages (commands) of the method in incoming XML form, coming from the Servi ci or B, are converted to the API format created by the application code C compiled for the Service A. Verification table 56 provides a translation at the time of call of the method of the XML object of Service B in calls in the native language of the device for Servi ci or A. The verification table 56 is compiled with the program of device control 20, being able to be executed locally on the server device A for Servi ci or A. The document INTERFACE-A. XML can be used by Service A for validity checks, if it finds an error in a received message. The document INTERFACE-A. XML can also be used by a strange application, such as Servi ci or B, to determine the format of the message in the Servi ci or A, before communicating with Servi cio A. Additionally, if the message from Service B to Service A causes an error, Service B may access document INTERFACE-A. XML to diagnose the error.

Referring to the service API extensions B, the first block 58 provides an integral definition or database of CE objects, such as the XCE definition for the Servi ci or A above. The next block 60 provides a language definition for making calls (commands) of the method in XML form for services or remote API devices, such as the API interface for Service A. The definition of language is a request for a method of definition of type document CALL.DTD, which describes the interaction with the objects that they find on the network. A software agent, designated as Tools in ta B, uses at least a subset of the objects and methods - within the XCE definition for the Servi ci or B and the CALL.DTD document to generate a verification table 62, to convert commands from the program code C compiled for Servi ci or B, in method requests in XML format. As such, the verification table 62 provides a conversion between a method invoked by the Servi ci or B (for example, "PLAY") and the document or XML message that carries the method call along the network interface to Servi ci or A, for example. The subset of the XCE definition used by the Software Tool in B depends on the scope and nature of the use of the network. For example, the subset can be selected to provide a global or restricted use of all services available in a home network. Accordingly, API extensions provide communication between several devices that are on the network, using XML. In the previous example, program code 20 for Servi ci or B generates method calls for an API interface, and API calls are converted to XML format to comply with the XML standard on the Web / Internet, for inter-device communications . Calls from the XML method (messages) are sent to Service A over the network, and Service A reconverts the XML method calls from the network interface to API definitions of program code for Service A. This conversion and reconversion provides Web / Internet compatibility for various devices that are on the network, with program code API interfaces that may otherwise require binary compatibility between the different devices. Examples of XML interface blocks that use the block diagrams of Fig. 15 are shown below. mterface.dtd rules to describe an object intlrfaz in xml < ! ELEMENT paramater #PCDATA > < ! ATTLIST paramater Type CDATA «REQUIRED > < ! ELEMENT method (OPCDATA, (parameter).) > < ! ELEMENT method (jtPCDATA, (method) t) > interface. example d? object interface in c / * object * / typedef struct Stream (int id,.}.: / * methods * / void StreamPlay (int id, int speod); void StresmStop { int id); interface.xml the same obje or in xml, using the rules of nterface.dtd < method > Play < p rame< t type = "mt" > ? d: / paramo te rv < parameter type = "mt" > speed < / paramecer > / m hod > < method > etap «parame ter type-"? nt "> ? d < / parame ter > < objecc > call.dtd rules to describe a function call in c, in xml < iELEMENT parameter #PCDATA > < ATTLIST parameter valué CDATA ÜP.EQU R? D < IBLEMENT method (#PCDATA, (parameter) + > <! ELEMENT object (jtPCDATA) <! ELEHEKT cali (object, method) > controller c controller command d? example, in c StreamPlay (OxOlae, büU., cali xml the same command in xml, using call.dtd example to play a train < ob; ject > Stream ../object :. < method > Play < / method > parameter value = "500" > speed < / parameter > - / cali - Additionally, the above shows examples of the INTERFACE interface definitions. DTD and CALL.DTD, used to create the description document of available services, INTERFACE. XML, described above. The CALL.DTD definition includes a set of rules to generate method call or call messages of function, such as XML Remote Procedure Call (RPC) or XMLRPC. The definition CALL.DTD describes an output interface of a controller service 14. In a home network, for example, INTERFACE. XML represents the services available on the home network. The available services are a subset of the complete services found in the CE space. In a Recording with a Key (OTR) scenario, the user has control of a Tuner Access Device, such as a Via Satellite Satellite Adaptation Box (STB). The user controls the tuner using an Electronic Programming Guide (EPG) such as a representation of the graphic user interface of the program listings. The OTR recording provides the user with a service that includes the selection of a future program of an electronic programming guide, to record without the user accessing the graphical user interface of the VCR, to program the VCR in a Delayed Recording in Weather. OTR recording automates the control of the VCR. Below is an example of the stock control list in OTR. XML: (1) StreamOpen = play the train output of programs selected to the network, from a satellite multimedia adaptation box; for OTR recording this control is local to the STB device; (2)? TorageOpen = open a storage device; and (3) StorageRecord = Send the Recording Command through the network, to the VCR. call.dtd rules to describe a function call c in xml < ! ELEMENT parameter #PCDATA > clATTLIST parameter valué CDATA #REQUIRED < ! ELEMENT method (#PCDATA, (parameter) +) > < IELEMENT object ("PCD? TAI> <! ELEMENT cali (object, tnethod) interface.dtd example to describe an object interface in xml < ! ELEMENT parameter #PCDATA > -. ATTLIST parameter valué CDATA (IREQUIRED < I ELEMENT method (ttPCDATA. Ip-carneter] +). < ! ELEMENT object (tfPCDATA, method +): > inter face. ml this document describes several CE services offered -a subset of the entire CE space. < ? xml version = "l.u" ?: > < ! D0CTYPE interface SYSTEM "interface.dtd". «ObjectsStream cmethod-Open < parameter type = "in" > id < / parameter > < parameter type = "int" > channel < / parameter > < / mctítod > «Nethod.Close < parame er type = "int" > id < / parame er > c / me hod-1 < / object > «Objec sControl < / object > < objec -Storage < r.ethod > Open < parameter type = "int" > ? d < / parameter > < parameter type = "? nt" > channel < / parameter: < / rt? ethod > < method-Record < parameter type = "int" > id < / parame er > < / method > < method > Play < parameter type »:" int "> id < / parameter > "Parameter type ="? Nt "> speed < / parameter > < / method > < method > SLop < parameter type = "int" > ? d < / parameter > < / method > < ntethod > Closc «parameter type -"? Nt "> ? d < / parametcr > < /? nethod_- < / object > < ob_ect > D? Aplay < method > Open «parame er« páramete- c / method > < [ueU.od. »Render < parameter «/ method: > < method > Blop? "Parameter type ="? Nt "> ? d «/ paramet, er > < / me hod > «Method-Control« parameter type »" inc "> id < / parameter > < parameter type - "? nt" > cid «/ parameter > "Parameter type" "int" > level < / pa? ameter > < / method > < method > Close < parameter < / method > < / object > otr.xml an xml representation of a recording representation of a key c StreamOpen (100.2); / * play a train (powered by satellite feed) * / StorageOpen (24.2); / * open a storage service * / StorageRecord (24); / * record the train * / «? Xtnl version -"! .- ". > «ICODTYPE interface SYSTEM" call.dtd "> < call > «Object > Stream «/ abject. «Metho > Open «/ method > "Parameter value =" l00"> id «/ parameter > "Parameter value-" 2"> chanpel < / parameter > «/ Call > < call > «Object > Storage «/ object > «Method > Open «/ method > «Parameter value =" 100"> id < / parameter > "Parameter value =" 2"> channel «/ parame er > < / call < call > «Object > Storage «/ obect > «Method > Record «/ method > «ParameLer valué-" 100"> id «/ parameter > < / call > As discussed above in relation to Fig. 15, a first device B can access the INTERFACE document. XML of a second device A, to determine the capabilities of the device and the details of the API interface of the second device A and determine the details of functionality and command supported by the second device A. In particular, the first device B can determine an overlap and consequently, usable methods supported by the first device B and the second device A. Fig. 16 shows an example in which a first server device B that includes an Apli cation B, accesses the document INTERFACE-A. XML of a second server device A, including an Apli cation A. The first server device B includes an INTERFACE-B document. XML to be compared with that of the INTERFACE-A.XML document in the second server device A. In a scenario, the first server device B wants to control the second server device A that the network is located. The document INTERFACE-A. XML of the second device A is transferred from the second server device A, to the first server device B and used by the application B to consult the capabilities and methods of the API interface of the second server device A. This allows the first server B device control the second server A device, using XML remote procedure calls, XMLPCR. In another scenario, the first server device B performs the above steps after attempting to communicate with the second server device A at least once, and has failed to establish communication. Still, in another scenario the first server device B questions the INTERFACE-A XML document that is located on the second server device A remotely, without transferring the document INTERFACE-A. XML to the first server device B. Until examining the contents of the document INTERFACE-A. XML, the first server device B can create commands to send them to the second device A in XML format, as previously described. Generally, the first server device A can interpret, at least, a portion of the content of the INTERFACE-A document. XML that overlaps with a subset of the XCE definition used by the first and second server devices B and A, as described above. If the first server device B is not capable of interpreting a portion of the content of the INTERFACE-A document. XML, then the first server device B can ignore this portion, or remove an application to help it interpret this portion, by means of translation, as will be described later. Referring to Fig. 17, another device-to-device or device-to-device control is shown between a controller server device 14 and a controlled server device 14. The server device 14 includes a controller application £ and the controlled device 14 includes an application executable C. The device 14 controlled It also includes the document INTERFACE-A. XML, the application interface description A of the application C. The application E accesses the description of the application interface A within the controlled device 14, to consult the capabilities and methods of the API interface of the server device 14 cortrolado. The application E commands and then controls the application C, using procedure calls - XML message to control the physical equipment or service D of the controlled device 14. A scheduler device may be the case with a controlled device 14, operated by daylight hours, such as the time-delayed recording controller of a video recorder. In a first example, application E accesses the description of application inteface A, by means to consult remotely about the network. In a second example, they applied E to the application description A-interface A, by means of transferring a copy of the application interface A-script from the controlled device 14, to the controlling device 14. Then, the application E consults locally the description of interface A. In a third example, the application interface descppc-on A transferred to a library device 64, which provides library space for descriptions of interface, and the E application remotely consult the interface description A within the library. The library device 64 stores the addresses (URL) of the available associated applications, for the action and the direct control responses. Referring to FIG. 18, the XML protocol provides an intermediate program layer as a standard for the Web, in a communication stack 66, at the API level between the applications 20 of various devices 14 that are in the network. Within each device 14, -the applications that are on top of the communication stack, send and receive communication messages on the network and communicate with layers of software in the device's stack that locally controls the physical equipment of the device. device or the service software for the device. A first XML layer API interface, designated as XML Layer OUTPUT 68 is used to send messages and a second XML layer API, designated as XML Layer INPUT 70, is used to receive messages. The XCE definition and the XML definition of a method call, call the definition of the document type CALL.DTD described above, are used to create the XML Layer 68 OUTPUT.

Additionally, the XCE definition and the XML definition for a method, call the definition of the INTERFACE document type. DTD described above, are used to create the XML Layer 70 ENTRY. For example, a controlling application uses the XML Layer 68 OUTPUT and a controlled application uses the XML Layer 70 ENTRY. Referring to Fig. 19, another mode of the command and control architecture is shown from server to server device. An XML-based control architecture is used to control from device to device (service to service), for devices or services enabled on the Web or the Internet. A first device A can remotely control an application 20 on a second device B over the network using messages from the XML command. The interface of each device includes the interfaces for the applications within the device and are described in XML format. Said interfaces can be extended and available in the intermediate program layer, to be removed and interpreted by means of other devices that are on the network, as will be described later. Each of the server devices A and B includes the physical equipment and software for control other devices that are on the network, and to be controlled by other server devices that are on the network. In Fig. 19 the home network device A is a controller device or module, and the home network device B is a controlled device or module. Each of the devices A and B includes a Device XML interface 72 comprising an INTERFACE.XML interface document and a definition of the INTERFACE.DTD document type. The INTERFACE document. XML includes a description of objects, methods and parameters supported by the corresponding device 14. The INTERFACE document. DTD can be used for validity checks specific to the device's XML interface, as described above. Each of the devices A and B also includes an XML parser 74, comprising the program code for analyzing and validating the XML messages, such as the XML interface and the XMLRPC commands. The XML parser 74 is similar to the XML Layer ENTRY 70 described above with reference to Fig. 18. In addition, each of the devices A and B includes an encoder and decoder (codec) XMLRPC 76 to encode the method names and parameters of an outgoing call in an XMLRPC message and to decode an incoming XMLRPC message after it is analyzed, to remove the name of the method and the parameters therefrom. The device-to-device control architecture consequently allows the use of different XMLRPC formats, without changing another aspect of the device-to-device control architecture. An interface grabber comprising a program code is used by each of the devices A and B to capture the device interface of another device, directly from the other device or from a home network interface library. When a device 14 is a controller device, a controller application program code 82 within the controller device 14, performs the command and control of other devices 14 that are on the network, by means of software and hardware. monitoring within the controller device 14, such as an XML parser 74, the interface grabber 78 and the codex XMLRPC 76. When a device 14 is a controlled device, a controlled application program code 84 within the controlled device 14, monitors to the software and the physical equipment inside device 14, so that the device 14 is controlled by other devices 14. A Home Network Device Web server 86 within each of the devices A and B, is used by means of the controlled application 84, to convert the information into XMLRPC messages (e.g. method name, parameter name and type) to the native interface of the device (for example, name of the native method, parameter name and type). Said table 88 is not used when the names of the methods and parameters in XML messages and the native interface of the device are the same. Each of the devices A and B additionally includes one or more Handlers 90, wherein each Handler 90 includes a pointer from within the controlled application 84, toward a native implementation of a device-specific functionality. On most devices, native implementations of device functionality include a daily code at the time of running. The binary code can be generated from higher level languages at the time of compilation, including C and Ja.a, for example. Thus, manufacturers of consumer electronic devices can add more Handlers 90 for new functions, without affecting the existing Managers and their function implementations. A Physical equipment service 92 within each of devices A and B includes native implementations of device functions. Each of the devices A and B also includes a Native Interface 94 which comprises the API interface of the native implementation of the functions of the device. Additionally, a Network Object Request Intermediary, such as a Home Network Object Request Intermediary 79 (HNORB) and an Interface Library 80 provide an intermediate program layer 98 for the home network 10. As shown Fig. 19, the intermediate program layer 98 may be located in a third device 96, or in a separate control center. The Home Network Object Request Intermediary 79 includes a software agent to be used by device 14 to discover the existence of other devices 14 connected to the network 10. The software agent of the network object request intermediary Home organizes device names into a hierarchical tree structure of names, organizes device interfaces in the Interface Library, and provides device interfaces for a device that requires interface information. , ag _.....- a.

The intermediate program layer, which comprises the Home Network Object Intermediary 79 and the Interface Library 80, can be connected directly to the Internet, in such a way that the selected domestic devices can be accessed outside of a local home network 10. The intermediate program layer 98, inside a local home network, can be connected to the layer of intermediate program 98, in other local home networks over the Internet, to provide an integrated network comprising two home networks 10. In this case, authorized users with the appropriate train encryption, can access a digital video disc changer (DVD) in the user's primary house, from a television in the user's secondary house, to play the video and watch it on the television. To use the Interface Library 80, at least one Home Network Object Request Intermediary and an Interface Library (set HNORB &; IL) must be running in the local home network 10. More than one HNORB &IL set may also be available. For example, a cable modem, several digital TVs and a home center can all have their own software agents from the HNORBSIL suite. To locate the HNORB &IL set, a device 14 sends a '' broadcast message on the local home network. The first set HNORB &IL that responds to device 14, is used by device 14. Once the H ORBSIL set is located, device 14 and the HNORBSIL set can establish a Transmission Control Protocol (TCP) connection. point-to-point or User Datagram Protocol (UDP) to register, the server device 14 interface request, as well as the device verification services. If a UDP protocol is not available, a TCP protocol can be used for connections with a broad bandwidth, such as an IEEE 1394 connection. HTTP-based XMLRPC can also be used for the HN0R3 &IL communications of the device. For example, a device 14 can remotely call a "registration" method of the Home Network Object Request Intermediary, to pass the device interface as one or more parameters, or, an XMLP.PC call may remove an interface of the partial or complete device from the interface library, as an XMLRPC response of the return value. As previously mentioned, more than one set HNORB-IL can run simultaneously in a network of ca.a 10, in count each set HNORBSIL recognizes to its set of available devices and a set H 0RB6IL can communicate * with other sets HNORB &IL to locate the devices 14 that rc can be located. Multiple HNORBSIL sets that are located on a local home network 10, can be automatically located with each other, by using radio broadcast messages, such as UDP or TCP. In this case, multiple intermediaries in the home network object request constitute a distributed object request intermediary, whereas multiple Interface Libraries constitute a distributed interface library. To provide a fault tolerance, if one of the HNORBSIL sets should terminate unexpectedly, all devices registered with this HNOFBSIL set are notified and those devices can be automatically registered with other available HNORB &IL sets. Each interface? of the device has a unique and consistent logical name associated. Other devices can use the logical, unique and consistent name to recognize and access the device, even after the location or the actual network address of the device has changed. The tracking of logical names and real device addresses is managed by a software agent for the name service in the Home Network Object Request Intermediary. Preferably, a standardized appointment method is used. More preferably, a hierarchical naming structure is used to organize the names of devices in a hierarchical tree. This hierarchical structure can be expressed using "/", similar to a file system. The structure can be generated by means of different methods, such as by means of different types of service such as home / MPEG2 / TV; or through different locations, such as home / room / VCR. Several appointment trees can coexist to improve performance and efficiency. In the example command and control, between the controlling server device A and the controlling server device B of FIG. 19, the intermediate program layer 98 is located in the third device 96, or it may be a separate central. The gray blocks show the device elements used for the specific command and control process, illustrated in Fig. 19. In an example operation scenario, after devices A and B have been made available and accessible to Through the network, each device registers / presents itself and its XML interface to the intermediate program layer 98 of the Central House Network Object Request Intermediary and the Interface Library. If an intermediate program layer 98 of the Central House Network Object Request Intermediary and the Interface Library is not available, then each device emits (broadcasts) a message about the local home network, to announce itself. The controlling application 82 of device A attempts to query all or part of the device interfaces of the controlled device B. If an Interface Library 80 is not available, the controller device A can make a request and capture the device interface, of the controlled device B, directly from the controller device B, by first sending a request to the device B over the network . However, if an Interface Library 80 is available, the controller device A may request all or part of the device devices of the controlled device B from the Interface Library 80. The object request broker software agent of home network, or has the device's XML device interface B, from the structure of the Interface Library 80, and sends it back to the controller device A.

Once the controller device A receives the XML device interface of the controlled device B, the controlling application of the device A uses the XML parser 74 of the device A, to analyze and interpret the device interface of the device. B. The codeR (encoder / decoder) XMLRPC 76 of device A then generates the desired XMLRPC command messages, using the results of the analyzer. The XMLRPC command messages are sent to the controlled device B over the network. Until receiving the XMLRPC command messages, the controlled application 84 of device B, uses the XML parser 74 of device B, to analyze and interpret received XML command messages. The codex XMLRPC 76 of device B then decodes the results of the analyzer to obtain the method call information in the command message, including the name and method parameters for device B to operate to perform the required services. The controlled application 84 of device B then uses the Native 88 Verification Table and the Handlers 90 within device B, to access and launch the native function implementations of device B, through the native interface of the device B. device B. If a function generates any response or return values, said responses or return values are encoded in XML or XMLRPC messages and are sent to the controller device A. Additionally, the intermediate program layer of the network object request intermediary of home and the library of interfaces, can provide to controller device A, a reference to controlled device B, where device A can generate remote calls to the native functions of device B, only as calls for the native function of the local device A. Preferably, a standard XMLRPC format is used, so that all devices can interpret and decode RPC calls over the network. Since the device interface of a controlled device 14 can be queried and examined by means of the controller device 14, a simplified XMLRPC format with sufficient device interface information to improve efficiency will preferably be used. The following example shows two possible XMLRPC call formats for One-Touch Calling (OTR) and Time-Delay Recording (TDR) operations.

EXAMPLE I: XML call, example format, including detailed information of tags and interface 1. Example of call OTR: < ? xml version = "1.0"? > < call > < object > DV CR1. record < / object > < method > timeDelayedRecod < / method > < parameters > < parameter < name > channel < / name > < value > < int > 4 < int > < / vaiue > < / parameter > < parameter > < name > recordTime < / pame > < value > < time > 2:10:30 < / time > < / value > < / parameter > < / parameters > < / call > 2. DTR call example: < ? xml vers? on = "1.0"? > < call > < object > DVCR1.record < .object > < method > oneTouchRecod < / method > < parametcrs > < parameter > < name > channel < / name > < value > < channelName > NBC < / channelName > < / va lue > < / parameter > < parameter > < name > startT? me < / name > < value > < datetime.iso8601 > 19990401 T19: 05: 35 < / datetime.iso8601 > < value > < / parameter > < parameter > < name > recordTime < / name > < value > < time > 2:00:00 < / time > < / value > < / parameter > < / parameters > < / call > EXAMPLE II: XML RPC Call, sample format with reduced interface information and 1. OTR call example: labeling. < ? xml version = "1.0"? > < call > < object > DV CR1.record <; / object > < method > timeDelayedRecod < / rnethod > < pa rameter value = "4" > channel < . pair ameter > < parameter value = "2:10:30" > recordTime < / stopper > < / call > 2. DTR call example: < ? xml version = "1.0"? > < call > < object > DVCR1.record < / object > < method > oneTouchRecod < / method > < parameter value = "NBC" > channel < / parameter > < parameter value = "19990401T19: 05: 35" > startTime < / parameter > < paramctor value = "2:00:00" > recordTime < / parameter > < / call > Referring to Fig. 20, the device interfaces for home devices 14, are based on a structured database standard in industry 100, using a standardized vocabulary. The interface data for the new interfaces and the vocabulary can be added to the database 100. An integral definition or database of CE objects, mes and parameters that use words in English to describe all CE devices, is called CE database 102. The integral definition or database can be in C, XML or other formats capable of representing objects, as well as their mes and parameters respective. The integral definition or database that uses standardized XML vocabulary is called XCE definition or database 104. The controlled and controlled applications 82, 84 are programmed using a subset of standard interfaces of the XCE database, based on XML 104. Each Device interface is stored with said applications 82, 84, in XML format. Algh the XCE 104 database does not need to be in XML, said interface of the subset produced at the time of compilation is in XML, in an embodiment of the invention, as has been described above with reference to Fig. 15 In Fig. 20, in embedded devices 14 the information designated as Manufacturer information 'Man uf a ct urer', is incorporated into devices 14 at the time of manufacture and the information designated as Home Network 'Home Network' is part of the operational aspects when running the device, within the network. The device XML interfaces 72 designated as i ... N, for N devices 14, are branches of the data in a standardized XCE database 104. A Home Network Interface Library 106 (HNIL) provides a collection of the device interfaces, available devices 14, connected to home. The Network Interface Library 106 is a subset of the entire XCE database 104. In Fig. 16, an interface of the device was transferred from an A device to a device.

B for an application B within device B, to examine the contents of the interface for the device A. As detailed above, a device interface includes a description of objects, mes, parameters supported by the device, and is referred to as INTERFACE-A.XML for device A, for example. An XML interface of the device 72 is a device interface in an XML format. The content of the XCE database 104 is a service-oriented structure that provides device interfaces. Referring to Fig. 20, the XCE 104 database also includes a standardized Document Type XCE Interface Definition (DTD) for CE devices, which provides a standardized set of rules for using XML, to represent CE 14 devices. The DTD definition or its subsets can be used for validity checks. A software agent designated as Manufacturer Tool 108 filters and uses a subset of the XCE 104 definition for a specific CE device and uses the DTD definition of the standardized XCE interjection, to generate an XML device interface 72 of the CE device, for example, INTERFACE. XML and INTERFACE. DTD. The INTERFACE document. XML includes a description of objects, mes and parameters supported by a specific device, according to the DTD document of the standardized XCE interface. The INTERFACE document. DTD is a subset of the standardized XCE interface DTD document and can be used to verify the validity of the device's XML interface. Other document type definitions can also be used to create the INTERFACE.XML document. The XML interfaces 72 of the CE devices, including the XML interface document and the DTD document, are stored in a universally accessible library, such as the Home Network Interface Library 106. A software agent 110 collects the device interfaces 72 of all the devices 14 accessible over the network and places them in an Interface Library. 106 structured and searchable, along with device name / address information. The Interface Library 106 is a subset of the XCE 104 database and the process for generating the Interface Library 106 is similar to reconstructing a part or to-Pa of the XCE database 104. The Interface Library 106 may function as a collection of device interfaces 72 of all devices 14 that are in the home network, or as a hidden or temporary memory , depending on the availability of the storage space, where only the most recently used device interfaces 72 are stored therein. In cases where a device 14 updates its device interface 72 due to an event, such as changing a disc in a DVD player, a part of the device interface 72 is updated based on an event service. Referring to Fig. 21, the interface definition of device 72 of each device 14, preferably has a hierarchical shape. This is caused because in a home device 14, the interface definition of the device 72 can be very extensive. Typically, one or a few functions such as a single function for the Recording of a Key, are accessed in a single moment and consequently, only a small portion of the interface of the device 72 is used. Instead of reproducing the complete device interface 72, it is more efficient to reproduce only a portion of the device interface 72.

By means of using the hierarchical device XML interface, a controller device 14 can make a partial request of the device interface 72 of a controller device 14, by means of specifying the desired function categorics or functions within a request for the interface of the controller. XML device, from the controlled device 14 or from the intermediate program layer 98 of the Home Network Object Request Intermediary and Interface Library. In the latter case, the intermediate program layer 98 of Home Network Object Request Intermediary and Interface Library sends back the desired portion of the device interface 72. Referring to Fig. 21, the hierarchical interface structure The device can include four layers, including: (1) a first layer 112 for the XML interface of each home network, which lists the currently available devices, (2) a second layer 114 for the general XML interfaces of each device, which lists the categories of the functions, (3) a third layer 116 for the specific XML interfaces of each function category for a device and (4) a fourth layer 118 for the specific XML interfaces of each function within a category of functions. Within the home network, only the three lower layers 114, 116 and 118 are used, and the first layer 112 is used outside the home network. Fig. 22 shows the layers 112, 114, 116, 118 and the corresponding interface examples. The interface of each layer is linked to the upper or lower layer (if available) through links such as Xl ink or XPoin ter, which provide a two way link. The Xlink link includes a package for a hyperlink functionality that has two parts: (1) an XLink component that allows links in XML documents to be recognized as such, and (2) an XPoin ter component that allows links to be located in the precise subparts within an XML document. Thus, the XLink link governs how links are inserted into XML documents, where the link can point to data such as a GIF file. Additionally, XPoin ter governs a fragment identifier that can go to a URL when it is linked to an XML document, from anywhere (for example, from an HTML file). In a typical command and control model for a server device 14 to control another server device 14, according to the present invention, a first device 14 attempts to query the device interface of a second device 14 in the second interface layer 114. After selecting the function categories (FC), the first de 14 queries the interface layer 116 of a function category specifically of the second de 14, such as a Recording Category. Additionally, the first de 14 may query the interface layer 118 of a specific function, such as OTR or DTR, to make calls to said functions. The hierarchical or tree structure makes it more efficient against an interface function and now bandwidth over the network. An example of structure of interface files and layers can be: First layer 112 - HNLxml Second layer 114 - VCRLxml Third layer 116 - VCR 1 RecordCategory.xml Fourth layer 118 - VCR_1 RecordCategory_OTR.xml Similarly, the Home Network Interfaces Library 106 is preferably hierarchical and can be structured in a variety of ways, such as by means of different types of device service or by different locations, such as rooms. This hierarchical structure is the interface from a local home network 10¡ * for other home networks or the Internet. An example of a hierarchical interface definition of the device 72 that can be implemented in XML syntax is shown below. consumer l occument_ £ ile, doc) + dacun.ent_file < server_hsme dt: d. server_auco.dtd > + doc (services_home, aerver_auto, server_satpsung_web_site, avc_commands, cal_commands.,.}. + serv? cee_home (xml utility, client, server_av, lighting, corrana, hvac, utility, security, appliances, conveniepce, t) + xml utility (download_DTD_file ,?, + client (acjcnowledge, attftntion, Rrror, poñt_mesaage, sound, stop_schedule, sto? _all,,) + sound (alarm, rinq, buzz,,) + server_av (controls_gen, eource, sink) + controls_gen (ping, process_infor, se up ,.) + process_ipfn (s / _id, h / _id) + h / _id (aer_no, manuf, model, class,,) + s / w_id (ser_no, exe_name, version,,) + eetup (clock,,) + clock (hours, minutes, eeconds) + - source (eervice_id, media, rate, protocol, st.reatt1_farm4.1L.controls_av,,) - * sink (air_c, media, rate, protocol, scream_format, controls_av,,) * • service_id (url,,) * media (tpt_streap ?, ram, diak, tape,,) + disk (yam, number ,,) + - --rate < value > + protoccl (61883/1394, UDP / iP / Ethemet,,) + 61883/1394 (isoc.h_ch._no) + strea! r_format (video, audio,,) * video (dv, mpeg2 pL, dsstp, m? eg2pes , mpegi? «u? -tpt,) * audao (m? eg3, ac 3, midi ,,.}. '^ + controls_av íflow_control, tune, timer_record, ui control,,) + ¿mer_record (tune, flow_control) + flow control (play, stop, goto, record ,,) + play (time_params) »• record (t? me_params) + tirpe_params (no, start, duration, end,,) + tune (send _ epg, chanpel,,) + cnnel int, id, time ^ jsarama,,) + ui control (display, acoustic) + display (brightness. contrast, csTor / tint, 0 horiz_s? ze, vert_size,, ) + acoustic (volumn, base, treble, balance, fade,) + lighting (sensors, lights, send_cpg) + senso to (liv? ng_room, sky,.) - *. 1ights (roome_u, rooms_do n, yarri,,) + rooma_up (bedl, bed2, bed3, bed4,,) + bedl (lamp, dimmer,,) -. dimmer < valuc > + rooms down (family, ki chen, living, dining, soho, garage,,) +, uelco.) * + homehub (send dev? ce_list, sena canfiguration, send_snmp_mib,,) + interco 0 + telco O + hvac Icontrols ^ gen, controls_havc,,) +. controls_hvac (a / c, heat, temp, humidity,) - + temp (low, high, hysteresis,,) _ ». utility (meters, energy_mgmt,,) + - tneters (water, gas, 'electric,,) + wate < value > , gas < value > , elec ric val é »+ security ísenaora, eend_cpg, alarm,,) + sensors (peripheral, motion,,) + peripheral (rooms_np, rcx.mñ_down,,.}. + motiop (rssm_down, yard,,) + appliances ( microwave, range, oven, fridge, freezer, coffee, toaeter, washer, dryer, water_heater,,) + microwave (send_epg, controls,,) + fridge (temp,,) + water_heater (temp) + convenience (window, curtain_open, door / gate, pool / spa, bath, fountain, lift, jacuzzi,,) * curtain or? in <value> + server_auto (message, server_auts_ford_explorer_98,,) _ server_auto_ford_explorer_ 98 (mileage, aiptenance,,) + mileage < data> maintenance data> -r server samsung_web_si e (message, servicc, help,,,) + a c_commands <,,, command_s ring,,, + service___id url ,,) + cal commands < ,,, command_st? ng,,, »+ service_id (url,,) Said hierarchical device interface definition 72 may include the following fields: Name 'document', provides the name of the file of the document type definition (DTD) that can be used by an XML parser 74 for the verification of legality and correctness of the XCE 104 database or part of the XML version of the XCE 104 database. There may be several DTD files for different parts of the XCE structure, where said DTD definitions are different from the Definitions of type Be document, for the communication of RPC.CALL and INTERFACE. DTD. Name 'doc', provides the name of the highest level the coverage area of the capabilities, attributes, communication and control interface. 'Servi ces_home', provides an area for home automation, consumer electronics, utility, etc. 'Server_a u to', for a car that is in the garage and shthe message interface available for one or more types of cars. For example, 'server_a u to_ford_expl orer_98' is the interface for a particular car. This allaccess to the car's mileage and maintenance interfaces and can also be used for remote access through an automobile manufacturer or workshop, for direct verification and remote diagnostics, for example. 'server_samsung_websi te', provides communication with a web page of a manufacturer outside the home. Includes the interface for messages, service, help, etc. 'AVC_commands' and 'CAL_commands', is provided for heritage devices capable of interpreting AV / C and CAL languages, for example. This portion of the structure identifies comar? ßos in these languages, where the commands are tagged and transported in XML. Thus, the contents are not XCE objects (Web) and applications of the protocol converter can be used to interface with the original CAL or AV / C application software. In the previous description, 'Services_home' provides the main structure, including electronic audio / video consumer devices. A branch of the structure is expanded in detail for a particular example of a video service acceptor control interface and train destination (e.g., a digital video recorder (DVCR)). Control interfaces within a typical home network can include: 'xml_u ti li ty', provides details to support utility network functions, such as downloading a DTD file, an interface file, an updated program file, etc. . 'cl i en t', describes the interface details of a client device 12, including a Web brr. For example, 'acknowledgmen t' indicates the acceptance of the controller to recognize a message or command sent. 'server_av', provides control and capacity interfaces for all available audio and video services, including STB, DVCR, DTV, DVD, AUDIO, etc. 'l i gh t ing', provides an interface for a lighting automation controller for home, and includes sensors, spotlights, etc. 'comms', provides control interfaces for communication devices, typically for utility purposes or for remote management of device configuration or parameters to retrieve configurations. 'hva c', provides interfaces for the remote control of a heating, ventilation and air conditioning (HVAC) system and can be used to control said system from outside the house through the service company, for example, to turn off the HVAC system during peak load periods during the day. Additionally, said interface can be used to control the HVAC system from inside the house, by means of an apparatus so that the controller based on the device provides a more sophisticated control mechanism than the control of the thermostat. 'u ti l i ty', provides an interface to read utility meters for the house, for example. 'securi ty', an interface for security sensors and alarm configurations. Thus, when using the interface, applications running on a home network device can access sensor devices and detectors around the house to monitor and control these devices. 'appl iances', provides interfaces for kitchen, utility and general household appliances, including for example, to provide remote control or temperature monitoring configurations or other controls and parameters from a controlling device. In a scenario, a microwave apparatus can scan bar code information in the package of a food article for a given type of microwave oven system. This integration of devices that use the command and control from device to device, provides many control scenarios to provide services such as automatically pause a dishwasher and put a television in silence, when a telephone is answered in the kitchen or in room. 'convenience', provides interfaces for the devices to provide convenience services such as interfaces for curtain controllers, windows, blinds or whirlpool tubs, for example.

In the previous description, 'server_a v' is part of the structure for the control interfaces of audio / video devices, which offer an audio / video train service and is subdivided into capabilities 'with trol s_gen', 'source' (source) and 'smk' (acceptor). 'con trol s_gen', provides an interface for attributes of general purpose device manufacturers, such as a test with an Internet packet finder (ping) of the presence of the device. Additionally, built-in attributes such as identification information and version of software and hardware may also be included. A device that supplies this interface returns data that provides the name or identification of the software, without performing any control action. A meter can also be included to set the clock for the time of day. 'sink' provides a platform for media train service devices. The structure is organized based on the service offered (ie, recording and playback of video streams) instead of particular device names such as VCR. For example, a Tuner and a DVD player are both sources of video program streams for the network with video program formats and can be controlled, such as being initiated and stopped. The differences in the control of particular devices are located by the lower layers of the structure of the definition. 'source' provides an interface similar to the 'sink' interface. As referred to above, "service" or "application" on a web server includes the name, address or web address, or URL location of one or more devices 14. Since the XCE database 104 comprises All of the agreed interfaces, a Dynamic Host Configuration Protocol (DHCP) software agent typically runs to assign a default address and name for each device, and the default address and name are added to the service interface or device. The software agent 110 then collects the device interfaces 72 that include the subset of 'partial device XCE' definitions of all devices connected locally to the home network, to generate a partial network XCE. Additional external interfaces relevant to the structure can be added for external control. For example 'servi ce_? D' can be a name / address within a network structure or in a Network Interface Library 106 that includes inputs from the software agent in accordance with the device interfaces of the devices connected to the network. Therefore, a user can search for a service within the data base and access an application whose interface includes a particular data branch of the library, using that name / address. Thus, the network can include multiple identical services distinguished by the name / address information. 'media', provides an interface for the type of media including, for example, the transport stream from a tuner, RAM from a personal computer DRAM, disk for a CD or DVD, and tape. The media can be named and identified and a controlling device can search the XCE database to identify the media currently provided on the network. When a new medium such as a digital video disc DVD is provided on the network, that portion of the device interface 72 identifies the program material on the disc that is being accordingly changed. Thus, the entire device 72 interface does not need to be transferred and only the relevant portion transmitted to the XCE database. Upon receiving a warning signal, the library software agent 110 can capture the new update and place it in the appropriate place within the Interface Library 106. The addition of disk media is similar to adding a service to the network or connect another device to the network. 'ra te', provides a value for the data stream ratio of a device interface, such as 6 Mbits / sec or 19.2 Mbits / sec, for example. 'protocol', identifies the protocol used for said data stream. If more than one protocol is provided, for example 61883/1394 or UDP / IP, then a desired protocol may be selected. 's tream_forma t', provides a packet format and / or a compression standard for the division of audio and video in digital train. If a format is provided more, a desired format can be selected through the interface message. A controller application 82 can examine the available formats to determine if there are formats that are compatible. 'with trols_a v', provides the main control interface for an A / V media device. 'Fl ow_con trol', provides data train controls such as PLAY, STOP, GOTO, RECORD, etc., as methods of a particular device. The methods do not change for an embedded device, except for the software of a PC, for example. The controls may include time parameters for delayed operations. 'Tuning', provides an interface for synchronization control. A controller device 14 can send a request to the interfaces a controlled device 14, so that I send back the data structure of the Electronic Programming Guide (EPG) described above. 'Ul trol', provides a control interface for a controlled application 84, to control settings in the display display, such as brightness and contrast, as well as for audio, such as volume and bass. 'Time_record', provides in interface for the configuration data of a controlled application 82, to implement delayed recording in time. The direct channel synchronization information and the flow control information (t? Me_apa rams) can be used. The above description can also apply to client devices 12. An XCE definition or database of alternative syntax can be used for the CE space. The XCE alternative syntax database includes full service descriptions that include home, appliance and automotive automation, for example. In cases where a service object provides flexibility and parameters to control, a control method is used to control the object as desired. Some example commands are shown in the AV / C and CAL command languages including binary and hexadecimal data strings. consumer (document_fi IR, doc). documept_fxle < server_home dtd, server_auto.dtd > -. doC (ave commande, cal commands, services_home, scrvcr_a co, server_samsung web site, server_auto_ford_explorer_98,,) + avc_commands < ... command_string ... > + cal_commands ... commcmd_Dtring ... > H services_ho e (client, av, lig ting, co ms, hvac, utility, eecurity, appliance, convenience,,) + xml_utility (do nload_DTD_files,,) + client (actaiowledge, attention, error, post_meseage, sound, stop_schßdule, stop_all ,,) + sound (alarm, ring, buzz ,,) + Berver_av (source, yes? -k). cource (sarvicß_id, media, rate, protocol, strea? n_f ormat, controls_gen, controls_av,,) x sink (Bervice_id, media, rate, protocol, stream_format, controls,,) + service? (url ,,) + media (tpt_stream, ram, disk, tape ,,) + d sk (yam, number ,,) + rate < value > + protocol (61893/1394,? DP / IP / Ethernet,,) + 61883/1394 (? soch_ch_no) + stream_format (video, audio.,) + video (dv, mpeg2tpt, dsstpt, mpeg2? en, mpegl080l-tp, ) + audio (mpeg3, ac- 3, idi,,) + controls_gen (ping, process_? nfo. setup,,) + control av (flow control, tune. t? mer_recsrd, ui control,,) + process_? n £ or (a / w_? d, h / w_? d) + h / w_? d (ser_no, mai? uf, model, claes,,) + s / w_id (be no, exe yam, version,,) + setup (clock,,) + clock (hours, minutes, seconds) + t? me_record (tune, flow_control) + flow_control (play, s op, goto, record,,) * play (t? me__parame) • «• record (? me_params) _, tune (eend__epg, channel,,) + channel (nuber, id, t? me_params,,) + t? me_params (now, start, duration, end,,? + u __control (display, acoustic) + display (bnghtness, contrast, cslor / tint, hor z_s? ze, vert_s? ze,,) + acoustic { volume, bass, treble, balance, fade,) -lightmg (screen, ligh, send_epg) t. ßansora (l? v? ng_room, sky,,) + lights (rooms_up, rooms_down, yard,,) + rooms_up (bedl, bed2, bed3, bed4,,) + - rooms_down (l amily, kitchen, living, dmmg, ßoho , garage,,? • + • yard (TronL, back) • * - bedl (lamp, dimraer,, > + d mer «.value > -comme (netmaua, mnercom, telco,) + netman (send deviee list send_conf? gurat? on, send snmp mib,,) + intercom O + telco 0 -hvac (controls_gen, controls_hvac,,) + controls hvac • (a / c, heat, temp, humidity,) + temp (low, high, hysteresie,,) -utility (meters, energy gtnt,,) i meters (water, gas, electric ,,) + watf? fr <; value > , gas < value > . electric value • > + security (seneors, send_epg, alram,,) + sensors (peripheral, motion,)) + peripheral (rooms_up, roome down,,) + motion (rooms_down, yard,,) + appli-aices (microwave, range, over, fridge, freezer, cooker, toaster, waeher, dryer, water - heater,,) + microwave (send_epg, controls ,,) + fridge (temp,) + water-heater (temp) + conveniepce (window, curtain_open , door / gate, pool / spa, bath, fountain, lift,,) + curtain_open < value > + server_auto (message, mileage, maintenance ,,) mileage < date > maintenacecdatav In another aspect, the present invention provides the use of existing command language implementations for device-to-device command and control within a network.

Devices can include internal objects and API interfaces, which at the time of running, create binary chains according to existing transport mechanisms. In this case, with the aim of providing remote XML procedure calls (XMLRPC) from a device 14 to another device 14 within application interface calls to the XML service API interface. Thus, the original implementation is equivalent to a container for the service API interface. Fig. 18 also shows applications created using other command languages such as CAL or AV / C in dotted lines, with their interface implementations replaced with a container within the XCE / XML service API interface. Examples for changing the CAL command language to the XMLRPC format are shown below. existing implementation: void DeviceCALCommand (int coromand). { / * Create CAL to train you! byte string to represent this object / roethod and output to the wire * / CreatCALFormattedByteString (command); / * different for each protocol * / SendCALBytpStr.ngO; / * different for each protocol * /} containing the Servivio XML API call void DeviceCALCommand (int command.} {. {replace the CAL implementation with calls to the XML API Service * / Create MLMessage (copronand); / * always the same * / sendXMLMcssaae £) / /* always the same */ Referring to laflUfg. 23, in another aspect, the present invention provides a translation of control language and standard command protocol for communication between devices, between disparate devices in a network. In order for different devices to share information, the information must be in a format that can be interpreted by a device that requires it. Thus, for a device 120 to control another device 22, the two devices must use a common language, with the objective of interpreting the other's commands. The present invention provides a common identification format for data protocols and commands. In one embodiment, a common data presentation or packaging method _ is provided, wherein a receiving device 122 can determine the native format of the transmitted data. If the receiving device 122 can interpret that native format, then it can directly accept the data. Otherwise, the receiving device 122 may make a request to a translator device or application 124, to translate the data into a desired format, which may interpret the requesting device 122. The translator device 124 or application, determines the native format of the original data, translates the data into the desired format and sends the translated data to the requesting device 122. The requesting device 122 then processes the data, such as the data that had originally been provided in the native language format of the requesting device by means of the sending device 120. The requesting device 122 may also send a reply back to the sending device 120 in the native format of the requesting device, or send a reply by means of a proxy server (proxy ) through the translator device 124 or application, to translate it into the native format of the transmitting device 120. The translation method can be used for information, including the command protocol, the data files and the audio / video streams. For devices that do not use the common format described above, the present invention provides translation of data, including command protocols to and from such non-compatible devices. For example, when an unsupported device 120 sends data to a compatible device 122, the compatible device 122 can translate the data based on the determination of the native format of the data.

For example, the compatible device 122 may examine the data in particular binary patterns within the data. When a compatible device sends data to a known non-compatible device, the compatible device can translate the data before transmission, based on the determination of the native format of the non-compatible device. An example implementation can be a home network that supports IP and HTTP protocols. The home network can be connected to the Internet to obtain applications and services of various desired types of functionality. As such, the method in common format can be converted to compatible with Internet protocols and with the procedure of operation over the Internet and the home network. An example of providing a common data format is to use XML to create a data packet that is transmitted over the home network. The data can include the command protocol, audio or video streams, graphics or applications. The data is 'contained' with a standard header that identifies the native format of the data and the content of the package, in XML form. The header allows the unique identification of the data type, the data portion of the XML code, where the data can be Translated if necessary and provided to the appropriate applications upon receipt. According to the regulations of the Web, the criticism process is carried out by browsers that use file name extensions, to identify the type and content of a file transmission. Markers can then launch appropriate pl ug-in modules to process the file. In the home network, XML is used to notify the data transmissions that provide all the transmissions of the home network, over the Internet protocol (IP) with a common identification method, such as the one described above. Alternatively, a software layer may be provided within the protocol stack of the home network, to uniquely identify the content of all data transmissions that pass over the home network. The software layer can be used instead of XML. The common format and the identification principles of the present invention also apply in any modality using XML or the software layer, as identification method. In Fig. 23, upon receipt of a data packet transmission, the receiving device 122 examines the XML identity header of the data packet, to determine the format of the data found within it. ' If the data is in a format recognizable by the device 122, the XML identity header information is discarded and the device directly processes the data. Otherwise, the device 122 converts the received XML packet into an XML translation request packet and sends it along with the data to the translation server device 124. The translation server device 124 translates the data and converts it into a packet. of XML translation response. The translator server 124 then transmits the response packet, back to the requesting device 122. In case of a translation error, the translation server 124 can provide a translation response error condition to the requesting device 122. Upon receipt of the data translated, the requesting device 122 processes the translated data in the response packet.

An example of an XML data package can be: < IDENTITY type = format = AV / c > ... packaged data ... < / IDENTITY > An example of a translation request package can be: < TRANSLATION REQUEST TYPE = Command format = CAL > < IDENTITY type = Command format = AV / c > ... packaged data ... < / IDENTITY > < / TRANSLATION REQUEST > An example of a translation request package can be: < TRANSLATION RESPONSE type = Command format = CAL > ... packaged data ... < / TRANSLATION RESPONSE > An example of a translation response error condition package can be: < TRANSLATION RESPONSE type = Command format = CAL > ... packaged data .. < ERROR Conditon = Unrecognized Command > The translation can not have been made < / ERROR > < / TRANSLATION RESPONSE > Additionally, Table 3 of Fig. 24 includes a partial list of package types and formats.

To provide translation services, a translator server 124 is identified within the network during network configuration in a manner similar to DHCP servers. Translation server 124 broadcasts its IP address to all devices that are in the network, for a period of time after the network is configured. All the devices 120, 122 compatible with the translation services, store the IP address of the translation server 124, while this is broadcast over the network, during the initialization of the network. Alternatively, the requesting device 122 may issue a translation request on the home network. All translation servers 124 within the network that receive the translation request, can respond to the translation request by means of sending a translation response to the requesting device 122. The requesting device 122 then selects a translation server 124 among the Translation servers that answer. In one example, the requesting device 122 selects the first translation server 124 that responds to the translation request. In another example, the translation servers 124 can negotiate between themselves and / or with the requesting device 122, to select a translation server 124 that satisfies the translation request. In another embodiment of the invention, multiple translation servers are used to satisfy all translation requests. For example, a single translation server 124 may not have the ability to translate all requests. In such cases, it is necessary to identify the address of each translation server 124 and the type of translation service that each translation server 124 can provide. Each device 120, 122 may store a list of all the IP addresses of the translation servers and a corresponding list of the types of translation services that each translation server 124 provides and optionally the associated translation application. For efficiency purposes, if a sending device 120 wishes to send data to a receiving device 122, which is known to use a native format different from the sending device 120, the sending device 120 may send the data to the receiving device 122 by proxy, to through a translation server 124. The transmitting device 120 transmits a translator device command 124, similar to the translation request command and include the address of the translator. receiver device 122, CE translated data. In cases where a receiving device 122 requires the translation of a data stream, the sending device 120 can route the data stream directly to the translation server 124 and the translation server 124, in turn, transmits the translated data to the receiving device. 122, as previously described. Alternatively, the sending device 120 can send the data stream to the receiving device 122 and the receiving device 122 then routes the data stream to the translation server 124 to translate and return the translated data back to the receiving device 122. In this description, the control mechanism is based on the HyperText Transfer Protocol (HTTP 1.1) which provides an application level protocol for distributed, collaborative hypermedia information systems. HTTP is a generic, stateless, object-oriented protocol with wide use in many tasks. An HTTP characteristic is the marking and negotiation of the representation of the data, allowing the systems of the transferred data to be independently constructed. Preferably, the network protocol used by services and applications over the home network is the Internet Protocol (IP). However, other protocols may be used. Although the invention has been described in considerable detail with respect to the preferred versions thereof, other versions are possible.

Accordingly, the appended claims should not be limited to the descriptions of the preferred versions contained herein. It is noted that, with regard to this date, the best method known by the requested, to carry out the present invention, is that which is clear from the present, discovering the invention. Having described the invention as above, the content of the following is claimed as property.

Claims (12)

1. CLAIMS A method for performing a service on a home network, the method characterized in that it comprises the steps of: (a) connecting a first domestic device to the home network; (b) connecting a second home device to the home network; (c) providing a database that includes a plurality of description data objects of the application interface, each description data object of the application interface including information in a structured format for command and control of a home device, by means of one or more different domestic devices, connected to the network; (d) the second home device accessing a first description object of the application interface for the first domestic device, within the database; (e) the first home device accessing a second description object of the application interface for the second home device, within the database; (f) sending command and control data from the first home device, to the second home device, using the description object of the application interface for the second home device, over the network; and (g) sending command and control data from the second home device, to the first home device, using the description object of the application interface for the first home device, over the network; and wherein the first and second domestic devices perform said service.
2. The method according to claim 1, characterized in that the structured format includes the XML format.
3. The method according to claim 1, characterized in that step (c) includes connecting a database device to the network, wherein the database device stores the database.
4. The method according to claim 3, characterized in that: (i) the first home device stores the first application interface data within it; (ii) the second home device stores the second application interface data, within it; and (iii) step (c) includes an initial step of forming the database in steps, including consulting the first and second home devices, to transfer the application interface data for the first and second home devices, to the database device.
5. The method according to claim 1, characterized in that step (d) includes providing the first description object of the application interface for the first domestic device, from the database to the second domestic device over the network.
6. The method according to claim 1, characterized in that step (e) includes providing the second description object of the application interface for the second home device, from the database to the first home device over the network.
7. The method according to claim 1, characterized in that it additionally comprises connecting three or more devices to the network, wherein at least one domestic device accesses the database to consult the description objects of the application interface, of a plurality of domestic devices, to send command and control data to the plurality of domestic devices over the network.
8. The method according to claim 1, characterized in that each object of description of The application interface includes data in a structured format.
9. A network system for providing a service, characterized in that it comprises: (a) a physical layer, wherein the physical layer provides a means of communication that can be used by devices, to communicate with each other; (b) a first domestic device; (c) a second household device; (d) a database that includes a plurality of description data objects of the application method, each description data object of the application method including information in a structured format, for command and control of a domestic device by means of one or more different devices connected to the network; wherein: the second household device includes application control means for accessing a first description object of the application interface for the first home device, within a database and sending command and control data from the second home device to the first home device, using the description object of the application interface; and the first home device includes application control means for accessing a first description object of the application interface for the first home device, within a database and sending command and control data from the first home device to the first domestic device, using the description object of the application interface; consequently, the first and second domestic devices perform said service.
10. The network system according to claim 9, characterized in that the structured format includes the XML format.
11. 11. The network system according to claim 9, characterized in that it additionally comprises a database device that stores said database. The network system according to claim 11, characterized in that: (i) the first home device stores the first description object of the application interface within it; (ii) the second home device stores the second description object of the application interface within it; (iii) the database device forms the database by means of consulting the first and second devices, to transfer the first and second description objects of the application interface, respectively, to the database device . 3. The network system according to claim 9, characterized in that the control application means of the second domestic device, obtain the first object of description of the application interface for the first domestic device, from the database. The network system according to claim 9, characterized in that the control application means of the first domestic device, obtain the second object of description of the application interface for the second domestic device, from the database. The network system according to claim 9, characterized in that it additionally comprises three or more domestic devices, wherein at least one domestic device accesses the database to consult the description objects of the application method of a plurality of domestic devices, to send command and control data to the plurality of domestic devices, over the network. The network system according to claim 9, characterized in that each object of description of the application interface includes data in a structured format. The network system according to claim 9, characterized in that the structured format includes the XML format Summary of the Invention A method and system for performing a service on a home network, by connecting a first and a second home device to the home network, providing a database that includes a plurality of data objects describing the application interface, wherein each application interface description data object includes information in a structured format, to command and control a domestic device by means of one or more different domestic devices, connected to the network, the second domestic device accessing to a first object of description of the application method for the first domestic device, within the database, the first domestic device accessing a second object of description of the application method for the second domestic device within the base of data, send control and command data from the first domestic device to the second domestic device, ut The object of describing the application interface on the network, and sending control and command data from the second domestic device, to the first domestic device, using the first object of description of the application interface on the network. Accordingly, the first and second domestic devices perform the service.