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 .
Response to Arguments
The amendment filed January 31, 2026 has been entered. Claims 1-3, 10-12, and 19 have been amended. The remaining claims are in original or previously presented form. Therefore, claims 1-20 are pending in the application. Claims 1, 10, and 19 are the independent claims.
The applicant’s Remarks, filed January 31, 2026 has been fully considered. The applicant argues, under the heading “Rejection under 35 U.S.C. §103,” that the prior art of record, alone or in combination, does not teach claim 1 as amended. In the last detailed action, which was the Non-final Rejection dated October 1, 2025, the examiner cited Rajkumar et al. (US2020/0090419 A1) in view of Malkowicz et al. (US2009/0222427 A1) to reject claim 1.
The applicant notes in the Remarks on page 10 that Malkowicz teaches counting the duty cycles of landing gear, for example. But the applicant argues that this does not teach present claim 1 in whole or part.
Claim 1 now recites:
A method for vehicle analytics, the method comprising:
receiving data from at least one condition indicator sensor of a vehicle,
wherein the at least one condition [indicator] sensor is configured to measure at least one of
a torque value associated with a steering system,
a handwheel position of a handwheel of the steering system, and
a motor position of a motor of the steering system;
receiving data from at least one usage indicator sensor of the vehicle;
updating a vehicle specific model based on a vehicle master model, the data from the at least one condition indicator sensor, and the data from the at least one usage indicator sensor,
wherein the vehicle master model
represents a class of vehicle corresponding to a vehicle design associated with the vehicle and
is generated based on
at least one design specification characteristic of the class of vehicle corresponding to the vehicle design and
at least one end-of-line characteristic associated with the vehicle, and
wherein the vehicle specific model is generated based on
the vehicle master model and
at least one initial parameter corresponding to at least one end-of-line characteristic of the vehicle,
the at least one initial parameter being one of a plurality of parameters of a parameter set generated based on at least one of nominal design data, as-built data, and in-use data;
identifying, using the vehicle specific model, at least one usage trend of the vehicle;
generating aggregated data based on (i) at least one of the data from the at least one condition indicator sensor of the vehicle and the data from the at least one usage indicator sensor of the vehicle, and (ii) at least one of condition indictor data and usage indicator data associated with at least one other vehicle; and
determining an estimate of a remaining useful life of at least one aspect of the vehicle based on the at least one usage trend of the vehicle and the aggregated data.
The examiner agrees that the cited prior art of Rajkumar et al. (US2020/0090419) in view of Malkowicz et al. (US2009/0222427) does not explicitly teach, as claim 1 does:
wherein the at least one condition [indicator] sensor is configured to measure at least one of
a torque value associated with a steering system,
a handwheel position of a handwheel of the steering system, and
a motor position of a motor of the steering system;
However, the examiner has located art that teaches this. Namely, Gusikhin et al. (US2021/0241128), a Ford disclosure. See paragraph 0005 for tracking the wear on a vehicle component so that a “predicted time to failure” can be estimated and a repair can be made. To do this, the system uses a “damage model” of the component that uses “vehicle operating data.” See paragraph 0033 for the vehicle operating data coming at least in part from sensors 110, as shown in Fig. 1. See paragraph 0036 for the sensors 110 collecting “operational parameters,” including “steering torque”. See paragraph 0037 for the steering subsystem 120” including components 125 which may include a steering wheel, steering rack, a steering gear, “etc.”
See paragraph 0040 for teaching that a “threshold can be determined for each subsystem 120 according to each specific damage model, and can be based on, e.g., manufacturer recommendations, empirical testing of components 125 of the subsystem 120 in test vehicles 101, comparison of performance metrics of damaged components 125 with require performance metrics to operate the vehicle 101, etc.” Thus, Gusikhin also teaches that “manufacturer recommendations” can be a source of life data of a components. Other damage models, such as textbook models, are cited in the paragraph.
It seems to the examiner that this reference can reasonably and obviously be combined with Rajkumar et al. (US2020/0090419). Rajkumar teaches in general a system that tracks the wear of vehicle components to determine if they need to be replaced. Rajkumar does not explicitly mention a steering component, but Gusikhin cures that deficiency. Rajkumar Fig. 2 shows that the system can “select a component for [failure] prediction” in step 206. Paragraph 0053 teaches “For instance a particular tire…could be selected for prediction.” The examples in Rajkumar revolve around the tire, but Fig. 6A shows that data is collected on the “engine” and other areas of the vehicle as well. Fig. 6B shows that a “transmission leak” has been detected several times. It appears that sensors detect these too. Paragraph 0028 teaches detecting tire wear using sensors, and paragraph 0001 teaches that “sensors…installed on components” can be “useful to predict remaining useful life of a component.” Gusikhin merely adds that the sensors from a steering system for use with useful life calculations is known in the prior art.
Gusikhin could also be combined with other cited prior art such as Ahn (US2016/0093119 A1), hereinafter Ahn. Ahn teaches fleet fatigue life calculations. Ahn teaches finding information on a specific vehicle that shares similarities to other vehicles in a fleet. See paragraph 0053 for determining a “manufacturing defect-related failure indicator” which can include “determining a failure history of one or more vehicles that share one or more user-selected variables”, such as “location, vehicle type, vehicle model, vehicle year, and/or cumulative operating hours of a vehicle.” See paragraph 0026 for incorporating Ahn ‘116 (US2016/0093116 A1) by reference. See paragraph 0023 for determining historical failures for reasons of manufacturer recall or defect. This data can come from “production management systems”. See paragraph 0034 for “calculating the life achieved percentage by dividing the lifetime operating house by the expected life published by the manufacturer”
Ahn teaches in paragraph 0039 obtaining details on each “specific vehicle” as shown in Fig. 3, which features a column for the “ ‘Component’” being studied for “ ‘AVG of Wear Indicators’ which “shows the average of all lifetime wear indicators for each component of the selected vehicle calculated by the system”. Wear can be found using a “third set of data comprising a collection of measurements taken in connection with the multiple vehicular components”. This is done using sensors. See paragraph 0017 and Fig. 1 for “sensors 102A, 102B, and 102C resident on each vehicle. The examiner notes that Ahn does not refer specifically to steering system.
So Ahn states that the wear of various components can be measured using data taken from sensors on the vehicle. Ahn does not specifically state that one of these components could be a steering component. Gusikhin teaches determining the wear of various components measured using data taken from sensors of a steering system, among others. It seems to the examiner that the specific example of using sensors that measure steering torque of the steering component in Gusikhin could be obviously combined with the wear calculation system of Ahn.
Due to amendment, the grounds for rejection have changed. Please see the rejection below.
Claim Rejections - 35 USC § 112
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claims 1-20 are rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor, or for pre-AIA the applicant regards as the invention.
Claim 1 now recites in part:
A method for vehicle analytics, the method comprising:
receiving data from at least one condition indicator sensor of a vehicle,
wherein the at least one condition sensor is configured to measure at least one of
The phrase “the at least one condition sensor” lacks antecedent basis. For examination purposes, this part of the claim will be interpreted as follows:
A method for vehicle analytics, the method comprising:
receiving data from at least one condition indicator sensor of a vehicle,
wherein the at least one condition [indicator] sensor is configured to measure at least one of
The other independent claims, claims 10 and 19, are substantially similar in this regard, are rejected for the same reasons, and will be interpreted in the same way.
Claim Rejections - 35 USC § 103
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 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 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.
The text of those sections of Title 35, U.S. Code not included in this action can be found in a prior Office action.
The factual inquiries set forth in Graham v. John Deere Co., 383 U.S. 1, 148 USPQ 459 (1966), that are applied for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
This application currently names joint inventors. In considering patentability of the claims the examiner presumes that the subject matter of the various claims was commonly owned as of the effective filing date of the claimed invention(s) absent any evidence to the contrary. Applicant is advised of the obligation under 37 CFR 1.56 to point out the inventor and effective filing dates of each claim that was not commonly owned as of the effective filing date of the later invention in order for the examiner to consider the applicability of 35 U.S.C. 102(b)(2)(C) for any potential 35 U.S.C. 102(a)(2) prior art against the later invention.
Claims 1, 4-8 and 10, 13-17, and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Rajkumar et al. (US2020/0090419) in view of Malkowicz et al. (US2009/0222427) in further view of Gusikhin et al. (US2021/0241128).
Regarding claim 1, Rajkumar teaches:
A method for vehicle analytics, the method comprising:
receiving data from at least one condition indicator sensor of a vehicle (see Fig. 2, step 202 and paragraph 0049 for extracting data about tire tread depth, for example. See paragraph 0028 for extracting tread depth as well as the hours of usage of an engine, etc, using sensors.);
receiving data from at least one usage indicator sensor of the vehicle (see Figs. 3B, 4C, and paragraph 0028-009 and for determining the number of hours a vehicle has been used, the route traveled by the vehicle, the number of stops, and the load);
updating a vehicle specific model based on a vehicle master model, the data from the at least one condition indicator sensor, and the data from the at least one usage indicator sensor (see Fig. 3B for determining the “current health” using the current miles and the “expected miles”. This implies that the system is updated. See Fig. 4C for determining a probability of survival for “tire RN0985” based on “miles traveled so far” and “predicted travel miles”.),
wherein the vehicle master model
represents a class of vehicle corresponding to a vehicle design associated with the vehicle (see Rajkumar Fig. 1 and paragraph 0021. All the vehicles in Fig. 1A are the same type and all labeled item 102. Paragraph 0021 refers to them as the “one or more transport vehicles 102, e.g., buses.” The paragraph goes on to say that Fig. 1 illustrates “buses” but the disclosed system is applicable for “any type of transport vehicles such as trains, cars, trams, etc.” Many examples in Rajkumar relate to tire useful life predictions, but obviously that would not apply to trains, because the vehicle design associated with trains does not include tires. In a broad reasonable interpretation, the “vehicle master model” of the present clause that “represents a class of vehicle” does not need to be, say, a master model of a Ford F150, for example, but merely a master model of a truck, or even a master model of a four-tired vehicle as compared to a master model of a train (which lacks tires). In this broad reasonable interpretation, Rajkumar teaches the present clause’s limitation. See also Rajkumar paragraph 0049 for a system which can “extract features of components of transport vehicles 102 in the transportation system 100 from the open database 108 and the proprietary database 110. The features can correspond to a single type of component, e.g., tires of the transport vehicles 102 or multiple types of components.” This means that the disclosed system knows what features, such as “tires of the transport vehicle 102” that it wants to extract because it knows that the master model of that type of vehicle has tires. This is a vehicle specific model being generated based on the vehicle master model. The parameters of the master model are being populated with initial parameters of the specific vehicle.) and
is generated based on
at least one end-of-line characteristic associated with the vehicle (in the present published disclosure, paragraph 0057 teaches that “the end-of-line characteristics may include actual manufacturing components used during production of the vehicle…and/or the class of vehicle corresponding to the vehicle 10….or…production measurements, production tolerances, other suitable production information…the class of vehicle”. In relation to the vehicle master model, an end-of-line characteristic could be, for example, steering system friction. But this end-of-line characteristic for the master model is not filled in with a specific value. That is what the vehicle specific model is for. Another example could reasonably be tread depth or even vehicle mileage.), and
wherein the vehicle specific model is generated based on
the vehicle master model and
at least one initial parameter corresponding to at least one end-of-line characteristic of the vehicle (this one initial parameter is reasonably the actual value of the steering wheel friction of the specific vehicle. Another example is the initial thread depth or even the initial mileage of the specific vehicle. As the vehicle rolls off the assembly line it’s vehicle specific model may be populated with some data, such as, it’s steering wheel friction has been tested and is 2.0 Nm, or it’s tread depth is 2 cm, or its mileage is 0.1 miles.),
the at least one initial parameter being one of a plurality of parameters of a parameter set generated based on at least one of nominal design data, as-built data, and in-use data (in the present published disclosure, paragraph 0062 teaches that “the controller 100 may generate or receive a vehicle specific model based on the master vehicle model and the parameter set. The vehicle specific model may include nominal design data (e.g., computer aided design data), as-built data (e.g., digital trace data), and in-use data. The nominal design data may correspond to the one or more design specification characteristics. The as-build [sic] may correspond to the one or more end-of-line characteristics. The in-use data may correspond to the operational data.” Reasonably, the parameter being one of a plurality of parameters means that the vehicle specific model has more than one parameter that could be filled in, such as both steering wheel friction and tread depth, or tread depth and mileage.);
identifying, using the vehicle specific model, at least one usage trend of the vehicle (in the present disclosure, paragraph 0032 recites: “a historic plot of usage indicators that indicate historical usage (e.g., by an owner or operator) of the vehicle”. Paragraph 0034 teaches that the system is configured to “aggregate the usage indicators and condition indicators for the each vehicle” and “compare the aggregated usage indicators and condition indicators to an average (e.g., or typical) value from a median user (e.g., buyer, seller, and the like of the systems…)”. Paragraph 0039 teaches that the system described can “identify, using the vehicle specific model, at least one usage trend of the vehicle,” and generate “an estimate of an RUL [remaining useful life] of at least one aspect of the vehicle based on the at least one usage trend of the vehicle.” In a broad reasonable interpretation, the disclosed system records how much time a user is using the specific vehicle or a vehicle component of the vehicle, and generates a RUL estimate based on that. For example, paragraphs 0021-0027 teaches that a tire can be estimated as needing replacement in 6 months at a cost of $400. This is reasonably related to the usage trend of the particular vehicle. Or, the new brake pads can be estimated to have an RUL of 3 years. As far as the examiner can tell, paragraphs 0042-0043 are about as close as the disclosure comes to tying together the concepts of the initial parameter with the usage trend. The vehicle specific model includes at least one initial parameter, according to paragraph 0042. And “using the vehicle specific model, at least one usage trend of the vehicle” can be identified and an RUL determined. So it seems that, the system may realize that the brake pads are new, and that the driver uses the vehicle 50,000 miles per year, for example. Then an RUL can be determined based on this data. Or, a tire is somewhat worn and given the average miles per year for the specific vehicle, they will need to be replaced in three years, for example.
With that in mind, see Rajkumar Fig. 4C for the “miles travelled so far” and the “predicted travel miles,” both of which are usage trends, and using these to generate a “survival curve for tire RN0985”. ); and
generating aggregated data based on (i) at least one of the data from the at least one condition indicator sensor of the vehicle and the data from the at least one usage indicator sensor of the vehicle, and (ii) at least one of condition indictor data and usage indicator data associated with at least one other vehicle (Rajkumar teaches comparing mileage and tread depth to a “survival curve” for a particular tire. Overall, a reasonable summary of Rajkumar is that it teaches a system that can monitor the wear, mileage, and weather data of a fleet of buses. It can then use this aggregated data to make life predictions about the components of a specific bus in the fleet. These predictions can be predictions about when to replace various components. One example in Rajkumar involves tires. See paragraph 0049 for a “single type of component, e.g., tires” can be extracted from “the transport vehicles 102”. According to paragraph 0053, the system can make a prediction for “a particular tire installed on a [particular] transport vehicle 102…selected for prediction.” Note that the disclosure used the singular “transport vehicle 102” here because it is referring to one specific vehicle in the fleet. The RUL is “learned” and used to make predictions about “tires, which are still in use.” To do this the system aggregates data from other vehicles, as described in paragraph 0067. See also Fig. 5 which discusses extracting the features, or wear and mileage data for the “vehicles” in the fleet in step 502. Then a prediction is made for the “a [specific] transportation vehicle” selected in steps 506 and 508.); and
determining an estimate of a remaining useful life of at least one aspect of the vehicle based on the at least one usage trend of the vehicle and the aggregated data (see paragraph 0053 and Fig. 5 as discussed in the above bullet point.).
Yet Rajkumar does not further teach:
wherein the at least one condition [indicator] sensor is configured to measure at least one of
a torque value associated with a steering system,
a handwheel position of a handwheel of the steering system, and
a motor position of a motor of the steering system.
Nor does Rajkumar further teach:
is generated based on
at least one design specification characteristic of the class of vehicle corresponding to the vehicle design.
However, Malkowicz teaches:
is generated based on
at least one design specification characteristic of the class of vehicle corresponding to the vehicle design (in the present published disclosure, Robinson et al. (US2023/0169802 A1), paragraph 0056 teaches that the controller 100 can receive “one or more design specification characteristics corresponding to a vehicle steering system design and/or other systems of [or?] subsystems of a class of vehicle corresponding to the vehicle 10 and/or may receive input indicating engineering and/or design information corresponding to engineering and/or design specifications of a class of vehicle corresponding to the vehicle 10 and/or other vehicles.” The “design information may include engineering tolerances, component model number or specification, component dimensions (e.g., weight, length, width, depth, and the like, component features (e.g., functions that various components are capable of performing), sensor location…design specification characteristics may include warranty information, sales information, safety feature information, recall information”.
With that in mind, see Malkowicz paragraph 0036, which teaches that in the prior art before Malkowicz, previous vehicle record logs “may have stored the dates that particular parts were initially delivered to particular customers. However, these previous implementations may not have updated the status of these parts after they were initially delivered to the customers.” Therefore, in Malkowicz “In contrast, the server systems 116 and related services 124 and databases 126 may store dynamic lifetime information for these particular life-limited parts, integrating status information provided by a variety of different sources over the lifetime of these life-limited parts.” Malkowicz therefore teaches storing the “dynamic lifetime information” as “provided by” sources such as the manufacturer or vendor on a database that is tracked throughout the components life. This dynamic lifetime information reasonably includes how many cycles a component can take and how many cycles the component has on it. According to Malkowicz, paragraph 0036, this data is now stored from the time the component is “initially delivered” and is tracked “over the lifetime” of the part. Such stored data of the lifetime of a part is a “design specification characteristic” as recited in claim 1. Malkowicz, paragraph 0056 teaches that “records 324 may indicate how many cycles a given part has undergone at particular points in its life.” For example, how many “takeoff and landings (i.e., periodic duty cycles)” the landing gear has on it. Paragraph 0060 also teaches recording the duty cycles of each part. Paragraph 0060 teaches that the overall system of Malkowicz can be used to determine the maximum permitted lifetime for the vehicle or component “whether expressed in terms of time, mileage, duty cycles, or the like.” The paragraph also teaches that various life-limited parts (LLPs) have specific “expected or permitted lifecycle” data. The FAA may state these permitted lifecycles, or other entities may specify them, including vendors or manufacturers, according to paragraph 0019. This permitted lifecycle data is a “design specification characteristic,” in the language of present claim 1. Furthermore, Malkowicz paragraph 0019 teaches that a component’s “time” in service is measured. Overall, Malkowicz teaches a system in which the number of permitted lifecycles a part can handle is stated from the manufacturer, vendor, or FAA. Then the cycles of the part is recorded over time and stored on a database. Then the part can be removed from service before it exceeds its duty cycle rating. In Malkowicz, the system knows what parts go on what aircraft. A Boeing 747 may have a particular front landing gear, for example. The number of permitted lifecycles that part can handle is known. The number of actual lifecycles is tracked. Then the part is serviced before it exceeds its permitted lifecycle. The system tracks each component on each specific aircraft from the time the component was built. Initial data, such as how many duty cycles and hours of use the component has, is recorded.).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the system, as taught by Rajkumar, to add the additional features wherein the vehicle master model is generated based on at least one design specification characteristic of the class of vehicle corresponding to the vehicle design, as taught by Malkowicz. The motivation for doing so would be “evaluate whether given life-limited parts have any permitted life remaining,” as recognized by Malkowicz (see paragraph 0006.).
This conclusion of obviousness corresponds to KSR rationale “A”: it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have combined prior art elements according to known methods to yield predictable results. See MPEP § 2141, subsection III.
In summary, Rajkumar teaches a system shown in Fig. 1A in which a fleet of vehicles report to a central server. Malkowicz teaches a similar system. Rajkumar teaches in paragraph 0022 a system in which a database 110 can provide information on individual “components installed on the transport vehicle”. Rajkumar does not explicitly state that this information comes from the manufacturer, though it very well could. Malkowicz cures this deficiency by teaching that for a given vehicle the expected lifecycle data is provided by the manufacturer, vendor, or FAA, and is tracked over the life of the part.
However, Rajkumar and Malkowicz do not further teach:
wherein the at least one condition [indicator] sensor is configured to measure at least one of
a torque value associated with a steering system,
a handwheel position of a handwheel of the steering system, and
a motor position of a motor of the steering system.
However, Gusikhin teaches:
wherein the at least one condition [indicator] sensor is configured to measure at least one of (see paragraph 0005 for tracking the wear on a vehicle component so that a “predicted time to failure” can be estimated and a repair can be made. To do this, the system uses a “damage model” of the component that uses “vehicle operating data.” See paragraph 0033 for the vehicle operating data coming at least in part from sensors 110, as shown in Fig. 1. See paragraph 0036 for the sensors 110 collecting “operational parameters,” including “steering torque”.)
a torque value associated with a steering system (see paragraph 0036 for the sensors 110 collecting “operational parameters,” including “steering torque”. See paragraph 0037 for the steering subsystem 120” including components 125 which may include a steering wheel, steering rack, a steering gear, “etc.”),
a handwheel position of a handwheel of the steering system, and
a motor position of a motor of the steering system.
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the system, as taught by Rajkumar and Malkowicz, to add the additional features wherein the at least one condition [indicator] sensor is configured to measure at least one of a torque value associated with a steering system, as taught by Gusikhin. The motivation for doing so would be to track the wear on a vehicle component so that a “predicted time to failure” can be estimated and a repair can be made, as recognized by Gusikhin (see paragraph 0005).
This conclusion of obviousness corresponds to KSR rationale “A”: it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have combined prior art elements according to known methods to yield predictable results. See MPEP § 2141, subsection III.
The examiner thinks that the limitations taught by Malkowicz in this rejection might be also taught by Gusikhin, since Gusikhin teaches in paragraph 0040 that a “threshold can be determined for each subsystem 120 according to each specific damage model, and can be based on, e.g., manufacturer recommendations, empirical testing of components 125 of the subsystem 120 in test vehicles 101, comparison of performance metrics of damaged components 125 with require performance metrics to operate the vehicle 101, etc.” Thus, Gusikhin also teaches that “manufacturer recommendations” can be a source of life data of a components. Other damage models, such as textbook models, are cited in the paragraph. These could be “one design specification characteristic of the class of vehicle corresponding to the vehicle design.” While the examiner might have gone to a two-reference rejection the examiner used the current rejection for consistency and because Malkowicz teaches this limitation more explicitly, thus the three-reference rejection is stronger.
Regarding claim 4, Rajkumar, Malkowicz, and Gusikhin teach the method of claim 1.
Rajkumar further teaches:
The method of claim 1, wherein
the data corresponding to the at least one usage indicator sensor indicates a usage of a component of the vehicle associated with the at least one usage indicator sensor (see paragraph 0028 for extracting “tread depth of tires, number of hours of usage of an engine, etc.” using sensors. See Fig. 3B for predicting a “probability of survival” as “240 days more” based on the “current health” which is based on current mileage and the “expected end at 30,000 miles.” This means that a usage trend involving miles and correlated to days has been calculated and estimates the “expected end” of the tire. Furthermore, the health on the specific route ID 13 is calculated. See Fig. 4C for the “miles traveled so far” and the “predicted travel miles”. See paragraph 0050 for determining an existing “tread depth of the tire which would have a direct correlation with the RUL”. See also paragraphs 0018 and 0024 for using the operating conditions of a vehicle component, such as a tire, to predict its RUL.).
Regarding claim 5, Rajkumar, Malkowicz, and Gusikhin teach the method of claim 1.
Yet Rajkumar does not further teach:
A method further comprising
receiving data from a health management system associated with a vehicle manufacturer logistics system.
However, Malkowicz teaches:
A method further comprising
receiving data from a health management system associated with a vehicle manufacturer logistics system (what does this claim mean in a broad reasonable interpretation? First, note that the claim say “a value manufacturer” not “the vehicle manufacturer.” Thus the manufacture mentioned in claim 5 is not the manufacturer of the vehicle of claim 1, at least it does not have to be. The disclosure uses the terms “vehicle manufacturer logistics system” in this claim and elsewhere and the term “dealership logistics system” in at least paragraph 0035. The examiner thinks the disclosure justifies interpreting these terms roughly interchangeably because they are taught as similar. Furthermore, a manufacturer, such as Ford for example, is often also the dealer, so the two are often the same. Paragraph 0035 teaches that the hidden-value reducing failure of one or more components of the vehicle can be “linked to a dealership logistics system. The system and methods described herein may be configured to determine vehicle and component costs using the dealer logistics system.” In a broad reasonable interpretation based on paragraph 0035 and others, it seems that a “hidden value-reducing failure” that is converted into a monetary value that is linked to a dealership logistics system that can determine vehicle or component costs could be a system in which the brake pads of a vehicle, for example, that have been worn down through a lot of use, but which has been detected by sensors, could be a “hidden” issue because the brake pad thickness is hidden from a simple visual inspection. These worn brake pads reduce the value of the vehicle. Therefore, the vehicle has a “hidden value-reducing failure”. This could be linked to a dealer system that calculates the cost of the parts and labor, or the cost of the vehicle given its particular used state.
In the present disclosure, paragraph 0070 teaches a controller that can receive data from “a health management system associated with a vehicle manufacturer logistics system”. This phrase is very similar to the present claim. The paragraph teaches that the controller may identify, “using the vehicle specific model and/or the data from the health management system, at least one hidden value-reducing failure of the vehicle 10.” (Hyphen added here and throughout the discussion of this claim.) Paragraph 0074 teaches determining “a monetary value of the vehicle based on the at least one hidden value-reducing failure of the vehicle and the estimate of the remaining useful life of the at least one aspect of the vehicle.” Paragraph 0020 teaches that the system could “provide a vehicle quality report” and that the system “may be configured to automatically calculate a value of a pre-owned vehicle based on health indicators and RUL metrics by vehicle component.” The report could be output to a “perspective buyer” by a computer system “associated with a seller of the vehicle” or associated with “a vehicle dealership, or other suitable computing device or display.” Paragraphs 0021-0027 expound on this and teach that the system can output that the tires currently have 3 mm of tread and will need “replacement in 6 months” at a cost of $400 and that the brake pads are new, and their RUL is 3 years. Finally, see paragraph 0056 for the controller obtaining “engineering and/or design information corresponding to engineering and/or design specifications” and “component model number or specification, component dimensions,” “warranty information, “safety feature information,” and other information.
Therefore, in a broad reasonable interpretation, [the claim means] in a sense, just what it says.
With all that in mind, see Malkowicz for a system the focuses on a server 116, as shown in Fig. 2. The server can obtain data from a vehicle manufacturer 108. See paragraph 0016 for a vehicle manufacturer that makes vehicles from parts provided by different vendors and then sells the vehicles to customers 110. The customers 110 may then have their vehicle repaired or maintained using third-party providers, according to paragraph 0017. The server 116 tracks the repairs the history of the individual parts or components, and provides data on the component life on each particular vehicle. For all that in the disclosure, see paragraph 0027 for Fig. 1 showing “at 128 a examples of uploads, queries, and/or responses between the vendors 104 and the server systems 116. Similarly, FIG. 1 represents at 128 b uploads, queries, and/or responses between the manufacturer 108 and the server systems 116, denotes at 128 c uploads, queries, and/or responses between the customers 110 and the server systems 116, and denotes at 128 m uploads, queries, and/or responses between the repair providers 112 and the server systems 116.” This means that the “manufacturer” can send information that relates to the life of a vehicle or vehicle part, which satisfies the limitations of this claim. See paragraph 0031 for “in some implementations, the vehicle manufacturer 108 may operate and maintain the common data warehouse. For example, the common data warehouse may list life-limited parts included within a given vehicle, organized as appropriate in different given applications.” See paragraph 0019 for a server systems 116 that provide an online system of life-limited parts included within the vehicles 102. See paragraph 0037 for “the manufacturer may provide delivery records (e.g., 220) relating to the vehicle to the customer, with these delivery records listing specific equipment installed on vehicle, along with identifying any life limited parts.” See paragraph 0040 for: “As shown in the example of FIG. 2, the server systems 116 may exchange assembly configuration data 232 with, for example, repair providers 112, customers 110, vehicle manufacturers 108, or other entities not shown in FIG. 2. In general, the assembly configuration data 232 may represent any actions taken relative to life-limited parts over the lifetime of the parts.” See paragraph 0046 for: “The server systems 116 may also exchange assembly configuration data 232 with one or more leasing or finance organizations 234…These leasing or finance organizations (or other entities described herein) may investigate the pedigree or heritage of any collateral in which they have an interest by interacting with the server systems 116….
In addition, the organizations 234 may be involved in outright sales, in which vehicles (e.g., airplanes, airplane parts, or the like) are transferred between owners (e.g., airlines 110).” Finance and leasing organizations would want to know about the maintenance history and hidden value-reducing failures of components on a vehicle. See paragraph 0014 for the system not being limited to an aviation context but can include “any type of vehicle” including “lane-based” ones.).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the system, as taught by Rajkumar, Malkowicz, and Gusikhin to add the additional features of receiving data from a health management system associated with a vehicle manufacturer logistics system, as taught by Malkowicz. The motivation for doing so would be “evaluate whether given life-limited parts have any permitted life remaining,” as recognized by Malkowicz (see paragraph 0006.).
This conclusion of obviousness corresponds to KSR rationale “A”: it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have combined prior art elements according to known methods to yield predictable results. See MPEP § 2141, subsection III.
In summary, Rajkumar teaches a system shown in Fig. 1A in which a fleet of vehicles report to a central server. Malkowicz teaches a similar system. Rajkumar teaches in paragraph 0022 a system in which a database 110 can provide information on individual “components installed on the transport vehicle”. Rajkumar does not explicitly state that this information comes from the manufacturer, though it very well could. Malkowicz cures this deficiency.
Regarding claim 6, Rajkumar, Malkowicz, and Gusikhin teach the method of claim 5.
Yet Rajkumar does not further teach:
A method further comprising
determining the estimate of the remaining useful life of the at least one aspect of the vehicle further based on the data from the health management system.
However, Malkowicz
A method further comprising
determining the estimate of the remaining useful life of the at least one aspect of the vehicle further based on the data from the health management system (see paragraph 0031 for “in some implementations, the vehicle manufacturer 108 may operate and maintain the common data warehouse. For example, the common data warehouse may list life-limited parts included within a given vehicle, organized as appropriate in different given applications.” See paragraph 0019 for a server systems 116 that provide an online system of life-limited parts included within the vehicles 102. See paragraph 0037 for “the manufacturer may provide delivery records (e.g., 220) relating to the vehicle to the customer, with these delivery records listing specific equipment installed on vehicle, along with identifying any life limited parts.” See paragraph 0037 for “the manufacturer may provide delivery records (e.g., 220) relating to the vehicle to the customer, with these delivery records listing specific equipment installed on vehicle, along with identifying any life limited parts.” See paragraph 0040 for: “As shown in the example of FIG. 2, the server systems 116 may exchange assembly configuration data 232 with, for example, repair providers 112, customers 110, vehicle manufacturers 108, or other entities not shown in FIG. 2. In general, the assembly configuration data 232 may represent any actions taken relative to life-limited parts over the lifetime of the parts.”).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the system, as taught by Rajkumar, Malkowicz, and Gusikhin, to add the additional features of determining the estimate of the remaining useful life of the at least one aspect of the vehicle further based on the data from the health management system, as taught by Malkowicz. The motivation for doing so would be “evaluate whether given life-limited parts have any permitted life remaining,” as recognized by Malkowicz (see paragraph 0006.).
This conclusion of obviousness corresponds to KSR rationale “A”: it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have combined prior art elements according to known methods to yield predictable results. See MPEP § 2141, subsection III.
Regarding claim 7, Rajkumar, Malkowicz, and Gusikhin teach the method of claim 1.
Rajkumar further teaches:
The method of claim 1, further comprising
determining the estimate of the remaining useful life of the vehicle further based on at least one physics-based metric (in the present disclosure, paragraph 0034 recites determining an RUL based on physics-based metrics (e.g., condition indicators, usage indicators, health indicators, and/or other suitable indicators or information).” In this description, the term “physics” is related to “usage” for example, meaning the dynamic movement of a part or component. With that in mind, see Rajkumar Fig. 4C for the “miles travelled so far” and the “predicted travel miles,” both of which are usage trends, and using these to generate a “survival curve for tire RN0985”.).
Regarding claim 8, Rajkumar discloses the method of claim 1.
Rajkumar further discloses:
The method of claim 1, further comprising
identifying, using the vehicle specific model, at least one hidden value-reducing failure of the vehicle (in the present disclosure, see paragraph 0035 which teaches that the hidden-value reducing failure of one or more components of the vehicle can be “linked to a dealership logistics system. The system and methods described herein may be configured to determine vehicle and component costs using the dealer logistics system.” In a broad reasonable interpretation based on paragraph 0035 and others, it seems that a “hidden value-reducing failure” that is converted into a monetary value that is linked to a dealership logistics system that can determine vehicle or component costs could be a system in which the brake pads of a vehicle, for example, that have been worn down through a lot of use, but which has been detected by sensors, could be a “hidden” issue because the brake pad thickness is hidden from a simple visual inspection. These worn brake pads reduce the value of the vehicle. Therefore, the vehicle has a “hidden value-reducing failure”. This could be linked to a dealer system that calculates the cost of the parts and labor, or the cost of the vehicle given its particular used state.
With that in mind, see Rajkumar, Figs. 3B and 4C and paragraph 0028-009 and for determining the number of hours a vehicle has been used, the route traveled by the vehicle, the number of stops, and the load. See Fig. 3B for determining the “current health” using the current miles and the “expected miles”. This implies that the system is updated. See Fig. 4C for determining a probability of survival for “tire RN0985” based on “miles traveled so far” and “predicted travel miles”. See paragraph 0028 for determining the “number of hours of usage of an engine, etc.” Although tread depth might not be “hidden”, the number of hours and load on an engine is hidden. See also paragraph 0034 teaches that the system is configured to “aggregate the usage indicators and condition indicators for the each vehicle” and “compare the aggregated usage indicators and condition indicators to an average (e.g., or typical) value from a median user (e.g., buyer, seller, and the like of the systems…)”. Paragraph 0039 teaches that the system described can “identify, using the vehicle specific model, at least one usage trend of the vehicle,” and generate “an estimate of an RUL [remaining useful life] of at least one aspect of the vehicle based on the at least one usage trend of the vehicle.”).
Regarding claim 10, Rajkumar teaches:
A system for vehicle analytics, the system comprising (see Fig. 1A and 1B):
a processor (see paragraph 0047); and
a memory including instructions that, when executed by the processor, cause the processor to (see paragraph 0047):
receive data from at least one condition indicator sensor of a vehicle (the remainder of this claim is substantially similar to claim 1. Please see the analogous bullets in claim 1 for the rest of the rejection of this claim.);
wherein the at least one condition [indicator] sensor is configured to measure at least one of
a torque value associated with a steering system,
a handwheel position of a handwheel of the steering system, and
a motor position of a motor of the steering system;
receive data from at least one usage indicator sensor of the vehicle;
update a vehicle specific model based on a vehicle master model, the data from the at least one condition indicator sensor, and the data from the at least one usage indicator sensor,
wherein the vehicle master model
represents a class of vehicle corresponding to a vehicle design associated with the vehicle and
is generated based on
at least one design specification characteristic of the class of vehicle corresponding to the vehicle design and
at least one end-of-line characteristic associated with the vehicle, and
wherein the vehicle specific model is generated based on
the vehicle master model and
at least one initial parameter corresponding to at least one end-of-line characteristic of the vehicle,
the at least one initial parameter being one of a plurality of parameters of a parameter set generated based on at least one of nominal design data, as-built data, and in-use data;
identify, using the vehicle specific model, at least one usage trend of the vehicle;
generate aggregated data based on (i) at least one of the data from the at least one condition indicator sensor of the vehicle and the data from the at least one usage indicated indicator sensor of the vehicle, and (ii) at least one of condition indictor data and usage indicator data associated with at least one other vehicle; and
determine an estimate of a remaining useful life of at least one aspect of the vehicle based on the at least one usage trend of the vehicle and the aggregated data.
Regarding claims 13-17, those claims are substantially similar to claims 4-8, respectively. Please see the rejections of those claims.
Regarding claim 19, Rajkumar teaches:
An apparatus for vehicle analytics, the apparatus comprising:
a processor (see paragraph 0047. For additional discussion of claim 19, see the “Response to Arguments” section of the Final Rejection May 28, 2025); and
a memory including instructions that, when executed by the processor, cause the processor to (see paragraph 0047):
receive data from at least one condition indicator sensor (see Fig. 2, step 202 and paragraph 0049 for extracting data about tire tread depth, for example. See paragraph 0028 for extracting tread depth as well as the hours of usage of an engine, etc, using sensors.),
receive data from at least one usage indicator sensor of the vehicle (see Figs. 3B, 4C, and paragraph 0028-009 and for determining the number of hours a vehicle has been used, the route traveled by the vehicle, the number of stops, and the load);
update a vehicle specific model based on a vehicle master model, the data from the at least one condition indicator sensor, and the data from the at least one usage indicator sensor (see Fig. 3B for determining the “current health” using the current miles and the “expected miles”. This implies that the system is updated. See Fig. 4C for determining a probability of survival for “tire RN0985” based on “miles traveled so far” and “predicted travel miles”.),
wherein the vehicle master model
represents a class of vehicle corresponding to a vehicle design associated with the vehicle (see Rajkumar Fig. 1 and paragraph 0021. All the vehicles in Fig. 1A are the same type and all labeled item 102. Paragraph 0021 refers to them as the “one or more transport vehicles 102, e.g., buses.” The paragraph goes on to say that Fig. 1 illustrates “buses” but the disclosed system is applicable for “any type of transport vehicles such as trains, cars, trams, etc.” Many examples in Rajkumar relate to tire useful life predictions, but obviously that would not apply to trains, because the vehicle design associated with trains does not include tires. In a broad reasonable interpretation, the “vehicle master model” of the present clause that “represents a class of vehicle” does not need to be, say, a master model of a Ford F150, for example, but merely a master model of a truck, or even a master model of a four-tired vehicle as compared to a master model of a train (which lacks tires). In this broad reasonable interpretation, Rajkumar teaches the present clause’s limitation. See also Rajkumar paragraph 0049 for a system which can “extract features of components of transport vehicles 102 in the transportation system 100 from the open database 108 and the proprietary database 110. The features can correspond to a single type of component, e.g., tires of the transport vehicles 102 or multiple types of components.” This means that the disclosed system knows what features, such as “tires of the transport vehicle 102” that it wants to extract because it knows that the master model of that type of vehicle has tires. This is a vehicle specific model being generated based on the vehicle master model. The parameters of the master model are being populated with initial parameters of the specific vehicle.) and
is generated based on
at least one end-of-line characteristic associated with the vehicle (in the present published disclosure, Robinson et al. (US2023/0169802 A1), paragraph 0059 teaches that “the master vehicle model may include a digital representation of the vehicle steering design”. The controller may “generate or receive at least one initial parameter or parameter set (e.g., a signature using the one or more end-of-line characteristics of the vehicle…For example, the controller 100 may generate or receive a parameter set corresponding to the vehicle steering system of the vehicle 10. The parameter set may include a value, such as a numeric string or other suitable value.” Other parameter sets may correspond to other components or systems or sub-systems, steering is just one example. Paragraph 0060 teaches that, “For example, the operational data may include sensor data indicating handwheel friction of a handwheel of the vehicle steering system, wheel angle corresponding to an applied handwheel torque” etc. Paragraph 0061 teaches that the controller can receive “one subsequent parameter based on the operational data.” These paragraphs teach that an “initial parameter” can be interpreted as an “end-of-line characteristic” and can be, for example, a measured steering wheel friction. So a master vehicle model may include general “digital representation” of various vehicle parameters, such as steering wheel friction. Yet a specific vehicle can then populate the master model with initial data from the specific vehicle’s sensors, such as a reading from the vehicle’s steering wheel torque sensor or the initial tire tread depth. The initial value provided is an “end-of-line characteristic” because it is the friction of the steering wheel or the tread depth at the time when that specific vehicle rolled off the end of the assembly line.
With that in mind, see Rajkumar, Fig. 2, step 212 for determining if the component is a “new component”. See Fig. 3A for looking at the “current health” of the vehicle over the “total miles traveled”. The initial mile provided the initial heath data for that specific vehicle. See Fig. 3B for predicting a “probability of survival” as “240 days more” based on the “current health” which is based on current mileage and the “expected end at 30,000 miles.” See paragraph 0050 for determining an existing “tread depth of the tire which would have a direct correlation with the RUL”. So the system gathers data, including when the component is new. The first tire tread depth reading after that is the initial parameter. Based on Fig. 2, the system will take at least one reading from sensors and then output an RUL in step 214.), and
wherein the vehicle specific model is generated based on
the vehicle master model and
at least one initial parameter corresponding to at least one end-of-line characteristic of the vehicle,
the at least one initial parameter being one of a plurality of parameters of a parameter set generated based on at least one of nominal design data, as-built data, and in-use data (for all these bullets note that in the present published disclosure, Robinson et al. (US2023/0169802 A1), paragraph 0059 teaches that “the master vehicle model may include a digital representation of the vehicle steering design”. The controller may “generate or receive at least one initial parameter or parameter set (e.g., a signature using the one or more end-of-line characteristics of the vehicle…For example, the controller 100 may generate or receive a parameter set corresponding to the vehicle steering system of the vehicle 10. The parameter set may include a value, such as a numeric string or other suitable value.” Other parameter sets may correspond to other components or systems or sub-systems, steering is just one example. Paragraph 0060 teaches that, “For example, the operational data may include sensor data indicating handwheel friction of a handwheel of the vehicle steering system, wheel angle corresponding to an applied handwheel torque” etc. Paragraph 0061 teaches that the controller can receive “one subsequent parameter based on the operational data.” These paragraphs teach that an “initial parameter” can be interpreted as an “end-of-line characteristic” and can be, for example, a measured steering wheel friction. So a master vehicle model may include general “digital representation” of various vehicle parameters, such as steering wheel friction. Yet a specific vehicle can then populate the master model with initial data from the specific vehicle’s sensors, such as a reading from the vehicle’s steering wheel torque sensor or the initial tire tread depth. The initial value provided is an “end-of-line characteristic” because it is the friction of the steering wheel or the tread depth at the time when that specific vehicle rolled off the end of the assembly line.
With that in mind, see Rajkumar, Fig. 2, step 212 for determining if the component is a “new component”. See Fig. 3A for looking at the “current health” of the vehicle over the “total miles traveled”. The initial mile provided the initial heath data for that specific vehicle. See Fig. 3B for predicting a “probability of survival” as “240 days more” based on the “current health” which is based on current mileage and the “expected end at 30,000 miles.” See paragraph 0050 for determining an existing “tread depth of the tire which would have a direct correlation with the RUL”. So the system gathers data, including when the component is new. The first tire tread depth reading after that is the initial parameter. Based on Fig. 2, the system will take at least one reading from sensors and then output an RUL in step 214.);
identify, using the vehicle specific model, at least one usage trend of the vehicle (in the present disclosure, paragraph 0032 recites: “a historic plot of usage indicators that indicate historical usage (e.g., by an owner or operator) of the vehicle”. Paragraph 0034 teaches that the system is configured to “aggregate the usage indicators and condition indicators for the each vehicle” and “compare the aggregated usage indicators and condition indicators to an average (e.g., or typical) value from a median user (e.g., buyer, seller, and the like of the systems…)”. Paragraph 0039 teaches that the system described can “identify, using the vehicle specific model, at least one usage trend of the vehicle,” and generate “an estimate of an RUL [remaining useful life] of at least one aspect of the vehicle based on the at least one usage trend of the vehicle.” In a broad reasonable interpretation, the disclosed system records how much time a user is using the specific vehicle or a vehicle component of the vehicle, and generates a RUL estimate based on that. For example, paragraphs 0021-0027 teaches that a tire can be estimated as needing replacement in 6 months at a cost of $400. This is reasonably related to the usage trend of the particular vehicle. Or, the new brake pads can be estimated to have an RUL of 3 years. As far as the examiner can tell, paragraphs 0042-0043 are about as close as the disclosure comes to tying together the concepts of the initial parameter with the usage trend. The vehicle specific model includes at least one initial parameter, according to paragraph 0042. And “using the vehicle specific model, at least one usage trend of the vehicle” can be identified and an RUL determined. So it seems that, the system may realize that the brake pads are new, and that the driver uses the vehicle 50,000 miles per year, for example. Then an RUL can be determined based on this data. Or, a tire is somewhat worn and given the average miles per year for the specific vehicle, they will need to be replaced in three years, for example.
With that in mind, see Rajkumar Fig. 4C for the “miles travelled so far” and the “predicted travel miles,” both of which are usage trends, and using these to generate a “survival curve for tire RN0985”.);
generate aggregated Rajkumar teaches comparing mileage and tread depth to a “survival curve” for a particular tire. Overall, a reasonable summary of Rajkumar is that it teaches a system that can monitor the wear, mileage, and weather data of a fleet of buses. It can then use this aggregated data to make life predictions about the components of a specific bus in the fleet. These predictions can be predictions about when to replace various components. One example in Rajkumar involves tires. See paragraph 0049 for a “single type of component, e.g., tires” can be extracted from “the transport vehicles 102”. According to paragraph 0053, the system can make a prediction for “a particular tire installed on a [particular] transport vehicle 102…selected for prediction.” Note that the disclosure used the singular “transport vehicle 102” here because it is referring to one specific vehicle in the fleet. The RUL is “learned” and used to make predictions about “tires, which are still in use.” To do this the system aggregates data from other vehicles, as described in paragraph 0067. See also Fig. 5 which discusses extracting the features, or wear and mileage data for the “vehicles” in the fleet in step 502. Then a prediction is made for the “a [specific] transportation vehicle” selected in steps 506 and 508.); and
determine an estimate of a remaining useful life of at least one aspect of the vehicle based on the at least one usage trend of the vehicle, the data from the health management system, and the aggregated data (Rajkumar teaches comparing mileage and tread depth to a “survival curve” for a particular tire. Overall, a reasonable summary of Rajkumar is that it teaches a system that can monitor the wear, mileage, and weather data of a fleet of buses. It can then use this aggregated data to make life predictions about the components of a specific bus in the fleet. These predictions can be predictions about when to replace various components. One example in Rajkumar involves tires. See paragraph 0049 for a “single type of component, e.g., tires” can be extracted from “the transport vehicles 102”. According to paragraph 0053, the system can make a prediction for “a particular tire installed on a [particular] transport vehicle 102…selected for prediction.” Note that the disclosure used the singular “transport vehicle 102” here because it is referring to one specific vehicle in the fleet. The RUL is “learned” and used to make predictions about “tires, which are still in use.” To do this the system aggregates data from other vehicles, as described in paragraph 0067. See also Fig. 5 which discusses extracting the features, or wear and mileage data for the “vehicles” in the fleet in step 502. Then a prediction is made for the “a [specific] transportation vehicle” selected in steps 506 and 508.).
Yet Rajkumar does not further teach:
receive data from a health management system associated with a vehicle manufacturer logistics system;
is generated based on
at least one design specification characteristic of the class of vehicle corresponding to the vehicle design.
However, Malkcowicz teaches:
receive data from a health management system associated with a vehicle manufacturer logistics system (see the discussion above in the “Response to Arguments” section of this detailed action. See also Malkowicz for a system the focuses on a server 116, as shown in Fig. 2. The server can obtain data from a vehicle manufacturer 108. See paragraph 0016 for a vehicle manufacturer that makes vehicles from parts provided by different vendors and then sells the vehicles to customers 110. The customers 110 may then have their vehicle repaired or maintained using third-party providers, according to paragraph 0017. The server 116 tracks the repairs and the history of the individual parts or components, and provides data on the component life on each particular vehicle. For all that in the disclosure, see paragraph 0027 for Fig. 1 showing “at 128 a examples of uploads, queries, and/or responses between the vendors 104 and the server systems 116. Similarly, FIG. 1 represents at 128 b uploads, queries, and/or responses between the manufacturer 108 and the server systems 116, denotes at 128 c uploads, queries, and/or responses between the customers 110 and the server systems 116, and denotes at 128 m uploads, queries, and/or responses between the repair providers 112 and the server systems 116.” This means that the “manufacturer” can send information that relates to the life of a vehicle or vehicle part, which satisfies the limitations of this claim. See paragraph 0031 for “in some implementations, the vehicle manufacturer 108 may operate and maintain the common data warehouse. For example, the common data warehouse may list life-limited parts included within a given vehicle, organized as appropriate in different given applications.” See paragraph 0019 for a server systems 116 that provide an online system of life-limited parts included within the vehicles 102. See paragraph 0037 for “the manufacturer may provide delivery records (e.g., 220) relating to the vehicle to the customer, with these delivery records listing specific equipment installed on vehicle, along with identifying any life limited parts.” See paragraph 0040 for: “As shown in the example of FIG. 2, the server systems 116 may exchange assembly configuration data 232 with, for example, repair providers 112, customers 110, vehicle manufacturers 108, or other entities not shown in FIG. 2. In general, the assembly configuration data 232 may represent any actions taken relative to life-limited parts over the lifetime of the parts.” See paragraph 0046 for: “The server systems 116 may also exchange assembly configuration data 232 with one or more leasing or finance organizations 234…These leasing or finance organizations (or other entities described herein) may investigate the pedigree or heritage of any collateral in which they have an interest by interacting with the server systems 116….In addition, the organizations 234 may be involved in outright sales, in which vehicles (e.g., airplanes, airplane parts, or the like) are transferred between owners (e.g., airlines 110).” Finance and leasing organizations would want to know about the maintenance history and hidden value-reducing failures of components on a vehicle. See paragraph 0014 for the system not being limited to an aviation context but can include “any type of vehicle” including “lane-based” ones.);
is generated based on
at least one design specification characteristic of the class of vehicle corresponding to the vehicle design (in the present published disclosure, Robinson et al. (US2023/0169802 A1), paragraph 0056 teaches that the controller 100 can receive “one or more design specification characteristics corresponding to a vehicle steering system design and/or other systems of [or?] subsystems of a class of vehicle corresponding to the vehicle 10 and/or may receive input indicating engineering and/or design information corresponding to engineering and/or design specifications of a class of vehicle corresponding to the vehicle 10 and/or other vehicles.” The “design information may include engineering tolerances, component model number or specification, component dimensions (e.g., weight, length, width, depth, and the like, component features (e.g., functions that various components are capable of performing), sensor location…design specification characteristics may include warranty information, sales information, safety feature information, recall information”.
With that in mind, see Malkowicz paragraph 0036, which teaches that in the prior art before Malkowicz, previous vehicle record logs “may have stored the dates that particular parts were initially delivered to particular customers. However, these previous implementations may not have updated the status of these parts after they were initially delivered to the customers.” Therefore, in Malkowicz “In contrast, the server systems 116 and related services 124 and databases 126 may store dynamic lifetime information for these particular life-limited parts, integrating status information provided by a variety of different sources over the lifetime of these life-limited parts.” Malkowicz therefore teaches storing the “dynamic lifetime information” as “provided by” sources such as the manufacturer or vendor on a database that is tracked throughout the components life. This dynamic lifetime information reasonably includes how many cycles a component can take and how many cycles the component has on it. According to Malkowicz, paragraph 0036, this data is now stored from the time the component is “initially delivered” and is tracked “over the lifetime” of the part. Such stored data of the lifetime of a part is a “design specification characteristic” as recited in claim 1. Malkowicz, paragraph 0056 teaches that “records 324 may indicate how many cycles a given part has undergone at particular points in its life.” For example, how many “takeoff and landings (i.e., periodic duty cycles)” the landing gear has on it. Paragraph 0060 also teaches recording the duty cycles of each part. Paragraph 0060 teaches that the overall system of Malkowicz can be used to determine the maximum permitted lifetime for the vehicle or component “whether expressed in terms of time, mileage, duty cycles, or the like.” The paragraph also teaches that various life-limited parts (LLPs) have specific “expected or permitted lifecycle” data. The FAA may state these permitted lifecycles, or other entities may specify them, including vendors or manufacturers, according to paragraph 0019. This permitted lifecycle data is a “design specification characteristic,” in the language of present claim 1. Furthermore, Malkowicz paragraph 0019 teaches that a component’s “time” in service is measured. Overall, Malkowicz teaches a system in which the number of permitted lifecycles a part can handle is stated from the manufacturer, vendor, or FAA. Then the cycles of the part is recorded over time and stored on a database. Then the part can be removed from service before it exceeds its duty cycle rating. In Malkowicz, the system knows what parts go on what aircraft. A Boeing 747 may have a particular front landing gear, for example. The number of permitted lifecycles that part can handle is known. The number of actual lifecycles is tracked. Then the part is serviced before it exceeds its permitted lifecycle. The system tracks each component on each specific aircraft from the time the component was built. Initial data, such as how many duty cycles and hours of use the component has, is recorded.).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the system, as taught by Rajkumar, to add the additional features of: receive data from a health management system associated with a vehicle manufacturer logistics system, and wherein the vehicle master model is generated based on at least one design specification characteristic of the class of vehicle corresponding to the vehicle design, as taught by Malkowicz. The motivation for doing so would be “evaluate whether given life-limited parts have any permitted life remaining,” as recognized by Malkowicz (see paragraph 0006.).
This conclusion of obviousness corresponds to KSR rationale “A”: it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have combined prior art elements according to known methods to yield predictable results. See MPEP § 2141, subsection III.
In summary, Rajkumar teaches a system shown in Fig. 1A in which a fleet of vehicles report to a central server. Malkowicz teaches a similar system. Rajkumar teaches in paragraph 0022 a system in which a database 110 can provide information on individual “components installed on the transport vehicle”. Rajkumar does not explicitly state that this information comes from the manufacturer, though it very well could. Malkowicz cures this deficiency by teaching that for a given vehicle the expected lifecycle data is provided by the manufacturer, vendor, or FAA, and is tracked over the life of the part.
However, Rajkumar and Malkowicz do not further teach:
wherein the at least one condition [indicator] sensor is configured to measure at least one of
a torque value associated with a steering system,
a handwheel position of a handwheel of the steering system, and
a motor position of a motor of the steering system.
However, Gusikhin teaches:
wherein the at least one condition [indicator] sensor is configured to measure at least one of (see paragraph 0005 for tracking the wear on a vehicle component so that a “predicted time to failure” can be estimated and a repair can be made. To do this, the system uses a “damage model” of the component that uses “vehicle operating data.” See paragraph 0033 for the vehicle operating data coming at least in part from sensors 110, as shown in Fig. 1. See paragraph 0036 for the sensors 110 collecting “operational parameters,” including “steering torque”.)
a torque value associated with a steering system (see paragraph 0036 for the sensors 110 collecting “operational parameters,” including “steering torque”. See paragraph 0037 for the steering subsystem 120” including components 125 which may include a steering wheel, steering rack, a steering gear, “etc.”),
a handwheel position of a handwheel of the steering system, and
a motor position of a motor of the steering system.
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the system, as taught by Rajkumar and Malkowicz, to add the additional features wherein the at least one condition [indicator] sensor is configured to measure at least one of a torque value associated with a steering system, as taught by Gusikhin. The motivation for doing so would be to track the wear on a vehicle component so that a “predicted time to failure” can be estimated and a repair can be made, as recognized by Gusikhin (see paragraph 0005).
This conclusion of obviousness corresponds to KSR rationale “A”: it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have combined prior art elements according to known methods to yield predictable results. See MPEP § 2141, subsection III.
The examiner thinks that the limitations taught by Malkowicz in this rejection might be also taught by Gusikhin, since Gusikhin teaches in paragraph 0040 that a “threshold can be determined for each subsystem 120 according to each specific damage model, and can be based on, e.g., manufacturer recommendations, empirical testing of components 125 of the subsystem 120 in test vehicles 101, comparison of performance metrics of damaged components 125 with require performance metrics to operate the vehicle 101, etc.” Thus, Gusikhin also teaches that “manufacturer recommendations” can be a source of life data of a components. Other damage models, such as textbook models, are cited in the paragraph. These could be “one design specification characteristic of the class of vehicle corresponding to the vehicle design.” While the examiner might have gone to a two-reference rejection the examiner used the current rejection for consistency and because Malkowicz teaches this limitation more explicitly, thus the three-reference rejection is stronger.
Regarding claim 20, Rajkumar, Malkowicz, and Gusikhin teach the apparatus of claim 19.
Rajkumar further teaches:
An apparatus wherein:
the instructions further cause the processor to determine the estimate of the remaining useful life of the vehicle further based on at least one physics based metric (see Rajkumar Fig. 4C for the “miles travelled so far” and the “predicted travel miles,” both of which are usage trends, and using these to generate a “survival curve for tire RN0985”.).
Claims 2, 3, 11, and 12, are rejected under 35 U.S.C. 103 as being unpatentable over Rajkumar et al. (US2020/0090419) in view of Malkowicz et al. (US2009/0222427) in further view of Gusikhin et al. (US2021/0241128) in further view of Ricci (US2014/0309871).
Regarding claim 2, Rajkumar, Malkowicz, and Gusikhin teach the method of claim 1.
Yet Rajkumar, Malkowicz, and Gusikhin do not explicitly further teach:
The method of claim 1, wherein
the steering system includes an electronic power steering system.
However, Ricci teaches:
the steering system includes an electronic power steering system (see paragraph 0620).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the system, as taught by Rajkumar, Malkowicz, and Gusikhin to add the additional wherein the steering system includes an electronic power steering system, as taught by Ricci. The motivation for doing so would be to use a sensor to “monitor” critical functions, as recognized by Ricci (see paragraph 0620).
This conclusion of obviousness corresponds to KSR rationale “A”: it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have combined prior art elements according to known methods to yield predictable results. See MPEP § 2141, subsection III.
The examiner could have taken official notice that power steering and steer-by-wire systems are known on autonomous vehicles taught by Gusikhin in paragraph 0038, but the examiner cites Ricci instead.
Regarding claim 3, Rajkumar, Malkowicz, and Gusikhin teach the method of claim 1.
Yet Rajkumar, Malkowicz, and Gusikhin do not explicitly further teach:
The method of claim 1, wherein
the steering system includes a steer-by-wire steering system.
However, Ricci teaches:
the steering system includes a steer-by-wire steering system (see paragraph 0620).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the system, as taught by Rajkumar, Malkowicz, and Gusikhin to add the additional wherein the steering system includes a steer-by-wire steering system, as taught by Ricci. The motivation for doing so would be to use a sensor to “monitor” critical functions, as recognized by Ricci (see paragraph 0620).
This conclusion of obviousness corresponds to KSR rationale “A”: it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have combined prior art elements according to known methods to yield predictable results. See MPEP § 2141, subsection III.
The examiner could have taken official notice that power steering and steer-by-wire systems are known on autonomous vehicles taught by Gusikhin in paragraph 0038, but the examiner cites Ricci instead.
Regarding claims 11 and 12, those claims are substantially similar to claims 2 and 3 respectively. Please see the rejections of those claims.
Claim 9 and 18 are rejected under 35 U.S.C. 103 as being unpatentable over Rajkumar in view of Malkowicz in further view of Gusikhin in further view of Kim et al. (US2015/0127429 A1).
Regarding claim 9, Rajkumar, Malkowicz, and Gusikhin teach the method of claim 8.
Yet Rajkumar, Malkowicz, and Gusikhin do not further teach:
A method further comprising
determining a monetary value of the vehicle based on the at least one hidden value reducing failure of the vehicle and the estimate of the remaining useful life of the at least one aspect of the vehicle.
However, Kim teaches:
A method further comprising
determining a monetary value of the vehicle based on the at least one hidden-value reducing failure of the vehicle and the estimate of the remaining useful life of the at least one aspect of the vehicle (see paragraph 0043 for “a reference durability value for each influence factor is stored in the vehicle part state information database 121…The reference durability value may be set as an average customer comparison value or an expected durability curve at the time of designing.” So the designer, which in a broad reasonable interpretation, is the manufacturer, provides an “excepted durability curve”. This is used to set the “reference durability value”. This is then stored on the “vehicle part state information database 121 based on the central server 110.” As shown in Fig. 4 and discussed in paragraph 0043, as the durability describes, the value decreases. As shown in Fig. 1, the “vehicle part state information database is loaded onto item 100, the “expectation price providing system”. In summary, like the present disclosure, Kim essentially teaches a Carfax report that is based on more than just vehicle age and mileage, but also on usage of individual components, accident history, maintenance, etc., as shown in Kim Fig. 3)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the system, as taught by Rajkumar, Malkowicz, and Gusikhin, to add the additional features of determining a monetary value of the vehicle based on the at least one hidden value reducing failure of the vehicle and the estimate of the remaining useful life of the at least one aspect of the vehicle, as taught by Kim. The motivation for doing so would be to determine the “right sale price” of a vehicle, as recognized by Kim (see paragraph 0008.).
This conclusion of obviousness corresponds to KSR rationale “A”: it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have combined prior art elements according to known methods to yield predictable results. See MPEP § 2141, subsection III.
Furthermore, Rajkumar at least strongly teaches toward this claim. See paragraph 0002 for connecting the RUL to avoiding “financial loss,” which is monetary.
Regarding claim 18, the claim is substantially similar to claim 9. Please see the rejection of that claim.
Conclusion
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). 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.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to DANIEL M. ROBERT whose telephone number is (571)270-5841. The examiner can normally be reached M-F 7:30-4:30 EST.
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, Hunter Lonsberry can be reached at 571-272-7298. 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.
/DANIEL M. ROBERT/Primary Examiner, Art Unit 3665