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 .
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
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-5 and 7-19 is/are rejected under 35 U.S.C. 103 as being unpatentable over Rakuten (WO 2023/183001, IDS Reference) in view of Anand et al. (US 2025/0021422).
Regarding claim 1, Rakuten discloses a method for managing and resolving chronic incidents occurring in a radio access network of the communication network (Title, RECURRING [chronic] ALARM DETECTION SYSTEM AND METHOD OF USING; Paragraph 15, alarm related to error [incident] or problems [incident] within a base station), wherein the method comprises:
generating, by an incident reporting application executing on a computer system (Figure 1, monitoring system 140), an incident report based on an alarm (Paragraph 20, the monitoring system 140 is configured to generate an incident report. An incident report identifies the corresponding recurring alarm), wherein the alarm is triggered in response to an incident that has occurred at a network element in the radio access network (Paragraph 15, alarm related to error [incident] or problems [incident] within a base station [network element in radio access network]; Paragraph 16, receiving an alarm), wherein the incident report indicates data describing the incident that has occurred at the network element (Paragraph 20, An incident report identifies the corresponding recurring alarm; Paragraph 15, alarm related to error or problems within a base station);
obtaining, by the incident reporting application, a history of prior incident reports associated with the network element, wherein the history of prior incident reports includes data associated with a plurality of prior incident reports that were created in response to a plurality of prior alarms triggered at the network element (Paragraph 20, the monitoring system 140 compares and matches the generated incident report with previous incident reports to identify a recurring alarm; Paragraph 15, Using the connection 120 to monitor the performance of the base stations 110, the monitoring system 140 is able to collect data from the base stations 110, such as alarm logs. An alarm log includes historical information related to error or problems within the base station. The alarm log includes information such as an alarm code, which indicates what type of problem or error occurred, a time that the alarm was initially generated, a time at which the alarm ceased, or other suitable information; Figure 2 and paragraph 31, a determination is made regarding whether the primary fault identified in operation 225 matches any of the open incidents in the retrieved incident log);
determining, by the incident reporting application, that the incident is a chronic incident when the history of prior incident reports includes at least a threshold quantity of prior incident reports (Paragraph 18, the monitoring system 140 is able to identify recurring alarms…the monitoring system 140 is able to recognize a number of occurrences of an alarm code from a same base station 110 or piece of equipment that exceeds a predefined threshold within a specific time duration based on information from the alarm log);
adding, by the incident reporting application, a tag to the incident report indicating that the incident report describes the chronic incident when the incident is the chronic incident (Paragraph 20, In response to identifying a recurring alarm, the monitoring system 140 is configured to generate an incident report. An incident report identifies [tagging] the corresponding recurring alarm…in response to a determination that the incident report matches an open incident report, the monitoring system 140 is configured to increase a priority level [tagging] of the previously generated incident report; Figure 2 and paragraph 31, in response to a determination that a match exists between the incident log and the identified primary fault, a priority level of the incident is increased); and
forwarding, by an incident management application executing on the computer system, the incident report to a processing entity to perform the reset action on the network element and perform one or more action items to resolve the incident (Paragraph 16, In response to receiving an alarm, a user, such as a system monitor, is able to review the alarm, determine a process for resolving the problem or error, and issuing [forwarding] instructions to begin a resolution process. In some embodiments, the instructions include instructions transmitted [forwarding] directly to the base station 110 over the connection 120. Instructions such as restart commands, reset commands, software updates, or the like are able to be transmitted [forwarding] directly to the base station 110 to help resolve the problem or error; Paragraph 20, An incident report identifies the corresponding recurring alarm and includes instructions for attempting to resolve the identified recurring alarm…whether to issue [forwarding] the instructions associated with the incident report; Paragraph 32, The incident includes instructions for resolving the primary fault…the instructions are automatically transmitted [forwarding] to either the user or a maintenance crew for implementing the instructions. In some embodiments, the instructions are transmitted wirelessly [forwarding]. In some embodiments, the instructions are transmitted via a wired connection [forwarding]).
Rakuten does not disclose the following limitations that are disclosed by Anand et al.: wherein each of the prior incident reports comprises a resolution identifier identifying a resolution of a prior incident (Anand et al., Paragraph 41, each data container 150 [prior incident report] stores the resolution process 156 associated with a previously resolved alarm 152b, including one or more root causes 160 (e.g., shown as root causes 160a and 160b) associated with the alarm 152b, and an error resolution method 162 [resolution identifier] (shown as self-healing method 162a and manual healing method 162b) corresponding to each root cause 160), the prior incident reports comprising the resolution identifier identifying that the prior incidents at the network element were resolved based on at least one of a self-clear action or a reset action (Anand et al., Paragraph 41, an error resolution method 162 [resolution identifier] (shown as self-healing method 162a and manual healing method 162b).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Rakuten with the cited disclosure from Anand et al. in order to provide intelligent and swift resolution to alarms (Anand et al., Paragraph 3).
Regarding claim 2, Rakuten discloses transmitting, by the incident reporting application, the incident report to the incident management application (Paragraph 20, incident report identifying recurring alarm and including resolution instructions; Paragraph 32, instruction transmission); and transmitting, by the incident management application, the incident report to the processing entity, wherein the processing entity is a network operations center (NOC) operator, a field technician, or an automated system (Paragraph 32, instruction transmission to user, maintenance crew; Paragraph 16, instructions transmitted direct to base station or maintenance crew).
Regarding claim 3, Rakuten in view of Anand et al. does not specifically disclose wherein the threshold quantity of prior incident reports is three. However, Rakuten discloses a threshold that ranges from about 5 occurrences to about 20 occurrences for identifying a recurring alarm (See paragraph 18). The threshold number of the claimed invention appears to be an obvious design choice when compared with the cited prior art and not involving an inventive step or improvement.
Regarding claim 4, Rakuten discloses wherein the incident report is generated based on an alarm configuration rule, wherein the alarm configuration rule includes an instruction to add the tag to the incident report when the incident report describes different types of chronic incidents (Paragraph 19, the rules include information related to a corresponding alarm code… the monitoring system 140 is able to review alarm logs to identify alarms which satisfy the criteria defined by the rules; Paragraph 24, the rule includes a monitoring period, an alarm code, an occurrence count, an equipment type, or other suitable information; Paragraph 28, faults satisfying the rules are identified based on the correlation performed in operation 215. The monitoring system determines what, if any, faults satisfy all of the conditions of any one rule; Paragraph 20, incident report is generated, the incident report identifying the recurring alarm, which has an alarm code according to the rule; Paragraph 15, alarm code indicates type of problem or error that occurred).
Regarding claim 5, Rakuten discloses wherein the tag comprises a flag, descriptive text, or an information element (Paragraph 20, In response to identifying a recurring alarm, the monitoring system 140 is configured to generate an incident report. An incident report identifies [flag/descriptive text/information element] the corresponding recurring alarm…in response to a determination that the incident report matches an open incident report, the monitoring system 140 is configured to increase a priority level [flag/information element] of the previously generated incident report; Figure 2 and paragraph 31, in response to a determination that a match exists between the incident log and the identified primary fault, a priority level of the incident is increased).
Regarding claim 7, Rakuten discloses a communications network implemented in a network comprising a radio access network (Figure 1), wherein the communications network comprises:
an incident reporting application executing on a computer system in the communications network (Figure 1, monitoring system 140), wherein the incident reporting application is configured to:
generate an incident report based on an alarm indicated in a data store (Paragraph 20, the monitoring system 140 is configured to generate an incident report. An incident report identifies the corresponding recurring alarm; Paragraph 15, alarms are continually transmitted to the monitoring system 140 over the connection 120 and an alarm log is stored in the monitoring system 140; Paragraph 22, the monitoring system is configured to store the alarms in an alarm log), wherein the alarm is triggered in response to an incident that has occurred at a network element in the radio access network (Paragraph 15, alarm related to error [incident] or problems [incident] within a base station [network element in radio access network]; Paragraph 16, receiving an alarm), wherein the incident report indicates data describing the incident that has occurred at the network element (Paragraph 20, An incident report identifies the corresponding recurring alarm; Paragraph 15, alarm related to error or problems within a base station);
obtain a history of prior incident reports associated with the network element, wherein the history of prior incident reports includes data associated with a plurality of prior incident reports that were created based on a plurality of prior alarms triggered at the network element (Paragraph 20, the monitoring system 140 compares and matches the generated incident report with previous incident reports to identify a recurring alarm; Paragraph 15, Using the connection 120 to monitor the performance of the base stations 110, the monitoring system 140 is able to collect data from the base stations 110, such as alarm logs. An alarm log includes historical information related to error or problems within the base station. The alarm log includes information such as an alarm code, which indicates what type of problem or error occurred, a time that the alarm was initially generated, a time at which the alarm ceased, or other suitable information; Figure 2 and paragraph 31, a determination is made regarding whether the primary fault identified in operation 225 matches any of the open incidents in the retrieved incident log);
determine that the incident is a chronic incident when the history of prior incident reports includes at least a threshold quantity of prior incident reports (Paragraph 18, the monitoring system 140 is able to identify recurring alarms…the monitoring system 140 is able to recognize a number of occurrences of an alarm code from a same base station 110 or piece of equipment that exceeds a predefined threshold within a specific time duration based on information from the alarm log);
add a tag to the incident report indicating that the incident report describes the chronic incident when the incident is the chronic incident (Paragraph 20, In response to identifying a recurring alarm, the monitoring system 140 is configured to generate an incident report. An incident report identifies [tagging] the corresponding recurring alarm…in response to a determination that the incident report matches an open incident report, the monitoring system 140 is configured to increase a priority level [tagging] of the previously generated incident report; Figure 2 and paragraph 31, in response to a determination that a match exists between the incident log and the identified primary fault, a priority level of the incident is increased); and
an incident management application executing on the computer system (Figure 1, monitoring system 140), wherein the incident management application is configured to forward the incident report to a processing entity to perform a reset action on the network element and perform one or more action items to resolve the incident (Paragraph 16, In response to receiving an alarm, a user, such as a system monitor, is able to review the alarm, determine a process for resolving the problem or error, and issuing [forwarding] instructions to begin a resolution process. In some embodiments, the instructions include instructions transmitted [forwarding] directly to the base station 110 over the connection 120. Instructions such as restart commands, reset commands, software updates, or the like are able to be transmitted [forwarding] directly to the base station 110 to help resolve the problem or error; Paragraph 20, An incident report identifies the corresponding recurring alarm and includes instructions for attempting to resolve the identified recurring alarm…whether to issue [forwarding] the instructions associated with the incident report; Paragraph 32, The incident includes instructions for resolving the primary fault…the instructions are automatically transmitted [forwarding] to either the user or a maintenance crew for implementing the instructions. In some embodiments, the instructions are transmitted wirelessly [forwarding]. In some embodiments, the instructions are transmitted via a wired connection [forwarding]).
Rakuten does not disclose the following limitations that are disclosed by Anand et al.: wherein each of the prior incident reports comprises a resolution identifier identifying a resolution of a prior incident (Anand et al., Paragraph 41, each data container 150 [prior incident report] stores the resolution process 156 associated with a previously resolved alarm 152b, including one or more root causes 160 (e.g., shown as root causes 160a and 160b) associated with the alarm 152b, and an error resolution method 162 [resolution identifier] (shown as self-healing method 162a and manual healing method 162b) corresponding to each root cause 160), the prior incident reports comprising the resolution identifier identifying that the prior incidents at the network element were resolved based on at least on a self-clear (Anand et al., Paragraph 41, an error resolution method 162 [resolution identifier] (shown as self-healing method 162a and manual healing method 162b).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Rakuten with the cited disclosure from Anand et al. in order to provide intelligent and swift resolution to alarms (Anand et al., Paragraph 3).
Regarding claim 8, Rakuten in view of Anand et al. does not specifically disclose wherein the threshold quantity of prior incident reports is three. However, Rakuten discloses a threshold that ranges from about 5 occurrences to about 20 occurrences for identifying a recurring alarm (See paragraph 18). The threshold number of the claimed invention appears to be an obvious design choice when compared with the cited prior art and not involving an inventive step or improvement.
Regarding claim 9, Rakuten discloses wherein the incident report is generated based on an alarm configuration rule, wherein the alarm configuration rule includes an instruction to add the tag to the incident report when the incident report describes different types of chronic incidents (Paragraph 19, the rules include information related to a corresponding alarm code… the monitoring system 140 is able to review alarm logs to identify alarms which satisfy the criteria defined by the rules; Paragraph 24, the rule includes a monitoring period, an alarm code, an occurrence count, an equipment type, or other suitable information; Paragraph 28, faults satisfying the rules are identified based on the correlation performed in operation 215. The monitoring system determines what, if any, faults satisfy all of the conditions of any one rule; Paragraph 20, incident report is generated, the incident report identifying the recurring alarm, which has an alarm code according to the rule; Paragraph 15, alarm code indicates type of problem or error that occurred).
Regarding claim 10, Rakuten discloses wherein the tag comprises a flag, descriptive text, or an information element (Paragraph 20, In response to identifying a recurring alarm, the monitoring system 140 is configured to generate an incident report. An incident report identifies [flag/descriptive text/information element] the corresponding recurring alarm…in response to a determination that the incident report matches an open incident report, the monitoring system 140 is configured to increase a priority level [flag/information element] of the previously generated incident report; Figure 2 and paragraph 31, in response to a determination that a match exists between the incident log and the identified primary fault, a priority level of the incident is increased).
Regarding claim 11, Rakuten discloses wherein the incident reporting application is further configured to transmit the incident report to the incident management application after adding the tag to the incident report (Paragraph 20, incident report identifying recurring alarm and including resolution instructions…increase a priority level [tag] of the previously generated incident report; Paragraph 32, instruction transmission; Paragraph 32, the incident, having a set priority level [tag], is placed in a queue for processing), and wherein the incident management application is further configured to triage the incident report among a plurality of other unresolved incident reports according to a priority of the incident report, wherein the incident report has a higher priority than the other unresolved incident reports (Paragraph 32, the incident is placed in a queue for processing based on a priority level of the incident. In some embodiments, the priority level of the incident is set based on a type of alarm code associated with the primary fault. In some embodiments, the priority level of the incident is set based on an equipment type of the primary fault. In some embodiments, multiple criteria are utilized to determine the priority level of the incident).
Regarding claim 12, Rakuten discloses a method for managing and resolving chronic incidents occurring in a radio access network of a communication network (Title, RECURRING [chronic] ALARM DETECTION SYSTEM AND METHOD OF USING; Paragraph 15, alarm related to error [incident] or problems [incident] within a base station), wherein the method comprises:
monitoring, by an incident reporting application executing on a computer system (Figure 1, monitoring system 140) of the communication network, an alarm stored at a data store of the communication network (Paragraph 15, Using the connection 120 to monitor the performance of the base stations 110, the monitoring system 140 is able to collect data from the base stations 110, such as alarm logs. An alarm log includes historical information related to error or problems within the base station. The alarm log includes information such as an alarm code, which indicates what type of problem or error occurred, a time that the alarm was initially generated, a time at which the alarm ceased, or other suitable information. In some embodiments, the alarm log is received in response to a request issued by the monitoring system 140 to each of the base stations 110. In some embodiments, alarms are continually transmitted to the monitoring system 140 over the connection 120 and an alarm log is stored in the monitoring system 140), wherein the alarm is associated with an incident that has occurred at a network element in the radio access network (Paragraph 15, monitor the performance of base stations…An alarm log includes historical information related to error or problems within the base station);
generating, by the incident reporting application, an incident report based on an alarm (Paragraph 20, the monitoring system 140 is configured to generate an incident report. An incident report identifies the corresponding recurring alarm), wherein the incident report indicates data describing the incident that has occurred at the network element (Paragraph 20, An incident report identifies the corresponding recurring alarm; Paragraph 15, alarm related to error or problems within a base station);
determining, by the incident reporting application, that the incident is a chronic incident when a history of prior incident reports includes at least a threshold quantity of prior incident reports (Paragraph 18, the monitoring system 140 is able to identify recurring alarms…the monitoring system 140 is able to recognize a number of occurrences of an alarm code from a same base station 110 or piece of equipment that exceeds a predefined threshold within a specific time duration based on information from the alarm log), wherein the prior incidents reports were generated based on prior alarms similar to the alarm (Paragraph 20, the incident report matches an open incident report);
adding, by the incident reporting application, a tag to the incident report indicating that the incident report describes the chronic incident (Paragraph 20, In response to identifying a recurring alarm, the monitoring system 140 is configured to generate an incident report. An incident report identifies [tagging] the corresponding recurring alarm…in response to a determination that the incident report matches an open incident report, the monitoring system 140 is configured to increase a priority level [tagging] of the previously generated incident report; Figure 2 and paragraph 31, in response to a determination that a match exists between the incident log and the identified primary fault, a priority level of the incident is increased);
determining, by an incident management application executing on the computer system (Figure 1, monitoring system 140), one or more action items to resolve the chronic incident (Paragraph 20, An incident report identifies the corresponding recurring alarm and includes instructions for attempting to resolve the identified recurring alarm; Paragraph 31, instructions associated with a matching incident from the incident log);
adding by one or more action items to the incident report (Paragraph 20, An incident report identifies the corresponding recurring alarm and includes instructions for attempting to resolve the identified recurring alarm);
transmitting, by the incident management application, the incident report to an automated system (Paragraph 20, incident report identifying recurring alarm and including resolution instructions and transmission of instructions; Paragraph 16, instructions transmitted; Paragraph 17, short-lived/recurring alarms to be resolved without human intervention [indicates automated system processing]) for performing the reset action on the network element and performing one or more action items at the network element (Paragraph 20, An incident report identifies the corresponding recurring alarm and includes instructions for attempting to resolve the identified recurring alarm; Paragraph 16, In some embodiments, the instructions include instructions transmitted directly to the base station 110 over the connection 120. Instructions such as restart commands, reset commands, software updates, or the like are able to be transmitted directly to the base station 110 to help resolve the problem or error).
Rakuten further discloses a reset action (Rakuten discloses restart and reset commands in paragraph 16 transmitted direct to a base station) but does not disclose the following limitations that are disclosed by Anand et al.: the prior incident reports identifying prior incidents that were resolved using an action (Anand et al., Paragraph 41, a resolution method 162 may include a self-healing method 162a or a manual healing method 162b); determining action items based on a history of incident resolutions indicating a pattern of resolving prior chronic incidents similar to the incident (Anand et al., Paragraph 41, each data container 150 [prior incident report] stores the resolution process 156 associated with a previously resolved alarm 152b, including one or more root causes 160 (e.g., shown as root causes 160a and 160b) associated with the alarm 152b, and an error resolution method 162 [resolution identifier] (shown as self-healing method 162a and manual healing method 162b) corresponding to each root cause 160).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Rakuten with the cited disclosure from Anand et al. in order to provide intelligent and swift resolution to alarms (Anand et al., Paragraph 3).
Regarding claim 13, Rakuten discloses wherein the incident report is generated based on an alarm configuration rule, wherein the alarm configuration rule includes an instruction to add the tag to the incident report when the incident report describes different types of chronic incidents (Paragraph 19, the rules include information related to a corresponding alarm code… the monitoring system 140 is able to review alarm logs to identify alarms which satisfy the criteria defined by the rules; Paragraph 24, the rule includes a monitoring period, an alarm code, an occurrence count, an equipment type, or other suitable information; Paragraph 28, faults satisfying the rules are identified based on the correlation performed in operation 215. The monitoring system determines what, if any, faults satisfy all of the conditions of any one rule; Paragraph 20, incident report is generated, the incident report identifying the recurring alarm, which has an alarm code according to the rule; Paragraph 15, alarm code indicates type of problem or error that occurred).
Regarding claim 14, Rakuten discloses wherein the tag comprises a flag added to the incident report (Paragraph 20, In response to identifying a recurring alarm, the monitoring system 140 is configured to generate an incident report. An incident report identifies [flag] the corresponding recurring alarm…in response to a determination that the incident report matches an open incident report, the monitoring system 140 is configured to increase a priority level [flag] of the previously generated incident report; Figure 2 and paragraph 31, in response to a determination that a match exists between the incident log and the identified primary fault, a priority level of the incident is increased).
Regarding claim 15, Rakuten discloses wherein the tag comprises descriptive text added to the incident report, wherein the descriptive text indicates that the incident is a chronic incident (Paragraph 20, In response to identifying a recurring alarm, the monitoring system 140 is configured to generate an incident report. An incident report identifies [descriptive text indicating chronic incident] the corresponding recurring alarm).
Regarding claim 16, Rakuten discloses wherein the tag is an information element added to the incident report, wherein the information element comprises a value indicating that the incident report is describing the chronic incident (Paragraph 20, In response to identifying a recurring alarm, the monitoring system 140 is configured to generate an incident report. An incident report identifies [information element] the corresponding recurring alarm).
Regarding claim 17, Rakuten discloses transmitting, by the incident reporting application, the incident report to the incident management application after adding the tag to the incident report (Paragraph 20, incident report identifying [tag] recurring alarm and including resolution instructions…increase a priority level [tag] of the previously generated incident report; Paragraph 32, instruction transmission; Paragraph 32, the incident, having a set priority level [tag], is placed in a queue for processing); and triaging the incident report among a plurality of other unresolved incident reports according to a priority of the incident report, wherein the incident report has a higher priority than the other unresolved incident reports (Paragraph 32, the incident is placed in a queue for processing based on a priority level of the incident. In some embodiments, the priority level of the incident is set based on a type of alarm code associated with the primary fault. In some embodiments, the priority level of the incident is set based on an equipment type of the primary fault. In some embodiments, multiple criteria are utilized to determine the priority level of the incident).
Regarding claim 18, Rakuten discloses transmitting, by the incident reporting application, the incident report to the incident management application after adding the tag to the incident report (Paragraph 20, incident report identifying [tag] recurring alarm and including resolution instructions…increase a priority level [tag] of the previously generated incident report; Paragraph 32, instruction transmission; Paragraph 32, the incident, having a set priority level [tag], is placed in a queue for processing); transmitting, by the incident management application, the incident report to the automated system (Paragraph 20, incident report identifying recurring alarm and including resolution instructions and transmission of instructions; Paragraph 16, instructions transmitted; Paragraph 17, short-lived/recurring alarms to be resolved without human intervention [indicates automated system processing]); performing, by the automated system, the reset action on the network element (Paragraph 16, In some embodiments, the instructions include instructions transmitted directly to the base station 110 over the connection 120. Instructions such as restart commands, reset commands, software updates, or the like are able to be transmitted directly to the base station 110 to help resolve the problem or error); and performing, by the automated system, the one or more action items on the network element after performing the reset action on the network element (Paragraph 16, software update transmitted directly to the base station to help resolve the problem or error).
Regarding claim 19, Anand et al. disclose determining, by the incident reporting application the pattern of resolving prior chronic incidents similar to the incident based on a history of incident resolutions indicating stored at the data store, wherein the history of incident resolutions indicates prior actions performed to resolve other similar alarms in the radio access network, wherein the other alarms are similar to the alarm (Anand et al., Paragraph 41, each data container 150 stores the resolution process 156 associated with a previously resolved alarm 152b, including one or more root causes 160 (e.g., shown as root causes 160a and 160b) associated with the alarm 152b, and an error resolution method 162 (shown as self-healing method 162a and manual healing method 162b) corresponding to each root cause 160; Figure 2 step 214, same root cause or a similar root cause).
Claim(s) 6 is/are rejected under 35 U.S.C. 103 as being unpatentable over Rakuten in view of Anand et al. as applied to claim 1 above, and further in view of Babu Balasubramani et al. (US 11,252,052, IDS Reference).
Regarding claim 6, Rakuten in view of Anand et al. discloses the claimed invention above but does not disclose the following limitations that are disclosed by Babu Balasubramani et al.: determining, by the incident reporting application based on a predictive model, one or more predicted action items to resolve the chronic incident (Babu Balasubramani et al., Abstract, Tickets are generated for predicted faults and stored in a ticket database. The tickets may be analyzed to predict executable actions to mitigate the faults associated with each ticket. To analyze the tickets, ticket data may be compiled and used to generate ticket analytical records (TARs). A second model may be executed against the TARs predict actions to resolve the predicted faults. The predicted actions may be executed to mitigate the impact that the faults have on the network, which may include preventing the faults entirely (e.g., via preventative maintenance) or minimizing the impact of the faults via use of the predicted actions); and adding, by the incident reporting application, the one or more predicted action items to the incident report (Babu Balasubramani et al., Column 35 lines 3-10, tickets may be updated to include information indicating the predicted actions and once updated, those tickets may be provided to an orchestration module (e.g., the orchestration module 330 of FIG. 3). The orchestration module may be configured to route the ticket for further processing, such as for automated execution, manual execution, diagnostic evaluation, or validation processing).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the system of Rakuten and Anand et al. with the cited disclosure from Babu Balasubramani et al. in order to implement a predictive model that prevents faults entirely or minimizes the impact of the faults (Babu Balasubramani et al., Abstract).
Allowable Subject Matter
Claim 20 is objected to as being dependent upon a rejected base claim, but would be allowable if rewritten in independent form including all of the limitations of the base claim and any intervening claims.
The following is a statement of reasons for the indication of allowable subject matter: regarding claim 20, the prior art does not disclose or adequately suggest the specific instance of when the history of incident reports not including at least the threshold quantity of prior incident reports identifying the reset action resolution, adding reset count set to 0 in the incident report or incrementing the reset count and adding it to the incident report, wherein the reset count indicates a number of prior incident reports that were resolved by the reset action.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to OTIS L THOMPSON, JR whose telephone number is (571)270-1953. The examiner can normally be reached Monday - Friday, 6:30am - 7:00pm.
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, Chirag G. Shah can be reached at (571)272-3144. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of published or unpublished applications may be obtained from Patent Center. Unpublished application information in Patent Center is available to registered users. To file and manage patent submissions in Patent Center, visit: https://patentcenter.uspto.gov. Visit https://www.uspto.gov/patents/apply/patent-center for more information about Patent Center and https://www.uspto.gov/patents/docx for information about filing in DOCX format. For additional questions, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/OTIS L THOMPSON, JR/Primary Examiner, Art Unit 2477
February 10, 2026