DE10244622A1

DE10244622A1 - Speicherung und Wiederverwendung von Drittparteidokumenten

Info

Publication number: DE10244622A1
Application number: DE10244622A
Authority: DE
Inventors: Manoel Tenorio
Original assignee: I2 Technologies Inc
Current assignee: I2 Technologies Inc
Priority date: 2001-09-27
Filing date: 2002-09-25
Publication date: 2003-05-08
Also published as: US7149744B1

Abstract

Ein elektronisches Handelssystem (10) für die Wiederverwendung von Drittparteidokumenten, bestehend aus einem oder mehreren Dokumentenspeichern (32, 35), in dem oder in denen eine Vielzahl von Geschäftsdokumenten gespeichert ist. Das System beinhaltet weiterhin ein globales Inhaltsverzeichnis (42), das eine Vielzahl von hierarchisch organisierten Produkt- und Dokumentklassen enthält, wobei in jede Klasse eine Reihe von Geschäftsdokumenten eingeordnet ist und jede Klasse mit einem oder mehreren Attributen des in der jeweiligen Klasse eingeordneten Dokuments assoziiert ist. Mindestens eine der Klassen besitzt einen oder mehrere assoziierte Zeiger, die die Dokumentenspeicher zu erkennen geben. Das System umfasst außerdem eine Suchschnittstelle (45) für das Durchsuchen der Dokumentenspeicher nach den Geschäftsdokumenten. Ein Intelligenzmodul (47) zerlegt die Geschäftsdokumente in ein oder mehrere Abschnitte und erstellt auf diese Weise generische Dokumente aus den Geschäftsdokumenten, um Käufern (20) die Möglichkeit zur Wiederverwendung der Geschäftsdokumente zu geben und dabei die in den Geschäftsdokumenten enthaltenen vertraulichen Angaben zu schützen.

Description

Diese Erfindung bezieht sich auf den elektronischen Handel und insbesondere die Speicherung und Wiederverwendung von Drittparteidokumenten.
Mit der stetig steigenden Beliebtheit des Internets und den immer besseren Zugangsmöglichkeiten zu diesem Kommunikationsmedium erhöht sich auch die Anzahl der über das Internet abgewickelten Geschäftsvorgänge und die Zahl der Käufer und Verkäufer, die elektronische Marktplätze als Forum für solche Geschäftsvorgänge in Anspruch nehmen. Bei der Mehrzahl der Geschäftsvorgänge im elektronischen Handel ("E- Commerce") stellt ein Käufer einen Bedarf für ein Produkt fest, ermittelt danach einen Verkäufer, der das betreffende Produkt anbietet, und führt schließlich einen Zugriff auf die Website des Verkäufers durch, um den Kauf des Produkts zu vereinbaren. Außerdem müssen Käufer und Verkäufer mehrere Dokumente benutzen, z. B. eine Aufforderung zur Abgabe eines Angebots oder ein Bestellformular, um den E-Commerce-Geschäftsvorgang abzuwickeln. Hat der Käufer keinen bevorzugten Verkäufer oder handelt es sich um einen Erstkauf des Produkts durch den Käufer, wird der Käufer häufig eine Suche durchführen, um eine Reihe von Verkäufern als Anbieter des betreffenden Produkts zu ermitteln. Anschließend wird er Zugriff auf die Websites zahlreicher Verkäufer nehmen um festzustellen, welcher Verkäufer das Produkt mit bestimmten gewünschten Produkteigenschaften zum günstigsten Preis oder zu den günstigsten Bedingungen für den Käufer anbietet, und danach einen Verkäufer auswählen und zahlreiche unvollständige Dokumente benutzen, um den E-Commerce-Geschäftsvorgang abzuwickeln. Diese Phase des Zusammenbringens von Käufer und Verkäufer (des Käufers und eines bestimmten Verkäufers) und auch das Benutzen der Dokumente sind häufig ineffiziente Prozesse. Die Phase des Zusammenbringens gestaltet sich deswegen ineffizient, weil zum Finden des Produkts eine umfangreiche Suche erforderlich ist und, sobald ein bestimmtes Produkt gefunden ist, es schwierig sein kann, die verschiedenen betreffenden Produktangebote der verschiedenen Verkäufer zu vergleichen. Die Dokumentbenutzungsphase gestaltet sich häufig ineffizient, da der Käufer im allgemeinen bei den meisten E-Commerce- Geschäftsvorgängen von einem unvollständigen Dokument oder gar keinem Dokument ausgehend ein Dokument erstellen oder sämtliche Angaben in ein unvollständiges Dokument eintragen muss, obwohl diese Angaben zum Teil in den verschiedenen Dokumenten verschiedener Verkäufer und verschiedener Produkte nahezu oder vollständig identisch ist.
Mit der vorliegenden Erfindung werden die Nachteile und Probleme früherer E- Commerce-Techniken deutlich verringert oder ganz vermieden.
In einer erfindungsgemäßen Ausführungsform besteht ein elektronisches Handelssystem aus einem oder mehreren Dokumentenspeichern, in denen eine Vielzahl von Geschäftsdokumenten gespeichert ist. Das System umfasst weiterhin ein globales Inhaltsverzeichnis, das eine Vielzahl von hierarchisch organisierten Klassen enthält. Bei den Klassen handelt es sich sowohl um Produktklassen, als auch um Dokumentklassen. In jede solche Klasse wird eine Anzahl von Geschäftsdokumenten eingeordnet und jede Klasse ist mit einem oder mehreren Attributen der in eingeordneten Geschäftsdokumente assoziiert. Mindestens eine der Klassen besitzt einen oder mehrere assoziierte Zeiger zur Angabe der Dokumentenspeicherspeicher. Das System umfasst weiterhin ein Intelligenzmodul, mit dem die Geschäftsdokumente in ein oder mehrere Abschnitte zerlegt werden, um daraus ein oder mehrere generische Dokumente zu erstellen. Und außerdem gehört zu dem System eine Suchschnittstelle für die Übermittlung eines Suchanfrage für die Geschäftsdokumente an den einen oder die mehreren Dokumentenspeicher.
Besondere erfindungsgemäße Ausführungsformen können einen oder mehrere technische Vorteile bieten. Beispielsweise bieten gewisse erfindungsgemäße Ausführungsformen ein Intelligenzmodul, das aus den Drittparteidokumenten generische Dokumente erstellt, die anschließend von anderen Käufern benutzt werden können. Das Intelligenzmodul entfernt die vertraulichen oder Wettbewerbs-relevanten Angaben in den Drittparteidokumenten, wie z. B. die Namen der beteiligten Parteien, die Kaufmenge und den Kaufpreis, ohne das Format des Dokuments zu verändern. Daher wird ein erstmalig im E-Commerce-System auftretender Käufer oder ein Erstkäufer eines bestimmten Produkts in die Lage versetzt, nach einem bestimmten generischen Dokument zu suchen, indem der Käufer nach dem Dokumenttyp sucht oder indem er nach Dokumenten sucht, die einen Bezug zu dem für den Käufer interessanten Produkt besitzen. Der Käufer kann zu diesem Zweck eines dieser generischen Dokumente benutzen, anstatt ein eigenes Dokument neu erstellen zu müssen. Der auf diese Weise beschleunigte Geschäftsvorgang fuhrt zu Einsparungen bei Zeit und Kosten, da der Käufer nicht mehr bei jedem Erstkauf und für jeden neuen Verkäufer und für jedes gesuchte Produkt ein neues Dokument erstellen muss.
Außerdem legen besondere erfindungsgemäße Ausführungsformen akzeptierbare Verhaltensweisen von Käufern und Verkäufer fest, sowohl in der Praxis als auch als System. In den Dokumenten werden die Anforderungen sowohl der Käufer als auch der Verkäufer berücksichtigt und daher wissen sowohl die Käufer als auch die Verkäufer besser Bescheid über die Erwartungen der jeweiligen anderen Partei in ihren Dokumenten.
Außerdem unterliegen die im E-Commerce-System verwendeten Dokumente im Lauf der Zeit einer zunehmenden Standardisierung oder Normierung, da die verwendeten Dokumente auf den generischen Dokumenten basieren. Einhergehend mit der zunehmenden Normierung der Dokumente gestalten sich die Geschäftsvorgänge zunehmend rationalisierter, da zwischen den Käufern und den Verkäufern ein geringerer Verhandlungsaufwand besteht. Weitere fachliche Vorzüge sind für den Fachmann anhand der folgenden Figuren, der Beschreibung und der Ansprüche leicht ersichtlich.
Zur besseren Erläuterung der vorliegenden Erfindung und ihrer Merkmale und Vorteile wird Bezug genommen auf die folgende Beschreibung in Verbindung mit den Begleitzeichnungen, wobei die:
Fig. 1 ein beispielhaftes elektronisches Handelssystem erläutert,
FigurN 2A und 2B eine beispielhafte Verzeichnisstruktur eines beispielhaften globalen Inhaltsverzeichnisses für Produktklassen erläutert,
Fig. 3 eine beispielhafte Verzeichnisstruktur eines beispielhaften globalen Inhaltsverzeichnisses für Dokumentklassen erläutert,
Fig. 4 eine Beispieltabelle einer Verkäuferdatenbank erläutert,
Fig. 5 ein beispielhaftes elektronisches Handelssystem in weiteren Einzelheiten erläutert, und
Fig. 6A und 6B eine beispielhaftes Verfahren für die Speicherung, Einordnung und Wiederverwendung von Dokumenten erläutert.
In Fig. 1 wird ein beispielhaftes System 10 erläutert, das aus einem Netzwerk 12 besteht, das Käufer 20, Verkäufer 30 und ein globales Inhaltsverzeichnis (global content directory, GCD-Verzeichnis)-Server 40 miteinander verbindet. Das System 10 ermöglicht Geschäftsvorgänge im elektronischen Handel ("E-Commerce") zwischen Käufern 20 und Verkäufern 30 durch die Verwendung eines GCD-Verzeichnisses 42 mit Hilfe des GCD- Servers 40. Das GCD-Verzeichnis 42 kann sich im GCD-Server 40 oder außerhalb befinden. Das Netzwerk 12 kann jede geeignete Kombination von öffentlichen und/oder privaten Netzwerken umfassen, mit denen Käufer 20, Verkäufer 30 und GCD-Server 40 verbunden werden können. In einer beispielhaften Ausiihrungsform umfasst Netzwerk 12 das Internet und alle geeigneten Local Area Networks (LANs), Metropolitan Area Networks (MANs) oder Wide Area Networks (WANs), mit denen Käufer 20, Verkäufer 30 und GCD-Server 40 mit dem Internet verbunden werden können. Durch die Zugänglichkeit des Internets für die überwältigende Mehrheit der Käufer und Verkäufer weltweit bezieht sich die vorliegenden Erfindung potenziell auf all diese Käufer und Verkäufer als Käufer 20 und Verkäufer 30 in Verbindung mit dem System 10. Die Verwendung des Begriffs "global" unterliegt dabei keiner geografischen Einschränkung in dem Sinne, dass es notwendig wäre, dass das GCD-Verzeichnis 42 seine Verzeichnisdienstleistungen Käufern 20 und Verkäufern 30 in der ganzen Welt (oder jeder beliebigen anderen bestimmten Region) anbietet oder dass der Inhalt des GCD-Verzeichnisses 42 aus der gesamten Welt (oder jeder beliebigen anderen bestimmten Region) stammt.
Obwohl die Käufer 20 und die Verkäufer 30 als separate Subjekte beschrieben werden, kann ein bei einem Geschäftsvorgang als Käufer 20 auftretendes Subjekt bei einem anderen Geschäftsanschluss durchaus als Verkäufer 30 auftreten und umgekehrt. Außerdem kann mit der Bezugnahme auf einen "Käufer" oder einen "Verkäufer" je nach den vorliegenden Umständen sowohl eine Person, als auch ein Computersystem, eine Organisation oder ein sonstiges Subjekt gemeint sein. Beispielsweise kann mit dem Käufer 20 ein Computer gemeint sein, der darauf programmiert wurde, einen Produktbedarf autonom festzustellen, nach dem betreffenden Produkt zu suchen und das Produkt bei Ermittlung eines geeigneten Verkäufers zu erwerben. Zwar werden hierin vorwiegend Vorgänge des Kaufens und Verkaufens beschrieben, doch bezieht sich die vorliegende Erfindung auf alle Vorgänge des E-Commerce. Und außerdem sind mit der Bezugnahme auf "Produkte" sowohl Güter, als auch Immobilien, Dienstleistungen, Informationen oder alle sonstigen materiellen und immateriellen Dinge gemeint.
Ein typischer Geschäftsvorgang im E-Commerce kann aus einer Phase des Zusammenbringen von Käufer und Verkäufer ("Matching Phase") und einer "Abwicklungs"-Phase bestehen. In der Phase des Zusammenbringens kann ein Käufer 20 nach einem geeigneten Produkt (damit sind beliebige Güter, Immobilien, Dienstleistungen, Informationen oder alle sonstigen materiellen und immateriellen Dinge gemeint, die zum Subjekt eines Geschäftsvorgangs im E-Commerce werden können) im Angebot eines oder mehrerer Verkäufer 30 suchen, den geeignetesten Verkäufer 30 ermitteln (was beispielsweise aus der Ermittlung des Verkäufers 30 mit dem günstigsten Preis bestehen kann) und Kontakt mit dem betreffenden Verkäufer 30 aufnehmen, um in die Abwicklungsphase einzutreten. In der Abwicklungsphase können der Käufer 20 und der Verkäufer 30 Verhandlungen über einen Kaufvertrag für das betreffende Produkt aufnehmen (was beispielsweise eine genauere Definition des Kaufgegenstands, Preisverhandlungen und Vereinbarungen zur Lieferlogistik beinhalten kann) und ein Rechtsdokument erstellen, in dem die ausgehandelten Vertragsbedingungen festgehalten sind. Zur Ermittlung des geeignetesten Verkäufer 30 in der Phase des Zusammenbringens von Käufer und Verkäufer ohne Zuhilfenahme des GCD-Verzeichnisses 42 könnte ein Käufer 20 auf zahlreiche Verkäufer-Websites Zugriff nehmen müssen, um feststellen zu können, welcher Verkäufer 30 das Produkt mit bestimmten gewünschten Produktmerkmalen zum besten Preis anbietet. Die Verkäufer 30 könnten jeweils eine oder mehrere Datenbanken 32, z. B. relationale Datenbanken, mit Daten über das Produktangebot des Verkäufer 30 und die zugehörigen Produktmerkmale verfügbar machen. Der Zugriff auf die Datenbanken 32 könnte über die Website des betreffenden Verkäufers oder auf jede beliebige andere geeignete Weise erfolgen. Die bei diesem Verfahren erforderlichen mehrfachen "1-zu-1-Suchen" (ein Käufer 20 und ein Verkäufer 30) machen diesen Prozess ineffizient und kostspielig, was auf den großen Suchaufwand zum Finden eines Produkts und die Tatsache zurückzuführen ist, dass die verschiedenen betreffenden Produktangebote der verschiedenen Verkäufer 30 möglicherweise nicht leicht zu vergleichen sind.
Als Alternative könnten mehrere Verkäufer 30 je nach Produktangebot in einem elektronischen Marktplatz zusammengefasst sein und ein Käufer 20 könnte die Angebote dieser mehreren Verkäufer 30 an einer einzelnen Website durchsuchen. Wünscht der Käufer 20 jedoch den Kauf von mehreren verschiedenen Produkttypen, muss Käufer 20 möglicherweise verschiedene Marktplätze besuchen. Außerdem könnten es zahlreiche konkurrierende Marktplätze geben, die der Käufer 20 in der Phase des Zusammenbringens von Käufer und Verkäufer bei einem Geschäftsvorgang für ein bestimmtes Produkt durchsuchen müsste. Bei einem potenziellen Verfahren zur Lösung dieses Problems wird eine globale Produktdatenbank erzeugt, die potenziell die Daten über die Merkmale aller Produkte enthält, die ein Käufer möglicherweise erwerben möchte. Diese globale Datenbank würde daher die gesamten Inhalte aller Datenbanken 32 aller Verkäufer 30 enthalten. Allerdings wäre eine solche globale Datenbank mit vielen Problemen verbunden. Beispielsweise wäre eine solche Datenbank schon aufgrund ihrer enormen Größe nur schwer zu durchsuchen und es würden daher Performanceprobleme auftreten. Außerdem wäre es schwierig, einer großen Anzahl von Käufern 20 gleichzeitig das Durchsuchen der Datenbank zu ermöglichen. Außerdem müssten alle Verkäufer 30 zur Aktualisierung ihrer Angaben Zugriff auf die globale Datenbank nehmen und die gesamte Datenbank müsste bei jeder Änderung einer Gesamtaktualisierung unterzogen werden. Darüber hinaus könnte eine Vielzahl von anderen Problemen bestehen.
Wie bereits erwähnt, besteht die Abwicklungsphase aus der Erstellung und der Benutzung eines oder mehrerer Dokumente durch den Käufer 20 und den Verkäufer 30. Bei der Erstellung und Benutzung von Dokumenten in der Abwicklungsphase ohne eine Zuhilfenahme des GCD-Verzeichnisses 42 muss der Käufer 20 möglicherweise bei Beginn eines jeden neuen Geschäftsvorgangs mit dem Verkäufer 30 neue Dokumente erstellen und anschließend die rechtlichen und geschäftlichen Einzelheiten mit dem Verkäufer 30 neu aushandeln, obwohl Käufer 20 und Verkäufer 30 bereits zuvor miteinander gehandelt haben, weil keine Unterlagen über diese früheren Geschäftsvorgänge gespeichert wurden, außer wenn Käufer 20 oder Verkäufer 30 solche Unterlagen speichern. Die Erstellung von Dokumenten und die Verhandlungen erhöhen den mit jedem Geschäftsvorgang verbunden Kosten- und Zeitaufwand. Falls der Käufer 20 außerdem Unterlagen über seine früheren Käufe bei früheren Geschäftsvorgängen mit mehreren Verkäufer 30 haben möchte, muss Käufer 20 die eigenen Unterlagen in einer Käuferdatenbank oder an einer anderen dem Käufer 20 zugänglichen Stelle speichern. In verstärktem Masse tritt dieses Problem auf, wenn Käufer 20 mit einem Verkäufer 30 zusammen kommt, mit dem Käufer 20 noch nie zuvor gehandelt hat, denn unter diesen Umständen besteht keine gemeinsame Ausgangsbasis zwischen den beiden Parteien und im allgemeinen werden die Dokumente neu erstellt werden müssen. Aber auch wenn der Käufer 20 bereits zahlreiche Geschäftsvorgänge mit einem bestimmten Verkäufer 30 durchgeführt hat, kann sich die Dokumentenerstellung ineffizient gestalten. Und auch wenn ein Käufer 20, der das System 10 bisher nicht benutzt hat, erstmals das System 10 nutzen möchte, gestaltet sich der Geschäftsvorgang mit Verkäufer 30 langwierig und aufwändig, da der Käufer 20 sämtliche benötigten Dokumente neu erstellen muss oder genötigt ist, die Dokumente des Verkäufers 30 zu verwenden. Manche Verkäufer 30 versuchen ihre Unterlagen über Geschäftsvorgänge zu speichern, indem sie Dokumente in einer oder mehreren Verkäuferdatenbanken 32 ablegen. Die in Verkäuferdatenbanken 32 gespeicherten Dokumente sind typischerweise aber nur dem Verkäufer 30 zugänglich, dem diese Dokumente gehören, und stehen Käufern 20 und anderen Verkäufern 30 im allgemeinen nicht zur Verfügung.
Das GCD-Verzeichnis 42 bietet eine Lösung zumindest für einen Teil der oben genannten Probleme. Das GCD-Verzeichnis 42 ist ein universelles Verzeichnis der Inhalte mehrerer Verkäuferdatenbanken 32 (und potenziell aller Verkäuferdatenbanken 32) und bietet einen Weg, diese Dokumente den Käufern 20 und anderen Verkäufern 30 zugänglich zu machen. Das GCD-Verzeichnis 42 kann mit einem oder mehreren Servern 40 oder anderen Computern, die sich an einem oder mehreren Standorten befinden, verwirklicht werden. Der Großteil oder der gesamte Inhalt dieser Verkäuferdatenbanken 32 bleibt dabei in den Datenbanken 32 gespeichert, doch wird ihr Inhalt mit Hilfe des GCD-Verzeichnisses 42 zugänglich gemacht. Daher bietet das GCD-Verzeichnis 42 wie die oben beschriebene globale Datenbank Käufern 20 einen Zugang zu Produktdaten mit einem Bezug zu einer Vielzahl von Produkten (und potenziell zu den Verkäuferdaten eines oder mehrerer Verkäufer 30 der betreffenden Produkte) und zu den bei früheren Geschäftsvorgängen zwischen den Käufern 20 und Verkäufern 30 benutzten Dokumenten. Im Gegensatz zur globalen Datenbank wird bei GCD-Verzeichnis 42 kein Versuch unternommen, all diese Daten und all diese Dokumente in einer enorm großen Datenbank zu speichern. Bei der Bezugnahme auf den Begriff "Daten" sind je nach Kontext sowohl Produktdaten (im Sinne von Informationen über Werte für bestimmte Produktattribute), Verkäuferdaten (im Sinne von Informationen über Werte für bestimmte Verkäuferattribute) oder Produkt- und Verkäuferdaten gemeint. Bei der Bezugnahme auf den Begriff "Dokumente" sind je nach Kontext Dokumente gemeint, die ein Käufer 20 für einen Geschäftsvorgang erstellt oder benutzt hat, und/oder Dokumente, die ein Verkäufer 30 für einen Geschäftsvorgang erstellt oder benutzt hat.
Das GCD-Verzeichnis 42 bietet ein Verzeichnis der Produkte und Dokumente und besitzt eine Verzeichnisstruktur, bei der die Produkte und/oder Dokumente mit Hilfe eines hierarchischen Klassifikationssystems (Einordnungssystems) organisiert sind. Durch Navigieren oder Suchen im Verzeichnis kann ein Käufer 20 eine bestimmte Produktklasse finden, in der Produkte eingeordnet sind, oder eine bestimmte Produktklasse, in der Dokumente eingeordnet sind, oder eine bestimmte Dokumentenklasse, in der Dokumente eingeordnet sind. Die mit einem in einer Produktklasse enthaltenen Produkt verbundenen Produktdaten (und potenziell die Verkäuferdaten) können in einer Verkäuferdatenbank 32 gespeichert sein und vom GCD-Verzeichnis 42 von dort abgerufen werden. Die mit einem in einer Produktklasse enthaltenen Produkt verbundenen Dokumente und die Dokumente in einer Dokumentklasse können ebenfalls in einer Verkäuferdatenbank 32 gespeichert sein und vom GCD-Verzeichnis 42 von dort abgerufen werden. Die angefragten Daten oder Dokumente können dem Käufer 20 aber auf eine transparente Weise dargeboten werden, so dass Käufer 20 den Eindruck bekommt, alle Produktdaten und Dokumente seien im GCD- Verzeichnis 42 selbst enthalten. Zwar wird hierin hauptsächlich eine Speicherung der Produktdaten, Verkäuferdaten und Dokumente in Verkäuferdatenbanken 32 beschrieben, doch wird bei der vorliegenden Erfindung auch eine Speicherung der Produktdaten, Verkäuferdaten und Dokumente auf eine andere geeignete Weise und der Abruf von jeder beliebigen geeigneten Quelle berücksichtigt. Beispielsweise könnte das System 10 einen gemeinsamen Datenenspeicher 34 umfassen, das Produkt- und/oder Verkäuferdaten enthält, die mit Daten aus einer oder mehreren Verkäuferdatenbanken 32 kombiniert werden können und die Dokumente enthalten, die Dokumente aus einer oder mehreren Verkäuferdatenbanken 32 ergänzen können, worauf an späterer Stelle ausführlicher eingegangen wird.
In Fig. 2 wird eine beispielhafte Verzeichnisstruktur 44 eines beispielhaften GCD- Verzeichnisses 42 für Produktklassen erläutert. Die im GCD-Verzeichnis 42 eingeordneten Produkte und Dokumente können nach Schemata organisiert sein. Ein solches Schema kann einen Satz von hierarchisch organisierten Produktklassen enthalten (dies kann als eine "Taxonomie" bezeichnet werden). Jede Klasse kann mit einem Satz an Produktmerkmalen, -eigenschaften oder sonstigen Produktattributen (die als "Produktontologie" bezeichnet werden können) und/oder einem Satz an Dokumentmerkmalen, -eigenschaften oder sonstigen Dokumentattributen (einer "Dokumentontologie") für jeden Produkttyp assoziiert sein. Beispielsweise können sich Stifte in ihrer Spitze (Kugel- oder Filzschreiber), ihrer Spitzengröße (fein, mittel oder breit) und ihrer Tintefarbe (wie z. B. blau, schwarz oder rot) unterscheiden. Außerdem könnten mit Filzstiften andere Dokumente verbunden sein als mit Kugelschreibern. Folglich könnte ein solches Schema eine Klasse für Stifte mit einer bestimmten Produktontologie einschließlich Spitzentyp, Spitzengröße und Farbe sowie andere geeignete Attribute sowie Dokumente für Stifte und bestimmte Stifttypen enthalten. Innerhalb einer bestimmten Klasse könnten die Produkte über ihre Produktattributwerte (wie z. B. Kugelschreiber, mittelfeine Spitze, blaue Farbe) definiert sein. Bei der Bezugnahme auf den Begriff "Wert" sind auch alle geeigneten Daten eingeschlossen, die ein (einzelnes) Produkt- oder Verkäuferattribut wiedergeben. Bei den Produktattributwerten und den Verkäuferattributwerten kann es sich um Zahlen, Buchstaben, Bilder, Schriftzeichen, Symbole oder eine sonstige geeignete Information zur Beschreibung eines Produkts oder Verkäufers handeln. Bei einer Ausführungsform kann die Produktontologie zusätzlich in Eingabe-erfordernde Attribute (d. h. Attribute, bei denen ein Wert vorgegeben werden muss) und Eingabeoptionale Attribute (d. h. Attribute, bei denen ein Wert optional ist) unterteilt sein und diese Kategorien können weiter unterschieden werden in Handelsmerkmale und Konstruktionsmerkmale (oder jede beliebige sonstige Unterteilung).
Zusätzlich zu einer Taxonomie und der Produkt- und Dokumentontologie kann ein Schema einen Satz von Attributen für jeden Verkäufer enthalten (dies könnte als eine "Verkäuferontologie" bezeichnet werden). Bei diesen Attributen kann es sich um geografische Einschränkungen (z. B. bediente Märkte), von den einzelnen Verkäufern akzeptierte Währungen, von den einzelnen Verkäufern akzeptierte Werkzeuge für die Zusammenarbeit, von den einzelnen Verkäufern akzeptierte Vertragsbedingungen, von den einzelnen Verkäufern akzeptierte Vertragsarten, von den einzelnen Verkäufern verlangte Kreditwürdigkeit des Kunden sowie sämtliche sonstigen geeigneten Verkäuferattribute handeln. Ähnlich wie die Produkte innerhalb einer Produktklasse können auch die Verkäufer, die Produkte in einer Produktklasse anbieten, anhand von Verkäuferattributwerten definiert werden, die den Verkäuferattributen entsprechen. Folglich kann ein Schema einen Satz von Klassen enthalten, die ihrerseits ein oder mehrere Produkte enthalten, und jede Klasse kann mit einem Satz von Produktattributen und einem Satz von Verkäuferattributen assoziiert sein.
In der beispielhaften Verzeichnisstruktur 44 können die Produkte gemäß branchenüblicher Standardschemata 46 oder einem anderen geeigneten Schema organisiert und katalogisiert sein, wie nachfolgend beschrieben wird. Im branchenüblichen Standardschema 46 gibt es zwei beispielhafte Klassen: eine direkte Materialklasse 48 und eine indirekte Materialklasse 50. Die Klassen 48 und 50 enthalten jeweils mehrere Unterklassen (die wiederum Unterklassen enthalten können). Folglich bilden die zahlreichen Klassen der Verzeichnisstruktur 44 eine "baumartig verzweigte" hierarchische Struktur für die Klassifikation (Einordnung) von Produkten und Dokumenten. Beispielhaft sind in Fig. 2 gewisse Teile der Verzeichnisstruktur 44 "vergrößert" dargestellt, um die verschiedenen Klassenebenen zu zeigen. Die "Ebene" einer Klasse ergibt sich aus der Anzahl von anderen Klassen zwischen der betreffenden Klasse und einer Grundklasse (wie z. B. der branchenüblichen Standardschemaklasse 46). Zum Beispiel befindet sich die indirekte Materialklasse 50 auf derselben Ebene in der Verzeichnisstruktur wie die direkte Materialklasse 48. Die indirekte Materialklasse 50 kann eine Büro- und Computerbedarfklasse 52 enthalten, die eine Schreibtischbedarfklasse 54 enthält, die eine Schreibwerkzeugklasse 56 enthält. Weiterhin kann die Schreibwerkzeugklasse 56 eine Stiftklasse 58 enthalten, die verschiedene Stifttypklassen 60a-60n enthält (wobei "n" bedeutet dass eine beliebige Anzahl von Klassen 60 in der Stiftklasse 58 enthalten sein kann), eine Stiftdokumentklasse 59 für alle Stifte und eine Stifttypdokumentklasse 63a-63n für die einzelnen Stifttypklassen 60a-60n. Die Klassen 50, 52, 54, 56, 58 und 60 befinden sich jeweils auf einer anderen Ebene der Verzeichnisstruktur 44. Auf allen Ebenen der Verzeichnisstruktur 44 kann eine Klasse eine oder mehrere Unterklassen enthalten, diese Unterklassen können ihrerseits wieder eine oder mehrere Unterklassen enthalten und so weiter, bis die Klassifizierung eine gewünschte Spezifität erreicht hat. Eine Reihe von Klassen - von der Klasse auf der höchsten Ebene (der allgemeinsten Klasse) bis zur Klasse auf der untersten Ebene (der spezifischsten Klasse) kann als ein "Zweig" der Verzeichnisstruktur 44 bezeichnet werden. So bilden beispielsweise die Klassen 46, 48, 50, 52, 54, 56, 58, 60b und 63b einen Zweig der Verzeichnisstruktur 44.
Obwohl die beispielhafte Verzeichnisstruktur 44, wie oben beschrieben, branchenübliche Standardschemata 46 verwenden kann, können auch beliebige andere geeignete Schemata 62 zusätzlich zu den oder an Stelle der branchenüblichen Standardschemata 46 verwendet werden. Beispielsweise könnten anstatt der aus der Sicht des Verkäufers organisierten branchenüblichen Standardschemata 46 andere Schemata 62 zum Einsatz kommen, bei denen die Produkte aus der Sicht des Käufers organisiert sind. Beispielsweise könnte ein Käufer 20 für einen Neubau den Kauf einer Küche mit verschiedenen Küchengeräten, Fensterbehandlungen, Anstrichmaterialien, Küchenschränken, Klempnerarbeiten, Geschirr und Kochwerkzeugen beabsichtigen. Mit Hilfe eines Schemas 62 könnten diese Produkte auf der Grundlage von bestimmten Eigenschaften dieser Produkte (z. B. gewisse Küchengeräte können in die Elektronikgeräteklasse 52 der Verzeichnisstruktur 44 eingeordnet werden, während Anstrichmaterialien in eine Industrieklasse 52 eingeordnet werden könnten) in eine Reihe von Klassen organisiert werden, die keinen Bezug zueinander haben. Bei einem anderen beispielhaften Schema 62 könnten jedoch alle diese Produkte in eine Heimproduktklasse eingeordnet werden (die mehrere Klassen zur weiteren Klassifizierung der Produkte enthalten könnte, z. B. eine Küchenproduktklasse, die eine Küchengeräteklasse enthält, die eine Kühlschrankklasse enthält, usw.). Folglich könnte ein und dasselbe Produkt in mehreren Schemata 62 enthalten sein. Diese Alternativschemata können in die Verzeichnisstruktur 44 aufgenommen werden und als Teil des GCD- Verzeichnisses 42 oder getrennt gespeichert werden.
Zur Navigation durch die Verzeichnisstruktur 44 kann ein Käufer 20 die verschiedenen Klassen nach Wunsch vergrößern oder wieder verkleinern. Beispielsweise sind in Fig. 2 gewisse Klassen der Verzeichnisstruktur 44, die zu einer Filzstiftklasse 60b führen, vergrößert dargestellt. Nachdem ein Käufer 20 bis zu einer für ihn ausreichend spezifischen Klasse navigiert ist (und/oder bis zur Klasse am Ende eines Zweiges) kann Käufer 20 eine Suche nach den in dieser Klasse enthaltenen Produkten durchführen. Beispielsweise kann Käufer 20 nach allen in Schreibwerkzeugklasse 56 enthaltenen Produkten suchen, bei denen es sich um blaue Filzstifte mit einer mittelfeinen Spitze handelt. Als Alternative kann der Käufer 20 aber auch bis zum Ende eines Zweigs der Verzeichnisstruktur 44 navigieren, z. B. bis zur Filzstiftklasse 60b, und dort mit Hilfe des GCD-Verzeichnisses 42 eine Suche nach Stiften mit blauer Tinte und einer mittelfeinen Spitze durchführen (wodurch der Käufer 20 zum selben Ergebnis wie zuvor gelangen kann).
Der Käufer 20 kann auch eine Suche nach Verkäufern durchführen, die einem oder mehreren Verkäuferattributwerten innerhalb einer Produktklasse entsprechen. Zum Beispiel kann Käufer 20 zusätzlich zur Suche nach allen Produkten in Schreibwerkzeugklasse 56, bei denen es sich um blaue Filzstifte mit mittelfeiner Spitze handelt, auch nach Verkäufern 30 suchen, die Texas bedienen und US-Dollar akzeptieren. Der Käufer 20 kann auf jede geeignete Weise nach Produkten mit bestimmten Produktattributwerten und nach Verkäufern mit bestimmten Verkäuferattributwerten suchen. Bei einer Ausführungsform kann Käufer 20 beispielsweise Suchkriterien vorgeben, die sowohl Werte für Produktattribute als auch für Verkäuferattribute enthalten (die Suchkriterien können stattdessen auch ganz oder teilweise automatisch erzeugt werden, siehe Beschreibung an späterer Stelle), woraufhin Server 40 eine Suche nach Produkten durchführt, die den Produktattributkriterien entsprechen und von Verkäufern angeboten werden, die den Verkäuferattributkriterien entsprechen. Bei einer weiteren Ausführungsform gibt der Käufer 20 lediglich Produktattributkriterien als Suchkriterien vor und Server 40 beschränkt seine Suche nach Produkten, die den Produktattributkriterien entsprechen, auf die Datenbanken 32 derjenigen Verkäufer 30, die bekanntermaßen den Verkäuferattributkriterien entsprechen, die der Käufer 20 gemäß seinem Käuferprofil oder auf andere Weise wünschen könnte.
Käufer 20 kann mit Hilfe der Verzeichnisstruktur 44 und des GCD-Verzeichnisses 42 auch eine Suche nach Dokumenten mit einem Bezug zu den gewünschten Produkten innerhalb der Produktklassen durchführen. Käufer 20 kann die Verzeichnisstruktur 44 mit Hilfe des GCD-Verzeichnisses 42 durchsuchen, um Dokumente mit einem Bezug zu bestimmten Produkten ausfindig zu machen. Beispielsweise könnte Käufer 20 Stifte kaufen wollen und zur Durchführung des Geschäftsvorgangs Dokumente benötigen. Dokumente mit einem Bezug zu Stiften kann Käufer 20 mindestens auf zwei verschiedene Weisen ausfindig machen, je nach der Spezifität des von Käufer 20 gewünschten Produkts. Interessiert sich Käufer 20 für mehr als einen Stifttyp, kann Käufer 20 in der Verzeichnisstruktur 44 bis zur Stiftdokumentklasse 59 navigieren. In Stiftdokumentklasse 59 angekommen kann Käufer 20 eine Suche nach allen Dokumenten mit einem Bezug zu allen Stifttypen durchführen. Die Stiftdokumentklasse 59 enthält eine oder mehrere Dokumentunterklassen 61a-61n, in denen die Stiftdokumente nach dem Dokumenttyp eingeordnet sind, so dass Käufer 20 bei Kenntnis des von Käufer 20 benötigten Dokumenttyps eine Suche nach diesem bestimmten Typ mit einem Bezug zu allen Stifttypen durchführen kann. Beispielsweise enthält Dokumentunterklasse 61a Angebotsanfragedokumente ("RFQ-Dokumente") für alle Stifttypen, während Dokumentunterklasse 61b Bestellformulardokumente für alle Stifttypen enthält. Falls Käufer 20 eine Angebotsanfrage bezüglich einer Bestellung von Stiften unterbreiten möchte, kann Käufer 20 bis zur Dokumentunterklasse 61a navigieren und die RFQ-Dokumente mit einem Bezug zu allen Stifttypen durchsuchen. Die Einordnung der Dokumente in die Produktklassen ermöglicht dem Käufer 20 außerdem die Durchführung einer detaillierteren Suche. Falls Käufer 20 sich beispielsweise nur für Kugelschreiber interessiert, kanh Käufer 20 auf die oben beschriebene Weise bis zur Kugelschreiberklasse 60a navigieren. Die Kugelschreiberklasse 60a enthält Kugelschreiberdokumentklasse 63a mit Dokumenten mit einem Bezug zu Kugelschreibern. In der Stifttypdokumentklasse 63a kann Käufer 20 eine Suche nach allen Dokumenten mit einem Bezug zu Kugelschreibern unabhängig vom jeweiligen Dokumenttyp durchführen. Eine Suche in Kugelschreiberdokumentklasse 63a kann durch Beschränkung der Suchkriterien aber auch auf nur einen bestimmten Dokumenttyp beschränkt werden, z. B. eine Suche nach Bestellaufträgen, so dass das Ergebnis der Suche nur aus Bestellauftragsformularen mit einem Bezug zu Kugelschreibern besteht. Nachdem Käufer 20 ein geeignetes Dokument im Sinne des richtigen Dokumenttyps und Produkttyps gefunden hat, kann Käufer 20 dieses Dokument auf die nachfolgend beschriebene Weise für die eigenen Zwecke modifizieren.
Wie bereits an früherer Stelle beschrieben wurde, werden bei einer Ausführungsform die Produktdaten (zumindest die detaillierteren Produktdaten als sie von der Produkttaxonomie geliefert werden), Verkäuferdaten und Dokumente nicht im GCD-Verzeichnis 42 selbst, sondern in Verkäuferdatenbanken 32 gespeichert. Beispielsweise kann ein Verkäufer 30 eine relationale Datenbank 32 mit einer Vielzahl von Tabellen unterhalten, die Produktattributwerte für eine Vielzahl von Produkten und Verkäuferattributwerte für jedes Produkt sowie einen Satz von Produkten oder sämtliche Produkte im Angebot von Verkäufer 30 enthalten. In der Verkäuferdatenbank 32 kann Verkäufer 30 außerdem Dokumente von früheren Geschäftsvorgängen zwischen Verkäufer 30 und verschiedenen Käufern 20 speichern. Die Produktdaten und Verkäuferdaten können in integrierter Form in einer oder mehreren Tabellen oder in getrennter Form in verschiedenen Tabellen vorliegen. Außerdem können die Produktdaten und die Verkäuferdaten eines Verkäufers 30 in der selben oder getrennten Datenbanken gespeichert sein. Mit jeder Klasse können ein oder mehrere Zeiger assoziiert sein, um den Standort der einen oder mehreren Datenbanken 32, die Produktdaten, Verkäuferdaten oder Dokumente für in der jeweiligen Klasse enthaltene Produkte zu erkennen zu geben oder bestimmte Daten oder bestimmte Produkte in Verkäuferdatenbanken 32 zu erkennen zu geben. Folglich kann das GCD-Verzeichnis 42 eine Suche nach Produkten oder Dokumenten in denjenigen Datenbanken 32 durchführen, die von einem Zeiger entsprechend einer vom Benutzer ausgewählten (oder automatisch ausgewählten) Klasse zu erkennen gegeben werden. Das GCD-Verzeichnis 42 kann dem Käufer 20 weiterhin die Netzwerk-Adresse (z. B. einen Uniform Resource Locator (URL) oder sonstige Netzwerkadresse) der Datenbank 32 mitteilen, so dass Käufer 20 selbst Zugriff auf die Datenbank 32 nehmen kann. Das Durchsuchen der Datenbanken 32 kann auf jede beliebige geeignete Weise erfolgen, z. B. mittels einer SQL-Anfrage (Structured Query Language), ohne aber auf diese beschränkt zu sein.
Das GCD-Verzeichnis 42 kann mit Hilfe des Lightweight Directory Access Protocol (LDAP) verwirklicht werden, mit dem Verzeichnisse mit der oben beschriebenen baumartigen Struktur erstellt werden können. Alternativ kann aber auch jede beliebige andere Technik oder Protokoll zur Erstellung des GCD-Verzeichnisses 42 verwendet werden und das GCD-Verzeichnis kann jede geeignete Struktur annehmen. Außerdem kann das GCD-Verzeichnis 42 ein Objektorientiertes Verzeichnis sein (auch dieses wird mit dem LDAP erstellt), so dass jede Klasse in der Verzeichnisstruktur 44 die Attribute der übergeordneten Klassen enthält, deren Unterklasse die jeweilige Klasse darstellt. Bei dieser Ausführungsform enthält eine am Ende eines Zweigs der Baumstruktur befindliche Klasse alle Attribute der ihr in dem betreffenden Zweig übergeordneten Klassen. Außerdem kann jedes in einer Verkäuferdatenbank 32 enthaltene Produkt oder Dokument ein Objekt darstellen, das sämtliche Attribute der Klassen enthält, in denen das Produkt oder Dokument enthalten ist. Wird daher von einer am Ende eines Zweigs der Verzeichnisstruktur 44 befindlichen Klasse aus eine Suche durchgeführt, dann kann die Suchanfrage automatisch alle geeigneten Attribute der übergeordneten Klassen der betreffenden Klasse enthalten.
Wenn ein Käufer 20 beispielsweise durch die Verzeichnisstruktur 44 hindurch bis zu Filzstiftklasse 60b navigiert ist und innerhalb Filzstiftklasse 60b eine Suche durchführt (oder diese Suche vom GCD-Verzeichnis 42 für Käufer 20 durchgeführt wird), dann kann diese Suche automatisch auf Filzstifte beschränkt sein und Käufer 20 kann zusätzliche gewünschte Suchkriterien eingeben (z. B. blaue Tinte und mittelfeine Spitze). Wenn demnach eine durchsuchte Datenbank 32 Produktdaten mit einem Bezug zu einer Reihe von Schreibwerkzeugen enthält, kann die Suche in der Datenbank 32 durch das GCD- Verzeichnis 42 automatisch auf eine Suche nach Filzstiften beschränkt werden. Der Käufer 20 kann außerdem zusätzliche Produktattributwerte und/oder Verkäuferattributwerte als zusätzliche Suchkriterien vorgeben.
Nachdem das GCD-Verzeichnis 42 eine Suche in den Datenbanken 32, die von einem oder mehreren assoziierten Zeigern einer vom Käufer 20 ausgewählten (oder automatisch ausgewählten) Klasse angegeben werden, beendet hat, kann GCD-Verzeichnis 42 die Produktdaten, Verkäuferdaten und/oder Dokumente mit einem Bezug zu einem oder mehreren, den Suchkriterien entsprechenden Produkten ausgeben. Das GCD-Verzeichnis 42 kann die als Ergebnis der Suche gefundenen Produktdaten, Verkäuferdaten und/oder Dokumente in die Verzeichnisstruktur 44 integrieren, so dass Käufer 20 den Anschein bekommt, die Daten seien ein Teil des GCD-Verzeichnisses 42. Als Alternative kann das GCD-Verzeichnis 42 die Suchergebnisse auf jede beliebige andere geeignete Weise präsentieren. Jedes als Suchergebnis gefundene Produkt oder Dokument kann ein Objekt darstellen, das eine eindeutige Instanz der vom Käufer 20 durchsuchten Klasse darstellt. Außerdem kann jedes solche Objekt (und sein Standort) durch ein der Verzeichnisstruktur 44 entsprechendes Nummerierungssystem auf eindeutige Weise identifiziert sein.
Es lässt sich zusammenfassen, dass ein Käufer 20 mit Hilfe des GCD-Verzeichnisses 42 eine Suche nach einem Produkt durchführen kann, das bestimmten Produktattributwerten entspricht und von einem Verkäufer 30 erhältlich ist, der bestimmten Verkäuferattributwerten entspricht, und auf diese Weise der Aufwand für Käufer 20 beim individuellen Durchsuchen zahlreicher Verkäuferdatenbanken 32 zur Ausfindigmachung des gewünschten Produkts im Angebot eines geeigneten Verkäufers verringert oder gänzlich eliminiert wird. Außerdem kann Käufer 20 eine Suche nach einem Dokument durchführen, das gewissen Attributen entspricht, so dass diese Dokumente nicht jedes mal wieder neu erstellt werden müssen, wenn Käufer 20 einen neuen Geschäftsvorgang mit einem Verkäufer 30 bezüglich eines oder mehrerer Produkte abwickelt. Mit Hilfe der Verzeichnisstruktur 44, in der Produkte in einem hierarchischen, objektorientierten Klassifikationssystem organisiert sind, bietet das GCD-Verzeichnis 42 einen Zugang zu Produkt- und Verkäuferdaten und Dokumenten mit einem Bezug zu dieser Vielzahl von Produkten. Der Käufer 20 kann durch die Verzeichnisstruktur 44 navigieren oder diese durchsuchen, um eine bestimmte Klassifikation von Produkten und verschiedene mit den Produkten in dieser Klassifikation assoziierte Informationen einschließlich Dokumente mit einem Bezug zu verschiedenen Produkten zu finden, dann die Datenbanken 32 nach Produkten und/oder Dokumenten einschließlich Produkt- und/oder Verkäuferdaten mit einem Bezug zu einem Produkt durchsuchen und anschließend mit Hilfe des GCD-Servers 40 oder auf eine sonstige Weise mit einer entsprechenden Datenbank 32 kommunizieren. Dieser Zugang zu einer unermesslichen Anzahl von Produkten und Dokumenten wird geboten, ohne dass sämtliche Daten über die Produkte, Verkäufer und Dokumente in einer globalen Datenbank gespeichert sein müssen. Stattdessen können diese Daten in Verkäuferdatenbanken 32 gespeichert sein, auf die ein Zugriff mit Hilfe des GCD- Verzeichnisses 42 leicht möglich ist.
Bei der Verwendung von verschiedenen Verkäuferdatenbanken 32 kann es möglicherweise zu dem Problem kommen, dass diese Datenbanken 32 Produktdaten über die selbe Produktklasse (z. B. Filzstifte) enthalten können, die Produkte in dieser Klasse aber anhand von unterschiedlichen Attributwerten definieren oder unterschiedliche Bezeichnungen für den selben Produktattributwert verwenden und/oder die Produktattributwerte auf unterschiedliche Weise quantifizieren oder unterscheiden (z. B. durch Anwendung unterschiedlicher Maßeinheiten). Dies kann gleichermaßen auch für die in den Datenbanken 32 enthaltenen Verkäuferdaten gelten. Außerdem haben Käufer 20 und Verkäufer 30 unterschiedliche Dokumente, die sich in ihren Formaten voneinander unterscheiden. Diese Probleme lassen sich möglicherweise zum Teil durch Übersetzungsmechanismen lösen, mit denen die Daten in ein einheitliches Format umgewandelt werden, das vom GCD-Verzeichnis 42 verwendet wird, und mit denen die unterschiedlichen Dokumente in ein für das GCD-Verzeichnis 42 verständliches Standardformat umgewandelt werden. Als Alternative können die Verkäufer 30 neue Datenbanken 32 anlegen oder bestehende Datenbanken 32 manuell modifizieren (oder eine Drittpartei mit der Erstellung oder Modifikation der Datenbanken 32 beauftragen), um sie in ein einheitliches Standardformat zu bringen, weil zu erwarten steht, dass die Datenbanken 32 in Verbindung mit dem GCD-Verzeichnis 42 verwendet werden und die Käufer 20 und Verkäufer 30 Dokumente so erstellen oder modifizieren, dass sie einem Standardformat entsprechen, das in Verbindung mit dem GCD-Verzeichnis 42 benutzt werden kann.
Die Erstellung oder Modifikation von Dokumenten in einem oder zu einem Standardformat ist eine schwierigere Aufgabe als die Standardisierung der Produktdaten, da die Dokumente zwar ähnliche grundlegende Angaben enthalten können, jeder Käufer 20 und jeder Verkäufer 30 jedoch im allgemeinen bestimmte Klauseln, Abschnitte und Bestimmungen besitzt oder verlangt, die bei anderen Käufern 20 und Verkäufern 30 nicht vorhanden sind oder verlangt werden. Außerdem können bestimmte Dokumenttypen sehr ähnliche Angaben enthalten, die sich nicht größer unterscheiden, während andere Dokumenttypen sehr stark voneinander abweichen können und wenige oder keine gemeinsamen Bestimmungen enthalten. Beispielsweise enthält eine Angebotsanfrage (RFQ) im allgemeinen Abschnitte mit Kontaktinformationen über den Käufer 20 und Verkäufer 30, eine Produktbeschreibung und Angaben zur angefragten Menge und typischerweise werden die meisten Angebotsanfragen ähnlich aussehen, obwohl sie von unterschiedlichen Käufern 20 und Verkäufern 30 erstellt werden. Andere Dokumente hingegen, z. B. ein Stornoformular, können sich je nach den Anforderungen des jeweiligen Käufers 20 oder Verkäufers 30 stark unterscheiden, da jeder Käufer 20 und Verkäufer 30 typischerweise seine eigenen Prozeduren und Anforderungen für Stornoformulare besitzt. Folglich werden bei einer Lösung für das Standardisierungsproblem die Dokumente in Standarddokumente bzw. Sonderdokumente eingeordnet und einen gemeinsamen Dokumentenspeicher 35 zur Speicherung der Standarddokumente geboten, wodurch das GCD-Verzeichnis 42 effizienter funktionieren kann.
Bei Standarddokumenten handelt es sich um Dokumente, die in einer vom GCD-Server 40 erkannten standardisierten Form vorliegen, oder um Dokumente, die sich bei verschiedenen Käufern 20 und Verkäufern 30 nicht größer unterscheiden und die im Laufe der Zeit leicht standardisiert werden könnten. Die standardisierte Form der einzelnen Standarddokumente unterscheidet sich in Abhängigkeit vom Typ des Dokuments. Beispielsweise unterscheidet sich die standardisierte Form eines Angebotsanfrage-Standarddokuments von der standardisierten Form eines Bestellformular-Standarddokuments. Bei Sonderdokumenten handelt es sich um Dokumente, die nicht in der standardisierten Form vorliegen, sondern im allgemeinen in einem vom Käufer 20 oder Verkäufer 30 vorgegebenen Format, und die im allgemeinen schwieriger auf eine Standardform zu reduzieren sind. Sonderdokumente enthalten häufig Bedingungen und Bestimmungen, die für einen bestimmten Käufer 20 oder Verkäufer 30 spezifisch sind und möglicherweise nicht bei allen Käufern 20 und Verkäufern 30 angewandt werden können. Sonderdokumente können stark voneinander abweichen.
Der gemeinsame Dokumentenspeicher 35 enthält ein oder mehrere Standarddokumente. Wenn ein Käufer 20 oder Verkäufer 30 ein Standarddokument erstellt oder ein bereits im gemeinsamen Dokumentenspeicher 35 enthaltenes Standarddokument modifiziert, wird das neu erstellte oder modifizierte Standarddokument im gemeinsamen Dokumentenspeicher 35 gespeichert. Sonderdokumente können in einer oder mehreren Verkäuferdatenbanken 32gespeichert werden. Im optimalen Fall enthalten die Produktklassen des GCD- Verzeichnisses 42, in die ein bestimmtes Produkt eingeordnet ist, eine Verknüpfung mit den aus Standard- und Sonderdokumenten bestehenden Kombinationen mit einem Bezug zu dem betreffenden Produkt. Beispielsweise könnte die Stiftdokumentklasse 59 im GCD- Verzeichnis 42 einen Zeiger zu den Standarddokumenten und den Sonderdokumenten im gemeinsamen Dokumentenspeicher 35 sowie einer oder mehreren Verkäuferdatenbanken 32 enthalten. Weiterhin könnte eine Verknüpfung von einem oder mehreren Zeigern zu dem gemeinsamen Dokumentenspeicher 35 zu einem oder mehreren Zeigern zur Verkäuferdatenbank 32 vorhanden sein, so dass die zusammengehörigen Standard- und Sonderdokumente assoziiert werden können. Als Alternative können die im gemeinsamen Dokumentenspeicher 35 enthaltenen Standarddokumente mit einem oder mehreren Sonderdokumenten in einer oder mehreren Verkäuferdatenbanken 32 verknüpft sein. Sonderdokumente aus der Verkäuferdatenbank 32 können mit Standarddokumenten aus dem gemeinsamen Dokumentenspeicher 35 verknüpft sein, so dass die Standard- und die Sonderdokumente einem Käufer 20 als das Ergebnis einer Suche vorgelegt werden können, wie nachfolgend unter Bezugnahme auf die Fig. 6A und 6B in weiteren Einzelheiten erläutert ist.
Der gemeinsame Dokumentenspeicher 35 ist zwar mit nur einem Archivstandort dargestellt, doch kann der gemeinsame Dokumentenspeicher 35 mehrere verschiedene Archivstandorte am selben oder unterschiedlichen geografischen Ort enthalten. Dabei kann jede beliebige Anzahl von Archivstandorten an einer Anzahl von geografischen Standorten verwendet werden (die Archivstandorte können beispielsweise über verschiedene geografische Regionen verteilt sein). Der GCD-Server 40 kann die verteilt angeordneten gemeinsamen Dokumentenspeicher 35 auf eine geeignete Weise durchsuchen, um Standarddokumente zu erhalten, die der Suche eines Käufers entsprechen. Als Alternative können mit einer Produktklasse assoziierte Zeiger den GCD-Server 40 zu einem oder mehreren bestimmten Archivstandorten leiten. Außerdem kann bei Einsatz von mehreren gemeinsamen Dokumentenspeichern 35 jedes einzelne gemeinsame Dokumentenspeicher 35 identische Standarddokumente, einige gemeinsame und einige verschiedene oder völlig verschiedene Standarddokumente enthalten. Außerdem können die Standarddokumente im gemeinsamen Dokumentenspeicher 35 mit Hilfe eines beliebigen geeigneten Speicherungsmediums gespeichert werden. Weiterhin ist zu beachten, dass der gemeinsame Dokumentenspeicher 35 der Beschreibung zufolge zwar die Standarddokumente enthält, die Verkäuferdatenbanken 32 aber ebenfalls Standarddokumente enthalten können.
In Fig. 3 ist eine beispielhafte Verzeichnisstruktur 70 eines beispielhaften GCD- Verzeichnisses 42 für Dokumentklassen dargestellt. Zusätzlich zur Einordnung in Produktklassen können in GCD-Verzeichnis 42 eingeordnete Dokumente auch nach einem Schema organisiert sein, das einen hierarchisch organisierten Satz von Dokumentklassen oder eine Taxonomie enthält, wobei jede Dokumentklasse mit einem Satz von Dokumentmerkmalen, -eigenschaften oder sonstigen Dokumentattributen (einer "Dokumentontologie") assoziiert ist. Durch die Einordnung der Dokumente in Dokumentklassen anstatt der in Fig. 2 beschriebenen Einordnung in Produktklassen kann der Käufer 20 auf der Grundlage des Dokumenttyps nach Dokumenten suchen und unabhängig davon, zu welchem Produkt ein Dokument einen Bezug aufweist.
In der beispielhaften Verzeichnisstruktur 70 können Dokumente nach den Geschäftsdokumentschemata 72 oder anderen geeigneten Schemata organisiert werden, wie nachfolgend beschrieben wird. Innerhalb der Geschäftsdokumentschemata 72 gibt es drei Beispielklassen: Verkäuferdokumentklasse 74, Verkäuferdokumentklasse 76 und Dokumentklasse 78. Diese Klassen 74, 76 und 78 enthalten jeweils wieder mehrere Unterklassen (die wiederum Unterklassen enthalten können). Auf diese Weise bilden die zahlreichen Klassen der Verzeichnisstruktur 70 ähnlich wie Verzeichnisstruktur 44 eine "baumartig verzweigte" hierarchische Struktur zur Einordnung der Dokumente. Beispielhaft sind gewisse Teile der Verzeichnisstruktur 70 in Fig. 3 vergrößert dargestellt, um die verschiedenen Ebenen der Klassen darzustellen, wobei mit Ebene einer Klasse das selbe gemeint ist wie in Fig. 2 oben. Wie oben beschrieben, kann die Verzeichnisstruktur 70 zwar Geschäftsdokumentschemata 72 verwenden, doch können zusätzlich zu oder anstelle der Geschäftsdokumentschemata 72 auch beliebige andere Schemata zur Anwendung kommen. Ein Dokument kann in mehreren Schemata 80 enthalten sein und diese Alternativschemata 80 können in der Verzeichnisstruktur 70 enthalten sein und als Teil des GCD-Verzeichnisses 42 oder getrennt gespeichert sein. Die Verzeichnisstruktur 70 besitzt eine ähnliche Organisation wie die Verzeichnisstruktur 44 mit dem Unterschied, dass die Verzeichnisstruktur 70 sich auf Dokumentklassen bezieht.
Wie Fig. 3 zu entnehmen ist, enthält die Käuferdokumentklasse 74 Dokumente, die aus der Sicht eines Käufers organisiert sind, Verkäuferdokumentklasse 76 enthält Dokumente, die aus der Sicht eines Verkäufers organisiert sind, und Dokumentklasse 78 enthält alle Dokumente. Dokumente, die aus der Sicht eines Käufers organisiert sind und bei einem Geschäftsvorgang zwischen Käufer 20 und Verkäufer 30 benutzt werden, enthalten günstige Bestimmungen für den Käufer und wurden typischerweise von einem Käufer bei einem früheren Geschäftsvorgang erstellt. Dokumente, die aus der Sicht des Verkäufers organisiert sind und aus einem früheren Geschäftsvorgang zwischen Käufern 20 und Verkäufern 30 stammen, enthalten günstigere Bestimmungen für den Verkäufer als für den Käufer und wurden typischerweise von einem Verkäufer bei dem früheren Geschäftsvorgang erstellt. Beispielsweise können unterschiedliche Bestimmungen in einem Dokument enthalten sein in Abhängigkeit von der Stärke der Verhandlungsposition des am Geschäftsvorgang teilnehmenden Käufers und Verkäufers. Befindet sich der Verkäufer in einer stärkeren Verhandlungsposition spiegelt sich dies im allgemeinen durch Bestimmungen im Dokument wider, die günstiger für den Verkäufer sind. Befindet sich hingegen der Käufer in einer stärkeren Verhandlungsposition, enthält das Dokument typischerweise günstigere Bestimmungen für den Käufer als für den Verkäufer. Folglich könnte ein nach einem bestimmten Dokument suchender Käufer 20 ein Interesse daran haben, nur solche Dokumente zu finden, die für den Käufer günstiger sind als für den Verkäufer, falls Käufer 20 in der besseren Verhandlungsposition ist oder Käufer 20 könnte ein aus der Sicht des Verkäufers organisiertes Dokument annehmbar finden, um die Verhandlungen mit dem Verkäufer abzukürzen, da das betreffende Dokument den Verkäufer bereits begünstigt.
Die Navigation des Käufers 20 innerhalb der Verzeichnisstruktur 70 wird davon bestimmt, nach welchem Typ von Dokument Käufer 20 sucht. Falls Käufer 20 nach Bestellauftragsdokumenten mit der Sichtweise des Käufers sucht, würde Käufer 20 bis zur Käuferdokumentklasse 74 und zur Käufer-Bestellauftragsklasse 82b navigieren. An dieser Stelle könnte Käufer 20 eine Suche nach allen Bestellauftragsdokumenten durchführen, die aus der Sicht des Käufers organisiert sind. Käufer 20 könnte die Suche in Käufer- Bestellauftragsklasse 82b weiter einschränken, indem Käufer 20 sich auf Bestellaufträge aus dem vergangenen Jahr und mit einem Bezug auf Baumwollkugeln beschränkt. Käufer 20 könnte aber auch an Dokumenten mit einem Bezug zu Auftragsbestätigungen aus der Sicht des Verkäufers ein Interesse haben und daher durch die Verzeichnisstruktur 70 bis zur Verkäuferdokumentklasse 76 und Verkäufer-Auftragsbestätigungsklasse 84n navigieren und dort eine Suche nach allen Auftragsbestätigungen durchführen, die aus der Sicht des Verkäufers organisiert sind. Es könnte dem Käufer 20 aber auch egal sein, ob ein Dokument aus der Sichtweise des Käufers oder des Verkäufers erstellt wurde und stattdessen lieber nach allen verfügbaren Dokumenten suchen. In diesem Fall würde Käufer 20 durch die Verzeichnisstruktur 70 bis zur Dokumentklasse 78 navigieren, in der sämtliche Dokumente enthalten sind. Anschließend könnte Käufer 20 eine der Dokumentunterklassen 86a-86n durchsuchen, je nachdem, nach welchem Dokumenttyp Käufer sucht. Käufer 20 könnte auch die Dokumentklasse 78 durchsuchen und ohne weitere Einschränkung der Suche alle Dokumente durchsuchen.
In der Verzeichnisstruktur 70 und den Dokumentklassen können die Dokumente auf die in Fig. 2 beschriebene Weise als Standarddokumente und Sonderdokumente eingeordnet und in einem gemeinsamen Dokumentenspeicher 35 und Verkäuferdatenbanken 32 gespeichert sein. Die Verwendung der Verzeichnisstruktur 70 und der Zeiger zum gemeinsamen Dokumentenspeicher 35 und den Verkäuferdatenbanken 32 entsprechen der Beschreibung der Verzeichnisstruktur 44 aus Fig. 2 mit dem Unterschied, dass die Dokumente in Dokumentklassen anstelle von Produktklassen eingeordnet sind. In der Verzeichnisstruktur 44 sind die Dokumente mit bestimmten Produkten assoziiert und die Suche nach den Dokumenten erfolgt über die Produktklassen. Bei der Verzeichnisstruktur 70 sind die Dokumente nicht in Produktklassen, sondern je nach Dokumenttyp in Dokumentklassen eingeordnet. Bei der Verzeichnisstruktur 44 ist ein Käufer oder Verkäufer mit einem bestimmten Produkt befasst und möchte Dokumente finden, die mit diesem Produkt assoziiert sind. Bei der Verzeichnisstruktur 70 ist ein Käufer oder Verkäufer an einem Dokumenttyp interessiert und möchte alle Dokumente eines bestimmten Typs finden, unabhängig davon, mit welchen Produkten diese Dokumente assoziiert sind.
In Fig. 4 wird eine Beispieltabelle 150 erläutert, die in einer Verkäuferdatenbank 32 und/oder einem Speicher 34 enthalten sein kann. Datenbank 32 und Speicher 34 können eine oder mehrere Tabellen 150 enthalten und jede Tabelle 150 kann Daten mit einem Bezug zu einem oder mehreren Produkten enthalten. Beispielsweise enthält Beispieltabelle 150 Daten mit einem Bezug zu verschiedenen Stifttypen. Tabelle 150 kann außerdem Daten für andere Typen von Produkten enthalten (zum Beispiel andere Typen von Bürobedarfartikeln) oder Daten dieser Art können in anderen Tabellen 150 in Datenbanken 32 und/oder Speicher 34 enthalten sein. Tabelle 150 enthält eine Vielzahl von Spalten 152, die jeweils Daten mit einem Bezug zu einem bestimmten Produktattribut oder Verkäuferattribut enthalten. Zwar ist an dieser Stelle eine beispielhafte Anzahl von Spalten 152 mit beispielhaften Produktattributwerten und Verkäuferattributwerten zu Erläuterungszwecken dargestellt, doch ist davon auszugehen, dass jede beliebige Anzahl von Produktattributen, Verkäuferattributen oder sonstigen Datenkategorien eines beliebigen Typs in Tabelle 150 enthalten sein kann. Außerdem können die Verkäuferdaten und die Produktdaten wie an früherer Stelle bereits kurz ausgeführt wurde, in verschiedene Tabellen getrennt werden anstatt in einer Tabelle auf die in Beispieltabelle 150 dargestellte Weise integriert zu sein.
Tabelle 150 enthält weiterhin eine Anzahl von Zeilen 154, die jeweils einem bestimmten Produkt entsprechen können und die jeweils Werte für ein oder mehrere Produktattribute und Verkäuferattribute enthalten können. Jeder dieser Werte (bei denen es sich um numerische Werte, Textwerte oder Werte in jedem beliebigen anderen geeigneten Format handeln kann) befindet sich am Schnittpunkt der einem bestimmten Produkt zugeordneten Zeile 154 und der Spalte 152, die ein bestimmtes Produktattribut oder Verkäuferattribut enthält. Solche Schnittpunkte können als Feld oder Zelle 156 der Tabelle 150 bezeichnet werden. Falls die Produktdaten und Verkäuferdaten integriert sind, kann jede Zeile 154 sämtliche Produktdaten und Verkäuferdaten für das der Zeile 154 zugeordnete Produkt enthalten. Als Alternative kann auch eine Zeile oder ein Satz von Zeilen den Verkäuferdaten vorbehalten sein, die für alle Produkte im Angebot des Verkäufers 30 oder einen Teil dieser Produkte gültig sind. Falls die Verkäuferdaten und Produktdaten getrennt sind, kann jede Zeile in der Verkäuferdatentabelle einem Satz von Verkäuferattributwerten entsprechen, die mit einem oder mehreren in der Produktdatentabelle enthaltenen Produkten verknüpft sein können, so dass beim Zugriff auf die Produktdaten für ein bestimmtes Produkt auch ein Zugriff auf die Verkäuferdaten für das betreffende Produkt erfolgen kann und umgekehrt. Außerdem können die Dokumente in Form von individuellen Dateien und/oder wie Produkt- und Verkäuferdaten als Daten in Tabellen gespeichert sein.
Die in einer oder mehreren Spalten 152 der Tabelle 150 enthaltenen Daten können mit einem Index versehen werden, um die Geschwindigkeit beim Lesen der Datenbank zu erhöhen. Beispielsweise können die Felder 156 der Tintenfarbespalte 152d und der Spitzengrößespalte 152e mit einem Index versehen werden, so dass eine Datenbankanfrage nach einem Stift mit einer bestimmten Tintenfarbe und Spitzengröße schnell durchgeführt werden kann. Die in Tabelle 150 enthaltenen Daten können mit Hilfe eines geeigneten Datenbankindizierungsverfahrens mit einem Index ("indiziert") versehen werden. Das typische Ergebnis einer solchen Indizierung besteht darin, dass bei einer Anfrage des GCD- Verzeichnisses 42 oder eines Käufers 20 nach indizierten Daten in einer Datenbank 32 und/oder einem Speicher 34 das zugehörige Datenbankverwaltungssystem (oder eine sonstige geeignete Schnittstelle zur Datenbank 32 und/oder zum Speicher 34) nicht jedes in Datenbank 32 und/oder Speicher 34 enthaltene Feld 156 in den Tabellen 150 durchsuchen muss, um die angefragten Daten zu finden. Statt dessen könnten die Daten so indiziert werden, dass beim Eingang einer Anfrage nach Produkten mit bestimmten Produktattributwerten und/oder Verkäufern 30 mit bestimmten Verkäuferattributwerten, bei denen eine Indexierung erfolgt ist, das Datenbankverwaltungssystem bereits weiß, wo diese Daten in Tabelle 150 zu finden sind und die mit diese Produkten verbundenen Daten ausgeben kann, ohne die gesamte Tabelle 150 oder Datenbank 32 und/oder Speicher 34 nach diesen Produkten zu durchsuchen. Bei einer Indexierung beispielsweise des Tintenfarbefelds 156 und des Spitzengrößefelds 156 der Spalten 152d bzw. 152e, wird durch die Indizierung typischerweise der Standort aller Produkte mit schwarzer Tinte und einer mittelfeinen Spitze angegeben.
Geht eine Suchanfrage ein, die auch einen Wert für ein oder mehrere nicht-indizierte Produktattribute (zum Beispiel eine Suchanfrage für Stifte des Herstellers Firma ABC, vorausgesetzt die Herstellerfelder 156 in Spalte 152c sind nicht indiziert) und oder Verkäuferattribute enthält, dann kann das entsprechende Datenbankverwaltungssystem in Datenbank 32 und/oder Speicher 34 eine Suche nach Produkten durchführen, die den vorgegebenen Wert für ein oder mehrere nicht-indizierte Attribute oder Verkäuferattribute enthalten. Eine solche Suche kann aber (mit Hilfe des Indexes) auf die Produkte begrenzt werden, bei denen bereits festgestellt wurde, dass sie die Vorgabewerte für die indizierten Attribute enthalten (zum Beispiel Stifte mit schwarzer Tinte und mittelfeiner Spitze) und/oder die Verkäuferattribute, die ebenfalls Bestandteil der Suche sind. Auf diese Weise kann der zeitliche Aufwand bei der Durchführung einer Suche selbst dann verringert werden, wenn ein oder mehrere der in die Suche einbezogenen Produktattributwerte oder Verkäuferattributwerte nicht indiziert sind.
In Fig. 5 ist ein beispielhaftes E-Commerce-System 10 in weiteren Einzelheiten dargestellt. Wie bereits beschrieben können zahlreiche Käufer 20 und Verkäufer 30 mit Hilfe des Netzwerks 12 mit GCD-Server 40 verbunden werden. Mit Hilfe eines Webbrowsers oder auf jede sonstige geeignete Weise können Käufer 20 Zugriff auf GCD- Server 40 nehmen und GCD-Server 40 kann den Käufern 20 mit Hilfe eines Webbrowsers oder auf jede sonstige geeignete Weise einen Zugriff auf das GCD-Verzeichnis 42 ermöglichen. Zwar wird das GCD-Verzeichnis 42 so dargestellt, als ob es in dem GCD- Server 40 angeordnet wäre, doch kann das GCD-Verzeichnis im GCD-Server 40 aber auch außerhalb des GCD-Servers 40 angeordnet sein, wie an früherer Stelle bereits ausgeführt wurde. Der GCD-Server 40 kann außerdem Hardware und/oder Software für die Umsetzung einer oder mehrerer GCD-Schnittstellen 43 umfassen. Ein Käufer 20 kann Zugriff auf den GCD-Server 40 nehmen und mit Hilfe einer GCD-Schnittstelle 43 eine Suche oder Navigation im GCD-Verzeichnis 42, Verkäuferdatenbanken 32, Speicher 34 und gemeinsamen Dokumentenspeicher 35 durchführen. Zur Kommunikation von Informationen zwischen Käufern 20, Verkäufern 30 und GCD-Verzeichnis 42 kann das Hypertext Transport Protocol (HTTP), Extensible Markup Language (XML), Simple Object Access Protocol (SOAP) oder jede sonstige geeignete Kommunikationstechnik dienen. An alle Käufer 20 und Verkäufer 30 kann ein eindeutiger Identifizierungskode vergeben werden, mit dem die Beteiligten an einem vom GCD-Verzeichnis 42 vermittelten Geschäftsvorgang eindeutig identifiziert werden können. Außerdem kann allen Käufern 20 und Verkäufern 30 eine bestimmte Rolle in Bezug auf einen Geschäftsvorgang zugeordnet werden. Wie bereits beschrieben wurde, kann ein Käufer 20 eines Geschäftsvorgangs bei einem anderen Geschäftsvorgang als Verkäufer 30 auftreten und umgekehrt.
Bei einem beispielhaften Suchvorgang kann ein Käufer 20 Zugriff auf die GCD- Schnittstelle 43 nehmen und eine Suche im GCD-Verzeichnis 42 durchführen. Die GCD- Schnittstelle 43 kann es dem Käufer 20 ermöglichen, sowohl durch die Klassen des GCD- Verzeichnisses 42 zu navigieren (im Sinne des "Browsers") als auch eine Suche nach einer bestimmten Klasse oder bestimmten Klassen durchzuführen. Beispielsweise könnte Käufer 20 entweder durch das GCD-Verzeichnis 42 navigieren, um eine Klasse zu finden, in die Stifte eingeordnet sind, oder Käufer 20 kann GCD-Verzeichnis 42 nach Klassenbezeichnungen durchsuchen, die das Wort "Stift" enthalten. Es kann aber auch jede andere geeignetes Verfahren zum Ausfindigmachen einer bestimmten Klasse benutzt werden. Nachdem Käufer 20 eine entsprechende Klasse für ein von Käufer 20 gewünschtes Produkt und/oder Dokument gefunden hat, kann Käufer 20 eine Liste mit den Produkten und/oder Dokumenten in dieser Klasse abfragen, die gewissen Produktattributwerten entsprechen. Falls Käufer 20 beispielsweise bis zur Filzstiftklasse 60b navigiert ist, könnte Käufer 20 beispielsweise alle Produkte in Klasse 60b (Filzstifte) abfragen, die rote Tinte verwenden, eine feine Spitze haben und von einem Verkäufer 30 mit Sitz in den Vereinigten Staaten verkauft werden.
Eine solche Abfrage könnte durch eine Suchschnittstelle 45 oder eine sonstige geeignete Komponente des GCD-Servers 40 ermöglicht werden, indem eine Suche in Speicher 34 und/oder Verkäuferdatenbanken 32 durchgeführt oder angefordert wird, die durch einen oder mehrere mit Filzstiften assoziierte Zeiger zu erkennen gegeben werden, wie bereits beschrieben wurde. Die Suchschnittstelle 45 könnte dem Käufer 20 ein Suchformular bieten, in das ein oder mehrere Suchkriterien eingegeben werden. Die zulässigen Suchkriterientypen können entweder im Suchformular vorgegeben werden oder es kann dem Käufer 20 erlaubt sein, mit bestimmten Begriffen eine allgemeine Suche in den Datenbanken 32 und/oder dem Speicher 34 durchzuführen. Beispielsweise könnte Suchschnittstelle 45 dem Käufer 20 ein Suchformular bieten, das auf die Klasse 60b zugeschnitten ist und Felder enthält, in denen der Käufer 20 eine gewünschte Tintefarbe, Größe der Spitze oder sonstige entsprechende produktbezogene oder Verkäuferbezogene Kriterien angeben kann. Bei einer Ausführungsform entsprechen die Felder des Suchformulars einigen oder allen Produktattributen in der Produktontologie und/oder Verkäuferattributen in der Verkäuferontologie für die ausgewählte Produktklasse und Käufer 20 kann Werte für die Produktattribute und Verkäuferattribute in die betreffenden Suchformularfelder eingeben. Anstelle eines Suchformulars kann Suchschnittstelle 45 aber auch ein einzelnes Feld bieten, in das der Käufer gewünschte Suchbegriffe eingeben kann, zum Beispiel "rot" und "fein" (die Eingabe von mehreren Suchbegriffen kann mit Hilfe von Booleschen Operatoren oder mit jeder beliebigen anderen geeigneten Technik erfolgen). Die Suchschnittstelle 45 oder jede beliebige andere geeignete Komponente des GCD- Servers 40 kann Suchanfragen aber auch durch den Zugriff auf ein Käuferprofil für Käufer 20 ermöglichen, das die gesammelten Informationen aus früheren Suchanfragen des Käufers 20 oder früheren E-Commerce-Vorgängen unter Beteiligung des Käufers 20 oder sonstigen Ereignissen oder Handlungen seitens des Käufers 20 enthält. Beispielsweise könnte ein Käuferprofil eine Liste von Verkäufern 30 enthalten, die den von Käufer 20 möglicherweise gewünschten Verkäuferattributwerten entsprechen. Zusammenstellen ließe sich eine solche Liste aus den Ergebnissen früherer Suchvorgänge des Käufers 20. Die Suchschnittstelle 45 kann für jeden geeigneten Zweck Zugriff auf das Profil des Käufers 20 nehmen. Bei einer Ausführungsform kann Suchschnittstelle 45 Zugriff auf das Profil des Käufers 20 nehmen, um automatisch Suchkriterien für einen Suchvorgang zu generieren, zum Beispiel Produktattributwerte und/oder Verkäuferattributwerte. Die Suchschnittstelle 45 könnte aber auch Zugriff auf das Profil des Käufers 20 nehmen, um ihre Suche nach Produkten, die bestimmten, von Käufer 20 vorgegebenen (oder automatisch erzeugten) Produktattributwerten entsprechen, auf die Datenbanken 32 von Verkäufern 30 zu beschränken, die bekanntermaßen den möglicherweise von Käufer 20 gewünschten Verkäuferattributwerten entsprechen (und/oder Daten in Speicher 34, die mit diesen Verkäufern 30 assoziiert sind).
Basierend auf den vom Käufer 20 oder automatisch erzeugt und vorgegeben Suchkriterien kann Suchschnittstelle 45 eine Suchanfrage an die entsprechende(n) Verkäuferdatenbank(en) 32 und/oder Speicher 34 übermitteln und verlangen, dass die Datenbanken 32 und/oder das Speicher 34 jeweils eine Liste aller Produkte (einschließlich der assoziierten Produktdaten und/oder Verkäuferdaten) ausgeben, die den Suchkriterien entsprechen. Die Datenbanken 32 und/oder das Speicher 34 können aber auch Daten mit einem Bezug zu Attributwerten ausgeben, die in den Suchkriterien nicht enthalten waren. Beispielsweise kann Datenbank 32 eine Angabe über den Preis und die Lieferbarkeit von Produkten ausgeben, die den Suchkriterien entsprechen, obwohl weder der Preis noch die Lieferbarkeit zu den Suchkriterien gehörten. Die Antworten auf die Suchanfragen für die Datenbanken 32 und/oder das Speicher 34 können dem Käufer 20 auf jede beliebige geeignete Weise angezeigt werden. Beispielsweise könnten die Produkte in der Reihenfolge ihrer Relevanz zu den Suchkriterien, die durch beliebige geeignete Vergleichskriterien ermittelt wird, aufgelistet werden. Weiterhin kann das GCD-Verzeichnis 42 die aufgelisteten Produkte auf Wunsch des Käufers 20 neu ordnen. Beispielsweise könnte Käufer 20 wünschen, dass die entsprechenden Produkte in der Reihenfolge vom kostengünstigsten bis zum teuersten Produkt aufgelistet werden. Als Alternative können die Suchergebnisse von den Datenbanken 32 und/oder Speicher 34 direkt an den Käufer 20 übermittelt werden.
Aus einer Produktliste kann Käufer 20 ein Produkt auswählen und auf diese Weise anzeigen, dass Käufer 20 einen Geschäftsvorgang zu diesem Produkt einzuleiten wünscht, zum Beispiel den Kauf dieses Produkts. Erfolgt eine solche Auswahl, kann das GCD- Verzeichnis 42 einen RID-Kode (Repository Identifier) zur Identifizierung des ausgewählten Verkäufers 30 und einen GUID-Kode (Globally Unique Identifier) für das Produkt an den Käufer 20 übermitteln. Als RID-Kode könnte beispielsweise eine Netzwerkadresse (zum Beispiel eine IP-Adresse) eines Verkäufernetzwerkknotens 30 dienen oder der RID-Kode kann mit der Netzwerkadresse in einer Tabelle assoziiert sein (wobei das GCD-Verzeichnis 42 den RID-Kode verwenden kann, um die zugehörige Netzwerkadresse herauszufinden und diese Netzwerkadresse anschließend dem Käufer 20 mitzuteilen). Der Käufer 20 kann den Verkäufer 30 mit Hilfe des RID-Kodes (oder der Netzwerkadresse) kontaktieren und mit Hilfe des GUID-Kodes einen Geschäftsvorgang für das betreffende Produkt veranlassen. Das GCD-Verzeichnis 42 kann sogar eine Verknüpfung einschließlich eines URL einer mit Verkäufer 30 verbundenen Website bieten oder dem Käufer 20 eine andere geeignetes Verfahren zur Verbindung mit dem Verkäufer 30 bieten. Zwar ist die Kommunikation zwischen Käufern 20 und Verkäufern 30 nur durch einen einzelnen Beispielpfeil (zwischen Käufern 20 und Verkäufern 30) dargestellt, doch bezieht sich dies auf die Kommunikation jedes Käufers 20 mit jedem Verkäufer 30 zur Abwicklung von entsprechenden Geschäftsvorgängen.
Das beispielhafte E-Commerce-System 10 umfasst außerdem das Sicherheitsmodul 41 und das Intelligenzmodul 47. Zwar sind das Sicherheitsmodul 41 und das Intelligenzmodul 47 als integrale Teile des GCD-Servers 40 dargestellt, doch können das Sicherheitsmodul 41 und das Intelligenzmodul 47 sowohl integrale Teile des GCD-Servers 40 sein als auch außerhalb angeordnet sein. Wie bereits beschrieben dient das System 10 zur Speicherung und Klassifizierung von Standarddokumenten und Sonderdokumenten. Beispielweise benötigt Käufer 20 zur Abwicklung eines Geschäftsvorgangs mit Verkäufer 30 ein oder mehrere Dokumente. System 10 kann die bei diesem Geschäftsvorgang benutzten Dokumente entweder im gemeinsamen Dokumentenspeicher 35 oder in den Verkäuferdatenbanken 32 speichern je nachdem, ob es sich bei den Dokumenten um Standarddokumente oder Sonderdokumente laut der oben beschriebenen Definition handelt. Es wird die Annahme gemacht, dass bei dem zwischen Käufer 20a und Verkäufer 30a abgewickelten Geschäftsvorgang ein Standarddokument und ein Sonderdokument verwendet werden. Der GCD-Server 40 unterzieht diese Dokumente einer Analyse um festzustellen, ob es sich um Standarddokumente oder Sonderdokumente handelt. Der GCD- Server 40 gespeichert anschließend das Standarddokument im gemeinsamen Dokumentenspeicher 35 und das Sonderdokument in der mit dem Verkäufer 30a verbundenen Verkäuferdatenbank 32.
Die Standarddokumente und die Sonderdokumente könnten vertrauliche oder Wettbewerbsrelevante Angaben enthalten, einschließlich, aber nicht beschränkt auf, die Namen des am Geschäftsvorgang beteiligten Käufers 20 und Verkäufers 30, das gekaufte Produkt, die Kaufmenge sowie der Kaufpreis. Da die Dokumente im gemeinsamen Dokumentenspeicher 35 und Verkäuferdatenbanken 32 gespeichert werden, sind die Dokumente mit Hilfe des GCD-Verzeichnisses 42 auch anderen Käufern 20 und Verkäufern 30 zugänglich, so dass die vertraulichen Angaben des Käufers 20 und Verkäufers 30 geschützt werden müssen, bevor die Dokumente auch den anderen Käufern 20 und Verkäufern 30 frei zugänglich werden. Zu diesem Zweck verschlüsselt das Sicherheitsmodul 41 die Standarddokumente und Sonderdokumente (oder Teile dieser Dokumente, siehe Beschreibung weiter unten) im Laufe der Speicherung im gemeinsamen Dokumentenspeicher 3 S und Verkäuferdatenbanken 32. Die Käufer 20 und Verkäufer 30, mit denen die Dokumente verbunden sind, erhalten die erforderliche Zugriffsberechtigung zur Entschlüsselung der Dokumente, so dass die betreffenden Käufer 20 und Verkäufer 30 die vertrauliche Angaben enthaltenden Dokumente ganz einsehen können. Auf diese Weise kann ein Käufer 20 mit Hilfe des GCD-Verzeichnisses 42 nach sämtlichen Dokumenten, an denen Käufer 20 beteiligt war, suchen und diese einsehen; folglich wird dem E-Commerce-System 10 ein Dokumentspeicherungs- und Einsichtnahmeelement hinzugefügt. Die eigenen Dokumente eines Käufers oder Verkäufers (bei denen ein Käufer oder Verkäufer eine an der Dokumententstehung beteiligte Partei darstellt) können als Benutzerdokumente bezeichnet werden. Ein Käufer 20 und Verkäufer 30 wird typischerweise einen uneingeschränkten Zugang zu den eigenen Benutzerdokumenten haben. Beispielsweise sind die eigenen Dokumente von Käufer 20 Benutzerdokumente für Käufer 20 und Käufer 20 hat einen uneingeschränkten Zugang zu allen eigenen Dokumenten von Käufer 20, weil Käufer 20 an den Geschäftsvorgängen, bei denen diese Dokumente erstellt wurden, als Partei beteiligt war. Für alle anderen Käufer 20 stellen die Benutzerdokumente von Käufer 20 aber Drittparteidokumente dar, da diese anderen Käufer 20 an den Geschäftsvorgängen des Käufers 20 nicht als Partei beteiligt waren. Folglich besitzt jeder Käufer 20 eigene Benutzerdokumente, bei denen Käufer 20 am Geschäftsvorgang beteiligt war, und Käufer 20 besitzt die Berechtigung zum uneingeschränkten Zugriff auf und zur uneingeschränkten Einsichtnahme in die gesamten Benutzerdokumente. Falls Käufer 20 an einem Geschäftsvorgang aber nicht als Partei beteiligt war, werden die Dokumente des betreffenden Geschäftsvorgangs zu Drittparteidokumenten für den betreffenden Käufer 20 und der Käufer 20 besitzt keine Berechtigung zum uneingeschränkten Zugriff auf und zur uneingeschränkten Einsichtnahme in die gesamten Drittparteidokumente.
Nachdem die Dokumente im gemeinsamen Dokumentenspeicher 35 und/oder in den Verkäuferdatenbanken 32 gespeichert und (gänzlich oder teilweise) verschlüsselt worden sind, nimmt der GCD-Server 40 oder eine andere geeignete Komponente im GCD- Verzeichnis 42 eine Einordnung der Dokumente nach Dokumentklassen und nach Produktklassen vor, wie in Fig. 2 und Fig. 3 beschrieben ist. Die Einordnung der Dokumente in Dokumentklassen und Produktklassen ermöglicht den späteren Abruf der Dokumente durch Käufer 20 und Verkäufer 30. Der GCD-Server 40 untersucht die Dokumente zur Bestimmung des Dokumenttyps und zur Feststellung, zu welchen Produkten das Dokument einen Bezug besitzt. Der GCD-Server 40 assoziiert Zeiger mit den Dokumenten und dem GCD-Verzeichnis 42, so dass das GCD-Verzeichnis 42 die Dokumente im gemeinsamen Dokumentenspeicher 35 und den Verkäuferdatenbanken 32 finden kann, wenn Käufer 20 nach Dokumenten sucht. Ein Kaufauftrag des Käufers für Kugelschreiber könnte beispielsweise mit der Kugelschreiberdokumentklasse 63c in der Kugelschreiberklasse 82b in Verzeichnisstruktur 44 assoziiert sein und auch mit Kaufauftragdokumentklasse 86b in Verzeichnisstruktur 70.
Dass der Käufer 20 zur Einsichtnahme in Benutzerdokumente befähigt wird, erhöht die Funktionalität des Systems 10 und tilgt dem System 10 ein Dokumentspeicherungs- und ein Dokumentwiederverwendungselement hinzu. Allerdings muss unter diesen Umständen auch dafür gesorgt sein, dass Käufer 20 Benutzerdokumente speichern, darauf zugreifen und Einsicht nehmen kann, ohne dass andere Käufer 20 die in den Benutzerdokumenten enthaltenen vertraulichen oder Wettbewerbs-relevanten Angaben einsehen können. Wenn Käufer 20 auf Benutzerdokumente zugreift und Einsicht in diese Dokumente nehmen möchte, ermittelt das Sicherheitsmodul 41, ob Käufer 20 die erforderliche Zugriffsberechtigung zur Einsichtnahme in die Benutzerdokumente besitzt. In einer Ausführungsform kann das Sicherheitsmodul 41 bei der Verschlüsselung der Dokumente jedes Dokument mit einem Passwort schützen und die Angabe dieses Passworts zur Entschlüsselung verlangen. Wenn Käufer 20 Zugriff auf ein Benutzerdokument nehmen möchte, fordert das Sicherheitsmodul 41 den Käufer 20 mit einer Eingabeaufforderung zur Eingabe des korrekten Passwort für die Entschlüsselung auf. Da die Dokumente aber Benutzerdokumente des Käufers 20 darstellen, wird Käufer 20 die erforderliche Berechtigung und das korrekte Passwort besitzen. Bei Eingabe des korrekten Passworts durch den Käufer 20 erhält Käufer 20 einen uneingeschränkten Zugriff auf die gesamten Benutzerdokumente. Nachdem Käufer 20 einen uneingeschränkten Zugriff erhalten hat, kann Käufer 20 die Benutzerdokumente nach Zusammenfassungen früherer Einkaufsvorgänge durchsuchen, um zukünftige Bestellungen zu erleichtern, oder die Benutzerdokumente für die anstehenden Geschäftsvorgänge wiederverwenden oder modifizieren.
Entscheidet sich Käufer 20 für die Wiederverwendung eines Benutzerdokuments für den anstehenden Geschäftsvorgang, stehen dem Käufer 20 mehrere Optionen zur Verfügung. Falls Käufer 20 mit dem Produkt und dem Verkäufer eines früheren Geschäftsvorgangs zufrieden war, kann Käufer 20 das Intelligenzmodul 47 anweisen, das Dokument des früheren Geschäftsvorgangs zu erneut auszugeben, um genau denselben Auftrag an den selben Verkäufer zu vergeben. Das Intelligenzmodul 47 kann dann ermitteln, welche Abschnitte des Benutzerdokuments generisch und welche spezifisch für den früheren Geschäftsvorgang sind und kann automatisch alle Abschnitte des Dokuments aktualisieren, die aktualisiert werden müssen (beispielsweise der Datumsabschnitt). Nach der Aktualisierung wird das Dokument an den Verkäufer geschickt, womit der Geschäftsvorgang abgeschlossen ist. Falls Käufer 20 dagegen mit dem Verkäufer des früheren Geschäftsvorgangs nicht zufrieden war, kann Käufer 20 das Dokument des früheren Geschäftsvorgangs zwar verwenden, das Intelligenzmodul 47 aber damit beauftragen, die Verkäuferangaben zu ändern, generische Abschnitte, die möglicherweise aktualisiert werden müssen, zu aktualisieren und das Benutzerdokument an den neuen Verkäufer wieder auszugeben. Durch diese Wiederausgabe von Dokumenten wird der Käufer 20 in die Lage versetzt, Bestellungen und somit Geschäftsvorgänge zu beschleunigen, da Käufer 20 keine Zeit mit der Wiedereingabe von Angaben in die Dokumente verschwendet.
Dass der Käufers 20 nur auf Benutzerdokumente Zugriff erhält, bedeutet eine Einschränkung der Funktionalität und Nutzeffekts des Systems 10 und würde einem erstmals im System 10 tätigen Käufer 20 die Vorteile der Dokumentspeicherungs- und -Dokumentwiederverwendungsfunktion vorenthalten, da dieser Käufer 20 keine Benutzerdokumente wieder verwenden könnte. Daher ist es wünschenswert, eine Möglichkeit für den Zugriff und die Einsichtnahme von Käufer 20 und Verkäufer 30 in Drittparteidokumente zu bieten, während der Schutz der vertraulichen Angaben in den Dokumenten gewährleistet bleibt. Das Intelligenzmodul 47 ermöglicht Käufern 20 und Verkäufern 30 den Zugriff und die Einsichtnahme in Drittparteidokumente, während der Schutz der vertraulichen oder Wettbewerbs-relevanten Angaben in den Dokumenten gewährleistet bleibt. Intelligenzmodul 47 zerlegt die Drittparteidokumente in einen oder mehrere Abschnitte und erstellt auf diese Weise generische Dokumente aus den Drittparteidokumenten. Die generischen Dokumente ermöglichen Käufern 20 einen eingeschränkten Zugriff auf Drittparteidokumente. Bei der Erstellung der generischen Dokumente untersucht das Intelligenzmodul 47 ein Drittparteidokument und entfernt oder verschlüsselt die Angaben aus den Abschnitten mit vertraulichen Angaben sowie die für einen bestimmten Geschäftsvorgang spezifischen Abschnitte.
Beispielweise soll davon ausgegangen werden, dass Käufer 20b Kugelschreiber mit blauer Tinte kaufen möchte und mit Hilfe des GCD-Verzeichnisses 42 eine Suche nach Dokumenten mit einem Bezug zu Kugelschreibern mit blauer Tinte durchführt. Diese Suche könnte mehrere Dokumente ergeben, die den Suchkriterien entsprechen, wobei eines dieser Dokumente aus einem Geschäftsvorgang zwischen Käufer 20a und Verkäufer 30a stammt. Käufer 20b wird nicht erkennen können, dass das Dokument Käufer 20a und Verkäufer 30a betrifft, sondern stattdessen nur sehen, dass es sich um ein Drittparteidokument handelt. Käufer 20b erfährt nicht, um wen es sich bei Käufer 20a und Verkäufer 30a handelt. Für Käufer 20b handelt es sich hierbei um ein Drittparteidokument, da Käufer 20b an dem Geschäftsvorgang nicht als Partei beteiligt war. Käufer 20b wird also nicht erfahren, dass der Geschäftsvorgang von Käufer 20a und Verkäufer 30a abgewickelt wurde, sondern nur, dass es sich um einen Geschäftsvorgang zwischen einem Käufer und einem Verkäufer handelt, bei denen es sich nicht um Käufer 20b handelt.
Das Intelligenzmodule 47 kann die Drittparteidokumente in Abschnitte, z. B. Kopfzeilen, Fußzeilen, Kontaktinformationen für den Käufer, Kontaktinformationen für den Verkäufer, Datum, Bestellmenge, Kaufpreis, Subjekt, Beschreibung, Vertragsbedingungen und beliebige andere geeignete Abschnitte zerlegen. Außerdem kann das Intelligenzmodule 47 ermitteln, welche Abschnitte genetisch sind und welche Abschnitte spezifisch für einen Geschäftsvorgang zwischen Käufer 20a und Verkäufer 30a sind oder Käufer 20a und/oder Verkäufer 30a können die genetischen Abschnitte angeben oder die genetischen Abschnitte können auf eine andere geeignete Weise ermittelt werden. Zur Erstellung des genetischen Dokuments entfernt das Intelligenzmodul 47 diejenigen Angaben aus dem Drittparteidokument, die entweder spezifisch für den Geschäftsvorgang zwischen Käufer 20a und Verkäufer 30a sind oder von Käufer 20a oder Verkäufer 30a als vertraulich angesehen werden, lässt aber die Angaben über den Geschäftsvorgang in den generischen Abschnitten im Dokument. Beispielweise kann das Intelligenzmodul 47 bei der Erstellung des generischen Dokuments den Namen und die Kontaktangaben des Käufers 20a und Verkäufers 30a sowie die Bestellmengen und den Kaufpreis entfernen, ohne aber diese Abschnitte aus dem generischen Dokument zu entfernen, so dass Käufer 20b an diesen Stellen die eigenen Angaben eingeben kann. Die Abschnitte und Angaben für die Kopfzeilen, Fußzeilen, Produktbeschreibung und Vertragsbedingungen werden vom Intelligenzmodul 47 nicht aus dem generischen Dokument entfernt. Als eine Alternative zur Entfernung von vertraulichen Angaben kann das Intelligenzmodul Informationen dieser Art auch verschlüsseln. Das Intelligenzmodul 47 kann auch den Datumsabschnitt im generischen Dokument dynamisch mit aktuellen Datumsangaben aktualisieren. Das Intelligenzmodul 47 kann außerdem auch andere Angaben im generischen Dokument automatisch und dynamisch aktualisieren, zum Beispiel die Namen von Käufer und Verkäufer und die Kontaktangaben, falls Käufer 20b ein registrierter Benutzer des Systems 10 ist und diese Angaben dem Intelligenzmodul 47 zur Verfügung stehen. Zur Vervollständigung des generischen Dokuments müssen der Käufer 20b oder der Verkäufer 30 möglicherweise einige der Informationen manuell eingeben, z. B. die gewünschte Bestellmenge und den Kaufpreis. Sobald das generische Dokument vollständig ist, kann Käufer 20b das Dokument zur Abwicklung des Geschäftsvorgangs benutzen.
Möglicherweise möchte ein Käufer 20 bei nachfolgenden Geschäftsvorgängen nach bestimmten Dokumenten suchen. Dazu kann Käufer 20 auf GCD-Schnittstelle 43 zugreifen und mit Hilfe des GCD-Verzeichnisses 42 der gemeinsame Dokumentenspeicher 35 und/oder eine oder mehrere Verkäuferdatenbanken durchsuchen. Die GCD-Schnittstelle 43 kann es dem Käufer 20 ermöglichen, sowohl durch die Produktklassen als auch durch die Dokumentklassen des GCD-Verzeichnisses 42 zu navigieren (im Sinne des "Browsers") als auch eine Suche nach einer bestimmten Klasse oder bestimmten Klassen durchzuführen. Beispielsweise könnte Käufer 20 entweder durch die Produktklassen des GCD- Verzeichnisses 42 navigieren, um Dokumente mit einem Bezug zu einem bestimmten Produkt zu finden, oder Käufer 20 könnte die Dokumentklassen des GCD-Verzeichnisses 42 nach einem bestimmten Dokumenttyp durchsuchen. Es können aber auch alle anderen geeigneten Verfahren zum Finden eines bestimmten Dokuments benutzt werden. Nachdem Käufer 20 die entsprechende Klasse für das gewünschte Dokument gefunden hat, kann Käufer 20 eine Liste von Dokumenten in dieser Klasse abfragen, die gewissen Produkt- und/oder Dokumentattributwerten entsprechen. Käufer 20 erhält dabei einen uneingeschränkten Zugriff auf alle Benutzerdokumente und einen eingeschränkten Zugriff auf alle Drittparteidokumente (als genetische Dokumente). Käufer 20 kann die Suchschnittstelle 45 auf die für die Produktsuche beschriebene Weise auch zur Suche nach Dokumenten verwenden.
Eine solche Abfrage könnte durch eine Suchschnittstelle 45 oder jede sonstige geeignete Komponente des GCD-Servers 40 ermöglicht werden, indem eine Suche im gemeinsamen Dokumentenspeicher 35 und/oder Verkäuferdatenbanken 32 durchgeführt oder angefordert wird, die durch einen oder mehrere mit den Dokumenten assoziierte Zeiger zu erkennen gegeben wird oder werden, wie oben bereits beschrieben wurde. Die Suchschnittstelle 45 könnte dem Käufer 20 ein Suchformular bieten, in das ein oder mehrere Suchkriterien für die gewünschten Dokumente eingegeben werden. Entweder können die zulässigen Suchkriterientypen im Suchformular genannt werden oder es kann dem Käufer 20 erlaubt sein, mit bestimmten Begriffen eine allgemeine Suche in den Verkäuferdatenbanken 32 und/oder dem gemeinsamen Dokumentenspeicher 35 durchzuführen. Beispielsweise könnte Suchschnittstelle 45 dem Käufer 20 ein auf die Klasse 82b zugeschnittenes Suchformular bieten, das Felder enthält, in denen der Käufer 20 gewünschte Dokumentbezogene Kriterien angeben kann. Anstelle eines Suchformulars könnte Suchschnittstelle 45 aber auch ein einzelnes Feld bieten, in das der Käufer gewünschte Suchbegriffe eingeben kann, zum Beispiel "Angebotsanfrage" und "Kugelschreiber" (die Eingabe von mehreren Suchbegriffen kann mit Hilfe von Booleschen Operatoren oder mit jeder beliebigen anderen geeigneten Technik erfolgen).
Basierend auf den vom Käufer 20 oder automatisch erzeugten und vorgegeben Suchkriterien kann Suchschnittstelle 45 eine Suchanfrage an die geeignete(n) Verkäuferdatenbank(en) 32 und/oder der gemeinsame Dokumentenspeicher 35 übermitteln und verlangen, dass die Datenbanken 32 und der gemeinsame Dokumentenspeicher 35jeweils eine Liste aller Dokumente ausgeben, die den Suchkriterien entsprechen. Die Antworten auf die Suchanfragen für die Datenbanken 32 und/oder den gemeinsame Dokumentenspeicher 35 können dem Käufer 20 auf jede beliebige geeignete Weise angezeigt werden. Beispielsweise könnten die Dokumente in der Reihenfolge ihrer Relevanz zu den Suchkriterien, die durch beliebige geeignete Vergleichskriterien ermittelt wird, aufgelistet werden. Weiterhin kann das GCD-Verzeichnis 42 die aufgelisteten Dokumente auf Wunsch des Käufers 20 neu ordnen. Beispielsweise könnte Käufer 20 wünschen, dass bei der Auflistung der entsprechenden Dokumente zuerst die Benutzerdokumente aufgelistet werden und anschließend die Drittparteidokumente oder erst die Standarddokumente und anschließend die Sonderdokumente. Als Alternative können die Suchergebnisse von den Datenbanken 32 und/oder dem gemeinsamen Dokumentenspeicher 35 direkt an den Käufer 20 übermittelt werden.
Aus der Dokumentliste kann Käufer 20 ein Dokument auswählen und damit anzeigen, dass Käufer 20 dieses Dokument bei einem Geschäftsvorgang zu benutzen wünscht. Handelt es sich bei dem Dokument um ein Benutzerdokument, besitzt Käufer 20 die erforderliche Zugriffsberechtigung zur Entschlüsselung und Einsichtnahme in das gesamte Dokument und kann das Dokument anschließend für die Verwendung bei dem anstehenden Geschäftsvorgang modifizieren. Handelt es sich bei dem Dokument um ein Drittparteidokument, wird Käufer 20 Einsicht in das aus dem Drittparteidokument erstellte generische Dokument oder die unverschlüsselten Abschnitte des Drittparteidokuments nehmen, ohne einen Zugang zu den vertraulichen Angaben im Drittparteidokument zu erhalten. Anschließend kann Käufer 20 das Dokument vervollständigen oder aktualisieren und den Geschäftsvorgang abwickeln.
In den Fig. 6A und6B wird eine Beispielsverfahren für die Speicherung, Klassifizierung (Einordnung) und Wiederverwendung von Dokumenten mit Hilfe des GCD-Verzeichnisses 42 erläutert. Das Verfahren beginnt bei Schritt 102, an dem das Sicherheitsmodul 41 die Dokumente verschlüsselt, um den Zugang zu den Dokumenten einer Kontrolle unterwerfen zu können und alle vertraulichen oder Wettbewerbs-relevanten Angaben in den Dokumenten zu schützen und somit einem Käufer 20, der an dem Geschäftsvorgang, aus dem das Dokument stammt, nicht als Partei teilgenommen hat, den Zugang zu und die Einsichtnahme in die vertraulichen Angaben im Dokument zu verwehren. Bei der Verschlüsselung der Dokumente wird jedem verschlüsselten Dokument eine Zugriffsberechtigung zugeordnet, so dass ein Käufer 20 mit der erforderlichen Zugriffsberechtigung das Dokument entschlüsseln kann und Einsicht in das gesamte Dokument nehmen kann. Ein Käufer 20 erhält die erforderliche Zugriffsberechtigung für alle Dokumente, an deren Geschäftsvorgängen Käufer 20 als Partei beteiligt war. Folglich wird ein Käufer 20 die erforderliche Zugriffsberechtigung zum Zugriff und zur uneingeschränkten Einsichtnahme in alle Benutzerdokumente des betreffenden Käufers 20 besitzen. Der GCD-Server 40 gespeichert die Dokumente in Schritt 104 in einem oder mehreren Dokumentenspeichern. Beispielsweise könnte GCD-Server 40 die Standarddokumente im gemeinsamen Dokumentenspeicher 35 und die Sonderdokumente in einer oder mehreren Verkäuferdatenbanken speichern. Außerdem könnte ein Käufer 20 oder Verkäufer 30 ausschließlich Standarddokumente verwenden oder ausschließlich Sonderdokumente verwenden oder die Dokumente könnten keine solche Unterscheidung enthalten und lediglich als Dokumente gespeichert sein.
In Schritt 106 werden die Dokumente von GCD-Server 40 mit einer Vielzahl von Produktklassen assoziiert und in diese eingeordnet. Die Einordnung der Dokumente in Produktklassen ermöglicht es dem Käufer 20, nach Dokumenten mit einem Bezug zu bestimmten Produkten zu suchen und diese zu finden oder bei einer Suche nach einem bestimmten Produkt nach Dokumenten für ein bestimmtes Produkt zu suchen und diese zu finden. Bei der Suche nach einem bestimmten Produkt kann Käufer 20 durch das GCD- Verzeichnis 42 navigieren und, wenn das Produkt ausfindig gemacht ist, nach Dokumenten mit einem Bezug zu dem Produkt suchen, diese finden und einsehen. Beispielsweise könnte der GCD-Server 40 ein Kaufauftragsdokument für Filzstifte mit der Filzstiftdokumentklasse 63b und der Stiftdokumentklasse 59 assoziieren und in diese Klassen einordnen. Falls Käufer 20 Filzstifte kaufen möchte, ist es Käufer 20 eine leichtes, die Dokumente mit einem Bezug zu Filzstiften zu finden.
In Schritt 108 werden die Dokumente von GCD-Server 40 mit einer Vielzahl von Dokumentklassen assoziiert und in diese eingeordnet. Die Einordnung der Dokumente in Dokumentklassen ermöglicht es dem Käufer 20, ausschließlich nach Dokumenten zu suchen, unabhängig von jedem Bezug zu bestimmten Produkten. Beispielsweise könnte der GCD-Server 40 die aus der Sichtweise des Käufers erstellten Kaufaufträge für Filzstifte mit Käufer-Kaufauftragdokumentklasse 82b und Kaufauftragdokumentklasse 86b assoziieren und in diese Klassen einordnen. Dies ermöglicht dem Käufer 20 die Suche nach und das Ausfindigmachen von Dokumenten ausschließlich auf der Grundlage des Dokumenttyps, im Gegensatz zum Ausfindigmachen eines Dokuments basierend auf dem Produktbezug des Dokuments. Die in den Schritten 106 und 108 erfolgende Einordnung der Standarddokumente und Sonderdokumente in Produktklassen und Dokumentklassen beinhaltet außerdem die Assoziierung von Zeigern mit den Klassen im GCD-Verzeichnis 42, wobei die Zeiger Dokumente zu erkennen geben, die im gemeinsamen Dokumentenspeicher 35 und/oder in den Verkäuferdatenbanken 32 gespeichert sind, und wobei die Zeiger den Käufer 20 zu den gewünschten Dokumenten leiten. Außerdem kann aber auch nur einer der Schritte 106 und 108 durchgeführt werden, je nachdem wie die Speicherung und Einordnung der Dokumente vorgenommen wird.
Nach der Speicherung und Einordnung der Dokumente wird das Verfahren mit Schritt 110 fortgesetzt, in dem Käufer 20 mit Hilfe der GCD-Schnittstelle 43 auf das GCD-Verzeichnis 42 zugreift, um eine Suche nach bestimmten Dokumenten durchzuführen. Wie bereits beschrieben, kann Käufer 20 einen Webbrowser oder jede beliebige andere Verfahren für diesen Zweck einsetzen. Der Käufer 20 navigiert in Schritt 112 durch die Verzeichnisstruktur 44 oder 70 bis zu einer Produkt- oder Dokumentklasse oder durchsucht die Verzeichnisstruktur 44 oder 70 nach einer Produkt- oder Dokumentklasse mit einer ausreichend hohen Spezifität für den Käufer 20 (und/oder eine Klasse am Ende eines Zweiges), auf die oben beschriebene Weise. In Schritt 114 wählt Käufer 20 eine gewünschte Klasse aus. Nach der Auswahl einer Klasse erhält der Käufer 20 in Schritt 116 eine Eingabeaufforderung zur Eingabe von Suchkriterien für ein gewünschtes Produkt und/oder ein gewünschtes Dokument. Beispielsweise kann der GCD-Server 40 dem Käufer 20 ein Suchformular für die Eingabe von einem oder mehreren Suchkriterien bieten oder ein einzelnes Feld, in das Käufer 20 die gewünschten Suchkriterien eintragen kann. Auch nach der Eingabe einer Suche nach einem bestimmten Produkt bleibt Käufer 20 in der Lage, Dokumente mit einem Bezug zu diesem bestimmten Produkt abzurufen. Folglich ist es nicht erforderlich, dass Käufer 20 eine spezielle Suche nach Dokumenten durchführt.
Falls Käufer 20 sich beispielweise für Stifte interessiert, kann Käufer 20 die Produktklassen nach Stiften durchsuchen und der GCD-Server 40 oder eine andere geeignete Komponente kann aus den Dokumentklassen für Stifte Dokumente mit einem Bezug zu Stiften abrufen. Die Dokumente mit einem solchen Bezug können dem Käufer 20 angezeigt werden, nachdem Käufer 20 ein bestimmtes Produkt ausgewählt und eine Suche nach diesem Produkt durchgeführt hat.
Anhand der von Käufer 20 vorgegebenen oder auf andere Weise erzeugten Suchkriterien kann die Schnittstelle 45 in Schritt 118 im gemeinsamen Dokumentenspeicher 35 und/oder einer oder mehreren Verkäuferdatenbanken 32, die von Zeigern in der vom Käufer 20 ausgewählten Klasse zu erkennen gegeben werden, nach Dokumenten suchen, die den Suchkriterien entsprechen. Diese Suche kann die Schnittstelle 45 kann auf jede beliebige geeignete Weise durchführen. Beispielsweise könnte der GCD-Server 40 basierend auf einem mit einer Klasse assoziierten Zeiger zunächst den gemeinsame Dokumentenspeicher 35 oder einen (vom Zeiger zu erkennen gegebenen) Teil des gemeinsamen Dokumentenspeichers 35 nach Standarddokumenten durchsuchen, die den Suchkriterien entsprechen, und anschließend ein oder mehrere Verkäuferdatenbanken 32 (die von dem selben Zeiger oder einem assoziierten Zeiger zu erkennen gegeben werden) nach Sonderdokumenten durchsuchen. Beispielsweise könnte das Standarddokument im gemeinsamen Dokumentenspeicher 35 einen Zeiger zu allen Verkäuferdatenbanken 32 aufweisen, die Sonderdokumente bieten, die das Standarddokument näher erläutern oder es erweitern. Als Alternative kann diese Suche auch in der umgekehrten Reihenfolge oder mit beliebigen anderen geeigneten Techniken durchgeführt werden. Die auf diese Weise erhaltenen Standard- und/oder Sonderdokumente aus dem gemeinsamen Dokumentenspeicher 35 und/oder den Verkäuferdatenbanken 32 können gemeinsam aufgelistet und einem Käufer 20 als einheitlicher Satz von Suchergebnissen angezeigt werden. In Schritt 120 präsentiert der GCD-Server 40 dem Käufer 20 die Sucherergebnisse, die aus einer Liste mit einem oder mehreren Dokumenten bestehen, die den Suchkriterien entsprechen (oder teilweise entsprechen).
Nachdem der GCD-Server 40 die den Suchkriterien entsprechenden Ergebnisse präsentiert hat, untersucht Käufer 20 in Schritt 122 die Ergebnisse und wählt aus den Suchergebnissen ein Dokument aus. Falls Käufer 20 dabei ein Drittparteidokument auswählt, besitzt Käufer 20 nicht die erforderliche Zugriffsberechtigung zur Entschlüsselung des Drittparteidokuments. Daher wird das Intelligenzmodul 47 zum Schutz der vertraulichen Angaben in diesem Drittparteidokument in Schritt 124 ein generisches Dokument aus dem Drittparteidokument erstellen, so dass Käufer 20 die generische Dokumentversion des ausgewählten Drittparteidokuments einsehen und modifizieren kann. Zur Erstellung des generischen Dokuments wird zunächst das Drittparteidokument in Abschnitte zerlegt. Nach der Zerlegung in Abschnitte untersucht das Intelligenzmodul 47 die Abschnitte des Drittparteidokuments um festzustellen, welche Abschnitte generisch und welche Abschnitte spezifisch für einen bestimmten früheren Geschäftsvorgang sind und welche Abschnitte vertrauliche Angaben enthalten. Bei generischen Abschnitten kann es sich um Kopfzeilen, Fußzeilen, Datumsangaben, Produkttypen und Produktbeschreibungen handeln, ohne auf diese beschränkt zu sein. Diese Abschnitte werden als generisch angesehen, da sie im allgemeinen in allen Dokumenten dieses Typs vorhanden sein müssen und außerdem keine vertraulichen oder Wettbewerbs-relevanten Informationen mit einem Bezug zu dem Käufer oder Verkäufer enthalten, die Originalparteien des Dokuments waren. Bei den Abschnitten, die als spezifisch für einen bestimmten Geschäftsvorgang und/oder vertraulich angesehen werden, kann es sich um den Käufernamen, Verkäufernamen, die Kaufmenge und den Kaufpreis des Produkts handeln, ohne auf diese beschränkt zu sein. Diese Abschnitte werden als spezifisch für einen bestimmten Geschäftsvorgang und/oder vertraulich angesehen, da der Käufer möglicherweise andere Käufer 20 nicht wissen lassen möchte, bei welchem Verkäufer 30 Käufer 20 seine Käufe tätigt, welche Produkte gekauft werden, wie viel gekauft wird und wie hoch der Kaufpreis ist.
Das Intelligenzmodule 47 kann die Angaben aus den für einen bestimmten Geschäftsvorgang spezifischen Abschnitten entfernen und die Angaben in den generischen Abschnitten weiter benutzen. Das Intelligenzmodule 47 kann die für einen bestimmten Geschäftsvorgang spezifischen Abschnitte weiter benutzen, diese Abschnitte aber unvollständig lassen, so dass Käufer 20 an diesen Stellen die Angaben für Käufer 20 eintragen kann. In Schritt 126 passt das Intelligenzmodul 47 auf dynamische Weise die generischen Abschnitte mit aktuellen Angaben an, wie zum Beispiel Datum und Name des Käufers 20 und Kontaktinformationen für den Käufer 20. Durch die dynamische Anpassung der generischen Dokumente muss der Käufer 20 das aktuelle Datum und den Namen und die Kontaktinformationen für den Käufer 20 nicht selbst eingeben. Folglich kann Käufer 20 den Geschäftsvorgang schneller und mit einem geringeren Aufwand beim Vervollständigen des generischen Dokuments abwickeln. Als Alternative kann Käufer 20 das Drittparteidokument in einer Form erhalten, in der alle vertraulichen Angaben entfernt sind, aber keine Aktualisierung erfolgt ist, und daher kann Käufer 20 das Dokument aktualisieren und vervollständigen. Nach der dynamischen Aktualisierung des generischen Dokuments und dem Entfernen aller vertraulichen Angaben aus dem generischen Dokument nimmt Käufer 20 in Schritt 128 Einsicht in das generische Dokument und vervollständigt das generische Dokument durch Einfügen von Angaben, wie gewünschte Menge und Kaufpreis. Nach der Vervollständigung des generischen Dokuments kann Käufer 20 das Dokument zur Abwicklung eines Geschäftsvorgangs benutzen. In Schritt 130 speichert der GCD-Server 40 das Dokument entweder als Standarddokument oder als Sonderdokument, so dass andere Käufer 20 es zukünftig benutzen können und das modifizierte generische Dokument wird zu einem Benutzerdokument des Käufers 20.
Falls Käufer 20 in Schritt 122 ein Benutzerdokument auswählt, sollte Käufer 20 die erforderliche Zugriffsberechtigung zur Entschlüsselung des Benutzerdokuments besitzen, weil ein Benutzerdokument definitionsgemäß ein Eigendokument des Käufers 20 darstellt und Käufer 20 daher die erforderliche Zugriffsberechtigung besitzt. In Schritt 132 besorgt sich das Sicherheitsmodul 41 das zur Entschlüsselung erforderliche Passwort oder andere Informationen von Käufer 20 und entschlüsselt das Dokument. In Schritt 134 entscheidet der Käufer 20, ob das Benutzerdokument für einen anstehenden Geschäftsvorgang wieder ausgegeben werden soll oder einfach nur Einsicht in das Dokument genommen werden soll. Entscheidet sich Käufer 20 zur Einsichtnahme in das Benutzerdokument, wird Käufer 20 in Schritt 136 Einsicht in das Benutzerdokument aus einem früheren Geschäftsvorgang nehmen. Typischerweise wird Käufer 20 Einsicht in ein Benutzerdokument nehmen, um Informationen über frühere Geschäftsvorgänge zu sammeln, die Bestellgeschichte einzusehen, um zu ermitteln, wann ein neuer Geschäftsvorgang einzuleiten ist, oder aus jedem beliebigen anderen angemessenen Beweggrund für die Einsichtnahme in das Benutzerdokument. Durch die Einsichtnahme in das Benutzerdokument könnte Käufer 20 in Erfahrung bringen, wann die früheren Bestellungen bestellt wurden, welche Vertragsbedingungen bei früheren Bestellungen galten und wann der beste Zeitpunkt für eine Nachbestellung gekommen ist.
Falls Käufer 20 in Schritt 134 die Entscheidung trifft, das Benutzerdokument für einen neuen Geschäftsvorgang wieder auszugeben, dann kann das Intelligenzmodul 47 in Schritt 138 das mit aktuellen Informationen, wie dem aktuellen Datum, aktualisierte Benutzerdokument wieder ausgeben. Bei der Wiederausgabe des Benutzerdokuments kann das Intelligenzmodul 47 feststellen, welche Abschnitte des Dokuments generisch und welche spezifisch für einen früheren Geschäftsvorgang sind. Das Intelligenzmodul 47 kann außerdem das wieder ausgegebene Benutzerdokument mit neuen Angaben über den Verkäufer 30 aktualisieren, falls Käufer 20 die Entscheidung trifft, bei dem anstehenden Geschäftsvorgang den Verkäufer 30 zu wechseln. In Schritt 140 nimmt Käufer 20 Einsicht in das wieder ausgegebene Benutzerdokument und vervollständigt alle vom Intelligenzmodul 47 nicht aktualisierten Abschnitte und verändert alle Abschnitte, die Käufer 20 verändern möchte. Der GCD-Server 40 speichert das wieder ausgegebene Benutzerdokument im letzten Schritt dieses Verfahren als ein Standard- oder Sonderdokument je nachdem, ob das wieder ausgegebene Benutzerdokument in Schritt 142 ein Standardformat besitzt.
Das in den Fig. 6A und 6B diskutierte Verfahren ist lediglich eine Beispielverfahren für die Speicherung, Einordnung und Wiederverwendung von Dokumenten durch Käufer 20 und/oder Verkäufer 30. Die Schritte können in anderer Reihenfolge durchgeführt werden und gewisse Schritte können auch ausgelassen werden.
Zwar wurde die vorliegende Erfindung anhand von mehreren Ausführungsformen beschrieben, doch sind für den Fachmann auf diesem Gebiet verschiedene Änderungen, Substitutionen, Variationen, Veränderungen und Modifikationen leicht ersichtlich, und diese Änderungen, Substitutionen, Variationen, Veränderungen und Modifikationen, insofern sie dem Geist und dem Gültigkeitsbereich der Ansprüche im Anhang entsprechen, werden hiermit ebenfalls beansprucht.

Claims

1. Ein elektronisches Handelssystem für die Wiederverwendung von Geschäftsdokumenten, bestehend aus:
einem oder mehreren Dokumentenspeichern für die Speicherung einer Vielzahl von Geschäftsdokumenten,
einem globalen Inhaltsverzeichnis, das eine Vielzahl von hierarchisch organisierten Klassen enthält, wobei die Geschäftsdokumente in die Klassen eingeordnet sind und jede Klasse mit einem oder mehreren Attributen des in der jeweiligen Klasse eingeordneten Dokuments assoziiert ist und mindestens eine der Klassen einen oder mehrere assoziierte Zeiger besitzt, die einen oder mehrere Dokumentenspeicher zu erkennen geben,
ein Intelligenzmodul, mit dem ein oder mehrere generische Dokumente aus dem einen oder den mehreren Geschäftsdokumenten erstellt werden können,
eine Suchschnittstelle zur Übermittlung einer die Geschäftsdokumente betreffenden Suchanfrage an einen oder mehrere Dokumentenspeicher, die von Zeigern, die mit einer oder mehreren der Klassen assoziiert sind, zu erkennen gegeben werden.

2. System nach Anspruch 1, wobei die Geschäftsdokumente aus Drittparteidokumenten bestehen.

3. System nach Anspruch 1, wobei die Klassen aus einer Vielzahl von Dokumentklassen bestehen.

4. System nach Anspruch 1, wobei die Klassen aus einer Vielzahl von Produktklassen bestehen.

5. System nach Anspruch 1, wobei das Intelligenzmodul:
die Geschäftsdokumente in einen oder mehrere Abschnitte zerlegt, feststellt, welche Abschnitte der Geschäftsdokumente generisch und welche Abschnitte spezifisch für einen bestimmten Geschäftsvorgang sind und
Angaben aus den für einen bestimmten Geschäftsvorgang spezifischen Abschnitten der Geschäftsdokumente entfernt.

6. System nach Anspruch 1, wobei die Suchschnittstelle es einem Benutzer außerdem ermöglicht, zur Suche nach einem bestimmten Geschäftsdokument durch die Klassen zu navigieren.

7. Das System nach Anspruch 1, wobei das Intelligenzmodul außerdem die Angaben in den Abschnitten der generischen Dokumente durch das Einfügen aktueller Angaben dynamisch anpasst.

8. System nach Anspruch 1, wobei die Suchschnittstelle außerdem einem Benutzer die Einsichtnahme in die generischen Dokumente ermöglicht.

9. System nach Anspruch 1, weiterhin bestehend aus einem mit dem globalen Inhaltsverzeichnis assoziierten Sicherheitsmodul, mit dem die Geschäftsdokumente verschlüsselt werden können, um den Zugang von Benutzern zu den Dokumenten einer Kontrolle zu unterwerfen.

10. Das System nach Anspruch 1, wobei die Dokumente aus einem oder mehreren Standarddokumenten bestehen, die in einem gemeinsamen Dokumentenspeicher gespeichert sind.

11. System aus Anspruch 1, wobei die Dokumente aus einem oder mehreren Sonderdokumenten bestehen, die in einer oder mehreren Verkäuferdatenbanken gespeichert sind.

12. Ein Verfahren für die Speicherung und Wiederverwendung von Geschäftsdokumenten, bestehend aus:
der Speicherung einer Vielzahl von Geschäftsdokumenten in einem oder mehreren Dokumentenspeichern,
der Assoziierung der Geschäftsdokumente mit einem globalen Inhaltsverzeichnis, das eine Vielzahl von hierarchisch organisierten Klassen enthält, wobei die Geschäftsdokumente in die Klassen eingeordnet sind und jede Klasse mit einem oder mehreren, in der jeweiligen Klasse eingeordneten Dokumenten assoziiert ist und mindestens eine der Klassen einen oder mehrere assoziierte Zeiger besitzt, die einen oder mehrere Dokumentenspeicher zu erkennen geben,
der Suche nach bestimmten Geschäftsdokumenten durch Navigieren durch die Klassen und der Erstellung von einem oder mehreren generischen Dokumenten aus einem oder mehreren Geschäftsdokumenten.

13. Verfahren nach Anspruch 12, wobei die Geschäftsdokumente aus Drittparteidokumenten bestehen.

14. Verfahren nach Anspruch 12, wobei die Klassen aus einer Vielzahl von Produktklassen bestehen.

15. Verfahren nach Anspruch 12, wobei die Klassen aus einer Vielzahl von Dokumentklassen bestehen.

16. Verfahren nach Anspruch 12, wobei die Erstellung von generischen Dokumenten besteht aus der:
Zerlegung der Geschäftsdokumente in einen oder mehrere Abschnitte,
Ermittlung, welche Abschnitte der Geschäftsdokumente generisch und welche Abschnitte spezifisch für einen bestimmten Geschäftsvorgang sind,
Entfernung von Angaben aus den für einen bestimmten Geschäftsvorgang spezifischen Abschnitten der Geschäftsdokumente und
Weiterverwendung der generischen Abschnitte der Geschäftsdokumente in den generischen Dokumenten zum Schutz einer oder mehrerer vertraulicher Einzelheiten in den Geschäftsdokumenten.

17. Verfahren nach Anspruch 12, weiterhin bestehend aus einer Zugriffsverweigerung zu den Geschäftsdokumenten, wenn ein Benutzer nicht die erforderliche Zugriffsberechtigung besitzt.

18. Verfahren nach Anspruch 12, weiterhin bestehend aus einer dynamischen Anpassung der generischen Dokumente anhand von aktuellen Angaben.

19. Verfahren nach Anspruch 12, weiterhin bestehend aus der:
Auswahl eines Geschäftsdokuments aus den mit Hilfe der Suchschnittestelle ausfindig gemachten Geschäftsdokumenten,
Einsichtnahme in das aus dem Geschäftsdokument erstellte generische Dokument und
Vervollständigung des generischen Dokuments mit einer Vielzahl von benutzerspezifischen Angaben.

20. Software für die Speicherung und Wiederverwendung von Geschäftsdokumenten, wobei die Software in oder auf einem Computerlesbaren Medium verkörpert ist und die Anwendung der Software dient zur:
Speicherung einer Vielzahl von Geschäftsdokumenten in einem oder mehreren Dokumentenspeichern,
Assoziierung der Geschäftsdokumente mit einem globalen Inhaltsverzeichnis, das eine Vielzahl von hierarchisch organisierten Klassen enthält, wobei die Geschäftsdokumente in die Klassen eingeordnet sind und jede Klasse mit einem oder mehreren, in der jeweiligen Klasse eingeordneten Dokumenten assoziiert ist,
Suche nach bestimmten Geschäftsdokumenten durch Navigieren durch die Klassen und
Erstellung eines oder mehrerer generischer Dokumente aus einem oder mehreren Geschäftsdokumenten.

21. Software nach Anspruch 20, wobei die Geschäftsdokumente aus Drittparteidokumenten bestehen.

22. Software nach Anspruch 20, wobei die Klassen aus einer Vielzahl von Produktklassen bestehen.

23. Software nach Anspruch 20, wobei die Klassen aus einer Vielzahl von Dokumentklassen bestehen.

24. Software nach Anspruch 20, wobei die Erstellung der generischen Dokumente dient zur:
Zerlegung der Geschäftsdokumente in einen oder mehrere Abschnitte,
Ermittlung, welche Abschnitte der Geschäftsdokumente generisch und welche Abschnitte spezifisch für einen bestimmten Geschäftsvorgang sind,
Entfernung von Angaben aus den für einen bestimmten Geschäftsvorgang spezifischen Abschnitten der Geschäftsdokumente und
Weiterverwendung der generischen Abschnitte der Geschäftsdokumente in generischen Dokumenten zum Schutz einer oder mehrerer vertraulicher Einzelheiten in den Geschäftsdokumenten.

25. Software nach Anspruch 20, durch deren Anwendung der Zugang zu den Geschäftsdokumenten verweigert werden kann, wenn ein Benutzer nicht die erforderliche Zugriffsberechtigung besitzt.

26. Software nach Anspruch 20, durch deren Anwendung außerdem die generischen Dokumenten auf dynamische Weise mit aktuellen Angaben angepasst werden können.

27. Software nach Anspruch 20, durch deren Anwendung außerdem:
ein Geschäftsdokument aus den mit Hilfe der Suchschnittestelle gefundenen Geschäftsdokumenten ausgewählt werden kann,
die Einsichtnahme in das aus dem Geschäftsdokument erstellte generische Dokument erfolgen kann und
das generische Dokument mit einer Vielzahl von benutzerspezifischen Angaben vervollständigt werden kann.

28. Ein System für die Speicherung und Wiederverwendung von Geschäftsdokumenten, das Verfahren bestehend aus:
Vorrichtung zur Speicherung einer Vielzahl von Geschäftsdokumenten,
Vorrichtung zur Organisation einer Vielzahl von hierarchisch organisierten Klassen, wobei die Geschäftsdokumente in die Klassen eingeordnet sind und jede Klasse mit einem oder mehreren in der jeweiligen Klasse eingeordneten Dokumenten assoziiert ist,
Vorrichtung zur Suche nach bestimmten Geschäftsdokumenten durch Navigieren durch die Klassen und
Vorrichtung zur Erstellung eines oder mehrerer generischer Dokumente aus einem oder mehreren Geschäftsdokumenten.