WO2000042547A2

WO2000042547A2 - Intelligent multi-media market

Info

Publication number: WO2000042547A2
Application number: PCT/US2000/001210
Authority: WO
Inventors: Eric W. W. Johnson; Raghav P. Kher
Original assignee: Imandi Corporation
Priority date: 1999-01-15
Filing date: 2000-01-18
Publication date: 2000-07-20
Also published as: WO2000042547A8; AU2730200A; HK1025468A2

Abstract

A method and system for providing lists of merchants that provide particular products and services to customers and for receiving and distributing submissions of requests for quotes from customers to merchants. The system comprises various communications media, centralized servers, and a centralized database that contains merchant and customer information. Customers access the merchant information via a basic transaction and transaction protocol in order to receive a list of merchants that offer any particular product or service. The customer then submits requests for quotes to each of the merchants from the list of merchants through the intelligent multi-media market and receives quotes back either directly from the merchants or through the intelligent multi-media market. The intelligent multi-media market identifies merchants through automated processes. The merchants are not provided exclusivity agreements to participate in the intelligent multi-media market, and may opt out of participation in the intelligent multi-media market at any time.

Description

Intelligent Multi-Media Market

Technical Field

The present invention relates to technology-based retail and wholesale markets, and, in particular, to a method and system for compiling lists of merchants for customers and for presenting requests for quotes from customers to merchants.

Background of the Invention

The retailing of goods and services by merchants to well-informed consumers, and the wholesaling of goods and services by wholesalers to merchants, by means of an efficient marketplace is a fundamental basis for a free market economy. The need for better mechanisms for informing potential retail and wholesale customers of services and goods available for sale by merchants and the need for increasing the efficiency, and decreasing the costs, of individual transactions have historically provided some of the strongest motivations for technological development. Methods for informing customers of available goods and services span an enormous range of technologies, from the cries of street vendors in crowded urban centers to graphical interactive web advertisements. Similarly, the efficiency of individual transactions currently spans simple barter exchange in urban markets to highly-automated electronic funds transfers. Although great technological and economic strides have been made towards increasing the flow of information to consumers and towards increasing the efficiency by which consumers obtain goods and services, there is still much room for improvement.

Tables 1 and 2, below, summarize various characteristics of different types of technology -enabled markets from the perspective of customers. The types of technology-enabled markets for which characteristics are listed in Tables 1 and 2 include: (1) in-person shopping; (2) shopping by mail; (3) shopping by telephone; (4) shopping through a buying service; (5) direct internet shopping; (6) shopping via an internet virtual store; (7) employing an internet-based shopping agent; (8) shopping via an internet-based vertical quote aggregator; and (9) shopping via an internet-based horizontal quote aggregator. These types of technology-based markets appear, in both Tables 1 and 2, in the first column entitled "Type of Shopping. " Within each row of Tables 1 and 2, each column, starting with the second column contains values for a particular characteristic applicable to the technology-enabled market listed in the first column. The final row in Tables 1 and 2 indicates the most desirable value for a particular characteristic

Table 1, below, includes various characteristics of technology -enabled markets that are currently adequately served by at least one type of technology-enabled market.

Table 1

The technology-enabled markets are listed in Tables 1 and 2 in the order in which the markets were developed, starting from the oldest markets. In general, values for the various characteristics of technology-enabled markets approach the most desirable values listed in the final row of Tables 1 and 2 as the tine since development of the technology-enabled markets decreases from the top of Tables 1 and 2 to the bottom of Tables 1 and 2. This is a rather natural result of technologies being driven by the need for improvement. For example, consider the first characteristic listed in Table 1, the timeliness with which a customer can search for merchants that provide a particular good or service. The timeliness of identifying merchants by in-person shopping is generally quite poor. In-person shopping requires the customer to be transported physically to a number of different retail establishments distributed over some geographical area in order to identify merchants offering a particular good or service. In a mail-based market, the timeliness of searching for merchants that offer a particular good or service is also relatively poor. Either the customer must passively wait to receive mail order catalogs or advertising fliers, or the customer must send out inquiries and wait for the responses to the inquiries in the return mail.

Probably the single greatest technological improvement, from the standpoint of customers, has been the development of the telephone. By using the telephone, a customer can far more quickly and immediately search a variety of retail establishments for provision of a particular good or service. A buying service, contacted by a customer via a telephone call, may further improve the timeliness of searching for merchants that provide a particular good or service. The buying service may develop pre-compiled and cross indexed lists of merchants and goods and services and thus take advantage of an extensive searching effort made in advance of a customer's need for identifying merchants that offer a particular good or service. Generally, a buying service employee interacts with a customer to obtain information about the good or service desired by a customer and various customer preferences, and then uses the pre-compiled list of merchants to directly contact merchants in order to identify one or more merchants that can offer the good or service to the customer at a favorable price and at favorable terms. The buying service may provide the customer with the list of the merchants, or may undertake management of the sale of the good or service to the customer.

Nowadays, a customer may connect to the Internet via an Internet browser and use Internet search tools to identify and browse web sites and homepages that offer goods and services by merchants. However, this direct Internet market may be only marginally more efficient than a telephone search, depending on the types of goods and services desired. For certain types of goods, an Internet virtual store may provide quite timely return of information with respect to a particular good or service. The Internet virtual store may offer a variety of different brands and service providers through a single set of interrelated web pages. The customer may instead employ an Internet-based shopping agent to search the internet for web sites that offer a particular good or service. Depending on the good or service sought by the customer, the automated searching via a shopping agent may provide a quite timely search.

More recently, a new type of market has developed on the Internet through which a customer may solicit quotes from merchants for provision of a particular good or service. This new type of market is referred to as an "aggregator. " There are vertical quote aggregators that offer quote request submission to merchants for a particular type of good or service and horizontal quote aggregators that attempt to offer submission of requests for quotes from customers to merchants for a broad range of goods and service categories. For both vertical and horizontal quote aggregators, the timeliness of the search is limited by the time required for particular merchants to respond to quotes. However, because the merchants have been identified by advance searching, the timeliness of a customer search for a particular good or service may be substantially better than searches conducted by a customer via more direct markets, such as the telephone market or direct Internet market.

The characteristics of the various technology-enabled markets listed in Table 1 include: (1) the timeliness of searching for a particular good or service; (2) the cost of searching for a particular good or service; (3) the costs of making an inquiry concerning price, availability, or other purchase parameters; (4) the timeliness of making an inquiry about purchase parameters; and (5) the flexibility of purchase parameter inquiries. In general, the cost of searching for merchants that provide a particular good or service is quite high for in-person shopping, proportional to the breadth of the search for mail and telephone markets, and relatively low for the more advanced market-enabled technologies, including Internet markets. This same trend is seen for the cost of purchase parameter inquiries, the timeliness of purchase parameter inquiries, and the flexibility with which a customer may make purchase parameter inquiries. The flexibility of a purchase parameter inquiry includes the ability to make an inquiry at various times of day, on weekends, and on holidays, and the ability to easily submit inquiries for varying numbers of purchase parameters. Table 2 includes additional characteristics of technology-enabled markets for which current technology -enabled markets do not offer optimal values. Again, as in Table 1 , the desired values for the characteristics included in Table 2 are shown in the first row, beneath the column headings of Table 2. The characteristics displayed in Table 2 include: (1) the geographical breadth of a search for provision of a good or service possible using a particular technology-enabled market; (2) the thoroughness of searching obtainable by a customer via a particular technology- enabled market; (3) the ease by which a customer can compare prices and other purchase parameters offered by various competing merchants; and (4) the degree to which a particular technology-enabled market provides a customer with advanced information and tools, such as verification of a merchant's business practices and tracking of inquiries and requests for quotes submitted to merchants.

Table 2

As can be seen from Table 2, above, none of the currently-available technology- enabled markets provide optimal values for the characteristics listed in Table 2. In all cases, the geographical breadth of a customer's search is either extremely low, in the case of in-person shopping, or limited by one or more resources. Mail and telephone shopping limit the geographical breadth of the search because of limitations in availability of non-local telephone number listings and mail addresses as well as by cost. The further a given merchant is located from a customer, the more expensive, in general, the information exchange between the customer and the merchant via mail or telephone. Various internet-based markets are also limited geographically, either by the availability of the Internet to merchants in different areas and of different technological capabilities, as well as by language barriers and by biased searching methodologies. In general, none of the currently-available technology-enabled markets provide the customer with the ability to easily conduct thorough searches, and none provide the customer with an easy way to compare prices, although the internet- based quote aggregators do provide for price comparison between those merchants to which the quote aggregators submit quote requests. Unfortunately, the quote aggregators generally operate through exclusivity agreements with particular merchants, or require merchants to subscribe to the quote aggregator for a fee, thus providing the customer with a relatively small and biased pool of merchants to which requests for quotes can be submitted. Finally, none of the currently-available technology-enabled markets provide easily accessible and high quality information tools, such as tools for verifying a merchant's business practices or for tracking quote requests after they have been submitted to particular merchants.

Tables 3 and 4 are laid out similarly to Tables 1 and 2, respectively, with the exception that the characteristics included in Tables 3 and 4 relate to a merchant's perspective of a particular technology-enabled market. Table 3 shows characteristics for which at least one currently-available technology-enabled market provides a desirable value. As in Tables 1 and 2, the desired values for the characteristics in Tables 3 and 4 appear in the final row.

Table 3

Table 4 shows characteristics for which no currently-available technology-enabled market provides a desirable value.

Table 4

Thus, although currently-available technology -enabled markets adequately serve some customer and merchant needs, other merchant and customer needs have yet to be adequately addressed. In particular, currently-available technology-enabled markets provide customers with less than adequate geographical breadth and thoroughness of searching for merchants that provide a particular good or service, provide less than adequate facilities for comparing prices offered by merchants for particular goods and services, and provide virtually no advanced information tools to allow a customer to verify a merchant's business practices, peruse customer feedback directed to a merchant, or track inquiries submitted by the customer to various merchants. Similarly, currently-available technology-enabled markets do not adequately address the need of merchants for efficiently and broadly advertising goods and services, for offering comparative prices, for tools that facilitate processing of requests for quotes and other inquiries from customers, and for tools that facilitate obtaining feedback from customers. Naturally, many of these inadequately served needs can be addressed through ad hoc mechanisms, cost and labor intensive services, and other techniques, but it is most desirable for a technology-enabled market to provide adequate solutions for these unsatisfied customer and merchant needs, as well as to provide the technological advances provided by currently-available technology -enabled markets.

Summary of the Invention

The present invention provides a method and system for facilitating the informed selection of merchants by a customer for the provision of particular goods and services to the customer and for facilitating an exchange of information between the customer and selected merchants regarding a planned purchase of a good or service. In other words, the present invention provides a technology -enabled marketplace in which customers and merchants do business knowledgeably and efficiently.

The intelligent multi-media market ("IMMM") of the present invention interconnects customers and merchants via a number of communications technologies, including the telephone, mail, fax transmission, email, and the Internet. This multi- media aspect of the IMMM provides for the greatest possible accessibility and reachability for both customers and merchants. Customers and merchants are interconnected through server-based automated processes, centralized databases, and a number of transaction protocols. Processes within the IMMM, including software routines running on server-computers and procedures carried out through the occasional intervention by human technicians, construct and maintain an extensive database of customer and merchant information. Merchants are identified and included in the database via automated search engines, automated analysis, and technical analysis conducted by human technicians. Customers access the IMMM through one of the number of communications technologies in order to search for merchants offering a particular desired good or service. The customers can then submit requests for price quotes via the IMMM to the merchants identified in a search and subsequently receive quotes either from the IMMM or directly from merchants to which quote requests have been submitted. The IMMM furnishes requests for quotes to identified merchants by one of the number of communications technologies. Merchants can either accept the requests and respond to them, or opt out of the IMMM. The IMMM provides tools that allow customers to track submitted requests for quotes and that allow merchants to process requests for quotes. In addition, the IMMM provides tools for conducting surveys of customers who have submitted requests for quotes with regard to the quality of service received from particular merchants. The IMMM provides customers with all the technological advantages of currently-available technology-enabled markets and, in addition, provides customers with a greater geographical breadth and thoroughness in searching for merchants, a greater ease of comparing prices offered by merchants, a greater ease in submitting requests for quotes, and tools for verifying a merchant's business practices and for tracking submitted requests for quotes. The IMMM provides merchants with all the technological advantages provided by currently-available technology-enabled markets and, in addition, provides merchants with greater geographical reachability for offering comparative prices in the marketplace, tools for processing requests for quotes, and automated feedback from customers. Brief Description of the Drawings

Figure 1 illustrates the connectivity between the main components of the Intelligent Multi-Media Market.

Figure 2 illustrates a representative transaction between a customer and the Intelligent Multi-Media Market.

Figure 3 illustrates the basic transaction between the Intelligent Multi- Media Market and a merchant.

Figure 4 illustrates the conceptual content of a merchant record within the Intelligent Multi-Media Market database.

Figure 5 illustrates the requests for quotes tracking facilities provided by the Intelligent Multi-Media Market to both customers and merchants.

Figure 6 represents a view of the contents of an example Intelligent Multi-Media Market database pertaining to merchants who retail new sport utility vehicles.

Figure 7 represents the results of a first step in compiling a list of merchants to present to a customer.

Figure 8 represents a map of the area in which an example customer lives and illustrates geographical filtering of an intermediate list of merchants.

Figure 9 illustrates the process by which a customer submits a request for a price quote.

Figure 10 is a flow-control diagram of the routine "connect to IMMM and login."

Figure 11 is a flow-control diagram of the routine "select category."

Figure 12 is a flow-control diagram of the routine "input requirements."

Figure 13 is a flow-control diagram of the routine "receive merchant list."

Figure 14 is flow-control diagram that outlines Intelligent Multi-Media Market processing.

Figure 15 is a flow-control diagram of the routine "process customer login."

Figure 16 is a flow-control diagram of the routine "get category."

Figure 17 is a flow-control diagram of the routine "get input requirements." Figure 18 is a flow-control diagram for the routine "prepare merchant list." Figure 19 is a flow-control diagram for the routine "quote request submission." Figure 20 is a flow-control diagram for the routine "send out requests for quotes."

Figure 21 is a flow-control diagram showing the merchant processing phase of the basic Intelligent Multi-Media Market transaction.

Detailed Description of the Invention

The present invention provides a new technology-enabled market, the intelligent multi-media market ("IMMM"). The IMMM thoroughly searches for and identifies merchants that provide a particular good or service desired by a customer. The search can be tailored to produce a list of merchants that satisfy various constraints and customer preferences. The IMMM provides the list of identified merchants to the customer, and the customer can then submit a request for a price quote to one or more of the identified merchants through the IMMM. The IMMM then forwards the request for a price quote to those merchants identified by the customer as being merchants from whom the customer desires further information.

The IMMM, on a continuous basis, compiles and maintains a detailed, cross-indexed database of merchants and categories of products and services. Merchants are automatically included in this database, but, upon receiving one or more requests for quotes from the IMMM, may elect to opt out either temporarily or permanently from the IMMM. The IMMM does not provide for exclusive agreements between the IMMM and merchants with regard either to inclusion of the merchants in the IMMM or with regard to submission of requests for quotes.

The IMMM provides both customers and merchants with facilities for tracking submitted requests for quotes. Customers can follow a request for quotes through the IMMM and through processing of the request for quotes conducted by a merchant. The IMMM provides tools to facilitate processing of requests for quotes by merchants. The IMMM also provides for periodic and automatic surveys of customers with regard to their satisfaction with services provided by particular merchants. Feedback based on these survey results are made available both to other customers and to the merchants surveyed.

Customers and merchants can access the IMMM via telephone, mail, fax, email, the internet, and other advanced communications media. Thus, the intelligence aspect of the IMMM is provided by a centralized database, transaction protocols, and IMMM processes, both computational and human. The multi-media aspect of the IMMM relates to the rich variety of communications media through which the IMMM may be accessed both by customers and merchants.

The IMMM will be described below in four subsections. In the first subsection, an overview of the IMMM will be presented. In the second subsection, a database implementation is presented to facilitate discussion of the flow-control diagram illustration of IMMM transactions that follows in the third subsection. The fourth subsection will summarize the description of the IMMM and point out alternative embodiments and approaches.

It should be noted, at the onset, that there are many different possible approaches through which the IMMM may be implemented. The database schema is provided in subsection 2 for illustrative purposes. Detailed implementations tailored to particular aspects of the IMMM are presented in additional, separately filed patent applications. The centralized database component of the IMMM can be implemented using any of the common types of database management systems, including network, hierarchical, relational, object-oriented, or hybrid database management systems. Alternatively, an ad hoc database system may be implemented to serve as the database component of the IMMM. Many different computer languages can be employed in order to implement IMMM processes, and there are almost a limitless number of possible software implementations of the software components of the IMMM.

Overview

Figure 1 illustrates the connectivity between the main components of the IMMM. In Figure 1, a number of customers 102-106 are interconnected to a number of merchants 108-113. Customers and merchants may possess connections to different communications media for access to the IMMM. For example, customer 102 is shown in Figure 1 as supporting fax exchanges 116, mail exchanges 118, internet access through a home PC 120, and telephone access 122. By contrast, customer 105 can access the IMMM only via mail 124 or telephone 126. The IMMM is shown in Figure 1 as comprising a number of communications links 128, redundant fault-tolerant server computers 130 and 132, and a database 134. In a preferred embodiment, the database is mirrored on separate physical media to prevent single points of failure. Data flows from customers 102-106 to the communications link 128, from the communications link to processors running on the server computers 130 and 132, and from the server computers 130 and 132 to the database 134. Data flows from the database 134 back to the customers 102-106 via server computers 130 and 132 and communications link 128. Data flows from the database 134 through server computers 130 and 132 and communications link 128 to merchants 108-113 and, by opposite paths, from the merchants to the database 134. Thus, the IMMM can be thought of as a logical crossbar interconnecting customers and merchants, with the logical crossbar selecting groups of merchants to which requests for quotes are broadcast from a customer depending on various customer preferences and criteria.

Figure 2 illustrates a representative transaction between a customer and the IMMM. Figure 2 is divided into two columns: (1) a column representing the customer 202; and (2) a column 204 representing the IMMM. Arrows, such as arrow 206, represent transfer of information from the customer to the IMMM, and arrows, such as arrow 208, represent transfer of information from the IMMM to the customer. Messages 210-217 represents information provided to the IMMM by the customer and information received by the customer from the IMMM. The messages are shown in Figure 2 as graphical, menu-like displays. When the customer is connected to the IMMM via the Internet, graphical messages are easily received and transmitted by the customer. On the other hand, when the customer is connected to the IMMM via only a telephone connection, information may be provided to the customer from the IMMM via audio menus and information provided by the customer to the IMMM via keypad-activated tones. The messages 210-217 in Figure 2 thus represent display and input of information appropriate to the type of communications medium through which the customer is interconnected with the IMMM. These above- described conventions apply to Figure 3 as well, and in the interest of brevity will not be repeated below.

After connecting and logging onto the internet, the customer is presented with a list of categories of products and services from which to select a particular category of product or service for which the customer wishes to submit a request for a price quote to one or more merchants. Message 210 displays a portion of a hierarchical list of categories of goods. In this case, and in the case of all other steps in Figures 2 and 3, presentation of information may require a single display, such as an internet-based graphical display, or may require a number of different steps, like, for example, selection of more and more specific categories presented through audio selection lists over a telephone. The initial information transfer from the customer to the IMMM and vice versa is not shown in Figure 2. The Customer then selects the product category, in the case of Figure 2, a Brute sport utility vehicle, and transmits that selection to the IMMM. The IMMM then solicits additional information from the customer, in message 211, including selection of various options and preferences. Again, the options and preferences may be solicited in a large number of steps, depending on the number of options and preferences related to the selected category and depending on the communications medium through which the customer accesses the IMMM. Next, customer X selects options and preferences, in the case of Figure 2, a V8 engine, and returns the selections 212 to the IMMM. Based on the category, options, and preferences selected by the customer, the IMMM prepares an initial list of merchants offering the selected product or services and meeting the criteria represented by the options and preferences selections 213 made by the customer and the IMMM then presents the initial list of merchants to the customer. The customer may then select a subset of the identified merchants, represented in Figure 2 by the selection of "Smallville Motors" and "SUV Mart" 214, and may then return the edited list of merchants to the IMMM.

Finally, the IMMM submits to the selected merchants requests for price quotes that include certain of the options and preferences selected by the customer for the indicated category of product or services. Sometime later, the customer receives completed price quotes back from the merchants, represented in Figure 2 by messages 215 and 216. The merchants can send the quotes directly to the customer via a communications medium preferred by the customer, or, alternatively, can return the quotes to the IMMM for forwarding to customers. The customer may then choose to accept one of the price quotes, represented in Figure 2 by message 217, and direct the acceptance to a merchant either directly, or via the IMMM. Figure 2 thus represents the basic market transaction supported by the IMMM. The IMMM also supports additional types of customer transactions, not shown in Figure 2. including transactions that allow a customer to modify the customer's user profile.

Figure 3 illustrates the basic transaction between the IMMM and a merchant. First, the merchant receives one or more requests for price quotes from the IMMM, represented in Figure 3 by messages 302 and 304. If the merchant has not previously received requests for quotes from the IMMM, the IMMM refers the request for quotes to the merchant via a communications medium identified by the IMMM from any of a number of sources of information, including the telephone yellow pages, advertising, internet websites, catalogs, and other types of information. The contact information for the various identified communications media through which a merchant can receive requests for quotes are stored in the IMMM database (134 in Figure 1). After receiving the requests for quotes, the merchant has a number of options. The merchant can opt out of the IMMM, either temporarily or permanently, as represented in Figure 3 by message 306. The requests for quotes contain sufficient information to allow the merchant to reply to the IMMM, such as internet hyperlinks, return email addresses, phone numbers, etc. Alternatively, the merchant can send price quotes back to either the IMMM or directly to customers via contact information contained in the request for quotes 302 and 304. Quotes are represented in Figure 3 by messages 308 and 310. A merchant may conduct a variety of other transactions with the IMMM, including furnishing additional merchant information. These additional transactions are not shown in Figure 3.

Figure 4 illustrates the conceptual content of a merchant record within the IMMM database (134 in Figure 1). It should be noted that the contents of a merchant record may be distributed throughout a number of different database records, entries, or objects. The logical merchant record, shown in Figure 4, illustrates the type of information that can be extracted from the database with regard to a particular merchant. The merchant record 402 may contain the name of the merchant 404 and a unique ID 406 that numerically represents and identifies the merchant. The logical merchant record may contain one or more physical addresses representing the merchant's retail locations 408 along with contact information for the various retail locations 410. In addition, the logical merchant record may contain an ordered list of preferred communications media and media addresses for receiving requests for quotes 412. The logical merchant record may contain extensive lists of product and service categories offered for sale by the merchant 414. The logical merchant record may, in addition, contain results of surveys conducted by the IMMM to evaluate the merchant's performance 416. Many other additional types of information may be contained within the logical merchant record 418-420. The merchant record thus provides the basis for constructing lists of merchants to furnish to IMMM customers in response to selection by customers of categories of products and services, preferences, and options. The IMMM database (134 in Figure 1) also includes logical category records, logical customer records, and logical requests for quote records. Again, as with the merchant records, these logical records may be distributed over a number of different database tables, records, entries, or objects.

The IMMM, in addition to the basic request for quotes submission and quote furnishing transactions illustrated in Figures 2 and 3, provides a number of advanced information tools to both customers and merchants. Figure 5 conceptually illustrates the requests for quotes tracking facilities provided by the IMMM to both customers and merchants. This facility provides views of outstanding requests for quotes to merchants and to customers. In Figure 5, these views are displayed as graphical displays 502 and 504 obtained from the IMMM via the Internet on a merchant computer 506 and a customer computer 508, respectively. The requests for quotes, represented in Figure 5 by small squares, such as square 510, can be thought of as inhabiting a three-dimensional Cartesian volume within the IMMM database. A view of a portion of that Cartesian volume appears within the three-dimensional coordinate system comprising the following three orthogonal axes in Figure 5: (1) the customer axis 512; (2) the merchant axis 514; and (3) the requests for quotes axis 516. Thus, the columns of stacked requests for quotes 518-520 each represents the total outstanding requests for quotes from one customer to one particular merchant. Because only a small window into the Cartesian volume of requests for quotes is shown in Figure 5, the first column 518 is arbitrarily assigned to customer m, the second column 519 is assigned to customer m+1, and the third column is assigned to customer m+2. Similarly, each of the three rows of stacked requests for quotes 522- 524 represents all the outstanding requests for quotes submitted to a particular merchant. The first row 522 is arbitrarily assigned to merchant n, the second row 523 is therefore assigned to merchant n+1, and the third row 524 is assigned to merchant n+2. The assignments of customers and merchants presumes a right-handed Cartesian coordinate system with indices increasing to the right and downward along the customer axis 512 and the merchant axis 514, respectively. The final axis 516 represents an ordered sequence of requests for quotes submitted by a particular customer to a particular merchant. Thus, for example, the requests for quotes 526- 529 were submitted to merchant n by customer m.

The Cartesian volume representation of the outstanding requests for quotes is simply one logical way to view all the outstanding requests for quotes contained within the IMMM database (134 in Figure 1). This conceptual view of the outstanding requests for quotes facilitates an understanding of the requests for quotes that are accessible to the merchant and to the customer. For example, merchant n+2 can view all the outstanding requests for quotes located in row 524. The IMMM viewing tool will provide navigational buttons or other types of navigation devices to allow merchant n+2 to traverse row 524 to select successive stacks of requests for quotes representing the requests for quotes submitted to merchant n+2 by particular customers. These navigational devices then allow merchant n+2 to select any one of the outstanding requests for quotes on the merchant's PC 506. In similar fashion, customer m+2 may display any of the outstanding requests for quotes within column 520 that represent all the requests for quotes submitted by customer m+2 to any of the merchants. It should be noted that additional types of views of the requests for quotes are also available to customers and merchants. For example, multiple requests for quotes for a particular good or service from a customer to multiple merchants may be submitted in one operation by the customer, and may be aggregated together within a multiple-merchant record for display to a customer.

Although a three-dimensional volume is shown in Figure 5, the outstanding requests for quotes can logically be considered to reside in a more complex hyper-volume with additional dimensions representing the path, or trajectory, of a given request for quotes through the IMMM and through processing following submission to a merchant. Also, various IMMM tools can extract summary information from all of the outstanding requests for quotes accessible by a merchant or customer, and the IMMM can search through the accessible outstanding requests for quotes in order to final and present subsets of the accessible outstanding requests for quotes based on various criteria. Thus, the centralized IMMM database (134 in Figure 1) provides information storage that enables the IMMM to provide sophisticated requests for quotes tracking tools to both merchants and customers.

Figures 6-8 illustrate the process by which the IMMM selects a list of merchants to present to a customer for submissions of requests for quotes for a particular good or service. Figure 6 represents a view of the contents of the IMMM database pertaining to merchants retailing new sport utility vehicles. In a relational database implementation of the IMMM database, this table might represent a view or temporary table constructed from the contents of the many different database tables that together comprise collections of logical merchant records, such as the logical merchant records shown in Figure 4. Generally, an implementation will contain many additional columns and rows representing different characteristics of the merchants and a great deal more merchants, respectively.

Figure 7 represents the results of a first step in compiling a list of merchants to present to the customer. Continuing with the example of Figure 2, the customer is seeking quotes on new Brute sport utility vehicles. Thus, the IMMM has filtered the information illustrated in Figure 6 into a smaller list, shown in Figure 7, that includes only those merchants that retail new Brute sport utility vehicles. Generally, for each category of product or service, the IMMM will determine the maximum number of merchants to present to the customer and will continue to filter the initial list with regard to customer preferences and selected options until a list smaller than the maximum list size has been determined. The final criteria employed by the IMMM, for retail sales of products such as automobiles, is to filter the list of merchants with regard to geographical proximity of the merchants to the customer. One approach to filtering the intermediate lists of merchants by geographical proximity is illustrated in Figure 8. Figure 8 represents a map of the area in which the customer lives. The IMMM filters the intermediate list by logically considering merchants within circles of increasing radius until an adequate number of merchants can be filtered from the intermediate list of merchants. For example, in Figure 8. the IMMM starts with a circle of radius 1 mile 802 centered about the location of the customer's residence 804. By applying a distance function to the addresses of the customer and each merchant in the intermediate list of merchants, respectively, the IMMM can determine that only one merchant, "Smallville Motors" 806, is located within one mile of the customer's residence. The IMMM then increases the radius of the circle to two miles 808 which further includes "Trust Me Auto" 810. If, in this example, the IMMM is seeking at least three merchants to which the customer can submit quotes, the IMMM further increases the radius of the circle to three miles 812 and discovers, through application of the distance function, that a third merchant "SUV Mart" 814 can now be included in the list. Thus, following geographical filtering, the IMMM has selected a list of three merchants that offer the particular sport utility vehicle desired by the customer, that meet the preferences and options selected by the customer, and that are geographically located closest to the customer.

For goods and services more easily offered from a distance, the IMMM may choose different radii for geographical filtering, or may not employ geographical filtering. The IMMM may employ vastly different preferences and options for different categories of products and services. Thus, the IMMM employs the information contained in the IMMM database to best advantage to select lists of merchants for each different category of products and services to present to individual customers. Example Database Schema

In this subsection, a generalized implementation of the IMMM database is presented. This generalized database schema provides a basis for implementing the IMMM transactions outlined in the previous subsection as well as a basis for IMMM automated survey techniques. In addition, the database schema presented in this subsection is sufficiently extensible to allow for the ongoing database construction and maintenance by which the IMMM continuously enhances the search capabilities that the IMMM offers to customers.

The database schema presented in this subsection is based on the relational database model. Seventeen relational database tables are described, below, in table form as well as in SQL-like table creation commands. Each table contains a few sample rows in order to illustrate the nature of the data contained in the tables as well as the interdependencies between tables. A live, functioning database contains far more information, with some tables containing hundreds of thousands to millions of rows. The generalized database schema presented in this subsection will facilitate discussion of flow-control illustrations of the IMMM transaction model and protocol presented in the following subsection.

Tables 5-8 store basic merchant information. Tables 5-8 are presented below:

Table 5 merchants

CREATE TABLE merchants ( field_name VARCHAR(128), num INTEGER, type INTEGER )

Table 6 merchant varchars

CREATE TABLE merchant varchars

( m id INTEGER, num INTEGER, value VARCHAR(128)) Table 7 merchant ints

CREATE TABLE merchant ints ( m id INTEGER, num INTEGER, value INTEGER)

Table 8 merchant contact

CREATE TABLE merchant contact ( m_id INTEGER, c id INTEGER, primry INTEGER, secondary INTEGER)

Table 5 describes the different types of basic merchant information contained in Tables 6 and 7. Table 5 contains the following three columns: (1) fιeld_name, a text description of a type of information, or information field, contained in either Table 6 or Table 7; (2) num, an integer identifier for a particular type of information, or field; and (3) type, an integer indicating the data type of the data field. In the generalized database schema presented in this subsection, two data types are used, integer data having a type of "1 ," and variable length character data, or strings, having a type designation of "2. " Table 6 contains all the fields having fields of type 2, or. in other words, fields having a type of variable length character string. Table 7 contains those fields having type 1, or, in other words, having a data type of integer. Note that, in this example, we assume that the SQL-like data type INTEER is large enough (by bits) to hold phone numbers. For SQL-like implementations having 32-bit integers, a different SQL-like data type can be used for phone numbers, such as the data type "NUMERIC(16,0)." More elaborate, and more capable database implementations may contain additional data types for merchant information fields, and additional tables to contain values of those additional data types. For example, when the IMMM provides facilities for automated electronics funds transfer, a special field type for security -protected, verifiable, and easily invoked account numbers may be employed. As another example, date or time of day data types may find common usage in descriptive fields related to merchants.

Tables 6 and 7 contain the basic merchant information. When a new merchant is identified by the IMMM, the new merchant is assigned a unique merchant ID. As with all other ID's used in this generalized database schema, the IMMM must have a method for allocating unique ID's in a reusable fashion, or, at least, must use large enough integers to represent ID's so that monotonically increasing ID values can be used without danger of rollover. Once a unique merchant ID has been assigned to the new merchant, values for the fields described in Table 5 are entered for that merchant into Tables 6 and 7. When information for certain of the fields cannot be gleaned from the sources used by the IMMM to identify new merchants, the value NULL may be used to indicate lack of information. Alternatively, the row describingthat field can simply be left out of Table 6 or Table 7. Both Tables 6 and 7 have the following three columns: (1) m_id, the unique merchant ID identifying a particular merchant; (2) num, the identifier of the particular field as shown in the second column of Table 5, discussed above; and (3) value, the value of the field identified by the field identifier in the preceding column. In the case of Table 6, the value is a variable length string value, and in the case of Table 7, the value is an integer.

If the contents of Table 5 are thought of as defining a simple merchant record, analogous to the logical merchant record described in Figure 4, above, then an instantiation of a particular merchant record can be constructed from the values contained in Tables 6 and 7. For example, referring to the sample data contained in Tables 5-7, above, the following logical merchant record is easily constructed: merchant id: 369 name: Bob's Used Cars street address: 361 Main Street, Belville, MN, 50120 host address: P.O. Box 897, Glensville, MN 50122 email address: Bob 's@bob.com fax number: (825) 113-1962 phone number: (825) 114-1401

Table 8 contains a preferred contact method for submitting requests for quotes to merchants. This table contains the following four columns: (1) m_id, the merchant identifier identifying a particular merchant; (2) c_id, a unique identifier of a category of product or services, to be discussed below, provided by the merchant identified by the merchant ID in the first column; (3) primry, an integer identifier of a contact method or communications media preferred by the merchant for submission of a requests for quotes of a category identified by the identifier in the preceding column; and (4) secondary, a second preferred communications media for receiving submissions of requests for quotes. The integer values indicate different types of contact methods. For example, the value "1 " may indicate mail, the value "2" may indicate telephone, and the value "3" may indicate Internet-based submissions via IMMM web-based facilities provided to customers. Various other types of communications media through which merchants may receive quotes from the IMMM will be designated with additional integer values.

Tables 9-12, shown below, store basic information related to customers. These tables are analogous to Tables 5-8. described above. The logical customer record is defined by the contents of Table 9. and values for fields of logical customer records are stored in Tables 10 and 11. Preferred methods for customer reception of completed price quotes from merchants are stored in Table 12, analogously to storage of merchant contact information in Table 8.

Table 9 customers

CREATE TABLE customers ( field name VARCHAR(128), num INTEGER, type INTEGER)

Table 10 customer varchers

CREATE TABLE customer varchars

( cst id INTEGER, num INTEGER, value VARCHAR(128)) Table 11 customer ints

CREATE TABLE customer ints ( cst id INTEGER, num INTEGER, value INTEGER)

Table 12 customer contact

CREATE TABLE customer contact

( cst_id INTEGER, c id INTEGER, primry INTEGER, secondary INTEGER)

Table 13, shown below, contains a hierarchically-organized list of product and service categories. Table 13 contains the following columns: (1) pc_id. an integer identifier that identifies the parent category of a particular categor}'. where top- level categories having no parents have a value of zero in the pc id field; (2) category, a variable length character string that describes the product or service; and (3) c_id. an integer that uniquely identified the product or service represented by the category.

Table 13 categories

CREATE TABLE categories ( pc id INTEGER, category VARCHAR(128), c_id INTEGER)

Referring to the sample data stored in Table 13, there are two top-level product categories: "automobiles," having c_id = 2, and "stereos", having c_id = 67. The category "automobiles" has subcategories "new" and "used, " and the category "stereos" has subcategories "amplifiers" and "tuners." The "amplifiers" subcategory itself has two subcategories, "new" and "used, " and the subcategory "tuners" has subcategory "new. " In a live IMMM database, there are likely to be thousands or hundreds of thousands of categories and subcategories. In addition, rather than a single hierarchical ordering, other types of organizations of categories and products may be employed.

Table 14, shown below, contains information related to specific categories for each merchant that offers a product or service of that category. This information can be extracted by the IMMM and used during the searching and filtering operations that the IMMM employs to provide a list of merchants to customers seeking a particular good or service. Table 14 contains the following columns: (1) m id, a unique identifier of a particular merchant; (2) c_id, a unique identifier of a particular category of a product or service; (3) name, a variable length character string text description of the piece of information; (4) num, an indication of the order in which the information might be displayed in a graphical display of information related to the particular merchant and category; and (5) value, a variable length character string representing a value associated with a particular merchant and category.

Table 14 merchant_category_info

CREATE TABLE merchant category info

( m id INTEGER, c id INTEGER, name VARCHAR(128), num INTEGER, value VARCHAR(128))

In the example data shown above in Table 14, various brand names associated with new and used automobiles, identified by category identifiers "4" and "82," respectively can be seen in to be associated with "Bob's Used Cars. " Thus, it can be seen from the contents displayed for Table 14 that Bob's Used Cars offers new Fordge, Cheville and Beaver automobiles and used Beaver and Fordge automobiles. In a live, functioning IMMM database, Table 14 might include hundreds of thousands or millions of individual pieces of information related to particular merchants and categories. In addition, Table 14 may be combined with auxiliary tables in order to support different types of values, such as integer values, real number values, dates, times, graphical objects, and other such types of values that might be used for displaying information about a merchant's offerings. Tables 15-17, shown below, together contain information related to particular preferences stored for particular clients related to particular categories. The methodology for storing these preferences is quite similar to the methodology for storing base information about merchants in Tables 5-7, and customers in Tables 9-11, above. The only substantive difference is that preferences are identified by a combination of two identifiers, or keys, namely a preference ID stored in column "p_id" and a category ID, stored in column "c_id" in Table 15. The preference ID uniquely identifies a particular preference associated with a particular category.

Table 15 preferences

CREATE TABLE preferences

(p_id INTEGER, c id INTEGER, name VARCHAR(128), num INTEGER, type INTEGER)

Table 16 preference_varchars

CREATE TABLE preference varchars (cst id INTEGER, p id INTEGER, value VARCHAR(128))

Table 17 preference_ints

CREATE TABLE preference ints (cst id INTEGER, p_id INTEGER, value INTEGER)

Because the methodology employed to store preferences is so similar to the above- described methodologies for storing base information about clients and merchants, the columns in Tables 15-17 will not be described in detail. Instead, the information storage strategy is easily seen in the example data shown above in Tables 15-17. For example, Table 15 contains two different types of preferences associated with the category "new automobiles. " These two preferences have preference identifiers of "997" and "998. " In a graphical display listing for soliciting preferences, the value stored in the column "number" indicates the order of listing or displaying the preferences. The text description of one preference is "brand" with a data type of variable length character string, and the text description of the second preference associated with new automobile is "transmission," also having a data type of variable length character string. Referring now to Table 16, one can see that the customer identified by the cst_id "2000" prefers the brand "Fordge" with respect to new automobiles. Similarly, the customer identified by the cst_id "2000" has a preference for automatic transmissions with regard to new automobiles. Referring back to Table 10, the customer with cst_id "2000" is named "John Everett."

Table 18 contains descriptions of forms related to specific categories of products and services for submission of requests for quotes. Multiple forms for any particular category can be accommodated by Table 18 since each form is uniquely identified by a form ID.

Table 18 forms descriptions

CREATE TABLE forms descriptions

(f id INTEGER, sc id INTEGER, query VARCHAR(128), num INTEGER, type INTEGER, field id INTEGER, table VARCHAR(128)) Table 18 contains the following columns: (1) f id, a unique identifier identifying a particular form; (2) c_id, a unique identifier identifying a particular category of product or service; (3) query, a variable length character string text description of a particular item of information; (4) num, an indication of the ordering of information requests within a particular form; (5) type, an indication of the data type of the expected response; (6) field_id, a unique identifier for a data-containing field in Tables 10, 11, 16, or 17; and (7) table, the name of one of Tables 10, 11, 16, or 17 that contains the data representing a response to the query represented by a row in Table 18. As with logical merchant records, and logical customer records, the IMMM can extract a logical form for a request for quotes form the information contained in Table 18. For example, the following logical form identified by the form identifier "831," related to a request for a price quote on a used automobile, can be extracted from the sample data included in Table 18 above: customer name: customer address: desired brand: desired maximum age: customer phone: Table 19, shown below, contains information regarding the forms used by merchants for different categories of products and services.

Table 19 merchant form list

CREATE TABLE merchant brm ist (m id INTEGER, f id INTEGER, c id INTEGER)

Table 19 contains the following columns: (1) m id, a unique identifier for a particular merchant; (2) f id, a unique identifier for a particular form; and (3) c_id, a unique identifier for a particular category of product or service. Thus, for example, the first row in Table 19, above, indicates that the merchant having merchant ID "369," i.e. "Bob's Used Cars," uses the form identified by form ID "831," described above in the description of Table 18, for receiving requests for quotes on used cars.

Table 20, shown below, represents a list of outstanding requests for quotes.

Table 20 requests for quote

CREATE TABLE requests for quote

(q_id INTEGER cst id INTEGER, f id INTEGER, m id INTEGER, time received DATETIME, last submitted DATETIME)

Table 20 has the following six columns: (1) q_id, a unique identifier identifying the request for quote; (2) cst id, a unique identifier identifying a particular customer; (3) f id, a unique identifer identifying a particular form; (4) m_id, a unique identifier identifying a particular merchant; (5) time_received, the date and time that the request for quotes was submitted to the IMMM by the customer identified by the customer ID in a previous column; and (6) last_submitted, the date and time that the request for quotes was last submitted to the merchant identified by the merchant ID in the previous column. Note that the values that represent responses to informational requests in a form are contained in Tables 10, 11, 16, and 17. Thus, the IMMM is able to use the information contained in each row of Table 20 to construct a logical request for quotes form and response to the queries within the form. For example, the first row in Table 20, shown above, indicates that a request for quote, identified by the request for quotes ID "97," was submitted by customer "John Everett" to "Bob's Used Cars" for a used automobile on December 13, 1998 at 11 :10PM. The IMMM has not yet submitted the request for quotes to the merchant, indicated by the value NULL in the last field of the row. The IMMM, using information contained in Tables 8, 10, 11, 16, and 17, can extract the following completed request for quotes form that corresponds to the entry in the first row of Table 20, above: customer name: John Everett customer address: 3612 Blackhawk Drive, Orlando, CA 94101 desired brand: Beaver desired maximum age: 6 customer phone: (510) 462-8887 Finally, Table 21, shown below, contains information collected by automated survey mechanisms within the IMMM.

Table 21 surveys

CREATE TABLE SURVEYS

(q_id INTEGER, quality CHAR, timeliness CHAR, value CHAR, service CHAR, comments TEXT)

Table 21 contains the following columns: (1) q_id, a unique identifier identifying a particular submitted request for quote; (2) quality, a value for the overall quality of the service obtained by the customer with relation to the submitted quote; (3) timeliness, a rating of the timeliness of fulfilling the request for quote; (4) value, the customer's estimation of the value provided by the merchant with respect to the particular request for quote; (5) service, the customer's estimation of the quality of service provided by the merchant; and (6) comments, a text field in which a customer's comments can be entered. Many additional types of comments representing different evaluation characteristics may be included in Table 21. Note that all the information about the customer, the merchant, and the nature of the submitted request for quotes can be obtained by using the q_id value in the first column of Table 21 to find an entry in Table 20, described above, from which an entire logical request for quotes can be extracted.

Again, a live and functioning IMMM database includes many additional columns, additional tables, or different tables and columns from those described above. Form information stored in the IMMM database reflects the different types of capabilities and services that the IMMM can provide to both customers and merchants. The database schema described in this subsection is adequate to support the basic IMMM transactions and protocols described in overview in the preceding subsection and described in detail in the following subsection.

Description of the Basic IMMM Transaction and Protocols In this subsection, flow-control diagrams are presented to describe, in detail, the basic IMMM transaction model and the IMMM processers which facilitate and support the transaction model. There are three main phases of the basic IMMM transaction. The first phase relates to a customer's request for quotes submission, described in Figures 9-14. The second phase is IMMM processing of a customer's request for quotes, described in Figures 15-20. The final phase relates to processing of requests for quotes by a merchant, described in Figure 21. These phases, particularly the first two phases, may be interwoven in time.

Figure 9 illustrates the process by which a customer submits a request for a price quote. In step 902, the customer connects to, and logs into, the IMMM by calling the "comment to IMMM and login routine," to be described below. In step 904, the customer selects a category of goods or services for which the customer desires to submit a request for quotes via a dialog with the IMMM, encapsulated in the "select category" routine to be described below. If the customer is successful in selecting a category, as detected in step 906, the customer proceeds to step 908 in which the routine "input requirements" is called to conduct a dialog with the IMMM in order to furnish additional information about the product or service desired by the customer, customer preferences, and various types of options available to the customer for the selected category. If requirements are successfully selected, as detected in step 910, the customer proceeds to step 912, where the customer selects a preferred contact method. Because the routine "input contact method" is straightforward, it will not be discussed below. In the routine "input contact method," the IMMM queries the customer for a primary and secondary contact method for receiving quotes for goods or services represented by the selected category, and places the information into the IMMM database. Using Table 12, described above, as an example, the IMMM may execute the following SQL-like command to determine whether the customer has previously entered contact information for the selected category:

SELECT primry, secondary FROM customer_contact

WHERE cst_id = 2000 AND cjd = 82 Note that the above example SQL-like command assumes the unique identifier identifying the customer to have a value "2000" and that the selected category has the category identifier "82." Using the example data from the preceding subsection, this would correspond to checking whether customer "John Everett" has previously identified a preferred contact method for receiving price quotes on used automobiles. In the case that no previous contact information was entered into Table 12, the IMMM can add that information to Table 12 using a SQL-like command such as the command that follows:

INSERT INTO customer_contact VALUES (2000, 82, 1, 2) If, on the other hand, Table 12 already contains contact information for a selected category of product or service, the IMMM can compare the information returned from the above SELECT statement to the information furnished by the customer in response to the solicitation of contact information from the customer by the IMMM to decide whether the information stored in the IMMM in step 912 database needs to be updated. If the information needs to be updated, the IMMM may update the stored information by the following SQL-like command:

UPDATE customer_contact SET primry = 1 , secondary = 2 WHERE cstjd = 2000 AND cjd = 82 These basic SQL-like commands can be used to extract information from the IMMM database, insert information into the IMMM database, and update information already stored in the IMMM database in all the transactions, transaction protocols, and routines to be discussed in this subsection. Thus, the detailed SQL-like commands will not be provided for the information obtaining and information storing stops in the transaction protocols, transaction models, and routines to be discussed below.

It should be noted that most of the steps in the flow-control diagrams described in this subsection will be represented as routine calls. This is because the details within the steps will vary depending on the type of communications medium to which the customer or merchant is connected to the IMMM. In the case of the connection through a web page, for example, an entire set of preferences, options, customer information, or other types of information can be obtained in a single step based on customer input to check boxes, active text fields, or other selection objects imbedded in a displayed web page. On the other hand, a series of tedious audio menu steps may be required to solicit and input the same information in the case that the customer or merchant is connected to the IMMM only by telephone.

Once the customer has input the contact information, the customer receives, in step 914, list of merchants identified by the IMMM by conducting searching and filtering operations on merchant data stored in the IMMM database in the routine "receive merchant list," discussed below. If the customer chooses to submit a request for quotes to merchants from the merchant list, as determined in step 916, the customer indicates to the IMMM the customer's desire to submit requests for quotes to merchants in the final list in step 918. If the customer desires to submit requests for quotes for additional categories, as detected in step 920, control flows back to step 904. Otherwise, the submission of a request for quotes transaction is completed. In the case that selection of a category or input of requirements fails, as detected in steps 906 and 910, respectively, the customer may elect to attempt to select a different category of product or service in step 922.

Figure 10 is a flow-control diagram of the routine "connect to IMMM and login." In step 1002, the customer connects to the IMMM through a selected communications medium. This may require the customer to dial a telephone number supported by the IMMM, send an email message to the IMMM at the IMMM's email address, or open an IMMM web page via an Internet browser. In the following discussions, it will be assumed that customers and merchants will be connected to the IMMM through a selected communications medium and that the various information solicitations and transfers in the steps of the flow-control diagrams will be appropriately tailored to the selected communications medium.

In step 1004. the customer receives a login prompt from the IMMM. In the login prompt, the IMMM needs to request a sufficient amount of information to retrieve the customer identifier corresponding to the customer from the IMMM database, and to identify and verify that the customer claiming the identified customer's identity is, in fact, that customer. If the customer is a new customer, as detected in step 1006, the new customer receives a new customer information solicitation prompt from the IMMM in step 1008 and responds to that prompt in step 1010. In the case of certain types of communications medium, steps 1008 and 1010 may be repeated a number of times in order to collect all of the required new customer information. The need for repeating steps 1008 and 1010 is detected, in step 1012. If the customer logging in is not a new customer, but if the IMMM detects that additional customer information is needed in step 1014, then the IMMM prompts the customer for the necessary additional information in step 1016, to which the customer responds in step 1018. As in the case of steps 1008 and 1010, depending on the type of communications medium through which the customer is connected to the IMMM, steps 1016 and 1018 may need to be repeated a number of times, as detected in step 1020. When the additional information is collected, if necessary, the routine connect to IMMM and login" is complete.

The need for additional customer information, as detected in step 1014, allows the IMMM to continuously update and elaborate information needed to respond to the various types of request for quotes forms used by merchants. Thus, if merchants require additional information and new forms, or new merchants are found by the IMMM with different requirements from previous merchants, the IMMM can make deferred additions the information collected from each customer by waiting to collect information until the customer again logs in to the IMMM. It is an important feature of the IMMM protocol that, whenever possible, the request for quotes forms are filled out automatically by the IMMM based on data already resident in the IMMM database. This vastly simplifies the customer's interaction with the IMMM in order to submit request for quotes. The same technique is applicable to basic customer information, customer preferences related to specific categories of products or services, and options related to specific categories of products and services. Thus, previous selections of options can be automatically placed into subsequent request for quotes forms, and the customer is given a chance to edit those forms in case the customer selections of options have changed over time. These strategies can differ from category to category and ma) be based on predictions from data related to the frequency of chosen options in successive requests for quotes by individual customers, or by a large group of customers with respect to any given category. Storage of basic customer data, customer preferences, and option selections in the IMMM database is thus an integral facilitator of the easy-to-use interface presented by the IMMM to customers.

Figure 11 is a flow-control diagram of the routine "select category." In step 1102, a customer receives a list of categories from the IMMM. During the first iteration of step 1102, the customer generally receives a list of the highest-level categories, or the highest-level categories pertaining to some large product or service area. When categories are organized in hierarchical fashion, the customer continues to select next-lower level categories, in step 1104, from the list of categories provided in step 1102 until the desired category level is found, as detected in step 1106. The customer then inspects the list of categories to determine if the category that the customer is seeking is included. If so, as detected in step 1108, the user may select the desired category from the list and return the selected category to the IMMM in step 1110, thus completing category selection. If the desired category is not found, then the customer can indicate to the IMMM, in steps 1112-11 14, the customer's desire to submit requests for quotes to a new category, describe that new category to the IMMM, and receive an indication from the IMMM as to whether the new category has been coded and enabled.

This is another important feature that adds flexibility to the IMMM. When a customer seeks a new category, the IMMM may. in real time, conduct at least a cursory search of various sources of information in order to compile an initial merchant list, as well as enter the information concerning the category into the IMMM database. If the IMMM can, within a reasonable response time, compile such a list of merchants, then the customer can continue with category selection in step 11 10. Otherwise, the customer may elect, in step 1 1 16, to attempt to select a different category'. Figure 12 is a flow-control diagram of the routine "input requirements." In step 1202, the customer receives a requirements input prompt from the IMMM. In step 1204, the customer responds to the prompt in order to input the solicited information into the IMMM database. If more requirements are needed by the IMMM, as detected in step 1206, steps 1202 and 1204 may be repeated until all the required input data is received by the IMMM. In step 1208, the customer receives from the IMMM a representation of all the requirements input by the customer. These requirements may indicate brands, models, options, color preferences, and any manner of information related to the category selected by the customer for which a customer desires to receive price quotes. If the customer is not satisfied with the requirements that the customer input to the IMMM, as detected in step 1210, the customer may edit the input requirements in step 1212 through an editing dialog between the customer and the IMMM. Editing of input forms is a standard type of interactive dialog and will not be discussed further. Once the customer is satisfied with the displayed requirements, the customer may decide to accept the requirements in step 1214, in which case the customer submits an indication of acceptance to the IMMM in step 1216, resulting in return of the value TRUE by the ratio "input requirements" in step 1222. Otherwise, the customer may elect to restart the input requirements dialog, in step 1218, or discontinue inputting requirements, resulting in return of the return value FALSE in step 1220.

Figure 13 is a flow-control diagram of the routine "receive merchant list." In step 1302, the customer receives an initial list of merchants which the IMMM has selected from the IMMM database for submission of requests for quotes. The customer may then edit this initial list of merchants in step 1304 until the merchant list is satisfactory to the customer, as detected in step 1306.

Figures 14-20 describe the processing of the basic IMMM transaction and transaction protocol by the IMMM. Figure 14 is flow-control diagram that outlines IMMM processing. In step 1402, the main processing routine of the IMMM receives a new task. IMMM processing is a continuous and ongoing procedure that fields various types of requests and tasks from a variety of different sources, including customers, merchants, and other IMMM processes or personnel. If the received task is a customer connection and login request, as detected in step 1404, the IMMM launches the routine "process customer login" in step 1406 in order to conduct the basic transaction outlined in Figures 9-13 and discussed above. On the other hand, if the received task is a merchant opt out request, as detected in step 1408, the IMMM processes the merchant opt out request by calling the routine "process merchant opt out" in step 1410. Note that the merchant is required to login to the IMMM via a login process similar to the login process undertaken by customers. That merchant login process is not shown. On the other hand, if the received task is an internally generated signal to send out requests for quotes, as detected in step 1412, then the IMMM launches the routine "send out request for quotes" in step 1414. Requests for quotes can be sent out periodically via computer scans of the IMMM database to detect requests for quotes that have been submitted by customers but that either have not yet been submitted to merchants or that were submitted at in some threshold period of time before the current time and not yet satisfied by the merchants to which the requests were submitted. A number of other strategies for timing the sending out of requests for quotes are possible. If, on the other hand, the received task is an internally generated signal to undertake automated surveying, as detected in step 1416, the IMMM launches the routine "send out request for feedback" in step 1318 in order to solicit feedback from customers with respect to specific submitted requests for quotes.

The internal IMMM processing loop, diagrammed in Figure 14, continues to iterate in order to handle any outstanding tasks, the need for iteration detected in step 1420. If there are not other outstanding tasks, the IMMM may continue ongoing building and maintenance of the IMMM database, in step 1422. This is another important feature of the IMMM. The IMMM is continuously searching for new merchants from which to acquire data for the IMMM database. The IMMM, in addition, continually monitors for various information sources to determine when forms for submitting requests for quotes are changed by merchants so that IMMM database tables can be updated to store the new form information. Thus, the IMMM customers benefit from extremely comprehensive and thorough pre-compiled information related to merchants and to the information required by merchants for submitting requests for quotes. It should be noted that many additional types of task may be handled in the internal loop represented in Figure 14, including requests for survey information and other types of information that is stood in the IMMM database, or that can be compiled with reference to the information stored in the IMMM database.

Figure 15 is a flow-control diagram of the routine "process customer login." In step 1502, the IMMM receives a connection request over a particular communications medium and establishes a connection with the customer. In step 1504, the IMMM sends a login prompt to the customer. In step 1506, the IMMM receives the customer's response to the login prompt. In case of certain communications media, such as the mail, certain of these steps are not required. As discussed above, the IMMM may use SQL-like commands to determine whether the customer is a new customer in step 1508. Alternatively, the IMMM may ask the customer at the login prompt to indicate whether the customer is a new customer or not. If the customer is a new customer, the IMMM, in steps 1510-1512, prompts the customer for new customer information and receives the customer's responses, placing the information into the IMMM database. As part of this step, a new customer ID must be generated to uniquely identify the new customer. The information is entered into the IMMM database in step 1414, essentially completing the customer login process and leading to flow of control to the routine "get category" in step 1516. If the customer logging in is not a new customer, as detected in step 1508, the IMMM uses information furnished by the customer to determine the customer's unique ID, as described above, in step 1518. If step 1518 fails, as detected in step 1520, then the IMMM increments a bad login counter in step 1522 and, providing that the bad login counter has not yet exceeded some threshold, as detected in step 1524, begins the login process anew by returning control to step 1504. If, on the other hand, the login counter threshold has been exceeded, then the IMMM displays a login refusal to the customer in step 1526 and returns.

If the customer is properly identified, as detected in step 1520, the IMMM determines whether any necessary customer information fields have not been previously supplied by the customer, in step 1528, and, if so, solicits that information from the customer in steps 1530-1533. The IMMM may detect the need for additional customer information by SQL-like commands similar to the following command:

SELECT NUMBER FROM customer_varchars

WHERE cstjd = 2000 AND VALUE = NULL

NULL values may be placed automatically by the IMMM into the various customer basic information tables, such as Table 10, discussed above, when the IMMM detects new merchants or new merchant forms that require additional information, as discussed above. It should be pointed out that the IMMM may be selective about the basic information required from customers. For example, in certain product or service categories, various merchant forms may differ significantly, and require a large amount of disparate information. In such cases, the IMMM may elect to require only a common subset of the various information required by the forms up front from customers, and defer soliciting specific information for specific forms until such time that the customer selects a merchant using that form for submission of a request for quote. Thus, the IMMM manages a trade off between requesting information from customers during initial or subsequent logins, to avoid lengthy subsequent submissions of requests for quotes, and asking for too much information during the login process that likely may never be used by the IMMM.

Figure 16 is a flow-control diagram of the routine "get category. " In step 1602, the IMMM prompts the customer for selection of a next hierarchical category level. In step 1604, the IMMM receives a response to the prompt from the customer. If the customer selects the next lower level of the hierarchy, as detected in step 1606, the IMMM displays the next lower level categories in step 1608 and waits for a response from the customer. There are many possible alternatives for traversing a hierarchical organization of categories. Moreover, there are many different types of organizations in which categories can be presented to the customer. Thus, initial steps for the routine "get category" serve to navigate through some category organization in order to display a sublist of categories that include the category that the customer is seeking to select.

If the customer has found the category that the customer desires, as detected in step 1610, the IMMM calls the routine "get input requirements" to continue the basic transaction with the customer in step 1612. Otherwise, the IMMM conducts a series of steps 1614-1617 in order to determine what new category the customer is seeking and create that category within the IMMM database. The creation process may involve a real time search of information and sources in order to compile a list of merchants that offer a product or service of that category. Alternatively, the IMMM may elect to defer compilation of merchant lists to a later time, or may decide not to create the new category.

The IMMM returns an indication to the customer that the new category has been created, in step 1620, if the IMMM has elected to create a new category along with an initial list of merchants, as detected in step 1618. The IMMM then receives a response from the customer in step 1622 indicating whether the customer wishes to select the newly created category. If the customer wishes to select the newly created category, as detected in step 1624, the IMMM calls the routine "get input requirement" in step 1612 to continue the processing of the customer transaction. Otherwise, in step 1626, the IMMM determines whether the customer has indicated a desire to select another category, if so, then control flows back to step 1602 to begin the category selection process anew. Otherwise, the routine "get category" returns without continuing the customer transaction.

If a new category was not created by the IMMM, the IMMM indicates this to the customer in step 1628 and receives a response from the customer, in step 1630, indicating whether or not the customer wishes to try selecting another category. Note that dialogs, such as the category selecting dialog diagrammed in Figure 16, may in practice be far more elaborate and allow the customer many different options at many different stages in the category selection process. Many such dialogs are currently used in automatic telephone answering products, Internet web-page based dialogs, and a variety of other technological interfaces.

Figure 17 is a flow-control diagram of the routine "get input requirements. " Requirements related to a particular category may be gleaned from a number of different sources within the IMMM database. For example, one source of such information is Table 14, discussed above. This table lists various information related to categories supplied by specific merchants. Thus, the IMMM may use an

SQL-like command, shown below, to determine that the information field "brand" might be a possible requirement for new cars:

SELECT NAME FROM merchant_categoryJnfo WHERE cjd = 4

Alternatively, requirements may be determined by the IMMM from required fields for forms, stored in Table 18, for which values cannot be found in either of Tables 10 and

11 or Tables 16 and 17. The text description of such information can be found by the

IMMM by executing SQL-like commands such as the command that follows: SELECT query, type FROM forms_descπptιons FC WHERE cjd = 4 AND

(

(table = 'customer_varchars' AND EXISTS

(SELECT value FROM customer_varchars WHERE value = NULL AND cstjd = 2000 AND num = FD fieldjd)) OR (table = 'customerjnts' AND EXISTS

(SELECT value FROM customerjnts WHERE value = NULL AND cstjd = 2000 AND num = FD fieldjd)) OR (table = 'preference_varchars' AND EXISTS

(SELECT value FROM preference_varc ars WHERE value = NULL AND cstjd = 2000 AND pjd = FD fieldjd)) OR (table = 'preferencejnts' AND EXISTS

(SELECT value FROM preferencejnts WHERE value = NULL AND cstjd = 2000 AND pjd = FD fieldjd))

There are many possible ways that the IMMM can identify requirements to solicit from a customer with regard to a particular product or service, in addition to the SQL- like commands shown above.

In step 1702, the IMMM executes one or more SQL-like commands to extract a list of requirements for which the IMMM needs to solicit values from the customer. In step 1704, the IMMM solicits the values for the requirements from the customer and, in step 1706, the IMMM receives the solicited values Step 1704 and 1706 may be repeated in order to solicit and obtain values for all the requirements identified in step 1702. In step 1708, the IMMM displays the requirements for which values have been furnished by the customer back to the customer and receives, in step 1710, a response form the customer to the display of requirements. The customer may respond by indicating a desire to edit the requirements, as detected in step 1712, in which case an editing session is conducted in step 1714. The customer may otherwise respond with an indication to accept the requirements as presented in step 1708, as detected by the IMMM in step 1716, in which case the IMMM proceeds to prompt the customer for contact information, in step 1718, receive the contact information and place the contact information into the IMMM database, in step 1720, and, finally, call the routine "prepare merchant list", in step 1722. Otherwise, if the customer does not wish to accept the requirements as displayed, the customer may elect to repeat the transaction, starting with category selection, in which case the IMMM calls the routine "get category" in step 1724, or may elect to simply discontinue the transaction, in which case the routine "get input requirements" returns in step 1726.

Figure 18 is a flow-control diagram for the routine "prepare merchant list." In step 1802, the IMMM determines the desired number of merchants based on the category selected by the customer. This desired number of merchants is a maximum threshold number so that the list of merchants returned to the customer will not exceed the desired number of merchants. The desired number of merchants may be determined in any number of ways. The desired number of merchants may be solicited from the customer explicitly, may be resident in the IMMM database as a customer preference, or threshold values may be stored in the IMMM database for certain types of categories. Alternatively, any combination of these methods and many other types of methods can be used by the IMMM to determine this threshold value.

In step 1804, the IMMM extracts an initial list of merchants from the database. This can be accomplished by execution of SQL-like commands from which the following two commands, which select an initial list of merchants that offer new automobiles: CREATE TABLE A (mjd INT, fjd INT), INSERT INTO A (mjd. fjd)

SELECT mjd, fjd FROM merchant ormjist WHERE cjd = 4,

In step 1806, the IMMM determines whether the size of this initial list of merchants, computed in step 1804, exceeds the threshold value determined in step 1802. If the threshold value is exceeded, the IMMM then repeatedly filters the list, in step 1808, based on additional customer preferences or additional requirements until the list of merchants falls below the threshold value, or until no more additional preferences can be found for additional filtering operations. As an example, the following SQL-like statement could be used to filter the initial list of merchants for new cars by customer brand preference.

CREATE TABLE B (mjd INT, fjd INT), INSERT INTO B (mjd, fjd) SELECT mjd, fjd from A WHERE EXISTS

(SELECT FROM merchantj-.ategoryjnfo M, preference_varchars PV, preferences P

WHERE M mjd = A mjd AND M name = p namd AND M cjd = 4 AND P cjd = 4 AND PV cst = 2000 AND PV pjd = 2000 AND PV value = M value ) Next, in step 1810, the IMMM filters the list of merchants for geographical proximity. as discussed above, in the overview subsection. This filtering can be accomplished by inputting the address of the customer and the address of each of the merchants into a geographical distance function that computes the distance between the customer and a merchant. If the resulting list of merchants is too small, and the radius for considering merchants geographically is below some maximum radius, as detected in step 1812. the IMMM increases the radius for considering merchants, in step 1814, and then repeats the geographical filtering starting at step 1810. In certain cases, the geographical filtering may not be executed by the IMMM. For certain types of products or services, geographical filtering may be inappropriate. In other cases, the effective radius defining a geographical area of interest may be so large that filtering based on other parameters is more appropriate.

Next, the IMMM determines whether the resulting list of merchants is still too large in step 1816. If the list is still too large, and if any additional filtering criteria are available, the IMMM carries out an additional filtering in step 1818. In step 1820, the IMMM presents a final list of merchants to the customer and receives from the customer a response. If the customer's response indicates that the customer wishes to edit the merchant list, as detected in step 1822, an editing dialog is carried out by the IMMM in step 1824. Finally, in step 1826, the IMMM calls the routine "request submission" to complete the IMMM transaction.

Figure 19 is a flow-control diagram for the routine "quote request submission. " In step 1902, the IMMM prompts the customer for permission to submit requests for quotes to the listed merchants determined in the routine "prepare merchant list." In step 1904, the IMMM receives a response from the customer. If the customer indicates that the request for quotes should not be submitted, as determined in step 1906, the IMMM determines in step 1908 whether the customer wishes to continue the transaction by starting over with selection of a new category. If so, then the IMMM calls the routine "get category" in step 1910 to continue processing of the transaction. Otherwise, the transaction is ended. If the customer elects to submit requests for quotes to the merchant, then the IMMM proceeds by processing each merchant in the list of merchants in the for-loop comprising steps 1912, 1914, 1916, 1918, and 1920. In step 1914, the IMMM identifies the form required by the merchant for the selected category, and, in steps 1916 and 1918, the IMMM uses the customer ID, merchant ID, and a newly generated quote ID to identify the requests for quotes and enters the information into a row in Table 20. Thus, each row of Table 20 represents a submitted request for quote. When all the merchants in the list of merchants have been thus processed, the IMMM may, in step 1922, present a display indicating that the requests for quotes have been submitted and informing the customer of tracking numbers by which the customer may track the requests for quotes as they are processed by the IMMM and merchants. The tracking numbers may be the "id" generated in step 1916.

Figure 20 is a flow-control diagram for the routine "send out requests for quotes. " In step 2002, the IMMM compares the lastjsubmitted and time_received fields of entries in Table 20 to select entries representing requests for quotes that need to be submitted either for the first time or submitted again. The IMMM extracts a list of merchant ID's from these entries as a list of merchants to which requests for quotes need to be sent. One approach for extracting a list of merchants might be to execute an SQL-like command such as that which follows:

SELECT UNIQUE mjd FROM request_for_quotes

WHERE DATEDIFF(week, time_received, lastjsubmitted) < 2 AND DATEDIFF(day, lastjsubmitted, GETDATE()) > 1

Each merchant in the list is then processed in the for-loop comprising steps 2004,

2006, 2008, 2010, and 2012. In step 2006, the IMMM extracts completed forms from the database for each entry in Table 20 representing a request for quotes that is to be submitted. Table 18 lays out forms for requests and indicates where the values for each query in the form can be obtained. Forms can be reconstructed from the data contained in the IMMM database by execution of a series of SQL-like select statements to construct a completed form, as discussed above. Next, in step 2008, the

IMMM consults Table 12 to determine by what communications medium to submit the completed form to the merchant and then submits the form to the merchant in step 2008. Then, in step 2010, the IMMM updates the last submitted field in Table 20 to indicate that the form was submitted.

Figure 21 is a flow-control diagram showing the merchant processing phase of the basic IMMM transaction. In step 2102, the merchant receives a series of requests for quotes from the IMMM. In step 2104, the merchant decides whether to respond to those requests for quotes, or opt out. If the merchant decides to opt out, in step 2106, the merchant decides whether to reply to the IMMM or simply to ignore the requests for quotes. If the merchant decides to reply, then in step 2108, the merchant replies to the IMMM via a communications medium indicated by the IMMM in the package of the requests for quotes submitted to the merchant in step 2102 to indicate that the merchant does not wish to participate at this time. The IMMM can then either remove the merchant from the IMMM database, or store information in the IMMM database to indicate that the merchant is either temporarily or permanently opting out of the IMMM, depending on the merchant's response. This information might be stored in additional basic information fields in the logical merchant basic information record, represented by Tables 5, 6, and 7.

If, on the other hand, the merchant decides not to opt out, then the merchant processes each request received in step 2102 in the for-loop comprising steps 2110, 2112, 2114, and 2116. In step 2112, the merchant determines a price to quote for the category of product or service in the request for quote. In step 2114, the merchant uses information provided in the request for quotes to either respond to the IMMM with the determined price quote or respond directly to the customer who submitted the request for quote.

Alternative Embodiments and Elaborations In the previous three subsections, the basic IMMM customer transaction has been described, with reference to a generalized implementation of the IMMM database. As noted above, there are almost a limitless number of ways in which to define and implement the IMMM database and the processes by which the IMMM conducts basic transactions. Many different possible elaborations of the basic transaction are possible, including collection and storage of many types of additional information, and provision of different options to the customer for submitting, directing, and tracking submitted requests for quotes. Quote tracking is made possible by the rich information that can be stored in the IMMM database with regard to submitted requests for quotes. For example, additional columns can be included in Table 20 to indicate stages of processing of a request for quotes within the IMMM and within merchant request for quotes processing facilities. Customers can access quote tracking tools via the Internet or possibly by telephone to receive information about the current status of any particular submitted request for quote. Similarly, rich information stored within the IMMM database can form the basis of various request for quotes processing tools that can be made available by the IMMM to merchants. A particular benefit to both customers and merchants is that the request for quotes information is stored in the centralized database by the IMMM, which may be distributed and mirrored and served by redundant, fault-tolerant processes. Thus, reliable maintenance of the data is centralized and off loaded from customers and merchants.

In addition to providing the basic IMMM transactions, as discussed above, the IMMM can collect survey data from customers and provide the results of automated surveys by customers and merchants in order to provide merchant verification information to customers and to provide feedback to merchants on the service provided by the merchants to customers. The IMMM can use the data stored within the IMMM database as a basis for providing any number of additional utilities and services both to customers and merchants. Merchants may be able to acquire comparative information on products and services offered by other merchants, marketing information on the customer population of the IMMM, and other such useful information. Data collected on the volume of submission of requests for quotes and the volume of responses to the requests for quotes can be generated and provided to prospective merchants and customers as a marketing tool for the IMMM itself.

The foregoing description, for purposes of explanation, used specific nomenclature to provide a thorough understanding of the invention. However, it will be apparent to one skilled in the art that the specific details are not required in order to practice the invention. In other instances, well-known components are shown in block diagram form in order to avoid unnecessary distraction from the underlying invention. Thus, the foregoing descriptions of specific embodiments of the present invention are presented for purposes of illustration and description; they are not intended to be exhaustive or to limit the invention to the precise forms disclosed, obviously many modifications and variations are possible in view of the above teachings. The embodiments were chosen and described in order to best explain the principles of the invention and its practical applications and to thereby enable others skilled in the art to best utilize the invention and various embodiments with various modifications as are suited to the particular use contemplated. It is intended that the scope of the invention be defined by the following claims and their equivalents:

Claims

1. A method for managing a market transaction between a potential customer seeking price quotes on particular product and merchants providing the product, the method comprising: compiling a database that includes information about products offered by the merchants and information about how requests for quotes can be submitted by customers to the merchants; receiving a request from the potential customer to establish a communications connection; establishing a communications connection with the potential customer; when the potential customer is a new customer, receiving from the customer information commonly required by merchants from customers seeking quotes and storing the information in the database; when the potential customer has previously conducted a market transaction, retrieving information related to the customer from the database; receiving from the potential customer a selection of a category of product for which the potential customer desires quotes; selecting from the database a list of merchants offering the selected product; for each merchant selected from the list of merchants, when additional information related to the selected category is needed in order to complete the selected merchant's request for quotes form, receiving from the potential customer additional information related to the selected category and storing the additional information in the database; submitting a request for quotes from the potential customer to the selected merchant.

2. The method of claim 1 wherein the database contains information that describes the data required by each merchant described in the database from a potential customer in order to provide to the potential customer a quote for a particular product.

3. The method of claim 1 wherein selecting from the database a list of merchants offering the selected product further includes: selecting a list of merchants from the database that provide the selected product and that meet any requirements and preferences stored in the database for the potential customer; when the selected list of merchants is smaller than a threshold number, selecting additional merchants from the database by changing the requirements and preferences for the potential customer; and when the selected list of merchants is larger than a maximum desired number, filtering the list of merchants in order to produce a list of merchants no larger than the maximum desired number.

4. The method of claim 1 further including allowing the potential customer to edit the selected list of merchants to determine a final list of merchants to which requests for quotes are submitted.

5. The method of claim 1 further including: receiving from a merchant to which a request for quotes has been submitted an indication that the merchant does not wish to receive requests for quotes, and storing an indication in the database to prevent subsequent inclusion of the merchant in selected lists of merchants.

6. The method of claim 1 further including: receiving from the potential customer an indication of the potential customer's satisfaction with services provided by a merchant to which a request for quotes has been submitted on behalf of the potential customer, and storing the indication received from the potential customer into the database.

7. The method of claim 1 wherein products may be tangible goods and services.

8. The method of claim 7 wherein compiling the database further includes: accessing information sources, such as telephone directories and Internet web sites, to identify merchants offering various products; when a description of a product offered by an identified merchant is not already present in the database, adding a description of the product to the database; and when a description of the merchant is not already in the database, adding a description of the merchant to the database.

9. The method of claim 8 wherein a description of a product offered by an identified merchant includes a category of product.

10. The method of claim 7 wherein a communications connection may include: communications via a telephone connection; communications via an exchange of mail through a postal service; communications via electronic mail; and Internet-based communications via web pages.

11. The method of claim 7 wherein customer information includes: a name; an address; contact information for various communications media including telephone, electronic mail; and customer preferences.

12. The method of claim 7 wherein additional information related to the selected category includes: selection of options available for products of the selected category; and preferences related to the selected category.

13. The method of claim 3 wherein selecting from the database a list of merchants offering the selected product further includes: retrieving the potential customer's preferences and options selected by the potential customer from the database; for each merchant selected from the database that offers the selected product, retrieving the selected merchant's information from the database related to the selected category; comparing the retrieved preferences and selected options to the retrieved information from the database related to the selected category; when comparison of the retrieved preferences and selected options to the retrieved merchant's information related to the selected category indicates that the retrieved preferences and selected options match the retrieved merchant's information at or above a threshold comparison value, including the merchant in an intermediate list of merchants; for each merchant selected from the intermediate list of merchants, calculating a distance between the selected merchant and the potential customer; when the calculated distance between the selected merchant and the potential customer is less than a maximum value, including the selected merchant in the selected list of merchants.

14. The method of claim 7 wherein submitting a request for quotes from the potential customer to the selected merchant further includes: retrieving merchant information related to the selected merchant from the database; using the retrieved merchant information to obtain a request for quotes form for submitting a request for quotes to the selected merchant; retrieving customer information and additional customer information related to the potential customer from the database; using the retrieved customer information and additional customer information to complete the obtained request for quotes form; using the retrieving merchant information related to the selected merchant to determine a communications medium and communications address to use to submit the request for quotes form; and sending the completed request for quotes form to the selected merchant.

15. A method for submitting requests to quotes for the provision of a good or service to a number of merchants by using an intelligent multi-media market, the method comprising: connecting to the intelligent multi-media market via a communications medium; logging into the intelligent multi-media market; indicating to the intelligent multi-media market a selection of a category of good or service for which a quote is desired; inputting to the intelligent multi-media market additional information related to the selected category of good or service, preferences regarding the selected category of good or service, and a selection of options available for the selected category of good or service; receiving from the intelligent multi -media market a list of merchants that provide the selected good or server, the provision of the selected good or service by each merchant in the list of merchants compatible with the input preferences and selected options; indicating to the intelligent multi-media market those merchants from the list of merchants from which requests for quotes are desired; and receiving quotes for the good or service from a number of the selected merchants, the requests for quotes having been submitted by the intelligent multi-media market to indicated merchants from the list of merchants.

16. The method of claim 10 wherein the intelligent multi -media market selects a list of merchants that provide the selected good or service from a database of merchants compiled by the intelligent multi-media market via information sources available through information services such as telephone yellow pages, catalogues, and Internet web sites;

17. The method of claim 15 wherein a connection to the intelligent multi-media market may be made via a telephone connection, the Internet, mail, email, and fax.

18. The method of claim 15 wherein logging into the intelligent multi-media market further includes: providing identification information to the intelligent multi-media market; and when logging into the intelligent multi-media market for the first time, providing to the intelligent multi-media market customer information commonly required by merchants from customers seeking quotes and storing the information in a database; and when not logging into the intelligent multi-media market for the first time, providing to the intelligent multi-media market additional customer information commonly required by merchants from customers seeking quotes and storing the information in a database identified by the multi-media market subsequent to the last login.

19. The method of claim 15 wherein inputting to the intelligent multi-media market additional information related to the selected category of good or service, preferences regarding the selected category of good or service, and a selection of options available for the selected category of good or service further includes: receiving prompts for additional information related to the selected category of good or service, preferences regarding the selected category of good or service, and a selection of options available for the selected category of good or service from the intelligent multi-media market, the intelligent multi-media market identifying additional information related to the selected category of good or service, preferences regarding the selected category of good or service, and a selection of options available for the selected category of good or service from information contained in the database of information related to merchants; responding to the prompts for additional information related to the selected category of good or service, preferences regarding the selected category of good or service, and a selection of options available for the selected category of good or service by indicating additional information, preferences, and selections of options to the intelligent multi-media market.

20. The method of claim 15 wherein, prior to receiving from the intelligent multimedia market the list of merchants, the multi-media market: selects an initial list or merchants that provides the selected good or service; filters the initial list of merchants into an intermediate list of merchants based on the correspondence between information about merchants stored in the database of merchant information and the selected preferences and options; and filters the intermediate list of merchants into the list of merchants based on geographical location of the merchants.

21. The method of claim 15 wherein, prior to receiving quotes for the good or service from a number of the selected merchants, the intelligent multi -media market: uses customer information, preferences, and selections of options provided to the multi-media market to prepare requests for quotes for each indicated merchant; and sends the prepared requests for quotes to each of the indicated merchants.