WO1996025709A1

WO1996025709A1 - A data collection and retrieval system for registering charges and royalties to users

Info

Publication number: WO1996025709A1
Application number: PCT/US1996/001699
Authority: WO
Inventors: Michael T. Rossides
Original assignee: Rossides Michael T
Priority date: 1995-02-16
Filing date: 1996-02-15
Publication date: 1996-08-22
Also published as: AU4974696A

Abstract

A self-organizing data-base that charges (7) users who find data in it and pays (7) users who supply the data found. Has a built-in feedback mechanism, called the Pay-off Meter (11, 14), that tells users what data needs supplying based on the number of requests (13) for that data over time. The Pay-off Meter outputs a projected Pay-off (10) for supplying the data.

Description

A Data Collection and Retrieval System for Registering Charges and Royalties to Users

Field of the Invention

This invention relates to a fee supported data-base system for community use.

Background-The Prior Art

U.S. patent 5,359,508 disclosed a new type of data-base system. The novelty of the system centers around a loop of sorts in which the system registers information about the demand for given data. From this demand information, the system calculates a Pay-off Estimate that tells users, especially the Requestors of the data, the projected amount of income they might receive for entering the data into the system. Then once the data is entered, users who request it are charged and royalties are paid to the supplier.

The loop is a quite basic and can be built upon. Continuing U.S. application #08/327,704 added new matter in three areas. First, it described a new feature for displaying the pay-off estimates of certain kinds of data. Second, it described the collection of more information about the demand for a piece of data, particularly price information. Third, it described a form of the invention not envisioned in U.S. patent 5.359,508, in which the system does not actually collect and output data but collects and outputs pointers or reference information telling where the data can be found. A few other comments were added for clarification purposes but these did not disclose any novel matter. For example, means for checking the pay-off value for data were described but these means are obvious.

Since application #08/327,704 directly precedes this application, it is now called the parent. The specification of the parent has been copied into this application. U.S. patent 5.359,508, will be called the grandparent. Summary

The SODB is a data-base system that charges users who find data in it and pays users who supply the data found. It can be a single machine or a network. The key to the SODB is a built in feedback mechanism, called the Pay-off Meter, that tells users what data needs supplying based on the number of requests for that data. When a person requests a piece of data not in the SODB, the Pay-off Meter registers the request. Based on the rate of requests registered, this function estimates the royalties the data will generate once the data is supplied. The more requests in a period of time the greater the expected pay-off, provided the price is the same.

The key is that the expected pay-off is announced to each requestor of the data. The beauty is that each requestor may have to find the data anyway elsewhere. To collect the pay-off, a requestor has only to "call" the SODB back and input the answer. A sensitive and potent feedback loop is created insuring that the more a piece of data is requested, the more likely it will be supplied by a requestor or by someone a requestor tells of the pay-off. Moreover, this pay-off creates an incentive to correct or update faulty data.

Brief Description of the Drawings

Figure 1 shows a flow chart of a basic SODB.

Figure 2a shows the flow chart of the Request Mode of a lowest price locator.

Figure 2b shows the flow chart of the Supply Mode of a lowest price locator.

Figure 3 shows a flow chart of the steps preceding the gathering of information on what users are willing to pay for given data.

Figure 3a shows a flow chart of steps for gathering of information on what users are willing to pay for given data.

Figure 3b shows another set of steps for gathering of information on what users are willing to pay for given data.

Figure 3c shows another set of steps for gathering of information on what users are willing to pay for given data.

Figure 3d shows another set of steps for gathering of information on what users are willing to pay for given data.

Figure 4 shows how a price setting formula can feed into the pay-off formula.

Figure 5 shows a basic menu for a system that includes More Specific Questions.

Figure 6 shows another basic menu for a system that includes More Specific Questions.

Figures 7 and 7a show how a direct answer might be relabelled.

Figures 8-8b show a flow chart of steps for a system with More Specific Questions. Figures 9 and 9a show additional steps for getting and entering More Specific Questions.

Figures 10-lOd show steps for creating question and answer nets using More Specific

Questions.

Figure 1 1 shows a menu of options that includes additional kinds of questions.

Figures 12 shows a flow chart of of steps for a multi-lingual system.

Figure 13 shows a flow chart of steps for registering requests for answers in specific langauges.

Description

The SODB is a data-base system that charges users for the data they receive and pays royalties to users who input that data. What differentiates the SODB from other data-bases is a function that tells users who request data what the estimated royalty value is for supplying the data. The function keeps track of the rate of requests for the data and from this rate projects a demand rate. The estimated demand multiplied by the royalty rate yields a projected royalty stream. If a person requests a piece of data that is not in the SODB, the SODB outputs the projected value of inputting the data. (If the person finds the data answer is in the SODB, the SODB still can output the projected royalties for improving, correcting or updating the data.) Then, if necessary, the SODB tells users how to input the data. In sum, the SODB is a powerful feedback system that tells users what data needs supplying, tells them the financial incentive to supply it, tells them how to supply it and then pays them for supplying it.

Some Definitions and Comments

Start Mode: The procedure the SODB executes to allow users to access the SODB and choose between the Request and Supply Modes. Start Mode is not strictly necessary as long as its "logging on" functions are part of the Request and Supply Modes.

Request Mode: The procedure the SODB executes to provide answers and/or Pay-off estimates to Requestors. In the Request Mode, a user inputs a question causing the SODB to search for the corresponding answer. If the answer is not found, a Pay-off Estimate is outputted. If the answer is found, the answer is outputted along with the Pay-off Estimate (see Pay-off Meter) and a Charge is registered to the user. Supply Mode: The procedure the SODB executes to allow users to input answers, potential answers and raw data. User identification data is registered along with the inputted data so that the user can be credited with royalties each time the data is used to supply answers.

Requestor: User who accesses the SODB by Request Mode seeking an answer. The Requestor owes a Charge if the answer is found.

Supplier: User who enters the Supply Mode to input an answer or raw data. The Supplier gets paid a Royalty each time the answer or the raw data is used by the SODB as determined by the royalty rules of the SODB.

Check Mode: The procedure the SODB executes to allow users to check the Pay-off Estimate given data. In this mode, a user is neither a Requestor nor Supplier though the Check Mode could be accessed through either the Request or Supply Modes.

Charge: The amount owed by a Requestor who receives an answer from the SODB.

Royalty Rules: The rules, embodied in functions, that determine the amount due to a Supplier of an answer (or of the raw data that is necessary for an answer), each time that answer is outputted to a Requestor.

Payments Register: The function the SODB executes to register payments owed by Requestors and payments due Suppliers. When an answer is outputted, the Payments Register registers who is owed a royalty and who owes a charge for the data used. What the Payments Register registers depends on the royalty rules of the SODB.

Question: Specific data corresponding to other specific data called the answer. When entered into the SODB by a Requestor, causes the SODB to search for the corresponding answer.

Answer: Specific data corresponding to other specific data called the question. An answer may be static, for example, the chemical structure of gasoline does not change. It may be dynamic, for example, the price gasoline does change. And, it may be improvable as well, for example, the octane of gasoline may be more accurately given. An answer may be long or short. It may have one component or many. For example, the question, "What are the Chinese restaurants in Biloxi?" may yield one restaurant or many.

The Correspondence Between a Question and Its Answer: There can only be one answer for any question, though that answer may have many components. Of course, a question may have multiple, even infinite, answers. But, the SODB requires rules that limit the answers to one, in the following sense: the answer to a question must be a finite set of data that is outputted to the requestor and charged for. The answer is what the requestor pays for. (A big problem in defining "answer" is that no one has come up with a good definition yet.) In the SODB, users input the answers they deem best. And users police the accuracy of those answers. The SODB accepts untrue or approximate answers, for it cannot divine meanings and truth, but any answer is displaced by a better answer. A better answer is one that, by convention and by the rules of the SODB, satisfies a question better than the existing answer. A user may displace one answer with another. If there is a dispute between users as to which answer is better, a neutral third party, the Data-Base Manager can be alerted to settle the dispute.

Of course, with many types of questions, whether an answer is "better " is not clear by convention. There may be many, even an infinite number of equally good answers. So, depending on the type of question, the SODB rules must limit the possible answers. One rule, for example, may be that the first answer inputted is considered better than all equivalent answers. However, no set of rules can capture truth and therefore, the manager, has final authority to decide whether an answer is true or not and whether one answer is better than another. See also Quality Control Functions below.

Potential Answer: An answer that may become the best answer in the SODB to a question.

Raw Data: If it has the requisite functions, the SODB can process raw data to arrive at answers. A piece of raw data may itself be considered the answer to a question. For example, the question, "What is the closest McDonalds to 1234 Main Street?," might require the SODB to have map coordinates for 1234 Main Street. Therefore, the coordinates are raw data. And, the coordinates themselves are the answer to the question, "What are the coordinates of 1234 Main Street?." Any answer for one question may be raw data for answering other questions. (The distinction is largely artificial between data that is by itself an answer and "raw data" that is used in calculating an answer. The distinction is artificial because "raw data" usually answers at least one question by itself. We will keep this term for now but probably improve on it in a future application.)

Storing Answers: Usually, the SODB simply lists an answer under the question it answers. The answer can then be accessed by simple lookup. Answers can also be stored as raw data that is processed.

Data-Request: Any search for data initiated by a Requestor inputting a question. An infinite variety of searches can be done for data including searches that invoke functions to yield data. A data-request and a question can be considered synonyms. (By infinite searches we mean that there are infinite possible questions which can involve infinite different operations for finding or arriving at answers.)

Classifying a Data-Request: The SODB classifies data requests in order to differentiate between them and count them. However, as in any classification system, arbitrary rules must be established. SODB's classification of requests can therefore be infinitely variable.

Data-Use: When the SODB uses a piece of data as an answer or to arrive at an answer. Data- uses broadly fall into two types: a) outputting the data as an answer or as part of an answer, b) plugging the data into an algorithm that outputs the answer.

Classifying a Data-Use: As there are infinite algorithms and infinite types of answers, there are also infinite uses of data. The SODB has rules to classify these uses for the purpose of tallying the uses and paying royalties. For example the use of pi may be given a different royalty value than the use of the date of Lincoln's Birthday or the use of a passage from Shakespeare. As in classifying data-requests, there are no hard and fast rules.

Pay-off Meter (POM): The function that is the heart of the SODB. The POM has three sub- functions:

1 ) The Demand Meter (D-Meter) which tallies Data-Requests and Data-Uses over time to come up with an estimated demand rate for an answer (or for a piece of raw data),

2) The Pay-off Formula (POF) which takes the demand rate and calculates a Pay-off Estimate (POE) of the income a user will get for inputting the answer (or the data),

3) Input Signal (I-Signal) which outputs the POE and tells the answer (or the data) that may need inputting and, if necessary, instructions on how to input the answer (or the data).

The POM works most simply when the SODB's answers are listed under questions and the SODB can find the answers by simple lookup. For example, a Requestor may input the questions, "What is Lincoln's date of birth?." The SODB will do a lookup. Initially, the answer will not be in the SODB. The SODB will then store the question and tally each lookup. The SODB will also register the time of each lookup so that the rate of lookups over time will be known. The rate of lookups (the demand rate) for the answer will be fed into the POF to yield the POE. The I-Signal outputs this POE to every Requestor. Since answers are listed under questions, the I-Signal need not tell what answer need inputting nor how to input it. It is assumed that Requestors implicitly know that to enter an answer, they simply access the Supply Mode, enter the question and then enter the answer. Once the answer is inputted, the D- Meter still keeps track of the demand rate because the answer may be wrong. The POM is then still able to provide Requestors with the POE for correcting the answer.

When the SODB simply looks up answers, data-requests and data-uses can be measured by tallying lookups. The SODB can get more complicated though because the classification of data-requests and data-uses can get complicated. Furthermore, the demand rate can take into consideration prices of data as well. POM functions are discussed below, taking into account the issue of classifying data-requests and data-uses but not the issue of the pricing of data.

Demand Meter (D-Meter): The function that tallies data-requests and data-uses along with the time they take place in order to calculate the demand rate for a piece of data.

The D-Meter tallies: a) data that is specifically searched for by name and not found. For example, a user may request a businesses phone number which is not in the SODB. This data-request can be tallied under the business' name; b) data that is used but not specifically searched for by name. For example, a user may request the average price of airline tickets to Boston. Dozens of prices may be fed into an averaging function to answer this request. Each of these prices is used but has not been specifically requested by name. c) data that is searched for by name and used (found). In these cases, the D-Meter only counts once. It does not count both the search and the find.

As discussed above, there can be an infinite variety of ways of classifying data-requests and data-uses, therefore, the D-Meter itself can be infinitely variable.

The key to the D-Meter is that it tallies data-requests and data-uses for data that satisfies two conditions: royalties are paid on the data and users can be instructed to input the data. The point of the D-Meter is to measure demand for specific data so that the demand rate can be fed into the POF which then yields the value of inputting that data. There would be no point in tallying requests for data that could not be named and therefore not be inputted by users.

The D-Meter does not necessarily measure the demand for all types of data that may be input into the SODB. For example, it is important to note that the D-Meter cannot measure the demand for potential answers. But, by measuring the demand for actual answers, the D-Meter can give users an idea of what the potential value is of inputting a potential answer. An example will illustrate both this situation and the issue of classification. Assume the question inputted by a Requestor is, "What store has the lowest price on Sony Camcorder #1239?" Say there are 1,000 requests. Now it may be that ten stores have the same lowest price. What then is the demand for a given store? That depends on how the SODB classifies the answer. The SODB may have a rule that only the first store with the lowest price can be outputted as the answer. This store becomes the answer and all royalties go to the inputter of this store. The SODB in effect turns the data-request into, "What stores have the lowest price and which among them was entered first?" Of course, the Requestor does not care which was entered first but the SODB may have default assumptions built into it to limit the size and number of answers outputted. Therefore, all other stores, even though they have the same lowest price are only potential answers (the first store may change its price so that another store takes its place). An inputter of a store with the lowest price does not know whether that input will generate any royalties or not. There is no established demand for that store.

On the other hand, the SODB can have a rule, for example, that all stores with the same price are equally part of the answer so the answer then has ten components. The demand rate for the store with the lowest price can then, for example, be divided by the number of components to arrive at a demand rate for each component (this calculation may actually be part of the POF). The classifications can be even more complicated. The second store inputted may be considered different from the first, location of the store may matter, and so on. The point is that the D- Meter tallies according to what data receives royalties and that depends on how answers are classified and that can be infinitely variable.

(Here in this continuation, we will often substitute the term "demand record" for Demand Meter because the key idea is that demand information is stored and then sent to the POF. There may be intermediate functions which calculate a demand rate (and these can be called part of a "demand meter") but that is not the main point. The same functions can be incorporated into the POF. It is easier to think of the parts of the Pay-off meter as being storage of demand information, calculation of a pay-off estimate, and outputting of the pay-off estimate. In the grandparent the issue may have been confused by having the demand meter do calculations. Because this application is a combination of the grandparent and an addition of new matter, we will use both terms. A future application will be stick to one way of looking at the steps of storing demand information and calculating demand.)

Pay-off Formula (POF): The function that calculates a Pay-off Estimate (POE). The POF projects future demand for a piece of data based on the demand it has had in the past. Thus two variables are critical, N, the number of times the data has been requested and, T, the times those requests took place. Based on the rate of requests for a piece of data, the POF estimates how many future requests there will be and then multiplies that by a royalty rate to arrive at the POE. When a piece of data is already in the SODB, the POF uses the tally, N, of data-requests and data-uses as supplied by the D-Meter. (This point is elaborated on later in the text.)

Like any equation for a projection, the Pay-off formula can be infinitely diverse based on historical data and other factors. For example, the formula would include a historically based assumption of when demand would end. The POF may contain estimates not based on the actual demand rate for a specific piece of data but for pieces of data that are similar. Regardless of what historical assumptions are built into it, the POF is always a function of the demand rate. The values for N and T are plugged into the POF which has the royalty rate built in.

The royalty rate can, of course, be infinitely variable. There may be sliding scales for the royalty paid to an answer for example. And different data-requests and data-uses may have different royalty rates. (Technically, it is possible for the POF not to have a royalty rate and only calculate a projected request rate. In this case, the royalty rate would be known by users who could do their own calculations.) Also, the POF must have an arbitrary value for the POE when a piece of data has been requested zero times or one time. This value could be an amount or simply a message like, "POE unknown."

(Note: the SODB can include multiple Pay-off Formulas that apply to different types of data.)

I-Signal: The function that is the output part of the POM, the signal that tells Requestors what data is needed, what the value is of supplying it and how to supply it. When a Requestor requests an answer not in the SODB, the SODB outputs the POE. When a Requestor requests an answer that is in the SODB, the SODB outputs the answer and the POE for correcting, updating or improving it. (The POE may be outputted only upon request rather than automatically).

When the I-Signal outputs the POE it may also output the answer needed or the data needed. Usually, the answer needed is implicit from the question asked. If raw data is needed, the data needed may not be implicit from the question. In this case, if the SODB had the requisite functions for recognizing the data needed, the I-Signal might output the type of data needed as well. For example, "Need Answer to, 'What is the speed of light?' , POE: $2." Finally, if necessary, the I-Signal could output instructions on how to input the data.

The I-Signal may include an alert function whereby a user can enter ask to be told if the POE for an answer rises above a threshold amount. The I-Signal can then alert the user if the threshold is exceeded, for example by sending a message the the user's E-mailbox. 10

A basic SODB includes of the following elements and procedure as shown in figure 1:

SODB Elements

Computing means for executing SODB functions.

SODB Functions a) inputting, storing, deleting and outputting data. b)start mode c) request mode d) supply mode e) lookup f) registering charges g) registering royalties h) Pay-off Meter (POM)

SODB Procedure

Start Mode

1 ) User inputs user identification data, SODB stores it 1

2) User inputs supply or request command 1 , SODB accesses appropriate mode 2.

Request Mode

1) Requestor inputs a Question 3, SODB a)registers date-time of Request 4 b) executes a look-up 5.

2) If the SODB has the Answer, it a)outputs the Answer 6 b)registers a payment due by the Requestor 7 c)registers a royalty due to the Supplier 7 d)adds one to the number of requests for that question 8, calculates the POF 9 e)outputs POE 10. 3) If the SODB does not have the answer it invokes the POM function which a)checks if the Question is already stored in the Pay-off register 1 1 (has been asked before) al)if no, stores the Question 12, sets the number of requests for that question to one 13, calculates the POE using the POF 14 a2)if yes, adds one to the number of requests for that question 8, calculates the POE using the POF 9 b)outputs the POE to the Requestor 10.

Supply Mode

1) Supplier inputs a question 15, SODB executes a look-up 16 (this lookup is not counted as a data-request; only lookups in the Request Mode are so counted in the POM),

2) If the answer is not found, the supplier inputs the answer 17, SODB stores the answer to correspond with the question inputted and stores the Supplier ID data along with the answer 18, in order to credit the Supplier with a royalty each time the Answer is requested.

3) If the answer is found, the SODB outputs a message saying the answer is already in the

SODB 19, if the Supplier intends to correct the existing answer, the Supplier inputs a command such as, CORRECT 20, and the SODB allows the new answer to replace the old answer 17 and allow new supplier ID data to replace the old ID data as well 18.

(We should correct an oversight here from the parent. The parent did not mention that the the Supplier can enter an entirely new question into the SODB and then supply an answer to that new question. Thus in the procedure above, if the Supplier's question is new, the system would store the question. That these steps were omitted was an oversight but was also due to the fact that a user could enter a question in the Request Mode and then enter the answer in the Supply Mode. The only problem with this is that the answer would have a single, superfluous request tallied for it.)

These elements and procedure are the heart of the SODB. The SODB would usually include other useful functions. Before detailing some of them, an embodiment of the basic SODB is described, a self-filling telephone directory (the SFTD). Then an embodiment is described which does more than lookup answers under questions. 1. The SFTD includes a list of names and corresponding telephone numbers, initially empty, a computer for storing the list and functions for inputting data into the list, outputting data from the list and looking up data in the list.

2. The SFTD also has a sign-on function that allows users to identify themselves for billing and payment purposes. The SFTD stores the ED data.

3. Users access the SFTD over the phone. The SFTD computer is equipped with phone- interface equipment. The SFTD accepts calls from two lines, a Request line and a Supply Line. The Request line automatically puts users in the Request mode, while the Supply Line puts them in the Supply Mode.

4. Using the Request mode, a Requestor accesses the SFTD list by spelling a name over the phone into the SFTD's computer. Equipped with a speech recognition function, the SFTD recognizes the request and does a lookup. Equipped with a speech synthesizer, it then responds with a speech synthesized answer.

5. If the SFTD has a number corresponding to the name, it outputs the number and registers the charge due by the Requestor and the royalty due to the Supplier. One is added to the POM tally of data-requests, the time of the request is registered, and a new POE is calculated and outputted along with the number.

6. If not, the SFTD's POM is invoked and outputs a POE to the Requestor. The POM has several functions: a) it registers the time of the request, b) it checks if the request has already been stored in the POM register, c)if not, it sets the request tally to 1 , stores the request and defaults the POE to the message "Insufficient Data to Estimate Pay-off," d) if the request is already stored, the POM advances the request tally by one and then calculates the POE using the POF (let us assume for illustration's sake, the POF divides the number of requests by the time period of those requests and then assumes that this rate will continue for 4 years. The formula then multiplies the number of requests over those four years by the royalty rate per request to arrive at the POE), e) outputs the POE.

7. A Supplier accesses the SFTD by spelling a name over the phone into the SFTD. The SFTD's speech recognition function recognizes the request and the SFTD does a lookup to see if a corresponding telephone number is already in the list. If the number is not in the SFTD, the SFTD allows the Supplier to enter the number and stores the Supplier ID data along with the number in order to properly credit royalties. If the number is already in the SFTD, the SFTD outputs a voice synthesized message, "Number is already in directory." If the number needs correcting, the Supplier then enters the command, CORRECT. The SFTD allows the Supplier to input the number using the SFTD's speech recognition function. The SFTD stores the number to correspond to the question, to the name that is, and also stores the Supplier's ED data with the number, in order to properly credit royalties.

Let us look at another embodiment, a lowest price locator, as shown in Figures 2a and 2b.

1. A lowest price locator (LPL) includes a list of product names and corresponding prices and stores, initially empty, a computer for storing the list and functions for inputting data into the list, outputting data from the list, looking up data in the list and processing data in the list.

2. The LPL also has a sign-on function 30 that allows users to identify themselves for billing and payment purposes. The LPL stores the ID data.

3. Users access the LPL over the phone. The LPL computer is equipped with phone-interface equipment. The LPL accepts calls from two lines, a Request Line and a Supply Line. The Request line puts users in the Request mode, the Supply Line puts them in the Supply Mode.

4. Using the Request mode, a Requestor accesses the LPL list by spelling a full product name over the phone into the LPL's computer. Equipped with a speech recognition function, the LPL recognizes the request 31 and checks 32 to see if the price is in its data-base.

5. The LPL registers 33 the time of the request.

6. If LPL finds no list of stores and prices under the product name, it checks 34 to see if the price has been requested before. If not, it stores the request 35, sets the request tally to one 36, calculates the POE 37 and outputs the POE 38. If so, it advances the tally 39, calculates the POE 40 and outputs the POE 38.

7. If LPL finds a list of stores and prices under the product name, it checks 41 for the lowest price. If it finds 42 more than one store has the same lowest price, it finds 43 the store whose lowest price was entered first and outputs 44 that store and its price. If not, it outputs 44 the single lowest priced store and its price. It then registers 45 the charge owed by the Requestor and the royalty owed the Supplier. It then advances the request tally 39, calculates the POE 40 and outputs the POE 38. 14

(Supply Mode)

8. A Supplier accesses LPL by the Supply Mode and spells a product name over the phone into the LPL. The LPL's speech recognition function 50 registers the name and allows the Supplier to input 51 a store and price

9. The LPL registers 52 the time of the inputting along with the store and price.

10. The LPL registers 53 the user's identification data along with the store, price and time.

1 1. The LPL checks 54 to see if there is list of stores and prices under that product name. If not, the LPL creates a list and stores the data in the list.

12. If the LPL already has such a list, the LPL checks 56 to see if the store inputted matches any store in the list. If not the store, price, time and user ID data are stored 57 in the list. If so, the data just inputted and registered is put in the list in place 58 of the data registered with the matching store.

13. The LPL finds 59 the lowest price.

14. The LPL checks 60 to see if there is more than one lowest price. If not, the single lowest price is held 61 for output. If so, the LPL finds the first, lowest price entered 62 and holds 61 it for output.

Some Comments on Data Processed in Lists and Tables

As the embodiment above indicates, the SODB is well suited to collecting data that is processed in what may generally be referred to as lists and tables. I--et us then make a few comments about such data and how the SODB can be applied to collect it. Many kinds of answers can only be found by processing data in a list or table and often that data can only be collected efficiently by members of a community rather than a central authority. For example, usually the most efficient way for an economy to find the lowest price on a given item is through a system that allows people to feed in prices to a central list where the prices are sorted to find the lowest ones. This way is more efficient than having a central authority call all the sellers of the item in order to check prices. With a feed-in system, only the low price sellers need feed in. The SODB is, of course, a feed-in system. We also note that, because of the nature of data tables, it is often advantageous for a single entry to include many sub-elements. For example, in a table of data on companies, each company entry might have many sub-elements, such as the name of the company, its telephone number, address, sales, number of employees, top officers and so forth. Thus a "single" entry can be used to answer multiple questions.

We also note that when a supplier enters data into a table, the SODB may suggest that the Supplier enter additional data as part of the entry. For instance, a Supplier might supply the answer to the question, "What is the telephone number of IBM?" The SODB might then also suggest that the supplier enter IBM's address. The SODB could guide the Supplier in how to enter extra data.

Additional Method For Outputting Pay-Off Estimates

We now describe an additional method the SODB can include for outputting a POE for data that answers or helps answer multiple questions. This method can be especially useful for data that is entered into and processed in lists or tables, for this type of data is often used to answer multiple questions.

As discussed in the Definitions section, the demand meter records multiple data-uses and sends this demand information to the POF which then calculates the POE for the relevant answer or "raw data". The Definitions section did not go in depth about how the Demand Meter registers multiple data-uses. It was understood that each time a piece of data was used, the use was recorded. Here we will elaborate on this topic and how multiple data-uses can lead to multiple POE's.

Before explaining how the SODB can output multiple POE's for an answer that is used for multiple questions, let us review how the SODB outputs a POE for an answer to a single question. A question is entered and before any answer is entered into the system, demand information is recorded and a POE is calculated for the question. After the corresponding answer is supplied, the demand information and POE can still be attached to the question or they can be attached to the answer, or they can be attached to both. It makes no difference concerning answers that answer one question.

But where an answer is used to answer multiple questions, then multiple POE's can be involved. Demand information can be stored for and a POE calculated for each question answered. In other words, the SODB keeps a demand record and corresponding POE for each question. The SODB can also keep a separate demand record for the answer itself. This record would include the demand records and POE's for all the questions involved.

For example, the answer to the question, "What was the lowest temperature at the South Pole yesterday?" might answer other questions, such as, "What was the lowest temperature on the surface of the earth yesterday?" Thus a demand record would be kept for both questions and a separate POE attached to both questions. The temperature data for the South Pole would also have its own demand record which could include the records of the two questions (and other questions the temperature data answers or helps answer). The POE for the South Pole data could then be calculated based on a combination of the demand information of the various questions involved.

The grandparent explained that the SODB registers multiple data uses, but did not illustrate multiple demand records. They are not illustrated here either, for they are easily implemented by those skilled in the art.

Now, when it comes time for the SODB to output a POE in response to a question, the POE can be the POE associated with the question or it can be the POE associated with the answer (based on demand information from all the relevant questions). The Pay-off Formula determines the POE to output.

But the new point made now is that human common sense will often be better than a machine rule (POF) for guessing the projected income for an answer that is used to answer multiple questions.

For example, the answer to the question, "What is the lowest price for a Walkman in the world?" might have as the answer, "$25 at Luskins." Another question that uses the same data for an answer might be, "What is the price for a Walkman at Luskins?" Now we will assume that the first question has a high POE, say $100, because we will assume that thousands of people want to know what the lowest price in the world is for a Walkman. And we will assume that the POE for the second question is low, say 10 cents, because we will assume that far fewer people ask the price for Walkmans at Luskins. So the same data, "$25 at Luskins," has a POE of $100 when it answers one question and 10 cents when it answers another.

Now assume that the price changes and the Luskin's price rises so that it is no longer the lowest in the world and thus no longer answers the first question. The remaining POE is only for the second question, 10 cents. And let us say that the new price is not in the system yet, and that a Supplier wants to enter the new price. But the new price may have an unusually high POE based on the "lowest-price-in-the-world" question it previously answered. Once the new price is in the system, the SODB will quickly register a drastic drop in demand for the Luskin's price but not until the new price is in. A person however can look at both questions that the data has answered and determine that the new POE will be low because the new price will only answer the second question (we assume the Supplier gets no extra reward for correcting the answer to the first question).

And so, a useful new feature not disclosed in the grandparent is that the SODB can include steps enabling Requestors to see more projected pay-off information than a single POE. The SODB can display some or all the information kept in the demand meter for an answer. Thus, the SODB can display, for example: a. all the questions that given data has answered or helped answer, b. the actual royalties paid corresponding to each question, c. the time periods the royalties were incurred and, d. the current POE's for the questions.

If there is a large number of questions, their display can be ordered in some way, such as by showing the questions that have generated the most royalties or have the highest current POE's. By seeing the questions that the data has answered or helped answer, the Requestor can see whether supplying replacement data is worthwhile.

We note that the most common procedure might be for the SODB to first output the POE for the question that the Supplier is intentionally answering. The Supplier can usually signify which question by entering the question first and then the answer. In the case above, the Supplier would signify that he was answering the question, "What is the price of Walkmans at Luskins?" The SODB may then default to first showing the POE for this question, and then showing a combined POE and/or the POE's from other questions the data might answer.

(We also note that before an answer is in the system, the SODB can include means for anticipating multiple questions that an answer might satisfy. For example, a question might be, "What is the temperature in Moscow today?" The system might anticipate that the answer to this question can be used to answer other questions such as, "What is the average temperature in Moscow this month?" The POE would then reflect these anticipated data-uses. For the SODB to anticipate in this manner requires that the SODB have functions that identify comparable questions and answers and extrapolate demand information and POE's from them. Further, the SODB might have functions for identifying and registering that missing data could have been used to answer multiple questions. We do not describe such functions because they depend on highly specific situations. Users, of course, can make their own extrapolations.) Additional Demand Information

We have shown above how the SODB gathers demand information on which to base a pay-off estimate. However, we showed only the most basic information being collected, the number of data-requests and the times of those requests. It often useful to gather more information. In fact, there is often a tradeoff between taking the time to gather more information versus the value of that information for calculating a more accurate projection of income, the pay-off estimate.

Formulas for projections have been known to contain thousands of variables. We will not discuss or describe nearly that number but we will note here a few more pieces of demand information that can be useful.

One piece of information that can be useful to register is whether a Requestor has asked the same question previously. In many cases repeat requests will mean misleading double counting of requests. For example, a Requestor might ask for the final score of a football game ten times before getting an answer (because the answer has not been entered until the time of the tenth request). It can therefore be useful for the SODB to include steps for registering whether a Requestor is making a repeat request.

In another variation of gathering such information, the SODB can ask the Requestor whether he has asked for the same answer before and whether the request is new or is a "repeat." Asking the Requestor explicitly can be important in at least two cases. In one case the system may not record the Requestors of a given answer. In the other, the Requestor may know better than a machine based rule whether a request constitutes double counting or not. For example, a person might request an answer to the question, "What is the temperature of the ocean at Ocean City?" The answer can change rapidly. The Requestor will know if he is his request is a repeat or if he expects a different answer in each case. The point is that double counting depends on the situation and the user's common sense can be more valuable in identifying double counting than a machine rule.

Another piece of useful demand information that the SODB can register is how long users are interested in the answers they have requested. Many answers are only valuable for short periods of time. For example, the SODB might register dozens of requests for the score of a football game. From all these requests, the SODB might project a large POE. However, the SODB does not "know" that almost no one will be interested in the score shortly after the game in question is over. For the SODB to "realize" this fact, users must "tell" it. Thus, the SODB can ask Requestors to input a time period for which they are interested in an answer. Even if the data is outputted, the SODB can still ask Requestors to input this information. Furthermore, a Requestor could also specify how long he thought others would be interested in an answer. Now this opinion is a guess but can still provide valuable information to the SODB for calculating a projection of future demand. Taking our football score example, a Requestor can input that he is interested in the score of the game up until four o'clock. And he can say that he thinks demand for the score will taper off at eight o'clock. Say the game ends at 4 o'clock. It is often better for the SODB to register and use such information than not.

In another variation of this type of demand information, the SODB might ask users whether they want an answer sent to them and for how long the order stands. The Requestor would specify the time period that the answer could be sent until. The Requestor could also cancel the request. (We presume that the SODB in this case has the capability to send answers to E-mail boxes.)

Price Tests — Registering More Demand Information

The grandparent did not delve into the issue of gathering price information from Requestors. It was assumed that Requestors knew the price of the answers they were requesting as, for instance, a person calling directory assistance or a 1-900 number would know the charges involved. The grandparent avoided price because the goal was to describe the core steps of an SODB. These steps include the gathering demand information about answers, feeding this information into a pay-off formula and outputting a pay-off estimate to Requestors. The key demand information the grandparent described (the number of times a question is asked and the times of those requests) is usually critical for making a projection of future income. Collecting this information did not, of course, preclude collecting other information about the demand for answers. Here we will describe steps for gathering information about what Requestors are willing to pay for answers.

Often it is neither practical nor desirable for Requestors to know the price of answers before the answers are requested. For example, the price of certain answers may change rapidly. The price of, say, today's weather report might be 20 cents while the price of yesterday's may be 2 cents. As another example, similar type answers may have very different prices. The phone number of the President's barber might cost 5 cents while the phone number of the President's private line might cost $5,000. When the price of answers is not known in advance by Requestors, it is often useful to gather information on what Requestors are willing to pay for those answers because this information can be used by a POF to calculate the POE.

(We also note that gathering information on what Requestors are willing to pay for answers can be critical for setting the prices of those answers. We will discuss this issue in a future application.)

Now since the SODB can't read minds, it must perform what we will call price tests. These tests will not reveal exactly what people are willing to pay, but they seem to be the best that can be done. There are two fundamental price tests. One is where the system (seller) offers a price for an answer and the Requestor (buyer) can accept or reject the price. The other is where the Requestor offers a price and the system can accept it, reject it, or simply register it (if the answer is not in the system, the system usually need not accept or reject the offer but just record it in the demand meter and tell the Requestor that the answer is not in the system).

The world of commerce has evolved a great variety of price offers and counter offers that can occur in a sale situation. Earnest money can be pledged, time limits can be imposed, letters of intent can be written, discounts can be given, and so forth. Many of these price offers can have analogues in SODB price tests. Here we will describe mainly the basics, in which either the system makes an offer or the Requestor makes an offer. We will include some important additions but we realize that a great number of variations are possible.

The basic idea behind the system-offer price test is that the system can tally total requests along with the acceptance/rejection rate at a given price. This information is then fed into the POF. The resulting POE might then be correlated not only with acceptances but with total requests and with the acceptance/rejection rate.

The basic idea behind the Requestor-offer price test is simply that the system can register what each Requestor says he will pay. This information is also sent to the POF. The Requestor's offer is not necessarily just talk. If the answer is in the system, the Requestor would usually be charged the amount offered, if the offer was accepted. Even when the answer is not in the system, the system can enable the Requestor to obligate himself to pay the amount offered provided the answer is entered into the system by a given time.

For price testing, it can matter if the answer is in the system or not. For example, take the answer to the question, "What time does The Rockford Files start tonight?" After this answer is in the system, the system might have a price assigned to the answer. But before the answer is in the system, the system might ask the Requestor to make an offer. Thus, different price tests can be used before and after the answer is in. Or, the same price test can be used in either case. There are four basic possibilities:

Before Answer Is In After Answer Is In

System makes offer System makes offer

System makes offer Requestor makes offer

Requestor makes offer System makes offer

Requestor makes offer Requestor makes offer

It can also matter if the price test is done before telling the Requestor whether or not the answer is in the system. Thus we double the number of possible ways by which price tests can be done. We will not illustrate all the permutations but will illustrate enough to get the basic steps across, while recognizing that variations are possible.

The significance of the price tests differs depending on the permutations and therefore the SODB can register information concerning whether the price test was done before or after the answer was in the system and whether or not the Requestor knew if the answer was in the system or not.

We will illustrate some price testing sequences. In the illustrations we will avoid repeating steps previously shown. For example, we gloss over the registering of data-requests and the times of those requests. The point is to show the new steps for executing price tests and using information from these tests in a POF for output as a POE. Also, we will assume that a given question has already been entered and that a demand record has been created for the question, as shown in figure 3. The rest of the figures, 3a-3d, show various price testing sequences. Also, in the figures, the term "question" will be used in place of "data-request" and "answer" will be used in place of "data." Also, when we say that the system registers a piece of information we mean that it stores the information in the demand record for the question being asked.

Finally, note that we also assume that the price offers that the system makes and the price thresholds that the system includes can be set in various ways: by the data-base manager, by the Supplier, by a price setting formula, or by some combination of these. We do not show the setting of prices but assume that step is done at the appropriate time in each case. Price setting will be addressed further in a future application.

Figure 3 shows the basic steps for registering the number of times a question is asked and the times of those requests. This demand information is stored in a demand record for the question and corresponding answer. Price test information is also stored in this demand record (in the grandparent this record was called the Demand Meter). As figure 3 shows, the SODB inputs 100 a question, then registers 101 the time of the request and checks 102 to see the question has been entered previously.

If the question is not found, the system creates 103 a demand record for the question and then stores 104 the time of the request and sets 104 the number of requests at 1.

If the question is found, the system stores 105 the time of the request and adds 105 one to the request tally.

The system then goes on to the steps for executing price tests. We will use the steps above as common preceding steps for four different price testing sequences. These different sequences are illustrated in figures 3a-3d. For the sake of concreteness, let us say that the question we will have in mind in all these illustrations is, "Who sells security holograms in the U.S.?"

In figure 3a a price testing sequence is illustrated in which the system presents 110 a price to the Requestor. The system enables 11 1 the Requestor to accept or reject the offer and the system does not tell the Requestor whether or not the answer is in the system. If the Requestor rejects the price, the system registers 1 12 the rejection at that price, calculates 1 18 the POE, and outputs 1 19 the POE. If the Requestor accepts the price, the system registers 113 the acceptance at that price, and then checks 114 to see if the answer is in the system. If the answer is not found, the system tells 115 the Requestor and then calculates and outputs the POE. If the answer is found, the system outputs 1 16 the answer, registers 117 the charge due to the Requestor and the royalty due to the Supplier and, calculates and outputs the POE.

Figure 3b shows a different price testing sequence where the system tells the Requestor whether or not the answer is in the system before the price tests. Further, the sequence has both price tests, one where the system makes an offer and the other where the Requestor makes an offer.

As shown in figure 3b, the system checks 120 if the answer is in the system. If the answer is in, the system tells 121 the Requestor and presents 122 a price. The system then enables 123 the Requestor to accept or reject the price. As before, if the Requestor rejects the price, the system registers 124 the rejection at that price and calculates and outputs the POE. And, as before, if the Requestor accepts the price, the system register 125 the acceptance at that price, outputs the answer, registers charges and royalties and calculates and outputs the POE. Now, if the answer is not in the system, the system tells 126 the Requestor that answer is not in. The system then asks 127 the Requestor to make an offer. Here, as shown, the system can include steps for enabling the Requestor to make various offers. The system can register 128 a non-binding offer. Here the Requestor expresses what he says he is willing to pay. The system can register 129 a binding offer to pay an amount up until a certain time. In this offer the Requestor not only states an amount he will pay but states a period of time his comitment is valid until. This type of offer can be quite important where certain kinds of answers are concerned. When binding commitments are involved, the Supplier can be fairly sure of getting a given amount of money for supplying a given answer. The system would also add to the POE based on Requestors who do not make binding commitments.

The system can register 130 binding offers that include a commitment of earnest money as a deposit. (Also shown in figure 3b is a step 131 for registering the Requestor's opinion as to the reasonable price for the answer. This opinion is simply the Requestor's judgement and not a personal offer. The step is pictured because it can be important demand information in certain cases. The Requestor can have this option in other price sequences as well and can both make an offer and state an opinion.) Once the system registers the Requestor's offer, the system, as usual, calculates and outputs the POE.

Figure 3c shows another price testing sequence that includes both types of price tests. In this sequence, the Requestor is not told before the price tests whether the answer is in the system or not. The main new feature here concerns the Requestor offer. The Requestor is asked to make an offer when the answer is in the system. In addition to asking for an offer, the system includes steps for registering when the Requestor makes an offer and steps for limiting the number of offers the Requestor can make.

If a Requestor can make unlimited offers when an answer is in the system, the Requestor will start low and keep going up. The Requestor will try to discover the system's threshold price ("bottom line"). Thus, the system needs to limit the number of offers the Requestor can make. This concern does not apply usually when the answer is not in the system because then the answer may have no price threshold attached to it. (It is possible for a Requestor to have a confederate make an offer in an attempt to find the system's "bottom line." But with answers that cost a small amount this practice is unlikely or impractical. So, a feature limiting the number of offers a Requestor can make on an answer can be useful.) The sequence in figure 3c limits the Requestor to one offer. (In figure 3d, steps limit the Requestor to one offer per a set period of time.) In figure 3c then, the system checks 140 to see if the answer if found. If the answer is not in the system, the system presents 141 a price to the Requestor and enables the Requestor to accept or reject the price. The System then registers 142, 143 whether the price is accepted or rejected and tells 144 the Requestor that the answer is not in the system and then calculates and outputs a POE. If the answer is in the system, the system then checks 145 whether the Requestor has made a previous offer. If yes, the system tells 146 the Requestor that he is ineligible to make an offer and then, as usual, the system calculates and outputs a POE. If the Requestor has not made an offer, the system asks 147 the Requestor to make an offer. The system then registers 148 the offer. The system then accepts or rejects the offer. If the offer is rejected, the system tells 149 the Requestor that the offer is rejected and registers 150 that the Requestor has made an offer for this answer. Then, as usual, the system calculates and outputs a POE. If the offer is accepted, the system outputs 151 the answer, registers the charges and royalties due, and calculates and outputs the POE.

Figure 3d shows a price testing sequence in which only the Requestor makes offers. Here steps are shown that limit the Requestor to making one offer per time period. The point, as mentioned previously, is to limit the number of offers that a Requestor can make in order to get the Requestor to make a higher offer. We note in figure 3d that if a Requestor makes an offer before the answer is in the system then this offer is not subject to a time period prohibition. The Requestor is free to make a different offer once the answer is in.

So as figure 3d shows, the system checks 160 whether the Requestor has made an offer that has been rejected. If yes, the system checks 161 to see if the pre-determined time period has expired. If not, the system tells 162 the Requestor that he cannot make another offer and, as usual, calculates and outputs a POE. If the time period has expired, the system asks 163 the Requestor to make an offer. The system registers 164 the offer. The system then checks 165 to see if the answer is in the system. Likewise, if the Requestor has never made an offer before that has been rejected, the system ask for an offer, registers the offer and checks to see if the answer is the system. If the answer is not in the system, the system tells 166 the Requestor that the answer is not found and, as usual, calculates and outputs a POE. If the answer is in the system, the system checks 167 the price threshold and accepts or rejects the offer. If the system rejects the offer, it tells 168 the Requestor that the offer is rejected and sets 169 a time period for when the Requestor can make another offer for the answer, and, as usual, calculates and outputs a POE. If the system accepts the offer, it outputs the answer and registers charges and royalties and calculates and outputs a POE. Brief Note About Price Tests With Price Ranges

Normally a price offer is at a single price. However, the SODB and Requestors can each present offers as ranges, especially when an the answer requested is not yet in the system. For example, marketing research polls that ask people what they are willing to pay for an item often ask in terms of price ranges. The point is that information about price ranges can be more useful than single prices (we also note the important point that Requestors, and the SODB, can offer different prices corresponding to different times.).

There is another reason though that the SODB can present offers in ranges and that is because the nature of the SODB is such that a user may indeed end up paying a price that is in a range. Here we have the fundamental idea of projected price.

The SODB may present a Requestor with a projected price. For example, the SODB might present an offer whereby the price of an answer is between 20 cents and $2.00, with the projected or expected price being 50 cents. Taking our hologram example, a Supplier who does research and compiles a list of hologram producers might want to be rather sure of being compensated for his time in compiling the list and entering it into the system. He might want, say, $20. And so, the SODB might set the initial price for the hologram answer high, in order to better insure that the Supplier will be paid the $20. Thus the first ten Requestor might be charged $2 each. However, say another 100 Requestors ask for the same hologram answer. These can be charged less, say 20 cents each, and the original Requestors can be rebated an amount. Thus the actual price the original Requestors pay is not definite, but a projected or expected price. Just as the system calculates a POE, it can calculate a projected price.

We will not delve into this idea further here but note that in certain situations the principle of projected price, like projected income, is not only fundamental but highly useful in getting answers into the SODB.

Brief Comments on the Types of Answers Suppliers Can Enter

In general, we get answers from computers in three ways. One is by straight look-up, direct correspondence. For example, if someone asks, "What type of wood are Stradivarius violins made out of?" the answer could be stored in a computer under the question.

Another type of knowledge is what might be called "algorithmic" in the sense that information is compressed in an algorithm. For example, one could ask, "What the length of the hypotenuse of a right triangle with sides 3 inches and 4 inches long?" This answer could be stored to correspond to the question. One could make a huge look-up table with answers to questions about the lengths of different hypotenuses. A more efficient way of representing this information though is by the well known Pythagorean Theorem. This theorem allows you simply to plug in the relevant numbers and let the computer calculate an answer.

The SODB can be adapted to calculate answers from algorithms. For example, if 1 ,000 people ask questions about the length of the hypotenuses of different triangles, a user might realize that, rather than answer each of these questions, she could enter the theorem and enable people to plug in the appropriate numbers. The user that entered the formula and the interface allowing people to enter the numbers could then get the royalties for the questions the theorem answers.

It is thus possible to enable users to enter formulas and an interface procedures for Requestors to be able to use the formulas to get desired answers. The problem is that the SODB cannot come up with a POE for the algorithm because doing so requires the intelligence to realize that a group of different questions can be answered with a single algorithm.

Likewise with tables of data that is processed; it is possible to enable Suppliers to enter sets of functions that create tables such that data can be entered into the tables and then be processed. Again, the SODB does not have the intelligence to assign a POE to such tables + functions. As with algorithmic answers, we note the possibility of enabling Suppliers to enter tables + functions and paying Suppliers for the usage of the tables. While having such features can be quite important, it is not he main point of the system.

(In the grandparent we presumed that the tables and functions can be part of the SODB. After all, there is nothing new in processing data in tables. What is new in the SODB is how economic values are attached to given data (whether that data is in tables or not) to induce users to supply that data.)

Brief Note on the Form of the Invention

Before going on to other features of the invention, it is worthwhile to pause and discuss the form of the invention. Because it is to be used by a community of people in different locations, the invention comprises a network in which terminals in various locations are used to input data requests and supply data. The terminals can be anything from telephones to super computers. The data itself can be stored centrally or in nodes throughout the network. For example, certain users might request the full text of Dracula. Other users might want the film version of Dracula. And all this data can be stored centrally. Or the text of Dracula, the book, might be stored in a computer owned by, say, the Library of Congress, while the film data might be stored in a computer owned by, say, a film studio. Because of the added communications costs, highly decentralized storage of data is not usually the most efficient method where the SODB is concerned. Nevertheless, real world concerns might dictate such decentralization. A movie studio, for example, might not want to put its copyrighted movie in someone else's computer for distribution to the public.

(One problem in discussing the issue of centralized storage is that the very concept of centralized storage is blurry in this age of sprawling networks. We will not try to define the notion crisply here, but will rely on peoples' intuitive notions.)

While the storage of data itself may be decentralized, the gathering of demand information about data-requests (and the calculation and outputting of POE's) must, in general, be highly centralized. For example, say we have a data-request, "How many paintings are in the Louvre?," and say that a dozen users request the answer to this question. It does no good if the twelve data-requests are all registered on different systems. There needs to be a central tally showing that there have been twelve requests for the data. That way the POE corresponds to the demand of twelve people. Otherwise the POE in each system would only correspond to one request.

In fact, the goal of the SODB is to collect the demand for given data centrally. That way the pay-off for supplying the data is higher and the data can cost less per user. Moreover, the more demand for a piece of data, the more likely the data will be entered into the system. If the demand is decentralized then there is no way to accumulate the demand and that defeats the purpose of the system. Of course it is conceivable that the demand could be registered throughout the system but it would still have to be tallied, matched up, somewhere to yield a total figure which would then lead to the maximal POE.

(The economic efficiency of accumulating demand information does not mean that a single SODB will store all the world's data-requests. An SODB is meant to be used by a community and a community can be defined narrowly. For example, a company might have an SODB for its employees. Data-request demand information would be stored centrally though and not in every employee's computer.) We have mentioned that the data itself might be stored in a decentralized manner. However, if the SODB does not store data centrally, it must at least store pointers to the data centrally. For example, if a Requestor asks for a given piece of data, the SODB must be able to tell if the data is in the system or not. To do this, a pointer would identify whether the data was in and where it was located. Thus a data-pointer is surrogate for the data itself. In the case of decentralized storage of data then, a Supplier who enters data into the system would have to enter a pointer centrally while entering the data into a given storage computer.

It is also possible that the SODB only outputs routing information to the Requestor but does not make the connection to the storage computer. In this case, the SODB is really a new kind of signaling mechanism that tells users where data is stored and tells users the potential pay-off of storing and selling data. This form of the invention was not envisioned in the grandparent and is noted here.

Another aspect of the SODB that can be decentralized is paying royalties and collecting charges. This can be done at the nodes where the data is stored. Again, this form of the invention was not envisioned in the grandparent but is noted here. However, even if payments are transacted in a decentralized manner, payment data would still be sent to the central SODB location because such data is usually important demand information to be used in calculating pay-off estimates.

Brief Note on the Importance of the Flexibility of the Royalty Rules

One of the advantages of the SODB is that the royalty rules and the POF are infinitely variable. Thus, the system Manager can adjust the formula to reward certain actions such as the correcting of answers. We will go into the importance more in a future application but here we will note one of the most important consequences, starting up the system and attaining critical mass. For many types of fee based data-base systems, the problem is starting up and gathering enough initial data and enough initial customers. This problem is often referred to as the critical mass problem. The idea is that if enough users use the system the system will be profitable and self-perpetuating. But it is a chicken and egg problem, for often no users can be gotten until the data is in the system.

The beauty of the SODB is that it enables the System Manager to provide incentives that can jump start the system. For example, if your plan is to start a lowest price locating system, a huge obstacle is how to convince thousands of sellers nationwide to feed in their prices so that the prices can be sorted. We met a similar problem in the very beginning when we discussed the problem of even keeping a data-base of telephone numbers up to date. The problems with a lowest price locator are worse.

If we agree though that people would be interested in lowest prices we can see that if the system got started it might be self-perpetuating for buyers would want to check lowest prices and the low price sellers would, out of self interest, want to display their prices. So let us assume that once the system got going it would have value for users.

In order to jump start the system the Manager can adjust the royalty rules so that the people who are the first to enter the lowest price of a given item get a share of future income from all the lowest prices, for that item for a period of time. For example, say that the item is a Sony Walkman (we'll pretend there is just one model in the world). Then the royalty rules can be set such that the person who enters the lowest price will get a share of the royalties of all subsequent lowest prices, for a period of, say, 5 years. Now, if there is no price in the data-base then the first person to enter the price is the lowest. That is not a reasonable way to get the system going. Therefore, the System Manager can set a rule such that the "first" lowest price Supplier is considered to be the person who has entered the lowest price that is valid at a given date and time.

The System Manager can set the royalty rules such that, for instance, the Supplier of the lowest price for a Walkman on December 24th, at noon, gets a small share of the royalties for all lowest prices entered for the next 5 years on a Walkman. The reward might be, say, $200. Thus the System Manager can set up a competition to be the lowest price Supplier on a given date and time. The competition might last, say a couple of months. At the end of this competition, a truly low price might be entered and the system may be off an running for that item.

We are using this illustration just as a representative example of the advantages of being able to adjust the POF (the royalty rules really). There are many other advantages of being able to adjust the royalty rate and thus the resulting POE's, but this use above is the inventor's favorite.

Additional Functions

An SODB should include more functions than the basic ones described above. Some useful functions are described below.

Matching Functions The SODB is a matching machine in two senses, both critical. First, it matches questions (data- requests) and keeps a tally of how many times the same, matching questions have been asked. Second, it matches answers to questions. In both types of matching, problems can arise due to the nature of language and the nature of questions and answers themselves. Therefore, the SODB should have functions to increase the chance of accurate matching. Examples of such approaches are best match algorithms.

a) Infinite Ways to Ask the Same Question

There are multiple, in fact infinite, ways to ask the same question. Two questions that have the same meaning may not be matchable because they have a different form. And so, the goal of the SODB is to try to make questions with the same meaning take on the same form. The SODB can therefore have a function that takes a Requestor through a standard input structure so that Requestors have a better chance of posing Questions in matching forms when the questions have the same meaning. This structure is easiest with simple questions such as, "What is the telephone number of John Smith?" A Requestor might simply input the name "John Smith," which would of course, match other inputs of "John Smith." This example brings us to the next problem.

b) Questions Can Have Multiple, and Possibly Infinite, Answers

To match an answer to a question, there needs to be a single answer. However, as discussed previously, the phrase "one answer" is not very clear. An answer can have multiple components. For example, the question, "What is John's telephone number?" might have an answer that includes multiple numbers because John might have several numbers. However, the answer could still be considered a single answer because the numbers are that person's numbers, which is what the requestor asked for. The Requestor though would not want multiple numbers of various people with the same name. For example, a person entering "John Smith" looking for a number might find hundreds of numbers. In fact, most all questions can have multiple answers, even seemingly specific questions such as, "What is John's weight in pounds?" The answer may be 150 or 150.1 1 or 150.111 1 , and then any figure depends on when he was weighed, with what scale, and so on. To narrow answers down, we use implicit default assumptions, some of which we build into our data-bases. In addition to these assumptions, the key to narrowing possible answers is to specify enough information in a question to make it highly likely that only one answer will be given. Specifiers such as full name, location, ID number, time, source of information and so on can often narrow the possible answers to one. The SODB can include a function that asks the Requestor to pose the question more specifically. The SODB can also include a function that picks one answer out of a set of equivalent answers. For example, the answer to the question, "Where is the lowest price on a certain compact disc?" might be many places. The SODB might pick one at random. Quality Control Functions

Quality control of answers in the SODB is essential. The SODB can have many functions to provide incentives and sanctions that encourage Suppliers to provide accurate answers. A general incentive is that a corrected answer will displace a wrong answer and garner royalties. The SODB may have rules to define what a wrong answer is but these rules cannot cover all situations. Disputes may arise as to whether answers are accurate and these dispute may have to be settled outside the system by the Manager of the SODB. Some quality control functions are listed below.

a) The SODB can have a function that stores identification information about an Answer such as the time it was supplied and the primary source (the primary source and the Supplier may or may not be one and the same).

b) The SODB can have a function that allows users to input a claim that an answer is wrong and send that claim to the Manager.

c) A user, Requestor or Supplier, can claim that an answer was intentionally supplied wrongly. The SODB can have a function that allows a user to record this claim and send it to the Manager.

d) The SODB can have a function that allows a user to request that a manager inspect an answer. The function can also register a charge for this inspection.

e) The SODB can have a function that allows the Manager to register that an answer is wrong and to register that wrong to a Supplier.

f) The SODB can have function that keeps a record of the wrong answers a Supplier has provided. This function can also disqualify a Supplier who has inputted too many wrong answers.

g) The SODB can have a function that charges Suppliers an amount of money, a penalty, for providing wrong answers.

h) The SODB can have a function that rewards a user who discovers that an answer is wrong. Such a function can charge a penalty to the Supplier of the wrong answer and pay the penalty fee to the discoverer of the incorrect answer. i) The SODB can have a function that pays Suppliers to update answers. Let us call such a Supplier an Updater. For example, a price that was originally entered correctly might become outdated. A user who discovers this can be paid for changing the answer to a correct one. The user would be paid royalties that the new, correct answer would generate. However, sometimes, when an answer is changed, it may receive no royalties. This is particularly true with prices and other time sensitive offers. For example, the answer to the question "Who sells HP printers for the lowest price?" might change. The Updater might find out that the current answer in the SODB is wrong. But the Updater might not be able to Supply the correct answer. That may have been supplied by someone else. In these cases, the SODB can have a function that pays the Updater a share of the Royalties owed to the Supplier of the new answer and/or of the old answer. Or the SODB may be able to credit the Updater in other ways, such as crediting him with free answers.

j) To cheat, a person might have a confederate change an accurate answer to a wrong one. The person would then re-enter the answer correctly and claim royalties. The SODB can have a function such that if an answer reverts to a previous answer within a given period of time, royalties will be paid to the Supplier of the previous answer, provided the previous answer was accurate. With static facts, such as a person's birthday or the speed of light, the first person to supply the answer accurately would usually claim all royalties. With changing facts, such as prices, the time allowed for reversion could vary depending on the situation.

k) The SODB can have a function that "confirms" answers by making sure that they are outputted to Requestors only after having been inputted by more than one Supplier.

1) The SODB can have a function that allows Suppliers to enter answers only after having entered a passcode.

m) If accessed by voice, the SODB can have a function that records the Supplier's voice for identification.

n) The SODB can have a function that audio records the Supplier receiving an answer from the primary source of that answer. For example, a Supplier could be getting a price from a store. In order to insure that the store cannot renege on this price, the Supplier might want to record the conversation. Thus the SODB can have a call forwarding function in which the Supplier calls through the SODB, the SODB connects the Supplier to the store and then also records the conversation. To reduce recording costs, the recording might be done randomly.

Deleting Data Function The SODB can have a function to get rid of "deadwood" by deleting answers, raw data, data- requests and data-uses whose demand rate drops too low. For example, the SODB can automatically delete any answer that has not been requested or any question that has not been asked for a period of time.

User Fee Functions

To offset costs and to encourage efficient use, the SODB can have a function that charges users for connect time, for the storage of answers and for any other usage of the data-base.

Pay-off Meter Functions a) A user might prefer not to have the POE outputted automatically but instead upon request. Therefore, the POM can have a function that allows Requestors to request a POE.

b) A function can be added to the POM that tells not only the Pay-off Estimate but also an estimated per hour rate. Thus the Pay-off Formula would have to include an estimate of the time it takes to input the necessary data. From this estimate, a per hour estimate follows.

c) The Pay-off Formula can calculate a second POE, one that is a percentage of the original POE and could be called a Referral Fee. This fee would be due a person, a Referrer, who alerted a Supplier to enter an answer. This function would allow a Supplier to input the name of the Referrer. The function would then credit royalties to both the Supplier and the Referrer. These two would normally share the original royalty amount.

d) The Pay-off Formula can calculate the Pay-off per component in an answer. There are infinite ways to assign a value per component. The Pay-off Formula could, for example, simply take the POE and divide it by the number of components, x, in an answer. The SODB would also have a function that tallies the components.

e) As mentioned, the SODB can include steps enabling Requestors to see more projected pay¬ off information than a single POE. The SODB can display some or all the information kept in the demand meter for an answer. Of particular importance, as mentioned in the section on price setting, is that the system can output a projected demand rate, without a price or cash pay-off attached to it. Of course, any data in the demand record (demand meter) can be made available.

f) The Pay-off Formula can allow users to create "what-if ' scenarios, where users plug different values in for key variables in the POF, such as the price of a answer, the time period that the answer will be desired, the rate of requests, and so on. This subject will be taken up in a future application.

Requestor/Supplier Functions a) A Requestor may not want to supply certain data because another Requestor might beat him to the punch. Therefore, the SODB can have a function that reserves the right to input the data. The Requestor could enter a command, such as RESERVE, after hearing the POE for the data. The function would store the Requestor's ID data along with the Requestor's question. Then, for a period of time, the SODB would allow only that user to enter the necessary data. This function would also alert other users that the data was reserved for that time.

b) A Requestor who becomes a Supplier may not want to bother re-entering a Question that he previously asked when in the Request mode. The SODB can then have a function whereby this user, when in the Request mode, could enter a command, such as "W LL SUPPLY", after hearing the POE for the answer. The function would store the Requestor's ED data along with the Question. Then, when the user is in the Supply mode, the function would, upon a command, such as PREVIOUS, look-up the last question that the user had asked. The data inputted by the user would then be stored to correspond to that Question.

c) A user who intends to be a Requestor might enter the Supply Mode, using that mode to check whether an answer is present in the SODB. (A user can check whether an answer is present using the Request or Supply Mode.) If the answer is present, the SODB can have a function that allows the user to automatically switch modes upon a single command and have the answer automatically outputted and a charge registered to the user. This function may seem trivial but an important issue lies behind it. The SODB is a feedback system different from other data-bases in that it forms a tight feedback loop based on royalty incentives provided to users who normally would pay to receive data. With certain data-bases, suppliers, who do not pay for receiving data, may be able to check on the potential royalty revenue from a piece of data. But, for the first time, with an SODB, this pay-off information is made directly available to users who are seeking data and who are charged for it if it is in the data-base. This fact makes a great difference for it creates a tight, efficient feedback system that is new.

Check Mode

Check mode was mentioned in the the grandparent briefly. The basic idea is that a user can check the POE of an answer without registering as a Requestor or Supplier. Check Mode is not necessary for a user could always check the POE of an answer in Supply Mode. With a special Check Mode, however, the system can enable a user to check multiple questions at once. Thus the system could enable a user to conduct a search based on the value of POE's. Such a search would probably be too broad but when conducted along with a keyword search could show users answers that were potentially high yielding and that the user might be able to answer. The other reason for Check Mode is that if a Requestor just wants to check whether an answer is in without registering demand information, this can be another way to do it.

Alerts

The system can include different types of alert functions that alert users as to relevant changes in the status of given answers. Users can direct the system to send them information on such chages. Two key alerts are the following:

1. A POE alert (mentioned in the definitions section under the I-Signal). In this alert, a user would ask that the POE for a given answer be sent to the user if the POE rises above a threshold.

2. Answer Status alerts. In this alert the user ask the system to send information if an answer has been supplied, has changed, has been complained about, or has been given a change of name (has had a new question attached to it). Both Requestors and Suppliers might be interested in such information. Requestors might of course want to find out if an answer is in and Suppliers might want to know if their answer has been messed with.

Probabilistic Payment Functions

If payments and royalties for data are quite small, it is very advantageous to use an expected value payment method (EVPM). An EVPM is described in patent no. 5,085,435 and 5,269,521. Please see this patent for an explanation of the method.

The main question in an EVPM is how to insure fair bets. In this case the bets are between the SODB and its users, both Requestors who owe money and Suppliers who are owed money. We will take the case of Requestors who owe money. The principles involved extend to Suppliers. Cheat-prevention methods are described in the patents above. Two examples of cheat prevention methods that can be applied to the SODB are given below.

Numbers Game Method: In the illegal Numbers Game, results were often determined by one number, for example the last three digits of the handle at the track. Anyone who picked that number would win. Thus, one number decided thousands of bets. Likewise the SODB's Payments Register can set up EVPM bets with each Requestor. Charges registered one day can all be decided by the daily lotto number the next day. For example, assume the stakes are set at $10.00. The bet then is decided by the last three numbers in the daily lotto. (See EVPM patent). So, the Payments Register register the charges owed by all Requestors during one day. Then the next day, the daily lotto number is announced. The Payments Register takes this number and applies it to every bet is made with Requestors on the previous day.

The only problem with such a method is that it can truly be feast or famine. For example, assume all charges one day are 10 cents. The SODB only has a 1 % chance of winning bets if the stakes are $10. Therefore, the SODB stands a 99% chance of getting nothing and a 1% chance of getting 100 times its money. In order to even out the income stream, the Payments Register might assign to each Requestor an extra number to be added to the lotto number. The extra number might be part of the Requestors ID number, for example. These extra numbers would be random or nearly so in order to even out the wins and losses from bets. As long the extra numbers are agreed upon by Requestors before the lotto number is announced, all is fair.

Probabilistic Metering Method: Normally, when people use an on-line data-base or phone system or any usage sensitive system, there is a metering component that measures usage and ultimately determines charges. The SODB has that with its Payment's Register. However, registering charges and then billing for them can be a large cost. Therefore, it would be advantageous to do the metering on a probabilistic basis by EVPM. For example, the meter might be off 90 percent of the time but, when on, the charges applied would be at 10 times the normal rate. The periods of time the meter is on and off are determined by a random number supplier that picks a number, in this case an integer from 1-10.

The SODB's Payment's Register can have a Probabilistic Metering Function (PMF) that randomly determines the time periods during which the SODB will register charges to Requestors (and register royalties to Suppliers). The function is described below.

1. A period of time is broken up into sub-periods. For example, a day might be broken up into minutes.

2. The probability that the meter will be on during a sub-period is decided upon by the SODB manager.

3. Each sub-period has assigned to it a random number that determines whether the meter will be on or off during that period. The number is chosen by a random number generator such that the probability of the meter being on is the probability that the SODB manager has decided on. With each sub-period having a random number chosen, a sequence or list of "on's" and "off s" is created. This list is inputted into the PMF. ( The list is supplied by an independent source that generates the numbers. The independence of the source is necessary to verify whether or not the SODB's sequence if fair.)

5. The PMF has a clock and a sub-function that, upon the clock's arriving at each sub-period, checks the list to determine whether the meter should be on or off. The sub-function turns the meter on and off as determined by the on/off list.

6. The clock is synchronized to an independent clock so that fairness can be assured.

7. When the meter is on, the Payment Register registers charges and multiplies them by the inverse of the probability that the meter would be on. Thus, if the meter is to be on 1/10 of the time, the charges would be 10 times normal.

Probabilistic metering by this method offers an efficient way to insure fair bets and also a way to smooth out the wins and losses from bets. Perhaps more importantly, it allows Requestors not to have to input the ID data unless they lose bets. There is no reason to input one's identity if one does not have to pay. Thus the inputting of ED data is eliminated from the Start mode. This can be a very advantageous for people in a hurry. It means they only have to identify themselves for billing purposes when they lose the bets. Of course, people might not pay if they haven't identified themselves. However, in addition to honor, it is possible in some cases to gather evidence to trace Requestors. It is possible to capture the Requestor's voice, for instance, if the SODB is accessed by voice. If the SODB is accessed by computer, the computer may be traced.

Handling Natural Language Questions

Introduction

The foundation task of the SOD, the one that the other key tasks are based on, is to count the number of people who want a given answer. The system must get a reasonably accurate count of how many people seek the same answer because it is from this number the system estimates of the future sales and POE of the answer.

For the system described in the grandparent and parent to get a good count, people must usually agree on the meanings of the questions that they enter into the system, and so, the meanings need to be highly constrained. For example, the question, "Billy Budd?," theoretically could correspond to an infinite number of different answers. In a given SOD, the meaning would ideally be constrained to a single one, say, a phone number, a movie, a book, and so on. Otherwise, the system could not count how many people wanted the answer for there would be no single answer.

Besides reasons of tallying demand, highly constrained meanings are used, as in most data¬ bases, so that people can find answers. Constrained meanings for queries are necessary because computers cannot understand natural language. For instance, when a person asks the Library of Congress computer about books that Herman Melville has written, the user must enter, "Browse Melville, Herman." The user cannot enter, "Hey, what books did Herman Melville write?" In the case of the SOD, where users not only enter questions but also enter the corresponding answers, it is especially important that users agree on what valid answers are, that is, agree on the interpretation of the questions. Therefore, with the system of the parent, a system designer or operator would strive to set rules that strictly limit how users interpret the questions entered into the system. No set of rules can succeed perfectly if the questions and answers deal with the real world, but the goal is to reduce ambiguity as much as possible.

You Can Do A Lot

As the success of computer data-bases attests, you can do a lot with constrained queries, even if the queries are just names. Names can naturally correspond to information such as phone numbers, addresses and prices and so this type of information is readily collected in an SOD. And since names can correspond to most anything, the SOD can readily collect more than short pieces of information. In fact, the original name of the SOD was the MOAE, a strange acronym standing for the Mother Of All Encyclopedias. This name came from the fact that the SOD lends itself to creating a gigantic encyclopedia with entries corresponding to subject names. The names could be about any subject people care to know about, from the accoustic properties of jello to the role of jello in the last Presidential election.

A given MOAE would still need special rules for defining a satisfactory answer though. These rules could allow a lot of flexibility. One such rule could be that an answer that is outputted and credited with royalites is an answer that is voted best by users. In this case, the the system would include rules whereby certain users would vote for the best answer to a question, or the best answer under a certain number of words. Rules like this would allow a variety of possible answers to be entered into the system, and yet the answers that could be outputted at any one time would still be very limited.

The Goal of Processing Natural Language Questions

The scope of the SOD would be greatly broadened if people could ask it unconstrained, ambiguous, natural language questions, as if they were talking to a person or the computer on the Starship Enterprise. It would be nice to be able to ask the SOD a question like, "Hey, what books did Herman Melville write?," and get the answer one was looking for. But natural language poses problems for the SOD because when a user enters a natural language question it is not clear what answer the user is looking for. And if it is in not clear what answer is wanted then the system cannot estimate a value for the answer.

Why is the answer not clear though? And can we enable the system to handle natural language questions and answers? Let us, for a moment, discuss natural language, by which we mean words and sentences people communicate with.

Natural Language

Words and sentences are things we use to refer to other things. As a synonym for "refer to" we also say that words and sentences "mean," "describe," "represent," "denote," "correspond to," "match," and "signify" things. These terms seem simple enough but, of course, we do not actually understand how this correspondence process works; we just realize that words and sentences in our brains somehow do correspond to things outside our brains and to ideas that may be only in our brains. One fact we know about the process is that a word or sentence can refer to many things, even an infinite number of things. Take the word "drive". What does it refer to? That depends on the situation. And since the number of possible situations is infinite, the word "drive" can potentially refer to innumerable things. It depends on what situation a person has in mind. Therefore, to determine the meaning of a what is said, one usually needs a great deal of context or a lengthy description of a situation. Even then the meaning is still personal and variable in the sense that it depends on a how a person views the situation.

Agreement Necessary

To communicate successfully with words and sentences, we must agree with each other about what those words and sentences refer to, a fact that is especially obvious to anyone who has listened to a foreign language. So, while words and sentences can potentially refer to infinite things, in practice they usually refer to a certain set of things that we generally agree on. Such a set itself may be infinite but it does not contain all things. So in fact, the meanings of words and sentences are very constrained compared to all the possible meanings they could have. And this fact makes communication with words and sentences possible. Still words and sentences can refer to enough things that an agreement process is necessary. While this agreement process is not well understood either, we do know that an essential part of it is the process of clarifying what is said.

To Humans, What Is a Question?

Now when someone asks us a question that needs clarifying, what is it that we are trying to clarify? Well, we are trying to clarify what information the person is seeking. But what then is a question that it "asks" for information?

That is a mystery will not be cleared up here. All we can say is that a question describes an answer, describes what information a person is looking for. The description does not tell all about an answer but tells enough so we know what answers can fit the description. Thus we can think of a question as a label on a black box and think of the corresponding answer as an item hidden in the box.

The problem with natural language labels is that an infinity of things could be in the box. So there is no such thing really as tΛe answer to a natural language question. A multitude of answers can fit the description of a question-label and can be considered an answer. That does not mean all answers can fit the description, just that there is an infinity that can.

Ambiguity, a Problem for the SOD

All this poses a problem for the SOD of the parent because, as mentioned, the key functions of the SOD depend on an agreed on, unambiguous correspondence between questions and answers. For the system to work best, a question should have a single answer. The system presumes that the same question strings (in the sense of a string of symbols that is) correspond to the same answers because to a machine the same question means the same question string. The system, being a machine, recognizes strings, not the meanings of the strings to humans.

To humans, the same string can refer to different answers. For example, say three people enter the following string into the SOD:

What is the definition of "drive"? Now we know this string can refer to innumerable definitions, just three being: To push or urge forward.

In baseball, to propel (the ball) swiftly, as by a hard or direct stroke. A road prepared for driving, esp. for leisure driving, as in a park.

Should the SOD register that there are three requests for the answer corresponding to this question? Not necessarily. The Requestors may want three different answers and only one request should be registered for each. But how is the system to recognize that? How is the system to recognize which answers the Requestors want? How is the system to know if the desired answers are in the system? And how even would a human know which answer to supply?

The problem seems daunting when one realizes that even seemingly specific questions like, "How far is it to Chicago from Washington D.C.?," are actually quite vague. How far in miles? In inches? In the time it takes to get from Chicago to Washington by foot, by car, by plane, by transporter beam? From what point in Washington to what point in Chicago? By what measurement method? According to whom? In what year? In what season? At what time of day? On a map or in reality? And so on.

Flexibility, Another Problem Now let us consider another problem that comes about because of the ambiguity of natural languge and also because of what is often called the flexibility of natural language. By flexibility we mean that we can easily say the same thing in many, even infinite ways. For humans, different words and sentences can refer to the same thing. Thus people can enter diffferent question strings into the SOD and have the same answer in mind. That's a problem for the SOD because the machine cannot recognize the same question in the human sense. To humans the string is not the point, the point is the answer being sought. To humans the same question means that the same answer is being sought. The machine cannot recognize the answer being sought though. To repeat, it recognizes strings, not their human meanings.

Let's say that our three people have read the same passage in a book and all three want to know the meaning of "drive" in this passage. In this case they are looking for the same answer. But in this imaginary case let us assume that they enter:

What is the definition of "drive"?

What does "drive" mean?

How do you define "drive"? How then is the system to recognize three requests for that answer rather than one request for three different answers?

This problem also seems daunting because of the infinite possible ways to ask the same question, in the sense that the same answer is being sought. Continuing from a previous example, a person in Washington D.C. might want to know how many miles it is to Chicago and ask, "How many miles is it to Chicago?" or "What's the distance to Chicago?" or "How far is it to Chicago?" or "Where is Chicago from here?" and so on.

So not only can a question be a sign for a multitude of different answers but a single answer can be labelled by a multitude of signs.

Two Problems of Natural Language Restated

Let's recall the foundation task of the system: to count how many people seek the same answer. If the system is to process natural language questions, we see at least two obstacles to accomplishing this task:

1. For any question string, there are potentially infinite answers. We might also call this the endless answers problem. 2. For any answer, there are potentially infinite questions strings. We might also call this the matching up questions problem.

What Follows

In the following sections we will describe solutions to these problems. First we will point out how well known best match algorithms can provide an initial solution to the matching up questions problem. Then we will focus on solving the endless answers problem. Some of the solutions we describe can also be used to solve the matching up questions problem in a new way.

To the SOD, What Is a Question? A Bazaar Analogy Is Given

Before plunging into these solutions, let us paint a picture, by way of analogy, of what a question is in the SOD. The picture will not be of just a question string but of all the information that is stored along with the string, and further, of what users can do when they have arrived at this question-record, which we will usually refer to just as a question. The analogy will not introduce any new ideas but give a more visual way of looking at questions within the system. This picture should help us keep track of the new things we will be adding to questions in later sections. In this analogy the data-base is a bazaar where answers are bought and sold.

It is said that the bazaar began long ago with a single peddler, a man named Borges they say, though no one is sure. Some come to the bazaar seeking answers and are called buyers. Others come bearing answers and are called producers. Though the bazaar was once crowded with people hawking their wares at stands and stalls, time has passed since the beginning and, though no one knows exactly when, robots took over. The robots care nothing for answers, only for running the bazaar. Why they do this is unknown.

People are the only ones who supply answers for they are the only ones who can venture out of the bazaar into the real world. There is an exception. Certain kinds of answers are made by combining and manipulating answers already in the bazaar. Robots can and do produce these answers using the materials humans supply.

People being people, disputes arise. But the robots care nothing for the disputes of humans and so the bazaar has human judges. These are wandering philosphers who spend most of their 44 time in thought. Anyone can ask the robots to fetch one to mediate a dispute. Legend has it that the philosophers have more to do with the operation of the bazaar than meets the eye.

In the old days, a buyer who could not find an answer would build a small stand and post a handwritten sign offering a reward to anyone who would supply the answer. Others who wanted the same answer could find that stand and write an offer of additional money. Eventually, someone might supply the answer to the stand and then that person or his agent would stay there, selling the answer.

In this age, whenever a buyer asks for a new answer, states a new question that is, the robots of the bazaar constuct a stand for that question and place it in its own location in the bazaar. In this age, a stand is a machine. It is an electronic sign with information about an answer, a vending machine that may sell an answer and, a polling station that collects information about buyer interest in the answer.

A question is a sign that stands twenty feet tall describing a product. (In the bazaar the products are answers but one can think of a product as anything, a pair of pants, a map, a movie, anything.) The sign is also a meeting spot where people go to find out about the product. And so the sign may also tell whether the product is in stock, what the price is, what the reward may be for supplying the product. This information may change and can be revealed at different times, depending on the type of product it is.

A question is also a vending machine that can dispense the product and collect money. In order for the product to be there, it must be brought by a producer, who then gets a part of the sales. With some questions, a buyer can agree to pay for the product by pressing a button on the machine. With other questions, just the arrival of the buyer means that he buyer agrees to pay for the product if it is there. With still others, the buyer must make an offer and the machine can decide whether or not to accept it. Sometimes a buyer can see the price of the answer in advance, other times not. The machine automatically identifies the buyer and charges him by debitting his account at the bazaar's bank. Money is electronic now, though some speak of the time when people carried gold and defended themselves with long knives.

A question also is a polling station. Each buyer's offer is recorded along with the time of the offer, whether a buyer has made an offer before and, whether a buyer has actually bought. From this data, the machine projects the sales of the product and displays the projection. Many scoff at this predicting, some call it fortunetelling, and it is true that many predictions have failed. Because it is an automated, multi-purpose sign, a question is sometimes called a signomat. Other times it is just called a sign.

No one knows where signomats are located relative to each other. The bazaar is now a vast place and no one has surveyed it. Some say it is infinite. Other say it cannot be. In the old days, people travelled for days to come to the bazaar and had to travel by foot to find answers. Now the bazaar sends vehicles, called hypercabs, to anyone interested in buying or providing answers. The cabs have meters that keep track of all the moves that buyers and producers make. The cabs take riders to any signomat desired. All a rider has to do is state a question and the cab will take him, at terrific speed, to the signomat that displays that question. The cabs are so well made that no one yet has complained of the driving.

Initial Solution to the Problem of Matching Up Questions

As mentioned, the matching up questions problem is that people can enter different question strings but mean the same thing. (While the discussion below applies to both Requestors and Suppliers, the term Requestor will signify both types of users because it is Requestors we are more concerned with.)

The goal then is for the system to match up strings that are different but, from each Requestor's point of view, correspond to the same answer. Another important goal is to match up different questions where the Requestors want "basically" the same answer. We will not define this concept here but just point out that rather than an identical answer, an answer that is close enough may do.

An obvious solution is to use best match algorithms, many of which are well known in the art. After a Requestor enters a question, the best match algorithm would find the question already stored in the system that best matches the question entered. The system may enable users to enter multiple phrasings of a question, all of which can be used to arrive at a best match. (Of course, there may be multiple "best" matches.) The SOD would then show the best match and ask the Requestor to confirm whether the match was satisfactory. If the match was not satisfactory, the Requestor could rephrase the original question or stop.

Assuming that the best match is satisfactory and taking the previous example of three people asking for the definition of the word "drive," let us imagine that already in the SOD is the question string:

What does the word "drive" mean? Now say that the following three questions are entered by different Requestors:

What is the definition of "drive"?

What does "drive" mean?

How do you define "drive?" In each case, we imagine that the system finds the best match and it is:

What does the word "drive" mean?

Once a Requestor has confirmed that the best match is satisfactory, basically three situations can occur with regard to an answer. No answer may exist in the system for the best match question. One answer may exist. Or, multiple answers may exist.

What then does the system do? That depends on the rules of the particular SOD. In the following sections we will describe some useful procedures for handling these situations. For now, we say that the best match is above all a way to jump into the data-base and usually land at a spot where others have been before. If a Requestor is satisfied with his drop off point then he can proceed. If not, he can try again.

Before going to the next section, a couple of more points are in order. One point is that the system can compile a thesaurus of questions that have been matched by the system and confirmed by Requestors as good matches. A novel way of organizing such a thesaurus will be discussed later.

Another point is that the important problem of matching up questions in different languages is also a best match problem, though it involves steps of translating. For example, if someone enters the question,

Quel est le definition de "drive" en Anglais? the system could, if equipped with translation functions, translate the question into, say, English, find the best match, translate the best match back into French, and get a confirmation from the French speaker. We will discuss translation more later.

Though we have spent little space on the best match step, we do not want to shortchange its importance and will discuss it more later. Suffice to say for now that it is an essential starting point for matching up natural language questions because a user seeking an answer usually will rarely enter the exact same question string as other users seeking the same answer.

Once a Requestor has confirmed that a best match question is a satisfactory start, then we come to the endless answers problem. The Basic Idea Behind a Solution to the Endless Answers Problem

Recap

As mentioned, the endless answers problem is that different Requestors may enter the same question string into the SOD but have different answers in mind. For example, each Requestor entering "Where is the ballgame?" may be thinking of a different game. Thus, the SOD needs to have a way for Requestors to distinguish the answers they want even though they enter the same question string initially.

Further, the problem is that different Suppliers may want to supply different answers to a question. One may want to supply "Fenway Park," another, "Yankee Stadium," another, "George Mason Field," and so on. Thus, the SOD needs to have a way for Suppliers to give different answers to the same question string.

One Solution

One possibility is to store all the answers together under the same question string so that all the answers are outputted in response to the question. Yet this way is only suitable for special types of questions that require "composite" answers. For example, the answer to, "What companies in the U.S. make steel?" can include partial answers supplied by many users, each contributing the name of a different steelmaker as an answer. These multiple answers can be combined and stored as a list under the single question above.

Generally though, combining different answers leads to problems. First of all, it is usually impractical to output all the different answers users might supply to a question. Further, it is not possible for a Requestor to indicate which answer he wants. Thus, it is usually impractical to record the demand, and calculate a POE, for each answer individually. Also, if a Requestor only wants one of the answers, it is usually unreasonable to charge him for multiple answers. And further, it is usually impractical to credit Suppliers.

Requirements of a Good Solution

A good solution to the endless answers problem should enable the SOD to distinguish between answers so that: 1. Requestors can signify which individual answers they want without signifying answers they don't want.

2. Requestors can find the individual answers they want without finding answers they don't want.

3. The SOD can maintain a distinct demand record for each individual answer.

4. Suppliers can enter different answers.

5. Users can be charged for the individual answers they receive and credited for the individual answers they supply.

A Better Solution

In the following sections we will describe an interface and data storage procedure that enables the SOD to do all of the above, not perfectly, but well enough to serve in a broad range of cases. While this method involves many steps, they all stem from a couple of operations that allow both Requestors and Suppliers to rephrase questions in a certain way. The operations are these:

1. A Requestor who enters a first question can enter a second, more specific question and link it to the first, less specific question.

So if a Requestor enters a question and receives an answer that he does not want he can enter a more specific question that better describes the answer he wants and he can link that question to his original question.

2. A Supplier who attempts to supply an answer to a first question can enter a more specific question and link it to the first, less specific question. And the Supplier can then enter an answer to the more specific question.

So, in a sense, an answer to a question can be a more specific question together with an answer to that more specific question. That way, when a Requestor enters a question, what can pop up is a more specific question, and possibly, its answer. We say possibly because the SOD initially might only reveal multiple more specific questions, allowing the Requestor to pick one that has the answer he wants. These two operations give Requestors and Suppliers the critical ability to rephrase a question so as to give a more specific description of the answer they want or of the answer they have supplied. The linking step is also critical because it allows users to "travel" from a question to a linked more specific question.

Before explaining how the rephrasing rules can be implemented, here are examples that illustrate more specific questions and show the generality of the approach.

Illustrations

What's EBM's phone number?

What's EBM's phone number in Armonk? What's IBM's phone number for toll-free support?

What is 2 + 3?

What is 2 + 3 in Roman numerals? What is 2 + 3 in the philosophy of Frege?

What is the square root of 2?

What is the square root of 2 to five decimal places?

What is the definition of entropy?

In 50 words, what is the definition of entropy?

In 5000 words by Fermi, what is the definition of entropy?

A-4 paper?

A-4 paper sellers?

A-4 sellers in Washington D.CJ

Was Casablanca a good movie?

Was Casablanca a good movie according to Siskel and Ebert?

Was Casablanca a good movie according to Siskel and Ebert; what is the full text of what they said?

Was Casablanca a good movie according to Siskel and Ebert and what is the full text of what they said on their show?

Was Casablanca a good movie according to Siskel and Ebert and what is the full text of what they said in their columns? 50

How do you get a passport?

How do you get a passport as fast as possible?

How do you get a passport as fast as possible in Norway?

How do you make a chocolate chip cookie?

How do you make a chocolate chip cookie on an open fire? How do you make a chocolate chip cookie that is toll house?

Blurgil smookle?

Blurgil smookle means what in the code of masterspy "L"?

What is the text of the decision in the Merrill Lynch CMA patent case?

What is the decision in the Merrill Lynch CMA patent case, in abstract form? What is the decision in the Merrill Lynch CMA patent case, full text that is? What is the decision in the Merrill Lynch CMA patent case, full text that is plus commentaries?

Specific Enough

By entering a more specific question can a Requestor describe exactly the answer he wants and can a Supplier describe exactly the answer he has provided? That depends on whether you believe that a natural language question can ever be perfectly exact. Usually, if not always, a more specific question will still have infinite possible answers. But by describing more the Requestor has a better chance of receiving an answer that will satisfy him. And by describing more a Supplier has a better chance of indicating what information an answer contains. However, describing too much can be inefficient. Thus the SOD allows Requestors and Suppliers to use their common sense when asking for and supplying answers.

The operations above enable users to act somewhat like they would act in a natural conversation. For example, say you ask a friend the following question,

Is there a restaurant around here where I can get some dinner? The friend supplies the following answer,

McDonald's is around the corner. But you dislike McDonald's and so you rephrase the question,

/ mean a good restaurant? This rephrasing is, of course, analogous in the SOD to when a Requestor sees an answer he doesn't like and rephrases his original question. Another possibility is that your friend supplies 51 more information to your question, for example, he supplies a more specific question and an answer, such as:

You want Southern food? There's a place at the Foundry Building. This rephrasing is analogous in the SOD to when a Supplier enters a more specific question and an answer to that question.

Most conversations reveal that it is somewhat of a myth that people understand natural language. Of course people do, but often not at first. People usually arrive at an understanding by a certain kind of back and forth questioning and answering. When the meaning of a question is ambiguous, they know to ask for more information (they ask for a more specific question).

The operations above allows both Requestors and Suppliers to enter more specific questions. And the link created between two questions allows users to find a more specific question even though they have initially entered one that is less specific.

We should keep in mind that while users do ask the SOD questions, they are really addressing other users. The SOD is a communications system. So while the system cannot understand natural language, it can enable people to better communicate their intentions. As with natural conversation, the questions in the SOD can get more and more specific so an original question can have a more specific question linked to it and then that question can have a more specific question linked to it, and so on, and so forth. The reason all this works is that eventually, through asking more specific questions, we can describe the answer we want so that our fellow human beings understand, usually, what it is we want.

Advantages of the Approach

Enabling both Requestors and Suppliers to link more specific questions to a given first question has many advantages. Among other things, it:

a. Allows Requestors to state a question that better signifies which answer they want out of endless possible answers.

b. Allows Requestors to find a question that better signifies which answer they want.

c. Allows as many answers to a single question as users want to supply.

d. Allows Suppliers to label answers with alternative questions. e. Allows Requestors to see the question-labels and choose the answers they want given what the labels describe.

f. Allows the SOD to first output only question-labels before outputting corresponding answers. (This yields at least two advantages. One, time is saved because full answers do not have to be outputted. Two, the SOD can conceal an answer until a Requestor agrees to pay for it.)

g. Allows the SOD to output a single answer to a given first question.

h. Allows Requestors to be charged for individual answers and allows Suppliers to be creditted for individual answers.

What Do We Mean By a More Specific Question?

Now that we have decided to use more specific questions, we should define them. However, we cannot give a precise definition. Only in rare cases is more specific well defined. These cases occur when we have a finite set of possible answers, say phone numbers. We can say that we are being more specific when we narrow down the list of numbers (answers) by providing more information. For example, take the question, "What is the phone number of John Smith?" Assuming we are dealing with the real world, at some instant in time, and assuming that all John Smith's do not live at the same address, and assuming no other shenannigans, a more specific question is, "What is the phone number of John Smith at 14 Cherry Lane?"

But since natural language questions have infinite possible answers we cannot define a more specific question as one that narrows down a list of answers. We can say that it narrows down a list in a data-base but, we cannot say it narrows down all the possible answers.

Perhaps the term more specific is not a good one. People use the term to describe a variety of situations that are not the same. The truth is, we do not understand specificity well, just as we do not understand ideas well. Still we are going to stick with the term more specific here because it is as good as any other in getting the point across. We will try to give a certain interpretation to it though. In the SOD, the key to a more specific question is the purpose it serves. The purpose is to better describe an answer relative to the description in another question. We say that a question, Qn, is more specific than another question, Q, when Qn:

1. matches the description of Q and

2. includes different descriptive material.

You can see this definition in operation in the illustrations above. By this definition, a more specific question does not mean that a question has more bits than another or that a question "seems" more specific than another. For example, "What is in that goblet?" cannot be compared to "What is in that swimming pool, by chemcial composition, temperature, volume and density?" We intiutively feel that the second question is more specific but, by our definition, the two questions are not even compared. A question is more specific than a first question only when it matches the description stated in the first and includes different descriptive material. Another word for matches the description is fit the description. In other words then, the more specific question must itself fit the original, less specific question. Of course, whether or not the Qn "fits" Q is subjective.

One result of this definition is that an answer to the more specific question should always be an answer to the less specific question, for when stating a more specific question, a person is not supposed to be changing what he was originally looking for, he is just supposed to be giving a better description.

Even though we cannot get into a philosophical discussion of how humans match descriptions to other description or to some subject, we can divide more specific questions into two broad types which we will call restricted and unrestricted.

A Restrictive Definition of "More Specific"

We said that Qn must fit the description of Q and include different descriptive material. One way to do this is for Qn to repeat Q and then add information. The illustrations above all fit this definition. Below is another example, this time with four questions, listed from least specific to most:

Q 1 What is in the can ?

Q2 that has no label on it?

Q3 and that you are holding ?

Q4 in your left hand ? Still, the term the "repeat" Q is a little ambiguous for when we add information to Q we can add to the front, to the back, or in between. Or, we can do some combination of all three. For example,

Q: What is the definition of entropy?

In 5000 words by Fermi, what is the definiton of entropy?

What is the definition of entropy, in 5000 words by Fermi?

What is the definition, in 5000 words by Fermi, of entropy?

Because it is easier for people to keep track of extra information when it is at the beginning or end of a sentence, we shall ignore the version where a person can insert information in between, though we note that it is often a natural alternative. We will say that a restrictive definition of a more specific question means that a question has the exact same information as a first question plus more information appended at the beginning or end of the first question.

This restrictive definition has advantages because it reduces ambiguity. For example, users can make a "ladder" like the one above that orders questions by their specificity. On the other hand, we lose some of the benefits of natural language.

A Loose Defintion of "More Specific"

We would like a more natural definition of more specific. Sorry. Though others may have better ideas, about the best we can do here is the definition above that, to repeat, Qn must fit the description of Q and include different descriptive material. That is a very subjective definition.

To judge whethe a question is more specific than another, the most important test is to recall the purpose of the MS-Q — to better describe an answer relative to the description in another question — and see if the question fulfills that purpose.

Another test is to see whether a question is more specific than another is to check if an answer to the more specifc question will always be an answer to the less specific question. As discussed above, an answer to Qn is always an answer to Q but, an answer to Q is not necessarily an answer Qn. For example, the answer to "What's IBM's phone number in Armonk?" will also answer "What's IBM's phone number?." But the answer to "What's D3M's phone number?" will not necessarily answer "What's EBM's phone number in Armonk?." The reason is that the more specific question fits all the conditions of the less specific question but the less specific question 55 does not include all the conditions of the more specific question. Of course, this test is still subjective.

Below are examples of more specific questions posed in an unrestricted manner.

More Illustrations

How can you reach IBM

What's IBM's phone number? What's EBM's Internet address Can you reach EBM's manager's by flying a blimp over their headquarters?

Who were the main actors in Casablanca? What was the full cast of Casablanca?

What time do the buses to New York leave today?

When do the afternoon buses to New York leave today?

When do the buses to New York leave after 3:00 p.m. today?

What is an example of furniture?

What is an example of Lx)uis XEV style furniture? What is an example of a chair?

What is the poverty rate in Washington, DC?

According to the Brookings Institution, how many people in Washington D.C. are below the poverty line?

What percentage of households in Washingtonian D.C. are on welfare?

What does the census say about the poverty rate in Washington, DC?

"Oma"?

What is the definition of "oma"?

Does "oma" mean some kind of cancer? What is a hybridoma?

What does an arterial plaque look like?

Arterial plaque in a ten minute video by NIH?

An illustrated guide to arterial plaques?

Artierial plaques according to drawings by Harvey? Until someone fully understands how ideas work we probably will have no precise definition of more specific. Meanwhile, in a given SOD the standards can vary and can be judged by humans. The examples above show there is much room for controversy as to whether a question is more specific than another. Nevertheless, the benefits of using natural langauge and letting people use their common sense can outweigh the costs in confusion.

Both the restrictive and unrestrictive definitions can be implemented in a system.

A Method of Using More Specific Questions

Now we describe a method for implementing more specific questions in the SOD. We discuss the method in three sections.

Section 1. About Storage and Use

How the system enables users to grow networks of questions and answers by storing more specific questions. And how the system enables users to move around in those networks to get and supply answers.

Section 2. About the Pay-off Estimate

How the system registers and estimates the demand for answers when Requestors can express interest in multiple answers.

Section 3. About Searching

How the system helps users find satisfactory questions and answers fast.

Section 1: Building and Moving Around in Question and Answer Nets

In the system described in the parent, questions are stored, and answers are stored to correspond directly to those questions. This section, which has four parts, describes how the system stores a new type of question that we have called a More Specific Question (MS-Q) and describes how people use this type of question. In part 1 we again define MS-Q's, this time giving rules about how they are stored in the system. In part 2 we describe new procedures that the system requires for enabling people to use MS-Q's. In part 3 we illustrate key steps of these procedures. And in part 4 we give examples of Requestors and Suppliers using MS-Q's. Part 1. Rules Defining How MS-Q's Are Stored

1. An MS-Q is a question.

This means that an MS-Q is like any other question in that users can enter it, store it, find it, and store an answer to correspond to it.

2. An MS-Q is a question that is stored to correspond directly to another question.

This means that an MS-Q is linked directly to another question, which we will call a Less Specific Question (LS-Q). By "linked directly" we mean that an MS-Q is stored such that when a user enters a linked LS-Q, the MS-Q can be accessed by default or in response to a command. And further, a user can jump from one linked question to another. Rather than say that an MS-Q is a special type of question, we can just as well say that the link created between two questions is special.

3. Any question, including an MS-Q, can have an MS-Q linked to it.

This means that a question can have an MS-Q linked to it and that MS-Q can have an MS- Q linked to it and so on and so on.

4. There is no limit to how many MS-Q's can be linked to a question.

(Of course, a system designer could set a limit.)

5. Users decide whether the link between an MS-Q and an LS-Q is valid and users can nullify an invalid link.

This means that users, not the system, judge whether an MS-Q is really more specific than a question it is linked to (a partial exception, discussed below, is the case of Restricted MS-Q's). Further, the system can enable users to take action to nullify a link they consider invalid.

Restricted MS-Q's

As discussed, MS-Q's can be divided into two types, restricted and unrestricted.

2.1 A Restricted MS-Q includes the exact same information as the LS-Q it is linked to and includes extra information as well.

This means that the system can in certain cases recognize whether a Restricted MS-Q is valid or not because the system can recognize a mismatch between the LS-Q and MS-Q. However, a system can eliminate this possibility by enabling users to create an MS-Q just by entering the information that is to be added to the LS-Q. The system can also enable a user to choose whether the extra information is added to the beginning or end of the LS-Q.

Linking Further Explained

Linking is a familiar term for the process of connecting two records in memory so that they can be accessed from one another. In the SOD the records we are concerned with are questions, not just the question strings but all the information that is collected to correspond to those strings. A question string can be said to name a record. The information in the record can include an answer, whether the answer is in the system, the price of the answer, the length of the answer, the POE and, any other information that the system has registered about the question and about the answer that corresponds directly to the question. When we say a first and second record are linked directly we mean several things:

a. The link is named to describe the semantic relationship between the two question strings.

b. While a user is at a first record the system can display at least the question string of the second record. The system may display this second string by default or in response to a command. If by command, the command would correspond to the name of the link, for example, "Get MS-Q's." From the first record, the user may be able to access more, or even all, of the information in the second record, depending on the rules of the particular system.

c. When a user is at a first record, the system can access all information at the second record and can make decisions based on that information. For example, if many MS-Q's are linked to a question, the system could determine which ones to show based on the information held in each.

d. The system enables a user to travel from the first record to the second.

e. The system can register when a user travels from one record to the other. This information can be kept in each record and/or kept in a third record created to store information about movement on the link.

f . The system can access records that are indirectly linked to each other and can enable users to access those records as well. How Answers Correspond to Questions

The system also requires rules that define how many answers can correspond to a question. There is no hard and fast rule; it is a design decision. For simplicity's sake, we adopt the rule below.

6. Only one answer can correspond directly to a question.

This means that only one answer can correspond to a question that has no linked MS-Q's. If a question has linked MS-Q's these might have their own direct answers. If so, these answers correspond indirectly to the original question, the LS-Q. Hence this rule differentiates between a direct answer and an indirect answer. A question can have one direct and multiple indirect answers. Further, it can have only indirect answers. (Rules for outputting answers are discussed later.)

Finally, we recall a rule from the parent.

7. An answer can correspond directly to multiple questions.

The system described in the parent allowed a single answer to answer multiple questions. This rule can be very useful where MS-Q's are concerned.

Part 2. Procedures and Functions for MS-Q's

To implement the rules above the system needs new procedures and functions. (Procedures and functions are both sets of steps, the main difference being that procedures are sequences that include functions.)

Follow the Signs

Before getting into a lot of details about these procedures, let us get some perspective and see basically what is being added to the system described in the parent. Basically, functions are added that enable users to link questions, to identify which of two linked questions is more specific, and to jump from one linked question to another.

These additions mean that a question, while still being a sign that tells about an answer, can also be a sign that tells about other questions. Further, these additions mean that users can find an answer by following the signs. In the system of the parent, a person would find an answer by entering the corresponding question. If the result was unsatisfactory, the user would have to enter another question. In the new system, a user can zip from sign to sign. What's more, the user can add new signs and link them to existing ones, letting other users follow his path.

Returning to the bazaar, let's say that the products are not answers but clothes. And let us say that a buyer asks for pants and that a sign exists for pants. This sign might point to other more specific signs about pants, for example, for khakis, jeans, cords, and others. Now let's say a buyer selects the sign for khaki's. He would then zip to this sign where he might find khaki pants but he also might find directions to more specific signs, for example, for pleated khaki's, loose-fit, 100% cotton, pre-washed, and others. Again he might pick one of these and then find directions there to more specific signs such as those describing certain sizes. Eventually he might find a sign that described the pair of pants that he wanted. It probably would not be for the exact pair of pants he wanted, but it could be close enough.

At that point he could request the pants and hope that they were there. (The sign could tell him if they were there and the price as well, and the estimated reward for supplying the pants.) On the other hand he might not find a sign for the pair of pants he wanted, for example no sign might describe his size. And so he could ask for a certain type of pants in his size and the robots of the bazaar would set up a sign for those pants, and could link it to the sign he is at.

Now let's say the rider is a producer and he wants to supply khaki pants. And say he finds that the sign saying "khaki pants" already has pants in stock, but not the ones he has in mind. The pants there might be khakis with pleats while he might want to supply khakis without pleats. And so he could: 1) have a sign set up saying "khaki pants without pleats," 2) supply the khakis without pleats and, 3) link the sign to the sign saying "khaki pants."

To illustrate the situation with answers rather than clothes, take the case of someone looking for a recipe for chocolate chip cookies. A sign for such a recipe might direct a person to more specific signs listing toll-house, and a variety of other recipes. A person picking "toll-house" might then find directions to more specific signs such as those for toll-house cookies made with walnuts, or margarine, or turbinado sugar, and so on. Eventually, the person might find the recipe he wanted.

Thus the bazaar is transformed into land of linked signs (or signomats as we also call them). A question gains an extra role, that of an intersection that can have any number of paths leading in and out. The intersection has a signomat in the middle and the signomat now has a large telescreen, like an airport telescreen, telling people the destinations they can zip to. So a person can stop at the intersection and buy something or just get directions to another signomat. Now back to the procedures that the system includes to make this scheme work.

How the Description Below Adds to the Description of the Parent

In the parent we described how a user could ask a question in Request Mode and possibly get an answer. Further we showed how the system included functions for registering demand and outputting a POE. We also showed how a user could supply an answer in Supply Mode. And we described various other possible steps and functions such as those for price testing and quality control.

Now we are adding a whole new capability to the system but let us stress that the basic functions remain. The central idea is of a question where demand is collected and where users can get an answer and a POE, and where users can supply an answer as well. The functions for making these things possible, such as the pay-off formula, all remain, though they may be modified. Rather than repeat what has been said about these functions, we will describe mainly the things that are added.

We will combine the old procedures with the new ones and call them both options because they correspond to the options that the new system presents to users. These options can be in menu form. When a user chooses an option, further choices may be possible and can be presented in a sub-menu.

Each option can have many variations. For example, the option of Getting MS-Q's can display MS-Q's by default or in response to a command. This option can also allow MS-Q's to be shown according to certain search parameters. These are just a couple examples. The point is that numerous variations are possible and we only have time to delve into certain ones. We will explain the basic steps.

One thing that is different from the parent is that in describing the options we do not differentiate between Request and Supply modes. That is because the point of the new procedures is to enable users to build networks of questions and answers, and to move around in those networks. Users do these things in both the roles of Requestor and Supplier, and therefore, Requestors and Suppliers usually use these procedures in the same way. Morevover, the system can allow users to switch roles easily. In building the data-base, and moving through it, the main difference between Requestors and Suppliers is that the actions of Requestors may be registered as demand information while those of Suppliers are not. (Of course, Requestors usually do more searching and Suppliers enter answers.) In the discussions then, we assume a user has declared which role he is in and that he can switch at any time.

(As for Check Mode, we do not go into it but note that a user in this mode would also use the same procedures for moving around the data-base.)

As mentioned previously, two topics have their own sections. These are the topics of the Pay¬ off Estimate (registering and calculating demand) and of Searching. Both topics involve functions that are part of the main menu options but these functions are put in their own sections for the sake of clarity. The key thing first is to describe how the systm allows questions to be linked to each other. Linked questions allow users more choices of answers. It is these choices that can then make registering demand and searching more complex. So we first explain how the choices are created then we describe functions for dealing with those choices.

Being At a Question

With the new system it is natural to think of a user being "at" a question because he can now move from one question to another. Being "at" a question was never brought up in the parent because there was no need; a person who entered a question was then "at" the question. While there, the user could transact business — make an offer, recieve an answer, see a pay-off estimate, supply an answer, and so on. In the new system, the meaning is the same as, except that once at a question a user can do more things. When a user arrives at a question, especially one that is already in the system, a POE might be shown along with a question automatically, even though a user does not request an answer to the question.

The user can get to a question by entering it, by confirming a best match, or by moving to it from another question. We will call the question that the user is at the current question.

Options

As seen in figure 5, once a user is at a question, the system presents him with a list of options. The system lets the user: a. Get an answer 210, b. Get MS-Q's 211, c. Get other questions 212, d. Enter an MS-Q 213, e. Enter an answer 214, f. Enter a new question-label 215, g. Link the current question to an existing question 216, h. Zip to another question 217, i. Rephrase the last entered question 218, j. Enter a new question 219, k. Stop 220.

We now describe these options one at a time but not in the order above.

Entering a Question

Before a user is at any question, he must use the procedure for entering a question. Once he gets to a question he can also use this procedure to get to another question.

When he enters a question the system searches for an exact match. If there is no exact match, the system stores the question and creates a demand record for it. The system then looks for a best match. If there is no best match the system alerts the user that there is no best match. If the user likes, he can rephrase the question.

If there is a best match or matches the user can select a match. If he does, the selected question becomes the current question.

The user may be satisfied with a best match candidate, but he may still prefer his original question. Further, he may want to link his original question to the best match question. Thus even though the user chooses a best match, the system stores the original question, and any rephrasings the user enters.

In the bazaar the entering a question procedure is equivalent to telling the cab driver which signomat to go to. If no such signomat is already in the bazaar, the robots of the bazaar construct the one that the rider has described. After taking him to it, the cab takes him to on a tour to see one or more similar sounding singomats. If the rider is satisfied with one of these he can tell the driver to stop. If he is not satisfied, the cab returns him to the new signomat the system has constructed for him.

Rephrase the Question When a user, especially a Requestor, enters a new question, he may be starting a new search or he may be rephrasing a previous question. The system may enable the user to distinguish between starting afresh and rephrasing a question. If so, the system includes a command for identifying the next question entered as a rephrasing of the last question entered.

In the bazaar this is analogous to a rider giving the driver slightly different directions, hoping to get to a signomat that already exists in the bazaar.

Zipping to Another Question

When a user is at a question, the system can enable him to move to (zip to) a linked question, or to any other question the system shows on screen or otherwise makes available to him. The system includes a select command so the user can designate which question he wants to move to. The command may consist of clicking on a question that is shown on screen. As is pictured in figure 6, to move to a question, a user would click on the zip tool 221 and then click on a question on screen. The selected question would then become the current question and die information associated with that question would then also appear on screen.

In the bazaar this option is equivalent to a rider telling the driver to go to another signomat that user has seen either at the current signomat or during his trip.

Getting MS-Q's

When a user is at a question, the system enables him to see the directly linked MS-Q's. The system may show these automatically or in response to a command. The system can also display the number of MS-Q's that are directly linked to the current question. Once the system displays the MS-Q's, the user can select any one of them to zip to. The process can be continued in the direction of greater specificity, unless there are no MS-Q's linked to the question that the user is at.

The system can also enable the user to see more than one level of MS-Q's. This type of viewing is especially feasible when the MS-Q's are Restricted MS-Q's. And the system can tell the user the maximum depth and average depth of the MS-Q tree is that the user is on (the actual depth depends on the route a user takes). As shown in figure 9, the system can enable the user to select 310 only the Restricted MS-Q's. When a Restricted MS-Q is shown, the system may output only the extra information the MS- Q contains over the current question.

The system must include defaults to determine the order in which MS-Q's are shown when there are too many MS-Q's output at once. In this case, the system can enable the user to scroll through the MS-Q's. Also, the system can enable the user to determine which MS-Q's to see according to various criteria.

In the bazaar, Getting MS-Q's is like viewing the telescreen that shows signomats that are linked to the signomat the rider is at. The telescreen may show these automatically or the rider may have to press a button to see them.

Getting Other Questions

When a user is at a question the system can enable him to see and move to more than just the directly linked MS-Q's. For example, the system can also show linked LS-Q's. This feature is important for it allows the user to backtrack, instead of just going in the direction of greater specificity.

The system can also enable the user to see any question the user has previously entered or been at. In this case, the system keeps a list of the questions that the user has been at and can enable the user to call up this list and select a question from it. The most important of these is the last question the user was at because returning to this question is often the most natural type of backtracking. The system need not show this previous question but can just include a command for selecting it.

The system may include an option whereby the user may ask to see questions that are good matches for the current question but that are not directly linked to that question. The reason for this feature is to enable the user to see questions in the data-base that may be related to the current question but that have not been linked together. This feature enables a user to zip to and possibly link questions that the user might not otherwise find out about.

In the bazaar, a signomat's telescreen would be able to display the less specific signomats linked to the signomat. A rider could then select one of these to go to. Also, the cab meter could keep a list of all the signomats a rider has gone to in a certain trip and can let the rider pick a signomat on the list to return to. Entering an MS-Q and Linking It to a Question

When a user is at a question, the system enables him to enter an MS-Q. The system includes a link command (in figure 6, "Enter MS-Q" 222). The user selects the command, which signifies that the current question is to be an LS-Q, relative to a new question to be entered. The user then enters a new question and the system stores it as an MS-Q to correspond directly to the LS-Q. The user can repeat this process, linking multiple MS-Q's to the question he is at.

As shown in figure 9a, if the system offers the option of entering both Restricted and Unrestricted MS-Q's then the system can enable the user to select 311 which type of MS-Q the user wants to enter. This choice could be presented as part of a sub-menu. As mentioned, with Restricted MS-Q's the system can enable users to enter an MS-Q by only entering information to be added to the LS-Q.

Now it may be that the MS-Q has an exact match in the data-base. Thus when a user enters an MS-Q the system can look for an exact match. If one is found, the system can link it to the current question. The system can also look for a best match for the MS-Q, and output best match candidates. The user might want to link one of these to the current question as well. The search for a match of the MS-Q can enable the user to find and link questions he might not otherwise have seen.

In the bazaar then, a rider can press a button on the signomat that signifies that the next question he enters will be for a more specific signomat and that the new signomat should be linked to the signomat he is at. Then, when the rider asks for a more specific product, the robots of the bazaar construct a signomat for it and paint a magnetic path with arrows pointing from the current signomat to the new one.

Entering an Answer

When a user is at a question, the system enables him to enter an answer. Thus the system includes a command for entering an answer (the system may enable a Requestor to become a Supplier just by entering this "Enter Answer" command). After the user enters the command, and if the question has no direct answer, the Supplier enters the answer and the system stores it is as the direct answer. If the question already has a direct answer, the system tells the Supplier he can only enter an indrect answer and enables him to do so. The Supplier can enter an indirect answer by entering an MS-Q and supplying a direct answer to the MS-Q. He can enter as many indirect answers as he likes.

The system can enable the user to designate whether he is entering a direct or indirect answer. He can enter both a direct and indirect answers, if the current question has no direct answer, or he can enter only indirect answers, if he wants.

To make it easier to enter an indirect answer, the system can enable a Supplier to use a sub¬ menu procedure when entering an MS-Q and an answer to the MS-Q, rather than making the Supplier switch to main menu option for entering an MS-Q. So the Entering an Answer procedure can also include steps for entering MS-Q's.

As discussed earlier, a question is a label that identifies what information a corresponding answer will have. It is often helpful to label an answer in multiple ways. Multiple labels can help people find an answer, just as listing a business under different headings in the phone book can help people find the business. The ability to name an answer in various ways is especially important when dealing with natural language requests where people call the same thing by many diffferent names. For Suppliers, multiple labels are like having multiple advertisements for a single answer. So the system can enable users to enter multiple MS-Q's for a single answer (and the system can include short cuts so that a user does not have to re-enter the same answer each time he enters a new label for it).

In the bazaar, a rider with a product to supply — call it a recipe — can press a button on the appropriate signomat and the signomat will then store the product to dispense to buyers. But, if a product is already in the signomat, then the producer must have a new signomat constructed. He can link this new machine to the original signomat he wanted to supply the product to. And he can have numerous machines set up with different signs for the same product. And he can have all these machines all linked to the original signomat.

Linking Questions to Existing Questions

The system can include a linking tool that enables users to link two questions that are already stored in the system. One way for such a tool to work is for a user to select (click on) the tool and then select a question on screen. The system then creates a link between the current question and the selected question such that the selected question is an MS-Q of the current question.

There are many other ways for selecting two questions to be linked and for designating the relationship between the two. In particular, a linking tool can be selected and then two questions on screen can be selected. In this case, the system would create a link between the two questions with the first question selected being the LS-Q and the second the MS-Q (or vice versa).

In the bazaar, the rider may press a linking button on the signomat telescreen and then select a signomat on the telescreen. The selected signomat then becomes linked to the signomat the rider is at.

Entering a New Label for an Answer

Before explaining this procedure, a quick digression is in order to explain the need for the procedure. Let us look at some possibilities where questions, MS-Q's and answers are concerned.

A question can have no answer, in which case there is no problem. A question can have one direct answer and no MS-Q's, in which case there is no problem. A question can have no direct answer and have MS-Q's that have direct answers. Again there is no problem if the MS-Q's just have direct answers.

A question can have a direct answer and an MS-Q that has a direct answer. Now we may have an problem. Why? Because when a person is at the question and wants an answer, how is he to differentiate between the direct and indirect answer? The question (the LS-Q) describes the direct answer but it also describes the indirect answer. As shown in figure 7, let's say the LS-Q

230 with the direct answer 231 is:

What is the recipe for Toll-House cookies?

And let's say the MS-Q 232 with the direct answer 233 is:

What is the recipe for Toll-House cookies with nuts?

There is no way to differentiate between the LS-Q's direct answer and indirect answer. Both are valid answers to the -LS-Q. (The direct answer for both questions may even be the same; it may be the same recipe with two different labels.) The problem gets worse when many MS-Q's are linked to a question that has a direct answer. Ideally then, the direct answer would be relabelled with an MS-Q so that the answer could be differentiated from the indirect answers.

(It is also possible to do nothing, to allow the direct answer to be described only by the LS-Q even though that question may have many MS-Q's with direct answers. This situation is feasible depending on the rules for outputting answers. These rules, for example, can include extra search parameters so that the direct answer can be differentiated by information other than the question-label.)

If a direct answer is to be relabelled, four people can do the relabelling:

1. The original Supplier can do it, but he may not be easy to alert to the need and he may not be interested in doing it.

2. The new Supplier who puts an MS-Q on the question and thus "crowds out" the direct answer can do it. But this person has a conflict of interest and might not give an accurate label.

3. A system judge can do it, but judges cannot keep up with the need.

4. A Requestor can do it. He might see a direct answer and feel it needs a more accurate label. This type of labelling can help other Requestors find an answer and it can also be an excellent method of quality control. For example, a question may be,

How far is it to Chicago from Washington, D.C. ? and someone may have supplied the following answer,

Less than 1,000,000 miles. Now a Requestor receiving this answer might relabel the answer, for example,

How far is it to Chicago from Washington, D.C. to within 1,000,000 miles?

The rules as to who can do the relabelling can be variable depending on the system. In any case, it can be useful for the system to include a procedure for relabelling an answer. Thus the system can include a command for selecting a direct answer, for example by selecting its "direct" question, and then entering an MS-Q to relabel (or add an extra label to) the direct answer. As shown in figure 7a, this MS-Q 240 would be linked to the original question and would correspond to the original question's direct answer 241.

In the bazaar, this relabelling is like having the system construct a new, more descriptive singomat for a product that is already in a signomat. 70

Getting an Answer

When a user is at a question, the system can enable him to get an answer, whether direct or indirect, by entering a command. (The system may enable a Supplier to become a Requestor just by entering this "Get Answer " command). We should note that in some cases the system may output the answer without a command.

Now, in the system of the parent, a person who entered a question and was therefore "at" the question was presumed to want the corresponding answer. Price tests could be done there to gather more information about what the Requestor was willing to pay, and it might turn out that the Requestor might not get the answer even if it was there. But the point is that it was presumed that the Requestor wanted the anwer and so arriving at a question was registered as demand information.

In the new system, arriving at a question does not necessarily mean that a person wants a corresponding answer, direct or indirect. The person can just be passing through, looking for a good question. So the arrival is not necessarily registered as demand information. Though it depends on the particular system's rules and on the particular answer, a user may have to explicitly express interest in paying for an answer, for instance by entering a Get Answer command, in order for the system to register the demand information, and for the system to output an answer. Of course, price testing could then be done, and other demand information gathered.

Getting an Answer can be the most complicated procedure of the ones we have discussed. That's because the point of implementing MS-Q's is to give users more choices for getting answers. The available answers may be direct and indirect and there may be many available. Or there may be unanswered but linked questions. As mentioned, these expanded choices raise several design issues. For example, when there are multiple possible answers, direct and indirect: a. which one is the system to output?, b. how is demand to be registered when a user may express interest in more than one answer; what should the POE be based on?, c. what if the user is dissatisfied with an answer because didn't think the question described it well and wants to look at another answer?

Our solution here is to skip these type issues for now and discusss them in sections 2 and 3. Here we will take the simplest case where the question has a direct answer and no MS-Q's. As in the parent, the user then asks for the answer, demand information is registered and a POE is outputted, and if the answer is in, the answer is outputted and the Requestor is charged and the Supplier creditted. Now, as discussed in the parent, there are many ways to accomplish these things. For example, price tests can be done. While we will not go over these issues again.

We do note though that in a system using natural language, rules for charging for answers are likely to be different than a system with highly constrained meanings. A person is more likely to be disappointed with an answer that corresponds to a natural language question than with one that corresponds to a highly constrained query. And so a system that handles natural language might have special rules for enabling users to see more than one answer but only pay for one. These rules are highly variable and are feasible in the system of the parent as well. (If the system charges a flat per hour fee for searching the data-base, this issue is not as relevant.)

We also note though that Suppliers as well as Requestors can be interested in whether an answer is in the system. A Supplier might want to know so he can see if a question needs answering or see if someone else has already entered his answer. Two problems arise. One, a Supplier may be forced to pay to see an answer. Two, a Supplier might steal an answer and store it under another label (MS-Q). We do not go into these issues here, only note that the system requires rules for dealing with them. These issues are not new from the parent but they become more pronounced where multiple answers to a natural language question are concerned.

Back in the bazaar, the signomat may or may not have the product — again, call it a recipe — that the rider is looking for. If the rider is interested in the recipe, he usually presses a button. If the recipe is there, and if the rider knows the price in advance, the recipe is dispensed. Another possibility is that the signomat posts a price, and the buyer can then choose to buy or not. Or the signomat can post a message saying, "Well, I might have the recipe and I might not, what are you willing to pay for it?," and let the buyer make an offer. If the recipe is there it is dispensed, if the buyer's offer is high enough. In any case, the signomat registers the details of any buyer offer and displays a POE for the recipe.

Quality Control Functions for MS-Q's

The system can include functions for quality control that enable users to nullify links. The system can allow users to take several actions. Two mains ones are:

1. ask the system judge to invalidate a link,

2. post a complaint about a link for other users to see. So the system can include means for a user to select an MS-Q and post a complaint marker for others to see. Further the system may reward users who properly point out invalid links and may penalize those who create such links.

The system can be self-regulating though without these measures because an invalid link may merely be ignored by users. An ignored link will not benefit its creator, and further, the system may have rules that cause an unused link to vanish.

In the bazaar, this type of quality control is like a rider posting a complaint on the telescreen about a linked signomat and possibly asking a judge to erase the link.

Part 3. Sequence of Operation

We do not show steps for all the options in Part 2 above, just the key steps for the critical options for creating question and answer nets. We repeating things that were said in Part 2, but here give flow diagrams. In the sequence below, selected question corresponds to current question in the discussion above. Below we assume a user has already arrived at a question and now selects an option. As shown in figures 8, 8a and 8b:

New Question

If the user selects "New Question" 250 he enters a question string and the system: a. Inputs 251 the question, b. Checks 252 for an exact match, bl . If an exact match is found, the question is the selected question 253, b2. If no exact match is found, the system stores 254 the question, creates 254 a demand record for it, and checks 255 for a best match, b2a. If no best match is found, the question is the selected question 256, b2b. If a best match is found, the system outputs 257 the match(es) and asks the user to confirm (select one) 258, b2bl. If the user selects a best match question, it is the selected question 259, b2b2. If the user selects none of the matches, the question is the selected question 256, c. Waits for an option to be selected.

Rephrase If the user selects "Rephrase" 260 the system registers 261 that the next question entered is a rephrasing of the previous question entered. When the user enters a question, the system continues with the procedure described just above for New Question.

Stop

If the user selects "Stop" 262 the system exits.

Get Answer

If the user selects "Get Answer" 270 the system: a. Registers 271 demand information (the request, the time of the request, the price offered, and other information depending on the particular system), b. Checks 272 if an answer is in the data-base, bl . If no, outputs 273 a message saying the answer is not found, b2. If yes, outputs 274 the answer, registers 274 a charge to the Requestor and a credit to the Supplier, c. Waits for an option to be selected.

Get MS-Q's

If the user selects "Get MS-Q's" 275 the system: a. Checks 276 if any MS-Q's are directly linked to the selected question, al . If no, outputs 277 a message that no MS-Q's are found, a2. If yes, outputs 278 the MS-Q's, b. Waits for an option to be selected.

Zip To

If the user selects "Zip To" 279 the system: a. Checks 280 if any MS-Q's are currently outputted, al . If no, the system remains at the menu, a2. If yes, the user selects one of the MS-Q's that has been outputted and the system inputs 281 the selection, and makes 282 the selected MS-Q the selected question, b. Waits for an option to be selected.

Enter MS-O

If the user selects "Enter MS-Q" 283 the user enters a question and the system: a. Inputs 284 the question, b. Stores 285 the question to correspond directly to the selected question as an MS-Q of the selected question, c. Creates 286 a demand record for the new question, d. Waits for an option to be selected.

Enter Answer

If the user selects "Enter Answer" 287 the system: a. Checks 288 if a direct answer is in the data-base, al . If no, the system asks 289 the user if he wants to enter a direct answer, a2a. If the user selects yes, he enters an answer, a2al. The system inputs 290 the answer, a2a2. Stores 291 it as the direct answer to the selected question and registers 292 the user's identification data in order to credit royalties, a2. If yes, outputs 293 a message telling the Supplier that a direct answer is already in the data-base, b. Asks 294 the user if he wants to enter an indirect answer, bl . If the user selects no, the system waits for an option to be selected, b2. If the user selects yes, he enters a question, b2a. The system inputs 295 the question, b2b. Stores 296 the new question as an MS-Q of the selected question, and sets 296 the MS-Q as the Latest MS-Q, b2c. Checks 297 if the user has already entered an answer to the selected question or to an MS-Q of the selected question, b2c 1. If no, the user enters an answer and the system inputs 298 it and stores it as the direct answer to the Latest MS-Q, b2c2. If yes, the system asks 299 the user if he wants the last answer he entered to also answer the Latest MS-Q, b2c2a. If the user selects yes, the system stores 300 that answer as the direct answer of the Latest MS-Q, b2c2b. If the user selects no, he enters an answer and the system inputs 298 it and stores 301 it as the direct answer to the Latest MS-Q, b2c2c. Registers 292 the user's identification data in order to credit royalties, and goes to step b.

Part 4. Illustrations: Basic Situations

Now we show some illustrations of how users can build question and answer networks (nets). Having arrived at a question, a user can face three basic situations with regard to direct answers. 1. The question is completely new; and so has no direct answer. 2. The question has been entered before but has no direct answer.

3. The question has a direct answer.

(Note: we do not show the situation where a question has no direct answer but does have an indirect answer. In this case the MS-Q is a question that has a direct answer and so this case does not add much to the discussion.)

What the System Lets Requestors Do

The Question Is Completely New

When a Requestor enters a question that no one has entered before, the system stores it. The question the current question and so the Requestor can enter an MS-Q. We do not picture the user adding an MS-Q, we only picture one new question , in figure 10, and imagine that the question is, What's IBM's phone number? 320.

The Question Has Been Entered Before But Has No Direct Answer When a Requestor arrives at a question that is already in the system but that has no direct answer, he can enter an MS-Q to that question. In figure 10a, we imagine that the user has initially entered, What's IBM's number? 321, and that the system has shown him a best match of What's EBM's phone number? 322, which he finds satisfactory. He then adds two MS-Q's, or tech support? 323 and What's a 1-800 number for IBM? 324. The first MS-Q is restricted and the second is unrestricted.

The Question Has a Direct Answer

When a Requestor arrives at a question that has a direct answer, he can get an answer and/or add an MS-Q. We do not picture these situations.

What the System Lets Supppliers Do

The Question Is Completely New

When a Supplier enters a question that nobody else has entered, the system stores it and the Supplier can then enter a direct answer. He can also enter and MS-Q and an answer to that. We do not picture these situations. (A Supplier may enter a new question and answer because he feels that people will ask the question in the future, even though no one has asked it in the past. For example, IBM might want to enter, A Directory of IBM Toll Free numbers in the U.S?, and then enter an answer to their own question.) The Question Has Been Entered Before But Has No Direct Answer When a Supplier arrives at a question that has no direct answer, he can: a) supply a direct answer, b) supply an MS-Q and a direct answer to the MS-Q or, c) do both of the above.

Doing both is shown in figure 10b. The Supplier selects the original question, What's IBM's phone number? 325 and enters a direct answer, 800-333-4444 326. He then enters one MS-Q, What's IBM's toll-free number for Inkjet tech support? 327, and then enters the same answer. He then selects another existing MS-Q, What's IBM's phone number for tech support? 328 and adds, for inkjets 329 to this, thus creating another MS-Q. He enters the same answer again. Finally, he selects another existing MS-Q, What's a 1-800 number for IBM? 330, and enters the same answer.

The Question Has a Direct Answer

When a Supplier selects a question that already has a direct answer he can then add an MS-Q and a direct answer to that MS-Q. In figure 10c, a Supplier selects the question, What's a 1-800 number for IBM? 340, and then adds one MS-Q to it, for laptop product information 341, and then enters an answer 342 to that new MS-Q. He then enters another MS-Q,/or laptop complaints and suggestions 343, and an answer 344 for that. Finally, he adds a third MS-Q, for laptop tech support 345, and an answer 346 to that.

Using the Linking Tool

As mentioned, the system can provide a linking tool that enables a user to link any two question that appear on screen. In figure lOd, we show how a Requestor might link a new question with best match candidates.

The user enters,

What's IBM's 1-800 number for tech support? 350 This is the current question. Now we assume the system presents the user with four best match candidates:

What's IBM's toll-free number, for Inkjet tech support? 351

What a 1-800 number for IBM, for laptop tech support? 352

What's IBM's phone number for tech support? 353

What's a 1-800 number for IBM? 354 In figure lOd, the dashed lines 355 represent possible links between the current question and the match candidates. We assume the linking tool works such that the user first selects the tool and then selects two questions, the first being designated the LS-Q and the second the MS-Q. In our example, we imagine that the user selects the current question 350 and then selects the first match 351 above. The system creates a link between the two questions with the match candidate being the MS-Q. The user repeats the process with the second match candidate 352. Now we assume that the user selects the third candidate 353 but selects this question before selecting the current question 350. Thus the current question becomes an MS-Q relative to the third match candidate. The user repeats the process with the fourth match candidate 354. Thus four links have been created, two where the current question is an LS-Q and two where the current question is an MS-Q.

Section 2: The Pay-off Estimate

In the system of the parent, it was assumed that when a question was entered by a Requestor that the Requestor wanted (was willing to pay something for) the corresponding answer. In the new system of linked questions, this assumption may no longer hold because the system can present multiple alternative answers.

l-£t us pretend for a moment that the system is an ordinary department store and that you are a buyer. You ask for khaki pants and the salesperson says, "Well, we may have ten different styles." You have a choice of these and you can add your own custom choice if you want. Now, how would the store register your demand for each of the different styles if the only information you give is khaki pants? What if some or all of those styles weren't in stock? What if the store had no idea when any of the styles would come in? What if the store wasn't sure of what the price for each would be? What if you were just looking? Given all these uncertainties, how is the store to estimate the sales of a given style of khaki pants? And what if you state a style that is not in stock and so you buy another? Should the store register demand for the pants you want or the pants you bought?

This problem of choice is plain with consumer goods like pants, shoes, shampoo, candy bars and things like that. But it is the same problem with answers. (The problem of choice exists for the parent as well but is not usually critical in a system without linked questions.)

We'll never perfectly solve the problem of estimating the sales of alternative choices. In a future application we will tackle the probem more fully though by introducing the notion of linked requests where a Requestor links requests for substitute answers, and possibly states an order of preference for those answers, and possibly states the total amount he will pay for the answers.

We do not address the issue of how to assign demand to alternative direct and indirect answers. Such rules are highly variable. Here we do say that the system needs to differentiate between Requestors who are just passing through a question, "just looking," and those who have an interest in buying an answer to that question. As in the parent, the system can register various kinds of demand information and can ask for this information and/or can gather it automatically. In a system with linked questions, the system registers demand information (in the demand record of a question) when a Requestor:

1. Enters a question that is not in the system.

2. Enters an MS-Q.

In this case, the system registers demand information in the MS-Q's demand record. The system also registers in this record whether the Requestor enters any other MS-Q's to be linked to the same current question. This registering would occur for each MS-Q the Requestor entered for that common question.

3. Explicitly states he wants an answer.

In this case, the Requestor can show he wants an answer by selecting the Get Answer command. Of course, he may end up buying the answer for it might be there. If the system shows him, in advance of his asking for an answer, whether or not an answer is in the system for the current question, then the system needs a command so that the user can explcitly state that he wants an answer and is not "just passing through" the question. Thus the system can have a separate command for indicating that the user wants an answer even though the answer is not in the system. Rather than have an extra command, the Get Answer command can be used here as well. When an answer to the current question is not in the system, Get Answer would signal the system to register demand for the answer.

Combination POE's

Now if an answer is a direct answer to multiple questions (as shown in figure lOd), then the POE for such an answer would be some combination of the POE's for all the questions it corresponds directly to. That is not to say that determining the POE is simple. We use the term "some combination" of the POE's because there are no hard and fast rules. If the answer is a direct answer to multiple questions and if these questions have no indirect answers, no alternative answers, then the issue is more straightforward and the combined POE might be based on a simple sum. But when multiple alternatives are involved, no clear rules exist. Basically though, for the purpose of estimating the future sales of an answer, multiple question- labels should be treated like one label because they are just different ways to ask for the answer.

"Get the POE"

A system may show a POE for a question by default. Otherwise, the system must include a command for showing the POE. The system can include a separate "Get POE" option. When a user selects this option, the system enables him to see POE information about the current question including, possibly, information about the POE's of linked MS-Q's. The system can show the average POE and a maximum POE for linked MS-Q. The system might show the POE's of MS-Q's by default though, along with the MS-Q's themsleves.

Another Reason the SOD Works

It may seem that letting people enter MS-Q's would only lead to a scattering of individual question throughout the data-base with no demand accumulating for individual answers. The situation would be like each buyer of pants wanting only his own personal style with no single style gaining enough sales interest for someone to supply the pants. Yet while users will state their personal preferences they will also settle for someone else's style if that is what is in the "department store" at the time. Further, users have an incentive to join in common choices so that an answer will be supplied. Thus, the system enables people to express their personal preferences and to agree with the preferences of others, which leads to the most popular styles, in general, being provided.

Section 3: Searching

The rules for entering MS-Q's and linking questions make it possible for a question to be linked to a great number of other questions. In fact, the number of links can potentially explode. The alternative paths thus created can cause confusion for a user who wants to find an answer, or find a good question. The situation is akin to getting too many "hits" when searching in a conventional data-base. So the system can include functions for making searching easier. These functions can come in two broad types: those that restrain the linking of questions, and those that use extra selection critieria for choosing which linked questions to see and which answers to get from the linked questions.

Restraining Rules (Functions)

Some rules the system can include for restraining the linking of questions are:

a. Charging users for entering questions.

b. Charging users for creating links.

c. Treating questions and links as investments where a user is charged rent for storing a question and creating a link, but is also paid when other users use the questions or the links. "Use" can mean travelling through the question or on the link. In other words, questions and links can be treated like answers in the sense that storing an answer can cost a Supplier in rent but may garner royalties. Questions and links in general would have lower rents and royalties than answers.

d. Forbidding automated linking, for example, by limiting a user to creating a maximum number of links per period of time.

e. Forbidding plagiarism.

Extra Search Parameters

When a user is at a question and there are too many linked questions, particularly MS-Q's, to be shown at once, the system can include defaults for determining which MS-Q's to show. The system can also enable a user to enter additional search parameters to choose which MS-Q's and answers to see. These choices of parameters and of system defaults can be the same. So let us first discuss some possible parameters the system can enable a user to enter .

A User Selects "Get MS-Q's" When a user selects the Get MS-Q's option and there are too many MS-Q's to output at once, the system can enable the user to enter some combination of the following selection criteria for choosing which MS-Q's to see:

a. More question information.

The user could enter additional information to the current question, rather than re-enter a whole new question. This information can then be best matched to the MS-Q's. (The system may also add the new information to the current question and treat the combined information as a new question and try that new question against the whole data-base.)

b. Price.

The user could specify a price level for the answer he wants. Thus the MS-Q's shown would be those that correspond to answers under a certain price. The MS-Q's might correspond indirectly to answers at various price levels. In this case the system could still show an MS-Q but only if it corresponded to some answer below the stated price threshold.

c. Quality control.

The user could specify that he wants to see only answers that have passed certain quality control inspections. In this case the system would need ways for users to enter reviews of answers.

d. Length of answer.

The user could specify the length of answer he wants.

e. Most popular MS-Q's by answers bought.

The user could specify that he wants to see the MS-Q's that correspond to the most popular answers according to those answers that have actually been bought.

f. Most popular MS-Q's by destination.

The user could specify that he wants to see the MS-Q's that other users have travelled to most from the current question.

g. Most popular MS-Q's by answers wanted.

The user could specify that he wants to see the MS-Q's that correspond to the most popular answers according to those answers that have the highest demand (by highest POE or by highest request rate), though the answers may or may not be in the system. h. By direct answers that are in the system.

The user could specify that he wants to see the MS-Q's that have direct answers (MS-Q's may have no direct or indirect answers).

A User Selects "Get Other Questions"

A user who selects the Get Other Questions option can use the same selection criteria as those above except, of course, that the questions he is referring to are not MS-Q's. The user can decide whether he wants to see LS-Q's or questions he has been previously at. Hence the system can include an additional criteria, allowing the user to choose questions according to the type of linked questions he wants to see, for example, LS-Q's. (Later, when other types of links are introduced, this "select-a-link" feature becomes more important.)

A User Selects "Get Answer"

A user who selects the Get Answer option can also use the same criteria above, though in this case the user would not want questions but answers. If there were no answers, the system could show MS-Q's without answers and register demand for the corresponding answers. If there were answers, the system would show the answer that best fit the criteria that the user entered.

System Defaults

Having discussed search parameters that users can enter, we see that the system can use some combination of these same criteria as defaults. Of course, the combination depends on the paticular system and the particular questions involved.

Voice Input and Output

In the discussion of the system for handling natural language, it may seem that the multiple choices created by linked questions are suited only for screen input and output. But often people would want to use the system by talking to it, and often users might not have a screen. For example, user might want to use a plain old telephone as a terminal. (In the U.S. patent 5,359,508, a self filling telephone directory is described using phones as terminals.) Yet there is no doubt that choices are much harder to present by voice because they take time to output.

That does not affect the entering of answers though. Answers, even long ones, can be entered voice if the system has voice recognition functions. An answer can be confirmed by the user or "cleaned up" at a later time.

More important and seemingly difficult is the problem of entering a question and then facing multiple MS-Q's. But this problem can be mitigated by using the search criteria described above. For example, a person can ask the computer,

What time does the Louvre open on Tuesday?

Please give me the most popular answer bought, under 25 cents.

With these criteria added to a question, the system can find an MS-Q to the original question and output an answer to the MS-Q that has satisfied the most people of should suffice for most users.

Though the answer may originally have been supplied by text, it can be outputted by text-to- speech functions, or it can be outputted on screen as well of course.

Where voice recognition and the SOD are concerned, questions have an inherent advantage. They are usually short. Thus a user can enter a question by voice in multiple ways and the system can look for a best match using the multiple phrasings. Normally, voice recognition suffers from problems of interpretation, but because questions are usually short messages, multiple phrasings can enable the system to find a good match (we will see the same principle involved in translating questions into other languages). Once the system arrives at a good match, additional selection criteria can be applied, espcially those concerning the most popular answers. Of course, using voice entails limitations, but the point is that people can find answers even in a system that has linked questions.

More Kinds of Questions and Links Between Questions

Let's recall the foundation task of the system: to count how many people seek the same answer.

Perhaps we should discuss what the same answer means to people. But we will not do this. Instead we will just note that different questions can correspond to the same answer. We have already noted and discussed this subject somewhat. Now let us discuss the subject more. The general idea is that two questions can be related by whether they correspond to the same answer or whether they might correspond to the same answer.

We note four types of relationships. Before we explain these briefly we realize that problems of interpretation will always exist and so we discuss these relationships as they would exist in a given user's mind. This is reasonable because links between questions are created by indivdual users. Other users can then agree with those links or agree that the interpretations are valid or not.

Less Specific to More Specific

We have already discussed this relationship between questions.

Synonym to Synonym

Here two questions are meant to ask for the same answer.

Synonym: Who wrote "Can't Buy Me Love"?

Synonym: What group wrote the song "Can't Buy Me Love"?

Less Complete to More Complete

Here an answer to the more complete question will always answer the less complete question but not always vice versa.

Less Complete: Did Elvis write "Can't Buy Me Love"? More Complete: Who wrote "Can't Buy Me Love"?

Less Complete: Is Johnny in the class?

More Complete: What's a list of all the students in the class?

Less Complete: How far is it to Chicago from Washington?

More Complete: Let me see a Rand McNally roadmap of the United States?

Less Complete: Is Paris, the City of Lights, in England? More Complete: What does the Encyclopedia Brittanica say about Paris?

Related to Related

This is a poor name for the relationship between two questions where the answer to one question might answer the other question. The relationship can be one way in that the answer to one question might answer the other question but not vice versa. Or it can be two way in that the answer to one question might answer the other question and vice versa.

Related Question: What's the name of that restaurant on Willow?

Related Question: What kind of food does that restaurant on Willow serve?

Related Question: What's on the menu of John's Pizza? Related Question: How much is a pizza at John's Pizza?

Related Question: Why should you correct your posture? Related Question: What does bad posture do to you?

Related Question: Where can you get hologram stickers in the U.S.? Related Question: Who sells high security stickers in the U.S.?

Related Question: How does a car engine work?

Related Question: How does an internal combustion engine work?

(Two questions might have multiple relationships above in common, for the relationships are not mutually exclusive.)

Rephrase Link

We point out one more general type link which we will call a Rephrase Link. A user searching for an answer might enter various questions that could correspond to that answer. He might not further specify the relationship between two such questions except to say that they are both entered in pursuit of the same answer. He does this by entering a rephrase command before entering a new question. This command signifies that the question is a rephrase of the previous question. The system can then create a link between the two questions. The user may further specify the relationship between the two questions later. Or he may not and the link would remain to identify the questions as rephrases of each other.

Just as a user can enter a new question and create a link between it and another question signifying that the new question is more specific than the other question, a user can create the links described above between questions. The links identify the relationship between two questions. Because the relationships have to do with whether the questions have the same answer, the links can help other users find answers or express interest in the same answers. As shown in figure 11 , in addition to enabling users to enter MS-Q's the system can include options for entering: Less Specific Questions 370 Synonymous Questions 371 More Complete Questions 372 Less Complete Questions 373 Related Questions 374.

When a user enters one of these he does it relative to the current question or another selected question. In other words, the process is directly analogous to entering an MS-Q. Likewise a user can move to (zip to) one linked question from another. All the other processes are analogous to those explained with MS-Q's.

The purpose of these new links is different though than the purpose of MS-Q's. MS-Q's are meant to solve the Endless Answers problem. The type of links described above are above all meant to solve the Matching Up Questions problem.

But we should realize that at bottom the problems can both be viewed as the same in the sense that the idea is to enable Requestors match up their intentions. (Suppliers may also need to do this when advertising an answer.) MS-Q's help Requestors match up their intentions by allowing Requestors to better explain their intentions. The links above enable Requestors to express related intentions. That is to say that they enable Requestors to express the answer they want in different ways. Thus the links above can help people find and match up related intentions. That can help people find answers and join together in expressing demand for answers. Multi-lingual SOD

A great goal is for an SOD is to be an international data-base where people can enter questions and answers in different languages, where a person can ask a question in, say, Swahili and get an answer back in Swahili that has been supplied originally in, say, English. It is a great goal not just because of the ideal of international cooperation but because of the economics of the system. In general, the more people who are willing to pay for an answer the more likely it is to be supplied, and further, the less it will cost per person. If 5 people speaking English want to know, What are the names of all the delegates to the United Nations?, the pay-off may be too small to induce someone to supply the answer. But if, say, 3 French speakers, 7 Japanese speakers, 2 Russian speakers, and others speaking other languages, also want the answer then it should usually have a better chance of being supplied and should cost each person less.

For the system to be multi-lingual, it needs to do two things:

A. Match up questions posed in different languages that ask for the same answer.

B. Input an answer in a given language and output the answer in other languages.

There are many ways these tasks can be accomplished. Because it is simplest, we will first discuss a system that has a central language such that all questions and answers are translated into the central language and answers are outputted from the central language. After describing the key steps involved with a central language model, we will discuss other methods.

Matching Up the Same Questions Posed in Different Languages

As mentioned in the section on best matching, the problem of matching up questions in different languages is a best match problem with translation functions added. A translated question is often just an ungrammatcial question spoken in a the language it has been translated into. The key step really is the matching step, which is necessary as well with questions posed in a single language. We will take the case of two languages because this case illustrates the basic steps involved. In our example, we assume the languages are French and English and that the question is entered in French and translated into the central language, English. And we assume that the user wants the answer that corresponds to the question entered (the user may be passing through but we assume he is not). The steps the system requires are shown below and pictured in figure 12.

1. Input 400 French question string. Anita Morris, comment-elle est morte? 2. Translate 401 French string into English string.

We pretend that the system translates the French into, How did Anita Morris die?

3. Check 402 for match among English questions stored.

4. Exact match found 403?

If no, store 404 the English version, create a demand record for the question. If yes, translate 405 match into French and go to step 6.

5. Best match(es) found 406?

If no, output 407 a message saying that no match was found and enable the user to rephrase the question.

If yes, translate 405 the best match into French. We will pretend that in the SOD there is a question, Anita Morris, death of?, and that this question is the one that is the best match found.

6. Output 408 translated match(es).

The best match string is then translated into French and returned to the French user for confirmation. We pretend that the translated version is, Anita Morris, la morte?

7. Have user confirm 409 whether any match is adequate.

The Requestor now sees the string in French, but it is different than the one he entered originally, because it is a translation of the best match. So the Requestor has the choice of rejecting the translated match or not.

If he rejects it, the system can enable 410 him to rephrase the question.

If he accepts the best match, the system can then register 411 demand information for the question, as posed in English. In other words, at this point the system treats the situation as if an English speaker has entered the question, Anita Morris, death of?.

8. Check 412 if the answer exists in English.

If no, output 413 the POE and enable the user to rephrase the question.

If yes, the translates 414 the answer into French and output 415 it and the POE.

Why It's Feasible to Match Up Translated Questions Let's see why questions in different languages can be translated and matched well, even though we know that machine translation is a hard problem. Well, is machine translation a hard problem? That depends on what you are doing. If you are translating a long piece of text then problems of interpretation mess the translation up. A translation program can't give multiple versions of each phrase in the piece because the result would be a jumble. But with short messages, like questions, multiple versions are possible. A program can make multiple interpretations of a question and try these against a data-base in a given language.

Then, when the system finds matches, it can translate these back into the original language, giving multiple interpretations of these. That number of versions can be manageable. And, because questions are usually short, the user can easily confirm a translation. Moreover, a user can easily rephrase a question multiple ways, so as to have a good shot of matching. In other words, because questions are usually short, problems of interpretation can be overcome by both the user and the system trying different possibilities.

The system also can include a feature that enables a user to more easily correct a mistranslated word or phrase. When the best matches are popped back, the system can enable the user to change some word or phrase and then re-enter the question without restating the whole thing.

Translating Answers into Different Languages from Central Language

Matching up questions is one essential task of a multi-lingual SOD, the other is inputting answers in different lanauges and then outputting the answers in other languages. The SOD can include functions that translate an answer into a central language. From this language, the system can translate an answer into any other language.

However, the problem of translating answers can be tougher than that of translating questions because answers are often longer than questions and therefore can suffer from the problems of machine translation. The system can overcome this problem by enabling users to: a. enter different language versions of an answer, b. enter improved versions of machine translations.

In order to do this, the system can accept an answer in any language and store it in that language. For example, the system can store an answer in French. When necessary, it can be translated into English or Spanish or any other language that the system has translation functions for. Now, as shown in figure 13, when a Requstor asks for an answer, the system can allow the user to select 420 a what language the user wants the answer in and can register 421 that choice. By registering the language a user wants (the system may default to the language that s Requestor's question is in in) the system can create a POE for that answer in that language. The system can also register demand for an improved translation, whereby a user who gets a machine translation can request an improved translation. Thus the system can create and output two POE's for an answer, one combined POE 422 of all the requests for an answer regradless of language, and one POE 423 for a human translated version of an answer in a given language.

A person seeing the POE for a given language can provide his own answer in that language or he can improve on a machine translation of an answer that has already been entered. The system can output 424 the human version if one is stored, otherwise the system outputs 425 a machine version. The person who supplied the answer first may get the bulk of the royalties while the person who improved the machine translation can get a share each time his improved translation is sold.

Thus the system can keep multi-lingual versions of an answer to correspond to a question, regardless of the language a question is posed in. And that is an important point, questions can be stored in various languages and need not correspond to the languages of the answers. So let us now address the issue of matching up questions when there is no central language.

Translating Questions Into Multiple Languages

The system may not have a central language at all. It can translate questions into multiple languages, trying various ones until it gets a match. When a user enters a question, the system first checks if a match exists in the language of the question. If not, the system can translate the question into multiple languages and look for the best match. The translation procedure described above can then follow. For example, if a French speaker asks when the Louvre opens, the system checks first whether any other French speaker has asked this question. If no good match exists, the question can be translated into various languages until a good match, if any, is found.

The system can store the mult-lingual versions of a question. This record is like a multi-lingual dictionary/thesaurus on a question (a bi-lingual dictionary, like French-English, is really a thesaurus). For example, a question can be translated from French into English. If a user confirms the translation then the system keeps a record for the question and this record has two versions of the question. Then let us say that the question is entered in Spanish and that it is translated into French and that this translation is confirmed. The the system would have three versions of the question in the record. The system will have done two translations, one of the French into the English and one of the Spanish into the French. Which languages get translated into which depends on the system.

When the system keeps multi-lingual versions of a question, the demand tally for that question is based on the sum of the times the question has been entered in each language. If the question has been entered 4 times in Japanese, 3 times in French, and 2 times in English then the tally is 9. The system can keep a combination tally as well as a tally by language.

Claims

ClaimsI claim:

1. a data collection and retrieval system comprising in combination the following elements and steps:

a computer and data-base having:

—input means for inputting data-requests and data corresponding to said data-requests, along with user identification information,

—output means for outputting said corresponding data, along with projected pay-off estimates,

—memory means for storing said data-requests and corresponding data,

—processing means for comparing data-requests, finding corresponding data, registering times of inputs, calculating formulas and registering charges and payments due to users,

said computer performing the following steps upon the inputting of a data-request by a user:

a. registering said user's identification information in said data-base,

b. registering user's preference in supplying or retrieving the data corresponding to said data- request,

c. if the user prefers to supply said corresponding data, looks for said corresponding data is said corresponding data-base,

cl . if corresponding data is found, outputting a message telling the user that the data is already in the data-base,

c2. if no corresponding data is found, allowing the user to input the data, storing the corresponding data and registering that royalties are due to the user when said data is requested, d. if the user prefers to retrieve data corresponding to said data-request,

dl . registering time and date said data-request is inputted,

d2. registering amount user is willing to pay for data corresponding to said data-request,

d3. finding data corresponding to said data-request is in the data-base,

d3a. if corresponding data is in the data-base, outputting the data, registering a charge due by said user who inputted the data-request and a royalty due to the user who supplied the data, adding one to the number of said data-requests, calculating a pay-off formula that projects the estimated royalties due to a user who inputs the correct data corresponding to said data-request, and outputting the resulting pay-off estimate,

d3b. if no corresponding data is in the data-base, checking if said data-request is stored in the data-base,

d3bl . if no, storing the data-request and setting the number of said data- requests to one, and calculating said pay-off formula, d3b2. if yes, adds one to the number of said data-requests, and calculates said pay-off formula,

d3b3. outputting the resulting pay-off estimate.