DE602005003220T2

DE602005003220T2 - Vorausladung von Sicherheitsrelevanten Daten in einem Mobilnetzwerk

Info

Publication number: DE602005003220T2
Application number: DE602005003220T
Authority: DE
Inventors: Michael K. Kitchener Brown; Michael S. Waterloo Brown; Michael G. Waterloo Kirkup
Original assignee: Research in Motion Ltd
Current assignee: BlackBerry Ltd
Priority date: 2005-07-29
Filing date: 2005-07-29
Publication date: 2008-09-04
Anticipated expiration: 2025-07-30
Also published as: SG129352A1; CN1905442B; CA2549616A1; EP1748608B1; ATE377891T1; CN1905442A; EP1748608A1; CA2549616C; DE602005003220D1

Description

Ein Teil der Offenbarung dieses Patentdokuments enthält urheberrechtlich geschütztes Material. Der Inhaber des Urheberrechts erhebt keinerlei Einwände gegen die Faksimile-Reproduktion des Patentdokuments oder der Patentoffenbarung, wie sie in der Patentakte oder den Patentunterlagen des Patent- und Warenzeichenamts vorkommen, behält sich aber alle sonstigen Urheberrechte vor.
Die Ausführungsformen der Erfindung beziehen sich allgemeinen auf die Verarbeitung von Nachrichten (z. B. E-Mail-Nachrichten) und insbesondere auf Systeme und Verfahren zum Verarbeiten von Nachrichten, die durch Benutzer von Computergeräten (z. B. Mobilgeräten) verfasst werden.
Per elektronischer Post übertragene Nachrichten (E-Mail-Nachrichten) können allgemein mit einem von mehreren bekannten Protokollen codiert werden, um die sichere Nachrichtenkommunikation zu ermöglichen. Das Protokoll Secure Multiple Internet Mail Extensions ("S/MIME") basiert z. B. auf öffentlichen und privaten Verschlüsselungsschlüsseln, um die Vertraulichkeit und die Integrität zu gewährleisten, und auf einer Public Key Infrastructure (PKI), um Informationen zu kommunizieren, welche die Authentifizierung und Autorisierung ermöglichen. Die mit einem privaten Schlüssel eines Paars aus privatem und öffentlichem Schlüssel verschlüsselten Daten können nur unter Verwendung des entsprechenden öffentlichen Schlüssels des Paars entschlüsselt werden, und die mit einem öffentlichen Schlüssel eines Paar aus privatem und öffentlichem Schlüssel verschlüsselten Daten können nur unter Verwendung des entsprechenden privaten Schlüssels des Paars entschlüsselt werden. In S/MIME kann die Authentizität von öffentlichen Schlüsseln, die zur Codierung von Nachrichten verwendet werden, mithilfe von Zertifikaten überprüft werden. Zur Gewährleistung der sicheren Nachrichtenkommunikation können auch andere bekannte Standards und Proto kolle eingesetzt werden, wozu beispielsweise Pretty Good Privacy^TM (PGP) und Varianten von PGP wie OpenPGP gehören. Es versteht sich, dass verglichen mit S/MIME-basierten Systemen auch PGP-basierte Systeme öffentliche und private Verschlüsselungsschlüssel verwenden, um die Vertraulichkeit und Integrität zu gewährleisten, obwohl die Authentizität der zur Codierung von PGP-Nachrichten verwendeten öffentlichen Schlüssel auf andere Weise überprüft wird als bei S/MIME-Systemen. In solchen anderen Standards und Protokollen zur sicheren Nachrichtenkommunikation können Konstrukte ähnlich einem "Zertifikat" (wie beispielsweise in S/MIME verwendet) bereitgestellt werden, die einen öffentlichen Schlüssel und Informationen zum Schlüsselinhaber bereitstellen. Ein solches Konstrukt ist in PGP-basierten Systemen als "PGP-Schlüssel" bekannt. Für den Zweck dieser Beschreibung und der Patentansprüche, kann der Begriff "Zertifikat" so aufgefasst werden, dass er solche Konstrukte einschließt.
Im Allgemeinen kann es erforderlich sein, vor dem Senden einer neuen E-Mail-Nachricht, die durch einen Benutzer eines Computergeräts verfasst wurde, bestimmte Daten abzurufen, um die Nachricht zu verarbeiten, wozu beispielsweise gehören: (1) Sicherheitsrichtliniendaten, die eine erforderliche Sicherheitscodierung für die Nachricht identifizieren können; (2) Zertifikatdaten, welche typischerweise den öffentlichen Schlüssel eines Zertifikatinhabers sowie andere mit dem Zertifikatinhaber assoziierte Identifikationsinformationen einschließen; und/oder (3) Zertifikatstatusdaten, die zur Verifizierung des Status eines Zertifikats (z. B. ob das Zertifikat widerrufen wurde) verwendet werden können. Während eine E-Mail-Nachricht verfasst wird, befindet sie sich typischerweise in einem dynamischen Status, bis die gesendet wird. Dementsprechend würden die Daten typischerweise erst abgerufen werden, nachdem der Benutzer das Verfassen der E-Mail-Nachricht beendet und das Computergerät angewiesen hat, die Nachricht zu senden (z. B. durch Auswählen einer von der Messaging-Anwendung bereitgestellten Option "Senden"), und sie würden dann für die weitere Verarbeitung der Nachricht verwendet werden, bevor diese gesendet wird. Damit werden unnötige Anforderungen der Daten vermieden, die durchgeführt werden könnten, wenn der Benutzer, der die Nachricht verfasst, sich beispielsweise letztendlich entscheidet, die Nachricht nicht zu senden.
WO05/015867 offenbart ein Verfahren und System zum Behandeln einer zum Senden an einen Empfänger vorgesehenen sicheren Nachricht in einem elektronischen Gerät. Dabei wird auf Daten über einen Sicherheitsschlüssel zugegriffen, der mit dem Empfänger assoziiert ist. Die empfangenen Daten werden verwendet, um eine Gültigkeitsprüfung im Zusammenhang mit dem Senden einer sicheren Nachricht an den Empfänger durchzuführen. Die Gültigkeitsprüfung kann ein Problem aufdecken, das beim Senden einer sicheren Nachricht an diesen Empfänger besteht. Es wird ein Grund für das Problem mit der Gültigkeitsprüfung ermittelt, und dieser Grund wird dem Benutzer des Mobilgeräts bereitgestellt.
Allgemeines
In einem umfassenden Aspekt wird ein Verfahren zum Verarbeiten von Nachrichten bereitgestellt, die durch einen Benutzer eines Computergeräts verfasst werden, wobei die Schritte des Verfahrens durch mindestens eine auf dem Computergerät ausgeführte Anwendung durchgeführt werden und das Verfahren die folgenden Schritte umfasst: das Empfangen einer Anforderung von einem Benutzer zum Verfassen einer Nachricht; das Initiieren der Durchführung von mindestens einem des Folgenden: das Abrufen von Sicherheitsrichtliniendaten aus einer Policy Engine und das Abrufen von Zertifikatdaten aus einem Zertifikatspeicher, die zur weiteren Verarbeitung der Nachricht erforderlich sind; und das Empfangen einer Anweisung von dem Benutzer zum Senden der auf dem Computergerät verfassten Nachricht, wobei der Schritt des Initiierens vor dem Schritt des Empfangens einer Anweisung von dem Benutzer zum Senden der Nachricht durchgeführt wird.
In einem anderen umfassenden Aspekt wird ein Verfahren zum Verarbeiten von Nachrichten bereitgestellt, die durch einen Benutzer eines Computergeräts verfasst werden, wobei das Verfahren des Weiteren die folgenden Schritte umfasst: das weitere Verarbeiten der Nachricht mithilfe der abgerufenen Daten; und das optionale Senden der Nachricht.
Kurze Beschreibung der Zeichnungen
Um ein besseres Verständnis der Ausführungsformen der hier beschriebenen Systeme und Verfahren zu ermöglichen, und um deutlicher zeigen zu können, wie diese in die Praxis umgesetzt werden können, wird anhand von Beispielen Bezug auf die beiliegenden Zeichnungen genommen, welche folgende Bedeutung haben:
1 ist ein Blockdiagramm eines Mobilgeräts in einer exemplarischen Implementierung;
2 ist ein Blockdiagramm einer Kommunikations-Subsystemkomponente des Mobilgeräts aus 1;
3 ist ein Blockdiagramm eines Knotens eines Drahtlosnetzes;
4 ist ein Blockdiagramm zur Darstellung der Komponenten eines Host-Systems in einer exemplarischen Konfiguration;
5A ist ein Flussdiagramm zur Darstellung der Schritte in einem Verfahren zum Verarbeiten von Nachrichten, die durch einen Benutzer eines Mobilgeräts verfasst werden, in einer exemplarischen Ausführungsform; und
5B ist ein Flussdiagramm zur Darstellung der Schritte in einem Verfahren zum Verarbeiten von Nachrichten, die durch einen Benutzer eines Mobilgeräts verfasst werden, in einer anderen exemplarischen Ausführungsform.
Beschreibung bevorzugter Ausführungsformen
Wie im obigen Beispiel beschrieben wurde, würden Daten wie Sicherheitsrichtliniendaten, Zertifikatdaten und/oder Zertifikatstatusdaten allgemein erst abgerufen werden, nachdem der Benutzer das Verfassen einer E-Mail-Nachricht beendet und ein Computergerät angewiesen hat, die Nachricht zu senden, um den Sendeprozess zu aktivieren, und dann für die weitere Verarbeitung der Nachricht verwendet werden. In einem typischen drahtgebundenen Netz ist die Zeit zur vollständigen Durchführung der erforderlichen Anforderungen zum Abrufen solcher Daten typischerweise minimal, weshalb der Prozess der Gewinnung dieser Daten zur Ermöglichung des Sendens der Nachricht für den Benutzer oft transparent ist. In vielen drahtlosen Netzen könnte die Zeit zur Gewinnung der erforderlichen Daten viel länger sein, was in der Wahrnehmung des Benutzers zu einer signifikanten Verzögerung des Sendeprozesses führen würde.
Im Gegensatz zu Systemen nach dem Stand der Technik, bei denen die Initiierung des Abrufen solcher Daten aufgeschoben wird, bis eine Anweisung vom Benutzer zum Senden der Nachricht empfangen wurde, um unnötige Anforderungen für die Daten zu vermeiden, kann es trotzdem wünschenswert sein, eine Technik einzusetzen, bei der Verzögerungen im Sendeprozess, die möglicherweise durch Benutzer bestimmter Computergeräte wie z. B. von Mobilgeräten erlebt werden, minimiert werden, so dass solchen Benutzern der Sendeprozess transparenter erscheint.
Die hier beschriebenen Ausführungsformen beziehen sich allgemein auf Systeme und Verfahren, bei denen die Durchführung von bestimmten Aufgaben initiiert wird, während ein Benutzer eine Nachricht verfasst und bevor eine Anweisung zum Senden der Nachricht vom Benutzer empfangen wird. Das kann beispielsweise das als "Prefetching" bezeichnete Laden von Daten im Voraus umfassen, die wahrscheinlich benötigt werden, um eine Nachricht zu senden, die sich noch im Prozess des Verfassens durch den Benutzer befindet. Das Initiieren der Durchführung solcher Aufgaben im Voraus erhöht allgemein die Wahrscheinlichkeit, dass eine Nachricht aus der Sicht des Benutzers scheinbar schnell gesendet wird, da die zum Abschließen des Sendeprozesses erforderlichen Aufgaben bis zum Zeitpunkt, zu dem die Anweisung vom Benutzer zum Senden der Nachricht empfangen wird, möglicherweise bereits abgeschlossen sind oder zumindest bereits initiiert wurden. Damit kann die Gebrauchsfähigkeit eines Computergeräts erhöht werden, und es kann besonders nützlich sein, wenn es sich bei dem Computergerät um ein Mobilgerät handelt.
In einem umfassenden Aspekt wird ein Verfahren zum Verarbeiten von Nachrichten bereitgestellt, die durch einen Benutzer eines Computergeräts verfasst werden, wobei die Schritte des Verfahrens durch mindestens eine auf dem Computergerät ausgeführte Anwendung durchgeführt werden und das Verfahren die folgenden Schritte umfasst: das Empfangen einer Anforderung von einem Benutzer zum Verfassen einer Nachricht; das Initiieren der Durchführung von mindestens einem des Folgenden: das Abrufen von Sicherheitsrichtliniendaten aus einer Policy Engine und das Abrufen von Zertifikatdaten aus einem Zertifikatspeicher, die zur weiteren Verarbeitung der Nachricht erforderlich sind; und das Empfangen einer Anweisung von dem Benutzer zum Senden der auf dem Computergerät verfassten Nachricht, wobei der Schritt des Initiierens vor dem Schritt des Empfangens einer Anweisung von dem Benutzer zum Senden der Nachricht durchgeführt wird.
In einem anderen umfassenden Aspekt wird ein Verfahren zum Verarbeiten von Nachrichten bereitgestellt, die durch einen Benutzer eines Computergeräts verfasst werden, wobei das Verfahren des Weiteren die folgenden Schritte umfasst: das weitere Verarbeiten der Nachricht mithilfe der abgerufenen Daten; und das optionale Senden der Nachricht.
In mindestens einer Ausführungsform handelt es sich bei dem Computergerät um ein Mobilgerät.
Diese und weitere Aspekte und Merkmale von verschiedenen Ausführungsformen werden im Folgenden detailliert beschrieben.
Einige Ausführungsformen der hier beschriebenen Systeme und Verfahren beziehen sich auf ein Mobilgerät. Ein Mobilgerät ist ein Zweiwege-Kommunikationsgerät mit erweiterten Datenkommunikationsfunktionen, das über die Fähigkeit zur Kommunikation mit anderen Computersystemen verfügt. Ein Mobilgerät kann auch die Fähigkeit zur Sprachkommunikation einschließen. In Abhängigkeit von der von einem Mobilgerät bereitgestellten Funktionalität kann es als Daten-Messaging-Gerät, als Zweiwege-Pager, als Mobiltelefon mit Möglichkeit zum Daten-Messaging, als drahtloses Internet-Gerät oder als Datenkommunikationsgerät (mit und ohne Telefoniefunktion) bezeichnet werden. Ein Mobilgerät kommuniziert mit anderen Geräten über ein Netz aus Sender-Empfänger-Stationen.
Um dem Leser das Verständnis des Aufbaus eines Mobilgeräts und seiner Kommunikation mit anderen Geräten zu erleichtern, wird Bezug auf 1 bis 3 genommen.
Zunächst Bezug nehmend auf 1 ist ein Blockdiagramm eines Mobilgeräts in einer exemplarischen Implementierung gezeigt, das allgemein mit 100 bezeichnet ist. Das Mobilgerät 100 umfasst eine Reihe von Komponenten, wobei der Mikroprozessor 102 die steuernde Komponente ist. Der Mikroprozessor 102 steuert den Gesamtbetrieb des Mobilgeräts 100. Die Kommunikationsfunktionen, einschließlich der Daten- und Sprachkommunikation, werden durch das Kommunikations-Subsystem 104 ausgeführt. Das Kommunikations-Subsystem 104 empfangt Nachrichten von und sendet Nachrichten zu einem Drahtlosnetz 200. In dieser exemplarischen Implementierung des Mobilgeräts 100 ist das Kommunikations-Subsystem 104 gemäß den Standards Global System for Mobile Communication (GSM) und General Packet Radio Services (GPRS) konfiguriert. Das GSM/GPRS-Drahtlosnetz wird weltweit verwendet, und es wird erwartet, dass diese Standards letztendlich durch die Standards Enhanced Data GSM Environment (EDGE) und Universal Mobile Telecommunications Service (UMTS) abgelöst werden. Es werden noch immer neue Standards definiert, es wird jedoch erwartet, dass diese Ähnlichkeiten zum hier beschriebenen Netzverhalten aufweisen werden, und dem Fachmann auf dem Gebiet der Technik wird auch einleuchten, dass die Erfindung zur Verwendung aller anderen geeigneten Standards vorgesehen ist, die in Zukunft entwickelt werden. Die Drahtlosverbindung, die das Kommunikations-Subsystem 104 mit dem Netz 200 verbindet, wird durch einen oder mehrere verschiedene Hochfrequenzkanäle (HF) repräsentiert, die entsprechend definierten Protokollen arbeiten, die für die GSM/GPRS-Kommunikation spezifiziert sind. Bei neueren Netzprotokollen sind diese Kanäle in der Lage, sowohl leitungsvermittelte Sprachkommunikation als auch paketvermittelte Datenkommunikation zu unterstützen.
Obwohl das dem Mobilgerät 100 in einer exemplarischen Implementierung des Mobilgeräts 100 zugeordnete Drahtlosnetz ein GSM/GPRS-Drahtlosnetz ist, kön nen in abweichenden Implementierungen auch andere Drahtlosnetze dem Mobilgerät 100 zugeordnet sein. Zu anderen Typen von Drahtlosnetzen, die verwendet werden können, zählen beispielsweise datenzentrische Drahtlosnetze, sprachzentrische Drahtlosnetze und Dualmodusnetze, die über dieselben physischen Basisstationen sowohl Sprachkommunikation als auch Datenkommunikation unterstützen können. Zu den kombinierten Dualmodusnetzen gehören unter anderem Code Division Multiple Access (CDMA) oder CDMA2000-Netze, GSM/GPRS-Netze (wie oben erwähnt), und zukünftige Netze der dritten Generation (3G) wie EDGE und UMTS. Zu einigen älteren Beispielen für datenzentrische Netze gehören das Mobitex^TM-Funknetz und das DataTAC^TM-Funknetz. Zu einigen älteren Beispielen für sprachzentrische Netze gehören Personal Communications Systems (PCS) Netze wie GSM und Time Division Multiple Access (TDMA) Systeme.
Der Mikroprozessor 102 interagiert auch mit zusätzlichen Subsystemen wie dem Random Access Memory (RAM) 106, dem Flash-Speicher 108, dem Display 110, dem zusätzlichen Eingabe-/Ausgabe-Subsystem (E/A) 112, dem seriellen Port 114, der Tastatur 116, dem Lautsprecher 118, dem Mikrofon 120, einem Nahbereichskommunikations-Subsystem 122 und sonstigen Geräten 124.
Einige der Subsysteme des Mobilgeräts 100 führen kommunikations-bezogene Funktionen aus, während andere Subsysteme für "residente" oder gerätespezifische Funktionen verantwortlich sind. Beispielsweise können das Display 110 und die Tastatur 116 sowohl für kommunikationsbezogene Funktionen wie das Eingeben einer Textnachricht zur Übertragung über das Netz 200 als auch für geräteresidente Funktionen wie ein Kalender oder eine Aufgabenliste verwendet werden. Die vom Mikroprozessor 102 verwendete Betriebssystemsoftware ist typischerweise in einem Dauerspeicher wie einem Flash-Speicher 108 gespeichert, bei dem es sich alternativ auch um einen Festwertspeicher (Read-Only Memory, ROM) oder um ein ähnliches Speicherelement (nicht dargestellt) handeln kann. Dem Fachmann auf dem Gebiet der Technik wird einleuchten, dass das Betriebssystem, spezifische Geräteanwendungen oder Teile davon temporär in einen flüchtigen Speicher wie den RAM 106 geladen werden können.
Das Mobilgerät 100 kann nach Abschluss der erforderlichen Netz-registrierungs- oder -aktivierungsprozeduren Kommunikationssignale über das Netz 200 senden und empfangen. Der Netzzugriff wird einem Teilnehmer oder Benutzer eines Mobilgeräts 100 zugeordnet. Um einen Teilnehmer zu identifizieren, benötigt das Mobilgerät 100 ein Teilnehmeridentitätsmodul (Subscriber Identity Module) oder eine "SIM"-Karte 126, die in eine SIM-Schnittstelle 128 eingelegt wird, damit die Kommunikation mit einem Netz erfolgen kann. Die SIM-Karte 126 entspricht vom Typ her einer konventionellen "SmartCard", die – unter anderem – zur Identifizierung eines Teilnehmers des Mobilgeräts 100 und zur Personalisierung des Mobilgeräts 100 verwendet wird. Ohne die SIM-Karte 126 ist das Mobilgerät 100 nicht voll funktionsfähig für die Kommunikation mit dem Netz 200. Durch Einlegen der SIM-Karte 126 in die SIM-Schnittstelle 128 erhält ein Teilnehmer Zugriff auf alle abonnierten Dienste. Zu diesen Diensten könnten zählen: Webbrowsing und Nachrichtenübertragung wie z. B. per E-Mail, Sprachnachrichten, Short Message Service (SMS) und Multimedia Messaging Services (MMS). Zu weiterentwickelten Diensten können gehören: Point of Sale-, Außendienst- und Sales Force-Automatisierung. Die SIM-Karte 126 enthält einen Prozessor und einen Speicher zum Speichern von Informationen. Sobald die SIM-Karte 126 in die SIM-Schnittstelle 128 eingelegt wird, ist sie mit dem Mikroprozessor 102 gekoppelt. Um den Teilnehmer zu identifizieren, enthält die SIM-Karte 126 einige Benutzerparameter wie z. B. eine International Mobile Subscriber Identity (IMSI). Ein Vorteil in der Verwendung der SIM-Karte 126 besteht darin, dass ein Teilnehmer nicht notwendigerweise an ein einziges physisches Mobilgerät gebunden ist. Die SIM-Karte 126 kann auch zusätzliche Informationen für ein Mobilgerät speichern, beispielsweise Informationen zu Terminen (Kalenderdaten) oder Informationen zu den zuletzt erfolgten Anrufen.
Das Mobilgerät 100 ist ein batteriebetriebenes Gerät und enthält eine Batterieschnittstelle 132 zur Aufnahme von einer oder mehreren wiederaufladbaren Batterien 130. Die Batterieschnittstelle 132 ist an einen Regler (nicht dargestellt) gekoppelt, der die Batterie 130 bei der Bereitstellung des Stroms V+ an das Mobil gerät 100 unterstützt. Obwohl derzeitige Technologien eine Batterie verwenden, können auch zukünftige Technologien wie Mikrobrennstoffzellen den Strom für das Mobilgerät 100 liefern.
Der Mikroprozessor 102 ermöglicht zusätzlich zu seinen Betriebssystemfunktionen die Ausführung von Softwareanwendungen auf dem Mobilgerät 100. Eine Reihe von Anwendungen zur Steuerung der grundlegenden Gerätefunktionen, einschließlich Anwendungen zur Daten- und Sprachkommunikation, sind normalerweise bereits herstellerseitig auf dem Mobilgerät 100 installiert. Eine weitere Anwendung, die auf das Mobilgerät 100 geladen werden könnte, ist ein Personal Information Manager (PIM). Ein PIM verfügt über Funktionen zum Organisieren und Verwalten von Datenobjekten, die für einen Teilnehmer von Interesse sind, was beispielsweise unter anderem E-Mails, Kalenderereignisse, Sprachnachrichten, Termine und Aufgabenobjekte sein können. Eine PIM-Anwendung verfügt über die Fähigkeit zum Senden und Empfangen von Datenobjekten über das Drahtlosnetz 200. Die PIM-Datenobjekte können mit den entsprechenden Datenobjekten des Mobilgerätteilnehmers, die auf einem Host-Computersystem gespeichert und/oder zugeordnet sind, über das Drahtlosnetz 200 nahtlos integriert, synchronisiert und aktualisiert werden. Diese Funktionalität erstellt hinsichtlich dieser Objekte ein gespiegeltes Abbild des Host-Computers auf dem Mobilgerät 100. Das kann insbesondere vorteilhaft sein, wenn es sich beim Host-Computersystem um das Bürocomputersystem des Mobilgerätteilnehmers handelt.
Weitere Anwendungen können auch über das Netz 200, das zusätzliche E/A-Subsystem 112, den seriellen Port 114, das Nahbereichskommunikations-Subsystem 122 oder jedes andere geeignete Subsystem 124 auf das Mobilgerät 100 geladen werden. Diese Flexibilität bei der Anwendungsinstallation erhöht die Funktionalität des Mobilgeräts 100 und kann erweiterte gerätespezifische Funktionen, kommunikationsbezogene Funktionen oder beides ermöglichen. Beispielsweise können über sichere Kommunikationsanwendungen E-Commerce- Funktionen und andere derartige Finanztransaktionen mit dem Mobilgerät 100 ermöglicht werden.
Der serielle Port 114 ermöglicht es einem Teilnehmer, über ein externes Gerät oder eine Softwareanwendung Voreinstellungen festzulegen, und erweitert die Fähigkeiten des Mobilgeräts 100 durch das Bereitstellen von Informationen oder Softwaredownloads zum Mobilgerät 100, die nicht über ein drahtloses Kommunikationsnetz erfolgen. Der alternative Downloadpfad kann beispielsweise verwendet werden, um über eine direkte und damit vertrauenswürdige Verbindung einen Verschlüsselungsschlüssel auf das Mobilgerät 100 zu laden, um eine sichere Gerätekommunikation zu ermöglichen.
Das Nahbereichskommunikations-Subsystem 122 ermöglicht die Kommunikation zwischen dem Mobilgerät 100 und verschiedenen Systemen oder Geräten, ohne dazu das Netz 200 zu verwenden. Beispielsweise kann das Subsystem 122 ein Infrarotgerät sowie die zugehörigen Schaltungen und Komponenten für die Nahbereichskommunikation enthalten. Beispiele für die Nahbereichskommunikation sind die von der Infrared Data Association (IrDA) entwickelten Standards, Bluetooth sowie die Gruppe der von der IEEE entwickelten 802.11-Standards.
Bei der Verwendung wird ein empfangenes Signal wie z. B. eine Textnachricht, eine E-Mail-Nachricht oder ein Webseitendownload durch das Kommunikations-Subsystem 104 verarbeitet und in den Mikroprozessor 102 eingespeist. Der Mikroprozessor 102 verarbeitet dann das empfangene Signal zur Ausgabe an das Display 110 oder alternativ an das zusätzlichen E/A-Subsystem 112. Ein Teilnehmer kann auch Datenobjekte wie beispielsweise E-Mail-Nachrichten erstellen, wozu die Tastatur 116 in Verbindung mit dem Display 110 und möglicherweise das zusätzliche E/A-Subsystem 112 verwendet wird. Das zusätzliche E/A-Subsystem 112 kann Geräte wie die folgenden enthalten: einen Touchscreen, eine Maus, einen Trackball, einen Infrarot-Fingerabdruckleser oder ein Drehrad mit dynamischer Tastendruckfunktion. Bei der Tastatur 116 handelt es sich um eine alphanumerische Tastatur und/oder um ein für Telefone typisches Ziffernfeld. Ein erstelltes Objekt kann durch das Kommunikations-Subsystem 104 über das Netz 200 übertragen werden.
Für die Sprachkommunikation ist der allgemeine Betrieb des Mobilgeräts 100 im Wesentlichen gleich, außer dass die empfangenen Signale zum Lautsprecher 118 ausgegeben würden, und die Signale für die Übertragung würden durch das Mikrofon 120 erzeugt werden. Alternative Sprach- oder Audio-E/A-Subsysteme, wie z. B. ein Aufzeichnungssystem für Sprachnachrichten, können auch auf dem Mobilgerät 100 implementiert sein. Obwohl die Sprach- oder Audiosignalausgabe in erster Linie durch den Lautsprecher 118 erreicht wird, kann auch das Display 110 verwendet werden, um zusätzliche Informationen wie z. B. die Identität des Anrufers, die Dauer eines Sprachanrufs oder andere auf Sprachanrufe bezogene Informationen bereitzustellen.
Nunmehr Bezug nehmend auf 2 wird ein Blockdiagramm der Kommunikations-Subsystemkomponente 104 aus 1 gezeigt. Das Kommunikations-Subsystem 104 umfasst einen Empfänger 150, einen Sender 152, einen oder mehrere eingebettete oder interne Antennenelemente 154, 156, Lokaloszillatoren (LOs) 158 und ein Verarbeitungsmodul wie beispielsweise einen digitalen Signalprozessor (DSP) 160.
Der konkrete Aufbau des Kommunikations-Subsystems 104 hängt vom Netz 200 ab, in dem das Mobilgerät 100 arbeiten soll, daher sollte es einleuchten, dass der in 2 gezeigte Aufbau nur als Beispiel dient. Die von der Antenne 154 über das Netz 200 empfangenen Signale werden in den Empfänger 150 eingespeist, der solche üblichen Empfängerfunktionen wie die Signalverstärkung, die Frequenzabwärtsmischung, die Filterung, die Kanalauswahl und die Analog-Digital-(A/D)-Umwandlung durchführen kann. Die A/D-Umwandlung eines empfangenen Signals ermöglicht die Durchführung komplexerer Kommunikationsfunktionen wie Demodulation und Decodierung im DSP 160. In einer ähnlichen Weise werden die zu übertragenden Signale durch den DSP 160 verarbeitet, einschließlich Modulation und Codierung. Diese vom DSP verarbeiteten Signale werden in den Sender 152 eingespeist, wo die Digital-Analog-(D/A)-Wandlung, die Frequenz aufwärtsmischung, die Filterung, die Verstärkung und die Übertragung über das Netz 200 mit der Antenne 156 erfolgt. Der DSP 160 verarbeitet nicht nur die Kommunikationssignale, sondern übernimmt auch die Empfänger- und Sendersteuerung. Beispielsweise können die im Empfänger 150 und im Sender 152 auf die Kommunikationssignale angewendeten Verstärkungsgrade adaptiv durch automatische Verstärkungsregelungsalgorithmen gesteuert werden, die im DSP 160 implementiert sind.
Die drahtlose Verbindung zwischen dem Mobilgerät 100 und einem Netz 200 kann einen oder mehrere unterschiedliche Kanäle einschließen, typischerweise unterschiedliche HF-Kanäle sowie die zugehörigen Protokolle, die zwischen dem Mobilgerät 100 und dem Netz 200 verwendet werden. Ein HF-Kanal ist eine beschränkte Ressource, mit der sparsam umgegangen werden muss, was sich typischerweise aus den Einschränkungen in der Gesamtbandbreite und aus der beschränkten Batterieleistung des Mobilgeräts 100 ergibt.
Wenn das Mobilgerät 100 sich im vollen Betrieb befindet, wird der Sender 152 typischerweise nur dann getastet oder eingeschaltet, wenn er an das Netz 200 sendet und ist ansonsten abgeschaltet, um sparsam mit Ressourcen umzugehen. In gleicher Weise wird der Empfänger 150 periodisch abgeschaltet, um Strom zu sparen, bis er benötigt wird, um Signale oder Informationen (wenn überhaupt) während ausgewiesener Zeitabschnitte zu empfangen.
Nunmehr Bezug nehmend auf 3 wird ein Blockdiagramm eines Knotens eines Drahtlosnetzes als 202 gezeigt. In der Praxis umfasst das Netz 200 einen oder mehrere Knoten 202. Das Mobilgerät 100 kommuniziert mit einem Knoten 202 innerhalb des Drahtlosnetzes 200. In der Beispielimplementierung von 3 ist der Knoten 202 gemäß den Technologien General Packet Radio Service (GPRS) und Global Systems for Mobile (GSM) konfiguriert. Der Knoten 202 enthält eine Basisstationssteuereinheit (Base Station Controller – BSC) 204 mit einer zugehörigen Turmstation 206, eine Paketsteuerungseinheit (Packet Control Unit – PCU) 208, die zur GPRS-Unterstützung in GSM hinzugefügt wurde, ein mobile Ver mittlungsstelle (Mobile Switching Center – MSC) 210, ein Heimatregister (Home Location Register – HLR) 212, ein Besucherregister (Visitor Location Register – VLR) 214, ein Serving GPRS Support Node (SGSN) 216, ein Gateway GPRS Support Node (GGSN) 218 und ein Dynamic Host Configuration Protocol (DHCP) 220. Diese Liste der Komponenten ist nicht als erschöpfende Liste jedes Knotens 202 innerhalb eines GSM/GPRS-Netzes gemeint, sondern vielmehr als eine Liste der Komponenten, die im Allgemeinen in der Kommunikation über das Netz 200 verwendet werden.
In einem GSM-Netz ist MSC 210 mit BSC 204 und mit einem ortsfesten Netz wie einem Public Switched Telephone Network (PSTN) 222 gekoppelt, um die Anforderungen der Leitungsvermittlung zu erfüllen. Die Verbindung über PCU 208, SGSN 216 und GGSN 218 zum öffentlichen oder privaten Netz (Internet) 224 (hier auch allgemein als eine gemeinsam verwendete Netzinfrastruktur bezeichnet) bildet den Datenpfad für GPRS-taugliche Mobilgeräte. In einem um GPRS-Funktionen erweiterten GSM-Netz enthält BSC 204 auch eine Packet Control Unit (PCU) 208, die eine Verbindung zu SGSN 216 hat, um die Segmentierung und die Funkkanalzuweisung zu steuern und um den Paketvermittlungsanforderungen gerecht zu werden. Um die Mobilgerätposition und die Verfügbarkeit für sowohl leitungs-vermittelte als auch paketvermittelte Verwaltung zu verfolgen, wird HLR 212 gemeinsam von MSC 210 und SGSN 216 verwendet. Der Zugriff auf VLR 214 wird durch MSC 210 gesteuert.
Station 206 ist eine feststehende Sende-Empfangsstation. Station 206 und BSC 204 bilden gemeinsam die feststehende Sende-Empfangsausrüstung. Die feststehende Sende-Empfangsausrüstung sorgt für die drahtlose Netzabdeckung für ein bestimmtes Abdeckungsgebiet, das im Allgemeinen als eine "Zelle" bezeichnet wird. Die feststehende Sende-Empfangsausrüstung überträgt Kommunikationssignale zu den und empfangt Kommunikationssignale von den Mobilgeräten innerhalb dieser Zelle über die Station 206. Die feststehende Sende-Empfangsausrüstung führt normalerweise solche Funktionen durch wie die Modulation und möglicherweise die Codierung und/oder Verschlüsselung von Signalen, die zum Mobilgerät übertragen werden sollen, und zwar entsprechend bestimmten, üblicherweise vorbestimmten Kommunikationsprotokollen und -parametern, unter der Steuerung ihrer Steuerungseinheit. Die feststehende Sende-Empfangsausrüstung übernimmt in gleicher Weise die Demodulation und möglicherweise Decodierung und Entschlüsselung, falls erforderlich, aller Kommunikationssignale, die innerhalb seiner Zelle vom Mobilgerät 100 empfangen werden. Die Kommunikationsprotokolle und -parameter können zwischen unterschiedlichen Knoten voneinander abweichen. Zum Beispiel kann ein Knoten ein abweichendes Modulationsschema verwenden und mit anderen Frequenzen arbeiten als andere Knoten.
Für alle innerhalb eines bestimmten Netzes registrierten Mobilgeräte 100 sind permanente Konfigurationsdaten wie z. B. ein Benutzerprofil im HLR 212 gespeichert. HLR 212 enthält auch Positionsinformationen für jedes registrierte Mobilgerät und kann abgefragt werden, um die aktuelle Position eines Mobilgeräts zu ermitteln. MSC 210 ist verantwortlich für eine Gruppe von Positionsbereichen und speichert die Daten der Mobilgeräte, die sich aktuell in seinem Verantwortlichkeitsbereich befinden, im VLR 214. Des Weiteren enthält VLR 214 auch Informationen zu den Mobilgeräten, die andere Netze besuchen. Die Informationen im VLR 214 schließen für einen schnelleren Zugriff einen Teil der permanenten Mobilgerätedaten ein, die vom HLR 212 zum VLR 214 übertragen wurden. Durch die Verschiebung zusätzlicher Informationen von einem entfernten HLR-Knoten 212 zum VLR 214 kann das Ausmaß an Verkehr zwischen diesen Knoten reduziert werden, sodass Sprach- und Datendienste mit kürzeren Reaktionszeiten bereitgestellt werden können und gleichzeitig weniger Computerressourcen verwendet werden müssen.
SGSN 216 und GGSN 218 sind Elemente, die innerhalb von GSM zur GPRS-Unterstützung hinzugefügt wurden, nämlich für die Unterstützung paketvermittelter Daten. SGSN 216 und MSC 210 haben innerhalb des Drahtlosnetzes 200 ähnliche Verantwortlichkeiten, indem sie die Position jedes Mobilgeräts 100 verfolgen. SGSN 216 führt außerdem Sicherheitsfunktionen und die Zugriffs steuerung für den Datenverkehr auf Netz 200 durch. GGSN 218 stellt Verbindungen für den netzüberschreitenden Betrieb mit externen paketvermittelten Netzen bereit und stellt die Verbindung zu einem oder mehreren SGSNs 216 über ein Internet Protocol (IP) Backbone-Netz her, das innerhalb des Netzes 200 betrieben wird. Während des normalen Betriebs muss ein bestimmtes Mobilgerät 100 einen "GPRS-Attach" durchführen, um eine IP-Adresse zu erhalten und um auf Datendienste zuzugreifen. Diese Erfordernis ist in leitungsvermittelten Sprachkanälen nicht vorhanden, da ISDN-Adressen (Integrated Services Digital Network) für die Leitweglenkung eingehender und ausgehender Anrufe verwendet werden. Gegenwärtig verwenden alle GPRS-fähigen Netze private, dynamisch zugewiesene IP-Adressen, wodurch ein an das GGSN 218 angeschlossener DHCP-Server 220 erforderlich ist. Es gibt viele Mechanismen zur dynamischen IP-Zuweisung, einschließlich der Verwendung einer Kombination aus einem RADIUS-Server (Remote Authentication Dial-In User Service) und einem DHCP-Server. Sobald der GPRS-Attach abgeschlossen ist, wird eine logische Verbindung von einem Mobilgerät 100, über PCU 208 und SGSN 216 zu einem Access Point Node (APN) innerhalb von GGSN 218 eingerichtet. Der APN repräsentiert ein logisches Ende eines IP-Tunnels, der entweder auf direkte Internet-kompatible Dienste oder auf Privatnetzverbindungen zugreifen kann. Der APN repräsentiert auch einen Sicherheitsmechanismus für das Netz 200, insofern als dass jedes Mobilgerät 100 einem oder mehreren APNs zugewiesen sein muss und das Mobilgerät 100 keine Daten austauschen kann, ohne zuerst einen GPRS-Attach zu einem APN durchzuführen, für dessen Benutzung es autorisiert wurde. Für den APN kann angenommen werden, dass er einem Internet-Domänennamen wie "meineverbindung.drahtlos.com" ähnelt.
Sobald der GPRS-Attach abgeschlossen ist, wird ein Tunnel erstellt, und der gesamte Verkehr wird innerhalb standardmäßiger IP-Pakete ausgetauscht, wozu jedes Protokoll verwendet wird, das in IP-Paketen unterstützt werden kann. Dazu zählen Tunnelungsverfahren wie IP over IP, wie das bei einigen IPSec-Verbindungen (IPSecurity) der Fall ist, die mit VPNs (Virtual Private Networks) verwendet werden. Diese Tunnel werden auch als PDP-Kontexte (Packet Data Protocol) bezeichnet, und von diesen ist nur eine begrenzten Anzahl im Netz 200 verfügbar. Um die Verwendung von PDP-Kontexten zu maximieren, führt das Netz 200 einen Idle-Timer für jeden PDP-Kontext aus, um zu ermitteln, ob es ein Fehlen von Aktivität gibt. Wenn ein Mobilgerät 100 nicht seinen PDP-Kontext verwendet, kann die Zuordnung des PDP-Kontexts aufgehoben und die IP-Adresse wieder dem IP-Adressenpool zugeführt werden, der durch den DHCP-Server 220 verwaltet wird.
Nunmehr Bezug nehmend auf 4 ist ein Blockdiagramm zur Darstellung der Komponenten eines Host-Systems in einer exemplarischen Konfiguration gezeigt. Das Host-System 250 wird typischerweise ein Unternehmensbüronetzwerk oder ein anderes LAN (Local Area Network) sein, kann aber stattdessen ein privater Bürocomputer oder in abweichenden Implementierungen beispielsweise ein anderes privates System sein. In diesem in 4 gezeigten Beispiel ist das Host-System 250 als ein LAN einer Organisation dargestellt, zu der ein Benutzer des Mobilgeräts 100 gehört.
Das LAN 250 umfasst eine Anzahl von Netzwerkkomponenten, die durch LAN-Verbindungen 260 miteinander verbunden sind. Beispielsweise befindet sich das Desktop-Computergerät ("Desktopcomputer") 262a eines Benutzers mit einer zugehörigen Dockingstation 264 für das Mobilgerät 100 des Benutzers im LAN 250. Die Dockingstation 264 für das Mobilgerät 100 kann mit dem Computer 262a verbunden sein, beispielsweise über eine serielle oder über eine USB-Verbindung (Universal Serial Bus). Andere Benutzercomputer 262b befinden sich auch im LAN 250, und jeder kann mit einer zugehörigen Dockingstation 264 für ein Mobilgerät ausgestattet sein oder auch nicht. Die Dockingstation 264 ermöglicht das Laden von Informationen (z. B. PIM-Daten, private symmetrische Verschlüsselungsschlüssel zum Ermöglichen einer sicheren Kommunikation zwischen dem Mobilgerät 100 und dem LAN 250) vom Benutzercomputer 262a zum Mobilgerät 100 und kann insbesondere nützlich für das massenhafte Aktualisieren von Informationen sein, das häufig bei der Initialisierung des Mobilgeräts 100 für dessen Verwendung durchgeführt wird. Zu den zum Mobilgerät 100 heruntergeladenen Informationen können S/MIME-Zertifikate oder PGP-Schlüssel gehören, die beim Austauschen von Nachrichten verwendet werden. Der Prozess des Herunterladens von Informationen vom Desktopcomputer 262a eines Benutzers zum Mobilgerät 100 des Benutzers kann auch als Synchronisierung bezeichnet werden.
Dem Fachmann auf dem Gebiet der Technik wird verständlich sein, dass die Benutzercomputer 262a, 262b typischerweise auch mit anderen Peripheriegeräten verbunden sind, die in 4 nicht explizit dargestellt sind. Darüber hinaus wird in 4 zur vereinfachten Darstellung nur eine Teilgruppe von Netzwerkkomponenten des LAN 250 gezeigt, und dem Fachmann auf dem Gebiet der Technik wird einleuchten, dass das LAN 250 für diese Beispielkonfiguration weitere Komponenten umfasst, die in 4 nicht explizit dargestellt sind. Noch allgemeiner kann das LAN 250 einen kleineren Teil eines größeren Netzwerks [nicht dargestellt] der Organisation repräsentieren und kann andere Komponenten umfassen und/oder in anderen Topologien angeordnet sein, die im Beispiel von 4 nicht gezeigt werden.
In diesem Beispiel kommuniziert das Mobilgerät 100 mit dem LAN 250 über einen Knoten 202 des Drahtlosnetzwerks 200 und eine gemeinsam verwendete Infrastruktur 224 wie beispielsweise ein Dienstanbieternetz oder das öffentliche Internet. Der Zugriff auf das LAN 250 kann durch einen oder mehrere Router [nicht dargestellt] ermöglicht werden, und die Computergeräte des LAN 250 können hinter einer Firewall oder einem Proxyserver 266 operieren.
In einer abweichenden Implementierung umfasst das LAN 250 einen drahtlosen VPN-Router [nicht dargestellt], um den Datenaustausch zwischen dem LAN 250 und dem Mobilgerät 100 zu ermöglichen. Das Konzept eines drahtlosen VPN-Routers ist in der Drahtlosindustrie noch neu, und es impliziert, dass eine VPN-Verbindung direkt über ein spezielles drahtloses Netzwerk zum Mobilgerät 100 eingerichtet werden kann. Die Möglichkeit zur Verwendung eines drahtlosen VPN-Routers steht erst seit kurzem zur Verfügung und könnte verwendet werden, wenn die neue Version 6 des Internetprotokolls (IPV6) in IP-basierte Drahtlosnetzwerke eingeführt wird. Dieses neue Protokoll wird ausreichend IP-Adressen bereitstellen, um jedem Mobilgerät eine IP-Adresse zuzuordnen, wodurch es möglich wird, jeder-zeit Informationen zu einem Mobilgerät zu pushen. Ein Vorteil der Verwendung eines drahtlosen VPN-Routers besteht darin, dass es sich dabei um eine Standard-VPN-Komponente handeln kann, für deren Verwendung kein separates drahtloses Gateway und keine separate drahtlose Infrastruktur erforderlich ist. Eine VPN-Verbindung wäre vorzugsweise eine Transmission Control Protocol (TCP)/IP- oder User Datagram Protocol (UDP)/IP-Verbindung, um die Nachrichten in dieser abweichenden Implementierung direkt an das Mobilgerät 100 zu liefern.
Die für einen Benutzer des Mobilgeräts 100 bestimmten Nachrichten werden anfänglich von einem Nachrichtenserver 268 des LAN 250 empfangen. Solche Nachrichten können von jeder aus einer Reihe von Quellen stammen. Beispielsweise kann eine Nachricht durch einen Absender von einem Computer 262b innerhalb des LAN 250, von einem anderen Mobilgerät [nicht dargestellt], das mit dem Drahtlosnetzwerk 200 oder mit einem anderen Drahtlosnetzwerk verbunden ist, oder von einem anderen Computergerät oder einem anderen Gerät, das zum Senden von Nachrichten in der Lage ist, über die gemeinsam verwendete Netzwerkinfrastruktur 224 und möglicherweise z. B. über einen Anwendungsdienstanbieter (Application Service Provider – ASP) oder Internet-Dienstanbieter (Internet Service Provider – ISP) gesendet worden sein.
Der Nachrichtenserver 268 agiert typischerweise als die primäre Schnittstelle für den Austausch von Nachrichten, insbesondere von E-Mail-Nachrichten, innerhalb der Organisation und über die gemeinsam verwendete Netzwerkinfrastruktur 224. Jedem Benutzer in der Organisation, der zum Senden und Empfangen von Nachrichten eingerichtet ist, ist typischerweise ein Benutzerkonto zugeordnet, das durch den Nachrichtenserver 268 verwaltet wird. Ein Beispiel eines Nachrichtenservers 268 ist ein Microsoft Exchange^TM-Server. In einigen Implementierungen kann das LAN 250 mehrere Nachrichtenserver 268 umfassen. Der Nachrichten server 268 kann auch so angepasst sein, dass er über die Nachrichtenverwaltung hinaus zusätzliche Funktionen bereitstellt, wozu die Verwaltung von Daten zählt, die beispielsweise Kalendern und Aufgabenlisten zugeordnet sind.
Wenn die Nachrichten vom Nachrichtenserver 268 empfangen werden, werden sie typischerweise in einem Nachrichtenspeicher [nicht explizit dargestellt] gespeichert, von dem die Nachrichten nachfolgend abgerufen und an die Benutzer geliefert werden können. Beispielsweise kann eine auf einem Benutzercomputer 262a ausgeführte E-Mail-Clientanwendung die auf dem Nachrichtenserver 268 gespeicherten E-Mail-Nachrichten abrufen, die dem Konto dieses Benutzers zugeordnet sind. Diese Nachrichten würden dann typischerweise vom Nachrichtenserver 268 abgerufen und lokal auf dem Computer 262a gespeichert werden.
Beim Betrieb des Mobilgeräts 100 kann der Benutzer wünschen, dass E-Mail-Nachrichten abgerufen und auf das Handgerät geliefert werden. Eine auf dem Mobilgerät 100 ausgeführte E-Mail-Clientanwendung kann auch die dem Konto des Benutzers zugeordneten Nachrichten von Nachrichtenserver 268 anfordern. Der E-Mail-Client kann so konfiguriert sein (entweder durch den Benutzer oder durch einen Administrator, möglicherweise in Übereinstimmung mit der IT-Richtlinie (Information Technology) einer Organisation), um diese Anforderung auf Anweisung des Benutzers, in einem vorbestimmten Zeitintervall oder beim Auftreten eines vordefinierten Ereignisses durchzuführen. In einigen Implementierungen ist dem Mobilgerät 100 seine eigene E-Mail-Adresse zugeordnet, und die speziell an das Mobilgerät 100 adressierten Nachrichten werden automatisch zum Mobilgerät 100 weitergeleitet, wenn sie durch den Nachrichtenserver 268 empfangen werden.
Um die drahtlose Kommunikation von Nachrichten und nachrichtenbezogenen Daten zwischen dem Mobilgerät 100 und den Komponenten des LAN 250 zu ermöglichen, können eine Anzahl von Drahtloskommunikations-Unterstützungskomponenten 270 vorhanden sein. In dieser Beispielimplementierung umfassen die Drahtloskommunikations-Unterstützungskomponenten 270 beispielsweise einen Nachrichtenverwaltungsserver 272. Der Nachrichtenverwaltungsserver 272 wird verwendet, um speziell die Unterstützung für die Verwaltung von Nachrichten wie E-Mail-Nachrichten bereitzustellen, die durch Mobilgeräte gehandhabt werden sollen. Im Allgemeinen kann der Nachrichtenverwaltungsserver 272 verwendet werden, um zu steuern, wann, ob und wie Nachrichten zum Mobilgerät 100 gesendet werden, obwohl die Nachrichten nach wie vor auf dem Nachrichtenserver 268 gespeichert werden. Der Nachrichtenverwaltungsserver 272 ermöglicht auch die Handhabung der auf dem Mobilgerät 100 erstellten Nachrichten, die zum Nachrichtenserver 268 gesendet werden, um anschließend ausgeliefert zu werden.
Beispielsweise kann der Nachrichtenverwaltungsserver 272: die "Mailbox" (z. B. den Nachrichtenspeicher, der dem Benutzerkonto auf dem Nachrichtenserver 268 zugeordnet ist) des Benutzers überwachen; vom Benutzer definierbare Filter auf neue Nachrichten anwenden, um zu ermitteln, ob und wie die Nachrichten an das Mobilgerät 100 des Benutzers weitergeleitet werden sollen; neue Nachrichten komprimieren und verschlüsseln (z. B. unter Verwendung einer Verschlüsselungstechnik wie Data Encryption Standard (DES) oder Triple DES) und sie über die gemeinsam verwendete Netzwerkinfrastruktur 224 und das Drahtlosnetzwerk 200 zum Mobilgerät 100 pushen; und auf dem Mobilgerät 100 erstellte Nachrichten (die z. B. mit Triple DES verschlüsselt wurden) empfangen, die erstellten Nachrichten entschlüsseln und dekomprimieren, die erstellten Nachrichten auf Wunsch umformatieren, sodass sie so erscheinen, als würden sie vom Computer 262a des Benutzers stammen, und die erstellten Nachrichten zum Nachrichtenserver 268 weiterleiten, um sie auszuliefern.
Bestimmte Eigenschaften oder Einschränkungen, die den Nachrichten zugeordnet sind, welche vom Mobilgerät 100 gesendet und/oder empfangen werden sollen, können durch den Nachrichtenverwaltungsserver 272 definiert (z. B. durch einen Administrator in Übereinstimmung mit einer IT-Richtlinie) und durchgesetzt werden. Dazu kann beispielsweise gehören, ob das Mobilgerät 100 verschlüsselte und/oder signierte Nachrichten empfangen kann, welche Mindestgröße die Ver schlüsselungsschlüssel haben, ob ausgehende Nachrichten verschlüsselt und/oder signiert werden müssen und ob Kopien von allen sicheren Nachrichten, die vom Mobilgerät 100 gesendet wurden, zu einer vordefinierten Kopieradresse gesendet werden sollen.
Der Nachrichtenverwaltungsserver 272 kann auch so angepasst sein, dass er andere Steuerungsfunktionen bereitstellt, zum Beispiel nur das Pushing bestimmter Nachrichteninformationen oder vordefinierter Abschnitte (z. B. "Blöcke") einer auf dem Nachrichtenserver 268 gespeicherten Nachricht zum Mobilgerät 100. Wenn beispielsweise eine Nachricht anfänglich durch das Mobilgerät 100 vom Nachrichtenserver 268 abgerufen wird, ist der Nachrichtenverwaltungsserver 272 so angepasst, dass er nur den ersten Teil einer Nachricht zum Mobilgerät 100 pusht, wobei der Teil eine vordefinierte Größe (z. B. 2 KB) hat. Der Benutzer kann dann weitere Teile der Nachricht anfordern, die in gleichgroßen Blöcken durch den Nachrichtenverwaltungsserver 272 zum Mobilgerät 100 geliefert werden, möglicherweise bis zu einer maximalen vordefinierten Nachrichtengröße.
Demnach ermöglicht der Nachrichtenverwaltungsserver 272 eine bessere Steuerung des Datentyps und der Datenmenge, die zum Mobilgerät 100 kommuniziert werden sollen, und kann dazu beitragen, potenzielle Verschwendung von Bandbreite und anderen Ressourcen zu minimieren.
Dem Fachmann auf dem Gebiet der Technik wird einleuchten, dass der Nachrichtenverwaltungsserver 272 nicht als ein separater physischer Server im LAN 250 oder einem anderen Netzwerk implementiert sein muss. Beispielsweise können einige oder alle Funktionen, die dem Nachrichtenverwaltungsserver 272 zugeordnet sind, auch in den Nachrichtenserver 268 oder in irgendeinen anderen Server im LAN 250 integriert sein. Darüber hinaus kann das LAN 250 mehrere Nachrichtenverwaltungsserver 272 umfassen, insbesondere in abweichenden Implementierungen, bei denen eine große Anzahl von Mobilgeräten unterstützt werden muss.
In einigen der hier beschriebenen Ausführungsformen werden Zertifikate bei der Verarbeitung von codierten Nachrichten wie z. B. E-Mail-Nachrichten verwendet, die verschlüsselt und/oder signiert sind. Während Simple Mail Transfer Protocol (SMTP), RFC822-Header und Teile des Bestandteile des Hauptkörpers von Multipurpose Internet Mail Extensions (MIME) verwendet werden können, um das Format einer typischen E-Mail-Nachricht zu definieren, die keine Codierung erfordert, kann Secure/MIME (S/MIME), eine Version des MIME-Protokolls, bei der Kommunikation von codierten Nachrichten verwendet werden (z. B. in sicheren Nachrichtenanwendungen). S/MIME ermöglicht End-to-End-Authentifizierung und -Vertraulichkeit und schützt die Datenintegrität und -sicherheit von dem Zeitpunkt, zu dem ein Erzeuger einer Nachricht eine Nachricht sendet, bis zum Decodieren und Lesen der Nachricht durch den Nachrichtenempfänger. In anderen der hier beschriebenen Ausführungsformen können andere Standards und Protokolle eingesetzt werden, um eine sichere Nachrichtenkommunikation zu ermöglichen, zum Beispiel Pretty Good Privacy^TM (PGP) und Varianten von PGP wie OpenPGP. Es sollte verständlich sein, dass bei hier vorkommenden allgemeinen Verweisen auf "PGP" mit diesem Begriff auch jede aus einer Vielzahl von abweichenden Implementierungen eingeschlossen sein soll, die auf dem allgemeineren PGP-Schema basiert.
Sichere Nachrichtenprotokolle wie S/MIME und PGP-basierte Protokolle basieren auf öffentlichen und privaten Verschlüsselungsschlüsseln, um die Vertraulichkeit und Integrität zu gewährleisten. Daten, die unter Verwendung eines privaten Schlüssels aus einem Paar aus privatem Schlüssel und öffentlichem Schlüssel verschlüsselt wurden, können nur decodiert werden, wenn der entsprechende öffentliche Schlüssel des Paares verwendet wird, und Daten, die unter Verwendung eines öffentlichen Schlüssels aus einem Paar aus privatem Schlüssel und öffentlichem Schlüssel verschlüsselt wurden, können nur decodiert werden, wenn der entsprechende private Schlüssel des Paares verwendet wird. Es ist vorgesehen, die Informationen des privaten Schlüssels niemals öffentlich zu machen, wogegen die Informationen des öffentlichen Schlüssels weitergegeben werden.
Wenn zum Beispiel ein Absender eine Nachricht in verschlüsselter Form an einen Empfänger senden möchte, wird der öffentliche Schlüssel des Empfängers zum Verschlüsseln einer Nachricht verwendet, die dann nur mithilfe des privaten Schlüssels des Empfängers entschlüsselt werden kann. Alternativ wird in einigen Codierungstechniken ein Sitzungsschlüssel zur einmaligen Verwendung erzeugt und zum Verschlüsseln des Nachrichtenhauptteils verwendet, was typischerweise mit einer symmetrischen Verschlüsselungstechnik (z. B. Triple DES) erfolgt. Der Sitzungsschlüssel wird dann mithilfe des öffentlichen Schlüssels des Empfängers (z. B. mit einem Algorithmus zur Verschlüsselung mit öffentlichen Schlüsseln wie RSA) verschlüsselt, der dann nur mithilfe des privaten Schlüssels des Empfängers wieder entschlüsselt werden kann. Der entschlüsselte Sitzungsschlüssel kann dann zum Entschlüsseln des Nachrichtenhauptteils verwendet werden. Der Nachrichten-Header kann verwendet werden, um das spezielle Verschlüsselungsschema zu spezifizieren, das zum Entschlüsseln der Nachricht verwendet werden muss. In abweichenden Implementierungen können andere auf der Kryptografie mit öffentlichen Schlüsseln basierende Verschlüsselungstechniken verwendet werden. Allerdings kann in jedem dieser Fälle nur der private Schlüssel des Empfängers verwendet werden, um die Entschlüsselung der Nachricht zu ermöglichen, und auf diese Weise kann die Vertraulichkeit der Nachrichten gewahrt werden.
Als ein weiteres Beispiel kann ein Absender eine Nachricht unter Verwendung einer digitalen Signatur signieren. Eine digitale Signatur ist eine unter Verwendung des privaten Schlüssels des Absenders codierte Zusammenfassung der Nachricht (z. B. ein Hash der Nachricht), die dann an die ausgehende Nachricht angehängt werden kann. Um die digitale Signatur der Nachricht beim Empfang zu verifizieren, verwendet der Empfänger dieselbe Technik wie der Absender (z. B. denselben standardmäßigen Hash-Algorithmus), um eine Zusammenfassung der empfangenen Nachricht zu erhalten. Der Empfänger verwendet auch den öffentlichen Schlüssel des Absenders, um die digitale Signatur zu decodieren, um das zu erhalten, was eine übereinstimmende Zusammenfassung der empfangenen Nachricht sein sollte. Wenn die Zusammenfassungen der empfangenen Nachricht nicht übereinstimmen, lässt das darauf schließen, dass entweder der Nachrichteninhalt während des Transports geändert wurde und/oder dass die Nachricht nicht von dem Absender stammt, dessen öffentlicher Schlüssel zur Verifizierung verwendet wurde. Digitale Signaturalgorithmen sind so konstruiert, dass nur jemand, der Kenntnis vom privaten Schlüssel des Absenders hat, in der Lage sein sollte, eine Signatur zu codieren, die der Empfänger mithilfe des öffentlichen Schlüssels des Absenders korrekt decodiert. Deshalb kann durch die Verifizierung einer digitalen Signatur in dieser Weise die Authentifizierung des Absenders und die Nachrichtenintegrität gewahrt werden.
Eine codierte Nachricht kann verschlüsselt, signiert oder sowohl verschlüsselt als auch signiert werden. In S/MIME wird die Authentizität der bei diesen Operationen verwendeten öffentlichen Schlüssel mithilfe von Zertifikaten validiert. Ein Zertifikat ist ein digitales Dokument, das von einer Zertifikatstelle (Certificate Authority – CA) ausgestellt wird. Zertifikate werden zur Authentifizierung der Zuordnung zwischen Benutzern und ihren privaten Schlüsseln verwendet und ermöglichen im Wesentlichen einen Level of Trust (Grad an Vertrauen) in die Authentizität der öffentlichen Schlüssel der Benutzer. Zertifikate enthalten Informationen über den Zertifikatinhaber, wobei die Zertifikatinhalte typischerweise entsprechend einem akzeptierten Standard (z. B. X.509) formatiert sind. Die Zertifikate werden typischerweise durch die Zertifikatstelle digital signiert.
In PGP-basierten Systemen wird ein PGP-Schlüssel verwendet, der insofern einem S/MIME-Zertifikat ähnelt, als dass er öffentliche Informationen enthält, wozu ein öffentlicher Schlüssel und Informationen zum Inhaber oder Eigentümer des Schlüssels gehören. Im Unterschied zu S/MIME-Zertifikaten werden PGP-Schlüssel jedoch im Allgemeinen nicht durch eine Zertifikatstelle ausgestellt, und der Level of Trust in die Authentizität eines PGP-Schlüssels erfordert typischerweise eine Verifizierung, dass eine vertrauenswürdige Person für die Authentizität eines gegebenen PGP-Schlüssels bürgt.
Für den Zweck der Beschreibung und in den Patentansprüchen wird der Begriff "Zertifikat" allgemein verwendet, um ein Konstrukt zu beschreiben, das zur Bereitstellung von öffentlichen Schlüsseln zum Codieren und Decodieren von Nachrichten und möglicherweise von Informationen zum Schlüsselinhaber verwendet wird, und es kann angenommen werden, dass dazu auch das gehört, was allgemein als ein "PGP-Schlüssel" bekannt ist, sowie andere ähnliche Konstrukte.
Standard-E-Mail-Sicherheitsprotokolle ermöglichen typischerweise die sichere Nachrichtenübertragung zwischen nicht-mobilen Computergeräten (z. B. Computer 262a, 262b aus 4; Remote-Desktopgeräte). Damit von Absendern empfangene signierte Nachrichten auf dem Mobilgerät 100 gelesen werden können und verschlüsselte Nachrichten vom Mobilgerät 100 aus gesendet werden können, ist das Mobilgerät 100 eingerichtet zum Speichern von öffentlichen Schlüsseln (z. B. in Form von S/MIME-Zertifikaten, PGP-Schlüsseln) von anderen Personen. Die auf dem Computer 262a eines Benutzers gespeicherten Schlüssel werden typischerweise vom Computer 262a z. B. über die Dockingstation 264 auf das Mobilgerät 100 heruntergeladen.
Das Mobilgerät 100 kann auch eingerichtet sein zum Speichern des privaten Schlüssels aus dem Paar aus öffentlichem und privatem Schlüssel, das mit dem Benutzer assoziiert ist, so dass der Benutzer des Mobilgeräts 100 abgehende Nachrichten, die auf dem Mobilgerät 100 verfasst wurden, signieren kann und zum Benutzer gesendete Nachrichten entschlüsseln kann, die mit dem öffentlichen Schlüssel des Benutzers verschlüsselt wurden. Der private Schlüssel kann vom Computer 262a des Benutzers beispielsweise über die Dockingstation 264 auf das Mobilgerät 100 heruntergeladen werden. Der private Schlüssel wird vorzugsweise zwischen dem Computer 262a und dem Mobilgerät 100 ausgetauscht, so dass der Benutzer eine Identität und ein Verfahren zum Zugriff auf Nachrichten gemeinsam verwenden kann.
Die Benutzercomputer 262a, 262b können S/MIME-Zertifikate und PGP-Schlüssel aus einer Reihe von Quellen gewinnen, um sie auf den Computer 262a, 262b und/oder auf Mobilgeräten (z. B. dem Mobilgerät 100) beispielsweise in einem Schlüsselspeicher zu speichern. Diese Zertifikatquellen können privat (z. B. nur für die Verwendung innerhalb einer Organisation bestimmt) oder öffentlich sein, können lokal und entfernt angeordnet sein und der Zugriff auf sie kann beispielsweise aus dem Privatnetz einer Organisation heraus oder über das Internet erfolgen. In dem in 4 gezeigten Beispiel befinden sich mehrere mit der Organisation assoziierte PKI-Server (Public Key Infrastructure) 280 im LAN 250. Die PKI-Server 280 schließen beispielsweise einen CA-Server 282, der zum Ausstellen von S/MIME-Zertifikaten verwendet werden kann, einen LDAP-Server (Lightweight Directory Access Protocol) 284, der zum Suchen nach und zum Herunterladen von S/MIME-Zertifikaten und/oder PGP-Schlüsseln (z. B. für Personen innerhalb der Organisation) verwendet werden kann, sowie einen OCSP-Server (Online Certificate Status Protocol) 286 ein, der zur Verifizierung des Widerrufstatus von S/MIME-Zertifikaten verwendet werden kann.
Zertifikate und/oder PGP-Schlüssel können vom LDAP-Server 284 beispielsweise durch einen Benutzercomputer 262a abgerufen werden, um über die Dockingstation 264 auf das Mobilgerät 100 heruntergeladen zu werden. Allerdings kann in einer abweichenden Implementierung der Zugriff auf den LDAP-Server 284 auch direkt (d. h. in diesem Kontext "über die Luft") durch das Mobilgerät 100 erfolgen, und das Mobilgerät 100 kann über einen mobilen Datenserver 288 nach individuellen Zertifikaten und PGP-Schlüsseln suchen und diese abrufen. In gleicher Weise kann der mobile Datenserver 288 eingerichtet sein, um dem Mobilgerät 100 das direkte Abfragen des OCSP-Servers 286 zur Verifizierung des Widerrufstatus von S/MIME-Zertifikaten zu gestatten.
In abweichenden Implementierungen können nur ausgewählte PKI-Server 280 für Mobilgeräte zugänglich gemacht sein (dass z. B. Zertifikate nur von einem Benutzercomputer 262a, 262b heruntergeladen werden dürfen, während die Überprüfung des Widerrufstatus auch vom Mobilgerät 100 aus zugelassen wird).
In abweichenden Implementierungen können bestimmte PKI-Server 280 nur für Mobilgeräte zugänglich gemacht sein, die für bestimmte Benutzer registriert sind, was beispielsweise durch einen IT-Administrator und möglicherweise entsprechend einer IT-Richtlinie festgelegt wird.
Zu anderen [nicht dargestellten] Quellen für S/MIME-Zertifikate und PGP-Schlüssel können beispielsweise ein Windows-Zertifikat- oder -Schlüsselspeicher, ein anderer sicherer Zertifikat- oder Schlüsselspeicher im oder außerhalb des LAN 250 sowie Smartcards gehören.
In mindestens einer Ausführungsform befindet sich im LAN 250 eine Policy Engine 290. In einigen Ausführungsformen der hier beschriebenen Systeme und Verfahren wird die Policy Engine 290 durch einen von der PGP Corporation entwickelten PGP Universal Server bereitgestellt werden. Das ist jedoch nur ein Beispiel. In abweichenden Implementierungen kann die Policy Engine in einem anderen Gerät oder einem anderen Konstrukt als einem PGP Universal Server implementiert sein, und sie kann im Kontext von anderen Protokollen als PGP (z. B. in einer S/MIME Policy Engine) angewendet werden. Beispielsweise kann ein EMS (Entrusted Entelligence Messaging Server) eingesetzt werden.
In diesem Beispiel ist ein PGP Universal Server 290 eingerichtet, um mit dem Desktopcomputer eines Benutzers (z. B. 262a) und dem Mobilgerät des Benutzers (z. B. 100 über den Nachrichtenverwaltungsserver 272) zu kommunizieren, und er kann des Weiteren eingerichtet sein, um Nachrichten zu verschlüsseln und um die Einhaltung von Sicherheitsanforderungen im Hinblick auf die durch den Benutzer gesendeten Nachrichten durchzusetzen, was beispielsweise auf der Grundlage von Richtlinien erfolgen kann, die durch einen Administrator festgelegt wurden. Die Platzierung des PGP Universal Servers 290 im LAN 250 wie in 4 gezeigt erfolgt nur als ein Beispiel, und es sind andere Platzierungen und Konfigurationen möglich. In Abhängigkeit von der Platzierung des PGP Universal Servers 290 und der konkreten Konfiguration des LAN 250, in welcher der PGP Universal Server 290 möglicherweise eingesetzt wird, kann das Ausmaß der Steuerung über die verarbeiteten Nachrichten, die Gegenstand der Sicherheitscodierung sind, und insbesondere über die durch einen Benutzer gesendeten Nachrichten variieren.
Der PGP Universal Server 290 kann beispielsweise eingerichtet sein, um direkt alle ausgehenden Nachrichten zu verarbeiten (d. h. Nachrichten, die durch den Benutzer vom Desktopcomputer, vom Mobilgerät oder von einem anderen Computergerät des Benutzers an einen oder mehrere vorgesehene Empfänger gesendet werden), wobei er die Entscheidungen darüber, welche Nachrichten zu verschlüsseln und/oder zu signieren sind, wenn dies überhaupt der Fall ist, in Übereinstimmung mit Richtlinien trifft, die auf dem PGP Universal Server 290 entsprechend der Konfiguration durch den Administrator definiert sind. Wenn eine Richtlinie vorschreibt, dass eine Nachricht, die durch den Benutzer an eine bestimmte Domain gesendet werden soll oder die zu einem bestimmten Thema bzw. einem bestimmten Betreff gehört, beispielsweise verschlüsselt und mit PGP signiert werden soll, dann kann der PGP Universal Server 290 selbst die Nachricht vor der Übertragung verschlüsseln und signieren.
Alternativ kann der Benutzer – beispielsweise über eine PGP-fähige Messaging-Anwendung auf dem Computergerät des Benutzers, die mit dem PGP Universal Server 290 kommuniziert – Sicherheitsrichtliniendaten von dem PGP Universal Server 290 auf das Computergerät des Benutzers herunterladen. Der Benutzer der Anwendung kann dann auf der Grundlage der erhaltenen Sicherheitsrichtliniendaten beispielsweise angewiesen werden, die Nachricht zu verschlüsseln und zu signieren, bevor sie übertragen werden.
Dementsprechend wird mit dem PGP Universal Server 290 die Möglichkeit bereitgestellt, eine zentralisierte Richtlinie auf der Basis von Domains und anderen Mechanismen durchzusetzen.
Der PGP Universal Server 290 kann auch eingerichtet sein, um PGP-Schlüssel zu speichern, zu prüfen und anderweitig zu verwalten, und um PGP-Schlüssel von entfernten Schlüsselspeichern abzurufen, wenn die Schlüssel zum Codieren (z. B. Verschlüsseln und/oder Signieren) von Nachrichten benötigt werden. Wenn das durch einen Benutzer oder durch eine Anwendung angefordert wird, kann der PGP Universal Server 290 auch bei Bedarf gespeicherte oder abgerufene PGP-Schlüssel dem Benutzer bereitstellen.
Durch Übernahme des Einsatzes einer Policy Engine, wie sie zum Beispiel im hier beschriebenen Beispiel durch einen PGP Universal Server 290 implementiert ist, kann ein Großteil der Belastung, die mit dem Verarbeiten von sicheren Nachrichten (z. B. E-Mails), und insbesondere mit der fallspezifischen Entscheidung, welche Nachrichten sicher gesendet werden sollen und welche Sicherheitscodierung angewendet werden soll, auf die Policy Engine übertragen werden.
Wie bereits zuvor in dieser Beschreibung erwähnt wurde, beziehen sich die hier beschriebenen Ausführungsformen auf Systeme und Verfahren, bei denen die Durchführung von bestimmten Aufgaben initiiert wird, während ein Benutzer eine Nachricht verfasst und bevor vom Benutzer eine Anweisung zum Senden der Nachricht empfangen wird. Dies kann das "Prefetching" von Daten umfassen, die wahrscheinlich benötigt werden, um eine Nachricht zu senden, die sich im Prozess der Erstellung durch den Benutzer befindet.
Beispielsweise kann die Sicherheitsrichtlinie, die durch eine Policy Engine (wie sie z. B. in einem PGP Universal Server 290 oder einem in 4 nicht gezeigten EMS implementiert ist) definiert wird, durch Abrufen von Sicherheitsrichtliniendaten auf das Computergerät gewonnen werden, während ein Benutzer eine Nachricht verfasst. Konkret können sobald ein Benutzer beginnt, eine neue Nachricht zu verfassen, beispielsweise in einem Hintergrundprozess Sicherheitsrichtliniendaten aktualisiert werden, die durch die Policy Engine bereitgestellt werden.
Ein weiteres Beispiel: Sobald während des Verfassen einer Nachricht durch den Benutzer ein spezieller Empfänger identifiziert wird (z. B. durch Identifizieren des Empfängers in einem der Felder "An:", "Cc:" oder "Bcc" der durch eine Messaging-Anwendung bereitgestellten Benutzeroberfläche), dann kann in einem Hintergrundprozess das Zertifikat (bei dem es sich in einigen Implementierungen um einen PGP-Schlüssel handeln kann) des potenziellen Empfängers und der Status des Zertifikats (z. B. aus Daten, die von einem OCSP-Server 286 für ein S/MIME-Zertifikat abgerufen wurden) abgerufen werden. In einigen Fällen können die Zertifikatdaten und/oder der Zertifikatstatusdaten von einem Zertifikatspeicher auf dem Computergerät (z. B. einem Mobilgerät) abrufbar sein. In einigen anderen Fällen müssen die Zertifikatdaten und/oder die Zertifikatstatusdaten möglicherweise von einem Server abgerufen werden, der sich entfernt vom Computergerät befindet.
Das Initiieren der Durchführung solcher Aufgaben im Voraus wird allgemein die Wahrscheinlichkeit erhöhen, dass das Senden einer Nachricht aus Sicht des Benutzers schnell erfolgt, da die zum Abschließen des Sendeprozesses erforderlichen Aufgaben möglicherweise bereits abgeschlossen oder zumindest bereits initiiert wurden, wenn vom Benutzer die Anweisung zum Senden der Nachricht empfangen wird. Durch das Integrieren dieser Methodik in eine Messaging-Anwendung wie z. B. eine E-Mail-Messaging-Anwendung kann eine nahtlosere Benutzererfahrung gewährleistet werden, und insbesondere dann, wenn es sich bei dem Computergerät um ein Mobilgerät handelt.
Mindestens einige der Schritte der Ausführungsformen eines hier beschriebenen Verfahrens werden durch eine Anwendung durchgeführt, die im Computergerät ausgeführt wird und sich dort befindet. Die Anwendung kann eine E-Mail- oder eine andere Messaging-Anwendung sein, eine andere Anwendung, die mit der E-Mail- oder anderen Messaging-Anwendung gekoppelt oder anderweitig in diese integriert ist (z. B. als Addon-Komponente, die für die benötigte Funktionalität sorgt), oder eine andere Anwendung, die zur Durchführung solcher Schritte programmiert wurde.
Das Computergerät kann ein Desktopcomputer (was beispielsweise einen Laptopcomputer oder ein anderes Computergerät einschließen kann, mit dem ein Mobilgerät synchronisiert werden kann), ein Mobilgerät oder ein anderes Computer gerät sein. Das Computergerät kann mit einer Policy Engine (z. B. in einem PGP Universal Server 290 aus 4 implementiert) sein.
In den im Folgenden beschriebenen Ausführungsformen wird sich auf Nachrichten bezogen, die durch einen Benutzer eines Computergeräts verfasst werden. Allgemein muss der Benutzer zum Initiieren des Prozesses zum Verfassen einer Nachricht typischerweise zuerst ein entsprechendes Symbol oder Menüelement auswählen, das durch eine Messaging-Anwendung bereitgestellt wird (z. B. "Neue Nachricht erstellen"). Wenn der Benutzer wünscht, eine Nachricht auf der Grundlage einer zuvor empfangenen Nachricht zu verfassen (z. B. "Nachricht weiterleiten" oder "Auf Nachricht antworten"), dann muss der Benutzer möglicherweise zuerst die zuvor empfangene Nachricht auswählen, bevor er das entsprechende Symbol oder Menüelement auswählen kann.
Sobald der Benutzer das Erstellen bzw. Verfassen der Nachricht abgeschlossen hat, kann der Benutzer als nächstes die Anwendung anweisen, die Nachricht zu "senden" (z. B. durch Auswahl einer Schaltfläche "Nachricht senden" oder eines Menüelements). Insbesondere wenn die Nachricht sicher zu einem Empfänger übertragen werden soll, führt die Anwendung dann üblicherweise die weitere Verarbeitung der Nachricht durch (z. B. Überprüfung der geltenden Sicherheitsrichtlinie, Verschlüsseln der Nachricht usw.), bevor diese tatsächlich an den Empfänger der Nachricht gesendet wird, der durch den Benutzer identifiziert wurde, was im Hinblick auf eine Ausführungsform des Verfahrens im Folgenden beschrieben wird.
Zunächst Bezug nehmend auf 5A ist ein Flussdiagramm zur Darstellung der Schritte in einem allgemein als 300 bezeichneten Verfahren zum Verarbeiten von Nachrichten, die durch einen Benutzer eines Mobilgeräts verfasst werden, in einer exemplarischen Ausführungsform dargestellt.
In Schritt 310 wird eine Anforderung zum Verfassen einer Nachricht vom Benutzer empfangen.
In Schritt 320 wird das Auftreten von mindestens einem vordefinierten auslösenden Ereignis erkannt, das mit einer Nachricht assoziiert ist, die gerade durch einen Benutzer auf dem Computergerät verfasst wird.
In Schritt 330 wird für jedes auslösende Ereignis, dessen Auftreten in Schritt 320 erkannt wurde, die Durchführung von mindestens einer vordefinierten Aufgabe initiiert, die mit dem jeweiligen auslösenden Ereignis assoziiert ist, während die Nachricht durch den Benutzer verfasst wird, nachdem das Auftreten des jeweiligen auslösenden Ereignisses erkannt wurde. Vorzugsweise wird bzw. werden die Aufgabe(n), die mit dem jeweiligen auslösenden Ereignis assoziiert ist bzw. sind, sofort initiiert, nachdem das Auftreten des Ereignisses erkannt wird. Dementsprechend kann bzw. können die Aufgabe(n) initiiert werden, während der Benutzer die Nachricht verfasst und bevor durch den Benutzer das eigentliche Senden der Nachricht angewiesen wird.
Mit jeder Aufgabe, die in Schritt 330 initiiert werden soll, ist mindestens ein spezielles auslösendes Ereignis assoziiert. Wie oben erwähnt wurde, können mit demselben auslösenden Ereignis auch mehrere Aufgaben assoziiert sein.
Danach wird in Schritt 340 vom Benutzer eine Anweisung zum Senden der auf dem Computergerät verfassten Nachricht empfangen. Der Benutzer kann eine solche Anweisung geben, indem er beispielsweise auf eine Schaltfläche "Nachricht senden" drückt, die durch die Benutzeroberfläche der Anwendung bereitgestellt wird, oder indem er ein entsprechendes Menüelement "Nachricht senden" auswählt.
Alternativ kann sich der Benutzer entscheiden, die Nachricht nicht zu senden, indem er die Anwendung anweist, die Nachricht abzubrechen oder zu verwerfen [Schritte nicht dargestellt]. In diesem Fall werden die verbleibenden Schritte des Verfahrens 300 nicht ausgeführt.
In Schritt 350 wird die Nachricht, die entsprechend der Anweisung des Benutzers in Schritt 340 gesendet werden soll, weiter verarbeitet, um die Nachricht für die Übertragung vorzubereiten, sofern das erforderlich ist. Beispielsweise kann die Nachricht zur Übertragung umformatiert werden oder im Hinblick auf die Einhaltung einer IT-Richtlinie überprüft werden, welche für den Benutzer des Computergeräts gilt.
In Schritt 360 wird die Nachricht typischerweise an den bzw. die durch den Benutzer identifizierten Nachrichtenempfänger gesendet. Allerdings kann im Ergebnis der in Schritt 350 durchgeführten weiteren Verarbeitung ein Fehler oder ein anderer Zustand erkannt werden, und die Anwendung kann so eingerichtet sein, dass sie das Senden der Nachricht in Schritt 360 zurückhält oder abbricht.
In einer anderen Ausführungsform soll die durch den Benutzer zu sendende Nachricht sicher an die vorgesehenen Empfänger gesendet werden. Dementsprechend schließt in dieser anderen Ausführungsform die mindestens eine Aufgabe, die in Schritt 330 des Verfahrens 300 initiiert würde, speziell das Abrufen von sicherheitsbezogenen Daten ein, die zur weiteren Verarbeitung der durch den Benutzer verfassten Nachricht benötigt würden, falls der Benutzer die Anweisung zum Senden der Nachricht geben sollte. Es kann eine Vielzahl unterschiedlicher Typen von sicherheitsbezogenen Daten geben, die angefordert werden könnten, und mit jedem dieser Typen wird ein anderes auslösendes Ereignis assoziiert sein. Diese Abweichung des Verfahrens 300 wird anhand eines Beispiels unter Bezug auf 5B beschrieben.
Bezug nehmend auf 5B ist ein Flussdiagramm zur Darstellung der Schritte in einem allgemein als 300b bezeichneten Verfahren zum Verarbeiten von Nachrichten, die durch einen Benutzer eines Mobilgeräts verfasst werden, in einer anderen exemplarischen Ausführungsform dargestellt.
Wie beim Verfahren 300 wird im Schritt 310 des Verfahrens 300b zunächst eine Anforderung zum Verfassen einer Nachricht vom Benutzer empfangen.
Die Anwendung überwacht dann das Verfassen der Nachricht durch den Benutzer im Hinblick auf verschiedene auslösende Ereignisse, was beispielsweise mit den Schritten 320a und 320b gezeigt ist. Es sollte verständlich sein, dass in abweichenden Ausführungsformen andere auslösende Ereignisse, mit denen andere Aufgaben assoziiert sind, überwacht werden können.
Beispielsweise erkennt die Anwendung in Schritt 320a, wenn der Benutzer damit begonnen hat, die Nachricht zu verfassen. Es kann beispielsweise angenommen werden, dass der Benutzer mit dem Verfassen der Nachricht begonnen hat, wenn das entsprechende Symbol oder Menüelement ausgewählt wird (z. B. "Neue Nachricht erstellen", "Nachricht weiterleiten", "Auf Nachricht antworten"), wenn ein Fenster zum Eingeben von Text in die zu verfassende Nachricht angezeigt wird, wenn tatsächlich Text in das Fenster eingegeben wird oder wenn durch den Benutzer ein Dokument an die Nachricht angehängt wird, oder bei einer anderen Aktion laut Definition für eine bestimmte Implementierung.
In Schritt 330a wird die Ermittlung initiiert, ob aktualisierte Sicherheitsrichtliniendaten von einer Policy Engine (z. B. implementiert in einem PGP Universal Server, EMS oder einer anderen Policy Engine oder einem anderen Server, von der bzw. dem spezielle Codierungen für die durch einen Benutzer gesendeten Nachrichten vorgeschrieben und/oder durchgesetzt werden) abgerufen werden müssen. Dazu kann es erforderlich sein, jegliche Sicherheitsrichtliniendaten zu überprüfen, die bereits auf dem Computergerät (z. B. dem Mobilgerät) gespeichert sind, und zu ermitteln, ob diese Daten veraltet sind und aktualisiert werden müssen. Wie lange solche Daten auf dem Computergerät existieren dürfen, bevor sie als veraltet gelten, kann beispielsweise durch eine IT-Richtlinie oder eine andere Sicherheitsrichtlinie oder Gerätekonfiguration festgelegt werden.
Die in Schritt 330a vorgenommene Ermittlung wird initiiert, wenn in Schritt 320a erkannt wird, dass der Benutzer damit begonnen hat, die Nachricht zu verfassen, was dann das auslösende Ereignis wäre, das mit der speziellen Aufgabe des Ermittelns, ob aktualisierte Sicherheitsrichtliniendaten abgerufen werden müssen, assoziiert ist. Allerdings kann in abweichenden Ausführungsformen mit dieser speziellen Aufgabe auch ein anderes auslösendes Ereignis assoziiert sein.
Anschließend wird in Schritt 332a das Abrufen von Sicherheitsrichtliniendaten von der Policy Engine initiiert, wenn in Schritt 330a ermittelt wurde, dass aktualisierte Sicherheitsrichtliniendaten von der Policy Engine abgerufen werden müssen.
Der Ablauf der Verfahrensschritte wird mit Schritt 340 fortgesetzt. Es sollte verständlich sein, dass die in den Schritten 330a und/oder 332a initiierten Aufgaben bis zu dem Zeitpunkt, wo in Schritt 340 die Anweisung des Benutzers zum Senden der Nachricht empfangen wird, bereits abgeschlossen sein können oder auch nicht.
In einer abweichenden Ausführungsform wird der Schritt 330a möglicherweise nicht ausgeführt, und die Sicherheitsrichtliniendaten können in Schritt 332a von der Policy Engine automatisch abgerufen werden, wenn in Schritt 320a erkannt wird, dass der Benutzer damit begonnen hat, die Nachricht zu verfassen (oder beim Auftreten eines anderen assoziierten auslösenden Ereignisses). Das kann beispielsweise erwünscht sein, wenn bei jedem Verfassen einer neuen Nachricht die jeweils aktuellsten Sicherheitsrichtliniendaten abgerufen werden sollen, also unabhängig davon, wann zuletzt Sicherheitsrichtliniendaten vom Computergerät abgerufen wurden.
Obwohl ein Risiko besteht, dass die gerade verfasste Nachricht letztendlich nicht gesendet wird und damit die Sicherheitsrichtliniendaten eventuell unnötigerweise auf dem Computergerät aktualisiert bzw. durch dieses abgerufen wurden, wird ein Kompromiss eingegangen, wenn die Schritte 330a und/oder 332a ausgeführt werden. Denn wenn die verfasste Nachricht tatsächlich gesendet wird, dann kann ein Teil der Zeit oder sogar die gesamte Zeit, die zum Aktualisieren oder Abrufen der Sicherheitsrichtliniendaten benötigt wird (die ansonsten möglicherweise erst aufgewendet werden muss, nachdem der Benutzer die Anweisung zum Senden der Nachricht gibt), bereits im Voraus aufgewendet werden, wodurch der Sendeprozess aus Sicht des Benutzers nahtloser erscheint.
Inzwischen erkennt die Anwendung in Schritt 320b, wenn der Benutzer einen Empfänger identifiziert hat, an den die gerade verfasste Nachricht gesendet werden soll. Es kann angenommen werden, dass der Benutzer einen Nachrichtenempfänger identifiziert hat, wenn er beispielsweise den Empfänger in einem der Felder "An:", "Cc:" oder "Bcc:" in der durch eine Messaging-Anwendung bereitgestellten Benutzeroberfläche spezifiziert hat, oder wenn eine andere Aktion eingetreten ist, die möglicherweise für eine bestimmte Implementierung definiert ist.
In Schritt 330b wird das Abrufen von Zertifikatdaten aus einem Zertifikatspeicher initiiert, wenn in Schritt 320b erkannt wird, dass der Benutzer während des Verfassens der Nachricht einen Nachrichtenempfänger identifiziert hat, was dann das auslösende Ereignis ist, das mit der speziellen Aufgabe des Abrufens von Zertifikatdaten für den speziellen Nachrichtenempfänger assoziiert ist. Allerdings kann in abweichenden Ausführungsformen mit dieser speziellen Aufgabe auch ein anderes auslösendes Ereignis assoziiert sein.
Bei den Zertifikatdaten kann es sich um ein S/MIME-Zertifikat handeln oder beispielsweise um einen PGP-Schlüssel. Der Zertifikatspeicher kann sich auf dem Computergerät befinden, oder er kann sich auf einem Server befinden, der vom Computergerät entfernt ist (z. B. LDAP-Server 284 aus 4), von dem die Zertifikatdaten angefordert werden müssen.
Das in Schritt 330b initiierte Abrufen der Zertifikatdaten ist typischerweise mit einem Zertifikat assoziiert, das für eine Person oder eine juristische Person aus gestellt wurde, und insbesondere für den durch den Benutzer identifizierten Nachrichtenempfänger. Wenn der Nachrichtenempfänger ein Alias für mehrere Einzelempfänger ist (die z. B. durch eine Mailing-Listen- oder Verteilerlistenadresse identifiziert sind), dann kann in Schritt 330b möglicherweise das Abrufen eines Zertifikats für jeden der Einzelempfänger initiiert werden.
Es wird verständlich sein, dass das in Schritt 330b initiierte Abrufen von Zertifikatdaten für einen bestimmten Einzelempfänger möglicherweise nicht immer er folgreich ist, weil beispielsweise nicht für alle Personen ein Zertifikat ausgestellt wurde.
Obwohl ein Risiko besteht, dass die gerade verfasste Nachricht letztendlich nicht gesendet wird und damit die Zertifikate für potenzielle Nachrichtenempfänger eventuell unnötigerweise abgerufen wurden, wird ein Kompromiss eingegangen, wenn Schritt 330b ausgeführt wird. Denn wenn die verfasste Nachricht tatsächlich gesendet wird, dann kann ein Teil der Zeit oder sogar die gesamte Zeit, die zum Abrufen des erforderlichen Zertifikats bzw. der erforderlichen Zertifikate benötigt wird (die ansonsten möglicherweise erst aufgewendet werden muss, nachdem der Benutzer die Anweisung zum Senden der Nachricht gibt), bereits im Voraus aufgewendet werden, wodurch der Sendeprozess aus Sicht des Benutzers nahtloser erscheint.
Die im Folgenden beschriebenen Schritte 332b bis 336b können ausgeführt werden, wenn die im Ergebnis der Ausführung von Schritt 330b abgerufenen Zertifikatdaten in einem Zertifikat bereitgestellt werden, für das der Zertifikatstatus verifiziert werden kann.
In Schritt 332b erkennt die Anwendung, wenn die Zertifikatdaten für den identifizierten Nachrichtenempfänger durch das Computergerät empfangen wurden, wie das in Schritt 330b initiiert wurde.
In Schritt 334b wird für das abgerufene Zertifikat eine Ermittlung initiiert, ob aktualisierte Zertifikatstatusdaten abgerufen werden müssen (z. B. vom OCSP-Server 286 aus 4). Das kann das Überprüfen eines Eintrags dazu erfordern, wann beispielsweise ein im Ergebnis der Ausführung von Schritt 330b abgerufenes Zertifikat zuletzt im Hinblick auf seinen Widerrufstatus verifiziert wurde. Wie lange diese Statusdaten auf dem Computergerät existieren dürfen, bevor sie als veraltet gelten, kann beispielsweise durch eine IT-Richtlinie oder eine andere Sicherheitsrichtlinie oder Gerätekonfiguration festgelegt werden.
Anschließend wird in Schritt 336b das Abrufen von Zertifikatstatusdaten (z. B. zum Widerrufstatus) für ein oder mehrere Zertifikate initiiert, wenn in Schritt 334b ermittelt wurde, dass aktualisierte Zertifikatstatusdaten abgerufen werden müssen.
Der Ablauf der Verfahrensschritte wird mit Schritt 340 fortgesetzt. Es sollte verständlich sein, dass die in den Schritten 330b, 334b und/oder 336b initiierten Aufgaben bis zu dem Zeitpunkt, wo in Schritt 340 die Anweisung des Benutzers zum Senden der Nachricht empfangen wird, bereits abgeschlossen sein können oder auch nicht.
In einer abweichenden Ausführungsform wird der Schritt 334b möglicherweise nicht ausgeführt, und die Zertifikatstatusdaten können in Schritt 336b automatisch abgerufen werden, wenn erkannt wird, dass das Zertifikat für einen Nachrichtenempfänger im Ergebnis der Ausführung von Schritt 330b abgerufen wurde, oder beim Erkennen des Auftretens eines anderen auslösenden Ereignisses. Das kann beispielsweise erwünscht sein, wenn bei jedem Abrufen eines Zertifikats die jeweils aktuellsten Zertifikatstatusdaten abgerufen werden sollen, also unabhängig davon, wann zuletzt der Widerrufstatus für das Zertifikat verifiziert wurde.
Obwohl ein Risiko besteht, dass die gerade verfasste Nachricht letztendlich nicht gesendet wird und damit die Zertifikatstatusdaten für ein oder mehrere Zertifikate eventuell unnötigerweise aktualisiert bzw. abgerufen wurden, wird ein Kompromiss eingegangen, wenn die Schritte 334b und/oder 336b ausgeführt werden. Denn wenn die verfasste Nachricht tatsächlich gesendet wird, dann kann ein Teil der Zeit oder sogar die gesamte Zeit, die zum Aktualisieren oder Abrufen der Zertifikatstatusdaten benötigt wird (die ansonsten möglicherweise erst aufgewendet werden muss, nachdem der Benutzer die Anweisung zum Senden der Nachricht gibt), bereits im Voraus aufgewendet werden, wodurch der Sendeprozess aus Sicht des Benutzers nahtloser erscheint.
Die Zertifikatstatusdaten, für die in Schritt 336b das Abrufen initiiert wird, kann auch andere zertifikatbezogene Daten einschließen als solche, die zum Verifizie ren des Widerrufstatus verwendet werden. Beispielsweise kann in diesem Schritt auch das Abrufen von Daten initiiert werden, die zum Verifizieren des Vertrauensstatus, der Gültigkeit (z. B. des Ablaufen) oder der Schlüsselstärke eines im Ergebnis von Schritt 330b abgerufenen Zertifikats verwendet werden.
In dieser exemplarischen Ausführungsform gehören zu den Daten die durch das "Prefetching" im Voraus abgerufen werden, während eine Nachricht durch den Benutzer verfasst wird, Sicherheitsrichtliniendaten, Zertifikatdaten und Zertifikatstatusdaten. Das Abrufen einer Teilmenge dieser Daten, von zusätzlichen Daten und/oder von anderen Daten kann in abweichenden Ausführungsformen initiiert werden, und das Abrufen von bestimmten Daten kann mit einem oder mehreren unterschiedlichen auslösenden Ereignissen assoziiert sein.
Es wird verständlich sein, dass zusätzliche Instanzen der Schritte 320b und 330b sowie Instanzen der Schritte 332b bis 336b, mit denen der Status von Zertifikaten verifiziert werden kann, wiederholt und gleichzeitig ausgeführt werden können, um das Abrufen von Zertifikatdaten und optional von Zertifikatstatusdaten für mehrere Nachrichtenempfänger zu initiieren, wenn durch den Benutzer für dieselbe Nachricht mehrere Nachrichtenempfänger identifiziert werden. In gleicher Weise können Instanzen der Schritte 320b bis 336b und der Schritte 320a bis 332a in parallelen Hintergrundprozessen gleichzeitig ausgeführt werden. Es können andere auslösende Ereignisse überwacht werden, und deren assoziierte Aufgaben können ebenfalls in parallelen Hintergrundprozessen gleichzeitig initiiert werden.
In Schritt 340 wird vom Benutzer eine Anweisung zum Senden der auf dem Computergerät verfassten Nachricht empfangen. Der Benutzer kann eine solche Anweisung geben, indem er beispielsweise auf eine Schaltfläche "Nachricht senden" drückt, die durch die Benutzeroberfläche der Anwendung bereitgestellt wird, oder indem er ein entsprechendes Menüelement "Nachricht senden" auswählt. Alternativ kann sich der Benutzer entscheiden, die Nachricht nicht zu senden, indem er die Anwendung anweist, die Nachricht abzubrechen oder zu verwerfen [Schritte nicht dargestellt]. In diesem Fall werden die verbleibenden Schritte des Verfahrens 300b nicht ausgeführt.
In Schritt 350 wird die Nachricht, die entsprechend der Anweisung des Benutzers in Schritt 340 gesendet werden soll, weiter verarbeitet, um die Nachricht für die Übertragung vorzubereiten, sofern das erforderlich ist. Beispielsweise kann die Nachricht zur Übertragung umformatiert werden oder im Hinblick auf die Einhaltung einer IT-Richtlinie überprüft werden.
In diesem Schritt kann die Nachricht weiter verarbeitet werden, indem die Daten verwendet werden, die in den vorherigen Schritten des Verfahrens 300b abgerufen wurden. Beispielsweise können die Sicherheitsrichtliniendaten, die im Ergebnis der Ausführung von Schritt 332a abgerufen wurden, verwendet werden, um zu ermitteln, welche spezielle Sicherheitscodierung auf die Nachricht angewendet werden soll, bevor diese gesendet wird. Die Zertifikatdaten, die im Ergebnis der Ausführung von Schritt 330b abgerufen wurden, können verwendet werden, um die Nachricht für die Übertragung zu codieren, und die Zertifikatstatusdaten, die im Ergebnis der Ausführung von Schritt 336b abgerufen wurden, können verwendet werden, um den Status des Zertifikats zu verifizieren, bevor dessen Verwendung zur Codierung der Nachricht für die Übertragung zugelassen wird.
Bei der weiteren Verarbeitung der Nachricht kann in Schritt 350 auch zusätzliche Einflussnahme durch den Benutzer erforderlich sein. Wenn es beispielsweise ein Problem mit dem Status eines Zertifikats gibt, oder wenn ein Zertifikat für einen bestimmten Empfänger nicht gefunden wird, dann kann der Benutzer zur Bestätigung aufgefordert werden, ob die Nachricht trotzdem gesendet werden soll. Wenn mehrere Zertifikate empfangen wurden, die potenziell mit einem identifizierten Empfänger assoziiert sind, dann kann der Benutzer aufgefordert werden, das richtige Zertifikat auszuwählen. Wenn der Benutzer eine bestimmte Codierung ausgewählt hat, die nicht mit den abgerufenen Sicherheitsrichtliniendaten übereinstimmt, dann kann der Benutzer zur Bestätigung aufgefordert werden, ob die Nachricht trotzdem gesendet werden soll.
Dies sind lediglich Beispiele, und bei der weiteren Verarbeitung der Nachricht in Schritt 350 können in abweichenden Ausführungsformen auch andere Aufgaben durchgeführt werden.
In Schritt 360 wird die Nachricht typischerweise an den bzw. die durch den Benutzer identifizierten Nachrichtenempfänger gesendet. Allerdings kann im Ergebnis der in Schritt 350 durchgeführten weiteren Verarbeitung ein Fehler oder ein anderer Zustand erkannt werden, und die Anwendung kann so eingerichtet sein, dass sie das Senden der Nachricht in Schritt 360 zurückhält oder abbricht.
Die Schritte der hier beschriebenen Verfahren können in Form von ausführbaren Softwareanweisungen bereitgestellt werden, die auf einem computerlesbaren Medium gespeichert sind, was auch übertragbare Medien einschließen kann.
Die Beschreibung der Erfindung erfolgte im Hinblick auf eine Reihe von Ausführungsformen. Dem Fachmann auf dem Gebiet der Technik wird jedoch verständlich sein, dass andere Varianten und Modifikationen ausgeführt werden können, ohne vom Umfang der Erfindung abzuweichen, der in den hier beigefügten Ansprüchen definiert ist.

Claims

Verfahren zum Verarbeiten von Nachrichten, die durch einen Benutzer eines Computergeräts (100) verfasst werden, wobei die Schritte des Verfahrens durch mindestens eine auf dem Computergerät (100) ausgeführte Anwendung durchgeführt werden und das Verfahren die folgenden Schritte umfasst: das Empfangen (310) einer Anforderung von einem Benutzer zum Verfassen einer Nachricht; das Initiieren (332a, 330b) der Durchführung von mindestens einem des Folgenden: das Abrufen von Sicherheitsrichtliniendaten aus einer Policy Engine und das Abrufen von Zertifikatdaten aus einem Zertifikatspeicher, die zur weiteren Verarbeitung der Nachricht erforderlich sind; und das Empfangen (340) einer Anweisung von dem Benutzer zum Senden der auf dem Computergerät (100) verfassten Nachricht, wobei der Schritt des Initiierens (332a, 330b) vor dem Schritt des Empfangens einer Anweisung von dem Benutzer zum Senden der Nachricht (340) durchgeführt wird.
Verfahren gemäß Anspruch 1, des Weiteren umfassend die folgenden Schritte: das weitere Verarbeiten (350) der Nachricht mithilfe der abgerufenen Daten; und das optionale Senden (360) der Nachricht.
Verfahren gemäß Anspruch 1 oder Anspruch 2, des Weiteren umfassend den Schritt des Erkennens (320a), wenn der Benutzer mit dem Verfassen der Nachricht begonnen hat, und wobei das Abrufen von Sicherheitsrichtliniendaten aus einer Policy Engine im Schritt des Initiierens (332a) initiiert wird, wenn er kannt wird (320a), dass der Benutzer mit dem Verfassen der Nachricht begonnen hat.
Verfahren gemäß Anspruch 1 oder Anspruch 2, des Weiteren umfassend den Schritt des Erkennens (320a), wenn der Benutzer mit dem Verfassen der Nachricht begonnen hat, und den Schritt des Initiierens (330a) einer Ermittlung, ob aktualisierte Sicherheitsrichtliniendaten aus einer Policy Engine abgerufen werden müssen; wobei die Ermittlung, ob aktualisierte Sicherheitsrichtliniendaten aus einer Policy Engine abgerufen werden müssen, initiiert wird (330a), wenn erkannt wird (320a), dass der Benutzer mit dem Verfassen der Nachricht begonnen hat, und wobei das Abrufen von Sicherheitsrichtliniendaten aus einer Policy Engine nur dann initiiert wird (332a), wenn ermittelt wird, dass aktualisierte Sicherheitsrichtliniendaten aus einer Policy Engine abgerufen werden müssen.
Verfahren gemäß jedem der Ansprüche 1 bis 4, des Weiteren umfassend den Schritt des Erkennens (320b), wenn der Benutzer während des Verfassens der Nachricht einen Nachrichtenempfänger identifiziert hat, und wobei das Abrufen von Zertifikatdaten aus einem Zertifikatspeicher für ein mit dem Nachrichtenempfänger assoziiertes Zertifikat in dem Schritt des Initiierens (330b) initiiert wird, wenn erkannt wird (320b), dass der Benutzer während des Verfassen der Nachricht den Nachrichtenempfänger identifiziert hat.
Verfahren gemäß Anspruch 5, wobei sich der Zertifikatspeicher auf einem Server (284) befindet, der vom Computergerät (100) entfernt ist.
Verfahren gemäß Anspruch 5 oder Anspruch 6, wobei es sich bei den Zertifikatdaten um ein S/MIME-Zertifikat handelt.
Verfahren gemäß Anspruch 5 oder Anspruch 6, wobei es sich bei den Zertifikatdaten um einen PGP-Schlüssel handelt.
Verfahren gemäß jedem der Ansprüche 1 bis 8, des Weiteren umfassend den Schritt des Erkennens (332b), wenn Zertifikatdaten auf das Computergerät (100) abgerufen wurden, und den Schritt des Initiierens (336b) des Abrufens von Zertifikatstatusdaten; wobei das Abrufen von Zertifikatstatusdaten initiiert wird (336b), um den Status eines Zertifikats zu verifizieren, wenn erkannt wird (332b), dass die Zertifikatdaten auf das Computergerät (100) abgerufen wurden.
Verfahren gemäß jedem der Ansprüche 1 bis 8, des Weiteren umfassend den Schritt des Erkennens (332b), wenn Zertifikatdaten auf das Computergerät (100) abgerufen wurden, den Schritt des Initiierens (334b) einer Ermittlung, ob aktualisierte Zertifikatstatusdaten abgerufen werden müssen, und den Schritt des Initiierens (336b) des Abrufen von Zertifikatstatusdaten; wobei die Ermittlung, ob aktualisierte Zertifikatstatusdaten abgerufen werden müssen, initiiert wird (334b), wenn erkannt wird (332b), dass Zertifikatdaten auf das Computergerät 100 abgerufen wurden, und wobei das Abrufen von Zertifikatstatusdaten nur darin initiiert wird (336b), wenn ermittelt wird, dass aktualisierte Zertifikatstatusdaten abgerufen werden müssen.
Computerlesbares Medium zum Speichern eines Computerprogramms, das bei seiner Ausführung auf einem Computer sämtliche Schritte eines Verfahrens gemäß jedem der vorherigen Ansprüche durchführt.
System zum Verarbeiten von Nachrichten, die durch einen Benutzer eines Computergeräts (100) verfasst werden, wobei das System eine mit dem Computergerät (100) verbundene Policy Engine umfasst, und wobei das System umfasst: Mittel (102) zum Empfangen einer Anforderung von einem Benutzer zum Verfassen einer Nachricht; Mittel (102) zum Empfangen einer Anweisung von dem Benutzer zum Senden der auf dem Computergerät (100) verfassten Nachricht; und Mittel (102) zum Initiieren der Durchführung von mindestens einem des Folgenden: das Abrufen von Sicherheitsrichtliniendaten aus einer Policy Engine und das Abrufen von Zertifikatdaten aus einem Zertifikatspeicher, die zur weiteren Verarbeitung der Nachricht erforderlich sind, bevor die Anweisung von dem Benutzer zum Senden der Nachricht empfangen wird.
System gemäß Anspruch 12, wobei sich die Policy Engine auf einem Gerät befindet, das vom Computergerät (100) entfernt ist.
System gemäß Anspruch 12 oder Anspruch 13, wobei die Policy Engine in einem PGP Universal Server (290) implementiert ist.
System gemäß Anspruch 12 oder Anspruch 13, wobei die Policy Engine in einem EMS implementiert ist.
System gemäß jedem der Ansprüche 12 bis 15, wobei es sich bei dem Computergerät (100) um ein Mobilgerät (100) handelt.