Response to an Amendment
This office action is a response to a communication made on 04/09/2026.
Claims 1, 11 and 15 are currently amended.
Claims 1-20 are pending for this application.
Response to Arguments
Applicant’s arguments with respect to claim(s) 1, 11 and 15 have been considered but are moot because the new ground of rejection does not rely on any reference applied in the prior rejection of record for any teaching or matter specifically challenged in the argument.
Applicant’s arguments, see remark on page 8-12, filed 04/09/2026, with respect to the rejection(s) of claim(s) 1, 11 and 15 under 103 have been considered and regrading the amended feature of “wherein the expected time of receipt is based on a time at which the monitoring system is expected to generate a corresponding alert message in response to the scheduled chaos event” are persuasive. Therefore, the rejection has been withdrawn. However, upon further consideration, a new ground(s) of rejection is made in view of Baker et al. (US 2025/0077374) in view of Kalra et al. (US 2024/0394093), and further in view of Paterson-Jones et al. (US 2022/0100645).
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.
Claim(s) 1, 4, 6-11, 14-15 and 18-20 is/are rejected under 35 U.S.C. 103 as being unpatentable over Baker et al. (US 2025/0077374), hereinafter “Baker” in view of Kalra et al. (US 2024/0394093), hereinafter “Kalra”, and further in view of Paterson-Jones et al. (US 2022/0100645), hereinafter “Paterson”.
With respect to claim 1, Baker discloses a method for identifying one or more weakness in a network system through simulations comprising:
configuring a plurality of chaos events to be run on the network system (¶0025, teaches the automatic creation of chaos experiments (i.e. chaos events), also referred to herein as fault scenarios, to perform automated service validation using chaos engineering… configuration of a service under test is obtained and a chaos engine creates a first set of fault scenarios based on the configuration);
running the plurality of chaos events on the network system (¶0025, teaches the automatic creation of chaos experiments (i.e. chaos events), also referred to herein as fault scenarios, to perform automated service validation using chaos engineering… configuration of a service under test is obtained and a chaos engine creates a first set of fault scenarios based on the configuration, ¶0057, teaches one or more of the first set of fault scenarios are randomly generated by the chaos engine. The randomly generated fault scenarios each include one or more randomly generated anomalies. For example, the chaos engine may be configured to obtain the configuration of the service under test, identify the computing resources in the configuration, and generate a random set of anomalies);
in response to the plurality of chaos events running on the network system (¶0025 and ¶0057), receiving alert messages from a monitoring system (¶0040, teaches the performance analysis system 120 includes a reporting module 124 that generates one or more reports, or error notifications (i.e. error alert), regarding the operation of the service under test 112 under the various fault scenarios);
reporting determined differences to the network system for display on a user terminal (¶0040, teaches the reporting module 124 may transmit a report that includes an identification of identified vulnerabilities of the service under test 112 to the operator (i.e. user terminal) of the service under test 112, , ¶0086, teaches selecting, based on a difference between the first set of values and the expected values, a first fault scenario from the first plurality of fault scenarios).
Baker ¶0025, teaches the automatic creation of chaos experiments, also referred to herein as fault scenarios, to perform automated service validation using chaos engineering, ¶0040, teaches the performance analysis system 120 includes a reporting module 124 that generates one or more reports (i.e. alerts), or error notifications (error alerts), regarding the operation of the service under test 112 under the various fault scenarios. In addition, the reporting module 124 may transmit a report that includes an identification of identified vulnerabilities of the service under test 112 to the operator of the service under test 112, ¶0048, teaches the telemetry data can also include network traffic information, such as incoming and outgoing data rates, packet loss, latency, and network errors of the computing resources in the configuration, ¶0086, teaches selecting, based on a difference between the first set of values and the expected values, a first fault scenario from the first plurality of fault scenarios. However, Baker remain silent on determining differences at least comparing an actual time of receipt of the alert messages from the monitoring system with an expected time of receipt based on a scheduled time of occurrence of a corresponding chaos event, wherein a determined delay between the actual time and the expected time indicates the one or more weakness.
Kalra discloses determining differences at least comparing an actual time of receipt of the alert messages from the monitoring system with an expected time of receipt based on a scheduled time of occurrence of a corresponding chaos event (¶0070, teaches computes 360 a difference between the actual number of interruption events and the predicted number of events to determine whether an anomalous number of interruption events occurred during the time period (see ¶0069, teaches the time period may be some subsequent period after the predicted number is generated (e.g., the next 24 hours) or may be some determined period (e.g., within a future day, week, or month) . For example, the online concierge system may compare the computed difference to a threshold value. If the difference is less than the threshold value, then the online concierge system may determine that the actual number of interruption events was not anomalous and continue to operate accordingly. The difference may be the actual difference between the actual number of interruption events and the predicted number of interruption events, or may be a percentage difference or ratio of the two numbers, ¶0073, teaches notifying users of potential interruption events, providing consideration to users affected by interruption events, or collecting additional data related to the interruption events), wherein a determined delay between the actual time and the expected time indicates the one or more weakness (¶0063, teaches the online concierge system identifies an interruption (i.e. delay) event at the client application by identifying an error (i.e. weakness) that occurs at the online concierge system as part of the execution of the application workflow. For example, the online concierge system may experience an error when identifying which item a picker should collect next within a retailer location as part of servicing an order and may fail to provide an item to the picker client application to present to the picker. The online concierge system may identify this error as an interruption event, ¶0070, teaches the online concierge system computes 360 a difference between the actual number of interruption events and the predicted number of events to determine whether an anomalous number of interruption events occurred during the time period, see ¶0055).
Therefore, it would be obvious to one of ordinary skill in the art before the effective filing date of the invention to modify Baker’s reporting module that generates one or more reports (i.e. alerts), or error notifications (error alerts), regarding the operation of the service under test under the various fault scenarios and selecting, based on a difference between the first set of values and the expected values, a first fault scenario from the first plurality of fault scenarios with determining differences at least comparing an actual time of receipt of the alert messages from the monitoring system with an expected time of receipt based on a scheduled time of occurrence of a corresponding chaos event, wherein a determined delay between the actual time and the expected time indicates the one or more weakness of Kalra, in order to capture delays caused by failover or weakness, especially in a chaos engineering context (Kalra).
However, Baker in view of Kalra remain silent on wherein the expected time of receipt is based on a time at which the monitoring system is expected to generate a corresponding alert message in response to the scheduled chaos event, a control plane of the network system.
Paterson discloses wherein the expected time of receipt is based on a time at which the monitoring system is expected to generate a corresponding alert message in response to the scheduled chaos event (¶0074, teaches the cloud provider service 142 generate and return error messages in response (i.e. alert messages in response) to service requests. For example, the fault instruction 159 could specify that service specific error messages be returned. As another example, the fault instruction 159 could specify that more generic error message be return (e.g., an HTTP response containing “Error Code 500—Internal Server Error” or “Error Code 504—Gateway Timeout Error”), ¶0113, teaches cloud provider service 142 could select service requests at random until a fraction or percentage of an expected number of service requests have been subject to the fault. For instance, if three-hundred (300) service requests were expected in one hour (i.e. expected time of receipt), and one-third of the expected service requests were to be subject to a fault, the object storage service 141 or cloud provider service 142 could randomly select service requests to fault until one-hundred (100) service requests had been faulted, ¶0162, teaches the service endpoint 806 could also generate and return error messages (i.e. alert messages in response) as specified by the fault parameters.
a control plane of the network system (¶0020, teaches the control plane components are typically implemented on a separate set of servers from the data plane servers, and control plane traffic and data plane traffic may be sent over separate/distinct networks, see ¶0023).
Therefore, it would be obvious to one of ordinary skill in the art before the effective filing date of the invention to modify Baker’s difference between the first set of values and the expected values in view of Kalra’s system with wherein the expected time of receipt is based on a time at which the monitoring system is expected to generate a corresponding alert message in response to the scheduled chaos event of Paterson in order to improve the accuracy of alert verification and reducing erroneous determinations regarding alert receipt (Paterson).
For claim 11, it is an apparatus claim corresponding to the method of claim 1. Therefore claim 11 is rejected under the same ground as claim 1.
For claim 15, it is a non-transitory computer readable storage medium claim corresponding to the method of claim 1. Therefore claim 15 is rejected under the same ground as claim 1.
With respect to claims 4 and 18, Baker in view of Kalra, and further in view of Paterson discloses the method of claim 1, further comprising defining times when one or more of the plurality of chaos events are triggered (Baker, ¶0057, teaches one or more of the first set of fault scenarios are randomly generated by the chaos engine. The randomly generated fault scenarios each include one or more randomly generated anomalies. For example, the chaos engine may be configured to obtain the configuration of the service under test, identify the computing resources in the configuration, and generate a random set of anomalies, ¶0082, teaches each of the random anomalies may include both a randomly generated anomaly rate and a randomly generated start and end time).
With respect to claims 6 and 19, Baker in view of Kalra, and further in view of Paterson discloses the method of claim 1, further comprising defining a plurality of types of modes for the plurality of chaos events (Baker, ¶0048, teaches network traffic information, such as incoming and outgoing data rates, packet loss, latency, and network errors of the computing resources in the configuration, wherein packet loss, latency and network errors are the plurality of types of modes).
With respect to claim 7, Baker in view of Kalra, and further in view of Paterson discloses the method of claim 6, wherein the plurality of types of modes comprises one or more of system load increase, network delay, packet loss, packet corruption, packet duplication, and/or random reboots for the plurality of chaos events (Baker, ¶0048, teaches network traffic information, such as incoming and outgoing data rates, packet loss, latency, and network errors of the computing resources in the configuration, wherein packet loss, latency and network errors are the plurality of types of modes).
With respect to claim 8, Baker in view of Kalra, and further in view of Paterson discloses the method of claim 7, wherein the plurality of chaos events comprises one or more of system load increase, network delay, packet loss, packet corruption, packet duplication, and/or random reboots (Baker, ¶0048, teaches network traffic information, such as incoming and outgoing data rates, packet loss, latency, and network errors of the computing resources in the configuration, wherein packet loss, latency and network errors are the plurality of chaos events).
With respect to claims 9, 14 and 20, Baker in view of Kalra, and further in view of Paterson discloses the method of claim 1, wherein the network system comprises one or more computing devices that are connected through one or more network interfaces (Baker, ¶0116, teaches the processing device 1002 to communicate with one or more other computing devices. Communication with various devices can occur via Input/Output (I/O) interfaces 1018 and 1020).
With respect to claim 10, Baker in view of Kalra, and further in view of Paterson discloses the method of claim 1, wherein the alert messages comprise error messages or warning messages (Baker, ¶0040, teaches the performance analysis system 120 includes a reporting module 124 that generates one or more reports, or error notifications (i.e. error alert), regarding the operation of the service under test 112 under the various fault scenarios, Paterson, ¶0074, teaches the cloud provider service 142 generate and return error messages in response (i.e. alert messages in response) to service requests. For example, the fault instruction 159 could specify that service specific error messages be returned. As another example, the fault instruction 159 could specify that more generic error message be return (e.g., an HTTP response containing “Error Code 500—Internal Server Error” or “Error Code 504—Gateway Timeout Error”).
Claim(s) 2-3, 12-13 and 16-17 is/are rejected under 35 U.S.C. 103 as being unpatentable over Baker in view of Kalra in view of Paterson, and further in view of Lachwani et al. (US 9113358), hereinafter “Lachwani”. Lachwani cited in applicant IDS filed 10/05/2023.
With respect to claims 2, 12 and 17, Baker in view of Kalra, and further in view of Paterson discloses the method of claim 1, wherein the configuring a plurality of chaos events to be run on the network system comprises:
manipulating system load by using stress commands (Baker, ¶0003, teaches the computing system or service's performance is assessed by conducting various tests, such as load testing, stress testing).
However, Baker in view of Kalra, and further in view of Paterson remain silent on manipulating network interfaces by using traffic control command.
Lachwani discloses manipulating network interfaces by using traffic control command (Col-4, II. 41-45, teaches the traffic modification server device(s) 110 may provide a traffic modification user interface module 118, to enable a user to manage or control traffic modification operations performed by the traffic modification module 114, Col-12, II. 14-20, teaches the client device 102 may also include one or more network interfaces 508 to enable communications between the client device 102 and other networked devices such as those depicted in FIG. 1. Such network interface(s) 508 may include one or more network interface controllers (NICs) or other types of transceiver devices configured to send and receive communications over the network(s)).
Therefore, it would be obvious to one of ordinary skill in the art before the effective filing date of the invention to modify Baker’s interface in view of Kalra’s in view of Paterson’s system with manipulating network interfaces by using traffic control command of Lachwani, in order to enable users to control various aspects of network traffic, manage and optimize network traffic according to specific requirements and objectives (Lachwani).
With respect to claims 3, 13 and 16, Baker in view of Kalra, and further in view of Paterson discloses the method of claim 1. However, Baker in view of Kalra, and further in view of Paterson remain silent on further comprising pushing the network system to failure by simultaneously adjusting two or more factors including one or more of: varying network traffic, stressing CPU or I/O operations, random rebooting, varying starting time or ending time, changing percentage of packet corruption, changing the percentage of packet loss and/or percentage packet duplication.
Lachwani discloses further comprising pushing the network system to failure by simultaneously adjusting two or more factors including one or more of: varying network traffic, stressing CPU or I/O operations, random rebooting, varying starting time or ending time, changing percentage of packet corruption, changing the percentage of packet loss and/or percentage packet duplication (see Fig. 10, step 1008, Col-19, II. 1-8, teaches the incoming or outgoing packets are further adjusted based on other characteristics of the network connection(s). Such as a packet loss rate, packet corruption rate, packet duplication rate, or packet reordering rate. Such adjustments may be made so that the modified outgoing network traffic 122 or the modified incoming network traffic 126).
Therefore, it would be obvious to one of ordinary skill in the art before the effective filing date of the invention to modify Baker’s in view of Kalra’s in view of Paterson’s system with pushing the network system to failure by simultaneously adjusting two or more factors including one or more of: varying network traffic, stressing CPU or I/O operations, random rebooting, varying starting time or ending time, changing percentage of packet corruption, changing the percentage of packet loss and/or percentage packet duplication of Lachwani, in order to adjust resource allocations, and implement better redundancy or failover mechanisms to improve overall performance and reliability (Lachwani).
Claim(s) 5 is/are rejected under 35 U.S.C. 103 as being unpatentable over Baker in view of Kalra in view of Paterson, and further in view of Anderson et al. (US 2022/0224625), hereinafter “Anderson”. Anderson cited in applicant IDS filed 10/05/2023.
With respect to claim 5, Baker in view of Kalra, and further in view of Paterson discloses the method of claim 4, however, Baker in view of Kalra, and further in view of Paterson remain silent on wherein the times are selected to be when network traffic is low to prevent disruptions to users.
Anderson discloses wherein the times are selected to be when network traffic is low to prevent disruptions to users (¶0023, teaches the example techniques may be capable of analyzing an impact of system changes on the resiliency of the cloud computing service…inhibit (e.g., prevent) regression for resiliency outcomes ¶0060, teaches selecting a duration of each of the time periods for each chaos event based on a duration of the respective chaos event…In another example, a chaos event having a relatively short duration may result in a relatively shorter duration being selected for each of the time periods for the chaos event, wherein short duration is selected to prevent disruptions to users).
Therefore, it would be obvious to one of ordinary skill in the art before the effective filing date of the invention to modify Baker’s in view of Kalra’s in view of Paterson’s system with the times are selected to be when network traffic is low to prevent disruptions to users of Anderson, in order to minimize disruption to users (Anderson, ¶0060).
Conclusion
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, 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 nonprovisional extension fee (37 CFR 1.17(a)) 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 mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to GOLAM MAHMUD whose telephone number is (571)270-0385. The examiner can normally be reached Mon-Fri 8.00-5.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, Umar Cheema can be reached on 5712703037. 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.
/GOLAM MAHMUD/Examiner, Art Unit 2458
/UMAR CHEEMA/Supervisory Patent Examiner, Art Unit 2458
Prosecution Insights