O
`.Ix
`
`’,.o
`o~ C
`
`-----4
`O
`
`HAMILTON & TERRILE, LLP
`
`8911 North Capital of Texas Highway
`Westech Center Suite 3150
`Austin, Texas 78759
`512.338.9100 Telephone
`512.345.7225 Facsimile
`
`April 19, 2004
`
`-~
`
`MAIL STOP PATENT APPLICATION
`COMMISSIONER FOR PATENTS
`P.O. Box 1450
`Alexandria, VA 22313-1450
`
`Enclosed herewith for filing is a patent application, as follows:
`
`Inventor(s):
`Title:
`Docket No.:
`Customer No.:
`
`Brandon M. Beck, Shawn A. P. Smith
`Consolidation of Product Data Models
`T00113
`33438
`
`X Return Receipt Postcard
`X Check for $810 for Filing Fee and Assignment Fee
`X Transmittal Letter
`35
`page(s) Specification (not including Claims)
`1
`page(s) Claims
`1
`page(s) Abstract
`13
`sheet(s) of Drawings
`page(s) Declaration For Patent Application and Power of Attorney
`2
`1
`page(s) Nonpublication Request
`1
`page(s) Recordation Form Cover Sheet
`1
`page(s) Assignment
`
`For
`
`Total Claims
`
`Independent Claims
`
`CLAIMS AS FILED (fees computed under §l.9(f))
`Number
`Number
`Filed
`Extra
`
`Rate
`
`4
`
`3
`
`-20
`
`-3
`
`=
`
`=
`
`0
`
`0
`
`x
`
`x
`
`$18
`
`$86
`
`--
`
`=
`
`[] Application contains one or more multiple dependent claims ($290 total fee)
`
`~] Fee for filing the patent application in the amount of."
`
`~5~ Fee for Recordation Form Cover Sheet and Assignment
`
`[] Check enclosed for total fees in the amount of."
`
`$
`
`$
`
`$
`
`$
`
`Basic Fee
`770.00
`
`.00
`
`.00
`
`0.00
`
`$.oo
`
`$40.00
`
`$810.00
`
`The Commissioner is hereby authorized to charge any additional fees which may be required,
`or credit any overpayment to Deposit Account 502264.
`
`EXPRESS MAIL LABEL NO:
`
`EV324253342US
`
`The PTO did not rooeive the ~ollowin
`Usted item(s) ,4)O.q :~ (’~ D~ 1
`
`Respectfully submitted,
`
`Kent B. Chambers
`Attorney for Applicant(s)
`Reg. No. 38,839
`
`Page 1 of 326
`
`FORD 1007
`
`

`
`Under the Paperwork Reduction Act of 1995, no pcrsor
`
`PTO/SB/35 (11-00)
`Approved through use through 10/31/2002 OM B 0651-0031
`l.S. Patent and Trademark Office; U.S. DEPARTMENT OF COMMERCE
`i are required to respond to collection of inforomtion unless it displays a valid OMB control number.
`
`NONPUBLICATION REQUEST
`UNDER
`35 U.S.C. 122(b)(2)(B)(i)
`
`First Named
`Inventor
`
`Title
`
`Brandon M. Beck
`
`CONSOLIDATION OF
`PRODUCT DATA MODELS
`
`Attomey
`Docket
`Number
`
`T00113
`
`I hereby certify that the invention disclosed in the attached application has not and will
`not be the subject of an application filed in another country, or under a multilateral
`agreement, that requires publication at eighteen months after filing. I hereby request that
`the attached application not be published under 35 U.S.C. 122(b).
`
`o
`
`J
`
`A,
`Date
`
`Signature
`
`Kent B. Chambers, Reg. No. 38,839
`Typed or printed name
`
`This request must be signed in compliance with 37 CFR 1.33(b) and submitted with the
`application upon filing.
`
`Applicant may rescind this nonpublication request at any time. If applicant rescinds a
`request that an application not be published under 35 U.S.C. 122(b), the application will
`be scheduled for publication at eighteen months from the earliest claimed filing date for
`which a benefit is claimed.
`
`If applicant subsequently files an application directed to the invention disclosed in the
`attached application in another country, or under a multilateral intemational agreement,
`that requires publication of applications eighteen months after filing, the applicant must
`notify the United States Patent and Trademark Office of such filing within forty-five (45)
`days after the date of the filing of such foreign or international application. Failure to do
`so will result in abandonment of this application (35 U.S.C. 122(b)(2)(B)(iii)).
`
`Burden Hour Statement: This collection of information is required by 37 CFR 1.213(a). The information is used by the public to
`request that an application not be published under 35 U.S.C. 122(b) (and the PTO to process that request). Confidentiality is governed
`by 35 U.S.C. 122 and 37 CFR 1.14.
`
`Page 2 of 326
`
`FORD 1007
`
`

`
`,/
`
`Attorney Docket No.: TOO I 13
`
`"Express Mail" mailing label number:
`
`EV324253342US
`
`CONSOLIDATION OF PRODUCT DATA MODELS
`
`Brandon M. Beck
`
`Shawn A. P. Smith
`
`BACKGROUND OF THE INVENTION
`
`Field of the Invention
`
`(1) The present invention relates in general to the field of information processing, and
`
`more specifically to a system and method for consolidating data from various product
`
`data models.
`
`DESCRIPTION OF THE RELATED ART
`
`(2) A configurable product can be described by a configuration model having a set of
`
`configuration rules. A configurable product can be conceptually broken down into
`
`sets of selectable families and features of families that make up each product. A
`
`family represents a classification of a particular type of feature. Families are typically
`
`classified as groups of features with the same functional purpose. Example families
`
`for an automobile are "engines," "tires," "seats," and "exterior paint color." Families
`
`can also represent other groups such as market areas. For example, a family can
`
`include a marketing region such as USA, Canada, Mexico, Europe, or any other
`
`region. Families can be represented in terms of the minimum and maximum number
`
`of features that must be present in a configuration from a family for the configuration
`
`to be valid. A common family minimum and maximum or "(min, max)" is (1, 1).
`
`This notation means that exactly one feature from the family must be part of a
`
`configuration for the configuration to be valid. Other common (min, max) settings
`
`are (0, 1), meaning that either no features or a single feature from the family must be
`
`present in a configuration for it to be valid, and (0, -1), meaning that zero or any
`
`-1-
`
`Page 3 of 326
`
`FORD 1007
`
`

`
`Attorney Docket No.: T00113
`
`positive number of features from the family must be present in a configuration for it
`
`to be valid.
`
`(3) A feature represents an option that can be ordered on a product. All features are
`
`members of a family. Features are both assigned optionalities and used to qualify
`
`other features and the optionalities assigned to them. An example feature from the
`
`engine family is a "4.8 liter V8." Features relate to each other via ordering codes or
`
`optionalities. Example optionalities include "S", "O", "M", and "hi," which translate
`
`to standard, optional, mandatory, and not available. A specific example would be
`
`"the 4.8 liter V8 engine is standard on the GS trim."
`
`(4) Features relate to each other via configuration rules. A rule can be characterized
`
`as generally including a ’left hand side’, (LHS), a ’right hand side’ (RHS), and a
`
`specified relationship between the LHS and RI-IS. Each LHS feature may be
`
`associated with one or more RHS features, which indicates that a single feature in the
`
`LHS may be constrained or otherwise qualified by one or more RHS features. The
`
`RHS describes when a rule is in effect and what features are particularly affected. For
`
`example, a rule with a RHS of"XA, XB" means that the rule is in effect in cases
`
`where you have at least XA and XB in a buildable configuration, and XA and XB are
`
`features particularly affected by the rule along with the LHS feature. Configuration
`
`rules include optionalities that define a relationship between the LHS and RHS.
`
`Further exemplary discussion of LHS and RHS rule concepts is described in Gupta et
`
`al., U.S. Patent No. 5,825,651 entitled "Method and Apparatus for Maintaining and
`
`Configuring Systems."
`
`(5) A configuration rule includes a main feature, an optionality, one or more
`
`constraints, and an applicable timeframe. As an example:
`Main feature Optionality Constraints Timeframe
`
`4.8 liter V8
`
`S
`
`XL & US May-December 2003 Rule 1
`
`(6) Rule 1 means "the 4.8 liter V8 is standard with the XL trim and US market from
`
`May to December 2003." The main feature represents the feature that is being
`
`affected by the rule. Optionalities can be positive or negative: positive optionalities
`
`-2-
`
`Page 4 of 326
`
`FORD 1007
`
`

`
`Attorney Docket No.: T00113
`
`state that the main feature can work with the constraints; negative optionalities state
`
`the main feature cannot work with the constraints. Constraints qualify the rule and
`
`can be an arbitrary Boolean expression of features such as AND, NOT, and OR
`
`operators. In the rules below, a "." indicates an AND operation, a "-" indicates a
`
`NOT operation, and a "+" indicates an OR operation. The timeframe specifies when
`
`the other rule elements are effective.
`
`(7) A buildable configuration describes what features can and can’t exist with other
`
`features of a product. The example rule above defines a buildable configuration in the
`
`following way: "the 4.8 liter V8 is buildable (because it is standard) with the
`
`combination of XL and US." If the combination of features, such as of XL and US, is
`
`not buildable, the example rule is inactive. Consequently, even though the engine is
`
`buildable with that combination, if the combination is not buildable, the three features
`
`together are not a buildable configuration. A rule that would make the example rule
`
`inactive is the following:
`
`Main feature
`
`Optionality Constraints
`
`Timeframe
`
`XL
`
`N
`
`US
`
`Sept. 2002
`
`Rule 2
`
`(8) Rule 2 means "the XL trim main feature is not available with US from September
`
`of 2002 onward." Until the XL main feature is made available with the US by
`
`changing the optionality from "N" to one that expresses a positive relationship, there
`
`will not be a buildable configuration for XL, US, and the 4.8L engine.
`
`(9) Thus, a rule defines a buildable configuration between its main feature and its
`
`constraints only. A rule does NOT define a buildable configuration relationship
`
`between the members of its constraints. A separate rule must define that buildable
`
`configuration. Consequently, all rules together for a product define the complete
`
`product buildable configurations. In order to determine if the three features in the
`
`example rule (the main feature and the constraints) are a buildable configuration, the
`
`rules written on each of those features (i.e. where each feature is the main feature)
`
`should to be considered jointly. Inactive rules do not define buildable configurations
`
`until they become active.
`
`-3-
`
`Page 5 of 326
`
`FORD 1007
`
`

`
`Attorney Docket No.: T00113
`
`(10) A "model" refers to a collection of rules that define the buildable
`
`configurations of one or more products.
`
`(11) Referring to Figure 2, the families in each model are internally organized in
`
`accordance with a directed acyclic graph ("DAG") 200. The DAG contains an edge
`
`between a child family and a parent family if there exists a rule with a LHS feature
`
`that belongs to the child family and a RHS feature that belongs to the parent family.
`
`The DAG organization allows a child family to reference an ancestor but not the other
`
`way around. Cyclic references within a model as in Figure 4 can produce ambiguities
`
`within the model.
`
`(12) Each model contains variations of the buildable configurations of the product.
`
`For example, a company may market a product with a particular set of standard
`
`features in one region and market the same product with a different set of standard
`
`features in another region. For example, in an automotive context, a V6 engine may
`
`be standard for a particular automobile model in one country, and a V8 engine may be
`
`standard for the particular automobile model in another country. In a computer
`
`context, a power supply with a 110V input may be standard in one country and a
`
`power supply with a 220V input may be standard in another country.
`
`(13) Defining and maintaining the configuration space for a large product can often
`
`be difficult to do in a single configuration model. In order to limit the complexity and
`
`facilitate maintenance the configuration space is often defined in multiple
`
`configuration models. Each of these models are then assigned a set of defining
`
`constraints that specify which portion of the overall configuration space for the
`
`product it is defining. An example breakdown of the configuration space definition
`
`for an automotive vehicle could be into 3 separate models. Each model would define
`
`the configuration space of the automobile in one of 3 countries: USA, Canada, or
`
`Mexico. In this example each configuration model would have as a defining
`
`constraint one of the features representing each country. In the USA model the only
`
`allowable configurations would all contain the "USA" feature. Although not
`
`specifically included in this example, time can also be a defining constraint.
`
`-4-
`
`Page 6 of 326
`
`FORD 1007
`
`

`
`Attorney Docket No.: T00113
`
`(14) A model may contain labels that describe the time period and space over
`
`which the model applies (also referred to as "model defining constraints"). For
`
`example, a model which describes the availability of cars in the United States during
`
`the years 2004 to 2006 may have defining constraints of"CARS.USA.2004-2006"
`
`while a model that describes the availability of all vehicles in North America during
`
`2005 may have defining constraints of
`
`"{CARS+TRUCKS}. {USA+CANADA+MEXICO} .2005".
`
`(15) While it is convenient to have this logical separation of the configuration
`
`space for maintenance purposes it is often desired to provide a single unified model
`
`that represents the configuration space for the entire product. The resulting unified
`
`configuration model can then be used to answer any questions that one of the original
`
`models could answer and it will give the same result. The set of allowable feature
`
`combinations for the unified model should be equivalent to the union of allowable
`
`feature combinations for each of the original configuration models.
`
`(16) Thus, despite the differences in various models, it is often desirable to
`
`combine the multiple models into a consolidated model having a unified set of rules
`
`(also referred to as "stitched rules"). Referring to Figure 5, the conventional
`
`consolidation system 500 includes a model 502 that represents a set of three models
`
`that may be created and maintained separately. Model 504 is, for example, a
`
`configuration model that describes how a particular product may be built and sold for
`
`the USA market. Model 506 is a configuration model that describes how the same
`
`product may be built and sold for the Canadian market. Model 508 is a configuration
`
`model that describes how the same product may be built and sold for the Mexican
`
`market. Models 504, 506, and 508 may be combined into a single model 512 by
`
`conventional consolidation (also referred to as "stitching") processes 510. The
`
`consolidated model 512 will contain stitched rules that represent all the information
`
`present in the original three models. However, in many circumstances the
`
`conventional consolidations processes 510 produce unspecified configuration
`
`buildables in consolidated model 512. "Unspecified configuration buildables" are
`
`configuration buildables included in consolidated model 512 that are not defined in
`
`any of the source models, i.e. models 504, 506, and 508. An unspecified
`
`configuration buildable is, thus, an error that can have significant adverse
`
`-5-
`
`Page 7 of 326
`
`FORD 1007
`
`

`
`Attorney Docket No.: T00113
`
`consequences. Conventional consolidation processes do not automatically detect
`
`unspecified configuration buildables and correct them. Since models can contain
`
`thousands, hundreds of thousands, or more rules, a high degree of automation is often
`
`a key to success for modeling and model data driven technologies.
`
`(17) Referring to Figure 1, for example, assume models 102 and 104 are two
`
`configuration models with the following rules:
`¯ Model 102: model defining constraints = {MKT1 }
`
`¯ MKT10 ALL
`
`¯ ENG1 S ALL
`
`¯ Model 104: model defining constraints = {MKT2}
`
`¯ MKT20 ALL
`
`¯ ENG1 S ALL
`
`¯ ENG2 O ALL
`
`(18) The rules in models 102 and 104 are interpreted as allowing the following
`
`buildable configurations:
`¯ Model102:
`
`¯ MKT1.ENG1
`
`¯ Model 104:
`
`¯ MKT2.ENG1
`
`¯ MKT2.ENG2
`
`(19) An example conventional consolidation process 510 that simply combined the
`
`rules from models 102 and 104 using a simple aggregation process would yield a
`
`consolidated model 106 with the following rules:
`¯ Model 106: model defining constraints ("MDC") = ~MKTI+MKT2}
`
`¯ MKT10 ALL
`
`¯ MKT20 ALL
`
`6-
`
`Page 8 of 326
`
`FORD 1007
`
`

`
`Attorney Docket No.: T00113
`
`¯ ENG1 S ALL
`
`¯ ENG20 ALL
`
`(20) The rules of model 106 are interpreted as allowing the following buildable
`
`configurations:
`¯ Model 106:
`
`¯ MKT1.ENG1 (corresponds to element 108)
`
`¯ MKT1.ENG2 (corresponds to element 112)
`
`¯ MKT2.ENG1 (corresponds to element 110)
`
`¯ MKT2.ENG2 (corresponds to element 110)
`
`(21) Model 106 includes the model space defined by the model defining constraints
`
`108 of model 102 and the model space defined by the model defining constraints of
`
`110 of model 104. Unfortunately, in addition to representing the stitched rules of
`
`models 102 and 104, model 106 also includes an unspecified buildable configuration
`
`"MKT1 .ENG2" 112. In the embodiment of Figure 1, buildable configurations of
`
`model 104 have been extended into the model defining constraints MKT1 space 114.
`
`Model defining constraints space MKT2 space 116 accurately contains only the
`
`buildable configurations of model 104.
`
`(22) The consolidated model should faithfully represent the buildable
`
`configurations of the products represented by models 102 and 104 without including
`
`any errors such as the unspecified buildable configurations 112. Conventional
`
`consolidation processes attempt to solve this problem by modifying, adding, and
`
`removing stitched rules so that rules from each source model do not extend outside of
`
`the space defined by their source model’s defining constraints.
`
`.(23) An example enhanced conventional consolidation process 510 that combined
`
`the rules from models 102 and 104, constraining each to their source model’s defining
`
`constraints, would yield a consolidated model 406 with the following rules:
`¯ Model 406: model defining constraints = {MKTI+MKT2}
`
`¯ MKT10 ALL (source model 102’s defining constraints = {MKT1 })
`
`-7-
`
`Page 9 of 326
`
`FORD 1007
`
`

`
`Attorney Docket No.: TOO 113
`
`¯ ENG1 S MKT1
`
`(source model 102’s defining constraints = {MKT1 })
`
`¯ MKT20 ALL
`
`(source model 104’s defining constraints = {MKT2})
`
`¯ ENG1 SMKT2
`
`(source model 104’s defining constraints = {MKT2})
`
`¯ ENG2OMKT2
`
`(source model 104’s defining constraints = {MKT2})
`
`(24) The rules of model 406 are interpreted as allowing the following buildable
`
`configurations:
`¯ Model 406:
`
`¯ MKT1.ENG1
`
`¯ MKT2.ENG 1
`
`¯ MKT2.ENG2
`
`(25) The new model 406 accurately combines the intent of source models 102 and
`
`104 without introducing new unspecified buildable combinations.
`
`(26) Although consolidation appears to be the straight forward process of adding
`
`all the rules from each model being consolidated and qualifying each rule with the
`
`model defining constraint label that indicates the orion of the rule in a consolidated
`
`model, the actual conventional process is not that simple due to constraints on the
`
`model’s representation of families. To avoid creation of ambiguous models, the
`
`consolidation process typically must also ensure that the families in the consolidated
`
`model 512 can be organized into a DAG as described above. However, the
`
`conventional consolidation process 510 violates this constraint.
`
`(27) Following is pseudo code for a conventional consolidation process produced
`
`using an appropriately programmed computer and model data. The "//" forward slash
`
`symbols represent the start and end of explanatory comments:
`
`def performConventionalStitching(rules, mdc, dag):
`
`//Defines the method "performConventionalStitching" to consolidate one or
`more models using the rules in the models, the model defining constraints
`(mdc), and the DAG of the model.//
`
`stitchedRules = {}
`
`-8-
`
`Page 10 of 326
`
`FORD 1007
`
`

`
`Attorney Docket No.: T00113
`
`//collects the consolidated rules for the consolidated model.//
`
`for each rule in rules:
`
`//Sequentially process each rule in the models being consolidated.//
`
`stitehedRule = rule.intersect(male)
`
`//Intersect the rule being processed with a model qualifier space, i.e.
`the configurations for which the model applies. Intersection Examples
`wherein A1, B 1, and B2 represent model qualifier spaces:
`(X1SA1) nAI=X1SA1
`(X1 S A1) riB1 =Xl S A1.B1
`(Xl SB2) nBI=O
`(B1SALL) nBI=B1 SALL
`(B2 S ALL) n B 1 = O
`(A1 S ALL) n A1.B2 = A1 S B2//
`
`if(stitehedRule != 0):
`
`//If the intersection is not empty ...//
`
`stitehedRule = removeDAGCyeles(stitehedRule, dag)
`
`//Remove any qualifiers that produce cyclical references within the
`DAG.//
`
`stitehedRules.add(stitehedRule)
`
`//Add stitched rules to the set of stitchedRules of the consolidated
`model.//
`
`return stitehedRules
`
`clef removeDAGCyeles(rule, dag):
`
`//Defines the method "removeDAGCycles" to remove qualifiers of the rule
`that produce cyclical relationships within the DAG.//
`
`remove qualifiers from the rule that are ancestor families of the main feature
`(i.e. the LHS of the rule) in the DAG.
`
`(28) The following represents the example application of the conventional model
`
`consolidation process. Consider two source models using the following rules:
`¯ Model 602: model defining constraints = {SER1 }
`
`-9-
`
`Page 11 of 326
`
`FORD 1007
`
`

`
`Attorney Docket No.: T00113
`
`¯ MKT10 ALL, MKT20 ALL
`
`¯ ENG1 S MKT1, ENG2 S MKT2, ENG20 MKT1
`
`¯
`
`SER1 S {ENGI+ENG2}
`
`¯ Model 612: model defining constraints = {SER2}
`
`¯ MKT1 O ALL, MKT2 O ALL
`
`¯ ENG 1 S MKT1, ENG2 S MKT2
`
`¯ SER2 S (ENGI+ENG2)
`
`(29) Figure 6 illustrates how the rules for each family combine to yield a set of
`
`buildable configurations. In addition, Figure 6 illustrates how conventional stitching
`
`combines the buildable combinations of models 602 and 612 to create the
`
`consolidated model 622. Shaded portions represent indicated buildable
`
`configurations. For clarity, Figure 6 ignores the effects of the optionalities (’S’,’O’,
`
`...) of the rules. Figure 3 illustrates a DAG for models 602 and 612.
`¯ Model 602: model defining constraints = {SER1 }
`
`¯ The MKT rules restrict the model to buildable combinations 604: all
`buildable combinations that include MKT1 and MKT2.
`
`¯ The ENG rules restrict the model to buildable combinations 606: all
`buildable combinations that include MKT 1.ENG 1, MKT 1.ENG2, MKT2.
`ENG2.
`
`¯ The SER rule restricts the model to buildable combinations 608: all
`buildable combinations that include SER2.
`
`¯ The intersection of the buildable combinations allowed by MKT (604),
`ENG (606) and SER (608) are the buildable combinations allowed by the
`entire model (610): all buildable combinations that include
`MKT1 .ENG1 .SER1, MKT1 .ENG2.SER1, MKT2.ENG2.SER1.
`
`¯ Model 612: model defining constraints = {SER2}
`
`¯ The MKT rules restrict the model to buildable combinations 614: all
`buildable combinations that include MKT1 and MKT 2.
`
`¯ The ENG rules restrict the model to buildable combinations 616: all
`buildable combinations that include MKT1 .ENG 1, MKT2.ENG2.
`
`-10-
`
`Page 12 of 326
`
`FORD 1007
`
`

`
`Attorney Docket No.: T00113
`
`The SER rule restricts the model to buildable combinations 618: all
`buildable combinations that include SER2.
`
`The intersection of the buildable combinations allowed by MKT (614),
`ENG (616) and SER (618) are the buildable combinations allowed by the
`entire model (620): all buildable combinations that include
`MKT1 .ENG1 .SER2, MKT2.ENG2.SER2.
`
`(30) Following are the consolidated model rules generated using conventional
`
`consolidation process 510 and above pseudo code:
`¯ Model 622: model defining constraints = {SERI+SER2}
`
`¯ MKT10 ALL, MKT20 ALL
`MKT10 ALL, MKT20 ALL (624)
`
`¯ ENG1 S MKT1, ENG2 S MKT2, ENG20 MKT1
`ENG1 S MKT1, ENG2 S MKT2 (626)
`
`¯
`
`SER1 S {ENGI+ENG2}
`SER2 S {ENGI+ENG2} (628)
`
`(31) The MKT and ENG rules could not be qualified by the model defining
`
`constraints because doing so would have caused a cycle in the family relationship
`
`DAG as depicted in Figure 4. Especially, the "ENG2 O MKTI" rule was not
`
`qualified by the model defining constraint SER1. The result is that the unspecified
`
`buildable configuration "MKT1 .ENG2.SER2" 636 was added to the buildable
`
`combinations 630 of the combined model 622.
`
`SUMMARY OF THE INVENTION
`
`(32) A model consolidation process combines multiple configuration models into a
`
`single unified configuration model that contains the union of the allowable
`
`combinations (i.e. combinations that are buildable) from each of the original models.
`
`An aspect of at least one embodiment of the model consolidation process is that it
`
`allows models to be combined in such a way that any incompatibilities or
`
`contradictions between models are detected and automatically resolved where
`
`possible. If an incompatibility is detected that cannot be automatically resolved, then
`
`the configuration models should not be combined. Instead if this incompatibility case
`
`occurs, at least one embodiment of the model consolidation process produces a
`
`-11-
`
`Page 13 of 326
`
`FORD 1007
`
`

`
`Attorney Docket No.: T00113
`
`description of the problem encountered and report the problem along with the
`
`necessary information required for a human to resolve it.
`
`(33) One embodiment of the present invention includes a method of consolidating
`
`multiple models, wherein each model comprises only rules that define a non-cyclic
`
`chain of dependencies among families and features of families and include at least
`
`one rule having a constraint that references a non-ancestral family to the constraint.
`
`The method includes combining the models into a single, consolidated model that
`
`maintains the non-cyclic chain of dependencies among families and features of
`
`families.
`
`(34) Another embodiment of the present invention includes a system for
`
`consolidating multiple models, wherein each model comprises only rules that define a
`
`non-cyclic chain of dependencies among families and features of families and include
`
`at least one rule having a constraint that references a non-ancestral family to the
`
`constraint. The system includes a model consolidation module to combine the models
`
`into a single, consolidated model that maintains the non-cyclic chain of dependencies
`
`among families and features of families.
`
`BRIEF DESCRIPTION OF THE DRAWINGS
`
`(35) The present invention may be better understood, andits numerous objects,
`
`features and advantages made apparent to those skilled in the art by referencing the
`
`accompanying drawings. The use of the same reference number throughout the
`
`several Figures designates a like or similar element.
`
`(36) Figure 1 (prior art) depicts a combination of models that generates unspecified
`
`buildable configurations.
`
`(37)
`
`Figure 2 (prior art) depicts a directed acyclic graph ("DAG").
`
`(38)
`
`(39)
`
`Figure 3 (prior art) depicts a DAG for models depicted in Figure 6.
`
`Figure 4 (prior art) depicts a DAG with a cycle for a model representing the
`
`consolidation of models in Figure 6 obtained using a conventional consolidation
`
`process.
`
`-12-
`
`Page 14 of 326
`
`FORD 1007
`
`

`
`Attorney Docket No.: T00113
`
`(40) Figure
`
`5 (prior art) depicts a conventional consolidation system.
`
`(41 ) Figure
`
`6 (prior art) depicts combining rules of two models into a consolidated
`
`model having
`
`specified and unspecified buildable configurations.
`
`(42) Figure
`
`7 depicts a model consolidation system.
`
`(43) Figure 8 depicts the model representations used for Figure 6 and the
`
`consolidation thereof using an embodiment of the model consolidation system of
`
`Figure 6.
`
`(44) Figure 9A depicts combining configuration models into an accurate
`
`consolidation model using the model consolidation system of Figure 7.
`
`(45) Figure 9B depicts a graphical representation of the combination of models into
`
`consolidated model.
`
`(46)
`
`Figure 10 depicts a flowchart of a model consolidation process 1000.
`
`(47) Figure 11 depicts a flowchart for removing unspecified buildable
`
`configurations from a consolidated model.
`
`(48) Figure 12 depicts a network of computer systems in which a model
`
`consolidation system can be used.
`
`(49)
`
`Figure 13 depicts a computer system with which a modeling consolidation
`
`system can be implemented.
`
`DETAILED DESCRIPTION
`
`(50) The term "product" is used herein to generically refer to tangible products,
`
`such as systems, as well as intangible products, such as services.
`
`(51) Contrary to conventional processes, the rules from individual models should
`
`not simply be qualified by the defining constraints for that model and then directly
`
`combined together. The first reason for this is because it is possible that one of the
`
`original models will make a statement that contradicts a statement in one of the other
`
`-13-
`
`Page 15 of 326
`
`FORD 1007
`
`

`
`Attorney Docket No.: T00113
`
`models. If two contradicting statements were present in the unified configuration
`
`model then an inference procedure run on it would never be able to draw a logical
`
`conclusion. Secondly, each configuration model defines a non-cyclic chain of
`
`dependencies among its families and features of families. The problem with
`
`conventional stitching algorithms can occur, for example, whenever model defining
`
`constraints reference families that have DAG ancestors and the DAG ancestors are not
`
`referenced by model defining constraints. In this instance, the DAG is a union of all
`
`family relationships across all models. Thus, if the defining constraint features are
`
`ancestral features and are added to the RHS of every rule in the model as with
`
`conventional consolidation processes, a cycle would be introduced into this chain of
`
`dependencies. In order to avoid introducing these cycles and still combine the
`
`individual models together into a consolidated model, an intelligent algorithm is
`
`required.
`
`(52) A model consolidation process, such as model consolidation process 710,
`
`represents a process for combining multiple configuration models into a single unified
`
`configuration model that contains the union of the allowable combinations (i.e.
`
`combinations that are buildable) from each of the original models. An aspect of at
`
`least one embodiment of the model consolidation process is that it allows models to
`
`be combined in such a way that any incompatibilities or contradictions between
`
`models are detected and automatically resolved where possible. If an incompatibility
`
`is detected that cannot be automatically resolved, then the configuration models
`
`should not be combined. Instead if this incompatibility case occurs, at least one
`
`embodiment of the model consolidation process produces a description of the problem
`
`encountered and report the problem along with the necessary information required for
`
`a human to resolve it.
`
`(53) Referring to Figure 7, the model consolidation system 700 includes model
`
`702, which represents a set of N models that may be created and maintained
`
`separately, where N is any integer. Model A 704 is, for example, a configuration
`
`model that describes how a particular product may be built and sold for the USA
`
`market. Model B 706 is a configuration model that, for example, describes how the
`
`same product may be built and sold for the Canadian market. Model N 708 is, for
`
`example, a configuration model that describes how the same product may be built and
`
`-14-
`
`Page 16 of 326
`
`FORD 1007
`
`

`
`Attorney Docket No.: T00113
`
`sold for the Mexican market. Models 704, 706, and 708 may be combined into a
`
`single model 712 by the model consolidation (also referred to as "stitching")
`
`processes 710. The combined model 712 contains stitched rules that represent all the
`
`information present in the original three models without unspecified buildable
`
`configurations.
`
`(54) Figures 8 and 9 depicts the model representations used for Figures 6 and 7 and
`
`the resulting consolidation of the model representations using an embodiment of
`
`model consolidation system 700. For clarity, Figures 8 and 9 ignore the effects of the
`
`optionalities (’ S’, ’O’, ...) of the rules.
`
`(55) There is a conflict between the two models on ENG: MKT1 .ENG2 is released
`
`in Model 602 but not Model 612. Referring to block 832, because the ENG family is
`
`above Model 612’s defining constraint family (SER) in the DAG, we may not adjust
`
`the ENG family by intersecting its space with Model 612’s defining constraint
`
`(SER2). Instead, extend the ENG family in Model