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 October 17, 2025 has been entered.
Status of the Claims
Claims 1, 4, 5, 7-9, 12, 13, 15-17, 20, 21, and 23-29 are all the claims pending in the application.
Claims 2, 3, 6, 10, 11, 14, 18, 19, and 22 are cancelled.
Claims 25-29 are new.
Claims 1, 4, 9, 12, 17, and 20 are amended.
Claims 1, 4, 5, 7-9, 12, 13, 15-17, 20, 21, and 23-29 are rejected.
The following is a Non-Final Office Action in response to amendments and remarks filed October 17, 2025.
Response to Arguments
Regarding the 101 rejections, the rejections are maintained for the following reasons. First, Applicant asserts the claims do not recite a mental process because the claims recite changing the configuration of a maintenance profile including the frequency. Examiner respectfully does not find this assertion persuasive because changing maintenance protocols (including the frequency of the maintenance) can be performed in the mind or with pen and paper.
Second, Applicant asserts the claims integrate the abstract idea into a practical application because changing the maintenance procedure is a practical application. Examiner respectfully does not find this assertion persuasive because a bare of a practical application without the detail necessary to be apparent is not sufficient to show a practical application, see MPEP 2106.04(d)(1) (discussing MPEP 2106.05(a)). That is, it is not clear how changing the maintenance procedure is a practical application (e.g., how changing the maintenance procedure reflects an improvement, see MPEP 2106.05(a), or effects a transformation or reduction, see MPEP 2106.05(c). Accordingly the 101 rejections are maintained, please see below for the complete rejections of the claims as amended.
Regarding the 103 rejections, the rejections are withdrawn because the cited references do not teach changing maintenance protocols including the frequency of the maintenance. Please see below for the new 103 rejections of the claims as amended.
In response to arguments in reference to any depending claims that have not been individually addressed, all rejections made towards these dependent claims are maintained due to a lack of reply by Applicant in regards to distinctly and specifically pointing out the supposed errors in Examiner's prior office action (37 CFR 1.111). Examiner asserts that Applicant only argues that the dependent claims should be allowable because the independent claims are unobvious and patentable over the prior art.
Claim Rejections - 35 USC § 101
35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
Claims 1, 4, 5, 7-9, 12, 13, 15-17, 20, 21, and 23-29 are rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more.
Under Step 1 of the patent eligibility analysis, it must first be determined whether the claims are directed to one of the four statutory categories of invention. Applying Step 1 to the claims it is determined that: claims 1, 4, 5, 7, 8, 25, and 26 are directed to a process; and claims 9, 12, 13, 15-17, 20, 21, 23, 24, 27, and 28 are directed to a machine.
Independent Claims
Under Step 2A Prong 1 of the patent eligibility analysis, it must be determined whether the claims recite an abstract idea that falls within one or more designated categories or “buckets” of patent ineligible subject matter that amount to a judicial exception to patentability.
The independent claims recite an abstract idea. Specifically, independent claim 1 recites an abstract idea in the limitations (emphasized):
…receiving, using at least one processor, a request to update a first maintenance profile of a device that is an operative maintenance profile of the device,
wherein a first maintenance profile data of the first maintenance profile includes at least one setting configuring a maintenance operation to be performed on the device, and the at least one setting has a first value;
receiving, using the at least one processor, a second maintenance profile of the device generated based on the first maintenance profile of the device,
wherein a second maintenance profile data of the second maintenance profile includes the at least one setting with a second value that is different from the first value, and the at least one setting configures a frequency of the maintenance operation to be performed on the device;
generating, using the at least one processor, an electronic change request (ECR) configured to request replacement of the first maintenance profile with the second maintenance profile as the operative maintenance profile of the device,
wherein the ECR includes a change in the one setting configuring the maintenance operation, including the frequency of the maintenance operation, and
wherein the generating of the ECR occurring automatically irrespective of a format in which the first maintenance profile data of the first maintenance profile is arranged within the first maintenance profile, wherein the second maintenance profile is generated based on the first maintenance profile of the device via:
a flattening operation on the first maintenance profile that is configured to preserve a form logic of the format in which the first maintenance profile data of the first maintenance profile is arranged within the first maintenance profile, and
editing of the flattened first maintenance profile to generate the second maintenance profile;
transmitting, using the at least one processor, the ECR to a profile change authorization server configured to regulate changes to the first maintenance profile of the device; and
receiving, using the at least one processor and in response to the transmitting, an authorization message from the profile change authorization server authorizing or denying the ECR.
These limitations recite an abstract idea because these limitations encompass human judgments, observations and evaluations that can be practically or reasonably performed in the human mind. That is, generating an ECR and editing a maintenance profile, as claimed, encompasses observing, analyzing and updating maintenance protocols which are processes that can be performed in the human mind. Claims 1, 9, and 17 recite an abstract idea consistent with the “mental process” grouping set forth in the see MPEP 2106.04(a)(2)(III).
Under Step 2A Prong 2 of the patent eligibility analysis, it must be determined whether the identified, recited abstract idea includes additional elements that integrate the abstract idea into a practical application.
The additional elements of the independent claims do not integrate the abstract idea into a practical application. Claim 1 recites the additional elements (emphasized):
…receiving, using at least one processor, a request to update a first maintenance profile of a device that is an operative maintenance profile of the device,
wherein a first maintenance profile data of the first maintenance profile includes at least one setting configuring a maintenance operation to be performed on the device, and the at least one setting has a first value;
receiving, using the at least one processor, a second maintenance profile of the device generated based on the first maintenance profile of the device,
wherein a second maintenance profile data of the second maintenance profile includes the at least one setting with a second value that is different from the first value, and the at least one setting configures a frequency of the maintenance operation to be performed on the device;
generating, using the at least one processor, an electronic change request (ECR) configured to request replacement of the first maintenance profile with the second maintenance profile as the operative maintenance profile of the device,
wherein the ECR includes a change in the one setting configuring the maintenance operation, including the frequency of the maintenance operation, and
wherein the generating of the ECR occurring automatically irrespective of a format in which the first maintenance profile data of the first maintenance profile is arranged within the first maintenance profile, wherein the second maintenance profile is generated based on the first maintenance profile of the device via:
a flattening operation on the first maintenance profile that is configured to preserve a form logic of the format in which the first maintenance profile data of the first maintenance profile is arranged within the first maintenance profile, and
editing of the flattened first maintenance profile to generate the second maintenance profile;
transmitting, using the at least one processor, the ECR to a profile change authorization server configured to regulate changes to the first maintenance profile of the device; and
receiving, using the at least one processor and in response to the transmitting, an authorization message from the profile change authorization server authorizing or denying the ECR.
These additional elements do not integrate the abstract idea into a practical application for the following reasons. First, the additional elements of receiving the request and the second maintenance profile, transmitting the ECR, and receiving an authorization message, when considered individually or in combination, do not integrate the abstract idea into a practical application because the additional elements encompass generic computer functions of receiving and sending data (e.g., sending and receiving various user inputs and stored data), see MPEP 2106.05(f)(2) (noting the use of computers in their ordinary capacity to receive, store, or transmit data does not integrate a judicial exception into a practical application).
Second, the additional elements of performing the various steps using a processor and the generating occurring automatically, when considered individually or in combination, do not integrate the abstract idea into a practical application because the additional elements are recited at a high-level of generality (i.e., as via generic computers) such that it amounts to no more than mere instructions to apply the exception.
Third, the additional elements of the flattening operation, when considered individually or in combination, do not integrate the abstract idea into a practical application because the additional elements are only a general link to a field of use or technological environment, see MPEP 2106.05(h) (discussing Affinity Labs). That is, although these additional elements do limit the use of the abstract idea, this type of limitation merely confines the use of the abstract idea to a particular technological environment (data processing techniques for machine learning) and does not integrate the abstract idea into a practical application or add an inventive concept to the claims.
Fourth, claims 9 and 17 further recite "at least one computer-readable medium storing computer-executable instructions; and at least one processor configured to execute the computer executable instructions" and a "non-transitory computer readable medium comprising at least one program for execution by at least one processor of a system, the at least one program including instructions", respectively. These additional elements, when considered individually or in combination, do not integrate the abstract idea into a practical application because the additional elements are recited at a high-level of generality such that it amounts to no more than mere instructions to apply the exception using generic computer components. Claims 1, 9 and 17 are directed to an abstract idea.
Under Step 2B of the patent eligibility analysis, the additional elements are evaluated to determine whether they amount to something “significantly more” than the recited abstract idea (i.e., an innovative concept).
The independent claims do not include additional elements that are sufficient to amount to significantly more than the judicial exception. As discussed above with respect to integration of the abstract idea into a practical application, the additional elements amount to no more than mere instructions to apply the exception and a general link to a field of use. Mere instructions to apply an exception and a general link to a field of use cannot provide an inventive concept. Claims 1, 9 and 17 are not patent eligible.
Dependent Claims
The dependent claims are rejected under 35 USC 101 as directed to an abstract idea for the following reasons.
Claims 4, 5, 12, 13, 20 and 21 recite the same abstract idea as the independent claims because configuring a procedure of the maintenance operation and activating new maintenance profiles are a part updating maintenance protocols.
Claims 7, 8, 15, 16, 23, and 24 recite the additional elements of limiting the format and profile to JavaScript Object Notation file format. These additional elements, when considered individually or in combination, do not integrate the abstract idea into a practical application because the additional elements are only a general link to a field of use or technological environment, see MPEP 2106.05(h) (discussing Affinity Labs). That is, although these additional elements do limit the use of the abstract idea, this type of limitation merely confines the use of the abstract idea to a particular technological environment (data processing techniques for machine learning and JSON formats) and does not integrate the abstract idea into a practical application or add an inventive concept to the claims.
Claims 25-29 recite the same abstract idea as the independent claims because configuring a duration and a location of a maintenance operations are a part updating maintenance protocols.
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.
Claim(s) 1, 4, 5, 7-9, 12, 13, 15-17, 20, 21, and 23-29 is/are rejected under 35 U.S.C. 103 as being unpatentable over U.S. Patent Application Publication No. 20220103549 to Jefferies et al. (hereafter Jefferies) in view of US 10,542,021 to Mehr, further in view of US 8560368 Maity et al. (hereinafter Maity)
Referring to Claims 1, 9 and 17 (similar in scope and language), Jefferies discloses a method, system, and the non-transitory computer readable medium comprising:
receiving, using at least one processor, a request to update a first maintenance profile of a device that is an operative maintenance profile of the device (see at least Jefferies: ¶ 54 “In an example scenario, when networked device 102(A1) receives a request to change a setting, such as a change to a user credential, an application update, or a maintenance procedure, networked device 102(A1) can determine similar devices of the networked devices 102 for which a similar change should be made or should be suggested. Setting changes can be suggested or implemented for all or particular ones of the selected networked devices 102 (e.g., (A2), (N1), and (N2)). This guides coordination and provides consistency of settings across similar devices and provides consistency for human actions (e.g., maintenance operations or password changes).”; see also ¶ 58-60 “the request can be to delete a particular user from having authorization to log onto similar networked devices 102…the request can be to change a particular setting of system settings… the request can be to change a particular setting of an application used by the networked devices”);
wherein a first maintenance profile data of the first maintenance profile includes at least one setting configuring a maintenance operation to be performed on the device, and the at least one setting has a first value (see at least Jefferies: ¶ 54 “In an example scenario, when networked device 102(A1) receives a request to change a setting, such as a change to a user credential, an application update, or a maintenance procedure, networked device 102(A1) can determine similar devices of the networked devices 102 for which a similar change should be made or should be suggested. Setting changes can be suggested or implemented for all or particular ones of the selected networked devices 102 (e.g., (A2), (N1), and (N2)). This guides coordination and provides consistency of settings across similar devices and provides consistency for human actions (e.g., maintenance operations or password changes).”; see also ¶ 58-60 “the request can be to delete a particular user from having authorization to log onto similar networked devices 102…the request can be to change a particular setting of system settings… the request can be to change a particular setting of an application used by the networked devices”; see also Jefferies: ¶ 37 “The request can be submitted by a user or the external processing device to change a specified setting of the device settings 106 to a new value Y. In one or more embodiments, the request can specify an original value of the specified setting being changed. Upon receiving a request, a networked device 102 changes its device settings 106 as specified by the request.”; see also Jefferies: ¶ 47 “Examples of device settings 106 includes a user credential (e.g., passwords, authorized user, constraints on authorized users), device system settings (e.g., an update to a simple network time protocol (SNTP) time server address or rapid spanning tree protocol (RSTP) parameters), and application settings (e.g., an updates to a motor protection undercurrent alarm threshold (such as from 80% to 70%), or an update to a motor protection ground current trip function from (such as from an enable setting to a disable setting).”; see also ¶ 58-60 “the request can be to delete a particular user from having authorization to log onto similar networked devices 102…the request can be to change a particular setting of system settings… the request can be to change a particular setting of an application used by the networked devices”; see also Jefferies: ¶ 37 “The request can be submitted by a user or the external processing device to change a specified setting of the device settings 106 to a new value Y. In one or more embodiments, the request can specify an original value of the specified setting being changed. Upon receiving a request, a networked device 102 changes its device settings 106 as specified by the request.”; see also Jefferies: ¶ 47 “Examples of device settings 106 includes a user credential (e.g., passwords, authorized user, constraints on authorized users), device system settings (e.g., an update to a simple network time protocol (SNTP) time server address or rapid spanning tree protocol (RSTP) parameters), and application settings (e.g., an updates to a motor protection undercurrent alarm threshold (such as from 80% to 70%), or an update to a motor protection ground current trip function from (such as from an enable setting to a disable setting).”);
receiving, using the at least one processor, a second maintenance profile of the device generated based on the first maintenance profile of the device (see at least Jefferies: ¶ 54 “In an example scenario, when networked device 102(A1) receives a request to change a setting, such as a change to a user credential, an application update, or a maintenance procedure, networked device 102(A1) can determine similar devices of the networked devices 102 for which a similar change should be made or should be suggested. Setting changes can be suggested or implemented for all or particular ones of the selected networked devices 102 (e.g., (A2), (N1), and (N2)). This guides coordination and provides consistency of settings across similar devices and provides consistency for human actions (e.g., maintenance operations or password changes).”; see also ¶ 58-60 “the request can be to delete a particular user from having authorization to log onto similar networked devices 102…the request can be to change a particular setting of system settings… the request can be to change a particular setting of an application used by the networked devices”; see also Jefferies: ¶ 37 “The request can be submitted by a user or the external processing device to change a specified setting of the device settings 106 to a new value Y. In one or more embodiments, the request can specify an original value of the specified setting being changed. Upon receiving a request, a networked device 102 changes its device settings 106 as specified by the request.”; see also Jefferies: ¶ 47 “Examples of device settings 106 includes a user credential (e.g., passwords, authorized user, constraints on authorized users), device system settings (e.g., an update to a simple network time protocol (SNTP) time server address or rapid spanning tree protocol (RSTP) parameters), and application settings (e.g., an updates to a motor protection undercurrent alarm threshold (such as from 80% to 70%), or an update to a motor protection ground current trip function from (such as from an enable setting to a disable setting).”);
wherein a second maintenance profile data of the second maintenance profile includes the at least one setting with a second value that is different from the first value (see at least Jefferies: ¶ 54 “In an example scenario, when networked device 102(A1) receives a request to change a setting, such as a change to a user credential, an application update, or a maintenance procedure, networked device 102(A1) can determine similar devices of the networked devices 102 for which a similar change should be made or should be suggested. Setting changes can be suggested or implemented for all or particular ones of the selected networked devices 102 (e.g., (A2), (N1), and (N2)). This guides coordination and provides consistency of settings across similar devices and provides consistency for human actions (e.g., maintenance operations or password changes).”; see also ¶ 58-60 “the request can be to delete a particular user from having authorization to log onto similar networked devices 102…the request can be to change a particular setting of system settings… the request can be to change a particular setting of an application used by the networked devices”; see also Jefferies: ¶ 37 “The request can be submitted by a user or the external processing device to change a specified setting of the device settings 106 to a new value Y. In one or more embodiments, the request can specify an original value of the specified setting being changed. Upon receiving a request, a networked device 102 changes its device settings 106 as specified by the request.”; see also Jefferies: ¶ 47 “Examples of device settings 106 includes a user credential (e.g., passwords, authorized user, constraints on authorized users), device system settings (e.g., an update to a simple network time protocol (SNTP) time server address or rapid spanning tree protocol (RSTP) parameters), and application settings (e.g., an updates to a motor protection undercurrent alarm threshold (such as from 80% to 70%), or an update to a motor protection ground current trip function from (such as from an enable setting to a disable setting).”; see also ¶ 58-60 “the request can be to delete a particular user from having authorization to log onto similar networked devices 102…the request can be to change a particular setting of system settings… the request can be to change a particular setting of an application used by the networked devices”; see also Jefferies: ¶ 37 “The request can be submitted by a user or the external processing device to change a specified setting of the device settings 106 to a new value Y. In one or more embodiments, the request can specify an original value of the specified setting being changed. Upon receiving a request, a networked device 102 changes its device settings 106 as specified by the request.”; see also Jefferies: ¶ 47 “Examples of device settings 106 includes a user credential (e.g., passwords, authorized user, constraints on authorized users), device system settings (e.g., an update to a simple network time protocol (SNTP) time server address or rapid spanning tree protocol (RSTP) parameters), and application settings (e.g., an updates to a motor protection undercurrent alarm threshold (such as from 80% to 70%), or an update to a motor protection ground current trip function from (such as from an enable setting to a disable setting).”);
generating, using the at least one processor, an electronic change request (ECR) configured to request replacement of the first maintenance profile with the second maintenance profile as the operative maintenance profile of the device (see at least Jefferies: ¶ 54 “In an example scenario, when networked device 102(A1) receives a request to change a setting, such as a change to a user credential, an application update, or a maintenance procedure, networked device 102(A1) can determine similar devices of the networked devices 102 for which a similar change should be made or should be suggested. Setting changes can be suggested or implemented for all or particular ones of the selected networked devices 102 (e.g., (A2), (N1), and (N2)). This guides coordination and provides consistency of settings across similar devices and provides consistency for human actions (e.g., maintenance operations or password changes).”; see also ¶ 58-60 “the request can be to delete a particular user from having authorization to log onto similar networked devices 102…the request can be to change a particular setting of system settings… the request can be to change a particular setting of an application used by the networked devices”; see also Jefferies: ¶ 37 “The request can be submitted by a user or the external processing device to change a specified setting of the device settings 106 to a new value Y. In one or more embodiments, the request can specify an original value of the specified setting being changed. Upon receiving a request, a networked device 102 changes its device settings 106 as specified by the request.”; see also Jefferies: ¶ 47 “Examples of device settings 106 includes a user credential (e.g., passwords, authorized user, constraints on authorized users), device system settings (e.g., an update to a simple network time protocol (SNTP) time server address or rapid spanning tree protocol (RSTP) parameters), and application settings (e.g., an updates to a motor protection undercurrent alarm threshold (such as from 80% to 70%), or an update to a motor protection ground current trip function from (such as from an enable setting to a disable setting).”);
wherein the ECR includes a change in the one setting configuring the maintenance operation (see at least Jefferies: ¶ 54 “In an example scenario, when networked device 102(A1) receives a request to change a setting, such as a change to a user credential, an application update, or a maintenance procedure, networked device 102(A1) can determine similar devices of the networked devices 102 for which a similar change should be made or should be suggested. Setting changes can be suggested or implemented for all or particular ones of the selected networked devices 102 (e.g., (A2), (N1), and (N2)). This guides coordination and provides consistency of settings across similar devices and provides consistency for human actions (e.g., maintenance operations or password changes).”);
and wherein the generating the ECR occurring automatically (Jefferies: ¶ 54 “In an example scenario, when networked device 102(A1) receives a request to change a setting, such as a change to a user credential, an application update, or a maintenance procedure, networked device 102(A1) can determine similar devices of the networked devices 102 for which a similar change should be made or should be suggested. Setting changes can be suggested or implemented for all or particular ones of the selected networked devices 102 (e.g., (A2), (N1), and (N2)). This guides coordination and provides consistency of settings across similar devices and provides consistency for human actions (e.g., maintenance operations or password changes).”; see also ¶ 58-60 “the request can be to delete a particular user from having authorization to log onto similar networked devices 102…the request can be to change a particular setting of system settings… the request can be to change a particular setting of an application used by the networked devices”)
transmitting, using the at least one processor, the ECR to a profile change authorization server configured to regulate changes to the first maintenance profile of the device; and receiving, using the at least one processor and in response to the transmitting, an authorization message from the profile change authorization server authorizing or denying the ECR (see at least Jefferies: ¶ 29 “change to all of the selected devices, or alternatively the change can be suggested to a user and implemented when the suggestion is accepted”; see also Jefferies: ¶ 56-58 “The suggestion can be accepted via a user input device (e.g., touch screen or keypad) of the device that received the suggestion. A user of the networked device 102 (A1) or the central management point can accept or decline a suggestion displayed at its user output device for changing the setting of all or particular ones of the selected networked devices 102 (e.g., (A2), (N1), and (N2))… The user can be removed for all of the selected devices, or alternatively the user removal can be suggested and implemented when the suggestion is accepted”; see also Jefferies: ¶ 55 “A suggestion can be output (e.g., as a displayed as a GUI or textual interface) to the user output device (e.g., display device) associated with the networked device 102(A1) or any of the selected networked devices 102 (e.g., (A2), (N1), and (N2)) or to a user output device of the central management point (e.g., which can be provided as an external component 408 shown in FIG. 4).”).
However Jefferies does not teach Mehr does teach
the generating occurring irrespective of a format in which the first maintenance profile data of the first maintenance profile is arranged within the first maintenance profile (see at least Mehr: Col. 6 Line 42-49 This particular example has a JSON structure, although other types and formats (i.e., CSV) of event logs and other data can be used as well within the scope of the various embodiments; see also Mehr Col. 6 Line 50-54 A naive approach to building a behavioral profile, using event logs with such a data structure, involves flattening the JSON structure and taking each of a set of fields (all or a subset of the fields) as a profile feature)
wherein the second maintenance profile is generated based on the first maintenance profile of the device via: a flattening operation on the first maintenance profile that is configured to preserve a form logic of the format in which the first maintenance profile data of the first maintenance profile is arranged within the first maintenance profile, and editing of the flattened first maintenance profile to generate the second maintenance profile (Mehr, which discloses monitoring, managing, processing, and storing profile information, teaches it is known to analyze a plurality of information using a normalization method and flattening method to process the table and datasets of information related to profiles associated to user’s and devices (see at least Mehr: Col. 2 Line 15-25 “an attempt can be made to normalize the field in order to aggregate the data for that field with data for other fields of that type or having similar aspects .”; see also Mehr: Col. 5 Line 27-52 “Accordingly, approaches in accordance with various embodiments can attempt to improve the accuracy of anomaly detection approaches by, at least in part, looking at the percentage or ratio of mismatch for any feature in a learned behavioral profile in an attempt to intelligently determine which fields to exclude from the profile for the current operation of a specific system or environment. In some embodiments, an anomaly detection system can have a set of built-in normalization methods for common feature types, such as Internet protocol (IP) addresses). These built-in normalizations can be applied to features that were flagged as candidate for exclusion based on the calculated mismatch rate, or another such criterion. For example, if the system notices that a particular field has 50% mismatch rate, the system can apply a normalization to this field to attempt to, for example, view additional data at a higher level or categorization of field type. If the normalizations decreases the mismatch rate to below a specified threshold, then the anomaly detection system can determine to not exclude the feature from the anomaly detection process, and can configure the effective normalization method for ongoing use on the feature-profile. Any exclusion candidate feature which exceeds the threshold even after attempted normalization can be excluded or removed from tracked features of the corresponding profile.”; see also Mehr: Col. 6 Line 31-67 “A naive approach to building a behavioral profile, using event logs with such a data structure, involves flattening the JSON structure and taking each of a set of fields (all or a subset of the fields) as a profile feature. FIG. 4A illustrates an example flattened file 400 including profile features that can be generated using the naive approach. As can be seen from analyzing the example flattened file, there are fields included that, even after baselining, will result in many normal events or actions being flagged as anomalies. For example, the event time value for the eventTime profile field will likely be different for each new event. Similarly, the request and response parameters could take highly variable names in certain systems, such as where each request and response is uniquely identified.”; see also Mehr: Col. 7 Line 58-65 through Col 8 Line 1-58; see also Mehr: Col. 10 Line 1-56; see also Mehr: Col. 6 Line 50-65))
Further, it would have been obvious to one of ordinary skill in the art at the time of filing to apply the known technique of normalizing and flattening profile information from a plurality of formats in order to manage profile information associated to users (as disclosed by Mehr) to the known method and system for autonomously managing device setting request changes wherein user information is processed and managed (as disclosed by Jefferies) to maintain a low false positive rate by only including stable features in a profile while not increasing the anomaly detection miss rate, because the claimed invention is merely applying a known technique to a known method ready for improvement to yield predictable results. In other words, all of the claimed elements were known in the prior art and one skilled in the art could have combined the elements as claimed by known methods with no change in their respective functions, and the combination would have yielded nothing more than predictable results to one of ordinary skill in the art at the time of the invention (i.e., predictable results are obtained by applying the known technique of normalizing and flattening profile information from a plurality of formats in order to manage profile information associated to users to the known method and system for autonomously managing device setting request changes wherein user information is processed and managed to maintain a low false positive rate by only including stable features in a profile while not increasing the anomaly detection miss rate). See also MPEP § 2143(I)(D).
However the combination of Jefferies and Mehr does not teach but Maity does teach:
and the at least one setting configures a frequency of the maintenance operation to be performed on the device (see at least Maity Col. 3 Line 18-35 “In another embodiment, the scheduler module uses the constraint-based scheduler to generate a maintenance schedule for a plurality of items that comprise a plurality of components. Such items may be any type of machine that is made up of components, and that requires maintenance over time, such as a vehicle, an airplane, a helicopter, a tank, or the like. Time-based maintenance information that identifies a first plurality of components of the plurality of components as requiring maintenance, and condition-based maintenance information that identifies a determined condition of a second plurality of components is received. A plurality of constraints associated with performing maintenance on the first plurality of components and the second plurality of components is determined. The scheduler module, based on the time-based maintenance information, the condition-based maintenance information, and the plurality of constraints, uses the constraint-based scheduler to generate a maintenance schedule for the plurality of items”; see also Maity Col. 1 Line 15-26 “Machinery is traditionally serviced at recommended peri odic intervals based on predetermined guidelines. For example, an automobile manufacturer may recommend that the oil be replaced in a vehicle every 7,500 miles. However, under certain conditions, the oil in the vehicle may not actually need replacing at the 7,500 mile interval, while under other conditions; the oil might actually need to be changed at 4,000 miles. In the former situation, the vehicle is taken out of service Sooner than necessary, and costs are expended to replace oil which did not need replacing. In the latter situation, the life of the engine may be compromised because the oil was not replaced as soon as it should have been.”);
one setting configuring the maintenance operation, including the frequency of the maintenance operation (see at least Maity Col. 3 Line 18-35 “In another embodiment, the scheduler module uses the constraint-based scheduler to generate a maintenance schedule for a plurality of items that comprise a plurality of components. Such items may be any type of machine that is made up of components, and that requires maintenance over time, such as a vehicle, an airplane, a helicopter, a tank, or the like. Time-based maintenance information that identifies a first plurality of components of the plurality of components as requiring maintenance, and condition-based maintenance information that identifies a determined condition of a second plurality of components is received. A plurality of constraints associated with performing maintenance on the first plurality of components and the second plurality of components is determined. The scheduler module, based on the time-based maintenance information, the condition-based maintenance information, and the plurality of constraints, uses the constraint-based scheduler to generate a maintenance schedule for the plurality of items”).
Further, it would have been obvious before the effective filing date of the claimed invention, to combine the managing device setting request changes with flattening of Jefferies and Mehr with the constraint based maintenance of Maity because known work in one field of endeavor may prompt variations of it for use in the same field based on design incentives, see MPEP 2143.I.F. That is, one of ordinary skill would have recognized the changes to device settings and maintenance of Jefferies would include many more aspects of maintenance than those disclosed in Jefferies, e.g., the schedule of maintenance as taught by Maity.
Referring to Claims 4, 12, and 20 (substantially similar in scope and language), the combination of Jefferies, Mehr and Maity teaches the method of claim 1, system of claim 9, and non-transitory computer readable medium of claim 17, and Jefferies further teaches:
wherein the at least one setting configures a procedure of the maintenance operation to be performed on the device (see at least Jefferies: ¶ 54 “In an example scenario, when networked device 102(A1) receives a request to change a setting, such as a change to a user credential, an application update, or a maintenance procedure, networked device 102(A1) can determine similar devices of the networked devices 102 for which a similar change should be made or should be suggested. Setting changes can be suggested or implemented for all or particular ones of the selected networked devices 102 (e.g., (A2), (N1), and (N2)). This guides coordination and provides consistency of settings across similar devices and provides consistency for human actions (e.g., maintenance operations or password changes).”; see also ¶ 58-60 “the request can be to delete a particular user from having authorization to log onto similar networked devices 102…the request can be to change a particular setting of system settings… the request can be to change a particular setting of an application used by the networked devices”; see also Jefferies: ¶ 37 “The request can be submitted by a user or the external processing device to change a specified setting of the device settings 106 to a new value Y. In one or more embodiments, the request can specify an original value of the specified setting being changed. Upon receiving a request, a networked device 102 changes its device settings 106 as specified by the request.”; see also Jefferies: ¶ 47 “Examples of device settings 106 includes a user credential (e.g., passwords, authorized user, constraints on authorized users), device system settings (e.g., an update to a simple network time protocol (SNTP) time server address or rapid spanning tree protocol (RSTP) parameters), and application settings (e.g., an updates to a motor protection undercurrent alarm threshold (such as from 80% to 70%), or an update to a motor protection ground current trip function from (such as from an enable setting to a disable setting).”; see also ¶ 58-60 “the request can be to delete a particular user from having authorization to log onto similar networked devices 102…the request can be to change a particular setting of system settings… the request can be to change a particular setting of an application used by the networked devices”; see also Jefferies: ¶ 37 “The request can be submitted by a user or the external processing device to change a specified setting of the device settings 106 to a new value Y. In one or more embodiments, the request can specify an original value of the specified setting being changed. Upon receiving a request, a networked device 102 changes its device settings 106 as specified by the request.”; see also Jefferies: ¶ 47 “Examples of device settings 106 includes a user credential (e.g., passwords, authorized user, constraints on authorized users), device system settings (e.g., an update to a simple network time protocol (SNTP) time server address or rapid spanning tree protocol (RSTP) parameters), and application settings (e.g., an updates to a motor protection undercurrent alarm threshold (such as from 80% to 70%), or an update to a motor protection ground current trip function from (such as from an enable setting to a disable setting).”).
Referring to Claims 5, 13, and 21 (substantially similar in scope and language), the combination of Jefferies, Mehr and Maity teaches the method of claim 1, system of claim 9, and non-transitory computer readable medium of claim 17, and Jefferies further teaches:
wherein the authorization message authorizes the ECR, the method further comprising: activating, using the at least one processor, the second maintenance profile to replace the first maintenance profile as the operative maintenance profile of the device (see at least Jefferies: ¶ 54 “In an example scenario, when networked device 102(A1) receives a request to change a setting, such as a change to a user credential, an application update, or a maintenance procedure, networked device 102(A1) can determine similar devices of the networked devices 102 for which a similar change should be made or should be suggested. Setting changes can be suggested or implemented for all or particular ones of the selected networked devices 102 (e.g., (A2), (N1), and (N2)). This guides coordination and provides consistency of settings across similar devices and provides consistency for human actions (e.g., maintenance operations or password changes).”; see also ¶ 58-60 “the request can be to delete a particular user from having authorization to log onto similar networked devices 102…the request can be to change a particular setting of system settings… the request can be to change a particular setting of an application used by the networked devices”; see also Jefferies: ¶ 37 “The request can be submitted by a user or the external processing device to change a specified setting of the device settings 106 to a new value Y. In one or more embodiments, the request can specify an original value of the specified setting being changed. Upon receiving a request, a networked device 102 changes its device settings 106 as specified by the request.”; see also Jefferies: ¶ 47 “Examples of device settings 106 includes a user credential (e.g., passwords, authorized user, constraints on authorized users), device system settings (e.g., an update to a simple network time protocol (SNTP) time server address or rapid spanning tree protocol (RSTP) parameters), and application settings (e.g., an updates to a motor protection undercurrent alarm threshold (such as from 80% to 70%), or an update to a motor protection ground current trip function from (such as from an enable setting to a disable setting).”; see also ¶ 58-60 “the request can be to delete a particular user from having authorization to log onto similar networked devices 102…the request can be to change a particular setting of system settings… the request can be to change a particular setting of an application used by the networked devices”; see also Jefferies: ¶ 37 “The request can be submitted by a user or the external processing device to change a specified setting of the device settings 106 to a new value Y. In one or more embodiments, the request can specify an original value of the specified setting being changed. Upon receiving a request, a networked device 102 changes its device settings 106 as specified by the request.”; see also Jefferies: ¶ 47 “Examples of device settings 106 includes a user credential (e.g., passwords, authorized user, constraints on authorized users), device system settings (e.g., an update to a simple network time protocol (SNTP) time server address or rapid spanning tree protocol (RSTP) parameters), and application settings (e.g., an updates to a motor protection undercurrent alarm threshold (such as from 80% to 70%), or an update to a motor protection ground current trip function from (such as from an enable setting to a disable setting).”).
Referring to Claim 7, 15, and 23 (substantially similar in scope and language), the combination of Jefferies, Mehr and Maity teaches the method of claim 1, system of claim 9, and non-transitory computer readable medium of claim 17, and Mehr further teaches:
wherein: the format is a tabular format; and the form logic of the first maintenance profile data includes a functional relationship relating fields of the first maintenance profile data in the tabular format (see at least Mehr: Col. 13-14 Lines 57-65 through 1-20).
Further, it would have been obvious to one of ordinary skill in the art at the time of filing to apply the known technique of normalizing and flattening profile information from a plurality of formats in order to manage profile information associated to users (as disclosed by Mehr) to the known method and system for autonomously managing device setting request changes wherein user information is processed and managed (as disclosed by Jefferies) to maintain a low false positive rate by only including stable features in a profile while not increasing the anomaly detection miss rate, because the claimed invention is merely applying a known technique to a known method ready for improvement to yield predictable results. In other words, all of the claimed elements were known in the prior art and one skilled in the art could have combined the elements as claimed by known methods with no change in their respective functions, and the combination would have yielded nothing more than predictable results to one of ordinary skill in the art at the time of the invention (i.e., predictable results are obtained by applying the known technique of normalizing and flattening profile information from a plurality of formats in order to manage profile information associated to users to the known method and system for autonomously managing device setting request changes wherein user information is processed and managed to maintain a low false positive rate by only including stable features in a profile while not increasing the anomaly detection miss rate). See also MPEP § 2143(I)(D).
Referring to Claim 8, 16, and 24 (substantially similar in scope and language), the combination of Jefferies, Mehr and Maity teaches the method of claim 1, system of claim 9, and non-transitory computer readable medium of claim 17, and Mehr further teaches:
wherein the flattening operation includes converting the first maintenance profile data from the format in which the first maintenance profile data of the first maintenance profile is arranged within the first maintenance profile to a JavaScript Object Notation (JSON) file format.
Mehr, which discloses monitoring, managing, processing, and storing profile information, teaches it is known to analyzed a plurality of information using a normalization method and flattening method so process the table and datasets of information related to profiles associated to user’s and devices (see at least Mehr: Col. 6 Line 31-67 “A naive approach to building a behavioral profile, using event logs with such a data structure, involves flattening the JSON structure and taking each of a set of fields (all or a subset of the fields) as a profile feature. FIG. 4A illustrates an example flattened file 400 including profile features that can be generated using the naive approach. As can be seen from analyzing the example flattened file, there are fields included that, even after baselining, will result in many normal events or actions being flagged as anomalies. For example, the event time value for the eventTime profile field will likely be different for each new event. Similarly, the request and response parameters could take highly variable names in certain systems, such as where each request and response is uniquely identified.”; see also Mehr: Col. 7 Line 58-65 through Col 8 Line 1-58; see also Mehr: Col. 10 Line 1-56; see also Mehr: Col. 6 Line 50-65 ).
Further, it would have been obvious to one of ordinary skill in the art at the time of filing to apply the known technique of normalizing and flattening profile information from a plurality of formats in order to manage profile information associated to users (as disclosed by Mehr) to the known method and system for autonomously managing device setting request changes wherein user information is processed and managed (as disclosed by Jefferies) to maintain a low false positive rate by only including stable features in a profile while not increasing the anomaly detection miss rate, because the claimed invention is merely applying a known technique to a known method ready for improvement to yield predictable results. In other words, all of the claimed elements were known in the prior art and one skilled in the art could have combined the elements as claimed by known methods with no change in their respective functions, and the combination would have yielded nothing more than predictable results to one of ordinary skill in the art at the time of the invention (i.e., predictable results are obtained by applying the known technique of normalizing and flattening profile information from a plurality of formats in order to manage profile information associated to users to the known method and system for autonomously managing device setting request changes wherein user information is processed and managed to maintain a low false positive rate by only including stable features in a profile while not increasing the anomaly detection miss rate). See also MPEP § 2143(I)(D).
Referring to Claim 25, 27, and 29 (substantially similar in scope and language), the combination of Jefferies, Mehr and Maity teaches the method of claim 1, system of claim 9, and non-transitory computer readable medium of claim 17, and Maity further teaches:
wherein the at least one setting configures a duration of the maintenance operation to be performed on the device (see at least Maity Col. 10 Lines 27-36 “The output from the constraint-based scheduler 24 may include the maintenance schedule, an identification of the parts to be used, the identification of the maintainers who have been scheduled, and the like. The maintenance schedule may identify, for example, for each of the components, a start time of a corresponding maintenance task, an end time of the corresponding maintenance task, a particular maintainer of a plurality of maintainers for performing the corresponding maintenance task, the facility at which the task is to be performed, and the like”).
Further, it would have been obvious before the effective filing date of the claimed invention, to combine the managing device setting request changes with flattening of Jefferies and Mehr with the constraint based maintenance of Maity because known work in one field of endeavor may prompt variations of it for use in the same field based on design incentives, see MPEP 2143.I.F. That is, one of ordinary skill would have recognized the changes to device settings and maintenance of Jefferies would include many more aspects of maintenance than those disclosed in Jefferies, e.g., the start and end times as taught by Maity.
Referring to Claim 26 and 28 (substantially similar in scope and language), the combination of Jefferies, Mehr and Maity teaches the method of claim 1, system of claim 9, and non-transitory computer readable medium of claim 17, and Maity further teaches:
wherein the at least one setting configures a location of the maintenance operation to be performed on the device (see at least Maity Col. 6 Lines 43-57 “The scheduler module 22 also receives constraints associated with providing maintenance of the machines 12, or com ponents thereof. Constraints include any data that identifies a parameter within which the maintenance is to be performed. Constraints can include, for example, the number of available maintainers, the available maintainers who have a qualification status Sufficient to perform the maintenance tasks, the work schedule of the available maintainers and work restrictions associated therewith (Such as a certain maximum number of hours in a day or hours already worked during the week), the number and location of facilities for performing the maintenance, the time frames during which Such facilities may be available, precedence constraints identifying a necessary order of maintenance when multiple components are being serviced, and the like”).
Further, it would have been obvious before the effective filing date of the claimed invention, to combine the managing device setting request changes with flattening of Jefferies and Mehr with the constraint based maintenance of Maity because known work in one field of endeavor may prompt variations of it for use in the same field based on design incentives, see MPEP 2143.I.F. That is, one of ordinary skill would have recognized the changes to device settings and maintenance of Jefferies would include many more aspects of maintenance than those disclosed in Jefferies, e.g., location information as taught by Maity.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to BRENDAN S O'SHEA whose telephone number is (571)270-1064. The examiner can normally be reached Monday to Friday 10-6.
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, Nathan Uber can be reached at (571) 270-3923. 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.
/BRENDAN S O'SHEA/Examiner, Art Unit 3626