Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Examiner’s Note (EN)
The prior art rejections below cite particular paragraphs, columns, and/or line numbers in the references for the convenience of the applicant. Although the specified citations are representative of the teachings in the art and are applied to the specific limitations within the individual claim, other passages and figures may apply as well. It is respectfully requested that, in preparing responses, the applicant fully consider the references in their entirety as potentially teaching all or part of the claimed invention, as well as the context of the passage as taught by the prior art.
Claim Rejections - 35 USC § 101
35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
Claims 1-11 and 13-19 are rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more.
Claim 1
Step 1: Statutory class – process.
Step 2A Prong One: Does the claim recite an abstract idea, law of nature or natural phenomenon?
Yes
“3) Mental processes – concepts performed in the human mind (including an observation, evaluation, judgment, opinion) (see MPEP § 2106.04(a)(2), subsection III).” MPEP § 2106.04(a).
The claims are directed to an abstract idea of data processing and analysis. The claim recites:
extracting component data from the at least one model reference block;
generating a system model based on the at least one software component model, the component data, and the at least some of the other component data.
The extracting and generating are limitations of mental processes of evaluation, and judgement. By way of example, one can mentally analyze which data needs to be extracted from the components as well as generate a system model based on the various different blocks in the system.
Step 2A Prong Two: Does the claim recite additional elements that integrate the judicial exception into a practical application?
No.
The additional elements are:
receiving at least one software component model;
receiving at least one model reference block associated with the at least one software component model;
storing the component data in a data store comprising other component data from other reference blocks associated with the at least one software component model;
retrieving the component data and at least some of the other component data from the data store;
The receiving, and retrieving components are generic computer components used as a tool. They provide nothing more than mere instructions to implement an abstract idea on a generic computer. Instructions are insignificant extra-solution activity that does not produce a practical application of the abstract idea or amount to significantly more. See MPEP 2106.05(d).
The “data store” is generically linking to a computing apparatus – e.g. using such to retrieve information. See MPEP 2106.05(f). MPEP 2106.05(f) provides the following considerations for determining whether a claim simply recites a judicial exception with the words “apply it” (or an equivalent), such as mere instructions to implement an abstract idea on a computer.
Step 2B: Does the claim recite additional elements that amount to significantly more than judicial exception?
No, as discussed with respect to Step 2A, the additional limitation are data gathering, mere instructions to apply an exception on a generic computer and a general purpose computer. See MPEP 2106.05(f). MPEP 2106.05(f) provides the following considerations for determining whether a claim simply recites a judicial exception with the words “apply it” (or an equivalent), such as mere instructions to implement an abstract idea on a computer.
Additionally, the limitations do not impose any meaningful limits on practicing the abstract idea and therefore the claim does not provide an inventive concept in Step 2B. Further, in regards to step 2B MPEP 2106.05 (d) - II. ELEMENTS THAT THE COURTS HAVE RECOGNIZED AS WELL-UNDERSTOOD, ROUTINE, CONVENTIONAL ACTIVITY IN PARTICULAR FIELDS
Because examiners should rely on what the courts have recognized, or those of ordinary skill in the art would recognize, as elements that describe well‐understood, routine activities, the following section provides examples of elements that have been recognized by the courts as well-understood, routine, conventional activity in particular fields. It should be noted, however, that many of these examples failed to satisfy other considerations (e.g., because they were recited at a high level of generality and thus were mere instructions to apply an exception, or were insignificant extra-solution activity). Thus, examiners should carefully analyze additional elements in a claim with respect to all relevant Step 2B considerations, including this consideration, before making a conclusion as to whether they amount to an inventive concept.
The courts have recognized the following computer functions as well‐understood, routine, and conventional functions when they are claimed in a merely generic manner (e.g., at a high level of generality) or as insignificant extra-solution activity.
• i. Receiving or transmitting data over a network, e.g., using the Internet to gather data, Symantec, 838 F.3d at 1321, 120 USPQ2d at 1362 (utilizing an intermediary computer to forward information); TLI Communications LLC v. AV Auto. LLC, 823 F.3d 607, 610, 118 USPQ2d 1744, 1745 (Fed. Cir. 2016) (using a telephone for image transmission); OIP Techs., Inc., v. Amazon.com, Inc., 788 F.3d 1359, 1363, 115 USPQ2d 1090, 1093 (Fed. Cir. 2015) (sending messages over a network); buySAFE, Inc. v. Google, Inc., 765 F.3d 1350, 1355, 112 USPQ2d 1093, 1096 (Fed. Cir. 2014) (computer receives and sends information over a network); but see DDR Holdings, LLC v. Hotels.com, L.P., 773 F.3d 1245, 1258, 113 USPQ2d 1097, 1106 (Fed. Cir. 2014) ("Unlike the claims in Ultramercial, the claims at issue here specify how interactions with the Internet are manipulated to yield a desired result‐‐a result that overrides the routine and conventional sequence of events ordinarily triggered by the click of a hyperlink." (emphasis added));
• ii. Performing repetitive calculations, Flook, 437 U.S. at 594, 198 USPQ2d at 199 (recomputing or readjusting alarm limit values); Bancorp Services v. Sun Life, 687 F.3d 1266, 1278, 103 USPQ2d 1425, 1433 (Fed. Cir. 2012) ("The computer required by some of Bancorp’s claims is employed only for its most basic function, the performance of repetitive calculations, and as such does not impose meaningful limits on the scope of those claims.");
• iii. Electronic recordkeeping, Alice Corp. Pty. Ltd. v. CLS Bank Int'l, 573 U.S. 208, 225, 110 USPQ2d 1984 (2014) (creating and maintaining "shadow accounts"); Ultramercial, 772 F.3d at 716, 112 USPQ2d at 1755 (updating an activity log);
• iv. Storing and retrieving information in memory, Versata Dev. Group, Inc. v. SAP Am., Inc., 793 F.3d 1306, 1334, 115 USPQ2d 1681, 1701 (Fed. Cir. 2015); OIP Techs., 788 F.3d at 1363, 115 USPQ2d at 1092-93.
The additional elements have been considered both individually and as an ordered combination in the significantly more consideration. This claim is ineligible.
Claim 2 recites generating code using the system model, which is a mental process under Step 2A Prong One, while the “using the system model” is mere instructions to apply an exception on a generic computer under Step 2A Prong Two and 2B.
The additional abstract idea and identified elements whether considered individually or in a combination with the parent claims further do not amount to significantly more than the judicial exception because the elements merely apply the abstract idea to be implemented on a generic computer and therefore the identified claim does not amount to significantly more. See MPEP 2106.05(f). Therefore, the claim is considered ineligible under 35 USC 101.
Claim 3 recites generating simulation variables using the system model, which is a mental process under Step 2A Prong One, while “using the system model” is mere instructions to apply an exception on a generic computer under Step 2A Prong Two and 2B.
The additional abstract idea and identified elements whether considered individually or in a combination with the parent claims further do not amount to significantly more than the judicial exception because the elements merely apply the abstract idea to be implemented on a generic computer and therefore the identified claim does not amount to significantly more. See MPEP 2106.05(f). Therefore, the claim is considered ineligible under 35 USC 101.
Claim 4 recites performing at least one simulation using the system model, which is mere instructions to apply an exception on a generic computer under Step 2A Prong Two and 2B.
The additional abstract idea and identified elements whether considered individually or in a combination with the parent claims further do not amount to significantly more than the judicial exception because the elements merely apply the abstract idea to be implemented on a generic computer and therefore the identified claim does not amount to significantly more. See MPEP 2106.05(f). Therefore, the claim is considered ineligible under 35 USC 101.
Claim 5 recites wherein the at least one model reference block includes at least one block parameter amount to the type of data that makes up a mental process under Step 2A Prong One.
The additional abstract idea and identified elements whether considered individually or in a combination with the parent claims further do not amount to significantly more than the judicial exception because the elements merely apply the abstract idea to be implemented on a generic computer and therefore the identified claim does not amount to significantly more. See MPEP 2106.05(f). Therefore, the claim is considered ineligible under 35 USC 101.
Claim 6 recites wherein extracting the component data from the at least one model reference block is based on the at least one block parameter, which is further specification to a mental process under Step 2A Prong One.
The additional abstract idea whether considered individually or in a combination with the parent claims further do not amount to significantly more than the judicial exception. Therefore, the claim is considered ineligible under 35 USC 101.
Claim 7 recites wherein the at least one block parameter is associated with a category amounts to the type / categorization of data , which is a further specification of performing the mental process under Step 2A Prong One.
The additional abstract idea whether considered individually or in a combination with the parent claims further do not amount to significantly more than the judicial exception. Therefore, the claim is considered ineligible under 35 USC 101.
Claim 8 recites wherein the system model is associated with a steering system of a vehicle, which is an additional element that generically links a vehicle having a system model to the abstract idea under Step 2A Prong Two and 2B.
The additional abstract idea and identified elements whether considered individually or in a combination with the parent claims further do not amount to significantly more than the judicial exception because the elements merely apply the abstract idea to be implemented on a generic computer and therefore the identified claim does not amount to significantly more. See MPEP 2106.05(f). Therefore, the claim is considered ineligible under 35 USC 101.
Claim 9 recites wherein the steering system includes an electronic power steering system, which is an additional element that generically links a vehicle having a system model to the abstract idea under Step 2A Prong Two and 2B.
The additional abstract idea and identified elements whether considered individually or in a combination with the parent claims further do not amount to significantly more than the judicial exception because the elements merely apply the abstract idea to be implemented on a generic computer and therefore the identified claim does not amount to significantly more. See MPEP 2106.05(f). Therefore, the claim is considered ineligible under 35 USC 101.
Claim 10 recites wherein the steering system includes a steer-by-wire steering system, which is an additional element that generically links a vehicle having a system model to the abstract idea under Step 2A Prong Two and 2B.
The additional abstract idea and identified elements whether considered individually or in a combination with the parent claims further do not amount to significantly more than the judicial exception because the elements merely apply the abstract idea to be implemented on a generic computer and therefore the identified claim does not amount to significantly more. See MPEP 2106.05(f). Therefore, the claim is considered ineligible under 35 USC 101.
Claim 11 recites wherein the steering system includes a hydraulic steering system, which is an additional element that generically links a vehicle having a system model to the abstract idea under Step 2A Prong Two and 2B.
The additional abstract idea whether considered individually or in a combination with the parent claims further do not amount to significantly more than the judicial exception. Therefore, the claim is considered ineligible under 35 USC 101.
Claims 13 recites a system for centralized data management of software models (statutory category – machine) the system comprising: a processor; and a memory including instructions that, when executed by the processor, cause the processor to, which is mere instructions to apply an exception on a generic computer under Step 2A Prong Two and 2B. MPEP § 2106.05(f).
The remaining limitations are similar to claim 1 and are rejected under the same rationale. Therefore, the claim is considered ineligible under 35 USC 101.
Claims 14-19 are system claims reciting limitations similar to claims 2-7 respectively and are rejected under the same rationale.
Claim Rejections - 35 USC § 102
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale, or otherwise available to the public before the effective filing date of the claimed invention.
(a)(2) the claimed invention was described in a patent issued under section 151, or in an application for patent published or deemed published under section 122(b), in which the patent or application, as the case may be, names another inventor and was effectively filed before the effective filing date of the claimed invention.
Claim(s) 1-7 and 12-19 are rejected under 35 U.S.C. 102(a)(1) as being anticipated by Kropinski et al. (US20110288840A1).
Regarding Claim 1, Kropinski teaches a method for centralized data management of software models, the method comprising: receiving at least one software component model; receiving at least one model reference block associated with the at least one software component model ([0026] "The model-based simulation software (e.g., Matlab and Simulink software by Mathworks) operates in a Microsoft Windows operating system and involves the connecting of function blocks and corresponding inputs and outputs to create a model. Models are developed in the Windows environment and autocode may be generated based on the developed models. Model-based software is user friendly and allows for easy manipulation of models, function blocks, signals, etc." [0033] "The model generation module 12 generates SIL models. For example, the model generation module 12 may be used to generate a model that may be used in conjunction with a model of a plant, such as a transmission, an engine, a vehicle, or another suitable plant. The model generation module 12 may set up one or more models including hooking inputs and outputs of the newly generated models to objects of other models. Hooking may refer to, for example, connecting the inputs and outputs of a model to signal lines or nodes of a block and/or model. Objects may be nodes, signal lines, inputs, outputs, stored variables, etc." [0039] "The modeling environment based library 42 may include models. For example only, the models may include plant models 52, such as control models 54, sensor models 56, controller area network (CAN) models 58, actuator models 60, transmission models 62, engine models 64, vehicle models 66, and other suitable models." Also see [0051])
extracting component data from the at least one model reference block ([0045] "A parser module 114 extracts information from the source code file 102 and the object code file 110. The parser module 114 produces a definitions file 118 and an extensible markup language (XML) file 122 based on the extracted information. The XML file 122 includes information describing the source code of the source code file 102, such as associated variables, calibrations, functions, algorithms, and other suitable information. The definitions file 118 contains information describing data that is to be exported from one or more libraries." [0059] "Referring now to FIG. 4, a diagram of an exemplary first GUI 402 is presented. The first GUI 402 may include a first set of predetermined options, such as option 406, option 410, etc. For example only, the first set of predetermined options may include arithmetic operators, logical operators, comparison operators, mathematical functions, counters and timers, delay blocks, subsystem blocks, non-linear blocks, control blocks, and filters and averages. The first set of predetermined options may also include, for example, parameters and constants, signals, analysis blocks (such as sources and sinks), model documentation, previously used blocks, examples, and model-based code generation option 414. When the user selects the model-based code generation option 414, the GUI module 240 may open and display a second GUI for the user." Also, [0065])
storing the component data in a data store comprising other component data from other reference blocks associated with the at least one software component model ([0037] "The data processing module 24 selects objects to monitor, retrieves various data, processes various data, etc. Data associated with the monitored objects is stored in object data files 30 in the memory 8. The calibration module 26 allows for calibration of variables or stored values (in calibration files 32) in the memory 8. The calibration module 26 may adjust values of various types including boolean values, scalar values, tabular values, etc" [0050] "The modeling module 160 retrieves data from the XML file 122 and selectively displays retrieved data for the user via the one or more of the GUIs. The user may configure a model in the modeling domain via the one or more GUIs. The modeling module 160 generates a model source code file 164 based on data retrieved from the XML file 122 and the configuration provided by the user. The model source code file 164 includes code that is compatible with the second operating system and operating in the modeling domain. " [0044] "A cross-compiler module 106 compiles the source code. The cross-compiler module 106 may convert the source code into object code and store the object code in an object code file 110.")
retrieving the component data and at least some of the other component data from the data store ([0067-0068] "Regarding the SIL build field 706, the data retrieving module 244 may look to the sub-items of a predetermined item in the file structure 300. For example only, where the un-zipper module 224 extracts the files to the second-level item 314, the data retrieving module 244 may look to the sub-items of the second-level item 314. The data retrieving module 244 may retrieve the name(s) of a predetermined type of sub-item of the predetermined item in the file structure 300. For example only, the data retrieving module 244 may retrieve the name(s) of the XML file(s) of the predetermined item in the file structure 300.")
generating a system model based on the at least one software component model, the component data, and the at least some of the other component data ([0094] "Referring back to FIG. 2, the configuration module 248 generates model-based code (e.g., the code in the model source code file 164) based on the configuration of the second and third SIL GUI's 702 and 1202 and the XML file 122. The model updating module 252 generates a model in the modeling/simulation environment based on the model-based code and the source code DLL file 130. The model updating module 252 may generate the model further based on the static library file 134." also [0059])
Regarding Claim 2, Kropinski teaches further comprising generating code using the system model ([0050] "The modeling module 160 generates a model source code file 164 based on data retrieved from the XML file 122 and the configuration provided by the user. The model source code file 164 includes code that is compatible with the second operating system and operating in the modeling domain. For example only, the model source code file 164 may include s-function code or another suitable type of code. In other words, the model source code file 164 may include code written in an s-function programming language or in another suitable programming language.")
Regarding Claim 3, Kropinski teaches the method of claim 1, further comprising generating simulation variables using the system model ([0041] "The input and output shared variables 44 and 46 may refer to variables that may be shared by one or more models. The input and output shared variables 44 and 46 may include global variables or may include variables that may be associated with one or more models, algorithms, or functions. The function library 48 may include additional standard blocks, such as mathematical functions used to generate one or more blocks." [0071-0075] "The data retrieving module 244 retrieves variables that are associated with the selected virtual model and variables that are available with the model file 176. The variables that are associated with the selected virtual model may be defined, for example, within the XML file. The data retrieving module 244 may populate the drop-down menu 748 of the variables field 714 with the associated variables. When the user selects the variables field 714, the data retrieving module 244 selectively displays the names of the variables in the drop-down menu 748. The user may select one of the variables from the drop-down menu 748. Once one of the variables has been selected from the drop-down menu 748, the user may add the selected variable as an input or an output. The user may add the selected variable as an input by selecting an input option 752 of the variables field 714. The user may add the selected variable as an output by selecting an output option 756 of the variables field 714. The user may add one or more other inputs and/or outputs.")
Regarding Claim 4, Kropinski teaches the method of claim 1, further comprising performing at least one simulation using the system model ([0095] "The simulation module 256 simulates the operation of the generated model with, for example, the model file 176 (i.e., a model of a plant of the vehicle), one or more other modules, etc. The simulation module 256 may also debug the model-based code. The GUI module 240 may display the simulation in one or more GUIs (not shown). The user may use the second and/or third SIL GUIs 702 and 1202 to re-configure and re-generate the model based on the result of the simulation. While shown and presented as being different, one or more of the modules of FIGS. 1B and 2 may be implemented within one or more of the modules of FIG. 1A.")
Regarding Claim 5, Kropinski teaches the method of claim 1, wherein the at least one model reference block includes at least one block parameter ([0060] "Referring now to FIG. 5, a diagram of an exemplary second GUI 502 is presented. The second GUI 502 may include a second set of predetermined options, such as option 506, option 510, etc. For example only, the second set of predetermined options may include a data object wizard option, a model helper option, a create internal types option, a legacy code option, an environment controller option, and a software in the loop (SIL) option 514. When the user selects the SIL option 514, the GUI module 240 may open and display a first SIL GUI for the user." [0071] "The data retrieving module 244 retrieves variables that are associated with the selected virtual model and variables that are available with the model file 176. The variables that are associated with the selected virtual model may be defined, for example, within the XML file. The data retrieving module 244 may populate the drop-down menu 748 of the variables field 714 with the associated variables.")
Regarding Claim 6, Kropinski teaches the method of claim 5, wherein extracting the component data from the at least one model reference block is based on the at least one block parameter ([0071] and [0072] "When the user selects the variables field 714, the data retrieving module 244 selectively displays the names of the variables in the drop-down menu 748. The user may select one of the variables from the drop-down menu 748. Once one of the variables has been selected from the drop-down menu 748, the user may add the selected variable as an input or an output. The user may add the selected variable as an input by selecting an input option 752 of the variables field 714. The user may add the selected variable as an output by selecting an output option 756 of the variables field 714. The user may add one or more other inputs and/or outputs.")
Regarding Claim 7, Kropinski teaches the method of claim 5, wherein the at least one block parameter is associated with a category ([0039] “The modeling environment based library 42 may include models. For example only, the models may include plant models 52, such as control models 54, sensor models 56, controller area network (CAN) models 58, actuator models 60, transmission models 62, engine models 64, vehicle models 66, and other suitable models.” EN: Kropinski defines various categories such as sensors, transmission, engine etc.)
Regarding Claim 12, Kropinski teaches further comprising controlling at least one aspect of a vehicle based on the system model ([0031] "The host control module 6 includes a vehicle system simulation (VSS) control module 10 that controls simulation of one or more vehicle control modules, components and systems of a vehicle. The VSS control module 10 may control: converting source code to model-based code; combining of model-based code generated from source code and model-based code generated via simulation software; and generation of a model based on model-based code." Also see [0096-0098])
Claims 13-19 are system claims reciting limitations similar to claims 1-7 respectively and are rejected under the same rationale.
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.
Claims 8, 10, and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Kropinski et al. (US20110288840A1) in view of Miller et al. (US20090299713A1)
Regarding Claim 8, Kropinski teaches the method of claim 1. Miller teaches wherein the system model is associated with a steering system of a vehicle ([0032-0034] “The system 40 has two rack-positioning motors 48 which are connected to the steering rack assembly 50. A steering rack angle sensor 52 is shown between the angle positioning motors 48 and the steering rack assembly 50 in the model. Two rack-positioning motor control signals 54, one for each of the two rack-positioning motors 48, are sent from steer-by-wire controller 46 to the rack positioning motors. These control signals 54 are depicted by the two arrows (one for each signal) extending from the controller 46 to the motors 48 in the FIGURE… FIG. 2 has been given for illustrative purposes. Functional model tools (e.g., Simulink) typically provide a graphical block diagram language which allows functional models to be written in a modular, hierarchical format. Groups of components are separated into hierarchical levels; the top layer showing the least detail and each succeeding level revealing more detail of each sub-system or component. The skilled person will be familiar with such models.”)
Kropinski and Miller are analogous art because they are from the same field of endeavor in automotive modeling and simulation. While Kropinski teaches creating automotive specific component models, Kropinski does not enumerate all the various components explicitly. Miller models a number of steering components specifically. Before the effective filing date of the invention, it would have been obvious to a person of ordinary skill in the art, to combine Kropinski, and Miller to apply Kropinski’s modelling, simulation and control to various steering configurations that are well known in the art as explicitly disclosed by Miller. “Any suitable functional model may be used in the present invention. Particularly suitable model tasks include Matlab/Simulink from The MathsWorks, Inc (www.mathworks.com), ITI/SimulationX from ITI GmbH (www.simulationx.com), Carsim from Mechanical Simulation Corporation (www.carsim.com) is a particularly suitable task for functional modelling of car systems.” (Miller, [0090])
Regarding Claim 10, Kropinski in view of Miller teaches the method of claim 8. Miller teaches wherein the steering system includes a steer-by-wire steering system ([0031-0032] “Referring to FIG. 2 an illustrative depiction of a functional model of a system is shown. In this example a steer-by-wire system 40 for a vehicle is shown. Hand wheel angle sensors 42 are illustrated. These sensors detect the angle of the hand wheel (i.e., the steering wheel). In the example shown in FIG. 2, three hand wheel sensors 42 are depicted. Providing three such sensors is a common approach to provide redundancy since hand wheel sensor failure has the potential to be extremely severe. Accordingly, three hand wheel angle signals 44 are sent from hand wheel angle sensors 42 to the steer-by-wire controller 46. The path of these three hand wheel angle signals 44 is depicted by the three arrows extending from hand wheel sensors 42 to controller 46 in the FIGURE. The system 40 has two rack-positioning motors 48 which are connected to the steering rack assembly 50. A steering rack angle sensor 52 is shown between the angle positioning motors 48 and the steering rack assembly 50 in the model. Two rack-positioning motor control signals 54, one for each of the two rack-positioning motors 48, are sent from steer-by-wire controller 46 to the rack positioning motors. These control signals 54 are depicted by the two arrows (one for each signal) extending from the controller 46 to the motors 48 in the FIGURE.” Also see [0034-0037])
Regarding Claim 20, Kropinski teaches an apparatus for centralized data management of software models, the apparatus comprising: a computing device configured to:
receive at least one software component model; receive at least one model reference block associated with the at least one software component model ([0026,0033,0039,0051])
extract component data from the at least one model reference block ([0045,0059,0065])
store the component data in a data store comprising other component data from other reference blocks associated with the at least one software component model ([0037,0044,0050])
retrieve the component data and at least some of the other component data from the data store ([0067-0068])
generate a system model associated with a steering system based on the at least one software component model, the component data, and the at least some of the other component data ([0059,0094])
wherein at least one aspect of the
However Kropinski is not relied on for:
wherein at least one aspect of the steering system is controlled based on the system model.
Miller teaches wherein at least one aspect of the steering system is controlled based on the system model ([0032-0034])
For motivation to combine please see claim 8.
Claims 9 and 11 are rejected under 35 U.S.C. 103 as being unpatentable over Kropinski et al. (US20110288840A1) in view of Miller et al. (US20090299713A1) and further in view of Applicant Admitted Prior Art
Regarding Claim 9, Kropinski in view of Miller teaches the method of claim 8. Applicant APA teaches wherein the steering system includes an electronic power steering system ([0003] “A vehicle, such as a car, truck, sport utility vehicle, crossover, mini-van, marine craft, aircraft, all-terrain vehicle, recreational vehicle, or other suitable forms of transportation, typically includes various systems, such as a steering system, which may include an electronic power steering (EPS) system, a steer-by-wire (SbW) steering system, a hydraulic steering system, or other suitable steering system and/or other suitable systems (e.g., such as a braking system, propulsion system, and the like). Such systems of the vehicle typically controls various aspects of vehicle steering (e.g., including providing steering assist to an operator of the vehicle, controlling steerable wheels of the vehicle, and the like), vehicle propulsion, vehicle braking, and the like.”)
Kropinski, Miller, and APA are analogous art because they are from the same field of endeavor in automotive modeling and simulation. While Kropinski teaches creating automotive specific component models, Kropinski does not enumerate all the various components explicitly. Miller models a number of steering components specifically, however, doesn’t enumerate EPS and Hydraulic steering systems. APA enumerates EPS and Hydraulic steering system. Before the effective filing date of the invention, it would have been obvious to a person of ordinary skill in the art, to combine Kropinski, Miller and APA to apply Kropinski’s modelling, simulation and control to various steering configurations that are well known in the art as explicitly disclosed by APA.
Regarding Claim 11, Kropinski in view of Miller teaches the method of claim 8. APA teaches wherein the steering system includes a hydraulic steering system ([0003])
For motivation to combine see claim 9.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Mueller et al. US20160210380A1): discloses block based modeling environment for automotive components.
Katzourakis et al. (US20230077259A1): discloses model based structure for motion control including power steering.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to AMIR DARWISH whose telephone number is (571)272-4779. The examiner can normally be reached 7:30-5:30 M-Thurs.
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, Lewis Bullock can be reached on 571-272-3759. 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.
/A.E.D./Examiner, Art Unit 2199
/LEWIS A BULLOCK JR/Supervisory Patent Examiner, Art Unit 2199
Prosecution Insights