Die vorliegende Erfindung umfasst ein Verfahren, das zum sicheren Suchen, Finden, Wiedergeben, Wiederherstellen und/oder Exportieren von elektronischen Daten dient. Insbesondere soll hier ein Verfahren geschaffen werden, welches es ermöglicht, elektronische Daten in einem Verbund von funktionsumfangsgleichen und dezentral organisierten Systemen zu erfassen und einem oder mehreren Benutzern bereitzustellen.

Nach dem Stand der Technik ist es bekannt, dass elektronische Daten mithilfe von entsprechenden Datenbanken und elektronischen Datenverarbeitungsanlagen zweckmäßig verarbeitet werden können. Im klassischen Sinn liegt hierbei ein sogenanntes„Client-Server Modell" vor, wobei der Client dem Ser- ver eine Anfrage, einen sogenannten Request auf einen Dienst des Servers stellt und auf die Antwort des Servers, die sogenannte Response, wartet, bevor der Client den Dienst des Servers in Anspruch nimmt. Die Einsatzgebiete der jeweiligen Datenbanken sind im Regelfall an die Bedürfnisse der Anwendung angepasst.

Seit geraumer Zeit tut sich allerdings ein völlig neues Konzept in der Informationstechnologie auf: das sogenannte „cloud Computing". Das Konzept dieser Entwicklung verspricht hohes Potential, da Software und Daten nicht mehr lokal bearbeitet werden bzw. gespeichert werden, sondern in einer komplett externen und komplexen Infrastruktur. Mit dieser aufstrebenden Technologie ist es auch möglich, komplette Hardware- und Softwaresysteme in die sog. Cloud auszulagern und somit die benötigten IT-Leistungen in Echtzeit als Service über ein Netzwerk wie beispielsweise das Internet bereitzustellen und nach jeweiliger Nutzung verrechnet zu bekommen. Selbstverständlich birgt diese„Outsource- technik" nicht nur Vorteile, sondern auch Nachteile, welche sich massiv im Rahmen der Datensicherheit und der Ausfallsicherheit niederschlagen. Durch moderne Geschäfts- und Bürostrukturen ist vernetztes Arbeiten zu einer der Säulen der Geschäftserfolge geworden und folglich ein Wegdenken selbiger Strukturen und dazugehöriger Hard- und Software nicht mehr oder nur schwerlich denkbar. Der größte Teil aller Büroarbeiten wird heute im Regelfall über elektronische Datenverarbeitungsanlagen in Verbindung mit einer Vielzahl von Programmen und Systemen abgearbeitet.

Ein wesentlicher Bestandteil der Kommunikation im Geschäfts- und Büroalltag bildet die elektronische Korrespondenz, welche ein geeignetes E-Mail-Pro- gramm in Verbindung mit einem Eingabegerät wie beispielsweise Computer, Laptop, Blackberry-Systemen, Tablet-PC, usw. ein fester Bestandteil der modernen Kommunikation ist. Selbstverständlich sind durch die modernen elektronischen Kommunikationsmittel nicht alle Informationsstrukturen der modernen Büroarbeit abgedeckt und somit ist es verständlich, dass zusätzlich der klassi- sehe postalische Brief und das Telefax noch immer einen durchaus respektablen Stellenwert in beinahe jeder Geschäfts- und Bürostruktur haben.

Durch neue und moderne Möglichkeiten der Datenerfassung und Archivierung überrascht es auch kaum, dass als Verbindung zwischen moderner Datenver- arbeitung und dem klassischen Brief/Faksimile, die optische Zeichenerkennung („Optical Character Recognition", kurz OCR) Einzug gehalten hat.

In diesem Fall wird zusätzlich zu den klassischen Archivierungssystemen, wie Aktenablagen und entsprechender Einführung von Identifikationselementen z.B. Aktenzeichen oder dergleichen, das betreffende Schriftstück mittels geeignetem externen Peripheriegerät eingescannt und durch eine sogenannte OCR- Software eine optische automatische Texterkennung und gegebenenfalls eine automatische Textkorrektur durchgeführt. Das nun elektronisch vorliegende Dokument kann nun selbstverständlich in schon bestehende Archivierungssyste- me eingegliedert werden, respektive mittels elektronischer Post im Anhang weltweit ohne Zeitverzögerung versendet werden. Durch dieses beschriebene „Elektrifizieren" der klassischen Geschäftsdaten greift die im modernen Büroalltag essentielle Methode der elektronischen Archivierung der Daten hinaus. Hierbei wird durch geeignete IT-Infrastrukturen ein Archivieren von jeglichen im Geschäftsalltag anfallenden Daten, wie E-Mails, Telefongesprächen usw. möglich. Die Möglichkeit, auch z.B. postalische Korrespondenz und Faksimile in ein elektronisches Archivierungs- bzw. Datensystem einzubinden, ist aufgrund der obigen Beschreibung im vollständigen Ausmaß gegeben.

Ein grundsätzlicher Vorteil eines solchen Archivierungssystems für elektronische Daten ist die Tatsache, dass von den elektronischen Daten in ihrer Gesamtheit ein Replikat erzeugt und entsprechend im elektronischen Archiv abge- legt wird. Diese standardisierte Methodik erlaubt nun, unabhängig vom Betriebssystem des jeweiligen dienten eine allumfassende Sicherung der elektronischen Daten, welche eine hohe Ausfallsicherheit aufgrund der Tatsache der Archivierung der Replikate sicherstellt. Im Regelfall sind diese gesicherten Rep- likate jederzeit wiederherstellbar und somit kann im Falle eines Ausfalls des dienten der letzte bekannte Zustand der elektronischen Daten sofort wiederhergestellt werden.

Um die Möglichkeit der elektronischen Archivierung vollends nutzen zu können, bedarf es aber zusätzlich passender IT- Infrastrukturen, welche es ermöglichen auf bereits archivierte Daten wieder zuzugreifen und konkrete Daten über diese Infrastruktur nicht nur wieder zu finden, sondern auch für den jeweiligen Benutzer so bereitzustellen, dass diese angeforderten Daten in aufbereiteter und lesbarer Form zur Verfügung gestellt werden. Da nun diese Archive je nach Unternehmensgröße entsprechende Dimensionen erreichen können, spielt die inter- ne Organisation des Archivs, ebenso wie die Simplizität der Wiederherstellung der angefragten Daten eine maßgebliche Rolle.

Da nun der komplette Umfang aller elektronischen Daten in einem Unternehmen, welches einen Zusammenschluss verschiedener technischer, primär selbstständiger elektronischer Systeme umfasst, ad-hoc nicht so ohne weiteres erfasst werden kann, stellt dies eine schwierige Aufgabenstellung an die IT- Infrastruktur. Falls nun aber die benötigten elektronischen Daten weder auf dem lokalen Arbeitsplatz (Client), noch auf dem dafür vorgesehenen Archivierungssystem zu finden sind, bleibt dem betroffenen Mitarbeiter oftmals nicht anderes übrig, als durch Nachfragen und Recherchieren eventuell zu den benötigten Daten kom- men. Diese Recherchen sind nicht selten zeitlich sehr aufwendig und beispielsweise bei Unternehmen, die global tätig sind, alleine schon aus dem Gesichtspunkt der räumlichen Distanz im wirtschaftlichen Sinn nicht rentabel, da das Ergebnis in keiner Relation zu dem aufgebrachten Aufwand steht. Möglicherweise ist aber genau eine solche Recherche von Nöten und eine ent- sprechende unwirtschaftliche Produktivität muss in Kauf genommen werden.

Durch eine Globalisierung der Unternehmen und die damit verbundene Dezentralisierung der Standorte muss damit gerechnet werden, dass der Informations- fluss in diesem Bereich zukünftig möglicherweise weiter eingeschränkt wird und die oben genannte unwirtschaftliche Produktivität vielleicht auf Dauer hingenommen werden muss. Hier ergeben sich offensichtlich aus dem Stand der Technik massive Nachteile, welche sich dadurch zeigen, dass die zuvor angesprochenen Strukturen per se über eine zentrale Datenverarbeitungsanlage verfügen müssen, oder vom sicherheitstechnischen Aspekt wenig vertrauens- würdig sind. Durch diese Globalisierung der Unternehmen ist aus der Praxis bekannt, dass bei weltweit tätigen Unternehmen, die auch mehrere geografisch verteilte Filialen oder Tochterunternehmen betreiben, es zu Problemen hinsichtlich der Speicherung und Übermittlung von Daten in Abstimmung mit den jeweiligen Gesetzen des jeweiligen Landes kommen kann. Beispielsweise kommt es bei der Richtlinie 95/46/EG zum Schutz natürlicher Personen bei der Verarbeitung personenbezogener Daten und zum freien Datenverkehr zu Problemen, da diese Richtlinie beispielsweise ein grundsätzliches Verbot der Übertragung von personenbezogen Daten aus EU-Mitgliedsstaaten in Staaten vorsieht, welche nicht über ein dem EU-Recht äqualem Datenschutzniveau verfügt. Zentrales Dogma hierbei ist der Speicherort der jeweiligen Daten.

Ein weiterer Aspekt der Aufgabe ist es natürlich, bereits vorhandene Infrastruktur in Verbindung mit vorherrschenden aktuellen und künftigen Standards zu verwenden und somit ein Verfahren zu schaffen, welches auch in einigen Jahren noch eine schnelle und nach Möglichkeit unkomplizierte Handhabung für den Benutzer erlaubt, dennoch aber nichts von seiner Sicherheit einbüßt und jederzeit ohne großen Aufwand erweiterbar ist.

Diese Aufgabenstellung wird vom Stand der Technik bei weitem nicht erreicht, da dieser entweder über ein Client-Server System abgearbeitet wird und somit eine zentrale Datenverarbeitungsstelle hat, welche zwar redundant ausgeführt sein kann, aber dennoch vor Angriffen von außen nicht gefeit ist, da bei einem erfolgreichen Angriff auf das Serversystem das restliche System nicht mehr arbeitsfähig ist. Ähnlich sieht es bei der schon erwähnten Cloud-Lösung aus, bei welcher alle Daten und selbst die entsprechende Software teilweise oder komplett in der Cloud-Lösung ausgelagert sind. Hinsichtlich der Datensicherheit scheint dies ebenfalls keine ideale Lösung zu sein. Der grundsätzliche Aufwand welcher betrieben werden müsste, um diesen Stand der Technik datensicher, ausfallssicher und vor allem so erweiterbar zu machen, ist exorbitant. Aus der Praxis ist bekannt, dass in besagten Verfahren die vorhandene Infrastruktur bei einer Vergrößerung der Struktur mit erheblichem Kostenaufwand und entsprechendem Zeitaufwand so angepasst werden muss, um dem Benutzer ein prob- lemloses Arbeiten zu gewährleisten. Diese Gewährleistung erfordert oft eine Rundum-Anpassung der kompletten zentralen Informationsverwaltung, welche mit einem erheblichen Maß an Mehraufwand und möglichen Problemen im Bereich der Integration in das vorhandene System verbunden sind. Andererseits generiert beispielsweise eine Migration von Teilsystemen ebenfalls massive Probleme hinsichtlich des Aufwandes. Die zentralisierten Gesamtdaten müss- ten in einem Migrationsfall separiert werden und entsprechend weiterverarbeitet werden. Insofern wäre ein Veräußern von Firmenteilen inklusive der entsprechenden elektronischen Daten auch hinsichtlich der finanziellen Aufwendungen für die Separation der zentralisiert gespeicherten Daten nicht zu verachten.

Aus dem Stand der Technik ist also nun bekannt, dass zentrale Datenverarbeitungsstellen dazu verwendet werden um Client-Server Systeme zu verwalten und die jeweiligen Clients mit entsprechenden Informationen durch zentralisier- te Server versorgt werden. Durch diese Zentralisierung ergeben sich offensichtlich einige massive Nachteile. So muss im Wartungsfall entweder für adäquaten Ersatz gesorgt werden, oder der Zeitpunkt der Wartung an den Arbeitsalltag angepasst werden. Dies kann in global tätigen Unternehmen schon zu massi- ven Problemen führen, wie beispielsweise ein geeignetes weltweites Wartungsfenster zu finden. Eine unvorhergesehene Systemhavarie kann im schlimmsten Fall zu einem längeren Ausfall der Produktivität des Unternehmens führen und würde mit entsprechenden finanziellen Kraftakten verbunden sein. Die angesprochene Systemhavarie kann beispielsweise sowohl von aktiven Angriffen auf den zentralisierten Server, als auch von einem Ausfall eines zentralisierten Systems oder vom Fehlerfall an einer Datenleistung herrühren. Grundsätzlich ist aber in jedem Fall das Gesamtsystem von dem Ausfall betroffen und eine Wartung bzw. Datenwiederherstellung kann in diesem Fall sehr kostenintensiv sein. Selbst eine Erweiterung des Systems kann zu erheblichen Schwierigkeiten beim laufenden Betrieb kommen.

Vor diesem Hintergrund ist es die Aufgabe der vorliegenden Erfindung, ein Verfahren zu etablieren, welches es möglich macht, elektronische Daten bzw. archivierte elektronische Daten, welche auf mindestens zwei in einem Verbund befindlichen, funktionsumfangsgleichen und dezentral organisierten Systemen abgelegt sind, mithilfe eines sicheren Verfahrens zu suchen, zu finden, wiederzugeben, wiederherzustellen und/oder zu exportieren.

Es wurde ein Verfahren zum sicheren Suchen, Finden, Wiedergeben, Wieder- herstellen und/oder Exportieren von elektronischen Daten von mindestens zwei in einem Verbund befindlichen, funktionsumfangsgleichen und dezentral organisierten Systemen gefunden, das zumindest die folgenden Verfahrensschritte umfasst: a. Verschlüsselte Anfrage für die angefragten Daten zwischen mindestens zwei funktionsumgangsgleichen Systemen, welche für sich ein Schichtenmodell aufweisen und mindestens aus einer Präsentationsschicht und einer Datenzugriffsschicht bestehen, b. Authentifizierung der gestellten Suchanfrage und/oder des Benutzers, welche durch die Präsentationsschicht des angefragten Systems geprüft wird,

c. Ausführen der authentifizierten Anfrage,

d. Überprüfung des Ergebnisses und verschlüsselte Übermittlung der relevanten angeforderten Daten, und

e. Darstellen und/oder Weiterverarbeiten der angeforderten Ergebnisse. Wie in Figur 1 ersichtlich ist, können die Schichten, welche in diesem Ausführungsbeispiel aus den Präsentationsschichten PA bzw. PB und Datenzugriffsschichten DA bzw. DB ausgeführt sind, mehrere Komponenten beinhalten. Die Datenzugriffsschicht D kann beispielsweise aus einer Archivierungskomponente 2A, einer Datenbank 3A, einem Suchserver 4A, einem System zur Indizierung 5A und einem Index 6A bestehen. Diese Komponentenkombination ergibt sich aus den Anforderungen des jeweiligen Systems und ist daher nicht als limitierend zu sehen. Figur 1 zeigt weiter das schematisierte, einfindungsgemäße System, welches beispielsweise aus System A und System B besteht, welche grundsätzlich funktionsumfangsgleich aufgebaut sind. Das jeweilige sich im Systemverbund befindliche System, z.B. System A, umfasst mindestens eine Präsentationsschicht PA, welche vorzugsweise der Datenzugriffsschicht DA verbunden ist. Wie in Figur 1 beispielhaft ersichtlich, ist die Präsentationsschicht PA mit einer Datenbank 3A verbunden. Weiter besteht eine vorteilhafte Verbindung zu dem Suchserver 4A welcher wiederum auf einen Index 6A zu- greifen kann. Der Index 6A selbst wird nicht nur vom Suchserver 4A gelesen, sondern kann auch von der Indizierungskomponente 5A beschrieben werden. Wie aus Figur 1 ersichtlich ist, gilt dieser grundsätzliche Aufbau auch für die jeweils anderen Systeme in diesem Systemverbund. Die schematisch dargestellte Ausgestaltung von zwei Systemen weist ebenfalls die jeweilige Anfrage 1 von System A auf System B , sowie die entsprechende Antwort 2 von System B nach System A auf, welche ebenfalls schematisch in Figur 1 dargestellt wurden. Grundsätzlich wird im erfindungsgemäßen Verfahren ein verschlüsseltes Transportprotokoll wie beispielsweise HTTPS verwendet. HTTPS hat als Beispiel den Vorteil, dass es per se durch symmetrische Verschlüsselung und HMACs (Keyed - Hash Message Authentication Code, dessen Konstruktion auf einer kryptografischen Hash-Funktion basiert) alle übertragenen Daten vor Mitlesern und vor Veränderung schützt. Ein weiterer Vorteil der Verwendung von HTTPS, welches hier natürlich nur als Beispiel angeführt wird ist, dass es einen Sitzungsschlüssel erstellt, welcher je nach gewählter Protokollvariante nach Ende der Kommunikation vernichtet wird und so auch nachträglich keine Auskunft über den Inhalt der jeweiligen verschlüsselten Kommunikation gibt. Darüber hinaus werden Daten nicht nur verschlüsselt, sondern beispielsweise auch vor Veränderung geschützt, da die interne Reihenfolge der Daten mitgesichert wird und so Dateninhalte weder vertauscht noch herausgenommen werden können. Somit wäre mit einem Protokoll wie beispielsweise HTTPS eine standardisierte und wirkungsvolle kryptografische Absicherung der Daten erreicht. Bevorzugt sollte im erfindungsgemäßen Verfahren HTTPS verwendet werden, da dies ein etablierter sicherer Industriestandard ist, dessen Sicherheit mit der einer VPN-Technik wie beispielsweise IPSec vergleichbar ist. Natürlich bringt die Verwendung von HTTPS folglich einige Vorteile mit sich, welche ei- nen sicheren und robusten Betrieb des Verfahrens sicherstellen. Die bevorzugte Ausgestaltung in HTTPS sollte aber nicht als limitierend gesehen werden, da prinzipiell jedes verschlüsselte Transportprotokoll an die Stelle von HTTPS treten könnte und dieses nur eine bevorzugte Ausgestaltungsform darstellt. Der Sicherheitsaspekt, welcher beispielsweise nicht über eine Verschlüsselung gelöst werden kann, ist jener der Authentifizierung der jeweiligen Systeme bzw. der Benutzer. Prinzipiell basiert das erfindungsgemäße Verfahren darauf, dass sich sämtliche im Verbund befindlichen Systeme gegenseitig grundsätzlich misstrauen. Durch dieses grundsätzliche Misstrauen wird ein Sicherheitsstan- dard geschafften, welcher darauf beruht, dass selbst bei einem kompromittierten System nur im jeweiligen Berechtigungsumfang der Zugriff auf die entsprechenden anderen Systeme möglich ist. In der hier vorliegenden Erfindung werden hierfür bevorzugt Zertifikate verwendet, welche beispielsweise mithilfe einer „Public-Key-Infrastruktur" und der entsprechenden Kombination aus Zertifikaten und dazugehörigem privaten Schlüssel bewerkstelligt wird. In der Regel enthält ein solches System einen privaten Schlüssel und ein Zertifikat mit einem öffentlichen Schlüssel. Dieses Zertifikat ist von einer Zertifizierungsstelle unterschrie- ben, wozu diese wiederum ihren privaten Schlüssel benutzt. Das öffentliche Zertifikat der Zertifizierungsstelle (Stammzertifikat) wird allgemein bekannt gemacht, so dass jeder die Zertifikate prüfen kann. Ein wichtiger Gesichtspunkt hierbei ist, dass die in den Zertifikaten enthaltenen Serveradressen und Namen sowie weitere Attribute vom Benutzer nicht geändert bzw. manipuliert werden können, da diese mit dem privaten Schlüssel des Stammzertifikats gezeichnet sind.

Grundsätzlich enthält jedes System des erfindungsgemäßen Verfahrens bei der Produktion vom Hersteller eine eindeutige Seriennummer. Bevorzugt kann der Hersteller eine Zertifizierungsstelle betreiben, welche dem jeweiligen System automatisch bei der Herstellung ein Zertifikat ausstellt. Um einen möglichst sicheren Zugriff auf das System zu gewährleisten, ist es generell besonders vorteilhaft, dass der Zugriff auf die Weboberfläche über HTTPS ausgeführt werden kann, und diesbezüglich ein vorteilhaft ausgeführtes Zertifikat verwendet wer- den kann, welches beispielsweise schon durch den Hersteller auf dem Gerät installiert sein kann. Da zum Zeitpunkt der Herstellung im Regelfall noch nicht bekannt ist, in welchem Umfeld das System eingebunden wird, ist es vorteilhaft, wenn es sich bei diesem Zertifikat um ein Zwischenzertifikat handelt, welches vom System selbst verwendet werden kann, um ein konkretes Zertifikat zu er- zeugen und zu signieren, wenn es an seinem Bestimmungsort bzw. an seiner Bestimmungsdomain gebunden wird. Aus dem Zwischenzertifikat können durch das System beispielsweise eine oder mehrere IP-Adressen oder DNS-Namen so verarbeitet werden, dass aus dem gespeicherten Zwischenzertifikat ein vollwertiges Zertifikat bei der Einbindung in ein vorhandenes Netzwerk erstellt wird, über das eine per HTTPS gesicherte Weboberfläche des Systems bereitgestellt werden kann. Bei einer vorteilhaften Ausgestaltung kann der Hersteller die jeweiligen Zertifikate schon mit entsprechenden Seriennummern versehen. Dieses Zertifikat kann überdies bei einer nachträglichen Integration eines Systems ohne entsprechendem Zertifikat beispielsweise im Rahmen eines Update nachgereicht werden. Es kann vom Hersteller einmalig nachgeneriert werden und mithilfe eines Daten bankflags wird dafür Sorge getragen, dass dies pro System nur einmal möglich ist und so etwaiger Missbrauch ausgeschlossen werden kann. Da der private Schlüssel, welcher zum Ausstellen der Zertifikate verwendet wird, ausschließlich im Besitz des Herstellers bzw. einer Zertifizierungsstelle des Herstellers ist, kann vom Benutzer selbst keine Seriennummer geändert oder modifiziert werden. Anhand dieser Seriennummer, die ausschließlich vom Hersteller vergeben werden kann, ist ein sicheres Authentifizieren möglich. Einem Angreifer ist es also nicht möglich diese Seriennummer in einer für ihn vorteilhaften Art zu kompromittieren. Weiter ergibt sich daraus auch die Möglich- keit, dass dieses Zertifikat in Verbindung mit HTTPS auch als sogenanntes „Clientzertifikat" verwendet werden kann. Dies könnte beispielsweise zum Authentifizieren an einem anderen System verwendet werden. Hierzu könnte aber beispielsweise auch ein weiteres Zertifikat verwendet werden, welches vorteilhaft für die Authentifizierung über eine Seriennummer verfügt, und vom Herstel- ler des Systems sehr vorteilhaft bei der Herstellung generiert wurde. Dieses Zertifikat kann aber auch beispielsweise im Rahmen eines Updates nachgereicht werden.

Diese vorteilhafte Ausgestaltungsform macht es auch möglich, Austauschsys- teme, welche an die Stelle von defekten oder in Wartung befindlichen Systemen treten, so zu integrieren, dass das Austauschsystem ohne Sicherheitsbedenken oder zusätzlichen Aufwand integriert werden kann. Dazu muss der Hersteller vor der Integration des entsprechenden Systems im Wesentlichen die entsprechenden Zertifikate in das jeweilige System einbringen. Vorteilhafterweise ent- halten diese Zertifikate die entsprechende Seriennummer und das jeweilige System kann so einfach in den Verbund integriert werden. Dieses neue Zertifikat enthält nun eine Originalseriennummer, um so bei beispielsweise einem Austauschsystem oder einem Standbysystem ohne weitere Probleme die Originalseriennummer für das Zertifikat benutzen zu können.

Selbstverständlich kann ein gebrauchtes System, welches möglicherweise aus einem andern Verbund kommt, ebenso in den Verbund eingefügt werden, ohne dass ein nicht berechtigtes System Zugriff auf den Verbund der Systeme hat. Vorteilhaft an dieser Ausgestaltung der Erfindung ist die Tatsache, dass der Austausch von Schlüsseln, Passwörtern oder Zertifikaten hier nicht zwingend notwendig ist, da alle nötigen Daten beispielsweise mithilfe einer Konfigurati- onstabelle angepasst werden können.

Wenn sich nun System A mit System B bei einer Abfrage verbinden will, kann System A über das Zwischenzertifikat dann prüfen, ob es sich beim verbundenen System auch tatsächlich um das System B handelt. Nachdem die Prüfung von System B durch das System A abgeschlossen ist, kann sich das System A sicher sein, auch mit dem System B zu kommunizieren. Anschließend authentifiziert sich nun System A gegenüber System B beim weiteren Aufbau der HTTPS-Verbindung mit dem eigenen Client-Zertifikat. Nun kann auch das System B sicher sein, dass sich System A und kein anderes System des Verbun- des mit ihm verbunden hat. Dieser Mechanismus ermöglicht es, dass alle weiteren Berechtigungsprüfungen ausschließlich auf Basis der Seriennummern erfolgen können und eine sehr hohe Sicherheit für die Verbindung gewährleistet ist. Durch die Seriennummern der Systeme, die natürlich auf allen Systemen hinterlegt wird, wird sichergestellt, dass sich nur berechtigte Systeme miteinan- der verbinden können. Im Praxisfall handelt es sich hierbei um firmeneigene Systeme, die möglicherweise weltweit verteilt sind.

Grundsätzlich sollte die Benutzerverwaltung in Administratoren und Benutzer gegliedert werden, wobei die Administratoren in der Regel alle Daten von allen Benutzern anfragen können, während die Benutzer jeweils nur ihre eigenen Daten abfragen können. Allerdings können hierbei auch Administratoren insofern in ihren Abfragen limitiert werden, als dass diese beispielsweise nur Daten über einen bestimmten Zeitraum abfragen dürfen. Ziel hierbei muss es immer sein, sowohl den Benutzern als auch den Administratoren die für sie jeweils relevanten Informationen im Suchverbund bereitzustellen und diese entsprechend mit Zugriffsrechten zu versehen. Es muss jedem System im Verbund eine Konfigurationstabelle vorliegen, die jedem anderen System in diesem Verbund Daten zuweist. Eine derartige einzelne Konfigurationstabelle kann beispielsweise folgende Daten beinhalten:

- Seriennummer von System B;

- IP/DNS Adresse, unter der System B für System A erreichbar ist;

- ob System B nur über einen Proxyserver erreichbar ist;

- Gewählter Name von System B, welcher bei einer Abfrage als Ergebnis ausgegeben werden kann;

Tooltip;

- Icon; welcher beispielsweise ein Firmenlogo oder eine Landesflagge beinhalten kann;

- Benutzerkontennamen, die hier eine Anfrage 1 stellen dürfen, ohne ein korrektes Passwort zu nennen;

- Benutzerkontennamen, die hier eine Anfrage 1 stellen können, wenn ein korrekter Benutzername und Passwort genannt wurden;

- Benutzerkontennamen, die hier eine Anfrage 1 stellen können, wenn sie durch eine sogenannte Single Sign-on-Abfrage, also einer Einmalabfrage ermittelt wurden;

- Benutzerkontennamen, die, wenn sie auf System A angemeldet sind, System B automatisch immer abfragen;

- Administratorkontennamen, die hier abfragen können, wenn sie korrekt Benutzernamen und Passwort eines Administratorkontos auf System A vorweisen können. Für den Teil der Abfrage, der auf System A stattfindet, werden die Rechte und Abfrageeinschränkungen, die für den Admi- nistrator auf System A definiert sind, verwendet;

- Administratorkontennamen, die hier abfragen können, wenn sie einen existierenden Benutzernamen eines Administratorkontos auf System A vorweisen können. Für den Teil der Abfrage, der auf System A stattfin- det, werden die Rechte und Abfrageeinschränkungen, die für den Administrator auf System A definiert sind, verwendet;

- Administratorkontennamen, die hier abfragen können, auch wenn sie nicht existieren. Für den Teil der Abfrage, der auf System A stattfindet, werden die Rechte und Abfrageeinschränkungen, die für den Administrator auf System B definiert wurden verwendet. Dabei werden die Rechte und die weltweit eindeutige ID (GUID) der Administratoreinschränkung bei der Anmeldung mit übertragen. Existiert die Administratoreinschränkung nicht unter dieser GUID, scheitert die Anmeldung;

- Administratorkontennamen, die, wenn sie auf System A angemeldet sind, System B auf Wunsch abfragen können sollen;

- Administratorkontennamen, die, wenn sie auf System A angemeldet sind, System B automatisch immer abfragen.

Natürlich sind dezidierte Kontonamen auch mithilfe von Platzhaltern auf alle Benutzer ausdehnbar. Man wird also in der Regel jede Kombination aus Systemen in je einer Tabellenzeile der Konfigurationstabelle finden, dort können die genannten Einstellungen dann für„Alle", „Keinen" oder für explizit benannte Benutzer und Administratoren freigegeben oder gesperrt werden.

Ein Abfragevorgang durch einen Administrator würde nun beispielsweise so aussehen:

Der Administrator 1 meldet sich an System A an und öffnet die Abfrageseite. Das System A ermittelt daraufhin aus der Konfigurationstabelle auf dem System A, welche Abfrageoptionen überhaupt für den Administrator 1 vorgesehen sind. Führt der Administrator 1 nun beispielsweise auf einer Weboberfläche 1A von System A eine Anfrage 1 aus, so wird das System A zu den gewünschten bzw. je nach Konfigurationstabelle berechtigten Systemen eine Verbindung aufbauen, die beispielsweise auf HTTPS basieren kann.

Hierbei wird geprüft, dass das korrekte HTTPS - Zertifikat der jeweiligen Systeme vorgelegt wird, damit sich System A sicher sein kann, die Anfrage 1 auch an die korrekten Systeme, wie beispielsweise System B, zu senden und nicht ein falsches System mit der Anfrage 1 beauftragt.

Das berechtige System, wie beispielsweise System B, wird sobald die Verbin- dung von System A ankommt, das HTTPS - Client-Zertifikat von System A prüfen und nun mit seiner eigenen Konfigurationstabelle abgleichen, ob dieses System bzw. Systeme überhaupt bekannt sind und welche Berechtigung die jeweiligen Benutzer auf System A haben. Das System A meldet sich nun über diese HTTPS API an System B (bzw. allen anderen involvierten Systemen) im Namen von Administrator 1 an. Das System B prüft diese Anmeldung von System 1 entsprechend der Berechtigung und der Anforderung. Wäre jetzt hier ein Passwort involviert, würde dieses Passwort so geprüft, als würde sich der Administrator 1 direkt auf der Weboberfläche 1 B von System B anmelden. Überdies würde in der Konfigurationstabelle von System B ebenfalls das System A anhand seiner Seriennummer erkannt und durch den Eintrag in der Konfigurationstabelle würden die Anfragerechte des jeweiligen Benutzers ebenfalls abgefragt werden. Das System B weiß nun, welche Rechte der Administrator 1 hat, wenn er auf dem System A eingeloggt ist und dann eine Anfrage 1 an System B stellt. Das System A kann jetzt eine Abfrage über HTTPS (beispielsweise über Port 442) direkt an das System B senden. Falls vom System A eine Abfrage an mehreren Systemen erfolgt, werden diese Abfragen natürlich gleichzeitig von System A an all jene Systeme versendet, welche im Rahmen dieser Abfrage abgefragt werden dürfen. Das System B führt nun die Abfrage durch und sendet das Ergebnis in Stücken an das System A zurück, welches diese Stücke zu- sammenfügt und dem Administrator 1 präsentiert. Wenn diese Abfrage beispielsweise eine E-Mail oder einen Teil einer E-Mail behandelt, und der Administrator einen Viewer für diese E-Mail aufruft, welche auf System B gespeichert ist, so sendet System A über die HTTPS-Verbindung und die entsprechende Sitzung einen Befehl zum System B, welches das System B beispielsweise mit Header und Body beantwortet. Hierbei ist es unerheblich, auf welchem System die Daten gespeichert sind, denn bei einem Ergebnis auf einem anderen System hätte dieses jeweilige System auf den Befehl für beispielsweise Header und Body reagiert. Aus der Praxis ist bekannt, dass es vorkommen kann, dass entsprechende Systeme durch deren Entwicklung aus verschiedenen Komponenten und aus verschiedenen Programmiersprachen bestehen. Mit dem erfindungsgemäßen Verfahren spielt dies eine untergeordnete Rolle.

Das erfindungsgemäße Verfahren macht es möglich, zum Beispiel Suchanfragen 1 so auszuführen, dass beispielsweise der Benutzer eine Anfrage 1 von der Weboberfläche bzw. der Präsentationsschicht PA aus startet und diese in der Präsentationsschicht PA dargestellt wird, wenn genug Ergebnisse für eine Seite (z.B. 50 Stück) vorhanden sind. Durch die Verwendung von beispielsweise PHP in der Präsentationsschicht PA wäre es nicht möglich, die Requests nach der ersten Ergebnisseite aufrecht zu erhalten, da PHP alle Datenstrukturen und offenen Verbindungen grundsätzlich nach Abarbeiten eines jeden Requests zerstört und keine weiterlaufenden Hintergrundprozesse unterstützt. Nun ist es vorteilhaft, die Struktur des jeweiligen Systems mit einem Suchserver 4A bzw. 4B auszustatten. Dieser Suchserver 4A bzw. 4B kann bei einer Abfrage im Hintergrund weiterlaufen und sich beispielsweise nach einer bestimmten Inaktivzeit selbst terminieren. Dieser hat natürlich den großen Vorteil, dass es keine Rolle spielt, in welcher Sprache die Oberfläche verfasst ist und welche Nachteile die- se bietet.

Im Falle einer Suche kann dieser Suchserver 4A bzw. 4B im Hintergrund weiterarbeiten und Abfrageergebnisse aus dem Index 6A bzw. 6B suchen und laden. Wenn sich nun der Benutzer die erste Seite anzeigen lässt, sucht der Suchserver 4A bzw. 4B im Hintergrund (bis beispielsweise eine Maximalwert an Ergebnissen erreicht ist) weiter und sobald der Benutzer die nächste Seite der Ergebnisse aufruft, gibt dieser die jeweils nächsten Ergebnisse an die Präsentationsschicht PA aus. Dies passiert natürlich nur solange, bis der Maximalwert der Ergebnisse erreicht ist. Sollte ein einzelnes System oder mehrere Sys- teme nach einer bestimmten Mindestreaktionszeit nicht auf die entsprechende Anfrage reagieren, ist es vorteilhaft, wenn trotz der Tatsache, dass von diesem System möglicherweise nicht die vollständigen Abfrageergebnisse am abfragenden System vorhanden sind, die vorhandenen Ergebnisse weiterverarbeitet werden. In einem solchen Fall kann es zwar im schlimmsten Fall zu unvollständigen Anfrageergebnissen kommen, dennoch sollte gewährleistet sein, dass die vorhandenen Ergebnisse nicht verworfen werden und der Benutzer zumindest jene Ergebnisse dargestellt bekommt, welche zu bis zu diesem Zeitpunkt ge- funden wurden. Die Unvollständigkeit des Ergebnisses kann dem Benutzer beispielsweise durch eine entsprechende Meldung kenntlich gemacht werden.

Durch die bevorzugte Verwendung von HTTPS ergibt sich ein weiterer Vorteil, welcher sich in der Verwendung von„Keep-Alive" manifestiert. Dieser„Keep- Alive"-Mechanismus hält eine Verbindung eine gewisse Zeit lang am Leben. Wird in dieser Zeit eine neue Abfrage gestellt, kann die bereits offene Verbindung sofort verwendet werden, ohne zeitaufwendig eine neue Verbindung aufbauen zu müssen und einen neuen Sitzungsschlüssel aushandeln zu müssen oder entsprechende Zertifikate prüfen zu müssen. Durch diese Ausgestaltung ist es möglich, mithilfe des Suchservers 4B, diese Keep-Alive-Verbindungen mithilfe eines Hintergrundprozesses offen zu halten und zu verwalten. Dadurch ergibt sich, dass alle Anfragen 1 von einem System A an ein anderes System B oder C etc. in der untersten„Suchserverschicht" stattfinden. Da die Präsentationsschicht PA bzw. PB typischerweise mehrere Prozesse für die Anfragen verwendet, könnte das Prinzip des Keep - Alive dort nicht so ohne weiteres aufrechterhalten werden. Am Beispiel von PHP wird deutlich, dass dies nicht so ohne weiteres nutzbar wäre. Aus der Praxis ist bekannt, dass beispielsweise die gängige Skriptsprache PHP die entsprechenden Verbindungen nach jedem Request sofort zerstört. Hier wäre beispielsweise eine Keep-Alive nicht, oder nur bedingt realisierbar. Mithilfe des Suchservers 4A bzw. 4B, welcher diese Keep-Alive-Verbindungen offen hält, ist dies in der vorliegenden Erfindung möglich.

Im Detail wird also bei einer typischen Anfrage 1 von System A ausgehend in der Präsentationsschicht 1A von System A eine Anfrage 1 an den lokalen Suchserver 4A gestellt, welcher zuerst eine lokale Suche im lokalen Index 6A startet und zeitgleich beispielsweise eine HTTPS-Verbindung zum Beispiel zum System B aufbaut, und diese Anfrage 1 ebenfalls an System B sendet. Diese Anfrage 1 wird in System B in der Präsentationsschicht 1 B entgegengenommen und dort das Anmeldeprozedere des Benutzers von System A wie schon beschrieben überprüft. Ist diese Überprüfung abgeschlossen und der Benutzer berechtigt die Anfrage 1 zu stellen, wird der Anfragebefehl angenommen. Die Präsentationsschicht 1 B von System B baut nun eine interne Verbindung zum Suchserver 4B des eigenen Systems auf. Falls dieser Suchserver 4B zu diesem Zeitpunkt noch nicht ausgeführt ist, wird dieser natürlich vorher gestartet, da dieser sonst für die Präsentationsschicht 1 B nicht erreichbar wäre. Der Suchserver 4B des System B führt nun ausschließlich eine lokale Suche am System B durch und liefert die Ergebnisse, welche natürlich über die vorherige Berechtigungsprüfung zwischen den System A und dem System B schon authentifiziert sind. Natürlich wird eine entsprechende Abfrageeinschränkung aufgrund der jeweiligen Benutzerrechte des anfragenden Benutzers eingebunden und so bereitet die Präsentationsschicht 1 B des Systems B das Abfrageergebnis entsprechend der Rechtevergabe auf und sendet es an das System A zurück.

Die lokale Abfrage selbst wird in zwei Phasen bewerkstelligt. In der ersten Phase werden die invertierten Indices 6A bzw. 6B nach den jeweiligen Suchwörtern gescannt. Hierbei nutzen Suchwörter, die durch boolesche Algebra, wie beispielsweise„Wort_A UND Wort_B" verknüpft sind, beispielsweise zwei Zeiger in den invertierten Indices 6A bzw. 6B. Diese Zeiger lokalisieren die Wörter A und B. An diesen beiden Stellen sind nun sequenziell aufsteigend, die auf den Suchindex 6A bzw. 6B bezogenen Dokumentnummern aller Dokumente, die jeweils Wort A oder Wort B enthalten, hinterlegt. Die Suche selbst überspringt nun jeweils auf der gegenüberliegenden Liste soviele Dokumenten-IDs, bis beide Zeiger die gleichen Dokumente-ID aufweisen. Diese Dokumenten-ID wäre also nun eine, bei der beide Wörter, also A und B enthalten sind und somit für die Suche relevant.

Natürlich kann die Anzahl der Treffer aufgrund des Umfangs der jeweiligen Listen erheblich sein. Um dem Benutzer diesbezüglich mehr Komfort zu bieten, wird das jeweilige Ergebnis mit einem Score-Wert versehen, welcher ein ge- wichtetes Ergebnis in Form von eines Wertes ausgibt, welcher auf die Anzahl der relevanten Treffer schließen lässt. Das jeweilige System arbeitet diese Ergebnispaare (bestehend aus der Dokumenten-ID und dem jeweiligen Score- Wert) ab, um so die besten Treffer zu ermitteln. Die Anzahl dieser Ergebnisse kann sinnvollerweise entsprechend mit beispielsweise 5000 Ergebnispaaren limitiert werden; gleichzeitig wird die Anzahl der relevanten Ergebnisse gezählt, um zu eruieren, wieviele Treffer relevant sind und wieviele davon zu den besten 5000 zum Beispiel gehören.

In der zweiten Phase werden die Suchergebniseinträge aus dem Suchindex 6A bzw. 6B geladen. In diesem Suchergebniseintrag können beispielsweise Betreff, Absender, Empfänger einer E-Mail vermerkt sein. Selbstverständlich muss die Dokumenten-ID ebenfalls vermerkt sein, ohne die ein weiterer Zugriff natürlich nicht möglich wäre. Hier kommt wieder die schon beschriebene Zurückgabe der Ergebnisse zu tragen, welche beispielsweise die ersten 50 Ergebnisse zurückliefert und darstellt und im Hintergrund über den bereits beschriebenen Suchserver 4A bzw. 4B die ausstehenden Ergebnisse lädt bzw. diese dann entsprechend bei Bedarf darstellen kann, ohne dass eine neue Suche ausgeführt werden muss. Die entsprechende Sortierung erfolgt im RAM, da der Index 6A bzw. 6B dazu nicht in der Lage ist. Natürlich kann diese Abfrage nicht nur zwischen zwei Systeme (in diesem konkreten Fall System A und System B) erfolgen, sondern es können selbstverständlich mehrere System daran beteiligt werden. Diesbezüglich liefert jedes „mitangefragte" System seine Ergebnisse in z.B. Blöcken aus jeweils 50 Ergebnissen. Die Daten erscheinen alle hintereinander und sind jeweils durch Flushbefehle getrennt, um das Ende des jeweiligen Blocks zu markieren und die Übertragung der Daten durch z.B. das HTTPS- Protokoll unmittelbar und ohne Verzögerung auszulösen. Der Flushbefehl dient grundsätzlich dazu, den Datenfluss zu regulieren und den jeweiligen Suchpuffer zu leeren. Dadurch wird die bestehende Verbindung ideal genutzt und die Daten werden als quasi Push-Dienst bei Verfügbarkeit an das anfragende System A geliefert. Wie einfach nachvollziehbar, kann es während der zuvor beschriebenen Abfragefunktion zu massiven Problemen zwischen den verwendeten Dateiformaten und Dateistrukturen kommen. Um dieses Verfahren unabhängig von Programmiersprachen und Dateistrukturen und ähnlichem stabil betreiben zu können, macht es Sinn, wenn die Präsentationsschicht 1 B des jeweils lokalen Systems, beispielsweise System B, die Daten für die Präsentationsschicht 1A des anfragenden Systems, beispielsweise System A, stets in dessen typischen Präsentationsschichtdatenstrukturen und Konzepten, wie zum Beispiel bei PHP serialisiert kodiert übergibt. Der Suchserver 4A von System A kann diese Daten nicht verarbeiten, und gibt diese lediglich an die Präsentationsschicht 1A der abgefragten Systeme weiter. Diese bringen unter anderem die Daten in eine entsprechende Form und übergeben diese dem jeweiligen lokalen Suchserver 4A bzw. 4B. Die zurückgelie- ferten Daten werden durch die jeweilige Präsentationsschicht 1 B wieder entsprechend ausgewertet und an das abfragende System A übermittelt. Dies kann aber auch je nach Anfragetyp mittels eines HTML - Codes abgearbeitet werden, welcher in der Präsentationsschicht 1 B von System B generiert wird und durch das Suchserver - Protokoll 4A des Systems A und dessen Präsenta- tionsschicht 1A weitergeleitet wird und dem Benutzer entsprechend ausgegeben werden kann.

In den Suchergebnisdarstellungen können natürlich mehrere Tools für die Weiterverarbeitung integriert werden. Es macht also Sinn, in der jeweiligen Oberflä- che nicht nur Icons zum Anfordern der markierten Daten zu integrieren, sondern auch beispielsweise Download-Icons für den Download eines Attachments, wenn das Suchergebnis beispielsweise ein mittels OCR Software verarbeitetes PDF Attachment betrifft. Ebenfalls sollten weitere Aktionen für die gefundenen und markierten E - Mails oder Dokumente vorgesehen sein, wie beispielsweise Löschen, Wiederherstellen, Weiterleiten, Listenexport als CSV-Datei, EML- Massenexport oder Export als passwortgeschützte ZIP-Datei. Die Integration eines Viewers, welcher beispielsweise mittels Popup integriert oder als Browserfenster angezeigt werden kann, spielt in der Weiterverarbeitung der Daten, welche mithilfe des erfindungsgemäßen Verfahrens gefunden wurden, eine maßgebliche Rolle. Mit der Integration einer solchen Oberfläche, ist es möglich, die Ergebnisse wieder weiterzuverarbeiten. In einer möglichen Ausgestaltungsform ist vorteilhaft eine Druckansicht integriert oder ein Viewer, der beispielsweise bei E-Mails den Header, die Liste der Attachments und den Body darstellt. Bei HTML-Mails kann natürlich auch der jeweilige HTML-Text angezeigt werden. Der Viewer kann ebenfalls über Buttons zum„Durchscrollen" der Ergebnisse verfügen bzw. jeweils zum ersten oder letzten Ergebnis navigieren. Auch eine Direktnavigation zu einem konkreten Ergebnis ist vorstellbar. Natürlich können die Funktionen, die hier implementiert werden, mannigfaltig erweitert und den jeweiligen Benutzern angepasst werden und sind nicht limitierend zu sehen.

Grundsätzlich wird bei dem erfindungsgemäßen Verfahren darauf geachtet, möglichst bandbreitendschonend zu arbeiten. Durch die Ausgabe der Anfrageergebnisse werden, wie schon beschrieben, nicht die kompletten relevanten Daten übertragen, sondern nur bestimmte, relevante Teile. Der Benutzer kann somit also eine Vorauswahl bzw. eine Auswahl der für ihn interessanten Anfrageergebnisse treffen. Mithilfe von bestimmten Tools kann der Benutzer nun also die Daten, die auf seine Suchabfrage passen, weiterverarbeiten. Durch die Menge der Daten ist es jedoch zu vermeiden, alle Suchergebnisse gleich direkt zum Benutzer zu übermitteln. Vielmehr macht es Sinn, den Benutzer über eine Vorschau eine Auswahl treffen zu lassen und erst dann, wenn der Benutzer die Daten auch wirklich benötigt und dieses dezidiert in Auftrag gibt, die Daten über den gleichen Weg, welcher bei der Anfrage 1 beschritten wurde, an den jeweiligen Benutzer zu übermitteln. Dies hat den immensen Vorteil, dass die Bandbreite geschont und optimal ausgenutzt werden kann, da nur jene Daten über- tragen werden, die auch relevant sind. Ein sinnloser Datentransfer wird hierdurch vermieden und die Ressourcen werden optimal genutzt. Eine solche vom Benutzer getätigte Voransicht gibt dem Benutzer überdies auch die Möglichkeit, darüber zu entscheiden, ob das Suchergebnis für ihn relevant ist oder nicht. Falls dies der Fall sein sollte, kann der Benutzer durch das erfindungsgemäße Verfahren die jeweils relevanten Suchergebnisse mithilfe einer Möglichkeit der Wiederherstellung in z.B. seinen Posteingang senden. Da nun natürlich auch der Export von Ergebnissen auf der grundsätzlichen Idee des erfindungsgemäßen Verfahrens beruht, gibt es ebenfalls die Möglichkeit, relevante Suchergebnisse zu exportieren. Da es sich bei den Ergebnissen nicht immer um nur ein einziges Ergebnis handeln muss, sondern es ebenso denkbar ist, dass es sich bei den relevanten Ergebnissen um eine größere Anzahl an relevanten Daten handelt, wäre es nicht zweckführend, wenn der Benutzer jedes Einzelergebnis manuell abspeichern müsste. Vielmehr macht es Sinn, sich zum Wiederherstellen bzw. Exportieren der Ergebnisse beispielsweise mithilfe eines ZIP Exportes zu bedienen. Bei einem ZIP - Export wird die vorhandele ZIP - Bibliothek angepasst. Der grundsätzliche Aufbau einer ZIP-Datei, welche hier sehr gut zum Weiterverarbeiten der Ergebnisse verwendet werden kann, besteht pro Datei aus einem Header und Trailer mit Dateinamen, einem Kompressionsverfahren und einer CRC-Prüfsumme. Dies wird pro Datei aneinander gereiht und am Ende werden alle Header und Trailer noch einmal wiederholt um einen schnellen Zugriff zu gewährleisten und mit einem Central Directory, also einem zentralen Verzeichnis beendet, welches auf den Beginn der Liste verweist. Um bei einer Weiterverarbeitung hier auch ein ZIP Archiv erstellen zu können, muss natürlich aufgrund der grundsätzlichen Struktur, welche räumlich sehr weitläufig sein und mehrere Systeme beinhalten kann, der Header, der Inhalt und der Trailer immer mit dem Eintrag für das Ende der jeweiligen ZIP- Datei verknüpft werden. Bei dem anfragenden System, z.B. System A, müssen nun die verknüpften Teile entfernt und zwischengespeichert werden. Der Rest wird mit den lokal gezippten Daten und denen der mit durchsuchten Systemen verbunden und die jeweiligen Dateioffsets gespeichert. Die jeweiligen Ende der ZIP-Datei werden in der gleichen Reihenfolge in einer temporären Datei oder im RAM zwischengespeichert und die jeweiligen enthaltenen Offsets auf den Inhalt angepasst. Wenn nun das Suchergebnis abgeschlossen ist und alle relevanten Daten der Abfrage vom Benutzer ausgewählt wurden, wird noch das Verzeichnis, welches beispielsweise in einer temporären Datei gespeichert wird, ange- hängt. Wie schon ausgeführt, wird auch hier der relevante, vom Benutzer ausgewählte und zusammengeführte Teil direkt an den Benutzer, bzw. an das System, welches der Benutzer verwendet, übermittelt. Dadurch wird, wie zuvor beim Wiederherstellen die Rechnerleistung und die Bandbreite sehr effizient ausgenutzt und dem Benutzer wird eine möglichst komfortable Lösung des Problems des sicheren Suchens, Findens, Wiedergebens, Wiederherstellens und/oder Exportierens angeboten.

Es ist nun also mit dem erfindungsgemäßen Verfahren erstmals möglich, einen Verbund von Systemen, welche für sich eigenständig arbeiten und funktionsumfangsgleich sind, in einem Verbund zusammengeschlossen sind, jedoch ohne zentrale Organisationsstrukturen wie beispielsweise einem Server oder ähnlichem, von jedem Einzelsystem aus, eine Anfrage 1 zum sicheren und verschlüsseltem Suchen, Finden, Wiedergeben, Wiederherstellen und/oder Expor- tieren von elektronischen Daten an alle anderen Systeme einzuleiten. Durch die Ausgestaltung des Verfahrens können die jeweiligen Einzelsysteme jederzeit unter gleichzeitiger Stabilität der lokalen Stetigkeit ausgetauscht, erweitert oder aus dem Verbund herausgenommen werden. Dies bringt natürlich erhebliche Vorteile in Hinblick auf Wartung und Service des Systemverbunds. Es ist mit dem erfindungsgemäßen Verfahren nun erstmals möglich, das sichere Suchen, Finden, Wiedergeben, Wiederherstellen und/oder Exportieren von elektronischen Daten ohne Relevanz des Standortes, also standortunabhängig, zu gewährleisten und überdies jegliche Bandbreite nur auf das Nötigste zu belasten und überflüssigen Datenaustausch zu minimieren. Bezugszeichenliste:

A System A

DA Datenzug ffsschicht System A

1 A / PA Präsentationsschicht System A

2 A Sonstige Komponenten System A; bspw. Archivierung

3 A Datenbank System A

4 A Suchserver System A

5 A Indizierung System A

6 A Index System A

B System B

DB Datenzugriffsschicht System B

1 B / PB Präsentationsschicht System B

2 B Sonstige Komponenten System B; bspw. Archivierung

3 B Datenbank System B

4 B Suchserver System B

5 B Indizierung System B

6 B Index System B

(1 ) Anfrage von System A auf System B

(2) Antwort von System B auf System A