DE60309576T2

DE60309576T2 - Mobiler zugriff auf LDAP-Server

Info

Publication number: DE60309576T2
Application number: DE60309576T
Authority: DE
Inventors: A. Herbert Waterloo LITTLE; J. Dale Woodstock HOBBS
Original assignee: Research in Motion Ltd
Current assignee: BlackBerry Ltd
Priority date: 2002-03-20
Filing date: 2003-03-20
Publication date: 2007-09-13
Anticipated expiration: 2023-03-21
Also published as: US8943317B2; CN1653783B; EP1488606B1; US20140173277A1; US20050169476A1; US20120265869A1; HK1071648A1; ATE345012T1; DE60309576D1; US20100332824A1; CA2479626C; CN1653783A; US8239675B2; US7822971B2; AU2003213911A1; EP1488606A1; HK1100250A1; CA2479626A1; WO2003079639A1; US8533467B2

Description

HINTERGRUND
1. TECHNISCHES GEBIET
Die vorliegende Erfindung betrifft ein System und ein Verfahren zum Handhaben bzw. Bearbeiten (handling) einer Datenbankdienstanforderung an einen Datenbankserver für einen Datenbankdienst. Insbesondere betrifft das System und das Verfahren das Ermöglichen, dass kryptographische Information, die in Datenbankservern gespeichert ist, an eine mobile Kommunikationsvorrichtung („mobile Vorrichtung") gesendet wird für ein verschlüsseltes Email-Messaging.
2. BESCHREIBUNG DER VERWANDTEN TECHNIK
Eine verschlüsselte Emailnachricht kann eine signierte Nachricht, eine verschlüsselte Nachricht oder eine signierte und verschlüsselte Nachricht sein. Standards, die kryptographisches bzw. verschlüsseltes Messaging unterstützen, umfassen S/MIME (Secure Multipurpose Internet Mail Extensions), PGP^TM (Pretty Good Privacy^TM), OpenPGP und andere sichere Email-Standards und -Protokolle. Kryptographische Information, wie digitale Zertifikate, öffentliche Schlüssel und Ähnliches wird oft in einem Server gespeichert, auf den über ein Netzwerk zugegriffen werden kann, wie ein LDAP(Lightweight Directory Access Protocol)-Server. Wenn eine kryptographische Nachricht von einem Benutzer einer Computervorrichtung zu senden ist, kann die kryptographische Information, wie ein öf fentlicher Schlüssel, welcher der Emailadresse eines Empfängers entspricht, nicht direkt für den Benutzer verfügbar sein. Die kryptographische Information kann stattdessen erlangt werden durch Abfrage des Verzeichnisses eines LDAP-Servers.
Auf einem Desktop-System kann der Sender zum Beispiel ein Browserprogramm verwenden, um eine Multipass- bzw. Mehrfach-Abfrage mit dem LDAP-Server durchzuführen, um eine spezifische kryptographische Information von dem LDAP-Server zu wählen. Einige für einen Desktop-Benutzer verfügbare Aktionen können jedoch für Benutzer mobiler Vorrichtungen nicht verfügbar sein. Ferner können LDAP-Abfragen umfangreiche Antworten auslösen, welche die Speicherkapazität der mobilen Vorrichtung übersteigen sowie die Bandbreitenkapazität eines drahtlosen Netzwerks übersteigen, wenn die mobile Vorrichtung für eine drahtlose Datenkommunikation über das drahtlose Netzwerk konfiguriert ist.
Die europäische Patentanmeldung EP 1 113 648 A3 beschreibt ein System zur Erleichterung einer generischen Registrierung von Ping-ins für einen Verzeichnisserver. Ein LDAP-Proxy wirkt als ein Zwischenstück zwischen einem Client und einem Verzeichnisserver. Der LDAP-Proxy ruft Verfahren von registrierten Anschluss- bzw. Plug-in-Modulen auf, die ein Interesse zeigen an direkten Einträgen, die von einer Client-Anfrage betroffen sind. Das Plug-in-Modul wird mit dem LDAP-Proxy während des Aufbaus bzw. Start-ups oder während einer LDAP-Sitzung registriert und eine Antwortnachricht, die einen Erfolg oder ein Fehlschlagen der Registrierung anzeigt, wird an einen Client gesendet.
Das Dokument XP-002094009 der GloMop Group beschreibt einen Proxy-Server für mobile Computervorrichtungen. Der Proxy-Server liefert eine Destillation eines angeforderten Dokuments und eine inkrementelle Verfeinerung des angeforderten Dokuments.
ZUSAMMENFASSUNG
Ein System zur Handhabung einer LDAP-Abfrage an einen LDAP-Server für einen LDAP-Dienst weist auf ein Client-Programm, das auf einem Client-System ausführbar ist, und ein Handhabungs-Programm, das auf einem Handhabungssystem ausführbar ist. Das Client-Programm ist betriebsfähig, LDAP-Abfragedaten entsprechend dem LDAP-Dienst zu erzeugen und die LDAP-Abfragedaten zur Übertragung von dem Client-System vorzusehen, und ist weiter betriebsfähig, LDAP-Abfrageantwortdaten als Antwort auf die LDAP-Abfragedaten zu empfangen. Das Handhabungsprogramm ist betriebsfähig, die LDAP-Abfragedaten zu empfangen, die von dem Client-System übertragen werden, und die LDAP-Abfrage auf dem LDAP-Server auszuführen, die LDAP-Abfrageantwortdaten von dem LDAP-Server während eines Durchgangs bzw. Durchlaufs oder mehrerer Durchgänge zu empfangen, und bei Beendigung des LDAP-Dienstes die LDAP-Abfrageantwortdaten zur Übertragung an das Client-System in einem einzigen Durchgang bereitzustellen.
Ein Verfahren zur Handhabung einer LDAP-Abfrage an einen LDAP-Server für einen LDAP-Dienst weist die Schritte auf: Empfang von LDAP-Abfragedaten, die von einem Client-System übertragen werden, Ausführen der LDAP-Abfrage an den LDAP-Server auf dem Handhabungssystem, Empfangen der LDAP-Abfrageantwortdaten von dem LDAP-Server während eines Durchgangs oder mehrerer Durchgänge während der Ausführung des LDAP-Dienstes und Übertragen der LDAP-Abfrageantwortdaten, die an dem Handhabungssystem empfangen werden, an das Client-System in einem einzigen Durchgang.
KURZE BESCHREIBUNG DER ZEICHNUNGEN
1A und 1B sehen ein Blockdiagramm eines illustrativen Kommunikationssystems vor, in dem eine LDAP-Dienstanforderung verarbeitet wird;
2 zeigt ein System zur Handhabung einer LDAP-Dienstanforderung an einen LDAP-Server;
3 sieht ein Ablaufdiagramm eines illustrativen Verfahrens zur Handhabung einer LDAP-Dienstanforderung vor;
4 ist ein Blockdiagramm eines illustrativen Client-Systems, das in einem System zur Handhabung einer LDAP-Dienstanforderung verwendet wird, wobei das Client-System eine mobile Vorrichtung aufweist;
5 sieht ein Ablaufdiagramm eines illustrativen Verfahrens für ein LDAP-Client-Abfrage-Verfahren vor;
6 sieht ein Ablaufdiagramm eines illustrativen Verfahrens für ein LDAP-Client-Datensatzempfangsverfahren vor;
7 sieht ein Ablaufdiagramm vor, das einen Prozess der Erzeugung und Ausführung von automatischen LDAP-Server-Abfragen für Datenelemente darstellt, die an eine mobile Vorrichtung um- bzw. weitergeleitet werden sollen;
8 sieht ein funktionales Blockdiagramm vor, das die Handhabung einer Clientinformationsanforderung durch eine Anforderungshandhabungsvorrichtung darstellt, die an einem Handhabungssystem ausgeführt wird; und
9 sieht ein funktionales Blockdiagramm vor, das die Handhabung einer Clientinformationsanforderung durch eine Anforderungshandhabungsvorrichtung darstellt, die an einem Serversystem ausgeführt wird.
DETAILLIERTE BESCHREIBUNG
1A und 1B sehen ein Blockdiagramm eines illustrativen Kommunikationssystems vor, in dem eine LDAP-Dienstanforderung verarbeitet wird. Das Kommunikationssystem weist auf einen Nachrichtenserver 10, das Internet 20, einen LDAP-Server 40, ein drahtloses Gateway 85, eine drahtlose Infrastruktur 90, ein drahtloses Netzwerk 105 und eine mobile Vorrichtung 100. Der LDAP-Server 40 ist illustrativ konfiguriert, eine kryptographische Information vorzusehen, wie ein digitales X.509-Zertifikat 30. Der Nachrichtenserver 10 betreibt ein Nachrichtenserversoftwaremodul, wie einen S/MIME-Server, und ist konfiguriert, S/MIME-Nachrichten, wie die S/MIME-Nachricht 50, zu senden und zu empfangen.
Der Nachrichtenserver 10 kann mit einem Carrier oder einem Internetdiensteanbieter (ISP – internet service provider) verbunden sein. Der Benutzer kann einen Account bzw. ein Konto auf dem Nachrichtenserver 10 haben, so dass der Benutzer elektronische Nachrichten, wie Email und Ähnliches, senden und empfangen kann. Selbstverständlich können die in 1 gezeigten Kommunikationssystemkomponenten alternativ mit einem von dem Internet verschiedenen Weitbereichsnetzwerk (WAN – wide area network) verbunden werden, wie ein Firmen-weites WAN.
Der Nachrichtenserver 10 und der LDAP-Server 40 können auf einem oder mehreren Netzwerkcomputer(n), der/die durch ein Firewall-Programm geschützt ist sind, einem oder mehreren Computer(n) in einem ISP- oder ASP(Application Service Provider)-System oder Ähnliches implementiert werden, und Email- und LDAP-Dienste vorsehen. Server, wie der Nachrichtenserver 10 und der LDAP-Server 40, können auch dynamische Datenbankspeichermaschinen umfassen, die vordefinierte Datenbankformate haben für Kalenderdaten, Aufgabenlisten, Arbeitslisten, Email, Adressen, Dokumentation, und Ähnliches.
Das drahtlose Gateway 85 und die drahtlose Infrastruktur 90 sehen eine Verbindung vor zwischen dem Internet 20 und dem drahtlosen Netzwerk 105 und bilden gemeinsam einen beispielhaften mobilen Informationsübertragungsmechanismus. Die drahtlose Infrastruktur bestimmt das wahrscheinlichste Netzwerk zur Lokalisierung einer bestimmten mobilen Vorrichtung 100 und verfolgt die mobile Vorrichtung 100, wenn sie zwischen Ländern oder Netzwerken roamt.
Das bestimmte drahtlose Netzwerk 105 kann im Grunde jedes drahtlose Netzwerk sein, über das eine Information mit einer mobilen Vorrichtung ausgetauscht werden kann. Zum Beispiel kann das drahtlose Netzwerk ein Daten-zentrisches drahtloses Netzwerk, ein Sprach-zentrisches drahtloses Netzwerk oder ein Dual-Mode-Netzwerk sein, das sowohl Sprach- als auch Datenkommunikationen über dieselben physikalischen Basisstationen unterstützen kann. Beispielhafte kombinierte Dual-Mode-Netzwerke umfassen das CDMA(Code Division Multiple Access)-Netzwerk, das GSM(Groupe Special Mobile oder Global System for Mobile Communications)- und das GPRS(General Packet Radio Service)-Netzwerk und Netzwerke der dritten Generation (3G), wie EDGE (Enhanced Data rates for Global Evolution) und UMTS(Universal Mobile Telecommunications Systems). Beispiele Daten-zentrischer Netzwerke umfassen das Mobitex^TM-Funknetzwerk und das DataTAC^TM-Funknetzwerk. Beispiele Sprach-zentrischer Datennetzwerke umfassen PCS(Personal Communication Systems)-Netzwerke wie CDMA-, GSM- und TDMA(Time Division Multiple Access)-Systeme.
Für jeden Typ eines drahtlosen Netzwerks 105 und den spezifischen Informationsübertragungsmechanismus, der das Weiterleiten und Senden von Datenelementen an die und von der mobilen Vorrichtung 100 steuert, werden Datenelemente, wie Emailnachrichten, über das drahtlose Gateway 85 an die mobile Vorrichtung 100 gesendet. Eine beispielhafte mobile Vorrichtung 100 kann von dem Typ sein, der in dem U.S.-Patent Nr. 6,278,442 mit dem Titel „HAND-HELD ELECTRONIC DEVICE WITH A KEYBOARD OPTIMIZED FOR USE WITH THE THUMBS" offenbart wird. Die Datenelemente können an das drahtlose Gateway 85 über ein Redirector-System 11 gesendet werden, das mit dem Nachrichtenserver 10 in Kommunikation steht. Ein beispielhaftes Um- bzw. Weiterleitungssystem kann von dem Typ sein, der in dem U.S.-Patent Nr. 6,219,694 mit dem Titel „SYSTEM AND METHOD FOR PUSHING INFORMATION FROM A HOST SYSTEM TO A MOBILE DATA COMMUNICATION DEVICE HAVING A SHARED ELECTRONIC ADDRESS" offenbart wird.
Die drahtlose Infrastruktur 90 umfasst eine Serie von Verbindungen zu dem drahtlosen Netzwerk 105. Diese Verbindungen können eine ISDN(Integrated Services Digital Network)-Verbindung, eine „Frame Relay"-Verbindung oder eine T1-Verbindung unter Verwendung des TCP/IP-Protokolls sein.
Wie in 1 gezeigt, sendet die mobile Vorrichtung 100 einen URI (Uniform Resource Identifier) 15 entsprechend einer Ressourcenanforderung von dem LDAP-Server 40. Der URI 15 ist zum Beispiel eine LDAP-Abfrage für ein digitales X.509-Zertifikat 30, das einen öffentlichen Schlüssel 35 enthält. Der öffentliche Schlüssel 35 ist erforderlich, um die Emailnachricht 5 zu verschlüsseln und die S/MIME-Nachricht 50 zu senden. Das drahtlose Gateway 85 empfängt den URI 15 und ein Handhabungsprogramm, das an dem drahtlosen Gateway 85 ausgeführt wird, führt eine herkömmliche LDAP-Abfrage für die mobile Vorrichtung 100 durch. Der URI 15 kommt an dem LDAP-Server 40 an, der wiederum durch Senden einer Multipass-Antwort 25 an den anfordernden Client antwortet. Die Multipass-Antwort 25 kann einen mehrfachen Austausch von Daten während mehreren Durchgängen 27 aufweisen.
Die Multipass-Antwort 25 weist einen normalen Informationsaustausch zwischen dem LDAP-Server 40 und dem Client auf. In diesem bestimmten Ausführungsbeispiel umfasst das drahtlose Gateway 85 ein Handhabungsprogramm, das die LDAP-Abfrage von der mobilen Vorrichtung 100 handhabt. Somit ist der anfordernde Client das drahtlose Gateway 85. Herkömmliche LDAP-Kommunikationstechniken werden zwischen dem drahtlosen Gateway 85 und dem LDAP-Server 40 verwendet.
Wie gezeigt, wird ein Informationsabruf über eine Abfrage durchgeführt, die über den URI 15 an den LDAP-Server 40 gerichtet ist. Der LDAP-Server 40 sendet die Antwort 25, die alle Ergebnisse oder Fehler umfasst, direkt an den anfordernden Client zurück, der die Abfrage über den URI 15 übertragen hat, wobei es sich in diesem Ausführungsbeispiel um das drahtlose Gateway 85 handelt. Typischerweise antwortet der LDAP-Server 30 in mehreren Durchgängen 27.
Obwohl der LDAP-Server 40 Antworten zurücksenden muss, wenn derartige Antworten definiert sind, müssen der LDAP-Server 40 und das drahtlose Gateway 85, das als ein LDAP-Client funktioniert, nicht synchron kommunizieren. Dies führt dazu, dass die Multipass-Antwort 25 „schwatzhaft (chatty)" ist und dies nicht förderlich ist zur Durchführung einer LDAP-Abfrage mit der mobilen Vorrichtung 100 als dem LDAP-Client, da das drahtlose Netzwerk 105 und die HF- Verbindung 107 eine relativ begrenzte Bandbreite und eine hohe Latenzzeit im Vergleich zu dem Internet 20 haben.
Der LDAP-Server 40 liefert einen Verzeichnisdienst über das Internet 20, wodurch Information, wie Email-Adressen, eine Kontaktinformation und eine kryptographische Information, abgerufen werden kann. Ein Beispiel einer derartigen Information ist ein digitales Zertifikat 30 mit einem öffentlichen Schlüssel 35, der über eine Abfrage von einem Verzeichnisinformationsbaum (DIT – Directory Information Tree) abgerufen werden kann, der von einem oder mehreren LDAP-Server(n) 40 und 41 bedient wird. Ferner kann, da ein DIT zusammen von einem oder mehreren LDAP-Server(n) 40 und 41 vorgesehen werden kann, der LDAP-Server 40 auf den URI 15 mit einem Verweis-URI 16 antworten, der an den LDAP-Server 41 gerichtet ist. Der LDAP-Server 41 gibt eine Antwort 26 an das drahtlose Gateway 85 aus, das als der LDAP-Client auf eine analoge Weise arbeitet, wie wenn der LDAP-Server 40 auf den URI 15 antwortet, d.h. die Antwort 26 kann mehrere Durchgänge 28 aufweisen. Dieser Verweis kann den LDAP-Austausch noch „schwatzhafter" machen.
Das drahtlose Gateway 85 empfängt die URI-Abfrage 15 von der mobilen Vorrichtung 100, führt die Abfrage im Namen der mobilen Vorrichtung 100 durch und antwortet der mobilen Vorrichtung 100 mit einer Kommunikation in einem Durchgang. Zumindest ein Teilsatz der Information, die an dem drahtlosen Gateway 85 in der herkömmlichen LDAP-Mehrfach-Antwort 25 empfangen wird, wird in der Antwort in einem Durchgang 45 an die mobile Vorrichtung 100 gesendet und geliefert. Da die Kommunikation des drahtlosen Netzwerks 105 über die HF-Verbindung 107 typischerweise eine hohe Latenzzeit hat im Vergleich zu einer Kommunikation über das Internet 20, nutzt die Einfach-Antwort 45 die Ressourcen zur Übertragung über eine HF-Verbindung 107 und das drahtlose Netzwerk 105 besser aus. Somit schützt das drahtlose Gateway 85 das drahtlose Netzwerk 105 von der „schwatzhaften" Eigenschaft von herkömmlichen LDAP- Kommunikationen durch Durchführen der herkömmlichen LDAP-Abfrage im Namen der mobilen Vorrichtung 100.
In dem Fall eines kryptographischen Verzeichnisdienstes wird der LDAP-Server 40 verwendet, um ein digitales Zertifikat 30 mit einem öffentlichen Schlüssel 35 zu erlangen, der zur Verschlüsselung einer Email-Nachricht 5 erforderlich ist. Unterschiedliche kryptographische Standards können in dem Kommunikationssystem verwendet werden, was dazu führt, dass unterschiedliche Typen von kryptographischer Information empfangen werden. Zum Beispiel kann in dem Fall der kryptographischen X.509-Information der LDAP-Server 30 ein oder mehrere Attribut(e) vorsehen, wie „userCetificate", „cACertificate", „authorityRevokation-List", „certificateRevocationList", „crossCertificatePair", „supportedAlgorithms" und „deltaRevocationList".
Die Daten werden normalerweise über das drahtlose Netzwerk 105 in binärer Form übertragen und die Antwort an den URI 15 kann eine relativ große Menge von Daten aufweisen. Zum Beispiel kann eine Abfrage für ein digitales Zertifikat 30 mit einem langen Zertifizierungspfad eine Antwort liefern, welche die Zertifikate der Zertifizierungsautorität (CA – certification authority) umfasst, die von mehreren Autoritäten bis hinauf zu einer Root-CA signiert sind, oder es kann mehr als ein Zertifikat zurückgesendet werden. Deswegen kann zusätzlich dazu, dass die von dem drahtlosen Gateway 85 empfangene herkömmliche LDAP-Antwort 25 „schwatzhaft" ist, die Antwort 25 auch zu groß sein für die relativ begrenzte Bandbreite des drahtlosen Netzwerks 85. Ferner können, wenn die mobile Vorrichtung 100 einen begrenzten Speicher hat, die Daten der Antwort 25 auch die begrenzte Kapazität des Speichers der mobilen Vorrichtung 100 übersteigen.
Somit kann die Einfach-Antwort 25 auch „gedrosselt (throttled)" und komprimiert sein, um die geringe Bandbreite des drahtlosen Netzwerks 105 und der HF-Verbindung 107 zu kompensieren. Demgemäß schützt das drahtlose Gateway 85 das drahtlose Netzwerk 105 und die HF-Schnittstelle 107 vor einer Antwort des LDAP-Servers, die eine große Menge an Daten aufweist.
Somit empfängt, wenn das drahtlose Gateway 85 eine URI-Abfrage 15 bezüglich kryptographischer Information im Namen der mobilen Vorrichtung 100 sendet, die mobile Vorrichtung 100 die gedrosselte und komprimierte Antwort 45 in einem Durchgang, was geeignet ist für das drahtlose Netzwerk 105 und die HF-Verbindung 107 mit geringer Bandbreite und hoher Latenzzeit. Die mobile Vorrichtung 100 kann somit die Email-Nachricht 5 verschlüsseln und kann somit eine kryptographische Nachricht 50 unter Verwendung von kryptographischer Information senden, die über das drahtlose Netzwerk 105 und die HF-Verbindung 107 erlangt wurde.
2 zeigt detaillierter ein System zur Handhabung einer LDAP-Dienstanforderung an einen LDAP-Server. Die mobile Vorrichtung 100 ist konfiguriert, ein LDAP-Client-Softwaremodul 200 und ein Email-Client-Softwaremodul 300 mit einem kryptographischen Verarbeitungsblock 350 zu betreiben. Das drahtlose Gateway 85 ist konfiguriert, ein LDAP-Handhabungs-Softwaremodul 400 und ein mobiles Email-Agent-Softwaremodul 500 zu betreiben. Das Nachrichtenserversystem 10 ist konfiguriert, ein Nachrichtenserver-Softwaremodul 700 zu betreiben, wie eine S/MIME-Server-Software. Das LDAP-Serversystem 40 ist konfiguriert, ein LDAP-Server-Softwaremodul 600 zu betreiben.
Das Nachrichtenserversystem 10, das LDAP-Serversystem 40 und das drahtlose Gateway 85 können implementiert werden auf jeder einer Vielzahl von Compu tervorrichtungen, wie ein Computer mit einem oder mehreren Prozessor(en), einem Speicherteilsystem und einer oder mehreren Netzwerkschnittstellenkarte(n), die konfiguriert ist/sind, über die in 1 dargestellten Netzwerke zu kommunizieren. Eine beispielhafte mobile Vorrichtung ist wie oben beschrieben und wie weiter im Folgenden unter Bezugnahme auf 4 beschrieben wird.
Ein Benutzer der mobilen Vorrichtung 100 kann eine Emailnachricht 5 erstellen, darauf antworten oder diese weiterleiten an einen anderen Benutzer mit einem Account auf dem Nachrichtenserversystem 10. Die Emailnachricht 5 muss in eine S/MIME-Nachricht 50 gemäß dem S/MIME-Standard verschlüsselt werden. Jedoch erfordert der Krypto-Block 350 zumindest einen öffentlichen Schlüssel 35, der einem privaten Schlüssel des Empfängers der Emailnachricht 5 entspricht. Der öffentliche Schlüssel 35 ist jedoch nicht in einem Speicher der mobilen Vorrichtung 100 gespeichert und somit muss der Benutzer der mobilen Vorrichtung 100 eine Abfrage an einen LDAP-Server 40 senden, um den öffentlichen Schlüssel 35 zu erlangen.
Der Email-Client 300 liefert eine Email-Adresse 7 oder alternativ einen gängigen Namen oder eine andere Benutzerinformation, die dem/den vorgesehenen Empfänger(n) der Emailnachricht 5 entspricht, an den LDAP-Client 200, der wiederum einen URI 15 formuliert, der das digitale Zertifikat 30 anfordert, das dem Empfänger entspricht. Der URI 15 wird an das drahtlose Gateway 85 übertragen und die LDAP-Handhabungssoftware 400 führt die LDAP-Abfrage an den LDAP-Server 40 aus. Die LDAP-Serversoftware 600 empfängt den URI 15 und liefert die Mehrfach-Antwort 25, die das digitale Zertifikat 30 enthält, zurück an das drahtlose Gateway 85. Bei Abschluss der LDAP-Abfrage überträgt das drahtlose Gateway 85 das digitale Zertifikat 30 an die mobile Vorrichtung 100 in einem einzigen Durchgang.
3 sieht ein Ablaufdiagramm eines illustrativen Verfahrens 800 zur Handhabung einer LDAP-Dienstanforderung vor. In Schritt 810 empfängt die mobile Vorrichtung 100 einen Auslöser für ein Ereignis, das eine LDAP-Verzeichnisinformation erfordert. Der Auslöser in dem unter Bezugnahme auf 1 und 2 beschriebenen beispielhaften Ausführungsbeispiel ist ein Verschlüsselungsbefehl, um eine Emailnachricht 5 zu verschlüsseln. Wie oben beschrieben, erfordert die Verschlüsselungsoperation den öffentlichen Schlüssel 35 des digitalen Zertifikats 30, das an dem LDAP-Server 40 gespeichert ist. Selbstverständlich können auch andere Ereignisse verwendet werden, um andere LDAP-Dienste auszulösen, wie Akquirieren einer Emailadresse, Kontaktinformation oder andere Daten, die in dem LDAP-Server 40 gespeichert sind.
In Schritt 815 wird eine URI-Abfrage erzeugt. Die Abfrage ist illustrativ eine standardmäßige URI-Abfrage. Der URI kann bekannte LDAP-Daten umfassen, wie das Protokoll-Präfix „ldap://"; einen Domain-Namen-Host, wie den Domain-Namen für eine Root-CA., wie „directory.ldap40.com" entsprechend der Internetadresse des LDAP-Servers 40; eine optionale Anschlussnummer, über die ein Datenstrom initiiert wird, wie der standardmäßige Anschluss „:389", und optionale Basisabfrage-DN, gefolgt von anderen bekannten LDAP-Abfrageparametern. Somit wäre ein beispielhafter URI, der von der mobilen Vorrichtung 100 erzeugt wird, „ldap://directory.ldap40.com:389/{optionale Parameter}".
In Schritt 820 wird die URI 15-Abfrage an die LDAP-Handhabungsvorrichtung 400 an dem drahtlosen Gateway 85 gesendet. Es ist anzumerken, dass die URI 15-Abfrage nicht direkt an die Internetadresse gesendet wird, die dem Domain-Namen „directory.ldap40.com" entspricht, sondern stattdessen an das drahtlose Gateway 85 gesendet wird zur weiteren Verarbeitung durch die LDAP-Handhabungssoftware 400. Dies kann zum Beispiel erreicht werden durch Senden der URI 15-Abfrage als Nutzdaten in einer Kommunikation, die an das drahtlose Gateway 85 gerichtet ist. Andere Verfahren zum Richten der URI 15-Abfrage an die LDAP-Handhabungssoftware 400 an dem drahtlosen Gateway 85 können ebenso verwendet werden.
In Schritt 825 wird die URI 15-Abfrage durch die LDAP-Handhabungsvorrichtung 400 im Namen einer mobilen Vorrichtung 100 an einen LDAP-Server 40 gesendet. Somit wird, sobald die LDAP-Handhabungsvorrichtung 400 die URI 15-Abfrage empfängt, die URI 15-Abfrage an die Internetadresse gesendet, die dem Domain-Namen in dem URI 15 entspricht. Weiter wird in diesem Beispiel die URI 15-Abfrage an die Internetadresse gesendet, die „directory.ldap40.com" entspricht. In diesem Schritt funktioniert die LDAP-Handhabungsvorrichtung 400 als ein herkömmlicher LDAP-Client, um das drahtlose Netzwerk 85 und die HF-Verbindung 107 vor der „schwatzhaften" und voluminösen LDAP-Kommunikation zu schützen.
In Schritt 830 wird zumindest eine Mehrfach-Antwon 45 an der LDAP-Handhabungsvorrichtung 400 empfangen. Die LDAP-Handhabungsvorrichtung 400 funktioniert weiterhin als ein herkömmlicher LDAP-Client, bis die Antwort empfangen wird, an diesem Punkt kann der nächste Schritt 835 beginnen, dann kann die LDAP-Handhabungsvorrichtung auch als ein optimierter LDAP-Server hinsichtlich der mobilen Vorrichtung 100 funktionieren.
In Schritt 835 wird eine Antwort in einem Durchgang mit zumindest einem Teil der zumindest einen Mehrfach-Antwort des Schritts 830 erzeugt. Durch Erzeugen der Antwort 45 in einem Durchgang auf die URI 15-Abfrage schützt die LDAP-Handhabungsvorrichtung 400 die mobile Vorrichtung 100 vor der „schwatzhaften" LDAP-Kommunikation.
Der Schritt 840 stellt fest, ob die Antwort 45 in einem Durchgang zu groß ist für die begrenzte Bandbreite des drahtlosen Netzwerks 105 und der HF-Verbindung 107 oder für die begrenzte Speicherfähigkeit der mobilen Vorrichtung 100. Es müssen nicht alle mehrfachen Durchgänge 27 empfangen werden, um diese Feststellung zu treffen. Zum Beispiel können die Schritte 830, 835 und 840 zusammenarbeiten und die empfangenen LDAP-Daten und die erzeugte Antwort in einem Durchgang überwachen. Dann kann, wenn eine URI 15-Abfrage normalerweise eine Antwort in mehreren Durchgängen mit 100 Datensätzen erzeugen würde, der Schritt 840 bestimmen, dass die Antwort zu groß ist, nachdem eine Schwelle, wie eine Schwellenanzahl von Datensätzen, empfangen wurde. Die Bestimmung kann somit gemacht werden, bevor die 100 Datensätze der Antwort in mehreren Durchgängen vollständig empfangen wurden in Schritt 830.
Wenn festgestellt wird, dass die Antwort zu groß ist, dann folgt der Schritt 845; ansonsten folgt der Schritt 850.
In Schritt 845 wird die Antwort 45 in einem Durchgang gedrosselt (throttled). Ein Drosseln begrenzt die Daten, die an die mobile Vorrichtung 100 übertragen werden. Wenn zum Beispiel eine Schwellenanzahl von empfangenen Datensätzen überschritten wird, dann kann die LDAP-Handhabungsvorrichtung 400 die Datensätze löschen, die nachfolgend nach Empfang des Schwellendatensatzes empfangen werden. Weiter können zusätzliche Verfeinerungsdaten an die gespeicherten Datensätze angehängt werden. Bei Empfang der gedrosselten Antwort in einem Durchgang kann die LDAP-Handhabungsvorrichtung 400, die in der mobilen Vorrichtung 100 arbeitet, den mobilen Benutzer anweisen, die URI-Abfrage zu verfeinern, um nachfolgende oder alternative Datensätze zu empfangen.
In Schritt 850 wird die Antwort in einem Durchgang komprimiert. Die Antwort in einem Durchgang ist für eine Komprimierung geeigneter, da Datenpakete in ei nem Durchgang dazu neigen, voller zu sein als Pakete in mehreren Durchgängen – und somit wahrscheinlicher Redundanzen haben, die zum Beispiel durch eine Lauflängencodierung (run length encoding) oder andere bekannte Codierungsschemen komprimiert werden können.
In Schritt 860 wird die Antwort in einem Durchgang an die mobile Vorrichtung 100 gesendet und in Schritt 860 wird die Antwort in einem Durchgang an der mobilen Vorrichtung 100 empfangen. In Schritt 865 wird die Antwort in einem Durchgang dekomprimiert.
In Schritt 870 wird die LDAP-Verzeichnisinformation aus der Antwort in einem Durchgang extrahiert. Für die mobile Vorrichtung 100 ist nachfolgend die angeforderte Information verfügbar, die an dem LDAP-Server 40 gespeichert war.
In Schritt 875 stellt die mobile Vorrichtung 100 fest, ob die angeforderte LDAP-Verzeichnisinformation, die in Schritt 810 erforderlich ist, in Schritt 870 extrahiert wurde. Wenn die angeforderte LDAP-Verzeichnisinformation vorhanden ist, dann folgt Schritt 885. Wenn die erforderliche Information nicht vorhanden ist, dann folgt der Schritt 880.
In Schritt 880 kann die URI 15-Abfrage verfeinert werden, um nachfolgende Antworten in einem Durchgang weiter zu drosseln oder die Suche an dem LDAP-Server 40 zu verfeinern. Dies kann zum Beispiel wünschenswert sein, wenn ein Datensatz in Schritt 845 in der Antwort in einem Durchgang geliefert wird, der den Benutzer anweist, die URI-Abfrage weiter zu verfeinern, nach dem Abbrechen des Datensatzes in eine Schwellengröße; oder wenn die Antwort in einem Durchgang anzeigt, dass keine Daten, die auf die URI 15-Abfrage reagieren, an dem LDAP-Server 40 verfügbar ist. Wenn der Benutzer der mobilen Vorrichtung 100 die URI-Abfrage verfeinert, dann werden der Schritt 820 und nachfolgende Schritte erneut ausgeführt.
In Schritt 885 wird die Aktion, welche die LDAP-Verzeichnisinformation erfordert, optional ausgeführt. Zum Beispiel kann ein öffentlicher Schlüssel 35 in dem digitalen Zertifikat 30 verwendet werden, die Email 5 in die S/MIME-Email 50 zu verschlüsseln, die dann von der mobilen Vorrichtung 100 gesendet wird. Dem Benutzer kann vorzugsweise eine Option bereitgestellt werden, die Aktion jedoch nicht auszuführen, wie, indem die mobile Vorrichtung 100 eine Benutzeraufforderung an einer E/A-Vorrichtung erzeugt. Zum Beispiel kann der Benutzer aufgefordert werden, die Verschlüsselung der Emailnachricht 5 unter Verwendung des öffentlichen Schlüssels 35 zu bestätigen und/oder die Emailnachricht 5 oder die S/MIME-Email 50 zu senden.
In einem alternativen Ausführungsbeispiel muss der Schritt 810 nicht unbedingt an der mobilen Vorrichtung 100 stattfinden. Zum Beispiel kann das drahtlose Gateway 85 auch eine an die mobile Vorrichtung 100 zu übertragende S/MIME-Nachricht 50 empfangen. Wenn die S/MIME-Nachricht 50, die an die mobile Vorrichtung 100 zu übertragen ist, mit einer digitalen Signatur signiert ist, kann die anstehenden Übertragung ein Auslöseereignis sein, um die LDAP-Handhabungssoftware 400 an dem drahtlosen Gateway 85 zu veranlassen, den LDAP-Server 40 präventiv abzufragen, um das Zertifikat 30 und den öffentlichen Schlüssel 35 für den Signierer der S/MIME-Nachricht sowie Zertifikatswiderrufsverzeichnisse oder andere kryptographische Information zu erlangen, die erforderlich ist, um die S/MIME-Nachricht zu verifizieren. Die kryptographische Information kann dann erlangt werden, bevor die S/MIME-Nachricht 50 an die mobile Vorrichtung 100 übertragen wird, in diesem Fall wird die S/MIME-Nachricht 50 an dem drahtlosen Gateway 85 gespeichert. Die LDAP-Handhabungssoftware 400 kann weiter betriebsfähig sein, die S/MIME-Nachricht 50 zu verwerfen, wenn die Signaturverifizierung fehlschlägt und/oder nicht vertrauenswürdig ist, oder alter nativ das digitale Zertifikat 30 zu übertragen, das mit der S/MIME-Nachricht 50 abgerufen wurde. In einem anderen Ausführungsbeispiel ist das drahtlose Gateway 85 konfiguriert, eine digitale Signatur zu verifizieren und die S/MIME-Nachricht 50 mit einem Verifizierungsergebnis „gültig" oder „ungültig" zu übertragen, wodurch Verarbeitungsressourcen an der mobilen Vorrichtung 100 geschont werden.
In einem weiteren alternativen Ausführungsbeispiel kann das Redirector-System 11 das LDAP-Handhabungsprogramm speichern und ausführen. Wenn die S/MIME-Nachricht 50, die an die mobile Vorrichtung 100 um- bzw. weiterzuleiten ist, mit einer digitalen Signatur signiert ist, kann die anstehende Übertragung ein Auslöseereignis sein, um die LDAP-Handhabungssoftware 400 an dem Redirector-System 11 zu veranlassen, den LDAP-Server 40 präventiv abzufragen, um das Zertifikat 30 und den öffentlichen Schlüssel 35 für den Signierer der S/MIME-Nachricht sowie Zertifikatswiderrufsverzeichnisse oder andere kryptographische Information zu erlangen, die erforderlich ist, um die S/MIME-Nachricht zu verifizieren. Die kryptographische Information kann dann erlangt werden, bevor die S/MIME-Nachricht 50 an die mobile Vorrichtung 100 um- bzw. weitergeleitet wird, in diesem Fall wird die S/MIME-Nachricht an dem Redirector-System 11 gespeichert. Die LDAP-Handhabungssoftware 400 kann weiter betriebsfähig sein, die S/MIME-Nachricht 50 zu verwerfen, wenn die Signaturverifizierung fehlschlägt und/oder nicht vertrauenswürdig ist, oder alternativ das digitale Zertifikat 30 zu übertragen, das mit der S/MIME-Nachricht 50 abgerufen wurde. In einem weiteren Ausführungsbeispiel ist das Redirector-System 11 konfiguriert, eine digitale Signatur zu verifizieren und die S/MIME-Nachricht 50 mit einem Verifizierungsergebnis „gültig" oder „ungültig" zu übertragen, wodurch Verarbeitungsressourcen an der mobilen Vorrichtung 100 geschont werden.
7 sieht ein Ablaufdiagramm 1200 vor, das einen derartigen Prozess der Erzeugung und Ausführung von automatischen LDAP-Serverabfragen für Daten elemente darstellt, die an eine mobile Vorrichtung 100 zu übertragen sind. Der Prozess wird veranschaulichend an dem drahtlosen Gateway 85 auf eine ähnliche Weise ausgeführt, wie oben beschrieben wird. In Schritt 1202 empfängt das drahtlose Gateway 85 ein Datenelement, das an eine mobile Vorrichtung 100 zu übertragen ist. Das Datenelement kann zum Beispiel eine S/MIME-Nachricht 50 sein, einschließlich Verschlüsselungsdaten, wie eine digitale Signatur.
In Schritt 1204 durchsucht das drahtlose Gateway 85 das Datenelement, um festzustellen, ob das Datenelement Verschlüsselungsdaten enthält. Wenn das Datenelement Verschlüsselungsdaten umfasst, wie die digitale Signatur, dann wird der Schritt 1206 durchgeführt; ansonsten wird der Schritt 1220 durchgeführt.
In Schritt 1206 wird eine URI-Abfrage erzeugt und an den LDAP-Server 40 gesendet. Die Abfrage ist illustrativ eine standardmäßige LDAP-Abfrage, wie oben beschrieben. Die Schritte 1208, 1210, 1212, 1214 und 1216 werden dann auf ähnliche Weise durchgeführt wie oben unter Bezugnahme auf die Schritte 830, 835, 840, 845 und 850 von 3 beschrieben wurde. In Schritt 1218 wird die Antwort in einem Durchgang an das Datenelement angehängt. Dann wird der Schritt 1220 ausgeführt und das Datenelement wird an die mobile Vorrichtung 100 gesendet. Da der Schritt 1218 die Antwort in einem Durchgang an das Datenelement anhängt, empfängt die mobile Vorrichtung 100 die gesamte erforderliche kryptographische Information von dem LDAP-Server 40 für die Verifizierung des Datenelements bei anfänglichem Empfang des Datenelements. Somit muss die mobile Vorrichtung 100 keine URI 15-Abfrage erzeugen.
In einem weiteren alternativen Ausführungsbeispiel können andere kryptographische Anwendungen unter Verwendung von SSL (secure socket layer), wie eine Webbrowseranwendung, Server- und/oder Client-Zertifikate erfordern, Zertifikatswiderrufsverzeichnisse und/oder andere kryptographische Information erfor dern. Die Verwendung von SSL kann auch ein Auslöseereignis sein, das auftritt, wenn zum Beispiel der Benutzer der mobilen Vorrichtung 100 auf eine SSL-Seite surft oder diese empfängt (is pushed). Die Verschlüsselungsinformation kann von der mobilen Vorrichtung 100 erlangt werden durch Ausgabe einer URI-Abfrage, wie oben beschrieben, oder kann alternativ von der LDAP-Handhabungsvorrichtung 400 erlangt werden durch Ausgabe der URI-Abfrage, wie oben beschrieben.
In einem weiteren Ausführungsbeispiel sind die Drosselungsschritte und Komprimierungs/Dekomprimierungsschritte optional. Die Verwendung von Komprimierung sowie einer Drosselung ermöglicht, dass das Verfahren auf verschiedene drahtlose Netzwerk/mobile Vorrichtungs-Kombinationen angepasst wird, um sicherzustellen, dass ein akzeptabler Kompromiss erzielt wird zwischen einer Minimierung der HF-Bandbreite durch eine Komprimierung und einer Minimierung der Auswirkung einer zusätzlichen Verarbeitung durch die mobile Vorrichtung durch eine erforderliche Dekomprimierung. Eine Komprimierung und eine Drosselung können optional von einem Benutzer der mobilen Vorrichtung 100 oder von einer Systemverwaltung oder automatisch abhängig von der Größe der Antwort in einem Durchgang aufgerufen werden.
Unter Bezugnahme auf 4 ist ein Blockdiagramm einer beispielhaften drahtlosen Vorrichtung 900 vorgesehen, die verwendet werden kann, um die mobile Vorrichtung 100 zu realisieren. Die drahtlose Vorrichtung 900 ist vorzugsweise eine Zweiweg-Kommunikationsvorrichtung mit zumindest Sprach- und Datenkommunikationsfähigkeiten. Die Vorrichtung hat vorzugsweise die Fähigkeit, mit anderen Computersystemen auf dem Internet zu kommunizieren. Abhängig von der Funktionalität, die von der Vorrichtung vorgesehen ist, kann die Vorrichtung als eine Datenmessagingvorrichtung, ein Zweiweg-Pager, ein zellulares Telefon mit Datenmessagingfähigkeiten, eine drahtlose Internetanwendung oder eine Daten kommunikationsvorrichtung (mit oder ohne Telefonfähigkeiten) bezeichnet werden.
Wenn die Vorrichtung 900 für eine Zweiweg-Kommunikation aktiviert ist, umfasst die Vorrichtung ein Kommunikationsteilsystem 911 mit einem Empfänger 912, einem Sender 914 und zugehörige Komponenten, wie ein oder mehrere Antennenelement(e) 916 und 918, lokale Oszillatoren (LOs) 913 und ein Verarbeitungsmodul, wie einen digitalen Signalprozessor (DSP) 920. Das bestimmte Design des Kommunikationsteilsystems 911 ist abhängig von dem Kommunikationsnetzwerk, in dem die Vorrichtung arbeiten soll. Zum Beispiel kann eine für den nordamerikanischen Markt bestimmte Vorrichtung 900 ein Kommunikationsteilsystem 911 umfassen, das in dem mobilen Mobitex-Kommunikationssystem oder dem mobilen DataTAC-Kommunikationssystem arbeiten soll, während eine Vorrichtung 900, die zur Verwendung in Europa vorgesehen ist, ein GPRS(General Packet Radio Service)-Kommunikationsteilsystem 911 aufweisen kann.
Netzwerkzugangsanforderungen variieren ebenfalls abhängig von dem Typ des Netzwerks 919, wie das drahtlose Netzwerk 105 von 1. Zum Beispiel werden in den Mobitex- und DataTAC-Netzwerken mobile Vorrichtungen, wie 900, in dem Netzwerk registriert unter Verwendung einer eindeutigen PIN (personal identification number), die zu jeder Vorrichtung gehört. In GPRS-Netzwerken gehört jedoch ein Netzwerkzugang zu einem Teilnehmer oder Benutzer einer Vorrichtung 900. Eine GPRS-Vorrichtung erfordert deswegen ein Teilnehmeridentifikationsmodul, im Allgemeinen als eine SIM(subscriber identity module)-Karte bezeichnet, um in einem GPRS-Netzwerk zu arbeiten.
Signale, die von der Antenne 916 über ein Kommunikationsnetzwerk 919 empfangen werden, werden an den Empfänger 912 eingegeben, der so allgemeine Empfängerfunktionen durchführen kann wie Signalverstärkung, Frequenzabwärtswandlung, Filtern, Kanalauswahl und Ähnliches und Analog-Digital-Wandlung. Eine Analog-Digital-Wandlung eines empfangenen Signals ermöglicht, dass komplexere Kommunikationsfunktionen in dem DSP 920 durchgeführt werden können, wie Demodulation und Decodierung. Auf ähnliche Weise werden zu übertragende Signale von dem DSP 920 verarbeitet, einschließlich zum Beispiel Modulation und Codierung, und an den Sender 914 eingegeben zur Digital-Analog-Wandlung, Frequenzaufwärtswandlung, Filterung, Verstärkung und Übertragung über das Kommunikationsnetzwerk 919 über die Antenne 918.
Der DSP 920 verarbeitet nicht nur Kommunikationssignale, sondern sieht auch eine Empfänger- und Sendersteuerung vor. Zum Beispiel können die Verstärkungen, die auf Kommunikationssignale in dem Empfänger 912 und Sender 914 angewendet werden, adaptiv gesteuert werden durch AGC(automatic gain control)-Algorithmen, die in dem DSP 920 implementiert werden.
Die Vorrichtung 900 umfasst vorzugsweise einen Mikroprozessor 938, der den Gesamtbetrieb der Vorrichtung steuert. Kommunikationsfunktionen, einschließlich von zumindest Daten- und Sprachkommunikationen, werden durch das Kommunikationsteilsystem 911 durchgeführt. Der Mikroprozessor 938 interagiert auch mit anderen Vorrichtungsteilsystemen, wie der Anzeige 922, dem Flash-Speicher 924, dem Arbeitsspeicher (RAM – random access memory) 926, den Hilfs-Ein-Ausgabe(E/A)-Teilsystemen 928, dem seriellen Anschluss 930, der Tastatur 932, dem Lautsprecher 934, dem Mikrofon 936, einem Nahbereichskommunikationsteilsystem 940 und allen anderen Vorrichtungs-Teilsystemen, die allgemein mit 942 bezeichnet werden.
Einige der in 4 gezeigten Teilsysteme führen Kommunikations-bezogene Funktionen durch, während andere Teilsysteme „residente" Funktionen oder Funktionen auf den Vorrichtungen vorsehen können. Insbesondere können einige Teilsysteme, wie zum Beispiel die Tastatur 932 und die Anzeige 922, verwendet werden sowohl für Kommunikations-bezogene Funktionen, wie Eingabe einer Textnachricht zur Übertragung über ein Kommunikationsnetzwerk, wie auch für Vorrichtungs-residente Funktionen, wie ein Taschenrechner oder eine Aufgabenliste.
Von dem Mikroprozessor 938 verwendete Betriebssystemsoftware wird vorzugsweise in einem bleibenden (persistent) Speicher gespeichert, wie dem Flash-Speicher 924, der stattdessen ein Festspeicher (ROM – read-only memory) oder ein ähnliches Speicherelement sein kann. Das Betriebssystem, bestimmte Vorrichtungsanwendungen oder Teile davon können temporär in einen flüchtigen Speicher, wie den RAM 926, geladen werden. Empfangene Kommunikationssignale und Datenelemente können ebenfalls in dem RAM 926 gespeichert werden. Der Flash-Speicher 924 umfasst vorzugsweise ein Datenkommunikationsmodul 924B, und, wenn die Vorrichtung 900 für eine Sprachkommunikation aktiviert ist, ein Sprachkommunikationsmodul 924A. Andere Softwaremodule können in anderen Flash-Speichermodulen 924N gespeichert werden, die illustrativ Software für den LDAP-Client 200, den Email-Client 300 und den kryptographischen Block 350 von 2 speichern.
Der Mikroprozessor 938 ermöglicht vorzugsweise zusätzlich zu seinen Betriebssystemfunktionen eine Ausführung von Softwareanwendungen auf der Vorrichtung. Ein vorgegebener Satz von Anwendungen, die grundlegende Vorrichtungsoperationen steuern, einschließlich von zumindest Daten- und Sprachkommunikationsanwendungen zum Beispiel, wird normalerweise auf der Vorrichtung 900 während der Herstellung installiert. Eine bevorzugte Anwendung, die auf die Vorrichtung geladen werden kann, ist eine PIM(personal information manager)-Anwendung, welche die Fähigkeit hat, Datenelemente zu organisieren und zu verwalten, die den Benutzer der Vorrichtung betreffen, wie Email, Kalenderereig nisse, Voicemails, Termine und Aufgabenelemente, aber nicht darauf beschränkt. Selbstverständlich können ein oder mehrere Speicher auf der Vorrichtung verfügbar sein, um eine Speicherung von PIM-Datenelementen auf der Vorrichtung zu erleichtern. Eine derartige PIM-Anwendung hat vorzugsweise die Fähigkeit, Datenelemente über das drahtlose Netzwerk zu senden und zu empfangen. In einem Ausführungsbeispiel sind die PIM-Datenelemente vorzugsweise über das drahtlose Netzwerk nahtlos integriert, synchronisiert und aktualisiert mit den dem Benutzer der Vorrichtung entsprechenden Datenelementen, die in einem Hostcomputersystem gespeichert sind oder zu diesem gehören. Weitere Anwendungen können ebenfalls über das Netzwerk 919, über ein Hilfs-E/A-Teilsystem 928, über den seriellen Anschluss 930, über das Nahbereichs-Kommunikationsteilsystem 940 oder über jedes andere geeignete Teilsystem 942 auf die mobile Vorrichtung 900 geladen werden und von einem Benutzer in dem RAM 926 oder vorzugsweise einem nichtflüchtigen Speicher installiert werden zur Ausführung durch den Mikroprozessor 938. Eine derartige Flexibilität bei der Installation von Anwendungen erhöht die Funktionalität der Vorrichtung und kann verbesserte Funktionen in der Vorrichtung, Kommunikations-bezogene Funktionen oder beides liefern. Zum Beispiel können sichere Kommunikationsanwendungen ermöglichen, dass Funktionen des elektronischen Handels und andere derartige finanzielle Transaktionen unter Verwendung der Vorrichtung 900 durchgeführt werden können.
In einem Datenkommunikationsmodus wird ein empfangenes Signal, wie eine Textnachricht oder eine heruntergeladene Webseite, von dem Kommunikationsteilsystem 911 verarbeitet und an den Mikroprozessor 938 geliefert, der vorzugsweise das empfangene Signal weiter verarbeitet zur Ausgabe an die Anzeige 922 oder alternativ an eine Hilfs-E/A-Vorrichtung 928. Ein Benutzer der Vorrichtung 900 kann auch Datenelemente, wie zum Beispiel Email-Nachrichten, unter Verwendung der Tastatur 932 erstellen, die vorzugsweise eine vollständige alphanumerische Tastatur oder eine Tastatur des Telefontyps ist, in Verbindung mit der Anzeige 922 und möglicherweise einer Hilfs-E/A-Vorrichtung 928. Derartige erstellte Elemente können dann über ein Kommunikationsnetzwerk durch das Kommunikationsteilsystem 911 übertragen werden.
Für eine Sprachkommunikation ist der gesamte Betrieb der Vorrichtung 900 im Wesentlichen ähnlich, außer, dass die empfangenen Signale vorzugsweise an einen Lautsprecher 934 ausgegeben werden und Signale zur Übertragung von einem Mikrofon 936 erzeugt werden. Alternative Sprach- oder Audio-E/A-Teilsysteme, wie ein Aufzeichnungsteilsystem für Sprachnachrichten, können ebenfalls auf der Vorrichtung 900 implementiert werden. Obwohl die Ausgabe der Sprach- oder Audiosignale vorzugsweise primär durch den Lautsprecher 934 erreicht wird, kann auch die Anzeige 922 verwendet werden, um zum Beispiel eine Anzeige der Identität eines anrufenden Teilnehmers, die Dauer eines Sprachanrufs oder andere Sprachanruf-bezogene Information zu liefern.
Der serielle Anschluss 930 wird normalerweise in einer Kommunikationsvorrichtung des PDA(personal digital assistant)-Typs implementiert, für die eine Synchronisierung mit einem Desktopcomputer des Benutzers wünschenswert sein kann, aber eine optionale Vorrichtungskomponente ist. Ein derartiger Anschluss 930 ermöglicht einem Benutzer, über eine externe Vorrichtung oder Softwareanwendung Einstellungen vorzunehmen und würde die Fähigkeiten der Vorrichtung erweitern, indem Information oder Software-Downloads auf die Vorrichtung 900 geliefert werden können anders als über ein drahtloses Kommunikationsnetzwerk. Der alternative Herunterladepfad kann zum Beispiel benutzt werden, um einen Verschlüsselungsschlüssel auf die Vorrichtung zu laden über eine direkte und somit zuverlässige und vertrauenswürdige Verbindung, um somit eine sichere Vorrichtungskommunikation zu ermöglichen.
Ein Nahbereichs-Kommunikationsteilsystem 940 ist eine weitere optionale Komponente, die eine Kommunikation zwischen der Vorrichtung 900 und anderen Systemen oder Vorrichtungen vorsehen kann, wobei es sich nicht unbedingt um ähnliche Vorrichtungen handeln muss. Zum Beispiel kann das Teilsystem 940 eine Infrarot-Vorrichtung und zugehörige Schaltungen und Komponenten oder ein Bluetooth^TM-Kommunikationsmodul umfassen, um eine Kommunikation mit ähnlich aktivierten Systemen und Vorrichtungen vorzusehen.
5 sieht ein Ablaufdiagramm 1000 eines illustrativen Verfahrens für eine LDAP-Client-Abfrage vor, die an der mobilen Vorrichtung 100 ausgeführt wird. In Schritt 1010 wird eine Stromverbindung (stream connection) mit einem LDAP-URI angefordert. Die Anforderung kann von einer Computervorrichtung in Kommunikation mit dem drahtlosen Gateway 85 über ein oder mehrere Netzwerke gesendet werden. In dem Fall des Beispiels des kryptographischen Messagings wird die Anforderung von dem mobilen LDAP-Client 200 gesendet, der auf der mobilen Vorrichtung 100 arbeitet.
In Schritt 1020 wird ein Stromverbindung zu der LDAP-Handhabungsvorrichtung 400 geöffnet. Durch Öffnen dieser Verbindung zu der LDAP-Handhabungsvorrichtung 400 statt zu dem LDAP-Server 40 wird die mobile Vorrichtung 100 vor dem „schwatzhaften" LDAP-Informationsaustausch geschützt.
In Schritt 1030 wird ein Verbindungseingabe- und Verbindungsausgabestrom erlangt. Die LDAP-Handhabungsvorrichtung 400 verwendet den Ausgabestrom, um den URI zu empfangen, der in dem nachfolgenden Schritt gesendet wird, und der LDAP-Client 200 verwendet den Eingabestrom, um Datensätze von der LDAP-Handhabungsvorrichtung 400 in der Antwort in einem Durchgang zu empfangen.
In Schritt 1040 wird der URI an die LDAP-Handhabungsvorrichtung 400 gesendet durch Schreiben des URIs in den Ausgabestrom. Die LDAP-Handhabungsvorrichtung 400 fährt dann fort, die Abfrage in mehreren Durchgängen (Multipass) im Namen bzw. Auftrag der mobilen Vorrichtung 100 durchzuführen und sendet eine gedrosselte, optional komprimierte Antwort in einem Durchgang zurück, wie oben beschrieben.
In Schritt 1050 bestimmt die mobile Vorrichtung 100, ob der Eingabestrom komprimiert ist. Diese Bestimmung kann zum Beispiel durchgeführt werden durch Lesen eines Booleschen Werts aus dem Eingabestrom, der von der LDAP-Handhabungsvorrichtung 400 geschrieben wird, um zu spezifizieren, dass die Option zur Komprimierung gewählt oder nicht gewählt wurde. Wenn eine Komprimierung gewählt ist, folgt der Schritt 1060 vor dem Schritt 1070. Wenn keine Komprimierung gewählt ist, dann folgt der Schritt 1070.
In Schritt 1060 wird ein Dekomprimierungsstrom auf den Eingabestrom angewendet. Die Dekomprimierung kann durch mehrere Verfahren implementiert werden, wie zum Beispiel Leiten des Eingabestroms durch einen Dekomprimierungsstrom und dann Ersetzen des Dekomprimierungsstroms für den Eingabestrom in den nachfolgenden Schritten.
Der Schritt 1070 bestimmt, ob der Eingabestrom Daten empfangen soll. Dies kann erreicht werden entweder durch Empfang einer Header-Datei, welche die Menge an Daten spezifiziert, die über den Eingabestrom zu übertragen ist, oder durch Lesen eines Booleschen Werts aus dem Eingabestrom, der von der LDAP-Handhabungsvorrichtung 400 geschrieben wird, der spezifiziert, dass entweder ein Datensatz bereitsteht oder dass alle Datensätze in der Antwort in einem Durchgang gesendet wurden. Eine Timeout-Bedingung kann weiter sicherstellen, dass die mobile Vorrichtung 100 die Kommunikation nach einem Timeout bzw. Zeitlimit beendet. Wenn eine Eingabe empfangen werden soll, dann folgt der Schritt 1080, wenn andererseits keine Eingabe empfangen werden soll, dann folgt der Schritt 1090.
In Schritt 1080 wird ein Datensatz aus dem Eingabestrom gelesen. Dieser Schritt definiert das Datensatzformat, das in der Antwort in einem Durchgang verwendet wird, das entweder von der mobilen Vorrichtung 100 oder der LDAP-Handhabungsvorrichtung 400 spezifiziert wird. Ein beispielhaftes Ausführungsbeispiel eines Verfahrens zur Ausführung dieses Schrittes wird in 6 dargestellt. Nach Empfang des Datensatzes folgt der Schritt 1070, um sicherzustellen, dass ein einzelner Durchgang verwendet wird.
In Schritt 1090 wird ein Empfangsmittel (Listener) benachrichtigt über den Empfang der LDAP-Verzeichnisinformation. Der Listener ist illustrativ das Email-Client-Programm 300, das auf der mobilen Vorrichtung 100 läuft. Der Listener kann dann automatisch den Empfang weiterer LDAP-Abfragedaten beenden, wenn die erforderliche Information empfangen wurde, oder kann alternativ von dem Benutzer der mobilen Vorrichtung 100 eine weitere Anweisung anfordern.
6 sieht ein Ablaufdiagramm 1100 eines illustrativen Verfahrens für ein LDAP-Client-Datensatzempfangsverfahren vor. Das Verfahren von 6 wird illustrativ verwendet, um einen Datensatz aus dem Eingabeschritt 1080 von 5 zu lesen.
In Schritt 1010 wird eine Anforderung zum Lesen eines Datensatzes empfangen. Der Schritt 1120 bestimmt, ob ein Eingabesignal einen neuen Eintrag an der Eingabe anzeigt. Diese Feststellung kann gemacht werden zum Beispiel durch Lesen eines Booleschen Werts aus der Eingabe, der von der LDAP- Handhabungsvorrichtung 400 geschrieben wurde, der spezifiziert, dass ein neuer Eintrag in dem aktuellen Datensatz ansteht, oder dass der aktuelle Datensatz den aktuellen Eintrag betrifft. Wenn ein neuer Eintrag an der Eingabe ist, dann folgt der Schritt 1130, ansonsten folgt der Schritt 1160.
In Schritt 1130 wird ein neuer Eintrag erzeugt. Der Eintrag weist die empfangenen Attribute des Datensatzes auf.
Der Schritt 1140 bestimmt, ob zumindest ein Eintrag empfangen wurde, d.h. ob der Eintrag alle seine Attribute empfangen hat. Wenn die Feststellung positiv ist, dann folgt der Schritt 1150. Wenn die Feststellung negativ ist, dann folgt der Schritt 1160.
In Schritt 1150 wird der Listener benachrichtigt, dass ein Eintrag empfangen wurde, d.h. alle Eintragsattribute wurden empfangen. Der Listener kann bestimmen, ob der Eintrag die gewünschte LDAP-Verzeichnisinformation ist, und wenn dem so ist, müssen keine zusätzlichen Datensätze empfangen werden und die Kommunikation kann beendet werden. Alternativ kann die mobile Vorrichtung 100 konfiguriert werden, den Benutzer aufzufordern, so dass der Benutzer feststellen kann, ob der Eintrag die gewünschte LDAP-Verzeichnisinformation ist.
Der Schritt 1160 bestimmt, ob die Eingabe ein neues Attribut hat. Diese Feststellung kann gemacht werden zum Beispiel durch Lesen eines Booleschen Werts aus der Eingabe, der von der LDAP-Handhabungsvorrichtung 400 geschrieben wurde, der spezifiziert, dass ein neues Attribut in dem aktuellen Datensatz ansteht. Wenn ein neues Attribut festgestellt wird, dann folgt der Schritt 1170, ansonsten folgt der Schritt 1180, um zu signalisieren, dass ein Datensatz gelesen wurde.
In Schritt 1170 wird ein Attribut aus dem Eingabestrom gelesen und zu einem Eintrag hinzugefügt. Dies kann zum Beispiel erreicht werden durch Lesen des Namens des Attributs aus der Eingabe, die von der LDAP-Handhabungsvorrichtung 400 geschrieben wurde, dann Lesen eines Booleschen Werts aus der eingegebenen Signalisierung, ob das Attribut binär oder Text ist, und Lesen des binären Attributs oder Text-Attributs aus der Eingabe. Das gelesene Attribut wird dann zu dem aktuellen Eintrag hinzugefügt.
Der Schritt 1180 beendet das Datensatzempfangsverfahren und benachrichtigt einen Listener in der mobilen Vorrichtung 100, dass ein Datensatz gelesen wurde.
8 sieht ein funktionales Blockdiagramm 2000 vor, das die Handhabung einer Clientinformationsanforderung durch eine Anforderungshandhabungsvorrichtung darstellt. Die Informationsanforderung ist illustrativ in der Form einer LDAP-Abfrage; jedoch können auch andere Informationsanforderungen von einem System und/oder Verfahren, wie in 8 dargestellt, gehandhabt werden. Ein Clientsystem kann eine Clientinformationsanforderung 2002 haben, von einem externen System bedient zu werden, wie einem LDAP-Server. Die Clientinformationsanforderung 2002 kann eine Anforderung für ein digitales Zertifikat, einen öffentlichen Schlüssel, eine bestimmte Kontaktinformation oder eine andere Informationsanforderung haben. Die Clientinformationsanforderung 2002 soll in einer Kommunikation in einem Durchgang vorgesehen werden.
Das Clientsystem gibt eine Anforderung aus, die Clientinformationsanforderung 2002 an ein Handhabungssystem zu liefern, das ein Anforderungshandhabungsprogramm 2004 ausführt. Das Anforderungshandhabungsprogramm 2004 handhabt die „Clientinformationsanforderung 2002"-Anforderung für das Clientsystem und stellt eine Kommunikation mit einem Serversystem oder einer anderen Computervorrichtung her, die ein Anforderungsserverprogramm 2006 ausführt, das auf die Clientinformationsanforderung 2002 antwortet. Das Anforderungshandhabungsprogramm 2004 empfängt und überwacht die Multipass-Kommunikation von dem Serversystem und bestimmt, ob die von dem Serversystem empfangenen Daten eine Schwellenanforderung des Clientsystems überschreiten, wie Größe oder Zahl der Datensätze. Wenn die Daten die Schwellenanforderung des Clientsystems überschreiten, dann verwendet das Anforderungshandhabungsprogramm 2004 eine Drosselung 2008, um die empfangenen Daten bis zu der Schwellenanforderung an das Clientsystem zu übertragen in einer Antwortkommunikation in einem Durchgang. Wenn die Daten die Schwellenanforderung des Clientsystems nicht überschreiten, dann überträgt das Anforderungshandhabungsprogramm 2004 die empfangenen Daten an das Clientsystem in einer Antwortkommunikation in einem Durchgang.
Die Drosselung 2008 drosselt illustrativ die empfangenen Daten durch Begrenzen der Antwortkommunikation in einem Durchgang auf eine gedrosselte Antwort 2010. Die gedrosselte Antwort 2010 muss nicht alle Daten umfassen, die in der Multipass-Kommunikation von dem Server empfangen wurden, wie dargestellt wird durch die gedrosselte Antwort 2010, die an einem Punkt in der Multipass-Kommunikation beginnt.
Die gedrosselte Antwort 2010 kann durch mehrere Verfahren erzeugt werden. In einem Ausführungsbeispiel kann das Anforderungshandhabungsprogramm 2004 die gesamte Multipass-Kommunikation empfangen und die empfangenen Daten in dem Handhabungssystem speichern. Das Anforderungshandhabungsprogramm 2004 kann dann bestimmen, ob die empfangenen Daten die Schwellenanforderung des Clientsystems überschreiten. Wenn die empfangenen Daten die Schwellenanforderung des Clientsystems überschreiten, dann wählt das Anforderungshandhabungsprogramm 2004 einen Teilsatz der empfangenen Daten aus und sendet den Datenteilsatz an das Clientsystem. Das Anforderungshandhabungsprogramm 2004 kann optional Verfeinerungsdaten aufnehmen, um das Clientsystem aufzufordern, die Införmationsanforderung zu verfeinern, oder das Clientsystem auffordern, den Empfang der zusätzlichen Daten zu bestätigen, die in der Multipass-Antwort empfangen wurden, aber nicht an das Clientsystem gesendet wurden.
In einem weiteren Ausführungsbeispiel überwacht das Anforderungshandhabungsprogramm 2004 die Multipass-Kommunikation, um zu bestimmen, ob die empfangenen Daten die Schwellenanforderung des Clientsystems überschreiten. Wenn die empfangenen Daten die Schwellenanforderung des Clientsystems überschreiten, dann beendet das Anforderungshandhabungsprogramm 2004 die Multipass-Kommunikation und sendet die empfangenen Daten an das Clientsystem. Das Anforderungshandhabungsprogramm 2004 kann optional Verfeinerungsdaten aufnehmen, um das Clientsystem aufzufordern, die Informationsanforderung zu verfeinern. Selbstverständlich können andere Verfahren zur Drosselung der Multipass-Kommunikation ebenfalls verwendet werden.
Während die LDAP-Handhabungsvorrichtung 400 beschrieben wurde als ein Softwareprogramm, das auf dem drahtlosen Gateway 85 ausgeführt wird, kann die LDAP-Handhabungsvorrichtung 400 auch ein Softwareprogramm sein, das auf dem LDAP-Server 40 ausgeführt wird. Zum Beispiel kann auf die LDAP-Handhabungsvorrichtung 400 zugegriffen werden über einen alternativen Anschluss auf dem LDAP-Server 40. Der alternative Anschluss kann in dem URI bezeichnet werden und somit kann der URI gewählt werden, entweder eine herkömmliche Multipass-LDAP-Abfrage (z.B. „ldap://...") oder eine LDAP-Abfrage in einem Durchgang (z.B. „mldap://...") zu spezifizieren. Ferner kann eine Multipass-LDAP-Abfrage dann in eine LDAP-Abfrage in einem Durchgang umgewandelt werden durch Modifizieren des URIs, z.B. Hinzufügen eines vorangestellten „m" zu dem URI „ldap://...", um den URI „mldap://..." zu erlangen. Ähnlich kann eine LDAP-Abfrage in einem Durchgang dann in eine Multipass-LDAP-Abfrage umgewandelt werden durch Entfernen des vorangestellten „m", um die URI „ldap://..." zu erlangen.
9 sieht ein funktionales Blockdiagramm vor, das die Handhabung einer Clientinformationsanforderung durch eine Anforderungshandhabungsvorrichtung darstellt, die auf einem Serversystem ausgeführt wird. Die Informationsanforderung ist illustrativ in der Form einer LDAP-Abfrage; jedoch können auch andere Informationsanforderungen von einem System und/oder Verfahren gehandhabt werden, wie in 9 dargestellt. Ein Clientsystem kann eine Clientinformationsanforderung 2102 haben, die von einem externen System bedient wird, wie einem LDAP-Server. Die Clientinformationsanforderung 2102 kann eine Anforderung für ein digitales Zertifikat, einen öffentlichen Schlüssel, eine bestimmte Kontaktinformation oder eine andere Informationsanforderung sein. Die Clientinformationsanforderung 2102 soll in einer Kommunikation in einem Durchgang vorgesehen werden.
Das Clientsystem gibt eine Anforderung aus, um die Clientinformationsanforderung 2102 an eine dazwischenliegende Vorrichtung zu liefern, illustrativ ein Gateway-Programm 2104, das auf dem drahtlosen Gateway 85 ausgeführt wird. Das Gateway-Programm 2104 sendet die Anforderung an ein Handhabungsprogramm 2106, das auf einem LDAP-Server ausgeführt wird. Das Anforderungshandhabungsprogramm 2106 handhabt die Clientinformationsanforderung 2102 für das Gateway-Programm 2104 und kommuniziert mit einem Anforderungsserverprogramm 2110, das auf die Clientinformationsanforderung 2102 antwortet. Das Anforderungshandhabungsprogramm 2106 empfängt und überwacht die Multipass-Kommunikation von dem Anforderungsserverprogramm 2110 und bestimmt, ob die von dem Anforderungsserverprogramm 2110 empfangenen Daten eine Schwellenanforderung des Clientsystems überschreiten, wie Größe oder Zahl der Datensätze.
Die Schwellenanforderung des Clientsystems kann an das Anforderungshandhabungsprogramm 2106 mit der Anforderung geliefert werden, wenn es von dem Gateway-Programm 2104 übertragen wird, oder kann alternativ vorher gespeichert werden und zugänglich sein für das Anforderungshandhabungsprogramm 2106.
Wenn die Daten die Schwellenanforderung des Clientsystems überschreiten, dann verwendet das Anforderungshandhabungsprogramm 2106 eine Drosselung 2108, um die empfangenen Daten bis zu der Schwellenanforderung an das drahtlose Gateway 85 zu übertragen in einer Antwortkommunikation in einem Durchgang. Wenn die Daten die Schwellenanforderung des Clientsystems nicht überschreiten, dann überträgt das Anforderungshandhabungsprogramm 2106 die empfangenen Daten an das drahtlose Gateway 85 in einer Antwortkommunikation in einem Durchgang. Das Gateway-Programm 2104 auf dem drahtlosen Gateway 85 überträgt dann die von dem Handhabungsprogramm 2016 empfangenen Daten an das Clientsystem in einer Kommunikation in einem Durchgang.
Die hier offenbarten Ausführungsbeispiele sind illustrativ und andere Konfigurationen und Kommunikationspfade für Computersysteme, die in einem oder mehreren Netzwerk(en) verteilt sind, welche die Funktionalität des LDAP-Handhabungssystems ermöglichen, wie hier offenbart, können ebenfalls verwendet werden.
Die hier beschriebenen Ausführungsbeispiele sind Beispiele von Strukturen, Systemen oder Verfahren mit Elementen, die Elementen der in den Ansprüchen rezitierten Erfindung entsprechen. Diese geschriebene Beschreibung kann Fachleuten ermöglichen, Ausführungsbeispiele mit alternativen Elementen herzustellen und zu verwenden, die genauso den Elementen der in den Ansprüchen rezitierten Erfindung entsprechen. Der beabsichtigte Umfang der Erfindung umfasst somit an dere Strukturen, Systeme oder Verfahren, die sich nicht von den Ansprüchen unterscheiden.

Claims

System zur Bearbeitung einer Lightweight Directory Access Protocol, LDAP, Anfrage an einen LDAP Server (40, 41) für einen LDAP-Dienst, wobei das System umfasst: ein Client-Programm (200), welche auf einem Client-System (100) ausgeführt wird, wobei das Client-Programm (200) tätig ist, LDAP-Anfrage-Daten, welche sich auf den LDAP-Dienst beziehen, zu erzeugen und die LDAP-Anfrage-Daten für eine Übersendung vom Client-System (100) bereitzustellen, und ferner tätig ist, LDAP-Anfrage-Antwort-Daten als Antwort auf die LDAP-Anfrage-Daten entgegenzunehmen; und ein Steuerungs-Programm (400), welches auf einem Steuerungs-System ausgeführt wird, wobei das Steuerungs-Programm (400) tätig ist, die LDAP-Anfrage-Daten entgegenzunehmen, welche von dem Client-System (100) gesendet wurden, und die LDAP-Anfrage an den LDAP-Server (40, 41) zu tätigen, die LDAP-Anfrage-Antwort-Daten von dem LDAP-Server (40, 41) während eines oder mehrerer Durchläufe entgegenzunehmen, und nach Abschluss des LDAP-Dienstes die LDAP-Anfrage-Antwort-Daten zum Senden an das Client-System (100) in einem einzigen Durchlauf bereitzustellen.
System nach Anspruch 1, wobei das Steuerungs-Programm (400) ferner tätig ist, die LDAP-Anfrage-Antwort-Daten zu drosseln, so dass gedrosselte LDAP-Anfrage-Antwort-Daten erzeugt werden, wenn die LDAP-Anfrage-Antwort-Daten einen Schwellwert überschreiten, und die gedrosselten LDAP-Anfrage-Antwort- Daten zum Senden an das Client-System (100) in einem einzigen Durchlauf bereitzustellen.
System nach Anspruch 2, wobei das Steuerungs-Programm (400) ferner tätig ist, Verfeinerungs-Daten an die gedrosselten LDAP-Anfrage-Antwort-Daten anzufügen.
System nach Anspruch 3, wobei das Client-Programm (200) ferner tätig ist, überarbeitete LDAP-Anfrage-Daten als Antwort auf die Entgegennahme der Verfeinerungs-Daten zu erzeugen und diese überarbeiteten LDAP-Anfrage-Daten zum Senden von dem Client-System (100) bereitzustellen.
System nach Anspruch 4, wobei das Client-System (100) ein Mobilgerät umfasst, welches tätig ist, über ein Funk-Netzwerk (105) zu kommunizieren.
System nach Anspruch 5, wobei die LDAP-Anfrage-Daten einen Uniform Resource Identifier, URI, umfassen.
System nach Anspruch 6, wobei der URI eine LDAP-Anfrage nach einem digitalen Zertifikat umfasst.
System nach Anspruch 7, wobei der URI eine LDAP-Anfrage nach einem öffentlichen Schlüssel umfasst.
System nach Anspruch 3, wobei das Steuerungs-Programm (400) ferner tätig ist, die LDAP-Anfrage-Antwort-Daten und die gedrosselten LDAP-Anfrage-Antwort-Daten vor dem Senden an das Client-System (100) zu komprimieren.
System nach Anspruch 3, wobei die LDAP-Anfrage-Antwort-Daten Datensätze umfassen und der Schwellwert eine Datensatz-Zahl umfasst.
System nach Anspruch 10, wobei die LDAP-Anfrage-Antwort-Daten gedrosselt werden, so dass gedrosselte LDAP-Anfrage-Antwort-Daten erzeugt werden, indem die LDAP-Anfrage-Antwort-Daten auf die Datensatz-Zahl der Datensätze beschränkt werden.
System nach Anspruch 11, wobei die LDAP-Anfrage-Daten eine LDAP-Anfrage nach einem digitalen Zertifikat enthalten.
System nach Anspruch 12, wobei das Steuerungs-Programm (400) ferner tätig ist, die Verfeinerungs-Daten an die gedrosselten LDAP-Anfrage-Antwort-Daten anzufügen und die Verfeinerungs-Daten zum Senden an das Client-System (100) bereitzustellen.
System nach Anspruch 13, wobei das Client-Programm (200) ferner tätig ist, überarbeitete LDAP-Anfrage-Daten in Antwort auf die Entgegennahme der Verfeinerungs-Daten zu erzeugen und die überarbeiteten LDAP-Anfrage-Daten zum Senden von dem Client-System (100) bereitzustellen.
System nach Anspruch 1, wobei die LDAP-Anfrage-Daten eine LDAP-Anfrage nach einem digitalen Zertifikat umfassen und wobei die LDAP-Anfrage-Antwort-Daten digitale Zertifikats-Daten umfassen.
System nach Anspruch 2, wobei das Steuerungs-System tätig ist, ein Daten-Objekt an das Client-System (100) umzuleiten und ein Steuerungs-Programm (400) ferner tätig ist, zu bestimmen, ob das Daten-Objekt Verschlüsselungs-Daten enthält, und nach einer Bestimmung, dass das Daten-Objekt Verschlüsselungs-Daten enthält, automatische LDAP-Anfrage-Daten zu erzeugen und eine entsprechende LDAP-Anfrage an den LDAP-Server (40, 41) zu tätigen.
System nach Anspruch 16, wobei das Steuerungs-Programm (400) ferner tätig ist, das Daten-Objekt in dem Steuerungs-System zu speichern, solange die LDAP-Anfrage-Antwort-Daten entgegengenommen werden, und dann das Daten-Objekt und die LDAP-Anfrage-Antwort-Daten oder die gedrosselten LDAP-Anfrage-Antwort-Daten an das Client-System (100) umzuleiten.
System nach Anspruch 17, wobei das Steuerungs-System ein Funk-Gateway (85) ist.
System nach Anspruch 17, wobei das Steuerungs-System ein Redirector-System (11) ist.
Verfahren zur Bearbeitung einer Lightweight Directory Access Protocol, LDAP, Anfrage an einen LDAP-Server (40, 41) für einen LDAP-Dienst, wobei das Verfahren die Schritte umfasst: Entgegennehmen von LDAP-Anfrage-Daten, welche von einem Client-System (100) gesendet worden sind, wobei die LDAP-Anfrage-Daten sich auf die LDAP-Anfrage beziehen; Ausführen der LDAP-Anfrage auf einem Steuerungs-System; Entgegennehmen der LDAP-Anfrage-Antwort-Daten von dem LDAP-Server (40, 41) an dem Steuerungs-System während einer oder mehrerer Durchläufe während der Ausführung des LDAP-Dienstes; und Sender der LDAP-Anfrage-Antwort-Daten, welche an dem Steuerungs-System empfangen worden sind, in einem einzigen Durchlauf an ein Client-System (100).
Verfahren nach Anspruch 20, wobei das Verfahren ferner die Schritte umfasst: Drosseln der LDAP-Anfrage-Antwort-Daten, so dass gedrosselte LDAP-Anfrage-Antwort-Daten erzeugt werden, wenn die LDAP-Anfrage-Antwort-Daten einen Schwellwert überschreiten; und Sender der gedrosselten LDAP-Anfrage-Antwort an das Client-System (100) in einem einzigen Durchlauf.
Verfahren nach Anspruch 21, wobei das Verfahren ferner die Schritte umfasst: Erzeugen von Verfeinerungs-Daten für die gedrosselten LDAP-Anfrage-Antwort-Daten; und Senden der Verfeinerungs-Daten an das Client-System (100).
Verfahren nach Anspruch 22, wobei die LDAP-Anfrage-Daten einen Uniform Resource Identifier, URI, umfassen.
Verfahren nach Anspruch 23, wobei der URI eine LDAP-Anfrage für ein digitales Zertifikat umfasst.
Verfahren nach Anspruch 22, wobei das Verfahren ferner den Schritt des Komprimierens der LDAP-Anfrage-Antwort-Daten und der gedrosselten LDAP-Anfrage-Antwort-Daten vor dem Senden an das Client-System (100) umfasst.
Verfahren nach Anspruch 21, wobei der Schritt des Drosselns der LDAP-Anfrage-Antwort-Daten, um gedrosselte LDAP-Anfrage-Antwort-Daten zu erzeugen, wenn die LDAP-Anfrage-Daten einen Schwellwert überschreiten, die Schritte umfasst: Bestimmen der Menge der entgegengenommenen LDAP-Anfrage-Antwort-Daten; Vergleichen der entgegengenommenen Menge der LDAP-Anfrage-Antwort-Daten mit einem Schwellwert; und Senden nur der Schwellwert-Menge der entgegengenommenen LDAP-Anfrage-Antwort-Daten, wenn die entgegengenommenen LDAP-Anfrage-Antwort-Daten einen Schwellwert überschreiten.
Verfahren nach Anspruch 26, wobei die LDAP-Anfrage-Antwort-Daten digitale Zertifikats-Daten umfassen.
Verfahren nach Anspruch 26, wobei das Verfahren ferner den Schritt des Komprimierens der LDAP-Anfrage-Antwort-Daten und der gedrosselten LDAP-Anfrage-Antwort-Daten vor dem Senden umfasst.