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 Office Action is in response to the application filed on 06/24/2024. Claims 1, 16, and 20 are independent claims. Claims 1-20 have been examined and are pending. This Action is made non-FINAL.
Priority
This application is a continuation-in-part (CIP) of application 18/675,494, filed May 28, 2024 (the parent application), and was filed June 26, 2024 (the CIP filing date). The CIP application includes new figures 6F, 6G, 11A, 11B, 11C, and 12 with associated description paragraphs [0169]-[0180] and [0220]-[0250] that were not present in the parent application. The Examiner has determined that claim 1 is provisionally entitled to the parent filing date of May 28, 2024 based on the general testing process described in the parent application. Claims 2 through 15 are entitled only to the CIP filing date of June 26, 2024 because their limitations find written description support only in paragraphs of publication specification [0169]-[0180] and [0220]-[0250] associated with new figures 6F, 6G, 11A, 11B, 11C, and 12, which were not disclosed in the parent application.
Information Disclosure Statement
The information disclosure statement (IDS), submitted on 09/30/2024, 01/16/2025, 03/17/2025, 04/29/2025, 05/20/205, 06/30/2025, 07/30/2025, 08/26/2025, 10/30/2025, 01/30/2026 is being considered by the examiner.
Drawings
The drawings were received on 06/24/2024. These drawings are reviewed and accepted by the Examiner.
Claim Objections
Claim 17 is objected to because of the following informalities:
Regarding claim 17, claim 17 recites limitation “the current CA certificate” in line 20. It appears that this is a typographical error. It is suggested that “the current CA certificate” should read “the new CA certificate” to be consistent with the preceding limitation of claim 17 and the corresponding limitation of claim 8
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.
Claims 1-3, 15-16, 18, and 19-20 are rejected under 35 U.S.C. 103 as being unpatentable over Martinez De La Cruz et al. (“Martinez”, EP 4000296) in view of Singhal et al. (“Singhal,” US 2022/0141085), and further in view of Bhalerao (“Bhalerao,” US 2015/0095995).
Regarding claim 1, Martinez teaches a or more non-transitory computer-readable media storing instructions that, when executed by one or more hardware processors, cause performance of operations comprising:
(a) receiving a new certificate authority (CA) certificate for installation in an execution environment of a virtual cloud network to supersede a current CA certificate installed in the execution environment (Martinez: par. [0092], "CA certificates must be updated... service producer NF 107E thus updates its NF profile with a new value for the caCertificates attribute" , "an NF can be implemented...as a virtualised function instantiated on an appropriate platform, e.g., on a cloud infrastructure; par. [0100], "each concerned service consumer NF has UPDATED its CA certificate(s)"; par. [0092]: "CA certificates in need of updating have previously been communicated in the core network domain") ;
Martinez does not explicitly disclose (b) orchestrating a testing process for performing…: (c) maintaining a set of testing configurations …; (d) receiving a first configuration update for rolling forward …; (e) responsive to receiving the first configuration update …
However, in an analogous art, Bhalerao discloses
(b) orchestrating a testing process for performing a set of one or more testing operations in the execution environment pertaining to the new CA certificate prior to the new CA certificate superseding the current CA certificate (Singhal: par. [0051] "The server side (cloud control plane) can provide canary deployments of configuration changes. A canary deployment, or deployment to a subset, may control a sudden impact of the configuration change and test out the changes.”), wherein orchestrating the testing process comprises:
(c) maintaining a set of testing configurations for a set of one or more network entities (Singhal: par. [0107], "a status for canary deployment (e.g., a cluster is selected for receiving and applying a configuration update to see if the update is effective)"; par. [0051], "each configuration change can be audited per cluster");
(d) receiving a first configuration update for rolling forward a first testing configuration for a first network entity of the set of one or more network entities (Singhal: par. 0107, "The processor determines whether a configuration update for one of the list of streams is available"; "If the processor determines that the configuration update is available, the processor sends the configuration update to the cluster"; Abstract "receive...an indication that the cluster received a configuration update");
(e) responsive to receiving the first configuration update, rolling forward the first testing configuration at least by configuring the first testing configuration” (Singhal: par. [0107] "a status for canary deployment (e.g., a cluster is selected for receiving and applying a configuration update)"; Abstract, "compare a first parameter of a configuration state of the node to a second parameter of the configuration update... apply the configuration update".);
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Singha with the method and system of Martinez to include “(b) orchestrating a testing process for performing a set of one or more testing operations …” “(c) maintaining a set of testing configurations for a set of one or more network entities;” “(d)receiving a first configuration update for rolling forward a first testing configuration for a first network entity of the set of one or more network entities; “ (e) responsive to receiving the first configuration update, rolling forward the first testing configuration at least by configuring the first testing configuration”. One would have been motivated because Singhal itself identifies the need to safely test configuration changes on a subset of virtual computing entities before full deployment, and a CA certificate update is precisely the type of configuration change that would benefit from Singhal's canary testing approach — controlling itssudden impact across a large network before full supersession (Singha: pars. 0003. 00051).
Singha teaches (e) responsive to receiving the first configuration update, rolling forward the first testing configuration at least by configuring the first testing configuration but does not explicitly disclose
“to indicate that a certificate issuance process is to use the new CA certificate for issuing entity certificates for the first network entity” (f) receiving a first request for a first entity certificate for the first network entity; (g) based on the first testing configuration, issuing the first entity certificate for the first network entity using the new CA certificate.
However, in an analogous art, Bhalerao discloses
“testing configuration to indicate that a certificate issuance process is to use the new CA certificate for issuing entity certificates for the first network entity” (Bhalerao: abstract: "A customer server creates a certificate profile and receives an associated profile identifier from a CA.". "If the customer changes information associated with the certificate profile, the CA may generate updated certificate based on the certificate profile changes." )
(f) receiving a first request for a first entity certificate for the first network entity (Bhalerao: abstract, "The agent application generates a public/private key pair and an identifier associated with the customer server.", "The agent application sends a signed request to the CA that includes the profile identifier, server identifier, and the public key.");
(g) based on the first testing configuration, issuing the first entity certificate for the first network entity using the new CA certificate (Bhalerao: abstract, "Upon receiving the credentials, the CA generates a dynamically updatable certificate." "CA may generate an updated certificate based on the certificate profile changes and the public key.").
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Bhalerao with the method and system of Martinez and Singhal to include “to indicate that a certificate issuance process is to use the new CA certificate for issuing entity certificates for the first network entity” (f) receiving a first request for a first entity certificate for the first network entity; (g) based on the first testing configuration, issuing the first entity certificate for the first network entity using the new CA certificate. One would have been motivated to apply this same per-server profile change mechanism to indicate which CA — new or current — issues entity certificates to a specific network entity, because Bhalerao itself teaches that profile changes drive CA issuance behavior (Bhalerao: abstract). Applying this teaching to select between a new CA and a current CA during a CA rotation testing process is a routine extension of Bhalerao's explicit disclosure,requiring only ordinary skill and yielding only predictable results. KSR Int'l Co. v. Teleflex Inc., 550 U.S. 398, 416 (2007).
The combination of Martinez, Singhal, and Bhalerao further teaches
(h) subsequent to issuing the first entity certificate:
(i) receiving a second configuration update for rolling back the first testing configuration for the first network entity (Singhal: par. [0051]: "A canary deployment, or deployment to a subset, may control a sudden impact of the configuration change and test out the changes."; par. [0107]: "The processor determines whether the configuration state changes (at operation 770) ... health status change (e.g., detecting a failure of a disk), or a status for canary deployment." Examiner interpretation: Singhal teaches that a canary deployment includes evaluation of configuration state changes including failure conditions, which inherently includes receiving an instruction to reverse the canary configuration update on the selected entity when the test is ineffective or a failure is detected, satisfying claim 1(i)'s requirement of receiving a rollback configuration update for the first network entity)
(j) responsive to receiving the second configuration update, rolling back the first testing configuration at least by configuring the first testing configuration to indicate that the certificate issuance process is to revert back to using the current CA certificate for issuing entity certificates for the first network entity (Singhal: par. [0107], "The processor determines whether a configuration update for one of the list of streams is available...the processor sends the configuration update to the cluster." Examiner interpretation: Singhal teaches applying a configuration update to a specific cluster entity responsive to receiving that configuration update, satisfying the structural requirement rolling back the testing configuration responsive to the second configuration update; Bhalerao: Abstract, "If the customer changes information associated with the certificate profile, the CA may generate an updated certificate based on the certificate profile changes." Examiner interpretation: Bhalerao teaches that a per-server certificate profile change drives updated CA cert issuance behavior. Under BRI, configuring the certificate profile to indicate the current CA — by reverting the profile change applied in claim 1(e) — reads on "configuring the first testing configuration to indicate that the certificate issuance process is to revert back to using the current CA certificate." Reverting Bhalerao's profile to its prior state is the same mechanism as the forward change in claim 1(e), applied in the opposite direction.);
(k) receiving a second request for a second entity certificate for the first network entity (Bhalerao: Abstract, "The agent application sends a signed request to the CA that includes the profile identifier, server identifier, and the public key corresponding to the key pair." Examiner interpretation: Bhalerao teaches that a customer server — the first network entity — sends a certificate request to the CA including a server identifier and profile identifier. Under BRI, a second such request from the same server after a profile change reads on claim 1(k)'s second request for a second entity certificate for the first network entity. The same request mechanism taught by Bhalerao for claim 1(f) applies identically to claim 1(k));
(l) based on the first testing configuration, issuing the second entity certificate for the first network entity using the current CA certificate (Bhalerao: Abstract, "Upon receiving the credentials, the CA generates a dynamically updatable certificate.", "The CA may generate an updated certificate based on the certificate profile changes and the public key." Examiner interpretation: Bhalerao teaches that after a profile change, the CA issues a certificate based on the updated profile. Under BRI, when the profile has been reverted to indicate the current CA configuration, the CA issues the second entity certificate based on that reverted profile — using the current CA — satisfying claim 1(l)'s requirement of issuing the second entity certificate based on the first testing configuration using the current CA certificate. The same mechanism taught by Behalerao for claim 1(g) applies identically here with the config pointing to the current CA rather than the new CA).
Regarding claim 2, the combination of Martinez, Singhal, and Bhalerao teaches the one or more non-transitory computer-readable media of claim 1. The combination of Martinez, Singhal, and Bhalerao further teaches, wherein maintaining the set of testing configurations for the set of one or more network entities comprises:
maintaining a first data structure comprising a first set of one or more designated testing groups, wherein the first set of one or more designated testing groups comprises a first testing group, wherein the first testing group comprises the first network entity (Singha: par. 0051, "A canary deployment, or deployment to a subset, may control a sudden impact of the configuration change and test out the changes."; par. [0107],"a status for canary deployment (e.g., a cluster is selected for receiving and applying a configuration update to see if the update is effective in resolving an issue)".Examiner interpretation: Singhal teaches maintaining per-cluster canary deploymentstatus indicating which clusters are selected for receiving a configurationupdate — satisfying first data structure’s requirement of maintaining a data structure ofdesignated testing groups identifying which network entities are selectedfor canary testing. A Person Having Ordinary Skill In The Art (PHOSITA) would store this membership information in a data structure as claimed.); and
maintaining a second data structure comprising a set of one or more configuration updates for the first testing configuration, wherein at least when receiving the first configuration update, the set of one or more configuration updates comprises the first configuration update (Singhal: par. [0107], "The processor determines whether a configuration update for one of the list of streams is available (e.g., released, identified, etc.) (at operation 750)...the processor sends the configuration update to the cluster (at operation 760). The processor determines whether the configuration state changes (at operation 770)." Examiner interpretation: Singhal teachesreceiving configuration updates and tracking configuration state changes per cluster, satisfying second data structure's requirement of maintaining a data structure comprisingreceived configuration updates for a testing configuration. Recording thefirst configuration update in the second data structure when it arrives is inherent in Singhal's disclosure of tracking configuration state changes. Bhalerao: Abstract, "A customer server creates a certificate profile and receives an associated profile identifier from a CA." , "If the customer changes information associated with the certificate profile, the CA may generate an updated certificate based on the certificate profile changes." Examiner interpretation: Bhalerao teaches maintaining a per-server certificate profile record that is updated when configuration changes arrive — corresponding to the second data structure 's requirement of maintaining a data structure of configuration updates for the first testing configuration. Each profile change recorded corresponds to aconfiguration update logged in the second data structure), and
wherein at least when receiving the second configuration update, the set of one or more configuration updates comprises the second configuration update (Singhal: par. [0107], "The processor determines whether the configuration state changes (at operation 770). In some embodiments, the configuration state change includes adding a node, upgrading a software, health status change (e.g., detecting a failure of a disk), or a status for canary deployment.").
Regarding claim 3, the combination of Martinez, Singhal, and Bhalerao teaches the one or more non-transitory computer-readable media of claim 2. The combination of Martinez, Singhal, and Bhalerao further teaches wherein maintaining the second data structure comprises:
replacing the first configuration update with the second configuration update in response to determining an unsuccessful testing result corresponding to a first set of one or more testing operations associated with the first network entity (Singhal: par. 0107, "the configuration state change includes adding a node, upgrading a software, health status change (e.g., detecting a failure of a disk), or a status for canary deployment (e.g., a cluster is selected for receiving and applying a configuration update to see if the update is effective in resolving an issue)" Examiner interpretation: Singhal explicitly teaches detecting failure conditions (health status change, failure detection) and tracking configuration state changes per cluster for canary deployment. A PHOSITA would update the second data structure by replacing the current configuration update record with the new rollback update when a failureis detected — this is a standard database update operation (overwrite) that any skilled practitioner would implement when the current state changes due to a failed canary test.Bhalerao: Abstract, "If the customer changes information associated with the certificate profile, the CA may generate an updated certificate based on the certificate profile changes.").
Regarding claim 15, the combination of Martinez, Singhal, and Bhalerao the one or more non-transitory computer-readable media of claim 1. The combination of Martinez, Singhal, and Bhalerao further teaches wherein orchestrating the testing process further comprises:
during performance of the set of one or more testing operations with respect to the first network entity (Singhal: par. [0051], "each configuration change can be audited per cluster "; par. [0107], "a cluster is selected for receiving and applying a configuration update to see if the update is effective"):
receiving a third request for a third entity certificate for a second network entity (Bhalerao: Abstract: "The agent application sends a signed request to the CA that includes the profile identifier, server identifier, and the public key.");
issuing, based on a second testing configuration corresponding to the second network entity, the third entity certificate for the second network entity using the current CA certificate (Bhalerao: Abstract, "A customer server creates a certificate profile and receives an associated profile identifier from a CA." "The CA generates a dynamically updatable certificate based on the certificate profile."; Singhal: par. [0051]: "each configuration change can be audited per cluster ". ),
wherein the second testing configuration indicates that the certificate issuance process is to use the current CA certificate for issuing entity certificates for the second network entity (Bhalerao: Abstract, "A customer server creates a certificate profile and receives an associated profile identifier from a CA." "If the customer changes information associated with the certificate profile, the CA may generate an updated certificate based on the certificate profile changes.").
Regarding claim 16, claim 16 is directed to a method associated with the method claimed in claim 1, wherein the method is performed by at least one device including a hardware processor (Martinez: pars. 0048-0049); claim 16 is similar in scope to claim 1, and is therefore rejected under similar rationale.
Regarding claim 18, claim 18 is similar in scope to claim 2, and is therefore rejected under similar rationale.
Regarding claim 19, claim 19 is similar in scope to claim 15, and is therefore rejected under similar rationale.
Regarding claim 20, claim 20 is directed to a system comprising at least one hardware processor (Martinez: pars. 0048-0049); wherein the system is configured to execute operations, using the at least one hardware processor associated with the method claimed in claim 1; claim 20 is similar in scope to claim 1, and is therefore rejected under similar rationale.
Claims 4-6 are ejected under 35 U.S.C. 103 as being unpatentable over Martinez De La Cruz et al. (“Martinez”, EP 4000296) in view of Singhal et al. (“Singhal,” US 2022/0141085), and Bhalerao (“Bhalerao,” US 2015/0095995), further in view of Punreddy et al (“Punreddy,” US 2024/0427642).
Regarding claim 4, the combination Martinez, Singhal, and Bhalerao teaches the one or more non-transitory computer-readable media of claim 2. The combination Martinez, Singhal, and Bhalerao further teaches wherein maintaining the set of testing configurations for the set of one or more network entities comprises:
maintaining a third data structure comprising a second set of one or more designated testing groups, wherein the first set of one or more designated testing groups corresponds to a first portion of the execution environment and wherein the second set of one or more designated testing groups corresponds to a second portion of the execution environment (Singhal: par. [0074]: "A processor identifies a first cluster on an edge network that has an issue and a second cluster on the edge network that has the issue."; par. [0082], "identify a first cluster and a second cluster. In some embodiments, each of the first cluster and the second cluster is on an edge network."; par. [0019], "The cluster can be located...distributed across multiple data centers, multiple clouds or data center-cloud hybrid." Examiner interpretation: Singhal explicitly teaches identifying a second cluster on an edge network that is separate from the first cluster; par. [0107]: "a status for canary deployment (e.g., a cluster is selected for receiving and applying a configuration update to see if the update is effective in resolving an issue)". Singhal [0107] teaches tracking per-cluster canary deployment status indicating which cluster is selected for testing. Under BRI the first cluster with its canary status = first data structure (DS1) for Portion 1. The second cluster with its canary status = third data structure (DS3) for Portion 2. A person of ordinary skill in the art would have been motivated to maintain a separate data structure (DS3) for the second cluster's group membership because Singhal explicitly teaches per-cluster canary deployment status tracking [0107] — where each cluster has its own independent configuration state. Organizing per-cluster group membership into separate data structures, one per portion, is a routine database design decision that any PHOSITA would make when extending Singhal's per-cluster tracking to two distinct portions of the execution environment. This requires no more than ordinary skill and yields only predictable results. KSR Int'l Co. v. Teleflex Inc.,550 U.S. 398, 416 (2007));
orchestrating the testing process, utilizing the first data structure and the second data structure, with respect to the first portion of the execution environment (Singhal: par. [0074], "The processor sends the first configuration update to the first cluster (at operation 520). The processor receives feedback from the first cluster (at operation 530)."; par. [0077]: "the processor uses canary deployment to selectively apply configuration settings to clusters that are identified as having an issue."; par. [0051]: "the server side (cloud control plane) can provide canary deployments of configuration changes. A canary deployment, or deployment to a subset, may control a sudden impact of the configuration change and test out changes.”...each configuration change can be audited per cluster"; par. [0041]: "any cluster having first type hypervisor vendors subscribe to a first stream. When configuration updates are ready for that hypervisor vendor type, the pub-sub system may publish the configuration update on that stream".); and
orchestrating the testing process, utilizing the third data structure and the second data structure, with respect to the second portion of the execution environment (Singhal: para. [0075]: "If the processor determines that the issue is resolved, the processor sends the first configuration update to the second cluster (at operation 550)."; para. [0082]: "send a first configuration update to the first cluster and, in response to determining that the issue is or is not resolved in the first cluster, send the first configuration update to the second cluster."; par. [0041]: "any cluster having first type hypervisor vendors subscribe to a first stream. When configuration updates are ready for that hypervisor vendor type, the pub-sub system may publish the configuration update on that stream."; para. [0107]: "a status for canary deployment (e.g., a cluster is selected for receiving and applying a configuration update to see if the update is effective in resolving an issue).
Singhal does not explicitly teach orchestrating the testing process on the second portion simultaneously with the first portion.
However, in an analogous art, Punreddy teaches parallel simultaneous orchestration of canary deployment across multiple zones. (Punreddy: para. [0028]: "deployment scenarios can include initial deployment zones for a canary deployment, and whether rollout to zones is to be performed serially or in parallel."; para. [0004]: "complex orchestration of multiple simultaneous Kubernetes deployments that are required to work together in some manner such as sharing external resources and following common lifecycles.").
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Punreddy with the method and system of Martinez, Singhal, and Bhaleran to include parallel simultaneous orchestration of canary deployment across multiple zone. One would have been motivated to combine Singhal's per-cluster canary configuration update methodology with Punreddy's parallel canary zone deployment teaching because Punreddy itself presents parallel rollout to canary zones as a known deployment option. Applying Punreddy's parallel zone execution to Singhal's second cluster canary process yields the predictable result of simultaneously orchestrating the testing process on both portions of the execution environment — reducing validation time without requiring any inventive step. KSR Int'l Co. v. Teleflex Inc., 550 U.S. 398, 416 (2007) (Punreddy: pars. [0004][0028]).
Regarding claim 5, the combination of Martinez, Singhal, Bhalerao, and Punrenddy teaches the one or more non-transitory computer-readable media of claim 4. The combination of Martinez, Singhal, Bhalerao, and Punreddy further teaches
wherein the first portion of the execution environment comprises a first public key infrastructure (PKI) service (Martinez : par. [0043], "an NF can be implemented...as a virtualised function instantiated on an appropriate platform, e.g., on a cloud infrastructure"; pars. [0092]-[0093]: "CA certificates must be updated... life-cycle management of CA certificates".); and
wherein the second portion of the execution environment comprises a second PKI service (Singhal: par. [0074]: "A processor identifies a first cluster on an edge network that has an issue and a second cluster on the edge network that has the issue."; par. [0019]: "The cluster can be located... distributed across multiple data centers, multiple clouds or data center-cloud hybrid." Martinez: Pars. [0092]-[0093]:"CA certificates must be updated... life-cycle management (LCM) of CA certificates").
Regarding claim 6, the combination of Martinez, Singhal, Bhalerao, and Punreddy teaches the one or more non-transitory computer-readable media of claim 5. The combination of Martinez, Singhal, Bhalerao and Punreddy further teaches
wherein the first data structure and the second data structure utilize a group naming convention for the first set of one or more designated testing groups and the second set of one or more designated testing groups (Singhal teaches: Par. [0041]: "any cluster having first type hypervisor vendors subscribe to a first stream. When configuration updates are ready for that hypervisor vendor type, the pub-sub system may publish the configuration update on that stream "), and
wherein the second data structure maps the set of one or more configuration updates to one or more designated testing groups according to the group naming convention (Singhal: par. [0041], "any cluster having first type hypervisor vendors subscribe to a first stream. When configuration updates are ready for that hypervisor vendor type, the pub-sub system may publish the configuration update on that stream."; par. [0039], "the request to update may be published to a stream on the pub-sub system. Each client may subscribe to particular streams based on the current state of the client.").
Claim 7 is ejected under 35 U.S.C. 103 as being unpatentable over Martinez De La Cruz et al. (“Martinez”, EP 4000296) in view of Singhal et al. (“Singhal,” US2022/0141085), and Bhalerao (“Bhalerao,” US 2015/0095995), further in view of Qui et al. (“Qui,” US 2024/0097919).
Regarding claim 7, the combination of Martinez, Singhal, and Bhalerao teaches the one or more non-transitory computer-readable media of claim 1. The combination of Martinez, Singhal, and Bhalerao further teaches , wherein orchestrating the testing process further comprises:
generating, responsive at least in part to the first configuration update, a first update, wherein the first request for the first entity certificate is generated for the first network entity responsive at least in part to the first update (Singhal: par. 0107, "The processor determines whether a configuration update for one of the list of streams is available"; "If the processor determines that the configuration update is available, the processor sends the configuration update to the cluster"; Abstract "receive...an indication that the cluster received a configuration update"; Singhal: [0107], "a status for canary deployment (e.g., a cluster is selected for receiving and applying a configuration update)"; Abstract ,"compare a first parameter of a configuration state of the node to a second parameter of the configuration update... apply the configuration update".; Bhalerao: abstract, "The agent application generates a public/private key pair and an identifier associated with the customer server.", "The agent application sends a signed request to the CA that includes the profile identifier, server identifier, and the public key.");
generating, responsive at least in part to the second configuration update, a second update, wherein the second request for the second entity certificate is generated for the first network entity responsive at least in part to the second update (Singhal: par. [0051]: "A canary deployment, or deployment to a subset, may control a sudden impact of the configuration change and test out the changes."; par. [0107]: "The processor determines whether the configuration state changes (at operation 770)...health status change (e.g., detecting a failure of a disk), or a status for canary deployment."; Singhal: par. [0107], "The processor determines whether a configuration update for one of the list of streams is available...the processor sends the configuration update to the cluster." Examiner interpretation: Singhal teaches applying a configuration update to a specific cluster entity responsive to receiving that configuration update, satisfying the structural requirement— rolling back the testing configuration responsive to the second configuration update; Bhalerao: Abstract, "If the customer changes information associated with the certificate profile, the CA may generate an updated certificate based on the certificate profile changes." ; Bhalerao: Abstract, "The agent application sends a signed request to the CA that includes the profile identifier, server identifier, and the public key corresponding to the key pair." Bhalerao: Abstract, "Upon receiving the credentials, the CA generates a dynamically updatable certificate.", "The CA may generate an updated certificate based on the certificate profile changes and the public key.").
Singhal and Bhalerao do not explicitly disclose “an epoch date” as the specific per-entity signaling mechanism between the config update and the cert request.” and “the epoch date as the per-entity trigger mechanism for the rollback-driven second cert request.
However, in an analogous art, Qiu discloses Qiu teaches epoch numbers as the mechanism connecting configuration changes to certificate generation (Qiu: Abstract: "determining a current epoch of a newly added validator node of the consensus trusted cluster... and a target epoch of the consensus trusted cluster"; para [0105]: "when the consensus trusted cluster is updated, the existing validator nodes...may generate certificates while the cluster changes, and the certificate list may include the next epoch validator list.").
Therefore, a person of ordinary skill in the art would have been motivatedto apply Qiu's epoch-triggered certificate generation mechanism to the PKI cloud CA rotation system of Martinez, Singhal, and Bhalerao because Qiu explicitly teaches that epoch changes — responsive to configuration changes — trigger certificate operations on a per-node basis. Applying this known epoch-based triggering mechanism to force Server 1 to request a new entity certificate from the CA when its configuration epoch is updated is a routine cross-domain application of a known technique yielding only predictable results. KSR Int'l Co. v. Teleflex Inc., 550 U.S. 398, 416 (2007) (Qiu: Abstract; para [0105]).
Allowable Subject Matter
Claim 8 is objected to as being dependent upon a rejected base claim, but would be allowable if rewritten in independent form including all of the limitations of the base claim 1 and any intervening claims. Claims 9-14 are also objected to as being dependent upon a rejected base claim, but would be allowable if rewritten in independent form including all of the limitations of the base claim 8 and any intervening claims.
Claim 17 is objected to as being dependent upon a rejected base claim, but would be allowable if rewritten in independent form including all of the limitations of the base claim 16 and overcome the objection of claim 17 addressed above.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to CANH LE whose telephone number is (571)270-1380. The examiner can normally be reached on Monday to Friday 6:00AM to 3:30PM other Friday off.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Luu Pham, can be reached at telephone number 571-270-5002. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of an application may be obtained from Patent Center and the Private Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from Patent Center or Private PAIR. Status information for unpublished applications is available through Patent Center and Private PAIR for authorized users only. Should you have questions about access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free).
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) Form at https://www.uspto.gov/patents/uspto-automated- interview-request-air-form.
/Canh Le/
Examiner, Art Unit 2439
April 13, 2026
/LUU T PHAM/Supervisory Patent Examiner, Art Unit 2439
Prosecution Insights