DE60036604T2

DE60036604T2 - Informationsarchitektur höchsten niveaus für ein an geräte angepasstes hausnetzwerk

Info

Publication number: DE60036604T2
Application number: DE2000636604
Authority: DE
Inventors: Dongyan Santa Clara WANG; Richard Fremont HUMPLEMAN
Original assignee: Samsung Electronics Co Ltd
Current assignee: Samsung Electronics Co Ltd
Priority date: 1999-07-27
Filing date: 2000-07-27
Publication date: 2008-01-31
Anticipated expiration: 2020-07-28
Also published as: KR20010085806A; DE60036604D1; US20100070868A1; EP1145244A4; CA2345320A1; AU6321800A; CA2345320C; JP2003505804A; EP1145244A1; CN1324601C; CN1322355A; WO2001008150A1; US7610559B1; US9137034B2; EP1145244B1; KR100646006B1

Description

Die vorliegende Erfindung betrifft das Gebiet der Netzwerke und insbesondere Hausnetzwerke, an die Multimedia-Geräte angebunden sind.
Ein Netzwerk umfasst generell eine Kommunikationsverbindung und verschiedene Geräte, die die Fähigkeit zur Kommunikation besitzen und mit der Kommunikationsverbindung verbunden sind. Die Geräte schließen Computer, Peripheriegeräte, Router, Speichervorrichtungen und Vorrichtungen mit Prozessoren und Kommunikationsschnittstellen ein. Ein Beispiel für ein Netzwerk ist ein Hausnetzwerk für einen Haushalt, bei dem verschiedene Geräte miteinander verbunden sind. Ein üblicher Haushalt kann verschiedene Geräte, einschließlich Personalcomputern und Hausgeräten, die üblicherweise in einem Haus zu finden sind, enthalten. Der Begriff "Gerät" schließt als solcher üblicherweise logische Vorrichtungen oder andere Einheiten mit einer Funktionalität und der Fähigkeit zum Datenaustausch ein und kann nicht nur alle Arten von Hausgeräten, sondern auch Universalcomputer umfassen. Hausgeräte schließen solche elektronischen Geräte wie Sicherheitssysteme, Kinoanlagen, TVS, VCRs, Stereoanlagen und Dienste von Direkt-Rundstrahlsatelliten oder (DBSS, direct broadcast satellite services), auch als Digital-Satellitendienste (DSS) bekannt, Sprinkleranlagen, Lichtanlagen, Mikrowellengeräte, Spülmaschinen, Öfen/Herde, Waschmaschinen/Trockner und Verarbeitungssysteme in einem Fahrzeug ein.
Hausgeräte werden in der Regel dazu verwendet, Aufgaben auszuführen, die den Lebensstil und Lebensstandard eines Hausbesitzers verbessern. Zum Beispiel führt eine Spülmaschine die Aufgabe aus, schmutziges Geschirr zu waschen und befreit den Hausbesitzer von der Verpflichtung, das Geschirr per Hand zu waschen. Ein VCR kann ein Fernsehprogramm aufnehmen, um einem Hausbesitzer das Anschauen eines bestimmten Programms zu einem späteren Zeitpunkt zu ermöglichen. Sicherheitssysteme schützen die Wertgegenstände des Hausbesitzers und können die Angst des Hausbesitzers vor unbefugtem Zutritt verringern.
Hausgeräte, wie zum Beispiel Hauskinoanlagen, werden oftmals durch Benutzen einer einzigen, zentralen Bedienungseinheit, nämlich einer Fernbedienungsvorrichtung, gesteuert. Diese einzige, zentrale Bedienungseinheit ermöglicht einem Hausbesitzer, mehrere unterschiedliche Hausgeräte unter Benutzen einer einzigen Schnittstelle zu steuern und diesen Befehle zu erteilen. Viele Hersteller haben daher Bedienungseinheiten entwickelt, um ihre Hausgeräte von einer einzigen Schnittstelle aus zu steuern und diesen Befehle zu erteilen.
Ein Nachteil, der mit der Benutzung einer Fernbedienungseinheit zum Erteilen von Befehlen an und Steuern von Hausgeräten verbunden ist, ist der, dass eine Statik und Befehlslogik zum Steuern von und Erteilen von Befehlen an nur ein Hausgerät allein bereitstellt wird. Eine bestimmte Fernbedienungseinheit kann daher nur diejenigen Hausgeräte steuern und Befehle an diese erteilen, für die es die notwendige Steuer- und Befehlslogik umfasst. Zum Beispiel kann, wenn eine Fernbedienungseinheit die Logik zum Steuern eines Fernsehgeräts (TV), eines Videokassettenrekorders (VCR) und einer digitalen Videovorrichtung (digital video device, DVD), jedoch nicht einer CD-Platten-(CD-)Einheit umfasst, die Fernbedienungseinheit nicht zum Erteilen von Befehlen an und Steuern der CD-Einheit verwendet werden. Da neue Hausgeräte entwickelt werden, wird die Fernbedienungseinheit daneben nicht die neuen Hausgeräte steuern und Befehle an sie erteilen können, die eine Steuer- und Befehlslogik benötigen, die zu dem Zeitpunkt der Entwicklung der Fernbedienungseinheit nicht bekannt war.
Zudem kann eine Fernbedienungseinheit üblicherweise nur zum Erteilen von Befehlen und Steuern solcher Hausgeräte verwendet werden, die sich innerhalb des Signalbereichs der Fernbedienungseinheit befinden. Ein Benutzer kann daher die Fernbedienungseinheit nicht von einer einzigen Stelle im Haus aus verwenden, um Hausgeräte zu steuern und Befehle an diese zu erteilen, die zwar miteinander verbunden sind, sich jedoch in verschiedenen Bereichen des Hauses befinden. Zum Beispiel kann ein VCR, der sich oben im Schlafzimmer befindet, mit einem TV verbunden sein, der sich unten im Wohnzimmer befindet. Wenn ein Benutzer ein in dem sich oben im Schlafzimmer befindenden VCR enthaltenes Band auf dem sich unten im Wohnzimmer befindenden TV abspielen möchte, kann der Benutzer nicht beide, den TV und den VCR, von einer einzigen Position aus steuern und Befehle an diese erteilen.
Ein weiterer Nachteil, der mit der Benutzung von Fernbedienungseinheiten verbunden ist, ist der, dass die bekannten Fernbedienungseinheiten nicht eine Vielzahl verschiedener Geräte steuern können und insbesondere nicht eine Vielzahl von Geräten mit unterschiedlichen Fähigkeiten zu einer Kommunikation untereinander zum Ausführen von Aufgaben oder Bereitstellen eines Dienstes steuern können. Ferner stellen herkömmliche Netzwerksysteme keine Einrichtung für Software-Anwendungen in verschiedenen Geräten des Netzwerks zur automatischen Kommunikation untereinander zum Ausführen von Aufgaben ohne direkte Befehle des Benutzers bereit.
Um die oben genannten Probleme zu verringern, stellen einige Netzwerk-Modelle eine zentrale/einzige Benutzerschnittstelle (user interface, UI) in einem Gerät bereit, die statische Geräteinformationen für in einem Netzwerk miteinander verbundene Geräte zur Beutzersteuerung der Netzwerkgeräte einschließt. In solchen Netzwerken erfordert eine Änderung der Geräteinformationen (z.B. ein Symbol (ICON)) in einem Gerät jedoch eine Änderung und einen Neuaufbau der Seite höchsten Niveaus. Wenn das Gerät, das die zentrale Benutzerschnittstelle anzeigt, nicht zur Verfügung steht, wird die Benutzersteuerung des Netzwerks zudem eingeschränkt. Ein weiteres Problem bei einer zentralen/einzigen Seite ist, dass jedes UI-Gerät die gleiche Seite anzeigen muss und kein Spielraum für jeden Hersteller zur Verfügung steht, so dass er weder sein eigenes Aussehen und seine eigene Haptik für die UI generieren kann, noch die in dem UI-Gerät verwendete Technologie verändern kann. Der Inhalt eines Symbols/der Informationen, die ein Gerät darstellt/en, kann (können) nicht geändert werden und ein UI-Gerät ist nicht in der Lage, ein mehr hervorstechendes Aussehen für ein Symbol des Geräts, wie beispielsweise das Symbol für das UI-Gerät selbst, anzuzeigen. Noch kann ein Werkzeug zum Aufbauen der UI E-Commerce-Symbole von einem externen Web-Portal erhalten. Da ein zentrales/einziges UI-Gerät die UI steuert, kann ein solches Modell nicht für großtechnische Anwendungen standardisiert werden.
Es besteht daher der Bedarf nach einem Verfahren und einem System, das Vorrichtungen zum dynamischen Steuern und Erteilen von Befehlen in einem Hausnetzwerk bereitstellt. Es besteht auch der Bedarf nach einem solchen Verfahren und System, die die Fähigkeit für eines oder mehrere Geräte, die mit dem Netzwerk verbunden sind, bereitstellen, unabhängig voneinander verschiedene Darstellungen der Benutzerschnittstellen der Geräte, die mit dem Netzwerk verbunden sind, für das Erteilen von Befehlen und Steuern durch den Benutzer generieren.
Die WO 98 59282 A betrifft ein Hausnetzwerk, mit dem gerade mehrere Hausgeräte verbunden sind. Die Hausgeräte schließen Clients, d.h. Geräte, die einer Bedienperson einen Dienst in Form einer Bedienschnittstelle bereitstellen, einschließlich einer Hardware zur Grafikanzeige, und Server-Geräte, d.h. Module, die einen Dienst unterstützen, der jeder Dienst sein kann, der sich von einer Bedienschnittstelle, die von einem Client bereitgestellt wird, unterscheidet, ein. Jedes Hausgerät, das mit dem Hausnetzwerk verbunden ist, besitzt eine oder mehrere assoziierte HTML-Dateien. Die HTML-Dateien für ein entsprechendes Hausgerät definieren die Steuer- und Befehlsfunktionen für dieses bestimmte Hausgerät. Die HTML-Dateien enthalten zudem Daten, die einem Browser die graphische Darstellung der in den HTML-Dateien enthaltenen Informationen ermöglichen. Durch Anpassen an die HTML- und http-Internetstandards sendet jedes Hausgerät seine angepasste GUI an einen browserbasierten DTV, der als Client fungiert. Der browserbasierte DTV empfängt und interpretiert die HTML-Dateien, die mit den als Server fungierenden Hausgeräten assoziiert sind und zeigt die entsprechenden Steuer- und Befehlsinformationen graphisch auf seiner sichtbaren Anzeige an. Wenn die in der HTML-Datei eines Geräts enthaltenen Informationen graphisch auf dem DTV angezeigt werden, kann der Benutzer das Hausgerät von dem DTV aus, durch Auswählen der Symbole, die assoziierte Hyperlinks zum Starten der Steuerprogramme, die auf dem Bildschirm des DTV angezeigt werden, steuern. Insbesondere kann die Bedienung durch Übertragen eines graphischen Bedienobjekts (graphial control object, GCO), das sich vorzugsweise auf dem Server befindet, von dem Server zur Wiedergabe auf dem Client realisiert werden, um die GUI zu bilden. Das Aussehen und die Haptik der GUI werden daher mit dem angebundenen Server und nicht mit dem Client erzeugt.
Die nachveröffentlichte WO 99 57839 A offenbart Verfahren und Systeme zum Durchführen eines Dienstes in einem Hausnetzwerk mit einer Vielzahl von daran angebundenen Hausgeräten. Zum Anzeigen einer Benutzerschnittstelle ist ein Client-Gerät mit dem Hausnetzwerk verbunden. Ein Software-Agent auf dem Client-Gerät wird ausgeführt, um Informationen über die Auswahl der Netzwerkgeräte zu erhalten und die Informationen über die Auswahl auf einer Benutzerschnittstelle, die auf dem Client-Gerät angezeigt wird, anzuzeigen. Das erste, mit dem Netzwerk verbundene Hausgerät wird von der Benutzerschnittstelle, die auf dem Client-Gerät angezeigt wird, ausgewählt. Ein erste Datensatz bezüglich der Fähigkeit für das erste Hausgerät und ein zweiter Datensatz bezüglich der Fähigkeit für ein zweites, mit dem Netzwerk verbundenes Hausgerät werden ausgelesen. Die ersten und zweiten Datensätze bezüglich der Fähigkeiten beinhalten in einem strukturierten Format Informationen zum Identifizieren der Fähigkeiten des ersten bzw. zweiten Hausgeräts. Die ersten und zweiten Datensätze bezüglich der Fähigkeiten des ersten bzw. zweiten Hausgeräts werden miteinander verglichen. Das zweite Hausgerät wird von der auf dem Client-Gerät angezeigten Benutzerschnittstelle aus ausgewählt. Die Steuer- und Befehlsdaten, werden von dem Client-Gerät zu dem ersten und dem zweiten Hausgerät gesendet, um eine Kommunikation zwischen dem ersten und dem zweiten Hausgerät zum Ausführen des Dienstes zu erwirken.
Eine Aufgabe der vorliegenden Erfindung ist, eine Technik zum Bereitstellen einer Benutzerschnittstelle zum Steuern von Geräten in einem Netzwerk, das mehr als einen Client enthält, bereitzustellen.
Diese Aufgabe wird mit der Erfindung gelöst, wie es in den unabhängigen Ansprüchen definiert ist. Ausführungsformen sind in den abhängigen Ansprüchen angegeben.
In einer Ausführungsform stellt die vorliegende Erfindung ein Verfahren und ein System zum Generieren einer Benutzerschnittstelle in einer Vielzahl von mehreren Geräten, die mit dem Netzwerksystem verbunden sind, zum Steuern der Geräte, die gerade mit einem Netzwerk verbunden sind, bereit. In einer Version schließt das Netzwerksystem eine physikalische Schicht, wobei die physikalische Schicht ein Kommunikationsmedium bereitstellt, das von den Geräten für eine Kommunikation miteinander verwendet werden kann, und mehrere Geräte, die Informationen, einschließlich Geräteinformationen speichern, ein. Eine Vielzahl dieser mehreren Geräte, wobei jedes einen Agenten einschließt, der daran angepasst ist: a) Informationen von den gerade mit dem Netzwerk verbundenen Geräten zu erhalten, wobei diese Informationen Geräteinformationen einschließen; b) eine Benutzerschnittstellenbeschreibung auf Basis zumindest der erhaltenen Informationen in jedem dieser einen oder mehreren Geräte zu generieren, wobei die Benutzerschnittstellenbeschreibung in jedem Gerät mindestens eine Referenz enthält, die mit den Geräteinformationen von jedem der gerade mit dem Netzwerk verbundenen Geräte assoziiert ist; und c) eine oder mehrere Benutzerschnittstellen, von denen jede auf einer der einen oder mehrere Benutzerschnittstellenbeschreibungen basiert, auf einem oder mehreren, mit dem Netzwerk verbundenen Geräten, die in der Lage sind, eine Benutzerschnittstelle anzuzeigen, anzuzeigen, zur Benutzersteuerung dieser gerade mit dem Netzwerk verbundenen Geräte.
In einem Beispiel wird eine Beschreibung der UI höchsten Niveaus der Netzwerk-Geräte unabhängig von irgendeinem Netzwerkgerät und sicherlich von Geräten, die in der Lage sind, eine UI anzuzeigen (UI-Geräte), generiert. Das Generieren einer Benutzerschnittstelle in jedem Gerät statt dem Generieren einer zentralen UI ermöglicht, dass ein Gerät sein eigenes Symbol/seinen eigenen Text bevorzugt in der GUI zeigt.
Daneben ist jede GUI auf den Hersteller anpassbar, von einem Benutzer konfigurierbar und ist auch zuverlässiger, da es nicht von einem anderen Gerät, z.B. einem einzigen Zentralserver abhängt.
Diese und andere Merkmale, Aspekte und Vorteile der vorliegenden Erfindung werden anhand der folgenden Beschreibung, der beigefügten Ansprüche und der begleitenden Figuren besser verständlich, in denen:
1 ein beispielhaftes Blockdiagramm für die Architektur einer weiteren Ausführungsform eines Netzwerks gemäß der vorliegenden Erfindung zeigt;
2 ein beispielhaftes Blockdiagramm für die Architektur einer anderen Ausführungsform eines Netzwerks gemäß der vorliegenden Erdfindung zeigt;
3 ein Beispiel für ein Modell für eine geschichtete Schnittstelle veranschaulicht, die zur Kommunikation zwischen Hausgeräten gemäß der vorliegenden Erfindung verwendet werden kann;
4A ein Beispiel für ein Architekturschema eines DVCR-Servergeräts, das ein Video auf einem DTV-Client-Gerät wiedergibt, das in der Lage ist, eine Benutzerschnittstelle anzuzeigen, in einem Netzwerk gemäß der vorliegenden Erfindung zeigt;
4B ein weiteres Beispiel für ein Architekturschema eines Servergeräts, das mit einem Client-Gerät, das in der Lage ist, eine Benutzerschnittstelle anzuzeigen, in einem Netzwerk gemäß der vorliegenden Erfindung zeigt;
5 bis 6 Beispiele für GUIs höchsten Niveaus veranschaulichen, die einem Benutzer graphisch die Funktionen miteinander vernetzter Geräte darstellen;
7 ein beispielhaftes Blockdiagramm für die Architektur eines Hausnetzwerks zeigt, das gemäß einer weiteren Ausführungsform der vorliegenden Erfindung aufgebaut wurde;
8 einen beispielhaften Prozess gemäß der vorliegenden Erfindung für eine Kommunikation zwischen einem 1394-Netzwerk und einem Nicht-1394-Netzwerk für die Konfiguration einer IP-Adresse zeigt;
9A–C beispielhafte, funktionelle Blockdiagramme der Verbindungen zu den Daten- und Kontroll-Bits einer Ausführungsform der Architektur eines Erkennungssystems in einem Netzwerk gemäß einem weiteren Aspekt der vorliegenden Erfindung zeigen;
10 ein beispielhaftes Ablaufdiagramm der Erkennungs- und Konfigurations-Agenten in dem Hausnetzwerk in Verbindung mit den funktionellen Blockdiagrammen aus den 9A–C zeigt;
11 ein beispielhaftes Ablaufdiagramm des Benutzerschnittstellen-Agenten in dem Hausnetzwerk in Verbindung mit den funktionellen Blockdiagrammen aus den 9A–C zeigt; und
die Anhänge 1 bis 4 Beispiele für 1) die Beschreibung der Seite höchsten Niveaus 250 (Anhang 1); 2) Background.htm (Anhang 2); 3) Icon.htm (Anhang 3); und 4) Name.htm (Anhang 4) zeigen.
Um das Verständnis zu erleichtern, wurden, wenn möglich, die gleichen Bezugszeichen verwendet, um gleiche Elemente zu bezeichnen, die allen Figuren gemeinsam sind.
Unter Bezugnahme auf 1 umfasst ein Netzwerk 10 in einer Ausführungsform der vorliegenden Erfindung mehrere Geräte 11, einschließlich eines Client-Geräts 12 und mindestens einem Servergerät 14, die über eine Kommunikationsverbindung 16 miteinander verbunden sind. Die Kommunikationsverbindung 16 kann einen seriellen 1394-Bus einschließen, der eine physikalische Schicht (ein physikalisches Medium) zum Senden und Empfangen von Daten zwischen den verschiedenen, verbundenen Hausgeräten bereitstellt. Der serielle 1394-Bus unterstützt sowohl Multiplex-Audio/Video-(AN-)Kanäle als auch Standard-IP-(Internet Protocol-)Verbindungen (z.B. IETF RFC 2734). In bestimmten Ausführungsformen verwendet ein Hausnetzwerk eine IP-Vermittlungsschicht als Kommunikationsschicht des Hausnetzwerks. Es könnten jedoch andere Kommunikationsprotokolle dazu verwendet werden, die Verbindungen des Hausnetzwerks bereitzustellen. Die Erfindung kann zum Beispiel durch Verwenden des Function Control Protocol (FCP), wie es in der IEC 61883 definiert ist, oder irgendeines anderen geeigneten Protokolls realisiert werden. Ein Netzwerk kann daher allgemein zwei oder mehrere Geräte einschließen, die miteinander durch den Austausch über eine physikalische Schicht oder die Übertragung von Daten gemäß einem vorgegebenen Kommunikationsprotokoll verbunden sind.
Jedes Client-Gerät 12 kann mit einem oder mehreren Servergeräten 14 in dem Netzwerk 10 kommunizieren. Ferner kann jedes Servergerät 14 mit einem oder mehreren anderen Servergeräten 14 und einem oder mehreren Client-Geräten 12 in dem Netzwerk 10 kommunizieren. Jedes Client-Gerät 12 kann eine Benutzerkommunikationsschnittstelle umfassen, die Eingabegeräte, wie beispielsweise eine Maus und eine Tastatur zum Erfassen der Eingabe des Benutzers, und eine Anzeige zum Bereitstellen einer Benutzerschnittstelle für die Steuerung, damit ein Benutzer mit den vernetzten Geräten interagieren kann, einschließen. Die Benutzerschnittstelle kann eine graphische Benutzerschnittstelle (GUI) 18 zum Bereitstellen von Informationen für den Benutzer umfassen. Jedes Server-Gerät 14 schließt Hardware als Ressource in dem Netzwerk zum Bereitstellen von Diensten für den Benutzer ein und kann ferner einen Server oder ein Programm zu Steuern der Dienste 20, um die Server-Hardware zu steuern, umfassen.
Jedes Server-Gerät 14, außer der Benutzerschnittstelle zur Steuerung, stellt dem Benutzer einen Dienst bereit und jedes Client-Gerät 12, einschließlich der Benutzerschnittstelle zur Steuerung für die Interaktion des Benutzers mit dem Netzwerk 10, stellt einen Dienst bereit. Als solche interagieren nur Client-Geräte 12 direkt mit den Benutzern und Server-Geräte 14 interagieren nur mit den Client-Geräten 12 und anderen Servergeräten 14. Beispiele für Dienste können das Beziehen und Herunterrechnen von MPEG (MPEG-Sourcing/-Sinking) und Anzeige-Dienste umfassen.
In einer beispielhaften Ausführungsform der vorliegenden Erfindung verwendet ein browserbasiertes Netzwerk (z.B. ein Hausnetzwerk) die Internet-Technologie zum Steuern von und Erteilen von Befehlen an Geräte, einschließlich Client-Geräten und Servergeräten, die mit einem Netzwerk verbunden sind. Jedes Gerät enthält Geräteinformationen, wie beispielsweise Daten bezüglich der Schnittstelle (z.B. HTML, XML, JAVA, JAVASCRIPT, GIF, JPEG, Graphikdateien oder irgendein anderes Format, das für den angestrebten Zweck nützlich ist), die von einer Schnittstelle zum Erteilen von Befehlen an das Gerät und Steuern desselben über das Netzwerk bereitgestellt werden. In bestimmten Ausführungsformen umfasst jedes Gerät Geräteinformationen, wie beispielsweise eine oder mehrere Hypertext Markup Language-(Hypertext-Auszeichnungssprache, HTML)Seiten, die zum Erteilen von Befehlen an das Gerät und Steuern desselben zur Verfügung gestellt werden. Unter Verwenden der Browser-Technologie benutzt das Netzwerk zum Wiedergeben der HTML-Seiten Internet-Standards, um den Benutzer eine Vielzahl von graphischen Benutzeroberflächen (GUI) zum Erteilen von Befehlen an jedes Gerät und Steuern desselben bereitzustellen. In einem Beispiel ist das Netzwerk als Intranet aufgebaut.
In einer Ausführungsform umfasst ein Client-Gerät ein Gerät, das einer Bedienperson einen Dienst zum Bedienen der Schnittstelle bereitstellt, der eine Hardware für eine graphische Anzeige zum Abgehen der Verbindung und eine Maus oder eine andere Zeige-und-Klick-Vorrichtung zur Aufnahme (oder Wiederaufnahme) der Kommunikation einschließt. Ein Server-Gerät umfasst ein Modul, das einen Dienst unterstützt, der jeder Service sein kann, der sich von einer Bedienschnittstelle, die von einem Client-Gerät bereitgestellt wird, unterscheidet. die Beziehung zwischen dem Servergerät und dem Client-Gerät ist daher eine Beziehung des Bedienens, bei der das Servergerät einen Dienst bereitstellt, das Client-Gerät jedoch die Daten verwenden kann, wie beispielsweise ein DTV, der Videodaten anzeigt, aber die Daten nicht manipulieren oder verändern muss. Mit dieser Definition stimmt daher die Beobachtung überein, dass ein Server oft einen Bezug für Informationen sein kann und ein Client (zum Beispiel ein Browser) ein Verbraucher der Informationen sein kann.
Beispiele für spezielle Funktionen, die von Servergeräten realisiert werden können, schließen ein: die Wiedergabe von Informationen (Daten); das Ausführen einer Funktion (z.B. einer mechanischen Funktion) und die Meldung des Status; die Rücksendung eines Datenstroms und die Meldung des Status; der Empfang eines Datenstroms und die Meldung des Status; oder das Abspeichern eines Zustands für spätere Aktionen. Beispiele für Servergeräte schließen Server zum Beziehen, Herunterrechnen und Anzeigen von MPEGs ein. Während ein Servergerät üblicherweise ein angepasstes, installiertes Bedienprogramm zum Ausführen der Bedienung seiner eigenen Hardware einschließt, bewirkt ein Client die Interaktion mit dem Servergerät. Ein Servergerät wie es hierin verwendet wird, impliziert jedoch nicht, dass ein Web-Server und ein Protokollstapel verwendet werden müssen.
2 zeigt ein Blockdiagramm einer Ausführungsform eines Netzwerks 100 gemäß einem Aspekt der vorliegenden Erfindung. Ein serieller 1394-Bus 114, der oben beschrieben wurde, verbindet elektronisch mehrere Geräte 11, die Servergeräte 14 (z.B. DVD 108, DVCR 110), Client-Geräte 12 (z.B. DTV 102, 103), eine Bridge 116, einen DVCR 120, einen PC 105, einen Kabel/Modem-Zugriff 107 und einen DBS-Zugriff 109 einschließen, in dem Netzwerk. 3 veranschaulicht ein Beispiel für ein Modell einer geschichteten Schnittstelle, die zur Kommunikation zwischen den Geräten 11 gemäß der vorliegenden Erfindung verwendet werden kann. In diesem Beispiel kommuniziert ein Gerät (Server) 150 mit einem Client-Gerät 166, wobei eine oder mehrere Kommunikationsschichten des Netzwerks 152–164 verwendet werden. In einem Beispiel kommuniziert eine Anwendung in dem Gerät 150 mit einer Anwendung in dem Gerät 165 über die Vermittlungsschicht 160. Die Einzelheiten der unteren Schichten 162 und 164 werden von den Anwendungen nicht wahrgenommen, wodurch die Verwendung von z.B. entweder 1394 oder Ethernet keinen Unterschied für die Anwendungen in den Geräten 150, 166 ausmacht. Zudem werden nicht alle oberen Schichten des 7-schichtigen Modells die ganze Zeit über verwendet (z.B. werden in dem Web-Modell (TCP/IP-Modell) die Verbindungsschicht 156 und die Darstellungsschicht 154 nicht verwendet). Durch Verwenden des Internet Protocol-Standards für die Vermittlungsschicht 160 können die Geräte daher miteinander kommunizieren, ohne dass bestimmte Einzelheiten über die anderen Kommunikationsschichten (d.h. die Anwendungsschicht 152, die Darstellungsschicht 154, die Sitzungsschicht 156, die Transportschicht 158, die Sicherungsschicht 162 und die Bitübertragungsschicht 164) bekannt sein müssen. Durch Verwenden des Internet Protocol-Standards für die Vermittlungsschicht 160 kann das Netzwerk daher eine Kommunikation verschiedener Kommunikationsschichten zum Herstellen einer Verbindung zwischen verschiedenen Geräten verwenden.
Eine einzige physikalische Einheit kann mehrere Geräte umfassen, die logisch über eine Vermittlungsschicht, wie sie zum Beispiel in 3 gezeigt ist, und nicht notwendigerweise über ein physikalisches Netzwerk miteinander vernetzt sind (z.B. können solche Geräte einen VCR und ein TV in einem einzigen Gehäuse enthalten). Wenn ein logisches Gerät auf eine GUI zugreift, um einem Benutzer die Steuerung eines Geräts zu ermöglichen, können das Gerät und das logische Gerät in der gleichen physikalischen Einheit enthalten sein. In einer solchen Ausführungsform ruft das physikalische Gerät eine GUI aus sich selbst ab. In anderen Auführungsformen verbindet das Netzwerk jedoch separate physikalische Geräte miteinander, wobei zum Beispiel ein erstes Gerät eine GUI aus einem zweiten Gerät abruft, um die Interaktion eines Benutzers mit der GUI zum Steuern des zweiten Geräts zuzulassen.
In einer derzeit bevorzugten Ausführungsform wird ein serieller 1394-Bus als Bitübertragungsschicht 164 für die Datenverbindungen in dem Netzwerk 100 verwendet.
Aufgrund seiner Fähigkeiten einer erhöhten Bandbreite (z.B. eine verstärkte und garantierte Bandbreite und die Fähigkeit eines isochronen Datenstroms) kann der serielle 1394-Bus ein einziges Medium für alle Datenverbindungen in dem Netzwerk 100 bereitstellen (d.h. Audio/Video-Kanäle und Befehle/Steuerung).
Zudem stellt der serielle 1394-Bus ein automatisches Zurücksetzen der Konfiguration bereit, so dass, wenn ein Gerät eingesteckt/entfernt wird, alle 1394-Schnittstellen zurückgesetzt werden, der 1394-Bus neu konfiguriert wird und jedes Gerät das Vorhandensein jedes anderen Geräts (einschließlich eines neu hinzugefügten Geräts oder ohne das Gerät, das gerade entfernt wurde) kennt. Die 1394-Schnittstelle unterstützt auch einen Datenraum für Informationen über die Konfiguration, die von jedem Gerät aufrufbar sind, wodurch anderen Geräten das Lesen/Schreiben von Informationen und Vornehmen von Änderungen ermöglicht wird, um z.B. den Ablauf des Protokolls der Vermittlungsschicht zuzulassen. Es ist jedoch möglich, diese Ergebnisse mit verschiedener Software und verschiedenen Standards zu erreichen. Das Netzwerk 100 ist daher nicht auf die Verwendung eines seriellen 1394-Busses beschränkt und in alternativen Ausführungsformen der vorliegenden Erfindung können andere Bus-Typen, wie beispielsweise eine Ethernet-, eine ATM-, eine drahtlose Verbindung usw. als physikalische Schicht verwendet werden, wenn sie die speziellen Anforderungen an den Durchsatz eines individuellen Netzwerks (z.B. eines Hausnnetzwerks) erfüllen. Des Weiteren kann eine modifizierte Version von z.B. drahtloser Ethernetverbindung die wesentlichen Merkmale der 1394-Verbindung einschließen.
Wie in 2 abgebildet ist, umfasst das Netzwerk 100 mehrere Geräte, die mit dem seriellen 1394-Bus 114 verbunden sind. In diesem Beispiel schließen die Geräte einen DBSS 104 zum Empfangen eines von einem Satelliten 122 gesendeten Signals zum späteren Anzeigen ein. Mit dem DBSS ist eine Netzwerk-Schnittstelleneinheit (network interface unit, "NIU") assoziiert, die unter anderem eine Schnittstelle zwischen der DBSS-Satellitenübertragung und dem seriellen 1394-Bus 114 bereitstellt.
Eine digitale Videovorrichtung (digital video device, DVD) 108 ist ebenfalls mit dem beispielhaften Netzwerk 100 verbunden. Die DVD 108 kann zum Anzeigen digital codierter Videos auf einem Fernseher verwendet werden. Mit dem beispielhaften Netzwerk 100 ist ebenso ein digitaler Videokassettenrekorder (DVCR) 110, d.h. ein digitales Fernsehen 102, verbunden. In diesem Beispiel stellt der DTV 102 durch Verwenden einer Browsertechnologie eine Benutzeroberfläche bereit, um den Benutzern das Steuern von und Erteilen von Befehlen an die Geräte im Hausnetzwerk 100 zu ermöglichen. Ein zweites DTV 103 stellt eine weitere Benutzeroberfläche für das Netzwerk 100 bereit, wobei eine Browsertechnologie verwendet wird, um den Benutzern das Steuern von und Erteilen von Befehlen an die Geräte im Hausnetzwerk 100 zu ermöglichen. Die DTVs 102 und 103 können Benutzeroberflächen für das Netzwerk 100 bereitstellen, da jeder DTV einen Bildschirm zum Anzeigen der HTML-Seiten umfasst. Andere Geräte, die Fähigkeiten zum Anzeigen besitzen, können jedoch dazu verwendet werden, Benutzeroberflächen bereitzustellen. In bestimmen Ausführungsformen der Erfindung wird daher ein Gerät, wie beispielsweise der Personal-Computer 105 (PC) dazu verwendet, eine Benutzeroberfläche für ein entsprechendes Hausnetzwerk bereitzustellen, da ein PC 105 üblicherweise mit einer Anzeigevorrichtung in Form eines Bildschirms ausgestattet ist.
Der serielle 1394-Bus ist dargestellt, während das HTTP/IP-Schnittstellen-Protokoll, und vorzugsweise HTTP/TCP/IP verwendet wird, wobei IP das Paketformat (ein einseitiges Nur-Schreib-Modell) bereitstellt, TCP eine fehlerfreie Version von IP bereitstellt (z.B. das Ankommen der Pakete und die richtige Reihenfolge sicherstellt) und HTTP eine zweiseitige Verbindung (das Paket an den Server wird eine Antwort erwarten – ein "Lese"-Modell ("Read"-Modell)) bereitstellt. Bestimmte Geräte können andere Arten der Protokolle an den Schnittstellen erfordern (z.B. UPD/IP, FTP/IP, TELNET/IP, SNMP/IP, DNS/IP, SMTP/IP). In bestimmten Ausführungsformen der Erfindung kann ein Proxy 116 zum Bilden der Schnittstelle zwischen zwei Netzwerken verwendet werden, wobei verschiedene Schnittstellenprotokolle auf ihren entsprechenden Medien benutzt werden, die, wenn sie miteinander verbunden werden, das Netzwerk 100 umfassen. Der Proxy 116 (z.B. der Web-Proxy) kann Haustechnik-(Home Automation-)Protokolle, wie beispielsweise den HTML/HTTP/TCP/IP-Proxy für X10, Lonworks, CEBus (auf ihren entsprechenden, physikalischen Technologien) oder Nicht-IP-Protokolle auf dem 1394 (z.B. AVC/FCP/1394) umfassen.
In bestimmten Ausführungsformen weisen die beiden Netzwerkmedien den gleichen Typ auf. Wie in 2 gezeigt ist, ist der serielle 1394-Bus 114 zum Beispiel unter Verwenden des HTTP/IP-Schnittstellenprotokolls über einen Proxy 116 mit dem Nulleiter ("Neutral") der Haustechnik 118 (z.B. X10) verbunden. Durch Verwenden des Proxy 116 als HTML/HTTP/TCP/IP/1394-Proxy für VCR-Befehle/AVC/FCP/1394 zum Bilden einer Schnittstelle zwischen HTML/HTTP/TCP/IP- und X10-Protokollen kann auf den DVCR 120 auch auf dem Netzwerk 100 zugegriffen werden. In bestimmten anderen Ausführungsformen kann ein Netzwerk zwei Netzwerkmedien verschiedenen Typs, z.B. einen seriellen 1394-Bus und ein Ethernet, umfassen. In bestimmen Ausführungsformen der Erfindung wird ein Proxy daher zum Bilden eines Schnittstelle zwischen zwei verschiedenen Medientypen zum Aufbauen eines einzigen Netzwerks verwendet. Ein Prozess des Erkennens, der weiter unten beschrieben ist, kann für das Entdecken (Erkennung) von Geräten, die mit Strom versorgt werden und mit dem Netzwerk 100 verbunden werden, verwendet werden. Der gleiche 1394-Bus kann auch ohne das Erfordernis einer Bridging-Vorrichtung verwendet werden.
Wie in 2 dargestellt ist, stellen die Geräte 11, einschließlich des DTV 102, des DTV 103, des PC 105, des DVCR 110, der DVD 108, der DSS-NIU 104 und des DVCR 120, Geräte dar, die gerade mit dem Netzwerk 100, das ein 1394-Netzwerk umfasst, verbunden sind. Zwischen den angebundenen Geräten liegt eine Client-Server-Beziehung vor, wobei der DTV 102, der DTV 103 und der PC 105 sich in der Regel als Clients verhalten und sich die Geräte DVCR 110, DVD 108, DSS-NIU 104 und DVCR 120 als Server verhalten.
Ein typisches 1394-Netzwerk umfasst miteinander verbundene Geräte, wie beispielsweise eine Sammlung von Anwendungen, die Servergeräte, die einen oder mehrere Dienste anbieten, die gesteuert werden müssen, (z.B. DVCR 100 als ein Dienst zum Aufzeichnen und Abspielen von MPEG-Videos), und Client-Geräte, die einen Dienst in Form einer Benutzerschnittstelle (user Interface) (z.B. DTV 102) zum Steuern der Servergeräte anbieten, einschließen. Einige Anwendungen (z.B. DTV 103) können beide Dienste (z.B. die Fähigkeit zum Decodieren und Anzeigen von MPEGs), die gesteuert werden sollen, und die Fähigkeit einer Steuervorrichtung in Form einer UI aufweisen. Gemäß einem Aspekt der vorliegenden Erfindung werden Verfahren und Systeme, einschließlich Protokollen, Dokumentenbeschreibung, Bildkompression und Standards für die Skriptsprachen aus Technologien, die in dem Standard des World Wide Web (Web-Modell) verwendet werden, zum Aufbauen eines Bedienmodells t a 1394-WEB-Benutzer-zu-Gerät in dem Netzwerk 100 verwendet. Das WEB-Modell ist ein Client/Server-Modell. Das gesteuerte Servergerät (der Dienst) umfasst einen Web-Server und das Client-Gerät als Steuervorrichtung (d.h. ein Gerät, das in der Lage ist, eine UI anzuzeigen) umfasst einen Web-Client, einschließlich einer Vorrichtung zur Darstellung der GUI, die weiter unten beschrieben ist, wie beispielsweise einen Web-Browser (z.B. Explorer^TM, Netscape^TM, usw.).
4A zeigt ein Servergerät, wie beispielsweise den DVCR 110, der ein MPEG-Video zu einem Client-Gerät, wie beispielsweise dem DTV 102, in einem Netzwerk 100 gemäß der vorliegenden Erfindung wiedergibt, wobei der DTV 102 eine Benutzerschnittstelle anzeigen kann. Der DVCR 110 enthält die Hardware und Software des Web-Servers und der DTV 102 enthält die Software des Web-Browsers. Ein Benutzer kann den DTV 102 dazu verwenden, den DTV 102 dazu aufzufordern, auf Basis der in dem DVCR 110 enthaltenen Geräteinformationen 202 oder auf Basis der in dem DTV 102 enthaltenen Geräteinformationen 202 eine Benutzerschnittstelle anzuzeigen. Zum Beispiel kann der Benutzer einen Browser 200 in dem DTV 102 dazu verwenden, eine auf HTML basierende Bedienseite als GUI 202, die in dem DVCR 110 enthalten ist, oder eine auf HTML basierende Bedienseite als GUI 204, die in dem DTV 102 enthalten ist, anzuzeigen. Jede Seite 202, 204 enthält in HTML geschriebene Informationen über die Beschreibung der graphischen Benutzerschnittstelle, wobei der Browser 200 die Informationen ausliest, um eine graphische Benutzerschnittstelle zu generieren. Jede Seite 202, 204 stellt die Bedienschnittstelle (Control Interface) für die Anwendungen 206 bzw. 212 dar. Jede Seite 202, 204 kann eine Hierarchie der Seiten zum Darstellen der Bedienschnittstelle der einer entsprechenden Anwendung umfasse.
Jede GUI 202 und/oder 204 schließt aktive Steuersymbole und/oder Knöpfe für den Benutzer zum Auswählen und Steuern der gerade mit dem Netzwerk 100 verbundenen Geräte ein. Wenn der Benutzer zum Beispiel einen PLAY-(Abspiel-)Knopf in der GUI 202 des DVCR 110, der von dem Browser 200 auf dem DTV 102 angezeigt wird, auswählt, wird eine Hyperlink-Nachricht zu dem Web-Server des DVCR 110 zurückgesendet und eine Anwendungssoftware 206 (z.B. ein MPEG-Aufnahme-/Abspeil-Dienst der Anwendungssoftware) in dem DVCR 110 angesteuert, um eine DVCR-Hardware 208 zu betreiben. In einem Beispiel sendet ein Bezug für einen MPEG-Videokanal 208 in dem DVCR 110 unter der Steuerung einer Bediensoftware für die Anwendung 212 in dem DTV 102 einen MPEG-Videokanal zu einem System zum Decodieren und Anzeigen des MPEG-Videos. Die Anwendungssoftware 206 in dem DVCR 110 sendet auch Informationen zu der Anwendungssoftware 212 in dem DTV 102, die z.B. eine Bestätigung, wenn der Prozess erfolgreich war, einschließen, oder eine geänderte oder andere Bedien-GUI 202 zu dem DTV 102, die dem Benutzer den Status anzeigen, zurück. Es kann eine weitere Kommunikation zwischen den Anwendungssoftwares 206 und 212, z.B. zum Einstellen einer isochronen 1394-Verbindung für einen isochronen Videokanal für den Videokanaldienst stattfinden.
4B zeigt ein weiteres beispielhaftes Architekturschema für ein Servergerät, das mit einem Client-Gerät kommuniziert, das in der Lage ist, eine Benutzerschnittstelle anzuzeigen, in einem Netzwerk 100. Das Servergerät, wie beispielsweise ein DCVR 110 spielt das MPEG-Video auf dem Client-Gerät, wie beispielsweise dem DTV 102, in dem Netzwerk 100 ab, wobei der DTV 102 eine Benutzerschnittstelle anzeigen kann.
In einer Ausführungsform der Erfindung basiert das Protokoll der Kommunikation zwischen den Geräten in dem Netzwerk 100 auf dem Hypertext Transfer Protocol (Hypertext-Übertragungsprotokol, HTTP 1.1), einem Protokoll auf der Anwendungsebene für verteilte, zusammenarbeitende Hypermedia-Informationssysteme. HTTP ist ein allgemeines, zustandsloses, objektorientiertes Protokoll, das für viele Aufgaben verwendet werden kann. Eine Eigenschaft von HTTP ist die Typisierung und Übertragung der Datendarstellung, die Geräten erlaubt, diese unabhängig von den über das Netzwerk 100, mit dem die Geräte verbunden sind, übertragenen Daten aufzubauen.
Die Sprache des Beschreibungsdokuments zum Definieren verschiedener GUIs 202, 204 kann z.B. HTML, Version 4.0, die Veröffentlichungssprache für das World Wide Web sein. HTML unterstützt Text-, Multimedia- und Hyperlink-Merkmale, Skriptsprachen und Formatvorlagen. HTML 4.0 ist eine SGML-Anwendung, die dem Internationalen Standard ISO 8879 – Normierte Verallgemeinerte Auszeichnungssprache (Standard Generalized Markup Language, SGML) entspricht.

Um Bilder anzuzeigen werden drei Kompressionsformate für die graphische Darstellung von Standbildern, die von der HTML-Beschreibung spezifiziert werden, in dem 1394WEB-Netzwerk 100 für ICON, LOGO und andere graphische Darstellungen verwendet. Die Kompressionsformate für die graphische Darstellung von Standbildern sind: das Graphikaustausch-Format (Graphics Interchange Format, GIF89s), der Standard der Progressive Joint Photographic Experts Group (JPEG) und portierbare Netzwerkgraphiken (Portable Network Graphics, PHG). Tabelle 1 zeigt die unterschiedlichen Fähigkeiten der drei Kompressionsformate für die graphische Darstellung von Standbildern. <Tabelle 1: Kompressionsformate für Standbilder>

	PNG	Progressives JPEG	GIF89a
Farbtiefe	48 bit	24 bit	8 bit
unterstützte Farben		16,7 Millionen	256
unterstützte Formate	Raster, Vektor	Raster	Raster
Kompressionsschema	LZ77-Derivat	JPEG	LZW
Transparenz	Pro Pixel für Graustufen und RGB, Pro Farbe für indizierte Farben, 256 Stufen	Nein	Einzelfarbe, 2 Stufen (binär)
progressive Anzeige	ja	ja	ja
skalierbar	nein	nein	nein
Animation		nein	ja
verlustfreie Kompression	100 %
Echtfarben (Truecolor)	48 bit
Graustufen	16 bit
indizierte Farben	ja
Gamma-Korrektur (Lichtintensität)	ja
Farbwertkorrektur	beide
durchsuchbare Meta-Daten	ja
Erweiterbarkeit	ja, in einem Stück codiert

Des Weiteren wird die Web-Skript-Sprache, ECMA-Script-262, dazu verwendet, ein Mittel zum visuellen Verstärken der Web-Seiten der GUI 202 als Teil einer webbasierten Client-Server-Architektur bereitzustellen. Die Skriptsprache ist eine Programmiersprache zum Manipulieren, Anpassen und Automatisieren der Möglichkeiten/Dienste der Geräte.
Die Benutzerschnittstelle 200 stellt grundlegende Funktionen für die Interaktionen des Benutzers bereit und die Skriptsprache wird dazu verwendet, diese Funktionalität der Steuerung durch ein Programm auszusetzen. Das bestehende System stellt die Host-Umgebung für Objekte und Möglichkeiten, die die Fähigkeiten der Skriptsprache vervollständigen, bereit. Der Webbrowser 200 stellt die Host-Umgebung für das ECMA-Skript für Berechnungen seitens des Clients, die zum Beispiel Objekte, die Fenster, Menüs, Pop-ups, Dialogkästchen, Textfelder, Anker, Rahmen, Ereignisse, Cookies und Eingabe/Ausgabe darstellen, einschließen, bereit.
Der Webbrowser 200 stellt die Host-Umgebung für das ECMA-Skript-262 bereit und die Host-Umgebung unterstützt das Verknüpfen des Skriptcodes mit Ereignissen, wie beispielsweise einer Änderung der Bildschärfe, dem Laden und Schließen sowie Fehlern und Abbruch und der Auswahl von Seiten und Bilden, dem Einreichen von Formularen und Mausaktionen. Der Skriptcode ist in den HTML-Seiten 202 und 204 enthalten und die angezeigte Seite in dem Browser 200 schließt eine Kombination aus Elementen der Benutzerschnittstelle und feste und berechnete Texte und Bilder ein. Der Skriptcode antwortet auf die Interaktionen des Benutzers, ohne dabei ein Hauptprgramm zu erfordern.
In einem Beispiel schließt die Beschreibung für einen 1394WEB-Client-Browser 200 eine HTTP1.1-Beschreibung ein, in der der Abschnitt '8.1.2.1 Übertragung' der HTTP1.1-Beschreibung bezüglich des Fortdauerns der Verbindung so modifiziert ist, dass ein HTTP1.1-Client-Gerät, wie z.B. der DTV 102, erwartet, dass eine Verbindung zu einem Servergerät, wie z.B. dem DVCR 110, über den 1394 offen bleibt, da die fortbestehende Verbindung in der Benutzersteuerung des 1394WEB ein vollständiges Melden des Status von dem Servergerät (DVCR 110) zulässt, während die GUI 202 und/oder 204 in dem Browser 200 des Client-Geräts (DTV 102) sichtbar bleiben. Die HTTP-Verbindung bleibt offen (HTTP spec RFC 2068), wobei ein Client, der fortdauernde Verbindungen unterstützt, die Anfragen über "eine Leitung leiten kann" (d.h. mehrere Anfragen, ohne auf eine Antwort zu warten, senden kann). Ein Server muss seine Antworten auf diese Anfragen in der gleichen Reihenfolge senden, in der die Anfragen empfangen wurden. Dies ermöglicht dem Webbrowser 200, die Anfragen an den DVCR 110 über eine Leitung zu senden, die der DVCR 110 dann später mit z.B. Antworten über den Status wie "Jetzt Abspielen", "Jetzt Aufnehmen", "Zurückspulen beendet", "Band defekt" usw. abgelten kann. Andere beispielhafte Umsetzungen umfassen z.B.: die Bedienseite aus dem DVCR 110 kann eine Anfrage enthalten, die in der Anforderung des DVCR 100 der Beschreibung der GUI 202 in einer Schleife ausgeführt werden soll.
Die Presentation Engine (Präsentationsvorrichtung) der GUI 200 wird in dem Client-Gerät, wie beispielsweise dem DTV 102, dazu verwendet, die in der Sprache der Dokumentenbeschreibung HTML4.0 geschriebenen Beschreibungen der GUI 202, 204 und die assoziierten Beschreibungen (unten) zu interpretieren und die graphische Gestaltung der Anzeige für den Benutzer zu erzeugen. Die Presentation Engine der GUI 200 schließt z.B. die folgenden Merkmale ein: 1) eine minimale Standardgröße für das Fenster (die GUI) von z.B. H0 × 640 Pixeln (480 × 640, davon 480 senkrecht, 640 waagrecht). Diese Standardgröße soll das angestrebte Erscheinungsbild in den GUIs 202, 204 sicherstellen und wird zu dem Benutzer in dem Browser gesendet. Die gesendeten GUIs 202, 204 werden in einem Fenster mit 480 × 640 Pixeln angezeigt oder mit dem gleichen Seitenverhältnis vergrößert, soweit es von dem Benutzer nicht anders angeordnet wird; 2) Kompressionsformate für Standbilder, z.B. GIF89a, JPEG und PNG; 3) Formate und Schriftarten für Formatvorlagen, z.B. CSS1 und CSS2; 4) Schriftarten (Fonts), wie z.B. die folgenden: installierte Schriftarten sind bei dem Client-Gerät erforderlich, um einfache Server-Einrichtungen davon zu befreien, solche Schriftarten unterstützen zu müssen. Es kann mindestens eine Schriftart von jeder allgemeinen lateinischen Familie ausgewählt werden: z.B. Times New Roman aus der 'serif'-Familie; Helvetica aus der 'sans-serif'-Familie; Zapf-Chancery aus der 'cursive'-Familie; Western aus der 'fantasy'-Familie; und Courier aus der 'monospace'-Familie. Es können auch andere Schriftarten verwendet werden; und 5) Skriptsprachen, z.B. ECMA-262. Beispiele für die Presentation Engine der GUI 200 schließen Webbrowser, wie beispielsweise Explorer^TM und Netscape^TM, die wie gewünscht konfiguriert/angepasst sind, ein.
Eines oder mehrere der Servergeräte (z.B. ein 1394WEB-Netzwerk, ein Webserver mit kontrollierter Anwendung, wie beispielsweise der DVCR 110) schließen die folgenden sechs aufgezählten Komponenten ein:

1) das Webserver-Protokoll HTTP1.1, mit dem Abschnitt '8.1.2.1 Übertragung' der Beschreibung des HTTP1.1, das die modifizierte Verbindung betrachtet, so dass ein HTTP1.1-Servergerät (z.B. der DVCR 110) annimmt, das ein HTTP1.1-Client-Gerät das Aufrechterhalten einer fortdauernden Verbindung mit dem Servergerät anstrebt. Die fortdauernde Verbindung in dem 1394WEB-Netzwerk 100 lässt das vollständige Melden eines Status von z.B. dem Servergerät DVCR 110 an das Client-Gerät DTV 102 zu, während die GUI 202 des DVCR 110 in dem Browser 200 des DTV 102 sichtbar bleibt. Des Weiteren kann unter Verwenden eines bedingten GET des HTTP ein Verfahren zum Erhalten des letzen Zustands der Servergeräte verwendet werden. Wann immer der Benutzer zu dem Datenverzeichnis des Hausnetzwerks zurückkehrt oder eine Aktualisierung desselben vornimmt, stellt der Browser 200 die Seite wieder in ihrer Gesamtheit dar. Dies ist notwendig, da die dem Datenverzeichnis des Hausnetzwerks zugrunde liegende HTML neu erstellt worden sein kann, wenn ein Gerät an das Netzwerk 100 angefügt oder aus diesem entfernt wurde. Es ist auch möglich, die Symbole für die Geräte zu aktualisieren um Änderungen des Betriebszustands der Geräte wiederzugeben. Browser, die durch EIA-775.1-Geräte umgesetzt werden, verwenden daher die Anfragen "bedingtes GET" des HTTP, um zu bestimmen, ob aktuelle Abbildungen der Web-Seiten oder -Graphiken von dem Server abgerufen werden sollten oder nicht.
2) Die Beschreibungen der Homepage-GUI der Geräte 202, 204, die z.B. in HTML4.0 beschrieben sind, schließen Dateien, z.B. icon.htm, logo.htm, index.htm, gif-Dateien usw. ein. Die Datei index.htm wird auf HTML-Verbindungen bezogen, die in den HTML-Dateien icon.htm und anme.htm des Geräts enthalten sind, wobei index.htm gegebenenfalls z.B. AINDEX.HTML@ oder AINDEX.HTM@ genannt werden kann. Eine Datei, die INDEX.HTM genannt wird, ist als Standardname nicht erforderlich, da ICON.HTM und NAME.HTM mit Hyperlinks zu 'INDEX.HTM' versehen werden, weshalb der Name frei wählbar ist. ICON.HTM und LOGO.HTM verweisen auf die aktuellen Graphikdateien in dem gleichen Gerät, z.B. LOGO.GIF und ICON.GIF. Die Geräte (z.B. HTTP-Geräte) in dem Netzwerk 100 können auf die Beschreibungen 202, 204 zugreifen. Um das gewünschte Erscheinungsbild sicherzustellen, kann die Bedien-GUI mit einer Standardgröße für die GUI von z.B. 480 × 640 Pixeln ausgebildet werden. Zum Beispiel kann eine übertragene GUI 202 in einem Fenster mit einer Größe von 480 × 640 Pixeln in dem Browser 200 angezeigt werden oder mit dem gleichen Seitenverhältnis vergrößert werden, soweit es von dem Benutzer nicht anders angeordnet wird.
3) Es werden mindestens zwei Symbol-Dateien (ICON-Dateien) bereitgestellt, um das Gerät auf der Seite eines Netzwerks höchsten Niveaus 220 (5 bis 6) in dem Browser 200, der die Informationen über die mit dem Netzwerk verbundenen Geräte zeigt, darzustellen. Ein Symbol kann einen Graphikdatei-Typ (z.B. GIF, JPG oder PNG) umfassen und ICON.HTM genannt werden. In einem Beispiel verweist ICON.HTM(DVCR) auf die Datei INDEX.HTM in der HTML-Seite 202 und ICON.HTM(CTV) verweist auf die Datei INDEX.HTM in der HTML-Seite 204. Die Verbindung höchsten Niveaus für die Bedienseiten (z.B. INDEX.HTM) des Geräts kann ICON.HTM sein. Der Browser 200 ordnet die darin enthaltenen Symbole und Verbindungen einer Vielzahl von Geräten in dem Netzwerk 100 auf der Seite höchsten Niveaus des HN-Datenverzeichnisses 220 für die Entdeckung (Erkennung) des Dienstes durch den Benutzer an. Dann klickt der Benutzer das auf der Seite 220 angezeigte Symbol an und die Seite des Geräts (z.B. INDEX.HTM auf der Seite 202) wird geholt. Das in einer Standardeinstellung angezeigte HN-Datenverzeichnis ist die Seite höchsten Niveaus der Erkennung. Es kann auch eine Reihe weiterer und unterschiedlicher, graphischer Symbole verwendet werden, um zum Beispiel den Status des Geräts, die von dem Benutzer eingestellte Präferenz oder die Formate des Herstellers, die gegen die graphische Darstellung des Symbols ausgetauscht werden können, darzustellen. In einem Prozess des Erkennens, der weiter unten beschrieben ist, werden Symbole aus den mit dem Netzwerk 100 verbundenen Geräten gesammelt und auf der Seite höchsten Niveaus der Netzwerkgeräte 220 für die Auswahl durch einen Benutzer angezeigt. Eine beispielhafte Beschreibung eines Gerätesymbols umfasst: den Dateinamen ICON.HTM, auf den der HTTP-Server zugreifen kann (die Dateinamen sind in einem Datenverzeichnis, Datenraum, vorhanden, auf den der Webserver zugreifen kann, so dass sie abgerufen werden können und über das Netzwerk an den Browser gesendet werden können); einen Graphikdatei-Typ, wie beispielsweise GIF, JPG oder PNG; und die graphische Darstellung des Symbols mit einer maximalen Größe von 70(V) × 130(H) Pixeln.
4) Es werden mindestens zwei LOGO-Dateien des Geräts bereitgestellt, um das Gerät auf der Seite höchsten Niveaus der Geräte des Netzwerks darzustellen. LOGO kann einen Graphikdatei-Typ (z.B. GIF, JPG oder PNG) umfassen und LOGO.HTM genannt werden. In einem Beispiel verweist LOGO.HTM(DVCR) auf die INDEX.HTM auf der HTML-Seite 202 und LOGO.HTM(DTV) verweist auf die INDEX.HTM auf der HTML-Seite 204. In einer Version kann die Verbindung höchsten Niveaus für die Bedienseiten (z.B. INDEX.HTM) des Geräts LOGO.HTM sein. Alle Logos der Geräte werden auf der Seite höchsten Niveaus des HN-Datenverzeichnisses 220 für eine Erkennung des Dienstes durch den Benutzer angeordnet. Dann klickt der Benutzer das LOGO, das auf der Seite 220 angezeigt wird, an und die Seite des Geräts (z.B. 220) wird geholt. Es kann auch eine Reihe weiterer und unterschiedlicher, graphischer Symbole für die Dienste des Herstellers durch das graphische Format des Logos ersetzt werden. Entsprechend dem Prozess des Erkennens werden die LOGOs von den Geräten, die mit dem Netzwerk 100 verbunden sind, gesammelt und auf der Seite höchsten Niveaus der Netzwerkgeräte 220 für die Auswahl durch einen Benutzer angezeigt. Eine beispielhafte Beschreibung des LOGOs eines Geräts umfasst: den Dateinamen LOGO.HTM, auf den der HTTP-Server zugreifen kann; einen Graphikdatei-Typ, wie beispielsweise GIF, JPG oder PNG; und die maximale Größe für die graphische Darstellung des Logos von ungefähr 70(V) × 130(H) Pixeln.
5) Es wird mindestens ein NAME des Geräts bereitgestellt, um das Gerät auf der Seite höchsten Niveaus der Geräte des Netzwerks darzustellen. Der NAME umfasst den TEXT in einer HTML-Datei NAME.HTM. Dieser Text kann auch auf Bedienseiten (z.B. 202) verweisen. Dies ist eine Verbindung höchsten Niveaus auf der Seite der Erkennung zu der Bedienschnittstelle des Geräts. Der Text stellt eine Möglichkeit bereit, zwischen identischen Geräten zu unterscheiden, wodurch z.B. zwei identische DTVs durch Hinzufügen des Texts des NAMENS 'Fernseher im Schlafzimmer' und 'Fernseher im Wohnzimmer' unterschieden werden können. Der Text kann ein paar Worte umfassen, den Gerätetyp, z.B. DVCR oder DTV eindeutig darzustellen. Entsprechend dem Prozess des Erkennens wird zusammen mit den entsprechenden Symbolen/LOGOs auf die NAMEN der mit dem Netzwerk verbundenen Geräte zugegriffen und diese auf der Seite höchsten Niveaus der Netzwerkgeräte 220 in Form des Symbols/LOGOs angezeigt. Eine beispielhafte Beschreibung des NAMENS umfasst: den Dateinamen NAME.HTM, auf den der HTTP-Server zugreifen kann; beispielsweise einen nicht genau beschriebenen Text in Schriftgröße 10, wobei zwei Linien des Texts unter dem entsprechenden Symbol/LOGO angezeigt werden können. Die Raumgröße für den Text der NAME.HTM kann daher zum Beispiel 20 senkrecht mal 130 waagrecht sein, um dem Symbol/LOGO (70 senkrecht × 130 waagrecht) zu entsprechen. Wie in den 5 bis 6 gezeigt ist, kann das Format der UI höchsten Niveaus 220 eine Matrix aus Symbolen umfassen, die die Funktionen der miteinander verbundenen Geräte für den Benutzer darstellen. Der Name, der das Gerät (aus dem name.htm) angibt, wird unter dem Symbol (aus dem icon.htm) von dem gleichen Gerät angeordnet. Das Logo (aus dem logo.htm) kann z.B. auf irgendeiner freien Position für das Symbol angeordnet werden. Da die Beschreibung höchsten Niveaus 250 (die weiter unten in Verbindung mit den 9A–C beschrieben ist) unabhängig von UI-fähigen Geräten generiert wird, muss die genaue Gestaltung nicht vorgeordnet werden. Die maximalen Größen für das Symbol, das Logo und den Namen können vorgeordnet werden, um die Gestaltung der GUI-Matrix zu erleichtern.
6) Eine Zusammenfassung der Informationen über das Gerät in einem Dokument der Beschreibung der Homepage, die in HTML4.0 geschrieben ist, kann bereitgestellt werden, z.B. "info.html" oder "info.htm" genannt werden und für den Prozess des Erkennens für den HTTP-Server zugänglich gemacht werden. Es kann eine Verbindung zu den Informationen INFO.HTM über die Bedienseiten, z.B. 202, 204, bereitgestellt werden. Die Homepage mit der Zusammenfassung der Informationen über die Geräte stellt dem Benutzer eine Zusammenfassung des Geräts statt der ausführlichen Bedienschnittstelle, die in der Homepage des Geräts angezeigt wird, bereit. Tabelle 2 zeigt den Text der Eigenschaften der Geräte, die eingeschlossen sind und anderen, die nicht eingeschlossen sind. Diese Tabelle kann erweitert werden, um andere Eigenschaften einzuschließen.

Name	Wert
Name des Geräts	Gerätebezeichnung (kann vom Benutzer konfiguriert werden)
Position des Geräts	Position des Geräts im Haus (kann vom Benutzer eingestellt werden)
Symbol des Geräts	Bezeichnung des Symbols des aktuellen Geräts
Gerätetyp	Gerätetyp oder Kategorie (VCR, DSS, TV usw.)
Gerätemodell	Gerätemodell
Name des Herstellers	Name des Geräteherstellers
Logo des Herstellers	Name des Logo-Bilds des Herstellers
URL des Herstellers	URL des Geräteherstellers
Standardeinstellung für den Namen des Bezugs des Datenstroms	Dienst: Bezeichnung des Geräts für den Standardbezug für diesen Dienst des Ziels des Geräts
Standardeinstellung für den Namen des Ziels des Datenstroms	Dienst: Bezeichnung des Geräts für das Standardziel für diesen Dienst des Bezugs des Geräts
Eigenschaften des Bezugs des Datenstroms	Art des Dienstes, den das Gerät liefern kann (Eigenschaften und Fähigkeit)
Eigenschaften des Ziels des Datenstroms	Art des Dienstes, den das Gerät empfangen kann (Eigenschaften und Fähigkeit)

Tabelle 2 beinhaltet eine Zusammenfassung der Informationen über das Gerät, wie beispielsweise den Namen des Herstellers, die Bezeichnung des Logo-Bildes des Herstellers, und kann daneben eine URL des Herstellers für eine Hilfe einschließen, wenn eine Internet-Verbindung zu der Webseite des Herstellers verfügbar ist. Die Tabelle 2 kann ferner eine Gerätebezeichnung und eine Position des Geräts in dem Haus, die von dem Benutzer konfiguriert werden können, enthalten. Es kann mehrere Variationen des Gerätesymbols geben, die die verschiedenen Zustände des Geräts wiedergeben. Das Feld für die Eigenschaften des Gerätesymbols schließt den Namen des aktuellen Symbols ein. Die Seite mit der Zusammenfassung der Informationen über das Gerät kann somit durch Anzeigen des für den aktuellen Zustand repräsentativen Symbols dem Benutzer Informationen über den unmittelbaren Zustand des Geräts bereitstellen.
Jedes Gerät kann einen oder mehrere Dienste, z.B. einen Bezug für einen Videokanal oder ein Ziel für einen Videokanal enthalten. Die Fähigkeit jedes Bezugs weist eine komplementierende Fähigkeit des Standardziels auf und jede Fähigkeit des Ziels weist eine komplementierende Fähigkeit des Standardbezugs auf. Der Eingang des Namens dieses Standardkanals kann z.B. dazu verwendet werden, den am nächsten liegenden DTV als Ziel vorzugeben, wenn ein DVCR als Bezug dafür gesteuert wird, das Erfordernis des Auswählens des DTV zu jedem Zeitpunkt auszuschließen. Ein Hintergrund, der einen Querverweis zwischen dem Standardnamen des Datenstroms und der Adresse auf der 1394 erzeugt, wird bereitgestellt. Die Dienste des Videokanals werden von der 1394-Schnittstelle selbst (und nicht von dem Web-Modell) bereitgestellt. Es besteht daher eine Verbindung des Standardbezugs oder -Herunterrechnens zu dem Adressmechanismus der 1394. Der Benutzer kann auf einen Dienst zugreifen und einen Namen für die Standardeinstellung auswählen, die dann in dem Gerät abgespeichert wird. Der Software-Agent des Geräts muss die 1394-Adresse und die Parameter für die 1394-s/w finden, um bei Bedarf die Standardeinstellung des Kanals zu ermöglichen.
Unter Verwenden der Eigenschaften der Bezugs- und Zieldienste können ein neuer Server/neue Dienste implementiert werden, während die Kompatibilität mit dem bestehenden Hauptcomputer oder dem Gerät (Knoten) und den Diensten aufrechterhalten wird. Wenn ein neues Servergerät, das einen neuen Dienst bereitstellt, entwickelt wird, das mit einem bereits bestehenden Servergerät kompatibel ist, können zum Beispiel sowohl der neue als auch der bereits bestehende Server zu der Liste der Eigenschaften des neuen Knotens hinzugefügt werden, während die Kompatibilität mit den bereits bestehenden Knoten unter Verwenden des bereits bestehenden Servers in dem Netzwerk 100 aufrechterhalten wird. Der Benutzer kann ein für diesen Zweck kompatibles Gerät auswählen. Diese stellen einem Benutzer "ABOUT"-Informationen (Informationen über etwas) bereit, um, wenn eine Kompatibilität gewünscht ist, die Fähigkeiten der bereits bestehenden Ausstattung, z.B. vor dem Kauf einer neuen Ausstattung, zu überprüfen, bereit.
Ein Prozess des Erkennens für jedes Gerät, das den 1394WEB-Standard unterstützt (z.B. Geräte, die in der Lage sind, eine Benutzerschnittstelle anzuzeigen), sammelt Geräteinformationen von den mit dem Netzwerk 100 verbundenen Geräten, um eine Beschreibung der Seite höchsten Niveaus der Benutzersteuerung für das Hausnetzwerk zu generieren, in dem jedes Gerät durch einen Bezug in Form einer graphischen Darstellung eines Symbols und einen Bezug in Form eines in Text verfassten Namens, wie oben ausführlich angegeben wurde, dargestellt wird. Die Beschreibung höchsten Niveaus kann eine Standardseite für eine Presentation Engine, wie beispielsweise den Browser 200, umfassen, bei der der Browser 200 die graphischen Bilder und Namen von den Geräten sammelt, während die graphische Benutzerschnittstelle GUI auf dem höchsten Niveau des Netzwerks 220 in dem Browser angezeigt wird, wie es beispielhaft in den 5 bis 6 gezeigt ist. Die dynamisch erzeugte Seite höchsten Niveaus des HN-Datenverzeichnisses 220 wird zu der Standardseite für den Browser (die erste Seite, die angezeigt wird, wenn der Browser gestartet wird) gemacht.
Unter Bezugnahme auf 4B schließen beispielhafte Schritte der Vorgehensweise ein: 1) der Browser 200 in dem Gerät 102 wird gestartet, 2) der Browser 200 holt und stellt die HTM-Dateien des HN_Datenverzeichnisses (UI höchsten Niveaus) von der Seite 204, 3) der Browser 200 holt incon.htm und names.htm der HTM-Dateien von den Seiten 202, 204 und stellt sie in der UI höchsten Niveaus dar, 4) der Browser 200 holt jegliche Graphikdateien (z.B. GIF) von den Seiten 202, 204 und stellt sie in der UI höchsten Niveaus dar, 5) der Browser 200 ist dann in der Lage, die vollständige Seite des HN-Datenverzeichnisses 220 darzustellen (die Seite 220 wird mit Hyperlinks zu den 'INDEX.HTM'-Dateien für verschiedene, in dem Netzwerk 100 verknüpfte Geräte versehen) und 6) wenn ein Benutzer z.B. das DVCR-Symbol in der GUI 220 zum Steuern des DVCR 110 anklickt, wird ein entsprechender Hyperlink in der Seite höchsten Niveaus 220 zu 'INDEX.HTM' des DVCR 110 dazu verwendet, die 'INDEX.HTM' (höchste Bedienseite des DVCR) von der Seite 202 in dem DVCR 110 abzurufen und dem Benutzer die DVCR-Bedienseite darzustellen (z.B. wird, wenn der Rahmen, der angeklickt wurde (z.B. der Rahmen der icon.htm) nicht groß genug ist, eine graphische Darstellung in einer anderen Kopie des Browsers mit einem Rahmen in vollständiger Größe dargestellt). Der Benutzer kann unter Verwenden der Bedienschnittstelle, die durch die 'INDEX.HTM' des DVCR-Geräts bereitgestellt wird, die von dem Browser 200 in dem DTV 102 dargestellt wird, dann Befehle an den DVCR 110 erteilen und diesen steuern.
Der Name 'INDEX.HTM' ist frei wählbar, da ICON.HTM und NAME.HTM mit Hyperlinks zu der 'INDEX.HTM' versehen werden. INCON.HTM und LOGO.HTM verweisen jedoch auf die aktuellen Graphikdateien (z.B. LOGO.GIF und ICON.GIF) in den gleichen Geräten. In einer Ausführungsform kann LOGO.HTM dann optional sein, wenn ein Logo für ein Gerät optional ist. Die HTML-Datei des HN_Datenverzeichnisses kann eine Standardbezeichnung haben, so dass von einem anderen Gerät darauf zugegriffen werden kann.
Die 5 bis 6 zeigen, dass das Host-Gerät, wie beispielsweise ein Client-Gerät (z.B. DTV 102, HDTV1) oder ein Server-Gerät (z.B. DVCR 110), das die Seite höchsten Niveaus der GUI 220 generiert und präsentiert, eine Priorität annehmen kann und ein größeres Symbol für das Symbol, den Namen, das Logo usw. des Host-Geräts verwenden kann. In einer Version werden nur Geräte mit Servern (die Dienste anbieten) in der GUI 220 angezeigt (ein "Client-Gerät" umfasst ein Gerät mit einer Client-Fähigkeit, wohingegen es, wenn nur als Client fungiert, nicht in der GUI höchsten Niveaus angezeigt wird, da es keinen Dienst anzubieten hat). Der Prozess des Erkennens liest die Informationen aus dem Datenspeicher des Adressbereichs der 1394 (Konfiguration ROM-Struktur), wie er in Paragraph 8 der ISO/IEC 13213 definiert ist, aus. Obwohl es 'ROM' genannt wird, wird vorausgesetzt, dass der Adressbereich überschreibbar ist, um dem Benutzer die Konfiguration und Modifikation der benutzerrelevanten, abgespeicherten Werte zu ermöglichen. Die Inhalte des Konfigurations-ROM und des Prozess des Erkennens werden nachstehend beschrieben.
Die Benennung des Geräts, die Adressierung des Geräts und der Prozess des Erkennens für die Steuerung lokaler Hausnetzwerke von Hausgeräten unter Verwenden der Internet-, Web- und 1394-Technologie können sich von den Anforderungen und Anwendungen des allgemeinen Internet-Bereichs unterscheiden. Gemäß einem Aspekt der vorliegenden Erfindung werden daher für die Steuerung eines Hausnetzwerks oder lokalen Netzwerks von Hausgeräten spezielle Prozesse, die die Geräteerkennung, die Adressierung des Geräts und die Erfordernisse für die Benennung einschließen, verwendet. Das Hausnetzwerk muss zum Beispiel vollständig ohne das Vorhandensein externer Verbindungen und Dienste, ohne einen Netzwerk-Administrator vollständig funktionieren und die Konfiguration muss vollautomatisch eingestellt werden. Die Bedienung durch den Benutzer kann in vielen Fällen vollständig tastaturlos erfolgen. Zudem wird das IEEE1394-Protokoll dazu verwendet, eine komplizierte Schnittstelle bereitzustellen, die Merkmale umfasst, die einfache, effiziente und hervorragende Erkennungs- und Konfigurationsfunktionen bereitstellen.
7 zeigt ein Blockdiagramm eines Netzwerks 300 das gemäß einer weiteren Ausführungsform der vorliegenden Erfindung aufgebaut wurde. Um das Verständnis zu erleichtern wurden, wenn möglich, die gleichen Bezugszeichen verwendet, um gleiche Elemente zu bezeichnen, die allen Figuren hierin gemeinsam sind. Wie in 7 abgebildet ist, verbindet ein serieller 1394-Bus, wie er oben beschrieben ist, mehrere Geräte, einschließlich Server-Geräten 14 (z.B. DVD 108, DVCR 110) und Client-Geräten 12 (z.B. DTV 102), elektronisch in einem Netzwerk 100, wie es oben unter Bezugnahme auf 2 beschrieben wurde, wobei die Geräte unter Verwenden des beispielhaften Modells für eine geschichtete Schnittstelle aus 3, wie sie oben beschrieben wurde, miteinander verbunden sind.
Das Netzwerk 300 ist nicht auf das Verwenden eines seriellen 1394-Busses beschränkt und in alternativen Ausführungsformen der vorliegenden Erfindung können andere Bus-Arten, wie beispielsweise ein Ethernet, drahtloses ATM usw. als physikalische Schicht verwendet werden wenn sie die bestimmten Anforderungen an den Durchsatz eines einzelnen Netzwerks (z.B. eines Hausnetzwerks) erfüllen. Wie in 7 gezeigt ist, umfasst das Netzwerk 300 mehrere mit dem seriellen 1394-Bus 114 verbundene Geräte. In diesem Beispiel schließen die Geräte einen DBSS 104 zum Empfangen eines Übertragungssignals von einem Satelliten 122 für eine spätere Anzeige ein. Mit dem DBSS assoziiert ist eine Netzwerkschnittstelleneinheit ("NIU"), die unter anderem eine Schnittstelle zwischen der Satellitenübertragung des DBSS und dem seriellen 1394-Bus 114 bereitstellt. Ein digitales Videogerät (DVD) 108 wird ebenso mit dem beispielhaften Netzwerk 300 verbunden. Das DVD 108 kann dazu verwendet werden, digital codierte Videos zum Abspielen auf z.B. einem digitalen Fernsehrgerät zu beziehen. Mit dem beispielhaften Netzwerk 100 ist auch ein digitaler Videokassettenrekorder (DVCR) 110, ein digitales Fernsehgerät (DTV) 102 verbunden. In diesem Beispiel stellt der DTV 102 eine Benutzeroberfläche für das Netzwerk 300 bereit, wobei die Browser-Technologie dazu verwendet wird, Benutzern das Steuern von und Erteilen von Befehlen für Geräte über das Hausnetzwerk 300 zu ermöglichen. Ein zweiter DTV 103 stellt eine weitere Benutzeroberfläche für das Netzwerk 100 bereit, wobei die Browser-Technologie dazu verwendet wird, Benutzern das Steuern von und Erteilen von Befehlen für die Geräte über das Hausnetzwerk 100 zu ermöglichen. Die DTVs 102 und 103 können Benutzeroberflächen für das Netzwerk 300 bereitstellen, da jeder DTV einen Bildschirm zum Anzeigen von HTML-Seiten umfasst. Es können jedoch auch andere Geräte, die die Fähigkeit für eine Anzeige besitzen, dazu verwendet werden, Benutzeroberflächen bereitzustellen. In bestimmten Ausführungsformen der Erfindung wird daher ein Gerät, wie beispielsweise ein Personalcomputer 105 (PC) dazu verwendet, eine Benutzeroberfläche für ein entsprechendes Hausnetzwerk bereitzustellen, da ein PC 105 gewöhnlich eine Anzeigeeinheit in Form eines Bildschirms enthält.
Der serielle 1394-Bus 114 ist abgebildet, wobei er das HTTP/IP-Protokoll, und bevorzugt HTTP/TCP/IP, für die Schnittstelle verwendet, wobei IP das Paketformat (ein einseitiges Nur-Schreib-Modell) bereitstellt, TCP eine fehlerfreie Version von IP bereitstellt (z.B. das Ankommen der Pakete und die richtige Reihenfolge sicherstellt) und HTTP eine zweiseitige Verbindung (das Paket an den Server wird eine Antwort erwarten – ein "Lese"-Modell ("Read"-Modell)) bereitstellt. Bestimmte Geräte können Schnittstellen-Typen mit anderen Protokollen (z.B. TCP/IP, UPD/IP, FTP/IP, TELNET/IP, SNMP/IP, DNS/IP, SMTP/IP) erfordern. In bestimmten Ausführungsformen der Erfindung kann ein Proxy 116 dazu verwendet werden, eine Schnittstelle zwischen zwei Netzwerken, die verschiedene Protokolle für die Schnittstelle auf ihren entsprechenden Medien verwenden und die, wenn sie miteinander verbunden sind, das Netzwerk 300 umfassen, zu bilden.
Wie in 7 abgebildet ist, wird zum Beispiel der serielle 1394-Bus 114, der das HTTP/IP-Protokoll für die Schnittstelle verwendet, über einen Proxy 116 mit dem Hausautomatisierungsnetzwerk 118 (z.B. X10) verbunden. Bei Verwenden des Proxys 116 als HTML/HTTP/TCP/IP/1394-Proxy für VCR-Befehle/AVC/FCP/1394 zum Bilden einer Schnittstelle zwischen HTML/HTTP/TCP/IP- und X10-Protokollen kann auf den DVCR 120 in dem Netzwerk 300 auch zugegriffen werden.
In dieser Ausführungsform kann das Netzwerk 300 mit einem externen Netzwerk 119 eines zu dem seriellen 1394-Bus unterschiedlichen Typs (z.B. Ethernet) über einen Bus 121 verbunden werden. Ein Proxy 117 wird dazu verwendet, eine Schnittstelle zwischen den beiden unterschiedlichen Medientypen zu bilden. Für eine Verbindung zwischen dem Adressschema des externen Netzwerks 119 und dem Adressschema des Netzwerks 300 umfasst die Bridge 117 eine Network Address Translation-(NAT, Adressumsetzung in Netzwerken)Grenze. Dieses Technik kann für ein Firmen-LAN verwendet werden und ist ein 'Teile und Herrsche'-Ansatz für das komplexe Problem, die Anforderungen der unterschiedlichen IP-Adressen in verschiedenen Netzwerken zu erfüllen und verhindert ein 'Ausgehen der IPV4'-Adressen. Das externe Netzwerk kann z.B. das Kabel-TV-Netzwerk 115 über Ethernet mit dem Telefon (z.B. ADSL), wodurch eine Breitbandverbindung zu dem Internet und dem WWW bereitgestellt wird, beinhalten. Das Ethernet 119 steht als Bridge-Funktion für das externe Netzwerk bereit. Die Bridge 117 oder das Ethernet 119 können die NAT-Adressumwandlungsfunktion bereitstellen. Wenn das Ethernet eine lokale, private (nur für das Haus) Adressierung bereitstellen soll (wie z.B. durch den IETF-Standard RFC 1918 definiert wird), ist die NAT-Funktion dann in dem Ethernet. Bereits bestehende Kabelmodems werden in dem Ethernet mit einer globalen Adresse und auch der globalen Adresse im Internet für den PC eingerichtet (in diesem Fall ist die NAT in der Bridge 117).
Die oben genannte Benennung des Geräts, die Adressierung des Geräts und die Prozesse des Erkennens für das Netzwerk 300 werden nachstehend beschrieben. Für die Benennung der Geräte benötigt eine per Mausklick angesteuerte Web-Funktion (z.B. unter Verwenden von GUI/Web) keine Namensdienste (DNS, Domain Name Service). Die Web-GUI stellt eine Abstraktionsschicht bereit und die Adressen werden als Hypertext-Verbindungen versteckt, die durch das Klicken des Benutzers zum Aktivieren der GUI-Bereiche (z.B. Knöpfe) aufgerufen werden. Jede Änderung bei den Geräten in dem lokalen Netzwerk 300 bewirkt, dass die Seite höchsten Niveaus der Erkennungs-GUI 200 (5 bis 6), die den Status der Geräte in dem Netzwerk 300 zu dem Zeitpunkt dargestellt, von dem Browser 200 (4A–B) neu erzeugt werden muss und dem Benutzer standardmäßig für eine unmittelbare Nutzung präsentiert werden muss.
Für eine Gerät-zu-Gerät-Steuerung wird ein anderer Nachschlagedienst für mehr als Namen verwendet (z.B. das Nachschlagen eines Dienstes und das Nachschlagen einer Anwendung). Der DNS kann dafür nicht die notwendigen Eigenschaften einer Gerät-zu-Gerät-Steuerung bereitstellen. Ein Gerät (z.B. ein mit einer 1394 verbundener PC) kann jedoch wie gewöhnlich auf einen DNS-Dienst zugreifen. Der DNS ist für die Erkennung oder Funktion der Geräte/Dienste innerhalb des Hauses erforderlich, ein DNS-(Name zu Adresse)-Nachschlagedienst ist jedoch für externe Zugriffe, z.B. von einem PC aus, erforderlich. Wenn ein Name, z.B. "www.yahoo.com", in einen Browser eingegebenen wird, erfolgt ein Nachschlagen der IP-Adresse des Yahoo-Computers, d.h. 216.32.74.52, da das Internet (sogar das Haus-Internet) mit Adressen arbeitet.
Bei einem 775WEB-UI-Gerät, das einen Agenten zum Erzeugen der Beschreibung der GUI höchsten Niveaus des HN-Datenverzeichnisses einschließt und auch einen Zugang zu dem Webserver einer bestimmten Firma, z.B. homewideweb.com (IP-Adresse) einschließt, kann auch der DNS Kenntnis der Adressen besitzen. Die IP-Adresse des DNS-Servercomputers kann jede IP-Adresse sein, die von dem Hersteller gesteuert wird. Die DNS-Adresse wird effektiv in dem Gerät installiert (oder kann aktualisiert werden wenn der Agent aktualisierbar gemacht wird und wird später aktualisiert).
Bei der Adressierung des Geräts kann in einer Ausführungsform der Erfindung das Verwenden fester IP-Adressen eines großen Adressbereichs die einfachste und zuverlässigste Netzwerkkonfiguration liefern und der leicht zugängliche ROM-Datenbereich in der 1394-Schnittstelle ermöglicht die Verwendung fester IP-Adressen in selbigem. In einer weiteren Ausführungsform der Erfindung können nicht-feste (dynamische) IP-Adressen verwendet werden, wobei eine Abstraktionsschicht (z.B. ein Name oder ein Nachschlagemechanismus) zum Speichern vorher angeordneter Verbindungen verwendet wird.
Für die Konfiguration der IP-Adressen können die folgenden Protokolle verwendet werden: 1) Dynamic Host Configuration Protocol (DHCP) mit DHCP-Servern und DHCP-Clients, 2) DHCP-Clients greifen auf eine Autokonfiguration zurück (es ist kein DHCP-Server vorhanden) und 3) vorzugsweise FWHCP-(Fire-Wire Host Configuration Protocol)Serveragent(s) und FWHCP-Clients, die nachstehend beschrieben sind. Die Autokonfiguration unter 2) oben ist so, wie sie als IETF-Entwurf "darft-ietf-dhc-ipv4-autoconfig-04.txt" vorgeschlagen wird.
Das DHCP benötigt die Unterstützung des BOOTP/UDP-Protokolls und bildet das nach, was innerhalb der Beschreibung der 1394 ausgeführt wird und stellt Eigenschaften, wie beispielsweise eine Lease-Time ("Mietzeit") und eine dynamische Adressierung bereit. Ein typisches DHCP erfordert die Verwaltung durch einen Administrator und muss konfiguriert und an die Anforderungen der Netzwerke von in Massen hergestellten Anwendungen der Unterhaltungselektronik (consumer electronics, CE), bei der zum Beispiel mehrere identische CE-Anwendungen mit installierten DHCP-Servern berücksichtigt werden müssen, angepasst werden.
Die 1394-Technologie stellt ein 'Plug-in' (Programmerweiterung) oder ein 'Power-up' (Einschalten) Reset und die folgenden 'Self-ID'-Folgen bereit, die gut für die Konfiguration des Netzwerks geeignet sind. Zudem stellt die 1394-Beschreibung einen installierten 'ROM'-Adressbereich, der gut für die Speicherung von und den Zugang zu den Konfigurationsdaten (z.B. IP-Adressen) geeignet ist, bereit. In einer bevorzugten Ausführungsform der Erfindung werden daher ein Konfigurationsagent für IP-Adressen (FWHCP) und eine Erkennungsseite für die Benutzersteuerung von 1394-Geräten verwendet. FWHCP stellt die Konfiguration von IP-Adressen für 1394WEB- und 1394-Geräte bereit. Der Zweck und das Ergebnis von FWHCP ähneln denjenigen von DHCP (d.h. einem Server zum Identifizieren und Zuweisen der lokalen IP-Adressen), das FWHCP verwendet jedoch während des Betriebs Daten im 1394-Adressbereich und 1394-Befehle. Das FWHCP stellt die Konfiguration von IP-Adressen von 1394WEB-Geräten in dem 1394-Netzwerk bereit, wobei Kollisionen mit Geräten in benachbarten, angeknüpften Netzen, die nicht 1394 sind, vermieden werden. Die Geräte werden mit einer eingebauten IP-Adresse aus dem Bereich 10.x.x.x hergestellt. In dem unwahrscheinlichen Fall einer Kollision bestimmt das FWHCP eine neue IP-Adresse und speichert diese in dem Gerät ab.
Die DHCP-/Autokonfiguration kann für Geräte in Netzwerken, die nicht 1394 sind, verwendet werden. Das DHCP-Protokoll stellt einem Client die "angeforderte IP-Adresse" bereit. Der angeforderte IP-Adressbereich wird bevorzugt aus dem oberen Teil eines 24 bit RFC 1918-Bereichs (10.128.1.1 bis 10.254.254.254) ausgewählt. Durch Auswählen eines Teils des erlaubten privaten Adressbereichs für 1394-IP-Adressen und eines anderen Teils für andere Konfigurationsverfahren (z.B. DHCP und DHCP-/Autokonfiguration) werden dann kompatible und sich nicht störende Adressen für ein heterogenes Netzwerk generiert und ermöglichen die Koexistenz von FWHCP und DHCP.
Während die Wahl sich nicht überlappender IP-Adressen für 1394 und benachbarte Netzwerke gewünscht ist, wird das heterogene Netzwerk, das FWHCP verwendet, selbst bei Überlappung derselben eine erfolgreiche Konfiguration vornehmen können. DHCP-Clients überprüfen auch ihre zugewiesene IP-Adresse mit einer ARP-Nachricht als Test, bevor sie diese verwenden. Auf diese Weise können verschiedene Verfahren der Adresskonfiguration erfolgreich koexistieren.
Unter Bezugnahme auf 8 wird ein beispielhafter Prozess gemäß der vorliegenden Erfindung für eine Kommunikation zwischen einem 1394-Netzwerk (z.B. Netzwerk 300) und einem Nicht-1394-Netzwerk (z.B. Ethernet 119) für die Konfiguration von IP-Adressen beschrieben. In diesem Fall verwendet das 1394-Netzwerk 300 eine FWHCP-Konfiguration und das Nicht-1394-Netzwerk 119 verwendet eine DHCP-Konfiguration oder ein anderes Verfahren. 1394-Geräte (wie beispielsweise der DTV und der DVCR in 7) unterstützen in der Regel kein DHCP. Das 1394-GERÄT-3 für eine Kommunikation zwischen einem 1394-Netzwerk und einem Nicht-1394-Netzwerk schließt eine IP-Adresse in dem 1394-ROM-Bereich ein und unterstützt FWHCP bei einem 1394-Gerät. Das GERÄT-3 umfasst ferner Mittel zum Unterstützen der Konfigurationsmechanismen in dem Nicht-1394-Netzwerk und hält ein erweitertes Datenblatt in dem 1394-ROM-Bereich für IP-Adressen von Geräten in dem Nicht-1394-Netzwerk bei. Die Konfigurationsprozesse (z.B. FWHCP für die Generierung der Beschreibung einer UI höchsten Niveaus) in dem 1394-Netzwerk 300 können daher die Verwendung von IP-Adressen in dem Nicht-1394-Netzwerk durch Auswählen von IP-Adressen aus dem erweiterten Datenblatt einschließen. Die Konfiguration des Nicht-1394-Netzwerks bewirkt das Bereitstellen der IP-Adressen für das erweiterte Datenblatt des 1394.
Entsprechend dem Prozess des Erkennens (Agent) werden ein 'Plug in' Reset aus der Beschreibung des 1394 und eine Self-ID für die Konfiguration verwendet und können für die Konfiguration der IP-Adresse benutzt werden. Bei Hausnetzwerken wird vorzugsweise das Vergeben fester IP-Adressen eingesetzt, es kann jedoch auch eine dynamische Adressierung verwendet werden. Innerhalb der Steuerung eines 1394WEB ist kein DNS erforderlich, da die Beschreibung der GUI höchsten Niveaus mit Hypertext-Verbindungen erzeugt wird, die IP-Adressen anstelle von Namen verwenden. Der IP-Konfigurationsagent (FWHCP) für das 1394-Netzwerk wird vorzugsweise für die IP-Konfiguration unter Verwenden der 1394-ROM-Daten und 1394-Befehle verwendet, es kann jedoch auch DHCP benutzt werden. FWHCP verwendet die untere Hälfte (lower half, LH) der RFC 1918 10.LH.X.X-Adressen und andere Hausnetzwerke (Nicht-1394) verwenden die obere Hälfte (upper half, UH) 10.UH.X.X. Vorzugsweise ist der Agent des FWHCP-Servers in jedem Gerät, das ein Client sein kann (Initiator der Steuerung) installiert. Wenn mehrere Client-Geräte mit dem 1394-Netzwerk verbunden sind, arbeitet nur das Client-Gerät mit der höchsten Global Unique Identification (GUID). GUID umfasst eine Nummer, die in der Schnittstelle integriert ist. Wenn mehrere FWHCP-Agents in dem 1394WEB-Netzwerk verfügbar sind, findet zu Beginn ein Selbstelektionsprozess statt, um dasjenige zu bestimmen, das arbeiten wird, während alle anderen untätig bleiben. Die höchste GUID wird arbeiten. In anderen Versionen kann die GUID mit dem umgedrehten höchsten Bit verwendet werden.
Ein Gerät, das über eine Schnittstelle mit einem Nicht-1394-Netzwerk verbunden ist, unterstützt ein erweitertes Blatt für IP-Adressen auf dem Nicht-1394-Netzwerk. Dies ermöglicht eine Aufnahme der IP-Adressen aus dem Nicht-1394-Netzwerk in die GUIs höchsten Niveaus des 1394 (z.B. in den 4A–B, GUIs 202, 204). Die Datenbits für die Steuerung in dem ROM-Bereich des 1394 werden dazu verwendet, die Funktion der drei Konfigurationsagents zu steuern: 1) Zählen der Self_ID des 1394, 2) FWHCP für die IP-Konfiguration und 3) Generierung der Beschreibung der UI, die weiter unten beschrieben ist.
Zuerst erkennt die Zählung der Self-ID des 1394 das Vorhandensein von Geräten. Nach einem Zurücksetzen des Busses (das durch An-/Ausschalten oder Hinzufügen/Entfernen von Geräten verursacht wird) beobachtet die 1394-Software in dem Gerät den Prozess der automatischen Konfiguration (Self-ID-Zyklen des 1394), um die Anzahl an Geräten zu zählen. Dies ist ein normaler Teil der 1394-Software für jedes 1394-Gerät. Dann überprüft das FWHCP für die IP-Konfiguration (das eine selbstelektierte FWHCP) die erkannten Geräte und kontrolliert ihre integrierten IP-Adressen. Erkannte doppelte (kollidierende) IP-Adressen werden unterdrückt und dem Gerät eine neue Adresse zugeteilt. Dann liest der Agent für die Generierung der Beschreibung der UI (UI oder andere Geräte) alle IP-Adressen der 1394WEB-Geräte aus und generiert für jedes Gerät eine Datei höchsten Niveaus für die graphische Benutzeroberfläche des Datenverzeichnisses des Geräts in HTML für die Seiten höchsten Niveaus des Symbols, die später von einem Webbrowser für die Erkennung der Geräte durch den Benutzer für eine Steuerung erzeugt werden.
Gemäß der vorliegenden Erfindung kann jedes Gerät in dem 1394-Netzwerk 400 seine eigene Beschreibung der UI des Netzwerks höchsten Niveaus 250 (9C) generieren. Die Beschreibung der UI 250 wird von einer Presentation Engine, wie beispielsweise dem Browser 200, in einem Client-Gerät dazu verwendet, eine Seite höchsten Niveaus für das Datenverzeichnis, wie beispielsweise die Seite 220 in den 5 bis 6, zu generieren und anzuzeigen. Nachdem der Self-ID-Agent des 1394 alle mit dem 1394-Netzwerk 300 verbundenen Geräte durchnummeriert hat, wird die Beschreibung der UI höchsten Niveaus 250 von allen UI-Geräten (und, wenn gewünscht, Nicht-UI-Geräten) separat generiert. Ein Gerät (z.B. ein DTV) kann einen mehr hervorstechendes (z.B. ein größeres) Symbol auswählen, um das Gerät darzustellen und der ganzen GUI 220 ein anderes Aussehen zu verleihen. Diese Technik stellt eine im Wesentlichen zuverlässigere Funktionsweise bereit als eine zentral generierte GUI für den Betrieb aller Geräte, da jedes Gerät seine eigene Beschreibung der UI 250 generieren und unabhängig von den anderen Geräten eine auf dieser basierende GUI (z.B. die Seite höchsten Niveaus 220) anzeigen kann. In jeder UI-Beschreibung UI werden das Gerätesymbol und die Bilddateien für das Logo der Geräte, die gerade mit dem Netzwerk 300 verbunden sind, auf HTML-'Seiten' für das Symbol und das Logo bezogen und bezeichnen den Text, der in einer HTML-Seite eingepackt ist (Auf ICON.'Graphic' bezogene ICON.HTM ist in den Seiten 202 und 204 zu finden, die auch die Bedienseiten für das Gerät einschließen; 5 unten zeigt auch ICON.HTM, LOGO.HTM und NAME.HTM in einer Seite höchsten Niveaus des Datenverzeichnisses). Wenn gewünscht, werden HTML-Rahmen (Frames) dazu verwendet, die Beschreibung der UI für das Datenverzeichnis höchsten Niveaus 250 für die Geräte des Netzwerks in jedem Gerät des Netzwerks zu erzeugen.
In vorteilhafter Weise wird daher eine nützliche Schicht der Abstraktion bereitgestellt, um die Verwendung alternativer Dateinamen und -Typen für z.B. die Identifizierung von Graphiken in den Netzwerkgeräten, ohne dabei eine Änderung der Beschreibung höchsten Niveaus 250, die in jedem Gerät generiert wurde, zu erfordern, zu ermöglichen. Der Text des Namens wird auch in einer HTML-Beschreibung 202, 204 (NAME.HTM ist auf den Seiten 202, 204 zu finden) angeordnet, wodurch dem Benutzer ermöglicht wird, den Text des Namens an einem Gerät, z.B. einem DTV, über eine der Seiten der GUIs der Geräte 220 zu z.B. DTV-BED2 zu ändern. Die Seite 220 wird dann angezeigt, wenn der Browser nach einem Zurücksetzen gestartet wird. Der Benutzer sieht die graphische Darstellung des DVCR-Symbols und klickt dieses an, wodurch die Bedien-GUI höchsten Niveaus des DVCR (mit dem 'PLAY'-Knopf usw.) geholt wird. Der Benutzer klickt einen der Knöpfe an, z.B. "Konfigurieren des NAMENS des Geräts" ("Configure Device NAME"), der eine andere GUI (aus der Hierarchie der Bedienseiten für den DVCR) mit einer großen Auswahl an verschiedenen Namen darstellt.
Der Benutzer klickt einen Namen aus den bereitgestellten Namenslisten, z.B. Master-Schlafzimmer-DVCR" ("Master Bedroom DVCR") an.
Die Software in dem Gerät ändert die Dateinamen, so dass die NAME.HTM genannte Datei den Text "Master-Schlafzimmer-DVCR" enthält (der alten standardmäßigen Datei NAME.HTM, die der DVCR enthielt, wird irgendein anderer Name gegeben).
Das Erscheinungsbild der GUI 220 ist in dem Fall 'Bad citizen'-("schlechter Bürger") Geräten mit zu viel oder übergroßem Text oder übergroßen Logos stabiler. In diesem Fall isolieren die Rahmen das Problem und verhindern, dass schlechte Elemente das Erscheinungsbild der gesamten GUI höchsten Niveaus 220 ungünstig beeinflussen.
Unter Bezugnahme auf die 9A–C, 10, 11 sind beispielhafte Funktionsblöcke und Verbindungen zu Daten- und Steuerbits und das Ablaufschema einer Ausführungsform für eine Systemarchitektur 400 für den vorher genannten Prozess des Erkennens gezeigt. Das System 400 umfasst fünf primäre Elemente: 1) den sich nicht selbst löschenden Speicherbereich des 1394 (IEEE 1212R ROM) 402 zum Konfigurieren der Daten und Speichern der Datenbits für die Steuerung; 2) den Agent für die Erkennung der Geräte (Device Discovery Agent) des 1394 (1394DDA) 404; 3) den Agent für die Konfiguration der IP-Adressen (IP Address Configuration Agent) (FWHCP) 406; 4) den Agent für die Generierung für die Beschreibung der UI (UI Description Generation Agent) 408; und 5) die Umgebung für die GUI-Generierung und die Laufzeit 410 (z.B. der Webbrowser 200 in der 2). 10 zeigt ferner ein beispielhaftes Ablaufdiagramm für die DDA- und FWHCP-Agents in dem System 400, das in Verbindung mit den Funktionsblöcken in den 9A-c funktioniert. Und die 10 zeigt ein Beispiel für ein Ablaufdiagramm für den UIDGA-Agent in dem System 400, der in Verbindung mit den Funktionsblöcken in den 9A-C funktioniert.
Unter Bezugnahme auf die 9A und 10 schließen alle Gerät den Agent für die Erkennung der Geräte des 1394 (1394DDA) 404 ein, um die Geräte an dem 1394-Bus, nach einem Zurücksetzen, durchzunummerieren, und den Wert in den lokalen ROM-Bereich des 1394 402 zu schreiben, damit der Wert anderen Funktionsagents mitgeteilt werden kann (Schritte 500, 502). Zum Synchronisieren (Hemmen) des Beginns anderer Konfigurations-Agents legt der 1394DDA-Agent 404 auch die die 'Konfiguration bewirkenden' Steuerbits fest. Der Agent/Mechanismus des Erkennens kann andere Mittel als den ROM-Bereich dafür verwenden, die Informationen zwischen den Konfigurations-Agents zu vermitteln, die lokal an einem Gerät auftreten und bei denen die Informationen nicht von anderen Geräten gesehen werden müssen.
Alle Geräte in dem Netzwerk 300 enthalten die folgenden Informationen, die entsprechend für die Agents der Erkennung und der IP-Adressen 404 und 406 für das 1394WEB in dem ROM für die Konfiguration des 1394 402 relevant sind: 1) Integrierte 64-Bit-GUID (Global Unique ID, in der Beschreibung des 1394); 2) Integrierte IP-Adresse aus dem privaten Adressbereich RFC 1918 in dem Bereich von '10.1.1.1' bis '10.127.254.254'. Hersteller können einen Wert des GUID auswählen, so dass die Wahrscheinlichkeit einer Kollision minimiert wird. Der obere Teil des privaten Adressbereichs (d.h. 10.128.1.1 bis 10.254.254.254) ist für Geräte in miteinander verbrückten Netzwerken ("Bridged Networks") reserviert; 3) zugewiesene IP-Adresse in dem Bereich von '10.1.1.1' bis '10.127.254.254' (zugeteilt von dem arbeitenden FWHCP-Agent 406); erweitertes Blatt für IP-Adressen für IP-Geräte in miteinander verbrückten Netzwerken; 5) zugewiesene Zählung der 1394-Geräte (zugewiesen von dem 1394DDA-Agent 404); 6) Steuer-/Statusbits, um die Steuerung der Synchronisation während der ablaufenden Konfiguration ("Configuration-in-Progress Synchronization") für den Agent des Erkennens der Geräte der 1394 404 anzuzeigen und die Konfiguration der IP-Adressen anzuzeigen (Die Steuerbits zeigen an, dass die Konfiguration gerade abläuft und daher werden die Werte in ROM-Daten, die sich von den Steuerbits unterscheiden, für den 1394DDA und die IP-Adresse weder geprüft noch eingeschrieben und diese sollten daher nicht verwendet werden). Die Bits zeigen ferner an, welche IP-Adresse verfügbar (zugewiesen oder integriert) ist und ob ein Agent für den FHWCP-Server 406 in dem Gerät vorhanden ist; 7) HTTP-Webserver, um einen entfernten Zugriff auf die Dateien in dem Raum für die Dateien in dem Gerät zu ermöglichen; und 8) Geräteinformationen 202, 204, die die aktuellen HTML-Dateien für das 'Symbol', den 'Namen' und das 'Logo' und andere graphische Dateien, auf die verwiesen wird und auf die über den Webserver zugegriffen werden kann, einschließen. Die obigen zusammengefassten Informationen werden in der unten angegebenen Beschreibung des ROM-Bereichs des 1394 ausführlich erläutert.
Der Inhalt der allgemeinen 1394ROM-Struktur 402 ist in den IEEE1212r, IEEE1212 und IEC61883 beschrieben. Die Struktur des ROM 402 ist eine Hierarchie aus Informationsblöcken, in denen die Blöcke, die in der Hierarchie höher gestellt sind, auf die Blöcke unterhalb zeigen. Die Position der anfänglichen Blöcke ist fest, wohingegen andere Eingaben von dem Hersteller abhängen, wobei diese jedoch durch Eingaben in den höheren Blöcken genauer beschrieben werden können.
Tabelle 3 zeigt den Businformationsblock und das Hauptverzeichnis (Root Directory) für die Konfigurations-ROM 402. Das erste Byte in jedem Eingang ist als Schlüsselbyte (Key) bekannt und identifiziert die Art des Eingangs. Folgendes kann bei der Konfigurations-ROM bei allen Geräten, die EIA-775-Beschreibungen verwenden, implementiert werden, wobei Anzeigevorrichtungen, wie beispielsweise DTVs und Bezugsvorrichtungen, wie beispielsweise DVCRs, STBs usw. eingeschlossen sind. Es kann mehrere andere erforderliche Strukturen, die auf anderen Protokollen basieren und an die jedes Gerät angepasst ist, geben. Tabelle 3 enthält Informationen für ein Gerät, das auch das Protokoll IEC61883 erfüllt. Das Hauptverzeichnis enthält Adressenverweise zu einem Modell-Datenverzeichnis (Model Directory) und drei Eingängen für Datenverzeichnisse von Geräten (Unit_Directories) (IEC61883, EIA-775 und 1394WEB), um anzuzeigen, dass das Gerät sowohl EIA-775- als auch 1394WEB-Protokolle unterstützt. Die Eingänge des Hauptverzeichnisses sind für andere 1394-Geräte nützlich, um die Protokolle und die Software (auch Dienste genannt), die von diesem 1394-Gerät unterstützt werden, zu erkennen. <Tabelle 3 – Konfigurations-ROM> Abstand (Basisadresse FFFF F000 000) Bus_info_blockbstand

04 00₁₆ 04 crc_Länge rom_crc_Wert

04 04₁₆ "1394"

04 08₁₆ Flags reserviert cyc_clk_acc max_rec reserviert

04 0C₁₆ Knoten_Hersteller_id chip_id-hi

04 10₁₆ Chip_ID_lo

Wobei 04 0C₁₆ und 04 10₁₆ auch als 64-Bit-GUID oder Global Unique ID bekannt sind. Hauptverzeichnis Abstand

04 14₁₆	Hauptlänge		CRC
	03₁₆	Modell_Hersteller_ID
	81₁₆	Hersteller_Name_Texturdeskriptor Abstand
	0C₁₆	Knoten_Fähigkeiten
	8D₁₆	Knoten_einzigartig_ID Abstand
	D1₁₆	Datenverzeichnis des Geräts Abstand (IEC 61833)

	D1₁₆	Datenverzeichnis des Geräts Abstand (EIA-775)
	D1₁₆	Datenverzeichnis des Geräts Abstand (1394WEB)
	Optional
xx xx₁₆	C3₁₆	Modell-Datenverzeichnis Abstand

Das Datenverzeichnis des IEC_61883-Geräts ist in Tabelle 4 gezeigt. Auf dieses Datenverzeichnis wird durch den Abstand des Datenverzeichnisses des Geräts in dem Hauptverzeichnis (d.h. Tabelle 3) verwiesen. In dem Feld 'Gerät_SW_Version' beschreibt das Bit mit dem geringsten Stellenwert (least significant bit) AV/C (0), wie es in der IEC 61883 beschrieben ist. <Tabelle 4 – Datenverzeichnis der IEC 61883 für ein Gerät> Datenverzeichnis des Geräts (IEC_61883)

Länge des Datenverzeichnisses CRC

12₁₆ Gerät_Beschr_ID (1394TA = 00 A0 2D₁₆)

13₁₆ Gerät_SW_Version (erster Hauptschlüssel = 01₁₆)

... <<möglicherweise andere Felder>>

... ...
Das Datenverzeichnis der EIA-775 für das Gerät ist in Tabelle 5 gezeigt. Die folgenden speziellen Informationen der EIA-775 erscheinen in dem Datenverzeichnis der EIA-775 für das Gerät. <Tabelle 5 – Datenverzeichnis der EIA-775 für das Gerät>

Länge des Datenverzeichnisses CRC

12₁₆ Gerät_Beschreibung_ID (EIA-775 = 005068₁₆)

13₁₆ Gerät_Software_Version (010100₁₆)

... <<möglicherweise andere Felder>>

... ...
Die 'Gerät_Beschreibung_ID' beschreibt die Identität der Anordnung, die für die architektonische Schnittstelle des Geräts und die Beschreibung verantwortlich ist. In diesem beispielhaften Fall beziehen sich das Datenverzeichnis und der Identitätswert = 005068₁₆ auf das EIA als verantwortlichen Körper und die Beschreibung der Architektur zur Steuerung des EIA-775.
Die 'Gerät_Software_Version' bezeichnet das von dem Gerät unterstützte Ausmaß der Änderung des EIA-775. Das Format ist in Tabelle 6 gezeigt. <Tabelle 6 – Gerät_Software_Version-Codierung>

Erstes Oktett 01₁₆

Zweites Oktett Höhere Nummer der Version (gerade 01₁₆)

Drittes Oktett Geringere Nummer der Version (gerade 00₁₆)

Das Datenverzeichnis des 1394WEB-Geräts ist in Tabelle 7 gezeigt. Die folgenden für das 1394WEB spezifischen Informationen erscheinen in dem Datenverzeichnis für das 1394WEB-Gerät. <Tabelle 7 – Datenverzeichnis des 1394WEB-Geräts>

Länge des Datenverzeichnisses		CRC

12₁₆	Gerät_Beschreibung_ID (1394WEB = 00XXXX₁₆)
13₁₆	Gerät_Software_Version (010100₁₆)

38₁₆	Erkennung_Steuerung_Bits
39₁₆	zugewiesene_Zählung_der_1394_Geräte
3A₁₆	IP_Adresse_integriert
3B₁₆	IP_Adresse_zugewiesen
	IP_Adresse_erweitertes Blatt
--₁₆	<<möglicherweise andere Felder>>

Die 'Gerät_Beschreibung_ID' beschreibt die Identität der Anordnung, die für die architektonische Schnittstelle des Geräts und die Beschreibung verantwortlich ist. In diesem beispielhaften Fall beziehen sich das Datenverzeichnis und der Identitätswert = 00XXXX₁₆ auf den verantwortlichen Körper und die Beschreibung der Architektur zur Steuerung des 1394WEB.
Die 'Gerät_Software_Version' bezeichnet das von dem Gerät unterstützte Ausmaß der Änderung des 1394WEB. Das Format ist in Tabelle 8 gezeigt. <Tabelle 8 – Gerät_Software_Version-Codierung>

Erstes Oktett 01₁₆

Zweites Oktett Höhere Nummer der Version (gerade 01₁₆)

Drittes Oktett Geringere Nummer der Version (gerade 00₁₆)
Der Schlüsselwert (38₁₆), der durch den Abschnitt 8.8 der Beschreibung der IEEE1212R für den privaten Gebrauch durch den Eigentümer des Datenverzeichnisses und der Architektur zugelassen ist, wird für den unmittelbaren Wert der 'Erkennung_Steuer_Bits' verwendet. <Tabelle 9 – Erkennung_Steuerung_Bits>

Agent des FWHCP-Servers Konfigurationsbetrieb. Nicht verwenden (wenn wahr) Welche IP-Adresse?

X Ja = 1 1394 Dev.-Zählung IP-Adresse zugewiesen_1integriert_0

31 6 5 4 3 2 1 0 (LSB)
In dem ROM-Bereich des 1394 402 gibt es Steuerbits, auf die von lokalen und entfernten Geräten zugegriffen werden kann. Die Steuerbits werden von dem Agenten für die Konfiguration der IP-Adresse 406 und dem Agenten für die Generierung einer Beschreibung der Schnittstelle 408 verwendet, wie weiter unten beschrieben ist.
In einer Ausführungsform der Erfindung stellen diese Steuerbits die folgenden Informationen bereit:
Bit 0 – Welche IP-Adresse – zeigt an, welche IP-Adresse verwendet wird oder gerade verwendet wird, d.h. die integrierte Adresse (= falsch) oder zugewiesene Adresse (= Adresse). Dies wird durch den arbeitenden Agenten für die IP-Konfiguration FWHCP 406 festgelegt.
Bits 1, 2 – Konfigurationsbetrieb nicht verwenden – Wenn die Einstellung anzeigt, dass die Erkennung des 1394-Geräts und auch separat dazu die Agenten für die IP-Konfiguration 404 bzw. 406 arbeiten und daher die Werte, die auf diese verweisen, ungültig sind, da sie sich ändern können oder noch nicht eingeschrieben wurden. Diese Bits werden durch den lokalen 1394DDA-Agenten (des Geräts) 404 festgesetzt. Der 1394DDA-Agent 404 löscht das Bit der Dev.-Zählung des 1394 und der arbeitende FWHCP-Agent 406 löscht das Bit der IP-Adresse.
Bit 3 – Das Vorhandensein des Agenten für den FWHCP-Server 406B wird festgesetzt, wenn das Gerät einen arbeitsfähigen FWHCP-Agenten 406 besitzt. Dieses Bit und die GUID werden von den FWHCP-Agenten 406 dazu verwendet, zu bestimmen, welcher FWHCP-Agent 406 arbeiten wird.
Zugewiesene_Zählung_der_1394_Geräte (39₁₆) – Der zugewiesene, unmittelbare Wert der Zählung der 1394-Geräte in dem Netzwerk 300. Die Zählung wird durchgeführt, wenn die 1394-Schnittstelle ihre Self-ID-Zyklen durchläuft. Der Agent für die Erkennung der 1394-Geräte 404 generiert den Wert, der in dem ROM-Bereich 403 für die spätere Verwendung durch die Agenten für die IP-Konfiguration und die Konfiguration der UI 406 bzw. 408 gespeichert wird.
IP_Adresse_integriert (3A₁₆)_B zugewiesener, unmittelbarer Wert. Diese Adresse wird während der Herstellung zugewiesen und in das Gerät integriert. Wenn diese integrierte Adresse nicht verwendet werden kann, kann eine alternative Adresse in dem Bereich für die zugewiesene Adresse abgespeichert werden und das Steuerbit so eingestellt werden, dass es so etwas anzeigt.
IP_Adresse_zugewiesen (3B₁₆) – zugewiesener, unmittelbarer Wert. Wenn identische IP-Adressen erfasst werden, weist der Agent für die Konfiguration der IP-Adressen FWCHP 406 diese Adresse zu, um eine Kollision zu vermeiden. Zudem wird das Steuerbit so eingestellt, dass es so etwas anzeigt.
IP_Adresse_erweitertes Blatt_für_ein_angeknüpftes_Netzwerk (BC₁₆) – Dieser Datenverzeichniseingang dient dem Abstand des Datenblattes für die erweiterte Tabelle für die IP-Adressen, siehe Tabelle 10. Das Datenblatt enthält IP-Adressen für die in Nicht-1394-Netzwerken verbundenen Adressen (die auch verbrückte 1394-Netzwerke sein könnten). Die Tabelle ist in den Verbindungsvorrichtungen des Typs (z.B. einer Bridge) enthalten, die fremde (Nicht-1394-) Netzwerke anbinden. Die Tabelle kann um so viele IP-Adressen, wie erforderlich sind, erweitert werden. Die Adresse der Verbindungsvorrichtung sollte selbst in der Tabelle enthalten sein. <Tabelle 10 – IP Adresse erweitertes Blatt>

Länge des Blatts-1(n)₁₆ CRC-16₁₆

IP-Adresse 1

...

IP<Adresse n
Unter Berücksichtigung des Steuerworts für die Erkennungssteuerungsbits funktioniert hierin die Verwendung einer ROM-Eingabe für das aktuelle Wort der Erkennungssteuerbits, ist jedoch nur eine beispielhafte Ausführung. Da ein ROM nicht so konstruiert ist, dass er effizient beschrieben werden kann (d.h. die ROM-Bereiche müssen gelöscht werden und das Beschreiben derselben erfolgt im Vergleich zu anderer Hardware, z.B. einem Register, langsam).
In der Hardware des 1394 werden Register für Daten bereitgestellt, die häufig beschrieben werden müssen. In einer anderen Version kann ein 1394-Register für das Steuerwort 'Erkennung_Steuerung_Bits' verwendet werden. Register können in einem Bereich ebenso von anderen Geräten adressiert werden, wobei ein anderes Gerät in dem ROM die Adresse des Registers nachschlagen und dann in das Register schreiben kann.
Unter Bezugsnahme auf 9B schließen eines oder mehrere Geräte einen Agenten für die Konfiguration der IP-Adressen (FWHCP) 406 (z.B. alle UI-Geräte und Gateway-Geräte und jedes andere Gerät, das ein Initiator für die Steuerung sein kann) ein. Der Konfigurations-Agent FWHCP 406 greift über das 1394-Netzwerk 300 auf die Werte der IP-Adressen von allen Geräten in Daten in dem ROM des 1394 402 zu. Für den Beginn der Synchronisation und die Fertigstellung des Beginns andere Anwendungen (z.B. der Generierung der Beschreibung einer UI) greift der FWHCP-Agent 406 auch auf die Steuerbits des 'Konfigurationsbetriebs' zu.
Unter Bezugnahme auf 9C können Geräte, die in der Lage sind, Benutzerschnittstellen anzuzeigen, und auch einige andere Geräte (z.B. Gateway-Geräte) den Agent für die Generierung der Beschreibung der UI 408 zum Generieren der Beschreibung der UI höchsten Niveaus 250 in z.B. HTML enthalten. Da, so wie oben ausführlich erläutert wurde, nur ein Agent für die IP-Konfiguration 406 pro Netzwerk arbeitet, müssen nicht alle Geräte den Agenten für die IP-Konfiguration 406 enthalten obwohl alle Geräte einen Agenten für die IP-Konfigration 406 enthalten können. Wenn ein Gerät den arbeitenden Agenten für die IP-Konfiguration 406 besitzt und ein Gerät für eine Benutzerschnittstelle ist, sollte der Agent für die IP-Konfiguration vor dem Agent für die Generierung der Beschreibung der UI arbeiten. Der Agent für die Generierung der Beschreibung der UI (UIDGA) 408 verwendet Informationen, die Steuerbits einschließen, die in dem ROM-Bereich des 1394 402 definiert sind, und andere Informationen (z.B. um zu bestimmen, welches arbeitende FWHCP die Global Unique ID (GUID) von Bus_Info_Block aus der Tabelle 3 ist), um zu bestimmen, welcher Agent für die IP-Konfiguration 406 arbeitet (wenn mehrere Agents in dem Netzwerk vorhanden sind), für einen synchronisierenden Beginn und für einen Zugang zu den gerade verwendeten IP-Adressen. Jedes Gerät kann einen UIDGA aufweisen und als solcher arbeiten, um die Seite des HN_Datenverzeichnisses (Seite der Erkennung höchsten Niveaus) zu erzeugen. Nachdem die IP-Adressen konfiguriert wurden, liest der UIDGA die Adressen aus, um die Seite des HN_Datenverzeichnisses zu erzeugen. Wenn die Generierung der Beschreibung der UI fertig gestellt wurde, verwenden die Generierung der GUI und die Umgebund des Zeitablaufs 410 (z.B. der Webbrowser 200 in der 2) die HTML-Datei für die Beschreibung der UI 250, um auf die Bereiche für die HTTP-Dateien in allen Geräten für Symbole, Namen und Logos (Icon.HTM, Name.HTM uns Logo.HTM sind in den Seiten 202 und 204 enthalten) zuzugreifen und die vollständige GUI höchsten Niveaus 220 für eine Anzeige in dem Client-Gerät zu generieren. Der Webbrowser verwendet die HTML-Datei 250, um die aktuellen graphischen Darstellungen der GUI in dem Prozess, der auf die Dateien aus den Geräten, z.B. Icon.HTM, Name.HTM und Logo.HTM zugreift, und wiederum auf irgendwelche Dateien zugreift, auf die diese Dateien verweisen, z.B. ICON.GIF und LOGO.GIF, zu erzeugen.
Unter Bezugnahme auf die 9A–C, 10, kann, wie erörtert wurde, jedes 1394WEB-Gerät in dem Netzwerk 300 den Agenten für die Erkennung der Geräte 404 einschließen. Der Agent für die Erkennung der Geräte 404 nummeriert die 1394-Geräte in dem Adressbereich des 1394, die mit dem 1394-Bus verbunden sind, wobei die unbearbeitete Erkennung in der 1394-Hardware durchgeführt wird. Die Self_ID und die Zuweisung der Nummer des physikalischen Knotens und die Schritte, die dazu führen, ist der zugrunde liegende Prozess der Erkennung durch die Hardware/Firmware der Schnittstelle. Alle Geräte überwachen die Self_ID-Zyklen und notieren das Vorhandensein von 1394-Geräten. Dies ist ein Teil einer 1394-Software für jedes 1394- Gerät: 1) Rücksetzen – das Rücksetzen des Busses verbreitet sich auf alle Schnittstellen während des Einschaltens des Geräts, des Hinzufügens von Geräten und des Entfernens von Geräten, 2) Identifizierung des Baums – wandelt eine einfache Netztopologie in einen Baum um, um ein Hauptverzeichnis (ROOT) aufzubauen, das als Master für bestimmte Funktionen dient: Master für die Zyklen des Busses, höchste Priorität für die Zuteilung der Bus-Zeit, 3) Selbstidentifizierung – weist die Nummer (Adresse) des physikalischen Knotens zu und tauscht auch die Fähigkeiten der Geschwindigkeit mit den Nachbarn aus. Der Knoten mit der höchsten Nummer mit sowohl dem Contender-Bit als auch dem Link-on-Bit ist der isochrone Ressourcemanager (Isochronous Resource Manager).
Der Erkennungsagent 404 schreibt den letzten Wert für die Zählung der Geräte in den ROM-Bereich des 1394, um diesen den anderen Agents zu vermitteln. Der Agent für die Erkennung der Geräte 404 ist der erste Software-Agent, der nach einem Zyklus des Rücksetzens des 1394 ausgeführt wird und Steuerbits (die Erkennungssteuerbits 2 und 1, Konfigurationsbetrieb: 1394DDA und IP_Adresse) werden zur Verzögerung anderer Agents, einschließlich der Konfigurations-Agents 406 und 408, von der Ausführung bis zu dem Zeitpunkt, wenn der Erkennungs-Agent 404 die Ausführung beendet hat, verwendet.
In einer Ausführungsform führt der 1394DDA-Agent 404 in jedem Gerät die Schritte 500, 502 durch, die einschließen: 1) das Einstellen der Steuerbits der Synchronisation (d.h. die Bits '1394DDA läuft gerade ab' und 'die IP-Konfiguration läuft gerade ab') in dem eigenen ROM-Bereich des Geräts 402, um anzuzeigen, dass der 1394DDA gerade abläuft und die IP-Konfiguration gerade abläuft (die IP-Konfiguration wird nicht ablaufen, wenn der 1394 DDA gerade ausgeführt wird) und dass die Werte für die Zählung der 1394-Geräte und die IP-Adresse nicht gültig sind, wodurch diese Steuerbits anderen Agenten (z.B. 408) an einem frühzeitigen Arbeitsablauf hindern; als solches wird dann der 1394 DDA ausgeführt, dann wird ein elektierter FWHCP ausgeführt und dann wird (gewöhnlich für das UI-Gerät) ein UIDGA ausgeführt; 2) das Auszählen der Anzahl an Selbstidentitätsfolgen des 1394, nach einem Rücksetzen des 1394 zum Erkennen der Anzahl an Geräten und effektiven Erkennen ihrer lokalen Adressen der Knoten für eine Verwendung durch andere Agenten 406, 408; 3) das Einschreiben des Werts der Zählung des Geräts in den eigenen ROM-Bereich des 1394 des Geräts 402; und 4) das Löschen (z.B. auf falsch) des Steuerbits für die Synchronisation für '1394DDA läuft gerade ab' in dem eigenen ROM des 1394 des Geräts 402, wobei das Bit 'die IP- Konfiguration läuft gerade ab' eingestellt bleibt und später von dem arbeitenden FWHCP-Agenten 406 gelöscht wird.
Eine alternative Architektur für die Konfiguration mit einer Liste der IP-Adressen in einem Gerät für eine Netzwerkverbindung (Bridge) ist möglich. Zum Beispiel kann die Liste der IP-Adressen für IP-Adressen von Geräten in einem verbrückten (Nicht-1394-) Netzwerk alternativ eher in der Phase der IP-Konfiguration durch den FWHCP-Agenten 406 als nur in der UIDGA-Phase durch den UIDGA-Agenten 408 untersucht werden. Dies ermöglicht, dass der FWHCP-Agent 406 Adresskollisionen erfasst und korrigiert und erlaubt daher einen Betrieb, ohne dass zwei verschieden definierte Adressbereiche, einer für das 1394-Netzwerk 300 und einer für das Nicht-1394-Netzwerk 119, erforderlich sind. Die Korrektur der Adresskollision kann durch Modifizieren der Adresse eines kollidierenden 1394-Geräts vorgenommen werden da die Liste der IP-Adressen für das verbrückte Netzwerk nicht mit den oben genannten Agents 406, 408 für das 1394-Netzwerk 300 modifiziert werden kann. Die Konfiguration ist zuverlässiger, wenn der FWHCP-Agent 406 die Adressen in dem verbrückten Netzwerk 119 auf eine Kollision prüfen kann, bevor er die Verwendung der Adressen in dem 1394-Netzwerk 300 zulässt.
Unter Bezugnahme auf die 9A–C, 10 bewirkt der Agent der Software für die Konfiguration der IP-Adressen (FWCHP) 406 das Bereitstellen einer Verwaltung 'fester' IP-Adressen und das Nachweisen und Korrigieren von Kollisionen der IP-Adressen in den in Massen hergestellten 1394-Geräten. Alle Geräte mit einer 1394WEB-UI enthalten einen FWHCP-Agent 406 und andere Geräte können diesen enthalten. In dem Netzwerk arbeitet jedoch nur ein FWHCP-Agent 406. Der 1394DDA-Agent ist der erste Software-Agent, der nach einem Zyklus des Rücksetzens des 1394 ausgeführt wird und, wie oben angegeben wurde, stellt der 1394DDA-Agent 404 die Bits '1394DDA läuft gerade ab' und 'die IP-Konfiguration läuft gerade ab' so ein, dass der FHWCP-Agent 406 solange verzögert wird, bis der 1394DDA-Agent 404 vollständig ausgeführt wurde.
In einer Ausführungsform führt der Agent für die Konfiguration der IP-Adressen 406 in einem Gerät Schritt durch, die ein Pollen des Steuerbits des Konfigurationsbetriebs des 1394DDA (d.h. das Bit '1394DDA läuft gerade ab') einschließen, um zu bestimmen, ob der Software-Agent für die Konfiguration des 1394DDA 406 vollständig ausgeführt wurde. Wenn dies der Fall ist, verwendet der FWHCP-Agent 406 die Zählung der durch den 1394 DDA-Agenten 404 bestimmten Geräte und liest die Wörter für die GUID und die Steuerung aus jedem Gerät (Schritt 504) ab, um zu bestimmen, welches Gerät in dem Netzwerk 300 dazu ausgewählt wurde, seinen FWHCP-Agenten auszuführen (Schritt 506). Das ausgewählte Gerät ist eines mit einem FWHCP-Agenten 406, das die höchste GUID aufweist (Schritt 508). Alle anderen FWHCP-Agenten 406 in anderen Geräten bleiben untätig (Schritt 510). Der arbeitende FWHCP-Agent 406 ist die 'gerade verwendete' (aktive) IP-Adresse (die durch das BIT 0 der Erkennung_Steuerung-Bits bestimmt wurde) aus jedem Knoten (z.B. den an der Schnittstelle vorhandenen Geräten, Host) ab und listet sie auf (Schritt 512). In einer Version erstellt der Software-Agent eine Liste zum Abspeichern der IP-Adressen während des Auslesens derselben in einer Anordnung (einem 'Array') (Schritte 514–518). Die Liste wird in einem Speicher (RAM oder DRAM) von dem Compiler und dem OS gesteuert werden. Der gerade verwendete Zustand wird durch Einstellen eines Bits in dem Gerät bestimmt, das anzeigt, ob die integrierte oder zugewiesene Adresse gerade verwendet wird. In Tabelle 7 liegen die IP_Adresse_zugewiesen und die IP_Adresse_integriert in dem Datenverszeichnis des 1394Web-Geräts vor.
Der arbeitende FWHCP-Agent 406 untersucht diese Liste auf eine Kollision unter den darin aufgelisteten IP-Adressen (es können auch andere Verfahren zum Nachweis und zur Auflösung einer Kollision verwendet werden) (Schritte 520–522). Wenn eine Kollision erfasst wird, ändert der FWHCP-Agent die miteinander kollidierenden Adressen, indem er z.B. die 6 Bits mit dem niedrigsten Stellenwert der IP-Adresse gegen ihre 6 Bit große Adresse des Knotens austauscht (Schritt 524). Es wird nur die minimale Anzahl an Änderungen durchgeführt, um die Kollision zu beheben. Wenn eine der miteinander kollidierenden Adressen bereits eine zugewiesene Adresse ist, wird diese Adresse bevorzugt vor der damit kollidierenden integrierten Adresse geändert, indem z.B. der 6 Bit umfassende, substituierte Wert inkrementiert wird und dies solange wieder überprüft wird, bis die Kollision behoben ist. Der FWHCP-Agent 406 schreibt den geänderten Wert zurück in das Gerät und das Steuerbit (Erkennung_Steuer_Bits: Bit 0) wird so eingestellt, dass es die zugewiesene IP-Adresse, die gerade verwendet wird, anzeigt und der integrierte Standard nicht länger verwendet wird (Schritt 526). Der Prozess wird für jede IP-Adresse wiederholt (Schritt 528). Nach dem Prozess zum Beheben der Kollision greift der arbeitende FWHCP-Agent 406 wiederum auf jedes Gerät zu und setzt die Bits 'IP-Konfiguration läuft gerade ab' in jedem Gerät auf z.B. falsch, um anzuzeigen, dass die angegebene IP-Adresse gültig ist.
Bei einem herkömmlichen WWW-Betrieb greift der Benutzer auf die gleiche Seite höchsten Niveaus zu. Unter Bezugnahme auf die 4B, 7 und 9 bis 11 schließen gemäß einem Aspekt der vorliegenden Erfindung jedoch alle UI-Geräte (z.B. Geräte, die zum Anzeigen von Benutzerschnittstellen in der Lage sind) eine Agenten für die Generierung einer Beschreibung der UI (UIDGA) 408 ein, um unabhängig eine Seite für die UI höchsten Niveaus 220 für die Steuerung der Geräte in dem lokalen Netzwerk (z.B. dem Netzwerk 100, dem Netzwerk 300 usw.) durch den Benutzer zu generieren. In einem Beispiel erzeugt ein Client-Gerät (z.B. ein PC) eine lokal abgespeicherte, standardmäßige Seite 220 für die Steuerung der Geräte, die mit dem Netzwerk 100 verbunden sind, durch den Benutzer. Dies ermöglicht, dass jedes UI-Gerät (z.B. der DTV 102) eine unterschiedliche Ansicht 220 des Hausnetzwerks, z.B. mit einem größeren, mehr hervorstechenden Symbol für das, was die Geräte der UI anzeigen, generiert wird. Der Benutzer wird daher leicht darüber in Kenntnis gesetzt, welches UI-Gerät 'gerade hier' ist (vor dem Benutzer) oder in dem Fall eines von dem Haus aus gesehen externen Zugangs ist kein Gerät 'gerade hier'. Ein Gerät ohne eine UI kann eine UI für ein anderes Gerät erzeugen, kennt jedoch nicht die Art des Geräts (z.B. erzeugt ein Kabelmodem die UI für HN-Geräte für Benutzer von außerhalb des Hauses). In diesem Fall ist das aktuelle UI-Gerät unbekannt. Es sticht daher kein bestimmtes Gerät in der GUI hervor. Zudem können Hersteller von Geräten, die mit dem Netzwerk 100 verbunden sind, falls es gewünscht ist, ihr eigene Gestaltung der GUI 202, 204 in jedem Gerät bereitstellen. Daneben müssen später verbesserte Ausgestaltungen der Browser- und Web-Technologie nicht durch die bereits existierende Technologie behindert werden.
Geräte ohne UI, insbesondere solche Geräte, die eine Gateway-Funktion ausführen, können auch einen Agent für die Generierung der Beschreibung einer UI 408 einschließen, um Beschreibungen der GUI höchsten Niveaus 250 zu generieren, ohne Prozesse für die Generierung der GUI und der Ablaufzeit 410 (z.B. den Webbrowser 200) zum Generieren und Anzeigen der GUIs 220 einzuschließen. Unter Verwendung der geeigneten Adressen (z.B. unter Verwenden der privaten Adressen des RFC1918 in dem lokalen HN) ermöglicht dies einen externen Zugang des WWW zu den Geräten des 1394WEB-Netzwerks. Den externen Adressen werden 'reale' IP-Adressen zugewiesen, die für eine Verwendung im Internet geeignet sind. Generell existiert ein Gerät (z.B. ein Gerät eines Gateway-Typs) mit der UIDGA 408, das das Haus dem Internet außerhalb repräsentiert. Der UIDGA des Gateways generiert eine andere Beschreibung der UI für die Verwendung außerhalb (der Fall des entfernten Zugriffs unterscheidet sich von der lokalen Verwendung der Geräte innerhalb), wobei die IP-Adresse des Hauses mit erweiterten Verbindungen verwendet wird, um die entsprechende lokale private IP-Adresse des Hausgeräts zu identifizieren.
Die UI-Geräte führen die folgenden Software-Prozesse aus, um die Ansichten 220 des Netzwerks 100/300 zu generieren und anzuzeigen: 1) den oben beschriebenen Agenten für die Erkennung der Geräte des 1394 404; 2) den Agenten für die Generierung der Beschreibung der UI (UIDGA) 408 und 3) den Prozess der Generierung der GUI und des Zeitablaufs (z.B. den Webbrowser 200). Unter Bezugnahme auf 11 führt ein UIDGA-Agent 408 in einem Gerät die Schritte aus, die das Pollen der Bits für die Konfiguration der IP-Adressen in dem eigenen ROM des 1394 des Geräts 402 einschließen, um die Fertigstelleung des FWHCP-Agent 406 vor dem Zugreifen auf irgendwelche weiteren IP-Informationen sicherzustellen (Schritt 600). Nach der Fertigstellung des FWHCP-Agenten 406, unter Verwenden der Zählung der durch den 1394DDA-Agent 404 generierten Geräte, greift der UIDGA-Agent 408 dann auf das Steuerwort in jedem Gerät, das gerade mit dem Netzwerk verbunden ist, zu, um die Einstellungen für den 'Konfigurationsbetrieb' falsch und die Bits der 'gerade verwendeten' IP-Adressen zu bestimmen (der UIDGA-Agent 408 erstellt die HTML-Seite höchsten Niveaus, die Seite des HN_Datenverzeichnisses, 220, die z.B. in den 5 bis 6 gezeigt ist). Danach liest der UIDGA-Agent 408 den aktuellen Wert für die gerade verwendete IP-Adresse aus und erstellt eine vollständige Liste der IP-Adressen der Geräte, die gerade mit dem Netzwerk 300 verbunden sind. Die Liste mit den IP-Adressen enthält Informationen (z.B. das Symbol, das Logo, den Namen usw.) von jedem Gerät und wird durch Verwenden der IP-Adressen von jedem Gerät in HTML geschrieben. Bevor er die Adressen einschließen kann, findet der UIDGA 408 die Adressen von jedem Gerät durch einen Zugriff auf jedes Gerät und Überprüfen derselben, um zu sehen, welche Adresse gerade beim Auslesen des Steuerbits (Bit 0) Erkennung_Steuerung_Bit, Tabelle 9, verwendet wird. Dann liest der UIDGA 408 die entweder integrierte oder zugewiesene Adresse aus Tabelle 7 aus. Für Geräte, die mit verbrückten Netzwerken kommunizieren, liest der UIDGA-Agent 408, wie durch Vorhandensein des Eingangs einer erweiterten Liste für die IP-Adressen in dem ROM des 1394 des Geräts 402 bestimmt wurde, die erweiterten IP-Adressen der Liste (IP_Adresse_erweitertes_Blatt) aus, um diesen Geräten zu ermöglichen, in die GUI 220 eingeschlossen zu werden. Das Eingangs-BC (IP_Adresse_erweitertes_Blatt) enthält die Adresse einer Referenzverbindung, die zu dem aktuellen Datenblatt zeigt. Geräte in dem angefügten, verbrückten Netzwerk werden nur in die Liste IP_Adresse_erweitertes_Blatt eingeschlossen, wenn sie auch den Dienst des 1394WEB-Typs unterstützen, d.h. dass sie einen Webserver und die Icon.HTM usw. und Bedienseiten ('index.htm') aufweisen.
Der UIDGA-Agent 408 liest die Liste der IP-Adressen aus (Schritt 602) und generiert die Beschreibung der UI des Netzwerks höchsten Niveaus 250 (9C) in z.B. HTML (z.B. Anhang 1) unter Verwenden der Liste der IP-Adressen (der UIDGA gibt das HN_Datenverzeichnis, die Seite der UI des Netzwerks höchsten Niveaus, die HTML-Datei aus) (Schritt 604). Der UIDGA-Agent 408 verwendet die IP-Adressen in den Hypertext-Verbindungen zu jedem Gerät für die Dateien icon.htm, name.htm und logo.htm. Der UIDGA schreibt eine HTML-Datei, die die Verweise zu der HTML-Seite von jedem erkannten Gerät, d.h. ICON.HTM, NAME.HTM, LOGO.HTM (z.B. Anhang 2, 3, 4) einschließt. Der UIDGA-Agent 408 verwendet dann die HTML-Dateien zu Referenz-Datenwörtern, die die Dateien für die graphischen Darstellungen des Symbols und des Logos und die Namensdaten einschließen, anstatt das unbearbeitete icon.gif oder logo.gif und den unbearbeiteten Text des Namens in der Beschreibung der UI höchsten Niveaus 250 einzuschließen (Schritt 606). Dies erlaubt eine Änderung der Datenwörter durch die entsprechende Gerät, um den aktuellen Zustand wiederzugeben, der von dem Hersteller zugeschnitten wurde oder von dem Benutzer an dem Gerät eingestellt wurde, ohne dabei irgendeine Änderung in der HTML-Beschreibung der UI höchsten Niveaus 250 in dem steuernden UI-Gerät zu verursachen. Obwohl eine Graphik pro Gerät in den beispielhaften GUI-Seiten 220 (5 bis 6) gezeigt wird, ermöglicht eine kundenspezifische Anpassung die Aufnahme von mehr als einer Datei für die graphische Darstellung, auf die durch ICON.HTM oder LOGO.HTM verwiesen wird, und von mehr Text in der NAME.HTM. In einer Ausführungsform werden HTML-Rahmen dazu verwendet, die Beschreibung der UI 250 zu implementieren, wie in den Beispielen weiter unten gezeigt ist. Die Verwendung von Rahmen stabilisiert das Erscheinungsbild der GUI 220 im Fall von 'Bad Citizen'-Geräten. Zum Beispiel wird ein Gerät, das zu viele Wörter oder einen übermäßig großen Text in seinem 'Namen'-Rahmen zeigt, nur das Aussehen der GUI des Geräts beeinflussen (da einige Wörter abgeschnitten sind und nicht angezeigt werden) und nicht das Erscheinungsbild der gesamten GUI höchsten Niveaus 220 in dem UI-Gerät ungünstig beeinflussen. Dann ruft der UIDGA den Prozess der Generierung der GUI (z.B. den Browser) in einem Client-Gerät auf, um eine Benutzerschnittstelle zu generieren und anzuzeigen (Schritt 608).
Der Prozess der Generierung der GUI 410 (z.B. der Webbrowser 200) verwendet die Beschreibung der UI 250 in z.B. HTML um die Seiten der GUI 220 in UI-Geräten zu generieren. In einem Beispiel zum Bereitstellen eines tastaturlosen Betriebs für Geräte der Unterhaltungselektronik (z.B. einen DTV) schafft es der Browser 200 beim Starten nicht, auszulesen und eine lokal generierte Beschreibung 'Geräte höchsten Niveaus.htm' 250 zum Generieren der Bedien-GUI höchsten Niveaus des Netzwerks 220 zu erstellen. Wie es hierin verwendet wird, bezeichnet 'lokal' in dem gleichen Gerät (ein UI-Gerät mit einem UIDGA, der das eigene HN-Datenverzeichnis (höchsten Niveaus) der GUI der Geräte des Netzwerks generiert) Das HN-Datenverzeichnis, die UI des Netzwerks höchsten Niveaus und die Seite der Erkennung sind gleich. Bei Personalcomputern (PCs) mit Tastaturen muss dies nicht standardmäßig der Fall sein. Bei CE-Geräten, wird das Starten des Browsers 200 bis nach der Fertigstellung der Generierung der Standardseite des UIDGA 250 durch den UIDGA-Agent 408 verzögert. In dem Fall, in dem der UIDGA-Agent 408 die Aufgaben nicht vollenden kann, zeigt der Browser eine alternative UI-Seite 220 an, die anzeigt, dass ein Fehler bei der Konfiguration des Netzwerks aufgetreten ist (z.B. "Aufgrund von xxxxxx ist es nicht möglich, die Seite des HN_Datenverzeichnisses zu generieren. Versuchen Sie, das Gerät xxxxxxx zu trennen. Während der Konfiguration des Netzwerks trat der Fehler Nummer xxxxxx auf. Kontaktieren Sie den Dienst des Tel-Dienstes xxx-xxx-xxxx oder den Webservice http://www.service.com.")
Um die GUI 220 zu erzeugen holt der Browser 200 die Dateien 'icon.htm', 'name.htm' und 'logo.htm' aus den Geräteinformationen 202, 204 in jedem Gerät, auf das verwiesen wurde (d.h. in der UI-Beschreibung, in der sich das ICON.HTM zum Beispiel in der HTML-Datei der Seite des HN_Datenverzeichnisses befindet), wie in der HTML-Beschreibung der UI 250 definiert ist. Die Inhalte dieser Seiten 202, 204 (z.B. die graphische Darstellung des Symbols) muss nicht gleich bleiben und kann dynamisch, um eine Änderung des Zustands des Geräts wiederzugeben oder nach der kundenspezifischen Anpassung geändert werden. Um die aktuellste Seite höchsten Niveaus 220 anzuzeigen, muss der Browser 200 nicht die Dateien 'icon.htm', 'name.htm' und 'logo.htm' in den Cachespeicher aufnehmen. In einer anderen Version wird zuerst immer überprüft, ob das Gerät irgendwelche Änderungen an den HTML-Dateien 202, 204, die es enthält, vorgenommen hat. Es wird ein "bedingtes GET" des HTTP dazu verwendet, den Zustand des angesteuerten Geräts zu überprüfen. In Abhängigkeit von dem zurückgesendeten Zustandscode wird der Browser 200 entweder seinen Cachespeicher auslesen oder eine frische oder aktualisierte Kopie der HTML-Datei 202, 204 aus den Geräten holen. Die Anzeige der GUI des HWW wird solange nicht beeinflusst, bis irgendeine Änderung in dem Zustand des angesteuerten Geräts auftritt.
Der Browser 200 versucht nicht, das HN-Datenverzeichnis höchsten Niveaus anzuzeigen, bis es vollständig generiert wurde. Wenn innerhalb einer vernünftigen Zeit kein HTML 250 generiert wird, zeigt der Browser eine alternative Seite an. Wenn ein Fehler bei der Konfiguration des Netzwerks die Ursache für das Problem ist, könnte eine alternative Seite ein gewisses Maß an technischer Unterstützung oder an Hilfe für den Benutzer für eine Diagnose bereitstellen.
Wann immer der Benutzer zu dem HN-Datenverzeichnis höchsten Niveaus zurückkehrt oder eine Aktualisierung durchführt, zeigt der Browser 200 die Seite 220 vollständig neu an. Dies ist notwendig, das HTML 250, das dem HN-Datenverzeichnis höchsten Niveaus zugrunde liegt, aktualisiert werden kann, wenn ein Gerät zu dem Netzwerk 100 hinzugefügt wurde oder aus diesem entfernt wurde. Es ist auch möglich, die Symbole für die Geräte zu aktualisieren, um die Änderungen des Betriebszustands der Geräte wiederzugeben. Browser die durch EIA-775.1-Geräte realisiert wurden, verwenden daher "bedingte GET"-Anforderungen des HTTP, um zu bestimmen, ob frische Kopien der Webseiten oder der graphischen Darstellungen von dem Server abgerufen werden oder nicht.
In diesem Aspekt stellt die vorliegende Erfindung die Beschreibung einer Benutzerschnittstelle bereit, in der die Erkennung des Benutzers von Geräten somit vollständig durch Verweise (d.h. in der Übersicht) erfolgt, wobei die Verweise 'Behälter' für die Informationen der Erkennung (z.B. Text und/oder graphische Darstellungen) für jedes Gerät sind und in jedem Gerät vorhanden sind. Jeder 'Behälter' enthält aktuelle Texturinformationen und/oder Verweise zu einer oder mehreren Informationsdateien, die mit graphischen Darstellungen formatiert sind, wobei jede Datei eines oder mehrere Bilder und/oder Text einschließen kann. Die Verwendung der Referenz-'Behälter' ermöglicht jedem Gerät, seinen bevorzugten UI-Inhalt oder sein bevorzugtes Graphikformat auszuwählen oder seinen UI-Inhalt so zu ändern, dass er angezeigt werden kann (indem der Text oder die Informationen über die graphische Darstellung, die darauf verweisen, geändert werden), ohne das Erfordernis, dass die Seite der Beschreibung der UI auf irgendeine Weise geändert werden muss. Daher ist keine Vermittlung der Änderungen der Software des generierenden Agent der Beschreibung der Erkennungs-UI erforderlich. In einer Version verweisen Geräte ihre Dateien für die graphische Darstellung von z.B. dem Symbol und dem LOGO indirekt, indem die HTML-Dateien verwenden, die durch Erzeugen der Beschreibung höchsten Niveaus des Netzwerks unter Verwenden von HTML-Rahmen aktiviert wurden. In ähnlicher Weise wird der Name des Geräts, der unter dem Symbol angezeigt wird, durch die Datei NAME.HTML dargestellt. HTML-Dateien werden dazu verwendet, auf z.B. die Dateien für die graphischen Darstellungen des Symbols oder des Logos und die Namensdaten zu verweisen, anstelle das unbearbeitete icon.gif ode logo.gif und den unbearbeiteten Namenstext zu enthalten. Dies ermöglicht ein Änderung des Datenworts, um den aktuellen Zustand, der von dem Hersteller angepasst wurde oder von dem Benutzer an dem Gerät eingestellt wurde, wiederzugeben, ohne irgendeine Änderung des HTML höchsten Niveaus zu verursachen. Dieser Grad der Abstraktion ermöglicht, dass die Beschreibung der UI höchsten Niveaus für die Namen und Typen der Dateien für die graphischen Darstellungen des Symbols und des Logos und den Namenstext, der angezeigt werden soll, immer gleich wenig berücksichtigt. Das Gerät kann auch mehrere verschiedene Dateien für die graphische Darstellung und den Text, der in der GUI höchsten Niveaus angezeigt wird, verwenden, ohne dass die Änderung an den UIDGA vermittelt werden muss. Die Änderung wird automatisch dann mit einbezogen, wenn die UI wieder angezeigt wird. Die Verwendung von Rahmen stabilisiert auch die Anzeige der GUI in dem Fall, in dem 'Bad Citizen'-Geräte unter Verwenden nicht anzeigbarer, graphischer Dateien oder von Text als Fehler in dem bestimmten Rahmen bestimmt werden und betrifft nicht die gesamte UI.
In einem Beispiel wird die Beschreibung der UI des Geräts des Netzwerks höchsten Niveaus unabhängig von irgendeinem Netzwerkgerät und mit Sicherheit von Geräten, die in der Lage sind, eine UI anzuzeigen, generiert. Das Generieren einer Benutzerschnittstelle in jedem Gerät anstelle des Generierens einer zentralen UI ermöglicht, dass das Gerät sein eigenes Gerätesymbols/seinen eigenen Text in der GUI in bevorzugter Weise angezeigt. Daneben kann jede GUI von dem Hersteller kundenspezifisch angepasst werden, von dem Benutzer konfiguriert werden und ist auch zuverlässiger, da es nicht von einem anderen Gerät, z.B. einem einzigen zentralen Server abhängt. Dies wird mit dem obigen Schema des 1394 gezeigt. Eine Generierung mehrerer UI ist möglich, da auf alle IP-Adressen des Geräts über die 1394-Schnittstelle zugegriffen werden kann. Die UI-Geräte (mit dem Browser) schließen den UIDGA-Agent ein, um ihre eigene Beschreibung der GUI höchsten Niveaus nach einem Zyklus des Rücksetzens eines 1394, wenn ein Gerät angefügt oder eingeschaltet wird, zu generieren.
Alle UI-Geräte erzeugen unabhängig voneinander eine Seite der UI höchsten Niveaus aus dem Betrieb des herkömmlichen WWW, wobei die Benutzer auf die gleiche Seite höchsten Niveaus zugreifen können. Gemäß einer Version der vorliegenden Erfindung generiert das Client-Gerät (z.B. ein PC) dynamisch eine lokal abgespeicherte, standardmäßige Seite einer Datei für jeden Zweck, wodurch ermöglich wird, dass jedes UI-Gerät (z.B. ein DTV) eine verschiedene Ansicht des Hausnetzwerks, z.B. mit einem größeren, mehr hervorstechenden Symbol für seine eigene Anzeige, generiert werden kann. Zudem ergibt sich für die Hersteller der Freiraum, ihre eigene Gestaltung der GUI besser als die anderen zu machen. Daneben müssen die Ausgestaltungen der Browser- und Web-Technologie nicht später durch die frühere Technologie behindert werden.
Unter Bezugnahme auf die Anhänge 1 bis 4 werden veranschaulichende Beispiele für Folgendes bereitgestellt: 1) Beschreibung der Seite höchsten Niveaus 250 (Anhang 1); 2) Background.htm (Anhang 2); 3) Icon.htm Anhang 3) und 4 Name.htm (Anhang 4).
Obwohl die vorliegende Erfindung in erheblichen Details und unter Bezugsnahme auf bevorzugte Versionen der gleichen beschrieben wurde, sind auch andere Versionen möglich.
Das Verfahren und das System zum Generieren einer Benutzerschnittstelle in einer Vielzahl verschiedener Geräte, die mit dem Netzwerksystem verbunden sind, um die Geräte, die mit einem Netzwerk verbunden sind, zu steuern, können gemäß der vorliegenden Erfindung in Hausnetzwerken mit daran angebundenen Multimedia-Geräten angewendet werden. Die Multimedia-Geräte können einen PC; einen VCR, einen Camcorder, eine DVD und einen HDTV usw. anwenden.
Anhang 1 – Beispiel für eine Seite höchsten Niveaus
Anhang 2 – Beispiel für Background.htm
Anhang 3 – Beispiel für Icon.htm
Anhang 4 – Beispiel für Name.htm

Claims

Verfahren zur Bereitstellung einer Benutzerschnittstelle (18, 220) zur Steuerung von Geräten (11–14, 102–110, 116, 117, 119, 120), die gerade mit einem Netzwerk (11a, 100, 300, 400) verbunden sind, umfassend folgende Schritte: a) Erhalten von Informationen durch eines oder mehrere der Geräte (12, 102, 103) von den Geräten, die gerade mit dem Netzwerk verbunden sind, wobei die Informationen Geräteinformationen enthalten; b) Generieren einer Benutzerschnittstellenbeschreibung in jedem der ein oder mehreren Geräte, wobei die Benutzerschnittstellenbeschreibung auf Basis zumindest der erhaltenen Informationen generiert wird und zumindest eine mit den Geräteinformationen jedes der gerade mit dem Netzwerk verbundenen Geräte assoziierte Referenz enthält; und c) Anzeigen einer oder mehrerer Benutzerschnittstellen (18, 220), die jeweils auf einer der einen oder mehreren Benutzerschnittstellenbeschreibungen basieren, auf einem oder mehreren mit dem Netzwerk verbundenen Geräten (12, 102, 103), die in der Lage sind, eine Benutzerschnittstelle anzuzeigen, zur Benutzersteuerung der Geräte, die gerade mit dem Netzwerk verbunden sind.
Verfahren nach Anspruch 1, wobei der Schritt des Anzeigens jeder Benutzerschnittstelle weiterhin folgende Schritte umfasst: Verwenden jeder Referenz in der entsprechenden Benutzerschnittstellenbeschreibung, um auf die assoziierten Informationen in jedem Gerät zuzugreifen; Generieren der Benutzerschnittstelle einschließlich Gerätedaten entsprechend jedem Gerät unter Benutzung der Informationen in jedem Gerät, auf die zugegriffen wurde; Anzeigen der Benutzerschnittstelle auf dem Gerät, das in der Lage ist, eine Benutzerschnittstelle anzuzeigen.
Verfahren nach Anspruch 1 oder 2, wobei der Schritt des Generierens einer Benutzerschnittstellenbeschreibung weiterhin einen Schritt des Assoziierens eines Hypertext-Links mit den Geräteinformationen jedes der Geräte, die gerade mit dem Netzwerk verbunden sind, umfasst.
Verfahren nach einem der Ansprüche 1 bis 3, wobei die Informationen in jedem Gerät eine in dem Gerät enthaltene HTML-Seite umfassen.
Verfahren nach einem der Ansprüche 1 bis 4, wobei der Schritt des Anzeigens der Benutzerschnittstelle weiterhin einen Schritt des Anzeigens der Benutzerschnittstelle auf einem Browser auf dem Gerät, das in der Lage ist, eine Benutzerschnittstelle anzuzeigen, umfasst.
Verfahren nach einem der Ansprüche 1 bis 5, weiterhin umfassend folgende Schritte: Verbinden mindestens eines Client-Geräts mit dem Netzwerk, das in der Lage ist, eine Benutzerschnittstelle anzuzeigen; und Anzeigen einer Benutzerschnittstelle auf dem Client-Gerät unter Benutzung der Referenzen in einer Benutzerschnittstellenbeschreibung zur Steuerung von Geräten, die gerade mit dem Netzwerk verbunden sind.
Verfahren nach Anspruch 1, wobei das mindestens eine Gerät in der Lage ist, eine Benutzerschnittstelle anzuzeigen, und weiterhin umfassend einen Schritt des Anzeigens einer Benutzerschnittstelle auf dem mindestens einen Gerät unter Benutzung der Referenzen in der Benutzerschnittstellenbeschreibung zur Steuerung von Geräten, die gerade mit dem Netzwerk verbunden sind.
Verfahren nach einem der Ansprüche 1 bis 7, wobei Schritt b) weiterhin einen Schritt des Generierens jeder Benutzerschnittstellenbeschreibung so umfasst, dass die Referenz in dieser Benutzerschnittstellenbeschreibung Zugriff auf zumindest die Informationen in jedem entsprechenden Gerät bereitstellt.
Verfahren nach einem der Ansprüche 1 bis 8, wobei Schritt b) weiterhin einen Schritt des Generierens jeder Benutzerschnittstellenbeschreibung so umfasst, dass auf Basis der von jedem Gerät erhaltenen Informationen die Benutzer schnittstellenbeschreibung weiterhin Gerätedaten entsprechend jedem Gerät enthält.
Verfahren nach einem der Ansprüche 1 bis 9, wobei die Geräteinformationen in jedem Gerät Geräteidentifikationsinformationen enthalten.
Verfahren nach einem der Ansprüche 1 bis 10, wobei die Geräteinformationen in jedem Gerät eine Benutzersteuerschnittstellenbeschreibung für eine Benutzerinteraktion mit dem Gerät enthalten.
Verfahren nach Anspruch 11, wobei Schritt b) weiterhin einen Schritt des Generierens jeder Benutzerschnittstellenbeschreibung so umfasst, dass jede Referenz in dieser Benutzerschnittstellenbeschreibung sich auf zumindest die Benutzersteuerschnittstellenbeschreibung in jedem entsprechenden Gerät bezieht.
Verfahren nach Anspruch 11, wobei Schritt b) weiterhin einen Schritt des Generierens jeder Benutzerschnittstellenbeschreibung umfasst, wobei diese Benutzerschnittstellenbeschreibung weiterhin Gerätedaten enthält, die jedem Gerät auf Basis von von jedem Gerät erhaltenen Informationen entspricht, wobei Gerätedaten Referenz auf die Benutzersteuerschnittstellenbeschreibung in jedem Gerät bereitstellen.
Netzwerksystem (11a, 100, 300, 400) zum Durchführen eines Dienstes und umfassend: eine physikalische Schicht (164), wobei die physikalische Schicht ein Kommunikationsmedium bereitstellt, das durch Geräte zum Kommunizieren miteinander verwendet werden kann; ein oder mehrere Geräte (11–14, 102–110, 116, 117, 119, 120), die mit der physikalischen Schicht verbunden sind, wobei mindestens ein Gerät Informationen speichert, die Geräteinformationen enthalten; einen Agent (408, 410) (Vermittler, Mittel, „agent") in jedem der ein oder mehreren Geräte (12, 102, 103), der zu Folgendem angepasst ist: a) Erhalten von Informationen durch jedes der ein oder mehreren Geräte von Geräten, die gerade mit dem Netzwerk verbunden sind, wobei die Informationen Geräteinformationen enthalten; b) Generieren einer Benutzerschnittstellenbeschreibung in jedem der ein oder mehreren Geräte, wobei die Benutzerschnittstellenbeschreibung auf Basis zumindest der erhaltenen Informationen generiert wird und zumindest eine mit der Geräteinformation jedes der gerade mit dem Netzwerk verbundenen Geräte assoziierte Referenz enthält; und c) Anzeigen einer oder mehrerer Benutzerschnittstellen (18, 220), die jeweils auf einer der ein oder mehreren Benutzerschnittstellenbeschreibungen basieren, auf einem oder mehreren mit dem Netzwerk verbundenen Geräten (12, 102, 103), die in der Lage sind, eine Benutzerschnittstelle anzuzeigen, zur Benutzersteuerung der Geräte, die gerade mit dem Netzwerk verbunden sind.
System nach Anspruch 14, wobei die Informationen, die Geräteinformationen enthalten, in jedem der ein oder mehreren Geräte gespeichert ist.
System nach Anspruch 14 oder 15, wobei jeder Agent weiterhin dazu angepasst ist, jede Benutzerschnittstelle durch folgende Schritte anzuzeigen: Benutzen jeder Referenz in der entsprechenden Benutzerschnittstellenbeschreibung, um auf die assoziierten Informationen in jedem Gerät zuzugreifen; Generieren der Benutzerschnittstelle, die jedem Gerät entsprechende Grätedaten enthält, unter Benutzung der Informationen in jedem Gerät, auf die zugegriffen wurde; und Anzeigen der Benutzerschnittstelle auf dem Gerät, das in der Lage ist, eine Benutzerschnittstelle anzuzeigen.
System nach einem der Ansprüche 14 bis 16, wobei jeder Agent ferner dazu angepasst ist, eine Benutzerschnittstellenbeschreibung durch Assoziieren eines Hypertext-Links mit den Geräteinformationen jedes der Geräte, die gerade mit dem Netzwerk verbunden sind, zu generieren.
System nach einem der Ansprüche 14 bis 17, wobei die Informationen in jedem Gerät eine in diesem Gerät enthaltene HTML-Seite umfassen.
System nach einem der Ansprüche 14 bis 18, wobei jeder Agent weiterhin dazu angepasst ist, eine Benutzerschnittstelle durch Anzeigen der Benutzerschnittstelle auf einem Browser auf dem Gerät, das in der Lage ist, eine Benutzerschnittstelle anzuzeigen, anzuzeigen.
System nach einem der Ansprüche 14 bis 19, weiterhin umfassend zumindest ein Client-Gerät, das mit dem Netzwerk verbunden ist und in der Lage ist, eine Benutzerschnittstelle anzuzeigen; und wobei ein oder mehrere Agents weiterhin dazu angepasst sind, eine Benutzerschnittstelle auf dem Client-Gerät unter Benuzung der Referenzen in einer entsprechenden Benutzerschnittstellenbeschreibung anzuzeigen, um Geräte zu steuern, die gerade mit dem Netzwerk verbunden sind.
System nach Anspruch 14, wobei das mindestens eine Gerät in der Lage ist, eine Benutzerschnittstelle anzuzeigen, und ein oder mehrere Agents weiterhin dazu angepasst sind, eine Benutzerschnittstelle auf dem zumindest einen Gerät unter Benutzung der Referenzen in einer entsprechenden Benutzerschnittstellenbeschreibung anzuzeigen, um Geräte zu steuern, die gerade mit dem Netzwerk verbunden sind.
System nach einem der Ansprüche 14 bis 21, wobei jeder Agent weiterhin dazu angepasst ist, jede Benutzerschnittstellenbeschreibung so zu generieren, dass die Referenz in dieser Benutzerschnittstellenbeschreibung Zugriff auf zumindest die Informationen in jedem entsprechenden Gerät bereitstellt.
System nach einem der Ansprüche 14 bis 22, wobei jeder Agent weiterhin dazu angepasst ist, jede Benutzerschnittstellenbeschreibung so zu generieren, dass die Benutzerschnittstellenbeschreibung weiterhin Gerätedaten auf Basis der von jedem Gerät erhaltenen Informationen enthält, die jedem Gerät entsprechen.
System nach einem der Ansprüche 14 bis 23, wobei die Geräteinformationen in jedem Gerät Geräteidentifikationsinformationen enthalten.
System nach einem der Ansprüche 14 bis 24, wobei die Geräteinformationen in jedem Gerät eine Benutzersteuerschnittstellenbeschreibung für eine Benutzerinteraktion mit dem Gerät enthalten.
System nach Anspruch 25, wobei jeder Agent weiterhin dazu angepasst ist, jede Benutzerschnittstellenbeschreibung so zu generieren, dass jede Referenz in dieser Benutzerschnittstellenbeschreibung sich zumindest auf die Benutzersteuerschnittstellenbeschreibung in jedem entsprechenden Gerät bezieht.
System nach Anspruch 25, wobei jeder Agent weiterhin dazu angepasst ist, jede Benutzerschnittstellenbeschreibung zu generieren, wobei diese Benutzerschnittstellenbeschreibung weiterhin Gerätedaten enthält, die jedem Gerät auf Basis von von jedem Gerät erhaltenen Informationen entsprechen, wobei die Gerätedatenreferenz auf die Benutzersteuerschnittstellenbeschreibung in jedem Gerät bereitstellen.
System nach einem der Ansprüche 14 bis 27, wobei, wenn mehrere Geräte mit der physikalischen Schicht verbunden sind, eines oder mehrere der mehreren Geräte Informationen speichern, die Geräteinformationen enthalten, und wobei eine Vielzahl der mehreren Geräte jeweils einen Agent enthalten.