Abstract:
Methods and apparatus for maintaining businesses rules in a configuration system are disclosed. The presently disclosed system allows systems to be configured using a plurality of rules that are syndicated by a plurality of different manufacturers. Each manufacturer syndicates a portion of the overall system attributes and/or configuration rule set for use by others. Configuration users, such as the sales channel, may then create additional rules and/or configure products with the most recent version of the component attributes and configuration rules, and no single entity is burdened with maintaining the entire attribute and/or rule set.

Description:
TECHNICAL FIELD 
     The present disclosure relates in general to system configuration, and, in particular, to methods and apparatus for maintaining businesses rules in a configuration system. 
     BACKGROUND 
     Often, systems have multiple options. However, those options may not all be compatible with each other. For example, a person may be selecting components for a new personal computer. If the person (e.g., end-user) chooses a certain peripheral (e.g., graphics card) for the computer, that peripheral may require a certain minimum amount of memory and/or CPU speed. Configuration software may be used to assist the end-user and enforce these rules. However, present configuration systems have certain drawbacks. 
     The configuration of complex systems typically requires a large number of rules. Maintaining these rules is burdensome. When new configuration options are added to the system, existing rules may need to be modified, and new rules may need to be added. This problem is compounded when different components in the system come from different manufactures, because the information needed to generate the rules may not be available. 
     SUMMARY 
     The presently disclosed system solves this problem by allowing systems to be configured using a plurality of rules that are syndicated by a plurality of different manufacturers. Each manufacturer syndicates a portion of the overall system attributes and/or configuration rule set for use by others. For example, a sales channel (e.g., of computers) may receive (push or pull) system configuration rules from multiple component manufacturers (e.g., manufacturers of CPUs, memory cards, graphic cards, etc.). The sales channel may then create additional rules and/or configure the system with the most up to date version of the component attributes and configuration rules, and no single entity is burdened with maintaining the entire attribute and/or rule set. 
    
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
         FIG. 1  is a high level block diagram of an example communications system. 
         FIG. 2  is a more detailed block diagram showing one example of a computing device. 
         FIG. 3  is a flowchart of an example process to maintain businesses rules in a configuration system. 
         FIG. 4  is an example run-time display of a system configurator applying the syndicated businesses rules. 
     
    
    
     DETAILED DESCRIPTION OF EXEMPLARY EMBODIMENTS 
     The present system is most readily realized in a network communications system. A high level block diagram of an exemplary network communications system  100  is illustrated in  FIG. 1 . The illustrated system  100  includes one or more client devices  102 , one or more web servers  106 , and one or more databases  108 . Each of these devices may communicate with each other via a connection to one or more communications channels  110  such as the Internet or some other wired and/or wireless data network, including, but not limited to, any suitable wide area network or local area network. It will be appreciated that any of the devices described herein may be directly connected to each other instead of over a network. 
     The web server  106  stores a plurality of files, programs, and/or web pages in one or more databases  108  for use by the client devices  102  as described in detail below. The database  108  may be connected directly to the web server  106  and/or via one or more network connections. The database  108  stores data as described in detail below. 
     One web server  106  may interact with a large number of client devices  102 . Accordingly, each server  106  is typically a high end computer with a large storage capacity, one or more fast microprocessors, and one or more high speed network connections. Conversely, relative to a typical server  106 , each client device  102  typically includes less storage capacity, a single microprocessor, and a single network connection. 
     A more detailed block diagram of the electrical systems of a computing device (e.g., client device  102  and/or server  106 ) is illustrated in  FIG. 2 . Although the electrical systems of a client device  102  and a typical server  106  may be similar, the structural differences between the two types of devices are well known. 
     The client device  102  may include a personal computer (PC), a personal digital assistant (PDA), an Internet appliance, a cellular telephone, or any other suitable communication device. The client device  102  includes a main unit  202  which preferably includes one or more processors  204  electrically coupled by an address/data bus  206  to one or more memory devices  208 , other computer circuitry  210 , and one or more interface circuits  212 . The processor  204  may be any suitable processor. The memory  208  preferably includes volatile memory and non-volatile memory. Preferably, the memory  208  stores a software program that interacts with the other devices in the system  100  as described below. This program may be executed by the processor  204  in any suitable manner. The memory  208  may also store digital data indicative of documents, files, programs, web pages, etc. retrieved from a server  106  and/or loaded via an input device  214 . 
     The interface circuit  212  may be implemented using any suitable interface standard, such as an Ethernet interface and/or a Universal Serial Bus (USB) interface. One or more input devices  214  may be connected to the interface circuit  212  for entering data and commands into the main unit  202 . For example, the input device  214  may be a keyboard, mouse, touch screen, track pad, track ball, isopoint, and/or a voice recognition system. 
     One or more displays, printers, speakers, and/or other output devices  216  may also be connected to the main unit  202  via the interface circuit  212 . The display  216  may be a cathode ray tube (CRTs), liquid crystal displays (LCDs), or any other type of display. The display  216  generates visual displays of data generated during operation of the client device  102 . For example, the display  216  may be used to display web pages and/or desktop pop-up data received from the server  106 . The visual displays may include prompts for human input, run time statistics, calculated values, data, etc. 
     One or more storage devices  218  may also be connected to the main unit  202  via the interface circuit  212 . For example, a hard drive, CD drive, DVD drive, and/or other storage devices may be connected to the main unit  202 . The storage devices  218  may store any type of data used by the client device  102 . 
     The client device  102  may also exchange data with other network devices  220  via a connection to the network  110 . The network connection may be any type of network connection, such as an Ethernet connection, digital subscriber line (DSL), telephone line, coaxial cable, etc. Users  114  (e.g., end-users and/or configuration users) of the system  100  may be required to register with the server  106 . In such an instance, each user  114  may choose a user identifier (e.g., e-mail address) and a password which may be required for the activation of services. The user identifier and password may be passed across the network  110  using encryption built into the user&#39;s browser. Alternatively, the user identifier and/or password may be assigned by the server  106 . 
     A flowchart of an example process  300  for maintaining businesses rules in a configuration system is illustrated in  FIG. 3 . Preferably, the process  300  is embodied in one or more software programs which is stored in one or more memories and executed by one or more processors. Although the process  300  is described with reference to the flowchart illustrated in  FIG. 3 , it will be appreciated that many other methods of performing the acts associated with process  300  may be used. For example, the order of many of the steps may be changed, and many of the steps described are optional. 
     In general, the process  300  allows systems to be configured using a plurality of attributes and rules that are syndicated by a plurality of different manufactures. The process  300  preferably begins with a plurality of manufacturers syndicating their respective attributes and/or configuration rules (block  302 ), which are then received by one or more sales channels (e.g., CDW) (block  304 ). For example, HP may publish one rule that says their model HP-1 computer must be configured with at least 2 GB of RAM if you want to use the NVIDIA G1 graphics card and another rule that says their model HP-2 computer must be configured with at least 4 GB of RAM if you want to use the NVIDIA G1 graphics card. Similarly, Dell may publish one rule that says their model D-1 computer must be configured with at least 4 GB of RAM if you want to use the NVIDIA G1 graphics card and another rule that says their model D-2 computer is never compatible with the NVIDIA G1 graphics card no matter how much RAM is installed. In addition, CDW may write certain rules regarding the compatibility of certain system attributes from various manufactures such as HP and Dell. 
     These attributes and business rules may be any type of business rule and may apply to things that are not systems or products. For example, the business rules may be bill of materials (BOM) rules, pricing rules, hiding rules, recommendation rules, constraint rules, recommended items rules, etc. 
     For each configuration, the end-user can create a bill of materials. When a BOM rule triggers, it appears to the end-user (e.g., buyer) on a commerce document line item pages. 
     Pricing rules may be used to calculate a price based on how a product is configured. The designer can create a smart pricing system by generating business rules for configurable attributes that add pricing to products. Pricing rules can be based on a combination of one or more configured values. 
     Hidden attribute rules tell the system to hide certain attributes when a pre-defined condition is met. Using hidden attribute rules, the designer can reduce the number of rules needed for a configuration process because the designer can include disparate attribute types in a single flow rule and how one set of attributes or another based on some condition. 
     Recommendation rules can be used to help end-users configure products by offering suggested attributes values. For each configuration, where a model or part would likely have a certain attribute value, the designer can create a recommendation. When recommendations trigger, they preferably appear to end-users. For example, the recommendation may display as text next to a configurable attribute that has a recommended value. For attributes with a set or forced option enabled, recommendation values automatically auto-populate the configurable attribute fields. 
     Constraint rules are set-up to warn an end-user when a certain attribute value will not work in a configuration. These rules may be used to reduce errors in the configuration process. For example, if the end-user is configuring an automobile and the end-user selects a blue exterior color, a constraint may run that only allows the end-user to select tan as an interior color. While a constraint is active, the system typically does not allow the end-user to advance to commerce (e.g., a purchase screen). 
     Recommended item rules enable a designer to associate extra sets of parts and models with products based on user-configured values. If the recommended item is mandatory, then the end-user must select (e.g. purchase) the configured model with the recommended item. Preferably, there is no way to delete the item association in the commerce process. If the item is not mandatory, then the end-user can opt to not buy the recommended item. 
     Preferably, the business rules (e.g., system configuration rules) are stored as a plurality of if-then statements relating certain attributes to other attributes. For example, “If Brand=‘Dell’ and Model=‘D-2’ Then NvidiaBrand=‘No’. These if-then statements are then used when the configuration software is executed (block  306 ). For example, an end-user may go to a web site  400  to configure a computer (see  FIG. 4 ). During the configuration the end-user enters a plurality of configuration attributes (block  308 ). For example, the end-user may select a Dell brand computer (via drop-down box  402 ), model D-1 (via drop-down box  404 ), with a 4 GB of RAM (via drop-down box  406 ). It will be appreciated that any suitable input mechanism may be used such as check boxes, radio buttons, etc. 
     The product is interactively configured based on the selected configuration attributes and configuration rules (block  310 ). For example, if the end-user selected a Dell model D-1 with 4 GB of RAM, one of the available graphics cards may be the NVIDIA G1. Accordingly, the NVIDIA G1 is one of the choices available for selection in the graphics card drop-down box  408 . Non-selectable choices may be excluded (e.g., not included in the drop-down box) or included (e.g., dimmed and not selectable). 
     If the end-user changes a choice in one drop-down box, the other drop-down boxes may also change based on a business rules table and the corresponding if-then statements relating certain attributes to other attributes. For example, if the end-user changes from a 4 GB of RAM to 8 GB of RAM, additional video cards may become available. In another example, one attribute selection may require another attribute selection. For example, one computer part may require another computer part for installation. In such an instance, the configuration software preferably enforces this relationship for the end-user. These attributes and or rules may be provided by each manufacturer and/or a configuration user such as the sales channel. For example, a retail channel may provide a rule relating the compatibility of one manufacturer&#39;s product to another manufacturer&#39;s product. 
     Once the end-user&#39;s selections are complete and the configuration rules are satisfied, a proposal, quote, contract, and/or specification associated with the system may be automatically generated, and/or the system may be built in accordance with the selected configuration parameters (block  312 ). For example, the computer may be assembled (or selected from inventory) and delivered to the customer. 
     In summary, persons of ordinary skill in the art will readily appreciate that methods and apparatus for maintaining businesses rules in a configuration system have been provided. The foregoing description has been presented for the purposes of illustration and description. It is not intended to be exhaustive or to limit the invention to the exemplary embodiments disclosed. Many modifications and variations are possible in light of the above teachings. It is intended that the scope of the invention be limited not by this detailed description of examples, but rather by the claims appended hereto.