Data processing: database and file management or data structures – Database design – Data structure types
Reexamination Certificate
2001-06-18
2004-12-21
Courtenay, III, St. John (Department: 2126)
Data processing: database and file management or data structures
Database design
Data structure types
C705S027200, C345S215000
Reexamination Certificate
active
06834282
ABSTRACT:
BACKGROUND OF THE INVENTION
1. Field of the Invention
The present invention relates to browsing on-line catalogs and web sites, and more specifically to a flexible and arbitrarily expressive rules-based browsing hierarchy for on-line catalogs and web sites.
2. Description of the Related Art
With the advent of Internet based commerce, organizations on both the buy and sell side of business-to-business (B2B) procurement relationships have sought to harness computer networks as a means for automating the procurement process between them. To facilitate e-commerce, and particularly e-procurement, suppliers of goods and services have developed electronic catalogs by which potential buyers can receive and display information regarding the goods and services offered by the seller, including descriptive information, pictures and prices.
One issue confronted by sellers offering goods and services for sale over the Internet, whether through electronic catalogs or a web site, is how to present their product information to a buyer. One simple approach is to mimic a user's interaction with a paper catalog. This approach involves presenting the buyer with a sequence of catalog pages displayed on the buyer's computer screen, each page consisting of descriptive data in the form of text and images that cover some number of items being offered by the seller. Using this technique for catalogs containing a large number of items will likely require the buyer to browse too many pages to find the items in which the user is interested. For a catalog or web site with even a moderately expansive offering of items, this solution is not practicable. The buyer will probably lose interest before finding the item being sought, and the seller will lose a sale.
One way to make the browsing process more manageable is to organize the catalog items in the database into some form of hierarchy. The presentation created by the hierarchy should be expressive, and should guide the buyer through the catalog of product offerings (as stored in the database of the seller) to specific items of interest to the buyer with reasonable ease and flexibility. A hierarchy typically attempts to classify and/or categorize catalog items starting with relatively general levels of specificity, and gradually becomes more specific based on values of particular attributes associated with the items. Such a hierarchy can be thought of as a simple tree structure, with higher-order nodes representing more general classifications for the items, and lower-order nodes (i.e. the children of the more general nodes) representing a narrowing of the scope of items that occupy the lower levels of the hierarchy.
One way sellers have been known to hierarchically organize their catalog data for browsing is in accordance with a “classification-category-vendor” hierarchy. A simple representation of this hierarchy is illustrated in
FIG. 1
a
. Imposing this hierarchy requires that products be stored in the database along with values for each of these three attributes. At the classification level
100
, catalog items are split into some predetermined number of classes each represented by a unique class label. Each class node is then split at the category level
120
into some number of category nodes equal to the number of predetermined categories established under each class. The category nodes are then split at the vendor level
140
to create some number of vendor nodes under each category equal to the precise number of vendors supplying products in the category.
FIG. 1
b
is illustrates one possible example of a hierarchy that has been created in accordance with the model of
FIG. 1
a
. In the example, the items in the catalog database are divided into two very general classes: hardware and software. Thus, the hierarchy of
FIG. 1
b
reflects these classes with two nodes at the class level
100
, one labeled as “hardware”
180
and one labeled as “software”
160
. The class nodes are then split at the category level
120
into categories represented by the nodes “O/S (operating systems)”
162
, “applications”
164
and “video games”
166
. Under the “hardware” node
180
, the categories might be “PCs (personal computers)”
182
, “peripherals”
186
, and “storage”
184
. Finally, the nodes at the category level
120
are split at the vendor level
140
into a number of nodes representing the particular vendors supplying items from each category as illustrated.
FIG. 1
c
illustrates the manner in which a seller might display this hierarchy in the form of hyperlinks on a web page displayed by a browser program. Typically, the top level is displayed first. If a user-buyer selects one of the classes, the categories are then displayed under the selected class in a manner that indicates they are children falling under the class (e.g. indented). Those of skill in the art will recognize that there a number of ways in which a user can select hyperlinks, including activating the link by clicking a button of a computer mouse. Selection of a category then causes the vendor choices to be displayed under the selected category. In
FIG. 1
c
, the class node “Software” was selected, which led to the display of category nodes “Applications,” “O/S” and “Video Games.” The “Applications” node was then selected, leading to the display of vendor nodes “Adobe,” “Microsoft” and “Intuit.” Selecting the “Adobe” node will then typically retrieve all Adobe applications software products, and descriptive marketing text and images associated with those products.
The database consisting of the data for each item can be flat (i.e. the database has no physical hierarchy such that all of the items are at the same level). In this case, items fall into a particular one of the terminal nodes of the hierarchy (i.e. a node having no children of its own) based on the attribute values that are ascribed to that node of the hierarchy. In the alternative, the database itself may be physically ordered hierarchically, in which case the location into which an item is stored in the database implicitly dictates its position in the hierarchy, rather than expressly using the values of attributes stored with the items. While a hierarchically arranged database can be more economical in size because attribute values are implied rather than explicitly stored, sellers have been moving away from this approach. Requiring the ordering of the database in a certain manner removes even more flexibility from the seller with respect to how the hierarchy is employed. For example, a seller may wish to organize the hierarchy as “vendor-class-category” but would be restricted from doing so if the database was hierarchically ordered in the manner illustrated by
FIG. 1
a.
Either way, the foregoing approach is extremely inflexible because the expressiveness of the hierarchy is limited to that which has been preordained. Even if the depth of the hierarchy is expanded to include more levels of specificity, the navigational path by which each item is ultimately browsed is fixed, and so are the rules by which the hierarchy is organized. Put another way, each item can be browsed through exactly one path through the hierarchy because the manner in which the hierarchy is organized is predetermined.
Thus, it would be desirable to provide a more flexible and expressive browse hierarchy that permits the seller the freedom to organize the browsing hierarchy in an arbitrary manner. Such a hierarchy would even permit a user to browse the catalog data through multiple navigational paths to arrive at the same item because multiple instances of an item would be permitted to reside in the hierarchy. It would also be preferable for the hierarchy to be flexible enough to accommodate arbitrary logical groupings of catalog items or classifications of items that aren't necessarily tied together by some common set of attribute values stored in association with the items in the database.
SUMMARY OF THE INVENTION
The invention is a hierarchy for representing a plurality of catalog items stored in a catalog database. In one embodime
Bonneau Scott
Nonemacher Michael
Weinrib Jeremy
Chambers Kent B.
Courtenay III St. John
Hamilton & Terrile LLP
Trilogy Development Group, Inc.
LandOfFree
Logical and constraint based browse hierarchy with... does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with Logical and constraint based browse hierarchy with..., we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Logical and constraint based browse hierarchy with... will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-3278172