DETAILED ACTION
This is a Request for continued Examination (RCE) filed on December 31 2025.
Claims 1, 8 and 15 are currently amended.
Claims 2-7, 9-11, 12-14, 16-18, 19-21 are originals.
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 .
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-21 are rejected under 35 U.S.C. 101 because the claimed invention is directed to a judicial exception without significantly more.
Step 1 (The Statutory Categories): Is the claim to a process, machine, manufacture, or composition of matter? MPEP 2106.03.
Per Step 1, claim 1-7 to a method (i.e., a process), claim 8-14 is to a system (i.e., a machine), and claim 15-21 to a non-transitory computer-readable medium (i.e., a manufacture or machine). Thus, the claims are directed to statutory categories of invention. However, the claims are rejected under 35 U.S.C. 101 because they are directed to an abstract idea, a judicial exception, without reciting additional elements that integrate the judicial exception into a practical application.
The analysis proceeds to Step 2A Prong One.
Step 2A Prong One: Does the claim recite an abstract idea, law of nature, or natural phenomenon? MPEP 2106.04.
The abstract idea of claim 1, 8 and 15 are:
A method comprising: (Claim 1; being representative)
A system comprising: at least one computer-readable medium storing computer-executable instructions; and at least one processor configured to execute the computer executable instructions to cause the system to perform operations comprising: (Claim 8)
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 which, when executed by the at least one processor, cause the system to perform operations comprising: (Claim 15)
requesting, using at least one processor of a device maintenance server, at least one change in a configuration or setting of a maintenance operation of a device to be performed on the device;
retrieving, using the at least one processor, a first maintenance profile of the device that is an operative maintenance profile of the device and includes first maintenance profile data configuring the maintenance operation to be performed on the device;
performing, using the at least one processor, a flattening operation on the first maintenance profile configured to preserve a characteristic of a format of a data structure in which the first maintenance profile data is arranged within the first maintenance profile,
wherein a file format of the flattened first maintenance profile differs from the format of the data structure in which the first maintenance profile data is arranged;
editing, using the at least one processor, the flattened first maintenance profile, to include the at least one change in the configurations or settings of the maintenance operation requested in the request from the device maintenance server;
generating, using the at least one processor, a second maintenance profile of the device based on the edited flattened first maintenance profile, the second maintenance profile having second maintenance profile data that is (i) different from the first maintenance profile data, and
(ii) configured to change the configuration of the maintenance operation;
and transmitting, using the at least one processor, the second maintenance profile to cause generation of 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 performing the flattening operation and generating the second maintenance profile occur automatically irrespective of the format in which the first maintenance profile data is arranged within the first maintenance profile.
The abstract idea steps italicized above are those which could be performed mentally, including with pen and paper. The steps describe, generating a request in the form of an electronic device change request, the request is analyzed by the system to update the stored profile information. If a claim limitation, under its broadest reasonable interpretation, covers performance of the limitation in the mind, including observations, evaluations, judgements, and/or opinions, then it falls within the Mental Processes – Concepts Performed in the Human Mind grouping of abstract ideas. Accordingly, the claim recites an abstract idea.
Step 2A Prong Two: Does the claim recite additional elements that integrate the judicial exception into a practical application? MPEP 2106.04.
This judicial exception is not integrated into a practical application because the additional elements are merely instructions to apply the abstract idea to a computer, as described in MPEP 2106.05(f).
Claim 1, 8, and 15 recites the following additional elements: a processor of a computer, computer-readable medium, non-transitory computer readable medium. device maintenance server, a flattening operation, data structure, device maintenance server, and electronic change request (ECR).
These elements are merely instructions to apply the abstract idea to a computer, per MPEP 2106.05(f). Applicant has only described generic computing elements in their specification, as seen in [0005] of applicant’s specification as filed, for example.
Further, the combination of these elements is nothing more than a generic computing system applied to the tasks of the abstract idea. Because the additional elements are merely instructions to apply the abstract idea to a generic computing system, they do not integrate the abstract idea into a practical application, when viewed in combination. See MPEP 2106.05(f).
Therefore, per Step 2A Prong Two, the additional elements, alone and in combination, do not integrate the judicial exception into a practical application. The claim is directed to an abstract idea.
Step 2B (The Inventive Concept): Does the claim recite additional elements that amount to significantly more than the judicial exception? MPEP 2106.05.
Step 2B involves evaluating the additional elements to determine whether they amount to significantly more than the judicial exception itself.
The examination process involves carrying over identification of the additional element(s) in the claim from Step 2A Prong Two and carrying over conclusions from Step 2A Prong Two pertaining to MPEP 2106.05(f).
The additional elements and their analysis are therefore carried over: applicant has merely recited elements that facilitate the tasks of the abstract idea, as described in MPEP 2106.05(f).
Further, the combination of these elements is nothing more than a generic computing system. When the claim elements above are considered, alone and in combination, they do not amount to significantly more.
Therefore, per Step 2B, the additional elements, alone and in combination, are not significantly more. The claims are not patent eligible.
The analysis takes into consideration all dependent claims as well:
Dependent claims 2-4, 6-7, 9-11,13-14, 16-18 and 20-21 contain additional steps that further narrow the abstract idea above.
Claim 2, 3, 9, 10, 16 and 17 recites the following additional elements: flattening operation and JavaScript Object Notation (JSON) file format. Applicant has only described generic computing elements in their specification, as seen in {[0034]} of applicant’s specification as filed. This does not integrate the abstract idea into practical and/or add significantly more. The claim is ineligible. Refer to MPEP 2106.05(F).
Claim 4, 6, 11, 13, 18 and 20 recites the following additional elements: data structure, processor, the flattened first maintenance profile. Applicant has only described generic computing elements in their specification, as seen in {[0007]} of applicant’s specification as filed. This does not integrate the abstract idea into practical and/or add significantly more. The claim is ineligible. Refer to MPEP 2106.05(F).
Claim 7, 14 and 21 recites the following additional elements: Electronic Change Request (ECR). Applicant has only described generic computing elements in their specification, as seen in {[0007]} of applicant’s specification as filed. This does not integrate the abstract idea into practical and/or add significantly more. The claim is ineligible. Refer to MPEP 2106.05(F).
Dependent claim 7, 14 and 21 further describes the abstract idea. Claim 7, 14 and 21 are based on the claims describing a mental process of requesting, retrieving and transmitting an Electronic Change Request (ECR). See applicants’ specification {[0024]} for further details. The Electronic Change Request (ECR) is merely a generic technology to manage and change configurations or parameters of maintenance operations that are to be performed on a device. The ECR is not a technical improvement and merely implementing the abstract idea using generic technology. As such additional elements are not significantly more or transformative into a practical application. MPEP 2106.05(F). Therefore, the claims are covered under certain methods of mental process groupings of abstract ideas.
In conclusion the claims do not provide an inventive concept, because the claims do not recite additional elements or a combination of elements that amount to significantly more than the judicial exception of the claims. Therefore, whether taken individually or as an order combination, the claims are nonetheless rejected under 35 U.S.C. 101 as being directed to non-statutory subject matter.
Accordingly, claims 1-21 are rejected under 35 USC § 101 as being directed to non-statutory subject matter.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claim(s) 1-21 are rejected under 35 U.S.C. 103 as being unpatentable over Jefferies et al [US2022/0103549], hereafter Jefferies in view of Mehr et al [US10542021] hereafter, Mehr.
As per claim 1, 8 and 15 (Similar scope and language)
Jefferies discloses:
Method and a system comprising: at least one computer-readable medium storing computer-executable instructions; and at least one processor configured to execute the computer executable instructions to cause the system to perform operations comprising: (Claim 8):
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 which, when executed by the at least one processor, cause the system to perform operations comprising: (Claim 15):
requesting, using at least one processor of a device maintenance server, at least one change in a configuration or setting of a maintenance operation of a device to be performed on the device;
{[0020] A further aspect of the disclosure provides a non-transitory computer readable storage medium having one or more computer programs embedded therein, which when executed by a computer system, cause the computer system to receive a request to update a device setting of a device of a plurality of networked devices to a new value, autonomously compare a characteristic of the plurality of networked devices to a corresponding characteristic of the device, autonomously determine one or more similar devices of the plurality of devices that satisfy a similarity criteria based on a result of the comparison, and autonomously access the one or more similar devices to change the device setting of the one or more similar devices to the new value.
[0054] 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).}
Jefferies discloses;
retrieving, using the at least one processor, a first maintenance profile of the device that is an operative maintenance profile of the device and includes first maintenance profile data configuring the maintenance operation to be performed on the device;
{[0054] 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).
[0037] At least a portion of the networked devices 102 includes an interface (as shown in FIG. 5) for receiving a request. The interface can be coupled with an external processing device for receiving requests from the processing device or can be coupled with a user input and/or output device (e.g., keypad, touchscreen, etc.) and utilize a user interface (shown in FIG. 5) for receiving requests from a user. The user interface can support a textual or graphical user interface (GUI). 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.}
Jefferies discloses;
performing, using the at least one processor, a flattening operation on the first maintenance profile configured to preserve a characteristic of a format of a data structure in which the first maintenance profile data is arranged within the first maintenance profile,
{[0034] FIG. 1 further shows a plurality of networked devices 102 that are configured to communicate with one another and to store and process information. Networked devices 102 can be, for example and without limitation, embedded devices, smart devices (mobile or stationary) or, computers (e.g., servers or laptop or desktop computers). The networked devices 102 can include different types of devices that serve different purposes, also referred to as heterogeneous devices. Each networked device 102 stores characteristics data 104 that defines the type of the networked device 102. In an example application, networked devices 102 are a variety of different types of industrial control devices, such as motor controllers, motion controllers, machine drives, and/or switches. The characteristic data 104 can include, for example, identification of the networked device's manufacturer and model. In one or more embodiments, the characteristic data 104 can include user settings, such as identification of a group to which the networked device 102 belongs or a site at which the networked device 102 is located.}
Jefferies discloses;
generating, using the at least one processor, a second maintenance profile of the device based on the edited flattened first maintenance profile, the second maintenance profile having second maintenance profile data that is (i) different from the first maintenance profile data, and (ii) configured to change the configuration of the maintenance operation; and
{[0054] 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).
[0058 – 0060] the request can be to delete a particular user from having authorization to log onto similar networked devices 102…. In one scenario, 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 102.
[0037] 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.}
Jefferies discloses;
transmitting, using the at least one processor, the second maintenance profile to cause generation of 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,
{[0054] 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).
[0037] 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.}
Jefferies discloses;
wherein performing the flattening operation and generating the second maintenance profile occur automatically irrespective of the format in which the first maintenance profile data is arranged within the first maintenance profile.
{[0061] FIG. 3 shows an exemplary and non-limiting flowchart 300 illustrating a method for automatically adjusting a device setting of a plurality devices, in accordance with certain illustrated embodiments.
[0054] 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).}
Jefferies discloses the configuration of the processor, but does not teach the flattening operation of the system, however Mehr discloses the flattening operation, Mehr discloses;
Flattening operation
{[Col. 6 Line 50-63] 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.}
Motivation: It would have been obvious to a person of ordinary skill in the art, before the effective filing date of the claimed invention, to combine/modify/adjust Jefferies’s modification of maintenance profiles to include Mehr et al’s Flattening operation, since Jefferies teaches receiving a request to automatically adjust, update and change device setting, maintenance procedure, delete a particular user from having authorization to log onto similar networked devices (See Jefferies [0020, 0054, 0034, 0037, and 0058-0061]). The combination would have been obvious to one ordinary skill in the art to modify Jefferies to include using event logs with such a data structure, with flattening the JSON structure and taking each of a set of fields (all or a subset of the fields) as a profile feature. Generating the flattened profile using naive approach to enable analyzing the flattened file and detection of anomalies. See Mehr [Col. 6 Line 50-63].
Mehr discloses;
wherein a file format of the flattened first maintenance profile differs from the format of the data structure in which the first maintenance profile data is arranged; editing, using the at least one processor, the flattened first maintenance profile, to include the at least one change in the configurations or settings of the maintenance operation requested in the request from the device maintenance server;
{[Col. 6 Line 50 – Col. 7. Line 6] 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. As mentioned, one approach to addressing this issue would be to utilize the manual work and knowledge of an engineer about the event logs to only include features in the behavioral profile which are most likely going to be stable after baselining. Using such a simplistic approach, however, can increase the detection miss rate even through the number of false positives would likely decrease. Thus, it can be desirable to implement an approach that can maintain a low false positive rate by only including stable features in a profile while not increasing the anomaly detection miss rate.}
Motivation: It would have been obvious to a person of ordinary skill in the art, before the effective filing date of the claimed invention, to combine/modify/adjust Jefferies’s modification of maintenance profiles to include Mehr et al’s difference in file format of the flattened first maintenance profile of the data structure in which the first maintenance profile data is arranged, editing the flattened first maintenance profile, to include the at least one change in the configurations or settings of the maintenance operation requested in the request from the device maintenance server, since Jefferies teaches receiving a request to automatically adjust, update and change device settings, maintenance procedure, delete a particular user from having authorization to log into a similar networked device (See Jefferies [0020, 0054, 0034, 0037, and 0058-0061]), The combination would have been obvious to one ordinary skill in the art to modify Jefferies to include using event logs in the data structure, with flattening the JSON structure, taking each of a set of fields as a profile feature, generating the flattened profile using a naive approach, including a behavioral profile and stable features to maintain a low false positive rate in a profile while not increasing the anomaly detection miss rate. See Mehr [Col. 6 Line 50 – Col. 7. Line 6].
As per claim 2, 9 and 16 (Similar scope and language);
Mehr discloses;
The method of claim 1, wherein the data structure is a table and the format is a tabular format, the flattening operation including converting the first maintenance profile data from the tabular format to a JavaScript Object Notation (JSON) file format.
{[Col. 6 Line 50-63] 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.}
Motivation: It would have been obvious to a person of ordinary skill in the art, before the effective filing date of the claimed invention, to combine/modify/adjust Jefferies’s modification of maintenance profiles to include Mehr et al’s Flattening operation, since Jefferies teaches receiving a request to automatically adjust, update and change device setting, maintenance procedure, delete a particular user from having authorization to log onto similar networked devices (See Jefferies [0020, 0054, 0034, 0037, and 0058-0061]). The combination would have been obvious to one ordinary skill in the art to modify Jefferies to include using event logs with such a data structure, with flattening the JSON structure and taking each of a set of fields (all or a subset of the fields) as a profile feature. Generating the flattened profile using naive approach to enable analyzing the flattened file and detection of anomalies. See Mehr [Col. 6 Line 50-63].
As per claim 3, 10, 17 (Similar scope and language);
Mehr discloses;
The method of claim 2, wherein the generation of the second maintenance profile includes editing the converted first maintenance profile data in the JSON file format to generate the second maintenance profile data that is different from the first maintenance profile data.
{[Col. 6 Line 50-63] 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.}
Motivation: It would have been obvious to a person of ordinary skill in the art, before the effective filing date of the claimed invention, to combine/modify/adjust Jefferies’s modification of maintenance profiles to include Mehr et al’s Flattening operation, since Jefferies teaches receiving a request to automatically adjust, update and change device setting, maintenance procedure, delete a particular user from having authorization to log onto similar networked devices (See Jefferies [0020, 0054, 0034, 0037, and 0058-0061]). The combination would have been obvious to one ordinary skill in the art to modify Jefferies to include using event logs with such a data structure, with flattening the JSON structure and taking each of a set of fields (all or a subset of the fields) as a profile feature. Generating the flattened profile using naive approach to enable analyzing the flattened file and detection of anomalies. See Mehr [Col. 6 Line 50-63].
As per claim 4, 11 and 18 (Similar scope and language);
Jefferies discloses;
The method of claim 1, wherein the data structure is a first table, the method further comprising storing, using the at least one processor,
{[0039-0040] The autonomous comparison performed by networked device 102 (A1) can include discovering as needed and sending a query to each of the networked devices 102 for their characteristic data 104. The characteristic data 104 can be provided in a field stored by the respective networked devices 102. Upon receiving the characteristic data 104 from networked devices 102, networked device 102 (A1) compares its characteristic data 104 to the received characteristic data 104.}
Mehr discloses the specific function and structure of the first and second table, Mehr discloses;
the flattened first maintenance profile and the second maintenance profile in a second table that is separate from, but references, the first table.
{[Col. 6 Line 63 – Col. 7 Line 6] As mentioned, one approach to addressing this issue would be to utilize the manual work and knowledge of an engineer about the event logs to only include features in the behavioral profile which are most likely going to be stable after baselining. Using such a simplistic approach, however, can increase the detection miss rate even through the number of false positives would likely decrease. Thus, it can be desirable to implement an approach that can maintain a low false positive rate by only including stable features in a profile while not increasing the anomaly detection miss rate.
Motivation: It would have been obvious to a person of ordinary skill in the art, before the effective filing date of the claimed invention, to combine/modify/adjust Jefferies’s modification of maintenance profiles to include Mehr et al’s flattened first maintenance profile and the second maintenance profile in a second table that is separate from, but references, the first table, since Jefferies teaches data structure is a first table, the method further comprising storing (See Jefferies [0039-0040]). The combination would have been obvious to one ordinary skill in the art to modify Jefferies to include manually editing the event logs to include features in the behavioral profile which are most likely going to be stable after baselining to enable the detection and tracking of an anomaly. See Mehr [Col. 6 Line 50 – Col. 7. Line 6].
As per claim 5, 12 and 19 (Similar scope and language);
Jefferies discloses;
The method of claim 1, wherein the configuration of the maintenance operation includes a frequency and/or a procedure of the maintenance operation.
{[0037] 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.
[0059] In one scenario, the request can be to change a particular setting of system settings. The similar devices can be all networked devices 102 that have a particular manufacturer, model, or are assigned to a particular group. The selected devices can be networked devices 102 for which the setting is set to an expected value at the time the request is received, wherein the setting value can be the same setting value for which the networked device 102 (A1) that received the request is configured or a value provided by the request. The setting value can be changed to a requested setting value for all of the selected devices, or alternatively the change can be suggested and implemented when the suggestion is accepted.}
As per claim 6, 13, 20 (Similar scope and language);
Mehr discloses;
The method of claim 1, wherein the characteristic of the format includes a form logic and/or a field type of the data structure.
{[Col. 13, Line 59 – Col. 14, Line 11] In embodiments utilizing a Web server, the Web server can run any of a variety of server or mid-tier applications, including HTTP servers, FTP servers, CGI servers, data servers, Java servers and business application servers. The server(s) may also be capable of executing programs or scripts in response requests from user devices, such as by executing one or more Web applications that may be implemented as one or more scripts or programs written in any programming language, such as Java®, C, C# or C++ or any scripting language, such as Perl, Python or TCL, as well as combinations thereof. The server(s) may also include database servers, including without limitation those commercially available from Oracle®, Microsoft®, Sybase® and IBM® as well as open-source servers such as MySQL, Postgres, SQLite, MongoDB, and any other server capable of storing, retrieving and accessing structured or unstructured data. Database servers may include table-based servers, document-based servers, unstructured servers, relational servers, non-relational servers or combinations of these and/or other database servers.}
Motivation: It would have been obvious to a person of ordinary skill in the art, before the effective filing date of the claimed invention, to combine/modify/adjust Jefferies’s modification of maintenance profiles to include Mehr et al’s characteristics of the format includes a form logic and/or a field type of the data structure, since Jefferies teaches the configuration of the maintenance operation includes a frequency and/or a procedure of the maintenance operation. (See Jefferies [0037-0059]). The combination would have been obvious to one ordinary skill in the art to modify Jefferies to include the server(s) that are capable of executing programs or scripts in response to requests from user devices, such as by executing one or more Web applications that may be implemented as one or more scripts or programs written in any programming language, such as Java®, C, C# or C++ or any scripting language, such as Perl, Python or TCL. The server(s) may also include database servers, including without limitation those commercially available from Oracle®, Microsoft®, Sybase® and IBM® as well as open-source servers such as MySQL, Postgres, SQLite, MongoDB, to enable the storage, maintenance and running of variety of devices. See Mehr [Col. 13, Line 59 – Col. 14, Line 11].
As per claim 7, 14, and 21 (Similar scope and language);
Jefferies discloses;
The method of claim 1, wherein the operative maintenance profile of the device is configured to be unmodifiable without approval of the ECR by a profile change authorization system configured to regulate modifications to the operative maintenance profile of the device.
{[0029] The device that received the request can propagate the password change to all of the selected devices, or alternatively the change can be suggested to a user and implemented when the suggestion is accepted.
[0056] 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)). A user of any of the selected networked devices 102 (e.g., (A2), (N1), and (N2)) can accept or decline the suggestion displayed at its user output device for changing its own setting.}
Response to Arguments
In response to the argument filled December 31, 2025 on pages 11 – 13 regarding the 101 rejections, the Examiner Respectfully disagree.
Applicant argues that the claims do not recite a certain method of organizing human activity, mathematical and mental concepts and an abstract idea because “the retrieving of the first maintenance profile, flattening the first maintenance profile, and generating a second maintenance profile based on the edited flattened first maintenance profile with a change in configuration cannot be practically performed in the human mind”.
The Examiner respectfully disagrees.
Examiner notes that the system is directed to a Mathematical concept and a mental process which is directed to a certain method of organizing human activity groupings of abstract idea.
The courts consider a mental process (thinking) that "can be performed in the human mind, or by a human using a pen and paper" to be an abstract idea. CyberSource Corp. v. Retail Decisions, Inc., 654 F.3d 1366, 1372, 99 USPQ2d 1690, 1695 (Fed. Cir. 2011). As the Federal Circuit explained, "methods which can be performed mentally, or which are the equivalent of human mental work, are unpatentable abstract ideas the ‘basic tools of scientific and technological work’ that are open to all.’" 654 F.3d at 1371, 99 USPQ2d at 1694 (citing Gottschalk v. Benson, 409 U.S. 63, 175 USPQ 673 (1972)). See also Mayo Collaborative Servs. v. Prometheus Labs. Inc., 566 U.S. 66, 71, 101 USPQ2d 1961, 1965 (2012) ("*[M]ental processes [] and abstract intellectual concepts are not patentable, as they are the basic tools of scientific and technological work’" (quoting Benson, 409 U.S. at 67, 175 USPQ at 675)); Parker v. Flook, 437 U.S. 584, 589, 198 USPQ 193, 197 (1978) (same).
Applicant argues that by applying maintenance profile, updating schema, greatly improves the authorization requesting process. Applicant also submits that claim 1 demonstrates an improvement to existing technology (e.g., maintenance profile requests and updating) and therefore integrates a judicial exception into a practical application. Applicant recites: “Some advantages of these techniques include the capability to generate requests to update device maintenance profiles in an efficient and scalable manner with little or no user input. In particular, maintenance profiles that may have different formats and data structures therein can be ingested into the request generator system irrespective of the formats and form of the data structures, and the requests can be generated automatically without prior input by a user, allowing the authorization requesting process to be highly scalable and efficient. See specification [0018].
The Examiner respectfully disagrees.
The Examiner notes that the specification quoted above asserts advantages of a device maintenance profile that is capable of updating, format ingestion and automatic generating of scalable and efficient request. However, the claims does not describe a technical solution, such as the form logic during flattening operation; instead, the claim only shows the desired outcome of preserving the format. See Applicant specification [0034] and [0037].
Applicant argues that the claims provide an improvement to the functioning of a computer or another technology and therefore are integrated into a practical application.
The Examiner respectfully disagrees. The Flattening operation and the Electronic Change Request (ECR) in the specification used in the generation of a second maintenance profile are merely generic technology with no technical improvement but rather an improvement to the abstract idea using generic technology. See Applicant specification [0005].
The examiner maintains these claims recite an abstract idea.
Therefore, for the foregoing reasons the Examiner has maintained the 35 USC 101 rejection.
Regarding the prior art rejection, on page 14-15, the Examiner respectfully disagrees.
Applicant argues that the prior art of record fails to teach the claims specifically the claim limitations: a flattening operation on the first maintenance profile, where a file format of the flattened first maintenance profile differs from the format of the data structure in which the first maintenance profile data is arranged, and editing, using the at least one processor, the flattened first maintenance profile, to include the at least one change in the configurations or settings of the maintenance operation requested in the request from the device maintenance server
The Examiner respectfully disagrees.
Examiner notes that Mehr teaches a flattening operation on the first maintenance profile, where a file format…... See Mehr {[Col. 6 Line 50 – Col. 7. Line 6]}.
The Applicant further argued that the prior art fails to disclose the editing and the flattened first maintenance profile.
The Examiner respectfully disagrees.
The Examiner notes that the prior art of Jefferies teaches receiving a request to automatically adjust, update and change device setting, maintenance procedure, delete a particular user from having authorization to log onto similar networked devices (See Jefferies [0020, 0054, 0034, 0037, and 0058-0061]).
In terms of the arguments Jefferies and Mehr does teach specific limitations as amended because the art teaches a generation of a system, setting and configurations of maintenance operations, flattened first maintenance profile, the second maintenance profile having second maintenance profile as stated above.
Based on the considered amendments cited, 35 USC 103 references have been utilized to
teach the claimed invention (claim 1-21).
Lacking any further argument, claims 1-21 are maintaining the 35 USC 103 rejection, as considered above in light of the amended claim limitation above.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure:
Garrow et al; [US7457763B1], discloses a method and system for maintaining equipment support, the provision of predictive maintenance in a manner which eliminates and reduces downtime of the equipment. Tracking performance data on the equipment, having at least one required maintenance activity predicted based upon the performance data with respect to a defined performance standard.
V. Tewari, S. Al Sufi, S. Benet and C. Park, "Predictive Modeling of Surface Flashover Using Deep Learning," 2024 IEEE Transportation Electrification Conference and Expo (ITEC), Chicago, IL, USA, 2024, pp. 1-6,
Any inquiry concerning this communication or earlier communications from the examiner should be directed to VICTOR CHIGOZIRIM ESONU whose telephone number is (571)272-4883. The examiner can normally be reached Monday - Friday 9:00 am - 5pm.
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, SARAH MONFELDT can be reached on (571) 270-1833. 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, vis it: 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.
/VICTOR CHIGOZIRIM ESONU/
Examiner, Art Unit 3629