DE69624168T2

DE69624168T2 - Erweiterbares System zur Verwaltung von Kommunikationsverfahren für ein Rechnersystem

Info

Publication number: DE69624168T2
Application number: DE69624168T
Authority: DE
Inventors: Peter J. Kaufman; Puneet Kukkal; Adam Trent
Original assignee: Intel Corp
Current assignee: Intel Corp
Priority date: 1995-05-26
Filing date: 1996-05-22
Publication date: 2003-05-28
Anticipated expiration: 2016-05-23
Also published as: EP0744689A3; US5961620A; EP0744689B1; EP0744689A2; DE69624168D1

Description

HINTERGRUND DER ERFINDUNG

Gebiet der Erfindung

Die Erfindung bezieht sich auf Computersysteme und Verfahren, speziell auf computerimplementierte Prozesse und Vorrichtung für erweiterbare Kommunikationen zwischen Anwendungen und Benutzern von Computersystemen.

Beschreibung der relevanten Technik

Es ist erwünscht, für Kommunikation zwischen verschiedenen Anwendungen, Komponenten und Benutzern von Computersystemen zu sorgen. Beispielsweise besteht für Konferenzsysteme auf Computerbasis eine Notwendigkeit, für Kommunikation zwischen entfernten Benutzern von Anwendungen des Konferenzsystems zu sorgen.
Solche Computersysteme umfassen häufig auf PC basierende Systeme, die in Windows-Umgebungen arbeiten, wie etwa diejenigen, die durch Versionen des Microsoft® WindowsTM-Betriebssystems gegeben sind. Anwendungen und Elementen von Computersystemen sind Adressen verschiedener Typen zugeordnet, die über die Zeit häufig aktualisiert oder kreiert werden.
Fernkommunikation wird oft mit einer Vielzahl Hardwaremechanismen realisiert. Beispielsweise kann ein solcher Kommunikations-Hardwaremechanismus ein Datenmodem enthalten, welches Datenkommunikationen über eine POTS-Telefonleitung (Plain Old Telephone System) ermöglicht, sowie ein Kommunikationsnetzwerkinterface, welches die Übertragung von E-Mail-Nachrichten über ein örtliches Netzwerk (LAN) erlaubt. Ein solches Computersystem kann auch ein Hochgeschwindigkeits-Kommunikationsleitungs-Interface enthalten, welches für ein Videokonferenzsystem eine Videokommunikation in Realzeit erlaubt.
Außerdem implementieren solche Computersysteme typischerweise eine Vielzahl von Kommunikations-Anwenderprogrammen, welche solche Hardware-Kommunikationsmechanismen verwenden. Beispielsweise wird typischerweise ein Fax oder Fax-Modem- Anwenderprogramm implementiert, welches Fax und Datenkommunikation über das Hardware-Datenmodem vornimmt. Ein solches früheres Computersystem kann auch ein E-Mail-Anwenderprogramm enthalten, welches die Übertragung von E-Mail-Nachrichten und Dateien über das LAN durch das Hardware-Netzwerkinterface erlaubt. Ein solches Computersystem kann außerdem ein Videokonferenz-Anwenderprogramm implementieren, welches die Übertragung von Videodaten und anderen Daten über ein Hochgeschwindigkeits-Kommunikations-Leitungsinterface vornimmt.
Derartige Kommunikations-Anwenderprogramme erfordern typischerweise, dass ein Benutzer ein oder mehrere Bestimmungsbezeichner für die Übertragung von Daten oder Nachrichten angibt. Ein Fax-Anwenderprogramm erfordert typischerweise vom Benutzer die Angabe einer Telefon/Fax-Nummer für die Fax- Übertragung. Ähnlich erfordert ein typisches E-Mail- Anwenderprogramm von einem Benutzer die Angabe einer E-Mail- Adresse für abgehende Nachrichten. Außerdem erfordert eine typische Videokonferenz-Anwendung vom Benutzer die Angabe einer Bestimmungsadresse auf einer Hochgeschwindigkeits-Kommunikationsleitung für die Übertragung abgehender Videodaten. Beispielsweise kann ein solches Videokonferenz-Anwenderprogramm vom Benutzer fordern, eine ISDN-Adresse für die Videokonferenzdurchführung über ein ISDN-Kommunikationslink anzugeben.
In der WO 96/28790 ist ein Computersystem beschrieben, welches die Verwendung von auf Arbeitsplatzrechnern (workstations) laufenden netzwerk- und plattformunabhängigen Anwendungen erlauben. Ein Konferenzprozessor (conference engine) bildet ein Netzwerkinterface zwischen Anwendungen und dem Netzwerk. Der Konferenzprozessor sorgt sowohl für Netzwerks- als auch Konferenzmanagementfunktionen. Die Anwendungen sind in Anwendungsmodulen organisiert, die jeweils eine diskrete kollaborative Rechnerfunktion durchführen. Zustandsrechner (state engines) an jedem der Mehrzahl von Arbeitsrechnern kommunizieren miteinander über das Netzwerk und bilden so einen verteilten Zustandsrechner für eine kollaborative Computersitzung, welche die Anwendungsmodule an jedem der Mehrzahl von Arbeitsplatzrechner benutzt, und wobei die Zustandsrechner an jedem der Mehrzahl von Arbeitsplatzrechnern in den aktiven Zustand übergehen, wenn eine kollaborative Computersitzung eingeleitet wird.
In der UK-Patentanmeldung GB 2 272 311 ist ein programmierbarer Arbeitsplatzrechner für kollaboratives Arbeiten in einem Netzwerk beschrieben. Jeder Knoten hat ein Betriebssystem und Anwenderprogramme und möglicherweise eine Mehrzahl von Manager-Aufrufprogrammen, die für die Verarbeitung ankommender Kommunikationen zuständig sind, welche nicht spezifisch für eine spezielle Anwenderprogrammanforderung sind, die auf dem Knoten läuft. Der Arbeitsplatzrechner hat eine Netzwerkkontroll-Programmschicht, die auf dem Betriebssystem läuft, um die räumliche Wegführung der Kommunikationen zwischen den Knoten zu steuern. Der Arbeitsplatzrechner hat ferner ein kollaboratives Anwenderuntersystem als Interface für die auf dem Arbeitsplatzrechner laufenden Anwenderprogramme. Das kollaborative Anwenderuntersystem ist für einen Anwenderprogrammaufruf von einem auf dem Arbeitsplatzrechner laufenden Manageraufrufprogramm zuständig, um dieses Manageraufrufprogramm als aktives Manageraufrufprogramm am Knoten zu etablieren, um ankommende Ereignisse zu bearbeiten, die nicht spezifisch für irgendeine Anwenderprogrammanforderung am Knoten sind.
Frühere Kommunikationsanwenderprogramme implementieren typischerweise einen Adressbuchservice, welcher es dem Benutzer ermöglicht, Empfängernamen und entsprechende Bestimmungsinformationen in einer Adressbuchdatei zu speichern. Typischerweise bewirkt ein solcher Adressbuchservice eine Abbildung von Empfängernamen im Bestimmungsbezeichner, wie etwa Telefonnummern und E-Mail-Adressen. Außerdem erlaubt es ein Adressbuchservice eines Kommunikationsanwenderprogramms üblicherweise dem Benutzer, in einer Adressbuchdatenbank nach Empfängernamen oder entsprechenden Bestimmungsbezeichnern zu suchen und diese zu finden. Beispielsweise erlaubt es ein Adressbuchservice in einem typischen Fax-Anwenderprogramm dem Benutzer, Fax-Nummern und zugehörige Bestimmungsnamen zu speichern und wieder zu finden. Ein typisches E-Mail-Anwenderprogramm erlaubt es dem Benutzer, zu den Empfängernamen E-Mail-LAN-Adressen zu speichern und wieder zu finden. Bei einigen früheren Computersystemen hält sich jedes installierte Kommunikationsanwenderprogramm ein separates privates Adressbuch. So hält sich beispielsweise ein Fax-Anwenderprogramm üblicherweise ein Fax- Nummer-Adressbuch, während sich ein E-Mail-Anwenderprogramm ein eigenes E-Mail-Adressbuch hält.
Unglücklicherweise fordern solche separaten Adressbücher typischerweise vom Benutzer die Eingabe der gleichen Information in mehrere Adressbuch-Datenbanken. Beispielsweise kann ein bestimmter Empfänger sowohl eine Fax-Adresse wie auch eine E- Mail-Adresse haben. Bei solchen früheren Systemen muss der Benutzer typischerweise den Empfängernamen und dazugehörige Information in das private Adressbuch für das Fax- Anwenderprogramm ebenso wie in das private Adressbuch für das E-Mail-Anwenderprogramm eingeben. Eine solche doppelte Information für mehrere private Adressbücher erhöht üblicherweise den Speicherplatzbedarf des Computersystems, der von Datenbanken für Computer-Anwenderprogramme benötigt wird.
Weiterhin sind solche Systeme, die mehrere private Adressbücher benötigen, üblicherweise schwierig auf dem Laufenden zu halten, weil Änderungen bezüglich Empfängerinformationen typischerweise vom Benutzer eine Änderung der gleichen Information in mehreren Adressbuch-Datenbanken erfordert. Außerdem erfordern solche Systeme typischerweise, dass der Benutzer mehrere Adressbuchbenutzer-Tnterfaces lernt. Demzufolge besetzen solche Systeme typischerweise größere Systemressourcen und erfordern höheren Erhaltungsaufwand, weil gleiche Informationen in mehreren Kommunikations-Anwenderprogrammen festgehalten werden.
Es besteht daher eine Notwendigkeit, mehrfach genutzte Adressbuchservices für Typmanagement in einem Computersystem zu schaffen. In Computersystemen, etwa Konferenzsystemen, gibt es eine Vielzahl verschiedener Adressentypen, beispielsweise PHONE-ISDN und PHONE-POTS oder andere Typen, wie oben angeführt. Jeder spezifische Adressentyp wird von einer dynamischen Link-Bibliothek (DLL) wie etwa Windows-DLL, unterstützt. Wenn beispielsweise ein Benutzer einer Anwendung eine Verbindung mit einem zweiten Benutzer eines anderen Konferenzknotens über eine ISDN-Verbindung wünscht, dann wird eine spezielle ISDN-Adresse geliefert. Eine darauf abgestellte DLL vom ISDN- Typ stellt dann die Verbindung zum zweiten Benutzer an dessen Adresse über ein ISDN her. Man kann einen Manager vom DLL-Typ oder vom Bibliothekstyp benutzen, um die richtige Typ-DLL auszuwählen, so dass die betreffende Kommunikationsverbindung hergestellt werden kann. Beispielsweise kann ein Videokonferenz-Anwenderprogramm einen Typ-Bibliotheksmanager und einige alternative Typ-Bibliotheken oder DLL's zur Unterstützung einer Vielzahl von Verbindungsadressentypen enthalten.
Das US-Patent Nr. 5,136,716 beschreibt ein System mit mindestens einem Serverknoten, der einen Namensgebungsservice (naming service) bereitstellt. Der Namensgebungsservice liefert, von einem einzigen Ort, den Ort jeglichen Objektes in den Serverknoten und im Klientenknoten. Ein Klientenknoten, welcher Zugang zu einem Objekt anfordert, versorgt den Namensgebungsknoten mit dem Namen des Objektes, und der Namensgebungsservice identifiziert den Klientenknoten oder Serverknoten, welcher das Objekt steuert und durch welchen auf das Objekt zugegriffen werden kann. Jeder Klientenknoten enthält einen Mehrschicht-Nachrichtenabschnitt mit einer Sitzungssteuerschicht, einem Satz oberer Schichten und einem Satz unterer Schichten. Jede der Schichten in dem Nachrichtenabschnitt wird benutzt zur Ermöglichung der Sendung und des Empfangs von Nachrichten über ein Kommunikationslink. Ein Modul für obere Interfaces in einem Klienten bildet ein uniformes Interface für Programme, welche auf dem Klienten laufen, und ein Modul für untere Interface bildet ein Interface für untere Schichten in dem Nachrichtenabschnitt. Ein Verbindungssteuermodul bearbeitet Übertragungsanforderungen, die beim Modul der oberen Interface ankommen und leitet sie zu den unteren Schichten weiter.
Jedoch entwickelt sich der Satz verschiedener Adressentypen mit der Zeit, wobei alte Adressentypen aktualisiert werden und neue Adressentypen entstehen, beispielsweise um neue Kommunikationsmechanismen oder Adressierschemen zu bilden. Ein Problem beim Stand der Technik besteht darin, dass solche neuen Adressentypen nicht in bestehende Anwenderprogramme und ihre Typ-Managementsysteme eingefügt werden können. Es muss also ein neues Anwenderprogramm und aktualisiertes Typ-Managementsystem entwickelt, neu kompiliert und neu verkauft oder anderweitig an Benutzer neu verteilt werden, um Vorteile verfügbarer neuer Adressentypen auszunutzen.
Es wird daher ein erweiterbarer Kommunikationstypmanager für ein Computersystem benötigt, welches das Formatieren, Speichern sowie benutzerseitiges Editieren neuer Adressentypen unterstützt.

ZUSAMMENFASSUNG DER ERFINDUNG

Es wird ein Universalmanager (general type manager) zum Managen von Verbindungsadressen und Verbindungstypen eines Computersystems beschrieben, welcher ein erstes Interface als Interface zwischen dem Universalmanager und ein oder mehreren Anwenderprogrammen von Computersystemen dient, und der Universalmanager eignet sich zur Durchführung einer Mehrzahl von Allgemeintypmanagerfunktionen (gtm-Funktionen), die von den Anwenderprogrammen aufgerufen werden. Der Universalmanager bildet auch ein zweites Interface als Interface zwischen dem Universalmanager und einem oder mehreren Typmanagern des Computersystems, wobei ein Typmanager mindestens einen Verbindungstyp unterstützt und jeder Typmanager sich zur Durchführung einer Mehrzahl von Typfunktionen eignen, welcher vom Universalmanager entsprechend ein oder mehreren gtm-Funktionen eignet, die vom Anmelderprogramm aufgerufen werden. Die Mehrzahl von gtm-Funktionen umfassen eine erste gtm-Funktion zur Initialisierung des Universalmanagers zur Benutzung; eine zweite gtm-Funktion zur Vorbereitung des zu entladenden Universalmanagers; eine dritte gtm-Funktion zur Editierung einer Verbindungsadresse entsprechend einem Verbindungstyp der Verbindungsadresse, und eine vierte gtm-Funktion zur Erzeugung und Editierung einer neuen Verbindungsadresse eines Verbindungstyps, welche von dem einen oder mehreren Typmanagern unterstützt wird.

KURZE BESCHREIBUNG DER ZEICHNUNGEN

Diese und andere Merkmale, Aspekte und Vorteile der Erfindung werden aus der folgenden Beschreibung, den beiliegenden Ansprüchen und Zeichnungen noch deutlicher. Es zeigen:
Fig. 1 ein Computersystem für eine Ausführungsform, welches einen Prozessor, einen Hauptspeicher, ein Massenspeicher- Untersystem, ein Kommunikationsleitungsinterface, ein Netzwerkinterface und einem Modem enthält;
Fig. 2 Beispiele von Software-Elementen, die auf dem Computersystem nach Fig. 1 implementiert werden können und ein Fax-Anwenderprogramm, ein Videokonferenz-Anwenderprogramm, ein E-Mail-Anwenderprogramm, ein Adressbuch-Anwenderprogramm und eine Adressbuch-Dynamik-Link-Bibliothek enthalten;
Fig. 3 ein Blockdiagramm einer bevorzugten Universal- Managementarchitektur gemäß der Erfindung;
Fig. 4 ein Karteneditier-Dialogfenster zum Editieren von Verbindungsadressen für bestimmte Eingaben in eine Adressendatenbank gemäß der Erfindung;
Fig. 5 ein Editierdialogfenster zum Editieren einer Telefonverbindungsadresse entsprechend einer Benutzereingabe unter Aufforderung durch das Karteneditierdialogfenster nach Fig. 4; und
Fig. 6 ein neues Dialogfenster zum Erstellen einer neuen Verbindungsadresse entsprechend einer Benutzereingabe unter Aufforderung durch das Karteneditierdialogfenster nach Fig. 4.

BESCHREIBUNG DER BEVORZUGTEN AUSFÜHRUNGSFORM

Referenzliteratur

Ein Konferenzsystem auf Computerbasis und eine Architektur hierfür sind in der US-Patentanmeldung Nr. 08/342,270 vom 16. November 1994 beschrieben, welche eine CIP-Anmeldung der US- Patentanmeldung Nr. 08/340,172 vom 15. November 1994 ist, die ihrerseits eine CIP-Anmeldung der US-Patentanmeldung Nr. 08/157,594 vom 24. November 1993 ist, auf welche hiermit in ihrer Gesamtheit Bezug genommen wird. Ein System, welches sich auf die hier beschriebene Adressbuchtechnologie bezieht, ist in der US-Patentanmeldung Nr. 08/312,317 (Anwaltsaktenzeichen Nr. 42390.P1463) vom 26. September 1994 beschrieben, auf welche hiermit ebenfalls insgesamt Bezug genommen wird.

Mehrfach genutzte Adressbuchservices

In Fig. 1 ist ein Computersystem 100 nach einer bevorzugten Ausführungsform der Erfindung veranschaulicht. Das Computersystem 100 enthält einen Prozessor 112, einen Hauptspeicher 114 und ein Massenspeicher-Untersystem 116. Das Computersystem 100 enthält weiterhin ein Kommunikationsleitungsinterface 118, ein Netzwerkinterface 120 und ein Modem 122. Der Prozessor 112, der Hauptspeicher 114, das Massenspeicher-Untersystem 116, das Kommunikationsleitungsinterface 118, das Netzwerkinterface 120 und das Modem 122 sind über einen Systembus 124 zur Kommunikation miteinander zusammengeschaltet.
Der Systembus 124 kann irgendeine geeignete Digitalsignal- Übertragungseinrichtung sein, beispielsweise ein Industrie- Standard-Architektur(ISA)-Bus oder ein erweiterter ISA(EISA)- Bus. Der Prozessor 112 kann ein Allzweckprozessor sein, der sich zur Verarbeitung von Konferenzdatensignale eignet, also etwa Intel®-Allzweck-Mikroprozessoren wie die Intel 1386TM-, 1486TM- oder PentiumTM-Prozessoren. Für den Fachmann versteht es sich, dass der Prozessor 112 auch ein Spezialzweck-Videoprozessor wie der Intel 82750PB sein kann.
Der Hauptspeicher 114 stellt Speicherbereiche für ein Betriebssystem, einen Satz von Anwenderprogrammen einschließlich Kommunikations-Anwenderprogrammen und entsprechende Gerätetreiberprogramme und zugehörige Datenstrukturen für das Computersystem 100 zur Verfügung. Das Massenspeicher-Untersystem 116 stellt in großem Maßstab Daten und Programmspeicher für das Computersystem 100 zur Verfügung. Es kann irgendeine geeignete Vorrichtung zum Speichern von Digitalsignalen sein und ist vorzugsweise eine Kombination von Computerfestplatte und RAM-Speichern. Das Massenspeicher-Untersystem 116 bietet Speicherbereiche für Anwenderprogramme, Gerätetreiberprogramme, ein Betriebssystem sowie Dateien und zugehörige Datenstrukturen für das Computersystem 100.
Das Kommunikationsleitungsinterface 118 erlaubt Kommunikation über ein Hochgeschwindigkeits-Kommunikationslink 130. Bei einer Ausführungsform umfasst das Hochgeschwindigkeits-Kommunikationslink 130 ein ISDN-Kommunikationslink. Das Netzwerkinterface 120 erlaubt LAN-Kommunikation über ein Kommunikationlink 132. Bei einer Ausführungsform umfasst das Kommunikationlink 132 ein Ethernet-Kommunikationlink. Das Modem 122 erlaubt Daten-Kommunikationen und Fax-Kommunikationen über eine POTS- Telefonleitung 134.
Das Computersystem 100 umfasst ferner eine Tastatur und Maus 128 und einen Monitor 126. Die Tastatur und Maus 128 und der Monitor 126 erlauben die Durchführung von Anwenderprogrammen auf dem Computersystem 100 zur Durchführung von Benutzerinterface-Funktionen über Eingaben auf der Tastatur und der Maus 128 und die Ausgangsdarstellung auf dem Monitor 126. Der Monitor 126 kann irgendein geeignetes Gerät zur Darstellung analoger Bildsignale sein, beispielsweise ein VGA-Monitor.
Es sei nun Fig. 2 betrachtet, welche verschiedene Beispiele von Software-Elementen veranschaulicht, die auf dem Computersystem 100 implementiert werden können. Die Software-Elemente des Computersystems 100 umfassen einen Satz von Kommunikations-Anwenderprogrammen einschließlich eines Fax-Anwenderprogramms 201, eines Video-Konferenz-Anwenderprogramms 202 und eines E-Mail-Anwenderprogramms 204. Die Software-Elemente des Computersystems 100 umfassen ferner ein Adressbuch- Anwenderprogramm 206 und eine Adressbuch-DLL 210. Die Software-Elemente des Computersystems 100 enthalten auch ein Betriebssystem 214. Bei einer bevorzugten Ausführungsform ist das Betriebssystem 214 ein Mikrosoft Windows-Betriebssystem, welches Kommunikationsinterfaces zwischen Software-Elementen über DLL's und entsprechende Anwenderprogrammier-Interfaces (API's) bereitstellt. Wie weiter unten noch im Zusammenhang mit Fig. 3 erläutert wird, wird im Computersystem 100 auch ein Universalmanager benutzt, um Formatieren, Speichern und Benutzereditierung von Adressentypen zu erlauben. Die Implementierung der Software-Elemente in Fig. 2 wird allerdings ohne einen solchen Universalmanager beschrieben, um die Verwendung von API's und eines Adressebuch-Anwenderprogramms zu veranschaulichen.
Die Adressbuch-DLL 210 bietet Adressbuchservices für auf dem Computersystem 100 ausgeführte Anwenderprogramme einschließlich Fax-Anwenderprogramm 201, Videokonferenz-Anwenderprogramm 202 und E-Mail-Anwenderprogramm 204. Das Fax-Anwenderprogramm 201, das Videokonferenz-Anwenderprogramm 202 und das E-Mail- Anwenderprogramm 204 greifen jeweils über ein Adressbuch API 220 auf Adressbuchservices der Adressbuch-DLL 210 zu. Das Adressbuch-Anwenderprogramm 206 greift auch über das Adressbuch API 220 auf die Adressbuchservices der Adressbuch-DLL 210 zu. Das Fax-Anwenderprogramm 201, das Videokonferenz-Anwenderprogramm 202 und das E-Mail-Anwenderprogramm 204 sowie andere Anwenderprogramme werden gegenüber der Adressbuch-DLL 210 als Klienten-Kommunikations-Anwenderprogramme bezeichnet.
Das Fax-Anwenderprogramm 201 führt Fax-Übertragungen über das Modem 122 durch die Telefonleitung 134 aus. Das Fax- Anwenderprogramm 201 bewirkt das Anwählen, die Verbindungsbestätigungsfunktionen sowie Telefonleitungs-Abschaltfunktionen über das Modem 122 durch. Das Fax-Anwenderprogramm 201 implementiert auch Benutzerinterface-Funktionen, welche es einem Benutzer erlauben, Fax-Übertragungen einzuleiten und Adressbuch-Informationen für Fax-Kommunikation einzugeben. Die Benutzerinterface-Funktionen des Fax-Anwenderprogramms 201 liefern auch Statusanzeigen mit Hilfe des Monitors 126 für den Benutzer.
Das Videokonferenz-Anwenderprogramm 202 führt Realzeit- Videodatenübertragungen über das Hochgeschwindigkeits- Kommunikationslink 130 durch das Kommunikationsleitungs- Interface 118 durch. Das Videokonferenz-Anwenderprogramm 202 führt auch Videodatencodier- und -decodierfunktionen sowie Benutzerinterface-Funktionen aus. Die Benutzerinterface-Funktionen des Videokonferenz-Anwenderprogramms 202 erlauben es dem Benutzer, Adressbuchinformationen einschließlich ISDN-Adressen einzugeben, welche die Videokonferenzempfänger auf dem Kommunikationslink 130 bezeichnen. Die Benutzerinterface-Funktionen des Videokonferenz-Anwenderprogramms 202 umfassen Videofensterdarstellungen und Statusanzeigen auf dem Monitor 126.
Die Adressbuch-DLL 210 implementiert Routinen oder Funktionen zum Zugreifen und Erhalten einer Adressbuchdatei im Massenspeicher-Untersystem 116. Die Adressbuch-DLL 210 greift auf eine Adressbuch-Datenbank im Massenspeicher-Untersystem 116 zurück, indem sie Funktionen der Datenbank-DLL 212 aufruft. Die Funktionen der Datenbank-DLL 212 werden über ein Datenbank-API 230 aufgerufen.
Das Adressbuch-Anwenderprogramm 206 implementiert Benutzerinterface-Funktionen, welche einen Benutzer in die Lage versetzen, individuelle Bestimmungsbezeichner aus der Adressbuchdatei im Massenspeicher-Untersystem 116 auszuwählen. Das Adressbuch-Anwenderprogramm 206 informiert das geeignete Kommunikations-Anwenderprogramm entsprechend dem vom Benutzer gewählten Bestimmungsbezeichnertyp. Die Benutzerinterface-Funktionen des Adressbuch-Anwenderprogramms 206 erlauben es auch einem Benutzer, Adressbuch-Informationen in die Adressbuchdatei im Massenspeicher-Untersystem 116 einzugeben, zu editieren und zu suchen. Wie in den folgenden Abschnitten dieser Anmeldung beschrieben ist, enthält das Adressbuch-Anwenderprogramm 206 einen Universalmanager (GTM), der das Ergänzen weiterer Adressentypen zum Adressbuch-Anwenderprogramm erlaubt.
Das Fax-Anwenderprogramm 201, das Video-Konferenz-Anwenderprogramm 202 und das E-Mail-Anwenderprogramm 204 und jegliche weiteren Klienten-Kommunikationsprogramme rufen jeweils die Adressbuchservices der Adressbuch DLL 210 über das Adressbuch API 220 auf. Das Adressbuch API 220 erlaubt es Klienten- Kommunikations-Anwenderprogrammen auf einzelne Aufzeichnungen in der Adressbuchdatei im Massenspeicher-Untersystem 116 zuzugreifen und sie zu aktualisieren. Außerdem greift das Adressbuch-Anwenderprogramm 206 auf einzelne Aufzeichnungen in der Adressbuchdatei im Massenspeicher 116 über das Adressbuch API 220 zu und aktualisiert sie.
Das Fax-Anwenderprogramm 201, das Video-Konferenz-Anwenderprogramm 202 und das E-Mail-Anwenderprogramm 204 sowie jegliche anderen Klienten-Kommunikationsprogramme rufen jeweils eine Registerfunktion der Adressbuch DLL's 210 auf, um eine entsprechende Rückruffunktion zu registrieren. Die Rückruffunktionen erlauben es der Adressbuch DLL 210 das geeignete Klienten-Kommunikations-Anwenderprogramm der Benutzerwahl zu informieren oder Anrufereignisse in das Adressbuch-Anwenderprogramm 206 einzugeben.
Die Adressbuch-DLL 210 implementiert Wählbenachrichtungsroutinen oder -funktionen, welche die geeigneten Rückruffunktionen des Klienten-Kommunikations-Anwenderprogramms aufrufen. Das Adressbuch-Anwenderprogramm 206 ruft die Wählbenachrichtungsfunktionen über das Adressbuch-Benachrichtungs-API 222 auf, um das geeignete Klienten-Kommunikations-Anwenderprogramm nach einer Benutzerauswahl oder nach Wählen eines Bestimmungsbezeichners im Adressbuch zu informieren.
Beispielsweise registriert das Fax-Anwenderprogramm 201 eine Fax-Rückruffunktion mit der Adressbuch-DLL 210 durch Aufrufen der Registerfunktion der Adressbuch-DLL 210 während des Anwenderprogrammanlaufs. Wenn der Benutzer danach eine Auswahl trifft oder einen Fax-Bestimmungsbezeichner (also eine Fax- Nummer) über die Benutzerinterface-Funktion des Adressbuch- Anwenderprogramms 206 wählt, dann ruft das Adressbuch- Anwenderprogramm 206 die Wählbenachrichtigungsfunktion der Adressbuch-DLL 210 auf. Die Wählbenachrichtungsfunktion in der Adressbuch-DLL 210 ruft dann die Fax-Rückruffunktion im Fax- Anwenderprogramm 201 auf und stellt den ausgewählten oder angewählten Bestimmungsbezeichner aus der Adressbuch-Datei zur Verfügung.
Das Adressbuch-Anwenderprogramm 206 unterhält eine Adressbuch- Informationsdatei 208, welche eine Vorgabeliste vorgegebener Klientenkommunikations-Anwenderprogramme enthält. Die Vorgabeliste spezifiziert ein Vorgabeklientenkommunikations-Anwenderprogramm für jeden eines vorbestimmten Satzes von Kommunikationstypen. Beispielsweise können vorbestimmte Kommunikationstypen Fax-, Video-, Sprach- oder E-Mail-Kommunikationstypen sein.
Beispielsweise spezifiziert die Adressbuch-Informationsdatei 208 das Fax-Anwenderprogramm 201 als Vorgabeklientenkommunikations-Anwendung für den Fax-Kommunikationstyp. Die Adressbuch- Informationsdatei 208 spezifiziert die Videokonferenz-Anwendung 202 als Vorgabeklientenkommunikations-Anwenderprogramm für den Videokommunikationstyp. Die Adressbuch-Informationsdatei 208 spezifiziert das E-Mail-Anwenderprogramm 204 als Vorgabeklientenkommunikations-Anwendung für den E-Mail- Kommunikationstyp.
Wie nachfolgend in weiteren Einzelheiten beschrieben wird, kann der vorbestimmte Satz von Kommunikationstypen durch Verwendung erweiterbarer Merkmale des erfindungsgemäßen Universalmanagers erweitert werden.

Universalmanagement

Es sei nun Fig. 3 betrachtet, welche ein Blockbild einer bevorzugten Universalmanagementarchitektur 3 zeigt, die auf dem Computersystem 100 nach Fig. 1 entsprechend der Erfindung implementiert ist. Wie Fig. 3 zeigt, gibt es zwei Ränge von Anwenderprogrammier-Interface(API) für den Universalmanager (GTM) 310: GTM API 305 und Typmanager AP 325. GTM API 305 wird von den Windows-Anwendungen 301 benutzt, welche das GTM-Untersystem 310 benutzen möchten, um Verbindungsadressentypen zu managen, und kann in ein Adressbuch-Anwenderprogramm eingebaut werden, wie das oben im Zusammenhang mit Fig. 2 beschriebene Adressbuch-Anwenderprogramm 206. Der Zweck dieser erweiterbaren Architektur liegt in der Unterstützung einer nicht begrenzten Serie hinzugefügter Typ-DLL's 320I wobei jede Typ-DLL 320 einen speziellen Verbindungsadressentyp (z. B. LAN-IPX, LAN-TCP/IP, PHONE-ISDN, PHONE-POTS, PHONE-ATT/WORLDWORX, etc.) unterstützt. Diese Adressentypen dienen jeweils einem Konferenzbetrieb oder anderen Kommunikationen über einen gegebenen Kommunikationstransport. Es sei bemerkt, dass dann, wenn ein neuer Verbindungsadressentyp gebildet wird oder verfügbar wird, der sich nicht in dem Satz von Adressentypen befindet, die von dem bestehenden Satz von durch das GTM 310 unterstützten DLL's befindet, eine neue Typ-DLL vom GTM unterstützt werden muss, so dass dieser neue Verbindungsadressentyp für die Anwenderprogramme 310 verfügbar wird. Es können zu irgendeinem Zeitpunkt allgemein N Anwendungen 301I und M Typ-DLL's 320I vorhanden sein. Die Anzahl von Anwendungen 301I und Typ-DLL's 320I lässt sich vergrößern durch Hinzufügen von Anwendungen oder Typ-DLL's zu der erweiterbaren GTM 310 Architektur, wie im einzelnen nachstehend noch beschrieben wird.
Um die einfache Ergänzung einer Unterstützung neuer Adressentypen zu ermöglichen, wird ein standardisierter Typmanager API 325 definiert. Wie sich versteht, ist das GTM 310 selbst eine DLL, auf die von Anwendungen 301I über das GTM API 305 zugegriffen wird. Jegliche neue Typ-DLL 320I, welche das Typmanager API 325 zur Verfügung stellt und sich räumlich im Verzeichnis des GTM 310 befindet, kann gefunden werden und der dynamischen Familie solcher Typ-DLL's zugefügt werden, auf welche die Anwendungen 301I zugreifen können. Jede Typ-DLL 3201 dient somit als ein Typmanager, welcher einen Verbindungsadressentyp unterstützt. Das Typ-Bibliotheksmanager-Untersystem 311 des GTM 310 besorgt dieses Finden und Verfolgen solcher Typ-DLL's. Sobald solche Typ-DLL's identifiziert und geladen sind, kann ein Typ-Bibliotheks-Manager 311 Anforderungen von Anwendungen nach Service an eine geeignete Typ-DLL 3201 schicken. Die Anwendung führt solche Serviceanforderungen unter Verwendung des GTM API 305 durch.
Ein wichtiger Unter-Satz von solchen Services erlaubt dem Endbenutzer Verbindungsadressen in einer Weise zu editieren, die für den Adressentyp einzigartig (unique) sind. Der Typ-Bibliotheksmanager 311 schickt solche Editierserviceanforderungen über ein Adressen-Editier-Manager-Untersystem 312. Dieses Untersystem arbeitet mit spezifischen Typ-DLL's, um die geeigneten Dialogschablonen (als Ressourcen) aus der Bibliotheksdatei der spezifischen Typ-DLL herauszuladen.
Beispielsweise kann die Typ-DLL 3202 Faxnummeradressentypen darstellen. Wenn der Endbenutzer der Anwendung 301I die Änderung einer Typ-DLL 320&sub2;-Verbindungsadresse in einer Verzeichnisdatenbank anfordert, dann führt die Anwendung 301I den geeigneten GTM API-Anruf durch (gtmEditAddress, wie im folgenden noch beschrieben wird). Aufgrund des Verbindungstyps der Adresse schickt das GTM 310 seinerseits diese Anforderung an das richtige Typen-Editier-Untersystem der Typen-DLL (in diesem Falle Typeneditierung 322&sub2;). Andere Unter-Sätze des GTM API 305 befassen sich mit der Bildung, Formatierung und Umwandlung verschiedener Formate für Verbindungsadressen. Diese Dienste werden von dem passenden Typdaten- und Transportmanipulations- Untersystem 321I jeder Typen-DLL 320I durchgeführt. Dieses Untersystem bietet auch Dienste, welche feststellen, ob der Transport für jeden betreffenden Adressentyp "lebendig" ist.
Die Routinen- und Funktionsaufrufe des GTM API 305 und Typmanagers API 325, welche den erfindungsgemäßen Universalmanager 310 beschreiben, werden unten in weiteren Einzelheiten beschrieben.

GTM API-Routinen

Der GTM 310 hat eine Architektur, welche Verbindungsadressen in vereinheitlichter Art unter einer Familie von Anwendungen 301I unterstützt. Die Architektur unterstützt Verbindungsadressen mit mehreren Verwendungen (z. B. Sprache und Video) über mehrere gegenständliche Transportmedien (z. B. Telefon, Netbios). Der GTM 310 unterstützt diese Mehrwegabbildung in einer Weise, die erweiterbar ist und dennoch eine konsolidierte gemeinsame Funktionalität anbietet, welche es den Anwendungen erlaubt, diese Verbindungsinformation zu definieren und auf sie zuzugreifen.
Der GTM 310 kann von einem Adressbuch-Anwenderprogramm, wie das oben beschriebene Adressbuch-Anwenderprogramm 206, benutzt werden und damit ein Teil von ihm werden. Der GTM 310 bietet diejenigen Dienste, welche vom Adressbuch-Anwenderprogramm 206 und anderen Anwendungen 301I wie Konferenz-Anwenderprogramme, benötigt werden, zum Kreieren, Editieren, Darstellen und Etablieren von persönlichen Konferenzverbindungen verschiedener Arten in erweiterbarer Weise. Der gesamte oder ein Teil des GTM 310 kann zukünftig ein Teil einer Konferenzmanagement- Anwendung oder einer Serviceschicht werden.
Bei früheren Adressbuch-Anwenderprogrammen war das Typmanagement statisch mit einer festen Anzahl von Typen und erforderte eine Rekompilierung des Adressbuch-Anwenderprogramms jedes Mal, wenn ein neuer Adressentyp eingeführt wurde. Der GTM 310 bietet Adressbuch-Klientenanwendungen 301I die Möglichkeit, neue Verbindungstypen einzuführen durch Schaffung neuer Typ- DLL's, welche Verbindungsadressen solcher neuen Typen kreieren, editieren und darstellen, und zwar sowohl vom Adressbuch- Anwenderprogramm als auch von der Klientenanwendung 301I oder Konferenzmanager ebenso wie Startanwendungen, um solche Typen zu handhaben. Somit managen die Typen DLL 320I worauf hier hingewiesen sei, das Kreieren, Editieren und Formatieren für Display-Verbindungsadressen des gewünschten Typs.
Das Adressbuch-Anwenderprogramm 206 und das Adressbuch API 220 in Fig. 2 bilden ein gemeinsames Benutzerinterface, Speicherformat und Mittel zum Zugreifen auf eine Datei von Verbindungsadressen für alle Anwendungen, welche Adressbuchservices erfordern. Der GTM 310 weitet dieses Konzept aus durch Trennung von benutzerspezifischen und transportspezifischen Adressenoperationen vom Adressbuch-Anwenderprogramm 206 selbst.
Anwendungen, welche Adressbuchservices erfordern, werden hier als "Klienten-Anwendungen" bezeichnet. Beispiele von Klienten- Anwendungen sind Intel ProShareTM Personal Conferencing-Anwendungen wie ProShare Data Conferencing, ProShare Video Conferencing und ProShare LAN Video Conferencing. Der GTM 310 unterstützt auch Anwendungstypen und Adressentypen, welche durch Anwendungen Dritter definiert sind.

GTM- und Adressbuch-Klienten-Anwandungen

Wie oben erläutert, charakterisieren die Routinen und Funktionsaufrufe des GTM API 305 und des Typmanagers API 325 den GTM 310. Dieser Abschnitt beschreibt die GTM API 305-Routinen und Funktionsaufrufe.
Das Adressbuch-Anwenderprogramm 206, welches hier als ICOMMAB.EXE bezeichnet wird, ist bei einer bevorzugten Ausführungsform eine eigenständige Windows 3.1-Anwendung. Wie verständlich ist, kann es benutzt werden, um Adressbuch- Aufzeichnungen zu ergänzen, zu kreieren oder zu entfernen, Gruppen zu ergänzen, zu kreieren und zu entfernen, Aufzeichnungen nach unterschiedlichen Kriterien anzuschauen usw. Der GTM 310 bildet einen Teil des Adressbuch-API 220.
Der GTM 310 besteht aus dem hier als ICGTM.DLL bezeichneten Typ-Bibliotheksmanager 311 und dem oben beschriebenen Adressen-Editier-Manager 312. Wie verständlich ist, kann der GTM 310 mit einer eingebauten Anzahl von Typ-DLL's versehen werden. Außerdem kann eine andere vom Klienten besorgte Typ DLL 320I vom GTM 310 unterstützt werden, solange sie mit dem Typmanager API 325 zusammenpasst. Bei einer bevorzugten Ausführungsform ist die POTS-Adressen-DLL eine ICHPONE.DLL, und die LAN-Adressen DLL ist eine ICLAN-DLL. Das Adressbuch-Anwenderprogramm 206, die Klienen-Anwendungen 301, und der GTM 310 benutzten sämtlich die Adressbuch-DLL's 210 (ABDLL.DLL). Wie sich weiterhin versteht, kann der Typ-Bibliotheksmanager 311 auch einige mehrfach genutzte Ressourcen enthalten. Bei einer bevorzugten Ausführungsform enthält beispielsweise die ICGTM.DLL Standarddialoge, welche es dem Endbenutzer erlauben, einen Verbindungstransporttyp zu wählen oder eine Verbindungsbenutzung (connection usage) zu wählen. Diese Standardbestandteile werden von Endbenutzern angetroffen, wenn sie für eine Personeneingabe in ein Adressbuch einen neuen Verbindungstyp kreieren oder einen alten editieren.
Eine (nicht dargestellte) Smart-Wähl-DLL kann ebenfalls benutzt werden, welche POTS- und ISDN-Nummern, wie sie in einem Adressbuch gespeichert sind, auf Grundlage einer Ortsbeschreibung in wählbare Nummern umwandeln. Weiterhin können eine Datei (database), Zugriffs-DLL und Datei(file)-Übersetzungs- DLL's, welche nicht dargestellt sind, von dem Adressbuch-Anwenderprogramm 206 und der ABDLL benutzt werden, um Adresseninformation zu speichern, hereinzuholen (Import) und Hinauszubringen (Export).

Spezielle Dienste und Nutzungen

Es folgt eine Beschreibung aller Dienste für Typmanagement, welche vom Adressbuch-Anwenderprogramm 206 für eine Erweiterungstyp-Management-Unterstützung seitens des GTM 310 ausgesondert worden sind. Wo es zweckmäßig ist, werden die Benutzerinterfaceelemente, die Teil der vom Klienten gelieferten Typ-DLL 320I sind, beschrieben, um bei ihrer Erschaffung zu helfen.

Aufruf

Wenn das Adressbuch-Anwenderprogramm 206 gestartet ist, lädt es die GTM DLL 310. Dann ruft es die (unten beschriebene) Routine gtmInitialize auf, damit der Typ-Bibliotheks-Manager 311 erforderliche Initialisierungen durchführen kann. Ehe die Anwendung endet, wird auch gtmTerminate (nachstehend ebenfalls im einzelnen beschrieben) aufgerufen.
Auf alle Routinen, welche von den Typ-DLL's durchgeführt werden können, kann über GTM API 305 zugegriffen werden. Dies ergibt die Möglichkeit eine gegebene DLL 3201 in der Zukunft durch eine Typ-DLL zu ersetzen, welche es möglich macht, dass Klienten- oder Verbindungsmanagement-Anwendungen die verschiedenen Routinen "einhaken" (hook) oder die existierende Funktionalität im Typ-Bibliotheksmanager 311 überspielen, um eine Form von Typ-Unterklassierung zu erlauben.
Es gibt zwei Gründe zu fordern, dass die Typ-DLL's 320I vom Klienten oder Benutzer installiert werden. Erstens brauchen Benutzer nicht mit Verbindungstypen konfrontiert zu werden, für welche sie keine zugehörigen Anwendungen haben, weiterhin wird Durcheinander verringert, Festplattenplatz eingespart und Verwirrung vermieden. Zweitens braucht nicht jede Klientenanwendung 310, welche ein Adressbuch-Anwenderprogramm 206 versendet, nicht mit dessen Installationsprozedur belastet zu werden oder verbraucht Installationsplattenplatz mit Typ- DLL's, welche ohne Belang dafür oder für seine Kunden sind.
Eine mögliche Ausnahme hiervon wäre für einen Unter-Satz der vordefinierten Typen, also solcher, welche automatisch in den GTM 310 inkorporiert sind. Vom Standpunkt des Benutzers kann es beispielsweise erwünscht sein, bequemlichkeitshalber Telefonnummern und Fax-Nummern in Adressbuch-Dateien zu haben, selbst wenn der Benutzer möglicherweise nicht die zugehörigen Telefon- oder Fax-Anwendungen hat, welche diese Typ-DLL's benutzten. Zum Zeitpunkt, wo Benutzer diese Anwendungen kaufen, wären ihre Verbindungsadressen (Telefonnummern) automatisch durch solche Anwendungen nützlich. Weiterhin müsste in diesem Fall der Benutzer nicht notwendigerweise diese Information in einem anderen Adressbuch oder persönlichen Informationsmanager (PIM) vorrätig haben, um sie Online zu halten, gerade weil der Benutzer diese anderen Anwendungen nicht schon hatte.
Wenn jede Typ-DLL 320I geladen wird, wird sie initialisiert durch Aufrufen einer typeInitialize genannten Routine (die noch beschrieben wird). Eine Typ-DLL 320I kann diese Routine benutzen, um jegliche Initialisierung durchzuführen, welche sie benötigt, was unbequem zum Zeitpunkt sein kann, wo LibMain aufgerufen wird. Wie der Fachmann weiß, ist LibMain ein Standardrahmen (fixture) von Windows DLL's, welcher von Windows aufgerufen wird, nachdem die DLL geladen ist.
Obwohl GTM 310 typeInitialize nur einmal aufruft und obwohl seitens des GTM 310 auf alle Typen-DLL's 320I-Routinen zugegriffen werden kann, sollte die spezielle Typ-DLL 320I für den Gebrauch durch verschiedene Anwendungen vorbereitet sein und so geschrieben sein, dass typeInitialize mehrmals aufgerufen werden kann, ehe sie entladen wird. Alle Module, welche diese DLL's laden, müssen sie auch wieder entladen (diese DLL's sind nicht IMPLIBed.) (Wie für den Fachmann verständlich ist, ist IMPLIBed ein Standard-Windows-Aufbauprozess, welcher das Laden einer DLL zur Laufzeit impliziert, im Gegensatz zum expliziten Laden einer DLL, wie es GTM 310 mit den Typ-DLL's macht. Gleichermaßen müssen alle Module, welche typeInitialize aufrufen, typeTerminate aufrufen, ehe die Typ-DLL's entladen werden, so dass sie "aufräumen" (clean up) können. Jedes einmalige Initialisieren und Aufräumen kann in diesen Routinen ebenfalls durch Benutzung eines Zählers erfolgen.

Typenaufzählung

Der Typ-Bibliotheksmanager 311 zählt nicht die existierenden Typen-DLL's 320I-M auf. Er "kennt" die eingebauten Typen-DLL's, welche er unterstützt. Die gtmNewAddress-Funktion wird aufgerufen, damit der Endbenutzer einen physischen Verbindungstransporttyp wählen kann. Dieser zeigt eine Dialogbox mit den verfügbaren Transporttypen und ihren möglichen Benutzungen. Der Aufrufer reicht einen "Griff" (handle) an ein Verbindungsobjekt und der GTM 310 legt die Wahl des Benutzers in diesem Objekt ab.
Jede Typ-DLL 320I hat eine kurze Sequenz (8 Zeichen bei einer bevorzugten Ausführungsform), welche individuell den von der Typ-DLL abgewickelten Verbindungstyp identifiziert und welche in der Adressbuchdatei (d. h. der Adressbuch-Informationsdatei 208 in Fig. 2) mit jeder Verbindungsadresse für diesen Typ aktuell gespeichert ist. Wählt der Benutzer eine Nummer im Adressbuch, um sie zu wählen oder zu editieren, dann erlaubt diese Typinformation, es über den GTM 310 zu bestimmen, welche Typ-DLL 320I zur Durchführung der Operation zu benutzen ist.

Verwendungsaufzählung

Es können mehr als eine Anwendung 301I eine gegebene Verwendung unterstützen. Beispielsweise kann ein Telefonprodukt wie ein einfacher modemgetriebener Sprachwähler (Automatikwähler) und eine andere Anwendung wie ein ProShare-Video, die beide in der Lage sind, sprachgesteuert zu wählen, jeweils dieselbe Verwendung berichten. Speicherbare Verwendungstypsequenzen und die vom Menschen lesbaren Verwendungstypsequenzen werden beide vom GTM 310 selbst aufgefunden. Der GTM 310 "kennt" die verschiedenen Typen und ihre möglichen Benutzungen. Er hat kurze (≤8 Zeichen bei einer bevorzugten Ausführungsform) Verwendungssequenzen, die in der Adressbuch-Datenbank in einer Form zu speichern sind, die mit einer NULL-Trennung/Doppel-NULL (NULL separated/double-NULL) endet. Der GTM 310 bildet diese kurzen Verwendungssequenzen in eine vom Menschen lesbare Form um, die er vor der Schirmdarstellung in seiner Ressource behält. Der GTM 310 stellt auch eine Funktion zur Verfügung, die gtmGet- UseDescription genannt wird (und im einzelnen nachstehend noch erläutert wird), um die kurzen Verwendungssequenzen, welche irgend jemand von der Datei holen könnte, in menschlich lesbare Form zu übersetzen.
Bei einer bevorzugten Ausführungsform kann ICOMM.INI, um Erweiterbarkeit zu erlauben, einen neuen, "Verwendung" genannten Abschnitt haben, der zum Zeitpunkt der Initialisierung gelesen wird und auf den später vom GTM 310 über gtmEnumUses und gtmGetUsageString zugegriffen werden kann. Neue Verwendungen brauchen nur zu ICOMM.INI hinzugefügt zu werden, wenn sie installiert werden.

Beispiele

Es sei nun Fig. 4 betrachtet, welche ein Karteneditier- Dialogfenster 400 zum Editieren von Verbindungsadressen für eine spezifische Eingabe in eine Adressendatei gemäß der Erfindung veranschaulicht. Das Karteneditier-Dialogfenster 400 kann bei einer Anwendung, wie das Adressbuch-Anwendungsprogramm 206, dargestellt werden, welches eine Namen- und Adressendatei managt, die beispielsweise in der Adressbuch- Informationsdatei 208 der Fig. 2 gespeichert ist. Das Karteneditier-Dialogfenster 400 kann vom Adressbuch-Anwenderprogramm 206 dargestellt werden, damit der Benutzer eine spezielle Eingabe in die Datenbank editieren kann, einschließlich Verbindungsadressen und ihre zugehörigen Typen für diese Eingabe, oder neue Eingaben kreieren kann. Wie Fig. 4 zeigt, stellt der Verbindungskasten 404 verschiedene Verbindungen im Verbindungsfeld 403 dar und Auswahlmöglichkeiten wie die Neu-Taste 401 und die Editier-Taste 402. Wenn die gewünschte Verbindung im Feld 403 hervorgehoben wird, dann kann die Editier-Taste 402 betätigt werden.

Kreierung von Verbindungsadressen

In Fig. 6 ist ein neues Dialogfenster 600 zur Schaffung einer neuen Verbindungsadresse entsprechend einer Benutzereingabe dargestellt, welche auf das Karteneditier-Dialogfenster nach Fig. 4 hin eingegeben worden ist. Im einzelnen: Wenn die Neu- Taste 401 gemäß Fig. 4 gewählt wird, dann kann dem Benutzer vom Adressbuch-Anwenderprogramm 206 ein Dialogfenster, wie etwa das neue Dialog-Fenster 600, gezeigt werden. Der Listenkasten 601 enthält eine Liste verschiedener Transporttypen, welche für die hervorgehobene Verbindung im Verbindungsfeld 403 nach Fig. 4 verfügbar sind. Der Check-Kasten 602 enthält eine Liste gewählter Verwendungen, von denen mindestens einige ausgewählt werden können für einen bestimmten Transport, der im Listenkasten 601 gewählt ist. Wie sich versteht, wird jeder Transporttyp des Listenkastens 601 durch eine spezielle Typen- DLL 320v unterstützt. Wenn der Benutzer die Neu-Taste 401 gemäß Fig. 4 aktiviert, dann lässt das Adressbuch-Anwenderprogramm 206 außerdem den GTM gtmNewAdress aufrufen, woraufhin GTM 310 das Dialogfenster 600 zeigt, welches alle Typen und ihre möglichen Verwendungen in Kästen 601 und 602 des neuen Dialogfensters 600 darstellt. Auf diese Weise werden die Listen der im Listenkasten 601 gezeigten Transporte und die im Check- Kasten 602 gezeigten Verwendungen dynamisch bestimmt.
Vom Adressbuch kann der Benutzer somit neue Verbindungsadressen für Individuen in ihren Adressbuch-Dateien kreieren. Der Typ der zu kreierenden Adresse braucht nicht zur Verfügung gestellt zu werden, weil bei einem Aufruf von gtmNewAddress, wie oben erläutert, GTM 310 eine Dialogdarstellung aller Typen und ihre möglichen Benutzungsweisen anbietet, wo der Benutzer eine Auswahl treffen kann. Ist diese Auswahl getroffen, dann ruft der GTM 310 seinerseits die typeNevAdress für den vom Benutzer angegebenen Typ, wodurch ein Dialog mit zu dieser Typen-DLL gehörigen Feldern kreiert wird. Nach dem Schließen dieses Dialogs sorgt die Typen-DLL für die Zuordnung geeigneter Werte im Verbindungsobjekt, und der GTM 310 gibt es zurück an den Benutzer, welcher die gtmNewAdress aufgerufen hat. Der Anrufer ist dann dafür verantwortlich, dass die Verbindung der Adressbuch-Datei übergeben wird.
Auf Wunsch kann der Benutzer auch Kennzeichnungsinformation liefern, um diese Nummer von anderen für dieselbe Person weiter zu unterscheiden. Beispielweise haben die meisten Leute eine Telefonnummer für Anrufe an der Arbeitsstelle und eine andere Telefonnummer für Anrufe zu Hause und die Kennzeichnungen "Büro" und "Wohnung" können beide "POTS"-Telefonnummer- Verbindungen vom "Sprach"-Verwendungstyp beschreiben. Der GTM 310 oder die Typen-DLL ist dafür nicht zuständig. Das Adressbuch-Anwenderprogramm 206 handhabt dies auf einer globalen Ebene auf seiner Editier-Individual-Eingabeebene.

Editieren vonhandener Verbindungsadressen

Es sei nun Fig. 5 betrachtet, welche ein Editier-Dialogfenster 500 zum Editieren einer Telefonverbindungsadresse entsprechend einer Benutzereingabe zeigt, welche auf das Karteneditier- Dialogfenster 400 nach Fig. 4 hin eingegeben worden ist. Im einzelnen: Wenn die Editiertaste 402 gewählt wird, kann dem Benutzer ein Dialogfenster gezeigt werden, wie etwa das Editier-Dialogfenster 500. Wie verständlich ist, können Felder dieser Eingabe vom Benutzer editiert werden.
So kann der Benutzer das Editieren vorhandener Verbindungsadressen wählen. Will er die Information für eine Person editieren, dann kann der Benutzer wählen, dass er eine Verbindungsadresse ändern möchte. Das Adressbuch-Anwenderprogramm 206 ruft das Verbindungsadressen-Editieren über die Routine gtm- EditAdress im Typ-Bibliotheksmanager 311 auf.
Die Argumente für gtmEditAdress geben an, welche Verbindungsadresse zu ändern ist. gtmEditAdress weist den Benutzer nicht für den Typ der Verbindung an. Stattdessen bestimmt es den Typ aus der Verbindung unmittelbar und benutzt dies zum Aufrufen typeEdithddress in der geeigneten Verbindungstyp-DLL 320I. Die Typ-DLL greift auf spezielle Werte im Verbindungsobjekt zu, welche benötigt werden, und bietet diese Information in einem Dialog an. Nachdem der Benutzer die Information verändert hat und auf die OK-Taste drückt, wird nur das Verbindungsobjekt verändert: Die Verbindung wird nicht an die Datei übergeben. Drückt der Benutzer auf "Cancel", dann wird die Aufzeichnung nicht verändert und typeEditAddress kehrt zu ABRC_CANCEL zurück.
Editierdialoge validieren alle Felder vor dem Speichern des Verbindungsobjekts. Wenn eine unvollständige oder falsche Information gegeben wird und der Benutzer die Eingabe akzeptiert (OK drückt), dann wird er über einen Nachrichtenkasten von dem Problem in Kenntnis gesetzt und daran gehindert, aus dem Dialog herauszugehen (außer wenn er das Editieren löscht). Die Benutzereingabemarkierung (z. B. ein blinkender vertikaler Balken, der angibt, wo die Benutzereingabe auf dem Schirm erwartet wird), bleibt in dem fehlerhaften Dialogfeld bestehen, um dem Benutzer bei der Lokalisierung des Problems zu helfen. Wenn das Analysieren von Information bei einer Editierkontrolle das Schließen des Dialogs verhindert, dann verbleibt der Einfügungspunkt an der Stelle, wo die Analyse versagt hat, und der Rest des Feldes wird ausgewählt (hervorgehoben), so dass ein Eintippen der richtigen Information die falsche Information ersetzt. Dieses Verhalten ist ähnlich wie bei anderen Windows-Anwendungen und hilft dem Benutzer, die Editieraufgabe erfolgreich zu Ende zu bringen.
Die Typ-DLL's 320I können dem Benutzer auch andere Hilfestellungen geben, um die Vollendung der Editieraufgabe leichter zu machen. Beispielsweise können sie Buchbinderdienste ausführen oder Server-Nachschlagedienste benennen oder andere Dateiwiedergewinnungsfunktionen, "wizards." oder Validierung, z. B. über "pinging" als Hilfe, um sicherzugehen, dass die Information richtig, aktuell und verfügbar ist. Im Falle einer Telefonnummer-Editierung wird die Nummer in einem separaten statischen Feld gezeigt als wenn sie von der momentanen Stelle aus gewählt würde mit dem momentanen Satz von Wählvorschriften, unter Verwendung eines "Smart Dialing API", wie sich versteht. Wenn die Nummer so zu wählen ist, wie sie ist, oder wenn sie beim Wählen zu überschreiben ist, dann bietet der Dialog ebenso die Fähigkeit, dies wunschgemäß einzustellen.
Schließlich, wie oben unter der Überschrift "Erzeugung von Verbindungsadressen" erwähnt, kann es nützlich sein, es dem Benutzer zu erlauben, andere gültige Benutzungen für die Verbindungsadresse zu spezifizieren/editieren. Beispielsweise kann eine gegebene Netzwerkadresse nützlich sein sowohl für ProShare Data Conferencing wie auch für ProShare Video Conferencing. Wenn der Benutzer weiß, dass die Person, für die er die Adresse eingibt, beide Anwendungen hat, dann kann es wünschenswert sein, diese Information nur einmal dann einzugeben, wenn sie anfänglich eingegeben wird. Dann enthält jede Adresse eine Liste aller "notierten" Verwendungen der gegebenen Adresse. Die von den Verbindungstyp-DLL's 320I zur Verfügung gestellten Dialoge haben eine Taste, um zum "Benutzungen- Wählen"-Dialog zu gelangen (der vom GTM 310 über einen Aufruf an gtmAssignUses (siehe nachfolgende Beschreibung)) angeboten wird. Dies erlaubt es dem Benutzer, die Verwendung für eine spezielle Verbindung während des Editiervorgangs zu ändern (beispielsweise, wenn eine im Adressbuch vorhandene Person, die ursprünglich ProShare Data hatte, ProShare Video installiert, wobei in diesem Fall der Benutzer es wünschen könnte, die Verbindung dieser Person so zu editieren, dass sie zusätzlich zu Data Conferencing auch Video Conferencing hat).
(Es sei darauf hingewiesen, dass es ohne Bedeutung sein kann, ob der Benutzer diese Anwendungen hat, wenn man für den Augenblick außer Acht lässt, dass sie nicht notwendigerweise nützlich sind, außer er oder sie hat sie doch. Die Verwendung Tippen, die den Verbindungsadressen im Adressbuch-Anwenderprogramm 206 zugeordnet ist, bezieht sich stattdessen auf die Möglichkeiten der Person, die der Benutzer über die Adresse im Adressbuch kontaktieren will, d. h. die Möglichkeiten, oder Leistungsfähigkeit, des Eigentümers der Adresse und nicht die Möglichkeiten des die Information eingebenden Benutzers. Bei alternativen Ausführungsformen wären dann, wenn die Benutzer Erlaubnis haben, elektronische "Geschäftskarten" unter Benutzung der Konferenzanwendungen auszutauschen, die Möglichkeiten des Systems des Benutzers wichtig für diesen Austausch. Das Vorhandensein von Typ-DLL's 3201 dient der Informierung von Adressbuch-Anwenderprogramm 206 und Klienten-Anwendungen 3011 selbst ebenso wie als Konferenz-Management-Anwendungen lokaler Möglichkeiten, damit diese in solche elektronischen Geschäftskarten aufgenommen werden können.)
Wenn der Benutzer die gültige Verbindungsadresseninformation in den Dialog eingibt und akzeptiert, dann wird die HAB_CONNECTION-Struktur aus den Editierungen des Benutzers in die Dialogfelder eingesetzt, und ein Wert von ABRC_SUCCESS wird zum GTM zurückgegeben.

Bildschirmdarstellung

Es gibt verschiedene, für eine Adresse spezifische Informationen, welche das Adressbuch-Anwenderprogramm 206 darstellt, wenn es dem Benutzer Adresseninformation zeigt. Hierzu gehören die Adressenbezeichnung ("Ort"), die Verwendung dieser Adresse (ihr Typ) und die Adresse selbst. Eine Adressenlistendarstellung in einer Anwendung kann die Option erlauben, dass für bestimmte Anwendungen der Verwendungstyp durch den Adressentyp ersetzt wird, d. h. es wird die Liste aus dem Inhalt einer Anwendung gezeigt, wo die Verwendung angenommen werden kann.
Die Bezeichnung ist lediglich eine Bequemlichkeit für den Benutzer, und weder das Adressbuch-Anwenderprogramm 206 noch irgendeine andere Anwendung gibt ihr irgendeine semantische Bedeutung, noch liefert sie irgendeine andere Validierung bezüglich des Inhalts dieses Feldes als die Länge. Die Sequenzen, welche für die Adresse dargestellt werden, werden direkt aus der Verbindungsadressenstruktur entnommen. Es wird kein spezielles API im GTM 310 oder in den dem Klienten zur Verfügung gestellten Typ DLL's 320I benötigt.
Der Typ zeigt primär die Vorgabenbenutzung dieser Adresse an, d. h. er impliziert, welche Anwendung aufgerufen werden sollte, um eine Verbindung mit dieser Adresse zu bewerkstelligen. Die festen vordefinierten Typen früherer Ausführungsformen von Adressbuch-Anwenderprogrammen ohne GTM 310 hatten auch feste vordefinierte Sequenzen, welche zur Darstellung dieser Typen benutzt wurden. Diese vordefinierten Typen beinhalten auch den Typ des physischen Mediums, für welche diese Adresse wichtig war. Beispielweise haben Telefonnummern vom Typ Video nicht nur impliziert, dass ProShare Video Conferencing benutzt würde, um eine Adresse mit diesem Typ zu "wählen", sondern implizierten auch, dass es eine ISDN-Adresse anstatt einer POTS- Nummer war.
Der GTM 310 unterscheidet zwischen Verwendung (Anwendungstyp) und Medium (Verbindungstyp). Die vordefinierten Typen bleiben insoweit vordefiniert mit der Art, in der sie Anwendungen spezieller Typen auf den bestimmten physischen Medien zugeordnet sind, aber wenn die Typ-Information dargestellt wird, wird der Unterschied aktuell. Neue Typen, wie Video über das LAN, ISDN- Anrufe u. dgl. werden über die neue GTM 310-Architektur bearbeitet.
Sequenzen, welche Verbindungstypen darstellen, werden zum Adressbuch-Anwenderprogramm 206, seinen Komponenten DLL's und anderen Benutzern des GTM 310 zurückgegeben mit dem Anruf gtmGetTypeDescription. Die Kurztypsequenzen (≤8 Zeichen), welche einen Verbindungstyp individuell identifizieren, werden an gtmGetTypeDescription als Argumente weitergegeben. Anrufe an gtmGetTypeDescription rufen die Routine typeGetString für jeden Typ auf, welcher von jeder Verbindungstyp-DLL geboten wird. Mehrfache Anrufe können durchgeführt werden, wenn eine einzige Typ-DLL 3201 mehrere Typen anbietet. Diese Routinen geben ihre Ergebnisse in einen Argumentpuffer zurück.
Wie oben beschrieben, werden Verwendungssequenzen von Anrufen an gtmGetUseDescription im GTM 310 zurückgegeben, welcher sie durch Schauen auf seine Ressourcen zurückführt.
Schließlich ist das Interessanteste einer adressenspezifischen Information die Adresse selbst. Die verschiedenen Typen von Verbindungsadresseninformation stellen ein größeres Wissen dar als das Adressbuch-Anwenderprogramm 206 hoffen kann zu umfassen. Daher fällt nicht nur das Editieren der Adresseninformation in den Bereich der vom Klienten gelieferten Typ-DLL's 3201 sondern die Aufgabe der Erzeugung darstellbarer Sequenzen, welche diese Information in vom Menschen lesbarer Form für den Benutzer zeigen, fällt ebenfalls in die Verantwortlichkeit dieser Typ-DLL's. Die GTM-Routine gtmFormatAddress gibt einen Puffer an, welcher die darstellbare Adressensequenz zusammen mit der HAB CONNECTION speichert. Der GTM 310 leitet seinerseits diese Anforderung an die typeFormatAddress-Routine der geeigneten Verbindungstyp-DLL weiter.

Funktionen

Im folgenden Abschnitt wird das vom Adressbuch gelieferte GTM AP 305 definiert. Nachfolgende Abschnitte beschreiben das Typmanager-API 325 der vom Klienten gelieferten Typ-DLL's 320I.

Universalmanagement API

Die unten angeführten Routinen werden im Typ-Bibliotheksmanager 311 (ICGTM. DLL) zur Verfügung gestellt. Das Adressbuch-Anwenderprogramm 206 bildet statisch ein Link zum GTM 310 und ruft während der Anwendungsinitialisierung gtmInitialize auf. Zugriff auf die vom Klienten gelieferten Typ-DLL's 320I erfolgt immer über einen Aufruf in den GTM 310 unter Verwendung des GTM API 305. gtmInitialize

Verbindungstyp DLL API

Die unten aufgelisteten Routinen werden in jeder Verbindungstyp-DLL 320I benötigt. "Verbindung" bezieht sich auf die physische Verbindung, beispielsweise eine POTS-Verbindung, eine ISDN-Verbindung oder eine Netzwerkverbindung über irgendeinen Transport wie etwa Netware oder TCP/IP. Solche Verbindungstyp- DLL's werden im Adressbuch-Verzeichnis im Massenspeicher unter System 116 des Benutzers abgelegt, so dass der GTM 310 sie nach Namen finden kann und sie mit der Windows Ladebibliothek API call laden kann. Die Namen der Verbindungstyp-DLL's sollten einen Namen der Form haben < name> .DLL, wobei < name> den Transporttyp impliziert und ein Zusammentreffen mit Namen anderer Modulen unwahrscheinlich ist, die gleichzeitig in Windows geladen werden können, beispielsweise ICISDN.DLL, ICPHONE.DLL, usw. Die Routinen in diesen Typ-DLL's sind nicht dazu bestimmt, unmittelbar von einer Anwendung 301, aufgerufen zu werden, falls die Anwendung für neue Verbindungstypen erweiterbar sein soll. Zugriff zu den Routinen in diesen Typ-DLL's lässt sich erreichen über einen Aufruf in GTM 310, für welchen eine statische Link-Bibliothek existiert. typeInitialize

Beispiel Type Manager API Implementation

Der Fachmann kennt sich mit der Implementierung der oben beschriebenen Funktionen, DLL's und API's aus. Als Beispiel beschreibt der folgende Code ein Implementierungsbeispiel einer Telefon-DLL-Extern-Header-Datei, wie sie für einen Telefongesprächtransport benutzt wird:
Es versteht sich, dass verschiedene Änderungen in Details, Materialien und der Anordnung der Teile, wie sie oben beschrieben und dargestellt sind, um die Natur der Erfindung zu erläutern, vom Fachmann vorgenommen werden können, ohne vom Prinzip und Schutzbereich der Erfindung abzuweichen, wie sie in den beiliegenden Ansprüchen beschrieben ist.

Claims

1. Universalmanager (general type manager) (310) zum managen von Verbindungsadressen und Verbindungstypen eines Computersystems (100), dadurch gekennzeichnet, dass

der Universalmanager (310) ein erstes Interface (305) zur Schnittstellenbildung zwischen dem Universalmanager und einem oder mehreren Anwenderprogrammen (301) des Computersystems (100) bildet,

der Universalmanager (310) geeignet ist zur Durchführung einer Mehrzahl von Universalmanagerfunktionen (gtm), welche von den Anwenderprogrammen aufgerufen werden,

der Universalmanager (310) ein zweites Interface (325) bildet als Interface zwischen dem Universalmanager und einem oder mehreren Typmanagern (320) des Computersystems (100), wobei ein Typmanager mindestens einen Verbindungstyp unterstützt und

jeder Typmanager (320) geeignet ist zur Durchführung einer Mehrzahl von Typfunktionen, welche vom Universalmanager aufgerufen werden entsprechend einer oder mehreren gtm- Funktionen, die von einem Anwenderprogramm (301) aufgerufen werden,

wobei die Mehrzahl von gtm-Funktionen umfasst:

eine erste gtm-Funktion zur Initialisierung des Universalmanagers (310) zur Benutzung,

eine zweite gtm-Funktion zur Vorbereitung des Universalmanagers (310), um entladen (unloaded) zu werden,

eine dritte gtm-Funktion zur Editierung einer Verbindungsadresse entsprechend einem Verbindungstyp der Verbindungsadresse und

eine vierte gtm-Funktion zur Erstellung und Editierung einer neuen Verbindungsadresse eines Verbindungstyps, die von dem einen oder den mehreren Typmanagern (320) unterstützt wird.

2. Universalmanager (310) nach Anspruch 1, bei welchem die Mehrzahl von gtm-Funktionen weiterhin umfassen:

eine fünfte gtm-Funktion zur Formatierung einer Verbindungsadresse für die Bildschirmwiedergabe,

eine sechste gtm-Funktion zur Lieferung einer Beschreibung eines Verbindungstyps und

eine siebte gtm-Funktion zur Lieferung einer Beschreibung eines zu einem gegebenen Verbindungstyp gehörigen Benutzungsparameters.

3. Universalmanager (310) nach Anspruch 2, bei welchem

die erste gtm-Funktion eine gtmInitialize-Funktion ist;

die zweite gtm-Funktion eine gtmTerminate-Funktion ist;

die dritte gtm-Funktion eine gtmEditAddress-Funktion ist;

die vierte gtm-Funktion eine gtmNewAddress-Funktion ist;

die fünfte gtm-Funktion eine gtmFormatAddress-Funktion ist;

die sechste gtm-Funktion eine gtmGetTypeDescription-Funktion ist;

die siebte gtm-Funktion eine gtmGetUseDescription-Funktion ist.

4. Universalmanager (310) nach Anspruch 2, bei welchem die Mehrzahl von Typfunktionen umfasst:

eine erste Typfunktion zur Inititalisierung des Typmanagers (320) zur Benutzung;

eine zweite Typfunktion zur Vorbereitung, des Typmanagers (320), um entladen (unloaded) zu werden;

eine dritte Typfunktion zur Editierung einer Verbindungsadresse entsprechend einem Verbindungstyp der Verbindungsadresse;

eine vierte Typfunktion zur Erstellung einer neuen Verbindungsadresse;

eine fünfte Typfunktion zur Formatierung einer Verbindungsadresse für die Schirmdarstellung, und

eine sechste Typfunktion zur Lieferung einer Beschreibung des Verbindungstyps des Typmanagers (320).

5. Universalmanager nach Anspruch 4, bei welchem jeder Verbindungstyp einem physischen Transporttyp entspricht.

6. Universalmanager nach Anspruch 4, bei welchem das erste und das zweite Interface (310 bzw. 320) Anwenderprogramminterfaces sind.

7. Universalmanager nach Anspruch 4, bei welchem das Computersystem (100) ein Konferenzsystem auf Computerbasis ist.

8. Universalmanager nach Anspruch 4, bei welchem der Universalmanager (310) in einem Adressenbuch-Anwenderprogramm (206) des Computersystems (100) vorgesehen ist.

9. Universalmanager nach Anspruch 4, bei welchem der Universalmanager (310) umfasst:

einen Typ-Bibliotheksmanager (311) zum Managen des einen oder der mehreren Typmanager (320) und Übermittlung von Anrufen seitens des Universalmanagers (310) zum richtigen Typmanager und

einen Adresseneditiermanager (312) zum Managen der Editierung von Adressentypen entsprechend dem Adressentyp,

wobei der eine oder die mehreren Typmanager (320) und der Universalmanager (310) dynamische Link-Bibliotheken sind.

10. Universalmanager (310) nach Anspruch 4, bei welchem

die erste Typfunktion eine Funktion typeInitialize ist,

die zweite Typfunktion eine Funktion typeTerminate ist;

die dritte Typfunktion eine Funktion typeEditAddress ist;

die vierte Typfunktion eine Funktion typeNewAddress ist;

die fünfte Typfunktion eine Funktion typeFormatAddress ist; und

die sechste Typfunktion eine Funktion typeGetString ist.

11. Universalmanager (310) nach Anspruch 10, bei welchem

das Aufrufen der Funktion gtmInitialize den Universalmanager (310) veranlasst, die Funktion typeInitialize eines geeigneten Typmanagers (320) aufzurufen, der entsprechend dem Verbindungstyp einer zugeführten Verbindungsadresse bestimmt wird;

das Aufrufen der Funktion gtmTerminate den Universalmanager (310) veranlasst, die Funktion typTerminate des geeigneten Typmanagers (310) aufzurufen;

das Aufrufen der Funktion gtmEditAddress den Universalmanager (310) veranlasst, die Funktion typeEditAddress des geeigneten Typmanagers (320) aufzurufen;

das Aufrufen der Funktion gtmFormatAddress den Universalmanager (310) veranlasst, die Funktion typeFormatAddress des geeigneten Typmanagers (320) aufzurufen;

das Aufrufen der Funktion gtmNewAddress den Universalmanager (310) veranlasst:

die Funktion typeNewAddress des geeigneten Typmanagers (320) aufzurufen;

ein Dialogfenster zu schaffen zur Darstellung der existierenden Verbindungstypen und

einen spezifizierten Verbindungstyp auf die Eingabe eines Benutzers hin zu bestimmen; und

das Aufrufen der Funktion gtmGetTypeDescription den Universalmanager (310) veranlasst, die Funktion typeGetString des geeigneten Typmanagers (320) aufzurufen, um eine vom Menschen lesbare Textfolge entsprechend dem Verbindungstyp zu schaffen.

12. Universalmanager (310) nach Anspruch 11, bei welchem jeder Verbindungstyp einem physischen Transporttyp entspricht.

13. Universalmanager (310) nach Anspruch 11, bei welchem das ersten und das zweite Interface (305 zw. 325) Anwenderprogramm-Interfaces sind.

14. Universalmanager (310) nach Anspruch 11, bei welchem das Computersystem ein Konferenzsystem auf Computerbasis ist.

15. Universalmanager (310) nach Anspruch 11, bei welchem der Universalmanager in einem Adressbuch-Anwenderprogramm (206) des Computersystems (100) vorgesehen ist.

16. Universalmanager (310) nach Anspruch 11, bei welchem der Universalmanager aufweist:

einen Typ-Bibliotheksmanager (311) zum Managen des einen oder der mehreren Typmanager (320) und zur Weiterleitung von Anrufen seitens des Universalmanagers an den geeigneten Typmanager; und

einen Adressen-Editier-Manager (310) zum Managen der Editierung von Adressentypen entsprechend den Adressentypen;

und wobei der eine oder die mehreren Typmanager (320) und der Universalmanager (310) dynamische Link-Bibliotheken sind.