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 Office Action is responsive to communication filed on 4/10/2026.
Claims 1, 3-4, 8 and 17 are amended.
Claims 1-20 are presented for examination.
Response to Arguments/Remarks
Regarding rejections under 35 U.S.C. §103
Applicant Argues
The Miklosovic-Lakomiak combination does not teach claim 1 as amended. Independent claims 8 and 17 includes similar limitations as claim 1 and are therefore allowable for the same reasons presented above.
Examiner Responds
The examiner has fully considered applicant’s amendments and arguments but respectfully disagrees that the Miklosovic-Lakomiak combination do not teach the claims as amended, as under the broadest reasonable interpretation Miklosovic’s industrial device analytic engine used for device condition monitoring in combination with Lakomiak’s industrial condition monitoring user interface that allows a user to select an industrial device, condition type, and to view corresponding condition information via a dashboard, still renders the amended claim obvious to one of ordinary skill in the art. Accordingly, Applicant’s arguments are not persuasive and the rejection under 35 U.S.C. 103 over Miklosovic in view of Lakomiak is maintained (or over Lakomiak in view of Miklosovic, regarding claim 17).
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 1-2, 5-11 and 14-16 are rejected under 35 U.S.C. 103 as being unpatentable over MIKLOSOVIC (US20210341896A1) in view of LAKOMIAK (US20100082158A1) (hereinafter – “MIKLOSOVIC-LAKOMIAK”).
Regarding claim 1
MIKLOSOVIC teaches a system comprising:
one or more computer-readable storage media (Fig. 10, [0009], [0071]: storage system 1003);
one or more processors coupled to the one or more computer-readable storage media (Fig. 10, [0009], [0072]: processing system 1002); and
program instructions stored on the one or more computer-readable storage media that, based on being read and executed by the one or more processors, direct the system to (Fig. 10, [0009], [0071]: software 1005);
obtain a plurality of performance metrics, each performance metric associated with a device in an industrial automation environment ([0030]: condition monitoring includes data acquisition; [0032]: “Variable frequency drive 110 supplies power to motors 124 of industrial operation 120 and receives signal data from industrial operation 120. Analytic engine 111 runs fault detection process 112 to detect faults within industrial operation 120 based on the signal data. Analytic engine 111 is a configurable analytics processor that provides flexibility for condition monitoring and includes an application layer that hides complexity and simplifies the user experience for individual applications and fault detection. Analytic engine may be configured to monitor various applications and detect degradation or other faults of a motor and a connected mechanical load from industrial operation 120”; [0034]: “analytic engine 111 may collect data from devices of industrial operation […] system analytics 131 may aggregate and contextualize information”);
contextualize each of the performance metrics based on contextualization information specific to each of the performance metrics to produce device health metrics, each device health metric corresponding to a performance metric of the performance metrics ([0030]: condition monitoring includes feature extraction; [0034]: “system analytics 131 may aggregate and contextualize information”; [0035]: “Environment 200 includes drive 210 representative of a variable frequency comprising an analytics engine such as drive 110 […] Metrics module 213 processes the data to generate metrics data that can be utilized for fault detection. The data collected by select and capture module 212 and the processing performed by metrics module 213 may, in some embodiments, depend on settings specific to one or more fault conditions being monitored. For example, for a given fault condition, settings may change which drive signal is selected to capture in select and capture module 212 as well as the manner in which metrics module 213 processes the data by changing signal paths to implement various filters and algorithms, performing measurements, utilizing specific parameters, or other settings that may affect processing to produce metrics specific to a fault condition. Metrics are calculated independently for baseline and runtime captures and then differences are calculated between them. Metrics may then be output by metrics module 213 and provided to one or more systems and modules for condition monitoring”);
classify each of the device health metrics into device health metric categories based on applying a rule set to each of the device health metrics, wherein the rule set is selectively applied to a respective device health metrics based on a type of the respective device health metric ([0030]: condition monitoring includes detection which includes categorizing conditions; [0034]: “system analytics 131 may […] detect system level fault conditions”; [0036]: “The output of metrics module 213 is provided to stand alone detection module 214 which may then use the metrics produced by metrics module 213 to perform fault detection within drive 210. Standalone detection, in some examples, comprises determining if one or more fault conditions is present based on the settings specific to at least one fault being monitored. Detection methods include thresholding or machine learning. In addition to supplying the metrics to stand alone detection module 214, metrics may be provided to additional systems for condition monitoring or other purposes. In the present example, metrics are provided to system detection module 240 for system-level fault detection”; [0041]: “Thresholds 351 may perform a variety of different condition monitoring functions including determining whether any measurements or metrics exceeded thresholds indicating an unhealthy state”);
provide a device health metric and a device health metric category associated with a selected device to a user ([0034]: “system analytics 131 may […] provide insights related to preventative maintenance, energy diagnostics, system modeling, performance optimization, and similar insights. At the enterprise level, enterprise analytics, cloud analytics, or a combination thereof may present information to users on devices and systems including mobile devices and desktop computers”; [0041]: “Detection section 350, in some examples, may display measurements, differences, or percent degradation. Differences and percentages may be displayed to give users a real-time or near real-time indication of the amount of mechanical and electrical degradation over time”; [0052]: “Detection 540 may then provide the information as output to indicate a status of the device or system with status 550. Detection 540 may further provide the information to additional systems for external condition monitoring”).
MIKLOSOVIC is not relied on to receive a request from a user device, wherein the request indicates an industrial system in an industrial automation environment, a device among a plurality of devices associated with the industrial system, and one or more types of device health metrics, and to provide in response to the request from the user device, a device health metric corresponding to the one or more types and to a device health metric category associated with the selected device to a user interface of the user device. MIKLOSOVIC is also not relied on for wherein applying the rule set comprises: identifying a unit of measurement with which to represent the respective device health metric based on the type; and converting a value of the respective device health metric to the unit of measurement.
However, LAKOMIAK in an analogous art teaches these claim limitations.
PNG
media_image1.png
548
826
media_image1.png
Greyscale
LAKOMIAK teaches methods and systems of using raw data originating from an industrial system or device to generate insight into the data based on end-user requirements at run-time of an industrial system (Fig. 3 above, [0001]: “invention relates to systems and methods for configuring, processing, and presenting machine condition monitoring information”), comprising:
receive a request from a user device, wherein the request indicates an industrial system in an industrial automation environment, a device among a plurality of devices associated with the industrial system, and one or more types of device health metrics (Fig. 4 below, [0027]: “FIG. 4 is an illustration of an embodiment of operator interface 14, including machine system selection interface 80. Machine selection interface 80 may allow an operator to choose the type of machine system that is connected to machine condition monitoring and control system 10. For example, a user may select between several machine system types, including a fan system, vertical pump system, motor system, conveyor system, turbine system, and so forth […] Once a system operator selects a system type foreach machine system, the machine system selection interface communicates the user selection, indicated by arrow 82, to a corresponding system type or profile 84” [0028]: “corresponding system type or profile may include a table of information for each system, thereby enabling an automatic configuration of the selected system type based on information in the system type profile 84, indicated by element 86”);
PNG
media_image2.png
541
800
media_image2.png
Greyscale
wherein applying the rule set comprises: identifying a unit of measurement with which to represent the respective device health metric based on the type; and converting a value of the respective device health metric to the unit of measurement ([0023]: “normalized indication of these machine system parameters enable a operator to see scaled data that may be scaled from 0 to 100% […] is an alternative to raw data presentation that may be in the form of frequency, revolutions per minute (RPM), magnitude, and other measurement units”[0034]: “indicator 146 displays a rotational speed for the shaft of motor 110, thereby providing a numeric indicator of the rotational speed of motor 110”, Fig. 6 #146)
provide, in response to the request from the user device, a device health metric corresponding to the one or more types and to a device health metric category associated with a selected device to a user interface of the user device ([0004]: “The method further includes the steps of normalizing each of the vibration parameters and presenting the normalized vibration parameters in an operator interface […] The system also includes a condition monitoring user interface configured to display normalized vibration parameters for the machine system”; [0016]: “operator interface 14 may allow a user […] to configure condition monitoring and control system 10, thereby enabling the system to monitor various machine condition parameters”; [0025]: operator may select the machine system type profile in the system being monitored; [0027]: “Machine selection interface 80 may allow an operator to choose the type of machine system that is connected to machine condition monitoring and control system […] system operator selects a system type of each machine system”; Fig. 6 below items 142 144 148 150 “NORMAL” maps to device health metric category; [0030]: “In step 100, the condition monitoring and control system 10 may execute and perform the selected machine system and calculation function block measurements on the selected machine system. In step 102, the conditioning monitoring software performs the selected calculation function block functions on the raw data acquired in step 100. For instance, the system software, including condition monitoring software 52 may perform FFT analysis and spike energy overall calculations on raw vibration data acquired by condition monitoring and control system 10. In step 104, the operator may view generic or normalized condition monitoring parameters, including alarms, trends and other screens such as diagnostic information” Fig. 5 below discloses a workflow that begins with a request from a user device #92 & #94, applying rule sets #100 & #102, and providing device health information to a user #104).
PNG
media_image3.png
846
653
media_image3.png
Greyscale
PNG
media_image4.png
547
784
media_image4.png
Greyscale
MIKLOSOVIC and LAKOMIAK are analogous art to the claimed invention because they are from the field of condition monitoring of industrial devices in an industrial facility. MIKLOSOVIC teaches an analytic engine configured to monitor industrial devices of an industrial system in order to detect component failures before they occur (Abstract), but does not emphasize a particular user interface. LAKOMIAK teaches a condition monitoring user interface that allows a user to select an industrial device from among industrial devices in an industrial system, select what kind of condition to monitor, and to provide the condition monitoring information to the user via a dashboard in response to the selection (Figs. 4-6). Before the effective filing date of the claimed invention, it would have been obvious to one of ordinary skill in the art to apply the teachings of LAKOMIAK to the teachings of MIKLOSOVIC because they address the same industrial device condition monitoring problem. One of ordinary skill in the art would have recognized, before the effective filing date of the claimed invention, that LAKOMIAK’s condition monitoring user interface could have been incorporated with MIKLOSOVIC’s analytic engine based industrial monitoring system represents according to known methods to yield predictable results.
Regarding claim 2
MIKLOSOVIC-LAKOMIAK teaches the elements of claim 1 as outlined above. MIKLOSOVIC also teaches to contextualize each of the performance metrics, the program instructions direct the system to perform one or more operations on each of the performance metrics ([0041]: “Metrics are then provided to detection section 350 comprising thresholds 351 and percent degradation 352 in addition to any other specified output locations such as additional condition monitoring modules within the drive or external systems. Differences may then be calculated between baseline metrics and the recent metric calculations. Percent degradation 352 may utilize a detection method that determines the percent of degradation between the baseline metrics and the recent metrics”).
Regarding claim 5
MIKLOSOVIC-LAKOMIAK teaches the elements of claim 1 as outlined above. MIKLOSOVIC also teaches wherein the device is a variable-speed drive ([0026]: “important instruments associated with motor control include the variable frequency drive”).
Regarding claim 6
MIKLOSOVIC-LAKOMIAK teaches the elements of claim 5 as outlined above. MIKLOSOVIC also teaches the device health metrics indicate health of one or more industrial devices coupled to the variable speed drive ([0027]: “Thus, a general-purpose, configurable analytic engine embedded in a motor drive (i.e., a VFD) is disclosed. An analytic engine in accordance with the present disclosure may include an application layer that hides configuration complexity and simplifies a user's experience. The analytic engine maybe configured to monitor various applications and detect degradation of a motor or its detected mechanical load early on”).
Regarding claim 7
MIKLOSOVIC-LAKOMIAK teaches the elements of claim 1 as outlined above. LAKOMIAK also teaches the device health metric categories comprise a healthy category, an unhealthy category, and an approaching unhealthy category ([0035]: status indicator may display a status such as normal, danger, or warning (i.e., healthy, unhealthy, or approaching unhealthy, respectively).
Regarding claim 8
Claim 8 recites a method comprising substantially the same limitations as claim 1 and is rejected as per such.
Regarding claim 9
MIKLOSOVIC-LAKOMIAK teaches the elements of claim 8 as outlined above. MIKLOSOVIC also teaches wherein the performance metric is a first performance metric of a plurality of performance metrics ([0007]: condition monitoring module is configured to monitoring one or more fault conditions based on metrics), wherein the device is a first device of a plurality of devices in the industrial automation environment ([0007]: “monitoring one or more fault conditions of the industrial operation comprises monitoring one or more fault conditions of the motor and/or the connected mechanical load”), and wherein each performance metric of the plurality of the performance metrics is associated with a device of the plurality of the devices ([0007]: “monitor one or more fault conditions of the industrial operation based on metrics […] of the motor and/or the connected mechanical load”).
Regarding claim 10
MIKLOSOVIC-LAKOMIAK teaches the elements of claim 8 as outlined above. The remaining limitations of claim 10 are substantially the same as claim 2 and are rejected as per such.
Regarding claim 11
MIKLOSOVIC-LAKOMIAK teaches the elements of claim 10 as outlined above. MIKLOSOVIC also teaches wherein the contextualization information comprises signals indicative of one or more of an electrical value, a mechanical value, and a thermal value associated with the device ([0030]: “input signal source, such as signals from vibration, temperature, or acoustic sensors or drive signals like phase current and voltage, torque reference, or velocity”).
Regarding claim 14
MIKLOSOVIC-LAKOMIAK teaches the elements of claim 8 as outlined above. The remaining limitations of claim 14 are substantially the same as claim 5 and are rejected as per such.
Regarding claim 15
MIKLOSOVIC-LAKOMIAK teaches the elements of claim 14 as outlined above. The remaining limitations of claim 15 are substantially the same as claim 6 and are rejected as per such.
Regarding claim 16
MIKLOSOVIC-LAKOMIAK teaches the elements of claim 8 as outlined above. The remaining limitations of claim 16 are substantially the same as claim 7 and are rejected as per such.
Claims 3-4 and 12-13 are rejected under 35 U.S.C. 103 as being unpatentable over MIKLOSOVIC-LAKOMIAK in view of MURPHY (US20150211581A1) (hereinafter “MIKLOSOVIC-LAKOMIAK-MURPHY”).
Regarding claim 3
MIKLOSOVIC-LAKOMIAK teaches the elements of claim 1 as outlined above. MIKLOSOVIC also teaches wherein applying the rule set comprises identifying the threshold data, [0041]: “Metrics are then provided to detection section 350 comprising thresholds 351 […] Thresholds
351 may perform a variety of different condition monitoring functions including determining whether any measurements or metrics exceeded thresholds indicating an unhealthy state. Specific thresholds may be set to show when metrics exceed predetermined values […] thresholds are averaged over a specified number of detection cycles”).
MIKLOSOVIC-LAKOMIAK is not relied on for wherein applying the rule set further comprises the time range. However, MURPHY in an analogous art teaches to verify that an industrial device has alarm condition by measuring subsequent operating condition parameters of the industrial device over a predetermined period of time ([0104]).
MURHPY is analogous art to the claimed invention because they are from the field of condition monitoring of industrial devices. Before the effective filing date of the claimed invention, it would have been obvious to one of ordinary skill in the art to apply the teaching of MURPHY to the teaching of the MIKLOSOVIC-LAKOMIAK combination such that MURHPY’s method of verifying an alarm condition of an industrial device by accounting for a period of time of the monitored parameter of the industrial device over the threshold would have been used with MIKLOSOVIC-LAKOMIAK’s analytic engine configured to monitor the health of an industrial device according to known methods with a reasonable expectation of success. One of ordinary skill in the art would have been motivated to make such a combination in order to “mitigate noise and other undesirable instantaneous effects”, as taught by MIKLOSOVIC ([0041]).
Thus, the MIKLOSOVIC-LAKOMIAK-MURPHY combination teaches or at least suggests wherein applying the rule set further comprises: identifying the threshold data, the time range and the quantity. LAKOMIAK also teaches or at least suggests to covert the value to the unit of measurement based on the threshold data, the time range, and the quantity ([0023]: “an alternative to raw data presentation that may be in the form of frequency, revolutions per minute(RPM), magnitude, and other measurement units”, Fig. 6 #146).
Regarding claim 4
MIKLOSOVIC-LAKOMIAK-MURPHY teaches the elements of claim 3 as outlined above.
LAKOMIAK also teaches or at least suggests wherein the rule set is user-selected via the user interface of the user device from among a plurality of rule sets available for selection via the user interface based on the type of respective device health metric ([0028]: “appropriate system profile information 86 may allow a user to configure condition monitoring of the selected system without in depth knowledge of the machine system. Further, the system profile information 86 enables an operator to configure the machine system without referring to industry standard tables during analysis of the condition monitoring data for the system. In addition, a library of machine system type profiles is available to the operator for each machine system to be configured by condition monitoring and control system 10. Machine system selection interface 80 may be a user interface of condition monitoring software 52that enables an operator to set up and configure condition monitoring of several types of machine systems”, Fig. 4 #84 and Fig. 5 #94).
Regarding claim 12
MIKLOSOVIC-LAKOMIAK teaches the elements of claim 8 as outlined above. The remaining limitations of claim 12 are substantially the same as claim 3 and are rejected as per such.
Regarding claim 13
MIKLOSOVIC-LAKOMIAK-MURPHY teaches the elements of claim 12 as outlined above. The remaining limitations of claim 13 are substantially the same as claim 4 and are rejected as per such.
Claims 17-20 are rejected under 35 U.S.C. as being unpatentable over LAKOMIAK (US20100082158A1) in view of MIKLOSOVIC (US20210341896A1) (hereinafter – “LAKOMIAK-MIKLOSOVIC”).
Regarding claim 17
LAKOMIAK teaches:
PNG
media_image5.png
646
931
media_image5.png
Greyscale
one or more computer-readable storage media (Fig. 2 memory 48);
one or more processors coupled to the one or more computer-readable storage media (Fig. 2 processor 50);
program instructions stored on the one or more computer-readable storage media (Fig. 2 monitoring software 52) that based on being read and executed by the one or more processors,
provide a user interface to a user device (Fig. 2 & [0023]: user device/display 56 “may enable an operator to assess a machine system condition”; [0031]: “FIGS. 6-8 illustrate embodiments of screens that display machine condition monitoring information to an operator” - Fig. 6 below shows user interface that displays machine condition information),
PNG
media_image6.png
641
914
media_image6.png
Greyscale
wherein the user interface comprises:
a dashboard navigable by a user of the user device ([0034]: “menu bar 154, which includes buttons to navigate between screens”); and
indications corresponding to one or more devices of an industrial automation environment ([0002]: industrial equipment [0016]-[0017]: user may configure systems 16, 18, and 20 to be monitored by condition monitoring and may be systems susceptible to automation; Fig. 6 above shows a plurality of indications corresponding an industrial device), wherein the indications comprise:
device health indications indicative of a health of the one or more devices (Fig. 6, [0032]: normalized vibration parameters 124);
PNG
media_image7.png
605
902
media_image7.png
Greyscale
behavioral indications indicative of a behavior of the one or more devices (Fig. 6, [0032]: status indicator 142, Fig. 7, [0035]: status indicator 166 may display status (e.g., behavioral indication) such as warning, danger, normal); and
maintenance indications indicative of maintenance tasks corresponding to the one or more devices based on the behavior indications and the device health indications (Fig. 7, [0036]: “a diagnostic message 186 may be communicated to help an operator address the problem indicated”, item 184 correct by balancing, check for looseness, add lubrication are indicative of maintenance tasks corresponding to one or more devices based determined from condition monitoring software, see Fig. 3 below); and
PNG
media_image8.png
669
938
media_image8.png
Greyscale
wherein a first subset of indications are generated and instantiated for display on the dashboard of the user interface in response to a first selection of the system by the user ([0031]: “screens may be displayed on the operator/user interfaces 14, 40, and 46 shown in FIG. 1. Embodiments of the operator interface screens may include a system of windows, icons, menus, and pointing devices to enable navigation through various screens of the machine condition monitoring software 52” [0032]: “FIG. 6 illustrates an embodiment of display screen 106, includes normalized vibration parameters that may be displayed to a system operator”, i.e., the first input from the user loads dashboard from FIG. 6 to user interface such that indications such as vibration parameters are instantiated for display on the dashboard); and
wherein a second subset of indications are generated and instantiated for display on the dashboard of the user interface in response to a second selection of the one or more devices and a type of device health metric corresponding to the one of the health, the behavior, and the maintenance tasks by the user ([0031]: “screens may be displayed on the operator/user interfaces 14, 40, and 46 shown in FIG. 1. Embodiments of the operator interface screens may include a system of windows, icons, menus, and pointing devices to enable navigation through various screens of the machine condition monitoring software 52” [0035]: “FIG. 7 is an illustration of an embodiment of screen 160 which displays diagnostic information for a machine system connected to condition monitoring and control system 10 […] The machine diagnostic status may be displayed in text box 178, thereby informing the operator of any warnings as well as instructions or diagnostic messages 180 to address the diagnostic problem”, i.e, the second input from the user loads dashboard from FIG. 7 to user interface such that indications of maintenance tasks are instantiated for display on the dashboard).
LAKOMIAK is not relied on for wherein the device health indications are based on contextualized metrics determined by performing operations on performance metrics associated with the one or more devices. LAKOMIAK is not relied on for wherein the behavioral indications are based on applying rule sets to the contextualized metrics.
However, MIKLOSOVIC in an analogous art does teach this claim limitation. MIKLOSOVIC teaches systems and methods for condition monitoring in an industrial environment ([0007]: “condition monitoring in industrial environments”) to determine:
device health indications indicative of a health of the one or more devices based on contextualized metrics determined by performing operations on performance metrics associated with the one or more devices ([0030]: condition monitoring includes data acquisition and feature extraction; [0034]: “system analytics 131 may aggregate and contextualize information to detect system level fault conditions and/or provide insights related to preventative maintenance, energy diagnostics, system modeling, performance optimization, and similar insights”; [0039]: “Runtime metrics section
330 and baseline metrics section 340 convert data heavy signals to data light metrics that may be used to detect fault conditions within the drive”; [0041]: “Differences may then be calculated between baseline metrics and the recent metric calculations. Percent degradation 352
may utilize a detection method that determines the percent of degradation between the baseline metrics and the recent metrics”); and
behavioral indications indicative of a behavior of the one or more devices based on applying rule sets to the contextualized metrics ([0041]: “Thresholds 351 may perform a variety of different condition monitoring functions including determining whether any measurements or metrics exceeded thresholds indicating an unhealthy state. Specific thresholds may be set to show when metrics exceed predetermined values”).
LAKOMIAK and MIKLSOVIC are analogous art to the claimed invention because they are from the field of condition monitoring of industrial devices in an industrial facility. LAKOMIAK teaches a condition monitoring user interface that allows a user to select an industrial device from among industrial devices in an industrial system, select what kind of condition to monitor, and to provide the condition monitoring information to the user via a dashboard in response to the selection (Figs. 4-6). MIKLOSOVIC teaches an analytic engine configured to monitor industrial devices of an industrial system in order to detect component failures before they occur (Abstract), but does not emphasize a particular user interface. Before the effective filing date of the claimed invention, it would have been obvious to one of ordinary skill in the art to apply the teachings of LAKOMIAK to the teachings of MIKLOSOVIC because they address the same industrial device condition monitoring problem. One of ordinary skill in the art would have recognized, before the effective filing date of the claimed invention, that LAKOMIAK’s condition monitoring user interface could have been incorporated with MIKLOSOVIC’s analytic engine based industrial monitoring system represents according to known methods to yield predictable results.
Regarding claim 18
LAKOMIAK-MIKLOSOVIC teaches the elements of claim 17 as outlined above. MIKLOSOVIC also teaches a server configured to obtain the performance metrics associated with the one or more devices ([0031]: “External systems 130 serves to represent or include any layer of an industrial automation environment external to variable frequency drive 110, wherein the external analytics may collect and analyze data”; [0063]: system level detection may comprise servers); contextualize each of the performance metrics based on contextualization information specific to each of the performance metrics to produce the contextualized metric, each contextualized metric corresponding to a performance metric of the performance metrics ([0030]: condition monitoring includes feature extraction; [0034]: “system analytics 131 may aggregate and contextualize information”; [0035]: “Environment 200 includes drive 210 representative of a variable frequency comprising an analytics engine such as drive 110 […] Metrics module 213 processes the data to generate metrics data that can be utilized for fault detection. The data collected by select and capture module 212 and the processing performed by metrics module 213 may, in some embodiments, depend on settings specific to one or more fault conditions being monitored. For example, for a given fault condition, settings may change which drive signal is selected to capture in select and capture module 212 as well as the manner in which metrics module 213 processes the data by changing signal paths to implement various filters and algorithms, performing measurements, utilizing specific parameters, or other settings that may affect processing to produce metrics specific to a fault condition. Metrics are calculated independently for baseline and runtime captures and then differences are calculated between them. Metrics may then be output by metrics module 213 and provided to one or more systems and modules for condition monitoring”); and classifying each of the contextualized metrics into behaviors based on applying a rule set to each of the contextualized metrics, wherein the rule set is selectively applied to a respective contextualized metric based on a type of the respective contextualized metric ([0030]: condition monitoring includes detection which includes categorizing conditions; [0034]: “system analytics 131 may […] detect system level fault conditions”; [0036]: “The output of metrics module 213 is provided to stand alone detection module 214 which may then use the metrics produced by metrics module 213 to perform fault detection within drive 210. Standalone detection, in some examples, comprises determining if one or more fault conditions is present based on the settings specific to at least one fault being monitored. Detection methods include thresholding or machine learning. In addition to supplying the metrics to stand alone detection module 214, metrics may be provided to additional systems for condition monitoring or other purposes. In the present example, metrics are provided to system detection module 240 for system-level fault detection”; [0041]: “Thresholds 351 may perform a variety of different condition monitoring functions including determining whether any measurements or metrics exceeded thresholds indicating an unhealthy state”).
MIKLOSOVIC is not relied on for the server obtaining a request from the user via a selectable element of the dashboard, the request including the first selection and the second selection. However, LAKOMIAK teaches selectable elements of the dashboard such that a user can make a first selection and a second selection, as outlined above (claim 17). While neither MIKLSOVIC nor LAKOMIAK individually explicitly disclose a server obtaining a request including the first and second user selection, because MIKLSOVIC teaches contextualizing and classifying at a health monitoring server, one of ordinary skill in the art would have found it obvious to try to configure the server such that inputs from the user at the user interface would be transmitted such that the contextualization and classification would be performed according to the first and second selections, with a reasonable expectation of success.
Regarding claim 19
LAKOMIAK-MIKLOSOVIC teaches the elements of claim 18 as outlined above. The remaining limitations of claim 19 are substantially the same as claim 7 and are rejected as per such.
Regarding claim 20
LAKOMIAK-MIKLOSOVIC teaches the elements of claim 17 as outlined above. The remaining limitations of the claim are substantially the same as claim 5 and are rejected as per such.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Dietz (US20150177100A1) teaches to count threshold exceedances to make a state determination ([0100]-[0121]).
ABB_NPL (“ABB Ability Smart Sensor: User guide for Smart Sensor Platform app and web portal”, published 11/18/2020, retrieved on 6/22/2026, retrieved from https://library.e.abb.com/public/80d80b6b23ba49dda329b62a82f2fd46/9AKK107045A8954_ABB%20Ability%20SmartSensor_user%20guide_RevF.pdf) teaches data visualization on a mobile app of condition monitoring of an industrial device.
THIS ACTION IS MADE FINAL. 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 Michael V Farina whose telephone number is (571)272-4982. The examiner can normally be reached Mon-Thu 8:00-6:00 EST.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Kamini Shah can be reached at (571) 272-2279. 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.
/M.V.F./Examiner, Art Unit 2115
/KAMINI S SHAH/Supervisory Patent Examiner, Art Unit 2115
Prosecution Insights