WO2001063477A1

WO2001063477A1 - Systems and methods for handling user-provided information on a network

Info

Publication number: WO2001063477A1
Application number: PCT/US2000/004504
Authority: WO
Inventors: Robert Fish
Original assignee: Robert Fish
Priority date: 2000-02-22
Filing date: 2000-02-22
Publication date: 2001-08-30
Also published as: AU2000241684A1

Abstract

The present invention provides systems and methods for handling user-provided information on a network. In one aspect content providers list the URLs or other identification information for files under their control. By listing such information, the content providers give permission to one or more service operator to extract tagged information from the listed files. In a second aspect a service operator enters into contracts with at least some of its content providers, which contracts obligate the service operator not to display specified information. In a third another aspect a service operator prevents content providers from using all of the displayed parameters in loading new item description, thereby placing evolutionary pressure on the development of the parameters. In yet a fourth aspect the service operator tracks the relative frequencies with which various parameters in the sets of parameters are employed by the individuals in loading the new item descriptions.

Description

SYSTEMS AND METHODS FOR HANDLING USER- PROVIDED INFORMATION ON A NETWORK

BACKGROUND OF THE INVENTION

This invention relates to the field of wide area data networks. 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.

There are now numerous search engines that use keyword or tree searching to locate web sites on the Internet. Popular search engines include Yahoo!™, Lycos™, GoTo™, and Northern Light™. One main problem, however, is that the known search engines list documents, web sites, and such, rather than underlying data. Thus, if one is looking for a red

Mercedes™, it is of only very limited value to see a listing of a million web sites that contain the key words "red" and "Mercedes". A searcher still needs to visit the listed sites individually to obtain the desired information.

There are several virtual marketplaces that list underling data. Yahoo! Store™ and Amazon.com™, for example, each lists descriptions, prices, and other information for thousands of products being sold over the Internet. eBay™ and many other sites perform a similar function for items being auctioned. While in many instances the virtual marketplaces provide a huge improvement over search engines, they suffer from inconsistencies in the way products and services are described. Residential houses, for example, are best described using parameters such as number of bedrooms, number of baths, square footage, and the like, while automobiles are best described using a different set of parameters, such as make, model, year, color, and odometer reading. These inconsistencies have in the past been addressed by providing a great many different fixed parameter databases - one for each of the different product or service types. In fact, the term "multiple types" as in "multiple types of items, products or services", refers herein to items, products or services that vary sufficiently from one another that they are stored using at least some substantially inconsistent parameters. Residential houses are considered herein to be a different type of product from automobiles because residential houses and automobiles are described using substantially different sets of parameters. Under these definitions, residential houses and commercial real estate would also most probably be considered to be different types of products.

Recently, applications have been filed describing evolving parameter marketplaces.

Unlike the previously existing marketplaces in which the databases have fixed parameters that are generally only modified or supplemented by programming staff, the evolving parameter marketplaces are contemplated to provide databases in which ordinary end users can add new parameters, and such parameters are then made available for use by subsequent users. It is particularly desirable in the evolving parameter marketplaces that users are provided with summary historical usage information on the parameters, to guide the users in their choices of parameters to use in describing their own products, services, and other information. It is even more desirable for users to also be provided with summary historical usage information on the values previously used with respect to individual parameters, to guide the users in their choices of values to use in describing their own products, services, and other information. These improvements were variously described in the following applications: PCT/US99/17480, filed 2 August 1999; PCT/US00/01786 filed 24 January 2000; US 09/128116 filed 3 August 1998; US 09/431031 filed 29 October 1999; US 09/478102 filed 4 January 2000; US 09/477222 filed 4 January 2000; US 09/478116 filed 4 January 2000; US 09/477206 filed 4 January 2000; US 09/478101 filed 4 January 2000; US

09/490409 filed 4 January 2000; and US 60/172278 filed 17 December 1999, all of which are incorporated herein by reference in their entirety.

There are, however, still many problems that can be resolved in a manner that improves electromc searching. One problem is the difficulty of obtaining data to display. Search engines presently "crawl" the Internet, focusing on one page after another, and extracting information from that page. The process is extremely inefficient, and moreover, may result in legal problems from extracting information that the search engine has no legal right to extract, let alone re-publish.

Another problem involves control over content. If an operator of a search engine controls content, it can be held liable for displaying pornography or other information deemed to be undesirable. If the operator does not control content, then it will almost certainly run into public opposition for displaying undesirable content.

Another problem, which is specific to evolving marketplaces, involves controlling the addition of new parameters to provide evolutionary pressure. If users are allowed to add and utilize any parameters they want, the evolutionary pressure on the parameters is greatly reduced. If users are precluded entirely from adding parameters, the evolution of the marketplace can be greatly hindered.

. Still another problem involves profiling user preferences in evolving marketplaces. Existing methods of profiling focus on the values preferred by users, not the parameters.

SUMMARY OF INVENTION

The present invention provides systems and methods for handling user-provided information on a network.

In one aspect content providers list the URLs or other identification information for files under their control. By listing such information, the content providers give permission to one or more service operator to extract tagged information from the listed files. The content provider(s) visit the listed files, extract tagged information, and then display that information to others using a classification system. Among other benefits this arrangement can reduce or eliminate liability to the service operator for obtaining data, and can speed up the crawling process by focusing the service operator on files that contain extractable data.

In another aspect a service operator enters into contracts with at least some of its content providers, which contracts obligate the service operator not to display specified information. By satisfying its obligations under the contract, the service operator can keep undesirable information from being published, while correctly maintaining that it is not controlling content in a manner that incurs liability arising from controlling content.

In yet another aspect a service operator stores previously loaded item descriptions as collections of parameter- value pairs, and displays to the general public sets of parameters used in the parameter-value pairs to aid members of the public in loading additional item descriptions. Advantageously, however, the service operator prevents content providers from using all of the displayed parameters in loading new item description, thereby placing evolutionary pressure on the development of the parameters.

In yet a fourth aspect the service operator again allows individuals to add new parameters to the sets of parameters displayed to subsequent users, allows the individuals to load new item descriptions on the service using proper subsets of the sets of displayed parameters, but additionally tracks the relative frequencies with which various parameters in the sets of parameters are employed by the individuals in loading the new item descriptions.

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 file access interface.

Figure 2 is a table depicting an exemplary three level classification system.

Figure 3 is a flowchart depicting steps in establishing a preferred contractual relationship.

Figure 4 depicts portions of a suitable contemplated click through contract.

Figure 5 is a flowchart 50 depicting steps to provide evolutionary pressure on parameters.

Figure 6 is a preferred data entry interface.

Figure 7 is a typical contemplated parameters listing.

Figure 8 is a typical contemplated values listing.

Figure 9 is a flowchart depicting steps in a method of profiling user preferences

Figure 10 is a simple tracking table for tracking frequency of parameter usage. DETAILED DESCRIPTION

Listing of Files

In Figure 1 a preferred file access interface 110 generally contains a user reference section 120, a table 130 of file names and addresses, a confirmation block 140, and a navigation block 150.

The reference section 120 identifies the name of the content provider 121 as stored in the vendor file (not shown), and the name of the person completing the interface 122. The content provider may or may not be the same as the person completing the interface, and there may be other related interfaces used for authentication of some or all of this information. It is contemplated that more than one person may have authorization to control data in the table 130 for a given content provider 121.

The table 130 has seven columns, a trivial file name column 131, a URL or other file address column 132, a tag type column 133, an authorization date column 134, and authorization name column 135, a preferred update frequency column 136, a last update column 137, and a slider type record control 138. The columns should be self-explanatory to those skilled in the field. By way of further clarification, however, the URL column 132 is preferably associated with a browse interface (not shown) to assist the user in selecting the exact addresses. It is also preferred that the tag type column 133 and the preferred update frequency column 136 be associated with drop down or pop up functionalities from which the user can select only certain entries. The preferred tagging type is XML. The authorization date column 134, authorization name column 135, and last update column 137 are preferably controlled by the system rather than the user.

The confirmation block 140 includes a check box 141 that can be checked or unchecked by the user, and a textual authorization section 142 that is preferably customized by the system to correspond to the current user. More preferably the reference to the contract can be hyperlinked. Of course, the exact language may vary considerably, depending upon the wording desired by the service operator, which in this instance is bigfatfish.com.

The navigation block 150 contains a Cancel button 151 and an Accept button 152 as is well known in the art. Use of interface 110 is straightforward. In a preferred embodiment a user accesses interface 110 from a navigation button (not shown) on a membership interface (not shown). The user can add data to rows, and is preferably limited to a maximum number of files, such as 200 without special authorization. Entering data in the trivial file name column 131 may be optional, but most likely all the other fields are required, or are set by the system. Rows of data can be modified or deleted by the user, preferably with appropriate controls such as an "are you sure?" pop up window (not shown) to reduce accidental modifications. The authorization check box 141 is preferably left unchecked at the initialization of each instance of interface 110, thus requiring the user to re-authorize at each instance.

The interface 110 preferably forms part of a system embodying an evolving marketplace, but may alternatively form part of a system embodying a search engine, or any other suitable software or service. Such systems may be private or public, or some combination of the two. The most preferred systems access the listed files periodically, such as weekly or monthly in accordance with the data in update frequency column 136, and extract data from the files in accordance with the tagging protocols set forth in tagging type column 133. The extracted data is preferably classified automatically according to content (such as by identifying a classification most closely associated with the tagged values), or by locating one or more classification tags in the file. The data in the file, for example, may contain descriptions and prices for many items, and may be tagged in table format. Preferably the data extracted comprises descriptions of items offered in a marketplace. Such offerings can be offerings to sell or purchase, lease, auction, hire (as in employment), or any other type of transaction.

The data extracted is preferably displayed in accordance with a classification system that includes a plurality of spanning classes described in greater detail below.

Thus, methods of obtaining data for a public access database are contemplated that comprise the steps of providing an interface through which an information supplier can list file identification information for a file; providing a first system that uses the file identification information to access the file and load data contained within the file into the database; and providing a second system that classifies the data for display to the public according to a classification system. In preferred embodiments the first and second systems are part of a publicly accessible search engine, and the classification system includes a plurality of spanning classes.

Classification Systems

Figure 2 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 2 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 some 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 1527 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 use 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 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 incorporated herein by reference.

Service Operator Contract

Figure 3 is a flowchart 300 depicting steps in establishing a contractual relationship under which a service operator is obligated to avoid displaying undesirable information without otherwise monitoring content being displayed. More formally, the steps provide a method of operating a publicly accessible service, comprising: a service operator entering into a contract with a supplier under which the service operator is to refrain from displaying specified information 312; the service operator obtaining from the supplier data having a first portion that includes specified information and a second portion that is free of the specified information 314; the service operator storing at least some of the data in the database 316; and the service operator publicly displaying the second portion of the display information, and not displaying the first portion pursuant to the contract 318.

Preferably the contract obligates the service operator to display the second portion of the data to the general public, and more preferably the data comprises descriptions of items offered in a marketplace. Such offerings can be offerings to sell or purchase, lease, auction, hire (as in employment), or any other type of transaction. The database may also advantageously store the data as a plurality of pairs of parameters and values, and more preferably the method includes displaying at least some of the parameters to the general public in a listing according to a relative frequency of historical use in the database.

Figure 4 depicts clauses of a suitable contemplated click through contract. Of course such a contract would likely vary from service operator to service operator, and is likely customizable by the users. Although not shown, preferred contracts also include boilerplate provisions such as definitions of parties, arbitration clauses, venue and jurisdiction, additional limitations on liability, merger clause, and so forth.

Providing Parameters With Evolutionary Pressure

Figure 5 is a flowchart 500 depicting steps to provide evolutionary pressure on parameters. More formally, the steps provide a method of operating a publicly accessible service, comprising: a service operator storing previously loaded item descriptions as collections of parameter- value pairs, and displaying to the general public sets of parameters used in the parameter- value pairs to aid in loading additional item descriptions 512; providing an interface through which a supplier member of the general public loads a new item description on the service using the displayed parameters 514; and preventing the supplier from using all of the displayed parameters in loading the new item description 516.

Preferably, the method further comprises the supplier using an additional parameter in loading the new item description, the additional parameter not previously included in the displayed parameters, and subsequently made available for other suppliers to use in loading other item descriptions.

The method may also advantageously comprise the service operator from time to time restricting the supplier's adding of the additional parameter as a means of limiting a total number of parameters utilized for a particular item classification.

The method may also advantageously comprise displaying the displayed parameters to the supplier in a parameters listing, and more preferably comprise the service operator enforcing a maximum number of displayed parameters included in the parameters listing. The displayed parameters included in the parameters listing may also advantageously vary as a function of an item classification, and independently the parameters listing preferably lists the displayed parameters at least in part according to a measure of previous usage of the displayed parameters on the service.

These methods are exemplified in Figures 6 - 8. In Figure 6 a preferred data entry interface 600 generally includes a selected classification display 610, a data entry table 620, and navigational buttons 630.

The first column 621 in table 620 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 typical contemplated parameters listing such as that shown in Figure 7. The parameters listing can be displayed by clicking on the adjacent "^Λ" symbol or other button shown here in column 622.

The third column 623 in table 620 records values that the user wants to associate with the selected parameters. Thus, in the example of Figure 6, 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 6. The values interface can be accessed by clicking on the corresponding "^Λ" symbol or other button in column 624.

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 620. In most systems users are likely to be limited to employing 65 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 6 the parameter of Inventor is listed two times to account for this patent having two inventors. Similarly the parameter of Figure is listed two times to account for this patent having two pages of drawing.

The fifth column 625 of table 620 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. The system may advantageously keep track of default units in a Units Key field (not shown) 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 626 shows the "^Λ" or other symbol that can be clicked upon to display a values selection interface such as that shown in Figure 8. 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 627, 628, respectively, may well be displayed only to those users who have identified themselves as being advanced. Column 627 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 6 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.

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 627 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 627 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 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 627 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 627 stores delimiters that can be used in displaying data in desired sort order formats (not shown). 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 630 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 6, and returns the user back to the previous interface. The Record button starts the process of performing validity checks on the data of Figure 6, 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 7 a parameter selection interface 700 generally includes a header 705, a parameters table 710, Apha/Frequency navigation buttons 752, slider 713, a word entry interface 740, and other navigation buttons 754, 756.

The parameters table 710 preferably lists some or all of the parameters presently stored for a previously chosen classification 705. The first column 711 of table 710 lists the available parameters, the second column 712 lists the respective frequencies with which the corresponding parameter was historically utilized with respect to the chosen classification 705, while the third "column" 713 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 752. 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 740, or typing a literal in a parameters box in column 621 of table 620.

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 713 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 754 and 756, respectively, are intended to be similar to those used on other systems, and are self-explanatory

In Figure 8 a values selection interface 800 generally includes a header 805, a values table 810, a word entry interface 840, Alpha/Freq button 852, and navigation buttons 854, 856.

The values table 810 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 811 with corresponding frequencies in column 812. Slider 813 is used to view additional values. As with the parameters selection interface of Figure 7, 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 752. 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 740, or typing a literal in a values box in column 623 of table 600.

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 813 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 navigation buttons 854 and 856 are intended to be similar to those used on other systems, and are self-explanatory.

Profiling User Preferences

Figure 9 is a flowchart 900 depicting steps in a method of profiling user preferences comprising: a service operator storing previously loaded item descriptions as collections of parameter- value pairs, and displaying to the general public sets of parameters used in the parameter- value pairs to aid in loading additional item descriptions 912; allowing individuals to add new parameters to the sets of parameters displayed to subsequent users 914; allowing individuals to load new item descriptions on the service using proper subsets of the sets of displayed parameters 916; and tracking relative frequencies with which various parameters in the sets of parameters are employed by the individuals in loading the new item descriptions 918.

Preferred methods may further comprise displaying to the general public sets of values used in the parameter-value pairs to aid in loading additional item descriptions, and tracking relative frequencies with which various values in the sets of values are employed by the individuals in loading the new item descriptions.

The process by which such tracking can take place is straightforward. In Figure 10 a simple table 1000 can be constructed having three columns (fields) - one column 1010 for user identification codes, a second column 1020 for classification codes, a third column for parameter codes 1030, and a fourth column 1040 for count. Each time a user chooses to enter a value for a parameter, the system searches for a matching row of data (i.e., the same user, classification, and parameter), and if found increments the cell in the fourth column. If a matching row is not found, a new row is added, and the count is set to 1.

It is also contemplated that the parameter choices of those using the service for searching, as opposed to loading data, may be advantageously tracked. In either case the tracking information can advantageously be stored and/or displayed on an individual by individual basis, or for groups of individuals. Thus, in targeting commercial messages to a particular user, it may be useful to know that the particular user appears to be more interested in color of an automobile than its engine size. It may be useful to provide such information for a population or sub-population as a group.

Conclusion

Thus, numerous systems and methods for handling user-provided information on a network have been described. 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

CLAIMSWhat is claimed is:

1. A method of obtaining data for a public access database, comprising: providing an interface through which an information supplier can list file identifica- tion information for a file; providing a first system that uses the file identification information to access the file and load data contained within the file into the database; and providing a second system that classifies the data for display to the public according to a classification system.

2. The method of claim 1 wherein the first and second systems are part of a publicly accessible search engine.

3. The method of claim 1 wherein the classification system includes a plurality of spanning classes.

4. A method of operating a publicly accessible service, comprising: a service operator entering into a contract with a supplier under which the service operator is to refrain from displaying specified information; the service operator obtaining from the supplier data having a first portion that includes specified information and a second portion that is free of the specified information; the service operator storing at least some of the data in the database; the service operator publicly displaying the second portion of the display information, and not displaying the first portion pursuant to the contract.

5. The method of claim 4 wherein the contract obligates the service operator to display the second portion of the data to the general public.

6. The method of any one of claims 1 and 4 wherein the data comprises descriptions of items offered in a marketplace.

7. The method of claim 6 wherein the database stores the data as a plurality of pairs of parameters and values.

8. The method of claim 7 further comprising displaying at least some of the parameters to the general public is a listing according to a relative frequency of historical use in the database.

9. A method of operating a publicly accessible information service, comprising: a service operator storing previously loaded item descriptions as collections of parameter- value pairs, and displaying to the general public sets of parameters used in the parameter- value pairs to aid in loading additional item descriptions; providing an interface through which a supplier member of the general public loads a new item description on the service using the displayed parameters; and preventing the supplier from using all of the displayed parameters in loading the new item description.

10. The method of claim 9 further comprising the supplier using an additional parameter in loading the new item description, the additional parameter not previously included in the displayed parameters, and subsequently made available for other suppliers to use in loading other item descriptions.

11. The method of claim 9 further comprising the service operator from time to time restricting the supplier's adding of the additional parameter as a means of limiting a total number of parameters utilized for a particular item classification.

12. The method of claim 9 further comprising displaying the displayed parameters to the supplier in a parameters listing.

13. The method of claim 12 further comprising the service operator enforcing a maximum number of displayed parameters included in the parameters listing.

14. The method of claim 12 wherein the displayed parameters included in the parameters listing varies as a function of an item classification.

15. The method of claim 12 wherein the parameters listing lists the displayed parameters at least in part according to a measure of previous usage of the displayed parameters on the service. A method of profiling user preferences comprising: a service operator storing previously loaded item descriptions as collections of parameter-value pairs, and displaying to the general public sets of parameters used in the parameter-value pairs to aid in loading additional item descriptions; allowing individuals to add new parameters to the sets of parameters displayed to subsequent users; allowing individuals to load new item descriptions on the service using proper subsets of the sets of displayed parameters; and tracking relative frequencies with which various parameters in the sets of parameters are employed by the individuals in loading the new item descriptions.

The method of claim 16 further comprising: displaying to the general public sets of values used in the parameter- value pairs to aid in loading additional item descriptions; and tracking relative frequencies with which various values in the sets of values are employed by the individuals in loading the new item descriptions.

AMENDED CLAIMS

[received by the International Bureau on 20 December 2000 (20.12.00); original claims 1, 4, 9, 16 and 17 amended; remaining claims unchanged (3 pages)]

A method of obtaining data for a public access database, comprising: providing an interface through which an information supplier can list file identification information for a file; a service operator providing a first system that uses the file identification information to access the file and load data contained within the file into the database; and the service operator providing a second system that classifies the data for display to the public according to a classification system defined in part by both the information supplier and a competing information supplier.

The method of claim 1 wherein the first and second systems are part of a publicly accessible search engine.

The method of claim 1 wherein the classification system includes a plurality of spanning classes.

A method of operating a publicly accessible service, comprising: a service operator entering into a contract with a supplier under which the service operator is to refrain from displaying specified information provided by the supplier for public display; the service operator obtaining from the supplier data having a first portion that includes specified information and a second portion that is free of the specified information; the service operator storing at least some of the data in the database; the service operator publicly displaying the second portion of the display information, and not displaying the first portion pursuant to the contract.

The method of claim 4 wherein the contract obligates the service operator to display the second portion of the data to the general public.

The method of any one of claims 1 and 4 wherein the data comprises descriptions of items offered in a marketplace. The method of claim 6 wherein the database stores the data as a plurality of pairs of parameters and values.

The method of claim 7 further comprising displaying at least some of the parameters to the general public is a listing according to a relative frequency of historical use in the database.

A method of operating a publicly accessible information service, comprising: a service operator storing previously loaded item descriptions as collections of parameter- value pairs, and displaying to the general public sets of parameters used in the parameter- value pairs to aid in loading additional item descriptions; the service operator providing an interface through which a supplier member of the general public loads a new item description on the service using the displayed parameters; and the service operator preventing the supplier from using all of the displayed parameters in loading the new item description.

The method of claim 9 further comprising the supplier using an additional parameter in loading the new item description, the additional parameter not previously included in the displayed parameters, and subsequently made available for other suppliers to use in loading other item descriptions.

The method of claim 9 further comprising the service operator from time to time restricting the supplier's adding of the additional parameter as a means of limiting a total number of parameters utilized for a particular item classification.

The method of claim 9 further comprising displaying the displayed parameters to the supplier in a parameters listing.

The method of claim 12 further comprising the service operator enforcing a maximum number of displayed parameters included in the parameters listing.

The method of claim 12 wherein the displayed parameters included in the parameters listing varies as a function of an item classification.

The method of claim 12 wherein the naram eters listing lists the displayed parameters at least in part according to a measure of previous usage of the displayed parameters on the service.

A method of profiling user preferences comprising: a service operator storing previously loaded item descriptions as collections of parameter- value pairs, and displaying to the general public sets of parameters used in the parameter- value pairs to aid in loading additional item descriptions; allowing supplier to add new parameters to the sets of parameters displayed to subsequent users; allowing the suppliers to load new item descriptions on the service using proper subsets of the sets of displayed parameters; and tracking relative frequencies with which various parameters in the sets of parameters are employed by the suppliers in loading the new item descriptions.

The method of claim 16 further comprising: displaying to the general public sets of values used in the parameter- value pairs to aid in loading additional item descriptions; and tracking relative frequencies with which various values in the sets of values are employed by the suppliers in loading the new item descriptions.