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 .
Continued Examination Under 37 CFR 1.114
A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Applicant's submission filed on 11/28/2025 has been entered.
Status of Claims
This is a Non-Final Action for Request for Continued Examination (RCE) application Serial No. 17/414,987. Claim(s) 14-21 and 24-30 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 Cella et al. (Pub . No . : US 2019/0025813).
Furthermore, per remarks, the rejections under 35 USC § 112 and 101 has been considered and are persuasive. Therefore, the rejections has been withdrawn.
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 is/are rejected under 35 U.S.C. 103 as being unpatentable over Mattern et al. (US 20170169634 A1). hereinafter, referred to as “Mattern” in view of in view of Cella et al. (Pub . No . : US 2019/0025813), hereinafter, referred to as “Cella”.
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”);
analyzing the stored condition data in a data processing unit (3), computing actual values of the tolerances existing at the motor vehicles (5.1 - 5.6) monitored (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.”; and [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.”) from the stored condition data (see, Figure 832 and 842, “trends”; and Paragraphs [0035]: “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.”; [0049]: “a failure location format (see, e.g., FIG. 7), a parameter trend format (see, e.g., FIG. 8), and a fault code format (see, e.g., FIG. 9). 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.), a location ( e.g., country, state, region, a predefined route, etc.), and/or a recommended action, among other possibilities.”;), and determining generally valid variables of the component or assembly sizing based on the actual values for the vehicle type (5) in particular (see, Paragraph [0035]: “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 [0071]: “As shown in FIG. 9, the fault code interface 900 includes a component fault count section 920, a fault code category section 930, and a notification section 940. The
component fault count section 920 is structured to provide an indication to the quantity of fault codes a specific component across a vehicle fleet 130 or engine systems is experiencing ( e.g., a number of NOx sensors throwing a fault code, etc.). The fault code category section 930 is
structured to provide an indication to a quantity of faults related to a component category (e.g., number of faults related to fueling systems, engines, aftertreatment systems, etc.). The notification section 940 is structured to provide an alert or notification to a user regarding the fault code for a vehicle and/or engine system.”), the data processing unit (3) (“such as processor 152 of FIG. 2.”) 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, Paragraph [0035]: “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.”; and [0039]: “For example, a component of a
vehicle or engine system may operate within a certain range during normal operation of the vehicle or the engine system. 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…
Mattern does not explicitly discloses
…
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, Cella teaches
…
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). (see, Paragraphs [0902]: “a method for data collection in an industrial environment having self-organization functionality, the method according to one disclosed non-limiting embodiment of the present disclosure can include analyzing a plurality of sensor inputs, sampling data received from the sensor inputs, and self-organizing at least one of (i) a storage operation of the data, (ii) a collection operation of sensors that provide the plurality of sensor inputs, and (iii) a selection operation of the plurality of sensor inputs, wherein the selection operation includes identifying a target signal to be sensed, receiving a signal relating to at least one condition of the industrial environment, based on the signal, changing at least one of the sensor inputs analyzed and a frequency of the sampling, receiving data indicative of environmental conditions near a target associated with the target signal, transmitting at least a portion of the received sampling data to another data collector according to a predetermined hierarchy of data collection, receiving feedback via a network connection relating to at least one of a bandwidth and a quality or of the network connection, analyzing the received feedback, and based on the analysis of the received feedback, changing at least one of the sensor inputs analyzed, the frequency of sampling, the data stored, and the data transmitted.”
[0927]: “The example controller 12512 further includes a sensor data storage implementation circuit 12526 that stores at least a portion of the number of sensor data values in response to the data storage profile 12532. An example controller 12512 includes the data storage profile 12532 having a storage location definition 12534 corresponding to at least one of the number of sensor data values 12542, including at least one location such as: a sensor storage location (e.g., data stored for a period of time on the sensor, and/or on a portable device for a user 12518 in proximity to the industrial system 12502 where the portable device is adapted by the system as a sensor), a sensor communication device storage location (e.g., a data controller 12508, MUX device, smart sensor in communication with other sensors, and/or on a portable device for a user 12518 in proximity to the industrial system 12502 or a network of the industrial system 12502 where the portable device is adapted by the system as a communication device to transfer sensor data between components in the system, etc.), a regional network storage location (e.g., on a plant computer 12510 and/or controller 12512), and/or a global network storage location (e.g., on a cloud computing device 12514).”; and [0931]: “ An example sensor data storage profile circuit 12524 further updates the data storage profile 12532 in response to external data 12544 and/or cloud-based data 12538, including data such as: an enhanced data request value (e.g., an operator, model, optimization routine, and/or other process requests enhanced data resolution for one or more parameters); a process success value (e.g., indicating that current storage practice provides for sufficient data availability and/or system performance; and/or that current storage practice may be over-capable, and one or more changes to reduce system utilization may be available); a process failure value (e.g., indicating that current storage practices may not provide for sufficient data availability and/or system performance, which may include additional operations or alerts to an operator to determine whether the data transmission and/or availability contributed to the process failure); a component service value (e.g., an operation to adjust the data storage to ensure higher resolution data is available to improve a learning algorithm predicting future service events, and/or to determine which factors may have contributed to premature service); a component maintenance value (e.g., an operation to adjust the data storage to ensure higher resolution data is available to improve a learning algorithm predicting future maintenance events, and/or to determine which factors may have contributed to premature maintenance)”.
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 to convey improved methods and systems for data collection in industrial environments, as well as for improved methods and systems for using collected data to provide improved monitoring, control, intelligent diagnosis of problems and intelligent optimization of operations. (see, Paragraph []).
As to claim 15, Mattern in view of Cella 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, Mattern in view of Cella 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, Mattern in view of Cella 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, Mattern in view of Cella 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, Mattern in view of Cella 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, Mattern in view of Cella 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, Mattern in view of Cella 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], Mattern in view of Cella 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], Mattern in view of Cella 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], Mattern in view of Cella 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], Mattern in view of Cella 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 17 4,
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”).
Claim(s) 19-20 is/are rejected under 35 U.S.C. 103 as being unpatentable over Mattern in view of Cella, 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, Mattern in view of Cella teaches the method of claim 14. Neither Mattern nor Cella 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 Cella 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, Mattern in view of Cella teaches the method of claim 14. Mattern discloses wherein the data processing unit (3) accesses data regarding the production period, however, Mattern nor Cella 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]).
Conclusion
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, James McPherson can be reached on (313) 446-6543. 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