Prosecution Insights
Last updated: August 18, 2026
Application No. 18/419,391

Disaster Recovery in Workload Protection Solutions

Final Rejection §103
Filed
Jan 22, 2024
Examiner
ABBATINE JR., MICHAEL WILLIAM
Art Unit
2419
Tech Center
2400 — Computer Networks
Assignee
Cisco Technology Inc.
OA Round
2 (Final)
17%
Grant Probability
At Risk
3-4
OA Rounds
10m
Est. Remaining
-3%
With Interview

Examiner Intelligence

Grants only 17% of cases
17%
Career Allowance Rate
1 granted / 6 resolved
-41.3% vs TC avg
Minimal -20% lift
Without
With
+-20.0%
Interview Lift
resolved cases with interview
Typical timeline
3y 5m
Avg Prosecution
31 currently pending
Career history
69
Total Applications
across all art units

Statute-Specific Performance

§101
2.2%
-37.8% vs TC avg
§103
83.1%
+43.1% vs TC avg
§102
7.6%
-32.4% vs TC avg
§112
6.7%
-33.3% vs TC avg
Black line = Tech Center average estimate • Based on career data from 6 resolved cases

Office Action

§103
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 . This Office Action is in response to the Applicant Arguments/REMARKS correspondence filed on 04/20/2026. Claims 1-20 are pending and rejected. Response to Arguments Applicant’s arguments, see Applicant Arguments/REMARKS, filed 04/20/2026, with respect to the rejection(s) of claim(s) 1-20 under 35 USC 103 have been fully considered and are persuasive. Therefore, the rejection has been withdrawn. However, upon further consideration, a new ground(s) of rejection is made in view of further search and inquiry warranted by the claim amendments. Claim Rejections - 35 USC § 103 In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status. The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action: A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made. The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows: 1. Determining the scope and contents of the prior art. 2. Ascertaining the differences between the prior art and the claims at issue. 3. Resolving the level of ordinary skill in the pertinent art. 4. Considering objective evidence present in the application indicating obviousness or nonobviousness. Claims 1-4 are rejected under 35 U.S.C. 103 as being unpatentable over Ciampaglia et al (US20230090611A1) in view of Yogesh et al (US20240036912A1) in view of Anish et al (US9,984,140B1). Regarding claim 1, Ciampaglia discloses a device, comprising: a processor ([0023], [0051] processor, memory, network system); at least one network interface controller configured to provide access to a network ([0023], [0051] processor, network system); and a memory communicatively coupled to the processor ([0023], [0051] processor, memory, network system), wherein the memory comprises a workload protection logic that is configured to: receive a disaster recovery request ([0075], [0095], discloses communication module 225 receives information such as “a request to perform disaster recover[y]”, and user interface module 260 provides an interface for a user “to request a disaster recovery,” including reconstructing the dataset using an earlier version of the dataset); create a plurality of keys ([0026], [0070], teaches a PII key may be randomly generated by the system, and further discloses an encryption key associated with the PII key with the system storing a mapping of PII keys to corresponding encryption key); execute a disaster recovery process ([0072], [0094], discloses disaster recovery module 255 which recovers an earlier version of a dataset by obtaining a reconstructed dataset, determining intervening redaction requests or actions from a audit log, and restoring the earlier version of the dataset based on the audit log)). However, Ciampaglia fails and Yogesh teaches replicate one or more configuration components of a source network device to one or more target network devices ([0027]-[0029], [0039], [0067], teaches replicating configuration-related components from a source platform/device to a target platform/device because source server 110 queries storage locations for a service to be replicated, captures workload snapshots, and communicates the snapshots to target server 118; further teaches updating the replicated boot/data files with target-platform configurations, including network configurations, and replicating source VM network security and access control configurations on the target VM). It would have been obvious to combine Ciampaglia and Yogesh to a person of ordinary skill in the art before the effective filing date of the claimed invention because both references address recovery of computing resources/data in networked or cloud-based systems and provide complementary teachings for improving continuity after a failure or recovery event. Ciampaglia teaches receiving disaster recovery request and executing a disaster recovery process by reconstructing or restoring a dataset using an earlier version of the dataset and an audit log, while Yogesh teaches replicating workload/configuration-related components from a source platform during failover or migration. A person of ordinary skill in the art would have been motivated to incorporate Yogesh’s source-to-target replication and interval-based snapshot/configuration replication into Ciampaglia’s disaster recovery system to ensure that the recovered dataset or service environment is maintained in an up-to-date replicated state and can be restored or executed on a target platform with reduced downtime. Such a combination would yield device to improve availability, reduce recovery time, and maintain consistency of recovered data/configuration across networked computing environments. However, Yogesh doesn’t fully teach but Anish teaches define a replication interval, wherein if the replication interval expires, a disaster recovery process is triggered (col 15 lines 64-67 & col 16 lines 1-3, 20-41, col 20 lines 7-15 & 29-47 respectively & Fig 7 & 11, discloses that, at every heartbeat time interval, a client process checks lease state and updates replication status, and that if the lease is not renewed by the primary master within a predetermined lease period, the method triggers a semi-automatic failover process; further teaches automatic failover where the secondary master acquires the lease if the primary does not renew, it within the lease interval and assumes the role of primary master-thus teaches defining a time-based replication/lease interval and triggering a failover/disaster recovery process when the interval expires without renewal). It would have been obvious to combine Ciampaglia and Yogesh to a person of ordinary skill in the art before the effective filing date of the claimed invention because both references address recovery of computing resources/data in networked or cloud-based systems and provide complementary teachings for improving continuity after a failure or recovery event. Ciampaglia teaches receiving disaster recovery request and executing a disaster recovery process by reconstructing or restoring a dataset using an earlier version of the dataset and an audit log, while Yogesh teaches replicating workload/configuration-related components from a source platform during failover or migration. Lastly, Anish teaches checking lease/replication status at heartbeat intervals and triggering failover when a primary master fails to renew its lease within a predetermined lease period. Anish is reasonably pertinent because both Anish and the claim address maintaining availability of replicated systems by using a time-based interval to trigger failover/recovery when a primary source system is no longer maintaining the expected state. A person of ordinary skill in the art would have been motivated to incorporate Yogesh’s source-to-target replication and interval-based snapshot/configuration replication into Ciampaglia’s disaster recovery system to ensure that the recovered dataset or service environment is maintained in an up-to-date replicated state and can be restored or executed on a target platform with reduced downtime. Such a combination would yield device to improve availability, reduce recovery time, and maintain consistency of recovered data/configuration across networked computing environments. Regarding claim 2, Ciampaglia teaches the device wherein the disaster recovery request is received in response to a disaster event ([0075], [0095], discloses communication module 225 receives information such as “a request to perform disaster recover[y]”, and user interface module 260 provides an interface for a user “to request a disaster recovery,” including reconstructing the dataset using an earlier version of the dataset). Regarding claim 3, Ciampaglia teaches the device wherein the disaster recovery request is received in response to a time-based event ([0048]-[0049], that system actions may be initiated according to time-based conditions or schedules, such as threshold period of time or predetermined schedule, and further teaches that disaster recovery operations are performed to restore a dataset to an earlier state using an audit log, thereby supporting a recovery request/process being initiated in response to a time-base event). Regarding claim 4, Ciampaglia teaches the device wherein the plurality of keys are application programming interface keys (([0026], [0070], teaches a PII key may be randomly generated by the system, and further discloses an encryption key associated with the PII key with the system storing a mapping of PII keys to corresponding encryption key)). Claims 5-20 are rejected under 35 U.S.C. 103 as being unpatentable over Ciampaglia et al (US20230090611A1) in view of Yogesh et al (US20240036912A1) in view of Anish et al (US9,984,140B1), in further view of Nix (US20190313246A1). Regarding claim 5, Ciampaglia, Yogesh, and Anish fail to teach but Nix teaches the device wherein the network comprises a plurality of network devices ([0232], [0255], explicitly discloses device recording certificate authority certificates and root certificate; devices records root certificates/certificate authority certificates; device records root certificate + intermediate certificates for verification). It would have been obvious to combine Ciampaglia and Yogesh to a person of ordinary skill in the art before the effective filing date of the claimed invention because both references address recovery of computing resources/data in networked or cloud-based systems and provide complementary teachings for improving continuity after a failure or recovery event. Ciampaglia teaches receiving disaster recovery request and executing a disaster recovery process by reconstructing or restoring a dataset using an earlier version of the dataset and an audit log, while Yogesh teaches replicating workload/configuration-related components from a source platform during failover or migration. Lastly, Anish teaches checking lease/replication status at heartbeat intervals and triggering failover when a primary master fails to renew its lease within a predetermined lease period. Anish is reasonably pertinent because both Anish and the claim address maintaining availability of replicated systems by using a time-based interval to trigger failover/recovery when a primary source system is no longer maintaining the expected state. Lastly, Nix teaches securely replicating configuration components to devices using certificate-based trust (including use of root/intermediate certificates and shared trust anchors) and performing backup/restore of configuration data when failures occur. A person of ordinary skill in the art would have been motivated to incorporate Yogesh’s source-to-target replication and interval-based snapshot/configuration replication into Ciampaglia’s disaster recovery system to ensure that the recovered dataset or service environment is maintained in an up-to-date replicated state and can be restored or executed on a target platform with reduced downtime. Such a combination would yield device to improve availability, reduce recovery time, and maintain consistency of recovered data/configuration across networked computing environments. Regarding claim 6, Ciampaglia, Yogesh, and Anish fail to teach but Nix teaches the device wherein the plurality of network devices are configured with security certificates ([0232], [0255], explicitly discloses device recording certificate authority certificates and root certificate; devices records root certificates/certificate authority certificates; device records root certificate + intermediate certificates for verification). It would have been obvious to combine Ciampaglia and Yogesh to a person of ordinary skill in the art before the effective filing date of the claimed invention because both references address recovery of computing resources/data in networked or cloud-based systems and provide complementary teachings for improving continuity after a failure or recovery event. Ciampaglia teaches receiving disaster recovery request and executing a disaster recovery process by reconstructing or restoring a dataset using an earlier version of the dataset and an audit log, while Yogesh teaches replicating workload/configuration-related components from a source platform during failover or migration. Lastly, Anish teaches checking lease/replication status at heartbeat intervals and triggering failover when a primary master fails to renew its lease within a predetermined lease period. Anish is reasonably pertinent because both Anish and the claim address maintaining availability of replicated systems by using a time-based interval to trigger failover/recovery when a primary source system is no longer maintaining the expected state. Lastly, Nix teaches securely replicating configuration components to devices using certificate-based trust (including use of root/intermediate certificates and shared trust anchors) and performing backup/restore of configuration data when failures occur. A person of ordinary skill in the art would have been motivated to incorporate Yogesh’s source-to-target replication and interval-based snapshot/configuration replication into Ciampaglia’s disaster recovery system to ensure that the recovered dataset or service environment is maintained in an up-to-date replicated state and can be restored or executed on a target platform with reduced downtime. Such a combination would yield device to improve availability, reduce recovery time, and maintain consistency of recovered data/configuration across networked computing environments. Regarding claim 7, Ciampaglia, Yogesh, and Anish fail to teach but Nix teaches the device wherein the security certificates are identical across the plurality of network devices ([0232], explicitly supports “identical across devices” by stating certificate authorities in the system can share the same root certificate (i.e. an identical root/trust-anchor certificate across multiple entities; could share the same root certificate). It would have been obvious to combine Ciampaglia and Yogesh to a person of ordinary skill in the art before the effective filing date of the claimed invention because both references address recovery of computing resources/data in networked or cloud-based systems and provide complementary teachings for improving continuity after a failure or recovery event. Ciampaglia teaches receiving disaster recovery request and executing a disaster recovery process by reconstructing or restoring a dataset using an earlier version of the dataset and an audit log, while Yogesh teaches replicating workload/configuration-related components from a source platform during failover or migration. Lastly, Anish teaches checking lease/replication status at heartbeat intervals and triggering failover when a primary master fails to renew its lease within a predetermined lease period. Anish is reasonably pertinent because both Anish and the claim address maintaining availability of replicated systems by using a time-based interval to trigger failover/recovery when a primary source system is no longer maintaining the expected state. Lastly, Nix teaches securely replicating configuration components to devices using certificate-based trust (including use of root/intermediate certificates and shared trust anchors) and performing backup/restore of configuration data when failures occur. A person of ordinary skill in the art would have been motivated to incorporate Yogesh’s source-to-target replication and interval-based snapshot/configuration replication into Ciampaglia’s disaster recovery system to ensure that the recovered dataset or service environment is maintained in an up-to-date replicated state and can be restored or executed on a target platform with reduced downtime. Such a combination would yield device to improve availability, reduce recovery time, and maintain consistency of recovered data/configuration across networked computing environments. Regarding claim 8, Ciampaglia, Yogesh, and Anish fail to teach but Nix teaches the device wherein the replication of the one or more configuration components comprises at least: querying a source network device for one or more configurations ([0190], [0192]-[0193], expressly teaches selecting/identifying nodes and querying sources to obtain information needed for configuration package creation, including querying an access network for credentials); copying the one or more configurations ([0018]-[0019], [0237], teaches the configuration server collecting configuration files/credentials for a configuration package and sending them to the device); replicating the one or more configurations to a target network device ([0019], [0237], explicitly sends a configuration package to the device where the device records/applies it). It would have been obvious to combine Ciampaglia and Yogesh to a person of ordinary skill in the art before the effective filing date of the claimed invention because both references address recovery of computing resources/data in networked or cloud-based systems and provide complementary teachings for improving continuity after a failure or recovery event. Ciampaglia teaches receiving disaster recovery request and executing a disaster recovery process by reconstructing or restoring a dataset using an earlier version of the dataset and an audit log, while Yogesh teaches replicating workload/configuration-related components from a source platform during failover or migration. Lastly, Anish teaches checking lease/replication status at heartbeat intervals and triggering failover when a primary master fails to renew its lease within a predetermined lease period. Anish is reasonably pertinent because both Anish and the claim address maintaining availability of replicated systems by using a time-based interval to trigger failover/recovery when a primary source system is no longer maintaining the expected state. Lastly, Nix teaches securely replicating configuration components to devices using certificate-based trust (including use of root/intermediate certificates and shared trust anchors) and performing backup/restore of configuration data when failures occur. A person of ordinary skill in the art would have been motivated to incorporate Yogesh’s source-to-target replication and interval-based snapshot/configuration replication into Ciampaglia’s disaster recovery system to ensure that the recovered dataset or service environment is maintained in an up-to-date replicated state and can be restored or executed on a target platform with reduced downtime. Such a combination would yield device to improve availability, reduce recovery time, and maintain consistency of recovered data/configuration across networked computing environments. Regarding claim 9, Ciampaglia, Yogesh, and Anish fail to teach but Nix teaches the device wherein executing the disaster recovery process comprises at least: determining a plurality of configurations to replicate ([0018]-[0019], [0236], teaches collecting a configuration package which includes multiple configuration files/parameters (plurality); selecting one or more target network devices ([0192]-[0193], [0237], centered around the system preparing/collecting a configuration package for the device (target); and replicating the plurality of configurations to the one or more target network devices ([0237], device records files and loads the configuration package). It would have been obvious to combine Ciampaglia and Yogesh to a person of ordinary skill in the art before the effective filing date of the claimed invention because both references address recovery of computing resources/data in networked or cloud-based systems and provide complementary teachings for improving continuity after a failure or recovery event. Ciampaglia teaches receiving disaster recovery request and executing a disaster recovery process by reconstructing or restoring a dataset using an earlier version of the dataset and an audit log, while Yogesh teaches replicating workload/configuration-related components from a source platform during failover or migration. Lastly, Anish teaches checking lease/replication status at heartbeat intervals and triggering failover when a primary master fails to renew its lease within a predetermined lease period. Anish is reasonably pertinent because both Anish and the claim address maintaining availability of replicated systems by using a time-based interval to trigger failover/recovery when a primary source system is no longer maintaining the expected state. Lastly, Nix teaches securely replicating configuration components to devices using certificate-based trust (including use of root/intermediate certificates and shared trust anchors) and performing backup/restore of configuration data when failures occur. A person of ordinary skill in the art would have been motivated to incorporate Yogesh’s source-to-target replication and interval-based snapshot/configuration replication into Ciampaglia’s disaster recovery system to ensure that the recovered dataset or service environment is maintained in an up-to-date replicated state and can be restored or executed on a target platform with reduced downtime. Such a combination would yield device to improve availability, reduce recovery time, and maintain consistency of recovered data/configuration across networked computing environments. Regarding claim 10, Ciampaglia, Yogesh, and Anish fail to teach but Nix teaches the device wherein the replication of at least two of the one or more configuration components are done in parallel ([0192]-[0193], describes the configuration system communicating with several elements/nodes to collect files for the configuration package, which supports obtaining/collecting multiple configuration components in a distributed manner (including parallelized secure session setups and collection). It would have been obvious to combine Ciampaglia and Yogesh to a person of ordinary skill in the art before the effective filing date of the claimed invention because both references address recovery of computing resources/data in networked or cloud-based systems and provide complementary teachings for improving continuity after a failure or recovery event. Ciampaglia teaches receiving disaster recovery request and executing a disaster recovery process by reconstructing or restoring a dataset using an earlier version of the dataset and an audit log, while Yogesh teaches replicating workload/configuration-related components from a source platform during failover or migration. Lastly, Anish teaches checking lease/replication status at heartbeat intervals and triggering failover when a primary master fails to renew its lease within a predetermined lease period. Anish is reasonably pertinent because both Anish and the claim address maintaining availability of replicated systems by using a time-based interval to trigger failover/recovery when a primary source system is no longer maintaining the expected state. Lastly, Nix teaches securely replicating configuration components to devices using certificate-based trust (including use of root/intermediate certificates and shared trust anchors) and performing backup/restore of configuration data when failures occur. A person of ordinary skill in the art would have been motivated to incorporate Yogesh’s source-to-target replication and interval-based snapshot/configuration replication into Ciampaglia’s disaster recovery system to ensure that the recovered dataset or service environment is maintained in an up-to-date replicated state and can be restored or executed on a target platform with reduced downtime. Such a combination would yield device to improve availability, reduce recovery time, and maintain consistency of recovered data/configuration across networked computing environments. Regarding claim 11, Ciampaglia fails to teach but Yogesh teaches the device wherein the configuration components include at least one of: user defined labels, scopes, inventory filters, agent profiles, agent intents, workspaces, workspace policies, or workspace clusters ([0039], [0060], [0067], replicating configuration-related components from a source platform to a target platform, including VM configurations, network configurations, and network security/access-control configurations; configuration files, network configurations, security access/control configurations, VM configurations, source-to-target replication). It would have been obvious to combine Ciampaglia and Yogesh to a person of ordinary skill in the art before the effective filing date of the claimed invention because both references address recovery of computing resources/data in networked or cloud-based systems and provide complementary teachings for improving continuity after a failure or recovery event. Ciampaglia teaches receiving disaster recovery request and executing a disaster recovery process by reconstructing or restoring a dataset using an earlier version of the dataset and an audit log, while Yogesh teaches replicating workload/configuration-related components from a source platform during failover or migration. Lastly, Anish teaches checking lease/replication status at heartbeat intervals and triggering failover when a primary master fails to renew its lease within a predetermined lease period. Anish is reasonably pertinent because both Anish and the claim address maintaining availability of replicated systems by using a time-based interval to trigger failover/recovery when a primary source system is no longer maintaining the expected state. Lastly, Nix teaches securely replicating configuration components to devices using certificate-based trust (including use of root/intermediate certificates and shared trust anchors) and performing backup/restore of configuration data when failures occur. A person of ordinary skill in the art would have been motivated to incorporate Yogesh’s source-to-target replication and interval-based snapshot/configuration replication into Ciampaglia’s disaster recovery system to ensure that the recovered dataset or service environment is maintained in an up-to-date replicated state and can be restored or executed on a target platform with reduced downtime. Such a combination would yield device to improve availability, reduce recovery time, and maintain consistency of recovered data/configuration across networked computing environments. Regarding claim 12, Ciampaglia fails to teach but Yogesh teaches the device wherein the configuration components include at least one of: user roles, user accounts, exclusion filters, external orchestrators, client server configurations, forensics profiles and intents, policy templates, collection rules, default application dependency mapping configuration, alert configurations, or connectors ([0039], [0060], [0067], replicating configuration-related components from a source platform to a target platform, including VM configurations, network configurations, and network security/access-control configurations; configuration files, network configurations, security access/control configurations, VM configurations, source-to-target replication). It would have been obvious to combine Ciampaglia and Yogesh to a person of ordinary skill in the art before the effective filing date of the claimed invention because both references address recovery of computing resources/data in networked or cloud-based systems and provide complementary teachings for improving continuity after a failure or recovery event. Ciampaglia teaches receiving disaster recovery request and executing a disaster recovery process by reconstructing or restoring a dataset using an earlier version of the dataset and an audit log, while Yogesh teaches replicating workload/configuration-related components from a source platform during failover or migration. Lastly, Anish teaches checking lease/replication status at heartbeat intervals and triggering failover when a primary master fails to renew its lease within a predetermined lease period. Anish is reasonably pertinent because both Anish and the claim address maintaining availability of replicated systems by using a time-based interval to trigger failover/recovery when a primary source system is no longer maintaining the expected state. Lastly, Nix teaches securely replicating configuration components to devices using certificate-based trust (including use of root/intermediate certificates and shared trust anchors) and performing backup/restore of configuration data when failures occur. A person of ordinary skill in the art would have been motivated to incorporate Yogesh’s source-to-target replication and interval-based snapshot/configuration replication into Ciampaglia’s disaster recovery system to ensure that the recovered dataset or service environment is maintained in an up-to-date replicated state and can be restored or executed on a target platform with reduced downtime. Such a combination would yield device to improve availability, reduce recovery time, and maintain consistency of recovered data/configuration across networked computing environments. Regarding claim 13, Ciampaglia teaches the device wherein the workload protection logic is further configured to determine a recovery interval ([0041]-[0045], [0048]-[0049], time-based processing using a threshold period of time, predetermined schedule, and threshold shutdown time for deletion/forgetting operations, and separately teaches disaster recovery using an audit log to restore a dataset to an earlier state). Regarding claim 14, Ciampaglia teaches the device wherein the recovery interval is dynamically determined ([0041]-[0045], [0048]-[0049], time-based processing using a threshold period of time, predetermined schedule, and threshold shutdown time for deletion/forgetting operations, and separately teaches disaster recovery using an audit log to restore a dataset to an earlier state). Regarding claim 15, Ciampaglia teaches the device wherein the dynamic determination is based on an event ([0041]-[0045], [0048]-[0049], time-based processing using a threshold period of time, predetermined schedule, and threshold shutdown time for deletion/forgetting operations, and separately teaches disaster recovery using an audit log to restore a dataset to an earlier state). Regarding claim 16, Ciampaglia teaches the device wherein the event is one of: receiving a warning notification ([0075], [0095], discloses communication module 225 receives information such as “a request to perform disaster recover[y]”, and user interface module 260 provides an interface for a user “to request a disaster recovery,” including reconstructing the dataset using an earlier version of the dataset), receiving a command to change the recovery interval ([0075], [0095], discloses communication module 225 receives information such as “a request to perform disaster recover[y]”, and user interface module 260 provides an interface for a user “to request a disaster recovery,” including reconstructing the dataset using an earlier version of the dataset; [0041]-[0045], [0048]-[0049], time-based processing using a threshold period of time, predetermined schedule, and threshold shutdown time for deletion/forgetting operations, and separately teaches disaster recovery using an audit log to restore a dataset to an earlier state), or But Ciampaglia, Yogesh and Anish fails to teach determining that one or more connection problems are present. However, Nix teaches determining that one or more connection problems are present ([0236]-[0237], expressly teaches detecting failure conditions such as failed signature verification or refusing to process a configuration package—these correspond to connection/communication problems or integrity/authentication problems during secure session data transfer). It would have been obvious to combine Ciampaglia and Yogesh to a person of ordinary skill in the art before the effective filing date of the claimed invention because both references address recovery of computing resources/data in networked or cloud-based systems and provide complementary teachings for improving continuity after a failure or recovery event. Ciampaglia teaches receiving disaster recovery request and executing a disaster recovery process by reconstructing or restoring a dataset using an earlier version of the dataset and an audit log, while Yogesh teaches replicating workload/configuration-related components from a source platform during failover or migration. Lastly, Anish teaches checking lease/replication status at heartbeat intervals and triggering failover when a primary master fails to renew its lease within a predetermined lease period. Anish is reasonably pertinent because both Anish and the claim address maintaining availability of replicated systems by using a time-based interval to trigger failover/recovery when a primary source system is no longer maintaining the expected state. Lastly, Nix teaches securely replicating configuration components to devices using certificate-based trust (including use of root/intermediate certificates and shared trust anchors) and performing backup/restore of configuration data when failures occur. A person of ordinary skill in the art would have been motivated to incorporate Yogesh’s source-to-target replication and interval-based snapshot/configuration replication into Ciampaglia’s disaster recovery system to ensure that the recovered dataset or service environment is maintained in an up-to-date replicated state and can be restored or executed on a target platform with reduced downtime. Such a combination would yield device to improve availability, reduce recovery time, and maintain consistency of recovered data/configuration across networked computing environments. Regarding claim 17, Ciampaglia teaches A device, comprising: a processor ([0023], [0051] processor, memory, network system); at least one network interface controller configured to provide access to a network ([0023], [0051] processor, memory, network system); and a memory communicatively coupled to the processor ([0023], [0051] processor, memory, network system), wherein the memory receive a disaster recovery request ([0075], [0095], discloses communication module 225 receives information such as “a request to perform disaster recover[y]”, and user interface module 260 provides an interface for a user “to request a disaster recovery,” including reconstructing the dataset using an earlier version of the dataset); However, Ciampaglia fails to teach but Yogesh teaches replicate one or more configuration components from the source network device wherein the one or more configurations of the source network device are replicated to target network devices ([0027]-[0029], [0039], [0067], teaches replicating configuration-related components from a source platform/device to a target platform/device because source server 110 queries storage locations for a service to be replicated, captures workload snapshots, and communicates the snapshots to target server 118; further teaches updating the replicated boot/data files with target-platform configurations, including network configurations, and replicating source VM network security and access control configurations on the target VM). It would have been obvious to combine Ciampaglia and Yogesh to a person of ordinary skill in the art before the effective filing date of the claimed invention because both references address recovery of computing resources/data in networked or cloud-based systems and provide complementary teachings for improving continuity after a failure or recovery event. Ciampaglia teaches receiving disaster recovery request and executing a disaster recovery process by reconstructing or restoring a dataset using an earlier version of the dataset and an audit log, while Yogesh teaches replicating workload/configuration-related components from a source platform during failover or migration. A person of ordinary skill in the art would have been motivated to incorporate Yogesh’s source-to-target replication and interval-based snapshot/configuration replication into Ciampaglia’s disaster recovery system to ensure that the recovered dataset or service environment is maintained in an up-to-date replicated state and can be restored or executed on a target platform with reduced downtime. Such a combination would yield device to improve availability, reduce recovery time, and maintain consistency of recovered data/configuration across networked computing environments. However, Yogesh doesn’t fully teach but Anish teaches define a replication interval, wherein a disaster recovery process is triggered in response to the replication interval expires (col 15 lines 64-67 & col 16 lines 1-3, 20-41, col 20 lines 7-15 & 29-47 respectively & Fig 7 & 11, discloses that, at every heartbeat time interval, a client process checks lease state and updates replication status, and that if the lease is not renewed by the primary master within a predetermined lease period, the method triggers a semi-automatic failover process; further teaches automatic failover where the secondary master acquires the lease if the primary does not renew, it within the lease interval and assumes the role of primary master-thus teaches defining a time-based replication/lease interval and triggering a failover/disaster recovery process when the interval expires without renewal). It would have been obvious to combine Ciampaglia and Yogesh to a person of ordinary skill in the art before the effective filing date of the claimed invention because both references address recovery of computing resources/data in networked or cloud-based systems and provide complementary teachings for improving continuity after a failure or recovery event. Ciampaglia teaches receiving disaster recovery request and executing a disaster recovery process by reconstructing or restoring a dataset using an earlier version of the dataset and an audit log, while Yogesh teaches replicating workload/configuration-related components from a source platform during failover or migration. Lastly, Anish teaches checking lease/replication status at heartbeat intervals and triggering failover when a primary master fails to renew its lease within a predetermined lease period. Anish is reasonably pertinent because both Anish and the claim address maintaining availability of replicated systems by using a time-based interval to trigger failover/recovery when a primary source system is no longer maintaining the expected state. A person of ordinary skill in the art would have been motivated to incorporate Yogesh’s source-to-target replication and interval-based snapshot/configuration replication into Ciampaglia’s disaster recovery system to ensure that the recovered dataset or service environment is maintained in an up-to-date replicated state and can be restored or executed on a target platform with reduced downtime. Such a combination would yield device to improve availability, reduce recovery time, and maintain consistency of recovered data/configuration across networked computing environments. But Anish fails to teach: comprises a workload protection logic that is configured to: establish a connection with a plurality of network devices on the network; configure identical security certificates on each of the plurality of network devices; determine at least one target network device; select a source network device from the plurality of network devices; replicate one or more configuration components from the source network device; and apply the one or more configuration components to the target network device. However, Nix teaches comprises a workload protection logic that is configured to: establish a connection with a plurality of network devices on the network ([0016]-[0019], [0181], teaches establishing secure sessions between different entities (device [Wingdings font/0xDF][Wingdings font/0xE0] configuration server, mobile phone [Wingdings font/0xDF][Wingdings font/0xE0] configuration server), which is establishing connections among multiple network devices in the system); configure identical security certificates on each of the plurality of network devices ([0130], [0133], [0232], supports deployment shared/identical trust anchors by describing root certificates recorded by the device and/or shared root certificates across certificate authorities; ; determine at least one target network device ([0017]-[0019], describes preparing a configuration package for the device (target) based on identity information gathered and stored in a configuration database; identifies list gathered; configuration system records identities and collects a configuration package for the device); select a source network device from the plurality of network devices ([0190], [0192]-[0193], teaches selecting among possible sources (e.g. preferred access network and/or nodes in the system) and querying them for information/credentials/configuration data); apply the one or more configuration components to the target network device ([0019], [0237], expressly teaches applying the configuration package and using it to update the device). It would have been obvious to combine Ciampaglia and Yogesh to a person of ordinary skill in the art before the effective filing date of the claimed invention because both references address recovery of computing resources/data in networked or cloud-based systems and provide complementary teachings for improving continuity after a failure or recovery event. Ciampaglia teaches receiving disaster recovery request and executing a disaster recovery process by reconstructing or restoring a dataset using an earlier version of the dataset and an audit log, while Yogesh teaches replicating workload/configuration-related components from a source platform during failover or migration. Lastly, Anish teaches checking lease/replication status at heartbeat intervals and triggering failover when a primary master fails to renew its lease within a predetermined lease period. Anish is reasonably pertinent because both Anish and the claim address maintaining availability of replicated systems by using a time-based interval to trigger failover/recovery when a primary source system is no longer maintaining the expected state. Lastly, Nix teaches securely replicating configuration components to devices using certificate-based trust (including use of root/intermediate certificates and shared trust anchors) and performing backup/restore of configuration data when failures occur. A person of ordinary skill in the art would have been motivated to incorporate Yogesh’s source-to-target replication and interval-based snapshot/configuration replication into Ciampaglia’s disaster recovery system to ensure that the recovered dataset or service environment is maintained in an up-to-date replicated state and can be restored or executed on a target platform with reduced downtime. Such a combination would yield device to improve availability, reduce recovery time, and maintain consistency of recovered data/configuration across networked computing environments. Regarding claim 18, Ciampaglia, Yogesh, and Anish fail to teach but Nix teaches but Nix teaches the device wherein the disaster recovery request is received in response to an event ([0237], describes situations where applying configuration updates may fail, and the device restores a prior backed-up configuration; this maps well to “disaster recovery” being invoked in response to a failure/adverse condition (i.e. disaster event) – supporting a disaster event as an operational failure/error condition triggering recovery). It would have been obvious to combine Ciampaglia and Yogesh to a person of ordinary skill in the art before the effective filing date of the claimed invention because both references address recovery of computing resources/data in networked or cloud-based systems and provide complementary teachings for improving continuity after a failure or recovery event. Ciampaglia teaches receiving disaster recovery request and executing a disaster recovery process by reconstructing or restoring a dataset using an earlier version of the dataset and an audit log, while Yogesh teaches replicating workload/configuration-related components from a source platform during failover or migration. Lastly, Anish teaches checking lease/replication status at heartbeat intervals and triggering failover when a primary master fails to renew its lease within a predetermined lease period. Anish is reasonably pertinent because both Anish and the claim address maintaining availability of replicated systems by using a time-based interval to trigger failover/recovery when a primary source system is no longer maintaining the expected state. Lastly, Nix teaches securely replicating configuration components to devices using certificate-based trust (including use of root/intermediate certificates and shared trust anchors) and performing backup/restore of configuration data when failures occur. A person of ordinary skill in the art would have been motivated to incorporate Yogesh’s source-to-target replication and interval-based snapshot/configuration replication into Ciampaglia’s disaster recovery system to ensure that the recovered dataset or service environment is maintained in an up-to-date replicated state and can be restored or executed on a target platform with reduced downtime. Such a combination would yield device to improve availability, reduce recovery time, and maintain consistency of recovered data/configuration across networked computing environments. Regarding claim 19, Ciampaglia teaches the device wherein the event is one of: receiving a warning notification ([0075], [0095], discloses communication module 225 receives information such as “a request to perform disaster recover[y]”, and user interface module 260 provides an interface for a user “to request a disaster recovery,” including reconstructing the dataset using an earlier version of the dataset), or But Ciampaglia fails to teach determining that one or more connection problems are present. Nix teaches determining that one or more connection problems are present ([0016], [0236], supports detecting secure session/authentication failures and refusing processing, which correspond to connection/session problems). It would have been obvious to combine Ciampaglia and Yogesh to a person of ordinary skill in the art before the effective filing date of the claimed invention because both references address recovery of computing resources/data in networked or cloud-based systems and provide complementary teachings for improving continuity after a failure or recovery event. Ciampaglia teaches receiving disaster recovery request and executing a disaster recovery process by reconstructing or restoring a dataset using an earlier version of the dataset and an audit log, while Yogesh teaches replicating workload/configuration-related components from a source platform during failover or migration. Lastly, Anish teaches checking lease/replication status at heartbeat intervals and triggering failover when a primary master fails to renew its lease within a predetermined lease period. Anish is reasonably pertinent because both Anish and the claim address maintaining availability of replicated systems by using a time-based interval to trigger failover/recovery when a primary source system is no longer maintaining the expected state. Lastly, Nix teaches securely replicating configuration components to devices using certificate-based trust (including use of root/intermediate certificates and shared trust anchors) and performing backup/restore of configuration data when failures occur. A person of ordinary skill in the art would have been motivated to incorporate Yogesh’s source-to-target replication and interval-based snapshot/configuration replication into Ciampaglia’s disaster recovery system to ensure that the recovered dataset or service environment is maintained in an up-to-date replicated state and can be restored or executed on a target platform with reduced downtime. Such a combination would yield device to improve availability, reduce recovery time, and maintain consistency of recovered data/configuration across networked computing environments. Regarding claim 20, Ciampaglia teaches a method generating an application dependency mapping, comprising: receive a disaster recovery request ([0075], [0095], discloses communication module 225 receives information such as “a request to perform disaster recover[y]”, and user interface module 260 provides an interface for a user “to request a disaster recovery,” including reconstructing the dataset using an earlier version of the dataset); However, Ciampaglia fails to teach but Yogesh teaches replicate one or more configuration components from the source network device to target network devices ([0027]-[0029], [0039], [0067], teaches replicating configuration-related components from a source platform/device to a target platform/device because source server 110 queries storage locations for a service to be replicated, captures workload snapshots, and communicates the snapshots to target server 118; further teaches updating the replicated boot/data files with target-platform configurations, including network configurations, and replicating source VM network security and access control configurations on the target VM). However, Yogesh doesn’t fully teach but Anish teaches define a replication interval, wherein a disaster recovery process is triggered in response to the replication interval expires (col 15 lines 64-67 & col 16 lines 1-3, 20-41, col 20 lines 7-15 & 29-47 respectively & Fig 7 & 11, discloses that, at every heartbeat time interval, a client process checks lease state and updates replication status, and that if the lease is not renewed by the primary master within a predetermined lease period, the method triggers a semi-automatic failover process; further teaches automatic failover where the secondary master acquires the lease if the primary does not renew, it within the lease interval and assumes the role of primary master-thus teaches defining a time-based replication/lease interval and triggering a failover/disaster recovery process when the interval expires without renewal). It would have been obvious to combine Ciampaglia and Yogesh to a person of ordinary skill in the art before the effective filing date of the claimed invention because both references address recovery of computing resources/data in networked or cloud-based systems and provide complementary teachings for improving continuity after a failure or recovery event. Ciampaglia teaches receiving disaster recovery request and executing a disaster recovery process by reconstructing or restoring a dataset using an earlier version of the dataset and an audit log, while Yogesh teaches replicating workload/configuration-related components from a source platform during failover or migration. Lastly, Anish teaches checking lease/replication status at heartbeat intervals and triggering failover when a primary master fails to renew its lease within a predetermined lease period. Anish is reasonably pertinent because both Anish and the claim address maintaining availability of replicated systems by using a time-based interval to trigger failover/recovery when a primary source system is no longer maintaining the expected state. A person of ordinary skill in the art would have been motivated to incorporate Yogesh’s source-to-target replication and interval-based snapshot/configuration replication into Ciampaglia’s disaster recovery system to ensure that the recovered dataset or service environment is maintained in an up-to-date replicated state and can be restored or executed on a target platform with reduced downtime. Such a combination would yield device to improve availability, reduce recovery time, and maintain consistency of recovered data/configuration across networked computing environments. But Anish fails to teach configure identical security certificates on a plurality of network devices; determine at least one target network device; select a source network device from the plurality of network devices; replicate one or more configuration components from the source network device; and apply the one or more configuration components to the target network device. However, Nix teaches— configure identical security certificates on a plurality of network devices ([0133], [0232], supports shared root certificates and certificate-based trust across devices and servers); determine at least one target network device ([0017]-[0019], supports selecting/configuring a specific device target based on identity information and generating its configuration package); select a source network device from the plurality of network devices ([0190], [0192]-[0193], supports choosing a preferred access network and querying nodes/elements to obtain data); apply the one or more configuration components to the target network device ([0019], [0237], expressly discloses applying configuration files from the configuration package). It would have been obvious to combine Ciampaglia and Yogesh to a person of ordinary skill in the art before the effective filing date of the claimed invention because both references address recovery of computing resources/data in networked or cloud-based systems and provide complementary teachings for improving continuity after a failure or recovery event. Ciampaglia teaches receiving disaster recovery request and executing a disaster recovery process by reconstructing or restoring a dataset using an earlier version of the dataset and an audit log, while Yogesh teaches replicating workload/configuration-related components from a source platform during failover or migration. Lastly, Anish teaches checking lease/replication status at heartbeat intervals and triggering failover when a primary master fails to renew its lease within a predetermined lease period. Anish is reasonably pertinent because both Anish and the claim address maintaining availability of replicated systems by using a time-based interval to trigger failover/recovery when a primary source system is no longer maintaining the expected state. Lastly, Nix teaches securely replicating configuration components to devices using certificate-based trust (including use of root/intermediate certificates and shared trust anchors) and performing backup/restore of configuration data when failures occur. A person of ordinary skill in the art would have been motivated to incorporate Yogesh’s source-to-target replication and interval-based snapshot/configuration replication into Ciampaglia’s disaster recovery system to ensure that the recovered dataset or service environment is maintained in an up-to-date replicated state and can be restored or executed on a target platform with reduced downtime. Such a combination would yield device to improve availability, reduce recovery time, and maintain consistency of recovered data/configuration across networked computing environments. 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 MICHAEL WILLIAM ABBATINE whose telephone number is (571)272-0192. The examiner can normally be reached Monday-Friday 0830-1700 EST. 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, Nishant Divecha can be reached at (571) 270-3125. 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. /MICHAEL WILLIAM ABBATINE JR./Examiner, Art Unit 2419 /Nishant Divecha/Supervisory Patent Examiner, Art Unit 2419
Read full office action

Prosecution Timeline

Jan 22, 2024
Application Filed
Jan 26, 2026
Non-Final Rejection mailed — §103
Mar 17, 2026
Applicant Interview (Telephonic)
Mar 18, 2026
Examiner Interview Summary
Apr 20, 2026
Response Filed
Jun 10, 2026
Final Rejection mailed — §103 (current)

Precedent Cases

Applications granted by this same examiner with similar technology

Patent 12647205
METHOD AND DEVICE FOR APPLYING OPTIMIZED PHASE ROTATION TO BROADBAND IN WIRELESS LAN SYSTEM
3y 7m to grant Granted Jun 02, 2026
Study what changed to get past this examiner. Based on 1 most recent grants.

Strategy Recommendation AI-generated — please review before filing

Get a prosecution strategy drawn from examiner precedents, rejection analysis, and claim mapping.
Typically takes 5-10 seconds — AI-generated, attorney review required before filing

Prosecution Projections

3-4
Expected OA Rounds
17%
Grant Probability
-3%
With Interview (-20.0%)
3y 5m (~10m remaining)
Median Time to Grant
Moderate
PTA Risk
Based on 6 resolved cases by this examiner. Grant probability derived from career allowance rate.

Sign in with your work email

Enter your email to receive a magic link. No password needed.

Personal email addresses (Gmail, Yahoo, etc.) are not accepted.

Free tier: 3 strategy analyses per month