WO2001063476A1

WO2001063476A1 - Systems and methods for using functionalities in virtual marketplaces

Info

Publication number: WO2001063476A1
Application number: PCT/US2000/004448
Authority: WO
Inventors: Robert D. Fish
Original assignee: Fish Robert D
Priority date: 2000-02-22
Filing date: 2000-02-22
Publication date: 2001-08-30
Also published as: AU2000230043A1

Abstract

The present invention provides systems and methods for using functionalities in virtual marketplaces. In broad terms the invention allows ordinary users of the virtual marketplace (whether content provider, searchers, or both) to provide custom functions to other users through the virtual marketplace. Such functions preferably operate on marketplace data contained within the marketplace, but need not do so. Preferred embodiments include evolving parameter marketplaces. Numerous functionalities are contemplated, including ordering or products, conversing with a sales representative, producing custom products, and providing statistical analysis. The functionality may be physically stored and executed on the hardware of the service provider, the content provider, the searcher, some other machine, or any combination of these.

Description

SYSTEMS AND METHODS FOR USING FUNCTIONALITIES IN VIRTUAL MARKETPLACES

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. Part of its success arises from the ability of ordinary users to post information and seek out information posted by others. An unfortunate side effect, however, is that both posting and searching methods have not kept pace with the enormous amount of information being provided.

Most of the information posted to the Internet is supplied in the form of web pages. Web pages are advantageous in that they are substantially free-form, thereby allowing individuals to express considerable creativity in posting information. One downside of such freedom, however, is that the posted information is largely accessible only through keyword type searching, through search engines such as Yahoo!™, Lycos™, GoTo™, and Northern

Light™. Such search engines are inherently both over-inclusive and under-inclusive, and often produce ridiculously large results sets containing thousands or even millions of entries. Another downside is that users supplying information in the form of web pages must often spend considerable resources programming or at least customizing their own interfaces. Such custom interfaces are then largely unavailable for use by others with respect to their storing and displaying their own information.

It is known for users to post information to services such as bulletin boards in a substantially freeform format. But other than categorizing the information by topic, most bulletin boards accept information with little or no structural constraints, thereby producing many of the same problems that arise from individuals loading data onto their individual web pages.

A major step in the evolution of the Internet was the addition of virtual stores that enforce at least some structure on the posters in the storage and presentation of information. The added structure makes the underlying data much easier to access, but at least historically has invariably limited the creativity with which posters can display their information. Previously known virtual stores, for example, have always provided fixed parameter databases for storing information relating to particular types of products. In such databases a used car may be described using a combination of pre-defined parameters such as make, model, year, color, mileage and price, while a residential house may be described using a combination of pre-defined parameters such as number of bedrooms, number of baths, square footage, etc. The fixed parameter nature of these databases not only limits the creativity of those listing information, but requires a large number of different databases and interfaces to accommodate many different types of products and services.

It is contemplated that the next major step in the evolution of the Internet will be the addition of an evolving parameter marketplace. Unlike the fixed parameter marketplaces in which the parameters are generally only modified or supplemented by programming staff, the evolving parameter marketplaces are contemplated to have 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 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/1722278 filed 17 December 1999, all of which are incorporated herein by reference in their entirety.

In addition to having the potential to greatly improve loading and searching of data on the Internet, evolving marketplaces can be implemented in ways that provide both the content provider and the searcher with interfaces of their own choice. For example, the US 09/490409 application disclosed the use of a sequence code that can be utilized by the content provider to structure a presentation of data to the searchers. The same application also disclosed various standard interfaces that can be selected by the searchers for use in place of the content providers' custom presentations.

It is now contemplated that even this level of customization and choice is unnecessarily limiting - primarily because all of these presentation interfaces are to some extent provided by the evolving marketplace service provider. Thus, there is a need for content providers and searchers to conveniently access data from an evolving or other virtual marketplace according to their own procedures and interfaces.

SUMMARY OF INVENTION

The present invention provides systems and methods for using functionalities in virtual marketplaces. In broad terms the invention allows ordinary users of the virtual marketplace (whether content provider, searchers, or both) to provide custom functions to other users through the virtual marketplace. Such functions preferably operate on marketplace data contained within the marketplace, but need not do so.

Preferred embodiments include evolving parameter marketplaces. In exemplary situations a service provider accepts both data and functionalities from a plurality of data providers, and displays subsets of both the data and the functionalities to end users, preferably in a table format. The data and functionalities are preferably stored as parameter- value pairs, with the columns of the table relating to selected parameters, and the cells of the various columns displaying values of the corresponding parameters. Of course the code sets driving the functionalities are not themselves displayed in the cell, but instead representations of the functionalities (graphical or textual icons) are displayed to represent the functionalities. End-users can access a functionality by clicking on a cell having an icon representing that functionality, or by moving the icon outside the cell, and then accessing the functionality from the new position.

The functionalities may operate without any interaction with the user, but more likely cause a new interface to open on the user's display. The user can then interact through the new interface. Most likely the new interface will also capture data from whatever row the functionality was contained, and may also capture data from cells located in other rows, or even within other display tables. It is also contemplated that a user can "drag and drop" data from cells into the new interface. Accordingly, users are not limited in their use of the virtual marketplace by interfaces provided by the virtual marketplace service provider. Instead, content providers (which in most cases may be independent from one another) can create or otherwise procure their own custom interfaces, which can then be hosted by the virtual marketplace service provider. Depending on the functionalities provided, content providers may well find it unnecessary to have their own web sites, instead of using the virtual marketplace as their web site. In other instances content providers may choose to maintain their own web sites, possibly to modify the functionality from time to time, or to save on storage costs. Conceptually it makes little difference to the virtual marketplace service provider where the data and the code for the functionalities are physically stored, and for purposes of discussion herein storage of data and functionalities at locations physically controlled by the service provider are deemed to be equivalent to storage of links to such data and functionalities that may be physically stored elsewhere.

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 interface for retrieving data.

Figure 2 is a schematic of an exemplary functionalities interface.

Figure 3 is a schematic of an alternative functionalities interface.

DETAILED DESCRIPTION

In Figure 1 a data retrieval interface 100 generally includes a selected classification display 110, a three-row parameter/filter/units selector 120, a main data display table 130, column navigation slider 140, record navigation buttons 150, and other navigation buttons

160. The selected classification display 110 displays the classification or classifications that the user is using, preferably from a three level classification system (not shown) that includes spanning classes.

The three-row parameter/filter/units selector 120 defaults to the five, ten or some other number of the most frequently used parameters for the chosen classification. Here the parameters are displayed as column headings. Of course columns and rows in display formats are more or less conceptually interchangeable, and all permutations of these are contemplated as alternative embodiments, as well as matrices in which the cells are noncontiguous horizontally, vertically, or in both directions.

The first row 121 of the parameter/filter/units selector 120 is labeled with the term

"Parameters" at the far left. The cells to the right are in pairs, with each pair having the same final letter. Thus, cells in row 1, columns 2 and 3 form a pair labeled 125 A, 126A, columns 4 and 5 form a pair labeled 125B, 126B, and columns 6 and 7 form a pair labeled 125C, 126C, etc. In each instance the first cell in the pair shows the parameter name used to define the data in the column of main display table 130 immediately below. In Figure 1, cell 125A shows the parameter City, which in this example refers to the location of a house offered for sale. Other parameters shown are No. Bedrooms, No. Baths, Picture, and More Info. The second cell in each pair displays a "^Λ" symbol or other button that leads the user to a parameter selection interface (not shown).

The second row 122 of the parameter/filter/units selector 120 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 (not shown).

The second row 122 is intended to receive values used in filtering the corresponding parameters. The filters are preferably null at the outset, but can be filled in by the users. One of the most important aspects of preferred systems is that they can display and filter on any combination of parameters. Thus, one can readily search all houses located within a given city or state, or houses for which the asking price falls within a given range. If the searcher is looking at cars, the filters might be used to see only red or white automobiles within a given price range, cars manufactured at least as recently as a particular year, and having no more than a given odometer reading, and so forth. The user can conduct successive searches, changing parameters and/or filters as desired.

The third row 123 of the parameter/filter/units selector 120 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 (not shown). The units information is employed in displaying the data in the corresponding column of the main data display table 130, with the system making appropriate calculations and rounding. Using this system, for example, a user can readily filter for and view Odometer data as miles or kilometers, regardless of how such data is stored, or convert Dollars into Yen.

The "Go Fish" button 128 tells the system to apply the parameters and value filters selected in rows 122 and 123, and produce the results in the main data table 130. Of course, other terms could be substituted for "Go Fish", including "Apply", or "Go", "Build Table", or "Submit", and the button 128 could be located elsewhere in the interface 100.

The main display table 130 preferably contains between 6 and 30 columns, with many of the columns being positioned off the screen at any given time. This can be accomplished by the usual Windows™ type of horizontal slider 140, 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 130, 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 130 of Figure 1 to better illustrate the preferred filtering techniques.

In Figure 1 the column farthest to the left is reserved for a "Select" button. Clicking on or near the word Select causes the system to display another interface (not shown) that preferably shows all the parameters and values stored on the system for the item (entry) having data displayed in the selected row. In preferred embodiments users can move directly to the "^Λ" symbol or other button, or alternatively users can type a parameter or value into the corresponding cell of the table. Upon tabbing or clicking out of the active cell, the system verifies the validity of the entry, and provides assistance (such as transfer to the appropriate parameter or value interfaces) if the entry is invalid.

Values are displayed in the various rows of the main data display table 130 that correspond to items matching the selected classification 110, the parameters selected or defaulted in row 121, and the filters selected in row 123, 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 121 A, 121B at the head of the desired column.

It is important to note that the cells of the table can include text, icons, hyperlinks to web pages, files or the like. Where a hyperlink is in the cell, users can preferably jump directly to the linked site. Where a video, audio or other file is indicated, users can preferably open and play or display that file as the case may be. Where an e-mail address is indicated, the system preferably opens an interface to facilitate recording and sending of an e-mail to that address.

The record navigation buttons 140 and other navigation buttons 150 are intended to be similar to those used on other systems, and are self-explanatory. The Spreadsheet button is used to send the data in the main display table 130 to the user as an Excel™, or perhaps some other spreadsheet format.

In the particular example of Figure 1, the sixth column of the main display table 130 is used to values for a More Info parameter. The corresponding Units is set to Function, which means that the values depicted in the cells comprise functions rather than data. For purposes of this example, there are two functions, a Talk With Agent Function, and a Prepare

CD function.

Figure 2 shows details of an exemplary Talk With Agent interface 200. Generally, the interface 200 contains a title section 210, a stored values data section 220, a user data section 230, a message section 240, and navigation buttons section 250. All of these sections are optional, or could be modified or substituted with other sections, and even when included can have entirely different fonts, formats, and so forth. The entire function is preferably designed by the content provider that provided the data for the corresponding row, and presumably was written to satisfy whatever particular interface needs were deeemed appropriate for that content provider.

The title section 210 is self-explanatory. For simplicity in this example the title has the same wording as the function name, but as noted above there is no requirement in that regard, and in fact the title section can be omitted entirely.

The stored values data section 220 preferably echoes all or some of the data from the row being selected. Thus, even though the user may only be viewing 6 rows, all of the data stored on the selected item may be echoed. On the other hand, the content provider may really only be interested in a subset of such data, or in the data for which the user provided filters. For example, an insurance company may choose to load information relating to its various policy offerings onto the system. Users could then see for themselves what policies are available by applying filters for gender, age, general health, or the like. It is the filters that may be of most interest to the insurer because that tells the insurer about the person doing the searching.

The user data section 230 is another way of obtaining data about the searcher. If the service provider has a sufficiently open system some or all of this information may be echoed from the user (searcher) membership record, and in any event may be added by the searcher as desired. In this example the stored values data section 220 and the user data section 230 are two columns of the same table, and share a vertical slider 239 to display information positioned out of view.

The message section 240 is shown here as a simple, stand-alone box, which may be entirely adequate. In other embodiments, however, the message section 240 may look more like an Outlook™ or HotMail™ e-mail message box. The message box may also be supplemented or replaced by a voice interface for live voice communication with a representative of the content provider. The navigation buttons section 250 contains two buttons in this example, a Cancel button 252 and a Send button 254, the uses of which are self-apparent.

Figure 3 depicts an alternative functionalities interface 300, generally comprising a title section 310, an instruction section 320, a user data section 330, a drag and drop receiving box 340, navigation buttons section 350, one or more branding or co-branding items 360, and one or more hyperlinks 370.

Most of these sections are self-explanatory. The title section 310 is similar to that described above with respect to Figure 2, except that here the title is worded differently from the name of the functionality that spawned it, and additional fonts are used. The instruction section 320 provides users with instructions for using the interface, and could be simple, extensive, and even hyperlinked to provide additional assistance. The user data section 330 captures whatever identification, billing, mailing or other information is deemed appropriate. The navigation buttons 352, 354 of navigation section 350 are also self-explanatory.

The drag and drop receiving box 340 is intended to act as a receptacle for icons of songs, either through drag and drop or cut and paste. The items added to the box may be icons contained in the main display table 130, or from elsewhere. Those skilled in the art will recognize that many other functions could be included or substituted, such as statistical routines where the user is prompted to drop data items (or indeed entire spreadsheets) into a receiving box.

It is contemplated that the content providers will likely choose to display their own branding labels, logos, and so forth, and may well choose to include brand names, logos and so forth of others. In this example the functionality involves making and delivering a custom CD, but the content provider is also co-branding the site with a Pepsi™ commercial message in branding section 360. The content provider has also chosen to provide a hyperlink 370 to its own web site.

The inventive subject matter is not, however, limited by the examples given above. For example, it is contemplated generally that functionalities will be provided that comprise a product ordering interface, or at least transmit information regarding the data searcher to a sales representative. Such interfaces may advantageously provide for live communication between the data searcher and a sales representative, and may also assist the data searcher in producing a custom product for the data searcher (such as the custom CD). The functionality may also provide a routine that alters the parameters and filters previously chosen by the searcher, thereby assisting the searcher to locate products of a given type, or manufacturer. Still other contemplated functionalities may assists a user in procuring a software update, or in indexing or tagging a document.

Since the items being searched can include all products, services, personal want ads, and even general information such as news and scientific information, the types of products being handled by the functionalities may be virtually anything, but especially including physical products and service products.

Where the functionality deals with statistics, the statistical routines may advantageously operate upon at least some of the values displayed in the table. Thus, a content provider having products to auction may include a functionality that statistically compares the progress of a given auction to other auctions for the same product. On the other hand, the functionality may provide an agent that searches for information not displayed in the table.

In terms of execution, the functionality may be executed on the hardware of the service provider, the content provider, the searcher, some other machine, or any combination of these. However, it is particularly contemplated that the functionality may be executed at least in part on a computer local to the data searcher, or at least in part on a computer local to the at least one of the plurality of data providers that loaded the functionality. Along the same line, storage of the various functionalities may occur executed on the hardware of the service provider, the content provider, the searcher, some other machine, or any combination of these.

In terms of access to functionalities, it is preferred that functionalities be accessed through icons displayed in the cells of the main display table 130. Alternatively or additionally the icons may be copied or moved outside the table, such as by dragging an icon to another area of the user's display. Depending on how this is done users may be able to access the functionality entirely independently from use of the table. An example would be a statistics routine that can be used at a later date. Thus, numerous systems and methods relating to systems and methods for using functionalities in virtual marketplaces have been described herein. While specific embodiments and applications of this invention have been shown and described, it would be apparent to those skilled in the art that many more modifications are possible without departing from the inventive concepts herein. Among other things, for example, the concepts discussed herein can be employed in narrow access databases, such as those directed to employees or customers of a single company. The invention, therefore, is not to be restricted except in the spirit of the appended claims.

Claims

CLAIMSWhat is claimed is:

1. A method of operating a public access data hosting service having at least one database, comprising: storing data from a plurality of data providers in the database as collections of parameter-value pairs; storing a functionality provided by at least one of the plurality of data providers for use by a data searcher; providing an interface through which the data searcher selects a set of parameter- value pairs that includes at least a portion of the data; and displaying a table having a plurality of cells, at least some of the cells being used to display a plurality of values from the selected set of parameter-value pairs, and at least another one of the cells being used to provide the data searcher with access to the functionality.

2. The method of claim 1 wherein at least some of the plurality of independent data providers are unrelated members of the general public.

3. The method of claim 1 wherein the functionality comprises a product ordering interface.

4. The method of claim 1 wherein the functionality transmits information regarding the data searcher to a sales representative.

5. The method of claim 1 wherein the functionality comprises an interface for live communication between the data searcher and a sales representative.

6. The method of claim 1 wherein the functionality comprises an interface that assists the data searcher in producing a custom product for the data searcher.

7. The method of claim 5 wherein the custom product comprises a physical product.

8. The method of claim 5 wherein the custom product comprises a service product.

9. The method of claim 1 wherein the functionality provides statistics related to at least some of the values displayed in the table.

10. The method of claim 1 wherein the functionality provides an agent that searches for information not displayed in the table.

11. The method of claim 1 wherein the functionality is executed at least in part on a computer local to the data searcher.

12. The method of claim 1 wherein the functionality is executed at least in part on a computer local to the at least one of the plurality of data providers that loaded the functionality.

13. The method of claim 1 further comprising storing a plurality of functionalities for the at least one of the plurality of data providers.

14. The method of claim 1 further comprising displaying an icon outside of the table on a display used by the data searcher for future use in accessing the functionality.

15. The method of claim 1 wherein the functionality comprises an interface that assists the data searcher in procuring a software update.

16. The method of claim 1 further comprising tagging the functionality in a publicly accessible document.

AMENDED CLAIMS

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

1. A method of an operator operating a public access data hosting service having at least one database, comprising: the operator storing data from a plurality of data providers in the database as collections of parameter'vaiue pairs, wherein the data providers are distinct from the operator; the operator storing a functionality provided by each of the plurality of data providers for use by a data searcher; the operator providing an interface through which the data searcher selects a set of parameter- value pairs that includes at least a portion of the data; and the operator displaying a table having a plurality of cells, at least some of the cells being used to display a plurality of values from the selected set of parameter- value pairs, and at least another one of the cells being used to provide the data searcher with access to at least one of the functionalities.

3. The method of claim 1 wherein fhe functionality comprises a product ordering interface.

4. The method of claim 1 wherein at least one of the functionalities transmits information regarding the data searcher to a sales representative.

5. The method of claim 1 wherein at least one of the functionalities comprises an interface for live communication between the data searcher and a sales representative.

6. The method of claim 1 wherein at least one of the functionalities comprises an interface that assists the data searcher in producing a custom product for the data searcher.

7. , The method of claim 5 wherein the custom product comprises a physical product.

9. The method of claim 1 wherein at least one of the functionalities provides statistics related to at least some of the values displayed in the table.

10. The method of claim 1 wherein at least one of the functionalities provides an agent that searches for information not displayed in the table.

11. The method of claim 1 wherein at least one of the functionalities is executed at least in part on a computer local to the data searcher.

12. The method of claim 1 wherein at least one of the functionalities is executed at least in part on a computer local to the at least one of the plurality of data providers that loaded the functionality.

13. The method of claim I further comprising storing the operator executing the functionalities for the at least one of the plurality of data providers.

14. The method of claim 1 further comprising displaying an icon outside of the table on a display used by the data searcher for future use in accessing at least one of the functionalities.

15. The method of claim 1 wherein at least one of the functionalities comprises an interface that assists the data searcher in procuring a software update.

16. The method of claim 1 further comprising tagging at least one of the functionalities in a publicly accessible document.