DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Priority
Acknowledgment is made of applicant’s claim for foreign priority under 35 U.S.C. 119 (a)-(d). The certified copy has been filed in parent Application No. JP2023-107293, filed on 06/29/2023.
This office action is responsive to a response filed on January 29th, 2026. In this office action:
Claims 1-11 are pending.
Claims 1-11 are rejected.
Summary of Previous Office Action
In the Non-Final Office Action mailed on November 5th, 2025:
Claims 6-7 were objected to because of the informalities.
Claims 3, 6, and 8 were rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite.
Claims 1-10 were rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more.
Claims 1-2 and 4-10 were rejected under 35 U.S.C. 102 (a)(1) as being anticipated by Tiwari et al. (Pub. No. US 2022/0114041), hereinafter Tiwari.
Claim 3 was rejected under 35 U.S.C. 103 as being unpatentable over Tiwari et al. (Pub. No. US 2022/0114041), hereinafter Tiwari; in view of Kaffine et al. (Patent No. US 6,654,914), hereinafter Kaffine.
Response to Amendment
The amendments filed on January 29th, 2026 have been entered.
Claims 1-3 and 6-10 have been amended.
Claim 11 has been added.
The previously raised claim objections for claims 6-7 are withdrawn by the Examiner in light of the amendments.
The previously raised 35 U.S.C. 112(b) rejection for claims 3, 6, and 8 is withdrawn by the Examiner in light of the amendments.
Response to Arguments
Applicant’s Arguments/Remarks, filed on January 29th, 2026, have been fully considered by the Examiner, but they are not persuasive.
Regarding Applicant’s “Response to Rejection Under 35 U.S.C. § 101” in Pages 6-8, the Examiner respectfully disagrees.
Applicant’s Arguments 1: "acquire operation information including error information received from the network device via a communication interface" - This is hardware-level communication with a network device, which cannot be performed mentally.
Examiner’s response: The “acquire” operation information … is reasonably interpreted by the Examiner as gathering/collecting data. The claim does not provide any details on the gathered data. Under its broadest reasonable interpretation when read in light of the specification, the claimed “acquire” operation information encompasses gathering data.
Applicant’s Arguments 2: "estimate an action to be executed for the error occurring in the network device based on the received error information and stored error history" - This involves algorithmic processing of device-specific historical data, beyond human mental capability.
Examiner’s response: The “estimate” is reasonably interpreted by the Examiner as making a judgment. Under its broadest reasonable interpretation when read in light of the specification, the claimed “estimate” encompasses making a judgement.
Applicant’s Arguments 3: "determine whether the estimated action to be executed for the error occurring in the network device is a remotely executable action that is able to be performed by remotely transmitting a command to a target network device via a network" - Comparing device identifiers and action details with remote execution capability data stored in memory.
Examiner’s response: The “determine” is reasonably interpreted by the Examiner as making a judgment. Under its broadest reasonable interpretation when read in light of the specification, the claimed “determine” encompasses making a judgement.
Applicant’s Arguments 4: "provide data for outputting information of candidates estimated as the action to be executed for the error occurring in the network device, wherein, when the remotely executable action is included in the candidates, data for outputting information indicating that a remote job is recommended is included in the provided data" - This generates structured output data tied to actionable device repair.
Examiner’s response: The “provide data” is reasonably interpreted by the Examiner as making an opinion. Under its broadest reasonable interpretation when read in light of the specification, the claimed “provide data” encompasses making an opinion. In addition, the wherein clause further defines data for outputting information indicating that a remote job is recommended, which does not integrate the abstract idea into a practical application because it does not impose any meaningful limits on practicing the abstract idea.
In response to Applicant’s argument that “These steps are not mental processes or generic data manipulation. They recite a specific machine and involve technical interactions with a network device and stored databases to automate troubleshooting and enable remote repair,” it is noted that even mental processes which may need the physical aids such as pen and paper can be still mental processes (see MPEP §2106.04(a)(2)(III)(B)) and even the fact that the claimed invention is performing steps on a computer does not prevent the function from being a mental process (see MPEP §2106.04(a)(2)(III)(C)). As result, the limitation recites a mental process.
Examiner’s response to “Traversal Claim Rejections under 35 U.S.C. 102 and 103” in Pages 8-10 in Applicant’s Arguments/Remarks”:
1/ In response to Applicant’s argument that “Tiwari does not disclose using historical error data from the same device or correlating past error occurrences to estimate actions, and while Tiwari references historical data for clustering incidents and determining a cause with a confidence level, Tiwari does not disclose using stored error history as the basis for estimating actions to be executed for the device's error as claimed,” the Examiner respectfully disagrees.
Tiwari discloses estimate an action to be executed for the error occurring in the network device based on the received error information and stored error history (See Parag. [0034-0035]; [T]he fault mitigation device 110 may evaluate the received alarm message to perform a root cause analysis. The root cause analysis may result in identification of a parent or primary alarm. Once the parent or primary alarm is identified, the parameters included in the alarm message may be evaluated against the model to determine one or more candidate actions that may be performed to resolve the issues related to the alarm message. For example, an artificial intelligence process may analyze the model using a nearest neighbor algorithm to find historical network incidents corresponding to the parameters of the alarm message, as described above. Actions corresponding to the historical network incidents identified by the artificial intelligence process may then be identified, such as by retrieving the actions for the historical network incidents from an actions database (e.g., one of the one or more databases 124) that includes information associated with actions taken to resolve the alarms corresponding to the historical network incidents. The set of actions may represent a set of candidate actions that may be performed to resolve the network incident that triggered generation of the alarm message … A score may be determined for each of the one or more candidate actions, where the score represents a likelihood that a particular candidate action will resolve the cause of the alarm message).
In addition, Tiwari discloses acquire operation information including error information received from the network device via a communication interface (See Parag. [0045] and Fig. 4; The fault data 402 may be an alarm message, as described above with reference to FIG. 1 and may be received from a node of a network (e.g., one of the nodes 132, 134, 136, 138 of the one or more networks 130 of FIG. 1), from a device supported by the network (e.g., one of the other devices 150 of FIG. 1 or the user device 140 of FIG. 1, such as a user's smartphone device). See Parag. [0019-0020]; The fault mitigation device 110 includes one or more input/output (I/O) devices 118 ... the I/O devices 118 may include one or more communication interfaces configured to communicatively couple the fault mitigation device 110 to the one or more networks 130 ...), as amended.
2/ In response to Applicant’s argument that “Tiwari fails to teach the feature "remotely executable action that is able to be performed by remotely transmitting a command to a target network device via a network," of Claim 1,” the Examiner respectfully disagrees.
Tiwari disclose, in Parag [0038], that the fault mitigation device 110 may be configured to categorize the network incident associated with the alarm prior to transmitting a notification to the user device 140 or automatically executing any candidate actions ... [t]he self-healable known issues category may be used for network incidents associated with recurring issues in the network for which a resolution is known and may be executed remotely (e.g., without having to physically be present at the node of the network), which is reasonably interpreted to be equivalent to the claimed “determine whether the estimated action to be executed for the error occurring in the network device is a remotely executable action that is able to be performed by remotely transmitting a command to a target network device via a network.” In addition, the execution of a candidate action remotely is equivalent to “transmitting a command to a target network device via a network.”
3/ Response to Applicant’s argument that “Tiwari does not disclose:
Providing data for outputting candidate actions in the claimed structured manner; and
Including a "remote job recommended" indicator conditioned specifically on whether a remotely executable action is among the candidates (as opposed to an incident-level category label).”
The Examiner respectfully disagrees.
As taught by Tiwari, the actions used to resolve network incidents may be executed remote from the source ... the fault mitigation device 110 may be configured to classify the network incident as one of: a no trouble found (NTF) category, a self-healable category, and a non-self-healable category … The self-healable known issues category may be used for network incidents associated with recurring issues in the network for which a resolution is known and may be executed remotely (See Tiwari, Parag. [0037-0038]); in addition, the action (i.e., the self-healable) is communicated to a user via the notification, the notification may be presented to the user in a graphical user interface (See Tiwari, Parag. [0037]), which is reasonably interpreted to be equivalent to the claimed “provide data for outputting information of candidates estimated as the action to be executed for the error occurring in the network device ...”
Claim Rejections - 35 USC § 112
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claim 8 is rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention.
Claim 8 recites “wherein an estimated action determined to be not remotely executable by operating the network device at an installation site of the network device”
It’s unclear how operating the network device at an installation site determines an estimated action to be not remotely executable. Therefore, the Examiner is unable to determine the metes and the bounds of the claim language.
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-11 are rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more.
Claim 1, 9, and 10 recite in part process steps which, under the broadest reasonable interpretation, are a series of mental processes including an observation, evaluation, judgment or opinion that could be performed in the human mind or with the aid of pencil and paper. If a claim, under its broadest reasonable interpretation, covers a mental process or a mathematical concept but for the recitation of generic computer components, then it falls within the "Mental Process" grouping of abstract ideas. The claims recite in part:
acquire operation information including error information received from the network device via a communication interface. The “acquire” operation information … is reasonably interpreted by the Examiner as gathering/collecting data. The claim does not provide any details on the gathered data. Under its broadest reasonable interpretation when read in light of the specification, the claimed “acquire” operation information encompasses gathering data.
estimate an action to be executed for the error occurring in the network device based on the received error information and stored error history. The “estimate” is reasonably interpreted by the Examiner as making a judgment. Under its broadest reasonable interpretation when read in light of the specification, the claimed “estimate” encompasses making a judgement.
determine whether the estimated action to be executed for the error occurring in the network device is a remotely executable action that is able to be performed by remotely transmitting a command to a target network device via a network. The “determine” is reasonably interpreted by the Examiner as making a judgment. Under its broadest reasonable interpretation when read in light of the specification, the claimed “determine” encompasses making a judgement.
provide data for outputting information of candidates estimated as the action to be executed for the error occurring in the network device. The “provide data” is reasonably interpreted by the Examiner as making an opinion. Under its broadest reasonable interpretation when read in light of the specification, the claimed “provide data” encompasses making an opinion.
wherein, when the remotely executable action is included in the candidates, data for outputting information indicating that a remote job is recommended is included in the provided data. The wherein clause further defines data for outputting information indicating that a remote job is recommended, which does not integrate the abstract idea into a practical application because it does not impose any meaningful limits on practicing the abstract idea.
Therefore, claims 1, 9, and 10 recite an abstract idea.
This judicial exception is not integrated into a practical application. In particular, the claims only recite one additional element - when executed by a processor/computer, to acquire operation information ... estimate an action to be executed for the error …, determine whether the estimated action to be executed for the error occurring in the network device is a remotely executable action …, and provide data for outputting information of candidates estimated as the action to be executed … The processor/computer is recited at a high-level of generality (i.e., as a generic processor/computer to acquire operation information ... estimate an action to be executed for the error …, determine whether the estimated action to be executed for the error occurring in the network device is a remotely executable action …, and provide data for outputting information of candidates estimated as the action to be executed …), such that it amounts no more than mere instructions to apply the exception using a generic computer component. As described in MPEP 2106.0S(g), limitations that amount to merely adding insignificant extra-solution activity to a judicial exception cannot integrate a judicial exception into a practical application. Accordingly, this additional element does not integrate the abstract idea into a practical application because it does not impose any meaningful limits on practicing the abstract idea. Therefore, claims 1, 9, and 10 are directed to a judicial exception.
Claims 1, 9, and 10 do not include additional elements that are sufficient to amount to significantly more than the judicial exception. As discussed above, the additional element of the processor to acquire operation information ... estimate an action to be executed for the error …, determine whether the estimated action to be executed for the error occurring in the network device is a remotely executable action …, and provide data for outputting information of candidates estimated as the action to be executed … to no more than mere instructions to apply the exception using a generic computer component. Mere instructions to apply an exception using a generic computer component cannot provide an inventive concept. Claims 1, 9, and 10 are not patent eligible.
Claim 2 is rejected under 35 U.S.C. 101 because the claimed invention is directed to a judicial exception (i.e., a law of nature, a natural phenomenon, or an abstract idea) without significantly more. Claim 2 depends on claim 1, and further recites “wherein the output data includes one or both of a message for recommending remote execution and a message of recommending remote execution of a target action”. The claim is further limiting and defining the output data, which does not integrate the abstract idea into a practical application because it does not impose any meaningful limits on practicing the abstract idea. Therefore, claim 2 is not patent eligible.
Claim 3 is rejected under 35 U.S.C. 101 because the claimed invention is directed to a judicial exception (i.e., a law of nature, a natural phenomenon, or an abstract idea) without significantly more. Claim 3 depends on claim 1, and further recites “wherein information of the estimated candidates is output by a web browser based on the data for outputting information of candidates estimated as the action to be executed for the error occurring in the network device”. The claim is further limiting and defining presenting information of the estimated candidates, which does not integrate the abstract idea into a practical application because it does not impose any meaningful limits on practicing the abstract idea. Therefore, claim 3 is not patent eligible.
Claim 4 is rejected under 35 U.S.C. 101 because the claimed invention is directed to a judicial exception (i.e., a law of nature, a natural phenomenon, or an abstract idea) without significantly more. Claim 4 depends on claim 1, and further recites “wherein the processor determines whether the estimated action to be executed for the error occurring in the network device is a remotely executable action based on remote action information indicating whether each action is remotely executable”. The “determine” is reasonably interpreted by the Examiner as making a judgment. Under its broadest reasonable interpretation when read in light of the specification, the claimed “determine” encompasses making a judgement, which does not integrate the abstract idea into a practical application because it does not impose any meaningful limits on practicing the abstract idea. Therefore, claim 4 is not patent eligible.
Claim 5 is rejected under 35 U.S.C. 101 because the claimed invention is directed to a judicial exception (i.e., a law of nature, a natural phenomenon, or an abstract idea) without significantly more. Claim 5 depends on claim 4, and further recites “wherein the processor ascertains whether the action determined to be a remotely executable action based on the remote action information is remotely received by the network device and determines whether the action is a remotely executable action”. The “ascertains” and “determines” are reasonably interpreted by the Examiner as making a judgment. Under their broadest reasonable interpretation when read in light of the specification, the claimed ascertains” and “determines” encompass making a judgement, which does not integrate the abstract idea into a practical application because it does not impose any meaningful limits on practicing the abstract idea. Therefore, claim 5 is not patent eligible.
Claim 6 is rejected under 35 U.S.C. 101 because the claimed invention is directed to a judicial exception (i.e., a law of nature, a natural phenomenon, or an abstract idea) without significantly more. Claim 6 depends on claim 1, and further recites “wherein, when a remotely executable action is included in the candidates and a probability of a reason of the error occurring in the network device corresponding to the remotely executable action is equal to or greater than a threshold value, data for outputting information indicating that a remote job is recommended is included in the provided data”. The claim is reasonably interpreted by the Examiner as making a judgment based on probability in comparison to a threshold. Under its broadest reasonable interpretation when read in light of the specification, the claim encompasses making a judgement, which does not integrate the abstract idea into a practical application because it does not impose any meaningful limits on practicing the abstract idea. Therefore, claim 6 is not patent eligible.
Claim 7 is rejected under 35 U.S.C. 101 because the claimed invention is directed to a judicial exception (i.e., a law of nature, a natural phenomenon, or an abstract idea) without significantly more. Claim 7 depends on claim 1, and further recites “when a plurality of actions are recommended to resolve one error, a sequence in which the plurality of actions including a remotely executable action are executed is not determined, and an action to be first executed out of the plurality of actions is the remotely executable action, and data for outputting information indicating that a remote job is recommended is included in the provided data”. The claim is reasonably interpreted by the Examiner as making a judgment. Under its broadest reasonable interpretation when read in light of the specification, the claim encompasses making a judgement, which does not integrate the abstract idea into a practical application because it does not impose any meaningful limits on practicing the abstract idea. Therefore, claim 6 is not patent eligible.
Claim 8 is rejected under 35 U.S.C. 101 because the claimed invention is directed to a judicial exception (i.e., a law of nature, a natural phenomenon, or an abstract idea) without significantly more. Claim 8 depends on claim 1, and further recites “wherein an estimated action determined to be not remotely executable by operating the network device in an installation site of the network device”. The claim is further limiting and defining an action which is not remotely executable, which does not integrate the abstract idea into a practical application because it does not impose any meaningful limits on practicing the abstract idea. Therefore, claim 8 is not patent eligible.
Claim 11 is rejected under 35 U.S.C. 101 because the claimed invention is directed to a judicial exception (i.e., a law of nature, a natural phenomenon, or an abstract idea) without significantly more. Claim 11 depends on claim 1, and further recites “wherein the processor ranks the estimated actions based on market result information corresponding to a model number and error code included in the operation information, and sets priorities for the estimated actions in the order of likelihoods that the error will be resolved”. The claim is reasonably interpreted by the Examiner as making a judgment (i.e., ranking and setting priorities). Under its broadest reasonable interpretation when read in light of the specification, the claim encompasses making a judgement, which does not integrate the abstract idea into a practical application because it does not impose any meaningful limits on practicing the abstract idea. Therefore, claim 11 is not patent eligible.
Claim Rejections - 35 USC § 102
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 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 the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(1) the claimed invention was patented, described in a printed publication, or in public use,
on sale or otherwise available to the public before the effective filing date of the claimed invention.
Claims 1-2 and 4-11 are rejected under 35 U.S.C. 102 (a)(1) as being anticipated by Tiwari et al. (Pub. No. US 2022/0114041), hereinafter Tiwari.
Claim 1. Tiwari discloses [a]n information provision system that provides information of an action recommended to resolve an error occurring in a network device (See Parag. [0018]; a system for diagnosing and resolving network incidents in accordance with aspects of the present disclosure is shown as a system 100 ... fault mitigation device 110 may be configured to monitor at least one network of the one or more networks 130 for faults (e.g., network errors or issues that may result in degraded network performance, loss of network services, or other issues) and initiate operations to mitigate any detected faults. Operations to mitigate detected faults may include providing recommendations associated with one or more actions configured to resolve or correct a detected fault to the user device(s) 140. See Parag. [0022]; the one or more networks 130 may include a plurality of nodes (e.g., physical devices, servers, security appliances, user devices, or other devices configured to provide functionality and services to one or more end users) …), the information provision system comprising:
a memory storing instructions; and a processor executing the instructions causing the information provision system (See Parag. [0019]; memory 120 may store instructions 122 that, when executed by the one or more processors 112, cause the one or more processors 112 to perform the operations described in connection with the fault mitigation device 110) to:
acquire operation information including error information received from the network device via a communication interface (See Parag. [0045] and Fig. 4; The fault data 402 may be an alarm message, as described above with reference to FIG. 1 and may be received from a node of a network (e.g., one of the nodes 132, 134, 136, 138 of the one or more networks 130 of FIG. 1), from a device supported by the network (e.g., one of the other devices 150 of FIG. 1 or the user device 140 of FIG. 1, such as a user's smartphone device). See Parag. [0019-0020]; The fault mitigation device 110 includes one or more input/output (I/O) devices 118 ... the I/O devices 118 may include one or more communication interfaces configured to communicatively couple the fault mitigation device 110 to the one or more networks 130 ...);
estimate an action to be executed for the error occurring in the network device based on the received error information and stored error history (See Parag. [0034-0035]; [T]he fault mitigation device 110 may evaluate the received alarm message to perform a root cause analysis. The root cause analysis may result in identification of a parent or primary alarm. Once the parent or primary alarm is identified, the parameters included in the alarm message may be evaluated against the model to determine one or more candidate actions that may be performed to resolve the issues related to the alarm message. For example, an artificial intelligence process may analyze the model using a nearest neighbor algorithm to find historical network incidents corresponding to the parameters of the alarm message, as described above. Actions corresponding to the historical network incidents identified by the artificial intelligence process may then be identified, such as by retrieving the actions for the historical network incidents from an actions database (e.g., one of the one or more databases 124) that includes information associated with actions taken to resolve the alarms corresponding to the historical network incidents. The set of actions may represent a set of candidate actions that may be performed to resolve the network incident that triggered generation of the alarm message … A score may be determined for each of the one or more candidate actions, where the score represents a likelihood that a particular candidate action will resolve the cause of the alarm message);
determine whether the estimated action to be executed for the error occurring in the network device is a remotely executable action that is able to be performed by remotely transmitting a command to a target network device via a network (See Parag. [0037]; the actions used to resolve network incidents may be executed remote from the source. To illustrate, the user device 140 may located at a first location and the node of the network causing the alarm may be located at a location that is geographically remote from the first location. In such cases, activation of the interactive element presented at the graphical user interface may cause one or more commands to be transmitted over a network to the node that caused the alarm message to be created. The one or more commands may correspond to commands to execute the action identified. See Parag. [0038]; the fault mitigation device 110 may be configured to categorize the network incident associated with the alarm prior to transmitting a notification to the user device 140 or automatically executing any candidate actions. For example, the fault mitigation device 110 may be configured to classify the network incident as one of: a no trouble found (NTF) category, a self-healable category, and a non-self-healable category … The self-healable known issues category may be used for network incidents associated with recurring issues in the network for which a resolution is known and may be executed remotely (e.g., without having to physically be present at the node of the network) … The non-self-healable category may be used for recurring network issues for which the resolution may be known but cannot be executed without physically troubleshooting the cause of the issue(s) or being present at the node. Non-self-healable network incidents may require analysis and troubleshooting by a user (e.g., an IT or network administrator) or replacement/repair of hardware components of the node … See Parag. [0039]; When categorization is utilized, the categorization of a network incident may be used to determine how the action(s) is executed. Examiner’s interpretation: The action is determined to be executed remotely if the network incident is classified as a self-healable category); and
provide data for outputting information of candidates estimated as the action to be executed for the error occurring in the network device, wherein, when the remotely executable action is included in the candidates, data for outputting information indicating that a remote job is recommended is included in the provided data (See Parag. [0038]; the fault mitigation device 110 may be configured to categorize the network incident associated with the alarm prior to transmitting a notification to the user device 140 or automatically executing any candidate actions. For example, the fault mitigation device 110 may be configured to classify the network incident as one of: a no trouble found (NTF) category, a self-healable category, and a non-self-healable category … The self-healable known issues category may be used for network incidents associated with recurring issues in the network for which a resolution is known and may be executed remotely (e.g., without having to physically be present at the node of the network) ... See also Parag. [0037] [0039]. Examiner’s interpretation: The self-healable is indicating that a remote job is recommended).
Claim 2. Tiwari discloses [t]he information provision system according to claim 1,
Tiwari further discloses wherein the output data includes one or both of a message for recommending remote execution and a message of recommending remote execution of a target action (See Parag. [0038]; the fault mitigation device 110 may be configured to categorize the network incident associated with the alarm prior to transmitting a notification to the user device 140 or automatically executing any candidate actions. For example, the fault mitigation device 110 may be configured to classify the network incident as one of: a no trouble found (NTF) category, a self-healable category, and a non-self-healable category … The self-healable known issues category may be used for network incidents associated with recurring issues in the network for which a resolution is known and may be executed remotely (e.g., without having to physically be present at the node of the network) ... See Parag. [0037]; When the action is communicated to a user via the notification, the notification may be presented to the user in a graphical user interface. See also [0039-0041]).
Claim 4. Tiwari discloses [t]he information provision system according to claim 1,
Tiwari further discloses wherein the processor determines whether the estimated action to be executed for the error occurring in the network device is a remotely executable action based on remote action information indicating whether each action is remotely executable (See Parag. [0038]; the fault mitigation device 110 may be configured to categorize the network incident associated with the alarm prior to transmitting a notification to the user device 140 or automatically executing any candidate actions. For example, the fault mitigation device 110 may be configured to classify the network incident as one of: a no trouble found (NTF) category, a self-healable category, and a non-self-healable category … The self-healable known issues category may be used for network incidents associated with recurring issues in the network for which a resolution is known and may be executed remotely (e.g., without having to physically be present at the node of the network) … The non-self-healable category may be used for recurring network issues for which the resolution may be known but cannot be executed without physically troubleshooting the cause of the issue(s) or being present at the node. Non-self-healable network incidents may require analysis and troubleshooting by a user (e.g., an IT or network administrator) or replacement/repair of hardware components of the node … See Parag. [0039]; When categorization is utilized, the categorization of a network incident may be used to determine how the action(s) is executed. See also Parag. [0037]. Examiner’s interpretation: The action is determined to be executed remotely if the network incident is classified as a self-healable category).
Claim 5. Tiwari discloses [t]he information provision system according to claim 4,
Tiwari further discloses wherein the processor ascertains whether the action determined to be a remotely executable action based on the remote action information is remotely received by the network device and determines whether the action is a remotely executable action (See Parag. [0038]; the fault mitigation device 110 may be configured to categorize the network incident associated with the alarm prior to transmitting a notification to the user device 140 or automatically executing any candidate actions. For example, the fault mitigation device 110 may be configured to classify the network incident as one of: a no trouble found (NTF) category, a self-healable category, and a non-self-healable category … The self-healable known issues category may be used for network incidents associated with recurring issues in the network for which a resolution is known and may be executed remotely (e.g., without having to physically be present at the node of the network) … The non-self-healable category may be used for recurring network issues for which the resolution may be known but cannot be executed without physically troubleshooting the cause of the issue(s) or being present at the node. Non-self-healable network incidents may require analysis and troubleshooting by a user (e.g., an IT or network administrator) or replacement/repair of hardware components of the node … See Parag. [0039]; When categorization is utilized, the categorization of a network incident may be used to determine how the action(s) is executed. See also Parag. [0037]; the user device 140 may located at a first location and the node of the network causing the alarm may be located at a location that is geographically remote from the first location. In such cases, activation of the interactive element presented at the graphical user interface may cause one or more commands to be transmitted over a network to the node that caused the alarm message to be created. The one or more commands may correspond to commands to execute the action identified. Examiner’s interpretation: The action is determined to be executed remotely if the network incident is classified as a self-healable category).
Claim 6. Tiwari discloses [t]he information provision system according to claim 1,
Tiwari further discloses wherein, when a remotely executable action is included in the candidates and a probability of a reason of the error occurring in the network device corresponding to the remotely executable action is equal to or greater than a threshold value, data for outputting information indicating that a remote job is recommended is included in the provided data (See Parag. [0036]; where the score for a candidate action satisfies a threshold score, the fault mitigation device 110 may automatically execute at least one candidate action to resolve the cause of the alarm message, but where the score for the candidate action does not satisfy the threshold score, the fault mitigation device 110 may transmit a notification to the user device 140 that identifies the action. The threshold score may correspond to a score that indicates a very high probability or likelihood the associated candidate action will resolve a suspected cause of the alarm message (e.g., a 95% chance or higher, a 90% chance or higher, a 85% chance or higher, etc.), such that actions associated with scores greater than or equal to the threshold score may be automatically executed and actions associated scores less than the threshold score may be transmitted to a user via the notification. See also Parag. [0037-0039]).
Claim 7. Tiwari discloses [t]he information provision system according to claim 1,
Tiwari further discloses wherein, when a plurality of actions are recommended to resolve one error, a sequence in which the plurality of actions including a remotely executable action are executed is not determined, and an action to be first executed out of the plurality of actions is the remotely executable action, and data for outputting information indicating that a remote job is recommended is included in the provided data (See Parag. [0041]; where more than one candidate action for resolving a network incident is identified, the notification may identify the multiple actions and the user (or fault mitigation device 110) may perform the actions one at a time until the network incident is resolved. For example, the candidate actions may be ranked based on their respective scores (or another metric) and then executed (e.g., by a user via interactive elements presented in the interface or automatically by the fault mitigation device 110) according to the rankings. In such a scenario, the highest ranked candidate action may be executed first and an evaluation may be performed to determine whether that candidate action resolved the network incident. See also Parag. [0037-0039]).
Claim 8. Tiwari discloses [t]he information provision system according to claim 1,
Tiwari further discloses wherein an estimated action determined to be not remotely executable by operating the network device at an installation site of the network device (See Parag. [0038]; the fault mitigation device 110 may be configured to categorize the network incident associated with the alarm prior to transmitting a notification to the user device 140 or automatically executing any candidate actions. For example, the fault mitigation device 110 may be configured to classify the network incident as one of: a no trouble found (NTF) category, a self-healable category, and a non-self-healable category … The non-self-healable category (action determined to be not remotely executable) may be used for recurring network issues for which the resolution may be known but cannot be executed without physically troubleshooting the cause of the issue(s) or being present at the node (an installation site of the network device). Non-self-healable network incidents may require analysis and troubleshooting by a user (e.g., an IT or network administrator) or replacement/repair of hardware components of the node … See Parag. [0039]; When categorization is utilized, the categorization of a network incident may be used to determine how the action(s) is executed).
Claim 9. Tiwari discloses [a] method of controlling an information provision system that provides information of an action recommended to resolve an error occurring in a network device (See Parag. [0018]; a system for diagnosing and resolving network incidents in accordance with aspects of the present disclosure is shown as a system 100 ... fault mitigation device 110 may be configured to monitor at least one network of the one or more networks 130 for faults (e.g., network errors or issues that may result in degraded network performance, loss of network services, or other issues) and initiate operations to mitigate any detected faults. Operations to mitigate detected faults may include providing recommendations associated with one or more actions configured to resolve or correct a detected fault to the user device(s) 140. See Parag. [0022]; the one or more networks 130 may include a plurality of nodes (e.g., physical devices, servers, security appliances, user devices, or other devices configured to provide functionality and services to one or more end users) …), the method comprising:
acquiring operation information including error information received from the network device (See Parag. [0045] and Fig. 4; The fault data 402 may be an alarm message, as described above with reference to FIG. 1 and may be received from a node of a network (e.g., one of the nodes 132, 134, 136, 138 of the one or more networks 130 of FIG. 1), from a device supported by the network (e.g., one of the other devices 150 of FIG. 1 or the user device 140 of FIG. 1, such as a user's smartphone device). See Parag. [0019-0020]; The fault mitigation device 110 includes one or more input/output (I/O) devices 118 ... the I/O devices 118 may include one or more communication interfaces configured to communicatively couple the fault mitigation device 110 to the one or more networks 130 ...);
estimating an action to be executed for the error occurring in the network device based on the received error information and stored error history (See Parag. [0034-0035]; [T]he fault mitigation device 110 may evaluate the received alarm message to perform a root cause analysis. The root cause analysis may result in identification of a parent or primary alarm. Once the parent or primary alarm is identified, the parameters included in the alarm message may be evaluated against the model to determine one or more candidate actions that may be performed to resolve the issues related to the alarm message. For example, an artificial intelligence process may analyze the model using a nearest neighbor algorithm to find historical network incidents corresponding to the parameters of the alarm message, as described above. Actions corresponding to the historical network incidents identified by the artificial intelligence process may then be identified, such as by retrieving the actions for the historical network incidents from an actions database (e.g., one of the one or more databases 124) that includes information associated with actions taken to resolve the alarms corresponding to the historical network incidents. The set of actions may represent a set of candidate actions that may be performed to resolve the network incident that triggered generation of the alarm message … A score may be determined for each of the one or more candidate actions, where the score represents a likelihood that a particular candidate action will resolve the cause of the alarm message);
determining whether the estimated action to be executed for the error occurring in the network device is a remotely executable action that is able to be performed by remotely transmitting a command to a target network device via a network (See Parag. [0037]; the actions used to resolve network incidents may be executed remote from the source. To illustrate, the user device 140 may located at a first location and the node of the network causing the alarm may be located at a location that is geographically remote from the first location. In such cases, activation of the interactive element presented at the graphical user interface may cause one or more commands to be transmitted over a network to the node that caused the alarm message to be created. The one or more commands may correspond to commands to execute the action identified. See Parag. [0038]; the fault mitigation device 110 may be configured to categorize the network incident associated with the alarm prior to transmitting a notification to the user device 140 or automatically executing any candidate actions. For example, the fault mitigation device 110 may be configured to classify the network incident as one of: a no trouble found (NTF) category, a self-healable category, and a non-self-healable category … The self-healable known issues category may be used for network incidents associated with recurring issues in the network for which a resolution is known and may be executed remotely (e.g., without having to physically be present at the node of the network) … The non-self-healable category may be used for recurring network issues for which the resolution may be known but cannot be executed without physically troubleshooting the cause of the issue(s) or being present at the node. Non-self-healable network incidents may require analysis and troubleshooting by a user (e.g., an IT or network administrator) or replacement/repair of hardware components of the node … See Parag. [0039]; When categorization is utilized, the categorization of a network incident may be used to determine how the action(s) is executed. Examiner’s interpretation: The action is determined to be executed remotely if the network incident is classified as a self-healable category); and
providing data for outputting information of candidates estimated as the action to be executed for the error occurring in the network device, wherein, when the remotely executable action is included in the candidates, data for outputting information indicating that a remote job is recommended is included in the provided data (See Parag. [0038]; the fault mitigation device 110 may be configured to categorize the network incident associated with the alarm prior to transmitting a notification to the user device 140 or automatically executing any candidate actions. For example, the fault mitigation device 110 may be configured to classify the network incident as one of: a no trouble found (NTF) category, a self-healable category, and a non-self-healable category … The self-healable known issues category may be used for network incidents associated with recurring issues in the network for which a resolution is known and may be executed remotely (e.g., without having to physically be present at the node of the network) ... See also Parag. [0037] [0039]. Examiner’s interpretation: The self-healable is indicating that a remote job is recommended).
Claim 10. Tiwari discloses [a] non-transitory computer-readable storage medium storing a control program (See Parag. [0019]; memory 120 may store instructions 122 that, when executed by the one or more processors 112, cause the one or more processors 112 to perform the operations described in connection with the fault mitigation device 110) causing a computer to execute a method of controlling an information provision system that provides information of an action recommended to resolve an error occurring in a network device (See Parag. [0018]; a system for diagnosing and resolving network incidents in accordance with aspects of the present disclosure is shown as a system 100 ... fault mitigation device 110 may be configured to monitor at least one network of the one or more networks 130 for faults (e.g., network errors or issues that may result in degraded network performance, loss of network services, or other issues) and initiate operations to mitigate any detected faults. Operations to mitigate detected faults may include providing recommendations associated with one or more actions configured to resolve or correct a detected fault to the user device(s) 140. See Parag. [0022]; the one or more networks 130 may include a plurality of nodes (e.g., physical devices, servers, security appliances, user devices, or other devices configured to provide functionality and services to one or more end users) …), the method comprising:
acquiring operation information including error information received from the network device (See Parag. [0045] and Fig. 4; The fault data 402 may be an alarm message, as described above with reference to FIG. 1 and may be received from a node of a network (e.g., one of the nodes 132, 134, 136, 138 of the one or more networks 130 of FIG. 1), from a device supported by the network (e.g., one of the other devices 150 of FIG. 1 or the user device 140 of FIG. 1, such as a user's smartphone device). See Parag. [0019-0020]; The fault mitigation device 110 includes one or more input/output (I/O) devices 118 ... the I/O devices 118 may include one or more communication interfaces configured to communicatively couple the fault mitigation device 110 to the one or more networks 130 ...);
estimating an action to be executed for the error occurring in the network device based on the received error information and stored error history (See Parag. [0034-0035]; [T]he fault mitigation device 110 may evaluate the received alarm message to perform a root cause analysis. The root cause analysis may result in identification of a parent or primary alarm. Once the parent or primary alarm is identified, the parameters included in the alarm message may be evaluated against the model to determine one or more candidate actions that may be performed to resolve the issues related to the alarm message. For example, an artificial intelligence process may analyze the model using a nearest neighbor algorithm to find historical network incidents corresponding to the parameters of the alarm message, as described above. Actions corresponding to the historical network incidents identified by the artificial intelligence process may then be identified, such as by retrieving the actions for the historical network incidents from an actions database (e.g., one of the one or more databases 124) that includes information associated with actions taken to resolve the alarms corresponding to the historical network incidents. The set of actions may represent a set of candidate actions that may be performed to resolve the network incident that triggered generation of the alarm message … A score may be determined for each of the one or more candidate actions, where the score represents a likelihood that a particular candidate action will resolve the cause of the alarm message);
determining whether the estimated action to be executed for the error occurring in the network device is a remotely executable action that is able to be performed by remotely transmitting a command to a target network device via a network (See Parag. [0037]; the actions used to resolve network incidents may be executed remote from the source. To illustrate, the user device 140 may located at a first location and the node of the network causing the alarm may be located at a location that is geographically remote from the first location. In such cases, activation of the interactive element presented at the graphical user interface may cause one or more commands to be transmitted over a network to the node that caused the alarm message to be created. The one or more commands may correspond to commands to execute the action identified. See Parag. [0038]; the fault mitigation device 110 may be configured to categorize the network incident associated with the alarm prior to transmitting a notification to the user device 140 or automatically executing any candidate actions. For example, the fault mitigation device 110 may be configured to classify the network incident as one of: a no trouble found (NTF) category, a self-healable category, and a non-self-healable category … The self-healable known issues category may be used for network incidents associated with recurring issues in the network for which a resolution is known and may be executed remotely (e.g., without having to physically be present at the node of the network) … The non-self-healable category may be used for recurring network issues for which the resolution may be known but cannot be executed without physically troubleshooting the cause of the issue(s) or being present at the node. Non-self-healable network incidents may require analysis and troubleshooting by a user (e.g., an IT or network administrator) or replacement/repair of hardware components of the node … See Parag. [0039]; When categorization is utilized, the categorization of a network incident may be used to determine how the action(s) is executed. Examiner’s interpretation: The action is determined to be executed remotely if the network incident is classified as a self-healable category); and
providing data for outputting information of candidates estimated as the action to be executed for the error occurring in the network device, wherein, when the remotely executable action is included in the candidates, data for outputting information indicating that a remote job is recommended is included in the provided data (See Parag. [0038]; the fault mitigation device 110 may be configured to categorize the network incident associated with the alarm prior to transmitting a notification to the user device 140 or automatically executing any candidate actions. For example, the fault mitigation device 110 may be configured to classify the network incident as one of: a no trouble found (NTF) category, a self-healable category, and a non-self-healable category … The self-healable known issues category may be used for network incidents associated with recurring issues in the network for which a resolution is known and may be executed remotely (e.g., without having to physically be present at the node of the network) ... See also Parag. [0037] [0039]. Examiner’s interpretation: The self-healable is indicating that a remote job is recommended).
Claim 11. Tiwari discloses [t]he information provision system according to claim 1,
Tiwari further discloses wherein the processor ranks the estimated actions based on market result information corresponding to a model number and error code included in the operation information, and sets priorities for the estimated actions in the order of likelihoods that the error will be resolved (See Parag. [0035]; A score may be determined for each of the one or more candidate actions, where the score represents a likelihood that a particular candidate action will resolve the cause of the alarm message ... See Parag. [0041]; where more than one candidate action for resolving a network incident is identified, the notification may identify the multiple actions and the user (or fault mitigation device 110) may perform the actions one at a time until the network incident is resolved. For example, the candidate actions may be ranked based on their respective scores (or another metric) and then executed (e.g., by a user via interactive elements presented in the interface or automatically by the fault mitigation device 110) according to the rankings. In such a scenario, the highest ranked candidate action may be executed first and an evaluation may be performed to determine whether that candidate action resolved the network incident. If the incident was resolved, the alarm may be cleared and no further candidate actions may be executed. If, however, the incident was not resolved, the next highest ranked candidate action may be executed and evaluated to determine whether the incident was resolved by the second action. This process may continue until either all candidate actions have been executed or the network incident is resolved).
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 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 set forth in Graham v. John Deere Co., 383 U.S. 1, 148 USPQ 459 (1966), that are applied 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 3 is rejected under 35 U.S.C. 103 as being unpatentable over Tiwari et al. (Pub. No. US 2022/0114041), hereinafter Tiwari; in view of Kaffine et al. (Patent No. US 6,654,914), hereinafter Kaffine.
Claim 3. Tiwari discloses [t]he information provision system according to claim 1,
Tiwari further discloses wherein information of the estimated candidates is output based on the data for outputting information of candidates estimated as the action to be executed for the error occurring in the network device (See Parag. [0018]; Operations to mitigate detected faults may include providing recommendations associated with one or more actions configured to resolve or correct a detected fault to the user device(s) 140, which may be devices operated by information technology (IT) or network administration personnel responsible for maintaining the network and the nodes supporting the network. See Parag. [0038]; the fault mitigation device 110 may be configured to categorize the network incident associated with the alarm prior to transmitting a notification to the user device 140. See also Parag. [0034-0038]).
Tiwari doesn’t explicitly disclose information of the estimated candidates is output by a web browser.
However, Kaffine discloses wherein information of the estimated candidates is output by a web browser based on the data (See Col. 15 lines 32-67; the user link 144 and user 140 interact via a diagnostic web page 275 by exchanging questions and answers to establish the user's symptom of not being able to connect … The expert link 146 proceeds with the connectivity test to isolate the root cause of the user's symptom … the expert link 146 analyzes the test results and determines that the likely cause of the user's 140 symptom is an intermittent one or isolated to single NAS … the expert link 146 reports the determined fault to the user link 144, that reports the fault isolation and required action to the browser 142. For example, the user 140 can be informed by a page 293 that there is a network fault causing the user's connectivity symptoms and that the is being attended to. The information can also instruct the user to dial in later or to try another POP and that the user 140 will receive an Email when the cause of the problem is resolved; the browser 142 acknowledges receipt of the information indicating the isolated fault and required action … See Col. 9 lines 42-45; The browser 142 can include any network application, such as web browsing. See also Col. 4 lines 23-29).
It would be obvious to one of ordinary skill in the art at the time before the effective filling date of the claimed invention to modify outputting the set of candidate actions, taught by Tiwari, to be output by a web browser, as taught by Kaffine. This would be convenient such that users can be informed as to remedial actions to correct faults causing the user problems, and can be informed of completion of the remedial actions. Network uptime, reliability, performance, and response/repair time can be improved (Kaffine, Col. 4 lines 23-35).
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure:
Sirota (Pub. No. US 2016/0100001) – Related art in the area of managing distributed execution of programs, (Abstract; Techniques are described for managing distributed execution of programs. In some situations, the techniques include determining configuration information to be used for executing a particular program in a distributed manner on multiple computing nodes and/or include providing information and associated controls to a user regarding ongoing distributed execution of one or more programs to enable the user to modify the ongoing distributed execution in various manners. Determined configuration information may include, for example, configuration parameters such as a quantity of computing nodes and/or other measures of computing resources to be used for the executing, and may be determined in various manners, including by interactively gathering values for at least some types of configuration information from an associated user (e.g., via a GUI that is displayed to the user) and/or by automatically determining values for at least some types of configuration information (e.g., for use as recommendations to a user).).
THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any extension fee pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to ABDELBASST TALIOUA whose telephone number is (571)272-4061. The examiner can normally be reached on Monday-Thursday 7:30 am - 5:30 pm.
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, Oscar Louie can be reached on 571-270-1684. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of an application may be obtained from the Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from either Private PAIR or Public PAIR. Status information for unpublished applications is available through Private PAIR only. For more information about the PAIR system, see https://ppair-my.uspto.gov/pair/PrivatePair. Should you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative or access to the automated information system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/Abdelbasst Talioua/Primary Examiner, Art Unit 2445
Prosecution Insights