[go: up one dir, main page]

WO1996013007A1 - Systeme pour recueillir et fournir des donnees, pouvant calculer les frais a payer et les royalties a percevoir par les utilisateurs - Google Patents

Systeme pour recueillir et fournir des donnees, pouvant calculer les frais a payer et les royalties a percevoir par les utilisateurs Download PDF

Info

Publication number
WO1996013007A1
WO1996013007A1 PCT/US1995/012630 US9512630W WO9613007A1 WO 1996013007 A1 WO1996013007 A1 WO 1996013007A1 US 9512630 W US9512630 W US 9512630W WO 9613007 A1 WO9613007 A1 WO 9613007A1
Authority
WO
WIPO (PCT)
Prior art keywords
data
answer
sodb
request
requestor
Prior art date
Application number
PCT/US1995/012630
Other languages
English (en)
Inventor
Michael T. Rossides
Original Assignee
Rossides Michael T
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Rossides Michael T filed Critical Rossides Michael T
Priority to AU41930/96A priority Critical patent/AU4193096A/en
Publication of WO1996013007A1 publication Critical patent/WO1996013007A1/fr

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q30/00—Commerce
    • G06Q30/04—Billing or invoicing
    • G—PHYSICS
    • G07—CHECKING-DEVICES
    • G07F—COIN-FREED OR LIKE APPARATUS
    • G07F17/00—Coin-freed apparatus for hiring articles; Coin-freed facilities or services
    • G07F17/0014—Coin-freed apparatus for hiring articles; Coin-freed facilities or services for vending, access and use of specific services not covered anywhere else in G07F17/00
    • G—PHYSICS
    • G07—CHECKING-DEVICES
    • G07F—COIN-FREED OR LIKE APPARATUS
    • G07F17/00—Coin-freed apparatus for hiring articles; Coin-freed facilities or services
    • G07F17/16—Coin-freed apparatus for hiring articles; Coin-freed facilities or services for devices exhibiting advertisements, announcements, pictures or the like

Definitions

  • the invention relates to a system for collecting and retrieving data and charging users for finding the data and paying users for supplying the data.
  • the parent disclosed a new type of data-base system.
  • the novelty of the parent 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 goal of the parent was to describe this loop.
  • the loop is a quite basic and can be built upon.
  • This continuation then adds new matter to the parent in three areas.
  • 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.
  • 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.
  • 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.
  • this pay-off creates an incentive to correct or update faulty data.
  • Figure 1 shows a flow chart of a basic SODB.
  • Figures 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.
  • Figures 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • An 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.
  • 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.)
  • 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 The function that is the heart of the SODB.
  • the POM has three sub- functions:
  • D-Meter The Demand 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)
  • I-Signal Input 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.
  • 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.
  • 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.
  • 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.
  • Pay-off Formula 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.
  • N the number of times the data has been requested
  • T the times those requests took place.
  • the POF estimates how many future requests there will be and then multiplies that by a royalty rate to arrive at the POE.
  • N the tally, N, of data-requests and data-uses as supplied by the D-Meter.
  • the Pay-off formula can be infinitely diverse based on historical data and other factors.
  • 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.”
  • 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.
  • the SODB When a Requestor requests an answer not in the SODB, the SODB outputs the POE.
  • the SODB 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).
  • the I-Signal 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.
  • a basic SODB includes of the following elements and procedure as shown in figure 1 :
  • Computing means for executing SODB functions are included in the Appendix.
  • 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 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.
  • 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.
  • 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.
  • the SFTD self-filling telephone directory
  • 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.
  • the SFTD also has a sign-on function that allows users to identify themselves for billing and payment purposes.
  • the SFTD stores the ID data.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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 ID 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.
  • a lowest price locator 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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
  • 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.
  • 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.
  • 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.
  • the LPL finds 59 the lowest price.
  • 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.
  • the SODB is well suited to collecting data that is processed in what may generally be referred to as lists and tables. Let 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.
  • 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.
  • 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.
  • 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.
  • 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?”
  • 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 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.
  • 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?"
  • 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.
  • 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.
  • 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.
  • the SODB can display: 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.
  • 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.
  • 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
  • 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.
  • the SODB can ask the Requestor whether he has asked for the same answer before and whether the request 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 they are interested in the answers the 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 data. Even if the data is outputted, the SODB can still ask Requestors to input this information.
  • a Requestor could also specify how long 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.
  • 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.
  • the SODB might ask register 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.)
  • the parent 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 parent 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 parent 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.
  • steps for gathering information about what Requestors are willing to pay for answers are willing to pay for answers.
  • 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.
  • SODB price tests 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. 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.
  • 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.
  • 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 parent this record was called the Demand Meter).
  • 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.
  • 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.
  • the system stores 105 the time of the request and adds 105 one to the request tally.
  • FIG 3a a price testing sequence is illustrated in which the system presents 1 10 a price to the Requestor.
  • the system enables 1 1 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.
  • the system registers 1 12 the rejection at that price, calculates 1 18 the POE, and outputs 1 19 the POE.
  • the system registers 1 13 the acceptance at that price, and then checks 1 14 to see if the answer is in the system. If the answer is not found, the system tells 1 15 the Requestor and then calculates and outputs the POE. If the answer is found, the system outputs 1 16 the answer, registers 1 17 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.
  • 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.
  • the system tells 126 the Requestor that answer is not in.
  • the system then asks 127 the Requestor to make an offer.
  • the system can include steps for enabling the Requestor to make various offers.
  • the system can register 128 a non-binding offer.
  • 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.
  • 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.
  • 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.
  • FIG. 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.
  • the system calculates and outputs the POE.
  • Figure 3c shows another price testing sequence that includes both types of price tests.
  • 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.
  • the system includes steps for registering when the Requestor makes an offer and steps for limiting the number of offers the Requestor can make.
  • 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.
  • the system 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.
  • 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.
  • 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.
  • the system checks 160 whether the Requestor has made an offer that has been rejected.
  • 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.
  • the system asks 163 the Requestor to make an offer.
  • the system registers 164 the offer.
  • the system 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.
  • the system tells 166 the Requestor that the answer is not found and, as usual, calculates and outputs a POE.
  • 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.
  • the system accepts the offer, it outputs the answer and registers charges and royalties and calculates and outputs a POE.
  • a price offer is at a single price.
  • 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.)
  • the SODB may present a Requestor with a projected price.
  • 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.
  • 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.
  • 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.
  • the actual price the original Requestors pay is not definite, but a projected or expected price.
  • 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.
  • 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.
  • 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.
  • SODB 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.
  • 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.
  • the SODB only outputs routing information to the Requestor but does not make the connection to the storage computer.
  • 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 parent 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 parent 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
  • 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.
  • 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.
  • 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.
  • 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.
  • An SODB should include more functions than the basic ones described above. Some useful functions are described below.
  • 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.
  • 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.
  • 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.
  • 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).
  • 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.
  • the SODB can have a function that allows a user to record this claim and send it to the Manager.
  • 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.
  • 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.
  • 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.
  • the SODB can have a function that charges Suppliers an amount of money, a penalty, for providing wrong answers.
  • 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.
  • the SODB can have a function that pays Suppliers to update answers.
  • a Supplier an Updater.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • changing facts, such as prices, the time allowed for reversion could vary depending on the situation.
  • 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.
  • the SODB can have a function that allows Suppliers to enter answers only after having entered a passcode.
  • the SODB can have a function that records the Supplier's voice for identification.
  • 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.
  • 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.
  • 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.
  • 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.
  • a function can be added to the POM that tells not only the Pay-off Estimate but also an estimated per hour rate.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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 "WILL SUPPLY", after hearing the POE for the answer.
  • the function would store the Requestor's ID data along with the Question.
  • 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.
  • 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.
  • EVPM expected value payment method
  • the main question in an EVPM is how to insure fair bets.
  • the bets are between the SODB and its users, both Requestors who owe money and Suppliers who are owed money.
  • Requestors who owe 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. Sandra 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.
  • 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).
  • PMF Probabilistic Metering Function
  • a period of time is broken up into sub-periods. For example, a day might be broken up into minutes.
  • the probability that the meter will be on during a sub-period is decided upon by the SODB manager.
  • 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 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.
  • the Payment Register 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 ID 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.

Landscapes

  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Business, Economics & Management (AREA)
  • Development Economics (AREA)
  • Economics (AREA)
  • Marketing (AREA)
  • Strategic Management (AREA)
  • Finance (AREA)
  • General Business, Economics & Management (AREA)
  • Accounting & Taxation (AREA)
  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)

Abstract

L'invention concerne une base de données qui s'organise toute seule et qui fait payer (7) les utilisateurs qui y trouvent des données et qui paie (7) ceux qui y entrent les données trouvées. Le système a un mécanisme de rétroaction appelé compteur de paiement (11, 14), qui indique à l'utilisateur quelles données doivent être fournies, compte tenu du nombre de demandes (13) concernant ces données faites au cours du temps. Le compteur de paiement fournit des projections de paiement (10) pour la fourniture de données.
PCT/US1995/012630 1994-10-24 1995-10-23 Systeme pour recueillir et fournir des donnees, pouvant calculer les frais a payer et les royalties a percevoir par les utilisateurs WO1996013007A1 (fr)

Priority Applications (1)

Application Number Priority Date Filing Date Title
AU41930/96A AU4193096A (en) 1994-10-24 1995-10-23 A data collection and retrieval system for registering charges and royalties to users

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US32770494A 1994-10-24 1994-10-24
US08/327,704 1994-10-24

Publications (1)

Publication Number Publication Date
WO1996013007A1 true WO1996013007A1 (fr) 1996-05-02

Family

ID=23277680

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/US1995/012630 WO1996013007A1 (fr) 1994-10-24 1995-10-23 Systeme pour recueillir et fournir des donnees, pouvant calculer les frais a payer et les royalties a percevoir par les utilisateurs

Country Status (2)

Country Link
AU (1) AU4193096A (fr)
WO (1) WO1996013007A1 (fr)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6961714B1 (en) * 2000-02-13 2005-11-01 David Levine Method of quantifying royalty owner rights

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US4843562A (en) * 1987-06-24 1989-06-27 Broadcast Data Systems Limited Partnership Broadcast information classification system and method
US5003584A (en) * 1990-04-16 1991-03-26 At&T Bell Laboratories Method and apparatus for the billing of value-added communication calls
US5101352A (en) * 1989-06-29 1992-03-31 Carolina Cipher Material requirements planning system
US5418713A (en) * 1993-08-05 1995-05-23 Allen; Richard Apparatus and method for an on demand data delivery system for the preview, selection, retrieval and reproduction at a remote location of previously recorded or programmed materials
US5465213A (en) * 1990-07-27 1995-11-07 Ross; Harvey M. System and method of manufacturing a single book copy

Patent Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US4843562A (en) * 1987-06-24 1989-06-27 Broadcast Data Systems Limited Partnership Broadcast information classification system and method
US5101352A (en) * 1989-06-29 1992-03-31 Carolina Cipher Material requirements planning system
US5003584A (en) * 1990-04-16 1991-03-26 At&T Bell Laboratories Method and apparatus for the billing of value-added communication calls
US5465213A (en) * 1990-07-27 1995-11-07 Ross; Harvey M. System and method of manufacturing a single book copy
US5465213C1 (en) * 1990-07-27 2001-09-18 On Demand Machine Corp System and method of manufacturing a single book copy
US5418713A (en) * 1993-08-05 1995-05-23 Allen; Richard Apparatus and method for an on demand data delivery system for the preview, selection, retrieval and reproduction at a remote location of previously recorded or programmed materials

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6961714B1 (en) * 2000-02-13 2005-11-01 David Levine Method of quantifying royalty owner rights

Also Published As

Publication number Publication date
AU4193096A (en) 1996-05-15

Similar Documents

Publication Publication Date Title
EP0712516B1 (fr) Systeme de collecte et d'extraction de donnees gere par un compteur de facturation
US6510418B1 (en) Method and apparatus for detecting and deterring the submission of similar offers in a commerce system
Short et al. What's your data worth?
US6131085A (en) Answer collection and retrieval system governed by a pay-off meter
US20080133417A1 (en) System to determine quality through reselling of items
Wurman et al. Specifying rules for electronic auctions
MX2010008511A (es) Metodos y sistemas para proporcionar un programa de tarjetas de pago dirigido a segmentos abandonados.
WO1997015362A1 (fr) Systeme de communication mettant en oeuvre des paris
JP2004534313A (ja) 消費者の寄付に基づいて市場の需要を判定するための方法およびシステム
JPH06295390A (ja) 点数管理システム
MX2007011675A (es) Aparato y metodos para proporcionar mensajeria de cola de espera sobre una red.
Peukert et al. Digital disintermediation and efficiency in the market for ideas
CN113570257A (zh) 基于评分模型的指标数据评估方法和装置、介质、设备
KR20210009051A (ko) 블록체인 기반의 쇼핑몰에서 제품을 사전에 검증하는 방법 및 그 시스템
JP6528074B1 (ja) 会計処理装置、会計処理方法、会計処理プログラム
EP4425416A1 (fr) Système de détermination d'affaires devant être déterminées lorsqu'un joueur effectue une action, procédé et programme
KR100413589B1 (ko) 실시간 경제 변수 지표를 도입한 복권 구입 및 판매 시스템
WO1996013007A1 (fr) Systeme pour recueillir et fournir des donnees, pouvant calculer les frais a payer et les royalties a percevoir par les utilisateurs
CN109858952A (zh) 服务场景下的数据处理方法和装置
JP2002203283A (ja) 点数管理システム
US20020087411A1 (en) Expected value methods ans systems for paying and qualifying
JP7260708B1 (ja) 情報処理装置、情報処理方法及びプログラム
CN117873906B (zh) 一种交易系统中奖励金额发放的测试方法及装置
WO1996025709A1 (fr) Systeme de collecte et de recherche d'informations destine a enregistrer des frais ou des redevances pour des utilisateurs
EP1199645A1 (fr) Système d'information basé sur la valeur de l'information

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A1

Designated state(s): AM AT AU BB BG BR BY CA CH CN CZ DE DK EE ES FI GB GE HU JP KE KG KP KR KZ LK LR LT LU LV MD MG MN MW MX NO NZ PL PT RO RU SD SE SI SK TJ TT UA UZ VN

AL Designated countries for regional patents

Kind code of ref document: A1

Designated state(s): KE LS MW SD SZ UG AT BE CH DE DK ES FR GB GR IE IT LU MC NL PT SE BF BJ CF CG CI CM GA GN ML MR NE SN TD TG

DFPE Request for preliminary examination filed prior to expiration of 19th month from priority date (pct application filed before 20040101)
121 Ep: the epo has been informed by wipo that ep was designated in this application
REG Reference to national code

Ref country code: DE

Ref legal event code: 8642

122 Ep: pct application non-entry in european phase
NENP Non-entry into the national phase

Ref country code: CA