WO2000051289A2

WO2000051289A2 - System and method for implementing active registries in an electronic network

Info

Publication number: WO2000051289A2
Application number: PCT/US2000/004230
Authority: WO
Inventors: Clement Lau
Original assignee: Sony Electronics Inc
Current assignee: Sony Electronics Inc
Priority date: 1999-02-25
Filing date: 2000-02-17
Publication date: 2000-08-31
Anticipated expiration: 2001-08-25
Also published as: JP2002538537A; AU3236000A; WO2000051289A3; EP1155530A2

Abstract

A system and method for implementing active registries in an electronic network (110) comprises one or more source elements that each subscribe for notification from an event manager (414) when either an add-element event or a remove-element event occurs. An active registry (412) generates an element-change event message (614) to the event manager (414) when either an add-element event or a remove-element event occurs. The event manager (414) responsively generates an event notification message (618) to all subscribed source elements. The subscribed source elements may then examine the registry (412) and respond appropriately to the add-element event or the remove-element event.

Description

SYSTEM AND METHOD FOR IMPLEMENTING ACTIVE

REGISTRIES IN AN ELECTRONIC NETWORK

CROSS-REFERENCE TO RELATED APPLICATIONS

This application relates to co-pending U.S. Patent Application Serial No. 09/259,504, entitled "System And Method For Incrementally Updating Remote Element Lists In An Electronic Network," filed on February 26, 1999, which is hereby incorporated by reference. The 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 system and method for implementing active registries in an electronic network.

Description of the Background Art

Implementing an effective method for managing communications between software elements from electronic devices within an electronic network is a significant consideration for designers, manufacturers, and users of contemporary electronic devices. 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 efficient communications in a network of electronic devices may create substantial challenges for designers and manufacturers of electronic networks. For example, enhanced design demands for increasing functionality and performance many require more system processing power and require additional hardware resources over the network. An increase in processing or hardware requirements also typically results in a corresponding detrimental economic impact from increased production costs and operational inefficiencies.

Network size and device functionality are also factors that affect 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. For example, a software element on a local network device may need to communicate with various remote software elements on remote devices on the network. However, successfully managing a substantial number of electronic devices on a single network may provide significant benefits to a system user. Furthermore, enhanced device capability to perform various advanced functions may provide additional benefit to a system user, but may also place increased demands on the control and management of various devices in the electronic network. For example, an 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, periodically altering the configuration of an electronic network by a system user may present a need for creating transparent and efficient techniques to manage the addition or removal of various software elements in the network. For example, if a new software element is added to the network, then the other software elements in the network may require notification of the existence and capabilities of newly-added software element, so that all software elements in the network may advantageously communicate with the newly-added software element.

Therefore, for all the foregoing reasons, implementing an effective method for managing communications between various software elements in a distributed electronic network remains a significant consideration for designers, manufacturers, and users of electronic devices.

SUMMARY OF THE INVENTION

In accordance with the present invention, a system and method are disclosed for implementing active registries in an electronic network. In one embodiment of the invention, initially, a software element becomes a subscribed element by subscribing with an event manager for notification of selected events occurring in the electronic network. The selected events may include an add-element event or a remove-element event, and the subscribed element may include, but is not limited to, a device application or an element of network software for controlling the electronic network. The subscribed element may then passively perform its normal functions, depending on the functionality of the particular software element or device application. The subscribed element concurrently monitors whether an event notification message has been received from the event manager. If an event notification message has been received from the event manager, then the subscribed element responsively examines a registry to search for a software element identifier (SEID) of a desired target element. The subscribed element may examine the registry using any appropriate and compatible examination technique, including an SEID search key method or a query method.

The subscribed element then determines, based on the results of the foregoing examination procedure, whether the desired target element is currently registered in the registry. Depending on whether the desired target element is currently registered in the registry, the subscribed element may advantageously respond in an appropriate manner to the event on the electronic network. For example, in the case of an add-element event, the subscribed element may send a message to the identified target element, in accordance with the present invention.

Similarly, in the case of a remove-element event, the subscribed element may take appropriate action in response to the removal of the software element. For example, if the subscribed element is responsible for displaying a topology map of all software elements in the network, then the subscribed element may update the software element topology map in response to the remove-element event. The subscribed element thus may remain passive, and, in accordance with the present invention, need not repeatedly poll the registry to determine the current software configuration of the electronic network.

The foregoing embodiment is discussed in the context of a single subscribed element and registry in the electronic network. However, the present invention may readily be implemented to function similarly with multiple subscribed elements and registries across the electronic network. The present invention thus effectively and efficiently implements active registries in an 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 memory map 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 block diagram illustrating the implementation of active registries in an electronic network, in accordance with one embodiment of the present invention; and

FIG. 7 is a flowchart of method steps for implementing active registries in an electronic network, 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 system and method for implementing active registries in an electronic network, and includes one or more source elements that each subscribe for notification from an event manager when either an add-element event or a remove-element event occurs. An active registry generates an element-change event message to the event manager when either an add-element event or a remove-element event occurs. The event manager responsively generates an event notification message to all subscribed source elements. The subscribed source elements may then examine the registry and respond appropriately to the add-element event or the remove-element event.

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 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 may readily be implemented using a larger or smaller 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 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 110 is preferably configured to operate in accordance with the Home Audio /Video Interoperability (HAVi) core specification (version 1.0 beta, November 19, 1998) which is hereby incorporated by reference. Therefore, device A 112, device B 114, device C 116, and device D 118 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 110 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 device (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 110 may readily includes 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 112 from FIG. 1 is shown, in accordance with the present invention. In the FIG. 2 embodiment, device 112 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 112 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 110. 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 1 12 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.

Referring now to FIG. 3, a memory map 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, and a vendor- specific platform 324. 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 112. 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 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 112 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 110. 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 110 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 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 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. 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 preferably includes a listing of all local software elements in network software 316. Registry 412 also preferably may include relevant element information 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 thus may serve as a directory service for software elements in network 110 to allow any software element to locate another software element in network 110. 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 manage 414 preferably serves as an 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 110. 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 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 control a specific associated device on network 110. 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 112 that corresponds to the FCM 423. A full device or an intermediate device may preferably host a DCM 422 to control a corresponding base device or a legacy device on network 110. In an intermediate device, the hosted DCM 422 is preferably embedded as part of network software 316. In a full device, the hosted DCM 422 may be downloaded from the corresponding remote device in network 110.

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. In addition to software elements 412 through 426 of network software 316, a full device may also include a bytecode runtime environment (not shown) to permit the full device to download and execute one or more remote DCM(s) 422 to thereby host and control other devices on network 1 10.

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)). Each FIG. 5 element registration 512(a) through 512 (d) preferably corresponds to a software element in network 1 10. 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 in network 110. In order to send a message to a target element in network 110, a source element preferably identifies the target element by using the corresponding SEID 514 of that target element. In network 110, a 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.

In the FIG. 5 embodiment, a source element (such as device application 312) may typically examine registry 412 through a number of different methods to locate the SEID 514 for a target element (such as a device control module (DCM) 422). For example, in a search key method, a source element that knows a potential, but unconfirmed, SEID 514 for the target element may send the unconfirmed SEID 514 to registry 412 as an search input parameter. Registry 412 responsively outputs to the source element an attribute list 516 that corresponds to the unconfirmed SEID 514. The source element may then examine that attribute list 516 to determine whether the unconfirmed SEID 514 is correct.

Alternately, in a query method, a source element may form a query, including a list of specified search criteria (for example, an element manufacturer and an element model), and then send the query to registry 412 as an input parameter. Registry 412 responsively outputs to the source element an SEID list including all SEIDs 514 that satisfy the search criteria of the query.

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). However, an element of uncertainty exists because of the capability of adding and removing software elements on network 110. A given source element therefore can not be confident that a particular target device is, or is not, currently on network 110. A source device may thus be required to constantly poll registry 412 to determine whether any changes have occurred in network 110. Frequent and repeated polling of registry 412 produces significantly increased traffic on network 110, and also requires substantially increased processing power across network 110. An alternate technique for implementing and utilizing an active registry 412 is further discussed below in conjunction with FIG. 6.

Referring now to FIG. 6, a block diagram illustrating the implementation of active registries 412 is shown, in accordance with one embodiment of the present invention. Although the FIG. 6 embodiment is discussed in the context of a single active registry, in practice, the present invention may readily be implemented to include similar processes in each registry 412 in network 110.

In the FIG. 6 embodiment, initially, whenever a new software element is added to network 1 10, then a defined add-element event occurs, and the newly-added software element preferably creates a corresponding element registration 612 in registry 412. Similarly, whenever an existing software element is removed from network 1 10, then a defined remove-element event occurs, and that software element concurrently removes its corresponding element registration 612 from registry 412. In the FIG. 6 embodiment, in response to either an add-element event or a remove-element event, registry 412 preferably generates an element- change event message 614 to event manager 414 via messaging system 424 (not shown). In the FIG. 6 embodiment, element-change event message 614 preferably specifies the type of event (add-element event or remove-element event) and the SEID 514 of the changed software element from registry 412. However, due to bandwidth limitations on network 110, in the FIG. 6 embodiment, element-change event message 614 typically contains no further details about the changed software element in registry 412.

Event manager 414 preferably comprises a subscription list 616 that includes a list of subscribed elements from network 110. For each of the subscribed elements, subscription list 616 preferably also includes corresponding specified events that require notification. Upon the occurrence of a specified event on network 110, event manager 414 may thus responsively notify the designated subscribed elements by referring to subscription list 616.

In the FIG. 6 embodiment, when event manager 414 receives element- change event message 614 from registry 412, then event manager 414 responsively transmits an event notification message 618 to the appropriate subscribed elements 620 via messaging system 424 (not shown), depending on whether the change to network 1 10 was an add-element event or a remove-element event. In the FIG. 6 embodiment, due to bandwidth limitations on network 1 10, event notification message 618 preferably includes only the SEID 514 of the changed software element from active registry 412.

The subscribed elements 620 may then responsively examine active registry 412 using various examination methods, including those discussed above in conjunction with FIG. 5, to potentially identify the desired target element. Finally, if a target element is successfully identified, subscribed elements 620 may advantageously respond in an appropriate manner to the change in network 110.

Referring now to FIG. 7, a flowchart of method steps for implementing active registries 412 is shown, in accordance with one embodiment of the present invention. The FIG. 7 embodiment is discussed in the context of a single subscribed element 620 (source element) and registry 412 in network 110. However, the present invention may readily be implemented to function similarly with multiple subscribed elements 616 (source elements) and registries 412 across network 110.

In the FIG. 7 embodiment, initially, in step 712, a source element subscribes to selected events in network 110 to thereby become a subscribed element 620 in subscription list 616 of event manager 414. Subscribed element 620 may include, but is not limited to, a device application 312 or a software element of network software 316 (FIG. 4). Then, in step 714, subscribed element 620 performs its normal functions, depending on the functionality of the particular software element or device application 312. In one embodiment, during the first occurrence of step 714, subscribed element 620 may perform a single initial examination of registry 412 in order to determine the beginning topology of software elements in network 110.

In step 716, subscribed element 620 monitors event manager 414 to determine whether an event notification message 618 has been triggered and transmitted due to the occurrence of an event on network 110. If no event notification message 618 has been received, then the FIG. 7 process returns to step 714, and subscribed element 620 continues to perform its normal functions. However, if an event notification message 618 has been received from event manager 414, then subscribed element 620 responsively examines registry 412 to potentially identify the desired target element. Subscribed element 620 may perform the foregoing registry examination (step 718) using any appropriate and compatible examination technique, including the search key method or the query method discussed above in conjunction with FIG. 5.

In step 720, subscribed element 620 determines, based on the results of the foregoing registry examination procedure (step 718), whether the desired target element can currently be identified using registry 412. If the desired target element can not currently be identified, then the FIG. 7 process returns to step 714, and subscribed element 620 continues to perform its normal functions.

However, if the desired target element can currently be identified using registry 412, then subscribed element 620 may advantageously respond in an appropriate manner to the event on network 110. In the case of an add- element event, subscribed element 620 may function as a source element to send a message to the identified target element, in accordance with the present invention. For example, a host device application 312 may send a message to a newly-added DCM 422 to control a new remote device on network 110.

Similarly, in the case of a remove-element event, subscribed element 620 may take appropriate action in response to the removal of a software element. For example, if subscribed element 620 is responsible for displaying a topology map of all software elements in network 110, then subscribed element 620 may advantageously update a software element topology map in response to the remove-element event. Subscribed element 620 may thus remain passive, and, in accordance with the present invention, need not repeatedly poll registry 412 to determine the software configuration of 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 identifying a target element in an electronic network (110), comprising: a registry (412) configured to generate a notification message when an event occurs in said electronic network (110); and a source element subscribed to receive said notification message and responsively perform an examination procedure on said registry (412) to identify said target element.

2. The system of claim 1 wherein said registry (412) forms part of network software (316) for a device on said electronic network (110).

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

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

5. The system of claim 1 wherein said event includes one of an add- element event for adding said target element to said electronic network (110) and a remove-element event for removing said target element from said electronic network (110).

6. The system of claim 1 wherein said source element passively receives notification of software changes in said electronic network (110) to eliminate repeated register polling operations for identifying said target element.

7. The system of claim 1 wherein said registry (412) includes element registrations (512) each corresponding to a software element in said electronic network (110), said element registrations (512) each including a software element identifier (514) and an attribute list (516).

8. The system of claim 7 wherein said registry (412) generates an element-change event message (614) to an event manager (414) in response to said event.

9. The system of claim 8 wherein said element-change event message (614) specifies an event type and a changed software element identifier corresponding to an altered element.

10. The system of claim 8 wherein said event manager (414) includes a subscription list (616) of subscribed elements (620) that are informed when said event occurs in said electronic network (110).

11. The system of claim 10 wherein said event manager (414) sends an event notification message (618) to said subscribed elements (620) in response to said element- change event message (614) from said registry (412), said subscribed elements (620) including said source element.

12. The system of claim 11 wherein said event notification message (618) includes only said changed software element identifier to conserve processing resources in said electronic network (110).

13. The system of claim 11 wherein said source element, in response to said event notification message (618), examines said registry (412) using said changed software element identifier as a search input parameter to retrieve an associated attribute list (516).

14. The system of claim 1 1 wherein said source element, in response to said event notification message (618), examines said registry (412) using a query to retrieve a list of appropriate software element identifiers (514) from said registry (412).

15. The system of claim 11 wherein said source element, in response to said event notification message (618), examines said registry (412) to determine whether said target element is identified in said registry (412).

16. The system of claim 15 wherein said source element responds to said event based on said event type and whether said target element is identified in said registry (412)

17. The system of claim 15 wherein said source element sends a message to said target element when said target element is identified in said registry

(412) following an add-element event.

18. The system of claim 15 wherein said source element updates information about said target element when said target element is not identified in said registry (412) following a remove-element event.

19. The system of claim 7 wherein said source element performs an initial registry examination procedure to determine a beginning software element topology for said electronic network (1 10).

20. The system of claim 1 wherein said source element is an application program in a device on said electronic network (110).

21. A method for identifying a target element in an electronic network (110), comprising the steps of: subscribing a source element to receive a notification message (618) from a registry (412) when an event occurs in said electronic network (110); and performing an examination procedure to identify said target element in response to said notification message (618).

22. The method of claim 21 wherein said registry (412) forms part of network software (316) for a device on said electronic network (110).

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

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

25. The method of claim 21 wherein said event includes one of an add- element event for adding said target element to said electronic network (1 10) and a remove-element event for removing said target element from said electronic network (110).

26. The method of claim 21 wherein said source element passively receives notification of software changes in said electronic network (110) to eliminate repeated register polling operations for identifying said target element.

27. The method of claim 21 wherein said registry (412) includes element registrations (512) each corresponding to a software element in said electronic network (110), said element registrations (512) each including a software element identifier (514) and an attribute list (516).

28. The method of claim 27 wherein said registry (412) generates an element-change event message (614) to an event manager (414) in response to said event.

29. The method of claim 28 wherein said element-change event message (614) specifies an event type and a changed software element identifier corresponding to an altered element.

30. The method of claim 28 wherein said event manager (414) includes a subscription list (616) of subscribed elements (620) that are informed when said event occurs in said electronic network (110).

31. The method of claim 30 wherein said event manager (414) sends an event notification message (618) to said subscribed elements (620) in response to said element-change event message (614) from said registry (412), said subscribed elements (620) including said source element.

32. The method of claim 31 wherein said event notification message (618) includes only said changed software element identifier to conserve processing resources in said electronic network (110).

33. The method of claim 31 wherein said source element, in response to said event notification message (618), examines said registry (412) using said changed software element identifier as a search input parameter to retrieve an associated attribute list (516).

34. The method of claim 31 wherein said source element, in response to said event notification message (618), examines said registry (412) using a query to retrieve a list of appropriate software element identifiers (514) from said registry (412).

35. The method of claim 31 wherein said source element, in response to said event notification message (618), examines said registry (412) to determine whether said target element is identified in said registry (412).

36. The method of claim 35 wherein said source element responds to said event based on said event type and whether said target element is identified in said registry (412)_,

37. The method of claim 35 wherein said source element sends a message to said target element when said target element is identified in said registry

(412) following an add-element event.

38. The method of claim 35 wherein said source element updates information about said target element when said target element is not identified in said registry (412) following a remove-element event.

39. The method of claim 27 wherein said source element performs an initial registry examination procedure to determine a beginning software element topology for said electronic network (110).

40. The method of claim 21 wherein said source element is an application program in a device on said electronic network (110).

41. A system for identifying a target element in an electronic network (110), comprising: means for subscribing a source element to receive a notification message (618) from a registry (412) when an event occurs in said electronic network (110); and means for performing an examination procedure to identify said target element in response to said notification message (618).

42. A computer-readable medium comprising program instructions for identifying a target element by performing the steps of: subscribing a source element to receive a notification message (618) from a registry (412) when an event occurs in said electronic network (110); and performing an examination procedure to identify said target element in response to said notification message (618).