DE69836101T2 - Ein audio-video-gerät - Google Patents

Ein audio-video-gerät Download PDF

Info

Publication number
DE69836101T2
DE69836101T2 DE69836101T DE69836101T DE69836101T2 DE 69836101 T2 DE69836101 T2 DE 69836101T2 DE 69836101 T DE69836101 T DE 69836101T DE 69836101 T DE69836101 T DE 69836101T DE 69836101 T2 DE69836101 T2 DE 69836101T2
Authority
DE
Germany
Prior art keywords
layer
network
software module
control software
devices
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
DE69836101T
Other languages
English (en)
Other versions
DE69836101D1 (de
Inventor
J. Rodger San Jose LEA
Aaron Harold San Jose LUDKE
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 DE69836101D1 publication Critical patent/DE69836101D1/de
Application granted granted Critical
Publication of DE69836101T2 publication Critical patent/DE69836101T2/de
Anticipated expiration legal-status Critical
Expired - Lifetime legal-status Critical Current

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H04L12/2803—Home automation networks
    • H04L12/2807—Exchanging configuration information on appliance services in a home automation network
    • H04L12/281—Exchanging configuration information on appliance services in a home automation network indicating a format for calling an appliance service function in a home automation network
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/4401—Bootstrapping
    • G06F9/4411—Configuring for operating with peripheral devices; Loading of device drivers
    • 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/2803—Home automation networks
    • H04L2012/2847—Home automation networks characterised by the type of home appliance used
    • H04L2012/2849—Audio/video appliances

Description

  • GEBIET DER ERFINDUNG
  • Die vorliegende Erfindung betrifft das Gebiet der Audio-Video-Systeme. Die Erfindung bezieht sich insbesondere auf die Vernetzung einer Anzahl von elektronischen Geräten zum Aufbau eines Audio-Video-Systems. In einer ihrer Verkörperungen stellt die Erfindung ein Audio-/Video-Heimnetz mit 2-Schicht-Gerätesteuerung dar.
  • HINTERGRUND DER ERFINDUNG
  • Eine typische Anlage mit audiovisuellen Heimgeräten umfaßt eine Anzahl von Komponenten, z.B. einen Rundfunkempfänger, einen CD-Player, ein Lautsprecherpaar, einen Fernseher, einen Videorekorder, ein Bandgerät usw.. Alle diese Komponenten sind über einen Satz von Leitungen miteinander verbunden. Eine der Komponenten bildet üblicherweise die zentrale Komponente des audiovisuellen Heimsystems. In der Regel ist dies der Rundfunkempfänger oder der Tuner. Der Tuner besitzt eine Anzahl von spezifischen Eingängen für den Anschluß der anderen Komponenten. Dazu weist der Tuner eine entsprechende Zahl von Steuertasten und Steuerschaltern auf, die einen begrenzten Grad an Steuerbarkeit und Interoperabilität für die Komponenten ermöglichen. Die Steuertasten und Steuerschalter befinden sich normalerweise an der Frontseite des Tuners. In vielen Fällen sind einige oder alle diese Tasten und Schalter an einer Handfernsteuereinheit dupliziert. Der Benutzer steuert das audiovisuelle Heimsystem durch Betätigen der Tasten und Schalter an der Frontseite des Tuners oder alternativ durch Betätigen der Tasten der Handfernsteuereinheit.
  • Dieses herkömmliche Paradigma für audiovisuelle Heimsysteme wurde sehr populär. Da elektronische Consumergeräte immer leistungsfähiger und komplexer werden, ist die Nachfrage nach den neuesten und leistungsfähigsten Geräten größer geworden. Wenn neue Geräte auf den Markt kommen und populär werden, werden diese Geräte von den Konsumenten gekauft und an ihre audiovisuellen Heimsysteme "angeschlossen". Im allgemeinen sind die neuesten und komplexesten dieser Geräte (z.B. digitale Tonbandgeräte, DVD-Player, digitale Camcorder und dgl.) recht teuer. Wenn ein Konsument ein neues Gerät erwirbt, wird das neue Gerät meistens zusammen mit den bereits vorhandenen älteren Geräten (z.B. Kassettenrekorder, CD-Player und dgl.) in das System eingesteckt. Das neue Gerät wird in einen freien Eingang an der Rückseite des Tuners oder eines mit dem Tuner verbundenen anderen Geräts eingesteckt. Der Konsument (z.B. der Benutzer) steuert das neue Gerät über die Steuertasten an dem Tuner, über die Steuertasten und Steuerschalter an der Frontseite des neuen Geräts selbst oder über eine ganz neue separate Fernsteuereinheit für das neue Gerät.
  • Da die Zahl neuer elektronischer Consumergeräte für audiovisuelle Heimsysteme größer geworden ist und die technische Perfektion und die Fähigkeiten dieser Geräte zugenommen haben, entstehen mit dem herkömmlichen Paradigma eine Anzahl von Problemen. Eines dieser Probleme ist die Inkompatibilität zwischen Geräten in dem audiovisuellen Heimsystem. Elektronische Consumergeräte eines Herstellers werden häufig anders mit einem audiovisuellen System verbunden als ähnliche Geräte eines anderen Herstellers. So kann es vorkommen, daß ein von einem Hersteller hergestellter Tuner mit einem von einem anderen Hersteller hergestellten Fernseher nicht richtig zusammenpaßt.
  • Wenn ein Gerät sehr viel neuer ist als ein anderes Gerät, können darüber hinaus weitere Inkompatibilitäten existieren. So kann ein neues Gerät Hardware aufweisen (z.B. spezifische Eingänge und Ausgänge), die ausgeklügeltere Fernsteuerfunktionen ermöglicht. Dabei kann es vorkommen, daß diese Hardware nicht mit älteren Geräten innerhalb des Systems benutzt werden kann. Oder es kann vorkommen, daß ältere Tuner nicht über geeignete Eingänge für einige neuere Geräte (z.B. Minidisc-Player, Videorekorder usw.) verfügen oder nicht genug Eingänge für alle Geräte des Systems haben.
  • Ein anderes Problem ist der Mangel an funktioneller Unterstützung für unterschiedliche Geräte innerhalb eines audiovisuellen Systems. So kann es z.B. vorkommen, daß ein Fernseher fortschrittliche Tonformate (z.B. Surroundklang, Stereo usw.) unterstützen kann, daß die Vorteile dieser fortschrittlichen Tonformate jedoch verlorengehen können, wenn diese Funktionalität von einem älteren Tuner, der weniger leistungsfähig ist, nicht untertützt wird. Ein anderes Problem besteht in der ausufernden Zunahme von Steuerungen für die neuen und die anderen Geräte innerhalb des audiovisuellen Heimsystems. So können z.B. ähnliche Geräte von verschiedenen Herstellern jeweils unterschiedliche Steuertasten- und Steuerschalterformate für die Erfüllung ähnlicher Aufgaben haben (Einstellen der Uhr an einem Videorekorder, Programmieren eines Videorekorders für die Aufzeichnung eines späteren Programms und dgl.). Außerdem führt jedes neue Gerät, das mit dem audiovisuellen System verbunden wird, häufig zu einer anderen dedizierten Fernsteuereinheit, wobei der Benutzer die Übersicht behalten und deren Bedienung erlernen muß.
  • Die Literaturstelle Child S.: "Intelligent home technology looks for leverage from related markets" Computer Design, Band 36, Nr. 12, 1. Dezember 1997, Seiten 85 bis 87, offenbart Heim-Technologie.
  • Während das Auftauchen von Vernetzungs- und Schnittstellentechnologie (z.B. der serielle IEEE-1394-Kommunikationsbus und die weit verbreitete Anwendung von digitalen Systemen) Aussichten zur Lösung dieser Probleme bietet, gibt es noch nicht kohärente, offene, erweiterbare Architektur, die intelligente, selbstkonfigurierende, leicht erweiterbare Geräte oder AV-Systeme zur Verfügung stellen kann. Während z.B. verschiedene Lösungen die Benutzung von IEEE 1394 als Basis eines AV-Systems involvieren, gibt es keine Lösung, die die Erweiterbarkeit des AV-Systems über seine ganze Lebensdauer vorsieht, wenn neue Geräte mit noch unbekannten Fähigkeiten und Merkmale hinzugefügt werden. Keines dieser Systeme gewährleistet, daß mit allen Geräten kommuniziert werden kann und daß der Benutzer sie steuern und genießen kann.
  • ZUSAMMENFASSUNG DER ERFINDUNG
  • Es wird also eine neue Architektur für ein audiovisuelles Heimsystem gefordert, das die Interoperabilitäts- und Funktionalitätsprobleme des herkömmlichen Systems korrigiert. Es wird neue Architektur für ein offenes, interoperables audiovisuelles System für Geräte innerhalb eines Heimnetzes gefordert. Es wird eine Architektur gefordert, die es ermöglicht, daß Geräte eines beliebigen Herstellers nahtlos mit einem audiovisuellen Heimsystem funktionieren. Es wird eine Architektur gefordert, die erweiterbar ist und leicht modifiziert und fortentwickelt werden kann, wenn die Markterfordernisse und die Technologie sich ändern.
  • Die vorliegende Erfindung sieht ein audiovisuelles (AV)-Heimnetz vor, das eine offene Architektur für miteinander operierende elektronische Consumergeräte (CE-Geräte) in einem Heimnetz definiert. Die Interoperabilitätsaspekte der vorliegenden Erfindung definieren ein Architekturmodell, das es CE-Geräten eines Herstellers ermöglicht, innerhalb des AV-Heimsystems des Benutzers nahtlos zu interoperieren und zu funktionieren. Das System gemäß der Erfindung enthält eine Kombination aus einem Basissatz von generischen Gerätesteuerungen mit einem Verfahren zur Erweiterung eines Basis-Steuerprotokolls, wenn neue Merkmale und neue CE-Geräte in das AV-Heimnetz integriert werden. Dadurch ist die Architektur der vorliegenden Erfindung erweiterbar und kann leicht modifiziert und fortentwickelt werden, wenn die Markterfordernisse und die Technologie sich ändern.
  • Für die Implementierung der obigen Merkmale umfaßt die vorliegende Erfindung eine Architektur, die es ermöglicht, das neu angeschlossene Gerät abzufragen. Unter Verwendung der Abfrageergebnisse wird eine softwarebasierte Abstraktion des Geräts erzeugt und anderen Elementen in dem Netz zur Verfügung gestellt. Die Software-Abstraktion wird als Gerätesteuermodul bezeichnet. Das Gerätesteuermodul liefert einen vorbestimmten stan dardisierten Satz an Interoperabilität, Funktionalität und Steuerschnittstellen für das Gerät. Das CE-Gerät wird mit dem Heimnetz verbunden und kommuniziert mit diesem über ein Gerätesteuermodul. Jedes CE-Gerät in dem AV-Heimnetz besitzt ein entsprechendes Gerätesteuermodul (DCM) [device control modul]. Das DCM gemäß vorliegender Erfindung sieht auch ein Anwendungsprogrammier-Interface (API) vor, um es anderen Anwendungen zu ermöglichen, auf ein neu angeschlossenes CE-Gerät zuzugreifen und dieses zu handhaben.
  • Wenn neue Geräte hinzugefügt werden, deren Fähigkeiten und Merkmale anderen Geräten nicht oder nur teilweise bekannt sind, wird durch die DCMs der vorliegenden Erfindung über die Lebensdauer des AV-Systems, ein Mechanismus bereitgestellt, der gewährleistet, daß mit allen Geräten auf einer minimalen Basisschicht kommuniziert und diese Geräte gesteuert werden können und dann, wo dies möglich ist, eine bessere Abstraktion des neuen Geräts erzeugt wird, wenn mehr Informationen über das Gerät gewonnen werden.
  • Wenn ein neues Gerät an ein AV-Heimsystem angeschlossen wird, wird gemäß einem Ausführungsbeispiel der Erfindung automatisch ein (als Schicht 1 bezeichnetes) Vorgabe-DCM für das neue Gerät generiert. Ein Gerätemanager (z.B. ein softwarebasiertes Steuerobjekt), der auf einem der Geräte in dem AV-System ausgeführt wird, ermittelt automatisch die Basiseigenschaften des Geräts, kategorisiert das Gerät in eine Klasse (die z.B. gemeinsamen Merkmale aufweist) und initialisiert ein (dieser Geräteklasse entsprechendes) generisches oder ein Vorgabe-DCM für das Gerät. Dadurch stellt das Schicht-1-DCM der vorliegenden Erfindung sicher, daß das System unabhängig davon, welches Gerät hinzugefügt wird, in der Lage ist, eine Basisschicht-(z.B. eine Schicht-1)-Gerätesteuerung zu erzeugen und die Fähigkeiten des Geräts für andere Teile des Systems und den Benutzer verfügbar zu machen.
  • Wenn sich während dieser Initialisierungsphase herausstellt, daß das Gerät einen Pseudocode oder einen Verweis zu einem Pseudocode enthält, der ein fähigeres oder höherentwickeltes DCM für das Gerät implementiert, ruft der Gerätemanager den Pseudocode ab und initialisiert auf der Basis des Pseudocodes ein DCM. Dieses wird als Schicht-2-DCM bezeichnet. Da in diesem Fall ein solcher Pseudocode typischerweise von dem Gerätehersteller zur Verfügung gestellt wird und deshalb mit der Hardware des Geräts enger vertraut ist, kann er eine bessere Software-Abstraktion der Fähigkeiten des Geräts anbieten. In Abhängigkeit von den in dem AV-System enthaltenen Geräten wird eines der DCMs, oder es werden beide DCMs initialisiert und instantiiert.
  • Indem das System gemäß der Erfindung sowohl das Schicht-1-DCM als auch das Schicht-2-DCM der vorliegenden Erfindung verfügbar macht, stellt es sicher, daß beliebige neue Geräte, die zu dem einen Netz hinzugefügt werden, für Anwendungen, Systemsoftware und den Benutzer nahtlos und einfach zur Verfügung gestellt werden. Indem man so verfährt, liefert die vorliegende Erfindung einen extrem flexiblen Mechanismus, der sicherstellt, daß neue Geräte nicht nur Teil des AV-Systems werden, sondern daß sie auf auch in Abhängigkeit von den Fähigkeiten der anderen Geräte in dem AV-System auf unterschiedliche Weise zugegriffen werden kann.
  • KURZBESCHREIBUNG DER ZEICHNUNGEN
  • Anhand der Figuren der anliegenden Zeichnungen, in denen für ähnliche Elemente gleiche Bezugszeichen benutzt werden, wird die Erfindung beispielhaft erläutert, ohne daß dies eine Einschränkung darstellt.
  • 1A zeigt ein Heim-AV-Netz nach einem Ausführungsbeispiel der Erfindung,
  • 1B zeigt eine logische Buskonfiguration des HAVI-Netzes von 1A,
  • 2 zeigt ein exemplarisches Peer-to-Peer-Netz mit zwei IAV-(intermediate audio video)-Knoten nach einem Ausführungsbeispiel der Erfindung
  • 3 zeigt ein HAVI-Netz mit einem einzigen FAV-(full audio video)-Cluster nach einem Ausführungsbeispiel der Erfindung,
  • 4 zeigt einem mit einem IAV-Peer-to-Peer-HAVI-Netz integrierten FAV-Cluster,
  • 5 zeigt ein exemplarisches HAVI-Netz mit mehreren FAVs,
  • 6 zeigt ein Diagramm einer Set-Top-Box nach einem Ausführungsbeispiel der Erfindung,
  • 7 zeigt ein logisches Blockdiagramm eines Ausführungsbeispiels der HAVI-Architektur gemäß vorliegender Erfindung,
  • 8 zeigt ein logisches Schicht-Diagramm einer HAVI-Architektur gemäß der Erfindung,
  • 9 zeigt ein Diagramm von lokalen und entfernten Meldungen in der HAVI-Architektur eines Ausführungsbeispiels,
  • 10 zeigt ein Diagramm einer Nachricht, die über 1394 in der HAVI-Architektur eines Ausführungsbeispiels gesendet wird,
  • 11 zeigt ein Diagramm einer Anwendung, die eine andere Anwendung aufruft, in einem Ausführungsbeispiel der HAVI-Architektur,
  • 12A zeigt eine erste exemplarische UI-[user interface]-Anzeige (z.B. auf einem Fernsehbildschirm) für ein Gerät (z.B. den Camcorder),
  • 12B zeigt eine zweite exemplarische UI-Anzeige (z.B. auf einem Fernsehbildschirm) für ein Gerät (z.B. den Camcorder),
  • 13 zeigt ein Flußdiagramm eines Prozesses für die Bereitstellung einer nahtlosen Interoperabilität und die Integration mehrerer Geräte in einem HAVI-Netz durch Verwenden der in jedem Gerät gespeicherten SDD-Information nach einem Ausführungsbeispiel der Erfindung,
  • 14 zeigt ein Flußdiagramm eines Prozesses für die Bereitstellung einer Grund-Befehlsfunktionalität und einer erweiterten Befehlsfunktionalität zwischen mehreren Geräten in einem HAVI-Netz nach einem Ausführungsbeispiel der Erfindung,
  • 15 zeigt ein Flußdiagramm eines Prozesses für die Sicherstellung zukünftiger Aufwertbarkeit und Erweiterbarkeit von Geräten in einem HAVI-Netz nach einem Ausführungsbeispiel der Erfindung,
  • 16 zeigt ein Flußdiagramm eines Prozesses für die Bereitstellung von nahtloser Interoperabilität und Integration von Legacy-Geräten mit den HAVI-konformen Geräten in einem HAVI-Netz nach einem Ausführungsbeispiel der Erfindung,
  • 17A zeigt ein Flußdiagramm eines Prozesses für die Steuerung von Geräten in einem Heim-Audio-/-Videonetz unter Verwendung eines Anwendungsprogramms aus einem externen Service-Provider nach einem Ausführungsbeispiel der Erfindung,
  • 17B zeigt ein Diagramm eines HAVI-Netzes mit einem Service-Provider entsprechend dem Prozeß von 17A.
  • DETAILLIERTE BESCHREIBUNG DER ERFINDUNG
  • Es wird nun detailliert auf die Ausführungsbeispiele der Erfindung Bezug genommen, von denen Beispiele in den anliegenden Zeichnungen dargestellt sind. Obwohl die Erfindung in Verbindung mit den bevorzugten Ausführungsbeispielen beschrieben wird, soll die Erfindung nicht auf diese Ausführungsbeispiele beschränkt sein. Die Erfindung soll im Gegenteil Alternativen, Modifizierungen und Äquivalente abdecken, die in dem Geist und Rahmen der Erfindung enthalten sein können, wie diese in den anliegenden Ansprüchen definiert ist. Darüber hinaus sind in der folgenden detaillierten Beschreibung der Erfindung zahlreiche spezifische Details ausgeführt, um ein durchgehendes Verständnis der Erfindung zu ermöglichen. Es ist für den einschlägigen Fachmann jedoch offensichtlich, daß die Erfindung auch ohne diese spezifischen Detail praktiziert werden kann. In anderen Fällen wurden allgemein bekannte Verfahren, Prozeduren, Komponenten und Schaltungen nicht detailliert beschrieben, um Aspekte der vorliegenden Erfindung nicht unnötig zu verdunkeln.
  • Die vorliegende Erfindung liefert ein Heim-AV-Netz, das eine offene Architektur für die Interoperation von CE-[consumer electronics]-Geräten in einem Heimnetz definiert. Die Interoperabilitäts-Aspekte der Erfindung definieren ein Architekturmodell, das es CE-Geräten von einem Hersteller ermöglicht, innerhalb des Heim-AV-Systems des Benutzers zu interoperieren und nahtlos zu funktionieren. Das System gemäß der Erfindung umfaßt eine Kombination aus einer Basisgruppe von allgemeinen Gerätesteuerungen mit einem Verfahren zur Erweiterung eines Basis-Steuerprotokolls, wenn neue Merkmale und neue CE-Geräte in dem Heim-AV-Netz benutzt werden. Dadurch ist die Architektur der vorliegenden Erfindung erweiterbar und kann leicht modifiziert und fortentwickelt werden, wenn sich die Markterfordernisse und die Technologie ändern. Die vorliegende Erfindung und ihre Vorteile werden im folgenden näher beschrieben.
  • NOTATION UND NOMENKLATUR
  • Einige Abschnitte der ausführlichen Beschreibungen, die nun folgen, werden in Form von Prozeduren, Schritten, logischen Blöcken, Verarbeitungen und anderen symbolischen Darstellungen von Operationen an Datenbits in einem Computerspeicher (siehe 2) dargestellt. Diese Beschreibungen und Darstellungen sind das Mittel, das von dem einschlägigen Fachmann auf dem Gebiet der Datenverarbeitung benutzt wird, um anderen Fachleuten die Substanz seiner Arbeit am effektivsten zu übermitteln. Eine Prozedur, ein von einem Computer ausgeführter Schritt, ein logischer Block, ein Prozeß usw. werden hier und allgemein als selbstkonsistente Sequenz von Schritten oder Instruktionen aufgefaßt, die zu einem gewünschten Ergebnis führen. Die Schritte sind solche, die physikalische Manipulationen von physikalischen Größen erfordern. Diese Größen nehmen im allgemeinen, jedoch nicht notwendigerweise, die Form von elektrischen oder magnetischen Signalen an, die gespeichert, übertragen, kombiniert, verglichen und anderweitig in einem Computersystem manipuliert werden können. Es hat sich mitunter, hauptsächlich zum Zweck des allgemeinen Gebrauchs, als praktisch herausgestellt, diese Signale als Bits, Werte, Elemente, Symbole, Zeichen, Ausdrücke, Zahlen oder dgl. zu bezeichnen.
  • Es ist jedoch zu bedenken, daß alle diese und ähnliche Ausdrücke den passenden physikalischen Größen zuzuordnen sind und lediglich bequeme Etiketten bilden, die diesen Größen angeheftet werden. Falls die folgenden Diskussionen nicht ausdrücklich anderes nahelegen, beziehen sich Diskussionen, die Ausdrücke wie "Verarbeiten" oder "Rechnen" oder "Übersetzen" oder "Instantiieren" oder "Festlegen" oder "Anzeigen" oder "Erkennen" oder dgl. benutzen, auf die Aktion und Prozesse eines Computersystems oder eines ähnlichen elektronischen Rechners, die Daten, die in Registern und Speichern des Computers als physikalische (elektronische) Größen dargestellt werden, in andere Daten manipulieren und transformieren, die ähnlich in Speichern oder Registern oder anderen Informationsspeicher-, Übertragungs- oder Anzeigevorrichtungen des Computersystems als physikalische Größen repräsentiert werden.
  • ÜBERBLICK ÜBER DIE ARCHITEKTUR
  • Die Architektur der vorliegenden Erfindung ermöglicht die Schaffung eines Heim-AV-Systems, das eine nahtlose Unterstützung neuer Geräte und eine problemlose Interoperabilität von Geräten in einem Heim-AV-Netz erlaubt. Die Grundkomponenten eines Systems gemäß vorliegender Erfindung sind eine Heim-AV-Interoperabilitäts-Architektur, eine Reihe von Heim-AV-Interoperabilitäts-Interfaces und ein Heim-AV-Netz. Die Heim-AV-Interoperabilitäts-Architektur ist ein breiter übergreifender Ausdruck, der das physikalische Netz und die steuernden Programmierungs-Interfaces umfaßt. Interoperabilitäts-Interfaces ist ein Ausdruck, der zur Beschreibung der Interaktionen und Interfaces der Komponenten der AV-Architektur benutzt wird. Zusätzlich zu der Bereitstellung eines gemeinsamen Befehlssatzes liefern die Interoperabilitäts-Interfaces eine Software-Architektur, die es ermöglicht, neue Geräte in das Netz zu integrieren und ihre Dienste nahtlos zur Verfügung zu stellen. Das Heim-AV-Netz ist der Ausdruck, der zur Beschreibung des physikalischen Netzes und seiner Topologie benutzt wird.
  • Es ist zu beachten, daß die Heim-AV-Interoperabilitäts-(HAVI)-Architektur der vorliegenden Erfindung ein offenes, plattformunabhängiges, architekturneutrales Netz ist, das es den Herstellern und Produzenten von elektronischen Consumer-Geräten ermöglicht, interoperable Einrichtungen zu liefern. Sie kann auf unterschiedlichen Hardware-/Softwareplattformen implementiert sein und beinhaltet keine Merkmale, die für irgendeine der Plattformen ausschließlich gelten. Die Interoperabilitäts-Interfaces der HAVI-Architektur sind erweiterbar und können hinzugefügt, modifiziert und fortgebildet werden, wenn sich die Marktanforderungen und die Technologie ändern. Sie liefern die Infrastruktur für die Steuerung des Routings und die Verarbeitung von isochronen und zeitsensitiven Daten (z.B. von Audio- und Videoinhalten).
  • Die HAVI-Architektur sieht speziell eine Ausführungs-Umgebung vor, die die visuelle Darstellung und Steuerung von Einrichtungen unterstützt, ferner Anwendungs- und Systemdienste sowie Kommunikationsmechanismen für die dynamische Erweiterung der Umgebung durch einfaches Einstecken (plug and play) oder anderweitig.
  • Es ist zu beachten, daß die HAVI-Architektur Legacy-Einrichtungen unterstützt, (z.B. Einrichtungen, die bereits existieren und für Benutzer verfügbar sind). Dies ist wichtig, weil der Übergang zu intelligenteren netzwerkfähigen Einrichtungen langsam vonstatten geht. Die meisten Hersteller beginnen nicht plötzlich, ausschließlich "intelligente" Einrichtungen zu produzieren, und die meisten Consumer beginnen nicht schnell damit, ihre sämtlichen vorhandenen Einrichtungen zu ersetzen.
  • Gemäß vorliegender Erfindung gibt es zwei Klassen von Legacy-Einrichtungen. Eine erste Klasse umfaßt "Einwege"- oder Einrichtungen mit Steuerung ohne Quittungsgabe. Eine zweite Klasse umfaßt steuerbare "Zweiwege"-Einrichtungen. Beispiele für Einwege-Einrichtungen sind Audio-/Videokomponenten, die durch Infrarotbefehle einer Handfernsteuerung gesteuert werden. Zweiwege-Einrichtungen sehen eine Quittierung der Befehlausführung, Status- und Fehlerbericht vor. Beispiele für Zweiwege-Einrichtungen umfassen die in jüngerer Zeit erfolgte Einführung bekannter IEEE-1394-fähiger digitaler Kameras.
  • Es ist zu beachten, daß das Heim-AV-Netz (im folgenden HAVI-Netz) gemäß der Erfindung die Unterstützung zur Anpassung zukünftiger Einrichtungen und Protokolle durch eine gemeinsame Sprache vorsieht, die einmal geschrieben wird und überall läuft [writeonce, run-everywhere]. Gemäß vorliegender Erfindung enthält jede Einrichtung eine selbstbeschreibende Information, die das Benutzer-Interface und die Gerätesteuerung betrifft und von einer externen Steuereinrichtung benutzt werden kann. Diese Information ist in Form von Programmen in der gemeinsamen Sprache spezifiziert.
  • Wie weiter unten beschrieben wird, besteht die untere Struktur für ein solches Netz aus einem Satz von miteinander verbundenen Clustern von Einrichtungen. In dem Heim befinden sich üblicherweise mehrere Cluster und zwar einer pro Stockwerk oder pro Raum. Jeder Cluster arbeitet als eine Gruppe von miteinander verbundenen Geräten, um den Benutzern eine Gruppe von Diensten zur Verfügung zu stellen. Häufig arbeitet ein Gerät als Steuereinrichtung für eine Gruppe von anderen Geräten. Die Architektur ist jedoch hinreichend flexibel, so daß ein Heim auch aus einem einzigen Cluster ohne Hauptsteuerung bestehen kann.
  • In einem Ausführungsbeispiel der vorliegenden Erfindung kann z.B. ein intelligenter Fernseher im Wohnzimmer des Benutzers als Steuereinrichtung für eine Anzahl von miteinander verbundenen Einrichtungen fungieren. Jede der gesteuerten Einrichtungen besitzt selbstbeschreibende Daten und möglicherweise einen zugeordneten Steuercode. Wenn diese Einrichtungen erstmalig verbunden werden, erhält die Steuereinrichtung das Benutzer-Interface und das Steuerprogramm für die Einrichtung. Auf dem Fernsehschirm kann dann ein Icon erscheinen, das die Einrichtung repräsentiert, und das Manipulieren des Icons kann dazu führen, daß Elemente des Steuerprogramms die dargestellte Einrichtung oder die Einrichtungen in der vorgeschriebenen Weise aktivieren. Eine Ausnahme zu diesem Modell bilden Legacy-Geräte, die weder selbstbeschreibende Daten noch einen Steuercode haben. Für zusätzliche Beschreibungen und den Stand der Technik zu selbstbeschreibenden Daten wird verwiesen auf Ludtke, et al., A METHOD AND APPARATUS FOR INCLUDING SELF-DESCRIBING INFORMATION WITHIN DEVICES, provisional application Nr. 60/054,327, eingereicht am 31. Juli 1997.
  • Es ist zu beachten, daß das HAVI-Netz gemäß vorliegender Erfindung "Plug and Play"-Consumer-Geräte unterstützt, die leicht zu installieren sind und einen erheblichen Teil ihres Werts für den Consumer zur Verfügung stellen, ohne daß der Benutzers über das physikalische Verbinden der Kabel hinaus irgendeine Aktion vornehmen muß. Dies bildet den Unterschied zu existierenden Einrichtungen, die ein Konfigurieren erfordern, um den größeren Teil ihrer Funktionalität zur Verfügung zu stellen. Das Ziel besteht darin, "heißes" Plug and Play anzubieten (bei dem der Benutzer keine Geräte ausschalten muß), das von dem Verbindungsverfahren sicher und zuverlässig unterstützt wird.
  • Gemäß vorliegender Erfindung konfiguriert eine Einrichtung sich selbst und integriert ohne Eingreifen des Benutzers ein systemweites "Look-and-Feel"-Benutzer-Interface. Einfache Kommunikationsdienste liefern eine Notifizierung, wenn eine neue Einrichtung in dem AV-Netz identifiziert wird. Obwohl es häufig Einstellungen gibt, die von dem Benutzer zur Anpassung an seine Präferenzen geändert werden können, erfordert die Einrichtung nicht, daß der Benutzer so verfährt, um ihre Grundfunktionalität zu erfüllen.
  • Es ist auch zu beachten, daß das HAVI-Netz der vorliegenden Erfindung flexibel ist und Mehrfach-Benutzer-Interfaces unterstützt, die sich sowohl an die Erfordernisse des Benutzers als auch an die Forderung der Hersteller zur Markendifferenzierung anpassen. In dem AV-Netz reichen die Protokolle von ressourcenreichen, intelligenten PC-artigen Einrichtungen bis zu "dummen", mit wenigen Ressourcen ausgestatteten Einrichtungen (z.B. Kaffeemaschinen oder Thermostaten). Um dies zu erreichen, ermöglicht die AV-Architektur, daß einfache Einrichtungen in wohldefinierter Weise die Ressourcen von intelligenten Einrichtungen nutzen. In ähnlicher Weise ermöglicht die AV-Architektur die Spezifizierung von Zusammenstellungen von Einrichtungen, bei denen aus einer logischen Sammlung von verschiedenen einfachen Einrichtungen eine abstrakte Einrichtung erzeugt wird.
  • Zusätzlich sollte beachtet werden, daß das HAVI-Netz der vorliegenden Erfindung existierende Standards unterstützt. Das HAVI-Netz ist zu verschiedenen existierenden, allgemein bekannten Industriestandards und Technologien komplementär, einschließlich CEBus; Home Plug and Play; EHSI; VESA; Heim-Netz, DAVIC, CoMMeND, Lonworks, USB, IEEE1394 usw. Es ist dementsprechend ein Ziel der vorliegenden Erfindung, eine Infrastruktur bereitzustellen, in die existierende Vorrichtungen eingepaßt werden können.
  • DAS SYSTEMMODELL DER HAVI-ARCHITEKTUR
  • Es sei nun auf 1A Bezug genommen, in der ein HAVI-Netz 10a gemäß einem Ausführungsbeispiel der Erfindung dargestellt ist. Wie oben beschrieben wurde, unterstützt die HAVI-Architektur einen großen Bereich von Geräten, einschließlich intelligenter Empfän ger/Dekodierer (IRDs), z.B. der Set-Top-Box 301, digitaler Videorekorder (DVTRs), Videorekorder (VCRs), Personalcomputer (PCs), Abspielgeräte für digitale Videoplatten (DVDs) usw., die über ein gemeinsames Nachrichtensystem miteinander kommunizieren. 1A zeigt die physikalische Anschluß-zu-Anschluß-Verbindungskonfiguration 10a eines exemplarischen HAVI-Netzes. Es sind CE-Geräte ("Geräte") 12 bis 24 dargestellt, die über Bus-Segmente 30a bis 30f miteinander verbunden sind. In einem HAVI-Ausführungsbeispiel wird der serielle IEEE-1394-Kommunikationsbus-Standard als Plattform benutzt, die das gemeinsame Nachrichtensystem zur Verfügung stellt.
  • 1B zeigt eine logische Buskonfiguration 10b des HAVI-Netzes von 1A. Wie in 1B dargestellt, können alle Geräte 12 bis 24 des HAVI-Netzes so betrachtet werden, daß sie logisch mit einem gemeinsamen seriellen IEEE-1394-Kommunikationsbus 30 verbunden sind. Innerhalb dieser Buskonfiguration 10b wird eine Peer-to-Peer-Gerätekommunikation unterstützt. So kann z.B., wie in 1C dargestellt, ein Gerät (das die passenden Fähigkeiten besitzt), z.B. das Gerät 12, Kommunikationspakete zu einem anderen Gerät in dem HAVI-Netz senden oder von diesem empfangen. In dem Beispiel von 1B kann die Set-Top-Box (z.B. ein IRD) Nachrichten von irgendeinem der anderen Geräte 14 bis 24 des HAVI-Netzes empfangen oder Nachrichten für diese erzeugen.
  • Es sei weiterhin auf 1A und 1B Bezug genommen. Wie oben beschrieben wurde, sieht das Interoperabilitäts-Modell in HAVI folgendes vor: 1) Unterstützung für existierende Geräte; 2) ein Default-[Vorgabe]-Steuermodell; 3) ein Mittel zur Erweiterung des Default-Steuermodells, wenn neue Geräte oder eine neue Funktionalität auf den Markt gebracht wird; und 4) ein gemeinsames Mittel für die Gerätedarstellung (z.B. graphische Benutzer-Interfaces). Um dies zu erreichen, definiert die HAVI-Architektur drei Typen von Knoten in dem Heim-Netz, nämlich den Voll-AV-Knoten (FAV), den Zwischen-AV-Knoten (IAV) und den Basis-AV-Knoten (BAV).
  • Ein Voll-AV-Knoten ist eine Vorrichtung, die ein komplettes Beispiel des (weiter unten näher erläuterten) AV-Softwaremodells enthält. Diese Art von Knoten besitzt im allgemeinen einen umfangreicheren Satz von Ressourcen und kann eine komplexe Software-Umgebung unterstützen. Das primäre Unterscheidungsmerkmal eines FAV besteht darin, daß er die Steuerverantwortung für weniger hochentwickelte Geräte übernehmen kann und dies dadurch tut, daß er üblicherweise von den weniger hochentwickelten Gerät ein Steuermodul lädt und dieses lokal ausführt. Beispiele für solche Knoten sind Set-Top-Boxen (z.B. die Set-Top-Box 301), intelligente Fernsehgeräte, universelle Heim-Steuervorrichtungen oder auch Heim-PCs.
  • Zwischen-AV-Knoten sind im allgemeinen kostengünstigere Geräte mit begrenzten Ressourcen. Sie sehen keine Umgebung für die Ausführung von Steuermodulen vor und können so innerhalb des Heim-Netzes nicht als Hauptsteuerung agieren. Da sie begrenzte Ressourcen haben, können sie auf eine von zwei Arten auf entfernte Ressourcen zugreifen, nämlich durch Zusammenarbeit mit anderen IAV-Geräten, die gewisse Fähigkeiten besitzen, die ihnen selbst fehlen, oder durch Benutzung eines FAV-Knotens, der ein Steuermodul unterstützt, um sie zu steuern. Bei dieser zweiten Betriebsart verlassen sie sich auf Voll-AV-Knoten, um solche Möglichkeiten zur Verfügung zu stellen, wie eine Anzeigevorrichtung, universelle Rechen-Ressourcen oder einen Rahmen für die Gesamtsteuerung. Dadurch sind Voll-AV-Geräten in der Lage, eine Vielfalt von Zwischen-AV-Geräten miteinander zu verbinden, um dem Benutzer einen Service oder eine Abstraktion zu bieten.
  • Basis-Knoten sind Knoten, die weder FAV- noch IAV-Knoten sind. Es gibt zwei allgemeine Typen, nämlich Legacy-Basisknoten und andere Basisknoten. Legacy-Basisknoten sind Geräte, die vor dem Aufkommen der HAVI-Architektur hergestellt wurden. Diese Geräte benutzen oft eigene Protokolle für Ihre Steuerung und haben sehr häufig ein einfaches, wohldefiniertes Protokoll ausschließlich für die Steuerung. Solche Geräte können in dem HAVI-Netz arbeiten, machen es jedoch erforderlich, daß ein Voll-AV-Knoten als Gateway agiert. Die Kommunikation zwischen einem Voll- oder Zwischen-AV-Knoten und Legacy-Geräten macht es erforderlich, daß die in der HAVI-Architektur benutzten Heim-AV-Befehle in das und aus dem Legacy-Befehlsprotokoll übersetzt werden. Andere Basisknoten sind Geräte, die aus Geschäfts- oder Ressourcengründen zukunftsfähiges Verhalten implementieren, indem sie heraufladbare Steuersoftware benutzen, und unterstützen weder die HAVI-Architektur noch das Nachrichtenkommunikationssystem. Diese Geräte werden von einem FAV-Knoten mit einem privaten Befehlsprotokoll zwischen FAV- und BAV-Knoten gesteuert.
  • Mit Ausnahme von Legacy-Knoten besitzt jeder Knoten zumindest genügend Funktionalität, die es ihm erlaubt, mit anderen Knoten in dem System zu kommunizieren. Im Verlauf einer Interaktion tauschen Knoten Steuer- und Dateninformationen aus, um zusammenzuarbeiten, und tun dies peer-to-peer. Dadurch ist sichergestellt, daß kein einziges Gerät in der Kommunikationsschicht als Master oder Steuerung für das System agieren muß. Es erlaubt jedoch auch, daß ein logischer Master oder eine logische Steuerung dem grundlegenden Peer-to-Peer-Kommunikationsmodell eine Steuerstruktur aufprägt. In dem HAVI-Netz werden Dienste von einem oder mehreren Knoten zur Verfügung gestellt, die untereinander kommunizieren, um dem Benutzer einen Service oder eine Anwendung zu liefern. Wenn ein Knoten mit einem Benutzer interagieren muß, verhandelt der Knoten mit anderen Knoten über den Zugriff auf die und die Benutzung der Anzeigevorrichtung.
  • Außerdem ist zu beachten, daß eine Unterscheidung zwischen logischen und physikalischen Knoten getroffen ist. Ein gutes Beispiel für diese Unterscheidung findet sich in einem normalen Fernsehgerät. Obwohl das Fernsehgerät im allgemeinen eine einzige physikalische Box ist, enthält es mehrere funktionelle Komponenten, z.B. den Tuner, den Audioausgang usw. Vom Standpunkt des Systems aus ist ein physikalischer Knoten ein adressierbarer Peer-Knoten in dem System. Falls der Fernseher so konstruiert ist, daß seine einzelnen funktionalen Komponenten individuell adressierbar sind, bildet er logisch einen einzigen Knoten und physikalisch mehrere Knoten. Wenn er umgekehrt so konstruiert ist, daß er eine einzige adressierbare Entität besitzt, bildet er sowohl einen einzigen logischen Knoten als auch einen einzigen physikalischen Knoten.
  • Die IAV-Geräte und FAV-Geräte kommunizieren, indem sie Nachrichten über das Heim-Netz senden, wobei sie ein allgemeines System zur Weitergabe von Nachrichten benutzen. Wenn neue Geräte zu dem Heim-Netz hinzukommen, werden sie erkannt und zu einer globalen Namen-Datenbank hinzugefügt (Registrierung). Die Registrierung speichert Informationen über ihre Eigenschaften und verschafft dem Steuerungsprogramm [Handler] eine Referenz für dieses Gerät. Andere Geräte und Dienste können die Registrierung abfragen, um ein Gerät zu lokalisieren und dann das Steuerungsprogramm zu benutzen, und können mit dem Gerät interagieren. Für zusätzliche Beschreibungen und den Stand der Technik bezüglich der Kommunikations- und Identifizierungsprozesse der vorliegenden Erfindung wird auf Ogino, et al., "METHOD AND SYSTEM FOR PROVIDING A DEVICE IDENTIFICATION MECHANISM WITHIN A CONSUMER AUDIO/VIDEO NETWORK", eine US-Patentanmeldung, eingereicht am 6. Januar 1998, verwiesen.
  • Wenn ein Gerät neu zu dem Heim-Netz hinzugefügt wird, fragt das System das Gerät ab, um seine Eigenschaften und Fähigkeiten zu bestimmen. Sobald die Eigenschaften eines Geräts bekannt sind, stellt die Architektur zwei Methoden zu seiner Steuerung zur Verfügung. Die erste Methode, die Schicht-1-Interoperatibilität, benutzt einen vordefinierten Nachrichtensatz. Alle IAV- und FAV-Knoten können diesen Befehlssatz benutzen, um auf andere Geräte zuzugreifen und diese zu steuern (BAV-Knoten werden mit Hilfe von Legacy-Protokollen gesteuert, weil sie entwickelt wurden, bevor die Architektur definiert wurde). Diese Methode liefert eine Steuer-Default-Schicht. Die FAV-Knoten arbeiten als Steuerknoten und erzeugen eine lokale Darstellung des IAV-Knotens, der als Geräte-Steuermodul (DCM) bekannt ist, das eine API liefert, die zum Senden von Steuerbefehlen an das Gerät benutzt wird.
  • Die Schicht-2-Interoperabilität innerhalb eines HAVI-Netzes geht weiter und unterstützt auch hinzugefügte zukünftige Funktionalität und neue Geräte. Um dies zu erreichen, kann ein spezielles Gerät in seinem ROM ein Override-DCM enthalten, das von dem IAV-Gerät in das FAV-Gerät heraufgeladen wird und das Default-DCM für das spezielle Gerät ersetzt. Dieses Override-DCM enthält nicht nur den grundlegenden Schicht-1-Befehlssatz für das spezielle Gerät, sondern auch zuliefererspezifische Befehle, um fortschrittliche Merkmale des Geräts zu steuern. Das Modell ermöglicht es dem Gerät, ein anderes über seine spezielle Funktionalität zu informieren. Da das Override-DCM in das FAV eines beliebigen Zulieferers geladen werden kann, ist das Format des DCM architekturneutral.
  • Um es einem Gerät zu ermöglichen, die Fähigkeiten eines anderen Geräts zu entdecken und festzulegen, welcher Befehlssatz mit diesem Gerät benutzt werden muß, ist eine Standard-Gerätebeschreibungsstruktur vorgesehen, die als selbstbeschreibende Daten-(SDD)-Struktur bezeichnet wird. Die SDD-Datenstruktur ist erweiterbar. Sie kann aus einer kleinen Zahl von Bytes bestehen, die den Gerätetyp, z.B. Fernseher oder Videorekorder usw., beschreiben. Alternativ kann die SDD-Datenstruktur eine komplexere Struktur sein, die auch das Override-DCM und eine graphische Darstellung des Geräts definiert. Die graphische Darstellung innerhalb der SDD-Datenstruktur ermöglicht es einem FAV-Knoten, den Benutzern eine bildliche Darstellung der Geräte in dem Heim-Netz zu präsentieren. Durch Definieren der graphischen Darstellung in einer ausreichend allgemeinen Weise, können die graphischen SDD-Daten eines Geräts in dem Produkt irgendeines Zulieferers benutzt werden, um ein Benutzer-Interface für dieses Gerät anzuzeigen. Dies liefert eine verbesserte Schicht der Zulieferer-Interoperabilität und ermöglicht es außerdem einem Zulieferer, ein Produkt zu differenzieren, während das Look-and-Feel der Anzeigevorrichtung beibehalten wird. Dies ermöglicht es einer Steuervorrichtung (dem FAV-Knoten), unabhängig von den Unterschieden in Typ und Anbieter für alle Geräte in dem Heim-Netz ein allgemeines Steuer-Benutzer-Interface zu präsentieren.
  • Wie oben beschrieben wurde, sind Legacy-Geräte solche Geräte, die vor Einführung der HAVI-Architektur gebaut wurden, oder Geräte, die HAVI nicht benutzen. HAVI unterstützt Legacy-Geräte durch die Bereitstellung von Legacy-DCMs, die Protokoll-Umwandlungen für Legacy-Geräte liefern. Diese Legacy-DCMs können genügend Intelligenz enthalten, die es ihnen ermöglicht, ein vorhandenes Ein- oder Zweiwege-Steuerprotokoll zu unterstützen und den Geräten ein spezifisches Steuer-Interface zur Verfügung zu stellen, das mit HAVI konform ist. Ein Legacy-DCM wirkt als Brücke zwischen den Legacy- und HAVI-Geräten. Dieser Lösungsweg ermöglicht es HAVI auch, mit irgendwelchen zukünftigen Gerätesteuer-Protokollen zusammenzuarbeiten, wie Protokollen, die für das Energiemanagement oder die Sicherheit des Heims benutzt werden.
  • Es ist zu beachten, daß die Kommunikations-Hardware und -Protokolle, die von der HAVI-Architektur benutzt werden, nicht spezifisch sind. Die HAVI-Architektur eignet sich ohne weiteres für die Einbeziehung und die Benutzung beliebiger Exemplare aus mehreren Kommunikationsmedien, mit der einfachen Forderung, daß das Medium einen allgemeinen Kommunikations-Mechanismus vorsieht, der die HAVI-Interfaces unterstützt. Das unterstellte Basismodell ist solches mit einem logischen Kommunikations-Rahmen (z.B. IEEE 1394). Alle AV-Geräte seien mit diesem Rahmen verbunden und können alle anderen AV-Geräte lokalisieren und mit ihnen kommunizieren, wie dies in 1B dargestellt ist. Bei einer physikalischen Einrichtung besteht dieser logische Rahmen wahrscheinlich aus mehr als einem physikalischen Kommunikationsmedium. Es wird ferner angenommen, daß in verschiedenen physikalischen Medien Mehrfach-Protokolle in Benutzung sein können. Die Heim-AV-Architektur abstrahiert über dieses Ganze und stellt ein allgemeines Modell von kommunizierenden Knoten dar. Sie liefert einen Mechanismus über der Transportschicht (funktional wie ein Stecker), um die Transparenz des Netzwerks zu gewährleisten. Dieser Mechanismus kann als "zuverlässiger, geordneter Datagramm-Service" beschrieben werden, der jede Fragmentierung und Wiederzusammensetzung ermöglicht.
  • Es ist dementsprechend ein Ziel der vorliegenden Erfindung, jeden physikalischen Bus in gleicher Weise zu unterstützen, so daß eine Anwendung sich nicht darum kümmern muß, welchen physikalischen Transport sie benutzt. Da die Industrie für elektronische Geräte jedoch mit IEEE 1394 vertraut ist, werden Merkmale der vorliegenden Erfindung im Hinblick auf das Funktionieren mit IEEE 1394 dargestellt und beschrieben. Andere Busse, wie CEBus und USB erfordern möglicherweise nicht alle die gleichen Merkmale.
  • Es sei nun auf 2 Bezug genommen, in der ein exemplarisches Peer-to-Peer, nämlich ein HAVI-Netz 200 mit zwei IAV-Knoten, nach einem Ausführungsbeispiel der vorliegenden Erfindung dargestellt ist. Das HAVI-Netz 200 enthält ein erstes IAV 201 (z.B. einen Fernseher), der mit einem zweiten IAV 202 (z.B. einem Empfänger) verbunden ist. Das IAV 201 und das IAV 202 verhalten sich nach Art von Peer-to-Peer, indem sie notwendige Ressourcen untereinander vermitteln. Ihnen fehlen zwar die Ressourcen, um das Hinzufügen eines BAV- oder LAV-Geräts zu unterstützen, sie können jedoch sinnvolle Aktivitäten in ihrem Kontext ausführen. Es ist nicht erforderlich, daß das IAV irgendeine Standard-UI-Fähigkeit zur Verfügung stellt. Es ist keine "Vorwärtskompatibilität" oder die Entdeckung von neuen Funktionen in der AV-Architektur vorgesehen (z.B. kennt IAV die Funktionen, die IAV 202 unterstützt, nur auf der Basis der bei der Verbindung von IAV2 bereitgestellten SDD). Jedoch können gemäß vorliegender Erfindung die Merkmale der SDD leicht dazu benutzt werden, eine "ad-hoc"-Merkmal-Entdeckung durchzuführen.
  • 3 zeigt ein HAVI-Netz 300 mit einem einzelnen FAV-Cluster nach einem Ausführungsbeispiel der Erfindung. Das HAVI-Netz 300 umfaßt ein FAV 301 (z.B. eine Set-Top-Box), die mit einem ersten LAV 302 (z.B. einem Fernseher), einem zweiten LAV 303 (z.B. einem Videorekorder) bzw. einem BAV 304 (z.B. einer digitalen Kamera) verbunden ist.
  • In dem HAVI-Netz 300 steuert das FAV 301 Legacy- und Basis-AV-Geräte (z.B. die Geräte 302 bis 304), wobei es clusterweite Dienste zur Verfügung stellt.
  • 4 zeigt einen FAV-Cluster, der mit einem IAV-Peer-to-Peer-HAVI-Netz 400 integriert ist. Gemäß vorliegender Erfindung sieht die Konfiguration des HAVI-Netzes 400 Unterstützung für Legacy-Geräte 302 und 303 vor, während es eine unabhängige Steuerung innerhalb der beiden IAV-Geräte 401 und 402 ermöglicht, wenn ihre Ressourcen nicht von dem FAV-Gerät 301 benutzt werden. Die IAV-Geräte 401 und 402 verhalten sich gegenüber dem FAV-Gerät 301 als Peers. Zum Zwecke der Effizienz kann für Ressourcen-Anforderungen sowohl von FAV zu FAV als auch von FAV zu IAV eine Ressourcen-Konfliktpolitik implementiert sein. Das IAV wird von dem FAV über ein in dem FAV 301 laufendes DCM gesteuert.
  • 5 zeigt ein exemplarisches HAVI-Netz 500 mit mehreren FAVs. Das HAVI-Netz 500 enthält ein zusätzliches FAV 501 (z.B. einen Satellitenempfänger). Diese Konfiguration verhält sich ähnlich wie das oben beschriebene HAVI-Netz 400. In dieser Konfiguration agieren die FAV-Geräte 301 und 501 als Peers.
  • DIE PLATTFORM DES COMPUTERSYSTEMS
  • In 6 ist ein Diagramm einer Set-Top-Box 301 nach einem Ausführungsbeispiel der Erfindung dargestellt. Wie oben beschrieben wurde, können irgendwelche elektronischen Consumer-Geräte ein FAV sein und damit eine Computersystem-Plattform für HAVI-Software zur Verfügung stellen. Die Set-Top-Box 301 des exemplarischen HAVI-Netzes enthält z.B. spezielle Komponenten, die eine Operations-Plattform für Softwarekomponenten der HAVI-Architektur zur Verfügung stellen, die weiter unten beschrieben werden. Im speziellen Fall werden die unten beschriebenen Aspekte der Erfindung in Form von Schritten diskutiert, die auf einem Computersystem ausgeführt werden (z.B. die in 13 bis 17A dargestellten Prozesse). Obwohl eine Vielfalt unterschiedlicher Computersysteme mit der vorliegenden Erfindung benutzt werden kann, ist in der Set-Top-Box von 6 ein exemplarisches Universal-Computersystem dargestellt.
  • Die Set-Top-Box 301 in 6 besitzt zusätzlich zu einer Video-/Audioempfänger-(Dekodierer)-Einheit 606 und einer MPEG-Einheit 607 einen Adressen-/Datenbus 600 für die Übertragung von Informationen, einen oder mehrere mit dem Bus 600 verbundene Zentralprozessoren 601 zur Verarbeitung von Informationen und Befehlen, einen mit dem Bus 600 verbundenen flüchtigen Speicher 602 (z.B. einen Speicher mit wahlfreiem Zugriff RAM) zum Speichern von Informationen und Befehlen für den Zentralprozessor 601 und einen mit dem Bus 600 verbundenen nichtflüchtigen Speicher 603 (z.B. einen Nurlesespeicher ROM) für die Speicherung von statischen Informationen und Befehlen für den Prozessor 601. Die Set-Top-Box 301 kann optional auch eine mit dem Bus 600 verbundene Datenspeichervorrichtung 604 ("Platten-Subsystem") enthalten, z.B. eine magnetische oder optische Platte und ein Plattenlaufwerk, für die Speicherung von Informationen und Befehlen. Außerdem enthält die Set-Top-Box 301 eine Bus-Interfaceeinheit 608 als Schnittstelle mit dem lokalen Bus 30 (z.B. einem seriellen IEEE-1394-Bus).
  • Die Set-Top-Box 301 kann unter einer Vielzahl verschiedener Betriebssysteme arbeiten (z.B. Windows-Betriebssystem, DOS-Betriebssystem, Macintosh O/S), wobei in der vorliegenden Erfindung jedoch das Aperios-Betriebssystem benutzt wird.
  • DAS HAVI-SOFTWAREMODELL
  • Gemäß vorliegender Erfindung sind die Recheneinheiten der HAVI-Architektur (z.B. DCMs) als Objekte modelliert. Jedes Objekt ist eine selbständige Entität, die über ein wohldefiniertes Interface zugänglich ist und in einer wohldefinierten Umgebung der Software-Ausführung arbeitet. Die Umgebung der Software-Ausführung (z.B. die Set-Top-Box 301 von 6) liefert einen Satz von wohldefinierten Diensten (lokal oder entfernt), die ebenfalls als Objekte modelliert sind und auf die unter Verwendung der Kommunikations-Infrastruktur über ihre wohldefinierten Interfaces zugegriffen werden kann.
  • Jedes Objekt ist eindeutig benannt. Es wird keine Unterscheidung getroffen zwischen Objekten, die zum Aufbau von System-Diensten genutzt werden, und solchen, die für Anwendungsdienste benutzt werden. Alle Objekte machen sich selbst über die Registrierung bekannt. Objekte in dem System können die Registrierung abfragen, um einen speziellen Service oder ein spezielles Gerät zu ermitteln, und können das Ergebnis dieser Abfrage dazu benutzen, Nachrichten zu diesem Service oder Gerät zu senden. Der einem Objekt zugeordnete Identifizierer wird erzeugt, wenn das Objekt registriert wird. Falls erforderlich, wird garantiert, daß diese Identität während der Lebenszeit des Objekts persistent ist und selbst bei einem vollständigen Neu-Booten des Heim-Netzes persistent bleibt.
  • Gemäß vorliegender Erfindung kommunizieren die Objekte, indem sie ein Nachrichtenübermittlungs-Modell benutzen. Ein Objekt, das den Service eines anderen Objekts benutzen möchte, tut dies, indem es einen universellen Mechanismus zur Nachrichtenübermittlung benutzt, der die Service-Anforderung an das Zielobjekt liefert. Das Zielobjekt wird mit Hilfe des oben erwähnten eindeutigen Objekt-Identifizierers spezifiziert. Im vorliegenden Ausführungsbeispiel arbeitet der Mechanismus zur Nachrichtenübermittlung mit IEEE 1394, wobei jedoch zu erwähnen ist, daß kein Unterschied besteht zwischen dem Senden einer Nachricht über einen 1394-Bus oder über eine Control-A1-Verbindungsleitung.
  • Ebenso wird keine Unterscheidung getroffen zwischen Objekten in dem gleichen Knoten und einem Objekt in einem entfernten Knoten. Die praktische Implementierung der Infrastruktur zur Nachrichtenübermittlung hängt von der System- und Netzumgebung ab und differiert von Knoten zu Knoten und zwischen Zulieferern. Das tatsächliche Format der Nachrichten muß jedoch ein gemeinsames sein, damit Interoperabilität gewährleistet ist.
  • Es ist zu beachten, daß die generelle Absicht des Objektmodells und des Nachrichtensystems darin besteht, ein vollständig generisches Softwaremodell zur Verfügung zu stellen, das hinreichend flexibel ist, um mehrfache Implementierung mit einer Vielfalt von Softwaresystemen und Sprachen zu ermöglichen. Details der Verknüpfung zwischen Nachrichten und dem sie behandelnden Code sind dem Implementierer des Systems überlassen.
  • ÜBERBLICK ÜBER DIE SOFTWARE-ARCHITEKTUR
  • Die HAVI-Software-Architektur definiert die Art und Weise, in der das Softwaremodell benutzt wird, um die HAVI-Architektur zu unterstützen. Insbesondere definiert sie die Art und Weise, in der Geräte in der AV-Architektur abstrahiert und verwaltet werden. Sie definiert die Art und Weise, in der Interoperabilität gewährleistet wird, und sie definiert die Möglichkeiten, zukünftige Geräte und Dienste in die Architektur zu integrieren.
  • Voll-AV-Knoten als Software-Manager: Gemäß vorliegender Erfindung arbeiten Voll-AV-Knoten (FAVs) als Manager für Zwischen-(IAVs)- und Basis-(BAVs)-Knoten und liefern eine Plattform für die Dienste, die die HAVI-Architektur unterstützen. Um dies zu erreichen, stellen sie eine Ausführungs-Umgebung zur Verfügung, die es Objekten ermöglicht, Dienste und Geräte zu steuern und mit ihnen zu kommunizieren. Um sicherzustellen, daß innerhalb des Heim-AV-Netzes auf Geräte zugegriffen werden kann, unterstützen die FAV-Knoten eine Software-Abstraktion der Dienste, die ein Gerät anderen Geräten bietet. Wie oben beschrieben wurde, wird diese Abstraktion als Geräte-Steuermodul (DCM) bezeichnet. Das DCM ist als Objekt innerhalb der Software-Architektur modelliert, wird im folgenden jedoch zur Unterscheidung einfach als DCM bezeichnet. Das Interface, das das DCM gegenüber dem Rest des Systems exponiert, stellt die Mittel zur Verfügung, um auf dieses Gerät zuzugreifen und es zu steuern. Im allgemeinen Fall verwaltet ein FAV eine Gruppe von DCMs, eines für jeden IAV-Knoten und Basis-Knoten in dem Heim-Netz oder in dem von ihm verwalteten Abschnitt des IAV-Netzes. So sollte also beachtet werden, daß aus der Perspektive der Interoperabilität die primäre Rolle des FAV-Knotens darin besteht, DCMs der vorliegenden Erfindung zu verwalten und als Ausführungs-Umgebung für DCMs zu agieren.
  • Voll-AV-Knoten als Steuereinrichtung und Anzeigevorrichtung: Gemäß vorliegender Erfindung haben FAVs in den meisten Fällen eine zugehörige Anzeigevorrichtung, die für die Anzeige von AV-Inhalten und von Benutzer-Interface-(UI)-Material benutzt wird. Die HAVI-Software-Architektur fordert dies jedoch nicht. FAV-Knoten können vielmehr auch "kopflos" sein. In diesem Fall kooperieren operieren sie mit anderen Knoten, um Inhalte und UI-Informationen anzuzeigen (siehe weiter unten). FAV-Geräte sind jedoch verantwortlich für die Unterstützung der UI-APIs der oberen Schicht, die das Look-and-Feel des gesamten Heim-Netzes liefern. Die APIs der niedrigen Schicht zur Graphik-Manipulation sind im allgemeinen in der Nähe der graphischen Anzeigevorrichtung selbst angeordnet und werden von den FAV-APIs der oberen Schicht manipuliert.
  • Peer-to-Peer-Architektur zwischen Voll-AV-Knoten: In einem Heim-AV-Netz gemäß vorliegender Erfindung kann es mehr als ein FAV geben. In diesem Fall arbeitet jedes FAV mit anderen FAVs zusammen, um sicherzustellen, daß dem Benutzer Dienste zur Verfügung gestellt werden. Dies ermöglicht es FAV-Knoten, zusammenzuarbeiten, um Ressourcen gemeinsam zu nutzen. Ein FAV-Knoten, der keinen direkten Zugriff auf eine Anzeigevorrichtung hat, kann z.B. einen entfernten FAV-Knoten benutzen, um DCM-Benutzer-Interfaces anzuzeigen. Alternativ kann ein FAV-Knoten die Dienste eines Datenübersetzungs-Moduls anfordern das sich in einem entfernten Knoten befindet, um ihm die Einrichtung eines Datenweg zwischen zwei AV-Geräten zu ermöglichen.
  • SCHICHT-1- UND SCHICHT-2-INTEROPERABILITÄT ALLGEMEIN
  • Gemäß vorliegender Erfindung besteht eines der Hauptziele der HAVI-Architektur der vorliegenden Erfindung darin, die Interoperabilität zwischen Geräten zu unterstützen. Dies schließt existierende Geräte und zukünftige Geräte ein. Um diese Interoperabilität zu erreichen, unterstützt die HAVI-Architektur der vorliegenden Erfindung ein generelles Modell, das zwei Interoperabilitäts-Schichten ermöglicht. Diese Schichten werden als Schicht 1 und Schicht 2 bezeichnet.
  • Schicht-1-Interoperabilität: Die Schicht-1-Interoperabilität der vorliegenden Erfindung widmet sich der allgemeinen Notwendigkeit, existierenden Geräten zu ermöglichen, miteinander zu kommunizieren. Um dies zu erreichen, definiert und benutzt die Schicht-1-Interoperabilität der vorliegenden Erfindung einen allgemeinen Satz von Steuernachrichten (Befehlen), die ein Gerät befähigen, mit einem anderen Gerät zu sprechen, sowie einen Satz von Ereignis-Nachrichten, die es vernünftigerweise von dem Gerät erwarten sollte. Um diesen Lösungsweg zu unterstützen, ist eine Grundmenge von Prozessen erforderlich. Diese Prozesse umfassen die Geräte-Entdeckung, die Kommunikation und einen Satz von allgemeinen Nachrichten.
  • Der Prozeß zur Geräte-Entdeckung gemäß vorliegender Erfindung sieht vor, daß jedes Gerät in dem Heim-AV-Netz ein wohldefiniertes Verfahren benötigt, das es ihm erlaubt, seine Eigenschaften anderen Geräten anzuzeigen. Der von uns übernommene Lösungsweg besteht darin, eine in allen FAV- und IAV-Geräten benötigte Datenstruktur zu spezifizieren, die Informationen über das Gerät enthält und auf die von allen anderen Geräten zugegriffen werden kann. Diese Datenstruktur wird als selbstbeschreibende Datenstruktur (SDD) bezeichnet. Die SDD enthält als Minimum genügend Informationen, um es einem anderen Gerät zu ermöglichen, seine Basisfähigkeiten zu entdecken und so die Grundmenge an Befehlsnachrichten erkennen zu lassen, die zu diesem Gerät gesendet werden können, sowie Ereignisse, von denen es vernünftigerweise erwarten kann, daß es sie von dem Gerät empfängt.
  • Der Kommunikationsprozeß der vorliegenden Erfindung sorgt dafür, daß ein Gerät in der Lage sein muß, auf die Fähigkeiten eines anderen Geräts zuzugreifen, sobald es diese festgestellt hat. Um dies zu erreichen, ist eine generelle Kommunikationsmöglichkeit erforderlich, die es einem Gerät erlaubt, an ein anderes Gerät eine Nachricht zu senden, die eine Befehlsanforderung enthält. Die allgemeinen Prozesse für den Nachrichten-Service gemäß der Erfindung wurden oben diskutiert.
  • Ein allgemeine Gruppe von Nachrichten bezieht sich auf den Prozeß, der für die Unterstützung der Schicht-1-Interoperabilität benötigt wird. Diese enthält einen wohldefinierten Satz von Nachrichten, die von allen Geräten einer speziellen Klasse unterstützt werden müssen. Dadurch ist sichergestellt, daß ein Gerät unabhängig vom Hersteller mit anderen Geräten zusammenarbeiten kann, weil bei allen Geräten Übereinstimmung über einen gemeinsamen Satz von allgemeinen Befehlen besteht. Wie oben diskutiert wurde, werden diese Befehle in der HAVI-Software-Architektur der vorliegenden Erfindung dem Rest des Systems als ein DCM präsentiert.
  • Diese drei Basis-Prozesse der vorliegenden Erfindung unterstützen zumindest eine minimale Interoperabilitäts-Schicht. Da in den meisten Fällen ein Gerät die Fähigkeiten eines anderen über die SDD abfragen kann, kann ein Gerät den von einem anderen Gerät unterstützten Befehlssatz fest stellen. Und da jedes Gerät Zugriff zu einem allgemeinen Nachrichtensystem hat, kann dann ein Gerät mit einem anderen Gerät interagieren.
  • Es ist jedoch zu beachten, daß die Schicht-1-Kompatibilität gemäß der Erfindung lediglich sicherstellt, daß Geräte in einer minimalen oder sehr einfachen Funktionalitäts-Schicht miteinander arbeiten können. Der allgemeine Nachrichtensatz für jede Geräteklasse ist ein minimaler und gemeinsamer Satz von Befehlen. Die SDD-Möglichkeit bietet ein Mittel für einen gewissen Grad von Kundenanpassung eines Geräts, indem sie eine Information über sein UI und einige Aspekte seines Interaktions-Modells liefert. Andere IAV-Geräte können diese Information benutzen, um dem Gerät ein Interface zu präsentieren. Alternativ kann ein FAV-Gerät diese Information zur kundenspezifischen Anpassung des allgemeinen DCM benutzen, das es für dieses Gerät erzeugt hat. Es ist jedoch zu beachten, daß auch ein Mechanismus mit größerer Erweiterbarkeit benötigt wird, um es einem Gerät zu ermöglichen, anderen Geräten irgendwelche zusätzliche Funktionalität mitzuteilen, die es besitzt. Die Schicht-2-Interoperabilität der vorliegenden Erfindung stellt diesen Mechanismus zur Verfügung. Die Schicht-1- und Schicht-2-Interoperabilität werden weiter unten näher erläutert.
  • SCHICHT-1- UND SCHICHT-2-DCMs
  • Wie oben beschrieben wurde, besteht die Funktion des DCM der vorliegenden Erfindung darin, Zugriff, Steuerung und Interaktion mit einem Gerät zu ermöglichen. DCMs werden typischerweise auf den Ressourcen von FAVs in der Heim-AV-Architektur instantiiert (d.h. ausgeführt). Das DCM der vorliegenden Erfindung stellt einem Gerät ein Interface zur Verfügung und verwaltet ein UI, das das Gerät den Benutzern präsentieren möchte.
  • Gemäß vorliegender Erfindung sind die für Geräte erzeugten DCMs mit der Schicht-1-Interoperabilität generisch. Sie unterstützen einen minimalen Befehlssatz, der eine generische Steuerung des Geräts ermöglicht. Um gerätespezifische Merkmale zu unterstützen, muß die DCM sich Zugang zu solchen gerätespezifischen Merkmalen verschaffen und ist in der Lage, Benutzern über daß UI gerätespezifische Merkmale zu präsentieren.
  • Um dies zu ermöglichen wird die Schicht-2-Interoperabilität benutzt. Gemäß vorliegender Erfindung ermöglicht es die Heim-AV-Architektur, einem Gerät, ein "Override"-DCM für das generische DCM zur Verfügung zu stellen, das normalerweise für dieses Gerät erzeugt wird. Das Override-DCM (z.B. ein Schicht-2-DCM) ist in der Lage, das Default-DCM (z.B. ein Schicht-1-DCM) in dem FAV zu ersetzen. Es ist zu beachten, daß das Schicht-2-DCM von verschiedenen Quellen aufgerufen werden kann. Eine solche Quelle ist das SDD des Geräts selbst. In diesem Fall wird das Schicht-DCM abgerufen, empfangen oder anderweitig von dem SDD des Geräts akquiriert und in einem FAV-Knoten instantiiert, wenn das Gerät in dem System installiert wird. Da die Heim-AV-Architektur zuliefererneutral ist, ist es notwendig, daß das Schicht-2-DCM in verschiedenen FAV-Knoten arbeitet, die jeweils potentiell unterschiedliche Hardware-Architekturen haben. Um dies zu erreichen, ist das Format sowohl der Schicht-1- als auch der Schicht-2-DCMs der vorliegenden Erfindung architekturneutral, so daß eine große Vielfalt von Umgebungen zur Software-Ausfüh rung der FAV-Knoten, die in der Lage sind, die Schicht-1- und Schicht-2-DCMs zu instantiieren und laufen zu lassen.
  • Es ist zu erwähnen, daß gemäß vorliegender Erfindung die DCMs der Erfindung, sobald sie in den FAV-Knoten erzeugt sind und laufen, in der gleichen Weise mit den IAV- und BAV-Knoten kommunizieren, wie dies oben beschrieben wurde, indem sie den Basis-Nachrichten-Mechanismus benutzen.
  • Wie oben beschrieben wurde, gibt es in einem gegebenen HAVI-Netz viele mögliche Permutationen von FAV-, IAV- und BAV-Knoten. Diese Permutationen fallen im allgemeinen uner einen von zwei Typen: HAVI-Netzwerk-Konfigurationen, die ein FAV-Gerät unterstützen, und solche, die das nicht tun. Diese Unterscheidung definiert im Wesentlichen, ob ein HAVI-Netz eine Peer-to-Peer-Konfiguration benutzt (wie sie z.B. in 2 dargestellt ist, in der kein FAV vorhanden ist) oder ob es irgendeine Form von Steuerhierarchie bedingt (z.B. das in 3 dargestellte FAV-Cluster).
  • Nach einem Ausführungsbeispiel der vorliegenden Erfindung ist in Fällen, in denen keine FAV vorhanden ist, nur die Schicht-1-Interoperabilität verfügbar, und die Geräte sind gezwungen, die SDD-Information zu benutzen, um andere IAV-Fähigkeiten zu entdecken, diese Fähigkeiten zu präsentieren und das Gerät zu steuern. Falls FAVs vorhanden sind, werden DCMs instantiiert und benutzt. Wenn es sich hierbei um Schicht-1-DCMs (z.B. generische DCMs) handelt, arbeiten die Geräte mit Schicht-1-Interoperabilität. Falls wenigstens ein Schicht-2-DCM vorhanden ist, arbeiten einige der Geräte mit Schicht-2-Interoperabilität.
  • Es ist zu beachten, daß gemäß vorliegender Erfindung ein gemischter Operationsmodus möglich ist, in dem Cluster von Geräten unter dem Steuereinfluß eines FAV-Knotens miteinander arbeiten, während andere Geräte nach Art von Peer-to-Peer miteinander arbeiten. Auf diese Weise verschafft die Flexibilität der Erfindung den Zulieferern die Möglichkeit, Geräte über das ganze Kosten-/Fähigkeits-Spektrum zu entwickeln und zu bauen mit der Gewißheit, daß diese Geräte nahtlos mit anderen Geräten in dem HAVI-Netz zusammenarbeiten
  • Es sei nun auf 7 Bezug genommen, in der ein logisches Blockdiagramm 700 eines Ausführungsbeispiels der HAVI-Architektur dargestellt ist. 7 zeigt eine HAVI-Gesamtachitektur gemäß vorliegender Erfindung. Folgende Komponenten sind in dem Diagramm 700 dargestellt:
    Geräte-Manager 761: Der Geräte-Manager 761 ist verantwortlich für die Schaffung und Verwaltung der DCMs, die von einem FAV-Gerät verwaltete Geräte repräsentieren.
  • Geräte-Module 720: Dieses sind die DCMs für individuelle Geräte. Wie oben beschrieben wurde, fungiert jedes DCM als Kontrollpunkt für ein Gerät und liefert eine UI-Komponente und eine Steuerkomponente. Die DCMs (z.B. Geräte-Module 720) liefern ein API, um anderen Anwendungen zu ermöglichen auf die Geräte zuzugreifen und sie zu handhaben.
  • Service-Module 730: Diese Module können als Software-Geräte betrachtet werden. Sie sind DCMs für irgendeine Software-Komponente (im Gegensatz zu einem Hardware-Gerät), die anderen Geräten oder Komponenten in dem Heim-Netz einen generellen Service liefert.
  • Comms-Media-Manager 740: Diese Komponente ist verantwortlich für die Verwaltung des darunter liegenden physikalischen Kommunikationsprozesses. Sie liefert ein API, das es Code-Modulen ermöglicht, mit den Merkmalen der Kommunikations-Medien (z.B. IEEE 1394) zu interagieren.
  • Registrierdatenbank 706: Dies ist eine Service-Datenbank. Alle DCMs für physikalische Geräte und Software-Dienste registrieren sich selbst in der Registrierdatenbank 706, und alle Module (z.B. die Geräte-Module 720) können die Registrierdatenbank abfragen, um ein Handle für ein anderes Gerät oder Modul zu bekommen.
  • Kommunikations-Manager 750: Diese Komponente ist eine Low-Level-Abstraktion der Kommunikations-Medien.
  • Messaging 702: Diese Komponente stellt eine Basis-Nachrichtenübermittlungseinrichtung zur Verfügung, um es sowohl Geräten (Hardware) als auch Geräte-Modulen 720 und Service-Modulen 730 zu ermöglichen, miteinander zu kommunizieren.
  • Ereignis-Manager 703: Dieses Modul stellt einen generischen Ereignis-Service zur Verfügung. Es ist ein Kommunikations-Service von einem Objekt zu vielen Objekten, der die Anmeldung in dem HAVI-Netz ermöglicht.
  • Initialisierungs-Manager 701: Diese Komponente wird als Teil des Geräte-Bootstrap-Prozesses benutzt.
  • Daten-Routing 762: Die Daten-Routing-Komponente 762 ist verantwortlich, Services bei der Einrichtung von Routen zwischen Geräten und Geräte-Modulen zu unterstützen. Sie berücksichtigt die "Kosten" der Übertragung von Daten über eine spezielle Route, die Forderungen nach Datenformatübersetzung usw. Für die Basis-Architektur wird diese Komponente nicht benötigt.
  • AV-Aktionen/Makros 763: Diese Komponente ist ein Manager für AV-Aktionen auf höherem Niveau, die Gruppen von individuellen Befehlen niedrigen Niveaus bilden, d.h. sie liefert einen Makro-Service. Für die Basis-Architektur wird diese Komponente nicht benötigt.
  • High-Level-UI-Bibliothek 704: Diese Komponente liefert einen Satz von High-Level-UI-Komponenten, die von den Geräte-Modulen 720 für den Aufbau von UIs für ihre entsprechenden Geräte benutzt werden. Für die Basis-Architektur wird diese Komponente nicht benötigt.
  • Anwendungs-(und Benutzer)-Interface 705: Diese Komponente liefert die Verknüpfung zwischen einer gemeinsamen Plattform von elektronischen Consumer-Geräten (CCEP)-APIs der HAVI-konformen Geräte und Anwendungen, die lokal oder möglicherweise entfernt angeordnet sind. Für die Basis-Architektur wird diese Komponente nicht benötigt.
  • Es ist zu beachten, daß die obigen Komponenten, wie sie in 7 schematisch dargestellt sind, Funktionalitäts-Abstraktionen darstellen. Sie dienen zur Erläuterung dafür, welche Funktionalität in der Architektur für HAVI-konforme Geräte enthalten ist. Um das Verständnis der Erfindung nicht unnötig zu erschweren, sind die Beziehung zwischen den Komponenten 701 bis 763 und der Nachrichtenfluß zwischen ihnen nicht dargestellt.
  • DCM-KONFIGURATION UND -FUNKTION
  • Überblick
  • In einem Ausführungsbeispiel der Erfindung existiert in HAVI-Netz-Konfigurationen, in denen ein FAV-Knoten verfügbar ist, für jedes physikalische Gerät im HAVI-Netz ein DCM, das dem FAV-Knoten bekannt ist. Das DCM liefert ein Interface für das Gerät und präsentiert es als ein Objekt in der Architektur. Andere DCMs, System-Services oder Anwendungs-Services können die lokale Registrierdatenbank abfragen, um die verfügbaren Geräte zu ermitteln und sich einen Identifizierer zu verschaffen, der es ihnen ermöglicht, über ihr DCM mit den Geräten zu interagieren.
  • Gerätesteuer-Module sind auch verantwortlich für die Interaktion mit der Software-Architektur, um dem Benutzer das Benutzer-Interface (UI) des Geräts zu präsentieren. Eingaben von Benutzern werden dann zu dem DCM übertragen, das die Eingabe für die Steuerung des tatsächlichen Geräts benutzt.
  • Wie oben diskutiert wurde, unterstützen DCMs die Schicht-1- und die Schicht-2-Interoperabilität. Ein Schicht-1-DCM ist ein generisches DCM, das üblicherweise mit dem FAV-Knoten geliefert wird und einen vordefinierten Basis-Satz von Merkmalen einer Geräteklasse verwalten kann, wobei sie einen vordefinierten Nachrichten-Satz benutzt. Während der Initialisierung arbeitet das DCM mit dem (unten beschriebenen) Geräte-Manager zusammen, um die tatsächlichen Eigenschaften des zu verwaltenden Geräts zu entdecken, und konfiguriert sich selbst, um dieses Gerät zu steuern. So könnte eine generische Videorekorder-Steuerung instantiiert werden, um einen Standard-Videorekorder entweder mit Hilfe von 1394-AV/C-Nachrichten oder über Control A1 zu steuern.
  • Im Fall der Schicht-2-Interoperabilität ist das für dieses Gerät instantiierte DCM ein Override-DCM, das aus einer externen Quelle, z.B. dem Gerät selbst, geladen wurde. Diese Override-DCMs sind in dem gemeinsamen Sprach-Format für DCMs geschrieben. Die Funktion eines Override-DCM unterscheidet sich nicht von derjenigen generischer DCMs, das angebotene API ist jedoch wahrscheinlich umfassender.
  • Sobald DCMs instantiiert sind, liefern sie nicht nur Steuer-Interfaces für das Gerät, sondern verschafft auch Zugriff auf die einem Gerät zugeordneten SDD-Daten. Sie arbeiten als Ereignis-Manager für ein Gerät, indem sie gerätespezifische Ereignisse empfangen und solche in dem Ereignis-System (siehe unten) verbuchen. Sie arbeiten auch als UI-Manager für das Gerät, indem sie mit dem UI-Management-Systems zusammenwirken, um über eine Anzeigevorrichtung ein Benutzer-Interface zur Verfügung zu stellen. Letztlich arbeitet das DCM als Ressourcen-Manager für Geräte, indem es Anforderungen auf Gerätezugriff und – service vermittelt.
  • Generelle DCM-Terminologie
  • In der Terminologie der vorliegenden Erfindung, so wie sie in den folgenden Beschreibungen benutzt wird, präsentiert jedes DCM ein Modell eines Geräts in dem Heim-Netz. Die verwendete Basis-Terminologie ist folgende:
    • 1) Gerät: Dieser Ausdruck bezieht sich auf das ganze Gerät.
    • 2) Untergerät: Dieser Ausdruck bezieht sich auf eine oder möglicherweise viele Komponenten, die ein Gerät bilden. Einige Technologien haben nicht die Möglichkeit, Untergeräte zu unterscheiden.
    • 3) Interne Verbindung: Dieser Ausdruck bezieht sich auf die logische oder physikalische Verbindung zwischen internen Untergeräten.
    • 4) Externe Verbindung: Dieser Ausdruck bezieht sich auf die Verbindung zwischen einem physikalischen Verbinder an der Außenseite eines Geräts und einem Zielgerät außerhalb des Geräts. Das gleiche gilt für den seriellen Einheits-Bus und externe Eingangs- und Ausgangs-Steckverbindungen für AV/C.
    • 5) Protokoll: Dieser Ausdruck bezieht sich auf das von dem Untergerät oder dem Gerät gesprochene Steuerprotokoll (z.B. AV/C, Control A1, usw.). Es ist zu beachten, daß ein Gerät Untergeräte enthalten kann, die verschiedene Protokolle sprechen.
    • 6) Interface: Dieser Ausdruck bezieht sich auf das physikalische Bus-Verbindungs-Interface (1394, USB usw.).
    • 7) Geräteklasse: Dieser Ausdruck ist eine Möglichkeit, die Basis-Funktionalität einer gegebenen Sammlung von Geräten zu beschreiben. So kann z.B. die Klasse von digitalen Videorekordern [DVCR-Geräten] Daten auf einem bandförmigen Medium aufzeichnen. Ebenso kann es viele Geräte geben, die ein Audiosignal aufnehmen, irgendeine Art spezieller Effekte ausführen und den modifizierten Audiostrom ausgeben können. Diese gehören alle zur Klasse Audioprozessor oder irgend etwas von dieser Art. Der Nutzen dieses Konzepts wird weiter unten in diesem Dokument weiter verdeutlicht.
    • 8) Gerätemodell: Dieser Ausdruck bezieht sich auf die Sammlung von Untergeräten und Verbindungen, die eine Definition entweder eines Standard- oder Customer-Geräts bilden. Individuelle Untergeräte, auf die innerhalb physikalisch getrennter Geräte zugegriffen werden kann, können kombiniert werden, um logische oder virtuelle Geräte zu bilden, die das Gerätemodell benutzen.
    • 9) Standard-Gerät: Dieser Ausdruck bezieht sich auf Standard-Modell-Definitionen (z.B. besteht ein digitaler Videorekorder zumindest aus einem Tuner-Untergerät und einem Videorekorder-(Transport)-Untergerät mit Steckverbindungen zwischen ihnen).
    • 10) Spezielles Gerät: Dieser Ausdruck bezieht sich auf ein zuliefererspezifisches Gerätemodell, das entweder aus Standard-Untergeräten oder aus einer Kombination von Standard- und zuliefererspezifischen Untergeräten besteht. So kann z.B. ein digitaler Zweifach-Videorekorder zwei Videorekorder-Untergeräte besitzen, die an sich Standardartikel sind, jedoch in einer Nichtstandard-Konfiguration vorliegen.
    • 11) Geräte-Komplex: Dieser Ausdruck bezieht sich auf logische Entitäten, die aus verschiedenen Komponenten kombiniert sein können. Physikalische Geräte und Untergeräte sind individuell zugängliche Hardwareteile. Wenn Geräte Untergeräte haben, auf die zugegriffen werden kann, wird dieses Modell auf die Unterstützung von Geräte- Komplexen erweitert. Beispiele für Geräte-Komplexe umfassen Untergeräte aus getrennten physikalischen Geräten oder innerhalb eines einzelnen Geräts sowie Software-Module, wie Software-Codecs, die ähnliche Services oder Fähigkeiten bieten wie Geräte und Untergeräte. Alle diese Module können in dem gleichen Knoten in dem AV-Netz angeordnet oder auf viele Knoten verteilt sein.
  • Geräte-Klassifikation
  • Die Klassifizierung von Geräten auf der Basis der Arten von Aktionen, die sie durchführen, oder die Art des Mediums, mit dem sie arbeiten, ist eine Möglichkeit, die es uns erlaubt, ein generalisiertes Steuer-API zu erzeugen, das für Geräte arbeitet, die in Zukunft hergestellt werden. Das Ziel besteht darin, daß unabhängig von dem Gerätetyp oder dem Hersteller des Geräts immer ein hoher Prozentsatz an Basis-Funktionalität zugänglich ist.
  • Eine herstellerspezifische oder gerätespezifische Funktionalität, die ebenfalls steuerbar ist, jedoch aus dem generalisierten Steuer-API herausfällt, ist nur über die SDD-Information und andere Technologien zugänglich, um eine DCM zu erweitern.
  • In der allgemeinsten Form kann die Klassifikation von Geräten oder Untergeräten durch ihre Hauptfunktionalität geschrieben werden. Das AV/C-Steuerprotokoll des 1394-Standards benutzt ein bequemes Verfahren zu Klassifizieren von Geräten, das wir unten übernommen haben. Im folgenden wird die erste Gruppe von Faktoren angegeben, die für die Klassifizierung eines Geräts oder Untergeräts benutzt werden:
    • 1) Ob ein spezielles Gerät einen Transportmechanismus besitzt,
    • 2) ob der Nutzen diese Untergeräts meistens durch die Tatsache definiert ist, daß ein Signal hier endet (unabhängig von der Tatsache, daß es ohne Änderungen ausgebreitet werden kann).
    • 3) ob ein spezielles Untergerät eine Signalquelle ist (z.B. einen Signalausgang hat).
    • 4) ob ein spezielles Gerät ein Eingangssignal aufnimmt, irgendeine Art von Verarbeitung durchführt und dann modifizierte Daten ausgibt.
    • 5) ob es keinen Signaleingang oder -ausgang irgendwelcher Art gibt (das Gerät ist z.B. eine Einrichtung eines bestimmten Typs, z.B. ein Mechanismus zum Positionieren einer Satellitenantenne).
  • Gemäß vorliegender Erfindung lassen sich in einer zweiten Klassifizierungs-Schicht Geräte untersuchen, die einen Transportmechanismus enthalten. In diesem Fall könnte eine generelle Frage lauten: "Arbeitet dieses Gerät mit entfernbaren Medien?". Wenn dies der Fall ist, wird eine Basisgruppe von Steuerungen angewendet, wie Play(), Stop() oder auch Suchen(). Geräte mit Medien können nach ihrer Fähigkeit zur Aufzeichnung abgefragt werden, um die Organisation der Information auf dem Medium zu bestimmen (Ist sie spurbasiert? Kontinuierlich wie ein Band? Wie wird sie gemessen – SMPTE-Zeitcodes, Zeitversatz gegenüber einer bestimmten Position usw.).
  • In der vorliegenden Erfindung kann ein Signalverarbeitungs-Service durch die Art des Signals (der Signale) beschrieben werden, das (die) er akzeptieren kann, und die Art, die er als Ergebnis produzieren kann. Dies erfordert die Einrichtung gemeinsamer Definitionen für die Beschreibung von Signaltypen und von Verfahren für den Zugriff auf die Services, so daß ein Client erkennen kann, wie er beschreiben muß, nach welcher Art von Service gesucht werden soll und wie auf diesen Service zugegriffen wird.
  • Ein Gerät, das eine Art von Daten akzeptiert und die Möglichkeit bietet, diese Daten an verschiedene Verbindungstypen übertragen kann (es nimmt z.B. digitales Video als Eingangssignal auf und besitzt analoge Standard-Video-RCA-Klinkenstecker, die die Daten zurücksenden können), kann als Datenwandler-Klasse agieren. Das DCM für diese Geräte registriert sich selbst als Datenwandler in der Registrierdatenbank des Systems, so daß Clients sie finden und benutzen können, falls dies erforderlich ist.
  • Gerätezugriff und -Steuerung
  • Sobald eine Basis-Geräteklassifikation durchgeführt wurde, liefert das generische DCM, das für dieses Gerät instantiiert wurde, erfindungsgemäß ein API, das veranlaßt, daß Nachrichten zu diesem Gerät gesendet werden. Die Basisgruppe von Steuernachrichten, die (im Fall von Ereignissen) zu einer speziellen Geräteklasse gesendet oder von dieser empfangen werden können, ist standardisiert und in der (in dieser Version des Dokuments nicht verfügbaren) Anlage detailliert. In der vorliegenden Erfindung repräsentieren diese Nachrichten ein Basis-API, das von dem DCM präsentiert wird.
  • Geräte-Management
  • Gemäß vorliegender Erfindung stellt das DCM-API auch eine Gruppe von Services einer höheren Schicht zur Verfügung, die eine komplexere Verwaltung des Geräts ermöglichen. Beispiele hierfür umfassen die Gerätereservierung und das Ereignis-Management. Im Fall der Gerätereservierung ist es wahrscheinlich, daß eine Anforderung für ein Gerät wegen bereits vorhandener Anforderungen für dieses Gerät zurückgewiesen werden kann oder alternativ die Geräteanforderung für eine zukünftige Reservierung für ein zeitbasiertes Makro benutzt werden kann. In diesen Fällen liefert das DCM ein Interface, das es einer Anwendung oder einem Service ermöglicht, Anforderungen mit dem DCM in einer Warte schlange anzuordnen, d.h. ein Gerät zu reservieren oder eine Meldung zu empfangen, wenn ein Gerät verfügbar wird.
  • Verbindungs-Management
  • Die DCMs der vorliegenden Erfindung stellen auch ein High-LeveI-API zur Verfügung, um es anderen Objekten zu ermöglichen, den Zustand von Verbindungen zwischen Geräten abzufragen und solche Verbindungen zu manipulieren. Dieses API wird primär von dem Routen-Manager benutzt, ist jedoch auch für irgendein anderes Objekt in dem System verfügbar. Das Verbindungs-Management erlaubt die Einrichtung von Verbindungen sowohl intern zwischen Untergeräteeinheiten als auch extern zwischen Geräten. Der Verbindungsstatur kann abgefragt werden, und die Verbindungsmöglichkeiten (Signalformate) können ebenfalls abgefragt werden.
  • SDD-Management
  • Die DCMs der vorliegenden Erfindung stellen auch dem SDD-Management ein generalisiertes Interface zur Verfügung. Dies ermöglicht es, daß die SDD-Daten in dem Gerät abgefragt und benutzt werden können. Das API ist in zwei Teile unterteilt. Teil 1 liefert APIs zur Erlangung wohlbekannter Informationen aus den SDD-Daten, einschließlich des Gerätebilds, seines Namens und (falls verfügbar) der URL-Adresse eines Orts für ein Override-DCM oder andere Icons, die bei der Darstellung des UI des Geräts zu benutzen sind. Teil 2 des SDD-API dient dazu, einen detaillierteren Zugriff auf funktionelle Aspekte des Geräts zu verschaffen.
  • Geräte-Darstellung und Benutzer-Interface (Ui)
  • Gemäß vorliegender Erfindung ist das DCM auch verantwortlich für die UI-Aspekte des Geräts. Im Fall der Schicht-1-Interoperabilität wird ein generisches UI benutzt, um eine Schnittstelle mit Benutzern herzustellen. Dies kann durch Basis-SDD-Daten erweitert werden, die Aspekte ermöglichen, wie das Spezifizieren von UI-Icons und der Zugriff auf sie durch das generische DCM. Um das Verständnis der Erfindung nicht unnötig zu erschweren, werden die Details, wie das DCM mit dem UI-Management-System zur Darstellung eines gerätespezifischen UI zusammenwirkt, nicht im einzelnen diskutiert. In der vorliegenden Erfindung besteht das Basismodell jedoch darin, daß ein interner Management-Code in dem DCM mit dem UI-Management-System zusammenarbeitet, um ein UI für das Gerät zu repräsentieren. Die Benutzereingabe wird dann von dem UI-Management-System an das DCM weitergegeben, das sie dann in gerätespezifische Befehle umwandelt. Diese Befehle werden mit Hilfe des Basis-Nachrichtensystems an das Gerät gesendet. Falls Ant worten empfangen werden, werden diese über das DCM an das UI weitergeleitet. Darüber hinaus werden irgendwelche Statusänderungen des Geräts, z.B. Ein-/Ausschalten, ebenfalls über das Ereignissystem an das DCM weitergegeben, das sie für die Aktualisierung des UI benutzt.
  • Service-Module
  • Service-Module (z.B. die Service-Module 730) haben ein ähnliches Konzept wie Geräte-Steuermodule. Sie liefern ein Interface zu einem Service, der üblicherweise nur durch Software zur Verfügung steht. In der vorliegenden Erfindung gibt es zwei Typen von Service-Modulen, nämlich System-Services und Anwendungs-Services. Ein System-Service ist ein allgemein bekannter Service, der als Teil der HAVI-Software-Architektur vorgesehen ist. Beispiele für diesen Servicetyp sind Datenformat-Übersetzer, Protokollwandler oder Graphik-Services. Diese Services haben allgemein bekannte APIs, die als Teil der HAVI-Architektur definiert sind. Anwendungs-Services sind Objekte, die für und durch andere Service-Objekte erzeugt wurden. Diese Objekte liefern ein wohldefiniertes API, wobei dieses API jedoch nicht öffentlich ist. In der vorliegenden Erfindung benötigt jede Anwendung oder jedes andere Objekt, das ein Anwendungsobjekt benutzten möchte, die Kenntnis seines API und der Ruf-Semantik. Obwohl dies nicht erforderlich ist, existieren System-Services im allgemeinen während der ganzen Lebensdauer des Systems. Anwendungs-Services existieren während der Lebenszeit einer Anwendung und können sehr kurzlebig sein.
  • System-Services
  • Gemäß vorliegender Erfindung sind viele der von der AV-Architektur zur Verfügung gestellten Services als Service-Module vorgesehen, die ihre Services in der Registrierdatenbank des Systems registrieren und auf die mittels Nachrichtübermittlung zugegriffen werden kann. Beispiele für solche Services sind die UI-Service-Module, die einen Mechanismus zur Verfügung stellen, der es Geräten ermöglicht, dem Benutzer ein UI zu präsentieren, Datenformat-Services, die AV-Daten zwischen verschiedenen Formaten umwandeln.
  • DER DCM-MANAGER
  • Überblick
  • Gemäß vorliegender Erfindung ist der DCM-Manager für alle Aspekte zur Behandlung der Sammlung von DCMs verantwortlich, die in einem FAV-Knoten residieren. Dies umfaßt die Aufgaben, alle möglichen Geräte-Steuermodul-Kandidaten zu entdecken, zu instantiieren und anzuordnen, die in einem gegebenen System verfügbar sind. Das Geräte-Ressourcen-Management wird im allgemeinen von individuellen DCMs durchgeführt. Falls jedoch mehrere Geräte oder Services interagieren und einige der DCMs in verschiedenen FAV-Knoten angeordnet sind, wird ein Higher-Level-Management benötigt. Deshalb kommuniziert der DCM-Manager mit anderen DCM-Managern in entfernten Knoten, um über die netzwerkweite Zuteilung und Verwaltung von Geräte- und Untergeräte-Ressourcen zu entscheiden. Seine Verantwortlichkeiten werden weiter unten diskutiert.
  • Entdeckung und Aufzählung von physikalischen Geräten
  • Gemäß vorliegender Erfindung arbeitet der DCM-Manager mit den zugrunde liegenden Services des Betriebssystems zusammen, um eine rohe Liste der verfügbaren Geräte zu gewinnen. Es ist zu beachten, daß diese DCMs in Abhängigkeit von der zugrundeliegenden Bus-Technologie dynamisch sein können. Wenn in dem vorliegenden Ausführungsbeispiel physikalische Geräte beispielsweise auf einem 1394-Bus kommen und gehen, kommen und gehen die DCMs mit ihnen. In der gleichen Weise sind auch die Service- und Gerätekomplex-DCMs dynamisch, die als Reaktion auf Ereignisse in dem FAV-Knoten erzeugt und zerstört werden.
  • Diese Aufgabe erfordert eine Interaktion sowohl mit Elementen der AV-Architektur als auch mit Elementen des FAV-Host-OS, der Knoten-Hardware und der Kommunikations-Hardware. Dies ist darauf zurückzuführen, daß der exakte Prozeß, der für die Entdeckung von Geräten erforderlich ist, von der Systemumgebung abhängt. Der generelle Lösungsweg zur Abfrage eines Geräts und irgendwelcher SDD-Daten, die es enthält, um seine Eigenschaften zu entdecken, wie dies oben in dem DCM-Abschnitt diskutiert wurde, ist jedoch gemeinsam. In dem vorliegenden Ausführungsbeispiel erfordert dies, daß der DCM-Manager jedesmal, wenn das System initialisiert wird oder jedesmal, wenn das System sich ändern kann (z.B. wenn der Bus zurückgesetzt wird), einen Satz Regeln in einer gegebenen Sequenz befolgt.
  • Erzeugung von generischen DCMs
  • Gemäß vorliegender Erfindung arbeitet der DCM-Manager für jeden Knoten genug, um festzustellen, daß er ein DCM erzeugen soll. Diese Arbeit wird für alle medienbezogen Geräte durchgeführt, die von dem FAV-Knoten verwaltet werden. In dem vorliegenden Ausführungsbeispiel können Geräte unter einer abweichenden Management-Technologie, z.B. USB-basierte Geräte, innerhalb der Architektur als DCMs in Knoten präsentiert werden, die USB-Kommunikation unterstützen, oder als spezielle DCMs, die als Proxies für ein entferntes Management-System arbeiten. Es ist jedoch zu beachten, daß einige USB-basierte Geräte, wie Festplattenlaufwerke, in Wirklichkeit so beschaffen sein können, daß sie einfach als Medien-Aufzeichnungs- oder -Wiedergabegeräte mit wahlfreiem Zugriff erscheinen. In diesen Fällen werden sie als ein anderes "reales" Mediengerät behandelt. In dem vorliegenden Ausführungsbeispiel erzeugt der DCM-Manager für jede medienbezogene Entität ein generisches oder Schicht-1-DCM. Jedes DCM trägt später selbst die Verantwortung dafür, daß es sich selbst medienspezifischer macht, falls dies möglich ist. Dies wird weiter unten beschrieben.
  • Integration von Schicht-2-DCMs
  • In Fällen, in denen ein Override-(z.B. Schicht-2)-DCM verfügbar und zugänglich ist, ist der DCM-Manager dafür verantwortlich, zu versuchen, dieses DCM abzurufen und es in dem FAV-Knoten zu installieren. In dem vorliegenden Ausführungsbeispiel sind die Details, wie das Override-DCM und das generische DCM interagieren, von dem DCM-Entwickler abhängig. In einigen Fällen ersetzt es z.B. das Default-DCM vollständig, in anderen Fällen arbeitet es mit dem Default-DCM zusammen, um dessen Fähigkeiten zu erweitern.
  • Gemäß vorliegender Erfindung können vom Hersteller gelieferte Schicht-2-DCMs aus verschiedenen Quellen stammen. So können Geräte sie in ihrer ROM oder einem anderen Speichermechanismus, wie dem Header einer Platte oder eines Bandes, mit sich führen. Sie können von einer Netz- oder ftp-Seite heruntergeladen werden, wenn solche Möglichkeiten dem FAV-Knoten zugänglich sind, oder sie können in der typischen Art der Computerindustrie über eine Installation von einer Platte oder einem anderem Speichermedium geliefert werden. Um diese vom Hersteller gelieferte Override-DCM-Fähigkeit zu ermöglichen, wird ein Modell zum Erzeugen und Installieren von DCMs benötigt. In dem vorliegenden Ausführungsbeispiel liefert das Schicht-2-DCM, wenn es installiert ist, dem Client das gleiche Basis-Interface wie ein Schicht-1-DCM, während es entweder zusätzliche Interfaces oder Modifikationen der zugrundeliegenden Funktionalität bereitstellt.
  • DCM-Entfernung
  • Gemäß vorliegender Erfindung ist der DCM-Manager dafür verantwortlich, daß DCMs zu geeigneten Zeiten entfernt werden und den Clients gemeldet wird, daß DCMs entfernt wurden. In dem vorliegenden Ausführungsbeispiel können die Regeln dafür, wann eine DCM-Entfernung stattfindet, und die Verteilung der Verantwortlichkeit für das Säubern zwischen dem DCM und dem DCM-Manager passend auf die spezifischen Erfordernisse eines speziellen HAVI-Netzes abgestellt werden.
  • Koordinieren zwischen Mehrfach-DCMs
  • Einige komplexe Services unter Mehrfach-DCMs, z.B. das Anordnen von Befehlen von komplexen Operationen in einer Warteschlange usw., machen es erforderlich, daß der DCM-Manager Mehrfach-DCMs koordiniert, um diese Operationen auszuführen. Dies wird durch das "Befehlsmodell" beeinflußt, das es für Clients vorsieht. Wenn z.B. ein API einer oberen Schicht definiert wird, mit dem der Kunde Aktionen auf der Basis von HH:MM:SS:FF-Zeitcodes spezifizieren kann, muß zwischen diesem Zeitmodell und dem, womit die Hardware oder die zugrundeliegenden Unterstützungs-Module umgehen, übersetzt werden. Es ist zu beachten, daß komplexen, zeitbasierten Operationen Rechnung getragen werden muß, die durch mechanische Verzögerungen usw. beeinflußt werden können. Dieser Typ von Koordination erfordert die Beachtung des Echtzeitverhaltens in dem Netz und ist von der physikalischen und der Software-Infrastruktur abhängig, die eine gewisse Garantie liefern muß.
  • Es sei nun auf 8 Bezug genommen, in der ein logisches Schichtdiagramm 800 einer HAVI-Architektur gemäß vorliegender Erfindung dargestellt ist. Die in dem Diagramm 800 dargestellte Komponenten gleichen den in dem Diagramm 700 dargestellten Komponenten, wobei das Diagramm 800 jedoch so organisiert ist, daß Prozesse einer hohen Schicht (z.B. Anwendungen 801) oben angeordnet sind, während Prozesse einer niedrigeren Schicht (z.B. das 1394-Modul 830) unten angeordnet ist. Das Diagramm 800 zeigt auch andere Services 810, Transport-Adaptierungs-Module 815 und andere Module 840.
  • Wie oben beschrieben wurde, kann die HAVI-Gesamtarchitektur in Form von Kommunikations-Komponenten und Service-Komponenten dargestellt werden. Anwendungen 801 in der höchsten Schicht der Architektur benutzen die Services und die Kommunikations-Komponenten (z.B. DCMs 720, Service-Module 730 usw.). Umgekehrt benutzt eine Anzahl von Service-Komponenten (z.B. die Service-Module 730, die DCMs 720 usw.), die zugrundeliegenden Kommunikations-Komponenten (z.B. das Messaging 702, die Transport-Adaptions-Module 815 usw.). So kann z.B. eine der Anwendungen 801 über die Registrierdatenbank 706 das Handle für einen digitalen Videorekorder (DVTR) anfordern und dann einen Abspiel-Befehl an das Gerät senden. Wie oben beschrieben wurde, kommunizieren Komponenten in der HAVI-Architektur unter Verwendung des zugrundeliegenden Nachrichtensystems, d.h. die Module benutzen Nachrichtenübermittlung.
  • 9 zeigt ein Diagramm 900 mit lokaler und entfernter Nachrichtenübermittlung in der HAVI-Architektur eines Ausführungsbeispiels. Die Nachrichten-Komponente 702 ist so dargestellt, daß sie sowohl lokale Nachrichtenübermittlung als auch entfernte Nachrichten übermittlung handhabt. Deshalb ist die Nachrichten-Komponente 702 als Basis des Diagramms 900 dargestellt. Lokale Nachrichten sind als Abschnitte 902a, 903a, 904a zu verschiedenen Anwendungen 901 bis 904 dargestellt. Eine entfernte Nachricht ist als Pfeil 901b dargestellt. Aus Gründen der klaren Darstellung ist in dem Diagramm 900 und in den folgenden Diskussionen die lokale Kommunikation über das Nachrichten-System nicht gezeigt. Lokale Nachrichtenübermittlung (z.B. die Pfeile 901a bis 904a) ist vielmehr so dargestellt, als ob sie auf direkten Funktions-Abrufen zwischen Komponenten basieren würden.
  • 10 zeigt ein Diagramm 1000 einer Nachricht, die in der HAVI-Architektur eines Ausführungsbeispiels über 1394 gesendet wird. In dem Diagramm 1000 ist eine Nachricht 1 (z.B. der Pfeil 820a) eine Anforderung von einer der Anwendungen 801 an die Registrierdatenbank 706 (über das Abruf-API) für das Handling eines DVTR-Geräts. Die Registrierdatenbank 706 schickt in der Nachricht 2 (z.B. Pfeil 820b) ein Handle für das DVTR-DCM zurück. Dieses Handle ist die Nachrichtenadresse, die für das Nachrichtensystem benutzt wird.
  • Gemäß vorliegender Erfindung benutzt die Anwendung dann das Handle, um mit der Nachricht 3 (z.B. 820c) das DCM für den DVTR aufzurufen. Das DCM wandelt den Anwendungs-Aufruf des Abspiel-Befehls in einen internen Befehl um, der zu der Nachrichten-Komponente gesendet wird, Nachricht 4 (z.B. Pfeil 820d). Dieser interne Befehl ist Teil des wohldefinierten Befehlssatzes der Schicht 1, d.h. es ist ein HAVI-Befehl. Die Nachrichten-Komponente 702 benutzt dann intern die Handle-Information um festzulegen, an welchem Bus sich dieses Gerät befindet. Wenn sie entdeckt, daß es an den IEEE-1394-Bus angeschlossen ist, benutzt es das IEEE-1394-Transport-Adaptions-Modul (TAM) 830, um die Nachricht in ein 1394-Paket umzuwandeln, Nachricht 5 (z.B. Pfeil 820e), das in dem Datenteil eines FCP-Pakets angeordnet wird. Das TAM ruft dann den 1394-Gerätetreiber, Nachricht 6 (z.B. Pfeil 820f), um die Nachricht über 1394 zu senden.
  • Auf der (nicht dargestellten) Empfangsseite wird die Nachricht an den 1394-Gerätetreiber ausgeliefert und dann über ein 1394-TAM an die Nachrichten-Komponente weitergegeben. Die Nachrichten-Komponente empfängt ein HAVI-Nachrichtenpaket, das sie dann über eine Nachrichten-Warteschlange oder eine Rückruffunktion direkt an den Empfangs-Code liefert. Wenn das empfangene Gerät in dem vorliegenden Ausführungsbeispiel ein IAV-Gerät ist, besitzt dieses nur die Kommunikations-Komponente der CCEP-Architektur und die Registrierdatenbank. Jede andere Funktionalität, die sie besitzt, ist gerätespezifisch.
  • Es ist zu erwähnen, daß das vorherige Beispiel in 10 eine Unterscheidung in der HAVI-Architektur zwischen dem Nachrichten-System und dem für die Steuerung von Geräten benutzten Befehlssatz zeigt. Gemäß vorliegender Erfindung ist das Nachrichten-System ein allgemeiner Nachrichten-Mechanismus, der ein Nachrichtenpaket mit einem Datenteil vorsieht, dessen Inhalte für das Nachrichten-System völlig undurchsichtig sind. Das Nachrichten-System kann z.B. eine private Anwendung an Anwendungsbefehle, AVC-CTS-Befehle, CAL-Befehle oder an irgendeinen anderen Befehl übergeben. Das DCM ist die Entität, die für die Kommunikation mit entfernten Geräten verantwortlich ist, es benutzt das Nachrichten-System zum Transportieren von Befehlen, die für dieses Gerät spezifisch sind. Für ein Schicht-1-HAVI-konformes Gerät ist der von dem Nachrichten-System transportierte Befehlssatz als Teil der CCEP-Architektur definiert. Nachrichten, die von dem Nachrichten-System zwischen DCMs und Geräten transportiert werden, die sie steuern, enthalten diese wohldefinierten Befehle. Für Schicht-2-Geräte ist der erweiterte Befehlssatz undefiniert, es können reine AV/C-CTS, CAL- oder irgendwelche anderen Befehle sein.
  • Es sei nun auf 11 Bezug genommen, in der ein Diagramm 1100 einer Anwendung dargestellt ist, die eine andere Anwendung in einem Ausführungsbeispiel der HAVI-Architektur aufruft. Das Diagramm 1100 zeigt eine auf einem Gerät 1101 laufende Anwendung 801a, die eine Nachricht 1105 der Nachrichten-Systeme 702a und 702b an eine Anwendung 801b weitergibt, die auf einem getrennten Gerät 1102 läuft. Wie oben beschrieben wurde, kann jede Anwendung, die in dem HAVI-Netz läuft, auf irgendeine andere Anwendung zugreifen, wenn sie ein Nachrichten-Handle für diese Anwendung besitzt. Um ein Nachrichten-Handle zu akquirieren, wird der gleiche Prozeß benutzt wie für ein entferntes IAV-Gerät (z.B. wie in 10 beschrieben). Sobald ein Nachrichten-Handle verfügbar ist, kann die Quell-Anwendung 801a eine Nachricht 1105 an die Ziel-Anwendung 801b senden. Wie oben beschrieben wurde, ist das Format dieser Nachrichten völlig abhängig von der Anwendung und betrifft somit die CCEP-Architektur nicht. Es liefert einfach einen Kommunikations-Mechanismus zum Senden und Empfangen von Nachrichten zwischen den Anwendungen.
  • Es ist zu beachten, daß in dem obigen Beispiel angenommen wird, daß die Anwendungen 801a und 801b sich in verschiedenen AV-Geräten 1101 und 1102 befinden. Wie oben diskutiert wurde, ist es jedoch ohne weiteres auch möglich, daß diese Anwendungen 801a und 801b sich in dem gleichen AV-Gerät befinden und das Nachrichten-System einen rein lokalen Kommunikations-Anruf ausführt statt eines Anrufs, der zum Transportieren der Nachricht das 1394-Netz benutzt.
  • Aufrufen eines Software-Service
  • Ein Software-Service ist ein spezieller Fall des obigen allgemeinen Anwendungsfalls. Gemäß der Erfindung ist ein Software-Service einfach eine Anwendung, die Teil der System-Infrastruktur ist. Wenn in diesem Fall ein Modul einen System-Service, z.B. die UI-Komponente aufrufen möchte, benutzt es hierfür die Nachrichten-Komponente. Falls die UI-Komponente lokal ist, ist der Anruf vollständig in einem AV-Gerät enthalten. Falls die UI-Komponente entfernt ist, wird der Anruf hingegen über das 1394-Netz zu dem entfernten AV-Gerät geleitet, in dem das Nachrichten-System den Anruf an den UI-System-Service sendet.
  • Hinzufügen eines neuen Geräts zu dem HAVI-Netz
  • Beim Hinzufügen von neuen Geräten zu einem HAVI-Netz gibt es drei generelle Situationen: Behandlung eines Legacy-Geräts unter Verwendung eines Legacy-Protokolls, das über ein Nicht-1394-Netz transportiert wird; Behandlung eines Basis-Geräts unter Verwendung eines Nicht-HAVI-Protokolls über ein 1394-Netz und Behandlung eines neuen IAV-Geräts, das HAVI-konform ist.
  • Im Fall des Hinzufügens eines Legacy-Geräts in dem vorliegenden Ausführungsbeispiel kann ein Legacy-Gerät nur direkt von einem FAV-Knoten gesteuert werden. Wie oben beschrieben wurde, muß für jedes Legacy-Gerät ein Legacy-DCM erzeugt werden. Es sei ein FAV betrachtet, das einen 1394-Port und einen Ethernet-Port besitzt. Das CMM-Modul wurde so konfiguriert, daß es sowohl 1394 als auch Ethernet verwaltet. Wenn das Legacy-Gerät dem FAV bekannt wird, wird es zunächst von dem CMM-Modul erkannt. Es ist zu beachten, daß der hierfür benutzte Mechanismus nicht im Rahmen der CCEP-Architektur liegt. Er ist für die Kommunikationsmedien spezifisch. Sobald das CMM ein neues Gerät erkennt, geht es über den von ihm benutzten medienspezifischen Mechanismus daran, den Typ des Geräts zu bestimmen. Dies ist wieder nicht Teil der CCEP-Architektur. Es fordert das DM ggf. auf, ein Legacy-DCM für dieses Gerät zu instantiieren. Es sei angenommen, daß der FAV-Knoten mit diesem DCM vorkonfiguriert wurde.
  • Sobald in dem vorliegenden Ausführungsbeispiel das DCM erzeugt ist, registriert es sich selbst in der gleichen Weise wie irgendein Standard-DCM. Ein schwieriger Unterschied zwischen diesem DCM und anderen DCMs besteht jedoch darin, daß das Kommunikationsmodell und der Befehlssatz, der für die Steuerung des Legacy-Geräts benutzt wird, der CCEP-Architektur völlig unbekannt sind. Es ist z.B. möglich, daß das Gerät ein IP-Gerät ist, das einen Druckerservice implementiert. In diesem Fall liefert das DCM einen Befehlssatz, wie Drucken, Status usw. Wenn eine Applikation das DCM-API mit einer Druckanforderung aufruft, wird der Druckbefehl von dem DCM über einen IP-Stapel an die Druck vorrichtung gesendet. Die tatsächlichen Details, wie dies geschieht, sind implementationsspezifisch.
  • Gemäß vorliegender Erfindung besteht eine Möglichkeit darin, daß das Legacy-DCM eine volle Implementierung des IP-Stapels in dem DCM aufweist und weiß, wie der Ethernet-Gerätetreiber einzubinden ist. Eine andere Möglichkeit besteht darin, daß das FAV-Gerät einen IP-Stapel und ein Higher-Level-API, wie z.B. Steckverbindungen, zur Verfügung stellt. Dies sind Details der FAV-Implementierung und nicht Teil der CCEP-Architektur. Es ist jedoch zu beachten, daß das Legacy-DCM als "Proxy"-DCM arbeitet. Sobald es in der Registrierdatenbank registriert wurde, ist es für alle anderen Module in dem Heim-Netz sichtbar. Sie können alle sein API aufrufen, und es führt die notwendige Umwandlung in die private Befehlssprache des Ethernet-IP-Druckers durch.
  • Falls in dem vorliegenden Ausführungsbeispiel ein Basis-AV-Gerät hinzugefügt wird und wenn das CMM über das neue Gerät informiert ist, erkennt es, daß dies kein CCEP-Knoten ist, es entdeckt jedoch auch, daß ein DCM für dieses Gerät verfügbar ist. In diesem Fall ist das CMM dafür verantwortlich, einen Mechanismus zu implementieren, der es ihm erlaubt, das DCM zu laden und das DM aufzufordern, dieses DCM zu erzeugen. Sobald das DCM instantiiert ist, benutzt es dann einen rein privaten Kommunikationsmechanismus, um auf das Gerät zuzugreifen und es zu steuern. Wie oben beschrieben wurde, ist in dem vorliegenden Ausführungsbeispiel ein Basis-AV-Gerät ein solches, das 1394 benutzt und das Override-DCM implementiert, jedoch kein Teil der CCEP-Architektur implementiert und keine Schicht-1-HAVI-Befehle implementiert. Ein Beispiel für dieses Gerät könnte ein solches sein, das ein Override-DCM enthält, die CCEP-Kommunikations-Infrastruktur jedoch nicht unterstützt.
  • Für den Fall, daß ein IAV-Gerät hinzugefügt wird, ist zu beachten, daß die Anwendung in den vorangehenden Beispielen die Registrierdatenbank abfragt, um ein Nachrichten-Handle für das Gerät zu erlangen, mit dem es kommunizieren möchte. Es ist zu beachten, daß für ein FAV-Gerät das zurückgesendete Handle immer für den Zugriff auf das DCM benutzt wird. Es ist nicht möglich, Nachrichten direkt zu dem Gerät zu senden. Das folgende Beispiel dient dazu, zu verstehen, wie ein zu dem Netz hinzugefügtes Gerät über die Registrierdatenbank verfügbar wird.
  • Es sei z.B. angenommen, daß ein neues Gerät (z.B. ein Camcorder) in das (z.B. 1394-basierte) HAVI-Netz eingesteckt wird. Dies verursacht ein Rücksetzen des Busses. Das Rücksetzen des Busses wird von dem Kommunikations-Medien-Manager (CMM) in dem IRD bewirkt. Das CMM ist verantwortlich, die SDD-Daten des Camcordergeräts abzufragen, um seine Fähigkeiten zu ermitteln. Wenn man annimmt, daß das Gerät ein Schicht-1- Gerät ist, d.h. kein ladbares DCM hat, informiert das CMM den Geräte-Manager, daß ein neues Gerät installiert wurde. Der Geräte-Manager erzeugt ein neues DCM für diesen Gerätetyp und registriert das DCM mit der Registrierdatenbank. Wenn das DCM initialisiert wird, steht es ihm frei, um das Gerät direkt abzufragen, um mehr Informationen über dieses selbst herauszufinden und sich selbst, falls nötig, zu spezialisieren, es kann z.B. auf die UI-Information zugreifen, wenn diese in dem Gerät existiert. Sobald das DCM in der Registrierdatenbank registriert ist, kann ein anderes Modul die Registrierdatenbank abfragen, um ein Handle für das Gerät zu erlangen und mit dem DCM kommunizieren, um auf das Gerät zuzugreifen und es zu steuern und dem Benutzer das UI zu präsentieren.
  • 12A und 12B zeigen eine exemplarische UI-Anzeige (z.B. auf einem Fernsehbildschirm) für ein solches Gerät (z.B. den Camcorder). 12A zeigt eine Textmenü-Anzeige, in der dem Benutzer verschiedene Steuerungen präsentiert werden, die mit Hilfe der Steuerungsnamen und Steuerungswerte modifiziert werden können. Der Benutzer kann Tasten wählen (was dem Drücken einer Taste gleicht). 12B zeigt eine UI-Anzeige der "nächsten Schicht" für den Camcorder. Hier wählte der Benutzer das Hauptpanel aus dem Menü in 12A, und die Anzeige präsentiert Steuerungen auf der Basis ihrer Gruppierungs-Information. In dem vorliegenden Ausführungsbeispiel werden Gruppennamen auf einem mit Registerkarten versehenen Interface benutzt, um dem Benutzer das Navigieren zwischen Gruppen innerhalb des ausgewählten Paneels zu ermöglichen.
  • Es sei nun auf 13 Bezug genommen, in der ein Flußdiagramm eines Prozesses 1300 nach einem Ausführungsbeispiel der Erfindung dargestellt ist. Der Prozeß 1300 zeigt die Schritte eines Verfahrens zur Bereitstellung von nahtloser Interoperabilität und Integration einer Mehrzahl von Geräten in einem HAVI-Netzwerk mit Hilfe der in jedem Gerät gespeicherten SDD-Information. Der Prozeß 1300 beginnt in dem Schritt 1301, in dem ein neues Gerät an das HAVI-Netz angeschlossen wird. In dem Schritt 1302 wird das Gerät abgefragt, um eine Beschreibung (z.B. SDD) von Schicht-1-Funktionen zu erhalten, die von dem Gerät unterstützt werden. In dem Schritt 1303 wird auf der Basis der SDD ein Schicht-1-DCM, das die Schicht-1-Funktionen implementiert, für das Gerät erzeugt. In dem Schritt 1304 prüft der Geräte-Manager, ob das neue Gerät Software für ein Schicht-2-DCM enthält.
  • Es sei weiter auf 13 Bezug genommen. Falls das neue Gerät Software zum Implementieren von Schicht-2-Funktionen enthält, wird die Software in dem Schritt 1305 aus dem Gerät aufgerufen, und in dem Schritt 1306 wird unter Verwendung der Software ein Schicht-2-DCM erzeugt, das die Schicht-2-Funktionen implementiert. In den Schritten 1307 und 1308 wird über das Schicht-2-DCM kontinuierlich auf das Gerät zugegriffen. Falls das neue Gerät keine Software für ein Schicht-2-DCM enthält, wird in den Schritten 1309 und 1310 über das Schicht-1-DCM kontinuierlich auf das Gerät zugegriffen. Auf diese Weise ermöglicht die Kombination aus der Schicht-1-DCM und der Schicht-2-DCM der Erfindung, eine nahtlose Interoperabilität und Integration des neuen Geräts mit der Mehrzahl von Geräten in dem Netz bereitzustellen.
  • 14 zeigt ein Flußdiagramm eines Prozesses 1400 nach einem Ausführungsbeispiel der Erfindung. Der Prozeß 1400 zeigt die Schritte eines Verfahrens zur Bereitstellung einer Basis-Befehls-Funktionalität und einer erweiterten Befehls-Funktionalität zwischen mehreren Geräten in einem HAVI-Netz. In dem Schritt 1401 wird ein Gerät mit dem HAVI-Netz verbunden, das ein FAV-Gerät enthält. In dem Schritt 1404 erzeugt das FAV-Gerät ein generisches Schicht-1-DCM für das Gerät. Wie oben beschrieben wurde, ist das generische Schicht-1-DCM eine Basis-Abstraktion der Fähigkeiten des Geräts. Das generische Schicht-1-DCM versetzt das Gerät in die Lage, auf einen Basis-Befehlssatz aus dem FAV-Gerät zu antworten. In den Schritten 1403 und 1404 benutzt das FAV-Gerät das generische DCM, um das Gerät abzufragen und festzustellen, ob das Gerät eine beschreibende Information (z.B. SDD) enthält. Wie oben beschrieben wurde, beschreibt die beschreibende Information die Fähigkeiten des Geräts. Falls das Gerät beschreibende Informationen enthält, erzeugt das FAV-Gerät in dem Schritt 1405 ein parametrisiertes DCM für das Gerät, indem es das generische DCM auf der Basis der beschreibenden Information modifiziert. In den Schritten 1406 und 1407 wird das Gerät unter Verwendung des parametrisierten Schicht-1-DCM kontinuierlich gesteuert. Falls das Gerät keine beschreibende Information enthält, wird das FAV-Gerät in den Schritten 1408 und 1409 kontinuierlich über das generische Schicht-1-DCM gesteuert.
  • Es sei nun auf 15 Bezug genommen, in der ein Flußdiagramm eines Prozesses 1500 nach einem Ausführungsbeispiel der Erfindung dargestellt ist. Der Prozeß 1500 zeigt die Schritte eines Verfahrens zur Sicherstellung zukünftiger Aufrüstbarkeit und Erweiterbarkeit von Geräten in einem HAVI-Netz. In dem Schritt 1501 wird ein Schicht-1-Default-DCM für ein mit dem Netz verbundenes Gerät erzeugt. Wie oben beschrieben wurde, ist das Schicht-1-Default-DCM so konfiguriert, daß es zumindest einen minimalen Grad an Interoperabilität zwischen dem Gerät und anderen Geräten an dem HAVI-Netz gewährleistet. In dem Schritt 1502 greifen andere Geräten über das Schicht-1-Default-DCM auf das Gerät zu. Wie oben beschrieben wurde, ermöglicht das Default-DCM dem ersten Gerät, auf einen Default-Befehlssatz aus anderen Geräten in dem HAVI-Netz zu antworten. In dem Schritt 1503 wird ein aktualisiertes Schicht-1-DCM für die Geräte entweder empfangen oder nicht empfangen. In dem Schritt 1504 wird ein aktualisiertes Schicht-2-DCM für das Geräte entweder empfangen oder nicht empfangen. Wie oben beschrieben wurde, ermöglichen die Aktualisierungen eine Weiterentwicklung der Fähigkeiten und der Funktionalität des Geräts (z.B. wenn neue, effizientere Software verfügbar wird).
  • Wenn ein aktualisiertes Schicht-1-DCM empfangen wird, wird dieses aktualisierte Schicht-1-DCM in den Schritten 1509 und 1508 eingebaut (dies kann z.B. darin bestehen, daß nur das laufende Schicht-1-DCM modifiziert wird), und über dieses DCM wird kontinuierlich auf das Gerät zugegriffen, bis eine spätere Aktualisierung verfügbar ist. Wenn ein aktualisiertes Schicht-2-DCM empfangen wird, trennt der DCM-Manager in dem Schritt 1505 das laufende DCM ab, und in den Schritten 1506 und 1507 wird das aktualisierte Schicht-2-DCM verknüpft, und die Registrierdatenbank wird aktualisiert, um anderen Geräten in dem HAVI-Netz den Zugriff auf das aktualisierte Schicht-2-DCM zu ermöglichen. Dieses DCM wird kontinuierlich für den Zugriff auf das Gerät benutzt, bis ein späteres, aktualisiertes Schicht-2-DCM empfangen wird. Wenn weder ein aktualisiertes Schicht-1- noch ein aktualisiertes Schicht-2-DCM empfangen wird, setzt der Prozeß 1500 in dem Schritt 1510 die Operation mit dem laufenden DCM (z.B. dem zuletzt installierten DCM) fort.
  • 16 zeigt ein Flußdiagramm eines Prozesses 1600 nach einem Ausführungsbeispiel der Erfindung. Der Prozeß 1600 zeigt die Schritte eines Verfahrens zum Bereitstellen von nahtloser Interoperabilität und Integration von Legacy-Geräten mit den HAVI-konformen Geräten in einem HAVI-Netz. Der Prozeß 1600 beginnt in dem Schritt 1601, in welchem ein Legacy-Gerät mit dem HAVI-Netz verbunden wird. In dem Schritt 1602 wird das Legacy-Gerät über das proprietäre Protokoll abgefragt, um einen Satz von Basis-Fähigkeiten des Legacy-Geräts zu ermitteln. Wie oben beschrieben wurde, benutzen HAVI-konforme Geräte ein gemeinsames HAVI-definiertes Protokoll. Das Legacy-Gerät kommuniziert typischerweise (falls überhaupt) mit externen Geräten mittels eines proprietären Protokolls. In dem Schritt 1603 bildet der Prozeß 1600 einen Satz von Basisbefehlen aus dem gemeinsamen Protokoll auf den Satz von Basis-Fähigkeiten des Legacy-Geräts ab. In dem Schritt 1604 wird ein Schicht-1-DCM für das Legacy-Gerät erzeugt. Wie oben beschrieben wurde, basiert das DCM auf dem Satz von Basisbefehlen. In den Schritten 1605 und 1606 wird über das Schicht-1-DCM kontinuierlich auf das Legacy-Gerät zugegriffen, so daß die anderen HAVI-Geräte auf den Satz von Basis-Fähigkeiten des Legacy-Geräts zugreifen können.
  • 17A zeigt ein Flußdiagramm eines Prozesses 1700 nach einem Ausführungsbeispiel der Erfindung. Der Prozeß 1700 zeigt die Schritte eines Verfahrens zur Steuerung von Geräten innerhalb eines Heim-Audio-/Video-Netzes unter Verwendung eines Anwendungsprogramms aus einem externen Service-Provider. In dem Schritt 1702 wird ein Anwendungsprogramm von einem Service-Provider (z.B. über Kabelfernsehen, Internet-Webseite usw.) aufgerufen. In dem Schritt 1703 überträgt der Service-Provider das Anwendungsprogramm aus dem Service-Provider zu einem intelligenten Empfangs/Dekodiergerät des HAVI-Netzwerks über einen logischen Kanal. Die Anwendung wird anschließend in einer computerlesbaren Speichereinheit des intelligenten Empfängers/Dekodierers instantiiert.
  • In dem Schritt 1704 von 17A fragt das Anwendungsprogramm die HAVI-Registrierdatenbank des Geräts (z.B. eines FAV-Geräts) ab, um DCMs in dem Netz zu lokalisieren, und wählt ein entsprechendes DCM aus der Registrierdatenbank aus. In dem Schritt 1705 bestimmt die heruntergeladene Anwendung eine Kommunikationspunkt-Information aus dem ausgewählten DCM. In dem Schritt 1706 steuert die Anwendung ein entsprechendes Gerät des HAVI-Netzes durch Kommunikation mit dem Gerät mit Hilfe der Information über den Kommunikationspunkt. Falls die Anwendung ein anderes Gerät steuern soll, werden in dem Schritt 1707 die Schritte 1704 bis 1706 wiederholt. Falls die Anwendung kein anderes Gerät steuern soll, endet der Prozeß 1700 in dem Schritt 1708.
  • 17B zeigt ein Diagramm eines HAVI-Netzes 1750 mit dem Service-Provider 1720 entsprechend dem Prozeß 1700 von 17A. Wie oben beschrieben wurde, wird das Anwendungsprogramm von dem Service-Provider 1720 in das HAVI-Netz 1750 heruntergeladen. Die Anwendung wird in dem Prozessor 601 und dem Speicher 602 des intelligenten Geräts (z.B. der Set-Top-Box 301) instantiiert. Das HAVI-Netz 1750 enthält auch vier HAVI-Geräte, Gerät 0 bis Gerät 3 (z.B. Fernseher, DVTR, usw.).
  • DCM-MANAGEMENT-API
  • Im folgenden wird ein Beispiel für ein DCM-Management-API nach einem Ausführungsbeispiel der Erfindung vorgestellt. In dem vorliegenden Ausführungsbeispiel beinhalten die gemeinsamen DCM-Befehle Bereiche, wie Verbindungs-Management, Informations- und Status-Abfrage für das Gerät und ihre Steckverbindungen usw.. Unabhängig von dem von dem DCM repräsentierten Gerätetyp müssen solche Nachrichten-Sätze unterstützt werden.
  • Das Folgende ist eine Liste von DCM-Management-Nachrichten, die in dem vorliegenden Ausführungsbeispiel von allen DCMs für die HAVI-Architektur unterstützt werden müssen:
    ChannelUsage(plug);//stellt den von der Steckverbindung der spezifizierten Einheit benutzten isoch. 1394-Kanal zurück
    PIugUsage(channel);//stellt die dem spezifierten Kanal zugeordnete Steckverbindung zurück
    GetDevicePIugCount(count);//stellt die Zahl von Einheits-Steckverbindungen an dem Gerät zurück
    EstablishlntemalConnection(sourcePlug, destPlug);
    EstabIishExternalConnection(sourcePlug, destPlug)
    StartDataFlow(plug);
    StopDataFlow(plug);
    GetSourceConnection(in dest, out source);//wenn eine Ziel-Steckverbindung gegeben ist, wird die Quelle zurückgestellt, mit der sie verbunden ist, (stellt die Quellen-Steckverbindung des sendenden Geräts zurück, das denselben isoch. Kanal benutzt)
    GetDestinationConnection(in source, out);
    GetAllConnection();
    NotifyOnConnectionChange();
    GetDynamicConnectionCapability();//berichtet, ob das Zielgerät dynamische Verbindungsänderungen unterstütz oder nicht (z.B. Nicht-1394-Gerät)
    LockConnection(plug);
    UnIockConnection(plug);
    GetConnectionStation(plug);//Status = besetzt, Datenübertragungsformat, Kanal, Bandbreitenbenutzung, usw.
    BreaklnternalConnection(plug);
    BreakExternalConnection(plug);
    GetlnputSignalFormat(plug);
    setlnputSignalFormat(plug);
    NotifylnputSignaIFormat(plug);//sendet eine Meldung, falls Signalformat geändert ist
    GetSupportedInputSignaIFormats(plug);//wiederhole das obige für Ausgangssignale
    GetFunctionlnfo();//stellt Information über die funktionalen Module in dem Gerät (z.B., die AV/C-Untereinheiten) zurück
    GetDeviceType();
    GetVendorName();
    Get VendorLogo();
    SetDevicePowerState(powerstate);
    GetDevicePowerState(powerstate);
    GetSupportedPowerStates(list);
    NotiyPowerState(powerstate);
    ReserveDevice();
    GetDeviceReservationStatus();
    NotifyDeviceReservationStatus();
    VendorDependentCommand(command parameters);//einen zuliefererspezifischen Befehl in dem nativen Protokoll durchgeben
  • Funktionssteuermodul-(FCM)-Nachrichten
  • Die funktionsspezifischen Nachrichten entsprechen den typischen nativen Befehlen, wie ABSPIELEN, STOP, RÜCKSPULEN für die Funktionalität eines Videorekorders in einem Gerät. Da diese Nachrichten an einen wohldefinierten Ort in einem Gerät adressiert sein müssen, benutzt man das FCM (Funktionssteuermodul), um das Ziel dieser Nachrichten darzustellen. Wie DCMs gibt es einige Nachrichten, die mit der Administration und dem Management von FCMs umgehen müssen. Diese Nachrichten werden von allen FCMs, unabhängig von ihrer speziellen Domäne, unterstützt. Die Nachrichten sind folgende:
    GetFunctionType();//Videorekorder, Tuner, Platte, usw.
    GetFunctionlnfo();//detailliertere Information über die Function, wie z.B. die spezielle Art des Disc-Players DVD, CD, usw.)
    GetNumberOfPlugs(inputPlugs outputPlugs);//stellt die Zahl von Quellen- und Ziel-Steckverbindungen für das Funktions-Modul zurück
    GetFunctionStatus();//laufender Status des Funktions-Moduls, einschließlich des Status die Quellen- und Ziel-Steckverbindungen (Eingang und Ausgang)
    GetPowerState(powerState);//Funktions-Module können individuell steuerbare Stromversorgungszustände haben
    SetPowerState(powerState);
    GetSupportedPowerStates(list);
    GetSupportedDataFormats(list);//stellt die von diesem Funktions-Modul unterstützten Dateiformate wieder her
    NativeCommand(params);//sendet dem Funktions-Modul einen Befehl in seinem nativen Befehls-Protokoll
  • Die funktionellen Domain-Nachrichten basieren auf dem Funktionstyp (Videorekorder, Tuner, usw.). Dieses sind die typischen ABSPIEL-, STOP-, RÜCKSPUL-Befehle, die man erwartet.
  • Die Schicht-1-Interoperabilität umfaßt sowohl Interaktionen von Gerät zu Gerät als auch von Mensch zu Gerät. Die funktionalen Nachrichtensätze, wie ABSPIELEN, STOP und RÜCKSPULEN werden für die Interaktion von Gerät zu Gerät benutzt. Ein Beispiel hierfür wäre ein Video-Schnittsoftware-Paket, das irgendeinen Typ von Videorekorder steuern möchte. Das Programm ist mit einem sehr spezifischen Satz von Benutzer-Interface-Steuerungen aufgebaut, die für alle Videorekorder passen. Wenn der Benutzer mit der Anwendung interagiert, sendet die Anwendung ihrerseits domänenspezifische Befehle, wie ABSPIELEN und STOP an das Zielgerät.
  • In der HAVI-Architektur sendet die Anwendung diese Nachrichten an das DCM, und das DCM übersetzt sie in die native Sprache des Ziel-BAV-Geräts. Falls das Zielgerät die HAVI-Nachrichten-Architektur unterstützt, müssen diese Befehle nicht übersetzt werden. Sie werden einfach als HAVI-Nachricht an das HAVI-Ziel gesendet.
  • Camcorder ähneln im wesentlichen Videorekordern. Ihre zusätzliche Funktionalität ist Teil der Camcorder-Effekte, -Übergänge, usw. Es sind folgende:
    stop()
    play()
    rewind()
    forward()
    record()
    volume(setvalue)
    changeStatus(newMode)//neuer Modus für VIDEOREKORDER, KAMERA, STANDBY
    cameraControl(controlType)//controlType definiert Steuerungstyp and Untertyp-Strukturen, z.B. Zoom, Zoomwert oder Effect, Übergänge usw.
  • Minidisks gehören zur Kategorie der Speicher mit wahlfreiem Zugriff. Sie unterstützen einen Basissatz von Befehlen zur Steuerung von ABSPIELEN, VORWÄRTS usw. und einen Satz von Befehlen die für Medien mit wahlfreiem Zugriff spezifisch sind. Diese Befehle sind die folgenden:
    stop()
    Play()
    rewind()
    forward()
    record()
    volume(setValue)
    changeStatus(newMode)//neuer Modus: STANDBY
    seek(track)
    seekstart()
    seekEnd()
    getDiskInfo()
    mdControl(controlType)//controlType definiert Steuerungstyp and Untertyp-Strukturen, z.B. Intro-Modus, zufallsgesteuertes Abspielen.
  • Festplatten gehören zur Kategorie der Speicher mit wahlfreiem Zugriff. Sie unterstützen einen Basissatz von Befehlen zur Steuerung von ABSPIELEN, VORWÄRTS usw. und einen Satz von Befehlen, die für Medien mit wahlfreiem Zugriff spezifisch sind. Diese Befehle sind die folgenden:
    stop()
    play()
    rewind()
    forward()
    record(type)//Typ-Structure liefert Information, die intelligenten Geräten Optimierung der Speicherpolitik ermöglicht
    changestatus(newMode)//neuer Modus: STANDBY
    seek(track)
    seek(block)
    seekStart()
    seekEnd()
    HDDControl(controlType)//definiert Steuerungstyp and Untertyp-Strukturen, z.B. Layout Befehle für Blockstrukturen
  • In Bezug auf Benutzer-Interfaces ist zu erwähnen, daß ein generisches und einfaches UI ein textbasiertes Interface sein kann, wie es in 12A dargestellt ist. Ein komplexeres Exemplar, das auf einer DCM-Spezialisierung basiert, kann so sein, wie dies in 12B dargestellt ist, in der eine graphische Information, die in dem SDD transportiert wird, von dem generischen DCM benutzt wird, um sich selbst zu spezialisieren.
  • Die vorliegende Erfindung stellt also ein audiovisuelles (AV) Heim-Netz zur Verfügung, das eine offene Architektur für die Interoperation von elektronischen Consumer-Geräten (CE-Geräten) in einem Heim-Netz definiert. Die Interoperabilitäts-Aspekte der Erfindung definieren ein Architekturmodell, das CE-Geräten irgendeines Herstellers nahtlose Interoperation und Funktion in dem Heim-AV-System des Benutzers ermöglicht. Das System der vorliegenden Erfindung enthält eine Kombination aus einem Basissatz von generischen Gerätesteuerungen mit einem Verfahren zur Erweiterung eines Basis-Steuerprotokolls, wenn neue Merkmale und neue CE-Geräte in dem Heim-AV-Netz eingesetzt werden. Dadurch ist die Architektur der vorliegenden Erfindung erweiterbar und kann leicht modifiziert und fortentwickelt werden, wenn sich die Markterfordernisse und die Technologie ändern.
  • Die vorangehenden Beschreibungen von spezifischen Ausführungsbeispielen der vorliegenden Erfindung wurden zum Zwecke der Illustration und Beschreibung präsentiert. Sie sollen nicht erschöpfend sein oder die Erfindung auf die offenbarten Formen beschränken. Im Licht der obigen Lehre sind offensichtlich viele Modifizierungen und Variationen möglich. Die Ausführungsbeispiele wurden ausgewählt und beschrieben, um die Prinzipien der Erfindung und ihre praktische Anwendung so gut wie möglich zu erläutern und anderen einschlägigen Fachleuten die beste Nutzung der Erfindung und verschiedene Ausführungsbeispiele mit verschiedenen Modifizierungen zu ermöglichen, wie sie für die jeweils in Betracht gezogene Benutzung geeignet sind. Der Rahmen der Erfindung soll durch die anliegenden Ansprüche und ihre Äquivalente definiert sein.

Claims (23)

  1. Verfahren zum Bereitstellen von Gerätesteuerung und -kommunikation für eine Mehrzahl von Geräten in einem Audio-Video-Heimnetzwerk, das einen ersten Satz von mit ihm verbundenen Geräten aufweist, wobei das Verfahren gekennzeichnet ist durch: Aufrufen (1302) eines Geräts, um eine Beschreibung von Funktionen einer ersten Schicht zu gewinnen, die von dem Gerät unterstützt werden, Erzeugen (1303) eines Steuersoftware-Moduls der ersten Schicht für das Gerät auf der Basis der Beschreibung der Funktionen der ersten Schicht, wobei dieser Schritt als Reaktion auf das Verbinden des Geräts mit dem Netzwerk ausgeführt wird, Empfangen (1305) eines Pseudocodes aus dem Gerät, der Funktionen einer zweiten Schicht für das Gerät implementiert, Erzeugen (1306) eines Steuersoftware-Moduls einer zweiten Schicht für das Gerät unter Verwendung des Pseudocodes und Zugreifen (1308, 1310) auf das Gerät über das Steuersoftware-Modul der ersten Schicht oder das Steuersoftware-Modul der zweiten Schicht, um auf die Funktionen der ersten Schicht bzw. die Funktionen der zweiten Schicht zuzugreifen, um die Kommunikation und die Steuerung des Geräts durch den ersten Satz von Geräten in dem Netzwerk zur Verfügung zu stellen.
  2. Verfahren nach Anspruch 1, bei dem das Abfragen des Gerät, das Erzeugen des Steuersoftware-Moduls der ersten Schicht und das Empfangen des Pseudocodes von einem Gerätemanager (761) ausgeführt werden, der auf einem intelligenten Gerät des ersten Satzes von Geräten in dem Netzwerk abläuft.
  3. Verfahren nach Anspruch 1, bei dem sowohl das Steuersoftware-Modul der ersten Schicht als auch das Steuersofware-Modul der zweiten Schicht auf einem intelligenten Gerät des ersten Satzes von Geräten in dem Netzwerk ablaufen.
  4. Verfahren nach Anspruch 1, bei dem von einem aus dem ersten Satz von Geräten auf das Gerät zugegriffen wird, indem in Abhängigkeit von den Fähigkeiten des Geräts auf das Steuersoftware-Modul der ersten Schicht oder auf das Steuersoftware-Modul der zweiten Schicht zugegriffen wird.
  5. Verfahren nach Anspruch 1, bei dem das Steuersoftware-Modul der ersten Schicht einen Mindestgrad an Interoperabilität für das Gerät zur Verfügung stellt.
  6. Verfahren nach Anspruch 5, bei dem das Steuersoftware-Modul der zweiten Schicht Interoperabilität für das Gerät bereitstellt, die im Vergleich zu derjenigen des Steuersoftware-Moduls der ersten Schicht verbessert ist.
  7. Verfahren nach Anspruch 1, bei dem das Netzwerk einen lokalen IEEE-1394-Kommunikationbus aufweist und das Steuersoftware-Modul der ersten Schicht und das Steuersoftware-Modul der zweiten Schicht so konfiguriert sind, daß sie mit dem Standard des seriellen IEEE-1394-Busses arbeiten.
  8. Verfahren nach Anspruch 1, bei dem das Steuersoftware-Modul der ersten Schicht für das Gerät erzeugt wird, um einen Mindestgrad an Interoperabilität bereitzustellen, und mit dem weiteren Verfahrensschritt, daß das Steuersoftware-Modul der ersten Schicht durch das Steuersoftware-Modul der zweiten Schicht ersetzt wird, das einen verbesserten Grad an Interoperabilität bereitstellt.
  9. Verfahren nach Anspruch 1, bei dem sowohl das Steuersoftware-Modul der ersten Schicht als auch das Steuersoftware-Modul der zweiten Schicht entsprechende standardisierte Steuer-Interfaces für das Gerät zur Verfügung zu stellen.
  10. Verfahren nach Anspruch 9, bei dem die Steuer-Interfaces ein Softwareprogramm umfassen, das einen vorbestimmten Satz an Interoperabilität, Funktionalität und Steuer-Interfaces bereitstellt, die eine nahtlose Interoperabilität und Integration des Geräts mit dem ersten Satz von Geräten in dem Netzwerk ermöglichen.
  11. Audio-Video-Heimnetzwerk, das eine Mehrzahl von Geräten umfaßt, die mit einem Bus verbunden sind, wobei wenigstens eines der Geräte ein Host-Gerät umfaßt, das einen mit einem computerlesbaren Speicher verbundenen Prozessor besitzt, wobei der Speicher computerlesbare Instruktionen enthält, die Kommunikation und Steuerung zwischen den Geräten bereitstellen, wenn sie von dem Prozessor ausgeführt werden, wobei das wenigstens eine Gerät gekennzeichnet ist durch: Mittel zum Aufrufen (1302) eines neuen Geräts des Netzwerks, um eine Beschreibung von Funktionen zu gewinnen, die von dem Gerät unterstützt werden, Mittel zum Erzeugen (1303) eines Steuersoftware-Moduls einer ersten Schicht für das neue Gerät auf der Basis der Beschreibung der Funktionen, die von dem Gerät unterstützt werden, Mittel zum Steuern (1309) des neuen Geräts unter Verwendung von Objekten des Netzwerks, wobei die Objekte des Netzwerks das Steuersoftware-Modul der ersten Schicht benutzen, Mittel zum Prüfen (1304), ob das neue Gerät ein Softwareprogramm für ein Steuersoftware-Modul einer zweiten Schicht enthält, das eine im Vergleich zu dem Steuersoftware-Modul der ersten Schicht erweiterte Funktionalität besitzt, Mittel zum Erzeugen (1306) eines Steuersoftware-Moduls der zweiten Schicht unter Verwendung des Softwareprogramms und Mittel zum Steuern (1307) des neuen Geräts unter Verwendung von Objekten des Netzwerks, wobei die Objekte des Netzwerks das Steuersoftware-Modul der zweiten Schicht benutzen.
  12. Netzwerk nach Anspruch 11, bei dem das neue Gerät neu in das Audio-Video-Heimnetzwerk eingefügt wird und bei dem der Bus dem seriellen IEEE-1394-Kommunikationsstandard entspricht.
  13. Netzwerk nach Anspruch 11, bei dem sowohl das Steuersoftware-Modul der ersten Schicht als auch das Steuersoftware-Modul der zweiten Schicht auf dem Host-Gerät simultan ausgeführt werden.
  14. Netzwerk nach Anspruch 11, bei dem von einem aus der Mehrzahl von Geräten auf das neue Gerät zugegriffen wird, indem auf dem Host-Gerät auf das Steuersoftware-Modul der ersten Schicht oder auf das Steuersoftware-Modul der zweiten Schicht zugegriffen wird.
  15. Netzwerk nach Anspruch 11, bei dem das Steuersoftware-Modul der ersten Schicht durch das Bereitstellen eines generalisierten Interoperabilitäts-Interfaces einen vorbestimmten Mindestgrad an Interoperabilität zur Verfügung stellt.
  16. Netzwerk nach Anspruch 15, bei dem das Steuersoftware-Modul der zweiten Schicht durch das Bereitstellen eines gerätespezifischen Interoperabilitäts-Interfaces einen im Vergleich zu dem Steuersoftware-Modul der ersten Schicht verbesserten Grad an Interoperabilität zur Verfügung stellt.
  17. Netzwerk nach Anspruch 11, bei dem die Steuersoftware-Module sowohl der ersten Schicht als auch der zweiten Schicht Steuer-Interfaces bereitstellen, die einen vordefinierten Satz an Interoperabilität, Funktionalität und Steuer-Interfaces zur Verfügung stellen, die eine nahtlose Interoperabilität und Integration des Geräts mit der Mehrzahl von Geräten in dem Netzwerk ermöglichen.
  18. Netzwerk nach Anspruch 11, bei dem das Steuersoftware-Modul der ersten Schicht einen vorbestimmten Mindestgrad an Interoperabilität für das Gerät bereitstellt, indem es ein generalisiertes Interoperabilitäts-Interface zur Verfügung stellt, bei dem das Steuersoftware-Modul der zweiten Schicht einen im Vergleich zu dem Steuersoftware-Modul der ersten Schicht verbesserten Grad an Interoperabilität bereitstellt, indem es ein gerätespezifisches Interoperabilitäts-Interface zur Verfügung stellt, und bei dem von einem aus der Mehrzahl von Geräten auf das neue Gerät zugegriffen wird, indem auf das Steuersoftware-Modul der ersten Schicht oder auf das Steuersoftware-Modul der zweiten Schicht auf dem Host-Gerät zugegriffen wird, wodurch eine erste Steuerschicht oder eine verbesserte zweite Steuerschicht zur Verfügung gestellt wird.
  19. Netzwerk nach Anspruch 18, bei dem sowohl das Steuersoftware-Modul der ersten Schicht als auch das Steuersoftware-Modul der zweiten Schicht simultan auf dem Host-Gerät ausgeführt werden.
  20. Netzwerk nach Anspruch 19, bei dem die Steuersoftware-Module sowohl der ersten Schicht als auch der zweiten Schicht Steuer-Interfaces bereitstellen, die einen vordefinierten Satz an Interoperabilität, Funktionalität und Steuer-Interfaces zur Verfügung stellen, die eine nahtlose Interoperabilität und Integration des Geräts mit der Mehrzahl von Geräten in dem Netzwerk ermöglichen.
  21. Netzwerk nach Anspruch 11, bei dem die Mittel zum Aufrufen eines neuen Geräts des Netzwerks zur Gewinnung einer Beschreibung von Funktionen, die von dem neuen Gerät unterstützt werden, die Mittel zum Erzeugen eines Steuersoftware-Moduls der ersten Schicht für das neue Gerät, die Mittel zum Steuern des neuen Geräts unter Verwendung von Objekten des Netzwerks, wobei die Objekte des Netzwerks das Steuersoftware-Modul der ersten Schicht benutzen, die Mittel zum Prüfen, ob das neue Gerät ein Softwareprogramm für ein Steuersoftware-Modul einer zweiten Schicht enthält, das eine im Vergleich zu dem Steuersoftware-Modul der ersten Schicht erweiterte Funktionalität besitzt, die Mittel zum Erzeugen eines Steuersoftware-Moduls der zweiten Schicht unter Verwendung des Softwareprogramms und die Mittel zum Steuern des neuen Geräts unter Verwendung von Objekten des Netzwerks, wobei die Objekte des Netzwerks das Steuersoftware-Modul der zweiten Schicht benutzen, durch computerlesbare Instruktionen implementiert werden.
  22. Vorrichtung zum Bereitstellen von Gerätesteuerung und -kommunikation für eine Mehrzahl von Geräten in einem Audio-Video-Heimnetzwerk, wobei die Vorrichtung gekennzeichnet ist durch Mittel zum Verbinden eines Geräts mit dem Netzwerk, wobei das Netzwerk einen ersten Satz von zuvor ihm verbundenen Geräten umfaßt, Mittel zum Aufrufen (1302) des Geräts, um eine Beschreibung von Funktionen einer ersten Schicht zu gewinnen, die von dem Gerät unterstützt werden, Mittel zum Erzeugen (1303) eines Steuersoftware-Moduls der ersten Schicht für das Gerät auf der Basis der Beschreibung der Funktionen der ersten Schicht, Mittel zum Empfangen (1305) eines Pseudocodes aus dem Gerät, der Funktionen einer zweiten Schicht für das Gerät implementiert, Mittel zum Erzeugen (1306) eines Steuersoftware-Moduls einer zweiten Schicht für das Gerät unter Verwendung des Pseudocodes und Mittel zum Zugreifen (1308, 1310) auf das Gerät über das Steuersoftware-Modul der ersten Schicht oder das Steuersoftware-Modul der zweiten Schicht, um auf die Funktionen der ersten Schicht bzw. die Funktionen der zweiten Schicht zuzugreifen, um die Kommunikation und die Steuerung des Geräts durch den ersten Satz von Geräten in dem Netzwerk bereitzustellen.
  23. Netzwerk nach einem der Ansprüche 11 bis 20, wobei das Netzwerk ein audiovisuelles Heimnetzwerk ist.
DE69836101T 1998-01-06 1998-12-24 Ein audio-video-gerät Expired - Lifetime DE69836101T2 (de)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
US3119 1998-01-06
US09/003,119 US6032202A (en) 1998-01-06 1998-01-06 Home audio/video network with two level device control
PCT/US1998/027764 WO1999035816A2 (en) 1998-01-06 1998-12-24 An audio/video device

Publications (2)

Publication Number Publication Date
DE69836101D1 DE69836101D1 (de) 2006-11-16
DE69836101T2 true DE69836101T2 (de) 2007-04-19

Family

ID=21704263

Family Applications (1)

Application Number Title Priority Date Filing Date
DE69836101T Expired - Lifetime DE69836101T2 (de) 1998-01-06 1998-12-24 Ein audio-video-gerät

Country Status (7)

Country Link
US (1) US6032202A (de)
EP (1) EP1046258B1 (de)
AT (1) ATE341875T1 (de)
AU (1) AU2020399A (de)
CA (1) CA2317801A1 (de)
DE (1) DE69836101T2 (de)
WO (1) WO1999035816A2 (de)

Families Citing this family (596)

* 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
US6237049B1 (en) * 1998-01-06 2001-05-22 Sony Corporation Of Japan Method and system for defining and discovering proxy functionality on a distributed audio video network
US20020002039A1 (en) 1998-06-12 2002-01-03 Safi Qureshey Network-enabled audio device
US7181501B2 (en) * 1998-03-19 2007-02-20 Isochron, Inc. Remote data acquisition, transmission and analysis system including handheld wireless equipment
US8631093B2 (en) 1998-03-19 2014-01-14 Crane Merchandising Systems, Inc. Remote data acquisition, transmission and analysis system including handheld wireless equipment
US6457038B1 (en) * 1998-03-19 2002-09-24 Isochron Data Corporation Wide area network operation's center that sends and receives data from vending machines
US20070050465A1 (en) * 1998-03-19 2007-03-01 Canter James M Packet capture agent for use in field assets employing shared bus architecture
US20060161473A1 (en) * 1998-03-19 2006-07-20 Defosse Erin M Remote data acquisition, transmission and analysis system including handheld wireless equipment
US7020680B2 (en) * 1998-03-19 2006-03-28 Isochron, Llc System and method for monitoring and control of beverage dispensing equipment
US7167892B2 (en) * 1998-03-19 2007-01-23 Isochron, Inc. System, method and apparatus for vending machine wireless audit and cashless transaction transport
JP4248028B2 (ja) * 1998-04-22 2009-04-02 コーニンクレッカ フィリップス エレクトロニクス エヌ ヴィ 消費者用電子システムにおける機能の管理
US6600958B1 (en) * 1998-04-22 2003-07-29 Koninklijke Philips Electronics N.V. Management of functionality in a consumer electronics system
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
JP2002514798A (ja) * 1998-05-07 2002-05-21 サムスン エレクトロニクス カンパニー リミテッド ネットワーク内のデバイス−デバイス間命令及び制御のための方法及びシステム
US6556875B1 (en) * 1998-06-30 2003-04-29 Seiko Epson Corporation Device control system
CN1867068A (zh) 1998-07-14 2006-11-22 联合视频制品公司 交互式电视节目导视系统及其方法
US6820278B1 (en) * 1998-07-23 2004-11-16 United Video Properties, Inc. Cooperative television application system having multiple user television equipment devices
US6202210B1 (en) * 1998-08-21 2001-03-13 Sony Corporation Of Japan Method and system for collecting data over a 1394 network to support analysis of consumer behavior, marketing and customer support
US6199136B1 (en) * 1998-09-02 2001-03-06 U.S. Philips Corporation Method and apparatus for a low data-rate network to be represented on and controllable by high data-rate home audio/video interoperability (HAVi) network
US6970081B1 (en) * 1998-09-17 2005-11-29 Koninklijke Philips Electronics N.V. Distributed software controlled theft detection
DE19850574A1 (de) * 1998-11-02 2000-05-04 Thomson Brandt Gmbh System mit mehreren Geräten, die über eine digitale Schnittstelle miteinander in Verbindung stehen
US6275865B1 (en) * 1998-11-25 2001-08-14 Sony Corporation Of Japan Method and system for message dispatching in a home audio/video network
US6859799B1 (en) 1998-11-30 2005-02-22 Gemstar Development Corporation Search engine for video and graphics
AUPP776498A0 (en) 1998-12-17 1999-01-21 Portus Pty Ltd Local and remote monitoring using a standard web browser
JP2000184303A (ja) * 1998-12-21 2000-06-30 Sony Corp ディジタル放送の受信システム及びディジタル放送の受信装置
US7966078B2 (en) 1999-02-01 2011-06-21 Steven Hoffberg Network media appliance system and method
US6311321B1 (en) * 1999-02-22 2001-10-30 Intel Corporation In-context launch wrapper (ICLW) module and method of automating integration of device management applications into existing enterprise management consoles
US6810452B1 (en) 1999-03-19 2004-10-26 Sony Corporation Method and system for quarantine during bus topology configuration
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
US7213061B1 (en) * 1999-04-29 2007-05-01 Amx Llc Internet control system and method
US6691161B1 (en) * 1999-05-11 2004-02-10 3Com Corporation Program method and apparatus providing elements for interrogating devices in a network
US20040168166A1 (en) * 1999-05-29 2004-08-26 Stefan Abramowski Network adapted for flexible media integration
US6823519B1 (en) * 1999-06-24 2004-11-23 Microsoft Corporation Control object and user interface for controlling networked devices
US6618764B1 (en) * 1999-06-25 2003-09-09 Koninklijke Philips Electronics N.V. Method for enabling interaction between two home networks of different software architectures
US6628607B1 (en) 1999-07-09 2003-09-30 Apple Computer, Inc. Method and apparatus for loop breaking on a serial bus
US6801507B1 (en) 1999-07-27 2004-10-05 Samsung Electronics Co., Ltd. Device discovery and configuration in a home network
US7490293B1 (en) 1999-07-27 2009-02-10 Samsung Electronics Co., Ltd. Device discovery and control in a bridged home network
US7610559B1 (en) * 1999-07-27 2009-10-27 Samsung Electronics Co., Ltd. Device customized home network top-level information architecture
KR100678595B1 (ko) * 1999-07-27 2007-02-05 삼성전자주식회사 브리지된 홈 네트워크에서의 장치 발견 및 제어
US8032833B1 (en) * 1999-07-27 2011-10-04 Samsung Electronics Co., Ltd. Home network device information architecture
US7200683B1 (en) 1999-08-17 2007-04-03 Samsung Electronics, Co., Ltd. Device communication and control in a home network connected to an external network
WO2001020476A1 (en) * 1999-09-16 2001-03-22 General Electric Company A virtual modular relay device
US6298069B1 (en) * 1999-09-30 2001-10-02 Sony Corporation System and method for implementing self-device control modules in an electronic network
US6691096B1 (en) 1999-10-28 2004-02-10 Apple Computer, Inc. General purpose data container method and apparatus for implementing AV/C descriptors
US6959343B1 (en) 1999-11-01 2005-10-25 Apple Computer, Inc. Method and apparatus for dynamic link driver configuration
US6671768B1 (en) 1999-11-01 2003-12-30 Apple Computer, Inc. System and method for providing dynamic configuration ROM using double image buffers for use with serial bus devices
US6618750B1 (en) 1999-11-02 2003-09-09 Apple Computer, Inc. Method and apparatus for determining communication paths
US8762446B1 (en) 1999-11-02 2014-06-24 Apple Inc. Bridged distributed device control over multiple transports method and apparatus
US6813663B1 (en) 1999-11-02 2004-11-02 Apple Computer, Inc. Method and apparatus for supporting and presenting multiple serial bus nodes using distinct configuration ROM images
US6631426B1 (en) 1999-11-02 2003-10-07 Apple Computer, Inc. Automatic ID allocation for AV/C entities
US6636914B1 (en) * 1999-11-05 2003-10-21 Apple Computer, Inc. Method and apparatus for arbitration and fairness on a full-duplex bus using dual phases
US6587904B1 (en) * 1999-11-05 2003-07-01 Apple Computer, Inc. Method and apparatus for preventing loops in a full-duplex bus
US6457086B1 (en) * 1999-11-16 2002-09-24 Apple Computers, Inc. Method and apparatus for accelerating detection of serial bus device speed signals
CA2371747C (en) * 1999-11-19 2007-03-13 Samsung Electronics Co., Ltd. Device communication and control in a home network connected to an external network with regional support
US6988276B2 (en) 1999-12-14 2006-01-17 Koninklijke Philips Electronics N.V. In-house TV to TV channel peeking
US7209980B2 (en) * 1999-12-17 2007-04-24 Gateway Inc. Method and system for interpreting device control commands
US7266617B1 (en) * 2000-01-18 2007-09-04 Apple Inc. Method and apparatus for border node behavior on a full-duplex bus
US6639918B1 (en) 2000-01-18 2003-10-28 Apple Computer, Inc. Method and apparatus for border node behavior on a full-duplex bus
US7421507B2 (en) * 2000-02-16 2008-09-02 Apple Inc. Transmission of AV/C transactions over multiple transports method and apparatus
US7050453B1 (en) 2000-02-17 2006-05-23 Apple Computer, Inc. Method and apparatus for ensuring compatibility on a high performance serial bus
US6831928B1 (en) 2000-02-17 2004-12-14 Apple Computer, Inc. Method and apparatus for ensuring compatibility on a high performance serial bus
JP2001237862A (ja) * 2000-02-21 2001-08-31 Sony Corp 情報処理装置および方法、並びに記録媒体
US6760045B1 (en) * 2000-02-22 2004-07-06 Gateway, Inc. Simultaneous projected presentation of client browser display
EP1133188A3 (de) * 2000-02-23 2004-11-24 Sony Corporation Informationsverarbeitungsvorrichtung, Netzwerksystem, Aufzeichnungsmedium
TW510134B (en) * 2000-04-04 2002-11-11 Koninkl Philips Electronics Nv Communication system, controlling device and controlled device
US6618785B1 (en) 2000-04-21 2003-09-09 Apple Computer, Inc. Method and apparatus for automatic detection and healing of signal pair crossover on a high performance serial bus
US6718497B1 (en) 2000-04-21 2004-04-06 Apple Computer, Inc. Method and apparatus for generating jitter test patterns on a high performance serial bus
US7444645B1 (en) * 2000-04-21 2008-10-28 Microsoft Corporation Method and system for detecting content on media and devices and launching applications to run the content
US7013337B2 (en) * 2000-05-12 2006-03-14 Isochron, Llc Method and system for the optimal formatting, reduction and compression of DEX/UCS data
US20030097474A1 (en) * 2000-05-12 2003-05-22 Isochron Data Corporation Method and system for the efficient communication of data with and between remote computing devices
US7010594B2 (en) * 2000-05-26 2006-03-07 Isochron, Llc System using environmental sensor and intelligent management and control transceiver for monitoring and controlling remote computing resources
US6601086B1 (en) * 2000-06-06 2003-07-29 Emware, Inc. Service provider for providing data, applications and services to embedded devices and for facilitating control and monitoring of embedded devices
US8090811B2 (en) * 2000-06-06 2012-01-03 Panasonic Electric Works Co., Ltd. Service provider for embedded devices using a message store
DE10030525A1 (de) * 2000-06-28 2002-01-24 Harman Becker Automotive Sys Verfahren zur Kommunikation zwischen zwei Netzwerken sowie Netzwerk
US6757773B1 (en) 2000-06-30 2004-06-29 Sony Corporation System and method for determining support capability of a device coupled to a bus system
US7072945B1 (en) * 2000-06-30 2006-07-04 Nokia Corporation Network and method for controlling appliances
US20020056113A1 (en) * 2000-07-04 2002-05-09 Ulan Co., Ltd. Home network connection system
EP1172721A1 (de) * 2000-07-10 2002-01-16 Sony International (Europe) GmbH Verfahren zur Steuerung von Netzwerkgeräten über ein MMI
US7349967B2 (en) * 2000-07-21 2008-03-25 Samsung Electronics Co., Ltd. Architecture for home network on world wide web with private-public IP address/URL mapping
US6547979B1 (en) * 2000-08-31 2003-04-15 Micron Technology, Inc. Methods of enhancing selectivity of etching silicon dioxide relative to one or more organic substances; and plasma reaction chambers
US6686838B1 (en) 2000-09-06 2004-02-03 Xanboo Inc. Systems and methods for the automatic registration of devices
US7734724B2 (en) * 2000-09-06 2010-06-08 Xanboo Inc. Automated upload of content based on captured event
US7555528B2 (en) 2000-09-06 2009-06-30 Xanboo Inc. Systems and methods for virtually representing devices at remote sites
TW521185B (en) * 2000-09-14 2003-02-21 Synq Technology Inc Method for generating an user interface and the system thereof
US7447815B2 (en) * 2000-09-27 2008-11-04 Thomson Licensing Architecture for optimizing audio and video operating modes for multimedia devices based on predetermined hierarchical order of available audio and video operating modes
US7103906B1 (en) 2000-09-29 2006-09-05 International Business Machines Corporation User controlled multi-device media-on-demand system
KR20190096450A (ko) 2000-10-11 2019-08-19 로비 가이드스, 인크. 매체 콘텐츠 배달 시스템 및 방법
US7206853B2 (en) 2000-10-23 2007-04-17 Sony Corporation content abstraction layer for use in home network applications
FR2816146A1 (fr) * 2000-10-27 2002-05-03 Canon Kk Procede et dispositif de gestion d'un reseau de communication
WO2002037217A2 (en) * 2000-11-02 2002-05-10 Sony Electronics, Inc. Content and application download based on a home network system configuration profile
DE10054840A1 (de) * 2000-11-04 2002-08-08 Xcellsis Gmbh Verfahren und Vorrichtung zum Starten eines Reaktors in einem Gaserzeugungssystem
US20020087964A1 (en) * 2000-12-28 2002-07-04 Gateway, Inc. System and method for enhanced HAVi based device implementation
US7631265B1 (en) * 2000-12-29 2009-12-08 Gateway, Inc. System and method for configuring and loading a user interface
US7188145B2 (en) 2001-01-12 2007-03-06 Epicrealm Licensing Llc Method and system for dynamic distributed data caching
US6660948B2 (en) * 2001-02-28 2003-12-09 Vip Investments Ltd. Switch matrix
US20020120932A1 (en) * 2001-02-28 2002-08-29 Schwalb Eddie M. Omni menu for an audio/visual network
US7146260B2 (en) * 2001-04-24 2006-12-05 Medius, Inc. Method and apparatus for dynamic configuration of multiprocessor system
US10298735B2 (en) 2001-04-24 2019-05-21 Northwater Intellectual Property Fund L.P. 2 Method and apparatus for dynamic configuration of a multiprocessor health data system
US7690017B2 (en) * 2001-05-03 2010-03-30 Mitsubishi Digital Electronics America, Inc. Control system and user interface for network of input devices
US6930730B2 (en) * 2001-05-03 2005-08-16 Mitsubishi Digital Electronics America, Inc. Control system and user interface for network of input devices
US20030075983A1 (en) * 2001-05-03 2003-04-24 Mitsubishi Digital Electronics America, Inc. Control system and user interface for network of input devices
US7814516B2 (en) * 2001-05-03 2010-10-12 Mitsubishi Digital Electronics America, Inc. Control system and user interface for network of input devices
US7797718B2 (en) * 2001-05-03 2010-09-14 Mitsubishi Digital Electronics America, Inc. Control system and user interface for network of input devices
US7778600B2 (en) * 2001-06-29 2010-08-17 Crane Merchandising Systems, Inc. Apparatus and method to provide multiple wireless communication paths to and from remotely located equipment
US7164884B2 (en) * 2001-06-29 2007-01-16 Isochron, Llc Method and system for interfacing a machine controller and a wireless network
US6925335B2 (en) 2001-07-05 2005-08-02 Isochron, Llc Real-time alert mechanism for monitoring and controlling field assets via wireless and internet technologies
US7574723B2 (en) * 2001-07-19 2009-08-11 Macrovision Corporation Home media network
US20030070002A1 (en) * 2001-08-31 2003-04-10 Henry Fang System and method for manipulating HAVi specification virtual key data
US7107358B2 (en) * 2001-09-12 2006-09-12 Rockwell Automation Technologies, Inc. Bridge for an industrial control system using data manipulation techniques
ATE347764T1 (de) * 2001-09-21 2006-12-15 Koninkl Philips Electronics Nv Gibt es kein spezifisches kontrollmodul? benutzen sie eines das weniger spezifisch ist
US6961099B2 (en) 2001-10-16 2005-11-01 Sony Corporation Method and apparatus for automatically switching between analog and digital input signals
US20030090501A1 (en) * 2001-11-14 2003-05-15 Gateway, Inc. Adjustable user interface
US7124367B2 (en) 2001-11-14 2006-10-17 Gateway Inc. Adjustable user interface
US7523182B2 (en) * 2001-11-27 2009-04-21 Isochron, Inc. Method and system for predicting the services needs of remote point of sale devices
US20030101262A1 (en) * 2001-11-27 2003-05-29 Isochron Data Corporation Method and system for scheduling the maintenance of remotely monitored devices
KR100467579B1 (ko) * 2001-12-24 2005-01-24 삼성전자주식회사 ＨＡＶｉ 네트워크 시스템의 피제어 장치를ｎｏｎ－ＩＥＥＥ１３９４망을 통해 제어하는 방법 및 그시스템
US7480439B2 (en) * 2002-03-25 2009-01-20 Panasonic Corporation Recording device recording method and program
US20030188320A1 (en) * 2002-04-02 2003-10-02 Intervideo, Inc. Method and system for a distributed digital video recorder
US20050076304A1 (en) * 2002-04-02 2005-04-07 Intervideo, Inc. Method and system for remote playback of a DVD
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
US20030204391A1 (en) * 2002-04-30 2003-10-30 Isochron Data Corporation Method and system for interpreting information communicated in disparate dialects
DE10226026A1 (de) * 2002-06-12 2003-12-24 Bosch Gmbh Robert Verteiltes objektorientiertes Gerätenetzwerksystem
DE10229388A1 (de) * 2002-06-26 2004-01-15 Deutsche Telekom Ag Multimediales System
US7933945B2 (en) 2002-06-27 2011-04-26 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
US7024256B2 (en) * 2002-06-27 2006-04-04 Openpeak Inc. Method, system, and computer program product for automatically managing components within a controlled environment
US8116889B2 (en) 2002-06-27 2012-02-14 Openpeak Inc. Method, system, and computer program product for managing controlled residential or non-residential environments
JP2004040285A (ja) * 2002-07-01 2004-02-05 Matsushita Electric Ind Co Ltd 家庭電化製品の制御装置、制御方法、制御プログラムおよび家庭電化製品
US8931010B2 (en) * 2002-11-04 2015-01-06 Rovi Solutions Corporation Methods and apparatus for client aggregation of media in a networked media system
US7417973B1 (en) 2002-12-31 2008-08-26 Apple Inc. Method, apparatus and computer program product for ensuring node participation in a network bus
US7457302B1 (en) 2002-12-31 2008-11-25 Apple Inc. Enhancement to loop healing for malconfigured bus prevention
US7987489B2 (en) 2003-01-07 2011-07-26 Openpeak Inc. Legacy device bridge for residential or non-residential networks
US20040143851A1 (en) * 2003-01-21 2004-07-22 Nokia Corporation Active packet identifier table
US7493646B2 (en) 2003-01-30 2009-02-17 United Video Properties, Inc. Interactive television systems with digital video recording and adjustable reminders
US20040157548A1 (en) * 2003-02-06 2004-08-12 Eyer Mark Kenneth Home network interface legacy device adapter
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
US8042049B2 (en) 2003-11-03 2011-10-18 Openpeak Inc. User interface for multi-device control
US7194700B2 (en) * 2003-03-14 2007-03-20 Sharp Laboratories Of America, Inc. System and method for one-stroke multimedia programming
US7574691B2 (en) * 2003-03-17 2009-08-11 Macrovision Corporation Methods and apparatus for rendering user interfaces and display information on remote client devices
US7213228B2 (en) 2003-03-17 2007-05-01 Macrovision Corporation Methods and apparatus for implementing a remote application over a network
DE10319935A1 (de) * 2003-05-02 2004-11-18 Deutsche Thomson-Brandt Gmbh Verfahren zur Bereitstellung einer Bedienoberfläche zur Bedienung eines Gerätes in einem Netzwerk verteilter Stationen sowie Netzwerkgerät für die Durchführung des Verfahrens
US7668099B2 (en) * 2003-06-13 2010-02-23 Apple Inc. Synthesis of vertical blanking signal
US7353284B2 (en) 2003-06-13 2008-04-01 Apple Inc. Synchronized transmission of audio and video data from a computer to a client via an interface
US20040255338A1 (en) * 2003-06-13 2004-12-16 Apple Computer, Inc. Interface for sending synchronized audio and video data
US8275910B1 (en) 2003-07-02 2012-09-25 Apple Inc. Source packet bridge
KR100466098B1 (ko) * 2003-07-03 2005-01-13 주식회사 스테이션지 오디오 포트와 유에스비 포트를 일체화시킨 음원재생장치및 그를 이용한 신호처리방법
KR101066669B1 (ko) * 2003-07-24 2011-09-22 코닌클리케 필립스 일렉트로닉스 엔.브이. 전자 시스템에 부가적인 기능성 특징들을 제공하는 전자시스템 및 방법
US8290603B1 (en) 2004-06-05 2012-10-16 Sonos, Inc. User interfaces for controlling and manipulating groupings in a multi-zone media system
US11294618B2 (en) 2003-07-28 2022-04-05 Sonos, Inc. Media player system
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
US11106424B2 (en) 2003-07-28 2021-08-31 Sonos, Inc. 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
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
US8086752B2 (en) 2006-11-22 2011-12-27 Sonos, Inc. Systems and methods for synchronizing operations among a plurality of independently clocked digital data processing devices that independently source digital data
US11106425B2 (en) 2003-07-28 2021-08-31 Sonos, Inc. Synchronizing operations among a plurality of independently clocked digital data processing devices
WO2005015824A1 (en) * 2003-08-07 2005-02-17 Samsung Electronics Co., Ltd. Audio/video device, apparatus and method for controlling audio/video device
FR2859341A1 (fr) * 2003-08-27 2005-03-04 Thomson Licensing Sa Methode de controle entre appareils connectes a un reseau heterogene et appareil implementant la methode
US7755506B1 (en) 2003-09-03 2010-07-13 Legrand Home Systems, Inc. Automation and theater control system
US7788567B1 (en) 2003-11-18 2010-08-31 Apple Inc. Symbol encoding for tolerance to single byte errors
US7995606B1 (en) 2003-12-03 2011-08-09 Apple Inc. Fly-by and ack-accelerated arbitration for broadcast packets
US7308517B1 (en) * 2003-12-29 2007-12-11 Apple Inc. Gap count analysis for a high speed serialized bus
US7237135B1 (en) 2003-12-29 2007-06-26 Apple Inc. Cyclemaster synchronization in a distributed bridge
US20050149215A1 (en) * 2004-01-06 2005-07-07 Sachin Deshpande Universal plug and play remote audio mixer
US9977561B2 (en) 2004-04-01 2018-05-22 Sonos, Inc. Systems, methods, apparatus, and articles of manufacture to provide guest access
US8028323B2 (en) 2004-05-05 2011-09-27 Dryden Enterprises, Llc Method and system for employing a first device to direct a networked audio device to obtain a media item
US8028038B2 (en) 2004-05-05 2011-09-27 Dryden Enterprises, Llc Obtaining a playlist based on user profile matching
US8024055B1 (en) 2004-05-15 2011-09-20 Sonos, Inc. Method and system for controlling amplifiers
US7029136B2 (en) * 2004-05-26 2006-04-18 Ming Kun Hsu Light shield for welding
US8326951B1 (en) 2004-06-05 2012-12-04 Sonos, Inc. Establishing a secure wireless network with minimum human intervention
US10268352B2 (en) 2004-06-05 2019-04-23 Sonos, Inc. Method and apparatus for managing a playlist by metadata
US8868698B2 (en) 2004-06-05 2014-10-21 Sonos, Inc. Establishing a secure wireless network with minimum human intervention
US20050289531A1 (en) * 2004-06-08 2005-12-29 Daniel Illowsky Device interoperability tool set and method for processing interoperability application specifications into interoperable application packages
JP4626221B2 (ja) * 2004-06-24 2011-02-02 ソニー株式会社 情報処理装置、情報記録媒体、および情報処理方法、並びにコンピュータ・プログラム
US20060064730A1 (en) * 2004-09-17 2006-03-23 Jacob Rael Configurable entertainment network
US8086575B2 (en) * 2004-09-23 2011-12-27 Rovi Solutions Corporation Methods and apparatus for integrating disparate media formats in a networked media system
US7545435B2 (en) * 2004-10-15 2009-06-09 Lifesize Communications, Inc. Automatic backlight compensation and exposure control
US7337650B1 (en) 2004-11-09 2008-03-04 Medius Inc. System and method for aligning sensors on a vehicle
US7768388B2 (en) 2005-01-05 2010-08-03 Rovi Solutions Corporation Methods and apparatus for providing notifications in a media system
EP1854231B1 (de) * 2005-02-17 2013-04-10 Koninklijke Philips Electronics N.V. In einem netzwerk betreibbare vorrichtung, netzwerksystem, verfahren für den betrieb einer vorrichtung in einem netzwerk, programmelement und computerlesbares medium
KR100737804B1 (ko) * 2005-03-30 2007-07-10 전자부품연구원 센서 네트워크 및 메타데이터를 이용한 미디어 서비스 제공시스템
US9401822B2 (en) * 2005-06-09 2016-07-26 Whirlpool Corporation Software architecture system and method for operating an appliance exposing key press functionality to a network
US8700730B2 (en) * 2005-08-18 2014-04-15 Microsoft Corporation Aggregated audio/video crossbar connections
US20070053519A1 (en) * 2005-08-30 2007-03-08 Godwin Bryan W Wireless adapter for data exchange and method
US7778262B2 (en) * 2005-09-07 2010-08-17 Vantage Controls, Inc. Radio frequency multiple protocol bridge
AU2006287639C1 (en) * 2005-09-07 2012-06-28 Open Invention Network, Llc Method and computer program for device configuration
US20070090920A1 (en) * 2005-10-22 2007-04-26 Canter James M Apparatus and Method for Controlling Access to Remotely Located Equipment
US8484068B2 (en) 2005-12-14 2013-07-09 Crane Merchandising Systems, Inc. Method and system for evaluating consumer demand for multiple products and services at remotely located equipment
US9467322B2 (en) * 2005-12-27 2016-10-11 Rovi Solutions Corporation Methods and apparatus for integrating media across a wide area network
US9681105B2 (en) 2005-12-29 2017-06-13 Rovi Guides, Inc. Interactive media guidance system having multiple devices
US8607287B2 (en) * 2005-12-29 2013-12-10 United Video Properties, Inc. Interactive media guidance system having multiple devices
US20070157240A1 (en) * 2005-12-29 2007-07-05 United Video Properties, Inc. Interactive media guidance system having multiple devices
US7813823B2 (en) * 2006-01-17 2010-10-12 Sigmatel, Inc. Computer audio system and method
US20070195490A1 (en) * 2006-02-13 2007-08-23 Howell Sean V Apparatus And Method For Attaching An Electronic Module To A Lock Assembly
JP2007272836A (ja) * 2006-03-31 2007-10-18 Toshiba Corp ネットワーク検索装置、ネットワーク検索用プログラム及びネットワーク検索方法
US8694910B2 (en) 2006-05-09 2014-04-08 Sonos, Inc. User interface to enable users to scroll through a large list of items
US9075509B2 (en) 2006-05-18 2015-07-07 Sonos, Inc. User interface to provide additional information on a selected item in a list
US7929551B2 (en) * 2006-06-01 2011-04-19 Rovi Solutions Corporation Methods and apparatus for transferring media across a network using a network interface device
WO2008022322A2 (en) * 2006-08-17 2008-02-21 Vantage Controls, Inc. System and method for creating a user interface
US8005236B2 (en) * 2006-09-07 2011-08-23 Porto Vinci Ltd. Limited Liability Company Control of data presentation using a wireless home entertainment hub
US8607281B2 (en) * 2006-09-07 2013-12-10 Porto Vinci Ltd. Limited Liability Company Control of data presentation in multiple zones using a wireless home entertainment hub
US9386269B2 (en) 2006-09-07 2016-07-05 Rateze Remote Mgmt Llc Presentation of data on multiple display devices using a wireless hub
US8935733B2 (en) * 2006-09-07 2015-01-13 Porto Vinci Ltd. Limited Liability Company Data presentation using a wireless home entertainment hub
US20080061578A1 (en) * 2006-09-07 2008-03-13 Technology, Patents & Licensing, Inc. Data presentation in multiple zones using a wireless home entertainment hub
US9319741B2 (en) 2006-09-07 2016-04-19 Rateze Remote Mgmt Llc Finding devices in an entertainment system
US8966545B2 (en) * 2006-09-07 2015-02-24 Porto Vinci Ltd. Limited Liability Company Connecting a legacy device into a home entertainment system using a wireless home entertainment hub
US9233301B2 (en) * 2006-09-07 2016-01-12 Rateze Remote Mgmt Llc Control of data presentation from multiple sources using a wireless home entertainment hub
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
US9202509B2 (en) 2006-09-12 2015-12-01 Sonos, Inc. Controlling and grouping in a multi-zone media system
US7997484B2 (en) * 2006-09-13 2011-08-16 Crane Merchandising Systems, Inc. Rich content management and display for use in remote field assets
US8258872B1 (en) 2007-06-11 2012-09-04 Sonos, Inc. Multi-tier power supply for audio amplifiers
US8959028B2 (en) * 2007-07-02 2015-02-17 Crane Merchandising Systems, Inc. Apparatus and method for monitoring and control of remotely located equipment
US20090019492A1 (en) * 2007-07-11 2009-01-15 United Video Properties, Inc. Systems and methods for mirroring and transcoding media content
US7857222B2 (en) * 2007-08-16 2010-12-28 Hand Held Products, Inc. Data collection system having EIR terminal interface node
US8533315B2 (en) * 2007-10-25 2013-09-10 Crane Merchandising Systems, Inc. Systems and methods for monitoring performance of field assets
US8990360B2 (en) 2008-02-22 2015-03-24 Sonos, Inc. System, method, and computer program for remotely managing a digital device
US8601526B2 (en) 2008-06-13 2013-12-03 United Video Properties, Inc. Systems and methods for displaying media content and media guidance information
US10459739B2 (en) 2008-07-09 2019-10-29 Sonos Inc. Systems and methods for configuring and profiling a digital media device
US20100083113A1 (en) * 2008-09-26 2010-04-01 Thomson Licensing Inc. Architecture For Optimizing Audio and Video Output States for Multimedia Devices
US10063934B2 (en) 2008-11-25 2018-08-28 Rovi Technologies Corporation Reducing unicast session duration with restart TV
US10061742B2 (en) 2009-01-30 2018-08-28 Sonos, Inc. Advertising in a digital media playback system
JP5307610B2 (ja) * 2009-04-17 2013-10-02 キヤノン株式会社 無線通信システムと通信方法
US9358924B1 (en) 2009-05-08 2016-06-07 Eagle Harbor Holdings, Llc System and method for modeling advanced automotive safety systems
US8305421B2 (en) * 2009-06-29 2012-11-06 Lifesize Communications, Inc. Automatic determination of a configuration for a conference
US20110072452A1 (en) * 2009-09-23 2011-03-24 Rovi Technologies Corporation Systems and methods for providing automatic parental control activation when a restricted user is detected within range of a device
US9014546B2 (en) 2009-09-23 2015-04-21 Rovi Guides, Inc. Systems and methods for automatically detecting users within detection regions of media devices
US9497092B2 (en) 2009-12-08 2016-11-15 Hand Held Products, Inc. Remote device management interface
US8923997B2 (en) 2010-10-13 2014-12-30 Sonos, Inc Method and apparatus for adjusting a speaker system
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
US8938312B2 (en) 2011-04-18 2015-01-20 Sonos, Inc. Smart line-in processing
US9343818B2 (en) 2011-07-14 2016-05-17 Sonos, Inc. Antenna configurations for wireless speakers
US9042556B2 (en) 2011-07-19 2015-05-26 Sonos, Inc Shaping sound responsive to speaker orientation
US9286384B2 (en) 2011-09-21 2016-03-15 Sonos, Inc. Methods and systems to share media
US20130076651A1 (en) 2011-09-28 2013-03-28 Robert Reimann Methods and apparatus to change control centexts of controllers
US9052810B2 (en) 2011-09-28 2015-06-09 Sonos, Inc. Methods and apparatus to manage zones of a multi-zone media playback system
US8539123B2 (en) 2011-10-06 2013-09-17 Honeywell International, Inc. Device management using a dedicated management interface
US8621123B2 (en) 2011-10-06 2013-12-31 Honeywell International Inc. Device management using virtual interfaces
US8971546B2 (en) 2011-10-14 2015-03-03 Sonos, Inc. Systems, methods, apparatus, and articles of manufacture to control audio playback devices
US9094706B2 (en) 2011-10-21 2015-07-28 Sonos, Inc. Systems and methods for wireless music playback
US9460631B2 (en) 2011-11-02 2016-10-04 Sonos, Inc. Systems, methods, apparatus, and articles of manufacture for playback demonstration at a point of sale display
US8811630B2 (en) 2011-12-21 2014-08-19 Sonos, Inc. Systems, methods, and apparatus to filter audio
US8805418B2 (en) 2011-12-23 2014-08-12 United Video Properties, Inc. Methods and systems for performing actions based on location-based rules
US9665339B2 (en) 2011-12-28 2017-05-30 Sonos, Inc. Methods and systems to select an audio track
US9247492B2 (en) 2011-12-29 2016-01-26 Sonos, Inc. Systems and methods for multi-network audio control
US9191699B2 (en) 2011-12-29 2015-11-17 Sonos, Inc. Systems and methods for connecting an audio controller to a hidden audio network
US9084058B2 (en) 2011-12-29 2015-07-14 Sonos, Inc. Sound field calibration using listener localization
US9654821B2 (en) 2011-12-30 2017-05-16 Sonos, Inc. Systems and methods for networked music playback
US9344292B2 (en) 2011-12-30 2016-05-17 Sonos, Inc. Systems and methods for player setup room names
US10469897B2 (en) 2012-03-19 2019-11-05 Sonos, Inc. Context-based user music menu systems and methods
US9729115B2 (en) 2012-04-27 2017-08-08 Sonos, Inc. Intelligently increasing the sound level of player
US9524098B2 (en) 2012-05-08 2016-12-20 Sonos, Inc. Methods and systems for subwoofer calibration
US9521074B2 (en) 2012-05-10 2016-12-13 Sonos, Inc. Methods and apparatus for direct routing between nodes of networks
US8908879B2 (en) 2012-05-23 2014-12-09 Sonos, Inc. Audio content auditioning
US8903526B2 (en) 2012-06-06 2014-12-02 Sonos, Inc. Device playback failure recovery and redistribution
US9031255B2 (en) 2012-06-15 2015-05-12 Sonos, Inc. Systems, methods, apparatus, and articles of manufacture to provide low-latency audio
US9020623B2 (en) 2012-06-19 2015-04-28 Sonos, Inc Methods and apparatus to provide an infrared signal
US9204174B2 (en) 2012-06-25 2015-12-01 Sonos, Inc. Collecting and providing local playback system information
US9882995B2 (en) 2012-06-25 2018-01-30 Sonos, Inc. Systems, methods, apparatus, and articles of manufacture to provide automatic wireless configuration
US9674587B2 (en) 2012-06-26 2017-06-06 Sonos, Inc. Systems and methods for networked music playback including remote add to queue
US9715365B2 (en) 2012-06-27 2017-07-25 Sonos, Inc. Systems and methods for mobile music zones
US9106192B2 (en) 2012-06-28 2015-08-11 Sonos, Inc. System and method for device playback calibration
US9690539B2 (en) 2012-06-28 2017-06-27 Sonos, Inc. Speaker calibration user interface
US9690271B2 (en) 2012-06-28 2017-06-27 Sonos, Inc. Speaker calibration
US9706323B2 (en) 2014-09-09 2017-07-11 Sonos, Inc. Playback device calibration
US9225307B2 (en) 2012-06-28 2015-12-29 Sonos, Inc. Modification of audio responsive to proximity detection
US9137564B2 (en) 2012-06-28 2015-09-15 Sonos, Inc. Shift to corresponding media in a playback queue
US9668049B2 (en) 2012-06-28 2017-05-30 Sonos, Inc. Playback device calibration user interfaces
US9219460B2 (en) 2014-03-17 2015-12-22 Sonos, Inc. Audio settings based on environment
US9031244B2 (en) 2012-06-29 2015-05-12 Sonos, Inc. Smart audio settings
US9306764B2 (en) 2012-06-29 2016-04-05 Sonos, Inc. Dynamic spanning tree root selection
US8995687B2 (en) 2012-08-01 2015-03-31 Sonos, Inc. Volume interactions for connected playback devices
US8930005B2 (en) 2012-08-07 2015-01-06 Sonos, Inc. Acoustic signatures in a playback system
US8965033B2 (en) 2012-08-31 2015-02-24 Sonos, Inc. Acoustic optimization
US8910265B2 (en) 2012-09-28 2014-12-09 Sonos, Inc. Assisted registration of audio sources
US9078010B2 (en) 2012-09-28 2015-07-07 Sonos, Inc. Audio content playback management
US9008330B2 (en) 2012-09-28 2015-04-14 Sonos, Inc. Crossover frequency adjustments for audio speakers
US9516440B2 (en) 2012-10-01 2016-12-06 Sonos Providing a multi-channel and a multi-zone audio environment
US9179197B2 (en) 2012-10-10 2015-11-03 Sonos, Inc. Methods and apparatus for multicast optimization
US9952576B2 (en) 2012-10-16 2018-04-24 Sonos, Inc. Methods and apparatus to learn and share remote commands
US10055491B2 (en) 2012-12-04 2018-08-21 Sonos, Inc. Media content search based on metadata
US9319153B2 (en) 2012-12-04 2016-04-19 Sonos, Inc. Mobile source media content access
US9510055B2 (en) 2013-01-23 2016-11-29 Sonos, Inc. System and method for a media experience social interface
US9237384B2 (en) 2013-02-14 2016-01-12 Sonos, Inc. Automatic configuration of household playback devices
US9319409B2 (en) 2013-02-14 2016-04-19 Sonos, Inc. Automatic configuration of household playback devices
US9195432B2 (en) 2013-02-26 2015-11-24 Sonos, Inc. Pre-caching of audio content
CN105229740A (zh) 2013-03-15 2016-01-06 搜诺思公司 具有多个图形界面的媒体回放系统控制器
US9247363B2 (en) 2013-04-16 2016-01-26 Sonos, Inc. Playback queue transfer in a media playback system
US9361371B2 (en) 2013-04-16 2016-06-07 Sonos, Inc. Playlist update in a media playback system
US9501533B2 (en) 2013-04-16 2016-11-22 Sonos, Inc. Private queue for a media playback system
US9495076B2 (en) 2013-05-29 2016-11-15 Sonos, Inc. Playlist modification
US9798510B2 (en) 2013-05-29 2017-10-24 Sonos, Inc. Connected state indicator
US9735978B2 (en) 2013-05-29 2017-08-15 Sonos, Inc. Playback queue control via a playlist on a mobile device
US9953179B2 (en) 2013-05-29 2018-04-24 Sonos, Inc. Private queue indicator
US9703521B2 (en) 2013-05-29 2017-07-11 Sonos, Inc. Moving a playback queue to a new zone
US9684484B2 (en) * 2013-05-29 2017-06-20 Sonos, Inc. Playback zone silent connect
US10715973B2 (en) 2013-05-29 2020-07-14 Sonos, Inc. Playback queue control transition
US9438193B2 (en) 2013-06-05 2016-09-06 Sonos, Inc. Satellite volume control
US9654073B2 (en) 2013-06-07 2017-05-16 Sonos, Inc. Group volume control
US9285886B2 (en) 2013-06-24 2016-03-15 Sonos, Inc. Intelligent amplifier activation
US9298415B2 (en) 2013-07-09 2016-03-29 Sonos, Inc. Systems and methods to provide play/pause content
US9232277B2 (en) 2013-07-17 2016-01-05 Sonos, Inc. Associating playback devices with playback queues
US9232314B2 (en) 2013-09-09 2016-01-05 Sonos, Inc. Loudspeaker configuration
US9066179B2 (en) 2013-09-09 2015-06-23 Sonos, Inc. Loudspeaker assembly configuration
US9354677B2 (en) 2013-09-26 2016-05-31 Sonos, Inc. Speaker cooling
US9355555B2 (en) 2013-09-27 2016-05-31 Sonos, Inc. System and method for issuing commands in a media playback system
US9231545B2 (en) 2013-09-27 2016-01-05 Sonos, Inc. Volume enhancements in a multi-zone media playback system
US9933920B2 (en) 2013-09-27 2018-04-03 Sonos, Inc. Multi-household support
US10095785B2 (en) 2013-09-30 2018-10-09 Sonos, Inc. Audio content search in a media playback system
US9244516B2 (en) 2013-09-30 2016-01-26 Sonos, Inc. Media playback system using standby mode in a mesh network
US9288596B2 (en) 2013-09-30 2016-03-15 Sonos, Inc. Coordinator device for paired or consolidated players
US9166273B2 (en) 2013-09-30 2015-10-20 Sonos, Inc. Configurations for antennas
US10028028B2 (en) 2013-09-30 2018-07-17 Sonos, Inc. Accessing last-browsed information in a media playback system
US9241355B2 (en) 2013-09-30 2016-01-19 Sonos, Inc. Media system access via cellular network
US9223353B2 (en) 2013-09-30 2015-12-29 Sonos, Inc. Ambient light proximity sensing configuration
US9122451B2 (en) 2013-09-30 2015-09-01 Sonos, Inc. Capacitive proximity sensor configuration including a speaker grille
US9537819B2 (en) 2013-09-30 2017-01-03 Sonos, Inc. Facilitating the resolution of address conflicts in a networked media playback system
US9456037B2 (en) 2013-09-30 2016-09-27 Sonos, Inc. Identifying a useful wired connection
US9298244B2 (en) 2013-09-30 2016-03-29 Sonos, Inc. Communication routes based on low power operation
US9654545B2 (en) 2013-09-30 2017-05-16 Sonos, Inc. Group coordinator device selection
US10296884B2 (en) 2013-09-30 2019-05-21 Sonos, Inc. Personalized media playback at a discovered point-of-sale display
US9323404B2 (en) 2013-09-30 2016-04-26 Sonos, Inc. Capacitive proximity sensor configuration including an antenna ground plane
US9344755B2 (en) 2013-09-30 2016-05-17 Sonos, Inc. Fast-resume audio playback
US20150095679A1 (en) 2013-09-30 2015-04-02 Sonos, Inc. Transitioning A Networked Playback Device Between Operating Modes
US9720576B2 (en) 2013-09-30 2017-08-01 Sonos, Inc. Controlling and displaying zones in a multi-zone system
US9674563B2 (en) 2013-11-04 2017-06-06 Rovi Guides, Inc. Systems and methods for recommending content
US9300647B2 (en) 2014-01-15 2016-03-29 Sonos, Inc. Software application and zones
US9313591B2 (en) 2014-01-27 2016-04-12 Sonos, Inc. Audio synchronization among playback devices using offset information
US20150220498A1 (en) 2014-02-05 2015-08-06 Sonos, Inc. Remote Creation of a Playback Queue for a Future Event
US9226073B2 (en) 2014-02-06 2015-12-29 Sonos, Inc. Audio output balancing during synchronized playback
US9226087B2 (en) 2014-02-06 2015-12-29 Sonos, Inc. Audio output balancing during synchronized playback
US9226072B2 (en) 2014-02-21 2015-12-29 Sonos, Inc. Media content based on playback zone awareness
US9372610B2 (en) 2014-02-21 2016-06-21 Sonos, Inc. Media system controller interface
US9408008B2 (en) 2014-02-28 2016-08-02 Sonos, Inc. Playback zone representations
US9679054B2 (en) 2014-03-05 2017-06-13 Sonos, Inc. Webpage media playback
US9892118B2 (en) 2014-03-18 2018-02-13 Sonos, Inc. Dynamic display of filter criteria
US20150261493A1 (en) 2014-03-11 2015-09-17 Sonos, Inc. Playback Zone Representations
US10599287B2 (en) 2014-03-11 2020-03-24 Sonos, Inc. Group volume control
US9264839B2 (en) 2014-03-17 2016-02-16 Sonos, Inc. Playback device configuration based on proximity detection
US9223862B2 (en) 2014-03-21 2015-12-29 Sonos, Inc. Remote storage and provisioning of local-media index
US10331736B2 (en) 2014-03-21 2019-06-25 Sonos, Inc. Facilitating streaming media access via a media-item database
US9338514B2 (en) 2014-03-28 2016-05-10 Sonos, Inc. Account aware media preferences
US10587693B2 (en) 2014-04-01 2020-03-10 Sonos, Inc. Mirrored queues
US9705950B2 (en) 2014-04-03 2017-07-11 Sonos, Inc. Methods and systems for transmitting playlists
US9680960B2 (en) 2014-04-28 2017-06-13 Sonos, Inc. Receiving media content based on media preferences of multiple users
US10129599B2 (en) 2014-04-28 2018-11-13 Sonos, Inc. Media preference database
US9478247B2 (en) 2014-04-28 2016-10-25 Sonos, Inc. Management of media content playback
US9524338B2 (en) 2014-04-28 2016-12-20 Sonos, Inc. Playback of media content according to media preferences
US20150324552A1 (en) 2014-05-12 2015-11-12 Sonos, Inc. Share Restriction for Media Items
US20150355818A1 (en) 2014-06-04 2015-12-10 Sonos, Inc. Continuous Playback Queue
US9363255B2 (en) 2014-06-04 2016-06-07 Sonos, Inc. Cloud queue playhead
US9720642B2 (en) 2014-06-04 2017-08-01 Sonos, Inc. Prioritizing media content requests
US20150356084A1 (en) 2014-06-05 2015-12-10 Sonos, Inc. Social Queue
US9672213B2 (en) 2014-06-10 2017-06-06 Sonos, Inc. Providing media items from playback history
US9348824B2 (en) 2014-06-18 2016-05-24 Sonos, Inc. Device group identification
US9646085B2 (en) 2014-06-27 2017-05-09 Sonos, Inc. Music streaming using supported services
US9535986B2 (en) 2014-06-27 2017-01-03 Sonos, Inc. Application launch
US10068012B2 (en) 2014-06-27 2018-09-04 Sonos, Inc. Music discovery
US9779613B2 (en) 2014-07-01 2017-10-03 Sonos, Inc. Display and control of pre-determined audio content playback
US9519413B2 (en) 2014-07-01 2016-12-13 Sonos, Inc. Lock screen media playback control
US9460755B2 (en) 2014-07-14 2016-10-04 Sonos, Inc. Queue identification
US9467737B2 (en) 2014-07-14 2016-10-11 Sonos, Inc. Zone group control
US10498833B2 (en) 2014-07-14 2019-12-03 Sonos, Inc. Managing application access of a media playback system
US10462505B2 (en) 2014-07-14 2019-10-29 Sonos, Inc. Policies for media playback
US9485545B2 (en) 2014-07-14 2016-11-01 Sonos, Inc. Inconsistent queues
US8995240B1 (en) 2014-07-22 2015-03-31 Sonos, Inc. Playback using positioning information
US9512954B2 (en) 2014-07-22 2016-12-06 Sonos, Inc. Device base
US9367283B2 (en) 2014-07-22 2016-06-14 Sonos, Inc. Audio settings
US10209947B2 (en) 2014-07-23 2019-02-19 Sonos, Inc. Device grouping
US9671997B2 (en) 2014-07-23 2017-06-06 Sonos, Inc. Zone grouping
US9524339B2 (en) 2014-07-30 2016-12-20 Sonos, Inc. Contextual indexing of media items
US9538293B2 (en) 2014-07-31 2017-01-03 Sonos, Inc. Apparatus having varying geometry
US9874997B2 (en) 2014-08-08 2018-01-23 Sonos, Inc. Social playback queues
US10275138B2 (en) 2014-09-02 2019-04-30 Sonos, Inc. Zone recognition
US9891881B2 (en) 2014-09-09 2018-02-13 Sonos, Inc. Audio processing algorithm database
US10127006B2 (en) 2014-09-09 2018-11-13 Sonos, Inc. Facilitating calibration of an audio playback device
US9910634B2 (en) 2014-09-09 2018-03-06 Sonos, Inc. Microphone calibration
US9952825B2 (en) 2014-09-09 2018-04-24 Sonos, Inc. Audio processing algorithms
US9742839B2 (en) 2014-09-12 2017-08-22 Sonos, Inc. Cloud queue item removal
US9446559B2 (en) 2014-09-18 2016-09-20 Sonos, Inc. Speaker terminals
US10778739B2 (en) 2014-09-19 2020-09-15 Sonos, Inc. Limited-access media
US10645130B2 (en) 2014-09-24 2020-05-05 Sonos, Inc. Playback updates
US9860286B2 (en) 2014-09-24 2018-01-02 Sonos, Inc. Associating a captured image with a media item
US9667679B2 (en) 2014-09-24 2017-05-30 Sonos, Inc. Indicating an association between a social-media account and a media playback system
US9723038B2 (en) 2014-09-24 2017-08-01 Sonos, Inc. Social media connection recommendations based on playback information
US9690540B2 (en) 2014-09-24 2017-06-27 Sonos, Inc. Social media queue
US9959087B2 (en) 2014-09-24 2018-05-01 Sonos, Inc. Media item context from social media
WO2016049342A1 (en) 2014-09-24 2016-03-31 Sonos, Inc. Social media connection recommendations based on playback information
US9671780B2 (en) 2014-09-29 2017-06-06 Sonos, Inc. Playback device control
US9521212B2 (en) 2014-09-30 2016-12-13 Sonos, Inc. Service provider user accounts
US10002005B2 (en) 2014-09-30 2018-06-19 Sonos, Inc. Displaying data related to media content
US9840355B2 (en) 2014-10-03 2017-12-12 Sonos, Inc. Packaging system with slidable latch
US9876780B2 (en) 2014-11-21 2018-01-23 Sonos, Inc. Sharing access to a media service
US9973851B2 (en) 2014-12-01 2018-05-15 Sonos, Inc. Multi-channel playback of audio content
US20160156992A1 (en) 2014-12-01 2016-06-02 Sonos, Inc. Providing Information Associated with a Media Item
US9665341B2 (en) 2015-02-09 2017-05-30 Sonos, Inc. Synchronized audio mixing
US9330096B1 (en) 2015-02-25 2016-05-03 Sonos, Inc. Playback expansion
US9329831B1 (en) 2015-02-25 2016-05-03 Sonos, Inc. Playback expansion
US9891880B2 (en) 2015-03-31 2018-02-13 Sonos, Inc. Information display regarding playback queue subscriptions
US9483230B1 (en) 2015-04-09 2016-11-01 Sonos, Inc. Wearable device zone group control
US10152212B2 (en) 2015-04-10 2018-12-11 Sonos, Inc. Media container addition and playback within queue
US9678707B2 (en) 2015-04-10 2017-06-13 Sonos, Inc. Identification of audio content facilitated by playback device
US9706319B2 (en) 2015-04-20 2017-07-11 Sonos, Inc. Wireless radio switching
US9787739B2 (en) 2015-04-23 2017-10-10 Sonos, Inc. Social network account assisted service registration
US10664224B2 (en) 2015-04-24 2020-05-26 Sonos, Inc. Speaker calibration user interface
WO2016172593A1 (en) 2015-04-24 2016-10-27 Sonos, Inc. Playback device calibration user interfaces
US9678708B2 (en) 2015-04-24 2017-06-13 Sonos, Inc. Volume limit
US9864571B2 (en) 2015-06-04 2018-01-09 Sonos, Inc. Dynamic bonding of playback devices
US10248376B2 (en) 2015-06-11 2019-04-02 Sonos, Inc. Multiple groupings in a playback system
US9544701B1 (en) 2015-07-19 2017-01-10 Sonos, Inc. Base properties in a media playback system
US10021488B2 (en) 2015-07-20 2018-07-10 Sonos, Inc. Voice coil wire configurations
US9729118B2 (en) 2015-07-24 2017-08-08 Sonos, Inc. Loudness matching
US9538305B2 (en) 2015-07-28 2017-01-03 Sonos, Inc. Calibration error conditions
US9712912B2 (en) 2015-08-21 2017-07-18 Sonos, Inc. Manipulation of playback device response using an acoustic filter
US9736610B2 (en) 2015-08-21 2017-08-15 Sonos, Inc. Manipulation of playback device response using signal processing
US10007481B2 (en) 2015-08-31 2018-06-26 Sonos, Inc. Detecting and controlling physical movement of a playback device during audio playback
US10001965B1 (en) 2015-09-03 2018-06-19 Sonos, Inc. Playback system join with base
US9693146B2 (en) 2015-09-11 2017-06-27 Sonos, Inc. Transducer diaphragm
US9779759B2 (en) 2015-09-17 2017-10-03 Sonos, Inc. Device impairment detection
CN108028985B (zh) 2015-09-17 2020-03-13 搜诺思公司 用于计算设备的方法
US9693165B2 (en) 2015-09-17 2017-06-27 Sonos, Inc. Validation of audio calibration using multi-dimensional motion check
US9946508B1 (en) 2015-09-30 2018-04-17 Sonos, Inc. Smart music services preferences
US10042602B2 (en) 2015-09-30 2018-08-07 Sonos, Inc. Activity reset
US9949054B2 (en) 2015-09-30 2018-04-17 Sonos, Inc. Spatial mapping of audio playback devices in a listening environment
US10098082B2 (en) 2015-12-16 2018-10-09 Sonos, Inc. Synchronization of content between networked devices
US10114605B2 (en) 2015-12-30 2018-10-30 Sonos, Inc. Group coordinator selection
US10303422B1 (en) 2016-01-05 2019-05-28 Sonos, Inc. Multiple-device setup
US10284980B1 (en) 2016-01-05 2019-05-07 Sonos, Inc. Intelligent group identification
US9898245B1 (en) 2016-01-15 2018-02-20 Sonos, Inc. System limits based on known triggers
US9743207B1 (en) 2016-01-18 2017-08-22 Sonos, Inc. Calibration using multiple recording devices
US11106423B2 (en) 2016-01-25 2021-08-31 Sonos, Inc. Evaluating calibration of a playback device
US10003899B2 (en) 2016-01-25 2018-06-19 Sonos, Inc. Calibration with particular locations
US9886234B2 (en) 2016-01-28 2018-02-06 Sonos, Inc. Systems and methods of distributing audio to one or more playback devices
US9743194B1 (en) 2016-02-08 2017-08-22 Sonos, Inc. Woven transducer apparatus
US9942680B1 (en) 2016-02-22 2018-04-10 Sonos, Inc. Transducer assembly
US9965247B2 (en) 2016-02-22 2018-05-08 Sonos, Inc. Voice controlled media playback system based on user profile
US9772817B2 (en) 2016-02-22 2017-09-26 Sonos, Inc. Room-corrected voice detection
US9947316B2 (en) 2016-02-22 2018-04-17 Sonos, Inc. Voice control of a media playback system
US10142754B2 (en) 2016-02-22 2018-11-27 Sonos, Inc. Sensor on moving component of transducer
US10264030B2 (en) 2016-02-22 2019-04-16 Sonos, Inc. Networked microphone device control
US10509626B2 (en) 2016-02-22 2019-12-17 Sonos, Inc Handling of loss of pairing between networked devices
US10095470B2 (en) 2016-02-22 2018-10-09 Sonos, Inc. Audio response playback
US9930463B2 (en) 2016-03-31 2018-03-27 Sonos, Inc. Defect detection via audio playback
US9860662B2 (en) 2016-04-01 2018-01-02 Sonos, Inc. Updating playback device configuration information based on calibration data
US9864574B2 (en) 2016-04-01 2018-01-09 Sonos, Inc. Playback device calibration based on representation spectral characteristics
US9763018B1 (en) 2016-04-12 2017-09-12 Sonos, Inc. Calibration of audio playback devices
US9978390B2 (en) 2016-06-09 2018-05-22 Sonos, Inc. Dynamic player selection for audio signal processing
US10152969B2 (en) 2016-07-15 2018-12-11 Sonos, Inc. Voice detection by multiple devices
US9794710B1 (en) 2016-07-15 2017-10-17 Sonos, Inc. Spatial audio correction
US10134399B2 (en) 2016-07-15 2018-11-20 Sonos, Inc. Contextualization of voice inputs
US9860670B1 (en) 2016-07-15 2018-01-02 Sonos, Inc. Spectral correction using spatial calibration
US10372406B2 (en) 2016-07-22 2019-08-06 Sonos, Inc. Calibration interface
US9883304B1 (en) 2016-07-29 2018-01-30 Sonos, Inc. Lifetime of an audio playback device with changed signal processing settings
US10115400B2 (en) 2016-08-05 2018-10-30 Sonos, Inc. Multiple voice services
US10459684B2 (en) 2016-08-05 2019-10-29 Sonos, Inc. Calibration of a playback device based on an estimated frequency response
US9693164B1 (en) 2016-08-05 2017-06-27 Sonos, Inc. Determining direction of networked microphone device relative to audio playback device
US10657408B2 (en) 2016-08-26 2020-05-19 Sonos, Inc. Speaker spider measurement technique
US9794720B1 (en) 2016-09-22 2017-10-17 Sonos, Inc. Acoustic position measurement
US10318233B2 (en) 2016-09-23 2019-06-11 Sonos, Inc. Multimedia experience according to biometrics
US9942678B1 (en) 2016-09-27 2018-04-10 Sonos, Inc. Audio playback settings for voice interaction
US9967689B1 (en) 2016-09-29 2018-05-08 Sonos, Inc. Conditional content enhancement
US9743204B1 (en) 2016-09-30 2017-08-22 Sonos, Inc. Multi-orientation playback device microphones
US9967655B2 (en) 2016-10-06 2018-05-08 Sonos, Inc. Controlled passive radiator
US10712997B2 (en) 2016-10-17 2020-07-14 Sonos, Inc. Room association based on name
US10181323B2 (en) 2016-10-19 2019-01-15 Sonos, Inc. Arbitration-based voice recognition
US10142726B2 (en) 2017-01-31 2018-11-27 Sonos, Inc. Noise reduction for high-airflow audio transducers
US11183181B2 (en) 2017-03-27 2021-11-23 Sonos, Inc. Systems and methods of multiple voice services
US9860644B1 (en) 2017-04-05 2018-01-02 Sonos, Inc. Limiter for bass enhancement
US10735880B2 (en) 2017-05-09 2020-08-04 Sonos, Inc. Systems and methods of forming audio transducer diaphragms
US10028069B1 (en) 2017-06-22 2018-07-17 Sonos, Inc. Immersive audio in a media playback system
US10475449B2 (en) 2017-08-07 2019-11-12 Sonos, Inc. Wake-word detection suppression
US10154122B1 (en) 2017-09-05 2018-12-11 Sonos, Inc. Grouping in a system with multiple media playback protocols
US10048930B1 (en) 2017-09-08 2018-08-14 Sonos, Inc. Dynamic computation of system response volume
US10292089B2 (en) 2017-09-18 2019-05-14 Sonos, Inc. Re-establishing connectivity on lost players
US10446165B2 (en) 2017-09-27 2019-10-15 Sonos, Inc. Robust short-time fourier transform acoustic echo cancellation during audio playback
US10985982B2 (en) 2017-09-27 2021-04-20 Sonos, Inc. Proximal playback devices
US10482868B2 (en) 2017-09-28 2019-11-19 Sonos, Inc. Multi-channel acoustic echo cancellation
US10621981B2 (en) 2017-09-28 2020-04-14 Sonos, Inc. Tone interference cancellation
US10051366B1 (en) 2017-09-28 2018-08-14 Sonos, Inc. Three-dimensional beam forming with a microphone array
US10466962B2 (en) 2017-09-29 2019-11-05 Sonos, Inc. Media playback system with voice assistance
US10880650B2 (en) 2017-12-10 2020-12-29 Sonos, Inc. Network microphone devices with automatic do not disturb actuation capabilities
US10818290B2 (en) 2017-12-11 2020-10-27 Sonos, Inc. Home graph
US11343614B2 (en) 2018-01-31 2022-05-24 Sonos, Inc. Device designation of playback and network microphone device arrangements
US10656902B2 (en) 2018-03-05 2020-05-19 Sonos, Inc. Music discovery dial
US10462599B2 (en) 2018-03-21 2019-10-29 Sonos, Inc. Systems and methods of adjusting bass levels of multi-channel audio signals
US10623844B2 (en) 2018-03-29 2020-04-14 Sonos, Inc. Headphone interaction with media playback system
US10397694B1 (en) 2018-04-02 2019-08-27 Sonos, Inc. Playback devices having waveguides
US10862446B2 (en) 2018-04-02 2020-12-08 Sonos, Inc. Systems and methods of volume limiting
US10698650B2 (en) 2018-04-06 2020-06-30 Sonos, Inc. Temporary configuration of a media playback system within a place of accommodation
US10499128B2 (en) 2018-04-20 2019-12-03 Sonos, Inc. Playback devices having waveguides with drainage features
US10863257B1 (en) 2018-05-10 2020-12-08 Sonos, Inc. Method of assembling a loudspeaker
US11175880B2 (en) 2018-05-10 2021-11-16 Sonos, Inc. Systems and methods for voice-assisted media content selection
US10452345B1 (en) 2018-05-15 2019-10-22 Sonos, Inc. Media playback system with virtual line-in
US10847178B2 (en) 2018-05-18 2020-11-24 Sonos, Inc. Linear filtering for noise-suppressed speech detection
US10959029B2 (en) 2018-05-25 2021-03-23 Sonos, Inc. Determining and adapting to changes in microphone performance of playback devices
US10735803B2 (en) 2018-06-05 2020-08-04 Sonos, Inc. Playback device setup
US10433058B1 (en) 2018-06-14 2019-10-01 Sonos, Inc. Content rules engines for audio playback devices
US10602286B2 (en) 2018-06-25 2020-03-24 Sonos, Inc. Controlling multi-site media playback systems
US10681460B2 (en) 2018-06-28 2020-06-09 Sonos, Inc. Systems and methods for associating playback devices with voice assistant services
US10747493B2 (en) 2018-07-09 2020-08-18 Sonos, Inc. Distributed provisioning of properties of operational settings of a media playback system
US11076035B2 (en) 2018-08-28 2021-07-27 Sonos, Inc. Do not disturb feature for audio notifications
US10461710B1 (en) 2018-08-28 2019-10-29 Sonos, Inc. Media playback system with maximum volume setting
US10299061B1 (en) 2018-08-28 2019-05-21 Sonos, Inc. Playback device calibration
US11206484B2 (en) 2018-08-28 2021-12-21 Sonos, Inc. Passive speaker authentication
US10878811B2 (en) 2018-09-14 2020-12-29 Sonos, Inc. Networked devices, systems, and methods for intelligently deactivating wake-word engines
US10587430B1 (en) 2018-09-14 2020-03-10 Sonos, Inc. Networked devices, systems, and methods for associating playback devices based on sound codes
US11024331B2 (en) 2018-09-21 2021-06-01 Sonos, Inc. Voice detection optimization using sound metadata
US10811015B2 (en) 2018-09-25 2020-10-20 Sonos, Inc. Voice detection optimization based on selected voice assistant service
US11100923B2 (en) 2018-09-28 2021-08-24 Sonos, Inc. Systems and methods for selective wake word detection using neural network models
US10692518B2 (en) 2018-09-29 2020-06-23 Sonos, Inc. Linear filtering for noise-suppressed speech detection via multiple network microphone devices
US10277981B1 (en) 2018-10-02 2019-04-30 Sonos, Inc. Systems and methods of user localization
US11514777B2 (en) 2018-10-02 2022-11-29 Sonos, Inc. Methods and devices for transferring data using sound signals
US11416209B2 (en) 2018-10-15 2022-08-16 Sonos, Inc. Distributed synchronization
US11899519B2 (en) 2018-10-23 2024-02-13 Sonos, Inc. Multiple stage network microphone device with reduced power consumption and processing load
EP3654249A1 (de) 2018-11-15 2020-05-20 Snips Erweiterte konvolutionen und takt zur effizienten schlüsselwortauffindung
US11183183B2 (en) 2018-12-07 2021-11-23 Sonos, Inc. Systems and methods of operating media playback systems having multiple voice assistant services
US11393478B2 (en) 2018-12-12 2022-07-19 Sonos, Inc. User specific context switching
US11132989B2 (en) 2018-12-13 2021-09-28 Sonos, Inc. Networked microphone devices, systems, and methods of localized arbitration
US10602268B1 (en) 2018-12-20 2020-03-24 Sonos, Inc. Optimization of network microphone devices using noise classification
US11740854B2 (en) 2019-01-20 2023-08-29 Sonos, Inc. Playing media content in response to detecting items having corresponding media content associated therewith
US11812249B2 (en) 2019-02-07 2023-11-07 Mayht Holding B.V. In line damper bellows dual opposing driver speaker
US11315556B2 (en) 2019-02-08 2022-04-26 Sonos, Inc. Devices, systems, and methods for distributed voice processing by transmitting sound data associated with a wake word to an appropriate device for identification
US10867604B2 (en) 2019-02-08 2020-12-15 Sonos, Inc. Devices, systems, and methods for distributed voice processing
US11356777B2 (en) 2019-02-28 2022-06-07 Sonos, Inc. Playback transitions
US11188294B2 (en) 2019-02-28 2021-11-30 Sonos, Inc. Detecting the nearest playback device
US11184666B2 (en) 2019-04-01 2021-11-23 Sonos, Inc. Access control techniques for media playback systems
US10998615B1 (en) 2019-04-12 2021-05-04 Sonos, Inc. Spatial antenna diversity techniques
US11120794B2 (en) 2019-05-03 2021-09-14 Sonos, Inc. Voice assistant persistence across multiple network microphone devices
KR20200130151A (ko) * 2019-05-10 2020-11-18 현대자동차주식회사 M2m 시스템에서 서비스 엔티티를 확인하기 위한 방법 및 장치
US11178504B2 (en) 2019-05-17 2021-11-16 Sonos, Inc. Wireless multi-channel headphone systems and methods
US10681463B1 (en) 2019-05-17 2020-06-09 Sonos, Inc. Wireless transmission to satellites for multichannel audio system
US10880009B2 (en) 2019-05-24 2020-12-29 Sonos, Inc. Control signal repeater system
US11126243B2 (en) 2019-06-07 2021-09-21 Sonos, Inc. Portable playback device power management
US11342671B2 (en) 2019-06-07 2022-05-24 Sonos, Inc. Dual-band antenna topology
US11093016B2 (en) 2019-06-07 2021-08-17 Sonos, Inc. Portable playback device power management
US11416210B2 (en) 2019-06-07 2022-08-16 Sonos, Inc. Management of media devices having limited capabilities
US11943594B2 (en) 2019-06-07 2024-03-26 Sonos Inc. Automatically allocating audio portions to playback devices
US10586540B1 (en) 2019-06-12 2020-03-10 Sonos, Inc. Network microphone device with command keyword conditioning
US11361756B2 (en) 2019-06-12 2022-06-14 Sonos, Inc. Conditional wake word eventing based on environment
US11200894B2 (en) 2019-06-12 2021-12-14 Sonos, Inc. Network microphone device with command keyword eventing
US11523206B2 (en) 2019-06-28 2022-12-06 Sonos, Inc. Wireless earbud charging
US11138969B2 (en) 2019-07-31 2021-10-05 Sonos, Inc. Locally distributed keyword detection
US10871943B1 (en) 2019-07-31 2020-12-22 Sonos, Inc. Noise classification for event detection
US11138975B2 (en) 2019-07-31 2021-10-05 Sonos, Inc. Locally distributed keyword detection
US10734965B1 (en) 2019-08-12 2020-08-04 Sonos, Inc. Audio calibration of a portable playback device
US11539545B2 (en) 2019-08-19 2022-12-27 Sonos, Inc. Multi-network playback devices
US11528574B2 (en) 2019-08-30 2022-12-13 Sonos, Inc. Sum-difference arrays for audio playback devices
US11818187B2 (en) 2019-08-31 2023-11-14 Sonos, Inc. Mixed-mode synchronous playback
US10754614B1 (en) 2019-09-23 2020-08-25 Sonos, Inc. Mood detection and/or influence via audio playback devices
US11762624B2 (en) 2019-09-23 2023-09-19 Sonos, Inc. Capacitive touch sensor with integrated antenna(s) for playback devices
US11303988B2 (en) 2019-10-17 2022-04-12 Sonos, Inc. Portable device microphone status indicator
US11189286B2 (en) 2019-10-22 2021-11-30 Sonos, Inc. VAS toggle based on device orientation
US11483670B2 (en) 2019-10-30 2022-10-25 Sonos, Inc. Systems and methods of providing spatial audio associated with a simulated environment
US11636855B2 (en) 2019-11-11 2023-04-25 Sonos, Inc. Media content based on operational data
US11204737B2 (en) 2019-11-11 2021-12-21 Sonos, Inc. Playback queues for shared experiences
US11093689B2 (en) 2019-11-12 2021-08-17 Sonos, Inc. Application programming interface for browsing media content
US11212635B2 (en) 2019-11-26 2021-12-28 Sonos, Inc. Systems and methods of spatial audio playback with enhanced immersiveness
US11200900B2 (en) 2019-12-20 2021-12-14 Sonos, Inc. Offline voice control
US11409495B2 (en) 2020-01-03 2022-08-09 Sonos, Inc. Audio conflict resolution
US11562740B2 (en) 2020-01-07 2023-01-24 Sonos, Inc. Voice verification for media playback
US11175883B2 (en) 2020-01-17 2021-11-16 Sonos, Inc. Playback session transitions across different platforms
US11556307B2 (en) 2020-01-31 2023-01-17 Sonos, Inc. Local voice data processing
US11308958B2 (en) 2020-02-07 2022-04-19 Sonos, Inc. Localized wakeword verification
US11445301B2 (en) 2020-02-12 2022-09-13 Sonos, Inc. Portable playback devices with network operation modes
US11528555B2 (en) 2020-02-19 2022-12-13 Sonos, Inc. Acoustic waveguides for multi-channel playback devices
US11422770B2 (en) 2020-03-03 2022-08-23 Sonos, Inc. Techniques for reducing latency in a wireless home theater environment
US11356764B2 (en) 2020-03-03 2022-06-07 Sonos, Inc. Dynamic earbud profile
US11038937B1 (en) 2020-03-06 2021-06-15 Sonos, Inc. Hybrid sniffing and rebroadcast for Bluetooth networks
US11348592B2 (en) 2020-03-09 2022-05-31 Sonos, Inc. Systems and methods of audio decoder determination and selection
US11418556B2 (en) 2020-03-23 2022-08-16 Sonos, Inc. Seamless transition of source of media content
US11496848B2 (en) 2020-03-25 2022-11-08 Sonos, Inc. Thermal control of audio playback devices
US11758214B2 (en) 2020-04-21 2023-09-12 Sonos, Inc. Techniques for clock rate synchronization
US11523207B2 (en) 2020-04-21 2022-12-06 Sonos, Inc. Cable retraction mechanism for headphone devices
AU2021259316B2 (en) 2020-04-21 2023-11-23 Sonos, Inc. Priority media content
US11727919B2 (en) 2020-05-20 2023-08-15 Sonos, Inc. Memory allocation for keyword spotting engines
US11308962B2 (en) 2020-05-20 2022-04-19 Sonos, Inc. Input detection windowing
US11482224B2 (en) 2020-05-20 2022-10-25 Sonos, Inc. Command keywords with input detection windowing
US11528551B2 (en) 2020-06-01 2022-12-13 Sonos, Inc. Acoustic filters for microphone noise mitigation and transducer venting
US11737164B2 (en) 2020-06-08 2023-08-22 Sonos, Inc. Simulation of device removal
US11553269B2 (en) 2020-06-17 2023-01-10 Sonos, Inc. Cable assemblies for headphone devices
WO2022047458A1 (en) 2020-08-24 2022-03-03 Sonos, Inc. Multichannel playback devices and associated systems and methods
US11698771B2 (en) 2020-08-25 2023-07-11 Sonos, Inc. Vocal guidance engines for playback devices
US11943823B2 (en) 2020-08-31 2024-03-26 Sonos, Inc. Techniques to reduce time to music for a playback device
US11758326B2 (en) 2020-09-09 2023-09-12 Sonos, Inc. Wearable audio device within a distributed audio playback system
US11809778B2 (en) 2020-09-11 2023-11-07 Sonos, Inc. Techniques for extending the lifespan of playback devices
US20220103199A1 (en) 2020-09-29 2022-03-31 Sonos, Inc. Audio Playback Management of Multiple Concurrent Connections
US11831288B2 (en) 2020-10-23 2023-11-28 Sonos, Inc. Techniques for enabling interoperability between media playback systems
US11812240B2 (en) 2020-11-18 2023-11-07 Sonos, Inc. Playback of generative media content
US11551700B2 (en) 2021-01-25 2023-01-10 Sonos, Inc. Systems and methods for power-efficient keyword detection
US11930328B2 (en) 2021-03-08 2024-03-12 Sonos, Inc. Operation modes, audio layering, and dedicated controls for targeted audio experiences
EP4305864A1 (de) 2021-03-08 2024-01-17 Sonos, Inc. Aktualisierung von netzwerkkonfigurationsparametern
US11818427B2 (en) 2021-03-26 2023-11-14 Sonos, Inc. Adaptive media playback experiences for commercial environments
US11700436B2 (en) 2021-05-05 2023-07-11 Sonos, Inc. Content playback reminders
WO2023056336A1 (en) 2021-09-30 2023-04-06 Sonos, Inc. Audio parameter adjustment based on playback device separation distance

Family Cites Families (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
FR2449379A1 (fr) * 1979-02-15 1980-09-12 Scart Systeme d'interconnexion dynamique audio-video
JP2725257B2 (ja) * 1987-09-16 1998-03-11 ソニー株式会社 ディジタル記録装置
US5317693A (en) * 1991-04-04 1994-05-31 Digital Equipment Corporation Computer peripheral device network with peripheral address resetting capabilities
JP3243803B2 (ja) * 1991-08-28 2002-01-07 ソニー株式会社 Ａｖ機器
GB2268816B (en) * 1992-07-14 1996-01-17 Sony Broadcast & Communication Controlling equipment
US5404460A (en) * 1994-01-28 1995-04-04 Vlsi Technology, Inc. Method for configuring multiple identical serial I/O devices to unique addresses through a serial bus
US5655148A (en) * 1994-05-27 1997-08-05 Microsoft Corporation Method for automatically configuring devices including a network adapter without manual intervention and without prior configuration information
US5787246A (en) * 1994-05-27 1998-07-28 Microsoft Corporation System for configuring devices for a computer system

Also Published As

Publication number Publication date
WO1999035816A3 (en) 1999-08-26
EP1046258A2 (de) 2000-10-25
DE69836101D1 (de) 2006-11-16
EP1046258B1 (de) 2006-10-04
ATE341875T1 (de) 2006-10-15
US6032202A (en) 2000-02-29
WO1999035816A2 (en) 1999-07-15
AU2020399A (en) 1999-07-26
CA2317801A1 (en) 1999-07-15

Similar Documents

Publication Publication Date Title
DE69836101T2 (de) Ein audio-video-gerät
DE69829219T2 (de) Verfahren und system in verbindung mit einem audio-video-netz
DE69829221T2 (de) Ein audio-video-netzwerk
DE69829218T2 (de) Ein audio-video-netzwerk mit gerätsteuerung
DE60036072T2 (de) Verfahren zur brückenverbindung von mehreren heimnetzsoftwarearchitekturen
DE69921342T2 (de) Verfahren und system zur elektronischen kommunikation
DE69838801T2 (de) Auf Browser basiertes Steuerungs- und Kontrollheimnetzwerk
US6052750A (en) Home audio/video network for generating default control parameters for devices coupled to the network, and replacing updated control parameters therewith
DE60119559T2 (de) Überbrückungssystem zur zusammenarbeit von entfernten gerätegruppen
DE60019750T2 (de) Allgemeines api zur gerätefernsteuerung
DE60036604T2 (de) Informationsarchitektur höchsten niveaus für ein an geräte angepasstes hausnetzwerk
DE69930534T2 (de) Szenarioandeutende Anrufe für Steuerung von Softwareobjekten mittels Eigenschaftsverbindungen
DE69819757T2 (de) Digitales fernsehgerät zum steuern eines peripheriegerätes über einen digitalen bus
DE602004011517T2 (de) Einbetten einer upnp av mediaserverobjektidentifikation in einem uri
DE60303903T2 (de) Verfahren zur Erzeugung einer graphischen Benutzerschnittstelle auf einem HAVi Gerät für die Steuerung eines nicht HAVi Gerätes
DE60030102T2 (de) Rundsendeentdeckung in einem netz mit einem oder mehreren 1394-bussen
DE102005011333A1 (de) Verfahren zum Übertragen von Daten in einem Netzwerk verteilter Stationen sowie Netzwerkstation
DE102004018980A1 (de) Verfahren zur Steuerung eines Gerätes in einem Netzwerk verteilter Stationen sowie Netzwerkstation
DE102005040924B3 (de) Verfahren zur Bereitstellung einer Bedienoberfläche zur Auswahl mindestens eines elektronischen Informations- und/oder Kommunikationsgerätes

Legal Events

Date Code Title Description
8364 No opposition during term of opposition