DE10244624A1 - Bestellbeschleunigung durch Speicherung dund Wiederverwendung von Benutzerdokumenten - Google Patents

Bestellbeschleunigung durch Speicherung dund Wiederverwendung von Benutzerdokumenten

Info

Publication number
DE10244624A1
DE10244624A1 DE10244624A DE10244624A DE10244624A1 DE 10244624 A1 DE10244624 A1 DE 10244624A1 DE 10244624 A DE10244624 A DE 10244624A DE 10244624 A DE10244624 A DE 10244624A DE 10244624 A1 DE10244624 A1 DE 10244624A1
Authority
DE
Germany
Prior art keywords
documents
user
document
buyer
user documents
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.)
Ceased
Application number
DE10244624A
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.)
I2 Technologies 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 DE10244624A1 publication Critical patent/DE10244624A1/de
Ceased 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
    • G06Q30/00Commerce
    • G06Q30/06Buying, selling or leasing transactions
    • G06Q30/08Auctions

Abstract

Ein elektronisches Handelssystem (10) zur Bestellbeschleunigung durch Wiederverwendung von Benutzerdokumenten beinhaltet einen oder mehrere Dokumentenspeicher (32, 35), in welchen eine Vielzahl von Benutzerdokumenten gespeichert sind. Das System umfasst weiter ein globales Inhaltsverzeichnis (42), welches eine Vielzahl von in einer Hierarchie organisierten Produkt- und Dokumentklassen beinhaltet, wobei jede Klasse eine Anzahl Dokumente kategorisiert und mit einem oder mehreren Attributen der in dieser Klasse kategorisierten Dokumente verbunden ist. Das System beinhaltet weiter eine Suchschnittstelle (45) zum Durchsuchen der Benutzerdokumente. Ein Sicherheitsmodul (41) verschlüsselt die Benutzerdokumente und entschlüsselt die Benutzerdokumente, wenn ein Käufer (20) die erforderliche Erlaubnisebene hat. Ein Intelligenzmodul (47) bringt einen oder mehrere Abschnitte mit aktuellen Informationen auf den neuesten Stand, so dass ein Käufer (20) die Benutzerdokumente zur Beschleunigung einer Bestellung wiederverwerten kann.

Description

  • Die Erfindung bezieht sich auf elektronischen Handel und insbesondere auf Bestellbeschleunigung durch Speicherung und Wiederverwendung von Benutzerdokumenten.
  • Aufgrund der immer weiter steigenden Popularität und Zugänglichkeit des Internets als Kommunikationsmedium ist auch die Anzahl der Geschäftstransaktionen, die unter Benutzung des Internets durchgeführt werden, steigend, ebenso wie die Anzahl der Käufer und Verkäufer, die an elektronischen Marktplätzen teilnehmen, welche einen Platz für solche Transaktionen bieten. Die überwiegende Zahl von elektronischen Handelsabwicklungen (e-commerce), tritt dann auf, wenn ein Käufer den Bedarf für ein Produkt bestimmt, einen Verkäufer herausfindet, der dieses Produkt anbietet, und die Webseite des Verkäufers besucht, um den Kauf dieses Produktes zu regeln. Zusätzlich muss der Käufer weiter eins oder mehrere Dokumente mit dem Verkäufer austauschen, wie beispielsweise eine Angebotsanforderung oder ein Bestellformular, um die e-commerce Abwicklung zu vervollständigen. Hat der Käufer keinen bevorzugten Verkäufer oder kauft der Käufer das Produkt zum ersten Mal, wird er oft eine Suche nach einer Mehrzahl von Verkäufern durchführen, die dieses Produkt anbieten, wird dann mehrere Verkäufer- Webseiten besuchen, um zu entscheiden, welcher Verkäufer bestimmte gewünschte Produktmerkmale zum besten Preis anbietet, unter den besten Bedingungen für den Käufer einen Verkäufer auswählen und mehrere leere Dokumente ausfüllen, um die e-commerce- Abwicklung zu vervollständigen. Die Verbindungsphase von e-commerce Abwicklungen (Zusammenfügen des Käufers mit einem speziellen Verkäufer) und das Ausfüllen der Dokumente sind oft ineffektive Vorgänge. Die Verbindungsphase ist ineffektiv, da das Finden eines Produktes eine grosse Suchleistung beinhaltet und da, sobald ein spezielles Produkt gefunden wurde, die verschiedenen Angebote dieses Produktes durch unterschiedliche Verkäufer nicht einfach zu vergleichen sein kann. Die Phase des Dokumentausfüllens ist häufig ineffizient, da der Käufer im allgemeinen die meisten e- commerce Abwicklungen mit einem Leerdokument oder gar keinem Dokument beginnt und demgemäss ein Dokument erstellen muss oder die gesamten Informationen in das leere Formular wieder eingeben muss, obwohl einige Informationen in dem Dokument bei verschiedenen Verkäufern und verschiedenen Produkten sich nur sehr wenig ändern.
  • Gemäß der vorliegenden Erfindung werden die Nachteile und Probleme, die mit den bisherigen e-commerce Techniken verbunden sind, im wesentlichen reduziert oder aufgehoben.
  • Gemäß einer Ausführungsform der vorliegenden Erfindung beinhaltet ein elektronisches Handelssystem ein oder mehrere Dokumentspeicher, in denen eine Vielzahl von Benutzerdokumenten gespeichert sind. Das System beinhaltet weiter ein globales Inhaltsverzeichnis, welches eine Mehrzahl von Klassen beihaltet, die in einer Hierarchie angeordnet sind. Die Klassen beinhalten sowohl Produktklassen als auch Dokumentklassen. Jede Klasse kategorisiert eine Anzahl von Benutzerdokumenten und ist mit einem oder mehreren Attributen der in dieser Masse kategorisierten Benutzerdokumente verbunden. Wenigsten eine der Klassen hat einen oder mehrere verbundene Zeiger, welche einen oder mehrere der Dokumentenspeicher identifizieren. Das System beinhaltet weiter einen Sicherheitsmodul, welches die Benutzerdokumente entschlüsselt, um dem Käufer zu ermöglichen, die Benutzerdokumente einzusehen. Das System beinhaltet weiterhin ein Intelligenzmodul, das einen oder mehrere Abschnitte in den Benutzerdokumenten mit der aktuellen Information auf den neuesten Stand bringt. Das System beinhaltet ebenfalls eine Suchschnittstelle, die eine Suchanfrage zu den Dokumentspeichern für die Benutzerdokumente überträgt und dem Käufer ermöglicht, in den Benutzerdokumenten zu suchen.
  • Besondere Ausführungsformen der vorliegenden Erfindung können eine oder mehrere technische Vorteile bringen. Beispielsweise können bestimmte Ausführungsformen der vorliegenden Erfindung es dem Käufer ermöglichen, Dokumente einzusehen und wiederzuverwenden, die der Käufer vorher in vorausgegangenen e-commerce Abwicklungen benutzt hat. Die Wiederverwendung von Dokumenten beschleunigt Bestellungen, in denen der Käufer entweder mit einem Verkäufer handelt, mit dem der Käufer vorher Interaktion hatte, oder mit einem neuen Verkäufer. Handelt es sich um einen Verkäufer, mit dem der Käufer bereits zuvor gehandelt hat, greift der Käufer auf ein Dokument aus einer früheren Transaktion zwischen dem Käufer und diesem Verkäufer zurück und bringt weniger als alle Abschnitte auf den neuesten Stand, wie beispielsweise Menge undl Preis, das Dokument ist vervollständigt, und der Käufer sendet das Dokument zu dem Verkäufer, um die Transaktion zu vervollständigen. Handelt ein Käufer mit einem neuen Verkäufer, aber die Transaktion ist für ein Produkt, welches der Käufer bereits zuvor gekauft hat, greift der Käufer auf ein früheres Benutzerdokument mit diesem Produkt zurück und bringt das Dokument mit der neuen Verkäuferinformation auf den neuesten Stand, und das Dokument ist vervollständigt. In jedem Fall spart der Käufer Zeit, da der Käufer die Dokumente nicht wiedererstellen, sondern nur bestimmte Abschnitte in diesem Dokument auf den neuesten Stand bringen muss. Demgemäss werden e-commerce Transaktionen schneller und effizienter, da der Käufer mehrere Benutzerdokumente wiederverwertet, und dadurch weniger von der Zeit des Käufers durch Erschaffen und Nachverfolgen von Dokumenten verbraucht wird.
  • Weiterhin etablieren bestimmte Ausführungsformen der vorliegenden Erfindung zum Speichern und Wiederverwenden von Benutzerdokumenten sowohl eine Praxis als auch eine Systemform von akzeptablem Verhalten zwischen Käufern und Verkäufern. Da der Käufer Dokumente mit neuen und alten Verkäufern wiederbenutzt, werden die Dokumente mit der Zeit standardisiert, und Käufer und Verkäufer erhalten ein besseres Verständnis von dem, was andere Käufer und Verkäufer in ihren Dokumenten benötigen. Käufer und Verlkäufer wissen, welche Bedingungen und Konditionen in bestimmten Dokumenten vorhanden sein müssen, und das Wissen hiervon im voraus macht ein Teil der Verhandlung von Transaktionsbedingungen zwischen Käufer und Verkäufer unnötig. Zusätzlich kann ein Käufer all seine Dokumente wiederansehen und die Kaufentwicklung studieren sowie alle Trends, die sich zwischen einem Käufer und einem Verkäufer oder Produkt entwickelt haben. Andere technische Vorteile werden dem Fachmann anhand der nachfolgenden Figuren, Beschreibung und der Patentansprüche ersichtlich.
  • Um ein besseres Verständnis der vorliegenden Erfindung und den Merkmalen und Vorteilen derselben zu schaffen, wird in der nachfolgenden Beschreibung auf die beigefügten Zeichnungsfiguren Bezug genommen, in denen:
  • Fig. 1 ein beispielhaftes e-commerce System aufzeigt;
  • Fig. 2A & 2B eine beispielhafte Verzeichnisstruktur eines beispielhaften globalen Inhaltsverzeichnisses für Produktklassen darstellt;
  • Fig. 3 eine beispielhafte Verzeichnisstruktur eines beispielhaften globalen Inhaltsverzeichnisses für Dokumentklassen darstellt;
  • Fig. 4 eine beispielhafte Tabelle einer Verkäuferdatenbank darstellt;
  • Fig. 5 ein beispielhaftes e-commerce System im Detail darstellt; und
  • Fig. 6A & 6B ein beispielhaftes Verfahren zum Speichern, Klassifizieren und Wiederverwenden von Dokumenten darstellt.
  • Fig. 1 zeigt ein beispielhaftes System 10, welches ein Netzwerk 12 umfasst, das Käufer 20, Verkäufer 30, und einen globalen Inhaltsverzeichnis-Server 40 (GCD-Server) verbindet. Das System 10 ermöglicht elektronische Handelstransaktionen (e-commerce) zwischen Käufern 20 und Verkäufern 30 durch die Benutzung eines globalen Inhaltsverzeichnisses (GCD; global content directory) 42, unterstützt durch GCD-Server 40. GCD 42 kann intern oder extern von GCD-Server 40 sein. Netzwerk 12 kann jede geeignete Kombination von öffentlichen und/oder privaten Netzwerken umfassen, welche Käufer 20, Verkäufer 30 und GCD-Server 40 verbindet. In einer beispielhaften Ausführungsform beinhaltet Netzwerk 12 das Internet und alle geeigneten lokalen Netzwerke (LANs; local area network), regionale Netzwerke (MANs; metropolitan area network), oder überregionale Netzwerke (WANs; wide area network), welche Käufer 20, Verkäufer 30 und GCD-Server 40 mit dem Internet verbinden. Da das Internet für die große Mehrheit von Käufern und Verkäufern in der ganzen Welt zugänglich ist, beinhaltet die vorliegende Erfindung all diese Käufer und Verkäufer als mit System 10 verbundene Käufer 20 und Verkäufer 30. Die Verwendung des Begriffes "global" sollte jedoch nicht als geographische Begrenzung interpretiert werden, die notwendigerweise voraussetzt, dass GCD 42 Verzeichnisdienste an Käufer 20 und Verkäufer 30 um die Welt (oder in jeder anderen besonderen Region) bietet, oder dass der Inhalt von GCD 42 von der ganzen Welt (oder von jeder anderen besonderen Region) ist.
  • Obwohl Käufer 20 und Verkäufer 30 als separate Einheiten beschrieben werden, kann ein Käufer 20 in einer Transaktion ein Verkäufer 30 in einer anderen Transaktion und umgekehrt sein. Überdies beinhaltet die Bezugnahme auf "Käufer" oder "Verkäufer" eine Person, ein Computersystem, eine Organisation oder jede andere Einheit, wenn erforderlich. Beispielsweise kann ein Käufer 20 ein Computer sein, der so programmiert ist, dass er selbstständig den Bedarf für ein Produkt ermittelt und das Produkt nach Herausfinden eines geeigneten Verkäufers kauft. Obwohl Kaufen und Verkaufen hier bereits beschrieben wurde, beansprucht die vorliegende Erfindung jede angemessene e-commerce Transaktion. Überdies beinhaltet die Bezugnahme auf "Produkte" Waren, Immobilien, Dienstleistungen, Informationen und alle anderen angemessenen materiellen oder immateriellen Dinge.
  • Eine typische e-commerce Transaktion kann eine Verbindungsphase und eine Transaktionsphase beinhalten. Während der Verbindungsphase kann ein Käufer 20 nach einem geeigneten Produkt suchen (bedeutet jede Ware, Immobilie, Dienstleistung, Information oder andere materielle oder immaterielle Dinge, die Subjekt einer e-commerce Transaktion sein können), die von einem oder mehreren Verkäufern 30 angeboten werden, den geeigneten Verkäufer 30 identifizieren (was zum Beispiel das Identifizieren des Verkäufers 30 als den preiswertesten Anbieter beinhaltet) und diesen Verkäufers 30 kontaktieren, um in die transaktionale Phase überzugehen. Während der transaktionalen Phase können der Käufer 20 und der Verkäufer 30 einen Vertrag für den Kauf des Produktes aushandeln (was zum Beispiel eine nähere Beschreibung des Objektes der Transaktion, Verhandeln eines Preises und Abschließen einer Vereinbarung über die Lieferung beinhalten kann) und ein rechtskräftiges Dokument aufsetzen, welches die ausgehandelten Vertragsbedingungen verkörpert. Um den geeignetsten Verkäufer 30 während der Verbindungsphase ohne den Gebrauch des GCD 42 zu identifizieren, kann ein Käufer 20 viele Verkäufer-Webseiten aufsuchen müssen, um zu entscheiden, welcher Verkäufer 30 bestimmte gewünschte Produkteigenschaften zum besten Preis anbietet. Verkäufer 30 können jeweils eine oder mehrere Datenbanken 32 anbieten, wie beispielsweise relationale Datenbanken, welche Daten beinhalten, die die verfügbaren Produkte der Verkäufer 30 identifizieren und deren Eigenschaften. Jede Datenbank 32 ist zugänglich über die verbundene Webseite des Verkäufers oder auf jede andere geeignete Art. Die vielfachen 1 : 1-Suchen (ein Käufer 20 zu einem Verkäufer 30), die dieser Vorgang erfordert, sind ineffizient und teuer wegen des großen Suchumfangs, den das Finden eines Produktes beinhaltet, und weil die verschiedenen Angebote dieses Produkts durch verschiedene Verkäufer 30 nicht einfach verglichen werden können.
  • Alternativ können viele Verkäufer 30 in einem elektronischen Marktplatz gruppiert werden gemäß der Produkte, die sie anbieten, und ein Käufer 20 kann die Angebote der vielen Verkäufer 30 auf einer einzelnen Webseite durchsuchen. Wenn der Käufer 20 mehrere verschiedene Arten von Produkten zu erhalten wünscht, muss der Käufer 20 durch mehrere verschiedene Arten von Marktplätzen gehen. Weiterhin können mehrere konkurrierende Marktplätze bestehen, die der Käufer 20 durchsuchen muss, um die Verbindungsphase einer Transaktion für ein bestimmtes Produkt auszuführen. Ein potentielles Verfahren, dieses Problem anzugehen, ist das Erzeugen einer globalen Produktdatenbank, die potentiell Daten beinhaltet, die die Merkmale aller Produkte identifiziert, die jeder Käufer zu erhalten wünschen kann. Demgemäss würde die globale Datenbank die kombinierten Inhalte jeder Datenbank 32 verbunden mit jedem Verkäufer 30 beinhalten. Eine solche globale Datenbank würde jedoch viele Probleme haben. Die reine Größe der Datenbank würde eine Suche schwierig machen, und demgemäss würde die Datenbank unter Ausführungsproblemen leiden. Zusätzlich wäre es schwierig, einer großen Anzahl von Käufern 20 zu erlauben, die Datenbank gleichzeitig zu durchsuchen. Weiterhin müssten alle Verkäufer 30 auf die Datenbank zugreifen, um ihre Informationen auf den neuesten Stand zu bringen, und die gesamte Datenbank müsste jedes Mal auf den neuesten Stand gebracht werden, wenn eine Veränderung gemacht wird. Viele andere Probleme können auch noch bestehen.
  • Wie bereits vorab erwähnt, beinhaltet die Transaktionsphase die Erzeugung und den Gebrauch von einem oder mehreren Dokumenten zwischen Käufer 20 und Verkäufer 30. Zum Erzeugen und Gebrauchen von Dokumenten ohne die Hilfe von GCD 42 in der Transaktionsphase kann der Käufer 20 jedes Mal neue Dokumente erzeugen müssen, wenn Käufer 20 in eine neue Transaktion mit einem Verkäufer 30 eintritt und dann die rechtlichen und geschäftlichen Punkte mit Verkäufer 30 aushandeln, obwohl Käufer 20 und Verkäufer 30 bereits vorab Interaktionen hatten, aufgrund der Tatsache, dass es keine gespeicherte Aufzeichnung von vorherigen Transaktionen gibt, wenn nicht Käufer 20 oder Verkäufer 30 eine solche Aufzeichnung aufhebt. Das Erzeugen und Aushandeln eines Dokumentes erhöht die Transaktionskosten und die Zeit jeder Transaktion. Wenn zusätzlich Käufer 20 eine Aufzeichnung wünscht von dem, was er vorher in vorausgegangenen Transaktionen mit verschiedenen Verkäufern 30 gekauft hat, ist der Käufer 20 verantwortlich für das Speichern seiner eigenen Dokumente in einer Käuferdatenbank oder an einem anderen dem Käufer zugänglichen Ort. Das Problem wird größer, wenn Käufer 20 mit einem Verkäufer 30 interagiert, mit dem Käufer 20 noch nie interagiert hat, da es keinen gemeinschaftlichen Boden zum Beginnen gibt und die Dokumente im allgemeinen erzeugt werden müssen. Selbst wenn Käufer 20 in vielen Transaktionen mit einem besonderen Verkäufer 30 verwickelt war, kann die Dokumenterzeugung ineffizient sein. Auch wenn ein dem System 10 noch nicht bekannter Käufer 20 sich entscheidet, das System 10 zum ersten Mal zu benutzen, ist das Abschließen einer Transaktion mit Verlkäufer 30 ein langer und ermüdender Vorgang, da Käufer 20 alle erforderlichen Dokumente von Anfang an neu erzeugen muss, oder gezwungen ist, die Dokumente des Verkäufers 30 zu benutzen. Einige Verkäufer 30 versuchen, eine Aufzeichnung der Transaktionen durch Speicherung der Dokumente in einer oder mehreren Verkäuferdatenbanken 32 zu bewahren. Die in den Verkäuferdatenbanken 32 gespeicherten Dokumente sind jedoch üblicherweise nur den Verkäufern 30 zugänglich, denen die Dokumente gehören, und sind im allgemeinen für Käufer 20 oder andere Verkäufer 30 nicht zugänglich.
  • Eine Lösung der oben genannten Probleme, zumindest teilweise, ist GCD 42. GCD 42 ist ein universales Verzeichnis der Inhalte verschiedener Verkäuferdatenbanken 32 (und potentiell aller Verkäuferdatenbanken 32) und bietet einen Weg, die Dokumente für Käufer 20 und andere Verkäufer 30 zugänglich zu machen. GCD 42 kann durch Verwenden eines oder mehrerer Server 40 oder anderer Computer implementiert werden, die an einem oder mehreren Orten angeordnet sind. Der Großteil oder der gesamte Inhalt dieser Verkäuferdatenbanken 32 bleibt in Datenbanken 32 gespeichert, aber der Inhalt ist unter Verwendung von GCD 42 zugänglich. Demgemäss bietet GCD 42, wie die oben beschriebene globale Datenbank, den Käufern 20 Zugang zu den Produktdaten in Verbindung zu einer Vielzahl von Produkten (und potentiell Verkäuferdaten, die sich auf einen oder mehrere Verkäufer 30 der Produkte beziehen) ebenso wie die Dokumente aus vorangegangen Transaktionen zwischen Käufern 20 und Verkäufern 30. Anders als die globale Datenbank versucht GCD 42 nicht, all diese Daten und all diese Dokumente in einer einzigen riesigen Datenbank zu speichern. Wo angemessen, bedeutet die Bezugnahme auf "Daten" Produktdaten (heißt Informationen, die bestimmte Produktattribute darstellen), Verkäuferdaten (bedeutet Informationen, die bestimmte Verkäuferattribute darstellen) oder sowohl Produktdaten als auch Verkäuferdaten. Wo angemessen, bedeutet die Bezugnahme auf "Dokumente" Dokumente, die von einem Käufer 20 für eine Transaktion erzeugt oder verwendet wurden und/oder Dokumente, die von einem Verkäufer 30 für eine Transaktion benutzt oder erstellt wurden.
  • GCD 42 bietet ein Verzeichnis von Produkten und Dokumenten unter Verwendung einer Verzeichnisstruktur, in welcher Produkte und/oder Dokumente unter Verwendung eines hierarchischen Klassifikationssystems organisiert sind. Ein Käufer 20 kann sich durch das Verzeichnis bewegen oder das Verzeichnis durchsuchen, um eine bestimmte Produktklasse zu finden, in welcher Produkte kategorisiert sind, eine besondere Produktklasse, in welcher Dokumente kategorisiert sind, oder eine besondere Dokumentenklasse, in welcher Dokumente kategorisiert sind. Die Produktdaten (und möglicherweise Verkäuferdaten), die mit einem Produkt verbunden sind, das in einer Produktklasse beinhaltet ist, können durch GCD 42 augenblicklich in einer Verkäuferdatenbank 32 gespeichert und davon erhalten werden. Die Dokumente, die mit einem in einer Produktklasse beinhalteten Produkt verbunden sind, und die Dokumente, die in einer Dokumentenklasse beinhaltet sind, können auch durch GCD 42 in einer Verkäuferdatenbank 32 gespeichert und davon erhalten werden. Die angeforderten Daten oder das angeforderte Dokument können jedoch transparent dem Käufer 20 geliefert werden, so dass alle Produktdaten und Dokumente dem Käufer 20 so erscheinen, als seien sie in GCD 42 enthalten. Obwohl die Produktdaten, Verkäuferdaten und Dokumente vorab beschrieben wurden als in einer Verkäuferdatenbank 32 gespeichert, beansprucht die vorliegende Erfindung Produkt- und Verkäuferdaten und Dokumente, die in angemessener Weise gespeichert und erhalten werden von jeder angemessenen Quelle. Zum Beispiel kann das System 10 einen geteilten Datenspeicher 34 beinhalten, der Produktdaten und/oder Verkäuferdaten beinhaltet, welche mit Daten von einer oder mehreren Verkäuferdatenbanken 32 kombiniert werden können, und welcher Dokumente beinhaltet, die Dokumente aus einer oder mehreren Verkäuferdatenbanken 32 ergänzen können, wie nachfolgend genauer beschrieben wird.
  • Fig. 2 zeigt eine beispielhafte Verzeichnisstruktur 44 eines beispielhaften GCD 42 für Produktklassen. Produkte und Dokumente, die in GCD 42 kategorisiert sind, können gemäß Schemata organisiert werden. Ein Schema kann einen Satz Produktklassen beinhalten (auf die mit "Taxonomie" Bezug genommen wird), die in einer Hierarchie organisiert sind. Jede Klasse kann mit einem Satz Produktmerkmalen, Eigenschaften oder anderen Produktattributen verbunden sein (worauf Bezug genommen wird als "Produktontologie") und/oder mit einem Satz von Dokumentmerkmalen, Eigenschaften oder anderen Dokumentattributen (eine "Dokumentontologie") für jede Art von Produkt. Zum Beispiel können Stifte verschiedene Arten von Spitzen haben (wie zum Beispiel Kugelschreiber oder Filzschreiber), verschiedene Spitzenbreiten (wie zum Beispiel fein, mittel oder breit) undl verschiedene Tintenfarben (wie zum Beispiel blau, schwarz oder rot). Zusätzlich kann es für Filzschreiber bestimmte Dokumente geben, die mit ihnen verbunden sind, während Kugelschreiber verschiedene Dokumente haben, die mit ihnen verbunden sind. Demgemäss kann ein Schema eine Klasse beinhalten, die Stiften entspricht, welche eine Produktontologie haben, die Spitzenart, Spitzenbreite und Farbe beinhaltet oder andere angemessene Attribute, sowie Dokumente für Stifte oder spezielle Stiftarten. Innerhalb einer Klasse können Produkte definiert werden durch Produktattributwerte (wie beispielsweise Kugelschreiber, mittlere Spitze, blaue Tinte). Bezugnahme auf "Wert" bedeutet, alle geeigneten Daten aufzunehmen, die eine Instanz eines Produktattributs oder Verkäuferattributs widerspiegeln. Produktattributwerte und Verkäuferattributwerte können Zahlen, Buchstaben, Abbildungen, Eigenschaften, Zeichen oder andere geeignete Informationen zum Beschreiben eines Produktes respektive eines Verkäufers beinhalten. In einer Ausführungsform kann eine Produktontologie geteilt werden in erforderliche Eingabeattribute (bedeutet Attribut, für welche ein Wert gegeben werden muss) und optionale Eingabeattribute (bedeutet Attribute, für welche ein Wert optional ist) und diese Kategorien können weiter geteilt werden in kommerzielle Merkmale und gestalterische Merkmale (oder jede andere angemessene Unterteilung).
  • Zusätzlich zu einer Taxonomie und Produkt- und Dokumentontologien kann ein Schema einen. Satz von Attributen für jeden Verkäufer beinhalten (auf welchen Bezug genommen wird als "Verkäuferontologie"). Solche Attribute können geographische Einschränkungen beinhalten (wie beispielsweise erschlossene Märkte), akzeptierte Währungen jedes Verkäufers, von jedem Verkäufer akzeptierte gemeinschaftliche Hilfsmittel, akzeptierte Vertragsbedingungen jedes Verkäufers, akzeptierte Vertragsarten jedes Verkäufers, Kreditwürdigkeit von Käufern, die von jedem Verkäufer gefordert wird und alle anderen geeigneten Verkäuferattribute. Gleich den Produkten innerhalb einer Produktklasse können Verkäufer, die bestimmte Produkte innerhalb einer Produktklasse anbieten, durch Verkäuferattributwerte entsprechend Verkäuferattributen definiert werden. Demgemäss kann ein Schema einen Satz von Klassen beinhalten, welcher jeweils eines oder mehrere Produkte beinhaltet, und jede Klasse kann mit einem Satz von Produktattributen und einem Satz von Verkäuferattributen verbunden werden.
  • In der beispielhaften Verzeichnisstruktur 44 können die Produkte organisiert und katalogisiert werden gemäß industriellen Standardschemas 46 oder anderen geeigneten Schemata, wie nachfolgend beschrieben wird. Innerhalb eines Industriestandardschemas 46 sind zwei beispielhafte Klassen: eine direkte Materialklasse 48 und eine indirekte Materialklasse 50. Jede dieser Klassen 48 und 50 beinhaltet mehrere Unterklassen (welche wiederum Unterklassen beinhalten können). Demgemäss bilden die zahlreichen Klassen der Verzeichnisstruktur 44 eine "baumähnliche" hierarchische Struktur, in welcher Produkte und Dokumente kategorisiert werden können. Zu Beispielzwecken sind verschiedene Abschnitte der Verzeichnisstruktur 44 in Fig. 2 "ausgedehnt", um verschiedene Ebenen von Klassen darzustellen. Die "Ebene" einer Klasse wird angezeigt durch die Anzahl anderer Klassen zwischen dieser Klasse und einer Wurzelklasse (wie beispielsweise Industriestandardschema Klasse 46). Zum Beispiel ist die indirekte Materialklasse 50 auf der gleichen Ebene in der Verzeichnisstruktur wie die direkte Materialklasse 48. Die indirekte Materialklasse 50 kann eine Büro- und Computerzubehörklasse 52 beinhalten, welche eine Tischzubehörklasse 45 beinhaltet, welche eine Schreibutensilienklasse 56 beinhaltet. Weiter beinhaltet die Schreibutensilienklasse 56 eine Stifteklasse 58, welche zahlreiche Stiftartenklassen 60a-60n beinhaltet ("n" bedeutet, dass jede Anzahl von Klassen 60 innerhalb der Stifteklasse 58 beinhaltet sein kann), eine Stiftedokumentenklasse 59 für alle Stifte und eine Stiftedokumentenklasse 63a-63n für jede Art Stiftartenklasse 60a-60n entsprechend. Jede der Klassen 50, 52, 54, 56, 58 und 60 ist auf verschiedenen Ebenen der Verzeichnisstruktur 44 angeordnet. Eine auf einer beliebigen Ebene der Verzeichnisstruktur 44 liegende Klasse kann eine oder mehrere Unterklassen beinhalten, diese Unterklassen können eine oder mehrere Unterklassen beinhalten usw., bis eine gewünschte Klassifizierungsgenauigkeit erreicht ist. Auf eine Serie von Klassen von der höchsten Klassenebene (die breiteste Klasse) zur niedrigsten Klassenebene (die genaueste Klasse) kann als "Zweig" der Verzeichnisstruktur 44 Bezug genommen werden. Zum Beispiel bilden die Klassen 46, 48, 50, 52, 54, 56, 58, 60b und 63b einen Zweig der Verzeichnisstruktur 44.
  • Obwohl die beispielhafte Verzeichnisstruktur 44 auch Industriestandardschemas 46 verwenden kann wie oben beschrieben, kann jedes andere geeignete Schemata 62zusätzlich oder an Stelle des Industriestandardschemas 46 verwendet werden. Während beispielsweise das Industriestandardschema 46 aus der Sicht eines Verkäufers organisiert werden kann, können andere Schemata 62 so verwendet werden, dass sie Produkte aus der Sicht eines Käufers organisieren. Beispielsweise kann ein Käufer 20 wünschen, eine Küche eines neuen Hauses mit verschiedenen Produkten wie beispielsweise Geräten, Fensterbehandlungsmitteln, Farben, Schränken, sanitären Einrichtungen, Geschirr und Kochutensilien auszustatten. Unter Verwendung eines Schemas 62 können diese Produkte organisiert werden in einer Vielzahl nicht verbundener Klassen basierend auf bestimmten Merkmalen der Produkte (zum Beispiel können bestimmte Küchengeräte in einer Elektrogeräteklasse 52 der Verzeichnisstruktur 44 kategorisiert werden, während Farbe in einer industriellen Klasse 52 kategorisiert werden kann). Ein anderes Beispielschema 62 kann jedoch alle diese Produkte in einer Heimprodukteklasse klassifizieren (welche verschiedene Klassen beinhalten kann, die die Produkte weiter kategorisiert, wie zum Beispiel eine Küchenprodukteklasse, welche eine Küchengeräteklasse beinhaltet, welche eine Kühlschrankklasse beinhaltet, usw.). Demgemäss kann das gleiche Produkt in einer Vielzahl von Schemata 62 beinhaltet sein. Diese alternativen Schemata können in einer Verzeichnisstruktur 44 beinhaltet sein und gespeichert sein als Teil oder getrennt von GCD 42.
  • Ein Käufer 20 kann sich durch die Verzeichnisstruktur 44 bewegen durch Erweitern oder Verkleinern verschiedener Klassen je nach Wunsch. Fig. 2 zeigt beispielsweise das Erweitern von bestimmten Klassen der Verzeichnisstruktur 44 zum Erreichen einer Filzschreiberklasse 60b. Hat sich Käufer 20 durch eine Klasse hindurch bewegt, welche genau genug für Käufer 20 ist (und/oder eine Klasse, welche das Ende dieses Zweiges ist), kann Käufer 20 eine Suche nach Produkten innerhalb dieser Klasse durchführen. Käufer 20 kann zum Beispiel in der Schreibutensilienklasse 56 nach allen Produkten suchen, die blaue Filzschreiber mit einer mittleren Spitze sind. Alternativ dazu, sofern Käufer 20 sich zu dem Ende eines Zweiges der Verzeichnisstruktur 44 bewegt, wie beispielsweise der Filzschreiberklasse 60b, kann GCD 42 dem Käufer ermöglichen, nach solchen Stiften zu suchen, die blaue Tinte und mittlere Spitzen haben (was das gleiche Ergebnis erzielen kann wie die oben genannte Suche).
  • Käufer 20 kann auch nach Verkäufern suchen, auf die ein oder mehrere Verkäuferattributwerte innerhalb einer Produkteklasse zutreffen. Beispielsweise kann der Käufer 20 zusätzlich zu seiner Suche nach allen Produkten in der Schreibutensilienklasse 56, die blaue Filzschreiber mit mittlerer Spitze sind, auch nach Verkäufern 30 suchen, die Texas beliefern und US-Dollar akzeptieren. Käufer 20 kann nach Produkten suchen, auf die bestimmte Produktattributwerte zutreffen und Verkäufer, auf die bestimmte Verkäuferattributwerte zutreffen, auf jede geeignete Weise. In einer Ausführungsform liefert Käufer 20 beispielsweise Suchkriterien, die sowohl Werte für Produktattribute als auch für Verkäuferattribute beinhalten (diese Suchkriterien können statt dessen auch komplett oder teilweise automatisch erzeugt werden, wie nachfolgend beschrieben wird), und Server 40 sucht nach Produkten, auf die die Produktattributkriterien zutreffen und die von Verkäufern angeboten werden, auf die die Verkäuferattributwerte zutreffen. In einer anderen Ausführungsform liefert Käufer 20 nur Produktattributwerte als Suchkriterien, und Server 40 begrenzt seine Suche nach Produkten, die diese Produktattributkriterien erfüllen, auf Datenbanken 32, die mit Verkäufern 30 verbunden sind, von denen bekannt ist, dass sie die Verkäuferattributkriterien erfüllen, die Käufer 20 gemäß einem Käuferprofil oder auf andere Art wünscht.
  • Käufer 20 kann auch nach Dokumenten suchen, die mit gewünschten Produkten innerhalb der Produktklasse verbunden sind, unter Verwendung der Verzeichnisstruktur 44 und GCD 42. Käufer 20 kann Verzeichnisstruktur 44 durchsuchen unter Verwendung von GCD 42 zum Lokalisieren von mit speziellen Produkten verbundenen Dokumente. Beispielsweise kann Käufer 20 wünschen, Stifte zu kaufen, und benötigt Dokumente, die diese Transaktion erleichtern. Käufer 20 kann auf mindestens zwei Arten stiftbezogene Dokumente finden, abhängig von der Genauigkeit des von Käufer 20 gesuchten Produktes. Wenn Käufer 20 an mehr als einer Stiftart interessiert ist, kann sich Käufer 20 durch die Verzeichnisstruktur 44 bewegen zu der Stifidokumentenklasse 59. Ist er einmal in der Stiftdokumentenklasse 59, kann Käufer 20 eine Suche durchführen nach allen Dokumenten, die mit dieser Art von Stiften in Bezug stehen. Stifidokumentenklasse 59 beinhaltet ein oder mehrere Dokumentenunterklassen 61a-61n, in denen Stiftdokumente nach ihrer Dokumentart kategorisiert sind, so dass, wenn Käufer 20 weiß, welche Art von Dokument er benötigt, Käufer 20 nach Dokumenten dieser bestimmten Art in Bezug auf alle Arten von Stiften suchen kann. Zum Beispiel beinhaltet die Dokumentenunterklasse 61a Dokumente zur Aufforderung zur Angebotsabgabe für alle Stiftarten, während Dokumentenunterklasse 61b Bestellformulardokumente für alle Stiftarten beinhaltet. Wenn also Käufer 20 eine Aufforderung zur Angebotsabgabe zur Bestellung von Stiften möchte, bewegt er sich bis zur Dokumentenunterklasse 61a und sucht das Dokument bezüglich Aufforderung zur Angebotsabgabe, das sich auf alle Stiftarten bezieht. Das Klassifizieren der Dokumente innerhalb der Produktklassen ermöglicht dem Käufer 20 weiter, eine detailliertere Suche auszuführen. Wenn Käufer 20 zum Beispiel nur an Kugelschreibern interessiert ist, kann sich Käufer 20 bis zu der Kugelschreiberklasse 60a wie oben beschrieben bewegen. Die Kugelschreiberklasse 60a beinhaltet Kugelschreiberdokumentenklasse 63a, welche Dokumente beinhaltet, die sich auf Kugelschreiber beziehen. Käufer 20 kann eine Suche innerhalb der Stiftartendokumentenklasse 63a durchführen und nach allen Dokumenten suchen, die sich auf Kugelschreiber beziehen unabhängig von der Dokumentenart. Eine Suche innerhalb der Kugelschreiberdokumentenklasse 63a kann auch eingegrenzt werden durch Begrenzen der Suchkriterien auf nur eine besondere Dokumentart, beispielsweise eine Suche nach Bestellungen, so dass das Suchergebnis nur Bestelldokumente in Bezug auf Kugelschreiber findet. Hat Käufer 20 ein geeignetes Dokument sowohl der Dokumentenart als auch der Produktart lokalisiert, kann Käufer 20 das Dokument zu seinem eigenen Gebrauch wie unten beschrieben modifizieren.
  • Wie oben beschrieben, sind in einer Ausführungsform Produktarten (wenigstens genauere Produktdaten als die durch eine Taxonomie gelieferten Daten), Verkäuferdaten und Dokumentdaten nicht in GCD 42 gespeichert, sondern in einer Verkäuferdatenbank 32. Zum Beispiel kann ein Verkäufer 30 eine relationale Datenbank 32 pflegen, welche eine Vielzahl von Tabellen beinhaltet, in denen Produktattributwerte für eine Vielzahl von Produkten und Verkäuferattributwerte für jedes Produkt, einem Satz von Produkten oder alle Produkte, die von Verkäufer 30 angeboten werden, enthalten sind. Innerhalb der Verkäuferdatenbank 32 kann Verkäufer 30 auch Dokumente aus vorhergehenden Transaktionen zwischen Verkäufer 30 und verschiedenen Käufern 20 speichern. Produktdaten und Verkäuferdaten können in eine oder mehrere Tabellen integriert werden oder können in verschiedene Tabellen getrennt werden. Weiter können Produktdaten und Verkäuferdaten für einen Verkäufer 30 in der gleichen oder in verschiedenen Datenbanken gespeichert werden. Ein oder mehrere Zeiger können mit jeder Klasse verknüpft werden zum Identifizieren des Ortes einer oder mehrerer Datenbanken 32, welche Produktdaten beinhalten, Verkäuferdaten und Dokumente für Produkte, die in dieser Klasse beinhaltet sind, oder zum Identifizieren besonderer Daten oder besonderer Dokumente in Verkäuferdatenbanken 32. Demgemäss kann GCD 42 eine Suche nach Produkten oder Dokumenten in Datenbanken 32 durchführen, die durch einen Zeiger identifiziert sind entsprechend einer benutzergewählten (oder automatisch gewählten) Klasse. GCD 42 kann auch die Netzwerkadresse (wie beispielsweise eine einheitliche Adressierungsstruktur zur eindeutigen Identifizierung von Ressourcen (URL (= uniform resource locator), oder andere Netzwerkadressen) der Datenbank 32 zu Käufer 20 zurücksenden, so dass Käufer 20 unabhängig auf die Datenbank 32 zugreifen kann. Die Datenbanken 32 können durchsucht werden unter Verwendung jedes geeigneten Verfahrens, welches eine strukturierte Abfragesprache (SQL; structured query language) Abfrage beinhaltet, aber nicht darauf begrenzt ist.
  • GCD 42 kann unter Verwendung des LDAP-Protokolls (lightweight directory access protocol; Verzeichniszugangsprotokoll) implementiert werden, welches ermöglicht, dass Verzeichnisse unter Verwendung der baumähnlichen Struktur wie oben beschrieben geliefert werden. Jedoch kann jede andere geeignete Technik oder jedes andere Protokoll zum Erzeugen von GCD 42 alternativ verwendet werden und GCD 42 kann jede angemessene Struktur haben. Weiter kann GCD 42 ein objektbezogenes Verzeichnis (was ebenfalls durch LDAP geliefert wird) sein, so dass jede Klasse in Verzeichnisstruktur 44 die Attribute der übergeordneten Klassen beinhaltet, in welcher die Klasse eine Unterklasse ist. Diese Ausführungsform beinhaltet eine Klasse, die am Ende eines Zweiges der Baumstruktur aufgeführt ist und alle Attribute seiner übergeordneten Klassen beinhaltet. Weiter kann jedes Produkt oder Dokument, welches in Datenbank 32 beinhaltet ist, ein Objekt sein, welches alle Attribute der Klassen beinhaltet, in welchen das Produkt oder Dokument enthalten ist. Überdies kann, wenn eine Suche von einer Klasse am Ende eines Zweiges der Verzeichnisstruktur 44 aus ausgeführt wird, die Suchanfrage automatisch alle geeigneten Attribute von übergeordneten Klassen dieser Klasse beinhalten.
  • Wenn sich ein Käufer 20 beispielsweise durch die Verzeichnisstruktur 44 bis zur Filzschreiberklasse 60b hindurchbewegt hat, kann eine Suche, die von Käufer 20 (oder von GCD 42 anstelle des Käufers 20) von der Filzschreiberklasse 60b durchgeführt wird, automatisch auf eine Suche nach Filzschreibern begrenzt werden und Käufer 20 kann zusätzliche gewünschte Suchkriterien einführen (wie beispielsweise blaue Tinte und mittlere Spitze). Wenn demgemäss eine durchsuchte Datenbank 32 Produktdaten beinhaltet, die sich auf eine Vielzahl von Schreibutensilien beziehen, kann eine Suche in Datenbank 32 von GCD 42 automatisch begrenzt werden, so dass sie nur Filzschreiber innerhalb dieser Datenbank 32 beinhaltet. Käufer 20 kann weiter zusätzliche Produktattributwerte und/oder Verkäuferattributwerte als zusätzliche Suchkriterien identifizieren.
  • Wenn GCD 42 eine Suche der Datenbanken 32 durchführt, die durch einen Zeiger identifiziert wird oder durch Zeiger, die mit einer von Käufer 20 ausgewählten Klasse verknüpft sind (oder die automatisch ausgewählt wurden), kann GCD 42 Produktdaten, Verkäuferdaten und/oder Dokumente als Ergebnis liefern, die mit einer oder mehreren Produkten verbunden sind, welche die Suchkriterien erfüllen. GCD 42 kann Produktdaten, Verkäuferdaten und/oder Dokumente, die aus einer Suche resultieren, in die Verzeichnisstruktur 44 integrieren, so dass die Daten dem Verkäufer 20 als Teil von GCD 42 erscheinen. GCD 42 kann alternativ die Ergebnisse der Suche auf jede andere geeignete Weise darstellen. Jedes Produkt oder Dokument, das Ergebnis einer Suche ist, kann ein Objekt sein, welches eine unverwechselbare Instanz der Klasse ist, in welcher Käufer 20 gesucht hat. Weiter kann jedes dieser Objekte (und sein Ort) unverwechselbar identifiziert werden unter Verwendung eines Nummerierungsverfahrens entsprechend der Verzeichnisstruktur 44.
  • Kurz zusammenfassend kann ein Käufer 20 ein Produkt suchen, welches bestimmte Produktattributwerte erfüllt von einem Verkäufer 30, der bestimmte Verkäuferattributwerte erfüllt unter Verwendung von GCD 42, wodurch die Notwendigkeit für Käufer 20 vermieden oder reduziert wird, eine Anzahl verschiedener Verkäuferdatenbanken 32 individuell zu durchsuchen, um das gewünschte Produkt von einem geeigneten Verkäufer zu finden. Zusätzlich kann ein Käufer 20 auch nach einem Dokument suchen, welches bestimmte Attribute erfüllt und die Notwendigkeit zum Schaffen von Dokumenten jedes Mal, wenn Käufer 20 eine neue Transaktion mit einem Verkäufer 30 in Bezug auf ein oder mehrere Produkte beginnt, verhindern. GCD 42 bietet Zugang zu Produkt- und Verkäuferdaten und Dokumenten, die sich auf diese zahlreichen Produkte beziehen, unter Verwendung der Verzeichnisstruktur 44, welche Produkte unter Verwendung eines hierarchischen objektbezogenen Klassifikationssystems organisiert. Innerhalb Verzeichnisstruktur 44 kann sich Käufer 20 bewegen oder eine Suche durchführen, um eine bestimmte Klassifikation von Produkten und verschiedene Informationen zu finden, die mit den Produkten innerhalb dieser Klassifikation verbunden sind, einschließlich Dokumenten, die mit verschiedenen Produkten verbunden sind, kann eine Suche von Datenbanken 32 für Produkte und/oder Dokumente einleiten einschließlich Produkt- und/oder Verkäuferdaten, die sich auf ein Produkt beziehen, und dann mit einer entsprechenden Datenbank 32 über GCD-Server 40 oder auf andere Art kommunizieren. Ein solcher Zugang zu einer riesigen Anzahl von Produkten und Dokumenten wird ohne die Notwendigkeit bereitgestellt, dass alle Daten über die Produkte, Verkäufer und Dokumenten in einer globalen Datenbank gespeichert sind. Stattdessen können die Daten in Verkäuferdatenbanken 32 gespeichert sein, auf welche unter Verwendung von GCD 42 einfach zugegriffen werden kann.
  • Ein Problem, das mit der Verwendung von verschiedenen Verkäuferdatenbanken 32 verbunden sein kann, ist, dass diese Datenbanken 32 Produktdaten über dieselbe Produktklasse (z. B. Filzschreiber) beinhalten können, aber Produkte dieser Klasse unter Verwendung von verschiedenen Attributwerten identifiziert sein können, verschiedene Namen für denselben Produktattributwert verwendet sein können und/oder Produktabtributwerte unterschiedlich quantitativ bestimmt oder unterschieden sein können (beispielsweise unter Verwendung verschiedener Maßeinheiten). Das gleiche kann auf Verkäuferdaten zutreffen, die in Datenbanken 32 enthalten sind. Zusätzlich haben Käufer 20 und Verkäufer 30 Dokumente in verschiedenen Formaten, die sich voneinander unterscheiden. Einige dieser Punkte können gelöst werden durch Verwendung von Ubersetzungsmechanismen, die die Daten in ein einheitliches Format konvertieren, welches von GCD 42 verwendet wird, sowie die verschiedenen Dokumente in ein Standardformat konvertieren, welches von GCD 42 verstanden wird. Alternativ können Verkäufer 30 neue Datenbanken 32 erstellen oder manuell existierende Datenbanken 32 modifizieren (oder von Dritten die Datenbanken 32 modifizieren oder erstellen lassen), um einem einheitlichen Standard zu entsprechen in der Erwartung, dass eine Datenbank 32 in Verbindung mit GCD 42 verwendet wird sowie Käufer 20 und Verkäufer 30 Dokumente erstellen oder modifizieren, um einem Standardformat zu entsprechen, das in Verbindung mit GCD 42 verwendet wird.
  • Das Erstellen oder Modifizieren von Dokumenten in ein Standardformat ist eine schwierigere Aufgabe als das Standardisieren von Produktdaten, da, während jedes Dokument eine ähnliche Basisinformation enthalten kann, jeder Käufer 20 und Verkäufer 30 im allgemeinen bestimmte Klauseln, Abschnitte und Bestimmungen hat oder erfordert, die nicht vorhanden sind oder von anderen Käufern 20 und Verkäufern 30 gefordert werden. Zusätzlich können bestimmte Dokumentarten sehr ähnliche Informationen beinhalten, die sich nicht wesentlich unterscheiden, während andere Dokumentarten wesentlich von anderen abweichen und wenig oder keine gemeinsamen Bestimmungen aufweisen. Beispielsweise umfasst eine Aufforderung zur Angebotsabgabe im generischen Abschnitte mit Kontaktinformationen für Käufer 20 und Verkäufer 30, eine Produktbeschreibung und die geforderte Anzahl, und üblicherweise sind die meisten Aufforderungen zur Angebotsabgabe ähnlich, selbst dann, wenn sie von unterschiedlichen Käufern 20 oder Verkäufern 30 erstellt werden. Andere Dokumente, wie beispielsweise ein Formular zum Widerruf einer Bestellung, können sich drastisch unterscheiden, abhängig von den Konditionen, die von einem besonderen Käufer 20 oder Verkäufer 30 gefordert werden, da jeder Käufer 20 und Verkäufer 30 üblicherweise sein eigenes Verfahren und seine eigenen Anforderungen für Bestellungswiderrufe hat. Demgemäss ist eine Lösung für das Standardisierungsproblem das Klassifizieren der Dokumente in Standarddokumente und einzelne Dokumente und das Vorsehen eines geteilten Dokumentenspeichers 35, in welchen Standarddokumente gespeichert werden, was GCD 42 ermöglicht, effizienter zu funktionieren.
  • Standarddokumente sind Dokumente, die in einer standardisierten Form sind, welche von dem GCD-Server 40 erkannt wird, oder Dokumente, die sich nicht wesentlich zwischen verschiedenen Käufern 20 und Verkäufern 30 unterscheiden und welche innerhalb einer gegebenen Zeitspanne einfach zu standardisieren wären. Die standardisierte Form jedes Standarddokumentes unterscheidet sich abhängig von der Dokumentenart. Beispielsweise ist die standardisierte Form einer Aufforderung zur Angebotsabgabe unterschiedlich von der standardisierten Form eines Kaufvertrag-Standarddokumentes. Einzelne Dokumente sind Dokumente, die nicht in standardisierter Form sind, aber im allgemeinen in einem Format sind, welches von Käufer 20 oder Verkäufer 30 bestimmt wurde und im allgemeinen schwieriger auf ein Standardformular zu reduzieren sind. Einzelne Dokumente beinhalten oft für einen bestimmten Käufer 20 oder Verkäufer 30 spezifische Bedingungen und Konditionen, welche nicht auf alle Käufer 20 und Verkäufer 30 anwendbar sind. Einzelne Dokumente können sich wesentlich voneinander unterscheiden.
  • Der geteilte Dokumentenspeicher 35 beinhaltet eins oder mehrere Standarddokumente. Wenn ein Käufer 20 oder Verkäufer 30 ein Standarddokument erstellt oder ein Standarddokument, welches bereits in dem verteilter Dokumentenspeicher 35 vorhanden ist, modifiziert, wird das neu geschaffene oder modifizierte Standarddokument in dem verteilten Dokumentenspeicher 35 gespeichert. Einzelne Dokumente können in einer oder mehreren Verkäuferdatenbanken 32 gespeichert werden. Optimalerweise wird die Verbindung der Standarddokumente und einzelnen Dokumente, die sich auf ein bestimmtes Produkt beziehen, verknüpft von den Produktklassen von GCD 42, in welchen das Produkt kategorisiert ist. Beispielsweise kann die Stiftedokumentenklasse 59 in GCD 42 Zeiger sowohl auf Standard- als auch auf einzelne Dokumente in dem verteilten Dokumentenspeicher 35 und zu einer oder mehreren Verkäuferdatenbanken 32 beinhalten. Weiter können ein oder mehrere Zeiger zum verteilten Dokumentenspeicher 35 mit einem oder mehreren Zeigern zu Verkäuferdatenbank 32 verknüpft werden, so dass die sich darauf beziehenden Standarddokumente und einzelnen Dokumente miteinander verbunden werden können. Alternativ können die Standarddokumente in dem verteilten Dokumentenspeicher 35 verknüpft werden mit einem oder mehreren einzelnen Dokumenten in einer oder mehreren Verkäuferdatenbanken 32. Einzelne Dokumente aus Verkäuferdatenbank 32 können mit Standarddokumenten vom verteilten Dokumentenspeicher 35 kombiniert werden, so dass die Standarddokumente und einzelnen Dokumente dem Käufer 20 als Ergebnis einer Suche geliefert werden können, wie nachfolgend unter Bezugnahme auf die Fig. 6A & 6B genauer beschrieben wird.
  • Obwohl der geteilte Dokumentenspeicher 35 als einzelner Speicherort dargestellt ist, kann der geteilte Dokumentenspeicher 35 mehrere Speicherorte an dem gleichen oder verschiedenen physikalischen Orten beinhalten. Jede geeignete Anzahl von Speicherorten, angeordnet in einer Anzahl von physikalischen Orten, kann verwendet werden (z. B. können die Speicherorte in verschiedene geographische Regionen verteilt werden). GCD-Server 40 kann jeden dieser verteilten Dokumentenspeicher je nach Eignung durchsuchen, um Standarddokumente, die einer Käufersuche entsprechen, zu erhalten. Alternativ können mit einer Produktklasse verbundene Zeiger den GCD-Server 40 zu einem oder mehreren besonderen Speicherorten führen. Wenn zusätzliche vielfach geteilte Dokumentenspeicher 35 verwendet werden, kann jeder geteilte Dokumentenspeicher 35 identische Standarddokumente, einige gleiche und einige unterschiedliche Standarddokumente oder komplett unterschiedliche Standarddokumente beinhalten. Weiter kann der geteilte Dokumentenspeicher 35 Standarddokumente unter Verwendung jedes geeigneten Speichermediums speichern. Weiter wird darauf hingewiesen, dass, obwohl der geteilte Dokumentenspeicher 35 Standarddokumente beinhaltet, die Verkäuferdatenbanken 32 ebenfalls Standarddokumente beinhalten können.
  • Fig. 3 zeigt eine beispielhafte Verzeichnisstruktur 70 eines beispielhaften GCD 42 für Dokumentklassen. Zusätzlich zum Klassifizieren von Dokumenten innerhalb von Produktklassen können in GCD 42 kategorisierte Dokumente auch gemäß einem Schema organisiert werden, welches einen Satz von Dokumentklassen beinhaltet oder in einer Hierarchie organisierte Taxonomie, wobei jedes Dokument mit einem Satz von Dokumentenmerkmalen, -eigenschaften und anderen Dokumentattributen verbunden ist (eine "Dokumentontologie"). Das Klassifizieren der Dokumente innerhalb von Dokumentklassen, im Gegensatz zu Produktklassen wie oben unter Bezugnahme auf Fig. 2 beschrieben, ermöglicht dem Käufer 20 nach Dokumenten zu suchen basierend auf Dokumentarten unabhängig von dem Produkt, auf welches das Dokument Bezug nimmt.
  • In der beispielhaften Verzeichnisstruktur 70 können Dokumente organisiert und katalogisiert werden gemäß Transaktionsdokumentenschemas 72 oder anderen geeigneten Schemata, wie nachstehend beschrieben wird. Innerhalb Transaktionsdokumentenschemas 72 gibt es drei beispielhafte Klassen: Käuferdokumentenklasse 74, Verkäuferdokumentenklasse 76 und Dokumentenklasse 78. Jede dieser Klassen 74, 76 und 78 beinhaltet mehrere Unterklassen (welche ihrerseits wiederum Unterklassen enthalten können). Dementsprechend bilden die zahlreichen Klassen der Verzeichnisstruktur 70 eine "baumähnliche" hierarchische Struktur, in welche Dokumente kategorisiert werden können ähnlich der Verzeichnisstruktur 44. Als Beispiel werden bestimmte Abschnitte der Verzeichnisstruktur 70 in Fig. 3 "ausgedehnt", um verschiedene Ebenen von Klassen aufzuzeigen, wobei "Ebenen" von Klassen dem entspricht, was oben in Bezug auf Fig. 2 beschrieben wurde. Obwohl die beispielhafte Verzeichnisstruktur 70 Transaktionsdokumentenschemas 72 verwenden kann, wie oben beschrieben, kann jedes andere geeignete Schemata 80 zusätzlich zu oder anstelle des Transaktionsdokumentenschemas 72 verwendet werden. Das gleiche Dokument kann in zahlreichen. Schemata 80 beinhaltet sein, und diese alternativen Schemata 80 können in der Verzeichnisstruktur 70 beinhaltet sein und als Teil oder getrennt von GCD 42 gespeichert sein. Die Organisation der Verzeichnisstruktur 70 ist ähnlich der Organisation von Verzeichnisstruktur 44, außer dass sich die Verzeichnisstruktur 70 auf Dokumentklassen bezieht.
  • Wie in Fig. 3 dargestellt, beinhaltet die Käuferdokumentenklasse 74 Dokumente, die aus der Sicht des Käufers organisiert sind, die Verkäuferdokumentenklasse 76 beinhaltet Dokumente, die aus der Sicht des Verkäufers organisiert sind, und die Dokumentenklasse 78 beinhaltet alle Dokumente. Dokumente aus der Sicht eines Käufers in einer Transaktion zwischen Käufer 20 und Verkäufer 30 beinhalten vorteilhafte Bestimmungen für einen Käufer und sind üblicherweise durch einen Käufer in einer vorhergehenden Transaktion erstellt worden. Dokumente aus dem Gesichtspunkt eines Verkäufers aus früheren Transaktionen zwischen Käufer 20 und Verkäufer 30 beinhalten Bestimmungen, die vorteilhafter für den Verkäufer als für den Käufer sind und im allgemeinen durch einen Verkäufer in einer früheren Transaktion erstellt wurden. Beispielsweise können die Bestimmungen, die ein Dokument enthält, basierend auf der entsprechenden Handelskraft des Käufers und dem in die Transaktion verwickelten Verkäufers variieren. Hat der Verkäufer eine größere Handelskraft, wird das Dokument im allgemeinen dieses durch Bestimmungen widerspiegeln, die vorteilhafter für den Verkäufer sind. Hat aber der Käufer die größere Handelskraft, dann hat das sich daraus ergebende Dokument üblicherweise Bestimmungen, die den Käufer dem Verkäufer bevorzugen. Demgemäss kann ein Käufer 20, der nach einem bestimmten Dokument sucht, daran interessiert sein, Dokumente zu lokalisieren, die den Käufer gegenüber dem Verkäufer bevorzugen, wenn Käufer 20 die größere Handelskraft hat, oder sich für das Dokument aus der Sicht eines Verkäufers entscheiden, um eine Verhandlung mit dem Verkäufer abzukürzen, da das Dokument den Verkäufer bereits bevorzugt.
  • Käufer 20 bewegt sich durch die Verzeichnisstruktur 70 abhängig davon, welche Art Dokument er sucht. Wenn Käufer 20 nach Bestellformularen aus dem Gesichtspunkt des Käufers sucht, dann würde sich Käufer 20 zur Käuferdokumentenklasse 74 und zur Käuferbestellformularklasse 82b bewegen. Käufer 20 wäre dann in der Lage, eine Suche in allen Bestellformularen aus der Sicht des Käufers durchzuführen. Käufer 20 kann die Suche in der Käuferbestellformularklasse 82b weiter eingrenzen durch Suchen nach Bestellformularen, die vor weniger als einem Jahr erstellt wurden und sich auf Baumwollballen beziehen. Käufer 20 könnte weiter an Dokumenten interessiert sein, die mit Bestellbestätigungen aus der Sicht des Verkäufers verbunden sind und sich deswegen durch die Verzeichnisstruktur 70 zur Verkäuferdokumentenklasse 76 und Verkäuferbestellbestätigungsklasse 84n bewegen, um eine Suche nach allen Bestellbestätigungen aus der Sicht des Verkäufers durchzuführen. Dem Käufer 20 könnte es egal sein, ob ein Dokument aus der Sicht des Käufers oder Verkäufers erstellt wurde, und würde statt dessen bevorzugen, nach allen verfügbaren Dokumenten zu suchen. Ist dies der Fall, bewegt sich Käufer 20 durch die Verzeichnisstruktur 70 zur Dokumentenklasse 78, welche alle Dokumente beinhaltet. Käufer 20 kann dann eine der Dokumentenunterklassen 86a-86n durchsuchen abhängig davon, nach welcher Art Dokument Käufer 20 sucht. Käufer 20 kann weiter die Dokumentenklasse 78 durchsuchen und nach allen Dokumenten suchen, ohne die Suche weiter zu begrenzen.
  • Innerhalb der Verzeichnisstruktur 70 und den Dokumentenklassen können die Dokumente als Standarddokumente oder einzelne Dokumente kategorisiert sein und in dem verteilten Dokumentenspeicher 35 und Verkäuferdatenbanken 32, wie oben in Bezug auf Fig. 2 beschrieben, gespeichert sein. Die Verwendung der Verzeichnisstruktur 70 sowie der Zeiger zu dem verteilten Dokumentenspeicher 35 und den Verkäuferdatenbanken 32 steht, wie oben unter Bezugnahme auf Fig. 2 beschrieben, in Relation zu der Verzeichnisstruktur 44, außer, dass die Dokumente in Dokumentenklassen an Stelle von Produktklassen kategorisiert sind. In der Verzeichnisstruktur 44 sind die Dokumente mit bestimmten Produkten verbunden, und die Dokumente werden über Produktklassen gesucht. In der Verzeichnisstruktur 70 sind die Dokumente nicht in Produktklassen, sondern sind in Dokumentenklassen kategorisiert, die sich auf die Art des Dokumentes beziehen. Bei der Verzeichnisstruktur 44 ist ein Käufer oder Verkäufer mit einem bestimmten Produkt beschäftigt und möchte ein mit diesem Produkt verbundenes Dokument finden. Bei der Verzeichnisstruktur 70 ist ein Käufer oder Verkäufer an einer Dokumentart interessiert und möchte alle Dokumente dieser bestimmten Art unabhängig von den Produkten, mit denen das Dokument verbunden ist, finden.
  • Fig. 4 zeigt eine Beispieltabelle 150, welche in einer Verkäuferdatenbank 32 und/oder Datenspeicher 34 beinhaltet sein kann. Datenbank 32 und Datenspeicher 34 können eine oder mehrere Tabellen 150 umfassen, und jede Tabelle 150 kann Daten beinhalten, die sich auf ein oder mehrere Produkte beziehen. Beispielsweise beinhaltet die beispielhafte Tabelle 150 Daten in Bezug auf verschiedene Stiftarten. Tabelle 150 kann weiter Daten für andere Produktarten (z. B. andere Arten von Bürozubehör) beinhalten, oder solche Daten können in Tabellen 150 in Datenbank 32 und/oder Datenspeicher 34 beinhaltet sein. Tabelle 150 beinhaltet eine Mehrzahl von Spalten 152, die jeweils Daten beinhalten, die sich auf ein bestimmtes Produktattribut oder Verkäuferattribut beziehen. Obwohl eine beispielhafte Anzahl von Spalten 152, die beispielhafte Produktattributwerte und Verkäuferattributwerte beinhalten, dargestellt ist, wird darauf hingewiesen, dass jede geeignete Anzahl und Art von Produktattributen, Verkäuferattributen oder anderen Datenkategorien in Tabelle 150 enthalten sein kann. Weiter können, wie oben kurz beschrieben, Verkäuferdaten und Produktdaten in verschiedene Tabellen aufgeteilt werden anstatt in einer Tabelle integriert zu sein, wie in der beispielhaften Tabelle 150 dargestellt.
  • Tabelle 150 beinhaltet auch eine Anzahl von Zeilen 154, die jeweils einem bestimmten Produkt entsprechen können, und die jeweils Werte für ein oder mehrere Produktattribute oder Verkäuferattribute beinhaltet. Jeder der Werte (welche numerisch, Text oder in jedem anderen geeigneten Format sein können) ist an dem Schnittpunkt der Zeile 154 angeordnet, die mit einem bestimmten Produkt verbunden ist, und der Spalte 152, die ein bestimmtes Produktattribut oder Verkäuferattribut beinhaltet. Auf jeden dieser Schnittpunkte kann Bezug genommen werden als Feld oder Zelle 156 der Tabelle 150. Wenn Verkäuferdaten und Produktdaten eingefügt sind, kann jede Zeile 154 alle Produktdaten und Verkäuferdaten für das Produkt entsprechend dieser Zeile 154 beinhalten. Alternativ kann es eine Zeile oder einen Satz von Zeilen geben, die Verkäuferdaten zugehörig sind und die auf alle von einem Verkäufer 30 angebotenen Produkte oder auf einen Untersatz all solcher Produkte anwendbar sind. Wenn Verkäuferdaten und Produktdaten geteilt sind, kann jede Zeile in der Verkäuferdatentabelle einem Satz von Verkäuferattributwerten entsprechen, welches verknüpft sein kann mit einem Satz von einem oder mehreren Produkten in der Produktdatentabelle, so dass Verkäuferdaten für ein Produkt zugänglich sind, wenn auf Produktdaten für dieses Produkt zugegriffen wird und umgekehrt. Weiter können Dokumente als individuelle Dateien und/oder als Dateien in Tabellen gespeichert werden, wie beispielsweise Produkt- und Verkäuferdaten.
  • Die Daten in einer oder mehreren Spalten 152 der Tabelle 150 können in das Verzeichnis aufgenommen sein, um die Geschwindigkeit zu steigern, mit der Datenbankzugriffe durchgeführt werden können. Beispielsweise können die Felder 156 der Tintenfarbspalte 152d und der Spitzenbreitenspalte 152e indiziert sein, so dass eine Datenbankabfrage für einen Stift mit einer bestimmten Tintenfarbe und Spitzenbreite schnell durchgeführt werden kann. Die Daten in Tabelle 150 können unter Verwendung jeder geeigneten Datenbankindizierungstechnik indiziert werden. Das übliche Ergebnis einer solchen Aufnähme in ein Verzeichnis ist, dass, wenn GCD 42 oder ein Käufer 20 indizierte Daten aus einer Datenbank 32 und/oder Datenspeicher 34 anfordert, das verbundene Datenbank- Managementsystem (oder jede geeignete Schnittstelle zu Datenbank 32 und/oder Datenspeicher 34) nicht in jedem Feld 156 der Tabelle 150, das sich in Datenbank 32 und/oder Datenspeicher 34 befindet, suchen muss, um die angeforderten Daten zu finden. Statt dessen können die Daten so indiziert sein, dass, wenn eine Anfrage abgesetzt wird nach Produkten mit bestimmten Produktattributwerten und/oder Verkäufern 30 mit bestimmten Verkäuferattributwerten, die indiziert sind, das Datenbank-Managementsystem bereits den Ort von solchen Produkten in Tabelle 150 kennt und die mit diesem Produkt verbundenen Daten ohne Durchsuchen der gesamten Tabelle 150 oder Datenbank 32 und/oder Datenspeicher 34 für Produkte liefern kann. Wenn beispielsweise die Tintenfarbfelder 156 und Spitzenbreitenfelder 156 der Spalten 152d und 152e entsprechend indiziert sind, wird das Verzeichnis üblicherweise den Ort aller Produkte mit schwarzer Tinte und einer mittleren Spitzenbreite feststellen.
  • Wird eine Anfrage durchgeführt, die auch Werte einer oder mehrerer nicht indizierter Produktattribute spezifiziert (z. B. eine Anfrage nach Stiften, die von der ABC-Firma hergestellt werden, wenn die Herstellerfelder 156 der Spalte 152c nicht indiziert sind) und/oder Verkäuferattribute, dann kann das verbundene Datenbank-Managementsystem eine Suche in Datenbank 32 und/oder Datenspeicher 34 durchführen nach Produkten, die den spezifizierten Wert von einem oder mehreren nicht indizierten Attributen oder Verkäuferattributen einschließt. Eine solche Suche kann jedoch auf die bereits identifizierten Produkte begrenzt werden (unter Verwendung des Verzeichnisses), da sie spezielle Werte von verzeichneten Attributen (z. B. Stifte mit schwarzer Tinte und mittlerer Spitze) und/oder Verkäuferattributen beinhaltet, die ebenfalls in die Suche eingeschlossen sind. Demgemäß kann die erforderliche Zeit zum Durchführen einer solchen Suche reduziert werden, selbst dann, wenn eins oder mehrere der gesuchten Produktattributwerte oder Verkäuferattributwerte nicht indiziert sind.
  • Fig. 5 zeigt ein beispielhaftes e-commerce-System 10 genauer. Wie oben beschrieben, können zahlreiche Käufer 20 und Verkäufer 30 mit GCD-Server 40 unter Verwendung des Netzwerkes 12 verbunden werden. Käufer 20 können auf den GCD-Server 40 unter Verwendung eines Webbrowsers oder auf jede geeignete Art zugreifen, und GCD-Server 40 kann Käufer 20 mit einem Zugang zu GCD 42 unter Verwendung eines Webservers oder auf jede andere geeignete Art ausstatten. Obwohl GCD 42 bezüglich GCD-Server 40 als intern dargestellt ist, kann GCD 42 intern oder extern zu GCD-Server 40 sein, wie oben beschrieben. GCD-Server 40 kann auch Hardware und/oder Software zum Implementieren einer oder mehrerer GCD-Schnittstellen 43 beinhalten. Ein Käufer 20 kann auf GCD- Server 40 zugreifen und eine GCD-Schnittstelle 43 verwenden, um GCD 42, Verkäuferdatenbanken 32, Datenspeicher 34 und den verteilten Dokumentenspeicher 35 zu benutzen oder sich durch diese zu bewegen. Informationen können zwischen Käufern 20, Verkäufern 30 und GCD 42 übertragen werden unter Verwendung des hypertext transport protocol (HTTP; Protokoll zur Übertragung von Hypertext-Dokumenten(Webseiten)). Extensible markup language (XML; Dokumentenbeschreibungssprache), simple object access protocol (SOAP; Kommunikationsprotokoll zum Zugang zu einzelnen Projekten im Internet) oder jede andere geeignete Übertragungstechnik. Jedem Käufer 20 und Verkäufer 30 kann ein einzigartiger Identifizierer zugewiesen werden, so dass die Teilnehmer an einer Transaktion, welche durch GCD 42 vereinfacht wird, identifiziert werden können. Jedem Käufer 20 und Verkäufer 30 kann eine Rolle in Bezug auf die Transaktion zugewiesen werden. Wie oben beschrieben, kann ein Käufer 20 in einer Transaktion ein Verkäufer 30 in einer anderen Transaktion sein und umgekehrt.
  • In einer beispielhaften Suchtransaktion kann ein Käufer 20 auf eine GCD-Schnittstelle 43 zugreifen und eine Suche in GCD 42 durchführen. GCD-Schnittstelle 43 kann dem Käufer 20 ermöglichen, sich sowohl durch die Klassen von GCD 42 hindurchzubewegen oder zu "browsen", als auch eine Suche nach einer bestimmten Klasse oder nach bestimmten Klassen durchzuführen. Zum Beispiel kann Käufer 20 sich entweder durch GCD 42 Navigieren, um eine Klasse zu finden, in welcher Stifte kategorisiert sind, oder Käufer 20 kann GCD 42 nach Klassennamen durchsuchen, die das Wort "Stift" beinhalten. Jedes andere geeignete Verfahren zum Identifizieren einer bestimmten Klasse kann ebenfalls verwendet werden. Wenn Käufer 20 die geeignete Klasse für ein Produkt und/oder Dokument lokalisiert hat, die Käufer 20 wünscht, kann er dann eine Liste von Produkten und/oder Dokumenten in dieser Klasse anfordern, auf die bestimmte Produktattributwerte zutreffen. Durchsucht Käufer 20 beispielsweise die Filzstiftklasse 60b, kann Käufer 20 alle Produkte in Klasse 60b (Filzstifte) anfordern, die rote Tinte und eine feine Spitze haben, und die von einem Verkäufer 30 verkauft werden, der in den Vereinigten Staaten von Amerika ist.
  • Eine Suchschnittstelle 45 oder jede andere geeignete Komponente von GCD-Server 40 kann eine solche Anfrage vereinfachen durch Suchen oder Durchführen von Suchen in Datenspeicher 34 und/oder Verkäuferdatenbanken 32, die durch einen oder mehrere Zeiger mit Filzstiftklasse 60b wie oben beschrieben verbunden sind. Suchschnittstelle 45 kann Käufer 20 ein Suchformular bieten, in welchem ein oder mehrere Suchkriterien eingegeben werden. Die Arten von Suchkriterien, die verwendet werden können, können in dem Suchformular identifiziert werden, oder es kann Käufer 20 ermöglich werden, eine generelle Suche der Datenbanken 32 und/oder Datenspeicher 34 nach bestimmten Begriffen zu durchsuchen. Zum Beispiel kann Suchschnittstelle 45 Käufer 20 ein Suchformular bieten, das für eine Suche in Klasse 60b maßgeschneidert ist und Felder beinhaltet, in denen Käufer 20 eine gewünschte Tintenfarbe, Spitzendicke oder andere geeigneten produktbezogenen oder verkäuferbezogenen Kriterien spezifizieren kann. In einer Ausführungsform entsprechen die Felder des Suchformulars einigen oder allen Produktattributen innerhalb der Produktontologie und/oder Verkäuferattributen innerhalb der Verkäuferontologie entsprechend den ausgewählten Produktklassen, und Käufer 20 kann Werte eingeben für die Produktattribute und Verkäuferattribute in den entsprechenden Feldern des Suchformulars. Anstelle eines Suchformulars kann Suchschnittstelle 45 ein einzelnes Feld bieten, in dem Käufer 20 gewünschte Suchbegriffe wie beispielsweise "rot" und "fein" eingeben kann (mehrere Suchbegriffe können unter Verwendung von booleschen Operatoren oder jeder anderen geeigneten Technik eingegeben werden).
  • Suchschnittstelle 45 oder jede andere geeignete Komponente von GCD-Server 40 kann ebenfalls Suchanfragen erleichtern durch Zugriff auf ein Käuferprofil von Käufer 20, welches Informationen beinhaltet, die aus vorherigen Suchanfragen von Käufer 20 aus vorherigen e-commerce Transaktionen zusammengestellt wurden, in die Käufer 20 verwickelt war, oder aus anderen Ereignissen oder Aktionen von Seiten des Käufers 20. Beispielsweise kann ein Käuferprofil eine Liste von Verkäufern 30 beinhalten, auf die die Verkäuferattributwerte zutreffen, die Käufer 20 wünscht. Solch eine Liste kann zusammengestellt werden aus den Ergebnissen vorheriger Suchen von Käufer 20. Suchschnittstelle 45 kann auf das Profil für Käufer 20 zu jedem geeigneten Zweck zugreifen. In einer Ausführungsform kann Suchschnittstelle 45 auf das Profil für Käufer 20 zugreifen, um automatisch Suchkriterien für eine Suche zu erzeugen wie beispielsweise Produktattributwerte und/oder Verkäuferattributwerte. Suchschnittstelle 45 kann weiter auf das Profil für Käufer 20 zugreifen, um seine Suche nach Produkten, auf die bestimmte Produktattributwerte, die von Käufer 20 gegeben werden (oder automatisch erzeugt werden) zu begrenzen, auf Datenbanken 32, die mit Verkäufern 30 verbunden sind und von denen bekannt ist, dass auf sie die Verkäuferattributwerte, die Käufer 20 wünschen kann, zutreffen (und/oder Daten in Datenspeicher 34, die mit solchen Verkäufern 30 verbunden sind).
  • Basierend auf den von Käufer 20 gelieferten oder automatisch erzeugten Suchkriterien kann die Suchschnittstelle 45 eine Suchanfrage zu der/den geeigneten Verkäuferdatenbank(en) 32 und/oder Datenspeicher 34 übertragen, die anfordert, dass Datenbanken 32 und/oder Datenspeicher 34 jeweils eine Liste aller Produkte (beinhaltet auch verbundene Produktdaten und/oder Verkäuferdaten) ausgibt, auf die die Suchkriterien zutreffen. Datenbanken 32 und/oder Datenspeicher 34 können auch Daten liefern, die mit Attributwerten verbunden sind, die nicht in den Suchkriterien beinhaltet sind.
  • Beispielsweise können Datenbanken 32 einen Preis oder die Verfügbarkeit eines Produktes liefern, das auf die Suchkriterien zutrifft selbst dann, wenn Preis und Verfügbarkeit keine Suchkriterien waren. Das Ergebnis auf die Anfragen der Datenbanken 32 und/oder Datenspeicher 34 können dem Käufer 20 auf jede geeignete Art dargestellt werden. Beispielsweise können die Produkte aufgelistet werden in Bezug auf ihre Bedeutung bei den Suchkriterien gemäß jedem zutreffenden Trefferkriterium. Weiterhin kann GCD-Server 42 die Produktliste aufgrund einer Anfrage von Käufer 20 neu ordnen. Beispielsweise kann Käufer 20 anfordern, dass die Trefferprodukte von dem preiswertesten zu dem teuersten Produkt aufgelistet werden. Alternativ können die Suchergebisse von Datenbank 32 und/oder Datenspeicher 34 direkt zum Käufer 20 übertragen werden.
  • Käufer 20 kann ein Produkt aus der Produktliste auswählen, um anzuzeigen, dass er eine Transaktion bezüglich des Produktes beginnen möchte, wie beispielsweise den Kauf eines Produktes. Aufgrund einer solchen Auswahl überträgt GCD 42 ein repository identifier (RID; Datenspeicher-Identifizierungsmerkmal), welches den ausgewählten Verkäufer 30 identifiziert, und ein global eindeutiges Identifizierungsmerkmal (GUID; globally unique identifier) für das Produkt zu Käufer 20 überträgt. Zum Beispiel kann ein RID eine Netzwerkadresse (wie beispielsweise eine IP-Adresse) eines Verkäufernetzwerkknotens 30 sein oder verbunden sein mit einer Netzwerkadresse in einer Tabelle (in welchem Fall GCD 42 das RID verwenden kann, um die verbundene Netzwerkadresse nachzuschlagen und dann die Netzwerkadresse zu Käufer 20 zu übertragen). Käufer 20 kann auf Verkäufer 30 unter Verwendung des RID (oder der Netzwerkadresse) zugreifen und eine Transaktion bezüglich des Produktes unter Verwendung der GUID anfordern. GCD 42 kann sogar einen Link liefern, der die URL einer Webseite verbunden mit dem Verkäufer 30 beinhaltet, oder kann jedes andere geeignete Verfahren verwenden, um Käufer 20 mit Verkäufer 30 zu verbinden. Obwohl nur ein einzelner beispielhafter Pfeil (zwischen Käufer 20n und Verkäufer 30n) dargestellt ist, um die Verbindung zwischen Käufern 20 und Verkäufern 30 darzustellen, wird darauf hingewiesen, dass jeder Käufer 20 mit jedem Verkäufer 30 kommunizieren kann, um geeignete Transaktionen durchzuführen.
  • Das beispielhafte e-commerce System 10 beinhaltet weiter einen Sicherheitsmodul 41 und ein Intelligenzmodul 47. Obwohl Sicherheitsmodul 41 und Intelligenzmodul 47 als interner Teil von GCD-Server 40 dargestellt sind, können das Sicherheitsmodul 41 und das Intelligenzmodul 47 intern oder extern von GCD-Server 40 sein. Wie oben beschrieben ist das System 10 fähig zum Speichern und Klassifizieren von Standarddokumenten und einzelnen Dokumenten. Zum Beispiel beendet Käufer 20a eine Transaktion mit Verkäufer 30a, wobei die Verwendung eines oder mehrerer Dokumente erforderlich ist. System 10 kann die Dokumente, die in der Transaktion verwendet wurden, nehmen und sie entweder in dem verteilten Dokumentenspeicher 35 oder in Verkäuferdatenbanken 32 speichern abhängig davon, ob die Dokumente Standarddokumente oder einzelne Dokumente wie oben definiert sind. Angenommen, die vervollständigte Transaktion zwischen Käufer 20 und Verkäufer 30a beinhaltet die Verwendung eines Standarddokumentes und eines einzelnen Dokumentes. GCD-Server 40 analysiert die Dokumente um zu entscheiden, ob die Dokumente Standarddokumente oder einzelne Dokumente sind. GCD-Server 40 speichert das Standarddokument im verteilten Dokumentenspeicher 35 und speichert das einzelne Dokument in der Verkäuferdatenbank 32, die mit Verkäufer 30a verbunden ist.
  • Die Standarddokumente und einzelnen Dokumente können vertrauliche oder wettbewerbsbezogene Informationen beinhalten einschließlich - aber nicht begrenzt auf - der Namen des Käufers 20 und Verkäufers 30, die in die Transaktion verwickelt sind, des gekauften Produktes, der gekauften Menge und des Kaufpreises. Da die Dokumente im verteilten Dokumentenspeicher 35 und in Verkäuferdatenbanken 32 gespeichert sind, sind die Dokumente anderen Käufern 20 und Verkäufern 30 über GCD 42 zugänglich, und die vertrauliche Information von Käufer 20 und Verkäufer 30 muss geschützt werden, bevor die Dokumente anderen Käufern 20 und Verkäufern 30 frei zugänglich werden. Demgemäß verschlüsselt Sicherheitsmodul 41 die Standarddokumente und die einzelnen Dokumente (oder Abschnitte der Dokumente wie nachfolgend beschrieben), wenn die Dokumente in dem verteilten Dokumentenspeicher 35 und den Verkäuferdatenbanken 32 gespeichert werden. Den Käufern 20 und Verkäufern 30, mit denen die Dokumente verbunden sind, wird die erforderliche Erlaubnisebene zum Entschlüsseln der Dokumente zugewiesen, so dass die verbundenen Käufer 20 und Verkäufer 30 die gesamten Dokumente mit der vertraulichen Information betrachten können. Dadurch wird einem Käufer 20 die Möglichkeit gegeben, GCD 42 zum Durchsuchen und Ansehen aller Dokumente zu verwenden, in denen Käufer 20 eine Partei war, was demzufolge ein Dokumentenspeicher- und Wiederansehelement zu dem e-commerce Transaktionssystem 10 hinzufügt. Auf die käufereigenen oder verkäufereigenen Dokumente (wenn ein Käufer oder Verkäufer Partei zu einem Dokument ist) kann als Benutzerdokument Bezug genommen werden. Ein Käufer 20 oder Verkäufer 30 hat üblicherweise vollen Zugriff auf seine verbundenen Benutzerdokumente. Beispielsweise sind die eigenen Dokumente von Käufer 20a für ihn Benutzerdokumente und Käufer 20a hat vollen Zugriff auf alle seine Benutzerdokumente, da Käufer 20a eine Partei von allen Transaktionen ist, aus denen die Dokumente hervorgegangen sind. Die Benutzerdokumente von Käufer 20a sind Drittparteidokumente für alle anderen Käufer 20, da alle anderen Käufer 20 keine Partei der Transaktion von Käufer 20a waren. Dementsprechend hat jeder Käufer 20 seine eigenen Benutzerdokumente von Transaktionen, bei denen er Partei war, und für die Käufer 20 die erforderliche Erlaubnisebene zum Zugriff auf die Benutzerdokumente besitzt. Wenn aber ein Käufer 20 nicht Partei einer Transaktion ist, werden alle Dokumente, die aus dieser Transaktion hervorgehen, für diesen Käufer 20 Drittparteidokumente und ein Käufer 20 hat nicht die Erlaubnis, ein Drittparteidokument komplett anzusehen oder darauf zuzugreifen.
  • Sind die Dokumente in dem verteilten Dokumentenspeicher 35 und/oder Verkäuferdatenbanken 32 gespeichert und verschlüsselt (ganz oder in Teilen), kategorisiert GCD-Server 40 oder jede andere geeignete Komponente die Dokumente innerhalb GCD 42 sowohl für Dokumentklassen als auch für Produktklassen, wie in Fig. 2 und 3 beschrieben. Die Klassifikation der Dokumente innerhalb der Dokument- und Produktklassen erleichtert das Wiederfinden der Dokumente zu einem späteren Zeitpunkt durch Käufer 20 und Verkäufer 30. GCD-Server 40 untersucht die Dokumente, um die Dokumentart zu bestimmen und um zu bestimmen, mit welchen Produkten das Dokument verbunden ist. GCD-Server 40 verbindet Zeiger mit den Dokumenten und GCD 42, so dass GCD 42 die Dokumente in dem geteilte Dokumentenspeicher 35 und Verkäuferdatenbanken 32 lokalisieren kann, wenn Käufer 20 eine Suche nach Dokumenten durchführt. Zum Beispiel kann das Bestellformular eines Käufers für Kugelschreiber verbunden werden mit Kugelschreiberdokumentenklasse 63c innerhalb der Kugelschreiberklasse 60c der Verzeichnisstruktur 44, Käuferbestelldokumentenklasse 82b der Verzeichnisstruktur 70 und Bestelldokumentenklasse 86b der Verzeichnisstruktur 70.
  • Die Möglichkeit für Käufer 20, die Benutzerdokumente anzusehen, steigert die Funktionalität von System 10 und fügt ein Dokumentenspeicher- und Wiederverwertungselement zu System 10 hinzu. Es muss jedoch einen Weg für Käufer 20 geben, Benutzerdokumente zu speichern, darauf zuzugreifen und diese anzusehen, während vor anderen Käufern 20 die vertrauliche oder wettbewerbsbezogene Information, die in den Benutzerdokumenten enthalten ist, versteckt wird. Wenn Käufer 20 versucht, auf Benutzerdokumente zuzugreifen oder diese anzusehen, bestimmt Sicherheitsmodul 41, ob Käufer 20 die erforderliche Erlaubnisebene hat, um Benutzerdokumente anzusehen. In einer Ausführungsform kann Sicherheitsmodul 41, wenn es die Dokumente verschlüsselt, jedes Dokument durch Passwörter schützen und das korrekte Passwort anfordern, um die Dokumente zu entschlüsseln. Wenn Käufer 20 eine Anfrage startet, um auf Benutzerdokumente zuzugreifen, fragt Sicherheitsmodul 41 Käufer 20 nach dem korrekten Passwort für die Entschlüsselung. Da die Dokumente die Benutzerdokumente von Käufer 20 sind, wird Käufer 20 die erforderliche Erlaubnisebene und das korrekte Passwort haben. Gibt Käufer 20 das korrekte Passwort ein, hat er vollen Zugriff auf die kompletten Benutzerdokumente. Hat Käufer 20 einmal vollen Zugriff, kann er die Benutzerdokumente nach vorhergehenden Kaufzusammenfassungen untersuchen zur Unterstützung bei zukünftigen Bestellungen oder bei Wiederverwertungen und Modifizierungen der Benutzerdokumente für gegenwärtige Transaktionen.
  • Entscheidet sich Käufer 20, ein Benutzerdokument für eine laufende Transaktion wiederzuverwenden, hat er mehrere Optionen. War Käufer 20 mit dem Produkt und dem Verkäufer einer vorhergehenden Transaktion zufrieden, kann Käufer 20 das Intelligenzmodul 47 anweisen, die gleiche Bestellung zu dem gleichen Verkäufer auszugeben unter Verwendung des Dokumentes aus der vorhergehenden Transaktion. Intelligenzmodul 47 kann bestimmen, welche Abschnitte in dem Benutzerdokument allgemein sind und welche sich speziell auf die vorhergehende Transaktion beziehen und kann automatisch einige Abschnitte des Dokumentes auf den neuesten Stand bringen, die dieses erfordern (wie beispielsweise den Datumsabschnitt). Ist es auf den neuesten Stand gebracht, wird das Dokument an den Verkäufer gesendet und die Transaktion ist vervollständigt. Wen Käufer 20 mit dem Verkäufer aus der vorhergehenden Transaktion nicht zufrieden war, kann Käufer 20 das Benutzerdokument aus der vorhergehenden Transaktion verwenden, muss aber das Intelligenzmodul 47 instruieren, die Verkäuferinformationen zu ändern, allgemeine Abschnitte, die dieses erfordern, auf den neuesten Stand zu bringen und das Benutzerdokument an den neuen Verkäufer auszugeben. Das Wiederausgeben von Dokumenten ermöglicht Käufer 20, Bestellungen zu beschleunigen und demgemäss Transaktionen, da Käufer 20 keine Zeit damit verschwenden muss, Informationen in Dokumente wieder einzugeben.
  • Das Aufweisen nur eines Käufers 20, der in der Lage ist, auf Benutzerdokumente zuzugreifen, begrenzt die Funktionalität und den Nutzen von System 10 und verhindert es, einen dem System 10 nicht bekannten Käufer 20 von der Dokumentenspeicher- und Wiederverwendungsfunktion Nutzen zu ziehen, da dieser Käufer 20 keine Benutzerdokumente zum Wiederverwenden hätte. Demgemäss ist es wünschenswert, einen Weg für Käufer 20 und Verkäufer 30 zu schaffen, auf Drittparteidokumente zuzugreifen und diese zu verwenden, während die vertrauliche Information in den Dokumenten geschützt wird. Intelligenzmodul 47 ermöglicht Käufern 20 und Verkäufern 30, auf Drittparteidokumente zuzugreifen und diese wiederzuverwenden, während vertrauliche und wettbewerbsbezogene Informationen in den Drittparteidokumenten geschützt ist. Intelligenzmodul 47 nimmt die Drittparteidokumente und teilt diese Drittparteidokumente in einen oder mehrere Abschnitte ein, um allgemeine Dokumente aus den Drittparteidokumenten zu erstellen. Die allgemeinen Dokumente ermöglichen Käufer 20, begrenzten Zugang auf Drittparteidokumente zu haben. Beim Erstellen der allgemeinen Dokumente untersucht Intelligenzmodul 47 ein Drittparteidokument und entfernt oder verschlüsselt Informationen aus den Abschnitten, die vertrauliche Informationen beinhalten und aus den Abschnitten, die sich auf bestimmte Transaktionen beziehen.
  • Angenommen, Käufer 20b möchte beispielsweise blaue Tintenkugelschreiber kaufen und führt unter Verwendung von GCD 42 eine Suche nach Dokumenten durch, die mit blauen Tintenkugelschreibern verbunden sind. Die Suche kann mehrere Dokumente liefern, die diese Suchkriterien erfüllen, von denen eines ein Dokument der Transaktion zwischen Käufer 20a und Verkäufer 30a ist. Käufer 20b wird nicht sehen können, dass dieses Dokument zwischen Käufer 20a und Verkäufer 30a ist, aber wird statt dessen sehen, dass dieses Dokument ein Drittparteidokument ist. Käufer 20b wird die Identität von Käufer 20a und Verkäufer 30a nicht kennen. Für Käufer 20b ist dies ein Drittparteidokument, da Käufer 20b nicht Partei an der Transaktion war. Käufer 20b wird nicht wissen, dass die Transaktion zwischen Käufer 20a und Verkäufer 30a stattgefunden hat, sondern nur, dass es ein Drittparteidokument zwischen einem Käufer und einem Verkäufer war, von denen Käufer 20b keine Partei ist.
  • Intelligenzmodul 47 kann Drittparteidokumente in Abschnitte teilen wie Kopf, Fuß, Kontaktinformationen für Käufer, Kontaktinformationen für Verkäufer, Datum, Bestellmenge, Kaufpreis, Gegenstand, Beschreibungen, Bedingungen und Konditionen und alle anderen geeigneten Abschnitte. Intelligenzmodul 47 kann bestimmen, welche Abschnitte allgemein sind und welche Abschnitte sich speziell auf die Transaktion zwischen Käufer 20a und Verkäufer 30a beziehen, Käufer 20a und/oder Verkäufer 30a können die generischen Abschnitte identifizieren, oder die generischen Abschnitte können auf jede andere Art identifiziert werden. Um das allgemeine Dokument zu erstellen, entfernt Intelligenzmodul 47 aus dem Drittparteidokument die Informationen in den Abschnitten, die sich speziell auf die Transaktion zwischen Käufer 20a und Verkäufer 30a beziehen und die vertraulich ist für entweder Käufer 20a oder Verkäufer 30a, und lässt die Information in den allgemeinen Abschnitten der Transaktion stehen. Zum Beispiel kann Intelligenzmodul 47 beim Erstellen des allgemeinen Dokumentes den Namen und die Kontaktinformation für Käufer 20a und Verkäufer 30a entfernen, die Bestellmenge und den Kaufpreis, aber lässt diese Abschnitte in dem allgemeinen Dokument stehen, so dass Käufer 20b diese mit eigenen Informationen ausfüllen kann. Intelligenzmodul 47 lässt im allgemeinen Dokument die Abschnitte und Informationen für Kopf, Fuß, Beschreibung des Produktes und den Bedingungen und Konditionen stehen. Als Alternative zum Entfernen vertraulicher Informationen kann Intelligenzmodul 47 solche Informationen verschlüsseln. Intelligenzmodul 47 kann auch dynamisch den Datumsabschnitt in dem allgemeinen Dokument mit der aktuellen Datumsinformation auf den neuesten Stand bringen. Intelligenzmodul 47 kann weiter automatisch und dynamisch das allgemeine Dokument mit anderer aktueller Information auf den neuesten Stand bringen wie beispielsweise dem Käufer- und Verkäufernamen und Kontaktinformationen, wenn Käufer 20b ein registrierter Benutzer des Systems 10 ist und solche Information dem Intelligenzmodul 47 verfügbar ist. Um das allgemeine Dokument zu vervollständigen, können Käufer 20b oder Verkäufer 30 manuell Informationen in das allgemeine Dokument eingeben wie die gewünschte Menge und Kaufpreis. Ist das allgemeine Dokument vervollständigt, kann Käufer 20b das Dokument zum Beenden der Transaktion verwenden.
  • In nachfolgenden Transaktionen kann Käufer 20 wünschen wollen, nach bestimmten Dokumenten zu suchen. Käufer 20 kann auf GCD-Schnittstelle 43 zugreifen und eine Suche in dem verteilten Dokumentenspeicher 35 und/oder einer oder mehreren Verkäuferdatenbanken 32 unter Verwendung von GCD 42 durchführen. GCD-Schnittstelle 43 kann dem Käufer 20 ermöglichen, sich sowohl durch die Produktklassen als auch durch die Dokumentklassen von GCD 42 hindurchzubewegen oder zu "browsen" und nach einer speziellen Klasse oder Klassen zu suchen. Zum Beispiel kann Käufer 20 sich entweder durch Produktklassen von GCD 42 Navigieren um Dokumente zu finden, die mit einem bestimmten Produkt verbunden sind, oder Käufer 20 kann Dokumentklassen des GCD 42 nach einer bestimmten Dokumentart durchsuchen. Jedes andere geeignete Verfahren zum Identifizieren eines Dokumentes kann ebenfalls verwendet werden. Hat Käufer 20 die entsprechende Klasse für das gewünschte Dokument lokalisiert, kann Käufer 20 eine Liste von. Dokumenten in dieser Klasse anfordern, auf die bestimmte Produkt- und/oder Dokumentattributwerte zutreffen. Käufer 20 hat vollen Zugriff auf alle Benutzerdokumente und begrenzten Zugriff auf Drittparteidokumente (als allgemeine Dokumente). Käufer 20 kann Suchschnittstelle 45 verwenden zum Suchen nach Dokumenten auf die gleiche Art wie oben für Produkte beschrieben.
  • Eine Suchschnittstelle 45 oder jede andere geeignete Komponente von GCD-Server 40 kann eine solche Anfrage erleichtern durch Suchen oder durch Anfordern einer Suche des geteilten Dokumentenspeichers 35 und/oder Verkäuferdatenbanken 32, identifiziert durch einen oder mehrere Zeiger verbunden mit den Dokumenten wie oben beschrieben. Suchschnittstelle 45 kann Käufer 20 ein Suchformular liefern, in welches ein oder mehrere Suchkriterien für die gewünschten Dokumente eingegeben werden. Die Arten von Suchkriterien, die verwendet werden können, können in dem Suchformular identifiziert werden, oder Käufer 20 ist es erlaubt, eine allgemeine Suche der Verkäuferdatenbanken 32 und dem verteilten Dokumentenspeicher 35 für bestimmte Begriffen durchzuführen. Beispielsweise kann die Suchschnittstelle 45 dem Käufer 20 ein Suchformular liefern, das auf die Klasse 82c zugeschnitten ist und Felder beinhaltet, in denen Käufer 20 die gewünschten dokumentbezogenen Kriterien spezifizieren kann. An Stelle eines Suchformulars kann Schnittstelle 45 ein einzelnes Feld bereitstellen, in das der Käufer die gewünschten Suchbegriffe wie beispielsweise "Aufforderung zur Angebotsabgabe" und "Kugelschreiber" eingeben kann (vielfache Suchbedingungen können eingegeben werden unter Verwendung von Booleschen Operatoren und anderen geeigneten Techniken).
  • Basierend auf den von Käufer 20 gelieferten oder automatisch erzeugten Suchkriterien kann die Suchschnittstelle 45 eine Anfrage zu der/den geeigneten Verkäuferdatenbank(en) 32 und/oder dem verteilten Dokumentenspeicher 35 übermitteln mit der Anforderung, dass Datenbanken 32 und geteilter Dokumentenspeicher 35 jeweils eine Liste aller Dokumente zurückschicken, auf die die Suchkriterien zutreffen. Die Antworten auf die Anfrage von Datenbanken 32 und dem verteilten Dokumentenspeicher 35 können dem Käufer 20 auf jede geeignete Art angezeigt werden. Beispielsweise können die Dokumente aufgelistet werden gemäß der Bedeutung entsprechend den Suchkriterien gemäß jedem geeigneten Trefferkriterium. Weiterhin kann GCD 42 die Dokumentliste basierend auf einer Anfrage von Käufer 20 neu ordnen. Beispielsweise kann Käufer 20 fordern, dass die Trefferdokumente in der Reihenfolge Benutzerdokumente und danach Drittparteidokumente oder zuerst Standarddokumente gefolgt von einzelnen Dokumenten aufgelistet werden. Alternativ können die Suchergebnisse von Verkäuferdatenbanken 32 und dem verteilten Dokumentenspeicher 35 direkt zu Käufer 20 übermittelt werden.
  • Käufer 20 kann ein Dokument aus der Dokumentenliste auswählen und ansehen, um den Wunsch, das Dokument in einer Transaktion zu verwenden, anzuzeigen. Ist das Dokument ein Benutzerdokument, muss Käufer 20 die erforderliche Erlaubnisebene zum Entschlüsseln und Ansehen der kompletten Dokumente besitzen und kann die Dokumente dann zum Gebrauch in der aktuellen Transaktion modifizieren. Ist das Dokument ein Drittparteidokument, sieht Käufer 20 das allgemeine Dokument, das aus dem Drittparteidokument erzeugt wurde oder sieht die unverschlüsselten Abschnitte des Drittparteidokumentes ohne Zugriff auf die vertrauliche Information in dem Drittparteidokument. Käufer 20 kann das Dokument dann vervollständigen oder auf den neuesten Stand bringen und die Transaktion abschließen.
  • Fig. 6A & 6B zeigen ein beispielhaftes Verfahren zum Speichen, Klassifizieren und Wiederverwenden von Dokumenten unter Verwendung von GCD 42. Das Verfahren beginnt bei Schritt 102, wenn Sicherheitsmodul 41 das Dokument verschlüsselt, um den Zugriff zu den Dokumenten zu kontrollieren, jede vertrauliche oder wettbewerbsbezogene Information, die in dem Dokument enthalten ist, schützt und demgemäss einem Käufer 20, der nicht Partei der Transaktion war, aus dem das Dokument hervorgegangen ist, nicht erlaubt, auf die vertrauliche Information in dem Dokument zuzugreifen oder diese anzusehen. Wenn die Dokumente verschlüsselt sind, wird jedem verschlüsselten Dokument eine Erlaubnisebene zugewiesen, so dass, wenn ein Käufer 20 die erforderliche Erlaubnisebene hat, dieser Käufer 20 das Dokument entschlüsseln und das komplette Dokument ansehen kann. Einem Käufer 20 wird die erforderliche Erlaubnisebene für alle Dokumente gegeben, in welchen er eine Partei der Transaktion war, in die das Dokument verwickelt ist. Dementsprechend wird ein Käufer 20 die erforderliche Erlaubnisebene zum Zugreifen und Ansehen der kompletten Benutzerdokumente von diesem Käufer 20 haben. GCD-Server 40 speichert die Dokumente in einem oder mehreren Dokumentenspeichern bei Schritt 104. Beispielsweise kann GCD-Server 40 die Standarddokumente im verteilten Dokumentenspeicher 35 speichern und die einzelnen Dokumente in einer oder mehreren Verkäuferdatenbanken 32. Zusätzlich können ein Käufer 20 oder Verkäufer 30 nur Standarddokumente benutzen, nur einzelne Dokumente benutzen, oder das Dokument kann als solches nicht differenziert werden und wird nur als Dokument abgespeichert.
  • Bei Schritt 106 verbindet und kategorisiert GCD-Server 40 die Dokumente in einer Vielzahl von Produktklassen. Klassifizieren der Dokumente in Produktklassen ermöglicht Käufer 20 nach Dokumenten zu suchen oder Dokumente zu lokalisieren, die mit bestimmten Produkten verbunden sind, oder Dokumente für ein bestimmtes Produkt zu lokalisieren, wenn Käufer 20 nach einem bestimmten Produkt sucht. Käufer 20 kann sich durch GCD 42 bewegen zum Suchen eines bestimmten Produktes und, sobald das Produkt lokalisiert ist, nach Dokumenten suchen, die mit diesem Produkt verbunden sind, sie lokalisieren und ansehen. GCD-Server 40 kann beispielsweise ein Bestelldokument für Filzstifte in der Filzstiftedokumentenklasse 63b und der Stiftedokumentenklasse 59 klassifizieren und verbinden. Will Käufer 20 Filzstifte kaufen, wird er schnell Dokumente in Bezug auf Filzstifte finden.
  • In Schritt 108 verknüpft und kategorisiert GCD-Server 40 die Dokumente mit einer Vielzahl von Dokumentenklassen. Klassifizieren der Dokumente in Dokumentenklassen ermöglicht Käufer 20 nur nach Dokumenten zu suchen, unabhängig von einem Bezug zu speziellen Produkten. Beispielsweise kann GCD-Server 40 die Bestellung für Filzstifte, die aus der Sicht des Käufers erstellt wurden, mit der Käuferbestelldokumentenklasse 82b sowie der Bestelldokumentenklasse 86b verbinden und klassifizieren. Dies ermöglicht Käufer 20, nach Dokumenten allein aufgrund der Dokumentart zu suchen und diese zu lokalisieren anstelle des Lokalisierens eines Dokumentes basierend darauf, mit welchem Produkt das Dokument verbunden ist. Das Klassifizieren der Standarddokumente und der einzelnen Dokumente in Produktklassen und Dokumentklassen in Schritten 106 und 108 beinhaltet das Verbinden von Zeigern mit den Klassen innerhalb GCD 42, wo die Zeiger gespeicherte Dokumente im verteilten Dokumentenspeicher 35 und Verkäuferdatenbanken 32 identifizieren und wo die Zeiger den Käufer 20 zu den gewünschten Dokumenten führen. Zusätzlich kann, abhängig davon, wie die Dokumente gespeichert und kategorisiert werden, nur Schritt 106 oder nur Schritt 108 ausgeführt werden.
  • Nachdem die Dokumente gespeichert und kategorisiert sind, geht das Verfahren bei Schritt 110 weiter, wo Käufer 20 auf GCD 42 zugreift unter Verwendung der GCD-Schnittstelle 43 zum Suchen bestimmter Dokumente. Wie oben beschrieben können Käufer 20 auf GCD 42 unter Verwendung eines Webbrowsers oder auf jede andere Art zugreifen. Bei Schritt 112 bewegt sich Käufer 20 durch die Verzeichnisstruktur 44 oder 70 zu einer Produkt- oder Dokumentenklasse oder durchsucht Verzeichnisstruktur 44 oder 70 nach einer Produkt- oder Dokumentenklasse, die für Käufer 20 speziell genug ist (und/oder einer Klasse, die am Ende eines Zweiges ist), wie oben beschrieben. Bei Schritt 114 sucht Käufer 20 eine gewünschte Klasse aus. Wenn eine Klasse ausgewählt wurde, ist Käufer 20 bei Schritt 116 aufgefordert, Suchkriterien für ein bestimmtes Produkt und/oder ein gewünschtes Dokument einzugeben. Beispielsweise kann, wie oben beschrieben, GCD-Server 40 einem Käufer 20 ein Suchformular liefern, in welches ein oder mehrere Suchkriterien eingegeben werden, oder ein einzelnes Feld, in das Käufer 20 die gewünschten Suchkriterien eingibt. Käufer 20 kann eine Suche nach einem speziellen Produkt starten und hat immer noch die Möglichkeit, Dokumente zurückzuholen, die mit diesem speziellen Produkt verbunden sind. Demgemäss muss Käufer 20 nicht speziell nach Dokumenten suchen. Ist Käufer 20 beispielsweise an Stiften interessiert, kann er die Produktklassen für Stifte durchsuchen und GCD-Server 40 oder jede andere geeignete Komponente kann auch Dokumente in Verbindung zu Stiften aus den Dokumentklassen für Stifte zurückholen. Die verbundenen Dokumente können Käufer 20 dargestellt werden, nachdem Käufer 20 ein spezielles Produkt ausgesucht hat und danach gesucht hat.
  • Unter Verwendung der Suchkriterien, die von Käufer 20 geliefert oder auf andere Art erzeugt wurden, sucht Suchschnittstelle 45 bei Schritt 118 nach Dokumenten, auf die die Suchkriterien zutreffen, in dem verteilten Dokumentenspeicher 35 und/oder einer oder mehreren Verkäuferdatenbanken 32, die durch Zeiger in der von Käufer 20 ausgewählten Klasse identifiziert werden. Suchschnittstelle 45 kann die Suche auf jede geeignete Art durchführen. Zum Beispiel kann, basierend auf einem mit einer Klasse verbundenen Zeiger, GCD-Server 40 zuerst im verteilten Dokumentenspeicher 35 oder einem Abschnitt des geteilten Dokumentenspeichers 35 (welcher durch den Zeiger identifiziert wird) nach Standarddokumenten suchen, auf die die Suchkriterien zutreffen und kann dann eine oder mehrere Verkäuferdatenbanken 32 (die durch denselben Zeiger oder einen verbundenen Zeiger identifiziert werden) nach einzelnen Dokumenten durchsuchen. Beispielsweise kann das Standarddokument in dem verteilten Dokumentenspeicher 35 einen verbundenen Zeiger zu jeder Verkäuferdatenbank 32 haben und einzelne Dokumente liefern zur weiteren Erklärung oder Weiterführung des Standarddokumentes. Alternativ kann diese Suche umgekehrt durchgeführt werden oder unter Verwendung jeder geeigneten anderen Technik. Eine Liste der sich ergebenden Standard- und/oder einzelnen Dokumente, die aus dem verteilten Dokumentenspeicher 35 und/oder Verkäuferdatenbanken 32 erhalten werden, kann verbunden werden und dem Käufer 20 als eine einheitliche Menge von Suchergebnissen präsentiert werden. Bei Schritt 120 präsentiert GCD-Server 40 dem Käufer 20 die Suchergebnisse einschließlich der Liste aus einem oder mehreren Dokumenten, auf die die Suchkriterien zutreffen (oder teilweise zutreffen).
  • Nachdem GCD-Server 40 die auf die Suche zutreffenden Dokumente präsentiert, untersucht Käufer 20 bei Schritt 122 die Ergebnisse und wählt ein Dokument aus den Suchergebnissen aus. Wählt Käufer 20 ein Drittparteidokument aus, hat Käufer 20 nicht die erforderliche Erlaubnisebene zum Entschlüsseln des Drittparteidokumentes. Demgemäss erzeugt Intelligenzmodul 47 zum Schutz der vertraulichen Information in dem Drittparteidokument ein allgemeines Dokument aus dem Drittparteidokument bei Schritt 124, so dass Käufer 20 die allgemeine Dokumentenversion des ausgewählten Drittparteidokumentes ansehen und modifizieren kann. Das Erzeugen des allgemeinen Dokumentes beinhaltet zuerst das Teilen des Drittparteidokumentes in Abschnitte. Einmal in Abschnitte unterteilt, untersucht Intelligenzmodul 47 die Abschnitte des Drittparteidokumentes um zu entscheiden, welche Abschnitte allgemein und welche Abschnitte zu einer bestimmten vorhergehenden Transaktion gehörend sind, und welche Abschnitte vertrauliche Informationen beinhalten. Allgemeine Abschnitte können beinhalten, aber sind nicht begrenzt auf, Kopf, Fuß, Datum, Produktart und Produktbeschreibung. Diese Abschnitte werden als allgemein betrachtet, da sie im allgemeinen in allen Dokumenten dieser Art enthalten sein müssen und weiter keine vertrauliche oder wettbewerbsbezogene Information verbunden mit dem Käufer und Verkäufer beinhalten, die Partei zu dem Dokument waren. Abschnitte, die als speziell zu einer bestimmten Transaktion und/oder als vertraulich betrachtet werden, beinhalten, aber sind nicht begrenzt auf, Käufername, Verkäufername, Kaufmenge und Kaufpreis des Produktes. Diese Abschnitte sind als speziell zu einer besonderen Transaktion und/oder vertraulich zu betrachten, da ein Käufer nicht möchte, dass andere Käufer 20 wissen, von . welchen Verkäufern 30 er kauft, welche Produkte er kauft, wie viel er kauft und wie viel er für die Produkte bezahlt.
  • Intelligenzmodul 47 kann die Information aus den Abschnitten entfernen, die speziell zu einer besonderen Transaktion gehören und kann die Information in den allgemeinen Abschnitten weiter übermitteln. Intelligenzmodul 47 kann die Abschnitte, die zu einer speziellen Transaktion gehören, weiter übermitteln, aber diese Abschnitte frei lassen, so dass Käufer 20 sie mit seinen Informationen ausfüllen kann. Bei Schritt 126 passt Intelligenzmodul 47 automatisch die generischen Abschnitte mit aktuellen Informationen an, wie beispielsweise Datum, Name und Kontaktinformation für Käufer 20. Das dynamische Anpassen der allgemeinen Dokumente räumt die Notwendigkeit für Käufer 20 aus, das aktuelle Datum und den Namen oder Kontaktinformationen über ihn einzugeben. Dementsprechend kann Käufer 20 die Transaktionen schneller vervollständigen mit weniger Aufwand beim Ausfüllen des allgemeinen Dokumentes. Alternativ kann Käufer 20 das Drittparteidokument erhalten, in dem die gesamte vertrauliche Information gelöscht ist, welches aber nicht auf den neuesten Stand gebracht wurde, und demgemäss kann Käufer 20 das Dokument auf den neuesten Stand bringen und vervollständigen. Ist das allgemeine Dokument dynamisch auf den neuesten Stand gebracht und die vertrauliche Information entfernt, sieht Käufer 20 bei Schritt 128 das allgemeine Dokument und vervollständigt es durch Hinzufügen solcher Informationen wie der gewünschten Menge und dem Kaufpreis. Ist das allgemeine Dokument vervollständigt, kann Käufer 20 das Dokument in einer Transaktion verwenden. GCD-Server 40 speichert das Dokument entweder als Standarddokument oder als einzelnes Dokument bei Schritt 130, so dass andere Käufer 20 das Dokument zukünftig verwenden können, und das modifizierte allgemeine Dokument wird ein Benutzerdokument für den Käufer.
  • Wenn Käufer 20 bei Schritt 122 ein Benutzerdokument auswählt, sollte Käufer 20 die erforderliche Erlaubnisebene zum Entschlüsseln des Benutzerdokumentes haben, da ein Benutzerdokument per Definition das eigene Dokument von Käufer 20 ist und demgemäss Käufer 20 die erforderliche Erlaubnisebene hat. Bei Schritt 132 erhält Sicherheitsmodul 41 das erforderliche Entschlüsselungspasswort oder andere Information von Käufer 20 und entschlüsselt das Dokument. Bei Schritt 134 entscheidet Käufer 20, ob er das Benutzerdokument für eine aktuelle Transaktion neu ausgeben möchte oder ob er das Benutzerdokument nur ansehen möchte. Wenn Käufer 20 entscheidet, das Benutzerdokument anzusehen, dann sieht Käufer 20 bei Schritt 136 das Benutzerdokument aus einer vorhergehenden Transaktion. Käufer 20 wird üblicherweise ein Benutzerdokument ansehen, um Informationen über vorhergehende Transaktionen zu sammeln, um die Bestellentwicklung zu studieren, um über den Zeitpunkt der nächsten Transaktion zu entscheiden, oder aus jedem anderen geeigneten Grund zum Ansehen eines Benutzerdokumentes. Beim Ansehen des Benutzerdokumentes kann Käufer 20 sehen, wann die vorhergehenden Bestellungen platziert wurden, welches die Bedingungen und Konditionen der vorhergehenden Bestellungen waren und wann die ideale Zeit zum Einleiten einer nächsten Transaktion ist.
  • Entscheidet Käufer 20 bei Schritt 134, das Benutzerdokument für eine neue Transaktion auszugeben, dann gibt Intelligenzmodul 47 bei Schritt 138 das Benutzerdokument aus, welches mit aktueller Information wie beispielsweise dem Datum auf den neuesten Stand gebracht wurde. Beim Wiederausgeben des Benutzerdokumentes kann Intelligenzmodul 47 bestimmen, welche Abschnitte des Dokumentes allgemein und welche zu der vorausgegangenen Transaktion speziell sind. Intelligenzmodul 47 kann weiter das wiederausgegebene Dokument mit der neuen Information über Verkäufer 30 auf den neuesten Stand bringen, wenn Käufer 20 entscheidet, in dieser Transaktion einen anderen Verkäufer zu verwenden. Bei Schritt 140 sieht Käufer 20 das wieder ausgegebene Benutzerdokument und vervollständigt Abschnitte, die nicht von dem Intelligenzmodul 47 auf den neuesten Stand gebracht wurden, und ändert Abschnitte, von denen Käufer 20 entscheidet, dass sie geändert werden müssen. GCD-Server 40 speichert das wieder ausgegebene Benutzerdokument als Standard- oder einzelnes Dokument abhängig davon, ob das wieder ausgegebene Benutzerdokument in einem Standardformat in Schritt 142 ist, und das Verfahren endet.
  • Das anhand von Fig. 6A & 6B beschriebene Verfahren ist nur ein beispielhaftes Verfahren zum Speichern, Klassifizieren und Wiederverwenden von Dokumenten durch Käufer 20 und/oder Verkäufer 30. Die Schritte können in einer anderen Reihenfolge als oben präsentiert durchgeführt werden und bestimmte Schritte können ausgelassen werden.
  • Obwohl die vorliegende Erfindung anhand verschiedener Ausführungsformen beschrieben wurde, können verschiedene Änderungen, Ersetzungen, Abweichungen, Abänderungen und Modifizierungen einem Fachmann vorgeschlagen werden, und es ist beabsichtigt, dass all diese Änderungen, Ersetzungen, Abweichungen, Abänderungen und Modifizierungen in den Schutzumfang der angefügten Ansprüche fallen.

Claims (35)

1. Elektronisches Handelssystem zur Bestellbeschleunigung durch Wiederverwendung von Benutzerdokumenten, welches umfasst:
einen oder mehrere Dokumentenspeicher, die in der Lage sind zum Speichern einer Vielzahl von Benutzerdokumenten;
ein globales Inhaltsverzeichnis, welches eine Vielzahl von Klassen umfasst, die in einer Hierarchie organisiert sind, jede Klasse die Benutzerdokumente kategorisiert und mit einem oder mehreren Attributen der Benutzerdokumente in dieser Klasse verbunden ist, wobei wenigstens eine der Klassen einen oder mehrere Zeiger besitzt, die einen oder mehrere Dokumentenspeicher identifizieren;
eine Suchschnittstelle verbunden mit dem globalen Inhaltsverzeichnis, wobei die Suchschnittstelle in der Lage ist, eine Suchanfrage an einen oder mehrere Dokumentenspeicher zu übermitteln, die durch einen der Zeiger gekennzeichnet sind, um die Dokumente in den Dokumentspeichern zu durchsuchen;
ein Sicherheitsmodul, das in der Lage ist, die Benutzerdokumente zu entschlüsseln, um einem Benutzer zu gestatten, auf die Benutzerdokumente zuzugreifen; und
ein Intelligenzmodul, das in der Lage ist, einen oder mehrere Abschnitte in den Benutzerdokumenten mit Informationen bezüglich einer zugehörigen Transaktion auf den neuesten Stand zu bringen.
2. System gemäss Anspruch 1, dadurch gekennzeichnet, dass die Dokumente Standarddokumente beinhalten, die in einem verteilten Dokumentenspeicher gespeichert sind.
3. System gemäss Anspruch 1, dadurch gekennzeichnet, dass die Dokumente eindeutige Dokumente beinhalten, die in einer oder mehreren Verkäuferdatenbanken gespeichert sind.
4. System gemäss Anspruch 1, dadurch gekennzeichnet, dass die Klassen eine Vielzahl von Dokumentenklassen beinhalten.
5. System gemäss Anspruch 1, dadurch gekennzeichnet, dass die Klassen eine Vielzahl von Produktklassen beinhalten.
6. System gemäss Anspruch 1, dadurch gekennzeichnet, dass das Sicherheitsmodul die Benutzerdokumente entschlüsselt, wenn der Benutzer, der die Benutzerdokumente anfordert, die erforderliche Erlaubnisebene besitzt.
7. System gemäss Anspruch 1, dadurch gekennzeichnet, dass das Intelligenzmodul die Abschnitte in den Benutzerdokumenten auf den neuesten Stand bringt, wenn der Benutzer anfordert, dass die Benutzerdokumente auf den neuesten Stand gebracht werden.
8. System gemäss Anspruch 1, dadurch gekennzeichnet, dass die Suchschnittstelle weiter in der Lage ist, es dem Benutzer zu erlauben, Benutzerdokumente anzusehen nachdem das Sicherheitsmodul die Benutzerdokumente entschlüsselt hat, jedoch bevor das Intelligenzmodul die Benutzerdokumente mit Informationen bezüglich einer zugehörigen Transaktion auf den neuesten Stand bringt.
9. System gemäss Anspruch 1, dadurch gekennzeichnet, dass das Intelligenzmodul weiterhin in der Lage ist, ein oder mehrere leere Standarddokumente aus den Benutzerdokumenten elektronisch zu erzeugen, wobei die leeren Standarddokumente erfordern, dass der Benutzer Daten von Hand in die Abschnitte des leeren Standarddokuments eingibt, wenn der Benutzer das leere Standarddokument zum ersten Mal ansieht.
10. System gemäss Anspruch 9, dadurch gekennzeichnet, dass das Intelligenzmodul:
Informationen aus den Abschnitten der Benutzerdokumente entfernt; und
die Abschnitte in einer bestimmten Reihenfolge als neues Dokument anordnet, um leere Standarddokumente zu erzeugen.
11. Verfahren zur Bestellbeschleunigung durch Speicherung und Wiederverwendung von Benutzerdokumenten, welches umfasst:
Speichern einer Vielzahl von Benutzerdokumenten in einem oder mehreren Dokumentspeichern;
Verbinden der Benutzerdokumente mit einem globalen Inhaltsverzeichnis, welches eine Vielzahl von einer oder mehreren in einer Hierarchie organisierten Klassen umfasst, wobei jede Klasse die Benutzerdokumente kategorisiert und verbunden ist mit einem oder mehreren Benutzerdokumenten, die in der Klasse kategorisiert sind;
Suchen nach bestimmten Benutzerdokumenten durch Navigieren durch eine oder mehrere der Klassen;
Entschlüsseln der Benutzerdokumente, um einen Benutzer die Benutzerdokumente ansehen zu lassen; und
Wiederausgabe der Benutzerdokumente, auf den neuesten Stand gebracht mit Informationen bezüglich einer zugehörigen Transaktion.
12. Verfahren gemäss Anspruch 11, dadurch gekennzeichnet, dass die Klassen eine Vielzahl von Dokumentklassen umfassen.
12. Verfahren gemäss Anspruch 11, dadurch gekennzeichnet, dass die Klassen eine Vielzahl von Produktklassen umfassen.
14. Verfahren gemäß Anspruch 11, dadurch gekennzeichnet, dass das Wiederausgeben der Benutzerdokumente automatisches Ändern eines oder mehrerer Abschnitte der Benutzerdokumente umfasst, so dass diese die auf die verbundene Transaktion bezogene Information beinhalten.
15. Verfahren gemäss Anspruch 11, dadurch gekennzeichnet, dass die Wiederausgabe der Benutzerdokumente umfasst, zu bestimmen, welche Abschnitte der Benutzerdokumente generisch sind und welche Abschnitte spezifisch für eine bestimmte Transaktion sind.
16. Verfahren gemäss Anspruch 15, dadurch gekennzeichnet, dass die Wiederausgabe der Benutzerdokumente dynamisches Anpassen der generischen Abschnitte der Benutzerdokumente umfasst.
17. Verfahren gemäss Anspruch 15, dadurch gekennzeichnet, dass die Wiederausgabe der Benutzerdokumente umfasst zu bestimmen, welche Abschnitte in ein oder mehrere wiederausgegebene Benutzerdokumente einfließen.
18. Verfahren gemäss Anspruch 11, dadurch gekennzeichnet, dass Entschlüsseln der Benutzerdokumente umfasst zu bestimmen, dass der Benutzer eine für die Entschlüsselung erforderliche Erlaubnisebene besitzt.
19. Verfahren gemäss Anspruch 11, dadurch gekennzeichnet, dass es weiterhin die Ansicht der generischen Abschnitte und der zu einer Transaktion spezifischen Abschnitte nach der Entschlüsselung der Benutzerdokumente umfasst.
20. Verfahren gemäss Anspruch 11, dadurch gekennzeichnet, dass Suchen nach bestimmten Benutzerdokumenten Navigieren durch die Dokumentklassen beim Suchen nach einer bestimmten Art von Benutzerdokument umfasst.
21. Verfahren gemäss Anspruch 11, dadurch gekennzeichnet, dass Suchen nach bestimmten Benutzerdokumenten Navigieren durch die Produktklassen beim Suchen nach mit bestimmten Produkten verbundenen Benutzerdokumenten umfasst.
22. Verfahren gemäss Anspruch 11, welches weiter umfasst:
elektronisches Erzeugen eines oder mehrerer leerer Standarddokumente; und
Eingeben der aktuellen Information von Hand in das leere Standarddokument, wenn der Benutzer das leere Standarddokument das erste Mal ansieht.
23. Software zur Bestellbeschleunigung durch Speicherung und Wiederverwendung von Benutzerdokumenten, wobei die Software auf einem computerlesbaren Medium verkörpert ist und in der Lage ist zum:
Speichern einer Vielzahl von Benutzerdokumenten in einem oder mehreren Dokumentspeichern;
Verbinden der Benutzerdokumente mit einem globalen Inhaltsverzeichnis, welches eine Vielzahl von einer oder mehreren in einer Hierarchie organisierten Klassen umfasst, wobei jede Klasse die Benutzerdokumente kategorisiert und verbunden ist mit einem oder mehreren Benutzerdokumenten, die in der Klasse kategorisiert sind;
Suchen nach bestimmten Benutzerdokumenten durch Navigieren durch eine oder mehrere der Klassen;
Entschlüsseln der Benutzerdokumente, um einen Benutzer die Benutzerdokumente ansehen zu lassen; und
Wiederausgabe der Benutzerdokumente, auf den neuesten Stand gebracht mit Informationen bezüglich einer zugehörigen Transaktion.
24. Software gemäss Anspruch 23, dadurch gekennzeichnet, dass die Klassen eine Vielzahl von Dokumentklassen umfassen.
25. Software gemäss Anspruch 23, dadurch gekennzeichnet, dass die Klassen eine Vielzahl von Produktklassen umfassen.
26. Software gemäß Anspruch 23, dadurch gekennzeichnet, dass das Wiederausgeben der Benutzerdokumente umfasst, das automatische Ändern eines oder mehrerer Abschnitte des Benutzerdokumentes, so dass diese die auf die verbundene Transaktion bezogene Information einschließen.
27. Software gemäss Anspruch 23, dadurch gekennzeichnet, dass die Wiederausgabe der Benutzerdokumente umfasst zu bestimmen, welche Abschnitte der Benutzerdokumente generisch sind und welche Abschnitte spezifisch für eine bestimmten Transaktion sind.
28. Software gemäß Anspruch 27, dadurch gekennzeichnet, dass die Wiederausgabe der Benutzerdokumente dynamisches Anpassen der generischen Abschnitte der Benutzerdokumente umfasst.
29. Software gemäß Anspruch 27, dadurch gekennzeichnet, dass die Wiederausgabe der Benutzerdokumente umfasst zu bestimmen, welche Abschnitte in ein oder mehrere wiederausgegebene Benutzerdokumente einfließen.
30. Software gemäss Anspruch 23, dadurch gekennzeichnet, dass Entschlüsseln der Benutzerdokumente umfasst zu bestimmen, dass der Benutzer eine für die Entschlüsselung erforderliche Erlaubnisebene besitzt.
31. Software gemäss Anspruch 23, welche weiter in der Lage ist, die generischen Abschnitte und die zu einer Transaktion spezifischen Abschnitte nach der Entschlüsselung der Benutzerdokumente anzuzeigen.
32. Software gemäss Anspruch 23, dadurch gekennzeichnet, dass Suchen nach bestimmten Benutzerdokumenten Navigieren durch die Dokumentklassen beim Suchen nach einer bestimmten Art von Benutzerdokument umfasst.
33. Software gemäss Anspruch 23, dadurch gekennzeichnet, dass Suchen nach bestimmten Benutzerdokumenten Navigieren durch die Produktklassen beim Suchen nach mit bestimmten Produkten verbundenen Benutzerdokumenten umfasst.
34. Software gemäss Anspruch 23, welche weiter in der Lage ist:
elektronisches Erzeugen eines oder mehrerer leerer Standarddokumente; und
Eingeben der aktuellen Information von Hand in das leere Standarddokument, wenn der Benutzer das leere Standarddokument das erste Mal ansieht.
35. System zur Bestellbeschleunigung durch Speicherung und Wiederverwendung von Benutzerdokumenten, welches umfasst:
Mittel zum Speichern einer Vielzahl von Benutzerdokumenten;
Mittel zum Verbinden der Benutzerdokumente mit einem globalen Inhaltsverzeichnis, wobei das globale Inhaltsverzeichnis eine Vielzahl von einer oder mehreren in einer Hierarchie organisierten Klassen umfasst, wobei jede Masse die Benutzerdokumente kategorisiert und verbunden ist mit einem oder mehreren Benutzerdokumenten, die in der Klasse kategorisiert werden;
Mittel zum Suchen nach bestimmten Benutzerdokumenten durch Navigieren durch eine oder mehrere der Klassen;
Mittel zum Entschlüsseln der Benutzerdokumente, um einen Benutzer die Benutzerdokumente ansehen zu lassen; und
Mittel zur Wiederausgabe der Benutzerdokumente, auf den neuesten Stand gebracht mit Informationen bezüglich einer zugehörigen Transaktion.
DE10244624A 2001-09-27 2002-09-25 Bestellbeschleunigung durch Speicherung dund Wiederverwendung von Benutzerdokumenten Ceased DE10244624A1 (de)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US32607101P 2001-09-27 2001-09-27
US10/002,433 US10282765B2 (en) 2001-09-27 2001-10-23 Order acceleration through user document storage and reuse

Publications (1)

Publication Number Publication Date
DE10244624A1 true DE10244624A1 (de) 2003-04-30

Family

ID=26670365

Family Applications (1)

Application Number Title Priority Date Filing Date
DE10244624A Ceased DE10244624A1 (de) 2001-09-27 2002-09-25 Bestellbeschleunigung durch Speicherung dund Wiederverwendung von Benutzerdokumenten

Country Status (3)

Country Link
US (1) US10282765B2 (de)
DE (1) DE10244624A1 (de)
TW (1) TWI251760B (de)

Families Citing this family (12)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20040054673A1 (en) * 2002-09-12 2004-03-18 Dement William Sanford Provision of search topic-specific search results information
GB2402506A (en) * 2003-06-02 2004-12-08 Yisia Young Suk Lee Navigation of hierarchical data
US20050050099A1 (en) * 2003-08-22 2005-03-03 Ge Information Systems System and method for extracting customer-specific data from an information network
US20080021767A1 (en) 2006-04-05 2008-01-24 Amanda Benson System and method for collecting and managing product information in a database
US8032427B1 (en) * 2007-04-03 2011-10-04 Local.com System for providing localized shopping information
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
CN102411591A (zh) 2010-09-21 2012-04-11 阿里巴巴集团控股有限公司 一种信息处理的方法及设备
US10776501B2 (en) 2013-08-07 2020-09-15 Microsoft Technology Licensing, Llc Automatic augmentation of content through augmentation services
US10394949B2 (en) 2015-06-22 2019-08-27 Microsoft Technology Licensing, Llc Deconstructing documents into component blocks for reuse in productivity applications
US10740349B2 (en) 2015-06-22 2020-08-11 Microsoft Technology Licensing, Llc Document storage for reuse of content within documents
US10339183B2 (en) * 2015-06-22 2019-07-02 Microsoft Technology Licensing, Llc Document storage for reuse of content within documents

Family Cites Families (37)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
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
US5920873A (en) * 1996-12-06 1999-07-06 International Business Machines Corporation Data management control system for file and database
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
US6076080A (en) * 1997-11-04 2000-06-13 The Standard Register Company Forms order entry system
US6092121A (en) * 1997-12-18 2000-07-18 International Business Machines Corporation Method and apparatus for electronically integrating data captured in heterogeneous information systems
AU3304699A (en) * 1998-02-20 1999-09-06 Storm Systems Llc File system performance enhancement
US6643624B2 (en) * 1998-03-09 2003-11-04 Yan Philippe Method and system for integrating transaction mechanisms over multiple internet sites
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
US7107268B1 (en) * 1998-11-12 2006-09-12 Printable Technologies, Inc. Centralized system and method for managing enterprise operations
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
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
AU2000233614A1 (en) 2000-02-14 2001-08-27 Stephen Corey Wren System for marketing goods and services utilizing computerized central and remote facilities
US6901403B1 (en) * 2000-03-02 2005-05-31 Quovadx, Inc. XML presentation of general-purpose data sources
CA2404141A1 (en) * 2000-03-22 2001-09-27 Unifiedmarket Inc NETWORK-BASED VALUE TRANSACTION METHOD AND SYSTEM
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
GB2364482B (en) * 2000-06-30 2002-10-09 Motorola Inc Server-based electronic wallet system
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
TWI251760B (en) 2006-03-21
US10282765B2 (en) 2019-05-07
US20040158496A1 (en) 2004-08-12

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
US6983276B2 (en) Facilitating electronic commerce transactions using buyer profiles
US8571945B2 (en) Pre-qualifying sellers during the matching phase of an electronic commerce transaction
US7647311B2 (en) Content enhancement for analyzing data in a database
US20180285883A1 (en) Providing Market Feedback Associated with Electronic Commerce Transactions to Sellers
DE10244731A1 (de) Dynamischer Auslastungsausgleich unter Verwendung einer semantischen Verkehrsüberwachung
US7127416B1 (en) Distributed processing of sorted search results in an electronic commerce system and method
US8086643B1 (en) Translation between product classification schemas
DE10244623A1 (de) Dynamische Datenbankumleitung unter Verwendung semantischer Taxonomie-Information
DE10244726A1 (de) Erzeugen, Aktualisieren und Verwalten von Multi-Taxonomie-Umgebungen
Stonebraker et al. Content integration for e-business
DE60037511T2 (de) Interaktives system um produkte in einem netzwerk zu suchen
US7099849B1 (en) Integrated media management and rights distribution apparatus
DE10244622A1 (de) Speicherung und Wiederverwendung von Drittparteidokumenten
DE112006002886T5 (de) System und Verfahren zum Speichern von Postenattributen in einem elektronischen Katalog
EP1131752B1 (de) Verfahren zur datenbankgestützten selektion von produkten für electronic-commerce-anwendungen im internet
DE10244624A1 (de) Bestellbeschleunigung durch Speicherung dund Wiederverwendung von Benutzerdokumenten
US7475030B1 (en) Facilitating electronic commerce transactions using a shared product data repository
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
Liu et al. Deployment of personalized e-catalogues: An agent-based framework integrated with XML metadata and user models
DE10246000A1 (de) Bereitstellung einer Visualisierung von Marktangeboten mittels Mustern von geometrischen Anzeigeelementen
WO2001067300A1 (en) Improved parameter-value databases

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
R002 Refusal decision in examination/registration proceedings
R003 Refusal decision now final

Effective date: 20110405