Patent Grant
7930149
The present invention relates to data processing, and more particularly to product modeling.
Business enterprises can generally design, build, and sell one or more products such as, for example, a car. A product such as a car can be configurable. That is, the product can have characteristics that can be varied. For example, a characteristic of a car that can vary is the number of doors. The car can be a sedan or a coupe. There are other characteristics, such as engine size, wheel size, body color, and type of seats, which are configurable.
Business enterprises can use computer systems to facilitate operations such as product design. One example of such systems is a product modeling system. Generally, product modeling of a product refers to a process, usually implemented in a computer system, which defines a model that represents the product. Defining a configurable product can include, for example, specifying characteristics, characteristic values, constraints describing dependencies of the characteristics, default values, values ranges, and other parts of the product. These items can be specified in a configuration model. The configuration model is generally some collection of this information that is needed to configure the product. The configuration model can be an element of the overall product model. The parts of the product can be specified in a product structure that can also be an element of the overall product model.
The configuration model is generally the basis for configuring of a product. For example, the configuration model can include criteria that determine the configuration of the product. Criteria can include, for example, constraints specifying that a particular type of wheel must be used for a particular type of engine.
The present invention provides methods and apparatus, including computer program products, for a multi-purpose configuration model.
In one implementation, a method for defining a configuration model for a configurable product by begins when a system receives a first input, and then defines, based on the first input, a first version of a first subcomponent to be used in the configuration model, the first version including information that describes the product. Next, the system receives a second input, and then defines, based on the second input, a second version of the first subcomponent to be used in the configuration model, the second version including information that describes the product. The system then designates one of the first or second versions to be an active version, and designates the other to be an inactive version. The system then defines, based at least in part on the active version of the first subcomponent, a first component that describes the product.
In another implementation, the system can include, as a child object of the active version of the first subcomponent, a second component, wherein the second component includes further information that describes the product and is in an active state. If the active version of the first subcomponent becomes inactive, then the second component changes to an inactive state. Similarly, the system can include, as a child object of the inactive version of the first subcomponent, a third component, wherein the third component includes further information that describes the product and is in an inactive state. If the inactive version of the first subcomponent becomes active, then the third component changes to an active state.
In yet another implementation, the first version can be active during a first promotional period, and the second version can be active during a second promotional period. Furthermore, the second version can be generated by updating the information within the first version.
Like reference numbers and designations in the various drawings indicate like elements.
Each component is formed from one or more subcomponents. Each subcomponent contains one or more elements used to define the configuration model, which can include but are not limited to characteristics of the product, characteristic values, constraints describing dependencies of the characteristics, default values, value ranges, prices of the product, costs of the product, classes, and other parts of the product.
The characteristics of the product refer to some aspect, such as “color”, of the product. Characteristic values, such as “blue”, specify the aspect. For example, blue specifies the color of the product. The constraints describe dependencies between or among characteristics. Constraints can also serve other functions. A system can, for example, determine whether an instance of a configuration model is consistent and complete. The instance is consistent if all constraints of the model are satisfied. The instance is complete if all required characteristics and elements of the configuration model are included. Constraints are further described below.
Price refers to a monetary value at which a product is sold. Cost refers to a monetary value at which the product or its components are built or procured.
A class, in this specification, refers to a collection of similar objects. Cars that have two doors, for example, can be grouped in a class called coupes. Cars that have four doors, for example, can be grouped in a class called sedans. Each component can include one or more classes. For example, a base component of a configuration model for a car can have two classes of cars, sedans and coupes. Sedans can inherit information from and add information to cars. Similarly, coupes can inherit information from and add information to cars.
The configuration model can include links such as the link 110, the link 112, and the link 114. The links, which can be pointers, associate parent object and child object components. For example, the link 110 associates the base component 102 and the component 104. Furthermore, the link 110 specifies that the component 104 is a child object of the base component 102. Links can also exist between two or more configuration models. This is described in more detail below.
Components and subcomponents can have multiple versions. A version is a particular storage state of the component or subcomponent. Documents, for example, can have different versions. The described links can associate versions of components or subcomponents. For example, the base component 102 and the component 104 can each have a first version and a second version, and the link 110 can associate the first versions of these components. The link can also associate a first version of one component with a second version of another component.
The subcomponents used to build a particular component do not necessarily have the same number of versions. Each subcomponent can have its own set of versions, and one of these versions can be used in forming the component. An example is provided in
The particular version of a component or a subcomponent that is currently being used in the configuration model can be referred to as the “active” version, as shown in
Additional components or subcomponents can be linked to the active version of a component or subcomponent, or they can be linked to an inactive version of a component or subcomponent. Any additional components or subcomponents that are linked to an active component or subcomponent are active themselves. Likewise, any additional components or subcomponents that are linked to an inactive component or subcomponent are inactive themselves. If an inactive component or subcomponent becomes active, then any additional inactive components or subcomponents that are linked to it also become active.
Versioning of components provides many advantages. Particular versions of a component can be generated for particular model configurations or selling seasons. For instance, different marketing components can be generated for normal sales periods and promotional sales periods. The use of versioning can also be advantageous when components are being updated. Often, it is not possible to take a component off-line in order to change the information contained within the component. In this situation, a different version can be generated that contains the new or updated information. Then this new version can reside in the configuration model as an inactive version. The inactive version can be tested and revised within the configuration model prior to making it the active version. Child components can inherit from their respective parent components. That is, a child component can include all characteristics of the product, characteristic values, constraints, classes, prices of the product, and costs of the product. A child component generally further adapts the configuration model. For example, a child component, such as the component 108 can add one or more characteristics not included in a parent component, such as the component 106. The child component can also add one or more constraints to those of the parent component, as long as the new constraints do not contradict the constraints of the parent component. Each of the new constraints are generally added by means of one or more subcomponents that form the child component 106. The child component can set or change default values for characteristics included in the parent component. The child component can restrict ranges of characteristic values included in the parent component.
A purpose, in the context of the specification, can be a goal or task to be completed. A purpose can be, for example, the completion of some process, such as a business process. Business processes can include processes for product design, marketing, production, sales, engineering, and so forth. A purpose can further be a goal or task to be completed by a particular entity. For example, a purpose can be a sales process of a particular sales organization.
A system that defines the configuration model 100 can present different views of the configuration model 100 to a user. The different views can include different information, depending on the purpose and, hence, the component. For example, when there are no purposes specified, the system can present a view that includes only information included in the base component. For the first purpose, the system can present a second view that includes information included in the base component 102 and the component 104.
The system can also determine which information to present to a user based on whether the user has authorization to view or change information. That is, the system can determine, based on a user's role and authorization, which component of the configuration model to use.
As shown in
Each component can also describe default values. For example, the default value for air conditioning is no, the default value for seat heating is no, the default value for airbags is driver, and the default value of seats is standard. In one implementation, default values can be inherited but cannot be overwritten.
As shown in
As shown in
As shown in
As shown in
Optionally, the system can determine whether the source of the input is authorized to request the action specified in the request is permissible. If there is no authorization, the system can deny access. If the source is authorized for the action, the system can proceed. The system can deny access based on role, authorization, or both. The system can also deny access because an object to be changed has been locked or is being modified by a different component of the configuration model.
The system checks consistency (step 704). Checking consistency includes verifying that existing constraints, ranges, and default values inherited and included in a component being changed are not violated by the action requested by the input. If the action maintains consistency, then the system changes the configuration model in accordance to the input (step 706). Otherwise, the system does not make the change and notifies the user that the input cannot be processed (step 708).
The second technique uses a table. As shown in
The third technique uses conditions to specify which characteristics require characteristic values, which characteristics are allowed to have characteristic values, and which characteristics are shown in the configuration process. As shown in the example of
In one implementation, the configuration model includes: classes, characteristics, characteristic values, constraints, a product structure, configurable products, pricing information, estimated costs, and relationships between objects besides product structure. There can be more than one configuration model used in an enterprise. Typically, configuration models encompass similar products, such as all products in a product family.
The configuration model can be linked with a master data system of a hosting system where applicable. Certain characteristics and characteristic values can refer to global definitions in the master data system. For example, a characteristic listing the customer, business partner, or other business context information of the configuration model can be linked to corresponding business objects in the master data system.
In one implementation, the system can define a way for processes connected in a process chain to communicate with each other by stipulating that a configuration passed from one process to the next must be consistent and complete with respect to a common ancestor component model. This defining is referred to, in this specification, as process completion and requires action by both processes. The process that is handing off (i.e., the handing process) must remove characteristics and components that are not common to the common ancestor component model. The handing process may need to translate the stripped information into additional objects and characteristic value assignments at the level of the common ancestor component model. In the example of the car, a product sold in a particular sales region, e.g., a California Dune Buggy specified by fifteen characteristic values, may not directly correspond to a manufactured model. The properties specified when ordering one such car should, however, enable identification of the car as a manufacturable model TX500 specified by some fifty characteristic values (which are not relevant for sales, but which can be inferred from the original fifteen by the sales process).
The receiving process may have to augment the configuration by adding such characteristics and components from its own component model to allow useful processing. For example, the TX500 derived by sales process in the above example may need to be built in a manufacturing plant. The manufacturing process needs additional details (like battery size). This information may lead to some 200 characteristic values to be set that can be derived from the passed fifty characteristics.
In one implementation, several model component versions can be concurrently used operationally by the associated business process or entities. For example, cars can be ordered some time ahead of intended delivery. Cars to be delivered in April may need to be configured against a different model from those to be delivered in June. When creating a new version of a model component an explicit decision must be made to release the model for business use. To this end, each model component has a status. If changes need to be made for a model component that is in operational use, these changes must be tested before allowing them to become active. For this purpose, each model component has an active and an inactive state. The inactive state can be changed and tested without affecting the operational version. If the changes are approved, then the inactive state can be changed to an activate state.
In one implementation, model components are the units of distribution of a model. A central sales model may be distributed to all (non-central) sales organizations. Distributing a model component pre-supposes that the ancestor versions the component references either have already been distributed or are being distributed along with the model component.
In one implementation, the system can provide a mechanism for importing and exporting model component versions. A data container that allows storing and shipping the data in a component is provided. Changes to a model component version can be exported and imported by them. When importing a change to a model component that is in operational use, the change may have to be imported in a staged way. It is first imported into the inactive state and later activated.
In an implementation, components and subcomponents that have been defined in one configuration model can be reused in other configuration models. This is advantageous when two or more configurable products have configuration models that are independent of each other, but the configuration models have at least one subcomponent or component that contains the same information. For example, if the configurable product is a car, there may be two different car models that come with the same three engine choices. The configuration models for the two cars will be independent of one another, but both configuration models will need one or more subcomponents that contain the same engine information. Once a user generates the engine subcomponents for one configuration model, the second configuration model can simply reuse these subcomponents rather than creating brand new subcomponents.
The reuse of subcomponents can be implemented in different ways. In one implementation, the reuse of subcomponents can be implemented by establishing an inter-model link between subcomponents of a first configuration model and subcomponents of a second configuration model. The subcomponents being reused stay within the structure of the first configuration model, but can now be accessed by the second configuration model as well through the inter-model link. The inter-model link creates a communication path between the two configuration models. The second configuration model retrieves information out of the subcomponents being reused from the first configuration model. The inter-model link technique is possible when information can be exchanged between configuration models.
There are several advantages to using inter-model links when reusing subcomponents. The inter-model link can reduce the consumption of memory space because subcomponents being reused are stored in only one location. The use of an inter-model link enables the system to update subcomponent versions. When a newer version of a subcomponent is activated, the link can be rerouted to the newer version of the subcomponent, thereby updating all configuration models that are reusing a particular subcomponent. With the link, the system can check consistency and consequences of a change with respect to subcomponents belonging to other configuration models. Modeling responsibility can be distributed over multiple configuration models when subcomponents are being reused by inter-model links. Inter-model links also allow for abstract or generic subcomponents to be used in the configuration models without those subcomponents having to belong to any particular component or business process.
In another implementation, subcomponents or components can be copied from a first configuration model and then inserted into a second configuration model. The first configuration model can be an existing one and the second configuration can be a new one. Any number of subcomponents or components can be copied. The copy and insert method is advantageous when the configuration models are stored in different locations, such as on different computer systems or within different data systems. In particular, this method is advantageous when the configuration models are stored such that they are unable to communicate with one another. Each configuration model will then need its own independent copy of the subcomponents.
The copy and insert method of reusing subcomponents is also useful when the information within the subcomponents will be changed or modified beyond changes usually made between versions, and the change or modification is specific to the configuration model in which the subcomponents reside. When two or more configuration models directly share the same subcomponent, the data cannot be altered for the benefit of just one of the configuration models. Making configuration model specific modifications is only possible when each configuration model has its own copy of the subcomponents.
In another implementation, the reusable subcomponents can be stored in a location that is independent of any configuration model. The subcomponents can then be linked to each configuration model that needs to use it. This can be done when the user knows ahead of time that the information in the subcomponent will be used in multiple configuration models. The subcomponent can be defined in one location, and the configuration models can be linked to the subcomponent as needed. This allows multiple users to collaborate in the modeling process. In yet another implementation, the reusable location can be another location within the same configuration model. A link can be an intra-model link. That is, the link can then be established within the same configuration model so that multiple branches of the configuration model can use the same subcomponent.
The reuse of subcomponents can greatly reduce the time required to input data when generating a configuration model. This is because these subcomponents often contain large amounts of data, and therefore a lot of user hours can be expended in entering the data. This is particularly true when the subcomponents being reused form an entire component, thereby containing data for an entire business process. If a user is defining another configuration model that will have subcomponents that are identical to subcomponents in an existing configuration model, the reuse of these subcomponents will save the user from having to reenter all of the data once again.
The information that is shared by reusing subcomponents can be of any type. For example, if the marketing department is doing the same promotion for several different car models, the configuration models for each of those cars can use the same marketing subcomponents, including the same entire marketing component if necessary. A user can enter the marketing information into subcomponents for one configuration model, and those subcomponents can then be copied and inserted into the configuration models for other cars that are part of the promotion. Alternatively, the marketing subcomponents can be entered in the configuration model for one car, and those subcomponents can then be linked into the configuration models for the other cars. In another implementation, the marketing subcomponents can be stored outside of any particular configuration model, and then each of the configuration models that require the marketing subcomponents can be linked to it. Component types, including but not limited to product design, production, engineering, and sales, can be reused as well.
One or more reused subcomponents can be joined with non-reused subcomponents to form a component of the first configuration model, or a component can be formed entirely from reused subcomponents. It should be noted that as above, the information that describes the product includes, but is not limited to, any combination of characteristics, characteristic values, constraints describing dependencies of the characteristics, default values, and values ranges. If the component is used for a business process, the business process can include, but is not limited to, one of marketing, product design, production, engineering, and sales.
In one implementation, an abstract configuration model that generically describes a product can be defined. The abstract configuration model can include a generic base component. The abstract configuration model can include one or more components for a generic purpose. The generic components do not necessarily belong to a particular business process such as marketing or engineering. Rather, the generic components describe general objects that can be used in many different contexts. These generic components can be implemented in actual configuration models in a number of different ways.
In one implementation, the abstract configuration model is not associated with any particular product. Although the abstract configuration model is not associated with any particular product, it can be associated with a particular version if desired. Thus, an abstract configuration model can have multiple versions. The abstract configuration model can serve as a baseline for a particular product. The abstract configuration model can also be linked to other configuration models, including abstract and non-abstract configuration models.
The abstract configuration model can perform all of the same functions as a non-abstract configuration model. The system can generate a first view and a second view of the abstract configuration model. The first view can include information that generically describes the product. The second view can include information that generically describes the product for some generic process. The views can be based on the role or access authorization of the user, so that only information needed by the user is shown. The generic components can be used for any of the processes described above, including marketing, product design, production, engineering, and sales.
The invention can be implemented in digital electronic circuitry, or in computer hardware, firmware, software, or in combinations of them. The invention can be implemented as a computer program product, i.e., a computer program tangibly embodied in an information carrier, e.g., in a machine-readable storage device or in a propagated signal, for execution by, or to control the operation of, data processing apparatus, e.g., a programmable processor, a computer, or multiple computers. A computer program can be written in any form of programming language, including compiled or interpreted languages, and it can be deployed in any form, including as a stand-alone program or as a verification module, component, subroutine, or other unit suitable for use in a computing environment. A computer program can be deployed to be executed on one computer or on multiple computers at one site or distributed across multiple sites and interconnected by a communication network.
Method steps of the invention can be performed by one or more programmable processors executing a computer program to perform functions of the invention by operating on input data and generating output. Method steps can also be performed by, and apparatus of the invention can be implemented as, special purpose logic circuitry, e.g., an FPGA (field programmable gate array) or an ASIC (application-specific integrated circuit).
Processors suitable for the execution of a computer program include, by way of example, both general and special purpose microprocessors, and any one or more processors of any kind of digital computer. Generally, a processor will receive instructions and data from a read-only memory or a random access memory or both. The essential elements of a computer are a processor for executing instructions and one or more memory devices for storing instructions and data. Generally, a computer will also include, or be operatively coupled to receive data from or transfer data to, or both, one or more mass storage devices for storing data, e.g., magnetic, magneto-optical disks, or optical disks. Information carriers suitable for embodying computer program instructions and data include all forms of non-volatile memory, including by way of example semiconductor memory devices, e.g., EPROM, EEPROM, and flash memory devices; magnetic disks such as internal hard disks and removable disks; magneto-optical disks; and CD-ROM and DVD-ROM disks. The processor and the memory can be supplemented by, or incorporated in special purpose logic circuitry.
The invention has been described in terms of particular embodiments. Other embodiments are within the scope of the following claims. For example, the steps of the invention can be performed in a different order and still achieve desirable results. The configuration model can be applied to any product and is not limited to those described. For example, the configuration model can describe configurable computer systems. The configuration model can be adapted for purposes other than those listed. For example, the configuration model can be adapted for a business process for advertising. The system can be any computing system that includes programs having instructions to perform the described actions and operations. A product model can include subcomponents and components other than the described configuration model and the product structure. For example, a product model can also include documents, routing information, line design information, and material information. The system can use any technique for defining constraints and is not limited to using those described in reference to
| Number | Name | Date | Kind |
|---|---|---|---|
| 4459663 | Dye | Jul 1984 | A |
| 4875162 | Ferriter et al. | Oct 1989 | A |
| 5099431 | Natarajan | Mar 1992 | A |
| 5111413 | Lazansky et al. | May 1992 | A |
| 5182705 | Barr et al. | Jan 1993 | A |
| 5191534 | Orr et al. | Mar 1993 | A |
| 5260866 | Lisinski et al. | Nov 1993 | A |
| 5311424 | Mukherjee et al. | May 1994 | A |
| 5335346 | Fabbio | Aug 1994 | A |
| 5359523 | Talbott et al. | Oct 1994 | A |
| 5381332 | Wood | Jan 1995 | A |
| 5418945 | Carter et al. | May 1995 | A |
| 5434791 | Koko et al. | Jul 1995 | A |
| 5442782 | Malatesta et al. | Aug 1995 | A |
| 5499357 | Sonty et al. | Mar 1996 | A |
| 5537524 | Aprile | Jul 1996 | A |
| 5655085 | Ryan et al. | Aug 1997 | A |
| 5694598 | Durand et al. | Dec 1997 | A |
| 5703938 | Lucas et al. | Dec 1997 | A |
| 5710884 | Dedrick | Jan 1998 | A |
| 5758031 | De Silva | May 1998 | A |
| 5765142 | Allred et al. | Jun 1998 | A |
| 5799293 | Kaepp | Aug 1998 | A |
| 5815395 | Hart | Sep 1998 | A |
| 5838965 | Kavanagh et al. | Nov 1998 | A |
| 5859972 | Subramaniam et al. | Jan 1999 | A |
| 5911139 | Jain et al. | Jun 1999 | A |
| 5923552 | Brown et al. | Jul 1999 | A |
| 5966715 | Sweeney et al. | Oct 1999 | A |
| 5984511 | Vasey-Glandon et al. | Nov 1999 | A |
| 6002854 | Lynch et al. | Dec 1999 | A |
| 6002941 | Ablay et al. | Dec 1999 | A |
| 6018742 | Herbert, III | Jan 2000 | A |
| 6029195 | Herz | Feb 2000 | A |
| 6032147 | Williams et al. | Feb 2000 | A |
| 6067525 | Johnson et al. | May 2000 | A |
| 6167383 | Henson | Dec 2000 | A |
| 6216108 | LeVander | Apr 2001 | B1 |
| 6226650 | Mahajan et al. | May 2001 | B1 |
| 6236997 | Bodamer et al. | May 2001 | B1 |
| 6247128 | Fisher et al. | Jun 2001 | B1 |
| 6324508 | Finney | Nov 2001 | B1 |
| 6324647 | Bowman-Amuah | Nov 2001 | B1 |
| 6330598 | Beckwith et al. | Dec 2001 | B1 |
| 6341261 | Vasey-Glandon et al. | Jan 2002 | B1 |
| 6405132 | Breed et al. | Jun 2002 | B1 |
| 6477517 | Limaiem et al. | Nov 2002 | B1 |
| 6480755 | Ootani et al. | Nov 2002 | B1 |
| 6487594 | Bahlmann | Nov 2002 | B1 |
| 6487713 | Cohen et al. | Nov 2002 | B1 |
| 6529948 | Bowman-Amuah | Mar 2003 | B1 |
| 6567818 | Frey et al. | May 2003 | B1 |
| 6609108 | Pulliam et al. | Aug 2003 | B1 |
| 6629065 | Gadh et al. | Sep 2003 | B1 |
| 6711456 | Yokomori et al. | Mar 2004 | B2 |
| 6718361 | Basani et al. | Apr 2004 | B1 |
| 6725257 | Cansler et al. | Apr 2004 | B1 |
| 6728888 | Ooki et al. | Apr 2004 | B2 |
| 6738682 | Pasadyn | May 2004 | B1 |
| 6754666 | Brookler et al. | Jun 2004 | B1 |
| 6760693 | Singh et al. | Jul 2004 | B1 |
| 6768944 | Breed et al. | Jul 2004 | B2 |
| 6778864 | Bugli et al. | Aug 2004 | B1 |
| 6810401 | Thompson et al. | Oct 2004 | B1 |
| 6820082 | Cook et al. | Nov 2004 | B1 |
| 6842881 | Croke et al. | Jan 2005 | B2 |
| 6857123 | Nuxoll et al. | Feb 2005 | B1 |
| 6879976 | Brookler et al. | Apr 2005 | B1 |
| 6883136 | Weinberg et al. | Apr 2005 | B1 |
| 6895408 | Kavantzas | May 2005 | B1 |
| 6915287 | Felsted et al. | Jul 2005 | B1 |
| 6959268 | Myers, Jr. et al. | Oct 2005 | B1 |
| 6961687 | Myers, Jr. et al. | Nov 2005 | B1 |
| 6988014 | Haag et al. | Jan 2006 | B2 |
| 7031787 | Kalthoff et al. | Apr 2006 | B2 |
| 7096164 | Musharbash | Aug 2006 | B1 |
| 7103605 | Hazi et al. | Sep 2006 | B1 |
| 7110988 | Allemann et al. | Sep 2006 | B1 |
| 7165041 | Guheen et al. | Jan 2007 | B1 |
| 7315826 | Guheen et al. | Jan 2008 | B1 |
| 20010034628 | Eder | Oct 2001 | A1 |
| 20020038206 | Dori | Mar 2002 | A1 |
| 20020065892 | Malik | May 2002 | A1 |
| 20020073114 | Nicastro et al. | Jun 2002 | A1 |
| 20020087510 | Weinberg et al. | Jul 2002 | A1 |
| 20020095454 | Reed et al. | Jul 2002 | A1 |
| 20020099583 | Matusek et al. | Jul 2002 | A1 |
| 20020108099 | Paclat | Aug 2002 | A1 |
| 20020116417 | Weinberg et al. | Aug 2002 | A1 |
| 20020124005 | Matson et al. | Sep 2002 | A1 |
| 20020128904 | Carruthers et al. | Sep 2002 | A1 |
| 20020156668 | Morrow et al. | Oct 2002 | A1 |
| 20020156688 | Horn et al. | Oct 2002 | A1 |
| 20020161778 | Linstedt | Oct 2002 | A1 |
| 20020165960 | Chan | Nov 2002 | A1 |
| 20020173999 | Griffor et al. | Nov 2002 | A1 |
| 20020184308 | Levy et al. | Dec 2002 | A1 |
| 20020188484 | Grover et al. | Dec 2002 | A1 |
| 20020188537 | Leeds et al. | Dec 2002 | A1 |
| 20020194196 | Weinberg et al. | Dec 2002 | A1 |
| 20030018878 | Dorward et al. | Jan 2003 | A1 |
| 20030028519 | Burgess | Feb 2003 | A1 |
| 20030090527 | Kamino | May 2003 | A1 |
| 20030130749 | Haag et al. | Jul 2003 | A1 |
| 20030135495 | Vagnozzi | Jul 2003 | A1 |
| 20030182145 | Kalthoff et al. | Sep 2003 | A1 |
| 20030182167 | Kalthoff et al. | Sep 2003 | A1 |
| 20030191832 | Satyavolu et al. | Oct 2003 | A1 |
| 20030204440 | Koller et al. | Oct 2003 | A1 |
| 20030233347 | Weinberg et al. | Dec 2003 | A1 |
| 20040012634 | Haag et al. | Jan 2004 | A1 |
| 20040015408 | Rauen, IV et al. | Jan 2004 | A1 |
| 20040059709 | Farrands et al. | Mar 2004 | A1 |
| 20040128180 | Abel et al. | Jul 2004 | A1 |
| 20040177002 | Abelow | Sep 2004 | A1 |
| 20040233232 | Iborra et al. | Nov 2004 | A1 |
| 20040249650 | Freedman et al. | Dec 2004 | A1 |
| 20050038551 | Mazumder et al. | Feb 2005 | A1 |
| 20050060245 | Hoffman et al. | Mar 2005 | A1 |
| 20050102374 | Moragne et al. | May 2005 | A1 |
| 20050177716 | Ginter et al. | Aug 2005 | A1 |
| 20050187973 | Brychell, III et al. | Aug 2005 | A1 |
| 20050193269 | Haswell et al. | Sep 2005 | A1 |
| 20050240621 | Robertson et al. | Oct 2005 | A1 |
| 20060064456 | Kalthoff et al. | Mar 2006 | A1 |
| Number | Date | Country |
|---|---|---|
| 2391829 | Jun 2001 | CA |
| 10049940 | Apr 2002 | DE |
| 0 483 039 | Apr 1992 | EP |
| 0 520 923 | Dec 1992 | EP |
| 0 913 967 | May 1999 | EP |
| WO 8600735 | Jan 1986 | WO |
| 0137097 | May 2001 | WO |
| 0225471 | Mar 2002 | WO |
| 0225500 | Mar 2002 | WO |
| 0247463 | Jun 2002 | WO |
| WO03040865 | May 2003 | WO |
| WO03081371 | Oct 2003 | WO |
| WO03081372 | Oct 2003 | WO |
| 03093998 | Nov 2003 | WO |
| WO2004063955 | Jul 2004 | WO |
| WO2004072877 | Aug 2004 | WO |
| Number | Date | Country | |
|---|---|---|---|
| 20050137731 A1 | Jun 2005 | US |
