DE60031107T2

DE60031107T2 - Kommunikation zwischen apparaten und steuerung der apparate in einem heimnetzwerk welches mit einem externen netzwerk mit regionaler unterstützung verbunden ist

Info

Publication number: DE60031107T2
Application number: DE60031107T
Authority: DE
Inventors: Dongyan Santa Clara California WANG; Richard Fremont California HUMPLEMAN
Original assignee: Samsung Electronics Co Ltd
Current assignee: Samsung Electronics Co Ltd
Priority date: 1999-11-19
Filing date: 2000-11-18
Publication date: 2007-03-01
Anticipated expiration: 2020-11-19
Also published as: CA2371747A1; EP1175677A2; WO2001037581A2; JP2003515206A; KR20010093265A; CN1163889C; EP1175677A4; WO2001037581A3; CN1352794A; AU753434B2; AU1897101A; DE60031107D1; EP1175677B1; CA2371747C; KR100379597B1

Description

Die vorliegende Erfindung betrifft das Gebiet von Netzwerken und genauer gesagt Heim-Netzwerke mit Multimediageräten, daran angeschlossen.
Ein Netzwerk schließt im Allgemeinen eine Kommunikationsverknüpfung und verschiedene Geräte mit Kommunikationsfähigkeit, verknüpft an die Kommunikationsverknüpfung ein. Die Geräte schließen Computer, Geräte der Peripherie, Router, Speichergeräte und Anwendungen mit Prozessoren und Kommunikationsschnittstellen ein. Ein Beispiel eines Netzwerkes ist ein Heim-Netzwerk für den Haushalt, in welchem verschiedene Geräte miteinander verknüpft sind. Ein üblicher Haushalt kann mehrere Geräte enthalten, einschließend Personalcomputer und Heimgeräte, welche sich typischerweise in einem Haus finden. Als solcher schließt der Begriff "Gerät" typischerweise logische Geräte oder andere Einheiten ein, welche eine Funktionalität und eine Fähigkeit haben, Daten auszutauschen, und nicht nur alle Heimgeräte, sondern auch Computer für generelle Zwecke einschließen können. Heimgeräte schließen solche elektronische Geräte ein, wie z.B. Sicherheitssysteme, Theaterausrüstung, TVs, VCRs, Stereoausrüstung und direkte Satellitenübertragungsdienste oder DBSS, auch bekannt als digitale Satellitendienste (digital satellite services (DSS)), Sprinklersysteme, Beleuchtungssysteme, Mikrowellen, Geschirrspüler, Ofen/Herd, Waschmaschinen/Trockner und ein Verarbeitungssystem in einem Automobil.
Im Allgemeinen werden Heimgeräte verwendet, um Aufgaben zu erfüllen, welche den Lebensstil eines Hausbesitzers verbessern und ebenso seinen Lebensstandard. Beispielsweise erfüllt ein Geschirrspüler die Aufgabe, dreckiges Geschirr zu waschen und nimmt es dem Hausbesitzer ab, dass er das Geschirr mit der Hand zu waschen hat. Ein VCR kann ein TV-Programm aufzeichnen, um dem Heimbesitzer zu ermöglichen, ein spezielles Programm zu einer späteren Zeit anzusehen. Sicherheitssysteme schützen die Wertgegenstände des Hausbesitzers und können die Angst des Hausbesitzers gegen unterwünschtes Eindringen vermindern.
Heimgeräte, wie z.B. eine Theaterausstattung für zu Hause werden oft gesteuert unter Verwendung einer allgemeinen einzelnen Steuereinheit, nämlich einem Fernbedie nungsgerät. Diese allgemeine einzelne Steuereinheit erlaubt es dem Hausbesitzer, mehrere unterschiedliche Heimgeräte unter Verwendung einer einzelnen Schnittstelle zu steuern und zu bedienen. Folglich haben viele Hersteller Steuereinheiten entwickelt zum Steuern und Bedienen ihrer Heimgeräte von einer einzelnen Schnittstelle aus.
Ein Nachteil, assoziiert mit der Verwendung der Fernbedienungseinheit, um Heimgeräte zu bedienen und zu steuern, ist, dass sie eine statische und Befehls-Logik zum Steuern und Bedienen eines jeden Heimgeräts zur Verfügung stellt. Folglich kann eine spezielle Fernbedienungseinheit nur diejenigen Heimgeräte steuern und bedienen, für welche sie die notwendige Steuer- und Befehls-Logik einschließt. Falls beispielsweise eine Fernbedienungseinheit eine Logik zum Steuern eines Fernsehers (TV), eines Video-Kassetten-Rekorders (VCR) (video cassette recorder) bzw. eines digitalen Videogerätes (DVD) (digital video device), jedoch nicht einer Kompaktdisk(CD)-Einheit umfasst, kann die Fernbedienungseinheit nicht verwendet werden, um die CD-Einheit zu bedienen bzw. zu steuern. Darüber hinaus wird, da neue Heimgeräte laufend entwickelt werden, die Fernbedienungseinheit nicht in der Lage sein, die neuen Heimgeräte zu steuern bzw. zu bedienen, welche eine Steuer- bzw. Befehlslogik benötigen, welche zum Zeitpunkt, zu welchem die Fernbedienungseinheit entwickelt worden ist, nicht bekannt war.
Des Weiteren kann typischerweise eine Fernbedienungseinheit nur verwendet werden, um diejenigen Heimgeräte zu bedienen bzw. zu steuern, welche innerhalb des Signalbereichs der Fernbedienungseinheit liegen. Folglich kann der Anwender nicht die Fernbedienungseinheit von einer einzelnen Stelle in einem Haus einsetzen, um die Heimgeräte zu steuern bzw. zu bedienen, welche angeschlossen sind, jedoch in unterschiedlichen Arealen des Hauses lokalisiert sind. Beispielsweise kann ein VCR, welcher in einem oberen Stockwerk in einem Schlafzimmer lokalisiert ist, mit einem Fernseher verknüpft sein, welcher in einem unteren Stockwerk in einem Wohnzimmer steht. Falls ein Anwender wünscht, ein Band, enthalten in dem VCR, lokalisiert in einem oberen Stockwerk in dem Schlafzimmer auf dem TV, lokalisiert in einem unteren Stockwerk im Wohnzimmer abspielen will, kann der Anwender nicht beide, den Fernseher und den VCR von einem einzelnen Ort aus steuern bzw. bedienen.
Ein weiterer Nachteil, assoziiert mit der Anwendung von Fernbedienungseinheiten ist, dass bekannte Fernbedienungseinheiten nicht eine Vielzahl von unterschiedlichen Geräten steuern können und genauer gesagt nicht eine Vielzahl von Geräten ansteuern kön nen, welche unterschiedliche Fähigkeiten haben, miteinander zu kommunizieren, um Aufgaben zu lösen oder eine Dienstleistung zu vollführen. Des Weiteren stellen konventionelle Netzwerksysteme nicht Mechanismen für Softwareanwendungen in unterschiedlichen Netzwerkgeräten zur Verfügung, so dass sie automatisch miteinander kommunizieren können, um Aufgaben zu realisieren, ohne dass es der direkten Befehle des Anwenders bedarf.
Um die oben genannten Probleme zu lindern, stellen einige Netzwerkmodelle eine zentrale/singuläre Bedienerschnittstelle (UI, user interface) in einem Gerät zur Verfügung, einschließend statische Geräteinformation für Netzwerkgeräte zur Anwendersteuerung von Netzwerkgeräten. Jedoch benötigt in solchen Netzwerken eine Veränderung der Geräteinformation (beispielsweise ein Symbol) in einem Gerät eine Veränderung und einen Neuaufbau der am weitesten oben gelegenen Seite. Des Weiteren wird, falls das Gerät, welches die zentrale Bedienerschnittstelle darstellt, nicht verfügbar wird, die Anwendersteuerung des Netzwerkes eingeschränkt. Ein weiteres Problem mit der zentralen/singulären Seite ist, dass jedes UI-Gerät die gleiche Seite darstellen muss und ein Umfang nicht für jeden Hersteller zur Verfügung gestellt wird, um sein eigenes UI-Aussehen bzw. seine Erscheinung zu erzeugen, noch die Technologie, verwendet in dem UI-Gerät, zu verändern. Der Inhalt eines Symbols/einer Information, repräsentierend ein Gerät, kann nicht verändert werden und ein UI-Gerät kann nicht ein markanteres Erscheinungsbild für ein Gerätesymbol anzeigen, als das Symbol für das UI-Gerät selbst. Außerdem kann ein UI-Erzeugerwerkzeug e-Business-Symbole nicht von einem externen Web-Portal erhalten. Solch ein Modell kann nicht für die Industrieanwendung standardisiert werden, da ein einzelnes/zentrales UI-Gerät die UI steuert.
Des Weiteren ermöglichen existierende Netzwerke nur die Kommunikation und Ansteuerung von Geräten, verknüpft mit einem Netzwerk (z.B. 1394) unter Verwendung einer zentralen Anwender-Schnittstelle, ohne die Fähigkeit, Anwender-Schnittstellen und Steuerungen von Geräten und Dienstleistungen, verknüpft mit anderen unterschiedlichen Netzwerken (beispielsweise Internet) zur Verfügung zu stellen.
Folglich besteht ein Bedürfnis nach einem Verfahren und einem System, welche dynamische Steuer- und Bedienungsgeräte in einem Heim-Netzwerk zur Verfügung stellen. Es besteht auch ein Bedürfnis nach einem Verfahren und einem System, die Fähigkeit zur Verfügung zu stellen, Zugang zu Geräten zu bekommen, verknüpft mit einem ersten Netzwerk, und Zugang zu Geräten zu bekommen und Dienstleistungen, verknüpft mit einem zweiten unterschiedlichen Netzwerk, und unabhängig unterschiedliche Anwender-Schnittstellen-Repräsentationen der Geräte, verknüpft mit dem ersten Netzwerk, und von Geräten und Dienstleistungen, verknüpft mit dem zweiten Netzwerk, zur Anwendersteuerung und Kommunikation zu erzeugen. Es besteht auch ein Bedarf nach einem Verfahren und einem System, regionalen Service und Kundendienst für Geräte, lokalisiert in unterschiedlichen geografischen Regionen, zu erhalten.
Die internationale Anmeldung, veröffentlicht unter dem Patent Cooperation Treaty (PCT) mit der internationalen Veröffentlichungsnummer WO 99/35753 mit dem Titel "Verfahren und System, bezogen auf ein Audio/Video-Netzwerk", offenbart das Herunterladen von Anwendungen zum Steuern von Geräten innerhalb eines Audio/Video-Heim-Netzwerkes. Eine Software-Abstraktion zur Steuerung des Gerätes wird als DCM (Device control module) bezeichnet und erzeugt. Die herunter geladene Anwendung kann eine Datenbank abfragen, enthaltend die DCMs der Geräte und dann wird besagte Anwendung mit einem Mechanismus, um diese Geräte zu steuern, zur Verfügung gestellt.
Die vorliegende Erfindung erfüllt die oben erwähnten Bedürfnisse. In einer Ausführungsform stellt die vorliegende Erfindung ein Verfahren und ein System zur Verfügung, zum Bereitstellen von Benutzerschnittstellen in einem ersten Netzwerk, das erste Geräte (Vorrichtungen) enthält, die über ein Kommunikationsmedium miteinander verbunden sind, sowie wenigstens ein Schnittstellengerät, das das erste Netzwerk mit zumindest einem zweiten Netzwerk verbindet, das daran angebunden zweite Geräte aufweist, welche Dienste bereitstellen, wobei die Benutzerschnittstellen dazu dienen, die Geräte zu steuern, welche momentan mit dem ersten Netzwerk verbunden sind und Geräte, welche derzeit mit dem zweiten Netzwerk verbunden sind. In einer Version umfasst das Verfahren die Schritte

– in jedem der einen oder mehreren ersten Geräte in dem ersten Netzwerk von:
(a) Beziehen von Information von einem oder mehreren Geräten, welche derzeit mit dem ersten Netzwerk verbunden sind, wobei die Informationen Geräte-Informationen einschließen; und
(b) Erzeugen einer Benutzerschnittstellenbeschreibung, einschließend:
(1) zumindest einen Bezug, assoziiert mit der Gerät-Information von jedem von besagten einen oder mehreren ersten Geräten,
(2) zumindest einen Umleitungs-Identifizierungscode ((RIC, redirection identification code), der mit diesem ersten Gerät korrespondiert, und
(3) zumindest einen Bezug, der mit den Diensten, bereitgestellt durch das zweite Netzwerk, verknüpft ist.

Das zweite Netzwerk schließt zumindest ein erstes Portal und zumindest einen Ziel-Service-Anbieter zum Bereitstellen von Diensten ein und das Verfahren umfasst des Weiteren die Schritte wie folgt: zumindest ein erstes Gerät fordert Dienste von dem zweiten Netzwerk andurch Übermitteln einer Anforderung, einschließend ein RIC an das erste Portal unter Verwendung eines Bezuges in der Anwender-Schnittstellen-Beschreibung, wobei das erste Portal einen Ziel-Dienstanbieter, basierend auf dem empfangenen RIC bestimmt und das erste Portal die Anforderung an den Ziel-Dienstanbieter umleitet. Der Ziel-Dienstanbieter in dem zweiten Netzwerk kann intern oder extern für das erste Portal sein.
Ein Bezug, assoziiert mit Diensten, bereitgestellt durch das zweite Netzwerk, umfasst zumindest einen Hyper-Link zu besagtem ersten Portal, wobei das erste Portal Dienstinformationen einschließt, umfassend zumindest eine Umleitungsinformation, basierend auf den RICs für Dienste, bereitgestellt durch andere Dienstanbieter in dem zweiten Netzwerk. Das erste Portal schließt des Weiteren eine Liste von RICs ein und korrespondierenden Ziel-Dienstanbieter-Portal-Adressen, so dass die Schritte des Bestimmens eines Ziel-Dienstanbieters des Weiteren die Schritte des Nachschauens in besagter Liste nach einer Ziel-Dienstanbieter-Portal-Adresse, korrespondierend zu einem empfangenen RIC. einschließt, und das Umleiten der Anforderung an besagte Ziel-Dienstanbieter-Portal-Adresse. Jede Ziel-Dienstanbieter-Adresse kann eine URL umfassen. Das RIC kann erhalten werden von einem Anwender oder automatisch. Für zumindest ein Benutzergerät umfasst das korrespondierende RIC einen Identifizierer, welcher die geografische Region des ersten Gerätes repräsentiert.
Eine Benutzer-Schnittstelle wird dargestellt, basierend auf jeder Benutzer-Schnittstellenbeschreibung auf einem Gerät, verbunden mit einem ersten Netzwerk, das in der Lage ist, eine Benutzer-Schnittstelle für die Benutzersteuerung von besagten ersten Geräten sowie die Kommunikation mit besagten zweiten Geräten darzustellen. Das Darstellen einer jeden Benutzer-Schnittstelle basiert auf der Anwendung eines jeden Bezugs in der korrespondierenden Benutzer-Schnittstellenbeschreibung, um die assoziierte Information in jedem ersten Gerät zugänglich zu machen und assoziierte Dienstinformation in jedem zweiten Gerät; das Erzeugen der Benutzer-Schnittstelle, einschließend Information, korrespondierend zu jedem Gerät, unter Verwendung der zugänglich gemachten Information in jedem Gerät; und das Darstellen der Benutzer-Schnittstellen auf jedem Gerät, das in der Lage ist, eine Benutzer-Schnittstelle darzustellen.
Diese und andere Merkmale, Aspekte und Vorteile der vorliegenden Erfindung werden besser verständlich werden unter Bezug auf die folgende Beschreibung, die beigefügten Ansprüche und die hinzugefügten Zeichnungen, wobei
1 ein beispielhaftes Blockdiagramm darstellt der Architektur einer Ausführungsform eines Netzwerks gemäß der vorliegenden Erfindung;
2 ein beispielhaftes Blockdiagramm der Architektur einer weiteren Ausführungsform eines Netzwerks gemäß der vorliegenden Erfindung darstellt;
3 ein Beispiel eines geschichteten Schnittstellenmodelles illustriert, welches zur Kommunikation zwischen Heimgeräten in Übereinstimmung mit der vorliegenden Erfindung verwendet werden kann;
4a ein Beispiel zeigt für ein Architekturdiagramm eines DVCR-Server-Gerätes, welches Video auf einem DTV-Client-Gerät abspielt, das in der Lage ist, eine Benutzer-Schnittstelle darzustellen, und zwar in einem Netzwerk gemäß der vorliegenden Erfindung;
4b ein weiteres beispielhaftes Architekturdiagramm eines Server-Gerätes zeigt, welches mit einem Client-Gerät kommuniziert, das in der Lage ist, eine Benutzer-Schnittstelle in einem Netzwerk gemäß der vorliegenden Erfindung darzustellen;
5 und 6 Beispiele von GUIs auf höchster Ebene illustrieren, welche die Funktionen von Geräten des Netzwerkes für einen Anwender repräsentieren;
7 ein Beispiel für eine Blockdiagramm-Architektur eines Heimnetzwerks, konstruiert in Übereinstimmung mit einer weiteren Ausführungsform der vorliegenden Erfindung zeigt;
8 ein Beispiel eines Prozesses gemäß der vorliegenden Erfindung zum Kommunizieren zwischen einem 1394-Netzwerk und einem nicht-1394-Netzwerk für IP-Adressen-Konfiguration zeigt;
9a–c Beispiele für funktionelle Blockdiagramme von Verknüpfungen von Daten und Steuer-Bits einer Ausführungsform einer Entdecker-System-Architektur in einem Netzwerk gemäß einem weiteren Aspekt der vorliegenden Erfindung zeigen;
10 ein Beispiel eines Flussdiagramms für Entdeckungs- und Konfigurationsmittel in dem Heim-Netzwerk in Verknüpfung mit den funktionellen Blockdiagrammen in 9a–c zeigt;
11 ein Beispiel für ein Flussdiagramm für ein Benutzer-Schnittstellen-Beschreibungs-Erzeugungsmittel in dem Heim-Netzwerk in Verbindung mit dem funktionellen Blockdiagramm in 9a–c zeigt;
12 eine bildhafte Ansicht einer Netzwerk-Benutzer-Schnittstellen-Beschreibung auf höchster Ebene zeigt, einschließend Links auf externe Dienste, welche tatsächliche Symbole- und Namens-HTML-Datei-Bezüge und Adressen zeigt, entsprechend einem weiteren Aspekt der vorliegenden Erfindung;
13 ein Beispiel eines GUI auf höchster Ebene zeigt, repräsentierend die Funktionen von Geräten in einem Heim-Netzwerk sowie Dienste, be reitgestellt durch ein externes Netzwerk, basierend auf der Anwender-Schnittstellen-Beschreibung von 12;
14 ein weiteres Beispiel für eine Prozess gemäß einem weiteren Aspekt der vorliegenden Erfindung zur Kommunikation zwischen einem 1394-Netzwerk und einen nicht-1394-Netzwerk zur IP-Adressenkonfiguration zeigt;
15 ein Beispiel für ein Flussdiagramm für einen Benutzer-Schnittstellen-Beschreibung-Erzeugungsagenten in einem Heim-Netzwerk zum Erzeugen einer Netzwerk-Benutzer-Schnittstellen-Beschreibung auf höchster Ebene zeigt, einschließend Verknüpfungen für externe Dienste gemäß einem weiteren Aspekt der vorliegenden Erfindung;
16 eine bildliche Übersicht einer Netzwerk-Benutzer-Schnittstellen-Beschreibung auf höchster Ebene, einschließend Verknüpfungen zu externen Diensten und regionale Identifizier-Codes (RIC) unter Verwendung von Zip-Codes zeigt, wobei tatsächliche Icon und Namen-HTML-Dateiverweise und Adressen gezeigt werden entsprechend einem weiteren Aspekt der vorliegenden Erfindung;
17 ein beispielhaftes Verfahren für eine Benutzerkonfiguration zeigt, wobei ein Benutzer die allgemeine RIC-Information, wie z.B. Zip-Code oder Gebiet-Code für regionale Unterstützung eingeben kann;
18 ein beispielhaftes Verfahren der automatischen Konfiguration zum Erhalten von IP-Adressen als RICs über das System des Service-Providers zeigt;
19 ein Beispiel eines Flussdiagramms von Schritten einer Ausführungsform der Umleitung entsprechend der vorliegenden Erfindung in Verknüpfung mit 17 zeigt;
20 ein Beispiel eines Flussdiagramms von Schritten einer weiteren Ausführungsform der Umleitung entsprechend der vorliegenden Erfindung in Verbindung mit 18 zeigt; und
21 ein Beispiel eines Blockdiagramms der Architektur eines Netzwerksystems einschließend mehrere Heim-Netzwerke und verschiedene externe Netzwerke, miteinander verknüpft über ein Kommunikations-Netzwerk, wie z.B. das Internet, zeigt, wobei die Umleitung basierend auf RICs ist, entsprechend einem Aspekt der vorliegenden Erfindung.

Appendix 1–4 sind illustrative Beispiele für: (1) Seitenbeschreibung auf höchster Ebene 250 (Appendix 1); (2) Background.htm (Appendix 2); (3) Icon.htm (Appendix 4); und (4) Name.htm (Appendix 4);
Appendix 5–12 sind illustrative Beispiele für die folgenden htm-Dateien zum Erzeugen einer Heim-Netzwerk-Benutzer-Schnittstellen-Beschreibung und GUI in den 12–13, einschließend externe Links, wobei:
Appendix 5 – das Seitenbeispiel auf höchster Ebene TLNUID (index.htm) zeigt
Appendix 6 – das Beispiel background.htm zeigt;
Appendix 7 – das Beispiel icon.htm zeigt;
Appendix 8 – das Beispiel name.htm zeigt;
Appendix 9 – das Beispiel logoicon1.htm zeigt;
Appendix 10 – das Beispiel logoname1.htm zeigt;
Appendix 11 – das Beispiel logoicon2.htm zeigt;
Appendix 12 – das Beispiel logoname2.htm zeigt;
Appendix 13 ein Perl-Beispiel-Programm für eine Spuren-Route für einen regionalen Dienst illustriert;
Appendix 14 ein Beispiel eines Umleitungsprogrammes illustriert;
Appendizes 15, 6, 7, 8, 16, 17, 18 und 19 sind illustrative Beispiele für htm-Dateien zum Erzeugen der Heim-Netzwerk-Benutzer-Schnittstellen-Beschreibung auf höchster Ebene und GUI in den 13 und 16, einschließend externe Links mit regionaler Unterstützung, wobei:
Appendix 15 – das Seiten-Beispiel auf höchster Ebene TLNUID (index.htm) zeigt;
Appendix 16 – das Beispiel logoicon1.htm zeigt;
Appendix 17 – das Beispiel logoname1.htm zeigt;
Appendix 18 – das Beispiel logoicon2.htm zeigt; und
Appendix 19 – das Beispiel logoname2.htm zeigt.

Um das Verständnis zu ermöglichen, wurden identische Referenznummern, wo möglich, verwendet, um identische Elemente, welche über die Fig. hinweg gemeinsam sind, zu bezeichnen.
Es wird nun auf 1 Bezug genommen; in einer Ausführungsform der vorliegenden Erfindung umfasst ein Netzwerk 10 multiple Vorrichtungen 11, einschließend zumindest eine Client-Vorrichtung 12 und zumindest eine Server-Vorrichtung 14, miteinander verknüpft über eine Kommunikationsverknüpfung 16. Die Kommunikationsverknüpfung 16 kann einen seriellen 1394-Bus einschließen, welcher eine physikalische Schicht (ein Medium) zum Senden und Empfangen von Daten zwischen verschiedenen verknüpften Heim-Vorrichtungen zur Verfügung stellt. Der serielle 1394-Bus unterstützt sowohl Zeit-gebündelte (multiplexed) Audio/Video(A/V)-Streams, als auch Standard-IP(Internetprotokoll)-Kommunikation (beispielsweise IETF RFC 2734). In bestimmten Ausführungsformen verwendet ein Heim-Netzwerk eine IP-Netzwerk-Ebene als die Kommunikationsebene für das Heim-Netzwerk. Jedoch können andere Kommunikationsprotokolle verwendet werden, um eine Kommunikation für das Heim-Netzwerk zur Verfügung zu stellen. Beispielsweise kann die Erfindung implementiert werden unter Verwendung des Function Control Protocols (FCP), wie definiert durch IEC 61883 oder irgendein anderes geeignetes Protokoll. Folglich kann ein Netzwerk allgemein zwei oder mehrere Vorrichtungen einschließen, welche über einen physikalischen Ebenen-Austausch oder Transfer von Daten miteinander verknüpft sind in Übereinstimmung mit einem vorher definierten Kommunikationsprotokoll.
Jede Client-Vorrichtung 12 kann mit einer oder mehreren Server-Vorrichtungen 14 in dem Netzwerk 10 kommunizieren. Des Weiteren kann jede Server-Vorrichtung 14 mit einer oder mehreren anderen Server-Vorrichtungen 14 kommunizieren und einer oder mehreren Client-Vorrichtungen 12 in dem Netzwerk 10. Jede Client-Vorrichtung 12 kann eine Benutzer-Kommunikations-Schnittstelle einschließen, welche Eingabevorrichtungen einschließt, wie z.B. eine Maus und eine Tastatur zum Aufnehmen der Benutzer-Eingabe sowie ein Display zum Bereitstellen einer Steuer-Benutzer-Schnittstelle für einen Anwender, um mit den Netzwerkvorrichtungen zu interagieren. Die Benutzer-Schnittstelle kann eine grafische Benutzer-Schnittstelle (GUI, graphical user interface) 18 zum Bereitstellen von Information für den Anwender einschließen. Jede Server-Vorrichtung 14 schließt Hardware als eine Ressource in dem Netzwerk zum Bereitstellen von Diensten für den Anwender ein und kann des Weiteren einen Server oder ein Dienst-Steuerprogramm 20 zum Steuern der Server-Hardware einschließen.
Jede Server-Vorrichtung 14 stellt einen Dienst für den Anwender zur Verfügung, außer der Steuer-Benutzer-Schnittstelle und jede Client-Vorrichtung 12 stellt einen Dienst zur Verfügung, einschließend die Steuer-Benutzer-Schnittstelle zur Benutzer-Interaktion mit dem Netzwerk 10. Als solche interagieren nur die Client-Vorrichtungen 12 direkt mit dem Benutzer und die Server-Vorrichtungen 14 interagieren nur mit den Client-Vorrichtungen 12 und anderen Server-Vorrichtungen 14. Beispiele für Dienste können MPEG Quelle/Senke (sourcing/sinking) und Display-Dienste einschließen.
In einer exemplarischen Ausführungsform der vorliegenden Erfindung verwendet ein Browser-basiertes Netzwerk (beispielsweise ein Heim-Netzwerk) Internet-Technologie, um Vorrichtungen zu steuern und ihnen Befehle zu übermitteln, einschließend Client-Vorrichtungen und Server-Vorrichtungen, welche mit einem Netzwerk verbunden sind. Jede Vorrichtung schließt Vorrichtungsinformation, wie z.B. Schnittstellendaten (beispielsweise HTML-, XML-, JAVA-, JAVASCRIPT-, GIF-, JPEG-, Grafikdateien oder irgendein anderes Format sinnvoll für den gewünschten Zweck) ein, welche eine Schnittstelle zur Befehlsübertragung und zur Steuerung der Vorrichtung über das Netzwerk zur Verfügung stellt. In bestimmten Ausführungsformen schliesst jedes Gerät Geräteinformationen ein, wie z.B. eine oder mehrere Hypertext Markup Language(HTML)-Seiten, welche die Befehlsübertragung und Steuerung dieser Vorrichtung realisieren. Unter Verwendung der Browser-Technologie setzt das Netzwerk Internet-Standards, um die HTML-Seiten in ihre Reihenfolge zu bringen, um dem Benutzer eine Vielzahl von grafischen Benutzer-Schnittstellen (GUIs) zur Verfügung zu stellen zum Befehlsübertragen und Steuern einer jeden Vorrichtung. In einem Beispiel ist das Netzwerk konfiguriert als ein Intranet.
In einer Ausführungsform umfasst eine Client-Vorrichtung eine Vorrichtung, welche einen Steuer-Schnittstellen-Dienst einem menschlichen Operator zu Verfügung stellt, einschließend eine grafische Display-Hardware zum Herabkommunizieren sowie eine Maus oder irgendeine andere Zeiger- und Anklick-Vorrichtung für die Hin-(oder Her-)Kommunikation. Eine Server-Vorrichtung umfasst ein Modul, welches einen Dienst bereitstellt, welcher irgendein Dienst sein kann, verschieden von einer Steuer-Schnittstelle, zur Ver fügung gestellt von einer Client-Vorrichtung. Als solche ist die Server/Client-Vorrichtung-Beziehung eine Steuerbeziehung, wobei die Server-Vorrichtung einen Dienst zur Verfügung stellt, jedoch eine Client-Vorrichtung, die Daten verwenden kann, wenn ein DTV Videodaten darstellt, jedoch nicht die Daten manipulieren oder verändern muss. Es ist folglich konsistent mit dieser Definition zu betrachten, dass ein Server häufig eine Quelle an Information und ein Client (beispielsweise ein Browser) ein Verbraucher der Information sein kann.
Beispiele von spezifischen Funktionen, welche implementiert werden können durch Server-Vorrichtungen schließen ein: Rückkehr an Informationen (Daten); Leistung einer Funktion (beispielsweise einer mechanischen Funktion) und Rückkehr eines Zustandes; Rückkehr eines Datenstroms und -zustands; Aufnahme eines Datenstroms und Rückkehr eines Status; oder Speichern eines Zustandes für eine nachfolgende Aktion. Beispiele von Server-Vorrichtungen schließen MPEG-Quelle, -Senke und Display-Server ein. Während eine Server-Vorrichtung typischerweise ein maßgeschneidertes, aufgesetztes Steuerprogramm einschließt, um die Steuerung seiner eigenen Hardware zu implementieren, fungiert ein Client als Vermittler mit der Server-Vorrichtung. Jedoch impliziert eine Server-Vorrichtung, wie hier verwendet, nicht, dass ein Web-Server und ein Protokoll-Stapel 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, wie oben beschrieben, verknüpft elektronisch multiple Vorrichtungen 11, einschließend Server-Vorrichtungen 14 (beispielsweise DVD 108, DVCR 110), Client-Vorrichtungen 12 (beispielsweise DTV 102, 103), Brücke 116, DVCR 120, PC 105, Kabel/Modem-Zugang 107 und DBS-Zugang 109 auf dem Netzwerk 100. 3 illustriert ein Beispiel eines geschichteten Schnittstellen-Modells, welches zum Kommunizieren zwischen den Vorrichtungen 11 in Übereinstimmung mit der vorliegenden Erfindung verwendet werden kann. In diesem Beispiel kommuniziert eine Vorrichtung (Server) 150 mit einer Client-Vorrichtung 166 unter Verwendung von einer oder mehrerer der Netzwerk-Kommunikationsebenen 152–164. In einem Beispiel kommuniziert eine Anwendung in der Vorrichtung 150 mit einer Anwendung in der Vorrichtung 166 über die Netzwerk-Ebene 160. Die Details der unteren Ebenen 162 und 164 werden durch die Anwendungen nicht gesehen, wobei die Verwendung beispielsweise entweder von 1394 oder Ethernet keinen Unterschied macht für besagte Anwendungen in den besagten Vorrichtungen 150, 166. Des Weiteren wer den nicht alle der oberen Ebenen des 7-Ebenen-Modells über die ganze Zeit hinweg verwendet (beispielsweise im Netz-Modell (TCP/IP-Modell) werden die Session-Ebene 156 und die Präsentations-Ebene 154 nicht verwendet). Als solche können in einer Version durch Einsatz des Internet-Protokoll-Standards für die Netzwerk-Ebene 160 die Vorrichtungen miteinander kommunizieren, ohne dass spezifische Details über die anderen Kommunikationsebenen bekannt sind (d.h. Anwendung 152, Präsentation 154, Session 156, Transport 158, Daten-Verknüpfung 162 und physikalisch 164). Folglich kann durch Einsatz des Internet-Protocol-Standards für die Netzwerk-Ebene 160 das Netzwerk eine Kombination verschiedener Kommunikationsebenen bei der Kommunikation zwischen verschiedenen Vorrichtungen verwenden.
Eine einzelne physikalische Packung kann mehrere Vorrichtungen einschließen, welche logisch über eine Netzwerk-Ebene miteinander vernetzt sind, wie beispielsweise in 3 gezeigt wird, nicht notwendigerweise über ein physikalisches Netzwerk (beispielsweise können solche Vorrichtungen einen VCR und einen TV in einem einzigen Gehäuse einschließen). Wo eine logische Vorrichtung zu einem GUI Zugang hat, und um einem Benutzer zu ermöglichen, eine Vorrichtung zu steuern, kann die Vorrichtung und die logische Vorrichtung in der gleichen physikalischen Packung eingeschlossen sein. In solch einer Ausführungsform ruft die physikalische Vorrichtung ein GUI von sich selbst ab. Jedoch in anderen Ausführungsformen, verknüpft das Netzwerk separate physikalische Vorrichtungen miteinander, wobei beispielsweise eine erste Vorrichtung ein GUI von einer zweiten Vorrichtung abruft, um die Benutzer-Interaktion mit dem GUI zu ermöglichen, um die zweite Vorrichtung zu steuern.
In einer derzeit bevorzugten Ausführungsform wird ein serieller 1394-Bus verwendet als physikalische Ebene 164 für die Daten-Kommunikationen auf dem Netzwerk 100. Aufgrund seiner verstärkten Bandbreiten-Fähigkeiten (beispielsweise verstärkte und garantierte Bandbreite und isochrone Strom-Fähigkeit) kann der serielle 1394-Bus ein einziges Medium für alle Daten-Kommunikationen auf dem Netzwerk 100 zur Verfügung stellen (d.h. Audio/Video-Ströme und Befehle/Steuerungen).
Des Weiteren stellt der serielle 1394-Bus die automatische Konfigurations-Rückstellung zur Verfügung, so dass, wenn eine Vorrichtung angeschlossen wird oder entfernt wird, alle 1394-Schnittstellen zurückgestellt werden, der 1394-Bus sich rekonfiguriert und jede Vorrichtung das Vorliegen einer jeden anderen Vorrichtung erkennt (einschließend einer neu hinzugefügten oder ohne diejenige, die gerade entfernt wurde). Des Weiteren unterstützt die 1394-Schnittstelle einen Datenraum für Konfigurations-Information, welche adressierbar ist von jeder anderen Vorrichtungen, was es anderen Vorrichtungen ermöglicht, Information zu schreiben oder zu lesen und Modifikationen zu realisieren, beispielsweise die Operation des Netzwerk-Ebenen-Protokolls zu erlauben. Es ist jedoch möglich, diese Ergebnisse mit unterschiedlicher Software und unterschiedlichen Standards zu erzielen. Als solches ist das Netzwerk 100 nicht limitiert auf die Verwendung eines seriellen 1394-Buses und in einer alternativen Ausführungsform der vorliegenden Erfindung können andere Bus-Typen, beispielsweise ein Ethernet, ATM, Wireless, etc. eingesetzt werden als die physikalische Ebene, falls sie die speziellen Durchsatz-Erfordernisse eines individuellen Netzwerks (beispielsweise eines Heim-Netzwerks) erfüllen. Des Weiteren kann eine modifizierte Version beispielsweise ein Wireless-Ethernet die essentiellen Merkmale von 1394 einschließen.
Wie in 2 dargestellt, schließt das Netzwerk 100 verschiedene Vorrichtungen ein, welche mit dem seriellen 1394-Bus 114 verknüpft sind. In diesem Beispiel schließen die Vorrichtungen ein DBSS 104 ein zum Empfangen eines Transmissionssignals von einem Satelliten 122 für die nachfolgende Darstellung. Assoziiert mit dem DBSS ist eine Netzwerk-Schnittstellen-Einheit ("NIU"), welche unter anderem eine Schnittstelle zwischen der DBSS-Satellit-Übertragung und dem seriellen 1394-Bus 114 zur Verfügung stellt.
Ein Digital-Video-Device (DVD) 108 ist auch mit dem exemplarischen Netzwerk 100 verbunden. Die DVD 108 kann verwendet werden, um digital gespeicherte Videos auf einem Fernseher darzustellen. Auch verknüpft mit dem exemplarischen Netzwerk 100 ist ein Digital-Video-Cassette-Recorder (DVCR) 110, d.h. ein digitaler TV 102. In diesem Beispiel stellt der DTV 102 eine menschliche Schnittstelle für das Netzwerk 100 zur Verfügung durch Einsetzen von Browser-Technologie, um dem Benutzer zu ermöglichen, dass er Vorrichtungen über das Heim-Netzwerk 100 steuert bzw. ihnen Befehle überträgt. Ein zweiter DTV 103 stellt eine weitere menschliche Schnittstelle für das Netzwerk 100 zur Verfügung durch Einsetzen von Browser-Technologie, um dem Benutzer zu ermöglichen, über das Heim-Netzwerk 100 Vorrichtungen zu steuern und ihnen Befehle zu übertragen. Die DTVs 102 und 103 können menschliche Schnittstellen für das Netzwerk 100 zur Verfügung stellen, da jedes DTV einen Schirm umfasst zum Darstellen von HTML-Seiten. Jedoch können andere Vorrichtungen mit Display-Fähigkeiten verwendet werden, um menschliche Schnittstellen zur Verfügung zu stellen. Folglich wird in be stimmten Ausführungsformen der Erfindung eine Vorrichtung eingesetzt, wie z.B. ein Personalcomputer 105 (PC), um eine menschliche Schnittstelle zur Verfügung zu stellen für ein entsprechendes Heim-Netzwerk, da ein PC 105 typischerweise eine Schirm-Display-Einheit ausführt.
Der serielle 1394-Bus 114 ist dargestellt als einsetzend das HTTP/IP-Schnittstellenprotokoll und vorzugsweise HTTP/TCP/IP, wobei IP ein Datenpaket-Format zur Verfügung stellt (ein Einwegmodell, auf das Schreiben begrenzt), TCP eine fehlerfreie Version von IP zur Verfügung stellt (beispielsweise sicherstellt, dass Datenpakete ankommen und in der richtigen Reihenfolge sind) und HTTP 2-Wege-Verknüpfung zur Verfügung stellt (Datenpaket zum Server wird eine Antwort erwarten – ein "Lese"-Modell). Bestimmte Vorrichtungen können andere Protokoll-Schnittstellen-Typen verlangen (beispielsweise UPD/IP, FTP/IP, TELNET/IP, SNMP/IP, DNS/IP, SMTP/IP). In bestimmten Ausführungsformen der Erfindung kann ein Proxy 116 eingesetzt werden, um die beiden Netzwerke anzubinden unter Verwendung von einander unähnlichen Schnittstellenprotokollen auf den entsprechenden Medien, welche, wenn sie miteinander verknüpft werden, das Netzwerk 100 umfassen. Der Proxy 116 (beispielsweise Web-Proxy) kann Home-Automation-Type-Protokolle einschließen, wie z.B der HTML/HTTP/TCP/IP-Proxy für X10, Lonworks, CEBus (auf ihren entsprechenden physikalischen Technologien), oder nicht-IP-Protokolle auf 1394 (beispielsweise AVC/FCP/1394).
In bestimmten Ausführungsformen sind die beiden Netzwerk-Medien vom selben Typus. Beispielsweise, wie in 2 dargestellt, ist der serielle 1394-Bus 114, welcher das HTTP/IP-Schnittstellenprotokoll einsetzt, verknüpft durch einen Proxy 116 mit dem Home Automation *.118 (beispielsweise X10). Unter Verwendund des Proxys 116 als HTML/HTTP/CTP/IP/1394-Proxy für VCR-Befehle/AVC/FCP/1394, und zwischen HTML/HTTP/TCP/IP und X10-Protokollen eine Verbindung herzustellen, ist auch ein DVCR 120 in dem Netzwerk 100 zugänglich. In bestimmten anderen Ausführungsformen kann ein Netzwerk zwei Netzwerk-Medien von unähnlichen Typen umfassen, beispielsweise einen seriellen 1394-Bus und Ethernet. Daher wird in bestimmten Ausführungsformen der Erfindung ein Proxy eingesetzt, um zwei unähnliche Medien-Typen aus einem einzigen Netzwerk miteinander zu koppeln. Ein Erkennungsprozess, wie des Weiteren unten beschrieben, kann eingesetzt werden für die Erkennung von Geräten, welche von dem Netzwerk betrieben werden und an das Netzwerk 100 angebunden werden. Es kann auch der gleiche 1394-Bus eingesetzt werden, ohne dass eine Verbrückungs-Box benötigt wird.
Wie in 2 dargestellt, repräsentieren Vorrichtungen 11, welche DTV 102, DTV 103, PC 105, DVCR 110, DVD 108, DSS-NIU 104 und DVCR 120 einschließen, Vorrichtungen, welche laufend mit dem Netzwerk 100 verbunden werden, umfassend ein 1394-Netzwerk. Eine Client-Server-Beziehung existiert zwischen den angebundenen Vorrichtungen mit dem DTV 102, DTV 103 und PC 105, welche sich typischerweise als Clients verhalten und in Vorrichtungen DVCR 110, DVD 108, DSS-NIU 104 und DVCR 120, welche sich als Server verhalten.
Ein typisches 1394-Netzwerk umfasst miteinander verbundene Vorrichtungen, wie z.B. eine Kollektion von Anwendungen, einschließend Server-Vorrichtungen, welche einen oder mehrere Dienste anbieten, welche gesteuert werden müssen (beispielsweise DVCR 100 als einen MPEG-Video-Aufzeichnungs- und Abspieldienst) sowie Client-Vorrichtung, welche einen Benutzer-Schnittstellen(UI, user interface)-Dienst anbieten (beispielsweise DTV 102) zum Steuern der Server-Vorrichtungen. Einige Anwendungen (beispielsweise DTV 103) können beide Dienste aufweisen (beispielsweise MPEG Decodier- und Darstell-Befähigung), welche gesteuert werden müssen, sowie eine UI-Steuer-Befähigung. Entsprechend einem Aspekt der vorliegenden Erfindung werden Verfahren und Systeme, welche Protokolle, Dokumentbeschreibung, Bildkompression und Script-Sprach-Standards von Technologien, welche in dem World Wide Web-Standard (Web-Modell) eingesetzt werden, eingesetzt, um ein 1394er WEB-Benutzer-zu-Device-Steuermodell in dem Netzwerk 100 zu implementieren. Das Web-Modell ist ein Client/Server-Modell. Die gesteuerte Server-Vorrichtung (Dienst) umfasst einen Web-Server und die Steuer-Client-Vorrichtung (d.h. eine Vorrichtung, welche in der Lage ist, ein UI darzustellen), umfassend einen Web-Client, einschließend einen GUI-Präsentations-Motor, der des Weiteren unter beschrieben wird, beispielsweise einen Web-Browser (z.B. Explorer J, NetscapeJ, etc.).
4a zeigt eine Server-Vorrichtung, beispielsweise das DVCR 100, welches MPEG-Video für eine Client-Vorrichtung, wie z.B. den DTV 102 in einem Netzwerk 100 gemäß der vorliegenden Erfindung abspielt, wobei der DTV 102 eine Benutzer-Schnittstelle darstellen kann. Der DVCR 110 schließt Web-Server-Hardware und Software ein und der DTV 102 schließt Web-Browser-Software ein. Ein Benutzer kann den DTV 102 einset zen, um zu verlangen, dass der DTV 102 eine Benutzer-Schnittstelle darstellt, basierend auf der Vorrichtungsinformation 202, enthalten in dem DVCR 110 oder basierend auf der Vorrichtungsinformation 204, enthalten in dem DTV 102. Beispielsweise kann der Benutzer einen Browser 200 in den DTV 102 einsetzen, um eine HTML-Steuerseite GUI 202, enthalten in dem DVCR 110 darzustellen, oder eine HTML-Steuerseite GUI 204, enthalten in dem DTV 102. Jede Seite 202, 204 schließt grafische Benutzer-Schnittstellen-Beschreibungsinformation in HTML ein, wobei der Browser 200 die Information liest, um eine grafische Benutzer-Schnittstelle zu erzeugen. Jede Seite 202, 204 repräsentiert die Steuer-Schnittstelle der Anwendungen 206 bzw. 212. Jede Seite 202, 204 kann eine Hirarchie von Seiten einschließen, um eine korrespondierende Anwender-Steuer-Schnittstelle zu repräsentieren.
Jedes GUI 202 und/oder 204 schließt aktive Steuer-Icons und/oder Buttons für den Benutzer ein, um Vorrichtungen auszuwählen und Vorrichtungen zu steuern, welche laufend mit dem Netzwerk 100 verbunden sind. Falls beispielsweise der Benutzer einen PLAY-Knopf in dem GUI 202 des DVCR 110, dargestellt durch den Browser 200 auf dem DTV 102 auswählt, kommt eine Hyper-Link-Nachricht zu dem DVCR 110 Web-Server zurück und diese ist gerichtet auf eine Anwender-Software 206 (beispielsweise MPEG-Aufzeichnungs-/Abspieldienst-Anwendungssoftware) in dem DVCR 110 zum Betrieb einer DVCR-Hardware 208. In einem Beispiel überträgt eine MPEG-Video-Stromquelle 208 in dem DVCR 110 einen MPEG-Video-Datenstrom an ein MPEG-Video-Decodier- und Darstellsystem 210 in dem DTV 102 zur Darstellung unter der Steuerung der Anwendungs-Steuer-Software 212 in dem DTV 102. Die Anwender-Software 206 in dem DVCR 110 sendet auch Information zurück zur Anwendungssoftware 212 in dem DTV 102, einschließend, beispielsweise eine Bestätigung, falls die Operation erfolgreich ist, oder eine veränderte oder unterschiedliche Steuerung GUI 202 an das DTV 102, welche den Zustand des Benutzers anzeigt. Es kann weitere Kommunikation zwischen den Anwender-Softwaren 206 und 212 geben, beispielsweise zum Aufbau einer 1394-isochronen Video-Datenstrom-Verbindung für einen Video-Datenstrom-Dienst.
4b zeigt ein weiteres Beispiel eines Architekturdiagramms einer Server-Vorrichtung, welche mit einer Client-Vorrichtung kommuniziert und in der Lage ist, eine Benutzer-Schnittstelle in einem Netzwerk 100 darzustellen. Die Server-Vorrichtung, wie z.B. ein DVCR 110, spielt ein MPEG-Video auf der Client-Vorrichtung, wie z.B. dem DTV 102 in dem Netzwerk 100 ab, wobei das DTV 102 eine Benutzer-Schnittstelle darstellen kann.
In einer Ausführungsform der Erfindung basiert das Kommunikationsprotokoll zwischen den Vorrichtungen in dem Netzwerk 100 auf dem Hypertext Transfer Protocol (HTTP 1.1), einem Protokoll auf Anwenderebene für kommerziell vertriebene, miteinander zusammenarbeitende Hypermedien-Informationssysteme. HTTP ist ein generisches, staatenloses, objektorientiertes Protokoll, welches für viele Aufgaben verwendet werden kann. Ein Merkmal von HTTP ist die Typisierung und Übertragung von Daten-Repräsentation, was es Vorrichtungen ermöglicht, unabhängig von den Daten, welche über das Netzwerk 100 übertragen werden, an welche die Vorrichtungen angebunden sind, gebaut zu sein.
Die Beschreibungs-Dokumentsprache zum Definieren verschiedener GUIs 202, 204 kann beispielsweise HTML, Version 4.0 sein, die Veröffentlichungssprache des World Wide Webs. HTML unterstützt Text, Multimedia und Hyperlink-Merkmale, Scripting-Sprachen und Style-Sheets. HTML 4.0 ist eine SGML-Anwendung, welche mit dem internationalen Standard ISO 8879 übereinstimmt – eine Standard-verallgemeinerte Aufzeichnungssprache.
Um Bilder darzustellen, werden drei Grafik-Kompressions-Formate für unbewegte Bilder, spezifiziert durch die HTML-Spezifikation eingesetzt in dem 1394WEB-Netzwerk 100 für ICON, LOGO und andere Grafiken. Die Grafik-Kompressionsformate für unbewegte Bilder sind: Graphics Interchange Format (GIF89s), Progressive Joint Photograhic Experts Group (JPEG) und Portable Netzwerk Graphics (PNG). Tabelle 1 zeigt die Unterschiede in den Fähigkeiten, zwischen diesen drei unterschiedlichen Bild-Kompressionsformaten für unbewegte Bilder.
Tabelle 1
Die Web-Script-Sprache, ECMA-Script-262, eingesetzt, um ein Mittel zur Verfügung zu stellen, um visuell die GUI-Web-Seiten 202 als ein Teil einer Web-basierten Client-Server-Architektur zu verstärken. Die Script-Sprache ist eine Programmiersprache zum Manipulieren, Maßschneidern und automatisieren der Möglichkeiten/Dienste der Vorrichtungen. Die Benutzer-Schnittstelle 200 stellt grundlegende Benutzer-Schnittstellen-Funktionen zur Verfügung und die Script-Sprache wird eingesetzt, um diese Funktionalität zur Programmsteuerung darzulegen. Das existierende System stellt die Host-Umgebung von Objekten und Anlagen zur Verfügung, welche die Möglichkeiten der Script-Sprache vervollständigen. Der Web-Browser 200 stellt die ECMA-Script-Host-Umgebung für Client-seitige Berechnungen zur Verfügung, einschließend beispielsweise Objekte, welche Fenster, Menüs, Pop-Up-Windows, Dialog-Fenster, Textfelder, Anker, Rahmen, Vergangenheit, Cookies und Eingabe/Ausgabe repräsentieren.
Der Web-Browser 200 stellt die Host-Umgebung für das EXMA-Script-262 zur Verfügung und die Host-Umgebung unterstützt das Anbringen des Script-Codes an Ereignisse, wie z.B. die Veränderung des Fokus, Seiten- und Bild-Laden, Löschen, Fehler und Abbruch, Auswahl, Form-Vorlagen und Maus-Aktionen. Der Script-Code ist in den HTML-Seiten 202 und 204 enthalten und die dargestellte Seite in dem Browser 200 schließt eine Kombination von Benutzer-Schnittstelleelementen und fixierten und berechneten Text und Bildern ein. Der Script-Code antwortet auf die Benutzer-Interaktion ohne, dass ein Hauptprogramm benötigt wird.
In einem Beispiel schließt die Beschreibung für einen 1394WEB-Client-Browser 200 eine HTTP1.1-Beschreibung ein, wobei Abschnitt > 8.1.2.1 Übertragung der HTTP1.1-Beschreibung betreffend die Verknüpfungsdauer modifiziert wird, so dass eine HTTP1.1-Client-Vorrichtung, wie z.B. der DTV 102, eine Verbindung an die Server-Vorrichtung erwartet, wie z.B. den DVCR 110 über das 1394, um offen zu bleiben, da die dauerhafte Verknüpfung in der 1394WEB-Benutzer-Steuerung den vollen Status ermöglicht, welcher von der Server-Vorrichtung (DVCR 110) berichtet, während der GUI 202 und/oder 204 sichtbar in dem Browser 200 der Client-Vorrichtung (DTV 102) bleibt. Die HTTP-Verknüpfung bleibt offen (HTTP spec RFC 2068), wobei ein Client, welcher dauerhafte Verknüpfungen unterstützt, seine Anforderung über eine Leitung leiten kann (d.h. multiple Aufforderungen senden kann, ohne auf jede Antwort zu warten). Ein Server muss seine Antworten auf diejenigen Anforderungen in der gleichen Reihenfolge schicken, in welcher die Anforderungen empfangen wurden. Dies ermöglicht dem Web-Browser 200, Anforderungen an das DVCR 110 über eine Leitung zu leiten, welche der DVCR 110 dann später erfüllen kann, beispielsweise mit Zustandsantworten, wie z.B. dem "nun Abspielen", "nun aufzeichnen", "Rückspulen beendet", "Band kaputt", etc. Andere beispielhafte Implementationen schließen z.B. ein, dass die Steuerseite von dem DVCR 110 eine Anforderung enthalten kann, die DVCR 100-Anforderung der GUI-Beschreibung 202 in einer Schleife ablaufen zu lassen.
Der GUI-Präsentationsmotor 200 wird eingesetzt in der Client-Vorrichtung, wie z.B. dem DTV 102, um die GUI-Beschreibungen 202, 204, geschrieben in der HTML4.0-Dokumentbeschreibungssprache und die assoziierten Beschreibungen (unten) zu interpretie ren und die grafische Form für die Anzeige für den Benutzer zu erzeugen. Der GUI-Präsentationsmotor 200 schließt die folgenden beispielhaften Attribute ein: (1) Fenster (GUI), mit minimaler eingestellter Größe von beispielsweise H0 × 640 Pixel (480 × 640, wobei 480 vertikal gilt und 640 horizontal). Diese voreingestellte Größe soll sicherstellen, dass die gewünschte Erscheinung der GUIs 202, 204 an den Benutzer in dem Browser 200 übertragen wird. Die übertragenen GUIs 202, 204 werden in einem Fenster mit 480 × 640 Pixel oder größer vergrößert mit dem gleichen Ansichtsverhältnis dargestellt, solange sie nicht anderweitig durch den Anwender übertragen werden; (2) Kompressionsformate für unbewegte Bilder: beispielsweise GIF89a, JPEG und PNG; (3) Formatvorlagen-Formate und Schriftarten: beispielsweise CSS1 und CSS2; (4) Schriftarten, wie z.B. die Folgenden; beispielsweise werden installierte Schriftarten für die Client-Vorrichtung benötigt, um einfache Server-Anwendungen davor zu bewahren, dass sie solche Schriftarten unterstützen müssen. Mindestens eine Schriftart von jeder generischen Latin-Familie kann ausgewählt werden: beispielsweise Times New Roman, aus der "serif"-Familie; Helvetica, aus der 'sans-serif"-Familie; Zapf-Chancery, von der "Kursiv'-Familie; Western von von 'fantasy'-Familie und Courier, von der 'monospace'-Familie. Andere Schriftarten können auch eingesetzt werden; und (5) Script-Sprache, beispielsweise ECMA-262. Beispiele des GUI-Präsentationsmotors 200 schließen Web Browser, wie z.B. Explorer J und NetscapeJ, konfiguriert/maßgeschneidert, je nach Bedarf, ein.
Eine oder mehrere der Server-Vorrichtungen (beispielsweise ein 1394WEB-Netzwerk, ein gesteuerter Anwender-Web-Server, wie z.B. der DVCR 110) schließen die folgenden sechs aufgelisteten Komponenten ein:

(1) HTTP1.1 Web-Server-Protokoll mit Abschnitt > 8.1.2.1 Negotiation' der HTTP1.1-Beschreibung betreffend eine Verbindung, modifiziert, so dass eine HTTP1.1-Server-Vorrichtung (beispielsweise DVCR 110) annimmt, dass eine a HTTP1.1-Client-Vorrichtung (beispielsweise DTV 102) beabsichtigt, eine dauerhafte Verbindung mit der Server-Vorrichtung aufrecht zu erhalten. Die dauerhafte Verbindung in dem 1394WEB-Netzwerk 100 ermöglicht das volle Zustands-Berichterstatten beispielsweise von der Server-Vorrichtung DVCR 110 an die Client-Vorrichtung DTV 102, während der GUI 202 des DVCR 110 sichtbar in dem Browser 200 des DTV 102 bleibt. Des Weiteren kann ein Verfahren unter Verwendung von http-konditionalem GET, um den letzten Status der Server-Vorrichtungen zu erhalten, eingesetzt werden. Wann immer der Benutzer zu dem Heim-Netzwerk- Verzeichnis zurückkehrt oder veranlasst, dass es aktualisiert wird, zeigt der Browser 200 von neuem die Seite zur Gänze an. Dies ist notwendig, da das HTML, welches dem Heim-Netzwerk-Verzeichnis zugrunde liegt, wieder erneuert worden ist, falls eine Vorrichtung zum Netzwerk 100 hinzugefügt worden ist oder von diesem entfernt worden ist. Es ist auch möglich, für Vorrichtungs-Icons, dass sie aktualisiert werden, um Veränderungen des Betriebszustandes ihrer Vorrichtung zu reflektieren. Als solches setzen Browser, welche durch EIA-775.1-Vorrichtungen implementiert sind, HTTP "conditional get"-Abfragen ein, um zu bestimmen, ob frische Kopien von Web-Seiten oder Grafiken von dem Server erhalten werden sollten oder nicht.
(2) Vorrichtungs-Heim-Seiten GUI-Beschreibungen 202, 204, geschrieben beispielsweise in HTML4.0, schließen Dateien ein, beispielsweise icon.htm-, name.htm-, logo.htm-, index.htm-, gif-Dateien etc. Die Datei index.htm wird durch HTML-Links mit Querverweisen verbunden, einschlossen in Vorrichtung icon.htm- und name.htm-HTML-Dateien, wobei index.htm optional beispielsweise "INDEX.HTML" oder "INDEX.HTM" genannt werden kann. Der Dateiname INDEX.HTM muss nicht als ein Standardname verwendet werden, da die ICON.HTM und NAME.HTM mit Hyperlinks zu dem "INDEX.HTM" erstellt worden sind; daher ist der Name zufällig. ICON.HTM und LOGO.HTM sind Verweise der aktuellen Grafikdateien in der gleichen Vorrichtung, beispielsweise LOGO.GIF und ICON.GIF. Die Beschreibungen 202, 204 sind zugänglich durch die Vorrichtungen (beispielsweise HTTP-Vorrichtungen) in dem Netzwerk 100. Um eine gewünschte Erscheinung zu garantieren, kann das Steuer-GUI-Design von einer voreingestellten GUI-Größe, beispielsweise von 480 × 640 Pixel sein. Beispielsweise kann ein übertragenes GUI 202 in einem Fenster von 480 × 640 Pixel in dem Browser 200 oder größer herausvergrößert in dem gleichen Längen-zu-Breiten-Verhältnis, solange nichts anderes durch den Benutzer vorgegeben wird.
(3) Zumindest zwei Vorrichtungs-ICON-Dateien werden zur Verfügung gestellt, um die Vorrichtung in einer Netzwerkseite auf höchster Ebene 220 (5–6) in dem Browser 200 zu repräsentieren, welche Information über die Vorrichtungen, verbunden mit dem Netzwerk zeigen. Ein ICON kann einen Grafik-Datei-Typus (beispielsweise GIF, JPG oder PNG) umfassen und wird bezeichnet als ICON.HTM. In einem Beispiel verweist ICON.HTM (DVCR) auf die INDEX.HTM-Datei in der HTML-Seite 202 und ICON.HTM (DTV) verweist auf die INDEX.HTM-Datei in der HTML-Seite 204. Die Verknüpfung auf höchster Ebene für die Steuer-Seiten (beispielsweise INDEX.HTM) der Vorrichtung, kann ICON.HTM sein. Der Browser 200 platziert die Icons und Verknüpfungen darin von einer Vielzahl von Vorrichtungen in dem Netzwerk 100 in der HN-Verzeichnis-Seite auf höchster Ebene 220 für die Dienst-Erkennung durch den Benutzer. Anschließend drückt der Benutzer das ICON, dargestellt in der Seite 220 und die Vorrichtungsseite (beispielsweise INDEX.HTM in Seite 202) wird aufgerufen. Das voreingestellte dargestellte HN-Verzeichnis ist die Erkennungsseite auf höchster Ebene. Eine Vielzahl von zusätzlichen und unterschiedlichen grafischen Icons kann eingesetzt werden, beispielsweise um den Vorrichtungs-Status zu repräsentieren, die Benutzer-konfigurierten Voreinstellungen oder Hersteller-Formate, welche anstelle der Icon-Grafik substituiert werden können. In einem Erkennungsprozess, wie des Weiteren unten beschrieben, werden ICONs von den Vorrichtungen, verbunden an das Netzwerk 100, zusammengesammelt und dargestellt in der Netzwerk-Vorrichtungs-Seite auf höchster Ebene 220 zur Auswahl durch einen Benutzer. Eine Beispiels-Vorrichtungs-ICON-Beschreibung umfasst: den Datei-Namen ICON.HTM, zugänglich durch den HTTP-Server (Dateinamen sind in einem Verzeichnis-Daten-Raum, zugänglich durch den Web-Server, so dass sie abgerufen werden können und über das Netzwerk an den Browser weitergeleitet werden können); grafische Dateitypen, wie z.B. GIF, JPG oder PNG; und Icon-Grafik mit einer maximalen Größe von 70(V) × 130(H) Pixel.
(4) Zumindest zwei Vorrichtungs-LOGO-Dateien werden zur Verfügung gestellt, um die Vorrichtung in der Netzwerk-Vorrichtungsseite auf höchster Ebene zu repräsentieren. LOGO kann einen Grafik-File-Typus (beispielsweise GIF, JPG oder PNG) umfassen und wird bezeichnet als LOGO.HTM. In einem Beispiel verweist LOGO.HTM (DVCR) auf das INDEX.HTM in der HTML-Seite 202 und LOGO.HTM (DTV) verweist auf das INDEX.HTM in der HTML-Seite 204. In einer Version kann die Verknüpfung für die Steuerseiten auf höchster Ebene (beispielsweise INDEX.HTM) der Vorrichtung LOGO.HTM sein. Alle Vorrichtungs-Logos werden in der HN-Verzeichnisseite 220 auf höchster Ebene zur Diensterkennung durch den Benutzer platziert. Anschließend drückt der Benutzer das LOGO, dargestellt in der Seite 220 und die Vorrichtungsseite (beispielsweise 202) wird aufgerufen. Ei ne Vielzahl von zusätzlichen unterschiedlichen Grafiken für Herstellerdienste können anstelle des Logo-Grafik-Formats substituiert werden. Gemäß dem Erkennungsprozess werden LOGOs von Vorrichtungen, verbunden mit dem Netzwerk 100 zusammengesammelt und dargestellt in der Netzwerk-Vorrichtungsseite auf höchster Ebene 220 zur Auswahl durch einen Anwender. Eine Beispiel-Vorrichtungs-LOGO-Beschreibung umfasst: den Dateinamen LOGO.HTM, zugänglich durch den HTTP-Server; Grafik-File-Typen, wie z.B. GIF, JPG oder PNG; und eine maximale Logo-Grafik-Größe von ungefähr 70(V) × 130(H)-Pixel.
(5) Zumindest ein Vorrichtungs-NAME wird zur Verfügung gestellt, um die Vorrichtung zu repräsentieren in der Netzwerk-Vorrichtungs-Seite auf höchster Ebene. NAME umfasst TEXT in einer HTML-Datei NAME.HTM. Dieser Text kann auch auf Steuerseiten (beispielsweise 202) verweisen. Dies ist eine Verknüpfung auf höchster Ebene in der Erkennungsseite, um die Schnittstelle der Vorrichtung zu steuern. Der Text stellt einen Weg zur Verfügung, um identische Vorrichtungen zu unterscheiden, wobei beispielsweise zwei identische DTV's unterschieden werden können durch Addition von NAME-Text "Schlafzimmer-TV" und "Wohnzimmer-TV". Der Text kann einige wenige Worte umfassen, um klar den Vorrichtungstyp, beispielsweise DVCR oder DTV zu repräsentieren. Gemäß dem Entdeckungsprozess werden NAMEn für Vorrichtungen, verbunden mit dem Netzwerk, zugänglich, zusammen mit den korrespondierenden ICONs/LOGOs und in der Netzwerk-Vorrichtungens-Seite auf höchster Ebene 220 unter dem ICON/LOGO dargestellt. Ein Beispiel für eine NAME-Beschreibung umfasst Folgendes: den Dateinamen NAME.HTM, zugänglich durch den HTTP-Server; einen unspezifischen Text; beispielsweise mit der Schriftgröße 10 können zwei Zeilen an Text dargestellt werden unter dem korrespondierenden ICON/LOGO. Daher kann beispielsweise die Blattgröße für den NAME.HTM-Text 20 vertikal mal 130 horizontal sein, um zum ICON/LOGO zu passen (70 vertikal × 130 horizontal). Wie durch das Beispiel in 5–6 gezeigt, kann das Format des UI auf höchster Ebene 220 eine Matrix von Icons umfassen, welche die Funktionen der per Netzwerk verbundenen Vorrichtungen für den Benutzer repräsentiert. Der Name, welcher die Vorrichtung repräsentiert (aus name.htm) wird platziert unter dem Icon (aus icon.htm) von der gleichen Vorrichtung. Logo (aus logo.htm) kann platziert werden beispielsweise in irgendeiner freien Icon-Position. Da die Beschreibung auf höchster Ebene 250 (beschrieben des Weiteren unten in Verbindung mit den 9a–c) unabhängig durch UI-fähige Vorrichtungen erzeugt wird, muss das exakte Design nicht im Vorhinein angeordnet werden. Die Icon-, Logo- und Namen-Maximalgrößen können im Vorhinein angeordnet werden, um das Design der GUI-Matrix zu ermöglichen.
(6) Ein Vorrichtungs-Informations-Zusammenfassungs-Homepage-Beschreibungs-Dokument, geschrieben in HTML4.0 kann zur Verfügung gestellt werden, beispielsweise mit der Bezeichnung "info.html" oder "info.htm" und zugänglich gemacht werden durch den HTTP-Server für den Erkennungsprozess. Eine Verknüpfung kann zur Verfügung gestellt werden zur INFO.HTM-Information über Steuerseiten, beispielsweise 202, 204. Die Vorrichtungs-informations-Zusammenfassungs-Homepage stellt dem Benutzer eine Vorrichtungszusammenfassung zur Verfügung anstelle der detaillierten Steuer-Schnittstelle, wie in der Vorrichtungs-Homepage gezeigt. Tabelle 2 zeigt Text für Vorrichtungsattribute, welche eingeschlossen sind und andere, welche eingeschlossen sein können. Diese Tabelle kann erweitert werden, um andere Attribute einzuschließen.

Tabelle 2
Tabelle 2 schließt Vorrichtungs-Zusammenfassungs-Information, wie z.B. Hersteller-Name, Hersteller-Logo-Bild-Name ein und kann des Weiteren eine URL des Herstellers einschließen als Hilfe, falls eine verfügbare Internetverknüpfung zu der Web-Seite des Herstellers verfügbar ist. Tabelle 2 kann des Weiteren einen Benutzer-einstellbaren Vorrichtungs-Namen und einen Benutzer-einstellbaren Vorrichtungs-Namen in dem Haus einschließen. Es kann mehrere Variationen des Vorrichtungs-Icons geben, repräsentierend verschiedene Zustände der Vorrichtung. Das Vorrichtungs-Icon-Attribut-Feld schließt den Namen des laufenden Icons ein. folglich kann die Vorrichtungs-Zusammenfassungs-Informations-Seite die unmittelbare Vorrichtungs-Zustands-Information dem Benutzer zur Verfügung stellen durch Anzeigen des Icons, welches für den derzeitigen Zustand steht.
Jede Vorrichtung kann einen oder mehrere Dienste einschließen, beispielsweise Video-Datenstrom-Quelle oder Video-Datenstrom-Ziel. Jedes Quellpotenzial hat ein komplementäres, voreingestelltes Zielpotenzial und jedes Zielpotenzial hat ein komplementäres voreingestelltes Quellpotenzial. Dieser voreingestellte Datenstrom-Namen-Eintrag kann verwendet werden beispielsweise, um automatisch den am nächsten gelegenen DTV voreinzustellen, dass er das Ziel ist, wenn ein DVCR als Quelle gesteuert werden wird, um zu eliminieren, dass der DTV zu jeder Zeit ausgewählt werden muss. Ein Hintergrund-Quervernetzen des Datenstrom-Voreinstellungs-Namen mit der 1394-Adresse wird zur Verfügung gestellt. Die Video-Datenstrom-Dienste werden durch die 1394-Schnittstelle selbst zur Verfügung gestellt (nicht durch das Web-Modell). Als solche gibt es eine Verknüpfung der Voreinstellungsquelle oder Senke zu dem 1394-Adressenmechanismus. Der Anwender kann eine Vorrichtung zugänglich machen und einen Namen für die Voreinstellung auswählen, welcher dann auf der Vorrichtung gespeichert wird. Der Software-Agent der Vorrichtung muss die 1394-Adresse finden und Parameter für die 1394 s/w, um den voreingestellten Datenstrom zu ermöglichen, wenn er benötigt wird.
Unter Verwendung der Quell- und Ziel-Dienstattribute können neue Server/Dienste implementiert werden, während die Kompatibilität mit dem existierenden Host oder der existierenden Vorrichtung (Knoten) und Diensten aufrechterhalten wird. Falls beispielsweise eine neue Server-Vorrichtung, welche einen neuen Dienst zur Verfügung stellt, entwickelt wird, welche kompatibel ist mit einer existierenden Server-Vorrichtung, können beide, der neue und der existierende Server, zu der Attributenliste des neuen Knotens hinzugefügt werden, während die Kompatibilität mit existierenden Knoten erhalten bleibt, unter Verwendung des existierenden Servers in dem Netzwerk 100. Der Benutzer kann eine kompatible Vorrichtung, welche käuflich erworben werden kann, auswählen. Diese liefern dem Benutzer "IN ETWA"-Information, um das Potenzial der existierenden Ausrüstung zu überprüfen, beispielsweise bevor neue Ausrüstung gekauft wird, wo Kompatibilität gewünscht ist.
Ein Erkennungsprozess für jede Vorrichtung, welche den 1394WEB-Standard unterstützt (beispielsweise Vorrichtungen, welche in der Lage sind, eine Benutzer-Schnittstelle anzuzeigen) faltet Vorrichtungsinformation von Vorrichtungen, verknüpft mit dem Netzwerk 100, um die Benutzer-Steuer-Seiten-Beschreibung für das Heim-Netzwerk zu erzeugen, wobei jede Vorrichtung repräsentiert wird durch eine grafischen Icon-Verweis und eine Text-Namen-Referenz, wie im Detail oben erläutert. Die Beschreibung auf höchster Ebene kann eine voreingestellte Seite einschließen für einen Präsentations-Motor, wie z.B. einem Browser 200, wobei der Browser 200 die grafischen Bilder sammelt und Namen für die Vorrichtungen, wenn er die grafische Netzwerk-Benutzer-Schnittstelle 220 (GUI) auf höchster Ebene erzeugt, dargestellt in dem Browser 200, wie beispielsweise in den 5–6 gezeigt. Die dynamisch erzeugte HN-Verzeichnisseite auf höchster Ebene 220 wird zur voreingestellten Seite für den Browser (die erste Seite, die angezeigt wird, wenn der Browser geöffnet wird).
Unter Verweis auf 4b schließen die Betriebsschritte eines Beispiels ein: (1) der Browser 200 in der Vorrichtung 102 wird geöffnet, (2) Der Browser 200 ruft auf und präsentiert HN-Verzeichnis HTM (UI auf höchster Ebene) von der Seite 204, (3) der Browser 200 ruft die HTM-Dateien icon.htm und names.htm von den Seiten 202, 204 auf und präsentiert sie in dem UI auf höchster Ebene, (4) der Browser 200 ruft alle Grafikdateien (beispielsweise GIF) von den Seiten 202, 204 auf und präsentiert sie in dem UI auf höchster Ebene, (5) der Browser 200 ist dann in der Lage, die vollständige HN-Verzeichnisseite 220 zu präsentieren (Seite 220 wird mit den Hyperlinks zu den "INDEX.HTM"-Dateien für unterschiedliche Vorrichtungen erzeugt, welche mit dem Netzwerk 100 verbunden sind) und (6) wenn ein Benutzer beispielsweise das DVCR-Icon in GUI 220 drückt, um den DVCR 110 zu steuern, wird ein korrespondierender Hyperlink in der Seite auf höchster Ebene 220 zu "INDEX.HTM" von dem DVCR 110 verwendet, um das "INDEX.HTM" (oberste Steuerseite von DVCR) von Seite 202 in dem DVCR 110 wieder aufzurufen und präsentiert die DVCR-Steuerseite dem Benutzer (beispielsweise falls der Rahmen, welcher angeklickt worden ist (beispielsweise der icon.htm-Rahmen) nicht groß genug ist, wird eine Grafik präsentiert in einer weiteren Kopie des Browsers mit der Voll-Rahmen-Größe). Der Benutzer kann dann Befehle übermitteln und den DVCR 110 steuern unter Verwendung der Steuer-Schnittstelle, bereitgestellt durch "INDEX.HTM" der DVCR-Vorrichtung 110, präsentiert durch den Browser 200 in dem DTV 102.
Der Name "INDEX.HTM" ist zufällig, da das ICON.HTM und NAME.HTM mit Hyperlinks zu dem "INDEX.HTM" erzeugt wurden. Jedoch verweisen ICON.HTM und LOGO.HTM auf tatsächliche Grafikdateien (beispielsweise LOGO.GIF und ICON.GIF) in den gleichen Vorrichtungen. In einer Ausführungsform kann LOGO.HTM optional sein, falls ein Logo für eine Vorrichtung optional ist. Die HN-Verzeichnis-HTML-Datei kann ein Standard-Namen aufweisen, so dass sie von einer anderen Vorrichtung aufgerufen werden kann.
5–6 zeigen, dass die Host-Vorrichtung, wie z.B. eine Client-Vorrichtung (beispielsweise DTV 102, HDTV1) oder Server-Vorrichtung (beispielsweise DVCR 110), welche die GUI-Seite 220 auf höchster Ebene erzeugt und präsentiert, eine Priorität annehmen können und ein Icon von größerer Größe für das Icon der Host-Vorrichtung, den entsprechenden Namen, das Logo etc. In einer Version werden nur Vorrichtungen mit Servern (Dienste, welche angeboten werden) in dem GUI 220 angezeigt (eine "Client-Vorrichtung" umfasst eine Vorrichtung mit Client-Potenzial, wobei, wenn sie nur ein Client ist, dann wird sie nicht angezeigt in dem GUI auf höchster Ebene, da sie keinen Dienst anzubieten hat). Der Erkennungsprozess liest Information von dem 1394-Adressen-Raum-Daten-Speicher (Konfiguration-ROM-Struktur), wie in Bestimmung 8 von ISO/IEC 13213 definiert. Obwohl als "ROM" bezeichnet, wird angenommen, dass der Adressraum beschreibbar ist, um dem Benutzer die Konfiguration und Modifikation von Benutzer-relevanten gespeicherten Werten zu ermöglichen. Die Inhalte der Konfigurations-ROM und der Erkennungsprozess werden des Weiteren unten beschrieben.
Vorrichtungs-Namensgebung, Adressierung und Erkennungsprozess für Heim- oder lokale Netzwerksteuerung für Verbraucher/Vorrichtungen unter Verwendung von Internet-, Web- und 1394-Technologie können sich unterscheiden von den Anforderungen und der Praxis im allgemeinen Internetraum. Als solche werden entsprechend einem Aspekt der vorliegenden Erfindung für die Heim- oder lokale Netzwerksteuerung, für Verbraucher-Vorrichtungen spezielle Prozesse einschließend, Vorrichtungs-Erkennung, Adressierung und Namensgebungserfordernisse eingesetzt. Beispielsweise muss das Heim-Netzwerk vollkommen funktionieren, ohne das Vorliegen von externen Kommunikationen und Diensten, ohne Netzwerk-Administrator und die Konfiguration muss vollkommen automatisch sein. Die Benutzer-Steuerung kann in vielen Fällen vollkommen Tastatur-frei sein. Des Weiteren wird das IEEE1394-Protokoll eingesetzt, um eine intelligente Schnittstelle zur Verfügung zu stellen, welche Merkmale einschließt, welche einfache, effiziente und überlegene Erkennungs- und Konfigurationsfunktionen zur Verfügung stellen können.
7 zeigt ein Blockdiagramm eines Netzwerks 300, konstruiert in Übereinstimmung mit einer Ausführungsform der vorliegenden Erfindung. Um das Verständnis zu erleichtern, wurden identische Referenznummern verwendet, womöglich, um identische Elemente zu bezeichnen, welche gemeinsam sind über all die Figuren, die hier vorkommen. Wie in 7 dargestellt, verknüpft ein serieller 1394-Bus 114, wie oben beschrieben, elektronisch multiple Vorrichtungen, einschließend Server-Vorrichtungen 14 (beispielsweise DVD 108, DVCR 110) und Client-Vorrichtungen 12 (beispielsweise DTV 102) auf dem Netzwerk 100, wie oben beschrieben unter Verweis auf 2, wobei die Vorrichtungen kommunizieren unter Verwendung des geschichteten Schnittstellenmodells des Beispiels von 3, wie oben beschrieben.
Das Netzwerk 300 ist nicht begrenzt auf die Verwendung eines seriellen 1394-Buses und in alternativen Ausführungsformen der vorliegenden Erfindung können andere Bus-Typen, beispielsweise Ethernet, ATM-Wireless, etc. eingesetzt werden als die physikalische Ebene, falls sie die speziellen Durchsatz-Anforderungen eines individuellen Netzwerkes erfüllt sind (beispielsweise eines Heim-Netzwerkes). Wie in 7 dargestellt, schließt das Netzwerk 300 mehrere Vorrichtungen ein, verknüpft an den seriellen 1394-Bus 114. In diesem Beispiel schließen die Vorrichtungen ein DBSS 104 ein zum Empfangen von Übertragungssignal von einem Satelliten 122 für nachfolgende Darstellung. Assoziiert mit dem DBSS ist eine Netzwerk-Schnittstelleneinheit ("NIU", network interface unit), welche unter anderem eine Schnittstelle zur Verfügung stellt zwischen der DBSS-Satellitenübertragung und dem seriellen 1394-Bus 114. Ein Digital-Video-Device (DVD) 108 ist auch mit dem beispielhaften Netzwerk 300 verbunden. Das DVD 108 kann eingesetzt werden als Quelle für digital kodierte Videos zur Darstellung beispielsweise auf einem digitalen Fernseher. Auch verbunden mit dem exemplarischen Netzwerk 100 ist ein digitaler Video-Kasetten-Rekorder (DVCR, digital video cassette recorder) 110, ein digitaler TV (DTV) 102. In diesem Beispiel stellt der DTV 102 eine menschliche Schnittstelle für das Netzwerk 300 zur Verfügung durch Einsetzen von Browser-Technologie, um den Benutzern zu ermöglichen, Vorrichtungen zu steuern und an sie Befehle zu übertragen über das Heim-Netzwerk 300. Ein zweiter DTV 103 stellt eine weitere menschliche Schnittstelle für das Netzwerk 100 zur Verfügung durch Einsetzen von Browser-Technologie, um den Benutzern zu ermöglichen, die Vorrichtungen über das Heim-Netzwerk 100 zu steuern und an sich Befehle zu übertragen. Die DTVs 102 und 103 können menschliche Schnittstellen für das Netzwerk 300 zur Verfügung stellen, da jeder DTV einen Schirm zum Darstellen von HTML-Seiten umfasst. Jedoch können andere Vorrichtungen mit Display-Fähigkeiten verwendet werden, um menschliche Schnittstellen zur Verfügung zu stellen. Folglich wird in bestimmten Ausführungsformen der Erfindung eine Vorrichtung, wie z.B. ein Personal-Computer 105 (PC) verwendet, um eine menschliche Schnittstelle für ein entsprechendes Heim-Netzwerk zur Verfügung zu stellen, da ein PC 105 typischerweise eine Schirm-Darstellungseinheit ausführt.
Der serielle 1394-Bus 114 ist dargestellt als einsetzend das HTTP/IP-Schnittstellenprotokoll und vorzugsweise HTTP/TCP/IP, wobei IP ein Datenpaket-Format zur Verfügung stellt (ein Einwegmodell, auf das Schreiben begrenzt), TCP eine fehlerfreie Version von IP zur Verfügung stellt (beispielsweise sicherstellt, dass Datenpakete ankommen und in der richtigen Reihenfolge sind) und HTTP 2-Wege-Verknüpfung zur Verfügung stellt (Datenpaket zum Server wird eine Antwort erwarten – ein "Lese"-Modell). Bestimmte Vorrichtungen können andere Protokoll-Schnittstellen-Typen verfangen (beispielsweise UPD/IP, FTP/IP, TELNET/IP, SNMP/IP, DNS/IP, SMTP/IP). In bestimmten Ausführungsformen der Erfindung kann ein Proxy 116 eingesetzt werden, um die beiden Netzwerke anzubinden unter Verwendung von einander unähnlichen Schnittstellenprotokollen auf den entsprechenden Medien, welche, wenn sie miteinander verknüpft werden, das Netzwerk 300 umfassen.
Beispielsweise, wie in 7 dargestellt, ist der serielle 1394-Bus 114, welcher das HTTP/IP-Schnittstellenprotokoll einsetzt, verknüpft durch einen Proxy 116 mit dem Home Automation *.118 (beispielsweise X10). Unter Verwendung des Proxys 116 als HTML/HTTP/CTP/IP/1394-Proxy für VCR-Befehle/AVC/FCP/1394, und zwischen HTML/HTTP/TCP/IP und X10-Protokollen eine Verbindung herzustellen, ist auch ein DVCR 120 in dem Netzwerk 300 zugänglich.
In dieser Ausführungsform kann das Netzwerk 300 verknüpft sein mit einem externen Netzwerk 119 eines unähnlichen Typus (beispielsweise Ethernet) an dem seriellen 1394-Bus über einen Bus 121. Ein Proxy 117 wird verwendet, um die beiden unähnlichen Medien-Typen aneinander anzubinden. Zur Kommunikation zwischen dem Adress-Schema des externen Netzwerkes 119 und dem Adress-Schema des Netzwerks 300 umfasst die Brücke 117 eine Netzwerk Address Translation(NAT)-Grenze. Diese Technik kann eingesetzt werden für LAN's von Firmen und ist ein "divide and conquer"-Ansatz für das komplexe Problem des Erfüllens von verschiedenen unterschiedlichen IP-Adress-Erfordernissen eines Netzwerkes und verhindert das "Ausgehen von IPV4"-Adressen. Das externe Netzwerk kann beispielsweise Kabel-TV-Netzwerk 115 via Ethernet an ein Telefon, beispielsweise ADSL) einschließen, welches eine Breitbandverknüpfung mit dem Internet und WWW bereitstellt. Das Ethernet 119 stellt eine Brückenfunktion für das externe Netzwerk zur Verfügung. Die Brücke 117 oder Ethernet 119 können die NAT-Adress-Konversionsfunktion zur Verfügung stellen. Falls das Ethernet lokales privates (nur nach Hause) Adressieren zur Verfügung stellen soll (beispielsweise wie durch den IETF-Standard RFC 1918 definiert), dann ist die NAT-Funktion in dem Ethernet 119. Existierende Kabel-Modems werden mit einer globalen Adresse und auch einer globalen Internetadresse für den PC aus dem Ethernet ausgerüstet (in diesem Fall ist das NAT in der Brücke 117).
Nun werden das oben beschriebene Benennen, Adressieren und die Entdeckungsprozesse der Vorrichtung für das Netzwerk 300 beschrieben. Die Vorrichtungs-Benennung, Punkt- und Anklick-Web-Operation (beispielsweise unter Verwendung von GUI/Web) benötigt keine Namensdienste (DNS, Domain Name Service). Das Web GUI stellt eine abstrakte Ebene zur Verfügung und die Adressen sind verborgen als Hypertext-Verknüpfungen, aufgerufen durch das Anklicken des Anwenders an aktive GUI-Flächen (beispielsweise Buttons). Jede Veränderung der Vorrichtungen in dem lokalen Netzwerk 300 bewirkt, dass die Erkennungs-GUI-Seite 200 auf höchster Ebene (5–6) durch den Browser 200 neu erzeugt wird (4a–b), was den Status der Vorrichtungen in dem Netzwerk 300 zu der Zeit repräsentiert und durch die Voreinstellung präsentiert für den Benutzer zur unmittelbaren Verwendung.
Für eine Vorrichtung-zu-Vorrichtung-Steuerung wird ein unterschiedlicher Look-up-Dienst eingesetzt für mehr als Namen (beispielsweise Dienst-Look-up und Anwendungs-Look-up). Als solches kann DNS nicht die notwendigen Merkmale für die Vorrichtung-zu-Vorrichtung-Steuerung zur Verfügung stellen. Jedoch kann eine Vorrichtung (beispielsweise ein 1394-verknüpfter PC) auf einen DNS-Dienst, wie üblich, zugreifen. DNS wird nicht benötigt zur Erkennung oder zum Betrieb von Vorrichtungen/Diensten innerhalb des Hauses, jedoch wird der DNS(Name zu Adresse)-Look-up-Dienst benötigt für externe Zugriffe, beispielsweise von einem PC. Wenn ein Name, beispielsweise "www.yahoo.com" in einen Browser eingetippt wird, findet der Look-up statt nach der IP-Adresse des Yahoo-Computers, d.h. 216.32.74.52, da das Internet (sogar das Haus-Internet) mit Adressen operiert.
Für eine 775WEB-UI-Vorrichtung, welche einen Agent einschließt zum Erzeugen der HN-Verzeichnis-GUI-Beschreibung auf höchster Ebene, und auch einen Zugang einschließt zu dem speziellen Firmen-Web-Server, beispielsweise homewideweb.com (IP-Adresse) gilt, dass sie auch die DNS-Adress-Kenntnis aufweisen kann. Die DNS-Server-Computer-IP-Adresse kann irgendeine IP-Adresse sein unter der Steuerung des Herstellers. Effektiverweise ist die DNS-Adresse in der Vorrichtung angegeben (oder kann aktu alisiert werden, falls der Agent akutalisierungsfähig gestaltet wird und später aktualisiert wird).
Zum Adressieren der Vorrichtung kann in einer Ausführungsform der Erfindung der Einsatz von fixierten IP-Adressen von einem großen Adressraum die einfachste und am meisten verlässlichste Netzwerk-Konfiguration bewirken und der fertig zugängliche ROM-Daten-Raum in der 1394-Schnittstelle ermöglicht den Einsatz von fixierten IP-Adressen darin. In einer anderen Ausführungsform der Erfindung können nicht-fixierte (dynamische) IP-Adressen eingesetzt werden, wobei eine Abstraktionsebene (beispielsweise Namen- oder Look-up-Mechanismen) eingesetzt wird, um vor-organisierte Kommunikationen zu erhalten.
Für die IP-Adress-Konfiguration können die folgenden Protokolle eingesetzt werden: (1) Dynamic Host Configuration Protocol (DHCP) mit DHCP-Servern und DHCP-Clients, (2) DHCP-Clients ziehen sich auf Auto-Konfiguration zurück (DHCP-Server liegt nicht vor) und (3) vorzugsweise FWHCP (Fire-Wire Host Configuration Protocol) Server-Agent(en) und FWHCP-Clients, wie des Weiteren unten beschrieben wird. Die Auto-Konfiguration in (2) oben ist diejenige, vorgeschlagen als ein IETF-Vorschlag "draft-ieff-dhc-ipv4autoconfig-04.txt".
DHCP benötigt Unterstützung durch das BOOTP/UDP-Protokoll und repliziert, was innerhalb der 1394-Beschreibung getan wird und stellt Merkmale zur Verfügung, wie z.B. Miet-Zeit und dynamisches Adressieren. Typischerweise benötigt DHCP das Management durch einen Administrator und muss konfiguriert werden und adaptiert werden an Netzwerk-Erfordernisse von in Massen hergestellten Verbraucher-Elektronik-(CE, consumer electronics)-Anwendungen, wobei beispielsweise multiple identische CE-Anwendungen mit DHCP-Server-Installationen betrachtet werden müssen.
Die 1394-Technologie stellt "Plug-in"- oder "Power-up"-Rückstellung und folgende "Self-ID"-Sequenzen zur Verfügung, die gut geeignet sind dür die Netzwerk-Konfiguration. Des Weiteren stellt die 1394-Beschreibung einen built-in "ROM"-Adress-Raum zur Verfügung, der gut geeignet ist zum Speichern von und zum Zugang zu Konfigurationsdaten (beispielsweise IP-Adressen). Als solche werden in einer bevorzugten Ausführungsform der Erfindung, ein IP-Adress-Konfigurations-Agent (FWHCP) und eine Erkennungsseite zur Benutzersteuerung von 1394-Vorrichtungen eingesetzt. FWHCP stellt die IP- Adresskonfiguration für 1394WEB und 1394-Vorrichtungen zur Verfügung. Der Zweck und das Ergebnis von FWHCP ist ähnlich zu DHCP (d.h. ein Server, um lokale IP-Adressen zu identifizieren und zu bestätigen), jedoch benutzt FWHCP beim Betrieb Daten im 1394-Adress-Raum und 1394-Befehle. FWHCP stellt die IP-Adress-Konfiguration von 1394WEB-Vorrichtungen auf dem 1394-Netzwerk zur Verfügung, was Kollisionen mit Vorrichtungen auf benachbarten, angebundenen Netzwerken, verschieden von 1394 vermeidet. Vorrichtungen werden hergestellt mit einer eingebauten IP-Adresse aus dem 10.x.x.x-Bereich. In dem unwahrscheinlichen Fall einer Kollision setzt FWHCP eine neue IP-Adresse und speichert sie in der Vorrichtung.
DHCP/Auto-Konfiguration kann eingesetzt werden für Geräte auf Netzwerken, verschieden von 1394. Das DHCP-Protokoll stellt die vom Client "angeforderte IP-Adresse" zur Verfügung. Vorzugsweise wird der angeforderte IP-Adressraum ausgewählt aus dem oberen Teil des 24 Bit-RFC1918-Bereiches (10.128.1.1 bis 10.254.254.254). Durch Auswählen von Teilen des erlaubten privaten Adressbereiches für 1394 IP-Adressen und eines weiteren Teils für andere Konfigurationsverfahren (beispielsweise DHCP und DHCP/Auto-Konfiguration) werden dann kompatible und nicht miteinander wechselwirkende Adressen erzeugt für ein heterogenes Netzwerk, was erlaubt, dass FWHCP und DHCP miteinander coexistieren. Während das Auswählen von nicht überlappenden IP-Adressen für 1394 und benachbarte Netzwerke wünschenswert ist, wird das heterogene Netzwerk unter Verwendung von FWHCP erfolgreich konfiguriert, selbst wenn sie sich überlappen. Auch DHCP-Clients überprüfen ihre zugeordnete IP-Adresse mit einer Test-ARP-Nachricht, bevor sie sie verwenden. Als solche können unterschiedliche Adress-Konfigurationsverfahren erfolgreich miteinander coexistieren.
Unter Verweis auf 8 wird ein Beispielprozess gemäß der vorliegenden Erfindung zur Kommunikation zwischen einem 1394-Netzwerk (beispielsweise Netzwerk 300) und einem nicht-1394-Netzwerk (beispielsweise Ethernet 119) zur IP-Adress-Konfiguration beschrieben. In diesem Fall setzt das 1394-Netzwerk 300 die FWHCP-Konfiguration ein und das nicht-1394-Netzwerk 119 setzt die DHCP-Konfiguration oder ein anderes Verfahren ein. Im Allgemeinen unterstützen 1394-Vorrichtungen (beispielsweise DTV und DVCR in 7) DHCP nicht. Die 1394-VORRICHTUNG-3 für die 1394-Netzwerk-zu-nicht-1394-Netzwerk-Kommunikation schließt eine IP-Adresse in dem 1394 ROM-Raum ein und stellt Unterstützung für FWHCP für eine 1394-Vorrichtung zur Verfügung. Die VORRICHTUNG-3 schließt des Weiteren Mittel ein zum Unterstützen der Konfigurati onsmechanismen auf dem nicht-1394-Netzwerk und hält ein Extensions-Daten-Blatt in dem 1394-ROM-Raum für IP-Adressen von Vorrichtungen in dem nicht-1394-Netzwerk aufrecht. Als solche können Konfigurationsprozesse (beispielsweise FWHCP für die UI-Beschreibungserzeugung auf höchster Ebene) auf dem 1394-Netzwerk 300 die Anwendung von IP-Adressen auf dem nicht-1394-Netzwerk einschließen durch Auswählen von IP-Adressen aus dem Extensions-Daten-Blatt. Die nicht-1394-Netzwerkkonfiguration operiert so, dass sie die IP-Adressen für das 1394-Extensions-Datenblatt zur Verfügung stellt.
Entsprechend dem Erkennungsprozess (Agent) wird 1394-Beschreibungs-"plug-in"-Rückstellung und selbst-ID eingesetzt zur Konfiguration und kann für IP-Adress-Konfiguration verwendet werden. Vorzugsweise wird das fixierte IP-Adressieren für Heim-Netzwerke eingesetzt, jedoch kann auch das dynamische IP-Adressieren eingesetzt werden. DNS ist nicht vonnöten innerhlb der 1394WEB-Steuerung, da eine GUI-Beschreibung auf höchster Ebene erzeugt wird mit Hypertext-Verknüpfungen, welche IP-Adressen anstelle von Namen verwenden. Vorzugsweise wird der IP-Konfigurationsagent (FWHCP) für das 1394-Netzwerk eingesetzt für die IP-Konfiguration unter Verwendung von 1394 ROM-Daten und 1394-Befehlen, jedoch kann auch DHCP eingesetzt werden. FWHCP setzt die untere Hälfte von RFC1918 10.LH.X.X-Adressen ein und andere Heim-Netzwerke (nicht 1394) verwenden die obere Hälfte 10.UH.X.X. Vorzugsweise ist der FWHCP-Server-Agent in irgendeine Vorrichtung eingebaut, welche ein Client (Steuerinitiator) sein kann. Wo verschiedene Client-Vorrichtungen an das 1394-Netzwerk verknüpft sind, arbeitet nur die Client-Vorrichtung mit der höchsten (GUID). GUID umfasst eine Nummer, eingebaut in die Schnittstelle. Falls es multiple FWHCP-Agents gibt, die auf dem 1394WEB-Netzwerk verfügbar sind, dann gibt es einen initialen Selbst-Auswahl-Prozess, um das eine zu bestimmen, welches arbeiten wird und alle anderen bleiben ruhig. Das höchste GUID wird arbeiten. In anderen Versionen kann das höchste Bit-reversed-GUID eingesetzt werden.
Eine Vorrichtung, welche eine Verbindung zu einem Nicht-1394-Netzwerk herstellt, unterstützt ein ROM-Extensionsblatt von IP-Adressen auf dem Nicht-1394-Netzwerk. Dies ermöglicht den Einschluss der IP-Adressen auf das Nicht-1394-Netzwerk in den 1394-GUIs auf höchster Ebene (beispielsweise 4a–b, GUIs 202, 204). Steuerdaten-Bits in dem 1394-ROM-Raum werden verwendet, um den Betrieb der drei Konfigurations- Agents zu steuern: (1) 1394SelfID Count, (2) IP-Konfiguration FWHCP und (3) UI-Beschreibungserzeugung, wie des Weiteren unten beschrieben.
Anfangs erkennt 1394 Self-ID Count die Existenz von Vorrichtungen. Nach einer Bus-Rückstellung (verursacht durch Hoch-/Herunterfahren einer Vorrichtung oder Anbindung oder Abkoppelung einer Vorrichtung) erkennt die 1394-Software in der Vorrichtung den automatischen Konfigurationsprozess (1394-selbst-ID-Zyklen) für den Zweck des Zählens der Zahl an Geräten. Dies ist ein normaler Teil einer 1394-Software für jede 1394-Vorrichtung. Anschließend untersucht die IP-Konfiguration FWHCP (wie eine selbst ausgewählte FWHCP) die entdeckten Vorrichtungen und überprüft ihre eingebaute IP-Adresse. Entdeckte doppelte (kollidierende) IP-Adressen werden außer Kraft gesetzt und eine neue Adresse wird der Vorrichtung zugeordnet. Anschließend liest der UI-Beschreibungs-Erzeugungs-Agent (UI oder andere Vorrichtungen) alle 1394WEB-Vorrichtungs-IP-Adressen und erzeugt eine Vorrichtungs-Verzeichnis-Grafik-Benutzer-Schnittstellen-Datei auf höchster Ebene in HTML aus Icon-Seiten auf höchster Ebene aus jeder Vorrichtung, die später durch einen Web-Browser zur Benutzer-Erkennung von Vorrichtungen zur Steuerung erzeugt wird.
Entsprechend der vorliegenden Erfindung kann jede Vorrichtung in dem 1394-Netzwerk 400 seine eigene Netzwerk-UI-Beschreibung auf höchster Ebene 250 (9c) erzeugen. Die UI-Beschreibung 250 wird eingesetzt durch einen Präsentations-Motor, wie z.B. den Browser 200 in einer Client-Vorrichtung, um die Verzeichnisseite auf höchster Ebene zu erzeugen und anzuzeigen, beispielsweise die Seite 220 in den 5–6. Nachdem der 1394-Selbst-ID-Agent alle Vorrichtungen nummeriert hat, welche an das 1394-Netzwerk 300 angeschlossen sind, wird die UI-Beschreibung 250 separat durch alle UI-Vorrichtungen (und Nicht-UI-Vorrichtungen wenn gewünscht) erzeugt. Eine Vorrichtung (beispielsweise DTV) kann ein hervorstechenderes (beispielsweise größeres) Icon auswählen, um die Vorrichtung zu repräsentieren und kann verursachen, dass das gesamte GUI 220 ein unterschiedliches Aussehen bekommt. Diese Technik stellt eine substanziell verlässlichere Operation zur Verfügung als ein zentral erzeugtes GUI zum Betrieb von allen Geräten, da jedes Gerät seine eigene UI-Beschreibung 250 erzeugen kann und ein GUI anzeigt (beispielsweise die Seite auf höchster Ebene 220), basierend darauf, ohne eine Abhängigkeit von einer weiteren Vorrichtung. In jeder UI-Beschreibung 250 werden Vorrichtungs-Icon und Logo-Bilddateien der Vorrichtungen laufend mit dem Netzwerk 300 verknüpft und auf sie wird verwiesen durch Icon- und Logo-HTML-"Seiten" und Namen- Text, verpackt in einer HTML-Seite (ICON. "Graphic" mit dem Verweis ICON.HTM liegt in Seiten 202 und 204 vor, welche auch die Steuerseiten für die Vorrichtung einschließen; 5 unten zeigt auch die ICON.HTM, LOGO.HTM und NAME.HTM in einer Verzeichnisseite auf höchster Ebene). HTML-Rahmen werden verwendet, um die Verzeichnis-UI-Beschreibung auf höchster Ebene 250 für Netzwerk-Vorrichtungen in einer jeden Netzwerk-Vorrichtung nach Wunsch zu erzeugen.
Als solche wird in vorteilhafter Art und Weise eine sinnvolle Ebene der Abstraktion zur Verfügung gestellt, um die Verwendung von alternativen Dateinahmen oder -typen zu ermöglichen, beispielsweise für Identifikations-Grafiken in den Netzwerk-Vorrichtungen, ohne dass die Beschreibung auf höchster Ebene 250, erzeugt in einer jeden Vorrichtung, geändert werden muss. Der Namen-Text wird auch in einer HTML-Beschreibung 202, 204 platziert (NAME.HTM liegt in den Seiten 202, 204 vor), was einem Benutzer ermöglicht, den Namen-Text in einem Gerät, beispielsweise DTV zu konfigurieren, beispielsweise DTV zu verändern in beispielsweise DTV-BED2, durch eine der Vorrichtungs-GUI-Seiten 220. Als solche wird die Seite 220 angezeigt, wenn der Browser nach einem Reset aufgerufen wird. Der Benutzer sieht und klickt die DVCR ICON-Grafik an, wobei das DVCR-Steuer-GUI auf höchster Ebene 202 aufgerufen wird (mit dem "Abspiel"-Button etc.). Der Benutzer klickt einen der Button an, beispielsweise"Konfiguriere den Vorrichtungs-NAMEN", was ein weiteres GUI ist (aus der Hierarchie von Steuer-Seiten für DVCR) mit einer großen Auswahl von unterschiedlichen Namen.
Der Benutzer klickt einen Namen aus der Liste von bereitgestellten Namen an, beispielsweise "Master-Schlafzimmer-DVCR".
Die Software auf der Vorrichtung verändert die Dateinamen, so dass die Datei mit der Bezeichnung NAME.HTM den Text "Master-Schlafzimmer-DVCR" enthält (die alte voreingestellte NAME.HTM-Datei, welche den DVCR enthielt, wird in einen anderen Namen umbenannt).
Die Erscheinung des GUI 220 ist stabiler im Fall von "schlechten Bürger-"(bad citizen)-Vorrichtungen, welche zu viel oder übergroßen Text oder übergroße Logos aufweisen. In diesem Fall isolieren die Rahmen das Problem und verhindern, dass die schlechten Abschnitte das Erscheinungsbild des gesamten GUIs auf höchster Ebene 220 nachteilhaft beeinflussen.
Nun wird auf 9a–c und 10, 11 Bezug genommen und Beispiele von funktionellen Blöcken und Verbindungen mit Daten- und Steuer-Bits und ein Flussdiagramm einer Ausführungsform einer System-Architektur 400 für den oben genannten Entdeckungsprozess werden gezeigt. Das System 400 umfasst vier primäre Elemente: (1) einen nicht-volatilen 1394-Speicherraum (IEEE1212R ROM) 402 für Konfigurations-Daten- und Steuerdaten-Bit-Speicherung; (2) einen 1394-Gerät-Entdeckungs-Agent (1394DDA) 404; (3) einen IP-Adress-Konfigurations-Agent (FWHCP) 406; (4) einen UI-Beschreibungs-Erzeugungs-Agent 408 und (5) eine GUI-Erzeugungs- und Laufzeitumgebung 410 (beispielsweise Web Browser 200 in 2). Des Weiteren zeigt die 10 ein Beispiel für ein Flussdiagramm für die DDA- und FWHCP-Agenten im System 400, welches in Verbindung mit den funktionellen Blöcken in 9a–c funktioniert. Des Weiteren zeigt 10 ein Beispiel eines Flussdiagramms für den UIDGA-Agenten in System 400, welche in Verbindung mit den funktionellen Blöcken in 9a–c funktioniert.
Nun wird auf 9a und 10 Bezug genommen und alle Vorrichtungen schließen den 1394-Vorrichtungs-Erkennungs-Agenten (1394DDA) 404 ein, um die Vorrichtungen auf dem 1394-Bus zu nummerieren nach einem Reset und den Wert in den lokalen 1394 ROM-Raum 402 zu schreiben zum Kommunizieren des Wertes mit anderen funktionellen Agenten (Schritte 500, 502). Für den synchronisierenden (inhibierenden) Beginn anderer Konfigurations-Agenten setzt der 1394DDA-Agent 404 auch die "Konfigurationsbetreibenden" Steuer-Bits. Der Erkennungs-Agent/Mechanismus kann Mittel verwenden, verschieden vom ROM-Raum, um Information zwischen dem Konfigurations-Agenten zu kommunizieren, welche lokal für eine Vorrichtung sind und wo die Information nicht durch andere Vorrichtungen gesehen werden muss.
Alle Vorrichtungen in dem Netzwerk 300 schließen die folgende Information ein, relevant für die Erkennung bzw. IP-Adresse-Agenten 404 bzw. 406 für das 1394WEB in dem 1394-Konfigurations-ROM 402: (1) eine eingebaute 64 Bit GUID (Global Unique ID, in der 1394-Beschreibung); (2) eine eingebaute IP-Adresse von dem RFC 1918-privaten Adressraum in dem Bereich "10.1.1.1" bis "10.127.254.254". Hersteller können einen Wert auswählen von dem GUID, so dass die Chance einer Kollision minimiert wird. Der obere Abschnitt des privaten Adress-Raumes (d.h. 10.128.1.1 bis 10.254.254.254) ist reserviert für Vorrichtungen auf verbrückten Netzwerken; (3) eine zugeordnete IP-Adresse in dem Bereich "10.1.1.1" bis "10.127.254.254" (zugeordnet durch den betrei benden FWHCP-Agenten 406); (4) ein IP-Adresse-Extensions-Blatt für IP-Dienste auf verbrückten Netzwerken; (5) die zugeordnete Zahl von 1394-Vorrichtungen (zugeordnet durch den 1394DDA-Agenten 404); (6) Steuer-/Status-Bits, um die Configuration-in-Progress Synchronization-Steuerung für den 1394-Vorrichtungs-Erkennungs-Agenten 404 anzuzeigen und die IP-Address-Konfiguration anzuzeigen (die Steuer-Bits zeigen, dass die Konfiguration läuft und daher werden die Werte in den ROM-Daten verschieden von den Steuer-Bits für die 1394DDA und IP-Adresse nicht überprüft oder nicht geschrieben und folglich sollten sie nicht verwendet werden). Die Bits zeigen des Weiteren, welche IP-Adresse gültig ist (zugeordnet oder eingebaut) und ob ein FWHCP-Server-Agent 406 in der Vorrichtung vorliegt; (7) einen HTTP-Web-Server, um den Dateien in dem Datenraum der Vorrichtung zu ermöglichen, dass auf sie ständig zugegriffen werden kann; und (8) Vorrichtungsinformation 202, 204 einschließend tatsächliche "Icon"-, "Namen-" und "Logo"-HTML-Dateien und andere Verweis-Grafik-Dateien, welche durch den Web-Server zugänglich werden. Die oben genannte zusammengefasste Information liegt im Detail in der 1394-ROM-Raum-Beschreibung unten vor.
Der Inhalt der allgemeinen 1394ROM-Struktur 402 wird spezifiziert in IEEE1212r, IEEE1212 und IEC61883. Die ROM-Struktur 402 ist eine Hierarchie von Informationsblöcken, wobei die Blöcke, die höher in der Hierarchie sind, auf die Blöcke unterhalb von ihnen zeigen. Die Stelle des Anfangs-Blocks ist fixiert, während andere Einträge Händlerabhängig sind, jedoch durch Eintragungen innerhalb der höheren Blöcke spezifiziert werden können.
Tabelle 3 zeigt den Bus_Info_Block und das Haupt_Verzeichnis des Konfigurations-ROM 402. Das erste Byte eines jeden Eintrages ist als ein Schlüssel bekannt und identifiziert den Typ des Eintrags. Das Folgende kann in das Konfigurations-ROM aller Vorrichtungen implementiert werden unter Verwendung der EIA-775-Beschreibungen, einschließend Display-Vorrichtungen, wie z.B. DTVs und Quell-Vorrichtungen, wie z.B. DVCRs, STBs, etc. Es kann verschiedene andere Strukturen geben, welche benötigt werden, basierend auf anderen Protokollen, mit welchen jede Vorrichtung zusammenpasst. Tabelle 3 schließt die Information für eine Vorrichtung ein, welche auch mit dem IEC61883-Protokoll kompatibel ist. Das Haupt_Verzeichnis enthält Hinweise auf ein Modell_Verzeichnis und drei Einheit_Verzeichnis-Einträge (IEC61883, EIA-775 und 1394WEB), um anzuzeigen, dass die Vorrichtung EIA-775-, wie auch 1394WEB-Protokolle unterstützt. Die Haupt_Verzeichnis-Einträge sind bedeutsam für andere 1394-Vorrichtungen, um die Protokolle und die Software (auch genannt Dienste) zu erkennen, die durch diese 1394-Vorrichtung unterstützt werden.
Tabelle 3 Abstand [Offset] (Basisadresse FFFF F000 0000) Bus_Info-block Abstand [Offset]
Wobei 04 OC₁₆ und 04 10₁₆ auch als die 64 Bit GUID oder Global Unique ID bekannt sind.
Haupt_Verzeichnis Abstand
Das IEC_61883-Einheits_Verzeichnis ist in Tabelle 4 gezeigt. Auf dieses Verzeichnis wird per Verweis hingewiesen durch den Einheits_Verzeichnis-Abstand in dem Haupt_Verzeichnis (beispielsweise Haupt_Verzeichnis-Tabelle). In dem Ein heits_SW_Versions-Feld spezifiziert das am wenigsten signifikante Bit AV/C (0), wie spezifiziert in IEC 61883.
Tabelle 4 Einheits_Verzeichnis (IEC_61883)
Das EIA-775 Einheits-Verzeichnis ist in Tabelle 5 gezeigt. Die folgende EIA-775-spezifische Information erscheint in dem EIA-775 Einheits-Verzeichnis.
Tabelle 5
Die Einheits_Beschreibungs-ID spezifiziert die Identität der Organisation, verantwortlich für die architekturelle Schnittstelle der Vorrichtung und die Beschreibung. Im Fall dieses Beispiels bezieht sich das Verzeichnis und der Identität-Wert = 005068₁₆ auf das EIA als das verantwortliche Gehäuse und die EIA-775 Steuer-Architektur-Beschreibung.
Tabelle 6
Das 1394WEB-Einheits-Verzeichnis ist in Tabelle 7 gezeigt. Die Folgende 1394WEB-spezifische Information erscheint in dem 1394WEB-Einheits-Verzeichnis.
Tabelle 7
Die Einheits_Beschreibungs_ID spezifiziert die Identität der Organisation, verantwortlich für die architekturale Schnittstelle der Einheit und der Beschreibung. Im Fall dieses Beispiels beziehen sich das Verzeichnis und der Identitäts-Wert = OOXXXX₁₆ auf das verantwortliche Gehäuse und die 1394WEB-Steuer-Architektur-Beschreibung.
Die Einheit_Software_Version bezeichnet das 1394WEB-Revisionsniveau, unterstützt durch die Vorrichtung. Das Format ist in Tabelle 8 gezeigt.
Tabelle 8
Der Schlüsselwert (38₁₆), erlaubt durch den IEEE1212R-Beschreibungsabschnitt 8.8 für die private Anwendung durch den Benutzer des Verzeichnisses und die Architektur wird verwendet für den unmittelbaren Wert der Erkennungs_Steuer_Bits.
Tabelle 9
Dies sind Steuer-Bits in dem 1394 ROM-Raum 402, zugänglich durch lokale und ferngesteuerte Vorrichtung. Die Steuer-Bits werden verwendet durch den IP-Adress-Konfigurations-Agent 406 und den Benutzer-Schnittstellen-Beschreibungs-Erzeugungs-Agent 408, wie des Weiteren unten beschrieben.
In einer Ausführungsform der vorliegenden Erfindung stellen besagte Steuer-Bits die folgende Information zur Verfügung:
Bit 0 – Welche IP-Adresse – zeigt, welche IP-Adresse verwendet wird oder in Gebrauch ist, d.h. die eingebaute Adresse (= FALSCH) oder die zugeordnete Adresse (= WAHR). Dies wird eingestellt durch den Betriebs-IP-Konfigurations-Agent FWHCP 406.
Bits 1, 2 – Konfigurations-Betrieb „verwende nicht" – zeigen, wenn sie gesetzt sind, an, dass die 1394-Vorrichtungs-Erkennung und auch – separat – die IP-Konfigurations-Agenten 404 bzw. 406 in Betrieb sind und folglich die Werte, auf die Bezug genommen wird, nicht gültig sind, da sie sich verändern können oder noch nicht geschrieben sind. Diese Bits werden gesetzt durch den lokalen (Vorrichtung) 1394DDA-Agent 404. Der 1394DDA-Agent 404 klärt das 1394-Vorrichtungs-Zahl-Bit und der Betriebs-FWHCP-Agent 406 klärt das IP-Adress-Bit.
Bit 3 – Vorliegen von FWHCP Server-Agent 406 – wird gesetzt, falls sie Vorrichtung einen operablen FWHCP-Agent 406 aufweist. Dieses Bit und GUID werden verwendet durch die FWHCP-Agenten 406, um zu bestimmen, welcher FWHCP-Agent 406 in Betrieb sein wird.
Zugeordnete_Zahl_von_1394_Vorrichtungen (39₁₆) – Zugeordneter unmittelbarer Wert der Anzahl von 1394-Vorrichtungen in dem Netzwerk 300. Diese Zahl wird erzeugt, wenn die 1394-Schnittstelle durch ihre Selbst-ID-Zyklen geht. Der 1394 Vorrichtungs-Erkennungs-Agent 404 erzeugt den Wert, welcher im ROM-Raum 403 gespeichert wird für die nachfolgende Anwendung durch die IP- und UI-Konfigurations-Agenten 406 bzw. 408.
IP_Adresse_eingebauter (3A₁₆) – zugeordneter unmittelbarer Wert. Diese Adresse wird bei der Herstellungszeit zugeordnet und in das Gerät eingebaut. Falls diese eingebaute Adresse nicht verwendet werden kann, kann eine alternative Adresse in dem zugeordneten Adress-Raum gespeichert werden und das Steuer-Bit eingestellt werden, um eine solche anzuzeigen.
IP_Adresse_zugeordnet (3B₁₆) – zugeordneter unmittelbarer Wert. Falls identische IP-Adressen festgestellt werden, ordnet der IP-Adressen-Konfigurations-Agent FWHCP 406 diese Adresse zu, um eine Kollision zu vermeiden. Des Weiteren wird das Steuer-Bit so eingestellt, dass eine solche angezeigt wird.
IP_Adresse_Extensions-Blatt_für_angebundenes_Netzwerk (BC₁₆) – Dieser Verzeichnis-Eintrag ist für den Adress-Abstand des Datenblattes für die IP-Adress-Extensions-Tabelle, siehe Tabelle 10. Das Datenblatt enthält IP-Adressen für Vorrichtungen auf verbundenen nicht-1394-Netzwerken (können aber auch verbrückte 1394-Netzwerke sein). Die Tabelle ist in Kommunikationsvorrichtungen von Typen (beispielsweise Brücke) eingeschlossen, welche mit fremden (nicht-1394)-Netzwerken eine Verbindung herstellen. Die Tabelle kann expandiert werden, um viele IP-Adressen je nach Bedarf einzuschließen. Die Adresse der Kommunikationsvorrichtung selbst sollte nicht in der Tabelle enthalten sein.
Tabelle 10
Was die Steuerung für ein Wort für die Erkennungs-Steuerungs-Bits anbelangt, arbeitet die Verwendung eines ROM-Eintrags für das tatsächliche Erkennungs-Steuer-Bit-Wort, wie hier definiert, ist jedoch ein Beispiel für eine Implementation, da ROM nicht konzipiert ist, um effizient geschrieben zu werden (d.h. ROM-Flächen müssen gelöscht werden und ihr Beschreiben ist langsam, relativ zu anderer Hardware, beispielsweise Register).
Register werden in der 1394-Hardware zur Verfügung gestellt für Daten, welche häufig geschrieben werden müssen. In einer anderen Version kann ein 1394-Register verwendet werden für das "Erkennungs_Steuer_Bit"-Steuerungs-Wort. Register liegen in einem Raum, der auch adressierbar ist von anderen Vorrichtungen, wobei eine andere Vorrichtung in dem ROM die Adresse des Registers nachschauen kann und dann zu diesem Register schreiben kann.
Nun wird auf 9b Bezug genommen, wo eine oder mehrere Vorrichtungen einen IP-Adresse-Konfiguration-Agent (FWHCP) 406 einschließen (beispielsweise alle UI-Vorrichtungen und Gateway-Vorrichtungen und jede andere Vorrichtung, welche ein Steuer-Initiator sein kann). Der FWHCP-Konfiguration-Agent 406 greift auf alle IP-Adress-Vorrichtungen zu in den Daten in dem 1394 ROM 402 über das 1394-Netzwerk 300. Für den Beginn der Synchronisation und die Vervollständigung des Beginns von anderen Anwendungen (beispielsweise die UI-Beschreibungs-Erzeugung) greift der FWHCP-Agent 406 auch auf die "Konfigurations-Betriebs"-Steuerungs-Bits zu.
Nun wird auf 9c Bezug 9c Bezug genommen, wo Vorrichtungen, die in der Lage sind, Benutzer-Schnittstellen anzuzeigen und auch andere Vorrichtungen (beispielsweise Gateway-Vorrichtungen) den UI-Beschreibungs-Erzeugungs-Agent (UIDGA) 408 zum Erzeugen der UI-Beschreibung auf höchster Ebene 250 in beispielsweise HTML einschließen können. Da, wie oben detailliert erläutert wurde, nur ein IP-Konfigurations-Agent 406 pro Netzwerk 300 in Betrieb ist, müssen nicht alle Vorrichtungen einen IP-Konfigurations-Agent 406 enthalten, obwohl alle Vorrichtungen einen IP-Konfigurations-Agent 406 einschließen können. Falls eine Vorrichtung den IP-Konfigurations-Agent 406 aufweist, der in Betrieb ist, und eine Benutzer-Schnittstellen-Vorrichtung ist, dann sollte der IP-Konfigurations-Agent in Betrieb sein vor dem UI-Beschreibungs-Erzeugungs-Agent. Der UI-Beschreibungs-Erzeugungs-Agent (UIDGA) 408 benutzt Information, einschließend Steuer-Bits, definiert in dem 1394-ROM-Raum 402 und andere Information (beispielsweise zum Bestimmen, welches FWHCP, das in Betrieb ist, die Global Unique ID (GUID) des Bus_Infor_Blocks von Tabelle 3 ist) zum Bestimmen, welche IP-Konfigurations-Agent 406 (falls multiple im Netzwerk vorliegen) im Betrieb ist, den Beginn zu synchronisieren und für den Zugriff auf die in Verwendung befindlichen IP-Adressen. Jegliche Vorrichtung kann einen UIDGA aufweisen und betreiben zum Erzeugen der HN_Verzeichnis-Seite (Erkennungsseite auf höchster Ebene). Nachdem die IP-Adressen konfiguriert sind, liest UIDGA die Adressen, um die HN_Verzeichnis-Seite zu erzeugen. In jeder Client-Vorrichtung verwendet, wenn die UI-Beschreibungs-Erzeugung vollständig ist, die GUI-Erzeugung und die Laufzeitumgebung 410 (beispielsweise Web-Browser 200 in 2) das UI-Beschreibung-HTML-Verzeichnis 250, um auf den HTTP-Daten-Raum aller Verzeichnisse zuzugreifen für Icons, Namen und Logos (Icon.HTM, Name.HTM und Logo.HTM sind in den Seiten 202 und 204 enthalten), um das GUI auf höchster Ebene 220 zur Darstellung in dieser Client-Vorrichtung zu veranlassen. Der Web-Browser verwendet HTML-Datei 250, um die tatsächlichen GUI-Grafiken zu erzeugen in dem Prozess des Zugreifens auf Dateien von den Vorrichtungen, beispielsweise Icon.HTM, Name.HTM und Log.HTM und wiederum beim Zugriff auf jegliche zusätzliche Dateien verweisen diese Dateien beispielsweise ICON.GIF und LOGO.GIF auf.
Nun wird Bezug genommen auf 9a–c 10, wie oben diskutiert, wo jede 1394WEB-Vorrichtung in dem Netzwerk 300 den Vorrichtungs-Erkennungs-Agent 404 einschließen kann. Der Vorrichtungs-Erkennungs-Agent 404 nummeriert die 1394 Vorrichtungen in dem 1394-Adressraum, verbunden mit dem 1394-Bus, wobei die bloße Erkennung durchgeführt wird in der 1394-Hardware. Die Selbst_ID und physikalische Knoten-Nummer-Zuordnung und die Schritte, welche dazu führen, bilden den grundlegenen Erkennungsprozess, durchgeführt in der Schnittstellen-Hardware/Firmware. Alle Vorrichtungen überwachen die Selbst_ID-Zyklen und machen eine Notiz der Existenz der 1394-Vorrichtungen. Dies ist ein Teil der 1394-Software für jede 1394-Vorrichtung: (1) Reset-Bus-Reset breitet sich über alle Schnittstellen aus, beim Vorrichtungs-Einschalten, Vorrichtungs-Ankoppeln und Vorrichtungs-Abkoppeln, (2) Baum-Identifikation – transformiert eine einfache Netz-Topologie in einen Baum, um eine Wurzel zu etablieren, welche den Master für bestimmte Funktionen darstellt: Bus-Zyklus-Master, höchste Priorität bei der Entscheidung für Bus-Zeit, (3) Selbst-Identifikation – ordnet die physikalische Knoten-Nummer (Adresse) zu und tauscht auch Geschwindigkeitspotenziale mit Nachbarn aus. Der am höchsten nummeriert Knoten mit dem Contender-Bit als auch dem Link-on-Bit ist der isochrone Ressourcen-Manager.
Der Erkennungs-Agent 404 schreibt den letztendlichen Nummern-Wert der Vorrichtungen in den 1394 ROM-Raum, um ihn mit anderen Agents zu kommunizieren. Der Vorrichtungs-Erkennungs-Agent 404 ist der erste Software-Agent, der ausgeführt wird nach einem 1394-Reset-Zyklus und Steuerungs-Bits (Erkennungs-Steuer-Bits 2 und 1, Konfigurations-Betrieb: 1394DDA und IP_Adresse) werden verwendet, um andere Agents zu verzögern, einschließend die Konfigurations-Agents 406 und 408 in ihrer Durchführung, bis der Erkennungs-Agent 404 die Durchführung beendet hat.
In einer Ausführungsform führt der 1394DDA-Agent 404 in jeder Vorrichtung die Schritte 500, 502 durch, einschließend: (1) Setzen von Synchronisierungs-Steuer-Bits (d.h. "1394DDA in Betrieb" und "IP-Konfiguration in Betrieb" Bits) in dem eigenen 1394 ROM-Raum einer Vorrichtung 402, um anzuzeigen, dass der 1394DDA in Betrieb ist und die IP-Konfiguration in Betrieb ist (IP-Konfiguration wird nicht in Betrieb sein, falls 1394DDA ausgeführt wird) und dass die Werte der 1394-Vorrichtungs-Zahl und der IP-Adresse nicht gültig sind, wodurch besagte Steuer-Bits andere Agenten daran hindern (beispielsweise 408), dass sie zu früh in Betrieb sind; als solches wird das 1394DDA ausgeführt, anschließend ein ausgewähltes FWHCP ausgeführt und dann (üblicherweise für eine UI-Vorrichtung) wird UIDGA ausgeführt; (2) Zählen der Anzahl von 1394 Selbst-Identitäts-Sequenzen nach einem 1394-Reset, um die Anzahl von Vorrichtungen zu erkennen und ihre lokalen Knoten-Adressen zur Verwendung durch andere Agenten 406, 408 effektiv zu machen; (3) Schreiben des Vorrichtungs-Zahlenwertes in den eigenen 1394 ROM-Speicher der Vorrichtung 402; und (4) Klären (beispielsweise nach falsch) des Synchronisierungs-Steuer-Bits für "1394DDA in Betrieb" in dem eigenen 1394 ROM der Vorrichtung 402, wobei das "IP-Konfiguration in Betrieb"-Bit gesetzt bleibt und später geklärt wird durch Betrieb des FWHCP-Agent 406.
Alternative Architektur zur Konfiguration mit der IP-Adress-Liste in der Netzwerk-Kommunikations-(Brücken)-Vorrichtung ist möglich. Beispielsweise kann die IP-Adress-Liste von IP-Adressen von Vorrichtungen auf einem verbrückten (beispielsweise nicht 1394-)Netzwerk alternativ untersucht werden in dem IP-Konfigurations-Zustand durch den FWHCP-Agent 406, anstelle von nur im UIDGA-Zustand durch den UIDGA-Agent 408. Dies ermöglicht, dass der FWHCP-Agent 406 Adress-Kollisionen entdeckt und korrigiert und ermöglicht folglich den Betrieb, ohne dass zwei unterschiedlich definierte Adress-Räume vorliegen, einer für das 1394 Netzwerk 300 und einer für das Nicht-1394 Netzwerk 119. Die Korrektur von Adress-Kollisionen kann realisiert werden durch Modifizie ren der Adresse einer kollidierenden 1394-Vorrichtung, da die verbrückte Netzwerk-IP-Adressenliste nicht modifiziert werden kann durch die oben genannten Agenten 406, 408 für das 1394 Netzwerk 300. Konfiguration ist verlässlicher, falls der FWHCP-Agent 406 die Adressen in dem verbrückten Netzwerk 119 für eine Kollision überprüfen kann, bevor erlaubt wird, dass die Adressen in dem 1394 Netzwerk 300 verwendet werden.
Nun wird auf 9a–c, 10 Bezug genommen, wo der IP-Adresse-Konfiguration-Software-Agent (FWHCP) 406 in Betrieb ist, um ein "fixiertes" IP-Adresse-Management zur Verfügung zu stellen und IP-Adresse-Widersprüche in den Massen-produzierten 1394-Vorrichtungen aufspüren und korrigieren kann. Alle 1394WEB-UI-Vorrichtungen schließen einen FWHCP-Agent 406 ein und andere Vorrichtungen können einen einschließen. Nur ein FWHCP-Agent 406 ist allerdings in dem Netzwerk in Betrieb. Der 1394DDA 404-Agent ist der erste Software-Agent, der ausgeführt wird nach einem 1394-Reset-Zyklus und wie oben erwähnt, setzt der 1394DDA 404-Agent die "1394DDA in Betrieb" und "IP-Konfiguration in Betrieb"-Bits so, dass der FWHCP-Agent 406 verzögert wird, bis der 1394DDA-Agent 404 den vollständigen Ablauf durchgeführt hat.
In einer Ausführungsform führt der IP-Adress-Konfigurations-Agent 406 in einer Vorrichtung Schritte durch, einschließend das Auswählen des 1394DDA-Konfigurations-Betriebs-Steuer-Bits (d.h. des "1394DDA in Betrieb"-Bits), um zu bestimmen, ob der 1394DDA-Konfigurations-Software-Agent 404 den vollständigen Ablauf durchgeführt hat. Falls dies der Fall ist, dann verwendet der FWHCP-Agent 406 die Zahl der Vorrichtungen, bestimmt durch den 1394DDA-Agent 404 und liest GUID"s und Steuer-Wörter aus jeder Vorrichtung (Schritt 504), um zu bestimmen, welche Vorrichtung in dem Netzwerk 300 ausgewählt ist, um seinen FWHCP-Agent 406 auszuführen (Schritt 506). Die ausgewählte Vorrichtung ist eine mit einem FWHCP-Agent 406, welcher findet, dass er die höchste GUID aufweist (Schritt 508). Alle anderen FWHCP-Agenten 406 in anderen Vorrichtungen bleiben im Ruhezustand (Schritt 510). Der in Betrieb befindliche FWHCP-Agent 406 liest die "in Betrieb" (aktive) IP-Adresse (bestimmt durch das Entdeckungs_Steuer_Bits-BIT 0) von jedem lokalen Knoten (beispielsweise Einheiten, vorliegend auf der Schnittstelle, dem Host) und die aufgeführten (Schritt 512). In einer Version erzeugt der Software-Agent eine Liste zum Speichern der IP-Adressen für ein "Array", wie sie gelesen werden (Schritte 514–518). Die Liste wird im Speicher (RAM oder DRAM) unter der Steuerung des Compilers und OS sein. Der In-Anwendungs-Zustand wird bestimmt durch ein Bit-Einstellen in der Vorrichtung, welches anzeigt, ob die einge baute oder die zugeordnete Adresse in Verwendung ist. In Tabelle 7 sind die IP_Adresse_zugeordnet und IP_Adresse_eingebaut in dem 1394Web-Einheits-Verzeichnis.
Der in Betrieb befindliche FWHCP-Agent 406 untersucht besagte Liste auf Kollision unter IP-Adressen, die dort aufgelistet sind (andere Kollisions-Nachweis- und Auflösungsverfahren können auch verwendet werden) (Schritte 520–522). Falls eine Kollision nachgewiesen wird, verändert der FWHCP-Agent die kollidierenden Adressen durch beispielsweise Substituieren der letzten signifikanten 6 Bits der IP-Adresse anstelle ihrer 6 Bit-Knoten-Adresse (Schritt 524). Nur die minimale Anzahl an Veränderungen wird durchgeführt, um die Kollision zu vermeiden. Falls eine der kollidierenden Adressen eine bereits zugeordnete Adresse ist, dann wird diese Adresse bevorzugt für die kollidierende, eingebaute Adresse verändert, beispielsweise durch Inkrementbildung des 6 Bit-Substitut-Werts und erneute Überprüfung, bis die Kollision aufgehoben ist. Der FWHCP-Agent 406 schreibt den veränderten Wert zurück in das Gerät und das Kontroll-Bit (Erkennungs_Steuer_Bits: Bit 0) wird so eingestellt, dass es die zugeordnete IP-Adresse im Gebrauch anzeigt und die eingebaute Voreinstellung ist nicht länger im Gebrauch (Schritt 526). Der Prozess wird dann für jede IP-Adresse wiederholt (Schritt 528). Nach dem Kollisions-Auflösungs-Prozess greift der in Betrieb befindliche FWHCP-Agent 406 wiederum auf jede Vorrichtung zu und setzt die "IP-Konfiguration in Betrieb"-Bits in jeder Vorrichtung beispielsweise auf "falsch", um anzuzeigen, dass die angegebene IP-Adresse gültig ist.
Beim konventionellen WWW-Betrieb greifen Benutzer auf die gleiche Seite auf oberster Ebene zu. Nimmt man auf 4b, 7 und 9–11 Bezug, schließen jedoch gemäß dem Aspekt der vorliegenden Erfindung alle UI-Vorrichtungen (beispielsweise Vorrichtungen, die in der Lage sind, Benutzer-Schnittstellen anzuzeigen) einen UI-Beschreibungs-Erzeugungs-Agenten (UIDGA) 408 ein, um unabhängig eine UI-Seite auf höchster Ebene 220 zu erzeugen zur Steuerung der Vorrichtungen auf dem lokalen Netzwerk (beispielsweise Netzwerk 100, Netzwerk 300, etc.) durch die Benutzer. In einem Beispiel erzeugt eine Client-Vorrichtung (beispielsweise ein PC) dynamisch eine lokal gespeicherte Voreinstellungs-Seite 220 zur Benutzer-Steuerung von Vorrichtungen, verbunden mit dem Netzwerk 100. Dies ermöglicht einer jeden UI Vorrichtung (beispielsweise dem DTV 102), eine unterschiedliche Ansicht 220 des Heim-Netzwerkes zu erzeugen, beispielsweise mit einem größeren, hervorstechenderen Icon für die angezeigten Vorrichtungen dieses UIs.
Als solches wird der Benutzer leicht darauf aufmerksam gemacht, welche UI-Vorrichtung "unmittelbar vorliegt" (vor dem Benutzer) oder im Falle von externem Zugriff auf das Haus liegt keine Vorrichtung "unmittelbar hier" vor. Eine Vorrichtung ohne ein UI kann ein UI für eine andere Vorrichtung erzeugen, ist jedoch sich klar über den Typus der Vorrichtung (beispielsweise erzeugt ein Kabel-Modem ein UI von HN-Vorrichtungen für Benutzer, welche extern zum Haus sind). In diesem Fall ist die tatsächliche UI-Vorrichtung unbekannt. Folglich sticht keine spezielle Vorrichtung in dem GUI hervor. Des Weiteren können Hersteller von Vorrichtungen, verbunden mit dem Netzwerk 100, ihr eigenes GUI-Design 202, 204 in jeder Vorrichtung, je nach Wunsch, zur Verfügung stellen. Darüber hinaus müssen spätere, verbesserte Browser- und Web-Technologie-Designs nicht durch die existierende Technologie behindert werden.
Nicht-UI-Vorrichtungen, insbesondere diejenigen Vorrichtungen, welche eine Gateway-Funktion durchführen, können auch einen UI-Beschreibungs-Erzeugungs-Agenten 408 einschließen, um GUI-Beschreibungen auf höchster Ebene 250 zu erzeugen, ohne dass GUI-Erzeugungs- und Laufzeit-Prozesse 410 (beispielsweise Web Browser 200) eingeschlossen sind, um GUis 220 zu erzeugen und darzustellen. Mit der geeigneten Adress-Verwendung (beispielsweise unter Verwendung der RFC1918 privaten Adressen auf dem lokalen HN) ermöglicht dies den externen WWW-Zugriff auf die 1394WEB-Netzwerk-Vorrichtungen. Externe Adressen werden "reellen" IP-Adressen, geeignet für die Internet-Anwendung, zugeordnet. Im Allgemeinen gibt es eine Einheit (beispielsweise eine Gateway-Typ-Einheit) mit dem UIDGA 408, welche das Haus gegenüber dem auswärtigen Internet repräsentiert. Das UIDGA des Gateways erzeugt eine unterschiedliche UI-Beschreibung für die Verwendung von außen (ferngesteuerter Zugriff[remote access]-Fall, verschieden von der Verwendung innerhalb einer lokalen Vorrichtung) unter Verwendung der IP-Adresse des Hauses mit ausgedehnten Verknüpfungen, um die jeweilige Heim-Vorrichtungs-lokale, private IP-Adresse zu identifizieren.
UI Vorrichtungen führen die folgenden Software-Prozesse aus, um Ansichten 220 des Netzwerkes 100/300 zu erzeugen und darzustellen: (1) 1394 Vorrichtungs-Erkennungs-Agent 404, wie oben beschrieben, (2) UI-Beschreibungs-Erzeugungs-Agent (UIDGA) 408 und (3) GUI-Erzeugungs- und Laufzeit(beispielsweise Web-Browser 200)-Prozess 410. Nimmt man auf 11 Bezug, führt in einer Ausführungsform ein UIDGA-Agent 408 in einer Vorrichtung Schritte durch, einschließend Auswählen der IP-Adress-Konfigurations-Bits in dem eigenen 1394 ROM 402 der Vorrichtung, um die Vervollständigung des FWHCP-Agenten 406 zu gewährleisten vor dem Zugriff auf irgendeine weitere IP-Information (Schritt 600). Nach Vervollständigung des FWHCP-Agenten 406 greift unter Verwendung der Anzahl von Vorrichtungen, erzeugt durch den 1394DDA-Agenten 404, der UIDGA-Agent 408 dann auf das Steuer-Wort in jeder Vorrichtung, welche derzeit mit dem Netzwerk verbunden ist, zu, um die Einstellungen für die "Konfiguration-Betriebs falsch" und die "in Betrieb"-IP-Adressen-Bits zu bestimmen (der UIDGA-Agent 408 erzeugt die HTML-Seite auf höchster Ebene, HN_Verzeichnis-Seite 220, dargestellt beispielsweise in 5–6). Anschließend liest der UIDGA-Agent 408 den tatsächlichen, in Gebrauch befindlichen IP-Adress-Wert und erzeugt eine vollständige Liste von IP-Adressen der Vorrichtungen, welche derzeit mit dem Netzwerk 300 verbunden sind. Die IP-Adressen-Liste schließt Information ein (beispielsweise Icon, Logo, Name, etc.) von jeder Vorrichtung und ist in HTML geschrieben unter Verwendung der IP-Adresse einer jeden Vorrichtung. Bevor er die Adressen einschließen kann, findet UIDGA 408 die Adresse einer jeden Vorrichtung durch Zugriff auf eine jede Vorrichtung und Überprüfen, um festzustellen, welche Adresse in Gebrauch ist durch Lesen der Tabelle 9, Erkennungs_Steuer_Bit, Steuer-Bit (Bit 0). Anschließend liest UIDGA 408 Tabelle 7, „Adresse entweder eingebaut oder zugeordnet". Für Vorrichtungen, welche mit verbrückten Netzwerken kommunizieren, wie bestimmt durch das Vorliegen von Extensions-IP-Adress-Listen-Einträgen in dem 1394 ROM 402 dieser Vorrichtung, liest der UIDGA-Agent 408 die Extentions-IP-Adressen aus der Liste (IP_Address_Extensions_Blatt), um zu ermöglichen, dass diese Vorrichtungen in dem GUI 220 eingeschlossen sind. Der Eintrag BC (IP_Address_Extensions Blatt) enthält eine Referenz-Verknüpfungs-Adresse, welche auf das tatsächliche Datenblatt verweist. Vorrichtungen in dem angebundenen verbrückten Netzwerk werden nur in der IP_Address_Extensions_Blatt-Liste eingeschlossen, falls sie auch den 1394WEB-Typ des Dienstes unterstützen, d.h. falls sie Web-Server und Icon.HTM etc. sowie Steuer-Seiten ("index.htm) aufweisen.
Der UIDGA-Agent 408 liest die IP-Adressen-Liste (Schritt 602) und erzeugt eine Netzwerk UI-Beschreibung auf höchster Ebene 250 (9c), beispielsweise in HTML (beispielsweise Appendix 1) unter Verwendung der IP-Adressen-Liste (UIDGA gibt das HN_Verzeichnis, die Netzwerk-UI-Seite auf höchster Ebene, eine HTML-Datei, aus) (Schritt 604). Der UIDGA-Agent 408 verwendet die IP-Adressen in den Hypertext-Verknüpfungen auf jede Vorrichtung für die icon.htm-, name.htm- und logo.htm-Dateien. UIDGA schreibt eine HTML-Datei, einschließend die Verweise auf die HTML-Seite einer jeden entdeckten Vorrichtung, beispielsweise ICON.HTM, NAME.HTM, LOGO.HTM (z.B. Appendix 2, 3, 4). Der UIDGA-Agent 408 verwendet dann HTML-Dateien, um auf Abschnitte zu verweisen, einschließend die Icon- und Logo-Grafik-Dateien und Namen-Dateien anstelle des Einschließens der bloßen icon.gif oder logo.gif bzw. des bloßen Namens-Texts in der UI-Beschreibung auf höchster Ebene 250 (Schritt 606). Dies ermöglicht, dass besagte Icons verwendet werden können durch die korrespondierende Vorrichtung, um den laufenden Status zu reflektieren, maßgeschneidert durch den Hersteller oder konfiguriert durch den Benutzer an der Vorrichtung, ohne dass irgendeine Veränderung in der HTML-UI-Beschreibung auf höchster Ebene 250 beim Steuern der UI-Vorrichtung verursacht wird. Obwohl eine Grafikvorrichtung in den beispielhaften GUI-Seiten 220 gezeigt ist (5–6), ermöglicht das Maßschneidern den Einschluss von mehr als einer Grafik-Dateien, auf die verwiesen wird durch ICON.HTM oder LOGO.HTM und von mehr Text in dem NAME.HTM. In einer Ausführungsform werden HTML-Dateien eingesetzt, um die UI Beschreibung 250 zu implementieren, wie in den Beispielen unten des Weiteren gezeigt wird. Die Verwendung von Rahmen stabilisiert das Erscheinungsbild des GUI 220 für den Fall von "bad citizen"-Vorrichtungen. Beispielsweise wird eine Vorrichtung, welche zu viele Wörter oder einen übergroßen Text in seinem "Namen"-Rahmen präsentiert, nur das Erscheinungsbild des GUIs beeinflussen (dadurch, dass einige der Wörter abgeschnitten und nicht dargestellt werden) und nicht negativ das Erscheinungsbild des gesamten GUI auf höchster Ebene 220 in der UI-Vorrichtung beeinflussen. Das UIDGA 408 ruft dann den GUI-Erzeugungsprozess 410 (beispielsweise Browser) in einer Client-Vorrichtung auf, um eine Benutzer-Schnittstelle zu erzeugen und darzustellen (Schritt 608).
Der GUI Erzeugungsprozess 410 (beispielsweise Web-Browser 200) setzt die UI-Beschreibung 250 ein, beispielsweise in HTML, um GUI-Seiten 220 auf UI-Vorrichtungen zu erzeugen. In einem Beispiel stellt der Browser 200, um eine tastaturfreie Operation für Verbraucher-Elektronik-Vorrichtungen (beispielsweise DTV) zur Verfügung zu stellen, das Lesen und das Erzeugen von lokal erzeugter "Top-Level-Vorrichtungen.Html"-Beschreibung 250 als Voreinstellung ein, um die Netzwerk-Steuerung GUI auf höchster Ebene 220 zu erzeugen. Lokal, wie hier verwendet, bedeutet in der gleichen Vorrichtung (einer UI-Vorrichtung mit einem UIDGA, welche das eigene HN-Verzeichnis-GUI (auf höchster Ebene) der Vorrichtung der Netzwerk-Vorrichtungen erzeugt). HN-Verzeichnis, Netzwerk-UI auf höchster Ebene und Erkennungsseite sind die gleichen. Für Personal-Computer (PC) mit Tastatur muss dies nicht im vorhinein eingestellt werden. CE-Vorrichtungen ist das Ingangsetzen des Browsers 200 verzögert, bis zur Vervollständi gung der UIDGA-Voreinstellungsseite 250-Erzeugung durch den UIDGA-Agent 408. In dem Fall, dass der UIDGA-Agent 408 seine Aufgaben nicht vervollständigen kann, stellt der Browser 200 dann eine alternative UI-Seite 220 dar, welche einen Netzwerk-Konfigurations-Fehler, der aufgetreten ist, zeigt (beispielsweise "nicht in der Lage zur Erzeugung der HN_Verzeichnis-Seite aufgrund von xxxxxx. Versuche, die Vorrichtung xxxxxxx abzukoppeln. Netzwerk-Konfigurations-Fehler Nummer xxxxxx trat auf. Kontaktiere Service-Telefon-Dienst xxx-xxx-xxxx oder Web-Dienst http://www.service.com").
Um das GUI 220 zu erzeugen, ruft der Browser 200 die "icon.htm"-, "name.htm-" und "logo.htm"-Dateien aus der Vorrichtungsinformation 202, 204 in jeder Vorrichtung, auf die Bezug genommen wird, auf (d.h. in der UI-Beschreibung, wo beispielsweise ICON.HTM in der HN_Directory-Seiten-HTML-Datei vorliegt), wie definiert wird durch die HTML-UI-Beschreibung 250. Die Inhalte dieser Seiten 202, 204 (beispielsweise die Icon-Grafik) müssen nicht statisch sein und können dynamisch verändert werden, um die Statusveränderung der Vorrichtung zu reflektieren oder nach Benutzer-Maßschneiderung. Um die am meisten aktuelle Seite auf höchster Ebene 220 anzuzeigen, cachet der Browser 200 nicht die "icon.htm-", "name.htm-" und "logo.htm"-Dateien. In einer weiteren Version wird eine Überprüfung jedes Mal zuerst durchgeführt, um zu bestimmen, ob die Vorrichtung irgendwelche Veränderungen in den HTML-Dateien 202, 204 welche sie aufweist, durchgeführt hat. HTTP "Conditional get" wird verwendet, um den Status der gesteuerten Vorrichtung zu überprüfen. Abhängend vom Status-Code, der zurückkommt, wird der Browser 200 entweder aus seinem eigenen Cache lesen oder auf eine frische oder aktualisierte Kopie der HTML-Datei 202, 204 von den Vorrichtungen zugreifen. Die HWW-GUI-Anzeige wird nicht beeinflusst, solange keine Veränderung des Status der gesteuerten Vorrichtung auftritt.
Der Browser 200 versucht nicht, das HN-Verzeichnis auf höchster Ebene anzuzeigen, bis es nicht vollständig erzeugt worden ist. Falls das HTML 250 nicht erzeugt wird innerhalb eines vernünftigen Zeitraums, zeigt der Browser eine alternative Seite an. Falls ein Netzwerk-Konfigurations-Fehler die Quelle des Problems ist, könnte eine alternative Seite gewisse technische Hilfestellung oder andere diagnostische Unterstützung liefern.
Wann immer der Anwender zu dem HN-Verzeichnis auf höchster Ebene zurückkehrt oder verursacht, dass es aktualisiert wird, zeigt der Browser 200 die Seite 220 in seiner Gesamtheit von neuem an. Dies ist notwendig, da HTML 250, welche dem HN-Ver zeichnis auf der höchsten Ebene zugrunde liegt, regeneriert werden hätte sein können, falls eine Vorrichtung zum Netzwerk 100 hinzugefügt oder von diesem entfernt worden ist. Es ist auch möglich, dass Device-Icons aktualisiert werden, um Veränderungen im Betriebszustand ihrer Vorrichtung zu reflektieren. Als solche verwenden Browser, implementiert durch EIA-775.1-Vorrichtungen HTTP-"conditional get"-Anforderungen, um zu bestimmen, ob Kopien von Web-Seiten oder Grafiken von dem Server wieder hergestellt werden oder nicht.
In diesem Aspekt stellt die vorliegende Erfindung eine Benutzer-Schnittstellen-Beschreibung zur Verfügung, wo die Benutzer-Erkennung von Vorrichtungen vollständig mit Verweisen (d.h. in der Zusammenfassung) erfolgt, wo die Verweise "Platzhalter" für die Erkennungs-Information (z.B. Text und/oder Grafiken) einer jeden Vorrichtung sind und in jeder Vorrichtung vorliegen. Jeder "Platzhalter" enthält tatsächliche Text-Information und/oder Verweise auf eine oder mehrere Grafik-formatierte Informations-Dateien, wobei jede Datei ein oder mehrere Bilder und/oder Text einschließen kann. Die Verwendung der Verweis-"Platzhalter" ermöglicht einer jeden Vorrichtung, den bevorzugten UI-Gehalt auszuwählen oder das bevorzugte Grafik-Format oder seinen UI-Gehalt, der angezeigt werden soll, zu verändern (durch Verändern des Textes oder der Grafik-Information, auf die Bezug genommen wird) ohne dass die UI-Beschreibungsseite in irgendeiner Weise verändert werden muss. Anschließend ist die Kommunikation von Veränderungen mit der erzeugenden Agent-Software der Erkennungs-UI-Beschreibung nicht nötig. In einer Version verweisen Vorrichtungen auf ihre eigenen ICON- und LOGO-Grafik-Dateien unter indirekter Verwendung von HTML-Dateien, möglich durch Erzeugen der Netzwerk-Beschreibung auf höchster Ebene unter Verwendung von HTML-Dateien. In ähnlicher Art und Weise wird der Vorrichtungsname, welcher unter dem Icon angezeigt wird, durch die NAME-HTML-Datei repräsentiert. HTML-Dateien werden verwendet, um beispielsweise auf die Icon- und logo-Grafikdateien zu verweisen und die Namen-Daten, statt dass die bloßen bzw. der bloße Namens-Text eingeschlossen wird. Dies ermöglicht, dass der Abschnitt verändert wird und den laufenden Status reflektiert, maßgeschneidert wird durch den Hersteller oder Benutzer, konfiguriert an der Vorrichtung, ohne dass irgendeine Veränderung in der HTML-Beschreibung auf höchster Ebene durchgeführt werden muss. Diese Ebene der Abstraktion ermöglicht es, der UI-Beschreibung auf höchster Ebene, immer die gleiche zu bleiben, unabhängig von den Grafiken ICON- und LOGO-Dateinamen und Typen und NAME-Text, welche dargestellt werden müssen. Auch die Vorrichtung kann verschiedene, multiple oder dynamische Veränderung der Grafikdateien und des Textes, dargestellt in dem GUI auf höchster Ebene, verwenden, ohne dass die Veränderung mit dem UIDGA kommuniziert werden muss. Die Veränderung ist automatisch eingeschlossen, wann immer das GUI erneut dargestellt wird. Die Verwendung von Rahmen stabilisiert auch die GUI-Darstellung in dem Fall von bad citizen-Vorrichtungen, welche nicht darstellbare Grafiken oder Text einsetzen, da der Fehler auf den speziellen Rahmen begrenzt ist und nicht das gesamte GUI beeinflusst.
Die Veränderung ist automatisch eingeschlossen, wann immer das GUI wieder dargestellt wird.
In einem Beispiel wird die Netzwerk-Vorrichtungs-UI-Beschreibung auf höchster Ebene unabhängig durch irgendeine Netzwerk-Vorrichtung erzeugt und mit Sicherheit durch Vorrichtungen, die in der Lage sind, UI darzustellen (UI-Vorrichtung). Erzeugen einer Benutzer-Schnittstelle in jeder Vorrichtung anstelle des Erzeugens eines zentralen UIs ermöglicht, dass eine Vorrichtung ihr eigenes Vorrichtungs-Icon/Text preferentiell in dem GUI zeigt. Darüber hinaus ist jedes GUI Hersteller-maßschneiderbar, Benutzer-konfigurierbar und auch verlässlicher, da es nicht von einer anderen Vorrichtung abhängt, z.B. von einem einzelnen zentralen Server. Dies wird demonstriert mit dem 1394-Schema oben. Multiple UI-Erzeugung ist möglich, da alle Vorrichtungs-IP-Adressen zugänglich sind über die 1394-Schnittstelle. UI-Vorrichtungen (mit Browser) schließen den UIDGA-Agent ein, um ihre eigene GUI-Beschreibung auf höchster Ebene zu erzeugen nach einem 1394 Reset-Zyklus, wenn eine Vorrichtung angebunden oder eingeschaltet wird.
Alle UI-Vorrichtungen erzeugen unabhängig voneinander eine UI-Seite auf höchster Ebene zur Steuerung für das lokale Netzwerk. Dies ist unterschiedlich vom konventionellen WWW-Betrieb, wobei Benutzer auf die gleiche Seite auf höchster Ebene zugreifen. Gemäß einer Version der vorliegenden Erfindung erzeugt die Client-Vorrichtung (beispielsweise ein PC) dynamisch eine lokal gespeicherte, voreingestellte Seiten-Datei für irgendeinen Zweck, was es jeder UI-Vorrichtung (beispielsweise DTV) ermöglicht, eine unterschiedliche Ansicht eines Heim-Netzwerkes zu erzeugen, beispielsweise mit einem größeren, hervorstechenderen Icon für seine eigene Darstellung. Des Weiteren haben die Hersteller Raum, ihr eigenes GUI-Design besser als ein anderes zu machen. Darüber hinaus müssen später verbesserte Browser- und Web-Technologie-Designs nicht durch frühere Technologie behindert werden.
Unter Verweis auf die Appendizes 1–4 werden illustrative Beispiele für das Folgende zur Verfügung gestellt: (1) Seitenbeschreibung auf höchster Ebene 250 (Appendix 1); (2) Background.Htm (Appendix 2); (3) Icon.Htm (Appendix 4) und (4) Name.Htm (Appendix 4).
Gemäß einen weiteren Aspekt der vorliegenden Erfindung werden Netzwerk-Konfiguration- und Benutzer-Schnittstelle(UI)-Beschreibungs-Erzeugung für die Heim-Netzwerk-Seiten-Grafik-Benutzer-Schnittstelle auf höchster Ebene (GUI) durchgeführt, um externe Dienste (beispielsweise Web-Dienste) von einem externen Netzwerk (beispielsweise einem Portal) wie auch von Heim-Netzwerk-Vorrichtungen 11 zu Verfügung zu stellen. In einer Ausführungsform schließt das externe Netzwerk miteinander verbundene Vorrichtungen ein, welche Dienste bereitstellen (beispielsweise Server, welche ein oder mehrere Computersysteme umfassen, welche Software zum Bereitstellen von Diensten ausführen). Als solche sind in einem Beispiel Portal-(externe Web-Server)-Dienste von Herstellern für ein externes Netzwerk 702 (7) in der Heim-Netzwerk-Benutzer-Schnittstellen-Beschreibung auf höchster Ebene 250 eingeschlossen.
In einer Implementation wird die Internet-Gateway-Adresse eines Gateways 700 in einem Adressraum definiert, welcher sichtbar ist für alle 1394-Vorrichtungen in dem Heim-Netzwerk 300. Anschließend kann für zumindest eine Vorrichtung 11 (beispielsweise Client-Vorrichtung 12, wie z.B. DTV 102) in dem Heim-Netzwerk 300, falls ein Gateway 700 detektiert wird, beispielsweise durch den Erkennungs-Agent 404, dann der UI-Beschreibungs-Generator-Agent (UIDGA) 408 von dieser Vorrichtung 11 externe IP-Adressen in der Heim-Netzwerk UI-Beschreibung auf höchster Ebene (TLNUID) 250 (wie auch Heim-Netzwerk-Vorrichtungs-Adressen, wie oben beschrieben) von dieser Vorrichtung 11 einschließen. Alternativ kann jede Vorrichtung 11 die Gateway-Vorrichtung 700 erkennen durch Kommunizieren und Erhalten von Information, beispielsweise von einer anderen Vorrichtung (wie z.B. DTV 103 oder Kabel-Modem), um die Gateway-IP-Adresse zu erhalten oder die Vorrichtung 11 kann mit der Gateway-Vorrichtung kommunizieren (die interne IP-Adresse des Gateways verwenden), um die öffentliche/externe IP-Adresse der Gateway-Vorrichtung zu erhalten. Auf externe Dienste von einem externen Netzwerk 702 von miteinander verbundenen Vorrichtungen 704 kann von einer oder mehreren IP-Adressen aus (oder Portal), bekannt für das UIDGA 408 zugegriffen werden, wenn das GUI auf höchster Ebene 220 erzeugt wird oder aktualisiert wird in dieser Vorrichtung 11. In einer Version wird die externe Heim-Portal-IP-Adresse im Voraus in das UIDGA 408 programmiert, wobei das UIDGA 408 keine externe Adresse durch die Gateway-Vorrichtung erhalten muss. In einem Beispiel schließt jede Vorrichtung 704 ein oder mehrere berechnende/Computersysteme ein, welche Software ausführen zum Bereitstellen von Diensten (Web-Dienste), wobei die Vorrichtungen 704 über Router und Kommunikationsverknüpfungen (beispielsweise Internet) verknüpft sind.
12 illustriert einen bildhaften Abriss von dem TLNUID 250, welcher den tatsächlichen HTML-Daten-Namen-Verweis und die Adresse einer logoicon-htm-Datei 710A (welche sich in einem Server 704 in einem externen Netzwerk 702 befindet) und einen tatsächlichen HTML-Datei-Namen-Verweis und die Adresse einer logoname-htm-Datei 712A (welches sich in einem Server 704 in dem externen Netzwerk 702 befindet) zeigt. 13 illustriert die Browser-erzeugte GUI 220, basierend auf dem TLNUID 250. Der Inhalt von logoicon- und Namen-Abschnitten 710B, 712B in 13 für Dienste von dem Portal wird aktualisiert, wann immer die GUI-Seite auf höchster Ebene 220 in dieser Vorrichtung 11 aktualisiert wird. Des Weiteren werden Portal- oder Inhalts-Seiten-Treffer erzeugt, wann immer das Netzwerk-GUI auf höchster Ebene 220 in dieser Vorrichtung 11 aktualisiert wird (oder vorzugsweise, wenn die Beschreibung auf höchster Ebene 250 erzeugt wird).
In einer Beispiel-Implementation kann der Hersteller einer Vorrichtung 11 (beispielsweise DTV 102) auswählen, das UIDGA 408 in dieser Vorrichtung 11 zu programmieren, so dass es extern bereitgestellte Dienst-Logos-Icons in dem Heim-Netzwerk GUI auf höchster Ebene 220 der Vorrichtung 11 einschließt. Solche Funktionalität ist in dem GUI-Beschreibungs-Erzeugungs-Agent (UIDGA) 408 eingebaut. Die Dienst-Logo-Seite 708B, Logo-Grafiken 710B und Text 712B adressieren einen Web-Server 704 extern für das Heim-Netzwerk. Die Logos 710B können Dienste, Information, Medien etc. repräsentieren und auf sie kann aktiv per Hyperlink verwiesen werden, welche durch Vorrichtungen 704 in dem externen Netzwerk 702 über das 700 zur Verfügung gestellt werden. Des Weiteren können Vorrichtungs-Icon-Räume 708B, welche in der Seite auf höchster Ebene der Heim-Netzwerk-Vorrichtung 220 nicht verwendet werden, gefüllt werden mit Dienst-Logos oder Icons 710B und Namen 712B von einer externen Web-Seite, bereitgestellt durch eine Server-Vorrichtung 704. In einem Beispiel kann es so viele wie 12 nicht verwendete Icon-Räume für ein minimales Heim-Netzwerk, einschließend eine Vorrichtung, geben. Bezieht man sich auf das Beispiel TLNUID 250 und das GUI 220 in den 12–13, gibt es ein Minimum von 12 Dienst-Logo-Grafik 710B, Logo-Namen 712B- Sätzen für das GUI 220. Die Logo-Daten-Namen 710A können eine Nummer von 1 bis 12 haben, beispielsweise logoicon1.htm bis logoicon12htm und auf sie wird zugegriffen in der Reihenfolge von den niedrigeren zu den höheren Nummern. In ähnlicher Weise können die Namen-Dateien-Namen 712A eine Nummer von 1 bis 12 aufweisen, beispielsweise logoname1.htm bis logoname12.htm und auf sie wird zugegriffen in der Reihenfolge von den niedrigeren bis zu den höheren Nummern. Die folgende beispielhafte Beschreibung ist ähnlich zu der für das Vorrichtungs-Icon, wie oben beschrieben.
Ein Logo-Icon bzw. eine Namen-Datei 710A, 712A pro Dienst repräsentieren den Dienst grafisch in der Heim-Netzwerk-Vorrichtungsseite auf höchster Ebene 250, dargestellt in 12 und in der korrespondierenden GUI 220, dargestellt in 13. Auf eine Grafik-Datei 710B mit einem Namen wird in einer korrespondierenden HTML-Seite 710A verwiesen. Die Grafik 710B ist mit einem Hyperlink zur Dienstseite auf höchster Ebene 710A versehen. Ein Beispiel einer grafischen Beschreibung kann einschließen: Grafik-File-Typen von GIF, JPG oder PNG (jeglicher Name) und eine logo-Icon-Grafik-Maximalgröße von 70(V) × 130(H) Pixeln. Eine HTML-Seite 250 verweist auf die Grafikdatei 710A, wobei die erste Datei, auf die zugegriffen wird, 710A, die primäre Dienst-Logo-Grafiken 710B repräsentiert, bezeichnet als logoicon1.htm 710A. Nachfolgende Logos können Dateien verwenden mit Inkrement-Nummer. Es ist auch möglich, mehr als eine Grafik-Referenz in logoicon1.htm einzuschließen. In diesem Fall ist der Hyperlink zu der Dienst-Homepage verknüpft und das zweite Bild (beispielsweise logoincon1_1.htm) kann per Hyperlink mit einer anderen Location verknüpft sein.
Des Weiteren schließt ein Minimum von einer Logo-Namens-Datei 712A Text 712B ein, um die Log-Grafik (logoicon.htm) in der Heim-Netzwerk-Vorrichtungs-Seite auf höchster Ebene 250 zu vergrößern. Der Text 712B schließt einige wenige Wörter ein, welche mit der Dienst-Logo-Icon-Grafik, relevant für diesen Dienst, übereinstimmen. Name (beispielsweise "VCR Wohnzimmer" als Name eines VCR in dem Wohnzimmer) kann Text in einer HTML-Seite einschließen mit der Bezeichnung „logoname1-htm". Nachfolgende Logos können Dateien verwenden mit Inkrement-Nummer. Vorzugsweise wird nur der Dateiname standardisiert und nicht der Text. Der Text kann auch mit Hyperlinks versehen sein. Ein Beispiel einer Beschreibung kann einschließen: Text, unspezifiziert ohne Schriftartbeschränkung. Als ein Beispiel können mit Schriftgröße 10 zwei Zeilen an Text dargestellt werden unter dem Logo-Icon.
Ein Beispiel für einen Erkennungsprozess, unterstützt durch jede Heim-Vorrichtung 11, welche den EIA-1394WEB-Standard unterstützt, wird nun beschrieben werden. Da Benutzer-Steuerung von Vorrichtungen indirekt über eine grafische Benutzer-Schnittstelle (GUI) 220 bedeutsam ist für den tastaturfreien Betrieb der Vorrichtungen 11, irgendwo auf dem Heim-Netzwerk 300 und für Dienste, bereitgestellt durch Vorrichtungen 704, außerhalb des Heim-Netzwerks 300, ist eine Funktion des Erkennungsprozesses das Internet-Protokoll zu urladen (bootstrap) und die Web-basierte Steuerung zu urladen. Das Erstgenannte schließt die Vorrichtungserkennung 404 und die IP-Adress-Konfiguration 406 ein und das letztgenannte schließt die Erzeugung von Netzwerk-Benutzer-Schnittstellen-Beschreibung auf höchster Ebene (TLNUID) 250 durch das UIDGA 408 für die Browser-Voreinstellungsseite ein, welche sie veranlasst, die Benutzersteuerung GUI auf höchster Ebene 220 zu erzeugen. Die UI-Beschreibung (GUI-Quell-Beschreibung) 250 in 12 schließt die grafische Icon-Referenz 706A und eine Text-Namens-Referenz 707A ein, repräsentierend jede Vorrichtung 11 in dem Heim-Netzwerk 300, korrespondierend mit der Grafik 706B bzw. dem Namen 707B in 13. Die UI-Beschreibung (GUI-Quell-Beschreibung) 250 schließt des Weiteren die grafische Icon-Referenz 710A ein und eine Text-Namens-Referenz 712A, repräsentierend jeden externen Dienst von dem externen Netzwerk 702, korrespondierend mit der Grafik 710B bzw. Namen 712B in 13. Der Browser sammelt ein Grafikbild (Grafikbilder) und Namen von jeder Vorrichtung und jedem Dienst, die das GUI 220, gezeigt durch das Beispiel in 13, erstellt.
Jede 1394WEB-UI-Vorrichtung 11 (beispielsweise Client-Vorrichtung 12, wie z.B. HDTV 102) erzeugt separat die Netzwerk-UI-Beschreibung auf höchster Ebene 250, was es der Vorrichtung ermöglicht, Priorität für sich selbst in dem dargestellten GUI zu geben. In 12–13 nimmt ein Host-HDTV 102, welcher das Top-Level GUI 220 erzeugt und präsentiert, Priorität an und verwendet ein Icon von vierfach größerer Größe. Unterschiedliche Hersteller können ihre eigenen GUIs erzeugen und können verschiedene, für ein jedes Vorrichtungsmodell erzeugen, wobei beispielsweise ein tragbares WEB-Steuergerät ein viel einfacheres GUI als ein HDTV erzeugt.
Für ein Heim-Netzwerk 300, verbunden mit einem externen Netzwerk 702, wie z.B. dem World Wide Web (beispielsweise über das Internet) können Vorrichtungs-Hersteller (beispielsweise TV) eine Vorrichtung-UIDGA 408 designen, so dass es Logo- oder Icon-Seiten einschließt (beispielsweise logoicon1.htm und logoname1.htm) mit Hyperlinks versehen von der Webseite des Herstellers in einem Server 704 in dem internen Netz werk 702. In den 12–13 schließt die Bottom-Reihe Ecommerce-Logos 712B von einem beispielhaften externen Web-Server oder Heim-Portal, Adresse 209.157.0.2, betrieben durch einen TV-Hersteller, ein. Der primäre Logo-Abschnitt, dargestellt auf der linken Seite, ist ein beispielhafte Logo-Grafik 710B sowie ein Name 712B von der Webseite des Herstellers (beispielsweise Domainname homewideweb.net, Adresse 209.157.0.2). In diesem Beispiel wird das YAHOO (TM) Icon, eingebettet in die zweite Logo-Seite (beispielsweise logoicon2.htm und logoname2.htm) von der Webseite des TV-Herstellers oder dem Heim-Portal erhalten, und nicht direkt von der YAHOO Web-Seite. Der TV-Hersteller kann ein Maßschneidern des GUIs 220 ermöglichen, wobei Dienst-Icons und Logos von einem Web-Server oder einem Portal außerhalb der Steuerung des Herstellers erhalten werden.
In einem Beispiel liest der Entdeckungsprozess Information von der 1394 Adress-Raum-Daten-Speicherung (beispielsweise Konfigurations-ROM-Struktur), wie in Abschnitt 8 von ISO/IEC 13213 definiert. Obwohl als "ROM" bezeichnet, wird angenommen, dass der Adressraum beschreibbar ist, um eine Benutzerkonfiguration und Modifikation von benutzerrelevanten gespeicherten Werten zu ermöglichen. Der Erkennungsprozess umfasst substanziell die Schritte, wie hier oben beschrieben, mit den folgenden zusätzlichen oder unterschiedlichen Funktionen für externe Web-Verknüpfungen. Eine jede Vorrichtung 11 behält ein Extensions-Datenblatt in dem 1394 ROM-Raum für IP-Adressen von Vorrichtungen 704 auf dem nicht1394-Netzwerk 702 (beispielsweise 7, 14) und zusätzlich einen unmittelbaren Datenwert für die Internet-Gateway-Adresse als Information für alle die 1394-Vorrichtungen 11. Irgendeine 1394-Vorrichtung 11 kann die Gateway-Adresse erkennen. Die Internet-Gateway-Vorrichtung 700 oder eine Vorrichtung (beispielsweise DTV 102) in Kommunikation mit einem nicht-1394-Netzwerk 702, welches die Gateway-Vorrichtung 700 unterstützt, schließt die IP-Adresse des Gateways im ROM-Raum (1212R) wie definiert, ein. Eine oder mehrere Vorrichtungen 11 (beispielsweise DTV 102) können ihr eigenes Icon hervorstechender (größer) machen, dem gesamten GUI 220 ein unterschiedliches Aussehen geben und Logos und Icons 710B vom externen Portal (beispielsweise Hersteller oder andere Webseite, bereitgestellt durch eine oder mehrere Vorrichtungen 704 in dem externen Netzwerk 702) einschließen. Logos 710B von einer externen Web-Seite (externen Web-Seiten) oder Portal können eingeschlossen sein in dem GUI auf höchster Ebene 220 unter der Steuerung von z.B. dem DTV-UI-Beschreibungs-Generator 408 des TV-Herstellers für verschiedene (beispielsweise Geschäfts-)Zwecke. Eine oder mehrere der Vorrichtungen 11 kann des Weiteren eine IP-Adresse des Internet-Gateways einschließen (falls eine Gateway- oder Brücken-Vorrichtung vorliegt), relevant für die Erkennung von IP-Adressen für das 1394WEB in dem 1394-Konfigurations-ROM.
Nun wird auf 15 Bezug genommen; während einem Beispiel für ein Operations-Szenario eines UIDGA 408 in einer Vorrichtung 11 (Schritt 800), falls eine Gateway-IP-Adresse während der Suche des 1394-ROM-Raums auftritt (Schritt 802), wird festgehalten, den Einschluss von Logos, auf die extern zugegriffen wird, 710A, 712A, in der Netzwerk-UI-Beschreibung auf höchster Ebene (TLNUID) 250 zu ermöglichen. Anschließend liest das UIDGA 408 die IP-Adressen-Liste der Vorrichtung in dem Heim-Netzwerk 300 (Schritt 804), entdeckt durch das DDA 404, das UIDGA 408 erhält die Heim-Portal-IP-Adresse (Schritt 806) und erzeugt das TLNUID 250 in HTML unter Verwendung der IP-Adressen-Liste, einschließend Links auf externe Dienste, bereitgestellt durch das Netzwerk 702 (Schritt 808). Wie beispielsweise in 12 gezeigt, umfasst das repräsentative Format des TLNUID 250 eine Matrix von Icon-Grafiken und Unterstreichungen im Text, welche die Funktionen der Vorrichtungen oder Dienste für den Anwender repräsentieren. Den Heim-Netzwerk-Vorrichtungen wird Priorität in dem relevanten TLNUID-Vorrichtungs-Icon-Raum eingeräumt. Entsprechend der TLNUID-Beschreibung 250 werden für die Heim-Netzwerk-Vorrichtungen 11 die Inhalte der icon.htm 706A Seite 706B in dem großen Raum platziert und der Inhalt der name.htm 707A Seite 707B in dem kleineren der vertikal benachbarten Rahmen für eine jede Vorrichtung. IP-Adressen der Vorrichtungen 11, verknüpft mit dem Heim-Netzwerk 300, werden in den Hypertext-Verknüpfungen für jede Vorrichtung verwendet für die icon.htm bzw. name.htm-Dateien (gezeigt durch die Beispiele im Folgenden unten) (Schritt 810).
Des Weiteren können während der Operation des UIDGA 408 in einer Vorrichtung 11, falls ein Gateway 700 nachgewiesen wird (beispielsweise durch das DDA 404), jegliche Vorrichtungs-Icon-GUI-Räume, welche als ein Ergebnis verbleiben, beispielsweise, da sie ein kleines Netzwerk aufweisen, multiple Niveaus (beispielsweise dadurch, dass einige Vorrichtungs-Icons auf eine Seite eines zweiten Niveaus verschoben werden), etc. für Logo-Abschnitte 708A eingesetzt werden, auf die extern zugegriffen wird, durch Entscheidung des UIDGA 408. In dem TLNUID 250 werden die externen Logo-Abschnitte 708A (beispielsweise jede Logo-Grafik-Datei 710A und der assoziierte Name 710B) beispielsweise von einem Web-Server (beispielsweise einem Home-Portal) des Herstellers bei einer fixierten externen IP-Adresse in dem externen Netzwerk 702 unter der Steue rung des UIDGA 408 des Herstellers erhalten. Die Log-Abschnitte 708A schließen vordefinierte Seiten-Namen 710A, 712A ein und auf sie wird in ihrer numerischen Reihenfolge zugegriffen (beispielsweise zuerst logoicon1-htm, logoname1.htm und dann logoicon2.htm, logoname2.htm usw.) (Schritt 812). Der Hersteller (oder Operator des Web-Servers) kann die geeigneten Grafiken und/oder Text mit Hyperlinks innerhalb von besagten Seite 710A, 712A insertieren. Als solche werden logoicon1.htm 710A und logoname1.htm 712A) häufiger in dem TLNUID 250 eingeschlossen werden und höhere Nummern werden zuletzt eingeschlossen werden. Das TLNUID 250 wird dann eingesetzt durch den Browser 410, um das GUI 220 zu erzeugen und es darzustellen (Schritt 814).
In den beispielhaften Versionen des TLNUID 250 werden HTML-Dateien eingesetzt, um indirekt auf die tatsächlichen Grafikdateien 710B bzw. die Namensdaten 712B zu verweisen anstelle des direkten Einschließens des rohen Grafik-Datei-Namen/Typs und des Namen-Textes. Dies stellt eine Ebene der Abstraktion zur Verfügung, was dem Abschnitt (beispielsweise tatsächlichen Grafik-Dateien 710B und Namens-Daten 712B) ermöglicht, auf Seiten der Vorrichtung verändert zu werden, um den derzeitigen Status zu reflektieren, welcher maßgeschneidert wird durch den Hersteller oder Benutzer konfiguriert wird an der Vorrichtung selbst, ohne dass irgendeine Veränderung für das TLNUID HTML 250 verursacht wird. Obwohl für eine Grafik gedacht, können mehr als eine Grafikdatei und ein Text per Verweis durch icon.htm oder logoiconX.htm einbezogen werden und gleiches gilt für Grafiken und Text, auf welche in name.htm und logonameX.htm verwiesen wird.
In beispielhaften Ausführungsformen werden HTML-Rahmen verwendet, um die UI-Bechreibung 250 zu implementieren. Die Verwendung von Rahmen stabilisiert das Erscheinungsbild des GUI 220 in dem Fall von "bad citizen"-Vorrichtungen. Beispielsweise wird eine Vorrichtung, welche zu viele Wörter oder einen überlangen Text in seinem "Name"-Rahmen präsentiert, nur das Aussehen des GUIs dieser Vorrichtung beeinträchtigen (dadurch, dass einige der Wörter abgeschnitten werden oder nicht angezeigt werden) und nicht negativ das Erscheinungsbild des gesamten GUI auf höchster Ebene beeinträchtigen werden. Da die Beschreibung 250 auf höchster Ebene unabhängig von den UI-befähigten Vorrichtungen erzeugt wird (beispielsweise Client-Vorrichtungen 12, wie z.B. DTV 102) muss das exakte Design nicht standardisiert werden. Die Icon- und Logo- Grafiken und die maximalen Namen-Größen werden standardisiert, so dass sie das Design der GUI-Matrix erleichtern.
Das GUI auf höchster Ebene 220, welches viele Vorrichtungen 11 und Dienste 708B einschließt, kann designed werden entsprechend der früheren Benutzer-Zugriffshäufigkeit. Vorrichtungen 11 oder Dienste 708B mit höherer Zugriffshäufigkeit können mit einem hervorstechenden Display auf dem GUI auf höchster Ebene 220 oder auf GUI-Seiten von höherer Ebene für die Einfachheit der Anwendung versehen werden. Ein Software-Agent, welcher mit dem Browser läuft, kann eingesetzt werden, um eine solche Funktion zur Verfügung zu stellen. Der Software-Agent zeigt den Benutzer-Zugriff auf jede Vorrichtung 11 oder jeden Dienst 708B an, zählt die Zugriffe und speichert die Anzahl von Zugriffen pro Vorrichtung/Dienst-IP-Adresse auf ein Datenverzeichnis in einer Stelle, auf welche durch den Benutzer-Schnittstellen-Beschreibung-Erzeugungs-Agent UIDGA 408 zugegriffen werden kann. Das Datenverzeichnis umfasst beispielsweise eine einfache Liste von IP-Adressen und Nummern. Falls eine Datei und Nummer bereits für eine spezielle IP-Adresse existiert, wird eine neue Nummer dem existierenden Wert hinzugefügt.
In einer Version wird das UIDGA 408 im Vorhinein programmiert mit einer oder mehreren IP-Adressen in dem externen Netzwerk 702, um auf eine oder mehrere externe Web-Seiten zuzugreifen, wobei ein Portal eine oder mehrere fixierte Web-Seiten umfasst. Das DDA 404 entdeckt die Vorrichtungen 11 in dem Heim-Netzwerk 300, während das UIDGA 408 verantwortlich ist, um das TLNUID 250 auf der höchsten Ebene zu erzeugen. Das Gateway 700 wird verwendet, um die Daten der externen Netzwerke zu routen. Jedes Mal, wenn eine Abfrage, auf ein äußeres Netzwerk zuzugreifen, besteht, beispielsweise auf ein externes Portal auf einer Internet-Web-Seite, wird die Anfrage durch den Gateway 700 zum außenseitigen Netzwerk 700 geroutet (spezifischerweise durch Netzwerk-Kommunikation). Das UIDGA 408 verwendet die im Vorhinein programmiert externe Portal-IP-Adresse, um das TLNUID 250 für das GUI auf höchster Ebene 220 zu erzeugen, einschließend beispielsweise eine Icon-Grafik-Repräsentatin 710B für die externen Dienste, und anschließend wird das GUI 200 dem Benutzer präsentiert. Wenn ein Benutzer auf die externe Verknüpfung/das externe Netzwerk zugreift durch Klicken eines Icons 710B in dem GUI 220, welches eine Vorrichtung/einen Dienst in dem außenseitigen Netzwerk 702 repräsentiert, wird die Abfrage aus dem Heim-Netzwerk 300 an ein externes Netzwerk 702 durch den Gateway 700 gesendet. Der Browser 410 wird ver wendet, um das GUI auf höchster Ebene 220 anzuzeigen, ebenso wie in dem Fall, wo keine externen Links eingesetzt werden. In einer Version schließt das UIDGA 408 nur eine externe "Basis"-Dienst-Portal-IP-Adresse ein (beispielsweise eine Web-Seite oder eine Portal-Adresse des Herstellers für eine Vorrichtung), ohne dass es notwendig ist, die externen Link-IP-Adressen oder andere externe Dienste zu kennen, beispielsweise yahoo.com, amazon.com, welche in der Basis-Portal-Weg-Seite gespeichert sind, und anschließend im GUI 220 zur Verfügung gestellt werden in Dateien, wie z.B. logoicon1-htm, beschrieben durch das Beispiel unten.
Obwohl in der oben aufgeführten Beschreibung eine beispielhafte Implementation beschreibt, dass Hersteller Portalinformation in den Vorrichtungen platzieren, sind andere möglich. Des Weiteren kann, obwohl die externe Web-Seite als eine Web-Seite für eine Vorrichtung eines Herstellers beschrieben wird, jede andere externe Web-Seite auch eingesetzt werden.
Nun wird auf die Appendizes 5–12 Bezug genommen; illustrative Beispiele für die folgenden htm-Dateien zum Erzeugen des TLNUID und des GUI in den 12–13 werden zur Verfügung gestellt:
Appendix 5 – Beispiel für eine Seite auf höchster Ebene TLNUID (index.htm).
Appendix 6 – Beispiel für background.htm
Appendix 7 – Beispiel für icon.htm
Appendix 8 – Beispiel für name.htm
Appendix 9 – Beispiel für logoicon1-htm
Appendix 10 – Beispiel für logoname1.htm
Appendix 11 – Beispiel für logoicon2.htm
Appendix 12 – Beispiel für logoname2.htm
Die Beispielseite auf höchster Ebene TLNUID (index.htm) 250 implementiert das TLNUID 250 und das GUI 220, gezeigt in 12–13. Acht Heim-Netzwerk-Vorrichtungen werden dargestellt, welche in der oberen 75%igen Fläche des GUI 200 repräsentiert sind. Die unteren 25% der Fläche, d.h. die Zahlen unten, zeigen Logo-Seiten 708B von dem vom Hersteller ausgewählten externen Web-Server oder Portal ein fixierten IP-Adresse. Das TLNUID 250 wird erzeugt unter Verwendung von Rahmen. Hyperlinks auf die lokale Vorrichtung 11, Grafiken und Namen-Seiten verwenden alle ihre lokalen 10.X.X.X-Adressen. Hyperlinks für extern zur Verfügung gestellte Logo-Grafiken und Namen-Seiten 710A, 712A verwenden die einzigartigen externen IP-Adressen (beispielsweise 209.157.0.2), welche vom Hersteller zur Verfügung gestellt werden. Als solche wird die Steuerung des Logo-Display 708B und der angebotenen Dienste durch das TV oder vom Vorrichtungshersteller zur Verfügung gestellt, d.h. dem Provider des TLNUID-Erzeugungs-Agents 408 in einer jeden von einer oder mehreren Vorrichtungen 11. Der "DVD 1" Vorrichtung 11-Icon-Rahmen schließt zwei Grafiken der Vorrichtung 11 ein. Dies beeinträchtigt nicht den TLNUID 250, jedoch wenn der Browser 410 das GUI 220 erzeugt, kann zumindest ein icon.htm 706A auf zwei Grafikdateien verweisen, eine (Vorrichtungs-Grafik 721) per Hyperlink verknüpft an die Vorrichtung 11-Steuer-Seite auf höchster Ebene und die andere (Logo 720) per Hyperlink verknüpft an den Web-Server für Kundenbetreuung, Dienst, Hilfe, etc. des Herstellers.
Auf die beispielhafte Beschreibungsseite icon.htm 706A wird von der Vorrichtung 11 zugegriffen, wenn der Weg-Browser 410 das GUI auf höchster Ebene 220 erzeugt und verwendet, um einen Icon-Raum zu füllen. Der Browser 410 liest diese Seite 706A und erzeugt weitere Zugriffe auf die Vorrichtung 11, um die tatsächliche Grafik icon.gif 706B zur Darstellung aufzurufen. Die Beschreibung icon.htm 706A zeigt, dass die voreingestellte Steuerseite der Vorrichtung index.htm der Hyperlink ist, der an die Grafiken angebunden ist, der verursacht, dass die Seite angezeigt wird, wenn sie aufgerufen wird. Wenn sie aufgerufen wird, wird die Heim-Steuer-Seite der Vorrichtung in einem neuen Browser-Fenster angezeigt.
Auf die Beispiel-Beschreibungsseite name.htm 707A wird von der Vorrichtung 11 durch den Web-Browser 410 zugegriffen, wenn er das GUI auf höchster Ebene 220 erzeugt. Der Text 707B. enthalten in dem name.htm 707A wird direkt unter dem Icon 706B platziert und stellt die Möglichkeit zur Verfügung, durch Möglichkeiten, bereitgestellt durch den Benutzer, durch die Vorrichtungs-Steuerseiten Benutzer-maßgeschneiderten Text unter das Icon anzuwenden.
Die Beispiel-Beschreibungsseite logoincon1.htm 710A wird auf einem Externen Web-Server 704 gehalten, welcher durch den Hardware-Hersteller betrieben wird (beispielsweise homewideweb.com). Die Seite 710A kann logo-Grafiken enthalten, um Zugriff auf einen Dienst zu ermöglichen. Ein Hyperlink in dem TLNUID 250 stellt den Zugriff auf den externen Web-Server 704 zur Verfügung, welcher diesen speziellen Dienst unterstützt. In diesem Beispielsfall korrespondiert die Adresse tatsächlich mit dem gleichen Web- Server oder Portal, welcher die logo-Seiten selbst unterstützt mit dem Domainennamen "homewideweb.com". Auf die Beispiel-Beschreibungsseite logoicon1.htm 710A wird im dem Web-Server 704 durch den Web-Browser 710 in der Vorrichtung 11 zugegriffen, um das GUI auf höchster Ebene 220 zu erzeugen. In ähnlicher Art und Weise wird auf die Datei logoname1.htm 712A in dem Server 704 durch den Browser 710 zugegriffen und der Text 712B in logoname1.htm wird direkt unter der logo-Grafik 710B platziert und kann zur Anreicherung der Grafik, beschrieben in dem Dienst, verwendet werden.
Per se gibt es einen ersten Hyperlink zwischen der Seite auf höchster Ebene 250 in der Vorrichtung 11 und der Datei logoincon1.htm 710A in einem Server 704 und es gibt einen zweiten Hyperlink zwischen der Datei logoicon1.htm 710A und der tatsächlichen logo-Grafik 710B. Das UIDGA 408 platziert den ersten Hyperlink für die Datei logoicon1.htm 710A in der Seite auf höchster Ebene 250 für den Benutzer durch den Browser 410, um auf die Datei logoincon1.htm 710A zuzugreifen, welche in dem Server 704 aufbewahrt wird und der Browser 410 benutzt den zweiten Hyperlink in der Datei logocon1.htm 710A, um auf das Tatsächliche Logo 710B zuzugreifen (beispielsweise Home-Wide-Web, Yahoo (TM), Amazon (TM), etc.), welches in dem GUI 220 in der Vorrichtung 11 dargestellt werden soll.
In einem Beispiel schließt die Datei logoicon1.htm 710A in dem Heim-Portal (beispielsweise dem Server 704) einen Hypertext-Link zur korrespondierenden Home Wide Web Icon-Grafik-Datei 710B ein in dem Heim-Portal und die Datei logoiconr.htm 710A in dem Heim-Portal (beispielsweise Server 704) schließt einen Hypertext-Link zur yahoo(TM) IP-Adresse für die korrespondierende Yahoo-Icon-Grafik-Datei 710B ein.
Der logoicon2.htm Hyperlink wird auf einem externen Web-Server 704 aufbewahrt, betrieben durch den Hardware-Hersteller und ist für einen externen Web-Server, welcher einen speziellen Dienst unterstützt. In diesem Beispiel schließt die logoicon2.htm einen Hyperlink zur IP-Adresse der Yahoo(TM)-Domäne 204.71.200.75 ein, um direkt auf die Yahoo-Web-Seite zu verweisen. DNS (wodurch eine Namen-Adress-Suche zur Verfügung gestellt wird und die Verwendung von Namen ermöglicht wird) wird nicht benötigt, wenn der Benutzer mit der Yahoo-Grafik interagiert, welche sich nicht verändert und ihr Hyperlink in der logoicon2.htm-Seite kann leicht verändert werden, um irgendeine neue Adresse zu reflektieren, zu einer beliebigen Zeit, zu der das GUI 220 erneut dargestellt wird/aktualisiert wird. In einem Beispiel wird das tatsächliche GUI 220 von der HTML- Beschreibung 250 erzeugt beim Hochfahren oder Neustart, nachdem eine Vorrichtung 11 zum Netzwerk 300 hinzugefügt worden ist bzw. bei einem Neustart.
Für die beispielhaft verknüpfte externe Web-Server-Implementation wird die beispielhafte Tabelle 11 unten eingesetzt anstelle der Einheitsverzeichnistabelle 7 oben, welche das EIA-775-Einheitsverzeichnis zeigt, wodurch die folgende EIA-1394WEB-spezifische Information in dem EIA-1394WEB-Einheitsverzeichnis erscheinen sollte.
Tabelle 11
Die Einheits_Beschreibung_ID spezifiziert die Identität der Organisation, welche verantwortlich ist für die architekturale Schnittstelle der Einheit und der Beschreibung. In diesem Fall bezieht sich das Verzeichnis und der Identitätswert = 005068₁₆ auf das EIA als den verantwortlichen Körper und die EIA-1394WEB-Steuer-Architektur-Beschreibung.
Das Datenblatt enthält eine Tabelle von Gateway-IP-Adressen, um mehr als eine Gateway-Adresse zu ermöglichen. Es ist für Kommunikationsvorrichtungen beabsichtigt. Dabei kann es sich um die gleiche Vorrichtung oder eine andere Vorrichtung auf einem verbrückten Netzwerk handeln (beispielsweise 7, welche die 1394- und nicht-1394-Vorrichtung einschleißt). Ein IP_Adress_Internet_Gateways_Blatt(BD₁₆)-Verzeichniseintrag ist eingeschlossen für den Adress-Absatz des Datenblattes für das IP_Address_Internet_Gateway_Blatt, wie in der beispielhaften Tabelle 12 unten. Gate way-Adressen werden verwendet durch Host-Cent-Software, um externe Adressen an das Internet zu verweisen. Filtern der externen Adressen wird durchgeführt durch die angenommene Sub-Net-Maske 255.0.0.0 für das 10.X.X.X private Netzwerk.
Tabelle 12
Des Weiteren ist es zusätzlich zu dem Erfordernis, dass der Bus_Info_Block, das Quellverzeichnis und die Einheitsverzeichnisse vorliegen, auch vonnöten, dass ein Modellverzeichnis vorliegt (beispielsweise Tabelle 13 unten). Die folgenden Felder (definiert in IEEE1212r, werden für alle Knoten benötigt, welche die EIA-775-Beschreibung unterstützen: Modell_ID, Text-Beschreibung für Moddll_ID. Auf den Modell-Verzeichnis-Abschnitt des ROMs wird durch das Absetzfeld Modell_Verzeichnis in dem Quell-Verzeichnis verwiesen.
Tabelle 13 Modell_Verzeichnis
Wie hier verwendet, schließen in einem Beispiel Dienste, bereitgestellt durch das Netzwerk 702 oder eine oder mehrere der Verzeichnisse 704, beispielsweise Dienste, Informationen, Daten, Transaktionen, e-commerce, Datentransfer, Nachrichten, Informationen, Hersteller-Web-Seiten etc. ein, welche durch das Internet und das Word-Wide-Web zur Verfügung gestellt werden können. Andere Dienste, bereitgestellt durch andere externe Netzwerke, werden durch die vorliegende Erfindung mit beabsichtigt.
In einem weiteren Aspekt stellt die vorliegende Erfindung regionale Dienst-Hilfe in Heim-Netzwerk-Homepages auf höchster Ebene zur Verfügung und das Portal (beispielsweise ein externer Web-Server) des Herstellers für die Vorrichtung stellt Dienste für Netzwerke zur Verfügung (beispielsweise Heim-Netzwerke), welche extern zur Verfügung gestellte Logos oder Icons in ihrer Heim-Netzwerk-GUI auf höchster Ebene (wie oben beschrieben) zur Verfügung stellen. Die regionale Dienst-Hilfe basiert auf dem verbunden externen Web-Server, wobei die Funktionalität auch in dem GUI-Beschreibungs-Erzeugungs-Agent (UIDGA) eingebaut ist. Der regionale Dienst stellt vorteilhafte Eigenschaften zur Verfügung, beispielsweise für Heim-Netzwerke, da typische Informationen und Dienste durch die Region lokalisiert sind. Beispielsweise kann solche Information lokale Neuigkeiten umfassen, Wetterinformation, etc. und Dienste können Kabel-Dienste, Internet-Dienste, lokales TV-Programm, etc. umfassen. Als solche können Hersteller, welche extern zur Verfügung gestellte Logos oder Icons einschließen, in ihrem Heim-Netzwerk-GUI auf höchster Ebene des Weiteren regionale Dienst-Hilfen einschließen, basierend auf dem verknüpften externen Web-Server.
In einer Implementation wird der Redirection-Identification-Code (RIC), beispielsweise ein regionaler Identifizier-Code, eingesetzt für die Benutzer-Schnittstellen-Vorrichtungen 11 in dem Heim-Netzwerken, um ihre geografischen Orte zu identifizieren, unter Verwendung von beispielsweise einer einmaligen Benutzer-Konfiguration oder einer automatischen Konfiguration. Beispielsweise können Flächen-Code, IP-Adresse oder Zip-Code als RIC eingesetzt werden. Die Wahl unterschiedlicher RICs beeinträchtigt nicht die regionale Dienst-Hilfe.
Nun wird auf 17 und 19 Bezug genommen; in einer Ausführungsform stellt die vorliegende Erfindung regionale Dienst-Hilfe in einem Homepage-erzeugenden Prozess auf höchster Ebene eines Heim-Netzwerkes zur Verfügung und Portal-Dienste des Herstellers der Vorrichtung unter Verwendung von Zip-Code. Regionaler Dienst wird unterstützt in dem Homepage erzeugenden Prozess auf höchster Ebene UIDGA, wobei RIC erhalten wird (Schritt 820) und in HTTP-Verknüpfungen eingebettet wird, für externe Web-Dienste durch den Homepage erzeugenden Prozess auf höchster Ebene UIDGA in der Seite auf höchster Ebene 250 (beispielsweise 16) (Schritt 822). Der Browser 410 stellt das GUI 220 dar, basierend auf der Seite auf höchster Ebene 250 (Schritt 824). Portal-Dienste des Herstellers 908 unterstützen regionalen Dienst, wobei die regionale Dienst-Umleitung durch besagtes Hersteller-Portal, basierend auf RIC, in HTTP-Ab fragen eingeschlossen ist von den Heim-Vorrichtungen 11. Wenn ein Benutzer eine externe Verknüpfung eines Kabel-Dienstes in der Homepage auf höchster Ebene 250 in einer Benutzer-Schnittstellen-(UI)-Vorrichtung 11 (Schritt 826) klickt, verwendet die Vorrichtung 11 den Hyperlink für das Portal 908, um eine HTTP-Anfrage mit RIC an das Portal 908 (Schritt 828) zu senden. Nachdem die RIC/lokale Dienst-Provider-Datenbank 900 durchsucht worden ist, leiten Umleitungsprogramme 904 in dem Hersteller-Portal 908 die HTTP-Anfragen an ein Ziel-Portal 910 in dem externen Netzwerk 702 um, basierend auf dem RIC (Schritte 830, 832), wobei in einem Beispiel relativ zum Portal 908 das Ziel-Portal 910 für die Vorrichtung 11 ist. Anschließend zeigt der Browser 410 die Web-Seite des lokalen Kabel-Dienst-Providers für den spezifischen Ort des Benutzers (die Region) an. Portal-Dienste des Herstellers unterstützen regionale Dienste, wobei regionale Dienst-Umleitung durch besagtes Hersteller-Portal, basiert auf RIC in den HTTP-Abfragen von Heim-Vorrichtungen 11 eingeschlossen ist. Das externe Netzwerk kann multiple Portale 908 umfassen und multiple Portale 910.
Nun wird auf 18 und 20 Bezug genommen; das RIC einer Vorrichtung 11 wird erhalten, wenn die Vorrichtung 11 sich in das Home-Portal 908 einwählt, das Portal 908 erhält den Telefon-Gebiets-Code (area code) (beispielsweise durch Anrufer-ID) (Schritt 840). Das Portal 908 kann Area-Codes für ein anderes RIC kartieren, beispielsweise Zip-Code, und der Software-Agent 902 in der Vorrichtung 11 empfängt das RIC. Die weiteren Schritte 842–852 in 20 sind ähnlich wie die Schritte 822–832 in 19 und werden nicht wiederholt.
In einem beispielhaften Szenario, wenn ein Benutzer mit einer Benutzer-Schnittstellen-Vorrichtung 11, wie z.B. einem Samsung(TM) HDTV 102 in Los Angeles, ein externes Link-Icon klickt, beispielsweise für Kabel-Dienste, wird eine HTTP-Anfrage (Aufforderung) an das Samsung-Heim-Netzwerk-Portal mit dem RIC in der URL von diesem HDTV 102 gesendet, wobei besagtes Samsung-Portal die Anfrage umleitet, beispielsweise an einen Kabel-Dienst-Provider in Los Angeles, basierend auf diesem RIC. Das Samsung-Portal leitet die Anfrage an einen Kabel-Dienst, lokal für diesen HDTV 102 weiter, basierend auf dem RIC in der Anforderung. In diesem beispielhaften Prozess empfängt das Samsung-Portal den RIC der erhaltenen HTTP-Nachricht oder nach der Nachricht. Als solcher weist in diesem Beispiel ein HDTV 102 in einem Netzwerk 300 in New York einen unterschiedlichen RIC auf im Vergleich zu einem HDTV 102 in Los Angeles in einem anderen Netzwerk 300, wobei jedes RIC die geografische Fläche eines HDTV anzeigt. Das Portal 908 leitet die Anfragen für Dienste von jedem HDTV in unterschiedlichen geografischen Gebieten zu einem Portal 910 um, lokal für den abfragenden HDTV, basierend auf dem RIC dieses HDTV (21).
Wie beschrieben, wird ein regionaler Identifizier-Code (RIC) für UI-Vorrichtungen 11 eingesetzt, um geografische Orte von solchen Vorrichtungen 11 in unterschiedlichen Netzwerken zu identifizieren. Der RIC kann beispielsweise einen Zip-Code (5stellig oder 9stellig) umfassen, einen Telefon-Gebiet-Code (phone area code), eine IP-Adresse der Vorrichtung oder des Heim-Netzwerks, eine IP-Adresse des Dienst-Providers oder irgendeine andere Identifizier-Information. Der RIC kann auch eine Kombination der oben genannten Beispiele umfassen. Beispielsweise kann unter Verwendung eines Zip-Codes oder eines Telefon-Gebiet-Codes die geografische Lage der UI-Vorrichtung und der lokale Service-Provider in dem geografischen Gebiet bestimmt werden. Da jeder lokale Internet-Dienst-Provider (ISP, Internet Service Provider) typischerweise fixierte IP-Adressen zugeordnet hat oder einen IP-Adress-Block und sie des Weiteren bestimmte IP-Adressen oder Blöcke einem regionalen Gebiet zuordnen, ermöglicht dies die Bestimmung des ISPs und der Region-Information einer IP-Adresse. Das Portal kann diese regionale Information nutzen, um des Weiteren die Web-Seite auf dem lokalen Service-Provider zur Verfügung zu stellen (beispielsweise Kabel oder andere Dienste). In einer Version wird beispielsweise ein 5stelliger Zip-Code verwendet als RIC, während in einer anderen Version beispielsweise ein 9stelliger Zip-Code eingesetzt wird für detaillierte grafische Information. Die Auswahl von 5stelligen oder 9stelligen Zip-Codes beeinflusst nicht die regionale Dienst-Hilfe. Die Auswahl zwischen Zip-Code, Gebiet-Code, IP-Adresse oder anderen möglichen Codes beeinflusst nicht die regionale Dienst-Hilfe, wie hier beschrieben.
Für Portal-Dienste mit regionaler Hilfe unterstützen in einem Beispiel Portal-Dienste des Herstellers für Heim-Vorrichtungen den regionalen Dienst (d.h. den regional umgeleiteten Dienst), basierend auf dem RIC, eingeschlossen in der HTTP-Anforderung von den Heim-Vorrichtungen 11. Das Portal mit regionaler Unterstützung leitet die HTTP-Anfrage an eine URL um, welche lokal zur Anfrage, basierend auf dem RIC ist.
Nachdem der UIDGA das Verzeichnis auf höchster Ebene 250 in 16 ausbildet (das Verzeichnis 250, einschließend Portal-Adresse, RIC und Hyperlinks zum Erhalten von Namen- und Logo-Information von dem Portal für externe Dienste), übermittelt, wenn der Browser 410 dies ausführt, das Portal HTML-Dateien (logoicon1.html 710A, logoname1.html 712A, etc.) für Icon und Namen, welche externe Dienste für die Vorrichtung 11 repräsentieren, zur Darstellung auf dem GUI 220. Diese html-Dateien 710A, 712A können von der gleichen Web-Seite oder von unterschiedlichen Web-Seiten stammen (beispielsweise allgemeine Web-Seite, wie z.B. die Portal- oder Dienst-Provider-Web-Seite). Nun wird auf 17–18 Bezug genommen; wenn danach ein Benutzer auf einen externen Link klickt, wie z.B. ein Kabel-Dienst-Icon auf dem GUI 220 der Vorrichtung 11 (beispielsweise HDTV), sendet ein Hyperlink, assoziiert mit diesem Icon, eine Anfrage, einschließend RIC der Vorrichtung 11 an das Portal 908 mit regionaler Hilfe und dieses Portal 908 bestimmt, basierend auf dem RIC, die Region der Vorrichtung 11.
In einer ersten Ausführungsform der Umleitung leitet das Portal 908 dann die Anfrage an einen Kabel-Dienst-Provider 910 in der lokalen Region um (oder irgendeiner anderen gewünschten Region), assoziiert mit dem RIC. Beispielsweise leitet das Portal 908 die Anfrage an die URL des Kabel-Dienst-Providers 910 (beispielsweise ATT), wobei der Browser 410 in der Vorrichtung 11 umgeleitet wird auf den Kabel-Dienst-Provider 910. Nach der Umleitung durch das Portal 908 wird die Web-Seite des Kabel-Dienstes 910 auf der Vorrichtung 11 zur Interaktion des Benutzers dargestellt. Die HTTP-Umleitung umfasst die Vorrichtung 11, welche an das Server-Portal 908 eine HTTP-Anfrage sendet (einschließend RIC) für ein URL für den Dienst und basierend auf dem RIC in der Abfrage stellt das Portal 908 eine neue URL des Dienst-Provider-Portals zur Verfügung für Dienste, welche lokal für die Vorrichtung 11 sind, wobei der Browser 410 die Inhalte der Web-Seite des Ziel-Service-Providers 910 an der URL der Vorrichtung 11 zeigt.
In einer zweiten Ausführungsform der Umleitung schließt das Portal 908 Sätze von html-Dateien 906 (einschließend Icon, Namen, URLs) ein, welche assoziiert sind mit Dienst-Providern 910. Die html-Dateien werden kategorisiert, basierend auf RIC, so dass es einen Satz von html-Dateien 906 gibt, welche mit einem jedem RIC korrespondieren. Nach Empfangen einer HTTP-Anfrage mit RIC von einer Vorrichtung 11 verwendet das Portal 908 den RIC, um die korrespondierenden html-Dateien 906 in dem Portal 908 zu finden und sendet die html-Dateien 906, assoziiert mit einem Ziel-Portal 910 an den Browser 410 der Vorrichtung 11 zur Darstellung. Die html-Dateien 906 schließen beispielsweise Icon, Namen und URL des Ziel-Portals 910, welches lokal für die Vorrichtung 11 ist, ein. Danach wird, wenn der Benutzer auf das Icon/den Namen des Ziel-Portals, dargestellt durch den Browser 410, klickt, wird die Vorrichtung 11 an die URL des Ziel-Portals 910 geleitet.
In einer Implementation arbeiten zwei Umleitungsprogramme 904 mit der Bezeichnung logoiconX und logonameX (für Umleitungs-Anfragen, basierend auf RIC) in dem Portal System 908 des externen Netzwerks 702 (7) für jeden Dienst (beispielsweise Kabel, ISP, Telefon, etc.). Die Portalseite 908 hat Zugang zu einer Datenbank des RICs 900 und lokalen Dienst-Providern, so dass das Portal 908 den korrespondierenden Dienst-Provider 910 für unterschiedliche RICs suchen kann und HTTP-Anfragen für eine jede Vorrichtung 11, basierend auf dem RIC dieser Vorrichtung, umleiten kann (zum Darstellen der lokalen Dienst-Provider-Information für diese Region auf der Vorrichtung 11). Beispielsweise kann für Zip-Code oder Phone-Gebiet-RIC die Datenbank 900 eine Suchtabelle von ZIP/lokalen Diensten oder Gebiet-Code/Lokalen Diensten für jeden Dienst sein und für IP-Adressen kann es sich um eine Datenbank von IP-Adressen/lokalen Dienst-Providern/HTML-Nehmen in dem Portal 908 (dem Heim-Portal) handeln. Die Datenbank 900 wird aktualisiert durch die Dienst-Provider, wie z.B. Kabel-Provider oder ISPs 910.
Das RIC wird eingebettet in die Heim-Netzwerk-Homepage auf höchster Ebene 250 in dem Homepage-erzeugenden Prozess durch das UIDGA 408. Wenn ein Benutzer auf einen RIC-eingebetteten HTTP-Link auf der Seite 220 zugreift beispielsweise durch anklicken), wird die HTTP-Anforderung, einschließend ein RIC, an das Portal 908 in dem externen Netzwerk 702 gesandt. Nach Empfangen der HTTP-Anfrage mit eingebettetem RIC: (1) leitet in der ersten Implementation der Umleitung, wie oben beschrieben, jedes Umleitungsprogramm 904 (beispielsweise logoiconX und logonameX) auf dem Portal 908 die Anfrage an die URL des Portal-Dienstes 910 außerhalb des Portals 908 um, basierend auf den RICs (beispielsweise korrespondierend mit den korrekten lokalen Dienst-Providern) oder (2) in der zweiten Implementation der Umleitung, wie oben beschrieben, verwendet jedes Umleitungs-Programm 904 besagte html-Datei 906 zur Umleitung, wobei beispielsweise das logoiconX-Programm die HTTP-Anfrage von einer jeden Vorrichtung 11 (beispielsweise HTTV 102) an eine html-Datei 906 umleitet, korrespondierend mit dem RIC in der Vorrichtung 11 in der HTTP-Abfrage in dem Portal 908, wobei die html-Datei 906 eine Verknüpfung zu einem Ziel-Dienst-Provider 910 einschließt (beispielsweise Att.com), korrespondierend mit dem RIC. In einem Beispiel sendet das Portal 908 die html-Dateien 906, assoziiert mit dem Ziel-Portal 910 an den Browser 410 der Vorrichtung 11 zur Darstellung. Die html-Dateien 906 schließen beispielsweise Icon, Name und URL des Ziel-Portals 910, lokal für die Vorrichtung 11, ein. Anschließend wird, wenn der Benutzer auf das Icon/den Namen des Ziel-Portals klickt, welcher durch den Browser 410 dargestellt wird, die Vorrichtung an die URL des Ziel-Portals 910 geleitet.
Die Umleitungsprogramme können programmiert werden unter Verwendung von irgendeiner geeigneten Programmiersprache, wie z.B. Java. Es kann viele Ziele (beispielsweise URLs) geben, welche für ein Umleitungsprogramm verfügbar sind (beispielsweise LogoinconX oder logonameX), um eine Anfrage umzuleiten. Das gleiche Umleitungsprogramm kann umleiten unter Verwendung unterschiedlicher Arten von RICs, beispielsweise 5stelligem Zip-Code, 9stelligem Zip-Code, Gebiet-Code oder IP-Adresse. Daher können sogar vermischte RICs für die regionale Dienst-Hilfe verwendet werden.
Apendix 14 zeigt ein Beispiel eines Umleitungsprogramm-Beispiels in Java Servlet, wobei das Umleitungsprogramm als go.java bezeichnet wird (gleiche Funktion als das logoiconX- oder logonameX-Programm). Die Umleitungs-URL für das Programm ist http://ip adress/servlet/go und diese wird die Seite unmittelbar beispielsweise an den lokalen Dienst-Provider www.att.com umleiten. Der RIC-Code kann leicht in der URL-Anfrage hinzugefügt werden, wie z.B. http://ip address/servlet/go?arecode=408, so dass dann das folgende Programm verändert werden kann, um den RIC-Code zu erhalten, die Datenbank zu durchsuchen, die korrekte URL zu erhalten und dann umzuleiten.
Vorrichtungs-Icon-Räume, welche in der Heim-Netzwerk-Verzeichnis-Seite auf höchster Ebene 250 nicht genutzt werden, können mit Dienst-Logos oder Icons oder Namen eines externen Portals 908 gefüllt werden (beispielsweise einer Web-Seite), welche durch Vorrichtungen 704 im externen Netzwerk 702 (7) zur Verfügung gestellt werden. Beispielsweise kann es bis zu 12 nicht verwendeten Icon-Räumen auf der Seite 250 (16) für ein minimales Netzwerk geben, welches eine UI-Vorrichtung 11 einschließt. In diesem Fall gibt es ein Minimum von 12 Sätzen von Umleitungsprogrammen auf dem Portal, welche für unterschiedliche HTML-File dienen, enthaltend logo-Grafik und logo-Namen für die IRC-basierte GUI 220 (12). Besagte Umleitungsprogramme können in unterschiedlichen Arten und Weisen implementiert werden wie z.B. CGI Script/Programm, Java Servlet/Programm, ASP, etc. In einem Beispiel haben die Umleitungsprogramm-Datei-Namen eine Zahl von 1 bis 12 (z.B. logoicon1 bis logoicon12, logoname1 bis logoname12) und auf sie in einer sequenziellen Reihenfolge, beginnend mit Nr. 1, zugegriffen.
Ein Software-Agent in einer jeden UI-Vorrichtung (17–18) kann die RICs verfügbar machen für den Heim-Netzwerk-Homepage-Generator auf höchster Ebene UIDGA. Anschließend wird der RIC eingebettet in die Heim-Netzwerk-Homepage auf höchster Ebene 250 (beispielsweise 16) in dem Homepage-erzeugenden Prozess durch den UIDGA 408. Ein voreingestellter RIC kann beispielsweise alle Nullen umfassen. Das Heim-Netzwerk kann den Identifiziercode auf UI-Vorrichtungen 11 ausdehnen unter Verwendung der gleichen Art von RIC, beispielsweise über einen Vorrichtung-zu-Vorrichtung-Steuermechanismus.
In einer Implementation des UIDGAs für einen regionalen Dienst werden Umleitungs-Programm-Namen in dem Portal-Server, wie z.B. logoiconX (z.B. logoicon1, logoicon2. etc.) und logonameX (z.B. logoname1, logoname2, etc.) verwendet anstelle der Logo- und Namen-Links in den Logo-Abschnitten und Namen-Abschnitten auf der Seite 250. Diese Umleitungsprogramme leiten die Anfrage für spezifische HTML-Dateien entsprechend des RICs um. Die Namen der logoicon1.htm-, logoname1.htm-, logoicon2.htm-, logoname2.htm-Dateien etc. sind nicht standardisiert. Die Umleitungsprogramme 904 (logoiconX und logonameX) in dem Portal-Server 908 leiten die Anfrage in Richtung von Ziel-URLs für einen jeden lokalen Dienst-Provider entsprechend dem RIC um (beispielsweise leiten eine Portal-Anfrage an eine lokale Kabel-Portal-Seite um).
In dem Beispiel oben verwendet, wenn eine Anfrage für beispielsweise einen Kabel-Dienst von einer Vorrichtung 11 durch das Samsung-Portal empfangen wird, das Portal die RIC-Information in der Abfrage und anstelle der Bereitstellung der verlangten Information von seinem eigenen Portal (beispielsweise yahoo.com oder amazon.com), basierend auf dem RIC des Portals, erfolgt eine Umleitung der Anfrage auf ein lokales Kabel-Dienst-Portal für Dienste, so dass der Dienst lokalisiert wird, basierend auf der regionalen RIC-Information.
Wie oben beschrieben, wird ein Aspekt des Bereitstellen von regionalem Dienst in dem Homepage-erzeugenden Prozess auf höchster Ebene UIDGA unterstützt, wobei ein RIC eingebettet ist in die HTTP-Abfrage für externe Web-Server 908 des Netzwerkes 702 in der Homepage auf höchster Ebene 220. Beispielsweise kann, falls der CGI-Typ vom Umleitungsprogramm logoiconX und logonameX auf dem Portal eingesetzt wird, die Icon-Umleitungs-URL beispielsweise umfassen:
http://209.157.0.2/cgi-bin/logoicon1?zip=95134, oder
http://209.157.0.2/cgi-bin/logoicon1?zip-951342111, oder
http://209.157.0.2/cgi-bin/logoicon1?ipaddress=165.35.2.1 oder
http://209.157.0.2/cgi-bin/logoicon1?areaCade=408.
In ähnlicher Art und Weise kann die Namen-Umleitungs-URL beispielsweise umfassen:
http://209.157.0.2/cgi-bin/logoname1?zip=95134, oder
http://209.157.0.2/cgi-bin/logoname1?zip=951342111, oder
http://209.157.0.2/cgi-bin/logonamel1?ipaddress=165.35.2.1, oder
http://209.157.0.2/cgi-bin/logoname1?areaCode=408.
In dem Prozess des Erzeugens einer Homepage auf höchster Ebene schließt der UIDGA den RIC (beispielsweise Zip-Code) der laufenden UI-Vorrichtung 11 in den HTTP-Link (beispielsweise logoicon2?zip=95134 in 16) ein.
RiCs können erhalten werden und aufgebaut werden in den folgenden zwei Beispielverfahren. Das erste Verfahren umfasst eine einmalige Benutzer-Konfiguration, wie durch das Beispiel in 17 und 19 gezeigt wird, wobei der Benutzer den RIC-Code, wie z.B. Zip-Code oder Gebiet-Code in einen Software-Agent 902 eingeben kann in einem einmaligen Setup-Schritt. Das zweite Verfahren umfasst die automatische Konfiguration mit der Hilfe von Dienst-Providern, wie in 18 und 20 dargestellt. Ein RIC-Software-Agent 902 in der UI-Vorrichtung 11 (beispielsweise HDTV) kann das RIC von dem Dienst-Provider automatisch sammeln, beispielsweise unter Verwendung eines Trace-Route-Programms 912 in dem Portal 908. In Fällen, wo der RIC einen Gebiets-Code oder einen Zip-Code umfasst, kann besagter Software-Agent 902 in einer UI-Vorrichtung 11 (beispielsweise HDTV 102) einen Einwähl-Telefonanruf (drahtbasiert oder drahtlos, direkt von der Vorrichtung oder durch das Heim-Netzwerk) an das Heim-Portal 908 aktivieren. Das Heim-Portal 908 kann den Gebiet-Code, beispielsweise unter Verwendung der Anrufer-ID, erhalten. Das Portal 908 kann des Weiteren den Gebiets-Code für den Zip-Code kartieren. Der Software-Agent 902 in der Vorrichtung 11 kann diese Information erhalten, beispielsweise den Gebiets-Code oder den Zip-Code als RIC zur Verwendung durch das UIDGA 408. Wo das RIC eine Vorrichtung oder eine Heim-Netzwerk-IP- Adresse umfasst, kann der Software-Agent 902 in dem HDTV 102 die IP-Adresse von dem HDTV 102 direkt oder vom Heim-Netzwerk erhalten, sie dann als RIC für das HDTV 102 verwenden.
In Fällen, wo die ServiceProvider-IP-Adresse als RIC verwendet wird, kann die IP-Adresse des Dienst-Providers auch als RIC verwendet werden. Zuerst kann der RIC-Software-Agent 902 in dem HDTV 102 ein TraceRoute-Programm 912 in einer Portalseite 908 des externen Netzwerks 702 aufrufen und dann die intermediäre IP-Adressliste abfragen. Anschließend wählt der RIC-Software-Agent 902 die IP-Adresse des Dienst-Providers 910 von der Liste entsprechend einem Kriterium aus (beispielsweise die nächstgelegene IP-Adresse mit einem Domännamen, welcher mit ".net" endet, kann ausgewählt werden). Anschließend kann diese IP-Adresse oder sogar der Domänenname als RIC verwendet werden. Die beispielhaften Schritte können verwendet werden, unabhängig vom Typ des RICs.
Ein Beispiel-Trace-Route-Programm 912 ist in Appendix 13 gezeigt, wobei nach Benutzer-Konfiguration oder automatischer Konfiguration der RIC-Code gespeichert wird in der UI-Vorrichtung 11 (beispielsweise auf einer Festplatte darin). Das Trace-Programm 912 tracet alle Hubs, Gateways und Routers, durch welche eine Nachricht läuft, wenn sie sich ausbreitet, beispielsweise das Internet, um zu erkennen, dass beispielsweise die Nachricht durch den Kopf-End-Router des Kabels gelangt ist, was die Identifikation des Kabel-Providers ermöglicht. Falls die Anfrage/Nachricht durch Router des TCIs gelangt ist, leitet das Portal zum Portal des TCIs um.
Obwohl in den Beispielen, wie hier beschrieben, die Umleitung von einem Portal zu Ziel-Portalen auf einem regionalen Identifizier-Code basiert, kann in einem weiteren Beispiel die Umleitung von einem Portal zu einem anderen auf anderer Information basieren, zusätzlich oder anstelle von einem Ort oder einer Region einer Vorrichtung 11. Solch eine andere Information kann beispielsweise Information umfassen (beispielsweise Alter, Erziehung etc.) betreffend den Benutzer einer Vorrichtung 11, wobei die Umleitung in Richtung von Ziel-Portalen auf solch einer Information basiert. Des Weiteren kann der Ziel-Dienst-Provider entweder extern für das Portal 908 sein oder innerhalb des Ziel-Portals 908 zur Bereitstellung von Diensten. Daher können die Umleitungsprogramme 904 in dem Portal 908 eine Anfrage von einer Vorrichtung 11 umleiten zu einem Dienst- Provider innerhalb des Portals 908 oder in Richtung von Portal 910, welche extern für das Portal 908 sind.
Die Appendizes 15, 6, 7, 8, 16, 17, 18 und 19 sind illustrative Beispiele für htm-Dateien zum Erzeugen der Heim-Netzwerk Benutzer-Schnittstellen-Beschreibung auf höchster Ebene und des GUIs in den 13 und 16, einschließend externe Links mit regionaler Hilfe.
Obwohl die vorliegende Erfindung beschrieben wurde in merklichem Detail mit Blick auf bevorzugte Versionen davon, sind andere Versionen möglich.
Das Verfahren und System zum Bereitstellen von Vorrichtungs-Kommunikation und Steuerung in einem Heim-Netzwerk, verknüpft mit einem externen Netzwerk mit regionalem Support kann gemäß der vorliegenden Erfindung angewandt werden auf Heim-Netzwerke mit Multimedia-Vorrichtungen, welche daran verknüpft sind, beispielsweise PC, VCR, Camcorder, DVD und HDTV, etc.
Appendix 1 – Beispiel für eine Seite auf höchster Ebene
Appendix 2 – Beispiel für Background.htm
Appendix 3 – Beispiel für Icon.htm
Appendix 4 – Beispiel für Name.htm
Appendix 5 – Beispiel für eine Seite auf höchster Ebene TLNUID (index.htm)
Appendix 6 – Beispiel für background.htm
Appendix 7 – Beispiel für icon.htm
Appendix 8 – Beispiel für name.htm
Appendix 9 – Beispiel für logoicon1.htm
Appendix 10 – Beispiel für logoname1.htm
Appendix 11 – Beispiel für logoicon2.htm
Appendix 12 – Beispiel für logoname2.htm
Appendix 13 – Beispiel für ein Perl-Program für Trace Route Ein Beispiel für ein Perl-Trace-Route-Programm für regionale Dienste unter Verwendung von Dienst-Provider-IP-Adresse als RIC.
Appendix 14 – Beispiel für Umleitungsprogramme
Appendix 15 – Beispiel für eine Seite auf höchster Ebene TLNUID (index.htm)
Appendix 16 – Beispiel für logoicon1.htm
Appendix 17 – Beispiel logoname1.htm
Appendix 18 – Beispiel für logoicon2.htm
Appendix 19 – Beispiel für logoname2.htm

Claims

Verfahren zum Bereitstellen von Benutzerschnittstellen in einem ersten Netzwerk, das erste Vorrichtungen, die über ein Kommunikationsmedium miteinander verbunden sind, sowie wenigstens eine Schnittstellenvorrichtung enthält, die das erste Netzwerk mit wenigstens einem zweiten Netzwerk verbindet, das Dienste bereitstellt, wobei die Benutzerschnittstellen dazu dienen, die Vorrichtungen zu steuern, die momentan mit dem ersten Netzwerk verbunden sind, und Dienste des zweiten Netzwerks wenigstens einem Benutzer bereitzustellen, wobei es die folgenden Schritte umfasst: in jeder von einer oder mehreren ersten Vorrichtungen in dem ersten Netzwerk: a) Beziehen von Informationen von einer oder mehreren der ersten Vorrichtungen, die momentan mit dem ersten Netzwerk verbunden sind, wobei die Informationen Vorrichtungsinformationen enthalten, und b) Erzeugen einer Benutzerschnittstellenbeschreibung, die enthält: 1) wenigstens einen Bezug, der mit den Vorrichtungsinformationen jeder der einen oder mehreren ersten Vorrichtungen verknüpft ist, 2) wenigstens einen Umleitungs-Identifizierungscode (redirection identification code – RIC), der dieser ersten Vorrichtung entspricht, und 3) wenigstens einen Bezug, der mit den durch das zweite Netzwerk bereitgestellten Diensten verknüpft ist.
Verfahren nach Anspruch 1, wobei das erste Netzwerk ein 1394-Netzwerk umfasst und das zweite Netzwerk ein Nicht-1394-Netzwerk umfasst.
Verfahren nach Anspruch 1 oder 2, wobei die Schnittstellenvorrichtung eine Gateway-Vorrichtung umfasst.
Verfahren nach einem der Ansprüche 1–3, wobei das zweite Netzwerk eine Vielzahl miteinander verbundener zweiter Vorrichtungen umfasst, die einen oder mehrere Dienste bereitstellen.
Verfahren nach Anspruch 4, wobei jede der zweiten Vorrichtungen wenigstens ein Computersystem umfasst, das zum Bereitstellen von Diensten programmiert ist.
Verfahren nach Anspruch 4 oder 5, wobei das zweite Netzwerk das Internet umfasst, und wenigstens eine der zweiten Vorrichtungen, die Dienste bereitstellen, einen oder mehrere Web-Server umfasst, die Dienste bereitstellen.
Verfahren nach Anspruch 6, wobei ein Dienst, der durch wenigstens eine der mit dem zweiten Netzwerk verbundenen Vorrichtungen bereitgestellt wird, einen Website-Dienst umfasst.
Verfahren nach einem der Ansprüche 1–7, wobei jeder Bezug in der Schnittstellenbeschreibung, die mit den durch das zweite Netzwerk bereitgestellten Diensten verknüpft ist, wenigstens einen Hyperlink zu Dienstinformationen in dem zweiten Netzwerk umfasst.
Verfahren nach einem der Ansprüche 1–8, das des Weiteren den folgenden Schritt einschließt: a) Anzeigen einer Benutzerschnittstelle auf Basis der Benutzerschnittstellenbeschreibung auf einer Vorrichtung, die mit dem ersten Netzwerk verbunden und in der Lage ist, eine Benutzerschnittstelle anzuzeigen, zur Benutzersteuerung der ersten Vorrichtungen und zur Kommunikation mit dem zweiten Netzwerk.
Verfahren nach Anspruch 9, wobei der Schritt des Anzeigens jeder Benutzerschnittstelle des Weiteren die folgenden Schritte einschließt: Verwenden jedes Bezugs in der entsprechenden Benutzerschnittstellenbeschreibung, um auf die damit verknüpften Informationen in jeder ersten Vorrichtung zuzugreifen; Verwenden jedes Bezugs, der mit durch das zweite Netzwerk bereitgestellten Diensten verknüpft ist, um auf entsprechende Dienstinformationen zuzugreifen; wobei Erzeugen der Benutzerschnittstelle einschließt: 1) Informationen, die jeder ersten Vorrichtung entsprechen und die Informationen in jeder ersten Vorrichtung verwenden, auf die zugegriffen wird, und 2) Dienstinformationen; und Anzeigen der Benutzerschnittstelle auf der Vorrichtung, die in der Lage ist, eine Benutzerschnittstelle anzuzeigen.
Verfahren nach Anspruch 10, wobei: der Schritt des Zugreifens auf Dienstinformationen die Schritte des Verwendens jedes Bezugs einschließt, der mit durch das zweite Netzwerk bereitgestellten Diensten verknüpft ist, um auf Basis des RIC in der Benutzerschnittstellen-Beschreibung auf entsprechende Dienstinformationen zuzugreifen; und der Schritt des Erzeugens der Benutzerschnittstelle des Weiteren Erzeugen der Benutzerschnittstelle einschließlich Dienstinformationen auf Basis des RIC einschließt.
Verfahren nach Anspruch 1, wobei der Schritt des Erzeugens einer Benutzerschnittstellenbeschreibung des Weiteren die folgenden Schritte umfasst: Verknüpfen eines Hyperlinks mit den Vorrichtungsinformationen einer oder mehrerer der ersten Vorrichtungen, und Verknüpfen wenigstens eines Hypertext-Links mit den durch das zweite Netzwerk bereitgestellten Dienstinformationen.
Verfahren nach einem der Ansprüche 1–12, wobei: 1) die Vorrichtungsinformationen in jeder ersten Vorrichtung in dem ersten Netzwerk eine Benutzerschnittstellenbeschreibung zur Benutzer-Interaktion mit dieser Vorrichtung enthalten, und 2) die Dienstinformationen in dem zweiten Netzwerk eine Vielzahl von Benutzerschnittstellen-Beschreibungen zur Benutzer-Interaktion mit einer Vielzahl von Diensten auf Basis von RIC einschließen.
Verfahren nach Anspruch 1, wobei jeder Bezug, der mit durch das zweite Netzwerk bereitgestellten Diensten verknüpft ist, wenigstens einen Hyperlink zu Dienstinformationen in dem zweiten Netzwerk umfasst, und die Dienstinformationen wenigstens Identifizierungsinformationen umfassen, die Dienste auf Basis von RIC darstellen.
Verfahren nach Anspruch 14, wobei die Identifizierungsinformationen wenigstens eine Logo-Informationsdatei umfassen, die Links zu einer Logo-Grafik enthält, die die Dienste darstellt.
Verfahren nach einem der Ansprüche 1–15, wobei das zweite Netzwerk wenigstens ein erstes Portal zum Bereitstellen von Diensten enthält und ein Bezug in der Benutzerschnittstellenbeschreibung, der mit durch das zweite Netzwerk bereitgestellten Diensten verknüpft ist, wenigstens einen Hyperlink zu dem ersten Portal umfasst und das erste Portal Dienstinformationen enthält, die wenigstens Identifizierungsinformationen umfassen, die durch das erste Portal bereitgestellte Dienste darstellen.
Verfahren nach Anspruch 16, wobei die Identifizierungsinformationen in dem ersten Portal des Weiteren wenigstens einen Hyperlink zu durch ein zweites Portal in dem zweiten Netzwerk bereitgestellten Dienstinformationen umfassen.
Verfahren nach Anspruch 17, wobei die Identifizierungsinformationen in dem ersten Portal des Weiteren wenigstens einen Hyperlink zu durch wenigstens ein zweites Portal in dem zweiten Netzwerk bereitgestellten Dienstinformationen auf Basis von RIC umfassen.
Verfahren nach einem der Ansprüche 16–18, wobei das zweite Netzwerk eine Vielzahl miteinander verbundener Computersysteme umfasst, die zum Bereitstellen von Diensten programmiert sind; das erste Portal eines oder mehrere der Computersysteme umfasst, die Dienste des ersten Portals bereitstellen; und das zweite Portal eines oder mehrere der Computersysteme umfasst, die Dienste des zweiten Portals bereitstellen.
Verfahren nach einem der Ansprüche 1–15, wobei das zweite Netzwerk wenigstens ein erstes Portal und wenigstens einen Ziel-Service-Provider zum Bereitstellen von Diensten enthält und das Verfahren des Weiteren die folgenden Schritte umfasst: Anfordern von Dienst von dem zweiten Netzwerk durch Senden einer Anforderung, die einen RIC enthält, durch wenigstens eine erste Vorrichtung zu dem ersten Portal unter Verwendung eines Bezugs in der Benutzerschnittstellen-Beschreibung, Bestimmen eines Ziel-Service-Providers auf Basis des empfangenen RIC durch das erste Portal, und Umleiten der Anforderung zu dem Ziel-Service-Provider durch das erste Portal.
Verfahren nach Anspruch 20, wobei sich der Ziel-Service-Provider in dem zweiten Netzwerk innerhalb des ersten Portals befindet.
Verfahren nach Anspruch 20, wobei sich der Ziel-Service-Provider in dem zweiten Netzwerk außerhalb des ersten Portals befindet.
Verfahren nach einem der Ansprüche 20–22, wobei ein Bezug, der mit durch das zweite Netzwerk bereitgestellten Diensten verknüpft ist, wenigstens einen Hyperlink zu dem ersten Portal umfasst und das erste Portal Dienstinformationen enthält, die wenigstens Umleitungsinformationen auf Basis von RIC zu durch andere Service-Provider in dem zweiten Netzwerk bereitgestellten Diensten umfassen.
Verfahren nach einem der Ansprüche 20 bis 23, wobei das erste Portal des Weiteren eine Liste von RIC und entsprechenden Ziel-Service-Provider-Portaladressen enthält, so dass die Schritte des Bestimmens eines Ziel-Service-Providers des Weiteren die Schritte des Auffindens einer Ziel-Service-Provider-Portaladresse in der Liste, die einem empfangenen RIC entspricht, und des Umleitens der Anforderung zu der Ziel-Service-Provider-Portaladresse umfasst.
Verfahren nach Anspruch 24, wobei jede Ziel-Service-Provider-Adresse eine URL umfasst.
Verfahren nach einem der Ansprüche 1–25, das des Weiteren die Schritte des Beziehens eines RIC für wenigstens eine erste Vorrichtung von einem Benutzer umfasst.
Verfahren nach einem der Ansprüche 1–25, das des Weiteren die Schritte des automatischen Beziehens eines RIC für wenigstens eine erste Vorrichtung innerhalb des ersten Netzwerks umfasst.
Verfahren nach einem der Ansprüche 1–27, wobei für wenigstens eine erste Vorrichtung der entsprechende RIC eine Kennung umfasst, die die geografische Region der ersten Vorrichtung darstellt.
Netzwerksystem zum Durchführen von Diensten, das umfasst: ein erstes Netzwerk erster Vorrichtungen, die über ein Kommunikationsmedium miteinander verbunden sind; eine Schnittstellenvorrichtung, die das erste Netzwerk mit einem externen Netzwerk verbindet, das Dienste bereitstellt, einen Benutzerschnittstellen-Beschreibungs-Erzeugungs-Agenten in wenigstens einer der ersten Vorrichtungen, der so konfiguriert ist, dass er: a) Informationen von einer oder mehreren der ersten Vorrichtungen bezieht, die momentan mit dem lokalen Netzwerk verbunden sind, wobei die Informationen Vorrichtungsinformationen enthalten; und b) Erzeugen einer Benutzerschnittstellenbeschreibung, die enthält: 1) wenigstens einen Bezug, der mit den Vorrichtungsinformationen jeder der einen oder mehreren ersten Vorrichtungen verknüpft ist, 2) wenigstens einen Umleitungs-Identifizierungs-Code (RIC), der dieser ersten Vorrichtung entspricht, und 3) wenigstens einen Bezug, der mit den durch das externe Netzwerk bereitgestellten Diensten verknüpft ist.
Netzwerksystem nach Anspruch 29, wobei das erste Netzwerk ein 1394-Netzwerk umfasst und das externe Netzwerk ein Nicht-1394-Netzwerk umfasst.
Netzwerksystem nach Anspruch 29 oder 30, wobei die Schnittstellenvorrichtung eine Gateway-Vorrichtung umfasst.
Netzwerksystem nach einem der Ansprüche 29–31, wobei das externe Netzwerk eine Vielzahl miteinander verbundener zweiter Vorrichtungen umfasst, die einen oder mehrere Dienste bereitstellen.
Netzwerksystem nach Anspruch 32, wobei jede der zweiten Vorrichtungen wenigstens ein Computersystem umfasst, das zum Bereitstellen von Diensten programmiert ist.
Netzwerksystem nach Anspruch 32 oder 33, wobei das zweite Netzwerk das Internet umfasst, und wenigstens eine der zweiten Vorrichtungen, die Dienste bereitstellen, einen oder mehrere Web-Server umfasst, die Dienste bereitstellen.
Netzwerksystem nach Anspruch 34, wobei ein Dienst, der durch wenigstens eine der mit dem zweiten Netzwerk verbundenen Vorrichtungen bereitgestellt wird, einen Website-Dienst umfasst.
Netzwerksystem nach einem der Ansprüche 29–35, wobei jeder Bezug in der Benutzerschnittstellenbeschreibung, der mit durch das externe Netzwerk bereitgestellten Diensten verknüpft ist, wenigstens einen Hyperlink zu Dienstinformationen in dem externen Netzwerk umfasst.
Netzwerksystem nach einem der Ansprüche 29–36, wobei wenigstens eine der ersten Vorrichtungen in dem ersten Netzwerk eine Benutzerschnittstellenvorrichtung enthält, die in der Lage ist, eine Benutzerschnittstelle anzuzeigen, und die Benutzerschnittstellenvorrichtung einen Benutzerschnittstellen-Erzeugungs-Agenten enthält, der so konfiguriert ist, dass er eine Benutzerschnittstelle auf Basis der Benutzerschnittstellenbeschreibung zur Benutzersteuerung der ersten Vorrichtungen und zur Kommunikation mit dem externen Netzwerk anzeigt.
Netzwerksystem nach Anspruch 37, wobei der Benutzerschnittstellen-Erzeugungs-Agent in der Benutzerschnittstellenvorrichtung des Weiteren so konfiguriert ist, dass er: jeden Bezug in der entsprechenden Benutzerschnittstellenbeschreibung nutzt, um auf die verknüpften Informationen in jeder ersten Vorrichtung zuzugreifen; jeden Bezug, der mit durch das externe Netzwerk bereitgestellten Diensten verknüpft ist, nutzt, um auf entsprechende Dienstinformationen zuzugreifen; wobei Erzeugen der Benutzerschnittstelle einschließt: 1) Informationen, die jeder ersten Vorrichtung entsprechen und die Informationen in der ersten Vorrichtung nutzen, auf die zugegriffen wird, und 2) Dienstinformationen; und Anzeigen der Benutzerschnittstelle auf der Benutzerschnittstellenvorrichtung.
Netzwerksystem nach Anspruch 38, wobei jeder Bezug, der mit durch das externe Netzwerk bereitgestellten Diensten verknüpft ist, wenigstens einen Hyperlink zu Dienstinformationen in dem externen Netzwerk umfasst und die Dienstinformationen wenigstens Identifizierungsinformationen umfassen, die einen Dienst darstellen.
Netzwerksystem nach Anspruch 39, wobei die Identifizierungsinformationen eine Logo-Informationsdatei umfassen, die einen Link zu einer Logo-Grafik enthält, die den Dienst darstellen.
Netzwerksystem nach einem der Ansprüche 29–40, wobei das externe Netzwerk wenigstens ein erstes Portal zum Bereitstellen von Diensten enthält und ein Bezug in der Benutzerschnittstellenbeschreibung, der mit durch das externe Netzwerk bereitgestellten Diensten verknüpft ist, wenigstens einen Hyperlink zu dem ersten Portal umfasst und das erste Portal Dienstinformationen enthält, die wenigstens Identifizierungsinformationen umfassen, die die durch das erste Portal bereitgestellten Dienste darstellen.
Netzwerksystem nach Anspruch 41, wobei die Identifizierungsinformationen in dem ersten Portal des Weiteren wenigstens einen Hyperlink zu durch wenigstens ein zweites Portal in dem externen Netzwerk bereitgestellten Dienstinformationen auf Basis von RIC umfassen.
Netzwerksystem nach Anspruch 41 oder 42, wobei: das externe Netzwerk eine Vielzahl miteinander verbundener Computersysteme umfasst, die zum Bereitstellen von Diensten programmiert sind; das erste Portal eines oder mehrere der Computersysteme umfasst, die Dienste des ersten Portals bereitstellen; und das zweite Portal eines oder mehrere der Computersysteme umfasst, die Dienste des zweiten Portals bereitstellen.
Netzwerksystem nach einem der Ansprüche 29–40, wobei: das externe Netzwerk wenigstens ein erstes Portal und wenigstens einen Ziel-Service-Provider zum Bereitstellen von Diensten enthält; das erste Portal so konfiguriert ist, dass in Reaktion auf eine Dienstanforderung von wenigstens einer ersten Vorrichtung auf Basis eines Bezugs in der Benutzerschnittstellenbeschreibung dieser ersten Vorrichtung in dem ersten Netzwerk, wobei die Dienst-Anforderung einen RIC dieser ersten Vorrichtung enthält, das erste Portal einen Ziel-Service-Provider auf Basis des empfangenen RIC bestimmt, und das erste Portal die Anforderung zu dem Ziel-Service-Provider umleitet.
Netzwerksystem nach Anspruch 44, wobei sich der Ziel-Service-Provider in dem externen Netzwerk innerhalb des ersten Portals befindet.
Netzwerksystem nach Anspruch 44, wobei sich der Ziel-Service-Provider in dem externen Netzwerk außerhalb des ersten Portals befindet.
Netzwerksystem nach einem der Ansprüche 44–46, wobei ein Bezug, der mit durch das externe Netzwerk bereitgestellten Diensten verknüpft ist, wenigstens einen Hyperlink zu dem ersten Portal umfasst und das erste Portal Dienstinformationen enthält, die wenigstens Umleitungsinformationen auf Basis von RIC zu durch andere Service-Provider in dem externen Netzwerk bereitgestellten Diensten umfassen.
Netzwerksystem nach einem der Ansprüche 44–47, wobei das erste Portal des Weiteren eine Liste von RIC und entsprechenden Ziel-Service-Provider-Portaladressen enthält und das erste Portal so konfiguriert ist, dass es einen Ziel-Service-Provider bestimmt, indem es eine Ziel-Service-Provider-Portaladresse, die einem empfangenen RIC entspricht, in der Liste auffindet und die Anforderung zu der Ziel-Service-Provider-Portaladresse umleitet.
Netzwerksystem nach Anspruch 48, wobei jede Ziel-Service-Provider-Adresse eine URL umfasst.
Netzwerksystem nach einem der Ansprüche 29–49, wobei das erste Portal so konfiguriert ist, dass es automatisch einen RIC-Code für wenigstens eine erste Vorrichtung innerhalb des ersten Netzwerkes bezieht.
Netzwerksystem nach einem der Ansprüche 29–49, wobei wenigstens eine erste Vorrichtung des Weiteren einen Software-Agenten zum Beziehen eines RIC für diese erste Vorrichtung von einem Benutzer enthält.
Netzwerksystem nach einem der Ansprüche 29–51, wobei für wenigstens eine erste Vorrichtung der entsprechende RIC eine Kennung umfasst, die die geografische Region der ersten Vorrichtung darstellt.
Steuervorrichtung zum Bereitstellen einer Benutzervorrichtungskommunikation und Steuerung in einem ersten Netzwerk miteinander verbundener erster Vorrichtung, wobei das erste Netzwerk über eine Schnittstellenvorrichtung mit einem externen Netzwerk verbunden ist, das Dienste bereitstellt, und die Steuervorrichtung umfasst: einen Benutzerschnittstellenbeschreibungs-Erzeugungs-Agenten, der so konfiguriert ist, dass er: a) Informationen von einer oder mehreren der ersten Vorrichtungen bezieht, die momentan mit dem ersten Netzwerk verbunden sind, wobei die Informationen Vorrichtungsinformationen enthalten; und b) eine Benutzerschnittstellenbeschreibung erzeugt, die enthält: 1) wenigstens einen Bezug, der mit den Vorrichtungsinformationen jeder der einen oder mehreren ersten Vorrichtungen verknüpft ist, 2) wenigstens einen Umleitungs-Identifizierungs-Code (RIC), der dieser ersten Vorrichtung entspricht, und 3) wenigstens einen Bezug, der mit durch das externe Netzwerk bereitgestellten Diensten verknüpft ist.
Steuervorrichtung nach Anspruch 53, wobei das erste Netzwerk ein 1394-Netzwerk umfasst und das externe Netzwerk ein Nicht-1394-Netzwerk umfasst.
Steuervorrichtung nach Anspruch 53 oder 54, wobei die Schnittstellenvorrichtung eine Gateway-Vorrichtung umfasst.
Steuervorrichtung nach einem der Ansprüche 53–55, wobei das externe Netzwerk eine Vielzahl miteinander verbundener zweiter Vorrichtungen umfasst, die einen oder mehrere Dienste bereitstellen.
Steuervorrichtung nach Anspruch 56, wobei jede der zweiten Vorrichtungen wenigstens ein Computersystem umfasst, das zum Bereitstellen von Diensten programmiert ist.
Steuervorrichtung nach Anspruch 56 oder 57, wobei das externe Netzwerk das Internet umfasst, und wenigstens eine der zweiten Vorrichtungen, die Dienste bereitstellen, einen oder mehrere Web-Server umfasst, die Dienste bereitstellen.
Steuervorrichtung nach Anspruch 58, wobei ein Dienst, der durch wenigstens eine der mit dem externen Netzwerk verbundenen Vorrichtungen bereitgestellt wird, einen Website-Dienst umfasst.
Steuervorrichtung nach einem der Ansprüche 53–59, wobei jeder Bezug in der Benutzerschnittstellenbeschreibung, der mit durch das externe Netzwerk bereitgestell ten Dienste verknüpft ist, wenigstens einen Hyperlink zu Dienstinformationen in dem externen Netzwerk umfasst.
Steuervorrichtung nach einem der Ansprüche 53–60, die des Weiteren umfasst: eine Benutzerschnittstellenvorrichtung, die in der Lage ist, eine Benutzerschnittstelle anzuzeigen; und einen Benutzerschnittstellen-Erzeugungs-Agenten, der so konfiguriert ist, dass er eine Benutzerschnittstelle auf Basis der Benutzerschnittstellenbeschreibung zur Benutzersteuerung der ersten Vorrichtungen und zur Kommunikation mit dem externen Netzwerk anzeigt.
Steuervorrichtung nach Anspruch 61, wobei der Benutzerschnittstellen-Erzeugungs-Agent des Weiteren so konfiguriert ist, dass er: jeden Bezug in der entsprechenden Benutzerschnittstellenbeschreibung nutzt, um auf die verknüpften Informationen in jeder ersten Vorrichtung zuzugreifen; jeden Bezug, der mit durch das externe Netzwerk bereitgestellten Diensten verknüpft ist, nutzt, um auf entsprechende Dienstinformationen zuzugreifen; wobei Erzeugen der Benutzerschnittstelle einschließt: 1) Informationen, die jeder ersten Vorrichtung entsprechen und die Informationen in der ersten Vorrichtung nutzen, auf die zugegriffen wird, und 2) Dienstinformationen; und Anzeigen der Benutzerschnittstelle auf der Benutzerschnittstellenvorrichtung.
Steuervorrichtung nach Anspruch 62, wobei jeder Bezug, der mit durch das externe Netzwerk bereitgestellten Diensten verknüpft ist, wenigstens einen Hyperlink zu Dienstinformationen in dem externen Netzwerk umfasst und die Dienstinformatio nen wenigstens Identifizierungsinformationen umfassen, die einen Dienst darstellen.
Steuervorrichtung nach Anspruch 63, wobei die Identifizierungsinformationen eine Logo-Informationsdatei umfassen, die einen Link zu einer Logo-Grafik enthält, die den Dienst darstellt.
Steuervorrichtung nach einem der Ansprüche 53–64, wobei das externe Netzwerk wenigstens ein erstes Portal zum Bereitstellen von Diensten enthält und ein Bezug in der Benutzerschnittstellenbeschreibung, der mit durch das externe Netzwerk bereitgestellten Diensten verknüpft ist, wenigstens einen Hyperlink zu dem ersten Portal umfasst und das erste Portal Dienstinformationen enthält, die wenigstens Identifizierungsinformationen umfassen, die die durch das erste Portal bereitgestellten Dienste darstellen.
Steuervorrichtung nach Anspruch 65, wobei die Identifizierungsinformationen in dem ersten Portal wenigstens einen Hyperlink zu durch wenigstens ein zweites Portal in dem externen Netzwerk bereitgestellten Dienstinformationen umfassen.
Steuervorrichtung nach Anspruch 66, wobei die Identifizierungsinformationen in dem ersten Portal des Weiteren wenigstens einen Hyperlink zu durch wenigstens ein zweites Portal in dem externen Netzwerk bereitgestellten Dienstinformationen auf Basis von RIC umfassen.
Steuervorrichtung nach einem der Ansprüche 65–67, wobei: das externe Netzwerk eine Vielzahl miteinander verbundener Computersysteme umfasst, die zum Bereitstellen von Diensten programmiert sind; das erste Portal eines oder mehrere der Computersysteme umfasst, die Dienste des ersten Portals bereitstellen; und das zweite Portal eines oder mehrere der Computersysteme umfasst, die Dienste des zweiten Portals bereitstellen.
Steuervorrichtung nach einem der Ansprüche 53–68, wobei der Benutzerschnittstellenbeschreibung-Erzeugungs-Agent in der Benutzerschnittstellenbeschreibung des Weiteren einen Hyperlink mit den Vorrichtungsinformationen einer oder mehrerer der ersten Vorrichtungen verknüpft und wenigstens einen Hyperlink mit den durch das externe Netzwerk bereitgestellten Dienstinformationen verknüpft.
Steuervorrichtung nach einem der Ansprüche 53–69, wobei: 1) die Vorrichtungsinformationen in jeder Vorrichtung in dem ersten Netzwerk eine Benutzerschnittstellenbeschreibung zur Benutzer-Interaktion mit dieser Vorrichtung enthalten, und 2) die Dienstinformationen in dem externen Netzwerk wenigstens eine Benutzerschnittstellenbeschreibung zur Benutzer-Interaktion mit einem Dienst enthalten.
Steuervorrichtung nach einem der Ansprüche 53–64, wobei: das externe Netzwerk wenigstens ein erstes Portal und wenigstens einen Ziel-Service-Provider zum Bereitstellen von Diensten enthält; das erste Portal so konfiguriert ist, dass es in Reaktion auf eine Dienstanforderung von wenigstens einer ersten Vorrichtung auf Basis eines Bezugs in der Benutzerschnittstellenbeschreibung dieser ersten Vorrichtung in dem ersten Netzwerk, wobei die Dienstanforderung einen RIC dieser ersten Vorrichtung enthält, das erste Portal einen Ziel-Service-Provider auf Basis des empfangenen RIC bestimmt, und das erste Portal die Anforderung zu dem Ziel-Service-Provider umleitet.
Steuervorrichtung nach Anspruch 71, wobei sich der Ziel-Service-Provider in dem externen Netzwerk innerhalb des ersten Portals befindet.
Steuervorrichtung nach Anspruch 71, wobei sich der Ziel-Service-Provider in dem externen Netzwerk außerhalb des ersten Portals befindet.
Steuervorrichtung nach einem der Ansprüche 71–73, wobei ein Bezug, der mit durch das externe Netzwerk bereitgestellten Diensten verknüpft ist, wenigstens einen Hyperlink zu dem ersten Portal umfasst und das erste Portal Dienstinformationen enthält, die wenigstens Umleitungsinformationen auf Basis von RIC zu durch andere Service-Provider in dem externen Netzwerk bereitgestellten Diensten umfassen.
Steuervorrichtung nach einem der Ansprüche 71–74, wobei das erste Portal des Weiteren eine Liste von RIC und entsprechenden Ziel-Service-Provider-Portaladressen enthält und das erste Portal so konfiguriert ist, dass es einen Ziel-Service-Provider bestimmt, indem es eine Ziel-Service-Provider-Portaladresse, die einem empfangenen RIC entspricht, in der Liste auffindet und die Anforderung zu der Ziel-Service-Provider-Portaladresse umleitet.
Steuervorrichtung nach Anspruch 75, wobei jede Ziel-Service-Provider-Adresse eine URL umfasst.
Steuervorrichtung nach einem der Ansprüche 53–76, wobei das erste Portal so konfiguriert ist, dass es automatisch einen RIC für wenigstens eine erste Vorrichtung innerhalb des ersten Netzwerkes bezieht.
Steuervorrichtung nach einem der Ansprüche 53–76, wobei wenigstens eine erste Vorrichtung einen Software-Agenten zum Beziehen einer RIC für diese erste Vorrichtung von einem Benutzer enthält.
Steuervorrichtung nach einem der Ansprüche 53–78, wobei für wenigstens eine erste Vorrichtung der entsprechende RIC eine Kennung umfasst, die die geografische Region der ersten Vorrichtung darstellt.