DE602006000660T2

DE602006000660T2 - Platzsparende Speicherung und Archivierung von elektronischer Post auf Basis einer Kommunikationsstruktur

Info

Publication number: DE602006000660T2
Application number: DE602006000660T
Authority: DE
Inventors: Peter Gerstl; Magnus Karlsson; Dirk Seider; Oliver Suhre
Original assignee: International Business Machines Corp
Current assignee: International Business Machines Corp
Priority date: 2005-02-04
Filing date: 2006-01-27
Publication date: 2009-04-02
Anticipated expiration: 2026-01-28
Also published as: EP1689137A1; EP1689137B1; US8849919B2; US9602452B2; US20060190830A1; US20140379831A1; ATE389284T1; DE602006000660D1

Description

1. HINTERGRUND DER ERFINDUNG
1.1 GEBIET DER ERFINDUNG
Die vorliegende Erfindung betrifft elektronische Post. Sie betrifft insbesondere ein Verfahren und System zur Verarbeitung elektronischer Post, wobei E-Mails durch das Entfernen von Redundanz aus dem Inhalt auf platzsparende Weise gespeichert werden.
1.2 BESCHREIBUNG UND NACHTEILE DES STANDS DER TECHNIK
Eine dem Stand der Technik entsprechende Struktur eines E-Mail-Systems ist in 1 in einer groben Übersicht dargestellt. Ein mit einem Mail-Server A 12 verbundener Client 10 sendet E-Mails an einen Mail-Server B 14 und an einen mit dem Server B verbundenen Client 16 bzw. empfängt E-Mails von diesen.
Die US-Patentschrift US 2004/0044735 beschreibt ein Verfahren und System zur E-Mail-Verarbeitung nach dem Stand Technik, das Redundanz in einem E-Mail-Thread entfernen soll. Es ist ausschließlich auf der Clientseite tätig. Auf der Clientseite wird eine neue E-Mail erstellt, wobei redundante Teile durch einen Vergleichsprozess beseitigt werden, der auf einem Textvergleich und auf einer Prozedur für den Headervergleich basiert. Aus ihr wird an dieser Stelle zitiert:
„...First, the plurality of e-mail messages are compared with each other, via step 410. Preferably, a comparison program is utilized to compare the plurality of email messages with each other. Next, a portion of at least one of the plurality of email messages is removed that is duplicative of a portion of another of the plurality of email messages via step 420.
The comparison program implemented by the method in accordance with the present invention can compare the text of the email message, the headers of the email messages or any of a variety of parameters present within the email message in order to minimize the redundancy between email messages. Accordingly, one of ordinary skill in the art will readily recognize that a variety of implementations could be employed to compare the email messages while remaining within the spirit and scope of the present invention.” (Ende des Zitats aus der Beschreibung des Stands der Technik).
Dieses Verfahren nach dem Stand der Technik wird auf der Clientseite ausgeführt, wie durch die Kreise 18 angezeigt wird. Im Allgemeinen ist eine große Menge (N) unterschiedlicher Clients mit einem einzigen Mail-Server verbunden. Im Vergleich zu einer serverseitigen Ausführung kann dies jedoch in vielen Fällen als nachteilig angesehen werden, da die Mail-Server für gewöhnlich die zusätzliche Aufgabe haben, auf einem entsprechenden Sicherungs-/Archivierungsserver 19A, 19B die zu speichernden Daten bereitzustellen. Es wäre folglich vorteilhafter, die Redundanz bereits beim Server zu entfernen, da dies zu einer enormen Einsparung an Speicherplatz während des Normal- und Backupbetriebs führen und den Datenverkehr zwischen jedem Client (N häufig größer als 100.000) und seinem Mail-Server reduzieren würde. Wegen der wachsenden gesetzlichen Auflagen, denen die Behandlung von E-Mails in Bezug auf Dokumentations- und Haftungszwecke in der Geschäftswelt unterworfen ist, und aufgrund des allgemeinen Trends, immer mehr Kommunikation auf elektronischem Weg abzuwickeln, gewinnt dieser Aspekt immer größere Bedeutung.
Von Nachteil ist, dass das dem Stand der Technik entsprechende Verfahren keine ausführlichen Informationen darüber darlegt, wie ein Vergleichsprozess im Einzelnen ausgeführt wird und welche E-Mails miteinander zu vergleichen sind. Es wird ferner nicht präzise dargelegt, was zu tun ist, wenn sich aus dem Vergleichsschritt keine unzweifelhafte Entscheidung ableiten lässt.
Darüber hinaus kann es nicht wirkungsvoll auf einem Mail-Server 12 oder 14 implementiert werden, auf dem E-Mails tausender verschiedener E-Mail-Sender mit tausenden verschiedenen E-Mail-Empfängern verglichen werden müssen, da ein mit einer vorausgehenden Headerfeldanalyse kombinierter Vergleich von einfachem Text keine effektive Entscheidungsgrundlage dafür ist, welche E-Mails zu demselben E-Mail-Thread gehören.
1.3 AUFGABEN DER ERFINDUNG
Eine Aufgabe der vorliegenden Erfindung ist folglich die Bereitstellung eines Verfahrens und Systems, das für den Serverbetrieb geeignet ist.
2. ÜBERBLICK ÜBER DIE ERFINDUNG UND IHRE VORTEILE
Diese Aufgabe der Erfindung wird durch die Merkmale der beigefügten unabhängigen Ansprüche erfüllt. Weitere vorteilhafte Anordnungen und Ausführungsarten der Erfindung sind in den entsprechenden Unteransprüchen dargestellt. Im Folgenden wird auf die beigefügten Ansprüche Bezug genommen.
Zur Bereitstellung eines für den Serverbetrieb geeigneten Verfahrens und Systems wird vorgeschlagen, eine besondere Speicherprozedur mit den folgenden Schritten a) bis d) und eine besondere, entsprechende Wiederherstellungsprozedur mit dem Schritt e), d. h. die Schritte in der folgenden Abfolge auszuführen:

a) In einem ersten Schritt wird der Inhalt einer ankommenden E-Mail, die hier auch als „ursprüngliche" E-Mail bezeichnet wird, in elementare E-Mail-Segmente aufgegliedert, indem der E-Mail-Body auf der Grundlage einer regulären Grammatik mit Umwandlungsregeln einer Syntaxanalyse unterzogen und optional normalisiert wird. Ein diese Grammatik implementierender Transduktor erkennt Aufgliederungspunkte, die anzeigen, dass der Body der E-Mail Darstellungen anderer E-Mails enthält. Er verwendet eine Kombination aus Basisregeln, E-Mail-System-spezifischen Erweiterungen und heuristischen Verfahren, um die Abschnitte innerhalb des E-Mail-Bodys zu identifizieren, die Elemente eines E-Mail-Threads darstellen. Zwei aufeinander folgende Elemente eines E-Mail-Threads gelten vorzugsweise dann als Instanzen einer über- bzw. untergeordneten Beziehung, wenn ihnen eine Antwort-an- oder eine Weiterleitungsbeziehung zugrunde liegt. Im Folgenden wird der Begriff Antwort-an-Beziehung für beide dieser Beziehungen verwendet.
b) In einem zweiten Schritt wird eine eindeutige ID für jedes elementare E-Mail-Segment berechnet, wobei die ID als Index für den Zugriff auf eine E-Mail-Speichertabelle verwendet wird.
c) Anschließend wird die berechnete ID jedes elementaren E-Mail-Segments in der Tabelle gesucht.
d) Falls die berechnete ID eines elementaren E-Mail-Segments nicht in der Tabelle (30) enthalten ist, wird schließlich das entsprechende elementare E-Mail-Segment als neuer Eintrag zusammen mit einem Link zu dem besonderen, ihm übergeordneten elementaren E-Mail-Segment in der Tabelle gespeichert, wodurch eine oder mehr sortierte Abfolgen von in Wechselbeziehung zueinander stehenden elementaren E-Mail-Segmenten definiert werden.
e) Die ursprüngliche E-Mail wird wiederhergestellt aus einer Verkettung einer entsprechenden Abfolge in Wechselbeziehung zueinander stehender elementarer E-Mail-Segmente (41, 45, 46) zum Zwecke der Anzeige auf einem E-Mails empfangenden Client (10; 16) oder für eine Wiederherstellungsprozedur anhand eines auf der E-Mail-Speichertabelle (30) basierenden E-Mail-Archivs.

Folglich wird, in einfachen, kurzen Worten ausgedrückt, jede ankommende E-Mail analysiert, und bestimmte Abschnitte ihres Nachrichtenbodys, d. h. nur so genannte elementare E-Mail-Segmente, werden in besonderer Weise und mit Hilfe einer besonderen, effektiv zugänglichen Datenstruktur gespeichert. Der Vorteil besteht darin, dass dieser auf einem Mail-Server basierende Speichermechanismus die Redundanz im Vergleich zur serverbasierten Speicherung gemäß dem Stand der Technik erheblich reduziert, da bei einem dem Stand der Technik entsprechenden Mail-Server der Gesamtinhalt der gespeicherten E-Mails voller Redundanzen ist.
Anschließend sendet der Mail-Server auf der Grundlage der gespeicherten Inhalte eine Verkettung dieser elementaren Segmente an den Adressaten. Auf der redundanzreduzierten Speicherung von E-Mails basiert entsprechend ein Langzeitarchiv.
Die Verwendung normalisierter anstelle von ursprünglichen Formen bei der Aufgliederung ist ein Kompromiss zwischen der Komprimierungsrate und der Möglichkeit, zu garantieren, dass wiederhergestellte E-Mails genauso aussehen wie die ursprüngliche E-Mail.
Die Normalisierung kann dazu dienen, Transformationen rückgängig zu machen oder Artefakte zu entfernen, die von dem weiterleitenden E-Mail-System erstellt wurden. In einer heterogenen Umgebung, in der verschiedene E-Mail-Systeme in Umgebungen verwendet werden, die eventuell unterschiedliche Ländereinstellungen aufweisen, kann die Normalisierung helfen, eine große Anzahl elementarer E-Mails als identisch zu identifizieren. Wird keine Normalisierung verwendet, können einige tatsächlich identische elementare E-Mails unterschiedliche eindeutige IDs zur Folge haben, wenn beispielsweise die E-Mail-Systeme, aus denen sie stammen, eine andere Headerdarstellung im Body der weitergeleiteten E-Mail verwenden, sodass sie wie unterschiedliche E-Mails behandelt werden. Im Folgenden wird auf die Normalisierung vor dem Hintergrund Bezug genommen, dass es sich dabei um einen optionalen Schritt handelt.
Aufgliederungspunkte werden anhand einer regulären Grammatik bestimmt. Ein Transduktor, der den Body einer ankommenden E-Mail anhand einer solchen Grammatik verarbeitet, bestimmt Aufgliederungspositionen und normalisiert optional die elementaren E-Mail-Segmente zwischen diesen Aufgliederungspositionen. Der Zweck der Normalisierung besteht im Entfernen von erstellten Artefakten oder von Transformationen, die von dem E-Mail-System vorgenommen wurden, aus dem die vorhergehende E-Mail stammt. Beim Beantworten einer E-Mail A mit einer neuen E-Mail B kann das ursprüngliche E-Mail-System entscheiden, den Header oder den Body von A auf beliebige Weise innerhalb des Bodys von B darzustellen. Es kann beispielsweise einige der Headerfelder entfernen, die spezifische Ländereinstellung der Ursprungsplattform zur Darstellung der Headerfeldernamen verwenden, oder entscheiden, jeder Zeile von A das Präfix ,>' voranzustellen. Der Schlüssel, der ein elementares E-Mail-Segment eindeutig darstellen soll, wird vom System auf der Grundlage dieser normalisierten Darstellung berechnet.
Ein diese Grammatik implementierender Transduktor erkennt Aufgliederungspunkte, die anzeigen, dass der Body dieser E-Mail Darstellungen anderer E-Mails enthält. Er verwendet in vorteilhafter Weise eine Kombination aus Basisregeln, E-Mail-System-spezifischen Erweiterungen und heuristischen Verfahren zur Identifizierung der Abschnitte innerhalb des E-Mail-Bodys, die Elemente einer E-Mail darstellen.
Der Mail-Server kann die ursprüngliche Form einer elementaren E-Mail wiederherstellen, indem er anhand des Schlüssels nach den elementaren E-Mail-Segmenten sucht und den Schlüssel durch den Text des gespeicherten elementaren E-Mail-Segments ersetzt.
Diese Anwendung des Verfahrens durch ein E-Mail-System kann für den Client transparent gemacht werden, wenn ein Server eine E-Mail in ihrer ursprünglichen Form wiederherstellt, bevor er sie an den Client sendet. Als Alternative kann ein Client die „komprimierte Form" einer E-Mail abrufen, die Links enthält, die auf die elementaren E-Mail-Segmente in ihrem Inhalt verweisen.
Durch Anklicken eines Links oder anderer grafischer Navigationsmittel kann der Benutzer den E-Mail-Verlauf nach Bedarf einblenden.
Wenn eine Antwort-an-Beziehung unerkannt bleibt oder Aufgliederungspositionen nicht korrekt lokalisiert werden, wirkt sich dies nicht auf die korrekte Wiederherstellung ursprünglicher E-Mails aus. Die einzige Auswirkung betrifft die Komprimierungsrate, denn wenn es nicht möglich ist, elementare E-Mail-Segmente als identisch zu identifizieren, erhöht sich die Anzahl der zu speichernden E-Mails.
3. KURZBESCHREIBUNG DER ZEICHNUNGEN
Die vorliegende Erfindung wird beispielhaft veranschaulicht und ist nicht durch die Form der Figuren in den folgenden Zeichnungen eingeschränkt:
1 ist eine Übersichtsdarstellung eines E-Mail-Systems nach dem Stand der Technik.
2 ist eine Übersichtsdarstellung eines erfindungsgemäßen E-Mail-Systems.
3 ist ein schematisches Baumdiagramm, das einen von einer einzelnen E-Mail M1 initiierten E-Mail-Thread darstellt.
4 ist ein schematisches Baumdiagramm der grundlegenden Speicherstruktur, die in einer bevorzugten Ausführungsart der vorliegenden Erfindung verwendet wird.
5 ist eine schematische Skizze zur Darstellung einer an einem Mail-Server ankommenden E-Mail und eine Skizze zur Darstellung der entsprechenden Headerfelder und deren Inhalte.
6 ist ein schematisches Kontrollflussdiagramm zu einem Verfahren gemäß einer bevorzugten Ausführungsart der vorliegenden Erfindung.
7 und 8 sind schematische Kontrollflussdiagramme zu einem Verfahren gemäß einer bevorzugten Ausführungsart der vorliegenden Erfindung, die Einzelheiten aus 6 darstellen.
Die 9A bis 9G sind während der Laufzeit entstehende Diagramme zu E-Mail-Speichertabellen.
4. EINFÜHRUNG IN DIE BEVORZUGTE AUSFÜHRUNGSART
Die bevorzugte Ausführungsart der vorliegenden Erfindung erfordert im Wesentlichen die Ausführung der folgenden Schritte:

a) Zerlegen einer E-Mail in ihre elementaren E-Mail-Segmente,
b) Berechnen einer ID für jedes elementare E-Mail-Segment und Verwenden der ID für den Zugriff auf eine E-Mail-Speichertabelle,
c) falls dieselbe ID bereits in der Tabelle enthalten ist, wird der entsprechende Eintrag in der Tabelle nicht überschrieben, ansonsten
d) Speichern der elementaren E-Mail-Segmente durch Verwenden der ID und
e) Wiederherstellen der ursprünglichen E-Mail.

Im Folgenden werden die während dieser Schritte ausgeführten Algorithmen vorgestellt.
a) Bestimmung von Aufgliederungspunkten
Hinsichtlich der internen Struktur einer E-Mail basiert das Format von Internet-Mail auf dem ARPA-Standard RFC822 für Textnachrichten im Internet [Ref.: http://www.w3.org/Protocols/rfc822/]. Gemäß RFC822 ist eine Internetnachricht ein ASCII-Textblock, der aus einem Header besteht, auf den ein Inhalt (der Body) folgt. Der Header ist eine Folge von Feldern und Werten, die durch einen Doppelpunkt getrennt sind:
RFC1521 grenzt die Notation eines Nachrichtenbodys durch die Einführung der Bezeichnung Inhaltstypen ein. Ein wichtiger Inhaltstyp aus dem Blickwinkel dieser Erfindung ist ,multipart' (mehrteilig), bei dem ein Nachrichtenbody aus mehreren Teilen bestehen kann, die durch eine konfigurierbare Kapselungsgrenze voneinander getrennt sind. Ein eigenständiger Teil ist der E-Mail-Body im Sinne einer Textnachricht, während die anderen als Anhänge behandelt werden.
RFC822 und RFC1521 definieren die Basisstruktur von Nachrichten, mit der dem Stand der Technik entsprechende, gängige E-Mail-Systeme wie Microsoft Exchange, Lotus Notes oder Novell Groupwise konform sein müssen, um die Interoperabilität im gesamten Internet sicherzustellen. Diese Standards sind jedoch als Empfehlungen gedacht, sodass tatsachliche Messaging-Systeme einige Aspekte anders handhaben können.
Ein spezifisches Nachrichtensystem verwendet intern in der Regel eine andere Darstellung. Da jedoch einige Informationen des Headers zur Übermittlung der E-Mail benötigt werden, kann jedes Nachrichtensystem auf diese Informationen zugreifen und sie verarbeiten. Hier ist ein Beispiel für einen Header gemäß der RFC822-Spezifikation:
Anders verhält es sich bei der Betrachtung eines Diskussionsverlaufs, da alle Header außer dem „obersten" Teil des Nachrichtenbodys sind, den ein E-Mail-System auf beliebige Weise darstellen kann. Die für den obersten Header verwendete Darstellung wird hier als die ,Standard-Notation' bezeichnet. Gemäß RFC822 ist der Nachrichtenbody ein schwarzes Feld.
Das folgende Beispiel dient der Veranschaulichung, wie ein Nachrichtensystem eine E-Mail „umpacken" kann, wenn sie in eine weitergeleitete oder zurückgesendete Kopie integriert wird:
Es wird angenommen, dass Alice die folgende E-Mail M1 an ihre Freunde Bob, Chris und Deirdre sendet:
Bob antwortet Alice und setzt Chris und Deirdre auf Kopie. Bobs E-Mail-System erstellt eine neue E-Mail M2, die aus zwei elementaren E-Mails besteht: eine E1, die M1 entspricht, und die neue E2, die Bobs Antwort enthält:
Es ist anzumerken, dass eine Darstellung des Headers von M1 ein Element des unstrukturierten Bodys von M2 ist. Das Betreff-Feld im Header von M2 enthält eine geänderte Version des ursprünglichen Betreffs. Die Identifizierung elementarer E-Mail-Segmente, die auf einem Zeichenfolgenvergleich zwischen M1 und dem Body von M2 basiert, ist wegen der folgenden Probleme nicht durchführbar:

• Bei dem Versuch, den Header und den Body von M1 innerhalb des Bodys von M2 zu lokalisieren, würde man keine übereinstimmende Unterzeichenfolge in dem Body von M2 finden, da das Element im Body von M2, das den ursprünglichen Header von M1 darstellt, von dem Messaging-System geändert wurde (das Feld „From:" wurde durch das Feld „Sender" ersetzt).
• Bei dem Versuch, den Body von M1 zu lokalisieren, gibt es kein klares Anzeichen für den Beginn des Elements, das in M2 mit dem Body von M1 übereinstimmt. Die Situation ist noch problematischer beim Betrachten einer Nachricht, die aus drei oder mehr elementaren E-Mails besteht. In diesem Fall gibt es kein klares Anzeichen dafür, wo die Darstellung des Bodys beginnt und endet. Darüber hinaus besteht ein gewisses Risiko, dass zwei elementare E-Mails als identisch angesehen werden, obwohl sie tatsächlich unterschiedlich sind. Ein Beispiel hierfür ist eine E-Mail mit dem Body „Hallo Bob", die von vielen verschiedenen Personen versendet worden sein könnte.

Die vorliegende Erfindung löst diese Probleme wie folgt:

• Sie verwendet vorzugsweise eine Kombination aus drei unten beschriebenen Ansätzen, um a) elementare E-Mails zu identifizieren und b) relevante Informationen aus der Darstellung eines E-Mail-Headers einem kanonischen Format zuzuordnen.
• Sie definiert ein Identitätskriterium, das angibt, unter welchen Bedingungen zwei elementare E-Mail-Segmente auf der Grundlage der kanonischen Darstellung des E-Mail-Headers und des entsprechenden Inhalts für identisch erachtet werden. Dies wird durch das erfindungsgemäße Schlüsselerstellungsverfahren erreicht, das nachfolgend beschrieben ist.

Obwohl ein einzelner der erfindungsgemäßen Ansätze allein zu nützlichen Ergebnissen führen kann, verwendet die vorliegende Erfindung in vorteilhafter Weise eine Kombination der folgenden Ansätze, um elementare E-Mails zu identifizieren und relevante Informationen aus der Darstellung eines E-Mail-Headers einem kanonischen Format zuzuordnen:

1. Unterstützung aus dem Messaging-System
2. Textmuster
3. Heuristische Verfahren

In Kapitel 5 werden diese Ansätze ausführlich beschrieben.
b) Berechnung der eindeutigen ID
Das erfindungsgemäße Verfahren beruht in hohem Maße auf einem Schlüssel, der ein elementares E-Mail-Segment identifiziert. Folglich wird der Schlüssel auf vorteilhafte Weise aus diskreten Komponenten eines elementaren E-Mail-Segments erstellt. Die Wahl dieser Komponenten definiert, wann zwei elementare E-Mail-Segmente als identisch angesehen werden. Ein Komponentensatz, der ein elementares E-Mail-Segment nicht eindeutig darstellt, kann zu einer höheren Trefferquote in Bezug auf die elementaren E-Mail-Segmente führen, aber es kann auch das Risiko eines Datenverlusts bestehen.
Wenn beispielsweise nur die Inhalte der E-Mail, z. B. „Wie geht's?", zur Erstellung des Schlüssels herangezogen werden, kann dieselbe oder eine andere Person denselben E-Mail-Text an eine andere Verteilerliste senden. Der Schlüssel würde jedoch derselbe sein, da er nur aus den Textinhalten der E-Mail erstellt wird.
Die für zukünftige E-Mail-Anwendungsprogramme immer wichtigere Bedingung der Einhaltung gesetzlicher Vorschriften beinhaltet, dass die E-Mail-Daten nicht aufgrund einer Schlüsselkollision verloren gehen dürfen, die darauf zurückzuführen ist, dass zu wenige der oben genannten Komponenten in dem Schlüssel gespeichert sind. Zur Einhaltung gesetzlicher Vorschriften in geschäftlichen Feldern mit strengen Auflagen sollten alle in einer elementaren E-Mail verfügbaren Komponenten zur Generierung des Schlüssels verwendet werden:

• Der gesamte Textinhalt des Headers der elementaren E-Mail. Der Textinhalt umfasst alle Headerinformationen der elementaren E-Mail, z. B. „from", alle Empfängerlisten sowie den Betreff.
• Wenn ein Datum vorhanden ist, trägt dieses zu einer noch eindeutigeren Identifizierung der elementaren E-Mail bei.
• Der E-Mail-Text des Nachrichtenbodys selbst. Bei E-Mails mit aufbereitetem Text (Enriched Text), sollte der Rich Text Teil des Schlüssels sein, damit sichergestellt ist, dass Farbcodierung, Schriftarten, Schriftstile und dergleichen Teil des Schlüssels sind.
• Anhänge werden in vorteilhafter Weise nicht als Teil des Schlüssels angesehen.

Wenn die Einhaltung gesetzlicher Vorschriften nicht erforderlich ist, kann eine Teilmenge der oben erwähnten Informationen herangezogen werden, um den Geltungsbereich der identischen elementaren E-Mails zu vergrößern. Dies kann jedoch zu einem Teilverlust der Informationen bestimmter elementarer E-Mails führen, wenn diese wieder angezeigt/wiederhergestellt werden.
Der Schlüsselwert selbst kann beispielsweise mit Hilfe eines Hashing-Algorithmus wie MD5 [Ref.: RFC 1321], siehe beispielsweise http://www.faqs.org/rfcs/rfc1321.html oder SHA [Ref.: NIST, FIPS PUB 180-1: Secure Hash Standard, April 1995] oder anderen generiert werden. Die Komponentenwerte einer elementaren E-Mail dienen wie oben beschrieben als Eingabe für diese Schlüsselgenerierung. Die Normalisierung kann angewendet werden, damit die Verwendung einer konsistenten Zeichencodierung, wie z. B. UTF-8, sichergestellt ist.
Der geeignete Elementesatz zur Berechnung der ID sollte in Abhängigkeit von den Qualitätsanforderungen ausgewählt werden. Eine kleine Anzahl von Elementen erhöht das Risiko, dass zwei E-Mails als identisch angesehen werden, obwohl sie tatsächlich unterschiedlich sind. Dieses Risiko kann akzeptabel sein, wenn die Einhaltung gesetzlicher Vorschriften keine Rolle spielt. Wenn die Einhaltung gesetzlicher Vorschriften wichtig ist, sollte ein größerer Elementesatz ausgewählt werden.
Gute Kombinationen zur Berechnung einer ID sind: From + To + ein einheitlich definierter Zeitstempel oder eine Vielzahl von Zeitstempeln. Ein Zeitstempel kann nach einem der folgenden Kriterien ausgewählt werden:

– gesendet vom Client des Servers A (erstellt),
– gesendet von Server A (weitergeleitet),
– empfangen von Server B (empfangen),
– empfangen am Client von Server B (zugestellt).

Falls er in einem global einheitlichen Standard (z. B. Greenwich-Zeit) enthalten ist, kann dieser direkt verwendet werden. Falls nicht, können entsprechende Zeitadditionen bzw. -subtraktionen gemäß dem Standort eines entsprechenden Servers in der Welt berechnet werden.
c, d) Elementare E-Mail-Segmente speichern
In den Figuren allgemein und insbesondere in 2 sind die Mail-Server 12 und 14 durch das Bezugszeichen 20 gekennzeichnet, um das Entfernen von Redundanz im Vergleich zum Stand der Technik zentralisiert zu realisieren.
Wenn Redundanz an den Servern 12, 14 entfernt wird, da dort das erfindungsgemäße Verfahren implementiert wird, müssen die Sicherungsserver 19A oder 19 ferner deutlich geringere Datenmengen speichern. Dies ist sehr hilfreich, wenn diese Server 19 oder andere dedizierte Archivierungsserver für die langfristige Archivierung von E-Mail-Korrespondenz verwendet werden.
In 3 ist ein kurzes und einfaches Beispiel für eine E-Mail-Diskussion dargestellt, um zu veranschaulichen, wie elementare E-Mail-Segmente nach dem erfindungsgemäßen Verfahren gespeichert werden:

1. Alice schreibt eine E-Mail an Bob, Chris und Deirdre mit dem Text „Wie geht's?" (diese E-Mail soll als M1 bezeichnet werden).
2. Bob antwortet auf M1 mit „Danke, gut!" (M2).
3. Chris antwortet auf M1 mit „Ganz gut. Und Dir?" und dem Anhang A1 (M3).
4. Deirdre antwortet auf M1 mit „Nicht so gut. Wie geht es Dir und Deinem Mann?" (M4).
5. Alice antwortet auf M3 mit „Mir geht's gut. Danke" und fügt den Anhang A2 bei (M5).
6. Alice antwortet auf M4 mit „Uns geht's gut. Danke" und fügt den Anhang A3 bei (M6).

Die Inhalte von M1 bis M6 erscheinen wie folgt auf den Mail-Clients, wobei eine abstrakte Notation „Attachments:..." dazu dient, optionale mehrteilige Elemente des E-Mail-Bodys darzustellen. Dies ist kein eigentlicher Teil des E-Mail-Bodys.
Ein einteiliger Body entspricht der Notation „Attachments: none":
Gemäß dem allgemeinen Stand der Technik, wie er in vielen E-Mail-Lösungen heute implementiert ist, die keine Antwort/Weiterleitungs-Struktur berücksichtigen, werden alle diese Inhalte so wie sie sind gespeichert, d. h., die Inhalte der E-Mails M1, M3 und M4 werden mehr als einmal gespeichert (M1 würde sogar sechsmal gespeichert). Im Gegensatz dazu speichert die vorliegende Erfindung diesen Dialog in einer viel platzsparenderen Weise ohne Informationsverlust.
Gemäß der vorliegenden Erfindung wird gegenüber dem Stand der Technik ein Speicherkonzept bevorzugt, das als Baumstruktur aus elementaren E-Mail-Segmenten dargestellt werden kann, wobei – wenn ein elementares E-Mail-Segment X das übergeordnete Objekt des elementaren E-Mail-Segments Y ist – dies bedeutet, dass Y eine Antwort auf X ist oder dass X von der E-Mail Y weitergeleitet wurde. Die Baumstruktur, die den exemplarischen E-Mail-Thread bezeichnet, ist für dieses Beispiel in 3 skizziert.
In 4 handelt es sich bei der grundlegenden Datenstruktur, die auf dem E-Mail-Server gemäß einer bevorzugten Ausführungsart der Erfindung benötigt wird, um eine Tabelle 30, die einen Schlüssel 36 einer Gruppe von Knoten zuordnet – beispielsweise handelt es sich um eine klassische Hash-Zuordnung, die später als „E-Mail-Speichertabelle" bezeichnet wird. Ein Knoten besteht wiederum aus folgenden Feldern:

1. dem (Text-)Inhalt E des elementaren E-Mail-Segments, Feld 32;
2. einem Zeiger auf einen anderen Knoten (kann den Wert NULL aufweisen), Feld 34;
3. einer Liste mit Anhang-IDs, Feld 35.

In dieser besonderen Ausführungsart wird davon ausgegangen, dass Anhänge von einer separaten Softwarekomponente verwaltet werden, die bei Vorhandensein eines Anhangs eine eindeutige ID – in 4 symbolisch als A1, A2, A3 usw. bezeichnet – für diesen Anhang berechnet und die den tatsächlichen Inhalt des Anhangs speichert sowie eine Zuordnung von Anhang-IDs zu dem tatsächlichen Inhalt des Anhangs vornimmt. Allgemeinere Aspekte der Behandlung von E-Mail-Anhängen können wie nach dem Stand der Technik bekannt auf das erfindungsgemäße Verfahren angewendet werden.
Die Zeigerkomponente 34 verweist auf das übergeordnete Objekt der elementaren E-Mail in der Baumstruktur des Diskussionsverlaufs. Anhand der E-Mail-Speichertabelle soll für einen bestimmten Schlüssel auf effiziente Weise – selbst wenn vom Mail-Server große E-Mail-Mengen verwaltet werden – festgestellt werden, ob die elementare E-Mail, für die der Schlüssel berechnet wurde, bereits gespeichert ist, und es soll ein schneller Zugriff auf dieses gespeicherte elementare E-Mail-Segment ermöglicht werden.
Hinsichtlich des oben genannten Beispiels sieht die gefüllte E-Mail-Speichertabelle wie die Tabelle in 4 aus, in der die Werte zur Veranschaulichung der baumartigen Struktur symbolisch nach rechts verschoben sind.
Die Anhangliste 35 eines Knotens zeigt alle Anhänge der gesamten E-Mail an, die mit diesem Knoten endet. Sie enthält nicht nur die Anhänge des elementaren E-Mail-Segments, da es sich bei E-Mails gemäß RFC822 nicht feststellen lässt, welcher Anhang zu welchem elementaren E-Mail-Segment gehört. Wenn keine solche Anhangtabelle vorhanden ist, bedeutet dies im Grunde, dass die Anhänge der E-Mail, die mit dem elementaren E-Mail-Segment endet, das von diesem Knoten dargestellt wird, (noch) nicht bekannt sind. Dies kann dann geschehen, wenn die Speicherung einer Antwort auf die E-Mail X angefordert wurde und X später oder sogar nie gespeichert wird (wenn beispielsweise die E-Mail verloren geht). In einem E-Mail-Archivierungsszenario, das unter Einschluss des erfindungsgemäßen Verfahrens implementiert wird, wäre dies kein Nachteil, weil nur diejenigen E-Mails aus dem Archiv abgerufen werden können, deren Speicherung tatsächlich angefordert wurde.
e) Wiederherstellung
Anhand der ID eines elementaren E-Mail-Segments lässt sich dessen entsprechende ursprüngliche E-Mail unter Bezugnahme auf 8 wie folgt wiederherstellen:

1. Suchen des mit der ID verknüpften Eintrags in der E-Mail-Speichertabelle,
2. Suchen und Anhängen des ihm übergeordneten elementaren E-Mail-Segments,
3. Wiederholen von Schritt 2 bis die übergeordnete Verknüpfung gleich Null ist.

Da mehrere Baumstrukturen gespeichert werden, wobei jede Baumstruktur mit einem einzigen E-Mail-Thread verknüpft ist, wird eine „Gesamtstruktur" geschaffen. Die zur Schaffung dieser Gesamtstruktur erforderlichen Schritte und Datenstrukturen sind in Kapitel 5 unten unter Bezugnahme auf die 6, 7 und 8 beschrieben.
5. DETAILLIERTE BESCHREIBUNG DER BEVORZUGTEN AUSFÜHRUNGSART
Dieser Abschnitt enthält eine ausführlichere Beschreibung der grundlegenden Schritte dieser Erfindung. Wie in Kapitel 4 bereits angemerkt wurde, gibt es drei Grundoperationen.
5.1 Aufgliederung des Nachrichtenbodys
Der Nachrichtenbody der ankommenden E-Mail M wird in Schritt 410 in seine elementaren E-Mail-Segmente E1, ..., En aufgegliedert.
Eine ankommende E-Mail wird von der Aufgliederungs-/Normalisierungsfunktion verarbeitet, die den E-Mail-Body einer Syntaxanalyse unterzieht, um Aufgliederungspunkte zwischen elementaren E-Mails zu erkennen und optional den Header und/oder Body dieser elementaren E-Mails zu normalisieren. Die Aufgliederungs-/Normalisierungsfunktion verwendet in der Regel eine Kombination der folgenden drei Ansätze:
Ansatz 1: Unterstützung durch das Messaging-System
Bei diesem ersten Ansatz wird davon ausgegangen, dass das Messaging-System eine interne Darstellung verwendet, die den E-Mail-Body als strukturierte Einheit auffasst. Im Sinne von RFC882 könnte dies extern durch einen bestimmten Markierungstyp (Zeichenfolge oder nicht druckbares Zeichen), dessen Vorkommen im Body eines elementaren E-Mail-Segments unwahrscheinlich ist, widergespiegelt werden. Diese Markierung wird nicht als Teil des E-Mail-Bodys angesehen. Alternativ kann jeder Typ eines anbieterspezifischen Rich Text-Formats zur Darstellung der internen Struktur eines E-Mail-Bodys verwendet werden. Leider kann diese Struktur teilweise oder sogar in ihrer Gesamtheit verloren gehen, wenn eine Nachricht die geschlossene Welt dieses anbieterspezifischen Messaging-Systems verlässt. Ein Beispiel: eine E-Mail, die intern in einem Unternehmen gesendet wird, das Lotus Notes als unternehmensweites Messaging-System verwendet, wird als Rich Text behandelt und behält alle internen Informationen, solange sie über Lotus Notes-Server geleitet wird. Sobald sie das Intranet des Unternehmens in ein Messaging-System verlässt, das nicht auf Lotus Notes basiert, konvertiert der letzte Lotus Notes-Server das Rich Text-Format in ein Format, das andere Messaging-System normalerweise verstehen (Text- oder HTML-Mail). Als Nebeneffekt geht ein Großteil der Struktur des Richt Text-Formats zugunsten der Kompatibilität verloren.
Ansatz 1 ist anwendbar, wenn eine Art interne Struktur (beispielsweise durch ein Rich Text-Format codiert) für alle relevanten E-Mails vorhanden ist, die die Identifizierung elementarer E-Mail-Segmente in einem Nachrichtenbody erleichtert. Obwohl dies eventuell nicht für E-Mails gilt, die willkürliche Routen durch das Internet nehmen, kann es eine wertvolle Option sein, wenn eine bedeutende Teilmenge der betreffenden E-Mails auf der erweiterten Infrastruktur eines einzigen Anbieters basiert (wie es beim Intranet eines Großunternehmens in der Regel der Fall ist).
Die folgende E-Mail ist ein Beispiel für eine XML-codierte Darstellung des Bodys von M2. XML dient dem Zweck der Veranschaulichung. Dieses Beispiel stellt ein willkürliches strukturiertes Format dar, das eine explizite Notation für Aufgliederungspunkte enthält. Ein bestimmtes E-Mail-System kann ein Rich Text-Format zur Codierung von Aufgliederungspunkten verwenden, oder ein zukünftiger Standard kann das Nachrichtenformat durch Mittel bereichern, die das Einbetten von E-Mails in einen Mail-Body ausdrücken. Angesichts einer solchen Situation ließe sich die vorliegende Erfindung sehr gut anwenden und erweitern, um von dieser Standardisierung zu profitieren. In einem solchen Szenario wird davon ausgegangen, dass ein „fiktives" Element „ThreadSeparator" aus dem Namensbereich „Mail" verwendet wird, um eine Grenze zwischen unterschiedlichen elementaren E-Mail-Segmenten anzuzeigen. Diese Grenze wird hier auch als Aufgliederungsposition oder Aufgliederungspunkt bezeichnet.
Aus technischer und leistungsorientierter Sicht ist dies der attraktivste Ansatz, da er Informationen nutzt, die sofort verfügbar sind. Allerdings wird dies heute von Nachrichtensystemen im Allgemeinen nicht unterstützt, und es gibt keinen vereinbarten Standard für die Verwendung dieser Markierungen. Daher wird dieser Ansatz, wie oben erwähnt, in der Regel nur auf eine Teilmenge der zu verarbeitenden E-Mails anwendbar sein. In größeren Unternebinen mit einer homogenen E-Mail-Infrastruktur von einem einzigen Anbieter kann dies jedoch ein beträchtlicher Anteil sein.
Ansatz 2: Textmuster
Dieser zweite Ansatz ist auf den heterogenen Charakter einer realistischen Nachrichtenumgebung abgestimmt. Er basiert auf der Annahme, dass Darstellungen von E-Mail-Headern im Body einer E-Mail von einem Textmuster identifiziert werden können, das durch eine formale Sprache, wie z. B. reguläre Ausdrücke, beschrieben werden kann. Der Regelsatz einer solchen Sprache kann manuell oder durch einen „statistischen Lernprozess" erstellt werden, der auf der Analyse eines vorhandenen Satzes repräsentativer E-Mails basiert. Dieser Ansatz kann zwar auch zur Syntaxanalyse von Rich Text-Darstellungen eines E-Mail-Bodys (Ansatz 1) verwendet werden, aber er ist erheblich leistungsfähiger. Er kann beispielsweise zur Identifizierung von Headern folgenden Typs verwendet werden:
Wobei <messageAddress> in standardmäßiger E-Mail-Syntax oder in einem auf X.500 (oder LDAP) aufbauenden Syntaxtyp dargestellt werden kann, wie er beispielsweise intern von Lotus Notes verwendet wird:
Darüber hinaus löst dieser Ansatz einige der zu Beginn dieses Abschnitts erwähnten Probleme, indem der Name des Absenderfelds wie ein optionales Element des Headers behandelt wird:
Dieser Ansatz kann auch in einer mehrsprachigen Umgebung verwendet werden, um die verschiedenen sprachspezifischen Übersetzungen eines Feldnamens, wie z. B. „De" als französische Übersetzung für „From", mit einem Muster wie z. B. dem folgenden zu identifizieren:
Muster können manuell erstellt werden, indem ein Satz repräsentativer E-Mails analysiert wird und indem die verschiedenen Formen identifiziert werden, in denen Headerinformationen im Body einer E-Mail dargestellt werden. Als Alternative kann ein lernender Algorithmus angewendet werden, der auf der Grundlage eines Einstiegspunkts automatisch Varianten identifiziert.
Reguläre Ausdrücke lassen sich effizient von endlichen Automaten oder Transduktoren (spezielle Versionen endlicher Automaten, die bei der Syntaxanalyse der Eingabe eine Ausgabe erzeugen) verarbeiten.
Die Verwendung eines Transduktors schließt die Zuordnung eines normalisierten Headerformats ein, da er beispielsweise die verschiedenen fremdsprachigen Übersetzungen des Felds „from" und anderer Headerfelder dem Standardformat ("From:", "To:", "Subject:") zuordnen und alle unnötigen Leerzeichen entfernen kann. Folglich kann eine solche normalisierte Form eine tabellenartige Struktur aufweisen oder so festgelegt werden, dass sie mit einem festen Format konform ist, das von einem Programmalgorithmus leicht ausgewertet werden kann.
Ansatz 3: Heuristische Verfahren
Dieser dritte Ansatz nutzt zusätzliche Hinweise, die im Body einer E-Mail verfügbar sein können, wenn diese aus einer allgemeineren Perspektive betrachtet wird. Ein Beispiel ist die Nutzung von Beziehungen zwischen den Darstellungen verschiedener Header in einem E-Mail-Body, wie z. B.:

• Ähnlichkeiten im Betreff-Feld (z. B. sind die Betreffe in einem E-Mail-Thread bis z. B. auf ein Präfix des Typs 'Re:' identisch).
• Einer elementaren E-Mail kann eine Abfolge von '>'-Symbolen vorangestellt sein (Formatierungsstil des UNIX-Mail-Client für Weiterleitung/Antwort). Dieses Kriterium ist allerdings nur dann relevant, wenn dasselbe Präfix, das aus derselben Anzahl von '>'-Symbolen besteht, der gesamten elementaren E-Mail vorangestellt ist.
• Felder mit dem Präfix "Resent-" (beispielsweise "Resent-From:") zeigen an, dass der Body eine E-Mail enthält, die bei entferntem Präfix "Resent-" durch die entsprechenden Headerfelder definiert wird.
• Der Absender einer E-Mail-Nachricht im Thread ist in der Regel (einer) der Empfänger der Nachricht und ist dieser in einem chronologisch geordneten Thread vorangestellt.

Das hier beschriebene Beispiel verdeutlicht die Funktionsweise:
M2 besteht aus den zwei elementaren E-Mails E1 und E2. Die Betreff-Felder von E1 und E2 sind wie folgt miteinander verbunden:
Der Wert des Betreff-Felds von E2 ist gleich dem Wert des Betreff-Felds von E1, nur dass ihm "Re:" vorangestellt ist.
Die Absender-Empfänger-Beziehungen sind folgende:
Die E-Mail-Adresse des Empfängers von E1 (bob@domain1) entspricht der E-Mail-Adresse des Absenders von E2.
Die drei Ansätze werden auf vorteilhafte Weise kombiniert, da sie auf verschiedene Aspekte des Problems der E-Mail-Trennung eingehen. Während Ansatz 1 auf die gut definierten Rich Text-Formate eines Intranet eines Unternehmens eingeht, dienen die Ansätze 2 und 3 dazu, die Identifizierungsquote in Fällen mit unbekannten oder nur teilweise bekannten Formaten zu maximieren, die auftreten, wenn Nachrichten auf willkürlichen Routen durch das Internet geleitet werden. Heuristische Verfahren können dazu dienen, Nachrichten vorab zu verarbeiten, bevor diese von dem den Transduktor implementierenden Ansatz 2 (Entfernung der vorangestellten '>'-Zeichen) verarbeitet werden, oder sie können dazu dienen, aus einem bereits normalisierten Ergebnis plausible Aufgliederungspunkte auszuwählen.
In einer bevorzugten Implementierung identifiziert das erfindungsgemäße E-Mail-System den Teil, der in einer mehrteiligen E-Mail den E-Mail-Text (Nachrichtenbody) darstellt, und übergibt diesen einer hier als „Aufgliederungs-/Normalisierungsfunktion" bezeichneten Softwarekomponente, die einen Transduktor verwendet, um Aufgliederungspunkte zwischen elementaren E-Mail-Segmenten zu identifizieren und jedes elementare E-Mail-Segment auf der Grundlage eines wie folgt aussehenden Regelsatzes seiner normalisierten Form zuzuordnen:
Der linke Teil ist das Ergebnis, und der rechte Teil liefert eine Definition des Ergebnisses.
Beispielsweise wird die zweite Regel von oben
erfüllt, d. h., ein elementares E-Mail-Segment wird gefunden, wenn ein Parser etwas findet, das auf der rechten Seite der Regel „Gleichung" definiert ist. In diesem Fall wird eine Nachrichtenadresse in einer ankommenden E-Mail gefunden, wenn zwei den Empfänger <addressee> und die Domäne <domain> darstellende Zeichenfolgen erkannt werden, die in der Mitte das Symbol '@' aufweisen. Ein Beispiel wäre "alice@domain1".
Bei einer Normalisierung erstellt der Transduktor zusätzlich zur Syntaxanalyse der Muster ein kanonisches Format der im Header enthaltenen Informationen, indem er <b1> einem einzigen Leerzeichen und <XXXName> dem entsprechenden Standardformat (zum Beispiel „Absender" zu „From" oder „Betreff" zu „Subject") zuordnet. Feldwerte (z. B. Nachrichtenadressen) und Nachrichtenbodys werden vom Transduktor ohne Änderung in die Ausgabe kopiert.
Übertragen auf das hier beschriebene Beispiel lässt sich leicht erkennen, dass beide Headerdarstellungen in M2 von dem regulären Ausdruck erfasst werden. Der E2 entsprechende oberste Header weist die folgende Struktur auf:
während die Darstellung des Headers von M1 in M2 wie folgt aussieht:
Da die von <subject> erfasste Zeichenfolge dieselbe in beiden Headerdarstellungen ist („eine Frage"), werden beide als Begrenzer elementarer E-Mail-Segmente angesehen.
5.2 Berechnung des Schlüssels
Nach der Bestimmung aller Aufgliederungspositionen für alle elementaren E-Mail-Segmente E1, ..., En werden unter Bezugnahme auf 6 anschließend in einem nächsten Schritt 420 für jedes elementare E-Mail-Segment Ei die Schlüssel K1, ..., Kn berechnet. In dieser Ausführungsart wird ein Schlüssel durch eine Kombination der oben genannten Inhalte des Felds „from", des Felds „To", des Felds „subject" und optional des Zeitstempels codiert.
Beispielsweise ist der Schlüssel 36 für M2 im Abschnitt 4.c, d des Beispiels mit folgender Eingabe codiert:
bob@domain2//alice@domain1,chris@domain3,
deirdre@domain4//Hallo//05112004.05:12:37//Danke, gut!
Selbstverständlich können andere Schlüsselkombinationen verwendet werden, solange diese dazu dienen, eine eindeutige ID für ein elementares E-Mail-Segment zu definieren.
5.3 E-Mails speichern/abrufen/löschen
In den 4 und 6 besteht der Schritt 430 darin, nur die elementaren E-Mail-Segmente E1, ..., En zu speichern. Die redundanten Segmente, d. h. bereits gespeicherte Segmente, werden entfernt und nicht erneut gespeichert.
Um dies in einer exemplarischen Implementierung zu tun, ist es erforderlich, den kleinsten Wert m zu finden, sodass die E-Mail-Speichertabelle keinen Eintrag für Km enthält. Es gibt nur zwei verschiedene Optionen a, b:

a. Falls kein solcher Wert m existiert (d. h., alle Schlüssel sind in der E-Mail-Speichertabelle enthalten): soll N der mit Kn verknüpfte Knoten sein. i. Falls für N keine Anhangliste vorhanden ist, ist eine neue Anhangliste für N zu erstellen, und alle Anhänge von M sind dieser Liste hinzuzufügen. ii. Andernfalls: Wenn die Speicherung der E-Mail bereits angefordert wurde, wird keine weitere Aktion ausgeführt.
b. Andernfalls: Für jedes elementare E-Mail-Segment j = m bis n werden die folgenden Schritte ausgeführt: 1. Einen neuen Knoten N ohne Anhangliste erstellen. 2. Den übergeordneten Zeiger des Knotens N auf den mit K (j – 1) in der E-Mail-Speichertabelle verknüpften Knoten verweisen lassen. (Ist kein übergeordneter Knoten vorhanden, wird der übergeordnete Zeiger von K0 als NULL definiert). 3. Den Inhalt Ej des j-ten elementaren E-Mail-Segments in das entsprechende Inhaltsfeld des Knotens N kopieren. 4. Einen neuen Eintrag in der E-Mail-Speichertabelle erstellen, der Kj mit N verknüpft – Schritt 430.

Beim Speichern der E-Mails gemäß diesem exemplarischen Algorithmus wird der Inhalt jedes elementaren E-Mail-Segments exakt einmal gespeichert, und es gibt keine Redundanzen. Mit den übergeordneten Zeigern ist es darüber hinaus möglich, die ursprüngliche E-Mail so wiederherzustellen wie sie ursprünglich gesendet wurde. In dem Beispiel oben soll angenommen werden, dass die E-Mail M6 wiederhergestellt werden soll. Wenn der Knoten bekannt ist, auf dem E6 (das „oberste", d. h. aktuellste elementare E-Mail-Segment von M6) gespeichert ist, lässt sich die ursprüngliche E-Mail wiederherstellen, indem die Inhalte dieses Knotens und aller Vorgängerknoten dadurch verkettet werden, dass in der Baumstruktur bis zum Erreichen des Rootknotens nach oben navigiert wird.
Als Nächstes wird der Schritt 440 zur Wiederherstellung einer ursprünglichen E-Mail gemäß dieser Ausführungsart ausführlicher beschrieben.
Die Wiederherstellung einer E-Mail aus der Gesamtstruktur des Diskussionsverlaufs erfolgt gewissermaßen in einer Weise, die ihrer Speicherung entgegengesetzt ist, vorausgesetzt, die Aufgliederung beginnt in der Vergangenheit und endet in der Gegenwart.
Anhand des Schlüssels K eines elementaren E-Mail-Segments lässt sich die ursprüngliche E-Mail umgehend wie folgt wiederherstellen (siehe 8):

1. Schritt 4420: Schlüssel K in der E-Mail-Speichertabelle suchen, wobei N1 der mit ihm verknüpfte Knoten sein soll.
2. Schritte 4430, 4440: Eine Abfolge von Knoten N1, ..., Nm erstellen, sodass der übergeordnete Zeiger von Ni auf N(i + 1) verweist und der übergeordnete Zeiger von Nm NULL ist. Dies erfolgt, wie in 8 dargestellt, in einer Schleife und mit einer IF-Anweisung.
3. Die Verkettung 4460 der Inhaltfelder von N1, ..., Nm entspricht dann der ursprünglichen E-Mail für K.
4. Falls für den Knoten von N1 eine Anhangliste vorhanden ist: a. Die Anhangtabelle für die ursprüngliche E-Mail nur anhand der Anhangliste von N1 erstellen, d. h., alle Anhang-IDs aus der Liste von N1 in die neue Anhangtabelle kopieren. b. Andernfalls: Dies bedeutet, dass die E-Mail, die mit dem elementaren E-Mail-Segment endet, das mit N1 verknüpft ist, niemals als solche, sondern durch Antworten auf diese E-Mail gespeichert werden sollte. Dann kann eine Nachricht darüber ausgegeben werden, dass die Wiederherstellung einer E-Mail angefordert wurde, obwohl ihre Speicherung zuerst nie explizit angefordert war, und dass somit die Wiederherstellung der Anhänge nicht möglich ist. Je nach Nutzungsszenario ließen sich die Anhänge aller untergeordneten Knoten, bei denen es sich möglicherweise um eine Obermenge der Anhänge von N1 handelt, oder gar keine Anhänge wiedergeben, wenn die Informationen der Anhänge nicht von Bedeutung sind.
5. Ende der Wiederherstellung, Rückkehr zu Schritt 450 in 6.

Folglich wird die ursprüngliche E-Mail wiederhergestellt, indem der aktuelle Knoten ausgewählt wird, und die verkettete Liste zum Rootknoten des Threads so verfolgt wird, dass von der Gegenwart in die Vergangenheit vorgedrungen wird.
In den 4 und 6 wird das elementare E-Mail-Segment E6 mit E4 und E1 verkettet, um die vollständige E-Mail M6 zu bilden. Zur Wiederherstellung von M5 müssen analog dazu E5, E3 und E1 verkettet werden. Zur Wiederherstellung von M2 müssen E2 und E1 verkettet werden.
Schließlich wird in Schritt 450 die verkettete Liste elementarer E-Mail-Segmente an den E-Mail-Client 10, 12 gesendet.
Zusätzlich kann in Schritt 460 eine Archivierungsprozedur aufgerufen werden, der die E-Mail-Speichertabelle wie oben beschrieben archiviert. Dadurch wird der Speicherplatzbedarf im Vergleich zum Stand der Technik deutlich verringert.
Als Nächstes wird eine optionale Löschprozedur wie folgt beschrieben:
Beim Löschen einer E-Mail ist vorzugsweise mehr zu tun als einfach den Knoten zu löschen, der die neueste elementare E-Mail enthält, da dadurch auch alle Antworten auf sie gelöscht werden können. Es sollte nur ein elementares E-Mail-Segment gelöscht werden, dem keine Antworten zugeordnet sind. In Bezug auf den Schlüssel K eines elementaren E-Mail-Segments kann die Löschung wie folgt umgesetzt werden:

1. Schlüssel K in der E-Mail-Speichertabelle suchen, wobei N1 der mit ihm verknüpfte Knoten sein soll.
2. N1, ..., Nm soll die maximale Abfolge von Knoten sein, damit für jedes i: Ni das übergeordnete Objekt von N(i – 1) ist. Insbesondere gilt, dass Nm kein übergeordnetes Objekt hat, d. h., es ist der Rootknoten der Baumstruktur für den Diskussionsverlauf.
3. Den größten Wert k suchen, sodass für alle i = 1, ..., k: Ni keine anderen untergeordneten Knoten aufweist als N(i – 1).
4. Die Knoten N1, ..., Nk aus der E-Mail-Speichertabelle löschen.

Selbstverständlich kann das erfindungsgemäße Verfahren auch auf dem Client 10 implementiert werden (siehe 1 und 2), da im Vergleich zum Server auf einem Client weitaus weniger E-Mail-Verkehr stattfindet und alle erforderlichen Informationen auf dem Client vorhanden sind.
Als Nächstes wird die Behandlung von Anhängen in auf Rich Text basierenden E-Mail-Systemen anhand einer spezifischen Ausführungsart des erfindungsgemäßen Verfahrens beschrieben.
Es wurde oben erwähnt, dass der für RFC822-E-Mails angewendete Aufgliederungsalgorithmus nicht ermitteln kann, welcher Anhang einer E-Mail zu welcher elementaren E-Mail gehört. In einem auf Rich Text basierenden E-Mail-System (wie Lotus Notes) gibt es jedoch Textverweise auf die Anhänge im E-Mail-Body, sodass der Aufgliederungsalgorithmus bestimmen kann, welcher elementaren E-Mail welche entsprechenden Anhänge zugeordnet sind.
In diesem Fall ist es immer möglich, der Anhangliste eines Knotens nur die Anhänge hinzuzufügen, die der entsprechenden elementaren E-Mail tatsächlich angehängt wurden (in dem oben beschriebenen Algorithmus wurden alle Anhänge der gesamten E-Mail gespeichert, die mit dem elementaren E-Mail-Segment endet, das von dem Knoten dargestellt wird). Folgende Modifikationen der oben beschriebenen Prozeduren werden vorgeschlagen:

1. Die Speicherprozedur wird so modifiziert, dass beim Erstellen eines neuen Knotens die Anhangliste des neuen Knotens auf jeden Fall erstellt wird und dass die Anhänge des betreffenden elementaren E-Mail-Segments der Liste hinzugefügt werden.
2. Die Wiederherstellungsprozedur wird in Schritt 4 dahingehend geändert, dass die Anhang-Gesamtliste durch den Vereinigungsalgorithmus set-union aller Anhanglisten aller elementaren E-Mail-Segmente erstellt wird.
3. Das Löschverfahren bleibt unverändert.

Als Nächstes wird zusammen mit dem obigen Beispiel demonstriert, wie die E-Mail-Speichertabelle 30 (4) und die Baumstruktur erstellt werden.
Es wird angenommen, dass die E-Mails in der folgenden Reihenfolge in dem System gespeichert werden:
M1, M2, M3, M5, M6, M4. Wie oben wird angenommen, dass die elementaren E-Mail-Segmente E1, ..., E6 die obersten – aktuellsten – elementaren E-Mail-Segmente von M1, ..., M6 sind. Es gilt zu beachten, dass M6 und M4 nicht in der Reihenfolge gespeichert werden sollen, in der sie gesendet wurden.
Anfangs ist die E-Mail-Speichertabelle leer (siehe 9A).
Dann wird M1 empfangen, sie wird in ihre elementaren E-Mail-Segmente (nur eines, E1) aufgegliedert, und unter ihrem Schlüssel K1 wird ein Knoten mit den Inhalten von E1 gespeichert, es gibt keinen übergeordneten Zeiger und die Anhangliste ist leer, da keine Anhänge gesendet wurden (siehe 9B).
Als Nächstes wird M2 gesendet. Wie nachzuvollziehen ist, handelt es sich um eine Antwort auf M1, und wiederum wird ein Knoten mit einer leeren Anhangliste erstellt, der mit dem Knoten von M1 (der E1 enthält) verknüpft wird (siehe 9C).
Anschließend wird die E-Mail M3 empfangen. Dabei werden ähnliche, wie oben beschriebene Schritte ausgeführt, aber alle Anhänge der vollständigen E-Mail, die in der Anhangliste des Knotens von M3 enthalten sind, werden gespeichert (siehe 9D).
Für M5 sind die Schritte ähnlich. Es ist jedoch anzumerken, dass der Knoten von M5 die beiden Anhänge A1 und A2 enthält, d. h., die Anhänge von M5 befinden sich direkt auf dem M5-Knoten und müssen nicht durch das Zurückverfolgen der Baumstruktur bis zum Rootknoten wiederhergestellt werden (siehe 9E).
Beim Empfangen von M6 unterscheidet sich die Situation etwas von der obigen, weil M4 – die E-Mail, für die M6 eine unmittelbare Antwort darstellt – noch nicht im System gespeichert ist. Folglich muss ein Knoten für M4 ohnehin erstellt werden, obwohl noch keine Anforderung zum Speichern von M4 empfangen wurde. Nun lassen sich in dem allgemeinen Fall einer E-Mail-Korrespondenz gemäß RFC822 die Anhänge von M4 nicht erschließen, und es ist nur bekannt, dass die M4-Anhänge eine Obermenge der M1-Anhänge und eine Untermenge der M6-Anhänge bilden. Es wird daher vorgeschlagen, für den Knoten von E4 keine Anhangliste zu erstellen. Folglich bleiben die Anhänge für M4 unbestimmt. Für M6 kann die Anhangliste, die A3 enthält, erstellt werden (siehe 9F).
Schließlich wird die E-Mail M4 empfangen. Da der Knoten bereits vorhanden ist, ist die Erstellung eines neuen Knotens nicht erforderlich. Es wird jedoch eine Anhangliste für M4 erstellt, da M4 noch über keine verfügt, und in diese werden die tatsächlich vorhandenen Anhänge (in diesem Fall keine) eingefügt (siehe 9F und 9G).
Dadurch wurde die gesamte Baumstruktur des Diskussionsverlaufs gespeichert.
Die vorliegende Erfindung lässt sich in Hardware und Software oder einer Kombination aus Hardware und Software realisieren. Ein E-Mail-Verarbeitungstool gemäß der vorliegenden Erfindung lässt sich zentral in einem Computersystem oder verteilt realisieren, wobei verschiedene Elemente auf mehrere miteinander verbundene Computersysteme verteilt sind. Jede Art von Computersystem oder jede andere zur Ausführung der oben beschriebenen Verfahren angepasste Einrichtung ist geeignet. Eine typische Kombination aus Hardware und Software kann ein Universalcomputersystem mit einem Computerprogramm sein, welches im geladenen und ausgeführten Zustand das Computersystem derart steuert, dass dieses die oben beschriebenen Verfahren umsetzt.
Die vorliegende Erfindung lässt sich auch in ein Computerprogrammprodukt einbetten, das alle Merkmale für die Implementierung der oben beschriebenen Verfahren umfasst und das nach dem Laden in ein Computersystem in der Lage ist, diese Verfahren umzusetzen.
Der Begriff Computerprogrammmittel oder Computerprogramm steht im vorliegenden Kontext unabhängig von Sprache, Code oder Notation für jeden Ausdruck eines Befehlssatzes, der ein über eine Datenverarbeitungsfunktionalität verfügendes System veranlasst, eine spezielle Funktion entweder direkt oder nach mindestens einem der folgenden beiden Vorgänge auszuführen:

a) Konvertierung in eine andere Sprache, Notation oder einen anderen Code;
b) Reproduktion in einer anderen materiellen Form.

Claims

Verfahren in einem Kommunikationssystem für elektronische Post, das mindestens einen Mail-Server (12; 14) und eine Vielzahl von mit einem entsprechenden Server (12; 14) verbundenen Mail-Clients (10; 16) umfasst, um elektronische Postnachrichten zu verarbeiten, die einen Nachrichtenheader und einen Nachrichtenbody aufweisen, dadurch gekennzeichnet, dass es folgende Schritte umfasst: a) Aufgliedern (410) des Nachrichtenbodys einer ankommenden E-Mail-Nachricht an einer oder mehr Aufgliederungspositionen (43, 44) durch eine Syntaxanalyse des E-Mail-Bodys auf der Grundlage einer regulären Grammatik mit einem vordefinierten Satz Umwandlungsregeln, sodass sich eine entsprechende Vielzahl elementarer E-Mail-Segmente ergibt, die mindestens paarweise in einer über- bzw. untergeordneten Beziehung zueinander stehen, b) Berechnen (420) einer eindeutigen ID (36) für jedes elementare E-Mail-Segment, wobei die ID (36) als Index für den Zugriff auf eine E-Mail-Speichertabelle (30) verwendet wird, c) Suchen (4320) der berechneten ID (36) jedes elementaren E-Mail-Segments in der Tabelle (30), d) im Fall, dass die berechnete ID (36) eines elementaren E-Mail-Segments nicht in der Tabelle (30) enthalten ist, Speichern (430) des entsprechenden elementaren E-Mail-Segments als neuen Eintrag in der Tabelle (30) zusammen mit einem Link (34) zu dem besonderen, ihm übergeordneten elementaren E-Mail-Segment, wodurch eine oder mehr sortierte Abfolgen von in Wechselbeziehung zueinander stehenden elementaren E-Mail-Segmenten (41, 45, 46) definiert werden, e) Wiederherstellen einer ursprünglichen E-Mail aus einer Verkettung einer entsprechenden Abfolge der in Wechselbeziehung zueinander stehenden elementaren E-Mail-Segmente (41, 45, 46) zum Zwecke der Anzeige auf einem E-Mails empfangenden Client (10; 16) oder für eine Wiederherstellungsprozedur anhand eines auf der E-Mail-Speichertabelle (30) basierenden E-Mail-Archivs.
Verfahren nach Anspruch 1, wobei ein oder eine Kombination der folgenden Mittel zur Bestimmung der Aufgliederungspositionen (43, 44) von Schritt a) in Anspruch 1 angewendet wird: a) ein Satz vordefinierter Syntaxanalyseregeln zum Erkennen des Beginns (43, 44) eines neuen elementaren E-Mail-Segments (41, 45 46), b) E-Mail-System-spezifische Erweiterungen, die einen Markierungspunkt für eine Aufgliederungsposition ergeben.
Verfahren nach Anspruch 1, wobei die über- bzw. untergeordnete Beziehung zwischen einem ersten und einem zweiten elementaren E-Mail-Segment definiert ist, wenn: a) das zweite die Inhalte einer Antwort auf das erste enthält, oder b) das zweite die Inhalte einer E-Mail enthält, die das erste an einen dritten E-Mail-Empfänger weiterleitet.
Verfahren nach Anspruch 1, wobei die eindeutige ID (36) auf der Grundlage einer Kombination der folgenden Werte berechnet wird: e1) der Inhalte des Felds „from" (46A) im E-Mail-Header, e2) eines einheitlich verwendeten Zeitstempels, e3) der Inhalte des Felds „to" (46B) im E-Mail-Header, e4) der Inhalte des Felds „subject" (46C) im E-Mail-Header, e5) des Bodys des elementaren E-Mail-Segments (46D).
Verfahren nach dem vorherigen Anspruch, ferner umfassend die Schritte, den E-Mail-Body zu normalisieren und die Werte e1) bis e5) in einer normalisierten Form zu verwenden.
Verfahren nach Anspruch 1, wobei der Speicherschritt (430) in Anspruch 1 Schritt d) das Generieren neuer Einträge in der Tabelle (30) umfasst, wobei a) ein Eintrag durch die eindeutige ID (36) indiziert wird und b) der Eintrag ferner Folgendes umfasst: b1) ein Feld (32) für den Inhalt eines elementaren E-Mail-Segments (41, 45, 46), b2) ein Feld (34) für einen Zeiger auf einen übergeordneten Eintrag in der Tabelle und b3) ein Feld (35), das eine Liste von Anhang-IDs enthält.
Verfahren nach Anspruch 1, das ferner folgenden Schritt umfasst: Senden einer verketteten (440) Liste elementarer E-Mail-Segmente (41, 45, 46) als Wiederherstellung der ursprünglichen E-Mail an einen Benutzer.
Verfahren nach Anspruch 1, das ferner folgenden Schritt umfasst: Wiederherstellen einer verketteten (440) Liste elementarer E-Mail-Segmente (41, 45, 46) als Wiederherstellung der ursprünglichen E-Mail aus einem E-Mail-Archiv.
Verfahren nach Anspruch 1, das ferner folgenden Schritt umfasst: Speichern einer Liste von Anhängen einer E-Mail auf dem Knoten, der deren aktuellstes elementares E-Mail-Segment darstellt, als eine Liste von Anhang-IDs (35).
Verfahren nach Anspruch 1, ausgeführt von einem Mail-Server, um Daten elektronischer Post mit reduzierter Redundanz zu archivieren.
Mail-Server-System (12; 14) in einem Kommunikationssystem für elektronische Post, das mit einer Vielzahl von Mail-Clients (10; 16) kommuniziert, um elektronische Postnachrichten zu verarbeiten, die einen Nachrichtenheader und einen Nachrichtenbody aufweisen, gekennzeichnet durch: a) eine Parserprogrammkomponente zum Aufgliedern (410) des Nachrichtenbodys einer ankommenden E-Mail-Nachricht an einer oder mehr Aufgliederungspositionen (43, 44) durch eine Syntaxanalyse des E-Mail-Bodys auf der Grundlage einer regulären Grammatik mit einem vordefinierten Satz Umwandlungsregeln, sodass sich eine entsprechende Vielzahl elementarer E-Mail-Segmente ergibt, die mindestens paarweise in einer über- bzw. untergeordneten Beziehung zueinander stehen, b) eine Programmkomponente zum Berechnen (420) einer eindeutigen ID (36) für jedes elementare E-Mail-Segment, wobei die ID (36) als Index für den Zugriff auf eine E-Mail-Speichertabelle (30) verwendet wird, c) Speichertabellenmittel (30), die einen Zugriffsindex in Form der eindeutigen ID (36) für jedes elementare E-Mail-Segment umfassen, wobei ein Tabelleneintrag ein elementares E-Mail-Segment zusammen mit einem Link (34) zu dem besonderen, ihm übergeordneten elementaren E-Mail-Segment umfasst.
Computerprogrammprodukt, das auf einem von einem Computer lesbaren Medium gespeichert ist und computerlesbare Anweisungen umfasst, um elektronische Postnachrichten zu verarbeiten, die einen Nachrichtenheader und einen Nachrichtenbody aufweisen, zur Verwendung in einem Kommunikationssystem für elektronische Post, das mindestens einen Mail-Server (12; 14) und eine Vielzahl von mit einem entsprechenden Server (12; 14) verbundenen Mail-Clients (10; 16) umfasst, dadurch gekennzeichnet, dass die Anweisungen bei ihrer Ausführung auf einem Computer bewirken, dass der Computer folgende Schritte ausführt: a) Aufgliedern (410) des Nachrichtenbodys einer ankommenden E-Mail-Nachricht an einer oder mehr Aufgliederungspositionen (43, 44) durch eine Syntaxanalyse des E-Mail-Bodys auf der Grundlage einer regulären Grammatik mit einem vordefinierten Satz Umwandlungsregeln, sodass sich eine entsprechende Vielzahl elementarer E-Mail-Segmente ergibt, die mindestens paarweise in einer über- bzw. untergeordneten Beziehung zueinander stehen, b) Berechnen (420) einer eindeutigen ID (36) für jedes elementare E-Mail-Segment, wobei die ID (36) als Index für den Zugriff auf eine E-Mail-Speichertabelle (30) verwendet wird, c) Suchen (4320) der berechneten ID (36) jedes elementaren E-Mail-Segments in der Tabelle (30), d) im Fall, dass die berechnete ID (36) eines elementaren E-Mail-Segments nicht in der Tabelle (30) enthalten ist, Speichern (430) des entsprechenden elementaren E-Mail-Segments als neuen Eintrag in der Tabelle (30) zusammen mit einem Link (34) zu dem besonderen, ihm übergeordneten elementaren E-Mail-Segment, wodurch eine oder mehr sortierte Abfolgen von in Wechselbeziehung zueinander stehenden elementaren E-Mail-Segmenten (41, 45, 46) definiert werden, e) Wiederherstellen einer ursprünglichen E-Mail aus einer Verkettung einer entsprechenden Abfolge der in Wechselbeziehung zueinander stehenden elementaren E-Mail-Segmente (41, 45, 46) zum Zwecke der Anzeige auf einem E-Mails empfangenden Client (10; 16) oder für eine Wiederherstellungsprozedur anhand eines auf der E-Mail-Speichertabelle (30) basierenden E-Mail-Archivs, wenn das Computerprogrammprodukt auf einem Computer ausgeführt wird.