Configurator using structure to provide a user interface Number:7,386,832 from the United States Patent and Trademark Office (PTO) owispatent A method and apparatus system for generating a configurator. According to one embodiment of the invention, a customizable product class is created. The customizable product class includes a set of one or more attributes to define the customizable product class. A component product class is added to the customizable product class, where the component product class is a subclass of the customizable product. A customizable UI is mapped to the customizable product class, where the customizable UI provides access structure to the configurator.<H Configurator, interface, Configurator, us, 7386832.html, Patent, pto, 7386832

Title: Configurator using structure to provide a user interface

Abstract: A method and apparatus system for generating a configurator. According to one embodiment of the invention, a customizable product class is created. The customizable product class includes a set of one or more attributes to define the customizable product class. A component product class is added to the customizable product class, where the component product class is a subclass of the customizable product. A customizable UI is mapped to the customizable product class, where the customizable UI provides access structure to the configurator.

Patent Number: 7,386,832 Issued on 06/10/2008 to Brunner, et al.

Inventors: Brunner; Stephan (Lafayette, CA), Kibilov; George (Santa Clara, CA), Rassi; Elie (San Francisco, CA), Tchikowani; Eugene (Cupertino, CA), Yao; Xiangyang (Cupertino, CA), Lim; Peter (Redwood City, CA)
Assignee: Siebel Systems, Inc. (San Mateo, CA)

Appl. No.: 09/945,448

Filed: August 31, 2001

Current U.S. Class: 717/104 ; 717/107; 717/121

Field of Search: 717/107,113,100

References Cited [Referenced By]

U.S. Patent Documents


5434791	July 1995	Koko et al.
5630025	May 1997	Dolby et al.
5867709	February 1999	Klencke
5877966	March 1999	Morris et al.
6035305	March 2000	Strevey et al.
6052669	April 2000	Smith et al.
6064982	May 2000	Puri
6167383	December 2000	Henson
6300948	October 2001	Geller et al.
6513152	January 2003	Branson et al.
6721817	April 2004	Khosrowpour
6754885	June 2004	Dardinski et al.
6779155	August 2004	Bahrs et al.
6853978	February 2005	Forth et al.
2001/0049644	December 2001	Webb et al.
2002/0010655	January 2002	Kjallstrom
2002/0042755	April 2002	Kumar et al.
2002/0052799	May 2002	Starikov
2002/0062475	May 2002	Iborra et al.
2002/0099617	July 2002	Fogelson
2005/0102199	May 2005	Lee

Foreign Patent Documents


WO 00/36544	Jun., 2000	WO
WO 01/29687	Apr., 2001	WO

Other References

EP Search Report, mailed Jul. 14, 2005, 3 pages. cited by other .
PCT Search Report PCT/US02/27650, mailed Feb. 25, 2003, 4 pages total. cited by other .
Gorti, S. R., A. Gupta, G. J. Kim, R. D. Sriram, and A. Wong (1998), "An ObjectOriented Representation for Product and Design Process", To appear in ComputerAided Design. http://citeseer.ist.psu.edu/gorti97objectoriented.html. cited by other .
Naughton, Patrick, et al. "Java2:The Complete Reference," Third Edition, 1999, pp. 131-137 and 191-197, 17 pages total. cited by other .
Washington, Natasha, "Furniture Consultants Assist Buyer Customers," The Saturday Oklahoma, Saturday City Edition, Apr. 3, 1999, 3 pages. cited by other.

Primary Examiner: Zhen; Wei
Assistant Examiner: Chow; Chih-Ching
Attorney, Agent or Firm: Campbell Stephenson LLP

Claims

What is claimed is:

1. A computer-implemented method comprising: generating a customizable product configurator, said generating comprising creating a customizable product class, wherein the customizable product class comprises a set of one or more attributes to define the customizable product class; adding a component product class to the customizable product class, wherein the component product class is a subclass of the customizable product class, and the component product class comprises customizable class rules; and mapping a customizable user interface (UI) to the customizable product class, wherein the customizable UI provides an access structure to the customizable product configurator, elements of the customizable UI access structure correspond to elements of the customizable product class, the customizable product class is configured to represent a customizable product, and the component product class is configured to represent one or more components of the customizable product; and generating a configurator user interface with HTML, Applets, and ActiveX programming languages, wherein said generating uses the customizable UI.

2. The method of claim 1 wherein the component product class includes component product subclasses.

3. The method of claim 1 wherein the component product class inherits the attributes of the customizable product class.

4. The method of claim 1 wherein said generating further comprises: adding one or more component product classes to a port; and adding the port to the customizable product class, wherein the port allows the coufigurator to classify a group of component products.

5. The method of claim 4, wherein the port comprises a cardinality attribute, and the cardinality attribute constrains the number of component products to be added by the configurator.

6. The method of claim 5, wherein the cardinality attribute comprises a minimum cardinality and a maximum cardinality, the minimum cardinality constrains the minimum number of component products to be added by the configurator, and the maximum cardinality constrains the maximum number of component products to be added by the configurator.

7. The method of claim 5, wherein the cardinality attribute comprises a default cardinality, and the default cardinality defines a quantity of the component product class added by the configurator.

8. The method of claim 1 wherein the mapping comprises: building the customizable UI from a set of themes, groups, and controls.

9. The method of claim 8 wherein a theme of the set of themes, groups, and controls comprises one or more of tabs and wizards.

10. The method of claim 8 wherein each theme in the set of themes, groups, and controls comprises at least one of the set of background colors, fonts, and multi-linguals.

11. The method of claim 8 wherein a control of the set of themes, groups, and controls comprises one or more of a drop down box, a radio button, and a list box.

12. The method of claim 1 further comprising: generating a user interface for the component product class using the customizable UI.

13. The method of claim 1 wherein the customizable UI is a subclass of the customizable product class. said generating uses the customizable UI.

14. The method of claim 1, wherein the component product class comprises a static attribute, and the static attribute is not associated with a parent class.

15. The method of claim 1 wherein the component product class, customizable class rules, and customizable UI are object oriented classes.

16. The method of claim 1 wherein the customizable product has an object oriented structure.

17. The method of claim 1 wherein the customizable product includes versioning.

18. The method of claim 1 wherein the configurator is stored in a data store.

19. A computer-readable storage medium that provides instructions, which when executed by a set of one or more processors, cause the set of processors to perform operations comprising: generating a customizable product configurator, said generating comprising creating a customizable product class, wherein the customizable product class comprises a set of one or more attributes to define the customizable product class; adding a component product class to the customizable product class, wherein the component product class is a subclass of the customizable product class, and the component product class comprises customizable class rules; and mapping a customizable UI to the customizable product class, wherein the customizable UI provides an access structure to the configurator, elements of the customizable UI access structure correspond to elements of the customizable product class, the customizable product class is configured to represent a customizable product, and the component product class is configured to represent one or more components of the customizable product; and generating a configurator user interface with HTML, Applets, and ActiveX programming languages, wherein said generating uses the customizable UI.

20. The computer-readable storage medium of claim 18 wherein the component product class includes component product subclasses.

21. The computer-readable storage medium of claim 19 wherein the component product class inherits the attributes of the customizable product class.

22. The computer-readable storage medium of claim 19 further provides instructions that cause the set of processors to perform operations comprising: adding one or more component product classes to a port; and adding the port to the customizable product class, wherein the port allows the configurator to classify a group of component products.

23. The computer-readable storage medium of claim 22, wherein the port comprises a cardinality attribute, and the cardinality attribute constrain the number of component products to be added by the configurator.

24. The computer-readable storage medium of claim 22, wherein the cardinality attribute comprises a minimum cardinality and a maximum cardinality, the minimum cardinality constrains the minimum number of component products to be added by the configurator, and the maximum cardinality constrains the maximum number of component products to be added by the configurator.

25. The computer-readable storage medium of claim 22, wherein the cardinality attribute comprises a default cardinality, and the default cardinality defines a quantity of the component product class added by the configurator.

26. The computer-readable storage medium of claim 19 further providing instructions for the mapping comprising: building the customizable UI from a set of themes, groups, and controls.

27. The computer-readable storage medium of claim 26 wherein a theme of the set of themes, groups, and controls comprises one or more of tabs and wizards.

28. The computer-readable storage medium of claim 26 wherein a theme of the set of themes, groups, and controls comprises one or more of background colors, fonts, and multi-linguals.

29. The computer-readable storage medium of claim 26 wherein a control of the set of themes, groups, and controls comprises one or more of a drop down box, a radio button, and a list box.

30. The computer-readable storage medium of claim 19 that further provides instructions causing the set of processors to perform operations comprising: generating a user interface for the component product class using the customizable UI.

31. The computer-readable storage medium of claim 19 wherein the customizable UI is a subclass of the customizable product class.

32. The computer-readable storage medium of claim 19, wherein the component product class comprises a static attribute, and the static attribute is not associated with a parent class.

33. The computer-readable storage medium of claim 19 wherein the component product class, customizable class rules, and customizable UI are object oriented classes.

34. The computer-readable storage medium of claim 19 wherein the customizable product has an object oriented structure.

35. The computer-readable storage medium of claim 19 wherein the customizable product includes versioning.

36. The computer-readable storage medium of claim 19 wherein the configurator is stored in a data store.

37. An object oriented configurator comprising: a processor; a memory coupled to the processor; a customizable product class stored in the memory; a component product class, wherein the component product class is a subclass of the customizable product class, and the component product class inherits a set of one or more attributes from the customizable product class; and a customizable UI, wherein the customizable UI is mapped to the customizable product class providing a view of the component product, the customizable UI provides an access structure, the customizable product class is configured to represent a customizable product, and the component product class is configured to represent one or more components of the customizable product; wherein the customizable UI map comprises HTML, Applets, and ActiveX components.

38. The object oriented configurator in claim 37 further comprising: a port comprising a set of one or more component products of the component product class.

39. The object oriented configurator in claim 38, wherein the port comprises a cardinality, and the cardinality constrains the number of component products to add to the customizable product class.

40. The object oriented configurator in claim 39, wherein the cardinality attribute comprises a minimum cardinality and a maximum cardinality, the minimum cardinality constrains the minimum number of component products to be added by the configurator, and the maximum cardinality constrains the maximum number of component products to be added by the configurator.

41. The object oriented configurator in claim 39, wherein the cardinality comprises a default cardinality, and the default cardinality defines a quantity of the component product class added by the configurator.

42. The object oriented configurator in claim 37 wherein the customizable class rule, and customizable UI are subclasses of the customizable product class.

43. The object oriented configurator in claim 37, wherein the component product class comprises a static attribute, and the static attribute is not inherited from a parent class.

44. The object oriented configurator in claim 37 wherein the attribute is of type string, number, date, and Boolean.

45. The object oriented configurator in claim 37 further comprising a second customizable product class.

46. The object oriented configurator in claim 45 wherein the second customizable product class comprises one or more component products of the component product class.

47. The object oriented configurator in claim 37 wherein a component product of the component product class includes an expression to restrict the component product from becoming a subclass of the customizable product class.

48. The object oriented configurator in claim 37 further comprising: a script configured to communicate with another application.

49. The object oriented configurator in claim 37 wherein the customizable UI includes a theme, group, and control.

50. The object oriented configurator in claim 37 wherein the theme includes one or more of a tab, wizard, font, and color.

51. The object oriented configurator in claim 37 wherein the control includes one or more of a drop down box, a radio button, and a list box.

52. The object oriented configurator in claim 45 wherein each component product class has an unique identifier, the unique identifier is used to locate an associative component product.

53. The object oriented configurator in claim 45 further comprising link items.

54. An apparatus comprising: a processor; means for generating a customizable product configurator using the processor, said means for generating comprising means for creating a customizable product class, wherein the customizable product class comprises a set of one or more attributes to define the customizable product class; means for adding a component product class to the customizable product class, wherein the component product class is a subclass of the customizable product class, and the component product class comprises customizable class rules; and means for mapping a customizable UI to the customizable product class, wherein the customizable UI provides an access structure to the configurator, elements of the customizable UI access structure correspond to elements of the customizable product class, the customizable product class is configured to represent a customizable product, and the component product class is configured to represent one or more components of the customizable product; and means for generating a configurator user interface with HTML, Applets, and ActiveX programming languages, wherein said generating uses the customizable UI.

55. The apparatus of claim 54 wherein the component product class includes component product subclasses.

56. The apparatus of claim 54 wherein the component product class inherits the attributes of the customizable product class.

57. The apparatus of claim 54 wherein said means for generating further comprises: means for adding one or more component product classes to a port; and means for adding the port to the customizable product class, wherein the port allows the configurator to classify a group of component products.

58. The apparatus of claim 55, wherein the port comprises a cardinality attribute, and the cardinality attribute constrains the number of component products to be added by the configurator.

59. The apparatus of claim 58, wherein the cardinality attribute comprises a minimum cardinality and a maximum cardinality, the minimum cardinality constrains the minimum number of component products to be added by the configurator, and the maximum cardinality constrains the maximum number of component products to be added by the configurator.

60. The apparatus of claim 58 wherein the cardinality attribute comprises a default cardinality, and the default cardinality defines a quantity of the component product class added by the configurator.

61. The apparatus of claim 54 wherein the means for mapping comprises: means for building the customizable UI from a set of themes, groups, and controls.

62. The apparatus of claim 61 wherein a theme of the set of themes, groups, and controls comprises one or more of tabs and wizards.

63. The apparatus of claim 61 wherein each theme in the set of themes, groups, and controls comprises at least one of a set of background colors, fonts, and multi-linguals.

64. The apparatus of claim 61 wherein a control of the set of themes, groups, and controls comprises one or more of a drop down box, a radio button, and a list box.

65. The apparatus of claim 54 wherein the means for generating further comprises: means for generating a user interface for a component product class using the customizable UI.

66. The apparatus of claim 54 wherein the customizable UI is a subclass of the customizable product class.

67. The apparatus of claim 54, wherein the component product class comprises a static attribute, and the static attribute is not associated with a parent class.

68. The apparatus of claim 54 wherein the component product class, customizable class rules, and customizable UI are object oriented classes.

69. The apparatus of claim 54 wherein the customizable product has an object oriented structure.

70. The apparatus of claim 54 wherein the customizable product includes versioning.

71. The apparatus of claim 54 wherein the configurator is stored in a data store.

Description

FIELD OF THE INVENTION

The invention relates to the field of computing. More specifically, the invention relates to the generation of and provisioning of customizable products.

BACKGROUND OF THE INVENTION

The Internet has provided new opportunities for most companies to advertise and sell products to a multitude of consumers, however, companies that sell complex or customizable products still face significant challenges. Customizable products are products that are made up of other products or component products. Component products typically complement each other in creating the customizable product, potentially allowing consumers to receive discounted pricing when the components are purchased as a group.

Computer companies, for example, may sell disk drives and monitors as well as other types of computer components. These companies may also group computer components together to form computer systems at discounted prices. Customers who want to buy a computer system can select among several alternatives for each component. For example, the company may provide three monitors for the customer to choose from when buying a desktop computer. As the number of components making up the customizable product increase, the more complex the decision making process is for the consumer to determine which components to select.

Most businesses are supported by attentive sales professionals who help the customer select the product, or combination of products, that best meet their specific requirements. Buying and selling over the Internet is more problematic because an expert sales professionals is not available to guide customers to choose the right product. Providing online access to product information for each sub-component without an explanation of how the components interrelate is not enough. Customer loyalty can be very fleeting in today's highly competitive online environment and frustrated customers can easily look for alternatives at a competitor's web site. Preferably, businesses utilize, fully integrated processes and systems that can handle consultative selling, intricate configurations, and complicated product relationships and options.

To achieve this, organizations in all industries are increasingly using product and service configurators. A configurator is a software tool developed by the product or service provider, that allows customers to find the products that suit their unique requirements. In some cases, configurators are integrated with a set of business rules that help guide the customer as would a sales professional.

Today, however, configurators are simply point products that do not fully address the needs of organizations with complex, multichannel sales environments, and application integration requirements. These configurators often use complex procedural programming based modeling tools, to define product relationships and business rules, that are difficult to use, costly to maintain, and hard to upgrade.

These configurators are treated essentially as big shopping carts containing a bunch of pre-defined "bags", one for every possible component product. Consequently, the supported configuration rules only provide constraints to the total amounts of each component product to be added. Therefore, there are many configurators with configuration rule semantics which cannot be implemented well in such a weakly structured framework.

For example, suppose a configurator consists of computers and power supplies, where every computer must have a power supply. And further suppose that U.S. computers require 110V power supplies while European computers require 220V power supplies. Here, current configurators have difficulty correctly modeling, for instance, an order having two computer systems, one for each locale. If a configuration rule denotes that mismatched computers and power supplies must exclude each other, then neither of the desired computer systems may be placed together in the same order. Yet if such a configuration rule did not exist then it would incorrectly allow configuring incompatible single systems. This is ultimately because the products are just "bagged together."

Another problem with procedural programming based configurators is the lag-time taken in making changes to the configurator. Configurators are normally designed and modeled with the help of an expert for the product being sold. Configuration experts, such as a sales professional or a product manager, explain to the software designer, the relationships between the component products in making the customizable product. Software engineers then program the software to present the products to the customer.

In many cases, the updating of a configurator consists of the software engineer(s) receiving the requested configurator changes from various configuration experts. The software engineer then reprograms the new components and/or configuration rules into the procedural programming-oriented source code of the configurator software. Therefore, there is usually a significant lag-time between a requested change to the configurator business model, and the time the software engineer reprograms the software.

Significant programming lag-time results in inaccessible and inaccurate information that extends sales cycles, increases the percentage of inaccurate quotes and orders, raises costs due to a greater number of returned items, and delays the timing in bringing new products to market. These inefficient and unreliable configurators often result in lost revenues and dissatisfied customers. As the rate of new customizable and component products increases these problems proliferate.

BRIEF DESCRIPTION OF THE DRAWINGS

The invention may best be understood by referring to the following description and accompanying drawings that are used to illustrate embodiments of the invention. In the drawings:

FIG. 1 illustrate a block diagram of the modeling of an object oriented configurator according to one embodiment.

FIG. 2 illustrates a class hierarchy with defined attributes for a customizable product according to one embodiment.

FIG. 3 illustrates an exemplary class hierarchy including port attributes according to one embodiment.

FIG. 4 illustrates several combinations for setting cardinality according to one embodiment.

FIG. 5 illustrates the customizable UI class hierarchy according to one embodiment.

FIG. 6 illustrates a block diagram of the creation of a UI for using defined customizable class structures according to one embodiment.

FIG. 7 illustrates a data store for various components of the configurator according to an embodiment.

FIG. 8 illustrates a medium or media useful for an embodiment of a process to generate a customizable product configurator.

DETAILED DESCRIPTION OF THE INVENTION

A method and apparatus to generate a customizable product configurator is described. In the following description, numerous specific details are set forth to provide a thorough understanding of the invention. However, it will be understood that the invention may be practiced without these specific details. In other instances, well-known circuits, structures and techniques have not been shown in detail in order not to obscure the invention.

The techniques shown in the figures can be implemented using code and data stored and executed on a computer. Such computers store and/or communicate (internally and with other network elements over the network) code and/or data using machine-readable media, such as magnetic disks; optical disks; random access memory; read only memory; flash memory devices; electrical, optical, acoustical or other form of propagated signals (e.g., carrier waves, infrared signals, lasers, digital signals, etc.); etc. Of course, one or more parts of the invention may be implemented using any combination of software, firmware, and/or hardware.

In one embodiment, the customizable product configurator is derived from an object oriented class hierarchy by a relational set of customizable and component classes (e.g. products or services) as will be further described. In one embodiment, the customizable product class includes attributes that defines the base structure of the customizable product. Component products, customizable class rules, and customizable user interface (UI) classes may be modeled as subclasses to, and inherit attributes from, the customizable product class. An instance of a customizable object may be generated from these classes when a consumer builds an instance of a customizable product.

In one embodiment, the configurator process is separated into two distinct sessions, the modeling session and runtime session. During the modeling session, a configuration expert (e.g. sales professional or product manager) designs the configurator. FIG. 1 illustrates a block diagram of the modeling of an object oriented configurator according to one embodiment of the invention. At block 110, a new customizable product is created with defined attributes and control passes to block 120. At block 120, the new customizable product is assigned to a class and control passes to block 130. This becomes the parent class in the customizable product class hierarchy.

At block 130, component products are added to the customizable product class and control passes to block 140. The component products are subclasses and inherit the attributes of the customizable product class. At block 140, customizable rules are added to the customizable product class structure and control passes to block 150. Here, the customizable rule may be designed by configuration experts, defining conditions and triggering actions between the component products that ensure the consumers purchase the optimal solution that meets their needs.

At block 150, the customizable UI is mapped to the customizable product class structure, thereby allowing the configuration expert to tailor the user interface of component products to the customizable product. Finally, at block 160, the configurator is released to a runtime session, allowing a consumer to build a customizable product.

As will be appreciated, the object oriented nature of the modeling session, such as the inheritance of class attributes and rules, lessens the complexity of building the configurator, allows for a configuration expert to make necessary changes to the configurator, and reduce the lag time from modeling to runtime.

During the runtime session, a consumer (e.g. one wanting to build a customizable product) accesses the configurator designed by the configuration expert to build a customized product or service. In one embodiment, the building of a customizable product is performed by the consumer through the UI designed for the specific customizable product class selected by the consumer. Upon, selecting specific component products or groups of component products to the customizable product class, other component products may be automatically added or restricted due to the rules defined, as will be further described. In one embodiment, a sales professional may also access the runtime configurator to help a consumer find the right product for their needs. In this way, the configuration expert has the most up-to-date products and quote list to design a customizable product.

Although the following will be described in relation to products (e.g. customizable products, component products, etc.), it should be understood that the customizable product configurator described is not limited to only products and may be used to customize other instances (e.g. services). In addition, alternative embodiments of the configurator may also comprise any number of various types of products or services such as literature and contracts, and is not limited to those examples described herein.

In one embodiment, the customizable product configurator is generated from customizable product classes and subclasses that are organized into the customizable product hierarchies. The customizable product classes defined during the model session may represent any number of instances (e.g. a computer system instance, a car instance, for example) or types of instances (e.g. Model X computer system, Model Y computer system, for example). In one embodiment, when a customizable product class is designed, the customizable product class name attribute is unique and the customizable product class name is added to a set of available customizable classes. Thereafter, all of the associated component products, customizable class rules, and customizable UIs designed become subclasses to the customizable product class.

FIG. 2 illustrates a class hierarchy with defined attributes for a customizable product according to one embodiment. Here, the customizable product classes are modeled as PCs 210 with attribute Cabinet 212, Cards 220 with attribute Size 222, HD 230, and Cables 240 with attribute Color 242.

The PCs 210 has a component product subclasses defined as Fast PCs 250 with attributes Memory 252 and Cabinet 254. The Cards 220 have two component product subclasses defined as Video Cards 260 and Sound Cards 270. The Video Card 260 has attribute Size 262 and Sound Cards 270 has attributes Surround 272 and Size 274. The HD 230 has a component product subclass defined as SCSI 280 with a defined attribute RPM 282.

Typically, a class hierarchy consists of classes and subclasses. Subclasses are classes that are defined within another class. For example, in FIG. 2, Video Cards 260 and Sound cards 270 are subclasses of the customizable product class Cards 220 which would inversely be the parent class of Video Cards 260 and Sound cards 270. Subclasses always have a parent class and classes can be nested to as many levels as needed. In one embodiment, the classification scheme used for setting up a customizable product class hierarchy depends on the product line, the business processes, and the marketing and selling to be customized. For example, one could create a customizable product class called disk drives that contains all the disk drives in a product line. The key characteristic of a component product class is that membership is species-based. All the members are the same species. For example, all the members of class HD 230 are disk drives.

In one embodiment, component product classes are the related products associated to a customizable product class. That is, component products make the customizable product customizable. A component product class may be added to the customizable product class one at a time, or as a group. For example, a car may be defined as a customizable product class having a car tire defined as a component product class. The car tire may be added one at a time, or a group of four tires may be added at once.

Similarly, in one embodiment, a component product class may also include other customizable products. In this way, a customizable product is a sub-assembly that is included as a component product in a final customizable product. For example, assume that a configurable power supply and a configurable gearbox are sold as part of an industrial lathe. One customizable product may be created for configuring the power supply and one for configuring the gearbox. Then both of these component customizable products may be added to the industrial lathe customizable product as subclasses.

In one embodiment, when a component product class is defined as a subclass, of a specified parent class (e.g. customizable product class or other component product class) the parent class is defined within the parent class attribute of the subclass. When a component product class is added to a customizable product class hierarchy, it automatically inherits all the attributes of the parent class or classes. Customizable product classes let you define what attributes are maintained for component product classes, propagate those attributes to the component product classes, and maintain those attributes in a consistent fashion.

Each customizable product class is associated with a collection of attributes during modeling. Attributes are the defined types of information to be captured and maintained about the customizable product classes and subclasses, and the component product classes and subclasses. In one embodiment, each attribute has a name or identifier, a data type, and a value from a specified domain or range.

When an attribute for a customizable product class or subclass is defined, the attribute is inherited by all its member component product classes and all member subclasses. In one embodiment, attributes are defined at the customizable product class level but not at the component product class level. For example, in FIG. 2, the Fast PCs component product subclass has defined attribute Cabinet 254 which is inherited from the attribute Cabinet 212 in the parent class PCs 210.

Defining attributes at the customizable product class or subclass level allows the creation and management of attributes for a plurality of component objects to be more efficient. Also, the customizable product classes provide a central location for propagating attributes to component products and shuffling attributes between customizable product classes during the building and revising of the class hierarchy.

It will be appreciated, however, that attributes need not only be defined at the customizable product class level, and in alternative embodiments attributes may also be defined at the component class level. In one embodiment, when an attribute is defined at the component class level, the attribute is static and does not inherit from its parent class. Here for example, in FIG. 2, the value stored in the attribute Cabinet 254 of the subclass Fast PCs 250 would be different from the value stored in attribute 212 of the parent class PCs 210.

Also, the Memory 252 attribute defined only for the subclass Fast PCs 250 is another example of an attribute defined solely for the subclass and not the parent class. When a new attribute is explicitly defined for a customizable or component product subclass, it is said to "shadow" the inherited attribute.

In one embodiment, each customizable product class is associated with a predefined set of attribute-value pairs. The value of the attribute is assigned at the component product class object level. The predefined set of attribute-value pairs store the run-time session data about that customizable product class and its relationship to other customizable product classes. Therefore, values of attributes may vary from component product class to component product class in the customizable product class.

In one embodiment, attribute data types include: Numbers, Integer, Floating-point, Enumeration, String, Date, Time, Currency, Phone, Boolean, etc. In one embodiment, attributes whose values are quantitative have an associated data type. That is, only quantities of a specific data type appears as the value of an attribute. The value of the attribute may also be for a quantity (of various data types) or a group consisting of a group of component product classes within the customizable product class. Attributes whose values are groups of component product classes are called ports as will be further described below.

In one embodiment, a domain of allowable values for an attribute may be defined. Attributes can have three types of domains: a single value, a list of values, or a range of values for an attribute. For example, an attribute called Color could have the domain red, green, blue. In one embodiment, a default value of the attribute may be defined.

Attributes can be further classified in various ways. In one embodiment, attributes are divided into fixed and dynamic attributes. Fixed attributes' values are completely determined within the modeling session, while dynamic attributes' values are determined during the runtime session.

In one embodiment, the component product classes may be grouped together into a list of component products or ports. All component product classes contained in a port are of the same type. The port can be characterized by the number of component products it contains. Port attributes, whose values are groups of component product classes, are typed with a customizable product class. Only component product classes that are a subclass of a customizable product class may appear in the group of values for that attribute.

FIG. 3 illustrates an exemplary class hierarchy including port attributes according to one embodiment of the invention. FIG. 3 contains the Fast PCs 310 component product which is a subclass of My PC 305 with the defined attributes of Memory 319 and Cabinet 322. Two ports, PCI Slots 311 and HD Bays 315 are also included. Here, the PCI Slots 311 and HD Bays 315 represent that the Fast PCs 310 may be customized with multiple PCI Slots and Hard Drive Bays. The attributes of these ports also describe the cardinality (elements 312 and 316), the domain values (elements 313 and 317) type of component products types which may be associated with the port, and the default domain value (elements 314 and 318). Here, the cardinality value 312 defines that the PCI Slots 311 may have 0 to 2 of the domain value 313 defined as cards installed with no default domain value 314 defined. The cardinality value 316 defines that the HD Bays 315 may have 1 to 4 of the domain value 316 defined as SCSI hard drives installed with the default domain value 318 defined to be 10 Gig. Further description of the use of cardinality is described below. The attribute Memory 319 has domain values 320 defined as 128 and 256, with the default value 321 defined as 256. The attribute Cabinet 322 has the domain value 323 defined as DT or MT, with the default value 324 defined as MT.

FIG. 3 also describes the types of cards which may be installed in the PCI slots. Here, Video Cards 342 are a subclass of class 3D 340 cards and Sound Cards 352 are a subclass of class Super Sound 350. Both Video Cards 342 and Sound Cards 352 are ports of cards which may be installed in the PCI slots. The Video Cards 342 also has defined another port Cable 343 and an attribute Size 347. The attribute Size 347 has the domain values 348 defined as short or long, with the default value 349 defined as short.

The Sound Cards 352 subclass has the attributes Size 353 and Surround 356 defined. Size 353 has the domain values 354 defined as short or long, with the default value 355 defined as short. Surround 356 (e.g. surround sound) has the domain value 357 defined as yes or no, with the default value 358 defined as yes.

As described above, the port Cable 343 contains attributes which describe the types of component product classes which may be associated with the port. Here, the Cardinality 344 is defined to include one of the domain value 345 defined as cables. Here, the default value 346 is defined to the port Video 380. The port Cable 343 is then associated with the Cables 382 subclass of Video 380, which contains the attribute Color 383 having the domain values 384 defined as red and green, with default value 385 defined as red.

Returning to the description of the HD Bays 315, the port includes a SCSI 362 subclass to 10 Gig 360 with the attribute RPM 363 defined and SCSI 372 subclass to 20 Gig 370 with the attribute RPM 373 defined. Both attributes RPM 363 and RPM 373 have domain values 364 and domain values 374 defined as 4500 and 7200, with both default value 365 and default value 375 defined as 7200.

In one embodiment, ports are generally inclusive by default, but also may be defined as exclusive, which means that any component product class which appears in that port will not appear in the ports of any other component product class object (however it may appear in other ports of that same component product class).

Pairs of port properties can also be defined as inverses. A port which is one of the attributes of an inverse pair will only contain component product classes which possess the other attribute in that pair. For example: if Husband and Wife are defined to be inverse properties and if, for instance, John's Wife is Mary then Mary's Husband is John.

It should be understood that inverse properties can be one-to-one, as in the example above, or they can be many-to-one, one-to-many or many-to-many. No matter how many classes are involved, an inverse port essentially defines just two sets of component product classes, such that each set appears as the value of the corresponding attribute for every member of the other set. For a many-to-many example: Sellers and Buyers might be defined as inverses. Then each Seller would have access to the common group of Buyers, and each Buyer would have access to the common group of Sellers. In one embodiment, the ports in an inverse property pair can each be independently defined as either inclusive or exclusive.

For a one-to-many example with both inclusive and exclusive ports, the wheels port of a car should be exclusive, so that the four wheels belong to just a single car, but the car port of each wheel would need to be inclusive, so that all the wheels could be attached to the same car.

In one embodiment, ports have cardinality. When a port is defined a minimum, maximum, and default cardinality may be specified. Cardinality refers to the quantity of the component product class a consumer can select from a port during the runtime session. For example, assume a port called Hard Drives is defined. It contains a 20 GB drive and a 30 GB drive. If the minimum cardinality is set to 2, the consumer must pick 2 items from this port. The consumer can do this in any of the following ways: Pick one 20 GB drive and one 30 GB drive; Pick two 20 GB drives; or Pick two 30 GB drives.

In one embodiment, there are three types of cardinality: minimum, maximum and default. FIG. 4 illustrates several combinations for setting cardinality according to one embodiment of the invention. The figure describes what will be displayed initially to the consumer in the configurator and the actions the consumer may perform according to one embodiment. N is the quantity of the default component product class in the configurator. In all the cases where the minimum cardinality is greater than 0, the consumer may substitute other component products for the default product.

The minimum cardinality governs whether or not selecting component product classes from the instance port is optional or is required. If the minimum cardinality is set to 0, selecting component product classes is optional. If the minimum cardinality is set greater than 0, the selected number of component product classes from the port must be selected.

The maximum cardinality sets the maximum number of component product classes that the user can select from a port during the runtime session. If the minimum cardinality is set greater than zero, the maximum cardinality must be set to a number at least as large.

The default cardinality specifies what quantity of the default component product class is automatically added to the initial configuration during the runtime session. In one embodiment, default cardinality must be equal to or greater than the minimum cardinality and must be less than or equal to the maximum cardinality.

In one embodiment, a component product class includes a collection of expressions, called the customizable class rules. The customizable class rules define constraints on component products. It is through the customizable class rules that the configuration expert helps guide the consumer to choose the appropriate product(s) for their needs. Here, the customizable class rules may be defined to require or exclude the selection of one or more component products upon the selection of a specific component product, or the customizable class rule may trigger the prompting of recommendations messages when a particular component product is selected. For example, a customizable class rule may be created that requires a specific monitor card when a specific type of monitor is selected during the runtime session by a consumer. In one embodiment, the required monitor card is automatically added to the runtime session of the configurator when the consumer selects that monitor.

In one embodiment, customizable class rules are inherited, but unlike attributes, the collection of customizable class rules are not named and do not shadow. However, it should be understood that in some embodiments customizable class rules may be named and/or may be shadowed. If a component product class adds new customizable class rules they simply "accumulate" downwards in the class hierarchy. A subclass possesses all the customizable class rules of its parent class, plus any new customizable class rules added by that subclass.

As stated above, the customizable class rule has a collection of expressions. In one embodiment, an expression is a template composed of property paths and constants that are combined together with operators. Expressions can be evaluated to implement customizable class rules constraints during the runtime session. Each evaluation is performed in some particular context, which resolves the meaning of any free references made in the expression. The nature of the constraints produced by an expression depend on the environment in which the expression is evaluated.

In one embodiment, configuration experts build customizable class rules by natural language templates. Here, templates are fill-in-the-blank natural language sentences that configuration experts complete using rule builder tools. Their purpose is to completely shield the configuration experts from customizable class rule assembly language which may need to be modified by a software engineer. The natural language template may use easy to understand and fully internationalizable natural language sentences that an configuration expert may implement. Some examples of template expressions are:

"Component Product 1 requires Component Product 2"

"Make sure that the quantity of a component product is less than a number"

"If the customer picks more than 50 of a component product, then include the Good Customer Bonus Pack for free"

"Add the quantities of one component product and another component product and then subtract the total from the quantity of a third component product"

"Sum of a number and a number"

"Product of a number and the absolute value of a number"

Configuration experts may select a natural language template and then fill in the blanks with defined classes and attributes (e.g. component classes and attributes), math expressions, or other templates. Then, the natural language customizable class rules are converted into a low-level rule assembly language. Here, a combination of math expression builders and natural language phrase builders may be used to let configuration experts create complex rules with minimal typing.

In one embodiment, batch customizable class rules may be used, which allow configuration experts to enter lists of values to fill in the blanks of any template in one step. Batch rules are particularly useful for creating large numbers of rules for a single component product class. Also, predicate-based customizable class rules design may be used, allowing configuration experts to build large customizable class rule sentences by combining condition and action phrases. For example, "If a user picks Computer X And configurator contains 3 of Software Titles And Account Type=="Good Customer" Then autopick free upgrade And autopick promo mousepad Except when attribute Shipping destination is Texas".

It should be understood that although various rule builder have been described the invention is not limited to any type of rule builder whether using natural language or low-level rule assembly language. In one embodiment, all templates and translations are defined in the database. This way, configuration experts may add any proprietary and non-proprietary templates using any template designer tool without limiting the invention.

As stated above, an expression may be partially composed of property paths. A property path refers to the attributes of component product classes which may appear during a runtime session in the ports of other component product classes (and may themselves contain yet other component subclasses, etc). For example, ports in a configuration such as

My Printer

My Printer's Power Cord

My Printer's Power Cord's Wattage

. . .

Would be referred to with the following property paths that could be written as

[MyPrinter]

[MyPrinter].[Power Cord]

[MyPrinter].[Power Cord].[Wattage]

. . .

Basically a port or attribute may be referred to (in this notation) by the name of the port or attribute, prefixed by a path that accesses the class of interest having that port or attribute. In these examples, the base access path is the port [MyPrinter] which is assumed to refer to some group of printers.

A base path must always be interpreted with respect to a context defined by some particular product class. How the context is determined will be discussed further below. If the base path accesses a group of product classes (such as the value of a port, or a subclass subgroup of a port) then a port (such as [Power Cord] above, which is assumed to be an subclass of [MyPrinter]) can be referred to by appending the name of the port to the path.

If a path accesses an attribute which is also a port then additional facilities exist to allow access to the members of that port, their members, etc. First, attributes of component product classes in the port can be referred to by further extending the path (as with [Wattage] above, which is an attribute of [Power Cord]).

Second, since in one embodiment, the value of a port is always a group of component product classes then any subclass can be accessed simply by qualifying the port name with the subclass name. For example:

[MyPrinter]:[HP LaserJet].[PowerCord]

refers to the subclass of power cords of just the HP laser printers.

Third, the individual members of the group can be accessed by appending the index of the member. For example,

[MyPrinter]#2.[PowerCord]

refers to the power cord(s) attached to the second printer in the group.

These access paths can be freely combined and extended to any degree (always reading from left to right in this notation). For example,

[MyPrinter]:[HP LaserJet]#2.[Cable]:[Serial]#1

refers to the first serial cable attached to the second HP printer.

In one embodiment, any path which doesn't end by referring to an attribute value refers to a group of component product classes. It can refer to an empty port, a group with a single member, or a group with multiple members.

In one embodiment, merely referring to an empty port will not constrain the port to have any component product classes. That is, a customizable class rule about [CPU]#1000 may only be effective when the configuration is known to have at least one thousand CPUs. However, if no constraint has required that the thousandth CPU be present, then this path, by itself, will merely refer to an empty port (a port which does not have any instances in it just like any other port). Conversely, to cause a referenced component product class to exist, either the quantity of the entire group must be constrained to a sufficiently large positive value, and/or the quantity of the indexed port must be constrained to be non-zero.

In one embodiment, the attributes and ports referred to in a path must be attributes or ports that are actually defined in the class hierarchy being referred to. In order to refer to an attribute or port that is only defined for a subclass it is necessary to "downcast" the path to a subclass subgroup. In one embodiment, a "downcast" path will thus refer to an empty group when no objects of that subclass are present.

In one embodiment, new operators may be defined by assigning an expression template to an operator property. The name of an operator property may be used as an operator in expressions of any class for which that operator is defined. Here, an operator property is inherited or shadowed by subclasses. In one embodiment, an operator property is similar to procedures and methods in object-oriented programming. For example, a MutuallyRequires operator property may be defined as follows:

TABLE-US-00001 op MutuallyRequires (x, y) { req(x,y); req(y,x); }

With this definition, a MutuallyRequires constraint may be conveniently added by applying the operator to any two expressions of interest.

A more complex example models a MatchingProperty rule, which constrains any selections within two given categories to require matching values for some given property:

TABLE-US-00002 op MatchingProperty (catA, catB, prop) { int propValue; withParts((catA), req(%1,==(propValue, %1.prop))); withParts((catB), req(%1,==(propValue, %1.prop))); }

Although examples of the operator property have been defined using a given syntax, an alternative syntax may be used to fulfill the nature of the operator property and the invention is not limited to the syntax described.

In one embodiment, third party scripts may also be used to interface the configurator with other software applications. Here, scripts can be associated with customizable or component product classes and can be set to trigger when certain defined events occur as would customizable class rules, however, the scripts may be used to perform actions outside the configurator. In one embodiment, scripts are sequential programs which are run when certain events occur. For example, when the user selects certain component products a script may be created to add additional information in the current shopping basket or quote and/or interface with other external applications. It should be understood that although scripts and customizable class rules are described to perform different tasks, in alternative embodiments, the customizable class rules place constraints and perform sequential actions on both the configurator and other applications.
<