MXPA00002741A - Peripheral electronic device and system for controlling this device via a digital bus - Google Patents

Abstract

A minimal level of interoperability for exchanging audio/video (A/V) content and associated control between common consumer electronic (CE) devices is defined. This interoperability is based on the IEEE 1394 serial bus for the physical and link layers and makes use of AV/C or CAL as the control language. On-Screen Displays (OSDs) (e.g., menus) may be transferred from a peripheral device (for example, digital VCR) to a controller (for example, DTV) by sending one frame of video either using a push or pull method in conjunction with the asynchronous services of the IEEE 1394 serial bus via an isochronous channel.

Description

PERIPHERAL ELECTRONIC DEVICE AND SYSTEMS TO CONTROL THIS DEVICE BY MEANS OF A DIGITAL COLLECTOR BAR Field of the Invention The invention involves a system for controlling multiple electronic devices, such as consumer electronic devices or the like, by means of interconnections, such as digital data bus bars. More particularly, this invention relates to a configuration for managing the interoperability of these devices.

BACKGROUND OF THE INVENTION A data busbar can be used to interconnect electronic devices, such as television receivers, visual display devices, video cassette recorders (VCRs), direct transmission satellite receivers (DBS), and broadcast devices. home control (for example, a security system or a temperature control device). The communication using a data bus is presented according to a bus protocol. Examples of bus bar protocols include the Consumer Electronic Bus Bar (CE Bus), and the IEEE High Performance Serial Bus Bar. A bus bar protocol typically provides communication of both control and data information. For example, CEBus control information is communicated on a "control channel" that has a protocol defined in the IS-60 specification of the Electronics Industries Association (EIA). In an IEEE-1394 serial bus, control information is usually passed using the asynchronous bus services in series. The control information for a particular application can be defined using, for example, the Common Application Language (CAL), or AV / C. Currently, most audio / video (AV) devices are controlled by a remote control unit (RC). The actual physical or direct link can be implemented with infrared (IR), ultrasound (US), or radio frequency (RF) transmission. The protocol between the peripheral device and the remote control unit is a specific device, such that each device comes with its own remote control unit. Each peripheral device interprets the clicks it receives through its direct link, and performs the corresponding actions. These actions may include, but do not require, the activation of an on-screen visual display (OSD) mechanism in a visual display or control device (eg, TV). Most important, even when this OSD mechanism is activated, it serves only as a visual feedback to the user. The actual control is driven by the input to the remote control unit, and takes place even when the visual display device is turned off (i.e., the visual display on the screen is not visible to the user). A visual on-screen display of these audio / video devices is generated in the peripheral device or target, and occurs over the NTSC output of the device in the same manner as any other video signal. Accordingly, no additional hardware or software is needed in the peripheral device or in the visual display device. Figure 1 illustrates a current A / V system 10 having a VCR 12 and a visual display device 14 (e.g., a television), which employs this control methodology. The menus associated with the control VCR 12, are generated by the VCR 12, and are provided to the visual display device 14 via the NTSC output of the VCR 12 as a composite video. Unfortunately, using the same approach (see Figure 2) with a digital television (DTV), as a visual display device 14 ', is impractical, because it would require that the menus be transported as MPEG transport streams. 2. The generation of these currents requires the integration of an MPEG encoder 15 'in all peripheral devices, which greatly increases the cost and complexity of these consumer electronic devices.

Compendium of the Invention The patent application defines a minimum level of interoperability for exchanging audio / video content (A / V), and the associated control between common consumer electronic devices (CE). The interface is based on the IEEE-1394 serial bus for the physical and link layers, and makes use of a control language, such as CAL or AV / C, to manage the OSDs, and issues connectivity. With most products today, a video source is selected on the visual display device, and then the user interacts directly with the device to be controlled (ie peripheral device (eg VCR)), using the remote control. The menus are generated by the peripheral device, and are transported to the television over the composite video link. The invention defines the transfer of On-Screen Visual Displays (OSD) (eg, menus) from a peripheral device (such as a digital VCR or DVHS) to a control device (such as a digital television or DTV), using one of various formats, such as (1) sending a video frame over the asynchronous channel using a push method or a pull method, triggered by a message from the peripheral device to the DTV, or on an isochronous channel; (2) transfer a coded version in execution length of the visual display on the screen; (3) transfer the actual information in a bitmap format of the visual display on the screen; (4) transport the MPEG-I frame freezes over the isochronic link. In most cases, the peripheral device would not use the MPEG-I frames for the menus, because it is difficult to represent the text using this method, and it is expensive to encode images in real time. However, peripheral devices that want to provide an MPEG image as a background for the menu, could do so. For example, the method of pushing involves writing the menu of the peripheral device (i.e., the device to be controlled) directly into a buffer area of the DTV, which is available by means of the IEEE serial bus -1394 The peripheral device can update the sections of the visual display that have changed, and make the DTV know when it ends, so that it can download the updated menu in the video RAM for visual display. Alternatively, a pulling method may be employed. OSD administration messages and connection management messages will be defined as general structures, which can be carried by means of AV / C or CAL. However, it should be noted that these messages can be easily carried out by other means. One approach of the present invention is to enable the ability to carry A / V information over a digital link, and provide a means for an A / V device to display its menu or the User Graphic Interface (GUI). In addition, the present invention is based on a paradigm of user-machine control, as opposed to the machine-machine paradigm that has been commonly discussed in the foregoing with respect to the control of IEEE-1394 and CEBus. Still further, the present invention supports the use of IEC61883 to carry A / V data through the isochronous channels, and the 61883 FCP can be used to encapsulate the CAL or AV / C command directly over the IEEE-1394 serial bus , and therefore, allows coexistence with other control languages. Many of the devices will use a log table that is constructed during a discovery process, which searches for the information stored in each Self-Descriptive Device Table (SDDT) of each instrument. The SDDT may contain information such as a unique identification, node address, and so on. The log tables would be used by the DTV to build a menu, in order to allow the user to establish connections between the components (in a similar way to when the user selects the composite input for the source of his TV at present).

There are several advantages to this control paradigm, where the peripheral device displays its menu or GUI in the DTV, and accepts the commands directly. For example, it is required to define little control language for basic interoperability, and no device models are needed. In addition, because the inputs go directly to the peripheral device, and because the OSD is defined as a basic video form, the control is totally independent of the type of device being controlled, thus ensuring long-term interoperability. A control language is required to manage the network, OSD, and to optionally transport universal commands through the busbar. AV / C, CAL, or any equivalent control language can be used successfully in connection with the practice of this invention.

BRIEF DESCRIPTION OF THE DRAWINGS The invention can be better understood by reference to the accompanying drawing, in which: Figure 1 shows, in a simplified block diagram form, the interoperability of a prior art audio / video system. Figure 2 shows, in a simplified block diagram form, the extension of the prior art interoperability between a digital VCR and a digital television.

Figure 3 is a simplified schematic block diagram illustrating the IEEE-1394 serial bus protocol. Figure 4 shows, in the form of a simplified block diagram, the interoperability of the digital devices employing the present invention. Figure 5 shows, in a simplified schematic form, the interaction of the digital devices of Figure 4. In the drawing, reference numerals that are identical in the different figures indicate characteristics that are the same or similar.

Detailed Description of Drawings The use of the IEEE-1394 series busbar has been suggested for many applications within a Home Network environment. It is being discussed within the Video Electronics Standards Association (VESA), the use as a "total home network". It is being built on the next generation PCs, and will be used for many local peripherals, including disk drives. It is also clear that this will be an important interface for consumer digital A / V devices, such as digital televisions and VCRs. Within the entertainment group comprised of the consumer's audio / video electronic devices, there are many different levels of interface support at the application level. The IEEE-1394 is a high-speed, low-cost digital serial busbar 16 developed to be used as a peripheral or a backplane bus. Some of the highlights of the busbar include: dynamic node address assignments, data rates of 100, 200, and 400 Mbits / second, asynchronous and isochronous modes, fair busbar arbitration, and ISO / IEC consistency 13213. Figure 3 illustrates the serial bus protocol for the IEEE-1394 serial bus, as a set of three stacked layers. Physical layer 18 has physical signaling circuits, and logic, which are responsible for energization initialization, arbitration, busbar reset detection, and data signaling. Two pairs of protected low-voltage differential signal are defined, plus one power pair for the IEEE-1394 serial cable. The signaling is done using a data slash bit level that encodes double hop tolerance. The data is formatted in packets at the link layer 20. Two kinds of data communication between the devices are supported: asynchronous and isochronous. Asynchronous communication can be characterized as "allows recognition", while isochronic communication can be characterized as "always on time". The asynchronous service will be used primarily to control status messages, while isochronic communication will be used for data streams, such as MPEG video. The timely nature of isochronic communication is achieved by providing a cycle every 125 microseconds. Isochronic cycles have priority over asynchronous communication. Asynchronous transfer can take place at any time the bus is free. A minimum of 25 microseconds is reserved for each cycle of 125 microseconds for the transfer of asynchronous data. The isochronic transfer provides a real-time data transfer mechanism. A continuous isochronic communication between one or more devices is referred to as a channel. The channel has to be established first, and then it is guaranteed that the requesting device has the requested amount of bus time each cycle. Transaction layer 22 defines a complete request-response protocol for performing bus transactions. Although transaction layer 22 does not add services for the transfer of isochronous data, it does provide a path for the administration of the resources needed for isochronous services. This is done through readings and writings in the control status register (CSR). The transaction layer 22 also defines a retry mechanism to handle situations where the resources are busy and can not respond. The asynchronous data is transferred between the nodes of IEEE-1394, using one of three transactions: "read data", to recover the data from a different node; "write data", to transfer data to a different node, and "secure data", to transfer data to a different node to be processed, and then the data is returned to the original node. The administration of the serial bus 24 describes the protocols, services, and operating procedures, where a node is selected, and then can exercise control at the management level over the operation of the remaining nodes on the busbar. There are two administrative entities defined for the IEEE-1394 serial bus; the isochronous resource manager 26, and the bus bar manager 28. These two entities can reside on two different nodes, or on the same node. A busbar manager 28 may be absent from the busbar. In this circumstance, the isochronous resource manager 26 exercises a subset of the administrative responsibilities normally assumed by the bus manager 28. The bus manager 28 provides a number of services, including, speed and map maintenance topological, and optimization of the busbar. The isochronous resource manager provides facilities for assigning isochronous bandwidth, channel number assignment, and master cycle selection. Node control is required on all nodes; the node controller 30 implements the CSRs required by all the nodes of the serial bus, and communicates with the physical 18, link 20, and transaction 22 layers, and with any application present in the device. The node controller component 30, as well as the CSR, and the configuration ROM facilities, are used to configure and manage the activities in an individual node.

In order for the IEEE-1394 serial bus to function properly, an isochronous resource manager (IRM), and a bus manager (BM) 28 will be required. Because most groups will include a visual display device of some kind, it must be required that a Superior Establishment Box with Visual Analogue Display and DTV must be capable of having MRI and BM. In some cases, such as in an all audio group, a visual display device may not be present. In this case, it must also be required that a Digital Audio Amplifier be capable of having IRM and BM. The IRM 26 provides the necessary resources for the serial bus to assign and disassociate in a cooperative manner the isochronous resources (channels and bandwidth), required for orderly isochronic operations. The IRM 26 provides a common location for the other nodes to verify the availability of channels and bandwidth, and to record their new assignments. In IRM 26, whose location is known immediately upon completion of the self-identification process, it also provides a common location where the nodes of the serial bus can determine the identity of BM 28, if one is present. BM 28, if present, provides administrative services to other nodes in the serial bus. These include activation of a master cycle, performance optimization, power management, speed management, and topology management. The Functional Control Protocol (FCP) is designed to control devices connected through an IEEE-1394 bus. The FCP uses the asynchronous writing package of the IEEE-1394, to send commands and responses. The asynchronous packet of the IEEE-1394 is structured with the FCP embedded in the data field shown below. The Command / Transaction Apparatus (CTS) specifies the command group (for example, AV / C, CAL).

FCP frame (shaded) in the payload of an asynchronous script FCP frames are classified as command frames, and response frames. The command frame is written to a command register of a peripheral device, and the response frame is written to a response register of a controller. The standard specifies two addresses for the command and the response. The structure of the isochronic package in IEC-61883 is shown below. The packet header consists of two quadlets of an IEEE-1394 isochronous packet. (A quadlet is defined as four bytes of 8 bits). The header of the Common Isochronous Package (CIP) is placed at the beginning of the data field of an isochronic IEEE-1394 packet, immediately followed by the real-time data.

Length Label Channel Code T If Data Header CRC CIP Header Real time data CRC data The data length is the length of the data field in bytes, Label indicates whether CIP exists (01) or not (00), Channel specifies the isochronous channel number, Code T = 1010, and Si is a control field specific to the application. Standard 61883 defined a generic format for consumer A / V transmission. This format has a two-quadlet header as shown below. In the Table, SID is the identification of the source node, DBS is the size of the block of data in quadlets, Fraction number (FN) it is allowed to divide the packets of the source for the use of the time of the busbar; Quadlet Cushion Account (QPC) indicates the count of the number of quadlets; Source Pack Header (SPH) is an indicator to indicate whether the packet has a source packet header; RSV indicates reserved for the future; Data Block Counter (DBC) is a continuity counter; FMT indicates the identification of the format, such as MPEG2, DVCR; and the Format Dependent Field (FDF) is specific to the identification of the format.

Reserved time stamp The concept of pins and plug control registers is used to start and stop the isochronous data flows in the busbar, and to control their attributes. Pin control records are CSR records for special purposes. The set of procedures that the pin control registers use to control an isochronous data flow is called Connection Management Procedure (CMP). The isochronic data flows from a transmitting device to zero or more receiving devices, sending the data over an isochronous channel in the IEEE-1394 bus. Each flow of isochronous data is transmitted to an isochronous channel through an output pin in the transmitting device, and is received from the isochronous channel through an input pin in each of the receiving devices. The transmission of an isochronous data stream through an output pin is controlled by an Output Pin Control Register (oPCR), and an Output Master Pin Register (oMPR) located in the transmitting device. oMPR controls all the attributes of the common isochronous data flow, while oPCR controls all other attributes. There are similar registers (iPCR, and iMPR) for the reception of isochronic data. There is only one oMPR (ÍMPR) for all output pins (input pins). The content of oMPR (iMPR), includes the capacity of data rate and number of pins, among others. oMPR and iMPR, each one contains a connection counter, channel number, and data rate, among others. There are a number of administrative procedures for each type of connection, which allow an application to establish a connection, overlap a connection, and disrupt a connection. These procedures involve the allocation of IEEE-1394 resources, the establishment of appropriate values in the pin control registers, the reporting of possible application failure conditions, and administrative connections after a busbar reset. Follow one of these CMP. To transport isochronic data between two A / V devices in an IEEE-1394 serial bus, it is necessary for an application to connect an output pin to the transmitting device, with an input pin on the receiver device, using an isochronous channel. The relationship between an input pin, an output pin, and an isochronous channel is called a point-to-point connection. In a similar way, there are external transmission connections (an output pin and an isochronous channel), and internal transmission connections (an input pin, and an isochronous channel). The isochronous data flow is controlled by an output pin control register (oPCR), and an output master pin register (oMPR), located on the transmission side. oMPR controls all attributes, (for example, data rate capacity, base of the transmission channel, etc.) that are common to all isochronous flows transmitted by the corresponding A / V device. The reception of an isochronous data stream through an input pin is controlled by an input pin control register (iPCR), and an input master plug register (iMPR) located on the receiving device. iMPR controls all attributes (for example, data rate capability, etc.) that are common to all isochronous data flows received by the corresponding device. The main steps involved in establishing a connection are allocation of IEEE-1394 resources (for example, bandwidth), and channel establishment, data rate, surplus identification, and connection counter, in oPCR and iPCR. An isochronous data stream can be controlled by any device connected to the IEEE-1394 serial bus, by modifying the corresponding pin control registers. Although the pin control registers can be modified by asynchronous transactions in the IEEE-1394 serial bus, the preferred method of connection management through the use of AV / C. It is completely within the scope of this invention that CAL can be used for connection management.

Application Control Languages In order for an electronic consumer device to interact with other devices interconnected by means of an IEEE-1394 serial bus, a common product mode, and a common set of commands, must be defined. There are three standards for modeling and controlling the device: CAL, AV / C, and the approach adopted by the USB.

CAL and AV / C are control languages that distinguish between logical and physical entities. For example, a television (i.e., a physical entity) may have a number of functional components (i.e., logical entities), such as a tuner, audio amplifier, and so on. These control languages provide two main functions: resource allocation and control. The assignment of resources refers to the request, use, and release of resources of the Generic Network. Messages and control are transported through the FCP, as defined in IEC-61883, and as discussed above. For example, CAL has adopted a base object methodology for its command syntax. An object contains and has a unique access to a set number of internal values known as instance variables (IV). Each object saves an internal list of methods. A method is an action that an object takes as a result of receiving a message. When a method is invoked, one or more IVs are usually updated. A message consists of a method identifier, followed by zero or more parameters. When an object receives a method, it searches through its list of methods, one that matches the method identified in the message. If it is found, the method will be executed. The parameters supplied with the message determine the exact execution of the method. The design of control languages is based on the assumption that all consumer electronic products have a hierarchical structure of common parts or functions. For example, CAL treats each product as a collection of one or more of these common parts, called Contexts. These contexts are designed to allow access to the functionality of the product in a uniform manner. The context data structure is a software model defined in each device, which models the operation of all device functions.

A context consists of one or more objects grouped together to form a specific functional subunit of a device. As an object, the context is a model of a functional subunit. The devices are defined by one or more contexts. CAL has defined a large set of contexts to model different types of consumer electronic devices. Each context, regardless of what product it is in, operates in the same way. The objects are defined by a set of IVs, for example, the IVs for a required binary switching object content, and optional IVs. The required IVs include a variable (current position) that indicates whether the switch is activated or deactivated, and the default position (omitted position) of the switch. Optional IVs include feature_of_positions; report_of_conditions; destination address; previous_value, and report header. The IVs are as variables in any software program, and are supported in CAL, such as Boolean, Numeric, Character, and Information (array) data. The IVs in an object can be categorized into three general groups: support IVs, reporting IVs, and active IVs. The support IVs are usually read-only variables that define the use of the object's installation, and the operation of the active IVs. The active IVs of an object are the variables that are established or read primarily to operate the object.

The interaction between a controller (for example, digital TV), and a target or peripheral device (for example, digital VCR), can be divided mainly into two main categories: i) A machine-machine interaction, wherein both the controller and the peripheral device are machines. It is important to note that, for this type of interaction, there is no user initiation at the time of the actual interaction. However, it is possible that the user will preprogram the controller to perform a specific action at a specific time point. ii) A user-machine interaction, where a human being is initiating actions in the controller. The primary element of user-machine input for analog audio / video (A / V) devices today is the use of a remote control unit, or the front panel. Some of the interaction can also make use of a visual display (OSD) mechanism. In this interaction class, the user interacts directly with the peripheral device. The present application defines a base level of interoperability between the devices of different manufacturers at a minimum cost. Users have the ability to interact with the interconnected A / V devices by means of an IEEE-1394 serial bus, in a manner in which they are accustomed (i.e., using a remote control unit, possibly in connection with a visual display on screen). Figure 4 defines this system 10"to provide interoperability between the digital A / V devices interconnected by means of an IEEE-1394 serial busbar In this 10" system, interoperability is achieved by transferring the menu or information of the GUI directly from the peripheral device 12"(eg, DVCR) to the control device 14" (eg, DTV), using one of the methodologies defined below. The menu is not transferred as a composite video stream, which would require first passing the menu information through an MPEG encoder contained in the peripheral device. The menu is transferred by means of the bus bar in series 16"to the DTV 14", where the menu information on the DTV 14"is superimposed, with the decoded MPEG stream, before being displayed." To simplify the transfer of information of the OSD, a "pull" method can be used to transfer the OSD information from the peripheral device or DVCR 12"to the control device with visual display capability or DTV 14." With this method, the volume of the data OSD is transferred from the peripheral device to a visual display device, by means of asynchronous read requests issued by the visual display device, i.e., the visual display device reads the OSD information from the memory of the peripheral device, making use of when minus a block read transaction of the IEEE-1394.The visual display device is informed of the location and size of the OSD data by means of a "trigger" command, which is sent from the peripheral device to the visual display device, when the peripheral device is ready to initiate data transfer. Because the OSD information in the peripheral device is updated in response to the data entered by the user (such as from a remote controller 13), the visual display device is alerted to the availability of newly updated data. This can be achieved by sending a short message (ie, "trigger") to the OSD object of the control device. It should be noted that this message needs to inform the control device of the initial location, as well as the length of the OSD data to be read. The length is necessary because the application of the control device will make use of asynchronous reading transactions of the IEEE-1394. If the length is greater than what would be set to the maximum possible packet length for an IEEE-1394 network, the controlling device can initiate multiple block read transactions, until all the OSD information has been read. In addition to the start location and the length of the current OSD data to be transferred to a visual display device, a field indicating the type of OSD data is useful. This is especially useful, because in this case, the same mechanism can also be used to trigger the OSD mechanism of a visual display device, to display such things as error, warning, and / or status messages. The differentiation of the OSD data type is useful for the visual display device and / or the user to decide if they really want it to be displayed (for example, a user who is watching a movie may want to ignore things such as status messages). Peripheral devices may indicate to the controller (i.e., visual display device) that they have the OSD data ready to be transferred. An OSD trigger message containing the start offset address, the length of the OSD data, and the OSD type information is sent to the controller. The format of this message is defined later. This information will be used to determine the number of reading requests you need to generate. The visual display device would pull the menu by reading it from the memory space mapped by the bus of the peripheral device. This message could be encapsulated in CAL or AV / C.

OSD data outdated OSD_datos__type OSD_datos_longitud < g Bytes > < 1 Byte > < 3 Bytes > OSD outdated data: 48 bit outdated address used in IEEE-1394, where OSD data can be found in the target node. OSD_type_data: 8 bits field that indicates the type of OSD data presented. A typical orderly stream may include the following messages, as illustrated in Figure 5. The peripheral device (e.g., VCR 12"digital) receives a command belonging to a first key from the corresponding remote controller 13". In response to the command, the peripheral device provides a message to the controller (eg, digital television 14"), which includes the start location and the length of the OSD information corresponding to the appropriate menu.The controller then sends a message to the controller. peripheral device, indicating a request for reading in blocks The peripheral device responds with a read response in blocks and OSD data, this is repeated until the entire menu is transferred to the controller, alternative methods to transfer an OSD menu are defined below. From a peripheral device to a visual control display device, an asynchronous push method, which primarily uses IEEE-1394 asynchronous write transactions, can be used by the peripheral device to write the OSD data to the controller. approach allows a peripheral device to write the contents of its menu in a n controller device. Because the menus are expected to be larger than the MTU (Maximum Transfer Unit) of the busbar, a fragmentation header can be added. The transport layer of the menu should add this header. On the receiving side, this layer reassembles the menu, and passes it to the upper layers. A possible fragmentation header is defined later. The fragmentation header is a quadlet, and contains a sequence number and the source of the fragment.

No Sequence of Fragments Source of Fragment (2) bytes (node_id) (2 bytes) Other methods can be used to fragment and reassemble OSD data, while transferring, using an asynchronous push methodology. An isochronous transport method provides the transmission of the OSD data over one of the isochronous channels provided by the IEEE-1394. It would be necessary to reserve bandwidth, and to maintain as long as the peripheral is being controlled using the OSD. It would also be possible that there was not enough bandwidth to reserve the channel. This could create a situation where the user could not get the feedback he requires.

An Asynchronous Current method would be similar to the Isochronous Current method, with the exception that it would use an Asynchronous Current to carry the OSD information. An Asynchronous Current is essentially the same as an Isochronic Current, with the exception that there is no bandwidth reservation, and the current is sent in the asynchronous portion of the bus cycle. During the operation through the direct link, a peripheral device simply receives inputs from its RC unit or from the front panel, and performs the corresponding actions. However, there is a slight complication when, as a result of these actions, it is assumed that an OSD is generated in a visual display device. Because it is in this case, the actions of the peripheral device were initiated through its own direct link, and the peripheral device has no knowledge on which node of the network to display its OSD. (The peripheral device builds the OSD data), ie, OSD blocks defined by a header), and stores them in its memory area. Therefore, a device that detects the start of control through its direct link, you can send OSD info messages to each device with OSD capability (that is, devices that have implemented the visual display object on the screen). It corresponds to the application of the visual display device to say whether to act on this message or not. For example, if the focus on that visual display device has been given to VCR1, and it receives an OSD info message from VCR1, it is quite natural for the visual display device to act on it. If the visual display device does not focus on the particular device, the user may be alerted to the presence of a visual display request OSD by a remote unit, but may choose to ignore it depending on the OSD_data_type in the received OSD_info message. Because the actual control is through the direct link, it has absolutely no effect on the peripheral device if any or multiple visual display devices choose to display the OSD. On the other hand, this mechanism can also be used to inform the user of the error conditions, warnings, etc., that the user may or may not want to have displayed at that time. Accordingly, the OSD_info message includes a field for OSD data type, to indicate whether the OSD data presented to the visual display device is of a warning message, an error message, normal OSD data, and so on. The OSD data can also be in a descriptive form, such as HTML. However, for the purposes of this invention, HTML would be used only to describe the way in which the OSD would look. HTML would not be used to control, as it does for the Internet. After a trigger message is received from a peripheral device, the OSD module of the visual display device requests memory accesses starting at the memory location of the trigger message. At this point, the OSD Module reads Block 1 of the OSD. The data is received using IEEE-1394 read commands, and transferred to the visual display memory area on the visual display device. These data are then stored in the internal memory of the visual display device, in the format required by the OSD controller of the visual display device. The discovery process allows the control device to discover other devices in the network. This process is activated by means of a busbar reset, and it is used to search and discover the existing devices in the network. It can cause a reset of the busbar by connecting / disconnecting a device, reset initiated by the software, and so on. This software module relies on some information stored in each device configuration ROM. This information is referred to as a Self-Description Device (SDD), and contains information such as Model Number, Menu Location, URL, EUI Vendor ID, and so on. The SDDT of a visual / controller display contains a pointer to a block of information containing information about the visual display capabilities of the device. The information block can include the type of visual display (interlaced or progressive), the maximum bytes per line, true color capacity, the resolution modes supported (full, 1/2, 1/3), maximum supported bits / pixels for palette mode (2, 4, 8), and so on. Other discovery methods can also be used to obtain this information, such as the Home Pin, and Play, as defined for CAL, or the subunit descriptors defined for AV / C. After the initialization of the bus is finished, the discovery manager reads the SDD located in the ROM of each connected device. This information is constructed in a record table. Each device in the IEEE-1394 serial bus will have a log table that will be used to keep track of other devices in the bus and their capabilities. For all devices in the busbar, this device record (log table) will be constantly updated in the discovery process in the busbar resets. The registry provides services to the application to map the volatile characteristics, node_ID of the IEEE-1394, address, and so on, to a non-volatile identification scheme used by the application. The application uses the non-volatile 64-bit EUI (Extended Unique Identifier) to identify any node in the IEEE-1394 serial bus. Regristro services are used to map this 64-bit EUI to the volatile IEEE-1394 node_ID or IP. The "Registration" module is a system service module. The "Registry" system module allows communication between the nodes inside the home network, abstracting their location within the home network. The registry table is maintained by the registry administrator inside each device, and contains the information for each node, in order to provide the previously specified service. This log table is constantly updated by the discovery manager in the busbar resets. Each row of the Record Table can be as follows: EUI of 64 ID_node Address Manufacturer / No. Type of bits 1394 Model IP Device The fields in the Record Table are defined as: • 64-bit EUI is a 64-bit number that uniquely identifies a node among all nodes in the Series Busbar manufactured in all the world. 1 quadlet = 32 bits- • ID_node 1394 is a 16-bit number that identifies a serial bus node within a 1394 subnetwork from a single node. The 10 most significant bits are the identification of the bus, and the least significant bits are the identification physical. The identification of the busbar uniquely identifies a particular busbar inside a group of bridged busbars. Physical identification is assigned dynamically during the self-identification process. • Address P is a 32-bit private IP address assigned dynamically. • Manufacturer / No. Model is obtained from the SDDT of the device, and is used to inform the customer of the possibilities to select a source.

• Type of Device is also obtained from the SDDT of the device, and is used to inform the client of the possibilities to select a source. This field can also be useful to determine which current format should be used. For example, a gaming machine can not use MPEG 2 as an output format. The application can use the registry to determine the address of the IEEE-1394 for any node in the home network, based on the 64-bit EUI of that node. The record will be constructed during the discovery process, after a busbar reset. The correlation with a stable identifier, such as the EUI, is important, because the node addresses can change during a busbar reset. Although the invention has been described in detail with respect to numerous modalities thereof, it can be seen that, after a reading and understanding of the foregoing, experts in the field will think of numerous alterations to the described modality, and it is intended to include these alterations within the scope of the appended claims.

Claims (12)

1. A consumer electronic peripheral device, which comprises: (a) an element for communicating with a digital visual display device interconnected by a digital bus bar; (b) an element for providing digital video content; (c) an element for generating, in the peripheral device, digital OSD data representative of a screen display menu associated with that peripheral device, the digital data being capable of being displayed; and (d) an element for transferring the digital video content and the digital OSD data capable of being displayed, by means of the digital bus bar, to the visual display device.

The peripheral device of claim 1, wherein the transfer element comprises an element for writing, by means of the digital bus bar, the digital data, in a memory device associated with this visual display device.

3. The peripheral device of claim 2, which further comprises an element for navigating the menu in response to a command initiated by the user, the navigation element generating updated digital data in response to the command initiated by the user, and writing this digital data updated in the memory device, controlling the command initiated by the user the operating modes of that peripheral device.

The peripheral device of claim 1, which further comprises a mapping element for identifying the connectivity of the peripheral device with other devices in the digital bus bar.

The peripheral device of claim 4, which further comprises an element for receiving the feature information of each connected device in the digital bus bar.

6. The peripheral device of claim 1, which further comprises an element for processing video data.

7. A method for controlling an electronic peripheral device of the consumer interconnected by means of an IEEE-1394 serial bus with a visual display device, which comprises: (a) receiving, in the visual display device, digital video content from the peripheral device, using an isochronic transfer mechanism of the bus in series; (b) generating, in the peripheral device, digital data representative of a display menu on the screen associated with the peripheral device, this digital data being able to be displayed; (c) transferring the digital data, by means of the bus in series, to the visual display device, using an asynchronous transfer mechanism of the bus in series; and (d) combining, in the visual display device, digital video content and digital data.

The method of claim 7, further comprising the steps of: (a) receiving the control information in response to a command initiated by the user, controlling this control information the operating modes of the peripheral device; (b) navigating the menu of the peripheral device in response to the control information, wherein the step of navigating comprises updating the digital data; and (c) transferring the updated digital data to the visual display device.

9. A method for controlling an electronic consumer peripheral device interconnected by means of an IEEE-1394 serial bus bar to a visual display device, which comprises: (a) mapping the connectivity of each device in the bus in series; (b) communicate with the visual display device, using an asynchronous transfer mechanism of the bus in series; (c) generating, in the peripheral device, digital data representative of a visual display display menu associated with the peripheral device; and (d) providing the visual display device with a first message indicating the availability of the digital data, this first message comprising the location and size of the digital data in a memory device associated with the peripheral device.

The method of claim 9, further comprising the steps of: (a) receiving the control information in response to a command initiated by the user, controlling this control information the operating modes of the peripheral device; (b) navigating the menu of the peripheral device, in response to the control information, wherein the navigation step comprises updating the digital data; (c) providing the visual display device with a second message comprising the location and size of the updated digital data; and (d) transferring the updated digital data to the memory device.

11. The method of claim 7, wherein the step of transferring the digital data by means of the bus in series, uses an isochronic transfer mechanism of the bus in series.

12. A visual display device, which comprises: (a) an element for communicating with a peripheral device interconnected by a digital bus bar; (b) an element for receiving digital video content; (c) an element for receiving, from the peripheral device, digital data representative of a menu of visual screen display associated with the peripheral device, these digital data being capable of being displayed; (d) an element to superimpose and display the digital data on the digital video content.