Synchronization of controlled device state using state table and eventing in data-driven remote device control model

Abstract

Controlled devices according to a device control model maintain a state table representative of their operational state. Devices providing a user control point interface for the controlled device obtain the state table of the controlled device, and may also obtain presentation data defining a remoted user interface of the controlled device and device control protocol data defining commands and data messaging protocol to effect control of the controlled device. These user control devices also subscribe to notifications of state table changes, which are distributed from the controlled device according to an eventing model. Accordingly, upon any change to the controlled device's operational state, the eventing model synchronizes the device's state as represented in the state table across all user control devices.

Claims

We claim:

1. A distributed computing network having at least one computing device, the distributed computing network comprising:

a controlled computing device;

a state table maintained by the controlled computing device and representing an operational state of the controlled computing device;

a user controller device having user input/output capability for presenting a user perceptible device control interface for remote user interaction with the controlled computing device to effect a change in the operational state of the controlled computing device represented in the state table;

a user control point module in the user controller device operating to obtain a copy of the state table of the user controller device and subscribe to change notifications of the state table; and

an event source module in the controlled computing device operating according to an eventing model to distribute the change notifications to any subscribing user controller device upon a change to the state table representing the operational state of the controlled computing device, wherein the change notifications represent the respective change in the state table, so as to thereby synchronize the user perceptible device control interface with the changed operational state among said any subscribing user controller device.

2. The distributed computing network of claim 1 further comprising:

the state table having a plurality of entries, wherein each entry of the state table comprises at least a variable identifier, a type and a current value;

at least one entry of the state table being of a type of data buffer, and containing a file as its current value;

whereby a change to the current value of said at least one entry effects a file transfer from the controlled device to said any subscribing user control device.

3. The distributed computing network of claim 1 wherein the controlled computing device is an embedded computing device.

4. The distributed computing network of claim 1, further comprising a computer-readable medium controlled computing device having encoded thereon the state table representing the operational state of the controlled computing device, the state table comprising:

a plurality of entries, each entry comprising:

a variable identifier; and

a current value.

5. The distributed computing network of claim 4 wherein each entry of the state table further comprises:

a variable type;

a designation of legal values; and

a designation of a default value.

6. The distributed computing network of claim 5 wherein the variable type can include a data buffer containing a file, whereby transmission of the state table between devices effects transfer of the file.

7. In a distributed computing network having a controlled computing device, a state table maintained by the controlled computing device and representing an operational state of the controlled computing device, a user controller device having user input/output capability for presenting a user perceptible device control interface for remote user interaction with the controlled computing device and communicating with the controlled computing device via a device control protocol to effect remote operational control of the controlled computing device, a user control point module in the user controller device operating to obtain the state table of the user controller device and subscribe to change notifications of the state table, and an event source module operating according to an eventing model to distribute the change notifications to any subscribing user controller device upon a change to the operational state of the controlled computing device, so as to thereby synchronize the user perceptible device control interface with the changed operational state among said any subscribing user controller device, a method of maintaining data representing a current state of the controlled computing device at the user controller device, the method comprising:

responsive to a controlled device state subscription request of the user controller device per a subscription eventing model, distributing an initial controlled computing device state event having a predefined initial sequence number and data defining a present state of the controlled computing device to the user controller device;

upon changes in the controlled device state, distributing controlled computing device state update events having sequence numbers assigned according to a sequential order following the predefined initial sequence number and data defining said changes to the user controller device; and

in response to a renewed controlled device state subscription request, recommencing distributing the initial controlled computing device state event and controlled computing device state update events to the user controller device so as to permit the user controller device to reinitialize to the controlled computing device's present state upon failure to receive the controlled computing device state update events in sequential order of their assigned sequence numbers.

8. The method of claim 7 wherein the predefined initial sequence number is zero.

9. The method of claim 7 wherein the data in the initial controlled computing device state event is a complete state table defining the controlled computing device's present state, and the data in the controlled computing device state update events define updates in part of the state table.

10. A controlled computing device operational in accordance with the method of claim 7.

11. In a distributed computing network having a controlled computing device, a state table maintained by the controlled computing device and representing an operational state of the controlled computing device, a user controller device having user input/output capability for presenting a user perceptible device control interface for remote user interaction with the controlled computing device and communicating with the controlled computing device via a device control protocol to effect remote operational control of the controlled computing device, a user control point module in the user controller device operating to obtain the state table of the user controller device and subscribe to change notifications of the state table, and an event source module operating according to an eventing model to distribute the change notifications to any subscribing user controller device upon a change to the operational state of the controlled computing device, so as to thereby synchronize the user perceptible device control interface with the changed operational state among said any subscribing user controller device, a method of maintaining data representing a current state of the controlled computing device at the controller computing device, the method comprising:

sending from the user controller device a state subscription request conforming to a subscription eventing model by which the controlled computing device distributes sequentially numbered state events to subscribing devices commencing with an initial state event that conveys a full data representation of a state of the controlled computing device and continuing with state update events that convey partial updates of the controlled computing device state;

upon receiving the initial state event, initializing storage at the user controller device of a representation of the controlled computing device's state with the full data representation in the initial state event;

upon receiving state update events, updating the storage with the partial updates; and

upon a failure to receive a state update event in accordance with their sequential numbering, repeating the actions of sending the state subscription request, initializing the storage and updating the storage.

12. The method of claim 11 wherein the sequential numbering of the state events begins with a predefined initial sequence number.

13. The method of claim 11 wherein the data representation of the controlled computing device's state is in the form of a state table.

14. The method of claim 11 further comprising:

producing a user control interface display at the user controller device based at least in part on the representation of the controlled computing device's state in the storage.

15. The method of claim 11 further comprising:

sending from the user controller device a control command for an operation of the controlled computing device depending at least in part on the representation of the controlled computing device's state in the storage.

16. A user controller device operational in accordance with the method of claim 11.

17. A computer readable software carrying medium having computer software carried thereon for implementing a peer networking control protocol for a plurality of control point computing devices in a distributed data communications network to effect control of a controlled computing device, the distributed data communications network having the controlled computing device, a state table maintained by the controlled computing device and representing an operational state of the controlled computing device, a control point computing device having user input/output capability for presenting a user perceptible device control interface for remote user interaction with the controlled computing device and communicating with the controlled computing device via a device control protocol to effect remote operational control of the controlled computing device, a user control point module in the control point computing device operating to obtain the state table of the control point computing device and subscribe to change notifications of the state table, and an event source module operating according to an eventing model to distribute the change notifications to any subscribing control point computing device upon a change to the operational state of the controlled computing device, so as to thereby synchronize the user perceptible device control interface with the changed operational state among said any subscribing control point computing device, the computer software comprising:

a subscription registration program module operative when executed on the controlled computing device to register, in response to a subscription request of the control point computing device, such device as a subscribing control point computing device to receive state events from the controlled computing device;

a state eventing program module operative when executed on the controlled computing device to distribute state events to the subscribing control point computing device, and further operative to assign sequence numbers to the state events in sequential order, the state events commencing with an initial state event having data for initializing a controlled computing device state table stored at the subscribing control point computing device to reflect a then present state of the controlled computing device, the state events continuing with state update events having data for updating the controlled computing device state table to reflect a changed state of the controlled computing device; and

the subscription registration program module further operative in response to a renewed subscription request of the subscribing control point device to cause the state eventing program module to recommence distributing a further sequence of initial state event and state update events to the subscribing control point computing device so as to permit the subscribing computing device to reinitialize its stored controlled computing device state table after failure to receive the state update events in sequence.

18. A computer readable software carrying medium having computer software carried thereon for implementing a peer networking control protocol for a plurality of control point computing devices in a data communications network to effect control of a controlled computing device, the data communications network having the controlled computing device, a state table maintained by the controlled computing device and representing an operational state of the controlled computing device, a control point computing device having user input/output capability for presenting a user perceptible device control interface for remote user interaction with the controlled computing device and communicating with the controlled computing device via a device control protocol to effect remote operational control of the controlled computing device, a user control point module in the control point computing device operating to obtain the state table of the control point computing device and subscribe to change notifications of the state table, and an event source module operating according to an eventing model to distribute the change notifications to any subscribing control point computing device upon a change to the operational state of the controlled computing device, so as to thereby synchronize the user perceptible device control interface with the changed operational state among said any subscribing control point computing device, the computer software comprising:

a state subscriber program module operative when executed on a control point computing device to communicate from the control point computing device a state subscription request conforming to a subscription eventing model of the peer networking control protocol by which the controlled computing device distributes sequentially numbered state events to subscribing devices commencing with an initial state event that conveys a full data representation of a state of the controlled computing device and continuing with state update events that convey partial updates of the controlled computing device state;

a controlled device state storage initialization program module operative when executed on the control point computing device to in response to the initial state event to initialize storage at the control point computing device of a data structure representation of the controlled computing device's state according to the full data representation in the initial state event;

a controlled device state update program module operative when executed on the control point computing device to in response to the state update events to update the data structure representation in the storage according to the partial updates in the state update events; and

a sequence validation program module operative when executed on the control point computing device to detect a failure to receive any of the state events as per their sequential numbering, and operative upon detecting such failure to cause the state subscriber program module to communicate a renewal state subscription request from the control point computing device so as to re-commence distribution of sequentially numbered state events with a renewed initial state event from the controlled computing device in conformance with the subscription eventing model and thereby effect re-initialization of the data structure representation by the controlled device state storage initialization program module.

19. The computer readable software carrying medium of claim 18 further comprising:

a user control interface display program module operative when executed on the control point computing device to display a user control interface display at the control point computing device based at least in part on the stored data structure representation of the controlled computing device's state.

20. A peer networking state eventing and control protocol method for effecting state-concurrent multi-master control of a controlled computing device by a plurality of control point computing devices communicating on a data communications network, the data communications network having the controlled computing device, a state table maintained by the controlled computing device and representing an operational state of the controlled computing device, a control point computing device having user input/output capability for presenting a user perceptible device control interface for remote user interaction with the controlled computing device and communicating with the controlled computing device via a device control protocol to effect remote operational control of the controlled computing device, a user control point module in the control point computing device operating to obtain the state table of the control point computing device and subscribe to change notifications of the state table, and an event source module operating according to an eventing model to distribute the change notifications to any subscribing control point computing device upon a change to the operational state of the controlled computing device, so as to thereby synchronize the user perceptible device control interface with the changed operational state among said any subscribing control point computing device, the method comprising:

from a plurality of the control point computing devices, receiving state eventing subscription requests;

responsive to the state eventing subscription requests, registering subscriptions of the respective control point computing devices to state events from the controlled computing device;

communicating state events having information descriptive of a state of the controlled computing device to the respective control point computing devices of the registered subscriptions;

receiving a control command from a control point computing device instructing the controlled computing device to perform a specified operation affecting the state of the controlled computing device;

responsive to the control command, performing the specified operation; and

communicating further state events having information descriptive of the state of the controlled computing device after the specified operation is performed to the respective control point computing devices of the registered subscriptions, whereby the plurality of control point computing devices having registered subscriptions can maintain concurrent storage of data representing the state of the controlled computing device.

21. The peer networking state eventing and control protocol method of claim 20 further comprising:

responsive to a state eventing subscription request of a control point computing device, communicating an initial state event having data defining a full data structure representation of the state of the controlled computing device upon registering the subscription of the control point computing device;

upon changes in the state of the controlled computing device, communicating state update events having data defining changes to the data structure representation of the state of the controlled computing device, wherein the initial state event and state update events have sequence numbers assigned in sequential order; and

in response to a renewed state eventing subscription request, repeating the communicating of initial state event and state update events, whereby the control point computing device can reinitialize storage of the data structure representation of the state of the controlled computing device after failure to receive the state update events in sequential order of their assigned sequence numbers.

22. The peer networking state eventing and control protocol method of claim 20 further comprising assigning the sequence number of the initial state event and state update events commencing with a predefined sequence number for the initial state event.

Description

TECHNICAL FIELD

This invention relates generally to dynamic connectivity among distributed devices and services, and more particularly relates to providing a capability to access device- or service-specific operational information and perform remote automation and control of embedded computing devices using a data-driven remote programming model, such as in a pervasive computing environment

BACKGROUND AND SUMMARY

The cost of computing and networking technologies have fallen to the point where computing and networking capabilities can be built into the design of many electronic devices in the home, the office and public places. The combination of inexpensive and reliable shared networking media with a new class of small computing devices has created an opportunity for new functionality based mainly on the connectivity among these devices. This connectivity can be used to remotely control devices, to move-digital data in the form of audio, video and still images between devices, to share information among devices and with the unconstrained World Wide Web of the Internet (hereafter "Web") and to exchange structured and secure digital data to support things like electronic commerce. The connectivity also enables many new applications for computing devices, such as proximity-based usage scenarios where devices interact based at least in part on geographical or other notions of proximity. A prevalent feature of these connectivity scenarios is to provide remote access and control of connected devices and services from another device with user interface capabilities (e.g., a universal remote controller, handheld computer or digital assistant, cell phones, and the like). These developments are occurring at the same time as more people are becoming connected to the Internet and as connectivity solutions are falling in price and increasing in speed. These trends are leading towards a world of ubiquitous and pervasive networked computing, where all types of devices are able to effortlessly and seamlessly interconnect and interact.

As just mentioned, a large number of usage scenarios in pervasive networked computing involve ad hoc remote control of operational functionality of various other devices from a device with user data input/output capabilities. For example, in some usage scenarios, a device with user interface capabilities controls an exchange of data between image, video, and audio capture devices (e.g., cameras and recorders) and recording, play-back and presentation devices (e.g., a television, printer, and data storage devices). In these scenarios, the user interface experience of a controlled device's physical control panel (e.g., the buttons, knobs and display of an audio/video equipment's front panel and infrared remote) are desirably remoted to other user interface capable control devices.

In accordance with a technology described herein, controlled devices in a device control model maintain a state table representative of their operational state. Devices that provide a user interface or user control point for the controlled device obtain the state table of the controlled device, and may also obtain presentation data defining presentation of the remoted user interface of the controlled device and device control protocol data defining commands and data messaging to effect control of the controlled device. These user control point devices also subscribe to notifications of state table changes, which are distributed from the controlled device according to an eventing model. Accordingly, upon any change to the controlled device's operational state caused by user inputs from any user control point device or even the controlled device's front panel or infrared remote, the device's state as represented in the state table is synchronized across all these user control point devices using the eventing model.

The device state table and eventing model enable dynamic and automatic synchronization of the device state among all interested controllers that subscribe to notifications of the controlled device's state upon a change in the controlled device's state, whether the device commands that cause a change in device state originate from other user control point devices or directly through front panel or infrared remote of the controlled device itself. This synchronization of the controlled device's state among all user control point devices that provide a user interface to the controlled device allows these user control point devices to present a consistent and correct depiction of the controlled device's state in their user interface. This way the user is able to interact appropriately to the actual current state of the device, e.g., avoiding issuing a "toggle power on/off" command when the controlled device's power already is on. The controlled device thus is able to truly remote its direct front panel/infrared remote user interface as a virtual user interface on other user control point devices in a distributed network.

The device state table also may contain entries that are a byte block or data buffer, in which a file can be loaded. In such embodiments, the device state table and eventing model enable a file transfer from the controlled device to interested subscribing devices via loading of the file into the data buffer entry of the device state table. Since the eventing model can broadcast any change to the data state table, the eventing model can effect an immediate file transfer upon any change in the file. Further, multiple files can be transferred by loading one at a time into this data buffer entry of the device state table.

Additional, features and advantages will be made apparent from the following detailed description of the illustrated embodiment which proceeds with reference to the accompanying drawings.

BRIEF DESCRIPTION OF THE DRAWINGS

FIGS. 1 and 2 are block diagrams of a device architecture per Universal Plug and Play using user control points, controlled devices and bridges for connectivity between devices.

FIG. 3 is a block diagram of a device model per Universal Plug and Play.

FIG. 4 is a block diagram illustrating example devices conforming to the device model of FIG. 3.

FIG. 5 is a block diagram illustrating device state synchronization using a state table and eventing.

FIG. 6 is a block diagram illustrating device addressing.

FIG. 7 is a block diagram of a programmatic interface-to-network messaging adapter or Rehydrator in the device control model of FIG. 3.

FIG. 8 is a general data flow diagram of the Rehydrator of FIG. 7 in the device control model of FIG. 3.

FIG. 9 is a block diagram of an implementation design of the Rehydrator of FIG. 7.

FIGS. 10 and 11 are block diagrams illustrating an internal software architecture of the user control point and controlled device in the device control model of FIG. 3.

FIG. 12 is a block diagram illustrating an internal software architecture of a combined bridge and user control point in the device control model of FIG. 3.

FIG. 13 is a data flow diagram illustrating a typical browsing protocol sequence in the device control model of FIG. 3.

FIG. 14 is a listing showing a layout of a description document in the device control model of FIG. 3.

FIG. 15 is a listing of an exemplary icon list of a Description Document in the device control model of FIG. 3.

FIG. 16 is a listing of an exemplary service control protocol declaration in a Description Document in the device control model of FIG. 3.

FIGS. 17, 18, and 19 are a listing of an exemplary contract in the device control model of FIG. 3.

FIGS. 20 and 21 are a listing of an XML schema for a Service Control Protocol Declaration Language used in the device control model of FIG. 3.

FIG. 22 is a block diagram of an eventing model used in the device control model of FIG. 3.

FIG. 23 is a data flow diagram illustrating subscription, notification and unsubscription in the eventing model of FIG. 22.

FIG. 24 is a block diagram of a computer system that may be used in the device control model of FIG. 3.

FIG. 25 is a block diagram of a device having embedded computing and networking capability per universal-plug-and-play (UPNP) standards that may be used in combination with the computer system of FIG. 24 in the device control model of FIG. 3.

FIG. 26 is a block diagram of a software architecture per UPNP standards in the embedded computing device of FIG. 25

FIG. 27 is a data flow diagram of a process for automatic network introduction of the embedded computing device of FIG. 25 into an ad hoc computer network environment per the UPNP protocol.

FIG. 28 is a data flow diagram of a process for automatic network introduction of the embedded computing device of FIG. 25 into a configured computer network environment per the UPNP protocol.

FIG. 29 is a block diagram of a software architecture of a client device per UPNP standards having embedded computing and networking capability that may be used in the device control model of FIG. 3.

FIG. 30 is a block diagram of an exemplary home or office pervasive computing environment having a variety of computers as per FIG. 24 and embedded computing devices as per FIG. 25 interconnected per UPNP standards that may be used in the device control model of FIG. 3.

FIGS. 31 through 43 are program listings of interfaces used in the Rehydrator implementation design of FIG. 9.

FIGS. 44-46 are an XML format listing that depicts an exemplary contract for interacting with a stock quote Service.

FIGS. 47-50 are an XML format listing that depicts an XML schema for defining Contracts.

DETAILED DESCRIPTION

The following detailed description is directed toward a device state representation and device state eventing in a distributed device control model. In one described implementation, this device state and eventing is used in a device architecture 100 (FIG. 1), connectivity model, and device control protocol proposed by Microsoft Corporation, called Universal Plug and Play ("UPnP").

Universal Plug and Play

Universal Plug and Play (UPnP) is an open network architecture that is designed to enable simple, ad hoc communication among distributed devices and services from many vendors. UPnP leverages Internet technology and can be thought of as an extension of the Web model of mobile web browsers talking to fixed web servers to the world of peer-to-peer connectivity among mobile and fixed devices. UPnP embraces the zero configuration mantra of Plug and Play (PnP) but is not a simple extension of the PnP host/peripheral model.

The cost, size and battery consumption of computing technology--including processing, storage and displays--continues to fall. This trend is enabling the evolution of stand-alone, single or limited function computing devices such as digital cameras, audio playback devices, smart mobile phones and handheld computers. Concurrent with this, the economical storage and transmission of digital audio, video and still images is enabling highly flexible models for managing entertainment content.

While many of these devices are capable of useful stand-alone operation, seamless connectivity with the PC can enhance the value to the customer of both stand-alone devices and the PC. Good examples of this synergy are digital image capture combined with PC image manipulation, storage and email transfer/web publishing and information synchronization between a PC and a handheld computer or smart mobile phone.

Since many of these devices, and the PC itself, are mobile, a suitable communication architecture must enable a highly dynamic connectivity model and must enable peer-to-peer operating among arbitrary combinations of devices.

The Internet has created a widespread awareness of the value of simple, universal communication that is independent of the underlying transmission technology and independent of technology from any single vendor.

UPnP makes it possible to initiate and control the transfer of bulk data (e.g. files) or A/V data streams from any device on the network, to any device on the network, under the control of any device on the network. UPnP enables the ad hoc addition or removal of devices on the network, and it enables multiple controlling devices to remain in sync with each other.

UPnP reuses existing protocols and technology whenever possible. The transition to this highly connected (and connectable) world will not occur overnight. UPnP builds on existing Internet protocols, but accommodates devices that cannot run the complete UPnP protocol suite. UPnP provides an architecture that enables legacy devices to communicate with UPnP devices.

IP internetworking has been chosen as a UPnP baseline due to its proven ability to span different physical media, to enable real world multiple vendor interoperation and to achieve synergy with the Internet and home and office intranets. Internet synergy enables applications such as IP telephony, multiple player games, remote control of home automation and security, Internet based electronic commerce, in addition to simple email and web browsing. UPnP's scope includes remote control of devices and bulk data transfer. But, it does not specify A/V streaming formats or protocols.

UPnP's media independence enables a great deal of flexibility in the packaging of products. UPnP enables an A/V system to be controlled through an A/C power communications technology, while the transmission of A/V streams among the components is analog or digital. One of the controllers of this system could be on the television, while another is on a PC, and yet another connected via radio or infrared.

Unlike Plug and Play, Universal Plug and Play is built on top of networking and enables ad hoc peer-to-peer connectivity. Networking, in this context, describes a style of connectivity that enables any networked device to initiate a communication with any other networked device, without having established a prior relationship or maintaining a persistent relationship between the devices. Networking also allows multiple devices to establish one or more connections with a single device, and it allows for a device to be capable of both initiating and accepting connections to/from other devices. The PnP, or host/peripheral, model is suitable whenever there is a natural persistent relationship between two devices (e.g. a keyboard, mouse and display maintain and a persistent relationship with a host computer). Even though networking does not mandate low level persistent relationships, it provides the needed anchors (addresses) for applications to choose to maintain associations as a convenience for the customer (e.g. remembering commonly used networked printers).

In order to achieve multiple vendor peer-to-peer interoperation among devices, vendors desirably agree on common technology and standards up to the highest level of desired functional interoperation.

UPnP leverages formal protocol contracts to enable peer-to-peer interoperation. Protocols contracts enable real-world multiple-vendor interoperation.

UPnP enables devices to expose a user interface by leveraging browser technology. In this context, the browser can be considered to be a very rich remote terminal. Current browser technology does not maintain a separation of presentation from data, or in the case of devices, control. It is possible to hunt through a page of HTML to extract data values, but it is not convenient or robust. UPnP leverages the separation of presentation and data enabled by the use of XML, and it extends this technology to the device control domain.

UPnP provides a device-driven auto-configuration capability that preserves the experience that customers have on the web. Today, it is possible to navigate around the web without loading programs beyond the browser itself. Since UPnP enables the browser to be extended to control devices, and because UPnP devices are controlled with explicit protocols, the browser must somehow learn how to talk to UPnP devices. This learning process is driven entirely from the device itself and is accomplishing entirely by uploading an XML document that describes the capabilities of the device. The architectural component that enables device-driven auto-configuration is called the Rehydrator. The job of the Rehydrator is to convert between APIs and protocols.

Since the auto-configuration process itself is driven only by the exchange of formatted data, there is very little opportunity for a malicious attack from a hostile piece of code.

There are some scenarios where the web UI model is not sufficient for a rich customer experience. It would not be convenient to have to a web for each light switch in a house. To support a rich user interface and to enable the aggregation of devices into a single UI, UPnP enables application control in addition to browser control of devices. This is achieved simply by enabling applications to call the same Rehydrator APIs that the browser does. Applications can also directly generate and consume the raw UPnP control protocols, provided they are not interested in the device-driven auto-configuration enabled by the Rehydrator.

UPnP assumes that there will be more than one device with UI that wants to control other devices in any given network, and it provides a simple mechanism that enables these control points to remain in sync. This mechanism can easily support device front panels and wireless remotes that do not run UPnP protocols. The UPnP control model is third-party control; any device can transfer bulk data (e.g. files) or A/V data streams from any device on the network, to any device on the network, under the control of any device on the network.

Terminology

The detailed description that follows uses the terminology defined below.

Module. A component of a device, software program, or system that implements some "functionality", which can be embodied as software, hardware, firmware, electronic circuitry, or etc.

User Control Point. The set of modules that enable communication with a UPnP Controlled Device. User Control Points initiate discovery and communication with Controlled Devices, and receive Events from Controlled Devices. User Control Points are typically implemented on devices that have a user interface this user interface is used to interact with Controlled Devices over the network. The modules minimally include a Discovery Client, a Description Client and a Rehydrator. User Control Points may also include Visual Navigation, an Event Subscription Client, Event Sink, a web browser and an application execution environment. User Control Points can add value to the network by aggregating the control of multiple Controlled Devices (the universal remote) or they can implement a function as simple as initiating the transfer of data to or from a Controlled Device. Examples of devices that could be User Control Points are the personal computer (PC), digital television (DTV), set-top box (STB), handheld computer and smart mobile phone, and the like. Nothing prevents a single device from implementing the functionality of a User Control Point and one or more Controlled Devices at the same time.

Controlled Device. The set of modules that enable communication with a User Control Point. Controlled Devices respond to discovery requests, accept incoming communications from User Control Points and may send Events to User Control Points. Devices that support Controlled Device functionality may also support local user interfaces such as front panel displays or wireless remotes. The modules minimally include a Discovery Server, a Description Server and a Control Server. Controlled Devices may also include a Presentation (web) Server, Event Subscription Server and Event Source. Examples of devices that could be Controlled Devices are the VCR, DVD player or recorder, heating/ventilation/air-conditioning equipment (HVAC), lighting controller, audio/video/imaging playback device, handheld computer, smart mobile phone and the PC, and the like. Nothing prevents a single device from implementing the functionality of a User Control Point and one or more Controlled Devices at the same time.

Bridge. A set of modules that enables Bridged and Legacy Devices to interact with native UPnP devices. The bridge itself exposes a collection of UPnP Controlled Devices to User Control Points. The Bridge maps between native UPnP Device Control Protocols and the underlying protocols exposed by the Bridged and Legacy Devices. Optionally, such a device could expose UPnP Controlled Devices to Legacy Devices in the manner required by the Legacy Devices. Nothing prevents a single device from implementing the functionality of a User Control Point, one or more Controlled Devices and a Bridge at the same time.

Service Provider. A module used by a UPnP Bridge that translates between UPnP protocols and the protocols used by Bridged and Legacy Devices. No Service Providers are required for communication among native UPnP devices.

Bridged Device. A device that cannot participate in UPnP at the native protocol level, either because the device does not have sufficient resources or because the underlying media is unsuitable to run TCP and HTTP. Examples of devices that could be Bridged Devices are power line-controlled AN equipment, light switches, thermostats, wristwatches and inexpensive toys. Bridged Devices are UPnP complaint and are exposed to other UPnP devices through a UPnP Bridge.

Legacy Device. Any non-UPnP compliant device that must be exposed to other UPnP devices through a UPnP Bridge.

Device Model. The UPnP model of Controlled Devices. The Device Model includes the addressing scheme, Description Document, Devices and Services hierarchy and the functional description of modules.

Device Control Protocol (DCP). A complete set of UPnP protocols and schemas used to interact with a UPnP Controlled Device.

Device Definition. The formal definition of a Device Type. A Device Definition includes a Device Type Identifier, the fixed elements in the Description Document, the required set of Service Definitions in the Root Device, and the hierarchy of required Devices and Service Definitions.

Service Definition. The formal definition of a Service Type. A Service Definition includes a Service Type Identifier, definition of the Service State Table (SST), definition of the Service Command Set, the Service Control Protocol (SCP) and Service Control Protocol Declaration (SCPD).

Device. In the context of the Device Model, a container for Services. A Device generally models a physical entity such as a VCR, but can also represent a logical entity. A PC emulating the traditional functions of a VCR would be an example of a logical device. Devices can contain other Devices. An example would be a TV/VCR packaged into a single physical unit. UPnP enables the association of user interface (display icon and root web page) with every Device, including Root Device.

Root Device. The topmost Device in a hierarchy of nested Devices. A Device with no nested Devices is always a Root Device.

Device Type. A relatively high level classification of Devices with common functionality. Device Type is intended to enable Devices to be simply and automatically grouped for presentation. An example of a Device Type is "VCR". Device Types are formally defined in terms of a required set of Service Definitions of minimum version that a compliant Device must support. UPnP supports searches for all Devices of a specified Device Type.

Device Type Identifier. A unique identifier that identifies a Device Definition. This identifier adheres to the format of a Uniform Resource Identifier (URI). See, T. Berners-Lee, R. Fielding, L. Masinter, "Uniform Resource Identifiers (URI): Generic Syntax", which can be found at http://www.ietf.org/rfc/rfc2396.txt.

Device Friendly Name. A human readable string that is initialized by vendors at the time of manufacturer of a Device. Every Device, including Root Devices, has a Device Friendly Name. A typical Device Friendly Name will contain manufacturer and model information, and is used to enable a more precise identification of a UPnP Device from the set of discovered Devices. Once identified, the Unique Device Name (UDN) can be used to unambiguously identify the same Device in the future. UPnP enables Device Friendly Names to be changed by User Control Points. The Device Friendly Name should not be used as device identifier.

Unique Device Name (UDN). The fundamental identifier of a Device. Every Device, including Root Devices, has exactly one UDN. The UDN is globally unique and permanent, even across power cycles and physical location changes. The UDN is the only UPnP device identifier guaranteed never to change. UPnP enables searches for devices by UDN.

Description Document. A structured unit of data that is used by a User Control Point or UPnP Bridge to learn the capabilities of a Controlled Device. Description Documents are retrieved from the Description Server on a UPnP Controlled Device. There is one Description Document for every Root Device that describes the Root Device and all non-Root Devices. Description Documents adhere to XML grammar. To support localization, multiple Description Documents can exist. A User Control Point requests the preferred localized Description Document by using the standard HTTP "accept-language" header.

Service. The fundamental UPnP controllable entity (but not the finest level of control). An example of a Service is "Clock". Services are defined with a mandatory common base set of functionality. Vendors can extend the base set with proprietary extensions provided the base functionality is implemented. Service Definitions are versioned and later versions are constrained to be supersets of previous versions. UPnP enables searches for all Devices that contain a specified Service of a minimum version. This search would find all clocks, regardless of their packaging. A search for Device Type "Clock" would be used to find only stand-alone clocks.

Service Type. A classification of Services by their function.

Service Type Identifier. A unique identifier that identifies a Service Definition. This identifier adheres to the format of a Uniform Resource Identifier (URI). See, T. Berners-Lee, R. Fielding, L. Masinter, "Uniform Resource Identifiers (URI): Generic Syntax", which can be found at http://www.ietf.org/rfc/rfc2396.txt.

Service State Table (SST). A logical table consisting of rows of [Variable, Type, Legal Values, Default Value, Current Value] that represents the current electrical, mechanical and/or logical state of a Service. SST instances are stored on the Controlled Device itself and are the ultimate authority of the state of the Service. All local user interface, such as front panels or wireless remotes are required to update the SST on UPnP compliant devices.

SST Definition:

Service Command Set. A set of Commands that can be invoked on a Service. Commands generally result in changes in the Current Value field of one or more rows of a SST. Commands are logically represented in the format Command (Variable=New Value, Variable=New Value, . . . ). Services must accept or reject the complete set of changes to a SST. There is a mandatory standard Query Command that is used to retrieve the Current Value of any row of a SST.

Service Command Set Definition:

Service Control Protocol (SCP). The protocol used to invoke Commands against a Service and to return results. There is exactly one SCP per Service Definition. SCPs adhere to the grammar of SCP XML schema. SCPs can be generated by an automated tool that accepts a SST Definition and a Command Set Definition as input.

Service Control Protocol Declaration (SCPD). A formal representation of the schema of a Service. The SCPD declares the rows of a Service's SST and the associated Command Set. SCPDs are uploaded from Controlling Devices in their Description Documents and enable User Control Points or Bridges to invoke Commands on the Service without any prior or persistent knowledge of the capabilities (or schema) of the Service. There is exactly one SCPD per Service Definition. SCPDs adhere to XML grammar. SCPDs can be generated by an automated tool that accepts a SST Definition and a Command Set Definition as input.

Event. An unsolicited message generated by a Controlled Device and delivered to one or more User Control Points. Events are used to maintain a consistent view of the state of Service across all interested User Control Points. UPnP leverages the GENA event architecture (see "Generic Event Notification") to transport event messages. All events are delivered using TCP/IP for reliability.

Generic Event Notification (GENA). An event transport protocol. GENA leverages TCP/HTTP as a transport. GENA has been submitted as an Internet Draft to the IETF. See, J. Cohen, S. Aggarwal, Y. Goland, "General Event Notification Architecture Base: Client to Arbiter", which can be found at http://www.ietf.org/internet-drafts/draft-cohen-gena-client-00.txt.

Simple Service Discovery Protocol (SSDP). A simple network device discovery protocol. UPnP uses SSDP to allow User Control Points to find Controlled Devices and Services. SSDP operates in a default, completely automatic multicast UDP/IP based mode in addition to a server-based mode that uses TCP/IP for registrations and query. Transitions between the default dynamic mode and server-based mode are automatic and transparent. SSDP enables every Controlled Device to control the lifetime that its Description URL is cached in all User Control Points. This enables a Controlled Device to remain visible to User Control Points for a relatively long time (through power cycles), in addition to enabling a Controlled Device to appear and disappear very quickly, all under the control of the Controlled Device. SSDP and related Multicast and Unicast UDP HTTP Messages specifications have been submitted as Internet Drafts to the IETF. See, Y. Goland, "Multicast and Unicast UDP HTTP Messages", which can be found at http://www.ietf.org/internet-drafts/draft-goland-http-udp-00.txt; and Y. Goland, T. Cai, P. Leach., Y. Gu, S. Albright, "Simple Service Discovery Protocol/1.0", which can be found at http://www.ietf.org/internet-drafts/draft-cai-ssdp-v 1-02.txt.

Client. In the context of UPnP, Client refers to a module that initiates a TCP/HTTP connection to a peer HTTP server.

Server. In the context of UPnP, Server refers to an HTTP server. This is a module that accepts incoming TCP/HTTP connections and either returns a web page or forwards the payload data to another module. Client and Server describe only the direction of initiation of TCP/HTTP connections. There is no relationship between the low level concepts of Client and Server and the high level concepts of User Control Point and Controlled Devices. Logically, User Control Points always discover and initiate communication with Controlled Devices, but this communication requires Client and Server functionality on both sides.

Hostname. A Hostname is the Domain Name System (DNS) or NetBIOS Name Service (NBNS) that, when resolved to an IP address, represents a network interface that can be used to establish TCP/IP level connectivity to User Control Points, Controlled Devices or Bridges. Hostnames can be used to provide persistent network level addressing on a network where IP addresses are dynamically assigned and of unknown lifespan or to integrate with an existing managed network. UPnP provides an algorithm for seeding a device's hostname from its UDN at manufacturing time.

Uniform Resource Locator (URL). A format for expressing web addresses. URLs minimally contain an identification of the protocol family that the URL is valid for, a Hostname, and a path. UPnP uses URLs as addresses whenever the module accepting the incoming connection is an HTTP server.

Description URL. The URL returned from a Controlled Device or Bridge in response to any UPnP SSDP query. This URL always points to a Description Server on the Controlled Device. An HTTP GET can be issued on this URL to retrieve the Description Document. This URL is valid as an address for the lifetime of the Hostname embedded in the URL.

Discovery Server. The module that runs in a Controlled Device or Bridge that responds to SSDP queries. This Server is unique in that it must support UDP/HTTP rather than just TCP/HTTP.

Discovery Client. The module that runs in a User Control Point that initiates SSDP queries.

Description Server. The module that runs in a Controlled Device or Bridge that responds to HTTP GETs and returns Description Documents. This service consists of a TCP/HTTP server than can retrieve and return a Description Document from persistent storage (like a filesystem).

Visual Navigation. User Control Point functionality that displays the icons of discovered Devices and enables the transfer of control to a browser or application to interact with the Controlled Device. In Windows, Visual Navigation could be implemented as a folder of icons.

Presentation URL. A URL that can be used by a User Control Point to navigate to the Presentation Server of a Controlled Device. This URL is returned in the Description Document and is valid as an address for the lifetime of the Hostname embedded in the URL. All Devices, including non-Root Devices, can have an associated Presentation URL.

Presentation Server. A web server. The module that runs in a Controlled Device that responds to HTTP GETs or Presentation URLs and returns user interface using web technologies (JavaScript, Jscript.RTM., ECMAScript, VBScript, ActiveX.RTM., Java Applet, etc.).

Browser. The Presentation Client. A web browser extended with a Rehydrator.

Control URL. A URL that can be used by a User Control Point to navigate to the Control Server of a Controlled Device or Bridge. This URL is returned in the Description Document and is valid as an address for the lifetime of the Hostname embedded in the URL. All Services have an associated Control URL.

Control Server. The module that runs in a Controlled Device or Bridge that responds to Commands invoked on a Service by a User Control Point. Commands are encoded using the SCP specified in the Service Definition. This service consists of a TCP/HTTP server than passes control to the native control logic of a Service, updates the SST and generates an event if the SST changes.

Rehydrator. In UPnP, the Control Client. A User Control Point module that translates between native operating system APIs and SCPs and events. The Rehydrator uploads SCPDs from Controlled Devices and Bridges and generates appropriate SCPs in response to application API requests to invoke Commands.

Event Subscription URL. A URL that can be used by a User Control Point to navigate to the Event Subscription Server of a Controlled Device or Bridge. This URL is returned in the Description Document and is valid as an address for the lifetime of the Hostname embedded in the URL. All Services have an associated Event Subscription URL.

Event Subscription Server. The module that runs in a Controlled Device or Bridge that responds to GENA SUBSCRIBE requests from User Control Points. A SUBSCRIBE informs the Controlled Device or Bridge of the User Control Point's desire to receive future events. This service consists of a TCP/HTTP server that adds the User Control Point's Event Sink URL to the list of destinations to be NOTIFY'd whenever the SST associated with the Service changes.

Event Subscription Client. The module that runs in a User Control Point that sends GENA SUBSCIBE messages to the Event Subscription Server.

Event Sink URL. A URL, supplied by a User Control Point, that is used as an address to send event NOTIFYs to. This URL is valid as an address for the lifetime of the Hostname embedded in the URL. There is no explicit relationship between Event Sink URLs and Subscription Identifiers.

Subscription Identifier (SID). A header in the GENA NOTIFY message that identifies the source of an event. In UPnP, the SID can be considered as an alias for the Event Source instance.

Event Sink. The module that runs in a User Control Point that accepts incoming GENA event NOTIFYs. This service consists of a TCP/HTTP server that passes the event information to interested applications running on the User Control Point.

Event Source. The module that runs in a Controlled Device or Bridge that sends GENA NOTIFYs to the Event Sink Servers of SUBSCRIBES User Control Points.

Domain Name System (DNS). A distributed system of servers that locates the IP addresses of other computers on a network based on their hierarchical names.

NetBIOS Name Server (NBNS). A server that locates the IP addresses of other computers on a network based on their flat NetBIOS computer names.

Multicast DNS (MDNS). A peer-to-peer translation scheme that does not require involvement of DNS servers.

UPnP Technologies Overview

An overview of technologies utilized in UPnP follows.

Device Discovery: Simple Service Discovery Protocol (SSDP)

TCP/IP provides the ability to initiate a connection with a specified application running on a specific device, provided both the network address of the device (IP address) and the application address (port) are known. Generally, application addresses (ports) are standardized and widely known, but the problem of learning the IP address of a device remains.

Simple Service Discovery Protocol (SSDP) is a protocol that enables devices to learn of the existence of potential peer devices and the required information (an IP address) needed to establish TCP/IP connections to them. The successful result of an SSDP search is a Uniform Resource Locator (URL). The Hostname embedded in the URL can be resolved to an IP address that can be used to make a connection to the discovered device. The name to address resolution is outside of the functionality of SSDP.

SSDP specifies a default, completely automatic, best-effort multicast UDP-based operating mode, in addition to a server mode that uses TCP for registration and query. Fall-forward to server mode and fallback to the default dynamic mode can occur automatically and transparently as a server is added or removed from a network. Server mode can be used to reduce network traffic, to implement searches based on location or policy and to integrate with a directory system.

SSDP requires that all devices specify a maximum lifetime that SSDP level knowledge of the device will remain cached in other network devices. If a device does not refresh the cache of other network devices before this interval expires, the device will disappear from the network. This interval can be chosen to be larger than a typical power down cycle to enable device visibility to persist for a relatively long time, or a smaller interval can be chosen to enable more dynamic visibility control. In all cases, devices that are abruptly removed from the network will eventually disappear from all networked devices.

In response to an SSDP search, UPnP devices return a Description URL in the SSDP Location and optionally the Alternate Location (AL) SSDP headers. An example location header is a follows:

Location: http://device.local/description/path/description.xml

In this example, the device.local is the Hostname of the Controlled Device, and the "description/path/description.xml" element of the URL is the path and name of the Description Document on the device.

Eventing: Generic Eventing Notification (GENA)

Eventing, in the context of UPnP, is the ability for a device to initiate a connection at any time to one or more devices that have expressed a desire to receive events from the source device. Events are used to enable synchronization among multiple devices organized into a many to one relationship. UPnP events are mainly used for asynchronous notifications of state changes.

TCP/IP provides the fundamental support for the connections that carry event information. Generic Event Notification (GENA) adds conventions for establishing relationships between interested devices and an addressing scheme to enable the unambiguous delivery of events. GENA leverages HTTP addressing and encapsulation.

User Control Points, Controlled Devices and Bridges

With reference now to FIGS. 1 and 2, UPnP is an application-level distributed network architecture where the logical nodes on the network are User Control Points 104-105, Controlled Devices 106-107 and Bridges 120. These classifications refer to functionality rather than physical entities. The functionality of UPnP User Control Points 104-105, Controlled Devices 106-107 and Bridges 120 can be packaged into physical entities (e.g., multiple function devices 102-103) in any combination.

The primary distinction between a User Control Point 104-105 and a Controlled Device 106-107 is that the User Control Point is always the communication initiator. After the initial communication, User Control Points can receive events from Controlled Devices.

Controlled Devices 106-107 are responsible for storing the state of Services. User Control Points are required to synchronize to the state on Controlled Devices and to share state directly among themselves.

User Control Points typically have user interface that is used to access one or more Controlled Devices on the network. Controlled Devices only have local user interfaces.

Bridges 120 (FIG. 2) expose devices that do not expose native UPnP protocols as native UPnP Controlled Devices. The Bridge itself looks to other UPnP User Control Points like a set of Controlled Devices.

The following table lists the modules in the User Control Points 104-105 and Controlled Devices 106-107, along with their functions.

           User Control Point            Controlled Device
    Function          Module          Function      Module
    Initiate discovery Discovery Client Respond to    Discovery
    of Controlled                     discovery     Server
    Devices.                          requests.
    Retrieve          Description Client Provide       Description
    Description                       Description   Server
    Documents.                        Documents.
    Display a folder  Visual Navigation
    of icons per
    discovered
    Device and allow
    transfer of
    control to a
    selected device.
    View user         Web Browser     Provide user  Presentation
    interface exposed                 inteface for  (Web) Server
    by a Controlled                   remote User
    Device.                           Control Points.
    Execute           Application
    applications.     Execution
                      Environment
    Invoke            Rehydrator      Accept        Control Server
    Commands on a                     incoming      plus native
    Controlled Device                 Commands in   control logic
    by sending                        SCPs and
    Service Control                   execute them.
    Protocols in
    response to local
    API calls.
    Inform a          Event           Accept requests Event
    Controlled Device Subscription    for Events    Subscription
    of a desire to    Client          and remember  Server
    receive Events.                   them.
    Receive an Event. Event Sink      Send an Event. Event Source

    Type      Description                        Example
    String    A sequence of UNICODE characters.
    Number    A number, with no limit on digits; may 15, 3.14,
              potentially have a leading sign,   -123.456E+10
              fractional digits, and optionally an
              exponent. Punctuation as in US
              English.
    Boolean   TRUE or FALSE.
    DateTime  A date in ISO8601 format, with     19941 105T08:1
              optional time and optional zone.   5:5 +03
              Fractional seconds may be as precise
              as nanoseconds. See, "Data elements
              and interchange formats - Information
              interchange - Representation of dates
              and times", which can be found at
              http:www.iso.ch/markete/8601.pdf.
    ByteBlock An unstructured sequence of bytes.

    URL           Function
    Description   Points to the Description Server and Document path on a
    URL           Root Device. This URL is returned by the Description
                  Server as part of the discovery process.
    Presentation  Points to a Presentation (web) Server on a Controlled
    URL           Device. There is one Presentation URL per Device,
                  including Root Devices. This URL can be entered into
                  the address bar of a web browser to navigate to the
                  root web page of a Device. This URL is returned in
                  the Description Document.
    Control URL   Points to the Control Server implementing a Service on a
                  Controlled Device. There is one Control URL per
                  instance of a Service. This URL is returned in
                  the Description Document.
    Event         Points to an Event Subscription Server on a
    Subscription  Controlled Device. This URL is returned in the
    URL           Description Document.
    Event Sink    Points to an Event Sink (an HTTP Server) on a User
    URL           Control Point. This URL is specified by the User Control
                  Point in the GENA SUBSCIBE message.

    Search for      Returns
    A unique Root   A single Description URL pointing to the Description
    Device (by      Server and Document path on the Root Device.
    UDN)
    A unique non-   A single Description URL pointing to the Description
    Root Device (by Server and Document path on the Root Device that
    UDN)            contains the non-Root Device.
    Type of Device  A set of Description URLs pointing to the Description
                    Servers/Document paths of all Root Devices that
                    match the Device Type, or contain a non-Root
                    Device that matches the Device Type.
    Type of Service A set of Description URLs pointing to the Description
                    Servers/Document paths of all Root Devices that
                    contain a matching Service, or contain a non-Root
                    Device that contains a matching Service.

            upnp:searchtype: [ allformat .vertline. UDNformat .vertline.
     srvformat
            .vertline. devformat ]
            searchtype      = [ UDN .vertline. SrvType .vertline. DevType
     .vertline. all ]
            allformat       = all
            UDNformat   = UDN:namespace:uniqueid
            namespace   = [ GUID .vertline. IEEEMAC .vertline. 1394]
            srvformat   = SrvType:servicetype:version
            devformat   = DevType:devicetype

                  Format               Example
    all           upnp:all             upnp:all
    Unique Device upnp:UDN:namespace:  upnp:UDN:IEEEMAC:0C009
    Name (UDN)    uniqueid             9123456
    Device Type   upnp:DevType:device  upnp:DevType:vcr
                  type
    Service Type  upnp:SrvType:        upnp:SrvType:clock:1
                  servicetype:ver

                  UPnP Notofication
    Announcement  Type              SSDP USN
                  "all"             Root Device UDN
    Unique Root   Root Device       Root Device UDN
    Device        UDN
    Unique non-   Non-Root Device   Non-Root Device UDN
    Root Device   UDN
    Device Type   Device Type       Root Device UDN + Device Type
                  Identifier        Identifier
    Service Type  Service Type      Root Device UDN + Service Type
                  Identifier        Identifier

              HRESULT
              RehydratorCreateServiceObject(
              IN  IXMLDOMDocument *pDCPD,
                  IN    IXMLDOMDocument *pContractDocument,
                  OUT   IUPnPService **pNewServiceObject);

            HRESULT
            RehydratorQueryStateVariable(
                IN        LPCTSTR         lpcszVerb,
                IN        LPCTSTR         lpcszControlURL,
                IN        LPCTSTR         lpcszSTI,
                IN        LPCTSTR         lpcszVarName,
                OUT       VARIANT         *pValue);

            M-POST /clockService HTTP/1.1
            Host: spather-xeon: 8586
            Content-Type: text/xml
            Man: "http://www.microsoft.com/protocols/ext/XOAP";
            ns=01
            01-MethodName: queryStateVariable
            01-MessageType: Call
            Accept-Language: en-gb, en;q=0.8
            Referer: http://myhouse/VCR1Presentation
            Content-Length: 84
            User-Agent: Mozilla/4.0 (compatible; MSIE 5.01;
            Windows NT 5.0)
            Connection: Keep-Alive
            <queryStateVariable>
                <variableName>currentTime</variableName>
            </queryStateVariable>

            HTTP/1.1 200 OK
            Connection: Close
            Cache-Control: private
            Date: Mon Oct 11 12:13:38 PDT 1999
            Expires: Mon Oct 11 12:13:38 PDT 1999
            Content-Type: text/xml
            Content-Length: 62
            Man: "http://www.microsoft.com/protocols/ext/XOAP";
            ns=01
            01-MessageType: CallResponse
            <queryStateVariableResponse>
                <_return>12:13:28</_return>
            </queryStateVariableResponse>

          HRESULT
          RehydratorInvokeServiceAction(
              IN            LPCTSTR       lpcszverb,
              IN            LPCTSTR       lpcszControlURL,
              IN            LPCTSTR       lpcszSTI,
              IN            LPCTSTR       lpcszActionName,
              IN            SAFEARRAY     saActionArgs,
              OUT   LONG                 *pStatus) ;

            M-POST /clockService HTTP/1.1
            Host: spather-xeon: 8586
            Content-Type: text/xml
            Man: "http://www.microsoft.com/protocols/ext/XOAP";
            ns=01
            01-MethodName: invokeAction
            01-MessageType: Call
            Accept-Language: en-gb, en;q=0.8
            Referer: http://myhouse/VCR1Presentation
            Content-Length: 119
            User-Agent: Mozilla/4.0 (compatible; MSIE 5.01;
            Windows NT 5.0)
            Connection: Keep-Alive
            <SerializedStream main="invokeAction">
                <invokeAction id="invokeAction">
                    <actionName>setCurrentTime</actionName>
                    <actionArg>15:41:29</actionArg>
                </invokeAction>
            </SerializedStream>

            HTTP/1.1 200 OK
            Connection: Close
            Cache-Control: private
            Date: Mon Oct 11 15:22:38 PDT 1999
            Expires: Mon Oct 11 15:22:38 PDT 1999
            Content-Type: text/xml
            Content-Length: 50
            Man: "http://www.microsoft.com/protocols/ext/XOAP";
            ns=01
            01-MessageType: CallResponse
            <invokeActionResponse>
                <_return>0</_return>
            </invokeActionResponse>

                <iconList>
                    <icon>
                       <size>16</size>
                       <imageType>PNG</imageType>
                       <color>1</color>
                       <depth>8</depth>
                       <image>
                "http://device.local/iconpath/icon.png"/>
                    </icon>
                </iconList>

                    GET iconpath/icon.png HTTP 1.1
                    Host: device.local

                HTTP/1.1 200 OK
                Content-Type: image/png
                Content-length: ###
                <binary color icon data in the PNG format>

    Root            The XML root element of a UPnP Description
                    Document.
    specVersionMajor The major version of the UPnP Architectural
                    Reference that this Description Document was
                    created against. This value must be 1.
    specVersionMajor The minor version of the UPnP Architectural
                    Reference that this Description Document was
                    created against. This value must be 0.
    URLBase         An optional element used to construct fully qualified
                    URLs. Relative URLS are appended to the value of
                    <URLBase> to create fully qualified URLs. If this
                    element is present, it must agree with the HTTP
                    Base header.
    manufacturer    A required element that contains a textual
                    manufacturer name.
    manufacturer    An optional element containing a URL that points to
    URL             the web page of the manufacturer.
    modelName       A required element containing a textual product
                    name.
    modelDescription A required element containing a textual product
                    description.
    modelNumber     An optional element containing a textual product
                    model number.
    modelURL        An optional element containing a URL that points to
                    the web page of the product.
    UPC             An optional element containing the product Universal
                    Product Code (UPC).
    serialNumber    An optional element containing a textual item serial
                    number.

    rootDevice    A required sub element of the root. This element is a
                  container for one or more service elements and the
                  elements that describe the rootDevice.
    device        An optional sub element of the root or another device
                  element. This element contains the same kinds of
                  elements as a rootDevice element.
    UDN           A required sub element of every rootDevice or device
                  element containing the Unique Device Name.
    friendlyName  A required sub element of every rootDevice or device
                  element containing a textual friendly name. This
                  element can be updated remotely.
    deviceType    A required sub element of every rootDevice or device
                  element containing a standardized Device Type
                  Identifier.
    presentation  An optional sub element of a rootDevice or device
    URL           element containing a Presentation URL.
    iconList      A required sub element of every rootDevice or device
                  element. This element is a container for one or more icon
                  elements. UPnP requires a base set of six icons that must
                  exist in the iconList. All devices must support PNG icon
                  image formats of three sizes, 16 by 16, 32 by 32 and 48
                  by 48 pixels in both color and black and white at 8 bit
                  depth. Additional formats and sizes, including JPEG,
                  GIF, BMP, ICON and VML, may be supported by
                  adding them to the list.
    icon          A required sub element of every iconList element. This
                  element is a container for the elements that define an
                  icon.
    size          A required sub element of every icon element. There
                  must be icon elements with associated size elements
                  with the values 16, 32 and 48. Other icons may
                  specify other sizes.
    color         A required sub element of every icon element with
                  value 0 or 1. Each icon of size 16, 32 or 48 must
                  exist in color and black and white.
    depth         A required sub element of every icon element. All
                  required icons must exist with a value of 8.
    imageType     A required sub element of every icon element that
                  identifies the format of the binary icon: png, jpeg,
                  vml, gif, bmp, or ico.
    image         A required sub element of every icon element that
                  references a binary icon.

    service       An optional sub element of the rootDevice or another
                  device element. This element is a container for the
                  Service Definition.
    serviceType   A required sub element of every service element
                  containing a standardized Service Type Identifier.
    controlURL    A required sub element of every service containing a
                  Control URL.
    eventSubURL   A required sub element of every service containing an
                  Event Subscription URL.
    SCPD          A required sub element of every service. The SCPD is a
                  container for the standardized Service Control Protocol
                  Declaration associated the Service.

    static VOID
    CUPnPService::EventNotifyCallback (SSDP_CALLBACK_TYPE
    ssdpType,
    SSDP_MESSAGE *pssdpMsg,
                       LPVOID pcontext);

            Dim UPnPAPI
            Set UPnPAPI = CreateObject("UPnPAPI.1")
            Devices = UPnPAPI.FindDevices(. . .)
            For each device in Devices
                For each service In devices.services
                    If service.dcpi = "clock.v1"
                       Service.EventHandler =
            GetRef ("clock_PropertyChanged")
                    End if
                Next service
            Next device
            Sub clock_PropertyChanged(prop, value)
                MsgBox "The time has changed. It is now " &
            value & "."
            End Sub

                    BOOL RegisterUpnpEventSource(
                    LPTSTR szRequestUri,
                    DWORD cProps,
                    UPNP_PROPERTY *rgProps
                    );