WO2001067300A1 - Improved parameter-value databases - Google Patents

Improved parameter-value databases Download PDF

Info

Publication number
WO2001067300A1
WO2001067300A1 PCT/US2000/005638 US0005638W WO0167300A1 WO 2001067300 A1 WO2001067300 A1 WO 2001067300A1 US 0005638 W US0005638 W US 0005638W WO 0167300 A1 WO0167300 A1 WO 0167300A1
Authority
WO
WIPO (PCT)
Prior art keywords
parameter
user
values
database
terms
Prior art date
Application number
PCT/US2000/005638
Other languages
French (fr)
Inventor
Robert Fish
Original Assignee
Robert Fish
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 Robert Fish filed Critical Robert Fish
Priority to AU2000233946A priority Critical patent/AU2000233946A1/en
Priority to PCT/US2000/005638 priority patent/WO2001067300A1/en
Publication of WO2001067300A1 publication Critical patent/WO2001067300A1/en

Links

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/90Details of database functions independent of the retrieved data types
    • G06F16/95Retrieval from the web
    • G06F16/954Navigation, e.g. using categorised browsing
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/24Querying
    • G06F16/242Query formulation
    • G06F16/2428Query predicate definition using graphical user interfaces, including menus and forms

Definitions

  • This invention relates to the field of wide area data networks and databases that index large numbers of different types of items.
  • the Internet is by now the world's largest computer network, interconnecting millions of computers.
  • One side effect of this large size is that the vast amount of information available on the Internet is often extremely difficult to access. Similar problems tend to occur on any large network, and in this discussion the Internet is discussed herein as an example of such a network. Similar problems occur in searching large databases in general, whether or not part of a network.
  • interpersonal speech one can sometimes adequately describe an item using decidedly non-specific language, such as "the clippie thing on the end of the rope", but in computer searching such descriptions are not helpful at all.
  • An automated yellow pages type search for example, can only access items if the exact name is known.
  • Keyword searches using existing technology are also exceedingly poor at handling ranges. For example, if one is searching the Internet to buy a LexusTM automobile between
  • the present invention includes improved parameter-value databases and methods of using the same that provide significant benefits to individuals loading data and/or conducting searches.
  • the database is used to properly identify overlap between search data and target data where the data sets contain any combination of single values, multiple values, and ranges.
  • items are loaded onto the database as sets of parameter- value pairs, with subsets of such pairs being further sub-correlated for various purposes, including establishing display order, chronological order, or coupling groupings of parameter-value pairs.
  • users are allowed to add new parameters to the database in such manner that the database develops a user-evolved categorization system.
  • users are presented with word or other value lists to assist them in searching the database, and the lists become smaller as filters are applied.
  • parameters and/or values are presented in listings for selection by users. This is potentially a huge advantage over the common Internet type search engines which provide no guidance at all in selection of parameters and values.
  • the listings may advantageously be presented in alternative alphanumeric and relative historical usage formats.
  • At least some of the information is classified using a classification structure having at least three levels. More preferably at least one of the levels contains a large number of classes that span (i.e., are applicable to) a high percentage of classes in the other levels.
  • systems and methods described herein can be applied to substantially all products, services, and information.
  • contemplated systems and methods can be used to describe every conceivable type of product and service currently listed in consumer or business-to-business telephone yellow page books, as well as all products and services commonly listed only in specialty consumer or industry catalogs.
  • the types of information that may be stored are equally universal. It is specifically contemplated, for example, that systems and methods described herein may be utilized to index such diverse types of information as news items, historical facts, book reviews, questionnaires, opinion surveys, case law, and the topics discussed in various chat rooms.
  • Figure 1 is a schematic of a preferred classification selection interface.
  • Figure 2 is a schematic of a preferred interface for adding data.
  • Figure 3 A is a schematic of a preferred interface for retrieving data.
  • Figures 3B - 3E are examples of preferred "complete record” displays.
  • Figure 4 is a preferred parameter selection interface.
  • Figures 5 A - 5B are examples of usage of a preferred values selection interface.
  • Figure 6 is a table showing a preferred three-level classification system.
  • Figure 7 is a preferred units selection interface.
  • Figure 8 is a preferred interface for accessing stored searches.
  • Figure 9 is a preferred database structure for storing and retrieving parameter-value data.
  • Figure 10 is an example of a preferred data interface providing information on "polyesters”.
  • Figure 11 is an example of a preferred data interface providing information "drug use”.
  • Figure 12 is an example of a preferred data interface providing information on "Clinton”.
  • Figure 13 is an example of a preferred data interface providing information on a questionnaire.
  • a preferred user interface 100 generally includes an item description section 110, a tree search selector 120, a classification display table 130, record navigational buttons 140, and other navigational buttons 150.
  • the item description section 1 10 is typical of many search engines in that a small space is allowed for one or more search terms, and in some embodiments there may be a button that allows for complex Boolean searching.
  • the search here may be different from typical searches, however, in several ways.
  • the search term or terms may advantageously be compared first against the classification structure itself, i.e., against the names of the various classes, subclasses and so forth, and then only applied against the values of parameter/values stored in the database if there are no matches in searching the classification structure.
  • search terms may be coupled together using synonyms, such that searching for one term may pull up records in which the search term is not present, but a synonym is present. For example, searching for the terms "autos", “auto”, “car”, “cars”, and “automobile” may all trigger a search for "automobiles".
  • the tree search section 120 preferably navigates to a pop-up or other series of windows (not shown) which display in sequence the various levels of the classification system. Additional details of preferred classification systems are described in more detail below.
  • the classification display table 130 lists classifications from the classification system that match the search terms.
  • the system is using, or at least displaying, only three levels of classification.
  • Level 1 class names are displayed in the first column 131, level 2 class names in the second column 132, and level 3 class names in the third column 133.
  • the fourth column 134 shows relative frequency of entries using the displayed classifications. These relative frequencies are intended to assist the user in selecting an appropriate classification.
  • the fifth column 135 provides check boxes 135A for users to select a specific classification from among the listed classifications. In this instance the user has selected the first listed classification, and the system has recorded the selection by changing the check box to a check mark 135B.
  • systems may also permit users to select multiple classifications so that a single search could cover many areas. Where selection of multiple classifications are chosen, it is likely that the system will limit the number of selections to a relatively small number, perhaps three or four.
  • the navigational buttons 140, 150 assist the user in navigating the various displays in the system.
  • the buttons first row of navigational buttons 140 are used to view subsets of classifications when more classifications meet the search criteria than can be conveniently displayed at the same time.
  • the classification table 130 displays 10 rows at the same time, which number is most likely a function of the resolution and size of the display screen, as well as the size of the window in which the classification table 130 is displayed.
  • the various navigational buttons 140 would be used to navigate among the many rows.
  • the "21-30" button for example, would display rows 21 - 30.
  • the ⁇ button would display rows 41 - 50, then 51 - 60, and so forth, while the ⁇ ⁇ button would display the last set of rows.
  • the "New Search” button of the second set of navigational buttons 150 provide the user with the ability to clear the screen and start a new search.
  • the "Add Item” button changes focus to an interface such as that shown in Figure 2, in which the user can add a new item to the database.
  • a preferred data entry interface 200 generally includes a selected classification display 210, a data entry table 220, and navigational buttons 230.
  • the classification section 210 echoes a classification chosen in the interface of Figure 1. In the event that multiple classifications are chosen, the classification section 210 may advantageously echo all the chosen classifications.
  • the first column 221 in table 220 preferably defaults with five, ten or some other relatively small number of the most frequently used parameters for the chosen classification or classifications. Any of the parameters can be modified from the defaults, either by overtyping the displayed parameter with a new parameter, or by selecting a parameter from a parameters listing such as that shown in Figure 4. The parameters listing can be displayed by clicking on the adjacent " ⁇ " symbol or other button shown here in column 222.
  • the third column 223 in table 220 records values that the user wants to associate with the selected parameters.
  • the user has chosen to associate the value 6000248 with the Patent No. parameter.
  • the system is preferably designed so that the user can either just type in the value, or select a value from a values interface such as that shown in Figure 5.
  • the values interface can be accessed by clicking on the corresponding " ⁇ " symbol or other button in column 224.
  • the system will limit the maximum number of parameters correlated with any given classification.
  • a typical limit may be 75 or 100 parameters. Users wanting to add a parameter beyond the maximum will likely be given a message to that effect, and asked to use an existing parameter, or try again later. Parameters that have minimal or no usage may be deleted periodically to make room for addition of new parameters.
  • the number of values allowed to be associated with a given parameter and classification may be limited in a manner analogous to limitations placed on parameters, although the limit would most likely be set much higher. For example, there may well be thousands of different dollar amounts (values) that can be associated with the parameter Price for an automobile classification. On the other hand, there may only be twenty or thirty values that can be reasonably associated with the parameter Color for the same classification.
  • the fifth column 225 of table 220 displays the measurement units corresponding to the value on the same row.
  • the corresponding value is pure text so that the units designation is simply listed as "text”.
  • the corresponding value is usually a number.
  • the user can choose among units of measurement in an auxiliary interface (not shown).
  • a user entering the numeral 55291 as a value for the parameter Odometer may be given a choice of Miles or Kilometers as units of measurement.
  • the system may advantageously keep track of default units in a Units Key field 926 with respect to individual parameter-classifications, so that the same literal parameter name may have different parameters depending upon the classification.
  • the parameter Color may be text data (red, blue, white, etc) for automobiles, but numeric data (1.79, 2.30, etc for hair color). Users may also choose to add multiple parameters to describe the same characteristic in different ways.
  • the parameter Height (text) may be used in conjunction with the values Tall or Short, while the parameter Height (in) may be used in conjunction with the values 72.5 or 68.
  • the sixth column 226 shows the " A " or other symbol that can be clicked upon to display a values selection interface such as that shown in Figures 5A - 5D.
  • a user may well elect not to use the values selection interface, and may instead simply type in a literal.
  • the literal would most likely be compared against existing values as a means of confirming spelling, as a means of suggesting alternatives to the user, and as a prelude to adding the value as a new value in the system.
  • the seventh and eighth columns 227, 228, respectively, may well be displayed only to those users who have identified themselves as being advanced.
  • Column 227 stores numbers that can be used to depict correlations between or among the parameter-value pairs for a given entry. These may also be referred to as "sub-correlations" because they provide further correlations among parameters and values that are already correlated by virtue of relating to the same entry or item.
  • One contemplated use is to set control the sort order in which the values are displayed.
  • the value "Patent" in the first data row would be displayed before the value 6000248 for the patent number because the corresponding sort data are 1 and 2, respectively. Examples of using the column 227 data in this manner are set forth in Figures 3B - 3D.
  • a cooking recipe or laboratory procedure for example, generally has multiple steps.
  • the various steps could be stored in the database using sequence identifying parameter names such as Step 1 ,
  • Step 2 Step 3 etc.
  • a user could enter all of the steps using only one or a small number of parameters with names such as Steps, Preliminary Steps, or Follow Up Steps. In these latter cases the user could still keep the steps in proper order upon later display by entering the step order as column 227 information.
  • the data need not be integers, so that one could have steps 1.0, 1.1, 1.2, 1.21 , 1.3, 2.1 and so forth. It should be apparent that the chronology of historical events can be designated in a similar manner.
  • column 227 is the grouping of subsets of parameter-value pairs. For example, a manufacturer selling an item that has multiple color choices would probably want to enter the differently colored telephones in the database as completely different entries. On the other hand the manufacturer may want to store O 01/67300
  • Column 227 stores delimiters that can be used in displaying data in desired formats such as those set forth in Figures 3B - 3D. At present it is preferred to use only simple characters such as asterisks, slashes, hyphens, carriage returns ("next line”), and so forth. In the future, however, it is contemplated to include more sophisticated delimiters, or even codes that are not delimiters per se, but affect the format of the information being displayed.
  • the navigational buttons 230 assist the user in navigating the various displays in the system.
  • the New Search button transfers the user back to a searching interface such as that shown in Figure 1.
  • the Cancel button clears the display of Figure 2, and returns the user back to the previous interface.
  • the Record button starts the process of performing validity checks on the data of Figure 2, and if the data clears the validity checks, ultimately causes the data to be loaded onto the system.
  • the parameter- value database is also a self-evolving (i.e. user- evolved) database.
  • the ability to add new parameters and/or values provides users with a mechanism for delineating characteristics of their items (products, information, or other data) that distinguish such items from those of others. For example, a person selling a car may want to advertise that he or she is the original owner. If Original Owner is not listed as an available parameter, the car owner can add that parameter, along with a likely value of Yes.
  • the Original Owner parameter will either "bubble to the top” or the listing (because subsequent users tend to choose that parameter), or remain at the bottom (because subsequent users tend not to choose that parameter).
  • the evolution process also takes care of variant spelling of parameters.
  • the database may well include both Color and Colour as parameters, but one of them will likely bubble to the top, and one of them will likely sink to the bottom.
  • a data retrieval interface 300 generally includes a selected classification display 310, a three-row parameter/filter/units selector 320, a main data display table 330, column navigation slider 340, record navigation buttons 350, and other navigation buttons 360.
  • the selected classification display 310 serves substantially the same function as the selected classification display 210 of Figure 2 - it displays the classification or classifications that the user is using, preferably classification(s) selected in an interface such as that of Figure 1.
  • the information displayed in the main data display table 330 is dependent upon the listed classification(s), as well as the selected parameters and filters as described below.
  • the three-row parameter/filter/units selector 320 defaults to the five, ten or some other number of the most frequently used parameters for the chosen classification, in a manner similar to that of Figure 2.
  • the parameters are displayed as column headings whereas in Figure 2 the parameters were displayed as row headings.
  • columns and rows in display formats are more or less conceptually interchangeable, and all permutations of these are contemplated as alternative embodiments, as well as matrices in which the cells are non-contiguous horizontally, vertically, or in both directions.
  • the first row 321 of the parameter/filter/units selector 320 is labeled with the term "Parameters" at the far left.
  • the cells to the right are in pairs, with each pair having the same final letter.
  • cells in row 1 , columns 2 and 3 form a pair labeled 325A, 326A
  • columns 4 and 5 form a pair labeled 325B, 326B
  • columns 6 and 7 form a pair labeled 325C, 326C, etc.
  • the first cell in the pair shows the parameter name used to define the data in the column of main display table 330 immediately below.
  • cell 325A shows the parameter Type, which in this example refers to the type of intellectual property. Examples may be Patent, Copyright, Trademark, Trade Secret, Contract, etc.
  • the second cell in each pair displays a " ⁇ " symbol or other button that leads the user to a parameter selection interface such as that depicted in Figure 4.
  • the second row 322 of the parameter/filter/units selector 320 is labeled with the term "Value" at the far left.
  • An alternative and possibly preferable label may be "Filter”.
  • the cells to the right are again in pairs, with the first cell of each pair either blank or displaying a value used for filtering, and the second cell of each pair is a " ⁇ " symbol or other button that leads the user to a value selection interface such as that depicted in Figures 5A-5D.
  • the second row 322 is intended to receive values used in filtering the corresponding parameters.
  • the filters are preferably null at the outset, but can be filled in by the users.
  • One of the most important aspects of preferred systems is that they can display and filter on any combination of parameters.
  • the user could then filter to a particular make, or perhaps filter on some other parameter.
  • competing systems such as the current version of autobytel.com, a user can only access the database by first selecting a make and a model. That type of very limited access to the database is just not satisfactory in many circumstances.
  • the third row 323 of the parameter/filter/units selector 320 is labeled with the term "Units" at the far left.
  • the cells to the right are once again in pairs, with the first cell of each pair displaying a units measurement, and the second cell of each pair displaying the " ⁇ " symbol or other button that leads the user to a units selection interface, as for example the units selection interface depicted in Figure 7.
  • Typical units measurements are "text"
  • the units information is employed in displaying the data in the corresponding column of the main data display table 330, with the system making appropriate calculations and rounding. Using this system a user can readily filter for and view Odometer data as miles or kilometers, regardless of how such data is stored.
  • the "Go Fish” button 328 tells the system to apply the parameters and value filters selected in rows 322 and 323, and produce the results in the main data table 330. Of course, other terms could be substituted for "Go Fish", including “Apply”, or “Go”, “Build Table”, or “Submit”, and the button 328 could be located elsewhere in the interface 300.
  • the main display table 330 preferably contains between 6 and 30 columns, with many of the columns being positioned off the screen at any given time. This can be accomplished by the usual WindowsTM type of horizontal slider 340, or any other suitable manner, such as tab type navigational buttons that would show subsets of the columns. Where more columns are utilized than can conveniently fit on the display screen, the columns with filters can advantageously be moved to the far right. Thus, if a user is employing 10 columns in the main display table 330, and 3 of those columns contain a filter, then those three columns would preferably be automatically moved to columns 8-10, respectively. In so doing the first seven columns would contain the variable data of interest to the user. Such automatic movement of columns, however, is not depicted in the main display table 330 of Figure 3A to better illustrate the preferred filtering techniques.
  • users can move directly to the " ⁇ " symbol or other button, or alternatively users can type a parameter or value into the corresponding cell of the table.
  • the system verifies the validity of the entry, and provides assistance (such as transfer to the appropriate parameter or value interfaces) if the entry is invalid.
  • Values are displayed in the various rows of the main data display table 330 that correspond to items matching the selected classification 310, the parameters selected or defaulted in row 321, and the filters selected in row 323, in short for values matching the search request.
  • the table sorts by default from left to right, but can advantageously be resorted by data within any given column by clicking on the corresponding ⁇ or T sort buttons 321 A, 32 IB at the head of the desired column.
  • the cells of the table can include text, icons, hyperlinks to web pages, files or the like. Where a hyperlink is in the cell, users can preferably jump directly to the linked site. Where a video, audio or other file is indicated, users can preferably open and play or display that file as the case may be. Where an e-mail address is indicated, the system preferably opens an interface to facilitate recording and sending of an e-mail to that address.
  • the record navigation buttons 340 and other navigation buttons 350 are intended to be similar to those used on other systems, and are self-explanatory.
  • the Select button brings up an interface such as those depicted in Figuies 3B - 3E.
  • the Spreadsheet button is used to send the data in the main display table 330 to the user as an Excel, or perhaps some other spreadsheet.
  • Figure 3B depicts a very simple preferred "full record” display.
  • the user has chosen to store only text information.
  • the text displayed is " 1998 Lexus LS400, white, gold package, 12,000 miles, perfect inside and out, original owner, Fullerton, CA, Bob 714-555-5555, $32,900, firm". This display can be achieved by inputting the following information into the interface of Figure 2:
  • Price firmness firm text 14 Figure 3C depicts substantially the same information as described above with respect to Figure 3B, but with the addition of a picture, modification of the sort order, and modification of the delimiters. This display can be achieved by inputting the following information into the interface of Figure 2:
  • Figure 3D depicts yet another format for a "full record" that may be selected by a user. This display can be achieved by inputting the following information into the interface of Figure 2:
  • each delimiter other than a space is followed by a space, and hyphens are preceded by a space.
  • Another convention may be that all words are displayed in lower case except for recognized proper names, and the first word after a period.
  • Still another contemplated convention is that the user can choose not to designate any sort order at all by leaving the sort field null. In such cases the data may be displayed in a simple multi-column parameter-value listing such as that depicted in Figure 3E.
  • alternative conventions are also contemplated, and innumerable combinations of conventions can be developed by clever programmers.
  • the system may also store default display formats for various classifications, which can be used by the system to display data in "classified" type listings when the person or company posting the data (i.e., the data provider) does not specify a custom format.
  • data can be "mined" from an original classified type listing format, converted into parameter value pairs, and then redisplayed in a classified type format similar or even identical to that of the original.
  • One step in a preferred strategy for such data mining would be to locate the target data using a web crawler, or have the data provider transfer or point the target data to the mining system.
  • the target data can then be parsed into terms, preferably using a listing of standard parsing characters (i.e., delimiters such as spaces, slashes, hyphens, commas, and so forth), or using one or more parsing characters designated by the data provider.
  • the system would also attempt to determine an appropriate classification for the target data, preferably by locating a classification code in the target data, or having the data provider designate a classification in some other manner. It may also be desirable to apply all of the parsed terms against the database to determine which classification contains the highest number of such terms as values. Once the classification is known, the parsed terms can be applied against the database to determine corresponding parameters, and stored as parameter value pairs. If the system also associates the delimiters from the original format with the respective terms as discussed above with respect to Figures 3B - 3E, the stored data can be redisplayed at a later time with an appearance similar to that found in the original listing.
  • the data provider would include the data on the web page in either a memo field or in a simple flat table.
  • a typical listing may be "Long stem red roses for sale. Shipped daily from Hawaii. Only $24.99 per dozen", with the listing followed by a picture of the dozen roses.
  • This information would preferably be forwarded to the mining system by the data provider with a selected classification designation, perhaps a code such as "A27", or less preferably with a corresponding recognized classification such as "agriculture-flowers-marketplace".
  • Preferred classifications and codings are discussed below with respect to Figure 6. If, however, the classification were not known, the system could still obtain a working classification by locating those classifications containing as values the parsed terms "red”,
  • the system can work backwards by locating a parameter for each, or at least many, of the values. In that manner Color may be determined to be a valid parameter for the value Red, and Plant Name may be determined to be a valid parameter for the value Roses.
  • the system could thus automatically resolve the parameter-value pairs from which the original listing could be substantially recreated. For the roses example, the data may resolve as follows:
  • an automatic data mining system may take substantially the same steps as a human user would take in separating data into parameter- value pairs, and then loading such pairs onto the system.
  • Another contemplated method of mining data is to provide a web crawler that scans web pages or other documents sequentially, or according to some other logic. In that scenario it is preferred that the web pages or other documents would tag selected information using tags that specify classification, parameters, and values.
  • the system could use XML type tags for this purpose, some other tagging format, or even a combination of tagging formats - provided that the system could resolve the data into parameter-value pairs.
  • a parameter selection interface 400 generally includes a header 405, a parameters table 410, Apha/Frequency navigation buttons 452, slider 413, a word entry interface 440, and other navigation buttons 454, 456.
  • the parameters table 410 preferably lists some or all of the parameters presently stored for a previously chosen classification 405.
  • the first column 41 1 of table 410 lists the available parameters
  • the second column 412 lists the respective frequencies with which the corresponding parameter was historically utilized with respect to the chosen classification 405, while the third "column" 413 is really a slider used to view additional rows.
  • One or more parameters can be selected by clicking on the desired row(s).
  • the default sort for the parameters is by frequency, although users can access alphabetic sort (including alphanumeric or numeric as appropriate) by clicking on the
  • Alpha/Freq toggle button 452 toggles between Alpha when the list is displayed by frequency, and Freq when the list is displayed by Alpha. Users can also access alphabetic sort, and jump to a particular point in the alphabetic sort by entering a literal in the appropriate word entry interface 440, typing a literal in a parameters box (column 1) of table 200, or typing a literal in the parameters box in column 325 A of Figure
  • the absolute number of parameters allowed on the system for any given classification may advantageously be limited.
  • the classification of "real estate-residential-marketplace” may be limited to 80 parameters, while the classification of "office supplies and equipment-desk items-marketplace” may be limited to only 50 parameters.
  • a simple viewing mechanism such as slider 413 will be sufficient to select among the various parameters.
  • the Cancel and Select navigation buttons 454 and 456, respectively, are intended to be similar to those used on other systems, and are self-explanatory
  • a values selection interface 500 generally includes a header 505, a values table 510, a word entry interface 540, and other navigation buttons 552, 554, 556.
  • the values table 510 preferably lists some or all of the values presently being stored for a previously chosen classification and parameter. Here the available values are listed in column 51 1 with corresponding frequencies in column 512. Slider 513 is used to view additional values. As with the parameters selection interface of Figure 4, the default sort is by frequency, although users can access alphabetic sort (including alphanumeric or numeric as appropriate) by clicking on the Alpha/Freq toggle button 452. The Alpha/Freq toggle button toggles between Alpha when the list is displayed by frequency, and Freq when the list is displayed by Alpha.
  • Users can also access alphabetic sort, and jump to a particular point in the alphabetic sort by entering a literal in the appropriate word entry interface 440, typing a literal in a parameters box (column 1) of table 200, or typing a literal in the parameters box in column 325 A of Figure 3.
  • the absolute number of values allowed on the system for any given classification and parameter may well be limited with respect to text values, but is probably unlimited with respect to numeric values. Thus, although it may be that a simple viewing mechanism such as slider 513 will be sufficient to select among the various values, other viewing mechanisms such as the alphabetic buttons or record number selectors discussed above may be utilized.
  • the record navigation buttons 530 and other navigation buttons 540 are intended to be similar to those used on other systems, and are self-explanatory.
  • Figure 5B depicts the interface of Figure 5 A in which the choices are reduced in number because of filtering of other parameters by the user.
  • the user is presumed to have selected a classification having automobile information as data.
  • the user elected to see the names of all models previously stored on the system with respect to the selected classification, and to list those models alphabetically.
  • the user presumably filtered his data by selecting a value of Chevrolet for Make, and therefore the only values showing for the parameter Model are Chevrolet models.
  • One of the enormous benefits of preferred systems and methods set forth herein is that users can access stored data using any combination of filters, and view the data using any combination of parameters. It is entirely possible, for example, for a user to select for all houses within a given price range, a given number of bedrooms range, and at least 100 feet of lakeside frontage without selecting a location at all. That degree of flexibility in searching is hitherto unknown on the Internet and elsewhere.
  • Figure 7 depicts a preferred interface 700 for selecting an alternative units measurement. Focus to this interface would most likely occur by clicking on the " ⁇ " or other symbol in any of the cells of column 226 of the main data entry table 220 of Figure 2, or on the " ⁇ " or other symbol in any of the cells of row 323, columns 326A, 326B, 326C, etc. of the main data retrieval table 330 of Figure 3.
  • the interface 700 preferably includes instruction lines 710, 720, and a units display table 730, and navigation buttons 742 and 744.
  • the units display table 730 preferably includes only a few conversion units so that the entire units conversion can be readily downloaded to, and operated on the client side of the network.
  • the accuracy column provides indicates how the system will display the converted data.
  • the entry "scientific notation" indicates that the system will display the converted data using scientific notation
  • the "+1 " entry indicates that the system will add one level of accuracy to that found in the source data
  • the "same” entry indicates that the system will use the same of accuracy as that found in the source data.
  • Figure 8 depicts a preferred Saved Searches interface 800, generally comprising a title 810, a main stored searches display table 820, and navigation buttons 831, 832, 833,
  • the main stored searches display table 820 includes a first column 821 containing user defined search designations, second, third, and fourth columns 822, 823, and 824 containing Level- 1, Level-2, and Level-3 class names, respectively, a fifth column 825 containing a designation of how often the search will be automatically run, a sixth column 826 containing a " ⁇ " symbol or other button for accessing the run schedule choices (weekly, monthly, etc), and a seventh column 827 that contains the last run date of the search.
  • There is no slider because in at least preferred embodiments users are limited to a relatively small number of saved searches.
  • the fourth row of data is partially completed because the user navigated to this interface 800 from a current search in the classification of Pets &
  • a Run Schedule is optional. Searches run automatically by the system according to the Run Schedule only include data that is new to the system since the last run date, and searches that are not null are preferably send to the user via e-mail in spreadsheet format.
  • Previously stored searches are accessed by clicking on the appropriate row, and then clicking on the "Select” button 834.
  • Stored searches are deleted by clicking on the appropriate row, and then clicking on the "Delete” button 833.
  • the Cancel button 831 is self-explanatory.
  • One especially useful feature contemplated herein is the ability to perform multi- value and range searches on target data that itself may include multiple values and ranges.
  • data rows 2, 3, and 6 have been highlighted by the user, and all three can be simultaneously selected for inclusion in filtering by clicking on the Select button 556.
  • the same principle can be advantageously applied to the parameter selection interface of Figure 4.
  • preferred embodiments include the ability to enter a value as a literal range, e.g. "between 15000 and 20000". Such a range may, for example, be included as a filter in a values cell of row 322 of Figure 3, or a values cell of column 223 of Figure 2. Because of the way the data structure is set up, (see e.g. discussion below with respect to Figure 9), both multiple value and multiple range searching can be accomplished merely by altering the database query.
  • Quadrant 1 represents the simplest type of search, where both the search data and the target data contain a single value for a parameter of interest. For example, a user searching to buy a dog through the Internet may enter the term "dogs" in a search field of a search engine. In the prior art, a search engine would have typically crawled through millions of web pages looking for tagged keywords, and would likely have stored the keyword "dogs" in an index for pages containing that term. The search engine would then match up the single value "dogs" against the index, and identify to the user the various pages that include the keyword "dogs”.
  • Quadrant 2 is similar to quadrant 1, except that the web pages contain multiple keyed terms for the same parameter.
  • a single web page may refer to both "dogs” and “cats”, which are either expressly or inherently correlated with a parameter such as Type of Pet.
  • the prior art search engines would identify web pages regardless of whether the user searched for "dogs” or “cats”.
  • the user specifies multiple search terms that are concatenated either expressly or inherently using Boolean logic connectors such as "or” and "and”.
  • Boolean logic connectors such as "or” and "and”.
  • Quadrant 1, 2, 4, and 5 searches are known to the extent that they do not involve searches in databases that store descriptions of items as parameter-value pairs.
  • LEXISTM and NEXISTM databases for example, all utilize Quadrant 1, 2, 4, and 5 searches. When applied to self-evolving databases, however, even these simple searches are thought to be novel.
  • Quadrant 3, 6, 7, 8, and 9 searches are all thought to be novel with respect to parameter-value type databases because they involve ranges.
  • a user searching for a car may enter a value such as $17000, and that value is applied against a web page stating that cars are available for between $15000 and $20000.
  • Yahoo!TM, GotoTM, LycosTM, or any of the other prior art search engines there would be no match because the term $17000 does not match either $15000 or $20000. In embodiments of the present invention, however, there would be a match.
  • Quadrants 7 and 8 searches a user may use an interface such as that shown in
  • Figure 3 to enter a value of "between $10000 and $15000" in row 322, column 325B.
  • a Quadrant 7 search preferred embodiments of the present system would located a web page having a value of $13000
  • a Quadrant 8 search preferred embodiments of the present system would located a web page having a multiple values of $10000, $12500, and $13000.
  • a user may be looking for cars with years after 1997, odometer reading less than 50000 miles, and price less than $15000. These searches would apply the indicated ranges against single or multiple stored values for the respective parameters.
  • the Quadrant 9 search is particularly powerful because it can identify items in which the search range overlaps the target range, such as the search range "between $70000 and $80000" matching a target range "$75000 - $1000000". This can be extremely useful, for example, in loading and searching insurance policies and other data.
  • an insurance policy may limit policies to individuals having incomes of "$75000 - $1000000", while a person shopping for an insurance policy may list his income as "between $70000 and $80000.
  • a toy manufacturer may price a particular toy "between $15.95 and $28.95" depending upon the color. A search for that toy would find a match if the searcher entered a price of " ⁇ $20.00".
  • preferred embodiments of the present invention thus include methods of searching a database comprising: storing descriptions of a plurality of different items on the database as sets of parameter- value pairs, in which at least some of the values form a target; providing a search criterion such that at least one of the target and the search criterion comprises a numeric range; and identifying a successful search as occurring when there is an overlap between the search criterion and the target.
  • Such methods may involve Quadrant 8 searches in which the overlap includes a portion of the target having multiple values for a particular one of the items, Quadrant 3, 6, or 9 searches in which the overlap includes a portion of the target having values stored as a range, Quadrant 6 searches in which at least a portion of the search criterion includes a collection of discrete values, Quadrant 7, 8, or 9 searches in which at least a portion of the search criterion includes a numeric range of values, and permutations thereof.
  • More preferred embodiments are self- evolving in that they supply a user providing the search criterion with an ability to add new parameters to the database, and still more preferred embodiments guide the user in the addition of the new parameters by displaying historical summary usage information, such as relative historical usage information on a percentage scale for other parameters previously employed in the same classification.
  • Level 1 (shown in column 1) includes a relatively small number of classes, Advertising & Marketing, Agriculture, Art, Automobiles, Beauty & Grooming . . . Transportation, Travel, and Weapons.
  • Level 2 (shown in column 2) includes varying numbers of classes hierarchically related to corresponding Level 1 classes.
  • the exemplary classification system of Figure 6 is typical in that many or even most of the Level 2 classes make sense only with respect to the related Level 1 classes.
  • Level 1 class of Agriculture one finds Level 2 classes of Animal Production, Chemicals, Crop Production, Florists, etc.
  • These Level 2 classes make sense with respect to Agriculture, but are generally inconsistent with respect to other Level 1 classes such as Art or Automobiles.
  • Levels 1 and 2 can also be described as having a superior / inferior relationship, with Level 1 being relatively superior and Level 2 being relatively inferior
  • An exemplary Level 3 (shown in column 3) includes 89 classes, many of which are referred to herein as "spanning classes" because they are logically related to many or all of the Level 1 / Level 2 classifications.
  • the Level 3 class of Awards could well apply to the Level 1 / Level 2 classification path of Advertising & marketing / Personnel Recruitment. But awards also applies to the Level 1 / Level 2 classification path of Art / Artists.
  • the Level 3 class of Industry Information applies to the Level 1 / Level 2 classification paths of Agriculture / International, Automobiles / Trucks, and Beauty & Grooming / Nails.
  • An alternative Level 3 (shown in column 4) includes only 47 classes. Astute observers will recognize that of the classes have been collapsed, and some of the categories have been eliminated entirely. For example, Importing and Exporting are subsumed under the more general class entitled Trade.
  • Another alternative Level 3 (shown in column 5) is even more collapsed, including only 28 classes.
  • the classes of Consortia and Cooperatives are collapsed into a single class named Companies, and Enthusiasts is subsumed under People. Also, Conventions & Conferences and meetings are merely types of Events, and so have been eliminated.
  • classification can be readily summarized for users in code format.
  • the classification path of Automobiles / Cars / Marketplace could be coded with only four numeric digits as 527 or 8103, or with a three digit alphanumeric code such as G57 or H29. This is because contemplated classification systems may only have about 10,000 or fewer permutations.
  • Individual codes can advantageously be provided to web-site developers for inclusion into their web pages, and used in combination with XML or other tagging system to direct a search engine to automatically apply a desired classification.
  • the classification codes could thus be used by millions of unrelated users in a manner analogous to the way real estate agents us the Thomas GuideTM page and grid codes.
  • Level 1 class of Automobiles may well include a service-related Level 2 class of Repairs & Maintenance.
  • Level 1 / Level 2 classification of Automobiles / Trucks addresses services by inclusion of the service-related Level 3 class of Schools & Training.
  • the type of classification systems contemplated herein can readily accommodate opinions, polls, and indeed information of all types.
  • the presently described systems and methods address these additional types of data very effectively, in part because in the parameter-value aspect the users themselves decide what parameters relate to what classifications, and what values relate to those parameters.
  • Such systems are preferably made to be inherently self-evolving at least in part by providing subsequent users with summary comparison usage information based upon the choices of previous users, and in part by permitting subsequent users to can add new add classifications, parameters, and values instead of being limited by those previously used by others.
  • Summary comparison usage information is preferably communicated to users in the form of listings in which the choices are presented in order of descending usage. In that manner parameters and values that are used more frequently bubble to the top of the list, while parameters and values that are used less frequently sink to the bottom of the list. Very poorly used parameters and values can even be deleted periodically.
  • the term "user” is employed herein to mean an end-user of the database, i.e. an ordinary person or business who is either listing an item on the database, or looking for an item, or both.
  • users of the database can add new classifications, and/or parameters, and/or values, rather than waiting for a programmer or systems designer to do so. In that manner the aggregate of users largely control the evolution of the database rather than a few programmers or other individuals. That is what makes the database or system self-evolving.
  • usage information is employed herein in a very broad sense to include information relating to occurrence, absolute or relative frequency, or any other data that indicates the extent of past or present usage with respect to the various choices. It is contemplated, for example, that the choices for which usage information is displayed would include one or more of item classifications, geographic classifications, parameters, and values. It is also contemplated that the usage information displayed may relate to subsets of choices determined by a user's own previous responses, the term "subset" being employed herein to include proper and improper subsets. Thus, when selecting a minor item classification, the system may display a listing of possible minor item classes determined by the user's selection of major classification, along with relative usage information among the displayed minor classes.
  • the item descriptions displayed, and the corresponding usage information would preferably be a function of the major and minor item classes selected.
  • the parameters and/or values displayed, and the corresponding usage information would preferably be a function of the item selected, and possibly also of the geographic class(es) selected.
  • usage information is not unlimited in scope. Usage information as employed herein is meant to be inherently comparative and summary in nature, so that usage information does not include a user successively performing keyword searches and viewing the numbers of hits independently of one another. Also, the terms “historical usage information” and “usage information” are used herein in slightly different manners. Historical usage information necessarily includes data that has accumulated over time, while usage information may or may not include data, and may therefore be limited to information gleaned from data currently on the system.
  • Usage information can be presented in many ways.
  • usage information is shown on a relative frequency scale as an integer from 1 to 100, with the data rows sorted from highest frequency at the top to lowest frequency at the bottom.
  • usage information can be displayed by depicting absolute frequency, by depicting occurrence of number of uses or "hits", or even by displaying data or data rows in different colors or using other identifying indicia.
  • indices such as used car guides do provide summary comparison information for various makes, models, and years, that information is based upon factors other than usage information for the database at hand, and is not accompanied by offers for individual cars.
  • the self-evolving approach systems and methods described herein can be used for all manner of products and services.
  • the self-evolving database concept is readily applied to employment want ads.
  • users would add parameters such as nature of employer, location, educational requirements, experience requirements, duties, salary, etc.
  • the self-evolving database concept is readily applied to personal advertisements. There, likely parameters include marital status, race, sex, sexual preferences, hobbies, likes and dislikes.
  • Still other specialized parameters may be employed to conduct auctions. For example, a user may choose to list the items of interest using the parameters of "last price bid", "last bid date”, and "closing date/time”. This capability is especially powerful because it allows a user to view information stored on all items of interest, whether such items were listed as fixed price offers, auctions, or whatever.
  • a user looking for a particular book, for example, would be presented with a single table showing fixed price offerings from volume retailers such as Amazon.com and BarnesandNoble.com, as well as offerings of smaller companies, individuals selling new and used copies of the book, offerings by auction, and so on. It is especially contemplated that both auction and non-auction (sales, lease, rental, etc) offerings can be displayed in the same table at the same time merely by selecting appropriate parameters.
  • entries for items being auctioned are stored as sets of parameter- value pairs, and then displayed to a potential customer in a matrix format in which individual cells contain values from the parameter-value pairs.
  • the item(s) being auctioned may be similar or even identical to the item(s) being sold other than by auction, or they may be quite different from one another.
  • the parameter-value pairs for the item(s) being auctioned may be stored on the same database as the item(s) being sold other than by auction, in overlapping databases, or in completely independent databases.
  • the matrices discussed here, as well as elsewhere in this application may have contiguous or noncontiguous cells, and may include navigational aids that accommodate more columns and/or rows than are viewed at a single time.
  • search strategies (which would include the classification, parameters, and values used to obtain a results set), can be stored either locally to a user (perhaps as a cookie), or stored centrally. This would allow a user to develop a search over time, and then run the search again using a keyword or other locator, rather than having to reconstruct the entire search.
  • one of the parameters utilized across all item characterizations is likely to be listing date or update date, and searches could be stored that only look for items entered after the last time the search was run.
  • the system could store a search strategy, run the strategy periodically, and then e-mail the user who entered the search only upon selecting a non-null results set.
  • Data structure 900 generally comprises a classification table 910, a parameter table 920, a values table 930, an entries (items) table 940, a parameters-value table 950, and several supporting tables (not shown).
  • the number of tables and fields is thought to have been optimized to enhance performance for MicrosoftTM Sequel Server 7.
  • additional fields may be added as well to various tables, and additional tables (including vendor records and so forth) may be added.
  • the Classification table 910 includes fields for Class key 911, Level- 1 912, Level-2 913, and Level-3 914 class literals, and a field storing a maximum number of parameter- value pairs 915. These fields should all be self-explanatory.
  • the Parameters table 920 includes a Parameter Key 921, and a Class Key 922 that relates back to the Class Key 91 1 of Classification table 910. Although parameter literals are thus stored repeatedly, it is thought that there are sufficiently few parameters that the inefficiency of storage is outweighed by the efficiency in accessing parameter frequencies for specific classes. Synonyms for parameter literals are preferably stored by including the synonym literal in the Parameter Literal field 923, storing the Parameter Key 921 of the root or base parameter in the Synonym Param Key field 925. That way a search for any parameter among a set of synonyms can identify all Parameter Keys 921 in the set.
  • the Parameter Freq field 924 stores the historical occurrence with which this particular parameter and classification combination has been used. The system can then calculate relative frequencies with which different parameters have been used for the same class. Frequency fields 924, 956 are maintained on an ongoing basis in Parameter table 920 and
  • the Units Key 926 related back to a Units table (not shown) that includes a corresponding Units Key, and fields for the literal name of the units (miles, kilometer, etc), a base unit of measurement into which the units can be converted, a conversion factor, and a default rounding factor. Thus miles would likely be converted into kilometers with a conversion accuracy indicator. Alternatively, the result of the conversion can use the same level of accuracy as the data being converted. From inclusion of the Units Key 926 in the Parameters table 920 it should be apparent that each parameter within each class is contemplated to have only a single parameter.
  • the Values table 930 is straightforward, containing a Value Key field 931, a Value Literal field 932 and a Synonym Value Key field 933.
  • The preferably operates in an analogous manner to the Synonym Param Key field 925.
  • the Value Key field 931 may be highly efficient for the Value Key field 931 to contain a very simple alphanumeric key, such as V99231.
  • the Value Key field 931 may be efficient for the Value Key field 931 to contain the numeral in some standard format to facilitate range searching when the Value Keys are used in Value Key-1 953 and Value Key-2 954 in the Parameter-Value table 950,
  • the Entries table 940 is used to correlate sets of parameter-value pairs that represent a particular item.
  • a person listing a car for sale may have the car data split up into 20 parameter-value pairs, which would be stored in the parameter-value table 950.
  • the system later needs to collect those 20 parameter-value pairs together it does so because all of those parameter-value pairs have the same Entry Key 941 in Entry Key field 957.
  • Entries table 940 also includes a Vendor Key 942 field that contains a key referring back to a Vendors table (not shown) that contains name, address, phone numbers, billing information, and so forth. .
  • the Entries table 940 also includes a Load Date field 943 and an Expiration Date field 944 that indicate when the particular entry was originally loaded onto the system, and when it is scheduled to be deleted, respectively. Entries may well be deleted a month after being added unless the vendor providing the data pays a fee to maintain the data on the system, especially for vendors having more than a small number (possibly 5 or 10) of entries.
  • the Rate Code field 945 is used to store information on how each particular entry is being billed.
  • the Rate Code field 945 may, for example, list a monthly billing charge for each item, with items listed for free having a rate code of zero.
  • One contemplated use would be for an insurance company to store doctor information on the public access system, and proprietary or confidential information on their local system. Users behind the firewall of the insurance company could readily access all the parameters and values made available to the public through the public access system, but additionally access the proprietary or confidential information as extensions of the public access data - and all of this can be done using a single interface such as the main display table 330 of Figure 3A. The only difference is that users behind the insurance fire wall would potentially have more choices for their parameters and values than would the public access users. In the meantime the public access users would have no idea that the proprietary or confidential information even existed. This scenario could be extended even further, with multiple offices, individuals or companies having their own “extensions" to the same basic data.
  • the Access Restriction field 946 and Access Code field 947 provide a person or company loading data with a means of keeping that data away from others.
  • One contemplated use is to keep adult materials from under-age users.
  • a vendor can load images and other data onto the system, using parameters and values to describe whatever is being offered.
  • a subsequent user accesses that information in a table such as the main display table 330 of Figure 3 A, only the text will appear in the cells. If the user then clicks on the Select button 332 to view the full record, he would be presented with an access screen (not shown) corresponding to a code stored in the Access Restriction field
  • the access screen would have functionality for weeding out the under-age users, and in this instance preventing them from viewing the videos or images contained in the full record. In other contemplated scenarios, the access screen could have functionality that provides access only to users entering a code that matches the data in the Access Code field
  • the Parameter-Value table 950 stores a Parameter-Value (PV) Key 951 , which is probably not used anywhere else in the database. It is unlikely that the Parameter- Value table 950 will be sorted by PV Key 951, and instead it may be kept more or less sorted by the Parameter Key 952 that relates back to the Parameter Key 921 of Parameters table 920. Most likely, the Value Key-1 always contains data because it stores a key for either a single value where no range is involved, or for the low value where a range is involved. The Value Key-2 most likely contains data only where a range is involved, and in that case includes a key for the high value of the range. To simplify matters, it is preferred that ranges always interpreted as being inclusive on both ends.
  • the Correlation field 955 can be used for all sorts of purposes, but preferably to store the sort information discussed above with respect to Figures 3A - 3E.
  • the system would first display all Level- 1 classes stored in the Classification table 910 of Figure 9. Upon selection of one of the Level-1 classes by the user, the system would search for and display all Level-2 classes subordinate to the selected Level-1 class. The user would then select one of the listed Level-2 classes, and upon such selection the system would search for and display all Level-3 classes subordinate to the selected Level-1 class. It is preferred, however, that all of the Level 3 classes would be spanning classes that are more or less applicable to all of the Level-2 classes, and would be displayed no matter what Level 1 / Level 2 choices the user had previously made.
  • the system would search the Level-1, level-2 and Level-3 fields for matches, and display the selected record set in descending frequency order as in the table 130 of Figure 1.
  • the system may well employ a synonyms table (not shown). If no matches were found the system would then search the value field of the parameter- value table 950, and work backwards from the selected record set to determine the corresponding classifications to display.
  • the system may advantageously employ a synonyms table (not shown). If no entries are found for the selected classification, the user would be notified of same, and prompted to add an item using a display as in Figure 2. Such an event may actually be a powerful incentive to a user, because that user has a wonderful opportunity to shape the parameters and values of that classification for future users.
  • the system Upon selection of a classification, the system would display data interface such as the three-row parameter/filter/units selector 320, and the main data display table 330 of figure 3.
  • the data in the parameter/filter/units selector 320 is determined by searching through the Parameter-Value table 950 for records having the selected classification.
  • the system calculates relative frequencies for the parameters, and displays the top five to ten parameters (depending on system settings) as defaults in the parameters row 321.
  • the user can modify those parameters or add new parameters in other columns.
  • the system then fills in the corresponding data in the main data display table 330, which process does not require another search since the relevant record set was already located.
  • selecting parameters for the various columns of the parameter/filter/units selector 320, and displaying the parameters selection interface of Figure 4 does not require any further trips to the database since all parameters for the selected classification were already located.
  • the system will need to search the Parameter- Value table 950 to determine what values have been used for the selected parameters within the selected classification. Once that information is obtained, the system calculates the relative percentages on the fly, and displays the information in the values portion of the main display table 330 of Figure 3, and as needed the values table 510 of Figure 5.
  • the system displays five to ten, or other number of the top frequency parameters for the selected classification, and then waits for the user to enter corresponding values, or change the selection of parameters. Values entered by the user are verified against the Parameter- Value table 950 for the selected classification and parameter, or alternatively values are chosen from the values listing of
  • the systems and methods described herein are applicable to storing and retrieving information regarding services, as well as other forms of information.
  • the global applicability derives in part because the self- evolving concept allows users to be creative in establishing parameters and values.
  • a user may store scientific articles or other information relating to such articles using parameters such as "article name”, “author”, “abstract”, “keywords”, and “full text”.
  • Historical facts can be stored articles using parameters such as "type of information” (where the value is “historical facts"), "subject matter” (where the value may be “ Egyptian Rome”), "persons involved” (where the value may be "Nero").
  • an embodiment provides a classification interface 1000 similar to the interface 100 of Figure 1.
  • a user entered the word "polymers" in a data entry field 1010, and the system provided a listing 1020 of all classifications including the term "polymers".
  • the listing 1020 has five columns 1021 - 1025 and a vertical slider 1026.
  • the system presents frequency information that assists the user in choosing among the various classifications.
  • Some of these classifications may deal with offers to buy or sell polymers, but some of the classifications may also deal with miscellaneous information, including scientific articles, historical facts, and so forth.
  • the classification system itself can be self evolving, allowing anyone to enter any classification he wants, where the classifications most commonly used bubble to the top, and those infrequently used sinking to the bottom.
  • a user has selected a classification 11 10 of Plastics / Polymers / Polyesters, either by a keyword path or a tree search, and the system responded by displaying a table 1120 containing information related to the classification.
  • the table 1120 has six columns 1 121 - 1126, and a vertical slider 1 128. By including a horizontal slider more rows can be utilized than can be visualized on the display at any given time.
  • Each column contains cells having values for a given parameter, which is named in the first row 1131. If the current user wants to limit the column to records in which the chosen parameter matches a particular value or range of values, he can do so by entering the value or range of values in the second rowl 132 of the corresponding column. In Figure 11, no values were selected.
  • the data rows 1 133 - 1 139 can contain data cells, with each row corresponding to a different entry.
  • the final row 1 150 can be used to add a new item.
  • Advertising graphics 1140 may be included as well.
  • At least some of the columns are preferably dictated by the user.
  • the user chose to include "Type of Story” in the second column 1 122, "Company Involved” in the third column 1 123, and so forth.
  • the second row of each column can be used as a drop-down window to select parameters, where the user is guided by information relating to usage of these parameters by previous users.
  • the user did not have to select the parameters shown here, and may well have had several dozen parameters to choose from.
  • the parameter choice is limited to parameters previously employed with respect to the classification chosen.
  • Sorting may be enforced by the user, or may occur from left to right, or in some other manner.
  • the highest level sort may be determined by the data in the first column, the next highest level sort being determined by the data in the second column, and so forth.
  • the system may be configured so that a user can adjust the widths of the columns, and possibly even the number of columns.
  • each record is shown on a single line in Figure 11 , it is contemplated that a user could choose a multiple line format for one or more rows. If multiple line rows are not allowed, then a user could view the entire cell in an overlying window, perhaps by double-clicking on the cell.
  • Data entry is contemplated to generally follow the teachings set forth with respect to the marketplace indices.
  • a person entering a record i.e. a story line or item
  • an idea not described with respect to the market place indices is that a user could couple his record to an existing record. In that manner, a subsequent user could find an item of interest, and then click on some portion of the related row, such as the cell in the first column of the row, to bring up all stories that were identified as being related.
  • Figure 12 is a sample of a display screen similar to Figure 12. Again the user has selected a classification 1210 of Plastics / Polymers / Polyesters, either by a keyword path or a tree search, and the system responded by displaying a table 1220 containing information related to the classification.
  • the table 1220 has four columns 1221 - 1224, and a vertical slider 1225. By including a horizontal slider more rows can be utilized than can be visualized on the display at any given time.
  • Each column contains cells having values for a given parameter, which is named in the first row 1231. If the current user wants to limit the column to records in which the chosen parameter matches a particular value or range of values, he can do so by entering the value or range of values in the second rowl232 of the corresponding column.
  • the data rows 1233 - 1237 can contain data cells, with each row corresponding to a different entry.
  • the final row 1250 can be used to add a new item.
  • Advertising graphics 1240 may be included as well. In this instance, the user chose a Sports/Olympics/Drug Use classification. Also, the user limited the items listed to those items in which the Type of
  • the system can operate in a manner substantially similar to that described herein for marketplace information, and news and information.
  • Figure 13 for example, a user entered the name, Clinton, and was presented with a listing of classifications relating to people's opinions regarding Clinton.
  • the user checked off the third row of data, relating to Hillary's run for a senate office seat.
  • the user has chosen to list questions according to frequency. No limitation (in row 2) as to the value of the frequency was selected, so that even questions that garnered minimal interest are included. Other columns selected list numbers of "yes" responses, numbers of "no" responses, total numbers of responses, dollar amounts, and average dollar amounts. Examples of possible other columns which were not selected are standard deviation, and other statistical functions.
  • a user could have a text column, which might seek adjectives to describe a particular venture. In data row 3, for example, a question was listed that asks for an adjective. The user chose the fourth column to list adjectives, and in the pull down of the values (not shown) may have received a listing of what adjectives were used by what percentage of respondents. Alternatively, the user could have entered a particular adjective as a value designation in the second row, and then chosen the other columns to obtain data with respect to respondents choosing that adjective. More complex tables can also be provided that statistically analyze specific responses to a given question.
  • the system can keep track of identifiers for individual users, so that their opinions about literally hundreds of various things can be accumulated over the years.
  • identifiers for individual users, so that their opinions about literally hundreds of various things can be accumulated over the years.
  • news and information can also be applied to opinions.
  • Historical facts may be readily stored as event/outcome pairings. For example, a user in the field of chemistry may choose to store the results repeated experiments using a given protocol in a single record. Illustrative parameters and values are listed below in a format similar to that of Figure 2:
  • the system can readily be configured to perform statistical calculations (averages, standard deviation, etc) on data within a single entry, and on data across multiple entries - and produce corresponding graphs as desired.
  • the statistics and/or graphs can be stored in specialty parameters, or displayed in separate windows.
  • One particularly useful embodiment is for the insurance company to store treatment information in parameters such as diagnosis, treatment, and results.
  • the system could then automatically calculate the percentages with respect to doctors in a given hospital, geographic region, or specialty, or those utilizing a given treatment for a given diagnosis. Such information would be presented automatically in a values type interface such as that depicted in Figures 5B.
  • a user would select a diagnosis and view the relative percentages of the treatments for that particular make.
  • the user could select a diagnosis and a treatment, and view the relative percentages of the corresponding treatment results.
  • Still other parameters covering signs and symptoms could be added so that the database would evolve over time to be an incredibly useful statistical resource.
  • analogous information could be stored and retrieved in many fields, including herbs and alternative medicine, or even car repair. It would be very interesting, for example, for a user to compare what repairs tend are performed by a particular service station with repairs performed by the industry in general, or by repair shops in a local area.
  • Other parameters may, for example, be useful in providing auction information. It is contemplated, for example, to provide parameters such as Auction Opening Date, Auction Closing Date, Auction Closing Time, No of Bids, Most Recent Bid, and Bidding History.
  • the Bidding History parameter would most likely be a specialty parameter that engaged a program to produce the history.
  • These parameters can be displayed along with any other selected parameters, so that a single table can contain both auction and "for sale" information. Still further, those skilled in the art will recognize that the same table can also contain any other information desired by the viewer. In looking for a book, for example, a viewer can see not only prices, delivery and other information from many different vendors, but also auctions, rentals, prices of used copies, and so forth. In short, the viewer gets to see all the information that he wants to see, and none of the information that he doesn't want to see.
  • the self-evolving type of parameter- value database can be utilized to provide an index to case law.
  • the LEXISTM system does not presently have a sophisticated key indexing system such as that found on the WestlawTM system.
  • a given user may well find that the WestlawTM key system does not characterize the cases in a manner especially useful to that particular user.
  • users could categorize cases in any manner that they choose, and then record their own summaries or other interpretations of cases of interest to them using parameter-value pairs.
  • LEXISTM or WestlawTM could keep track of such categorizations and parameter- value pairs as a service for the users, but then also make available to all users the categorizations and parameter-value pairs used by others. In that manner categorizations and summaries of cases in each particular field and subfield would eventually evolve to reflect what the users have stored for their own benefit. This would allow LEXISTM to develop its own key-type system without doing much of anything. In the hands of WestlawTM, systems according to the present invention could be used to supplement the existing key system.
  • the contemplated user developed categorization systems can be considered as a method comprising: providing an interface through which a user can categorize a document indexed on the database using at least one parameter-value pair; providing the user with a first listing that displays a set of parameters previously used by others in categorizing other documents; providing the user with a second listing that displays a set of values previously used by others in categorizing the other documents; and allowing the user to add a new value to the set of values such that subsequent users will have access to the new value.
  • the development or "evolution" of the categorization may be either entirely or only partially dependent upon actions of the users.
  • the step of providing the user with a first listing includes displaying historical usage information for individual members of the displayed parameters.
  • the step of providing the user with a second listing includes displaying historical usage information for individual members of the displayed values.
  • Still another aspect of preferred embodiments further comprises allowing the user to add a new parameter to the set of parameters such that subsequent users will have access to the new parameter.
  • Yet another aspect of preferred embodiments further comprises storing the at least one parameter-value pair in a storage system distal to the user, and providing the user with access to the at least one parameter- value pair at a future date through a network.
  • Another potentially valuable feature of in preferred embodiments of the present invention is that they can provide values lists that are automatically shortened as the user narrows in on his search.
  • Matthew BenderTM markets a CD ROM based database product for accessing intellectual property case law.
  • system users are assisted in formulating their queries by access to "word wheel" listing all of the indexed keywords on the system.
  • the word wheel is advantageous in many ways, such as preventing mis-spellings of keywords on the part of the searcher, and identifying alternative word spellings and even mis-spellings in the case law.
  • the keywords in existing word wheels are all jumbled together rather than being separated according to some sort of usage classification.
  • Another problem with existing word wheels is that the keywords are displayed are always the entire keyword listing rather than just those keywords located in a previously selected subset of records. This wastes time since it does a user precious little good for a user to add a keyword to his search strategy if the keyword is not present in any of his documents. Still another problem with existing word wheels is that they either do not show the frequency of the keywords in the documents, or the frequencies are not updated as the search proceeds to narrower and narrower record sets.
  • the values listing for the parameter Opinion Date would include only dates, and not the names of parties. This solves the jumbling problem alluded to above.
  • the third problem of depicting frequencies would also be solved.
  • Preferred embodiments of the present invention automatically display values with their corresponding frequencies of use.
  • the frequencies are shown in relative frequency format as a percentage from 0 to 100, but they could readily (and even more simply) by shown as the raw occurrence frequency. Still further, however they are displayed, the frequencies would automatically be updated as filtering occurs.
  • these advantages can be considered to result from any method of searching a database having a plurality of records, in which the method comprises: deriving a plurality of terms from the plurality of records; displaying to a user at least some of the terms in a first interface; selecting a search term from the plurality of terms; using the search term to derive a subset of records from the plurality of records; using the search term to derive a subset of terms from the plurality of terms; and displaying to the user at least some of the subset of terms in a second interface.
  • the terms would often be ordinary text, or perhaps alphanumeric, and that the terms could advantageously be listed in either alphanumeric or frequency order.
  • the interfaces would likely comprise one or more windows on a computer operated display screen, although as technology progresses the interfaces may be completely or primarily audial
  • parsing and./or tagging may be used to separate out individual terms (values) from the documents, and however derived the terms may advantageously be stored as values of parameter-value pairs.

Abstract

Improved parameter-value databases and methods of using the same provide significant benefits to individuals loading data and/or conducting searches. In one aspect the database is used to properly identify overlap between search data and target data where the data sets contain any combination of single values, multiple values, and ranges. In another aspect items are loaded onto the database as sets of parameter-value pairs, with subsets of such pairs being further sub-correlated for various purposes, including establishing display order, chronological order, or coupling groupings of parameter-value pairs. In another aspect users are allowed to add new parameters to the database in such manner that the database develops a user-evolved categorization system. In yet another aspect users are presented with word or other value lists to assist them in searching the database, and the lists become smaller as filters are applied. The databases and methods are applicable to information that is not strictly marketplace information, namely opinion surveys, scientific information, legal information, and general information.

Description

IMPROVED PARAMETER-VALUE DATABASES
This application claims priority to US Provisional Application No. 60/123,019 filed March 4, 1999 and to US Patent Application No. 09/490,409 filed January 24, 2000 which claims priority to US Provisional Application No. 60/172,278 filed December 17, 1999. This application also claims priority to US Patent Application No. 09/431,031 , filed October 28, 1999, which is a Continuation in Part of US Patent Application No. 09/128,1 16 filed July 3, 1998.
BACKGROUND OF THE INVENTION
This invention relates to the field of wide area data networks and databases that index large numbers of different types of items.
BACKGROUND
The Internet is by now the world's largest computer network, interconnecting millions of computers. One side effect of this large size is that the vast amount of information available on the Internet is often extremely difficult to access. Similar problems tend to occur on any large network, and in this discussion the Internet is discussed herein as an example of such a network. Similar problems occur in searching large databases in general, whether or not part of a network.
One very significant problem is that different people will almost always use different terms to describe similar items. In a marketplace type database, for example, one person may say that he or she is selling an automobile, while others may refer to the same item as a "car", "auto", "sedan", "motor vehicle", and so forth. Similarly, in a news database such as NEXIS™, the concept of "modern" may well be expressed using the term "modern", but may also be expressed using the terms "contemporary", "up to date",
"progressive", "recent" or "prevailing". Similarly, in a legal database such as LEXIS™, a single case almost always contains information relating to many different aspect of law, so that one person may consider the case to be important for some procedural precedent, while another person may consider the case to be important for a different procedural precedent, or one or more substantive precedents. Searching any of these databases using only a given word or phrase will thus likely overlook many items that should be identified by the search. This problem is often referred to as "under inclusion", and is regarded as a necessary drawback of keyword searching. Of course the problem is further compounded in a worldwide network such as the Internet, where the existence of many different languages and dialects make keyword search very difficult.
A related problem arises when a person searches for something without knowing the correct name or characteristic of the item being searched. In interpersonal speech one can sometimes adequately describe an item using decidedly non-specific language, such as "the clippie thing on the end of the rope", but in computer searching such descriptions are not helpful at all. An automated yellow pages type search, for example, can only access items if the exact name is known.
The modern search engines such as Lycos™, Yahoo!™ solve the naming problem by conducting context insensitive keyword searches. Unfortunately, such searches are notoriously both over-inclusive and under-inclusive. For example, someone using any of these search engines to purchase a red Mercedes™ may well locate a story dealing with a woman named Mercedes who is wearing a red dress, or an article about a traffic accident dealing with a red Mercedes™, both of which would be over-inclusive. Yet, if the user tries to narrow the search by adding the keywords "for sale", the search would omit a great many web sites that listed the desired car, but didn't happen to include the words "for sale", that would be an under-inclusive error. Even if the simplistic keyword searches of the modern search engines could somehow be made neither over-inclusive nor under-inclusive, they would still be unsatisfactory because they only point to web pages (i.e. documents) rather than the underlying data. It would be much better if a search engine actually listed the desired information in a table format for easy viewing and manipulation by the user.
Keyword searches using existing technology are also exceedingly poor at handling ranges. For example, if one is searching the Internet to buy a Lexus™ automobile between
$15,000 and $20,000, one could readily find all web pages that contain the word "Lexus", but it would be impossible using only keyword searching to narrow down the search to the desired price range. The reason is that there are thousands of numerically distinct dollar values in the desired range, $19,500, $18,999, $15,450, and so forth. A conceptually similar problem is that keyword searches are very poor at locating variants. Someone wanting a red car might be happy with a car listed as being rose, maroon, scarlet, or even cherry. But a search for "red" will generally only pull up "red".
Some of these problems can theoretically be addressed using artificial intelligence and sophisticated fuzzy logic routines. But in the meantime there is a very definite need for better systems and methods for keyword type searching of large networks and databases.
SUMMARY OF INVENTION
The present invention includes improved parameter-value databases and methods of using the same that provide significant benefits to individuals loading data and/or conducting searches. In one aspect the database is used to properly identify overlap between search data and target data where the data sets contain any combination of single values, multiple values, and ranges. In another aspect items are loaded onto the database as sets of parameter- value pairs, with subsets of such pairs being further sub-correlated for various purposes, including establishing display order, chronological order, or coupling groupings of parameter-value pairs. In another aspect users are allowed to add new parameters to the database in such manner that the database develops a user-evolved categorization system. In yet another aspect users are presented with word or other value lists to assist them in searching the database, and the lists become smaller as filters are applied.
In still another aspect of preferred systems and methods, parameters and/or values are presented in listings for selection by users. This is potentially a huge advantage over the common Internet type search engines which provide no guidance at all in selection of parameters and values. The listings may advantageously be presented in alternative alphanumeric and relative historical usage formats.
In still another aspect of preferred systems and methods, at least some of the information is classified using a classification structure having at least three levels. More preferably at least one of the levels contains a large number of classes that span (i.e., are applicable to) a high percentage of classes in the other levels.
The systems and methods described herein can be applied to substantially all products, services, and information. Thus, contemplated systems and methods can be used to describe every conceivable type of product and service currently listed in consumer or business-to-business telephone yellow page books, as well as all products and services commonly listed only in specialty consumer or industry catalogs. The types of information that may be stored are equally universal. It is specifically contemplated, for example, that systems and methods described herein may be utilized to index such diverse types of information as news items, historical facts, book reviews, questionnaires, opinion surveys, case law, and the topics discussed in various chat rooms.
Various objects, features, aspects and advantages of the present invention will become more apparent from the following detailed description of preferred embodiments of the invention, along with the accompanying drawing, in which like items are represented by like numerals.
BRIEF DESCRIPTION OF THE DRAWINGS
Figure 1 is a schematic of a preferred classification selection interface.
Figure 2 is a schematic of a preferred interface for adding data.
Figure 3 A is a schematic of a preferred interface for retrieving data.
Figures 3B - 3E are examples of preferred "complete record" displays.
Figure 4 is a preferred parameter selection interface.
Figures 5 A - 5B are examples of usage of a preferred values selection interface.
Figure 6 is a table showing a preferred three-level classification system.
Figure 7 is a preferred units selection interface.
Figure 8 is a preferred interface for accessing stored searches.
Figure 9 is a preferred database structure for storing and retrieving parameter-value data.
Figure 10 is an example of a preferred data interface providing information on "polyesters". Figure 11 is an example of a preferred data interface providing information "drug use".
Figure 12 is an example of a preferred data interface providing information on "Clinton".
Figure 13 is an example of a preferred data interface providing information on a questionnaire.
DETAILED DESCRIPTION
Loading and Retrieving Data
In Figure 1 a preferred user interface 100 generally includes an item description section 110, a tree search selector 120, a classification display table 130, record navigational buttons 140, and other navigational buttons 150.
The item description section 1 10 is typical of many search engines in that a small space is allowed for one or more search terms, and in some embodiments there may be a button that allows for complex Boolean searching. The search here may be different from typical searches, however, in several ways. One difference is that the search term (or terms) may advantageously be compared first against the classification structure itself, i.e., against the names of the various classes, subclasses and so forth, and then only applied against the values of parameter/values stored in the database if there are no matches in searching the classification structure. Another difference is that search terms may be coupled together using synonyms, such that searching for one term may pull up records in which the search term is not present, but a synonym is present. For example, searching for the terms "autos", "auto", "car", "cars", and "automobile" may all trigger a search for "automobiles".
The tree search section 120 preferably navigates to a pop-up or other series of windows (not shown) which display in sequence the various levels of the classification system. Additional details of preferred classification systems are described in more detail below.
The classification display table 130 lists classifications from the classification system that match the search terms. In this particular example, the system is using, or at least displaying, only three levels of classification. Level 1 class names are displayed in the first column 131, level 2 class names in the second column 132, and level 3 class names in the third column 133. The fourth column 134 shows relative frequency of entries using the displayed classifications. These relative frequencies are intended to assist the user in selecting an appropriate classification. The fifth column 135 provides check boxes 135A for users to select a specific classification from among the listed classifications. In this instance the user has selected the first listed classification, and the system has recorded the selection by changing the check box to a check mark 135B.
It is contemplated that systems may also permit users to select multiple classifications so that a single search could cover many areas. Where selection of multiple classifications are chosen, it is likely that the system will limit the number of selections to a relatively small number, perhaps three or four.
The navigational buttons 140, 150 assist the user in navigating the various displays in the system. The buttons first row of navigational buttons 140 are used to view subsets of classifications when more classifications meet the search criteria than can be conveniently displayed at the same time. Here, for example, the classification table 130 displays 10 rows at the same time, which number is most likely a function of the resolution and size of the display screen, as well as the size of the window in which the classification table 130 is displayed. In this instance there are only six rows to display, but had there been more than 10 rows, the various navigational buttons 140 would be used to navigate among the many rows. The "21-30" button, for example, would display rows 21 - 30. The ► button would display rows 41 - 50, then 51 - 60, and so forth, while the ► ► button would display the last set of rows.
The "New Search" button of the second set of navigational buttons 150 provide the user with the ability to clear the screen and start a new search. The "Add Item" button changes focus to an interface such as that shown in Figure 2, in which the user can add a new item to the database.
In Figure 1, as well as all of the Figures depicted herein, advertising and/or other graphics are entirely optional, and are omitted from the drawings for the sake of simplicity. In Figure 2 a preferred data entry interface 200 generally includes a selected classification display 210, a data entry table 220, and navigational buttons 230.
The classification section 210 echoes a classification chosen in the interface of Figure 1. In the event that multiple classifications are chosen, the classification section 210 may advantageously echo all the chosen classifications.
The first column 221 in table 220 preferably defaults with five, ten or some other relatively small number of the most frequently used parameters for the chosen classification or classifications. Any of the parameters can be modified from the defaults, either by overtyping the displayed parameter with a new parameter, or by selecting a parameter from a parameters listing such as that shown in Figure 4. The parameters listing can be displayed by clicking on the adjacent "Λ" symbol or other button shown here in column 222.
The third column 223 in table 220 records values that the user wants to associate with the selected parameters. Thus, in the example of Figure 2, the user has chosen to associate the value 6000248 with the Patent No. parameter. Here again the system is preferably designed so that the user can either just type in the value, or select a value from a values interface such as that shown in Figure 5. The values interface can be accessed by clicking on the corresponding "Λ" symbol or other button in column 224.
It should be apparent to those skilled in the art that a parameter and value located on the same row will be stored as a parameter-value pair, and that a car or house being sold, or any other item being stored is actually stored as the collection of parameter-value pairs listed in the data entry table 220. In most systems users are likely to be limited to employing 25 or some other maximum number of parameter- value pairs in describing each item. It is also contemplated that the maximum number of different parameter- value pairs that can be used to describe a given item may vary with the classification of the item. Thus, the system may allow thirty or forty parameter-value pairs when storing information on a house, but may only allow fifteen parameter-value pairs when storing information on a car. Such maximum number of parameter-value pairs would most likely be set at an administrative level.
It is also contemplated that the system will limit the maximum number of parameters correlated with any given classification. A typical limit may be 75 or 100 parameters. Users wanting to add a parameter beyond the maximum will likely be given a message to that effect, and asked to use an existing parameter, or try again later. Parameters that have minimal or no usage may be deleted periodically to make room for addition of new parameters.
The number of values allowed to be associated with a given parameter and classification may be limited in a manner analogous to limitations placed on parameters, although the limit would most likely be set much higher. For example, there may well be thousands of different dollar amounts (values) that can be associated with the parameter Price for an automobile classification. On the other hand, there may only be twenty or thirty values that can be reasonably associated with the parameter Color for the same classification.
It is contemplated that a single parameter can be listed multiple times to account for an item having multiple parameters. Thus, in Figure 2 the parameter of Inventor is listed three times to account for this patent having three inventors. Similarly the parameter of Figure is listed three times to account for this patent having three pages of drawing.
The fifth column 225 of table 220 displays the measurement units corresponding to the value on the same row. For most parameters such as Color, or Make, the corresponding value is pure text so that the units designation is simply listed as "text". For other parameters such as Length, Height, Weight, and so forth, the corresponding value is usually a number. In such instances the user can choose among units of measurement in an auxiliary interface (not shown). Thus, for example, a user entering the numeral 55291 as a value for the parameter Odometer may be given a choice of Miles or Kilometers as units of measurement. As discussed further with respect to Figure 9, the system may advantageously keep track of default units in a Units Key field 926 with respect to individual parameter-classifications, so that the same literal parameter name may have different parameters depending upon the classification. In this manner the parameter Color may be text data (red, blue, white, etc) for automobiles, but numeric data (1.79, 2.30, etc for hair color). Users may also choose to add multiple parameters to describe the same characteristic in different ways. The parameter Height (text) may be used in conjunction with the values Tall or Short, while the parameter Height (in) may be used in conjunction with the values 72.5 or 68. The sixth column 226 shows the "A" or other symbol that can be clicked upon to display a values selection interface such as that shown in Figures 5A - 5D. As described above with respect to parameters selection, however, a user may well elect not to use the values selection interface, and may instead simply type in a literal. The literal would most likely be compared against existing values as a means of confirming spelling, as a means of suggesting alternatives to the user, and as a prelude to adding the value as a new value in the system.
The seventh and eighth columns 227, 228, respectively, may well be displayed only to those users who have identified themselves as being advanced. Column 227 stores numbers that can be used to depict correlations between or among the parameter-value pairs for a given entry. These may also be referred to as "sub-correlations" because they provide further correlations among parameters and values that are already correlated by virtue of relating to the same entry or item. One contemplated use is to set control the sort order in which the values are displayed. Thus, in Figure 2 the value "Patent" in the first data row would be displayed before the value 6000248 for the patent number because the corresponding sort data are 1 and 2, respectively. Examples of using the column 227 data in this manner are set forth in Figures 3B - 3D.
Another contemplated use is the delineation of a sequence of events. A cooking recipe or laboratory procedure, for example, generally has multiple steps. The various steps could be stored in the database using sequence identifying parameter names such as Step 1 ,
Step 2, Step 3, etc. Alternatively, a user could enter all of the steps using only one or a small number of parameters with names such as Steps, Preliminary Steps, or Follow Up Steps. In these latter cases the user could still keep the steps in proper order upon later display by entering the step order as column 227 information. In preferred embodiments the data need not be integers, so that one could have steps 1.0, 1.1, 1.2, 1.21 , 1.3, 2.1 and so forth. It should be apparent that the chronology of historical events can be designated in a similar manner.
Still another contemplated use for column 227 is the grouping of subsets of parameter-value pairs. For example, a manufacturer selling an item that has multiple color choices would probably want to enter the differently colored telephones in the database as completely different entries. On the other hand the manufacturer may want to store O 01/67300
differently colored telephones in the same entry. He or she can do that by storing the make, model, size, and so forth as described above, with corresponding Sort values in column 227 as 1, 2, 3, 4, 5, 6, etc. But then when storing multiple colors and prices, the red telephone and its price may both be listed as having Sort values of 10, while the white telephone and its price may both be listed as having Sort values of 11 , and the green telephone and its price may both be listed as having Sort values of 12.
Column 227 stores delimiters that can be used in displaying data in desired formats such as those set forth in Figures 3B - 3D. At present it is preferred to use only simple characters such as asterisks, slashes, hyphens, carriage returns ("next line"), and so forth. In the future, however, it is contemplated to include more sophisticated delimiters, or even codes that are not delimiters per se, but affect the format of the information being displayed.
The navigational buttons 230 assist the user in navigating the various displays in the system. The New Search button transfers the user back to a searching interface such as that shown in Figure 1. The Cancel button clears the display of Figure 2, and returns the user back to the previous interface. The Record button starts the process of performing validity checks on the data of Figure 2, and if the data clears the validity checks, ultimately causes the data to be loaded onto the system.
Where the system involves a parameter-value based database as discussed herein, it is particularly advantageous if users are allowed to add new parameters and/or values as they see fit. In such manner the parameter- value database is also a self-evolving (i.e. user- evolved) database. Among other things the ability to add new parameters and/or values provides users with a mechanism for delineating characteristics of their items (products, information, or other data) that distinguish such items from those of others. For example, a person selling a car may want to advertise that he or she is the original owner. If Original Owner is not listed as an available parameter, the car owner can add that parameter, along with a likely value of Yes. As subsequent users make their own choices of parameters and values with which to describe their own automobiles, the Original Owner parameter will either "bubble to the top" or the listing (because subsequent users tend to choose that parameter), or remain at the bottom (because subsequent users tend not to choose that parameter). The evolution process also takes care of variant spelling of parameters. The database may well include both Color and Colour as parameters, but one of them will likely bubble to the top, and one of them will likely sink to the bottom.
A similar selection occurs with values. If the color Maroon has not been used in conjunction with the parameter Color, any user can simply add the color. Then, if subsequent users tend to choose the value Maroon over, say Red or Scarlet, the value of
Maroon will tend to bubble up the list of values.
In Figure 3 A a data retrieval interface 300 generally includes a selected classification display 310, a three-row parameter/filter/units selector 320, a main data display table 330, column navigation slider 340, record navigation buttons 350, and other navigation buttons 360.
The selected classification display 310 serves substantially the same function as the selected classification display 210 of Figure 2 - it displays the classification or classifications that the user is using, preferably classification(s) selected in an interface such as that of Figure 1. The information displayed in the main data display table 330 is dependent upon the listed classification(s), as well as the selected parameters and filters as described below.
The three-row parameter/filter/units selector 320 defaults to the five, ten or some other number of the most frequently used parameters for the chosen classification, in a manner similar to that of Figure 2. One difference is that here the parameters are displayed as column headings whereas in Figure 2 the parameters were displayed as row headings. Of course columns and rows in display formats are more or less conceptually interchangeable, and all permutations of these are contemplated as alternative embodiments, as well as matrices in which the cells are non-contiguous horizontally, vertically, or in both directions.
The first row 321 of the parameter/filter/units selector 320 is labeled with the term "Parameters" at the far left. The cells to the right are in pairs, with each pair having the same final letter. Thus, cells in row 1 , columns 2 and 3 form a pair labeled 325A, 326A, columns 4 and 5 form a pair labeled 325B, 326B, and columns 6 and 7 form a pair labeled 325C, 326C, etc. In each instance the first cell in the pair shows the parameter name used to define the data in the column of main display table 330 immediately below. In Figure 3A, cell 325A shows the parameter Type, which in this example refers to the type of intellectual property. Examples may be Patent, Copyright, Trademark, Trade Secret, Contract, etc. The second cell in each pair displays a "Λ" symbol or other button that leads the user to a parameter selection interface such as that depicted in Figure 4.
The second row 322 of the parameter/filter/units selector 320 is labeled with the term "Value" at the far left. An alternative and possibly preferable label may be "Filter".
The cells to the right are again in pairs, with the first cell of each pair either blank or displaying a value used for filtering, and the second cell of each pair is a "Λ" symbol or other button that leads the user to a value selection interface such as that depicted in Figures 5A-5D.
The second row 322 is intended to receive values used in filtering the corresponding parameters. The filters are preferably null at the outset, but can be filled in by the users. One of the most important aspects of preferred systems is that they can display and filter on any combination of parameters. Thus, one can readily search all red or white automobiles within a given price range, at least as recent as a particular year, and having no more than a given odometer reading, and obtain a listing of all such automobiles on the database, regardless of their makes or models. In subsequent searches the user could then filter to a particular make, or perhaps filter on some other parameter. In competing systems such as the current version of autobytel.com, a user can only access the database by first selecting a make and a model. That type of very limited access to the database is just not satisfactory in many circumstances.
The third row 323 of the parameter/filter/units selector 320 is labeled with the term "Units" at the far left. The cells to the right are once again in pairs, with the first cell of each pair displaying a units measurement, and the second cell of each pair displaying the "Λ" symbol or other button that leads the user to a units selection interface, as for example the units selection interface depicted in Figure 7. Typical units measurements are "text",
"miles", "kilometers", "inches", "meters", kilograms", "date", and so forth. The units information is employed in displaying the data in the corresponding column of the main data display table 330, with the system making appropriate calculations and rounding. Using this system a user can readily filter for and view Odometer data as miles or kilometers, regardless of how such data is stored. The "Go Fish" button 328 tells the system to apply the parameters and value filters selected in rows 322 and 323, and produce the results in the main data table 330. Of course, other terms could be substituted for "Go Fish", including "Apply", or "Go", "Build Table", or "Submit", and the button 328 could be located elsewhere in the interface 300.
The main display table 330 preferably contains between 6 and 30 columns, with many of the columns being positioned off the screen at any given time. This can be accomplished by the usual Windows™ type of horizontal slider 340, or any other suitable manner, such as tab type navigational buttons that would show subsets of the columns. Where more columns are utilized than can conveniently fit on the display screen, the columns with filters can advantageously be moved to the far right. Thus, if a user is employing 10 columns in the main display table 330, and 3 of those columns contain a filter, then those three columns would preferably be automatically moved to columns 8-10, respectively. In so doing the first seven columns would contain the variable data of interest to the user. Such automatic movement of columns, however, is not depicted in the main display table 330 of Figure 3A to better illustrate the preferred filtering techniques.
In Figure 3 A the column farthest to the left is reserved for a "Select" button. Clicking on or near the word Select causes the system to display another interface that preferably shows reveals all the parameters and values stored on the system for the item (entry) having data displayed in the selected row. Particularly desired formats for display of this "complete record" is discussed below with respect to Figures 3B - 3E.
In preferred embodiments users can move directly to the "Λ" symbol or other button, or alternatively users can type a parameter or value into the corresponding cell of the table. Upon tabbing or clicking out of the active cell, the system verifies the validity of the entry, and provides assistance (such as transfer to the appropriate parameter or value interfaces) if the entry is invalid.
Values are displayed in the various rows of the main data display table 330 that correspond to items matching the selected classification 310, the parameters selected or defaulted in row 321, and the filters selected in row 323, in short for values matching the search request. The table sorts by default from left to right, but can advantageously be resorted by data within any given column by clicking on the corresponding ▲ or T sort buttons 321 A, 32 IB at the head of the desired column.
It is important to note that the cells of the table can include text, icons, hyperlinks to web pages, files or the like. Where a hyperlink is in the cell, users can preferably jump directly to the linked site. Where a video, audio or other file is indicated, users can preferably open and play or display that file as the case may be. Where an e-mail address is indicated, the system preferably opens an interface to facilitate recording and sending of an e-mail to that address.
The record navigation buttons 340 and other navigation buttons 350 are intended to be similar to those used on other systems, and are self-explanatory. The Select button brings up an interface such as those depicted in Figuies 3B - 3E. The Spreadsheet button is used to send the data in the main display table 330 to the user as an Excel, or perhaps some other spreadsheet.
Figure 3B depicts a very simple preferred "full record" display. In this instance the user has chosen to store only text information. The text displayed is " 1998 Lexus LS400, white, gold package, 12,000 miles, perfect inside and out, original owner, Fullerton, CA, Bob 714-555-5555, $32,900, firm". This display can be achieved by inputting the following information into the interface of Figure 2:
Parameter Value Units Sort Delim
Make Lexus text 2
Model LS400 text 3
Year 1998 text 1
Color White text 4
Price 32900 dollars 13
Odometer 12000 miles 6
Condition perfect inside and out text 7
Extras Gold Package text 5
City Fullerton text 9
State CA text 10
Contact person Bob text 1 1
Contact phone 714-555-5555 text 12
Ownership order original owner text 8
Price firmness firm text 14 Figure 3C depicts substantially the same information as described above with respect to Figure 3B, but with the addition of a picture, modification of the sort order, and modification of the delimiters. This display can be achieved by inputting the following information into the interface of Figure 2:
Parameter Value Units Sort Delim
Make Lexus text 3
Model LS400 text 4 -
Year 1998 text 2
Color White text 7 with
Price 32900 dollars 5
Odometer 12000 miles 10 -
Condition perfect inside and out text 9 new line
Extras Gold Package text 8 n
City Fullerton text 12
State CA text 13
Contact person Bob text 14
Contact phone 714-555-5555 text 15
Ownership order original owner text 1 1
Price firmness firm text 6 new line
File Picture of Car file 1 new line
Figure 3D depicts yet another format for a "full record" that may be selected by a user. This display can be achieved by inputting the following information into the interface of Figure 2:
Parameter Value Units Sort Delim
Tag line Best buy in Fullerton text 1 ,
Bedrooms 4 number 2
Bathrooms 5 number 3
Views views from every room text 4
Lake frontage 450 feet 5
Features dock text 7
Stories 2 text 8
Condition needs nothing text 9
Financing owner will carry text 10
Price firmness asking text 1 1
Price 450000 dollars 12
File Picture of house 1 file 13
File Picture of house 2 file 14
File Picture of house 3 file 15
File Picture of house 4 file 16
File Picture of house 5 file 17
File Picture of house 6 file 18 Those skilled in the art will recognize that the above examples assume certain conventions on the part of the system. For example, in producing the "classified" type listing it can be a convention of the system that the thumbnail pictures are automatically dimensioned to an appropriate dimension. Also, where the units data is something other than "text" or "file", the system would automatically follow the value data with the literal value of the parameter, and where the units data is other than "text", "file" or "number", the system would automatically insert the units after the value. Thus, where the parameter is "Lake frontage" and the units is "feet", the system prints value followed by units followed by parameter, i.e., "450 feet lake frontage". Another convention may be that each delimiter other than a space is followed by a space, and hyphens are preceded by a space. Another convention may be that all words are displayed in lower case except for recognized proper names, and the first word after a period. Still another contemplated convention is that the user can choose not to designate any sort order at all by leaving the sort field null. In such cases the data may be displayed in a simple multi-column parameter-value listing such as that depicted in Figure 3E. Of course alternative conventions are also contemplated, and innumerable combinations of conventions can be developed by clever programmers. The system may also store default display formats for various classifications, which can be used by the system to display data in "classified" type listings when the person or company posting the data (i.e., the data provider) does not specify a custom format.
It is also contemplated that data can be "mined" from an original classified type listing format, converted into parameter value pairs, and then redisplayed in a classified type format similar or even identical to that of the original. One step in a preferred strategy for such data mining would be to locate the target data using a web crawler, or have the data provider transfer or point the target data to the mining system. The target data can then be parsed into terms, preferably using a listing of standard parsing characters (i.e., delimiters such as spaces, slashes, hyphens, commas, and so forth), or using one or more parsing characters designated by the data provider. The system would also attempt to determine an appropriate classification for the target data, preferably by locating a classification code in the target data, or having the data provider designate a classification in some other manner. It may also be desirable to apply all of the parsed terms against the database to determine which classification contains the highest number of such terms as values. Once the classification is known, the parsed terms can be applied against the database to determine corresponding parameters, and stored as parameter value pairs. If the system also associates the delimiters from the original format with the respective terms as discussed above with respect to Figures 3B - 3E, the stored data can be redisplayed at a later time with an appearance similar to that found in the original listing.
These steps can be illustrated using a very simple example involving the storage of data related to the selling of flowers on a web page of the Internet. Typically, the data provider would include the data on the web page in either a memo field or in a simple flat table. A typical listing may be "Long stem red roses for sale. Shipped daily from Hawaii. Only $24.99 per dozen", with the listing followed by a picture of the dozen roses. This information would preferably be forwarded to the mining system by the data provider with a selected classification designation, perhaps a code such as "A27", or less preferably with a corresponding recognized classification such as "agriculture-flowers-marketplace". Preferred classifications and codings are discussed below with respect to Figure 6. If, however, the classification were not known, the system could still obtain a working classification by locating those classifications containing as values the parsed terms "red",
"flowers", etc. Once one or more actual or working classifications are known, the system can work backwards by locating a parameter for each, or at least many, of the values. In that manner Color may be determined to be a valid parameter for the value Red, and Plant Name may be determined to be a valid parameter for the value Roses. The system could thus automatically resolve the parameter-value pairs from which the original listing could be substantially recreated. For the roses example, the data may resolve as follows:
Parameter Value Units Sort Delim
Type long stem text 1
Color red text 2
Plant Name roses text 3
Transaction Type for sale text 4
Shipping shipped daily text 5
Connector from text 6
Source Hawaii text 7
Connector only text 8
Price 24.99 dollars 9
Connector per text 10
Sales grouping dozen text 1 1
File Picture of roses file 12 In effect, it is contemplated that an automatic data mining system may take substantially the same steps as a human user would take in separating data into parameter- value pairs, and then loading such pairs onto the system. Another contemplated method of mining data is to provide a web crawler that scans web pages or other documents sequentially, or according to some other logic. In that scenario it is preferred that the web pages or other documents would tag selected information using tags that specify classification, parameters, and values. The system could use XML type tags for this purpose, some other tagging format, or even a combination of tagging formats - provided that the system could resolve the data into parameter-value pairs.
In Figure 4 a parameter selection interface 400 generally includes a header 405, a parameters table 410, Apha/Frequency navigation buttons 452, slider 413, a word entry interface 440, and other navigation buttons 454, 456.
The parameters table 410 preferably lists some or all of the parameters presently stored for a previously chosen classification 405. The first column 41 1 of table 410 lists the available parameters, the second column 412 lists the respective frequencies with which the corresponding parameter was historically utilized with respect to the chosen classification 405, while the third "column" 413 is really a slider used to view additional rows. One or more parameters can be selected by clicking on the desired row(s).
The default sort for the parameters is by frequency, although users can access alphabetic sort (including alphanumeric or numeric as appropriate) by clicking on the
Alpha/Freq toggle button 452. The Alpha/Freq toggle button toggles between Alpha when the list is displayed by frequency, and Freq when the list is displayed by Alpha. Users can also access alphabetic sort, and jump to a particular point in the alphabetic sort by entering a literal in the appropriate word entry interface 440, typing a literal in a parameters box (column 1) of table 200, or typing a literal in the parameters box in column 325 A of Figure
3.
It is contemplated that the absolute number of parameters allowed on the system for any given classification may advantageously be limited. For example, the classification of "real estate-residential-marketplace" may be limited to 80 parameters, while the classification of "office supplies and equipment-desk items-marketplace" may be limited to only 50 parameters. Because of the relatively small number of parameters contemplated for many, or even all, classifications, it is entirely possible that a simple viewing mechanism such as slider 413 will be sufficient to select among the various parameters. In other instances, it may be advantageous to include or substitute some other viewing mechanism, such as alphabetic buttons "A", "B", "C", etc that can be used to jump to parameters beginning with a particular letter. In still other embodiments it may be useful to include or substitute yet another viewing mechanism, such as a record number selected "1-15", "16- 30", etc.
The Cancel and Select navigation buttons 454 and 456, respectively, are intended to be similar to those used on other systems, and are self-explanatory
In Figure 5A a values selection interface 500 generally includes a header 505, a values table 510, a word entry interface 540, and other navigation buttons 552, 554, 556.
The values table 510 preferably lists some or all of the values presently being stored for a previously chosen classification and parameter. Here the available values are listed in column 51 1 with corresponding frequencies in column 512. Slider 513 is used to view additional values. As with the parameters selection interface of Figure 4, the default sort is by frequency, although users can access alphabetic sort (including alphanumeric or numeric as appropriate) by clicking on the Alpha/Freq toggle button 452. The Alpha/Freq toggle button toggles between Alpha when the list is displayed by frequency, and Freq when the list is displayed by Alpha. Users can also access alphabetic sort, and jump to a particular point in the alphabetic sort by entering a literal in the appropriate word entry interface 440, typing a literal in a parameters box (column 1) of table 200, or typing a literal in the parameters box in column 325 A of Figure 3.
The absolute number of values allowed on the system for any given classification and parameter may well be limited with respect to text values, but is probably unlimited with respect to numeric values. Thus, although it may be that a simple viewing mechanism such as slider 513 will be sufficient to select among the various values, other viewing mechanisms such as the alphabetic buttons or record number selectors discussed above may be utilized. The record navigation buttons 530 and other navigation buttons 540 are intended to be similar to those used on other systems, and are self-explanatory.
Figure 5B depicts the interface of Figure 5 A in which the choices are reduced in number because of filtering of other parameters by the user. In the particular example of Figure 5A, for example, the user is presumed to have selected a classification having automobile information as data. For a hypothetical parameter Model, the user elected to see the names of all models previously stored on the system with respect to the selected classification, and to list those models alphabetically. In Figure 5B the user presumably filtered his data by selecting a value of Chevrolet for Make, and therefore the only values showing for the parameter Model are Chevrolet models.
One of the enormous benefits of preferred systems and methods set forth herein is that users can access stored data using any combination of filters, and view the data using any combination of parameters. It is entirely possible, for example, for a user to select for all houses within a given price range, a given number of bedrooms range, and at least 100 feet of lakeside frontage without selecting a location at all. That degree of flexibility in searching is hitherto unknown on the Internet and elsewhere.
Figure 7 depicts a preferred interface 700 for selecting an alternative units measurement. Focus to this interface would most likely occur by clicking on the "Λ" or other symbol in any of the cells of column 226 of the main data entry table 220 of Figure 2, or on the "Λ" or other symbol in any of the cells of row 323, columns 326A, 326B, 326C, etc. of the main data retrieval table 330 of Figure 3.
The interface 700 preferably includes instruction lines 710, 720, and a units display table 730, and navigation buttons 742 and 744. The units display table 730 preferably includes only a few conversion units so that the entire units conversion can be readily downloaded to, and operated on the client side of the network. In this particular example there are three columns, a units description column 731 , a conversion factor column 732, and an accuracy column 733. The accuracy column provides indicates how the system will display the converted data. The entry "scientific notation" indicates that the system will display the converted data using scientific notation, the "+1 " entry indicates that the system will add one level of accuracy to that found in the source data, and the "same" entry indicates that the system will use the same of accuracy as that found in the source data.
Stored Searches
Figure 8 depicts a preferred Saved Searches interface 800, generally comprising a title 810, a main stored searches display table 820, and navigation buttons 831, 832, 833,
834. The main stored searches display table 820 includes a first column 821 containing user defined search designations, second, third, and fourth columns 822, 823, and 824 containing Level- 1, Level-2, and Level-3 class names, respectively, a fifth column 825 containing a designation of how often the search will be automatically run, a sixth column 826 containing a "Λ" symbol or other button for accessing the run schedule choices (weekly, monthly, etc), and a seventh column 827 that contains the last run date of the search. There is no slider because in at least preferred embodiments users are limited to a relatively small number of saved searches.
In this particular example the fourth row of data is partially completed because the user navigated to this interface 800 from a current search in the classification of Pets &
Animals / House Pets / Schools & Training. If the user enters a Search Name in the corresponding row of column 821 and then clicks on the Store button 832, the system will store the current search for future reference. Selecting a Run Schedule is optional. Searches run automatically by the system according to the Run Schedule only include data that is new to the system since the last run date, and searches that are not null are preferably send to the user via e-mail in spreadsheet format.
Previously stored searches are accessed by clicking on the appropriate row, and then clicking on the "Select" button 834. Stored searches are deleted by clicking on the appropriate row, and then clicking on the "Delete" button 833. The Cancel button 831 is self-explanatory.
Multi-Value and Range Searching
One especially useful feature contemplated herein is the ability to perform multi- value and range searches on target data that itself may include multiple values and ranges. In Figure 5B data rows 2, 3, and 6 have been highlighted by the user, and all three can be simultaneously selected for inclusion in filtering by clicking on the Select button 556. The same principle can be advantageously applied to the parameter selection interface of Figure 4. Still further, preferred embodiments include the ability to enter a value as a literal range, e.g. "between 15000 and 20000". Such a range may, for example, be included as a filter in a values cell of row 322 of Figure 3, or a values cell of column 223 of Figure 2. Because of the way the data structure is set up, (see e.g. discussion below with respect to Figure 9), both multiple value and multiple range searching can be accomplished merely by altering the database query.
This ability to conduct particular classes of multiple value and multiple range searching is itself new, as can be understood by reviewing the following chart.
Figure imgf000023_0001
Quadrant 1 represents the simplest type of search, where both the search data and the target data contain a single value for a parameter of interest. For example, a user searching to buy a dog through the Internet may enter the term "dogs" in a search field of a search engine. In the prior art, a search engine would have typically crawled through millions of web pages looking for tagged keywords, and would likely have stored the keyword "dogs" in an index for pages containing that term. The search engine would then match up the single value "dogs" against the index, and identify to the user the various pages that include the keyword "dogs". Quadrant 2 is similar to quadrant 1, except that the web pages contain multiple keyed terms for the same parameter. Thus, a single web page may refer to both "dogs" and "cats", which are either expressly or inherently correlated with a parameter such as Type of Pet. In a Quadrant 2 search the prior art search engines would identify web pages regardless of whether the user searched for "dogs" or "cats". In Quadrant 4 and 5 searches the user specifies multiple search terms that are concatenated either expressly or inherently using Boolean logic connectors such as "or" and "and". Thus, a user may search for "dogs" or "cats", and the search engine would return addresses to web pages that contain either term (Quadrant 4 search) or both terms (Quadrant 5 search).
Quadrant 1, 2, 4, and 5 searches are known to the extent that they do not involve searches in databases that store descriptions of items as parameter-value pairs. The
LEXIS™ and NEXIS™ databases, for example, all utilize Quadrant 1, 2, 4, and 5 searches. When applied to self-evolving databases, however, even these simple searches are thought to be novel.
Quadrant 3, 6, 7, 8, and 9 searches are all thought to be novel with respect to parameter-value type databases because they involve ranges. In a typical Quadrant 3 search, a user searching for a car may enter a value such as $17000, and that value is applied against a web page stating that cars are available for between $15000 and $20000. In Yahoo!™, Goto™, Lycos™, or any of the other prior art search engines there would be no match because the term $17000 does not match either $15000 or $20000. In embodiments of the present invention, however, there would be a match. For a parameter of Price, someone using an interface such as that shown in Figure 2 may well enter the value of "between 15000 and 20000" in column 223, and that information would have been stored on a database such as that depicted in Figure 9 as Value 1 = 15000 and Value2 = 20000. The search for $17000 would then match the stored record.
In Quadrants 7 and 8 searches a user may use an interface such as that shown in
Figure 3 to enter a value of "between $10000 and $15000" in row 322, column 325B. In a Quadrant 7 search preferred embodiments of the present system would located a web page having a value of $13000, while in a Quadrant 8 search preferred embodiments of the present system would located a web page having a multiple values of $10000, $12500, and $13000. In another example a user may be looking for cars with years after 1997, odometer reading less than 50000 miles, and price less than $15000. These searches would apply the indicated ranges against single or multiple stored values for the respective parameters.
The Quadrant 9 search is particularly powerful because it can identify items in which the search range overlaps the target range, such as the search range "between $70000 and $80000" matching a target range "$75000 - $1000000". This can be extremely useful, for example, in loading and searching insurance policies and other data. Thus, an insurance policy may limit policies to individuals having incomes of "$75000 - $1000000", while a person shopping for an insurance policy may list his income as "between $70000 and $80000. In another example, a toy manufacturer may price a particular toy "between $15.95 and $28.95" depending upon the color. A search for that toy would find a match if the searcher entered a price of "< $20.00".
Viewed generically, preferred embodiments of the present invention thus include methods of searching a database comprising: storing descriptions of a plurality of different items on the database as sets of parameter- value pairs, in which at least some of the values form a target; providing a search criterion such that at least one of the target and the search criterion comprises a numeric range; and identifying a successful search as occurring when there is an overlap between the search criterion and the target. Such methods may involve Quadrant 8 searches in which the overlap includes a portion of the target having multiple values for a particular one of the items, Quadrant 3, 6, or 9 searches in which the overlap includes a portion of the target having values stored as a range, Quadrant 6 searches in which at least a portion of the search criterion includes a collection of discrete values, Quadrant 7, 8, or 9 searches in which at least a portion of the search criterion includes a numeric range of values, and permutations thereof. More preferred embodiments are self- evolving in that they supply a user providing the search criterion with an ability to add new parameters to the database, and still more preferred embodiments guide the user in the addition of the new parameters by displaying historical summary usage information, such as relative historical usage information on a percentage scale for other parameters previously employed in the same classification.
Classification Systems Figure 6 depicts an exemplary three level classification system. Level 1 (shown in column 1) includes a relatively small number of classes, Advertising & Marketing, Agriculture, Art, Automobiles, Beauty & Grooming . . . Transportation, Travel, and Weapons. Level 2 (shown in column 2) includes varying numbers of classes hierarchically related to corresponding Level 1 classes. The exemplary classification system of Figure 6 is typical in that many or even most of the Level 2 classes make sense only with respect to the related Level 1 classes. Thus, under the Level 1 class of Agriculture one finds Level 2 classes of Animal Production, Chemicals, Crop Production, Florists, etc. These Level 2 classes make sense with respect to Agriculture, but are generally inconsistent with respect to other Level 1 classes such as Art or Automobiles. Levels 1 and 2 can also be described as having a superior / inferior relationship, with Level 1 being relatively superior and Level 2 being relatively inferior
An exemplary Level 3 (shown in column 3) includes 89 classes, many of which are referred to herein as "spanning classes" because they are logically related to many or all of the Level 1 / Level 2 classifications. For example, the Level 3 class of Awards could well apply to the Level 1 / Level 2 classification path of Advertising & marketing / Personnel Recruitment. But Awards also applies to the Level 1 / Level 2 classification path of Art / Artists. As another example, the Level 3 class of Industry Information applies to the Level 1 / Level 2 classification paths of Agriculture / International, Automobiles / Trucks, and Beauty & Grooming / Nails.
An alternative Level 3 (shown in column 4) includes only 47 classes. Astute observers will recognize that of the classes have been collapsed, and some of the categories have been eliminated entirely. For example, Importing and Exporting are subsumed under the more general class entitled Trade. Another alternative Level 3 (shown in column 5) is even more collapsed, including only 28 classes. Here, for example, the classes of Consortia and Cooperatives are collapsed into a single class named Companies, and Enthusiasts is subsumed under People. Also, Conventions & Conferences and meetings are merely types of Events, and so have been eliminated.
In repeated use by numerous end-users it is contemplated that "holes" will be found in the classification system, i.e. goods or services that are not readily classified using the existing classification. Some of these "holes" can be accommodated through the use of "Miscellaneous" classes. Such problems can also be resolved by expanding the number of classes. But in general it is preferred that each Level be limited to no more than about 30 - 50 classes for easy viewing and comprehension by the users. Classification systems contemplated herein can include up to 10 or more levels, but preferably no more than about five levels. At first one would think it impossible to accommodate millions of different types of goods and services with only a three to five Level classification system. But such accommodation is indeed very possible by combining the classification system with a parameter- value method of storing and retrieving data.
Exemplary parameter- value systems are described in US Pat. Appl. No. 09/128116 referred to above.
Yet another benefit is that classification can be readily summarized for users in code format. The classification path of Automobiles / Cars / Marketplace, for example, could be coded with only four numeric digits as 527 or 8103, or with a three digit alphanumeric code such as G57 or H29. This is because contemplated classification systems may only have about 10,000 or fewer permutations. Individual codes can advantageously be provided to web-site developers for inclusion into their web pages, and used in combination with XML or other tagging system to direct a search engine to automatically apply a desired classification. The classification codes could thus be used by millions of unrelated users in a manner analogous to the way real estate agents us the Thomas Guide™ page and grid codes.
If desired, the type of classification systems contemplated herein can readily accommodate services as well as products. For example, for the Level 1 class of Automobiles may well include a service-related Level 2 class of Repairs & Maintenance.
Similarly, the otherwise product oriented Level 1 / Level 2 classification of Automobiles / Trucks addresses services by inclusion of the service-related Level 3 class of Schools & Training.
In a similar fashion the type of classification systems contemplated herein can readily accommodate opinions, polls, and indeed information of all types. The presently described systems and methods address these additional types of data very effectively, in part because in the parameter-value aspect the users themselves decide what parameters relate to what classifications, and what values relate to those parameters. Such systems are preferably made to be inherently self-evolving at least in part by providing subsequent users with summary comparison usage information based upon the choices of previous users, and in part by permitting subsequent users to can add new add classifications, parameters, and values instead of being limited by those previously used by others. Summary comparison usage information is preferably communicated to users in the form of listings in which the choices are presented in order of descending usage. In that manner parameters and values that are used more frequently bubble to the top of the list, while parameters and values that are used less frequently sink to the bottom of the list. Very poorly used parameters and values can even be deleted periodically.
Additional details and observations regarding preferred classification systems are contained in co-pending application ser. no. 09/478102, filed January 4, 2000, and incoφorated herein by reference.
Usage Information
The term "user" is employed herein to mean an end-user of the database, i.e. an ordinary person or business who is either listing an item on the database, or looking for an item, or both. One of the big distinctions over the prior art is that users of the database can add new classifications, and/or parameters, and/or values, rather than waiting for a programmer or systems designer to do so. In that manner the aggregate of users largely control the evolution of the database rather than a few programmers or other individuals. That is what makes the database or system self-evolving.
The term "usage information" is employed herein in a very broad sense to include information relating to occurrence, absolute or relative frequency, or any other data that indicates the extent of past or present usage with respect to the various choices. It is contemplated, for example, that the choices for which usage information is displayed would include one or more of item classifications, geographic classifications, parameters, and values. It is also contemplated that the usage information displayed may relate to subsets of choices determined by a user's own previous responses, the term "subset" being employed herein to include proper and improper subsets. Thus, when selecting a minor item classification, the system may display a listing of possible minor item classes determined by the user's selection of major classification, along with relative usage information among the displayed minor classes. Similarly, the item descriptions displayed, and the corresponding usage information, would preferably be a function of the major and minor item classes selected. As yet a further example, the parameters and/or values displayed, and the corresponding usage information would preferably be a function of the item selected, and possibly also of the geographic class(es) selected.
The term "usage information", however, is not unlimited in scope. Usage information as employed herein is meant to be inherently comparative and summary in nature, so that usage information does not include a user successively performing keyword searches and viewing the numbers of hits independently of one another. Also, the terms "historical usage information" and "usage information" are used herein in slightly different manners. Historical usage information necessarily includes data that has accumulated over time, while usage information may or may not include data, and may therefore be limited to information gleaned from data currently on the system.
Usage information can be presented in many ways. In Figures 1 , 4 and 5, usage information is shown on a relative frequency scale as an integer from 1 to 100, with the data rows sorted from highest frequency at the top to lowest frequency at the bottom. In other embodiments, usage information can be displayed by depicting absolute frequency, by depicting occurrence of number of uses or "hits", or even by displaying data or data rows in different colors or using other identifying indicia.
It should be appreciated, however, that not all prior usage information is summary comparison usage information as that term is employed herein. For example, some prior usage information is commonly provided in ordinary listings of automobiles for sale. Such items as price are very frequently included in such listings, and subsequent users can see for themselves what prices are being asked for particular makes, models and years. In fact, it is by perusing such lists that many individuals determine the price at which they list their own car for sale. But such listing provide only individual usage information for each item, they do not provide summary information. The subsequent users need to summarize that information for themselves. Nor do automobile "for sale" listings provide summarize the information in a comparative format, such as comparative listings of car prices by frequency. Moreover, while it is true that some indices such as used car guides do provide summary comparison information for various makes, models, and years, that information is based upon factors other than usage information for the database at hand, and is not accompanied by offers for individual cars. The self-evolving approach systems and methods described herein can be used for all manner of products and services. For example, the self-evolving database concept is readily applied to employment want ads. In such cases it is likely that users would add parameters such as nature of employer, location, educational requirements, experience requirements, duties, salary, etc. As another example, the self-evolving database concept is readily applied to personal advertisements. There, likely parameters include marital status, race, sex, sexual preferences, hobbies, likes and dislikes.
It should also apparent to those skilled in database design that the inherent flexibility in parameter selection allows users to store and access information objects other than text. For example, users may choose specialized parameters that store image files such as TIFF or GIFF files, video clips such as MPEG or AVI files, audio clips such as WAV files, word processing documents such as WORD or WordPerfect files, tables such as Excel files, hyperlinkable URLs, and so forth. The URLs are thought to be especially useful as links to the web sites of others, or even simply to video or other files. Users may also choose to store entire audio-video electronic commercials such as those marketed by eCommercial.com, or slide shows, net-decks, or advertising coupons. Some of the parameters may be used to store multiple types of files. In preferred embodiments appropriate icons would appear in cells of data rows of the data selection and display matrix. Users would click on the icon, and the system would then display the contents of the file. It is also contemplated that an interface would be provided for users to download such files.
Still other specialized parameters may be employed to conduct auctions. For example, a user may choose to list the items of interest using the parameters of "last price bid", "last bid date", and "closing date/time". This capability is especially powerful because it allows a user to view information stored on all items of interest, whether such items were listed as fixed price offers, auctions, or whatever. A user looking for a particular book, for example, would be presented with a single table showing fixed price offerings from volume retailers such as Amazon.com and BarnesandNoble.com, as well as offerings of smaller companies, individuals selling new and used copies of the book, offerings by auction, and so on. It is especially contemplated that both auction and non-auction (sales, lease, rental, etc) offerings can be displayed in the same table at the same time merely by selecting appropriate parameters.
Thus, it is expressly contemplated herein to provide a method of storing and displaying information in which entries for items being auctioned, as well as entries for items being sold by a method or methods other than auction, are stored as sets of parameter- value pairs, and then displayed to a potential customer in a matrix format in which individual cells contain values from the parameter-value pairs. The item(s) being auctioned may be similar or even identical to the item(s) being sold other than by auction, or they may be quite different from one another. Similarly, the parameter-value pairs for the item(s) being auctioned may be stored on the same database as the item(s) being sold other than by auction, in overlapping databases, or in completely independent databases. The matrices discussed here, as well as elsewhere in this application, may have contiguous or noncontiguous cells, and may include navigational aids that accommodate more columns and/or rows than are viewed at a single time.
In yet other aspects of preferred embodiments, search strategies (which would include the classification, parameters, and values used to obtain a results set), can be stored either locally to a user (perhaps as a cookie), or stored centrally. This would allow a user to develop a search over time, and then run the search again using a keyword or other locator, rather than having to reconstruct the entire search. Of course, one of the parameters utilized across all item characterizations is likely to be listing date or update date, and searches could be stored that only look for items entered after the last time the search was run. In still another variation the system could store a search strategy, run the strategy periodically, and then e-mail the user who entered the search only upon selecting a non-null results set.
Database Implementation Of course, all of the above can be implemented in any number of ways, provided that the user is able to select choices based in some manner upon the usage (relative or absolute) of those choices by others. Nevertheless, some implementations are undoubtedly better than others, and it is contemplated that the system can be best implemented as discussed below. In Figure 9 depicts a preferred data structure 900 for accommodating the various principles and advantages described herein. Data structure 900 generally comprises a classification table 910, a parameter table 920, a values table 930, an entries (items) table 940, a parameters-value table 950, and several supporting tables (not shown). In this particular structure the number of tables and fields is thought to have been optimized to enhance performance for Microsoft™ Sequel Server 7. Those skilled in the art will recognize, however, that other data structures may be better optimized for other database managers. As the database is developed for actual usage, additional fields may be added as well to various tables, and additional tables (including vendor records and so forth) may be added.
The Classification table 910 includes fields for Class key 911, Level- 1 912, Level-2 913, and Level-3 914 class literals, and a field storing a maximum number of parameter- value pairs 915. These fields should all be self-explanatory.
The Parameters table 920 includes a Parameter Key 921, and a Class Key 922 that relates back to the Class Key 91 1 of Classification table 910. Although parameter literals are thus stored repeatedly, it is thought that there are sufficiently few parameters that the inefficiency of storage is outweighed by the efficiency in accessing parameter frequencies for specific classes. Synonyms for parameter literals are preferably stored by including the synonym literal in the Parameter Literal field 923, storing the Parameter Key 921 of the root or base parameter in the Synonym Param Key field 925. That way a search for any parameter among a set of synonyms can identify all Parameter Keys 921 in the set. The Parameter Freq field 924 stores the historical occurrence with which this particular parameter and classification combination has been used. The system can then calculate relative frequencies with which different parameters have been used for the same class. Frequency fields 924, 956 are maintained on an ongoing basis in Parameter table 920 and
Parameter-value table 950, respectively, to avoid having to recalculate the frequencies on the fly. The Units Key 926 related back to a Units table (not shown) that includes a corresponding Units Key, and fields for the literal name of the units (miles, kilometer, etc), a base unit of measurement into which the units can be converted, a conversion factor, and a default rounding factor. Thus miles would likely be converted into kilometers with a conversion accuracy indicator. Alternatively, the result of the conversion can use the same level of accuracy as the data being converted. From inclusion of the Units Key 926 in the Parameters table 920 it should be apparent that each parameter within each class is contemplated to have only a single parameter.
The Values table 930 is straightforward, containing a Value Key field 931, a Value Literal field 932 and a Synonym Value Key field 933. The preferably operates in an analogous manner to the Synonym Param Key field 925. For text values it may be highly efficient for the Value Key field 931 to contain a very simple alphanumeric key, such as V99231. For numeric values it may be efficient for the Value Key field 931 to contain the numeral in some standard format to facilitate range searching when the Value Keys are used in Value Key-1 953 and Value Key-2 954 in the Parameter-Value table 950,
The Entries table 940 is used to correlate sets of parameter-value pairs that represent a particular item. Thus, a person listing a car for sale may have the car data split up into 20 parameter-value pairs, which would be stored in the parameter-value table 950. When the system later needs to collect those 20 parameter-value pairs together, it does so because all of those parameter-value pairs have the same Entry Key 941 in Entry Key field 957. The
Entries table 940 also includes a Vendor Key 942 field that contains a key referring back to a Vendors table (not shown) that contains name, address, phone numbers, billing information, and so forth. . The Entries table 940 also includes a Load Date field 943 and an Expiration Date field 944 that indicate when the particular entry was originally loaded onto the system, and when it is scheduled to be deleted, respectively. Entries may well be deleted a month after being added unless the vendor providing the data pays a fee to maintain the data on the system, especially for vendors having more than a small number (possibly 5 or 10) of entries. The Rate Code field 945 is used to store information on how each particular entry is being billed. The Rate Code field 945 may, for example, list a monthly billing charge for each item, with items listed for free having a rate code of zero.
It is also especially contemplated that some individuals or companies will choose to utilize the database systems and methods described herein both to present information to the public, and to maintain information for themselves. In such circumstances the database structure of Figure 9 could be duplicated locally to the individual or company, with some of the parameters, values, and parameter-value records stored locally behind a firewall, and some of the records stored in a public access database. In that case data can be correlated between the two systems by using a common Entry Key 941 on the two systems, or preferably by storing on the local system a second entry key pointing to the Entries table 940 of the public access database.
One contemplated use would be for an insurance company to store doctor information on the public access system, and proprietary or confidential information on their local system. Users behind the firewall of the insurance company could readily access all the parameters and values made available to the public through the public access system, but additionally access the proprietary or confidential information as extensions of the public access data - and all of this can be done using a single interface such as the main display table 330 of Figure 3A. The only difference is that users behind the insurance fire wall would potentially have more choices for their parameters and values than would the public access users. In the meantime the public access users would have no idea that the proprietary or confidential information even existed. This scenario could be extended even further, with multiple offices, individuals or companies having their own "extensions" to the same basic data.
The Access Restriction field 946 and Access Code field 947 provide a person or company loading data with a means of keeping that data away from others. One contemplated use is to keep adult materials from under-age users. For example, a vendor can load images and other data onto the system, using parameters and values to describe whatever is being offered. When a subsequent user accesses that information in a table such as the main display table 330 of Figure 3 A, only the text will appear in the cells. If the user then clicks on the Select button 332 to view the full record, he would be presented with an access screen (not shown) corresponding to a code stored in the Access Restriction field
946. The access screen would have functionality for weeding out the under-age users, and in this instance preventing them from viewing the videos or images contained in the full record. In other contemplated scenarios, the access screen could have functionality that provides access only to users entering a code that matches the data in the Access Code field
947. In general, then, systems and methods are contemplated for permitting those listing data on the system to bear the responsibility for policing access to their own information.
The Parameter-Value table 950 stores a Parameter-Value (PV) Key 951 , which is probably not used anywhere else in the database. It is unlikely that the Parameter- Value table 950 will be sorted by PV Key 951, and instead it may be kept more or less sorted by the Parameter Key 952 that relates back to the Parameter Key 921 of Parameters table 920. Most likely, the Value Key-1 always contains data because it stores a key for either a single value where no range is involved, or for the low value where a range is involved. The Value Key-2 most likely contains data only where a range is involved, and in that case includes a key for the high value of the range. To simplify matters, it is preferred that ranges always interpreted as being inclusive on both ends. The Correlation field 955 can be used for all sorts of purposes, but preferably to store the sort information discussed above with respect to Figures 3A - 3E.
There will presumably be hundreds of thousands, or even millions of records in some of these tables, especially the parameters-values table 950. For operational efficiency, one might therefore advantageously split up the parameters-values table 950 into smaller tables that handle subsets of data, such as particular classifications. Logical or even physical separation of the data in this manner should be transparent to the user. Of course, other database structures could have an entirely different design, and the appended claims are not to be limited to the particular database structures set forth herein as examples. An earlier design that may yet prove to be useful in some circumstances is that disclosed in priority document US Pat. Appl. No. 09/1281 16.
Operation of a system using tables of Figure 9 should now be readily apparent to those skilled in the art. The general flow in retrieving data is that a user selects a classification (classification path), either by performing a tree search through the classification system, or by entering one or more search terms in an interface such as the item description section 110 of Figure 1.
In tree searching the system would first display all Level- 1 classes stored in the Classification table 910 of Figure 9. Upon selection of one of the Level-1 classes by the user, the system would search for and display all Level-2 classes subordinate to the selected Level-1 class. The user would then select one of the listed Level-2 classes, and upon such selection the system would search for and display all Level-3 classes subordinate to the selected Level-1 class. It is preferred, however, that all of the Level 3 classes would be spanning classes that are more or less applicable to all of the Level-2 classes, and would be displayed no matter what Level 1 / Level 2 choices the user had previously made. Where the user selects a classification by entering one or more search terms in an interface such as that depicted in Figure 1, the system would search the Level-1, level-2 and Level-3 fields for matches, and display the selected record set in descending frequency order as in the table 130 of Figure 1. In performing the search the system may well employ a synonyms table (not shown). If no matches were found the system would then search the value field of the parameter- value table 950, and work backwards from the selected record set to determine the corresponding classifications to display. Here again the system may advantageously employ a synonyms table (not shown). If no entries are found for the selected classification, the user would be notified of same, and prompted to add an item using a display as in Figure 2. Such an event may actually be a powerful incentive to a user, because that user has a wonderful opportunity to shape the parameters and values of that classification for future users.
Upon selection of a classification, the system would display data interface such as the three-row parameter/filter/units selector 320, and the main data display table 330 of figure 3. The data in the parameter/filter/units selector 320 is determined by searching through the Parameter-Value table 950 for records having the selected classification. The system then calculates relative frequencies for the parameters, and displays the top five to ten parameters (depending on system settings) as defaults in the parameters row 321. The user can modify those parameters or add new parameters in other columns. The system then fills in the corresponding data in the main data display table 330, which process does not require another search since the relevant record set was already located. Similarly, selecting parameters for the various columns of the parameter/filter/units selector 320, and displaying the parameters selection interface of Figure 4 does not require any further trips to the database since all parameters for the selected classification were already located.
If the user chooses to apply any filters to the database, the system will need to search the Parameter- Value table 950 to determine what values have been used for the selected parameters within the selected classification. Once that information is obtained, the system calculates the relative percentages on the fly, and displays the information in the values portion of the main display table 330 of Figure 3, and as needed the values table 510 of Figure 5. When a user wants to add a new item (entry), the system displays five to ten, or other number of the top frequency parameters for the selected classification, and then waits for the user to enter corresponding values, or change the selection of parameters. Values entered by the user are verified against the Parameter- Value table 950 for the selected classification and parameter, or alternatively values are chosen from the values listing of
Figure 5 as described above.
Although this discussion focused primarily on the user selecting only a single classification, it is contemplated that the system can operate in a substantially similar fashion to accommodate selection of multiple classifications for both retrieving data and for entering new data.
Non-Marketplace Information
In addition to storing and retrieving product information, the systems and methods described herein are applicable to storing and retrieving information regarding services, as well as other forms of information. The global applicability derives in part because the self- evolving concept allows users to be creative in establishing parameters and values. For example, a user may store scientific articles or other information relating to such articles using parameters such as "article name", "author", "abstract", "keywords", and "full text". Historical facts can be stored articles using parameters such as "type of information" (where the value is "historical facts"), "subject matter" (where the value may be "ancient Rome"), "persons involved" (where the value may be "Nero").
In this application all information is tautologically divided among marketplace information, opinion surveys, scientific information, legal information, and general information. All information that specifies a monetary value for an item, i.e., descriptions of items for sale, lease, purchase, and so forth, that are denominated in dollars, Yen, or any other currency, is considered to be marketplace information. Of the information that is not marketplace information, all information that contains numeric summarizations of opinions is deemed to be opinion surveys. Of the information that is not marketplace information or opinion surveys, all information that includes a reference to a scientific journal, a description of an experiment, invention or discovery, technical data such as measurements and constants, engineering and other technical drawings, or taxonomies are deemed to be scientific information. Of the information that is not marketplace information, opinion surveys, or scientific information, all information that includes a reference to a scientific journal, a description of an experiment, invention or discovery, technical data such as measurements and constants, engineering and other technical drawings, or taxonomies are deemed to be scientific information. Of the information that is not marketplace information, opinion surveys, or scientific information, all information that contains a citation to a statute or case law, or a quotation of a statute or case law, or is not a contract, is deemed to be legal information. All information that is not marketplace information, opinion surveys, scientific information, or legal information is deemed to be general information.
Scientific Information
In Figure 10, for example, an embodiment provides a classification interface 1000 similar to the interface 100 of Figure 1. Here a user entered the word "polymers" in a data entry field 1010, and the system provided a listing 1020 of all classifications including the term "polymers". The listing 1020 has five columns 1021 - 1025 and a vertical slider 1026. In the fifth column 1025 the system presents frequency information that assists the user in choosing among the various classifications. Some of these classifications may deal with offers to buy or sell polymers, but some of the classifications may also deal with miscellaneous information, including scientific articles, historical facts, and so forth. As with the marketplace indices described herein, the classification system itself can be self evolving, allowing anyone to enter any classification he wants, where the classifications most commonly used bubble to the top, and those infrequently used sinking to the bottom.
In Figure 11, a user has selected a classification 11 10 of Plastics / Polymers / Polyesters, either by a keyword path or a tree search, and the system responded by displaying a table 1120 containing information related to the classification. Here the table 1120 has six columns 1 121 - 1126, and a vertical slider 1 128. By including a horizontal slider more rows can be utilized than can be visualized on the display at any given time. Each column contains cells having values for a given parameter, which is named in the first row 1131. If the current user wants to limit the column to records in which the chosen parameter matches a particular value or range of values, he can do so by entering the value or range of values in the second rowl 132 of the corresponding column. In Figure 11, no values were selected. The data rows 1 133 - 1 139 can contain data cells, with each row corresponding to a different entry. The final row 1 150 can be used to add a new item. Advertising graphics 1140 may be included as well.
At least some of the columns are preferably dictated by the user. In this particular instance, the user chose to include "Type of Story" in the second column 1 122, "Company Involved" in the third column 1 123, and so forth. Again, as with the marketplace indices described herein, the second row of each column can be used as a drop-down window to select parameters, where the user is guided by information relating to usage of these parameters by previous users. Of course, the user did not have to select the parameters shown here, and may well have had several dozen parameters to choose from. Ideally, the parameter choice is limited to parameters previously employed with respect to the classification chosen.
Sorting may be enforced by the user, or may occur from left to right, or in some other manner. Thus, the highest level sort may be determined by the data in the first column, the next highest level sort being determined by the data in the second column, and so forth.
It is contemplated that the system may be configured so that a user can adjust the widths of the columns, and possibly even the number of columns. And although each record is shown on a single line in Figure 11 , it is contemplated that a user could choose a multiple line format for one or more rows. If multiple line rows are not allowed, then a user could view the entire cell in an overlying window, perhaps by double-clicking on the cell.
Data entry is contemplated to generally follow the teachings set forth with respect to the marketplace indices. Among other things, a person entering a record (i.e. a story line or item), can be guided by information relating to prior usage as to both parameters and values, whether that information is depicted a frequency, count, percentage, color, position within a table, and so forth. In addition, an idea not described with respect to the market place indices is that a user could couple his record to an existing record. In that manner, a subsequent user could find an item of interest, and then click on some portion of the related row, such as the cell in the first column of the row, to bring up all stories that were identified as being related. General Information
Figure 12 is a sample of a display screen similar to Figure 12. Again the user has selected a classification 1210 of Plastics / Polymers / Polyesters, either by a keyword path or a tree search, and the system responded by displaying a table 1220 containing information related to the classification. Here the table 1220 has four columns 1221 - 1224, and a vertical slider 1225. By including a horizontal slider more rows can be utilized than can be visualized on the display at any given time. Each column contains cells having values for a given parameter, which is named in the first row 1231. If the current user wants to limit the column to records in which the chosen parameter matches a particular value or range of values, he can do so by entering the value or range of values in the second rowl232 of the corresponding column. In Figure 12, no values were selected. The data rows 1233 - 1237 can contain data cells, with each row corresponding to a different entry. The final row 1250 can be used to add a new item. Advertising graphics 1240 may be included as well. In this instance, the user chose a Sports/Olympics/Drug Use classification. Also, the user limited the items listed to those items in which the Type of
Story was entered as medical, and the posted date was after February 2, 1999.
Storing And Retrieving Opinions
Turning to storing and retrieving of opinions, it is contemplated that the system can operate in a manner substantially similar to that described herein for marketplace information, and news and information. In Figure 13, for example, a user entered the name, Clinton, and was presented with a listing of classifications relating to people's opinions regarding Clinton. In this particular instance, the user checked off the third row of data, relating to Hillary's run for a senate office seat.
In Figure 14, the user has chosen to list questions according to frequency. No limitation (in row 2) as to the value of the frequency was selected, so that even questions that garnered minimal interest are included. Other columns selected list numbers of "yes" responses, numbers of "no" responses, total numbers of responses, dollar amounts, and average dollar amounts. Examples of possible other columns which were not selected are standard deviation, and other statistical functions. In addition, a user could have a text column, which might seek adjectives to describe a particular venture. In data row 3, for example, a question was listed that asks for an adjective. The user chose the fourth column to list adjectives, and in the pull down of the values (not shown) may have received a listing of what adjectives were used by what percentage of respondents. Alternatively, the user could have entered a particular adjective as a value designation in the second row, and then chosen the other columns to obtain data with respect to respondents choosing that adjective. More complex tables can also be provided that statistically analyze specific responses to a given question.
It is especially contemplated that the system can keep track of identifiers for individual users, so that their opinions about literally hundreds of various things can be accumulated over the years. Of course, those skilled in the art will recognize that all of the other options described herein with respect to for marketplace information, and news and information can also be applied to opinions.
Historical Events
Historical facts may be readily stored as event/outcome pairings. For example, a user in the field of chemistry may choose to store the results repeated experiments using a given protocol in a single record. Illustrative parameters and values are listed below in a format similar to that of Figure 2:
Parameter Value Units Sort Delim
Protocol X5 Hamster Test text 1
Subject number 1 number 2
Gender M text 3
Age 2 months 4
X5 3 ml 5
Weeks after injection 1 weeks 5
Reduction in tumor 2 % 5
X5 3 ml 6
Weeks after injection 2 weeks 6
Reduction in tumor 15 % 6
X5 3 ml 7
Weeks after injection 4 weeks 7
Reduction in tumor 22 % 7
The system can readily be configured to perform statistical calculations (averages, standard deviation, etc) on data within a single entry, and on data across multiple entries - and produce corresponding graphs as desired. The statistics and/or graphs can be stored in specialty parameters, or displayed in separate windows. One particularly useful embodiment is for the insurance company to store treatment information in parameters such as diagnosis, treatment, and results. The system could then automatically calculate the percentages with respect to doctors in a given hospital, geographic region, or specialty, or those utilizing a given treatment for a given diagnosis. Such information would be presented automatically in a values type interface such as that depicted in Figures 5B. But instead of selecting a car make and viewing the relative percentages of the models for that particular make, a user would select a diagnosis and view the relative percentages of the treatments for that particular make. Alternatively the user could select a diagnosis and a treatment, and view the relative percentages of the corresponding treatment results. Still other parameters covering signs and symptoms could be added so that the database would evolve over time to be an incredibly useful statistical resource. Moreover, analogous information could be stored and retrieved in many fields, including herbs and alternative medicine, or even car repair. It would be very interesting, for example, for a user to compare what repairs tend are performed by a particular service station with repairs performed by the industry in general, or by repair shops in a local area.
Other parameters may, for example, be useful in providing auction information. It is contemplated, for example, to provide parameters such as Auction Opening Date, Auction Closing Date, Auction Closing Time, No of Bids, Most Recent Bid, and Bidding History. The Bidding History parameter would most likely be a specialty parameter that engaged a program to produce the history. These parameters can be displayed along with any other selected parameters, so that a single table can contain both auction and "for sale" information. Still further, those skilled in the art will recognize that the same table can also contain any other information desired by the viewer. In looking for a book, for example, a viewer can see not only prices, delivery and other information from many different vendors, but also auctions, rentals, prices of used copies, and so forth. In short, the viewer gets to see all the information that he wants to see, and none of the information that he doesn't want to see.
User Developed Categorization System
In still another example of the flexibility of the systems and methods discussed herein, the self-evolving type of parameter- value database can be utilized to provide an index to case law. The LEXIS™ system, for example, does not presently have a sophisticated key indexing system such as that found on the Westlaw™ system. On the other hand, a given user may well find that the Westlaw™ key system does not characterize the cases in a manner especially useful to that particular user. Under the presently contemplated self-evolving database concept, users could categorize cases in any manner that they choose, and then record their own summaries or other interpretations of cases of interest to them using parameter-value pairs. LEXIS™ or Westlaw™ could keep track of such categorizations and parameter- value pairs as a service for the users, but then also make available to all users the categorizations and parameter-value pairs used by others. In that manner categorizations and summaries of cases in each particular field and subfield would eventually evolve to reflect what the users have stored for their own benefit. This would allow LEXIS™ to develop its own key-type system without doing much of anything. In the hands of Westlaw™, systems according to the present invention could be used to supplement the existing key system.
Viewed generically, the contemplated user developed categorization systems can be considered as a method comprising: providing an interface through which a user can categorize a document indexed on the database using at least one parameter-value pair; providing the user with a first listing that displays a set of parameters previously used by others in categorizing other documents; providing the user with a second listing that displays a set of values previously used by others in categorizing the other documents; and allowing the user to add a new value to the set of values such that subsequent users will have access to the new value. In such methods the development or "evolution" of the categorization may be either entirely or only partially dependent upon actions of the users.
In one aspect of preferred embodiments the step of providing the user with a first listing includes displaying historical usage information for individual members of the displayed parameters. In another aspect of preferred embodiments the step of providing the user with a second listing includes displaying historical usage information for individual members of the displayed values. Still another aspect of preferred embodiments further comprises allowing the user to add a new parameter to the set of parameters such that subsequent users will have access to the new parameter. Yet another aspect of preferred embodiments further comprises storing the at least one parameter-value pair in a storage system distal to the user, and providing the user with access to the at least one parameter- value pair at a future date through a network.
Variable List Keyword Searching
Another potentially valuable feature of in preferred embodiments of the present invention is that they can provide values lists that are automatically shortened as the user narrows in on his search. Matthew Bender™, for example, markets a CD ROM based database product for accessing intellectual property case law. In that system users are assisted in formulating their queries by access to "word wheel" listing all of the indexed keywords on the system. The word wheel is advantageous in many ways, such as preventing mis-spellings of keywords on the part of the searcher, and identifying alternative word spellings and even mis-spellings in the case law. Unfortunately the keywords in existing word wheels are all jumbled together rather than being separated according to some sort of usage classification. Another problem with existing word wheels is that the keywords are displayed are always the entire keyword listing rather than just those keywords located in a previously selected subset of records. This wastes time since it does a user precious little good for a user to add a keyword to his search strategy if the keyword is not present in any of his documents. Still another problem with existing word wheels is that they either do not show the frequency of the keywords in the documents, or the frequencies are not updated as the search proceeds to narrower and narrower record sets.
All of these problems are resolved by preferred embodiments of the present invention. Assuming, for example, that each litigation opinion were stored on the presently described system as a collection of keywords, with the various sections of the case defining the parameters. Thus, corresponding to the parameter of Parties one would find values of IBM, Jones, and the name of other litigants in the cases. Advantageously, the values listing for the Parties parameter would not contain names that are listed only in the body section.
Similarly, the values listing for the parameter Opinion Date would include only dates, and not the names of parties. This solves the jumbling problem alluded to above.
The narrowing problem would also be solved, since preferred systems would automatically narrow the listed values depending upon the filtering being used. In the same manner that the listing of models of automobiles was narrowed in Figure 5B over that depicted in Figure 5 A by virtue of the user having selected a particular make of automobile, the values listing for Parties would be narrowed by selecting cases involving a particular judge or court, or cases decided after a given date.
The third problem of depicting frequencies would also be solved. Preferred embodiments of the present invention automatically display values with their corresponding frequencies of use. In the descriptions above the frequencies are shown in relative frequency format as a percentage from 0 to 100, but they could readily (and even more simply) by shown as the raw occurrence frequency. Still further, however they are displayed, the frequencies would automatically be updated as filtering occurs.
Viewed generically, these advantages can be considered to result from any method of searching a database having a plurality of records, in which the method comprises: deriving a plurality of terms from the plurality of records; displaying to a user at least some of the terms in a first interface; selecting a search term from the plurality of terms; using the search term to derive a subset of records from the plurality of records; using the search term to derive a subset of terms from the plurality of terms; and displaying to the user at least some of the subset of terms in a second interface. It is contemplated that in such methods the terms would often be ordinary text, or perhaps alphanumeric, and that the terms could advantageously be listed in either alphanumeric or frequency order. Also, the interfaces would likely comprise one or more windows on a computer operated display screen, although as technology progresses the interfaces may be completely or primarily audial
(sound based) rather than visual. The records in such methods would very likely include web pages on the Internet, but may be alternatively or additionally include any documents. As discussed above, parsing and./or tagging may be used to separate out individual terms (values) from the documents, and however derived the terms may advantageously be stored as values of parameter-value pairs.
Conclusion
It should be apparent from the above discussion that systems and methods employing the contemplated aspects of parameter-value databases, and especially the self- evolving embodiments of such databases, are a significant improvement over all previously known database systems, and especially over previously known publicly modifiable, and wide access database systems such as Internet search engines. The preferred embodiments allow users to quickly and efficiently access hundreds of thousands or even millions of records, and still find only those few records that are relevant. Even more importantly, the preferred embodiments allow users to add data and search for items according to parameters and values in a manner that allows the entire database to evolve.
Thus, numerous systems and methods relating to parameter- value databases, and especially self-evolving databases, have been described herein. While specific embodiments and applications of this invention have been shown and described, it would be apparent to those skilled in the art that many more modifications are possible without departing from the inventive concepts herein. Among other things, for example, the concepts discussed herein can be employed in narrow access databases, such as those directed to employees or customers of a single company. The invention, therefore, is not to be restricted except in the spirit of the appended claims.

Claims

CLAIMS What is claimed is:
1. A method of searching a database, comprising; storing descriptions of a plurality of different items on the database as sets of parameter- value pairs, in which at least some of the values form a target; providing a search criterion such that at least one of the target and the search criterion comprises a numeric range; and identifying a successful search as occurring when there is an overlap between the search criterion and the target.
2. The method of claim 1 wherein the overlap includes a portion of the target having multiple values for a particular one of the items.
3. The method of claim 1 wherein the overlap includes a portion of the target having values stored as a range.
4. The method of claim 1 wherein at least a portion of the search criterion includes a collection of discrete values.
5. The method of claim 1 wherein at least a portion of the search criterion includes a numeric range of values.
6. The method of claim 1 wherein the overlap includes a portion of the target having multiple values for a particular one of the items, and at least a portion of the search criterion includes a collection of discrete values.
7. The method of claim 1 wherein the overlap includes a portion of the target having values stored as a range, and at least a portion of the search criterion includes a numeric range of values.
8. The method of claim 1 further comprising: supplying a user providing the search criterion with an ability to add new parameters to the database.
9. The method of claim 8 further comprising: guiding the user in the addition of new parameters to the database by displaying historical usage information.
10. A method of storing data comprising: providing a database that stores descriptions of items as sets of parameter- value pairs; providing a correlation field in a table that includes data specifying at least some of the parameter-value pairs; and using the correlation field to record a relationship among parameters-value pairs within at least one of the sets.
1 1. The method of claim 10 wherein the step of using the correlation field includes loading the correlation field with numbers to establish a sort order for display of a subset of corresponding values.
12. The method of claim 10 wherein the step of using the correlation field includes loading the correlation field with numbers to record a chronological relationship among a subset of corresponding values.
13. The method of claim 10 wherein the step of using the correlation field includes loading at least some of the correlation field with duplicate values.
14. The method of claim 1 wherein the step of providing the database comprises allowing users to add new parameters to the database.
15. The method of claim 14 further comprising guiding the user in the addition of new parameters to the database by displaying historical usage information.
16. A method of developing a categorization system for a keyword accessed database, comprising: providing an interface through which a user can categorize a document indexed on the database using at least one parameter-value pair; providing the user with a first listing that displays a set of parameters previously used by others in categorizing other documents; providing the user with a second listing that displays a set of values previously used by others in categorizing the other documents; and allowing the user to add a new value to the set of values such that subsequent users will have access to the new value.
17. The method of claim 16 wherein the step of providing the user with a first listing includes displaying historical usage information for individual members of the displayed parameters.
18. The method of claim 16 wherein the step of providing the user with a second listing includes displaying historical usage information for individual members of the displayed values.
19. The method of claim 16 further comprising allowing the user to add a new parameter to the set of parameters such that subsequent users will have access to the new parameter.
20. The method of claim 16 further comprising storing the at least one parameter-value pair in a storage system distal to the user, and providing the user with access to the at least one parameter-value pair at a future date through a network.
21. A method of searching a database having a plurality of records; deriving a plurality of terms from the plurality of records; displaying to a user at least some of the terms in a first interface; selecting a search term from the plurality of terms; using the search term to derive a subset of records from the plurality of records; using the search term to derive a subset of terms from the plurality of terms; and displaying to the user at least some of the subset of terms in a second interface.
22. The method of claim 21 wherein at least some of the plurality of records comprise web pages on the Internet.
23. The method of claim 21 wherein the step of deriving the plurality of items comprises parsing at least some of the records into words, indexing the words, and using at least some of the indexed words as the plurality of terms.
24. The method of claim 21 wherein the step of deriving the plurality of terms comprises searching at least some of the records for tagged data, indexing the tagged data, and using at least some of the tagged data as the plurality of terms.
25 The method of claim 21 wherein the step of deriving the plurality of terms comprises storing information found in at least some of the records as parameter- value pairs, and using at least some of the values of the parameter- value pairs as the plurality of terms.
26. The method of claim 21 wherein the step of displaying at least some of the terms comprises listing the terms at least partially according to prior usage of the terms.
27. The method of claim 21 wherein the step of using the search term to derive a subset of records comprises: storing information found in at least some of the records as parameter-value pairs; using at least some of the values of the parameter-value pairs as the plurality of terms; storing the plurality of terms in a first table; storing a plurality of keys correlating a subset of the parameter- value pairs in a second table; joining the first and second tables; and searching the first table for a group of records including the search term.
28. The method of claim 21 wherein the step of using the search term to derive a subset of terms from the plurality of terms comprises: storing information found in at least some of the records as parameter-value pairs; using at least some of the values of the parameter-value pairs as the plurality of terms; storing a plurality of values of the parameter-value pairs in a first table; storing a plurality of keys correlating subsets of the parameter- value pairs in a second table; joining the first and second tables; and searching the first table for a group of records including the search term.
29. The method of claim 21 further comprising: selecting a second search term from the subset of terms; deriving a second subset of records from the plurality of records using the second search term; and deriving a second subset of search terms from the plurality of search terms using the second search term; displaying at least some of the second subset of search terms in a third interface.
30. A method of storing information for multiple types of items in a database, comprising: providing a user with a parameter list relating to at least a portion of the multiple types of items, wherein at least one of the multiple types of items is selected from the list consisting of opinion surveys, scientific information, legal information, and general information; providing a first data entry interface that allows the user to add an additional parameter to the parameter list; and providing a second data entry interface that allows the user to use the additional parameter to record additional data relating to the item.
31. The method of claim 30 wherein the multiple types of items includes opinion surveys.
32. The method of claim 30 wherein the multiple types of items includes scientific information.
32. The method of claim 30 wherein the multiple types of items includes legal information.
33. The method of claim 30 wherein the multiple types of items includes general information. AMENDED CLAIMS
[received by the International Bureau on 25 October 2000 (25.10.00); original claims 1, 10, 16, 21 and 30 amended; remaining claims unchanged (4 pages)]
1. A method of searching a database, comprising; storing descriptions of a plurality of different items on the database as sets of textual parameter-value pairs other than location-value pairs, in which at least some of the values form a target; providing a search criterion such that at least one of the target and the search criterion comprises a numeric range; and identifying a successful search as occurring when there is an overlap between the search criterion and the target.
2. The method of claim 1 wherein the overlap includes a portion of the target havin^ multiple values for a particular one of the items.
3. The method of claim 1 wherein the overlap includes a portion of the target having values stored as a range.
4. The method of claim 1 wherein at least a portion of the search criterion includes a collection of discrete values.
5. The method of claim 1 wherein at least a portion of the search criterion includes a numeric range of values.
6. The method of claim 1 wherein the overlap includes a portion of the target having multiple values for a particular one of the items, and al least a portion of the search criterion includes a collection of discrete values.
7. The method of claim 1 wherein tlie overlap includes a portion of the target having values stored as a range, and at least a portion of the search criterion includes a numeric ran 'gόe of values.
The method of claim 1 further comprising: supplying a user providing the search criterion with an ability to add new parameters to the database.
9. The method of claim 8 further comprising: guiding the user in the addition of new parameters to the database by displaying historical usage information.
10. A method of storing data comprisin : providing a database that stores descriptions of items as sets of textual parameter- value pairs other than location-value pairs; providing a correlation field in a table that mcludes data specifying at least some of the parameter-value pairs; and using the correlation field to record a relationship among parameters-value pairs within at least one of the sets.
11. The method of claim 10 wherein the step of using the correlation field includes loading the correlation field with numbers to establish a sort order for display of a subset of corresponding values.
12. The method of claim 10 wherein the step of using the correlation field includes loading the correlation field with numbers to record a chronological relationship among a subset of corresponding values.
13. The method of claim 10 wherein the step of using the correlation field includes loading at least some of the correlation field with duplicate values.
14. The method of claim 1 wherein the step of providing the database comprises allowing users to add new parameters to the database.
15. The method of claim 14 further comprising guiding the user in the addition of new parameters to the database by displaying historical usage information.
16. A method of developing a categorization system for a keyword accessed database, comprising: providing an interface through which a user can categorize a document indexed on the database using at least one textual parameter-value pair other than a location-value pair; providing the user with a first listing that displays a set of parameters previously used by others in categorizing other documents; providing the user with a second listing that displays a set of values previously used by others in categorizing the other documents; and allowing the user to add a new value to the set of values such that subsequent users will have access to tlie new value.
17. The method of claim 16 wherein the step of providing the user with a first listing includes displaying historical usage information for individual members of the displayed parameters.
18. The method of claim 1 wherein the step of providing the user with a second listing includes displaying historical usage information for individual members of the displayed values.
19. The method of claim 16 further comprising allowing the user to add a new parameter to the set of parameters such that subsequent users will have access to the new parameter.
0 The method of claim 16 further comprising storing the at least one parameter- value pair in a storage system distal to tlie user, and providing the user with access to the at least one parameter-value pair at a future date through a network.
21 A method of searching a database having a plurality of records; deriving a plurality of textual terms from the plurality of records, wherein at least some of the terms for a given record are not literally found m the given record; displaying to a user at least some of the terras in a first interface; selecting a search term from the plurality of terms; using the search term to derive a subset of records from the plurality of records; using the search term to derive a subset of terms from the plurality of terms; and displaying to tl e user at least some of the subset of terms in a second interface.
22 The method of claim 21 wherein at least some of the plurality of records comprise web pages on the Internet. joining the first and second tables; and searching the first table for a group of records including the search term.
29. The method of claim 21 furtlier comprising: selecting a second search term from the subset of terms; deriving a second subset of records from the plurality of records using the second search term; and deriving a second subset of search terms from the plurality of search terms using tlie second search term; displaying at least some of the second subset of search terms in a third interface.
30. A method of storing information for multiple types of items in a database, comprising: providing a user with a parameter hst relating to at least a portion of the multiple types of items, wherein at least one of the multiple types of items is selected from the list consisting of opinion surveys, scientific information, legal information, and general information; providing a first data entry interface that allows the user to add an additional parameter to tlie parameter list; and providing a second data entry interface that allows the user to use the additional parameter to record additional textual data relating to the item, wherein the data is not location data.
31. The method of claim 30 wherein the multiple types of items includes opinion surveys.
32. The method of claim 30 wherein the multiple types of items includes scientific information.
32. The method of claim 30 wherein the multiple types of items incl udes legal information.
The method of claim 30 wherein the multiple types of items includes general information.
54
Figure imgf000055_0001
PCT/US2000/005638 2000-03-03 2000-03-03 Improved parameter-value databases WO2001067300A1 (en)

Priority Applications (2)

Application Number Priority Date Filing Date Title
AU2000233946A AU2000233946A1 (en) 2000-03-03 2000-03-03 Improved parameter-value databases
PCT/US2000/005638 WO2001067300A1 (en) 2000-03-03 2000-03-03 Improved parameter-value databases

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/US2000/005638 WO2001067300A1 (en) 2000-03-03 2000-03-03 Improved parameter-value databases

Publications (1)

Publication Number Publication Date
WO2001067300A1 true WO2001067300A1 (en) 2001-09-13

Family

ID=21741116

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/US2000/005638 WO2001067300A1 (en) 2000-03-03 2000-03-03 Improved parameter-value databases

Country Status (2)

Country Link
AU (1) AU2000233946A1 (en)
WO (1) WO2001067300A1 (en)

Cited By (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2003027902A1 (en) * 2001-09-21 2003-04-03 Endeca Technologies, Inc. Hierarchical data-driven search and navigation system and method for information retrieval
WO2003027901A1 (en) * 2001-09-21 2003-04-03 Endeca Technologies, Inc. Scalable hierarchical data-driven navigation system and method for information retrieval
US6633903B1 (en) * 2000-03-23 2003-10-14 Monkeymedia, Inc. Method and article of manufacture for seamless integrated searching
WO2004057453A2 (en) * 2002-12-20 2004-07-08 Sap Aktiengesellschaft Scrolling through data in a graphical user interface
WO2004059525A2 (en) * 2002-12-30 2004-07-15 Richard Wiedemann Information management system
WO2004059526A2 (en) * 2002-12-30 2004-07-15 Richard Wiedemann Information management system
CN100403314C (en) * 2006-04-19 2008-07-16 华为技术有限公司 Data inquiry method

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5632009A (en) * 1993-09-17 1997-05-20 Xerox Corporation Method and system for producing a table image showing indirect data representations
US5745899A (en) * 1996-08-09 1998-04-28 Digital Equipment Corporation Method for indexing information of a database
US5802361A (en) * 1994-09-30 1998-09-01 Apple Computer, Inc. Method and system for searching graphic images and videos
US5802525A (en) * 1996-11-26 1998-09-01 International Business Machines Corporation Two-dimensional affine-invariant hashing defined over any two-dimensional convex domain and producing uniformly-distributed hash keys

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5632009A (en) * 1993-09-17 1997-05-20 Xerox Corporation Method and system for producing a table image showing indirect data representations
US5802361A (en) * 1994-09-30 1998-09-01 Apple Computer, Inc. Method and system for searching graphic images and videos
US5745899A (en) * 1996-08-09 1998-04-28 Digital Equipment Corporation Method for indexing information of a database
US5802525A (en) * 1996-11-26 1998-09-01 International Business Machines Corporation Two-dimensional affine-invariant hashing defined over any two-dimensional convex domain and producing uniformly-distributed hash keys

Cited By (13)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6633903B1 (en) * 2000-03-23 2003-10-14 Monkeymedia, Inc. Method and article of manufacture for seamless integrated searching
US7739357B2 (en) 2000-03-23 2010-06-15 Eric Justin Gould System, method, and article of manufacture for seamless integrated searching
US7653704B2 (en) 2000-03-23 2010-01-26 Gould Eric J System, method, and article of manufacture for seamless integrated searching
US7062483B2 (en) 2000-05-18 2006-06-13 Endeca Technologies, Inc. Hierarchical data-driven search and navigation system and method for information retrieval
WO2003027901A1 (en) * 2001-09-21 2003-04-03 Endeca Technologies, Inc. Scalable hierarchical data-driven navigation system and method for information retrieval
WO2003027902A1 (en) * 2001-09-21 2003-04-03 Endeca Technologies, Inc. Hierarchical data-driven search and navigation system and method for information retrieval
WO2004057453A2 (en) * 2002-12-20 2004-07-08 Sap Aktiengesellschaft Scrolling through data in a graphical user interface
WO2004057453A3 (en) * 2002-12-20 2004-12-29 Sap Ag Scrolling through data in a graphical user interface
WO2004059526A3 (en) * 2002-12-30 2004-09-23 Richard Wiedemann Information management system
WO2004059525A3 (en) * 2002-12-30 2004-09-10 Richard Wiedemann Information management system
WO2004059526A2 (en) * 2002-12-30 2004-07-15 Richard Wiedemann Information management system
WO2004059525A2 (en) * 2002-12-30 2004-07-15 Richard Wiedemann Information management system
CN100403314C (en) * 2006-04-19 2008-07-16 华为技术有限公司 Data inquiry method

Also Published As

Publication number Publication date
AU2000233946A1 (en) 2001-09-17

Similar Documents

Publication Publication Date Title
US20180075150A1 (en) Methods and apparatus for matching relevant content to user intention
US7181438B1 (en) Database access system
US7698315B2 (en) System and method allowing advertisers to manage search listings in a pay for placement search system using grouping
US10262028B2 (en) Simultaneous intellectual property search and valuation system and methodology (SIPS-VSM)
US8296296B2 (en) Method and apparatus for formatting information within a directory tree structure into an encyclopedia-like entry
US6732092B2 (en) Method and system for database queries and information delivery
US8015063B2 (en) System and method for enabling multi-element bidding for influencing a position on a search result list generated by a computer network search engine
US8380721B2 (en) System and method for context-based knowledge search, tagging, collaboration, management, and advertisement
US20040230461A1 (en) Methods and systems for enabling efficient retrieval of data from data collections
EP1282051A1 (en) System and method for enabling multi-element bidding for influencing a position on a search result list generated by a computer network search engine
US10026112B2 (en) Systems and methods for storing and retrieving goods and services information using parameter/value databases
WO2001067300A1 (en) Improved parameter-value databases
WO2001053967A1 (en) Improved parameter-value databases
Lucas et al. The present and future of internet search
WO2001063477A1 (en) Systems and methods for handling user-provided information on a network
WP Internet Information Aggregation using the Context Interchange Framework
Suen Internet information aggregation using the Context Interchange framework

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A1

Designated state(s): AE AL AM AT AT AU AZ BA BB BG BR BY CA CH CN CR CU CZ CZ DE DE DK DK DM EE EE ES FI FI GB GD GE GH GM HR HU ID IL IN IS JP KE KG KP KR KZ LC LK LR LS LT LU LV MA MD MG MK MN MW MX NO NZ PL PT RO RU SD SE SG SI SK SK SL TJ TM TR TT TZ UA UG US UZ VN YU ZA ZW

AL Designated countries for regional patents

Kind code of ref document: A1

Designated state(s): GH GM KE LS MW SD SL SZ TZ UG ZW AM AZ BY KG KZ MD RU TJ TM AT BE CH CY DE DK ES FI FR GB GR IE IT LU MC NL PT SE BF BJ CF CG CI CM GA GN GW ML MR NE SN TD TG

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

Ref country code: DE

Ref legal event code: 8642

122 Ep: pct application non-entry in european phase