DETAILED ACTION
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Responsive to the communication dated 5/18/2026.
Claims 7, 14, 20 are cancelled.
Claims 21, 22, 23 are newly presented.
Claims 1 – 6, 8 – 13, 15 – 19, 21, 22, 23 are presented for examination
Final Action
THIS ACTION IS MADE FINAL. Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Response to Arguments.
The Applicant asserts that the art of record does not make obvious the amended claim limitations.
The Applicant asserts that while Whang teaches a graphical user interface that Whang does not teach “a product to be designed along with a listing of multiple classes of components or subsystems.” The Applicant merely asserts that Young also does not make this obvious. The Applicant did not provide any rational or evidence of this mere assertion.
In response the argument is not persuasive. Young_2021 clearly teaches a design with hierarchical components with multiple classes of components and two or more subsystems. See Figure 1 which clearly illustrates, for example, a missile that has a component class called tail fins and there are 3 subclasses of tail fins. Figure 1 explicitly shows a graphical listing of these items in part of system infrastructure called a “solution composer.” A solution composer, in this context, is some sort of software application that is used to compose/select from among components and subcomponents.
Whang_2017 further clearly illustrate a solution composer for aircraft. Fig. 8, 9, 4, 5 all clearly illustrate a graphical user interface used for the purpose of composing/selecting the various components and subcomponents to be incorporated into an aircraft. For example, Fig. 8, 9, 4, 5 show components such as galley, closet, lav, partition, attendant seat, etc.
In combination it would be obvious to use the graphical user interface taught by Whang_2017 that is used to select among components and subcomponents to be integrated into an aircraft to display the various component and subcomponent options as illustrated by Young_2021 to have the “solution composer” as taught by Young_2021.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claim(s) 1 - 20 are rejected under 35 U.S.C. 103 as being unpatentable over Young_2021 (How Missile Engineering is Taking Product Line Engineering to the Extreme at Raytheon, 31st Annual INCOSE International Symposium, Honolulu, HI, USA July 17 – 22, 2021) in view of Krueger_2016 (US 2016/0078384 A1) in view of Whang_2017 (US 2017/0103159 A1).
Claim 1. Young_2021 makes obvious “A method comprising: obtaining, , initial information associated with a product to be designed, at least some of the initial information identifying an intended application for the product to be designed (page 3: “… governed technical design artifacts for reusable modular components. These component designs are governed by a governance body to ensure compliance with standards and business goals to meet the business needs…; Figure 1: governing body defines the reference model, component team develop component and store component data Page 4: “… Feature-based Product Line Engineering provides… shared assets are the “soft” artifacts that support the creation, design, implementation, deployment, and operation of products. A shared asset can be any artifact representable digitally: requirements, design models, source code, test cases, BoMs, wiring diagrams, documents, and user manuals, installation guides, and more… a shared asset used in the product line takes the form of a superset… for our missiles… Technical Data Package…”; Page 8 section 5: “… a technical data package (TDP) is a collection of technical data – models, documents… describing the missiles architecture, design… the TDP contains information and documents which we have made shared assets… that contains the feature catalogue and assertions that allow us to create an manage the trade space for a missile…”; Page 10 Specification Documents: “… people may even create documents… Feature-based PLE allows a superset of requirements to be created at the system level, at the product line level of subsystems, and at the component level…”) Identifying, multiple features associated with the product to be designed based on the initial information (page 3: “… to compose a missile product, we develop a missile reference model. The missile reference model defines the ontology of missile components – that is, it defines what components a missile does or can comprise…” Figure 2: Feature Catalogue ); Identifying,nd for each of the multiple features, one or more feature options that are acceptable for use in the intended application (Page 3: “… solution composer… allows the user to compose different design options by selecting desired features (in the sense of Feature-based PLE – see next section) of the solution. The composer then selects the feasible combinations of component variants to meet the missiles requirements…”; Figure 2: “Bill-of-Features Portfolio ); Identifying, and for each of the multiple features, one or more components or subsystems that are associated with the one or more acceptable feature options for that feature, at least some of the identified components or subsystems being reusable in multiple products (Figure 1: Solution Composer illustrates alternative reusable sub-components that are acceptable for features. For example, tail fine feature has three alternatives. Nose cone feature has two alternatives. Figure 2: illustrates shared assets are selected by the PLE Factory Configurator); Generating, multiple feasible candidate product configurations based on the identified components or subsystems, each feasible candidate product configuration representing a potential design for the product and being acceptable for use in the intended application (abstract: “… automatic generation, exploration, an pruning of an automatically generated trade space of possible missile designs that satisfy a given set of requirements…”; Figure 1: “trade models”; Figure 2: illustrate “product asset instances”; page 6: “… the configurator automates the generation of valid product configurations and outputs the products to a trade study…”; Figure 4 illustrates configurations output from the configurator); Performing,one or more simulations or analysis associated with each of the feasible candidate product configurations, at least one of the one or more simulations or analyses estimating performance of each of the feasible candidate product configurations (page 2: “… a viable design that meets its requirements (we refer to his set of all possible combinations as the missile trade space.) a significant part of the effort to compose a missile, even from a portfolio of existing parts, is the need to integrate with performance simulations, design models, flight control simulations, six-degree-of-freedom simulation, and more, to perform trade analysis and verify that performance requirements will be met. Adding the simulation capability to virtually simulate the physical hardware provides the added benefit of composing a digital twin…”; page 3: “… the solution composer is integrated with simulation capabilities to provide digital twin capabilities to ensure performance requirements can be met and provide insight into any design gaps or needed changes…”; Figure 1 illustrates “performance design and trade models and simulations” are performed as part of an analysis of the trade models composed of identified parts from solution composer. Figure 4: “trade study”; Page 9: “… a SysML model for a particular missile that can now be used as the basis for further analysis…”; page 13: “… generate validation and simulations for chosen candidates, to speed up qualification (or dis-qualification) of design candidates…”); and generating, (i) one or more of the feasible candidate product configurations and (ii) one or more results associated with the one or more simulations or analysis or information based thereon (Page 2: “… Adding the simulation capability to virtually simulate the physical hardware provides the added benefit of composing a digital twin…”; Figure 1: illustrates “trade models and simulations” and illustrates charts of the simulation results Figure 4: illustrates “trade study” loop and “resulting in only feasible designs” Figure 5 illustrates the process of paring down the trade space to selection of meaningful product configurations) a listing of multiple classes of components or subsystems, at least one of the classes containing to or more components or subsystems that are each usable in the product” (Figure 1 illustrates a solution composer section that illustrates a plurality of classes with more than one component/subsystem that are usable for the product. Figure 1 clearly illustrates, for example, a missile that has a component class called tail fins and there are 3 subclasses of tail fins. Page 8/16 section 5: “… Bills of materials…” Young_2021, however, merely doesn’t illustrate a graphical user interface.)
Because Young_2021 teaches a system that includes automation and illustrates graphical windows interfaces (Fig. 3, 8) typical of computers with operating systems, it may properly be found that it would have been obvious to those of ordinary skill in the art to use at least one processing device (i.e., computer with an operating system) to execute the approach taught by Young_2021. Nevertheless, Young_2021 does not EXPLICITLY recite: “using at least one processing device” nor “using the at least one processing device” nor “a graphical user interface that identifies” nor “Wherein the graphical user interface presents a graphical representation of the product to be designed along with”
Krueger_2016 makes obvious “using at least one processing device” and “using the at least one processing device” (FIG. 8 “computing device”; FIG. 9: processor 901, memory 903, graphics control 921, display 932; Par 51: “… a first embodiment of a computing device 800, such as, for example, a server, used to implement one or more parts of the creation of software representation of feature bundles in accordance with an embodiment of the present invention…”; par 55: “The computing device 900 can include a processor 901, memory 903 and storage 908… all or a portion of the elements 901 – 936 can be housed in a single unit…”)
Young_2021 and Krueger_2016 are analogous art because they are from the same field of endeavor called product line/level engineering and/or creating product option for a family of similar products.
Before the effective filing date, it would have been obvious to a person of ordinary skill in the art to combine Young_2021 and Krueger_2016. The rationale for doing so would have been that Young_2021 teaches a method for doing product line engineering (i.e., feature-based Product Line Engineering: FbPLE) to create product options for a family of similar products. Young_2021 teaches configurators that are “an automated software tool” (page 5) and to “automates the generation of valid product configurations” (page 6). Krueger_2016 also teaches to perform Product Line Engineering and further teaches to use a computing device to perform Product Line Engineering. Kreuger_2016 also teaches “the present invention serves to dramatically simplify and automate the creation of product option codes” (par 8). Therefore, it would have been obvious to combine Young_2021 and Krueger_2016 for the benefit of having a device that automates aspects Product Line Engineering to obtain the invention as specified in the claims.
Young_2021 and Krueger_2016 does not explicitly recite: “a graphical user interface that identifies.” Nor “Wherein the graphical user interface presents a graphical representation of the product to be designed along with”
Whang_2017, however, makes obvious “a graphical user interface that identifies” (i) one or more of the feasible candidate product configurations and (ii) one or more results associated with the one or more simulations or analysis or information based thereon (FIG. 3, 4, 5, 6, 7, 8, 9; FIG. 10 block 1008: “… display user interface for selected layout of passenger arrangements optimization tool; receive and process operator input via user interface to optimize layout of passenger arrangements using previously designed configurations…”; par 2: “… designing and manufacturing aircraft…”; par 4: “designing an aircraft or other platform may include placing various structures in a design for the aircraft or other platform…”; par 5: “a designer may use a computer-implemented design tool to indicate the desired placement for various structures in a design… or other platform… such an engineering design may specify structural, mechanical, electrical, heating, air circulation, water supply, waste water drainage, or various other components…”; par 9: “an illustrative embodiment of the disclosure provides… a graphical representation of the layout of passenger arrangement is displayed… a list of the previously designed configurations that may be used is displayed…”; par 10: “… a graphical representation of the layout of passenger arrangement is displayed…”; par 33: “the different illustrative embodiments recognize and take into account that different purchasers or users of aircraft may have different requirements…”; par 35: “… illustrative embodiments may reduce the amount of time and cost needed to generate engineering designs for configurations of commodities…”; par 41: “… aircraft 105 may be optimized by using previously designed layouts…”; par 49: “… visualization tool 212 may be configured… parts used on tool 218 may be configured for displaying parts information for parts used to implement commodities…”; par 60: “… a user interface for the selected layout of passenger arrangements optimization tool may be displayed, and the operator input via the user interface may be received and processed to optimize the layout of passenger arrangements using previously designed configurations…” and “Wherein the graphical user interface presents a graphical representation of the product to be designed along with” ((Figures 3, 4, 5, 6, 7, 8, 9; par 9: “… a list of the previously designed configurations that may be used is displayed in response to an operator selecting the location of the commodity… an input by an operator selecting a selected previously designed configuration from the list of previously designed configurations is received. The layout… is changed to include the selected previously designed configuration…”; Par 39: “… layout of passenger arrangement information 122 may include appropriate information for use by aircraft manufacturing system 104 to implement layout…”; Par 47: “previously designed layout of passenger arrangements identification tool 208 may be configured for identifying and selecting a previously designed layout of passenger arrangements for an aircraft… to identify and display a previously designed layout…”; Par 48: “previously design configurations identification and selection tool 210 may be configured for designing a layout of passenger arrangements for an aircraft using previously designed configurations… user interface 400 for previously designed configuration identification and selection tool… identification and selection tool 210 to identify and select…”).
Young_2021 and Whang_2017 are analogous art because they are from the same field of endeavor called creating new designs using previous designs. Before the effective filing date, it would have been obvious to a person of ordinary skill in the art to combine Young_2021 and Whang_2017. The rationale for doing so would have been Young_2021 teaches to use previously design components (e.g., shared assets, etc.) to configure new products and to perform trade studies with user input pare down the trade space to have feasible designs. (Figure 4). Whang_2017 teaches to have a graphical user interface by which the user and select previous designs from which new designs can be created and that by doing so designs can achieve the requirements of different purchasers. Therefore, it would have been obvious to combine Young_2021 and Whang_2017 for the benefit of having an interface by which a user can iterate and optimize designs to meet purchaser requirements to obtain the invention as specified in the claims.
Claim 8. The limitations of claim 8 are substantially the same as those of claim 1 and are rejected due to the same reasons as outlined above for claim 1. Krueger_2016 also makes obvious the further limitations of “An apparatus comprising: at least one processing device configured to:” (FIG. 8 “computing device”; FIG. 9: processor 901, memory 903, graphics control 921, display 932; Par 51: “… a first embodiment of a computing device 800, such as, for example, a server, used to implement one or more parts of the creation of software representation of feature bundles in accordance with an embodiment of the present invention…”; par 55: “The computing device 900 can include a processor 901, memory 903 and storage 908… all or a portion of the elements 901 – 936 can be housed in a single unit…”)
Claim 15. The limitations of claim 15 are substantially the same as those of claim 1 and are therefore rejected due to the same reasons as outlined above for claim 1. Krueger_2016 also makes obvious the further limitations of “A non-transitory computer readable medium containing instructions that when executed cause at least one processor to:” (FIG. 8 “computing device”; FIG. 9: processor 901, memory 903, graphics control 921, display 932; Par 51: “… a first embodiment of a computing device 800, such as, for example, a server, used to implement one or more parts of the creation of software representation of feature bundles in accordance with an embodiment of the present invention…”; par 55: “The computing device 900 can include a processor 901, memory 903 and storage 908… all or a portion of the elements 901 – 936 can be housed in a single unit…”)
Claim 2, 9, 16. Krueger_2016 also makes obvious “Wherein: the initial information is obtained from a user; and Identifying the multiple features associated with the product to be designed comprises mapping the initial information to the multiple features using a feature model” (par 5: “… product option codes are often used to create the mapping from an option selection… this requires engineers to create mappings from product option codes to thousands of part…”; par 8: “… the invention splits the mapping into two mappings, one that is difficult and done once plus one that is easy and repeated to get the product option codes…”; par 11: “the majority of the mapping effort goes into the single mapping from multistage configuration trees…”).
Claim 3, 10, 17. Young_2012 makes obvious “Wherein the identifying the one or more feature components for each feature comprises: Identifying a feature profile definition for each feature, the feature profile definition identifying all feature options available for that feature; and
Disregarding at least one feature option in one or more of the feature profile definitions based on (i) the intended application or (ii) the initial information, one or more remaining feature options in each feature profile definition representing the one or more acceptable feature options for the associated feature” (page 5 Feature Catalogue, Bill-of-Features, Figure 2 illustrates a feature catalogue and the bill-of features disregards at least one feature option in the feature catalogue. Page 7: “… product families are groupings of product based on their features…”).
Krueger_2016 also makes obvious “…feature profile definitions based on (i) the intended application…” (par 5 – 8: “… product option codes are often used to create an option selection… for example, a “sport package” option for a pickup truck family may be different from the “sport package” for a luxury sedan family…”; par 47 – 50: “… configuration tree 700 with feature bundles applied. It is an example of how feature bundles might be used in practice… P701 represents the feature configurations offered by the product engineering team… nodes in the tree, node P-US 702 and node P-China 703, represent the manufacturable products for the US and China markets, respectively… salable product configurations for the standard (S), midrange (M) and premium (X) tiers of both the US and China markets…” EXAMINER NOTE: teaches feature profiles for different intended applications (US vs. China, trucks, sedans, etc.)
Claim 4, 11. Young_2021 makes obvious “Wherein identifying the one or more components or subsystems for each feature comprises: identifying, using a digital library of components and subsystems, one or more components or subsystems associated with each acceptable feature option for the associated feature” (Figure 1: Digital Library and Solution Composer).
Claim 5, 12, 18 Young_2021 makes obvious “Wherein generating, the multiple feasible candidate product configurations comprises: generating at least one of the feasible candidate product configurations using user inputthe user input identifying one or more user-selected components or subsystems to be used in the at least one feasible candidate product configurations” (page 3: “… solution composer… the solution composer allows the user to compose different design options by selecting desired features… of the solution. The composer then selects the feasible combinations of component variants to meet the missile’s feature requirements…”).
Whang_2017 makes obvious “Wherein generating, the multiple feasible candidate product configurations comprises: generating at least one of the feasible candidate product configurations using user input received via the graphical user interface, the user input identifying one or more user-selected components or subsystems to be used in the at least one feasible candidate product configurations” (FIG. 3, 4, 5, 6, 7, 8, 9; FIG. 10 block 1008: “… display user interface for selected layout of passenger arrangements optimization tool; receive and process operator input via user interface to optimize layout of passenger arrangements using previously designed configurations…”; par 2: “… designing and manufacturing aircraft…”; par 4: “designing an aircraft or other platform may include placing various structures in a design for the aircraft or other platform…”; par 5: “a designer may use a computer-implemented design tool to indicate the desired placement for various structures in a design… or other platform… such an engineering design may specify structural, mechanical, electrical, heating, air circulation, water supply, waste water drainage, or various other components…”; par 9: “an illustrative embodiment of the disclosure provides… a graphical representation of the layout of passenger arrangement is displayed… a list of the previously designed configurations that may be used is displayed…”; par 10: “… a graphical representation of the layout of passenger arrangement is displayed…”; par 33: “the different illustrative embodiments recognize and take into account that different purchasers or users of aircraft may have different requirements…”; par 35: “… illustrative embodiments may reduce the amount of time and cost needed to generate engineering designs for configurations of commodities…”; par 41: “… aircraft 105 may be optimized by using previously designed layouts…”; par 49: “… visualization tool 212 may be configured… parts used on tool 218 may be configured for displaying parts information for parts used to implement commodities…”; par 60: “… a user interface for the selected layout of passenger arrangements optimization tool may be displayed, and the operator input via the user interface may be received and processed to optimize the layout of passenger arrangements using previously designed configurations…”).
Claim 6, 13, 19. Young_2021 makes obvious “Wherein the one or more simulations or analyzes associated with each feasible candidate product configuration comprises performing at least one trade study involving the feasible candidate product configuration” (Figure 4: “trade study”).
Claim 21 are rejected under 35 U.S.C. 103 as being unpatentable over Young_2021 in view of Krueger_2016 in view of Whang_2017 in view of Vaujour_2021 in view of Chandramohan_2014 (US 8,806,406 B2).
Claim 21. Vaujour_2021 makes obvious “wherein performing the one or more simulations or analysis comprises: automatically [using] design parameters of each feasible candidate product configuration; and providing thedesign parameters as inputs to one or more simulation environments” (Par 32: “… validate these system configurations using modelling and simulation (e.g., to provide automated trade studies)… the various system configurations… are compared… the evaluation system can run an evaluation process continuously and automatically…” EXAMINER NOTE: the trade studies are automatic simulations that compare each candidate. PAR 74: “… additional system configurations can be automatically generated and validated…”; par 81: “… system configurations can be generated automatically…”; Par 42: “… data for models… includes one or more of: characteristics… parameters… state variables, control variables…”; par 46: “… system configuration 124 includes one or more of: characteristics, parameters, state variables, control variables, and environment variables…”; par 78: “… each model identifies one or more parameters…”; par 79: “… a model for a device that includes a power source identifies power supply parameters (e.g., max power output, charge capacity, charge rate, voltage ranges, max current, etc.)…”; par 112: “generating simulation output for a system configuration S230 can include generating values for one or more system parameters… any suitable parameters can be simulated…”; par 116: “… showing simulated values for one or more system parameters over time…”; par 118: “… parameter constraints include one or more of threshold values, ranges, rules, and the like. Comparing simulated values with constraints…”).
Young_2021 and Vaujour_2021 are analogous art because they are from the same field of endeavor called evaluation of system variants/configurations. Before the effective filing date, it would have been obvious to a person of ordinary skill in the art to combine Young_2021 and Vaujour_2021.
The rationale for doing so would have been that Young_2021 teaches to perform trade study simulations and to produce feasible system artifacts called technical data packages (TDP) that include part manifests called bills of materials (BOM). Vaujour_2021 teaches to perform trade studies using cloud storage for storing artifacts and that the artifacts include assembly instructions and these assembly instruction artifacts are used as inputs to the trade study simulations. Therefore, it would have been obvious to combine the technical data package (TDP) artifacts including the bill of materials which is a list of parts used in the assembly of a feasible configuration taught by Young_2021 with the cloud storage and trade study simulations taught by Vaujour_2021 for the benefit of having assembly information that defines the parts used in the trade study simulation to obtain the invention as specified in the claims.
While Vaujour_2021 clearly teaches that parameters at included in the model configurations and that the simulations use the parameters and parameter constraints, Vajour_2021 does not explicitly teach that the parameters are “extracted.”
Chandramohan_2014 makes obvious “extracted” and “extracting” (abstract: “… the computer system extracts… a parasitic netlist of a part of the circuit design… the parasitic netlist is a list of parasitic nets… the computer system performs simulation of the circuit design including the netlist of a circuit design and the parasitic netlist of the part of the circuit design…”; par 39: “… model the interconnect parasitics using parameters…”)
Vaujour_2021 and Chandramohan_2014 are analogous art because they are from the same field of endeavor called design simulation and/or validation. Before the effective filing date, it would have been obvious to a person of ordinary skill in the art to combine Vaujour_2021 and Chandramohan_2014.
The rationale for doing so would have been that Vaujour_2021 teaches to automatically perform design configuration simulations as part of a trade study and teaches that the simulations use parameters and that the design configurations use parameters and the models have parameters. Chandramohan_2014 teaches to extract design parameters and provide the design parameters to simulation. Therefore, it would have been obvious to combine Vaujour_2021 and Chandramohan_2014 for the benefit of getting the relevant parameters used in the simulations to obtain the invention as specified in the claims.
Claim 22 is rejected under 35 U.S.C. 103 as being unpatentable over Young_2021 in view of Krueger_2016 in view of Whang_2017 in view of Vaujour_2021 (US 2021/0110502 A1) in view of Baldow_2017 (MAGPI: Simplifying access and execution of computational models in the life sciences, PLOS Computational Biology, 2017).
Claim 22. Young_2021 makes obvious “wherein performing the one or more simulations or analyses comprises: generating, for each feasible candidate product configuration, a parts manifest identifying a combination of components or subsystems usable for the intended application (Figure 2 illustrates the configurator creating “product asset instances” according to “BILL-OF-Features Portfolio” page 8 section 5 par 1: “a technical data package (TDP) is a collection of technical data – models, documents, drawings and bills of materials… of the trade space… we can use its features to create the TDP for it…” EXAMINER NOTE: therefore, each member of the trade space (i.e., feasible candidate) has a bill-of-materials that that identify combination of components used in that trade model. Figure 1 illustrates “performance design and trade model and simulations”. Figure 4 illustrates to perform a “trade study” which is a simulation of configuration variants and produces the feasible designs. EXAMINER NOTE: therefore, feasible designs are produced (fig 4) and simulations are performed (Fig. 1) and the technical data packages for the feasible designs include bills of materials (i.e., parts manifests)
While Young_2021 clearly teaches to perform trade studies using models and simulations (Figure 1, Figure 4) and to generate artifacts for feasible designs stored in a technical data package (TDP) and where the technical data package includes an artifact known as a bill-of materials, Young_2021 does not teach to store the technical data package (TDP) which includes the bill of materials (BOM) in cloud storage.
Therefore, Young_2021 does not recite: “storing the parts manifest in cloud storage; performing at least one simulation for the feasible candidate product configuration using the parts manifest; and providing results of the at least one simulation to a computing system implementing the graphical user interface via a messaging service.”
Vaujour_2021, however, makes obvious “Storing the parts manifest in cloud storage (par 28: “the system can be a local (e.g., on-premise) system, a cloud-based system, or any combination of local and cloud-based systems…”; par 30: “the system data repository 120 can be any suitable type of data repository. The repository 120 can be implemented using any suitable type of storage device (or combination of several storage devices). The repository can be an on-premise storage device, or a cloud-based storage device (e.g., included in a single or multi-tenant cloud-based storage platform)…”; par 127: “… artifacts are stored in the repository 120 in a machine-readable format such that they can be retrieved from the repository in response to execution of a query by any suitable computing system… in some variants, stored artifacts S250 include… functional specifications, requirements documents, test documents, test plans, regulatory compliance documents, system assembly instructions, and the like.…” EXAMINER NOTE: A parts list/manifest such as a bill-of-materials is made obvious by the system assembly instructions because a list/manifest of parts is a list of parts used in the assembly of the system.); Performing at least one simulation for the feasible candidate product configuration (par 132: “in some implementations, the evaluation system 110 functions to validate one or more system configurations… the evaluation system can allow… manufacturer or service provider to assess the viability of various system configurations… generate system configurations… and then assess and validate these system configurations using modelling and simulation (e.g., to provide automated trade studies)… the various system configurations… are compared to analyze… the evaluation system can run an evaluation process continuously and automatically to provide an ongoing visualization of the performance of validated system configurations as more potential system configurations… are added or updated to a data repository (e.g., 120)…”) using the parts manifest (par 127: “… artifacts are stored in the repository 120 in a machine-readable format such that they can be retrieved from the repository in response to execution of a query by any suitable computing system… in some variants, stored artifacts S250 include… functional specifications, requirements documents, test documents, test plans, regulatory compliance documents, system assembly instructions, and the like. However, any suitable type of documentation can be generated…”; par 130: “… artifacts stored at S250 can be used as inputs for processes performed at one or more of: S220 (generating system configurations), S230 (generating simulation outputs), 8240 (Validating system configuration), and S250 (evaluating validated system configurations)…” EXAMINER NOTE: the above teaches to store artifacts into cloud storage and that the artifacts include system assembly instructions and that the system assembly instructions can be used as input to the simulation in order for the simulation to generate simulated outputs. Also, a parts list/manifest such as a bill-of-materials is made obvious by the system assembly instructions because a list/manifest of parts is a list of parts used in the assembly of the system.); and providing results of the at least one simulation to a computing system implementing the graphical user interface (par 38: “… the evaluation system 110 includes one or more of… a trade space visualizer 116…”; par 132: “… the trade space visualizer 116 evaluates validated system configurations at S260…”; par 133: “in variants, evaluating validated system configurations includes displaying data for one or more system configurations (e.g., in a user interface), along with predefined selection criteria. Information can be displayed in any suitable manner, such as by using a histogram, scatter plat, parallel coordinate plot, and the like. In variants, evaluating validated system configurations includes displaying a user interface that provides a user-friendly interpretation of complex design trades by identifying and labeling clusters of similar system configurations and visually depicting Pareto fronts. However, validated system configurations (and related data) can be otherwise displayed for selection by a user…”
Par 39: “… a graphical user interface…”; par 90: “… graphical user interface (GUI)… evaluation system 110 provides the graphical user interface…”; par 63: “… one or more of the components of the system 100… are implemented as a hardware device that includes one or more of a processor (e.g., a CPU (central processing unit), GPU (graphical processing unit), NPU (neural processing unit), etc.)… one or more components included in hardware device are communicatively coupled via a computing system bus… coupled to an external system via the communication interface…”)
Young_2021 and Vaujour_2021 are analogous art because they are from the same field of endeavor called evaluation of system variants/configurations. Before the effective filing date, it would have been obvious to a person of ordinary skill in the art to combine Young_2021 and Vaujour_2021.
The rationale for doing so would have been that Young_2021 teaches to perform trade study simulations and to produce feasible system artifacts called technical data packages (TDP) that include part manifests called bills of materials (BOM). Vaujour_2021 teaches to perform trade studies using cloud storage for storing artifacts and that the artifacts include assembly instructions and these assembly instruction artifacts are used as inputs to the trade study simulations. Therefore, it would have been obvious to combine the technical data package (TDP) artifacts including the bill of materials which is a list of parts used in the assembly of a feasible configuration taught by Young_2021 with the cloud storage and trade study simulations taught by Vaujour_2021 for the benefit of having assembly information that defines the parts used in the trade study simulation to obtain the invention as specified in the claims.
While the combination of Young_2021 and Krueger_2016 and Whang_2017 and Vaujour_2021 teach graphical user interfaces, Young_2021 and Krueger_2016 and Whang_2017 and Vaujour_2021 does not teach implementing the GUI “via a messaging service.”
Baldow_2017 makes obvious providing results of the at least one simulation to a computing system implementing the graphical user interface “via a messaging service” (Abstract: “MAGPI, a Modeling and Analysis Generic Platform with Integrated Evaluation, closes the gap by providing a software platform for both, publishing and executing computational models without restriction on the programming language… MAGPIE to improve transparency and reproducibility of computational models…”; page 3/11: “… the central layers of MAGPIE are a repository of models and analysis tools, a project-orientated access to the models that allows changing parameter configurations and data input, program execution, visualization of results, as well as a twitter-like hashtag system to simplify the sharing of results increasing the visibility of individual researchers…”; Fig. 2 “G” tagging system; page 5/11: “… the user is notified when a job is finished and can immediately view the results in the browser (Fig. 2F). Projects and models of interest can be tagged, shared with other researchers and discussed via the integrated messaging service (Fig. 2G)…”; page 8/11: “… MAGPIE provides the option to share and announce new models, projects, results and feedback via a Twitter-like messaging system. In MAGPIE, hashtags can be assigned to models, projects, or messages. Users can define which topics they are interested in and retrieve updates about projects or researchers of interest… this structure allows using MAGPIE as a platform for collaborative efforts…”).
Vaujour_2021 and Baldow_2017 are analogous art because they are from the same field of endeavor called model execution and simulation. Before the effective filing date, it would have been obvious to a person of ordinary skill in the art to combine Vaujour_2021 and Baldow_2017. The rationale for doing so would have been that Vaujour_2021 teaches to have a cloud based repository for simulations. Baldow_2017 teaches to execute computational models without restriction and to improve transparency and reproducibility of computational model by combining the computational simulations with a integrated messaging service that provides results in graphical form which improves collaborative efforts. Therefore, it would have been obvious to combine the trade study simulations with MAGPIE and integrated messaging services for the benefit of improved collaborative efforts, improved transparency and reproducibility of computational models and simulations to obtain the invention as specified in the claims.
Claim 23 are rejected under 35 U.S.C. 103 as being unpatentable over Young_2021 in view of Krueger_2016 in view of Whang_2017 in view of Vaujour_2021 in view of Baldow_2017 in view of Caruso_2012 (US 2012/0197995).
Claim 23. Vaujour_2021 makes obvious “wherein the graphical user interface comprises adisplay configured to compare multiple saved feasible candidate product configurations the display including (Par 39: “… a graphical user interface…”; par 90: “… graphical user interface (GUI)… evaluation system 110 provides the graphical user interface…”; par 32: “… automated trade studies. In an example, the various system configurations… and their performance in a simulated mission, are compared…” EXAMINER NOTE: a trade study make obvious to compare the results of simulations from various system configurations because a trade study is a structured, analytical decision-making tool used by engineers and project teams to compare competing design alternatives or solutions against a set of conflicting criteria, such as cost, weight, performance, and schedule, to select the single best option)
At least one comparison section comparing results of studies for the multiple saved feasible candidate product configurations; and A control configured to selectively show differences between the multiple saved feasible candidate product configurations by displaying highlighting or other indicators for entries that differ from one another (par 32: “… automated trade studies. In an example, the various system configurations… and their performance in a simulated mission, are compared…”; par 38: “… the evaluation system 110 includes one or more of… trade space visualizer 116…”; par 132: “… the trade space visualizer 116 evaluates validated system configurations…”; par 133: “… In variants, evaluating validated system configurations includes displaying data for one or more system configurations (e.g., in a user interface), along with predefined selection criteria. Information can be displayed in any suitable manner, such as by using a histogram, scatter plot, parallel coordinate plot, and the like. In variants, evaluating validated system configurations includes displaying a user interface that provides a user-friendly interpretation of complex design trades by identifying and labeling clusters of similar system configurations and visually depicting Pareto fronts. However, validated system configurations (and related data) can be otherwise displayed for selection by a user…” EXAMINER NOTE: labeling design trades in the trade study makes obvious to display other indicators for entities that differ.).
Young_2021 and Vaujour_2021 are analogous art because they are from the same field of endeavor called evaluation of system variants/configurations. Before the effective filing date, it would have been obvious to a person of ordinary skill in the art to combine Young_2021 and Vaujour_2021.
The rationale for doing so would have been that Young_2021 teaches to perform trade study simulations and to produce feasible system artifacts called technical data packages (TDP) that include part manifests called bills of materials (BOM). Vaujour_2021 teaches to perform trade studies using cloud storage for storing artifacts and that the artifacts include assembly instructions and these assembly instruction artifacts are used as inputs to the trade study simulations. Therefore, it would have been obvious to combine the technical data package (TDP) artifacts including the bill of materials which is a list of parts used in the assembly of a feasible configuration taught by Young_2021 with the cloud storage and trade study simulations taught by Vaujour_2021 for the benefit of having assembly information that defines the parts used in the trade study simulation to obtain the invention as specified in the claims.
While Vaujour_2021 indicates that the system configurations have an ID (Figure 4C) and simulations have an ID (Figure 4D), Vaujour_2021 does not explicitly teach that there is a simulation report status.
Accordingly, Young_2021 and Vaujour_2021 does not recite: “An identification of each of the multiple saved feasible candidate product configurations; One or more report statuses for each of the multiple saved feasible candidate product configurations” nor “dashboard”
Baldow_2017, however, makes obvious “An identification of each of the multiple saved feasible candidate product configurations; One or more report statuses for each of the multiple saved feasible candidate product configurations” (Fig. 3 illustrates a hashtag which is an indicator of feasible candidate identification. Fig. 3 also illustrates a “status” of the trade study simulation. When the result of the trade study simulation is finished the output of the simulation (i.e., report) is available.
PNG
media_image1.png
653
921
media_image1.png
Greyscale
Vaujour_2021 and Baldow_2017 are analogous art because they are from the same field of endeavor called model execution and simulation. Before the effective filing date, it would have been obvious to a person of ordinary skill in the art to combine Vaujour_2021 and Baldow_2017. The rationale for doing so would have been that Vaujour_2021 teaches to have a cloud based repository for simulations and system configurations. Baldow_2017 teaches to execute computational models without restriction and to improve transparency and reproducibility of computational model by combining the computational simulations with a integrated messaging service that provides results in graphical form which improves collaborative efforts. Therefore, it would have been obvious to combine the trade study simulations with MAGPIE and integrated messaging services for the benefit of improved collaborative efforts, improved transparency and reproducibility of computational models and simulations to obtain the invention as specified in the claims.
While Krueger_2015 teaches to graphical user interface capable of comparing different product configurations (Fig. 8, 9, par 81: “… whether the operator desires to compare part information for different part…… selection of a second part may be received… first selected part and the second selected part then may be displayed at the same time… to allow the desired comparison to be made…”) and while such a graphical user interface with controls for selecting the comparison of two parts may properly make obvious a “dashboard”, Krueger_2015 does not explicitly call the graphical user interface a ”dashboard.”
Caruso_2012 makes obvious “dashboard” that displays identification of feasible system configurations and report status ( FIG. 3 “dashboard” with “my hashtags”; par 19: “… dashboard sceen for the social media content management system…”; par 25: “… hashtag lists screen that can be accessed from the Dashboard…”; par 45: “… the dashboard… adapted for Twitter, provides users with selection tabs to access different functions… providing hashtags…”
Vaujour_2021 and Baldow_2017 and Caruso_2012 are analogous art because they are from the same field of endeavor called displaying information. Before the effective filing date, it would have been obvious to a person of ordinary skill in the art to combine Vaujour_2021 and Baldow_2017 and Caruso_2012. The rationale for doing so would have been that Vaujour_2021 teaches to use computational simulations for trade studies and Baldow_2017 teaches to use a Twitter like messaging system with hashtags for computational simulations. Caruso_2012 teaches to have a dashboard for organizing and accessing hashtag information. Further, Caruso_2012 provides examples of adapting the dashboard to work with Twitter hashtags. Therefore, it would have been obvious to combine the computational simulations identified by, for example, Twitter like hashtags with the dashboard adapted for organizing, selecting, and displaying Twitter hashtag content for the benefit of organizing and viewing the hashtag content for the various computational simulations and product configurations in a trade study to obtain the invention as specified in the claims.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to BRIAN S COOK whose telephone number is (571)272-4276. The examiner can normally be reached 8:00 AM - 5:00 PM.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Emerson Puente can be reached at 571-272-3652. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of published or unpublished applications may be obtained from Patent Center. Unpublished application information in Patent Center is available to registered users. To file and manage patent submissions in Patent Center, visit: https://patentcenter.uspto.gov. Visit https://www.uspto.gov/patents/apply/patent-center for more information about Patent Center and https://www.uspto.gov/patents/docx for information about filing in DOCX format. For additional questions, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/BRIAN S COOK/Primary Examiner, Art Unit 2187
Prosecution Insights