2. BACKGROUND OF THE INVENTION A variety of technologies have been developed that allow for the connection of various AV and Information Technology (IT) devices. For example, in a typical home, a consumer may have a TeleVision (TV), Personal Computer (PC), and a variety of other AV and IT devices. The consumer can use various technologies, such as serial and parallel connections, and various protocols (proprietary or open standard), to allow for the communication and interoperability between such devices.

For example, an electronic device can be connected to an electronic network in a user's home to allow for communication and interoperability of various computing and consumer electronic devices. The electronic network can connect a variety of devices, such as a PC, Digital

Versatile Disk (DVD) device, digital Set-Top Box (STB), Digital TV (DTV), various home appliance devices, and a variety of other AV and IT devices.

Increasing device capabilities that enable a device to perform advanced functionality can provide additional advantages, but this can also increase hardware storage and processing requirements in order to control and manage the various devices connected to the network. For example, the control of a target device by a control device can be implemented by allowing the control device to upload static information (e. g., control information including the functionality of the target device) from the target device.

SUMMARY OF THE INVENTION However, there is a need for devices that are connected to home or business networks to not only describe static information to be displayed to the user, but to augment the user experience by allowing a set of actions to be carried out by the device (or several devices) when that information is manipulated by the user.

For example, in the HAVi (Home Audio Video) version 0.8 standard (see www. HAVi. org), the model of a Device Control Module (DCM) as an uploadable, executable Java applet is defined. The DCM can be embedded in a device, as part of its Self-Describing Data (SDD). However, the SDD model requires the uploading device to have a JAVA Virtual Machine (VM) that can execute the JAVA applet.

HAVi also defines the Data Driven Interface (DDI). The DDI allows for the description of merely static information to be displayed to the user.

Accordingly, in one embodiment, Dynamic Self- Describing Data (DSDD) provides an extension of the Self- Describing Data (SDD) mechanism described in HAVi (e. g., the HAVi version 0.8 standard), which is more cost and performance efficient than the JAVA virtual machine model of HAVi. In particular, DSDD provides for a device that can include not only descriptive information for static display, but also can include sets of commands or scripts (e. g., DSDD scripts) that can be executed when a particular DSDD data element is manipulated by the user.

For example, DSDD can be used as an extension to HAVi.

DSDD can also be used for networking of AV or IT devices generally and is not limited to HAVi-based networks.

Various communication protocols or networking protocols can be used, such as IEEE 1394, AV/C, or a variety of other technologies.

Accordingly, this embodiment allows DSDD to be realized in HAVi-based or non-HAVi-based devices simply by agreement on commands and data structures, as well as decision making logic, without the need for, for example, a JAVA VM. As a result, the device (s) executing the DSDD actions require less hardware storage and processing, and less software (e. g., a JAVA VM). Thus, this reduces the cost of making such controlling devices, while still

providing a fairly rich user experience. Moreover, this embodiment provides for, for example, the following: the ability to link the execution of several scripts to a single command (where a script is a set of DSDD commands and data); the ability for these linked scripts to exist in a distributed environment (e. g., the scripts need not all be stored within the same device) and to be retrieved as needed during execution; the ability to explicitly support multiple device control languages (e. g., AV/C and CAL) in a script, in addition to"native"DSDD commands, by encoding which command protocol is used in the command structure; enabling the"blind"support of multiple device control languages by encoding the characteristics of non- DSDD command protocols into the DSDD command structures, including, for example, split transaction templates and command time out values; the ability for a script to include commands that affect multiple devices, not just a single device; the ability for scripts to be updated or "pre-flighted"before execution, so that the scripts can be tailored to the exact environment in which the scripts will run (e. g., scripts do not have to be permanent or hard-coded); and the ability to associate an icon (e. g., sound and name with a DSDD script), to assist with the creation of a user interface that allows the user to see, hear, or otherwise access the script functionality.

In one embodiment, a method for execution of DSDD script commands on target destinations is provided. In

this embodiment, a control device executes (e. g., interprets) DSDD scripts and sends DSDD commands to the appropriate target device for execution. In one embodiment, the control device that is sending the DSDD commands transmits the DSDD commands to the appropriate target device (e. g., a 1394 node including bus address information for multi-bus 1394 networks). Once the target device receives the DSDD command, the target device can then parse the structure and determine how it should be routed and handled internally.

This embodiment also allows the DSDD control device to be independent of any command protocols that can be transmitted within DSDD command tokens (e. g., AV/C or HAVi commands). In particular, if a particular DSDD script includes a set of HAVi commands that are sent to a particular target device, then the target device should support (e. g., be able to interpret or execute) the DSDD commands in addition to the HAVi commands. This embodiment advantageously supports future compatibility: control devices that upload and execute a DSDD scripts do not have to know anything about the command sets that can be embedded within a DSDD script. As a result, a current DSDD control device can upload future DSDD scripts and still execute them to completion even if the future DSDD scripts include new command sets, which are unknown to the DSDD control device.

In one embodiment, the DSDD command protocol can be used to package and deliver"non-DSDD"commands, such as HAVi or AV/C commands. This embodiment can also be used to expose only command addressing information for, for example, AV/C, CAL, HAVi, or possibly any other command protocols, and encourage DSDD devices to deliver those commands in their native formats (e. g., not embedded in DSDD command frames). This embodiment can be used to allow the above command protocols to also be delivered in DSDD command frames (e. g., if the target device supports both AV/C and the DSDD protocol, then it should be prepared to accept an AV/C command either in the native AV/C command delivery mechanism or inside of a DSDD command delivery packet). This embodiment can also be advantageously used for future devices that implement future protocols to support DSDD for the delivery of their new protocols.

In one embodiment, a DSDD control device exposes specific addressing information and, thus, the control device executes or interprets the command protocol (e. g., HAVi or AV/C) of the embedded DSDD commands in order to send that command to the appropriate target device. In this embodiment, the DSDD script provides a container or a wrapper for a different command protocol, and the control device should support that command protocol, as well as the addressing model of that command protocol, in order to deliver the command to the target device.

Thus, this embodiment exposes the DSDD command and its addressing information. This embodiment advantageously allows for backward compatibility with existing devices and protocols. For example, this embodiment can be used to allow a DSDD script to expose, for example, AV/C, CAL, and HAVi addressing information for a particular command, and to require or recommend that DSDD-compliant devices support these particular command protocols. Accordingly, this would allow a DSDD script to control legacy devices (i. e., those devices that do not understand the DSDD protocol), but it would also limit the burden of DSDD controllers to, for example, just these existing protocols (and not require them to explicitly support future protocols).

Other aspects and advantages of the present invention will become apparent from the following detailed description and accompanying drawings.

BRIEF DESCRIPTION OF THE DRAWINGS FIG. 1 is a block diagram for one embodiment of a network, in accordance with one embodiment of the present invention; FIG. 2 is a block diagram for one embodiment of an exemplary device from FIG. 1, in accordance with the present invention; FIG. 3 is a memory map for one embodiment of the memory of FIG. 2, in accordance with the present invention;

FIG. 4 illustrates standard DSDD user actions in accordance with one embodiment of the present invention; FIG. 5 provides a table that illustrates the DSDD command tokens and their associated parameters in accordance with one embodiment of the present invention; FIG. 6 provides a table that illustrates the DSDD data tokens and their associated data in accordance with one embodiment of the present invention; FIG. 7 is a diagram that illustrates the general format of a DSDD script in accordance with one embodiment of the present invention; FIG. 8 provides a table that illustrates attributes in accordance with one embodiment of the present invention; FIG. 9 provides a diagram of an FCP frame used by the DSDD protocol in accordance with one embodiment of the present invention; FIG. 10 illustrates the structure of DSDD commands in accordance with one embodiment of the present invention; FIG. 11 provides a diagram of the response frame in accordance with one embodiment of the present invention; FIG. 12 provides a model diagram of delivering HAVi commands in DSDD command frames in accordance with one embodiment of the present invention; FIG. 13 provides a flow diagram illustrating the stages of operation of DSDD script execution in accordance with one embodiment of the present invention.

FIG. 14 provides a flow diagram that illustrates the stages of operation of the DSDD protocol that a control device executes in order to locate and present DSDD data to the user, and to execute the associated DSDD scripts, in accordance with one embodiment of the present invention; and FIG. 15 provides an example DSDD script in accordance with one embodiment of the present invention.

DETAILED DESCRIPTION OF THE INVENTION The present invention relates to an improvement in network and device control technology. The following description is presented to enable one of ordinary skill in the art to make and use the invention and is provided in the context of a patent application and its requirements.

Various modifications to the preferred embodiment will be readily apparent to those skilled in the art and the generic principles herein may be applied to other embodiments. Thus, the present invention is not intended to be limited to the embodiments shown, but is to be accorded the widest scope consistent with the principles and features described herein.

In accordance with one embodiment of the present invention, Dynamic Self Describing Data (DSDD) is a mechanism that allows devices to embed commands and data structures that can be extracted by other devices,

and used to create a user interface for the manipulation and control of those devices via control devices. In one embodiment, the devices can include references (e. g., to remote locations such as a URL on the Internet) where the commands and data structures can be found. A device can also include commands, data structures, and a reference to a remote location. Devices that contain this information, or which are the recipients of commands, are referred to as target devices. Devices that use this information to let the user control target devices are referred to as control devices.

In one embodiment, DSDD provides a more efficient protocol than other protocols, such as the HAVi Level 1/Level 2 user interface models. Rather than defining a full featured user interface environment, DSDD defines a limited number of commands and data structures that are used for interoperability among devices from different vendors. For example, DSDD allows a target device to encode several proprietary commands that are sent to the target device by the control device when the user manipulates some user interface elements. For such purposes, it is not necessary to define an elaborate set of functions (e. g., Application Program Interfaces (APIs)), such as would be created for disks, tuners, VCR's, and other types of IT or AV devices.

Referring now to FIG. 1, a block diagram for one embodiment of an electronic network 110 is shown, in

accordance with one embodiment of the present invention. In the FIG. 1 embodiment, network 110 includes, but is not limited to, device A 112, device B 114, device C 116, and device D 118. In other embodiments, network 110 can readily be implemented using a higher or fewer number of devices than the four devices (device A 112 through device D 118) shown in the FIG. 1 embodiment.

In the FIG. 1 network 110, device A 112, device B 114, device C 116, and device D 118 communicate with each other through a commonly-shared network bus 120. In one embodiment, network bus 120 is implemented according to the IEEE 1394 interconnectivity standard. However, a variety of other interconnectivity standards (e. g., other Local Area Network (LAN) standards (cable-based or wireless) or bus protocol standards) can also be implemented in conjunction with the present invention.

In one embodiment, network 110 is configured to operate in accordance with the Home Audio/Video Interoperability (HAVi) core specification (e. g., HAVi Specification version 1.0 beta, released November 19,1998 via www. HAVi. org), which is hereby incorporated by reference in its entirety.

Therefore, device A 112, device B 114, device C 116, and device D 118 can be implemented as various types of Consumer Electronics (CE), Information Technology (IT), or home appliance devices, including, but not limited to, PCs, DVD devices, TV sets, audio reproduction systems, Video Cassette Recorders (VCRs), and STBs for digital video broadcasting.

However, in various other embodiments, network 110 can be implemented as any appropriate electronic network configured to permit communication between any desired types of electronic devices.

Referring now to FIG. 2, a block diagram for one embodiment of an exemplary device 112 from FIG. 1 is shown, in accordance with one embodiment of the present invention.

In the FIG. 2 embodiment, device 112 includes, but is not limited to, a processor 212, an input/output interface (I/O) 214, and a memory 216 that are each in communication with, and communicate with each other via, a common device bus 218.

In the FIG. 2 embodiment, device 112 is configured to represent a control device (e. g., in the HAVi extension embodiment, either a full AV device or an intermediate AV device, as referred to in the HAVi Specification version l. OB).

In the FIG. 2 embodiment, processor 212 can be implemented to include any appropriate and compatible generic, multi-purpose microprocessor device. The FIG. 2 input/output interface (I/O) 214 provides an interface to facilitate communications between device 112 and network bus 120 (FIG. 1). In the FIG. 2 embodiment, memory 216 can be implemented to include any combination of desired storage devices, including, but not limited to, Read-Only Memory (ROM), Random-Access Memory (RAM), and various types of non- volatile memory, such as floppy disks or hard disks. The

contents and functionality of memory 216 are further discussed below.

Referring now to FIG. 3, an illustrative memory map for one embodiment of FIG. 2 memory 216 is shown, in accordance with one embodiment of the present invention. In the FIG. 3 embodiment, memory 216 includes one or more device applications 312, a network Application Program Interface (API) 314, network software 316, Dynamic Self-Describing Data (DSDD) 320 (e. g., uploaded from a target device), a device driver 318, a platform-specific API 322, and a vendor- specific platform 324. In other embodiments, memory 216 can include various components and elements that are different from, or in addition to, those software components and elements 312 through 324 discussed in conjunction with the FIG. 3 embodiment.

In the FIG. 3 embodiment, device application 312 includes software instructions that are executed (e. g., executed or interpreted) by processor 212 (FIG. 2) to effectively manage and control the functionality of device 112. Network API 314 serves as an interface between various elements of network software 316 and device application 312.

In the FIG. 3 embodiment, network, software 316 includes one or more software elements that are executed by processor 212 to advantageously permit device 112 to communicate and interoperate with other devices in communication with network 110.

In the FIG. 3 embodiment, Dynamic Self-Describing Data (DSDD) 320 includes various types of relevant information regarding a target device that can be controlled via device 112. The DSDD specification of the information included in DSDD 320, in accordance with one embodiment of the present invention, is discussed in greater detail below. Device driver 318 includes appropriate software instructions that enable device 112 to communicate with network bus 120 (FIG.

1).

In the FIG. 3 embodiment, platform-specific API 322 provides an interface that enables network software 316 to communicate with vendor-specific platform 324. In the FIG. 3 embodiment, vendor-specific platform 324 can include basic operating system software for supporting low-level operations of device 112.

The FIG. 3 embodiment of memory 216 corresponds to a control device (e. g., a full AV device or an intermediate AV device in the HAVi extension embodiment, as discussed above in conjunction with FIG. 1) that includes network software 316 to enable compatibility and functionality with network 110. In contrast, a target device (e. g., a base AV device in the HAVi extension embodiment, as discussed above in conjunction with FIG. 1) is hosted on network 110 by a control device (e. g., a full AV device or an intermediate AV device in the HAVi extension embodiment), and therefore typically does not include network software 316. However, in

one embodiment, a target device includes DSDD 320 and a device driver 318.

A legacy device (LD) can be defined as a device that does not comply with the architectural specifications of network 110 and network software 316. Legacy devices typically were designed and manufactured prior to the design and implementation of network 110 and network software 316.

Therefore, a legacy device is preferably hosted on network 110 by a control device, and typically does not include network software 316 or DSDD 320.

DSDD Specification In one embodiment, the DSDD specification includes the definition of the following: (1) a set of DSDD user actions; (2) a set of DSDD commands (referred to as "command tokens") ; (3) a set of DSDD data structures (referred to as"data tokens"); (4) a DSDD script structure to provide a script (e. g., a program) of DSDD commands and associated data; (5) a script execution model; and (6) a command packaging and delivery protocol between control devices and target devices. In one embodiment, the DSDD data corresponding to the DSDD specification can be stored in memory 216 (FIG. 2), in which the DSDD data is uploaded from a target device, the DSDD data being stored in a memory (e. g., a configuration ROM) of the target device in order to allow control

devices to control the target device using the DSDD protocol.

DSDD User Actions Referring now to FIG. 4, FIG. 4 illustrates standard DSDD user actions in accordance with one embodiment of the present invention. In the FIG. 4 embodiment, the DSDD protocol defines a set of user actions that are used by the control device (the one with which the user is interacting, and that is executing the DSDD scripts). The user actions are the"point of embarkation", or the means of triggering the execution of a DSDD script.

In the FIG. 4 embodiment, the control device extracts DSDD scripts and related data from target devices and constructs a Graphical User Interface (GUI) (e. g., displaying appropriate DSDD GUI elements). The user interacts with the GUI via the control mechanism supported by the control device (e. g., a remote control, laser pointer, mouse, or keyboard). When the user performs one of the DSDD-defined user actions on a DSDD GUI element, a script is triggered.

DSDD Script Command and Data Tokens Referring now to FIG. 5, FIG. 5 provides a table that illustrates the DSDD command tokens and their associated parameters in accordance with one embodiment of the

present invention. The commands included in a DSDD script can either be DSDD command tokens; standard commands as defined by a particular protocol, such as the AV/C VCR command set; or vendor-specific commands (i. e., vendor- specific according to the DSDD protocol).

In one embodiment, a script includes a single vendor- specific command associated with each of the defined DSDD user actions (e. g., user actions include actions like clicking a button or turning a dial). When the target device receives that vendor-specific command, the target device takes over and can then execute any number of internally-defined operations. When the target device complets the execution of internally-defined operations, the target device sends a completion signal to the control device, and the script execution is finished.

In one embodiment, as part of its internal operations, the target device can send commands back to the control device for various purposes, such as updating the graphic display to keep the user informed of the status of the operation. This kind of interaction from the target device back to the control device can be implemented using a standard set of DSDD commands and data, as the operations involve more than just a target device carrying out a proprietary action.

In the FIG. 5 embodiment, the DSDD protocol defines some command tokens that a control device processes when they are found in a script that it is executing. An

example of such a token would be the signal to load and execute another script, which advantageously enables the execution of any number of linked scripts.

In the FIG. 5 embodiment, DSDD-defined tokens are two-byte values; some of which represent instructions to be followed by the control device while executing the script, and others represent standardized data that will be found in the following bytes.

Referring now to FIG. 6, FIG. 6 provides a table that illustrates the DSDD data tokens and their associated data in accordance with one embodiment of the present invention.

Additional Embodiments It should be apparent that the set of command tokens and data types can easily be expanded or otherwise modified. This includes a richer set of command and data tokens in the protocol (e. g., timers or graphics), and various GUI-related tokens, such as start and stop animation, play sound, and draw background or image.

Also, additional user actions (e. g., drag and drop, or triple click) can also be defined.

DSDD Script Structure Referring now to FIG. 7, FIG. 7 is a diagram that illustrates the general format of a DSDD script in

accordance with one embodiment of the present invention.

In this embodiment, a DSDD script is a data structure that contains a set of commands and parameters. Some of the DSDD commands require a simple decision making or flow- control, branching mechanism, which enables the control device to determine how to react to the results of commands as part of the DSDD script execution.

In particular, the FIG. 7 diagram illustrates the general format of a DSDD script. The column labeled "Address"shows the location, in bytes, of each field from the beginning of the script, which indicates that it is the offset address. When the address column contains" :" characters, it means that the exact address values depend upon the implementation and involve variable numbers of fields. As a result, specific values are not shown in the diagram. In the fields of the diagram, text that is drawn sideways is informative, and describes the collection of data fields to its right. Note that some collections of fields are indented below other fields; this is intended to show a hierarchical relationship, where the indented fields are related to the field (s) above them in a defined manner.

Timeout-Value This value represents the amount of time that the target device has to return a response to a command. If no response is returned within this time, the control

device may re-try or abandon script execution. Each bit represents 2 milliseconds.

Split-Response-Code If the specified command supports a split response, then this field contains the value that will be returned in the error-code field of the initial response frame.

When the controller receives a response frame, it examines error-code to determine if this is the initial or final response. If the command does not support a split response, the value in this field shall be set to $FF. In the error-code definitions, $FF must be allocated for "split-response". In one embodiment, the timeout value indicates the timeout for an initial response only, but it is not a final response (which could take many minutes to complete).

In the FIG. 7 embodiment, the script ID field represents a unique ID value for this script, assigned by the target device from which the script was obtained. In order to ensure uniqueness in the case that multiple devices and scripts are being used at any given time, the control device associates the target device ID with the script ID. For example, in the IEEE 1394 architecture, the device ID used for this purpose can be the phy ID (i. e., a temporary value assigned after each bus reset), or the global unique ID (i. e., a fixed, world-wide unique value for each 1394 device).

Referring now to FIG. 8, FIG. 8 provides a table that illustrates the currently defined attributes in accordance with one embodiment of the present invention. In particular, the script-attributes field represents the attributes field, which specifies a variety of attributes for the DSDD script (e. g., each bit in the field specifies whether the attribute exists or not). As illustrated in FIG. 8, the attributes field is 2 bytes; the first byte includes basic attributes, such as"needs validation", and the second byte includes bit flags for each of the supported native command protocols such as AV/C or HAVi.

Referring now to FIG. 7, the script name token is a DSDD data token that indicates that the following bytes contain the name of this script. The script name data that follows the token is arranged as a 2-byte length value, followed by the name bytes. The length value indicates the number of bytes that follow for the name data. In one embodiment, the name data bytes are arranged according to the IEEE 1212/1212r format for textual descriptors. Accordingly, this allows the name to be in several different languages if desired. If there is no name assigned to the script, then the token still exists but the length field is set to 0 (i. e., no data bytes for the name). The number of user actions field specifies the number of defined user actions supported by this DSDD element. Examples of actions include"select"and"drag".

The action token x is an action token specified for each

supported action. Following the action token is the data that specifies each command to execute in response to that action. The number of commands field indicates that for each action, some number of commands can be specified.

Each command is a structure as shown in the diagram. The number of commands field indicates how many of these command structures follow for this user action. The command x opcode field provides the opcode for a given command. The number of bytes used for this field is 2 + the number of bytes needed for the native command protocol. The first two bytes specify the DSDD command token, if this command is a DSDD command. If not, then the command is a"native"protocol command, and that opcode is specified in the remaining bytes. In one embodiment, when the command is a DSDD token, then the native command byte (s) are set to FF16 ; when the command is in a native protocol, then the DSDD command bytes are set to FF16.

For example, AV/C command opcodes are one byte, so a script that contains AV/C commands (and possibly DSDD command tokens) would use 3 bytes for this field. If the control device does not understand the native command language as specified in the attributes, then it should not attempt to parse the script, because it would not know how many bytes to allow for the command x fields. If the script contains commands from more than one native protocol (such as AV/C and HAVi), then ALL of the command

opcode fields will be"2 + largest size"bytes in length.

In this case, the largest number of bytes required for a given protocol will determine the size. When native commands are encoded with less than the full number of bytes, the coding is from low address to high address.

In the FIG. 7 embodiment, the command x parameters length field specifies the number of bytes used for the command parameters that follow. The command-x parameters field provides the parameters for the command. Generally, the control device would not need to understand the parameters; it just packages them up into a command frame and sends them to the target device. The sizeofresultx field indicates the number of bytes to expect for the result of the operation. The control device must allocate enough of its internal script execution stack space (or other result storage area) to accommodate the result. The number of expected results x field indicates the number of expected result values that follow. Depending on the command, several possible return values can be defined. The DSDD command set includes a compare and branch operation, allowing the script to specify what to do for each of the possible results.

However, in one embodiment, the control device is responsible for doing its own compare of the ACTUAL return result against all of the valid possibilities, and handling an unexpected return result by itself. The expectedresultsforcommandx field provides an array of

values that are considered"successful"results. The DSDD script execution model operates on the presumption of success, with exceptions handled as needed.

DSDD Command Frame Delivery In one embodiment, a DSDD command can also have addressing information associated with it. If present, the addressing information specifies where to send the command (e. g., which 1394 node address). In one embodiment, if the address is absent, then the control device is to execute the command. Some commands can have "implicit"addresses associated with them, such as the validate script command, which is sent to the device from which the script was uploaded.

FIG. 9 provides a diagram of an FCP frame used by the DSDD protocol in accordance with one embodiment of the present invention. In particular, the DSDD protocol, as well as both AV/C and HAVi, use the Function Control Protocol (FCP) format, which is contained within IEEE 1394 asynchronous bus packets, for command delivery.

Accordingly, in one embodiment, it is the responsibility of the execution device to construct the IEEE 1394 asynchronous bus packet. The execution device uses the IEEE 1394 node address for the destination device as the destination ID field and its own IEEE 1394 address as the source ID. The destination offset field is set to FFFF

F000 OB0016, which is the FCP command address within an IEEE 1394 node. The remainder of the serial bus packet fields are coded according to the IEEE 1394 protocol. In particular, FIG. 9 illustrates an IEEE 1394 serial bus asynchronous packet, with a payload that consists of an FCP frame.

In one embodiment, the format within the FCP frame depends on the value of the Command Transaction Set (CTS) code, which is 4 bits. The values for AV/C and HAVi are documented in the AV/C and HAVi specifications, respectively. For example, an appropriate standards body can assign a suitable value for the DSDD protocol. If the command delivery protocol being used were not FCP, then the area within the serial bus asynchronous packet shown as the"FCP frame"would be used for the appropriate structure, as specified by the protocol.

DSDD Command Frame Construction Referring now to FIG. 10, FIG. 10 illustrates the structure of DSDD commands in accordance with one embodiment of the present invention. In particular, the DSDD command tokens found in a script are either executed by the control device or sent to a target device for execution. These command tokens allow the script to specify the stages of operation followed by the control device as it carries out the script instructions.

In the FIG. 10 embodiment, there are some DSDD tokens that involve only local execution by the control device, and there are some DSDD tokens that require the control device to issue a command to the target device as part of the token execution. For example, the validate script token requires the control device to allow the target device to validate the script and update any missing commands or parameters. In response, the target device needs to return the updated script data. For example, for these purposes, a DSDD command protocol that can be carried in FCP frames across 1394 is defined.

As shown in FIG. 10, the DSDD command structure is similar to AV/C command frames, but unlike AV/C command frames, there is no need for subunit addressing information. In one embodiment, DSDD commands are addressed to an IEEE 1394 node, via the FCP delivery protocol. The IEEE 1394 node takes care of handling the DSDD commands and returning results. The internal unit architecture is not necessarily critical for the DSDD protocol, because, in this embodiment, DSDD commands are administrative in nature and do not deal with functionality, such as VCR or tuner mechanisms.

In the FIG. 10 embodiment, depending on the unit architecture implementation, the data [n] parameters can include internal addressing information, but this is completely transparent to the control device that is sending the command frames to the target device (s).

Another difference is that the DSDD command frame contains a transaction ID field, which is a dynamically assigned ID value for this command. The control device (optionally) can serialize ID values for each of the commands it sends out. The target devices that receive these commands may or may not execute these commands sequentially (e. g., this would depend on the nature of the command and the target device implementation). When the target device sends back the response frame, it includes this transaction-ID field.

The control device can then match up the response (and which target device came from) with its internal list of outstanding commands, so that it can deal with it appropriately. In the absence of this field, the control device may not know which command was coming back, in case it happens to send more than one of the same command to the same device. Yet another difference is that command opcodes are 2 bytes in size, as opposed to 1 byte for AV/C opcodes. The result frame that is returned from a command has the same general structure, but the data [x] bytes are replaced by the error-code (1 byte) and the result data (x bytes up to the maximum FCP frame of 512 bytes).

In one embodiment, the command opcode in a DSDD command frame is the same as the DSDD token value that the control device finds in the script. The difference between "tokens"and"commands"defined by DSDD is that tokens are handled locally on the control device, and commands are sent to the target device for processing. The DSDD

command protocol is also more efficient than others are, such as HAVi or AV/C. For example, the control device sends a DSDD command to the target device, and some kind of response is returned, such as an error code or result data. In the event that a command causes data to be generated that is larger than the FCP frame can handle (e. g., 512 bytes), then other means of extracting the results can be used. For example, when a target device is given the chance to validate a script, the resulting script may be much larger than 512 bytes. The return result from the validate script command would be a result code (which can indicate success) and the ID of the , script. The control device then goes back and reads the specified script from the target device, which is now validated and ready to execute.

DSDD Response Frame Construction Referring now to FIG. 11, FIG. 11 provides a diagram of the response frame in accordance with one embodiment of the present invention. After receiving and executing a command, the target device constructs a response frame for sending the results back to the control device.

As shown in FIG. 11, the first few fields of the response frame (up through the opcode-high field) are the same as the command frame. However, all of the input parameters (shown as data [n] in the command frame diagram)

are replaced by the error_code, and the resulting results data (shown by results [n] in the diagram above). The exact values for these fields will of course depend on the command and the defined behavior for each command/errorcode combination.

Non-DSDD Command Frame Construction and Delivery As described previously, it is possible for a DSDD script to contain commands that are from different command protocols, such as AV/C or HAVi. For example, there are two basic approaches to command delivery: 1) deliver all of the DSDD commands to the target node, and let the logic -in the device figure out how to take care of internal routing and command handling; or 2) expose protocol- specific messaging in the DSDD command frames and require the DSDD controller to use the native protocol delivery mechanism (this is a mixed-mode solution).

AV/C Command Frame Construction and Delivery In one embodiment, for AV/C commands, the DSDD command structure includes the full AV/C command frame, including the target subunit type and ID. The executing device need not determine this information, because it is hard-coded in the data that is extracted from the target device. In one embodiment, an AV/C command is carried in the"FCP data"field of the FCP frame, as discussed above.

For AV/C commands whose parameters are not known in advance, the DSDD protocol includes a script validation step to allow the target device to provide the parameters and zero pad bytes at run time (as described below). In both cases, the target device can also hard code the CTS code in the command frame, because this information is typically the same for the given command protocol (e. g., AV/C or HAVi).

In one embodiment, the delivery of the AV/C command includes the control device delivering the DSDD command frame (which contains the AV/C command frame) to the node specified in the DSDD command frame structure (as discussed above). For example, in one embodiment, when an IEEE 1394 node receives the DSDD command frame, it will strip off the outer layers of the command frame to access the AV/C command frame hidden inside. The IEEE 1394 node will then decode the AV/C command and handle it appropriately. Finally, the IEEE 1394 node will respond with a DSDD response frame.

Note that when a script contains AV/C commands (or any other non-DSDD command), they will generally be commands that cause something to happen, such as a"PLAY" command to trigger a VCR playback. The results will generally be"successful"or"failure"and will be delivered in a DSDD response frame. The purpose, of course, is that the control device is only delivering "black boxes"to the target device, and those black boxes

happen to contain AV/C commands. The control device is not specifically issuing AV/C commands that it expects to return with results that need to be analyzed (such as a READ DESCRIPTOR command).

HAVi Command Frame Construction and Delivery FIG. 12 provides a model diagram of delivering HAVi commands in DSDD command frames in accordance with one embodiment of the present invention. As shown in FIG. 12, the target device that is hosting a HAVi implementation dynamically fabricates and exposes a configuration ROM that contains the DSDD scripts to be uploaded and executed by control devices. The control device analyzes all nodes (e. g., IEEE 1394 nodes) on the bus and finds these scripts as it would find scripts in any other device.

In the FIG. 12 embodiment, the scripts include either DSDD-specific command tokens, HAVi messages, or both. The DSDD control device need not be HAVi-savvy, because it only needs to handle DSDD script execution.

In the FIG. 12 embodiment, the control device sends the DSDD commands to the device from which the script was uploaded. The device parses the DSDD command frame, extracts the HAVi message, and delivers it to the Device Control Module (DCM). In this manner, the HAVi software executing in the target device needs no knowledge of the DSDD protocol, only the device that is hosting the HAVi components needs to be DSDD-aware.

In the FIG. 12 embodiment, the HAVi messages are packed into the DSDD command frame in the data [n] fields, as shown in FIG. 10.

DSDD Script Execution This section describes some of the details of how a DSDD script is executed, including support for non-DSDD protocols.

Split Response Indicator In one embodiment, a split transaction model is provided, in which commands can invoke more than one response (e. g., an initial response of INTERIM and a later response of FINAL). For example, the DSDD script includes command frames, and each command frame includes a split response indicator, if appropriate, that tells the DSDD control device how the split response model is to be executed. This advantageously allows the DSDD control device to deal with split responses of non-DSDD protocols, without requiring the DSDD control device to have protocol-specific knowledge.

In particular, the split response indicator indicates to the DSDD controller the number of responses that can be returned for a given command, the possible non-final (e. g., INTERIM) response codes, and the FINAL response code. When the DSDD controller receives response frames

from a target device, it can then compare the response codes with the split response template to determine where it is in the overall command processing cycle.

Command Time Out Values Different command protocols have different command time out values. Accordingly, in one embodiment, the controlling device uses these to determine when to time out (e. g., give up on waiting for a response from the target device uses a time out). The time out can also be used as a baseline measurement that specifies, for example, some kind of result, even if it is an INTERIM response, must be returned within the time out value.

In particular, in one embodiment, the DSDD script structure also contains time out values, where appropriate, for commands of non-DSDD protocols. The DSDD protocol also defines its own time out value of, for example, 200 milliseconds (this value is the same as the AV/C protocol time out value, but the value is arbitrary and can be selected to be any appropriate or application- specific value). The command time out template in the DSDD script structure also indicates what to do in case a time out occurs (e. g., show the user an error message, or ignore the command and move on to the next one).

DSDD Script Validation In one embodiment, DSDD scripts include sets of commands that are well defined, including the parameters to use in the command frames. However, for those situations in which the command parameters are not known in advance, the target device is given a chance to validate the parameters before the commands are executed, in accordance with one embodiment of the present invention.

For example, an AV/C tuner subunit, which supports one of the tuning commands (e. g., either DIRECT SELECT INFORMATION TYPE or OBJECT NUMBER SELECT), can present the situation in which the command parameters are not known in advance. In particular, at any given moment, depending on a variety of factors, an SDD data element can be intended to result in the tuning and output of a specific item from the broadcast signal or an arbitrary item from the broadcast signal. The parameters for these commands will vary, based on the specific data that can be found in the broadcast signal. Because this data can vary from time to time, or in different geographic locations, it is generally not possible to hard code this information at the time the device is manufactured.

A script that is intended to make use of more than just the target device from which it was loaded represents another example of the situation in which the parameters

of a command are not known in advance. Because all possible network configurations may not be known in advance, it may be necessary to analyze the network to determine what devices and capabilities exist, and then adjust the script commands and parameters based on these results.

In accordance with one embodiment, to satisfy these types of problems, the protocol for DSDD includes a validation operation in the protocol. In particular, the script data structure includes a set of attributes, including a"needs validation"attribute. If this attribute is true, then the control device offers the target device an opportunity to validate the parameters for later use. Script validation is then achieved by having the control device send a"validate script"command to the target device, specifying which script to validate.

In typical situations, there is no need to also send the script along with the command, because the target device already has the script (e. g., the script was uploaded from that device). In response, the target device updates any variable parameters and then returns the updated script to the control device. If the script was obtained from a remote location (e. g., an Internet address), the script is sent to the device associated with that script (e. g., the device that contains the remote addressing information for the script). The target device is then responsible for the validation activity. In

another embodiment, the"validatescript"command is sent to the remote Internet address, and an updated script is returned.

DSDD Script Execution FIG. 13 provides a flow diagram illustrating the stages of operation of the DSDD script execution in accordance with one embodiment of the present invention.

At stage 1302, the control device interacts with the user, and determines what user action (if any) has occurred. At stage 1304, the control device begins executing the commands corresponding to that action. At stage 1305, the control device obtains the next step (e. g., a command or token) from the script. At stage 1306, the control device determines whether the next step is a token or a command.

At stage 1307 (i. e., the next step is a command), the DSDD commands are sent to the target device (e. g., legacy support is also discussed above). At stage 1308 (the next step is a token), the control device executes DSDD command tokens. At stage 1310, if no error occurs, then each native protocol command (e. g., embedded within DSDD commands) is executed on the target device. At stage 1312, whether an error has occurred is determined. If so, then at stage 1314, the control device stops executing the DSDD script. At stage 1316, the control device loads and executes the specified error handling script (if one is specified). If the script does not specify an error

handler, the control device may optionally do something to handle the error, such as inform the user, or simply stop execution of the DSDD script and do nothing. If there is no error, then whether another step is to be executed is determined at stage 1313. If so, processing returns to stage 1305. If not, then at stage 1318, after the error handling script is finished (or no error occurs), the DSDD script execution is complete.

In one embodiment, the stages of operation of DSDD script execution include the control device parsing the DSDD script structure and then sending each of the specified native protocol commands to the target device (e. g., this advantageously allows the target device to not need to know how to interpret or execute DSDD commands).

In another embodiment, the stages of operation of DSDD script execution can also include features such as the following: exception handling, in which unexpected results trigger actions ; the ability to send commands to more than one device from the same script; linked scripts, in which the execution of one script involves the loading and execution of other scripts. These features can be implemented by using the DSDD script, command, and data token structures, as discussed above, in accordance with one embodiment of the present invention.

The Overall DSDD Protocol FIG. 14 provides a flow diagram that illustrates the stages of operation of the overall DSDD protocol that a control device executes in order to locate and present DSDD data to the user, and to execute the associated DSDD scripts, in accordance with one embodiment of the present invention. In particular, at stage 1402, the control device (s) search the network to find all target devices that contain DSDD information. At stage 1404, the control device (s) present these target devices to the user, or depending on the specific control device implementation, can autonomously decide which target device (s) to use in subsequent stages of operation. At stage 1406, when a target device is selected, the control device extracts the DSDD information from the target device. At stage 1408, the control device then prepares for execution and presents the menu of DSDD options from the target device to the user (e. g., the control device can construct an appropriate GUI). At stage 1410, whether a DSDD script needs to be validated is determined. If so, then, at stage 1412, the DSDD script is validated, for example, before being displayed (e. g., as a GUI element (s)) to the user (because the validation could fail, and it may be more user friendly to just keep invalid features hidden from the user if they will not be available). In one embodiment, the control device can also add a mechanism

that allows the user to go back to stages 1402 or 1404 (e. g., depending on the design and implementation of the control device), or to bail out of this DSDD protocol execution altogether. At stage 1414, when the user manipulates a DSDD element, the control device executes the appropriate script (see FIG. 13 and accompanying description above).

Example Scenario As an example of an application of DSDD, consider a VCR that includes a set of timed recording operations, which can be specified by the user. The VCR has a feature that allows the user to enable or disable any given recording operation. If an operation is disabled, then the data for that operation stays resident in the VCR so that it can be easily re-enabled, instead of forcing the user to enter the data again.

In particular, an example list of recording actions that the user can set up is provided below: Action 1-SIMPSONS, Sundays at 8: 00 PM on channel 2 (currently disabled by the user because the World Series game pre-empts the Simpsons).

Action 2-KING OF THE HILL, Tuesdays at 8: 00 PM on channel 2 (enabled).

Action 3-Movie: The Ghost and Mr. Chicken, Thursday at 9: 00 PM on channel 7 (enabled).

In one embodiment, each recording action corresponds to a DSDD element provided by the VCR. The control device (e. g., TV or STB) extracts the DSDD data and constructs an appropriate user interface. Using the input mechanism of the control device, the user moves the focus to action 1 and presses"select". The DSDD script associated with this item is executed, which sends, for example, a proprietary, vendor-specific DSDD command to the VCR, which it interprets as a command to enable the item. The VCR then sends a DSDD command back to the control device, with the necessary information to cause the GUI to be updated to reflect the change (e. g., the icon changes from a"disabled"to an"enabled"sign of some sort). This is the end of the DSDD script, and the control device goes back to the GUI screen with the list of recording actions.

The user can change another one, or can exit the DSDD for the VCR and go back to watching television.

In particular, FIG. 15 provides an example DSDD script for execution of action 1 of the above example, in accordance with one embodiment of the present invention.

Although particular embodiments of the present invention have been shown and described, it will be apparent to those of ordinary skill in the art that changes and modifications can be made without departing from the present invention in its broader aspects. For example, a variety of programming languages, techniques,

and formats can be used to implement the disclosed techniques for the DSDD protocol in accordance with the teachings of the present invention. Also, the present invention can be used with a variety of network architectures or protocols, such as HAVi or AV/C. In particular, some variations to the overall DSDD specification as herein disclosed can include, for example, the following: modifications to data structures or command frames; the definition of new command or data tokens to enhance the functionality that is defined herein; the use of command transport protocols other than FCP to deliver DSDD commands between devices; the . specification of DSDD"command targeting"information that is finer in scope than just the unit architecture of the target device (e. g., a command is addressed to a specific "internal"function within the target device, not just to the 1394 node); and the use of DSDD on networks other than 1394 (with appropriate addressing and other protocol changes). Therefore, the pending claims are to encompass within their scope all such changes and modifications that fall within the true scope of the present invention.