DE60019750T2 - Allgemeines api zur gerätefernsteuerung - Google Patents

Allgemeines api zur gerätefernsteuerung Download PDF

Info

Publication number
DE60019750T2
DE60019750T2 DE60019750T DE60019750T DE60019750T2 DE 60019750 T2 DE60019750 T2 DE 60019750T2 DE 60019750 T DE60019750 T DE 60019750T DE 60019750 T DE60019750 T DE 60019750T DE 60019750 T2 DE60019750 T2 DE 60019750T2
Authority
DE
Germany
Prior art keywords
service
upnp
devices
event
interface
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Expired - Lifetime
Application number
DE60019750T
Other languages
English (en)
Other versions
DE60019750D1 (de
Inventor
S. Amar GANDHI
J. Andrew LAYMAN
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Microsoft Corp
Original Assignee
Microsoft Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Microsoft Corp filed Critical Microsoft Corp
Publication of DE60019750D1 publication Critical patent/DE60019750D1/de
Application granted granted Critical
Publication of DE60019750T2 publication Critical patent/DE60019750T2/de
Anticipated expiration legal-status Critical
Expired - Lifetime legal-status Critical Current

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H04L12/2803—Home automation networks
    • H04L12/2807—Exchanging configuration information on appliance services in a home automation network
    • H04L12/281—Exchanging configuration information on appliance services in a home automation network indicating a format for calling an appliance service function in a home automation network
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L61/00—Network arrangements, protocols or services for addressing or naming
    • H04L61/50—Address allocation
    • H04L61/5007—Internet protocol [IP] addresses
    • H04L61/5014—Internet protocol [IP] addresses using dynamic host configuration protocol [DHCP] or bootstrap protocol [BOOTP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H04L12/46—Interconnection of networks
    • H04L12/4633—Interconnection of networks using encapsulation techniques, e.g. tunneling
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/10—Flow control; Congestion control
    • H04L47/24—Traffic characterised by specific attributes, e.g. priority or QoS
    • H04L47/2408—Traffic characterised by specific attributes, e.g. priority or QoS for supporting different services, e.g. a differentiated services [DiffServ] type of service
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L61/00—Network arrangements, protocols or services for addressing or naming
    • H04L61/30—Managing network names, e.g. use of aliases or nicknames
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L61/00—Network arrangements, protocols or services for addressing or naming
    • H04L61/50—Address allocation
    • H04L61/5092—Address allocation by self-assignment, e.g. picking addresses at random and testing if they are already in use
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/02—Protocols based on web technology, e.g. hypertext transfer protocol [HTTP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/12—Protocols specially adapted for proprietary or special-purpose networking environments, e.g. medical networks, sensor networks, networks in vehicles or remote metering networks
    • H04L67/125—Protocols specially adapted for proprietary or special-purpose networking environments, e.g. medical networks, sensor networks, networks in vehicles or remote metering networks involving control of end-device applications over a network
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/14—Session management
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/51—Discovery or management thereof, e.g. service location protocol [SLP] or web services
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/40—Network security protocols
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H04L12/2803—Home automation networks
    • H04L12/2816—Controlling appliance services of a home automation network by calling their functionalities
    • H04L12/282—Controlling appliance services of a home automation network by calling their functionalities based on user interaction within the home
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H04L12/2803—Home automation networks
    • H04L2012/2847—Home automation networks characterised by the type of home appliance used
    • H04L2012/2849—Audio/video appliances
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2101/00—Indexing scheme associated with group H04L61/00
    • H04L2101/30—Types of network names
    • H04L2101/365—Application layer names, e.g. buddy names, unstructured names chosen by a user or home appliance name
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/02—Protocols based on web technology, e.g. hypertext transfer protocol [HTTP]
    • H04L67/025—Protocols based on web technology, e.g. hypertext transfer protocol [HTTP] for remote control or remote monitoring of applications
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/30—Definitions, standards or architectural aspects of layered protocol stacks
    • H04L69/32—Architecture of open systems interconnection [OSI] 7-layer type protocol stacks, e.g. the interfaces between the data link level and the physical level
    • H04L69/322—Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions
    • H04L69/329—Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions in the application layer [OSI layer 7]

Description

  • Diese Erfindung bezieht sich allgemein auf einen dynamischen Aufbau einer Zwischenverbindungsfähigkeit unter verteilten Vorrichtungen und Diensten und bezieht sich insbesondere darauf, eine Fähigkeit bereitzustellen, auf vorrichtungs- oder dienst-spezifische, operationsmäßige Informationen zuzugreifen und eine Fern-Automatisation und Steuerung von eingeschlossenen Rechenvorrichtungen, unter Verwendung eines datengesteuerten Fernprogrammier-Modells, wie beispielsweise in einer pervasiven Rechenumgebung, durchzuführen.
  • Die Kosten von Rechen- und Netzwerk-Technologien sind zu dem Punkt gefallen, wo Rechen- und Netzwerk-Fähigkeiten in das Design vieler elektronischer Vorrichtungen zu Hause, im Büro und an öffentlichen Stellen eingebaut werden können. Die Kombination von kostengünstigen und zuverlässigen, gemeinsam geteilten Netzwerk-Medien mit einer neuen Klasse von kleinen Rechenvorrichtungen hat die Möglichkeit für eine neue Funktionalität basierend hauptsächlich auf der Verbindungsfähigkeit unter diesen Vorrichtungen hervorgerufen. Diese Verbindungsfähigkeit kann dazu verwendet werden, entfernt Vorrichtungen zu steuern, digitale Daten in der Form von Audio, Video und Standbildern zwischen Vorrichtungen zu bewegen, Informationen gemeinsam unter Vorrichtungen und mit dem nicht eingeschränkten World Wide Web des Internets (nachfolgend „Web") zu teilen und strukturierte und sichere, digitale Daten auszutauschen, um Dinge, ähnlich elektronischem Kommerz, zu unterstützen. Die Verbindungsfähigkeit ermöglicht auch viele neue Anwendungen für Rechenvorrichtungen, wie beispielsweise auf einer Proximity basierende Nutzungs-Szenarien, bei denen Vorrichtungen basierend zumindest teilweise auf geografischen oder anderen Absichten von Proximitys zusammenwirken. Ein häufiges Merkmal dieser Szenarien einer Verbindungsfähigkeit ist dasjenige, einen entfernten Zugriff und eine Steuerung von verbundenen Vorrichtungen und Diensten von einer anderen Vorrichtung mit Benutzer-Schnittstellen-Fähigkeiten zu schaffen (z. B. eine universelle Fernsteuereinheit, ein in der Hand gehaltener Computer oder Digital Assistant, Zellen-Telefone, und dergleichen). Diese Entwicklungen sind zu derselben Zeit aufgetreten, da mehr Leute mit dem Internet verbunden werden, und da Verbindungs-Lösungen im Preis fallen und sich in der Geschwindigkeiten erhöhen. Diese Trends führen zu einer Welt einer allgegenwärtigen und überall vorhandenen, vernetzten Rechenumgebung, wo alle Typen von Vorrichtungen in der Lage sind, mühelos und nahtlos sich miteinander zu verbinden und zusammenzuwirken.
  • In einer neuen Vorrichtungs-Verbindungsfähigkeits-Architektur, bekannt als Universal Plug and Play, werden Vorrichtungen und Dienste durch Austauschen von Nachrichten des gut definierten XML-Formats ausgetauscht. Auf dem programmatischen Niveau ist es allerdings nützlich und produktiv, in einem objekt-orientierten System zu arbeiten.
  • Frühere Verbindungsfähigkeits-Modelle sind nicht ausreichend, um zwischen Objekt-Schnittstellen und den Daten-Nachrichten, ausgetauscht mit der gesteuerten Vorrichtung über ein Netzwerk, zu überbrücken. Einige frühere Verbindungsfähigkeits-Modelle erfordern eine Steuervorrichtung, um den Programm-Code (wie beispielsweise einen Vorrichtungs-Treiber, einen Jini Code, usw.) zum Zusammenarbeiten mit der gesteuerten Vorrichtung oder dem Dienst von einer vernetzten Quelle herunterzuladen. Ein solches Erfordernis eines Herunterladens eines Codes ist nicht für das Web und andere, allgegenwärtige Rechen-Szenarien geeignet. Andere Verbindungsfähigkeits-Modelle erfordern die Verwendung eines durch den Kunden geschriebenen Objekts für spezifische Klassen von Diensten. Diese Maßnahme führt zu Einsatz-Schwierigkeiten (z. B. Benutzer-Setup und -Konfiguration) und ist auch nicht für eine allgegenwärtige Berechnung geeignet.
  • Die US-A-5491800 beschreibt eine Client Server Facility (CSF) Schnittstelle und eine vernetzte Service-Einrichtung-(Network Service Facility – NSF)-Schnittstelle zum Ausführen einer Kommunikation zwischen Anwendungs-Programmen, die in Client- und Server-Knoten eines Netzwerks mit verteilten Diensten vorhanden sind. Die CSF-Schnittstelle umfasst Fern-Prozedur-Ruf-(Remote Procedure Call – RCP)-Objekte zum Aufrufen von und zum Antworten auf Dienstanforderungen an den Knoten, und Anwendungs-Programmier-Schnittstellen-(Application Programming In terface – API)-Objekte zum Transportieren solcher Anforderungen zwischen den Knoten. Allerdings liefern die API-Objekte nur Kommunikations-Transporte innerhalb eines Knotens. Dementsprechend arbeiten die API- und RPC-Objekte mit dynamisch konfigurierbaren Protokoll-Stacks innerhalb der NSF-Schnittstellen zusammen, um den Transport-Mechanismus, benötigt durch ein Anwendungs-Programm an dem Client-Knoten, zu vervollständigen, wenn auf Dienste an einem entfernten Server-Knoten zugegriffen wird.
  • „The HAVI Specification: Specification of the Home Audio/Video Interoperability (HAVi) Architectur", HAVI Specification XP-002116332, 19. November 1998, Seiten 1–384, gibt einen Satz von Diensten an, die eine Arbeitsfähigkeit miteinander und die Entwicklung von verteilten Anwendungen auf Heim-Netzwerken erleichtert. Für eine dynamische Konfiguration einer Zwischenverbindungs-Fähigkeit unter verteilten Vorrichtungen und Diensten werden Steuereinheit-Vorrichtungen in der HAVi-Architektur vorgeschlagen, die, über einen Knoten, ein Herunterladen eines „Device Control Module" DCM für eine gesteuerte Vorrichtung erhalten.
  • Die WO-A-9935856 (angeführt unter Artikel 54 (3) und (4) EPÜ) bezieht sich auf ein Verfahren und ein System zum Erreichen einer nahtlosen Arbeits-Fähigkeit miteinander und einer Integration zwischen einer Mehrzahl von Vorrichtungen in einem Netzwerk, das ein gemeinsames Protokoll verwendet, wobei mindestens eine der Vorrichtungen eine Legacy- bzw. Alt-Vorrichtung ist, die mit dem Netzwerk unter Verwendung eines Proprietary Protokolls kommuniziert.
  • Es ist die Aufgabe der vorliegenden Erfindung, eine verbesserte Vorrichtung, ein Verfahren und ein durch Computer lesbares Medium zu schaffen, um eine dynamische Konfiguration einer Zwischenverbindungs-Fähigkeit unter verteilten Vorrichtungen ohne ein Erfordernis eines Herunterladens spezifischer Programm-Code oder eines Erfordernisses von durch den Kunden geschriebener Objekte für spezifische Klassen von Diensten zu schaffen.
  • Die Aufgabe wird durch den Gegenstand der unabhängigen Ansprüche gelöst.
  • Bevorzugte Ausführungsformen der vorliegenden Erfindung sind durch die abhängigen Ansprüche definiert.
  • Gemäß einer Technologie, die hier beschrieben ist, ist ein allgemeiner, programmatischer Schnittstellen-zu-Netzwerk-Benachrichtigungs-Adapter (bezeichnet als ein „Rehydrator") ein Modul, das eine geeignete Objekt-Integrations-Schnittstelle oder eine Anwendungs-Programmier-Schnittstelle zu Anwendungen auf einer Steuervorrichtung auferlegt und Netzwerk-Daten-Nachrichten sendet, um Dienste oder einen Frage-Status einer gesteuerten Vorrichtung aufzurufen. Der Adapter listet Anwendungs-Rufe zu der Schnittstelle in die Netzwerk-Daten-Nachrichten hinein entsprechend von Service- bzw. Dienst-Protokollen der gesteuerten Vorrichtung auf. Der beschriebene Adapter ist vorzugsweise allgemein für alle Vorrichtungen und Dienste mit dem Verbindungsfähigkeits-Modell kompatibel, und wendet sich selbst auf spezifische solche der Vorrichtungen basierend auf einer Schnittstelle und einer Nachrichten-Format/Protokoll-Beschreibung an. Mit anderen Worten arbeitet dieser Adapter als ein universelles Modul, über das durch Netzwerk-Daten-Nachrichten geleitete Dienste auf anderen, vernetzten Rechenvorrichtungen entfernte, programmatische Anwendungs-Programmier-Schnittstellen sein können, umfassend Objekt-Integrations-Schnittstellen entsprechend einem Objekt-Modell, wie beispielsweise COM, CORBA, JAVA, und dergleichen, von Microsoft.
  • Genauer gesagt schafft dieser allgemeine Adapter die Schnittstelle, die für irgendeinen spezifischen Dienst einer gesteuerten Vorrichtung geeignet ist, basierend auf einer Daten-Beschreibung der Schnittstelle, und wandelt die Anwendungs-Aufrufe zu Netzwerk-Daten-Nachrichten basierend auf einer Daten-Beschreibung eines Protokolls und eines Formats für Netzwerk-Daten-Nachrichten um, um mit dem spezifischen Dienst zusammenzuarbeiten. Wenn einmal die Schnittstellen/Nachrichten-Beschreibung erhalten ist, können Anwendungen auf der Steuervorrichtung programmatisch mit dem Adapter zusammenwirken, und der Adapter kann geeignete Nachrichten-Änderungen mit dem Dienst der gesteuerten Vorrichtungen handhaben. Mit dem beschriebenen Adapter ist kein Herunterladen eines Codes erforderlich, sondern es wird nur eine Schnittstellen/Benachrichtigungs-Beschreibung benötigt. Die Beschreibung kann von der gesteuerten Vorrichtung, einem Netzwerk-Server-Computer, oder durch Vorladen oder cachemäßiges Speichern auf der Steuervorrichtung erhalten werden. Die Technologie ermöglicht, dass Steuervorrichtungs-Anwendungen unter Verwendung eines Objekt-orientierten Programmierens geschrieben werden können, während ein Herunterladen eines Codes vermieden wird.
  • Zusätzliche Merkmale und Vorteile werden aus der nachfolgenden und detaillierten Beschreibung der dargestellten Ausführungsform ersichtlich werden, die unter Bezugnahme auf die beigefügten Zeichnungen vorgenommen wird.
  • Kurze Beschreibung der Zeichnungen
  • 1 und 2 zeigen Blockdiagramme einer Vorrichtungs-Architektur per Universal Plug and Play, unter Verwendung von Benutzer-Steuer-Punkten, gesteuerten Vorrichtungen und Brücken für eine Verbindungsfähigkeit zwischen Vorrichtungen.
  • 3 zeigt ein Blockdiagramm eines Vorrichtungs-Modells per Universal Plug and Play.
  • 4 zeigt ein Blockdiagramm, das Beispiel-Vorrichtungen darstellt, die mit dem Vorrichtungs-Modell der 3 übereinstimmen.
  • 5 zeigt ein Blockdiagramm, das eine Vorrichtungs-Zustands-Synchronisation unter Verwendung einer Zustands-Tabelle und eines Ereignisauftretens darstellt.
  • 6 zeigt ein Blockdiagramm, das ein Vorrichtungs-Adressieren darstellt.
  • 7 zeigt ein Blockdiagramm eines programmatischen Schnittstellen-zu-Netzwerk-Benachrichtigungs-Adapters oder eines Rehydrators in dem Vorrichtungs-Steuer-Modell der 3.
  • 8 zeigt ein allgemeines Daten-Flussdiagramm des Rehydrators der 7 in dem Vorrichtungs-Steuer-Modell der 3.
  • 9 zeigt ein Blockdiagramm eines Ausführungs-Designs des Rehydrators der 7.
  • 10 und 11 zeigen Blockdiagramme, die eine interne Software-Architektur des Benutzer-Steuer-Punkts und einer gesteuerten Vorrichtung in dem Vorrichtungs-Steuer-Modell der 3 darstellen.
  • 12 zeigt ein Blockdiagramm, das eine interne Software-Architektur einer kombinierten Brücke und eines Benutzer-Steuer-Punkts in dem Vorrichtungs-Steuer-Modell der 3 darstellt.
  • 13 zeigt ein Daten-Flussdiagramm, das eine typische Browsing-Protokoll-Sequenz in dem Vorrichtungs-Steuer-Modell der 3 darstellt.
  • 14 zeigt eine Auflistung, die ein Layout eines Beschreibungs-Dokuments in dem Vorrichtungs-Steuer-Modell der 3 darstellt.
  • 15 zeigt eine Auflistung einer beispielhaften Icon-Liste eines Beschreibungs-Dokuments in dem Vorrichtungs-Steuer-Modell der 3.
  • 16 zeigt eine Auflistung einer beispielhaften Dienst-Steuer-Protokoll-Deklaration in einem Beschreibungs-Dokument in dem Vorrichtungs-Steuer-Modell der 3.
  • 17, 18 und 19 zeigen eine Auflistung eines beispielhaften Kontrakts in dem Vorrichtungs-Steuer-Modell der 3.
  • 20 und 21 zeigen eine Auflistung eines XML-Schemas für eine Service-Steuer-Protokoll-Deklarations-Sprache, verwendet in dem Vorrichtungs-Steuer-Modell der 3.
  • 22 zeigt ein Blockdiagramm eines Ereignis-Modells, verwendet in dem Vorrichtungs-Steuer-Modell der 3.
  • 23 zeigt ein Daten-Flussdiagramm, das eine Subskription, einen Hinweis, und eine Entsubskription in dem Ereignis-Modell der 22 darstellt.
  • 24 zeigt ein Blockdiagramm eines Computer-Systems, das in dem Vorrichtungs-Steuer-Modell der 3 verwendet werden kann.
  • 25 zeigt ein Blockdiagramm einer Vorrichtung, die eine eingebettete Berechnungs- und Vernetzungs-Fähigkeit per Universal-Plug-and-Play-(UPNP)-Standards besitzt, die in Kombination mit dem Computer-System der 24 in dem Vorrichtungs-Steuer-Modell der 3 verwendet werden können.
  • 26 zeigt ein Blockdiagramm einer Software-Architektur pro UPNP-Standards in der eingebetteten Berechnungs-Vorrichtung der 25.
  • 27 zeigt ein Daten-Flussdiagramm eines Vorgangs für eine Automatik-Netzwerk-Einführung der eingebetteten Rechenvorrichtung der 25 in einer ad hoc Computer-Netzwerk-Umgebung per UPNP-Protokoll.
  • 28 zeigt ein Daten-Flussdiagramm eines Vorgangs für eine Automatik-Netzwerk-Einführung der eingebetteten Rechenvorrichtung der 25 in eine konfigurierte Computer-Netzwerk-Umgebung per UPNP-Protokoll.
  • 29 zeigt ein Blockdiagramm einer Software-Architektur einer Client-Vorrichtung per UPNP-Standard, die eine eingebettete Rechen- und Vernetzungs- Fähigkeit besitzt, die in dem Vorrichtungs-Steuer-Modell der 3 verwendet werden kann.
  • 30 zeigt ein Blockdiagramm einer beispielhaften Home- oder Office-Rechenumgebung, die überall vorhanden ist, die eine Vielzahl von Computern entsprechend 24 und eingebettete Rechenvorrichtungen entsprechend 25, über UPNP-Standards miteinander verbunden, besitzt, die in dem Vorrichtungs-Steuer-Modell der 3 verwendet werden können.
  • 31 bis 43 zeigen Programm-Auflistungen von Schnittstellen, verwendet in dem Ausführungs-Design des Rehydrators der 9.
  • 44–46 zeigen eine XML-Format-Auflistung, die einen beispielhaften Kontrakt für ein Zusammenwirken mit einem Stock-Quote-Service darstellt.
  • 47–50 zeigen eine XML-Format-Auflistung, die ein XML-Schema zum Definieren von Kontrakten darstellt.
  • DETAILLIERTE BESCHREIBUNG
  • Die nachfolgende, detaillierte Beschreibung ist auf einen allgemeinen, programmatischen Schnittstellen-zu-Netzwerk-Nachrichten-Adapter (auch bekannt als ein „Rehydrator") in einem Vorrichtungs-Steuer-Modell gerichtet. In einer beschriebenen Ausführung wird der Rehydrator in einer Vorrichtungs-Architektur 100 (1), einem Verbindungs-Modell und einem Vorrichtungs-Steuer-Protokoll, vorgeschlagen durch die Microsoft Corporation, bezeichnet als Universal Plug and Play („UPnP"), verwendet. Obwohl der allgemeine, programmatische Schnittstellen-zu-Netzwerk-(interface-to-network)-Benachrichtigungs-Adapter im Zusammenhang eines Vorrichtungs-Steuer-Modells, und spezifisch im Zusammenhang mit UPnP, beschrieben ist, ist er allgemeiner in anderen, verteilten, vernetzten Umgebungen anwendbar, um eine objekt-orientierte oder ähnliche Anwendungs-Programmier-Schnittstelle zu Anwendungen, die entfernt miteinander zusammenarbeiten, unter Verwendung von Netzwerk-Daten-Nachrichten, zu schaffen.
  • Universal Plug and Play
  • Universal Plug and Play (UPnP) ist eine offene Netzwerk-Architektur, die dazu ausgelegt ist, eine einfache ad hoc Kommunikation unter verteilten Vorrichtungen und Diensten von vielen Anbietern zu ermöglichen. UPnP setzt eine Internet- Technologie ein und kann als eine Erweiterung des Web-Modells von Mobil-Web-Browsern, die mit fixierten Web-Servern in der Welt einer Peer-to-Peer-Verbindungsfähigkeit unter mobilen und fixierten Vorrichtungen sprechen, angesehen werden. UPnP bezieht die Null-Konfigurations-Meinung (Mantra) von Plug and Play (PnP) ein, ist allerdings keine einfache Erweiterung des PnP-Host-Peripher-Modells.
  • Die Kosten, die Größe und der Batterie-Verbrauch einer Rechen-Technologie – einschließlich einer Verarbeitung, einer Speicherung und einer Anzeige – fahren fort, zu fallen. Dieser Trend wird durch die Entwicklung von selbstständigen, einzelnen Rechenvorrichtungen oder solchen mit begrenzter Funktion, wie beispielsweise Digital-Kameras, Audio-Playback-Vorrichtungen, Smart-Mobil-Telefonen und in der Hand haltbaren Computern, ermöglicht. Gleichzeitig hiermit ermöglicht die ökonomische Speicherung die Übertragung von Digital-Audio, -Video und Standbildern hochflexibler Modelle zum Verwalten von Entertainment-Inhalten.
  • Während viele dieser Vorrichtungen für eine nützliche, selbstständige Operation geeignet sind, kann eine nahtlose Verbindungsfähigkeit mit dem PC den Wert für den Kunden von sowohl selbstständigen Vorrichtungen als auch dem PC erhöhen. Gute Beispiele für diese Synergie sind eine digitale Bilderfassung kombiniert mit einer PC-Bildbearbeitung, -Speicherung und -Übertragung per Email/Veröffentlichung über das Web und eine Informations-Synchronisation zwischen einem PC und einem in der Hand haltbaren Computer oder einem Smart-Mobil-Telefon.
  • Da viele dieser Vorrichtungen, und der PC selbst, mobil sind, muss eine geeignete Kommunikations-Architektur ein hochdynamisches Verbindungsfähigkeits-Modell ermöglichen und muss einen Peer-to-Peer Betrieb unter wahlweisen Kombinationen von Vorrichtungen ermöglichen.
  • Das Internet hat ein weit verbreitetes Bewusstsein über den Wert einer einfachen, universellen Kommunikation hervorgerufen, die von der hinterlegenden Übertragungs-Technologie unabhängig ist und die von der Technologie irgendeines einzelnen Anbieters unabhängig ist.
  • UPnP macht es möglich, die Übertragung von großen Datenmengen (bulk data) (z. B. Dateien) oder A/V-Daten-Folgen von irgendeiner Vorrichtung auf dem Netzwerk zu irgendeiner Vorrichtung auf dem Netzwerk, unter der Steuerung irgendeiner Vorrichtung auf dem Netzwerk, zu initiieren und zu steuern. UPnP ermöglicht die Hinzufügung und das Entfernen von Vorrichtungen ad hoc auf dem Netzwerk, und sie ermöglicht, dass mehrere Steuervorrichtungen synchron zueinander verbleiben.
  • UPnP verwendet erneut existierende Protokolle und Technologien, immer wenn dies möglich ist. Der Übergang zu dieser stark verbundenen (und verbindbaren) Welt wird nicht über Nacht auftreten. UPnP baut sich auf existierenden Internet-Protokollen auf, nimmt allerdings Vorrichtungen auf, die nicht das vollständige UPnP-Protokoll laufen lassen können. UPnP sieht eine Architektur vor, die Alt-Vorrichtungen ermöglicht, mit UPnP-Vorrichtungen zu kommunizieren.
  • Ein IP-Internet-Arbeiten ist als eine UPnP-Basis-Richtlinie aufgrund der erwiesenen Fähigkeit ausgewählt worden, unterschiedliche, physikalische Medien zu überspannen, um eine reale Welt einer Zusammenarbeit von mehreren Anbietern zu ermöglichen und um eine Synergie mit dem Internet und Home- und Office-Intranets zu erreichen. Eine Internet-Synergie ermöglicht Anwendungen, wie beispielsweise eine IP-Telefonie, Spielen mit mehreren Spielern, eine Fernsteuerung einer Heim-Automatisierung und -Sicherheit, einen auf dem Internet basierenden, elektronischen Handel, zusätzlich zu einem einfachen Email und einem Web-Browsing. Der Umfang von UPnP umfasst eine Fernsteuerung von Vorrichtungen und eine Übertragung von großen Datenmengen. Allerdings spezifiziert es nicht A/V-Streaming-Formate oder -Protokolle.
  • Eine Medien-Unabhängigkeit von UPnP ermöglicht eine große Flexibilität in der Verpackung von Produkten. UPnP ermöglicht einem A/V-System, dass es über eine A/C-Power-Kommunikations-Technologie gesteuert wird, während die Übertragung von A/V-Datenfolgen unter den Komponenten analog oder digital ist. Eine der Steuereinheiten dieses Systems könnte auf einem Fernsehgerät vorhanden sein, während eine andere auf einem PC vorhanden ist, und eine noch andere über Funk oder Infrarot verbunden ist.
  • Im Gegensatz zu Plug and Play ist Universal Plug and Play on Top einer Netzwerk-Verbindung aufgebaut und ermöglicht eine Peer-to-Peer-Verbindungsfähigkeit ad hoc. Eine Netzwerk-Verbindung beschreibt, in diesem Zusammenhang, eine Art einer Verbindungsfähigkeit, die irgendeiner vernetzten Vorrichtung ermöglicht, eine Kommunikation mit einer anderen, vernetzten Vorrichtung einzuleiten, oh ne eine frühere Beziehung eingerichtet zu haben, oder eine bestehende Beziehung zwischen den Vorrichtungen aufrechtzuerhalten. Eine Vernetzung ermöglicht auch mehreren Vorrichtungen, eine oder mehrere Verbindungen) mit einer einzelnen Vorrichtung einzurichten, und ermöglicht einer Vorrichtung, dass sie in der Lage ist, sowohl Verbindungen zu anderen Vorrichtungen einzuleiten oder solche Verbindungen von anderen Vorrichtungen anzunehmen. Das PnP, oder Host/Peripher, Modell ist immer dann geeignet, wenn eine natürliche, dauerhafte Beziehung zwischen zwei Vorrichtungen vorhanden ist (z. B. ein Tastenfeld, eine Mouse, und eine Anzeige halten eine dauerhafte Beziehung zu einem Host-Computer aufrecht). Gerade obwohl eine Vernetzung keine dauerhaften Beziehungen auf niedrigem Niveau überträgt, schafft sie die benötigten Verankerungen (Adressen) für Anwendungen, um auszuwählen, Assoziationen als eine Annehmlichkeit für den Kunden beizubehalten (z. B. wird an die gemeinsam verwendeten, vernetzten Drucker erinnert).
  • Um eine Peer-to-Peer-Zusammenarbeit unter Vorrichtungen von mehreren Anwendern zu erreichen, vereinbaren Anwender eine gemeinsame Technologie und Standards bis zu dem höchsten Niveau der erwünschten, funktionalen Zusammenarbeit.
  • UPnP verbindet formale Protokoll-Kontrakte, um eine Peer-to-Peer-Operation dazwischen zu ermöglichen. Protokoll-Kontrakte ermöglichen eine Operation miteinander von mehreren Verkäufern in einer realen Welt.
  • UPnP ermöglicht Vorrichtungen, eine Benutzer-Schnittstelle durch Verknüpfen einer Browser-Technologie freizulegen. Eine derzeitige Browser-Technologie hält nicht eine Separation einer Präsentation von Daten, oder, in dem Fall von Vorrichtungen, einer Steuerung aufrecht. Es ist möglich, eine Seite von HTML zu durchsuchen, um Datenwerte zu extrahieren, allerdings ist dies nicht einfach oder robust. UPnP verbindet die Separation einer Präsentation und von Daten, freigegeben durch die Benutzung von XML, und es erweitert diese Technologie auf die Vorrichtungs-Steuer-Domäne.
  • UPnP sieht eine durch eine Vorrichtung gesteuerte Auto-Konfigurations-Fähigkeit vor, die die Erfahrung bewahrt, die Kunden auf dem Web haben. Heutzutage ist es möglich, das Web ohne Herunterladen von Programmen über den Browser selbst hinaus zu navigieren. Da UPnP dem Browser ermöglicht, auf Steuervorrich tungen erweitert zu werden, und da UPnP-Vorrichtungen mit expliziten Protokollen gesteuert werden, muss der Browser irgendwie fernen, wie mit UPnP-Vorrichtungen zu kommunizieren ist. Dieser Lernprozess wird vollständig von der Vorrichtung selbst geleitet und wird vollständig durch Herunterladen eines XML-Dokuments durchgeführt, das die Fähigkeiten der Vorrichtung beschreibt. Die architekturmäßige Komponente, die eine durch die Vorrichtung geleitete Auto-Konfiguration ermöglicht, wird als der Rehydrator bezeichnet. Die Aufgabe des Rehydrators ist diejenige, zwischen APIs und Protokollen umzuwandeln.
  • Da der Auto-Konfigurations-Prozess selbst nur durch die Änderung von formatierten Daten geleitet wird, ist dabei eine sehr geringe Gelegenheit für einen arglistigen Angriff von einem feindlichen Teil eines Codes aus vorhanden.
  • Es sind einige Szenarien vorhanden, bei denen das Web-UI-Modell nicht für eine umfangreiche Kunden-Erfahrung ausreichend ist. Es wäre nicht passend, ein Web für jeden Lichtschalter in einem Haus zu haben. Um eine umfangreiche Benutzer-Schnittstelle zu unterstützen und um eine Zusammenfassung von Vorrichtungen in eine einzelne UI zu ermöglichen, ermöglicht UPnP eine Anwendungs-Steuerung zusätzlich zu einer Browser-Steuerung von Vorrichtungen. Dies wird einfach dadurch erreicht, dass Anwendungen ermöglicht wird, dieselben Rehydrator-APIs aufzurufen, wie dies auch der Browser vornimmt. Anwendungen können auch direkt die groben UPnP-Steuer-Protokolle erzeugen und verbrauchen, vorausgesetzt, dass sie nicht an einer durch die Vorrichtung geleiteten Auto-Konfiguration, freigegeben durch den Rehydrator, interessiert sind.
  • UPnP nimmt an, dass dort mehr als eine Vorrichtung mit UI vorhanden sein wird, die wünscht, andere Vorrichtungen in irgendeinem gegebenen Netzwerk zu steuern, und es schafft einen einfachen Mechanismus, der diesen Steuer-Punkten ermöglicht, synchron zu verbleiben. Dieser Mechanismus kann einfach Vorrichtungs-Front-Panels und drahtlose Fernsteuerungen unterstützen, die nicht UPnP-Protokolle laufen lassen. Das UPnP-Steuer-Modell ist der dritte Teil einer Steuerung; irgendeine Vorrichtung kann umfangreiche Daten (z. B. Files bzw. Dateien) oder A/V-Datenfolgen von irgendeiner Vorrichtung auf dem Netzwerk zu irgendeiner Vorrichtung auf dem Netzwerk, unter der Steuerung irgendeiner Vorrichtung auf dem Netzwerk, übertragen.
  • Terminologie
  • Die detaillierte Beschreibung, die folgt, verwendet die Terminologie, die nachfolgend definiert ist.
  • Modul. Eine Komponente einer Vorrichtung, eines Software-Programms oder eines Systems, das eine bestimmte „Funktionalität" umsetzt, die als eine Software, eine Hardware, eine Firmware, eine elektronische Schaltung, usw., verkörpert sein kann.
  • Benutzer-Steuer-Punkt (User Control Point). Der Satz von Modulen, der eine Kommunikation mit einer UPnP-Steuervorrichtung ermöglicht. Benutzer-Steuer-Punkte initiieren eine Entdeckung und Kommunikation mit gesteuerten Vorrichtungen und empfangen Ereignisse von gesteuerten Vorrichtungen. Benutzer-Steuer-Punkte werden typischerweise auf Vorrichtungen umgesetzt, die eine Benutzer-Schnittstelle haben. Diese Benutzer-Schnittstelle wird dazu verwendet, mit gesteuerten Vorrichtungen über das Netzwerk zusammenzuarbeiten. Die Module umfassen minimal einen Discovery-Client, einen Description-Client und einen Rehydrator. Benutzer-Steuer-Punkte können auch eine visuelle Navigation, einen Event-Subscription-Client, eine Event-Sink, einen Web-Browser und eine Anwendungs-Ausführungs-Umgebung umfassen. Benutzer-Steuer-Punkte können einen Wert zu dem Netzwerk durch Zusammenfassung der Steuerung von mehreren gesteuerten Vorrichtungen (die universelle Fernsteuerung) hinzufügen oder sie können eine Funktion so einfach wie Initiieren der Übertragung von Daten zu einer gesteuerten Vorrichtung oder von dieser umsetzen. Beispiele von Vorrichtungen, die Benutzer-Steuer-Punkte sein könnten, sind der Personal-Computer (PC), das digitale Fernsehen (DTV), eine Set-Top-Box (STB), in der Hand haltbare Computer und Smart-Mobil-Telefone, und dergleichen. Nichts hindert eine einzelne Vorrichtung daran, die Funktionalität eines Benutzer-Steuer-Punkts und von einer oder mehreren gesteuerten Vorrichtungen) zu derselben Zeit umzusetzen.
  • Controlled Device. Der Satz von Modulen, der eine Kommunikation mit einem Benutzer-Steuer-Punkt ermöglicht. Gesteuerte Vorrichtungen sprechen auf Discovery-Anforderungen an, nehmen ankommende Kommunikationen von Benutzer-Steuer-Punkten (User Control Points) an und können Ereignisse zu Benutzer-Steuer-Punkten schicken. Vorrichtungen, die eine Funktionalität einer gesteuerten Vorrich tung unterstützen, können auch lokale Benutzer-Schnittstellen, wie beispielsweise Front-Panel-Displays oder drahtlose Fernsteuerungen, unterstützen. Die Module umfassen minimal einen Discovery-Server, einen Description-Server und einen Control-Server. Gesteuerte Vorrichtungen können einen Presentation-(Web)-Server, einen Event-Subscription-Server und eine Event-Source umfassen. Beispiele von Vorrichtungen, die gesteuerte Vorrichtungen sein könnten, sind ein VCR, ein DVD-Abspielgerät oder eine -Aufzeichnungs-Vorrichtung, eine Heiz/Ventilations/Klimatisierungs-Ausrüstung (HVAC), eine Beleuchtungs-Steuereinheit, eine Audio/Video/Bildabspiel-Vorrichtung, ein in der Hand gehaltener Computer, ein Smart-Mobil-Telefon und der PC, und dergleichen. Nichts hindert eine einzelne Vorrichtung daran, die Funktionalität eines Benutzer-Steuer-Punkts oder von einer oder mehreren gesteuerter Vorrichtungen) gleichzeitig umzusetzen.
  • Brücke (Bridge). Ein Satz von Modulen, der Bridged- and Legacy-Vorrichtungen ermöglicht, mit nativen UPnP-Vorrichtungen zusammen zu arbeiten. Die Brücke selbst gibt eine Zusammenstellung von UPnP gesteuerten Vorrichtungen zu Benutzer-Steuer-Punkten frei. Die Brücke listet zwischen nativen UPnP-Vorrichtungs-Steuer-Protokollen und den hinterlegenden Protokollen, freigegeben durch die Bridged and Legacy Devices, auf. Optional könnte eine solche Vorrichtung UPnP gesteuerte Vorrichtungen zu Legacy Vorrichtungen in der Art und Weise freigeben, die durch die Legacy-Vorrichtungen erforderlich sind. Nichts hindert eine einzelne Vorrichtung daran, die Funktionalität eines Benutzer-Steuer-Punkts, einer oder mehrerer gesteuerter Vorrichtungen und einer Brücke gleichzeitig umzusetzen.
  • Service-Provider. Ein Modul, verwendet durch eine UPnP-Brücke, die zwischen UPnP-Protokolen und den Protokollen, verwendet durch Bridged- and Legacy-Vorrichtungen, translatiert. Keine Service-Provider sind für eine Kommunikation unter nativen UPnP-Vorrichtungen erforderlich.
  • Überbrückte Vorrichtung (Bridged Device). Eine Vorrichtung, die in einem UPnP auf dem nativen Protokoll-Niveau partizipieren kann, entweder da die Vorrichtung keine ausreichenden Ressourcen besitzt oder da die hinterlegenden Medien nicht geeignet sind, um TCP und HTTP laufen zu lassen. Beispiele von Vorrichtungen, die überbrückte Vorrichtungen sein könnten, sind eine über die Energieversorgungs-Leitung gesteuerte A/V-Ausrüstung, Lichtschalter, Thermostate, Armbanduh ren und kostengünstige Spielzeuge. Überbrückte Vorrichtungen sind UPnP-beschwert und sind zu anderen UPnP-Vorrichtungen über eine UPnP-Brücke freigegeben.
  • Legacy-Vorrichtung (Legacy Device). Irgendeine Nicht-UPnP-Compliant-Vorrichtung, die zu anderen UPnP-Vorrichtungen über eine UPnP-Brücke freigelegt werden muss.
  • Vorrichtungs-Modell (Device Model). Das UPnP-Modell von gesteuerten Vorrichtungen. Das Vorrichtungs-Modell umfasst das Adressier-Schema, das Beschreibungs-Dokument, eine Hierarchie von Vorrichtungen und Diensten und die funktionale Beschreibung von Modulen.
  • Vorrichtungs-Steuer-Protokoll (Device Control Protocol – DCP). Ein vollständiger Satz von UPnP-Protokollen und Schemata, verwendet dazu, um mit einer UPnP gesteuerten Vorrichtung zusammenzuarbeiten.
  • Vorrichtungs-Definition (Device Definition). Die formale Definition eines Vorrichtungs-Typs. Eine Vorrichtungs-Definition umfasst einen Vorrichtungs-Typ-Identifizierer, die festgelegten Elemente in dem Beschreibungs-Dokument, den erforderlichen Satz von Dienst-Definitionen in der Root-Vorrichtung, und die Hierarchie von erforderlichen Vorrichtungen und Dienst-Definitionen.
  • Dienst-Definition (Service Definition). Die formale Definition eines Dienst-Typs. Eine Dienst-Definition umfasst einen Dienst-Typ-Identifizierer, eine Definition der Dienst-Zustands-Tabelle (Service State Table – SST), eine Definition des Dienst-Befehl-Satzes, das Dienst-Steuer-Protokoll (Service Control Protocol – SCP) und die Dienst-Steuer-Protokoll-Deklaration (Service Control-Protocol Declaration – SCPD).
  • Vorrichtung (Device). In dem Zusammenhang des Vorrichtungs-Modells ein Container für Dienste. Eine Vorrichtung gibt allgemein modellmäßig einen physikalischen Gegenstand, wie beispielsweise ein VCR, an, kann allerdings auch eine logische Einrichtung darstellen. Ein PC, der die traditionellen Funktionen eines VCR emuliert, würde ein Beispiel einer logischen Vorrichtung sein. Vorrichtungen können andere Vorrichtungen enthalten. Ein Beispiel würde ein TV/VCR sein, der zu einer einzelnen, physikalischen Einheit zusammengefasst ist. UPnP ermöglicht die Assoziation einer Benutzer-Schnittstelle (Anzeige-Icon und Root-Web-Seite) zu jeder Vorrichtung, umfassend eine Root-Vorrichtung.
  • Root-Vorrichtung (Root Device). Die oberste Vorrichtung in einer Hierarchie von verschachtelten Vorrichtungen. Eine Vorrichtung ohne verschachtelte Vorrichtungen ist immer eine Root-Vorrichtung.
  • Vorrichtungs-Typ (Device Type). Ein relativ hohes Niveau einer Klassifizierung von Vorrichtungen mit einer gemeinsamen Funktionalität. Vorrichtungs-Typ ist dazu vorgesehen, zu ermöglichen, dass Vorrichtungen einfach sind und automatisch für eine Präsentation gruppiert sind. Ein Beispiel eines Vorrichtungs-Typs ist „VCR". Vorrichtungs-Typen sind formal in Termen eines erforderlichen Satzes von Dienst-Definitionen einer minimalen Version, die eine konforme Vorrichtung unterstützen muss, definiert. UPnP unterstützt Suchen nach allen Vorrichtungen eines spezifizierten Vorrichtungs-Typs.
  • Vorrichtungs-Typ-Identifizierer (Device Typ Identifier). Ein eindeutiger Identifizierer, der eine Vorrichtungs-Definition identifiziert. Dieser Identifizierer hängt an dem Format eines Uniform Resource Identifier (URI). Siehe T. Berners-Lee, R. Fielding, L. Masinter, „Uniform Resource Identifiers (URI): Generic Syntax", das bei IETF RFC 2396 (August 1998) gefunden werden kann.
  • Device-Friendly-Name. Eine durch eine Person lesbare Folge bzw. ein String, der durch Anbieter zum Zeitpunkt einer Herstellung einer Vorrichtung initialisiert wird. Jede Vorrichtung, umfassend Root-Vorrichtungen, besitzt einen Device-Friendly-Name. Ein typischer Device-Friendly-Name wird Hersteller- und Modell-Informationen enthalten und wird dazu verwendet, eine präzisere Identifikation einer UPnP-Vorrichtung von dem Satz entdeckter Vorrichtungen zu ermöglichen. Wenn der eindeutige Vorrichtungs-Name (Unique Device Name – UDN) einmal identifiziert ist, kann er dazu verwendet werden, eindeutig dieselbe Vorrichtung in der Zukunft zu identifizieren. UPnP ermöglicht, dass Device-Friendly-Names durch Benutzer-Steuer-Punkte geändert werden. Der Device-Friendly-Name sollte nicht als Vorrichtungs-Identifizierer verwendet werden.
  • Eindeutiger Vorrichtungs-Name (Unique Device Name – UDN). Der grundsätzliche Identifizierer einer Vorrichtung. Jede Vorrichtung, umfassend Root-Vorrichtungen, besitzt exakt einen UDN. Der UDN ist global eindeutig und dauerhaft, sogar über große Leistungs-Zyklen und Änderungen des physikalischen Orts. Der UDN ist der einzige UPnP-Vorrichtungs-Identifizierer, in Bezug auf den garantiert ist, sogar über große Leistungs-Zyklen und Änderungen des physikalischen Orts. Der UDN ist der einzige UPnP-Vorrichtungs-Identifizierer, in Bezug auf den garantiert ist, dass er sich niemals ändert. UPnP ermöglicht Suchen nach Vorrichtungen durch UDN.
  • Beschreibungs-Dokument (Description Document). Eine strukturierte Einheit aus Daten, die durch einen Benutzer-Steuer-Punkt oder eine UPnP-Brücke verwendet wird, um die Fähigkeiten einer gesteuerten Vorrichtung zu erlernen. Beschreibungs-Dokumente werden von dem Beschreibungs-Server auf einer UPnP gesteuerten Vorrichtung aufgesucht. Dabei ist ein Beschreibungs-Dokument für jede Root-Vorrichtung vorhanden, die die Root-Vorrichtung und alle Nicht-Root-Vorrichtungen beschreibt. Beschreibungs-Dokumente hängen an einer XML-Grammatik. Um eine Lokalisierung zu unterstützen, können mehrere Beschreibungs-Dokumente existieren. Ein Benutzer-Steuer-Punkt erfordert das bevorzugte, lokalisierte Beschreibungs-Dokument durch Verwendung des Standard-HTTP-"accept-language"-Header.
  • Dienst (Service). Die fundamentale, durch UPnP steuerbare Einheit (allerdings nicht das feinste Niveau einer Steuerung). Ein Beispiel eines Dienstes ist "Clock". Dienste sind mit einem obligatorisch gemeinsamen Basis-Satz einer Funktionalität definiert. Anbieter können den Basis-Satz mit eigenen Erweiterungen erweitern, vorausgesetzt, dass die Basis-Funktionalität ausgeführt wird. Dienst-Definitionen sind Versionen und spätere Versionen sind dahingehend eingeschränkt, dass sie Untersätze von früheren Versionen sein müssen. UPnP ermöglicht Suchen nach allen Vorrichtungen, die einen spezifizierten Dienst einer minimalen Version enthalten. Diese Suche würde alle Clocks (Takte bzw. Uhren) finden, ungeachtet deren Verpackung. Eine Suche nach einem Vorrichtungs-Typ "Clock" würde dazu verwendet werden, nur selbstständige Clocks (Takte bzw. Uhren) zu finden.
  • Dienst-Typ (Service Type). Eine Klassifikation von Diensten durch deren Funktion.
  • Dienst-Typ-Identifizierer Service Type Identifier) Ein eindeutiger Identifizierer, der eine Service-Definition identifiziert. Dieser Identifizierer hängt sich an das Format eines Uniform Resource-Identifier (URI) an. Siehe T. Berners-Lee, R. Fielding, L. Masinter, Uniform Resource Identifiers (URI): Generic Syntax, IETF RFC 2396 (August 1998).
  • Dienst-Zustand-Tabelle (Service State Table – SST). Eine logische Tabelle, die aus Reihen von [Variable, Typ, legale Werte, Voreinstellungs-Wert, momentaner Wert] besteht, die den momentanen elektrischen, mechanischen und/oder logischen Zustand eines Dienstes darstellt. SST-Fälle sind an der gesteuerten Vorrichtung selbst gespeichert und sind die ultimative Autorität des Zustands des Dienstes. Die gesamte lokale Benutzer-Schnittstelle, wie beispielsweise Front-Panels oder drahtlose Fernsteuer-Einrichtungen, sind erforderlich, um die SST auf UPnP-Compliant-Vorrichtungen zu aktualisieren.
  • SST-Definition
  • Dienst-Befehl-Satz (Service Command Set). Ein Satz von Befehlen, der an einem Dienst aufgehoben werden kann. Befehle führen allgemein zu Änderungen in dem Feld des momentanen Werts einer oder mehrerer Reihe(n) einer SST. Befehle werden logisch in dem Format Befehl (Variable = neuer Wert, Variable = neuer Wert, ...) dargestellt. Dienste müssen den vollständigen Satz von Änderungen zu einer SST akzeptieren oder zurückweisen. Dabei ist ein obligatorischer Standard-Frage-Befehl (Query Command) vorhanden, der dazu verwendet wird, den momentanen Wert irgendeiner Reihe einer SST aufzusuchen.
  • Dienst-Befehl-Satz-Definition
  • Dienst-Steuer-Protokoll (Service Control-Protocol – SCP). Das Protokoll, verwendet dazu, Befehle gegen einen Dienst aufzurufen und Ergebnisse zurückzuführen. Dabei ist exakt ein SCP pro Dienst-Definition vorhanden. SCPs hängen sich an die Grammatik eines SCP XML Schemas an. SCPs können durch ein automatisiertes Tool erzeugt werden, das eine SST-Definition und eine Befehl-Satz-Definition als Eingabe annimmt.
  • Dienst-Steuer-Protokoll-Deklaration (Service Control-Protocol Declaration – SCPD). Eine formale Darstellung des Schemas eines Dienstes. Die SCPD erklärt die Reihen eines SST eines Dienstes und den zugeordneten Befehl-Satz. SCPDs werden von steuernden Vorrichtungen in deren Beschreibungs-Dokumenten heruntergeladen und ermöglichen Benutzer-Steuer-Punkten oder Brücken, Befehle über den Dienst aufzurufen, ohne eine frühere oder dauerhafte Kenntnis der Fähigkeiten (oder des Schemas) des Dienstes. Dabei ist exakt eine SCPD pro Dienst-Definition vorhanden. SCPDs hängen sich an eine XML-Grammatik an. SCPDs können durch ein automatisiertes Tool erzeugt werden, das eine SST-Definition und eine Befehl-Satz-Definition als Eingabe annimmt.
  • Ereignis (Event). Eine freiwillige Nachricht, erzeugt durch eine gesteuerte Vorrichtung und zugeführt zu einem oder zu mehreren Benutzer-Steuer-Punkten. Ereignisse werden dazu verwendet, eine konsistente Ansicht des Zustands des Dienstes über alle interessierten Benutzer-Steuer-Punkte beizubehalten. UPnP verbindet die GENA-Ereignis-Architektur (siehe "Generic Event Notification"), um Ereignis-Nachrichten zu transportieren. Affe Ereignisse werden unter Verwendung von TCP/IP für eine Zuverlässigkeit geliefert.
  • Generik-Ereignis-Hinweis (Generic Event Notification – GENA) Ein Ereignis-Transport-Protokoll. GENA verbindet TCP/HTTP als einen Transport. GENA ist als ein Internet Draft zu dem IETF herausgegeben worden. Siehe J. Cohen, S. Aggarwal, Y. Goland, General Event Notification Architektur Base: Client to Arbiter, IETF Internet Draft, "draft-cohen.gena-client-00.txt".
  • Einfaches Dienst-Entdeckungs-Protokoll (Simple Service Discovery Protocol – SSDP). Ein einfaches Netzwerk-Vorrichtungs-Entdeckungs-Protokoll. UPnP verwendet SSDP, um Benutzer-Steuer-Punkten zu ermöglichen, gesteuerte Vorrichtungen und Dienste zu finden. SSDP arbeitet in einem auf einer Voreinstellung, einem vollständig automatisierten Multicast-UDP/IP, basierenden Mode zusätzlich zu einem auf einem Server basierenden Mode, der TCP/IP für Registrierungen und Fragen verwendet. Die Übergänge zwischen dem Voreinstellungs-Dynamik-Mode und dem auf dem Server basierenden Mode sind automatisch und transparent. SSDP ermöglicht jeder gesteuerten Vorrichtung, die Lebensdauer zu steuern, für die die Description URL in allen Benutzer-Steuer-Punkten cachemäßig gespeichert werden. Dies ermöglicht einer gesteuerten Vorrichtung, für Benutzer-Steuer-Punkte für eine relativ lange Zeit sichtbar zu verbleiben (über Power-Zyklen), zusätzlich dazu, einer gesteuerten Vorrichtung zu ermöglichen, sehr schnell zu erscheinen und zu verschwinden, alles unter der Steuerung der gesteuerten Vorrichtung. SSDP und dazu in Bezug stehende Multicast und Unicast-UDP-HTTP-Nachrichten-Spezifikationen sind als Internet Drafts zu den IETF herausgegeben worden. Siehe Y. Goland, Multicast and Unicast UDP HTTP Messages. IETF Internet Draft, "draft-goland-http-udp-00.txt" und Y. Goland, T. Cai, P. Leach., Y. Gu, S. Albright, Simple Service Discovery Protocol/1.0, IETF Internet Draft, "draft-cai-ssdp-v1-02.txt".
  • Client. In dem Zusammenhang mit UPnP bezieht sich Client auf ein Modul, das eine TCP/HTTP-Verbindung zu einem Peer-HTTP-Server initiiert.
  • Server. In dem Zusammenhang von UPnP bezieht sich Server auf einen HTTP-Server. Dies ist ein Modul, das ankommende TCP/HTTP-Verbindungen akzeptiert und entweder eine Web-Seite zurückführt oder Payload-Daten zu einem anderen Modul zuführt. Client und Server beschreiben nur die Beschreibung einer Initiierung von TCP/HTTP-Verbindungen. Dabei ist keine Beziehung zwischen Konzepten mit niedrigem Niveau von Client und Server und Konzepten mit hohem Niveau von Benutzer-Steuer-Punkten und kontrollierten Vorrichtungen vorhanden. Logisch entdecken Benutzer-Steuer-Punkte immer eine Kommunikation mit gesteuerten Vorrichtungen und initiieren sie, allerdings erfordert diese Berechnung eine Client- und Server-Funktionalität auf beiden Seiten.
  • Hostname. Ein Host-Name ist ein Domäne-Namen-System (Domain Name System – DNS) oder ein NetBIOS-Name-Dienst (NBNS), das bzw. der, wenn es bzw. er zu einer IP-Adresse aufgelöst ist, eine Netzwerk-Schnittstelle darstellt, die dazu verwendet werden kann, eine Verbindungsfähigkeit auf einem TCP/IP-Niveau zu Benutzer-Steuer-Punkten, zu gesteuerten Vorrichtungen oder zu Brücken einzurichten. Hostnames können dazu verwendet werden, ein dauerhaftes Niveau-Netzwerk-Adressieren auf einem Netzwerk zu schaffen, wo IP-Adressen dynamisch zugeordnet werden und von einer nicht bekannten Lebensdauer sind oder mit einem existierenden, verwalteten Netzwerk integriert werden. UPnP liefert einen Algorithmus, um einen Hostnamen einer Vorrichtung von deren UDN zum Herstellungs-Zeitpunkt zu erzeugen.
  • Uniform-Ressource-Lokator (Uniform Resource-Locator – URL) Ein Format zum Ausdrücken von Web-Adressen. URLs enthalten minimal eine Identifikation der Protokoll-Familie, für die der URL für einen Hostname, und einen Pfad, gültig ist. UPnP verwendet URLs als Adressen, immer wenn das Modul, das eine ankommende Verbindung annimmt, ein HTTP-Server ist.
  • Beschreibungs-URL (Description URL) Der URL, zurückgeführt von einer gesteuerten Vorrichtung oder einer Brücke auf irgendeine UPnP-SSDP-Frage hin. Die ser URL weist immer auf einen Beschreibungs-Server an der gesteuerten Vorrichtung hin. Ein HTTP GET kann auf diesen URL ausgegeben werden, um das Beschreibungs-Dokument aufzusuchen. Dieser URL ist als eine Adresse für die Lebensdauer des Hostname, eingebettet in den URL, gültig.
  • Entdeckungs-Server (Discovery Server). Das Modul, das in einer gesteuerten Vorrichtung oder Brücke läuft, die auf SSDP-Fragen antwortet. Dieser Server ist einzigartig dahingehend, dass er UDP/HTTP, im Gegensatz zu nur TCP/HTTP, unterstützen muss.
  • Entdeckungs-Client (Discovery Client). Das Modul, das in einem Benutzer-Steuer-Punkt läuft, der SSDP-Fragen initiiert.
  • Beschreibungs-Server (Description Server). Das Modul, das in einer gesteuerten Vorrichtung oder Brücke läuft, die auf HTTP GETs antwortet und Beschreibungs-Dokumente zurückführt. Dieser Dienst besteht aus einem TCP/HTTP-Server, der ein Beschreibungs-Dokument von einem dauerhaften Speicher (ähnlich eines Dateisystems) aufsuchen und zurückführen kann.
  • Visuelle Navigation (Visual Navigation). Eine Benutzer-Steuer-Punkt-Funktionalität, die die Icons von entdeckten Vorrichtungen anzeigt und die Übertragung einer Steuerung zu einem Browser oder einer Anwendung freigibt, um mit der gesteuerten Vorrichtung zusammenzuwirken. In Windows könnte Visual Navigation als ein Folder von Icons ausgeführt werden.
  • Präsentations-URL (Presentation URL). Ein URL, der durch einen Benutzer-Steuer-Punkt verwendet werden kann, um zu dem Präsentations-Server einer gesteuerten Vorrichtung zu navigieren. Dieser URL wird in dem Beschreibungs-Dokument zurückgeführt und ist als eine Adresse für die Lebensdauer des Hostname, eingebettet in dem URL, gültig. Alle Vorrichtungen, umfassend Nicht-Root-Vorrichtungen, können einen zugeordneten Präsentations-URL haben.
  • Präsentations-Server (Presentation Server). Ein Web-Server. Das Modul, das in einer gesteuerten Vorrichtung läuft, die auf HTTP GETs oder Präsentations-URLs anspricht und eine Benutzer-Schnittstelle unter Verwendung von Web-Technologien (JavaScript, Jscript®, ECMAScript, VBScript, ActiveX®, Java Applet, usw.) zurückführt.
  • Browser. Der Präsentations-Client. Ein Web-Browser, erweitert mit einem Rehydrator.
  • Steuer-URL (Control URL). Ein URL, der durch einen Benutzer-Steuer-Punkt verwendet werden kann, um zu dem Steuer-Server einer gesteuerten Vorrichtung oder Brücke zu navigieren. Dieser URL wird in dem Beschreibungs-Dokument zurückgeführt und ist als eine Adresse für die Lebensdauer des Hostname, eingebettet in den URL, gültig. Alle Dienste besitzen einen zugeordneten Steuer-URL.
  • Steuer-Server (Control Server). Das Modul, das in einer gesteuerten Vorrichtung oder Brücke läuft, die auf Befehle, aufgerufen an einem Dienst durch einen Benutzer-Steuer-Punkt, anspricht. Befehle werden durch das SCP, spezifiziert in der Dienst-Definition, codiert. Dieser Dienst besteht aus einem TCP/HTTP-Server, der eine Steuerung zu der nativen Steuer-Logik eines Dienstes führt, die SST aktualisiert und ein Ereignis erzeugt, falls sich die Statistik ändert.
  • Rehydrator. Ein UPnP, der Steuer-Client. Ein Benutzer-Steuer-Punkt-Modul, das zwischen nativen Betriebssystem-APIs und SCPs und Ereignissen translatiert. Der Rehydrator lädt SCPDs von gesteuerten Vorrichtungen und Brücken hoch und erzeugt geeignete SCPs auf die Anwendung von API-Anforderungen hin, um Befehle aufzurufen.
  • Ereignis-Subskriptions-URL (Event Subscription URL). Ein URL, der durch einen Benutzer-Steuer-Punkt verwendet werden kann, um zu dem Ereignis-Subskriptions-Server einer gesteuerten Vorrichtung oder Brücke zu navigieren. Dieser URL wird in das Beschreibungs-Dokument zurückgeführt und ist als eine Adresse für die Lebensdauer des Hostname, eingebettet in den URL, gültig. Alle Dienste besitzen einen zugeordneten Ereignis-Subskriptions-URL.
  • Ereignis-Subskriptions-Server (Event Subscription Server) Das Modul, das in einer gesteuerten Vorrichtung oder Brücke arbeitet, die auf GENA SUBSCRIBE Anforderungen von Benutzer-Steuer-Punkten anspricht. Ein SUBSCRIBE informiert die gesteuerte Vorrichtung oder Brücke über den Wunsch des Benutzer-Steuer-Punkts, weitere Ereignisse zu empfangen. Dieser Dienst besteht aus einem TCP/HTTP-Server, der die Ereignis-Sink-URL des Benutzer-Steuer-Punkts zu der Liste von Bestimmungen, die NOTIFY'd sind, immer wenn sich die SST, zugeordnet zu dem Dienst, ändert, hinzufügt.
  • Ereignis-Subskriptions-Client (Event Subscription Client). Das Modul, das in einem Benutzer-Steuer-Punkt läuft, das GENA SUBSCRIBE Nachrichten zu dem Ereignis-Subskriptions-Server schickt.
  • Ereignis-Sink-URL (Event Sink URL). Ein URL, zugeführt durch einen Benutzer-Steuer-Punkt, der als eine Adresse verwendet wird, um Ereignis-NOTIFYs zu senden. Dieser URL ist als eine Adresse für die Lebensdauer des Hostname, eingebettet in den URL, gültig. Dabei ist keine explizite Beziehung zwischen Ereignis-Sink-URLs und Subskriptions-Identifizierern vorhanden.
  • Subskriptions-Identifizierer (Subscription Identifier-SID). Ein Header in der GENA NOTIFY Nachricht, die die Quelle eines Ereignisses identifiziert. In UPnP kann der SID als ein Alias für den Fall der Ereignis-Quelle angesehen werden.
  • Ereignis-Sink (Event Sink). Das Modul, das in einem Benutzer-Steuer-Punkt läuft, der ankommende GENA-Ereignis-NOTIFYs akzeptiert. Dieser Dienst besteht aus einem TCP/HTTP-Server, der die Ereignis-Informationen zu interessierten Anwendungen, die an dem Benutzer-Steuer-Punkt laufen, führt.
  • Ereignis-Quelle (Event Source). Das Modul, das in einer gesteuerten Vorrichtung oder Brücke läuft, die GENA NOTIFYs zu den Ereignis-Sink-Servern von SUBSCRIBES-Benutzer-Steuer-Punkten schickt.
  • Domäne-Name-System (Domain Name System – DNS). Ein verteiltes System von Servern, die die IP-Adresse von anderen Computern auf einem Netzwerk, basierend auf deren hierarchischen Namen, lokalisiert.
  • NetBIOS-Namen-Server (NBNS). Ein Server, der die IP-Adressen anderer Computer auf einem Netzwerk basierend auf deren Flat-NetBIOS-Computer-Namen lokalisiert.
  • Multicast-DNS (MDNS). Ein Peer-to-Peer-Translations-Schema, das kein Einsetzen von DNS-Servern erfordert.
  • UPnP-Technologien-Übersicht
  • Eine Übersicht von Technologien, verwendet in UPnP, folgt.
  • Vorrichtungs-Entdeckung: einfaches Vorrichtungs-Entdeckungs-Protokoll
  • Simple Service Discovery Protocol – SSDP
  • TCP/IP liefert die Fähigkeit, eine Verbindung mit einer spezifizierten Anwendung, die auf einer spezifischen Vorrichtung läuft, zu initiieren, vorausgesetzt, dass sowohl die Netzwerk-Adresse der Vorrichtung (IP-Adresse) als auch die Anwendungs-Adresse (Port) bekannt sind. Allgemein sind Anwendungs-Adressen (Ports) standardisiert und weitgehend bekannt, allerdings verbleibt das Problem eines Lernens der IP-Adresse einer Vorrichtung.
  • Ein einfaches Dienst-Entdeckungs-Protokoll (SSDP) ist ein Protokoll, das Vorrichtungen ermöglicht, die Existenz von potenziellen Peer-Vorrichtungen und den erforderlichen Informationen (eine IP-Adresse), benötigt, um TCP/IP-Verbindungen damit einzurichten, zu lernen. Das erfolgreiche Ergebnis einer SSDP-Suche ist ein Uniform-Resource-Lokator (URL). Der Hostname, eingebettet in den URL, kann zu einer IP-Adresse aufgelöst werden, die dazu verwendet werden kann, eine Verbindung mit der entdeckten Vorrichtung vorzunehmen. Die Auflösung Name-zu-Adresse liegt außerhalb der Funktionalität des SSDP.
  • SSDP spezifiziert einen Betriebs-Mode, der auf einer vollständig automatischen, besten Multicast-Voreinstellungs-UDP basiert, zusätzlich zu einem Server-Mode, der TCP für eine Registrierung und Frage verwendet. Ein Vorwärtsfallen zu dem Server-Mode und ein Rückwärtsfallen zu dem dynamischen Voreinstellungs-Mode können automatisch und transparent auftreten, wenn ein Server zu einem Netzwerk hinzugefügt oder von diesem entfernt wird. Der Server-Mode kann dazu verwendet werden, einen Netzwerk-Verkehr zu verringern, Suchen basierend auf einer Lokalisierung oder einer Policy auszuführen und sich mit einem Entdeckungs-System zu integrieren.
  • SSDP erfordert, dass alle Vorrichtungen eine maximale Lebensdauer spezifizieren, für die die SSDP-Niveau-Kenntnis der Vorrichtung cachemäßig in anderen Netzwerk-Vorrichtungen gespeichert verbleibt. Falls eine Vorrichtung nicht den Cache anderer Netzwerk-Vorrichtungen erneuert, bevor dieses Intervall abläuft, wird die Vorrichtung von dem Netzwerk verschwinden. Dieses Intervall kann so ausgewählt werden, um größer als ein typischer Power-Down-Zyklus zu sein, um eine Vorrichtungs-Sichtbarkeit so zu ermöglichen, dass sie für eine relativ lange Zeit besteht, oder ein kleineres Intervall kann ausgewählt werden, um eine dynamischere Sichtbarkeits-Kontrolle zu ermöglichen. In allen Fällen werden Vorrichtungen, die abrupt von dem Netzwerk entfernt werden, schließlich von allen vernetzten Vorrichtungen verschwinden.
  • Auf eine SSDP-Suche hin führen UPnP-Vorrichtungen einen Beschreibungs-URL in die SSDP-Stelle und optional die Alternativ-Stellen-(AL)-SSDP-Header zurück. Ein beispielhafter Stellen-Header ist wie folgt:
    Location: http://device.local/description/path/description.xml
  • In diesem Beispiel ist device.local der Hostname der gesteuerten Vorrichtung, und das Element "description/path/description.xml" von URL sind der Pfad und der Name des Beschreibungs-Dokuments auf der Vorrichtung.
  • Ereignis: Genetik-Ereignis-Hinweis (GENA)
  • Ein Eventing (Auftreten eines Ereignisses), in dem Zusammenhang mit UPnP, ist die Fähigkeit einer Vorrichtung, eine Verbindung zu irgendeinem Zeitpunkt mit einer oder mehreren Vorrichtungen) zu initiieren, die einen Wunsch ausgedrückt haben, Ereignisse von der Quellen-Vorrichtung zu empfangen. Ereignisse werden dazu verwendet, eine Synchronisation unter mehreren Vorrichtungen, organisiert in einer viele-zu-eine Beziehung zu ermöglichen. UPnP-Ereignisse werden hauptsächlich für asynchrone Hinweise von Zustands-Änderungen verwendet.
  • TCP/IP liefert die grundsätzliche Unterstützung für die Verbindungen, die Ereignis-Informationen tragen. Generic-Event-Notification (GENA) fügt Konventionen zum Einrichten von Beziehungen zwischen interessierten Vorrichtungen und einem Adressier-Schema, um die eindeutige Zuführung von Ereignissen zu ermöglichen, hinzu. GENA verbindet ein HTTP-Adressieren und eine Einkapselung.
  • Benutzer-Steuer-Punkte, gesteuerte Vorrichtungen und Brücken
  • In den 1 und 2 nun ist ein UPnP eine auf einem Anwendungs-Niveau verteilte Netzwerk-Architektur, wo logische Knoten auf dem Netzwerk Benutzer-Steuer-Punkte 104–105, gesteuerte Vorrichtungen 106–107 und Brücken 120 sind. Diese Klassifikationen beziehen sich auf eine Funktionalität, im Gegensatz zu physikalischen Einheiten. Die Funktionalität von UPnP-Benutzer-Steuer-Punkten 104–105, gesteuerten Vorrichtungen 106–107 und Brücken 120 kann in physikalische Einheiten gepackt werden (z. B. Vorrichtungen 102–103 in mehreren Funktionen), und zwar in irgendeiner Kombination.
  • Die primäre Bestimmung zwischen einem Benutzer-Steuer-Punkt 104–105 und einer gesteuerten Vorrichtung 106–107 ist diejenige, dass der Benutzer-Steuer-Punkt immer der Initiator für die Kommunikation ist. Nach der Anfangs- Kommunikation können die Benutzer-Steuer-Punkte Ereignisse von gesteuerten Vorrichtungen empfangen.
  • Gesteuerte Vorrichtungen 106–107 sind zum Speichern des Zustands von Diensten verantwortlich. Benutzer-Steuer-Punkte sind dazu erforderlich, zu dem Zustand auf gesteuerten Vorrichtungen zu synchronisieren und einen Zustand direkt unter diesem selbst gemeinsam zu teilen.
  • Benutzer-Steuer-Punkte besitzen typischerweise eine Benutzer-Schnittstelle, die dazu verwendet wird, auf eine oder auf mehrere gesteuerte Vorrichtungen) auf dem Netzwerk zuzugreifen. Gesteuerte Vorrichtungen besitzen nur lokale Benutzer-Schnittstellen.
  • Brücken 120 (2) legen Vorrichtungen frei, die nicht native UPnP-Protokolle als native UPnP-gesteuerte Vorrichtungen freilegen. Die Brücke selbst sieht nach anderen UPnP-Benutzer-Steuer-Punkten ähnlich einem Satz von gesteuerten Vorrichtungen.
  • Die nachfolgende Tabelle listet die Module in den Benutzer-Steuer-Punkten 104–105 und gesteuerten Vorrichtungen 106–107, zusammen mit deren Funktionen, auf.
  • Figure 00250001
  • Figure 00260001
  • Vorrichtungs-Modell
  • Das UPnP-Varrichtungs-Modell 200, dargestellt in 3, ist das Modell einer UPnP-gesteuerten Vorrichtung oder Brücke, die native, gesteuerte Vorrichtungen emuliert. Das Vorrichtungs-Modul umfasst ein Adressier-Schema, ein Ereignis-Schema, ein Beschreibungs-Dokument-Schema, Vorrichtungs- und Dienst-Schemata und -Hierarchie, und die funktionale Beschreibung von Modulen. Das UPnP-Vorrichtungs-Modell erstreckt sich über eine einfache API oder einen Befehl und Steuer-Protokoll-Definitionen hinaus, um mehreren Benutzer-Steuer-Punkten zu ermöglichen, eine übereinstimmende Ansicht von gesteuerten Vorrichtungen zu haben. Dies erfordert, dass der Zustand von laufenden Diensten formal modelliert wird und dass alle Zustands-Änderungen für Benutzer-Steuer-Punkte sichtbar sind. Zentral für die verteilte UPnP-Architektur ist die Regel, dass gesteuerte Vorrichtungen die ultimative Autorität für den Zustand von Diensten, die darauf laufen, sind.
  • Dienst
  • Die fundamentale, steuerbare Einheit in UPnP ist ein Dienst 210–217. Jeder laufende Fall eines Dienstes umfasst:
    • • Eine Dienst-Zustands-Tabelle (Service State Table – SST) 230, die den momentanen Zustand des Dienstes darstellt. Die SST 230 kann dazu verwendet werden, den Betriebs-Modus einer Vorrichtung darzustellen oder als eine Informations-Quelle oder eine Senke (Sink) für strukturierte Daten oder einfache Dateien zu wirken. Die SST einer VCR 254 (4) könnte den momentanen Transport-Modus, die Tuner-Kanal-Auswahl, Eingabe- und Ausgabe-Schalter-Auswahlen, ein Audio- und Video-Decodier-Format und ein momentanes Zeitgeber-Programm darstellen. Die SST einer Uhr (Takt) 251 (4) würde ähnlich die momentane Zeit darstellen. Die SST einer ein Bild gestaltenden Vorrichtung könnte einen Video-Frame-Puffer ausführen, der grobe Pixel-Informationen oder formatierte JPG-Dateien akzeptieren kann. Die SST einer Audio- oder Video-Abspielvorrichtung könnte einen Übertragungs-Puffer oder eine Warteschlange von Material, das abgespielt werden soll, ausführen. Die SST von PDA könnte eine Zusammenstellung von formatierten Daten ausführen, die sich geändert haben und mit einer anderen Vorrichtung synchronisiert werden müssen, zusätzlich zu einem Übertragungs-Puffer zum Aufnehmen von ankommenden, formatierten Daten. Die logische Struktur einer SST, veröffentlicht in der Dienst-Definition (Service-Definition), allerdings das tatsächliche Speicher-Format eines Falls einer SST, ist vollständig die Vorrichtung. Die einzige Wechselwirkung mit einer SST erfolgt über ein Formal-Anwendungs-Niveau-Netzwerk-Protokoll.
    • • Ein Steuer-Server 232, der ankommende Befehle annimmt, ausgedrückt in dem Dienst-Steuer-Protokoll (SCP) des Dienstes. Der Steuer-Server führt den Befehl zu der den nativen Befehl verarbeitenden Logik des Dienstes weiter und wartet auf einen Befehl-Abschluss. Wenn der Befehl erfolgreich abgeschlossen ist, wird die SST aktualisiert, ein Ereignis wird erzeugt und eine erfolgreiche Antwort wird zu dem Benutzer-Steuer-Punkt zurückgeführt. In dem Fall eines illegalen Befehls oder eines nicht erfolgreichen Befehls, werden keine Änderungen in Bezug auf die SST vorgenommen und eine Fehler-Antwort wird zurückgeführt. Die Befehl- und Antwort-Sequenz wird zu einer TCP/HTTP-Anforderung-Antwort geladen.
    • • Ein Ereignis-Subskriptions-Server und eine Ereignis-Quelle 234. Der Ereignis-Subskriptions-Server nimmt ankommende GENA-SUBSCRIBE Nachrichten von Benutzer-Steuer-Punkten an und fügt sie zu einer Liste von Benutzer-Steuer-Punkten hinzu, die an SST-Änderungs-Ereignisse von dem Dienst interessiert sind. Die Ereignis-Quelle initiiert eine TCP/HTTP-Verbindung zu jedem interessierten Benutzer-Steuer-Punkt und schickt eine GENA NOTIFY zu jedem Zeitpunkt, zu dem sich die DST des Dienstes ändert. Das NOTIFY Payload umfasst die geänderten Inhalte der DST.
    • • Ein Steuer-URL, der den Steuer-Server identifiziert.
    • • Ein Ereignis-URL, der den Ereignis-Subskriptions-Server identifiziert.
  • Die formale Definition eines Dienstes (Dienst-Definition) umfasst:
    • • Die Definition von SST. SST-Layouts sind logisch in Termen von Reihen von [Variable, Typ, legale Werte, Voreinstellungs-Wert] spezifiziert. Der tatsächliche Fall einer SST würde auch ein Feld momentaner Wert in jeder Reihe umfassen.
    • • Die Definition des Dienst-Befehl-Satzes kann gegenüber der SST des Dienstes aufgerufen werden. Befehle sind logisch in Termen von Befehl (Variable = Neuer Wert, Variable = Neuer Wert, ...) spezifiziert. Falls ein Befehl zu mehr als einer einzelnen Variablen-Änderung führt, sind die Aktualisierungen autonom und der Befehl wird fehlschlagen, falls er illegal ist, um die spezifizierte Änderung bei irgendeiner Variablen vorzunehmen.
    • • Die Definition einer strukturierten Einheit von Daten bezeichnete eine Dienst-Steuer-Protokoll-Deklaration (SCPD). SCPD wird dazu verwendet, das Layout (Schema) der SST und des Befehl-Satzes des Dienstes zu einem Benutzer-Steuer-Punkt oder einer Brücke anzuzeigen. Die SCPD ermöglicht dem Benutzer-Steuer-Punkt, Befehle (Über den Rehydrator) an der gesteuerten Vorrichtung ohne eine vorherige oder dauerhafte Kenntnis über die Fähigkeiten der Vorrichtung aufzurufen. Die SCPD wird von der steuernden Vorrichtung als Teil des Beschreibungs-Dokuments heruntergeladen. Ein automatisiertes Tool, das die SST-Definition und die Befehl-Satz-Definition als Eingaben annimmt, kann die SCPD für einen Dienst erzeugen.
    • • Die Definition eines Netzwerk-Protokolls, verwendet dazu, Befehle gegenüber der SST, zugeordnet zu einem Dienst, aufzurufen und Ergebnisse zurückzuführen. Ein automatisiertes Tool, das die SST-Definition und die Befehl-Satz-Definition als Eingaben annimmt, kann die SCPD für einen Dienst erzeugen. Das SCP kann auch von einem SCPD erzeugt werden. Der Auftrag des Rehydrators ist derjenige, SCPDs in SCPs umzuwandeln. Der Grund für eine formale SCP-Spezifikation ist derjenige, die Ausführung des Steuer-Servers selbst zu ermöglichen und eine einfache Peer-to-Peer-Vorrichtungs-Zusammenarbeit, unter Verwendung nur veröffentlichter Protokolle, zu ermöglichen. Ein Identifizierer, bezeichnet als der Dienst-Typ-Identifizierer, der eine eindeutige Dienst-Definition definiert. Dienst-Definitionen sind in einer gesteuerten Art und Weise als Versionen aufgebaut. Jede spätere Version eines Dienstes muss ein geeigneter Untersatz der vorherigen Version sein.
  • Vorrichtung
  • Gemäß dem Vorrichtungs-Modell 200, das in 3 dargestellt ist, ist eine UPnP-Vorrichtung 202–205 (z. B. Vorrichtungen 102–103 mit Mehrfach-Funktionen der 1 und überbrückte Vorrichtungen 122–123 der 2) ein logischer Container von einem oder mehreren Diensten) 210–217. Allgemein stellt eine Vorrichtung eine physikalische Einheit, wie beispielsweise einen VCR, dar. Typische Dienste in dem Beispiel der VCR-Vorrichtung könnten sein "TRANSPORT", "TUNER", "TIMER" und "CLOCK". Während Vorrichtungen oftmals physikalische Einheiten sind, könnte ein PC, der die traditionellen Funktionen eines VCR emuliert, auch in derselben Art und Weise wie ein selbstständiger VCR aufgebaut werden. Vorrichtungen können andere Vorrichtungen enthalten. Ein Beispiel würde ein TV-VCR 250 (4) sein, verpackt in einer einzelnen, physikalischen Einheit. Eine Vorrichtung (z. B. Vorrichtungen 202–203) kann auch ein logischer Container von anderen Vorrichtungen sein. Die oberste Vorrichtung in einer Hierarchie von verschachtelten Vorrichtungen 203–205 wird als die Root-Vorrichtung 202 bezeichnet. Eine Vorrichtung ohne verschachtelte Vorrichtungen ist immer eine Root-Vorrichtung.
  • Das UPnP-Vorrichtungs-Modell wurde so ausgelegt, um allgemein und flexibel zu sein. Es sollte möglich sein, einen gesamten Nuclear Power Plant als einen einzelnen Dienst (Service) oder als eine tief verschachtelte Hierarchie von Vorrichtungen und Diensten aufzubauen. Allgemein ist ein Dienst 210–217 ein kohäsiver Satz von Funktionen, der eine flexible Verpackung in einer Vielzahl von Vorrichtungen ermöglicht. Dienste können unabhängig von Vorrichtungen als Version aufgebaut werden.
  • Alle Vorrichtungen, umfassend Root-Vorrichtungen, gehören zu einem oder mehreren Vorrichtungs-Typ(en). Vorrichtungs-Typen sind dazu vorgesehen, Fälle von Vorrichtungen freizugeben, die einfach und automatisch für eine Präsentation gruppiert werden. Ein Beispiel eines Vorrichtungs-Typs ist "VCR" 254 (4). Vorrichtungs-Typen sind formal in Termen eines minimalen Satzes von als Version aufgebauten Diensten definiert, die ein Dienst eines Vorrichtungs-Typs unterstützen müssen. Vorrichtungs-Typen sind nicht formal als Version aufgebaut. Ein Vorrichtungs-Typ ist eine Gruppierung mit relativ hohem Niveau. Eine Vorrichtung eines Vorrichtungs-Typs stellt nur sicher, dass ein minimaler Satz von Diensten einer minimalen Versison vorhanden ist. Dabei können andere Dienste, Dienste einer höheren Version und Dienste mit Anbieter-Erweiterungen, vorhanden auf einer solchen Vorrichtung, sein.
  • UPnP ermöglicht Suchen auf einem SSDP-Niveau für einen eindeutigen Fall einer Vorrichtung (durch UDN), und zwar alle Vorrichtungen des Typs Vorrichtungs-Typ und alle Vorrichtungen, die mindestens einen Dienst-Typ einer minimalen Version enthalten. Das Ergebnis einer SSDP-Suche ist immer ein URL, der auf das Beschreibungs-Dokument, enthalten in der Root-Vorrichtung, hinweist. In dem Fall, dass eine passende Vorrichtung nicht die Root-Vorrichtung ist, besitzt das Beschreibungs-Dokument einen Baum von verschachtelten Vorrichtungen, die durchquert werden können, um die passende Vorrichtung zu finden.
  • Jede Vorrichtung umfasst:
    • • einen oder mehrere Vorrichtungs-Typ(en).
    • • einen oder mehrere Dienste).
    • • optional eine oder mehrere Vorrichtung(en).
    • • optional einen Präsentations-(Web)-Server 220–223, der dazu verwendet werden kann, eine Vorrichtungs-Benutzer-Schnittstelle freizulegen. Jeder Präsentations-Server besitzt einen zugeordneten Präsentations-URL.
    • • einen global eindeutigen Identifizierer, der als der Unic-Device-Name (UDN) bezeichnet wird. Der UDN ist der fundamentale Identifizierer für einen Fall einer Vorrichtung. Jede Vorrichtung, umfassend Root-Vorrichtungen, besitzt exakt einen UDN.
  • Jede Root-Vorrichtung 202 umfasst auch das Beschreibungs-Dokument 226 und den Beschreibungs-Server 228 für alle Vorrichtungen unter sich und sich selbst umfassend.
  • Die formale Definition einer Vorrichtung (Vorrichtungs-Definition 226) umfasst:
    • • Die festgelegten Elemente des Beschreibungs-Dokuments, die die Vorrichtung beschreiben.
    • • Die erforderliche Hierarchie von Vorrichtungen und Dienst-Definitionen.
  • Dabei können viele Vorrichtungs-Definitionen vorhanden sein, die zu einem einzelnen Vorrichtungs-Typ gehören.
  • Vorrichtungs-Typen
  • Die formale Definition eines Vorrichtungs-Typs umfasst:
    • • Eine Vorrichtungs-Typ-Identifizierer.
    • • Die erforderliche Hierarchie von Vorrichtungen und Dienst-Definitionen von minimalen Versionen.
  • Dienst-Zustands-Tabelle
  • Eine Dienst-Zustands-Tabelle (Service State Table – SST) besteht logisch aus Reihen von:
    Variable, Typ, legale Werte, Voreinsfellungs-Wert, momentaner Wert
  • Obwohl Eintritte der Dienst-Zustands-Tabelle in UPnP aus diesen fünf Elementen bestehen, kann die Zustands-Tabelle alternativ weniger oder zusätzliche Elemente enthalten. Allgemein wird jeder Eintritt minimal aus einem Variable-Namen oder Identifizierer, und seinem momentanen Wert, bestehen.
  • Die nachfolgende Tabelle listet verschiedene Typen, verfügbar in UPnP, auf.
  • Figure 00310001
  • Figure 00320001
  • Der ByteBlock ist im Wesentlichen ein Daten-Puffer. In einer Benutzung kann eine Variable dieses Typs verwendet werden, um eine Übertragung einer Datei von der gesteuerten Vorrichtung zu dem Benutzer-Steuer-Punkt zu bewirken. Die Datei, die übertragen werden soll, wird in der Dienst-Zustands-Tabelle als der momentane Wert dieser Variablen gehalten. Bei einer Änderung in der Datei wird die Datei zu irgendeinem teilnehmenden Benutzer-Steuer-Punkt in einem Ereignis-Hinweis übertragen.
  • Der Grund zum Darstellen von Diensten auf diese Art und Weise ist derjenige, sicherzustellen, dass der Zustand eines Dienstes einfach in einer üblichen Art und Weise zu mehreren Benutzer-Steuer-Punkten verfügbar ist.
  • Eine SST kann dazu verwendet werden, einen momentanen Operations-Modus einer Vorrichtung darzustellen, als eine Informations-Quelle oder -Senke (Sink) zu wirken und/oder einfach eine Ablage für Befehle zu sein. Die SST eines VCR-Dienstes könnte den momentanen Transport-Modus, eine Tuner-Kanal-Auswahl, Eingabe- und Ausgabe-Schalter-Auswahlen, Audio- und Video-Decodier-Format und ein momentanes Zeitgeber-Programm darstellen. Alternativ könnte der VCR 254 als ein Transport-Dienst 260, ein Tuner-Dienst, ein I/O-Schalter-Dienst, ein A/V-Decodier-Konfigurations-Dienst und ein programmierbarer Zeitgeber-Dienst 261 dargestellt werden.
  • Die SST für eine Uhr 251 würde ähnlich die momentane Zeit darstellen. Zusätzlich könnte eine Alarm-Uhr Dienst-Variable umfassen, um die Uhr bzw. den Takt zu konfigurieren.
  • Die SST einer ein Bild gestaltenden Vorrichtung könnte einen Video-Frame-Puffer ausführen, der grobe Pixel-Informationen oder formatierte JPG-Dateien annimmt. Die SST einer Audio- oder Video-Abspiel-Vorrichtung könnte einen Übertragungs-Puffer oder eine Warteschlange von Material, das abgespielt werden soll, ausführen. Die SST von PDA könnte eine Zusammenstellung von formatierten Daten ausführen, die sich geändert haben und mit einer anderen Vorrichtung synchronisiert werden müssen, zusätzlich zu einem Übertragungs-Puffer zum Annehmen von ankommenden, formatierten Daten.
  • Benutzer-Steuer-Punkt-Synchronisation
  • Gemäß eines Vorrichtungs-Zustands und eines Ereignis-Modells, dargestellt in 5, erfordern UPnP-Regeln, dass jede Änderung zu einer SST ein entsprechendes Ereignis erzeugt, um die Änderung zu allen interessierten Benutzer-Steuer-Punkten anzuzeigen.
  • Vorrichtungs-Adressieren
  • Wie nun 6 zeigt, ist ein UPnP an der Oberseite eines HTTP aufgebaut und verbindet ein natives Adressen-Format des Web, Uniform-Ressource-Lokatoren (URLs) URLs enthalten minimal eine Identifikation einer Anwendungs-Protokoll-Familie ("HTTP"), dass der URL für einen Hostname und einen Pfad gültig ist. In dem Zusammenhang von UPnP kann der Pfad-Teil eines URL entweder einen Datei-System-Pfad oder einfach einen Identifizierer des Lokal-System-Moduls und den Kontext, der ankommende Nachrichten verarbeiten kann, darstellen.
  • Während UPnP-Module als HTTP-Server beschrieben sind, ist dabei kein Erfordernis vorhanden, dass Ausführungen auf tatsächlichen Web-Servern basieren müssen. In den meisten Fällen ist der Auftrag des HTTP-Servers einfach, um die ankommende Verbindung anzunehmen, an dem lokalen Bestimmungs-Teil der Adresse (dem Pfad) nachzusehen, und das Payload zu einem anderen Modul weiterzuführen. UPnP ermöglicht, allerdings erfordert nicht, dass alle HTTP-Server auf einer gemeinsamen Software-Ausführung oder einem Laufzeit-Fall basieren. Gesteuerte Vorrichtungen und Brücken können eine TCP-Port-Spezifikation als ein Teil eines URL umfassen, um den Voreinstellungs-Wert von 80 zu überlaufen.
  • Das erfolgreiche Ergebnis einer UPnP-SSDP-Pegel-Suche ist immer ein oder mehrere Beschreibungs-URLs. Diese URLs können dazu verwendet werden, zu dem Beschreibungs-Dokument einer gesteuerten Vorrichtung oder einer Brücke zu navigieren. Ein Benutzer-Steuer-Punkt lädt das Beschreibungs-Dokument hoch und extrahiert die URLs der Server, die auf der gesteuerten Vorrichtung oder der Brücke laufen.
  • Alle URLs, zurückgeführt in das Beschreibungs-Dokument, besitzen eine Lebensdauer gleich zu der Lebensdauer des Hostname, der darin eingebettet ist. Benutzer-Steuer-Punkte können diese URLs als Adressen speichern, ohne zuerst durch eine Such-Sequenz zu laufen. Wenn sie einmal in einem Beschreibungs-Dokument angezeigt worden sind, können die gesteuerte Vorrichtung und die Brücken nicht wahlweise Server-URLs ändern.
  • Immer wenn sich ein Hostname ändert, werden alle URLs, die zu allen Vorrichtungen, adressiert durch diesen Hostnamen, zugeordnet sind, für ungültig erklärt. Der UDN ist der einzige UPnP-Identifizierer, der dahingehend garantiert ist, dass er sich niemals ändert. Irgendwelche vorhandenen Assoziationen, die durch Anwendungen beibehalten werden, sollten mindestens den UDN speichern, um eindeutig die Ziel-Vorrichtung zu identifizieren.
  • Die Lebensdauer eines Beschreibungs-URL wird durch die gesteuerte Vorrichtung oder die Brücke, die ihn anzeigt, bestimmt. Falls eine gesteuerte Vorrichtung oder eine Brücke zulässt, dass eine SSDP-Anzeige eines Beschreibungs-URL abläuft, wird der URL für ungültig erklärt.
  • Benutzer-Steuer-Punkte verwenden den Ereignis-Subskriptions-URL, zurückgeführt durch die gesteuerte Vorrichtung oder Brücke, um den Ereignis-Subskriptions-Server zu verbinden. Dieser Server ist die Organisation, die alle Benutzer-Steuer-Punkte erinnert, die daran interessiert sind, Ereignisse auf einem Dienst zu empfangen. Der Ereignis-Subskriptions-Server benötigt eine Adresse, um die Ereignisse zurückzuschicken. Diese Adresse wird als der Ereignis-Sink-URL bezeichnet, und wird zu der gesteuerten Vorrichtung oder der Brücke in der GENA SUBSCRIBE Nachricht zugeführt. Die Lebensdauer einer Ereignis-Subskription, und des Ereignis-Sink-URL, wird durch den Zeitablauf über die SUBSCRIBE Nachricht bestimmt. Weitere Details einer UPnP-Adressierung sind in der nachfolgenden Tabelle aufgelistet.
  • UPnP Adressen
    Figure 00350001
  • Vorrichtungs-Discovery und Identifikation
  • UPnP ermöglicht SSDP-Suchen nach einem eindeutigen Root oder einer Nicht-Root-Vorrichtung durch UDN, Vorrichtungen eines spezifizierten Vorrichtungs-Typs und Vorrichtungen, die einen Dienst eines spezifizierten Dienst-Typs enthalten.
  • UPnP-SSDP-Pegel-Suchen und -Ergebnis
    Figure 00360001
  • SSDP spezifiziert einen Dienst-Typ (ST), einen Hinweis-Typ (NT) und eindeutige Dienst-Namen-(USN)-Header-Felder für Fragen und für Anzeigen. UPnP verwendet den ST oder den NT-Header, um eine der UPnP definierten Identifizierer zu tragen. Ein eindeutiger USN ist für jede eindeutige SSDP-Anzeige erforderlich.
  • Mehrere Fälle desselben Namen-Dienst-Typs innerhalb einer gesteuerten Vorrichtung 106–107 oder einer Brücke 120 werden nicht unabhängig angezeigt.
  • UPnP-Such-Identifizierer werden während des Entdeckungs-Vorgangs verwendet. Das Ergebnis einer erfolgreichen Entdeckung ist eine oder sind mehrere Beschreibungs-URLs. Das Format für Such-Identifizierer ist:
  • Figure 00370001
  • UPnP-Such-Identifizierer
    Figure 00370002
  • SSDP spezifiziert, dass SSDP-Anzeigen für alle SSDP-suchbaren Werte vorgenommen werden müssen. SSDP-Anzeigen mit "alle" als der Hinweis-Header-Wert müssen die Root-Vorrichtungs-UDN als den USN-Header-Wert tragen. SSDP-Anzeigen für einen Vorrichtungs-Typ müssen den UDN der Root-Vorrichtung, verknüpft mit dem Vorrichtungs-Typ URI, als den USN-Header-Wert, tragen. SSDP-Anzeigen für einen Dienst-Typ werden den UND der Root-Vorrichtung, verknüpft mit dem Dienst-Typ-URI-Wert, als den USN-Header-Wert, tragen. SSDP-Anzeigen von UDNs werden den UDN-Wert als den USN-Header wiederholen.
  • UPnP-SSDP-Anzeigen
    Figure 00380001
  • UPnP-Brücken 120 (2) zeigen überbrückte Vorrichtungen 122–123 und zugeordnete Dienste, unter Verwendung von SSDP, an. Die Identifizierer, die den überbrückten Vorrichtungen zugeordnet sind, sind eindeutig für die Vorrichtung, und sie duplizieren keine Identifizierer für gesteuerte Vorrichtungen und Dienste, die direkt an der Brücke selbst verfügbar sind. Dies bedeutet, dass eine Brücke, die auch eine gesteuerte Vorrichtung ist, überbrückte Vorrichtungen und lokale, gesteuerte Vorrichtungen unabhängig anzeigen muss, mit geeigneten, eindeutigen Identifizierern, Beschreibungs-Dokumenten und zugeordneten URLs.
  • Beschreibung
  • Das UPnP-Beschreibungs-Dokument 226 (3) liefert die Informationen, die dazu notwendig sind, eine UPnP gesteuerte Vorrichtung 106–107 oder eine Brücke 120, von einem Benutzer-Steuer-Punkt 104–105 aus, zu identifizieren, zu beschreiben, zu verbinden und zu steuern.
  • Das Beschreibungs-Dokument ist ein XML-Dokument. UPnP definiert die Verwendung von HTTP und XML für das Beschreibungs-Dokument und verdrahtete Protokolle. UPnP hängt sich an die Schema-Deklarations-Regeln von XML-Data und Y. Goland, „Flexible XML Processing Profile", an.
  • Die XML-Elemente des oberen Niveaus werden in drei Kategorien aufgeteilt: pro Vorrichtung, pro Dienst und gemeinsam geteilt.
  • Rehydrator
  • Wie nun die 7 zeigt, geben alle (UPnP) gesteuerte Vorrichtungen 106–107 (1) oder Brücken 120 (2) einen oder mehrere Dienst(e) 210–217 (3) frei, die entfernt gesteuert werden können. Eine Steuerung von solchen Diensten umfasst einen Nachrichten-Austausch zwischen einem Benutzer-Steuer-Punkt 104 und der Vorrichtung 106. Dieser Nachrichten-Austausch tritt entsprechend einem spezifischen Dienst-Steuer-Protokoll (SCP) 402 auf, das den Inhalt und die Folge der Nachrichten, die ausgetauscht sind, spezifiziert.
  • Benutzer-Steuer-Punkte 104 sind nicht dahingehend erforderlich, dass sie irgendeine frühere Kenntnis der SCPs 402, erforderlich dazu, den Dienst an den verschiedenen Vorrichtungen zu steuern, haben. Deshalb muss eine gesteuerte Vorrichtung oder Brücke in der Lage sein, zu einem Benutzer-Steuer-Punkt die Protokolle, die erforderlich dazu, seine Dienste zu steuern, zu beschreiben, so dass der Benutzer-Steuer-Punkt in der Lage sein wird, diese Protokolle dynamisch umzusetzen. Dies erfordert eine Standard-Art eines Erklärens von Dienst-Steuer-Protokollen in einer übereinstimmenden und eindeutigen Weise. UPnP führt eine Technik zum Erklären von Dienst-Steuer-Protokollen unter Verwendung einer Reihe von XML-Dokumenten ein.
  • Ein Rehydrator 410 ist ein Modul, das eine geeignete API zu Anwendungen freigibt und entweder Befehle an einem Dienst aufruft oder den Zustand dieses Dienstes abfragt, oder Ereignisse empfängt oder auf diese antwortet. Die primäre Aufgabe des Rehydrators ist diejenige, zwischen API-Anrufen und der Dienst-Steuer-Protokoll-Sequenz, die den Befehl aufruft, aufzulisten.
  • Als Teil der Dienst-Definition 406 sind eine Dienst-Zustands-Tabelle 230 und ein Befehl-Satz 408 definiert. Diese Dinge können in einer deterministischen Art und Weise, definiert durch UPnP, kombiniert werden, um eine Dienst-Steuer-Protokoll-Definition (SCPD) 406 zu erzeugen, die eine Dienst-Steuer-Deklaration 404 und ein Dienst-Steuer-Protokoll 402 umfasst. Die SCPD 406 ist eine Darstellung des Schemas eines Dienstes. Es ist möglich, die SST, den Befehl-Satz und das SCP von der SCPD zu rekonstruieren.
  • Die SCPD ist direkt in das Beschreibungs-Dokument 226 einer gesteuerten Vorrichtung eingebettet. Wenn das Beschreibungs-Dokument in den Benutzer-Steuer-Punkt 104 hochgeladen wird, kann der Rehydrator 410 die SCPD davon extrahieren. An diesem Punkt besitzt der Rehydrator genug Informationen, um dienstspezifische SCPs 402 auszugeben.
  • Allgemeine Operation des Rehydrators
  • Wie allgemeiner unter Bezugnahme auf 8 erläutert wird, arbeitet der Rehydrator 410 als ein universeller Adapter, um eine programmatische Schnittstelle zu irgendeinem dienstspezifischen Protokoll einer entfernten Rechenvorrichtung zu schaffen. Der Rehydrator 410 erhält einfach eine Daten-Beschreibung oder eine Deklaration der Verfahren, der Eigenschaften und der Ereignisse des entfernten Dienstes, ebenso wie eine Definition des Protokolls der Netzwerk-Daten-Nachrichten, über die der Rehydrator die Verfahren, die Abfragungen oder die Sätze der Eigenschaften aufruft und Ereignis-Hinweise empfängt. In UPnP nimmt diese Daten-Beschreibung die Form des Beschreibungs-Dokuments 226 an, das einen Kontrakt 412 enthält. Der Kontrakt definiert Netzwerk-Daten-Pakete 413 (z. B. XML-Daten), Anforderungs/Antwort-Muster und ein Protokoll (z. B. GENA, HTTP, SSDP), über die die Pakete ausgetauscht werden. Diese Informationen sind für den Rehydrator ausreichend, um die geeigneten Netzwerk-Daten-Pakete auszutauschen, um mit dem Dienst der gesteuerten Vorrichtung zusammenzuarbeiten, einschließlich eines Aufrufens von Befehlen, Frage- und Einstellungs-Eigenschaften, und Empfangen von und Antworten auf Ereignisse, ohne irgendeinen ausführbaren Code zu der Vorrichtung des Benutzer-Steuer-Punkts 104 herunterzuladen und ohne Installations- oder Konfigurations-Erfahrung.
  • Das Beschreibungs-Dokument 226 umfasst auch eine Deklaration der Verfahren, der Eigenschaften und der Ereignisse für den Dienst. Basierend auf dieser Deklaration erzeugt der Rehydrator eine entsprechende Programmier-Schnittstelle zur Verwendung durch Anwendungen an dem Benutzer-Steuer-Punkt. Die Programmier-Schnittstelle ist eine Anwendungs-Programmier-Schnittstelle, die in der Form einer Integrations-Schnittstelle eines Objekt-orientierten Programmier-Modells, wie beispielsweise Microsoft COM, COBRA, Java Klassen, Skriptbildungs-Maschinen-Namen-Erweiterungen, vorliegen kann. In dem Beispiel, das in 8 dargestellt ist, gibt der Rehydrator 410 eine COM-Objekt-Integrations-Schnittstelle („ICoock" Schnittstelle 414) frei, mit Verfahren getTime() und setTime(), für eine gesteuerte Vorrichtung, die einen „Clock" Dienst mit GetTime und SetTime Befehlen besitzt. Der Rehydrator 410 wandelt Aufrufe nach einem Anwendungs-Programm 416 zu der ICoock Schnittstelle 414 in die Netzwerk-Daten-Nachrichten, spezifiziert in dem Kontrakt, um, um die entsprechenden Befehle des Clock-Dienstes aufzurufen. Der Rehydrator 410 erzeugt in ähnlicher Weise geeignete, weitere Programm-Schnittstellen für andere Dienste (z. B. für Dienste 210–217 der 3), und zwar basierend auf dem Beschreibungs-Dokument deren jeweiliger, gesteuerter Vorrichtungen.
  • Dementsprechend arbeitet der Rehydrator als ein universelles Proxy-Objekt mit einer durch Daten gesteuerten Konversion von programmatischen Schnittstellen zu Netzwerk-Daten-Nachrichten. Weiterhin erzeugt der Rehydrator die programmatische Schnittstelle an dem Benutzer-Steuer-Punkt basierend nur auf einer XML-Daten-Beschreibung. Dieser Vorgang ermöglicht dem Rehydrator, Übergangs-Schnittstellen „just-in-time" zu entfernten Vorrichtungs-Diensten ohne die Komplexität von Code-Herunterladungen und einer Installation oder Konfiguration zu erzeugen. Unter einer späteren Freigabe der Schnittstelle durch die Anwendung zerstört der Rehydrator die Schnittstelle, ohne das Erfordernis, dauerhafte Konfigurations-Daten in einer Ausrichtungs- oder Konfigurations-Datei des Betriebssystems oder der Objekt-Ausführungs-Laufzeit zu deinstallieren oder zu entfernen.
  • Rehydrator-Ausführung
  • Zusammenfassung. Wie 9 zeigt, ist eine bevorzugte Ausführung 440 des Rehydrators 410 wie eine interne Komponente von Microsoft Windows, die Dienst-Steuer-Anforderungen von der UPnP-API zu Vorrichtungen weiterführt. Anwendungen, die es wünschen, einen Dienst auf einer UPnP-Vorrichtung zu steuern, erhalten ein Dienst-Objekt über die UPnP-API und verwenden die Verfahren dieses Objekts, um die Zustands-Variablen des Dienstes abzufragen und seine Aktionen aufzurufen. Diese Verfahren verwenden die Privat-Rehydrator-API, um die Dienst-Steuer-Anforderungen in Netzwerk-Nachrichten umzusetzen, die zu der UPnP-Vorrichtung laufen. In diesem Sinne führt der Rehydrator eine Auflistung zwischen API-Aufrufen und Netzwerk-Protokollen durch.
  • Basis-Funktionalität. Die bevorzugte Umsetzung des Rehydrators ist in der Lage, einen Dienst-Steuer-Ruf zu der UPnP-API in geeignete Netzwerk-Nachrichten, definiert durch das Dienst-Steuer-Protokoll, umzusetzen.
  • Asynchron-Ereignis-Hinweis. Die bevorzugte Umsetzung des Rehydrators ist in der Lage, UPnP-API-Clients über irgendwelche asynchronen Ereignisse, erzeugt durch die Vorrichtungen, die sie kontrollieren, hinzuweisen. Ein Ereignis-Hinweis wird mittels der Ereignis-Schnittstellen, definiert nachfolgend, vorgenommen.
  • Fehler-Bericht. Aus einer Vielzahl von Gründen können Zustands-Variablen-Fragen und Aktions-Aufrufe fehlschlagen. Die bevorzugte Ausführung des Rehydrators ist in der Lage, eine Art und Weise zu schaffen, um die Folge oder den Fehler-Status solcher Operationen zu Parteien, die ihn initiieren, zu kommunizieren.
  • Rehydrator-Ausführungs-Design. Wie in 9 dargestellt ist, wird die bevorzugte Ausführung des Rehydrators auf zwei Arten und Weisen verwendet. Zuerst verwendet der Vorrichtungs-Finder 450 ihn, um Dienst-Objekte 460 zu erzeugen. Dann verwenden diese Dienst-Objekte ihn, um Dienst-Steuer-Operationen (abfragende Zustands-Variable und aufrufende Aktionen) auszuführen.
  • Erzeugen von Dienst-Objekten. Wenn der Vorrichtungs-Finder 450 ein Vorrichtungs-Objekt erzeugt, ruft er den Rehydrator 410 auf, um Dienst-Objekte 460 für jeden der Dienst-Fälle auf dieser Vorrichtung zu erzeugen. Jeder Dienst-Fall unterstützt ein bestimmtes Dienst-Steuer-Protokoll und der Rehydrator benötigt eine Beschreibung dieses Protokolls, um ein geeignet hydriertes Dienst-Objekt zu erzeugen.
  • Das Dienst-Steuer-Protokoll wird in zwei separaten XML Dokumenten deklariert: das DCDP und der Kontrakt. Der Rehydrator benötigt die Informationen in beiden Dokumenten. Diese zwei Dokumente werden zu dem Rehydrator als IXMLDOMDocument Schnittstelle-Hinweiszeiger in dem RehydratorCreateServiceObject() API-Ruf geführt.
  • Figure 00420001
  • Diese API führt einen Hinweiszeiger zu einer IUPnPService Schnittstelle auf einem neu erzeugten Dienst-Objekt zurück. Zusätzlich zu der Erzeugung des Dienst- Objekts stellt der Rehydrator seine interne Daten-Strukturen so ein, dass er geeignet Anforderungen, um den Dienst zu steuern, handhaben kann. Genauer gesagt erzeugt er eine Liste der Eigenschaften und Aktionen, die durch den Dienst unterstützt werden. Da alle Dienst-Fälle von demselben Dienst-Typ dieselben Eigenschaften und dieselben Aktionen exportieren, werden diese Informationen nur einmal für jeden Dienst-Typ gehalten und werden durch den Dienst-Typ-Identifizierer indexiert.
  • Der Rehydrator speichert die Informationen, die für einen bestimmten Dienst-Vorgang spezifisch sind, als private Daten innerhalb des Dienst-Objekts selbst. Dies umfasst den Steuer-URL und die Informationen über den Steuer-Server 232 (wie beispielsweise der HTTP Verbs sie unterstützt). Der Dienst-Typ-Identifizierer ist die Verknüpfung zwischen dem Dienst-Objekt, das einen Fall eines Dienst-Typs darstellt, und den internen Daten-Strukturen des Rehydrators, der Informationen enthält, die für alle Fälle dieses Dienst-Typs gemeinsam sind. Der Dienst-Typ-Identifizierer ist als ein Privat-Daten-Element in dem Dienst-Objekt gespeichert.
  • Abfragende Dienst-Eigenschaften. Anwendungen können die Werte der Dienst-Eigenschaften abfragen, durch Aufrufen des IUPnPService::GetProperty() Verfahrens an einem Dienst-Objekt. Intern nimmt dieses Verfahren einen Ruf nach der RehydratorQueryStateVarable() Funktion vor.
  • Figure 00430001
  • Die ersten zwei Parameter zu dieser Funktion führen die spezifischen Informationen für den Dienst-Vorgang zu: das HTTP Verb, um URL zu verwenden und zu steuern, zu dem die Netzwerk-Nachrichten zielmäßig gerichtet werden. Der dritte Parameter ist der Dienst-Typ-Identifizierer, der dazu verwendet werden wird, die Dienst-Steuer-Protokoll-Informationen in den internen Daten-Strukturen des Rehydrators zu lokalisieren. Der vierte Parameter ist der Name der Variablen, die abgefragt werden wird (der Rehydrator wird diesem gegenüber den Variablen seiner in ternen Zustands-Liste durch den Dienst für gültig erklären), und der abschließende Parameter ist die Adresse einer VARIANT Struktur in der der Rehydrator den Wert der Variablen platzieren wird.
  • Diese Funktion wird eine HTTP-Anforderung zu dem Steuer-Server auf der Vorrichtung erzeugen. Das Grundgerüst dieser Anforderung wird ein XML-Fragment sein, das eine XOAP-codierte Anforderung für den Wert der Variablen enthält. Das Nachfolgende ist ein Beispiel einer solchen Anforderung (der exakte Header und das Payload-Format dieser Nachricht ist in dem Dienst-Kontrakt definiert):
  • Figure 00440001
  • Der Steuer-Server wird auf diese Nachricht mit einem anderen XML-Fragment antworten: die XOAP-codierte Verfahrens-Antwort. Das Nachfolgende ist ein Beispiel einer solchen Antwort:
  • Figure 00440002
  • Figure 00450001
  • Der Rehydrator wird den Rückführ-Wert von diesem XML-Fragment extrahieren, ihn in der VARIANT Struktur platzieren, deren Adresse als der letzte Parameter zu RehydratorGetServiceProperty() geführt wurde, und geht dann zurück.
  • Aufrufen von Dienst-Aktionen Der Vorgang eines Aufrufens einer Dienst-Aktion ist sehr ähnlich zu einem Abfragen einer Zustands-Variablen. Eine Anwendung ruft IUPnPService::InvokeAction() auf einem Dienst-Objekt, unter Weiterführen in dem Namen einer Aktion, auf, um aufzurufen, und eines Felds von Argumenten für die Aktion. Intern ruft IUPnPService::InvokeAction() RehydratorInvokeServiceAction() auf, erklärt so, wie dies nachfolgend dargestellt ist.
  • Figure 00450002
  • Die für den Dienst-Fall spezifischen Informationen werden, wie dies der Fall beim Abfragen von Zustands-Variablen der Fall war, in die ersten zwei Parameter geführt, gefolgt durch den Dienst-Typ-Identifizierer in dem dritten. Der Aktions-Name und ein Feld von Argumenten werden als die nächsten zwei Parameter weitergeführt, und der End-Parameter ist die Adresse einer Variablen, in der der Status der Operation zu speichern ist.
  • RehydratorInvokeServiceAction() wird eine HTTP-Anforderung zu dem Steuer-Server, identifiziert durch den zweiten Parameter, schicken. Wie zuvor wird die Grundstruktur dieser Nachricht ein XML-Fragment sein, das einen XOAP-codierten Verfahrens-Aufruf enthält. Eine beispielhafte HTTP-Anforderung, um eine Aktion aufzurufen, ist nachfolgend dargestellt.
  • Figure 00450003
  • Figure 00460001
  • Das Codieren der Grund-Struktur dieser Nachricht wird wiederum in dem Dienst-Kontrakt spezifiziert. Der Rehydrator wird auf die HTTP-Antwort auf diese Anforderung warten, die manchmal ähnlich dem Beispiel nachfolgend sein würde.
  • Figure 00460002
  • Nach Empfangen einer Antwort, wie diese, wird der Rehydrator den Rückführ-Wert extrahieren, ihn in dem Aus-Parameter, der hindurchgeführt wurde, platzieren, und dann zurückkehren.
  • Die 31 bis 43 zeigen Programm-Auflistungen, die verschiedene Schnittstellen, verwendet in der bevorzugten Ausführung des Rehydrators, definieren, einschließlich von IUPNPDevice Interface, eine IUPNPPropertyBag Interface, eine IUPNPService Interface, eine IUPNPDevices Interface und eine IUPNPServices Interface.
  • Beschreibungs-Dokument
  • Wie 13 zeigt, können Benutzer-Steuer-Punkte 104 ein Beschreibungs-Dokument 226 durch Ausgeben eines HTTP GET auf einem Beschreibungs-URL aufsuchen. Dieser URL wird in dem Stellen-Header entweder einer SSDP-Anzeige oder einer SSDP-Frage-Antwort zurückgeführt.
  • Das HTTP GET muss einen Annahme-Sprach-Header umfassen, der verwendet wird, um die bevorzugte Sprache für die Antwort anzufordern. Falls die angeforderte Sprache nicht unterstützt wird, kann ein Beschreibungs-Dokument in der Voreinstellungs-Sprache, unterstützt durch die gesteuerte Vorrichtung oder die Brücke, zurückgeführt werden.
  • Ein HTTP GET wird dazu verwendet, Unterelemente eines Beschreibungs-Dokuments aufzusuchen, die als URLs ausgedrückt werden.
  • URL-Handling
  • URLs, eingebettet in Beschreibungs-Dokumente 226, nehmen eine von 3 Formen an: ein vollständig qualifizierter URL oder ein relativer URL.
  • Vollständig qualifizierte URLs nehmen die Form an:
    http://devicename/pathname
  • Der devicename Teil des URL ist ein Hostname oder eine IP-Adresse und der pathname ist ein Dateisystem-Pfad oder ein Äquivalent. Ein vollständig qualifizierter URL wird „so wie er ist" verwendet, um eine HTTP-Verbindung zu einer Vorrichtung einzurichten.
  • Ein relativer URL enthält nicht das „:" Zeichen und ist von der Form:
    pathname
    /pathname
  • Relative URLs sind eine kompakte Darstellung der Stelle einer Ressource relativ zu einem absoluten Basis-URL. Alle relativen URLs in einem Beschreibungs-Dokument sind an den Wert des Beschreibungs-Dokumenten-Elements <URLbase> angehängt, um vollständig qualifizierte URLs zu bilden.
  • Binäre Daten
  • Einige Elemente eines Beschreibungs-Dokuments sind binär. XML unterstützt nicht direkt das Einbetten von binären Daten. Um binäre Daten direkt in einem Beschreibungs-Dokument einzuschließen, muss man die Daten zu einem Text unter Verwendung des Codier-Schemas Base 64 konvertieren. Dies führt zu einer Erhöhung der Größe der Daten um 25% im Durchschnitt. Ein Großteil dieses Overheads kann dann beseitigt werden, wenn die binären Daten unter Referenz, anstelle durch einen Wert, weitergeführt werden. Um auf binäre Daten Bezug zu nehmen, ist ein URL zu den Daten in dem Beschreibungs-Dokument vorgesehen. Die binären Daten können aufgesucht werden, indem ein HTTP GET mit diesem URL genommen wird.
  • Als ein Beispiel wird das Element <image> in dem folgenden Beschreibungs-Dokument betrachtet:
  • Figure 00480001
  • Das icon würde mit einem HTTP GET des folgenden Formats aufgesucht werden:
  • Figure 00480002
  • Die HTTP-Antwort würde ähnlich aussehen wie:
  • Figure 00480003
  • Beschreibungs-Dokument-Layout
  • Das Basis-Layout des Beschreibungs-Dokuments 226 ist in 14 dargestellt.
  • Die folgende Tabelle listet Beschreibungs-Dokument-Elemente auf, die Unterelemente zu dem Root-Element sind.
  • Figure 00490001
  • Figure 00500001
  • Figure 00510001
  • Figure 00520001
  • 15 stellt eine beispielhafte Icon-Liste in einem Beschreibungs-Dokument (Description Document) 226 dar.
  • Dienst-Steuer-Protokoll und SCP-Deklaration
  • Als ein Teil der Dienst-Definition 406, dargestellt in 7, sind eine Dienst-Bestands-Tabelle (Service State Table) 230 und ein Befehl-Satz (Command Set) 408 definiert. Der SCPD 406 ist eine Darstellung des Schemas eines Dienstes. Es ist möglich, die SST 230, den Befehl-Satz 408 und SCP 402 von der SCPD zu rekonstruieren.
  • Die Deklaration eines solchen Protokolls muss die Liste von Variablen, die abgefragt werden können, den Satz von Befehlen, der aufgerufen werden kann, ebenso wie das Verdrahtungs-Protokoll (den Inhalt und die Sequenz von Netzwerk-Nachrichten), erforderlich, um diese Operationen auszuführen, spezifizieren. SCPD wird in zwei XML-Dokumenten spezifiziert. Das erste oder Dienst-Steuer-Definitions-Dokument 404, geschrieben in einer Sprache, bezeichnet als Dienst-Steuer-Protokoll-Deklarations-Sprache (Service Control Protocol Declaration Language – SCPDL), erklärt die Liste von Zustands-Variablen und -Befehlen, die dem Dienst-Typ zugeordnet sind, um durch das Protokoll gesteuert zu werden. Das zweite oder Dienst-Steuer-Protokoll-Dokument 402 ist in einer Kontrakt-Definitions-Sprache (Contract Definition Language – CDL) geschrieben und erklärt das Verdrahtungs-Protokoll, das dazu verwendet werden wird, die Werte der Zustands-Variablen abzufragen und die Aktionen, die dem Dienst zugeordnet sind, aufzurufen.
  • Erklärung der Dienst-Zustands-Tabelle und des Befehl-Satzes
  • Ein SCPDL-Dokument 404 wird dazu verwendet, die Liste von Zustands-Variablen, die ein SCP abfragen kann, und den Satz von Befehlen, den er aufrufen kann, zu spezifizieren. SCPDL ist ein XML-Schema, ein Satz von Regeln zum Schreiben von XML-Dokumenten (Service Control Protocol Declarations).
  • 16 stellt ein beispielhaftes SCPDL-Dokument dar. Dieses XML-Dokument besteht aus einem Root <SCPD> Element, das zwei Unterelemente, <serviceStateTable> und <actionList>, enthält. Weiterhin ist das <serviceStateTable> Element ein <StateVariable> Element für jede Zustands-Variable, die dem Dienst zugeordnet ist. Der Dienst in diesem Beispiel ist ein TV-Tuner, der nur eine Zustands-Variable, currentChannel, besitzt. Die Elemente innerhalb des Elements <StateVariable> spezifizieren den Namen, den Daten-Typ und zugelassene Werte für die Zustands-Variable. Hätte der Dienst mehr Zustands-Variablen, würden sie durch zusätzliche Elemente <StateVariable> innerhalb des Elements <deviceStateTable> dargestellt werden.
  • Das Element <actionList> enthält ein Element <action> für jede Aktion, die dem Dienst zugeordnet ist. Die Elemente innerhalb eines Elements <action> spezifizieren den Namen der Aktion und irgendwelcher Argumente, die die Aktion annehmen kann. In diesem Fall unterstützt der Dienst zwei Aktionen, die keine Argumente annehmen, ChannelUp und ChannelDownChannel, und eine andere, SetChannel, die eine neue Kanal-Zahl als ein Argument annimmt. Das Element <argument> und die Elemente, die innerhalb davon eingebettet sind, definieren das Argument. Das Element <relatedStateVariable> innerhalb von <argument> spezifiziert den Namen einer der Zustands-Variablen, zu denen das Argument in Bezug gesetzt ist. In dem UPnP-Vorrichtungs-Modell müssen alle Argumente zu Aktionen direkt derselben Zustands-Variablen entsprechen.
  • Deklarieren des Kontrakts
  • Der Kontrakt ist eine Spezifikation des Verdrahtungs-Protokolls, das dazu verwendet werden wird, Zustands-Variablen abzufragen, Befehle aufzurufen und Hinweise oder Ereignisse zu befördern. Dieser Kontrakt spezifiziert den Typ eines Protokolls, das verwendet ist, den Netzwerk-Endpunkt, zu dem Nachrichten geschickt werden, die Inhalte dieser Nachrichten, die Inhalte der erwarteten Antworten und die Inhalte von Ereignissen. Kontrakte sind in der Kontrakt-Definitions-Sprache (Contract Definition Language – CDL) geschrieben.
  • Alle UPnP-SCPs werden im Wesentlichen denselben Kontrakt verwenden. Ein spezifischer Kontrakt gilt für einen einzelnen Dienst-Fall (da er den Netzwerk-Endpunkt spezifiziert, zu dem Nachrichten geschickt werden, und Netzwerk-Endpunkte sind spezifisch für Dienst-Fälle). Allerdings sollten, anders als die Netzwerk-Endpunkt-Definition, alle Kontrakte für alle Dienst-Fälle dieselben sein.
  • Die 17 bis 19 stellen einen beispielhaften Kontrakt dar. Dieser Kontrakt definiert zwei Verfahren: queryStateVariable und invokeAction. Diese Verfahren werden durch Austauschen von XML-Nachrichten mit einem Steuer-Server auf einer UPnP gesteuerten Vorrichtung oder Brücke aufgerufen. Der Kontrakt definiert vollständig den Header und ein Payload jeder Nachricht. Durch Weiterführen der geeigneten Argumente zu diesen Verfahren können irgendwelche Zustands-Variablen, deklariert in der SCPDL-Deklaration, abgefragt werden und irgendwelche der Aktionen können aufgerufen werden.
  • Die 20 und 21 stellen ein XML-Schema für die SCPDL dar.
  • Basis-UPnP-Ereignis-Architektur
  • Wie 22 zeigt, erfordert die UPnP-Architektur 200 (3), dass Clients der UPnP-API freigegeben werden, um Hinweise zuverlässig von UPnP-Diensten 210–217 zu empfangen, wenn sich deren Zustände ändern. Da Zustands-Änderungen relativ üblich sind, ist das Ereignis-Untersystem effektiv und eine Funktion ist ein Haupt-Punkt in diesem Design. 22 und die folgende Diskussion beschreiben die Basis-UPnP-Ereignis-Architektur 600, die sowohl die gesteuerte Vorrichtung (CD) 106 als auch die Steffen des Benutzer-Steuer-Punkts (UCP) 104 des Ereignis-Dienstes umfasst. Sie umfasst auch die unterstützenden APIs für sowohl eine Dienst-Interaktion mit niedrigem Niveau als auch eine auf COM basierende Wrapper auf hohem Niveau dieser APIs. Der letztere ermöglicht Automations-Steuerungen ähnlich Visual Basic und Jscript 602, um Ereignis-Hinweise aufzunehmen.
  • Was ist ein Ereignis?
  • Property- bzw. Eigenschafts-Änderungs-Ereignisse sind als irgendeine Änderung in dem Wert einer Reihe der Vorrichtungs-Zustands-Tabelle (Device State Table – DST) 230 (3) für einen Dienst 210–217 definiert. Diese Änderung wird als ein Property-Änderungs-Hinweis reflektiert. Zum Beispiel kann, falls eine „VCR" Vorrichtung einen „VCR-Transport" Dienst besitzt, eine Reihe in dieser DST dieses Dienstes TapeState sein und der Wert könnte TapePresent sein. Falls das Band ausgestoßen wird, würde der neue Wert TapeAbsent sein. Diese Zustands-Änderung würde als ein Hinweis, geschickt zu alten Teilnehmern, reflektiert werden.
  • Was ist ein Hinweis?
  • Ein UPnP-Ereignis-Hinweis ist eine XML-Nachricht, geschickt über HTTP/TCP, zu jedem und allen Teilnehmern an einen bestimmten UPnP-Dienst. Der Inhalt der XML ist nachfolgend definiert. Die wichtigen Inhalte dieser Nachricht sind der eindeutige Identifizierer für die Teilnahme bzw. Subskription, der Eigenschafts- bzw. Property-Name, ein neuer Wert und der Property-Typ.
  • Hinweis-Verarbeitung
  • In UPnP ist der Hörer von Hinweisen der SSDP-Dienst selbst. SSDP hört bereits auf eine andere Multicast-Adresse für „alive" und „beybey" Nachrichten, geschickt durch UPnP-Vorrichtungen. Derselbe Hörer wird auf einen TCP-Port auf Hinweise, die geschickt sind, hören. Alle Subskriptionen, geschickt von dem UCP, enthalten denselben Callback-URL, und so werden alle Hinweise zu diesem URL gerichtet werden. Wenn ein Hinweis ankommt, wird der SSDP-Dienst den NT-Header der Nachricht prüfen und bestimmen, ob dies ein Ereignis-Hinweis ist. Falls dies so ist, wird die Nachricht weiter analysiert, um zu bestimmen, ob sie weiter zu den Subscribern (Teilnehmern) (die existieren müssen) zu führen ist. GENA definiert das Format der HTTP-Nachricht, welche Header verwendet werden können, und für was sie verwendet werden können.
  • GENA
  • GENA ist das Protokoll einer Kommunikation, das, in einer bevorzugten Ausführungsform, UPnP-Vorrichtungen verwendet, um Ereignis-Hinweise zu senden. Deshalb werden UPnP-Vorrichtungen, die wünschen, UCPs über Zustands-Änderungen zu informieren, empfohlen, GENA zu verwenden. Hinweis-Subscriber bzw. Teilnehmer werden niemals aufgefordert werden, mit einer UPnP-Vorrichtung direkt in Wechselwirkung zu treten, und so wird von ihnen nicht gefordert, GENA zu verwenden. Die Ereignis-API wird diese Komplexität einkapseln. Andere, geeignete Ereignis-Transport-Protokolle können verwendet werden, wie beispielsweise Veröffentfichungs/Subskriptions-Systeme.
  • Empfangen von Hinweisen
  • Anwendungen, geschrieben in C (C Application 604), werden in der Lage sein, das SSDP C API 610 zu verwenden, um Rückrufe zu empfangen, wenn Hinweise durch den SSDP-Dienst verarbeitet werden. Dies ist analog zu SSDP-Clients, die sich für Hinweise registrieren, dass Dienste verfügbar geworden sind. Wenn ein UCP für einen Hinweis registriert, führt er einen Parameter des URL des Dienstes, an dem er interessiert ist, in Empfangs-Hinweise hindurch. Dieser URL wird aus dem Beschreibungs-Dokument für diesen Dienst erhalten. (Wenn ein Dienst auf einer UPnP-Vorrichtung registriert ist, verwendet er diesen URL, um auf Subskriptions-Anforderungen zu hören.)
  • Wenn eine Hinweis-Nachricht durch den SSDP-Dienst-Hörer empfangen ist, wird der SID-Header gegen die Liste von Teilnehmern, die er beibehält, geprüft. Wenn ein Teilnehmer gefunden ist, wird die Callback-Funktion für diesen Teilnehmer aufgerufen, wobei einer der Parameter die Inhalte der Hinweis-Nachricht ist. Der Hinweis-Client, der die Callback-Funktion ausführt, kann diese Nachricht in irgendeiner geeigneten Art und Weise verarbeiten.
  • Hinweis in dem UPnP-API
  • Der UPnP-API 410 ist ein Verbraucher der Basis-C-Schnittstelle, bereitgestellt durch die Komponente des SSDP-C-AP 1610. Um nahtlos zu integrieren, wird die Registrierung von Hinweisen durch das Dienst-Objekt 612 innerhalb des UPnP-Objekt-Modells gehandhabt. Dienst-Objekte werden sich für Hinweise, wenn sie erzeugt sind, registrieren. Dies stellt sicher, dass die DST durch den UPnP-API beibehalten wird und aktualisiert gehalten wird. Sie werden die Rückruf-Funktion, erforderlich durch die Registrierungs-Funktion, ausführen. Falls diese Rückruf-Funktion aufgerufen ist, wird sie diesen Hinweis weiter zu UCPs führen. Die UCPs können in C, C++, VB oder einem Skript-Code geschrieben sein, so dass der Mechanismus zum Weiterführen von Hinweisen unterschiedlich sein kann.
  • Skript-Support
  • Ein Merkmal des dargestellten Ereignis-Systems ist dasjenige, dass es Skript-Sprachen, wie beispielsweise VBScript und JavaScript 602, unterstützt. Für VBScript wird dies durch Vorsehen einer Property (Eigenschaft) an dem Dienst-Objekt vorgenommen, das, wenn es eingestellt ist, den IDispatch-Hinweiszeiger für eine VBScript-Funktion oder ein Unterprogramm enthält, das der Ereignis-Handler sein wird. Wenn der Hinweis-Rückruf des Dienst-Objekts aufgerufen ist, prüft er, um zu sehen, ob dieser IDispatch-Hinweiszeiger eingestellt wurde, und falls dies der Fall ist, ruft er IDispatch::Invoke auf DISPID 0 dieser Schnittstelle auf, um das VBScript-Unterprogramm aufzurufen. Ein äquivalenter Mechanismus ist für Jscript ausgeführt.
  • Ereignis-Untersystem-Technologie
  • UCP – Benutzer-Steuer-Punkt (User Control Point). Ein Teil einer Software, die nach Vorrichtungen sucht und sie steuert.
  • CD – gesteuerte Vorrichtung (Control Device). Eine Hardware- oder Software-Vorrichtung, die ihre Verfügbarkeit über SSDP anzeigt und eine Steuerung durch UCPs ermöglicht.
  • Subscriber (Teilnehmer) – ein UCP, der wünscht, über Ereignis-Änderungen informiert zu werden.
  • Notifying Resource (hinweisende Ressource) (oder einfach „Ressource") – für die Zwecke dieses Dokuments wird dies immer ein Dienst sein, enthalten innerhalb einer UPnP-CD 106.
  • Event Source (Ereignis-Quelle) – ein Dienst, der Ereignisse liefert. UPnP-Dienste sind Ereignis-Quellen. Alle hinweisenden Ressourcen sind Ereignis-Quellen, und vice versa.
  • Event (Ereignis) – Nachricht, erzeugt dann, wenn eine Änderung in den Zustand einer Ressource auftritt.
  • Property (Eigenschaft)) – ein einzelner Eintritt in der Zustands-Tabelle des Dienstes, deren Default Value (Voreinstellungs-Wert) sich ändern kann. Eigenschaften und Ereignisse besitzen immer eine Korrespondenz eins zu eins.
  • Teilnehmen an Ressourcen
  • Integrieren mit der UPnP-API
  • Der UPnP-API 410 gibt verschiedene Schnittstellen frei, mit denen ein Verbraucher Vorrichtungen, Steuer-Dienste finden und aufzählen kann, und Eigenschaften über Vorrichtungen und Dienste erhält. Um die Integration von Ereignissen in dieses Modell zu ermöglichen, fügt man eine neue Property zu der IUPnPService Schnittstelle, bezeichnet als EventHandler, hinzu. Wenn diese Eigenschaft eingestellt ist, teilt sie dem Dienst-Objekt 612 mit, dass deren Client daran interessiert ist, Hinweise für diesen Dienst zu empfangen. Die SSDP-API-RegisterNotification() API wird aufgerufen, wenn das Dienst-Objekt erzeugt ist, so dass es eine lokale Kopie des DST für diesen Dienst beibehalten kann. Das Dienst-Objekt kennt den URL des Dienstes und kann deshalb diesen als einen Parameter zu RegisterNotification() liefern. RegisterNotification() wird auch als eine Rückruf-Funktion vorgesehen, die ein statisches Element der Dienst-Objekt-Klasse ist. Diese Funktion wird für jeden Hinweis, geschickt durch diesen bestimmten UPnP-Dienst, aufgerufen.
  • Der Hinweis-Rückruf
  • Das Dienst-Objekt 612 umfasst eine Statik-Element-Funktion, bezeichnet als EventNotifyCallback(), die für jeden Hinweis, geschickt durch den UPnP-Dienst, aufgerufen wird. Der Rückruf wird die gesamten HTTP-Nachrichten-Inhalte in einer Struktur hindurchführen, die ein Parameter zu der Funktion ist. Der Prototyp sieht ähnlich aus wie:
  • Figure 00590001
  • Der ssdpType Parameter sollte immer SSDP_PROPCHANGE sein. Der pssdpMsg Parameter enthält die relevanten Informationen über das Ereignis. Der Schlüsselteil von Informationen ist der Grundteil der XML-Nachricht. Der Grundteil bzw. Rumpf enthält Informationen darüber, welche Eigenschaft geändert worden ist, was der neue Wert ist und welcher Typ er ist, unter anderen Informationen. Der pContext Parameter wird immer dieser Hinweiszeiger zu dem Dienst-Objekt sein. Dies ermöglicht dem Code, ein Verfahren aufzurufen, um das Ereignis zu dem UCP zu „feuern". Der Rückruf wird den XML-Rumpf unter Verwendung der XML DOM Dienste analysieren. Eigenschafts-Änderungen werden iteriert und der lokale DST wird aktualisiert, um diese Änderungen zu reflektieren. Nachdem diese Verarbeitung vorgenommen ist, kann ein Ereignis-Hinweis für jede Eigenschaft abgegeben werden, die geändert wurde, und zwar zu dem Eigner der Subskription, falls eine existiert. In Abhängigkeit davon, in welcher Umgebung der Eigner eingeschrieben ist (C++ oder Skript, usw....), kann ein unterschiedlicher Mechanismus zum Absenden des Ereignisses eingesetzt werden.
  • Ein spezieller Fall für diesen Vorgang ist der erste Hinweis, der empfangen ist, nachdem eine Subskription eingerichtet ist. Dieser Hinweis enthält den gesamten Satz von Eigenschaften und deren Werte und wird dazu verwendet, lokal die DST zu synchronisieren. Ereignisse werden nicht zu Clients des UPnP API in diesem Fall geschickt werden.
  • Abschicken von Hinweisen
  • Wenn die EventNotifyCallback() Funktion aufgerufen ist, wird die lokale Kopie der DST für den Dienst aktualisiert. Hiernach muss ein Ereignis abgegeben werden, falls ein Teilnehmer existiert. Ein Teilnehmer bzw. Subscriber existiert, falls das put_EventHandler() Verfahren aufgerufen wurde, entweder von dem VBScript, dem C++ Code, oder einer anderen Quelle. Um immer diese Komplexität weg zu abstrahieren, wird eine neue Schnittstelle, bezeichnet als IUPnPEvents, benötigt.
  • Diese Schnittstelle besitzt momentan ein Verfahren, bezeichnet als NotifyEvent(), das verschiedene Parameter (TBS) heranzieht. Wenn die put_EventHandler() Funktion aufgerufen ist, ist deren Argument ein IUnknown. Dieser Hinweiszeiger ist QueryInterface'd() für IDispatch zuerst, und falls er fortschreitet, dann wird IDispatch::Invoke() mit DISPID mit dem Wert 0 aufgerufen, um das Voreinstellungs-Verfahren aufzurufen. Dies ermöglicht, dass VBScript 602 aufgerufen wird. Falls dies allerdings fehlschlägt, ist dies „Queried" für IUPnPEvents, und falls dies fortschreitet, wird das NotifyEvent() Verfahren mit denselben Parametern wie für Invoke() aufgerufen. Dies handhabt C++UCPs effektiv.
  • Subskribieren mit C++
  • Um einen UPnP-Dienst von C++ zu subskribieren, realisiert ein UCP ein UPnP-Dienst-Objekt, gibt QueryInterface() dazu für IUPnPEvents aus, und ruft die IUPnPEvents::SetEventCallback() Funktion auf. Diese Funktion nimmt 2 Parameter, einen Rückruf-Funktion-Hinweiszeiger und einen Kontext-Hinweiszeiger, auf.
  • Subskribieren mit VBScript
  • Um Ereignisse eines UPnP-Dienstes zu subskribieren, ist alles, was durch ein Skript 602 vorgenommen werden muss, dasjenige, eine Funktion oder ein Unterprogramm als eine Handler-Funktion zu erzeugen und den Hinweiszeiger dieser Funktion auf die Eigenschaft EventHandler des Dienst-Objekts einzustellen. Nun wird, zu jedem Zeitpunkt, zu dem ein Ereignis hervorgerufen wird, diese VBScript Funktion oder das Unterprogramm aufgerufen werden. In VBScript wird dies wie folgt geschrieben:
  • Figure 00600001
  • Figure 00610001
  • In diesem Beispiel zählt das Skript alle Vorrichtungen auf, die nach irgendeiner Vorrichtung suchen, die die „Clock" Schnittstelle unterstützt. Wenn sie eine Vorrichtung findet, die diese Schnittstelle unterstützt, zählt sie die Dienste der Vorrichtung auf, die nach der einen suchen, die die „clock.v1" Schnittstelle besitzt. Wenn sie diesen Dienst findet, stellt sie diese EventHandler Eigenschaft des Dienstes auf das VBScript Unterprogramm, bezeichnet als „clock_PropertyChanged", ein. Dieser Name ist wahlweise.
  • Schicken und Empfangen von Hinweisen
  • GENA-Client API
  • GENA-Client sind tatsächlich UPnP Dienste. Ein GENA-Client erzeugt eine neue Ereignis-Quelle, wenn sie initialisiert wird. Der GENA-Client-API 620 führt dies durch. Er liefert auch eine Art und Weise für GENA-Clients, deren Hinweis-Nachrichten zu senden. Es ist auch wichtig, anzumerken, dass der HTTP-Server, der an der UPnP-Vorrichtung vorhanden ist, auch ein Client dieser API ist. Der GENA-Client-API besteht aus den folgenden Funktionen:
  • Register UPnPEventSource()
  • Der RegisterUPnPEventSource() API gibt einem GENA-Client die Fähigkeit, sich selbst als eine Ereignis-Quelle zu registrieren. Der Prototyp ist wie folgt:
  • Figure 00610002
  • Parameter: szRequestUri [in] ein wahlweises Request-Uri, dass SUBSCRIBE-Anforderungen dorthin geschickt werden. Wenn eine SUBSCRIBE-Anforderung an der gegebenen URI ankommt, ist sie bekannt, und der Subscriber wird zu der Liste von Hinweis-Empfängern hinzugefügt. Es ist anzumerken, dass dieser URI zu dem URI passen sollte, der in der Beschreibung für diesen Dienst vorgesehen ist. CProps [in] die Zahl von Eigenschaften, die diese Ereignis-Quelle liefert. RgProps [in] Array of UPNP_Property Strukturen, die Informationen über jede Eigenschaft enthalten. Die Property-Informationen werden aus der DST für die Ereignis-Quelle abgeleitet.
  • Rückführ-Wert: die Funktion führt ein TRUE, falls erfolgreich, zurück. Falls die gegebene URL bereits als eine Ereignis-Quelle registriert worden ist, ist der Rückführ-Wert FALSE und GetLastError() führt ERROR_ALREADY_EXISTS zurück.
  • Anmerkungen: der Anfangs-Zustand der Ereignis-Quelle muss zu der API so gegeben werden, dass er effektiv den Aktualisierungs-Zustand der Ereignis-Quelle beibehalten kann.
  • DeRegisterUpnpEventSource()
  • Die DeRegisterUpnpEventSource() API gibt einem GENA-Client die Fähigkeit, sich selbst als eine Ereignis-Quelle aus dem Register herauszunehmen. Der Prototyp ist wie folgt:
  • Figure 00620001
  • Parameter: szRequestUri [in] ein wahlweises Request-Uri, dass SUBSCRIBE Anforderungen zu senden sind. Wenn eine SUBSCRIBE Anforderung an dem gegebenen URI ankommt, ist sie bekannt, und der SUBSCRIBER wird zu der Liste von Hinweis-Empfängern hinzugefügt. Es ist anzumerken, dass dieser URI zu dem URI, vorgesehen in der Beschreibung für diesen Dienst, passen sollte.
  • UPNP PROPERTY
    Figure 00620002
  • Wo szName der Name der Property ist, ist szValue der momentane Wert von Property, und szType ist der Typ von Property (Zeichenfolge, ganzzahlige Zahl, usw. ...).
  • SubmitUPnpPropertyEvent()
  • Der SubmitUPnpPropertyEvent() API ermöglicht dem GENA-Client, ein UPnP-Property-Änderungs-Ereignis zuzuführen, um es zu Subscribern als einen Hinweis zu schicken. Der Prototyp ist wie folgt:
  • Figure 00630001
  • Parameter: „szRequestUri [in]" identifiziert die Ereignis-Quelle, zu der dieses Ereignis gehört. Dies ist derselbe Request-Uri, weitergeführt zu RequestUPnPEventSource().
  • „DwFlags [in]" ist nicht verwendet. „CProps [in]" ist die Zahl von Ereignissen, die zugeführt werden soll. „RgProps [in]" ist ein Feld von UPNP_PROPERTY Strukturen, die Informationen über jedes Ereignis enthalten.
  • Rückführ-Wert: falls die Funktion fehlschlägt, ist der Rückführ-Wert FALSE. Die erhaltenen, erweiterten Fehler-Informationen rufen die GetLastError() Funktion auf.
  • Anmerkungen: wenn eine Reihe von Eigenschaften für einen Ereignis-Hinweis geliefert wird, wird die lokale Version des Property-Zustands für die gegebene Ereignis-Quelle mit der Liste von Properties, die hineingeführt ist, aktualisiert.
  • SubmitUpnpPropertyEvent() ruft SubmitEvent() auf, nachdem sie einen XML Körper erzeugt hat.
  • SubmitEvent()
  • Die SubmitEvent() API ermöglicht dem GENA-Client, dass ein nicht strukturiertes Ereignis zu Subscribern als ein Hinweis geschickt wird. Der Prototyp ist wie folgt:
  • Figure 00630002
  • Parameter: szRequestUri [in] identifiziert die Ereignis-Quelle, zu der dieses Ereignis gehört. Dies ist derselbe Request-Uri, weitergeführt zu RegisterUpnpEventSource(). DwFlags [in] unbenutzt. SzHeaders [in] eine mit Null beendete Text-Folge, die die Headers für jedes Ereignis enthalten, jedes separiert durch CRLF. SzEvent-Body [in] ist eine mit Null beendete Text-Folge, die den Körper der Ereignis-Nachricht enthält.
  • Rückführ-Wert: falls die Funktion fehlschlägt, ist der Rückführ-Wert FALSE. Die erhaltenen, erweiterten Fehler-Funktionen rufen die GetLastError() Funktion auf. Anmerkungen: falls keine Subscriber existieren, bewirkt die Funktion nichts.
  • Falls einer oder mehrere Subscriber existiert (existieren), wird eine Nachricht zu jedem Subscriber geschickt. SubmitEvent() wird immer zu allen Subscribern geschickt.
  • Mittels UPnP gesteuerte Vorrichtungs-Architektur
  • In UPnP muss jeder UPnP-Dienst 210–211, der Property-Änderungs-Ereignis-Hinweise unterstützt, ein GENA-Client sein. Deshalb muss, wenn der Dienst initialisiert wird, er sich selbst als eine GENA-Ereignis-Quelle registrieren. Er wird dies mit der RegisterUpnpEventSource() API tun. Dies führt einen Handle zurück, der in darauf folgenden APIs verwendet werden kann.
  • RegisterUpnpEventSource() nimmt einen URL und ein Feld von Eigenschaften als Parameter. Innerhalb des API wird ein Eintritt in ein Feld von Strukturen initialisiert und der Index wird als der Handle zurückgeführt. Die Struktur enthält die Quellen-URL als eines der Mitglieder. Ein zweites Mitglied bzw. Element der Struktur, ein Feld von Bestimmungs-URLs, wird nicht initialisiert belassen. Dies wird in jeder Zeit erfüllt, wenn ein Subscriber für diese Ereignis-Quelle hinzugefügt wird. Ein anderes Element der Struktur ist die Liste von Eigenschaften, die diese Ereignis-Quelle liefert. Dies ist effektiv eine cachemäßig gespeicherte Kopie der DST für die Ereignis-Quelle. Wenn Ereignisse zugeführt werden, werden die lokalen Eigenschaften aktualisiert.
  • Wenn SubmitUpnpPropertyEvent() aufgerufen ist, ersetzt jede Property, die zugeführt ist, die entsprechende Property, die bereits durch den API gehalten wird. Falls keine Subscriber existieren, wird die Anforderung, ein Ereignis zuzuführen, ignoriert. Falls einer oder mehrere Subscriber existiert (existieren), werden deren Rückruf-URLs in der Liste von Subscribern nach einer gegebenen Ereignis-Quelle durchgesehen und eine NOTIFY Nachricht wird konstruiert und zu jeder URL, eine zu einem Zeitpunkt, in der Reihenfolge einer Subskription, geschickt. Falls ein Ereignis zugeführt wird und keine Antwort empfangen wird (oder ein CD-seitiger Fehler auftritt), fährt die CD fort, zu versuchen, zu der UPC zu schicken. Falls die Subskription-Ablaufzeit abläuft, dann wird die Subscription entfernt. Falls der UCP erneut verfügbar wird, wird er erneut subskribieren, da er bemerken wird, dass die Folge-Zahlen nicht fortlaufend sind.
  • Wenn ein HTTP-Server 626 eine SUBSCRIBE-Nachricht empfängt, führt er sie weiter zu einer Funktion, die die Nachricht für die notwendigen Informationen analysiert. Die Anforderung URI identifiziert den Dienst, der hinzu subskribiert werden soll. Der Callback-URL wird von dem „Callback" Header erhalten. Da der Callback-Header mehrerer URLs enthalten kann, nimmt er die erste „HTTP://" URL, die er findet, auf. Er fügt dann den Subscriber zu der Liste von Subscribern für diese Ereignis-Quelle hinzu. Ein eindeutiger Subskriptions-Identifizierer wird konstruiert, der zurück zu dem Subscriber in der HTTP-Antwort auf die SUBSCRIBE-Anforderung hin geschickt werden wird.
  • Falls keine Ereignis-Quelle zu der Request-URI von der Subskriptions- Nachricht passt, sollte der HTTP-Server „404 Not Found" zurückführen.
  • Wenn eine Subskription hinzugefügt wird, wird die Lokal-Kopie der DST als eine NOTIFY Nachricht geschickt. Diese spezielle NOTIFY Nachricht enthält eine Sequenz-Zahl 0, die die UCP informiert, dass dies ein Anfangs-Zustands-Populations-Ereignis ist, und nicht ein Hinweis, wo sich jedes Ereignis geändert hat.
  • Wenn eine CD eine UNSUBSCRIBE Nachricht empfängt, prüft sie den „SID" Header, um den Subskriptions-Identifizierer zu erhalten. Sie sieht nach der Subscriber-ID in der Liste der Subscriber für diese Ereignis-Quelle und entfernt den Bestimmungs-URL-Eintritt, der dazu zugeordnet ist.
  • GENA Server API
  • GENA Server 630 sind allgemein so, dass sie zu UPnP UCPs gehen. Ein GENA Server ist irgendetwas, der NOTIFY Nachrichten empfängt und verarbeitet, um Hinweise von Ressourcen zu handhaben, und schickt SUBSCRIBE und UNSUBSCRIBE Nachrichten, um Hinweise von Ressourcen zu empfangen. Diese APIs verbinden die bereits existierenden SSDP APIs. Das Nachfolgende sind die Änderungen zu den APIs:
  • RegisterNotification()
  • Das RegisterNotification() ermöglicht einer UPnP UCP, einen Hinweis anzufordern, wenn ein Ereignis für einen gegebenen UPnP-Dienst auftritt. Der Prototyp ist wie folgt:
  • Figure 00660001
  • Parameter: NT [in] eine Aufzählung, die den Typ eines Hinweises, der angefordert ist, bestimmt. Die Werte sind: SSDP_ALIVE – ein Dienst, der verfügbar geworden ist, und SSDP_PROPCHANGE – eine Property hat sich an dem Dienst geändert. SzResourceType[in] eine mit Null beendete Folge, die den Ressource-Typ, der erwünscht ist, spezifiziert. Für SSDP_ALIVE ist dies der Dienst-Typ, für SSDP_PROPCHANGE ist dies unbenutzt. SzEventUri [in] eine mit Null bestimmte Folge, die den URL spezifiziert, dass eine Subskriptions-Anforderung dazu geschickt werden sollte. FnCallback [in] ein Hinweiszeiger zu einer Funktion, die zu jedem Zeitpunkt aufgerufen werden wird, zu dem ein Hinweis empfangen ist. Der Funktion-Hinweiszeiger ist in der SSDP spec. PContext [in] definiert. Dieser Parameter ist als ein Parameter umfasst, wenn die durch den Client zugeführte Callback-Funktion aufgerufen wird.
  • Rückführ-Wert: falls die Funktion fortschreitet, ist der Rückführ-Wert ein Handle, verwendet in einem darauf folgenden Anruf zu der DeregisterEventNotification() Funktion. Falls die Funktion fehlschlägt, ist der Rückführ-Wert der INVALID_HANDLE_VALUE Fehler-Code. Um erweiterte Fehler-Informationen zu erhalten rufe GetLastError auf.
  • ServiceCallbackFunc
    Figure 00660002
  • Figure 00670001
  • UPnP-UCP Architektur
  • Wenn ein UPnP-UCP wünscht, an Hinweisen für einen bestimmten UPnP-Dienst teilzunehmen, ruft er die RegisterNotification() API auf. Er führt zu dieser API einen Hinweis-Typ, der den Typ eines Hinweises, der angefordert werden soll, identifiziert, einen URL, zu dem eine Subskription geschickt werden sollte, und eine Rückruf-Funktion und einen Kontext zur Verwendung, wenn der Hinweis empfangen wird, zu.
  • RegisterNotification() wird eine SUBSCRIBE Nachricht, unter Verwendung der Daten, die dort hineingeführt sind, zusammensetzen, und diese zu dem URL, spezifiziert durch den Anrufer, schicken. Der Callback-Header der SUBSCRIBE Nachricht wird unterwegs (on the fly) zusammengesetzt werden, als ein wahlweiser URL für Hinweise, die zu dieser Subskription geschickt werden sollen. Dieser Callback-URL wird wahrscheinlich eine Konstante sein, da der Server-API immer wissen wird, wie Anforderungen, geschickt zu dieser URL, zu handhaben sind. Sie wird dann die SUBSCRIBE Nachricht senden und auf eine Antwort warten.
  • RegisterNotification() in der SSDP API schickt momentan nicht HTTP-Anforderungen, sondern sie kann modifiziert werden, um dies vorzunehmen. Sie muss auch auf eine Antwort warten, die sie auch modifizieren wird, um dies so vorzunehmen.
  • Wenn die Antwort empfangen wird, enthält der Subskription-ID-Header eine SID, die zu der Callback-Funktion, spezifiziert durch den Anrufer, zugeordnet ist.
  • Unmittelbar nachdem die Antwort empfangen ist, sollte der UCP eine Anfangs-NOTIFY-Nachricht erwarten, die den vollständigen Satz von Eigenschaften, beibehalten durch die CD, enthält. Dies wird die lokale, cachemäßig gespeicherte DST auf der UCP-Seite. Von diesem Punkt an werden alle Modifikationen zu der Tabelle über NOTIFY Nachrichten vorgenommen. Diese Anfangs-NOTIFY-Nachricht wird die Sequenz-Zahl 0 haben, die anzeigt, dass sie die Anfangs-Property ist, die eingestellt ist, und nicht eine Aktualisierung. Die UPC kann diese Informationen auf irgendeine Art und Weise, die sie sieht, um anzupassen, verwenden. Dies stellt sicher, dass die Zustands-Tabelle der UCP immer synchron zu der einen auf der CD ist.
  • Wenn eine Nachricht durch den HTTP-Server auf der UPnP-UCP empfangen ist, wird sie zu einer Funktion geführt, die den Verfahren-Namen und die Anforderungs-URI bestimmt. Falls dies eine NOTIFY-Nachricht ist, werden die Header analysiert und in eine Struktur gepackt. Diese Callback-Funktion, die zu RegisterNotification() spezifiziert wurde, wird mit dieser Struktur als einer der Parameter aufgerufen. UCPs, die die Callback-Funktion ausführen, können die Header und das Grundgerüst der NOTIFY-Nachricht finden und eine zusätzliche Verarbeitung basierend auf dem Hinweis-Typ vornehmen.
  • Dies erfordert, dass der SSDP-HTTP-Server an einem TCP-Sockel zusätzlich zu dem UDP-Multicast-Port, auf den er bereits gehört hat, hört. Allerdings wird, wenn einmal eine NOTIFY-Nachricht empfangen ist, sie in derselben Art und Weise ungeachtet davon verarbeitet, von welcher Verbindung sie ursprünglich stammte.
  • Handhabungs-Fehler
  • Das Nachfolgende sind Subskription/Hinweis-Fehler, die auftreten können, und deren Lösungen:
  • Abgelaufene Subskriptionen
  • Um gegen Subskriptionen zu schützen, die an der gesteuerten Vorrichtung, allerdings nicht länger auf der UCP, existieren, bildet man das Timeout-Merkmal von GENA-Subskrtptionen. Das Szenarium ist dieses: eine UCP schreibt sich an einer CD ein, wobei dann die UCP erneut bootet. Dabei wird die CD noch versuchen, Hinweise zu dieser UCP zu schicken. Falls die UCP niemals zurückkommt, würde die Subskription abgelaufen sein, da die UCP niemals der CD mitteilte, dass sie wegging. So umfasst, um dies zu korrigieren, jede Subskriptions-Anforderung einen wahlweisen Timeout-Wert, der der CD anzeigt, dass die UCP alle n Sekunden, angezeigt in dem Timeout-Header der Subskriptions-Anforderung, erneut subskribieren wird. Falls der Zeitablauf an der CD abläuft, wird die Subskription entfernt. Von der UCP wird gefordert, sich erneut zu subskribieren, bevor die Timeout-Periode abgelaufen ist. Falls sie es versäumt, dies vorzunehmen, wird die Subskription durch die CD beendet.
  • Eine bestimmte Zeit, bevor der Zeitablauf an der UCP abläuft, sollte eine Wiedereinschreibungs-Nachricht geschickt werden. Die Wiedereinschreibungs-Nachricht ist ähnlich zu der Subskriptions- bzw. Teilnahme-Nachricht, allerdings enthält sie keine NT oder einen Callback-Header. Falls die UCP nicht in der Lage ist, innerhalb der Timeout-Periode erneut zu subskribieren, wird die Subskription durch die CD beendet werden. Falls die UCP eine erneute Subskription sendet, nachdem die CD die Subskription beendet hat, wird die CD „412 Precondition Failed" zurückführen.
  • Erneutes Booten einer gesteuerten Vorrichtung
  • Falls eine gesteuerte Vorrichtung rebootet, würden Informationen über alle deren Subscriber verloren gehen. Um dies zu verhindern, werden die Subscriber-Informationen über Reboot-Vorgänge der Vorrichtung bestehen bleiben. Da das Subskriptions-Info ein Timeout-Element enthält, wird die absolute Ablaufzeit verwendet werden, wenn die Subskriptions-Informationen bestehen bleiben. Auf diese Art und Weise kann, wenn die Vorrichtung wieder zurückkommt, sie das Timeout für jeden Subscriber prüfen, und falls die Zeit vergangen ist, wird die Subskription entfernt werden.
  • Netzwerk-Fehler, Ereignis-Hinweise sendend
  • Falls eine gesteuerte Vorrichtung einen Fehler, einen Ereignis-Hinweis sendend, zu einem Subscriber empfängt, wird sie NICHT aufhören, Hinweise zu schicken. Sie wird fortfahren, Hinweise zu schicken und Fehler zu empfangen, bis die Subskription abläuft. Das Problem für die UCP ist dasjenige, dass sie eine Zahl von Ereignis-Hinweisen vermisst haben wird, und so wird ihre Zustands-Tabelle nicht in Synchronisation sein. Um dies zu korrigieren, wird jede Ereignis-Hinweis-Nachricht einer Folge-Zahl von 32-Bit enthalten, die mit 0 beginnt und sich für jede Nachricht, geschickt zu einem Subscriber, erhöht. Falls ein Subscriber einen Hinweis mit einer Folge-Zahl empfängt, die nicht exakt eins mehr als der vorherige Hinweis ist, wird sie wissen, dass sie Ereignisse verloren hat, und wird alle zukünftige Hinweise ignorieren, bis sie einen solchen mit einer Sequenz-Zahl 0 erneut empfängt. Ereignisse mit einer Sequenz-Zahl 0 zeigen an, dass das Ereignis ein Ereignis in einem „Anfangs-Zustand" ist.
  • Wenn sie realisiert hat, dass sie einen oder mehrere Ereignisse) verloren hat, wird die UCP eine UNSCRIBE Nachricht, gefolgt durch eine SUBSCRIBE Nachricht, schicken. Dies ist nicht dasselbe wie eine erneute Subskription, da erneute Subskriptionen nicht bewirken, dass die CD die Sequenz bei 0 startet. In diesem Fall wird das aktive Nicht-Subskribieren/Subskribieren bewirken, dass die CD erneut die Sequenz bei 0 startet und die gesamte Zustands-Tabelle mit der ersten Hinweis-Nachricht schickt.
  • Die SUBSCRIBE Nachricht
  • Wenn eine UPnP-UCP wünscht, an Ereignis-Hinweisen für einen UPnP-Dienst 210–211 teilzunehmen, wird sie eine SUBSCRIBE Nachricht mit dem folgenden Format bilden:
  • Figure 00700001
  • Die Antwort ist wie folgt:
  • Figure 00700002
  • Dieses Beispiel einer GENA SUBSCRIBE Anforderung und Antwort demonstriert eine Subskription zu Ereignis-Hinweisen für „service1". Der Host ist „vcr.local". Alle Hinweise für diesen Dienst werden zu dem Callback-URL http://danielwe/upnp:923 geschickt werden. Daraufhin stattet der „Subskriptions-ID" Header den Subscriber mit einem Identifizierer aus, um diesen zu verwenden, wenn er wünscht, zu dieser Ressource nicht zu subskribieren. Der „Timeout" Header zeigt an, dass der Subscriber eine Wieder-Subskriptions-Anforderung schicken wird, bevor 10 Minuten abgelaufen sind. Falls die Vorrichtung nicht diese Anforderung innerhalb dieser Zeitperiode empfängt, wird sie die Subskription entfernen.
  • Die Re-SUBSCRIBE Nachricht
  • Wenn eine UPnP-UCP wünscht, sich für Ereignis-Hinweise für einen UPnP-Dienst wieder zu subskribieren, wird sie eine SUBSCRIBE Nachricht mit dem folgenden Format bilden:
  • Figure 00710001
  • Es ist anzumerken, dass die NT- und Callback-Header nicht vorhanden sind, allerdings existiert der SID-Header. Dies teilt der CD 106 mit, welche Subskription erneuert wird, und startet erneut den Zeitablauf (Timeout). Wenn die CD diese Nachrichtempfängt, wird sie die Subskriptionen auf einer Disk aufrechterhalten (oder einem anderen, dauerhaften Datenspeicher-Medium), den absoluten Zeitablauf basierend auf der momentanen Zeit aktualisieren und einen neuen Zeitablauf zu der UCP (falls sie unterschiedlich war) schicken.
  • Die NOTIFY Nachricht
  • Wenn es eine Ressource wünscht, einen Ereignis-Hinweis zu schicken, wird sie eine NOTIFY Nachricht mit dem folgenden Format bilden:
  • Figure 00710002
  • Die Antwort ist wie folgt:
  • Figure 00710003
  • Dieses Beispiel einer GENA NOTIFY Anforderung und Antwort demonstriert, dass ein „upnp:propertychanged" Ereignis zu http://danielwe/upnp:923 geschickt werden soll. Der USN-Header identifiziert „vcr.service1" als die Ereignis-Quelle. Die XML enthält den Property-Namen, Wert und Typ. Der „Seq" Header zeigt die Sequenz-Zahl des Hinweises an. Die Sequenz-Zahl 0 zeigt die Anfangs-Zustands-Aktualisierung für den Subscriber an.
  • Property-Änderungs-Ereignis-XML-Schema
  • Ein UPnP-Property-Änderungs-Ereignis wird in der folgenden Form vorliegen:
  • Figure 00720001
  • Hierbei ist eine Property bzw. Eigenschaft, benannt mit „foo", von dem Typ „string" und besitzt einen Wert von „goodbye", und ein Property, benannt mit „bar", besitzt einen Typ von „integer" und besitzt einen Wert von 27. Die XML wird eine Liste von mehreren Properties enthalten, die geändert worden sind, zusammen mit einer Zählung, um es einfach zu machen, sie zu bestimmen.
  • Die UNSUBSCRIBE Nachricht
  • Wenn eine UPnP-UCP wünscht, nicht an Ereignis-Hinweisen für einen UPnP-Dienst teilzunehmen, wird sie eine UNSUBSCRIBE Nachricht des folgenden Formats bilden:
  • Figure 00720002
  • Die Antwort würde wie folgt sein:
  • Figure 00720003
  • Dieses Beispiel einer GENA UNSUBSCRIBE-Anforderung und Antwort demonstriert, dass der UCP nicht länger daran interessiert ist, Ereignis-Hinweise von http://vcr.local/service1:200 zu empfangen.
  • Step By Step: UCP zu CD & Back
  • Dieser Abschnitt wird eine Maßnahme Schritt für Schritt für das vornehmen, was an beiden Seiten (UCP & CD) eines Ereignis-Hinweises auftritt. Die Beschreibung beginnt bei der Initialisierung einer UPnP-Vorrichtung. 23 stellt den Subskriptions-Hinweis- und Ansubskribtion-Vorgang dar.
    • 1. Eine UPnP-Vorrichtung, bezeichnet als „vcr", initialisiert.
    • a. Sie stellt sich selbst so ein, um ein HTTP-Server zu sein, indem das Folgende vorgenommen wird:
    • i. Sie verbindet sich mit einem TCP-Anschluss-Sockel unter Verwendung dessen IP-Adresse und einer wahlweisen Port-Zahl. Auf dieses Adressen/Port-Paar wird durch alle ankommenden URL-Anforderungen Bezug genommen werden.
    • ii. Sie listet die ankommenden Verbindungs-Anforderungen an diesem Sockel auf und stellt sich selbst so ein, um irgendwelche ankommenden Verbindungen zu akzeptieren.
    • b. Sie stellt sich selbst so ein, dass sie ein HTTP-Client ist, indem das Folgende vorgenommen wird:
    • i. Ruft InternetOpen() auf, um einen Handle zu der Internet-Sitzung zu erhalten.
    • c. Für jeden Dienst, den sie aufdeckt, nimmt sie das Folgende vor:
    • i. Sie ruft die SSDP API RegisterUpnpEventSource() auf, um den SSDP-Server wissen zu lassen, dass er Subskriptionen akzeptieren wird und Ereignis-Hinweise schicken wird. An diesem Punkt besitzt sie keine Subscriber. Es ist anzumerken, dass dies aufgerufen wird, bevor der Dienst sich selbst angezeigt hat, so dass er bereit sein kann, Subskriptionen unmittelbar anzunehmen. RegisterUpnpEventSource() schickt keinen Netzwerk-Verkehr weiter über die Leitung. Es ist nur eine lokale Initialisierung. RegisterUpnpEventSource() nimmt das Folgende vor:
    • 1. Füge eine Struktur zu der Liste von Ereignis-Quellen hinzu, das folgende enthaltend:
    • a. Ein URL, zu dem Subscriber Subskriptions-Anforderungen schicken werden
    • b. Eine Liste von Bestimmungs-URLs. Eine Hinweis-Nachricht wird zu jedem Bestimmungs-URL geschickt werden.
    • c. Die Zustands-Tabelle für die Ereignis-Quelle. Diese Struktur enthält den Property-Namen, -Wert und -Typ für jede Property, unterstützt durch den Dienst.
    • ii. Sie ruft den SSDP API RegisterService() auf, um die Welt wissen zu lassen, dass sie verfügbar geworden ist. RegisterService() wird eine SSDP „alive" Nachricht auf dem Multicast-Kanal abschicken, die durch irgendeine Vorrichtung, die den SSDP-Dienst laufen lässt, gehört werden wird.
    • d. Sie beginnt damit, Ereignisse unmittelbar zu senden, auch ohne Subscriber. Jede Ereignis-Versendung aktualisiert die Lokal-Zustands-Tabelle. Diese Submission muss automatisch in Bezug auf ein Hinzufügen von Subscribern vorliegen, so dass zwischen der Zeit, zu der das SubmitEvent() API aufgerufen wird, und der Zeit, zu der die Lokal-Zustands-Tabelle aktualisiert wird, keine Subskription hinzugefügt oder entfernt werden kann.
    • 2. Zwischenzeitlich initialisiert eine UPnP-UCP.
    • a. Sie initialisiert ihren HTTP-Server, passiv an einem TCP-Port hörend.
    • b. Falls die UCP gestartet wird, bevor die UPnP-Vorrichtung initialisierte, wünscht sie nicht irgendwelche Dienste, die verfügbar werden, zu sehen. Wenn die Vorrichtung schließlich startet, wird die UCP darauf hingewiesen werden.
    • c. Wenn einmal die UPnP-Dienste angezeigt worden sind, wird die UCP in der Lage sein, auf einen oder mehrere davon zuzugreifen.
    • d. Die UCP steuert die UPnP-API so an, um ein UPnP-Dienst-Objekt zu initiieren.
    • e. Das UpnP-Dienst-Objekt nimmt das Folgende vor, wenn es instantiiert wird:
    • i. Sie erhält den Ereignis-Beschreibungs-URL von der Beschreibung für diesen Dienst.
    • ii. Sie ruft den SSDP-API-RegisterNotification() auf, SSDP_PROPCHANGE als den Ereignis-Typ, die Ereignis-Subskriptions-URL, einen Callback-Funktions-Hinweiszeiger (der eine Statik-Element-Funktion der Klasse ist) und einen Kontext-Hinweiszeiger der („dieser" Hinweiszeiger der Klasse ist) spezifizierend. RegisterNotification() nimmt das Folgende vor:
    • 1. Er nimmt einen LRPC-Ruf zu dem SSDP-Dienst vor. Der Rest tritt auf der Seite des Dienstes auf.
    • 2. Falls dies das erste Mai ist, zu der er SSDP_PROPCHANGE Hinweise aufruft, wird Register-Notification() InternetOpen() aufrufen, um einen Handle zu einer Internet-Session zu erhalten. Dieser Handle wird gemeinsam unter allen lokalen UPnP-UCPs geteilt.
    • 3. Er ruft InternetConnect(), den Server-Namen weiterführend, gegeben in dem URL, den er hindurchgeführt hat, auf.
    • 4. Er ruft HTTPOpenRequest() auf, in den Rest des URL hindurchführend, die hindurchgeführt wurde.
    • 5. Die Handle, zurückgeführt durch diese Funktionen, werden mit der Struktur, die die Subskription aufrechterhält, gesichert.
    • 6. Er setzt eine SUBSCRIBE Nachricht zusammen, unter Verwendung der Daten, die hineingeführt sind, durch Aufrufen von HttpAddRequestHeaders(). Er fügt die „NT", „Callback" und „Timeout" Header hinzu. Der Callback- Header der SUBSCRIBE Nachricht wird unterwegs (on the fly) zusammengesetzt, als ein wahlweiser URL für Hinweise, die für diese Subskription geschickt werden sollen. Der Server-Name ist die lokale IP-Adresse, und der Port ist derselbe, auf den man durch Schritt 2a vorstehend Bezug nahm.
    • 7. Er ruft HttpSendRequest() auf, um die Anforderung zu der CD zu schicken. Dies ist eine synchrone Funktion, die zurückkehren wird, wenn die Anforderung durch die CD beantwortet worden ist.
    • 8. Sie ruft HttpQueryInfo(..., HTTP_QUERY_CUSTOM, ...) auf, um den „Subskriptions-ID" Header zu erhalten. Die sich ergebende SID wird mit der Subskriptions-Struktur gespeichert werden.
    • 9. Er ruft HttpQueryInfo(..., HTTP_QUERY_CUSTOM, ...) auf, um den „Timeout" Header zu erhalten. Der sich ergebende Timeout-Wert wird mit der Subskriptions-Struktur gespeichert werden.
    • 10. Ein Zeitgeber wird für eine Resubskription basierend auf dem Timeout-Wert, zurückgeführt in der Antwort, gestartet. Wenn der Zeitgeber abläuft, wird die erneute Subskription geschickt werden.
    • 11. Die SID der Callback-Funktions-Hinweiszeiger und Timeout-Werte werden in einer Struktur gespeichert, die die Liste von lokalen Subskriptionen aufrechterhält.
    • 3. Zurück an der UPnP-CD wird die Subskriptions-Anforderung durch den HTTP-Server empfangen. Das Nachfolgende tritt auf:
    • a. Die Anforderung wird in URI, NT, Callback und Timeout-Feldern analysiert.
    • b. Das NT-Feld muss „Upnp:event" anpassen. Falls es das tut, antwortet die CD mit „412 Precondition Failed".
    • c. Der URI identifiziert die Ereignis-Quelle. Der URI wird in einen URL umgewandelt und zu der Liste von Ereignis-Quellen, registriert an der CD, angepasst. Falls keine Anpassung gefunden wird, antwortet die CD mit „404 Not Found".
    • d. Falls eine Anpassung gefunden wird, tritt das Folgende auf:
    • i. Der Callback-URL wird zu einer Liste von Subscriber-URLs hinzugefügt.
    • ii. Der Timeout-Wert wird verarbeitet und eine absolute Zeit wird mit den Event-Quellen-Daten gespeichert. Falls diese Zeit abläuft und eine Wieder-Subskriptions-Nachricht nicht empfangen worden ist, wird die Subskription entfernt.
    • iii. Eine neue SID wird erzeugt und mit dem Subscriber in der Ereignis-Quelle gespeichert.
    • iv. Eine Sequenz-Zahl wird auf 0 initialisiert.
    • v. Eine Subskriptions-Antwort wird zusammengestellt, einschließlich eines Echos des Timeout-Headers und der SID, die gerade erzeugt ist.
    • vi. Die Antwort wird gesendet.
    • vii. Falls die Antwort erfolgreich gesendet ist, wird die Liste von Ereignis-Quellen zu einer Platte bzw. Disk für Wiederherstellungs-Zwecke bestehen gelassen.
    • viii. Ein Zeitgeber wird gestartet unter Verwendung desselben Timeout-Werts wie der Header, der echomäßig zu der UCP hin gegeben ist. Wenn dieser Zeitgeber abläuft, wird die Subskription entfernt. Falls die CD eine Anforderung für eine erneute Subskription empfängt, wird dieser Zeitgeber zurückgesetzt werden. In einer idealen Welt wird der Zeitgeber niemals ablaufen.
    • ix. Ein Anfangs-Ereignis-Hinweis wird gesendet, um die Zustands-Tabelle von UCP's zu initialisieren. Das Folgende beschreibt den Vorgang:
    • 1. InternetOpen() wird aufgerufen, falls ein existierender Internet-Session-Handle nicht existiert.
    • 2. InternetConnect() wird aufgerufen, den Server-Namen, spezifiziert in dem Callback-URL für diese Subskription, hindurchführend.
    • 3. HTTPOpenRequest() wird aufgerufen, in den Rest der Callback-URL hindurchführend.
    • 4. Eine NOTIFY Nachricht wird zusammengestellt, unter Verwendung der Daten, die hineingeführt sind, durch Aufrufen von HttpAddRequestHeaders(). Sie fügt die „NT", „NTS", „SID", „Seq", „Content-Length" und „Content-Type" Headers hinzu.
    • a. Der NT-Header wird immer „upnp:event" sein. Der NTS-Header wird immer „upnp:propertychanged" sein.
    • b. Der SID-Header enthält den SID, gespeichert in der Ereignis-Quellen-Struktur.
    • c. Der Seq-Header wird immer 0 sein.
    • d. Der Inhalt-Längen-Header wird die Zahl von Bytes in dem XML-Körper sein.
    • e. Der Content-Type-Header wird immer „text/XML" sein.
    • f. Der Grundbestandteil bzw. Körper der Nachricht ist aus der Liste von Properties bzw. Eigenschaften, gespeichert innerhalb der Ereignis-Quellen-Struktur, zusammengesetzt:
    • i. Schreibe das <propertyset> Öffnungs-Zeichen.
    • ii. Schreibe das <propcount>n</propcount> Zeichen. Hierbei ist n die Zahl von gesamten Properties.
    • iii. Für jede Property:
    • 1. Schreibe das <property> Öffnungs-Zeichen.
    • 2. Schreibe das <prop> Öffnungs-Zeichen, wobei prop der Name der Property ist.
    • 3. Schreibe das <type>type>/type> Zeichen, wobei type der als Stringfolge gebildete Typ-Name des Property-Typs ist.
    • 4. Schreibe den Property-Wert.
    • 5. Schreibe das <prop> Schließungs-Zeichen.
    • 6. Schreibe das <property> Schließungs-Zeichen.
    • iv. Schreibe das </propertyset> Schließungs-Zeichen.
    • 5. Er ruft HttpSendRequestEx(), dann InternetWriteFile(), dann HttpEndRequest(), um die Anforderung zu der CD zu schicken, auf.
    • 6. Die Antwort wird ignoriert, mit der Ausnahme für Debugging- bzw. Fehler-Beseitigungs-Zwecke.
    • 4. Die UPnP-CD ist nun bereit, einen Ereignis-Hinweis zu senden. Sie nimmt dies durch Aufrufen der SubmitUPnPPropertyEvent() API vor. Das Nachfolgende tritt innerhalb der API auf:
    • a. Ein Ereignis-Quellen-Handle wird zu einer Ereignis-Quellen-Struktur umgewandelt.
    • b. Die Eigenschaften, die als eine Folge des Ereignisses geändert worden sind, werden in die Funktion hineingeführt und in der lokalen Liste von Eigenschaften, gespeichert mit der Ereignis-Quelle aktualisiert.
    • c. Für jeden Subscriber tritt das Folgende auf:
    • i. InternetConnect() wird aufgerufen, den Server-Namen, spezifiziert in dem Callback-URL für diese Subskription, hindurchführend.
    • ii. HttpOpenRequest() wird aufgerufen, in den Rest des aufgerufenen URL hineinführend.
    • iii. Eine NOTIFY Nachricht wird zusammengestellt, unter Verwendung der Daten, hineingeführt durch Aufrufen von HttpAddRe questHeaders(). Sie fügt die „NT", „NTS", „SID", „Seq", „Content-Length" und „ContentType" Headers hinzu.
    • 1. Der NT-Header wird immer „upnp:event" sein. Der NTS-Header wird immer „ UPnP:propertychange" sein.
    • 2. Der SID-Header enthält den SID, gespeichert in der Ereignis-Quellen-Struktur.
    • 3. Die Sequenz-Zahl für die Ereignis-Quelle wird erhöht und der Seq-Header wird mit diesem Wert erzeugt.
    • 4. Der Content-Length-Header wird die Zahl von Bytes in dem XML-Körper sein.
    • 5. Der Content-Type-Header wird immer „text/XML" sein.
    • 6. Der Körper der Nachricht ist aus der Liste von Eigenschaften, gespeichert innerhalb der Ereignis-Quellen-Struktur, zusammengesetzt:
    • a. Schreiben des <propertyset> Öffnungs-Zeichens.
    • b. Schreiben des <propcount>n</propcount> Zeichens. Hierbei ist n die Zahl von gesamten Eigenschaften.
    • c. Für jede Property, die zugeführt worden ist:
    • i. Schreibe das <property> Öffnungs-Zeichen.
    • ii. Schreibe das <prop> Öffnungs-Zeichen, wobei prop der Name der Property ist.
    • iii. Schreibe das <type>type>/type> Zeichen, wobei type der als String-Folge gebildete Typ-Namen des Property-Typs ist.
    • iv. Schreibe den Property-Wert.
    • v. Schreibe das </prop> Schließungs-Zeichen.
    • vi. Schreibe das </property> Schließungs-Zeichen.
    • d. Schreibe das </propertyset> Schließungs-Zeichen.
    • iv. SubmitEvent() wird aufgerufen, den Ereignis-Quellen-Handle hindurchführend, den Handle zu den Headern, erzeugt durch 4c(i) bis 4c(ii) vorstehend, und der Körper, erzeugt in Schritt 4c(iii)6. SubmitEvent() nimmt das Folgende vor:
    • 1. Er ruft HttpSendRequestEx(), dann InternetWriteFile() an dem Körper, dann HttpEndRequest(), um die Anforderung zu der CD zu schicken, auf.
    • 2. Die Antwort wird ignoriert, mit der Ausnahme für Debugging- bzw. Fehler-Beseitigungs-Zwecke.
    • 5. Die UPnP-UCP empfängt die Hinweis-Nachricht. Die Nachricht wird wie folgt verarbeitet:
    • a. Der HTTP-Server empfängt eine NOTIFY Nachricht mit einem Request-URI und verschiedenen anderen Headern.
    • b. Die NOTIFY Nachricht wird analysiert, auf den „NT" Header zuerst sehend. Falls dieser Header „upnp:Event" enthält, dann wird die Nachricht weiter für Ereignis-Hinweise wie folgt verarbeitet:
    • i. Die Nachricht wird nach dem NTS-Header analysiert. Falls dieser „upnp:propertychanged" enthält, dann wird die Nachricht weiter wie folgt analysiert:
    • 1. Die Nachricht wird nach dem SID-Header analysiert. Die SID zeigt zu dem UPnP-Steuer-Punkt, für welche Subskription diese Nachricht gilt.
    • 2. Die Nachricht wird nach dem „Seq" Header analysiert. Falls dieser Header einen Wert von 0 enthält, weiß die UCP, dass dieser eine Anfangs-Zustands-Bestückungs-Anforderung ist. Falls die lokale Sequenz-Zahl exakt eins geringer als der Seq-Header ist, wird die lokale Sequenz- Zahl aktualisiert (erhöht), und die Nachricht wird weiter verarbeitet.
    • 3. Der Request-URI kann ignoriert werden, da der HTTP-Server weiß, dass alle NOTIFY Nachrichten mit einem NT-Header von „upnp:Event" zu demselben Request-URI geschickt sind.
    • 4. Falls der Seq-Header eine Zahl enthält, die nicht exakt eins mehr als die lokale Sequenz-Zahl ist, weiß der UCP, dass er ein Ereignis bzw. Event verfehlt hat. In diesem Zustand muss die Teilnahme beendet werden und erneut zu der Ereignis-Quelle subskribiert werden, um seinen Zustand wieder zu synchronisieren.
    • 5. Die SID wird gegen die Liste von Subskriptionen, aufrechterhalten an dem UCP, angepasst. Wenn die SID angepasst ist, wird deren zugeordnete Callback-Funktion aufgehoben.
    • 6. Die Callback-Funktion hat eine SSDP_Message Struktur hindurchgeführt, die alle relevanten Header und den Körper der XML-Nachricht, die empfangen ist, enthält.
    • 7. Die Callback-Funktion wird durch den UPnP-API, als ein statisches Element des Dienst-Objekts, ausgeführt. Wenn diese Funktion aufgerufen ist, tritt das Folgende auf:
    • a. Der Körper der Nachricht wird unter Verwendung der XML-DOM Dienste analysiert.
    • b. Da Eigenschaften aufgezählt sind, werden deren Werte in der Lokal-Zustands-Tabelle für den Dienst gespeichert.
    • c. Ein Ereignis wird zu allen Clients auf einem hohen Niveau des UPnP-API unmittelbar abgeschickt. Dieses Ereignis enthält die Liste von Properties bzw. Eigensachaften, die sich geändert haben, und deren neue Werte.
    • 6. Der Resubskriptions-Zeitgeber für eine der Subskriptionen der UCPs läuft ab. Das Folgende tritt auf:
    • a. Eine Resubskriptions-Nachricht wird zusammengestellt. Diese Nachricht ist sehr ähnlich zu einer Subskriptions-Nachricht, mit der Ausnahme, dass sie nicht einen NT- oder Callback-Header umfasst, sondern sie besitzt einen SID-Header.
    • b. Die Anforderung wird zu der CD geschickt.
    • c. Die Antwort enthält den neuen Timeout-Wert.
    • d. Der Zeitgeber wird mit diesem Timeout bzw. Zeitablauf zurückgesetzt.
  • UCP-Zustand-Synchronisations-Modelle
  • Durch CD initiiertes NeedsSync Verfahren
  • Dieses Verfahren beginnt damit, dass die CD ihren Anfangs-Zustand zu dem Subscriber sendet, zum ersten Mal, für das ein Ereignis durch den Dienst zugeführt wird. UCPs werden an dem Dienst zum ersten Mal teilnehmen, dann Hinweise von Ereignissen, wie sie auftreten, empfangen. Das erste Ereignis wird der Anfangs-Zustand des Dienstes sein. Die UCP-Zustands-Tabelle wird immer synchron zu diesem Verfahren sein.
  • Wenn die CD einen Hinweis zu einem Subscriber sendet und einen Fehler empfängt. In diesem Fall markiert sie den Subscriber als „NeedsSync" und das nächste Mal, zu dem ein Ereignis zugeführt wird, werden alle Ereignisse zu dem Subscriber geschickt. Das Problem hierbei ist dasjenige, dass der API verfolgen muss, welche Subscriber eine Synchronisation benötigen und welche nicht. Der Client dieses API (der UPnP-Dienst) würde benötigen, dass separate Nachrichten zu jedem Subscriber geschickt werden, und muss wissen, welche alle Ereignisse benötigten und welche nur diejenigen wünschten, die sich änderten.
  • Durch UCP-initiierte Synchronisation
  • Dieses Verfahren gibt an, dass die UCP an Ereignis-Hinweisen teilnehmen sollte, dann eine Funktion aufruft, die den Zustand von dem Dienst erhielt. Das bedeutet, dass irgendwelche Ereignisse, die in der Zwischenzeit empfangen wurden, benötigt werden würden, um gegen den ankommenden Satz von Ereignissen angepasst zu werden, und um ersetzt zu werden, falls sie älter waren. Dieses Verfahren führt zu Synchronisations-Ereignissen dort, wo die UCP Ereignisse empfangen kann, die neuer sind, allerdings wenn sie nach dem Zustand fragt, sie eine ältere Ansicht der Tabelle erhält. Dies erfordert die Verwendung von Sequenz-Zahlen, um zu bestimmen, welche Informationen neuer sind. Falls die Ansicht der Tabelle, die durch die Nachfrage empfangen ist, zu alt ist, muss sie ausgesondert werden. Alternativ wurden die Properties, die nicht durch den Ereignis-Hinweis empfangen wurden, nicht überschrieben, sondern alle anderen Properties würden überschrieben sein. Die Verwendung von Sequenz-Zahlen macht dies komplizierter.
  • Durch CD initiierte Synchronisation
  • Dieses bevorzugte Verfahren nimmt eine einfachere Maßnahme vor. Zu irgendeinem Zeitpunkt, zu dem die UCP an einem Dienst teilnimmt, wird der Dienst unmittelbar danach die gesamten Inhalte der Zustands-Tabelle mit dem ersten Hinweis senden. Dies beugt vor, dass die UCP eine Anfrage nach der Zustands-Tabelle vornimmt. Darauf folgende Ereignisse aktualisieren die lokale Zustands-Tabelle an der UCP. Falls die Verbindung verloren ist, wird die UCP ihre Subskription verlieren. Falls die UCP realisiert, dass sie nicht ein Ereignis nach Ablauf einer bestimmten Zeitdauer empfangen hat, wird sie resubskribieren. An diesem Punkt wird die CD wieder die gesamte Zustands-Tabelle erneut geschickt haben, und es wird sichergestellt, dass die UCP aktualisiert ist.
  • Beispielhafte Computer-Hardware
  • 24 und die nachfolgende Diskussion sind dazu vorgesehen, eine kurze, allgemeine Beschreibung eines geeigneten Computers anzugeben, der in dem vorstehend beschriebenen UPnP-Vorrichtungs-Steuer-Modell verwendet werden kann. Dieser herkömmliche Computer 820 (wie beispielsweise Personal-Computer, Laptops, Palmtops oder in der Hand haltbare PCs, Set-Tops, Server, Mainframes, oder andersartige Computer) umfasst eine Verarbeitungs-Einheit 821, einen Systemspeicher 822 und einen System-Bus 823, der verschiedene System-Komponenten, einschließlich des Systemspeichers, mit der Verarbeitungs-Einheit 821 verbindet. Die Verarbeitungs-Einheit kann irgendeiner von verschiedenen, kommerziell erhältlichen Prozessoren sein, einschließlich Intel x86, Pentium und kompatibler Mikroprozessoren von Intel, und anderen, einschließlich Cyrix, AMG und Nexgen; Alpha von Digital; MIPS von MIPS Technology, NEC, IDT, Siemens, und anderen; und der Power PC von IBM und Motorola. Dual-Mikroprozessoren und andere Multi-Prozessor-Architekturen können auch als die Verarbeitungs-Einheit 821 verwendet werden.
  • Der System-Bus kann irgendeiner von verschiedenen Typen einer Bus-Struktur sein, einschließlich eines Speicherbusses oder einer Speicher-Steuereinheit, eines peripheren Busses und eines lokalen Busses, unter Verwendung irgendeiner Vielzahl von herkömmlichen Bus-Architekturen, wie beispielsweise PCI, VESA, AGP, Microchannel, ISA und EISA, um ein paar zu nennen. Der Systemspeicher umfasst einen Read Only Memory (ROM) 824 und einen Random Access Memory (RAM) 825. Ein Basis-Eingabe/Ausgabe-System (BIOS), das die Basis-Routines besitzt, die dabei helfen, Informationen zwischen Elementen innerhalb des Computers 820 zu übertragen, wie beispielsweise während des Hochfahrens, ist in dem ROM 824 gespeichert.
  • Der Computer 820 umfasst weiterhin ein Festplatten-Laufwerk 827, ein Magnetplatten-Laufwerk 828, z. B. um von einer entnehmbaren Platte 829 zu lesen oder darauf zu schreiben, und ein Laufwerk 830 für eine optische Platte, z. B. zum Lesen einer CD-ROM Platte 831 oder zum Lesen von anderen, optischen Medien oder zum Schreiben darauf. Das Festplatten-Laufwerk 827, das Magnetplatten-Laufwerk 828 und das Laufwerk 830 für die optische Platte sind mit dem System-Bus 823 durch eine Festplatten-Laufwerk-Schnittstelle 832, eine Magnetplatten-Laufwerk-Schnittstelle 833 und eine Optik-Laufwerk-Schnittstelle 834, jeweils, verbunden. Die Laufwerke, und deren zugeordnete, mittels Computer lesbare Medien, bilden eine nicht flüchtige Speicherung von Daten, Daten-Strukturen, durch einen Computer ausführbare Instruktionen, usw., für den Computer 820. Obwohl sich die Beschreibung der mittels Computer lesbaren Medien vorstehend auf ein Festplatten-Laufwerk, eine entnehmbare Magnetplatte und eine CD bezieht, sollte durch Fachleute auf dem betreffenden Fachgebiet ersichtlich werden, dass andere Typen von Medien, die durch einen Computer lesbar sind, wie beispielsweise magnetische Kassetten, Flash-Memory-Cards, Digital-Video-Disks, Bernoulli-Kassetten, und dergleichen, in der beispielhaften Betriebsumgebung auch verwendet werden können.
  • Eine Anzahl von Programm-Modulen kann in den Laufwerken und dem RAM 825, einschließlich einem Betriebssystem 835, einem oder mehreren Anwendungs- Programmen 836, anderen Programm-Modulen 837 und Programm-Daten 838, gespeichert sein.
  • Ein Benutzer kann Befehle und Informationen in den Computer 820 über eine Tastatur 840 und eine Hinweis-Vorrichtung, wie beispielsweise eine Mouse 842, eingeben. Andere Eingabe-Vorrichtungen (nicht dargestellt) können ein Mikrofon, einen Joystick, ein Game-Pad, eine Satellitenschüssel, einen Scanner, oder dergleichen, umfassen. Diese und andere Eingabe-Vorrichtungen sind oftmals mit der Verarbeitungs-Einheit 821 über eine Seriell-Port-Schnittstelle 846 verbunden, die mit dem System-Bus verbunden ist, können allerdings durch andere Schnittstellen verbunden sein, wie beispielsweise einem Parallel-Port, einem Game-Port oder einem Universal-Serial-Bus (USB). Ein Monitor 847 oder ein anderer Typ einer Anzeige-Vorrichtung ist auch mit dem System-Bus 823 über eine Schnittstelle, wie beispielsweise einen Video-Adapter 848, verbunden. Zusätzlich zu dem Monitor umfassen Computer typischerweise andere, periphere Ausgabe-Vorrichtungen (nicht dargestellt), wie beispielsweise Lautsprecher und Drucker.
  • Der Computer 820 arbeitet in einer vernetzten Umgebung unter Verwendung von logischen Verbindungen zu einem oder mehreren entfernten Computer(n), wie beispielsweise einem entfernten Computer 849. Der entfernte Computer 849 kann ein Server, ein Router, eine Peer-Vorrichtung oder ein anderer, gemeinsamer Netzwerk-Knoten sein, und umfasst typischerweise viele oder alle der Elemente, die in Bezug auf den Computer 820 beschrieben sind, obwohl nur eine Speichervorrichtung 850 in 24 dargestellt worden ist. Die logischen Verbindungen, gezeigt in 24, umfassen ein Local Area Netzwerk (LAN) 851 und ein Wide Area Netzwerk (WAN) 852. Solche vernetzten Umgebungen sind in Büros, in weltweiten Computer-Netzwerken, in Intranets und dem Internet üblich.
  • Der Computer 820 ist, wenn er in einer LAN-Netzwerkumgebung verwendet wird, mit dem lokalen Netzwerk 851 über eine Netzwerk-Schnittstelle oder einen Adapter 853 verbunden. Der Computer 820 umfasst, wenn er in einer WAN-Netzwerk-Umgebung verwendet ist, typischerweise ein Modem 854 oder eine andere Einrichtung zum Einrichten von Kommunikationen (z. B. über das LAN 851 und einen Gateway- oder Proxy-Server 855) über das Wide Area Network 852, wie beispielsweise das Internet. Das Modem 854, das intern oder extern vorhanden sein kann, ist mit System-Bus 823 über die Seriell-Port-Schnittstelle 846 verbunden. In einer vernetzten Umgebung können Programm-Module, gezeigt relativ zu dem Computer 820, oder Bereiche davon, in der entfernten Speichervorrichtung gespeichert sein. Es wird ersichtlich werden, dass die Netzwerk-Verbindungen, die dargestellt sind, beispielhaft sind, und andere Mittel zum Einrichten einer Kommunikations-Verbindung zwischen den Computern können verwendet werden.
  • Entsprechend der Praxis von Fachleuten auf dem Gebiet der Computer-Programmierung wird die vorliegende Erfindung nachfolgend in Bezug auf Wirkungen und symbolische Darstellungen von Operationen, die durch den Computer 820 durchgeführt werden, beschrieben, ohne dass dies in anderer Weise angezeigt ist. Solche Vorgänge und Operationen werden manchmal dahingehend angegeben, dass sie mittels Computer ausgeführt werden. Es wird ersichtlich werden, dass die Vorgänge und die symbolisch dargestellten Operationen die Manipulation durch die Verarbeitungs-Einheit 821 von elektrischen Signalen umfassen, die Daten-Bits darstellen, was eine sich ergebende Transformation oder Reduktion der Darstellung des elektrischen Signals bewirken wird und die Beibehaltung von Daten-Bits an Speicherstellen in dem Speichersystem (einschließlich des Systemspeichers 822, dem Festplatten-Laufwerk 827, den Floppy-Disks 829 und dem CD-ROM 831), um dadurch die Operation des Computersystems zu rekonfigurieren oder in anderer Weise zu ändern, ebenso wie eine andere Verarbeitung von Signalen. Die Speicherstellen, wo Daten-Bits beibehalten werden, sind physikalische Stellen, die bestimmte elektrische, magnetische oder optische Eigenschaften, entsprechend zu den Daten-Bits, haben.
  • Beispielhafte, einbezogene Rechenvorrichtung
  • Die 25 und 26 sind dazu vorgesehen, eine kurze, allgemeine Beschreibung einer geeigneten, einbezogenen Rechenvorrichtung 900 anzugeben, die in der dargestellten Ausführung der Erfindung verwendet werden kann. Die einbezogene Rechenvorrichtung 900 kann irgendeine einer Vielfalt von Vorrichtungen sein, die Elektroniken einsetzen, um Operations-Funktionen (Operations-Schaltung 906) zu steuern, und in denen Rechen- und Netzwerk-Fähigkeiten einbezogen sind. Zum Beispiel können Vorrichtungen, in denen Rechen- und Netzwerk-Funktionen eingebettet sind, Kommunikations-Vorrichtungen (z. B. Telefone, Zellen-Telefone, Audio- und Video-Konferenzsysteme, Zwei-Wege-Funkgeräte, usw.), eine Büroausrüstung (Drucker, Fax-Maschinen, Kopierer, Diktiergeräte, usw.), eine Audio-Video-Ausrüstung (Audio-Video-Aufzeichnungsgeräte und Abspielgeräte, einschließlich Fernsehgeräte, Funkempfänger, Kompakt-Disk (CD), Digital-Video-Disks (DVD), Camcorder, usw.), Entertainment-Vorrichtungen (Set-Top-Boxen, Spiel-Konsolen, usw.), Umgebungs-Steuergeräte (Thermostate, Heiz/Ventilations/Klimatisierungs-Geräte, Lichtschalter usw.), Sicherheitssysteme, Haushaltsgeräte (Kaffeemaschinen, Geschirrspülmaschinen, Waschmaschinen/Trockner), Kraftfahrzeuge, Geräte von öffentlichen Einrichtungen (Zeichen, Verkehrssignale, usw.), eine Herstellgerätschaft, und viele andere, umfassen.
  • Wie 25 zeigt, umfasst die Vorrichtung 900 eine Verarbeitungs-Einheit 902 und einen Speicher 904, um eine eingebettete Rechenfähigkeit zu erreichen. Die Verarbeitungs-Einheit 902 besitzt Hardware-Schnittstellen zu der Operations-Schaltung 906, die Vorrichtungs-Funktionen betätigt. Die Verarbeitungs-Einheit 902 kann ein Mikroprozessor oder eine Mikrosteuereinheit sein, wie sie beispielsweise von Intel, Motorrola, IBM, und anderen, erhältlich ist. Der Speicher 904 setzt vorzugsweise einen RAM und einen ROM ein, um die Software und Daten für einen Grund-Arbeitscode ebenso wie für Benutzer-Anwendungen zu halten.
  • Die Vorrichtung 900 umfasst auch einen Netzwerk-Adapter 908 zum Verbinden mit einem Netzwerk-Medium 910, das mit dem Computer-Netzwerk verbunden ist, in dem die autorisierende Namen-Registrierung (beschrieben nachfolgend) entsprechend der (Erfindung ausgeführt wird. Ein Netzwerk-Adapter 908 kann eine Netzwerk-Schnittstellen-Karte (oder ein Chip-Satz, integriert auf einer einzelnen Leiterplatte mit der Verarbeitungs-Einheit 902) sein, geeignet für das bestimmte Netzwerk-Medium 910. Das Netzwerk-Medium kann von irgendeinem verschiedener verdrahteter oder drahtloser Netzwerk-Medien, einschließlich dem Ethernet, IEEE 1394 (eine a.k.a. Firewire), einer Funkfrequenz (einschließlich Satellit, Zelle, Pager, kommerzielles Signal-Sideband, usw.), einem Energieversorgungs-Leitungsträger (PLC), einer Telefonleitung, eines Fernsehkabels, unter anderen, sein.
  • Wie nun (26 zeigt, besitzt die eingebettete Computer-Vorrichtung 100 (25) eine Software-Architektur 120, die mit dem vorstehend beschriebenen UPNP-Vorrichtungs-Steuermodell übereinstimmt. UPNP liefert einen Mechanismus für die eingebettete Rechenvorrichtung, um in dem Internet zu arbeiten, ebenso wie in Netzwerken, die keinen Administrator und keine Verbindung mit dem Internet haben, und demzufolge keinen Zugang zu Konfigurations-Diensten, ähnlich dem Dynamic Host Configuration Protocol (DHCP). DHCP ist ein Mechanismus, um Vorrichtungen mit Konfigurations-Informationen zu versehen, die benötigt werden, um auf das Internet zuzugreifen. Der Mechanismus funktioniert über die Verwendung einer Multicast-Anforderung von Konfigurations-Informationen, auf die allgemein mit einer IP-Adresse und einer DNS-Server-Stelle geantwortet wird. Zusätzliche Informationen können nur in der Antwort zurückgeführt werden.
  • In nicht-konfigurierten (ad-hoc) Netzwerken verwendet UPnP das AutoIP Protokoll. AutoIP ist eine Erweiterung zu DHCP, die Vorrichtungen ermöglicht, IP-Adressen beim Nichtvorhandensein eines DHCP-Servers oder einer ähnlichen IP-Konfigurations-Autorität zu beanspruchen. IP-Adressen werden von einem umgekehrten Bereich beansprucht, der nicht zugelassen ist, um auf dem offenen Internet übertragen zu werden; demzufolge sind sie nur gut für ein lokales Netzwerk. Die eingebettete Rechenvorrichtung 100 beansprucht eine Adresse durch zufälliges Erzeugen einer Adresse in dem umgekehrten Bereich und dann Vornehmen einer ARP-Anforderung, um zu sehen, ob irgendein anderer auch bereits diese Adresse beansprucht hat. AutoIP-Systeme werden kontinuierlich das Vorhandensein eines DHCP-Servers prüfen, so dass dann, falls einer jemals online kommen sollte, alle AutoIP-Vorrichtungen versuchen werden, deren IP-Adressen zu einem, geliefert durch den DHCP-Server, umzuschalten. Dies ermöglicht einem Netzwerk, in einer Isolation zu arbeiten, verbunden mit dem Internet, mit einer DHCP-Unterstützung, um dann zu einer Isolation zurückgeführt zu werden. Dieser Typ eines Szenariums wird in Häusern üblich sein, die einen Anwähl-Zugang verwenden werden.
  • Das UPNP-Protokoll verwendet auch Multicast-DNS zum Adressieren der eingebetteten Rechenvorrichtung 900. Das Internet Domain Name System (DNS) ist ein Auflistungssystem, das durch eine Person lesbare Domäne-Namen, ähnlich microsoft.com, in deren äquivalente IP-Adresse translatiert. Die meisten zusammenarbeitenden Intranets führen eine moderne Version derselben Technologie aus, um dieselben Dienste bereitzustellen. In kleinen Netzwerken, wie beispielsweise zu Hause oder in einem kleinen Geschäft, können DNS-Server nicht existieren, ähnlich Multi cast-DNS, die DNS-Anforderungen „Multicast" sind. Dies ermöglicht einer Maschine, Anforderungen für deren eigenen Namen zu sehen und darauf zu antworten. Ähnlich AutoIP wird nur Multicast DNS verwendet, wenn ein DNS-Server nicht verfügbar ist. (Für mehr Informationen siehe B. Woodcock, Zocolo, und B. Manning, Multicast Discovery of DNS Services, IETF Internet Draft, „draft-manning-multicast-dns-01.txt".)
  • UPNP führt einen Peer-Discovery-Mechanismus aus, der das Simple-Service-Discovery-Protocol (SSDP) zum Aufdecken von Vorrichtungen auf IP-Netzwerken verwendet. SSDP basiert auf Profilen. Ein einzelner Identifizierer spezifiziert ein Profil, das einen Kontrakt zwischen dem Client und dem Dienst spezifiziert (z. B. operationsmäßige Funktion, bereitgestellt für die eingebettete Rechenvorrichtung). Durch Identifizieren von sich selbst mit dem Profil zeigt der Dienst eine Einwilligung mit dem zugeordneten Kontrakt bzw. Vertrag an.
  • Die Verwendung eines einzelnen Identifizierers macht es möglich, ein extrem einfaches Aufdeckungs-System auszuführen. Clients schicken ein User Datagram Protocol (UDP) Multicast Paket, den Identifizierer des erwünschten Dienstes enthaltend, auf einem bestimmten Standard-Kanal ab. Dienste, die auf den Standard-Kanal hören, lesen die Anforderung, sehen, ob sie den Dienst bereitstellen, und antworten, falls dies der Fall ist.
  • UPNP stellt auch einen Directories Mechanismus bereit, um eine Aufdeckung zu ermöglichen, um zu skalieren – zu dem gesamten Internet, falls benötigt. Wenn vorhanden, wird ein Directory alle ankommenden Dienst-Anforderungen lesen und wird auf sie selbst antworten. Dies erfordert, dass sich alle Dienste (z. B. die eingebettete Rechenvorrichtung 900) mit dem Directory registrieren, so dass das Directory in der Lage ist, geeignet in deren Namen zu antworten. Das Directory ist auch für eine Kommunikation mit anderen Directories bzw. Datei-Verzeichnissen verantwortlich, um zu bestimmen, ob der Dienst innerhalb des lokalen Netzwerks, des WAN's und potenziell des Internets verfügbar ist.
  • Um das Discovery-Protokoll zu vereinfachen, werden Directories als Proxies behandelt. Ein Proxy ist ein Dienst, der Anforderungen akzeptiert und die Verantwortung dafür übernimmt, die geeignete Antwort zu finden. Wenn ein Client online kommt, wird er ein Discovery für das Proxy durchführen. Falls das Proxy vorhanden ist, wird der Client alle zukünftigen Discovery-Anforderungen zu dem Proxy schicken. Falls das Proxy nicht vorhanden ist, dann wird der Client alle Discovery-Anforderungen zu dem reservierten Discovery-Multicast-Kanal senden. Ungeachtet des Vorhandenseins eines Proxy werden das Anforderungs-Format des Clients und Prozeduren immer dieselben sein. Der einzige Unterschied wird die Adresse sein, zu der der Client seine Anforderungen schickt. Für Dienste ist die Differenz zwischen einem als Proxy und eines nicht als Proxy aufgebauten Netzwerks deren Erfordernis, auf Discovery-Anforderungen zu antworten. Auf einem Proxy-Netzwerk müssen Dienste nichts unternehmen, wenn sie einmal mit dem Proxy registriert sind. An einem Nicht-Proxy-Netzwerk werden sie Discovery-Anforderungen direkt beantworten.
  • SSDP verwendet das auf dem UDP und Transmission Control Protocol (TCP) basierende Hypertext Transport Protocol (HTTP), um ein Service- bzw. Dienst-Discovery bereitzustellen. SSDP verwendet einen Uniform Resource Identifier (URI), um den Dienst zu repräsentieren, und das OPTIONS Verfahren, um ein Discovery zu schaffen. SSDP wird auch eine Unterstützung für Proxies bereitstellen. Diese Proxies, die real nur Fronts bzw. Zeichensätze für Directories sind, richten Discovery-Anforderungen zu sich selbst zurück. Es ist die Aufgabe des Proxy, Anzeige-Anforderungen zusammenzustellen, um zu bestimmen, welche Dienste verfügbar sind, ebenso wie mit anderen Proxies zu kommunizieren, um eine Entdeckung bzw. ein Discovery eines skalierbaren Dienstes zu schaffen.
  • Der Discovery-Prozess führt nur die Basis-Informationen zurück, die benötigt werden, um die eingebettete Rechenvorrichtung zu verbinden. Wenn einmal ein Dienst seine Peers entdeckt hat, muss der Dienst oftmals mehr Informationen herausfinden, um am besten damit zu arbeiten. Der Beschreibungs-Prozess führt ein Schema zurück, das beschreibende Daten über den Dienst liefert.
  • Ein Schema ist eine strukturierte Daten-Definition, die einen Satz von strukturierten Werten definiert, der beschreibende Informationen über einen Dienst liefert. UPNP verwendet Extensible Markup Language (XML) für ein Schema, da ein selbst beschreibendes, strukturiertes Daten-Format der XML das Niveau für eine Ausdrucks-Fähigkeit und Verlängerbarkeit, benötigt durch ein universelles Schema und Daten-Fonnat, liefert.
  • Dementsprechend unterstützt UPNP eine automatische Netzwerk-Einführung, was bedeutet, dass die Vorrichtungen und deren in Bezug stehende Dienste die Fä higkeit haben, sich selbst zu beschreiben und eine automatische Konfiguration zu ermöglichen. Wenn eine Vorrichtung in ein Computer-Netzwerk eingesteckt ist, konfiguriert die Vorrichtung automatisch sich selbst und erhält eine TCP/IP-Adresse. Die Vorrichtung zeigt dann deren Vorhandensein zu anderen Vorrichtungen an, die bereits auf dem Netzwerk vorhanden sind, unter Verwendung eines einfachen Discovery-Protokolls, basierend auf dem Internet HTTP Protokoll, und ist unmittelbar bereit, ihre Dienste gemeinsam mit irgendeiner Vorrichtung, die sie anfordert, zu teilen.
  • Mit UPNP wird von Vorrichtungs-Entwicklern nicht gefordert, spezifische Vorrichtungs-Treiber zu entwickeln, um unter UPNP zu arbeiten. Die Aufgabe eines Präparierens einer Vorrichtung für einen Betrieb in dieser Netzwerk-Umgebung ist demzufolge sehr einfach. Weiterhin ermöglicht eine dynamische Erfassung ein Betriebssystem, um unmittelbar unter Verwendung von hinzugefügten Vorrichtungen oder ein Anhalten, unter Verwendung von entfernten Vorrichtungen ohne ein erneutes Booten, zu beginnen.
  • UPNP-Vorrichtungen unterstützen eine automatische Entdeckung (Discovery), Identifikation und Konfiguration, um eine Nicht-Arbeitsfähigkeit in der Umgebung zu Hause zu erreichen, müssen allerdings korrekt in einem verwalteten, zusammenarbeitenden Netzwerk arbeiten. Vorrichtungen können als Netzwerk aufgebaut werden, anstelle davon, dass sie direkt mit einem PC verbunden werden, und Vorrichtungen sind alles autonome Mitglieder auf dem Netzwerk, in der Lage, miteinander zu sprechen, und Informationen auszutauschen. UPNP liefert eine vereinheitlichte Art und Weise, um Directory-Dienste mit einer automatischen Konfiguration durchzuführen. Die Fähigkeit für einen einfachen Discovery-Mechanismus, verwendet in einer Heim-Umgebung, liefert die Fähigkeit für irgendeine Vorrichtung, ein Knoten auf dem globalen Internet zu werden. Zusätzlich können Directory-Dienste verknüpft werden, wenn sie in der zusammenarbeitenden Umgebung verfügbar werden.
  • UPNP schafft einen gemeinsamen Satz von Schnittstellen zum Zugreifen auf Vorrichtungen und Dienste, was die betriebsmäßige Vereinheitlichung von diversen Medien-Typen ermöglicht. Kommunikations-Protokolle für Universal Plug an Play basieren auf Industrie-Standards, insbesondere Schlüssel-Internet-Standards, wie beispielsweise TCP/IP, HTML, XML, HTTP, DNS, LDAP, und anderen. Individuelle Ausführungen für bestimmte Netzwerke und Busse werden auf eingerichteten Protokollen aufgebaut.
  • Wie in 26 dargestellt ist, umfasst die Software-Architektur 920 der eingebetteten Rechenvorrichtung 900 (25) die folgenden Software-Code-Module, die UPNP ausführen: Vorrichtungs-Funktionen 922, einfaches Discovery 924, Hypertext Transport Protocol (HTTP) 925, Transmission Control Protocol/Internet Protocol (TCP/IP) Stapel 926, Autonet 928, Dynamic Host Configuration Protocol (DHCP) 930 und physikalische Medien 910 (auch in 25 dargestellt). Die Vorrichtungs-Funktionen 922 sind ein Software-Code-Modul, um die Funktionalität der Vorrichtung auszuführen. Zum Beispiel kann dort, wo die eingebettete Rechenvorrichtung ein VCR ist, der Vorrichtungs-Funktions-Code ein Code zum Ausführen von Start-, Stopp-, Pause-, Record- und andere Funktionen ausführen, die der VCR durchführen kann.
  • Das einfache Discovery 924 ist ein Software-Code-Modul (ungefähr 4 Kbytes), das einen einfachen Discovery-Vorgang (beschrieben nachfolgend) für eine automatische Netzwerk-Einführung unter dem UPNP-Protokoll ausführt.
  • Der einfache Discovery-Vorgang schafft zusätzlich eine Extensible Markup Language (XML) Format Vorrichtungs-Beschreibung, die zu Clients heruntergeladen wird, die auf die Vorrichtung zugreifen, um eine Aktivierung der Vorrichtungs-Funktionalität von dem Client zu ermöglichen. XML ist eine textmäßige, auf einem Tag basierende Auszeichnungs-Sprache. Sie wurde ursprünglich dahingehend ausgelegt, dass sie die „webby"-Vereinfachung von SGML (Standard Generalizied Markup Language) ist, und ist deshalb dazu vorgesehen, dazu verwendet zu werden, „Vokabularien" von Tags zu erzeugen, die dazu verwendet werden können, eine semantische Auszeichnung für Dokumente anzuwenden, wie beispielsweise wer der Autor war, was einen Absatz bildet (semantisch nicht von einem Anzeige-Betrachtungs-Punkt), wann der Autor zum letzten Mal Frühstück hatte, usw.. (Für mehr Informationen siehe A. Laymann, E. Jung, E. Maler, H. Thompson, J. Paoli, J. Tigue, N. H. Mikula, S. De Rose, „XML-Data", W3C Note, „NOTE-XML-data-0105"). In dem Zusammenhang von UPNP wird XML dazu verwendet, die Beschreibung von Diensten und Fähigkeiten der einbezogenen Rechenvorrichtungen zu erzielen. Die einbezogene Rechenvorrichtung macht deren Merkmale für Clients sichtbar, indem ihre XML-Vorrichtungs-Beschreibung bereitgestellt wird, die der Client verwenden kann, um Vorrichtungs-Funktionen 922 zu aktivieren. Zum Beispiel kann, falls die Vorrichtung eine Kamera ist, der Browser des Client direkt die Kamera anweisen, herein/heraus zu zoomen oder einen Kontrast einzustellen, unter Verwendung des Mechanismus von XML.
  • Die XML-Vorrichtungs-Beschreibung kann Links (über einen gleichförmigen Ressource-Lokator oder eine URL-Adresse) zu einem begleitenden Blatt im XSL-Format liefern. Blätter im XSL-Stil werden dazu verwendet, die Daten in unterschiedlichen Arten und Weisen zu präsentieren, d. h. die Style-Blätter werden bei unterschiedlichen Ansichten derselben Daten angewandt. Zum Beispiel kann, falls die Vorrichtung ein Datei-System enthält, ein Style-Blatt die Datei-Abschnitte darstellen; ein anderes stellt die Datei-Größen in einer bestimmten Art eines Diagramms dar; und ein noch anderes Style-Blatt könnte Miniaturbilder dieser Bild-Dateien erstellen.
  • Das HTTP 925 ist ein Software-Code-Modul (ungefähr 20 Kbytes), das das Standard-HTTP-Protokoll ausführt, was ein offener Standard-Mechanismus für eine auf einer Client/Server-Nachricht basierenden Kommunikation ist. HTTP dient zu einer Proxy-Bildung, einer Inhalt-Übergabe und einer Sicherheit. [Für mehr Informationen siehe R. Fielding, J. Gettys, J. Mogul, H. Frystyk, T. Berners-Lee, Hypertext Transfer Protocol – HTTP/1.1, IETF/RFC 2068 (Januar 1997).] Der TCP/IP-Stapel 926 führt die Standard-TCP/IP-Netzwerk-Protokolle für eine Kommunikation auf dem Computer-Netzwerk aus. Das Internet-Protokoll (IP) ist ein Gründungs-Protokoll des Internets. Es definiert, wie eine einzelne Nachricht von einer Quelle über Null oder mehr Router zu deren Endbestimmung zu schicken ist. Sie deckt Dinge ab, wie beispielsweise Nachricht-Länge, Nachricht-Fragmentierung, Adressierung und Dinge, die ein Routing betreffen. Das Transmission Control Protocol (TCP) ist ein auf IP basierendes Protokoll, das eine Unterstützung für die zuverlässige, geordnete Lieferung von Nachrichten über IP bildet. Zusätzlich sind ein User Datagram Protocol (UDP) und Internet Group Management Protocol (IGMP) Multicast-Sende/Hör-Fähigkeit in der Umsetzung enthalten.
  • Das Autonet 928 ist ein Software-Code-Modul, das auch für eine automatische Netzwerk-Einführung über AutoIP in dem UPNP-Protokoll verwendet wird. Autonet verwendet einen vordefinierten Satz von IP-Adressen, und, wenn eine Vorrichtung mit dem Netzwerk verbunden ist, pingt sie eine Adresse in diesem Adressen-Raum. Falls sie keine Antworten erhält, nimmt die Vorrichtung an, dass die Adresse verfügbar ist und weist sie sich selbst zu. Um diese Funktionalität noch nützlicher zu machen, wird sie mit Multicast-DNS kombiniert, wo die Vorrichtung selbst ihren eigenen Namen hält. Demzufolge ist es sogar nicht notwendig, zu bestimmen, welche IP-Adresse der Vorrichtung zu sich selbst zugeordnet ist, da deren Name immer anstelle davon verwendet werden kann. Ein IP-Multicast ist ein Mechanismus, um eine einzelne Nachricht zu mehreren Empfängern zu schicken. Ein IP-Multicasting ist besonders nützlich für Discovery-Operationen, wo man nicht exakt weiß, wer die Informationen besitzt, die man sucht. In solchen Fällen kann man eine Anforderung zu einer reservierten IP-Multicast-Adresse schicken. Irgendwelche Dienste, die die angeforderten Informationen liefern können, werden auch zu der Multicast-Anforderung subskribieren bzw. teilnehmen und demzufolge in der Lage sein, die Informations-Anforderung zu hören und geeignet zu antworten. Multicast-DNS ist ein Vorschlag für das IETF basierend auf Regeln zum Vornehmen normaler DNS-Anforderungen unter Verwendung von Multicast-UDP. (Für mehr Informationen siehe B. Woodcock, B. Manning, Multicast Discovery of DNS Services, IETF Internet Draft, „draft-manning-multicast-dns-01.txt".)
  • Das DHCP 930 ist ein Software-Code-Modul, das das Dynamic Host Configuration Protocol (DHCP) umsetzt, was ein Mechanismus ist, um Vorrichtungen mit Konfigurations-Informationen auszustatten, die benötigt werden, um auf das Internet zuzugreifen. Der Mechanismus funktioniert über die Verwendung einer Multicast-Anforderung für Konfigurations-Informationen, auf die allgemein mit einer IP-Adresse und einer DNS-Server-Stelle geantwortet wird. Zusätzliche Informationen können nur in der Antwort zurückgeführt werden.
  • Die 27 und 28 stellen Vorgänge 934, 940 pro UPNP-Protokoll für eine automatische Netzwerk-Einführung der eingebetteten Rechenvorrichtung 900 (25) in eine ad hoc (wo die Vorrichtung keine konfigurierte IP-Adresse besitzt) und eine konfigurierte Computer-Netzwerk-Umgebung, jeweils, dar. Der automatische Netzwerk-Einführungs-Vorgang richtet eine geeignete Konfiguration (z. B. mit einer IP-Adresse) der eingebetteten Rechenvorrichtung unter Verbindung mit einem Server-Computer auf einem Computer-Netzwerk ein, um so in der Lage zu sein, auf die Vorrichtung von einem Client aus zuzugreifen. Die Prozesse 934, 940 umfassen fünf Phasen: Anzeige, Entdeckung, Antwort auf die Entdeckung, bzw. das Discovery, Autonet und Vorrichtungs-Beschreibung.
  • In der Announce- bzw. Anzeige-Phase schickt die eingebettete Rechenvorrichtung 900 ein kleines Multicast-Paket ab, so dass andere Vorrichtungen dieses auf dem Netzwerk finden können. Das Multicast-Nachrichten-Paket sagt im Wesentlichen „ich bin hier, ich bin (zum Beispiel) eine Kamera, und du kannst mich an dieser IP-Adresse oder dem URL erreichen".
  • In der Discovery-Phase hört die eingebettete Rechenvorrichtung 900 auf ein Discovery-Paket, das von einem einfachen Discovery-Client kommt, d. h. die Vorrichtung zeigt sich selbst an, wobei sie dann auf ein Discovery hört. Das Discovery-Paket wird auch durch Multicast verschickt. In Antwort auf ein Discovery hört die eingebettete Rechenvorrichtung 900 auf die Multicast-Adresse und analysiert dann die Informationen von einer einzelnen Simple Discovery Anforderung, um zu entscheiden, ob die Anforderung für diese Art einer Vorrichtung ist. Falls dies der Fall ist, dann schickt die Vorrichtung 100 ein Antwort-Datenpaket zurück, das die folgenden Informationen enthält: die IP-Adresse oder den URL, wo sie erreicht werden kann; Identifikation deren eigenen Vorrichtungs-Typs; und die Discovery-Paket-ID, so dass der anfordernde Client weiß, welche Anforderung beantwortet werden soll.
  • An der Autonet-Phase verwendet das Autonet-Modul 928 der eingebetteten Rechenvorrichtung 900 einen vordefinierten Satz von IP-Adressen und, wenn die Vorrichtung mit dem Netzwerk verbunden ist, pingt sie eine Adresse in diesem Adressen-Raum. Falls keine Antwort empfangen wird, nimmt die Vorrichtung 900 an, dass die Adresse verfügbar ist und sie ordnet sie sich selbst zu. Alternativ kann die Vorrichtung 900 Autonet mit Multicast DNS kombinieren und kann selbst ihren eigenen Namen halten. In diesem Fall ist es nicht notwendig, zu bestimmen, welche IP-Adresse die Vorrichtung sich selbst zuordnete, da deren Name immer anstelle davon verwendet wird.
  • Sowohl die Announce- als auch Discovery-Pakete enthalten auch ein Link oder eine URL zu einer XML-Datei, die durch die eingebettete Rechenvorrichtung an der Vorrichtungs-Beschreibungs-Phase verwendet wird, um sich selbst zu beschreiben (d. h. deren Funktionalität). Diese XML-Daten enthalten alle Fakten über die Vor richtung. XML kann auch URLs haben, die zu Blättern mit geeignetem Stil (XLS Dateien) hinweisen, die für eine optimale Präsentation verwendet werden. Die XSL-Style-Blätter werden dazu verwendet, die Daten in unterschiedlichen Arten und Weisen zu präsentieren, d. h. die Style-Blätter werden dazu angewandt, unterschiedliche Ansichten der Daten zu präsentieren. Zum Beispiel kann, wenn die Vorrichtung ein Datei-System enthält, ein Style-Blatt die Datei-Auswahlen darstellen; ein anderes stellt die Datei-Größen in einer bestimmten Art eines Diagramms dar; ein noch anderes Style-Blatt könnte Miniatur-Ansichten dieser Bild-Dateien erstellen.
  • Beispielhafter Client
  • Wie nun 29 zeigt, besitzt ein Client, der auf die eingebettete Rechenvorrichtung 900 über das Computer-Netzwerk zugreift und verwendet, eine beispielhafte Client-Software-Architektur 950, die Software-Code-Module für Anwendungen 952, ein einfaches Discovery 954, XML 955, LDAP 956, TCP/IP-Stapel 958 und eine Netzwerk-Schnittstellen-Karte (NIC) 960, die eine physikalische Verbindung mit dem Computer-Netzwerk schafft, umfasst. Die Applikationen 952 sind ein Software-Code-Modul, das Benutzer-Schnittstellen-Merkmale zum Lokalisieren erwünschter Vorrichtungen (z. B. einer eingebetteten Rechenvorrichtung 900) und Diensten auf dem Computer-Netzwerk schafft, und auch Benutzer-Schnittstellen-Merkmale, um mit der lokalisierten Vorrichtung oder dem Dienst zusammenzuarbeiten. Die Applikationen 952 können einen Internet-Browser, wie beispielsweise den Microsoft Internet Explorer, umfassen, der die XML-Vorrichtungs-Beschreibung entsprechend einem zugeordneten XSL-Style-Blatt für eine Interaktion mit der eingebetteten Rechenvorrichtung und einer Aktivierung deren betriebsmäßiger Funktionalität präsentiert.
  • Das einfache Discovery 954 ist ein Modul, das die vorstehend beschriebene, einfache Discovery pro UPNP-Protokoll ausführt. Das XML 955 ist ein Modul, das die XML-Vorrichtungs-Beschreibung und die XSL-Style-Blätter für eine Präsentation in der Benutzer-Schnittstelle der Anwendung verarbeitet. LDAP 956 führt das Standard-LDAP-Directory-Protokoll für eine Namen-Durchsicht aus. TCP/IP-Stapel 958 führt das TCP/IP-Protokoll für Kommunikationen über das Computer-Netzwerk aus.
  • Erläuternde, überall vorhandene Rechenumgebung
  • 30 stellt eine überall vorhandene Rechenumgebung 1000 dar, wie sie beispielsweise in einem Haus, in einem Büro oder an einem öffentlichen Ort instal liert sein kann, die eine große Anzahl von einbezogenen Rechenvorrichtungen umfasst, wie die dargestellte Vorrichtung 900 (25). Die überall vorhandene Rechenumgebung 1000 umfasst Personal-Computer 1002, 1004 (z. B. von dem Typ, der in 24 dargestellt ist), verbunden über ein Local Area Network (LAN) 1006. Der PC 1002 ist über einen universellen, seriellen Bus 1016 mit einem Telefon-Modem 1010, einer XDSL-Schnittstelle 1011 oder einem Kabel-Modem 1012 verbunden, die wiederum eine Verbindung mit dem Computer-Netzwerk, z. B. dem Internet, schaffen.
  • Verschiedene, eingebundene Rechenvorrichtungen verbinden sich auch mit dem Computer-Netzwerk über verschiedene Netzwerk-Verbindungen mit den PCs 1002, 1004. Diese umfassen eine Audio-Vorrichtung 1014 (z. B. Lautsprecher, Radio-Tuner, Mikrofon) und einen Drucker 1015, die den PC 1004 über eine USB 1017 verbinden. Auch verbinden sich eine digitale Kamera 1020, ein in der Hand haltbarer PC (H/PC) 1021 und eine andere, persönliche Rechenvorrichtung 1022 über einen Infrarot-Port (IRDA) 1024, der auch den PC 1004 über die USB 1017 verbindet. Auch sind Lichtschalter 1030 und entsprechende Haushaltsgeräte über ein auf einer A/C-Energieversorgungs-Leitung basierendem Netzwerk 1032 mit dem PC 1002 verbunden. Weiterhin verbindet eine Kette von IEEE 1394 Kabeln 1048 ein Digital-TV 1040, einen DVD-Player 1041, einen Digital-Video-Camcorder (DV/DVC) 1042, eine Audio-Vorrichtung 1043 (z. B. CD-Player/Rekorder, Radioempfänger, Verstärker, und ähnliche Audio-System-Komponenten) und eine Spiel-Konsole 1044. Vorrichtungen, wie beispielsweise ein tragbares Telefon 1050 und eine Fernsteuerung 1051, haben eine Funkfrequenz-Netzwerk-Verbindung mit dem PC 1004.
  • Mit deren verschiedenen, miteinander netzwerkmäßigen Verbindungen, sind die eingebetteten Rechenvorrichtungen „sichtbar", und, zugänglich von einer Client-Vorrichtung 950 (30), auch mit dem Computer-Netzwerk verbunden.
  • Kontrakt-Definitions-Sprache
  • Übersicht
  • Kontrakte bzw. Verträge beschreiben das öffentliche Verhalten von UPnP-Vorrichtungen, und alternativ von anderen Daten-Einheiten (Entities) auf dem Web (erreichbar meistens über HTTP) oder einem anderen Computer-Netzwerk, das auf Nachrichten reagiert und diese abgibt. Der Kontrakt ist in einer Contract Definition Language (CDL) geschrieben. Die Nachrichten für den größten Teil sind strukturierte Dokumente, z. B. in XML. Die Nachrichten können auch HTML Seiten sein, Streaming-Medien, Bilder oder andere Daten-Typen, geeignet für das WebObject.
  • Der Kontrakt wird die folgenden Attribute eines WebObject beschreiben:
    • • Endpunkt (gut definierter Name)
    • • Protokoll
    • • Benachrichtigungs-Muster
    • • Zuführungs-Charakteristika
    • • Payloads
  • Alle diese Attribute müssen nicht in dem Kontrakt vorhanden sein, da einige davon (der Endpunkt, zum Beispiel) nicht zu dem Zeitpunkt der Entwicklung verfügbar sein können.
  • Protokoll-Beschreibung
  • Auf WebObject kann unter Verwendung von mehreren Protokollen zugegriffen werden: HTTP, GENA, SMTP, FDP, MSMQ, ... Dieser Abschnitt diskutiert, wie die Protokoll-Bindungen insbesondere mit einem WebObject zu beschreiben sind. Die Dokumenten-Vorlagen (Templates) zum Beschreiben des Protokolls verwenden das Format:
  • Figure 00990001
  • Das „protocol" Element kann ein „id" Attribut haben. Dies ist dann nützlich, wenn mehrere Benachrichtigungs-Muster dieselbe Protokoll-Definition verwenden werden. Dies wird in weiterem Detail nachfolgend angegeben.
  • Zum Zweck der Vereinfachung werden hier nur auf HTTP basierende Protokolle abgedeckt. Eine Erweiterung dieses Modells, um andere Protokolle abzudecken, ergibt sich unmittelbar.
  • HTTP
    Figure 01000001
  • Diese Beschreibung zeigt an, dass das folgende gültige URLs sind:
    http://search.yahoo.com/bin/search?pattern=Rio+player&limit=50&xml=yes
    http://search.yahoo.com/bin/search?xml=yes&pattern=Rio+player
  • Der Grund für ein Nichtzuordnen der Frage-Variablen zu dem GET Verb kommt daher, dass es gültig ist, eine POST Nachricht zu einem URL, der Frage-Variablen enthält, zu schicken.
  • Das „value" Attribut für das „QUERY" Element impliziert, dass der Wert statisch ist – er muss als ein Teil des URL behandelt werden. Ein Deklarieren auf diese Art und Weise ermöglicht, dass der geeignete Aufbau der Frage-Folge durch den Anrufer gehandhabt werden kann.
  • POST
    Figure 01000002
  • Figure 01010001
  • Das „default" Attribut gibt an, dass der Wert des Parameters geändert werden kann.
  • M-POST
    Figure 01010002
  • Das M-POST und die eingeschlossenen MAN Elemente erklären den vorgeschriebenen Erweiterungs-Mechanismus, der verwendet werden muss. Der optionale Erweiterungs-Mechanismus kann auch auf diese Art und Weise gehandhabt werden.
  • Das „Header" Element ermöglicht die Deklaration von HTTP Headers, die verwendet werden müssen.
  • GENA
  • Payload Beschreibung
  • Nachfolgend ist ein Beispiel einer XML Payload-Beschreibung angegeben.
  • Figure 01010003
  • Figure 01020001
  • Unter Verwendung dieser Erklärung, sind das Nachfolgende gültige XML-Fragmente:
  • Figure 01030001
  • Benachrichtigungs-Muster
  • Die Benachrichtigungs-Muster-Deklaration arbeitet als eine Verankerung für ein Abfragen zusammen des Protokolls, der Zuführ-Charakteristika und der Payload-Informationen. Die Benachrichtigungs-Muster-Deklarationen können diese Typen umfassen:
    • • Anforderung/Antwort
    • • Nachfrage/Antwort
    • • In einer Richtung
  • Anforderung/Antwort (RR). Das RR-Muster wird benannt. Die zwei Beispiele nachfolgend sind äquivalente Mechanismen, um das Protokoll zu deklarieren, das für das RR-Benachrichtigungs-Muster verwendet werden soll. Dieser Verknüpfungs-Mechanismus ist dann nützlich, wenn mehrere RR-Paare dieselben Protokoll-Daten verwenden. Dies ist der Fall für UPnP. Auch kann ein Dienst mehrere Protokolle zum Erreichen desselben „Verfahren"-Aufrufs einsetzen. Das „ist" („is") Attribut akzeptiert eine Liste von ID-Refs – voraussetzend, dass irgendeines der Protokolle gleich für ein Zugreifen auf die Funktionalität geeignet ist.
  • Figure 01030002
  • Figure 01040001
  • Die Payloads für eine Anforderung, eine Antwort und einen Fehler werden in dem Fall von XML Daten durch die Namen der Elemente, auf die durch das „is" Attribut Bezug genommen ist, identifiziert. Die Schema-Informationen werden dahin angenommen, dass sie in demselben Dokument vorhanden sind. Das Nachfolgende sind Beispiele, die die zwei Schemata verwenden:
  • Figure 01040002
  • Die DCL beschreibt hier die Element-Deklarationen in dem „Schema" Block, im Gegensatz dazu, sie mit den Benachrichtigungs-Muster-Definitionen zu „streuen". Die Gründe hierfür sind:
    • • Wiederverwendung von Element-Deklarationen ist einfach.
    • • Man kann einen Fragment-Validierungs-Support so verwenden, wie er ist.
    • • Beibehalten von Schemata an einer Stelle ist konsistent mit der Verwendung von In-Line-Schemata in SQLI2 und ADO.
  • In dem Fall, dass die Anforderung oder Antwort nicht XML Dokumente, sondern HTML Dokumente, sind, oder binäre Dateien, wird die nachfolgende Syntax verwendet werden. Das enthaltende Element definiert die Art der Daten. Die Verwendung von MIME liegt nicht in dem HTTP spezifischen Sinne vor, sondern in dem Sinne „Art des Payload". Das Vorhandensein der „is" Attribute zeigt an, dass der MIME Typ „text/xml." ist.
  • Figure 01050001
  • Zuführungs-Charakteristika
  • Der Kontrakt kann die Zuführungs-Charakteristika (manchmal auch bezeichnet als Qualität eines Dienstes), erforderlich oder unterstützt durch den Server, spezifizieren. Beispiele sind:
    • • Geordnete, beste Bemühung (ordered, best-effort)
    • • Garantierte Zuführung
    • • Fire-and-forget
    • • Exakt einmal
    • • Mindestens einmal
    • • Transaktional
  • Beispiel
  • Die 44–46 zeigen einen beispielhaften Kontrakt (Vertrag) zum Zusammenarbeiten mit einem Stock-Quote-Service.
  • Die 47–50 zeigen ein XML-Schema zum Definieren von Kontrakten. Indem die Prinzipien der Erfindung unter Bezugnahme auf eine dargestellte Ausführungsform beschrieben und dargestellt worden sind, wird erkannt werden, dass die dargestellte Ausführungsform in dem Aufbau und im Detail modifiziert werden kann, ohne solche Prinzipien zu verlassen. Es sollte verständlich werden, dass die Programme, Prozesse oder Verfahren, die hier beschrieben sind, nicht zu einem bestimmten Typ einer Computer-Vorrichtung in Bezug gesetzt sind oder darauf beschränkt sind, ohne dass dies in anderer Weise angegeben ist. Verschiedene Typen von spezialisierten Computer-Vorrichtungen oder solchen für allgemeine Zwecke können in Verbindung mit den Lehren, die hier beschrieben sind, verwendet werden, oder dazu, Operationen entsprechend dazu auszuführen. Elemente der dargestellten Ausführungsform, dargestellt in einer Software, können in einer Hardware, und vice versa, ausgeführt werden.
  • Im Hinblick auf die vielen, möglichen Ausführungsformen, bei denen die Prinzipien der Erfindung angewandt werden können, sollte erkannt werden, dass die detaillierten Ausführungsformen nur erläuternd sind, und sollten nicht als den Schutzumfang der Erfindung einschränkend angesehen werden. Im Gegensatz dazu werden als Erfindung alle Ausführungsformen beansprucht, wie sie innerhalb des Schutzumfangs der nachfolgenden Ansprüche, und Äquivalenten dazu, fallen.

Claims (12)

  1. Computervorrichtung, die einen Benutzer-Steuerpunkt (104) mit Verbindungsmöglichkeit zu wenigstens einer gesteuerten Vorrichtung (107) über ein Vernetzungsmedium bereitstellt, wobei die Computervorrichtung umfasst: ein Dokument zur Beschreibung der gesteuerten Vorrichtung, das eine Dienststeuerungs-Protokolldeklaration für wenigstens einen Dienst hat, der durch die wenigstens eine gesteuerte Vorrichtung bereitgestellt wird, wobei die Dienststeuerungs-Protokolldeklaration Inhalt und Abfolge von Mitteilungen (413) zum Austausch mit der wenigstens einen gesteuerten Vorrichtung zur Durchführung von Steuerung des wenigstens einen Dienstes (210–217) beschreibt; und einen allgemeinen programmierenden Schnittstelle-zu-Netzwerk-Mitteilungsadapter, der auf Basis des Dokumentes zur Beschreibung der gesteuerten Vorrichtung arbeitet und eine Struktur einer Programmierschnittstelle generiert, die spezifisch für den wenigstens einen Dienst ist, und die Programmierschnittstelle zu Anwendungsprogrammen bereitstellt, die auf der Computervorrichtung laufen, und Aufrufe an die Programmierschnittstelle in Netzwerk-Mitteilungen entsprechend dem Dienststeuerungs-Protokoll (402) umwandelt, das durch das Dokument zur Beschreibung der gesteuerten Vorrichtung definiert wird, und die Netzwerk-Mitteilungen über das Vernetzungsmedium an die gesteuerte Vorrichtung ausgibt, um Befehle des wenigstens einen Dienstes aufzurufen.
  2. Computervorrichtung nach Anspruch 1, wobei die Programmierschnittstelle eine Objektintegrations-Schnittstelle (414) entsprechend einem objektorientierten Programmiermodell ist.
  3. Verfahren für ein Client-Programm auf einer ersten Computervorrichtung zum programmorientierten Steuern eines Dienstes (210–217) einer logischen Vorrichtung (107), die in einem Datenübertragungs-Netzwerk auf einer entfernten Computervorrichtung implementiert ist, über Peer-to-Peer-Vernetzungs-Verbindungsmöglichkeit von der ersten Computervorrichtung in dem Datenübertragungs-Netzwerk, wobei das Verfahren umfasst: Erhalten eines Beschreibungsdokumentes (226) über Peer-to-Peer-Vernetzungs-Verbindungsmöglichkeit von der entfernten Computervorrichtung, wobei das Beschreibungsdokument ein dienstspezifisches Protokoll definiert, das einen Austausch von Datenmitteilungen (413) über Peer-to-Peer-Vernetzungs-Verbindungsmöglichkeit mit der entfernten Computervorrichtung zum Steuern des Dienstes der logischen Vorrichtung auf der entfernten Computervorrichtung einschließt; dynamisches Generieren, auf Basis des Beschreibungsdokumentes, einer Instanz einer programmorientierten Schnittstelle zum Aufrufen durch das Client-Programm, um dienstspezifische Operationen zur Fernsteuerung des Dienstes der logischen Vorrichtung auszulösen; Umsetzen, beim Aufrufen der Methodenelemente durch das Client-Programm, des Aufrufs der programmorientierten Schnittstelle des Client-Programms in den Austausch von Datenmitteilungen über Peer-to-Peer-Netzwerk-Verbindungsmöglichkeit entsprechend dem Beschreibungsdokument, um Steuerung des Dienstes der logischen Vorrichtung zu bewirken.
  4. Verfahren nach Anspruch 3, wobei die programmorientierte Schnittstelle eine Objektintegrationsschnittstelle eines objektorientierten Programmiermodells ist.
  5. Verfahren nach Anspruch 3, wobei die Datenmitteilungen (413) in einer Auszeichnungssprache sind und über ein HTTP-Protokoll ausgetauscht werden.
  6. Verfahren nach Anspruch 3, wobei die dienstspezifischen Operationen Aufrufen von Befehlen des Dienstes (210–217), Abfragen eines Status des Dienstes und Empfangen von Ereignissen des Dienstes sowie Antworten darauf einschließen.
  7. Verfahren nach Anspruch 3, wobei der Dienst (210–217) eine Gruppe von Eigenschaften aufweist, die einen Status des Dienstes definieren, und die dienstspezifischen Operationen Abfragen und Einstellen von Werten der Gruppe von Eigenschaften einschließen.
  8. Computerlesbares Medium, das durch Computer ausführbaren Software-Programmcode zum Ausführen auf einer ersten Computervorrichtung in einem Datenübertragungs-Netzwerk enthält, um ein Verfahren für ein Client-Programm auf der ersten Computervorrichtung zum programmorientierten Steuern eines Dienstes (210–217) einer logischen Vorrichtung (107), die auf einer entfernten Computervorrichtung in einem Datenübertragungs-Netzwerk implementiert ist, über Peer-to-Peer-Vernetzungs-Verbindungsmöglichkeit von der ersten Computervorrichtung in dem Datenübertragungs-Netzwerk durchzuführen, wobei das Verfahren umfasst: Erhalten eines Beschreibungsdokumentes (226) über Peer-to-Peer-Vernetzung von der entfernten Computervorrichtung, wobei das Beschreibungsdokument ein dienstspezifisches Protokoll definiert, das einen Austausch von Datenmitteilungen (413) über Peer-to-Peer-Vernetzungs-Verbindungsmöglichkeit mit der entfernten Computervorrichtung zum Steuern des Dienstes der logischen Vorrichtung auf der entfernten Computervorrichtung einschließt; dynamisches Generieren, auf Basis des Beschreibungsdokumentes, einer Instanz einer programmorientierten Schnittstelle zum Aufrufen durch das Client-Programm, um dienstspezifische Operationen zur Fernsteuerung des Dienstes der logischen Vorrichtung auszulösen Umsetzen, beim Aufrufen der Methodenelemente durch das Client-Programm, des Aufrufs der programmorientierten Schnittstelle des Client-Programms in den Austausch von Datenmitteilungen über Peer-to-Peer-Vernetzungs-Verbindungsmöglichkeit entsprechend dem Beschreibungsdokument, um Steuerung des Dienstes der logischen Vorrichtung durchzuführen.
  9. Computerlesbares Medium nach Anspruch 8, wobei die programmorientierte Schnittstelle eine Objektintegrations-Schnittstelle eines objektorientierten Programmiermodells ist.
  10. Computerlesbares Medium nach Anspruch 8, wobei die Datenmitteilungen (413) in einer Auszeichnungssprache sind und über ein HTTP-Protokoll ausgetauscht werden.
  11. Computerlesbares Medium nach Anspruch 8, wobei die dienstspezifischen Operationen Aufrufen von Befehlen des Dienstes (210–217), Abfragen eines Status des Dienstes und Empfangen von Ereignissen des Dienstes sowie Antworten darauf einschließen.
  12. Computerlesbares Medium nach Anspruch 8, wobei der Dienst (210–217) eine Gruppe von Eigenschaften aufweist, die einen Status des Dienstes definieren, und die dienstspezifischen Operationen Abfragen und Einstellen von Werten der Gruppe von Eigenschaften einschließen.
DE60019750T 1999-06-11 2000-06-07 Allgemeines api zur gerätefernsteuerung Expired - Lifetime DE60019750T2 (de)

Applications Claiming Priority (7)

Application Number Priority Date Filing Date Title
US13913799P 1999-06-11 1999-06-11
US139137P 1999-06-11
US16023599P 1999-10-18 1999-10-18
US160235P 1999-10-18
US43285499A 1999-11-02 1999-11-02
US432854 1999-11-02
PCT/US2000/015690 WO2000078001A2 (en) 1999-06-11 2000-06-07 General api for remote control of devices

Publications (2)

Publication Number Publication Date
DE60019750D1 DE60019750D1 (de) 2005-06-02
DE60019750T2 true DE60019750T2 (de) 2005-09-29

Family

ID=27385293

Family Applications (1)

Application Number Title Priority Date Filing Date
DE60019750T Expired - Lifetime DE60019750T2 (de) 1999-06-11 2000-06-07 Allgemeines api zur gerätefernsteuerung

Country Status (6)

Country Link
US (2) US7085814B1 (de)
EP (1) EP1188291B1 (de)
AT (1) ATE294480T1 (de)
AU (1) AU5728500A (de)
DE (1) DE60019750T2 (de)
WO (1) WO2000078001A2 (de)

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE102009056758A1 (de) * 2009-01-28 2010-07-29 Dspace Digital Signal Processing And Control Engineering Gmbh Verfahren zur Beeinflussung eines Steuergerätes und Manipulationseinheit
US8166344B2 (en) 2009-01-28 2012-04-24 Dspace Digital Signal Processing And Control Engineering Gmbh Method for controlling an operating mechanism and a manipulation unit
US8171341B2 (en) 2009-01-28 2012-05-01 Dspace Digital Signal Processing And Control Engineering Gmbh Method for controlling an operating mechanism and a manipulation unit
EP2701360B1 (de) * 2012-08-21 2019-05-08 BSH Hausgeräte GmbH Hausgerät mit Kommunikationsmodul

Families Citing this family (473)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7693748B1 (en) * 1991-06-03 2010-04-06 Ewinwin, Inc. Method and system for configuring a set of information including a price and volume schedule for a product
US7818212B1 (en) 1999-10-22 2010-10-19 Ewinwin, Inc. Multiple criteria buying and selling model
US6892230B1 (en) * 1999-06-11 2005-05-10 Microsoft Corporation Dynamic self-configuration for ad hoc peer networking using mark-up language formated description messages
US6876991B1 (en) * 1999-11-08 2005-04-05 Collaborative Decision Platforms, Llc. System, method and computer program product for a collaborative decision platform
US6895558B1 (en) * 2000-02-11 2005-05-17 Microsoft Corporation Multi-access mode electronic personal assistant
US8135796B1 (en) * 2000-05-09 2012-03-13 Oracle America, Inc. Mechanism and apparatus for accessing and addressing services in a distributed computing environment
US7577834B1 (en) * 2000-05-09 2009-08-18 Sun Microsystems, Inc. Message authentication using message gates in a distributed computing environment
US7263719B2 (en) 2000-05-15 2007-08-28 Hewlett-Packard Development Company, L.P. System and method for implementing network security policies on a common network infrastructure
US7024686B2 (en) 2000-05-15 2006-04-04 Hewlett-Packard Development Company, L.P. Secure network and method of establishing communication amongst network devices that have restricted network connectivity
US7020718B2 (en) 2000-05-15 2006-03-28 Hewlett-Packard Development Company, L.P. System and method of aggregating discontiguous address ranges into addresses and masks using a plurality of repeating address blocks
US8069205B1 (en) * 2000-06-16 2011-11-29 8X8, Inc. Communications controller and method therefor
US7181487B1 (en) * 2000-07-07 2007-02-20 Schneider Automation Inc. Method and system for transmitting and activating an application requesting human intervention in an automation network
US7117239B1 (en) * 2000-07-28 2006-10-03 Axeda Corporation Reporting the state of an apparatus to a remote computer
US6757714B1 (en) * 2000-07-28 2004-06-29 Axeda Systems Operating Company, Inc. Reporting the state of an apparatus to a remote computer
JP2002077755A (ja) * 2000-08-29 2002-03-15 Sharp Corp エージェントインタフェース装置
FR2813471B1 (fr) * 2000-08-31 2002-12-20 Schneider Automation Systeme de communication d'un equipement d'automatisme base sur le protocole soap
US8108543B2 (en) 2000-09-22 2012-01-31 Axeda Corporation Retrieving data from a server
US7185014B1 (en) 2000-09-22 2007-02-27 Axeda Corporation Retrieving data from a server
US11467856B2 (en) 2002-12-12 2022-10-11 Flexiworld Technologies, Inc. Portable USB device for internet access service
US11204729B2 (en) 2000-11-01 2021-12-21 Flexiworld Technologies, Inc. Internet based digital content services for pervasively providing protected digital content to smart devices based on having subscribed to the digital content service
US7318086B2 (en) 2000-11-20 2008-01-08 Flexiworld Technologies, Inc. System for mobile and pervasive output
US7171475B2 (en) * 2000-12-01 2007-01-30 Microsoft Corporation Peer networking host framework and hosting API
EP1346534B1 (de) * 2000-12-28 2012-11-14 Abb Ab Verfahren, systemarchitektur und computersoftware zur kommunikation zwischen einrichtungen
US20020097408A1 (en) 2001-01-19 2002-07-25 Chang William Ho Output device for universal data output
US8909739B2 (en) 2001-01-29 2014-12-09 Universal Electronics Inc. System and method for upgrading the remote control functionality of a device
US7181490B1 (en) * 2001-02-14 2007-02-20 Cisco Technology, Inc. Method and apparatus for mapping network events to names of network devices
DE10107701A1 (de) * 2001-02-19 2002-09-05 Siemens Ag Verfahren für einen automatischen Rückruf in einem paket-orientierten Netzwerk
US7433942B2 (en) * 2001-02-27 2008-10-07 Intel Corporation Network management
US7734285B2 (en) * 2001-04-03 2010-06-08 Qualcomm Incorporated Method and apparatus for network initiated uninstallation of application program over wireless network
US7747764B2 (en) * 2001-04-20 2010-06-29 Rockwell Automation Technologies, Inc. Web access for non-TCP/IP control devices of an industrial control system
US20030061333A1 (en) * 2001-05-04 2003-03-27 Stephen Dean System and method for universal networked device management
US6971001B1 (en) * 2001-05-17 2005-11-29 Accenture Global Services Gmbh General and reusable components for defining net-centric application program architectures
US7930352B2 (en) * 2001-06-25 2011-04-19 At&T Intellectual Property Ii, L.P. System and method for sorting electronic communications
US6957259B1 (en) 2001-06-25 2005-10-18 Bellsouth Intellectual Property Corporation System and method for regulating emails by maintaining, updating and comparing the profile information for the email source to the target email statistics
FR2826761B1 (fr) * 2001-06-27 2003-10-17 Canon Kk Procede d'analyse d'un document represente dans un langage de balisage
US7356803B2 (en) * 2001-07-02 2008-04-08 Bea Systems, Inc. Annotation based development platform for asynchronous web services
US7587515B2 (en) * 2001-12-19 2009-09-08 International Business Machines Corporation Method and system for restrictive caching of user-specific fragments limited to a fragment cache closest to a user
US7254601B2 (en) 2001-12-20 2007-08-07 Questra Corporation Method and apparatus for managing intelligent assets in a distributed environment
US6658091B1 (en) 2002-02-01 2003-12-02 @Security Broadband Corp. LIfestyle multimedia security system
US7370093B2 (en) * 2002-03-07 2008-05-06 Brother Kogyo Kabushiki Kaisha Electronic apparatus and system capable of assigning appropriate address
US6651100B2 (en) * 2002-03-12 2003-11-18 Lexmark International, Inc. Automatic negotiation of an internet protocol address for a network connected device
US20050066037A1 (en) * 2002-04-10 2005-03-24 Yu Song Browser session mobility system for multi-platform applications
US6931405B2 (en) * 2002-04-15 2005-08-16 Microsoft Corporation Flexible subscription-based event notification
US7178149B2 (en) 2002-04-17 2007-02-13 Axeda Corporation XML scripting of soap commands
JP2003309664A (ja) * 2002-04-17 2003-10-31 Sony Corp 端末装置、データ送受信システム及びデータ送受信開始方法
US9565275B2 (en) 2012-02-09 2017-02-07 Rockwell Automation Technologies, Inc. Transformation of industrial data into useful cloud information
US7606890B1 (en) * 2002-06-04 2009-10-20 Rockwell Automation Technologies, Inc. System and methodology providing namespace and protocol management in an industrial controller environment
US7512906B1 (en) * 2002-06-04 2009-03-31 Rockwell Automation Technologies, Inc. System and methodology providing adaptive interface in an industrial controller environment
US7899707B1 (en) 2002-06-18 2011-03-01 Ewinwin, Inc. DAS predictive modeling and reporting function
US8116889B2 (en) * 2002-06-27 2012-02-14 Openpeak Inc. Method, system, and computer program product for managing controlled residential or non-residential environments
KR20040005503A (ko) * 2002-07-10 2004-01-16 엘지전자 주식회사 홈 네트워크의 유피엔피 기능 분산 시스템
DE10234304A1 (de) * 2002-07-26 2004-02-19 Endress + Hauser Gmbh + Co. Kg Verfahren zum Aktualisieren von Gerätebeschreibungen für Feldgeräte der Prozessautomatisierungstechnik
US7433915B2 (en) * 2002-08-01 2008-10-07 Xerox Corporation System and method for controlling communication
US7689463B1 (en) 2002-08-28 2010-03-30 Ewinwin, Inc. Multiple supplier system and method for transacting business
GB2393529B (en) * 2002-09-24 2006-06-14 Hewlett Packard Co Improvements relating to data delivery
DE10250102A1 (de) * 2002-10-28 2004-07-15 Deutsche Thomson-Brandt Gmbh Verfahren zur Verwaltung von eingerichteten logischen Verbindungen in einem Netzwerk verteilter Stationen sowie Netzwerkstation
US20040083196A1 (en) * 2002-10-29 2004-04-29 Jason Reasor Hardware property management system and method
FR2846821B1 (fr) * 2002-11-04 2005-03-11 Cit Alcatel Dispositif et procede de controle de donnees de gestion d'equipements de reseau, pour un systeme de gestion de reseau de communications
US7177790B2 (en) * 2002-11-13 2007-02-13 Hewlett-Packard Development Company, L.P. Method and apparatus for providing virtual devices
US8495180B2 (en) * 2002-12-11 2013-07-23 Broadcom Corporation Server architecture supporting a personal media exchange network
US7908401B2 (en) 2002-12-12 2011-03-15 Flexiworld Technology, Inc. Method and device for wireless communication between computing devices
US7346669B2 (en) * 2002-12-19 2008-03-18 Intel Corporation Method, apparatus and system for processing message bundles on a network
US20040133896A1 (en) * 2002-12-20 2004-07-08 Sony Corporation And Sony Electronics, Inc. Network device application interface
JP3577067B2 (ja) * 2002-12-24 2004-10-13 一 福嶋 動的ｉｐアドレス割当てを受けた機器を管理する方法およびシステム
US7987489B2 (en) 2003-01-07 2011-07-26 Openpeak Inc. Legacy device bridge for residential or non-residential networks
US20040133595A1 (en) * 2003-01-08 2004-07-08 Black Karl S. Generation of persistent document object models
DE10302477A1 (de) * 2003-01-23 2005-02-24 Deutsche Thomson-Brandt Gmbh Verfahren zur Verfügbarmachung eines Eingabeparameters einer Netzwerkstation eines Netzwerks eines ersten Typs in einem Netzwerk eines zweiten Typs sowie Verbindungseinheit zur Verbindung der Netzwerke des ersten und zweiten Typs
KR100493890B1 (ko) * 2003-01-28 2005-06-10 삼성전자주식회사 다양한 디바이스의 지원이 가능한 사용자 인터페이스 변환시스템 및 방법
US7966418B2 (en) 2003-02-21 2011-06-21 Axeda Corporation Establishing a virtual tunnel between two computer programs
JP2004302564A (ja) * 2003-03-28 2004-10-28 Hitachi Ltd ネームサービス提供方法及びその実施装置並びにその処理プログラム
EP1614254A1 (de) * 2003-04-04 2006-01-11 Computer Associates Think, Inc. Verfahren und system zur alarmmitteilung
JP2004312412A (ja) * 2003-04-08 2004-11-04 Sony Corp コンテンツ提供サーバ、情報処理装置、および方法、並びにコンピュータ・プログラム
JP2004312413A (ja) * 2003-04-08 2004-11-04 Sony Corp コンテンツ提供サーバ、情報処理装置、および方法、並びにコンピュータ・プログラム
CN107885679B (zh) 2003-04-11 2021-10-08 富意科技公司 一种可实现自动运行的集成电路存储设备或方法
KR100533667B1 (ko) * 2003-04-15 2005-12-05 삼성전자주식회사 효율적인 홈 네트워크 관리 시스템 및 방법
US7221331B2 (en) * 2003-05-05 2007-05-22 Microsoft Corporation Method and system for auxiliary display of information for a computing device
US7827232B2 (en) * 2003-05-05 2010-11-02 Microsoft Corporation Record button on a computer system
US20040235520A1 (en) 2003-05-20 2004-11-25 Cadiz Jonathan Jay Enhanced telephony computer user interface allowing user interaction and control of a telephone using a personal computer
EP1636713B1 (de) * 2003-06-02 2016-04-27 Seiko Epson Corporation Bildanzeigeeinrichtung und verfahren zur kommunikation mit einer bildanzeigeeinrichtung über ein netzwerk
US7546584B2 (en) * 2003-06-16 2009-06-09 American Megatrends, Inc. Method and system for remote software testing
US7543277B1 (en) 2003-06-27 2009-06-02 American Megatrends, Inc. Method and system for remote software debugging
US7512689B2 (en) * 2003-07-02 2009-03-31 Intel Corporation Plug and play networking architecture with enhanced scalability and reliability
US7127305B1 (en) * 2003-07-21 2006-10-24 Eyecon Technologies, Inc. Method and apparatus for unified control of multiple devices
US7774441B2 (en) * 2003-08-05 2010-08-10 Siemens Industry Inc. System and method for configuring nodes in a network
KR100941139B1 (ko) * 2003-09-15 2010-02-09 엘지전자 주식회사 유피엔피(UPnP) 기반 네트워크의 미디어 스트리밍 파라미터 설정 방법
KR101015811B1 (ko) * 2003-09-23 2011-02-22 엘지전자 주식회사 UPnP 기반의 미디어 콘텐츠 재생을 제어하는 전자기기 및 그 방법
US7216221B2 (en) * 2003-09-30 2007-05-08 Microsoft Corporation Method and system for unified audio control on a personal computer
US7327221B1 (en) 2003-09-30 2008-02-05 Rockwell Automation Technologies, Inc. Power supply communication system and method
US7979519B2 (en) * 2003-10-09 2011-07-12 Oki Electric Industry Co., Ltd. System for providing information between different protocol environments cooperative with each other and a method therefor
US7343409B1 (en) * 2003-10-14 2008-03-11 Sun Microsystems, Inc. Method, system and article of manufacture for discovering devices in a network monitoring system
US11379897B1 (en) 2003-10-21 2022-07-05 Neil Thomas Computerized process to, for example, automate the home sale, mortgage loan financing and settlement process, and the home mortgage loan refinancing and settlement processes
US7496648B2 (en) * 2003-10-23 2009-02-24 Microsoft Corporation Managed peer name resolution protocol (PNRP) interfaces for peer to peer networking
US7716357B2 (en) * 2003-10-24 2010-05-11 Microsoft Corporation Service discovery and publication
US8205235B2 (en) * 2003-11-14 2012-06-19 Sharp Laboratories Of America, Inc. Systems and methods for representing a tuner device in a media server content directory service
JP4399773B2 (ja) * 2003-11-19 2010-01-20 横河電機株式会社 制御システム
KR100562907B1 (ko) * 2003-12-18 2006-03-21 삼성전자주식회사 미디어 컨텐츠의 통합 관리 장치 및 그 방법
GB0329499D0 (en) * 2003-12-19 2004-01-28 Nokia Corp Communication network
US7428735B2 (en) * 2004-02-06 2008-09-23 Microsoft Corporation Extensible configuration handlers
CA2555630C (en) * 2004-02-12 2016-04-05 Mobileframe Llc Integrated deployment of software projects
US7827258B1 (en) * 2004-03-01 2010-11-02 American Megatrends, Inc. Method, system, and apparatus for communicating with a computer management device
US11159484B2 (en) 2004-03-16 2021-10-26 Icontrol Networks, Inc. Forming a security network including integrated security system components and network devices
US8963713B2 (en) 2005-03-16 2015-02-24 Icontrol Networks, Inc. Integrated security network with security alarm signaling system
US9141276B2 (en) 2005-03-16 2015-09-22 Icontrol Networks, Inc. Integrated interface for mobile device
US20090077623A1 (en) 2005-03-16 2009-03-19 Marc Baum Security Network Integrating Security System and Network Devices
US11368429B2 (en) 2004-03-16 2022-06-21 Icontrol Networks, Inc. Premises management configuration and control
US11277465B2 (en) 2004-03-16 2022-03-15 Icontrol Networks, Inc. Generating risk profile using data of home monitoring and security system
US10444964B2 (en) 2007-06-12 2019-10-15 Icontrol Networks, Inc. Control system user interface
US11916870B2 (en) 2004-03-16 2024-02-27 Icontrol Networks, Inc. Gateway registry methods and systems
US10721087B2 (en) 2005-03-16 2020-07-21 Icontrol Networks, Inc. Method for networked touchscreen with integrated interfaces
US9531593B2 (en) 2007-06-12 2016-12-27 Icontrol Networks, Inc. Takeover processes in security network integrated with premise security system
US11113950B2 (en) 2005-03-16 2021-09-07 Icontrol Networks, Inc. Gateway integrated with premises security system
US10382452B1 (en) 2007-06-12 2019-08-13 Icontrol Networks, Inc. Communication protocols in integrated systems
US11244545B2 (en) 2004-03-16 2022-02-08 Icontrol Networks, Inc. Cross-client sensor user interface in an integrated security network
US20160065414A1 (en) 2013-06-27 2016-03-03 Ken Sundermeyer Control system user interface
US11582065B2 (en) 2007-06-12 2023-02-14 Icontrol Networks, Inc. Systems and methods for device communication
US11343380B2 (en) 2004-03-16 2022-05-24 Icontrol Networks, Inc. Premises system automation
US7711796B2 (en) 2006-06-12 2010-05-04 Icontrol Networks, Inc. Gateway registry methods and systems
US10313303B2 (en) 2007-06-12 2019-06-04 Icontrol Networks, Inc. Forming a security network including integrated security system components and network devices
US11489812B2 (en) 2004-03-16 2022-11-01 Icontrol Networks, Inc. Forming a security network including integrated security system components and network devices
US9729342B2 (en) 2010-12-20 2017-08-08 Icontrol Networks, Inc. Defining and implementing sensor triggered response rules
US11368327B2 (en) 2008-08-11 2022-06-21 Icontrol Networks, Inc. Integrated cloud system for premises automation
US10156959B2 (en) 2005-03-16 2018-12-18 Icontrol Networks, Inc. Cross-client sensor user interface in an integrated security network
US10522026B2 (en) 2008-08-11 2019-12-31 Icontrol Networks, Inc. Automation system user interface with three-dimensional display
US9609003B1 (en) 2007-06-12 2017-03-28 Icontrol Networks, Inc. Generating risk profile using data of home monitoring and security system
US10380871B2 (en) 2005-03-16 2019-08-13 Icontrol Networks, Inc. Control system user interface
US10200504B2 (en) 2007-06-12 2019-02-05 Icontrol Networks, Inc. Communication protocols over internet protocol (IP) networks
EP1738540B1 (de) 2004-03-16 2017-10-04 Icontrol Networks, Inc. Gebäudeverwaltungssystem
US11316958B2 (en) 2008-08-11 2022-04-26 Icontrol Networks, Inc. Virtual device systems and methods
US10339791B2 (en) 2007-06-12 2019-07-02 Icontrol Networks, Inc. Security network integrated with premise security system
US10142392B2 (en) 2007-01-24 2018-11-27 Icontrol Networks, Inc. Methods and systems for improved system performance
US11811845B2 (en) 2004-03-16 2023-11-07 Icontrol Networks, Inc. Communication protocols over internet protocol (IP) networks
US8635350B2 (en) 2006-06-12 2014-01-21 Icontrol Networks, Inc. IP device discovery systems and methods
US8988221B2 (en) 2005-03-16 2015-03-24 Icontrol Networks, Inc. Integrated security system with parallel processing architecture
US10375253B2 (en) 2008-08-25 2019-08-06 Icontrol Networks, Inc. Security system with networked touchscreen and gateway
US11201755B2 (en) 2004-03-16 2021-12-14 Icontrol Networks, Inc. Premises system management using status signal
US11677577B2 (en) 2004-03-16 2023-06-13 Icontrol Networks, Inc. Premises system management using status signal
US10237237B2 (en) 2007-06-12 2019-03-19 Icontrol Networks, Inc. Communication protocols in integrated systems
US9191228B2 (en) 2005-03-16 2015-11-17 Icontrol Networks, Inc. Cross-client sensor user interface in an integrated security network
US20050235048A1 (en) * 2004-04-20 2005-10-20 Jose Costa-Requena Exchanging multimedia data via a communications device
DE102004018980A1 (de) 2004-04-20 2005-12-08 Deutsche Thomson-Brandt Gmbh Verfahren zur Steuerung eines Gerätes in einem Netzwerk verteilter Stationen sowie Netzwerkstation
JP4533247B2 (ja) * 2004-06-08 2010-09-01 キヤノン株式会社 サービス提供システム、サービス提供方法及びサービス提供装置
US7607138B2 (en) * 2004-06-17 2009-10-20 Cisco Technology, Inc. System and method for optimizing inter-domain event services
US7652632B2 (en) 2004-08-18 2010-01-26 Ruckus Wireless, Inc. Multiband omnidirectional planar antenna apparatus with selectable elements
US8031129B2 (en) 2004-08-18 2011-10-04 Ruckus Wireless, Inc. Dual band dual polarization antenna array
US7696946B2 (en) 2004-08-18 2010-04-13 Ruckus Wireless, Inc. Reducing stray capacitance in antenna element switching
US7193562B2 (en) 2004-11-22 2007-03-20 Ruckus Wireless, Inc. Circuit board having a peripheral antenna apparatus with selectable antenna elements
US7292198B2 (en) 2004-08-18 2007-11-06 Ruckus Wireless, Inc. System and method for an omnidirectional planar antenna apparatus with selectable elements
US7965252B2 (en) 2004-08-18 2011-06-21 Ruckus Wireless, Inc. Dual polarization antenna array with increased wireless coverage
US7933628B2 (en) 2004-08-18 2011-04-26 Ruckus Wireless, Inc. Transmission and reception parameter control
US7880683B2 (en) 2004-08-18 2011-02-01 Ruckus Wireless, Inc. Antennas with polarization diversity
US7899497B2 (en) 2004-08-18 2011-03-01 Ruckus Wireless, Inc. System and method for transmission parameter control for an antenna apparatus with selectable elements
US8224966B2 (en) * 2004-08-24 2012-07-17 Cisco Technology, Inc. Reproxying an unproxied connection
US7519749B1 (en) 2004-08-25 2009-04-14 American Megatrends, Inc. Redirecting input and output for multiple computers
WO2006029391A2 (en) * 2004-09-09 2006-03-16 Amx Corporation Method, system and computer program using standard interfaces for independent device controllers
WO2006034407A2 (en) * 2004-09-23 2006-03-30 Airclic, Inc. Mobile process automation method
JP4588395B2 (ja) * 2004-09-24 2010-12-01 富士通株式会社 情報処理端末
JP4314178B2 (ja) * 2004-09-27 2009-08-12 株式会社リコー 画像形成装置、サービス機能分割統治方法およびサービス機能分割統治プログラム
US20060075042A1 (en) * 2004-09-30 2006-04-06 Nortel Networks Limited Extensible resource messaging between user applications and network elements in a communication network
CA2581199C (en) 2004-09-30 2013-09-24 Avaya Canada Corp. System and methods for announcing and locating services in a distributed peer-to-peer network
US20060093119A1 (en) * 2004-11-03 2006-05-04 Wilson Richard A Jr Leveraging real-time communications client
US20060106840A1 (en) * 2004-11-04 2006-05-18 International Business Machines Corporation System and method for tracking notifications in a publish subscribe system
JP4343814B2 (ja) * 2004-11-04 2009-10-14 キヤノン株式会社 情報処理装置及びその制御方法及びプログラム
US8638708B2 (en) 2004-11-05 2014-01-28 Ruckus Wireless, Inc. MAC based mapping in IP based communications
US8619662B2 (en) 2004-11-05 2013-12-31 Ruckus Wireless, Inc. Unicast to multicast conversion
TWI391018B (zh) 2004-11-05 2013-03-21 Ruckus Wireless Inc 藉由確認抑制之增強資訊量
US7505447B2 (en) 2004-11-05 2009-03-17 Ruckus Wireless, Inc. Systems and methods for improved data throughput in communications networks
JP4645165B2 (ja) * 2004-11-12 2011-03-09 セイコーエプソン株式会社 ネットワーク型プラグアンドプレイに対応したネットワーク装置の制御
CN1934750B (zh) 2004-11-22 2012-07-18 鲁库斯无线公司 包括具有可选择天线元件的外围天线装置的电路板
US7711868B2 (en) * 2004-11-23 2010-05-04 Microsoft Corporation Waking a main computer system to pre-fetch data for an auxiliary computing device
US7581034B2 (en) * 2004-11-23 2009-08-25 Microsoft Corporation Sending notifications to auxiliary displays
US8792414B2 (en) 2005-07-26 2014-07-29 Ruckus Wireless, Inc. Coverage enhancement using dynamic antennas
US7358912B1 (en) 2005-06-24 2008-04-15 Ruckus Wireless, Inc. Coverage antenna apparatus with selectable horizontal and vertical polarization elements
JP2006184999A (ja) * 2004-12-27 2006-07-13 Toshiba Corp ネットワーク装置および機器情報取得方法
US8856359B2 (en) * 2005-06-29 2014-10-07 Qualcomm Connected Experiences, Inc. Caller-callee association of a plurality of networked devices
US8055743B2 (en) * 2005-01-19 2011-11-08 Siemens Industry, Inc. System and method for configuring a network after replacing a node
US7893882B2 (en) 2007-01-08 2011-02-22 Ruckus Wireless, Inc. Pattern shaping of RF emission patterns
US7646343B2 (en) 2005-06-24 2010-01-12 Ruckus Wireless, Inc. Multiple-input multiple-output wireless antennas
US7953844B2 (en) * 2005-01-31 2011-05-31 Sharp Laboratories Of America, Inc. Systems and methods for implementing an instant messaging remote control service
JP4411222B2 (ja) * 2005-02-02 2010-02-10 Ｎｅｃインフロンティア株式会社 ネットワーク、ネットワーク端末装置及びそれらに用いるｉｐアドレス管理方法並びにそのプログラム
US7784065B2 (en) * 2005-02-07 2010-08-24 Microsoft Corporation Interface for consistent program interaction with auxiliary computing devices
US7647394B2 (en) * 2005-02-15 2010-01-12 Microsoft Corporation Scaling UPnP v1.0 device eventing using peer groups
US7640329B2 (en) * 2005-02-15 2009-12-29 Microsoft Corporation Scaling and extending UPnP v1.0 device discovery using peer groups
US9118717B2 (en) * 2005-02-18 2015-08-25 Cisco Technology, Inc. Delayed network protocol proxy for packet inspection in a network
US20060209810A1 (en) * 2005-03-08 2006-09-21 Openpeak Inc. Network-extensible and controllable telephone
US20060206442A1 (en) * 2005-03-08 2006-09-14 Rockwell Automation Technologies, Inc. Systems and methods for managing control systems through java extensions
US11615697B2 (en) 2005-03-16 2023-03-28 Icontrol Networks, Inc. Premise management systems and methods
US20120324566A1 (en) 2005-03-16 2012-12-20 Marc Baum Takeover Processes In Security Network Integrated With Premise Security System
US9306809B2 (en) 2007-06-12 2016-04-05 Icontrol Networks, Inc. Security system with networked touchscreen
US20110128378A1 (en) 2005-03-16 2011-06-02 Reza Raji Modular Electronic Display Platform
US20170180198A1 (en) 2008-08-11 2017-06-22 Marc Baum Forming a security network including integrated security system components
US11496568B2 (en) 2005-03-16 2022-11-08 Icontrol Networks, Inc. Security system with networked touchscreen
US11700142B2 (en) 2005-03-16 2023-07-11 Icontrol Networks, Inc. Security network integrating security system and network devices
US10999254B2 (en) 2005-03-16 2021-05-04 Icontrol Networks, Inc. System for data routing in networks
CN101151850A (zh) 2005-03-30 2008-03-26 皇家飞利浦电子股份有限公司 用于在家庭环境中控制服务的系统和方法
WO2006120590A1 (en) * 2005-05-09 2006-11-16 Koninklijke Philips Electronics N.V. A tunnel device to be used in networks for etablishing a connection therebetween
US9401822B2 (en) * 2005-06-09 2016-07-26 Whirlpool Corporation Software architecture system and method for operating an appliance exposing key press functionality to a network
US8705550B2 (en) * 2005-08-08 2014-04-22 Qualcomm Incorporated Device interface architecture and protocol
US8230491B2 (en) * 2005-08-19 2012-07-24 Opnet Technologies, Inc. Automatic access to network devices using various authentication schemes
KR100727999B1 (ko) * 2005-10-14 2007-06-14 삼성전자주식회사 ＵＰｎＰ 디바이스 정보를 효율적으로 관리하는 방법 및장치
US20070168507A1 (en) * 2005-11-15 2007-07-19 Microsoft Corporation Resource arbitration via persistent reservation
JP5110805B2 (ja) * 2005-11-18 2012-12-26 キヤノン株式会社 有線及び無線通信可能な通信端末、通信方法、プログラム
US8149847B2 (en) * 2005-11-23 2012-04-03 Comcast Cable Holdings, Llc Initializing, provisioning, and managing devices
TW200720931A (en) * 2005-11-30 2007-06-01 Benq Corp Systems, methods and machine-readable storage media for device or service management
CN101322346A (zh) 2005-12-01 2008-12-10 鲁库斯无线公司 借助于无线基站虚拟化的按需服务
US7752315B2 (en) * 2005-12-01 2010-07-06 International Business Machines Corporation Method for extending the use of SIP (session initiated protocol) for providing debug services
WO2007120227A2 (en) * 2005-12-06 2007-10-25 Thomas Paulos Device for wirless transmission of digital information
US7590762B2 (en) 2005-12-07 2009-09-15 Microsoft Corporation API for network discovery
US8010843B2 (en) * 2005-12-14 2011-08-30 American Megatrends, Inc. System and method for debugging a target computer using SMBus
US7949646B1 (en) * 2005-12-23 2011-05-24 At&T Intellectual Property Ii, L.P. Method and apparatus for building sales tools by mining data from websites
US20070186010A1 (en) * 2006-02-03 2007-08-09 Rockwell Automation Technologies, Inc. Extending industrial control system communications capabilities
US20070186011A1 (en) * 2006-02-03 2007-08-09 Rockwell Automation Technologies, Inc. Industrial protocol and gateway
KR101017365B1 (ko) 2006-02-14 2011-02-28 삼성전자주식회사 복수의 컨텐츠 디렉토리 서비스 장치를 동기화하는 방법,컨텐츠 디렉토리 서비스 장치 및 시스템
KR100782837B1 (ko) * 2006-02-15 2007-12-06 삼성전자주식회사 외부 튜너를 이용한 예약 녹화 서비스 제어 방법 및 장치
EP1999616A4 (de) * 2006-03-01 2010-08-18 Telcordia Licensing Company Ll Integrierte plattformen zur generierung und ausführung von diensten für konvergierte netze
KR100754431B1 (ko) * 2006-04-10 2007-08-31 삼성전자주식회사 Ｄｌｎａ 시스템에서 ｄｍｒ의 처리용량에 따른 컨텐츠변환방법
WO2007127120A2 (en) 2006-04-24 2007-11-08 Ruckus Wireless, Inc. Dynamic authentication in secured wireless networks
US9769655B2 (en) 2006-04-24 2017-09-19 Ruckus Wireless, Inc. Sharing security keys with headless devices
US9071583B2 (en) 2006-04-24 2015-06-30 Ruckus Wireless, Inc. Provisioned configuration for automatic wireless connection
US10079839B1 (en) 2007-06-12 2018-09-18 Icontrol Networks, Inc. Activation of gateway device
US8402150B1 (en) 2006-07-31 2013-03-19 Automated Irrigation Controls, LLC Manipulation of LonWorks® protocol for RF communications
US7613840B2 (en) * 2006-08-17 2009-11-03 General Electric Company Methods and apparatus for dynamic data acquisition configuration parameters
US8670725B2 (en) 2006-08-18 2014-03-11 Ruckus Wireless, Inc. Closed-loop automatic channel selection
US7783799B1 (en) 2006-08-31 2010-08-24 American Megatrends, Inc. Remotely controllable switch and testing methods using same
US20170185594A1 (en) * 2006-09-27 2017-06-29 Rockwell Automation Technologies, Inc. Universal, hierarchical layout of assets in a facility
US20080080543A1 (en) * 2006-09-28 2008-04-03 Rockwell Automation Technologies, Inc. Network switch with controller i/o capability
US8370479B2 (en) 2006-10-03 2013-02-05 Axeda Acquisition Corporation System and method for dynamically grouping devices based on present device conditions
US7680956B2 (en) * 2006-10-24 2010-03-16 Cisco Technology, Inc. Communicating additional information in a DNS update response by requesting deletion of a specific record
KR100745642B1 (ko) * 2006-10-31 2007-08-02 삼성전자주식회사 ＵＰｎＰ 네트워크 시스템에서의 ＯＢＪＥ 네트워크 기기서비스 장치 및 그 방법
US8616976B2 (en) 2006-11-07 2013-12-31 Core Wireless Licensing S.A.R.L. Gaming via peer-to-peer networks
US20090132712A1 (en) * 2007-11-19 2009-05-21 General Instrument Corporation Method and system for session mobility between end user communication devices
US7734717B2 (en) * 2006-12-05 2010-06-08 Nokia Corporation Software distribution via peer-to-peer networks
US20080147880A1 (en) * 2006-12-14 2008-06-19 Morris Robert P Methods And Systems For Routing A Message Over A Network
US20080147827A1 (en) * 2006-12-14 2008-06-19 Morris Robert P Method And System For Synchronizing Operating Modes Of Networked Appliances
US8065397B2 (en) 2006-12-26 2011-11-22 Axeda Acquisition Corporation Managing configurations of distributed devices
US8170183B2 (en) * 2007-01-22 2012-05-01 Control4 Corporation Systems and methods for providing a message service for a site
US20080178198A1 (en) * 2007-01-22 2008-07-24 Media Ripple, Llc Distributed digital media management
US11706279B2 (en) 2007-01-24 2023-07-18 Icontrol Networks, Inc. Methods and systems for data communication
US7633385B2 (en) 2007-02-28 2009-12-15 Ucontrol, Inc. Method and system for communicating with and controlling an alarm system from a remote server
US7984497B2 (en) * 2007-04-04 2011-07-19 Microsoft Corporation System and method for binding a subscription-based computing system to an internet service provider
US8451986B2 (en) 2007-04-23 2013-05-28 Icontrol Networks, Inc. Method and system for automatically providing alternate network access for telecommunications
US8216221B2 (en) 2007-05-21 2012-07-10 Estech, Inc. Cardiac ablation systems and methods
US8611378B2 (en) * 2007-05-29 2013-12-17 Red Hat, Inc. Message handling multiplexer
US8505028B2 (en) * 2007-05-30 2013-08-06 Red Hat, Inc. Flow control protocol
KR101113237B1 (ko) * 2007-05-30 2012-02-20 삼성전자주식회사 ＵＰｎＰ 네트워크의 서비스를 원격의 디바이스에게제공하는 방법 및 장치
US7921227B2 (en) * 2007-05-30 2011-04-05 Red Hat, Inc. Concurrent stack
US7992153B2 (en) * 2007-05-30 2011-08-02 Red Hat, Inc. Queuing for thread pools using number of bytes
US7733863B2 (en) * 2007-05-30 2010-06-08 Red Hat, Inc. Out of band messages
US10423309B2 (en) 2007-06-12 2019-09-24 Icontrol Networks, Inc. Device integration framework
US11237714B2 (en) 2007-06-12 2022-02-01 Control Networks, Inc. Control system user interface
US10616075B2 (en) 2007-06-12 2020-04-07 Icontrol Networks, Inc. Communication protocols in integrated systems
US10051078B2 (en) 2007-06-12 2018-08-14 Icontrol Networks, Inc. WiFi-to-serial encapsulation in systems
US11212192B2 (en) 2007-06-12 2021-12-28 Icontrol Networks, Inc. Communication protocols in integrated systems
US11423756B2 (en) * 2007-06-12 2022-08-23 Icontrol Networks, Inc. Communication protocols in integrated systems
US11089122B2 (en) 2007-06-12 2021-08-10 Icontrol Networks, Inc. Controlling data routing among networks
US11601810B2 (en) 2007-06-12 2023-03-07 Icontrol Networks, Inc. Communication protocols in integrated systems
US10389736B2 (en) 2007-06-12 2019-08-20 Icontrol Networks, Inc. Communication protocols in integrated systems
US10498830B2 (en) 2007-06-12 2019-12-03 Icontrol Networks, Inc. Wi-Fi-to-serial encapsulation in systems
US10666523B2 (en) 2007-06-12 2020-05-26 Icontrol Networks, Inc. Communication protocols in integrated systems
US10523689B2 (en) 2007-06-12 2019-12-31 Icontrol Networks, Inc. Communication protocols over internet protocol (IP) networks
US11218878B2 (en) 2007-06-12 2022-01-04 Icontrol Networks, Inc. Communication protocols in integrated systems
US11646907B2 (en) 2007-06-12 2023-05-09 Icontrol Networks, Inc. Communication protocols in integrated systems
US11316753B2 (en) 2007-06-12 2022-04-26 Icontrol Networks, Inc. Communication protocols in integrated systems
KR101493692B1 (ko) * 2007-06-22 2015-02-16 삼성전자주식회사 이벤트 메시지 전송 방법, 이벤트 메시지 수신 방법,피제어 장치 및 제어 포인트
KR101495536B1 (ko) * 2007-06-22 2015-02-25 삼성전자주식회사 동적으로 변경되는 ＵＰｎＰ 명세를 제공하는 방법 및 장치
US8478861B2 (en) 2007-07-06 2013-07-02 Axeda Acquisition Corp. Managing distributed devices with limited connectivity
US8547899B2 (en) 2007-07-28 2013-10-01 Ruckus Wireless, Inc. Wireless network throughput enhancement through channel aware scheduling
US10223903B2 (en) 2010-09-28 2019-03-05 Icontrol Networks, Inc. Integrated security system with parallel processing architecture
US11831462B2 (en) 2007-08-24 2023-11-28 Icontrol Networks, Inc. Controlling data routing in premises management systems
US7774490B2 (en) * 2007-09-20 2010-08-10 Microsoft Corporation Crisscross cancellation protocol
US7844764B2 (en) * 2007-10-01 2010-11-30 Honeywell International Inc. Unitary control module with adjustable input/output mapping
US8108911B2 (en) 2007-11-01 2012-01-31 Comcast Cable Holdings, Llc Method and system for directing user between captive and open domains
KR101474840B1 (ko) * 2007-11-05 2014-12-19 삼성전자 주식회사 ＵＰｎＰ 기반의 네트워크 시스템 및 그 제어 방법
KR101544210B1 (ko) * 2007-11-26 2015-08-13 삼성전자주식회사 네트워크에서 에러 정보를 통지하기 위한 방법 및 시스템
US20090161579A1 (en) * 2007-12-20 2009-06-25 Mika Saaranen Method, system, and apparatus for implementing network capable input devices
WO2009086600A1 (en) * 2008-01-07 2009-07-16 Avega Systems Pty Ltd Systems and methods for providing dual-control functionality in a networked digital media device
US8355343B2 (en) 2008-01-11 2013-01-15 Ruckus Wireless, Inc. Determining associations in a mesh network
KR101478621B1 (ko) * 2008-01-15 2015-01-02 삼성전자주식회사 ＵＰｎＰ 네트워크에 다중으로 원격 접속 서비스를제공하는 ＵＰｎＰ 장치 및 그 방법
US11916928B2 (en) 2008-01-24 2024-02-27 Icontrol Networks, Inc. Communication protocols over internet protocol (IP) networks
US8365203B2 (en) * 2008-03-20 2013-01-29 Willflow Limited Method for creating a native application for mobile communications device in real-time
US8170481B2 (en) * 2008-03-24 2012-05-01 Intel Corporation Techniques for discovering services provided in a wireless network
US8060353B2 (en) * 2008-05-02 2011-11-15 Iguran LLC Flow cytometer remote monitoring system
US8670942B2 (en) * 2008-05-02 2014-03-11 Inguran, Llc Flow cytometer remote monitoring system
US8949936B2 (en) * 2008-06-19 2015-02-03 Microsoft Technology Licensing, Llc Hosted network device user interface
US8261322B2 (en) 2008-06-19 2012-09-04 Microsoft Corporation Home networking web-based service portal
US20170185278A1 (en) 2008-08-11 2017-06-29 Icontrol Networks, Inc. Automation system user interface
US8107671B2 (en) 2008-06-26 2012-01-31 Microsoft Corporation Script detection service
US8266514B2 (en) * 2008-06-26 2012-09-11 Microsoft Corporation Map service
US8713697B2 (en) 2008-07-09 2014-04-29 Lennox Manufacturing, Inc. Apparatus and method for storing event information for an HVAC system
US9471406B2 (en) * 2008-07-09 2016-10-18 International Business Machines Corporation Remote product invocation framework
US11792036B2 (en) 2008-08-11 2023-10-17 Icontrol Networks, Inc. Mobile premises automation platform
US11758026B2 (en) 2008-08-11 2023-09-12 Icontrol Networks, Inc. Virtual device systems and methods
US10530839B2 (en) 2008-08-11 2020-01-07 Icontrol Networks, Inc. Integrated cloud system with lightweight gateway for premises automation
US11729255B2 (en) 2008-08-11 2023-08-15 Icontrol Networks, Inc. Integrated cloud system with lightweight gateway for premises automation
US11258625B2 (en) 2008-08-11 2022-02-22 Icontrol Networks, Inc. Mobile premises automation platform
KR101614945B1 (ko) * 2008-08-20 2016-04-25 삼성전자주식회사 홈 네트워크에서의 개인정보 보호 방법 및 장치
US8645559B2 (en) * 2008-09-22 2014-02-04 Microsoft Corporation Redirection of multiple remote devices
US8527096B2 (en) 2008-10-24 2013-09-03 Lennox Industries Inc. Programmable controller and a user interface for same
US8802981B2 (en) 2008-10-27 2014-08-12 Lennox Industries Inc. Flush wall mount thermostat and in-set mounting plate for a heating, ventilation and air conditioning system
US8437877B2 (en) 2008-10-27 2013-05-07 Lennox Industries Inc. System recovery in a heating, ventilation and air conditioning network
US8463442B2 (en) 2008-10-27 2013-06-11 Lennox Industries, Inc. Alarm and diagnostics system and method for a distributed architecture heating, ventilation and air conditioning network
US8437878B2 (en) 2008-10-27 2013-05-07 Lennox Industries Inc. Alarm and diagnostics system and method for a distributed architecture heating, ventilation and air conditioning network
US8855825B2 (en) 2008-10-27 2014-10-07 Lennox Industries Inc. Device abstraction system and method for a distributed-architecture heating, ventilation and air conditioning system
US8774210B2 (en) 2008-10-27 2014-07-08 Lennox Industries, Inc. Communication protocol system and method for a distributed-architecture heating, ventilation and air conditioning network
US8762666B2 (en) 2008-10-27 2014-06-24 Lennox Industries, Inc. Backup and restoration of operation control data in a heating, ventilation and air conditioning network
US8655490B2 (en) 2008-10-27 2014-02-18 Lennox Industries, Inc. System and method of use for a user interface dashboard of a heating, ventilation and air conditioning network
US8600558B2 (en) 2008-10-27 2013-12-03 Lennox Industries Inc. System recovery in a heating, ventilation and air conditioning network
US8295981B2 (en) 2008-10-27 2012-10-23 Lennox Industries Inc. Device commissioning in a heating, ventilation and air conditioning network
US9651925B2 (en) 2008-10-27 2017-05-16 Lennox Industries Inc. System and method for zoning a distributed-architecture heating, ventilation and air conditioning network
US9325517B2 (en) 2008-10-27 2016-04-26 Lennox Industries Inc. Device abstraction system and method for a distributed-architecture heating, ventilation and air conditioning system
US8442693B2 (en) 2008-10-27 2013-05-14 Lennox Industries, Inc. System and method of use for a user interface dashboard of a heating, ventilation and air conditioning network
US9678486B2 (en) 2008-10-27 2017-06-13 Lennox Industries Inc. Device abstraction system and method for a distributed-architecture heating, ventilation and air conditioning system
US8548630B2 (en) 2008-10-27 2013-10-01 Lennox Industries, Inc. Alarm and diagnostics system and method for a distributed-architecture heating, ventilation and air conditioning network
US8433446B2 (en) 2008-10-27 2013-04-30 Lennox Industries, Inc. Alarm and diagnostics system and method for a distributed-architecture heating, ventilation and air conditioning network
US8892797B2 (en) 2008-10-27 2014-11-18 Lennox Industries Inc. Communication protocol system and method for a distributed-architecture heating, ventilation and air conditioning network
US8452456B2 (en) 2008-10-27 2013-05-28 Lennox Industries Inc. System and method of use for a user interface dashboard of a heating, ventilation and air conditioning network
US8744629B2 (en) 2008-10-27 2014-06-03 Lennox Industries Inc. System and method of use for a user interface dashboard of a heating, ventilation and air conditioning network
US9632490B2 (en) 2008-10-27 2017-04-25 Lennox Industries Inc. System and method for zoning a distributed architecture heating, ventilation and air conditioning network
US8463443B2 (en) 2008-10-27 2013-06-11 Lennox Industries, Inc. Memory recovery scheme and data structure in a heating, ventilation and air conditioning network
US8788100B2 (en) 2008-10-27 2014-07-22 Lennox Industries Inc. System and method for zoning a distributed-architecture heating, ventilation and air conditioning network
US8452906B2 (en) 2008-10-27 2013-05-28 Lennox Industries, Inc. Communication protocol system and method for a distributed-architecture heating, ventilation and air conditioning network
US8564400B2 (en) 2008-10-27 2013-10-22 Lennox Industries, Inc. Communication protocol system and method for a distributed-architecture heating, ventilation and air conditioning network
US9432208B2 (en) * 2008-10-27 2016-08-30 Lennox Industries Inc. Device abstraction system and method for a distributed architecture heating, ventilation and air conditioning system
US8977794B2 (en) 2008-10-27 2015-03-10 Lennox Industries, Inc. Communication protocol system and method for a distributed-architecture heating, ventilation and air conditioning network
US8694164B2 (en) 2008-10-27 2014-04-08 Lennox Industries, Inc. Interactive user guidance interface for a heating, ventilation and air conditioning system
US8994539B2 (en) 2008-10-27 2015-03-31 Lennox Industries, Inc. Alarm and diagnostics system and method for a distributed-architecture heating, ventilation and air conditioning network
US8543243B2 (en) 2008-10-27 2013-09-24 Lennox Industries, Inc. System and method of use for a user interface dashboard of a heating, ventilation and air conditioning network
US8655491B2 (en) 2008-10-27 2014-02-18 Lennox Industries Inc. Alarm and diagnostics system and method for a distributed architecture heating, ventilation and air conditioning network
US8874815B2 (en) 2008-10-27 2014-10-28 Lennox Industries, Inc. Communication protocol system and method for a distributed architecture heating, ventilation and air conditioning network
US8600559B2 (en) 2008-10-27 2013-12-03 Lennox Industries Inc. Method of controlling equipment in a heating, ventilation and air conditioning network
US8798796B2 (en) 2008-10-27 2014-08-05 Lennox Industries Inc. General control techniques in a heating, ventilation and air conditioning network
US8661165B2 (en) 2008-10-27 2014-02-25 Lennox Industries, Inc. Device abstraction system and method for a distributed architecture heating, ventilation and air conditioning system
US9268345B2 (en) 2008-10-27 2016-02-23 Lennox Industries Inc. System and method of use for a user interface dashboard of a heating, ventilation and air conditioning network
US8560125B2 (en) 2008-10-27 2013-10-15 Lennox Industries Communication protocol system and method for a distributed-architecture heating, ventilation and air conditioning network
US8725298B2 (en) 2008-10-27 2014-05-13 Lennox Industries, Inc. Alarm and diagnostics system and method for a distributed architecture heating, ventilation and conditioning network
US8615326B2 (en) 2008-10-27 2013-12-24 Lennox Industries Inc. System and method of use for a user interface dashboard of a heating, ventilation and air conditioning network
US20100138550A1 (en) * 2008-12-01 2010-06-03 Kwangil Lee Ship-borne device managing method
KR101718889B1 (ko) * 2008-12-26 2017-03-22 삼성전자주식회사 홈 네트워크에서 디바이스에게 원격 애플리케이션을 제공하는 방법 및 장치
US8356106B2 (en) * 2009-02-02 2013-01-15 George Mason Intellectual Properties, Inc. Cache validating SCIT DNS server
US8217843B2 (en) 2009-03-13 2012-07-10 Ruckus Wireless, Inc. Adjustment of radiation patterns utilizing a position sensor
US8424024B2 (en) * 2009-03-26 2013-04-16 Digi International Inc. Application-specific serial port redirector
US8676926B2 (en) * 2009-04-15 2014-03-18 Wyse Technology L.L.C. System and method for handling remote drawing commands
US8863237B2 (en) * 2009-04-15 2014-10-14 Wyse Technology L.L.C. Remote-session-to-go method and apparatus
US9448815B2 (en) 2009-04-15 2016-09-20 Wyse Technology L.L.C. Server-side computing from a remote client device
US9189124B2 (en) 2009-04-15 2015-11-17 Wyse Technology L.L.C. Custom pointer features for touch-screen on remote client devices
US9578113B2 (en) 2009-04-15 2017-02-21 Wyse Technology L.L.C. Method and apparatus for transferring remote session data
US9553953B2 (en) 2009-04-15 2017-01-24 Dell Products L.P. Method and apparatus for extending capabilities of a virtualization domain to support features available in a normal desktop application
US8638211B2 (en) 2009-04-30 2014-01-28 Icontrol Networks, Inc. Configurable controller and interface for home SMA, phone and multimedia
US8698675B2 (en) 2009-05-12 2014-04-15 Ruckus Wireless, Inc. Mountable antenna elements for dual band antenna
US20100293555A1 (en) * 2009-05-14 2010-11-18 Nokia Corporation Method and apparatus of message routing
US10810692B1 (en) * 2009-06-16 2020-10-20 Neil Thomas Computerized process to, for example, automate the home sale, mortgage loan financing and settlement process, and the home mortgage loan refinancing and settlement processes
US20100322264A1 (en) * 2009-06-18 2010-12-23 Nokia Corporation Method and apparatus for message routing to services
US20100322236A1 (en) * 2009-06-18 2010-12-23 Nokia Corporation Method and apparatus for message routing between clusters using proxy channels
US8667122B2 (en) * 2009-06-18 2014-03-04 Nokia Corporation Method and apparatus for message routing optimization
EP2270658A1 (de) * 2009-06-22 2011-01-05 Clayster Asia Ltd. Verfahren und Computersystem zur Einführung von Kundenvorrichtungen in einem Client-Server-Netzwerk
US9979626B2 (en) 2009-11-16 2018-05-22 Ruckus Wireless, Inc. Establishing a mesh network with wired and wireless links
CN102763378B (zh) 2009-11-16 2015-09-23 鲁库斯无线公司 建立具有有线和无线链路的网状网络
US9391853B2 (en) 2009-12-23 2016-07-12 Apple Inc. Efficient service advertisement and discovery in a peer-to-peer networking environment with dynamic advertisement and discovery periods based on operating conditions
US9015136B2 (en) * 2010-01-22 2015-04-21 Microsoft Technology Licensing, Llc Storing temporary state data in separate containers
US20110185134A1 (en) * 2010-01-22 2011-07-28 Microsoft Corporation Temporary state service protocol
AU2011222509C1 (en) * 2010-03-05 2015-05-28 Infrared5, Inc. System and method for two way communication and controlling content in a web browser
PL3232610T3 (pl) * 2010-03-22 2020-09-21 Koninklijke Kpn N.V. System i sposób obsługi żądania konfiguracji
US8880685B2 (en) * 2010-03-26 2014-11-04 Be Intellectual Property, Inc. Gain to gain network for aircraft galley system
US20110252328A1 (en) * 2010-04-12 2011-10-13 Jeyhan Karaoguz System and method in a network controller for remotely monitoring and/or controlling devices
WO2011135457A2 (en) * 2010-04-30 2011-11-03 Positron Telecommunication Systems Systems and methods for providing a client-side application programming interface and telephony and private branch exchange services via an ethernet adapter
US8473967B2 (en) 2010-04-30 2013-06-25 Positron Telecommunication Systems Systems and methods for providing a client-side application programming interface to access a networked telecommunication resource
US20110276670A1 (en) * 2010-05-10 2011-11-10 Nokia Siemens Networks Oy Automated device integration
US10250678B2 (en) * 2010-07-07 2019-04-02 Qualcomm Incorporated Hybrid modes for peer discovery
KR101698354B1 (ko) * 2010-07-16 2017-01-23 삼성전자주식회사 홈 네트워크에서 멀티캐스트 메시지를 이용하여 복수 개의 원격 사용자 인터페이스 서버들을 제어하기 위한 장치 및 방법
US9407012B2 (en) 2010-09-21 2016-08-02 Ruckus Wireless, Inc. Antenna with dual polarization and mountable antenna elements
US8836467B1 (en) 2010-09-28 2014-09-16 Icontrol Networks, Inc. Method, system and apparatus for automated reporting of account and sensor zone information to a central station
KR20120066147A (ko) * 2010-12-14 2012-06-22 삼성전자주식회사 Ｄｌｎａ 기기 표시 방법 및 장치
US11750414B2 (en) 2010-12-16 2023-09-05 Icontrol Networks, Inc. Bidirectional security sensor communication for a premises security system
US9147337B2 (en) 2010-12-17 2015-09-29 Icontrol Networks, Inc. Method and system for logging security event data
JP5732896B2 (ja) * 2011-02-21 2015-06-10 セイコーエプソン株式会社 ネットワークシステムおよびネットワークシステムの制御方法
US9251097B1 (en) 2011-03-22 2016-02-02 Amazon Technologies, Inc. Redundant key management
US9563681B1 (en) 2012-08-08 2017-02-07 Amazon Technologies, Inc. Archival data flow management
US9213709B2 (en) 2012-08-08 2015-12-15 Amazon Technologies, Inc. Archival data identification
US9767098B2 (en) * 2012-08-08 2017-09-19 Amazon Technologies, Inc. Archival data storage system
US8621377B2 (en) 2011-03-24 2013-12-31 Honeywell International Inc. Configurable HVAC controller terminal labeling
WO2012151224A2 (en) 2011-05-01 2012-11-08 Ruckus Wireless, Inc. Remote cable access point reset
US9064017B2 (en) * 2011-06-01 2015-06-23 D2L Corporation Systems and methods for providing information incorporating reinforcement-based learning and feedback
US8762113B2 (en) * 2011-06-03 2014-06-24 Sony Computer Entertainment America Llc Method and apparatus for load testing online server systems
KR20120139574A (ko) * 2011-06-17 2012-12-27 삼성전자주식회사 ＵＰｎＰ 기반 디바이스 간 데이터 교환 장치 및 방법
US10045175B2 (en) * 2011-07-14 2018-08-07 Telefonaktiebolaget Lm Ericsson (Publ) Handling device generated data
US9407507B2 (en) * 2011-08-30 2016-08-02 Qualcomm Incorporated Topology discovery in a hybrid network
US9495326B2 (en) 2011-09-12 2016-11-15 Qualcomm Incorporated Providing communication path information in a hybrid communication network
US9183001B2 (en) * 2011-09-12 2015-11-10 Microsoft Technology Licensing, Llc Simulation of static members and parameterized constructors on an interface-based API
US8469816B2 (en) 2011-10-11 2013-06-25 Microsoft Corporation Device linking
US20140258526A1 (en) * 2011-10-24 2014-09-11 Schneider Electric Industries Sas Systems and methods of remote communication
US8813173B2 (en) * 2011-12-22 2014-08-19 Next Level Security Systems, Inc. Mobile communication device surveillance system
US20130205018A1 (en) * 2012-02-06 2013-08-08 Samsung Electronics Co., Ltd. Extending service discovery into cloud computing
JP6652236B2 (ja) * 2012-02-08 2020-02-19 マーベル ワールド トレード リミテッド 無線デバイスを検出するための方法及び装置
US9477936B2 (en) 2012-02-09 2016-10-25 Rockwell Automation Technologies, Inc. Cloud-based operator interface for industrial automation
US8756668B2 (en) 2012-02-09 2014-06-17 Ruckus Wireless, Inc. Dynamic PSK for hotspots
US10186750B2 (en) 2012-02-14 2019-01-22 Arris Enterprises Llc Radio frequency antenna array with spacing element
US9634403B2 (en) 2012-02-14 2017-04-25 Ruckus Wireless, Inc. Radio frequency emission pattern shaping
US9092610B2 (en) 2012-04-04 2015-07-28 Ruckus Wireless, Inc. Key assignment for a brand
CN102819500B (zh) * 2012-07-20 2016-01-20 腾讯科技（深圳）有限公司 一种创建外部设备控制界面的方法及装置
US9594384B2 (en) 2012-07-26 2017-03-14 Honeywell International Inc. Method of associating an HVAC controller with an external web service
US9652487B1 (en) 2012-08-08 2017-05-16 Amazon Technologies, Inc. Programmable checksum calculations on data storage devices
US9904788B2 (en) 2012-08-08 2018-02-27 Amazon Technologies, Inc. Redundant key management
US9092441B1 (en) 2012-08-08 2015-07-28 Amazon Technologies, Inc. Archival data organization and management
US9225675B2 (en) 2012-08-08 2015-12-29 Amazon Technologies, Inc. Data storage application programming interface
US8959067B1 (en) 2012-08-08 2015-02-17 Amazon Technologies, Inc. Data storage inventory indexing
US9354683B2 (en) 2012-08-08 2016-05-31 Amazon Technologies, Inc. Data storage power management
US9250811B1 (en) 2012-08-08 2016-02-02 Amazon Technologies, Inc. Data write caching for sequentially written media
US9779035B1 (en) 2012-08-08 2017-10-03 Amazon Technologies, Inc. Log-based data storage on sequentially written media
US8805793B2 (en) 2012-08-08 2014-08-12 Amazon Technologies, Inc. Data storage integrity validation
US10120579B1 (en) 2012-08-08 2018-11-06 Amazon Technologies, Inc. Data storage management for sequentially written media
US9830111B1 (en) 2012-08-08 2017-11-28 Amazon Technologies, Inc. Data storage space management
US9137563B2 (en) * 2012-08-24 2015-09-15 Google Technology Holdings LLC Processing emergency alert system messages
US9570799B2 (en) 2012-09-07 2017-02-14 Ruckus Wireless, Inc. Multiband monopole antenna apparatus with ground plane aperture
US9635197B2 (en) * 2012-11-30 2017-04-25 Samsung Electronics Co., Ltd. Method of executing application installed in outside server and image forming apparatus to perform the same
US10558581B1 (en) 2013-02-19 2020-02-11 Amazon Technologies, Inc. Systems and techniques for data recovery in a keymapless data storage system
US9578626B2 (en) 2013-03-15 2017-02-21 Qualcomm Incorporated Systems and methods for sharing context information in a neighbor aware network
US10425371B2 (en) 2013-03-15 2019-09-24 Trane International Inc. Method for fragmented messaging between network devices
EP2974045A4 (de) 2013-03-15 2016-11-09 Ruckus Wireless Inc Niedrigbandreflektor für eine gerichtete doppelbandantenne
US9438648B2 (en) 2013-05-09 2016-09-06 Rockwell Automation Technologies, Inc. Industrial data analytics in a cloud platform
US9703902B2 (en) 2013-05-09 2017-07-11 Rockwell Automation Technologies, Inc. Using cloud-based data for industrial simulation
US9786197B2 (en) 2013-05-09 2017-10-10 Rockwell Automation Technologies, Inc. Using cloud-based data to facilitate enhancing performance in connection with an industrial automation system
US10026049B2 (en) 2013-05-09 2018-07-17 Rockwell Automation Technologies, Inc. Risk assessment for industrial systems using big data
US9709978B2 (en) 2013-05-09 2017-07-18 Rockwell Automation Technologies, Inc. Using cloud-based data for virtualization of an industrial automation environment with information overlays
US9989958B2 (en) 2013-05-09 2018-06-05 Rockwell Automation Technologies, Inc. Using cloud-based data for virtualization of an industrial automation environment
US9659012B2 (en) * 2013-05-17 2017-05-23 Oracle International Corporation Debugging framework for distributed ETL process with multi-language support
US9426185B1 (en) * 2013-06-03 2016-08-23 Ayla Networks, Inc. Proximity based communication with embedded system
US20140359061A1 (en) * 2013-06-04 2014-12-04 Telefonaktiebolaget L M Ericsson (Publ) Method and Apparatus for Automating Access Rights Creation and Control in Machine-to-Machine Systems
US9215227B2 (en) * 2013-08-23 2015-12-15 Unisys Corporation Systems and methods for network communications
US9386067B2 (en) 2013-12-30 2016-07-05 Sonic Ip, Inc. Systems and methods for playing adaptive bitrate streaming content by multicast
KR102201616B1 (ko) * 2014-02-23 2021-01-12 삼성전자주식회사 전자 장치 간의 장치 검색 방법
US11405463B2 (en) 2014-03-03 2022-08-02 Icontrol Networks, Inc. Media content management
US11146637B2 (en) 2014-03-03 2021-10-12 Icontrol Networks, Inc. Media content management
US10560975B2 (en) * 2014-04-16 2020-02-11 Belkin International, Inc. Discovery of connected devices to determine control capabilities and meta-information
US9716623B2 (en) * 2014-05-22 2017-07-25 Verizon Patent And Licensing Inc. Automatic and secure activation of a universal plug and play device management device
US10404658B1 (en) * 2014-06-03 2019-09-03 Xevo Inc. Naming services extensions to URLs to handle inconstant resources, non-addressable resources, and large numbers of resources
US9596143B2 (en) * 2014-07-25 2017-03-14 Cohesity, Inc. Node discovery and cluster formation for a secondary storage appliance
US9894009B2 (en) * 2014-08-29 2018-02-13 Microsoft Technology Licensing, Llc Client device and host device subscriptions
US9443195B2 (en) 2014-11-26 2016-09-13 Sense Labs, Inc. Assisted labeling of devices with disaggregation
US9172623B1 (en) 2014-11-26 2015-10-27 Sense Labs, Inc. Communication of historical and real-time information about devices in a building
US10175276B2 (en) 2014-11-26 2019-01-08 Sense Labs, Inc. Identifying and categorizing power consumption with disaggregation
US9152737B1 (en) 2014-11-26 2015-10-06 Sense Labs, Inc. Providing notifications to a user
US9739813B2 (en) 2014-11-26 2017-08-22 Sense Labs, Inc. Determining information about devices in a building using different sets of features
US11042131B2 (en) 2015-03-16 2021-06-22 Rockwell Automation Technologies, Inc. Backup of an industrial automation plant in the cloud
US11513477B2 (en) 2015-03-16 2022-11-29 Rockwell Automation Technologies, Inc. Cloud-based industrial controller
US10496061B2 (en) 2015-03-16 2019-12-03 Rockwell Automation Technologies, Inc. Modeling of an industrial automation environment in the cloud
US11243505B2 (en) 2015-03-16 2022-02-08 Rockwell Automation Technologies, Inc. Cloud-based analytics for industrial automation
US10419497B2 (en) * 2015-03-31 2019-09-17 Bose Corporation Establishing communication between digital media servers and audio playback devices in audio systems
EP3281390B1 (de) * 2015-04-09 2022-03-23 OMRON Corporation Eingebetteter webserver
EP3278499A4 (de) * 2015-05-15 2019-01-09 Hewlett-Packard Development Company, L.P. Einbettung von informationen in einen audiodatenstrom für konnektivität
JP6606355B2 (ja) * 2015-05-29 2019-11-13 キヤノン株式会社 情報処理装置、情報処理方法、及びプログラム
US11386060B1 (en) 2015-09-23 2022-07-12 Amazon Technologies, Inc. Techniques for verifiably processing data in distributed computing systems
US10609185B2 (en) * 2015-11-04 2020-03-31 Rockwell Automation Technologies, Inc. Method for topology tree to learn about, present, and configure device information by automatically uploading device description files from device
CN108885592A (zh) * 2016-03-28 2018-11-23 株式会社索思未来 通信装置、通信方法以及通信程序
US9800958B1 (en) 2017-02-22 2017-10-24 Sense Labs, Inc. Training power models using network data
US10750252B2 (en) 2017-02-22 2020-08-18 Sense Labs, Inc. Identifying device state changes using power data and network data
US9699529B1 (en) 2017-02-22 2017-07-04 Sense Labs, Inc. Identifying device state changes using power data and network data
US20180344116A1 (en) 2017-06-02 2018-12-06 Irobot Corporation Scheduling and control system for autonomous robots
RU2020114622A (ru) * 2017-09-27 2021-10-27 Фрезениус Виаль Сас Система и способ для передачи данных о состоянии здоровья в среде медицинского контроля
CN108304176B (zh) * 2017-12-14 2021-09-07 广东数果科技有限公司 一种跨平台移动终端的可视化埋点方法
US11128563B2 (en) * 2018-06-22 2021-09-21 Sorenson Ip Holdings, Llc Incoming communication routing
US10740691B2 (en) 2018-10-02 2020-08-11 Sense Labs, Inc. Identifying devices connected to a smart plug
US11122136B2 (en) * 2018-10-22 2021-09-14 Red Hat, Inc. Quantum payload service for facilitating communications between a quantum computing system and classical computing systems
EP3814901A1 (de) 2018-12-03 2021-05-05 salesforce.com, inc. Automatisiertes betriebsmanagement für rechnersysteme
US11309974B2 (en) 2019-05-09 2022-04-19 Red Hat, Inc. Quantum channel routing utilizing a quantum channel measurement service
USD944731S1 (en) 2019-07-11 2022-03-01 Sense Labs, Inc. Electrical current sensor
US11536747B2 (en) 2019-07-11 2022-12-27 Sense Labs, Inc. Current transformer with self-adjusting cores
US11172057B2 (en) * 2019-10-04 2021-11-09 Soti Inc. Systems and methods for managing devices using dynamically configurable device and protocols definitions
US11165875B2 (en) * 2019-11-12 2021-11-02 International Business Machines Corporation Method and system for a discovery engine
CN111314203B (zh) * 2019-11-20 2022-11-29 北京字节跳动网络技术有限公司 一种通信方法、装置、介质和电子设备
WO2021147109A1 (zh) * 2020-01-23 2021-07-29 华为技术有限公司 信息传输方法以及相关设备
CN111324654A (zh) * 2020-02-18 2020-06-23 深圳壹账通智能科技有限公司 接口调用方法、系统、计算机设备及计算机可读存储介质
US20220345540A1 (en) * 2021-04-26 2022-10-27 Kyocera Document Solutions Inc. Electronic apparatus executing service in response to command from front end apparatus and front end apparatus managing electronic apparatus
CN114374673B (zh) * 2021-12-15 2023-07-25 东方通信股份有限公司 Pdt跨系统互联中信令网关选择最优媒体网关的方法
US20230247111A1 (en) * 2022-02-02 2023-08-03 Servicenow, Inc. Runtime module conversion

Family Cites Families (46)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5394556A (en) 1992-12-21 1995-02-28 Apple Computer, Inc. Method and apparatus for unique address assignment, node self-identification and topology mapping for a directed acyclic graph
US5559967A (en) 1993-03-18 1996-09-24 Apple Computer, Inc. Method and apparatus for a dynamic, multi-speed bus architecture in which an exchange of speed messages occurs independent of the data signal transfers
US5491800A (en) * 1993-12-20 1996-02-13 Taligent, Inc. Object-oriented remote procedure call networking system
US5748980A (en) 1994-05-27 1998-05-05 Microsoft Corporation System for configuring a computer system
US5787246A (en) 1994-05-27 1998-07-28 Microsoft Corporation System for configuring devices for a computer system
US5694546A (en) * 1994-05-31 1997-12-02 Reisman; Richard R. System for automatic unattended electronic information transport between a server and a client by a vendor provided transport software with a manifest list
US5546574A (en) * 1994-06-30 1996-08-13 At&T Corporation Peer-to-peer data concurrence processes and apparatus
EP0792493B1 (de) * 1994-11-08 1999-08-11 Vermeer Technologies, Inc. Herstellungshilfe für online-dienste mit gebührenfeststellung
US5627964A (en) 1994-12-13 1997-05-06 Microsoft Corporation Reduce or fail-safe bootstrapping of a system having a graphical user interface
US5623492A (en) * 1995-03-24 1997-04-22 U S West Technologies, Inc. Methods and systems for managing bandwidth resources in a fast packet switching network
US5796951A (en) * 1995-12-22 1998-08-18 Intel Corporation System for displaying information relating to a computer network including association devices with tasks performable on those devices
US5721825A (en) * 1996-03-15 1998-02-24 Netvision, Inc. System and method for global event notification and delivery in a distributed computing environment
US5787259A (en) 1996-03-29 1998-07-28 Microsoft Corporation Digital interconnects of a PC with consumer electronics devices
US5825750A (en) * 1996-03-29 1998-10-20 Motorola Method and apparatus for maintaining security in a packetized data communications network
US5764930A (en) 1996-04-01 1998-06-09 Apple Computer, Inc. Method and apparatus for providing reset transparency on a reconfigurable bus
US5809331A (en) 1996-04-01 1998-09-15 Apple Computer, Inc. System for retrieving configuration information from node configuration memory identified by key field used as search criterion during retrieval
US5881230A (en) 1996-06-24 1999-03-09 Microsoft Corporation Method and system for remote automation of object oriented applications
US5956487A (en) * 1996-10-25 1999-09-21 Hewlett-Packard Company Embedding web access mechanism in an appliance for user interface functions including a web server and web browser
US6122362A (en) * 1996-12-24 2000-09-19 Evolving Systems, Inc. Systems and method for providing network element management functionality for managing and provisioning network elements associated with number portability
US5903894A (en) 1997-03-03 1999-05-11 Microsoft Corporation System and method for using a hierarchical data structure to control and identify devices and represent connections between the devices
US6130892A (en) * 1997-03-12 2000-10-10 Nomadix, Inc. Nomadic translator or router
US5903728A (en) 1997-05-05 1999-05-11 Microsoft Corporation Plug-in control including an independent plug-in process
US5938752C1 (en) 1997-05-20 2002-02-05 Microsoft Corp System and method for encapsulating legacy data transport protocols for ieee 1394 serial bus
US6389464B1 (en) * 1997-06-27 2002-05-14 Cornet Technology, Inc. Device management system for managing standards-compliant and non-compliant network elements using standard management protocols and a universal site server which is configurable from remote locations via internet browser technology
US6115545A (en) * 1997-07-09 2000-09-05 Hewlett-Packard Company Automatic internet protocol (IP) address allocation and assignment
US5987135A (en) * 1997-07-25 1999-11-16 Prc Inc. System and method for controlling and monitoring remote distributed processing system
US6216152B1 (en) * 1997-10-27 2001-04-10 Sun Microsystems, Inc. Method and apparatus for providing plug in media decoders
US6457066B1 (en) * 1997-11-10 2002-09-24 Microsoft Corporation Simple object access protocol
US6085236A (en) * 1998-01-06 2000-07-04 Sony Corporation Of Japan Home audio video network with device control modules for incorporating legacy devices
US6230307B1 (en) * 1998-01-26 2001-05-08 Xilinx, Inc. System and method for programming the hardware of field programmable gate arrays (FPGAs) and related reconfiguration resources as if they were software by creating hardware objects
US6253208B1 (en) * 1998-03-31 2001-06-26 British Telecommunications Public Limited Company Information access
US6173316B1 (en) * 1998-04-08 2001-01-09 Geoworks Corporation Wireless communication device with markup language based man-machine interface
US6101499A (en) 1998-04-08 2000-08-08 Microsoft Corporation Method and computer program product for automatically generating an internet protocol (IP) address
US6370141B1 (en) * 1998-04-29 2002-04-09 Cisco Technology, Inc. Method and apparatus for configuring an internet appliance
KR100607215B1 (ko) * 1998-05-07 2006-08-01 삼성전자주식회사 네트워크에서 사용자와 디바이스 명령 및 제어 방법 및 장치
US6233611B1 (en) * 1998-05-08 2001-05-15 Sony Corporation Media manager for controlling autonomous media devices within a network environment and managing the flow and format of data between the devices
US6438744B2 (en) * 1998-07-15 2002-08-20 Microsoft Corporation Dynamic mapping of component interfaces
US6334178B1 (en) * 1998-08-31 2001-12-25 International Business Machines Corporation Multiprocessing system with automated propagation of changes to centrally maintained configuration settings
US6282568B1 (en) * 1998-12-04 2001-08-28 Sun Microsystems, Inc. Platform independent distributed management system for manipulating managed objects in a network
US6463447B2 (en) * 1998-12-16 2002-10-08 Rstar Corporation Optimizing bandwidth consumption for document distribution over a multicast enabled wide area network
US6529936B1 (en) * 1998-12-23 2003-03-04 Hewlett-Packard Company Object-oriented web server architecture suitable for various types of devices
US6480860B1 (en) * 1999-02-11 2002-11-12 International Business Machines Corporation Tagged markup language interface with document type definition to access data in object oriented database
US6430570B1 (en) * 1999-03-01 2002-08-06 Hewlett-Packard Company Java application manager for embedded device
US6405366B1 (en) * 1999-05-28 2002-06-11 Electronic Data Systems Corporation Multi-layered software application interface architecture
US6405310B1 (en) * 1999-07-09 2002-06-11 Hewlett-Packard Company System and method for peripheral system management using operation object interfaces for device control
US6401132B1 (en) * 1999-08-03 2002-06-04 International Business Machines Corporation Subchaining transcoders in a transcoding framework

Cited By (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE102009056758A1 (de) * 2009-01-28 2010-07-29 Dspace Digital Signal Processing And Control Engineering Gmbh Verfahren zur Beeinflussung eines Steuergerätes und Manipulationseinheit
US8074118B2 (en) 2009-01-28 2011-12-06 Dspace Digital Signal Processing And Control Engineering Gmbh Method for influencing a control unit and manipulation unit
US8166344B2 (en) 2009-01-28 2012-04-24 Dspace Digital Signal Processing And Control Engineering Gmbh Method for controlling an operating mechanism and a manipulation unit
US8171341B2 (en) 2009-01-28 2012-05-01 Dspace Digital Signal Processing And Control Engineering Gmbh Method for controlling an operating mechanism and a manipulation unit
DE102009056758B4 (de) * 2009-01-28 2017-07-27 Dspace Digital Signal Processing And Control Engineering Gmbh Verfahren zur Beeinflussung eines Steuergerätes und Manipulationseinheit
EP2701360B1 (de) * 2012-08-21 2019-05-08 BSH Hausgeräte GmbH Hausgerät mit Kommunikationsmodul

Also Published As

Publication number Publication date
WO2000078001B1 (en) 2001-10-18
DE60019750D1 (de) 2005-06-02
WO2000078001A2 (en) 2000-12-21
EP1188291B1 (de) 2005-04-27
EP1188291A2 (de) 2002-03-20
US7085814B1 (en) 2006-08-01
US20050267935A1 (en) 2005-12-01
AU5728500A (en) 2001-01-02
ATE294480T1 (de) 2005-05-15
WO2000078001A3 (en) 2001-08-16

Similar Documents

Publication Publication Date Title
DE60019750T2 (de) Allgemeines api zur gerätefernsteuerung
DE60036072T2 (de) Verfahren zur brückenverbindung von mehreren heimnetzsoftwarearchitekturen
DE69829219T2 (de) Verfahren und system in verbindung mit einem audio-video-netz
US6725281B1 (en) Synchronization of controlled device state using state table and eventing in data-driven remote device control model
DE69836101T2 (de) Ein audio-video-gerät
US7487230B2 (en) Dynamic self-configuration for AD HOC peer networking
US7640329B2 (en) Scaling and extending UPnP v1.0 device discovery using peer groups
US7647394B2 (en) Scaling UPnP v1.0 device eventing using peer groups
US7171475B2 (en) Peer networking host framework and hosting API
US6910068B2 (en) XML-based template language for devices and services
DE69926368T2 (de) Verfahren und vorrichtung für universellen zugriffsbefehl und kontrollinformation in einem netzwerk
DE60109029T2 (de) Zugriff auf ein in-haus netzwerk über das internet
DE60032054T2 (de) Erfassung von geographischen Daten
US20040120344A1 (en) Device discovery application interface
US20040133896A1 (en) Network device application interface
WO2002001833A1 (en) Remoting general purpose operating system services via a peer networking device control protocol
Saif et al. Internet access to a home area network
Hsu et al. Widget-based framework for web service discovery on multiple home social network
Zeadally et al. PLUG AND PLAY ARCHITECTURES IN PROXIMITY NETWORKS
Laubscher et al. Studio Exploring Using Universal Plug and Play

Legal Events

Date Code Title Description
8364 No opposition during term of opposition