DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Status of Claims
This is a Final Action for Request for Continued Examination (RCE) application Serial No. 17/414,987. Claim(s) 14-21 and 24-33 have been examined and fully considered.
Claim(s) 1-13 and 22-23 are cancelled.
Claim(s) 14 and 26 are amended.
Claim(s) 14-21 and 24-30 are pending in Instant Application.
Response to Arguments/Rejections
Applicant’s arguments, see Remarks, filed 11/28/2025, with respect/t to the rejection(s) of claim(s) 14 and 26 under 35 USC § 103 have been fully considered and are persuasive. However, upon further consideration, a new ground(s) of rejection is made in view of Aiello et al. (Pub. No.: US 2022/0237960).
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 (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 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 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.
Claim(s) 14-18, 21, 24-30, and 32 is/are rejected under 35 U.S.C. 103 as being unpatentable over Mattern et al. (US 20170169634 A1; previous recorded). hereinafter, referred to as “Mattern” in view of in view of Aiello et al. (Pub. No.: US 2022/0237960), hereinafter, referred to as “Aiello”, and in view of Jhon Jong Yong (KR20200024992A) hereinafter, referred to as “Yong” (Foreign NPL; the citations are based on the provided English Translation).
Regarding [claim 14], Mattern discloses a method for determining tolerances of components or assemblies (see, Abstract), comprising:
at least periodically monitoring the components or assemblies of motor vehicles (5.1 - 5.6) of a same vehicle type by one or more on-board sensors of each of the motor vehicles during a driving operation in order to metrologically gather condition data (10) characteristic for tolerances at the components or assemblies (see, Paragraph [0019]: “As a more particular example, the controller receives a fault code from one of the vehicles in the fleet and/or engines in the engine system. The controller determines a potential root cause for the fault code and/or a recommended course of action to address the potential root cause.”; and [0039]: “A sensor may then read that the component is operating outside of that range when a fault code is thrown. Therefore, the vehicle data 172 or the engine data 174 may indicate that
the vehicle component or engine system component is operating outside of the normal operating conditions may be the reason for the fault code or that other components coupled ( e.g., fluidly coupled, mechanically coupled, electrically coupled, etc.) to the component may be the reason
for the fault code.”; and [0039]-[0040]: “The status circuit 162 is structured to monitor the
vehicle(s) 132 of the vehicle fleet 130 and/or the engine system(s)… For example, the status circuit 162 may keep track of the vehicle(s) 132 and/or engine system(s) that are experiencing a fault code, operating according to standard operating conditions, operating at a derated torque output or speed ( e.g., due to emission issues, to prevent progressive damage, etc.), shutdown (e.g., turned off, not currently running, etc.), experiencing downtime due to a fault code or
other factor, and the like.”);
transmitting the condition data (10) via existing, wireless communication paths to a central computer (1) or a cloud (2) (see, Paragraph [0023]: “The vehicles 132 of the vehicle fleet 130 (or engines of the engine system) may include one or more on-board diagnostic (OBD) tools structured to monitor the vehicles 132 (or engines) (i.e., gather operating characteristics) during operation (e.g., while driving, during power generation, etc.). The OBD tools may gather vehicle data and/or engine data to be transmitted to the fleet management system 150 over the network 110 via the telematics system 134. The telematics system 134 is structured to facilitate the transfer of vehicle data from the vehicles 132 (or engine data from the engine) to the fleet management system 150 over the network 110.”);
storing the condition data (10) within the central computer (1) or the cloud (2) together with a specific identifier for a respective individual vehicle (5.1 - 5.6) of the motor vehicles (see, Paragraph [0028]: “Referring now to FIG. 2, a structure and function of the fleet management system 150 are shown according to an example embodiment. The fleet management system 150 may also be referred to as a controller herein and is shown to include a processing circuit 151 including a processor 152 and a memory 154. The processor 152 may be implemented as a general-purpose processor… Thus, the one or more memory devices 154 may be communicably connected to the processor 152 and provide computer code or instructions to the processor 152 for executing the processes described in regard to the fleet management system 150 herein”);
Mattern does not explicitly discloses
…
analyzing the stored condition data in a data processing unit (3), to compute actual values of the tolerances existing at the motor vehicles (5.1 - 5.6) monitored from the stored condition data, and determine generally valid variables of [[the]] component or assembly sizing of the components or assemblies based on the actual values for the vehicle type (5) in particular, the data processing unit (3) accessing technical setting data related to individual motor vehicles (5.1 - 5.6) of the motor vehicles (5.1 - 5.6) of the vehicle type (5) while determining the generally valid variables of the component or assembly sizing; and transmitting operation settings from the central computer (1) or the cloud (2) to individual vehicles (5.1 - 5.6) via the existing, wireless communication paths in order to implement or change operation settings of the motor vehicles (5.1 - 5.6) based at least in part on the actual values of the tolerances to adjust the respective tolerance existing at the motor vehicles (5.1 - 5.6).
However, Aiello teaches
analyzing the stored condition data in a data processing unit (3), to compute actual values of the tolerances existing at the motor vehicles (5.1 - 5.6) monitored from the stored condition data (see, Paragraph [0032]: [0034]: “the reference data signatures may be compared against the generated telematics data signatures to ascertain whether the monitored vehicle component is operating as expected. Accordingly, the identified performance metrics may identify desirable component operation (e.g., desired vehicle component output), failing component telematics characteristics (e.g., common output characteristics of a failing vehicle component), a vehicle component life-cycle data signature (e.g., identifying characteristics of a reference vehicle component output throughout the vehicle component life-cycle between a moment the component was new to a moment the vehicle component fails), and/or the like. The performance metrics may identify target desirable and/or undesirable operating ranges, tolerances, thresholds”; [0035]: “The central computing entity 110 may retrieve applicable performance metrics for the collected/captured component telematics information/data from a storage device accessible to the central computing entity 110 (e.g., a database). The applicable performance metrics may be selected from a plurality of predetermined performance metrics (e.g., a list stored in the database), or the performance metrics may be selected based on the collected/captured information/data types. For example , upon receipt of the component telematics information/data, the central computing entity 110 may be configured to extract information/data from the component telematics information/data indicative of the type of telematics information/data to be reviewed. For example, the central computing entity 110 may be configured to extract information/data indicative of the units to be associated with the component telematics information/data, the source sensor from which the telematics information/data was received, and/or the like. Such information/data may be stored as metadata associated with the component telematics information/data…”; [0060]: “the information / data collection device 130 may include, be associated with, or be in wired or wireless communication with one or more processors 200 (various exemplary processors are described in greater detail below), one or more location-determining devices or one or more location sensors 120 (e.g., Global Navigation Satellite System (GNSS) sensors), one or more telematics sensors 125, one or more real-time clocks 215, a J-Bus protocol architecture, one or more electronic control modules ( ECM ) 245, one or more communication ports 230 for receiving telematics information/data from various sensors (e.g., via a CAN-bus), one or more communication ports 205 for transmitting/sending information/data”), and
determine generally valid variables of component or assembly sizing of the components or assemblies based on the actual values for the vehicle type (5) in particular, the data processing unit (3) accessing technical setting data related to individual motor vehicles (5.1 - 5.6) of the motor vehicles (5.1 - 5.6) of the vehicle type (5) while determining the generally valid variables of the component or assembly sizing (see, Paragraphs [0027]: “FIG . 1 shows an example component monitoring system implemented for monitoring of components on one or more vehicles. As shown in FIG. 1, a vehicle 100 and/or various onboard computing entities (e.g., information/data collection device 130, telematics sensors 125, location sensors 120 ) are in communication with a central computing a entity 110 and/or a mobile computing entity 105 via one or more wired and/or wireless networks 135.”; [0036]; [0037]: “the applicable performance metrics may comprise performance metrics for two or more monitored telematics characteristics. For example, the performance metrics for a particular electrical vehicle component may comprise both an output voltage and a current draw for the electrical component. The performance metrics specific to each of the two or more monitored telematics characteristics may be determined independently of one another, such that a determination that the vehicle component does not satisfy one of the telematics characteristics is itself indicative of a failing vehicle component. In yet other embodiments, the performance metrics for various monitored telematics characteristics may be interdependent, such that a relevant electrical component is not indicated as failing unless the telematics characteristics do not satisfy each of a plurality of the relevant performance metrics”); and
transmitting operation settings from the central computer (1) or the cloud (2) to individual vehicles (5.1 - 5.6) via the existing, wireless communication paths (see, Paragraph [0057]: “As shown in FIG . 1, the system may include one or more vehicles 100, one or more mobile computing entities 105, one or more mapping computing entities 110 , one or more Global Positioning System (GPS) satellites 115, one or more location sensors 120, one or more telematics sensors 125, one or more information/data collection devices 130, one or more networks 135, one or more user computing entities (not shown), and/or the like. Each of the components of the system may be in electronic communication with, for example, one another over the same or different wireless or wired networks including , for example, a wired or wireless Personal Area Network (PAN), Local Area Network (LAN), Metropolitan Area Network (MAN), Wide Area Network (WAN), or the like. Additionally, while FIG. 1 illustrates certain system entities as separate, standalone entities, the various embodiments are not limited to this particular architecture”; and [0063]: “the ECM 245 may be one of several components in communication with and/or available to the information / data collection device 130. The ECM 245, which may be a scalable and subservient device to the information / data collection device 130, may have information/data processing capability to decode and store analog and digital inputs from vehicle systems and sensors. The ECM 245 may further have information/data processing capability to collect and present telematics information/data to the J-Bus (which may allow transmission to the information/data collection device 130), and output standard vehicle diagnostic codes when received from a vehicle's J-Bus compatible on-board controllers 240 and/or sensors”).
Accordingly, it would have been obvious to one of ordinary skill in the art before the filing of the invention to implement systems and methods enabling prognostic vehicle maintenance processes for various vehicles as taught by Aiello. One would be motivated to make this modification in order to convey a need exists for improved systems and methods for diagnosing and/or detecting impending vehicle component failures without requiring a significant vehicle owner time expenditure in order to enable replacement and/or repair of vehicle components immediately prior to an impending vehicle component failure (see, Paragraph [0003]).
Additionally, Yong teaches
… in order to implement or change operation settings of the motor vehicles (5.1 - 5.6) based at least in part on the actual values of the tolerances to adjust the respective tolerance existing at the motor vehicles (5.1 - 5.6) (see, Paragraphs [0039]: “In addition, when the DTG terminal (200) is installed in the vehicle (200) by the vehicle (200) or the manager of the DTG terminal (200) (e.g., the DTG terminal installer), it collects vehicle operation information according to the operation of the vehicle (200) through a wireless communication interface provided by itself and transmits it in real time to the cloud server platform (100)”); [0038]: “As illustrated in FIG. 1, a cloud server platform (100) (hereinafter referred to as a cloud server platform) for managing vehicle operation through a DTG terminal according to one embodiment of the present invention is implemented in the form of a cloud server to provide various functions for operation, maintenance, and management of DTG terminals (200) mounted on a plurality of vehicles (300)”; [0042]: “the setting information of the DTG terminal (200) is automatically downloaded from the cloud server platform (100) through a communication interface provided by itself, thereby enabling the DTG terminal (200) to be set based on the downloaded setting information”; and [0047]: “the DTG terminal (200) requests the cloud server platform (100) for setting information about the DTG terminal (200) upon initial startup or whenever the vehicle (300) is turned on, and when the setting information already applied to the DTG terminal (200) is changed or updated, the cloud server platform (100) transmits the changed or updated setting information about the DTG terminal (200) to the DTG terminal (200)” and [0048]: “In addition, the DTG terminal (200) receives the changed or updated setting information from the cloud server platform (100) and applies it to the corresponding DTG terminal (200), thereby maintaining the newly changed or updated setting information”).
Accordingly, it would have been obvious to one of ordinary skill in the art before the filing of the invention to further modify Mattern by combining transmitting operation settings from the central computer (1) or the cloud (2) to individual vehicles (5.1 - 5.6) via the existing, wireless communication paths in order to implement or change operation settings at the motor vehicles (5.1 - 5.6) as taught by Yong. One would be motivated to make this modification in order so that the vehicle operation information in real time according to the operation of the vehicle driver, enables objective analysis of the recorded vehicle operation information, and helps in driving the vehicle (see Paragraph [0004]).
As to claim 15, the combination of Mattern, Aiello, and Yong teaches the method of claim 14. Mattern discloses wherein the data processing unit (3) accesses production data related to the vehicle type (5) while determining the generally valid variables of the component or assembly sizing (see, Paragraph [0035]: “As shown in FIG. 2, the analysis circuitry 158 includes a modification circuit 159, a fault circuit 160, a trend circuit 161, a status circuit 162, and a recommendation circuit 163. The modification circuit 159 is structured to modify at least one of the vehicle data 172, the engine data 174, and the technician data 170 received for each of the one or more vehicles 132 with a unique modifier. In one embodiment, the unique modifiers are predefined within the memory 154 of the fleet management system 150. In an alternative embodiment, the unique modifiers may be defined by the user of the data visualization system 100 using the input device 142. The unique modifier may be based on the type of vehicle (e.g., truck, sedan, coupe, etc.), type of engine (e.g., 10 cylinder, 8 cylinder, 6 cylinder, 4 cylinder, etc.), and/or any other type of component of the vehicles 132 and/or engine system” and [0036]: “The "decorated" vehicle data 172, engine data 17 4, and technician data 170 may provide the other circuits of the analysis circuitry 158 with data that includes unique knowledge of the vehicles 132, the components of the vehicles 132, the engine system(s), and/or the components of the engine system(s) that allows for a more detailed analysis of the operation of the vehicles 132 and/or engine systems. For example, decorating (e.g., enriching, enhancing, etc.) the data may include incorporating details such as vehicle make, vehicle model, engine size, engine model, engine date of manufacture, and the like. The raw vehicle data 172 or the raw engine data 174 may include a fault code that one of the vehicles 132 or engine systems, respectively, is experiencing. The modification circuit 159 may interpret the fault code (e.g., using a look-up table, etc.) to determine what components of the vehicle 132 or the engine system may be affected by or cause the fault code.”).
As to claim 16, the combination of Mattern, Aiello, and Yong teaches the method of claim 14. Mattern further discloses wherein the data processing unit (3) accesses technical data of supplied components or assemblies related to the vehicle type (5) while determining the generally valid variables of the component or assembly sizing (see, Paragraph [0035]: “As shown in FIG. 2, the analysis circuitry 158 includes a modification circuit 159, a fault circuit 160, a trend circuit 161, a status circuit 162, and a recommendation circuit 163. The modification circuit 159 is structured to modify at least one of the vehicle data 172, the engine data 174, and the technician data 170 received for each of the one or more vehicles 132 with a unique modifier. In one embodiment, the unique modifiers are predefined within the memory 154 of the fleet management system 150. In an alternative embodiment, the unique modifiers may be defined by the user of the data visualization system 100 using the input device 142. The unique modifier may be based on the type of vehicle (e.g., truck, sedan, coupe, etc.), type of engine (e.g., 10 cylinder, 8 cylinder, 6 cylinder, 4 cylinder, etc.), and/or any other type of component of the vehicles 132 and/or engine system” and [0036]: “The "decorated" vehicle data 172, engine data 17 4, and technician data 170 may provide the other circuits of the analysis circuitry 158 with data that includes unique knowledge of the vehicles 132, the components of the vehicles 132, the
engine system(s), and/or the components of the engine system(s) that allows for a more detailed analysis of the operation of the vehicles 132 and/or engine systems. For example, decorating (e.g., enriching, enhancing, etc.) the data may include incorporating details such as vehicle make, vehicle model, engine size, engine model, engine date of manufacture, and the like. The raw vehicle data 172 or the raw engine data 174 may include a fault code that one of the
vehicles 132 or engine systems, respectively, is experiencing. The modification circuit 159 may interpret the fault code (e.g., using a look-up table, etc.) to determine what components of the vehicle 132 or the engine system may be affected by or cause the fault code.”).
As to claim 17, the combination of Mattern, Aiello, and Yong teaches the method of claim 14. Mattern further discloses wherein the data processing unit (3) accesses technical setting data related to the vehicle type (5) while determining the generally valid variables of the component or assembly sizing (see, Paragraph [0035]: “As shown in FIG. 2, the analysis circuitry 158 includes a modification circuit 159, a fault circuit 160, a trend circuit 161, a status circuit 162, and a recommendation circuit 163. The modification circuit 159 is structured to modify at least one of the vehicle data 172, the engine data 174, and the technician data 170 received for each of the one or more vehicles 132 with a unique modifier. In one embodiment, the unique modifiers are predefined within the memory 154 of the fleet management system 150. In an alternative embodiment, the unique modifiers may be defined by the user of the data visualization system 100 using the input device 142. The unique modifier may be based on the type of vehicle (e.g., truck, sedan, coupe, etc.), type of engine (e.g., 10 cylinder, 8 cylinder, 6 cylinder, 4 cylinder, etc.), and/or any other type of component of the vehicles 132 and/or engine system” and [0036]: “The "decorated" vehicle data 172, engine data 17 4, and technician data 170 may provide the other circuits of the analysis circuitry 158 with data that includes unique knowledge of the vehicles 132, the components of the vehicles 132, the engine system(s), and/or the components of the engine system(s) that allows for a more detailed analysis of the operation of the vehicles 132 and/or engine systems. For example, decorating (e.g., enriching, enhancing, etc.) the data may include incorporating details such as vehicle make, vehicle model, engine size, engine model, engine date of manufacture, and the like. The raw vehicle data 172 or the raw engine data 174 may include a fault code that one of the vehicles 132 or engine systems, respectively, is experiencing. The modification circuit 159 may interpret the fault code (e.g., using a look-up table, etc.) to determine what components of the vehicle 132 or the engine system may be affected by or cause the fault code.”).
As to claim 18, the combination of Mattern, Aiello, and Yong teaches the method of claim 14. Mattern discloses wherein the data processing unit (3) accesses workshop and service data related to the vehicle type (5) while determining the generally valid variables of the component or assembly sizing (see, Paragraph [0035]: “As shown in FIG. 2, the analysis circuitry 158 includes a modification circuit 159, a fault circuit 160, a trend circuit 161, a status circuit 162, and a recommendation circuit 163. The modification circuit 159 is structured to modify at least one of the vehicle data 172, the engine data 174, and the technician data 170 received for each of the one or more vehicles 132 with a unique modifier. In one embodiment, the unique modifiers are predefined within the memory 154 of the fleet management system 150. In an alternative embodiment, the unique modifiers may be defined by the user of the data visualization system 100 using the input device 142. The unique modifier may be based on the type of vehicle (e.g., truck, sedan, coupe, etc.), type of engine (e.g., 10 cylinder, 8 cylinder, 6 cylinder, 4 cylinder, etc.), and/or any other type of component of the vehicles 132 and/or engine system” and [0036]: “The "decorated" vehicle data 172, engine data 17 4, and technician data 170 may provide the other circuits of the analysis circuitry 158 with data that includes unique knowledge of the vehicles 132, the components of the vehicles 132, the engine system(s), and/or the components of the engine system(s) that allows for a more detailed analysis of the operation of the vehicles 132 and/or engine systems. For example, decorating (e.g., enriching, enhancing, etc.) the data may include incorporating details such as vehicle make, vehicle model, engine size, engine model, engine date of manufacture, and the like. The raw vehicle data 172 or the raw engine data 174 may include a fault code that one of the vehicles 132 or engine systems, respectively, is experiencing. The modification circuit 159 may interpret the fault code (e.g., using a look-up table, etc.) to determine what components of the vehicle 132 or the engine system may be affected by or cause the fault code.”; [0039]: “The comparison between vehicle data 172, the engine data 174, and/or the technician data 170 may facilitate determining a root cause or potential root cause for a fault code of one or more of the vehicles 132 and/or engine systems. For example, a first vehicle that was experiencing a particular fault code may be serviced ( e.g., at a vehicle servicing location 120, etc.) where diagnostics testing was run to determine a root cause of the fault code. A second vehicle may experience the same or a similar fault code. By
comparing the technician data 170 and/or the vehicle data 172 of the first vehicle ( or the engine data 17 4 of a first engine system) to the vehicle data 172 of the second vehicle ( or the engine data 17 4 of a second engine system), the trend circuit 161 may be able to facilitate determining whether the fault code of the second vehicle ( or the second engine system) may be caused by the same root cause as the first vehicle (or first engine system). In another example, a vehicle may experience a particular fault code while driving in a certain geographic location ( e.g., desert, mountains, etc.), experiencing certain vehicle operating conditions ( e.g., engine speed, transmission gear, engine temperature, etc.”).
As to claim 21, the combination of Mattern, Aiello, and Yong teaches the method of claim 14. Mattern discloses further wherein the data processing unit (3) accesses data regarding the running period or the operating hours related to individual motor vehicles (5.1 - 5.6) of the vehicle type (5) while determining the generally valid variables of the component or assembly sizing (see, Paragraphs [0040]: “For example, the status circuit 162 may keep track of the vehicle(s) 132 and/or engine system(s) that are experiencing a fault code, operating according to standard operating conditions, operating at a derated torque output or speed (e.g., due to emission issues, to prevent progressive damage, etc.), shutdown (e.g., turned off, not currently running, etc.), experiencing downtime due to a fault code or other factor, and the like. The status circuit 162 may also monitor the geographic location at which a fault code initially occurred.”; and [0049]: “The configurable options may include the aforementioned graphical formats and various filtering options to filter data displayed in the respective graphical formats. For example, the filtering options may include, but are not limited to, an account of the user (i.e., the respective vehicle fleet 130), an identification number (e.g., a model number, a serial number, a VIN number, etc.), a fault code (e.g., an individual fault code, a fault code category, a fault code priority, etc.), a status (e.g., healthy/normal, derated, shutdown, etc.), a performance parameter selection (e.g., oil pressure, oil temperature, etc.), a time (e.g., date range, time range, etc.),”).
As to claim 24, the combination of Mattern Aiello, and Yong teaches the method of claim 14. Mattern discloses further wherein a release function is accessed prior to implementing or changing the operation settings, a vehicle user having access to the release function (see, Paragraph [0022]: “a user of the data visualization system 100 may own or operate engine systems (e.g. power generation systems, etc.) in addition to or alternatively to a vehicle fleet 130. In this case, the data visualization system 100 may be tailored for an engine system, rather than a vehicle system, or both. The data visualization system 100 may be structured to segregate data by customer or user (e.g., Customer A may only see data associated with Customer A's fleet and/or engine systems, etc.). The data visualization system 100 may be structured to also segregate data of an individual customer based on access permissions ( e.g., a regional manager only has access to data regarding vehicles and/or engine system in his/her region, etc.). The data visualization system 100 may also be structured to allow administrative rights to a user (e.g., a "super-user", etc.) such that the user is able to see all the data for all vehicle fleets 130 and/or engine systems.”).
As to claim 25, the combination of Mattern Aiello, and Yong teaches the method of claim 24. Mattern further discloses wherein the vehicle user has access to the release function via an app (see at least Paragraph [0058]: “Referring now to FIGS. 4-9, the various graphical formats of the GUI provided by the data visualization system 100 are shown according the method of claim 24to one embodiment. The data visualization system 100 may be accessed by a user on a website ( e.g., an URL, etc.), an application ( e.g., a portable device application such as a smart phone or tablet application, etc.), or any other platform that facilitates remote access to the data visualization system 100 (i.e., via the network 110). The data visualization system 100 is structured to provide a user with a login interface 400 when a user accesses the data visualization system 100.”).
Regarding claim 26, recites analogous limitations that are present in claim 14, therefore claim 26 would be rejected for the same/similar reasons above.
As to [claim 27], the combination of Mattern Aiello, and Yong teaches the method of claim 14. Mattern discloses wherein the components or assemblies of the motor vehicles are part of vehicle drive trains of the motor vehicles (see, Paragraph [0062]: “The geographic status interface 600 may also facilitate providing suggested vehicle servicing locations 120 on the map 610 for vehicles 132 that may need servicing or testing. For example, the data visualization system 100 may overlay various vehicle servicing locations 120 onto the map 610 that are near a vehicle that can provide the recommended service (e.g., have a part needed to fix the vehicle, within a certain distance, etc.). In some embodiments, the geographic status interface 600 provides a "failure resolved" indicator on the map 610. The failure resolved indicator may be linked to a particular indicator 612 showing that the component failure has been remedied. The failure resolved indicator may also provide an indication to a location at which the component failure was addressed and/or fixed (e.g., a vehicle servicing location 120, a location with different external conditions such as altitude, grade, or temperature that may have caused the fault code to clear independently, etc.).”; and [0066]: “The failure location interface 700 may also facilitate providing suggested vehicle servicing locations 120 on the map 710 for vehicles 132 based on the component failure. For example, the data visualization system 100 may overlay various vehicle servicing locations 120 onto the map 710 that are near a vehicle that can provide the recommended service (e.g., have a part needed to fix the component, within a certain distance, etc.). The failure location interface 700 may also facilitate providing suggested technician companies on the map 710 to contact for on-site service and/or diagnostics based on the component failure”).
As to [claim 28], the combination of Mattern, Aiello, and Yong teaches the method of claim 27. Mattern discloses wherein the components or assemblies are part of transmissions or clutches of the vehicle drive trains of the motor vehicles (see, Paragraph [0039]: “The comparison between vehicle data 172, the engine data 174, and/or the technician data 170 may facilitate determining a root cause or potential root cause for a fault code of one or more of the vehicles 132 and/or engine systems. For example, a first vehicle that was experiencing a particular fault code may be serviced (e.g., at a vehicle servicing location 120, etc.) where diagnostics testing was run to determine a root cause of the fault code. A second vehicle may experience the same or a similar fault code. By comparing the technician data 170 and/or the vehicle data 172 of the first vehicle ( or the engine data 17 4 of a first engine system) to the vehicle data 172 of the second vehicle ( or the engine data 17 4 of a second engine system), the trend circuit 161 may be able to facilitate determining whether the fault code of the second vehicle ( or the second engine system) may be caused by the same root cause as the first vehicle (or first engine system). In another example, a vehicle may experience a particular fault code while driving in a certain geographic location ( e.g., desert, mountains, etc.), experiencing certain vehicle operating conditions ( e.g., engine speed, transmission gear, engine temperature, etc.), and/or encountering certain external conditions (e.g., temperature, altitude, weather, road grade, etc.).”).
As to [claim 29], the combination of Mattern Aiello, and Yong teaches the method of claim 14. Yong teaches wherein transmitting the operation settings from the central computer (1) or the cloud (2) to the individual vehicles (5.1 - 5.6) via the existing, wireless communication paths implements or changes the operation settings of the motor vehicles (5.1 - 5.6) to adjust the respective tolerance of the components or assemblies existing at the motor vehicles (5.1 - 5.6) (see, Paragraphs [0039]: “In addition, when the DTG terminal (200) is installed in the vehicle (200) by the vehicle (200) or the manager of the DTG terminal (200) (e.g., the DTG terminal installer), it collects vehicle operation information according to the operation of the vehicle (200) through a wireless communication interface provided by itself and transmits it in real time to the cloud server platform (100)”); [0038]: “As illustrated in FIG. 1, a cloud server platform (100) (hereinafter referred to as a cloud server platform) for managing vehicle operation through a DTG terminal according to one embodiment of the present invention is implemented in the form of a cloud server to provide various functions for operation, maintenance, and management of DTG terminals (200) mounted on a plurality of vehicles (300)”; [0042]: “the setting information of the DTG terminal (200) is automatically downloaded from the cloud server platform (100) through a communication interface provided by itself, thereby enabling the DTG terminal (200) to be set based on the downloaded setting information”; and [0047]: “the DTG terminal (200) requests the cloud server platform (100) for setting information about the DTG terminal (200) upon initial startup or whenever the vehicle (300) is turned on, and when the setting information already applied to the DTG terminal (200) is changed or updated, the cloud server platform (100) transmits the changed or updated setting information about the DTG terminal (200) to the DTG terminal (200)” and [0048]: “In addition, the DTG terminal (200) receives the changed or updated setting information from the cloud server platform (100) and applies it to the corresponding DTG terminal (200), thereby maintaining the newly changed or updated setting information”).
Accordingly, it would have been obvious to one of ordinary skill in the art before the filing of the invention to further modify Mattern by combining transmitting operation settings from the central computer (1) or the cloud (2) to individual vehicles (5.1 - 5.6) via the existing, wireless communication paths in order to implement or change operation settings at the motor vehicles (5.1 - 5.6) as taught by Yong. One would be motivated to make this modification in order so that the vehicle operation information in real time according to the operation of the vehicle driver, enables objective analysis of the recorded vehicle operation information, and helps in driving the vehicle (see Paragraph [0004]).
As to [claim 30], the combination of Mattern, Aiello, and Yong teaches the method of claim 14. Mattern discloses wherein the generally valid variables of the component or assembly sizing defines a range of tolerances for the component or assembly sizing that is different from previously utilized tolerances established for the component or assembly sizing (see, Paragraph [0037]: “The trend circuit 161 is structured to analyze how different parameters (e.g., vehicle operating characteristics, engine operating characteristics, external characteristics, etc.) factor into the vehicle data 172 and the various fault codes of the one or more vehicles 132 and/or the engine data 17 4 and the various fault codes of the one or more engine systems. In one embodiment, the trend circuit 161 is structured to compare the vehicle data 172, the engine data 174, and/or technician data 170 between the one or more of the vehicles 132 and/or engine systems. For example, the trend circuit 161 may compare the technician data 170 and/or the
vehicle data 172 of a first vehicle 132, an individual component of the first vehicle 132, a plurality of components of the first vehicle 132, a first population of vehicles 132, or a
first vehicle fleet 130 to the technician data 170 and/or the vehicle data 172 of a second vehicle 132, an individual component of the second vehicle 132, a plurality of components of the second vehicle 132, a second population of vehicles 132, or a second vehicle fleet 130, or any combination thereof”).
As to claim 32, the combination of Mattern, Aiello, and Yong teaches the method of claim 14.
Aiello teaches wherein transmitting the operation settings from the central computer (1) or the cloud (2) to the individual vehicles (5.1 - 5.6) comprises transmitting the operation settings from the central computer (1) or the cloud (2) to the individual vehicles (5.1 - 5.6) (see, Paragraph [0057]: “As shown in FIG . 1, the system may include one or more vehicles 100, one or more mobile computing entities 105, one or more mapping computing entities 110 , one or more Global Positioning System (GPS) satellites 115, one or more location sensors 120, one or more telematics sensors 125, one or more information/data collection devices 130, one or more networks 135, one or more user computing entities (not shown), and/or the like. Each of the components of the system may be in electronic communication with, for example, one another over the same or different wireless or wired networks including , for example, a wired or wireless Personal Area Network (PAN), Local Area Network (LAN), Metropolitan Area Network (MAN), Wide Area Network (WAN), or the like. Additionally, while FIG. 1 illustrates certain system entities as separate, standalone entities, the various embodiments are not limited to this particular architecture”; and [0063]: “the ECM 245 may be one of several components in communication with and/or available to the information / data collection device 130. The ECM 245, which may be a scalable and subservient device to the information / data collection device 130, may have information/data processing capability to decode and store analog and digital inputs from vehicle systems and sensors. The ECM 245 may further have information/data processing capability to collect and present telematics information/data to the J-Bus (which may allow transmission to the information/data collection device 130), and output standard vehicle diagnostic codes when received from a vehicle's J-Bus compatible on-board controllers 240 and/or sensors”) in order to implement or change the operation settings of the motor vehicles (5.1 - 5.6) based at least in part on the generally valid variables of the component or assembly sizing to adjust the respective tolerance existing at the motor vehicles (5.1 - 5.6) (see, Paragraph [0032]: [0034]: “the reference data signatures may be compared against the generated telematics data signatures to ascertain whether the monitored vehicle component is operating as expected. Accordingly, the identified performance metrics may identify desirable component operation (e.g., desired vehicle component output), failing component telematics characteristics (e.g., common output characteristics of a failing vehicle component), a vehicle component life-cycle data signature (e.g., identifying characteristics of a reference vehicle component output throughout the vehicle component life-cycle between a moment the component was new to a moment the vehicle component fails), and/or the like. The performance metrics may identify target desirable and/or undesirable operating ranges, tolerances, thresholds”; [0035]: “The central computing entity 110 may retrieve applicable performance metrics for the collected/captured component telematics information/data from a storage device accessible to the central computing entity 110 (e.g., a database). The applicable performance metrics may be selected from a plurality of predetermined performance metrics (e.g., a list stored in the database), or the performance metrics may be selected based on the collected/captured information/data types. For example , upon receipt of the component telematics information/data, the central computing entity 110 may be configured to extract information/data from the component telematics information/data indicative of the type of telematics information/data to be reviewed. For example, the central computing entity 110 may be configured to extract information/data indicative of the units to be associated with the component telematics information/data, the source sensor from which the telematics information/data was received, and/or the like. Such information/data may be stored as metadata associated with the component telematics information/data…”; [0060]: “the information / data collection device 130 may include, be associated with, or be in wired or wireless communication with one or more processors 200 (various exemplary processors are described in greater detail below), one or more location-determining devices or one or more location sensors 120 (e.g., Global Navigation Satellite System (GNSS) sensors), one or more telematics sensors 125, one or more real-time clocks 215, a J-Bus protocol architecture, one or more electronic control modules ( ECM ) 245, one or more communication ports 230 for receiving telematics information/data from various sensors (e.g., via a CAN-bus), one or more communication ports 205 for transmitting/sending information/data”).
Accordingly, it would have been obvious to one of ordinary skill in the art before the filing of the invention to implement systems and methods enabling prognostic vehicle maintenance processes for various vehicles as taught by Aiello. One would be motivated to make this modification in order to convey a need exists for improved systems and methods for diagnosing and/or detecting impending vehicle component failures without requiring a significant vehicle owner time expenditure in order to enable replacement and/or repair of vehicle components immediately prior to an impending vehicle component failure (see, Paragraph [0003]).
Claim(s) 19-20 is/are rejected under 35 U.S.C. 103 as being unpatentable over Mattern, Aiello and Yong, and in view of Martin Schussler (WO2018177526A1; previously recorded) hereinafter, referred to as “Schussler” (Foreign NPL; the citations are based on the provided English Translation).
As to claim 19, the combination of Mattern, Aiello, and Yong teaches the method of claim 14. Neither Mattern nor Aiello explicitly teaches wherein the data processing unit (3) accesses test stand data related to the vehicle type (5) and data from type-specific test series while determining the generally valid variables of the component or assembly sizing.
However, in the same field of endeavor, Schussler teaches
wherein the data processing unit (3) accesses test stand data (see at least Paragraph [0031]: “a test run of a real or virtual technical device with a specific configuration and a specific operating behavior over a specified time. 251 The test is preferably carried out using an operating behavior simulation. 252 A component in the sense of the invention is a component or an assembly of a vehicle”) related to the vehicle type (5) (see, Paragraph [0035]: “A configuration in the sense of the invention corresponds to a point in a test space, which is defined by those properties that determine the robustness of the vehicle type”) and data from type-specific test series (see, Paragraph [0127]: “Starting with three engines, the test procedure evaluates the test statistics based on the legally regulated pollutants. Depending on the result of the test statistics, the product conformity test is passed, failed or an additional motor is removed from the production series”) while determining the generally valid variables of the component or assembly sizing (see, Paragraph [0040]: “the robustness analysis can be carried out using the method according to the invention when a vehicle model for a vehicle type is available. Furthermore, the invention enables a cause analysis with regard to the robustness of the vehicle type”).
Accordingly, it would have been obvious to one of ordinary skill in the art before the filing of the invention to further modify Mattern in view of Aiello by combining wherein the data processing unit (3) accesses test stand data related to the vehicle type (5) and data from type-specific test series while determining the generally valid variables of the component or assembly sizing as taught by Schussler. One would be motivated to make this modification in order to match the theoretical distribution properties, in particular the theoretical quantiles, with sufficient accuracy (see at least Paragraph [0012]).
As to claim 20, the combination of Mattern, Aiello, and Yong teaches the method of claim 14. Mattern discloses wherein the data processing unit (3) accesses data regarding the production period, however, Mattern nor Aiello explicitly teach the production lot related to individual motor vehicles (5.1 - 5.6) of the vehicle type (5) while determining the generally valid variables of the component or assembly sizing.
However, in the same field of endeavor, Schussler teaches
wherein the data processing unit (3) accesses data regarding … the production lot related to individual motor vehicles (5.1 - 5.6) of the vehicle type (5) while determining the generally valid variables of the component or assembly sizing (see, Paragraph [0154]: “a configuration is determined, for example, by the properties of the components of the respective vehicle, in particular their specific production and/or measurement tolerances, a use of the components of the vehicle or the vehicle itself, in particular in the form of a specific characteristic driving cycle, certain environmental conditions under which the vehicle was operated, as well as a certain aging structure of the components of the vehicle or the vehicle itself.”).
Accordingly, it would have been obvious to one of ordinary skill in the art before the filing of the invention to further modify Mattern in view of Yong by combining wherein the data processing unit (3) accesses data regarding … the production lot related to individual motor vehicles (5.1 - 5.6) of the vehicle type (5) while determining the generally valid variables of the component or assembly sizing as taught by Schussler. One would be motivated to make this modification in order to match the theoretical distribution properties, in particular the theoretical quantiles, with sufficient accuracy (see at least Paragraph [0012]).
Claim(s) 31 and 33 is/are rejected under 35 U.S.C. 103 as being unpatentable over Mattern, Aiello, and Yong, and Cella et al. (Pub. No. : US 2019/0025813), hereinafter, referred to as “Cella”.
As to [claim 31], the combination of Mattern, Aiello, and Yong teaches the method of claim 14. As Mattern in view of Aiello teaches further comprising: transmitting the operation settings from the central computer (1) or the cloud (2) to a first individual vehicle of the individual vehicles (5.1 - 5.6) for the first individual vehicle to implement the operation settings; and observing changes in the condition data for the first individual vehicle (5.1 - 5.6) after the operation settings are implemented by the first individual vehicle (see, Paragraph [0032]: [0034]: “the reference data signatures may be compared against the generated telematics data signatures to ascertain whether the monitored vehicle component is operating as expected. Accordingly, the identified performance metrics may identify desirable component operation (e.g., desired vehicle component output), failing component telematics characteristics (e.g., common output characteristics of a failing vehicle component), a vehicle component life-cycle data signature (e.g., identifying characteristics of a reference vehicle component output throughout the vehicle component life-cycle between a moment the component was new to a moment the vehicle component fails), and/or the like. The performance metrics may identify target desirable and/or undesirable operating ranges, tolerances, thresholds”; [0035]: “The central computing entity 110 may retrieve applicable performance metrics for the collected/captured component telematics information/data from a storage device accessible to the central computing entity 110 (e.g., a database). The applicable performance metrics may be selected from a plurality of predetermined performance metrics (e.g., a list stored in the database), or the performance metrics may be selected based on the collected/captured information/data types. For example , upon receipt of the component telematics information/data, the central computing entity 110 may be configured to extract information/data from the component telematics information/data indicative of the type of telematics information/data to be reviewed. For example, the central computing entity 110 may be configured to extract information/data indicative of the units to be associated with the component telematics information/data, the source sensor from which the telematics information/data was received, and/or the like. Such information/data may be stored as metadata associated with the component telematics information/data…”; [0060]: “the information / data collection device 130 may include, be associated with, or be in wired or wireless communication with one or more processors 200 (various exemplary processors are described in greater detail below), one or more location-determining devices or one or more location sensors 120 (e.g., Global Navigation Satellite System (GNSS) sensors), one or more telematics sensors 125, one or more real-time clocks 215, a J-Bus protocol architecture, one or more electronic control modules ( ECM ) 245, one or more communication ports 230 for receiving telematics information/data from various sensors (e.g., via a CAN-bus), one or more communication ports 205 for transmitting/sending information/data”) …, however, neither references teaches …wherein transmitting the operation settings from the central computer (1) or the cloud (2) to the individual vehicles (5.1 - 5.6) comprises transmitting the operation settings from the central computer (1) or the cloud (2) to other vehicles of the individual vehicles (5.1 - 5.6) when the changes in the condition data for the first individual vehicle result in a positive verification of the condition data for the first individual vehicle being within an optimum quality range.
However, Cella teaches
…wherein transmitting the operation settings from the central computer (1) or the cloud (2) to the individual vehicles (5.1 - 5.6) comprises transmitting the operation settings from the central computer (1) or the cloud (2) to other vehicles of the individual vehicles (5.1 - 5.6) when the changes in the condition data for the first individual vehicle result in a positive verification of the condition data for the first individual vehicle being within an optimum quality range (see, Paragraphs [0127]: “a local data collection system 102, which may be disposed in an environment 104, such as an industrial environment similar to that shown in FIG. 3, for collecting data from or about the elements of the environment, such as machines, components, systems, sub-systems, ambient conditions, states, workflows, processes, and other elements. The platform 100 may connect to or include portions of the industrial IoT data collection, monitoring and control system 10 depicted in FIGS. 1-5. The platform 100 may include a network data transport system 108, such as for transporting data to and from the local data collection system 102 over a network 110, such as to a host processing system 112, such as one that is disposed in a cloud computing environment or on the premises of an enterprise, or that consists of distributed components that interact with each other to process data collected by the local data collection system 102”; [0223]: “the platform 100 may include the local data collection system 102 deployed in the environment 104 to monitor signals from machines, elements of the machines and the environment of the machines including heavy duty machines deployed at a local job site or at distributed job sites under common control. The heavy-duty machines may include earthmoving equipment, heavy duty on-road industrial vehicles, heavy duty off-road industrial vehicles, industrial machines deployed in various settings such as turbines, turbomachinery, generators, pumps, pulley systems, manifold and valve systems”; and [0271]: “a smart band method for data collection in an industrial environment may include periodic collection of data from one or more sensors configured to sense a condition of an industrial machine in the environment. The collected data may be checked against a set of criteria that define an acceptable range of the condition. Upon validation that the collected data is either approaching one end of the acceptable limit or is beyond the acceptable range of the condition, data collection may commence from a smart-band group of sensors associated with the sensed condition based on a smart-band collection protocol configured as a data collection template”).
Accordingly, it would have been obvious to one of ordinary skill in the art before the filing of the invention to implement methods and systems for leveraging collected data for monitoring, remote control, autonomous action as taught by Cella. One would be motivated to make this modification in order to convey data have historically been returned to a central office for analysis, such as undertaking signal processing or other analysis on the data collected by various sensors, after which analysis can be used as a basis for diagnosing problems in an environment and/or suggesting ways to improve operations (see, Paragraph [0009]).
As to [claim 33], recites analogous limitations that are present in claim 31, therefore claim 33 would be rejected for the same/similar reasons above.
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 BAKARI UNDERWOOD whose telephone number is (571)272-8462. The examiner can normally be reached M - F 8:00 TO 4:30.
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, Abby Flynn can be reached (571) 272-9855. 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.
/B.U./Examiner, Art Unit 3663
/JAMES M MCPHERSON/Examiner, Art Unit 3663
Prosecution Insights