DE10244729A1 - Dokumentenspeicherung und -klassifizierung - Google Patents

Dokumentenspeicherung und -klassifizierung

Info

Publication number
DE10244729A1
DE10244729A1 DE10244729A DE10244729A DE10244729A1 DE 10244729 A1 DE10244729 A1 DE 10244729A1 DE 10244729 A DE10244729 A DE 10244729A DE 10244729 A DE10244729 A DE 10244729A DE 10244729 A1 DE10244729 A1 DE 10244729A1
Authority
DE
Germany
Prior art keywords
documents
buyer
document
classes
seller
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Withdrawn
Application number
DE10244729A
Other languages
English (en)
Inventor
Manoel Tenorio
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Blue Yonder Group Inc
Original Assignee
I2 Technologies Inc
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by I2 Technologies Inc filed Critical I2 Technologies Inc
Publication of DE10244729A1 publication Critical patent/DE10244729A1/de
Withdrawn legal-status Critical Current

Links

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q30/00Commerce
    • G06Q30/06Buying, selling or leasing transactions
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00Payment architectures, schemes or protocols
    • G06Q20/38Payment protocols; Details thereof
    • G06Q20/382Payment protocols; Details thereof insuring higher security of transaction
    • YGENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y10TECHNICAL SUBJECTS COVERED BY FORMER USPC
    • Y10STECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y10S707/00Data processing: database and file management or data structures
    • Y10S707/99931Database or file accessing
    • YGENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y10TECHNICAL SUBJECTS COVERED BY FORMER USPC
    • Y10STECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y10S707/00Data processing: database and file management or data structures
    • Y10S707/99941Database schema or data structure
    • Y10S707/99944Object-oriented database structure
    • Y10S707/99945Object-oriented database structure processing

Abstract

Ein E-Commerce-System (10) für die Speicherung und Klassifizierung von Dokumenten, das ein oder mehrere Dokumentenspeicher (32, 35) enthält, die Dokumente speichern. Das System enthält auch ein globales Inhaltsverzeichnis (42), das mehrere Produkt- und Dokumentenklassen enthält, die hierarchisch geordnet sind, wobei jede Klasse mehrere Dokumente kategorisiert und mit einem oder mehreren Attributen der in der Klasse kategorisierten Dokumente in Verbindung bringt. Mindestens eine der Klassen hat ein oder mehrere verbundene Zeiger, die einen oder mehrere Dokumentenspeicher kennzeichnen. Das System enthält ferner eine globale Inhaltsverzeichnis-Schnittstelle (43), die das Finden der Dokumente erleichtert. Ein Sicherheitsmodul (41) verschlüsselt die Dokumente, um vertrauliche Informationen zu schützen, die in den Dokumenten enthalten sind und verschlüsselt die Dokumente, wenn sich ein Käufer (20) im Besitz der erforderlichen Genehmigungsstufe befindet.

Description

    TECHNISCHES GEBIET DER ERFINDUNG
  • Die Erfindung bezieht sich auf E-Commerce und genauer gesagt auf die Dokumentenspeicherung und -klassifizierung.
  • HINTERGRUND DER ERFINDUNG
  • Wegen der ständig zunehmenden Beliebtheit und Erreichbarkeit des Internets als Kommunikationsmittel mehrt sich auch die Anzahl der über das Internet abgewickelten Geschäftsvorgänge sowie die Käufer- und Verkäuferzahlen, die an elektronischen Märkten teilnehmen, die eine Plattform für diese Geschäftsvorgänge bieten. Die meisten E- Commerce-Geschäftsvorgänge entstehen, wenn ein Käufer feststellt, dass er ein Produkt benötigt, einen Verkäufer sucht, der es liefert und die Website des Verkäufers besucht, um den Kauf des Produkts zu arrangieren. Ferner muss der Käufer ein oder mehrere Dokumente für den Verkäufer ausfüllen, wie eine Angebotsaufforderung oder ein Auftragsformular um den E-Commerce-Geschäftsvorgang abzuschließen. Wenn der Käufer keinen bevorzugten Verkäufer hat oder wenn er ein Produkt zum ersten Mal kauft, führt er häufig eine Suche nach mehreren Verkäufern durch, die das Produkt anbieten und besucht dann zahlreiche Websites von Verkäufern um festzustellen, welcher Verkäufer gewisse gewünschte Merkmale zum günstigsten Preis und zu den günstigsten Bedingungen für den Käufer anbietet. Dann wählt er einen Verkäufer und füllt zahlreiche Formulare aus, um den E-Commerce-Geschäftsvorgang abzuschließen. Die Abstimmungsphase von E-Commerce- Geschäftsvorgängen (Abstimmen des Käufers auf einen bestimmten Verkäufer) und das Ausfüllen des Dokumentes sind häufig ineffiziente Vorgänge. Die Abstimmungsphase ist wegen der langen Suche nach einem Produkt ineffizient und weil die verschiedenen Angebote verschiedener Verkäufer für das Produkt, nachdem ein bestimmtes Produkt gefunden wurde, nicht ohne weiteres vergleichbar sind. Die Phase für das Ausfüllen eines Dokumentes ist häufig ineffizient, weil der Käufer generell mit einem Formular oder bei den meisten E-Commerce-Geschäftsvorgängen ohne ein Dokument beginnt und daher ein Dokument erstellen oder alle Informationen in das Formular eingeben muss, obgleich sich ein Teil der Informationen in den Dokumenten nur geringfügig oder überhaupt nicht zwischen verschiedenen Verkäufern und verschiedenen Produkten ändert.
  • ZUSAMMENFASSUNG DER ERFINDUNG
  • Nach der vorliegenden Erfindung wurden die Nachteile und Probleme, die mit früheren E-Commerce-Techniken verbunden waren, wesentlich gemindert oder ausgeschlossen.
  • In einem Ausführungsbeispiel der vorliegenden Erfindung enthält ein E-Commerce- System ein oder mehrere Dokumentenspeicher, die mehrere Dokumente speichern. Das System enthält auch ein globales Inhaltsverzeichnis, das wiederum mehrere Klassen enthält, die hierarchisch geordnet sind. Die Klassen enthalten Produkt- und Dokumentklassen. Jede Klasse kategorisiert mehrere Dokumente und ist mit einem oder mehreren Attributen der Dokumente verbunden, die in der Klasse kategorisiert sind. Mindestens eine der Klassen hat einen oder mehrere zugeordnete Zeiger (pointer), die einen oder mehrere Dokumentenspeicher bestimmen. Das System enthält ferner ein Sicherheitsmodul, das die Dokumente verschlüsselt, um vertrauliche oder Wettbewerbsinformationen in den Dokumenten zu schützen. Das System enthält auch eine globale Inhaltsverzeichnis-Schnittstelle, durch die eine Anzeige entsteht, die das Finden der Dokumente erleichtert.
  • Spezifische Ausführungsbeispiele der vorliegenden Erfindung können ein oder mehrere technische Vorteile bieten. Zum Beispiel bieten gewisse Ausführungsbeispiele der vorliegenden Erfindung eine Geschäftsvorgang-Dokumentenspeicher- und - managementkomponente in einem E-Commerce-Geschäftsvorgangssystem. Durch diese Funktion werden das Management und die Verfolgung aller E-Commerce- Geschäftsvorgänge verbessert, weil Dokumente, die sich auf E-Commerce- Geschäftsvorgänge beziehen, in verallgemeinerten Zellen gespeichert werden können. Die im E-Commerce-Geschäftsvorgangssystem eingesetzte Dokumentenspeicher- und Managementkomponente ist für Aufträge oder Konfliktlösungen zwischen dem Käufer und dem Verkäufer von Hilfe, weil die Dokumente für den E-Commerce-Geschäftsvorgang ohne weiteres zur Verfügung stehen. Ferner bleiben alle vertraulichen oder Wettbewerbsinformationen, die in dem Dokument enthalten sind, geschützt und sind für andere Käufer nicht erreichbar, weil die Dokumente verschlüsselt werden können, wenn sie gespeichert werden.
  • Ferner gestatten es bestimmte Ausführungsbeispiele der vorliegenden Erfindung auch dem Käufer, Nachbestellungen von Produkten und andere sich wiederholende Geschäftsvorgänge zu ordnen, da alle früheren E-Commerce-Geschäftsvorgangsdaten schnell durch Durchsicht der gespeicherten Dokumente in Verbindung mit dem E- Commerce-Geschäftsvorgangssystem gefunden werden können. Informationen, die für jeden Käufer unabhängig von der Produktart oder dem Verkäufer gleich sind, sind vom Käufer nicht neu einzugeben, weil der Käufer ein früheres Dokument erneut benutzen kann und er nur die Teile des Dokumentes ändern muss, die zu ändern sind. Daher bedeutet die Benutzung eines gemeinsamen Dokumentenspeichers für den Käufer und Verkäufer Zeit- und Kosteneinsparungen und ermutigt eine große Anzahl Käufer und Verkäufer, ein E- Commerce-System zu benutzen, das ein globales Inhaltsverzeichnis enthält. Weitere technische Vorteile sind für den Fachmann ohne weiteres anhand der folgenden Abbildungen, der Beschreibung und der Ansprüche ersichtlich.
  • KURZBESCHREIBUNG DER ABBILDUNGEN
  • Um das Verständnis der vorliegenden Erfindung und der Merkmale und Vorteile derselben zu verbessern, wird auf die folgende Beschreibung Bezug genommen, die in Verbindung mit den anliegenden Abbildungen zu verstehen ist, wobei:
  • Fig. 1 das Beispiel eines E-Commerce-Systems darstellt;
  • Fig. 2A & 2B ein Beispiel der Verzeichnisstruktur eines Beispiels eines globalen Inhaltsverzeichnisses für Produktklassen darstellt;
  • Fig. 3 ein Beispiel der Verzeichnisstruktur eines Beispiels eines globalen Inhaltsverzeichnisses für Dokumentenklassen darstellt;
  • Fig. 4 eine Beispieltabelle einer Verkäuferdatenbank darstellt;
  • Fig. 5 ein Beispiel für ein E-Commerce-System in genauerem Detail und Beispielverfahren für die Speicherung, Klassifizierung und Wiederverwendung von Dokumenten darstellt.
  • GENAUE BESCHREIBUNG EINIGER AUSFÜHRUNGSBEISPIELE
  • Fig. 1 zeigt ein Beispielsystem 10, das ein Netzwerk 12 enthält, das den Käufer 20, den Verkäufer 30 und den Server eines globalen Inhaltsverzeichnis-Servers (GCD) 40 miteinander verbindet. Mit dem System 10 können E-Commerce-Geschäftsvorgänge zwischen Käufern 20 und Verkäufern 30 durch den Einsatz eines GCD 42, unterstützt durch einen Server GCD 40, ausgeführt werden. Das GCD 42 kann ein interner oder externer Server GCD 40 sein. Das Netzwerk 12 kann jede geeignete Kombination aus öffentlichen bzw. privaten Netzwerken zum Verbinden von Käufern 20, Verkäufers 30 und des GCD-Servers 40 enthalten. In einem Beispiel des Ausführungsbeispiels enthält das Netzwerk 12 das Internet und alle geeigneten LAN, MAN oder WAN, die die Käufer 20, Verkäufer 30 und den Server GCD 40 mit dem Internet verbinden Da das Internet für die überwiegende Mehrheit der Käufer und Verkäufer in aller Welt erreichbar ist, enthält die vorliegende Erfindung potentiell alle diese Käufer und Verkäufer wie den Käufer 20 und Verkäufer 30, die mit dem System 10 verbunden sind. Die Verwendung des Ausdrucks "global" ist jedoch nicht als geografische Beschränkung zu interpretieren, die notwendigerweise vorschreibt, dass das GCD 42 den Käufern 20 und Verkäufern 30 weltweit (oder in einer anderen bestimmten Region) Verzeichnisdienste zur Verfügung stellt oder dass der Inhalt des GCD 42 aus aller Welt stammt (oder aus einer bestimmten anderen Region).
  • Obgleich die Käufer 20 und Verkäufer 30 als getrennte Einheiten beschrieben werden, kann der Käufer 20 in einem Geschäftsvorgang ein Verkäufer 30 sein und in einem anderen Geschäftsvorgang ein Verkäufer und umgekehrt. Außerdem schließt der Bezug auf einen "Käufer" oder "Verkäufer" eine Person, ein Computersystem, eine Organisation oder, wo zutreffend, eine andere Einheit ein. Zum Beispiel kann ein Käufer 20 einen Computer einschließen, der dazu programmiert ist, autonom den Bedarf an einem bestimmten Produkt festzustellen, eine Suche nach dem Produkt auszuführen und nach Finden eines geeigneten Verkäufers das Produkt zu kaufen. Obgleich nachstehend in erster Linie Kaufen und Verkaufen beschrieben werden, betrachtet die vorliegende Erfindung jeden geeigneten E- Commerce-Geschäftsvorgang. Außerdem schließt der Bezug auf "Produkte" Waren, Immobilien, Dienstleistungen, Informationen oder alle anderen geeigneten materiellen oder immateriellen Gegenstände ein.
  • Ein typischer E-Commerce-Geschäftsvorgang kann eine "Abstimmungsphase" und eine "Geschäftsvorgangsphase" enthalten. Während der Abstimmungsphase kann ein Käufer 20 nach einem geeigneten Produkt (d. h. einem beliebigen Produkt oder Immobilien, Dienstleistungen, Informationen oder einem anderen materiellen oder immateriellen Gegenstand) suchen, das Gegenstand eines E-Commerce-Geschäftsvorgangs ist, das von einem oder mehreren Verkäufern 30 angeboten wird, wobei der geeignetste Verkäufer 30 gefunden wird (was zum Beispiel das Finden des Verkäufers 30 umfasst, der den günstigsten Preis anbietet) sowie die Kontaktaufnahme zu diesem Verkäufer 30, um in die Geschäftsvorgangsphase zu gelangen. Während der Geschäftsvorgangsphase können der Käufer 20 und der Verkäufer 30 einen Vertrag für den Verkauf des Produkts aushandeln (bei dem es sich zum Beispiel darum handeln kann, den Gegenstand des Geschäftsvorgangs genauer zu beschreiben, einen Preis auszuhandeln und zu einer Einigung über die Lieferlogistik zu kommen) und ein rechtsgültiges Dokument mit den Bedingungen des ausgehandelten Vertrages aufzustellen. Um den geeignetsten Verkäufer 30 während der Abstimmungsphase ohne den Einsatz des GCD 42 zu finden, kann ein Käufer 20 Zugriff auf zahlreiche Verkäufer-Websites haben, um festzustellen, welcher Verkäufer 30 gewisse gewünschte Merkmale des Produkts zum günstigsten Preis anbietet. Die Verkäufer 30 können je eine oder mehrere Datenbanken 32 wie relationale Datenbanken liefern, die die Daten enthalten, die die vom Verkäufer 30 lieferbaren Produkte und ihre Merkmale beschreiben. Auf jede Datenbank 32 kann der Zugriff durch die mit den Verkäufern verbundene Website oder in jeder andern geeigneten Weise erfolgen. Mehrfachsuchen im Verhältnis eins zu eins (ein Käufer 20 auf einen Verkäufer 30), auf denen dieses Verfahren beruht, sind ineffizient und teuer, da die Suche zum Finden eines Produkts umfangreich ist und weil die verschiedenen Angebote des Produkts von verschiedenen Verkäufern 30 nicht ohne weiteres vergleichbar sind.
  • Alternativ können mehrere Verkäufer 30 auf einem elektronischen Markt nach den von ihnen gelieferten Produkten gruppiert werden und ein Käufer 20 kann die Angebote mehrerer Verkäufer 30 auf einer einzigen Website durchsuchen. Wenn jedoch der Käufer 20 am Kauf mehrerer Produktarten interessiert ist, kann der Käufer 20 unter Umständen mehrere verschiedene Märkte aufsuchen müssen. Ferner kann es zahlreiche konkurrierende Märkte geben, auf denen der Käufer 20 eine Suche durchführen muss, um die Abstimmungsphase eines Geschäftsvorgangs für ein bestimmtes Produkt durchzuführen.
  • Ein potentielles Verfahren zum Ansprechen dieses Problems ist das Erstellen einer globalen Datenbank, die potentiell Daten enthält, die die Merkmale aller Produkte finden, an denen einer der Käufer interessiert ist. Daher würde die globale Datenbank den kombinierten Inhalt jeder Datenbank 32 enthalten, die mit jedem Verkäufer 30 verbunden ist. Eine derartige globale Datenbank würde jedoch viele Probleme haben. Zum Beispiel würde die reine Größe der Datenbank die Suche erschweren und daher würden bei der Datenbank Leistungsprobleme auftreten. Ferner wäre es schwierig, es zahlreichen Käufern 20 zu gestatten, die Datenbank gleichzeitig zu durchsuchen. Außerdem müssten alle Verkäufer 30 Zugriff auf die globale Datenbank nehmen, um ihre Informationen zu aktualisieren und die gesamte Datenbank müsste jedes Mal, wenn eine Änderung vorgenommen wird, aktualisiert werden. Dazu könnten viele andere Probleme auftreten.
  • Wie bereits erwähnt, enthält die Geschäftsvorgangsphase die Ausstellung und den Einsatz eines oder mehrerer Dokumenten zwischen dem Käufer 20 und dem Verkäufer 30. Zum Ausstellen und Einsatz von Dokumenten ohne die Unterstützung des GCD 42 in der Geschäftsvorgangsphase kann der Käufer 20 jedes Mal, wenn der Käufer 20 einen neuen Geschäftsvorgang mit dem Verkäufer 30 abwickelt, neue Dokumente ausstellen müssen und hat dann die rechtlichen und geschäftlichen Punkte mit dem Verkäufer 30 auszuhandeln, obgleich der Käufer 20 und der Verkäufer 30 bereits früher in Verbindung standen, weil es keine gespeicherten Aufzeichnungen von früheren Geschäftsvorgängen gibt, außer wenn der Käufer 20 oder der Verkäufer 30 solche Aufzeichnungen führt. Die Ausstellung von Dokumenten und die Aushandlung von Bedingungen steigert die Kosten des Geschäftsvorgangs sowie die auf diesen verwendete Zeit. Wenn ferner der Käufer 20 eine Unterlage dafür wünscht, was der Käufer 20 früher in früheren Geschäftsvorgängen von mehreren Verkäufern 30 gekauft hat, ist der Käufer 20 für die Speicherung der eigenen Dokumente des Käufers 20 in einer Käuferdatenbank oder an einem anderen Ort, den der Käufer 20 erreichen kann, verantwortlich. Das Problem wird noch größer, wenn der Käufer 20 mit einem Verkäufer 30 in Beziehung steht, mit dem der Käufer 20 noch nie Beziehungen unterhalten hat, weil es von Anfang an keine Gemeinsamkeiten gibt und normalerweise Dokumente ausgestellt werden müssen. Selbst wenn der Käufer 20 zahlreiche Geschäftsvorgänge mit einem bestimmten Verkäufer 30 abgeschlossen hat, kann die Ausstellung von Dokumenten ineffizient sein. Wenn außerdem ein Käufer 20, der neu im System 10 ist, beschließt, das System 10 zum ersten Mal zu benutzen, um einen Geschäftsvorgang mit dem Verkäufer 30 abzuschließen, ist dies ein langwieriger, arbeitsintensiver Prozess, weil der Käufer 20 alle erforderlichen Dokumente von Grund auf neu erstellen muss oder sonst gezwungen ist, die Dokumente des Verkäufers 30 zu benutzen. Manche Verkäufer 30 versuchen, Aufzeichnungen von Geschäftsvorgängen durch Speicherung von Dokumenten in einer oder mehreren Verkäuferdatenbanken 32 vorzuhalten. Aber die Dokumente, die in Verkäuferdatenbanken 32 gespeichert werden, stehen typischerweise nur den Verkäufern 30 zur Verfügung, denen die Dokumente gehören und generell nicht dem Käufer 20 und anderen Verkäufern 30.
  • Eine Lösung für die vorstehend beschriebenen Probleme ist zumindest teilweise das GCD 42. Das GCD 42 ist ein universelles Verzeichnis des Inhalts der Datenbanken 32 mehrerer Verkäufer (und potentiell aller Verkäuferdatenbanken 32) und auf diese Weise werden die Dokumente für die Käufer 20 und andere Verkäufer 30 erreichbar. Das GCD 42 kann mit einem oder mehreren Servern 40 oder anderen Computern implementiert werden, die sich an einem oder mehreren Orten befinden. Der größte Teil oder der gesamte Inhalt in diesen Verkäuferdatenbanken 32 bleibt in den Datenbanken 32 gespeichert, aber der Inhalt ist durch Zugriff auf das GCD 42 erreichbar. Wie bei der vorstehend beschriebenen globalen Datenbank, bietet das GCD 42 Käufern 20 Zugriff zu Produktdaten, die sich auf mehrere Produkte beziehen (und potentiellen Verkäuferdaten, die sich auf ein oder mehrere Verkäufer 30 der Produkte beziehen) sowie zu Dokumenten, die in früheren Geschäftsvorgängen zwischen den Käufern 20 und Verkäufern 30 benutzt wurden. Im Gegensatz zur globalen Datenbank versucht jedoch das GCD 42 nicht, alle diese Daten und Dokumente in einer enormen Datenbank zu speichern. Wo zutreffend, schließt der Bezug auf "Daten" auch die Produktdatenwerte ein (also Informationen, die für die Werte von gewissen Attributen eines Produkts gelten), Verkäuferdaten (also Informationen, die für die Werte von gewissen Attributen eines Verkäufers gelten) oder sowohl Produktdaten wie auch Verkäuferdaten. Bei einem entsprechenden Bezug auf "Dokumente" schließt dieser auch Dokumente ein, die von einem Käufer 20 für einen Geschäftsvorgang bzw. Dokumente ausgestellt oder benutzt wurden oder von einem Verkäufer 30 für einen Geschäftsvorgang verwendet wurden.
  • Das GCD 42 liefert ein Verzeichnis für Produkte und Dokumente unter Verwendung einer Verzeichnisstruktur, wobei Produkte bzw. Dokumente nach einem hierarchischen Klassifizierungssystem geordnet sind. Ein Käufer 20 kann durch das Verzeichnis navigieren oder dies durchsuchen, um eine bestimmte Produktklasse zu finden, unter der die Produkte eingeordnet sind, eine bestimmte Produktklasse, in der die Dokumente kategorisiert sind oder eine bestimmte Dokumentenklasse, in der die Dokumente kategorisiert sind. Die Produktdaten (und potentiellen Verkäuferdaten), die mit einem Produkt verbunden und in einer Produktklasse enthalten sind, können übrigens in einer Verkäuferdatenbank 32 gespeichert und von dieser durch das GCD 42 erhalten werden. Die mit einem Produkt verbundenen Dokumente, die sich in einer Produktklasse befinden und die Dokumente, die sich in einer Dokumentenklasse befinden, können ebenfalls von einem GCD 42 in einer Verkäuferdatenbank 32 gespeichert und aus dieser erhalten werden. Die angeforderten Daten oder das Dokument können jedoch so transparent an den Käufer 20 geliefert werden, dass alle Produktdaten und Dokumente für den Käufer 20 so erscheinen, als wenn sie sich im GCD 42 befanden. Obgleich die Produktdaten, die Verkäuferdaten und Dokumente in erster Linie als in den Verkäuferdatenbanken 32 gespeichert beschrieben wurden, betrachtet die vorliegende Erfindung Produkt- und Verkäuferdaten und Dokumente als in geeigneter Weise gespeichert und als in geeigneten Quellen gefunden. Zum Beispiel kann das System 10 einen gemeinsamen Datenspeicher 34 enthalten, der Produktdaten bzw. Verkäuferdaten enthält, die mit Daten aus einer oder mehreren Verkäuferdatenbanken 32 kombiniert werden können und der Dokumente enthält, die die Dokumente aus einer oder mehreren Verkäuferdatenbanken 32 ergänzen können, wie nachstehend genauer im Einzelnen beschrieben.
  • Fig. 2 beschreibt ein Beispiel einer Verzeichnisstruktur 44 anhand eines Beispiels eines GCD 42 für Produktklassen. Produkte und Dokumente, die im GCD 42 kategorisiert sind, können nach Schemen geordnet werden. Ein Schema kann mehrere Produktklassen enthalten (auch "Taxonomie" genannt), die hierarchisch geordnet sind. Jede Klasse kann mit einem Satz Produktmerkmale, -eigenschaften oder anderen Prokduktattributen verbunden werden (auch "Produktontologie" genannt) bzw. einem Satz Dokumentenmerkmalen, -eigenschaften oder anderen Dokumentenattributen (die "Dokumentenontologie") für jede Art. Zum Beispiel haben Stifte unterschiedliche Spitzen (wie Kugelschreiber oder Filzstifte), andere Spitzengrößen (wie fein, mittel oder breit) und verschiedene Farben (wie blau, schwarz oder rot). Ferner sind mit Filzstiften bestimmte Dokumente verbunden, während mit Kugelschreibern andere verbunden sein können. Daher kann ein Schema eine Klasse enthalten, die Stiften entspricht, mit einer Produktontologie wie Spitzenart, Spitzengröße und Farbe oder andere entsprechende Attribute aufweisen, wie Dokumente für Stifte und spezifische Stiftarten. Innerhalb einer Klasse können Produkte nach Produktattributwerten beschrieben werden (wie zum Beispiel Kugelschreiber, mittlere Spitze, blau). Der Bezug auf den "Wert" soll alle entsprechenden Daten einschließen, die zum Beispiel ein Produktattribut oder ein Verkäuferattribut einschließen. Produktattributwerte und Verkäuferattributwerte können zum Beispiel Zahlen, Buchstaben, Ziffern, Zeichen, Symbole oder sonstige geeignete Informationen zum Beschreiben eines Produkts bzw. eines Verkäufers enthalten. In einem Ausführungsbeispiel kann eine Produktontologie in Attribute unterteilt werden, die einzugeben sind (also Attribute, für die ein Wert zu liefern ist) und Attribute, die nach Wahl eingegeben werden können (also Attribute, für die die Eingabe eines Wertes eine Option ist) und diese Kategorien können weiter in kommerzielle und Designmerkmale (oder andere geeignete Unterteilungen) unterteilt werden.
  • Abgesehen von Taxonomie, Produkt- und Dokumentenontologien kann ein Schema auch einen Satz Attribute für jeden Verkäufer einschließen (die man mit "Verkäuferontologie" bezeichnen kann). Derartige Attribute können geografische Beschränkungen (wie belieferte Märkte) sein, Währungen, die von jedem Verkäufer angenommen werden, Mittel für die Zusammenarbeit, die von jedem Verkäufer angenommen werden, Vertragsbedingungen, die von jedem Verkäufer angenommen werden, Vertragsarten, die von jedem Verkäufer angenommen werden. Käuferkreditstufen, die von jedem Verkäufer gefordert werden und alle anderen geeigneten Verkäuferattribute. Ähnlich wie bei einem Produkt in einer Produktklasse können Verkäufer, die Produkte in einer Produktklasse anbieten, nach Verkäuferattributwerten klassiert werden, die den Verkäuferattributen entsprechen. Daher kann ein Schema einen Satz Klassen enthalten, die jeweils ein oder mehrere Produkte enthalten und jede Klasse kann mit einem Satz Produktattribute und einem Satz Verkäuferattribute verbunden werden.
  • Im Beispiel für die Verzeichnisstruktur 44 können Produkte nach Industriestandardschemen 46 geordnet und katalogisiert werden oder nach anderen geeigneten Schemen, wie nachstehend beschrieben. In Industriestandardschemen 46 gibt es zwei Beispielklassen: eine direkte Materialklasse 48 und eine indirekt Materialklasse 50. Jede dieser Klassen 48 und 50 enthält mehrere Unterklassen (die wiederum Unterklassen enthalten können). Daher bilden die zahlreichen Klassen der Verzeichnisstruktur 44 eine "baumartige" hierarchische Struktur, in der Produkte und Dokumente kategorisiert werden können. Als Beispiel werden gewisse Teile der Verzeichnisstruktur 44 in Fig. 2 "expandiert", um die verschiedenen Klassenstufen darzustellen. Die "Stufe" einer Klasse wird von der Anzahl anderer Klassen zwischen einer Klasse und einer "Ausgangsklasse" (wie einer Industriestandard-Schemenklasse 46) angezeigt. Zum Beispiel befindet sich die direkte Materialklasse 50 auf der gleichen Stufe in der Verzeichnisstruktur wie die direkt Materialklasse 48. Die indirekte Materialklasse 50 kann eine Klasse 52 für Büro- und Computerbedarf einschließen, die eine Klasse 54 für Schreibtischzubehör enthält, die wiederum eine Klasse 56 für Schreibutensilien enthält. Ferner enthält die Klasse 56 für Schreibutensilien eine Stiftklasse 58, die zahlreiche Stiftartenklassen 60a-60n enthält (wobei "n" besagt, dass die Klassen 60 in beliebiger Anzahl in der Stiftklasse 58 enthalten sein können), eine Stift-Dokumentenklasse 59 für alle Stifte und eine Stiftart- Dokumentenklasse 63a-63n für jede Stiftartentklasse 60a-60n. Jede der Klassen 50, 52, 54, 56, 58 und 60 befindet sich auf einer anderen Stufe der Verzeichnisstruktur 44. Eine Klasse auf einer beliebigen Stufe in der Verzeichnisstruktur 44 kann ein oder mehrere Unterklassen einschließen, wobei diese Unterklassen ein oder mehrere Unterklassen einschließen können usw., bis eine gewünschte Kategorisierungsspezifität erreicht ist. Mehrere Klassen von der Klasse der höchsten Stufe (der breitesten Klasse) bis zur Klasse der untersten Stufe (die spezifischste Klasse) können auch als "Zweige" der Verzeichnisstruktur 44 bezeichnet werden. Zum Beispiel bilden die Klassen 46, 48, 50, 52, 54, 56, 58, 60b und 63b Zweige der Verzeichnisstruktur 44.
  • Obgleich die Beispiel-Verzeichnisstruktur 44 Industriestandardschemen 46, wie vorstehend beschrieben, benutzen kann, können alle anderen geeigneten Schemen 62 zusätzlich zu oder an Stelle von Industriestandardschemen 46 benutzt werden. Während zum Beispiel Industriestandardschemen 46 aus der Sicht des Verkäufers geordnet sein können, können andere Schemen benutzt werden, bei denen die Produkte aus der Sicht des Käufers geordnet sind. Ein Käufer kann zum Beispiel den Wunsch hegen, die Küche eines neuen Hauses mit verschiedenen Produkten wie Haushaltsgeräten, Fensterdekorationen, Anstrich, Schränken, Installationen, Geschirr und Küchenutensilien auszustatten. Unter Verwendung eines Schemas 62 können diese Produkte in verschiedensten nicht miteinander verwandten Klassen geordnet werden, beruhend auf gewissen Merkmalen der Produkte (zum Beispiel können gewisse Küchengeräte in einer Elektronikklasse 52 der Verzeichnisstruktur 44 geordnet werden, während der Anstrich in Industrieklasse 52 geordnet wird). In einem weiteren Beispiel kann Schema 62 alle derartigen Produkte in einer Haushaltsprodukte-Klasse ordnen (die mehrere Klassen enthalten kann, die die Produkte weiter kategorisieren wie eine Küchenprodukteklasse, die eine Küchengeräteklasse enthält, die wiederum eine Kühlgeräteklasse usw. enthält). Das gleiche Produkt kann daher in mehreren Schemen 62 enthalten sein. Diese Alternativschemen können in Verzeichnisstruktur 44 enthalten sein und als Teil oder getrennt vom GCD 42 gespeichert werden.
  • Ein Käufer 20 kann durch die Verzeichnisstruktur 44 navigieren, indem er nach Wunsch verschiedene Klasse erweitert oder verkleinert. Fig. 2 zeigt zum Beispiel die Vergrößerung gewisser Klassen der Verzeichnisstruktur 44, um einen Filzstift in Klasse 60b zu erreichen. Nachdem ein Käufer 20 in eine Klasse gelangt ist, die spezifisch genug für den Käufer 20 ist (bzw. eine Klasse, die sich am Ende eines Zweiges befindet), kann der Käufer 20 eine Suche nach Produkten innerhalb dieser Klasse durchführen. Der Käufer 20 kann zum Beispiel nach allen Produkten der Schreibutensilienklasse 56 suchen, bei denen es sich, um blaue Filzstifte mit mittleren Spitzen handelt. Wenn der Käufer 20 andererseits bis zum Ende des Zweiges der Verzeichnisstruktur 44 navigiert, wie z. B. zur Filzstiftklasse 60b, kann es das GCD 42 dem Käufer 20 evtl. gestatten, nach Stiften zu suchen, die blau sind und die mittlere Spitzen haben (wobei das gleiche Ergebnis erreicht werden kann wie bei der vorstehend beschriebenen Suche).
  • Der Käufer 20 kann auch nach Verkäufern suchen, die einem oder mehreren Verkäuferattributwerten innerhalb einer Klasse entsprechen. Abgesehen von der Suche nach allen Produkten in Schreibutensilienklasse 56, die blaue Filzstifte mit mittleren Spitzen sind, kann der Käufer 20 auch nach Verkäufern 30 suchen, die Texas beliefern und US-Dollar annehmen. Der Käufer 20 kann nach Produkten suchen, die gewissen Produktattributwerten und Verkäufern, die gewissen Verkäuferattributwerten in geeigneter Weise entsprechen. In einem Ausführungsbeispiel zum Beispiel liefert der Käufer 20 die Suchkriterien sowohl mit Werten für Produktattribute wie auch mit Verkäuferattributen (statt dessen können Suchkriterien ganz oder teilweise automatisch generiert werden, wie nachstehend beschrieben) und der Server 40 sucht nach Produkten, die mit den Produktattributkriterien übereinstimmen und von Verkäufern angeboten werden und den Verkäuferattributkriterien entsprechen. In einem anderen Ausführungsbeispiel liefert der Käufer 20 nur Produktattributwerte als Suchkriterien und der Server 40 beschränkt seine Suche auf Produkte, die mit den Produktattributkriterien übereinstimmen, auf Datenbanken 32, die mit Verkäufern 30 verbunden sind, von denen bekannt ist, dass sie mit den Verkäuferattributkriterien übereinstimmen, die der Käufer 20 nach einem Käuferprofil oder anderweitig wünscht.
  • Der Käufer 20 kann auch nach Dokumenten suchen, die sich auf gewünschte Produkte innerhalb der Produktklasse beziehen, indem er die Verzeichnisstruktur 44 und das GCD 42 benutzt. Der Käufer 20 kann unter Verwendung des GCD 42 die Verzeichnisstruktur 44 durchsuchen. Der Käufer 20 kann die Verzeichnisstruktur unter Verwendung des GCD 42 durchsuchen, um Dokumente zu finden, die sich auf spezifische Produkte beziehen. Zum Beispiel kann der Käufer 20 Stifte kaufen wollen und Dokumente benötigen, um den Geschäftsvorgang abzuschließen. Der Käufer 20 hat für die Suche nach Dokumenten, die sich auf Stifte beziehen, mindestens zwei Möglichkeiten, was von der Spezifizität des vom Käufer 20 gesuchten Produkts abhängt. Wenn der Käufer 20 an mehr als einer Art Stifte interessiert ist, kann der Käufer 20 durch die Verzeichnisstruktur 44 zur Stift-Dokumentenklasse 59 navigieren. Sobald er sich in der Stift-Dokumentenklasse 59 befindet, kann der Käufer 20 die Suche nach allen Dokumenten durchführen, die sich auf alle Stiftarten beziehen. Die Stift-Dokumentenklasse 59 enthält ein oder mehrere Dokumentenunterklassen 61a-61n, die die Stiftdokumente so nach Dokumentenart kategorisieren, dass, wenn der Käufer 20 weiß, welche Dokumentenart der Käufer 20 benötigt, der Käufer 20 nach den Dokumenten dieser bestimmten Art für alle Stiftarten suchen kann. Zum Beispiel enthält die Dokumentenunterklasse 61a eine Angebotsanforderung ("RFQ") für alle Stiftarten, während Dokumentenunterklasse 61b Auftragsformular-Dokumente für alle Stiftarten enthält. Wenn daher der Käufer 20 ein Angebot für einen Auftrag über Stifte anfordern will, kann der Käufer 20 zur Dokumentenunterklasse 61a navigieren und die RFQ-Dokumente suchen, die sich auf alle Stiftarten beziehen. Die Kategorisierung der Dokumente innerhalb der Produktklassen ermöglicht es ferner dem Käufer 20, eine genauere Suche auszuführen. Wenn der Käufer 20 zum Beispiel nur an Kugelschreibern interessiert ist, kann der Käufer 20 zur Kugelschreiberklasse 60a navigieren, wie vorstehend beschrieben. Die Kugelschreiberklasse 60a enthält die Kugelschreiber-Dokumentenklasse 63a, die die Dokumente enthält, die sich auf Kugelschreiber beziehen. Der Käufer 20 kann eine Suche innerhalb der Stiftart-Dokumentenklasse 63a einleiten und nach allen Dokumenten suchen, die sich auf Kugelschreiber beziehen, unabhängig von der Dokumentenart. Die Suche innerhalb der Kugelschreiber-Dokumentenklasse 63a kann auch konzentriert werden, indem die Suchkriterien nur auf eine spezifische Dokumentenart beschränkt werden, zum Beispiel die Suche nach Bestellungen, so dass das Suchergebnis nur Bestelldokumente findet, die sich auf Kugelschreiber beziehen. Nachdem der Käufer 20 ein entsprechendes Dokument sowohl hinsichtlich der Dokumentenart und der Produktart gefunden hat, kann der Käufer 20 das Dokument für den Eigengebrauch des Käufers 20 ändern, wie nachstehend beschrieben.
  • Wie vorstehend beschrieben, werden in einem Ausführungsbeispiel Produktdaten (mindestens Produktdaten, die genauer sind als die von einer Taxonomie gelieferten Daten), Verkäuferdaten und Dokumente nicht im GCD 42 gespeichert, sondern in Verkäuferdatenbanken 32. Ein Verkäufer 30 kann zum Beispiel eine relationale Datenbank 32 unterhalten, die mehrere Tabellen mit Produktattributwerten für verschiedene Produkte enthält und mit Verkäuferattributwerten für jedes, einen Satz der Produkte oder alle Produkte, die vom Verkäufer 30 angeboten werden. In der Verkäuferdatenbank 32 kann der Verkäufer 30 auch Dokumente aus früheren Geschäftsvorgängen zwischen dem Verkäufer 30 und verschiedenen Käufern 20 speichern. Produktdaten und Verkäuferdaten können in eine oder mehrere Tabellen integriert oder auf verschiedene Tabellen aufgeteilt werden. Außerdem können Produktdaten und Verkäuferdaten für einen Verkäufer 30 in der gleichen oder in getrennten Datenbanken gespeichert werden. Ein oder mehrere Zeiger können mit jeder Klasse verbunden werden, um eine Zelle von einer oder mehreren Datenbanken 32 zu kennzeichnen, die Produktdaten, Verkäuferdaten und Dokumente für Produkte umfasst, die in der Klasse enthalten sind oder bestimmte Daten oder bestimmte Dokumente in Verkäuferdatenbanken 32. Daher kann das GCD 42 eine Suche nach Produkten oder Dokumenten in Datenbanken 32 durchführen, die von einem Zeiger gekennzeichnet sind, der einer vom Benutzer gewählten Klasse entspricht (oder der automatisch gewählt wird). Das GCD 42 kann auch die Netzwerkposition wie einen URL oder eine andere Netzwerkadresse der Datenbank 32 so für den Käufer 20 anzeigen, dass der Käufer 20 unabhängig Zugriff zur Datenbank 32 erhält. Die Datenbanken 32 können mit jedem geeigneten Verfahren durchsucht werden, einschl. jedoch nicht beschränkt auf eine SQL- Anfrage.
  • Das GCD 42 kann unter Verwendung des LDAP implementiert werden, mit dem Verzeichnisse entstehen, die die vorstehend beschriebene baumartige Struktur aufweisen. Jede andere geeignete Technik oder jedes Protokoll zum Einrichten des GCD 42 kann alternativ benutzt werden und das GCD 42 kann eine beliebige geeignete Struktur aufweisen. Ferner kann ein GCD 42 ein objektbezogenes Verzeichnis sein (das auch vom LDAP geliefert wird), so dass jede Klasse in der Verzeichnisstruktur 44 die Attribute der Mutterklassen enthält, von denen die Klasse eine Unterklasse ist. In diesem Ausführungsbeispiel enthält eine Klasse, die sich am Ende des Zweiges einer Baumstruktur befindet, alle Attribute ihrer Mutterklassen in dem Zweig. Ferner kann jedes Produkt oder Dokument in einer Datenbank 32 ein Objekt sein, das alle Attributklassen der Klassen enthält, in denen das Produkt oder Dokument enthalten ist. Wenn daher eine Suche von einer Klasse am Ende des Zweiges von Verzeichnisstruktur 44 durchgeführt wird, kann die Suchabfrage automatisch jedes geeignete Attribut der Mutterklassenattribute einer Klasse enthalten.
  • Wenn zum Beispiel ein Käufer 20 durch die Verzeichnisstruktur 44 bis zur Filzstiftklasse 60b navigiert ist, kann eine vom Käufer 20 (oder vom GCD 42 für den Käufer 20) ausgeführte Suche nach Filzstiftklasse 60b automatisch auf eine Suche nach Filzstiften beschränkt werden und der Käufer 20 kann zusätzlich gewünschte Suchkriterien einführen (wie blaue Farbe und mittlere Spitze). Wenn daher eine durchsuchte Datenbank 32 Produktdaten enthält, die sich auf mehrere Schreibutensilien beziehen, kann die Suche einer Datenbank 32 automatisch vom GCD 42 beschränkt werden, so dass sie nur Filzstifte in der Datenbank 32 umfasst. Der Käufer 20 kann auch zusätzliche Attributwerte bzw. Verkäuferattributwerte als zusätzliche Suchkriterien bestimmen.
  • Wenn das GCD 42 eine Suche einer Datenbanken 32 durchgeführt hat, die von einem Zeiger oder Zeigern gekennzeichnet ist, die mit einer Klasse verbunden sind, die der Käufer 20 gewählt hat (oder die automatisch gewählt wurde), kann das GCD 42 die Produktdaten, Verkäuferdaten, bzw. Dokumente finden, die mit einem oder mehreren Produkten, die den Suchkriterien entsprechen, verbunden sind. Das GCD 42 kann die Produktdaten, Verkäuferdaten, bzw. Dokumente, die sich aus der Suche in der Verzeichnisstruktur 44 ergeben, so integrieren, dass die Daten für den Käufer 20 so erscheinen, als wenn sie Teil des GCD 42 wären. Das GCD 42 kann alternativ die Ergebnisse der Suche in jeder anderen geeigneten Weise darstellen. Jedes Produkt oder Dokument, das sich aus der Suche ergibt, kann ein Objekt sein, bei dem es sich um ein spezifisches Beispiel der Klasse handelt, in der der Käufer 20 sucht. Ferner kann ein solches Objekt (und seine Speicherzelle) spezifisch mit einem Nummerierschema, das der Verzeichnisstruktur 44 entspricht, gefunden werden.
  • Zusammenfassend kann der Käufer 20 nach einem Produkt suchen, das bestimmten Produktattributwerten entspricht, die von einem Verkäufer 30 zur Abstimmung gewisser Verkäuferattributwerte unter Verwendung des GCD 42 benutzt wird und damit für den Käufer 20 die Notwendigkeit ausschließen oder reduzieren, dass er zahlreiche Verkäuferdatenbanken 32 einzeln durchsuchen muss, um das gewünschte Produkt zu finden, das von einem geeigneten Verkäufer lieferbar ist. Ferner kann ein Käufer 20 auch nach einem Dokument suchen, das bestimmten Attributen entspricht und die Notwendigkeit ausschließen, dass Dokumente jedes Mal neu erstellt werden müssen, wenn ein Käufer einen neuen Geschäftsvorgang beginnt, der sich auf ein oder mehrere Produkte bezieht. Das GCD 42 bietet Zugriff zu Produkt- und Verkäuferdaten und Dokumenten, die sich auf diese zahlreichen Produkte beziehen, unter Verwendung der Verzeichnisstruktur 44, die Produkte unter Verwendung eines hierarchischen, objektorientierten Klassifizierungssystems ordnet. Der Käufer 20 kann durch die Verzeichnisstruktur 44 navigieren oder suchen, um eine bestimmte Klassifizierung der Produkte und der verschiedenen Informationen zu finden, die mit den Produkten in dieser Klassifizierung verbunden sind, einschließlich Dokumenten, die mit verschiedenen Produkten verbunden sind und die Suche nach Datenbanken 32 für die Produkte bzw. Dokumente einleiten, einschließlich Produkt- bzw. Verkäuferdaten, die sich auf ein Produkt beziehen und dann den Informationsaustausch mit einer entsprechenden Datenbank 32 durch den Server GCD-40 oder anderweitig vornehmen. Ein solcher Zugriff zu einer enormen Anzahl Produkte und Dokumente steht ohne die Bedingung zur Verfügung, dass alle Daten über die Produkte, Verkäufer und Dokumente in einer globalen Datenbank gespeichert sind. Statt dessen können diese Daten in den Verkäuferdatenbanken 32 gespeichert werden, auf die ohne weiteres der Zugriff über den Server GCD 42 erfolgen kann.
  • Ein Problem, das mit dem Einsatz verschiedener Verkäuferdatenbanken 32 verbunden sein kann, ist die Tatsache, dass diese Datenbanken 32 Produktdaten über die gleiche Produktklasse enthalten können (zum Beispiel Filzstifte), jedoch Produkte der Klasse finden können, die andere Attributwerte benutzen, andere Namen für den gleichen Produktattributwert, bzw. die Produktattributwerte anders bestimmen oder unterscheiden (zum Beispiel unter Verwendung anderer Maßeinheiten). Das gleiche kann für Verkäuferdaten zu treffen, die in den Datenbanken 32 enthalten sein können. Ferner haben der Käufer 20 und der Verkäufer 30 Dokumente in verschiedenen Formaten, die sich voneinander unterscheiden. Einige dieser Probleme können mit Übersetzungsmechanismen gelöst werden, die die Daten in ein einheitliches Format umwandeln, das vom GCD 42 benutzt wird und unterschiedliche Dokumente in ein Standardformat umwandeln, das vom GCD 42 verstanden wird. Alternativ können die Verkäufer 30 neue Datenbanken 32 erstellen oder existierende Datenbanken 32 manuell ändern (oder Dritte damit beauftragen, die Datenbanken 32 zu erstellen oder zu ändern), um für die Datenbank 32 einen einheitlichen Standard zu erfüllen, der in Verbindung mit dem GCD 42 benutzt werden soll und die Käufer 20 und Verkäufer 30 können auch Dokumente erstellen oder ändern, um ein Standardformat zu erfüllen, das in Verbindung mit dem GCD 42 benutzt wird.
  • Das Erstellen oder Ändern von Dokumenten nach einem Standardformat ist eine schwierigere Aufgabe als des Standardisieren von Produktdaten, denn obgleich jedes Dokument ähnliche grundsätzliche Informationen enthalten kann, hat oder benötigt jeder Käufer 20 und Verkäufer 30 generell gewisse Klauseln, Teile oder Bedingungen, die bei anderen Käufern 20 und Verkäufern 30 nicht vorhanden sind oder von diesen gewünscht werden. Ferner können gewisse Dokumentenarten sehr ähnliche Informationen enthalten, die nicht sehr stark variieren, während sich andere Dokumentenarten sehr stark voneinander unterscheiden können und wenig oder keine gemeinsamen Bedingungen haben. Eine RFQ enthält zum Beispiel generell Abschnitte für Kontaktinformationen für Käufer 20 und Verkäufer 30, eine Produktbeschreibung und die geforderte Menge und typischerweise sind die meisten RFQ ähnlich, selbst wenn sie von anderen Käufern 20 oder Verkäufern 30 ausgestellt wurden. Andere Dokumente wie Formulare zum Annullieren von Bestellungen können völlig anders sein, abhängig von den von einem bestimmten Käufer 20 oder Verkäufer 30 geforderten Bedingungen, weil jeder Käufer 20 und Verkäufer 30 typisch seine eigenen Verfahren und Vorschriften für die Annullierung von Aufträgen hat. Daher besteht eine Lösung für das Standardisierungsproblem daraus, die Dokumente in Standarddokumente und spezifische Dokumente zu kategorisieren und einen gemeinsamen Speicherstandard für den Dokumentenspeicher 35 zu liefern, mit dem das GCD 42 leistungsfähiger arbeiten kann.
  • Standarddokumente sind Dokumente, die eine Standardform aufweisen, die der Server GCD 40 erkennt oder Dokumente, die sich bei verschiedenen Käufern 20 und Verkäufern 30 nicht sehr stark unterscheiden und die im Laufe einer gewissen Zeit leicht zu standardisieren wären. Die standardisierte Form für jedes Standarddokument ist je nach der Dokumentenart unterschiedlich. Die Standardform für ein RFQ-Standarddokument unterscheidet sich zum Beispiel von der standardisierten Form eines Standarddokumentes für eine Bestellung. Spezifische Dokumente sind Dokumente, die nicht in einer standardisierten Form gehalten sind aber generell in einem Format, das vom Käufer 20 oder Verkäufer 30 festgelegt wird und sie sind generell schwieriger auf Standardform zu reduzieren. Spezifische Dokumente enthalten häufig Bedingungen, die spezifisch für einen bestimmten Käufer 20 oder Verkäufer 30 gelten und nicht für alle Käufer 20 und Verkäufer 30 gelten müssen. Spezifische Dokumente können sich stark voneinander unterscheiden.
  • Der gemeinsame Dokumentenspeicher 35 enthält ein oder mehrere Standarddokumente. Wenn ein Käufer 20 oder Verkäufer 30 ein Standarddokument aufstellt oder ein Standarddokument ändert, das sich bereits in einem gemeinsamen Dokumentenspeicher 35 befindet, wird das neu erstellte oder geänderte Standarddokument im gemeinsamen Dokumentenspeicher 35 gespeichert. Spezifische Dokumente können in einer oder mehreren Verkäuferdatenbanken 32 gespeichert werden. Es wäre eine optimale Lösung, wenn Standard- und spezifische Dokumente, die sich auf bestimmte Produkte beziehen, von den Produktklassen des GCD 42 miteinander verbunden würden, in denen das Produkt klassiert ist. Zum Beispiel kann die Stift-Dokumentenklasse 59 im GCD 42 Zeiger für Standarddokumente und spezifische Dokumente im gemeinsamen Dokumentenspeicher 35 enthalten und eine oder mehrere Verkäuferdatenbanken 32. Ferner können ein oder mehrere Zeiger zum gemeinsamen Dokumentenspeicher 35 mit einem oder mehreren Zeigern zur Verkäuferdatenbank 32 verbundene werden, so dass verwandte Standarddokumente und spezifische Dokumente miteinander verbunden werden können. Alternativ können Standarddokumente im gemeinsamen Dokumentenspeicher 35 mit einem oder mehreren spezifischen Dokumenten in einer oder mehreren Verkäuferdatenbanken 32 verbunden werden. Spezifische Dokumente aus der Verkäuferdatenbank 32 können so mit Standarddokumenten aus einem gemeinsamen Dokumentenspeicher 35 verbunden werden, dass Standard- und spezifische Dokumente nach der Suche an einen Käufer 20 geliefert werden, wie nachstehend genauer unter Bezugnahme auf Fig. 6A & 6B beschrieben.
  • Obgleich der gemeinsame Dokumentenspeicher 35 als eine einzige Speicherzelle dargestellt wird, kann der gemeinsame Dokumentenspeicher 35 mehrere Speicherzellen an den gleichen oder alle anderen Stellen enthalten. Jede geeignete Anzahl Speicherzellen, die sich an verschiedenen Stellen befinden, kann benutzt werden, (zum Beispiel, können die Speicherzellen auf verschiedene geografische Regionen verteilt sein). Der Server GCD 40 kann die Suche nach jedem dieser verteilten gemeinsamen Dokumentenspeicher 35 wie erforderlich vornehmen, um Standarddokumente zu erhalten, die auf die Suche des Käufers reagieren. Alternativ können Zeiger, die mit einer Produktklasse verbunden sind, den Server GCD 40 zu einer oder mehreren bestimmten Speicherzellen führen. Wenn ferner mehrere gemeinsame Dokumentenspeicher 35 benutzt werden, kann jeder gemeinsame Dokumentenspeicher 35 die gleichen Standarddokumente enthalten, einige gleiche oder einige andere Standarddokumente oder völlig andere Standarddokumente. Ferner kann der gemeinsame Dokumentenspeicher 35 die Standarddokumente mit einem geeigneten Speichermittel speichern. Außerdem wird darauf hingewiesen, dass obgleich der gemeinsame Dokumentenspeicher 35 so beschrieben wird, dass er Standarddokumente enthält, die Verkäuferdatenbanken 32 auch Standarddokumente enthalten können.
  • Fig. 3 zeigt ein Beispiel einer Verzeichnisstruktur 70 eines Beispielservers GCD 42 für Dokumentenklassen. Abgesehen von der Kategorisierung der Dokumente in Produktklassen können Dokumente, die im GCD 42 kategorisiert sind, auch nach einem Schema geordnet werden, das einen Satz Dokumentenklassen oder eine Taxonomie enthält, die hierarchisch geordnet sind, wobei jede Dokumentenklasse mit einem Satz Dokumentenmerkmale, Eigenschaften oder anderen Dokumentenattributen verbunden ist, die charakteristisch sind oder mit anderen Dokumentenattributen (einer "Dokumentenontologie"). Die Kategorisierung von Dokumenten in Dokumentenklassen im Gegensatz zu einer Produktklasse, wie vorstehend in Fig. 2 beschrieben, gestattet es dem Käufer 20, die Suche nach Dokumenten, die auf der Dokumentenart beruhen, durchzuführen, unabhängig davon, auf welches Produkt sich das Dokument bezieht.
  • In der als Beispiel angeführten Verzeichnisstruktur 70 können die Dokumente nach den Geschäftsvorgang-Dokumentenschemen 72 geordnet und katalogisiert werden oder nach entsprechenden Schemen, wie nachstehend beschrieben. In Geschäftsvorgang- Dokumentenschemen 72 gibt es drei Beispielklassen: die Käuferdokumentenklasse 74, die Verkäuferdokumentenklasse 76 und die Dokumentenklasse 78. Jede dieser Klassen 74, 76und 78 enthält mehrere Unterklassen (die wiederum andere Unterklassen einschließen können). Daher bilden die zahlreichen Klassen der Verzeichnisstruktur 70 eine "baumartige" hierarchische Struktur, in der Dokumente ähnlich wie in der Verzeichnisstruktur 44 kategorisiert werden können. Als Beispiel wurden gewisse Teile der Verzeichnisstruktur 70 in Fig. 3 "vergrößert", um verschiedene Stufen von Klassen darzustellen, wobei es sich bei der "Stufe" einer Klasse um den gleichen Ausdruck handelt wie bereits in Fig. 2 beschrieben. Obgleich das Beispiel von Verzeichnisstruktur 70 Geschäftsvorgang-Dokumentenschemen 72, wie vorstehend beschrieben, benutzen kann, können alle anderen geeigneten Schemen 80 zusätzlich zu oder an Stelle von Geschäftsvorgang-Dokumentenschemen 72 benutzt werden. Das gleiche Dokument kann in mehreren Schemen 80 enthalten sein und diese alternativen Schemen 80 können in Verzeichnisstruktur 70 enthalten sein und als Teil des oder getrennt vom GCD 42 gespeichert werden. Die Ordnung der Verzeichnisstruktur 70 ist ähnlich wie die Ordnung der Verzeichnisstruktur 44, mit der Ausnahme, dass sich die Verzeichnisstruktur 70 auf Dokumentenklassen bezieht.
  • Wie in Fig. 3 dargestellt, enthält die Käuferdokumentenklasse 74 Dokumente, die aus der Sicht des Käufers geordnet sind. Die Verkäuferdokumentenklasse 76 enthält Dokumente, die aus der Sicht des Verkäufers geordnet sind und die Dokumentenklasse 78 enthält alle Dokumente. Dokumente aus der Sicht des Käufers aus einem Geschäftsvorgang zwischen einem Käufer 20 und Verkäufer 30 enthalten günstige Bedingungen für den Käufer und wurden typischerweise von einem Käufer in einem früheren Geschäftsvorgang erstellt. Dokumente aus der Sicht des Verkäufers aus früheren Geschäftsvorgängen zwischen einem Käufer 20 und Verkäufer 30 enthalten Bedingungen, die günstiger für den Verkäufer als den Käufer sind und wurden generell von einem Käufer in einem früheren Geschäftsvorgang erstellt. Zum Beispiel können die Bedingungen, die ein Dokument enthält, je nach der entsprechenden Verhandlungsstärke des Käufers und Verkäufers, die an dem Geschäftsvorgang beteiligt sind, unterschiedlich sein. Wenn der Verkäufer eine größere Verhandlungsstärke hat, spiegelt sich dies generell in dem Dokument wider, das Bedingungen hat, die günstiger für den Verkäufer sind. Wenn jedoch der Käufer eine größere Verhandlungsstärke hat, enthält das Dokument typisch Bedingungen, die günstiger für den Käufer als den Verkäufer sind. Wenn der Käufer 20 daher nach einem bestimmten Dokument sucht, kann er daran interessiert sein, nur solche Dokumente zu finden, die den Käufer und nicht den Verkäufer begünstigen, wenn der Käufer 20 eine größere Verhandlungsstärke hat oder ein Dokument aus der Sicht des Verkäufers zu akzeptieren, um alle Verhandlungen mit dem Verkäufer zu verkürzen, da das Dokument den Verkäufer begünstigt.
  • Der Käufer 20 navigiert abhängig von der Art des Dokumentes, das der Käufer 20 sucht, durch die Verzeichnisstruktur 70. Wenn der Käufer 20 nach Bestellungen aus der Sicht des Käufers sucht, würde der Käufer 20 zur Käuferdokumentenklasse 74 und zur Käuferbestellungsklasse 82b navigieren. Der Käufer 20 wäre dann in der Lage, eine Suche nach allen Bestellungen durchzuführen, die aus der Sicht des Käufers abgefasst wurden. Der Käufer 20 kann ferner die Suche in der Käuferbestellungsklasse 82b einengen, indem er nach Bestellungen sucht, die vor unter einem Jahr ausgestellt wurden und sich auf Wattebäusche beziehen. Der Käufer 20 könnte auch an Dokumenten interessiert sein, die mit Auftragsbestätigungen aus der Sicht des Verkäufers verbunden sind und daher durch Verzeichnisstruktur 70 zur Verkäuferdokumentenklasse 76 und Verkäufer- Auftragbestätigungsklasse 84n navigieren, um eine Suche nach allen Auftragsbestätigungen aus der Sicht eines Verkäufers durchzuführen. Dem Käufer 20 könnte es jedoch auch egal sein, ob ein Dokument aus der Sicht des Käufers oder Verkäufers erstellt wurde und er würde dann bevorzugen, die Suche nach allen verfügbaren Dokumenten durchzuführen. Wenn dies zutrifft, navigiert der Käufer 20 durch die Verzeichnisstruktur 70 zur Dokumentenklasse 78, die alle Dokumente enthält. Der Käufer 20 kann dann eine der Dokumentenunterklassen 86a-86n durchsuchen, abhängig davon, nach welcher Dokumentenart der Käufer 20 sucht. Der Käufer 20 kann auch Dokumentenklasse 78 durchsuchen und alle Dokumente, ohne seine Suche weiter einzuschränken.
  • In der Verzeichnisstruktur 70 und in den Dokumentenklassen können die Dokumente als Standarddokumente und spezifische Dokumente kategorisiert und im gemeinsamen Dokumentenspeicher 35 und in den Verkäuferdatenbanken 32 gespeichert werden, wie vorstehend in Fig. 2 beschrieben. Die Verwendung der Verzeichnisstruktur 70 und der Zeiger für den gemeinsamen Dokumentenspeicher 35 und die Verkäuferdatenbanken 32 wurden, wie vorstehend in Fig. 2 beschrieben, im Verhältnis zur Verzeichnisstruktur 44 beschrieben, außer dass die Dokumente in Dokumentenklassen anstatt in Produktklassen klassiert sind. In Verzeichnisstruktur 44 werden die Dokumente mit bestimmten Produkten in Verbindung gebracht und die Dokumente werden durch die Produktklassen durchsucht. In Verzeichnisstruktur 70 werden die Dokumente nicht in Produktklassen sondern in Dokumentenklassen klassiert, die sich auf die Art des Dokumentes beziehen. Bei Verzeichnisstruktur 44 sucht ein Käufer oder Verkäufer nach einem bestimmten Produkt und er will Dokumente finden, die mit diesem Produkt verbunden sind. Bei Verzeichnisstruktur 70 ist ein Käufer oder Verkäufer an einer Dokumentenart interessiert und er will alle Dokumente einer spezifischen Art finden, unabhängig davon, ob die Produkte in den Dokumenten damit verbunden sind oder nicht.
  • Fig. 4 zeigt eine Beispieltabelle 150, die in einer Verkäuferdatenbank 32 bzw. einem Speicher 34 enthalten sein kann. Die Datenbank 32 und der Speicher 34 können ein oder mehrere Tabellen 150 enthalten und jede Tabelle 150 kann Daten enthalten, die sich auf ein oder mehrere Produkte beziehen. Zum Beispiel enthält die Beispieltabelle 150 Daten, die sich auf verschiedene Stiftarten beziehen. Tabelle 150 kann auch Daten für andere Produktarten enthalten (zum Beispiel andere Büromaterialarten) oder derartige Daten können in anderen Tabellen 150 in der Datenbank 32 bzw. im Speicher 34 enthalten sein. Die Tabelle 150 enthält mehrere Spalten 152, in denen sich Daten befinden, die sich auf ein bestimmtes Produktattribut oder Verkäuferattribut beziehen. Obgleich eine Beispiel- Spaltenzahl 152 mit Beispiel-Produktattributwerten und -Verkäuferattributwerten dargestellt ist, ist darauf hinzuweisen, dass eine entsprechende Anzahl und Art Produktattribute, Verkäuferattribute oder andere Datenkategorien in Tabelle 150 enthalten sein können. Außerdem und wie kurz vorstehend beschrieben, können Verkäuferdaten und Produktdaten auf verschiedene Tabellen aufgeteilt werden anstatt in der gleichen Tabelle enthalten zu sein, wie in Beispieltabelle 150 dargestellt.
  • Die Tabelle 150 enthält auch mehrere Reihen 154, die jeweils einem bestimmten Produkt entsprechen können und die je Werte für ein oder mehrere der Produktattribute und Verkäuferattribute enthalten. Jeder der Werte (die ein numerisches, Text- oder jedes andere geeignete Format aufweisen können) befindet sich am Schnittpunkt der Reihe 154, die mit einem bestimmten Produkt verbunden ist, mit der Spalte 152, die ein bestimmtes Produktattribut oder Verkäuferattribut enthält. Jeden dieser Schnittpunkte kann man als Feld oder Zelle 156 von Tabelle 150 bezeichnen. Wenn Verkäuferdaten und Produktdaten integriert sind, kann jede Reihe 154 alle Produktdaten und Verkäuferdaten für das Produkt enthalten, das Reihe 154 entspricht. Alternativ können eine oder mehrere Reihen den Verkäuferdaten gewidmet sein, die für alle Produkte gelten, die ein Verkäufer 30 anbietet oder einen Untersatz solcher Produkte. Wenn Verkäuferdaten und Produktdaten getrennt sind, kann jede Reihe in der Verkäuferdatentabelle einem Satz Verkäuferattributwerte entsprechen, der mit einem oder mehreren Produkten in der Datentabelle verbunden ist, so dass die Verkäuferdaten für ein Produkt erreichbar sind, wenn Zugriff auf die Produktdaten für das Produkt genommen wird und umgekehrt. Ferner können Dokumente als Einzeldateien bzw. als Daten in Tabellen gespeichert werden, z. B. mit Produkt- und Verkäuferdaten.
  • Die Daten in einer oder mehreren Spalten 152 von Tabelle 150 können indexiert werden, um die Lesegeschwindigkeit der Datenbank zu erhöhen. Zum Beispiel können die Felder 156 der Stiftfarben-Spalte 152d und Spitzengrößen-Spalte 152e so indexiert werden, dass eine Datenbankanfrage für einen Stift, der eine bestimmte Farbe und Spitzengröße haben soll, schnell ausgeführt werden kann. Die Daten in Tabelle 150 können unter Verwendung einer geeigneten Datenbank-Indexiertechnik indexiert werden. Das typische Ergebnis einer solchen Indexierung sieht so aus, dass wenn das GCD 42 oder ein Käufer 20 indexierte Daten aus einer Datenbank 32 bzw. einem Speicher 34 anfordert, das damit verbundene Datenbank-Managementsystem (oder eine andere geeignete Schnittstelle zur Datenbank 32 bzw. zum Speicher 34) nicht jedes Feld 156 in den Tabellen 150 in der Datenbank 32 bzw. im Speicher 34 durchsuchen muss, um die angeforderten Daten zu finden. Statt dessen können die Daten so indexiert werden, dass wenn eine Anfrage für Produkte mit gewissen Produktattributwerten bzw. Verkäufern 30 mit bestimmten Verkäuferattributwerten, die indexiert worden sind, vorgelegt wird, das Datenbank- Managementsystem bereits die Speicherzellen für derartige Produkte in Tabelle 150 kennt und die Daten gefunden werden können, die mit diesen Produkte verbunden sind, ohne die ganze Tabelle 150 oder die Datenbank 32 bzw. den Speicher 34 für die Produkte durchsuchen zu müssen. Wenn zum Beispiel die Felder für die Stiftfarbe 156 und die Felder für die Spitzengröße 156 der Spalten 152d bzw. 152e indexiert werden, gibt die Indexierung im typischen Fall die Speicherzelle aller Stifte an, deren Farbe schwarz ist und die eine mittlere Spitze haben.
  • Wenn eine Anfrage vorgelegt wird, die auch einen Wert für ein oder mehrere nicht indexierte Produktattribute (zum Beispiel eine Anfrage nach Stiften, die von der Firma ABC hergestellt werden, wenn die Felder für den Hersteller 156 in Spalte 152c nicht indexiert sind) bzw. Verkäuferattribute angibt, kann das damit verbundene Datenbank- Managementsystem eine Durchsuchung der Datenbank 32 bzw. des Speichers 34 nach Produkten durchführen, die den vorgeschriebenen Wert für ein oder mehrere nicht indexierte Attribute oder Verkäuferattribute enthält. Eine solche Suche kann jedoch auf die Produkte beschränkt werden, die bereits (unter Verwendung der Indexierung) als solche erkannt wurden, die die vorgeschriebenen Werte der indexierten Attribute enthalten (zum Beispiel schwarze Stifte mit mittlerer Spitze) bzw. Verkäuferattribute, die auch in der Suche enthalten sind. Daher kann die Zeit, die zur Durchführung der Suche erforderlich ist, reduziert werden, obgleich ein oder mehrere Produktattributwerte oder Verkäuferattributwerte, nach denen gesucht wird, nicht indexiert sind.
  • Fig. 5 zeigt ein Beispiel des E-Commerce-Systems 10 in größerem Detail. Wie vorstehend beschrieben, können zahlreiche Käufer 20 und Verkäufer 30 unter Verwendung des Netzwerks 12 mit dem Server GCD 40 verbunden werden. Die Käufer 20 erreichen den Server GCD 40 mit einem Web-Browser oder in jeder andern geeigneten Weise und der Server GCD 40 kann den Käufern 20 unter Verwendung eines Web-Servers Zugriff auf das GCD 42 verschaffen oder in jeder anderen geeigneten Weise. Obgleich das GCD 42 als in den Server GCD 40 eingebaut dargestellt wird, können GCD 42 interne oder externe Bestandteile des Servers GCD 40 sein, wie vorstehend beschrieben. Der Server GCD 40 kann auch die Hardware bzw. Software zur Implementation einer oder mehrerer GCD- Schnittstellen 43 enthalten. Ein Käufer 20 kann Zugriff zum Server GCD 40 erhalten und eine GCD Schnittstelle 43 zur Suche oder zum Navigieren durch das GCD 42 benutzen, durch die Verkäuferdatenbanken 32, den Speicher 34 und den gemeinsamen Dokumentenspeicher 35. Informationen können zwischen Käufern 20, Verkäufern 30 und dem GCD 42 mittels HTTP, XML, SOAP oder jedem geeigneten Datenaustauschverfahren ausgetauscht werden. Jeder Käufer 20 und Verkäufer 30 kann eine spezifische Kennung erhalten, so dass die an einem Geschäftsvorgang Beteiligten mit Hilfe des GCD 42 erkannt werden können. Jedem Käufer 20 und Verkäufer 30 kann auch im Hinblick auf einen Geschäftsvorgang eine Rolle zugeteilt werden. Wie vorstehend beschrieben, kann ein Käufer 20 in einem Geschäftsvorgang ein Käufer 20 sein und in einem anderen Geschäftsvorgang ein Verkäufer 30 und umgekehrt.
  • In einem Beispiel-Suchvorgang kann ein Käufer 20 Zugriff auf eine GCD- Schnittstelle 43 nehmen und eine Suche durch das GCD 42 durchführen. Die GCD Schnittstelle 43 kann es dem Käufer 20 gestatten, sowohl durch die Klassen das GCD 42 zu navigieren oder zu "browsen" und nach einer bestimmten Klasse oder Klassen zu suchen. Zum Beispiel kann der Käufer 20 entweder durch das GCD 42 navigieren, um eine Klasse zu finden, in der Stifte kategorisiert sind oder der Käufer 20 kann das GCD 42 nach Klassennamen einschließlich dem Wort "Stift" durchsuchen. Jedes andere geeignete Verfahren zum Finden einer bestimmten Klasse kann ebenfalls benutzt werden. Wenn der Käufer 20 eine entsprechende Klasse für das Produkt gefunden hat, bzw. das Dokument, das der Kunde 20 sucht, kann der Käufer 20 dann eine Liste der Produkte bzw. Dokumente in einer Klasse anfordern, die sich mit entsprechenden Produktattributwerten deckt. Wenn zum Beispiel der Käufer nach Filzstiften der Klasse 60b sucht, kann der Käufer 20 alle Produkte in Klasse 60b (Filzstifte) anfordern, die rot sind und eine feine Spitze haben und die von einem in den Vereinigten Staaten ansässigen Verkäufer 30 verkauft werden.
  • Eine Suchschnittstelle 45 oder jeder andere geeignete Bestandteil des Servers GCD 40 können eine solche Suche ermöglichen, indem sie suchen oder Suchen des Speichers 34 bzw. der Verkäuferdatenbanken 32 anfordern, die, wie vorstehend beschrieben, von einem oder mehreren Zeigern gekennzeichnet sind, die mit Filzstiften der Klasse 60b verbunden sind. Sie Suchschnittstelle 45 kann für den Käufer 20 ein Suchformular anzeigen, in das er ein oder mehrere Suchkriterien eingibt. Die einsetzbaren Suchkriterien können in ein Suchformular eingegeben werden oder es kann dem Käufer 20 gestattet werden, eine generelle Suche der Datenbanken 32 bzw. des Speichers 34 nach bestimmten Bedingungen durchzuführen. Zum Beispiel kann die Suchschnittstelle 45 für den Käufer 20 ein Suchformular anzeigen, das auf Klasse 60b zugeschnitten ist, das Felder enthält, in die der Käufer 20 die gewünschte Stiftfarbe, die Spitzenstärke oder alle anderen produktbezogenen oder verkäuferbezogenen Kriterien eingeben kann. In einem Ausführungsbeispiel reagieren die Felder des Suchformulars auf einige oder alle Produktattribute in der Produktontologie bzw. auf Verkäuferattribute innerhalb der Verkäuferontologie, die der Produktklasse entsprechen, die gewählt wurde und der Käufer 20 kann Produktwerte für die Produktattribute und Verkäuferattribute in die entsprechenden Felder des Suchformulars eingeben. Anstelle eines Suchformulars kann die Suchschnittstelle 45 ein Einzelfeld anbieten, in das der Käufer die gewünschten Ausdrücke für die Suche wie "rot" und "fein" eingibt (mehrere Ausdrücke für die Suche können unter Verwendung von Booleschen Operatoren oder mit jedem anderen geeigneten Verfahren eingegeben werden).
  • Die Suchschnittstelle 45 oder jeder andere geeignete Bestandteil des Servers GCD 40 können auch Suchanforderungen ermöglichen, indem sie Zugriff auf ein Käuferprofil für Käufer 20 nehmen, das Informationen enthält, die anhand früherer Suchanforderungen des Käufers 20, früherer E-Commerce-Geschäftsvorgänge mit dem Käufer 20 oder anderer Vorgänge oder Maßnahmen seitens des Käufers 20 kompiliert wurden. Zum Beispiel kann ein Käuferprofil eine Liste von Verkäufern 30 enthalten, die mit Verkäuferattributwerten übereinstimmen, die der Käufer 20 wünschen kann. Eine derartige Liste kann anhand der Ergebnisse früherer Suchen des Käufers 20 kompiliert werden. Die Suchschnittstelle 45 kann zu jedem geeigneten Zweck Zugriff auf das Profil für den Käufer 20 nehmen. In einem Ausführungsbeispiel kann die Suchschnittstelle 45 Zugriff auf das Profil für den Käufer 20 nehmen, um automatisch Suchkriterien wie Produktattributwerte bzw. Verkäuferattributwerte für eine Suche zu erstellen. Die Suchschnittstelle 45 kann auch Zugriff auf das Profil für den Käufer 20 nehmen, um ihre Suche nach Produkten auf übereinstimmende Produktattributwerte zu beschränken, die der Käufer 20 an die Datenbanken 32 liefert (oder die automatisch generiert werden), die mit dem Verkäufer 30 verbunden sind und von denen bekannt ist, dass sie die Verkäuferattributwerte decken, die der Käufer 20 wünscht (bzw. Daten im Speicher 34, die mit einem solchen Verkäufer 30 verbunden sind).
  • Beruhend auf den vom Käufer 20 gelieferten oder automatisch generierten Suchkriterien kann die Suchschnittstelle 45 dann der/den entsprechenden Verkäuferdatenbank(en) 32 bzw. dem Speicher 34 Informationen zukommen lassen, die fordern, dass die Datenbanken 32 bzw. der Speicher 34 jeweils eine Liste aller Produkte liefern (einschließlich der damit verbundenen Produktdaten bzw. Verkäuferdaten), die die Suchkriterien erfüllen. Die Datenbanken 32 bzw. der Speicher 34 können auch Daten liefern, die sich auf Attributwerte beziehen, die nicht in den Suchkriterien enthalten waren. Zum Beispiel können die Datenbanken 32 einen Preis und Angaben über die Lieferbarkeit der Produkte, die die Suchkriterien erfüllen, finden, selbst wenn es sich bei dem Preis und der Lieferbarkeit nicht um Suchkriterien handelte. Die Reaktionen auf Anfragen von den Datenbanken 32 bzw. vom Speicher 34 können für den Käufer 20 in jeder geeigneten Weise angezeigt werden. Zum Beispiel können die Produkte entsprechend der Relevanz im Hinblick auf die Suchkriterien nach geeigneten Übereinstimmungskriterien angezeigt werden. Ferner kann das GCD 42 die Produktliste beruhend auf einer Anforderung vom Käufer 20 neu bestellen. Der Käufer 20 kann zum Beispiel anfordern, dass übereinstimmende Produkte in der richtigen Reihenfolge vom billigsten bis zum teuersten in einer Liste aufgeführt werden. Alternativ können die Suchergebnisse direkt dem Käufer 20 von den Datenbanken 32 bzw. dem Speicher 34 mitgeteilt werden.
  • Der Käufer 20 kann ein Produkt aus der Liste wählen, um seinem Wunsch dahingehend Ausdruck zu verleihen, dass er einen Geschäftsvorgang für des Produkt einleiten, z. B. den Kauf eines Produkts tätigen möchte. Bei einer solchen Wahl kann das GCD 42 dem Käufer 20 eine Speicherkennung (RID) mitteilen, die den gewählten Verkäufer 30 kennzeichnet und eine globale spezifische Kennung (GUID) für das Produkt. Eine RID kann zum Beispiel die Netzwerkadresse (wie eine IP-Adresse) eines Verkäufer- Netzwerkknotens 30 sein oder sie kann mit der Netzwerkadresse in einer Tabelle verbunden sein (in diesem Fall kann das GCD 42 die RID benutzen, um die damit verbundene Netzwerkadresse nachzusehen und dann die Netzwerkadresse an den Käufer 20 weiterzugeben). Der Käufer hat Zugriff zum Verkäufer 30 durch Einsatz der RID (oder der Netzwerkadresse) und fordert einen Geschäftsvorgang unter Verwendung der GUID hinsichtlich des Produkts an. Das GDC 42 kann sogar eine Verbindung einschließlich einer URL von einer Website liefern, die mit dem Verkäufer 30 verbunden ist oder kann ein anderes geeignetes Verfahren für den Käufer 20 liefern, mit dem er mit dem Verkäufer 30 verbunden wird. Obgleich nur ein Beispielpfeil (zwischen dem Käufer 20n und dem Verkäufer 30n) angegeben ist, um den Informationsaustausch zwischen dem Käufer 20 und dem Verkäufer 30 darzustellen, wird darauf hingewiesen, dass die Käufer 20 mit allen Verkäufern 30 in Verbindung treten könnte, um die entsprechenden Geschäftsvorgänge durchzuführen
  • Das als Beispiel herangezogene E-Commerce-System 10 enthält ferner ein Sicherheitsmodul 41 und ein Intelligenzmodul 47. Obgleich das Sicherheitsmodul 41 und das Intelligenzmodul 47 so dargestellt wurden, dass sie integrale Bestandteile des Servers GCD 40 sind, können das Sicherheitsmodul 41 und das Intelligenzmodul 47 interne oder externe Bestandteile des Servers GCD 40 sein. Wie vorstehend beschrieben, kann des System 10 zum Speichern und Klassieren von Standarddokumenten und spezifischen Dokumenten benutzt werden. Wenn zum Beispiel ein Käufer 20a einen Geschäftsvorgang mit einem Verkäufer 30a abschließt, der die Benutzung von einem oder mehreren Dokumenten anfordert, kann das System 10 die in Geschäftsvorgängen 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 spezifische Dokumente handelt, wie vorstehend beschrieben. Angenommen, dass der abgeschlossene Geschäftsvorgang zwischen dem Käufer 20a und dem Verkäufer 30a die Benutzung eines Standarddokumentes und eines spezifischen Dokumentes umfasst, analysiert der Server GCD 40 die Dokumente um festzustellen, ob die Dokumente Standard- oder spezifische Dokumente sind. Der Server GCD 40 speichert das Standarddokument im gemeinsamen Dokumentenspeicher 35 und das spezifische Dokument in der Verkäuferdatenbank 32, verbunden mit dem Verkäufer 30a.
  • Die Standarddokumente und spezifischen Dokumente können vertrauliche oder Wettbewerbsinformationen enthalten, einschließlich der Namen des Käufers 20 und Verkäufers 30, die an dem Geschäftsvorgang beteiligt sind, dem gekauften Produkt, der gekauften Menge und dem Einkaufspreis. Da die Dokumente im gemeinsamen Dokumentenspeicher 35 und den Verkäuferdatenbanken 32 gespeichert sind, sind die Dokumente für andere Käufer 20 und Verkäufer 30 über das GCD 42 erreichbar, die vertrauliche Informationen des Käufers 20 und Verkäufers 30 sind und zur Verfügung stehen. Daher verschlüsselt das Sicherheitsmodul 41 die Standarddokumente und die spezifischen Dokumente (oder Teile der Dokumente, wie nachstehend beschrieben) wenn die Dokumente in einem gemeinsamen Dokumentenspeicher 35 und in einer Verkäuferdatenbank 32 gespeichert sind. Der Käufer 20 und der Verkäufer 30, mit denen die Dokumente verbunden sind, erhalten beide die erforderliche Genehmigungsstufe zum Entschlüsseln der Dokumente, so dass der damit verbundene Käufer 20 und Verkäufer 30 die Dokumente vollständig zusammen mit den vertraulichen Informationen durchsehen können. Damit ist ein Käufer 20 in der Lage, das GCD 42 zur Suche nach und Durchsicht von allen Dokumenten zu benutzen, an denen der Käufer 20 beteiligt war, wodurch das E- Commerce-Geschäftsvorgangssystem 10 mit dem Dokumentenspeicher- und - Durchsichtelement versehen wird. Die eigenen Dokumente eines Käufers oder Verkäufers (wenn ein Käufer oder Verkäufer an einem Dokument beteiligt ist) können daher Benutzerdokumente genannt werden. Ein Käufer 20 oder Verkäufer 30 hat typisch hinsichtlich seiner verbundenen Benutzerdokumente unbehinderten Zugriff zu allen mit ihnen verbundenen Benutzerdokumenten. Zum Beispiel sind die eigenen Dokumente des Käufers 20a Benutzerelemente für den Käufer 20a und der Käufer 20a hat unbehinderten Zugriff zu allen Benutzerdokumenten des Käufers 20a, weil der Käufer 20a an allen Geschäftsvorgängen beteiligt ist, aus denen sich die Dokumente ergaben. Die Benutzerdokumente des Käufers 20a sind Dokumente Dritter für alle anderen Käufer 20, weil alle anderen Käufer 20 nicht an den Geschäftsvorgängen des Käufers 20a beteiligt waren. Daher hat jeder Käufer 20 seine eigenen Benutzerdokumente, wenn er an einem Geschäftsvorgang beteiligt war und dieser Käufer 20 ist im Besitz der erforderlichen Genehmigungsstufe, um Zugriff auf die Benutzerdokumente nehmen zu können. Wenn jedoch ein Käufer 20 nicht an einem Geschäftsvorgang beteiligt ist, werden alle Dokumente, die sich aus einem Geschäftsvorgang ergeben, zu Dokumenten Dritter für den Käufer 20 und der Käufer 20 hat keine Genehmigung zum Zugriff auf und für die Durchsicht von Dokumenten Dritter.
  • Nachdem die Dokumente im gemeinsamen Dokumentenspeicher 35 bzw. den Verkäuferdatenbanken 32 gespeichert und (ganz oder teilweise) verschlüsselt wurden, kategorisiert der Server GCD 40 oder jeder andere entsprechende Bestandteil die Dokumente im GCD 42 für beide Dokumentenklassen und Produktklassen, wie in Fig. 2 und 3 beschrieben. Die Klassifizierung von Dokumenten in Dokument- und Produktklassen erleichtert das spätere Finden der Dokumente des Käufers 20 und Verkäufers 30. Der Server GCD 40 prüft die Dokumente, um die Dokumentenart zu bestimmen und auf welche Produkte sich das Dokument bezieht. Der Server GCD 40 verbindet die Zeiger mit den Dokumenten und dem GCD 42, so dass das GCD 42 die Dokumente im gemeinsamen Dokumentenspeicher 35 und in den Verkäuferdatenbanken 32 finden kann, wenn der Käufer 20 eine Suche nach den Dokumenten ausführt. Zum Beispiel kann die Bestellung eines Käufers über Rollerball-Stifte mit der Rollerball-Dokumentenklasse 63c in der Rollerball-Stiftklasse 60c der Verzeichnisstruktur 44, Dokumentenklasse 82b der Verzeichnisstruktur 70 für die Käuferbestellung und der Bestelldokumentenklasse 86b der Verzeichnisstruktur 70 verbunden werden.
  • Die Fähigkeit des Käufers 20, Benutzerdokumente durchsehen zu können, erhöht die Funktionalität des Systems 10 und gibt dem System 10 ein Dokumentenspeicher- und Wiederverwendungselement. Aber der Käufer 20 muss eine Möglichkeit für die Speicherung, den Zugriff und die Durchsicht von Benutzerdokumenten haben, während er vor anderen Käufern 20 die vertraulichen oder Wettbewerbsinformationen schützt, die in den Benutzerdokumenten enthalten sind. Wenn der Käufer 20 versucht, Zugriff auf Benutzerdokumente zu nehmen und diese durchzusehen, bestimmt das Sicherheitsmodul 41, ob sich der Käufer 20 im Besitz der erforderlichen Genehmigungsstufe zur Durchsicht der Benutzerdokumente befindet. In einem Ausführungsbeispiel kann das Sicherheitsmodul 41 jedes Dokument mit einem Passwort schützen und das richtige Passwort zum Entschlüsseln der Dokumente anfordern, wenn das Sicherheitsmodul 41 die Dokumente verschlüsselt. Wenn der Käufer 20 eine Aufforderung für den Zugriff auf die Benutzerdokumente vorlegt, bittet das Sicherheitsmodul 41 den Käufer 20 um das richtige Passwort für die Entschlüsselung. Weil es sich bei den Dokumenten um die Benutzerdokumente für den Käufer 20 handelt, ist der Käufer 20 im Besitz der erforderlichen Genehmigungsstufe und des richtigen Passworts. Wenn der Käufer 20 das richtige Passwort eingibt, erhält der Käufer 20 vollen Zugriff zu den gesamten Benutzerdokumenten. Nachdem der Käufer 20 den vollen Zugriff hat, kann der Käufer 20 die Benutzerdokumente für frühere Kauflisten durchsehen, um ihm bei zukünftigen Bestellungen zu helfen oder er kann die Benutzerdokumente für die jetzigen Geschäftsvorgänge wiederverwenden oder ändern.
  • Wenn der Käufer 20 beschließt, ein Benutzerdokument erneut für einen laufenden Geschäftsvorgang zu verwenden, stehen dem Käufer 20 mehrere Möglichkeiten zur Wahl. Wenn der Käufer 20 mit dem Produkt und dem Verkäufer von einem früheren Geschäftsvorgang zufrieden ist, kann der Käufer 20 das Intelligenzmodul 47 anweisen, genau den gleichen Auftrag wieder an den gleichen Verkäufer auszustellen und dazu das Dokument aus dem früheren Geschäftsvorgang zu benutzen. Das Intelligenzmodule 47 kann bestimmen, welche Teile im Benutzerdokument generisch und spezifisch für den früheren Geschäftsvorgang sind und es kann automatisch alle Teile der Dokumente, die zu aktualisieren sind, aktualisieren (wie den Datenteil). Nachdem das Dokument aktualisiert wurde, wird es an den Verkäufer gesandt und der Geschäftsvorgang ist abgeschlossen. Wenn der Käufer 20 nicht mit dem Verkäufer aus dem früheren Geschäftsvorgang zufrieden war, kann der Käufer 20 das Benutzerdokument aus dem früheren Geschäftsvorgang benutzen aber statt dessen das Intelligenzmodul 41 anweisen, die Verkäuferinformationen zu ändern, alle generischen Teile zu aktualisieren, die zu aktualisieren sind und das Benutzerdokument erneut an den neuen Verkäufer auszustellen. Durch die erneute Ausstellung des Dokumentes kann der Käufer 20 die Bestellungen und damit die Geschäftsvorgänge beschleunigen, weil der Käufer 20 keine Zeit mit der erneuten Eingabe von Informationen in die Dokumente verschwendet.
  • Wenn ein Käufer 20 nur in der Lage ist, Zugriff auf Benutzerdokumente zu nehmen, wird die Funktionalität und Nützlichkeit des Systems 10 begrenzt und es würde verhindern, dass ein Käufer 20, dem das System 10 neu ist, die Dokumentenspeicher- und Wiederverwendungsfunktion vorteilhaft nutzt, weil der Käufer 20 keine Benutzerdokumente für die Wiederverwendung hätte. Daher ist es wünschenswert, für den Käufer 20 und den Verkäufer 30 den Zugriff und die Verwendung von Dokumenten Dritter vorzusehen, während vertrauliche Informationen in den Dokumenten Dritter weiterhin geschützt werden. Das Intelligenzmodul 47 gestattet dem Käufer 20 und dem Verkäufer 30 den Zugriff zu und die Wiederverwendung von Dokumenten Dritter, während vertrauliche Informationen in den Dokumenten weiterhin geschützt werden. Das Intelligenzmodul 47 nimmt die Dokumente Dritte und unterteilt sie in einen oder mehrere Teile, so dass generische Dokumente aus den Dokumenten Dritter entstehen. Die generischen Dokumente gestatten dem Käufer 20 beschränkten Zugriff zu den Dokumente Dritter. Beim Erstellen generischer Dokumente überprüft das Intelligenzmodul 47 ein Dokument Dritter und entfernt oder verschlüsselt Informationen aus den Teilen, die vertrauliche Informationen enthalten und solchen, die für bestimmte Geschäftsvorgänge gelten.
  • Man könnte zum Beispiel annehmen, dass der Käufer 20b blaue Kugelschreiber kaufen möchte und eine Suche unter Verwendung des GCD 42 nach Dokumenten durchführt, die sich auf blaue Kugelschreiber beziehen. Bei der Suche können mehrere Dokumente gefunden werden, die die Suchkriterien erfüllen, von denen eins ein Dokument für einen Geschäftsvorgang zwischen dem Käufer 20a und dem Verkäufer 30a ist. Der Käufer 20b ist nicht in der Lage festzustellen, dass sich das Dokument auf einen Abschluss zwischen einem Käufer 20a und einem Verkäufer 30a bezieht sondern lediglich, dass es sich bei dem Dokument um ein Dokument Dritter handelt. Dem Käufer 20b ist die Identität des Käufers 20a und des Verkäufers 30a unbekannt. Es handelt sich für den Käufer 20b um ein Dokument Dritter, weil der Käufer 20b nicht an dem Geschäftsvorgang beteiligt war. Der Käufer 20b würde nicht wissen, dass der Geschäftsvorgang zwischen dem Käufer 20a und dem Verkäufer 30a abgeschlossen wurde, sondern lediglich, dass es sich um ein Dokument Dritter zwischen zwei Käufern und Verkäufern handelt, bei denen eine Partei der Käufer 20b ist.
  • Das Intelligenzmodul 47 kann das Dokument Dritter in mehrere Teile wie Kopfzeile, Fußzeile, Kontaktinformationen für Käufer, Kontaktinformationen für Verkäufer, Datum, Bestellmenge, Kaufpreis, Gegenstand, Beschreibung, Bedingungen und alle anderen geeigneten Teile unterteilen. Das Intelligenzmodul 47 kann bestimmen, welche Teile generisch und welche für den Geschäftsvorgang zwischen dem Käufer 20a und Verkäufer 30a spezifisch sind. Der Käufer 20a bzw. der Verkäufer 30a kann die generischen Teile feststellen oder die generischen Teile können in jeder anderen geeigneten Weise festgestellt werden. Zum Erstellen eines generischen Dokumentes entfernt das Intelligenzmodul 47 aus dem Dokument Dritter die Informationen in den Teilen, die spezifisch für den Geschäftsvorgang zwischen dem Käufer 20a und dem Verkäufer 30a sind oder die entweder für den Käufer 20a oder den Verkäufer 30a vertraulich sind und belässt die Informationen in den generischen Teilen des Geschäftsvorgangs. Beim Erstellen eines generischen Dokumentes kann das Intelligenzmodul 47 zum Beispiel die Namen und Kontaktinformationen für den Käufer 20a und den Verkäufer 30a, die Bestellmenge und den Kaufpreis entfernen aber diese Teile noch im generischen Dokument belassen, so dass der Käufer 20b seine eigenen Informationen darin ausfüllen kann. Das Intelligenzmodul 47 belässt im generischen Dokument die Teile und Informationen für Kopfzeilen, Fußzeilen, die Produktbeschreibung sowie die Bedingungen. Als Alternative zum Entfernen von vertraulichen Informationen kann das Intelligenzmodul 47 solche Informationen verschlüsseln. Das Intelligenzmodul 47 kann auch den Datenteil im generischen Dokument mit Informationen über das laufende Datum dynamisch aktualisieren. Das Intelligenzmodul 47 kann auch das generische Dokument automatisch und dynamisch mit anderen laufenden Informationen wie dem Namen des Käufers und des Verkäufers und den Kontaktinformationen aktualisieren, wenn der Käufer 20b ein registrierter Benutzer des Systems 10 ist und solche Informationen dem Intelligenzmodul 47 ohne weiteres zur Verfügung stehen. Zum Ausfüllen des generischen Dokumentes kann der Käufer 20b oder der Verkäufer 30 einen Teil der Informationen im generischen Dokument manuell eingeben, wie die gewünschte Menge und den Kaufpreis. Nachdem das generische Dokument ausgefüllt ist, kann der Käufer 20b das Dokument zum Abschluss des Geschäftsvorgangs benutzen.
  • In späteren Geschäftsvorgängen könnte ein Käufer 20 nach bestimmten Dokumenten suchen wollen. Der Käufer 20 kann Zugriff auf die GCD-Schnittstelle 43nehmen und die Suche des gemeinsamen Dokumentenspeichers 35 bzw. von ein oder mehreren Verkäuferdatenbanken 32 unter Verwendung des GCD 42 vornehmen. Die Schnittstelle GCD 43 kann es dem Käufer 20 ermöglichen, sowohl durch die Produktklassen wie auch durch die Dokumentenklassen des GCD 42 zu navigieren oder zu "browsen" und nach einer bestimmten Klasse oder Klassen zu suchen. Zum Beispiel kann der Käufer 20 entweder durch die Produktklassen des GCD 42 navigieren, um Dokumente zu finden, die sich auf bestimmte Produkte beziehen oder der Käufer 20 kann die Dokumentenklassen das GCD 42 nach einer bestimmten Dokumentenart durchsuchen. Alle anderen geeigneten Verfahren zum Finden eines Dokumentes können ebenfalls angewandt werden. Wenn der Käufer 20 die entsprechende Klasse für das gewünschte Dokument gefunden hat, kann der Käufer 20 eine Liste der Dokumente in der Klasse anfordern, die mit einem gewissen Produkt bzw. mit Dokumentenattributwerten übereinstimmen. Der Käufer 20 hat vollen Zugriff zu allen Benutzerdokumenten und beschränkten Zugriff zu Dokumenten Dritter (wie generischen Dokumenten). Der Käufer 20 kann die Suchschnittstelle 45 für die Suche nach Dokumenten in der gleichen Weise benutzen wie bei der Suche nach Produkten, wie vorstehend beschrieben.
  • Eine Suchschnittstelle 45 oder jeder andere geeignete Bestandteil des Servers GCD 40 können eine solche Anforderung durch Suchen oder die Anforderung von Suchen des gemeinsamen Dokumentenspeichers 35 bzw. der Verkäuferdatenbanken 32 ermöglichen, die von einem oder mehreren Zeigern gekennzeichnet sind, die mit den Dokumenten, wie vorstehend beschrieben, verbunden sind. Die Suchschnittstelle kann dem Käufer 20 ein Suchformular zur Verfügung stellen, mit dem ein oder mehrere Suchkriterien für die gewünschten Dokumente eingegeben werden. Die Art der Suchkriterien, die benutzt werden, kann auf dem Suchformular angegeben sein oder dem Käufer 20 ist es möglich, eine generelle Durchsuchung der Verkäuferdatenbanken 32 und des gemeinsamen Dokumentenspeichers 35 hinsichtlich gewisser Ausdrücke durchzuführen. Zum Beispiel kann die Suchschnittstelle 45 dem Käufer 20 ein Suchformular liefern, das auf Klasse 82c zugeschnitten ist, das Felder enthält, in die der Käufer 20 die gewünschten dokumentbezogenen Kriterien eingeben kann. Statt eines Suchformulars kann die Suchschnittstelle 45 auch ein Einzelfeld liefern, in das der Käufer die gewünschten Ausdrücke für die Suche wie "RFQ" und "Kugelschreiber" eingibt (Ausdrücke für die mehrfache Suche können mit Booleschen Operatoren oder einer anderen geeigneten Technik eingegeben werden).
  • Beruhend auf den vom Käufer 20 gelieferten Suchkriterien oder solchen, die automatisch erzeugt wurden, kann die Suchschnittstelle 45 eine Anfrage an die entsprechende(n) Verkäuferdatenbank(en) 32 bzw. den gemeinsamen Dokumentenspeicher 35 richten und fordern, dass die Datenbanken 32 und der gemeinsame Dokumentenspeicher 35 eine Liste aller Dokumente finden, die den Suchkriterien entsprechen. Die Reaktion auf die Anfragen der Datenbanken 32 und des gemeinsamen Dokumentenspeichers 35 können dem Käufer 20 in jeder geeigneten Weise angezeigt werden. Zum Beispiel können die Dokumente in der Reihenfolge ihrer Relevanz zu den Suchkriterien mit allen geeigneten übereinstimmenden Kriterien aufgeführt werden. Außerdem kann das GCD 42 die Dokumentenliste, beruhend auf einer Anforderung seitens des Käufer 20, neu bestellen. Zum Beispiel kann der Käufer 20 fordern, dass übereinstimmende Dokumente so aufgeführt werden, dass die Benutzerdokumente zuerst in der Liste erscheinen, gefolgt von Dokumenten Dritter oder zuerst die Standarddokumente, gefolgt von den spezifischen Dokumenten. Alternativ können die Suchergebnisse von den Verkäuferdatenbanken 32 und den gemeinsamen Dokumentenspeichern 35 direkt dem Käufer 20 mitgeteilt werden.
  • Der Käufer 20 kann ein Dokument aus der Dokumentenliste wählen und durchsehen, um seinen Wunsch kundgeben zu können, dass er das Dokument in einem Geschäftsvorgang benutzen möchte. Wenn das Dokument ein Benutzerdokument ist, befindet sich der Käufer 20 im Besitz der erforderlichen Genehmigungsstufe, um das gesamte Dokument zu verschlüsseln und dann für den jeweiligen Geschäftsvorgang zu ändern. Wenn das Dokument ein Dokument Dritter ist, sieht der Käufer 20 das generische Dokument, das von einem Dritten erstellt worden ist, durch oder er sieht die unverschlüsselten Teile des Dokumentes eines Dritten durch, ohne Zugriff zu vertraulichen Informationen im Dokument eines Dritten. Der Käufer 20 kann dann das Dokument ausfüllen und aktualisieren und den Geschäftsvorgang abschließen.
  • Fig. 6A & 6B zeigen ein Beispielverfahren für die Speicherung, Klassifizierung und Wiederverwendung von Dokumenten unter Verwendung des GCD 42. Das Verfahren beginnt mit einem Schritt 102, in dem das Sicherheitsmodul 41 die Dokumente verschlüsselt, um den Zugriff zu den Dokumenten zu kontrollieren, alle vertraulichen oder Wettbewerbsinformationen in den Dokumenten zu schützen und es einem Käufer 20, der an einem Geschäftsvorgang beteiligt sein will, von dem das Dokument stammt, daher nicht zu gestatten, Zugriff zu den vertraulichen Informationen in dem Dokument zu nehmen oder diese durchzusehen. Wenn die Dokumente verschlüsselt sind, wird jedem verschlüsselten Dokument eine Genehmigungsstufe zugeteilt, so dass wenn der Käufer 20 die gewünschte Genehmigungsstufe besitzt, dieser Käufer 20 das Dokument entschlüsseln und das ganze Dokument durchsehen kann. Ein Käufer 20 kann die erforderliche Genehmigungsstufe für alle Dokumente erhalten, mit denen der Käufer 20 an einem Geschäftsvorgang beteiligt war, zu dem das Dokument gehörte. Daher befindet sich ein Käufer 20 im Besitz der geforderten Genehmigungsstufe für den Zugriff und die Durchsicht der gesamten Benutzerdokumente für den Käufer 20. Der Server GCD 40 speichert die Dokumente in einem oder mehreren Dokumentenspeichern in Schritt 104. Zum Beispiel kann der Server GCD 40 die Standarddokumente im gemeinsamen Dokumentenspeicher 35 speichern und die spezifischen Dokumente in einer oder mehreren Verkäuferdatenbanken 32. Außerdem kann ein Käufer 20 oder ein Verkäufer 30 nur das Standarddokument, nur spezifische Dokumente benutzen oder das Dokument als solches darf nicht differenziert und nur als Dokument gespeichert werden.
  • In Schritt 106 verbindet und kategorisiert der Server GCD 40 Dokumente in mehreren Klassen. Das Kategorisieren der Dokumente in Klassen gestattet es dem Käufer 20, nach Dokumenten zu suchen und diese zu finden, die mit bestimmten Produkten verbunden sind oder Dokumente für ein spezifisches Produkt zu finden, wenn der Käufer 20 nach einem bestimmten Produkt sucht. Der Käufer 20 kann durch das GCD 42 navigieren, indem er nach einem bestimmten Produkt sucht und wenn er das Produkt gefunden hat, nach Dokumenten, die sich auf das Produkt beziehen, suchen, diese finden und sie durchsehen. Zum Beispiel kann der Server GCD 40 ein Bestelldokument für Filzstifte in der Filzstift-Dokumentenklasse 63b und der Stift-Dokumentenklasse 59 aufeinander in Bezug bringen und kategorisieren. Wenn daher der Käufer 20 Filzstifte kaufen will, kann der Käufer 20 ohne Weiteres Dokumente finden, die sich auf Filzstifte beziehen.
  • Der Server GCD 40 bringt in Schritt 108 die Dokumente mit mehreren Dokumentenklassen in Verbindung und ordnet sie. Die Klassifizierung der Dokumente in Dokumentenklassen ermöglicht es dem Käufer 20, ausschließlich nach Dokumenten zu suchen, die unabhängig von jedem Bezug auf spezifische Produkte sind. Zum Beispiel kann der Server GCD 40 die Bestellung von Filzstiften in Bezug bringen und kategorisieren, die aus der Sicht des Käufers in der Bestellung des Käufers in Dokumentenklasse 82b und in der Bestelldokumentenklasse 86b erstellt wurde. Dies gestattet dem Käufer 20 die Suche nach und das Finden von Dokumenten, die lediglich auf der Dokumentenart beruhen, anstatt ein Dokument anhand von etwas zu finden, mit dem das Dokument verbunden ist. Die Kategorisierung der Standarddokumente und der spezifischen Dokumente in Klassen und Dokumentenklassen in Schritt 106 und 108 erstreckt sich darauf, die Zeiger in Bezug auf die Klassen im GCD 42 zu bringen, wobei der Zeiger die Dokumente kennzeichnet, die im gemeinsamen Dokumentenspeicher 35 und in den Verkäuferdatenbanken 32 gespeichert sind und wobei der Zeiger den Käufer 20 auf die gewünschten Dokumente verweist. Ferner und abhängig davon, wie die Dokumente gespeichert und geordnet werden sollen, kann nur Schritt 106 oder nur Schritt 108 ausgeführt werden.
  • Nachdem die Dokumente gespeichert und geordnet worden sind, wird das Verfahren mit Schritt 110 fortgesetzt, bei dem der Käufer 20 Zugriff auf das GCD 42 nimmt und dazu die Schnittstelle GCD 43 für die Suche nach bestimmten Dokumenten verwendet. Wie vorstehend beschrieben, kann der Käufer 20 Zugriff auf das GCD 42 nehmen, indem er einen Web-Browser benutzt oder in jeder anderen geeigneten Weise. Der Käufer 20 navigiert oder durchsucht die Verzeichnisstrukturen 44 oder 70 in Schritt 112 hinsichtlich einer Produkt- oder Dokumentenklasse, die spezifisch genug für den Käufer 20 sind (bzw. einer Klasse, die sich am Ende eines Zweiges befindet), wie vorstehend beschrieben. In Schritt 114 wählt der Käufer 20 eine gewünschte Klasse. Wenn eine Klasse gewählt worden ist, wird der Käufer 20 in Schritt 116 gebeten, die Suchkriterien für ein gewünschtes Produkt bzw. ein gewünschtes Dokument einzugeben. Wie vorstehend beschrieben, kann zum Beispiel der Server GCD 40 dem Käufer 20 ein Suchformular liefern, in das er ein oder mehrere Suchkriterien eingibt oder ein Einzelfeld, in das der Käufer 20 die gewünschten Suchkriterien eingeben kann. Der Käufer 20 kann eine Suche nach einem bestimmten Produkt eingeben und trotzdem noch die Fähigkeit haben, die Dokumente zu finden, die mit dem spezifischen Produkt verbunden sind. Daher hat der Käufer 20 nicht spezifisch nach den Dokumenten zu suchen. Wenn zum Beispiel der Käufer 20 an Stiften interessiert ist, kann der Käufer 20 die Klassen für Stifte suchen und der Server GCD 40 oder jeder andere geeignete Bestandteil können auch Dokumente aus den Dokumentenklassen für Stifte suchen, die sich auf Stifte beziehen. Die verwandten Dokumente können dem Käufer 20 vorgelegt werden, nachdem der Käufer 20 ein bestimmtes Produkt gewählt und nach diesem gesucht hat.
  • Unter Verendung der vom Käufer 20 gelieferten oder anderweitig erzeugten Suchkriterien sucht die Suchschnittstelle 45 in Schritt 118 nach Dokumenten, die mit den Suchkriterien im gemeinsamen Dokumentenspeicher 35 bzw. einer oder mehreren Verkäuferdatenbanken 32 übereinstimmen, die von Zeigern in der vom Käufer 20 gewählten Klasse bezeichnet werden. Die Suchschnittstelle 45 kann die Suche in geeigneter Weise vornehmen. Beruhend auf einem Zeiger, der mit einer Klasse verbunden ist, kann zum Beispiel der Server GCD 40 zuerst einen gemeinsamen Dokumentenspeicher 35 oder einen Teil eines gemeinsamen Dokumentenspeichers 35 (der von einem Zeiger gekennzeichnet wird) nach Standarddokumenten durchsuchen, die mit den Suchkriterien übereinstimmen und dann können ein oder mehrere Verkäuferdatenbanken 32 (die vom gleichen Zeiger oder einem verbundenen Zeiger gekennzeichnet sind) nach spezifischen Dokumenten durchsucht werden. Das Standarddokument im gemeinsamen Dokumentenspeicher 35 kann zum Beispiel einen damit verbundenen Zeiger für jede Verkäuferdatenbank 32 haben, die spezifische Dokumente liefert, um das Standarddokument zu erklären oder zu erweitern. Alternativ kann diese Suche in der entgegengesetzten Reihenfolge durchgeführt werden oder durch Anwendung beliebiger anderer Techniken. Eine Liste der sich ergebenden Standard- bzw. spezifischen Dokumente, die von den gemeinsamen Dokumentenspeichern 35 bzw. den Verkäuferdatenbanken 32 erhalten wird, kann kombiniert werden und einem Käufer 20 als ein vereinter Satz Suchergebnisse vorgelegt werden. In Schritt 120 legt der Server GCD 40 dem Käufer 20 die Suchergebnisse mit einer Liste von einem oder mehreren Dokumenten vor, die mit den Suchkriterien übereinstimmen (oder teilweise übereinstimmen).
  • Nachdem der Server GCD 40 die Dokumente vorgelegt hat, die mit der Suche übereinstimmen, überprüft der Käufer 20 in Schritt 122 die Ergebnisse und wählt ein Dokument aus den Suchergebnissen. Wenn der Käufer 20 ein Dokument Dritter wählt, besitzt der Käufer 20 nicht die erforderliche Genehmigungsstufe zum Entschlüsseln des Dokumentes Dritter. Um daher die vertraulichen Informationen im Dokument Dritter zu schützen, erstellt das Intelligenzmodul 47 ein generisches Dokument anhand des Dokumentes Dritter in Schritt 124, so dass der Käufer 20 die Version des generischen Dokumentes des gewählten Dokumentes Dritter durchsehen und ändern kann. Das Erstellen eines generischen Dokumentes besteht zuerst aus dem Unterteilen des Dokumentes Dritter in mehrere Teile. Nachdem es in Teile unterteilt worden ist, überprüft das Intelligenzmodul 47 die Teile des Dokumentes Dritter um festzustellen, welche Teile generisch und welche spezifisch für einen bestimmten früheren Geschäftsvorgang sind und welche Teile vertrauliche Informationen enthalten. Generische Teile können Kopfzeilen, Fußzeilen, Daten, Produktart und -beschreibung enthalten, sind jedoch nicht auf diese beschränkt. Diese Teile sind darum generisch, weil sie sich generell in allen Dokumenten dieser Art befinden müssen und auch keine vertraulichen oder Wettbewerbsinformationen bezüglich des Käufers und Verkäufers enthalten, die die ursprünglichen Parteien für das Dokument darstellten. Teile, die als spezifisch für einen bestimmten Geschäftsvorgang betrachtet werden bzw. die vertraulich sind, schließen den Namen des Käufers, den Namen des Verkäufers, die Menge des gekauften Produkts und den Kaufpreis des Produkts ein, sind jedoch nicht auf diese beschränkt. Die Teile werden für einen bestimmte Geschäftsvorgang als spezifisch bzw. vertraulich betrachtet, weil ein Käufer möglicherweise nicht wünscht, dass andere Käufer 20 wissen, von welchem Verkäufer 30 sie einkaufen, welche Produkte die kaufen, wie viel sie kaufen und welchen Kaufpreis sie für die Produkte bezahlen.
  • Das Intelligenzmodul 47 kann die Informationen aus den Teilen entfernen, die für einen bestimmten Geschäftsvorgang spezifisch sind und die Informationen in den generischen Teilen übertragen. Das Intelligenzmodul 47 kann die Teile übertragen, die spezifisch über einen bestimmte Geschäftsvorgang sind aber Teile frei lassen, so dass der Käufer 20 sie mit den Informationen für den Käufer 20 ausfüllen kann. In Schritt 126 passt das Intelligenzmodul 47 dynamisch die generischen Teile den laufenden Informationen an wie Datum, Namen und Kontaktinformationen für den Käufer 20. Die dynamische Anpassung der generischen Dokumente schließt die Notwendigkeit aus, dass der Käufer 20 das laufende Datum, den Namen und die Kontaktinformationen für den Käufer 20 eingeben muss. Daher kann der Käufer 20 den Geschäftsvorgang schneller und mit weniger Mühe abschließen. Alternativ kann der Käufer 20 ein Dokument Dritter erhalten, aus dem alle vertraulichen Informationen entfernt wurden, das jedoch nicht aktualisiert ist und daher kann der Käufer 20 das Dokument aktualisieren und vervollständigen. Nachdem das generische Dokument dynamisch aktualisiert wurde und alle vertraulichen Informationen entfernt worden sind, füllt er das generische Dokument aus, indem er Informationen wie die gewünschte Menge und den Kaufpreis einsetzt. Nachdem das generische Dokument ausgefüllt ist, kann der Käufer 20 das Dokument in einem Geschäftsvorgang benutzen. Der Server GCD 40 speichert das Dokument entweder als Standarddokument oder spezifisches Dokument in Schritt 130, so das es andere Käufer 20 in Zukunft benutzen können und das geänderte generische Dokument für den Käufer zum Benutzerdokument wird.
  • Wenn der Käufer 20 in Schritt 122 ein Benutzerdokument wählt, sollte sich der Käufer 20 im Besitz der erforderlichen Genehmigungsstufe befinden, um das Benutzerdokument zu entschlüsseln, weil ein Benutzerdokument dem Inhalt nach das eigene Dokument des Käufers 20 ist und daher befindet sich der Käufer 20 im Besitz der erforderlichen Genehmigungsstufe. In Schritt 132 erhält das Sicherheitsmodul 41 das erforderliche Passwort für die Entschlüsselung oder andere Informationen vom Käufer 20 und entschlüsselt das Dokument. In Schritt 134 beschließt der Käufer 20, ob der Käufer 20 das Benutzerdokument für einen laufenden Geschäftsvorgang neu ausstellen oder das Benutzerdokument einfach durchsehen will. Wenn sich der Käufer 20 entscheidet, das Benutzerdokument durchzusehen, sieht der Käufer 20 in Schritt 136 das Benutzerdokument aus einem früheren Geschäftsvorgang durch. Der Käufer 20 sieht typisch ein Benutzerdokument durch, um Informationen über frühere Geschäftsvorgänge zu sammeln, den Auftragsablauf zu prüfen, zu bestimmen, wann der nächste Geschäftsvorgang einzuleiten ist oder aus jedem anderen geeigneten Grund zur Durchsicht des Benutzerdokumentes. Während der Durchsicht des Benutzerdokumentes kann der Käufer 20 feststellen, wann frühere Aufträge platziert wurden und wo, welche Bedingungen für die früheren Aufträge galten und wann der ideale Zeitpunkt gekommen ist, um den nächsten Geschäftsvorgang einzuleiten.
  • Wenn der Käufer 20 in Schritt 134 beschließt, das Benutzerdokument für einen neuen Geschäftsvorgang neu auszustellen, kann das Intelligenzmodul 47 in Schritt 138 das Benutzerdokument mit den aktualisierten laufenden Informationen wie dem laufenden Datum neu ausstellen. Bei der Neuausstellung des Dokumentes kann das Intelligenzmodul 47 bestimmen, welche Teile des Dokumentes für den früheren Geschäftsvorgang generisch und welche spezifisch waren. Das Intelligenzmodul 47 kann auch das neu ausgestellte Benutzerdokument mit den neuen Informationen des Verkäufers 30 aktualisieren, wenn der Käufer 20 beschließt, einen anderen Verkäufer in diesem Geschäftsvorgang zu benutzen. In Schritt 140 sieht der Käufer 20 das neu ausgestellte Benutzerdokument durch und füllt alle Teile aus, die noch nicht vom Intelligenzmodul 47 aktualisiert wurden und ändert alle Teile, für deren Änderung sich der Käufer 20 entscheidet. Der Server GCD 40 speichert das neu ausgestellte Benutzerdokument als Standard- oder spezifisches Dokument, abhängig davon, ob sich das neu ausgestellte Benutzerdokument in Schritt 142 im Standardformat befindet. Das Verfahren endet damit.
  • Das in Fig. 6A & 6B besprochene Verfahren ist lediglich ein Beispielverfahren für die Speicherung, Klassifizierung und Wiederverwendung der Dokumente des Käufers 20 bzw. des Verkäufers 30. Die Schritte können in einer anderen Reihenfolge als vorstehend dargestellt ausgeführt werden und gewisse Schritte können ausgelassen werden.
  • Obgleich die vorliegende Erfindung anhand mehrerer Ausführungsbeispiele beschrieben worden ist, können für den Fachmann verschiedene Änderungen, Möglichkeiten für den Ersatz, Variationen, Änderungen und Modifizierungen angeregt werden und es wird beabsichtigt, dass die Erfindung für alle solche Änderungen, Möglichkeiten für den Ersatz, Variationen, Änderungen und Modifizierungen gedacht ist, die in den Geist und Umfang der anliegenden Ansprüche fallen.

Claims (35)

1. E-Commerce-System für die Speicherung und Klassifizierung von Dokumenten, wobei das System folgendes umfasst:
ein oder mehrere Dokumentenspeicher, die so betrieben werden können, dass sie mehrere Dokumente speichern;
ein globales Inhaltsverzeichnis, das mehrerer Klassen enthält, die hierarchisch geordnet sind, wobei jede Klasse die Dokumente kategorisiert und mit einem oder mehreren der Dokumente in Verbindung bringt, die in der Klasse kategorisiert sind, wobei mindestens eine der Klassen ein oder mehrere verbundene Zeiger hat, die ein oder mehrere Dokumentenspeicher bezeichnen;
eine Suchschnittstelle, die betrieben werden kann, um Informationen über eine Suchabfrage für die Dokumente an einen oder mehrere Dokumentenspeicher weiterzugeben, die von Zeigern gekennzeichnet sind, die mit einer oder mehreren der Klassen verbunden sind und
eine globale Inhaltsverzeichnis-Schnittstelle, die so betrieben werden kann, dass eine Anzeige entsteht, um das Finden der Dokumente zu erleichtern.
2. System nach Anspruch 1, bei dem die Klassen aus mehreren Dokumentenklassen bestehen.
3. System nach Anspruch 1, bei dem die Klassen aus mehreren Produktklassen bestehen.
4. System nach Anspruch 1, bei dem die Klassen aus Dokumenten Dritter bestehen.
5. System nach Anspruch 1, bei dem die Klassen aus mehreren Benutzerdokumenten bestehen.
6. System nach Anspruch 1, bei dem die Klassen aus Dokumenten bestehen, die Standarddokumente enthalten, die in einem gemeinsamen Dokumentenspeicher gespeichert sind.
7. System nach Anspruch 1, bei dem die Dokumente spezifische Dokumente enthalten, die in einer oder mehreren Verkäuferdatenbanken gespeichert sind.
8. System nach Anspruch 1, bei dem die globale Inhaltsverzeichnis- Schnittstelle das Finden der Dokumente erleichtert, indem sie dem Benutzer die Durchsuchung einer oder mehrerer Klassen nach den Dokumenten ermöglicht.
9. System nach Anspruch 1, das außerdem ein Intelligenzmodul enthält, das dazu eingesetzt werden kann, um:
die Dokumente in einen oder mehrere Teile zu unterteilen;
zu bestimmen, welche Teile der Dokumente generisch und welche spezifisch für einen bestimmten Geschäftsvorgang sind und
aus den Dokumenten Informationen aus den Teilen zu entfernen, die für einen bestimmten Geschäftsvorgang spezifisch sind.
10. System nach Anspruch 1, das ferner ein Sicherheitsmodul enthält, das dazu einsetzbar ist, um die Dokumente zu verschlüsseln.
11. System nach Anspruch 10, bei dem das Sicherheitsmodul die Dokumente verschlüsselt, indem es jedem der Dokumente eine Genehmigungsstufe zuweist.
12. System nach Anspruch 10, das ferner ein Sicherheitsmodul enthält, dass dazu einsetzbar ist, um die Dokumente zu entschlüsseln, wenn sich ein Benutzer im Besitz der für die Entschlüsselung erforderlichen Genehmigungsstufe befindet.
13. Verfahren zur Speicherung und Klassifizierung von Dokumenten, aufweisend:
Speicherung mehrerer Dokumente in einem oder mehreren Dokumentenspeichern;
Kategorisieren der Dokumente in mehreren Klassen, um das Finden der Dokumente in Zukunft zu ermöglichen, wobei die Klassen hierarchisch geordnet sind, wobei jede Klasse, die Dokumente kategorisiert und mit einem oder mehreren der in der Klasse kategorisierten Dokumente in Verbindung steht;
Suche nach bestimmten Dokumenten durch Navigieren durch die Klassen und
Durchsicht von einem oder mehreren der Dokumente, die beim Navigieren durch die Klassen gefunden wurden.
14. Verfahren nach Anspruch 13, bei dem die Klassen aus mehreren Produktklassen bestehen.
15. Verfahren nach Anspruch 13, bei dem die Klassen aus mehreren Dokumentenklassen bestehen.
16. Verfahren nach Anspruch 13, bei dem die Kategorisierung der Dokumente daraus besteht, mehrere Zeiger auf die Klassen in Bezug zu bringen, wobei die Zeiger ein oder mehrere Dokumentenspeicher bezeichnen.
17. Verfahren nach Anspruch 13, das ferner aus dem Verschlüsseln der Dokumente besteht, um den Zugriff zu den Dokumenten zu kontrollieren;
18. Verfahren nach Anspruch 17, bei dem das Verschlüsseln der Dokumente die Zuteilung einer Genehmigungsstufe für die Dokumente umfasst.
19. Verfahren nach Anspruch 17, das ferner das Entschlüsseln der Dokumente aufweist, so dass dem Benutzer der Zugriff zu den Dokumenten gestattet wird, wenn sich der Benutzer im Besitz der erforderlichen Genehmigungsstufe befindet.
20. Verfahren nach Anspruch 13, bei dem die Speicherung mehrer Dokumente die Speicherung eines oder mehrer Standarddokument in einem gemeinsamen Dokumentenspeicher beinhaltet.
21. Verfahren nach Anspruch 13 bei dem die Speicherung von mehreren Dokumenten die Speicherung von einem oder mehreren spezifischen Dokumenten in einer oder mehreren Verkäuferdatenbanken beinhaltet.
22. Verfahren nach Anspruch 13, das ferner die erneute Ausstellung der Dokumente beinhaltet, die mit den laufenden Informationen aktualisiert wurden.
23. Verfahren nach Anspruch 13, das ferner aufweist:
die Unterteilung der Dokumente in ein oder mehrere Teile,
die Bestimmung, welche Teile der Dokumente generisch und welche spezifisch für einen bestimmten Geschäftsvorgang sind und
das Entfernen von Informationen aus den Dokumenten aus den Teilen enthält, die spezifisch für einen bestimmten Geschäftsvorgang sind.
24. Software für die Speicherung und Klassifizierung von Dokumenten, wobei sich die Software in einem durch Computer lesbaren Medium verkörpert ist und betrieben werden kann, um:
mehrere Dokumente in einem oder mehreren Dokumentenspeichern zu speichern;
die Dokumente in mehreren Klassen zu kategorisieren, um das spätere Finden der Dokumente zu erleichtern, wobei die Klassen hierarchisch geordnet sind und jede Klasse die Dokumente kategorisiert und sie mit einem oder mehreren der in der Klasse kategorisierten Dokumente in Verbindung bringt;
nach bestimmten Dokumenten durch Navigieren durch die Klassen zu durchsuchen und
ein oder mehrere der Dokumente, die gefunden werden, während durch die Klassen navigiert wird, zu durchsuchen.
25. Software nach Anspruch 24, wobei die Klassen aus mehreren Produktklassen bestehen.
26. Software nach Anspruch 24, wobei die Klassen aus mehreren Dokumentenklassen bestehen.
27. Software nach Anspruch 24, wobei das Kategorisieren der Dokumente daraus besteht, mehrere Zeiger mit den Klassen zu verbinden, wobei die Zeiger einen oder mehrere Dokumentenspeicher bezeichnen.
28. Software nach Anspruch 24, die ferner dazu einsetzbar ist, um die Dokumente zu verschlüsseln, um den Zugriff zu den Dokumenten zu kontrollieren;
29. Software nach Anspruch 28, wobei das Verschlüsseln der Dokumente die Zuteilung einer Genehmigungsstufe zu den Dokumenten umfasst.
30. Software nach Anspruch 28, die ferner dazu einsetzbar ist, um die Dokumente zu entschlüsseln, so dass der Benutzer Zugriff zu den Dokumenten hat, wenn sich der Benutzer im Besitz der erforderlichen Genehmigungsstufe befindet.
31. Software nach Anspruch 24, wobei die Speicherung mehrerer Dokumente die Speicherung von einem oder mehreren Standarddokumenten in einem gemeinsamen Dokumentenspeicher enthält.
32. Software nach Anspruch 24, wobei die Speicherung mehrerer Dokumente die Speicherung von einem oder mehreren spezifischen Dokumenten in einer oder mehreren Verkäuferdatenbanken enthält.
33. Software nach Anspruch 24, die ferner dazu einsetzbar ist, um Dokumente mit laufenden Informationen zu aktualisieren.
34. Software nach Anspruch 24, die ferner dazu einsetzbar ist:
die Dokumente in einen oder mehrere Teile zu teilen;
zu bestimmen, welche Teile der Dokumente generisch und welche spezifisch für einen bestimmten Geschäftsvorgang sind und
aus den Dokumenten Informationen in den Teile zu entfernen, die spezifisch für einen bestimmten Geschäftsvorgang sind.
35. System für die Speicherung und Klassifizierung von Dokumenten, wobei das Verfahren folgende Mittel enthält:
Mittel zur Speicherung mehrerer Dokumente;
Mittel zum Kategorisieren von Dokumenten in mehreren Klassen, um das zukünftige Finden der Dokumente zu erleichtern, wobei die Klassen hierarchisch geordnet sind, wobei jede Klasse Dokumente kategorisiert und sie mit einem oder mehreren der Dokumente verbindet, die in der Klasse kategorisiert sind;
Mittel zur Suche nach bestimmten Dokumenten durch Navigieren durch die Klassen und
Mittel für die Durchsicht von einem oder mehreren der beim Navigieren durch die Klassen gefundenen Dokumenten.
DE10244729A 2001-09-27 2002-09-25 Dokumentenspeicherung und -klassifizierung Withdrawn DE10244729A1 (de)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US32606201P 2001-09-27 2001-09-27
US09/999,524 US7054841B1 (en) 2001-09-27 2001-10-23 Document storage and classification

Publications (1)

Publication Number Publication Date
DE10244729A1 true DE10244729A1 (de) 2003-07-24

Family

ID=26985227

Family Applications (1)

Application Number Title Priority Date Filing Date
DE10244729A Withdrawn DE10244729A1 (de) 2001-09-27 2002-09-25 Dokumentenspeicherung und -klassifizierung

Country Status (3)

Country Link
US (1) US7054841B1 (de)
DE (1) DE10244729A1 (de)
TW (1) TWI286709B (de)

Families Citing this family (54)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20080172314A1 (en) 1996-11-12 2008-07-17 Hahn-Carlson Dean W Financial institution-based transaction processing system and approach
US20070055582A1 (en) 1996-11-12 2007-03-08 Hahn-Carlson Dean W Transaction processing with core and distributor processor implementations
US8396811B1 (en) 1999-02-26 2013-03-12 Syncada Llc Validation approach for auditing a vendor-based transaction
US8392285B2 (en) 1996-11-12 2013-03-05 Syncada Llc Multi-supplier transaction and payment programmed processing approach with at least one supplier
US20030236754A1 (en) * 2002-05-17 2003-12-25 Thompson Bryan D. Method, system, and computer program for identifying and classifying EDI and proprietary transactions
US7085755B2 (en) * 2002-11-07 2006-08-01 Thomson Global Resources Ag Electronic document repository management and access system
US7519604B2 (en) * 2003-08-29 2009-04-14 Nokia Corporation Troubleshooting engine and method for using same
US7818308B2 (en) * 2003-10-01 2010-10-19 Nuance Communications, Inc. System and method for document section segmentation
US7464330B2 (en) * 2003-12-09 2008-12-09 Microsoft Corporation Context-free document portions with alternate formats
US7617447B1 (en) 2003-12-09 2009-11-10 Microsoft Corporation Context free document portions
US7418652B2 (en) 2004-04-30 2008-08-26 Microsoft Corporation Method and apparatus for interleaving parts of a document
US7383500B2 (en) * 2004-04-30 2008-06-03 Microsoft Corporation Methods and systems for building packages that contain pre-paginated documents
US8661332B2 (en) * 2004-04-30 2014-02-25 Microsoft Corporation Method and apparatus for document processing
US7512878B2 (en) * 2004-04-30 2009-03-31 Microsoft Corporation Modular document format
US7549118B2 (en) 2004-04-30 2009-06-16 Microsoft Corporation Methods and systems for defining documents with selectable and/or sequenceable parts
US7487448B2 (en) * 2004-04-30 2009-02-03 Microsoft Corporation Document mark up methods and systems
US8380715B2 (en) * 2004-06-04 2013-02-19 Vital Source Technologies, Inc. System, method and computer program product for managing and organizing pieces of content
US7574386B2 (en) 2004-06-09 2009-08-11 U.S. Bank National Association Transaction accounting auditing approach and system therefor
CN101385044A (zh) 2004-06-09 2009-03-11 美国银行和许可股份有限公司 具有核心和经销商处理器实现的交易处理
US7925551B2 (en) * 2004-06-09 2011-04-12 Syncada Llc Automated transaction processing system and approach
CN101036169A (zh) 2004-06-09 2007-09-12 美国银行和许可股份有限公司 订购资源完成以及管理系统和方法
US8762238B2 (en) 2004-06-09 2014-06-24 Syncada Llc Recurring transaction processing system and approach
US7617450B2 (en) * 2004-09-30 2009-11-10 Microsoft Corporation Method, system, and computer-readable medium for creating, inserting, and reusing document parts in an electronic document
US7475335B2 (en) * 2004-11-03 2009-01-06 International Business Machines Corporation Method for automatically and dynamically composing document management applications
US20060136816A1 (en) * 2004-12-20 2006-06-22 Microsoft Corporation File formats, methods, and computer program products for representing documents
US7617451B2 (en) * 2004-12-20 2009-11-10 Microsoft Corporation Structuring data for word processing documents
US7620889B2 (en) 2004-12-20 2009-11-17 Microsoft Corporation Method and system for linking data ranges of a computer-generated document with associated extensible markup language elements
US7617444B2 (en) 2004-12-20 2009-11-10 Microsoft Corporation File formats, methods, and computer program products for representing workbooks
US7617229B2 (en) * 2004-12-20 2009-11-10 Microsoft Corporation Management and use of data in a computer-generated document
US7614000B2 (en) 2004-12-20 2009-11-03 Microsoft Corporation File formats, methods, and computer program products for representing presentations
US7770180B2 (en) * 2004-12-21 2010-08-03 Microsoft Corporation Exposing embedded data in a computer-generated document
US7752632B2 (en) 2004-12-21 2010-07-06 Microsoft Corporation Method and system for exposing nested data in a computer-generated document in a transparent manner
US20060277452A1 (en) * 2005-06-03 2006-12-07 Microsoft Corporation Structuring data for presentation documents
US8306918B2 (en) 2005-10-11 2012-11-06 Apple Inc. Use of media storage structure with multiple pieces of content in a content-distribution system
US7917519B2 (en) * 2005-10-26 2011-03-29 Sizatola, Llc Categorized document bases
WO2007101040A2 (en) 2006-02-22 2007-09-07 First American Corelogic Holdings, Inc. System and method for monitoring events associated with a person or property
US20080021767A1 (en) * 2006-04-05 2008-01-24 Amanda Benson System and method for collecting and managing product information in a database
US8224745B2 (en) * 2006-06-13 2012-07-17 Corelogic Tax Services, Llc Automatic delinquency item processing with customization for lenders
US8712884B2 (en) 2006-10-06 2014-04-29 Syncada Llc Transaction finance processing system and approach
US8099345B2 (en) * 2007-04-02 2012-01-17 Bank Of America Corporation Financial account information management and auditing
US8032427B1 (en) * 2007-04-03 2011-10-04 Local.com System for providing localized shopping information
JP5024056B2 (ja) * 2008-01-07 2012-09-12 富士ゼロックス株式会社 操作管理システム
US8751337B2 (en) 2008-01-25 2014-06-10 Syncada Llc Inventory-based payment processing system and approach
US8015037B2 (en) * 2008-07-01 2011-09-06 Corelogic Information Solutions, Inc. System and method for tracking, monitoring and reporting extinguishment of a title insurance policy
US8495030B2 (en) 2011-01-06 2013-07-23 International Business Machines Corporation Records declaration filesystem monitoring
CN101650717B (zh) * 2008-08-13 2013-07-31 阿里巴巴集团控股有限公司 一种节约数据库存储空间的方法和系统
US8620778B2 (en) * 2009-01-20 2013-12-31 Microsoft Corporation Document vault and application platform
US10282373B2 (en) * 2009-04-17 2019-05-07 Excalibur Ip, Llc Subject-based vitality
US9189811B1 (en) 2010-01-07 2015-11-17 Amazon Technologies, Inc. Electronic marketplace recommendations
US8423420B1 (en) * 2010-01-07 2013-04-16 Amazon Technologies, Inc. Method and media for duplicate detection in an electronic marketplace
WO2014144033A1 (en) * 2013-03-15 2014-09-18 Cerinet Usa Inc. Multiple schema repository and modular data procedures
CN104182427A (zh) * 2013-05-28 2014-12-03 纬创资通股份有限公司 电子文件制作系统及其电子文件制作方法
TWI509449B (zh) * 2014-12-11 2015-11-21 Pile Up Design Furniture online design system
EP3541161B1 (de) * 2016-11-14 2021-11-24 Fuji Corporation Neuklassifizierungssystem und neuklassifizierungsverfahren für gespeicherte bilder

Family Cites Families (33)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
GB8704883D0 (en) * 1987-03-03 1987-04-08 Hewlett Packard Co Secure information storage
US5132900A (en) * 1990-12-26 1992-07-21 International Business Machines Corporation Method and apparatus for limiting manipulation of documents within a multi-document relationship in a data processing system
JPH04352068A (ja) * 1991-05-29 1992-12-07 Nec Corp 文書編集装置
US5379340A (en) 1991-08-02 1995-01-03 Betterprize Limited Text communication system
US5812995A (en) 1993-10-14 1998-09-22 Matsushita Electric Industrial Co., Ltd. Electronic document filing system for registering and retrieving a plurality of documents
US5625811A (en) 1994-10-31 1997-04-29 International Business Machines Corporation Method and system for database load balancing
US5862325A (en) * 1996-02-29 1999-01-19 Intermind Corporation Computer-based communication system and method using metadata defining a control structure
US5933841A (en) 1996-05-17 1999-08-03 Ameritech Corporation Structured document browser
US6253188B1 (en) * 1996-09-20 2001-06-26 Thomson Newspapers, Inc. Automated interactive classified ad system for the internet
US5987506A (en) 1996-11-22 1999-11-16 Mangosoft Corporation Remote access and geographically distributed computers in a globally addressable storage environment
US6014644A (en) 1996-11-22 2000-01-11 Pp International, Inc. Centrally coordinated communication systems with multiple broadcast data objects and response tracking
US6088693A (en) * 1996-12-06 2000-07-11 International Business Machines Corporation Data management system for file and database management
US6035297A (en) * 1996-12-06 2000-03-07 International Business Machines Machine Data management system for concurrent engineering
US5920873A (en) 1996-12-06 1999-07-06 International Business Machines Corporation Data management control system for file and database
US6092121A (en) 1997-12-18 2000-07-18 International Business Machines Corporation Method and apparatus for electronically integrating data captured in heterogeneous information systems
US6473791B1 (en) 1998-08-17 2002-10-29 Microsoft Corporation Object load balancing
US6397231B1 (en) 1998-08-31 2002-05-28 Xerox Corporation Virtual documents generated via combined documents or portions of documents retrieved from data repositories
US6226675B1 (en) 1998-10-16 2001-05-01 Commerce One, Inc. Participant server which process documents for commerce in trading partner networks
US6275933B1 (en) * 1999-04-30 2001-08-14 3Com Corporation Security system for a computerized apparatus
EP1056024A1 (de) 1999-05-27 2000-11-29 Tornado Technologies Co., Ltd. Textsuchsystem
US6269361B1 (en) 1999-05-28 2001-07-31 Goto.Com System and method for influencing a position on a search result list generated by a computer network search engine
FI991261A (fi) * 1999-06-02 2000-12-03 Nokia Networks Oy Trie-rakenteeseen perustuva funktionaalinen muisti
US6560620B1 (en) 1999-08-03 2003-05-06 Aplix Research, Inc. Hierarchical document comparison system and method
US6484143B1 (en) 1999-11-22 2002-11-19 Speedera Networks, Inc. User device and system for traffic management and content distribution over a world wide area network
US6219674B1 (en) 1999-11-24 2001-04-17 Classen Immunotherapies, Inc. System for creating and managing proprietary product data
CA2437027A1 (en) 2000-02-14 2001-08-23 Stephen Corey Wren System for marketing goods and services utilizing computerized central and remote facilities
JP2001313720A (ja) * 2000-02-24 2001-11-09 Jintetsuku:Kk 電子商取引システムにおける個人情報確認方法
US20020013827A1 (en) 2000-05-18 2002-01-31 Edstrom Claes G.R. Personal service environment management apparatus and methods
US6745206B2 (en) 2000-06-05 2004-06-01 International Business Machines Corporation File system with access and retrieval of XML documents
US20020095301A1 (en) 2001-01-17 2002-07-18 Jose Villena Load sharing
US20020147656A1 (en) 2001-04-04 2002-10-10 Tam Richard K. E-commerce using a catalog
US20030050958A1 (en) 2001-09-10 2003-03-13 Keller Beth A. Supplier/reseller interaction
US6778991B2 (en) 2001-09-27 2004-08-17 I2 Technologies Us, Inc. Dynamic load balancing using semantic traffic monitoring

Also Published As

Publication number Publication date
US7054841B1 (en) 2006-05-30
TWI286709B (en) 2007-09-11

Similar Documents

Publication Publication Date Title
DE10244729A1 (de) Dokumentenspeicherung und -klassifizierung
DE10196672B4 (de) Verfahren zum selektiven Indizieren von Datenbanken
DE10196670B3 (de) System und Verfahren zur Migration von Daten in einem elektronischen Handelssystem
US8571945B2 (en) Pre-qualifying sellers during the matching phase of an electronic commerce transaction
DE10244726A1 (de) Erzeugen, Aktualisieren und Verwalten von Multi-Taxonomie-Umgebungen
US6983276B2 (en) Facilitating electronic commerce transactions using buyer profiles
DE10244622A1 (de) Speicherung und Wiederverwendung von Drittparteidokumenten
DE10244623A1 (de) Dynamische Datenbankumleitung unter Verwendung semantischer Taxonomie-Information
US7099849B1 (en) Integrated media management and rights distribution apparatus
US7127416B1 (en) Distributed processing of sorted search results in an electronic commerce system and method
US20180285883A1 (en) Providing Market Feedback Associated with Electronic Commerce Transactions to Sellers
US8086643B1 (en) Translation between product classification schemas
DE10244731A1 (de) Dynamischer Auslastungsausgleich unter Verwendung einer semantischen Verkehrsüberwachung
DE60037511T2 (de) Interaktives system um produkte in einem netzwerk zu suchen
US6944613B2 (en) Method and system for creating a database and searching the database for allowing multiple customized views
US20070276819A1 (en) Content Enhancement for Analyzing Data in a Database
DE112006002886T5 (de) System und Verfahren zum Speichern von Postenattributen in einem elektronischen Katalog
DE10255127A1 (de) Zuordnung zwischen Teilenummern, die auf verschiedenen Schemata für Teilenummerierung beruhen
DE10244624A1 (de) Bestellbeschleunigung durch Speicherung dund Wiederverwendung von Benutzerdokumenten
US7809672B1 (en) Association of data with a product classification schema
DE10239294A1 (de) Lokales Erzeugen von Preisangaben unter der Verwendung eines oder mehrerer Preisgestaltungswerkzeuge, die von einem Verkäufer empfangen wurden
US7412424B1 (en) Third party certification of content in electronic commerce transactions
DE10239293A1 (de) Dynamische Preisgestaltung in einem unausgeglichenen Markt
DE112008003980T5 (de) On-Line Handelssystem
DE10246000A1 (de) Bereitstellung einer Visualisierung von Marktangeboten mittels Mustern von geometrischen Anzeigeelementen

Legal Events

Date Code Title Description
8128 New person/name/address of the agent

Representative=s name: DF-MP, 80333 MUENCHEN

8110 Request for examination paragraph 44
R082 Change of representative

Representative=s name: DF-MP, DE

Representative=s name: DF-MP, 80333 MUENCHEN, DE

R081 Change of applicant/patentee

Owner name: JDA SOFTWARE GROUP, INC., SCOTTSDALE, US

Free format text: FORMER OWNER: I2 TECHNOLOGIES, INC., DALLAS, TEX., US

Effective date: 20120119

Owner name: JDA SOFTWARE GROUP, INC., US

Free format text: FORMER OWNER: I2 TECHNOLOGIES, INC., DALLAS, US

Effective date: 20120119

R082 Change of representative

Representative=s name: DF-MP DOERRIES FRANK-MOLNIA & POHLMAN PATENTAN, DE

Effective date: 20120119

Representative=s name: DF-MP, DE

Effective date: 20120119

R119 Application deemed withdrawn, or ip right lapsed, due to non-payment of renewal fee
R119 Application deemed withdrawn, or ip right lapsed, due to non-payment of renewal fee

Effective date: 20120403