DE10226611A1

DE10226611A1 - Eingabevorrichtungssteuerung mit mehreren Instanzen

Info

Publication number: DE10226611A1
Application number: DE10226611A
Authority: DE
Inventors: Aaron Standridge; Tim Dieckman
Original assignee: Logitech Europe SA
Current assignee: Logitech Europe SA
Priority date: 2001-06-15
Filing date: 2002-06-14
Publication date: 2003-02-06
Also published as: CN1405680A; CN1244863C; US20020019888A1; US20060064701A1; US6918118B2

Abstract

Die vorliegende Erfindung kombiniert die Merkmale eines ausführbaren Prozesses mit dem Bedarf dafür, daß mehrere Anwendungsprogramme eine einzelne Eingabevorrichtung gemeinsam benutzen. Die vorliegende Erfindung sieht ein ausführbares Programm vor, das als Prozeß implementiert wird, der ermöglicht, daß mehrere Anwendungen mit einer einzelnen Eingabevorrichtung in Dialogverkehr treten. Dies wird durch Laden des ausführbaren Eingabevorrichtungs-Steuerprogramms als Prozeß erreicht. Das ausführbare Programm ist ein Server, was somit ermöglicht, daß mehrere Anwendungsprogramme mit derselben Eingabevorrichtung über eine Schnittstelle koppeln. Das ausführbare Programm der Eingabevorrichtungssteuerung für mehrere Instanzen (MIIDC) reagiert auf jede Anwendungsprogrammanforderung, als ob die Eingabevorrichtung für das aufrufende Anwendungsprogramm offen wäre. Jedem Anwendungsprogramm wird somit ermöglicht, mit der Eingabevorrichtungsinstanz in Dialogverkehr zu treten, ohne die Operation anderer Anwendungsprogramme, die mit der Eingabevorrichtung im Dialogverkehr stehen, zu unterbrechen. Die Eingabevorrichtungsinstanz verfolgt alle Verbindungen mit dieser und multiplexiert und löst sich widersprechende Aufforderungen.

Description

RÜCKVERWEISUNGEN AUF VERWANDTE ANMELDUNGEN

Diese Anmeldung ist eine Teilfortführung ("CIP") der Anmeldung Nr. 09/438 012, eingereicht am 10. November 1999, MULTI INSTANCE INPUT DEVICE CONTROL.

HINTERGRUND DER ERFINDUNG

Die vorliegende Erfindung betrifft Medienquellen-Eingabevorrichtungen wie z. B. Mikrophone und Videokameras und insbesondere die Kopplung von Medienquellen- Eingabevorrichtungen mit Anwendungsprogrammen über eine Schnittstelle.
Wenn ein Anwendungsprogramm mit einer Medienquelle verbindet, werden üblicherweise alle anderen Anwendungsprogramme an der Verwendung dieser Medienquelle gehindert. Im Zusammenhang mit einem üblichen Personalcomputer, wenn ein Anwendungsprogramm zum Informationsaustausch mit einer Medienquelle aufruft, ruft das Anwendungsprogramm die Treiberdateien oder die Dateien der dynamischen Verknüpfungsbibliothek (DLL, Dynamic Link Library, oder *.dll) auf. Typischerweise stellt eine DLL eine oder mehrere spezielle Funktionen bereit und ein Programm greift durch Erzeugen einer Verknüpfung mit der DLL auf die Funktion zu. DLLs können auch Daten enthalten. Einige DLLs sind mit dem Betriebssystem (wie z. B. dem Windows-Betriebssystem) versehen und sind für eine beliebige Betriebssystemanwendung verfügbar. Andere DLLs sind für eine spezielle Anwendung geschrieben und werden mit dem Anwendungsprogramm (wie z. B. einem Medienquellensteuerungs-Anwendungsprogramm) geladen. Wenn ein Medienquellensteuerungs-Anwendungsprogramm zur Verbindung mit einer Medienquelle aufruft, prüft der Treiber an diesem Punkt, um sicher zu gehen, daß keine andere Anwendung die spezielle Kameratreiberdatei (*.dll) geöffnet hat, und wenn keine andere dies getan hat, öffnet der Treiber die spezielle Treiberdatei. Wenn dies ausgeführt wurde, existiert nun eine einzelne verkettete Verbindung zwischen der Medienquelle (z. B. Videokamera) und dem Anwendungsprogramm über die geöffnete Treiberdatei der Medienquelle (z. B. Videokamera), wie in Fig. 1 zu sehen ist.
Fig. 1 zeigt ein Anwendungsprogramm, das mit einer Medienquelle verbindet, die eine Videokamera ist. Wie in Fig. 1 dargestellt, wird die Treiberdatei 14 durch den Treiber 12 geöffnet, der durch das aufrufende Anwendungsprogramm 10 aufgerufen wird, und wird in den Speicher des aufrufenden Anwendungsprogramms geladen. Da die Videokamera-Treiberdatei 14 durch das Anwendungsprogramm 10 geöffnet wurde, wird die nächste Anwendung, die versucht, die Videokamera aufzurufen, daran gehindert. Die mit Konflikten bei der gemeinsamen Nutzung einer Medienquelle zwischen mehreren Anwendungsprogrammen verbundenen Probleme sind als Kontinggenzprobleme bekannt. Es bestehen Kontingenzprobleme, da typische Eingabevorrichtungstreiber nur gestatten, daß eine Anwendung die Eingabevorrichtungsdaten zu irgendeinem gegebenen Zeitpunkt verwendet. Dies liegt daran, daß die Videokamera-Treiberdatei in den Speicher des ersten Anwendungsprogramms geladen wurde und nicht für den Zugriff durch ein weiteres aufrufendes Programm verfügbar ist. Daher muß jedes Anwendungsprogramm, das potentiell eine Videokamera aufruft, die Anwesenheit eines anderen Anwendungsprogramms, das möglicherweise die Kamera bereits verwendet, berücksichtigen. Folglich sind solche Anwendungsprogramme durch die Notwendigkeit belastet, zuerst zu prüfen, um festzustellen, ob ein anderes erstes Anwendungsprogramm ausgeführt wurde, das mit der Videokamera verbunden hat, und wenn dies der Fall ist, muß das zweite aufrufende Programm Routinen aufweisen, die ermöglichen, daß es über die gemeinsame Benutzung der Kamera verhandelt. Eine solche gemeinsame Benutzung ist jedoch eine mit einzelner Instanz, was bedeutet, daß die Verbindung zwischen der Kamera und dem ersten Anwendungsprogramm unterbrochen werden müßte (d. h. das erste Anwendungsprogramm müßte beendet werden oder die Videokamera abgeschaltet werden), bevor die Verbindung zwischen der Kamera und dem zweiten Anwendungsprogramm hergestellt werden könnte. Berechtigung, Vorrang und andere Sicherheitsaspekte sowie eine zweckmäßige Fehlerbehandlung müssen ebenfalls durch den Informationsaustausch zwischen den zwei konkurrierenden Anwendungsprogrammen gelöst werden. Derzeit versucht ein Anwendungsprogramm nicht einmal, irgendeines dieser Probleme zu lösen, und wenn eine Verbindung zwischen einem aufrufenden Programm und einer Kamera nicht hergestellt werden kann, werden daher die unerwarteten Anwendungsprogrammfehler durch das Betriebssystem gelöst, das ziemlich unbeholfene und unerklärliche Fehlermeldungen ausgibt, was den Endanwender nur schließen läßt, daß keine korrekte Verbindung hergestellt werden konnte. Bestenfalls empfängt das zweite aufrufende Anwendungsprogramm eine Meldung, daß die aufgerufene Vorrichtung derzeit verwendet wird und nicht zur Verfügung steht.
Anwendungsprogramme haben in der Größe, Flexibilität und Brauchbarkeit weiter zugenommen, und der Trend bestand darin, sich von großen monolithischen Anwendungsprogrammen weg zu Programmen zu bewegen, die aus vielen kleineren Unterprogrammen bestehen. Diese Blockbaumethode stellt viele Vorteile bereit, wie z. B. eine leichte spätere Modifikation und Konfigurierbarkeit. Überdies haben Betriebssystemlieferanten wie z. B. Microsoft auch eine solche modulare Methode übernommen und bieten daher viele Standard-Unterprogramme oder Objekte an, die viele Dienstfunktionen verarbeiten, wie z. B. die Warteschlangenbildung von Dateien für einen Drucker und das Laden und Abarbeiten von Dateien eines Druckertreibers (z. B. DLL) zu Druckdateien. Die Dateien des Treibers (z. B. DLL) selbst sind Objekte oder Unterprogramme. Bei einer Bemühung, eine Kompatibilität zwischen Objekten und kleineren Unterprogrammen, die in verschiedenen problemorientierten Programmiersprachen geschrieben sind, zu ermöglichen, haben Betriebssystemlieferanten ferner Modelle für ausführbare Programme entwickelt, die auf der binären Ebene miteinander kompatibel sein können. Ein solches Modell für einen Binärcode, das von der Microsoft Corporation entwickelt wurde, ist das Komponentenobjektmodell (CCM, Component Object Model). Das COM ermöglicht, daß Programmierer Objekte entwickeln, auf die von einer beliebigen COM entsprechenden Anwendung zugegriffen werden kann. Obwohl durch Übergehen von großen monolithischen Anwendungsprogrammen zu Sätzen von kleineren Unterprogrammen und Objekten viele Vorteile realisiert werden können, müssen diese Vorteile gegen die Belastungen abgewogen werden, die durch den Bedarf für die zusätzlichen Routinen auferlegt werder, welche unter diesen Unterprogrammen und Objekten einen Informationsaustausch zwischen Prozessen ermöglichen.
Außer der Zunahme in der Komplexität und Brauchbarkeit sind Anwendungsprogramme aus mehreren Einheiten von Standorten eines einzelnen Hauptrechners zu heterogenen Netzwerkumgebungen mit mehreren Hauptrechnern gewandert. Folglich ist es nun nicht einmalig, daß ein einzelnes Anwendungsprogramm aus vielen verschiedenen Routinen besteht, die jeweils in verschiedenen problemorientierten Programmiersprachen geschrieben sind und sich jeweils auf einem separaten Computer befinden, wobei alle diese Computer über ein Netzwerk miteinander verbunden sind. Bei solchen Implementierungen können die Forderungen nach einem effizienten Informationsaustausch in den und zwischen den Netzwerken und zwischen den Prozessen ein Eigenleben übernehmen, was die Hauptfunktion des Programmierers des Schreibens eines Anwendungsprogramms beeinträchtigt. Der Programmierer muß auch die von der Verteilung von Anwendungsprogrammen über ein Netzwerk gestellten Informationsaustauschprobleme behandeln. Wiederum haben Betriebssystemlieferanten diese Herausforderung und potentielle Beeinträchtigung realisiert und sind dies auf verschiedene Weisen angegangen. Microsoft hat die COM- Funktionalität beispielsweise durch Entwickeln des Modells mit verteilten Komponentenobjekten (DCOM, Distributed Component Object Model) erweitert. DCOM ist eine Erweiterung von COM, um über ein Netzwerk verteilte Objekte zu unterstützen. Abgesehen davon, daß es eine Erweiterung von COM ist, stellt DCOM eine Schnittstelle bereit, die die Details von Netzwerkkommunikationsprotokollen verarbeitet, was ermöglicht, daß sich Anwendungsprogrammierer auf ihre Hauptfunktion der Entwicklung von anwendungsspezifischen Programmen konzentrieren. DCOM ist dazu ausgelegt, sich den Unternehmensanforderungen für eine Architektur mit verteilten Komponenten zuzuwenden. Ein Geschäft kann beispielsweise eine Kundenbestellungseingabe-Anwendung aufbauen und einsetzen wollen, die mehrere verschiedene Funktionalitätsbereiche beinhaltet, wie z. B. Steuerberechnung, Kundenkreditüberprüfung, Bestandsverwaltung, Garantieaktualisierung und Bestellungseingabe. Unter Verwendung von DCOM kann die Anwendung aus fünf separaten Komponenten aufgebaut werden und auf einem Netzserver mit Zugang über eine Suchmaschine betrieben werden. Jede Komponente kann sich auf einem anderen Computer befinden, der auf eine andere Datenbank zugreift. Der Programmierer kann sich auf die Anwendungsentwicklung konzentrieren und DCOM ist vorhanden, um die Informationsaustauschaspekte zwischen den Prozessen der separaten Komponenten des Anwendungsprogramms zu bearbeiten. Beispielsweise würde DCOM die Integration des Komponenteninformationsaustauschs mit entsprechenden Warteschlangen und die Integration von Komponentenanwendungen auf einem Server mit Internetanwendungen auf HTML-Basis bearbeiten.
Obwohl viele Computersystem-Betriebssystemlieferanten viele normierte Modelle für ausführbare Programme bereitstellen, können selbst solche ausführbaren Programme folglich mit einer Medienquellen-Eingabevorrichtung nur auf einer Basis Eins-zu- Eins über eine Schnittstelle koppeln. Eine normierte Gerätetreiberdatei, die einmal mit einem Anwendungsprogramm verbunden ist, steht nicht mehr zur Verwendung von einem anderen Programm zur Verfügung. Es besteht ein Bedarf zu ermöglichen, daß mehrere Anwendungsprogramme eine einzelne Medienquellen- Eingabevorrichtung gemeinsam benutzen, welche am üblichsten eine Videokamera oder ein Mikrophon ist.

ZUSAMMENFASSUNG DER ERFINDUNG

Die vorliegende Erfindung kombiniert die Merkmale eines ausführbaren Prozesses mit dem Bedarf dafür, daß mehrere Anwendungsprogramme eine einzelne Eingabevorrichtung, wie z. B. eine Videokamera oder ein Mikrophon, gemeinsam benutzen. Eine Eingabevorrichtung, wie z. B. eine Videokamera oder ein Mikrophon, ist ein Peripheriegerät, das als Reaktion auf einen Aufruf von einem Anwendungsprogramm geöffnet wird und offen bleibt. Die vorliegende Erfindung stellt ein ausführbares Programm bereit, das als Prozeß implementiert wird, der ermöglicht, daß mehrere Anwendungen mit einer einzelnen Eingabevorrichtung in Dialogverkehr treten. Dies wird durch Erzeugen einer virtuellen Schnittstelle (einer Instanz) zur physischen Eingabevorrichtung und durch Laden des ausführbaren Programms der Eingabevorrichtungssteuerung in einen Prozeß erreicht. Eine Instanz ist eine tatsächliche Verwendung und die resultierende virtuelle Erzeugung einer in den Speicher geladenen Kopie einer Einheit. Der Prozeß des ausführbaren Programms wirkt als Server, was somit ermöglicht, daß mehrere Anwendungsprogramme mit derselben Eingabevorrichtung über eine Schnittstelle koppeln. Dieses ausführbare Programm, das, wie hierin verwendet, als ausführbares Programm der Eingabevorrichtungssteuerung für mehrere Instanzen (MIIDC, Multi-instance Input Device Control) bezeichnet wird, reagiert auf jede Anwendungsprogrammaufforderung, als ob die Eingabevorrichtung für das aufrufende Anwendungsprogramm offen ist. Jedem Anwendungsprogramm wird somit ermöglicht, mit der Eingabevorrichtungsinstanz in Dialogverkehr zu treten, ohne die Operation anderer Anwendungsprogramme, die mit derselben Eingabevorrichtung in Dialogverkehr stehen, zu unterbrechen. Mit anderen Worten, die MIIDC virtualisiert eine Eingabevorrichtung durch Erzeugen einer Client-Server-Architektur, wobei jedes aufrufende Anwendungsprogramm ein Client ist und wobei die MIIDC der Server ist, der der Treiberdatei für jedes aufrufende Anwendungsprogramm dient.
Die MIIDC und das Verfahren zum Virtualisieren einer Eingabevorrichtung sind auf vielen Rechenplattformen implementierbar, die auf verschiedenen Betriebssystemen laufen. Eine Medienquellen-Eingabevorrichtung, wie z. B. eine Videokamera oder ein Mikrophon, wird üblicherweise mit einem Hauptrechner über eine Schnittstelle gekoppelt. Der Hauptrechner ist am üblichsten ein Personalcomputer wie z. B. der üblicherweise erhältliche PC von Mac-Computers. Da jedoch die Fortschritte in der Technologie die Grenzen zwischen Rechen- und Informationsaustauschvorrichtungen verwischen, ist ein Hauptrechner, wie hierin verwendet, zu einem intelligenten Hauptrechner synonym, und ein intelligenter Hauptrechner, wie hierin verwendet, soll andere Beispiele von irgendeinem Hauptrechner mit einem Prozessor, einem Speicher, einer Einrichtung zur Eingabe und Ausgabe und einer Einrichtung zur Speicherung beinhalten. Andere Beispiele von intelligenten Hauptrechnern, die auch gleichermaßen zur Verwendung in Verbindung mit Ausführungsbeispielen der vorliegenden Erfindung qualifiziert sind, umfassen einen in der Hand gehaltenen Computer, ein interaktives Decodiergerät für digitales Fernsehen, eine einfache Client- Rechenvorrichtung, eine persönliche Zugangsvorrichtung, persönliche digitale Assistenten und eine Interneteinrichtung.
Bei einer Implementierung auf einem PC-Hauptrechner, der unter einem üblichen auf Windows basierenden Betriebssystem läuft, kann das (MIIDC) ausführbare Programm ein DCOM-Objekt sein. DCOM kann auch als Schnittstelle dienen, die ermöglicht, daß mehrere Anwendungsprogramme mit einer einzelnen Eingabevorrichtung in Dialogverkehr stehen. Die DCOM-Schnittstelle bearbeitet alle Schnittstellenoperationen, wie z. B.: Laden, Ausführen, Puffern, Entladen und Aufrufen des ausführbaren Programms. Bei der Implementierung auf DCOM-Basis ist das MIIDC- Objekt selbst ein DCOM-Server. Das MIIDC-Programm arbeitet durch Verbinden mit der Eingabevorrichtung in einem DCOM-Objekt, das als ausführbarer Server implementiert wird. Folglich wird die MIIDC zu einem DCOM-Objekt, das als ausführbares Programm implementiert wird, was bedeutet, daß die MIIDC ein Prozeß ist - wie ein beliebiger anderer Prozeß eines Betriebssystems (O/S) - der von vielen Anwendungen gemeinsam benutzbar ist. Indem das Eingabevorrichtungs-Zugriffsprogramm in einen separaten ausführbaren Prozeß gegeben wird, kann die Eingabevorrichtung von mehreren Anwendungsprogrammen gemeinsam benutzt werden. Die DCOM- Schnittstelle erscheint dem Anwendungsprogramm, als ob sie nur für die Anwendung geöffnet wird, die das DCOM-Objekt aufruft, obwohl nur eine Instanz der Eingabevorrichtung vorhanden ist.
Die MIIDC wird so implementiert, daß für jede tatsächliche Hardware- Eingabevorrichtung der DCOM-Server eine einzelne Eingabevorrichtungsinstanz erzeugt und mit der Hardwarevorrichtung verbindet. Wenn ein Anwendungsprogramm mit der Eingabevorrichtungssteuerung verbindet - welche ein ausführbarer DCOM- Server ist -, erzeugt der DCOM-Server eine MIIDC-Instanz (und eine Schnittstelle), über die das Anwendungsprogramm mit der einzelnen Eingabevorrichtungsinstanz in Dialogverkehr tritt. Daten werden zur Ausgabe durch die einzelne Eingabevorrichtungsinstanz für jede Instanz der Eingabevorrichtungssteuerung geliefert, was somit ermöglicht, daß mehrere simultane Anwendungen mit einer einzelnen Eingabevorrichtung in Dialogverkehr stehen. Globale Einstellungen sind spezifisch für die (MIIDC)-Instanz. Außerdem wird die Eingabevorrichtungsinstanz geschützt, so daß mehrere Instanzen des Eingabevorrichtungs-Steuerprogramms keine Aufgaben durchführen können, die die Verarbeitung in einer anderen Instanz stören würden. Unter Verwendung dieser neuen Methode können Anwendungen geschrieben werden, die nicht die Anwesenheit einer anderen Anwendung, die möglicherweise bereits dieselbe Eingabevorrichtung verwendet, berücksichtigen müssen.
Andere Aspekte der vorliegenden Erfindung richten sich auf die Client-Seiten- Mechanismen, die ermöglichen, daß ein Anwendungsprogramm mit dem ausführbaren Programm des Eingabevorrichtungsservers in Dialogverkehr steht. Wie vorstehend beschrieben, wird das ausführbare Programm der MIIDC unter einer Client- Server-Architektur implementiert, wobei jedes Anwendungsprogramm ein Client ist. Ein Client muß natürlich mit dem Server in Dialogverkehr stehen können. Das Verfahren der vorliegenden Erfindung stellt verschiedene Mechanismen bereit, die ermöglichen, daß ein Anwendungsprogramm mit dem MIIDC-Server in Dialogverkehr steht. In einer PC/Windows-Umgebung wird ein erster Client-Seiten-Mechanismus über eine ActiveX-Steuerung, die Eingabevorrichtungsportal genannt wird, geliefert. Ein zweiter Client-Seiten-Mechanismus auch unter einer PC/Windows-Umgebung wird über einen DirectShow^TM-Videoerfassungsquellenfilter geliefert.
Die Client-Seiten-Mechanismen unter der Portalmethode umfassen den Dialogverkehr mit dem MIIDC-Server und das Liefern von Benutzerschnittstellenelementen zu einer Anwendung. Mit der Portalmethode wird die gesamte Funktionalität der Virtua- lisierung einer Eingabevorrichtung durch den MIIDC-Server durchgeführt, und somit erfordern Anwendungsprogramme, die mit dem MIIDC-Server in Dialogverkehr stehen, eine Benutzerschnittstellenprogrammierung. Um dies durchzuführen, wird unter der Videoportalmethode eine Schablone bereitgestellt, um zu ermöglichen, daß verschiedene Anwendungsprogrammanbieter ihr eigenes kundenspezifisches Eingabevorrichtungsportal erzeugen.
Der Client-Seiten-Mechanismus unter der zweiten Methode (d. h. DirectShow- Methode) nutzt die normierten modularen DirectShow-Komponenten, die Filter genannt werden, aus. Dieser zweite Client-Seiten-Mechanismus ersetzt den Standardquellen-(Medieneingabe)Filter mit einem Filter einer virtuellen Quelle, der direkt mit dem MIIDC-Server in Dialogverkehr steht. Der Filter der virtuellen Quelle ist für den MIIDC-Server ein Client. Mit diesem Mechanismus kann eine DirectShow- Anwendung nicht zwischen dem Filter der "realen" und der "virtuellen" Quelle unterscheiden. Der Vorteil dieses zweiten Client-Seiten-Mechanismus besteht darin, daß irgendein Anwendungsprogramm, das zum Funktionieren in einer DirectShow- Umgebung geschrieben ist, ohne den Bedarf für irgendeine zusätzliche Benutzerschnittstellenprogrammierung, bevor es mit dem MIIDC-Server in Dialogverkehr treten kann, eine Eingabevorrichtung leicht gemeinsam benutzen kann.
Für ein weiteres Verständnis der Art und der Vorteile der vorliegenden Erfindung sollte auf die folgende Beschreibung in Verbindung mit den zugehörigen Zeichnungen Bezug genommen werden.

KURZBESCHREIBUNG DER ZEICHNUNGEN

Fig. 1 ist ein Blockdiagramm, das das Verfahren des Standes der Technik von einem einzelnen Anwendungsprogramm, das mit einer einzelnen Videokameravorrichtung in Dialogverkehr steht, zeigt.
Fig. 2 ist ein Blockdiagramm, das ein Ausführungsbeispiel des vorliegenden Eingabevorrichtungs-Steuerprogramms für mehrere Instanzen darstellt.
Fig. 3 ist ein Ablaufplan, der die Schritte zeigt, die bei einer Anwendung, die mit einer einzelnen Eingabevorrichtung verbindet, beteiligt sind.

BESCHREIBUNG DER SPEZIELLEN AUSFÜHRUNGSBEISPIELE

Fig. 2 zeigt ein Blockdiagramm, das ein Ausführungsbeispiel des vorliegenden Eingabevorrichtungs-Steuerprogramms für mehrere Instanzen (MIIDC) in einer PC/Windows-Umgebung darstellt. Bei diesem Ausführungsbeispiel ist die Eingabevorrichtung eine Videokamera und das ausführbare Programm ist ein ausführbarer DCOM-Server. Diese Figur zeigt, wie mehrere Anwendungsprogramme eine einzelne Videokamera gemeinsam benutzen können. Wenn ein erstes Anwendungsprogramm 100 einmal zur Verbindung mit der Videokamera 108 aufruft, wird der Aufruf an die DCOM-Anwendungsprogrammschnittstelle (API) 102 weitergeleitet. Auf die entsprechende Microsoft-Dokumentation oder die Microsoft-Website kann für eine ausführlichere Beschreibung von DCOM Bezug genommen werden. Die DCOM-API 102 bearbeitet das Laden des ausführbaren DCOM-Programms und stellt eine Verbindung vom Anwendungsprogramm zum ausführbaren DCOM-Programm 200 her. Der DCOM-Server 200 erzeugt eine einzelne Videokamerainstanz 106 und eine erste MIIDC-Instanz 104. Als nächstes verbindet der DCOM-Server 200 die einzelne Videokamerainstanz 106 mit dem Videokameratreiber 107, den Videokameratreiber 107 mit der Videokameravorrichtung 108 und die erste MIIDC-Instanz 104 mit der einzelnen Videokamerainstanz 106. Die Videokamerainstanz 106 ist eine virtuelle Schnittstelle zur physischen Videokameravorrichtung 108. Eine Instanz ist eine tatsächliche Verwendung und die virtuelle Erzeugung einer in den Speicher geladenen Kopie einer Einheit. Bei diesem Ausführungsbeispiel wird ein Speicher aller Instanzen im ausführbaren Server zugeordnet. Schließlich wird die Verbindung 300 hergestellt, was ermöglicht, daß die Client-Anwendung 100 über die neu als Instanz eingerichtete DCOM-Schnittstelle (einzelne Videokamerainstanz) 106 mit der Videokameravorrichtung 108 in Dialogverkehr tritt.
Sobald ein zweites Anwendungsprogramm 110 zur Verbindung mit der Videokamera 108 aufruft, erzeugt der DCOM-Server 200 eine zweite MIIDC-Instanz 114 und verbindet sie mit der einzelnen Videokamerainstanz 106, was somit ermöglicht, daß die zweite Client-Anwendung 110 über die einzelne Videokamerainstanz 106 mit der Videokameravorrichtung 108 über die zweite hergestellte Verbindung 310 in Dialogverkehr tritt. Anschließende Anwendungsprogrammaufrufe 120 und folgende treten ebenfalls über die von DCOM als Instanz eingerichtete Schnittstelle 106 der einzelnen Videokamerainstanz mit der Videokameravorrichtung 108 über die anschließend hergestellten Verbindungen 320 und folgende in Dialogverkehr.
Fig. 3 ist ein Ablaufplan, der den Prozeß von Fig. 2 darstellt. Wenn ein Client- Anwendungsprogramm einmal zur Verbindung mit der Videokameravorrichtung aufruft (Schritt 103), wird der Aufruf des Anwendungsprogramms zur DCOM-API gesandt (Schritt 203). Als nächstes stellt die DCOM-API fest, ob das ausführbare Programm der DCOM-implementierten MIIDC geladen ist oder nicht. Typischerweise veranlaßt das erste Client-Anwendungsprogramm, daß das ausführbare Programm der MIIDC geladen wird. Wenn der ausführbare MIIDC-Server nicht geladen ist, übernimmt die DCOM-API den Aufruf und veranlaßt, daß der DCOM-Server den ausführbaren Server der DCOM-implementierten MIIDC lädt (Schritt 403). Als nächstes erzeugt der MIIDC-Server eine Eingabevorrichtungssteuerungs-Instanz (Schritt 503). Wenn der ausführbare MIIDC-Server bereits geladen wurde, wird Schritt 403 unnötig, und der nächste Schritt nach Schritt 303 wäre Schritt 503. Der MIIDC-Server erzeugt als nächstes eine einzelne Videokamerainstanz und verbindet sie mit der Videokameravorrichtung und verbindet die Eingabevorrichtungssteuerungs-Instanz mit der einzelnen Videokamerainstanz (Schritt 603). Schließlich erzeugt der MIIDC- Server eine Schnittstelle, über die das erste Client-Anwendungsprogramm mit der einzelnen Kamerainstanz in Dialogverkehr tritt (Schritt 703).
Die in Fig. 2 abgebildete Videokamerainstanz 106 ist eine Schnittstelle mit der Videokameravorrichtung, die den Zustand der Instanz der Eingabevorrichtungssteuerung beibehält. Die Eingabevorrichtungsinstanz 106 ist ein Speicherblock, der die erforderliche Berücksichtigung der Anzahl von Verbindungen, die mit der Videokameravorrichtung hergestellt wurden, und die speziellen Zustände von jeder dieser Verbindungen aufrechterhält. Die Videokamerainstanz 106 beinhaltet auch die zum Priorisieren der Aufforderungen von jeder Verbindung der Eingabevorrichtungssteuerungs-Instanzen und zum Multiplexieren und Lösen von einander widersprechenden Aufforderungen erforderliche Logik. Da der MIIDC-Server als separater Prozeß existiert, müssen Video-(und Audio-)Daten für jeden Client reproduziert werden, der einen Zugriff auf die Video-(und Audio-)Daten benötigt. Um die Datenreproduktion zu verringern, ist der MIIDC-Server dazu ausgelegt, Video-(und Audio-)Daten aufzuzeichnen, eine Bewegung zu erkennen, Bilder zu speichern, sowie für andere Funktionen, die für eine Medienquellenerfassungsvorrichtung typisch sind. Der MIIDC-Server begrenzt somit die Datenreproduktion auf nur jene Anwendungen, die einen direkten Zugriff auf Medienquellen-(z. B. Video- und Audio-)Daten benötigen.
Die erste Eingabevorrichtungsinstanz kann beispielsweise einen Videostrom mit einer Auflösung von 640 mal 480 Pixeln anfordern, während die zweite und die dritte Instanz Videoströme mit Auflösungen von 320 mal 480 bzw. 160 mal 120 Pixeln anfordern können. In einem solchen Szenario würde die Videokamerainstanz 106 dann entscheiden, Videosignale mit der höchsten Auflösung von 640 mal 480 Pixeln zu erfassen und sie dann auf die geringeren Auflösungen, die von der zweiten und der dritten Instanz angefordert werden, maßstäblich zu verkleinern oder zu kappen. Wenn folglich die erste Videoinstanz von der Videokamera abtrennt, würde die Videokamerainstanz 106 dann gemäß derselben Logik die Anforderungen von der zweiten und der dritten Instanz lösen, die Auflösungen von 320 mal 480 bzw. 160 mal 120 Pixeln anfordern, durch Erfassen von Videosignalen mit der höchsten angeforderten Auflösung von 320 mal 480 Pixeln, um die Anforderung der zweiten Instanz zu erfüllen, und dann maßstäbliches Verkleinern oder Kappen des Videostroms mit 320 mal 480 Pixeln auf 160 mal 120 Pixel, um die Anforderung der dritten Instanz zu erfüllen.
Bei einem weiteren Beispiel, das drei Eingabevorrichtungssteuerungs-Instanzen beinhaltet, kann die erste Eingabevorrichtungssteuerungs-Instanz einen Bewegungserkennungsbefehl zur virtuellen Videokameravorrichtung senden, während die anderen zwei Instanzen nur Videoströme anfordern. Nun würde die Videokamerainstanz 106Videosignale mit der höchsten geforderten Auflösung erfassen und nur diesen Videostrom durch eine Bewegungserkennungsberechnung für die erste Eingabevorrichtungssteuerungs-Instanz weiterleiten.
Bei noch einem weiteren Beispiel, das drei Eingabevorrichtungssteuerungs- Instanzen beinhaltet, kann die zweite Eingabevorrichtungssteuerungs-Instanz eine Textüberlagerung auf das Videobild anfordern, während die anderen zwei Instanzen nur Videostromerfassungen anfordern. Nun würde die Videokamerainstanz 106 Videosignale mit der höchsten geforderten Auflösung erfassen und nur die Textüberlagerung zum Strom, der zur zweiten Eingabevorrichtungsanforderung fließt, hinzufügen.
Obwohl die bisher beschriebenen Ausführungsbeispiele im allgemeinen im Zusammenhang mit einer Videokamera beschrieben wurden, die mit einem Personalcomputer-Hauptrechner über eine Schnittstelle gekoppelt ist, soll der Schutzbereich der vorliegenden Erfindung nicht allein auf eine Videokamera oder auch eine spezielle Art von Personalcomputer-Hauptrechner begrenzt sein. Wie vorstehend beschrieben, richten sich die Ausführungsbeispiele der vorliegenden Erfindung auf die gleichzeitige gemeinsame Benutzung einer Eingabevorrichtung durch mehrere Anwendungsprogramme durch Virtualisieren einer Gerätetreiberdatei, was wiederum durch Implementieren des Eingabevorrichtungs-Steuerprogramms als ausführbaren Server erreicht wird. Obwohl die vorstehend beschriebene Eingabevorrichtung eine Videokamera ist, ist eine andere Eingabevorrichtung, die konfiguriert sein kann, um gleichzeitig gemeinsam benutzt zu werden, ein Mikrophon. Somit beinhaltet die Eingabevorrichtungsinstanz (106 in Fig. 2) die Logik, die erforderlich ist, um die Aufforderungen von jeder Eingabevorrichtungs-Steuerinstanz zu priorisieren und sich widersprechende Aufforderungen zu multiplexieren und zu lösen. Die Erweiterung der Fähigkeiten zur gemeinsamen Nutzung der Videoquelle dahingehend, daß sie auch eine Audioeingabequelle umfassen, ist nicht nur eine natürliche, sondern ist auch fast obligatorisch, da Video und Audio am üblichsten als natürlich komplementäre Medienquellen miteinander gebündelt sind.
Unter Rückbezug auf Fig. 2 wird beispielsweise erwartet, zu berücksichtigen, daß ein Mikrophon (nicht dargestellt) auch Ton aufzeichnet, während die Vorrichtung 108Video aufzeichnet. Dann kann die erste Eingabevorrichtungsinstanz beispielsweise Audiosignale mit einer Bittiefe von 16 Bits bei 44,1 kHz anfordern, während die zweite Instanz Audioströme mit einer Tiefe von 8 Bit bei 11,025 kHz anfordern kann. In einem solchen Szenario entscheidet die Eingabevorrichtungsinstanz dann, Audiosignale mit der höchsten Abtastrate und Bittiefe zu erfassen und dann auf die niedrigere Bittiefe oder Abtastrate, die von der zweiten Instanz angefordert wird, maßstäblich zu verkleinern oder zu komprimieren.
Die MIIDC und das Verfahren zum Virtualisieren einer Eingabevorrichtung sind auf vielen Rechenplattformen implementierbar, die auf verschiedenen Betriebssystemen laufen. Eine Medienquellen-Eingabevorrichtung, wie z. B. eine Videokamera oder ein Mikrophon, wird üblicherweise mit einem Hauptrechner über eine Schnittstelle gekoppelt. Der Hauptrechner ist am üblichsten ein Personalcomputer wie z. B. der üblicherweise erhältliche PC von Mac-Computers. Da jedoch die Fortschritte in der Technologie die Grenzen zwischen Rechen- und Informationsaustauschvorrichtungen verwischen, ist ein Hauptrechner, wie hierin verwendet, zu einem intelligenten Hauptrechner synonym, und ein intelligenter Hauptrechner, wie hierin verwendet, soll andere Beispiele von irgendeinem Hauptrechner mit einem Prozessor, einem Speicher, einer Einrichtung zur Eingabe und Ausgabe und einer Einrichtung zur Speicherung beinhalten. Andere Beispiele von intelligenten Hauptrechnern, die auch gleichermaßen zur Verwendung in Verbindung mit Ausführungsbeispielen der vorliegenden Erfindung qualifiziert sind, umfassen einen in der Hand gehaltenen Computer, ein interaktives Decodiergerät für digitales Fernsehen, eine einfache Client- Rechenvorrichtung, eine persönliche Zugangsvorrichtung, persönliche digitale Assistenten und eine Interneteinrichtung.
Andere Aspekte der vorliegenden Erfindung richten sich auf die Client-Seiten- Mechanismen, die ermöglichen, daß ein Anwendungsprogramm mit dem ausführbaren Programm des Eingabevorrichtungsservers in Dialogverkehr steht. Wie vorstehend beschrieben, wird das ausführbare Programm der MIIDC unter einer Client- Server-Architektur implementiert, wobei jedes Anwendungsprogramm ein Client ist. Ein Client muß daher mit dem Server in Dialogverkehr stehen können. Das Verfahren der vorliegenden Erfindung stellt verschiedene Mechanismen bereit, die ermöglichen, daß ein Anwendungsprogramm mit dem MIIDC-Server in Dialogverkehr steht.
In einer PC/Windows-Umgebung wird ein erster Client-Seiten-Mechanismus über eine ActiveX-Steuerung, die Eingabevorrichtungsportal genannt wird, geliefert. Ein zweiter Client-Seiten-Mechanismus auch unter einer PC/Windows-Umgebung wird über einen DirectShow-Videoerfassungsquellenfilter geliefert.
Die Client-Seiten-Mechanismen unter der Portalmethode umfassen den Dialogverkehr mit dem MIIDC-Server und das Liefern von Benutzerschnittstellenelementen zu einer Anwendung. Mit der Portalmethode wird die gesamte Funktionalität der Virtualisierung einer Eingabevorrichtung durch den MIIDC-Server durchgeführt, und somit erfordern Anwendungsprogramme, die mit dem MIIDC-Server in Dialogverkehr stehen, eine Benutzerschnittstellenprogrammierung. Um dies durchzuführen, wird unter der Videoportalmethode eine Schablone bereitgestellt, um zu ermöglichen, daß verschiedene Anwendungsprogrammanbieter ihr eigenes kundenspezifisches Eingabevorrichtungsportal erzeugen.
Der Client-Seiten-Mechanismus unter der zweiten Methode (d. h. DirectShow- Methode) nutzt die normierten modularen DirectShow-Komponenten, die Filter genannt werden. DirectShow^TM-Dienste von Microsoft^TM sehen Wiedergabedienste für Multimediaströme, einschließlich Erfassung von Multimediaströmen von Vorrichtungen, vor. Im Innersten der DirectShow^TM-Dienste befindet sich ein modulares System von steckbaren Komponenten, die Filter genannt werden. Diese modularen Komponenten können als Quelle, Transformation oder Wiedergabe klassifiziert werden. Filter verarbeiten Datenströme durch Lesen, Kopieren, Modifizieren oder Schreiben der Daten in eine Datei oder Wiedergeben der Datei an eine Ausgabevorrichtung. Die Filter weisen eine Eingabe- und Ausgabeeinrichtung auf und sind in einer Filtergraph genannten Konfiguration miteinander verbunden. Anwendungsprogramme verwenden ein Objekt, das Filtergraphmanager genannt wird, um den Filtergraphen zusammenzusetzen und Daten durch diesen zu bewegen. Der Filtergraphmanager vorarbeitet den Datenfluß von einer Eingabevorrichtung zur Wiedergabevorrichtung. Eine weitere Beschreibung von DirectShow^TM-Diensten und des Mediensoftware- Entwicklungssatzes von Microsoft^TM DirectX^TM kann durch Bezugnahme auf die entsprechende Dokumentation, wie Fachleuten bekannt ist, erhalten werden.
Dieser zweite Client-Seiten-Mechanismus ersetzt den Standardquellen-(Medieneingabe)Filter mit einem Filter einer virtuellen Quelle, der direkt mit dem MIIDC-Server in Dialogverkehr steht. Der Filter der virtuellen Quelle ist für den MIIDC-Server ein Client. Mit diesem Mechanismus kann eine DirectShow-Anwendung nicht zwischen dem Filter der "realen" und der "virtuellen" Quelle unterscheiden. Der Vorteil dieses zweiten Client-Seiten-Mechanismus besteht darin, daß irgendein Anwendungsprogramm, das zum Funktionieren in einer DirectShow-Umgebung geschrieben ist, ohne den Bedarf für irgendeine zusätzliche Benutzerschnittstellenprogrammierung, bevor es mit dem MIlDC-Server in Dialogverkehr treten kann, eine Eingabevorrichtung leicht gemeinsam benutzen kann.
Wie für Fachleute verständlich ist, kann die vorliegende Erfindung in anderen speziellen Formen verkörpert werden, ohne von deren wesentlichen Eigenschaften abzuweichen. Die MIIDC könnte beispielsweise als irgendein anderer ausführbarer Prozeß als ein Prozeß auf DCOM-Basis implementiert werden und irgendein anderes Schnittstellenprotokoll als die DCOM-Schnittstelle könnte verwendet werden, um zu ermöglichen, daß mehrere Anwendungsprogramme mit diesem Prozeß in Dialogverkehr treten. Diese anderen Ausführungsbeispiele sollen innerhalb des Schutzbereichs der vorliegenden Erfindung, der in den folgenden Ansprüchen dargelegt ist, eingeschlossen sein.

Claims

1. Eingabevorrichtungs-Steuerprogramm, das ermöglicht, daß mehrere Client- Anwendungsprogramme simultan mit einer einzelnen Eingabevorrichtung in Dialogverkehr treten,
wobei das Eingabevorrichtungs-Steuerprogramm als Prozeß geladen wird, und
wobei alle anschließenden Anwendungsprogramme den Prozeß aufrufen, um eine Verbindung mit der einzelnen Eingabevorrichtung herzustellen.

2. Eingabevorrichtungs-Steuerprogramm nach Anspruch 1, wobei die Eingabevorrichtung eine digitale Internet-Videokamera umfaßt.

3. Eingabevorrichtungs-Steuerprogramm nach Anspruch 1, wobei die Eingabevorrichtung ein Mikrophon umfaßt.

4. Eingabevorrichtungs-Steuerprogramm nach Anspruch 1, wobei das Eingabevorrichtungs-Steuerprogramm Routinen umfaßt für:

a) Videosteuerungsverfahren, umfassend:

a) Initialisieren einer Videosteuerung;

b) Aufnehmen von digitalen Standbildern;

c) Aufzeichnen von digitalen Videobildern;

d) Erhalten von Videotreiberinformationen;

e) Einstellen von Videokameraeigenschaften; und

f) Erhalten von Videokameraeigenschaften;

b) Videokameraereignis-Benachrichtigung, umfassend:

a) Bewegungserkennungsbenachrichtigung;

b) audiovisuelle (AVI) Fehlerbenachrichtigung;

c) Kameratrennungsbenachrichtigung; und

d) Kamerawiederanschlußbenachrichtigung.

5. Eingabevorrichtungs-Steuerprogramm nach Anspruch 1, wobei der Prozeß alle Details von Netzwerkprotokollen bearbeitet, umfassend:
Laden des Eingabevorrichtungs-Steuerprogramms;
Aufrufen des Eingabevorrichtungs-Steuerprogramms mit relevanten Eingabe/Ausgabe-Daten;
Puffern von Eingabe und Ausgabe in das/aus dem Eingabevorrichtungs- Steuerprogramm;
Ausführen des Eingabevorrichtungs-Steuerprogramms; und
Entladen des Eingabevorrichtungs-Steuerprogramms.

6. Eingabevorrichtungs-Steuerprogramm, das ermöglicht, daß mehrere Client- Anwendungsprogramme simultan mit einer Eingabevorrichtung in Dialogverkehr treten, wobei das Eingabevorrichtungs-Steuerprogramm als Reaktion darauf, daß ein erstes Anwendungsprogramm für die Herstellung einer ersten Verbindung mit der Eingabevorrichtung aufruft:

a) die Aufrufe des ersten Anwendungsprogramms an eine Anwendungsprogrammschnittstelle (API) des Prozesses weiterleitet;

b) veranlaßt, daß das Netzwerkprotokoll des Prozesses das ausführbare Eingabevorrichtungs-Steuerprogramm auf einen Prozeßserver lädt;

c) veranlaßt, daß der Prozeßserver eine einzelne Eingabevorrichtungsinstanz erzeugt, und die einzelne Eingabevorrichtungsinstanz mit der Eingabevorrichtung verbindet;

d) veranlaßt, daß der Prozeßserver eine erste Eingabevorrichtungssteuerungs-Instanz erzeugt, und die erste Eingabevorrichtungssteuerungs-Instanz mit der einzelnen Eingabevorrichtungsinstanz verbindet;

e) veranlaßt, daß der Prozeßserver eine Schnittstelle erzeugt, über die das Client-Anwendungsprogramm mit der einzelnen Eingabevorrichtungsinstanz in Dialogverkehr tritt, und

f) veranlaßt, daß eine zweite Eingabevorrichtungssteuerungs-Instanz als Reaktion auf einen Aufruf von einem zweiten Anwendungsprogramm, das für eine zweite Verbindung mit der einzelnen Eingabevorrichtung aufruft, erzeugt wird, und die zweite Eingabevorrichtungssteuerungs-Instanz mit der einzelnen Eingabevorrichtungsinstanz verbunden wird, was ermöglicht, daß das zweite Anwendungsprogramm mit derselben einzelnen Eingabevorrichtungsinstanz in Dialogverkehr tritt.

7. Eingabevorrichtungsprogramm nach Anspruch 6, wobei das Eingabevorrichtungs-Steuerprogramm ein ausführbares Programm eines Modells mit verteilten Komponentenobjekten (DCOM) ist, das Routinen für folgendes umfaßt:

a) Videosteuerungsverfahren, umfassend:

a) Initialisieren einer Videosteuerung;

b) Aufnehmen von digitalen Standbildern;

c) Aufzeichnen von digitalen Videobildern;

d) Erhalten von Videotreiberinformationen;

e) Einstellen von Videokameraeigenschaften; und

f) Erhalten von Videokameraeigenschaften;

b) Videokameraereignis-Benachrichtigung, umfassend:

a) Bewegungserkennungsbenachrichtigung;

b) audiovisuelle (AVI) Fehlerbenachrichtigung;

c) Kameratrennungsbenachrichtigung; und

d) Kamerawiederanschlußbenachrichtigung.

8. Eingabevorrichtungs-Steuerprogramm nach Anspruch 6, wobei der Prozeß ein ausführbares Programm eines Modells mit verteilten Komponentenobjekten (DCOM) ist.

9. Ausführbares Eingabevorrichtungs-Steuerprogramm eines Modells mit verteilten Komponentenobjekten (DCOM), das ermöglicht, daß mehrere Client- Anwendungsprogramme simultan mit einer Eingabevorrichtung in Dialogverkehr treten, wobei das Programm als Reaktion darauf, daß ein erstes Anwendungsprogramm für die Herstellung einer ersten Verbindung mit der Eingabevorrichtung aufruft:

a) die Aufrufe des ersten Anwendungsprogramms an eine Anwendungsprogrammschnittstelle (API) des DCOM weiterleitet;

b) veranlaßt, daß das Netzwerkprotokoll des DCOM das ausführbare Eingabevorrichtungs-Steuerprogramm auf einen DCOM-Server lädt; und

c) veranlaßt, daß der DCOM-Server eine einzelne Eingabevorrichtungsinstanz erzeugt, und die einzelne Eingabevorrichtungsinstanz mit der Eingabevorrichtung verbindet;

d) veranlaßt, daß der DCOM-Server eine erste Eingabevorrichtungssteuerungs-Instanz erzeugt, und die erste Eingabevorrichtungssteuerungs-Instanz mit der einzelnen Eingabevorrichtungsinstanz verbindet;

e) veranlaßt, daß der DCOM-Server eine Schnittstelle erzeugt, über die das Client-Anwendungsprogramm mit der einzelnen Eingabevorrichtungsinstanz in Dialogverkehr tritt, und

f) veranlaßt, daß eine zweite Eingabevorrichtungssteuerungs-Instanz als Reaktion auf einen Aufruf von einem zweiten Anwendungsprogramm, das für eine zweite Verbindung mit der einzelnen Eingabevorrichtung aufruft, erzeugt wird und die zweite Eingabevorrichtungssteuerungs-Instanz mit der einzelnen Eingabevorrichtungsinstanz verbunden wird, was ermöglicht, daß das zweite Anwendungsprogramm mit derselben einzelnen Eingabevorrichtungsinstanz in Dialogverkehr tritt.

10. Vom Computer verwendbares Medium mit einem darin verkörperten maschinenlesbaren Code, um die gleichzeitige gemeinsame Benutzung einer Eingabevorrichtung durch mehrere Anwendungsprogramme, die auf einem Hauptrechner laufen und die Eingabevorrichtung aufrufen, zu bewirken, wobei der maschinenlesbare Code eine Eingabevorrichtungstreiberdatei virtualisiert, wobei der maschinenlesbare Code in einer ausführbaren Client-Server- Architektur implementiert wird, wobei jedes der Anwendungsprogramme ein Client ist, und wobei der maschinenlesbare Code ein Server ist.

11. Vom Computer verwendbares Medium nach Anspruch 10, wobei die Eingabevorrichtung eine digitale Videokamera umfaßt, die mit dem Hauptrechner über eine Schnittstelle gekoppelt ist.

12. Vom Computer verwendbares Medium nach Anspruch 10, wobei die Eingabevorrichtung ein Mikrophon umfaßt, das mit dem Hauptrechner über eine Schnittstelle gekoppelt ist.

13. Vom Computer verwendbares Medium nach Anspruch 10, wobei der Hauptrechner aus der Gruppe ausgewählt ist, die aus einem Personalcomputer, einem in der Hand gehaltenen Computer, einem interaktiven Decodiergerät für digitales Fernsehen, einer einfachen Client-Rechenvorrichtung, einer persönlichen Zugangsvorrichtung, einem persönlichen digitalen Assistenten, einer Interneteinrichtung, einem mit dem Internet verbundenen Digitalbildrahmen und Kombinationen davon besteht.

14. Vom Computer verwendbares Medium nach Anspruch 10, wobei die Anwendungsprogramme mit der Client-Server-Architektur über einen Client-Seiten- Mechanismus in Dialogverkehr stehen, der als Eingabevorrichtungsportal implementiert wird.

15. Vom Computer verwendbares Medium nach Anspruch 14, wobei das Eingabevorrichtungsportal eine ActiveX-Steuerung ist.

16. Vom Computer verwendbares Medium nach Anspruch 10, wobei die Anwendungsprogramme mit der Client-Server-Architektur über einen Client-Seiten- Mechanismus in Dialogverkehr stehen, der als Filter einer virtuellen Quelle implementiert wird.

17. Verfahren zum Ermöglichen, daß mehrere Client-Anwendungsprogramme mit einer einzelnen Eingabevorrichtung in Dialogverkehr treten, wobei das Verfahren folgendes umfaßt:

a) Weiterleiten der Aufrufe eines ersten Anwendungsprogramms an eine Anwendungsprogrammschnittstelle (API) des Prozesses;

b) Veranlassen, daß das Netzwerkprotokoll des Prozesses ein ausführbares Eingabevorrichtungs-Steuerprogramm auf einen Prozeßserver lädt; und

c) Veranlassen, daß der Prozeßserver eine einzelne Eingabevorrichtungsinstanz erzeugt, und Verbinden der einzelnen Eingabevorrichtungsinstanz mit der einzelnen Eingabevorrichtung;

d) Veranlassen, daß der Prozeßserver eine erste Eingabevorrichtungssteuerungs-Instanz erzeugt, und Verbinden der ersten Eingabevorrichtungssteuerungs-Instanz mit der einzelnen Eingabevorrichtungsinstanz;

e) Veranlassen, daß der Prozeßserver eine Schnittstelle erzeugt, über die das Client-Anwendungsprogramm mit der einzelnen Eingabevorrichtungsinstanz in Dialogverkehr tritt, und

f) Erzeugen einer zweiten Eingabevorrichtungssteuerungs-Instanz als Reaktion auf einen Aufruf von einem zweiten Anwendungsprogramm, das für eine Zweite Verbindung mit der einzelnen Eingabevorrichtung aufruft, und Verbinden der zweiten Eingabevorrichtungssteuerungs-Instanz mit der einzelnen Eingabevorrichtungsinstanz, um eine Schnittstelle zu erzeugen, über die die zweite Client-Anwendung mit derselben einzelnen Eingabevorrichtungsinstanz in Dialogverkehr tritt.

18. Verfahren nach Anspruch 17, wobei das ausführbare Eingabevorrichtungs- Steuerprogramm ein ausführbares Programm eines Modells mit verteilten Komponentenobjekten (DCOM) ist.

19. Verfahren nach Anspruch 17, wobei der Prozeß ein DCOM-Prozeß ist.