DE60036072T2 - Verfahren zur brückenverbindung von mehreren heimnetzsoftwarearchitekturen - Google Patents

Verfahren zur brückenverbindung von mehreren heimnetzsoftwarearchitekturen Download PDF

Info

Publication number
DE60036072T2
DE60036072T2 DE60036072T DE60036072T DE60036072T2 DE 60036072 T2 DE60036072 T2 DE 60036072T2 DE 60036072 T DE60036072 T DE 60036072T DE 60036072 T DE60036072 T DE 60036072T DE 60036072 T2 DE60036072 T2 DE 60036072T2
Authority
DE
Germany
Prior art keywords
network
software
havi
architecture
home
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
DE60036072T
Other languages
English (en)
Other versions
DE60036072D1 (de
Inventor
Yevgeniy E. Shteyn
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.)
Koninklijke Philips NV
Original Assignee
Koninklijke Philips Electronics NV
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 Koninklijke Philips Electronics NV filed Critical Koninklijke Philips Electronics NV
Application granted granted Critical
Publication of DE60036072D1 publication Critical patent/DE60036072D1/de
Publication of DE60036072T2 publication Critical patent/DE60036072T2/de
Anticipated expiration legal-status Critical
Expired - Lifetime legal-status Critical Current

Links

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F15/00Digital computers in general; Data processing equipment in general
    • G06F15/16Combinations of two or more digital computers each having at least an arithmetic unit, a program unit and a register, e.g. for a simultaneous processing of several programs
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00Data switching networks
    • H04L12/28Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H04L12/40Bus networks
    • H04L12/40052High-speed IEEE 1394 serial bus
    • H04L12/40091Bus bridging
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00Data switching networks
    • H04L12/28Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H04L12/2803Home automation networks
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00Data switching networks
    • H04L12/28Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H04L12/2803Home automation networks
    • H04L12/2805Home Audio Video Interoperability [HAVI] networks
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00Data switching networks
    • H04L12/28Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H04L12/2803Home automation networks
    • H04L12/283Processing of data at an internetworking point of a home automation network
    • H04L12/2832Interconnection of the control functionalities between home networks
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00Data switching networks
    • H04L12/28Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H04L12/40Bus networks
    • H04L12/40052High-speed IEEE 1394 serial bus
    • H04L12/40117Interconnection of audio or video/imaging devices

Description

  • ANWENDUNGSBEREICH DER ERFINDUNG
  • Die Erfindung bezieht sich auf ein System und ein Verfahren, die es Netzen mit möglicherweise unterschiedlicher Softwarearchitektur, wie einem HAVi-Heimnetz und einem auf Home-API basierenden oder einem auf JINI basierenden Heimnetz, erlauben zusammenzuarbeiten.
  • STAND DER TECHNIK
  • Heimnetze und entsprechende Softwarearchitekturen wie JINI von Sun Microsystems, Inc. (http://www.sun.com/jini), HAVi (http://www.havi.org), Home-API (http://www.homeapi.org) und Universal-Plug-and-Plag (UPnP) von Microsoft (http://www.upnp.org) stehen inzwischen für Anwendungsentwickler, Gerätehersteller und Diensteanbieter (Service Provider) zur Verfügung.
  • HAVi-Softwarearchitektur
  • HAVi betrifft einen Kern von Schnittstellen zur Anwendungsprogrammierung (eng. Application Programming Interfaces, API) für digitale Geräte der Unterhaltungselektronik in einem Heimnetz und stellt einen Standard für die Audio- bzw. Videoelektronik- und Multimedia-Industrie bereit. Eine API spezifiziert das Verfahren, das erforderlich ist, um Anfragen an ein Betriebssystem oder Anwendungsprogramm zu stellen. Das Heimnetz wird als verteilte Computerplattform angesehen. Das primäre Ziel des als HAVi-(Home Audio/Video interoperability)Architektur bezeichneten Standards besteht darin sicherzustellen, dass Produkte von verschiedenen Anbietern interoperieren, d. h. zusammenarbeiten können, um Anwendungsaufgaben auszuführen. Aktuelle Einrichtungen der Unterhaltungselektronik wie Einrichtungen der Heimunterhaltung (DVD-Player, DV-Camcorder, digitale Fernsehgeräte usw.) sind Systeme der digitalen Verarbeitung und digitalen Speicherung. Die Verbindung dieser Einrichtungen in Netzen ermöglicht eine gemeinsame Nutzung der Verarbeitungs- und Speicherressourcen. Dadurch kann die Steuerung von mehreren Einrichtungen der Unterhaltungselektronik gleichzeitig koordiniert werden, um beispielsweise die Benutzerinteraktion zu vereinfachen. Beispielsweise kann eine erste Einrichtung die Aufnahme auf einer zweiten Einrichtung instanzieren, während auf eine elektronische Programmzeitschrift (engl. Electronic Program Guide, EPG) auf einer dritten Einrichtung zugegriffen wird. Das Heimnetz liefert die Grundlage für die Verbindung der Einrichtungen der Unterhaltungselektronik. Es ermöglicht verbundenen Einrichtungen, sowohl Steuer-(wenn eine Einrichtung einen Befehl an eine andere sendet) als auch AV-(Audio/Video) Daten (wenn eine Einrichtung einen Audio- oder Videostrom an eine andere Einrichtung sendet) auszutauschen. Das Netz muss zu diesem Zweck verschiedene Anforderungen erfüllen. Es muss rechtzeitig den Transfer von AV-Datenströmen mit hoher Geschwindigkeit unterstützen. Das Netz muss die Selbstkonfiguration, die Selbstorganisation und das Hot Plug-and-Plag unterstützen und muss mit kostengünstiger Verkabelung und Schnittstellen auskommen.
  • Die HAVi-Softwarearchitektur ist plattformunabhängig und basiert auf Java. HAVi nutzt das Hochleistungs-IEEE-1394-Serienbusprotokoll für den Transport von Steuerung und Inhalt zwischen den mit dem Netz verbundenen Einrichtungen. Der IEEE-1394-Standard ist ein dynamisch konfigurierbares kostengünstiges digitales Netz. IEEE 1394 definiert sowohl eine Ausführung als physikalische so genannte Backplane als auch als verkabelter virtueller Punkt-zu-Punkt-Bus. Die Backplaneversion funktioniert mit 12,5, 25 oder 50 Mbit/s. Die Kabelversion unterstützt Transferraten von 100, 200 und 400 Mbit/s. Der Standard spezifiziert die Medien, die Topologie und das Protokoll. Das IEEE-1394-Transportprotokoll ist aufgrund seiner hohen Transferrate besonders nützlich bei der Unterstützung von Audio- und Videokommunikationsprotokollen.
  • Die HAVi-Architektur steuert die Einrichtungen der Unterhaltungselektronik in dem Netz durch abstrakte Darstellungen der Einrichtungen der Unterhaltungselektronik. Die abstrakten Darstellungen werden von einem Controller gesteuert und verbergen die Eigenheiten der zugehörigen reellen Einrichtung der Unterhaltungselektronik. Die abstrakte Darstellung bietet somit eine einheitliche Schnittstelle für Software höherer Ebenen. Die abstrakten Darstellungen werden mit ihren Steuereigenschaften registriert, die diejenigen der dargestellten Einrichtung wiedergeben. Die abstrakten Darstellungen machen den Anwendungen ihre so genannten Interoperabilitäts-API zugänglich und bilden gemeinsam einen Satz mit Diensten zum Einrichten von tragbaren verteilten Anwendungen in dem Heimnetz.
  • Die Architektur ermöglicht es einer Einrichtung, einen Befehl oder Steuerinformationen zu einer anderen Einrichtung in dem Heimnetz zu senden. Eine HAVi-konforme Einrichtung enthält Daten (die obige abstrakte Darstellung bezeichnet als Device Control Model oder DCM, siehe nachfolgende Erläuterung), die ihre Benutzerschnittstelle (beispielsweise grafische Benutzerschnittstelle, GUI) und ihre Steuerfähigkeiten betreffen. Diese Daten umfassen beispielsweise den HAVi-Bytecode (Java), der hinauf geladen und von anderen Einrichtungen im Netz ausgeführt werden kann. Eine HAVi-konforme Einrichtung verfügt als Minimum über ausreichende Funktionalität, um mit anderen Einrichtungen in dem System zu kommunizieren. Während der Interaktion können Einrichtungen Steuerung und Daten in einem so genannten P2P-Netz (Peer-to-Peer-Netz) austauschen. Dadurch wird sichergestellt, dass auf der Kommunikationsebene keine der Einrichtungen als Master oder Controller des Systems zu agieren braucht. Andererseits erlaubt es einem logischen Master oder Controller, dem grundlegenden P2P-Kommunikationsmodell eine Steuerungsstruktur aufzuerlegen. HAVi unterscheidet zwischen Controller und gesteuerten Einrichtungen, wie nachfolgend erläutert wird. Ein Controller ist eine Einrichtung, die für eine gesteuerte Einrichtung als Host agiert. Ein Controller hostet die abstrakte Darstellung für die gesteuerte Einrichtung. Die Steuerschnittstelle wird über die API der abstrakten Darstellung zugänglich gemacht. Diese API ist der Zugangspunkt für Anwendungen zur Steuerung der Einrichtung.
  • HAVi-konforme Einrichtungen der Unterhaltungselektronik werden folgendermaßen kategorisiert: so genannte FAV-Einrichtungen (Full-AV), IAV-Einrichtungen (Intermediate-AV) und BAV-Einrichtungen (Base-AV).
  • Eine FAV-Einrichtung enthält einen vollständigen Satz mit Softwarekomponenten der HAVi-Softwarearchitektur (siehe unten). Eine FAV-Einrichtung ist dadurch gekennzeichnet, dass sie eine Laufzeitumgebung für den HAVi-Bytecode aufweist. Dadurch kann eine FAV-Einrichtung den Bytecode von anderen Einrichtungen hinauf laden, um beispielsweise erweiterte Fähigkeiten für ihre Steuerung bereitzustellen. Eine FAV-Einrichtung kann beispielsweise aus einer HAVi-konformen Set-Top-Box, einem HAVi-konformen digitalen Fernsehempfänger und einem Heim-PC gebildet werden. Ein intelligenter Fernsehempfänger kann beispielsweise der HAVi-Controller von anderen Einrichtungen sein, die in dem Netz verbunden sind. Der Empfänger erhält den Bytecode von einer anderen Einrichtung hinauf geladen, um eine Benutzerschnittstelle für diese Einrichtung und eine externe Steuerung dieser Einrichtung zu schaffen. Es kann veranlasst werden, dass ein diese Einrichtung darstellendes Symbol auf dem Fernsehbildschirm erscheint, und durch die Interaktion des Benutzers mit dem Symbol können Elemente des Steuerprogramms veranlasst werden, die dargestellte Einrichtung auf eine vorher spezifizierte Art zu bedienen.
  • Eine IAV-Einrichtung stellt keine Laufzeitumgebung für den HAVi-Bytecode bereit, kann jedoch eine native Unterstützung für die Steuerung bestimmter Einrichtungen in dem Heimnetz bieten. Eine IAV-Einrichtung umfasst integrierte Softwareelemente, die eine Schnittstelle für die Steuerung allgemeiner Funktionen der bestimmten Einrichtungen schaffen. Diese Softwareelemente brauchen nicht der HAVi-Bytecode zu sein und können als native Anwendungen in der IAV-Einrichtung ausgeführt werden, die native Schnittstellen für den Zugang zu anderen Einrichtungen nutzt.
  • Eine BAV-Einrichtung kann den hinaufladbaren HAVi-Bytecode bereitstellen, hostet jedoch keines der Softwareelemente der HAVi-Architektur. Eine BAV-Einrichtung ist durch eine FAV-Einrichtung mit Hilfe des hinaufgeladenen Bytecodes der ersteren steuerbar. Eine BAV-Einrichtung ist durch eine IAV-Einrichtung über den nativen Code steuerbar. Die Kommunikation zwischen einer FAV- oder einer IAV-Einrichtung einerseits und einer BAV-Einrichtung andererseits erfordert die Übersetzung des HAVi-Bytecodes zum und vom von der BAV-Einrichtung verwendeten Befehlsprotokoll.
  • Die Hauptsoftwareelemente, die in der Kernspezifikation der HAVi-Architektur enthalten sind, sind nachfolgend aufgelistet. Für eine ausführlichere Erläuterung dieser Elemente wird auf die HAVi-Spezifikation verwiesen, die durch Nennung als hierin aufgenommen betrachtet wird.
    • 1) Ein so genannter 1394-Communications Media Manager (CMM) wirkt als Schnittstelle zwischen den anderen Softwareelementen und dem IEEE 1394.
    • 2) Ein so genannter Eventmanager (EM) informiert die verschiedenen Softwareelemente über Ereignisse im Netz, wie Änderungen der Netzkonfiguration, die auftreten, wenn Geräte zum Netz hinzugefügt oder aus ihm entfernt werden.
    • 3) Eine so genannte Registry (Registrierdatenbank) hält Informationen über die mit dem Netz verbundenen Geräte und die von ihnen gebotenen Funktionen aufrecht. Anwendungen können diese Informationen von der Registry erhalten.
    • 4) Ein so genanntes Messaging System (MS) dient als API, die die Kommunikation zwischen den Softwareelementen der verschiedenen Geräte im Netz erleichtert. Das MS stellt für die HAVi-Softwareelemente Kommunikationsfunktionen bereit. Es ist unabhängig vom Netz und den Transportschichten. Ein MS ist in jeglicher FAV- und IAV-Einrichtung integriert. Das MS ist für die Zuordnung von Identifikatoren für die abstrakten Darstellungen in der FAV- oder IAV-Einrichtung zuständig. Diese Identifikatoren werden zuerst von den abstrakten Darstellungen dazu verwendet, sich in der FAV- oder IAV-Einrichtung zu registrieren. Dann werden sie von den abstrakten Darstellungen dazu verwendet, sich untereinander innerhalb des Heimnetzes zu identifizieren. Wenn eine erste abstrakte Darstellung eine Meldung an eine andere abstrakte Darstellung senden möchte, muss sie beim Aufrufen der Messaging-API den Identifikator der letzteren verwenden.
    • 5) Ein so genanntes Device Control Module (DCM) stellt ein Gerät im Netzwerk dar. Anwendungsprogramme können direkt mit einem DCM interagieren. Dies schirmt sie vor den Eigenheiten jedes einzelnen Gerätes ab.
    • 6) Ein so genannter DCM-Manager installiert die DCMs. Er reagiert automatisch auf Veränderungen im Netzwerk, indem er neue DCMs für neue Geräte installiert.
    • 7) Ein so genannter Data Driven Interaction (DDI-) Controller gibt im Auftrag eines HAVi-Softwareelementes eine grafische Benutzerschnittstelle (GUI) auf der Anzeige eines Gerätes wieder. Er unterstützt ein großes Spektrum an Anzeigen, von der grafischen bis zur reinen Textanzeige. Ein DCM kann eine Benutzerschnittstelle (UI) bereitstellen. Der DCM kann die Benutzerschnittstelle auf einer oder mehreren Einrichtungen in dem Netz darstellen, die über eine Anzeige verfügen. Ein Mechanismus zum Erreichen dieses Ziels wird DDI (Data Driven Interaction) genannt. Mit Hilfe dieses Mechanismus kann ein DCM eine DDI-Beschreibung seiner Benutzerschnittstelle bieten. Die Beschreibung kann von jeglicher HAVi-konformen Einrichtung mit einer Anzeige abgerufen werden. Der Benutzer kann mit der Benutzerschnittstelle über die lokale Anzeige interagieren. Eine Benutzerinteraktion bewirkt das Senden von Meldungen an das zugeordnete DCM zur Steuerung der physikalischen Einrichtung, die durch das DCM dargestellt wird.
    • 8) Ein so genannter Stream Manager (SMGR) erstellt Verbindungen und leitet Echtzeit-AV-Datenströme zwischen zwei und mehr Geräten im Netz weiter.
  • Die HAVi-Architektur spezifiziert mindestens zwei Ebenen der Interoperabilität, bezeichnet als Ebene 1 und Ebene 2.
  • Die Interoperabilität der Ebene 1 betrifft den allgemeinen Bedarf daran, existierenden Einrichtungen die Kommunikation auf einer grundlegenden Funktionalitätsebene zu ermöglichen. Zu diesem Zweck definiert und verwendet die Interoperabilität der Ebene 1 einen allgemeinen Satz mit Steuermeldungen (Befehlen), die eine Einrichtung befähigen, mit einer anderen Einrichtung zu kommunizieren, und einen Satz mit Ereignismeldungen, die es eigentlich von einer Einrichtung angesichts seiner Klasse (Fernseher, Videorecorder, DVD-Player usw.) erwarten sollte. Zur Unterstützung dieses Ansatzes ist ein grundlegender Satz mit Mechanismen erforderlich: Geräteerkennung, Kommunikation und ein HAVi-Meldungssatz.
  • Bezüglich der Geräteerkennung benötigt jede Einrichtung in dem Heimnetz ein genau definiertes Verfahren, das es ihr ermöglicht, ihre Fähigkeiten anderen mitzuteilen. Der HAVi-Ansatz besteht darin, die so genannten SDD-Daten (Self-Describing Data) zu nutzen. Die SDD-Daten werden in allen Einrichtungen im Netz benötigt. SDD-Daten umfassen als Minimum ausreichend Informationen, um die Instanzierung eines so genannten integrierten DCM zu ermöglichen. Ein integriertes DCM ist ein vorher in einer steuernden IAV- oder FAV-Einrichtung in einem plattformabhängigen Code installierter Teilcode, der native Schnittstellen nutzt, um auf die Ressourcen der IAV- oder FAV-Einrichtungen zuzugreifen. Wie oben erwähnt ist ein DCM für eine Einrichtung ein Softwareelement, das eine Schnittstelle zum Steuern von allgemeinen Funktionen der Einrichtungen schafft. Die Instanzierung eines integrierten DCM bewirkt die Registrierung der Fähigkeiten der Einrichtung in einer Registrierdatenbank. Die Registrierdatenbank stellt einen Verzeichnisdienst bereit und ermöglicht es jeglichem Objekt in dem Netz, ein anderes Objekt in dem Netz zu lokalisieren. Die Registrierung erlaubt es Anwendungen, den grundlegenden Satz mit Befehlsmeldungen abzuleiten, die zu einer bestimmten Einrichtung in dem Netz gesendet werden können.
  • Bezüglich der Kommunikation muss eine Anwendung, nachdem sie die Fähigkeiten einer Einrichtung ermittelt hat, auf diese Fähigkeiten zugreifen können. Dies erfordert eine allgemeine Kommunikationsfähigkeit, die es Anwendungen erlaubt, Anfragen an Einrichtungen auszugeben. Dieser Dienst wird von den HAVi-MS und DCMs bereitgestellt. Die Anwendung sendet HAVi-Meldungen an DCMs, und die DCMs führen dann selbst Kommunikation mit den Einrichtungen aus.
  • Bezüglich der HAVi-Meldungssätze ist zur Unterstützung der Interoperabilität der Ebene 1 ein genau definierter Satz mit Meldungen erforderlich, der von allen Einrichtungen einer betreffenden bekannten Klasse (beispielsweise der Klasse der Fernsehempfänger, der Klasse der Videorecorder, der Klasse der DVD-Player usw.) unterstützt werden muss. Dadurch wird sichergestellt, dass eine Einrichtung mit existierenden Einrichtungen sowie mit zukünftigen Einrichtungen unabhängig vom Hersteller zusammenarbeiten kann.
  • Diese drei grundlegenden Anforderungen unterstützen einen gewissen minimalen Grad der Interoperabilität. Da jegliche Einrichtung die Fähigkeiten einer anderen über die Registrierdatenbank abfragen kann, kann jegliche Einrichtung den von einer anderen Einrichtung unterstützten Meldungssatz ermitteln. Da Anwendungen Zugriff auf das MS haben, kann jegliche Einrichtung mit jeglicher anderen Einrichtung interagieren.
  • Die Interoperabilität der Ebene 1 stellt sicher, dass Einrichtungen auf einer grundlegenden Funktionalitätsebene zusammenarbeiten können. Es ist jedoch ein erweiterter Mechanismus erforderlich, der es einer Einrichtung auch erlaubt, mit anderen Einrichtungen mit jeglicher zusätzlichen Funktionalität zu kommunizieren, die nicht in den integrierten DCMs in einer FAV-Einrichtung vorliegt. Beispielsweise unterstützen integrierte DCMs eventuell nicht alle Funktionen von existierenden Produkten und werden wahrscheinlich auch nicht die vollständig neuen Funktionen von zukünftigen Produktkategorien unterstützen. Die Interoperabilität der Ebene 2 stellt diesen Mechanismus bereit. Zu diesem Zweck lässt die HAVi-Architektur hinaufladbare DCMs als Alternative zu den oben erwähnten integrierten DCMs zu. Das hinauf geladene DCM kann ein existierendes DCM in einer FAV-Einrichtung ersetzen. Ein hinaufladbares DCM kann von jeglicher geeigneten Quelle bereitgestellt werden, ein gängiges Verfahren besteht jedoch darin, das hinaufladbare DCM in den HAVi-SDD-Daten der BAV-Einrichtung zu platzieren und von der BAV-Einrichtung zur FAV-Einrichtung hinauf zu laden, wenn die BAV-Einrichtung mit dem Heimnetz verbunden ist. Da die HAVi-Architektur anbieterneutral ist, ist es notwendig, dass das hinauf geladene DCM in einer Vielzahl von FAV-Einrichtungen mit jeweils möglicherweise unterschiedlicher Hardwarearchitektur funktioniert. Zu diesem Zweck werden hinauf geladene DCMs im HAVi- (Java) Bytecode ausgeführt. Die Laufzeitumgebung des HAVi-Bytecodes in FAV-Einrichtungen unterstützt die Instanzierung und Ausführung von hinauf geladenen DCMs. Nachdem das DCM erstellt wurde und in einer FAV-Einrichtung läuft, kommuniziert es mit den BAV-Einrichtungen in der gleichen Weise wie oben beschrieben.
  • Die Effizienz der Interoperabilität der Ebene 2 wird deutlich, wenn man die Ressourcen betrachtet, die erforderlich sind, um auf die Funktionalität einer bestimmten Einrichtung zuzugreifen. Die Ebene 2 erlaubt es einer Einrichtung, über ein hinauf geladenes DCM gesteuert zu werden, das alle von der Einrichtung gebotenen Fähigkeiten zeigt, während zum Erzielen der gleichen Funktionalität in Ebene 1 dieses DCM irgendwo im Netz integriert sein müsste. Wenn beispielsweise eine neue Einrichtung zum Netz hinzugefügt wird, erfordert es die Ebene 1, dass mindestens eine andere Einrichtung ein integriertes DCM umfasst, das mit der neuen Einrichtung kompatibel ist. Zum Vergleich erfordert es die Ebene 2 lediglich, dass eine Einrichtung eine Laufzeitumgebung für das von der neuen Einrichtung erhaltene hinauf geladene DCM schafft.
  • Das Konzept des Hinaufladens und Ausführens des Bytecodes bietet außerdem die Möglichkeit für gerätespezifische Anwendungen, die so genannten Device Control Applications. Durch diese Anwendungen kann ein Gerätehersteller dem Benutzer die Möglichkeit bieten, spezielle Merkmale einer Einrichtung zu steuern, ohne dass alle Merkmale im HAVi genormt sein müssen. Die Anwendung wird von einem DCM im HAVi-Bytecode bereitgestellt und kann von jeder FAV-Einrichtung im Netz hinauf geladen und installiert werden.
  • Für weitere Informationen wird auf die frei zugängliche HAVi-Spezifikation und IEEE-1394-Spezifikation verwiesen. Die HAVi-Kernspezifikation wurde beispielsweise unter http://www.sv.philips.com/news/press ins Web gestellt und wird durch Nennung als hierin aufgenommen betrachtet.
  • Home-API-Architektur
  • Ein Home-API-System umfasst Softwaredienste und Schnittstellen zur Anwendungsprogrammierung (Application Programming Interface, API), die es auf einem PC laufenden Softwareanwendungen erlauben, steuerbare Einrichtungen, die in dem System registriert sind, zu erkennen und mit ihnen zu interagieren. Die Heimumgebung kann Einrichtungen wie Fernseher, Videorecorder, Set-Top-Boxen, Haussicherheitssysteme, Beleuchtung usw. einschließen. Home-APIs sind protokollunabhängig und verbergen Unterschiede in den zugrunde liegenden Netzen und den Protokollen der Kommunikation zwischen den Einrichtungen, die von den Softwareanwendungen transparent sind. Die Art des Zugriffs einer Anwendung auf eine Einrichtung ist einheitlich und unabhängig von dem zugrunde liegenden Protokoll, das für die Kommunikation mit der Einrichtung eingesetzt wird.
  • Softwareanwendungen interagieren mit den Einrichtungen, indem sie Eigenschaften von zur Darstellung dieser Einrichtungen erstellten Softwareobjekten einstellen oder erhalten. Anwendungen können auch an Ereignissen teilnehmen, die Änderungen der Eigenschaften einer Einrichtung betreffen, damit ihnen diese Änderungen gemeldet werden.
  • Die Home-API-Architektur umfasst Komponenten genannt Diensteanbieter (Service Provider). Diese Komponenten sind für entsprechende Einrichtungen und Netze bestimmt und dienen dazu, die Operationen auf hoher Ebene an den Eigenschaften des Softwareobjekts in Befehle umzusetzen, die über das Netz an die zugeordneten Einrichtungen gesendet werden. Die Diensteanbieter führen die Home-API-Softwareobjekte aus. Die Diensteanbieterkomponente ist außerdem für die Erzeugung von Ereignissen bei Eigenschaftsänderungen für die Objekte zuständig, die dem Diensteanbieter zugeordnet sind.
  • Im Detail setzt die Home-API ein Rechenmodell ein, das auf der so genannten Component-Object-Model-(COM/DCOM)Technologie von Microsoft basiert. Für nähere Informationen wird beispielsweise auf die Component Object Model Specification, Version 0.9 vom Oktober 1995, von Microsoft verwiesen, die durch Nennung als hierin aufgenommen betrachtet wird. COM ist objektorientiert. Ein Objekt hat Eigenschaften, die Steuerfunktionen einer zugeordneten elektronischen Einrichtung darstellen, wie sie einer Softwareanwendung zugänglich gemacht werden. Eine Zustandsänderung eines Objekts infolge eines externen Ereignisses wird zur Softwareanwendung weitergeleitet. Die Anwendung wirkt auf die Objekte, indem sie ihre Eigenschaften verändert oder einstellt. Verändert die Anwendung eine Eigenschaft eines einer gewissen physikalischen Einrichtung zugeordneten Objekts, wird ein Befehl an die zugeordnete Einrichtung gesendet.
  • COM ist ein allgemeiner Mechanismus, der es Anwendungen erlaubt konsistent zu kommunizieren und ein Rahmen für die Entwicklung und Unterstützung von Programmkomponentenobjekten. Es bietet ähnliche Fähigkeiten wie in CORBA (Common Object Request Broker Architecture) definiert, dem Rahmen für das Zusammenwirken von verteilten Objekten in einem Netz. OLE (Object Linking and Embedding) stellt Dienste für das Verbunddokument bereit, das der Benutzer auf seiner Anzeige sieht, COM liefert die zugrunde liegenden Dienste der Schnittstellenabstimmung und die Ereignisdienste (indem es ein Objekt infolge eines bei einem anderen Objekt geschehenen Ereignisses in Betrieb setzt). Bei dieser Ausführung werden Clients als OLE-Automatisierungsobjekte (abstrakte Darstellungen) modelliert, die Eigenschaften verwenden, um Steuerungen und Ereignisse für Signalzustandsänderungen zugänglich zu machen. Die OLE-Automatisierung ist eine COM-Technologie, die das Scripting und die späte Bindung von Clients an Server erlaubt. Die OLE-Automatisierung schafft die Kommunikation mit anderen Programmen durch das Aufrufen von Merkmalen (Befehle und Anfragen), die die Programme für die externe Verwendung verfügbar gemacht haben. Vor dem Einsatz eines Objekts muss eine Client-Anwendung als Erstes den Schnittstellenzeiger des Objekts erhalten. Der Schnittstellenzeiger ist über das Verzeichnis des Netzes verfügbar, indem der Name des Objekts gebunden wird oder die Einrichtungen aufgezählt werden. Es können Standard-COM-APIs für die Moniker-Bindung eingesetzt werden. Verweise auf Objekte sind durch Aufrufen von GetObject oder CoGetObject mit einem String verfügbar, der den Namen oder die Identität der gewünschten Einrichtung spezifiziert. Die Anwendung kann dann auf das Objekt wirken, indem sie seine Eigenschaften durch Aufrufe von „set property" auf die geeigneten Eigenschaften einstellt oder sie abruft. Wenn eine Anwendung eine Eigenschaft eines mit einer Einrichtung korrespondierenden Objekts einstellt oder verändert, wird die Operation der Einstellung der Eigenschaft oder die Operation der Veränderung in einen Befehl umgewandelt, der über das Netz zu der betreffenden Einrichtung gesendet wird. Die Objekte können sich in der Ausführung unterscheiden, weisen jedoch ein ähnliches, auf Eigenschaften basierendes Modell für Client-Anwendungen auf, die auf einem Controller, beispielsweise einem PC mit einem auf Windows basierenden Betriebssystem, laufen.
  • JINI-Architektur
  • JINI vereinfacht die Verbindung und die gemeinsame Nutzung von Einrichtungen in einem Netz. Bei herkömmlichen Systemen erfordert das Hinzufügen einer Einrichtung zu einem PC oder einem Netz die Installation und das Hochfahren. Bei JINI gibt die Einrichtung ihre Existenz bekannt und liefert Informationen über ihre Funktionen. Danach wird die Einrichtung zugänglich für andere Ressourcen in dem Netz. Diese Technologie ermöglicht ein verteiltes Rechnen – die Fähigkeiten werden von den Ressourcen des Netzes gemeinsam genutzt.
  • JINI legt seinen Schwerpunkt auf den Prozess des Hinzufügens einer Einrichtung zu dem Netz und des Verbreitens von Informationen über die Einrichtung an andere Maschinen. Auf diese Weise bietet JINI einen so genannten Suchdienst (Look-Up-Service), der es Anwendungen auf anderen Maschinen erlaubt, die neu hinzugefügte Einrichtung einzusetzen. Der Ansatz von JINI setzt voraus, dass das Netz und das Betriebssystem bereits konfiguriert wurden, so dass jeder Computer bereits von den anderen Computer weiß. Die Funktionalität von JINI erfolgt in einer Schicht oberhalb des Netzes. Es löst beispielsweise nicht die Probleme der automatischen Konfiguration des Netzes nach der Verbindung, der Trennung oder der erneuten Verbindung. Es setzt voraus, dass das Netz unabhängig von JINI verbunden oder unterbrochen ist. JINI setzt die vom Netz gebotenen Dienste wirksam ein, um seine Dienste auszuführen.
  • Im Besonderen stellt die JINI-Netzinfrastruktur Ressourcen bereit zum Ausführen von Java-Programmiersprachenobjekten, Kommunikationsfähigkeiten zwischen diesen Objekten und die Fähigkeit, Dienste im Netz zu finden und zu nutzen. Durch den Einsatz der Java Remote Method Invocation (RMITM) stellt JINI die Kommunikation zwischen Objekten über Einrichtungsgrenzen hinweg bereit und ermöglicht es diesen Objekten somit zusammenzuarbeiten. RMI ermöglicht die Aktivierung von Objekten und den Einsatz von Multicast zum Kontaktieren von replizierten Objekten, wodurch Objekte mit hoher Verfügbarkeit und hoher Zuverlässigkeit leicht im JINI-Framework ausgeführt werden können. RMI ist eine Erweiterung für klassische Mechanismen des Prozedur-Fernaufrufs (Remote Procedure Call, RPC). RMI ermöglicht es, nicht nur Daten von Objekt zu Objekt sondern vollständige Objekte einschließlich Code im Netz weiterzuleiten. Ein Großteil der Einfachheit des JINI-Systems ist auf diese Fähigkeit zurückzuführen, Codes in einem Netz in einer wie ein Objekt verkapselten Form weiterzuleiten. JINI bietet einen Suchdienst, der das Auffinden von Diensten ermöglicht, die durch die Kommunikationsinfrastruktur verbunden sind. JINI bietet ferner einen Mechanismus bezeichnet als Discovery/Join für JINI-fähige Einrichtungen (beispielsweise Festplattenlaufwerke, Drucker und Computer) zum Erkennen des geeigneten Suchdienstes und das Verbinden mit dem Gesamtsystem. Wenn eine Einrichtung mit einem JINI-basierten System verbunden wird, werden seine Dienste zu diesem Suchdienst hinzugefügt. In gleicher Weise werden, wenn eine JINI-fähige Einrichtung das System verlässt, beispielsweise weil sie entfernt oder unzuverlässig wird, ihre Dienste aus dem Suchdienst gelöscht.
  • Für mehr Informationen über Heimnetze, insbesondere über HAVi, den Einsatz der COM-Technologie und der OLE-Automatisierungsobjekte und Home-API und über JINI, wird auf die folgenden Dokumente verwiesen, die durch Nennung als hierin aufgenommen betrachtet werden: die frei zugänglichen Spezifikationen zur HAVi-Architektur (beispielsweise Version 0.86), die Spezifikationen der Component Object Model Specification (beispielsweise Version 0.9), das von der Home-API Working Group veröffentlichte Home-API White Paper vom März 1999, der Überblick über die JINI-Architektur von Sun Microsystems Inc. (einschließlich der Java Remote Invocation Specification, der Java Object Serialization Specification, der JavaSpaces Specification usw.).
  • Jede der speziellen Softwarearchitekturen von HAVi, Home-API, JINI usw. weist ihre eigenen Vorteile und Nachteile auf.
  • Beispielsweise erlaubt es die JINI-Architektur, dass Java-Objekte, die von einer Netzplattformumgebung zu einer anderen übertragen werden, lokal laufen. Andererseits setzt sie plattformspezifische Merkmale nicht immer wirksam ein. Ferner ist JINI, da sie auf Java, einer interpretierten Sprache basiert, nicht so leistungsfähig wie ein kompilierter nativer Code.
  • Die HAVi-Architektur ist für den Einsatz von IEEE-1394-Audio- bzw. Videoausrüstungen mit hoher Bandbreite ausgelegt. Sie bietet die Möglichkeit der Erweiterung durch von Einrichtungen herunter ladbare Softwarekomponenten (DDI, Java usw.) und weitere nützliche Merkmale. Andererseits können Einrichtungen ohne IEEE-1394-Verbindung oder -Schnittstelle nicht einfach von einer HAVi-Anwendung gesteuert werden.
  • Die Home-API-Architektur setzt wirksam die Windows COM/DCOM-Softwarearchitektur und -Dienste ein, ist jedoch noch nicht im großen Rahmen in anderen Betriebssystemen wie UNIX, LINUX, Apple Mac OS usw. verfügbar.
  • Da Rechen- und Steuereinrichtungen wie PCs, Set-Top-Boxen, digitale Fernseher, Videorecorder, X10-Module usw. von Verbrauchern zu verschiedenen Zeitpunkten für verschiedene Zwecke erworben werden, gewinnt es an Bedeutung, Lösungen für die Brückenverbindung von Heimnetzen und Architekturen zu entwickeln. Bei derartigen Softwarelösungen ist es höchst wahrscheinlich, dass sie auf relativ leistungsfähigen Rechenplattformen wie PCs, Set-Top-Boxen, Videospielmaschinen usw. erscheinen. In diesem Zusammenhang dominierten PCs zum Preis von $ 1.000 oder weniger im Laufe von 1998 und in das Jahr 1999 hinein im PC-Einzelhandel immer mehr, wobei die größte Zunahme in dem Preissegment unter $ 600 zu beobachten ist. Die PC-Hersteller Emachines, Packard-Bell und NEC sind aktuell (1999) die Hauptlieferanten für dieses Marktsegment. Emachines bietet beispielsweise PCs unter $ 600 an, die Hochleistungselemente wie DVD-Laufwerke, schnelle 400-Mhz-Intelprozessoren und 32-MB-RAMs aufweisen. Ähnlich Trends sind im Bereich der Videospiele zu beobachten, wo Sega und andere Firmen planen, 64-Bit-Spielkonsolen auf den Markt zu bringen. Die meisten der neuen Einrichtungen enthalten Modems und andere Verbindungsoptionen, die ihnen das Einbinden in ein Netz ermöglichen.
  • Jede der oben genannten bekannten Softwarearchitekturen bietet einen Dienst, der die Erkennung von Einrichtungen oder Diensten im Netz abstrakt gesehen auf mehr oder weniger ähnliche Weise ermöglicht. Als Endergebnis eines Erkennungsprozesses wird eine Softwaredarstellung einer Einrichtung oder eines Dienstes in einem Suchdienst (oder einer Registry oder einem Verzeichnis) platziert. Die HAVi-Architektur registriert die erkannten Einrichtungen oder Dienste in der Registry, die JINI-Architektur registriert sie in einem Suchdienst, Home-API bezieht sich auf den Dienst als Verzeichnis. Danach werden die registrierten Einrichtungen oder Dienste Softwareanwendungen zur Verfügung gestellt, die auf dem Host laufen. Eine Anwendung lokalisiert die Softwaredarstellung oder das Objekt und nutzt sie oder es, um auf Schnittstellen und Reservierungsprozeduren der betreffenden Softwarearchitektur zuzugreifen.
  • AUFGABE DER ERFINDUNG
  • Es entsteht ein Problem, wenn eine Steuereinrichtung mehr als eine Netzumgebung hostet. Beispielsweise kann ein PC mit einer IEEE-1394-Verbindung Teil einer HAVi- und einer Home-API-Umgebung sein. Daher existiert ein Potenzial dafür, dass auf HAVi-Audio- bzw. Videoeinrichtungen von Home-API-Anwendungen zugegriffen werden kann und umgekehrt Home-API-steuerbare Einrichtungen von HAVi-Anwendungen gesteuert werden usw. Wenn dieses Potenzial in der Praxis umgesetzt würde, würde der Benutzer diese beiden Heimnetzumgebungen als eine wahrnehmen, die Nutzung würde erleichtert und die Zugangsoptionen verbessert. Es würde außerdem Softwareentwicklern erlauben, Anwendungen für ein größeres Spektrum von steuerbaren Einrichtungen zu entwickeln, als es bisher möglich war.
  • Eine weitere Vereinfachung einer derartigen hybriden Funktionalität ist notwendig, damit existierende und zukünftige Heimnetzarchitekturen und -anwendungen berücksichtigt werden können.
  • Dementsprechend liegt der Erfindung die Aufgabe zugrunde, ein Verfahren zu schaffen, das die Brückenverbindung zwischen verschiedenen Heimnetzumgebungen und dadurch eine Erhöhung der Funktionalität des Heimnetzes als Ganzes ermöglicht.
  • ZUSAMMENFASSUNG DER ERFINDUNG
  • Das erfindungsgemäße Verfahren nutzt eine Softwarekomponente (Reference Factory) in einer Netzumgebung. Die Komponente erkennt Softwaredarstellungen von Einrichtungen oder Diensten, die in einem ersten Netz der Umgebung zur Verfügung stehen. Dies kann durch Aufzählung und/oder Überwachung eines Home-API-Verzeichnisses, einer HAVi-Registrierdatenbank, einer JINI-Registrierdatenbank oder einem funktionell gleichwertigen bestandsbezogenen Dienst in dem ersten Netz erfolgen. Nach Erkennung einer neuen Softwaredarstellung durch die so genannte Reference Factory erstellt letztere einen Verweis, der der in dem ersten Netz erkannten Softwaredarstellung zuzuordnen ist. Ein derartiger Verweis umfasst Informationen, beispielsweise eine Klassenidentität, eine so genannte URL (Uniform Ressource Locator), einen eindeutigen Objektidentifikator, einen so genannten XML- oder DDI-Descriptor usw., die für die Erstellung einer zumindest teilweise funktionellen Darstellung der Einrichtung oder des Dienstes innerhalb einer anderen Netzsoftwareumgebung erforderlich sind.
  • Auf die Verweisinformationen wird von einer anderen Softwarekomponente (Object Factory) zugegriffen, die in der Lage ist, derartige Softwaredarstellungen (Objekte) zu erstellen und für das andere Netz verfügbar zu machen. Die so genannte Objekt Factory erstellt falls erforderlich ein Objekt oder ruft ein vorher erstelltes Objekt von beispielsweise einer durch ihre URL gegebenen Website ab oder leitet den Verweis entsprechend den Regeln und/oder Präferenzen der Netzumgebung, mit der sie interagiert, weiter. Diese Präferenzen spiegeln beispielsweise allgemeine Architekturrichtlinien oder bestimmte Benutzerinteressen wieder. Beispielsweise ist lediglich eine gewisse Art von Einrichtungen (Beleuchtung) von Interesse für den Benutzer. Ein weiteres Beispiel ist eine HAVi-Umgebung, in der basierend auf der Netzkonfiguration lediglich DDI-Darstellungen zulässig sind.
  • In einer betreffenden Netzsoftwarearchitektur können mehrere Reference Factories existieren. Jede von ihnen kann für eine bestimmte Art von Verweisen wie für andere Netzsoftwareumgebungen (JINI, HAVi, Home-API, UPnP) oder andere Objektdarstellungen in einem derartigen Netz (beispielsweise für HAVi: Java DCM, DDI-Daten oder native DCM) oder ein Klasse von Einrichtungen bzw. Diensten (Datenspeicherung, Heimautomatisierung, A/V-Befehlssatz usw.) zuständig sein.
  • Die Erfindung basiert auf der Erkenntnis, dass zwei Prozesse getrennt werden sollten – die Analyse der Netzsoftwarekonfiguration einerseits und die Erstellung von für die Steuerung und/oder Interaktion erforderlichen Softwaredarstellungen (Objekten) andererseits. Factory-Verfahren der Objekterstellung sind in der Technik bekannt, siehe beispielsweise „Design Patterns: Elements of Reusable Object-Oriented Software", Addison-Wesley Professional Computing, von Erich Gamma, Richard Helm, Ralph Johnson und John Vlissides, erschienen im Oktober 1994 bei Addison-Wesley Pub. Co., ISBN 0201633612, insbesondere die Seiten 81–116.
  • Im Besonderen betrifft die Erfindung ein Verfahren, das es einem ersten Netz mit einer ersten Softwarearchitektur ermöglicht, mit einem zweiten Netz mit einer zweiten Softwarearchitektur zu interagieren. Das Verfahren umfasst folgende Schritte: Verwenden eines Suchdienstes des ersten Netzes zum Erkennen einer ersten Softwaredarstellung einer Einrichtung oder eines Dienstes in dem ersten Netz; Erstellen eines Verweises für die erste erkannte Softwaredarstellung; Speichern des Verweises in einem Repositorium und Zugreifen auf das Repositorium zum Bestimmen einer zumindest teilweise funktionell gleichwertigen zweiten Softwaredarstellung basierend auf dem Verweis, wobei die zweite Softwaredarstellung von dem zweiten Netz aus zugänglich ist. Das erste und das zweite Netz können identische Softwarearchitekturen aufweisen, beispielsweise auf HAVi basieren, oder das erste und das zweite Netz können verschiedene Softwarearchitekturen aufweisen: beispielsweise basiert eines der ersten und zweiten Netze auf einer HAVi-Architektur und das andere auf einer Home-API-Architektur, eines der ersten und zweiten Netze auf einer HAVi-Architektur und das andere auf einer JINI-Architektur, eines der ersten und zweiten Netze basiert auf einer HAVi-Architektur und das andere auf einer UPnP-Architektur, eines der ersten und zweiten Netze basiert auf einer JINI-Architektur und das andere auf einer Home-API-Architektur, eines der ersten und zweiten Netze basiert auf einer JINI-Architektur und das andere auf einer UPnP- Architektur, eines der ersten und zweiten Netze basiert auf einer UPnP-Architektur und das andere Netz basiert auf einer Home-API-Architektur usw.
  • Jedes der oben genannten Beispiele für Softwarearchitekturen verfügt über einen Erkennungsdienst, der es ermöglicht, einen Bestand von in dem betreffenden Netz registrierten Einrichtungen und/oder Diensten zu erstellen. Das erfindungsgemäße Verfahren nutzt diesen Erkennungsdienst und die Funktionalität der Registrierdatenbank bzw. des Verzeichnisses bzw. des Suchdienstes, um die Verfügbarkeiten erkennen zu können, indem es diesen Bestand abfragt. Danach umfasst das Erstellen das Extrahieren von Informationen über die erste Softwaredarstellung, die aus Sicht des zweiten Netzes von Bedeutung für seine Funktionalität ist, und das Bestimmen umfasst das Erstellen einer zweiten Softwaredarstellung basierend auf den extrahierten Informationen.
  • Auf die folgenden Patentdokumente wird verwiesen, um die Erfindung in die richtige Perspektive zu rücken:
    In dem Dokument EP-A 0 849 913 wird ein Datenkommunikationssystem dargelegt, das Folgendes umfasst: einen ersten Bus zum bidirektionalen Übertragen von digitalen Daten und Befehlen, einen zweiten Bus zum Übertragen von Befehlen zum Steuern von elektronischen Geräten hauptsächlich im Hausgebrauch und eine Verbindungseinrichtung zum Verbinden des ersten und des zweiten Busses. Die Verbindungseinrichtung wandelt ein Paketformat eines asynchronen Übertragungsmodus des ersten Busses in ein Paketformat des zweiten Busses um und wandelt das Paketformat des zweiten Busses in das Paketformat des asynchronen Übertragungsmodus des ersten Busses um.
  • In dem Dokument WO 96/27357 wird Folgendes dargelegt: In einem lokalen Kommunikationssystem mit einer Anzahl von durch einen ersten Datenbus, der einen ersten Satz mit Kommunikationsprotokollen unterstützt, verbundenen Einrichtungen und mindestens einer weiteren mit einem zweiten Bus, der diese Protokolle nicht unterstützt, verbundenen Einrichtung wird, eine Gateway-Einrichtung geschaffen, die den ersten und den zweiten Datenbus verbinden und dadurch eine Kommunikation zwischen ihnen ermöglicht. Der erste Satz mit Protokollen spezifiziert eine maximale Zeitspanne für die Antwort einer ersten Einrichtung auf eine von einer zweiten Einrichtung gesendete Anfrage. Wenn eine Anfrage von einer Einrichtung auf dem ersten Bus zu der weiteren Einrichtung gesendet wird, nimmt der Gateway die Zeitsteuerung für die Anfrage vor und erzeugt und sendet eine temporäre Antwort an die anfragende Einrichtung, wenn von der weiteren Einrichtung keine Antwort innerhalb der spezifizierten maximalen Antwortzeitspanne empfangen wird. Das System kann zwei oder mehr Cluster mit Einrichtungen umfassen, die jeweils durch entsprechende Gateway-Einrichtungen mit dem weiteren Bus verbunden sind.
  • In dem am 12.06.2000 veröffentlichten Dokument EP-A 1 058 422 werden Verfahren zur Brückenverbindung von HAVi- und UPnP-Teilnetzen mit Hilfe einer Brückeneinrichtung dargelegt, die sowohl HAVi- als auch UPnP-fähig ist.
  • Keines dieser Dokumente behandelt oder schlägt die Brückenbildung von Netzen mit unterschiedlichen Softwarearchitekturen wie oben angegeben, basierend auf dem Speichern eines Verweises einer Softwaredarstellung für eine Einrichtung oder einen Dienste in einem der Netze in einem Repositorium und dem Bestimmen einer zweiten Softwaredarstellung beim Zugriff auf das Repositorium von dem anderen Netz aus vor, die funktionell zumindest teilweise gleichwertig mit der ersten Darstellung ist und in dem anderen Netz eingesetzt werden kann.
  • Die folgenden Patentdokumente bieten eventuell weitere Informationen in diesem Zusammenhang:
    • – Die US-amerikanische Patentschrift 6.159.136 (Aktenzeichen des Patentanwalts PHA 23.942), eingereicht am 02.09.1998 für Yevgeniy Shteyn, mit dem Titel „Low Data-Rate Network Represented an High Data-Rate HAVi-Network". Dieses Dokument betrifft ein auf einem PC basierendes Heimautomatisierungssystem, das eine Transportschicht mit geringer Transferrate und auf COM basierende Softwarekomponenten wie Home-API für die Steuerung von Einrichtungen in einem Heimautomatisierungsnetz nutzt. Das Heimautomatisierungssystem wird mit einem auf Messaging basierenden HAVi-Netz gemischt, das IEEE 1394 als Transportschicht mit hoher Transferrate einsetzt. Das HAVi-Netz steuert die Audio- bzw. Videoausstattung in einem Heimunterhaltungssystem. Die Heimautomatisierungsdienste und -einrichtungen werden als HAVi-konforme Elemente in den FAV- oder IAV-Controllern des HAVi-Netzes registriert. Die Heimautomatisierungsressourcen (Einrichtungen und Dienste) verfügen sowohl über COMOLE-Automatisierungsschnittstellen als auch über HAVi-konforme Schnittstellen, die die Steuerung des Heimautomatisierungssystems von dem HAVi-Netz aus erlauben.
    • – Die US-amerikanische Patentschrift 6.163.817 (Aktenzeichen des Patentanwalts PHA 23.438), eingereicht am 30.06.1998 für Yevgeniy Shteyn und Gregory Gewickey, mit dem Titel „Dynamic De-registering of Devices in System with Multiple Communication Protocols". Dieses Dokument betrifft ein Informationsverarbeitungssystem mit einem ersten und einem zweiten elektronischen Teilsystem und Steuermitteln zum Steuern der Teilsysteme. Mindestens das erste Teilsystem verfügt über eine Softwaredarstellung, die in den Steuermitteln registriert ist. Die Steuermittel ändern den Zustand des ersten Teilsystems durch Interaktion mit der Softwaredarstellung. Das erste und das zweite Teilsystem sind auch in der Lage, direkt miteinander zu interagieren, ohne dass die Steuermittel beteiligt sind. Zur Vermeidung von Konflikten ist zumindest das erste Teilsystem in der Lage, sich aus der Registrierung in den Steuermitteln auszutragen und so funktionell seine Softwaredarstellung in den Steuermitteln zu deaktivieren.
    • – Die US-amerikanische Patentschrift 5.959.536 (Aktenzeichen des Patentanwalts PHA 23.169), eingereicht am 15.10.1996 für Paul Chambers und Saurabh Srivastava, mit dem Titel „Task-driven Distributed Multimedia Consumer System". Dieses Dokument betrifft ein Steuersystem mit mehreren Einrichtungen der Unterhaltungselektronik und aufgabengesteuerten, mit den Einrichtungen verbundenen Steuermitteln zum Steuern der Interaktion zwischen den Einrichtungen. Die Steuermittel wirken auf entsprechende Softwaredarstellungen jeder entsprechenden Unterhaltungseinrichtung. Durch Verkapseln der variablen Komplexität der Aufgabe (Task) in einer Softwaredarstellung kann sie so einfach oder so hoch entwickelt wie nötig gemacht werden, um die Fähigkeiten auf eine gemeinsame Ebene zu bringen. Da die Schnittstellenebene für alle Einrichtungen die gleiche ist, können Anwendungen Einrichtungen einheitlich handhaben, die sehr verschiedene Ebenen der Entwicklung aufweisen.
    • – Die US-amerikanische Patentschrift 6.480.473 (Aktenzeichen des Patentanwalts PHA 23.405), eingereicht am 29.12.1998 für Paul Chambers und Steven Curry, mit dem Titel „Verification of Active Nodes in Open Networks". Dieses Dokument betrifft ein Netzabrufprotokoll (Network Polling Protocol), das das Netz als logischen Ring oder lineare Sequenz von miteinander verbundenen Knoten behandelt. Eine Poll-Abfrage wird einfach einen Knoten nach dem anderen nach unten oder in dem Netz weitergeleitet, bis ein vollständiger Bestand aktiver Knoten ermittelt wurde. Die Protokolle umfassen auch Prozeduren zum Kurieren oder Reparieren von Unterbrechungen im Verbindungsprotokoll und zum Hinzufügen neuer Knoten zum Verbindungsprotokoll. Das Verbindungsprotokoll kann auch dazu verwendet werden, hierarchisch verknüpfte Netze einzurichten, in denen Hierarchien der höchsten Ebene Adressen eines dauerhaften Gliedes eines verknüpften Netzes umfassen und Hierarchien der untersten Ebene ein gegebenes verknüpftes Netz sind.
    • – Die US-amerikanische Patentschrift 6.314.459 (Aktenzeichen des Patentanwalts PHA 23.488), eingereicht am 13.08.1998 für Lawrence Freeman, mit dem Titel "Home-Network Autoconfiguration". Dieses Dokument betrifft die automatische Konfigurierung von zwei PCs in einem Netz zur gemeinsamen Nutzung von Ressourcen, die in den einzelnen PCs registriert sind. Lokale Dienste und Ressourcen in einem PC werden bei dem anderen PC registriert und umgekehrt. Die Registrierdatenbank verbirgt, ob ein Dienst oder eine Ressource entfernt oder lokal ist. Beim Betrieb des Netzes ist eine lokale Ressource oder ein lokaler Dienst eines PCs von dem entfernten PC so adressierbar, als wäre sie/er lokal bei letzterem vorhanden. Ein Heimnetz mit PCs wird auf diese Weise automatisch konfiguriert.
    • – Die US-amerikanische Patentschrift 6.918.123 (Aktenzeichen des Patentanwalts PHA 23.483), eingereicht am 02.10.1998 für Yevgeniy Shteyn, mit dem Titel „Calls Identify Scenario for Control of Software Objects via Property Routes". Dieses Dokument betrifft im Besonderen, jedoch nicht ausschließlich, Home-API und ein Informationsverarbeitungssystem mit ersten und zweiten physikalischen Komponenten, die durch erste und zweite Softwareobjekte dargestellt werden. Beide Objekte weisen Eigenschaften auf, die durch Aufrufe an die Objekte verändert werden können. Das System ermöglicht die Registrierung einer Eigenschaftsroute, die eine erste Eigenschaft des ersten Objekts mit einer zweiten Eigenschaft des zweiten Objekts verbindet, so dass eine Änderung der ersten Eigenschaft bewirkt, dass der zweite Aufruf an das zweite Objekt ausgegeben wird, nachdem die Eigenschaftsroute aufgerufen wurde. Der Eingabeaufruf an das erste Objekt umfasst einen Identifikator, der das bedingte Aufrufen der Route ermöglicht. Auf diese Weise bleiben Routen, die zu anderen Szenarien gehören, unabhängig, so dass das System zuverlässiger arbeitet als ohne Identifikatoren des Szenarios.
    • – Die US-amerikanische Patentschrift 6.434.447 (Aktenzeichen des Patentanwalts PH 23.484), eingereicht am 02.10.1998 für Yevgeniy Shteyn, mit dem Titel „Control Property is Mapped Onto Modally Compatible GUI Element". Dieses Dokument betrifft im Besonderen, jedoch nicht ausschließlich, Home-API und ein Informationsverarbeitungssystem, das eine elektronische Einrichtung und einen Controller zur Steuerung einer Funktionalität der Einrichtung umfasst. Eine abstrakte Darstellung der Funktionalität wird dem Controller bereitgestellt. Die abstrakte Darstellung macht eine Modalität zum Steuern der Funktionalität zugänglich. Der Controller ermöglicht die Steuerung der Funktionalität durch die Interaktion mit der abstrakten Darstellung. Die Modalität steuert die Zuordnung der Steuerung der Funktionalität zu einer modal kompatiblen Steuerungsfähigkeit des Controllers. Die zugänglich gemachte Modalität kann beispielsweise Boolescher Natur, veränderlicher Natur oder eine ganzzahlige Matrix sein.
    • – Die US-amerikanische Patentschrift 6.970.081 (Aktenzeichen des Patentanwalts PHA 23.503), eingereicht am 21.10.1998 für Doreen Cheng, mit dem Titel „Distributed Software Controlled Theft Detection". Dieses Dokument betrifft das Schaffen eines Rahmens für ein Sicherheitssystem, das eigentumspezifisch ist. Der Rahmen umfasst ein verteiltes softwaregesteuertes Sicherheitssystem, das den Zustand von einzelnen Eigentumseinrichtungen überwacht und bewertet. Die Aktivierung eines Alarms und die als Reaktion auf den Alarm ergriffene Maßnahme werden durch den Zustand der gesicherten Eigentumseinrichtungen und die jedem Zustand der Kombination von Zuständen zugeordneten Regeln bestimmt. In Abhängigkeit von den Fähigkeiten der einzelnen Eigentumseinrichtungen werden die Sicherheitsfunktionen zwischen den Einrichtungen verteilt. Bei einer bevorzugten Ausführungsform erfolgt die Übertragung von Meldungen zwischen den Komponenten des Systems in Übereinstimmung mit HAVi- oder Home-API-Standards, wodurch die Interoperabilität zwischen den Komponenten verschiedener Hersteller möglich wird.
    • – Das Dokument WO 0017789 (Aktenzeichen des Patentanwalts PHA 23.500), eingereicht für Adrian Turner et al, mit dem Titel „Customized Upgrading of Internet-enabled Devices Based an User-Profile". Dieses Dokument betrifft ein Serversystem, das ein Benutzerprofil eines bestimmten Endbenutzers einer netzfähigen Einrichtung der Unterhaltungselektronik aufrechterhält, und eine Datenbank mit neuen technischen Merkmalen für diese Art der Einrichtung, beispielsweise ein Heimnetz. Besteht eine Übereinstimmung zwischen dem Benutzerprofil und einem neuen technischen Merkmal und gibt der Benutzer an, dass er Informationen über Updates oder Verkaufsangebote empfangen möchte, wird der Benutzer über das Netz über die Option informiert, dieses Merkmal zu erhalten.
    • – Das Dokument WO 0028436 (Aktenzeichen des Patentanwalts PHA 23.527), eingereicht für Yevgeniy Shteyn, mit dem Titel „Upgrading of Synergetic Aspects of Home Networks". Dieses Dokument betrifft ein System mit einem Server, der Zugriff auf einen Bestand an Einrichtungen und Fähigkeiten in dem Heimnetz eines Benutzers hat. Der Bestand ist beispielsweise ein Suchdienst, wie er von HAVi-, JINI- und Home-API-Architekturen geboten wird. Der Server hat ebenfalls Zugriff auf eine Datenbank mit Informationen über Merkmale für ein Netz. Der Server ermittelt, ob die Synergie der in dem Netz des Benutzers vorliegenden Geräte basierend auf der Auflistung des Bestands und dem Profil des Benutzers verbessert werden kann. Existieren basierend auf diesen Kriterien für die Synergie relevante Merkmale, wird der Benutzer informiert.
    • – Das Dokument WO 0028398 (Aktenzeichen des Patentanwalts PHA 23.528), eingereicht für Yevgeniy Shteyn, mit dem Titel „Content Supplied as Software Objekts for Copyright Protection". Dieses Dokument betrifft die Lieferung von Inhaltsinformationen beispielsweise einen Film, eine Audiodatei oder eine Textmeldung an einen Endbenutzer. Die Inhaltsinformationen sind in einem Softwareobjekt enthalten, das eine verkapselte Prozedur für den Zugriff auf Inhaltsinformationen durch den Endbenutzer in einer Laufzeitumgebung aufweist. Das Objekt kann einen Zeitrahmen für die Inhaltsinformationen und eine Art des Zugriffs auf diese Informationen spezifizieren. Da die Prozedur in dem Objekt zusammen mit den Inhaltsdaten verkapselt ist und die Übertragung des Objekts über das Internet nach der seriellen Anordnung erfolgt, wird ein angemessener Grad der Sicherheit gegen unerlaubtes Abspielen oder Kopieren geschaffen.
    • – Die US-amerikanische Patentschrift 6.499.062 (Aktenzeichen des Patentanwalts PHA 23.529), eingereicht am 17.12.1998 für Yevgeniy Shteyn, mit dem Titel „Synchronizing Property Changes to Enable Multiple Control Options". Dieses Dokument betrifft im Besonderen, jedoch nicht ausschließlich, Home-API und behandelt ein Informationsverarbeitungssystem wie ein Heimnetz. Komponenten in dem Netz werden durch Softwareobjekte dargestellt, deren Eigenschaften durch Funktionsaufrufe (siehe oben genanntes COM) verändert werden können. Das Einstellen einer Eigenschaft eines Objekts steuert die zugeordnete Komponente. Die Eigenschaften sind durch Routen miteinander verbunden, die Zustandsänderungen im ganzen System weiterleiten, ohne dass eine Client-Anwendung laufen muss. Zweiweg-Eigenschaftsrouten werden dazu verwendet, die Konsistenz zwischen einem gesteuerten Objekt und mehreren steuernden Objekten zu erhalten, ohne dass die Gefahr endloser Schleifen besteht. Zu diesem Zweck wird die Zweiwegroute zur Änderung des Zustandes einer der Eigenschaften nach der Änderung des Zustandes einer anderen Eigenschaft ausgeführt, wenn die Änderung des Zustands der anderen Eigenschaft durch einen anderen Effekt als die Route selbst verursacht wurde.
  • Dieser Mechanismus ermöglicht die automatische Synchronisierung von Komponenten von mehreren Steuereingängen aus.
  • Die Erfindung erlaubt es Softwareentwicklern auch, Anwendungen mit einem größeren Spektrum an steuerbaren Einrichtungen zu schaffen, als es vorher möglich war, beispielsweise in einer Anwendung zur Netzpersonalisierung, wie sie in dem Dokument WO 0017789 (Aktenzeichen des Patentanwalts PHA 23.500), eingereicht für Adrian Turner et al, und dem oben erwähnten Dokument WO 0028436 (Aktenzeichen des Patentanwalts PHA 23.527), eingereicht für Yevgeniy Eugene Shteyn, mit dem Titel „Upgrading of Synergetic Aspects of Home Networks" dargelegt wird. Zur Personalisierung von Diensten wird auch auf die US-amerikanische Patentschrift 6.611.654 (Aktenzeichen des Patentanwalts 23.633), eingereicht am 01.04.1999 für Yevgeniy Eugene Shteyn, mit dem Titel „Time- and Location-driven Personalized TV" verwiesen. Dieses Dokument betrifft ein Serversystem und ein Verfahren, das es einem Teilnehmer ermöglicht, ein bestimmtes Rundfunkprogramm zum Aufzeichnen und einen bestimmten Ort und Zeitrahmen zum Abspielen des aufgezeichneten Programms auszuwählen.
  • KURZE BESCHREIBUNG DER ZEICHNUNGEN
  • Ausführungsbeispiele der Erfindung sind in den Zeichnungen dargestellt und werden im Folgenden näher beschrieben. Es zeigen:
  • 1 ein Blockschaltbild eines die Erfindung darstellenden Systems;
  • 2 ein Blockschaltbild einer HAVi- bzw. Home-API-Hardwarekonfiguration; und
  • die 3 und 4 Blockschaltbilder, die Softwarekonfigurationen für ein HAVi-Home-API-System darstellen.
  • Ähnliche oder entsprechende Merkmale haben in allen Figuren die gleichen Bezugszeichen.
  • BEVORZUGTE AUSFÜHRUNGSFORMEN
  • Die Erfindung ermöglicht es, Heimnetze mit unterschiedlichen Softwarearchitekturen zu integrieren. Verweise auf Softwaredarstellungen von Einrichtungen und Diensten in einem ersten Netz werden automatisch erstellt. Die Verweise reichen semantisch für die automatische Erstellung von zumindest teilweise funktionell gleichwertigen Softwaredarstellungen für ein zweites Netz aus, so dass Einrichtungen und Dienste des ersten Netzes von dem zweiten Netz aus zugänglich sind.
  • Konzepte der Blockschaltbilder
  • 1 ist ein Blockschaltbild eines Systems 100 zur Darstellung der Erfindung. Das System 100 umfasst ein erstes und ein zweites Netz 102 und 104 mit unterschiedlicher Softwarearchitektur. Beispielsweise hat das Netz 102 eine auf HAVi basierende Architektur und das Netz 104 eine auf Home-API basierende Architektur oder das Netz 102 hat eine auf JINI basierende Architektur und das Netz 104 eine auf HAVi basierende Architektur usw.
  • Das erste Netz 102 verfügt über einen Dienst 106, der das Abfragen der Softwaredarstellungen 108, 110, ..., 112 von Ressourcen (Einrichtungen und Diensten) ermöglicht, die in dem Netz 102 registriert wurden. Beim Abfragen werden die Attribute der Darstellungen 108112 durchsucht. Der Dienst 106 ermöglicht die Registrierung, die Austragung aus der Registrierung und die Abfrage von Ressourcen, die gesteuert werden können und mit denen interagiert werden kann. Die Registrierung einer Ressource erfordert einen Satz mit Attributen und einen Verweis für die Darstellung. Die Austragung aus der Registrierung erfordert das Liefern desselben Verweises und das Deaktivieren des Zugriffs auf den Verweis durch Softwareanwendungen oder andere Softwareobjekte. Die Abfrage erfordert das Schaffen eines vollständigen oder Teilsatzes mit Attributen, mit denen die registrierten Eingaben abgeglichen werden. In gleicher Weise verfügt das Netz 104 über einen Dienst 114, der die Erkennung und Steuerung von Ressourcen ermöglicht, deren Softwaredarstellungen 116, 118, 120 in ihm registriert sind.
  • Das System 100 verfügt über Mittel 122, die eine Brückenverbindung zwischen den Netzen 102 und 104 herstellen und dazu dienen, dem Netz 102 die Steuerung von einer oder mehreren im Netz 104 registrierten Ressourcen zu übertragen.
  • Die Mittel 122 umfassen ein Softwaremodul (ein Objekt oder eine Anwendung) 124 genannt Reference Factory. Die Reference Factory 124 ist in dem Netz 104 installiert und hat über den Dienst 114 Zugriff auf jegliche der Softdarstellungen 116120. Die Reference Factory 124 ist in der Lage, den Bestand des Dienstes 114 abzufragen oder über eine neue Softwaredarstellung gemäß den Verfahren der Softwarearchitektur des Netzes 104 informiert zu werden. In diesem Sinne ist die Factory 124 spezifisch für das Netz 104. Hat die Reference Factory 124 ein interessierendes Objekt, beispielsweise die Softwaredarstellung 116, gefunden, erstellt die Factory 124 einen Verweis oder einen Satz mit Verweisen auf die Darstellung 116.
  • Die Mittel 122 verfügen ferner über einen so genannten Associations Container 126, eine Softwaredarstellung für ein Repositorium für die von der Factory 122 erstellten Verweise, damit diese allen Clients des Netzes 104 zur Verfügung gestellt werden.
  • Die Mittel 122 verfügen ebenfalls über eine so genannte Software Element Factory 128, die in dem Netz 102 installiert ist. Die Factory 128 wählt Verweise aus dem Container 126 aus und erstellt vorgefertigte Softwaredarstellungen oder ruft sie ab basierend auf den in den ausgewählten und für eine Installation im Netz 102 geeigneten Verweisen enthaltenen Informationen, indem sie sie beispielsweise bei dem Dienst 106 registriert oder dort gemäß den durch die Softwarearchitektur des Netzes 102 vorgegebenen Regeln platziert. Nach der Registrierung im Dienst 106 werden die Ressourcen im Netz 104 von dem Netz 102 aus zugänglich und steuerbar.
  • Die Factory 124 ist in der Lage, die Regeln der Softwarearchitektur des Netzes 104 einzusetzen, um auf den Dienst 114 zuzugreifen und Informationen zum Erstellen der Verweise zu extrahieren. Die Factory 128 ist in der Lage, die Regeln der Softwarearchitektur des Netzes 102 einzusetzen, um zum Registrieren neu erstellter Softwaredarstellungen basierend auf den Verweisen im Repositorium 126 auf den Dienst 106 zuzugreifen. Die Factory 124 und die Factory 128 haben eine Schnittstelle über das Repositorium 126. Das Repositorium 126 sollte daher in der Lage sein, den Informationsinhalt der von der Factory 124 für die Factory 128 erstellten Verweise zu übertragen. Zu diesem Zweck besteht ein möglicher Mechanismus darin, dass die Factory 124 und die Factory 128 eine Schnittstelle zum Repositorium 126 aufweisen, die auf derselben Sprache, beispielsweise XML, basiert. Dies bedeutet, dass die als Ausgangsdaten von der Factory 124 gelieferten Verweise direkt als Eingangsdaten für die Factory 128 verwendet werden können. Ein weiterer Mechanismus besteht darin, es dem Repositorium 126 zu ermöglichen, die von der Factory 124 empfangenen Informationen mit Hilfe eines Konvertierungsprotokolls in auf geeignete Weise formatierte Ausgangsdaten für die Factory 128 zu übersetzen oder zu konvertieren. In diesem Zusammenhang wird beispielsweise auf die oben erwähnte US-amerikanische Patentschrift 6.434.447 (Aktenzeichen des Patentanwalts PHA 23.484) verwiesen, die eine allgemeine Art des Mapping-Protokolls darlegt. Als Alternative können bestimmte Konvertierungsstufen zwischen dem Repositorium 126 einerseits und den Netzen 102 und 104 andererseits eingefügt werden.
  • Mit den nötigen Abänderungen können ähnliche Mittel 130 hinzugefügt werden, die eine Reference Factory 132, einen Container 134 und eine Software Element Factory 136 umfassen, um die Ressourcen im Netz 102 von dem Netz 104 aus steuerbar zu machen.
  • In dem Netz 104 können mehrere Reference Factories installiert werden, beispielsweise eine weitere Reference Factory 136 zum Schaffen bestimmter Verweisinformationen, damit ein drittes (nicht dargestelltes) Netz mit noch einer anderen Softwarearchitektur eine oder mehrere Funktionen steuern kann, die in dem Netz 104 registriert sind, ähnlich wie die Steuerung vom Netz 102 aus. Jede dieser mehreren Reference Factories kann für gewisse Arten von Verweisen, beispielsweise eine weitere Softwareumgebung (HAVi, JINI, Home-API) oder eine weitere Objektdarstellung innerhalb eines derartigen Netzwerkes (Java DCM für FAV-Einrichtungen, DDI-Daten für grafische Benutzerschnittstellen (GUI), native DCM für IAV-Einrichtungen usw.) oder eine Klasse mit Ressourcen (Einrichtungen bzw. Dienste) zuständig sein, beispielsweise die Datenspeicherung, die Heimautomatisierung, den Audio-/Video-Befehlssatz usw.
  • Das Repositorium 126 kann für eine weitere Software Element Factory 138 für ein viertes Netz zugänglich sein, wobei die weitere Factory in der Lage ist, direkt oder indirekt die Verweise im Repositorium 126 zu bearbeiten.
  • Blockschaltbild Hardwarekonfiguration HAVi – Home-API
  • 2 zeigt die physikalische Konfiguration eines integrierten Heimnetzsystems 200 mit einem auf HAVi basierenden Netz 202 und einem auf Home-API basierenden Netz 204.
  • Das Netz 202 umfasst eine HAVi-Set-Top-Box 206 mit FAV-Fähigkeiten (siehe obige Erläuterung zu HAVi), einen HAVi-konformen Fernseher 208, der als BAV-Einrichtung dient (siehe obige Erläuterung zu HAVi) und einen HAVi-konformen digitalen Videorecorder 210, der ebenfalls als BAV-Einrichtung dient. Die Einrichtungen 206, 208 und 210 sind über einen IEEE-1394-Bus miteinander verbunden, so dass die Set-Top-Box 206 den Fernseher 208 und den digitalen Videorecorder 210 steuern kann.
  • Das Netz 204 umfasst einen PC 212, der so konfiguriert ist, dass er die Beleuchtung 214 über eine X-10-Verbindung, Rasensprenger 216 über eine IR-Verbindung und andere (nicht dargestellte) Geräte über zugeordnete Verbindungen steuert.
  • Die Set-Top-Box 206 und der PC 212 sind über einen IEEE-1394-Bus miteinander verbunden. Die IEEE-1394-Verbindung ermöglicht es dem PC 212, auf IEEE-1394-konforme Einrichtungen zuzugreifen. Zur Nutzung dieser Fähigkeit ist ein Home-API-Diensteanbieter 218 (siehe oben „Hintergrund der Erfindung" oder die Home-API-Spezifikation) für HAVi auf dem PC 204 installiert. Der HAVi-spezifische Diensteanbieter 218 ist in der Lage, auf eine auf einem PC basierende HAVi-FAV-Anwendung oder eine auf einem PC basierende HAVi-IAV-Anwendungsumgebung zuzugreifen. Er kann auch selbst eine FAV- oder IAV-Umgebung ausführen oder installieren, wenn keine verfügbar ist. Der Diensteanbieter 218 bestückt das Home-API-Verzeichnis 220 dann mit COM-Objekten, die HAVi-Einrichtungen, beispielsweise die Einrichtungen 206210, darstellen. Dadurch können Home-API-Awendungen auf dem PC 212 die HAVi-Einrichtungen 206210 steuern.
  • Diese Konfiguration erlaubt es jedoch auf HAVi basierenden Anwendungen in der FAV-Einrichtung 206 nicht, auf Home-API-Softwareobjekte wie diejenigen für die Beleuchtung 214, die Rasensprenger 216 oder andere in dem Verzeichnis 220 registrierte Einrichtungen, zuzugreifen. Damit vom HAVi-Netz 202 ausgehend eine Steuerung möglich wird, muss ein Satz mit HAVi-konformen Softwareelementen (beispielsweise DCMs, FCMs) in einer HAVi-Registrierdatenbank 222 installiert werden. Die Erfindung schlägt nun vor, die Konzepte der Reference Factory und der Software Element Factory einzuführen, um diese Installation wie in Bezug auf 1 erläutert zu ermöglichen. Diese Steuerfähigkeit erlaubt es dem Benutzer beispielsweise, die Beleuchtung 214 über seine HAVi-Set-Top-Box 206 ein- und auszuschalten und die Sprenger 216 anzuhalten oder zeitlich neu zu steuern, wenn er ungestört einen interessanten Film ansehen möchte, usw.
  • Blockschaltbilder für die Erstellung der Softwarekonfiguration HAVi – Home-API
  • 3 ist ein erstes Blockschaltbild, das eine Softwarekonfiguration 300 einer Brückenverbindung zwischen HAVi und Home-API zeigt. Die Konfiguration 300 umfasst einen PC 302 mit einer Home-API-Steuerumgebung 304 und eine HAVi-IAV/FAV-Softwareausführung 306. Die Konfiguration 300 umfasst ebenfalls ein HAVi-Netz 308 und ein Home-API-Netz 310. Mit der Home-API-Umgebung 304 interagierende HAVi-spezifische Softwareelemente ermöglichen es, dass Einrichtungen oder Dienste des Netzes 310, die in der Home-API-Umgebung 304 registriert sind, von dem HAVi-Netz 308 aus gesteuert werden.
  • Wie oben erläutert schafft die Erfindung ein Verfahren, das die Brückenverbindung zwischen verschiedenen Heimnetzumgebungen, hier dem HAVi-Netz 308 und dem Home-API-Netz 310, ermöglicht. Zu diesem Zweck umfasst die Home-API-Umgebung 304 eine Softwarekomponente 312, eine Anwendung oder ein Softwareobjekt und Reference Factory genannt, die Softwaredarstellungen von Einrichtungen und Diensten erkennt, die in der Umgebung 304 zur Verfügung stehen, beispielsweise ein Objekt 314. Diese Erkennung kann durch Aufzählen und/oder Überwachen des Home-API-Verzeichnisses 316 oder durch Zugreifen auf einen Home-API-Stamm oder einen anderen Container erfolgen. Basierend auf den Fähigkeiten der Reference Factory 312 und/oder den Benutzerpräferenzen wird ein Verweis oder ein Satz mit Verweisen erstellt, der der Softwaredarstellung der erkannten Einrichtung oder des erkannten Dienstes zugeordnet ist. Ein derartiger Verweis umfasst Informationen über die Softwaredarstellung, beispielsweise die Objektart, die Eigenschaftsbeschreibung, eine Klassenidentität, eine URL, einen eindeutigen Objektidentifikator, ein XML-Tag, eine DDI-Beschreibung usw., die für die Erstellung einer gleichwertigen Softwaredarstellung derselben Einrichtung oder desselben Dienstes, jetzt jedoch für den Einsatz innerhalb eines anderen Netzes, hier der HAVi-Umgebung 304 und dem Netz 310, erforderlich sind. Die Factory 312 nutzt Home-API-Meldungsmechanismen, wie Ereignisteilnahme oder Eigenschaftsrouten, um zur Umgebung 304 hinzugefügte Softwareobjekte zu erkennen. Wenn ein Softwareobjekt zu der Home-API-Umgebung 304 hinzugefügt wird, wird die Reference Factory 312 benachrichtigt, und es wird/werden, falls erforderlich, (ein) Verweis(e) erstellt und in einem so genannten Reference Container 318 platziert, der dem hinzugefügten Objekt zugeordnet ist.
  • In diesem Beispiel stellt der Container 318 die Verweise allen Home-API-Clients zur Verfügung. Beispielsweise greift die Reference Factory 312 auf interessierende Objekte, beispielsweise wie vom Benutzer angegeben, über das Home-API-Verzeichnis 316 zu. Der Benutzer hat beispielsweise angegeben, dass er an den Objekten „Beleuchtung" 214 interessiert ist. Die Benutzerpräferenzen können durch eine Konfigurationsanwendung bzw. -führung erzielt werden. Die Anwendung oder Führung listet beispielsweise alle verfügbaren Einrichtungen oder Arten von Einrichtungen in einer Netzumgebung auf. Sie sammelt Benutzereingaben bezüglich derjenigen von ihnen, die über ein anderes Netz zugänglich sein sollen. Die Reference Factory 312 identifiziert die interessierenden Softwareobjekte in dem Verzeichnis 310 und erstellt einen Satz mit Verweisen für HAVi-Softwareelemente wie jene, die DDI-Daten, einen Java-DCM-Verweis oder einen nativen (binären) DCM umfassen, jedoch nicht hierauf beschränkt. Diese Verweise werden in dem Reference Container 318 für „Beleuchtung" 214 platziert. Nachdem die Reference Factory 312 installiert ist, wird sie beispielsweise durch den Home-API-Ereignismechanismus zum Home-API-Stamm hinzugefügt. Das Installationsprogramm kann die Factory 312 zu einem bestimmten Container oder zu einem Teil des Home-API-Verzeichnisses 316, wie „Wohnzimmer", hinzufügen, damit lediglich die Beleuchtung im Wohnzimmer gesteuert werden kann. Wenn ein neues Beleuchtungsobjekt zum Netz 310 hinzugefügt wird, erstellt die Factory 312 einen neuen Verweis, beispielsweise eine DDI-Beschreibung und eine URL für ein Java-Paket, das die neue Beleuchtung darstellt. Diese Verweise werden dann zum Container 318 der neuen Beleuchtung hinzugefügt.
  • Eine HAVi-Software Element Factory 320 ist die Softwarekomponente, die für den Zugriff auf interessierende Home-API-Objekte zuständig ist. In diesem Beispiel wählt sie geeignete Verweise aus dem Container 318 für das Objekt „Beleuchtung" aus. Die Factory 320 erstellt HAVi-Softwareelemente basierend auf den abgerufenen Verweisen und mit Hilfe von internen oder externen Ressourcen (beispielsweise dem Internet). Es wird beispielsweise auf die oben erwähnte Infrastruktur verwiesen, wie sie in den Dokumenten WO 00017789 und WO 0028436 dargelegt ist. Der PC 302 verfügt über einen DCM-Manager 322 und eine Registry 324 als Teile der HAVi-IAV/FAV-Ausführung auf dem PC 302. Die Factory 320 interagiert mit dem HAVi-DCM-Manager 322 und der HAVi-Registry 324 gemäß den HAVi-Architekturregeln und/oder den Präferenzen der Element Factory. Die Factory 320 erstellt beispielsweise DDI-Daten, um die Funktionalität des Horne-API-Objekts „Beleuchtung" über eine Anzeige und HAVi-Anwendungen zugänglich zu machen, die vom HAVi-Netz 308 gehostet werden. Als Alternative oder Ersatz erstellt oder ruft die Factory 320 aus dem Internet (über eine URL) ein Java-DCM ab und registriert es in der Registry 324, um es den HAVi-Anwendungen oder anderen DCMs zu ermöglichen, mit der Softwaredarstellung der „Beleuchtung" 214 zu interagieren.
  • Hinsichtlich der Installation der Reference Factory 302 kann diese beispielsweise durch einen Gerätehersteller während der Installation einer Einrichtung im Netz aktiviert werden. Beispielsweise können Beleuchtungen von Philips im Paket mit PC- Software verkauft werden, die das Softwareobjekt Reference Factory 302 umfassen und den Zugriff auf HAVi erlauben. Die Installation kann von einem Diensteanbieter, von dem Benutzer selbst oder von Dritten als Teil eines Upgrades der PC-Softwarefunktionalität vorgenommen werden.
  • Hinsichtlich der Installation der Software Element Factory 320 kann diese von einem HAVi-Diensteanbieter oder von einem Dritten, dem Benutzer selbst oder einem Diensteanbieter installiert werden, um eine existierende Element Factory aufzurüsten.
  • 4 ist ein zweites Blockschaltbild, das eine Softwarekonfiguration 400 einer Brückenverbindung zwischen HAVi und Home-API darstellt. Die Konfiguration umfasst einen PC 302 mit einer Home-API-Steuerumgebung 304 und einem Home-API-Netz 310. Die Konfiguration 400 umfasst ebenfalls ein HAVi-Netz 308, das eine HAVi-FAV-Einrichtung 402 enthält. Der PC 302 verfügt nun über ein Softwaremodul 404 zur Darstellung der Home-API-Steuerumgebung 304 in dem HAVi-Netz 308. Das Modul 404 ist eine HAVi-BAV-Einrichtung, die die Software Element Factory 320 umfasst und mit anderen BAV-Softwarekomponenten interagiert, um das Home-API-Objekt 314 als ein DCM 406 (oder ein FCM) in dem HAVi-Netz 308 darzustellen. Einer oder mehrere (nicht dargestellte) DCM-Manager in HAVi-FAV- oder IAV-Einrichtungen interagieren mit der BAV-Software 404, um das Home-API-Objekt 314 über das DCM 406 im Netz 308 verfügbar zu machen.
  • Es wird auch auf die oben für diese Konfiguration aufgelistete US-amerikanische Patentschrift mit der Seriennummer 09/146.020 (Aktenzeichen des Patentanwalts PHA 23.492) verwiesen.
  • Im Zusammenhang mit der Installation von Softwareelementen wird auf die oben erwähnten Dokumente WO 0017789 (Aktenzeichen des Patentanwalts PHA 23.500), eingereicht für Adrian Turner et al, mit dem Titel „Customized Upgrading of Internet-Enabled Devices Based an User-Profile" und WO 0028436 (Aktenzeichen des Patentanwalts PHA 23.527), eingereicht für Yevgeniy Eugene Shteyn, mit dem Titel „Upgrading Of Synergetic Aspects of Home Networks" verwiesen.
  • Als ein weiteres Beispiel wird eine Brückenverbindung zwischen HAVi und UPnP gebildet, indem HAVi-Softwareelemente dem UPnP-Netz zugänglich gemacht werden und umgekehrt. XML ist die Basis für die Darstellung von Einrichtungen bei UPnP. Damit HAVi-Softwareelemente an einem UPnP-Netz beteiligt sein können, müssen sie eine ihnen zugeordnete XML-Darstellung aufweisen. Eine derartige Darstellung kann automatisch, d. h. bei jeder Verbindungs- bzw. Aufzählungsabfrage, oder vorzugsweise einmal erstellt und in der Registrierdatenbank als ein Attribut des Softwareelements oder ein getrenntes Softwareelement platziert werden, das dem ersteren durch eine eindeutige Softwareelementidentität zugeordnet ist. Wenn eine direkte Übersetzung in XML eines bestimmten HAVi-Softwareelementes funktionell nicht möglich ist (beispielsweise wenn ein Softwareelement durch ein Java-Objekt von Drittherstellern dargestellt wird usw.), kann eine allgemeine XML-Darstellung erstellt werden. Der Hersteller des Softwareelements (DCM, FCM) kann eine bevorzugte XML-Darstellung der Komponente liefern, wenn die Beteiligung an dem UPnP-Netz geplant ist. In gleicher Weise kann die HAVi-DDI-Schnittstelle basierend auf den frei zugänglichen DDI-Benutzerschnittstellenelementen (für weitere Details siehe beispielsweise Abschnitt 4 der HAVi-Spezifikation) in XML übersetzt werden. Der Reflexionsmechanismus von Java kann dazu eingesetzt werden, Schnittstellen eines bestimmten Java-Objekts abzufragen, und ein gleichwertiges XML-Modell kann erstellt werden, wenn die Schnittstelle als bekannt erkannt wird.

Claims (8)

  1. Verfahren, das es einem ersten Heimnetz (104) mit einer ersten Softwarearchitektur ermöglicht, mit einem zweiten Heimnetz (102) mit einer zweiten Softwarearchitektur zu interagieren, wobei das Verfahren Folgendes umfasst: – Verwenden eines Suchdienstes (114) des ersten Netzes zum Erkennen einer ersten Softwaredarstellung (116, 118, 120) einer Einrichtung oder eines Dienstes in dem ersten Netz, – Erstellen (124) eines Verweises auf die erkannte erste Softwaredarstellung, – Speichern des Verweises in einem Repositorium (126) und – Zugreifen auf das Repositorium zum Bestimmen (128) einer zumindest teilweise funktionell gleichwertigen zweiten Softwaredarstellung basierend auf dem Verweis, wobei die zweite Softwaredarstellung von dem zweiten Netz aus zugänglich ist.
  2. Verfahren nach Anspruch 1, wobei das erste und das zweite Netz (202, 204) verschiedene Softwarearchitekturen aufweisen.
  3. Verfahren nach Anspruch 2, wobei – eines der ersten und zweiten Netze auf einer JINI-Architektur basiert und – das andere der ersten und zweiten Netze auf einer HAVi-Architektur basiert.
  4. Verfahren nach Anspruch 2, wobei – eines der ersten und zweiten Netze auf einer JINI-Architektur basiert und – das andere der ersten und zweiten Netze auf einer UPnP-Architektur basiert.
  5. Verfahren nach Anspruch 2, wobei – eines der ersten und zweiten Netze auf einer UPnP-Architektur basiert und – das andere Netz auf einer HAVi-Architektur basiert.
  6. Verfahren nach Anspruch 1, wobei – das erste Netz einen Bestand von Einrichtungen und/oder Diensten umfasst, die in dem ersten Netz registriert sind, – das Erkennen das Abfragen des Bestandes umfasst, – das Erstellen das Extrahieren von Informationen über die erste Softwaredarstellung umfasst, die für das zweite Netz relevant sind, und – das Bestimmen das Schaffen einer zweiten Softwaredarstellung basierend auf den extrahierten Informationen umfasst.
  7. Informationsverarbeitungssystem (100), das Folgendes umfasst: – ein erstes Heimnetz (104) mit einer ersten Softwarearchitektur und – ein zweites Heimnetz (102) mit einer zweiten, von der ersten Softwarearchitektur verschiedenen Softwarearchitektur, wobei – das erste Netz einen Suchdienst (114) umfasst, der es ermöglicht, eine erste Softwaredarstellung (116, 118, 120) einer ersten Einrichtung oder eines ersten Dienstes in dem ersten Netz zu erkennen, – das System einen Verweisgenerator (124) zum Erstellen eines Verweises auf die erste Softwaredarstellung durch Interaktion mit dem Suchdienst umfasst, – das System ein Repositorium zum Speichern des Verweises umfasst und – das System einen Softwareelementgenerator (128) zum Zugreifen auf das Repositorium und zum Ermöglichen der Bestimmung einer zumindest teilweise funktionell gleichwertigen zweiten Softwaredarstellung basierend auf dem Verweis umfasst, wobei die zweite Softwaredarstellung vom zweiten Netz aus zugänglich ist.
  8. Softwarekomponente (122) zum Einsatz in einem Informationsverarbeitungssystem (100), wobei – das System ein erstes Netz (104) mit einer ersten Softwarearchitektur und ein zweites Heimnetz (102) mit einer zweiten, von der ersten Softwarearchitektur verschiedenen Softwarearchitektur umfasst, – das erste Netz einen Suchdienst (114) umfasst, der es ermöglicht, eine erste Softwaredarstellung (116, 118, 120) einer ersten Einrichtung oder eines ersten Dienstes in dem ersten Netz zu erkennen, – die Komponente erste Codemittel zum Ausführen eines Verweisgenerators (124) zum Erstellen eines Verweises auf die erste Softwaredarstellung durch Interaktion mit dem Suchdienst umfasst, – die Komponente zweite Codemittel zum Ausführen eines Repositoriums (126) zum Speichern des Verweises umfasst und – die Komponente dritte Codemittel zum Ausführen eines Softwareelementgenerators (128) zum Zugreifen auf das Repositorium und zum Ermöglichen der Bestimmung einer zumindest teilweise funktionell gleichwertigen zweiten Softwaredarstellung basierend auf dem Verweis umfasst, wobei die zweite Softwaredarstellung vom zweiten Netz aus zugänglich ist.
DE60036072T 1999-06-25 2000-06-21 Verfahren zur brückenverbindung von mehreren heimnetzsoftwarearchitekturen Expired - Lifetime DE60036072T2 (de)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
US340272 1999-06-25
US09/340,272 US6618764B1 (en) 1999-06-25 1999-06-25 Method for enabling interaction between two home networks of different software architectures
PCT/EP2000/005717 WO2001001632A2 (en) 1999-06-25 2000-06-21 Bridging multiple home network software architectures

Publications (2)

Publication Number Publication Date
DE60036072D1 DE60036072D1 (de) 2007-10-04
DE60036072T2 true DE60036072T2 (de) 2008-05-21

Family

ID=23332636

Family Applications (1)

Application Number Title Priority Date Filing Date
DE60036072T Expired - Lifetime DE60036072T2 (de) 1999-06-25 2000-06-21 Verfahren zur brückenverbindung von mehreren heimnetzsoftwarearchitekturen

Country Status (8)

Country Link
US (1) US6618764B1 (de)
EP (1) EP1131919B1 (de)
JP (1) JP4721600B2 (de)
KR (1) KR20010073003A (de)
CN (1) CN1188986C (de)
BR (1) BR0006861A (de)
DE (1) DE60036072T2 (de)
WO (1) WO2001001632A2 (de)

Families Citing this family (144)

* 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
CN1218241C (zh) * 1998-05-07 2005-09-07 三星电子株式会社 网络中通用存取命令和控制的方法和设备
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
US7904187B2 (en) 1999-02-01 2011-03-08 Hoffberg Steven M Internet appliance system and method
FI107206B (fi) * 1999-03-16 2001-06-15 Nokia Networks Oy Menetelmä ja laite rajapinnan määrittämiseksi ja tietoliikennejärjestelmä
US6769021B1 (en) * 1999-09-15 2004-07-27 Adaptec, Inc. Methods for partitioning end nodes in a network fabric
US7110973B1 (en) * 1999-09-29 2006-09-19 Charles Schwab & Co., Inc. Method of processing customer transactions
US7444661B1 (en) * 1999-09-30 2008-10-28 Gateway Inc. Electronic program guide utilizing multiple tuning sources
DE59911450D1 (de) * 1999-11-01 2005-02-17 Abb Research Ltd Integration eines Feldleitgerätes in ein Anlagenleitsystem
CN1128531C (zh) * 1999-12-30 2003-11-19 国际商业机器公司 可接插式服务发送平台
US7035270B2 (en) 1999-12-30 2006-04-25 General Instrument Corporation Home networking gateway
KR100317303B1 (ko) * 2000-01-10 2001-12-22 구자홍 방송 프로그램 녹화 및 재생시 a/v와 데이터간 동기화장치
US20010047431A1 (en) * 2000-02-09 2001-11-29 Eytchison Edward B. HAVi-VHN bridge solution
US7050453B1 (en) 2000-02-17 2006-05-23 Apple Computer, Inc. Method and apparatus for ensuring compatibility on a high performance serial bus
KR20010092525A (ko) * 2000-03-22 2001-10-26 윤종용 인터넷 프로토콜 근간 네트워크 기기로서 비 인터넷프로토콜 근간 네트워크 기기의 제어를 이루는 인터넷프로토콜 인터페이스 장치 및 그 방법
US6804232B1 (en) 2000-03-27 2004-10-12 Bbnt Solutions Llc Personal area network with automatic attachment and detachment
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
US7603301B1 (en) * 2000-04-26 2009-10-13 Accenture Llp Verification and printing of a tax return in a network-based tax architecture
US7234103B1 (en) 2000-04-26 2007-06-19 Accenture Llp Network-based tax framework database
US7577834B1 (en) * 2000-05-09 2009-08-18 Sun Microsystems, Inc. Message authentication using message gates in a distributed computing environment
US20020056113A1 (en) * 2000-07-04 2002-05-09 Ulan Co., Ltd. Home network connection system
EP1293081A2 (de) * 2000-07-25 2003-03-19 Koninklijke Philips Electronics N.V. Gateway für hausnetzwerke
US10390074B2 (en) 2000-08-08 2019-08-20 The Directv Group, Inc. One click web records
EP1308045B1 (de) * 2000-08-08 2013-10-30 The DirecTV Group, Inc. Verfahren und system zur fernsteuerung von fernsehwiedergabe
US9171851B2 (en) * 2000-08-08 2015-10-27 The Directv Group, Inc. One click web records
CN101087412B (zh) * 2000-09-27 2010-07-07 汤姆森特许公司 用于优化多媒体设备的音频和视频输出状态的方法
US7206853B2 (en) * 2000-10-23 2007-04-17 Sony Corporation content abstraction layer for use in home network applications
AU2002225810A1 (en) * 2000-11-02 2002-05-15 Sony Electronics Inc. Content and application download based on a home network system configuration profile
GB0026981D0 (en) 2000-11-04 2000-12-20 Koninkl Philips Electronics Nv Bridging system for interoperation of remote groups of devices
US20040205734A1 (en) * 2000-11-30 2004-10-14 Krishnamurthy Srinivasan Dynamic notification of non java services using jini (TM)
US7343427B2 (en) * 2000-12-13 2008-03-11 Sony Corporation Method and an apparatus for the integration of IP devices into a HAVi network
US20020083143A1 (en) * 2000-12-13 2002-06-27 Philips Electronics North America Corporation UPnP architecture for heterogeneous networks of slave devices
US20020087964A1 (en) * 2000-12-28 2002-07-04 Gateway, Inc. System and method for enhanced HAVi based device implementation
US7389341B2 (en) * 2001-01-31 2008-06-17 Accenture Llp Remotely monitoring a data processing system via a communications network
US7174363B1 (en) * 2001-02-22 2007-02-06 Charles Schwab & Co., Inc. Distributed computing system architecture
KR20020094031A (ko) * 2001-03-09 2002-12-16 코닌클리케 필립스 일렉트로닉스 엔.브이. 새로운 컴포넌트들을 검증하는 서버를 가진 시스템
EP1241827B1 (de) * 2001-03-15 2009-12-23 Sony Deutschland GmbH Steuerung von Heimnetzwerkgeräten
US20020147797A1 (en) * 2001-04-06 2002-10-10 Paul Stephen D. Discovery and configuration of network attached storage devices
CA2445842C (en) * 2001-04-26 2008-08-05 General Instrument Corporation Home networking gateway
US20030061333A1 (en) * 2001-05-04 2003-03-27 Stephen Dean System and method for universal networked device management
US20020165975A1 (en) * 2001-05-07 2002-11-07 Michael Abbott Dynamic mapping of communication protocols
US20020174198A1 (en) * 2001-05-16 2002-11-21 Imation Corp. Management of networked devices
US20030005130A1 (en) * 2001-06-29 2003-01-02 Cheng Doreen Yining Audio-video management in UPnP
KR100413684B1 (ko) 2001-07-05 2003-12-31 삼성전자주식회사 서로 다른 미들웨어를 가진 디바이스들간 통신을 가능하게하는 게이트웨이, 홈네트웍시스템 및 데이터 중계방법
EP1286501A1 (de) * 2001-08-22 2003-02-26 Thomson Licensing S.A. Verfahren für die Verbindung von einem UPnP-Netz und einem HAVi-Netz mittels Brücken
US7925737B2 (en) * 2001-09-17 2011-04-12 Hewlett-Packard Development Company, L.P. System and method for dynamic configuration of network resources
JP2005504482A (ja) * 2001-09-21 2005-02-10 コーニンクレッカ フィリップス エレクトロニクス エヌ ヴィ 固有の制御モジュールが無い場合の固有性の低いモジュールの使用
AU2002358031A1 (en) * 2001-11-23 2003-06-10 Thomson Licensing Sa METHOD FOR CONNECTING A HAVi CLUSTER AND AN IP CLUSTER USING A BRIDGE DEVICE, AND ASSOCIATED BRIDGE DEVICE
KR100406857B1 (ko) * 2002-01-09 2003-11-21 엘지전자 주식회사 홈네트워크에서의 구성 매니저 결정방법
CN100486129C (zh) * 2002-02-05 2009-05-06 纬创资通股份有限公司 用于无线装置访问和管理的动态机器组合方法
US8412581B1 (en) 2002-02-21 2013-04-02 Jda Software Group, Inc. Facilitating business transactions between trading networks
KR100442256B1 (ko) * 2002-02-28 2004-07-30 엘지전자 주식회사 홈 네트워크 시스템의 규격 호환장치 및 방법
US6895408B1 (en) * 2002-03-19 2005-05-17 Oracle International Corporation Method and apparatus to facilitate interaction management between loosely coupled applications
EP1493250A2 (de) * 2002-04-09 2005-01-05 Thomson Licensing S.A. Verfahren zur kommunikation in einem mehrgruppennetzwerk, vorrichtung zur verbindung zu einem mehrgruppennetzwerk, und brücke zur verbindung von knotengruppen
EP1355136B1 (de) * 2002-04-18 2006-03-08 Thomson Licensing Verfahren zur Erzeugung einer graphischen Benutzerschnittstelle auf einem HAVi Gerät für die Steuerung eines nicht HAVi Gerätes
EP1355485A1 (de) * 2002-04-18 2003-10-22 Deutsche Thomson-Brandt Gmbh Verfahren für die Herstellung einer Benutzerschnittstelle auf ein HAVi-Gerät zur Kontrolle eines nicht-HAVi-Gerätes
US7861273B2 (en) * 2002-04-26 2010-12-28 Microsoft Corporation TV control resource management
KR100440583B1 (ko) * 2002-05-16 2004-07-19 한국전자통신연구원 외부 인터넷에 의한 댁내망의 UPnP장치 관리제어 장치및 방법
US7933945B2 (en) * 2002-06-27 2011-04-26 Openpeak Inc. Method, system, and computer program product for managing controlled residential or non-residential environments
US8116889B2 (en) 2002-06-27 2012-02-14 Openpeak Inc. Method, system, and computer program product for managing controlled residential or non-residential environments
EP1396962A1 (de) * 2002-08-05 2004-03-10 Sony International (Europe) GmbH Busdienstschnittstelle
JP4305092B2 (ja) * 2002-08-14 2009-07-29 ソニー株式会社 情報処理装置、データ通信システム、および方法、並びにコンピュータ・プログラム
US20040039468A1 (en) * 2002-08-23 2004-02-26 Vladimir Zahorack Method, system and apparatus for an industrial framework based on integrated applications via adapters
KR100909518B1 (ko) * 2002-10-19 2009-07-27 엘지전자 주식회사 아이에이브이 플랫폼을 이용한 에프에이브이 디바이스
US8356067B2 (en) * 2002-10-24 2013-01-15 Intel Corporation Servicing device aggregates
KR20040039043A (ko) * 2002-10-30 2004-05-10 엘지전자 주식회사 UPnP 네트워크 시스템의 제어 메시지 전송 방법
KR100455123B1 (ko) * 2002-10-30 2004-11-06 엘지전자 주식회사 UPnP 기반의 네트워크 시스템의 제어 메시지멀티캐스트 방법 및 장치
US20040205240A1 (en) * 2002-11-21 2004-10-14 International Business Machines Corporation Method, system, and computer program product for providing a four-tier corba architecture
FR2848051B1 (fr) * 2002-12-03 2005-02-25 Canon Res Ct France Sa PASSERELLE ET PROCEDE POUR L'INTERCONNEXION DE DEUX RESEAUX, NOTAMMENT UN RESEAU HAVI ET UN RESEAU UPnP
US20040133896A1 (en) * 2002-12-20 2004-07-08 Sony Corporation And Sony Electronics, Inc. Network device application interface
KR100493883B1 (ko) 2003-01-02 2005-06-10 삼성전자주식회사 애플리케이션 관리 시스템 및 방법
US7987489B2 (en) * 2003-01-07 2011-07-26 Openpeak Inc. Legacy device bridge for residential or non-residential networks
DE10302477A1 (de) * 2003-01-23 2005-02-24 Deutsche Thomson-Brandt Gmbh Verfahren zur Verfügbarmachung eines Eingabeparameters einer Netzwerkstation eines Netzwerks eines ersten Typs in einem Netzwerk eines zweiten Typs sowie Verbindungseinheit zur Verbindung der Netzwerke des ersten und zweiten Typs
HK1052830A2 (en) * 2003-02-26 2003-09-05 Intexact Technologies Ltd An integrated programmable system for controlling the operation of electrical and/or electronic appliances of a premises
KR100513277B1 (ko) * 2003-04-16 2005-09-09 삼성전자주식회사 개별적으로 존재하는 네트워크를 연결하는 장치 및 방법
WO2004095293A1 (ja) * 2003-04-24 2004-11-04 Mitsubishi Denki Kabushiki Kaisha 映像機器、映像モジュールユニット及び映像機器操作方法
US7660985B2 (en) * 2003-04-30 2010-02-09 At&T Corp. Program security through stack segregation
US7197580B2 (en) * 2003-05-29 2007-03-27 Microsoft Corporation Computer system and method for supporting network-enabled devices
AU2003246146A1 (en) * 2003-05-30 2005-01-21 Lg Electronics, Inc. Home network system and its configuration system
AU2003246151A1 (en) * 2003-05-30 2005-01-21 Lg Electronics, Inc. Home network system
AU2003246141A1 (en) * 2003-05-30 2005-01-21 Lg Electronics, Inc. Home network system
KR100605216B1 (ko) * 2003-05-30 2006-07-31 엘지전자 주식회사 네트워크 디바이스
KR100596755B1 (ko) 2003-05-30 2006-07-04 엘지전자 주식회사 홈 네트워크 시스템
KR100638017B1 (ko) * 2003-05-30 2006-10-23 엘지전자 주식회사 네트워크 디바이스
KR100605218B1 (ko) * 2003-05-30 2006-07-31 엘지전자 주식회사 홈 네트워크 시스템
WO2004107662A1 (en) * 2003-05-30 2004-12-09 Lg Electronics, Inc. Home network system
KR20050014631A (ko) * 2003-05-30 2005-02-07 엘지전자 주식회사 홈 네트워크 시스템
FR2856874B1 (fr) * 2003-06-24 2005-09-23 Canon Europa Nv Procede et systeme de reservation d'au moins une ressource d'un appel controlable par un controleur au sein d'un reseau, programme d'ordinateur correspondant
US7383340B2 (en) * 2003-06-30 2008-06-03 Intel Corporation System and method for programmatically changing the network location of a network component
WO2005013136A1 (ja) * 2003-08-04 2005-02-10 Mitsubishi Denki Kabushiki Kaisha 映像情報装置及びモジュールユニット
US7549149B2 (en) * 2003-08-21 2009-06-16 International Business Machines Corporation Automatic software distribution and installation in a multi-tiered computer network
JP3842768B2 (ja) * 2003-08-26 2006-11-08 株式会社東芝 サービス検索装置およびサービス検索方法
US7755506B1 (en) 2003-09-03 2010-07-13 Legrand Home Systems, Inc. Automation and theater control system
FI20031340A0 (fi) * 2003-09-18 2003-09-18 Nokia Corp Menetelmä ja järjestelmä yhteyksien seurantaan ja seurantaprotokolla
KR100949020B1 (ko) * 2003-09-22 2010-03-23 엘지전자 주식회사 멀티캐스트 스트리밍 서비스 방법 및 시스템
KR20050032313A (ko) * 2003-10-01 2005-04-07 엘지전자 주식회사 홈 네트워크 시스템
DE10360416A1 (de) * 2003-12-19 2005-07-14 Deutsche Thomson-Brandt Gmbh Verfahren zur automatischen Datenverbindungseinrichtung zwischen Netzwerkteilnehmerstationen in einem Netzwerk verteilter Stationen sowie Netzwerkteilnehmerstation als Benutzeroberflächengerät bei der Durchführung des Verfahrens
US7486695B1 (en) * 2003-12-22 2009-02-03 Sun Microsystems, Inc. Method and apparatus for data communication tunneling channels
US7656822B1 (en) 2003-12-22 2010-02-02 Sun Microsystems, Inc. Method and apparatus for decentralized device and service description and discovery
US9009290B2 (en) 2004-01-22 2015-04-14 Sony Corporation Methods and apparatuses for discovery and notification of services
US7467384B2 (en) * 2004-02-20 2008-12-16 Microsoft Corporation Uniform resource discovery with multiple computers
US20050192927A1 (en) * 2004-02-20 2005-09-01 Microsoft Corporation Uniform resource discovery and activation
US8549541B2 (en) * 2004-03-26 2013-10-01 Intellectual Ventures Ii Llc Bridging local device communications across the wide area
EP1643713A1 (de) * 2004-10-04 2006-04-05 Hewlett-Packard Development Company, L.P. Verteiltes Rechnersystem
KR20060053251A (ko) * 2004-10-13 2006-05-19 조배수 중계기를 이용한 호스트와 클라이언트 간의 플러그 엔플레이 시스템 및 방법
WO2006080762A1 (en) * 2004-10-13 2006-08-03 Bea Su Jo System and method for plug and play between host and client
WO2006080763A1 (en) * 2004-10-13 2006-08-03 Bea Su Jo System and method for plug and play between host and client by using repeater
US20060112192A1 (en) * 2004-11-24 2006-05-25 Motorola, Inc. Method and apparatus to facilitate universal plug and play interaction between different local networks
US20060149761A1 (en) * 2004-12-09 2006-07-06 Lg Electronics Inc. Structure of objects stored in a media server and improving accessibility to the structure
US8205013B2 (en) * 2005-05-02 2012-06-19 Samsung Electronics Co., Ltd. Method and system for aggregating the control of middleware control points
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
US7778262B2 (en) 2005-09-07 2010-08-17 Vantage Controls, Inc. Radio frequency multiple protocol bridge
KR100736090B1 (ko) * 2005-09-28 2007-07-06 삼성전자주식회사 홈 네트워크에서 제 3의 장치의 이벤트를 처리하는 방법 및장치
US7788409B2 (en) * 2005-10-28 2010-08-31 Sony Corporation System and method for achieving interoperability in home network with IEEE 1394 and UPnP devices
US8270293B2 (en) * 2005-12-02 2012-09-18 Panasonic Corporation Systems and methods for efficient electronic communication in a distributed routing environment
US7539517B2 (en) * 2006-01-23 2009-05-26 Sony Corporation Method of selecting one of dual antennas
US7561903B2 (en) * 2006-01-23 2009-07-14 Sony Corporation Wireless headphones with dual antennas
US8028283B2 (en) * 2006-03-20 2011-09-27 Samsung Electronics Co., Ltd. Method and system for automated invocation of device functionalities in a network
US20070279389A1 (en) * 2006-05-31 2007-12-06 Samsung Electronics Co., Ltd. Method of task-oriented universal remote control user interface
US20090055760A1 (en) * 2006-08-17 2009-02-26 Vantage Controls, Inc. System and method for creating a user interface
CN101584192B (zh) * 2006-11-27 2013-10-30 艾利森电话股份有限公司 节点注册方法
JP5028979B2 (ja) * 2006-12-01 2012-09-19 富士通株式会社 機器管理システム、機器管理方法及びエージェント
US8200786B2 (en) * 2006-12-29 2012-06-12 Sap Ag Methods and systems for distributing software
US20080163200A1 (en) * 2006-12-29 2008-07-03 Volker Schulz Methods and systems for distributing software
US8122101B2 (en) * 2006-12-29 2012-02-21 Sap Ag Methods and systems for distributing software
US8200787B2 (en) * 2006-12-29 2012-06-12 Sap Ag Methods and systems for distributing software
US8103363B2 (en) * 2007-01-31 2012-01-24 Hewlett-Packard Development Company, L.P. Device control system
CA2681734A1 (en) 2007-03-23 2008-10-02 Allegiance Corporation Fluid collection and disposal system having interchangeable collection and other features and methods relating thereto
US9889239B2 (en) 2007-03-23 2018-02-13 Allegiance Corporation Fluid collection and disposal system and related methods
TWI385966B (zh) * 2008-09-25 2013-02-11 Mitac Int Corp 多媒體系統、媒體中央控制器及其管理媒體檔案的方法
US20100083113A1 (en) * 2008-09-26 2010-04-01 Thomson Licensing Inc. Architecture For Optimizing Audio and Video Output States for Multimedia Devices
EP2372960B1 (de) * 2008-12-12 2014-09-10 Panasonic Corporation Kommunikationsnetzsystem
US8135434B2 (en) * 2009-03-31 2012-03-13 International Business Machines Corporation Integrating device functionality into a telecommunications service composition
WO2011008961A1 (en) 2009-07-15 2011-01-20 Allegiance Corporation Fluid collection and disposal system and related methods
US9128986B2 (en) 2011-06-29 2015-09-08 Infosys Limited Method and system for managing a database having a plurality of tables
US8595269B2 (en) 2011-09-02 2013-11-26 Infosys Limited Managing classification hierarchies in master data management environments
EP2847962B1 (de) * 2012-05-10 2019-11-20 Telefonaktiebolaget LM Ericsson (publ) System, verfahren und computerprogrammprodukt zur protokollanpassung
JP6224105B2 (ja) 2013-07-22 2017-11-01 パナソニック インテレクチュアル プロパティ コーポレーション オブ アメリカPanasonic Intellectual Property Corporation of America 情報管理方法
CN106702677B (zh) * 2015-11-17 2019-03-19 泰科电子(上海)有限公司 家电总线控制系统
US11356315B2 (en) 2018-03-28 2022-06-07 Intel Corporation Methods and apparatus to dynamically control devices based on distributed data
EP3644206A1 (de) 2018-10-22 2020-04-29 Koninklijke Philips N.V. Container-builder für individualisierte netzwerkdienste
US11196837B2 (en) 2019-03-29 2021-12-07 Intel Corporation Technologies for multi-tier prefetching in a context-aware edge gateway
US11388054B2 (en) 2019-04-30 2022-07-12 Intel Corporation Modular I/O configurations for edge computing using disaggregated chiplets
US11405257B2 (en) * 2020-05-18 2022-08-02 SCADAfence Ltd. System for centralized monitoring and control of IoT devices

Family Cites Families (12)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5329619A (en) 1992-10-30 1994-07-12 Software Ag Cooperative processing interface and communication broker for heterogeneous computing environments
GB9406477D0 (en) * 1994-03-31 1994-05-25 D2B Systems Co Ltd Interconnection of local communication bus systems
US5682532A (en) * 1994-05-02 1997-10-28 Microsoft Corporation System and method having programmable containers with functionality for managing objects
US6523696B1 (en) * 1996-10-15 2003-02-25 Kabushiki Kaisha Toshiba Communication control device for realizing uniform service providing environment
US5959536A (en) * 1996-10-15 1999-09-28 Philips Electronics North America Corporation Task-driven distributed multimedia consumer system
JPH10178438A (ja) * 1996-12-18 1998-06-30 Sony Corp データ通信システム、データ通信装置および方法
US6032202A (en) * 1998-01-06 2000-02-29 Sony Corporation Of Japan Home audio/video network with two level device control
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
US6038625A (en) * 1998-01-06 2000-03-14 Sony Corporation Of Japan Method and system for providing a device identification mechanism within a consumer audio/video network
US6445690B2 (en) * 1998-06-08 2002-09-03 Koninklijke Philips Electronics N.V. Wireless coupling of incompatible nodes via a virtual network
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
EP1058422A1 (de) * 1999-06-02 2000-12-06 THOMSON multimedia Verfahren für die Verbindung von einem HAVi-Teilnetz und einem UPnP-Teilnetz und UPnP-einrichtung für das Einführen der besagten Methoden

Also Published As

Publication number Publication date
WO2001001632A2 (en) 2001-01-04
DE60036072D1 (de) 2007-10-04
EP1131919A2 (de) 2001-09-12
BR0006861A (pt) 2001-07-10
CN1327666A (zh) 2001-12-19
CN1188986C (zh) 2005-02-09
EP1131919B1 (de) 2007-08-22
KR20010073003A (ko) 2001-07-31
JP2003503897A (ja) 2003-01-28
JP4721600B2 (ja) 2011-07-13
US6618764B1 (en) 2003-09-09
WO2001001632A3 (en) 2001-07-05

Similar Documents

Publication Publication Date Title
DE60036072T2 (de) Verfahren zur brückenverbindung von mehreren heimnetzsoftwarearchitekturen
DE69836101T2 (de) Ein audio-video-gerät
DE69829219T2 (de) Verfahren und system in verbindung mit einem audio-video-netz
DE69930534T2 (de) Szenarioandeutende Anrufe für Steuerung von Softwareobjekten mittels Eigenschaftsverbindungen
DE60019750T2 (de) Allgemeines api zur gerätefernsteuerung
DE69828696T2 (de) Erzeugung eines programmführers für heimnetzwerke
DE60303903T2 (de) Verfahren zur Erzeugung einer graphischen Benutzerschnittstelle auf einem HAVi Gerät für die Steuerung eines nicht HAVi Gerätes
DE60109029T2 (de) Zugriff auf ein in-haus netzwerk über das internet
DE69829218T2 (de) Ein audio-video-netzwerk mit gerätsteuerung
DE69829221T2 (de) Ein audio-video-netzwerk
DE69926368T2 (de) Verfahren und vorrichtung für universellen zugriffsbefehl und kontrollinformation in einem netzwerk
DE69921342T2 (de) Verfahren und system zur elektronischen kommunikation
DE60029321T2 (de) Verfahren und vorrichtung zur fernbedienung eines hausnetzwerks von einem externen kommunikationsnetz
DE60308929T2 (de) Vorrichtung und Verfahren, um Informationen über Heimnetzwerkgeräte über das Internet bereitzustellen
DE602004011517T2 (de) Einbetten einer upnp av mediaserverobjektidentifikation in einem uri
DE60308520T2 (de) Modul zur integration in einem heimnetzwerk
US20010032273A1 (en) Architecture of a bridge between a non-IP network and the web
DE60030102T2 (de) Rundsendeentdeckung in einem netz mit einem oder mehreren 1394-bussen
US20060190571A1 (en) Service framework for home network
DE60207243T2 (de) Netzanpassungsgerät zur Steuerung von Audio/Video-Geräten in einem lokalen Netz
DE602004009746T2 (de) Teilen von Diensten in einem Netz
EP1693990B1 (de) Dienstarchitektur eines Heimnetzwerkes
DE60031107T2 (de) Kommunikation zwischen apparaten und steuerung der apparate in einem heimnetzwerk welches mit einem externen netzwerk mit regionaler unterstützung verbunden ist
JP2005512401A (ja) HAViとUPnPのブリッジ
DE102004018980A1 (de) Verfahren zur Steuerung eines Gerätes in einem Netzwerk verteilter Stationen sowie Netzwerkstation

Legal Events

Date Code Title Description
8364 No opposition during term of opposition