DE69829218T2 - Ein audio-video-netzwerk mit gerätsteuerung - Google Patents

Ein audio-video-netzwerk mit gerätsteuerung Download PDF

Info

Publication number
DE69829218T2
DE69829218T2 DE69829218T DE69829218T DE69829218T2 DE 69829218 T2 DE69829218 T2 DE 69829218T2 DE 69829218 T DE69829218 T DE 69829218T DE 69829218 T DE69829218 T DE 69829218T DE 69829218 T2 DE69829218 T2 DE 69829218T2
Authority
DE
Germany
Prior art keywords
control module
facility
dcm
network
new
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Expired - Lifetime
Application number
DE69829218T
Other languages
English (en)
Other versions
DE69829218D1 (de
Inventor
J. Rodger LEA
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Sony Electronics Inc
Original Assignee
Sony Electronics Inc
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Sony Electronics Inc filed Critical Sony Electronics Inc
Publication of DE69829218D1 publication Critical patent/DE69829218D1/de
Application granted granted Critical
Publication of DE69829218T2 publication Critical patent/DE69829218T2/de
Anticipated expiration legal-status Critical
Expired - Lifetime legal-status Critical Current

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H04L12/2803—Home automation networks
    • H04L12/2807—Exchanging configuration information on appliance services in a home automation network
    • H04L12/281—Exchanging configuration information on appliance services in a home automation network indicating a format for calling an appliance service function in a home automation network
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H04L12/2803—Home automation networks
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H04L12/2803—Home automation networks
    • H04L12/2805—Home Audio Video Interoperability [HAVI] networks
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H04L12/40—Bus networks
    • H04L12/40052—High-speed IEEE 1394 serial bus
    • H04L12/40117—Interconnection of audio or video/imaging devices
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/40—Network security protocols
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/43—Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
    • H04N21/436—Interfacing a local distribution network, e.g. communicating with another STB or one or more peripheral devices inside the home
    • H04N21/43615—Interfacing a Home Network, e.g. for connecting the client to a plurality of peripherals
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N7/00—Television systems
    • H04N7/24—Systems for the transmission of television signals using pulse code modulation
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/24—Negotiation of communication capabilities
    • Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y10—TECHNICAL SUBJECTS COVERED BY FORMER USPC
    • Y10S—TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y10S707/00—Data processing: database and file management or data structures
    • Y10S707/99931—Database or file accessing

Description

  • Gebiet der Erfindung
  • Das Gebiet der vorliegenden Erfindung betrifft Audio-/Video-Systeme. Insbesondere betrifft die vorliegende Erfindung die Vernetzung einer Anzahl von elektronischen Einrichtungen, um ein Audio-/Video-System zu bilden. Bei einer Ausführungsform ist ein Heim-Audio-/Videonetzwerk sowohl mit allgemeiner als auch parametrischer Einrichtungssteuerung offenbart.
  • Hintergrund der Erfindung
  • Eine übliche audiovisuelle Heimausrüstungsanordnung umfasst eine Anzahl von Komponenten, beispielsweise einen Radioempfänger, einen CD-Player, zwei Lautsprecher, ein Fernsehgerät, einen VCR, ein Band-Deck und dgl.. Jede dieser Komponenten ist miteinander über einen Satz von Drähten verbunden. Eine Komponente ist üblicherweise die Zentralkomponente des audiovisuellen Heimsystems. Dies ist üblicherweise der Radioempfänger oder der Tuner. Der Tuner hat eine Anzahl spezieller Eingänge, um die anderen Komponenten daran zu koppeln. Der Tuner hat eine entsprechende Anzahl von Steuerungstasten oder Steuerungsschaltern, die einen begrenzten Grad an Steuerbarkeit und Kompatibilität für die Komponenten liefern. Die Steuerungstasten und die Steuerungsschalter sind üblicherweise an der Vorderseite des Tuners angeordnet. In einigen Fällen sind manchmal alle diese Tasten und Schalter auf einer tragbaren Fernsteuerungseinheit nochmals angeordnet. Ein Benutzer steuert das audiovisuelle Heimsystem, indem er die Tasten und Schalter auf der Vorderseite des Tuners oder alternativ Tasten auf der tragbaren Fernsteuerungseinheit betätigt.
  • Das übliche audiovisuelle Heimsystem-Musterbeispiel ist ziemlich populär geworden. Da elektronische Verbrauchereinrichtungen leistungsfähiger und komplexer werden, stieg der Wunsch nach neuesten und leistungsfähigsten Einrichtungen an. Da neue Einrichtungen zum Vorschein kommen und populär werden, werden die Einrichtungen durch Verbraucher erworben und in ihre audiovisuellen Heimsysteme "gesteckt". Allgemein sind die neuesten und die verfeinersten dieser Einrichtungen ziemlich teuer (beispielsweise digitale Audiobandrekorder, DVD-Player, digitale Camcorder und dgl.). Da ein Verbraucher neue Einrichtungen am häufigsten erwirbt, wird die neue Einrichtung lediglich in das System ge meinsam zu vorher existierenden älteren Einrichtungen (beispielsweise Kassettenbanddeck, CD-Player und dgl.) gesteckt. Die neue Einrichtung wird in einen offenen Eingangsanschluss auf der Rückseite des Tuners gesteckt, oder in eine andere Einrichtung, die mit dem Tuner gekoppelt ist. Der Verbraucher (beispielsweise der Benutzer) steuert die neue Einrichtung über die Steuerungstasten auf dem Tuner, über die Steuerungstasten und die Schalttasten auf der Vorderseite der neuen Einrichtung selbst oder über eine gänzlich neue separate entsprechende Fernsteuerungseinheit für die neue Einrichtung.
  • Da die Anzahl neuer elektronischer Verbrauchereinrichtungen für das audiovisuelle Heimsystem angestiegen ist und da die Verfeinerung und die Leistung dieser Einrichtungen angestiegen sind, ist eine Anzahl von Problemen beim herkömmlichen Musterbeispiel zum Vorschein gekommen. Eines dieser Probleme ist die Kompatibilität zwischen Einrichtungen im audiovisuellen Heimsystem. Elektronische Verbrauchereinrichtungen von einem Hersteller werden häufig mit einem audiovisuellen System in einer anderen Weise als ähnliche Einrichtungen von einem anderen Hersteller zusammengeschaltet. Beispielsweise kann ein Tuner, der durch einen Hersteller hergestellt ist, nicht mit einem Fernsehgerät, welches durch einen anderen Hersteller hergestellt ist, passend zusammengeschaltet werden.
  • Wenn außerdem eine Einrichtung viel neuer als eine andere Einrichtung ist, können zusätzliche Unverträglichkeiten existieren. Beispielsweise könnte eine neue Einrichtung Hardware aufweisen (beispielsweise spezielle Eingänge und Ausgänge), die verfeinerte Fernsteuerungsfunktionen ermöglichen. Diese Hardware kann bei älteren Einrichtungen innerhalb des Systems nicht nützlich sein. Oder beispielsweise können ältere Tuner nicht geeignete Eingänge für einige neuere Einrichtungen haben, beispielsweise Mini-Disc-Player, VCRs, usw., oder können nicht ausreichend genug Eingänge für alle Einrichtungen des Systems haben.
  • Ein weiteres Problem ist der Mangel an funktioneller Unterstützung für verschiedene Einrichtungen innerhalb eines audiovisuellen Systems. Obwohl beispielsweise ein Fernsehapparat weiterentwickelte Tonformate (beispielsweise Surround-Ton, Stereo, usw.) unterstützen kann, können, wenn ein älterer wenig leistungsfähigerer Tuner diese Funktionalität nicht unterstützt, die Vorteile der weiterentwickelten Tonformate verloren werden.
  • Ein weiteres Problem ist die starke Ausbreitung von Steuerungen für neue und andere Einrichtungen innerhalb des audiovisuellen Heimsystems. Beispielsweise können ähnliche Einrichtungen von verschiedenen Herstellern andere Steuerungstasten und Steuerungsschaltformate aufweisen, um ähnliche Aufgaben zu erfüllen (beispielsweise das Einstellen der Uhr in einem VCR, das Programmieren eines VCR, um ein späteres Programm aufzuzeich nen, und dgl.). Außerdem führt jede neue Einrichtung, die mit dem audiovisuellen System zusammengeschaltet wird, häufig zu einer anderen dafür bestimmten Fernsteuerungseinheit für den Benutzer, damit er sich auf dem Laufenden hält und lernt, diese zu betätigen.
  • Während das Auftreten von Vernetzung und Schnittstellen-Technologie (beispielsweise IEEE-1394-Seriell Kommunikationsbus und die weit verbreitete Annahme digitaler Systeme) Aussichten bietet, diese Probleme zu korrigieren, gibt es noch keine einheitliche, offene, erweiterbare Architektur, die für intelligente, selbst-konfigurierende, leicht-erweiterbare Einrichtungen oder AV-Systeme geliefert werden kann. Beispielsweise liefern, obwohl verschiedene Lösungen die Verwendung von IEEE 1394 als Basis eines AV-Systems verwenden, keine eine Erweiterbarkeit des AV-Systems über seine Lebensdauer, wenn neue Einrichtungen hinzugefügt werden, deren Leistungen und Merkmale unbekannt sind. Keines dieser Systeme garantiert, dass alle Einrichtungen mit dem Benutzer kommunizieren können und durch den Benutzer so gesteuert werden können, dass sich der Benutzer daran erfreut.
  • Evans G. "CE-Bus Defining the future of residential communications" Australian Electronics Engineering, März 1997, Reel Business Publishing, Australia, Band 30, Nr. 3, Seite 34–36, 38, xP 002/05591, ISSN 0004-9042 offenbart residente Kommunikation.
  • Überblick über die Erfindung
  • Folglich ist eine neue Architektur für ein audiovisuelles Heimsystem erforderlich, welche die Kompatibilitäts- und Funktionalitätsprobleme des herkömmlichen Systems korrigiert. Erforderlich ist eine neue Architektur für ein offenes kompatibles audiovisuelles System für Einrichtungen innerhalb eines Heimnetzwerks. Erforderlich ist eine Architektur, die erlaubt, dass Einrichtungen von einem anderen Hersteller nahtlos bei einem audiovisuellen Heimsystem funktionieren. Erforderlich ist eine Architektur, die erweiterbar ist und die schnell modifiziert werden kann und die weiterentwickelt werden kann, wenn sich Markterfordernisse und die Technologie ändern.
  • Verschiedene entsprechende Merkmale der vorliegenden Erfindung sind in den angehängten Patentansprüchen herausgestellt.
  • Die vorliegende Erfindung liefert ein Heim-Audio-Visuelles Netzwerk (AV), welches eine offene Architektur für kompatible CE-Einrichtungen (elektronische Verbrauchereinrichtungen) in einem Heimnetzwerk definiert. Die Kompatibilitätsmerkmale der vorliegenden Erfindung definieren ein Architekturmodell, welches es CE-Einrichtungen von irgendeinem Hersteller erlaubt, nahtlos innerhalb des Heim-AV-Systems des Benutzers kompatibel zu sein und zu funktionieren. Das System der vorliegenden Erfindung umfasst eine Kombination ei nes Basissatzes allgemeiner Einrichtungssteuerungen mit einem Verfahren, um ein Basissteuerungsprotokoll zu erweitern, wenn neue Merkmale und neue CE-Einrichtungen innerhalb des AV-Heimnetzwerks verwendet werden. Wenn man so verfährt, ist die Architektur nach der vorliegenden Erfindung erweiterbar und kann schnell modifiziert und weiter entwickelt werden, wenn sich die Markterfordernisse und die Technologie ändern.
  • Um die obigen Merkmale auszuführen, umfasst die vorliegende Erfindung eine Architektur, die es erlaubt, dass die neu angeschaltete Einrichtung abgefragt wird. Unter Verwendung der Ergebnisse der Abfrage wird eine Software auf der Basis von Abstraktion dieser Einrichtung erzeugt und den anderen Elementen im Netzwerk verfügbar gemacht. Die Software-Abstraktion wird als Einsrichtungssteuerungsmodul bezeichnet. Das Einrichtungssteuerungsmodul liefert einen vorher festgelegten genormten Satz an Kompatibilität, Funktionalität und Steuerungsschnittstellen für die Einrichtung. Die CE-Einrichtung ist mit dem AV-Heimnetzwerk über ein Einrichtungssteuerungsmodul gekoppelt und kommuniziert mit diesem. Jede CE-Einrichtung im AV-Heimsystem besitzt ein entsprechendes Einrichtungssteuerungsmodul (DCM). Das DCM der vorliegenden Erfindung stellt außerdem eine Anwendungsprogrammier-Schnittstelle (API) bereit, um es anderen Anwendungen zu erlauben, auf eine neu angeschaltete CE-Einrichtung zuzugreifen und diese zu handhaben.
  • Über die DCMs nach der vorliegenden Erfindung wird über die Lebensdauer des AV-Systems, wenn neue Einrichtungen hinzugefügt werden, deren Leistungen und Merkmale unbekannt sind oder lediglich teilweise anderen Einrichtungen bekannt sind, ein Mechanismus bereitgestellt, der garantiert, dass alle Einrichtungen miteinander in Verbindung stehen können und auf einer grundsätzlichen minimalen Ebene gesteuert werden können, und dann, wo möglich, wenn mehr Information über die Einrichtung erhalten wird, eine bessere Abstraktion der neuen Einrichtung erzeugt wird.
  • Insbesondere wird bei einer Ausführung der vorliegenden Erfindung das allgemeine Ebenen-1-DCM verwendet, um eine Basisabstraktion für eine Funktionalität von Einrichtungen und Leistungen auf der Basis der allgemeinen Klasse der Einrichtung bereitzustellen. Die vorliegende Erfindung verwendet dann Information, die in der Einrichtung selbst gehalten wird, um das allgemeine Ebenen-1-DCM zu parametrisieren und zu spezialisieren, so dass eine bessere Abstraktion der Einrichtung verfügbar gemacht wird. Um dies zu tun nutzt das System das allgemeine Ebenen-1-DCM als einen Zugriffspunkt, um die Einrichtung weiter abzufragen. Eine resultierende Information, welche die Einrichtung verfügbar macht, wird dann dazu verwendet, das allgemeine Ebenen-1-DCM zu modifizieren und zu parametrisieren. Dies ermöglicht, dass die Einrichtung Extrabefehle bereitstellt, auf die die Einrichtung antwortet, die über dem Basissatz von Befehlen für eine Einrichtung seiner Klasse sind, Extrainformation, wie dem Benutzer über eine Benutzerschnittstelle die Einrichtung zu zeigen werden sollte, und Mischinformation, die dazu verwendet werden kann, die Einrichtungsabstraktion und die verknüpfte Anwendungsprogramm-Schnittstelle (API) zu steigern. Wenn man so verfährt, so liefert die vorliegende Erfindung einen extrem flexiblen Mechanismus, der sicherstellt, dass neue Einrichtungen in das Heim-AV-System wirksam eingegliedert werden
  • Kurzbeschreibung der Zeichnungen
  • Die vorliegende Erfindung ist beispielhaft und nicht beschränkend in den Figuren der beiliegenden Zeichnungen dargestellt, in denen gleiche Bezugszeichen ähnliche Elemente bezeichnen, und in denen:
  • 1A ein Heim-AV-Netzwerk gemäß einer Ausführungsform der vorliegenden Erfindung zeigt;
  • 1B eine logische Buskonfiguration des HAVI-Netzwerks von 1A zeigt;
  • 2 beispielhaft ein Partner-zu-Partner-Zwei-IAV-Knotennetzwerk (zwischen Audio/Video) gemäß einer Ausführungsform der vorliegenden Erfindung zeigt;
  • 3 ein einzelnes FAV (full audio video)-Gruppen-HAVI-Netzwerk gemäß einer Ausführungsform der vorliegenden Erfindung zeigt;
  • 4 eine FAV-Gruppe, die in ein IAV-Partner-zu-Partner-HAVI-Netzwerk eingegliedert ist, zeigt;
  • 5 ein beispielhaftes HAVI-Netzwerk zeigt, welches mehrere FAVs hat;
  • 6 ein Diagramm einer Set-Top-Box gemäß einer Ausführungsform der vorliegenden Erfindung zeigt;
  • 7 ein logisches Blockdiagramm einer Ausführungsform der HAVI-Architektur der vorliegenden Erfindung zeigt;
  • 8 ein logisches Ebenen-Diagramm einer HAVI-Architektur gemäß der vorliegenden Erfindung zeigt;
  • 9 ein Diagramm einer lokalen und einer fernen Mitteilungsübermittlung in der HAVI-Architektur einer Ausführungsform zeigt;
  • 10 ein Diagramm einer Information zeigt, welche über 1394 in der HAVI-Architektur einer Ausführungsform gesendet wird;
  • 11 ein Diagramm einer Anwendung zeigt, die eine andere Anwendung in einer Ausführungsform der HAVI-Architektur anruft;
  • 12A eine erste beispielhafte UI-Anzeige (beispielsweise auf einem Fernsehbildschirm) für eine Einrichtung (beispielsweise den Camcorder) zeigt;
  • 12B eine zweite beispielhafte UI-Anzeige (beispielsweise auf einem Fernsehbildschirm) für eine Einrichtung (beispielsweise den Camcorder) zeigt;
  • 13 ein Flussdiagramm eines Verfahrens zum Bereitstellen nahtloser Kompatibilität und Integration von mehreren Einrichtungen in einem HAVI-Netzwerk unter Verwendung der SDD-Information zeigt, die in jeder Einrichtung gespeichert ist, gemäß einer Ausführungsform der vorliegenden Erfindung;
  • 14 ein Flussdiagramm eines Verfahrens zeigt, um eine grundsätzliche Befehlsfunktionalität und eine erweiterte Befehlsfunktionalität zwischen mehreren Einrichtungen in einem HAVI-Netzwerk bereitzustellen, gemäß einer Ausführungsform der vorliegenden Erfindung;
  • 15 ein Flussdiagramm eines Verfahrens zeigt, um zukünftige Aufrüstbarkeit und Erweiterungsfähigkeit von Einrichtungen im HAVI-Netzwerk sicherzustellen, gemäß einer Ausführungsform der vorliegenden Erfindung;
  • 16 ein Flussdiagramm eines Verfahrens zeigt, um nahtlose Kompatibilität und Integration von Stammeinrichtungen mit den konformen HAVI-Einrichtungen in einem HAVI-Netzwerk zeigt, gemäß einer Ausführungsform der vorliegenden Erfindung;
  • 17A ein Flussdiagramm eines Verfahrens zeigt, um Einrichtungen innerhalb eines Heim-Audio-Video-Netzwerks unter Verwendung eines Anwendungsprogramms von einem externen Dienstbereitsteller zu steuern, gemäß einer Ausführungsform der vorliegenden Erfindung; und
  • 17B ein Diagramm eines HAVI-Netzwerks mit dem Dienstbereitsteller gemäß dem Verfahren von 17A zeigt.
  • Ausführliche Beschreibung der Erfindung
  • Es wird nun ausführlich auf die Ausführungsformen der Erfindung bezuggenommen, von denen Beispiele in den beiliegenden Zeichnungen gezeigt sind. Obwohl die Erfindung in Verbindung mit den bevorzugten Ausführungsformen beschrieben ist, soll verstanden sein, dass nicht beabsichtigt ist, die Erfindung auf diese Ausführungsformen zu beschränken. Im Gegensatz dazu ist die Erfindung dazu da, Alternativen, Modifikationen und Äquivalente abzudecken, die im Rahmen der Erfindung enthalten sein können, wie durch die beigefügten Patentansprüche definiert. Außerdem sind in der folgenden ausführlichen Beschreibung der vorliegenden Erfindung zahlreiche spezifische Details angegeben, um ein gründliches Ver ständnis der vorliegenden Erfindung zu liefern. Es soll jedoch klar sein, dass der Fachmann die vorliegende Erfindung ohne diese speziellen Details ausüben kann. In anderen Beispielen wurden bekannte Verfahren, Prozeduren, Komponenten und Beispiele nicht ausführlich beschrieben, um nicht unnötigerweise Merkmale der vorliegenden Erfindung zu verdecken.
  • Die vorliegende Erfindung stellt ein Heim-AV-Netzwerk bereit, welches eine offene Architektur von kompatiblen CE-Einrichtungen in einem Heim-Netzwerk definiert. Die Kompatibilitätsmerkmale der vorliegenden Erfindung definieren ein Architekturmodell, welches erlaubt, dass CE-Einrichtungen von irgendeinem Hersteller nahtlos innerhalb des Heim-AV-Systems des Benutzers zusammenarbeiten und funktionieren. Das System der vorliegenden Erfindung enthält eine Kombination eines Basissatzes von allgemeinen Einrichtungssteuerungen mit einem Verfahren, um ein Basissteuerungsprotokoll zu erweitern, wenn neue Merkmale und neue CE-Einrichtungen innerhalb des Heim-AV-Netzwerks entwickelt werden. Wenn so verfahren wird, ist die Architektur der vorliegenden Erfindung erweiterbar, und sie kann schnell modifiziert und weiter entwickelt werden, wenn sich die Markterfordernisse und das Verfahren ändern. Die vorliegende Erfindung und ihre Vorteile werden anschließend beschrieben.
  • Bezeichnung und Namensgebung
  • Einige Bereiche der ausführlichen Beschreibung, die folgen, werden hinsichtlich von Prozeduren, Schritten, logischen Blöcken, Verarbeitung und anderen symbolischen Darstellungen von Betriebsweisen in Bezug auf Datenbits innerhalb eines Computerspeichers dargestellt (siehe 2). Diese Beschreibungen und Darstellungen sind Mittel, welche durch den Fachmann auf dem Gebiet der Datenverarbeitung verwendet werden, um die Substanz ihrer Arbeit anderen auf diesem Gebiet zu überbringen. Eine Prozedur, ein Computerausführungsschritt, ein logischer Block, ein Verfahren, usw. wird hier und allgemein als selbstkonsistente Folge von Schritten oder Instruktionen angesehen, die zu einem gewünschten Ergebnis führen. Die Schritte sind so, dass sie körperliche Handhabungen physikalischer Quantitäten erfordern. Üblicherweise, obwohl nicht notwendig, nehmen diese Quantitäten die Form elektrischer oder magnetischer Signal an, die gespeichert, übertragen, kombiniert, verglichen oder anderweitig in einem Computersystem gehandhabt werden können. Es hat sich häufig als angenehm erwiesen, hauptsächlich aus Gründen einer gemeinsamen Verwendung diese Signale als Bits, Werte, Elemente, Symbole, Zeichen, Begriffe, Zeichen oder dgl. zu bezeichnen.
  • Man sollte jedoch im Gedächtnis behalten, dass alle diese und ähnlichen Begriffe in Verbindung mit geeigneten physikalischen Quantitäten zu bringen sind und lediglich ange nehme Bezeichnungen sind, die für diese Quantitäten angewandt werden. Wenn nicht speziell festgestellt wird, anders als aus den folgenden Erläuterungen deutlich wird, soll es gewürdigt werden, dass in die Erfindung durchwegs die Erläuterungen, welche die Begriffe beispielsweise "Verarbeitung" oder "Berechnung" oder "Übersetzung" oder "Beginnen" oder "Bestimmen" oder "Anzeigen" oder "Erkennen" oder dgl. verwenden, sich auf die Aktion und auf Verfahren eines Computersystems oder einer ähnlichen elektronischen Berechnungseinrichtung beziehen, welche Daten handhabt und transformiert, die als physikalische (elektronische) Quantitäten innerhalb der Register des Computersystems dargestellt werden, und Speicher in anderen Daten ähnlich als physikalische Quantitäten innerhalb der Computersystem-Speicher oder Register oder einem anderen derartigen Informationsspeicher, Übertragungs- oder Anzeigeeinrichtungen dargestellt werden.
  • Architekturübersicht
  • Die Architektur der vorliegenden Erfindung ermöglicht die Bildung eines Heim-AV-Systems, welches eine nahtlose Unterstützung neuer Einrichtungen und eine problemfreie Kompatibilität von Einrichtungen in einem Heim-AV-Netzwerk liefert. Die meisten grundsätzlichen Komponenten eines Systems gemäß der vorliegenden Erfindung sind: eine Heim-AV-Kompatibilitäts-Architektur, eine Reihe von Heim-AV-Kompatibilitäts-Schnittstellen und ein Heim-AV-Netzwerk. Die Heim-AV-Kompatibilitäts-Architektur ist ein breiter, überbrückender Griff, der das physikalische Netzwerk und die steuernden Programmierschnittstellen umfasst. Die Kompatibilitätsschnittstelle ist ein Begriff, der verwendet wird, die Zusammenarbeit und die Schnittstellen von Komponenten der AV-Architektur zu beschreiben. Zusätzlich zum Bereitstellen eines gemeinsamen Befehlssatzes liefern die Kompatibilitätsschnittstellen eine Software-Architektur, die es neuen Einrichtungen erlaubt, in das Netzwerk integriert zu werden und ihre Dienste in einer nahtlosen Weise bereitzustellen. Das Heim-AV-Netzwerk ist ein Begriff, der verwendet wird, das physikalische Netzwerk und dessen Topologie zu schreiben.
  • Es sollte angemerkt sein, dass die Heim-AV-Kompatibilitäts-Architektur (HAVI) nach der vorliegenden Erfindung ein offenes, plattformunabhängiges, architektur-neutrales Netzwerk ist, welches es elektronischen Verbraucherherstellern und Erzeugern erlaubt, kompatible Anwendungen bereitzustellen. Dies kann auf unterschiedlichen Hardware-/Software-Plattformen ausgeführt werden und umfasst nicht Merkmale, die für irgendeine Plattform eigentümlich sind. Die Kompatibilitätsschnittstellen der HAVI-Architektur sind erweiterbar, und sie können hingefügt werden, modifiziert werden und weiterentwickelt werden, wenn sich die Markterfordernisse und die Technologie ändern. Sie liefern die Infrastruktur, um das Lenken und die Verarbeitung von isochronen und zeitsensitiven Daten zu steuern (beispielsweise Audio- und Videoinhalt).
  • Insbesondere liefert die HAVI-Architektur: eine Ausübungsumgebung, welche die visuelle Repräsentation und die Steuerung von Anwendungen unterstützt; Anwendung und Systemdienste; und Kommunikationsmechanismen, um die Umgebung dynamisch durch "Reinstecken-Laufenlassen" (plug and play) zu erweitern.
  • Es sollte angemerkt sein, dass die HAVI-Architektur Stammanwendungen (beispielsweise Anwendungen, welche schon existieren oder für Benutzer verfügbar sind) unterstützt. Dies ist wichtig, da der Übergang zu intelligenteren Netzwerkanwendungen langsam vorangeht. Die meisten Hersteller werden nicht plötzlich mit dem Erzeugen von lediglich "intelligenten" Anwendungen beginnen, und die meisten Verbraucher werden nicht schnell alle ihre existierenden Anwendungen ersetzen.
  • Gemäß der vorliegenden Erfindung gibt es zwei Klassen an Stammanwendungen. Eine erste Klasse umfasst "Einweg-" oder nicht anerkannte Steuerungsanwendungen. Eine zweite Klasse umfasst "Zweiweg"-Anwendungen. Beispiele von Einweg-Anwendungen sind Audio-/Videokomponenten, die durch Infrarotbefehle einer tragbaren Fernsteuerung gesteuert werden. Zweiwege-Anwendungen liefern Bestätigung der Befehlsausführung, den Status und einen Fehlerbericht. Beispiele von Zweiwege-Anwendungen umfassen die kürzlich eingeführte Einführung von bekannten IEEE 1394-fähigen Digitalkameras.
  • Es sei angemerkt, dass das Heim-AV-Netzwerk (anschließend als HAVI-Netzwerk bezeichnet) der vorliegenden Erfindung Unterstützung bereitstellt, um zukünftige Anwendungen und Protokolle über eine einmalschreibbare, überall laufende gemeinsame Sprache unterzubringen. Gemäß der vorliegenden Erfindung umfasst jede Anwendung in ihr selbstbeschreibende Information, welche die Benutzerschnittstelle betrifft, und die Einrichtungssteuerung, welche durch eine externe Steuerung verwendet werden kann. Diese Information ist als Programm in der gemeinsamen Sprache spezifiziert.
  • Wie anschließend beschrieben besteht die darunterliegende Struktur für ein solches Netzwerk aus einem Satz miteinander verbundener Gruppen von Anwendungen. Üblicherweise werden es mehrere Gruppen in einem Haus sein, eine pro Flur oder pro Raum. Jede Gruppe wird wie ein Satz miteinander verbundener Einrichtungen arbeiten, um einen Satz von Diensten den Benutzern bereitzustellen. Häufig wird eine Einrichtung wie eine Steuerung für einen Satz von anderen Einrichtungen arbeiten. Die Architektur ist jedoch ausreichend flexibel, um es einem Heim zu erlauben, aus einer einzelnen Gruppe ohne Hauptsteuerung zu bestehen.
  • Beispielsweise könnte bei einer Ausführungsform der vorliegenden Erfindung ein intelligentes Fernsehgerät in einem Familienraum des Heims eines Benutzers als Steuerung für eine Anzahl von miteinander verbundenen Anwendungen funktionieren. Jede der gesteuerten Anwendungen würde selbstbeschreibende Daten haben und möglicherweise einen damit verknüpften Steuerungscode. Wenn diese Anwendungen zuerst angeschaltet werden, erhält die Steuerung die Benutzerschnittstelle und das Steuerungsprogramm für die Anwendung. Ein Icon, welches die Anwendung zeigt, kann dann auf dem Fernsehbildschirm erscheinen, und das Manipulieren des Icons kann veranlassen, dass Elemente des Steuerungsprogramms die dargestellte Anwendung oder Anwendungen in vorgeschriebenen Wegen betätigen. Die Ausnahme zu diesem Modell sind Stammeinrichtungen, die weder selbstbeschreibende Daten noch einen Steuerungscode haben werden. Für zusätzliche Beschreibung und Stand der Technik in bezug auf selbstbeschreibende Daten wird der Leser aufmerksam gemacht auf Ludtke et al., A Method and Apparatus for Including Selfdescribing Information within Devices, vorläufige Anmeldungs-Nr. 60/054 327, angemeldet am 31. Juli 1997.
  • Es sei angemerkt, dass das HAVI-Netzwerk der vorliegenden Erfindung es unterstützt, dass "Reinstecken-Laufenlassen"-Verbraucheranwendungen leicht installiert werden können, und einen signifikanten Bereich ihres Werks dem Verbraucher ohne irgendwelche Aktion von Seiten des Verbrauchers über die physikalische Verbindung der Kabel hinaus bereitstellt. Dies ist in Unterschied zu existierenden Anwendungen, die Konfiguration erfordern, um einen Hauptbereich ihrer Funktionalität zu liefern. Das Ziel besteht darin, "heißes" Reinstecken und Laufenlassen zu bieten, (das nicht erfordert, dass der Benutzer die Anwendungen ausschaltet), wo die Anschaltungsverfahren dies sicher und verlässlich unterstützen.
  • Gemäß der vorliegenden Erfindung konfiguriert sich eine Anwendung selbst, und sie integriert sich in eine systemweite Benutzerschnittstelle "schaue und fühle"-Schnittstelle ohne Benutzerintervention. Die Niedrigebenen-Kommunikationsdienste liefern Information, wenn eine neue Anwendung auf dem AV-Netzwerk identifiziert wird. Obwohl es häufig Einstellungen geben wird, welche der Benutzer zu ändern wünscht, um seine Vorzüge anzupassen, erfordert die Anwendung nicht, dass der Benutzer dies ausführt, um Basisfunktionalität anzubieten.
  • Es sollte auch angemerkt sein, dass das HAVI-Netzwerk nach der vorliegenden Erfindung flexibel ist und mehrfache Benutzerschnittstellen unterstützt, wobei sowohl die Notwendigkeiten des Benutzers als auch die Notwendigkeit von Herstellern nach Warenzei chen-Unterscheidung angepasst wird. Im AV-Netzwerk steigen Protokolle elegant von sehr resourcenreichen, intelligenten, PC-förmigen Anwendungen zu "dummen" resourcen-verkümmerten Anwendungen (beispielsweise einen Kaffeeautomat oder Thermostat). Um dies zu erreichen, erlaubt die AV-Architektur, dass Anwendungen am hinteren Ende die Resourcen intelligenterer Anwendungen auf wohl definierte Weise nutzen. In einer ähnlichen Weise erlaubt die AV-Architektur die Spezifikation von Gesamtanwendungen, wo eine abstrakte Anwendung von einer logischen Sammlung mehrerer Anwendungen niedrigerer Ebene gebildet wird.
  • Zusätzlich sollte angemerkt sein, dass das HAVI-Netzwerk nach der vorliegenden Erfindung existierende Standards unterstützt. Das HAVI-Netzwerk ist komplementär zu mehreren existierenden bekannten Industriestandards und Technologien, einschließlich: CEBus; Heim-Reinstecken-Laufenlassen; EHSI; VESA; Heimnetzwerk, DAVIC; CoMMeND, Lonworks, USB, IEEE 1394, usw.. Folglich ist es eine Aufgabe der vorliegenden Erfindung, eine Infrastruktur bereitzustellen, zu der existierende Einrichtungen passen können.
  • Systemmodell der HAVI-Architektur
  • Mit Bezug auf 1A ist eine HAVI-Netzwerk 10a gemäß einer Ausführungsform der vorliegenden Erfindung gezeigt. Wie oben beschrieben unterstützt die HAVI-Architektur einen breiten Bereich von Einrichtungen, einschließlich intelligenter Empfänger/Decoder (IRDs), beispielsweise die Set-Top-Box 301, die digitalen Videobandrekorder (DVTRs), Videokassettenrekorder (VCRs), Personalcomputer (PCs), digitale Videoplattenspieler (DVDs), usw., die über ein gemeinsames Informationssystem miteinander kommunizieren. 1A zeigt die reale Port-Port-Verbindungskonfiguration 10a eines beispielhaften HAVI-Netzwerks. Es ist gezeigt, dass CE-Einrichtungen ("Einrichtungen") 12–24 miteinander mit Bussegmenten 30a–30f verbunden sind. Bei einer Ausführungsform von HAVI wird der IEEE 1394-Seriell-Kommunikations-Busstandard als Plattform verwendet, um das gemeinsame Informationssystem bereitzustellen.
  • 1B zeigt eine logische Buskonfiguration 10b des HAVI-Netzwerks von 1A. Wie in 1B gezeigt ist, können alle Einrichtungen 14–24 des HAVI-Netzwerks so betrachtet werden, dass sie logisch mit einem gemeinsamen IEEE 1394-Seriell-Kommunikationsbus verbunden sind. Innerhalb dieser Anordnung 10b wird eine Partner-Partner-Einrichtungs-Kommunikation unterstützt. Beispielsweise kann, wie in 1B gezeigt ist, jede Einrichtung (die geeignete Leistung hat) Kommunikationspakete zu einer anderen Einrichtung im HAVI-Netzwerk senden oder davon empfangen. Im Beispiel von 1B kann die Set-Top- Box 301 (beispielsweise eine IRD) Informationen von einer anderen Einrichtung 14–24 des HAVI-Netzwerks empfangen oder Informationen für diese erzeugen.
  • Betrachtet man weiter 1A und 1B, so liefert, wie oben beschrieben das Kompatibilitätsmodell bei HAVI folgendes: 1) Unterstützung für existierende Einrichtungen; 2) ein Vorgabesteuerungsmodell; 3) eine Einrichtung, das Vorgabesteuerungsmodell zu erweitern, wenn neue Einrichtungen oder Funktionalität auf den Markt gebracht werden; und 4) eine gemeinsame Einrichtung zur Einrichtungsdarstellung (beispielsweise grafische Benutzerschnittstellen). Um obiges zu erreichen definiert die HAVI-Architektur drei Arten von Knotenpunkten im Heimnetzwerk: Voll-AV-Knoten (FAV), Zwischen-AV-Knoten (IAV) und Basis-AV-Knoten (BAV).
  • Ein Voll-AV-Knoten ist eine Einrichtung, welche eine vollständige Instanz des AV-Software-Modells enthält (wird anschließend ausführlich beschrieben). Diese Art von Knoten besitzt allgemein einen reicheren Satz an Resourcen und ist in der Lage, eine komplexe Software-Umgebung zu unterstützen. Das primäre Unterscheidungsmerkmal eines FAV ist das, dass dieser in der Lage ist, Steuerungsverantwortlichkeit für weniger verfeinerte Einrichtungen zu übernehmen und führt dies dadurch durch, dass ein Steuerungsmodul geladen wird, üblicherweise von einer weniger verfeinerten Einrichtung, und führt dies lokal aus. Beispiele solcher Knotenpunkte würden Set-Top-Boxen (beispielsweise Set-Top-Box 301), intelligente Fernsehgeräte, Allzweck-Heimsteuerungseinrichtungen oder sogar Heim-PCs sein.
  • Zwischen-AV-Knoten sind allgemein preiswertere Einrichtungen, die begrenzte Resourcen haben. Sie liefern keine Ausführungsumgebung für Steuerungsmodule und können somit nicht als Hauptsteuerungen innerhalb des Heimnetzwerks arbeiten. Da sie beschränkte Resourcen haben, können sie auf Fernresourcen in einer von zwei Arten zugreifen: durch Arbeiten mit anderen IAV-Einrichtungen, welche einige Leistung, die sie nicht haben, bereitstellen, oder durch Verwendung eines FAV-Knotens, welcher ein Steuerungsmodul unterstützt, um diese zu steuern. In diesem zweiten Betriebsmodus verlassen sie sich auf Voll-AV-Knoten, um Einrichtungen, beispielsweise eine Anzeigeeinrichtung, Allgemeinzweck-Computerresourcen und irgendein Gesamtsteuerungsrahmennetzwerk bereitzustellen. Dies erlaubt, dass Voll-AV-Einrichtungen eine Vielzahl von Zwischen-AV-Einrichtungen zusammenbinden können, um einen Dienst oder Abstraktion dem Benutzer bereitzustellen.
  • Basisknoten sind Knoten, die weder FAV- oder IAV-Knoten sind. Diese sind zwei allgemeine Arten: Stammbasisknoten oder andere Basisknoten. Stammbasisknoten sind Einrichtungen, die vor dem Erscheinen der HAVI-Architektur gebaut wurden. Diese Einrichtungen benutzen häufig eigene Protokolle für ihre Steuerung und haben ziemlich häufig ein ein faches wohl definiertes einiges Steuerungsprotokoll. Diese Einrichtungen können in einem HAVI-Netzwerk arbeiten, erfordern jedoch, dass ein Voll-AV-Knoten als Durchlass arbeitet. Kommunikation zwischen einem Voll- oder Zwischen-AV-Knoten und Stammeinrichtungen erfordert, dass die Heim-AV-Befehle, welche in der HAVI-Architektur verwendet werden, in das Stammbefehlsprotokoll übertragen werden und davon übertragen werden. Andere Basisknotenpunkte sind Einrichtungen, die für Geschäfts- oder Resourcengründe es wählen, zukünftiges sicheres Verhalten unter Verwendung von nach oben ladbarer Steuerungssoftware durchzuführen und nicht irgendeine HAVI-Architektur oder Informationskommunikationssystem tragen. Diese Einrichtungen werden durch einen FAV-Knoten mit einem privaten Befehlsprotokoll zwischen dem FAV- und BAV-Knoten gesteuert.
  • Mit Ausnahme der Stammknoten hat jeder Knoten als Minimum genug Funktionalität, um es diesem zu erlauben, mit anderen Knoten im System zu kommunizieren. Während des Laufes des Zusammenarbeitens tauschen Knoten Steuerungs- und Dateninformation aus, um es Einrichtungen zu ermöglichen, miteinander zu arbeiten und dies in einer Partner-Partner-Weise durchführen. Dies stellt sicher, dass in der Kommunikationsebene keine Einrichtung erforderlich ist, um als Hauptgerät oder Steuerung für das System zu arbeiten. Dies erlaubt jedoch auch, dass einem logischen Mastergerät oder einer Steuerung eine Steuerungsstruktur auf Basis des Partner-Partner-Kommunikationsmodells auferlegt wird. Dienste im HAVI-Netzwerk werden durch einen oder mehrere Knoten bereitgestellt, die untereinander selbst kommunizieren, um einen Dienst dem Benutzer oder einer Anwendung zu liefern. Wenn es für einen Knoten notwendig ist, mit einem Benutzer zusammenzuwirken, verhandelt der Knoten mit anderen Knoten, um auf eine Anzeigeeinrichtung zuzugreifen und diese zu verwenden.
  • Zusätzlich sollte erkannt werden, dass eine Unterscheidung zwischen logischen und realen Knoten getroffen wird. Ein gutes Beispiel dieser Unterscheidung kann in einem normalen TV-Gerät gefunden werden. Obwohl das TV-Gerät allgemein eine reale Box ist, enthält es mehrere funktionelle Komponenten, beispielsweise den Tuner, die Audioausgabe, usw.. Vom Systemstandpunkt aus ist ein realer Knoten ein adressierbarer Partnerknoten im System. Wenn das Fernsehgerät so aufgebaut ist, dass seine individuelle funktionellen Komponenten individuell adressierbar sind, ist dieses dann logisch ein Knoten und physikalisch mehrere Knoten. Umgekehrt, wenn dieses so aufgebaut ist, dass es eine adressierbare Entität hat, ist diese sowohl ein einzelner logischer Knoten als auch ein einzelner physikalischer Knoten.
  • Die IAV-Einrrichtungen und die FAV-Einrichtungen kommunizieren miteinander, indem sie Information über das Heimnetzwerk unter Verwendung eines allgemeinen Informationsdurchlasssystems senden. Wenn neue Einrichtungen zum Heimnetzwerk hinzukommen, werden sie erkannt und zu einer globalen Namensdatenbank (Registratur) hinzugefügt. Die Registratur hält Information über deren Merkmale und liefert eine Referenz zum Betreuer für diese Einrichtung. Andere Einrichtungen und Dienste sind in der Lage, die Registratur abzufragen, um eine Einrichtung zu lokalisieren und dann unter Verwendung des Betreuers mit der Einrichtung zusammenarbeiten kann. Für zusätzliche Beschreibungen und Stand der Technik in bezug auf die Kommunikations- und Identifikationsprozesse der vorliegenden Erfindung wird der Leser hingewiesen auf Ogino et al, "Method and System for Providing a Device Identification Mechanism within a Consumer Audio/Video Network", eine US-Patentanmeldung, welche am 6. Januar 198 angemeldet wurde.
  • Wenn eine Einrichtung zunächst dem Heimnetzwerk zugefügt wird, fragt das System die Einrichtung ab, um deren Kenndaten und Fähigkeiten sicherzustellen. Wenn die Kenndaten einer Einrichtung einmal bekannt sind, liefert die Architektur zwei Verfahren, um diese zu steuern. Das erste Verfahren, die Ebene-1-Kompatibilität, verwendet einen vorher festgelegten Informationssatz. Alle IAV- und FAV-Knoten können diesen Befehlssatz verwenden, um auf andere Einrichtung zuzugreifen und diese zu steuern (BAV-Knoten, da diese entwickelt wurden, bevor die Architektur definiert wurde, werden unter Verwendung von Stammprotokollen gesteuert). Dies liefert eine Vorgabesteuerungsebene. Die FAV-Knoten wirken als Steuerungsknoten und bilden einen lokale Repräsentation des IAV-Knotens, der als Einrichtungssteuerungsmodul (DCM) bekannt ist, welches eine API liefert, die verwendet wird, um Steuerungsbefehle zur Einrichtung zu senden.
  • Die Ebenen-2-Kompatibilität innerhalb HAVI geht weiter und unterstützt zukünftig hinzugefügte Funktionalität und neue Einrichtungen. Um dies zu erreichen kann eine bestimmte Einrichtung innerhalb ihres ROM ein Aufschaltungs-DCM, welches von der IAV-Einrichtung nach oben geladen wird, zur FAV-Einrichtung tragen und ersetzt das Vorgabe-DCM für die bestimmte Einrichtung. Dieses Aufschaltungs-DCM enthält nicht nur den Basisebenen-1-Befehlssatz für die bestimmte Einrichtung, sondern auch verkäufer-spezifische Befehle, um weiterentwickelte Merkmale der Vorrichtung zu steuern. Das Modell erlaubt der Einrichtung, eine andere über ihre bestimmte Funktionalität zu informieren. Da das Aufschaltungs-DCM auf jeden FAV-Knoten des Verkäufers geladen werden kann, ist das Format des DCM architektur-neutral.
  • Um es einer Einrichtung zu erlauben, die Leistungen einer anderen Einrichtung zu entdecken und zu bestimmen, welcher Befehlssatz mit dieser Einrichtung zu verwenden ist, ist eine Standardeinrichtungs-Beschreibungsstruktur vorgesehen, die als Selbstbeschreibungs-Datenstruktur (SDD) bezeichnet wird. Die SDD-Datenstruktur ist erweiterbar. Sie kann eine kleine Anzahl von Bytes sein, welche den Einrichtungstypus beschreibt, beispielsweise den Fernseher oder den VTR usw.. Alternativ kann die SDD-Datenstruktur eine komplexere Struktur sein, welche das Aufschaltungs-DCM und eine grafische Darstellung der Einrichtung definiert. Die grafische Darstellung innerhalb der SDD-Datenstruktur erlaubt es, dass ein FAV-Knoten eine Bilddarstellung der Einrichtungen im Heimnetzwerk den Benutzern zeigt. Durch Definieren der grafischen Darstellung in einer ausreichend allgemeinen Weise können grafische Daten der Einrichtungs-SDD in irgendeinem Produkt von Verkäufern verwendet werden, um eine Benutzerschnittstelle für diese Einrichtung anzuzeigen. Dies liefert eine verbesserte Ebene an Verkäuferkompatibilität und erlaubt es außerdem einem Verkäufer, ein Produkt zu differenzieren, während er innerhalb eines allgemeinen Blickfelds und Gefühls der Anzeigeeinrichtung bleibt. Dies ermöglicht es, dass eine Steuerungseinrichtung (der FAV-Knoten) eine allgemeine Steuerungsbenutzerschnittstelle für alle Einrichtungen im Heimnetzwerk unabhängig von den Unterschieden von Typus und Verkäufer zeigt.
  • Wie oben beschrieben sind Stammeinrichtungen Einrichtungen, die vor der HAVI-Architektur gebaut wurden, oder Einrichtungen, die nicht wählen, HAVI zu verwenden. HAVI unterstützt Stammeinrichtungen durch Bereitstellen von Stamm-DCMs, um Protokollumsetzungen für Stammeinrichtungen bereitzustellen. Diese Stamm-DCMs können ausreichende Kenntnis enthalten, um es diesen zu erlauben, ein existierendes Einweg- oder Zweiweg-Steuerungsprotokoll zu unterstützen und eine spezielle Steuerungsschnittstelle den Einrichtungen zu liefern, welche mit HAVI konform sind. Ein Stamm-DCM wirkt wie eine Brücke zwischen den Stamm- und HAVI-Einrichtungen. Dieser Versuch erlaubt es der HAVI ebenfalls, mit irgendwelchen zukünftigen Einrichtungssteuerungsprotokollen zusammenzuarbeiten, wobei diese Protokolle für Heimenergieverwalung oder Sicherheit verwendet werden.
  • Es sollte gewürdigt werden, dass die Kommunikations-Hardware und die Protokolle, welche durch die HAVI-Architektur verwendet werden, nicht-spezifisch sind. Die HAVI-Architektur ist schnell für die Eingliederung und die Verwendung von irgendeinem von mehreren Kommunikationsmedien geeignet, mit dem einfachen Erfordernis, dass das Medium einen allgemeinen Kommunikationsmechanismus bereitstellt, der die HAVI-Schnittstellen unterstützt. Das angenommene Basismodell ist eines einer logischen hinteren Kommunikationsebene (beispielsweise IEEE 1394). Es wird angenommen, dass alle AV-Einrich tungen mit dieser hinteren Ebene verbunden sind und alle anderen AV-Einrichtungen lokalisieren können und mit diesen kommunizieren können, wie in 1B gezeigt ist. Bei einer realen Einstellung ist es wahrscheinlich, dass diese logische hintere Ebene aus mehr als einem realen Kommunikationsmedium bestehen wird. Es wird weiter angenommen, dass Mehrfachprotokolle bei unterschiedlichen realen Medien verwendet werden können. Die Heim-AV-Architektur abstrahiert vor allem dies und stellt ein allgemeines Kommunikationsknotenmodell bereit. Sie wird einen Mechanismus über die Transport-Schicht (funktionsmäßig wie ein Sockel) bereitstellen, um Netzwerktransparenz sicherzustellen. Dieser Mechanismus kann als "verlässlicher, geordneter Datengrammdienst" beschrieben werden, der die gesamte Aufteilung und Umanordnung bereitstellen wird.
  • Folglich ist es eine Aufgabe der vorliegenden Erfindung, jeden realen Bus gleich zu unterstützen, so dass sich eine Anwendung nicht zu kümmern muss, welchen realen Transport sie verwendet. Mit der Vertrautheit von IEEE 1394 in der elektronischen Industrie werden jedoch Merkmale der vorliegenden Ausführungsform im Hinblick auf Funktionieren mit IEEE 1394 gezeigt und beschrieben. Andere Busse als der CEBus und USB mögen nicht alle die gleichen Merkmale erfordern.
  • Gemäß 2 nun ist ein beispielhaftes Partner-Partner-Netzwerk, nämlich ein Zwei-IAV-Knoten-HAVI-Netzwerk 200 gemäß einer Ausführungsform der vorliegenden Erfindung gezeigt. Das HAVI-Netzwerk 200 besitzt einen ersten IAV 201 (beispielsweise einen Fernseher), der mit einem zweiten IAV 202 (beispielsweise einem Empfänger) gekoppelt ist. IAV 201 und IAV 202 verhalten sich in einer Partner-Partner-Weise, die notwendige Resourcen untereinander bereinigen. Sie ermangeln an Resourcen, um die Hinzufügung einer BAV- oder LAV-Einrichtung zu unterstützen, können jedoch bedeutungsvolle Aktivitäten innerhalb ihres Zusammenhangs durchführen. Es ist nicht erforderlich, dass der IAV irgendeine Standard-UI-Fähigkeit bereitstellt. Es gibt keine Bereitstellung in der AV-Architektur für "Vorwärtskompatibilität" oder zum Entdecken von neuen Funktionen (beispielsweise IAV 201 kennt lediglich die Funktionen, welche die IAV 202 unterstützt, auf der Basis von SDD, die bei Anschaltung von IAV 2 vorgesehen ist). Gemäß der vorliegenden Erfindung können die Merkmale von SDD jedoch leicht entwickelt werden, um eine "sofortige" Merkmalsentdeckung durchzuführen.
  • 3 zeigt ein Gruppen-HAVI-Netzwerk 300 mit einem einzelnen FAV-Knoten gemäß einer Ausführungsform der vorliegenden Erfindung. Das HAVI-Netzwerk 300 umfasst einen FAV 301 (beispielsweise eine Set-Top-Box), die entsprechend mit einem ersten LAV 302 (beispielsweise einem Fernsehgerät), einem zweiten LAV 303 (beispielsweise einem VCR) und einem BAV 304 (beispielsweise einer Digitalkamera) gekoppelt ist. Im HAVI-Netzwerk 300 steuert der FAV 301 Stamm- und Basis-AV-Einrichtungen (beispielsweise Einrichtungen 302–304), der gruppenweite Dienste bereitstellt.
  • 4 zeigt eine FAV-Gruppe, die in einem IAV-Partner-Partner-HAVI-Netzwerk 400 integriert ist. Gemäß der vorliegenden Erfindung liefert die Konfiguration des HAVI-Netzwerks 400 Unterstützung für Stammeinrichtungen 302 und 303, während unabhängige Steuerung ermöglicht wird, die innerhalb der beiden IAV-Einrichtungen 401 und 402 auftritt, wenn deren Resourcen nicht durch die FAV-Einrichtung 301 in Verwendung sind. Die IAV-Einrichtungen 401 und 402 verhalten sich wie Partner zur FAV-Einrichtung 301. Aus Wirksamkeitsgründen kann eine Resourcenkonfliktpolice für sowohl FAV zu FAV als auch für FAV zu IAV-Resourcenanfragen verwirklicht werden. Der IAV wird über ein DCM, das in FAV 301 läuft, durch den FAV gesteuert.
  • 5 zeigt ein beispielhaftes HAVI-Netzwerk, welches mehrere FAVs hat. Das HAVI-Netzwerk 500 umfasst einen zusätzlichen FAV 501 (beispielsweise einen Satellitenempfänger). Diese Konfiguration verhält sich in einer ähnlichen Weise zum HAVI-Netzwerk 400, wie oben beschrieben. In dieser Konfiguration wirken die FAV-Einrichtungen 301 und 501 wie Partner.
  • Computersystem-Plattform
  • Unter Bezugnahme auf 6 wird nun ein Diagramm einer Set-Top-Box 301 gemäß einer Ausführungsform der vorliegenden Erfindung gezeigt. Wie oben beschrieben kann jegliche elektronische Verbrauchereinrichtung ein FAV sein und dadurch eine Computersystem-Plattform für HAVI-Software bereitstellen. Beispielsweise enthält die Set-Top-Box 301 des beispielhaften HAVI-Netzwerks spezielle Komponenten, die eine Betriebsplattform für Software-Komponenten der HAVI-Architektur bereitstellen, was anschließend beschrieben wird. Insbesondere werden Merkmale der vorliegenden Erfindung, die anschließend beschrieben werden, in Form von Schritten besprochen, welche auf einem Computersystem ausgeführt werden (beispielsweise Prozesse, welche in 13 bis 17A gezeigt sind). Obwohl eine Vielzahl unterschiedlicher Computersysteme bei der vorliegenden Erfindung verwendet werden kann, ist ein beispielhaftes Allgemeinzweck-Computersystem in der Set-Top-Box von 6 dargestellt.
  • Die Set-Top-Box 301 von 6, welche zusätzlich einen Video-/Audio-Empfänger (Decoder) 606 und eine MPEG-Einheit 607 hat, besitzt außerdem einen Adress-Datenbus 600 zur Mitteilung von Information, einen oder mehrere Zentralprozessoren 601, welche mit dem Bus zur Verarbeitung von Information und Instruktionen gekoppelt sind, einen flüchtigen Speicher 602 (beispielsweise einen Speicher mit wahlfreiem Zugriff RAM), der mit dem Bus 600 gekoppelt ist, um Information und Instruktionen für den Zentralprozessor 601 zu speichern, und einen nichtflüchtigen Speicher 603 (beispielsweise einen Nur-Lese-Speicher ROM), der mit dem Bus 600 gekoppelt ist, um statistische Information und Instruktionen für den Prozessor 601 zu speichern. Die Set-Top-Box 301 kann außerdem optional eine Datenspeicherungseinrichtung 604 ("Platten-Subsystem") aufweisen, beispielsweise eine Magnetplatte oder eine optische Platte, und eine Plattenansteuerung, welche mit dem Bus 600 gekoppelt ist, um Information und Instruktionen zu speichern. In der Set-Top-Box 301 ist außerdem eine Busschnittstelleneinheit 608 enthalten, um eine Schnittstelle mit einem lokalen Bus 30 (beispielsweise einen IEEE 1394-Seriell-Bus) zu bilden. Die Set-Top-Box 301 kann unter einer Vielzahl von unterschiedlichen Betriebssystemen arbeiten (beispielsweise das Betriebssystem von Windows, das DOS-Betriebssystem, Macintosh O/S), wobei jedoch bei der vorliegenden Ausführungsform das Aperios-Betriebssystem verwendet wird.
  • Das HAVI-Software-Modell
  • Gemäß der vorliegenden Erfindung werden die Berechnungseinheiten der HAVI-Architektur (beispielsweise DCMs) als Objekte modellhaft dargestellt. Jedes Objekt ist eine selbstbeherrschende Entität, auf die über eine definierte Schnittstelle zugegriffen werden kann und innerhalb einer definierten Software-Führungsumgebung eine Ausführung vornimmt. Die Software-Ausführungsumgebung (beispielsweise Set-Top-Box 301 von 6) liefert einen Satz von definierten Diensten (lokal oder entfernt), die auch als Objekt modelliert sind und auf die unter Verwendung der Kommunikationsstruktur über ihre definierten Schnittstellen zugegriffen werden kann.
  • Jedes Objekt ist eigens bezeichnet. Es wird keine Unterscheidung zwischen Objekten getroffen, die verwendet werden, Systemdienste aufzubauen und denjenigen, welche für Anwendungsdienste verwendet werden. Alle Objekte machen sich über die Registratur selbst bekannt. Objekte im System können die Registratur abfragen, einen bestimmten Dienst oder eine Einrichtung zu finden und können das Ergebnis dieser Anfrage nutzen, Informationen zu diesem Dienst oder dieser Einrichtung zu liefern. Der Kennzeichner, der einem Objekt zugeordnet ist, wird gebildet, wenn das Objekt registriert wird. Diese Identifizierung, wenn erforderlich, ist garantiert, so dass sie während der Lebensdauer des Objekts anhält und wird verbleiben, sogar im Falle eines kompletten Neubootens des Heimnetzwerks.
  • Gemäß der vorliegenden Erfindung kommunizieren die Objekte unter Verwendung eines Informationsdurchlaufmodells. Ein Objekt, welches wünscht, den Dienst eines anderen Objekts zu nutzen, tut es so, dass ein Allgemeinzweck-Informationsdurchlaufmechanismus verwendet wird, der die Dienstanfrage zum Zielobjekt liefert. Das Zielobjekt wird unter Verwendung des einmaligen Objektkennzeichners, der oben erläutert wurde, spezifiziert. Obwohl bei der vorliegenden Ausführungsform der Informationsdurchlaufmechanismus mit IEEE 1394 arbeitet, sollte angemerkt werden, dass es keine Unterscheidung zwischen dem Senden einer Information über einen 1394-Bus oder über eine Steuerungs-A1-Verknüpfung gibt. In der gleichen Weise gibt es keine Unterscheidung zwischen Objekten auf dem gleichen Knoten und einem auf einem entfernten Knoten. Die tatsächliche Ausführung der Informationsdurchlassinfrastruktur wird vom System und der Vernetzungsumgebung abhängen und wird von Knoten zu Knoten und zwischen Verkäufern sich unterscheiden. Das aktuelle Format von Informationen muss jedoch gemeinsam sein, so dass die Kompatibilität sichergestellt ist.
  • Es sollte anerkannt werden, dass die allgemeine Absicht des Objektmodells und des Informationssystems darin besteht, ein vollständig allgemeines Software-Modell bereitzustellen, welches ausreichend flexibel ist, Mehrfachdurchführungen mit einer Vielzahl von Software-Systemen und Sprachen zu erlauben. Details zum Binden zwischen Informationen und dem Code, der diese handhabt, sind dem Systemausführer überlassen.
  • Überblick über die Software-Architektur
  • Die HAVI-Software-Architektur definiert die Art und Weise, wie das Software-Modell verwendet wird, um die HAVI-Architektur zu unterstützen. Insbesondere definiert sie die Art und Weise, wie Einrichtungen innerhalb der AV-Architektur abstrahiert und verwaltet werden. Sie definiert die Art und Weise, dass Kompatibilität sichergestellt wird, und sie definiert die Art und Weise, dass zukünftige Einrichtungen und Dienste in die Architektur integriert werden können.
  • Voll-AV-Knotenpunkte als Software-Verwalter: gemäß der vorliegenden Erfindung arbeiten Voll-AV-Knoten (FAVs) wie Verwalter für Zwischenknoten (IAVs) und Basisknoten (BAVs) und liefern eine Plattform für die Dienste, die die HAVI-Architektur unterstützt. Um dies zu erreichen, stellen sie eine Ausführungsumgebung bereit, die erlaubt, Objekte zu steuern und mit Diensten und Einrichtungen zu kommunizieren. Um sicherzustellen, dass auf Einrichtungen innerhalb des Heim-AV-Netzwerks zugegriffen werden kann, unterstützen die FAV-Knoten eine Software-Abstraktion der Dienste, die eine Einrichtung anderen bietet. Wie oben beschrieben ist diese Abstraktion auf ein Einrichtungssteuerungsmodul (DCM) bezogen. Dieses DCM ist als ein Objekt innerhalb der Software-Architektur modelliert, jedoch wird dies anschließend einfach als DCM bezeichnet, um dies zu unterscheiden. Die Schnittstelle, die das DCM gegenüber dem Rest des Systems zeigt, liefert die Einrichtung, um auf diese Einrichtung zuzugreifen und diese zu steuern. Im allgemeinen Fall wird ein FAV einen Satz von DCMs verwalten, jeweils eines für einen IAV-Knoten und einen Basisknoten im Heimnetzwerk oder einem Bereich des IAV-Netzwerks, das sie verwaltet. Somit sollte es geschätzt werden, dass von der Perspektive einer Kompatibilität die primäre Aufgabe des FAV-Knotens darin besteht, DCMs der vorliegenden Erfindung zu verwalten und wie eine Ausführungsumgebung für DCMs zu wirken.
  • Voll-AV-Knotenpunkt als Steuerung und Anzeigeeinrichtung: gemäß der vorliegenden Erfindung werden in den meisten Fällen die FAVs eine damit verbundene Anzeigeeinrichtung aufweisen, welche zur Anzeige von AV-Inhalt und von Benutzerschnittstellenmaterial (UI) verwendet wird. Die HAVI-Software-Architektur wird dies jedoch nicht vorschreiben, und FAV-Knoten können "kopflos" sein. In diesem Fall werden sie mit anderen Knoten zusammenarbeiten, um Inhalt und UI-Information (siehe unten) anzuzeigen. Diese FAV-Einrichtungen werden jedoch dafür verantwortlich sein, die Hochebenen-UI-APIs zu unterstützen, die das Aussehen und das Empfinden des gesamten Heimnetzwerks bereitstellen. Die Grafikmanipulations-APIs der unteren Ebene werden jedoch allgemein in der Nähe der Grafikanzeigeeinrichtung selbst angeordnet sein und durch die FAV-Hochebenen-APIs gehandhabt werden.
  • Partner-Partner-Architektur zwischen Voll-AV-Knoten: in einem Heim-AV-Netzwerk gemäß der vorliegenden Erfindung kann es mehr als einen FAV geben. In diesem Fall arbeitet jeder FAV mit anderen FAVs zusammen, um sicherzustellen, dass dem Benutzer Dienste bereitgestellt werden. Dies erlaubt, dass FAV-Knoten mit Anteilsresourcen zusammenarbeiten. Beispielsweise kann ein FAV-Knoten, der keinen direkten Zugriff zu einer Anzeigeeinrichtung hat, einen entfernten FAV-Knoten nutzen, um DCM-Benutzerschnittstellen anzuzeigen. Alternativ kann ein FAV-Knoten die Dienste eines Datenübertragungsmoduls erforderlich machen, welches in einem entfernten Knoten existiert, um diesem zu erlauben, einen Datenweg zwischen zwei AV-Einrichtungen einzurichten.
  • Allgemeine Kompatibilität von Ebene 1 und Ebene 2
  • Gemäß der vorliegenden Erfindung ist es eine der Hauptaufgaben der HAVI-Architektur der vorliegenden Erfindung, die Kompatibilität zwischen Einrichtungen zu unter stützen. Dies umfasst existierende Einrichtungen und zukünftige Einrichtungen. Um diese Kompatibilität zu erreichen, unterstützt die HAVI-Architektur nach der vorliegenden Erfindung ein allgemeines Modell, welches zwei Kompatibilitätsebenen zulässt. Diese Ebenen werden als Ebene 1 und Ebene 2 bezeichnet.
  • Ebenen-1-Kompatibilität: die Ebenen-1-Kompatibilität nach der vorliegenden Erfindung adressiert sich auf die allgemeine Notwendigkeit, existierenden Einrichtungen zu erlauben, zu kommunizieren. Um dies zu erreichen, definiert und verwendet die Ebenen-1-Kompatibilität nach der vorliegenden Erfindung einen allgemeinen Satz an Steuerungsmitteilungen (Befehlen), um eine Einrichtung in die Lage zu versetzen, mit der anderen Einrichtung zu sprechen, und einen Satz an Ereignisinformationen, die vernünftigerweise von der Einrichtung erwartet werden könnten. Um diesen Versuch zu unterstützen, ist ein Basissatz von Verarbeitungen erforderlich. Diese Verarbeitungen umfassen Einrichtungsentwicklung, Kommunikation und einen allgemeinen Informationssatz.
  • Der Einrichtungserkennungsprozess nach der vorliegenden Erfindung liefert die Tatsache, dass jede Einrichtung im Heim-AV-Netzwerk ein gut definiertes Verfahren benötigt, welches es ihm erlaubt, anderen seine Kenndaten anzukündigen. Der Versuch, den wir angenommen haben, besteht darin, eine Datenstruktur zu spezifizieren, die für alle FAV- und IAV-Einrichtungen erforderlich ist, der Information über die Einrichtung enthält und auf die durch alle anderen Einrichtungen zugegriffen werden kann. Diese Datenstruktur wird als Selbstbeschreibungs-Datenstruktur (SDD) bezeichnet. Die SDD enthält als Minimum genügend Information, um es anderen Einrichtung zu erlauben, ihre Basisleistung zu erkennen und insoweit den Basissatz von Befehlsinformationen, die zu dieser Einrichtung geliefert werden können, und Ereignisse, von denen sie vernünftigerweise erwarten kann, von dieser Einrichtung empfangen zu werden.
  • Das Kommunikationsverfahren nach der vorliegenden Erfindung liefert die Tatsache, dass, wenn eine Einrichtung einmal die Leistung einer anderen Einrichtung bestimmt hat, diese dann in der Lage sein muss, um auf diese Fähigkeiten zuzugreifen. Um dies zu erreichen, erfordert dies eine allgemeine Kommunikationsfähigkeit, die es einer Einrichtung erlaubt, eine Information, die eine Befehlsanforderung enthält, zu einer anderen Einrichtung zu senden. Die allgemeinen Informationsdienstverarbeitungen der vorliegenden Erfindung wurden oben erläutert.
  • Ein allgemeines Informationsgerät bezieht sich auf das Verfahren, welches erforderlich ist, die Ebenen-1-Kompatibilität zu unterstützen. Dies umfasst einen gut definierten Satz an Informationen, welche durch alle Einrichtungen einer bestimmten Klasse unterstützt werden müssen. Dies stellt sicher, dass eine Einrichtung mit anderen Einrichtungen arbeiten kann, unabhängig vom Hersteller, da alle Einrichtungen mit einem gemeinsamen Satz an allgemeinen Befehlen übereinstimmen. Wie oben erläutert werden innerhalb der HAVI-Software-Architektur nach der vorliegenden Erfindung diese Befehle als DCM dem Rest des Systems präsentiert.
  • Diese drei grundsätzlichen Verfahren nach der vorliegenden Erfindung unterstützen zumindest einen Minimalgrad an Kompatibilität. Da in den meisten Fällen irgendeine Einrichtung die Fähigkeiten einer anderen über die SDD abfragen kann, kann irgendeine Einrichtung den Befehlssatz, der durch die andere Einrichtung unterstützt wird, bestimmen. Da jede Einrichtung Zugriff zu einem allgemeinen Informationssystem hat, kann dann irgendeine Einrichtung mit einer anderen Einrichtung zusammenarbeiten.
  • Es sollte jedoch gewürdigt werden, dass die Ebenen-1-Kompatibilität gemäß der vorliegenden Erfindung lediglich sicherstellt, dass Einrichtungen mit einer minimalen oder verschlechterten Ebenen-Funktionalität miteinander operieren können. Der allgemeine Informationssatz für jede Einrichtungsklasse ist ein minimaler und gemeinsamer Satz an Befehlen. Die SDD-Fähigkeit bietet eine Einrichtung, um einen gewissen Grad an Kundenbedarf einer Einrichtung bereitzustellen, indem Information über ihre UI und einigen Merkmalen des zusammenarbeitenden Modells bereitgestellt wird. Andere IAV-Einrichtungen können diese Information nutzen, um eine Schnittstelle für die Einrichtung zu zeigen. Alternativ kann irgendeine FAV-Einrichtung diese Information dazu verwenden, das allgemeine DCM auf den Kunden zuzuschneiden, das für diese Einrichtung erzeugt wurde. Es sollte jedoch angemerkt sein, dass ein mehr erweiterbarer Mechanismus auch benötigt wird, um es einer Einrichtung zu erlauben, mit anderen Einrichtungen zu kommunizieren, wenn irgendwelche zusätzliche Funktionalität auftritt. Die Ebenen-2-Kompatibilität der vorliegenden Erfindung liefert diesen Mechanismus. Die Ebenen-1- und die Ebenen-2-Kompatibilität werden anschließend ausführlicher erläutert.
  • DCMs für Ebene 1 und Ebene 2
  • Wie oben beschrieben funktioniert das DCM nach der vorliegenden Erfindung durch Bereitstellen von Zugriff, Steuerung und Zusammenarbeiten mit einer Einrichtung. DCMs sind üblicherweise auf den Resourcen von FAVs in der Heim-AV-Architektur spezialisiert (werden beispielsweise ausgeübt). Das DCM nach der vorliegenden Erfindung stellt eine Schnittstelle für eine Einrichtung bereit und verwaltet eine UI, welche die Einrichtung wünscht, den Benutzern dies zu zeigen.
  • Gemäß der vorliegenden Erfindung sind mit der Ebenen-1-Kompatibilität die DCMs, die für Einrichtungen gebildet sind, allgemein. Sie unterstützen einen allgemeinen Befehlssatz, der allgemeine Steuerung der Einrichtung erlaubt. Um spezielle Einrichtungsmerkmale zu unterstützen, erfordert dies, dass das DCM Zugriff zu diesen speziellen Einrichtungsmerkmalen hat und in der Lage ist, spezielle Einrichtungsmerkmale den Benutzern über die UI zu zeigen.
  • Um dies zu erreichen, wird die Ebenen-2-Kompatibilität verwendet. Gemäß der vorliegenden Erfindung erlaubt die Heim-AV-Architektur es einer Einrichtung, ein "Aufschaltung"-DCM für das allgemeine DCM bereitzustellen, welches normalerweise für diese Einrichtung gebildet würde. Das Aufschaltungs-DCM (beispielsweise Ebenen-2-DCM) ist in der Lage, das Vorgaben-DCM (beispielsweise Ebenen-1-DCM) auf dem FAV zu ersetzen. Es sollte anerkannt werden, dass das Ebenen-2-DCM von einer Vielzahl von Quellen gewonnen werden könnte. Eine derartige Quelle ist die SDD der Einrichtung selbst. In diesem Fall wird das Ebenen-DCM geholt, empfangen oder anderweitig von der SDD der Einrichtung erworben und in einem FAV-Knoten spezialisiert, wenn die Einrichtung in dem System installiert wird. Da die Heim-AV-Architektur verkäufer-neutral ist, ist es notwendig, dass das Ebenen-2-DCM auf einer Vielzahl von FAV-Knoten arbeitet, jedes mit potentiell unterschiedlicher Hardware-Architektur. Um dies zu erreichen ist das Format des DCM sowohl der Ebene 1 als auch der Ebene 2 nach der vorliegenden Erfindung architektur-neutral, so dass eine große Vielzahl von Software-Ausübungsumgebungen der FAV-Knoten in der Lage sind, DCMs nach der Ebene 1 und der Ebene 2 zu spezialisieren und darauf zu laufen.
  • Es sollte gewürdigt werden, dass gemäß der vorliegenden Erfindung die DCMs, wenn sie einmal gebildet und innerhalb eines FAV-Knotens laufen, nach der vorliegenden Erfindung mit dem IAV- und BAV-Knoten in der gleichen Weise wie oben beschrieben unter Verwendung des grundsätzlichen Informationsmechanismus kommunizieren.
  • Wie oben beschrieben sind viele Vertauschungen von FAV, IAV und BAV-Knoten innerhalb eines bestimmten HAVI-Netzwerks möglich. Diese Vertauschungen fallen allgemein in zwei Arten: HAVI-Netzwerkkonfigurationen, die eine FAV-Einrichtung unterstützen und die, die dis nicht tun. Diese Unterscheidung definiert im Wesentlichen, ob ein HAVI-Netzwerk eine Partner-Partner-Konfiguration verwenden wird (beispielsweise wie in 2 gezeigt ist, wo keine FAV-Einrichtung vorhanden ist) oder eine Form von Steuerungshierarchie belasten wird (beispielsweise die FAV-Gruppe, wie in 3 gezeigt ist).
  • Gemäß einer Ausführungsform der vorliegenden Erfindung ist in den Fällen, wo keine FAV-Einrichtung vorhanden ist, lediglich Ebene-1-Kompatibilität verfügbar und die Einrichtungen werden gezwungen, SDD-Information zu nutzen, um andere IAV-Leistungen zu entdecken, die diese Leistungen zeigen und die die Einrichtung steuern. In den Fällen sind, wo FAVs vorhanden sind, DCMs spezialisiert und werden verwendet. Wenn diese Ebenen-1-DCMs (beispielsweise allgemeine DCMs) sind, arbeiten die Einrichtungen bei Ebenen-1-Kompatibilität. Wenn zumindest ein Ebenen-2-DCM vorhanden ist, arbeiten dann einige der Einrichtungen bei Ebenen-2-Kompatibilität.
  • Gemäß der vorliegenden Erfindung sollte angemerkt sein, dass ein gemischter Betriebsmodus möglich ist, in welchem Gruppen von Einrichtungen miteinander unter der Steuerung eines FAV-Knotens arbeiten, während andere Einrichtungen in einer Partner-Partner-Weise arbeiten. Auf diese Weise erlaubt die Flexibilität der vorliegenden Erfindung Verkäufern die Freiheit, Einrichtungen an allen Punkten des Kosten/Leistungsspektrums mit der Sicherheit zu entwerfen und zu bauen, dass diese Einrichtungen mit anderen Einrichtungen im HAVI-Netzwerk nahtlos arbeiten werden.
  • In 7 ist ein logisches Blockdiagramm 700 einer Ausführungsform der HAVI-Architektur gezeigt. 7 zeigt eine Gesamt-HAVI-Architektur gemäß der vorliegenden Erfindung. Die im Diagramm 700 gezeigten Komponenten sind wie folgt:
    Einrichtungsmanager 761: der Einrichtungsmanager 761 ist dafür verantwortlich, die DCMs, welche die Einrichtungen, die durch eine FAV-Einrichtung verwaltet wird, zu bilden und zu verwalten.
    Einrichtungsmodule 720: diese sind die DCMs für individuelle Einrichtungen. Wie oben beschrieben arbeitet jedes DCM als Steuerungspunkt für eine Einrichtung und liefert eine UI-Komponente und eine Steuerungskomponente. Die DCMs (beispielsweise die Einrichtungsmodule 720) liefern eine API, um es anderen Anwendungen zu erlauben, auf die Einrichtungen zuzugreifen und die Einrichtungen zu verwalten.
    Dienstmodule 730: diese Module können als Software-Einrichtungen angesehen werden. Sie sind DCMs für irgendeine Software-Komponente (im Gegensatz zu einer Hardware-Einrichtung), die einen allgemeinen Dienst anderen Einrichtung oder Komponenten im Heimnetzwerk bereitstellt.
    Comms Media Manager 740: diese Komponente ist dafür verantwortlich, den darunter liegenden realen Kommunikationsprozess zu verwalten. Er stellt eine API bereit, die es Codemodulen erlaubt, mit den Merkmalen der Kommunikationsmedia (beispielsweise IEEE 1384) zusammenzuarbeiten.
    Registratur 706: dies ist eine Dienstdatenbank. Alle DCMs für reale Einrichtungen und Software-Dienste werden sich selbst in der Registratur 706 registrieren und alle Module (beispielsweise Einrichtungsmodule 720) können die Registratur anfragen, einen Betreuer für eine andere Einrichtung oder Modul zu bekommen.
    Kommunikationsmanager 750: diese Komponente ist eine Niedrigebenen-Abstraktion der Kommunikationsmedia.
    Mitteilungsübermittlung 702: diese Komponente liefert grundsätzliche Informationsdurchleitungsfähigkeit, um es zu erlauben, dass sowohl Einrichtungen (Hardware) und Einrichtungsmodule 720 als auch Dienstmodule 730 miteinander kommunizieren.
    Ereignismanager 703: dieses Modul liefert einen allgemeinen Ereignisdienst. Dies ist ein Ein-bis-Viel-Kommunikationsdienst, der Mitteilung im HAVI-Netzwerk erlaubt.
    Initialisierungsmanager 701: diese Komponente wird als Teil des Einrichtungs-Urladeprozesses (Bootstrap) verwendet.
    Daten-Leitweglenkung 762: die Daten-Leitweglenkungskomponente 702 ist verantwortlich dafür, um Diensteinrichtungsleitwegen zwischen Einrichtungen und Einrichtungsmodulen zu helfen. Sie wägt die "Kosten" zur Übernagung von Daten über einen bestimmten Weg, die Erfordernisse in Bezug auf die Datenformatübernagung, usw. ab. Diese Komponente wird für die Basisarchitektur nicht benötigt.
    AV-Aktionen/Makros 783: diese Komponente ist ein Manager für höhere Ebenen-AV-Aktionen, welche Gruppen individueller Niedrigebenenbefehle sind, d.h., sie liefern einen Makrodienst. Diese Komponente wird für die grundsätzliche Architektur nicht benötigt.
    Hochebenen-UI-Bibliothek 704: diese Komponente liefert einen Satz von Hochebenen-UI-Komponenten, welche durch Einrichtungsmodule 720 verwendet werden, um UIs für ihre entsprechenden Einrichtungen zu bilden. Diese Komponente wird für die Basisarchitektur nicht benötigt.
    Anwendungs-(und Benutzer-)Schnittstelle 705: diese Komponente liefert die Verknüpfung zwischen einer allgemeinen elektronischen Verbraucherplattform (CCEP) APIs der HAVI-konformen Einrichtungen und Anwendungen, die örtlich oder möglicherweise entfernt angeordnet sind. Diese Komponente wird für die Basisarchitektur nicht benötigt.
  • Es sollte gewürdigt werden, dass die obigen Komponenten, wie sie in 7 grafisch dargestellt sind, Abstraktionen von Funktionalität sind. Sie sind ausgebildet, um es zu verdeutlichen, welche Funktionalität in der Architektur für HAVI-konforme Einrichtungen enthalten ist. Um unnötiges Verdecken der Erfindung zu vermeiden, sind die Beziehung zwischen Komponenten 701–763 und den Informationsflüssen zwischen diesen nicht gezeigt.
  • DCM-Konfiguration und Funktion
  • Überblick
  • Bei einer Ausführungsform der vorliegenden Erfindung existiert in HAVI-Netzwerkkonfigurationen, wo ein FAV-Knoten nicht verfügbar ist, ein DCM für jede reale Einrichtung im HAVI-Netzwerk, welche durch diesen FAV-Knoten etwa bekannt ist. Das DCM stellt eine Schnittstelle für die Einrichtung bereit und zeigt diese als ein Objekt in der Architektur. Andere DCMs, Systemdienste oder Anwendungsdienste können die örtliche Registratur anfragen, um die Einrichtungen herauszufinden, die verfügbar sind, und um einen Kennzeichner zu bekommen, um diesen zu erlauben, mit den Einrichtungen über ihr DCM zusammenzuarbeiten.
  • Die Einrichtungssteuerungsmodule sind außerdem dafür verantwortlich, mit der Software-Architektur zusammenzuarbeiten, um die Einrichtungsbenutzerschnittstelle (UI) dem Benutzer zu zeigen. Eingaben von Benutzern werden dann zum DCM weitergeleitet, der die Eingabe dazu verwendet, die reale Einrichtung zu steuern.
  • Wie oben erläutert und unterstützen die DCMs die Kompatibilität der Ebene 1 und der Ebene 2. Ein Ebenen-1-DCM ist ein allgemeines DCM, welches üblicherweise mit dem FAV-Knoten beliefert wird und in der Lage ist, einen grundsätzlichen vorher festgelegten Satz von Merkmalen einer Einrichtungsklasse unter Verwendung eines vorher definierten Informationssatzes zu verwalten. Während der Initialisierung wird das DCM mit dem Einrichtungsmanager (unten) arbeiten, um die aktuellen Merkmale der zu verwaltenden Einrichtung zu entdecken und wird sich selbst konfigurieren, um diese Einrichtung zu steuern. Somit sollte eine allgemeine VCR-Steuerung spezialisiert werden können, um einen Standard-VCR zu steuern, wobei entweder 1394-AV/C-Informationen oder die Steuerung A1 verwendet werden.
  • Im Fall der Ebenen-2-Kompatibilität wird das DCM, welches für diese Einrichtung spezialisiert ist, ein Aufschaltungs-DCM sein, welches von einer externen Quelle, beispielsweise der Einrichtung selbst geladen wurde. Diese Aufschaltungs-DCMs werden im gemeinsamen Sprachformat für DCMs geschrieben. Die Funktion eines Aufschaltungs-DCM unterscheidet sich nicht von allgemeinen DCMs, wobei jedoch die API, die angeboten wird, wahrscheinlich verständlicher sein wird.
  • Wenn sie spezialisiert sind, werden die DCMs nicht nur Steuerungsschnittstellen für die Einrichtung bereitstellen, sondern auch Zugriff zu SDD-Daten in Verbindung mit einer Einrichtung. Sie werden wie Ereignismanager für eine Einrichtung wirken, spezielle Einrichtungsereignisse empfangen und diese in das Ereignissystem (siehe unten) stellen. Sie werden außerdem als UI-Manager für die Einrichtung wirken, mit dem UI-Verwaltungssystem zu sammenarbeiten, um eine Benutzerschnittstelle über eine Anzeigeeinrichtung bereitzustellen. Schließlich wird das DCM wie ein Resourcenmanager für Einrichtungen arbeiten, wobei Anfragen, die für Einrichtungszugriff und Dienst gemacht werden, bereinigt werden
  • Allgemeine DCM-Terminologie
  • In der Terminologie nach der vorliegenden Erfindung, wie sie in den folgenden Beschreibungen verwendet wird, zeigt jedes DCM ein Modul einer Einrichtung im Heimnetzwerk. Die Basisterminologie ist wie folgt:
    • 1) Einrichtung: dieser Begriff bezieht sich auf die gesamte Einrichtung.
    • 2) Hilfseinrichtung: dieser Begriff bezieht sich auf eine von vielen möglichen Komponenten, um eine Einrichtung zu bilden. Einige Technologien besitzen nicht die Fähigkeit, Hilfseinrichtungen zu unterscheiden.
    • 3) Innenverbindung: dieser Begriff bezieht sich auf die logische oder körperliche Verbindung zwischen internen Hilfseinrichtungen.
    • 4) Externe Verbindung: dieser Begriff bezieht sich auf die Verbindung zwischen einem realen Verbinder auf der Außenseite einer Einrichtung und einer Bestimmungseinrichtung außerhalb der Einrichtung. Das gleiche gilt für die Einheit Seriell-Bus und die externen Eingabe- und Ausgabestecker für AV/C.
    • 5) Protokoll: dieser Begriff bezieht sich auf das Steuerungsprotokoll, welches durch die Hilfseinrichtung oder die Einrichtung (beispielsweise AV/C, Steuerungs-A1 usw.) gesprochen wird. Es sollte angemerkt sein, dass eine Einrichtung Hilfseinrichtungen enthalten kann, die verschiedene Protokolle sprechen können.
    • 6) Schnittstelle: dieser Begriff bezieht sich auf die reale Busverbindungsschnittstelle (1394, USB, usw.).
    • 7) Einrichtungsklasse: dieser Begriff ist ein Einwegbegriff, um die Grundfunktionalität einer bestimmten Sammlung von Einrichtungen zu beschreiben. Beispielsweise kann die Klasse von DVCR-Einrichtungen Daten auf einem Bandträger aufzeichnen. Ebenso kann es viele Einrichtungen geben, die ein Audioeingangssignal aufnehmen können, einige Arten spezieller Effekte durchführen können und den modifizierten Audiostrom ausgeben können. Diese würden alle unter die Klasse eines Audioprozessors oder eines ähnlichen Geräts fallen. Die Nützlichkeit dieses Konzepts wird später in diesem Dokument deutlicher.
    • 8) Einrichtungsmodell: dieser Begriff bezieht sich auf die Ansammlung von Hilfseinrichtungen und Verbindungen, die entweder eine Standard- oder Kundeneinrichtungsdefinition bilden. Individuelle Hilfseinrichtungen, auf die innerhalb körperlich getrennter Ein richtung zugegriffen werden kann, können kombiniert sein, um logische oder virtuelle Einrichtungen zu bilden, wobei das Einrichtungsmodell verwendet wird.
    • 9) Standardeinrichtung: dieser Begriff bezieht sich auf Standardmodelldefinitionen (beispielsweise besteht eine DVCR-Einrichtung aus zumindest einer Tuner-Hilfseinrichtung und einer VCR-Hilfseinrichtung (Transporteinrichtung) mit Steckern zwischen diesen).
    • 10) Spezialeinrichtung: dieser Begriff bezieht sich auf ein verkäufer-spezifisches Einrichtungsmodell, welches aus entweder Standardhilfseinrichtungen oder aus einer Kombination von Standard- und verkäufer-spezifischen Hilfseinrichtungen besteht. Beispielsweise kann ein Dualdeck-DVCR zwei VCR-Hilfseinheiten haben, die Standardgeräte sind, jedoch in einer Nichtstandard-Konfiguration.
    • 11) Gesameinrichtungen: dieser Begriff bezieht sich auf logische Entitäten, die von einer Vielzahl von Komponenten kombiniert werden können. Körperliche Einrichtungen und Hilfseinrichtungen sind individuell zugreifbare Teile von Hardware. Wenn Einrichtungen zugreifbare Hilfseinrichtungen haben, wird dieses Modell erweitert, um Gesamteinrichtungen zu unterstützen. Beispiele von Gesamteinrichtungen umfassen Hilfseinrichtungen von separaten körperlichen Einrichtungen oder innerhalb einer einzelnen Einrichtung, und Software-Module, beispielsweise Software-Codecs, die Dienste oder Fähigkeiten ähnlich den Einrichtungen und Hilfseinrichtungen bereitstellen. Diese Module können alle auf dem gleichen Knotenpunkt im AV-Netzwerk bleiben oder unter vielen Knoten verteilt sein.
  • Einrichtungsklassifizierung
  • Klassifizierungseinrichtungen auf der Basis der Art von Aktionen, die sie durchführen, oder der Art des Trägers, mit der sie umgehen, ist eine Art und Weise, uns zu erlauben, eine allgemeine Steuerungs-API zu bilden, die für Einrichtungen arbeiten wird, die in der Zukunft gebildet werden. Die Absicht ist, einen hohen Prozentsatz an Grundfunktionalität zuzulassen, um immer unabhängig von der Art der Einrichtung oder des Herstellers der Einrichtung zugreifbar zu sein.
  • Jede hersteller-spezifische oder einrichtungs-spezifische Funktionalität, die ebenfalls steuerbar ist, jedoch außerhalb der allgemeinen Steuerungs-API fällt, wird lediglich über die SDD-Information und andere Verfahren zugreifbar sein, um ein DCM zu erweitern.
  • In den meisten allgemeinen Kategorien kann die Klassifikation von Einrichtungen oder Hilfseinrichtungen durch deren Hauptfunktionalität beschrieben werden. Das AV/C-Steuerungsprotokoll des 1394-Standards verwendet ein angenehmes Verfahren zum Klassifi zieren von Einrichtungen, die wir unten angepasst haben. Folgendes ist der erste Satz an Faktoren, die verwendet werden, eine Einrichtung oder Hilfseinrichtung zu klassifizieren:
    • 1) ob eine bestimmte Einrichtung ein Transportsystem hat;
    • 2) ob die Nützlichkeit dieser Hilfseinrichtung, die am häufigsten durch die Tatsache definiert wird, dass ein Signal hier endet (unabhängig von der Tatsache, dass sie ohne Änderungen verbreitet werden kann);
    • 3) ob eine bestimmte Hilfseinrichtung eine Signalquelle ist (beispielsweise hat diese einen Signalausgang);
    • 4) ob eine bestimmte Einrichtung das Eingangssignal annimmt, eine Art an Verarbeitung durchführt und dann die modifizierten Daten ausgibt;
    • 5) ob es keinen Signaleingang oder -ausgang irgendwelcher Art gibt (beispielsweise, ist die Einrichtung eine nützliche Einrichtung irgendeiner Art, beispielsweise ein Mechanismus zum Positionieren einer Satellitenantenne).
  • Gemäß der vorliegenden Erfindung können wir bei einer zweiten Ebene an Klassifikation Einrichtungen studieren, die einen Transportmechanismus enthalten. In diesem Fall würde eine allgemeine Frage sein "beschäftigt sich diese Einrichtung mit entnehmbaren Trägern ?". Wenn sie dies tut, wird dann ein Basissatz an Steuerungen angewandt, beispielsweise Wiedergabe (), Stopp () und sogar Suche (). Einrichtungen mit Trägern können nach ihrer Fähigkeit, eine Aufzeichnung durchzuführen, abgefragt werden, die Organisation von Information auf dem Träger bestimmen (wird dieser Spur nachgeführt?, fortlaufend wie ein Band ?, wie wird gemessen – SMPTE-Zeitcodes, Zeitversatz von einer bestimmten Position, usw.).
  • Bei der vorliegenden Ausführungsform kann ein Signalverarbeitungsdienst durch die Art von einem Signal (Signalen), die dieser annimmt, und die Art, wie dieses als Ergebnis erzeugt werden kann, vorgeschrieben werden. Dies erfordert die Einrichtung von allgemeinen Definitionen zum Vorschreiben von Signalarten und Methoden zum Zugreifen auf Dienste, so dass ein Kunde erkennen kann, zu beschreiben, nach welcher Art von Dienst sucht und wie er auf diesen Dienst zugreift.
  • Jede Einrichtung, die eine Art von Daten akzeptiert und die Fähigkeit hat, diese Daten auf einer verschiedenen Art an Verbindung zu übertragen (beispielsweise nimmt sie digitales Video als Eingangssignal und hat analoge Standardvideo-RCA-Stecker, die diese Daten zurück aussenden können) können als eine Datenumsetzerklasse arbeiten. Das DCM für diese Einrichtungen wird sich selbst als Datenumsetzer in der Systemregistratur registrieren, so dass Kunden dieses finden können und dieses wenn notwendig verwenden können.
  • Einrichtungszugriff und Steuerung
  • Gemäß der vorliegenden Erfindung wird, wenn eine Basiseinrichtungsklassifikation einmal durchgeführt wurde, dann das allgemeine DCM, welches für diese Einrichtung spezialisiert ist, eine API bereitstellen, die veranlasst, dass Steuerungsmitteilungen zu dieser Einrichtung geliefert werden. Der Basissatz an Steuerungsinformationen, der zu einer bestimmten Klasse einer Einrichtung gesendet oder davon empfangen (im Fall von Ereignissen) werden kann, ist standardisiert und im Anhang ausführlich dargestellt (nicht in dieser Version des Dokuments verfügbar). Bei der vorliegenden Ausführungsform zeigen diese Informationen eine Basis-API, welche durch das DCM dargestellt wird.
  • Einrichtungsverwaltung
  • Gemäß der vorliegenden Erfindung liefert die DCM API ebenfalls einen Satz von Diensten auf höhere Ebene, die eine verfeinerte Verwaltung der Einrichtung erlauben. Beispiele davon umfassen Einrichtungsreservierung und Ereignisverwaltung. Im Fall einer Einrichtungsreservierung ist es wahrscheinlich, dass eine Anforderung nach einer Einrichtung aufgrund von existierenden Anforderungen auf die Einrichtung verweigert werden können, alternativ, dass die Einrichtungsanforderung für eine zukünftige Reservierung nach einer Zeit auf Basis von Makro sein kann. In diesen Fällen liefert das DCM eine Schnittstelle, um eine Anwendung oder einen Dienst auf wartende Anforderungen mit dem DCM zuzulassen, d.h., eine Einrichtung zu reservieren oder um eine Information zu empfangen, wenn eine Einrichtung verfügbar wird.
  • Verbindungsverwaltung
  • Die DCMs nach der vorliegenden Erfindung liefern außerdem eine Hochebenen-API, um anderen Objekten zu erlauben, den Zustand von Verbindungen zwischen Einrichtungen abzufragen und um diese Verbindungen zu handhaben. Diese API wird hauptsächlich durch den Leitweg-Manager verwendet, ist jedoch für jedes Objekt im System verfügbar. Die Verbindungsverwaltung erlaubt, dass Verbindungen eingerichtet werden können, sowohl intern zwischen Hilfseinrichtungen als auch extern zwischen Einrichtungen. Der Verbindungsstatus kann abgefragt werden und die Verbindungsleistungen (Signalformate) können ebenfalls abgefragt werden.
  • SDD-Verwaltung
  • Die DCMs nach der vorliegenden Erfindung liefern außerdem eine gewöhnliche Schnittstelle für die SDD-Verwaltung. Dies erlaubt, dass nach den SDD-Daten in der Einrichtung gefragt werden kann und diese verwendet werden können. Die API ist in zwei Teile unterteilt. Teil 1 liefert APIs, um bekannte Information von den SDD-Daten zu erlangen, die in dem Einrichtungsimage enthalten sind, dessen Namen und dessen URL (wenn verfügbar) einer Stelle für eine Aufschaltungs-DCM oder andere Icons, die bei der Darstellung der UI der Einrichtung verwendet werden. Teil 2 der SDD API ist dazu bestimmt, ausführlicheren Zugriff zu funktionellen Merkmalen der Einrichtung zu liefern.
  • Datendarstellung und Benutzerschnittstelle (UI)
  • Gemäß der vorliegenden Erfindung ist das DCM auch für die UI-Merkmale der Einrichtung verantwortlich. Im Fall der Ebenen-1-Kompatibilität wird eine allgemeine UI dazu verwendet, eine Schnittstelle mit Benutzern zu bilden. Dies kann durch Basis-SDD-Daten gesteigert werden, die erlauben, dass diese Merkmale, wie UI-Icons, spezifiziert werden und auf diese durch das allgemeine DCM zugegriffen werden kann. Um unnötiges Verdecken der vorliegenden Erfindung zu vermeiden, werden Details, wie das DCM mit dem UI-Verwaltungssystem zusammenarbeitet, um eine spezielle Einrichtungs-UI zu zeigen, nicht ausführlich erläutert. Bei der vorliegenden Ausführungsform ist jedoch das Basismodell so, dass der interne Managementcode innerhalb des DCM mit dem UI-Verwaltungssystem arbeitet, um eine UI für die Einrichtung zu zeigen. Die Benutzereingabe wird dann durch das UI-Verwaltungssystem zum DCM weitergeleitet, das diese dann in spezifische Einrichtungsbefehle umsetzt. Diese Befehle werden unter Verwendung des Basisnachrichtensystems zur Einrichtung geliefert. Wenn Antworten empfangen werden, werden diese dann über das DCM bis zur UI geleitet. Zusätzlich werden jegliche Statusänderungen der Einrichtung, beispielsweise Einschalten/Ausschalten ebenfalls über das Ereignissystem zum DCM geleitet, welches diese dazu verwendet, die UI zu aktualisieren.
  • Dienstmodule
  • Dienstmodule (beispielsweise Dienstmodule 730) sind im Konzept ähnlich den Einrichtungssteuerungsmodulen. Sie liefern eine Schnittstelle zu einem Dienst, der üblicherweise lediglich durch die Software bereitgestellt wird. Bei der vorliegenden Ausführungsform bestehen die Dienstmodule aus zwei Arten, nämlich den Systemdiensten und den Anwendungsdiensten. Ein Systemdienst ist ein äußerst bekannter Dienst, der als Teil der HAVI-Software-Architektur bereitgestellt wird. Beispiele dieser Art von Diensten sind Datenformat übersetzer, Protokollumsetzer oder Grafikdienste. Diese Dienste haben bekannte APIs, die als Teil der HAVI-Architektur definiert sind. Anwendungsdienste sind Objekte, die für Dienstobjekte gebildet sind und durch andere gebildet sind. Diese Objekte liefern eine definierte API, wobei jedoch diese API nicht öffentlich ist. Bei der vorliegenden Ausführungsform muss jede Anwendung oder anderes Objekt, welches wünscht, ein Anwendungsobjekt zu nutzen, seine API und Ruf-Bedeutungslehren kennen. Obwohl nicht erforderlich werden allgemein Systemdienste die Lebensdauer des Systems lang existieren. Anwendungsdienste werden die Lebensdauer einer Anwendung lang existieren und können eine relativ kurze Lebensdauer haben.
  • Systemdienste
  • Gemäß der vorliegenden Erfindung werden viele der Dienste, die durch die AV-Architektur bereitgestellt werden, als Dienstmodule bereitgestellt, wo deren Dienste in der Systemregistratur registriert werden und auf die unter Verwendung der Mitteilungsübermittlung zugegriffen werden kann. Beispiele solcher Dienste sind die UI-Dienstmodule, die einen Mechanismus bereitstellen, um es Einrichtungen zu erlauben, eine UI, Datenformatdienste, welche AV-Daten zwischen unterschiedlichen Format umsetzen, dem Benutzer zu zeigen.
  • Der DCM-Manager
  • Überblick
  • Gemäß der vorliegenden Erfindung ist der DCM-Manager für alle Merkmale zum Handhaben der Sammlung von DCMs verantwortlich, die auf einem FAV-Knoten vorhanden sind. Dies umfasst die Aufgaben zum Entdecken, zum Spezialisieren und zum Anordnen aller möglichen Einrichtungssteuerungs-Modulkandidaten, die für ein bestimmtes System verfügbar sind. Die Einrichtungsresourcenverwaltung wird allgemein durch individuelle DCMs durchgeführt, jedoch, wo mehrere Einrichtungen oder Dienste miteinander zusammenarbeiten und wo einige der DCMs auf verschiedenen FAV-Knoten angeordnet sind, wird ein Management mit höherer Ebene benötigt werden. Daher kommuniziert der DCM-Manager mit anderen DCM-Managern auf entfernten Knoten, um auf eine netzwerkweise Einrichtung und eine Hilfseinrichtungs-Resourcenzuordnung und Verwaltung zu entscheiden. Deren Verantwortlichkeiten werden unten erläutert.
  • Entdeckung und Aufzählung von realen Einrichtungen
  • Gemäß der vorliegenden Erfindung arbeitet der DCM-Manager mit den darunterliegenden OS-Diensten, um eine grobe Liste von verfügbaren Einrichtungen zu erzielen. Es sei angemerkt, dass in Abhängigkeit von der darunterliegenden Bustechnologie diese DCMs dynamisch sein können. Bei der vorliegenden Ausführungsform, wenn beispielsweise reale Einrichtungen auf einem 1394-Bus kommen und gehen, kommen und gehen die DCMs mit diesen. In der gleichen Weise sind der Dienst und die Gesamteinrichtungs-DCMs ebenfalls dynamisch, wobei diese als Antwort auf Ereignisse im FAV-Knoten gebildet und verteilt werden.
  • Diese Aufgabe erfordert die Zusammenarbeit sowohl mit Elementen der AV-Architektur als auch mit Elementen der FAV-Host-OS, Knoten-Hardware und Kommunikations-Hardware. Aufgrund dieser Tatsache wird der exakte Prozess, der zur Einrichtungsentdeckung erforderlich ist, von der Systemumgebung abhängen. Der allgemeine Versuch zum Abfragen einer Einrichtung und irgendwelcher SDD-Daten, die sie enthält, um deren Charakteristik zu entdecken, wie im DCM-Abschnitt erläutert wurde, ist jedoch allgemein. Bei der vorliegenden Ausführungsform erfordert dies, dass der DCM-Manager einem Satz von Regeln in einer vorgegebenen Sequenz folgt, jedes Mal, wenn das System initialisiert wird, oder jedes Mal, wenn sich das System ändern mag (beispielsweise, wenn der Bus zurückgesetzt wird).
  • Bildung allgemeiner DCMs
  • Gemäß der vorliegenden Erfindung arbeitet für jeden Knoten der DCM-Manager genug, um zu bestimmen, dass dieser ein DCM bilden sollte. Diese Arbeit wird für alle medien-bezogenen Einrichtungen ausgeführt, welche durch den FAV-Knoten verwaltet werden. Bei der vorliegenden Ausführungsform können Einrichtungen unter einer unterschiedlichen Verwaltungstechnologie, beispielsweise Einrichtungen auf USB-Basis innerhalb der Architektur als DCMs auf Knoten dargestellt werden, die die USB-Kommunikation unterstützen, oder als spezielle DCMs, die als Stellvertreter für ein fernes Verwaltungssystem wirken. Es sollte jedoch angemerkt sein, dass einige Einrichtungen auf USB-Basis, beispielsweise Festplatten in Wirklichkeit so ausgebildet sind, um lediglich als Aufzeichnungs- oder Wiedergabeeinrichtungen für wahlfrei zugreifbare Medien zu erscheinen. In diesen Fällen werden sie wie andere "reale" Medieneinrichtung behandelt. Bei der vorliegenden Ausführungsform wird für jede medien-bezogene Entität der DCM-Manager ein allgemeine oder ein Ebenen-1DCM erzeugen. Jedes DCM wird später die Verantwortung haben, sich selbst einrichtungsspezifischer zu machen, wenn dies möglich ist. Dies wird unten beschrieben.
  • Integration von Ebenen-2-DCMs
  • In Fällen, wo das Aufschaltungs-DCM (beispielsweise Ebenen 2-DCM) verfügbar ist und auf dieses zugegriffen werden kann, ist der DCM-Manager dafür verantwortlich, zu versuchen, dieses DCM zu holen und dieses in den FAV-Knoten zu installieren. Bei der vorliegenden Ausführungsform ist, wie das Aufschaltungs-DCM und das allgemeine DCM miteinander arbeiten, vom DCM-Entwickler abhängig. In einigen Fällen wird beispielsweise dieses vollständig das Vorgabe-DCM ersetzen, in anderen wird dies mit dem Vorgabe-DCM arbeiten, um dessen Fähigkeiten zu steigern.
  • Gemäß der vorliegenden Erfindung können durch Hersteller gelieferte Ebenen-2-DCMs von einer Vielzahl von Quellen herstammen. Die Einrichtungen können diese innerhalb ihres ROM oder einem anderen Speichermechanismus, beispielsweise dem Datenkopf einer Platte oder Band tragen. Sie können von einem web oder ftp-site heruntergeladen werden, wenn auf diese Leistungen durch den FAV-Knoten zugegriffen werden kann, oder sie könnten in der üblichen Computer-Industrieweise über eine Installation von einer Platte oder einem anderen Speicherträger geliefert werden. Das Zulassen dieser hersteller-gelieferten Aufschaltungs-DCM-Fähigkeit erfordert ein Modell, um DCMs zu bilden und zu installieren. Bei der vorliegenden Ausführungsform wird, wenn installiert, das Ebenen-2-DCM die gleiche Basisschnittstelle dem Kunden wie das Ebenen-1-DCM bereitstellen, während entweder zusätzliche Schnittstellen oder unmittelbar darunterliegende Funktionalitätsmodifikationen bereitgestellt werden.
  • DCM-Anordnung
  • Gemäß der vorliegenden Erfindung wird der DCM-Manager verantwortlich dafür sein, um DCMs in geeigneten Zeitpunkten anzuordnen, und Kunden zu informieren, dass DCMs entfernt wurden. Bei der vorliegenden Ausführungsform sind Regeln, wenn die DCM-Anordnung vorkommt, und die Verteilung von Verantwortlichkeit zum Aufbereiten zwischen dem DCM- und dem DCM-Manager auf die speziellen Erfordernisse eines bestimmten HAVI-Netzwerks maßgeschneidert.
  • Koordinieren zwischen mehreren DCMs
  • Einige komplexe Dienste unter mehreren DCMs beispielsweise Befehlswarteschlangenbildung von komplexen Operationen usw. erfordern, dass der DCM-Manager mehrere DCMs koordiniert, um diese Operationen durchzuführen. Dies wird beeinflusst durch das "Befehlsmodell", welches für Kunden vorgesehen ist. Wenn beispielsweise wir eine obere Ebene API definieren, die es Kunden erlaubt, Aktionen zu spezifizieren, die auf HH:MM:SS:FF-Zeitcodes basieren, müssen wir zwischen diesem Zeitmodell oder irgendeiner Hardware oder darunterliegenden Stützmodulen, die damit sich beschäftigen, eine Übertragung durchführen. Es sollte angemerkt werden, dass komplexe Zeitbasisoperationen, die durch mechanische Verzögerungen usw. beeinträchtigt werden, geklärt werden müssen. Diese Art an Kombination erfordert eine Vorstellung von realem Zeitverhalten im Netzwerk und ist von physikalischer oder Software-Infrastruktur abhängig, die einen gewissen Grad an Garantie liefern.
  • Mit Hilfe von 8 ist nun ein logisches mehrschichtiges Diagramm 800 von einer HAVI-Architektur gemäß der vorliegenden Erfindung gezeigt. Die im Diagramm 800 gezeigten Komponenten sind ähnlich denjenigen, die im Diagramm 700 gezeigt sind, wobei jedoch das Diagramm 800 so organisiert ist, dass Hochebenenverarbeitung auf dem Kopf (beispielsweise Anwendungen 801) in Bezug auf Niedrigebenen-Verarbeitungen auf dem Boden (beispielsweise 1394-Modul 830) organisiert ist. Das Diagramm 800 zeigt außerdem andere Dienste 810, Transportaktionsmodule 815 und andere Module 840.
  • Wie oben beschrieben kann die Gesamt-HAVI-Architektur als Kommunikationskomponenten und Dienstkomponenten angesehen werden. Anwendungen 801 nutzen an der höchsten Ebene in der Architektur die Dienste und die Kommunikationskomponenten (beispielsweise DCMs 720, Dienstmodule 730 usw.). Wiederum wird eine Anzahl von Dienstkomponenten (beispielsweise Dienstmodule 730, DCMs 720, usw.) die darunterliegenden Kommunikationskomponenten verwenden (beispielsweise Mitteliungsübermittlung 702, Übertragungsadaptionsmodule 815, usw.). Beispielsweise fragt eine der Anwendungen 801 über die Registratur 706 den Betreuer nach einem DVTR (digitaler Videobandrekorder)-Einrichtung und sendet dann einen Wiedergabebefehl zur Einrichtung. Wie oben beschrieben kommunizieren Komponenten in der HAVI-Architektur, wobei das darunterliegende Mitteilungsübermittlungssystem verwendet wird, d.h., die Module nutzen den Miteilungsdurchlauf.
  • 9 zeigt ein Diagramm 900 einer örtlichen und fernen Mitteilungsübermittlung in der HAVI-Architektur einer Ausführungsform. Die gezeigte Mitteilungsübermittlungs-Komponente 702 handhabt sowohl die örtliche Mittelungsübermittlung als auch die ferne Mitteilungsübermittlung. Folglich ist die Mitteilungsübermittlungskomponente 702 an der Basis des Diagramms 900 gezeigt. Örtliche Mitteilungen sind als Pfeile 902a, 903a, 904a zu verschiedenen Anwendungen 901–904 dargestellt. Eine ferne Mitteilung ist als Pfeil 901 dargestellt. Aus Einfachheitsgründen ist im Diagramm 900 und in der folgenden Erläuterung die örtliche Kommunikation über das Mitteilungsübermittlungssystem nicht gezeigt, wobei bevorzugt die lokale Mitteilungsübermittlung (beispielsweise Pfeile 901a–904a) so gezeigt sind, als ob sie auf unmittelbaren Funktionsrufen zwischen Komponenten basieren.
  • 10 zeigt ein Diagramm 1000 einer Mitteilung, die über 1394 in der HAVI-Architektur einer Ausführungsform geliefert wird. Im Diagramm 1000 ist die Nachricht 1 (beispielsweise Pfeil 820a) eine Anfrage von einer von Anwendungen 801 zur Registratur 706 (über die Anforderungs-API) nach dem Betreuer einer DVTR-Einrichtung. Die Registratur 706 liefert einen Betreuer für das DVTR DCM in der Information 2 zurück (beispielsweise Pfeil 820b). Diese Betreuung ist die Informationsadresse, welche für das Mitteilungsübermittlungssystem verwendet wird.
  • Gemäß der vorliegenden Erfindung nutzt dann die Anwendung die Betreuung, das DCM für den DVTR mit der Information 3 (beispielsweise 820c) anzurufen. Das DCM setzt die Anwendungsanrufung des Wiedergaberufs in einen internen Befehl um, der zur Informationskomponente geliefert wird, nämlich die Information 4 (beispielsweise 820d). Dieser interne Befehl ist Teil des definierten Befehlssatzes in der Ebene 1 (d.h., dies ist ein HAVI-Befehl). Die Mitteilungsübermittlungskomponente 702 verwendet dann intern die Betreuerinformation, um zu bestimmen, auf welchem Bus diese Einrichtung ist. Wenn sie ermittelt, dass diese auf dem IEEE 1394-Bus ist, verwendet sie das IEEE 1394-Transportadaptionsmodul (TAM) 830, um die Information in ein 1394-Paket, d.h., die Information 5 (beispielsweise Pfeil 820e) umzusetzen, welche im Datenbereich eines FCP-Pakets angeordnet wird. Das TAM ruft dann die 1394-Einrichtungsansteuerung, d.h., die Information 6 (beispielsweise Pfeil 820f auf, um die Information über 1394 zu senden.
  • Auf der Empfangsseite (nicht gezeigt) wird die Information zur 1394-Einrichtungsansteuerung geliefert und dann über ein 1394-TAM zur Mitteilungsübermittlungskomponente geleitet. Die Mitteilungsübermittlungskomponente wird ein HAVI-Informationspaket empfangen, welches sie dann zu dem empfangenen Code unmittelbar über eine Informationswarteschlange oder eine Rückruffunktion liefert. Bei der vorliegenden Ausführungsform wird, wenn die Empfangseinrichtung eine IAV-Einrichtung ist, diese lediglich die Mitteilungskomponente der CCEP-Architektur und die Registratur haben. Eine andere Funktionalität, die diese haben wird, wird einrichtungs-spezifisch sein.
  • Es sollte angemerkt sein, dass das vorherige Beispiel in 10 eine Unterscheidung in der HAVI-Architektur zwischen dem Mitteilungsübermittlungssystem und dem Befehlssatz, der dazu verwendet wird, um Einrichtungen zu steuern, zeigt. Gemäß der vorliegenden Erfindung ist das Mitteilungsübermittlungssystem ein allgemeiner Mitteilungsüber mittlungsmechanismus, der ein Mitteilungspaket mit einem Datenabschnitt bereitstellt, dessen Inhalt gegenüber dem Mitteilungsübermittlungssystem vollständig undurchlässig ist. Beispielsweise kann das Mitteilungsübermittlungssystem private Anwendung zu Anwendungsbefehlen, zu AVC-DTS-Befehlen, zu CAL-Befehlen oder irgendwelchem anderen Befehl überbringen. Das DCM ist die Entität, welche für die Kommunikation mit fernen Einrichtungen verantwortlich ist, es verwendet das Mitteilungsübermittlungssystem, um Befehle speziell für diese Einrichtung auszuführen. Für eine Ebenen-1-HAVI-Einrichtung, die damit konform ist, wird der Befehlssatz, der durch das Mitteilungsübermittlungssystem ausgeführt wird, als Teil der CCEP-Architektur definiert. Mitteilungen, welche durch das Mitteilungssystem zwischen DCMs ausgeführt werden und Einrichtungen, die sich stören, enthalten diese definierten Befehle. Für Ebenen-2-Einrichtungen ist der erweiterte Befehlssatz undefiniert, wobei diese lediglich AV/C-CTS-, CAL- oder andere Befehle sein können.
  • Mit Hilfe von 11 ist nun ein Diagramm einer Anwendung, die eine andere Anwendung in einer Ausführungsform der HAVI-Architektur anruft, gezeigt. Das Diagramm zeigt eine Anwendung 801a, welche auf einer Einrichtung 1101 läuft, die eine Information 1105 zu einer Anwendung 801b, die auf einer separaten Einrichtung 1102 läuft, über Informationssysteme 702a und 702b weiterleitet. Wie oben beschrieben kann jede Anwendung, welche innerhalb des HAVI-Netzwerks läuft, auf eine andere Anwendung zugreifen, wenn diese einen Informationsbetreuer für diese Anwendung hat. Um einen Informationsbetreuer zu erwerben, wird der gleiche Prozess wie für die ferne IAV-Einrichtung verwendet (beispielsweise der, der in 10 oben beschrieben wurde). Wenn ein Informationsbetreuer verfügbar ist, kann die Quellenanwendung 801a eine Information 1105 zur Zielanwendung 801b liefern. Wie oben beschrieben ist das Format dieser Informationen völlig abhängig von der Anwendung und betrifft nicht die CCEP-Architektur. Dieses liefert lediglich einen Kommunikationsmechanismus, um Information zwischen Anwendungen zu senden und zu empfangen.
  • Es sollte gewürdigt werden, dass bei dem obigen Beispiel angenommen ist, dass die Anwendungen 801a und 801b auf unterschiedlichen AV-Einrichtungen 1101 und 1102 sind. Wie jedoch vorher erläutert, ist es auch möglich, dass diese Anwendungen 801a und 801b auf der gleichen AV-Einrichtung bleiben und so das Mitteilungsübermittlungssystem lieber einen reinen lokalen Kommunikationsruf als einen Ruf, welcher 1394 verwendet, um die Information zu übertragen, ausführen wird.
  • Anrufen eines Software-Dienstes
  • Ein Software-Dienst ist ein Spezialfall eines allgemeinen Anwendungsfalls von oben. Gemäß der vorliegenden Erfindung ist ein Software-Dienst einfach eine Anwendung, die Teil der Systeminfrastruktur ist. In diesem Fall, wenn ein Modul wünscht, einen Systemdienst anzurufen, beispielsweise die UI-Komponente, nutzt er die Informationskomponente, um dieses auszuführen. Wenn die UI-Komponente örtlich ist, ist der Ruf vollständig innerhalb einer AV-Einrichtung enthalten. Wenn jedoch die UI-Komponente fern ist, wird der Ruf über das 1394-Netzwerk zur fernen AV-Einrichtung geleitet, wo das Informationssystem den Ruf an den UI-Systemdienst abschicken wird.
  • Hinzufügen einer neuen Einrichtung zu einem HAVI-Netzwerk
  • Beim Hinzufügen neuer Einrichtungen zu einem HAVI-Netzwerk gibt es drei allgemeine Situationen: Handhabung einer Stammeinrichtung unter Verwendung eines Stammprotokolls, welches über kein 1394-Netzwerk ausgeführt wird; Handhabung einer Basiseinrichtung unter Verwendung keines HAVI-Protokolls über ein 1394-Netzwerk; und Handhabung einer neuen IAV-Einrichtung, die HAVI-konform ist.
  • Im Fall eines Hinzufügens einer Stammeinrichtung kann bei der vorliegenden Ausführungsform eine Stammeinrichtung lediglich unmittelbar durch einen FAV-Knoten gesteuert werden. Wie oben beschrieben muss für jede Stammeinrichtung ein Stamm-DCM gebildet werden. Es sei ein FAV betrachtet, welches einen 1394-Anschluss und einen Ethernet-Anschluss hat. Das CMM-Modul wird so konfiguriert sein, um sowohl 1384 als auch Ethernet zu verwalten. Wenn die Stammeinrichtung dem FAV bekannt wird, wird diese zunächst im CMM-Modul bekannt werden. Es sei angemerkt, dass der Mechanismus, der verwendet wird, um dies zu erreichen, nicht innerhalb des Rahmens der CCEP-Architektur ist. Dieser ist kommunikationsmedien-spezifisch. Wenn das CMM eine neue Einrichtung erkennt, wird dieses fortfahren, gleich, welcher medien-spezifischer Mechanismus verwendet wird, um die Art der Einrichtung zu bestimmen. Dies ist wiederum nicht Teil der CCEP-Architektur. Eventuell wird diese das DCM auffordern, ein Stamm-DCM für diese Einrichtung zu spezialisieren. Es sei angenommen, dass der FAV-Knoten mit diesem DCM vorher konfiguriert wurde.
  • Bei der vorliegenden Ausführungsform registriert sich, wenn das DCM einmal erzeugt wurde, diese sich selbst in der gleichen Weise wie irgendein genormtes DCM. Eines der wesentlichen Unterschiede zwischen diesem DCM und anderen DCMs besteht darin, dass das Kommunikationsmodell und der Befehlssatz, der dazu verwendet wird, um die Stammeinrichtung zu steuern, der CCEP-Architektur völlig ungekannt sind. Beispielsweise ist es möglich, dass die Einrichtung eine IP-Einrichtung ist, die einen Druckerdienst aufweist. In diesem Fall wird das DCM einen Satz an Befehlen, beispielsweise Drucken, Status usw. liefern. Wenn eine Anwendung die DCM API mit einer Druckaufforderung ruft, wird der Druckbefehl durch das DCM über einen IP-Stapel zur Druckereinrichtung geliefert. Die aktuellen Details, wie dies geschieht, sind anwendungs-spezifisch.
  • Gemäß der vorliegenden Erfindung gibt eine Möglichkeit, dass das Stamm-DCM eine völlige Durchführung des IP-Stapels innerhalb des DCM hat und weiß, wie eine Anbindung zur Ethernet-Einrichtungsansteuerung herzustellen ist. Eine weitere Möglichkeit besteht darin, dass die FAV-Einrichtung einen IP-Stapel und eine API mit höherer Ebene beispielsweise als Sockelbereich bereitstellt. Dies sind FAV-Durchführungsdetails und nicht Teil der CCEP-Architektur. Es sollte jedoch angemerkt sein, dass das Stamm-DCM wie ein "Stellvertreter"-DCM arbeitet. Wenn dies einmal in der Registratur registriert ist, ist es für alle anderen Module im Heimnetzwerk sichtbar. Sie alle können ihre API aufrufen und diese führt die notwendige Umsetzung in die private Befehlssprache des Ethernet-IP-Druckers durch.
  • Wenn eine Basis-AV-Einrichtung hinzugefügt wird, erkennt bei der vorliegenden Ausführungsform, wenn das CMM über die neue Einrichtung informiert ist, dies, dass dies nicht ein CCEP-Knoten ist, sondern entdeckt außerdem, dass ein DCM für diese Einrichtung verfügbar ist. In diesem Fall ist das CMM dafür verantwortlich, einen Mechanismus durchzuführen, der es dieser erlaubt, das DCM nach oben zu laden und das DM zu fragen, um dieses DCM zu bilden. Wenn jedoch das DCM einmal spezialisiert ist, verwendet dies reinen privaten Kommunikationsmechanismus, um auf die Einrichtung zuzugreifen und diese zu steuern. Wie oben beschrieben ist bei der vorliegenden Ausführungsform eine Basis-AV-Einrichtung eine Einrichtung, die 1394 verwendet und das Aufschaltungs-DCM implementiert, jedoch nicht irgendeine CCEP-Architektur durchführt und nicht die Ebenen-1-HAVI-Befehle ausführt. Ein Beispiel könnte ein Beispiel sein, welches ein Aufschaltungs-DCM enthält, jedoch nicht die CCEP-Kommunikations-Infrastruktur unterstützt.
  • Wenn eine IAV-Einrichtung hinzugefügt wird, sollte es gewürdigt werden, dass in den vorherigen Beispielen die Anwendung die Registratur fragte, einen Informationsbetreuer für die Einrichtung, mit der sie zu kommunizieren wünscht, zu bekommen. Es sei angemerkt, dass für eine FAV-Einrichtung der Betreuer, der zurückkehrt, immer verwendet wird, auf das DCM zuzugreifen. Es ist nicht möglich, Informationen unmittelbar zur Einrichtung zu liefern. Um zu verstehen, wie eine Einrichtung, die zum Netzwerk hinzugefügt ist, über die Registratur verfügbar wird, wird dann das folgende Beispiel verwendet.
  • Beispielsweise sei angenommen, dass eine neue Einrichtung (beispielsweise ein Camcorder) in das HAVI-Netzwerk (beispielsweise auf Basis von 1394) gesteckt wird. Dies bewirkt einen Bus-Reset. Der Bus-Reset wird durch den Kommunikations-Media-Manager (CMM) auf der IRD gehandhabt. Der CMM ist dafür verantwortlich, die SDD-Daten der Camcorder-Einrichtung abzufragen, um dessen Fähigkeiten zu entdecken. Wenn angenommen wird, dass die Einrichtung eine Ebenen-1-Einrichtung ist, d.h., dass diese kein nach oben ladbares DCM hat, informiert das CMM diesen Einrichtungsmanager, dass eine neue Einrichtung installiert wurde. Der Einrichtungsmanager bildet ein neues DCM für diese Art von Einrichtung und registriert das DCM mit der Registratur. Das DCM, wenn dieses initialisiert, ist frei, um die Einrichtung unmittelbar zu fragen, um mehr Information über sich selbst zu finden und wenn notwendig sich selbst zu spezialisieren, beispielsweise auf UI-Information zugreifen kann, wenn diese in der Einrichtung existiert. Wenn das DCM einmal in der Registratur registriert ist, kann dann irgendein ein anderes Modul die Registratur abfragen, um einen Betreuer für die Einrichtung zu bekommen und mit dem DCM kommunizieren, um auf die Einrichtung zuzugreifen und diese zu steuern und die UI dem Benutzer zu zeigen.
  • Beispielsweise zeigen 12A und 12B eine beispielhafte UI-Anzeige (beispielsweise auf einem Fernsehbildschirm) für eine derartige Einrichtung (beispielsweise den Camcorder). 12A zeigt eine Textmenüanzeige 1200, wo dem Benutzer verschiedene Steuerungen präsentiert werden, die unter Verwendung der Steuerungsnamen und Steuerungswerte modifiziert werden können. Der Benutzer kann diese Tasten auswählen (das gleiche gilt für das Betätigen einer Taste). 12B zeigt eine "nächste Ebenen"-UI-Anzeige 1210 für den Camcorder. Hier wählte der Benutzer das Hauptfeld aus dem Menü in 12A aus, und die Anzeige zeigt Steuerungen auf der Basis ihrer Gruppeninformation. Bei der vorliegenden Ausführungsform werden Gruppennamen auf einer tabellierten Schnittstelle verwendet, um es dem Benutzer zu erlauben, zwischen Gruppen innerhalb des ausgewählten Felds zu navigieren.
  • In 13 ist nun ein Flussdiagramm eines Verfahrens 1300 gemäß einer Ausführungsform der vorliegenden Erfindung gezeigt. Das Verfahren 1300 zeigt die Schritte eines Verfahrens zum Bereitstellen nahtloser Kompatibilität und Integration von mehreren Einrichtungen in einem HAVI-Netzwerk unter Verwendung der SDD-Information, welche in jeder Einrichtung gespeichert ist. Der Prozess 1300 beginnt im Schritt 1301, wo eine neue Einrichtung mit einem HAVI-Netzwerk gekoppelt wird. Im Schritt 1302 wird die Einrichtung abgefragt, eine Beschreibung (beispielsweise SDD) von Ebenen-1-Funktionen, die durch die Einrichtung unterstützt werden, zu erreichen. Im Schritt 1303 wird ein Ebenen-1-DCM, welches die Ebenen-1-Funktionen durchführt, für die Einrichtung auf der Basis der SDD erzeugt. Im Schritt 1304 bestimmt der Einrichtungsmanager, ob die neue Einrichtung Software für ein Ebenen-2-DCM enthält.
  • Betrachtet man weiter 13, so wird im Schritt 1305, wenn die neue Einrichtung Software zum Durchführen von Ebenen-2-Funktionen enthält, die Software von der Einrichtung aufgefunden, und im Schritt 1306 wird ein Ebenen-2-DCM, welche die Ebenen-2-Funktionen durchführt, unter Verwendung der Software erzeugt. In den Schritten 1307 und 1308 wird auf die Einrichtung ständig über das Ebenen-2-DCM zugegriffen. In den Schritten 1309 und 1310 wird, wenn die neue Einrichtung keine Software für das Ebenen-2-DCM enthält, auf die neue Einrichtung ständig über das Ebenen-1-DCM zugegriffen. Auf diese Weise erlauben es die Kombinationen des Ebenen-1-DCM und des Ebenen-2-DCM der Erfindung, nahtlose Kompatibilität und Integration der neuen Einrichtung mit den mehreren Einrichtungen im Netzwerk bereitzustellen.
  • 14 zeigt ein Flussdiagramm eines Prozesses 1400 gemäß einer Ausführungsform der vorliegenden Erfindung. Der Prozess 1400 zeigt die Schritte eines Verfahrens zum Bereitstellen einer Basisbefehlsfunktionalität und einer erweiterten Befehlsfunktionalität zwischen mehreren Einrichtungen in einem HAVI-Netzwerk. Im Schritt 1401 wird eine Einrichtung mit einem HAVI-Netzwerk gekoppelt, welches eine FAV-Einrichtung enthält. Im Schritt 1402 wird ein allgemeines Ebenen-1-DCM für die Einrichtung durch die FAV-Einrichtung erzeugt. Wie oben beschrieben ist das allgemeine Ebenen-1-DCM eine Grundabstraktion der Leistungen der Einrichtung. Das allgemeine Ebenen-1-DCM ermöglicht es der Einrichtung, auf einen Basissatz von Befehlen von der FAV-Einrichtung zu antworten. In den Schritten 1403 und 1404 verwendet die FAV-Einrichtung das allgemeine DCM, um die Einrichtung abzufragen, um zu bestimmen, ob die Einrichtung beschreibende Information (beispielsweise SDD) enthält. Wie oben beschrieben beschreibt die beschreibende Information die Leistungen der Einrichtung. Im Schritt 1405 erzeugt, wenn die Einrichtung beschreibende Information enthält, die FAV-Einrichtung ein parametrisiertes DCM für die Einrichtung, wobei das allgemeine DCM auf der Basis der beschreibenden Information modifiziert wird. In den Schritten 1406 und 1407 wird die Einrichtung fortlaufend unter Verwendung des parametrisierten Ebenen-1-DCM gesteuert. In den Schritten 1408 und 1409 wird, wenn die Einrichtung keine beschreibende Information enthält, die FAV-Einrichtung fortlaufend über das allgemeine Ebenen-1-DCM gesteuert.
  • Mit Hilfe von 15 ist nun ein Flussdiagramm eines Verfahrens 1500 gemäß einer Ausführungsform der vorliegenden Erfindung gezeigt. Das Verfahren 1500 zeigt die Schritte eines Verfahrens, um zukünftige Aufrüstung und Erweiterbarkeit der Einrichtungen im HAVI-Netzwerk sicherzustellen. Im Schritt 1501 wird ein Vorgabe-Ebenen-1-DCM für eine Einrichtung, welche mit dem Netzwerk gekoppelt ist, erzeugt. Wie oben beschrieben ist das Vorgabe-Ebenen-1-DCM so konfiguriert, um zumindest einen minimalen Grad an Kompatibilität zwischen der Einrichtung und anderen Einrichtungen im HAVI-Netzwerk sicherzustellen. Im Schritt 1502 wird durch die anderen Einrichtungen über das Vorgabe-Ebenen-1-DCM auf die Einrichtung zugegriffen. Wie oben beschrieben ermöglicht es das Vorgabe-DCM, dass die erste Einrichtung auf einen Vorgabesatz von Befehlen von anderen Einrichtungen im HAVI-Netzwerk antwortet. Im Schritt 1503 wird ein aktualisiertes Ebenen-1-DCM für die Einrichtungen entweder empfangen oder nicht empfangen. Im Schritt 1504 wird das aktualisierte Ebenen-2-DCM für die Einrichtung entweder empfangen oder nicht empfangen. Wie oben beschrieben ermöglichen es die Aktualisierungen, dass Leistungen und Funktionalität von Einrichtungen sich zu entwickeln (dass beispielsweise wirksamere Software verfügbar wird).
  • In den Schritten 1509 und 1508, wo ein aktualisiertes Ebenen-1-DCM empfangen wird, wird das aktualisierte Ebenen-1-DCM einbezogen (beispielsweise könnte dies lediglich das Modifizieren des laufenden Ebenen-1-DCM umfassen), und auf die Einrichtung wird laufend über dieses DCM zugegriffen, bis eine spätere Aktualisierung verfügbar ist. Im Schritt 1505, wo ein aktualisiertes Ebenen-2-DCM empfangen wird, unterbricht der DCM-Manager auf der Host-FAV-Einrichtung das laufende DCM, und in den Schritten 1506 und 1507 wird das aktualisierte Ebenen-2-DCM verbunden und die Registratur wird aktualisiert, um es anderen Einrichtungen innerhalb des HAVI-Netzwerks zu erlauben, auf das aktualisierte Ebenen-2-DCM zuzugreifen. Dieses DCM wird laufend zum Zugreifen auf die Einrichtung verwendet, bis ein später aktualisiertes Ebenen-2-DCM empfangen wird. Im Schritt 1510, wenn weder ein aktualisiertes Ebenen-1-DCM noch ein aktualisiertes Ebenen-2-DCM empfangen wird, arbeitet das Verfahren 1500 weiter mit dem laufenden DCM (beispielsweise dem letzten installierten DCM).
  • 16 zeigt ein Flussdiagramm eines Verfahrens 1600 gemäß einer Ausführungsform der vorliegenden Erfindung. Das Verfahren 1600 zeigt die Schritte eines Verfahrens zum Bereitstellen nahtloser Kompatibilität und Integration von Stammeinrichtungen mit den HAVI-konformen Einrichtungen in einem HAVI-Netzwerk. Das Verfahren 1600 beginnt im Schritt 1601, wo eine Stammeinrichtung mit dem HAVI-Netzwerk gekoppelt wird. Im Schritt 1602 wird die Stammeinrichtung über ein eigenes Protokoll abgefragt, um einen Satz von Grundsatzleistungen der Stammeinrichtung festzulegen. Wie oben beschrieben verwenden die HAVI-konformen Einrichtungen ein gemeinsames definiertes HAVI-Protokoll. Die Stamm einrichtung kommuniziert üblicherweise mit externen Einrichtungen (wenn überhaupt) unter Verwendung eines eigenen Protokolls. Im Schritt 1603 setzt das Verfahren 1600 einen Satz von Basisbefehlen von dem gemeinsamen Protokoll in den Satz von Grundsatzleistungen der Stammanmeldung um. Im Schritt 1604 wird ein Ebenen-1-DCM für die Stammeinrichtung erzeugt. Wie oben beschrieben basiert das DCM auf dem Satz von Grundsatzbefehlen. In Schritten 1605 und 1606 wird auf die Stammeinrichtung fortlaufend über das Ebenen-1-DCM zugegriffen, so dass die anderen HAVI-Einrichtungen in der Lage sind, auf den Satz von Grundsatzleistungen der Stammeinrichtung zuzugreifen.
  • 17A zeigt ein Flussdiagramm eines Verfahrens 1700 gemäß einer Ausführungsform der vorliegenden Erfindung. Das Verfahren 1700 zeigt die Schritte eines Verfahrens zum Steuern von Einrichtungen innerhalb eines Heim-Audio-/Video-Netzwerks unter Verwendung eines Anwendungsprogramms von einem externen Dienstbereitsteller. Im Schritt 1702 wird ein Anwendungsprogramm durch einen Dienstbereitsteller aufgebaut (beispielsweise über Kabelfernsehen, Internet web site, usw.). Im Schritt 1703 teilt der Dienstbereitsteller das Anwendungsprogramm von dem Dienstbereitsteller einer intelligenten Empfänger/Decodereinrichtung des HAVI-Netzwerks über einen logischen Kanal mit. Diese Anwendung wird nachfolgend innerhalb eines computer-lesbaren Speichers des intelligenten Empfängers/Decoders spezialisiert.
  • Betrachtet man weiter 17A, so fragt im Schritt 1704 das Anwendungsprogramm die HAVI-Registratur der Einrichtung (beispielsweise FAV-Einrichtung) ab, um DCMs im Netzwerk anzuordnen, und wählt ein entsprechendes DCM von der Registratur. Im Schritt 1705 bestimmt die nach unten geladene Anwendung eine Kommunikationspunktinformation vom ausgewählten DCM. Im Schritt 1706 steuert die Anwendung eine entsprechende Einrichtung des HAVI-Netzwerks, wobei mit der entsprechenden Einrichtung unter Verwendung der Kommunikationspunktinformation kommuniziert wird. Im Schritt 1707 werden, wenn die Anwendung benötigt, eine andere Einrichtung zu steuern, die Schritte 1704 bis 1706 wiederholt. Wenn die Anwendung nicht benötigt, eine andere Einrichtung zu steuern, enden die Verfahren 1700 im Schritt 1708.
  • 17B zeigt ein Diagramm eines HAVI-Netzwerks 1750 mit dem Dienstbereitsteller 1720 gemäß dem Verfahren 1700 von 17A. Wie oben beschrieben wird das Anwendungsprogramm vom Dienstbereitsteller 1720 auf das HAVI-Netzwerk 1750 heruntergeladen. Die Anwendung wird auf dem Prozessor 601 und dem Speicher 602 der intelligenten Einrichtung (beispielsweise Set-Top-Box 301) spezialisiert. Das HAVI-Netzwerk 1750 um fasst außerdem vier HAVI-Einrichtungen, d.h., die Einrichtung 0 bis zur Einrichtung 3 (beispielsweise Fernsehgerät, DVDR usw.).
  • DCM-Verwaltungs-API
  • Eine DCM-Verwaltungs-API gemäß einer Ausführungsform der vorliegenden Erfindung wird anschließend gezeigt. Bei der vorliegenden Ausführungsform umfassen die gemeinsamen DCM-Befehle Bereiche, beispielsweise die Verbindungsverwaltung, Information und Statusanfragen für die Einrichtung und deren Stecker, usw.. Unabhängig vom Typus der Einrichtung, die durch das DCM gezeigt wird, müssen diese Informationssätze unterstützt werden.
  • Das folgende ist eine Liste von DCM-Verwaltungsinformationen, welche – bei den vorliegenden Ausführungsformen – alle DCM's benötigen, die HAVI-Architektur zu unterstützen:
  • Figure 00440001
  • Figure 00450001
  • Die funktions-spezifischen Informationen entsprechen den üblichen natürlichen Befehlen, beispielsweise Wiedergabe, Stopp, Rückspulen für die VCR-Funktionalität innerhalb einer Einrichtung. Da es benötigt wird, diese Informationen zu einer definierten Lage innerhalb einer Einrichtung zu adressieren, wird das FCM (Funktionssteuerungsmodul) verwendet, um das Ziel dieser Informationen zu zeigen. Wie DCM's gibt es einige Informationen, welche sich mit der Administration und Verwaltung der FCM's beschäftigen müssen. Diese Informationen werden durch alle FCM's unterstützt, unabhängig von ihrem besonderen Bereich. Die Informationen sind wie folgt:
  • Figure 00460001
  • Die funktionellen Bereichsinformationen basieren auf der Art von Funktion (VCR, Tuner, usw.). Diese sind die typischen Befehle Wiedergabe, Stopp, Zurückspulen, die einer erwarten würde.
  • Die Ebenen-1-Kompatibilität umfasst sowohl das Zusammenwirken von Einrichtung zu Einrichtung als auch von Mensch-zu-Einrichtung. Die funktionellen Informationssätze, beispielsweise Wiedergabe, Stopp und Zurückspulen werden für die Zusammenarbeit von Einrichtung-zu-Einrichtung verwendet. Ein Beispiel von diesem würde ein Videoeditier-Software-Paket sein, welches wünscht, einen anderen Typus von VCR zu steuern. Das Programm wird mit einem sehr spezifischen Satz von Benutzerschnittstellensteuerungen ausge bildet, die sich auf alle VCR's beziehen. Wenn der Benutzer mit der Anwendung zusammenarbeitet, sendet die Anwendung wiederum bereichs-spezifische Befehle, beispielsweise Wiedergabe und Stopp, zur Zieleinrichtung.
  • In der HAVI-Architektur wird die Anwendung diese Informationen zum DCM liefern, und das DCM wird diese in die ursprüngliche Sprache der Ziel-BAV-Einrichtung übertragen. Wenn die Zieleinrichtung zufällig die HAVI-Informations-Architektur unterstützt, müssen diese Befehle dann überhaupt nicht übertragen werden. Sie werden lediglich als HAVI-Information zum HAVI-Ziel geliefert.
  • Camcorder-Einrichtungen sind im Wesentlichen VCR-ähnlich. Deren zusätzliche Funktionalität ist Teil von Camcorder-Effekten, Übertragungen usw.. Sie sind wie folgt:
  • Figure 00470001
  • Mini-Discs gehören zur Kategorie des Speichers mit wahlfreiem Zugriff, sie unterstützen einen Basissatz von Befehlen, um Wiedergabe, Vorwärts, usw. zu steuern und einen Satz von Befehlen, die für wahlfreie Zugriffsmedia speziell sind. Diese Befehle sind wie folgt:
  • Figure 00470002
  • Festplatten gehören zur Kategorie der Speicher mit wahlfreiem Zugriff, sie unterstützen einen Basissatz von Befehlen, um Wiedergabe, Vorwärts, usw. zu steuern, und einen Satz von Befehlen speziell für wahlfreie Zugriffsmedia. Die Befehle sind wie folgt:
  • Figure 00480001
  • In bezug auf Benutzerschnittstellen sollte man vorteilhaft erkennen, dass eine allgemeine und einfache UI sein kann, die auf Worten basiert, wie in 12A gezeigt ist. Eine verfeinerte, auf der Basis von DCM-Spezialisierung kann so sein, wie in 12B gezeigt ist. Wo es grafische Information gibt, welche mitgeführt wird, wird SDD durch das allgemeine DCM verwendet, um sich selbst zu spezialisieren.
  • Folglich liefert die vorliegende Erfindung ein Heim-Audio-Visuelles (AV)-Netzwerk, welches eine offene Architektur für zusammenarbeitende CE Einrichtungen (Verbraucher elektronische Einrichtungen) in einem Heimnetzwerk definiert. Die Kompatibilitätsmerkmale der vorliegenden Erfindung definieren ein Architekturmodell, welches es CE-Einrichtungen von irgendeinem Hersteller erlaubt, nahtlos mit dem Heim-AV-System des Benutzers zusammenzuarbeiten und zu funktionieren. Das System nach der vorliegenden Erfindung umfasst eine Kombination eines Basissatzes von allgemeinen Einrichtungssteuerungen mit einem Verfahren, um ein Basissteuerungsprotokoll als neue Merkmale zu erweitern, und neue CE-Einrichtungen werden innerhalb des Heim-AV-Netzwerks entwickelt. Wenn man so verfährt, ist die Architektur nach der vorliegenden Erfindung erweiterbar und kann schnell modifiziert und erweitert werden, wenn sich die Markterfordernisse und die Technologie ändern.
  • Die obigen Beschreibungen spezieller Ausführungsformen der vorliegenden Erfindung wurden aus Darstellungs- und Beschreibungszwecken geliefert. Sie sind nicht dafür beabsichtigt, erschöpfend zu sein oder die Erfindung auf die genau offenbarten Formen zu beschränken, und folglich sind viele Modifikationen und Variationen im Lichte der obigen Lehre möglich. Die Ausführungsformen wurden ausgewählt und beschrieben, um am besten die Prinzipien der Erfindung und deren praktische Anwendung zu erläutern, um dadurch den Fachmann in die Lage zu versetzen, die Erfindung und verschiedene Ausführungsformen mit verschiedenen Modifikationen am besten zu nutzen, wie sie auf die bestimmte in Betracht gezogene Anwendung geeignet sind. Es ist beabsichtigt, dass der Rahmen der Erfindung durch die hier angehängten Patentansprüche und der Äquivalente definiert ist.

Claims (26)

  1. Verfahren zum Bereitstellen eines grundsätzlichen und erweiterten Befehlssatzes, wobei das Verfahren folgende Schritte aufweist: a) Koppeln (1401) einer neuen Einrichtung (14, 16, 18, 20, 22, 24, 201, 202, 301, 302, 303, 304, 401, 402, 501) an ein Heim-Audio-/Video-Netzwerk (10a, 10b, 200, 300, 400, 500); b) Erzeugen (1402) eines allgemeinen Steuerungsmoduls für die neue Einrichtung (14, 16, 18, 20, 22, 24, 201, 202, 301, 302, 303, 304, 401, 402, 501), wobei das allgemeine Steuerungsmodul ermöglicht, dass die neue Einrichtung (14, 16, 18, 20, 22, 24, 201, 202, 301, 302, 303, 304, 401, 402, 501) auf einen grundsätzlichen Befehlssatz anspricht; c) Erzielen (1403, 1404) beschreibender Information in bezug auf die neue Einrichtung (14, 16, 18, 20, 22, 24, 201, 202, 301, 302, 303, 304, 401, 402, 501), wobei die Information in der neuen Einrichtung (14, 16, 18, 20, 22, 24, 201, 202, 301, 302, 303, 304, 401, 402, 501) gespeichert ist; d) Erzeugen (1405) eines parametrisierten Steuerungsmoduls für die neue Einrichtung (14, 16, 18, 20, 22, 24, 201, 202, 301, 302, 303, 304, 401, 402, 501) durch Modifizieren des allgemeinen Steuerungsmoduls auf der Basis der beschreibenden Information; und e) Zugreifen (1406, 1407) auf die neue Einrichtung (14, 16, 18, 20, 22, 24, 201, 202, 301, 302, 303, 304, 401, 402, 501), über das parametrisierte Steuerungsmodul, wobei das parametrisierte Steuerungsmodul ermöglicht, dass die neue Einrichtung (14, 16, 18, 20, 22, 24, 201, 202, 301, 302, 303, 304, 401, 402, 501) auf einen erweiterten Befehlssatz anspricht.
  2. Verfahren nach Anspruch 1, wobei die neue Einrichtung eine erste Einrichtung ist, so dass die Schritte a)–e) modifiziert werden zu a) Koppeln einer ersten Einrichtung (14, 16, 18, 20, 22, 24, 201, 202, 301, 302, 303, 304, 401, 402, 501) mit dem Heim-Audio-/Video-Netzwerk (10a, 10b, 200, 300, 400, 500), wobei das Netzwerk (10a, 10b, 200, 300, 400, 500) eine zweite Einrichtung (14, 16, 18, 20, 22, 24, 201, 202, 301, 302, 303, 304, 401, 402, 501) hat; b) Erzeugen eines allgemeinen Steuerungsmoduls für die erste Einrichtung (14, 16, 18, 20, 22, 24, 201, 202, 301, 302, 303, 304, 401, 402, 501) unter Verwendung der zweiten Einrichtung (14, 16, 18, 20, 22, 24, 201, 202, 301, 302, 303, 304, 401, 402, 501), wobei das allgemeine Steuerungsmodul ermöglicht, dass die erste Einrichtung (14, 16, 18, 20, 22, 24, 201, 202, 301, 302, 303, 304, 401, 402, 501) auf einen grundsätzlichen Befehlssatz von der zweiten Einrichtung (14, 16, 18, 20, 22, 24, 201, 202, 301, 302, 303, 304, 401, 402, 501) anspricht; c) Erzielen beschreibender Information in bezug auf die erste Einrichtung (14, 16, 18, 20, 22, 24, 201, 202, 301, 302, 303, 304, 401, 402, 501), wobei die. beschreibende Information in der ersten Einrichtung (14, 16, 18, 20, 22, 24, 201, 202, 301, 302, 303, 304, 401, 402, 501) gespeichert ist; d) Erzeugen eines parametrisierten Steuerungsmoduls für die erste Einrichtung (14, 16, 18, 20, 22, 24, 201, 202, 301, 302, 303, 304, 401, 402, 501) durch Modifizieren des allgemeinen Steuerungsmoduls auf der Basis der beschreibenden Information, wobei der Schritt d) durch die zweite Einrichtung (14, 16, 18, 20, 22, 24, 201, 202, 301, 302, 303, 304, 401, 402, 501) durchgeführt wird; und e) Zugreifen auf die erste Einrichtung (14, 16, 18, 20, 22, 24, 201, 202, 301, 302, 303, 304, 401, 402, 501) durch die zweite Einrichtung (14, 16, 18, 20, 22, 24, 201, 202, 301, 302, 303, 304, 401, 402, 501) über das parametrisierte Steuerungsmodul, wobei das parametrisierte Steuerungsmodul ermöglicht, dass die erste Einrichtung (14, 16, 18, 20, 22, 24, 201, 202, 301, 302, 303, 304, 401, 402, 501) auf einen erweiterten Befehlssatz von der zweiten Einrichtung (14, 16, 18, 20, 22, 24, 201, 202, 301, 302, 303, 304, 401, 402, 501) anspricht.
  3. Verfahren nach Anspruch 2, wobei das parametrisierte Steuerungsmodul ermöglicht, dass die zweite Einrichtung (14, 16, 18, 20, 22, 24, 201, 202, 301, 302, 303, 304, 401, 402, 501) spezialisierte Information in bezug auf die erste Einrichtung (14, 16, 18, 20, 22, 24, 201, 202, 301, 302, 303, 304, 401, 402, 501) einem Benutzer über eine Benutzerschnittstelle (1200, 1210) darbietet.
  4. Verfahren nach Anspruch 2, wobei die beschreibende Information durch die zweite Einrichtung (14, 16, 18, 20, 22, 24, 201, 202, 301, 302, 303, 304, 401, 402, 501) verwendet wird, eine Anwendungsprogrammier-Schnittstelle (API) für die erste Einrichtung (14, 16, 18, 20, 22, 24, 201, 202, 301, 302, 303, 304, 401, 402, 501) zu vergrößern.
  5. Verfahren nach Anspruch 2, wobei die beschreibende Information durch die zweite Einrichtung (14, 16, 18, 20, 22, 24, 201, 202, 301, 302, 303, 304, 401, 402, 501) ver wendet wird, um eine Einrichtungsabstraktion der ersten Einrichtung (14, 16, 18, 20, 22, 24, 201, 202, 301, 302, 303, 304, 401, 402, 501) zu vergrößern.
  6. Verfahren nach Anspruch 2, wobei die Schritte b) bis d) durch einen Einrichtungsmanager (761) durchgeführt werden, der auf der zweiten Einrichtung (14, 16, 18, 20, 22, 24, 201, 202, 301, 302, 303, 304, 401, 402, 501) spezialisiert ist.
  7. Verfahren nach Anspruch 2, wobei sowohl das grundsätzliche Steuerungsmodul als auch das parametrisierte Steuerungsmodul auf der zweiten Einrichtung (14, 16, 18, 20, 22, 24, 201, 202, 301, 302, 303, 304, 401, 402, 501) spezialisiert sind.
  8. Verfahren nach Anspruch 2, wobei auf die erste Einrichtung (14, 16, 18, 20, 22, 24, 201, 202, 301, 302, 303, 304, 401, 402, 501) durch eine der mehreren Einrichtungen (14, 16, 18, 20, 22, 24, 201, 202, 301, 302, 303, 304, 401, 402, 501) im Netzwerk (10a, 10b, 200, 300, 400, 500) zugegriffen wird, wobei auf das grundsätzliche Steuerungsmodul oder das parametrisierte Steuerungsmodul zugegriffen wird (1502, 1503, 1504, 1505, 1506, 1507) in Abhängigkeit von den Fähigkeiten der ersten Einrichtung (14, 16, 18, 20, 22, 24, 201, 202, 301, 302, 303, 304, 401, 402, 501).
  9. Verfahren nach Anspruch 2, wobei das Netzwerk (10a, 10b, 200, 300, 400, 500) ein Netzwerk auf der Basis von IEEE 1394 ist, und das allgemeine Steuerungsmodul und das parametrisierte Steuerungsmodul so konfiguriert sind, um gemäß der seriellen Kommunikation von IEEE 1394 zu funktionieren.
  10. Verfahren nach Anspruch 1, wobei das Heim-Audio-/Video-Netzwerk (10a, 10b, 200, 300, 400, 500) mehrere Einrichtungen (14, 16, 18, 20, 22, 24, 201, 202, 301, 302, 303, 304, 401, 402, 501) aufweist, die mit einem Bus (30) gekoppelt sind, wobei zumindest eine der Einrichtungen eine Host-Einrichtung (301) ist, die einen Prozessor (601) hat, der mit einem computer-lesbaren Speicher (602, 603) gekoppelt ist, wobei der Speicher computerlesbare Instruktionen enthält, welche, wenn ausgeführt, ein Verfahren zum Bereitstellen eines grundsätzlichen Befehlssatzes ausführen, und eines erweiterten Befehlssatzes zwischen den mehreren Einrichtung (14, 16, 18, 20, 22, 24, 201, 202, 301, 302, 303, 304, 401, 402, 501), wobei das Heim-Audio-/Video-Netzwerk (10a, 10b, 200, 300, 400, 500) mehrere Einrichtung (14, 16, 18, 20, 22, 24, 201, 202, 301, 302, 303, 304, 401,402, 501) aufweist.
  11. Verfahren nach Anspruch 1 oder 10, wobei das Verfahren außerdem den Schritt aufweist, spezialisierte Information in Bezug auf die neue Einrichtung (14, 16, 18, 20, 22, 24, 201, 202, 301, 302, 303, 304, 401, 402, 501) einem Benutzer über eine Benutzerschnittstelle unter Verwendung des parametrisierten Steuerungsmoduls darzustellen.
  12. Verfahren nach Anspruch 1 oder 10, wobei das Verfahren außerdem den Schritt aufweist, eine Anwendungsprogrammierungsschnittstelle für die neue Einrichtung (14, 16, 18, 20, 22, 24, 201, 202, 301, 302, 303, 304, 401, 402, 501) unter Verwendung der beschreibenden Information zu vergrößern.
  13. Verfahren nach Anspruch 1 oder 10, wobei das Verfahren außerdem den Schritt aufweist, eine Einrichtungsabstraktion der neuen Einrichtung (14, 16, 18, 20, 22, 24, 201, 202, 301, 302, 303, 304, 401, 402, 501) unter Verwendung der beschreibenden Information zu vergrößern.
  14. Verfahren nach Anspruch 1 oder 10, wobei sowohl das allgemeine Steuerungsmodul als auch das parametrisierte Steuerungsmodul auf der Host-Einrichtung (301) der mehreren Einrichtungen (14, 16, 18, 20, 22, 24, 201, 202, 301, 302, 303, 304, 401, 402, 501) spezialisiert sind, die im Heim-Audio-/Video-Netzwerk (10a, 10b, 200, 300, 400, 500) enthalten sind.
  15. Verfahren nach Anspruch 1 oder 10, wobei auf die neue Einrichtung (14, 16, 18, 20, 22, 24, 201, 202, 301, 302, 303, 304, 401, 402, 501) durch eine der mehreren Einrichtungen (14, 16, 18, 20, 22, 24, 201, 202, 301, 302, 303, 304, 401, 402, 501) zugegriffen wird, wobei auf das allgemeine Steuerungsmodul oder das parametrisierte Steuerungsmodul in Abhängigkeit von den Fähigkeiten der neuen Einrichtung (14, 16, 18, 20, 22, 24, 201, 202, 301, 302, 303, 304, 401, 402, 501) zugegriffen (1502, 1503, 1504, 1505, 1506, 1507) wird.
  16. Verfahren nach Anspruch 1 oder 10, wobei sowohl das allgemeine Steuerungsmodul als auch das parametrisierte Steuerungsmodul Steuerungsschnittstellen bereitstellen, die einen vorher festgelegten Satz von Steuerungsschnittstellen für die neue Einrichtung (14, 16, 18, 20, 22, 24, 201, 202, 301, 302, 303, 304, 401, 402, 501) bereitstellen, welche Integration der neuen Einrichtung (14, 16, 18, 20, 22, 24, 201, 202, 301, 302, 303, 304, 401, 402, 501) mit den mehreren Einrichtung (14, 16, 18, 20, 22, 24, 201, 202, 301, 302, 303, 304, 401, 402, 501) im Heim-Audio-/Video-Netzwerk (10a, 10b, 200, 300, 400, 500) ermöglichen.
  17. Verfahren nach Anspruch 1, wobei das Verfahren in einem System durchgeführt wird, welches mehreren Einrichtungen (14, 16, 18, 20, 22, 24, 201, 202, 301, 302, 303, 304, 401, 402, 501) eines Heim-Audio-/Video-Netzwerks (10a, 10b, 200, 300, 400, 500) aufweist, die mehreren Einrichtungen (14, 16, 18, 20, 22, 24, 201, 202, 301, 302, 303, 304, 401, 402, 501) mit einem Bus (30) gekoppelt sind, wobei eine der Einrichtungen (14, 16, 18, 20, 22, 24, 201, 202, 301, 302, 303, 304, 401, 402, 501) eine Host-Einrichtung ist, die einen Prozessor (601) aufweist, der mit einem computer-lesbaren Speicher (602, 603) gekoppelt ist, wobei der Speicher computer-lesbare Instruktionen enthält, die, wenn ausgeführt, das Verfahren zum Bereitstellen eines grundsätzlichen Befehlssatzes und eines erweiterten Befehlssatzes zwischen den mehreren Einrichtungen (14, 16, 18, 20, 22, 24, 201, 202, 301, 302, 303, 304, 401, 402, 501) bereitstellt, wobei das Verfahren folgende zusätzliche Schritte aufweist: f) Darstellen spezialisierter Information in bezug auf die neue Einrichtung (14, 16, 18, 20, 22, 24, 201, 202, 301, 302, 303, 304, 401, 402, 501) einem Benutzer über eine Benutzerschnittstelle unter Verwendung des parametrisierten Steuerungsmoduls; und g) Vergrößern einer Anwendungsprogrammierungsschnittstelle (API) für die neue Einrichtung (14, 16, 18, 20, 22, 24, 201, 202, 301, 302, 303, 304, 401, 402, 501) unter Verwendung der beschreibenden Information.
  18. Verfahren nach Anspruch 17, wobei auf die neue Einrichtung (14, 16, 18, 20, 22, 24, 201, 202, 301, 302, 303, 304, 401, 402, 501) durch eine der mehreren Einrichtungen (14, 16, 18, 20, 22, 24, 201, 202, 301, 302, 303, 304, 401, 402, 501) zugegriffen wird, wobei auf das allgemeine Steuerungsmodul oder das parametrisierte Steuerungsmodul in Abhängigkeit von den Fähigkeiten der neuen Einrichtung (14, 16, 18, 20, 22, 24, 201, 202, 301, 302, 303, 304, 401, 402, 501) zugegriffen wird.
  19. Verfahren nach Anspruch 1, 10 oder 17, wobei der Bus (30) des Heim-Audio-/Video-Netzwerks (10a, 10b, 200, 300, 400, 500) der IEEE 1394-Standard oder der IEEE-Seriell-Kommunikations-Bus-Standard ist, und das allgemeine Steuerungsmodul und das parametrisierte Steuerungsmodul so konfiguriert sind, um gemäß IEEE 1394 oder serieller Kommunikation nach IEEE 1394 zu funktionieren.
  20. Verfahren nach Anspruch 17, wobei sowohl das allgemeine Steuerungsmodul als auch das parametrisierte Steuerungsmodul Steuerungsschnittstellen bereitstellen, welche die Integration der neuen Einrichtung (14, 16, 18, 20, 22, 24, 201, 202, 301, 302, 303, 304, 401, 402, 501) mit den mehreren Einrichtungen (14, 16, 18, 20, 22, 24, 201, 202, 301, 302, 303, 304, 401, 402, 501) im Heim-Audio-/Video-Netzwerk (10a, 10b, 200, 300, 400, 500) ermöglichen.
  21. Verfahren nach Anspruch 17, wobei die Steuerungsschnittstellen Kompatibilitäts- und Funktionalitätsschnittstellen für die neue Einrichtung (14, 16, 18, 20, 22, 24, 201, 202, 301, 302, 303, 304, 401, 402, 501) bereitstellen.
  22. Gerät zum Bereistellen eines grundsätzlichen Befehlssatzes und eines erweiterten Befehlssatzes zwischen mehreren Einrichtungen in einem Heim-Audio-/Video-Netzwerk, welches aufweist: a) eine Einrichtung zum Koppeln einer ersten Einrichtung (14, 16, 18, 20, 22, 24, 201, 202, 301, 302, 303, 304, 401, 402, 501) mit einem Netzwerk (10a, 10b, 200, 300, 400, 500), wobei das Heim-Audio-Video-Netzwerk (10a, 10b, 200, 300, 400, 500) eine zweite Einrichtung (14, 16, 18, 20, 22, 24, 201, 202, 301, 302, 303, 304, 401, 402, 501) aufweist; b) eine Einrichtung zum Erzeugen eines allgemeinen Steuerungsmoduls für die erste Einrichtung (14, 16, 18, 20, 22, 24, 201, 202, 301, 302, 303, 304, 401, 402, 501) durch Verwenden der zweiten Einrichtung (14, 16, 18, 20, 22, 24, 201, 202, 301, 302, 303, 304, 401, 402, 501), wobei das allgemeine Steuerungsmodul ermöglicht, dass die erste Einrichtung (14, 16, 18, 20, 22, 24, 201, 202, 303, 302, 303, 304, 401, 402, 501) auf einen Basissatz von Befehlen von der zweiten Einrichtung (14, 16, 18, 20, 22, 24, 201, 202, 301, 302, 303, 304, 401, 402, 501) anspricht; c) eine Einrichtung zum Erzielen beschreibender Information in bezug auf die erste Einrichtung (14, 16, 18, 20, 22, 24, 201, 202, 301, 302, 303, 304, 401, 402, 501), wobei die beschreibende Information in der ersten Einrichtung (14, 16, 18, 20, 22, 24, 201, 202, 301, 302, 303, 304, 401, 402, 501) gespeichert ist; d) eine Einrichtung zum Erzeugen eines parametrisierten Steuerungsmoduls für die erste Einrichtung (14, 16, 18, 20, 22, 24, 201, 202, 301, 302, 303, 304, 401, 402, 501) durch Modifizieren des allgemeinen Steuerungsmoduls auf der Basis der beschreibenden Information unter Verwendung der zweiten Einrichtung (14, 16, 18, 20, 22, 24, 201, 202, 301, 302, 303, 304, 401, 402, 501); und e) eine Einrichtung zum Zugreifen auf die erste Einrichtung (14, 16, 18, 20, 22, 24, 201, 202, 301, 302, 303, 304, 401, 402, 501) durch die zweite Einrichtung (14, 16, 18, 20, 22, 24, 201, 202, 301, 302, 303, 304, 401, 402, 501) über das parametrisierte Steuerungsmodul, wobei das parametrisierte Steuerungsmodul ermöglicht, dass die erste Einrichtung (14, 16, 18, 20, 22, 24, 201, 202, 301, 302, 303, 304, 401, 402, 501) auf einen erweiterten Satz von Befehlen von der zweiten Einrichtung (14, 16, 18, 20, 22, 24, 201, 202, 301, 302, 303, 304, 401, 402, 501) anspricht.
  23. Gerät nach Anspruch 22, welches außerdem eine Benutzerschnittstelle aufweist.
  24. Gerät nach Anspruch 22, wobei ein Einrichtungsmanager (761) auf der zweiten Einrichtung spezialisiert ist.
  25. Gerät nach Anspruch 22, wobei das Netzwerk ein Netzwerk auf Basis von IEEE 1394 ist.
  26. Gerät nach Anspruch 22, wobei die erste Einrichtung einen Prozessor (601) aufweist, der mit einem computer-lesbaren Speicher (602, 603) gekoppelt ist, wobei der Speicher computer-lesbare Instruktionen enthält, die, wenn ausgeführt, das Verfahren zum Bereitstellen eines grundsätzlichen Befehlssatzes und eines erweiterten Befehlssatzes zwischen den mehreren Einrichtungen (14, 16, 18, 20, 22, 24, 201, 202, 301, 302, 303, 304, 401, 402, 501) durchführen.
DE69829218T 1998-01-06 1998-12-23 Ein audio-video-netzwerk mit gerätsteuerung Expired - Lifetime DE69829218T2 (de)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
US3097 1998-01-06
US09/003,097 US6349352B1 (en) 1998-01-06 1998-01-06 Home audio/video network with both generic and parameterized device control
PCT/US1998/027605 WO1999035787A2 (en) 1998-01-06 1998-12-23 A home audio/video network with device control

Publications (2)

Publication Number Publication Date
DE69829218D1 DE69829218D1 (de) 2005-04-07
DE69829218T2 true DE69829218T2 (de) 2006-02-16

Family

ID=21704131

Family Applications (1)

Application Number Title Priority Date Filing Date
DE69829218T Expired - Lifetime DE69829218T2 (de) 1998-01-06 1998-12-23 Ein audio-video-netzwerk mit gerätsteuerung

Country Status (8)

Country Link
US (1) US6349352B1 (de)
EP (1) EP1046257B1 (de)
JP (1) JP4301731B2 (de)
KR (1) KR20010033878A (de)
AT (1) ATE290280T1 (de)
AU (1) AU2014599A (de)
DE (1) DE69829218T2 (de)
WO (1) WO1999035787A2 (de)

Families Citing this family (122)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10361802B1 (en) 1999-02-01 2019-07-23 Blanding Hovenweep, Llc Adaptive pattern recognition based control system and method
FR2778046B1 (fr) * 1998-04-23 2000-05-19 Thomson Multimedia Sa Procede de gestion d'objets dans un reseau de communication et dispositif de mise en oeuvre
US7043532B1 (en) * 1998-05-07 2006-05-09 Samsung Electronics Co., Ltd. Method and apparatus for universally accessible command and control information in a network
JP3922817B2 (ja) * 1998-06-30 2007-05-30 株式会社東芝 通信ノード及び通信端末
JP3583657B2 (ja) * 1998-09-30 2004-11-04 株式会社東芝 中継装置及び通信装置
US6963784B1 (en) * 1998-10-16 2005-11-08 Sony Corporation Virtual device control modules and function control modules implemented in a home audio/video network
US6275865B1 (en) * 1998-11-25 2001-08-14 Sony Corporation Of Japan Method and system for message dispatching in a home audio/video network
JP3576019B2 (ja) * 1998-12-28 2004-10-13 株式会社東芝 通信ノード
US7904187B2 (en) 1999-02-01 2011-03-08 Hoffberg Steven M Internet appliance system and method
US6684401B1 (en) * 1999-03-26 2004-01-27 Sony Corporation Method and system for independent incoming and outgoing message dispatching in a home audio/video network
US6560635B1 (en) * 1999-04-09 2003-05-06 Sony Corporation System and method for locally caching remote query replies in an electronic network
JP2000332801A (ja) * 1999-05-19 2000-11-30 Matsushita Electric Ind Co Ltd 仮想ａｖネットワーク構築装置、及び仮想ａｖネットワーク構築方法、並びに仮想ａｖネットワーク構築方法に関するプログラムを記載した記録媒体
US6738835B1 (en) * 1999-05-28 2004-05-18 Sony Corporation Information processing apparatus and method, and recording medium
JP2000349793A (ja) * 1999-06-04 2000-12-15 Toshiba Corp ネットワーク装置及びネットワーク方法
DE19943875A1 (de) * 1999-09-14 2001-03-15 Thomson Brandt Gmbh System zur Sprachsteuerung mit einem Mikrofonarray
KR100620186B1 (ko) 1999-09-21 2006-09-01 엘지전자 주식회사 디지털 인터페이스에서의 명령 및 응답 프레임 생성장치 및 방법
US6988276B2 (en) 1999-12-14 2006-01-17 Koninklijke Philips Electronics N.V. In-house TV to TV channel peeking
US7295986B2 (en) * 2000-01-14 2007-11-13 Sony Corporation Information processing apparatus and method, and recording medium therefor
WO2001054292A1 (en) * 2000-01-21 2001-07-26 Koninklijke Philips Electronics N.V. Set-top box connects remote control device to web site for customized code downloads
US6618714B1 (en) * 2000-02-10 2003-09-09 Sony Corporation Method and system for recommending electronic component connectivity configurations and other information
US6813669B1 (en) * 2000-02-24 2004-11-02 International Business Machines Corporation Agent provided by USB device for executing USB device dependent program in USB host
ATE268529T1 (de) * 2000-03-17 2004-06-15 America Online Inc Heimnetz
US7187947B1 (en) 2000-03-28 2007-03-06 Affinity Labs, Llc System and method for communicating selected information to an electronic device
JP2001285309A (ja) * 2000-03-31 2001-10-12 Matsushita Electric Ind Co Ltd ゲートウェイ装置、媒体および情報集合体
TW510134B (en) 2000-04-04 2002-11-11 Koninkl Philips Electronics Nv Communication system, controlling device and controlled device
JP2001318745A (ja) * 2000-05-11 2001-11-16 Sony Corp データ処理装置およびデータ処理方法、並びに記録媒体
DE10030525A1 (de) * 2000-06-28 2002-01-24 Harman Becker Automotive Sys Verfahren zur Kommunikation zwischen zwei Netzwerken sowie Netzwerk
JP2002024197A (ja) * 2000-07-10 2002-01-25 Hitachi Ltd 遠隔制御可能な電子機器および遠隔制御方法
CN1322730C (zh) * 2000-08-14 2007-06-20 皇家菲利浦电子有限公司 HAVi及其它网际互联设备中的资源请求转发
DE10049498A1 (de) * 2000-10-06 2002-04-11 Philips Corp Intellectual Pty Virtuelles Speichergerät für ein digitales Hausnetz
US7277765B1 (en) 2000-10-12 2007-10-02 Bose Corporation Interactive sound reproducing
US7206853B2 (en) * 2000-10-23 2007-04-17 Sony Corporation content abstraction layer for use in home network applications
JP4586268B2 (ja) * 2000-12-25 2010-11-24 ヤマハ株式会社 ネットワークにおけるデータ送受信管理方法及び同データ送受信管理装置
US20020087964A1 (en) * 2000-12-28 2002-07-04 Gateway, Inc. System and method for enhanced HAVi based device implementation
US7346911B2 (en) * 2001-01-05 2008-03-18 International Business Machines Corporation Method, system, and program for communication among nodes in a system
US7206821B2 (en) * 2001-01-19 2007-04-17 Ricoh Co. Ltd. System and method for recording information on a storage medium
EP1239644A1 (de) * 2001-03-08 2002-09-11 THOMSON multimedia Verfahren zur Verwaltung isochroner Datenübertragungen in einer HAVI Umgebung
US20020174198A1 (en) * 2001-05-16 2002-11-21 Imation Corp. Management of networked devices
US7373495B2 (en) * 2001-05-17 2008-05-13 Intel Corporation Hardware cross-emulation using personas
EP1438669B1 (de) 2001-06-27 2014-01-22 SKKY Incorporated Verbesserte medienablieferungsplattform
EP1286349A1 (de) 2001-08-21 2003-02-26 Canal+ Technologies Société Anonyme Datei- und Inhaltsverwaltung
ATE347764T1 (de) * 2001-09-21 2006-12-15 Koninkl Philips Electronics Nv Gibt es kein spezifisches kontrollmodul? benutzen sie eines das weniger spezifisch ist
US7299304B2 (en) 2001-11-20 2007-11-20 Intel Corporation Method and architecture to support interaction between a host computer and remote devices
US20030097497A1 (en) * 2001-11-21 2003-05-22 Jeffrey Esakov Data format recognition for networks providing device interoperability
AU2002357175A1 (en) * 2001-12-18 2003-06-30 Thomson Licensing S.A. Internally generated close captioning/tele-texting for set-up menus of network-capable signal processing apparatus
TWI280759B (en) * 2002-03-13 2007-05-01 Matsushita Electric Ind Co Ltd Data communication method
KR20040089640A (ko) * 2002-03-25 2004-10-21 마츠시타 덴끼 산교 가부시키가이샤 기록장치, 기록방법, 및 프로그램
KR100830451B1 (ko) * 2002-03-30 2008-05-20 엘지전자 주식회사 홈 네트워크 시스템의 가전제품 제어코드 구성방법
WO2003085892A2 (en) * 2002-04-09 2003-10-16 Thomson Licensing S.A. Methods for communication in a multi-cluster network, device for connection to a network of clusters and bridge for connecting clusters
KR100441602B1 (ko) * 2002-04-11 2004-07-23 삼성전자주식회사 복수의 재생장치를 갖는 복합장치 및 그의 동작제어방법
US7181511B1 (en) * 2002-04-15 2007-02-20 Yazaki North America, Inc. System and method for using software objects to manage devices connected to a network in a vehicle
US8116889B2 (en) 2002-06-27 2012-02-14 Openpeak Inc. Method, system, and computer program product for managing controlled residential or non-residential environments
US6792323B2 (en) * 2002-06-27 2004-09-14 Openpeak Inc. Method, system, and computer program product for managing controlled residential or non-residential environments
US7933945B2 (en) 2002-06-27 2011-04-26 Openpeak Inc. Method, system, and computer program product for managing controlled residential or non-residential environments
US7024256B2 (en) * 2002-06-27 2006-04-04 Openpeak Inc. Method, system, and computer program product for automatically managing components within a controlled environment
JP3730599B2 (ja) * 2002-06-27 2006-01-05 株式会社東芝 サーバ装置および状態制御方法
US7383339B1 (en) 2002-07-31 2008-06-03 Aol Llc, A Delaware Limited Liability Company Local proxy server for establishing device controls
US20040039459A1 (en) * 2002-08-06 2004-02-26 Daugherty Paul R. Universal device control
JP4499565B2 (ja) * 2002-08-06 2010-07-07 コーニンクレッカ フィリップス エレクトロニクス エヌ ヴィ ネットワーク確立及び管理プロトコル
US7953899B1 (en) * 2002-08-21 2011-05-31 3Par Inc. Universal diagnostic hardware space access system for firmware
DE10254010B4 (de) * 2002-11-19 2009-01-02 Siemens Ag Verfahren zur automatischen Konfiguration einer Parametrieroberfläche von Werkzeugmaschinen oder Produktionsmaschinen
US7315886B1 (en) * 2002-12-30 2008-01-01 Aol Llc, A Delaware Limited Liability Company Capability spoofing using a local proxy server
US7756928B1 (en) * 2002-12-30 2010-07-13 Aol Inc. Interoperability using a local proxy server
US7987489B2 (en) 2003-01-07 2011-07-26 Openpeak Inc. Legacy device bridge for residential or non-residential networks
KR100512947B1 (ko) * 2003-01-16 2005-09-07 삼성전자주식회사 출력신호제어가 가능한 콤비네이션 시스템 및 그의 제어방법
DE10302477A1 (de) * 2003-01-23 2005-02-24 Deutsche Thomson-Brandt Gmbh Verfahren zur Verfügbarmachung eines Eingabeparameters einer Netzwerkstation eines Netzwerks eines ersten Typs in einem Netzwerk eines zweiten Typs sowie Verbindungseinheit zur Verbindung der Netzwerke des ersten und zweiten Typs
US20040157548A1 (en) * 2003-02-06 2004-08-12 Eyer Mark Kenneth Home network interface legacy device adapter
US8042049B2 (en) * 2003-11-03 2011-10-18 Openpeak Inc. User interface for multi-device control
US7668990B2 (en) * 2003-03-14 2010-02-23 Openpeak Inc. Method of controlling a device to perform an activity-based or an experience-based operation
JP4093899B2 (ja) * 2003-04-03 2008-06-04 シャープ株式会社 データ送信装置及びデータ受信装置及びデータ通信システム及びデータ通信管理用サーバ
US7337219B1 (en) 2003-05-30 2008-02-26 Aol Llc, A Delaware Limited Liability Company Classifying devices using a local proxy server
US11294618B2 (en) 2003-07-28 2022-04-05 Sonos, Inc. Media player system
US11106425B2 (en) 2003-07-28 2021-08-31 Sonos, Inc. Synchronizing operations among a plurality of independently clocked digital data processing devices
US11106424B2 (en) 2003-07-28 2021-08-31 Sonos, Inc. Synchronizing operations among a plurality of independently clocked digital data processing devices
US10613817B2 (en) 2003-07-28 2020-04-07 Sonos, Inc. Method and apparatus for displaying a list of tracks scheduled for playback by a synchrony group
US8234395B2 (en) 2003-07-28 2012-07-31 Sonos, Inc. System and method for synchronizing operations among a plurality of independently clocked digital data processing devices
US11650784B2 (en) 2003-07-28 2023-05-16 Sonos, Inc. Adjusting volume levels
US8290603B1 (en) 2004-06-05 2012-10-16 Sonos, Inc. User interfaces for controlling and manipulating groupings in a multi-zone media system
EP1505796A1 (de) * 2003-08-06 2005-02-09 STMicroelectronics Limited Dienstkontrollverfahren
CN100481767C (zh) * 2003-08-07 2009-04-22 三星电子株式会社 音频/视频装置及其控制设备和方法
JP2005079849A (ja) * 2003-08-29 2005-03-24 Toshiba Corp 情報処理装置、接続先選択方法および接続先選択プログラム
KR20050049199A (ko) * 2003-11-21 2005-05-25 삼성전자주식회사 콤보시어터 시스템 및 그의 동작 제어방법
US7206643B2 (en) * 2003-12-10 2007-04-17 Nokia Corporation Apparatus, system, and method for automation using automation modules
US9977561B2 (en) 2004-04-01 2018-05-22 Sonos, Inc. Systems, methods, apparatus, and articles of manufacture to provide guest access
US8868698B2 (en) 2004-06-05 2014-10-21 Sonos, Inc. Establishing a secure wireless network with minimum human intervention
US8326951B1 (en) * 2004-06-05 2012-12-04 Sonos, Inc. Establishing a secure wireless network with minimum human intervention
JP4037851B2 (ja) * 2004-06-16 2008-01-23 オンキヨー株式会社 増幅装置
JP4171456B2 (ja) * 2004-12-03 2008-10-22 三洋電機株式会社 Ａｖ機器
US8468219B2 (en) * 2005-02-01 2013-06-18 Broadcom Corporation Minimum intervention authentication of heterogeneous network technologies (MIAHNT)
KR100636784B1 (ko) * 2005-02-22 2006-10-20 삼성전자주식회사 홈네트워크의 서비스 프레임워크
JP4534891B2 (ja) 2005-07-26 2010-09-01 ソニー株式会社 入力装置、映像コンテンツのシステム及び入力方法
KR100782820B1 (ko) * 2005-09-30 2007-12-06 삼성전자주식회사 방송 수신기를 포함하는 인쇄 장치 및 인쇄 장치 구동 방법
JP2007287007A (ja) * 2006-04-19 2007-11-01 Orion Denki Kk 操作タスク予約機能を備えた情報処理装置及び操作タスク予約処理プログラム及び操作タスクの予約処理方法
FR2895109A1 (fr) * 2006-05-11 2007-06-22 France Telecom Procede de connexion sans fil entre deux dispositifs, dispositif sans fil et programme d'ordinateur a installer dans le dispositif sans fil correspondant
KR100765789B1 (ko) * 2006-06-27 2007-10-12 삼성전자주식회사 외부 기기에 대한 정보를 디스플레이하는 방법 및 장치와,그 방법을 수행하는 프로그램을 기록한 컴퓨터 판독 가능한기록 매체
JP4182997B2 (ja) * 2006-08-15 2008-11-19 ソニー株式会社 伝送システム及び送受信装置
US9202509B2 (en) 2006-09-12 2015-12-01 Sonos, Inc. Controlling and grouping in a multi-zone media system
US8788080B1 (en) 2006-09-12 2014-07-22 Sonos, Inc. Multi-channel pairing in a media system
US8483853B1 (en) 2006-09-12 2013-07-09 Sonos, Inc. Controlling and manipulating groupings in a multi-zone media system
US8077263B2 (en) * 2006-10-23 2011-12-13 Sony Corporation Decoding multiple remote control code sets
US20080098357A1 (en) * 2006-10-23 2008-04-24 Candelore Brant L Phantom information commands
US8438589B2 (en) 2007-03-28 2013-05-07 Sony Corporation Obtaining metadata program information during channel changes
US8299954B2 (en) 2009-12-15 2012-10-30 At&T Intellectual Property I, L.P. Proxy remote control
JP2012038032A (ja) * 2010-08-05 2012-02-23 Sony Corp 制御装置、制御システム、及び制御方法
US8782150B2 (en) 2010-11-09 2014-07-15 Sony Corporation Method and apparatus for enabling device communication and control using XMPP
US11429343B2 (en) 2011-01-25 2022-08-30 Sonos, Inc. Stereo playback configuration and control
US11265652B2 (en) 2011-01-25 2022-03-01 Sonos, Inc. Playback device pairing
US20150046830A1 (en) * 2012-03-19 2015-02-12 Telefonaktiebolaget L M Ericsson (Publ) Methods, Device and Social Network Manager for Enabling Interaction with Another Device
US8910265B2 (en) 2012-09-28 2014-12-09 Sonos, Inc. Assisted registration of audio sources
CN105052179B (zh) * 2013-01-24 2019-07-05 中兴通讯(美国)公司 机器对机器服务层和传输网络之间的通信
US9319409B2 (en) 2013-02-14 2016-04-19 Sonos, Inc. Automatic configuration of household playback devices
US9237384B2 (en) 2013-02-14 2016-01-12 Sonos, Inc. Automatic configuration of household playback devices
US9933920B2 (en) 2013-09-27 2018-04-03 Sonos, Inc. Multi-household support
US9241355B2 (en) 2013-09-30 2016-01-19 Sonos, Inc. Media system access via cellular network
US8782122B1 (en) 2014-01-17 2014-07-15 Maximilian A. Chang Automated collaboration for peer-to-peer electronic devices
US8782121B1 (en) 2014-01-17 2014-07-15 Maximilian A. Chang Peer-to-peer electronic device handling of social network activity
US10248376B2 (en) 2015-06-11 2019-04-02 Sonos, Inc. Multiple groupings in a playback system
US9608717B1 (en) 2015-09-30 2017-03-28 The Directv Group, Inc. Method and system for communicating between a media processor and network processor in a gateway device
US10181991B1 (en) 2015-09-30 2019-01-15 The Directv Group, Inc. Method and system for resetting processors of a gateway device
US10712997B2 (en) 2016-10-17 2020-07-14 Sonos, Inc. Room association based on name
US11218374B2 (en) * 2019-07-30 2022-01-04 Microsoft Technology Licensing, Llc Discovery and resolution of network connected devices
US11582110B2 (en) 2021-03-22 2023-02-14 Apple Inc. Techniques for sharing device capabilities over a network of user devices

Family Cites Families (11)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2725257B2 (ja) 1987-09-16 1998-03-11 ソニー株式会社 ディジタル記録装置
US5394541A (en) * 1990-07-17 1995-02-28 Sun Microsystems, Inc. Programmable memory timing method and apparatus for programmably generating generic and then type specific memory timing signals
JP3243803B2 (ja) 1991-08-28 2002-01-07 ソニー株式会社 Ａｖ機器
GB2268816B (en) 1992-07-14 1996-01-17 Sony Broadcast & Communication Controlling equipment
US5657414A (en) * 1992-12-01 1997-08-12 Scientific-Atlanta, Inc. Auxiliary device control for a subscriber terminal
JPH08168085A (ja) * 1994-12-13 1996-06-25 Sony Corp 電子機器装置
AU7706596A (en) * 1995-11-13 1997-06-05 Webtronics, Inc. Control of remote devices using http protocol
JPH09238385A (ja) * 1996-02-29 1997-09-09 Victor Co Of Japan Ltd 家電機器のリモートコントロール方法
JPH09265444A (ja) * 1996-03-28 1997-10-07 Aiwa Co Ltd データ処理装置
US5936667A (en) * 1997-05-13 1999-08-10 Sony Corporation System and method for testing and updating stored content of a remote transmitter for an entertainment system
US6052750A (en) * 1998-01-06 2000-04-18 Sony Corporation Of Japan Home audio/video network for generating default control parameters for devices coupled to the network, and replacing updated control parameters therewith

Also Published As

Publication number Publication date
ATE290280T1 (de) 2005-03-15
KR20010033878A (ko) 2001-04-25
DE69829218D1 (de) 2005-04-07
JP2002501240A (ja) 2002-01-15
WO1999035787A2 (en) 1999-07-15
US6349352B1 (en) 2002-02-19
AU2014599A (en) 1999-07-26
JP4301731B2 (ja) 2009-07-22
WO1999035787A3 (en) 1999-09-16
EP1046257A2 (de) 2000-10-25
EP1046257B1 (de) 2005-03-02

Similar Documents

Publication Publication Date Title
DE69829218T2 (de) Ein audio-video-netzwerk mit gerätsteuerung
DE69829221T2 (de) Ein audio-video-netzwerk
DE69836101T2 (de) Ein audio-video-gerät
DE69829219T2 (de) Verfahren und system in verbindung mit einem audio-video-netz
DE69838801T2 (de) Auf Browser basiertes Steuerungs- und Kontrollheimnetzwerk
DE69921342T2 (de) Verfahren und system zur elektronischen kommunikation
DE60119559T2 (de) Überbrückungssystem zur zusammenarbeit von entfernten gerätegruppen
US6052750A (en) Home audio/video network for generating default control parameters for devices coupled to the network, and replacing updated control parameters therewith
DE60029321T2 (de) Verfahren und vorrichtung zur fernbedienung eines hausnetzwerks von einem externen kommunikationsnetz
DE69737525T2 (de) Aufgabengesteuertes steuerungssystem für elektronische verbraucher
DE69813566T2 (de) Ein verfahren und eine vorrichtung zum versehen von geräten mit selbstbeschreibenden informationen
DE69819735T2 (de) Modell und befehlssatz für av/c-basierte untereinheit eines plattenwiedergabe-/-aufzeichnungsgeräts
DE69930534T2 (de) Szenarioandeutende Anrufe für Steuerung von Softwareobjekten mittels Eigenschaftsverbindungen
DE69838078T2 (de) Verfahren zum Steuern eines elektronischen Peripherie-Unterhaltungsgeräts
DE60303903T2 (de) Verfahren zur Erzeugung einer graphischen Benutzerschnittstelle auf einem HAVi Gerät für die Steuerung eines nicht HAVi Gerätes
US6963784B1 (en) Virtual device control modules and function control modules implemented in a home audio/video network
DE602004011517T2 (de) Einbetten einer upnp av mediaserverobjektidentifikation in einem uri
DE69829110T2 (de) Verfahren zur beschreibung der benutzerschnittstellenmerkmale und funktionalität von av/c-geräten
DE102005040924B3 (de) Verfahren zur Bereitstellung einer Bedienoberfläche zur Auswahl mindestens eines elektronischen Informations- und/oder Kommunikationsgerätes
DE60309518T2 (de) Kommunikationsgerät und Netzwerksystem mit einer schnellen digitalen Schnittstelle
DE19924795A1 (de) Netzwerk mit mehreren Terminals und einem auf allen Terminals verteilten Softwaresystem

Legal Events

Date Code Title Description
8364 No opposition during term of opposition