PatentDe  


Dokumentenidentifikation DE69913953T2 23.12.2004
EP-Veröffentlichungsnummer 0001075750
Titel VERFAHREN UND VORRICHTUNG ZUR VERARBEITUNG VON ELEKTRONISCHEN POST
Anmelder Nokia Corp., Espoo, FI
Erfinder MERTAMA, Markus, FIN-33100 Tampere, FI;
HYTTINEN, Teuvo, FIN-33720 Tampere, FI;
MÄENPÄÄ, Jari, FIN-33240 Tampere, FI
Vertreter COHAUSZ & FLORACK, 40211 Düsseldorf
DE-Aktenzeichen 69913953
Vertragsstaaten DE, FR, GB, NL
Sprache des Dokument EN
EP-Anmeldetag 22.04.1999
EP-Aktenzeichen 999169402
WO-Anmeldetag 22.04.1999
PCT-Aktenzeichen PCT/FI99/00328
WO-Veröffentlichungsnummer 9957619
WO-Veröffentlichungsdatum 11.11.1999
EP-Offenlegungsdatum 14.02.2001
EP date of grant 02.01.2004
Veröffentlichungstag im Patentblatt 23.12.2004
IPC-Hauptklasse H04L 12/58

Beschreibung[de]

Die vorliegende Erfindung betrifft ein Verfahren und eine Vorrichtung, die das Verfahren zum Verarbeiten einer E-Mail-Nachricht implementiert. Bei dem Verfahren wird eine erste Nachricht durch einen E-Mail-Server gebildet, wobei die Nachricht Information über die Bauteile der E-Mail-Nachricht, die am Server angekommen ist, sowie über Attribute bezüglich des Inhalts der Bauteile umfaßt, wobei die erste Nachricht vom E-Mail-Server zu einem Terminal übertragen wird.

E-Mail ist ein Telematikdienst, bei dem Nachrichten in einem Computerspeicher gespeichert werden können, damit sie von einem Empfänger gelesen werden. Zur Implementierung von E-Mail sind E-Mail-Server, die als Datenübertragungs-Gateways arbeiten, an ein Telekommunikationsnetz angeschlossen, wobei die Gateways die E-Mail-Nachricht untereinander übertragen, bis ein Zielcomputer erreicht ist. Der Empfangscomputer speichert die E-Mail-Nachricht in einem Speichermittel, wie einem E-Mail-Nachrichtenordner, auf den ein Benutzer zum Einsehen seiner Mail und Übertragen der Mail unter Verwendung einer lokalen Mailclientsoftware weiter in seinen Computer zugreifen kann. Mailclientsoftwares folgen einem ausgewählten Leseprotokoll, für das das POP (Post Office Protocol) und das IMAP (Internet Message Access Protocol) als Beispiele dienen können.

Anfangs unterstützte der E-Mail-Bau hauptsächlich die Übertragung von englischem Text zwischen zwei Benutzern über ein TCP/IP- (Transmission Control Protocol/Internet Protocol-) Netzwerk. Als ihre Nutzung sich ausbreitete, gab es einen wachsenden Bedarf, über unterschiedliche Arten von Netzwerken unterschiedliche Arten von E-Mail-Nachrichten zu übertragen, die auch Text, Graphiken, Bilder, Sprache oder ihre Kombinationen in Verwendung auch anderer Sprachen enthalten. Als Ergebnis einer gemeinsamen Standardisierungsarbeit wurde eine allgemeine Spezifizierung, die den Bau von E-Mail-Nachrichten definiert, d. h. MIME (Multipurpose Internet Mail Extensions) entwickelt. Als Ergebnis der Entwicklungsarbeit ist es einfacher, E-Mail-Nachrichten, die einen klaren Bau aufweisen, im Internet zu übertragen, und die Überschriften von E-Mail-Nachrichten, die in einem Textformat erstellt sind, können Zeichen enthalten, die nicht im US-ASCII-Zeichensatz (American Standard Code for Information Interchange) beinhaltet sind. Eine E-Mail-Nachricht kann in Teile geparst werden, und eine Beschreibung des Inhalts des fraglichen Bauteils kann in jedem Bauteil beinhaltet sein. Es können unterschiedliche E-Mail-Nachrichtformate auf die Bauteile einer E-Mail-Nachricht angewendet sein, und die Bauteile können außerdem mehrteilige Unterstrukturen aufweisen. Die Teile in Textformat können auch Zeichen enthalten, die nicht im US-ASCII-Zeichensatz enthalten sind.

Eine Grundvoraussetzung zum Verarbeiten von Daten in unterschiedlichen Formaten ist jedoch, daß ein E-Mail-Client die Nutzung von ausreichenden Mitteln zum Verarbeiten der Daten wie erforderlich aufweist. Es werden Aufrufprogramme sowie Konvertierungsprogramme zum Editieren der Daten in ein Format, das durch die Aufrufprogramme identifizierbar ist, gebraucht, was Anforderungen an die Leistung des Computers stellt, der zum Verarbeiten benutzt wird. Insbesondere bei Computern mit begrenzter Prozessorausgabe und Speicherkapazität ist das Verarbeiten mehrerer Dateiformate problematisch. Aufgrund des zügigen Fortschreitens der Softwareentwicklung ändern sich die Versionen der benutzten Anwendungen schnell, und daher muß sich der Client ständig um die Aktualisierung der verwendeten Software bemühen. Es sollte außerdem beachtet werden, daß MIME im Grunde eine Anwendungsnorm ist und individuelle Lösungen, die auf seiner Grundlage implementiert sind, Kompatibilitätsprobleme aufweisen können, die den Benutzer frustrieren.

Die europäische Patentveröffentlichung EP 0719016 A2 offenbart eine Technik, bei der Kommunikationsgeräte wie PC, Arbeitsplätze, Telefone auch dann zur Ausführung von Datenkommunikation imstande sind, wenn die Datenformate unterschiedlich sind, z. B. Zeichen, Bilder, Figuren, Sprache, Musik usw. Dies wird durch Aufweisen von Vermittlungsmitteln in den Kommunikationsgeräten zum Kommunizieren mit anderen Geräten ausgeführt, um festzustellen, ob die Empfangsgeräte die geeigneten Ressourcen zum Wiedergeben der Daten aufweisen. Im Gegensatz dazu sieht die vorliegende Erfindung ein Verfahren zum Verarbeiten von Multimedia-E-Mail vor, das in Kooperation mit mobilen Dienstanbietern zum Gebrauch mit mobilen Netzwerken mit hoher Bitrate wie jenen, die gemäß General Packet Radio Service (GPRS) und dritter Generation und darüber hinaus arbeiten, geeignet ist.

US-Patent 5,283,887 offenbart ein Verfahren zum automatischen Konvertieren eines Dokumentformats auf Grundlage von Benutzereinstellungen für E-Mailsysteme. Zum Beispiel könnten Dokumente, die in einem bestimmten Textverarbeitungsformat gesendet werden, nicht in dem Format sein, das der Empfänger eingestellt hat. Das Verfahren beinhaltet das Vergleichen einer Benutzereinstellungentabelle, die Benutzerdokumenteinstellungen enthält, mit dem empfangenen Dokument zusammen mit einem Tag, das dem Dokument beigefügt ist und das Format identifiziert. Das Dokument wird konvertiert, wenn das empfangene Dokumentformat dem eingestellten Format, das in der Benutzereinstellungentabelle aufgeführt ist, nicht entspricht.

US-Patent 5,497,319 offenbart ein System zum automatischen Übersetzen und Senden von Text von einem Sender in einer Sprache an einen Empfänger in einer anderen Sprache, zum Beispiel vom Englischen ins Französische. In einer bevorzugten Ausführungsform ist eine Telekommunikationsschnittstelle zum Senden von übersetztem, elektronischen Ausgabetext an eine E-Mailadresse eines Empfängers an ein Faxmodem gekoppelt.

Die PCT-Veröffentlichung WO 94/06230 offenbart ein System zur Multimedia-Nachrichtenübertragung, bei dem Dateien verschiedener Formate wie Text, Bilddaten und anwendungsspezifische Daten automatisch analysiert und in Datenformate konvertiert werden, die mit dem Medium des ausgewählten Ziels wie E-Mail, Faxgeräten und Druckern kompatibel sind.

Die PCT-Veröffentlichung WO 98/15091 offenbart ein Informationsübertragungssystem zwischen einer Zentraleinrichtung und verschiedenen Datenterminals, die unterschiedliche Fähigkeiten oder Merkmale aufweisen können. Das Datenterminal weist einen zugeordneten Modellcode auf, der jedesmal an die Zentraleinrichtung gesendet wird, wenn das Datenterminal mit der Zentraleinrichtung verbunden wird. Die Zentraleinrichtung stellt die Fähigkeiten des Datenterminals aus dem Modellcode fest und sendet die Information auf einer Ebene, die für das Datenterminal geeignet ist.

Es wurde nun ein Verfahren und eine Vorrichtung, die das Verfahren implementiert, erfunden, um die oben dargelegten Nachteile zu verringern. Es ist kennzeichnend für das Verfahren gemäß der Erfindung, daß eine zweite Nachricht durch ein Terminal gebildet wird, wobei die Nachricht Information über zumindest ein Verarbeiten enthält, das sich an den Inhalt der E-Mail-Nachricht richtet und durch einen Server auszuführen ist; wobei die zweite Nachricht an den Server übertragen wird; wobei das Verarbeiten durch den Server in Reaktion auf die zweite Nachricht ausgeführt wird; und wobei die verarbeitete Nachricht oder ein Teil davon von dem E-Mail-Server an das Terminal übertragen wird.

Eine Aufgabe der Erfindung ist außerdem ein Terminal gemäß Anspruch 8 zum Nutzen von E-Mail-Diensten, die über ein Telekommunikationsnetzwerk implementiert sind, wobei das Terminal Mittel zum Empfangen einer ersten Nachricht von einem ersten Server umfaßt, wobei die erste Nachricht Information über die Bauteile der E-Mail-Nachricht und die Attribute bezüglich des Inhalts der Bauteile umfaßt. Es ist kennzeichnend für das Terminal, daß das Terminal Mittel zum Bilden einer zweiten Nachricht, wobei die zweite Nachricht Information über zumindest ein Verarbeiten in dem Server umfaßt, das sich an den Inhalt der E-Mail-Nachricht richtet, und Mittel zum Übertragen der zweiten Nachricht oder ihrer Teile zum Server umfaßt.

Eine weitere Aufgabe der vorliegenden Erfindung ist ein E-Mail-Server gemäß Anspruch 9, umfassend eine Datenbank zum Speichern von E-Mail-Nachrichten, Mittel zum Bilden einer ersten Nachricht, die Information über die Bauteile einer E-Mail-Nachricht, welche sich in der Datenbank des E-Mail-Servers befindet, und die Attribute bezüglich des Inhalts der Bauteile umfaßt, und Mittel zum Übertragen der ersten Nachricht von dem E-Mail-Server zu einem Terminal. Es ist kennzeichnend für den E-Mail-Server, daß der E-Mail-Server Mittel zum Empfangen einer zweiten Nachricht, die vom Terminal übertragen wird, wobei die zweite Nachricht Information über zumindest ein Verarbeiten im Server umfaßt, das sich an den Inhalt der E-Mail-Nachricht richtet, Mittel zum Ausführen des verarbeitens in Reaktion auf den Empfang der zweiten Nachricht und Mittel zum Übertragen der verarbeiteten Nachricht oder ihrer Teile vom E-Mail-Server zu einem Terminal umfaßt.

Eine weitere Aufgabe der Erfindung ist ein Datenübertragungssystem, das digitale E-Mail-Dienste implementiert, gemäß Anspruch 11, umfassend ein oder mehrere Terminals, E-Mail-Server, Datenbanken in Verbindung mit den E-Mail-Servern sowie Datenübertragungsnetzwerke, wobei die E-Mail-Server Mittel zum Bilden einer ersten Nachricht, wobei die Nachricht Information über die Bauteile der E-Mail-Nachricht, die sich in der Datenbank des E-Mail-Servers befindet, und die Attribute bezüglich des Inhalts der Bauteile umfaßt, und Mittel zum Übertragen der ersten Nachricht zu einem Terminal umfaßt. Es ist kennzeichnend für das Datenübertragungssystem, daß das Terminal Mittel zum Bilden einer zweiten Nachricht, wobei die zweite Nachricht Information über zumindest ein Verarbeiten umfaßt, das sich an den Inhalt der E-Mail-Nachricht richtet und im Server ausgeführt wird, und Mittel zum Übertragen der zweiten Nachricht umfaßt, wobei der E-Mail-Server Mittel zum Empfangen der zweiten Nachricht, Mittel zum Ausführen des Verarbeitens in Reaktion auf die zweite Nachricht und Mittel zum Übertragen der verarbeiteten Nachricht oder ihrer Teile vom E-Mail-Server zum Terminal umfaßt.

Die Erfindung gründet sich darauf, daß ein Server eine empfangene E-Mail-Nachricht in einem geparsten Format meldet, woraufhin ein Client über den Bau der E-Mail-Nachricht und Attribute bezüglich des Inhalts der Bauteile informiert wird. Diese könnten z. B. die Darstellung der Information, die in einem Bauteil enthalten ist, die Sprache des Texts, die in einem Bauteil enthalten ist, usw. sein. Der Client stellt fest, welche Verarbeitungstätigkeit an die E-Mail-Nachricht zu richten ist, bildet eine Nachricht, die dem Verarbeiten durch das Terminal entspricht, und sendet sie zu dem E-Mail-Server. In Reaktion auf die empfangene Nachricht führt der E-Mail-Server die Verarbeitungstätigkeit aus, die durch den Client ausgewählt wurde. Aufgrund der Lösung gemäß der vorliegenden Erfindung kann eine Tätigkeit, die an den Inhalt der E-Mail-Nachricht gerichtet ist, daher auf eine zentralisierte Art und Weise durch einen Server, der mit größeren Ressourcen ausgestattet ist, implementiert werden.

Aufgrund der Erfindung können neue Dienste, die sich an das Verarbeiten des Inhalts von E-Mail-Nachrichten richten, für einen Server auf einfache Weise geschaffen sein. Die Ressourcen, die zur Implementierung der Dienste erforderlich sind, können auf Server konzentriert sein, die häufig erheblich mehr Kapazität zur Implementierung der Dienste als das Terminal des Benutzers aufweisen. Der verfügbare Umfang von Werkzeugen kann umfassender sein, und die Softwarewartung kann aufgrund der Erfindung auf eine zentralisierte Weise durch den Dienstanbieter ausgeführt werden. Die Erfindung ist insbesondere für mobile Teilnehmer nützlich, die häufig Terminals mit begrenzter Kapazität haben. Da die Lösung gemäß der Erfindung außerdem leicht für Terminal- und Servergeräte implementiert werden kann, kann mittels einer Erweiterung, die leicht an den Standard angepaßt werden kann, ein erheblicher Vorteil im Vergleich mit bestehenden Lösungen erzielt werden.

Im folgenden wird die vorliegende Erfindung unter Bezugnahme auf die beiliegenden Zeichnungen detailliert besprochen.

Es zeigen:

1 ein Blockdiagramm, das die Implementierung von E-Mail im Prinzip darstellt;

2 ein Ablaufdiagramm, das Phasen zum Ausgeben einer E-Mail-Nachricht, die an einem E-Mail-Server angekommen ist, an ein Terminal eines Teilnehmers darstellt, welches gemäß dem Stand der Technik implementiert ist;

3 ein Ablaufdiagramm, das das Grundprinzip einer Lösung gemäß der Erfindung in Verbindung mit dem Verarbeiten eines Dateiformats darstellt, das in einer E-Mail-Nachricht enthalten ist;

4 ein Signalgebungsdiagramm, das eine Datenübertragung zwischen einem Teilnehmerterminal CLIENT und einem SERVER darstellt, wenn ein E-Mail-Dienst auf eine Art und Weise gemäß einer ersten Ausführungsform der Erfindung implementiert ist;

5 ein Blockdiagramm, das eine Anordnung zum Nutzen von E-Mail-Diensten über ein mobiles GSM-Kommunikationsnetzwerk zeigt;

6 ein Blockdiagramm, das eine Implementierung eines Terminals gemäß der Erfindung darstellt;

7 ein Ablaufdiagramm, das den Betrieb eines Terminals in einer Anordnung gemäß der Erfindung darstellt;

8 ein Ablaufdiagramm, das eine Implementierung eines E-Mail-Servers gemäß der Erfindung darstellt;

9 ein Signalgebungsdiagramm, das eine Datenübertragung zwischen einem Teilnehmerterminal CLIENT und einem SERVER darstellt, wenn ein E-Mail-Dienst auf eine Art und Weise gemäß einer zweiten Ausführungsform der Erfindung implementiert ist;

10 ein Signalgebungsdiagramm, das das Verarbeiten einer ankommenden E-Mail-Nachricht darstellt, wenn die E-Mail-Nachricht, die in ein korrektes Dateiformat konvertiert wurde, auch durch Übersetzungswerkzeuge, die an einem Server verfügbar sind, übersetzt werden soll;

11 ein Signalgebungsdiagramm, das die Implementierung einer Ausführungsform durch Nutzung des Arguments ALTERNATIVEBODY in Verbindung mit der Konvertierung eines Dateiformats darstellt.

Das Blockdiagramm in 1 stellt die Implementierung von E-Mail im Prinzip dar. Ein Terminal 10 umfaßt eine Bedieneroberfläche und übernimmt die Aufgaben bezüglich der Darstellung und Verarbeitung von E-Mail. Das Terminal 10 wurde mit einem Netzwerk 13 verbunden, das einen Datenübertragungsmechanismus zum Implementieren der Datenübertragung zwischen dem Terminal 10 und einem Server 11 vorsieht. Der Server 11 übernimmt das Empfangen ankommender E-Mail-Nachrichten und das Übertragen der abgehenden Nachrichten über das Netzwerk 13. Datenbanken 12, die Benutzer- oder benutzergruppenspezifische Mailboxen umfassen, in denen die E-Mail-Nachrichten, welche von dem Netzwerk 13 und dem Terminal 10 angekommen sind, gespeichert sind, wurden in Verbindung mit dem Server gekoppelt. Ein Datenübertragungssystem, das E-Mail-Dienste implementiert, umfaßt normalerweise mehrere Terminals 10, 15, Server 11, 16, Datenbanken 12 und Netzwerke 13, 18.

Das Terminal 10 arbeitet als Clientcomputer CLIENT, der durch Kontaktieren des Servers 11, der als ein Hostcomputer SERVER arbeitet, einen E-Mail-Dienst startet. Nach dem Bestätigen der Identität des Benutzers bietet der Server dem Benutzer Zugang zu den Mailboxen, für die ihm Rechte definiert wurden. Im Falle ankommender E-Mail kann der Benutzer abhängig von dem verwendeten E-Mail-Protokoll die Dateien in der Mailbox auf sein eigenes Terminal zur späteren Verarbeitung herunterladen (POP), oder er ist imstande, direkt Befehle zum Verarbeiten der Mailboxen am Server zu geben (IMAP). Im Falle abgehender E-Mail faßt ein Benutzer A, der das Terminal 10 benutzt, eine E-Mail-Nachricht ab, gibt sie an den Server 11 weiter, der die E-Mail-Nachricht über das Netzwerk 13, 18 zur Mailbox eines Benutzers B sendet, welche in einer Datenbank 17 des E-Mail-Servers 16 des Empfängers gespeichert ist, von wo der Benutzer B die E-Mail-Nachricht zu seiner Verwendung z. B. durch ein Terminal 15 abruft.

Im folgenden stellen wir eine Lösung gemäß der Erfindung unter Verwendung des Verarbeitens von Dateiformaten, die in einer E-Mail-Nachricht enthalten sind, als Beispiel dar. 2 zeigt ein Ablaufdiagramm, das Phasen zum Ausgeben einer E-Mail-Nachricht, die am E-Mail-Server (SERVER) angekommen ist, an das Benutzerterminal 10 (CLIENT) dar, welches gemäß dem Stand der Technik implementiert ist. Wenn der Benutzer den E-Mail-Server mit seinem Terminal kontaktiert, empfängt er eine Nachricht von dem Server 11 der E-Mail-Nachrichten, die in der Mailbox gespeichert sind. Im folgenden wird der Begriff Client verwendet, wenn Tätigkeiten beschrieben werden, die durch das Terminal entweder unabhängig oder durch einen Teilnehmer gesteuert ausgeführt werden. Bei Schritt 20 leitet der Client eine Anforderung zum Herunterladen an den Server, welche sich an eine spezifische E-Mail-Nachricht richtet. Bei Schritt 21 sendet der Server die E-Mail-Nachricht an den Client. Bei Schritt 22 prüft der Client die Dateiformate, die in der E-Mail-Nachricht enthalten sind, und folgert, ob er die E-Mail-Nachricht in diesem Format ausgeben kann oder ob die E-Mail-Nachricht vor der Ausgabe konvertiert werden sollte. Abhängig von der Anwendung kann die E-Mail-Nachricht zum Beispiel als Text, Graphik, Sprache oder einer Kombination daraus ausgegeben werden. Wenn keine Konvertierung erforderlich ist, wird die E-Mail-Nachricht zum Client übertragen und ausgegeben (Schritt 25). Wenn eine Konvertierung erforderlich ist, prüft der Client, ob er über die Verwendung der notwendigen Mittel zum Ausführen der Konvertierung verfügt (24) und gibt die E-Mail-Nachricht aus (Schritt 25). Wenn keine Mittel zum Ausführen der Konvertierung vorhanden sind, kann der Client wählen (Schritt 26), ob die E-Mail-Nachricht nicht ausgegeben wird, welchenfalls das Verarbeiten der E-Mail-Nachricht hier endet (geht zu ENDE), oder ob die E-Mail-Nachricht ohne Konvertierung ausgegeben wird, welchenfalls ein Teil des Inhalts der E-Mail-Nachricht ungenutzt verbleibt (geht zu Schritt 25).

Die neuesten MIME-kompatiblen E-Mail-Programme ermöglichen, daß der Client den Server über den Bau der angekommenen E-Mail-Nachricht abfragen und den Konvertierungsbedarf und die Konvertierungsmöglichkeiten prüfen kann, bevor die E-Mail-Nachricht zum Client übertragen wird. Wenn der Client keinen Bedarf oder keine Möglichkeit zur Ausführung der Konvertierung aufweist, kann eine unnötige Übertragung von Daten durch Feststellen des Konvertierungsbedarfs vor der Übertragung vermieden werden. Heutzutage tritt ziemlich häufig ein Bedarf auf, aufgrund der zügigen Softwareentwicklung und der ständig ansteigenden Anzahl von gebräuchlichen Dateiformaten eine zunehmend große Konvertierungsressource zu unterhalten. Andererseits sind die Benutzer in höchstem Maße am Zugreifen auf E-Mail-Dienste mittels tragbarer Terminals, wie mobiler Stationen oder Computer, interessiert. Die Mobilität der Terminalsets begrenzt jedoch die verfügbare Kapazität und Prozessorausgabe, und daher kann das Management und Verarbeiten vieler unterschiedlicher Dateiformate in Verbindung mit einem mobilen Terminal äußerst schwierig werden.

3 stellt die charakteristischen Merkmale einer Lösung gemäß der vorliegenden Erfindung in Verbindung mit dem Verarbeiten eines Dateiformats, das in einer E-Mail-Nachricht enthalten ist, dar. Die Erfindung nutzt die Gelegenheit, die durch die neuesten E-Mail-Protokolle geboten ist, den Bau von E-Mail-Nachrichten zu parsen und ihn dem Client wie benötigt anzuzeigen. Bei Schritt 310 sendet ein Terminal einem Server eine Anfrage über den Bau einer ausgewählten E-Mail-Nachricht. Die E-Mail-Nachricht ist mithilfe eines Tags identifiziert, der die Nachricht in der Mailbox unzweideutig identifiziert. Der Server hat den Bau der E-Mail-Nachricht in Verbindung mit der Ankunft des E-Mail-Nachricht geparst oder parst sie nun, gemäß dem Stand der Technik, und informiert das Terminal über den Bau (Schritt 315). Das Terminal analysiert des Format der Bauteile der E-Mail-Nachricht und prüft den Konvertierungsbedarf (Schritt 320). Wenn keine Konvertierung benötigt ist (Schritt 325), kann die E-Mail-Nachricht vom Server zum Terminal übertragen (Schritt 370) und an den Benutzer ausgegeben werden (Schritt 380). Abhängig von der Anwendung kann die Nachricht z. B. als Text, Graphik, Sprache oder eine Kombination daraus ausgegeben werden. Wenn eine Konvertierung notwendig ist (Schritt 325), wird die erforderliche Konvertierungsart spezifiziert (Schritt 330). Das Terminal kann die Spezifizierung automatisch auf Grundlage seiner eigenen Konvertierungsressourcen ausführen oder über eine Benutzeroberfläche Benutzerbefehle zum Ausführen der Konvertierung erfragen. Nach dem Auswählen der Konvertierungsart informiert das Terminal den Server darüber (Schritt 340, 341, 342). Der Server führt die ausgewählte Konvertierung aus (Schritt 350), versieht die konvertierte E-Mail-Nachricht mit einem neuen Identifizierungstag und speichert die E-Mail-Nachricht in der Mailbox (355). Wenn der Server den Client über die Ausführung der Konvertierung und das neue Tag der konvertierten E-Mail-Nachricht informiert hat (360), kann der Benutzer entscheiden, ob er die ursprüngliche E-Mail-Nachricht oder die konvertierte E-Mail-Nachricht weiter verarbeiten möchte (Schritt 365). Diese Art weiterer Verarbeitung kann z. B. das Übersetzen einer E-Mail-Nachricht, die in ein spezifisches Textformat konvertiert ist, in eine andere Sprache sein. Wenn weiteres Verarbeiten erforderlich ist, kehrt die Verarbeitung zu Schritt 330 zurück, wo die erforderliche Konvertierung spezifiziert wird. Wenn kein weiteres Verarbeiten erforderlich ist, wird die E-Mail-Nachricht im gewünschten Format vom Server zum Terminal übertragen (Schritt 370) und ausgegeben (Schritt 380).

Im folgenden präsentieren wir eine bevorzugte Ausführungsform der vorliegenden Erfindung in Verbindung mit einem MIME-kompatiblen IMAP4 E-Mail-Protokoll. Ursprünglich ist das IMAP ein E-Mail-Protokoll an der Stanford University, das es einem Client ermöglicht, Inhalte von entfernten Mailboxen, die durch Hostcomputer gespeichert werden sollen, in derselben Weise wie lokale Dateien zu behandeln. Für eine detailliertere Beschreibung des IMAP4 Protokolls und seiner Version 1 beziehen wir uns auf die Anwendungsnorm Network Working Group RFC 2045 (Requests for Comments), die in mehreren Internetquellen zu finden ist; zum Zeitpunkt der Ausarbeitung dieser Anmeldung unter der Adresse http://ds.internic.net.

Das Signalgebungsdiagramm in 4 stellt die Übertragung von Daten zwischen dem Clientterminal CLIENT und dem E-Mail-Server SERVER in einer E-Mail-Dienstimplementierung gemäß der Erfindung dar. Eine Nachricht 4.1 enthält einen FETCH Befehl, gemäß dem IMAP4 Protokoll, mithilfe dessen Daten bezüglich der E-Mail-Nachricht von einer Mailbox abgerufen werden. Die Befehlsargumente enthalten ein nicht-flüchtiges Nachrichtentag N, das die E-Mail-Nachricht in der Mailbox unzweideutig identifiziert, sowie ein Befehlsargument BODY, das bezeichnet, daß die Dateneinheit, die abgerufen werden soll, der Bau der fraglichen E-Mail-Nachricht ist. Im IMAP4 Protokoll kann sich auf zwei Arten auf die Nachricht bezogen werden: unter Verwendung der fortlaufenden Nummer oder des einheitlichen Identifikators (UID) der Nachricht. Hier bedeutet der Bau einer E-Mail-Nachricht eine Aufgliederung unterschiedlicher Arten von Baueinheiten, aus denen die E-Mail-Nachricht gebildet ist, und Attribute, die den Inhalt der Baueinheiten beschreiben. Der Server leitet eine FETCH Antwortnachricht 4.2 zurück, worin eine Parameterkette para1, in Klammern, den Bau einer E-Mail-Nachricht N bezeichnet.

Die Parameterkette gemäß dem IMAP4 Protokoll, die den Bau bezeichnet, ist aus acht Parametern zusammengesetzt, die durch ein Leerzeichen getrennt sind. Die E-Mail-Nachricht kann aus einem Bauteil oder mehreren zusammengesetzt sein, wobei die Ordnung zwischen ihnen und den Attributen bezüglich des Inhalts der Bauteile mittels der MIME-Struktur bezeichnet ist. Zum Beispiel kann die MIME-Struktur einer zweiteiligen E-Mail-Nachricht, die Text und eine BASE64-codierten Textanlage enthält, im IMAP4 Protokoll durch eine Parameterkette ((„TEXT" „PLAIN" („CHARSET" „US-ASCII") NIL NIL „7BIT" 1152 23)(„TEXT" „NAME „PLAIN" („CHARSET" „US-ASCII" „cc.diff")"<960723163407.20117h@cac.washington.edu>" „Compiler diff" „BASE64" 4554 73) „MIXED")) bezeichnet sein. Zur detailliertem Bau und Inhalt der Parameter beziehen wir uns auf die oben angegebene RFC 2045 Anwendungsnorm.

Im IMAP4 Protokoll bezeichnet ein Stern * eine nicht mit Tag versehene Antwort, die keine spezifische E-Mail-Nachricht direkt betrifft. Eine Antwort, die von einem Server auf eine Frage gegeben wird, die von einem Terminal vorgelegt wird, wird ebenfalls mit einem Stern begonnen und mit einer Zeile mit einem Tag beendet. In 4 bezeichnet der Stern * folglich, daß die fragliche Nachricht typischerweise Datenübertragung beschreibt, die eine Befehlszeile länger ist und in einer Befehlszeile endet, die mit einem Tag beginnt.

Nachdem das Terminal über das Format der E-Mail-Nachricht, die durch das Tag N bezeichnet ist, informiert wurde, stellt es den Konvertierungsbedarf bezüglich der E-Mail-Nachricht fest. Wenn die E-Mail-Nachricht Teile enthält, für deren Verarbeitung das Terminal keine Mittel aufweist, identifiziert es den Konvertierungsbedarf. Das Terminal kann die Entscheidung automatisch auf Grundlage der verfügbaren Ressourcen treffen, oder der Benutzer kann am Entscheidungsfällungsprozess über eine Benutzeroberfläche des Terminals teilnehmen. Zum Beispiel kann das Terminal zunächst den möglichen Konvertierungsbedarf identifizieren und dem Benutzer den Bedarf und alternative weitere Maßnahmen zum Ausführen der Konvertierungsentscheidung bezeichnen. Wenn die Konvertierungsentscheidung getroffen ist, sendet das Terminal den Servern eine Nachricht 4.3, die gemäß der Erfindung die Ausführung der Konvertierung an einem Server steuert. Das Argument N eines Konvertierungsbefehls XCONVERT bezeichnet das Tag der ausgewählten E-Mail-Nachricht, und die Parameter des Arguments BODY spezifizieren einen neuen Bau, gemäß dem die ausgewählte E-Mail-Nachricht konvertiert werden soll. In Reaktion auf die Nachricht 4.3 initiiert der Server die Konvertierung, wonach er eine Antwortnachricht 4.4 zurücksendet, die über den Erfolg der Konvertierung informiert. Wenn der Server den Befehl, der in der Nachricht 4.3 enthalten ist, nicht identifiziert hat, enthält die Antwortnachricht 4.4 das Ergebnis BAD. Wenn der Server den Befehl identifiziert hat, die Konvertierung jedoch nicht erfolgt ist, enthält die Antwortnachricht 4.4 das Ergebnis NO. Wenn die Konvertierung erfolgt ist, enthält die Antwortnachricht 4.4 das Ergebnis OK sowie ein neues Tag, das die neue E-Mail-Nachricht, die im konvertierten Format in der Mailbox gespeichert ist, unzweideutig identifiziert.

Nach der Konvertierung kann der Client die E-Mail-Nachricht mittels des FETCH Befehls (Nachricht 4.5) von der Mailbox abrufen. Da es eine Frage eines Diensts ist, der sich an den Inhalt einer E-Mail-Nachricht richtet, hat sich der Name file.text, der in den Nachrichtenkopfdaten der E-Mail-Nachricht beinhaltet ist, bei der Konvertierung nicht geändert. Ein Tag M bezeichnet, ob es eine Frage einer E-Mail-Nachricht ist, die sich in ihrem ursprünglichen Format oder in einem konvertierten Format befindet. Die E-Mail-Nachricht M wird in einer Nachricht 4.6 vom Server zum Terminal zur Ausgabe übertragen.

Wie oben häufig dargestellt, ist der Vorteil, der aus der Erfindung erzielt ist, insbesondere vom Gesichtspunkt eines Benutzers aus erheblich, der mithilfe eines mobilen Terminals auf E-Mail zugreift, dessen Speicher und Leistung aufgrund der Mobilitätsunterstützung begrenzt ist. Im folgenden beschreiben wir die Erfindung, wenn sie an eine mobile Station angepaßt ist, die im GSM-System (Global System for Mobile Telecommunications) betrieben ist, ohne die Erfindung auf die oben dargestellten Elemente oder Begriffe zu beschränken. Das genutzte Netzwerk kann jegliches Zugangsnetzwerk oder jegliche Kombination von Netzwerken sein, die zur Nutzung von E-Mail-Diensten geeignet sind, wie das GSM-System, das den General Packet Radio Service (GPRS) unterstützt, Ethernet, Token Ring usw., und das Terminal kann jeglicher Client des Zugangsnetzwerks mit den notwendigen Mitteln zum Nutzen der E-Mail-Dienste sein.

Das Blockdiagramm in 5 zeigt eine Anordnung zum Nutzen von E-Mail-Diensten über ein digitales GSM-System, wobei ein Teil des Netzwerks gemäß 1 aus dem GSM-Netzwerk zusammengesetzt ist. Mobile Stationen MS stehen mit Basisfunkstationen (BTS) unter Verwendung von Funkkommunikation in Verbindung. Die Basisfunkstationen stehen über eine sogenannte Abis-Schnittstelle ferner mit einer Basisstationssteuerung (BSC) in Verbindung, die mehrere Basisfunkstationen steuert und managt. Die Einheit, die durch mehrere Basisstationen BTS (typischerweise einige Dutzend Basisstationen) und eine einzelne Basisstationsteuerung BSC, die sie steuert, gebildet ist, wird Basis-Stationssystem (BSS) genannt. Die Basisstationsteuerung BSC managt Funkkommunikationskanäle und insbesondere Übergaben. Andererseits steht die Basisstationsteuerung BSC über eine sogenannte A-Schnittstelle mit einer Mobilfunkvermittlungsstelle (MSC) in Verbindung, welche mittels eines Heimatregisters HLR, das permanente Clientdaten enthält, und eines Besucherregisters VLR, das veränderliche Clientdaten enthält, die Herstellung von Verbindungen zu und von mobilen Stationen koordiniert. Über die Mobilfunkvermittlungsstelle MCS wird ferner eine Verbindung nach außerhalb des Mobiltelefonnetzwerks hergestellt, d. h. über das Netzwerk zu einem E-Mail-Server. Das Mobiltelefonnetzwerk kann außerdem eine Gateway-Mobilfunkvermittlungsstelle GMSC umfassen, an das ein Anruf von außerhalb der Mobilfunkvermittlungsstelle gerichtet wird, wenn er nicht direkt an die MSC des Mobiltelefonnetzwerk in dem Bereich, in dem die mobile Station gelegen ist, gerichtet wird.

Die Benutzeroberfläche einer gewöhnlichen mobilen Station ist primär für Anrufe gestaltet, und daher ist ein bevorzugtes mobiles Terminal zum Nutzen von E-Mail-Diensten ein Fernmelder, der zusätzlich zu den gewöhnlichen Mobilstationsfunktionen einen Datenverarbeitungsabschnitt umfaßt, der die Nutzung von E-Mail ermöglicht. Das Blockdiagramm in 6 stellt eine Implementierung eines Terminals gemäß der Erfindung dar. Das fragliche Terminal ist ein Fernmelder, der Schaltungen und eine Benutzeroberfläche umfaßt, die das Verarbeiten von E-Mail ermöglicht.

Ein Terminal 10 enthält eine Funkeinheit 61 zur Kommunikation unter Verwendung von Funkkommunikation, wobei die Funkeinheit einen Senderzweig 610 (der Funktionsblöcke umfaßt, die Kanalcodierung, Verschachtelung, Verschlüsselung, Modulation und Sendung ausführen), der von einer gewöhnlichen mobilen Station bekannt ist, einen Empfängerzweig 612 (der Funktionsblöcke umfaßt, die Empfang, Demodulation, Entschlüsselung, Entschachtelung und Kanaldecodierung ausführen), einen Duplexfilter 614, der den Empfang und die Sendung zur Sendung unter Verwendung von Funkkommunikation trennt, sowie eine Antenne 616 umfaßt.

Der Betrieb des Terminals ist durch eine Hauptsteuerschaltung 62 gesteuert, die ferner eine RU-Steuerung 620 umfaßt, welche Steuerfunktionen einer gewöhnlichen mobilen Station ausführt. Außerdem umfaßt die Hauptsteuerschaltung eine Datenverarbeitungseinheit 622 zum Ausführen und Steuern der Datenverarbeitungsfunktionen des Terminals. Die Steuerungen der Funkeinheit 61 und der Datenverarbeitungseinheit 622 müssen nicht in einer Steuerschaltung integriert sein. Stattdessen können sie auch getrennt voneinander implementiert sein, so daß die RU-Steuerschaltung 620 auf der Funkeinheitsseite ist und auf der Seite der Datenverarbeitungseinheit ein DU-Prozessor 624 ist, der mit der RU-Steuerschaltung 620 zum Managen von Kommunikation zwischen der Funkeinheit und der Datenverarbeitungseinheit in Verbindung steht.

Bei der Implementierung, die in 6 dargestellt ist, ist ein erster Speicher 630, der ein flüchtiger Speicher sein kann, z. B. RAM, worin die CP im Gebrauch befindliche Daten speichert, mit der Hauptsteuerschaltung 62 verbunden. Zudem umfaßt das Terminal einen zweiten Speicher 640, der vorzugsweise ein nichtflüchtiger Speicher ist, worin die Anwendungsprogramme, die die verschiedenen Dienste des Terminals ausführen, andere Daten, die für das Funktionieren des Fernmelders wesentlich sind, und alle anderen Daten, die permanent gespeichert sein sollten, gespeichert sind. Alternativ dazu können die Daten im Speicher einer Smartcard gespeichert sein, die separat an das Terminal anzuschließen ist, von wo eine Verbindung zur Hauptsteuerschaltung 62 besteht. Eine derartige Smartcard ist z. B. aus dem GSM-System als sogenannte SIM-Karte (Subscriber Identity Module) bekannt.

Außer den oben erwähnten Teilen umfaßt das Terminal eine Benutzeroberfläche (UI) 65, die zumindest ein Display 652, einen Lautsprecher 654 und eine Tastatur 650 umfaßt. Der Client gibt die E-Mail-Nachrichten ein und gibt die Befehle über die Tastatur, die als Eingabemittel dient, und die E-Mail-Nachrichten und die E-Mail-Nachrichten werden durch das Display und/oder den Lautsprecher ausgegeben, die als die Ausgabemittel des Terminals dienen.

Wenn die Datenverarbeitungseinheit 622 und die Funkeinheit 62 als funktional unabhängige Einheiten implementiert sind, weisen sie beide doch entweder einen gemeinsamen oder getrennten Speicher 630, 640 sowie eine Benutzeroberfläche UI auf. Kommunikation zwischen den Einheiten wird über eine Verbindung zwischen dem DU-Prozessor 624 und die RU-Steuereinheit 620 gemanagt.

Unter Bezugnahme auf 6 und das Ablaufdiagramm in 7 besprechen wir im folgenden die Implementierung und den Betrieb des oben beschrieben Terminals in Verbindung mit der ersten Ausführungsform der Erfindung. Der Benutzer gibt den Befehl zum Starten des E-Mail-Programms über die Benutzeroberfläche UI, woraufhin die Hauptsteuerschaltung CP die E-Mail-Anmeldung aus dem Speicher 640 abruft. Die E-Mail-Anwendung wird durch den DU-Prozessor 624 verarbeitet. Der DU-Prozessor 624 steuert den Empfang der Befehle, die durch den Benutzer mit dem Eingabemittel 650 gegeben wurden, und die Ausgabe der Nachrichten, die durch die Ausgabemittel 652, 654 an den Benutzer gesendet werden, gemäß dem E-Mail-Programm. Der DU-Prozessor steuert außerdem die Sendung und den Empfang der Nachrichten bezüglich der E-Mail-Funktionen über die RU-Steuerschaltung 620, die die Funktion der Funkeinheit 61 steuert.

Wenn der Benutzer den Befehl mithilfe des Eingabemittels 650 gibt, verarbeitet der DU-Prozessor 624 den Befehl und erstellt eine mögliche Nachricht, die dem Vorgang entspricht, zur Sendung über die Benutzeroberfläche an den Benutzer oder zur Sendung über das Netzwerk an den E-Mail-Server. Wenn es eine Frage einer Nachricht ist, die an den E-Mail-Server gesendet werden soll, bildet der DU-Prozessor 624 ein digitales Signal der Nachricht für einen Sender 610. In einem Senderzweig 610 wird die Nachricht gemäß dem mobilen Kommunikationssystem verarbeitet, einschließlich Codierung, Verschachtelung, Verschlüsselung, Burst-Bildung, Modulation und Sendung 616.

Die Nachricht, die vom E-Mail-Server angekommen ist, kommt zunächst am Empfängerzweig 612 der Funkeinheit RU an, wo die Nachricht gemäß dem mobilen Kommunikationssystem verarbeitet wird, einschließlich Empfang, Demodulation, Entschlüsselung, Entschachtelung und Decodierung. Vom Empfängerzweig wird die verarbeitete Nachricht an den DU-Prozessor gesendet, der die Nachricht verarbeitet und eine mögliche Nachricht, die dem Vorgang entspricht, zur Sendung an den Client über die Benutzeroberfläche oder zur Sendung an den E-Mail-Server über das Netzwerk erstellt.

Nachdem der Benutzer über die Benutzeroberfläche UI 65 den Befehl zum Starten des E-Mail-Programms gegeben hat, ruft der DU-Prozessor 624 die E-Mail-Anwendung aus dem Speicher 640 ab und beginnt das Programm auszuführen, indem er eine Verbindung zum E-Mail-Server herstellt. Nach der Herstellung der Verbindung sendet der E-Mail-Server dem Terminal die Information über den Inhalt der Benutzer-Mailboxen. Wie oben beschrieben, sendet das Terminal bei Schritt 71 eine Anfrage, die sich an den Bau der Nachricht, die am E-Mail-Server angekommen ist, richtet, und empfängt vom E-Mail-Server bei Schritt 72 den Bau der E-Mail-Nachricht. Die Anfrage kann so angepaßt sein, daß sie automatisch durch das Terminal erfolgt, oder der Anfragebefehl kann vom Benutzer über die Benutzeroberfläche empfangen werden. Ein Terminal stellt gemäß der Erfindung den erforderlichen Bau (Schritt 73) entweder durch Prüfen seiner eigenen Anwendungsressourcen, die im Speicher 640 gespeichert sind, oder durch Empfang eines entsprechenden Befehls vom Benutzer über die Benutzeroberfläche fest. Danach stellt das Terminal den Konvertierungsbedarf fest (Schritt 74) und bildet dann den XCONVERT Befehl (Schritt 75). Der Befehl wird über einen Senderzweig TX an den E-Mail-Server gesendet (Schritt 76).

Wenn der Server die ausgewählte Konvertierung ausgeführt hat, informiert er das Terminal über den Erfolg der Konvertierung. Eine Empfängerschaltung RX sendet die Rückmeldung an den DU-Prozessor, der die Information zu ihrer Ausgabe an den Client über das Displaymittel 652 leitet.

Das Blockdiagramm in 8 stellt die Implementierung eines E-Mail-Servers gemäß der Erfindung im Prinzip dar. Der E-Mail-Server umfaßt einen Empfänger/Sender-Block 81 zum Senden von Daten gemäß dem ausgewählten Übertragungsprotokoll (z. B. TCP/IP), einen Datenverbindungsinterpreter 82 (z. B. Winsocket) und einen Host-Block 83. Der Host-Block 83 umfaßt Datenbanken DB1 bis DB3, die zumindest die Client-Daten enthalten, sowie die Anhäufungsdatenbanken zum Speichern der ankommenden und abgehenden E-Mail-Nachrichten (Mailboxen). Außerdem umfaßt der Host-Block 83 eine Zentraleinheit 85 zum Unterhalten der E-Mail-Funktionen, z. B. zum Bilden von Nachrichten gemäß dem ausgewählten Leseprotokoll und zum Implementieren von Funktionen gemäß den empfangenen Nachrichten. Ein Anwendungsblock 84, der eine Anzahl von Anwendungen zum Implementieren der Verarbeitungstätigkeiten, die sich an den Inhalt der E-Mail-Nachrichten richten, umfaßt, wurde außerdem gemäß der Erfindung mit dem Host-Block 83 des E-Mail-Servers verbunden. Solche Anwendungen können z. B. Änderungen im Dateiformat, Übersetzungen von einer Sprache in eine andere usw. sein.

Wie oben dargestellt, kann ein Client mehrere E-Mail-Server über Netzwerke kontaktieren. Da es für die Clients nicht notwendig ist, Information über die Konvertierungskapazität der verschiedenen Server zu speichern, können die Server geeignet sein, die Information über mögliche Konvertierungen in Reaktion auf einen konvertierten CAPABILITY Befehl vorzusehen. Eine derartige zweite bevorzugte Ausführungsform der vorliegenden Erfindung ist in 9 gezeigt. Das IMAP Protokoll umfaßt den Befehl CAPABILITY, mit dessen Hilfe der Client den Server fragen kann, welche Dateierweiterungen der Server unterstützt. Der CAPABILITY Befehl ist unabhängig vom Status des Servers und des Terminals und kann daher nur einmal während einer Verbindung gegeben werden. Wenn der Server zum Unterstützen des XCONVERT Befehls angeordnet wurde, geht dies aus der Antwort des Servers an den Client hervor. Vor der Übertragung der E-Mail-Nachrichten kann der Client dem Server eine Nachricht 9.1 senden, die einen Befehl XCONVERT CAPABILITY umfaßt, der dem IMAP Protokoll hinzugefügt wird, und der die CAPABILITY Anfrage an die Konvertierungsressourcen des Servers richtet. Der Server sendet dem Client eine Antwortnachricht 9.2 zurück, die eine Liste der Konvertierungen enthält, zu deren Ausführung der Server imstande ist. Die Liste kann bei der Fällung der Konvertierungsentscheidung durch das Terminal genutzt werden, dessen eigene Softwareauswahl sehr begrenzt ist. Zum Beispiel kann das Terminal geeignet sein, automatisch die Konvertierungen, die am Server verfügbar sind, zu prüfen und die E-Mail-Nachricht in dem erforderlichen konvertierten Format, das zu seiner eigenen Softwareauswahl gehört, zu verlangen, wann immer dies möglich ist. Da die Nachrichten 9.3 bis 9.8 den Nachrichten 4.1 bis 4.6 direkt entsprechen, beziehen wir uns auf die entsprechenden Schritte in den Beschreibungen von 4.

In den oben dargestellten Ausführungsformen war die erforderliche Funktion, die sich an den Inhalt der E-Mail-Nachrichten richtet, das Verarbeiten des Dateiformats. Eine Lösung gemäß der Erfindung kann außerdem entsprechend bei der Implementierung anderer Funktionen, die sich an den Inhalt der E-Mail-Nachrichten richten, genutzt werden. Einige Internet-Zugangsdienstanbieter weisen bereits Mittel zum Übersetzen des Inhalts von HTML-Seiten von einer Sprache in eine andere auf. Entsprechende Übersetzungsdienste können auch durch einen E-Mail-Server implementiert sein. 10 stellt das Verarbeiten einer ankommenden E-Mail-Nachricht, wie oben gezeigt, dar, wenn eine E-Mail-Nachricht, die in das korrekte Dateiformat konvertiert wurde, auch mithilfe der Übersetzungswerkzeuge, die am Server verfügbar sind, übersetzt werden soll. Der CONVERT CAPABILITY Befehl, der in einer Nachricht 10.1 gegeben ist (vgl. Kommentare in Verbindung mit den Nachrichten 7.1 und 7.2), enthält eine Anfrage über alle Funktionen, die durch den Server vorgesehen sind und sich an den Inhalt der E-Mail-Nachrichten richten, einschließlich der verfügbaren Sprachen. In einer Nachricht 10.2 antwortet der Server dem Terminal, indem er eine Liste der Funktionen vorsieht. Mithilfe der Nachrichten 10.3 und 10.4 wird der Bau einer E-Mail-Nachricht erläutert, wie oben beschrieben, und mithilfe der Nachrichten 10.5 und 10.6 wird eine E-Mail-Nachricht in einer Mailbox gebildet, deren Dateiformat in ein erforderliches Format param konvertiert wurde, und das Terminal wird über den Tag M der konvertierten E-Mail-Nachricht informiert. Der XCONVERT Befehl, der in einer Nachricht 10.7 beinhaltet ist, läßt den Server eine Übersetzungsfunktion starten, die sich an die E-Mail-Nachricht richtet, welche durch das Tag M identifiziert ist, zum Übersetzen der Sprache der E-Mail-Nachricht in eine Sprache lang. Die Antwortnachricht des Servers enthält ein BAD, NO oder OK Ergebnis, wie oben gezeigt, und ein neues Tag K, das die E-Mail-Nachricht identifiziert, die in der Mailbox im konvertierten und übersetzten Format vorliegt. Nach den oben dargestellten Vorgängen hat der Client am Server die Versionen N, M und K der E-Mail-Nachricht, von denen N die E-Mail-Nachricht in ihrem ursprünglichen Format ist, M die E-Mail-Nachricht mit einem konvertierten Dateiformat ist und K die E-Mail-Nachricht mit einem konvertierten und übersetzten Format ist. Mithilfe der Nachrichten 10.9 und 10.10 ruft das Terminal die Version einer Nachricht file.ext ab, die im param Format und in der lang Sprache ist.

Oben haben wir nur wenige Funktionen, die sich an den Inhalt einer E-Mail-Nachricht richten, als bevorzugte Ausführungsformen der vorliegenden Erfindung beschrieben, es gibt jedoch zahlreiche Möglichkeiten für die fraglichen Funktionalitäten. Auf eine der Erfindung entsprechende Weise kann ein E-Mail-Server z. B. zum Managen von Entschlüsselung oder der Verifizierung von Authentifikation gesteuert sein.

In den beschriebenen Ausführungsformen wurde das Verarbeiten des Inhalts einer E-Mail-Nachricht am Server mithilfe des XCONVERT Befehls gesteuert, der dem IMAP4 Protokoll als Erweiterung hinzuzufügen war. Dies ist nur eine Alternative zum Implementieren einer Lösung gemäß der Erfindung. Zum Beispiel in Verbindung mit Konvertierungen einer Dateiart kann, statt den XCONVERT Befehl zu verwenden, die Konvertierungsfunktion gemäß der Erfindung mithilfe eines neuen Arguments, das für den FETCH Befehl zu definieren ist, implementiert werden. Wie oben in Verbindung mit der Nachricht 4.1 zum FETCH N BODY Befehl erklärt, sendet das Terminal eine Anfrage zum Format der E-Mail-Nachricht, die durch das Tag N bezeichnet ist, an den Server. Das ALTERNATIVE BODY Argument in Verbindung mit dem FETCH Befehl kann zum Steuern des Servers zum Rücksenden des E-Mail-Nachrichtenformats an das Terminal definiert sein, das der Server nach dem Analysieren des ursprünglichen Formats der E-Mail-Nachricht erstellt hat. Das neue Format dient als primäres Angebot des Servers zu dem der Server den Rest der verfügbaren Konvertierungen als MULTIPART/ALTERNATIVE Teile gemäß der MIME-Struktur der Antwortnachricht vorlegen kann. Beim Abrufen der E-Mail-Nachricht vom Server wird dem FETCH Befehl ein Indikator gemäß dem IMAP Protokoll, der den Abruf zur ausgewählten Antwortnachrichtenalternative leitet, hinzugefügt.

11 stellt die Implementierung der oben beschriebenen Ausführungsform in Verbindung mit der Konvertierung eines Dateiformats dar. Eine Nachricht 11.1 enthält einen normalen FETXH Befehl, mit dem das Terminal über das Format der E-Mail-Nachricht, die durch das Tag N identifiziert ist, beim Server anfragt. Eine Nachricht 11.2 enthält die Antwort des Servers, die das Format der ursprünglichen E-Mail-Nachricht auf eine oben beschriebene Weise bezeichnet. Eine Nachricht 11.3 enthält den FETCH Befehl, dessen ALTERNATIVEBODY Argument den Server zum Rücksenden der alternativen Formate steuert, in die, wie der Server nach dem Analysieren des Baus der E-Mail-Nachricht herausgefunden hat, die E-Mail-Nachricht konvertiert werden kann. Eine Nachricht 11.4 enthält die Antwortnachricht des Servers, die das Format und andere mögliche alternative Konvertierungen als MULTIPART/ALTERNATIVE Teile bezeichnet. Eine Nachricht 11.5 enthält den FETCH Befehl, mit dem das Terminal den Server informiert, daß es die E-Mail-Nachricht, die durch das Tag N zu identifizieren ist, in dem Format empfangen will, das durch eine Alternative [p, r] bezeichnet ist, die in der Antwort 11.4 bezeichnet ist. Die ausgewählte Version der E-Mail-Nachricht wird in einer Nachricht 11.6 zum Terminal übertragen.

Dieses Schriftstück präsentiert die Implementierung und Ausführungsformen der vorliegenden Erfindung mithilfe von Beispielen. Es ist für den Fachmann offensichtlich, daß die vorliegende Erfindung nicht auf Details der oben dargestellten Ausführungsformen beschränkt ist, und daß die Erfindung auch in einer anderen Ausbildung implementiert sein kann, ohne von den charakteristischen Merkmalen der Erfindung abzuweichen. Die dargestellten Ausführungsformen sollten als veranschaulichend, jedoch nicht als einschränkend betrachtet werden. Die Möglichkeiten der Implementierung und Verwendung der Erfindung sind daher nur durch die beigefügten Patentansprüche begrenzt. Folglich gehören die verschiedenen Implementierungsoptionen der Erfindung wie durch die Ansprüche festgelegt, einschließlich der äquivalenten Implementierungen, ebenfalls zum Anwendungsgebiet der Erfindung.


Anspruch[de]
  1. Verfahren zum Verarbeiten einer E-Mail-Nachricht, umfassend:

    Bilden einer ersten Nachricht (4.2; 9.4; 10.4; 11.4) in einem E-Mail-Server (11), die Information über die Bauteile der E-Mail-Nachricht und Attribute bezüglich des Inhalts der Bauteile umfaßt;

    Übertragen der ersten Nachricht vom E-Mail-Server (11) zu einem Terminal (10);

    gekennzeichnet durch

    Erstellen einer zweiten Nachricht (4.3; 9.5; 19.5; 11.5) in dem Terminal (10), die Information über zumindest ein Verarbeiten in dem Server umfaßt, das sich an den Inhalt der E-Mail-Nachricht richtet;

    Übertragen der zweiten Nachricht zum Server (11);

    Implementieren des Verarbeitens im Server (11) in Reaktion auf die zweite Nachricht; und

    Übertragen der verarbeiteten Nachricht oder ihrer Teile vom E-Mail-Server (11) zum Terminal (10).
  2. Verfahren nach Anspruch 1, gekennzeichnet durch Versehen der E-Mail-Nachricht, die in dem Server (11) verarbeitet wird, mit einem Tag, das die Nachricht im Server identifiziert, wobei sich das Tag von dem Tag einer unverarbeiteten E-Mail-Nachricht unterscheidet, und Speichern der E-Mail-Nachricht in einer Datenbank (12) des Servers (11).
  3. Verfahren nach Anspruch 1, dadurch gekennzeichnet, daß die Nachricht einen Befehl enthält, der das Verarbeiten im Server startet.
  4. Verfahren nach Anspruch 1, dadurch gekennzeichnet, daß die erste Nachricht Information über eine oder mehrere alternative Aktivitäten umfaßt, die durch den Server an den Inhalt der E-Mail-Nachricht gerichtet werden sollen, und die zweite Nachricht Information über die ausgewählte Aktivität umfaßt.
  5. Verfahren nach einem der Ansprüche 1 bis 4, dadurch gekennzeichnet, daß das Verarbeiten eine Dateikonvertierung ist.
  6. Verfahren nach einem der Ansprüche 1 bis 4, dadurch gekennzeichnet, daß das Verarbeiten das Übersetzen eines Texts von einer Sprache in eine andere ist.
  7. Verfahren nach Anspruch 1, dadurch gekennzeichnet, daß die erste Nachricht Information über die MIME-Struktur der E-Mail-Nachricht umfaßt.
  8. Terminal (10) zum Nutzen von E-Mail-Diensten, die über ein Telekommunikationsnetzwerk implementiert sind, wobei das Terminal (10) Mittel (61, 62) zum Empfangen einer ersten Nachricht (4.2; 9.4; 19.4; 11.4) von einem Server umfaßt, wobei die erste Nachricht Information über die Bauteile der E-Mail-Nachricht und die Attribute bezüglich des Inhalts der Bauteile umfaßt,

    dadurch gekennzeichnet, daß das Terminal

    Mittel (622, 62) zum Bilden einer zweiten Nachricht (4.3; 9.5; 10.5; 11.5), wobei die zweite Nachricht Information über zumindest ein Verarbeiten in dem Server umfaßt, das sich an den Inhalt der E-Mail-Nachricht richtet, und

    Mittel (61, 62) zum Übertragen der zweiten Nachricht oder ihrer Teile zum Server umfaßt.
  9. E-Mail-Server, umfassend:

    eine Datenbank (DB1 – DB3) zum Speichern von E-Mail-Nachrichten,

    Mittel (83) zum Bilden einer ersten Nachricht (4.2; 9.4; 10.4; 11.4), wobei die erste Nachricht Information über die Bauteile einer E-Mail-Nachricht, die sich in der Datenbank des E-Mail-Servers befindet, und die Attribute bezüglich des Inhalts der Bauteile umfaßt, und

    Mittel (81, 82) zum Übertragen der ersten Nachricht von dem E-Mail-Server zu einem Terminal,

    dadurch gekennzeichnet, daß

    der E-Mail-Server Mittel (81, 82) zum Empfangen einer zweiten Nachricht (4.3; 9.5; 10.5; 11.5), die vom Terminal übertragen wird, wobei die zweite Nachricht Information über zumindest ein Verarbeiten im Server umfaßt, das sich an den Inhalt der E-Mail-Nachricht richtet;

    Mittel (83, 84) zum Ausführen des Verarbeitens in Reaktion auf den Empfang der zweiten Nachricht und

    Mittel (81, 82) zum Übertragen der verarbeiteten Nachricht oder ihrer Teile vom E-Mail-Server zu einem Terminal umfaßt.
  10. E-Mail-Server nach Anspruch 9, dadurch gekennzeichnet, daß der E-Mail-Server Mittel (83, 84) zum Versehen der verarbeiteten E-Mail-Nachricht mit einem Tag, der eine E-Mail-Nachricht identifiziert, die sich von der unverarbeiteten E-Mail-Nachricht auf dem Server unterscheidet, und Mittel zum Speichern der E-Mail-Nachricht in der Datenbank (DB1–DB3) des Servers umfaßt.
  11. Datenübertragungssystem, das digitale E-Mail-Dienste implementiert, umfassend:

    ein oder mehrere Terminals (10), E-Mail-Server (11, 16), Datenbanken (12, 17) in Verbindung mit den E-Mail-Servern und Datenübertragungsnetzwerke (13, 18), wobei die E-Mail-Server Mittel (83) zum Bilden einer ersten Nachricht (4.2; 9.4; 19.4; 11.4), wobei die Nachricht Information über die Bauteile der E-Mail-Nachricht, die sich in der Datenbank (12, 17) des E-Mail-Servers (11, 16) befindet, und die Attribute bezüglich des Inhalts der Bauteile umfaßt, und Mittel (81, 82) zum Übertragen der ersten Nachricht zu einem Terminal umfaßt;

    dadurch gekennzeichnet, daß

    das Terminal (10) Mittel (622, 62) zum Bilden einer zweiten Nachricht (4.3; 9.5; 10.5; 11.5), wobei die zweite Nachricht Information über zumindest ein Verarbeiten umfaßt, das sich an den Inhalt der E-Mail-Nachricht richtet und im Server ausgeführt wird, und Mittel (61, 62) zum Übertragen der zweiten Nachricht zum Server umfaßt; und

    der E-Mail-Server Mittel (81, 82) zum Empfangen der zweiten Nachricht, Mittel (83, 84) zum Ausführen des Verarbeitens in Reaktion auf die zweite Nachricht und Mittel (81, 82) zum Übertragen der verarbeiteten Nachricht oder ihrer Teile vom E-Mail-Server (11) zum Terminal (10) umfaßt.
Es folgen 11 Blatt Zeichnungen






IPC
A Täglicher Lebensbedarf
B Arbeitsverfahren; Transportieren
C Chemie; Hüttenwesen
D Textilien; Papier
E Bauwesen; Erdbohren; Bergbau
F Maschinenbau; Beleuchtung; Heizung; Waffen; Sprengen
G Physik
H Elektrotechnik

Anmelder
Datum

Patentrecherche

Patent Zeichnungen (PDF)

Copyright © 2008 Patent-De Alle Rechte vorbehalten. eMail: info@patent-de.com