DE69424218T2

DE69424218T2 - Vorrichtung zum Herstellen von kristallisiertem Glas

Info

Publication number: DE69424218T2
Application number: DE69424218T
Authority: DE
Inventors: Keiichiro Miyano; Yoshikazu Nagayoshi; Takatsugu Ogata; Kenji Suzuki; Takeshi Yamaura
Original assignee: Tsukishima Kikai Co Ltd
Current assignee: Tsukishima Kikai Co Ltd
Priority date: 1993-05-24
Filing date: 1994-05-24
Publication date: 2000-11-02
Anticipated expiration: 2014-05-25
Also published as: EP0626349A2; DE69424218D1; EP0626349B1; JP2864323B2; ATE192419T1; US5571301A; JPH06329423A; EP0626349A3; ES2148294T3

Description

Beim Aufbau jedweder Datenbank für eine gemeinschaftliche Nutzung tauchen oftmals zwei Probleme auf: welche Daten gesammelt werden und wie dies vonstatten gehen soll. So hat z. B. das Problem, wie Daten gesammelt werden sollen, den Aufbau einer Datenbank mit sämtlichen US-Telefonnummern, die nicht durch die einzelnen Beil Firmen kontrolliert werden, verhindert. Das Problem wird schlimmer, wenn ein internationales Verzeichnis beabsichtigt wird. Noch schlimmer wird das Problem, wenn dabei Netzwerke wie das Internet involviert sind, da es in diesen Netzwerken keine "Telefongesellschaft" gibt, die die Nummern der Teilnehmer zwangsweise einträgt.
Das Problem, welche Daten gesammelt werden sollen, kann genauso ärgerlich sein. Es gibt eine unendliche Anzahl von Informationen, die man in eine Datenbank eingeben könnte. Woher soll man z. B. wissen, ob eine bestimmte Telefonnummer eingetragen werden soll? Ein System und ein verfahren zur Lösung dieser beiden Probleme in einem grossen Rahmen wird offenbart. Es ermöglicht einer Datenbank, sich selbst mit Informationen, die die Anwender benötigen, zu füllen und diese Daten auch zu aktualisieren und korrigieren. Dieses System und diese Methode können als Selbstorganisierende Datenbank (SODB) bezeichnet werden.
Dem Erfinder sind keine Datenbanksysteme und -verfahren wie die SODB bekannt. Die SODB ermöglicht den für Daten zahlenden Anwendern, ebenfalls Daten einzugeben und dafür Lizenbeträge zu erhalten. In einem konventionellen Informationsverteilsystem, wie in WO 90/02382 beschrieben, bezahlt der Anwender für die aus der Datenbank bezogene Information. Des Weiteren ermöglicht die SODB diesen Anwendern, automatisch die geschätzte Höhe der Lizenzbeträge für die einzugebenden Daten zu ermitteln. Während andere Datenbanken bestimmten nichtzahlenden Anwendern gestatten, den möglichen Lizenzbetrag, den eine Information einbringt, zu ermitteln, hat jedoch noch keine Datenbank diese Möglichkeit zahlenden Anwendern so direkt zugänglich gemacht wie die SODB, um ein wirksames Rückmeldungssystem zu erzeugen.

Zusammenfassung

Die SODB ist ein Datenbanksystem, das für die Anwender kostenpflichtig ist, die dort Daten suchen, und die Anwender bezahlt, die dort die gefundenen Daten liefern. Sie kann sowohl aus einem einzelnen Rechner bestehen als auch aus einem Netzwerk. Der Schlüssel zu der SODB ist ein eingebauter Rückmeldungsmechanismus, genannt Abrechnungsmeter, der den Anwendern mitteilt, welche Daten auf Basis von Anforderungen nach diesen Daten benötigt werden. Fordert ein Anwender Daten an, die nicht in der SODB enthalten sind, registriert das Abrechnungsmeter diese Anforderung. Je nach der Anzahl der Anfragen schätzt diese Funktion den möglichen Lizenzbetrag für den Fall, dass diese Daten zur Verfügung gestellt werden. Je mehr Anfragen in einem bestimmten Zeitraum registriert werden, desto höher ist das zu erwartende Honorar.
Der Schlüssel ist, dass das zu erwartende Honorar jedem Anforderer nach diesen Daten mitgeteilt wird. Das Schöne daran ist, dass sich jeder dieser Anforderer die entsprechenden Daten ohnehin anderweitig besorgen muss. Um das Honorar zu vereinnahmen, braucht ein Anforderer im Anschluss nur die SODB "zurückzurufen" und die Antwort einzugeben. So wird ein sensibles und wirksames Rückmeldungssystem erzeugt, das sicherstellt, dass, ie häufiger die Anforderung nach bestimmten Daten ist, desto wahrscheinlicher diese von einem Anforderer oder einer Person, der der Anforderer von der Abrechnung erzählt hat, zur Verfügung gestellt werden wird. Ausserdem schafft dieses Honorar einen Ansporn, fehlerhafte Daten zu korrigieren oder zu aktualisieren.

Liste der Abbildungen

Fig. 1 zeigt das Flussdiagramm einer grundlegenden SODB.
Fig. 2a zeigt - das Flussdiagramm des Anfragemodus eines Niedrigstpreis-Lokalisierers.
Fig. 2b zeigt das Flussdiagramm des Liefermodus eines Niedrigstpreis- Lokalisierers.

Beschreibung

Die SODB ist ein Datenbanksystem, das für den Anwender, der Daten erhält, kostenpflichtig ist und dem Anwender, der Daten liefert, ein Honorar zahlt. Was die SODB von anderen Datenbanken unterscheidet, ist eine Funktion, die den Anwendern, die Daten anfordern, zeigt, wie hoch die geschätzten Lizenzbeträge für gelieferte Daten sind. Die Funktion merkt sich die Anzahl der Anforderungen für bestimmte Daten und errechnet daraus eine Anforderungsrate. Die geschätzte Nachfrage wird mit der Lizenzrate multipliziert und ergibt einen voraussichtlichen Lizenzbetragsstrom. Fordert eine Person Daten an, die nicht in der SODB enthalten sind, zeigt die SODB den geschätzten Wert der Daten an, falls sie eingegeben würden. (Stellt die Person fest, dass die angeforderten Daten in der SODB sind, kann die SODB immer noch den Lizenzbetrag für verbesserte, korrigierte oder aktualisierte Einträge anzeigen.) Danach zeigt die SODB den Anwendern, falls erforderlich, wie eine Dateneingabe erfolgen muss. Zusammengefasst ist die SODB ein hochwirksames Rückmeldungssystem, das den Anwendern zeigt, welche Datenlieferungen benötigt werden, welcher finanzielle Anreiz vorhanden ist, die Daten zu liefern, wie die Daten eingegeben werden, und die sie anschliessend für die Lieferung bezahlt.

Einige Definitionen und Kommentare

Startmodus: Die von der SODB ausgeführte Prozedur ermöglicht den Anwendern Zugriff auf die SODB und die Auswahl zwischen Liefer- und Anforderungsmodus. Der Startmodus ist nicht unbedingt erforderlich, solange dessen "Einbuchfunktion" teil der Liefer- und Anforderungsmodi ist.
Anforderungsmodus: Die von der SODB ausgeführte Prozedur liefert Antworten und/oder zeigt dem Anforderer das geschätzte Honorar an. Im Anforderungsmodus gibt ein Anwender eine Frage ein, woraufhin die SODB die entsprechende Antwort sucht. Wird die Antwort nicht gefunden, wird ein geschätztes Honorar angezeigt. Wird die Antwort gefunden, wird diese zusammen mit dem geschätzten Honorar angezeigt (siehe Abrechnungsmeter), und dem Anwender wird eine Gebühr berechnet.
Liefermodus: Die von der SODB ausgeführte Prozedur ermöglicht dem Anwender die Eingabe von Antworten, potenziellen Antworten und Rohdaten. Die Anwenderidentifikation wird zusammen mit den eingegebenen Daten registriert, so dass dem Anwender bei jeder Anforderung dieser Daten der Lizenzbetrag gutgeschrieben werden kann.
Anforderer: Anwender, der auf der Suche nach einer Antwort über den Anforderungsmodus auf die SODB zugreift. Der Anforderer schuldet eine Gebühr, falls die Antwort gefunden wird.
Lieferant: Anwender, der über den Liefermodus zugreift, um eine Antwort oder Rohdaten einzugeben. Der Lieferant wird bei jedem Zugriff durch die SODB auf diese Antwort oder Rohdaten gemäss der Lizenzbetragsregeln bezahlt.
Gebühren: Summe, die ein Anforderer für die gefundene Antwort schuldet.
Lizenzbetragsregeln: Regeln, eingebettet in Funktionen, die die dem Lieferanten einer Antwort (oder der für eine Antwort erforderlichen Rohdaten) für jedes Mal, das diese Antwort ausgegeben wird, zustehende Summe bestimmen.
Zahlungsregister: Die von der SODB ausgeführte Funktion registriert von Anforderern geschuldete und den Lieferanten zustehende Zahlungen. Wird eine Antwort ausgegeben, registriert das Zahlungsregister, wem ein Lizenzbetrag zusteht oder wer die Kosten für die benutzten Daten trägt. Was das Zahlungsregister registriert, hängt von den Lizenzbetragsregeln der SODB ab.
Frage: Spezifische Daten, die anderen spezifischen Daten, Antwort genannt, entsprechen. Die Eingabe einer Frage durch den Anforderer veranlasst die SODB zur Suche nach der entsprechenden Antwort.
Antwort: Spezifische Daten, die anderen spezifischen Daten, Frage genannt, entsprechen. Eine Antwort kann statisch sein, z. B. verändert sich die chemische Struktur von Benzin nicht. Sie kann dynamisch sein, z. B. verändert sich der Benzinpreis. Und sie kann verbesserbar sein, z. B. kann die Oktanzahl des Benzins genauer angegeben werden. Eine Antwort kann lang oder kurz sein. Sie kann eine oder mehrere Komponenten aufweisen. Beispiel: Die Frage "Welche chinesischen Restaurants gibt es in Biloxi?" kann eines oder mehrere Restaurants liefern.
Die Beziehung zwischen einer Frage und deren Antwort: Auf eine Frage kann es nur eine Antwort geben, obwohl diese Antwort aus mehreren Komponenten bestehen kann. Natürlich kann es auf eine Frage mehrere, vielleicht sogar unendlich viele, Antworten geben. Doch die SODB benötigt Regeln, die die Antwort auf eine limitieren, wie im folgenden Sinne: Die Antwort auf eine Frage muss ein endlicher Datensatz sein, der dem Anforderer ausgegeben und berechnet wird. Die Antwort ist, wofür der Anforderer bezahlt.
(Ein grosses Problem bei der Definition von "Antwort" ist, dass bisher niemand eine gute Definition geliefert hat.) In der SODB geben die Anwender die Antworten ein, die ihnen am besten erscheinen. Und die Anwender bestimmen die Genauigkeit dieser Antworten. Die SODB akzeptiert unwahre oder ungefähre Antworten, denn sie kann Bedeutungen und Wahrheit nicht erkennen, aber jede Antwort wird durch eine bessere Antwort ersetzt. Eine bessere Antwort ist eine Antwort, die gemäss Konvention und nach den Regeln der SODB eine Frage besser beantwortet als die bereits existierende Antwort. Ein Anwender kann eine Antwort durch eine andere ersetzen. Gibt es zwischen Anwendern Streit darüber, welche Antwort besser ist, kann eine dritte, neutrale Instanz, der Datenbankmanager, zur Schlichtung des Streits angerufen werden.
Natürlich ist bei der Vielzahl der Fragen nicht durch Konventionen bestimmbar, welche Antwort "besser" ist. Es kann viele, sogar eine unendliche Anzahl von gleich guten Antworten geben. Daher müssen die Regeln der SODB abhängig von der Art der Frage die möglichen Antworten limitieren. Eine Regel kann z. B. sein, dass die erste eingegebene Antwort als besser angesehen wird als alle anderen gleichwertigen Antworten. Dennoch kann kein Regelsatz die Wahrheit vereinnahmen, und daher hat der Datenbankmanager das letzte Wort bei der Entscheidung, ob eine Antwort wahr ist oder nicht, oder ob eine Antwort besser ist als eine andere. Siehe auch Qualitätskontrollfunktionen weiter unten.
Potenzielle Antwort: Eine Antwort, die zur besten Antwort in der SODB auf eine Frage werden kann.
Rohdaten: Wenn die SODB die erforderlichen Funktionen aufweist, kann sie Rohdaten so verarbeiten, dass diese zu Antworten führen. Ein Rohdatum kann als Antwort zu einer Frage angesehen werden. Beispiel: Für die Frage "Welches McDonald's liegt am nächsten zur 1234 Main Street?" könnte die SODB die Koordinaten von 1234 Main Street benötigen. Daher sind diese Koordinaten Rohdaten. Ausserdem sind die Koordinaten selbst die Antwort auf die Frage "Welche Koordinaten hat 1234 Main Street?". Jede Antwort auf eine Frage kann ein Rohdatum für die Beantwortung anderer Fragen sein.
Speichern von Antworten: Normalerweise listet die SODB eine Antwort unter der zu beantwortenden Frage auf. Auf die Antwort kann dann durch einfaches Nachschlagen zugegriffen werden. Antworten können ebenfalls als Rohdaten gespeichert werden, die dann verarbeitet werden.
Datenanforderung: Jede Suche nach Daten, die durch das Eingeben einer Frage durch den Anforderer gestartet wird. Eine unendliche Anzahl von Nachschlageoperationen kann durchgeführt werden, einschliesslich Suchen, die Funktionen zum Erzeugen von Daten anführen.
Klassifizierung einer Datenanforderung: Die SODB klassifiziert Datenanforderungen, um zwischen ihnen unterscheiden und sie zählen zu können. Dennoch muss es wie bei jedem Klassifizierungssytem willkürliche Regeln geben. Die Klassifizierung der Anforderungen durch die SODB kann daher unendlich verschieden sein.
Datennutzung (Nutzung): Wenn die SODB ein Datum als Antwort benutzt oder um zu einer Antwort zu gelangen. Datennutzungen können grob in zwei Arten unterteilt werden:
a) Ausgabe der Daten als Antwort oder als Teil einer Antwort,
b) Einfügen der Daten in einen Algorithmus, der die Antwort ausgibt.
Klassifizierung einer Datennutzung: Da es unendlich viele Algorithmen und unendlich viele Arten von Antworten gibt, gibt es ebenfalls unendlich viele Datennutzungen. Die SODB hat Regeln für die Klassifizierung dieser Nutzungen mit dem Zweck, die Nutzungen zu zählen und die Lizenzbeträge zu zahlen. So kann z. B. der Nutzung der Zahl Pi ein anderer Lizenzbetrag zugewiesen werden als der Nutzung des Geburtsdatums Lincolns oder der Nutzung eines Auszugs aus Shakespeare. Wie bei der Klassifizierung von Datenanforderungen gibt es keine starren und festen Regeln.
Abrechnungsmeter (POM): Die Funktion, die das Kernstück der SODB bildet. Der POM hat drei Unterfunktionen:
1) Anforderungsmeter (D-Meter), das Datenanforderungen und
- nutzungen über einen Zeitraum hinweg zählt, um eine geschätzte Anforderungsrate für eine Antwort (oder für ein Rohdatum) anzuzeigen.
2) Auszahlungsformel (POF), die aus der Anforderungsrate eine Honorarschätzung (POE) für das Einkommen eines Anwender für die Eingabe der Antwort (oder eines Rohdatums) berechnet,
3) Input-Signal (I-Signal), das die POE und die Antwort (oder das Rohdatum) ausgibt, das ggf. eingegeben werden muss, und, falls erforderlich, Anweisungen gibt, wie die Antwort (oder die Rohdaten) eingegeben werden kann.
Das POM arbeitet am einfachsten, wenn die Antworten der SODB unter den Fragen aufgelistet werden und die SODB die Antworten durch eine einfache Nachschlageoperation finden kann. Ein Anforderer gibt z. B. die Frage "Wann ist Lincolns Geburtstag?" ein. Die SODB führt eine Nachschlageoperation durch. Am Anfang befindet sich die Antwort noch nicht in der SODB. Die SODB speichert daraufhin diese Anfrage und zählt jede Nachschlageoperation. Die SODB registriert ebenfalls die Zeit jeder Nachschlageoperation, so dass die Rate der Nachschlageoperationen festgestellt werden kann. Die Rate der Nachschlageoperationen (Anforderungsrate) für diese Antwort wird in die POF eingespeist, um die POE zu erhalten. Das I-Signal zeigt jedem Anforderer diese POE an. Da die Antworten unter den Fragen aufgelistet sind, braucht das I- Signal nicht anzuzeigen, welche Antwort nicht vorhanden ist oder wie diese eingegeben werden kann. Es wird angenommen, dass die Anforderer implizit wissen, dass sie die Eingabe einer Antwort einfach in den Liefermodus gehen und die Frage und anschliessend die Antwort eingeben müssen. Sobald die Antwort eingegeben ist, verfolgt der D-Meter weiterhin die Anforderungsrate, da die Antwort auch falsch sein könnte. Das POM kann dann den Anforderern immer noch die POE für die Korrektur der Antwort anzeigen.
Wenn die SODB Antworten nachschlägt, können Datenanforderungen und - nutzungen durch das Zählen der Nachschlageoperationen gemessen werden. Die SODB kann jedoch komplizierter werden, da die Klassifizierung von Datenanforderungen und -nutzungen kompliziert sein kann. Des Weiteren kann die Anforderungsrate die Preise für Daten ebenfalls berücksichtigen. POM- Funktionen werden nachstehend besprochen, wobei das Thema der Klassifizierung von Datenanforderungen und -nutzungen berücksichtigt wird, nicht jedoch das Thema der Preisgestaltung für Daten.
Anforderungsmeter (D-Meter): Funktion, die Datenanforderungen und - nutzungen zusammen mit der Zeit, zu der diese stattfinden, zählt, um die Anforderungsrate für ein Datum zu errechnen.
Der D-Meter zählt:
a) Daten, nach denen spezifisch mit Namen gesucht wird, die jedoch nicht gefunden wurden. Ein Anwender fordert z. B. eine geschäftliche Telefonnummer an, die nicht in der SODB enthalten ist. Diese Datenanforderung kann unter dem Firmennamen gezählt werden.
b) Daten, die benutzt, jedoch nicht spezifisch nach Namen gesucht werden. Ein Anwender fordert z. B. den durchschnittlichen Preis für einen Flugschein nach Boston an. Dutzende von Preisen können in eine Durchschnittsfunktion eingespeist werden, um diese Frage zu beantworten. Jeder diese Preise wird benutzt, wurde jedoch nicht spezifisch nach Namen angefordert.
c) Daten, nach denen mit Namen gesucht wird und die benutzt (gefunden) werden. In diesen Fällen zählt der D-Meter nur einmal. Es zählt nicht zweimal Suche und Finden.
Wie oben besprochen kann es eine unendliche Anzahl von Wegen geben, Datenanforderungen und -nutzungen zu klassifizieren, daher kann das D-Meter unendlich variiert ausgebildet sein.
Der Schlüssel zum D = Meter ist, dass dieser Datenanforderungen und - nutzungen für Daten zählt, die zwei Bedingungen erfüllen: Lizenzbeträge werden für diese Daten gezahlt, und die Anwender können instruiert werden, Daten einzugeben. Die Aufgabe des D-Meters ist es, die Nachfrage nach bestimmten Daten zu messen, so dass die Anforderungsrate in die POF eingespeist werden kann, die dann den Wert für eine Dateneingabe errechnet. Es wäre sinnlos, Anforderungen für Daten zu zählen, die nicht benannt und daher auch nicht eingegeben werden können. (Nebenbei: Das Auszahlungsregister kann Nutzungen zählen, die das D-Meter nicht zählt.)
Das D-Meter muss nicht notwendigerweise die Nachfrage für alle Arten von Daten, die in die SODB eingegeben werden können, zählen. Es ist z. B. wichtig zu beachten, dass das D-Meter nicht die Nachfrage nach potenziellen Antworten messen kann. Doch durch die Messung der Nachfrage nach tatsächlichen Antworten kann das D-Meter den Anwendern einen Eindruck des potenziellen Wertes für die Eingabe einer potenziellen Antwort vermitteln. Ein Beispiel wird sowohl diese Situation als auch das Thema Klassifizierung erläutern.
Angenommen, ein Anforderer gibt die Frage ein "Welches Geschäft bietet den niedrigsten Preis für den Sony Camcorder #1239?" Nehmen wir weiter an, dass es 1.000 Anfragen gibt. Nun kann es sein, dass zehn Geschäfte denselben niedrigsten Preis bieten. Was ist dann die Nachfrage nach einem gegebenen Geschäft? Dies hängt davon ab, wie die SODB die Antwort klassifiziert. Die SODB könnte als Regel haben, dass nur das als erstes eingegebene Geschäft mit dem niedrigsten Preis als Antwort angezeigt werden kann. Dieses Geschäft wird zur Antwort, und alle Lizenzbeträge gehen an den Anwender, der dieses Geschäft eingespeist hat. Tatsächlich ändert die SODB die Anfrage in "Welches Geschäft hat den niedrigsten Preis und wurde als erstes eingespeist?". Natürlich interessiert den Anforderer nicht, welches Geschäft als erstes eingespeist wurde, aber die SODB kann eingebaute Standardannahmen aufweisen, um die Grösse und Anzahl der angezeigten Antworten zu begrenzen. Daher sind alle anderen Geschäfte, auch wenn sie denselben niedrigsten Preis bieten, potenzielle Antworten (das erste Geschäft könnte den Preis ändern, so dass ein anderes Geschäft seinen Platz einnimmt). Der Einspeiser eines Geschäfts mit dem niedrigsten Preis weiss nicht, ob seine Eingabe Lizenzbeträge erzielen wird oder nicht. Es gibt keine registrierte Nachfrage nach diesem Geschäft.
Andererseits kann die SODB z. B. eine Regel haben, dass alle Geschäfte mit demselben Preis ein gleichwertiger Teil der Antwort sind, so dass die Antwort dann aus zehn Komponenten besteht. Die Anforderungsrate nach dem Geschäft mit dem niedrigsten Preis kann dann z. B. durch die Anzahl von Komponenten dividiert werden, um eine Anforderungsrate für jede Komponente zu erreichen (diese Berechnung kann tatsächlich Teil der POF sein). Die Klassifizierungen können sogar noch komplizierter sein. Der zweite eingegebene Laden kann als vom ersten verschieden angesehen werden, die Lage des Geschäfts kann wichtig sein, usw. Der Punkt ist, dass das D-Meter danach zählt, welche Daten Lizenzbeträge erhalten, was davon abhängt, wie Antworten klassifiziert werden, und das kann unendlich variierbar sein.
Auszahlungsformel (POF): Die Funktion, die eine Honorarschätzung (POE) berechnet. Die POF errechnet die zukünftige Nachfrage nach einem Datum, basierend auf der Nachfrage, die bereits besteht. Daher gibt es zwei kritische Variablen, N, die Anzahl der Nachfragen nach einem Datum, und T, die Zeiten der Nachfragen. Basierend auf der Anforderungsrate eines Datums, schätzt die POF, wie viele Nachfragen es zukünftig nach diesem Datum geben wird, und multipliziert dies mit der Lizenzbetragsrate, um die POE zu erlangen. Wenn ein Datum bereits in der SODB enthalten ist, nutzt die POF den Zähler N der Datenanforderungen und -nutzungen, die das D-Meter zur Verfügung stellt.
Wie bei jeder Gleichung für eine Prognose kann die Auszahlungsformel unendlich variieren, basierend auf historischen Daten und anderen Faktoren. Die Formel würde z. B. eine historisch basierende Annahme, wann die Nachfrage aufhört, einschliessen. Die POF kann Schätzungen, die nicht auf der aktuellen Anforderungsrate für ein bestimmtes Datum basieren, sondern für Daten, die ähnlich sind, umfassen. Unabhängig von den eingebauten historischen Annahmen ist die POF immer eine Funktion der Anforderungsrate. Die Werte für N und T sind in der POF enthalten, die die Lizenzbetragsrate enthält.
Die Lizenzbetragsrate kann natürlich auch unendlich variabel sein. Es kann z. B. gleitende Staffelungen für den ausgezahlten Lizenzbetrag für eine Antwort geben. Und unterschiedliche Datenanforderungen und -nutzungen können unterschiedlich hohe Lizenzbeträge haben. (Technisch gesehen ist es der POF möglich, keine Lizenzbetragsrate zu haben und nur die erwartete Anforderungsrate zu berechnen. In diesem Falle wäre die Lizenzbetragsrate den Anwendern bekannt, die ihre eigenen Berechnungen durchführen könnten.) Die POF muss ebenfalls einen willkürlichen Wert für die POE aufweisen, wenn ein Datum null mal oder einmal angefragt wurde. Dieser Wert könnte ein Betrag sein oder einfach eine Meldung, wie z. B. "POE unbekannt".
I-Signal: Die Funktion ist der Ausgabeteil der POM, das Signal, das dem Anforderer mitteilt, welche Daten benötigt werden, welchen Wert die Lieferung von Daten hat und wie man diese liefert. Wenn ein Anforderer eine Antwort anfordert, die nicht in der SODB enthalten ist, gibt die SODB die POE aus. Wenn ein Anforderer eine in der SODB enthaltene Antwort anfordert, gibt die SODB die Antwort und die POE für die Eingabe von Korrektur, Aktualisierung oder Verbesserung aus. (Die POE kann auch nur auf Anfrage ausgegeben werden, anstatt automatisch.)
Wenn das I-Signal die POE ausgibt, kann es die benötigte Antwort oder die benötigten Daten ebenfalls ausgeben. Normalerweise ergibt sich die benötigte Antwort aus der gestellten Frage. Wenn Rohdaten benötigt werden, könnten die benötigten Daten sich nicht implizit aus der Frage ergeben. In diesem Falle kann das I-Signal ebenfalls die benötigte Datenart ausgeben, wenn die SODB die erforderlichen Funktionen für die Erkennung der benötigten Daten hat. Beispiel: "Benötige Antwort auf "Was ist die Geschwindigkeit des Lichts?". POE: $2." Wenn es schliesslich erforderlich ist, kann das I-Signal Anweisungen anzeigen, wie die Daten eingegeben werden müssen.

Eine grundlegende SODB umfasst die folgenden Elemente und Prozeduren wie in Fig. 1 gezeigt:

SODB Elemente
Computereinheit für die Ausführung der SODB-Funktionen.
SODB-Funktionen
a) Eingabe, Speicherung, Löschung und Ausgabe von Daten
b) Startmodus
c) Anforderungsmodus
d) Liefermodus
e) Nachschlageoperation
f) Registrierung der Gebühren
g) Registrierung der Honorare
h) Abrechnungsmeter (POM)
SODB-Prozeduren
Startmodus
1) Anwender gibt Anwenderidentifikation ein, SODB speichert diese (1)
2) Anwender gibt Liefer- oder Anforderungsbefehl ein (1), SODB greift auf den entsprechenden Modus zu (2).
Anforderungsmodus
1) Anforderer gibt eine Frage ein (3), SODB
a) registriert Datum und Uhrzeit der Anfrage (4)
b) führt eine Nachschlageoperation durch (5)
2) Ist die Antwort in der SODB enthalten, wird
a) die Antwort ausgegeben (6)
b) die für den Anfrager fällige Zahlung registriert (7)
c) der für den Lieferanten fällige Lizenzbetrag registriert (7)
d) die Anzahl der Anfragen nach dieser Frage um eins erhöht (8) und die POF berechnet (9)
e) die POE ausgegeben (10)
3) Ist die Antwort nicht in der SODB enthalten, führt die SODB die POM-Funktion aus, welche
a) prüft, ob die Frage bereits im Abrechnungsmeter gespeichert ist (11) (wurde bereits zuvor nachgefragt)
a1) falls nein, speichert die Frage (12), setzt die Anzahl der Anfragen für diese Frage auf eins (13), berechnet unter Verwendung der POF die POE (14)
a2) falls ja, addiert eins zu der Anzahl der Anfragen für diese Frage (8), errechnet unter Verwendung der POF die POE (9)
b) gibt dem Anwender die POE aus (10).
Liefermodus
1) Lieferant gibt eine Frage ein (15), SODB führt Nachschlageoperation durch (16) (diese Nachschlageoperation wird nicht als Datenanforderung gezählt; nur Nachschlageoperationen im Anforderungsmodus werden so im POM gezählt).
2) Wird die Antwort nicht gefunden, gibt der Lieferant die Antwort ein (17), die SODB speichert die Antwort entsprechend der eingegebenen Frage und speichert die Identifikation des Lieferanten zusammen mit der Antwort (18), um dem Lieferanten bei jeder Anforderung dieser Antwort den Lizenzbetrag gutgeschrieben.
3) Wird die Antwort gefunden, gibt die SODB eine Meldung aus, dass die Antwort bereits in der SODB enthalten ist (19); hat der Lieferant die Absicht, die bestehende Antwort zu korrigieren, gibt der Lieferant einen Befehl, wie z. B. KORRIGIEREN (20), ein, und die SODB gestattet es, die alte Antwort durch die neue zu ersetzen (17) und die alte Lieferantenidentifikation durch die neue Lieferantenidentifikation zu ersetzen (18).
Diese Elemente und Prozeduren bilden das Kernstück der SODB. Die SODB enthält normalerweise weitere nützliche Funktionen. Bevor diese näher erläutert werden, wird ein Ausführungsbeispiel einer grundlegenden SODB, ein selbstfüllendes Telefonverzeichnis (SFTD), beschrieben. Danach wird ein Ausführungsbeispiel beschrieben, das mehr kann, als nur Antworten unter Fragen nachzuschlagen.
1. Das SFTD enthält eine Liste von Namen und dazugehörigen Telefonnummern, anfänglich leer, einen Computer zum Speichern der Liste und Funktionen für die Dateneingabe in die Liste, zum Ausgeben von Daten aus der Liste und zum Nachschlagen der Daten in der Liste.
2. Das SFTD enthält ebenfalls eine Anmeldefunktion, die es den Anwendern ermöglicht, sich selbst zu Rechnungs- und Zahlungszwecken zu identifizieren. Die SFTD speichert die Identifikationsdaten.
3. Anwender greifen auf das SFTD per Telefon zu. Der SFTD- Computer ist mit einer Telefonschnittstelle ausgerüstet. Das SFTD nimmt Anrufe über zwei Leitungen entgegen, eine Anforderungsleitung und einer Lieferleitung. Die Anforderungsleitung setzt die Anwender automatisch in den Anforderungsmodus, währen die Lieferleitung die Anwender in den Liefermodus setzt.
4. Beim Benutzen des Anforderungsmodus greift ein Anforderer auf die SFTD-Liste durch das Buchstabieren eines Namens über das Telefon in den SFTD-Computer zu. Ist das SFTD mit einer Spracherkennung ausgestattet, erkennt es die Anforderung und führt eine Nachschlageoperation aus. Mit einem Spracherzeuger wird die Antwort dann in Form von künstlicher Sprache ausgegeben.
5. Enthält das SFTD eine zum Namen passende Telefonnummer, gibt es diese Nummer aus und registriert die für den Anforderer anfallenden Gebühren sowie den Lizenzbetrag für den Lieferanten. Eine Eins wird zum POM-Zähler für Datenanforderungen hinzugefügt, die Uhrzeit der Anfrage wird registriert und eine neue POE berechnet und zusammen mit der Telefonnummer angezeigt.
6. Ist die Telefonnummer nicht enthalten, wird das POM des SFTD dem Anforderer ausgegeben. Das POM hat mehrere Funktionen: a) Es registriert die Uhrzeit der Anfrage, b) es prüft, ob die Anfrage bereits im POM-Register gespeichert ist, c) falls nein, setzt er den Zähler auf 1, speichert die Anfrage und setzt die POE auf die Meldung "nicht genügend Daten für eine Honorarschätzung", d) ist die Anfrage bereits gespeichert, ergänzt POM den Zähler um eins und berechnet dann unter Verwendung der POF die POE (wir nehmen zu Erläuterungszwecken an, dass die POF die Anzahl der Anfragen durch den Zeitraum dieser Anfragen dividiert und dann annimmt, dass diese Rate für weitere vier Jahre bestehen bleibt. Die Formel multipliziert dann die Anzahl der Anfragen über vier Jahre hinweg mit der Lizenzbetragsrate pro Anfrage, um die POE zu erhalten), e) es gibt die POE aus.
7. Ein Lieferant greift durch Buchstabieren eines Namens über das Telefon auf das SFTD zu. Die Spracherkennungsfunktion des SFTD erkennt die Anforderung, und das SFTD führt eine Nachschlageoperation aus, um festzustellen, ob eine entsprechende Telefonnummer bereits in der Liste eingetragen ist. Ist die Nummer nicht in dem SFTD vorhanden, ermöglicht das SFTD dem Lieferanten, diese Nummer einzugeben und speichert die Lieferantenidentifikation zusammen mit der Nummer, um die Lizenzbeträge korrekt gutschreiben zu können. Ist die Nummer bereits in dem SFTD eingetragen, erzeugt das SFTD eine Sprachmeldung "Nummer ist bereits im Verzeichnis eingetragen". Muss die Nummer korrigiert werden, gibt der Lieferant den Befehl KORRIGIEREN ein. Die SFTD gestattet dem Lieferanten die Eingabe der Nummer über die Spracherkennungsfunktion des SFTD.
Das SFTD speichert die passende Nummer zu der Frage, d. h. dem Namen, und speichert ebenfalls die Identifikation des Lieferanten zusammen mit der Nummer, um die Lizenzbeträge korrekt gutschreiben zu können.
Ein weiteres Ausführungsbeispiel, ein Niedrigstpreis-Lokalisierer, wird in den Fig. 2a und 2b gezeigt.
1. Ein Niedrigstpreis-Lokalisierer (LPL) umfasst eine Liste von Produktnamen und dazugehörigen Preisen und Geschäften, anfänglich leer, einen Computer zum Speichern der Liste und Funktionen zum Eingeben von Daten in die Liste, zum Ausgeben der Daten aus der Liste, zum Nachschlagen der Daten in der Liste und zum Verarbeiten der Daten in der Liste.
2. Der LPL besitzt auch eine Anmeldefunktion (30), die den Anwendern die eigene Identifizierung zu Rechnungs- und Auszahlungszwecken ermöglicht. Der LPL speichert die Identifikationsdaten.
3. Anwender greifen auf den LPL per Telefon zu. Der LPL-Computer ist mit einer Telefonschnittstelle ausgerüstet. Der LPL nimmt Anrufe über zwei Leitungen entgegen, einer Anforderungsleitung und einer Lieferleitung. Die Anforderungsleitung setzt die Anwender automatisch in den Anforderungsmodus, während die Lieferleitung die Anwender in den Liefermodus setzt.
4. Beim Benutzen des Anforderungsmodus greift ein Anforderer auf die LPL-Liste durch Buchstabieren eines vollständigen Produktnamens über das Telefon in den LPL-Computer zu. Da der LPL mit einer Spracherkennung ausgestattet ist, erkennt er die Anforderung (31) und prüft (32), ob der Preis in seiner Datenbank zu finden ist.
5. Der LPL registriert die Uhrzeit der Anfrage (33).
6. Findet der LPL unter dem Produktnamen keine Liste von Geschäften und Preisen, prüft er, ob der Preis bereits angefragt wurde (34). Ist dies nicht der Fall, speichert er die Anfrage (35), setzt den Anfrage-Zähler auf eins (36), berechnet die POE (37) und zeigt die POE an (38). Falls doch, wird die Anfrage erhöht (39), die POE berechnet (40) und die POE ausgegeben(38).
7. Findet der LPL unter dem Produktnamen eine Liste mit Geschäften und Preisen, sucht er nach dem niedrigsten Preis (41). Findet er mehr als ein Geschäft mit demselben niedrigsten Preis (42), findet er das Geschäft mit dem niedrigsten Preis, das zuerst eingegeben wurde (43) und gibt dieses Geschäft und dessen Preis aus (44). Findet er nicht mehrere Geschäfte, zeigt er das einzige Geschäft mit dem niedrigsten Preis an (44). Danach registriert er die für die Anfrage für den Anforderer fälligen Gebühren (45) und die Lizenzbeträge für den Lieferanten. Danach addiert er eins zum Anforderungsmeter hinzu (39), berechnet die POE (40) und zeigt die POE an (38). (Liefermodus)
8. Ein Lieferant greift auf den LPL im Liefermodus zu, und buchstabiert einen Produktnamen über das Telefon in den LPL. Die Spracherkennungsfunktion des LPL (50) registriert den Namen und gestattet dem Lieferanten, ein Geschäft und Preis einzugeben (51). 9. Der LPL registriert die Uhrzeit der Eingabe zusammen mit dem Geschäft und Preis (52).
10. Der LPL registriert die Anwenderidentifikationsdaten (53) zusammen mit Geschäft, Preis und Uhrzeit.
11. Der LPL prüft, ob es unter diesem Produktnamen eine Liste mit Geschäften und Preisen gibt (54). Falls nicht, erzeugt der LPL eine Liste und speichert die Daten in dieser Liste.
12. Existiert bereits eine solche Liste im LPL, prüft der LPL, ob das eingegebene Geschäft mit irgendeinem der Geschäfte in der Liste übereinstimmt (56). Falls nicht, werden Geschäft, Preis, Uhrzeit und Anwenderidentifikation in der Liste gespeichert (57). Falls doch, werden die gerade eingegebenen und registrierten Daten in der Liste an die Stelle der Daten des übereinstimmenden Geschäfts registriert (58). 13. Der LPL findet den niedrigsten Preis (59).
14. Der LPL prüft, ob es mehr als einen niedrigsten Preis gibt (60). Falls nicht, wird der einzige niedrigste Preis für die Ausgabe festgehalten (61). Falls doch, findet der LPL den als erstes eingespeisten niedrigsten Preis (62) und hält diesen für die Ausgabe fest (61).

Zusätzliche Funktionen

Eine SODB sollte mehr als die oben beschriebenen grundlegenden Funktionen umfassen. Einige nützliche Funktionen sind nachstehend beschrieben.

Abgleichsfunktionen

Die SODB ist eine Abgleichsmaschine im zweifachen Sinn, beide von ihnen kritisch. Sie gleicht erstens Fragen (Datenanforderungen) ab und zählt, wie oft dieselbe, übereinstimmende Frage gestellt wurde. Sie gleicht zweitens Antworten mit Fragen ab. Bei beiden Abgleichsarten können Probleme auftreten, die mit der Art der Sprache und der Art der Fragen und Antworten selbst zusammenhängen. Daher sollte die SODB Funktionen besitzen, die die Chance eines besseren Abgleichs erhöhen. Beispiele für solches Vorgehen sind beste Abgleichsalgorithmen.
a) Unendlich viele Arten, dieselbe Frage zu stellen Es gibt viele, tatsächlich sogar unendlich viele, Arten, dieselbe Frage zu stellen. Zwei Fragen, die dieselbe Bedeutung haben, können ggf. nicht abgleichbar sein, weil sie in unterschiedlicher Form gestellt werden. So ist es das Ziel der SODB, zu versuchen, Fragen mit derselben Bedeutung in dieselbe Form zu bringen. Die SODB kann hierzu eine Funktion enthalten, die einen Anforderer durch eine Eingabestruktur führt, so dass die Anforderer eine bessere Chance haben, Fragen in einer abgleichbaren Form zu stellen, wenn die Fragen dieselbe Bedeutung haben. Diese Struktur ist am einfachsten bei einfachen Fragen, wie z. B. "Welche Telefonnummer hat John Smith?". Ein Anforderer kann einfach den Namen "John Smith" eingeben, der natürlich mit anderen Eingaben auf "John Smith" übereinstimmen würde. Dieses Beispiel führt uns zum nächsten Problem.
b) Fragen können mehrere, möglicherweise sogar unendlich viele Antworten haben
Um eine Antwort auf eine Frage abzugleichen, muss es eine einzige Antwort geben. Dennoch ist die Phrase "eine Antwort", wie oben bereits erwähnt, nicht klar definiert. Eine Antwort kann mehrere Komponenten haben. Beispiel: Die Frage "Wie lautet Johns Telefonnummer?" kann eine Antwort haben, die mehrere Nummern umfasst, weil John vielleicht mehrere Telefonnummern besitzt. Dennoch könnte die Antwort immer noch als einzige Antwort gelten, da die Nummern derselben Person, John, gehören, wonach der Anforderer ja gefragt hatte. Der Anforderer will jedoch nicht mehrere Nummern verschiedener Leute mit demselben Namen haben. Eine Person z. B., die "John Smith" eingibt, um eine Telefonnummer zu finden, kann so Hunderte von Telefonnummern erhalten. Tatsächlich können alle Fragen mehrere Antworten haben, sogar scheinbar spezifische Fragen, wie z. B. "Wieviel wiegt John in Pfund?". Die Antwort könnte 150 oder 150,11 oder 150,1111 lauten, und dann würde die Antwort immer noch davon abhängen, wann er gewogen wurde, mit was für einer Skala, usw. Um die Antwortmöglichkeiten einzuschränken, verwenden wir implizite Standardannahmen, von denen wir einige in unseren Datenbanken einbauen. Zusätzlich zu diesen Annahmen ist ein weiterer Schlüssel zum Einschränken der möglichen Antworten, genügend Informationen in einer Frage zu spezifizieren, so dass die Wahrscheinlichkeit einer einzigen Antwort steigt. Details, wie der vollständige Name, Ort, Identifikationsnummer, Uhrzeit, Informationsquelle, usw. können die möglichen Antworten auf eine reduzieren. Die SODB kann eine Funktion umfassen, die den Anforderer dazu auffordert, die Frage genauer zu stellen. Die SODB kann ebenfalls eine Funktion enthalten, die eine Antwort aus einem Satz von gleichwertigen Antworten heraussucht. Beispiel: Die Antwort auf die Frage "Wo gibt es den niedrigsten Preis für eine bestimmte CD?" kann mehrere Orte auflisten. Die SODB kann eine davon nach dem Zufallsprinzip auswählen.

Qualitätskontrollfunktionen

Die Qualitätskontrolle der Antworten ist in der SODB wesentlich. Die SODB kann viele Funktionen haben, die Anreize und Sanktionen bieten, um Lieferanten dazu zu ermutigen, genaue Antworten zu liefern. Ein allgemeiner Anreiz ist, dass eine korrigierte Antwort eine falsche ersetzen wird und dem Lieferanten Lizenzbeträge einbringt. Die SODB kann Regeln haben, die eine falsche Antwort definieren, aber diese Regeln können nicht alle Situationen abdecken. Es kann zu Streit darüber kommen, ob Antworten korrekt sind, und diese Diskussionen müssen ausserhalb des Systems durch den Manager der SODB geschlichtet werden. Einige Qualitätskontrollfunktionen sind nachstehend aufgeführt.
a) Die SODB kann eine Funktion enthalten, die Identifikationsinformationen über eine Antwort speichert, z. B. die Lieferzeit und die ursprüngliche Quelle (die ursprüngliche Quelle und der Lieferant müssen nicht notwendigerweise ein- und derselbe sein).
b) Die SODB kann eine Funktion enthalten, die den Anwendern gestattet, ein Vorbringen einzugeben, dass eine Antwort falsch ist, und dieses Vorbringen dem Manager zuzusenden.
c) Ein Anwender - Anforderer oder Lieferant - kann die Behauptung vorbringen, dass eine Antwort mit Absicht falsch geliefert wurde. Die SODB kann eine Funktion enthalten, die einem Anwender gestattet, dieses Vorbringen aufzunehmen und dem Manager zuzusenden.
d) Die SODB kann eine Funktion enthalten, die es dem Anwender gestattet, zu beantragen, dass ein Manager eine Antwort überprüft. Die Funktion kann ebenfalls eine Gebühr für diese Überprüfung erheben.
e) Die SODB kann eine Funktion enthalten, die es dem Manager gestattet zu registrieren, dass eine Antwort falsch ist und diese falsche Antwort dem Lieferanten zu registrieren.
f) Die SODB kann eine Funktion enthalten, die eine Aufzeichnung von den falschen Antworten erstellt, die ein Lieferant eingeliefert hat. Diese Funktion kann auch einen Lieferanten disqualifizieren, der zu viele falsche Antworten eingegeben hat.
g) Die SODB kann eine Funktion enthalten, die Lieferanten Geldbeträge oder Strafen für die Lieferung falscher Antworten berechnet.
h) Die SODB kann eine Funktion enthalten, die einen Anwender belohnt, der entdeckt, dass eine Antwort falsch ist. Eine solche Funktion kann dem Lieferanten der falschen Antwort Strafgebühren berechnen und diese Strafgebühren dem Entdecker der falschen Antwort auszahlen.
i) Die SODB kann eine Funktion enthalten, die Lieferanten für die Aktualisierung der Anworten bezahlt. Nennen wir einen solchen Lieferanten einen Aktualisierer. Ein ursprünglich korrekt eingegebener Preis kann z. B. veraltet sein. Ein Anwender, der dies feststellt, kann für die Korrektur dieser Antwort bezahlt werden. Der Anwender würde die Lizenzbeträge erhalten, die für diese neue, korrekte Antwort errechnet wurden. Dennoch kann es vorkommen, dass eine geänderte Antwort keine Lizenzbeträge erbringt. Dies gilt vor allen Dingen bei Preisen und anderen zeitabhängigen Angeboten. Beispiel: Die Antwort auf die Frage "Wer verkauft HP Drucker zum niedrigsten Preis?" kann sich ändern. Der Aktualisierer könnte herausfinden, dass die derzeitige Antwort in der SODB falsch ist. Aber der Aktualisierer mag nicht in der Lage sein, die richtige Antwort zu liefern. Diese könnte durch einen anderen Lieferanten geliefert worden sein. Für solche Fälle kann die SODB eine Funktion enthalten, die dem Aktualisierer einen Anteil an den Lizenzbeträgen bezahlt, die für den Lieferanten der neuen oder/und alten Antwort bestimmt sind. Oder die SODB kann dem Aktualisierer eine anderweitige Gutschrift, z. B. kostenlose Antworten, erteilen.
j) Um zu betrügen, könnte eine Person einen Verbündeten haben, der eine korrekte Antwort in eine falsche umändert. Die Person würde dann die richtige Antwort erneut eingeben und Lizenzbeträge einfordern. Die SODB kann eine Funktion enthalten, die dem Lieferanten einer früheren Antwort Lizenzbeträge auszahlt, falls eine Antwort innerhalb eines bestimmten Zeitraums geändert und dann wieder in den früheren Zustand zurückversetzt wird, vorausgesetzt, dass die frühere Antwort korrekt war. Mit statischen Fakten, wie z. B. dem Geburtstag einer Person oder der Lichtgeschwindigkeit, kann die erste Person, die die genaue Antwort eingibt, normalerweise alle Lizenzbeträge einfordern. Mit sich ändernden Fakten, z. B. von Preisen, kann der Zeitraum für das Zulassen einer erneuten früheren Antwort je nach Situation variieren.
k) Die SODB kann eine Funktion enthalten, die Antworten "bestätigt", indem sie sicherstellt, dass sie den Anforderern ausgegeben wurden, nachdem sie von mehr als einem Lieferanten eingegeben wurden.
l) Die SODB kann eine Funktion enthalten, die es den Lieferanten gestattet, ihre Antworten erst nach Eingabe eines Passworts einzugeben.
m) Bei Sprachzugriff auf die SODB kann es eine Funktion geben, die die Stimme des Lieferanten zu Identifikationszwecken aufzeichnet.
n) Die SODB kann eine Funktion enthalten, die eine Audio- Aufzeichnung des Lieferanten bei Erhalt einer Antwort aus der ursprünglichen Quelle dieser Antwort durchführt. So kann z. B. ein Lieferant einen Preis aus einem Geschäft erhalten. Um sicherzustellen, dass das Geschäft sein Preis-Wort nicht bricht, kann der Lieferant das Gespräch aufzeichnen wollen. So kann die SODB eine Anrufweiterschaltungsfunktion enthalten, bei der der Lieferant über die SODB anruft und die SODB den Lieferanten mit dem Geschäft verbindet und ferner das Gespräch aufzeichnet. Um die Kosten für die Aufzeichnung zu reduzieren, kann die Aufzeichnung nach dem Zufallsprinzip durchgeführt werden.

Datenlöschfunktion

Die SODB kann eine Funktion enthalten, um "Treibholz" durch Löschen von Antworten, Rohdaten, Datenanforderungen und -nutzungen, deren Anforderungsrate zu niedrig geworden ist, zu entfernen. Die SODB kann z. B. automatisch jede Antwort oder jede Frage löschen, die innerhalb eines bestimmten Zeitraums nicht angefordert wurde.

Nutzergebührenfunktionen

Um die Kosten auszugleichen und eine sinnvolle Nutzung anzuregen, kann die SODB eine Funktion haben, die den Anwendern Gebühren für die Verbindungszeit, Speicherung von Antworten und jede weitere beliebige Nutzung der Datenbank berechnet.

Abrechnungsmeterfunktion

a) Ein Anwender mag es vorziehen, die POE nicht automatisch ausgegeben zu bekommen, sondern nur auf Anfrage. Daher kann der POM eine Funktion enthalten, die dem Anforderer gestattet, die POE anzufragen.
b) Eine Funktion kann dem POM hinzugefügt werden, die nicht nur die Honorarschätzung mitteilt, sondern auch eine geschätzte Rate pro Stunde. Die Auszahlungsformel müsste eine Schätzung der Zeit beinhalten, die es dauert, die notwendigen Daten einzugeben. Aus dieser Schätzung folgt die Schätzrate pro Stunde.
c) Die Auszahlungsformel kann eine zweite POE errechnen, die ein Prozentsatz der ursprünglichen POE ist und als Referenzgebühr bezeichnet werden kann. Diese Gebühr würde einer Person, dem Referenten, bezahlt, der einen Lieferanten auf die Eingabe einer Antwort aufmerksam gemacht hat. Diese Funktion würde einem Lieferanten gestatten, den Namen des Referenten einzugeben. Die Funktion würde dann sowohl dem Lieferanten als auch dem Referenten Lizenzbeträge gutschreiben. Diese beiden würden sich im Normalfall die ursprünglichen Lizenzebträge teilen.
d) Die Auszahlungsformel kann das Honorar pro Antwortkomponente berechnen. Es gibt unendlich viele Möglichkeiten, einer Komponente einen Wert zuzuordnen. Die Auszahlungsformel könnte z. B. einfach die POE nehmen und diese durch die Anzahl der Antwortkomponenten dividieren. Die SODB hätte ebenfalls eine Funktion, die diese Komponenten zählt.

Anforderer-/Lieferanten-Funktionen

a) Ein Anforderer möchte vielleicht bestimmte Daten nicht liefern, weil ein anderer Anforderer ihn übertrumpfen könnte. Die SODB könnte daher eine Funktion enthalten, die ein Eingaberecht reserviert. Der Anforderer könnte einen Befehl eingeben, z. B. RESERVIEREN, des Anforderers nachdem er die POE für diese Daten gehört hat. Die Funktion würde die Identifikation zusammen mit der Frage des Anforderers speichern. Danach würde die SODB für einen bestimmten Zeitraum nur diesem Anforderer die Eingabe der erforderlichen Daten gestatten. Diese Funktion würde anderen Anwendern mitteilen, dass diese Daten für einen bestimmten Zeitraum reserviert sind.
b) Ein Anforderer, der zum Lieferanten wird, möchte vielleicht eine Frage nicht erneut eingeben, die er bereits gestellt hat, als er sich noch im Anforderungsmodus befand. Die SODB kann daher eine Funktion enthalten, durch die der Anforderer im Anforderungsmodus einen Befehl, z. B. "WERDE LIEFERN", eingeben kann, nachdem er die POE für die Antwort gehört hat. Die Funktion würde die Identifikation des Anforderers zusammen mit der Frage speichern. Wenn der Anwender sich im Liefermodus befindet, würde die Funktion auf einen Befehl hin, z. B. VORHERIGE, die letzte Frage nachschlagen, die der Anwender gestellt hat. Die durch den Anwender eingegebenen Daten würden dann entsprechend der Frage gespeichert.
c) Ein Anwender, der vorhat, ein Anforderer zu werden, kann in den Liefermodus gehen, um dort zu überprüfen, ob eine Antwort in der SODB vorhanden ist. (Ein Anwender kann prüfen, ob eine Antwort vorhanden ist, indem er den Anforderungs- oder Liefermodus benutzt.) Ist die Antwort vorhanden, kann die SODB eine Funktion enthalten, die dem Anwender das automatische Umschalten zwischen den Modi durch einen einzigen Befehl gestattet und die Antwort automatisch ausgegeben und dem Anwender die Gebühren belastet. Diese Funktion scheint trivial zu sein, doch verbirgt sich ein wichtiger Aspekt dahinter. Die SODB ist ein Rückmeldesystem, das sich von anderen Datenbanken dadurch unterscheidet, dass es eine enge Rückmeldungsschleife aufweist, basierend auf Lizenzbeträgen als Anreiz für Anwender, die normalerweise für das Erhalten von Daten bezahlen müssten. Bei bestimmten Datenbanken können Lieferanten, die nicht für das Erhalten von Daten bezahlen, die möglichen Lizenzbeträge für ein Datum überprüfen. Doch bei der SODB wird diese Auszahlungsinformation erstmalig den Anwendern direkt zugänglich gemacht, die Daten suchen und für deren Nutzung bezahlen müssen, wenn diese in der Datenbank enthalten sind. Diese Tatsache macht einen grossen Unterschied aus, da so ein engmaschiges, effizientes Rückmeldesystem entsteht, das völlig neuartig ist.

Zahlungsfunktionen nach Wahrscheinlichkeit

Wenn Gebühren und Lizenzbeträge für Daten niedrig sind, ist es von Vorteil, ein erwartetes Wertauszahlungsverfahren (EVPM) zu verwenden. Ein EVPM wird in den Patenten mit den Nummern 5,085,435 und 5,269,521 beschrieben. Nähere Erläuterungen s. diese beiden Patente.
Die Hauptfrage bei einem EVPM ist, wie man gerechte Gebote sicherstellt. In diesem Fall entstehen diese zwischen der SODB und ihren Anwendern, sowohl Anforderern, die Geld schulden, als auch Lieferanten, denen Geld geschuldet wird. Wir nehmen den Fall der Anforderer, die Geld schulden. Die involvierten Grundsätze können auf die Lieferanten ausgedehnt werden. Verfahren zur Betrugsprävention werden in den oben genannten Patenten beschrieben. Zwei Beispiele von Verfahren zur Betrugsprävention, die für die SODB anwendbar sind, werden nachstehend aufgeführt.
Zahlenspielmethode: Beim illegalen Zahlenspiel wurden die Ergebnisse oftmals durch eine Zahl bestimmt, z. B. die letzten drei Ziffern am Griff der Bahn. Jeder, der diese Zahl zog, gewann. So entschied eine Zahl über Tausende von Wetten. Die SODB kann auf eine ähnliche Art EVPM-Wetten für jeden Anforderer festsetzen. Die Gebühren, die an einem Tag registriert werden, können durch die täglichen Lottozahlen des nächsten Tages festgesetzt werden. Nehmen wir z. B. an, die Einsätze liegen an einem Tag bei $10,00. Der Einsatz wird dann durch die letzten drei Ziffern der täglichen Lottozahlen bestimmt (s. EVPM Patent). So registriert das Zahlungsregister die Gebühren, die für die Anforderer während eines Tages anfallenden Gebühren.
Am nächsten Tag werden die täglichen Lottozahlen bekannt gegeben. Das Zahlungsregister nimmt diese Zahlen und setzt sie für jeden Einsatz, den die Anforderer am Vortag gemacht haben, um.
Das einzige Problem bei einer solchen Methode ist, dass es dadurch zu extremen Schwankungen kommen kann. Nehmen wir z. B. an, dass an einem Tag die Gebühr bei 10 Cents liegt. Die SODB hat so nur eine einprozentige Gewinnchance, wenn der Einsatz bei $10 liegt. Daher besteht eine 99%ige Chance, dass die SODB gar nichts bekommt und eine einprozentige Chance, das Hundertfache davon zu bekommen. Um das Einkommen auf einem gleichbleibenden Niveau zu halten, könnte das Zahlungsregister jedem Anforderer zusätzlich zu den Lottozahlen eine weitere Zahl zuordnen, die den Lottozahlen hinzuaddiert würde. Diese zusätzliche Zahl könnte z. B. Teil der Anwenderidentifikation des Anforderers sein. Diese zusätzlichen Zahlen wären zufällig oder annähernd so geordnet, dass sich Gewinn und Verlust die Waage halten könnten. Solange die Anforderer einer zusätzlichen Zahl zustimmen, bevor die Lottozahlen bekannt gegeben werden, ist alles gerecht.
Messverfahren nach Wahrscheinlichkeit: Normalerweise gibt es immer eine Messkomponente für die Nutzung und die letztendliche Bestimmung von Gebühren, wenn Personen eine Online-Datenbank, ein Telefonsystem oder überhaupt ein nutzungsorientiertes System benutzen. Bei der SODB ist diese Messkomponente das Zahlungsregister. Dennoch kann es sehr teuer sein, Gebühren zu registrieren und dann eine Rechnung dafür zu erstellen. Daher wäre es von Vorteil, die Messungen mit einer EVPM auf einer Wahrscheinlichkeitsbasis durchzuführen. Das Meter könnte z. B. während 90% der Zeit ausgeschaltet sein, doch nach dem Einschalten wären die Gebühren zehnmal so hoch wie normal. Die Zeiten, zu denen das Meter ein- und ausgeschaltet ist, werden durch eine zufälligen Zahlengenerator bestimmt, der eine Zahl auswählt, hier von 1 bis 10.
Das Zahlungsregister der SODB kann eine Messfunktion nach Wahrscheinlichkeit (PMF) enthalten, die die Zeiten, an denen die SODB Gebühren von den Anforderern registriert (und die Lizenzgebühren für die Lieferanten registriert), zufällig bestimmt. Diese Funktion wird nachstehend beschrieben.
1. Ein Zeitraum wird in Unter-Zeiträume unterteilt. Ein Tag kann z. B. in Minuten unterteilt werden.
2. Die Wahrscheinlichkeit, dass das Meter während eines bestimmten Unter-Zeitraums eingeschaltet ist, wird durch den SODB bestimmt.
3. Jeder Unter-Zeitraum ist einer zufälligen Zahl zugeordnet, die bestimmt, ob das Meter während dieses Zeitraums ein- oder ausgeschaltet wird. Die Zahl wird durch einen Zufallszahlengenerator derart ausgewählt, dass die Wahrscheinlichkeit, dass das Meter eingeschaltet ist, der Wahrscheinlichkeit entspricht, die der SODB- Manager festgesetzt hat. Mit jedem Unter-Zeitraum mit einer ausgewählten Zufallszahl wird eine Sequenz oder Liste von "An" und "Aus" erzeugt. Diese Liste wird in die PMF eingegeben.
(Die Liste wird von einer unabhängigen Quelle bereitgestellt, die die Zahlen erzeugt. Die Unabhängigkeit der Quelle ist nowendig, um festzustellen, ob die Sequenz der SODB gerecht ist oder nicht.)
5. Die PMF enthält eine Uhr und eine Unterfunktion, die bei Erreichen jedes Unter-Zeitraums der Uhr die Liste überprüft, um zu bestimmen, ob das Meter ein- oder ausgeschaltet werden soll. Die Unterfunktion schaltet das Meter gemäss der Ein/Aus-Liste ein oder aus.
6. Die Uhr wird mit einer unabhängigen Uhr synchronisiert, um Gerechtigkeit zu gewährleisten.
7. Wenn das Meter eingeschaltet ist, registriert der Zahlungsregister die Gebühren und multipliziert sie mit der umgekehrten Wahrschein lichkeit, mit der das Meter eingeschaltet ist. So erreichen die Gebühren das Zehnfache der normalen Gebühren, wenn das Meter während einem Zehntel der Zeit eingeschaltet ist.
Messungen nach Wahrscheinlichkeit mit diesem Verfahren bieten einen wirksamen Weg zur Sicherstellung von gerechten Gebühren, aber auch einen Weg, um die Gewinne und Verluste von Einsätzen auszugleichen. Es gestattet - was vielleicht noch wichtiger ist - den Anforderern, nur dann ihre Identifikation einzugeben, wenn sie verlieren. Es gibt keinen Grund, die eigene Identifikation einzugeben, wenn man ohnehin nicht bezahlen muss. Daher wird die Eingabe der Identifikation aus dem Startmodus entfernt. Das kann für Anwender, die es eilig haben, von Vorteil sein. Es bedeutet, dass sie ihre Identifikation zu Rechnungszwecken nur dann eingeben müssen, wenn sie ihren Einsatz verloren haben. Natürlich könnten Anwender nicht bezahlen, wenn sie sich nicht identifiziert haben. Dennoch ist es neben der Ehrlichkeit möglich, die Stimme des Anforderers aufzuzeichnen, z. B. falls die SODB sprachgesteuert ist, um Beweise zum Aufspürendes Anforderers zu erlangen. Wird die SODB durch Coputer angesprochen, kann der Computer zurückverfolgt werden.

Claims

1. Datensammel- und Datenwiedergewinnungssystem für eine selbstorganisierende Datenbank, umfassend in Kombination die folgenden Elemente und Schritte:

einen Computer mit:

- einem Eingabemittel für die Eingabe von Datenanforderungen und Daten, welche den Datenanforderungen entsprechen, sowie anderen Daten, wie zum Beispiel Anwenderidentifikationsinformationen,

- einem Ausgabemittel für die Ausgabe der Daten sowie anderer Daten, wie zum Beispiel geschätzte Lizenzgebühren,

- ein Speichermittel zum Speichern der Datenanforderungen und Daten,

- ein Prozessormittel für den Vergleich der Datenanforderungen, das Ausführen der Nachschlageoperationen, das Registrieren von Eingabezeiten, das Berechnen von Formeln und das Registrieren von Gebühren und Zahlungen, die von den Anwendern zu entrichten sind,

wobei der Computer bei der Eingabe einer Datenanforderung durch einen Anwender die folgenden Schritte ausführt:

a. er registriert die Identifikationsinformationen des Anwenders (1),

b. er registriert, ob ein Anwender gemäss der Datenanforderung Daten zur Verfügung stellen oder Daten abrufen will (2),

c. führt, wenn der Anwender Daten (15) zur Verfügung stellen will, eine Nachschlageoperation aus, um zu prüfen, ob sich die Daten, welche der Datenanforderung entsprechen, bereits im Speicher befinden,

c1. gibt, wenn entsprechende Daten gefunden werden, eine Meldung (19) aus, die dem Anwender mitteilt, dass sich die Daten bereits im Speicher befinden,

c2. erlaubt, wenn keine entsprechenden Daten gefunden werden, dem Anwender die Eingabe der Daten, speichert die Daten so, dass sie der Datenanforderung entsprechen (17), und registriert, dass dem Anwender ein Honorar zusteht, wenn die Daten angefordert werden (18),

d. wenn der Anwender Daten (3) gemäss der Datenanforderung anfordern will,

d1. registriert die Zeit und das Datum, an dem die Datenanforderung eingegeben wird (4),

d2. führt eine Nachschlageoperation aus, um zu prüfen, ob Daten, welche der Datenanforderung entsprechen, im Speicher vorhanden sind (5),

d2a. gibt, wenn entsprechende Daten im Speicher vorhanden sind, die Daten aus, registriert eine Gebühr, die vom Anwender zu bezahlen ist, der die Datenanforderung eingegeben hat, und eine Lizenzgebühr, die an jenen Anwender zur Auszahlung kommt, der die Daten zur Verfügung gestellt hat (7), fügt der Zahl der Datenanforderungen eins hinzu, berechnet eine Auszahlungsformel, welche die geschätzten Lizenzgebühren für einen Anwender, der die richtigen Daten entsprechend der Datenanforderung eingibt, vorhersagt, und gibt den geschätzten Lizenzbetrag aus (10),

d2b. prüft, wenn keine entsprechenden Daten im Speicher vorhanden sind, ob die Datenanforderung bereits im Speicher gespeichert ist (11),

d2b1. speichert, wenn dies nicht der Fall ist, die Datenanforderung (12) und setzt die Nummer der Datenanforderungen auf eins, und berechnet die geschätzte Lizenzgebühr,

d2b2. fügt, wenn ja, eins zur Zahl der Datenanforderungen hinzu (5) und berechnet die Lizenzformel,

d2b3. gibt das Ergebnis der Lizenzgebührschätzung (10) aus.