WO2001009740A1 - Systeme et procede destines a la mise en place de modeles de dispositifs dans un reseau electronique - Google Patents

Systeme et procede destines a la mise en place de modeles de dispositifs dans un reseau electronique Download PDF

Info

Publication number
WO2001009740A1
WO2001009740A1 PCT/US2000/021037 US0021037W WO0109740A1 WO 2001009740 A1 WO2001009740 A1 WO 2001009740A1 US 0021037 W US0021037 W US 0021037W WO 0109740 A1 WO0109740 A1 WO 0109740A1
Authority
WO
WIPO (PCT)
Prior art keywords
model
remote
control module
network
remote device
Prior art date
Application number
PCT/US2000/021037
Other languages
English (en)
Inventor
James Lea Rodger
Original Assignee
Sony Electronics Inc.
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Sony Electronics Inc. filed Critical Sony Electronics Inc.
Priority to JP2001514681A priority Critical patent/JP2003506779A/ja
Priority to AU63962/00A priority patent/AU6396200A/en
Priority to EP00950934A priority patent/EP1125215A1/fr
Publication of WO2001009740A1 publication Critical patent/WO2001009740A1/fr

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/14—Network analysis or design
    • H04L41/145—Network analysis or design involving simulating, designing, planning or modelling of a network
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/54—Interprogram communication
    • G06F9/541—Interprogram communication via adapters, e.g. between incompatible applications
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H04L12/2803—Home automation networks
    • H04L12/2805—Home Audio Video Interoperability [HAVI] networks
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H04L12/2803—Home automation networks
    • H04L12/2807—Exchanging configuration information on appliance services in a home automation network
    • H04L12/2809—Exchanging configuration information on appliance services in a home automation network indicating that an appliance service is present in a home automation network
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H04L12/2803—Home automation networks
    • H04L12/2807—Exchanging configuration information on appliance services in a home automation network
    • H04L12/2814—Exchanging control software or macros for controlling appliance services in a home automation network
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H04L12/2803—Home automation networks
    • H04L12/2823—Reporting information sensed by appliance or service execution status of appliance services in a home automation network
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/08—Protocols specially adapted for terminal emulation, e.g. Telnet
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/12—Protocols specially adapted for proprietary or special-purpose networking environments, e.g. medical networks, sensor networks, networks in vehicles or remote metering networks
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H04L12/2803—Home automation networks
    • H04L2012/2847—Home automation networks characterised by the type of home appliance used
    • H04L2012/2849—Audio/video appliances
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/30—Definitions, standards or architectural aspects of layered protocol stacks
    • H04L69/32—Architecture of open systems interconnection [OSI] 7-layer type protocol stacks, e.g. the interfaces between the data link level and the physical level
    • H04L69/322—Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions
    • H04L69/329—Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions in the application layer [OSI layer 7]

Definitions

  • This invention relates generally to electronic networks, and relates more particularly to a system and method for implementing device models in an electronic network.
  • 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.
  • 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 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 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.
  • Network size is also a factor that affects the management of communications in an electronic network.
  • Communications in an electronic network typically become more complex as the number of individual devices or nodes increases.
  • a particular device on an electronic network is defined as a local device with local software elements
  • other devices on the electronic network are defined as remote devices with remote software elements.
  • a local software module on the local device may need to communicate with various remote software elements on remote devices across the electronic network.
  • successfully managing a substantial number of electronic devices across a single network may provide significant benefits to a system user.
  • 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.
  • an enhanced electronic network that effectively accesses, processes, and displays digital television programming may benefit from efficient network communication techniques because of the large amount and complexity of the digital data involved. Therefore, for all the foregoing reasons, implementing an efficient method for managing communications between electronic devices in a distributed electronic network remains a significant consideration for designers, manufacturers, and users of electronic systems.
  • network software in a local host device may utilize any appropriate techniques to maintain a device model corresponding to a remote device on the electronic network.
  • a local software module in a host device may generate a device request to a device control module (DCM).
  • the DCM preferably translates the device request into an underlying device command that a remote device on the electronic network may then receive using a normal protocol.
  • the remote device then preferably returns a command acknowledge event to a local event manager using the foregoing normal protocol.
  • the command acknowledge event preferably notifies the event manager that the device command initially sent from the DCM has been received and executed by the remote device.
  • the event manager preferably includes a series of notification registrations from various software elements in the host device to request a notification message upon the occurrence of specified corresponding events.
  • the DCM initially registers with the event manager for a notification message whenever a command acknowledge event is transmitted by the remote device.
  • a model manager for a device model which corresponds to the remote device may therefore access the notification message from the event manager, and responsively update a corresponding device state in the device model.
  • the remote device preferably provides additional self- initiated notification messages to the DCM for any device state changes that are not caused by device commands from the DCM.
  • the foregoing techniques may be augmented through the use of an efficient polling process during which the device model preferably formulates and propagates a polling inquiry to the remote device using a private protocol.
  • the remote device preferably returns a polling reply to the device model in response to the polling inquiry.
  • the DCM may then advantageously utilize the polling reply to update a corresponding device state in the device model to thereby compensate for any drift or variation between the current status of the remote device and corresponding device states of the device model.
  • the remote device may also advantageously provide significant-event notifications to the DCM whenever a defined significant event occurs.
  • the DCM may thus utilize the foregoing significant-event notifications to update the device model and thereby reduce the amount of polling required to maintain the device model.
  • the device model may then be advantageously utilized by any module, element, or device to provide local information about the current status of the remote device.
  • the DCM may effectively utilize the device model to efficiently respond to various types of queries about the current status of the remote device without actually communicating directly with the remote device for every individual query.
  • the DCM may thus return a rapid query reply to a querying software module without unduly burdening the electronic network with unnecessary messaging traffic. Furthermore, the foregoing local query technique efficiently conserves valuable device resources of the remote device in order to perform other processing tasks.
  • 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 a device control module of
  • FIG. 4 in accordance with the present invention.
  • FIG. 6 is a diagram for one embodiment of the device model of FIG. 6, in accordance with the present invention.
  • FIG. 7 is a block diagram illustrating the use of a device model, in accordance with one embodiment of the present invention.
  • FIG. 8 is a flowchart of method steps for performing a query process, in accordance with one embodiment of the present invention.
  • FIG. 9 is a flowchart of method steps for maintaining a device model, in accordance with one embodiment of the present invention.
  • FIG. 10 is a flowchart of method steps for using a private protocol to poll a remote device, in accordance with one embodiment of the present invention.
  • 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.
  • 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 efficiently implementing device models in an electronic network, and preferably includes a device control module that maintains a local device model to accurately represent various device states of a remote device on the electronic network.
  • the device control module may then efficiently analyze the local device model to provide updated information about the remote device to local software modules.
  • FIG. 1 a block diagram for one embodiment of an electronic network 1 10 is shown, in accordance with the present invention.
  • 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 112(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 1 12(a) through device D 112(d)) shown 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.
  • 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 112(a), device B 112(b), device C 112(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.
  • HAVi Home Audio /Video Interoperability
  • 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).
  • full devices FD
  • intermediate devices ID
  • BD base devices
  • LD legacy devices
  • the foregoing four categories of electronic devices are further discussed below in conjunction with FIGS. 2 and 3.
  • 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.
  • 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.
  • 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.
  • processor 212 may be implemented to include any appropriate and compatible generic, multi-purpose microprocessor device.
  • FIG. 2 The FIG.
  • I/O 214 preferably provides an effective interface to facilitate communications between device 112 and network bus 120 (FIG. 1).
  • 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.
  • 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.
  • 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.
  • device application(s) 312 preferably include software instructions that are executed by processor 212 (FIG.
  • Network API 314 preferably serves as an interface between various elements of network software 316 and device application 312.
  • network software 316 preferably includes one or more software elements that are executed by processor 212 to advantageously permit device 1 12 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 1 12.
  • 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).
  • platform-specific API 322 provides an interface that preferably permits network software 316 to communicate with vendor- specific platform 324.
  • vendor- specific platform 324 may include basic operating system software for supporting low-level operations of device 1 12.
  • 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.
  • memory 216 may correspond to an intermediate device (ID) which includes only a reduced set of software elements from network software 316.
  • ID an intermediate device
  • BD base device
  • a base device preferably does include self- describing data 320 and a device driver 318.
  • a legacy device 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 1 10 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 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.
  • HAVi Home Audio/Video Interoperability
  • 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.
  • DCM device control module
  • FCMs functional control modules
  • CMS communication media manager
  • 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.
  • 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.
  • 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 110. 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 110. In the FIG.
  • SEID software element identifier
  • 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.
  • 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.
  • FCMs functional control modules
  • 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.
  • 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.
  • network bus 120 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 1 12. Each DCM manager 416 in network 1 10 may therefore maintain a current list of all devices in network 110. 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 1 10.
  • DCM 422 includes, but is not limited to, a request manager 512, a query manager 514, and a device model 516. In alternate embodiments, DCM 422 may include various elements that are different from, or in addition to, those discussed in conjunction with the FIG. 5 embodiment.
  • DCM manager 416 preferably instantiates DCM 422 in a local host device 1 12 to represent and control another hosted remote device on network 1 10.
  • the remote device is typically a base device or a legacy device, as discussed above in conjunction with FIG. 3.
  • DCM 422 preferably comprises an abstraction of the control interface of the remote device that may then be utilized to interact between a local software module and the remote device.
  • a local software module may utilize request manager 512 to control a corresponding remote device of network 110.
  • the software module preferably transmits a device request to DCM 422.
  • the remote device is a VCR
  • the software module may transmit a VCR "play" request to DCM 422.
  • DCM 422 translates the device request into an underlying device command, and then propagates the device command to the remote device for appropriate action.
  • a local software module may utilize query manager 514 to perform a query process regarding a corresponding remote device of network 1 10.
  • the software module preferably transmits a device query to DCM 422.
  • DCM 422 preferably parses the device query, and then analyzes device model 516 to return an appropriate query response to the querying software module, in accordance with the present invention.
  • device model 516 includes a local representation of various operational states and parameters of the corresponding remote device of network 1 10.
  • device model 516 may readily be implemented as part of another software element (such as FCM 423) on network 1 10, or as an independent module on network 1 10.
  • device model 516 may represent various devices on network 1 10 other than the foregoing hosted remote device. The maintenance and utilization of device model 516 is further discussed below in conjunction with FIGS. 6 through 10.
  • device model 516 includes, but is not limited to, a state data structure 612, a series of state simulation routines 616 ( state simulation routine 1 (616(a)) through state simulation routine N (616(c)), and a model manager 618.
  • device model 516 may be configured to include various elements that are different from, or in addition to, those discussed in conjunction with the FIG. 6 embodiment.
  • state data structure 612 is preferably implemented as a detailed local model of a corresponding remote device on network 1 10.
  • State data structure 612 preferably includes a series of separate device states 614 ( device state 1 (614(a)) through device state N (614(c)).
  • Each one of the device states 614 preferably corresponds to a separate functional state, parameter, attribute, or any other characteristic of the corresponding remote device.
  • a given device state 614 may correspond to a tape counter value in a remote VCR device.
  • state data structure 612 may be configured in any other appropriate manner.
  • state data structure 612 may be configured to include a detailed device state machine or various other types of detailed device representations.
  • each one of the state simulation routines 616 preferably corresponds to a separate one of the device states 614. However, certain of the device states 614 may not relate to any of the state simulation routines 616.
  • each of the state simulation routines 616 preferably comprises a series of program instructions that mimic relevant expected performance characteristics of a corresponding remote device, to thereby generate simulation update values for a given device state 614.
  • a state simulation routine 616 may mimic the expected operation of a tape counter in a VCR device, and then responsively generate simulated counter update values for a corresponding device state 614.
  • model manager 618 preferably includes a series of program instructions for controlling and managing the operation of device model 516.
  • model manager 618 may periodically perform update procedures on selected device states 614 in state data structure 612 to thereby maintain device model 516 in a current and accurate condition.
  • model manager 618 may readily be implemented as a discrete program module that is separate from device model 516. The maintenance and utilization of device model 516 is further discussed below in conjunction with FIGS. 7 through 10.
  • a local software module 712 may generate a device request to device control module (DCM) 422 via path 714.
  • DCM 422 preferably translates the device request into an underlying device command that a remote device 720 on network 110 may then receive using a normal protocol via path 716.
  • Remote device 720 then preferably returns a command acknowledge event to event manager 414 using the normal protocol via path 716.
  • the command acknowledge event preferably notifies event manager 414 that the device command initially sent from DCM 422 has been received and executed by remote device 720.
  • Event manager 414 preferably includes a series of notification registrations from various software elements in host device 1 12 to request a notification message upon the occurrence of specified corresponding events.
  • DCM 422 initially registers with event manager 414 for a notification message whenever a command acknowledge event is transmitted by remote device 720.
  • the foregoing notification message preferably includes information specifying characteristics of the device command that was received and executed by remote device 720.
  • Model manager 618 may therefore access the notification message from event manager 414 and responsively update a corresponding device state 614 in state data structure 612 to effectively maintain device model 516.
  • model manager 618 may similarly directly utilize the foregoing device request from software module 712 to update device model 516, instead of using the notification message from event manager 414.
  • remote device 720 preferably provides additional self-initiated notification messages to DCM 422 for any device state changes that are not caused by device commands from DCM 422.
  • the foregoing techniques may be augmented through the use of an efficient polling process during which device model 516 preferably formulates and propagates a polling inquiry to remote device 720 using a private protocol via path 718.
  • device model 516 may periodically poll remote device 720 to determine the actual current status of a VCR tape counter.
  • the private protocol and the normal protocol are shown on separate paths (paths 718 and 716, respectively). However, in practice, the private protocol and the normal protocol may alternately be transmitted over the same path (for example, by utilizing network bus 120).
  • Remote device 720 preferably returns a polling reply to device model 516 in response to the polling inquiry.
  • the foregoing remote VCR device would preferably return a polling reply that specifies the current status of the VCR tape counter.
  • DCM 422 may then advantageously utilize the polling reply to update the corresponding device state 614 to thereby compensate for any drift or variation between the current state of remote device 720 and corresponding device states 614 of device model 516.
  • the private protocol of the foregoing polling process may utilize any appropriate messaging techniques and preferably depends upon various specific mechanisms and characteristics associated with remote device 720.
  • remote device 720 may also advantageously provide significant-event notifications to DCM 422 whenever a defined significant event occurs. DCM 422 may thus utilize the foregoing significant-event notifications to update device model 516 and thereby reduce the amount of polling required to maintain device model 516.
  • device model 516 may be implemented as a simple abstraction of remote device 720, rather than a detailed model. In such cases, the foregoing polling process may be similarly utilized to effectively maintain the simplified version of device model 516.
  • device model 516 of DCM 422 may therefore be advantageously utilized by any appropriate module, element, or device to provide local information about the current status of remote device 720.
  • DCM 422 may effectively utilize device model 516 to efficiently respond to various types of queries about the current status of remote device 720 without actually communicating directly with remote device 720 for every individual query.
  • a software module 712 may wish to query remote device 720 at very frequent intervals, and therefore, local query analysis of device model 516 may provide significantly increased efficiency across network 110.
  • a software module 712 may propagate a device query to DCM 422 via path 714.
  • DCM 422 would then be required to perform the burdensome and time- consuming process of propagating the query to remote device 720 via path 716 (possibly at frequent intervals).
  • Remote device 720 would also be required to utilize valuable device resources to perform the query and return a query reply to DCM 422 via path 716.
  • DCM 422 may locally analyze device model 516 to efficiently perform the query from software module 712 without communicating with remote device 720. DCM 422 may thus return a rapid query reply to software module 712 without unduly burdening network 1 10 with unnecessary messaging traffic. Furthermore, the foregoing local query technique efficiently conserves valuable device resources of remote device 720 in order to performing other processing tasks.
  • DCM manager 416 instantiates a device control module (DCM) 422 corresponding to a remote device 720 on network 1 10.
  • DCM 422 preferably includes a device model 516 corresponding to remote device 720.
  • step 814 DCM 422 maintains device model 814 to accurately represent remote device 720, as discussed in conjunction with FIG. 7 and FIG. 9.
  • step 816 DCM 422 determines whether a query concerning the status of remote device 720 has been sent from a software module 712 to DCM 422. If no query has been sent, then DCM 422 continues to monitor for a query regarding remote device 720. However, in step 816, if a query concerning the status of remote device 720 has been sent from a software module 712 to DCM 422, then, in step 818, DCM 422 advantageously performs the query by analyzing local device model 516. Finally, in step 820, DCM 422 returns a query reply to the software module 712 to efficiently complete the FIG. 8 query process.
  • model manager 618 of device model 516 preferably determines and stores initial device states 614 into state data structure 612 of device model 516.
  • processor 212 of host device 1 12 begins executing the state simulation routines 616 of device model 516 to simulate various device states 614 of remote device 720. Then, in step 916, model manager 618 determines whether any new device states 614 have been received by DCM 422.
  • the foregoing new device states 614 may originate from any desired source, and may be generated using any appropriate technique.
  • DCM 422 may update devices state 614 in device model 516 using simulated update values from the state simulation routines 616 of foregoing step 914.
  • DCM 422 may also update devices state 614 by using polling reply values generated through a polling process symbolized by the reference letter "A" of FIG. 9. The foregoing polling process is further discussed below in conjunction with FIG. 10.
  • DCM 422 may update devices state 614 using any of the various techniques discussed above in conjunction with FIG. 7.
  • model manager 618 preferably determines whether new device states 614 have been received from any source. If no new device states 614 have been received, then model manager 618 continues to monitor for new device states 614. However, in step 916, if any new device states 614 have been received, then, in step 918, model manager 618 advantageously updates state data structure 612 of device model 516 with the appropriate new device states 614. The FIG. 9 process then returns to step 916, where model manager 618 continues to monitor for new device states 614 from any source.
  • step 1012 DCM 422 defines a polling threshold.
  • the foregoing polling threshold may be a finite time period that is optimized depending upon a particular corresponding device state 614.
  • step 1014 DCM 422 determines whether the defined polling threshold has been reached.
  • step 1016 if the polling threshold of step 1012 has been reached, then, in step 1016, DCM 422 preferably sends a polling inquiry to remote device 720 using a private protocol, as discussed above in conjunction with FIG. 7.
  • step 1018 DCM 422 advantageously receives a polling reply from remote device 720 using the foregoing private protocol.
  • the FIG. 10 method then proceeds to reference letter "A" which is located immediately prior to step 916 of FIG. 9.

Abstract

La présente invention concerne un système et un procédé, destinés à mettre en place des modèles de dispositifs (516) dans un réseau électronique (110), comprenant un module de commande de dispositif (422) qui permet à un modèle de dispositif local (516) de représenter précisément des états variés de dispositif (614) d'un dispositif distant (720) sur le réseau électronique (110). Le module de commande de dispositif (422) peut alors analyser efficacement le modèle de dispositif local (516) afin de communiquer au module logiciel local (714) une information à jour à propos du dispositif distant (720).
PCT/US2000/021037 1999-08-03 2000-08-02 Systeme et procede destines a la mise en place de modeles de dispositifs dans un reseau electronique WO2001009740A1 (fr)

Priority Applications (3)

Application Number Priority Date Filing Date Title
JP2001514681A JP2003506779A (ja) 1999-08-03 2000-08-02 電子ネットワークにおける機器モデルの実現システム及び方法
AU63962/00A AU6396200A (en) 1999-08-03 2000-08-02 System and method for implementing device models in an electronic network
EP00950934A EP1125215A1 (fr) 1999-08-03 2000-08-02 Systeme et procede destines a la mise en place de modeles de dispositifs dans un reseau electronique

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US36665799A 1999-08-03 1999-08-03
US09/366,657 1999-08-03

Publications (1)

Publication Number Publication Date
WO2001009740A1 true WO2001009740A1 (fr) 2001-02-08

Family

ID=23443956

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/US2000/021037 WO2001009740A1 (fr) 1999-08-03 2000-08-02 Systeme et procede destines a la mise en place de modeles de dispositifs dans un reseau electronique

Country Status (4)

Country Link
EP (1) EP1125215A1 (fr)
JP (1) JP2003506779A (fr)
AU (1) AU6396200A (fr)
WO (1) WO2001009740A1 (fr)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2005018193A1 (fr) * 2003-07-17 2005-02-24 Abb Research Ltd. Procede et systeme de transmission d'evenements
CN100372328C (zh) * 2000-06-30 2008-02-27 诺基亚公司 控制设备的网络和方法

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5592620A (en) * 1993-08-12 1997-01-07 International Business Machines Corporation System and method for controlling, monitoring and retrieving accounting data
US5764913A (en) * 1996-04-05 1998-06-09 Microsoft Corporation Computer network status monitoring system
US5862404A (en) * 1997-02-12 1999-01-19 Toshiba America Information Systems, Inc. Network device discovery and status information distribution using independent information distribution processes
US6003064A (en) * 1996-02-22 1999-12-14 Fujitsu Limited System and method for controlling data transmission between network elements

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5592620A (en) * 1993-08-12 1997-01-07 International Business Machines Corporation System and method for controlling, monitoring and retrieving accounting data
US6003064A (en) * 1996-02-22 1999-12-14 Fujitsu Limited System and method for controlling data transmission between network elements
US5764913A (en) * 1996-04-05 1998-06-09 Microsoft Corporation Computer network status monitoring system
US5862404A (en) * 1997-02-12 1999-01-19 Toshiba America Information Systems, Inc. Network device discovery and status information distribution using independent information distribution processes

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN100372328C (zh) * 2000-06-30 2008-02-27 诺基亚公司 控制设备的网络和方法
WO2005018193A1 (fr) * 2003-07-17 2005-02-24 Abb Research Ltd. Procede et systeme de transmission d'evenements
US8005941B2 (en) 2003-07-17 2011-08-23 Abb Research Ltd Method and system for event transmission

Also Published As

Publication number Publication date
AU6396200A (en) 2001-02-19
JP2003506779A (ja) 2003-02-18
EP1125215A1 (fr) 2001-08-22

Similar Documents

Publication Publication Date Title
US6314447B1 (en) System uses local registry and load balancing procedure for identifying processing capabilities of a remote device to perform a processing task
US7305680B2 (en) Listening module for asynchronous messages sent between electronic devices of a distributed network
JP3977596B2 (ja) ネットワーク環境内の自律媒体装置を制御し、自律媒体装置間のデータフロー及びデータフォーマットを管理する媒体管理装置
TW406509B (en) A home audio/video network with updatable device control modules
US6349352B1 (en) Home audio/video network with both generic and parameterized device control
KR20010033849A (ko) 오디오 비디오 네트워크
EP1169812B1 (fr) Decouverte de diffusion dans un reseau pourvu d'un ou plusieurs bus 1394
KR20010033879A (ko) 오디오/비디오 네트워크 및 이에 관련된 제어 방법
US7187661B2 (en) Gathering of device discovery information
WO2000026876A1 (fr) Dispositif et procede concernant les connexions internes d'un systeme audio/video
CA2317801A1 (fr) Appareil audio-video
US6298069B1 (en) System and method for implementing self-device control modules in an electronic network
US6477573B1 (en) System and method for performing a hierarchical remote query in an electronic network
US20050021852A1 (en) Gateway and method for the interconnection of two networks, especially a HAVi network and an UPnP network
US6542474B1 (en) System and method for incrementally updating remote element lists in an electronic network
JP2002304337A (ja) 高性能ＨＡＶｉ準拠機器実施のためのシステム及び方法
US8176343B2 (en) Method for providing information for power management of devices on a network
JP2001512927A (ja) ヒューマンインターフェイスの特徴記述方法及びａｖ／ｃ対応装置の機能
US6560635B1 (en) System and method for locally caching remote query replies in an electronic network
KR100371166B1 (ko) 홈 네트워크 접속 장치 및 그의 제어 방법
EP1125215A1 (fr) Systeme et procede destines a la mise en place de modeles de dispositifs dans un reseau electronique
WO2001020426A2 (fr) Methodologie permettant de decouvrir les fonctions etendues d'un dispositif d'un reseau electronique
CN101785245B (zh) 根据控制点的连接状态管理通用即插即用设备的资源的方法和装置
WO2000051289A2 (fr) Systeme et procede de mise en oeuvre de registres actifs dans un reseau electronique
WO2000062479A2 (fr) Systeme et procede de tenue a jour de registres totalement dupliques dans un reseau electronique

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A1

Designated state(s): AE AL AM AT AU AZ BA BB BG BR BY CA CH CN CR CU CZ DE DK DM EE ES FI GB GD GE GH GM HR HU ID IL IN IS JP KE KG KP KR KZ LC LK LR LS LT LU LV MA MD MG MK MN MW MX NO NZ PL PT RO RU SD SE SG SI SK SL TJ TM TR TT TZ UA UG UZ VN YU ZA ZW

AL Designated countries for regional patents

Kind code of ref document: A1

Designated state(s): GH GM KE LS MW MZ SD SL SZ TZ UG ZW AM AZ BY KG KZ MD RU TJ TM AT BE CH CY DE DK ES FI FR GB GR IE IT LU MC NL PT SE BF BJ CF CG CI CM GA GN GW ML MR NE SN TD TG

ENP Entry into the national phase

Ref country code: JP

Ref document number: 2001 514681

Kind code of ref document: A

Format of ref document f/p: F

WWE Wipo information: entry into national phase

Ref document number: 2000950934

Country of ref document: EP

121 Ep: the epo has been informed by wipo that ep was designated in this application
WWP Wipo information: published in national office

Ref document number: 2000950934

Country of ref document: EP

REG Reference to national code

Ref country code: DE

Ref legal event code: 8642

WWW Wipo information: withdrawn in national office

Ref document number: 2000950934

Country of ref document: EP