XML-based template language for devices and services Number:7,437,434 from the United States Patent and Trademark Office (PTO) owispatent A universal plug and play (UPnP) device makes itself known through a set of processes--discovery, description, control, eventing, and presentation. Following discovery of a UPnP device, an entity can learn more about the device and its capabilities by retrieving the device's description. The description includes vendor-specific manufacturer information like the model name and number, serial number, manufacturer name, URLs to vendor-specific Web sites, etc. The description also includes a list of any embedded devices or services, as well as URLs for control, eventing, and presentation. The description is written by a vendor, and is usually based on a device template produced by a UPnP forum working committee. The template is derived from a template language that is used to define elements to describe the device and any services supported by the device. The template language is written using an XML-based syntax that organizes and structures the elements.<H services, language, XML, based, templ, 7437434.html, Patent, pto, 7437434

Title: XML-based template language for devices and services

Abstract: A universal plug and play (UPnP) device makes itself known through a set of processes--discovery, description, control, eventing, and presentation. Following discovery of a UPnP device, an entity can learn more about the device and its capabilities by retrieving the device's description. The description includes vendor-specific manufacturer information like the model name and number, serial number, manufacturer name, URLs to vendor-specific Web sites, etc. The description also includes a list of any embedded devices or services, as well as URLs for control, eventing, and presentation. The description is written by a vendor, and is usually based on a device template produced by a UPnP forum working committee. The template is derived from a template language that is used to define elements to describe the device and any services supported by the device. The template language is written using an XML-based syntax that organizes and structures the elements.

Patent Number: 7,437,434 Issued on 10/14/2008 to Zintel, et al.

Inventors: Zintel; William Michael (Kenmore, WA), Gandhi; Amar S. (Redmond, WA), Gu; Ye (Seattle, WA), Pather; Shyamalan (Redmond, WA), Schlimmer; Jeffrey C. (Redmond, WA), Rude; Christopher M. (Redmond, WA), Weisman; Daniel R. (Kirkland, WA), Ryan; Donald R. (Redmond, WA), Leach; Paul J. (Seattle, WA), Cai; Ting (Redmond, WA), Knight; Holly N. (Woodinville, WA), Ford; Peter S. (Carnation, WA)
Assignee: Microsoft Corporation (Redmond, WA)

Appl. No.: 10/981,057

Filed: November 4, 2004

Related U.S. Patent Documents


Application Number	Filing Date	Patent Number	Issue Date
09811362	Mar., 2001	6910068
09496318	Feb., 2000	6892230
60190943	Mar., 2000
60160235	Oct., 1999
60139137	Jun., 1999

Current U.S. Class: 709/220 ; 709/221

Current International Class: G06F 15/177 (20060101); G06F 12/00 (20060101)

Field of Search: 709/220,217-219,223,224,221 370/254-258

References Cited [Referenced By]

U.S. Patent Documents


5394556	February 1995	Oprescu
5491800	February 1996	Goldsmith et al.
5559967	September 1996	Oprescu et al.
5627964	May 1997	Reynolds et al.
5745126	April 1998	Jain et al.
5748980	May 1998	Lipe et al.
5764930	June 1998	Staats
5787246	July 1998	Lichtman et al.
5787259	July 1998	Haroun et al.
5793979	August 1998	Lichtman et al.
5809331	September 1998	Staats et al.
5881230	March 1999	Christensen et al.
5903728	May 1999	Semenzato
5903894	May 1999	Reneris
5938752	August 1999	Leung et al.
6083276	July 2000	Davidson et al.
6101499	August 2000	Ford et al.
6167448	December 2000	Hemphill et al.
6466971	October 2002	Humpleman et al.
6477566	November 2002	Davis et al.
6507856	January 2003	Chen et al.
6546419	April 2003	Humpleman et al.
6553402	April 2003	Makarios et al.
6560633	May 2003	Roberts et al.
6910068	June 2005	Zintel et al.
7043532	May 2006	Humpleman et al.

Foreign Patent Documents


WO 99/35856	Jul., 1999	WO

Other References

"Home Plug & Play.TM.: CAL-based Interoperability for Home Systems," HomePNP.TM. Specification, Version 1.0, pp. 1-111, (Apr. 9, 1998). cited by other .
White Paper, "HAVi, the A/V digital network revolution," HAVi Organization, pp. 1-7 (1999). cited by other .
"Specification of the Home Audio/Video Interoperablity (HAVi) Architecture," The HAVi Specification, Version 1.0 (Jan. 18, 2000). cited by other .
Anderson, "FireWire System Architecture: Second Edition, IEEE 1394a," chapters 1-4 (1999). cited by other .
Technical White Paper, "Jini Architectural Overview," Sun Microsystems, Inc. (1999). cited by other .
"Salutation Consortium Frequently Asked Questions," The Salutation Consortium, pp. 1-6 (prior to filing date). cited by other .
"Salutation Architecture Specification (Part-1), Version 2.0c," The Salutation Consortium, (Jun. 1, 1999). cited by other .
"How it works," Thalia, pp. 1-3 (prior to filing date). cited by other .
"Sun Microsystems and Thalia Products Inc. to Collaborate to Co-Develop Network Software and Protocols for the Home, Results to Make Networked Appliances for the Home a Reality," Sunbeam Corporation, pp. 1-2 (2000). cited by other .
"Sunbeam Joins Microsoft in the Universal Plug and Play Forum to Establish A `Universal` Smart Appliance Technology Standard," Sunbeam Corporation, pp. 1-2 (2000). cited by other .
"Time For Smart Talk Is Over, Sunbeam Trumps Small Appliance Industry With Smart Appliance Debut," Sunbeam Corporation, pp. 1-4 (2000). cited by other .
"Lonworks Core Technology," Echelon Corporation, pp. 1-2 (2000). cited by other .
"Underlying Protocol of Echelon's LONWORKS.RTM. Network Adopted as New ANSI Standard, Free Reference Implementation Available to Developers," Echelon Corporation, pp. 1-2 (2000). cited by other .
Handley et al., "SIP: Session Initiation Protocol," The Internet Society, pp. 1-130 (Aug. 6, 2000). cited by other .
Rosenberg et al., "SIP Extensions for Instant Messaging," Internet Engineering Task Force, pp. 1-30 (Jun. 15, 2000). cited by other .
Rosenberg et al., "SIP Extensions for Presence," Internet Engineering Task Force, pp. 1-77 (Jun. 15, 2000). cited by other .
Tsang et al., "Requirements for Networked Appliances: Wide-Area Access, Control, and Interworking," Internet Engineering Task Force, pp. 1-9 (Sep. 2000). cited by other .
Tsang et al., "SIP Extensions for Communicating with Networked Appliances," Internet Engineering Task Force, pp. 1-9 (Nov. 2000). cited by other .
Moyer et al., "Framework Draft for Networked Appliances Using the Session Initiation Protocol," Internet Engineering Task Force, pp. 1-31 (Nov. 2000). cited by other .
Marples, "Naming and Accessing Network Appliances using extensions to the Session Initiation Protocol," SIP for Toaster, Telcordia Technologies (2000). cited by other .
"Networked Appliances," AR Greenhouse, Telcordia Technologies, pp. 1-2 (Dec. 15, 2000). cited by other .
Moyer et al., "SIP for Light Bulbs, Using SIP to Support Communication with Networked Appliances," Telcordia Technologies (Aug. 2, 2000). cited by other .
Bennett et al., "Integrating Presence with Multi-media Communications," White Paper, Dynamicsoft., pp. 1-18 (2000). cited by other .
Rosenberg et al., "An Application Server Architecture for Communications Services," White Paper, Dynamicsoft., pp. 1-13 (2000). cited by other .
"EIB Technology," EIB (2000). cited by other .
Freeman et al., "JavaSpaces.TM. Principles, Patterns, and Practice," Addison-Wesley Longman, Inc., Reading, Massachusetts (1999, Sun Microsystems, Inc.). cited by other .
Arnold et al., "The Jini.TM. Specification," Addison-Wesley Longman, Inc., Reading, Massachusetts (1999, Sun Microsystems, Inc.). cited by other .
A Kung, B. Raither, S. McConnell, Electronic Commerce Services Expand Home Automation Capabilities, Trialog, EMMSEC '99 Conference, Jun. 1999, pp. 1-7. cited by other .
Web Interface Definition Language (WIDL), Note-widl-970922, WebMethods, Inc. 1997, pp. 1-15. cited by other.

Primary Examiner: Maung; Zarni
Attorney, Agent or Firm: Lee & Hayes, PLLC

Parent Case Text

RELATED APPLICATION DATA

This is a continuation of U.S. patent application Ser. No. 09/811,362, entitled "An XML-Based Template Language for Devices and Services," which was filed on Mar. 16, 2001, and issued as U.S. Pat. No. 6,910,068 on Jun. 21, 2005, which is a continuation-in-part of U.S. patent application Ser. No. 09/496,318, entitled "Dynamic Self-Configuration For Ad Hoc Peer Networking", filed Feb. 1, 2000, which is based on provisional application No. 60/139,137 filed Jun. 11, 1999, and provisional application No. 60/160,235 filed Oct. 18, 1999. This also claims priority to provisional application No. 60/190,943, filed Mar. 21, 2000, which is hereby incorporated by reference.

Claims

We claim:

1. A method comprising: creating a device template for a universal plug and play device, the device template being written in an XML-based language; and instantiating the device template with vendor-specific information to form a device description of the universal plug and play device.

2. A method of describing a self-describing network device, comprising: storing a description of the self-describing network device, the description comprising a set of elements to describe the self-describing network device and an XML-based syntax that structures the set of elements such that, when the data structure is read by a computing device, the computing device can learn about the self-describing network device; and making the description available to the computing device.

3. A method as recited in claim 2, wherein the storing comprises storing the description at the self-describing network device.

4. A method as recited in claim 2, wherein the self-describing network device comprises a universal plug and play device.

5. A method as recited in claim 2, further comprising storing a set of elements to describe at least one service supported by the self-describing network device.

6. A method as recited in claim 2, wherein the storing comprises storing the description at the self-describing network device, the method further comprising storing a set of elements to describe at least one service supported by the self-describing network device at a location remote from the self-describing network device.

7. A data structure stored on a computer-readable medium, the data structure being constructed according to an XML-based template language, the data structure comprising: a set of elements to describe a universal plug and play device; and an XML-based syntax that organizes and structures the set of elements such that, when the data structure is read by a computing device, the computing device can learn about the universal plug and play device.

8. A data structure stored as recited in claim 7, wherein the set of elements requires: a first element to identify one or more versions of the template language; and a second element to identify the universal plug and play device.

9. A data structure stored as recited in claim 7, wherein the set of elements includes at least one of: a first element to identify one or more versions of the template language; a second element to identify the universal plug and play device; and a third element to specify a base universal resource locator (URL).

10. A data structure stored as recited in claim 9, wherein the second element includes at least one of: a first subelement to specify a type of universal plug and play device; a second subelement to identify a user; a third subelement to identify a manufacturer; a fourth subelement to specify a URL of a website for the manufacturer; a fifth subelement to provide a word description of the universal plug and play device for the user; a sixth subelement to specify a model name of the universal plug and play device; a seventh subelement to specify a model number of the universal plug and play device; an eighth subelement to specify a URL of a website for the universal plug and play device; a ninth subelement to specify a URL of a website for a presentation hosted by the universal plug and play device; a tenth subelement to specify a serial number of the universal plug and play device; an eleventh subelement to specify a universal device name of the universal plug and play device; a twelfth subelement to specify a universal product code of the universal plug and play device; a thirteenth subelement to specify any icons associated with the universal plug and play device; a fourteenth subelement to identify any of one or more services supported by the universal plug and play device; and a fifteenth subelement to identify any of one or more devices embedded within the universal plug and play device.

11. A data structure stored on a computer-readable medium, the data structure being constructed according to an XML-based template language, the data structure comprising: a set of elements to describe a service supported by a universal plug and play device; and an XML-based syntax that organizes and structures the set of elements such that, when the data structure is read by a computing device, the computing device can learn about the service supported by the universal plug and play device.

12. A data structure stored as recited in claim 11, wherein the set of elements includes at least one of: a first element to identify any of one or more actions performed by the service; and a second element to identify any of one or more state variables in the service.

13. A data structure stored as recited in claim 12, wherein the first element includes at least one subelement for each corresponding action, the subelement containing at least one of a name string to hold a name of the action, an argument list to hold parameters of the action, and a data type of the parameters.

14. A data structure stored as recited in claim 12, wherein the second element includes at least one of: a first subelement to identify a name of a state variable; a second subelement to specify a data type of the state variable; a third subelement to specify a default value of the state variable; a fourth subelement to enumerate legal string values; and a fifth subelement to define bounds of legal numeric values.

15. A universal plug and play device comprising: a memory; a description of the universal plug and play device stored in the memory, the description comprising a set of elements written in an XML syntax to describe the universal plug and play device to a computing device; and a processor coupled to the memory to submit the description to a remote entity on a network.

16. A universal plug and play device as recited in claim 15, wherein the description data comprises a first set of elements a first set of elements to describe the universal plug and play device and a second set of elements to describe a service supported by the universal plug and play device.

17. A universal plug and play device as recited in claim 15, wherein the set of elements comprises at least one of: a first element to identify one or more versions of the template language; a second element to identify the universal plug and play device; and a third element to specify a base universal resource locator (URL).

18. A universal plug and play device as recited in claim 17, wherein the second element includes at least one of: a first subelement to specify a type of universal plug and play device; a second subelement to identify a user; a third subelement to identify a manufacturer; a fourth subelement to specify a URL of a website for the manufacturer; a fifth subelement to provide a word description of the universal plug and play device for the user; a sixth subelement to specify a model name of the universal plug and play device; a seventh subelement to specify a model number of the universal plug and play device; an eighth subelement to specify a URL of a website for the universal plug and play device; a ninth subelement to specify a URL of a website for a presentation hosted by the universal plug and play device; a tenth subelement to specify a serial number of the universal plug and play device; an eleventh subelement to specify a universal device name of the universal plug and play device; a twelfth subelement to specify a universal product code of the universal plug and play device; a thirteenth subelement to specify any icons associated with the universal plug and play device; a fourteenth subelement to identify any of one or more services supported by the universal plug and play device; and a fifteenth subelement to identify any of one or more devices embedded within the universal plug and play device.

19. A universal plug and play device as recited in claim 15, wherein the set of elements includes at least one of: a first element to identify any of one or more actions performed by a service supported by the universal plug and play device; and a second element to identify any of one or more state variables in the service.

20. A universal plug and play device as recited in claim 19, wherein the first element includes at least one subelement for each corresponding action, the subelement containing a name string to hold a name of the action and an argument list to hold parameters of the action.

21. A universal plug and play device as recited in claim 19, wherein the second element includes at least one of: a first subelement to identify a name of a state variable; a second subelement to specify a data type of the state variable; a third subelement to specify a default value of the state variable; a fourth subelement to enumerate legal string values; and a fifth subelement to define bounds of legal numeric values.

22. A universal plug and play device comprising: storage means for storing a description of the universal plug and play device, the description comprising a set of elements to describe the universal plug and play device and an XML-based syntax that structures the set of elements such that, when the data structure is read by another computing device, the computing device can learn about the universal plug and play device; and responsive means for making the description available to another computing device.

Description

TECHNICAL FIELD

This invention relates generally to dynamic connectivity among distributed devices and services, and more particularly relates to providing a capability for devices to automatically self-configure to interoperate with other peer networking devices on a network, 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.

In the above ubiquitous and pervasive networked computing scenarios, the devices desirably can interoperate on an ad hoc peer-to-peer networking connectivity basis. Such a peer networking connectivity model 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. This peer networking connectivity 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 prevalent model for device connectivity, however, has been that of host-peripheral connectivity, typified by the personal computer and its many peripheral devices (e.g., data storage drives, user input devices, displays, printers, scanners, etc.) connected via various buses (e.g., PCI, VESA, AGP, Microchannel, ISA, EISA, USB), ports (e.g., serial, parallel), and connectors (e.g., PS/2 connector). This host-peripheral connectivity model is characterized in that the host and peripherals typically have persistent relationships and stable configurations. This persistent relationship is created, by example, through a set-up and configuration process through which appropriate driver software is installed by a user or administrator onto the host for use in controlling the peripheral, and updating the host's configuration to include peripheral device settings. Such persistent configured relationships with a user installation/configuration experience are generally inappropriate to the ubiquitous and pervasive computing environment where portable and mobile devices desirably can instantly connect and interact with other computing devices in their environment without having established prior or persistent relationships.

More specifically, two common computing networks where many of these small, network-capable computing devices are expected to be used include the home and small office. Such networks are commonly not actively managed by experienced administrators. In fact, due to the lack of networking experience of a large majority of the users of these networks, lengthy, complex and/or involved user installation and setup experiences pose a significant impediment to adoption and penetration of such networks and devices into homes and small offices.

Further, the establishment of persistent relationships with other devices in the configuration of these small, network-capable computing devices is inappropriate to many usage scenarios. For example, portable computing devices (such as a handheld computer or digital assistant, cell phones, and the like) may be used to access information (such as transportation departure/arrival times, store locations, etc.) from other devices on networks in public places (such as malls and airports). Not only would a user installation/configuration experience upon each such use pose an inconvenience, but the establishment of persistent configuration information poses configuration management issues and consumes device resources. As another example, devices (such as printers, scanners, monitors and etc.) on an office or home network may interact with many portable computing devices (such as the laptops, cameras, and other equipment of the mobile professional) that are introduced into its network. Again, in device connectivity models requiring establishing persistent device relationship configurations, such one-time and occasional relationships between these devices would results in configuration instability requiring management and maintenance of ever-changing persistent device configurations. Due to the time and cost (or lack of) active administration of these devices, any requirement to manage and maintain changing persistent device configurations on networked devices is undesirable.

Accordingly, there is a need for a device connectivity model that supports ad hoc peer networking among computing devices with preferably zero user installation or configuration experience and without persistent device configuration.

In accordance with a technology described herein, a universal plug and play (UPnP) device makes itself known and available for communication with other entities on a network through a set of processes--discovery, description, control, eventing, and presentation (herein also termed "self-bootstrapping"). Following discovery of a UPnP device, an entity can learn more about the device and its capabilities, or interact with the device, by retrieving the device's description from a URL provided by the device in an initial discovery message.

The description is expressed in XML and includes vendor-specific manufacturer information like the model name and number, serial number, manufacturer name, URLs to vendor-specific Web sites, etc. The description also includes a list of any embedded devices or services, as well as URLs for control, eventing, and presentation.

The description is written by a vendor and is usually based on a standard device template produced by a UPnP forum working committee. The template is derived from a template language that utilizes standard XML constructions. The template language includes a first set of elements to describe the UPnP device and a second set of elements to describe any services supported by the device. The template language is written using an XML-based syntax that organizes and structures the first and second sets of elements.

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 of layers in a self-bootstrapping process including addressing, naming, discovery and description layers per the device control model of FIG. 3.

FIG. 7 is a block diagram illustrating device addressing.

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

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

FIG. 10 is a block diagram of an implementation design of the Rehydrator of FIG. 8.

FIGS. 11 and 12 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. 13 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. 14 is a data flow diagram illustrating a typical browsing protocol sequence in the device control model of FIG. 3.

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

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

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

FIGS. 18, 19, and 20 are a listing of an XML schema for a contract in the device control model of FIG. 3.

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

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

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

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

FIG. 26 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. 25 in the device control model of FIG. 3.

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

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

FIG. 29 is a data flow diagram of a process for automatic network introduction of the embedded computing device of FIG. 26 into a configured computer network environment per the UPnP protocol.

FIG. 30 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. 31 is a block diagram of an exemplary home or office pervasive computing environment having a variety of computers as per FIG. 25 and embedded computing devices as per FIG. 26 interconnected per UPnP standards that may be used in the device control model of FIG. 3.

FIGS. 32 through 44 are program listings of interfaces used in the Rehydrator implementation design of FIG. 10.

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

FIGS. 48-51 are an XML format listing that depicts an XML schema for defining Contracts.

DETAILED DESCRIPTION

The following detailed description is directed toward self-bootstrapping or automatic dynamic self-configuring of devices for ad hoc peer networking with other devices on a computing network that avoid user installation experience, persistent relationship configurations, and software driver downloads. In one described implementation, this self-bootstrapping 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, and can be easily extended to specify A/V streaming.

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 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. UPnP enables the browser to be extended to control devices. 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.

There are some scenarios where the Web UI model is not sufficient for a rich customer experience. It would not be convenient to have a separate Web interface 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, a Rehydrator, an Event Subscription Client and an Event Sink,. User Control Points may also include Visual Navigation, 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 perform certain tasks (e.g., printing) and communicate 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, a Control Server, an Event Subscription Server and an Event Source. Controlled Devices may also include a Presentation (e.g., Web) Server. 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 or other control methods 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 A/V 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 schemes, Description Document, Devices and Services hierarchy and the functional description of Services.

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 search and/or 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 usually 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 especially when interpreted by humans, can be 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 Architecture (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 to upper level software. 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-v1-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 in addition to 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 in most common cases. 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. A 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 and sent using the SCP specified in the Service Definition. This service consists of a TCP/HTTP server that passes control to the native control logic of a Service, updates the SST and generates an event if the SST changes.

Rehydrator. In UPnP, a 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 accept