WO2000062479A2

WO2000062479A2 - System and method for maintaining fully-replicated registries in an electronic network

Info

Publication number: WO2000062479A2
Application number: PCT/US2000/008851
Authority: WO
Inventors: Rodger Lea
Original assignee: Sony Electronics Inc
Current assignee: Sony Electronics Inc
Priority date: 1999-04-09
Filing date: 2000-04-03
Publication date: 2000-10-19
Anticipated expiration: 2001-10-09
Also published as: WO2000062479A3; AU4067400A; TW477134B

Abstract

A system and method for maintaining fully-replicated registries in an electronic network comprises a local registry (412) that generates a remote update message (820) in response to the addition of a new software element (812) on the electronic network. The local registry (412) then broadcasts the remote update message (820) to all remote registries (822) in the electronic network (110). Each of the remote registries (822) may then perform an update procedure to incorporate a unique element registration corresponding to the new software element (812). The present invention thus maintains fully-replicated registries across the electronic network to facilitate and expedite remote messaging processes.

Description

SYSTEM AND METHOD FOR MAINTAINING FULLY-REPLICATED 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, to co-pending U.S. Patent Application Serial No. 09/257,344, entitled "System And Method For Implementing Active Registries In An Electronic Network," filed on February 25, 1999, to co-pending U.S. Patent Application Serial No. 09/289,498, entitled "System And Method For Performing A Hierarchical Remote Query In An Electronic Network," filed on April 9, 1999, and to co-pending U.S. Patent Application Serial No. 09/288,995, entitled "System And Method For Locally Caching Remote Query Replies In An

Electronic Network," filed on April 9, 1999, which are hereby incorporated by reference. The cross-referenced applications are commonly assigned.

BACKGROUND OF THE INVENTION

Field of the Invention

This invention relates generally to electronic networks, and relates more particularly to a system and method for maintaining fully-replicated registries in an electronic network.

2. Description of the Background Art

Implementing an effective method for managing communications between software elements that reside on electronic devices within an electronic network is a significant consideration for manufacturers and designers 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 of electronic networks. For example, enhanced demands for increased functionality and performance many 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.

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 across the 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 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, periodic alteration of 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 information about 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 maintaining fully-replicated registries in an electronic network. In one embodiment of the invention, whenever a new software element is added to the electronic network, an added-element notification is preferably provided to local software to announce the addition of the new software element to the electronic network.

The local software preferably receives the added-element notification corresponding to the new software element, and then responsively generates a registration call to a local registry to initiate a local registration of the new software element. The local registry then preferably creates and locally stores an element registration corresponding to the new software element. In the one embodiment, the local registry generates a unique software element identifier (SEID) as part of the element registration. As part of the element registration, the local registry also preferably stores an attribute list that corresponds to the new software element.

In accordance with the present invention, the local registry also builds a remote update message that includes information regarding the addition of the new software element on the electronic network. In one embodiment of the present invention, the remote update message preferably includes the SEID and the attribute list that correspond to the new software element. The local registry then advantageously broadcasts the remote update message to all remote registries on the electronic network. In one embodiment, the local registry references a remote registry list to identify the remote registries to which the remote update message is broadcast.

Upon receiving the remote update message, each of the remote registries responsively updates itself by creating a new element registration that is based upon the remote update message. The new element registration preferably includes information for identifying and locating the new software element on the electronic network. The present invention may thus propagate and manage relevant information regarding any software elements that are added to the electronic network to provide fully-replicated registries across the network. The time- consuming need to globally broadcast remote queries each time that a local query is unsuccessful in locating a target software element is therefore removed. Instead, the present invention efficiently performs a remote registry update procedure whenever a software element is added to the electronic network. The present invention thus effectively maintains fully-replicated registries 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 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 flowchart of method steps for locally registering a software element, in accordance with one embodiment of the present invention;

FIG. 7 is a flowchart of method steps for performing a query process, in accordance with one embodiment of the present invention;

FIG. 8 is a block diagram illustrating one embodiment for maintaining fully-replicated registries, in accordance with the present invention; and

FIG. 9 is a flowchart of method steps for maintaining fully-replicated 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 maintaining fully-replicated registries in an electronic network, and includes a local registry that generates a remote update message in response to the addition of a new software element on the electronic network. The local registry then broadcasts the remote update message to all remote registries in the electronic network. Each of the remote registries may then perform an update procedure to incorporate a unique element registration corresponding to the new software element. The present invention thus maintains fully- replicated registries across the electronic network to facilitate and expedite remote messaging processes.

Referring now to FIG. 1 , a block diagram for one embodiment of an electronic network 110 is shown, in accordance with the present invention. In the FIG. 1 embodiment, network 110 includes, but is not limited to, device A 1 12, device B 1 14, device C 1 16, 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 may preferably be 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 1 14, device C 1 16, and device D 1 18 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 1 10 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 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.

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 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 112. 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 1 12.

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 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 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 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. 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 software elements in network 110. Registry 412 may thus allow any software element to obtain a software element identifier (SEID) for identifying and locating 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 110.

In the FIG. 4 embodiment, event manager 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 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 110. In the FIG. 4 embodiment, resource manager 420 preferably facilitates the sharing of various resources and scheduling of various actions in network 110. 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 legacy device on network 1 10. 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 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. 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 110.

Network software 316 preferably performs a number of significant and related operations whenever a particular device is removed from, or added to, network 110. When a device is added or removed from network 110, then network bus 120 preferably triggers a bus reset event which notifies all connected devices about the change in network 110. Following the bus reset event, all DCM managers 416 in network 110 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 must therefore maintain a current list of all devices in network 110. Network software 316 preferably also updates relevant software element information in registry 412 whenever a device is removed from, or added to, network 1 10. In the FIG. 4 embodiment, a given local registry 412 also preferably includes a list of all remote registries 412 in 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 110. 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. 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).

Referring now to FIG. 6, a flowchart of method steps for locally registering a software element is shown, in accordance with one embodiment of the present invention. In the FIG. 6 embodiment, in step 612, network software 216 monitors network 110 to determine whether a new software element has been added to network 110. If a new software element has been added to network 110, then the FIG. 6 process advances to step 614 to register the new software element.

For example, local software such as a DCM manager 416 in a local set- top box device may receive an added-element notification after a new base device, such as a storage device, is added to network 110. The local DCM manager 416 may then locally install a new DCM 422 to control the added storage device. The local registry 412 must then register the new DCM 422 with a corresponding SEID, so that other software across network 110 may communicate with the new DCM 422, as discussed above.

In step 614, local software (such as DCM manager 416) preferably sends a registration call to local registry 412 to initiate a local software element registration process. Then, in step 616, local registry 412 determines whether the new software element is already registered locally. In step 618, if the newly-added software element is already registered, then the FIG. 6 process returns to step 612 to wait for notification of another added software element on network 1 10.

However, in step 618, if the new software element is not already registered, then, in step 620, local registry 412 generates a software element identifier (SEID) to uniquely identify the new software element. Next, in step 622, local registry 412 performs an update process to incorporate the new software element. In the FIG. 6 embodiment, local registry 412 creates an element registration 512 that preferably includes the newly-created SEID 514 and a corresponding attribute list 516, as discussed above in conjunction with FIG. 5. Finally, in step 624, local registry 412 provides the SEID, corresponding to the new software element, to the local software (for example, DCM manager 416) that initiated the FIG. 6 software element registration process in step 614. The foregoing FIG. 6 software element registration process therefore locally registers local software elements from a given set of network software 216. Limiting element registrations in registry 412 to only local software elements conserves memory resources. However, local software may be required to utilize a remote query process to obtain SEIDs for those remote software elements not registered in local registry 412. One embodiment of such a remote query process is further discussed below in conjunction with FIG. 7.

Referring now to FIG. 7, a flowchart of method steps for performing a query process is shown, in accordance with one embodiment of the present invention. In the FIG. 7 embodiment, initially, local software (such as device application 312) creates a local query to locate a desired target software element in network 110. Queries may be configured using any appropriate format, and may specify desired criteria such as one or more software element attributes.

In step 714, the local software preferably transmits the local query to local registry 412. In response, in step 716, local registry 412 performs a lookup procedure to determine whether any locally-registered software elements satisfy the local query transmitted from the local software. In step 718, if the local query is successful and a local software element is located that satisfies the query criteria, then, in step 728, local registry 412 returns the SEID of that local software element to the querying local software and the FIG. 7 process terminates.

However, in step 718, if the local query is not successful, then, in step 720, local registry 412 builds a remote query that preferably includes the same or similar criteria as the local query transmitted in foregoing step 714. Next, in step 722, local registry 412 broadcasts the remote query to all remote registries located on other devices across network 110 in the hope of locating a remote software element that satisfies the remote query.

In step 724, local registry 412 gathers the replies to the remote query from all of the remote registries across network 1 10. Then, in step 726, local registry 412 determines whether the remote query was successful in locating at least one target software element for the local software. In the FIG. 7 embodiment, such a successful remote query reply preferably includes the SEID of the remote target software element. If the remote query fails to successfully locate a target software element, then, in step 730, local registry 412 returns a remote query failure message to the local software. However, if the remote query successfully locates a target software element, then, in step 728, local registry 412 returns the SEID of the target software element to the local software that initially instigated the FIG. 7 query process in foregoing step 714. The local software may then utilize the SEID of the remote target software element to communicate with the target software element. However, the foregoing remote query process (FIG. 7, steps 720 through 726) typically requires excessive messaging across network 1 10, and also consumes substantial amounts of processing resources. An alternative technique for implementing and maintaining fully-replicated registries in network 110 is discussed below in conjunction with FIGS. 8 and 9. Referring now to FIG. 8, a block diagram illustrating one embodiment for maintaining fully-replicated registries is shown, in accordance with the present invention. In the FIG. 8 embodiment, whenever a new software element 812 is added to network 110, an added-element notification 814 is preferably provided to local software 816 to announce the addition of new software element 812 on network 110. Added-element notification 814 may include various relevant information corresponding to new software element 812. In some embodiments of the present invention, new software element 812 may generate added-element notification 814, and may also provide added-element notification 814 to other destinations across network 1 10. In accordance with the present invention, added-element notification 814 may be generated and propagated using any appropriate and compatible technique. In practice, local software, such as a DCM manager 416 in a local set-top box device, may receive added-element notification 814 after a new base device, such as a storage device, is added to network 1 10. The local DCM manager 416 may take responsibility for controlling the new storage device, and then locally install a new DCM 422 to control the storage device. The local registry 412 must then register the new DCM 422 with a corresponding SEID, so that other software across network 1 10 may communicate with the new DCM 422.

In the FIG. 8 embodiment, local software 816 preferably receives added-element notification 814 corresponding to new software element 812, and then responsively generates a registration call 818 to local registry 412 to initiate the local registration of new software element 812 in local registry 412. In some embodiments, registration call 818 may include selected information from added-element notification 814 that relates to new software element 812.

Local registry 412 then preferably creates and locally stores an element registration 512 (FIG. 5) for new software element 812. In the FIG. 8 embodiment, local registry 412 generates a unique software element identifier (SEID) 514 as part of the element registration 512. Local registry 412 also preferably stores an attribute list 516 corresponding to new software element 812 as part of element registration 512.

In accordance with the present invention, and in response to the addition of new software element 812 to network 110, local registry 412 also builds a remote update message 820 and broadcasts the remote update message 820 to all remote registries 822 on network 1 10. In the FIG. 8 embodiment, remote update message 820 preferably includes the SEID 514 and attribute list 516 corresponding to new software element 812. In alternate embodiments, remote update message 820 may likewise include various other information that is different from, or in addition to, the SEID 514 and attribute list 516 of the FIG. 8 embodiment.

In the FIG. 8 embodiment, local registry 412 preferably maintains a remote registry list 824 that includes a series of unique SEIDs that each correspond to a different remote registry 822 currently residing on network 110. Local registry 412 therefore may reference the remote registry list 824 to locate each remote registry 822, and then advantageously broadcast remote update message 820 through local messaging system 424, local communication media manager 426, and network bus 120 to each device on network 110 that includes a remote registry 822. Upon receiving remote update message 820, each of the remote registries 822 responsively performs an update process by creating and incorporating a new element registration 512 that is based upon the remote update message 820. New element registration 512 preferably includes information for identifying and locating new software element 812. Therefore, the present invention effectively registers new software element 812 in both local registry 412 and remote registries 822. Creating and broadcasting remote update messages for any new software elements 812 thus successfully maintains fully- replicated registries in network 110.

In some embodiments of the present invention, a process similar to the foregoing FIG. 8 technique may be utilized to globally delete any removed software elements from the registries on network 1 10. For example, when a software element is deleted from network 110, then network 1 10 may generate a removed-element notification to local software 816. Then, local software 816 may send a de-registration call to local registry 412, and, in response, local registry 412 may generate a remote deletion message to all remote registries 822. Remote registries 822 therefore may delete the element registration 512 that corresponds to the particular software element removed from network 1 10.

Therefore, the present invention may advantageously propagate and manage relevant information regarding any software elements that are added to, or removed from, network 1 10 to provide fully-replicated registries across network 110. The time-consuming and burdensome need to globally broadcast remote queries each time that a local query is unsuccessful in locating a target software element is therefore removed. Instead, the present invention performs a single remote registry update procedure whenever a software element is added or removed from network 110.

Referring now to FIG. 9, a flowchart of method steps for maintaining fully-replicated registries is shown, in accordance with one embodiment of the present invention. Initially, in step 912 of the FIG. 9 embodiment, network software 216 monitors network 1 10 to determine whether a new software element 812 has been added to network 110. If a new software element 812 has been added to network 1 10, then the FIG. 9 process advances to step 914 to register the new software element 812.

For example, local software 816 such as a DCM manager 416 in a local set-top box device may receive an added-element notification 814 after a new base device, such as a storage device, is added to network 110. The local DCM manager 416 may then locally install a new DCM 422 to control the added storage device. The local registry 412 must then register the new DCM 422 with a corresponding SEID 514, so that other software across network 110 may communicate with the new DCM 422. In step 914, local software 914 preferably sends a registration call 818 to local registry 412 to initiate a local software element registration process. Then, in step 916, local registry 412 determines whether the new software element 812 is already registered locally. In step 918, if new software element 812 is already registered, then the FIG. 9 process returns to step 912 to wait for notification of another added software element on network 1 10. However, in step 918, if new software element 812 is not already registered, then, in step 920, local registry 412 generates a software element identifier (SEID) 514 to uniquely identify new software element 812. Next, in step 922, local registry 412 performs an update process to incorporate new software element 812. In the FIG. 9 embodiment, local registry 412 creates an element registration 512 that preferably includes the newly-created SEID 514 and a corresponding attribute list 516, as discussed above in conjunction with FIG. 5. In step 924, local registry 412 then provides the SEID 514, corresponding to new software element 812, to the local software 816 that initiated the FIG. 9 process in step 914.

In accordance with the present invention, in step 926, local registry 412 also builds a remote update message 820. In the FIG. 9 embodiment, remote update message 820 preferably includes the SEID 514 and attribute list 516 corresponding to new software element 812. Then, in step 928, local registry 412 preferably broadcasts the remote update message 820 to all remote registries 822 on network 1 10. In the FIG. 9 embodiment, local registry 412 preferably maintains a remote registry list 824 that includes a unique SEID corresponding to each remote registry 822 currently residing on network 1 10. Local registry 412 therefore may reference the remote registry list 824 to locate each remote registry 822, and then advantageously broadcast remote update message 820 through local messaging system 424, local communication media manager 426, and network bus 120 to each device on network 110 that includes a remote registry 822.

Finally, in step 930, upon receiving remote update message 820, each remote registry 822 responsively performs an update process by creating and incorporating a new element registration 512 that is based upon the remote update message 820. New element registration 512 preferably includes various relevant information for identifying and locating new software element 812. Therefore, the present invention effectively registers new software element 812 in both local registry 412 and remote registries 822. Creating and broadcasting remote update messages for any new software elements 812 thus successfully maintains fully-replicated registries in network 1 10. The foregoing FIG. 9 embodiment is discussed in the context of a single local registry 412. However, the present invention is contemplated for use by any registry within network 110. In other words, any given registry in network 1 10 may readily assume the role of local registry 412 to locally register a new software element 812 that is added to network software 316, and then globally broadcast a remote update message 820 to all remaining remote registries 822 in network 1 10, in accordance with the present invention.

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 updating information in an electronic network (110), comprising: a local registry (412) coupled to said electronic network (110) for generating and broadcasting a remote update message (820); and one or more remote registries (822) coupled to said local registry (412) for receiving said remote update message (820) and responsively performing an update process.

2. The system of claim 1 wherein said information includes individual element registrations each corresponding to a software element in said electronic network (110).

3. The system of claim 1 wherein said local registry (412) forms part of network software (316) for a device on 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 said local registry (412) generates said remote update message (820) to register new software elements in said one or more remote registries (822) on said electronic network (110), and thereby maintains said information in a fully-replicated state across said electronic network (110) to facilitate remote messaging processes.

7. The system of claim 1 wherein a new software element (812) on said electronic network ( 1 10) provides an added-element notification (814) to local software (816) in an electronic device on said electronic network (1 10).

8. The system of claim 7 wherein said local software (816) instigates a registration procedure by sending a registration call (818) to said local registry (412) in response to said added-element notification (814).

9. The system of claim 8 wherein said local registry (412) determines whether said new software element (812) has previously been registered in said local registry (412).

10. The system of claim 9 wherein said local registry (412) returns a reject message to said local software (816) whenever said new software element (812) has previously been registered in said local registry (412).

1 1. The system of claim 8 wherein said local registry (412) creates a local element registration corresponding to said new software element (812).

12. The system of claim 11 wherein said element registration includes a unique software element identifier (514) and an attribute list (516) that correspond to said new software element (812).

13. The system of claim 11 wherein said local registry (412) performs a local update by incorporating said element registration that corresponds to said new software element (812).

14. The system of claim 13 wherein said local registry (412) returns a unique software element identifier (514) to said local software (816) after completing said local update.

15. The system of claim 12 wherein said local registry (412) builds a remote update message (820) that includes registration information corresponding to said new software element (812).

16. The system of claim 15 wherein said remote update message (820) includes said unique software element identifier (514) corresponding to said new software element (812).

17. The system of claim 15 wherein said local registry (412) broadcasts said remote update message (820) to each of said one or more remote registries (822) in said electronic network (1 10).

18. The system of claim 17 wherein said local registry (412) broadcasts said remote update message (820) by referencing a remote registry list (824).

19. The system of claim 17 wherein said one or more remote registries (822) each perform a remote update based on said remote update message (820) to incorporate a remote element registration corresponding to said new software element (812).

20. The system of claim 1 wherein said local registry (412) generates and broadcasts a remote deletion message to de-register removed software elements from said one or more remote registries (822) on said electronic network (110).

21. A method for updating information in an electronic network (110), comprising the steps of: generating a remote update message (820) with a local registry (412) in said electronic network (1 10); broadcasting said remote update message (820) to one or more remote registries (822) in said electronic network (110); and performing an update process to said one or more remote registries (822) based on said remote update message (820).

22. The method of claim 21 wherein said information includes individual element registrations each corresponding to a software element in said electronic network (110).

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

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 said local registry (412) generates said remote update message (820) to register new software elements in said one or more remote registries (822) on said electronic network (1 10), and thereby maintains said information in a fully-replicated state across said electronic network (110) to facilitate remote messaging processes.

27. The method of claim 21 wherein a new software element (812) on said electronic network (110) provides an added-element notification (814) to local software (816) in an electronic device on said electronic network (110).

28. The method of claim 27 wherein said local software (816) instigates a registration procedure by sending a registration call (818) to said local registry (412) in response to said added-element notification (814).

29. The method of claim 28 wherein said local registry (412) determines whether said new software element (812) has previously been registered in said local registry (412).

30. The method of claim 29 wherein said local registry (412) returns a reject message to said local software (816) whenever said new software element (812) has previously been registered in said local registry (412).

31. The method of claim 28 wherein said local registry (412) creates a local element registration corresponding to said new software element (812).

32. The method of claim 31 wherein said element registration includes a unique software element identifier (514) and an attribute list (516) that correspond to said new software element (812).

33. The method of claim 31 wherein said local registry (412) performs a local update by incorporating said element registration that corresponds to said new software element (812).

34. The method of claim 33 wherein said local registry (412) returns a unique software element identifier (514) to said local software (816) after completing said local update.

35. The method of claim 32 wherein said local registry (412) builds a remote update message (820) that includes registration information corresponding to said new software element (812).

36. The method of claim 35 wherein said remote update message (820) includes said unique software element identifier (514) corresponding to said new software element (812).

37. The method of claim 35 wherein said local registry (412) broadcasts said remote update message (820) to each of said one or more remote registries (822) in said electronic network ( 1 10).

38. The method of claim 37 wherein said local registry (412) broadcasts said remote update message (820) by referencing a remote registry list (824).

39. The method of claim 37 wherein said one or more remote registries (822) each perform a remote update based on said remote update message (820) to incorporate a remote element registration corresponding to said new software element (812).

40. The method of claim 21 wherein said local registry (412) generates and broadcasts a remote deletion message to de-register removed software elements from said one or more remote registries (822) on said electronic network (110).

41. A system for updating information in an electronic network (1 10), comprising: means for generating a remote update message (820) in response to an event on said electronic network (1 10); means for broadcasting said remote update message (820) to one or more remote registries (822) in said electronic network (1 10); and means for performing an update process to said one or more remote registries (822) based on said remote update message (820).

42. A computer-readable medium comprising program instructions for updating information in an electronic network ( 1 10) by performing the steps of: generating a remote update message (820) with a local registry (412) in said electronic network ( 1 10); broadcasting said remote update message (820) to one or more remote registries (822) in said electronic network (110); and performing an update process to said one or more remote registries (822) based on said remote update message (820).