WO2001053967A1 - Bases de donnees perfectionnees de valeurs de parametres - Google Patents

Bases de donnees perfectionnees de valeurs de parametres Download PDF

Info

Publication number
WO2001053967A1
WO2001053967A1 PCT/US2000/001786 US0001786W WO0153967A1 WO 2001053967 A1 WO2001053967 A1 WO 2001053967A1 US 0001786 W US0001786 W US 0001786W WO 0153967 A1 WO0153967 A1 WO 0153967A1
Authority
WO
WIPO (PCT)
Prior art keywords
parameter
values
user
terms
database
Prior art date
Application number
PCT/US2000/001786
Other languages
English (en)
Inventor
Robert D. Fish
Original Assignee
Fish Robert D
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 Fish Robert D filed Critical Fish Robert D
Priority to PCT/US2000/001786 priority Critical patent/WO2001053967A1/fr
Priority to AU2000228587A priority patent/AU2000228587A1/en
Publication of WO2001053967A1 publication Critical patent/WO2001053967A1/fr

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/30—Information retrieval; Database structures therefor; File system structures therefor of unstructured textual data
    • G06F16/38—Retrieval characterised by using metadata, e.g. metadata not derived from the content or metadata generated manually

Definitions

  • This invention relates to the field of wide area data networks.
  • the Intemet 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 Intemet 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.
  • NEXISTM the concept of "modem” may well be expressed using the term “modem”, but may also be expressed using the terms “contemporary”, “up to date”, “progressive”, “recent” or “prevailing”.
  • a legal database such as LEXISTM
  • 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
  • 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.
  • Some of the more sophisticated search engines such as LycosTM, Yahoo!TM, and so forth can search by keywords without knowing the name of the thing being searched, but such searches are notoriously over-inclusive. For example, someone using any of these search engines to purchase a red MercedesTM 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 MercedesTM. If the user tried 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”. Even if such searches could somehow be made neither over-inclusive nor under-inclusive, they would still be unsatisfactory because they would only point to web pages (i.e. documents) rather than listing the desired information in a nice table format for easy viewing and manipulation by the user.
  • keyword searches using existing technology are exceedingly poor at handling ranges. For example, if one is searching the Internet to buy a LexusTM 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”.
  • 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.
  • 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 110 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 stmcture 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 135 A 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 "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 " ⁇ " 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 differently colored telephones in the same enu . 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.
  • 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 classif ⁇ cation(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 325 A 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 ofautobytel.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.
  • 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.
  • 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 A or Tsort 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 Figures 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, FuUerton, CA, Bob 714-555-5555, $32,900, firm".
  • This display can be achieved by inputting the following information into the interface of Figure 2:
  • 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
  • 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.
  • 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:
  • 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 411 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 325A of Figure 3.
  • 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. 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
  • buttons 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 511 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 325A of Figure 3.
  • 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.
  • 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 instmction 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, 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.
  • 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.
  • 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 stmcture 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.
  • the 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.
  • FIG. 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
  • 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,
  • 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 / T cks, 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 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.
  • 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.
  • the type of classification systems contemplated herein can readily accommodate services as well as products.
  • the Level 1 class of Automobiles may well include a service-related Level 2 class of Repairs & Maintenance.
  • the otherwise product oriented Level 1 / Level 2 classification of Automobiles / Tmcks 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. 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.
  • 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. In such cases it is likely that 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.
  • 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.
  • 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.
  • 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 non-contiguous 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).
  • a classification table 910 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 911 of Classification table 910.
  • 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.
  • 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-2954 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.
  • 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
  • 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 3A, 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.
  • 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.
  • 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.
  • 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-
  • Level-2 classes 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 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.
  • 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 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.
  • 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 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 “ Egyptiant Rome”), "persons involved” (where the value may be “Nero”).
  • 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:
  • One parameter for storing opinions may include “Question” (where a value may be “should Hillary run for the senate?"). Other parameters may be "Yes”, “No”, “Undecided”, and “Comments”.
  • 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 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. 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.
  • 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.
  • 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.

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Library & Information Science (AREA)
  • Data Mining & Analysis (AREA)
  • Databases & Information Systems (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)

Abstract

L'invention se rapporte à des bases de données perfectionnées de valeurs de paramètres et à des procédés mettant en oeuvre de telles bases de données qui s'avèrent particulièrement avantageuses pour des utilisateurs chargeant des données et/ou effectuant des recherches. Dans un mode de réalisation, la base de données est utilisée pour identifier correctement le recouvrement entre des données de recherche et des données cibles, lesdits ensembles de données contenant toute combinaison de valeurs simples, de valeurs multiples et de plages de valeurs. Dans un autre mode de réalisation, des articles sont chargés dans la base de données en tant qu'ensembles de paires (326A) de valeurs de paramètres, des sous-ensembles de ces paires faisant l'objet de sous-corrélation dans des buts divers, et notamment en vue de l'établissement d'un ordre d'affichage, d'un ordre chronologique (334) ou en vue du couplage de regroupements des paires de valeurs de paramètres (326B). Dans un autre mode de réalisation, les utilisateurs sont autorisés à ajouter de nouveaux paramètres à la base de données de manière que celle-ci produise un système de catégorisation élaboré par l'utilisateur. Dans encore un autre mode de réalisation, les utilisateurs se voient présenter des listes de mots ou d'autres valeurs les aidant à effectuer leur recherche dans la base de données et ces listes deviennent moins longues à mesure que des filtres sont appliqués (330).
PCT/US2000/001786 2000-01-24 2000-01-24 Bases de donnees perfectionnees de valeurs de parametres WO2001053967A1 (fr)

Priority Applications (2)

Application Number Priority Date Filing Date Title
PCT/US2000/001786 WO2001053967A1 (fr) 2000-01-24 2000-01-24 Bases de donnees perfectionnees de valeurs de parametres
AU2000228587A AU2000228587A1 (en) 2000-01-24 2000-01-24 Improved parameter-value databases

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/US2000/001786 WO2001053967A1 (fr) 2000-01-24 2000-01-24 Bases de donnees perfectionnees de valeurs de parametres

Publications (1)

Publication Number Publication Date
WO2001053967A1 true WO2001053967A1 (fr) 2001-07-26

Family

ID=21740995

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/US2000/001786 WO2001053967A1 (fr) 2000-01-24 2000-01-24 Bases de donnees perfectionnees de valeurs de parametres

Country Status (2)

Country Link
AU (1) AU2000228587A1 (fr)
WO (1) WO2001053967A1 (fr)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP1788494A1 (fr) * 2005-11-21 2007-05-23 Sap Ag Suivi d'éléments de données dans des communications commerciales électroniques
US7711676B2 (en) 2004-11-12 2010-05-04 Sap Aktiengesellschaft Tracking usage of data elements in electronic business communications

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5769793A (en) * 1989-09-08 1998-06-23 Steven M. Pincus System to determine a relative amount of patternness
US5802524A (en) * 1996-07-29 1998-09-01 International Business Machines Corporation Method and product for integrating an object-based search engine with a parametrically archived database
US5940815A (en) * 1994-09-07 1999-08-17 Hitachi, Ltd. Data analyzing method

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5769793A (en) * 1989-09-08 1998-06-23 Steven M. Pincus System to determine a relative amount of patternness
US5940815A (en) * 1994-09-07 1999-08-17 Hitachi, Ltd. Data analyzing method
US5802524A (en) * 1996-07-29 1998-09-01 International Business Machines Corporation Method and product for integrating an object-based search engine with a parametrically archived database

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7711676B2 (en) 2004-11-12 2010-05-04 Sap Aktiengesellschaft Tracking usage of data elements in electronic business communications
US7818342B2 (en) 2004-11-12 2010-10-19 Sap Ag Tracking usage of data elements in electronic business communications
EP1788494A1 (fr) * 2005-11-21 2007-05-23 Sap Ag Suivi d'éléments de données dans des communications commerciales électroniques

Also Published As

Publication number Publication date
AU2000228587A1 (en) 2001-07-31

Similar Documents

Publication Publication Date Title
US10733250B2 (en) Methods and apparatus for matching relevant content to user intention
US8296296B2 (en) Method and apparatus for formatting information within a directory tree structure into an encyclopedia-like entry
US7698315B2 (en) System and method allowing advertisers to manage search listings in a pay for placement search system using grouping
US6732092B2 (en) Method and system for database queries and information delivery
US7181438B1 (en) Database access system
US8380721B2 (en) System and method for context-based knowledge search, tagging, collaboration, management, and advertisement
US20010049674A1 (en) Methods and systems for enabling efficient employment recruiting
WO2001067300A1 (fr) Bases de donnees a valeurs de parametres ameliorees
WO2001053967A1 (fr) Bases de donnees perfectionnees de valeurs de parametres
WO2001063477A1 (fr) Systemes et procedes de gestion d'informations fournies par l'utilisateur dans un reseau
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