WO2001020426A2

WO2001020426A2 - Methodology for discovering extended capabilities of devices in an electronic network

Info

Publication number: WO2001020426A2
Application number: PCT/US2000/025150
Authority: WO
Inventors: Rodger J. Lea
Original assignee: Sony Electronics Inc.
Priority date: 1999-09-16
Filing date: 2000-09-13
Publication date: 2001-03-22
Also published as: WO2001020426A3; AU7484600A

Abstract

A methodology for discovering extended capabilities of devices (112) in an electronic network (110) comprises a registry (412) that is configured to include one or more extended attributes (614) that each correspond to a different extended capability of a device (112) in the electronic network (110). A software module (312), such as an application program, may then access a particular extended attribute (614) to discover an extended application program interface (326) for effectively communicating with the extended capability of the device (112) in the electronic network (110).

Description

METHODOLOGY FOR DISCOVERING EXTENDED CAPABILITIES OF DEVICES IN AN ELECTRONIC NETWORK

CROSS-REFERENCE TO RELATED APPLICATIONS

This application relates to co-pending U.S. Patent Application No.

09/259,504, entitled "System And Method For Incrementally Updating

Remote Element Lists In An Electronic Network," filed on February 26, 1999, to co-pending U.S. Patent Application No. 09/257,344, entitled "System And Method For Implementing Active Registries In An Electronic Network," filed on February 25, 1999, and to co-pending U.S. Patent Application No. 09/289,500, entitled "System And Method For Maintaining Fully-Replicated Registries In An Electronic Network," filed on April 9, 1999, which are hereby incorporated by reference. The foregoing cross-referenced applications are commonly assigned.

BACKGROUND OF THE INVENTION

1. Field of the Invention

This invention relates generally to electronic networks, and relates more particularly to a methodology for discovering extended capabilities of devices in an electronic network.

2. Description of the Background Art

Implementing an effective method for utilizing extended capabilities of electronic devices within an electronic network is a significant consideration for manufacturers and designers of contemporary electronic systems. An electronic device in a distributed electronic network may advantageously communicate with other remote electronic devices in the network to share and substantially increase the resources available to individual devices in the network. For example, an electronic network may be implemented in a user's home to enable flexible and beneficial sharing of resources between various consumer electronic devices, such as personal computers, digital video disk devices, digital set-top boxes for digital broadcasting, television sets, and audio playback systems.

Managing and controlling a network of electronic devices may create substantial challenges for designers of electronic networks. For example, enhanced demands for increased functionality and performance may require more system processing power and require additional hardware resources across the network. An increase in processing or hardware requirements may also result in a corresponding detrimental economic impact due to increased production costs and operational inefficiencies. Furthermore, efficiently accessing the increased functionality may pose certain problems.

Network size is also a factor that affects the control and management of an electronic network. Communications in an electronic network typically become more complex as the number of individual devices or nodes increases. Assume that a particular device on an electronic network is defined as a local device with local software elements, and other devices on the electronic network are defined as remote devices with remote software elements. Accordingly, a local software module on the local device may need to communicate with various remote software elements on remote devices across the electronic network. However, successfully managing a substantial number of electronic devices across a single network may provide significant benefits to a system user. Furthermore, enhanced device capability to perform various advanced functions may provide additional benefits to a system user, but may also place increased demands on the control and management of the various devices in the electronic network. For example, an enhanced electronic network that effectively accesses, processes, and displays digital television programming may benefit from efficient network management techniques because of the large amount and complexity of the digital data involved. In addition, the presence of electronic devices with extended capabilities and functionality may present a need for creating efficient techniques to allow discovery of the extended capabilities by various software elements in the network. For example, if an enhanced video cassette recorder (VCR) with extended capabilities is added to the network, then the other software elements in the network may require information about the existence and capabilities of the newly-added VCR, so that all software elements in the network may advantageously utilize the extended capabilities of the newly- added software device. Therefore, for all the foregoing reasons, implementing an efficient method for utilizing extended capabilities of electronic devices in a distributed electronic network remains a significant consideration for designers, manufacturers, and users of electronic systems.

SUMMARY OF THE INVENTION

In accordance with the present invention, a methodology is disclosed for discovering extended capabilities of devices in an electronic network. In one embodiment of the invention, initially, a DCM manager (416) preferably performs a device discovery process for devices that are added to the electronic network by querying various relevant configuration information that is preferably stored in self-describing data of the added devices. In accordance with the present invention, the DCM manager (416) may discover relevant extended capability information for the added devices during the foregoing device discovery process.

The DCM manager (416) then preferably instantiates a new device control module (DCM) for controlling an added device on the electronic network. The DCM manager (416) also preferably creates a DCM registration to register the new DCM into a local registry. The DCM registration may advantageously include one or more extended API attributes (EAAs) that each correspond to different extended capabilities of an added device on the electronic network.

Subsequently, in accordance with the present invention, whenever a software module (such as an application program) requires a particular extended API to access a given extended capability of a target device, the software module may then propagate a query to the local registry for locating the appropriate DCM registration that corresponds to the target device. In some embodiments, the registry may similarly broadcast the query to other remote registries across the electronic network in the event that the initial query to the local registry is unsuccessful.

If the foregoing query successfully locates an appropriate DCM registration, then the registry returns a corresponding DCM software element identifier to the software module that originated the query process. The software module may then access and scan a DCM attribute list from the DCM registration to locate an appropriate extended API attribute (EAA), in accordance with the present invention. The software module may then preferably access and parse the extended API attribute to identify the corresponding extended API. Finally, the software module may responsively build a request call using relevant information from the extended API attribute, and may then send the request call to the target device's DCM through the extended API using any appropriate and compatible messaging protocol.

The foregoing embodiment is discussed in the context of a single local software module discovering a single extended API, however the present invention may readily be utilized to allow any number of software modules across the electronic network to discover and utilize any number of local or remote extended APIs on various devices across the network. The present invention thus effectively facilitates discovery of extended capabilities of devices across the electronic network.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a block diagram for one embodiment of an electronic network, in accordance with 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 diagram for one embodiment of the memory of FIG. 2, in accordance with the present invention;

FIG. 4 is a diagram for one embodiment of the network software of FIG. 3, in accordance with the present invention;

FIG. 5 is a diagram for one embodiment of the registry of FIG. 4, in accordance with the present invention;

FIG. 6 is a diagram for one embodiment of the DCM attribute list of FIG. 5, in accordance with the present invention;

FIG. 7 is a diagram for one embodiment of the extended API attributes of FIG. 6, in accordance with the present invention;

FIG. 8 is a diagram for one embodiment of an exemplary extended API attribute from FIG. 7, in accordance with the present invention;

FIG. 9 is a diagram for one embodiment of an exemplary method signature from FIG. 7, in accordance with the present invention; FIG. 10 is a flowchart of method steps for registering a DCM of an added device, in accordance with one embodiment of the present invention; and

FIG. 11 is a flowchart of method steps for discovering extended APIs to access extended capabilities of a device, in accordance with one embodiment of the present invention.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENT

The present invention relates to an improvement in electronic network 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 embodiment shown, but is to be accorded the widest scope consistent with the principles and features described herein.

The present invention comprises a methodology for discovering extended capabilities of devices in an electronic network, and preferably includes a registry that is configured to include one or more extended attributes that each correspond to a different extended capability of a device on the electronic network. A software module, such as an application program, may then advantageously access a particular extended attribute to thereby discover an appropriate extended application program interface for effectively communicating with the extended capability of the device on the electronic network.

Referring now to FIG. 1 , a block diagram for one embodiment of an electronic network 1 10 is shown, in accordance with the present invention. In the FIG. 1 embodiment, network 1 10 includes, but is not limited to, device A 1 12(a), device B 1 12(b), device C 1 12(c), and device D 1 12(d). In other embodiments, network 1 10 may readily be implemented using a larger or smaller number of devices than the four devices (device A 112(a) through device D 112(d)) shown in the FIG. 1 embodiment.

In the FIG. 1 network 110, device A 1 12(a), device B 1 12(b), device C 112(c), and device D 1 12(d) preferably communicate with each other through a commonly- shared network bus 120. In the FIG. 1 embodiment, network bus 120 is preferably implemented according to the IEEE 1394 interconnectivity standard. However, in alternate embodiments, other appropriate and compatible interconnectivity standards are also contemplated for use in conjunction with the present invention. In the FIG. 1 embodiment, network 1 10 may preferably be configured to operate in accordance with the Home Audio/Video Interoperability (HAVi) core specification (version 1.0 beta, at www.HAVi.org) which is hereby incorporated by reference. Therefore, device A 1 12(a), device B 1 12(b), device C 1 12(c), and device D 1 12(d) may be implemented as various types of consumer electronics devices, including, but not limited to, personal computers, digital video disk devices, television sets, audio reproduction systems, video tape recorders (VCRs), and set- top boxes for digital video broadcasting. However, in various alternate embodiments, network 1 10 may readily be implemented as any appropriate electronic network configured to permit communication between any desired types of electronic devices.

In the FIG. 1 embodiment, the various electronic devices that form part of network 1 10 preferably include the following four categories of electronic devices: full devices (FD), intermediate devices (ID), base devices (BD), and legacy devices (LD). The foregoing four categories of electronic devices (FD, ID, BD, and LD) are further discussed below in conjunction with FIGS. 2 and 3. In alternate embodiments of the present invention, network 1 10 may readily include various other categories of electronic devices in addition to, or instead of, the four categories of FD, ID, BD, and LD.

Referring now to FIG. 2, a block diagram for one embodiment of an exemplary device 1 12 from FIG. 1 is shown, in accordance with the present invention. In the FIG. 2 embodiment, device 1 12 preferably includes, but is not limited to, a processor 212, an input/output interface (I/O) 214, and a memory 216 that are each coupled to, and communicate with each other via, a common device bus 218. In the FIG. 2 embodiment, device 1 12 is preferably configured to represent either a full device or an intermediate device, as referred to above in the discussion of the FIG. 1 network 1 10. In the FIG. 2 embodiment, processor 212 may be implemented to include any appropriate and compatible generic, multi-purpose microprocessor device. The FIG. 2 input/ output interface (I/O) 214 preferably provides an effective interface to facilitate communications between device 112 and network bus 120 (FIG. 1). In the FIG. 2 embodiment, memory 216 may 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 in conjunction with FIGS. 3 and 4. In accordance with the present invention, the FIG. 2 device 112 may include extended capabilities and functionality not typically found in similar devices. For example, in one embodiment, device 1 12 may be implemented as a video cassette recorder (VCR) that includes a non-standard half-speed fast forward capability.

Referring now to FIG. 3, a diagram for one embodiment of FIG. 2 memory 216 is shown, in accordance with 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, self- describing data (SDD) 320, a device driver 318, a platform- specific application program interface (API) 322, a vendor- specific platform 324, and one or more extended application program interface(s) (extended APIs) 326. In alternate embodiments, memory 216 may readily include various components and elements that are different from, or in addition to, those software components 312 through 324 discussed in conjunction with the FIG. 3 embodiment.

In the FIG. 3 embodiment, device application 312 preferably includes software instructions that are executed by processor 212 (FIG. 2) to effectively manage and control the functionality of device 1 12. Network API 314 preferably serves as an interface between various elements of network software 316 and device application 312. In the FIG. 3 embodiment, network software 316 preferably includes one or more software elements that are executed by processor 212 to advantageously permit device 112 to communicate and cooperate with other devices in network 110. The contents and functionality of network software 316 are further discussed below in conjunction with FIG. 4.

Self-describing data (SDD) 320 preferably includes various types of relevant information regarding device 112. For example, SDD 320 may include information specifying the manufacturer, model, version, serial number, and other fixed data that specifically corresponds to device 1 12. Device driver 318 preferably includes appropriate software instructions that permit device 1 12 to communicate with network bus 120 (FIG. 1).

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

The FIG. 3 embodiment of memory 216 typically corresponds to a full device (or FD, as discussed above in conjunction with FIG. 1) that preferably includes a complete set of network software 316 to permit optimal compatibility and functionality with network 1 10. Alternately, memory 216 may correspond to an intermediate device (ID) which includes only a reduced set of software elements from network software 316. In contrast, a base device (BD) is preferably hosted on network 1 10 by a full device or an intermediate device, and therefore typically does not include network software 316. A base device, however, preferably does include self-describing data 320 and a device driver 318.

A legacy device (LD) may be defined as a device that does not comply with the architectural specifications of network 1 10 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 1 10 by a full device or an intermediate device, and typically does not include network software 316 or self-describing data 320. A digital base device, however, may include a device driver 318 for interfacing with network bus 120. Full devices, intermediate devices, base devices, and legacy devices are further discussed in the Home Audio/Video Interoperability (HAVi) core specification (see pages 3 through 22) that has been previously incorporated by reference.

In accordance with the present invention, extended application program interface(s) (extended APIs) 326 preferably include application program interfaces that permit applications 312 or software elements from network software 316 to communicate (for example, by appropriate calls or messages) with a DCM 422 to thereby access and control extended capabilities of a corresponding device 1 12 on network 1 10. Techniques for discovering extended APIs 326 by applications 312 or network software 316 are further discussed below in conjunction with FIGS. 6 through 1 1.

Referring now to FIG. 4, a diagram for one embodiment of the network software 316 of FIG. 3 is shown, in accordance with the present invention. In the FIG. 4 embodiment, network software 316 preferably comprises a number of software elements, including a registry 412, an event manager 414, a device control module (DCM) manager 416, a stream manager 418, a resource manager 420, one or more device control modules (DCMs) 422 and one or more corresponding functional control modules (FCMs) 423, a messaging system 424, and a communication media manager (CMM) 426.

In the FIG. 4 embodiment, software elements 412 through 426 are preferably configured to function in accordance with the Home Audio /Video Interoperability (HAVi) architecture which has previously been incorporated herein by reference. However, in alternate embodiments, network software 316 may readily conform to any other appropriate and compatible interoperability architecture, and may also include various software elements that are different from, or in addition to, those elements 412 through 426 that are presented in the FIG. 4 embodiment.

In the FIG. 4 embodiment, registry 412 may preferably include a listing of software elements in network software 316. Registry 412 also preferably may include relevant element information or attributes corresponding to the listed software elements. For example, elements 412 through 426 from network software 316 and corresponding element information may be listed in registry 412. Registry 412 therefore may serve as a directory service for applications 312 or software elements in network 1 10. Registry 412 may thus allow any application or software element to obtain a software element identifier (SEID) for identifying and locating another software element in network 1 10. In accordance with the present invention, registry 412 may also include a remote registry list that identifies all remote registries on network 1 10.

In the FIG. 4 embodiment, event manager 414 preferably serves as a network-event notification service to notify various software elements (that have previously subscribed for notification) about the occurrence of a specified network event, such as a change in a software element or a change in network 1 10. DCM manager 416 is preferably responsible for installing and removing DCMs 422 on full devices or intermediate devices. Stream manager 418 is preferably responsible for managing real-time transfer of data and other information between various functional components of network 1 10. In the FIG. 4 embodiment, resource manager 420 preferably facilitates the sharing of various resources and scheduling of various actions in network 1 10. A device control module (DCM) 422 preferably includes a software element that is used to control a specific associated device on network 1 10. A given DCM 422 preferably includes one or more directly-corresponding functional control modules (FCMs) 423 that each control a specific functional component within the particular device 1 12 that corresponds to the FCM 423. A full device or an intermediate device may preferably host a DCM 422 to control a remote base device or a remote legacy device on network 1 10. In the FIG. 4 embodiment, messaging system 424 is preferably responsible for bi-directionally transferring various messages between the software elements of network software 316. Communication media manager (CMM) 426 coordinates and manages asynchronous and isochronous communications through device driver 318 onto network bus 120.

Network software 316 preferably performs a number of significant and related operations whenever a particular device is removed from, or added to, network 1 10. When a device is added or removed from network 1 10, then network bus 120 preferably triggers a bus reset event which notifies all connected devices about the change in network 1 10. Following the bus reset event, all DCM managers 416 in network 1 10 preferably perform a negotiation procedure to determine which, if any, DCM manager 416 is the most appropriate host for controlling the newly-added device 112. Each DCM manager 416 in network 110 may therefore maintain a current list of all devices in network 1 10. Once a given DCM manager 416 is selected as host, that host DCM manager 416 responsively instantiates a new DCM 422 as an abstraction of the control interface of the newly-added device. Network software 316 preferably also updates relevant software element information in registry 412 whenever a device is removed from, or added to, network 110.

Referring now to FIG. 5, a diagram for one embodiment of the FIG. 4 registry 412 is shown, in accordance with the present invention. In the FIG. 5 embodiment, registry 412 preferably includes an element registration 1 (512(a)) through an element registration N (512(d)), and a DCM registration 512(e). Each FIG. 5 element registration 512(a) through 512 (d) preferably corresponds to a local software element in local device 1 12. For example, any one of element registration 512(a) through 512 (d) may uniquely correspond to an associated software element from network software 316 (FIG. 4).

In the FIG. 5 embodiment, each element registration 512(a) through 512 (d) preferably includes a software element identifier (SEID) and a corresponding attribute list. Therefore, element registration 1 (512(a)) through element registration N (512 (d)) each preferably include a corresponding respective SEID 1 (514(a)) through SEID N (514(d)), and a associated respective attribute list 1 (516(a)) through attribute list N (516(d)). In alternate embodiments, registry 412 may readily be configured to include various components in addition to, or instead of, those shown in the FIG. 5 embodiment.

In the FIG. 5 embodiment, each SEID 1 (514(a)) through SEID N (514(d)) preferably includes a global unique identifier (GUID) and a software element local handle (SELH) that are used to uniquely identify a specific software element in network 110. Attribute list 1 (516(a)) through attribute list N (516(d)) preferably each include relevant information corresponding to the associated software element. For example, such relevant information may include, but is not limited to, an element manufacturer, an element model, a version level, and various other element features.

In the FIG. 5 embodiment, registry 412 may advantageously be utilized during communications between various software elements (including applications 312) in network 1 10. In order to send a message to a target element in network 110, a source element (such as an application 312) preferably identifies the target element by using the corresponding SEID 514 of that target element. In network 1 10, the source element preferably obtains the correct SEID 514 of the target element by accessing, from registry 412, the appropriate element registration 512 that uniquely corresponds to the target element. Once a source element locates an SEID 514 for a target element using any appropriate examination technique, then the source element may use the located SEID 514 to communicate with the corresponding target element via messaging system 424 (FIG. 4). For example, an application 312 may send a message via an extended API 326 to a DCM 422 of a VCR device 1 12 to thereby control an extended capability such as a half- speed fast forward function.

In accordance with the present invention, DCM registration 512(e) preferably corresponds to a DCM 422 for a device 1 12 that includes capabilities that may be classified into an extended category of capabilities. In the FIG. 5 embodiment, DCM registration 512(e) preferably includes a DCM SEID 514(e) and a corresponding DCM attribute list 516(e). In alternate embodiments, DCM registration 512(e) may readily be configured to include various components in addition to, or instead of those shown in the FIG. 5 embodiment.

In the FIG. 5 embodiment, DCM SEID 514(e) preferably includes a global unique identifier (GUID) and a software element local handle (SELH) that are used to uniquely identify a specific software element in network 1 10. DCM attribute list 516(e) preferably includes relevant information corresponding to the associated DCM 422. DCM attribute list 516(e) is further discussed below in conjunction with FIGS. 6 through 1 1.

Referring now to FIG. 6, a diagram for one embodiment of the FIG. 5

DCM attribute list 516 is shown, in accordance with the present invention. In the FIG. 6 embodiment, DCM attribute list 516 includes, but is not limited to, standard attributes 612 and extended API attribute(s) (EAAs) 614.

Standard attributes 612 preferably include items that relate to basic characteristics or functions of the particular device that corresponds to DCM attribute list 516. For example, if the device is a VCR, then standard attributes 612 may include information identifying device as a VCR, as well as other relevant information such as manufacturer, model, and version level. In the FIG. 6 embodiment, EAA(s) 614 preferably include one or more special, non-standard attributes that correspond to extended capabilities or functionality of the corresponding device on network 1 10. The configuration and utilization of EAA(s) 614 are further discussed below in conjunction with FIGS. 7 through 1 1.

Referring now to FIG. 7, a diagram for one embodiment of the FIG. 6 extended API attribute(s) (EAAs) 614 is shown, in accordance with the present invention. In the FIG. 7 embodiment, EAA(s) 614 may comprise any number of separate and discrete EAA(s) 614. For example, FIG. 7 includes an EAA 1 (614(a) through an EAA N (614(c). In alternate embodiment, EAA(s) 614 may likewise be readily configured using any other effective and appropriate manner. Referring now to FIG. 8, a diagram for one embodiment of an exemplary FIG. 7 extended API attribute (EAA) 614 is shown, in accordance with the present invention. In one embodiment of the present invention, EAA 614 is preferably formatted as a tuple that encodes relevant information as a series of textual strings. In the FIG. 8 embodiment, EAA 614 preferably includes, but is not limited to, a method identifier (ID) 812 and a method signature 814.

In the FIG. 8 embodiment, EAA 614 may effectively be encoded using Interface Definition Language (IDL) which is designed to capture abstract interface APIs using a Common Object Request Broker Architecture (CORBA). Concepts and techniques relating to IDL and CORBA are discussed in "Client/ Server Programming with Java and CORBA," by Robert Orfali and Dan Harkey, Wiley Computer Publishing, 1998, which is hereby incorporated by reference. In alternate embodiments, any or all portions of EAA 614 may readily be encoded using any other appropriate formats or languages. In the FIG. 8 embodiment, method ID 812 preferably includes an identifier that uniquely corresponds to a particular extended API 326. Similarly, method signature 814 preferably includes encoded signature information corresponding to the particular extended API 326. One configuration for method signature 814 is further discussed below in conjunction with FIG. 9. In alternate embodiments, EAA 614 may readily comprise various other information that is different from, or in addition to the information discussed above in conjunction with the FIG. 8 embodiment.

Referring now to FIG. 9, a diagram for one embodiment of a FIG. 7 exemplary method signature 814 is shown, in accordance with the present invention. In the FIG. 9 embodiment, method signature 814 preferably comprises, but is not limited to, a method string 912 and a set of parameters that preferable include a parameter name 914 and a parameter type 916. However, in alternate embodiments, method signature 814 may readily be configured to include any other appropriate information. In the FIG. 9 embodiment, method string 912 preferably includes a textual string describing a method corresponding to a given extended API 326. For example, in the case of a VCR with an extended API 326 for a half- speed fast forward function, the method string 912 may include the string "half-speed fast forward". In the FIG. 9 embodiment, parameter name 914 preferably includes a textual string describing a given parameter for the corresponding extended API 326. For example, in the case of a VCR with a half- speed fast forward function, the parameter name 914 may include the string "speed". In the FIG. 9 embodiment, parameter type 916 preferably includes a textual string describing a specific type for the parameter identified by parameter name 914. For example, in the case of a VCR with a half-speed fast forward function, the parameter type 916 may include the string "integer". In alternate embodiments, method signature 814 may readily be configured to include various other information in addition to, or instead of the information discussed above in conjunction with the FIG. 9 embodiment.

Referring now to FIG. 10, a flowchart of method steps for registering a

DCM 422 of an added device is shown, in accordance with one embodiment of the present invention. In the FIG. 10 embodiment, in step 1010, network software 216 monitors network 1 10 to determine whether a system user has recently connected an added device to network 1 10.

If a system user has connected an added device to network 110, then, in step 1012, network 1 10 preferably generates a bus reset event to notify interested devices 112 about the presence of the added device. In step 1014,

DCM manager 416 of network software 316 preferably performs a device discovery process for the added device.

In the FIG. 10 embodiment, DCM manager 416 preferably performs the foregoing device discovery process by querying various relevant configuration information stored in- self-describing data (SDD) 320 (FIG. 3). In accordance with the present invention, DCM manager 416 may also concurrently discover relevant extended capability information relating to the added device during the foregoing device discovery process. For example, SDD 320 may include various types of extended capability information for creating one or more extended API attributes (EAAs) 614.

In step 1016, DCM manager 416 preferably locally instantiates a new DCM 422 for controlling the added device on network 1 10, as discussed above in conjunction with FIG. 4. Finally, in step 1018, DCM manager 416 creates a DCM registration 512(e) (FIG. 5) to register the new DCM 422 into local registry 412. In accordance with the present invention, the DCM registration 512(e) created in step 1018 may include one or more extended API attribute(s) (EAAs) 614 corresponding to various extended capabilities of the added device that was connected to network 1 10 in foregoing step 1010.

Referring now to FIG. 1 1 , a flowchart of method steps for discovering extended APIs 326 is shown, in accordance with one embodiment of the present invention. In the FIG. 1 1 embodiment, in step 1 110, a local software module (such as application 312 or any other software element in network 110) determines whether an extended API 326 is required to access a given extended capability of a target device that is represented by a locally-hosted DCM 422. For example, in one embodiment, an application 312 may wish to communicate with given DCM 422 to thereby control an extended half-speed fast forward function of a VCR on network 1 10.

If an extended API 326 is required, then, in step 1 1 12, the local software module creates and propagates a query to local registry 412 to locate the DCM registration 512(e) corresponding to the target device on network 1 10. In some embodiments, registry 412 may broadcast the query to other remote registries 412 across network 1 10 in the event that the initial query to local registry 412 is unsuccessful.

In step 11 14, registry 412 determines whether the foregoing query of step 11 12 has been successful in locating the desired DCM registration 512(e). If the query is not successful, then, in step 1 126, registry 412 returns a failure message to the local software module that originated the query. However, if the query of step 11 12 successfully locates the appropriate DCM registration 512(e), then, in step 1 1 16, registry 412 returns the corresponding DCM SEID 514(e) to the local software module that originated the query.

In step 1 1 18, the local software module of step 1 1 10 may then access the entire DCM attribute list 516(e) corresponding to the target device with the desired extended capability. Next, in step 1 120, the local software module of step 1 1 10 may advantageously scan the DCM attribute list 516(e) to locate the desired extended API attribute (EAA) 614, in accordance with the present invention. In step 1 122, the local software module of step 1 1 10 may then access and parse the extended API attribute 614 to identify the corresponding extended API 326. Finally, in step 1 124, the local software module of step 1 1 10 may responsively build a request call using information from the extended API attribute 326, and may then send the request call to DCM 422 through the identified extended API 326 using any appropriate and compatible messaging protocol. For example, in one embodiment, the request call of step 1 124 may include information such as the DCM SEID 514(e), method ID 812, parameter name 914, and parameter type 916.

The foregoing discussion of the FIG. 1 1 embodiment is presented in the context of a single local software module discovering a single extended API 326, however the present invention may readily be utilized to allow any number of software modules across network 1 10 to discover and utilize any number of local or remote extended APIs 326 on various devices across network 1 10.

The invention has been explained above with reference to a preferred embodiment. Other embodiments will be apparent to those skilled in the art in light of this disclosure. For example, the present invention may readily be implemented using configurations and techniques other than those described in the preferred embodiment above. Additionally, the present invention may effectively be used in conjunction with systems other than the one described above as the preferred embodiment. Therefore, these and other variations upon the preferred embodiments are intended to be covered by the present invention, which is limited only by the appended claims.

Claims

WHAT IS CLAIMED IS:

1. A system for discovering an extended capability of a device (1 12) in an electronic network (1 10), comprising: a registry (412) configured to include an extended attribute (614) corresponding to said extended capability; and a software module (312) configured to utilize said extended attribute (614) for accessing said extended capability of said device ( 1 12).

2. The system of claim 1 wherein said software module (312) is a device application that communicates with said device (1 12) on said electronic network (1 10).

3. The system of claim 1 wherein said registry (412) forms part of network software (316) for said electronic network (1 10).

4. The system of claim 3 wherein said network software (316) is configured to comply with a home audio-video interoperability specification.

5. The system of claim 1 wherein said electronic network (1 10) is connected through a network bus ( 120) configured using an IEEE 1394 interconnectivity standard.

6. The system of claim 1 wherein a manager element encodes said extended attribute (614) in an attribute list (516(e)) within a module registration (512(e)) to thereby include extended API information in said extended attribute (614), and wherein said software module (312) responsively utilizes said extended API information to discover and use an extended API (326) for controlling said extended capability through a device control module (422).

7. The system of claim 1 wherein a DCM manager (416) performs a device discovery procedure following a connection of said device (1 12) to said electronic network (110), said DCM manager (416) examining self-describing data (320) in said device (1 12) to learn about said extended capabilities during said device discovery procedure.

8. The system of claim 7 wherein said DCM manager (416) instantiates a device control module (422) to control said device ( 1 12) on said electronic network (110).

9. The system of claim 8 wherein said DCM manager (416) creates a DCM registration (512(e)) in said registry (412), said DCM registration (512(e)) including a DCM software element registration (514(e)) and a DCM attribute list (516(e)).

10. The system of claim 9 wherein said DCM attribute list (516(e)) includes standard attributes (612) and said extended attribute (614).

1 1. The system of claim 10 wherein said extended attribute (614) comprises extended API information that is obtained by said DCM manager (416) during said device discovery procedure, said extended API information being encoded as a textual string to include a method ID (812) corresponding to an extended API (326), and a method signature (814) also corresponding to said extended API (326).

12. The system of claim 1 1 wherein said method signature (814) comprises a method string (912) corresponding to said extended API (326), and set of parameters also corresponding to said extended API (326), said set of parameters including a parameter name (914) and a parameter type (916).

13. The system of claim 1 wherein said software module (312) utilizes an extended API (326) to communicate with said extended capability of said device (1 12).

14. The system of claim 13 wherein said software module (312) sends a query to said registry (412) to locate a DCM registration (512(e)) corresponding to a device control module (422) that controls said device (1 12).

15. The system of claim 14 wherein said registry (412) returns a DCM software element identifier (514(e)) to said software module (312) when said query is successful.

16. The system of claim 14 wherein said registry (412) returns a failure message to said software module (312) when said query is unsuccessful.

17. The system of claim 14 wherein said software module (312) accesses an attribute list (516(e)) within said DCM registration (512(e)) in said registry (412).

18. The system of claim 17 wherein said software module (312) scans said attribute list (516(e)) to locate said extended attribute (614).

19. The system of claim 18 wherein said software module (312) accesses and parses said extended attribute (614) to extract extended API information.

20. The system of claim 19 wherein said software module (312) utilizes said extended API information to construct and send a request call via said extended API (326) to said device control module (422), to thereby control said extended capability of said device (1 12) .

21. A method for discovering an extended capability of a device (112) in an electronic network (1 10), comprising the steps of: storing into a registry (412) an extended attribute (614) corresponding to said extended capability; and accessing said extended capability with a software module (312) by utilizing said extended attribute (614).

22. The method of claim 21 wherein said software module (312) is a device application that communicates with said device (1 12) on said electronic network ( 110).

23. The method of claim 21 wherein said registry (412) forms part of network software (316) for said electronic network (1 10).

24. The method of claim 23 wherein said network software (316) is configured to comply with a home audio- video interoperability specification.

25. The method of claim 21 wherein said electronic network (110) is connected through a network bus (120) configured using an IEEE 1394 interconnectivity standard.

26. The method of claim 21 wherein a manager element encodes said extended attribute (614) in an attribute list (516(e)) within a module registration (512(e)) to thereby include extended API information in said extended attribute (614), and wherein said software module (312) responsively utilizes said extended API information to discover and use an extended API (326) for controlling said extended capability through a device control module (422).

27. The method of claim 21 wherein a DCM manager (416) performs a device discovery procedure following a connection of said device (1 12) to said electronic network (1 10), said DCM manager (416) examining self-describing data (320) in said device (1 12) to learn about said extended capabilities during said device discovery procedure.

28. The method of claim 27 wherein said DCM manager (416) instantiates a device control module (422) to control said device (1 12) on said electronic network (1 10).

29. The method of claim 28 wherein said DCM manager (416) creates a DCM registration (512(e)) in said registry (412), said DCM registration (512(e)) including a DCM software element registration (514(e)) and a DCM attribute list (516(e)).

30. The method of claim 29 wherein said DCM attribute list (516(e)) includes standard attributes (612) and said extended attribute (614).

31. The method of claim 30 wherein said extended attribute (614) comprises extended API information that is obtained by said DCM manager (416) during said device discovery procedure, said extended API information being encoded as a textual string to include a method ID (812) corresponding to an extended API (326), and a method signature (814) also corresponding to said extended API (326) .

32. The method of claim 31 wherein said method signature (814) comprises a method string (912) corresponding to said extended API (326), and set of parameters also corresponding to said extended API (326), said set of parameters including a parameter name (914) and a parameter type (916).

33. The method of claim 21 wherein said software module (312) utilizes an extended API (326) to communicate with said extended capability of said device (1 12).

34. The method of claim 33 wherein said software module (312) sends a query to said registry (412) to locate a DCM registration (512(e)) corresponding to a device control module (422) that controls said device (1 12).

35. The method of claim 34 wherein said registry (412) returns a DCM software element identifier (514(e)) to said software module (312) when said query is successful.

36. The method of claim 34 wherein said registry (412) returns a failure message to said software module (312) when said query is unsuccessful.

37. The method of claim 34 wherein said software module (312) accesses an attribute list (516(e)) within said DCM registration (512(e)) in said registry (412).

38. The method of claim 37 wherein said software module (312) scans said attribute list (516(e)) to locate said extended attribute (614).

39. The method of claim 38 wherein said software module (312) accesses and parses said extended attribute (614) to extract extended API information.

40. The method of claim 39 wherein said software module (312) utilizes said extended API information to construct and send a request call via said extended API (326) to said device control module (422), to thereby control said extended capability of said device (1 12).

41. A system for discovering an extended capability of a device (1 12) in an electronic network (1 10), comprising: means for storing an extended attribute (614) corresponding to said extended capability; and means for accessing said extended capability by utilizing said extended attribute (614).

42. A computer-readable medium comprising program instructions for discovering an extended capability of a device (1 12) by performing the steps of: storing into a registry (412) an extended attribute (614) corresponding to said extended capability; and accessing said extended capability with a software module (312) by utilizing said extended attribute (614).