Method and system for providing interactive electronic catalog for product and constraint information of equality and inequality search

[0002] The present application claims priority to co-pending U.S. Provisional Application Serial No. 60/053,345 which was filed on Jul. 22, 1997.

[0003] This invention relates to the field of electronic information searching. More specifically, it relates to internet-based electronic catalog query and response interactions for product inquiries and sales.

[0004] Search tools for advancing through information provided in a database have been available for years. Generally, in such applications, a user's responses direct progress through the layers of available information. The interaction follows one of a plurality of pre-set paths along a decision tree, with the user input typically being limited as responses to pre-defined choices. As an example, so-called “expert systems,” such as searchable on-line medical databases, are navigated via responses to system prompts regarding symptoms which are tied to various diagnoses in a relational database. Interactive on-line catalog sales applications utilize user responses to questions, which may directly or indirectly relate to products in the catalog. The user may indicate his or her interest in defined categories of product information and then be provided with appropriate screens displaying available product from the database.

[0005] Shortcomings of available prior art search and query tools include the fact that all users must interact with the system using a limited set of pre-established interactions. Necessarily the pre-established interactions are predisposed toward a particular type of customer and cannot effectively meet the needs of a larger audience of users that may have an interest in the information. In addition, all users must navigate through the pre-set paths and iterations to obtain information regarding features of the available products.

[0006] Different users will also have different interaction parameters with respect to the level of product detail that they require. For example, when shopping for a computer, a professional programmer will approach the interaction with more detailed specification requirements than will a user who is shopping for a home computer for “recreational” use. Finally, the details of the actual display of product information should ideally differ depending upon the user, the user's needs, and the user's knowledge in the area. An inventive electronic catalog system has been developed, and is the subject of co-pending U.S. patent application Ser. No. 08/987,214, filed Dec. 9, 1997, which was based on is now U.S. Pat. No. 6,076,091, provisional patent application Ser. No. 60/032,543, entitled “METHOD AND SYSTEM which is the subject of U.S. Pat. No. 6,076,091 which issued on Jun. 13, 2000, FOR PROVIDING A FLEXIBLE AND EXTENSIBLE ON-LINE ELECTRONIC CATALOG,” which was filed on Dec. 10, 1996 and is assigned to the present assignee (hereinafter referred to as “assignee's system”). In that application, the inventors detailed an electronic catalog system which provides the user with the ability to interact at a user-defined level of detail, in the user's preferred language, and with user-directed queries, as opposed to the relatively static prior art interaction systems. Particularly significant to the assignee's system is the ability for meaningful interactions at the user's level of product awareness, so that the user does not have to step through a series of query interactions which are too fundamental, or too advanced, for the user's level of interest and/or knowledge.

[0007] Queries input to presently available electronic catalogs had, in the past, been limited to responding to system-generated “yes-no” questions, or to inputting specific product feature details; for example, inputting “memory=4” would obtain product information about systems which have exactly 4 MB of memory. Such queries could only provide limited information to the user, and would not allow for retrieval of all of the relevant information which may be desired by the user, and which would be available in the assignee's system. The “memory=4” query noted above will, using prior art search tools, retrieve all systems which are available for sale with exactly 4 Mb of memory. It may be, however, that the user wishes to obtain information about all available systems which have at least 4 Mb of memory. Inexact or inequality searching requires additional searching steps and additional characterization of product data which would not otherwise be maintained under the prior art electronic catalog methods and systems.

[0008] Prior art systems are not only unable to respond to inequality queries, but are also ill-equipped to respond to successive user-defined refinements of queries. For example, when the user is choosing the search parameters for searching in a web-based Common Gateway Interface (CGI), and the search parameters are input in random order, such that the user is not following a pre-set path along a system decision tree, the CGI will not retain information regarding the user's preceding refinements/parameters and is, therefore, unable to support the iterative query. In addition, at the graphical user interface (GUI) level, prior art systems based on hypertext mark-up language (HTML) do not readily allow for the graphical expression required to support the preferred user interaction involving inequalities.

[0009] It is therefore an objective of the present invention to provide an on-line catalog interaction methodology to support inequality searching for retrieval of product information.

[0010] It is another objective of the invention to provide an extensible system to characterize product data for retrieval based upon an inequality search.

[0011] Still another objective of the invention is to provide data collection, categorization and searching methodologies which support inequality searching for retrieval of product information.

[0012] Yet another objective of the invention is to provide for on-line product searching which involves multiple iterations for user refinement of the query.

[0013] These and other objectives are realized by the present invention which provides a system for collecting and categorizing metadata about products which may be the subject of user-input inequality searches, which metadata is used in a unique method for retrieving and displaying the product data. Unique methods are provided for: generating image information at the user interface; inputting of the inequality search; conducting an inequality search based on the metadata in response to input at the user interface; and, displaying the search results appropriately.

[0014] The invention will now be further detailed with specific reference to the appended Figures wherein:

[0015] FIG. 1 provides a schematic illustration of the graphical user interface for inequality searching using textually-marked selection buttons created using HTML.

[0016] FIG. 2 provides a schematic illustration of the graphical user interface for inequality searching in accordance with the present invention.

[0017] FIG. 3 provides a schematic illustration of the X-axis values of the image file representations of the equality:inequality values to be used in interpreting user input.

[0018] FIG. 4 provides a representative process flow for the inventive build-time processing steps.

[0019] FIG. 5 provides a representative process flow for the inventive run-time processing steps.

[0020] FIG. 6 provides a schematic of a user/client: server system for implementation of the present invention.

[0021] User interaction techniques with systems using the hypertext mark-up language (HTML) on the world wide web (WWW) are severely limited when compared to graphical interfaces found in modern day windowing systems that are found on personal computers. These web-based systems must provide interactions which are easy enough to use in order for users to build queries that involve inequalities. Expressing such inequalities usually takes a sophisticated user interface requiring multiple screen representations (i.e., “buttons”), multiple interactions (i.e., multiple successive steps to refine the query), and a trained user who understands how to put several query concepts together to express the search that they require, including all of the search constraints.

[0022] Under the present invention, product information is gathered and dynamically maintained to facilitate inequality searching. As a first step to gathering and categorizing the product data, one must determine which product features are candidates for “greater than or equal to” and “less than or equal to” searches based upon the data type. All numeric data types (i.e., float, double, numeric and int.) are suitable values for inequality searching. Character data, however, cannot be quantified, and is therefore not suited for quantification comparisons, other than “=” or “≠”. For example, if the data represents CD-ROM speed with the values “6X”, “8X”, “10X”, and one performed a search for “CD-ROM>6X”, the search would retrieve only products with “6X” and “8X” drives, because the first character of “10X” is “1”, which is less than the first character in “6X.” It is for this reason that inequality searching cannot be conducted on character data. It is also important to note that the query must include “or equal to” so that the selected value be included in the search, or else the search will come back empty if the largest or smallest value in the list is selected with “>” or “<”, respectively.

[0023] Data formatting and presentation is another problem which must be solved. To determine how to display the data, one must first understand, for example, how the data is to be used,; whether it is displayable; whether it needs special treatment for localized use (such as formatting of conversion of currency values in displaying product pricing); and, whether the data is the name of an image file and should be displayed as an image and not as the image file name. Also, one must determine what means should be used to display the values, such as a simple text hyperlink, a choice box, multiple selection boxes, radio buttons, check boxes, etc. Some displays will allow single selections while others allow multiple selections, either of which will directly affect how the query is to be built.

[0024] FIG. 6 provides a schematic illustration of a client:server system for implementation of the present invention. Server location 601 includes at least one server 602 for performing the build-time and run-time processing steps discussed below and for storing the results in the at least one storage location 603. The server is connected across the network, WWW 605, to a client location 610 which includes at least a client computer 611, user display 612, and user input device 613.

[0025] Determining the data type, data usage, and display means is done by collection of “metadata” in a “build-time” step. “Metadata” is simply, “data about data.” The “build-time” is the name given to the preparation steps conducted prior to allowing the users of the system to perform their queries (as opposed to “run-time” when the user is using the system). This metadata is collected with a builder tool at the individual feature/field level and has two levels of granularity. The first level (“level 1”) is metadata about the feature itself, which is immutable information about the data. Its name, type, usage, etc. will not change regardless of how the data is displayed. Level 1 data is composed of the data elements shown in Table I:

[0026] The second level of metadata (Level 2) is concerned with the particular manner of display chosen for the feature. This data might change for a different instance of the data, so that the relationship between the first and second levels of data is one too many. The second level of metadata is composed of display attributes about the data, for example: what manner in which the data should be displayed; how multiple values should be sorted; and whether a unit of measure should be displayed next to the values, how juxtaposed, etc. Table II provides the Level 2 metadata:

[0027] Given the availability of the foregoing Level 1 and Level 2 metadata, the system can dynamically determine how to deal with the data at run-time. Representative pseudo-code for using the available metadata at run-time follows:

[0028] In FIG. 4, the “build-time” processing steps are representatively illustrated. At step 401, the product information is indexed, followed by generating product constraint information at step 402. The product constraint information comprises the “immutable” first level metadata. Once the information has been generated, the product information and product constraint information are stored at step 403 for use upon initialization of a user query (discussed below as “run-time” processing). Additional display information may be generated at step 404 and stored, at step 405.

[0029] The system is further driven by a set of templates at run-time. These templates determine the overall layout of the data. While the data is assumed to be displayed in a table, the template can define how that table should look, (e.g., its orientation, number of rows and columns, background colors, etc.). Any information which is unique to a specific feature is specified in the metadata and any information that controls the overall layout of features is specified in the template. By using these methods, the final determination of what features are shown and how they are sorted, etc., is left to the product expert who enters the data; while the final design and presentation to the customer is left to someone who understands catalog and product layout, such as a graphics artist.

[0030] The templates are HTML files having special tags that the system recognizes during run-time and processes appropriately. Anything that is not a recognizable tag is passed through the system to be processed by the web server. The custom tags are placed in “comments” so as not to confuse a web browser, which would be unable to “understand” them. The format of the tags is as follows:

[0031] <!--IC_TAG=tagname option1=value1 option2=value2 etc . . . -->

[0032] At run-time, the system searches for lines in the template which start with “<!--ICTAG=” and then parses the next word to determine which type of tag is present. The system then passes the remainder of the string over to a class which knows how to process that particular tag. The tag class then renders the tag to the client. All of the known tags are kept in the registry which aids the run-time program in determining what tags are valid and what classes should be used to process the tags. In this way, tags can be added in the future without any modifications of the system, thereby allowing dynamic updating of the display formats without requiring that the catalog be taken “off line” during implementation of updates. Because the system is written in JAVA, new classes can be added while the system is running, simply by refreshing the registry.

[0033] The pseudo-code for the master run-time loop, including template recognition and implementation, is shown below:

[0034] The call to the class that handles the tag, shown in the master run-time loop pseudo-code above, invokes similar pseudo-code to that shown previously. Therefore, the main run-time logic simply iterates over the template looking for tags to process, and the actual processing, which is unique to each tag, is handled by a tag's registered class.

[0035] The valid tags for a representative implementation of the system are seen in Table III. Each tag is registered in a row of a database table which contains the name of the tag and the name of the class which must be used to process the tag.

[0036] Once the system is capable of supporting inequality searching, the user interface must provide an input mechanism beyond that which has been previously available. However, the need for multiple buttons to express the various values of equality and inequality may clutter the screen in an environment where screen real estate is very expensive. For example, if a customer is presented with a selection of ten (10) product features, forty (40) screen representations or buttons would be needed to express all of the statements of the query (i.e., one each for “equal to feature x”, “unequal to feature x”, “greater than or equal to feature x” and “less than or equal to feature x” for each of features one through 10). The forty buttons would not only take up a great deal of screen real estate, but would also overwhelm the user with choices.

[0037] A first alternative is to provide four screen “buttons” to represent the four query statements for each feature, as schematically illustrated in FIG. 1. The HTML code for the illustrated hard drive representation would be as follows:

[0038] As is illustrated, the browser has “wrapped” the buttons for each feature, due to the fact that the buttons would have been too wide to display next to each other. The text button display is clearly not visually appealing for the user. Moreover, if one were to imagine all query statements for all product features, the display would overwhelm the user and the buttons dominate the look of the page. Furthermore, different web browsers may display the text buttons in different configurations, depending upon the browser's specifications and protocols. Therefore, a consistent look across different browsers accessing the underlying catalog could not be guaranteed.

[0039] In addition, when a selection is input by the user to one of the text buttons of FIG. 1, the web server would return a query string and utilize logic to test for the existence of each variable. For the “not equal” example, the query string developed by the common gateway interface (CGI) would be:

[0040] QUERY_STRING=HARDDRIVE=540&notequals=Not+equal.

[0041] As can be seen, there is no single variable to check, such that each button generates a new variable name. The query would require logic to test for the existence of each variable while anticipating that three of the four would not be generated. Once the program determined which variable was generated, it would then use logic to determine what to do next.

[0042] Alternatively, one could define all four buttons to have the same name as in the tags below:

[0043] <INPUT TYPE=submit NAME=operand VALUE=“Equal”>

[0044] <INPUT TYPE=submit NAME=operand VALUE=“Not equal”>

[0045] <INPUT TYPE=submit NAME=operand VALUE=“Less than”>

[0046] <INPUT TYPE=submit NAME=operand VALUE=“Greater than”>.

[0047] Using the latter programming, the CGI would return a string representing the button word, and a string compare would be conducted to compare the returned string to the available choices. String comparisons, however, are expensive to execute, making use of such comparisons a less than optimal solution. This user input interpretation process requires several steps; and, therefore extra time. While a useful option for implementing the inequality search, an alternative embodiment has been developed to provide faster, and more visually appealing query statement representations.

[0048] FIG. 2 illustrates the preferred embodiment of the graphical user interface for the inventive inequality searching. A selection bar, 20, 22 and 24, is provided for each of the product feature values for users of the computer system to easily indicate whether they are interested in retrieval of values equal to, not equal to, greater than or equal to, or less than or equal to, the illustrated value. The selection bar takes up minimal screen space and does not require sophisticated user input in order to implement the desired query. The product feature values, shown as memory in megabytes at 21, hard drive in megabytes at 23, and modem speed at 25, are each accompanied by a selection bar bearing mathematical symbols that express the query. Each selection bar is a single image which takes up minimal screen real estate. Since the selection bar is an image, the web browser will not separate the elements of the image and “wrap” them, as may occur with the text buttons shown in the FIG. 1 embodiment.

[0049] It is to be noted that the selection bar illustrated for each of the first two features, memory and hard drive, provides for selection of four queries based upon the displayed value. Therefore, the user can retrieve product information about all available computers having, for example, more than 4 Mb of memory but less than 540 Mb on the hard drive; or exactly 4 Mb of memory with a hard drive having more than 540 Mb; etc. Since the search conducted in response to selection of one of the four queries for either the memory or hard drive feature value is a numerical comparison, inequality searching is possible. For the illustrated value for the CD ROM, however, which is 2X (meaning two times the normal speed of 150 rpms), greater than and less than comparisons cannot be conducted on the character string “2X”. Therefore, the query choices provided for the CD ROM feature includes only equal to or unequal to the value 2X. As will be apparent to one having skill in the art, it may be possible to express the feature value differently in order to allow for inequality searching for that feature. For example, one could express the CD ROM feature in rpms (e.g., 300) and then conduct any of the four queries on the numerical representation, which does not then involve searching on character strings. Characterization of the product features in the electronic catalog is, however, ideally expressed in the terms of the art which have already been developed through standard marketing channels. Therefore, each type of representation and search can be supported by the present invention, as is appropriate to the product, the market, and the user needs.

[0050] By providing a single image of the selection bar, one avoids the possibility of the web browser altering the display, as noted above. In addition, the input interpretation is facilitated by providing the queries as illustrated in FIG. 2. The CGI program that interprets the user input would use the X,Y coordinates returned from the call in the environment variable QUERY_STRING to determine where the user pressed on the button image. In actuality, for the illustrated selection bar/button as shown in FIG. 3, only the X coordinate is required for interpretation of the user's input. If the user pressed, or clicked on, the “not equal to” section of the image, the following query string would be returned to the CGI program:

[0051] QUERY_STRING=HARDDRIVE=540&X=35&Y=6.

[0052] Because the symbols on the selection bar are of identical size (e.g., 22 pixels in width), a simple offset calculation along the X axis can be used to determine how far over the user pressed, and thus what symbol was selected. In the example above, 35 is between 22 and 44, which places the input on the second symbol. Such input interpretation is much faster than the variable or character string comparisons required by the FIG. 1 embodiment. For data that is character-based, such as the CD ROM feature values discussed above, the less than and greater than queries may not be appropriate. The inappropriate query representations can be removed from the selection bar without affecting the programming logic, since the X values will simply not be generated in that range for the particular product feature displayed. The pseudo-code below shows the logic:

[0053] if (X<22)

[0054] // the user pressed equal

[0055] else if (X<44)

[0056] // the user pressed not equal

[0057] else if (X<66)

[0058] // the user pressed less than or equal to

[0059] else if (X<88)

[0060] // the user pressed greater than or equal to

[0061] endif.

[0062] The first “if()” that gets satisfied indicates the symbol selected by the user.

[0063] The selection bar can be implemented for a WWW application by using an HTML form which contains an <INPUT>tag that creates an image button. The button would use the bar as its image. The HTML code for using the selection bar would be as follows:

[0064] The resulting display is an image that contains mathematical characters that would not otherwise be represented on an HTML page. Furthermore, because it is an image, the web browser will not wrap it in the cell. Programs that use the illustrated selection bar of FIG. 2 evaluate where on the bar the user has pressed or clicked to determine what action to take. The bar itself is generated from the single line of HTML code with the tag:

[0065] <INPUT TYPE=image SRC=“/icons/equalbar.gif” border=0 VALUE=SUBMIT>

[0066] While the illustrated selection bar image is symmetrical, it may be generated as an asymmetrical image as well; however, input interpretation is not as straightforward for the asymmetrical image instance.

[0067] In operation upon initialization a user will be presented with a query display based on the information generated and stored in accordance with the processing steps of FIG. 4. As shown in FIG. 5, the system will dynamically generate an image file, at step 501, and display the file, at 502, including the product features and graphical representations of the operators (i.e., the equality and inequality operators). The system receives user input, at step 503, as a user of the system selects a feature that they desire in a product (e.g., hard drive), a value or values desired for that feature (e.g., 1 GB), and an operation on that feature/value pair (e.g., “greater than or equal to”). They do this by selecting the value or values they want from a list that is generated for each feature. The system searches at 504 and displays the search results with further search parameters at 505. If further user input is receive, at 506, the system repeats the search and display steps until the user query is satisfied. The user input selection (again, by clicking on a portion of the image) is interpreted as a query similar to the following:

[0068] SELECT DISTINCT(HARDDRIVE) FROM FEATURETABLE WHERE <where_clause>.

[0069] The query shown above will return only the unique values for the feature HARDDRIVE that are in the system. At first, the <where_clause> is empty. As features, values and operations are selected, the where clause will contain the selections (or constraints) so far. If the user selected 1000 and clicked on the “greater than or equal to” symbol on the selection bar for hard drive, the next time that the query is run, the system would add HARDDRIVE>1000 to the where clause. The foregoing has the effect of subsetting all of the other feature values as only those which are also found in a product with a hard drive which is 1 GB or larger. On successive queries, the values are ANDed together so that only products which contain all of the selected features will be considered. Alternatively, the features could be ORed together to show the user products which have ANY (i.e., one or more) of the selected features.

[0070] In the above example, where the initial values list for MEMORY could have contained 8, 16 and 32, after the HARDDRIVE selection, the system may return only 16 and 32 because there are no available products with 8 MB of memory and a 1 GB hard drive. In this way, feasible products are always kept in the product space and the user will never enter a query selection which yields no products (i.e., no search results). Providing the user with search results is extremely important for keeping a user shopping at your web site, as there is nothing more frustrating than taking the time to formulate a query, only to get back no results.

[0071] It is important to note that if the user selects multiple values on a single input entry, these values must be ORed with each other before being ANDed with previous or subsequent constraints. For example, if the user selects 1000 and 2000 for HARDDRIVE, then the query should be “HARDDRIVE=1000 OR HARDDRIVE=2000”. If on the next invocation, the user selects “MEMORY=16”, then the query should be “HARDDRIVE=1000 OR HARDDRIVE=2000 AND MEMORY=16”. In this way, like features from each iteration are ORed together and dissimilar features are ANDed together to produce the desired result. It should be noted that “like” features from successive iterations are not ORed together, but rather ANDed together, which allows further refinement of a previous feature constraint.

[0072] In order for the foregoing to work in a web-based CGI environment, the system must maintain its own state, because CGI programs inherently have no notion of state. CGI programs service a transaction and then exit, “forgetting” everything previously done. It is for this reason that the constraint list of feature, operation, and values must be converted into a format which can be appended to the URL and later transformed back into constraints for a <WHERE_CLAUSE> on subsequent invocations. The server program sends its state, including the previous constraints, to the client and the client sends the constraints back in the next <WHERE_CLAUSE>. In this way, previous constraints from previous query string(s) from the HTML query will be incorporated into each successive call.

[0073] The invention has been described with reference to several specific embodiments. One having skill in the relevant art will recognize that modifications may be made without departing from the spirit and scope of the invention as set forth in the appended claims.