v’
`
`'r
`
`Attorney Docket No : M-l 0958 US
`Client Reference: TOOO42
`
`
`
`“Express Mail” mailing label number:
`
`EL803198675US
`
`LOGICAL AND CONSTRAINT BASED BROWSE
`HIERARCHY WITH PROPAGATION FEATURES
`
`Scott Bonneau
`Michael Nonemacher
`
`Jeremy Weinrib
`
`CROSS REFERENCE TO RELATED APPLICATIONS
`
`This application relates to application serial no.
`
`
`
`(attorney docket M-lO956
`
`US), filed on same day herewith, entitled "Rules Based Provision of Custom Pricing for
`
`Multiple Entities" and naming Scott Bonneau, Michael Nonemacher and Jeremy Weinrib as
`
`inventors, the application being incorporated herein by reference in its entirety.
`
`This application relates to application serial no.
`
`
`
`(attorney docket M40957
`
`US), filed on same day herewith, entitled “Rules Based Custom Catalogs Generated from a
`
`Central Catalog Database for Multiple Entities" and naming Scott Bonneau, Michael
`
`Nonemacher and Jeremy Weinrib as inventors, the application being incorporated herein by
`
`reference in its entirety.
`
`This application relates to application serial no.
`
`
`
`(attorney docket M-11857
`
`US), filed on same day herewith, entitled "Browse Hierarchies Customized for Rules Based
`
`Custom Catalogs" and naming Scott Bonneau, Michael Nonemacher and Jeremy Weinrib as
`
`inventors, the application being incorporated herein by reference in its entirety.
`
`5
`
`
`
`
`20
`
`This application relates to application serial no.
`
`
`
`(attorney docket M-lO959
`
`US), filed on same day herewith, entitled "A Method For Building Digital Databases
`
`Optimized For Maintenance, Descriptiveness, And Fast Search“ and naming Scott Bonneau
`
`and Michael Nonemacher as inventors, the application being incorporated herein by reference
`
`in its entirety.
`
`7l24l lvl
`
`-l-
`
`Exh. 2005 - Page 1 of 24
`
`Versata Exh. 2005
`Volusion v. Versata
`
`CBM2013-00017
`
` Versata Exh. 2005
` Volusion v. Versata
` CBM2013-00017
`
`
`
`Exh. 2005 - Page 1 of 24
`
`
`
`

`

`Attorney Docket No : M-l0958 US
`Client Reference: T00042
`
`BACKGROUND OF THE INVENTION
`
`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.
`
`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
`
`
`
`20
`
`25
`
`30
`
`71241 lvl
`
`-2-
`
`Exh. 2005 - Page 2 of 24
`
`Exh. 2005 - Page 2 of 24
`
`

`

`Attorney Docket No ' M-10958 US
`Client Reference: TOOO42
`
`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. 1a. 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.
`
`Figure 1b is illustrates one possible example of a hierarchy that has been created in
`
`accordance with the model of Fig 1a. In the example, the items in the catalog database are
`
`divided into two very general classes: hardware and software. Thus, the hierarchy of Fig. lb
`
`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 “0/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.
`
`10
`
`
`
`25
`
`3O
`
`Fig. lc 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
`
`712411v1
`
`-3-
`
`Exh. 2005 - Page 3 of 24
`
`Exh. 2005 - Page 3 of 24
`
`

`

`Attorney Docket No.. M-l 0958 US
`ChentReflnence: T00042
`
`selected category. In Fig. 1c, the class node “Software” was selected, which led to the
`
`display of category nodes “Applications,” “0/8” 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 (ie. 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. 1a.
`
`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
`
`10
`
`
`
`25
`
`3O
`
`712411vl
`
`Exh. 2005 - Page 4 of 24
`
`Exh. 2005 - Page 4 of 24
`
`

`

`Attorney Docket No.: M-lO958 US
`Client Reference: T00042
`
`0r 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 embodiment, the hierarchy includes a plurality of nodes each
`representative of some predefined subset of the items. Each of the nodes is a child of one
`other node, except for a root node, which is a child of no other node and is an ancestor of all
`
`of the nodes. Some of the nodes each specify one or more constraints defining a scope of the
`
`subset of items represented by each of the nodes. A second group of the nodes specifies no
`constraints, and each of the second portion of nodes establishes a logical grouping of items
`
`that logically defines a scope of the subset of the items represented by each of the second
`
`portion relative to the scope of items represented by its parent.
`
`The constraints specified by the first portion of nodes are based on attributes
`
`associated with the items and a permissible range of values for those attributes. Each node in
`
`the hierarchy inherits all of the constraints of its ancestors along with any of its own
`
`constraints, and the aggregation of these constraints through a logical ANDing completely
`
`defines the scope of the items represented by the node.
`
`Leafnodes comprise a third portion of the nodes, and leaf nodes have no child nodes
`
`
`
`under them. The hierarchy can facilitate computer browsing of the database when the
`
`20
`
`hierarchy is made available for display on a computer terminal. In one embodiment, the
`
`nodes are operable to be activated when selected by a computer mouse. In one embodiment,
`selecting a node other than a leaf node causes optional text associated with the selected node
`to be displayed. Further, activating a node also causes the display of the activated node’s
`child nodes and renders them available for selection. Selecting a leaf node causes an
`
`25
`
`aggregation of all constraints specified by the leaf node and its ancestors, and the formulation
`of a search rule that includes all items in the database that meets the aggregation of
`
`constraints. The search rule is then transmitted to a database server in the former of a search
`
`query that returns a list of the items from the database that belong to the subset represented
`by the leaf node. The list of items, and other collateral information is then returned to the
`
`30
`
`computer terminal used to select the leaf node.
`
`7124llvl
`
`-5-
`
`Exh. 2005 - Page 5 of 24
`
`Exh. 2005 - Page 5 of 24
`
`

`

`Attorney Docket No.: M-10958 US
`Client Reference: T00042
`
`BRIEF DESCRIPTION OF THE DRAWINGS
`
`The present invention may be better understood, and its numerous objectives, features
`
`and advantages made apparent to those skilled in the art by referencing the accompanying
`
`drawings. The use of the same reference number throughout the several figures designates a
`
`like or similar element.
`
`Figure 1a shows a prior-art browsing hierarchy based on classification.
`
`Figure 1b shows an example hierarchy based on the prior art hierarchy of Fig. 1a.
`
`Figure 10 shows an example of how the browsing hierarchy might be displayed to a
`
`user as the user browses a catalog in accordance with the prior—art hierarchy of Fig. 1b.
`
`Figure 2 shows one embodiment of a system in which the logic and constraint based
`
`hierarchy of the invention can be employed.
`
`Figure 3 provides one possible example of a logic and constraint—based hierarchy that
`
`might be employed in accordance with the invention.
`
`DETAILED DESCRIPTION
`
`Overview
`
`
`
`The method and apparatus for hierarchically representing items in a database provides
`
`a highly flexible and expressive catalog browsing hierarchy by which a buyer can navigate
`
`the items in a seller’s catalog database. The seller can develop the hierarchy to be arbitrarily
`
`expressive and provide any number of navigational paths by which the buyer can navigate the
`
`20
`
`seller’s catalog to reach a particular item or set of items in the catalog.
`
`In one embodiment, the seller’s database is hierarchically flat and each product is
`
`represented by a unique SKU ID (identifier) in the catalog database. In this embodiment,
`
`each product belongs to exactly one product type. Unless an attribute is one that is
`
`deliberately made common to more than one product type, each attribute belongs to one
`
`25
`
`product type and is identified by a unique attribute ID. Each product type is also uniquely
`
`identified with a product type ID. Those of skill in the art will recognize that the most
`
`common way to uniquely identify something in a table is with some form of alphanumeric
`
`7124llvl
`
`—6—
`
`Exh. 2005 - Page 6 of 24
`
`Exh. 2005 - Page 6 of 24
`
`

`

`Attorney Docket No.: M-lO958 US
`Client Reference' T00042
`
`59 CC
`identifier. Some examples of product type might be “personal computer (PC), memory,”
`
`and “hard-drive.” Some examples of attributes that might be uniquely associated with such
`73 66
`
`product types might be “processor clock speed,” “memory size,
`
`vendor” and “capacity”
`
`respectively. Catalog data typically consists of part specific data such as attribute value pairs.
`
`Examples are color = blue, size = 64k, processor speed = 800 MHZ, etc.
`
`Each node in the hierarchy is associated with a unique label. Each node also contains
`
`a list of the labels for each of its child nodes (if any). Optionally, each node is associated
`
`with marketing text and image data, and may specify one or more constraints that require all
`
`items falling under the node to have specific values for certain item attributes. The
`
`constraints specified at a node are logically ANDed together, and are in effect logically
`
`ANDed with the constraints specified (if any) by all of the nodes that are its ancestors. Thus,
`
`any items that fall under a particular node in the hierarchy must meet al of the constraints by
`
`specified by the node itself, but also any constraints that are specified by its ancestors. Put
`
`another way, each node inherits the constraints of its ancestors. If a node does not specify
`
`any constraints, then it in effect specifies a logical grouping of items that could not otherwise
`
`be specified by an ANDed set of constraints. A logical grouping of items under a node is the
`
`equivalent of an implied logical ORing of constraints.
`
`In one embodiment, whenever a leaf node is selected (i.e. activated), the constraints
`
`specified by the leaf node and all of its ancestors are ANDed together (i.e. aggregated) into a
`
`single rule that is used to generate a single query on the catalog database. The search returns
`
`a set of catalog items the scope of which is dictated by the aggregated constraints. The
`
`returned set of catalog items, along with marketing and image data associated with the items
`
`can then be displayed by the browser for the user’s perusal. In one embodiment, the rule
`
`“includes” all items in the database that meet the aggregation of constraints. Those of skill in
`
`the art will recognize that the rule could instead be implemented as “excluding” all items
`
`meeting the constraint. Because a node specifying a logical grouping in effect specifies an
`
`implicit ORing of constraints by express assignment, the OR function does not have to be
`
`included in the database query and therefore executed by the database server. This makes the
`
`searching process significantly faster.
`
`As previously mentioned, each of the nodes optionally can be associated with
`
`marketing text and image data related to the items defined by the node. When a user selects
`
`10
`
`
`
`25
`
`30
`
`712411vl
`
`-7-
`
`Exh. 2005 - Page 7 of 24
`
`Exh. 2005 - Page 7 of 24
`
`

`

`Attorney Docket No: M—10958 US
`Client Reference. TOOO42
`
`an interim (i.e. not a leaf) node in the hierarchy, the associated text and image data can be
`
`displayed along with the children of the selected node. This information may be more
`generalized information for items falling within the scope of the constraints specified by the
`node and its ancestors, or it could be remotely or not all related to the path taken by the user
`
`through the hierarchy.
`
`Thus, a seller can arbitrarily define the scope of catalog items defined by any node,
`
`without regard to some predetermined hierarchy, provided that attributes are associated with
`the items or that a logical assignment can be made, sufficient to define the desired scope.
`
`Structure
`
`
`
`20
`
`One embodiment of the invention is presented with reference to Fig. 2. Catalog
`
`database 10 contains the most recent version of the catalog data assembled and maintained by
`
`the seller. The catalog data stored in the database 10 is accessed through queries made to
`
`database server 9. Database server 9 can be any server capable computer, including one
`
`capable of running SQL Server 7 by Microsoft. Item information can be imported into
`database 10 via import input 24 from manufacturers and vendors of products sold by seller.
`
`A format such as XML (eXtensible Mark—up Language) can be used to represent the imported
`
`data for easy manipulation and conversion.
`
`Users authorized by the seller may be given access to the database 10 through an
`
`application program running on application server 8, which is in communication with the
`database server 9 through communications bus 32. The application server 8 can be any
`
`server capable computer, including a PC server capable of running the Windows NT
`
`operating system available from Microsoft Corporation. Updates to and maintenance of
`database 10 can be made directly by the seller—authorized users through the application
`
`program. In one embodiment of the invention, the application server 8 communicates with
`database server 9 over bus 32 using TCP/IP communications protocol and JDBC/ADO
`
`25
`
`database protocols.
`
`The set of nodes and the arbitrary rules used to define the scope of the subset of
`
`catalog data to be included at each node of the browse hierarchy is created by seller—
`
`authorized users through terminals 38 coupled to application server 8. The constraints are
`
`30
`
`physically stored with (although maintained independently from) the catalog data in database
`
`712411v1
`
`.8.
`
`Exh. 2005 - Page 8 of 24
`
`Exh. 2005 - Page 8 of 24
`
`

`

`Attorney Docket No.2 M-10958 US
`Client Reference. T00042
`
`10. For each leaf node activated during the browse process, the application aggregates the
`
`constraints specified by the leaf node and all of its ancestors into a single “include” rule. The
`application then derives a database search query from the “include” rule and communicates
`the query to the database server 9. The database server 9 executes the query and retrieves the
`subset of the catalog data that meets the aggregated constraints for the leaf node activated
`
`during the browsing process. The database server 9 returns the subset of the catalog
`
`information in the form of a list of item SKUs, along with any ancillary marketing text or
`
`image data associated with each of the returned SKUs. In one embodiment, the data is
`presented for display on the user’s terminal from which the browsing is conducted. where a
`user is browsing the hierarchy over the Internet using a web browser, the list of retrieved
`
`SKUs and any data associated therewith is converted by the application to one or more web
`pages communicated presented to the user based on the query initiated by the selection of the
`
`leaf node.
`
`In another embodiment, a buyer authorizes users to access the application running on
`
`application server 8 over the Internet 40. In this case, the buyer-authorized user accesses the
`application through web server 12 coupled to browsers 14. Those of skill in the art will
`recognize that a single server could be used to run both the application as well as the web
`
`server application. Once the buyer—authorized user gains access through an Internet Service
`
`Provider (ISP), the user contacts the application through web server 12, signs on and is
`
`acknowledged as an authorized user by the application. The application then provides the
`
`user with web pages that display the browse hierarchy as developed by the seller in
`
`accordance with the invention.
`
`10
`
`
`
`
`The buyer—authorized user can then browse the catalog database by selecting (i.e.
`
`activating) nodes in the hierarchy and initiating database queries as previously described.
`
`25
`
`The application provides the results of database searches as initiated by the selection of leaf
`
`nodes in the hierarchy as web pages through web server 12 over Internet 40 to be displayed
`
`on the user’s browser 14. The seller-authorized users can perform hierarchy development
`
`and maintenance either over the Internet 40 using a machine such as a PC running a web
`
`browser 38, or directly with the application server 8 as previously discussed.
`
`712411vl
`
`-9-
`
`Exh. 2005 - Page 9 of 24
`
`Exh. 2005 - Page 9 of 24
`
`

`

`Attorney Docket No: M-10958 US
`Client Reference: T00042
`
`Methodology
`
`As previously discussed, each node has a unique label or name associated with it,
`
`each node also contains a list of the names of its children. Optionally, each node specifies
`
`attribute-value based constraints as well as marketing text or image data that can be displayed
`
`5
`
`upon activation of the node. In one embodiment, the general form of the constraints specified
`
`at each node might be
`
`All items where:
`
`[ATT_Name op ATTVVal
`
`(AND)
`
`[ATT_Name opATT_Va1]
`
`l;
`
`
`
`where ATT_Name is an attribute identifier, 0p is an operator {=, >, <, “starts with” or
`
`“contains”}, ATT_Val is the value of the attribute, and the AND is an implicit operator
`‘I
`
`between all of the constraints specified by the node.
`
`Also as previously discussed, in one embodiment when a leaf node is activated, a rule
`
`is generated that includes all of the constraints as specified for the leaf node and each of the
`nodes that are ancestors of the leaf node. Just as the constraints for each node are implicitly
`
`ANDed together, so are the constraints between nodes. The rule for the entire browse path
`between the selected leaf node and the root takes the general form of either an include (INC)
`
`or exclude (EXC). In one embodiment, the rule is an INC based rule and takes the general
`
`20
`
`form:
`
`INC
`
`All items where:
`
`[ATT_Name op ATTiVal
`
`(AND)
`
`[ATT_Name op ATT_Val]
`
`25
`
`]
`
`One example of a hierarchy that might be developed by a seller-authorized user in
`
`accordance with the method of the invention is illustrated in Fig. 3. At the top of the
`
`hierarchy is a root node 142 that typically is labeled “the root” and typically does not specify
`
`30
`
`constraints associated with it. This is because for a typical implementation, the root node will
`
`7124llvl
`
`-10-
`
`Exh. 2005 - Page 10 of 24
`
`Exh. 2005 - Page 10 of 24
`
`

`

`Attorney Docket No.: M-10958 US
`Client Reference: TOOO42
`
`represent all items in the database. In fact, if the root node 142 does specify constraints, the
`
`hierarchy will likely not represent or span the scope of the entire database. One example
`
`where this might be desirable is in the event that items in the database are associated with a
`
`date-stamp attribute indicating when they were added to the database. The root node could,
`
`for example, constrain the items falling under it as only those items that were added more
`
`than three days prior to the current date.
`
`In the alternative, if the root node does not specify any constraints, than by default it
`
`specifies a logical grouping of all items in the database as defined by its children. This is a
`
`powerful tool for expression because the items may then be grouped arbitrarily under the root
`
`10
`
`node into any combination of nodes that the seller desires. With respect to Fig. 3, the items
`
`
`
`are grouped into the categories of: “PCs,” “Peripherals,” “Software,” and “Clearance
`
`Specials.” The benefit of specifying such a logical grouping at any node is significant. First,
`
`it is equivalent to the implicit logical ORing of several disparate attributes. It does so without
`
`requiring any database query to reflect the function, and thus does not burden the database
`
`server with its execution. Second, it permits the seller to classify the items into arbitrary
`
`groups under it as the seller sees fit. The root 142 may also have some optional marketing
`
`text or image information associated with it so that the data may be displayed to the user’s
`
`browser prior to the user browsing the catalog database.
`
`The next level of the example hierarchy of Fig. 3 includes the logical grouping of
`
`nodes labeled “PCs” 143, “Peripherals” 155, “Software” 154 and “Clearance Specials” 157
`
`as previously noted. Each of these nodes includes the list of their respective children as
`
`previously discussed. If the items that fall under any of these nodes can be expressed as one
`
`or more logically ANDed constraints based on attribute values associated with the items in
`
`the database, they are so specified. For nodes such as PCs 143 and Software 154, if these
`
`25
`
`labels also represent product types for example, then the items that fall under them can be
`
`specified by node constraints such as: “all items having PRODUCT TYPE = PC” and “all
`
`items having PRODUCT TYPE = Software” respectively. For a node such as Clearance
`
`Specials 157, however, there may be no such attribute ascribed to any items in the database.
`
`Thus, the nodes that fall under it will themselves be a logical grouping.
`
`30
`
`The node labeled “PCS” 143 has as its list of children nodes labeled “High-
`
`performance” 145 and “Medium Performance” 144. In one embodiment, these nodes will be
`
`712411V1
`
`-11-
`
`Exh. 2005 - Page 11 of 24
`
`Exh. 2005 - Page 11 of 24
`
`

`

`Attorney Docket No.: M-10958 US
`Client Reference: T00042
`
`displayed if the buyer—authorized user selects the “PCs” 143 node. For these nodes,
`constraints can be specified by the seller to describe the items that would fall under either of
`
`these nodes in the hierarchy. For example, the constraint for node 145 might be “all items
`
`where Processor Clock Speed > lGHz”. To continue down a browse path, a constraint for
`
`node 151 might be “all items Where PROCESSOR VENDOR = Intel” and for node 152
`
`might be “all items where PC VENDOR = Compaq”.
`
`Thus, in the case of the example hierarchy of Fig. 3, the rule defining of all items that
`
`fall under the leaf node “Compaq” 153 with its aggregated constraints could be expressed as:
`
`INC
`
`All parts where:
`
`[Product type = ‘PC’
`
`AND [Processor clock speed > ‘1 GHZ’
`
`AND [Processor Vendor = ‘Intel’
`
`[PC Vendor = ‘Compaq’]
`
`]
`
`An example of aggregated node constraints by which to include all software that is
`
`manufactured by Microsoft Corporation and is related to “Windows” under leaf node 159
`
`could be expressed as follows:
`
`INC
`
`All parts Where:
`
`[Product type : ‘software’
`
`[Description “starts with” ‘Windows’
`
`[Vendor = ‘Microsoft’]
`
`]
`
`10
`
`
`
`
`
`25
`
`A database query is created by the application running on the application server from
`
`these INC rules, and the database query is issued to the database server. The database server
`
`searches the database in accordance with the constraints specified by the rules and returns a
`
`30
`
`set of SKUs to the application server. The application then converts the data returned by the
`
`712411v1
`
`-12-
`
`Exh. 2005 - Page 12 of 24
`
`Exh. 2005 - Page 12 of 24
`
`

`

`Attorney Docket No.2 M-10958 US
`Client Reference: TOOO42
`
`search to pages that can be displayed on the user’s computer. In the case of an embodiment
`
`accessed over the Internet, the search results data is converted into web pages that are
`
`transmitted to the user over the Internet by the web browser. The pages are received by the
`
`user’s browser, and displayed by the browser on the user’s terminal.
`
`It can be seen from the example hierarchy of Fig. 3 that the invention provides far
`
`more flexibility and expressiveness than prior art browsing hierarchies. For example, the
`
`user has the option to browse high-performance Compaq personal computers either through a
`level that further refines the PCs based on processor vendor (i.e. through browse path nodes
`
`143, 145, 151 and 152), or directly from the high-performance node (i.e. through browse path
`
`10
`
`nodes 143, 145 and 147). In former case, the SKUS returned by selecting the leaf node will
`
`
`
`
`include only those PCs that are made by Compaq and employ an Intel processor operating at
`
`a clock speed greater than 1 GHZ. In the latter case, the SKUs will be all PCs made by
`Compaq running at over 1 GHZ. Thus, it can be seen that the items represented by the SKUs
`in the first case will also be included in the set of SKUs returned by the second case. There
`
`are two paths by which the SKUs in the first set are browsed. Moreover, some of those SKUs
`may also end up returned by selecting the “PCs” node under the “Clearance” node.
`
`One example of the more flexible nature of the invention is that the particular levels
`
`in the hierarchy are not rigidly assigned to one attribute or product type for differentiation.
`
`For example, the second level of the hierarchy for PCs splits based on processor performance,
`
`whereas for software, the split is based on operating system type. With respect to peripherals,
`
`the second level of the hierarchy splits on product categories. Thus, the seller is not
`
`constrained to follow some rigid and predetermined hierarchical format.
`
`Another example of the flexibility of the invention permits arbitrary logical groupings
`
`to be made where convenient. For example, the “Peripheral” 155 and “Clearance” 157 nodes
`
`25
`
`are not likely discernable on the basis of rules based constraints; the seller will not likely alter
`
`the database to add a clearance attribute to items that are occasionally priced for clearance.
`
`Yet, this hierarchical category can be arbitrarily established using the invention. In fact, the
`
`entire hierarchy under the Clearance node 157 may be a logical grouping that specifies the
`
`SKUs outright for those PCs and those software programs that have been placed on
`
`30
`
`clearance.
`
`712411vl
`
`-13-
`
`Exh. 2005 - Page 13 of 24
`
`Exh. 2005 - Page 13 of 24
`
`

`

`Attorney Docket No.: M40958 US
`Client Reference: T00042
`
`In Fig. 4, a screen shot is presented that provides one example of how the hierarchy
`
`for a particular catalog database may be developed by a seller-authorized user. The nodes are
`
`represented as folder icons and selecting one of the node icons will reveal child nodes if any.
`The existence of child nodes is indicted by the plus signs that are associated with each node
`
`icon. The sc