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 .
DETAILED ACTION
This non-final action is responsive to application filed on 02/26/2024. In this application, claims 1-20 are pending, with claims 1, 8 and 15 being independent.
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.
Claims 1, 8 and 15 are 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.
Regarding claims 1, 8 and 15, the phrase "may be" renders the claim indefinite because it is unclear whether the limitation(s) following the phrase are part of the claimed invention. See MPEP § 2173.05(d).
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 of this title, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 1-2, 8-9, 15 and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Chen et al. (US 2023/0350668, Pub. Date: Nov. 2, 2023), in view of Khan (US 2024/0146622, Filed: Mar. 25, 2022).
As per claim 1, Chen discloses a system (Chen fig. 4, system 400) comprising:
one or more processors (Chen fig. 8, Processing device 802); and
a memory in communication with the one or more processors and storing instructions that, when executed by the one or more (Chen fig. 8, Main memory 804), are configured to cause the system to:
receive an indication of a code update to source code at a source code repository (Chen fig. 4 and para. [0034], To determine whether code changes for the service have been uploaded to the central repository 140, the update module 135 may check the configuration metadata 425 to determine if a signature of the code changes 415 indicates that code changes 415 has been uploaded to the central repository 140 since the previous check … to determine whether the central repository 140 includes code changes 415 for the service, the update module 135 may determine a checksum of the service code (e.g., code changes 415) at the central repository 140), wherein the indication of the code update code (Chen para. [0034], To determine whether code changes for the service have been uploaded to the central repository 140, the update module 135 may check the configuration metadata 425 to determine if a signature of the code changes 415 indicates that code changes 415 has been uploaded to the central repository 140 since the previous check) represents replacing a first set of source code with a second set of source code (Chen fig. 4 and para. [0032], a system 400 for pull based inner loop code deployment; Chen para. [0014], This method of replacing portions of code while the application continues to operate is referred to herein as inner-loop development. In inner-loop development, the changed code is pushed to the running container by copying the code to the running container instance);
receive an indication that the second set of source code has been deployed (Chen para. [0057], after the code changes have been applied to the instance of the service, a snapshot of the instance may be taken and stored in a repository of service versions) to a cloud infrastructure (Chen para. [0053], the processing logic publishes the code changes within the serverless environment to make the code changes available to instances of the service; Chen para. [0016], During code development and deployment, code updates for a service (e.g., an application, function, micro-service etc.) are pushed to the central repository of a computing system, such as a cloud computing system, computing cluster, or other high performance computing platform);
an event at an alerting resource (Chen fig. 7 and para. [0058], the processing logic monitors performance metrics of the service instance [alerting resource] associated with the code changes. At block 714, in response to detecting a performance regression of the service [event] associated with the code changes; Chen para. [0018], the processing logic may collect performance metrics from before the update and then restart collection of metrics after the update. The processing logic may compare the performance metrics from before the update and after the update to determine whether there are regressions associated with deployment of the new code to the service instance), wherein the alerting resource is one of a plurality of cloud resources hosted on the cloud infrastructure (Chen para. [0053], the processing logic publishes the code changes within the serverless environment to make the code changes available to instances of the service; Chen para. [0016], During code development and deployment, code updates for a service (e.g., an application, function, micro-service etc.) are pushed to the central repository of a computing system, such as a cloud computing system, computing cluster, or other high performance computing platform);
resources comprise one or more resources of the plurality of cloud resources (Chen para. [0053], the processing logic publishes the code changes within the serverless environment to make the code changes available to instances [resources] of the service; Chen para. [0016], During code development and deployment, code updates for a service (e.g., an application, function, micro-service etc.) are pushed to the central repository of a computing system, such as a cloud computing system, computing cluster, or other high performance computing platform);
communicate with the cloud infrastructure to obtain a snapshot of resource states (Chen para. [0057], after the code changes have been applied to the instance of the service, a snapshot of the instance may be taken and stored in a repository of service versions; Chen para. [0018], If a regression is detected, the processing logic may roll back to the prior version using the snapshot of the service instance from prior to the update; Chen fig. 7 and para. [0054], The processing logic may perform a snapshot of the entire serverless environment … The snapshot may save a state (e.g., memory, storage, processor state, etc.) of the containers of the serverless environment at the time the snapshot is performed. [The citations indicate communicating with a repository in serverless environment/cloud infrastructure for obtaining/using snapshot of resource states to roll back to the prior version]);
identify, a previous update to source code at the source code repository that is suspected of having caused the event (Chen fig. 7 and para. [0058], in response to detecting a performance regression of the service associated with the code changes, the processing logic rolls back the service to a previous version of the service; Chen fig. 7 and para. [0051], It is appreciated that the blocks in method 700 may be performed in an order different than presented);
information comprises the snapshot of resource states (Chen para. [0054], The processing logic may perform a snapshot of the entire serverless environment … The snapshot may save a state (e.g., memory, storage, processor state, etc.) of the containers of the serverless environment at the time the snapshot is performed) and an indication of the previous update to source code suspected of having caused the event (Chen para. [0058], in response to detecting a performance regression of the service associated with the code changes, the processing logic rolls back the service to a previous version of the service. For example, the processing logic may roll back the instance of the service to the state of the service instance at the time of the snapshot performed at block 706);
responsive to information, determine a rectification action (Chen para. [0058], in response to detecting a performance regression of the service associated with the code changes, the processing logic rolls back the service to a previous version of the service).
Chen does not explicitly disclose:
receive an alert associated with an event at an alerting resource;
identify, based on the alert, one or more interrelated resources, wherein the one or more interrelated resources comprise one or more resources that may be impacted by the event at the alerting resource;
generate aggregated alert information, wherein the aggregated alert information comprises an indication of the alert, the snapshot of resource states and an indication of the previous update to source code suspected of having caused the event; and
responsive to outputting the aggregated alert information to a machine learning model, determine a rectification action.
Khan teaches:
receive an alert associated with an event at an alerting resource (Khan para. [0018], the affected nodes algorithm is configured to provide the alarms and events that occur on the affected nodes; Khan para. [0085], thereby causing the processing circuitry to: determine a first node affected by an alarm event in a network);
identify, based on the alert, one or more interrelated resources (Khan para. [0085], determine a first node affected by an alarm event in a network; obtain each affected node connected to the first node from a topology application programming interface (API); obtain alarm events associated with each of the connected nodes from an alarm API; Khan para. [0034], Topology API 120 is configured to provide connected nodes to ANM 118 based upon an affected node suffering an alarm event), wherein the one or more interrelated resources comprise one or more resources that may be impacted by the event at the alerting resource (Khan para. [0035], in response to the discovery of an affected node (an occurrence of an alarm event), ANM 18 requests nodes connected to the first node from topology API 120. Continuing with the example, ANM 118 then requests all the alarm events from alarm API 122 for each connected node [interrelated resource] provided to the ANM 118 from topology server 120; Khan para. [0013], such as a RAN, faults (e.g., an abnormal condition or defect at the component, equipment, or sub-system level which leads to a failure or subpar performance) occurring at a single network node (hereinafter referred to as a first node) have the ability to impact other connected nodes);
generate aggregated alert information (Khan para. [0068], GUI 600 is configured to provide a user with information regarding node 620 for troubleshooting. For example, a user is able to view the equipment identification (ID) 604, an equipment type 606, an alarm code 608, an alarm name 610, the first time the alarm appears at start time 612, the last occurrence time of the alarm 614, how many times the alarm has occurred at occurrence count 616, a vendor name 618, and the severity of the alarm at EMS severity 620), wherein the aggregated alert information comprises an indication of the alert (Khan para. [0068], a user is able to view the equipment identification (ID) 604, an equipment type 606, an alarm code 608, an alarm name 610, the first time the alarm appears at start time 612, the last occurrence time of the alarm 614, how many times the alarm has occurred at occurrence count 616, a vendor name 618, and the severity of the alarm at EMS severity 620),
responsive to outputting the aggregated alert information to a machine learning model, determine a rectification action (Khan para. [0068], GUI 600 is configured to provide a user with information regarding node 620 for troubleshooting. For example, a user is able to view the equipment identification (ID) 604, an equipment type 606, an alarm code 608, an alarm name 610, the first time the alarm appears at start time 612, the last occurrence time of the alarm 614, how many times the alarm has occurred at occurrence count 616, a vendor name 618, and the severity of the alarm at EMS severity 620; Khan para. [0046], In operation 218 of ANA 200, ANM 118 is configured to troubleshoot (debug) each of the alarm events filtered in operations 212, 214, and/or 216 … ANM 118 is configured to troubleshoot and debug automatically based upon an artificial intelligence (AI) engine or machine learning engine that has recorded prior faults and the solution to these faults).
Note: Chen teaches using information comprises the snapshot of resource states and an indication of the previous update to source code suspected of having caused the event to determine a rectification action (Chen para. [54&58]). However, Chen does not explicitly disclose generating aggregated alert information comprises an indication of the alert, the snapshot of resource states and an indication of the previous update to source code suspected of having caused the event and determining a rectification action in response to outputting the aggregated alert information to a machine learning model. Khan teaches generating the aggregated alert information and applying machine learning model on aggregated alert information (Khan para. [0046&0068]).
Therefore, it would been obvious to one of ordinary skill in the art before the effective filling date of the claimed invention to modify Chen in view of Khan for receiving an alert associated with an event at an alerting resource; identifying, based on the alert, one or more interrelated resources of the plurality of cloud resources that may be impacted by the event at the alerting resource and applying machine learning model on aggregated alert information comprises an indication of the alert, the snapshot of resource states and an indication of the previous update to source code suspected of having caused the event to determine a rectification action.
One of ordinary skill in the art would have been motived because it offers the advantage of reducing the amount of time to debug the faults (Khan para. [0016]).
As per claim 2, Chen-Khan discloses the system according to claim 1, as set forth above, Chen-Khan also discloses wherein the snapshot of resource states comprises states (Chen para. [0054], The processing logic may perform a snapshot of the entire serverless environment … The snapshot may save a state (e.g., memory, storage, processor state, etc.) of the containers of the serverless environment at the time the snapshot is performed) of the alerting resource and the one or more interrelated resources (Khan para. [0035], in response to the discovery of an affected node (an occurrence of an alarm event), ANM 18 requests nodes connected to the first node from topology API 120. Continuing with the example, ANM 118 then requests all the alarm events from alarm API 122 for each connected node [interrelated resource] provided to the ANM 118 from topology server 120).
Similar rationale in claim 1 is applied.
Per claims 8-9, they do not teach or further define over the limitations in claims 1-2 respectively. As such, claims 8-9 are rejected for the same reasons as set forth in claims 1-2 respectively.
As per claim 15, Chen discloses a system (Chen fig. 4, system 400) comprising:
one or more processors (Chen fig. 8, Processing device 802); and
a memory in communication with the one or more processors and storing instructions that, when executed by the one or more processors (Chen fig. 8, Main memory 804), are configured to cause the system to:
an event at an alerting resource (Chen fig. 7 and para. [0058], the processing logic monitors performance metrics of the service instance [resource] associated with the code changes. At block 714, in response to detecting a performance regression of the service associated with the code changes; Chen para. [0018], the processing logic may collect performance metrics from before the update and then restart collection of metrics after the update. The processing logic may compare the performance metrics from before the update and after the update to determine whether there are regressions associated with deployment of the new code to the service instance), wherein the alerting resource is one of a plurality of cloud resources hosted on a cloud infrastructure (Chen para. [0053], the processing logic publishes the code changes within the serverless environment to make the code changes available to instances of the service; Chen para. [0016], During code development and deployment, code updates for a service (e.g., an application, function, micro-service etc.) are pushed to the central repository of a computing system, such as a cloud computing system, computing cluster, or other high performance computing platform);
resources comprise one or more resources of the plurality of cloud resources (Chen para. [0053], the processing logic publishes the code changes within the serverless environment to make the code changes available to instances [resources] of the service; Chen para. [0016], During code development and deployment, code updates for a service (e.g., an application, function, micro-service etc.) are pushed to the central repository of a computing system, such as a cloud computing system, computing cluster, or other high performance computing platform);
communicate with the cloud infrastructure to obtain a snapshot of resource states (Chen para. [0057], after the code changes have been applied to the instance of the service, a snapshot of the instance may be taken and stored in a repository of service versions; Chen para. [0018], If a regression is detected, the processing logic may roll back to the prior version using the snapshot of the service instance from prior to the update; Chen fig. 7 and para. [0054], The processing logic may perform a snapshot of the entire serverless environment … The snapshot may save a state (e.g., memory, storage, processor state, etc.) of the containers of the serverless environment at the time the snapshot is performed. [The citations indicate communicating to a repository in serverless environment/cloud infrastructure for obtaining/using snapshot of resource states to roll back to the prior version]);
identify, a previous update to source code at a source code repository that is suspected of having caused the event (Chen fig. 7 and para. [0058], in response to detecting a performance regression of the service associated with the code changes, the processing logic rolls back the service to a previous version of the service; Chen fig. 7 and para. [0051], It is appreciated that the blocks in method 700 may be performed in an order different than presented); and
information comprises the snapshot of states (Chen para. [0054], The processing logic may perform a snapshot of the entire serverless environment … The snapshot may save a state (e.g., memory, storage, processor state, etc.) of the containers of the serverless environment at the time the snapshot is performed) and an indication of the previous update to source code (Chen para. [0058], in response to detecting a performance regression of the service associated with the code changes, the processing logic rolls back the service to a previous version of the service. For example, the processing logic may roll back the instance of the service to the state of the service instance at the time of the snapshot performed at block 706; Chen para. [0054], The processing logic may perform a snapshot of the entire serverless environment … The snapshot may save a state (e.g., memory, storage, processor state, etc.) of the containers of the serverless environment at the time the snapshot is performed).
Chen does not explicitly disclose:
receive an alert associated with an event at an alerting resource;
identify, based on the alert, one or more interrelated resources, wherein the one or more interrelated resources comprise one or more resources that may be impacted by the event at the alerting resource;
output aggregated alert information for display via a graphical user interface (GUI) of a user device, wherein the aggregated alert information comprises the alert, the snapshot of states and an indication of the previous update to source code.
Khan teaches:
receive an alert associated with an event at an alerting resource (Khan para. [0018], the affected nodes algorithm is configured to provide the alarms and events that occur on the affected nodes; Khan para. [0085], determine a first node affected by an alarm event in a network);
identify, based on the alert, one or more interrelated resources (Khan para. [0085], determine a first node affected by an alarm event in a network; obtain each affected node connected to the first node from a topology application programming interface (API); obtain alarm events associated with each of the connected nodes from an alarm API; Khan para. [0034], Topology API 120 is configured to provide connected nodes to ANM 118 based upon an affected node suffering an alarm event), wherein the one or more interrelated resources comprise one or more resources that may be impacted by the event at the alerting resource (Khan para. [0035], in response to the discovery of an affected node (an occurrence of an alarm event), ANM 18 requests nodes connected to the first node from topology API 120. Continuing with the example, ANM 118 then requests all the alarm events from alarm API 122 for each connected node [interrelated resource] provided to the ANM 118 from topology server 120; Khan para. [0013], such as a RAN, faults (e.g., an abnormal condition or defect at the component, equipment, or sub-system level which leads to a failure or subpar performance) occurring at a single network node (hereinafter referred to as a first node) have the ability to impact other connected nodes);
output aggregated alert information for display via a graphical user interface (GUI) of a user device (Khan para. [0068], GUI 600 is configured to provide a user with information regarding node 620 for troubleshooting. For example, a user is able to view the equipment identification (ID) 604, an equipment type 606, an alarm code 608, an alarm name 610, the first time the alarm appears at start time 612, the last occurrence time of the alarm 614, how many times the alarm has occurred at occurrence count 616, a vendor name 618, and the severity of the alarm at EMS severity 620; Khan para. [0046], a user has the ability to select which of the alarm events from operations 212, 214, and 216 the user desires to troubleshoot first), wherein the aggregated alert information comprises the alert (Khan para. [0068], a user is able to view the equipment identification (ID) 604, an equipment type 606, an alarm code 608, an alarm name 610, the first time the alarm appears at start time 612, the last occurrence time of the alarm 614, how many times the alarm has occurred at occurrence count 616, a vendor name 618, and the severity of the alarm at EMS severity 620).
Note: Chen teaches information comprises the snapshot of states and an indication of the previous update to source code (Chen para. [0054&0058]. However, Chen does not explicitly disclose displaying aggregated alert information comprises the alert, the snapshot of states and an indication of the previous update to source code.
Therefore, it would been obvious to one of ordinary skill in the art before the effective filling date of the claimed invention to modify Chen in view of Khan for receiving an alert associated with an event at an alerting resource; identifying, based on the alert, one or more interrelated resources of the plurality of cloud resources that may be impacted by the event at the alerting resource and displaying via a graphical user interface (GUI) of a user device aggregated alert information comprises the alert, the snapshot of states and an indication of the previous update to source code.
One of ordinary skill in the art would have been motived because it offers the advantage of reducing the amount of time to debug the faults (Khan para. [0016]).
As per claim 20, Chen-Khan discloses the system according to claim 15, as set forth above, Chen also discloses where the instructions are further configured to cause the system to:
responsive to receiving an instruction from the user device (Khan para. [0068], GUI 600 is configured to provide a user with information regarding node 620 for troubleshooting; Khan para. [0046], a user has the ability to select which of the alarm events from operations 212, 214, and 216 the user desires to troubleshoot first), automatically revert the source code to a previous version of source code that was previously utilized prior to the previous update that is suspected as having caused the event (Chen fig. 7 and para. [0058], in response to detecting a performance regression of the service associated with the code changes, the processing logic rolls back the service to a previous version of the service).
Claims 3-4, 10-11 and 17 are rejected under 35 U.S.C. 103 as being unpatentable over Chen et al. (US 2023/0350668, Pub. Date: Nov. 2, 2023), in view of Khan (US 2024/0146622, Filed: Mar. 25, 2022), in view of Ali et al. (US 2021/0279162, Pub. Date: Sep. 9, 2021).
As per claim 3, Chen-Khan discloses the system according to claim 1, as set forth above, Khan also discloses the alerting resource and each of the one or more interrelated resources (Khan para. [0085], determine a first node affected by an alarm event in a network; obtain each affected node connected to the first node from a topology application programming interface (API)).
Similar rationale in claim 1 is applied.
Chen does not explicitly disclose:
wherein the snapshot of resource states comprises performance metrics of the alerting resource and each of the one or more interrelated resources.
Ali teaches:
snapshot of resource states comprises performance metrics of resources (Ali fig. 3D, Obtain a snapshot of performance metrics for the resource devices associated with the workload at step 356 and para. [0075], a performance metric is a measurable aspect of a resource device that specify how the resource device is being utilized at a given point in time. Examples of performance metrics include, but are not limited to: CPU utilization (e.g., as a percentage of total CPU capability)).
It would been obvious to one of ordinary skill in the art before the effective filling date of the claimed invention to modify Chen in view of Ali for the snapshot of resource states comprises performance metrics of the alerting resource and each of the one or more interrelated resources.
One of ordinary skill in the art would have been motived because it offers the advantage of performing a remediation based on the performance metric (see Ali para. [0070]).
As per claim 4, Chen-Khan-Ali discloses the system according to claim 3, as set forth above, Ali also discloses wherein the performance metrics comprise one or more of:
a central processing unit (CPU) utilization (Ali para. [0075], a performance metric is a measurable aspect of a resource device that specify how the resource device is being utilized at a given point in time. Examples of performance metrics include, but are not limited to: CPU utilization (e.g., as a percentage of total CPU capability));
a memory usage; and
errors.
Similar rationale in claim 3 is applied.
Per claims 10 and 17, they do not teach or further define over the limitations in claim 3. As such, claims 10 and 17 are rejected for the same reasons as set forth in claim 3.
Per claim 11, it does not teach or further define over the limitations in claim 4. As such, claim 11 is rejected for the same reasons as set forth in claim 4.
Claims 5-6, 12-13 and 18-19 are rejected under 35 U.S.C. 103 as being unpatentable over Chen et al. (US 2023/0350668, Pub. Date: Nov. 2, 2023), in view of Khan (US 2024/0146622, Filed: Mar. 25, 2022), in view of Reynolds et al. (US 2014/0215055, Pub. Date: Jul. 31, 2014).
As per claim 5, Chen-Khan discloses the system according to claim 1, as set forth above, Chen does not explicitly disclose wherein each of the plurality of cloud resources hosted on the cloud infrastructure comprises its own respective monitoring software that monitors an electronic health of the respective cloud resource.
Reynolds teaches:
each of resources comprises its own respective monitoring software that monitors an electronic health of the respective resource (Reynolds para. [0011], Presently existing systems and methods may rely on each of the nodes to monitor its own performance metrics and perform all necessary algorithms to generate its own performance scores. Each node may also be responsible for monitoring these scores and generating and triggering alerts if and when the node determines a score is out of bounds of acceptable parameters).
It would been obvious to one of ordinary skill in the art before the effective filling date of the claimed invention to further modify Chen in view of Reynolds for each of the plurality of cloud resources hosted on the cloud infrastructure comprises its own respective monitoring software that monitors an electronic health of the respective cloud resource.
One of ordinary skill in the art would have been motived because it offers the advantage of triggering alerts based on monitoring (see Reynolds para. [0011]).
As per claim 6, Chen-Khan-Reynolds discloses the system according to claim 5, as set forth above, Chen-Reynolds also discloses wherein the instructions are further configured to cause the system to:
monitor for alerts from cloud resources hosted on the cloud infrastructure (Chen fig. 7 and para. [0058], the processing logic monitors performance metrics of the service instance associated with the code changes. At block 714, in response to detecting a performance regression of the service associated with the code changes; Chen para. [0018], the processing logic may collect performance metrics from before the update and then restart collection of metrics after the update. The processing logic may compare the performance metrics from before the update and after the update to determine whether there are regressions associated with deployment of the new code to the service instance), wherein the alerting resource is one of a plurality of cloud resources hosted on the cloud infrastructure (Chen para. [0053], the processing logic publishes the code changes within the serverless environment to make the code changes available to instances of the service; Chen para. [0016], During code development and deployment, code updates for a service (e.g., an application, function, micro-service etc.) are pushed to the central repository of a computing system, such as a cloud computing system, computing cluster, or other high performance computing platform) by:
executing code (Chen para. [0018], processing logic may collect performance metrics of the service instance from both before and after the update) comprising a plurality of listeners, wherein each of the plurality of listeners is configured to listen for a specified alert event (Reynolds para. [0011], Presently existing systems and methods may rely on each of the nodes to monitor its own performance metrics and perform all necessary algorithms to generate its own performance scores. [Listener of] Each node may also be responsible for monitoring these scores and generating and triggering alerts if and when the node determines a score is out of bounds of acceptable parameters) from a specified one of the plurality of cloud resources hosted on the cloud infrastructure (Chen para. [0053], the processing logic publishes the code changes within the serverless environment to make the code changes available to instances of the service; Chen para. [0016], During code development and deployment, code updates for a service (e.g., an application, function, micro-service etc.) are pushed to the central repository of a computing system, such as a cloud computing system, computing cluster, or other high performance computing platform).
Similar rationale in claim 5 is applied.
Per claims 12-13, they do not teach or further define over the limitations in claims 5-6 respectively. As such, claims 12-13 are rejected for the same reasons as set forth in claims 5-6 respectively.
Per claims 18-19, they do not teach or further define over the limitations in claims 5-6 respectively. As such, claims 18-19 are rejected for the same reasons as set forth in claims 5-6 respectively.
Claims 7 and 14 are rejected under 35 U.S.C. 103 as being unpatentable over Chen et al. (US 2023/0350668, Pub. Date: Nov. 2, 2023), in view of Khan (US 2024/0146622, Filed: Mar. 25, 2022), in view of Li (US 2018/0060218, Pub. Date: Mar. 1, 2018).
As per claim 7, Chen-Khan discloses the system according to claim 1, as set forth above, Chen also discloses wherein the previous update suspected as having caused the alert is identified as being the code update (Chen fig. 7 and para. [0058], in response to detecting a performance regression of the service associated with the code changes, the processing logic rolls back the service to a previous version of the service) and the rectification action comprises automatically causing the second set of source code to be replaced with the first set of source code (Chen para. [0058], in response to detecting a performance regression of the service associated with the code changes, the processing logic rolls back the service to a previous version of the service).
Chen does not explicitly disclose:
the second set of source code to be replaced with the first set of source code at the source code repository.
Li teaches:
the second set of source code to be replaced with the first set of source code at the source code repository (Li para. [0104], If any errors or improper operations have been encountered, computing system 200 may, in some examples, roll back or revert source code 262 within repository 260 to a prior version of source code 262 (824)).
It would been obvious to one of ordinary skill in the art before the effective filling date of the claimed invention to further modify Chen in view of Li for rectification action comprises automatically causing the second set of source code to be replaced with the first set of source code at the source code repository.
One of ordinary skill in the art would have been motived because it offers the advantage of fixing a software bug in source code (Li para. [0021]).
As per claim 14, Chen-Khan discloses the system according to claim 8, as set forth above, Chen does not explicitly disclose wherein the rectification action comprises automatically reverting the source code to a previous version of source code that was installed on the source code repository prior.
Li teaches:
rectification action comprises automatically reverting the source code to a previous version of source code that was installed on the source code repository prior (Li para. [0104], If any errors or improper operations have been encountered, computing system 200 may, in some examples, roll back or revert source code 262 within repository 260 to a prior version of source code 262 (824)).
It would been obvious to one of ordinary skill in the art before the effective filling date of the claimed invention to further modify Chen in view of Li for rectification action comprises automatically reverting the source code to a previous version of source code that was installed on the source code repository prior.
One of ordinary skill in the art would have been motived because it offers the advantage of fixing a software bug in source code (Li para. [0021]).
Claim 16 is rejected under 35 U.S.C. 103 as being unpatentable over Chen et al. (US 2023/0350668, Pub. Date: Nov. 2, 2023), in view of Khan (US 2024/0146622, Filed: Mar. 25, 2022), in view of Li et al. (US 2022/0019497, Pub. Date: Jan. 20, 2022).
As per claim 16, Chen-Khan discloses the system according to claim 15, as set forth above, Chen-Khan also discloses wherein the instructions are configured to cause the system to obtain the aggregated alert information output for display via the GUI of the user device (Khan para. [0068], GUI 600 is configured to provide a user with information regarding node 620 for troubleshooting. For example, a user is able to view the equipment identification (ID) 604, an equipment type 606, an alarm code 608, an alarm name 610, the first time the alarm appears at start time 612, the last occurrence time of the alarm 614, how many times the alarm has occurred at occurrence count 616, a vendor name 618, and the severity of the alarm at EMS severity 620; Khan para. [0046], a user has the ability to select which of the alarm events from operations 212, 214, and 216 the user desires to troubleshoot first) based on:
receiving a new alert associated with a new event at a new alerting resource (Khan para. [0018], the affected nodes algorithm is configured to provide the alarms and events that occur on the affected nodes; Khan para. [0085], determine a first node affected by an alarm event in a network);
identifying, based on the new alert, one or more new interrelated resources (Khan para. [0085], determine a first node affected by an alarm event in a network; obtain each affected node connected to the first node from a topology application programming interface (API); obtain alarm events associated with each of the connected nodes from an alarm API; Khan para. [0034], Topology API 120 is configured to provide connected nodes to ANM 118 based upon an affected node suffering an alarm event);
communicating with the cloud infrastructure to obtain a new snapshot of resource states (Chen para. [0057], after the code changes have been applied to the instance of the service, a snapshot of the instance may be taken and stored in a repository of service versions; Chen para. [0018], If a regression is detected, the processing logic may roll back to the prior version using the snapshot of the service instance from prior to the update; Chen fig. 7 and para. [0054], The processing logic may perform a snapshot of the entire serverless environment … The snapshot may save a state (e.g., memory, storage, processor state, etc.) of the containers of the serverless environment at the time the snapshot is performed. [The citations indicate communicating to a repository in serverless environment/cloud infrastructure for obtaining/using snapshot of resource states to roll back to the prior version]); and
identifying an update to source code at the source code repository that is suspected of having caused the new event (Chen fig. 7 and para. [0058], in response to detecting a performance regression of the service associated with the code changes, the processing logic rolls back the service to a previous version of the service; Chen fig. 7 and para. [0051], It is appreciated that the blocks in method 700 may be performed in an order different than presented).
Similar rationale in claim 15 is applied.
Chen-Khan teaches receiving, identifying, communicating and identifying steps (Chen para. [54, 57-58) and Khan para. [18. 34, 85]). However, Chen-Khan does not explicitly disclose iteratively update the aggregated alert information based on iteratively performing the receiving, identifying, communicating and identifying steps.
Li teaches:
instructions are further configured to cause the system to iteratively update the aggregated alert information based on iteratively monitoring alarms (Li para. [0088], the alarm aggregating module 230 uses the learned patterns 240 to aggregate the T minutes of the alarm data. After that, the method continues to process the next T minutes of the alarm data. It continues when alarms continue to stream into the system; Li para. [0060], The aggregation component uses the rules learned by the correlation component and the rules stored in the aggregation rules to aggregate alarms so as to obtain aggregated alarms).
It would been obvious to one of ordinary skill in the art before the effective filling date of the claimed invention to further modify Chen in view of Li in order to incorporate iteratively receiving a new alert associated with a new event at a new alerting resource; identifying, based on the new alert, one or more new interrelated resources communicating with the cloud infrastructure to obtain a new snapshot of resource states; and identifying an update to source code at the source code repository that is suspected of having caused the new event for iteratively updating the aggregated alert information output for display via the GUI of the user device.
One of ordinary skill in the art would have been motived because it offers the advantage of performing problem diagnosis more efficiently (Li para. [0051]).
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
van der Goot (US 8726083) Synchronized Taking Of Snapshot Memory Images Of Virtual Machines And Storage Snapshots;
Constandache et al. (US 20200349172) Managing Code And Data In Multi-Cluster Environments;
Goyer et al. (US 20240256242) Operational Validation System For Software Deployments.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to VINH NGUYEN whose telephone number is (571)272-4487. The examiner can normally be reached Monday-Friday: 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, KAMAL B DIVECHA can be reached at (571)272-5863. 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.
/VINH NGUYEN/Examiner, Art Unit 2453
/KAMAL B DIVECHA/Supervisory Patent Examiner, Art Unit 2453
Prosecution Insights