Prosecution Insights
Last updated: April 19, 2026
Application No. 18/910,847

SYSTEMS AND METHODS FOR MONITORING VEHICLE DIAGNOSTICS

Non-Final OA §103§DP
Filed
Oct 09, 2024
Examiner
GREENE, DANIEL LAWSON
Art Unit
3665
Tech Center
3600 — Transportation & Electronic Commerce
Assignee
United Parcel Service of America, Inc.
OA Round
1 (Non-Final)
76%
Grant Probability
Favorable
1-2
OA Rounds
2y 11m
To Grant
93%
With Interview

Examiner Intelligence

Grants 76% — above average
76%
Career Allow Rate
653 granted / 859 resolved
+24.0% vs TC avg
Strong +17% interview lift
Without
With
+17.1%
Interview Lift
resolved cases with interview
Typical timeline
2y 11m
Avg Prosecution
26 currently pending
Career history
885
Total Applications
across all art units

Statute-Specific Performance

§101
10.3%
-29.7% vs TC avg
§103
50.1%
+10.1% vs TC avg
§102
17.4%
-22.6% vs TC avg
§112
10.5%
-29.5% vs TC avg
Black line = Tech Center average estimate • Based on career data from 859 resolved cases

Office Action

§103 §DP
DETAILED ACTION This is the First Office Action on the Merits and is directed towards claims 1-20 as originally presented and filed on 10/09/2024. This application is subject to Double Patent rejections with the Parent Applications. Notice of Pre-AIA or AIA Status Priority is claimed as set forth below, accordingly the earliest effective filing date is May 19, 2017 (20170519). The present application, effectively filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA . Priority This application is a continuation application of U.S. Non-Provisional Application No. 17/717,726, entitled "Systems and Methods for Vehicle Diagnostics" filed on April 11, 2022, now U.S. Patent 12,136,302 (“Parent Application”), which claims priority to U.S. Non-Provisional Application No. 16/891,298, entitled "Systems and Methods for Vehicle Diagnostics" filed on June 3, 2020, now U.S. Patent 11,328,541 (“Parent Application”), which claims priority to U.S. Non-Provisional Application No. 15/984,070, entitled "Systems and Methods for Vehicle Diagnostics" filed on May 18, 2018, now U.S. Patent 10,719,997 (“Parent Application”), which claims priority to Provisional Patent Application No. 62/508,451, filed May 19, 2017. See MPEP §201.07[R-08.2017]. In accordance with MPEP §609.02 [R-07.2015] Section A. 2 and MPEP §2001.06(b)[R-08.2017] (last paragraph), the Examiner has reviewed and considered the prior art cited in the Parent Application. Also in accordance with MPEP §2001.06(b) [R-08.2017] (last paragraph), all documents cited or considered ‘of record’ in the Parent Application are now considered cited or ‘of record’ in this application. Additionally, Applicant(s) are reminded that a listing of the information cited or ‘of record’ in the Parent Application need not be resubmitted in this application unless Applicants desire the information to be printed on a patent issuing from this application. See MPEP §609.02 [R-07.2015] Section A. 2. Finally, Applicants are reminded that the prosecution history of the Parent Application is relevant in this application. See e.g., Microsoft Corp. v. Multi-Tech Sys., Inc., 357 F.3d 1340, 1350, 69 USPQ2d 1815, 1823 (Fed. Cir. 2004) (holding that statements made in prosecution of one patent are relevant to the scope of all sibling patents). Information Disclosure Statement As required by M.P.E.P. 609 [R-07.2022], Applicant's 01/27/2025 submission(s) of Information Disclosure Statement (IDS)(s) is/are acknowledged by the Examiner and the reference(s) cited therein has/have been considered in the examination of the claim(s) now pending. A copy of the submitted IDS(s) initialed and dated by the Examiner is/are attached to the instant Office action. Specification Content of Specification (a) TITLE OF THE INVENTION: See 37 CFR 1.72(a) and MPEP § 606. The title of the invention should be placed at the top of the first page of the specification unless the title is provided in an application data sheet. The title of the invention should be brief but technically accurate and descriptive, preferably from two to seven words. It may not contain more than 500 characters. (b) CROSS-REFERENCES TO RELATED APPLICATIONS: See 37 CFR 1.78 and MPEP § 211 et seq. (c) STATEMENT REGARDING FEDERALLY SPONSORED RESEARCH OR DEVELOPMENT: See MPEP § 310. (d) THE NAMES OF THE PARTIES TO A JOINT RESEARCH AGREEMENT. See 37 CFR 1.71(g). (e) INCORPORATION-BY-REFERENCE OF MATERIAL SUBMITTED ON A READ-ONLY OPTICAL DISC, AS A TEXT FILE OR AN XML FILE VIA THE PATENT ELECTRONIC SYSTEM: The specification is required to include an incorporation-by-reference of electronic documents that are to become part of the permanent United States Patent and Trademark Office records in the file of a patent application. See 37 CFR 1.77(b)(5) and MPEP § 608.05. See also the Legal Framework for Patent Electronic System posted on the USPTO website (https://www.uspto.gov/sites/default/files/documents/2019LegalFrameworkPES.pdf) and MPEP § 502.05 (f) STATEMENT REGARDING PRIOR DISCLOSURES BY THE INVENTOR OR A JOINT INVENTOR. See 35 U.S.C. 102(b) and 37 CFR 1.77. (g) BACKGROUND OF THE INVENTION: See MPEP § 608.01(c). The specification should set forth the Background of the Invention in two parts: (1) Field of the Invention: A statement of the field of art to which the invention pertains. This statement may include a paraphrasing of the applicable U.S. patent classification definitions of the subject matter of the claimed invention. This item may also be titled “Technical Field.” (2) Description of the Related Art including information disclosed under 37 CFR 1.97 and 37 CFR 1.98: A description of the related art known to the applicant and including, if applicable, references to specific related art and problems involved in the prior art which are solved by the applicant’s invention. This item may also be titled “Background Art.” (h) BRIEF SUMMARY OF THE INVENTION: See MPEP § 608.01(d). A brief summary or general statement of the invention as set forth in 37 CFR 1.73. The summary is separate and distinct from the abstract and is directed toward the invention rather than the disclosure as a whole. The summary may point out the advantages of the invention or how it solves problems previously existent in the prior art (and preferably indicated in the Background of the Invention). In chemical cases it should point out in general terms the utility of the invention. If possible, the nature and gist of the invention or the inventive concept should be set forth. Objects of the invention should be treated briefly and only to the extent that they contribute to an understanding of the invention. (i) BRIEF DESCRIPTION OF THE SEVERAL VIEWS OF THE DRAWING(S): See MPEP § 608.01(f). A reference to and brief description of the drawing(s) as set forth in 37 CFR 1.74. (j) DETAILED DESCRIPTION OF THE INVENTION: See MPEP § 608.01(g). A description of the preferred embodiment(s) of the invention as required in 37 CFR 1.71. The description should be as short and specific as is necessary to describe the invention adequately and accurately. Where elements or groups of elements, compounds, and processes, which are conventional and generally widely known in the field of the invention described, and their exact nature or type is not necessary for an understanding and use of the invention by a person skilled in the art, they should not be described in detail. However, where particularly complicated subject matter is involved or where the elements, compounds, or processes may not be commonly or widely known in the field, the specification should refer to another patent or readily available publication which adequately describes the subject matter. (k) CLAIM OR CLAIMS: See 37 CFR 1.75 and MPEP § 608.01(m). The claim or claims must commence on a separate sheet or electronic page (37 CFR 1.52(b)(3)). Where a claim sets forth a plurality of elements or steps, each element or step of the claim should be separated by a line indentation. There may be plural indentations to further segregate subcombinations or related steps. See 37 CFR 1.75 and MPEP 608.01(i) - (p). (l) ABSTRACT OF THE DISCLOSURE: See 37 CFR 1.72 (b) and MPEP § 608.01(b). The abstract is a brief narrative of the disclosure as a whole, as concise as the disclosure permits, in a single paragraph preferably not exceeding 150 words, commencing on a separate sheet following the claims. In an international application which has entered the national stage (37 CFR 1.491(b)), the applicant need not submit an abstract commencing on a separate sheet if an abstract was published with the international application under PCT Article 21. The abstract that appears on the cover page of the pamphlet published by the International Bureau (IB) of the World Intellectual Property Organization (WIPO) is the abstract that will be used by the USPTO. See MPEP § 1893.03(e). (m) SEQUENCE LISTING: See 37 CFR 1.821 - 1.825 and MPEP §§ 2421 - 2431. The requirement for a sequence listing applies to all sequences disclosed in a given application, whether the sequences are claimed or not. See MPEP § 2422.01. The disclosure is objected to because of the following informalities: paragraph [0001] must be updated to reflect the issuance of the parent applications. Appropriate correction is required. 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 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-20 is/are rejected under 35 U.S.C. 103 as being unpatentable over US 20030009270 A1 to Breed, David S. in view of US 20170372534 A1 to Steketee; Brian B. et al. (Steketee) Regarding claim 1 Breed teaches in for example the Figure(s) reproduced immediately below: PNG media_image1.png 578 738 media_image1.png Greyscale PNG media_image2.png 454 567 media_image2.png Greyscale PNG media_image3.png 443 628 media_image3.png Greyscale PNG media_image4.png 634 447 media_image4.png Greyscale PNG media_image5.png 775 763 media_image5.png Greyscale and associated descriptive texts a system comprising: a computer-readable storage medium storing instructions; and at least one processor communicatively coupled with the computer-readable storage medium, wherein the at least one processor is configured to execute the instructions to cause the at least one processor to (as shown in the figures above there is a system including at least one Processor 416 in Fig. 3, executing instructions as explained in for example paras: “[0215] A processor 416 is coupled to the presence determining means 410, the health state determining means 412 and the location determining means 414. A communications unit 418 is coupled to the processor 416. The processor 416 and/or communications unit 418 can also be coupled to microphones 420 that can be distributed throughout the vehicle and include voice-processing circuitry to enable the occupant(s) to effect vocal control of the processor 416, communications unit 418 or any coupled component or oral communications via the communications unit 418. The processor 416 is also coupled to another vehicular system, component or subsystem 422 and can issue control commands to effect adjustment of the operating conditions of the system, component or subsystem. Such a system, component or subsystem can be the heating or air-conditioning system, the entertainment system, an occupant restraint device such as an airbag, a glare prevention system, etc. Also, a positioning system 424 could be coupled to the processor 416 and provides an indication of the absolute position of the vehicle, preferably using satellite-based positioning technology (e.g., a GPS receiver).”): collect telematics data from an environmental sensor that generates the telematics data based on an output of a vehicle component (see Fig. 8, diagnostic module 870 and paras: “[0304] In addition, various other sensors 852, 853 measure other parameters of other components that in some manner provide information directly or indirectly on the operation of component 800. All of the sensors illustrated on FIG. 5 can be connected to a data bus 860. A diagnostic module 870, in accordance with the invention, can also be attached to the vehicle data bus 860 and receives the signals generated by the various sensors. The sensors may however be wirelessly connected to the diagnostic module 870 and be integrated into a wireless power and communications system or a combination of wired and wireless connections. [0305] As shown in FIG. 5, the diagnostic module 870 has access to the output data of each of the sensors that have information relative to the component 800. This data appears as a series of numerical values each corresponding to a measured value at a specific point in time. The cumulative data from a particular sensor is called a time series of individual data points. The diagnostic module 870 compares the patterns of data received from each sensor individually, or in combination with data from other sensors, with patterns for which the diagnostic module has been trained to determine whether the component is functioning normally or abnormally.”), wherein the telematics data (i) comprises telematics data points that are each indicative of the output of the vehicle component as a function of time and (ii) forms a telematics data signature for the vehicle component (see for example para: “[0297] Every component of a vehicle emits various signals during its life. These signals can take the form of electromagnetic radiation, acoustic radiation, thermal radiation, vibrations transmitted through the vehicle structure, and voltage or current fluctuations, depending on the particular component. When a component is functioning normally, it may not emit a perceptible signal. In that case, the normal signal is no signal, i.e., the absence of a signal. In most cases, a component will emit signals that change over its life and it is these changes which contain information as to the state of the component, e.g., whether failure of the component is impending. Usually components do not fail without warning. However, most such warnings are either not perceived or if perceived are not understood by the vehicle operator until the component actually fails and, in some cases, a breakdown of the vehicle occurs. In a few years, it is expected that various roadways will have systems for automatically guiding vehicles operating thereon. Such systems have been called "smart highways" and are part of the field of intelligent transportation systems (ITS). If a vehicle operating on such a smart highway were to breakdown, serious disruption of the system could result and the safety of other users of the smart highway could be endangered.”); identify a reference data signature for a performance metric of the vehicle component (see para: “[0346] Furthermore, the pattern recognition algorithm may be trained based on patterns within the signals from the sensors. Thus, by means of a single sensor, it would be possible to determine whether one or more components are operating abnormally. To obtain such a pattern recognition algorithm, tests are conducted using a single sensor, such as a microphone, and causing abnormal operation of one or more components, each component operating abnormally while the other components operate normally and multiple components operating abnormally. In this manner, in use, the pattern recognition algorithm may analyze a signal from a single sensor and determine abnormal operation of one or more components. Note that in some cases, simulations can be used to analytically generate the relevant data.”), wherein: the performance metric comprises at least one of a performance range, a performance tolerance, or a performance threshold for the vehicle component and identifies at least one of a desired output, a failing telematics characteristic, or a vehicle component life-cycle data signature (see for example paras: “[0388] A tire operating at correct values of load and pressure has a precise signature in terms of variation of the radius of curvature in the loaded zone. More flattening indicates under-inflation or overloading, while less flattening indicates over-inflation or under-loading. Note that tire loading has essentially no effect on internal pressure.”); and the reference data signature is indicative of how the vehicle component performs as the function of time and identifies a failure level for the vehicle component (see for example para: [0393] The accelerometer approach has the advantage of giving a signature from which a harmonic analysis of once-per-revolution disturbances could indicate developing problems such as hernias, flat spots, loss of part of the tread, sticking of foreign bodies to the tread, etc.”); compare the telematics data signature and the reference data signature to determine that the telematics data signature satisfies the failure level (see for example para: [0397] Generation 1 devices monitor pressure only while generation 2 devices also monitor the temperature and therefore will provide a warning of imminent tire failure more often than through monitoring pressure alone. Generation 3 devices will give an indication that the vehicle is overloaded before either a pressure or temperature monitoring system can respond. The generation 3 system can also be augmented to measure the vibration signature of the tire and thereby detect when a tire has worn to the point that the steel belt is contacting the road. In this manner, the generation 3 system also provides an indication of a worn out tire and, as will be discussed below, an indication of the road coefficient of friction.”); and upon determining that the telematics data signature satisfies the failure level, generate an output notification to initialize a repair procedure for the vehicle component (see paras: “[0310] Once the data has been collected, it is processed by a neural network-generating program, for example, if a neural network pattern recognition system is to be used. Such programs are available commercially, e.g., from NeuralWare of Pittsburgh, Pa. or from International Scientific Research, Inc., of Romeo Mich. for modular neural networks. The program proceeds in a trial and error manner until it successfully associates the various patterns representative of abnormal behavior, an unbalanced tire, with that condition. The resulting neural network can be tested to determine if some of the input data from some of the sensors, for example, can be eliminated. In this way, the engineer can determine what sensor data is relevant to a particular diagnostic problem. The program then generates an algorithm that is programmed onto a microprocessor, microcontroller, neural processor, FPGA, or DSP (herein collectively referred to as a microprocessor or processor). Such a microprocessor appears inside the diagnostic module 870 in FIG. 5. Once trained, the neural network, as represented by the algorithm, will now recognize an unbalanced tire on a vehicle when this event occurs. At that time, when the tire is unbalanced, the diagnostic module 870 will output a message to the driver indicating that the tire should be now be balanced as described in more detail below. The message to the driver is provided by output means coupled to or incorporated within the module 870 and may be, e.g., a light on the dashboard, a vocal tone or any other recognizable indication apparatus. A similar message may also be sent to the dealer or other repair facility or remote facility. [0369] Information from the occupant sensing system 1000, vehicle sensors 1004 and environment sensors 1006 could also be transmitted to the vehicle manufacturer 1016 in the event of an accident so that a determination can be made as to whether failure of a component of the vehicle causes or contributed to the cause of the accident. For example, the vehicle sensors might determine that the tire pressure was too low so that advice can be disseminated to avoid maintaining the tire pressure too low in order to avoid an accident. Information from the vehicle sensors 1004 relating to component failure could be transmitted to a dealer/repair facility 1012 which could schedule maintenance to correct the problem.”). While Breed teaches the invention as claimed and explained above, if applicant is of the opinion that Breed does not appear to expressly disclose a signature of the device then resort may be had to the teachings of Steketee. In analogous art Steketee teaches in for example, the figures below: PNG media_image6.png 362 478 media_image6.png Greyscale And associated descriptive texts (in for example para: “[0291] As discussed in more detail above, tracking the wear on vehicles and work tools is useful. Accelerometer data can assist in this regard. Raw accelerometer data can be processed to provide a variety of different metrics. An example would be watching wear out over time. The signature can then be transformed to limits and triggers for that specific wear out. Identifying these patterns are all about monitoring the raw data and mining the possibilities. The associated activity data among the monitors can be used to assure safety, enable training, and understand use. The use and associations can be used to calculate wear over time. This calculation uses wear index tables for each association.”). It would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to combine the signatures disclosed in Steketee with the signatures taught in Breed with a reasonable expectation of success because it would have “assure safety, enable training, and understand use.” as taught by Steketee Para(s) [0291] above. Regarding claim 2 and the limitation the system of claim 1, wherein, upon determining that the telematics data signature satisfies the failure level, the at least one processor is configured to execute the instructions to cause the at least one processor to order at least one of a replacement part or a repair part for the vehicle component (see Steketee para: “[0123] FIG. 1 illustrates one embodiment of a system for comparison and recommender for vehicles and parts providers by cost and wear analysis. The depicted embodiment includes vehicles, OEM parts and service parts recommendation database and website. This database can be populated with data from a variety of different sources including heavy duty equipment, devices installed on heavy duty equipment, or measurement tools used to collect various data about the heavy duty equipment. The collected information can be used to determine information about various wear parts in the heavy duty equipment. That information can be used to order new wear parts, automatically if desired by the user.). It would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to combine the ordering disclosed in Steketee with Breed with a reasonable expectation of success because it would have “determined the timing needed in ordering and delivering on time replacements for service” as taught by Steketee Para(s) “[0135] One aspect of the invention enables dynamic wear part ordering based on the monitored status of heavy equipment. The dynamic nature of the system does not only relate to ordering wear parts dynamically, but also relates to operator performance, environmental conditions, and service interactions. This can take into consideration the rate of usage against the rate of decay of a given part to determine the timing needed in ordering and delivering on time replacements for service. Scheduling of that service is also a key outcome.” Regarding claim 3 and the limitation the system of claim 1, wherein, upon determining that the telematics data signature satisfies the failure level, the at least one processor is configured to execute the instructions to cause the at least one processor to generate an alert to a user indicating that the vehicle component is failing (see Breed para: “[0019] There are various gages on an automobile which alert the driver to various vehicle problems. For example, if the oil pressure drops below some predetermined level, the driver is warned to stop his vehicle immediately. Similarly, if the coolant temperature exceeds some predetermined value, the driver is also warned to take immediate corrective action. In these cases, the warning often comes too late as most vehicle gages alert the driver after he or she can conveniently solve the problem. Thus, what is needed is a component failure warning system that alerts the driver to the impending failure of a component sufficiently in advance of the time when the problem gets to a catastrophic point.”). Regarding claim 4 and the limitation the system of claim 1, wherein the at least one processor is configured to execute the instructions to cause the at least one processor to generate derivative telematics data characteristics of the telematics data signature, the reference data signature comprises derivative reference data characteristics, and comparing the telematics data signature with the reference data signature comprises comparing the derivative telematics data characteristics with the derivative reference data characteristics (see the teachings of Steketee paras: “[0192] FIG. 21 illustrates SMA (Simple Moving Average) for different activities over the data. There are seven distinct chunks corresponding to each test. SMA is helpful at identifying moving forward, but not as helpful for other states. This is a good way to help determine variables in the analysis and also helpful in determining how much activity occurs over time. FIG. 22 provides additional data on more variables. RMS, SMA, and standard deviation of the 3 axes behave similarly. [0272] The relative change in force magnitude can be tracked in a variety of different ways. In the current embodiment, the running event force vector magnitude for a given accelerometer is compared to the previous running event force vector magnitude for that accelerometer to determine a percentage change in force magnitude. For example, if the previous running event for a vehicle sensor had a force magnitude of 5 m/s.sup.2 and the latest running event for that vehicle sensor has a force magnitude of 8 m/s.sup.2, the percentage change in force magnitude would be 60%. In alternative embodiments, the percentage change in force magnitude could be calculated in a variety of different ways such as by using a running average of a predetermined number of samples. The mass and rotation of an excavator can impact these ratios. For example if the bucket is extended and the vehicle is on an angle the weight of the bucket and arm can impact the safety angle dramatically. This can be exaggerated if the bucket is loaded.”). It would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings disclosed in Steketee with Breed with a reasonable expectation of success because it would have “assured safety, enabled training, and understand use.” as taught by Steketee Para(s) [0291] above. Regarding claim 5 and the limitation the system of claim 4, wherein the derivative telematics data characteristics comprises a moving average of the telematics data signature (see the obviousness to combine and the rejection of corresponding parts of claim 4 above incorporated herein by reference, i.e. Steketee “SMA (Simple Moving Average) “). Regarding claim 6 and the limitation the system of claim 1, wherein the failure level identifies a range of the telematics data indicative of the vehicle component failing (see breed paras: “[0301] When a vehicle component begins to change its operating behavior, it is not always apparent from the particular sensors, if any, which are monitoring that component. The output from any one of these sensors can be normal even though the component is failing. By analyzing the output of a variety of sensors, however, the pending failure can be diagnosed. For example, the rate of temperature rise in the vehicle coolant, if it were monitored, might appear normal unless it were known that the vehicle was idling and not traveling down a highway at a high speed. Even the level of coolant temperature which is in the normal range could be in fact abnormal in some situations signifying a failing coolant pump, for example, but not detectable from the coolant thermometer alone. [0325] (h) notifying a driver if the value on one output series node is within a chosen range signifying that a tire requires balancing.”). Regarding claim 7 and the limitation the system of claim 1, wherein the failure level identifies a tolerance for the telematics data indicative of the vehicle component failing (it is considered that the BRI of the term a tolerance connotes the range taught in Breed para: “[0301] When a vehicle component begins to change its operating behavior, it is not always apparent from the particular sensors, if any, which are monitoring that component. The output from any one of these sensors can be normal even though the component is failing. By analyzing the output of a variety of sensors, however, the pending failure can be diagnosed. For example, the rate of temperature rise in the vehicle coolant, if it were monitored, might appear normal unless it were known that the vehicle was idling and not traveling down a highway at a high speed. Even the level of coolant temperature which is in the normal range could be in fact abnormal in some situations signifying a failing coolant pump, for example, but not detectable from the coolant thermometer alone.”). Regarding claim 8 and the limitation the system of claim 1, wherein the failure level identifies a threshold for the telematics data indicative of the vehicle component failing (see the teachings of Breed wherein it is understood that identifying an abnormality requires the “part” going past the normal threshold as explained in for example paras: “[0310] Once the data has been collected, it is processed by a neural network-generating program, for example, if a neural network pattern recognition system is to be used. Such programs are available commercially, e.g., from NeuralWare of Pittsburgh, Pa. or from International Scientific Research, Inc., of Romeo Mich. for modular neural networks. The program proceeds in a trial and error manner until it successfully associates the various patterns representative of abnormal behavior, an unbalanced tire, with that condition. The resulting neural network can be tested to determine if some of the input data from some of the sensors, for example, can be eliminated. In this way, the engineer can determine what sensor data is relevant to a particular diagnostic problem. The program then generates an algorithm that is programmed onto a microprocessor, microcontroller, neural processor, FPGA, or DSP (herein collectively referred to as a microprocessor or processor). Such a microprocessor appears inside the diagnostic module 870 in FIG. 5. Once trained, the neural network, as represented by the algorithm, will now recognize an unbalanced tire on a vehicle when this event occurs. At that time, when the tire is unbalanced, the diagnostic module 870 will output a message to the driver indicating that the tire should be now be balanced as described in more detail below. The message to the driver is provided by output means coupled to or incorporated within the module 870 and may be, e.g., a light on the dashboard, a vocal tone or any other recognizable indication apparatus. A similar message may also be sent to the dealer or other repair facility or remote facility. [0311] It is important to note that there may be many neural networks involved in a total vehicle diagnostic system. These can be organized either in parallel, series, as an ensemble, cellular neural network or as a modular neural network system. In one implementation of a modular neural network, a primary neural network identifies that there is an abnormality and tries to identify the likely source. Once a choice has been made as to the likely source of the abnormality, another of a group of neural networks is called upon to determine the exact cause of the abnormality. In this manner, the neural networks are arranged in a tree pattern with each neural network trained to perform a particular pattern recognition task.”). Regarding claim 9 and the limitation a method comprising: collecting, by at least one computing entity, telematics data from a vehicle mounted sensor that generates the telematics data based on an output of a vehicle component, wherein the telematics data (i) comprises telematics data points that are each indicative of the output of the vehicle component as a function of time and (ii) forms a telematics data signature for the vehicle component; identifying, by the at least one computing entity, a reference data signature for a performance metric of the vehicle component, wherein: the performance metric comprises at least one of a performance range, a performance tolerance, or a performance threshold for the vehicle component and identifies at least one of a desired output, a failing telematics characteristic, or a vehicle component life-cycle data signature, and the reference data signature is indicative of how the vehicle component performs as the function of time and identifies a failure level for the vehicle component; comparing, by the at least one computing entity, the telematics data signature and the reference data signature to determine that the telematics data signature satisfies the failure level; `and upon determining that the telematics data signature satisfies the failure level, generating, by the at least one computing entity, an output notification to initialize a repair procedure for the vehicle component (see the obviousness to combine and the rejection of corresponding parts of claim 1 above incorporated herein by reference). Regarding claim 10 and the limitation the method of claim 9, wherein, upon determining that the telematics data signature satisfies the failure level, the method further comprises ordering at least one of a replacement part or a repair part for the vehicle component (see the obviousness to combine and the rejection of corresponding parts of claim 2 above incorporated herein by reference). Regarding claim 11 and the limitation the method of claim 9, wherein, upon determining that the telematics data signature satisfies the failure level, the method further comprises generating an alert to a user indicating that the vehicle component is failing (see the obviousness to combine and the rejection of corresponding parts of claim 3 above incorporated herein by reference). Regarding claim 12 and the limitation the method of claim 9, wherein the method further comprises generating, by the at least one computing entity, derivative telematics data characteristics of the telematics data signature, the reference data signature comprises derivative reference data characteristics, and comparing the telematics data signature with the reference data signature comprises comparing the derivative telematics data characteristics with the derivative reference data characteristics (see the obviousness to combine and the rejection of corresponding parts of claim 4 above incorporated herein by reference). Regarding claim 13 and the limitation the method of claim 12, wherein the derivative telematics data characteristics comprises a moving average of the telematics data signature (see the obviousness to combine and the rejection of corresponding parts of claim 5 above incorporated herein by reference). Regarding claim 14 and the limitation the method of claim 9, wherein the failure level identifies a range of the telematics data indicative of the vehicle component failing (see the obviousness to combine and the rejection of corresponding parts of claim 6 above incorporated herein by reference). Regarding claim 15 and the limitation the method of claim 9, wherein the failure level identifies a tolerance for the telematics data indicative of the vehicle component failing (see the obviousness to combine and the rejection of corresponding parts of claim 7 above incorporated herein by reference). Regarding claim 16 and the limitation the method of claim 9, wherein the failure level identifies a threshold for the telematics data indicative of the vehicle component failing (see the obviousness to combine and the rejection of corresponding parts of claim 8 above incorporated herein by reference). Regarding claim 17 and the limitation A computer-readable medium storing computer-executable instructions that, when executed by at least one computing entity, configure the at least one computing entity to perform operations comprising: collecting data from a sensor that generates the data based on an output of a vehicle component, wherein the data (i) comprises data points that are each indicative of the output of the vehicle component as a function of time and (ii) forms a data signature for the vehicle component; identifying a reference data signature for a performance metric of the vehicle component, wherein: the performance metric comprises at least one of a performance range, a performance tolerance, or a performance threshold for the vehicle component, and the reference data signature is indicative of how the vehicle component performs as the function of time and identifies a failure level for the vehicle component; comparing the data signature and the reference data signature to determine that the data signature satisfies the failure level; and upon determining that the data signature satisfies the failure level, generating an output notification to initialize a repair procedure for the vehicle component (see the obviousness to combine and the rejection of corresponding parts of claim 1 above incorporated herein by reference). Regarding claim 18 and the limitation the computer-readable storage medium of claim 17, wherein the failure level identifies a range of the data indicative of the vehicle component failing (see the obviousness to combine and the rejection of corresponding parts of claim 6 above incorporated herein by reference). Regarding claim 19 and the limitation the computer-readable storage medium of claim 17, wherein the failure level identifies a tolerance for the data indicative of the vehicle component failing (see the obviousness to combine and the rejection of corresponding parts of claim 7 above incorporated herein by reference). Regarding claim 20 and the limitation the computer-readable storage medium of claim 17, wherein the failure level identifies a threshold for the data indicative of the vehicle component failing (see the obviousness to combine and the rejection of corresponding parts of claim 8 above incorporated herein by reference). Double Patenting The nonstatutory double patenting rejection is based on a judicially created doctrine grounded in public policy (a policy reflected in the statute) so as to prevent the unjustified or improper timewise extension of the “right to exclude” granted by a patent and to prevent possible harassment by multiple assignees. A nonstatutory double patenting rejection is appropriate where the conflicting claims are not identical, but at least one examined application claim is not patentably distinct from the reference claim(s) because the examined application claim is either anticipated by, or would have been obvious over, the reference claim(s). See, e.g., In re Berg, 140 F.3d 1428, 46 USPQ2d 1226 (Fed. Cir. 1998); In re Goodman, 11 F.3d 1046, 29 USPQ2d 2010 (Fed. Cir. 1993); In re Longi, 759 F.2d 887, 225 USPQ 645 (Fed. Cir. 1985); In re Van Ornum, 686 F.2d 937, 214 USPQ 761 (CCPA 1982); In re Vogel, 422 F.2d 438, 164 USPQ 619 (CCPA 1970); In re Thorington, 418 F.2d 528, 163 USPQ 644 (CCPA 1969). A timely filed terminal disclaimer in compliance with 37 CFR 1.321(c) or 1.321(d) may be used to overcome an actual or provisional rejection based on nonstatutory double patenting provided the reference application or patent either is shown to be commonly owned with the examined application, or claims an invention made as a result of activities undertaken within the scope of a joint research agreement. See MPEP § 717.02 for applications subject to examination under the first inventor to file provisions of the AIA as explained in MPEP § 2159. See MPEP § 2146 et seq. for applications not subject to examination under the first inventor to file provisions of the AIA . A terminal disclaimer must be signed in compliance with 37 CFR 1.321(b). The filing of a terminal disclaimer by itself is not a complete reply to a nonstatutory double patenting (NSDP) rejection. A complete reply requires that the terminal disclaimer be accompanied by a reply requesting reconsideration of the prior Office action. Even where the NSDP rejection is provisional the reply must be complete. See MPEP § 804, subsection I.B.1. For a reply to a non-final Office action, see 37 CFR 1.111(a). For a reply to final Office action, see 37 CFR 1.113(c). A request for reconsideration while not provided for in 37 CFR 1.113(c) may be filed after final for consideration. See MPEP §§ 706.07(e) and 714.13. The USPTO Internet website contains terminal disclaimer forms which may be used. Please visit www.uspto.gov/patent/patents-forms. The actual filing date of the application in which the form is filed determines what form (e.g., PTO/SB/25, PTO/SB/26, PTO/AIA /25, or PTO/AIA /26) should be used. A web-based eTerminal Disclaimer may be filled out completely online using web-screens. An eTerminal Disclaimer that meets all requirements is auto-processed and approved immediately upon submission. For more information about eTerminal Disclaimers, refer to www.uspto.gov/patents/apply/applying-online/eterminal-disclaimer. Claims 1-20 are rejected on the ground of nonstatutory double patenting as being unpatentable over claims 1, 6 AND 12 of U.S. Patent No. US 10719997 B1. Although the claims at issue are not identical, they are not patentably distinct from each other as shown in the side by side comparison below. Those claims not cited are rejected for depending from a rejected base claim. Claims of instant Application Claims of U.S. Patent No. 10,719,997 B1 1. A system comprising: a computer-readable storage medium storing instructions; and at least one processor communicatively coupled with the computer-readable storage medium, wherein the at least one processor is configured to execute the instructions to cause the at least one processor to: collect telematics data from an environmental sensor that generates the telematics data based on an output of a vehicle component, wherein the telematics data (i) comprises telematics data points that are each indicative of the output of the vehicle component as a function of time and (ii) forms a telematics data signature for the vehicle component; identify a reference data signature for a performance metric of the vehicle component, wherein: the performance metric comprises at least one of a performance range, a performance tolerance, or a performance threshold for the vehicle component and identifies at least one of a desired output, a failing telematics characteristic, or a vehicle component life-cycle data signature, and the reference data signature is indicative of how the vehicle component performs as the function of time and identifies a failure level for the vehicle component; compare the telematics data signature and the reference data signature to determine that the telematics data signature satisfies the failure level; and upon determining that the telematics data signature satisfies the failure level, generate an output notification to initialize a repair procedure for the vehicle component. A prognostic vehicle diagnostic system configured for monitoring the relative health of one or more vehicle components, the system comprising: at least one voltage sensor secured within a vehicle and configured to monitor a voltage output of a vehicle alternator and generate telematics data based on the voltage output of the vehicle alternator; and a computing entity in wireless communication with the vehicle, the computing entity configured to: receive telematics data from the at least one voltage sensor, wherein the telematics data comprises a plurality of telematics data points each indicative of the voltage output of the vehicle alternator; store the received telematics data within a telematics data file to form a telematics data signature for the vehicle alternator; generate an inquiry to identify at least one predetermined performance metric for one or more types of telematics data to be retrieved, wherein the at least one predetermined metric comprises detecting a threshold value for a moving average voltage output for an alternator; retrieve the at least one identified predetermined performance metric comprising the threshold value for the moving average voltage output and a reference data signature for the vehicle alternator that is indicative of how the alternator performs as a function of time, wherein the reference data signature identifies a threshold vehicle alternator failure level for the vehicle alternator and wherein the at least one identified predetermined performance metric identifies one or more of desired alternator output, failing alternator telematics characteristics, and vehicle component life-cycle data signature; compare the telematics data signature and the reference data signature to determine whether the telematics data signature satisfies the threshold vehicle alternator failure level; and upon determining that the telematics data signature satisfies the threshold vehicle alternator failure level, generate an output notification to initialize a repair procedure for the vehicle alternator. 9. A method comprising: collecting, by at least one computing entity, telematics data from a vehicle mounted sensor that generates the telematics data based on an output of a vehicle component, wherein the telematics data (i) comprises telematics data points that are each indicative of the output of the vehicle component as a function of time and (ii) forms a telematics data signature for the vehicle component; identifying, by the at least one computing entity, a reference data signature for a performance metric of the vehicle component, wherein: the performance metric comprises at least one of a performance range, a performance tolerance, or a performance threshold for the vehicle component and identifies at least one of a desired output, a failing telematics characteristic, or a vehicle component life-cycle data signature, and the reference data signature is indicative of how the vehicle component performs as the function of time and identifies a failure level for the vehicle component; comparing, by the at least one computing entity, the telematics data signature and the reference data signature to determine that the telematics data signature satisfies the failure level; and upon determining that the telematics data signature satisfies the failure level, generating, by the at least one computing entity, an output notification to initialize a repair procedure for the vehicle component. 6. A method for prognostic diagnosis of one or more vehicle components, the method comprising: generating telematics data via at least one nitrogen dioxide sensor secured within a vehicle and configured to monitor the nitrogen dioxide output level within a vehicle exhaust, wherein the telematics data comprises a plurality of telematics data points each indicative of the vehicle nitrogen dioxide output level; storing, via a computing entity in wireless communication with the vehicle, the generated telematics data within a telematics data file to form a telematics data signature for the at least one nitrogen dioxide sensor; calculating, via the computing entity, a maximum detected nitrogen dioxide quantity in an exhaust emission for the vehicle; retrieving, via the computing entity, a performance metric comprising a threshold maximum detected nitrogen dioxide quantity for the exhaust emission and a reference data signature for the at least one nitrogen dioxide sensor, wherein the reference data signature identifies a reference nitrogen dioxide level as a function of time and a threshold nitrogen dioxide sensor failure level for the vehicle nitrogen dioxide sensor; comparing, via the computing entity, the telematics data signature and the reference data signature to determine whether the telematics data signature satisfies the threshold vehicle nitrogen dioxide sensor failure level; upon determining that the telematics data signature satisfies the threshold vehicle nitrogen dioxide sensor failure level, generating, via the computing entity, an output notification to initialize one or more of: a repair procedure for a catalytic converter, ordering of a replacement catalytic converter, and generating a notification to a user that the vehicle should not be utilized until the catalytic converter is repaired. 17. A computer-readable medium storing computer-executable instructions that, when executed by at least one computing entity, configure the at least one computing entity to perform operations comprising: collecting data from a sensor that generates the data based on an output of a vehicle component, wherein the data (i) comprises data points that are each indicative of the output of the vehicle component as a function of time and (ii) forms a data signature for the vehicle component; identifying a reference data signature for a performance metric of the vehicle component, wherein: the performance metric comprises at least one of a performance range, a performance tolerance, or a performance threshold for the vehicle component, and the reference data signature is indicative of how the vehicle component performs as the function of time and identifies a failure level for the vehicle component; comparing the data signature and the reference data signature to determine that the data signature satisfies the failure level; and upon determining that the data signature satisfies the failure level, generating an output notification to initialize a repair procedure for the vehicle component. 12. A computer program product comprising at least one non-transitory computer-readable storage medium having computer-readable program code portions stored therein, the computer-readable program code portions comprising: an executable portion configured to receive telematics data generated via at least one voltage sensor secured within a vehicle and configured to monitor the voltage output of a vehicle alternator, wherein the telematics data comprises a plurality of telematics data points each indicative of the voltage output of the vehicle alternator; an executable portion configured to store the generated telematics data within a telematics data file to form a telematics data signature for the vehicle alternator; an executable portion configured to generate an inquiry to identify at least one predetermined performance metric for one or more types of telematics data to be retrieved, wherein the at least one predetermined metric comprises detecting a threshold value for a moving average voltage output for an alternator; an executable portion configured to retrieve at least one performance metric comprising the threshold value for the moving average voltage output and a reference data signature for the vehicle alternator that is indicative of the performance of the alternator as a function of time, wherein the reference data signature identifies a threshold vehicle alternator failure level for the vehicle alternator and wherein the at least one identified predetermined performance metric identifies one or more of desired alternator output, failing alternator telematics characteristics, and vehicle component life-cycle data signature; an executable portion configured to compare the telematics data signature and the reference data signature to determine whether the telematics data signature satisfies the threshold vehicle alternator failure level; and an executable portion configured to, upon determining that the telematics data signature satisfies the threshold vehicle alternator failure level, generate an output notification to initialize a repair procedure for the vehicle alternator. Claims 1-20 are rejected on the ground of nonstatutory double patenting as being unpatentable over claims 1, 8 and 15 of U.S. Patent No. 11,328,541 B2. Although the claims at issue are not identical, they are not patentably distinct from each other as shown in the side by side comparison below. Those claims not cited are rejected for depending from a rejected base claim. Claims of instant Application Claims of U.S. Patent No. 11,328,541 1. A system comprising: a computer-readable storage medium storing instructions; and at least one processor communicatively coupled with the computer-readable storage medium, wherein the at least one processor is configured to execute the instructions to cause the at least one processor to: collect telematics data from an environmental sensor that generates the telematics data based on an output of a vehicle component, wherein the telematics data (i) comprises telematics data points that are each indicative of the output of the vehicle component as a function of time and (ii) forms a telematics data signature for the vehicle component; identify a reference data signature for a performance metric of the vehicle component, wherein: the performance metric comprises at least one of a performance range, a performance tolerance, or a performance threshold for the vehicle component and identifies at least one of a desired output, a failing telematics characteristic, or a vehicle component life-cycle data signature, and the reference data signature is indicative of how the vehicle component performs as the function of time and identifies a failure level for the vehicle component; compare the telematics data signature and the reference data signature to determine that the telematics data signature satisfies the failure level; and upon determining that the telematics data signature satisfies the failure level, generate an output notification to initialize a repair procedure for the vehicle component. A prognostic vehicle diagnostic system configured for monitoring the relative health of one or more vehicle components, the system comprising: at least one voltage sensor secured within a vehicle and configured to monitor a voltage output of one or more vehicle electrical components and generate telematics data based on the voltage output of the one or more vehicle electrical components; and a computing entity in wireless communication with the vehicle, the computing entity configured to: receive telematics data from the at least one voltage sensor, wherein the telematics data comprises a plurality of telematics data points each indicative of the voltage output of the one or more vehicle electrical components; store the received telematics data within a telematics data file to form a telematics data signature for the one or more vehicle electrical components; generate an inquiry to identify at least one predetermined performance metric for one or more types of telematics data to be retrieved, wherein the at least one predetermined metric comprises detecting a threshold value for a moving average voltage output for the one or more vehicle electrical components; retrieve the at least one identified predetermined performance metric comprising the threshold value for the moving average voltage output and a reference data signature for the one or more vehicle electrical components that is indicative of how the one or more vehicle electrical components performs as a function of time, wherein the reference data signature identifies a threshold vehicle electrical failure level for the one or more vehicle electrical components and wherein the at least one identified predetermined performance metric identifies one or more of desired vehicle electrical component output, failing vehicle electric component telematics characteristics, and vehicle component life-cycle data signature; compare the telematics data signature and the reference data signature to determine whether the telematics data signature satisfies the threshold vehicle electrical component failure level; upon determining that the telematics data signature satisfies the threshold vehicle electrical component failure level, generate an output notification to initialize one or more of: a repair procedure for the vehicle electrical component, ordering of a replacement vehicle electrical component, and generating a notification to a user that the vehicle should not be utilized until the vehicle electrical component is repaired. 9. A method comprising: collecting, by at least one computing entity, telematics data from a vehicle mounted sensor that generates the telematics data based on an output of a vehicle component, wherein the telematics data (i) comprises telematics data points that are each indicative of the output of the vehicle component as a function of time and (ii) forms a telematics data signature for the vehicle component; identifying, by the at least one computing entity, a reference data signature for a performance metric of the vehicle component, wherein: the performance metric comprises at least one of a performance range, a performance tolerance, or a performance threshold for the vehicle component and identifies at least one of a desired output, a failing telematics characteristic, or a vehicle component life-cycle data signature, and the reference data signature is indicative of how the vehicle component performs as the function of time and identifies a failure level for the vehicle component; comparing, by the at least one computing entity, the telematics data signature and the reference data signature to determine that the telematics data signature satisfies the failure level; and upon determining that the telematics data signature satisfies the failure level, generating, by the at least one computing entity, an output notification to initialize a repair procedure for the vehicle component. 8. A prognostic vehicle diagnostic system configured for monitoring the relative health of a vehicle battery, the system comprising: at least one voltage sensor secured within a vehicle and configured to monitor a voltage output of a vehicle battery and generate telematics data based on the voltage output of the vehicle battery; and a computing entity in wireless communication with the vehicle, the computing entity configured to: receive telematics data from the at least one voltage sensor, wherein the telematics data comprises a plurality of telematics data points each indicative of the voltage output of the vehicle battery; store the received telematics data within a telematics data file to form a telematics data signature for the vehicle battery; generate an inquiry to identify at least one predetermined performance metric for one or more types of telematics data to be retrieved, wherein the at least one predetermined metric comprises detecting a threshold value for an average voltage output for the vehicle battery; retrieve the at least one identified predetermined performance metric comprising the threshold value for the average voltage output for the vehicle battery and a reference data signature for the vehicle battery that is indicative of how the vehicle battery performs as a function of time, wherein the reference data signature identifies a threshold vehicle electrical failure level for the vehicle battery and wherein the at least one identified predetermined performance metric identifies one or more of desired battery output, failing vehicle battery telematics characteristics, and vehicle component life-cycle data signature; compare the telematics data signature and the reference data signature to determine whether the telematics data signature satisfies the threshold vehicle battery failure level; upon determining that the telematics data signature satisfies the threshold vehicle battery failure level, generate an output notification to initialize one or more of: a repair procedure for the vehicle battery, ordering of a replacement vehicle battery, and generating a notification to a user that the vehicle should not be utilized until the vehicle battery is repaired. 17. A computer-readable medium storing computer-executable instructions that, when executed by at least one computing entity, configure the at least one computing entity to perform operations comprising: collecting data from a sensor that generates the data based on an output of a vehicle component, wherein the data (i) comprises data points that are each indicative of the output of the vehicle component as a function of time and (ii) forms a data signature for the vehicle component; identifying a reference data signature for a performance metric of the vehicle component, wherein: the performance metric comprises at least one of a performance range, a performance tolerance, or a performance threshold for the vehicle component, and the reference data signature is indicative of how the vehicle component performs as the function of time and identifies a failure level for the vehicle component; comparing the data signature and the reference data signature to determine that the data signature satisfies the failure level; and upon determining that the data signature satisfies the failure level, generating an output notification to initialize a repair procedure for the vehicle component. 15. A computer program product comprising at least one non-transitory computer-readable storage medium having computer-readable program code portions stored therein, the computer-readable program code portions comprising: an executable portion configured to receive telematics data generated via at least one voltage sensor secured within a vehicle and configured to monitor the starter current of a vehicle starter, wherein the telematics data comprises a plurality of telematics data points each indicative of starter current of the vehicle starter; an executable portion configured to store the generated telematics data within a telematics data file to form a telematics data signature for the vehicle starter; an executable portion configured to generate an inquiry to identify at least one predetermined performance metric for one or more types of telematics data to be retrieved, wherein the at least one predetermined metric comprises detecting a threshold value for an average starter current for the vehicle starter; an executable portion configured to retrieve at least one performance metric comprising the threshold value for the average starter current for the vehicle starter and a reference data signature for the vehicle alternator that is indicative of the performance of the vehicle starter as a function of time, wherein the reference data signature identifies a threshold vehicle starter failure level for the vehicle starter and wherein the at least one identified predetermined performance metric identifies one or more of desired starter current, failing starter telematics characteristics, and vehicle component life-cycle data signature; an executable portion configured to compare the telematics data signature and the reference data signature to determine whether the telematics data signature satisfies the threshold vehicle starter failure level; and an executable portion configured to, upon determining that the telematics data signature satisfies the threshold vehicle failure level, generate an output notification to initialize one or more of: a repair procedure for the vehicle starter, ordering of a replacement vehicle starter, and generating a notification to a user that the vehicle should not be utilized until the vehicle starter is repaired. Claims 1-20 are rejected on the ground of nonstatutory double patenting as being unpatentable over claims 1, 8 and 15 of U.S. Patent No. 12,136,302 B2. Although the claims at issue are not identical, they are not patentably distinct from each other as shown in the side by side comparison below. Those claims not cited are rejected for depending from a rejected base claim. Claims of instant Application Claims of U.S. Patent No. 12,136,302 B2. 1. A system comprising: a computer-readable storage medium storing instructions; and at least one processor communicatively coupled with the computer-readable storage medium, wherein the at least one processor is configured to execute the instructions to cause the at least one processor to: collect telematics data from an environmental sensor that generates the telematics data based on an output of a vehicle component, wherein the telematics data (i) comprises telematics data points that are each indicative of the output of the vehicle component as a function of time and (ii) forms a telematics data signature for the vehicle component; identify a reference data signature for a performance metric of the vehicle component, wherein: the performance metric comprises at least one of a performance range, a performance tolerance, or a performance threshold for the vehicle component and identifies at least one of a desired output, a failing telematics characteristic, or a vehicle component life-cycle data signature, and the reference data signature is indicative of how the vehicle component performs as the function of time and identifies a failure level for the vehicle component; compare the telematics data signature and the reference data signature to determine that the telematics data signature satisfies the failure level; and upon determining that the telematics data signature satisfies the failure level, generate an output notification to initialize a repair procedure for the vehicle component. 1. A system comprising: an environmental sensor that generates telematics data based on an electrical output of a vehicle electrical component; and at least one processor communicatively coupled with computer storage media storing executable instructions that, when executed, cause the at least one processor to: collect the telematics data from the environmental sensor, wherein the telematics data comprises telematics data points that are each indicative of the electrical output of the vehicle electrical component; store the telematics data within a data file to form a telematics data signature for the vehicle electrical component; generate an inquiry to identify a predetermined electrical metric, wherein the predetermined electrical metric comprises a threshold value for a moving average electrical output for the vehicle electrical component; retrieve the predetermined electrical metric and a reference data signature for the vehicle electrical component that is indicative of how the vehicle electrical component performs as a function of time, wherein the reference data signature identifies a threshold vehicle electrical failure level for the vehicle electrical component, and the predetermined electrical metric identifies at least one of a desired vehicle electrical component output, a failing vehicle electrical component telematics characteristic, or a vehicle electrical component life-cycle data signature; compare the telematics data signature and the reference data signature to determine that the telematics data signature satisfies the threshold vehicle electrical failure level; and upon determining that the telematics data signature satisfies the threshold vehicle electrical failure level, generate an output notification to initialize a repair procedure for the vehicle electrical component. 9. A method comprising: collecting, by at least one computing entity, telematics data from a vehicle mounted sensor that generates the telematics data based on an output of a vehicle component, wherein the telematics data (i) comprises telematics data points that are each indicative of the output of the vehicle component as a function of time and (ii) forms a telematics data signature for the vehicle component; identifying, by the at least one computing entity, a reference data signature for a performance metric of the vehicle component, wherein: the performance metric comprises at least one of a performance range, a performance tolerance, or a performance threshold for the vehicle component and identifies at least one of a desired output, a failing telematics characteristic, or a vehicle component life-cycle data signature, and the reference data signature is indicative of how the vehicle component performs as the function of time and identifies a failure level for the vehicle component; comparing, by the at least one computing entity, the telematics data signature and the reference data signature to determine that the telematics data signature satisfies the failure level; and upon determining that the telematics data signature satisfies the failure level, generating, by the at least one computing entity, an output notification to initialize a repair procedure for the vehicle component. 8. A system comprising: at least one voltage sensor secured within a vehicle and configured to monitor a voltage output of a vehicle electrical component and generate telematics data based on the voltage output of the vehicle electrical component; and a computing entity in wireless communication with the vehicle, the computing entity configured to: receive the telematics data from the at least one voltage sensor, wherein the telematics data comprises a plurality of telematics data points that are each indicative of the voltage output of the vehicle electrical component; store the telematics data within a data file to form a telematics data signature for the vehicle electrical component; generate an inquiry to identify at least one predetermined performance metric for one or more types of the telematics data, wherein the at least one predetermined performance metric comprises detecting a threshold value for an average voltage output for the vehicle electrical component; retrieve the at least one predetermined performance metric and a reference data signature for the vehicle electrical component that is indicative of how the vehicle electrical component performs as a function of time, wherein the reference data signature identifies a threshold vehicle electrical failure level for the vehicle electrical component, and the at least one predetermined performance metric identifies at least one of a desired battery output, a failing vehicle electrical component telematics characteristic, or a vehicle component life-cycle data signature; compare the telematics data signature and the reference data signature to determine that the telematics data signature satisfies the threshold vehicle electrical failure level; and upon determining that the telematics data signature satisfies the threshold vehicle electrical failure level, generate an output notification to initialize a repair procedure for the vehicle electrical component. 17. A computer-readable medium storing computer-executable instructions that, when executed by at least one computing entity, configure the at least one computing entity to perform operations comprising: collecting data from a sensor that generates the data based on an output of a vehicle component, wherein the data (i) comprises data points that are each indicative of the output of the vehicle component as a function of time and (ii) forms a data signature for the vehicle component; identifying a reference data signature for a performance metric of the vehicle component, wherein: the performance metric comprises at least one of a performance range, a performance tolerance, or a performance threshold for the vehicle component, and the reference data signature is indicative of how the vehicle component performs as the function of time and identifies a failure level for the vehicle component; comparing the data signature and the reference data signature to determine that the data signature satisfies the failure level; and upon determining that the data signature satisfies the failure level, generating an output notification to initialize a repair procedure for the vehicle component. 15. A computer program product comprising at least one non-transitory computer-readable storage medium having computer-readable program code portions stored therein, the computer-readable program code portions comprising: an executable portion configured to receive telematics data generated via at least one sensor secured within a vehicle and configured to monitor an electrical system of the vehicle, the telematics data comprising telematics data points that are indicative of electrical output of a vehicle electrical component; an executable portion configured to store the telematics data within a data file to form a telematics data signature for the vehicle electrical component; an executable portion configured to identify a predetermined electrical metric, wherein the predetermined electrical metric includes a threshold value for a moving average electrical output for the vehicle electrical component; an executable portion configured to retrieve the predetermined electrical metric that includes the threshold value for the moving average electrical output and a reference data signature for the vehicle electrical component that is indicative of how the vehicle electrical component performs as a function of time, wherein the reference data signature identifies a threshold vehicle electrical failure level for the vehicle electrical component, and the predetermined electrical metric identifies at least one of a desired vehicle electrical component output, a failing vehicle electrical component telematics characteristic, or a vehicle electrical component life-cycle data signature; an executable portion configured to compare the telematics data signature and the reference data signature to determine that the telematics data signature satisfies the threshold vehicle electrical failure level; and an executable portion configured to, upon determining that the telematics data signature satisfies the threshold vehicle electrical failure level, generate an output notification to initialize a repair procedure for the vehicle electrical component. Conclusion The prior art made of record and not relied upon is considered pertinent to applicant's disclosure as teaching, inter alia, the state of the art of diagnostic monitoring of vehicles at the time of the invention. For example: US 20090138141 A1 to Nwadiogbu; Emmanuel Obiesie et al. (hereinafter Nwadiogbu) teaches, inter alia a VEHICLE HEALTH MONITORING SYSTEM ARCHITECTURE FOR DIAGNOSTICS AND PROGNOSTICS DISCLOSURE in for example the ABSTRACT, Figures and/or Paragraphs below: “A health monitoring system for a vehicle system includes an operational support system including a plurality of managers and a decision support module. Each manager corresponds to a different sub-system of the vehicle system, and comprises a plurality of reasoners and a fusion block. Each reasoner is configured to obtain data and provide preliminary output regarding a different component of the sub-system based on the data. The fusion block is coupled to the plurality of reasoners, and is configured to receive the preliminary output and generating manager output based on the preliminary output. The decision support module is coupled to the plurality of managers, and is configured to receive the manager output and provide a decision support output based on the manager output. [0011] A subsystem fusion block is coupled to the plurality of reasoners. Algorithms operate on the subsystem and component data. Output from the algorithms are preferably connected to the subsystem fusion block. Each algorithm is designed to determine faults in the subsystem or subsystem component using failure signatures and representations of the subsystem and/or component failure behaviors. Each reasoner preferably contains a plurality of algorithms for providing diagnosis and prognosis of a subsystem, component or component operational behavior within the subsystem. The reasoner also preferably obtains operational reliability, operational life and operational maintenance history of the subsystem and/or component.”. US 20160292846 A1 to Sprock; Christopher et al. teaches, inter alia a System and Method for Determination of Machine State Based on Video and Audio Analytics in for example the ABSTRACT, Figures and/or Paragraphs below: “Systems and methods for analyzing and optimizing worksite operations based on video and or audio data are disclosed. One method includes receiving one or more models relating to a worksite, receiving first sensor data associated with the machine at the worksite, receiving second sensor data associated with an operation of the machine at the worksite, wherein the second sensor data is sourced from a sensor that is different from a sensor sourcing the first sensor data, determining, by the one or more processors, a machine state based at least on the first data and the second data, comparing the determined machine state to a modeled machine state represented by the received one or more models to classify site operations and/or detect an irregularity in site operations or an inefficiency in site operations, and generating a response based at least on the detected irregularity or inefficiency.”. Any inquiry concerning this communication or earlier communications from the examiner should be directed to DANIEL LAWSON GREENE JR whose telephone number is (571)272-6876. The examiner can normally be reached on MON-THUR 7-5:30PM (EST). Examiner interviews are available via telephone 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 on (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 an application may be obtained from the Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from either Private PAIR or Public PAIR. Status information for unpublished applications is available through Private PAIR only. For more information about the PAIR system, see http://pair-direct.uspto.gov. Should you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative or access to the automated information system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000. /DANIEL L GREENE/Primary Examiner, Art Unit 3665 20260123
Read full office action

Prosecution Timeline

Oct 09, 2024
Application Filed
Jan 23, 2026
Non-Final Rejection — §103, §DP (current)

Precedent Cases

Applications granted by this same examiner with similar technology

Patent 12601605
ELECTRONIC HORIZON FOR ADAS FUNCTION
2y 5m to grant Granted Apr 14, 2026
Patent 12595022
BICYCLE CONTROL SYSTEM
2y 5m to grant Granted Apr 07, 2026
Patent 12595004
FRONT SPOILER ARRANGEMENT FOR A MOTOR VEHICLE, IN PARTICULAR FOR A TRUCK
2y 5m to grant Granted Apr 07, 2026
Patent 12589039
VEHICLE
2y 5m to grant Granted Mar 31, 2026
Patent 12583719
ANTI-COLLISION SYSTEM
2y 5m to grant Granted Mar 24, 2026
Study what changed to get past this examiner. Based on 5 most recent grants.

AI Strategy Recommendation

Get an AI-powered prosecution strategy using examiner precedents, rejection analysis, and claim mapping.
Powered by AI — typically takes 5-10 seconds

Prosecution Projections

1-2
Expected OA Rounds
76%
Grant Probability
93%
With Interview (+17.1%)
2y 11m
Median Time to Grant
Low
PTA Risk
Based on 859 resolved cases by this examiner. Grant probability derived from career allow rate.

Sign in with your work email

Enter your email to receive a magic link. No password needed.

Personal email addresses (Gmail, Yahoo, etc.) are not accepted.

Free tier: 3 strategy analyses per month