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 communication and claim amendment filed on 01/16/2026; Claims 1, 12, and 20 are independent claims. Claims 1-20 have been examined and are pending. This Action is made FINAL.
Information Disclosure Statement
The information disclosure statement (IDS), submitted on 01/30/2026 is being considered by the examiner.
Response to Arguments
Applicants’ arguments in the instant Amendment, filed on 01/16/2026, with respect to limitations listed below, have been fully considered but they are not persuasive.
1. Applicants argue: "The Office improperly characterizes orchestrating the testing process as ‘canary deployment of CA certificates’ and relies on this improper characterization as a basis for applying the general concept of canary deployment of a software modification in Yi to the CA certificate renewal process in Singh."(Applicant Remarks/Arguments, page 12).
The Examiner respectfully disagrees with the Applicants. The Examiner did not “improperly characterize” the testing process. The rejection is a standard 103 combination of multiple references. Singh teaches CA certificate renewal/replacement (par. [0017]: “the CA certificate is renewed to a different authority”). Seunghee teaches canary deployment methodology (page 5, lines 7-16: “a new software version is released to a subset of...servers...tested on a small subset of servers or users and if it operates as expected then the new version may be rolled out to the rest”). The Examiner combined these two teachings: Singh provides the subject matter (CA certificates), and Seunghee provides the process (canary deployment). The phrase “canary deployment of CA certificates” describes the result of the combination, not a characterization of any single reference.
Under 35 U.S.C. §103, the Examiner is not required to find a single reference that teaches the entire claim—that would be an anticipation standard under §102, not an obviousness standard under §103. The very purpose of §103 is to combine teachings from different references to establish obviousness. See MPEP §2143(I)(A): “Combining prior art elements according to known methods to yield predictable results.”
2. Applicants argue: "canary deployment of software does not equate to 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, as recited in claim 1." (Applicant Remarks/Arguments, page 12).
The Examiner respectfully disagrees with the Applicants. This argument is essentially the same as Argument 1 restated. Again, the Examiner does not rely on Seunghee alone to teach this limitation. The Examiner relies on the combination of Seunghee and Singh. Seunghee teaches the canary deployment process—testing a new version on a subset before rolling out to the rest (page 5, lines 7-16). Singh teaches that CA certificates need to be replaced/renewed (par. [0017]). When combined, a person of ordinary skill in the art would apply Seunghee’s canary deployment process to Singh’s CA certificate replacement, resulting in a testing process pertaining to the new CA certificate.
Moreover, Seunghee’s canary deployment is a general methodology applicable to any infrastructure change—it is not limited to software code deployments. A CA certificate is a component deployed in an execution environment, and a person of ordinary skill would recognize that the same staged rollout approach applies to any risky infrastructure change, including CA certificate rotation. Seunghee itself teaches that canary deployment provides “an early warning indicator with less impact on service downtime” (page 5, lines 17-26), which is directly relevant to CA certificate rotation where a failed deployment can cause widespread authentication failures.
3. Applicants argue: the cited references fail to teach "issuing a new entity certificate based on the new CA certificate and distributing the new entity certificate to a network entity in the execution environment as part of the testing process." (Applicant Remarks/Arguments, page 12).
The Examiner respectfully disagrees with the Applicants. The Examiner does not rely on Seunghee alone to teach certificate issuance. This is a 103 combination rejection. Singh teaches that client certificates are generated using the CA certificate (par. [0017]: “OpenSSL client certificates are generated using server...OpenSSL CA certificate”). Seunghee teaches releasing a new version to a designated subset for testing (page 5, lines 7-16: “a new software version is released to a subset of...servers”).
In the combination, when a new CA certificate is deployed to a subset of servers for canary testing (Seunghee’s process applied to Singh’s CA context), the test entities necessarily receive entity certificates issued from the new CA—because that is how a CA functions. A CA certificate’s sole purpose is to issue entity certificates. You cannot deploy and test a new CA on a subset of servers without issuing entity certificates from it to that subset. Singh teaches the issuance mechanism; Seunghee teaches deploying to a subset and testing. The combination teaches issuing entity certificates from the new CA to the designated subset as part of the testing process, and distributing those certificates to the subset entities.
4. Applicants argue: the cited references fail to teach: "testing the new CA certificate against a new entity certificate whatsoever, let alone against a new entity certificate distributed to a network entity in the execution environment." (Applicant Remarks/Arguments, page 12).
The Examiner respectfully disagrees with the Applicants. First, the Examiner notes that Claim 1 does NOT recite “testing the new CA certificate against a new entity certificate.” Claim 1 recites “performing a set of one or more testing operations...pertaining to the new CA certificate” and that testing is performed “with respect to the first network entity based at least in part on the first entity certificate”. The Applicant is arguing against claim language that does not exist in the actual claim. The Examiner cannot be required to map prior art to limitations that are not recited in the claim.
Second, Seunghee teaches testing whether the new version “operates as expected” on the subset (page 5, lines 7-16). When combined with Singh’s CA certificate context, testing whether the new CA “operates as expected” encompasses performing testing operations pertaining to the new CA—including whether entity certificates issued from the new CA function correctly in the execution environment. Seunghee does not need to teach the specific type of testing; Seunghee teaches the framework of testing a new version on a subset before full rollout, which satisfies “performing a set of one or more testing operations...pertaining to the new CA certificate” as actually recited in Claim 1.
5. Applicants argue: the cited references fail to teach "determining that a first entity is designated for performing testing operations and that a second entity is not designated for performing testing operations, and issuing new entity certificates using the new CA to issue a first entity certificate to the first entity based on the first entity being designated for performing testing operations and using the current CA to issue a second entity certificate to the second entity during the testing process based on the second entity not being designated for performing testing operations." (Applicant Remarks/Arguments, page 13).
The Examiner respectfully disagrees with the Applicants. The Applicant’s argument bundles four separate limitations together. The Examiner addresses each component separately:
Regarding - Determining designated vs. not designated: Seunghee explicitly teaches “a new software version is released to a subset of...servers” and “the new version may be rolled out to the rest of the servers” (page 5, lines 7-16). Selecting a “subset” inherently requires determining which servers belong to the subset and which do not. You cannot release to a “subset” without first identifying which entities constitute that subset. Under broadest reasonable interpretation, “determining that a first network entity...is designated” means identifying which entity is selected for testing. Seunghee’s “subset” = entities determined to be designated for testing. “The rest” = entities determined to be NOT designated. This distinction is explicit in Seunghee’s teaching, not implied.
Regarding Dual-CA issuance: This is the same argument Applicant made in argument 3, restated. As explained above in Response to Argument 3, the Examiner relies on the combination of Seunghee and Singh. Seunghee teaches that during canary testing, the subset receives the new version while “the rest of the servers” continue operating with the current version (page 5, lines 7-16, 17-26). Singh teaches CA certificate issuance (par. [0017]). In the combination: the designated subset receives entity certificates from the new CA, and the non-designated entities continue receiving entity certificates from the current CA been validated for full deployment; therefore, non-test entities necessarily continue receiving certificates from the current CA.
6. Applicants argue: "The Office relies on Yi’s disclosure that ‘a new software version is released to a subset of users or services’ as allegedly teaching issuing a first entity certificate for a first network entity based on a new CA certificate responsive to determining that the first network entity is designated for performing the set of one or more testing operations, as recited in claim 1. However, releasing a new software version does not equate to issuing an entity certificate based on a new CA certificate."(Applicant Remarks/Arguments, page 13).
The Examiner respectfully disagrees with the Applicants. As explained in the Response to Argument 3, the Examiner does not rely on Seunghee alone to teach issuing an entity certificate. The Examiner relies on Seunghee for the process of deploying to a designated subset (page 5, lines 7-16) and on Singh for the concept of CA certificate issuance (par. [0017]). Seunghee teaches the deployment pattern (release new version to subset for testing). Singh teaches the deployment subject (CA certificates and entity certificates generated from CA certificates). The combination teaches: deploy new CA certificates to a designated subset for testing = issue entity certificates from the new CA to the first network entity.
The Applicant’s argument that “releasing software ≠ issuing certificate” ignores that this is a 103 combination rejection. The Examiner is not saying Seunghee alone teaches certificate issuance. The Examiner is saying Seunghee teaches the canary deployment process, Singh teaches CA certificate issuance, and the combination teaches canary deployment of CA certificates, including issuing entity certificates from the new CA to the test subset.
7. Applicants argue: "testing a new software version on a small subset of servers does not equate to issuing a second entity certificate for a second network entity based on a current CA certificate, as recited in claim 1." (Applicant Remarks/Arguments, page 13).
The Examiner respectfully disagrees with the Applicants. As explained in the Response to Argument 5, Seunghee teaches that during canary testing, “the rest of the servers” continue operating with the current version while the subset is tested with the new version (page 5, lines 7-16, 17-26). Specifically, Seunghee teaches that during canary deployment, “the amount of traffic (workload) handled by the new software version is limited” (page 5, lines 17-26), which confirms that the non-test entities continue handling traffic with the current version.
Singh teaches that servers operate with certificates issued from the CA certificate (par. [0017]). In the combination, “the rest of the servers continue operating” with the current version means the non-test entities continue receiving certificates from the current (old) CA—because in Singh’s CA certificate environment, operating with the current version means operating with certificates from the current CA. During the testing period, if a non-test entity needs a certificate renewal, it receives it from the current CA because the new CA has not yet been validated. This is a necessary technical consequence of combining Seunghee’s canary methodology with Singh’s CA certificate context.
8. Applicants argue: "testing a new software version on a small subset of servers does not equate to determining that a first entity is designated for performing testing operations and that a second entity is not designated for performing testing operations, and issuing new entity certificates using the new CA or the current CA depending on whether or not the entity is designated for performing testing operations, as recited in claim 1." (Applicant Remarks/Arguments, page 13).
The Examiner respectfully disagrees with the Applicants. As explained in the Response to Argument 5, this argument bundles multiple limitations. Regarding the determination of designated/not-designated: Seunghee’s explicit distinction between “subset” and “the rest” directly teaches determining which entities are designated for testing and which are not. Regarding dual-CA issuance: the combination of Seunghee’s canary deployment process with Singh’s CA certificate issuance teaches issuing from the new CA to the designated subset and from the current CA to the non-designated entities. The Examiner’s response to Argument 5 is fully incorporated here by reference.
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-7, 10, 12-16, and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Singh et al., (“Singh,” US 2024/0430249) in view of Srivastav et al. (“Srivastav,” US 2017/0222981), further in view of Yi, Seunghee (“Seunghee,” WO 2023/227228).
Regarding claim 1, Singh teaches one or more non-transitory computer-readable media storing instructions that, when executed by one or more hardware processors, cause performance of operations comprising:
receiving a new certificate authority (CA) certificate to supersede a current CA certificate installed in the execution environment (Singh: par. 0017, There can be multiple scenarios where client certificates need to be replaced on the endpoints. For example, the client certificate may have to be replaced when the remote collector's Certificate Authority (CA) certificate that generates the client certificate is expired, when the client certificate is expired, when the CA certificate or the client certificate is compromised, when the CA certificate is renewed to a different authority, or the like).
Singh does not explicitly disclose that the receiving and installation occurs in an execution environment of a virtual cloud network.
However, in analogous art, Srivastav teaches installing that a certificate authority in an execution environment of a virtual cloud network, wherein an operator initially installs a certificate authority in the customer's enterprise cloud network, and the certificate authority provides the basis for dynamic certificate enrollment (Srivastav: par. 0028: In one use case scenario, the certificates may be distributed throughout a customer's enterprise cloud network according to the following steps. Initially, an operator installs a certificate authority (e.g. CA 320) in the customer's enterprise cloud network. The certificate authority will provide the basis for dynamic certificate enrollment for bootstrapping operator-provided solution services as well as client virtual machine instances".)
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 Srivastav with the method and system of Singh to include “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. One would have been motivated to make this modification in order to provide certificate management in modern cloud environments where virtual machines are created dynamically and require certificate provisioning (Srivastav: par. 0042).
The combination of Singh and Srivastav teaches installing a new certificate authority (CA) certificate to supersede a current CA certificate but does not explicitly teach “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, wherein orchestrating the testing process comprising: …removing the current CA certificate from the execution environment, wherein the new CA certificate supersedes the current CA certificate”
However, in an analogous art, Seunghee discloses
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 (Seunghee: page 5, lines 7-16; page 5, lines 17-26; page 11, lines 22-28 to page 12, lines 1-3), wherein orchestrating the testing process comprises
determining that a first network entity of a set of network entities executing in the execution environment, is designated for performing the set of one or more testing operations (Seunghee: page 5, lines 7-16: "a new software version is released to a subset of users or servers...the new version may be tested on a small subset of servers or users."),
responsive to determining that the first network entity is designated for performing the set of one or more testing operations, issuing a first entity certificate for the first network entity based on the new CA certificate (Seunghee: page 5, lines 7-16 in combination with Singh, par. 0017: Seunghee teaches that "a new software version is released to a subset of...servers." In the context of deploying a new CA certificate (Singh), "releasing" the new version to a subset means deploying/issuing certificates from the new CA to the subset of servers.),
distributing the first entity certificate to the first network entity for performing the set of one or more testing operations, wherein the set of one or more testing operations are performed with respect to the first network entity based at least in part on the first entity certificate (Seunghee: page 5, lines 7-16: "a new software version is released to a subset of...servers...the new version may be tested on a small subset of servers." The term "released" encompasses distributing and deploying to target entities.),
while performing the set of one or more testing operations with respect to the first network entity based at least in part on the first entity certificate (Seunghee: page 5, lines 7-16; Seunghee teaches that the new version is tested on a subset "and if it operates as expected then the new version may be rolled out to the rest". Not that The conditional structure - testing first, then rolling out to the rest if successful—teaches that there is a period during which testing is being performed on the subset while the rest of the servers have not yet received the new version; page 5, lines 17-26, Seunghee further teaches that during canary deployment, "the amount of traffic (workload) handled by the new software version is limited" while testing occurs “):
determining that a second network entity of the set of network entities, is not designated for performing the set of one or more testing operations (Seunghee: page 5, lines 7-16 "the new version may be tested on a small subset of servers or users and if it operates as expected then the new version may be rolled out to the rest of the servers or users." When Seunghee teaches testing on "a subset" and subsequently rolling out to "the rest,"),
issuing a second entity certificate for the second network entity based on the current CA certificate (Seunghee: page 5, lines 7-16; page 5, lines 17-26; in combination with Singh, par. 0017; page 5, lines 7-16, Seunghee teaches that while testing occurs on a subset, the rest of the servers continue operating; page 5, lines 17-26, Specifically, Seunghee teaches limiting "the amount of traffic (workload) handled by the new software version" during testing,),
responsive to determining that the set of one or more testing operations is successful (Seunghee: page 5, lines 7-16, "the new version may be tested on a small subset of servers or users and if it operates as expected then the new version may be rolled out to the rest." Seunghee's teaching of the conditional statement "if it operates as expected" explicitly teaches determining whether the testing operations are successful.):
issuing a third entity certificate based on the new CA certificate for the second network entity (Seunghee: page 5, lines 7-16 in combination with Singh, par. 0017; page 5, lines 7-16, Seunghee teaches that after successful testing - "if it operates as expected" - "then the new version may be rolled out to the rest of the servers or users". Rolling out the new version "to the rest of the servers" teaches deploying the new version to the second network entity (the servers that were not part of the initial test subset), and
removing the current CA certificate from the execution environment, wherein the new CA certificate supersedes the current CA certificate (Singh, par. 0017 in combination with Seunghee, page 5, lines 7-16; Singh teaches that the CA certificate is "renewed to a different authority" (par. 0017), which teaches that the current CA is replaced with (superseded by) a new CA. When Seunghee's teaching of complete rollout after successful testing - "rolled out to the rest of the servers" (page 5, lines 7-16)—is combined with Singh's teaching of CA renewal/replacement, the combination teaches that after the new CA certificate has been successfully tested with the first network entity, the current CA certificate is removed from the execution environment).
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 Seunghee with the method and system of Singh and Srivastav to include to include orchestrating a testing process for performing testing operations prior to superseding the current CA certificate, as recited in claims. One would have been motivated to apply Seunghee's canary deployment to test the new CA certificate with a subset of entities before full deployment to minimize risk of widespread failures, as Seunghee teaches that canary deployment provides "an early warning indicator with less impact on service downtime" if the new version fails (Seunghee, page 5, lines 17-26).
Regarding claim 2, the combination of Singh, Srivastav, and Seunghee teaches the one or more non-transitory computer-readable media of claim 1. The combination teaches maintaining both the new CA certificate and current CA certificate in the execution environment during testing (Singh, par. 0017; Seunghee, page 5, lines 7-16; page 5, lines 17-26), issuing entity certificates from the new CA to test entities, and issuing entity certificates from the current CA to production entities (Singh, par. 0017; Seunghee, page 5, lines 7-16; page 5, lines 17-26).
Singh, Srivasta, and Seunghee do not explicitly disclose, “wherein the operations further comprise: maintaining the new CA certificate and the current CA certificate in an active state in the execution environment at least by: storing the new CA certificate and the current CA certificate in a certificate repository …; issuing the first entity certificate based on the new CA certificate …;; and issuing the second entity certificate based on the current CA certificate …”.
However, storing both CA certificates in a certificate repository and issuing certificates from CAs stored in the repository would have been obvious.
storing both CA certificates in a certificate repository (Under broadest reasonable interpretation, "certificate repository" means any storage system for certificates—database, key management system, certificate store, LDAP directory, or file system. When both CAs are present in the system as taught by the combination, they must be stored somewhere. Storing them in a centralized repository is an obvious storage choice that provides centralized management, consistent access, enhanced security, and improved reliability—predictable benefits of centralized storage).
issuing first entity certificate from new CA stored in repository (When the new CA is stored in a repository, issuing entity certificates requires retrieving he CA from the repository and using it to sign certificates—this is standard PKI operation. The combination teaches issuing from the new CA to test entities (Singh, par. 0017; Seunghee, page 5, lines 7-16; page 5, lines 17-26, and doing so from a repository is the obvious implementation when CAs are stored in a repository).
issuing second entity certificate from current CA stored in repository (When the current CA is stored in a repository, issuing entity certificates requires retrieving the CA from the repository and using it to sign certificates—this is standard PKI operation. The combination teaches issuing from the current CA to production entities (Singh, par. 0017; Seunghee, page 5, lines 17-26, and doing so from a repository is the obvious implementation when CAs are stored in a repository).
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 teaching of centralized certificate repository storage with the method and system of the combination to include storing both CAs in a certificate repository, issuing from the new CA stored in the repository, and issuing from the current CA stored in the repository. One would have been motivated to provide centralized certificate storage for simplified management, consistent access, enhanced security, and improved reliability - benefits that are predictable and well-known in certificate management systems.
Regarding claim 3, the combination of Singh, Srivastav, and Seunghee teaches the one or more non-transitory computer-readable media of claim 1. Although Singh, Srivastav, and Seunghee do not explicitly disclose, wherein during the testing process: the first network entity transmits the first entity certificate to a third network entity for authentication against the new CA certificate, and the second network entity transmits the second entity certificate to a fourth network entity for authentication against the current CA certificate. These limitations are inherent in the combination. Using certificates for authentication is the fundamental purpose of certificates. When certificates are issued as taught in claim 1 [i.e. first entity certificate and second entity certificate], they will necessarily be used for authentication. A certificate signed by a particular CA must be authenticated against that CA-this is inherent in PKI operation.
Regarding claim 4, the combination of Singh, Srivastav, and Seunghee teaches the one or more non-transitory computer-readable media of claim 1. The combination of Singh, Srivastav, and Seunghee teaches orchestrating a testing process where a new CA certificate is deployed for testing on a first network entity (test entity) while a current CA certificate continues to be used by a second network entity (production entity) in a virtual cloud network execution environment. Singh, Srivastav, and Seunghee do not explicitly disclose “installing the new CA certificate in a first portion of the execution environment …; wherein the current CA certificate is installed in a second portion of the execution environment ….”
However, the combination teaches or renders obvious these limitations as follows:
installing the new CA certificate in a first portion of the execution environment, wherein the first network entity is located in the first portion of the execution environment (Seunghee: page 5, lines 7-16; page 5, lines 17-26, deploying a new software version to a subset of servers for testing, stating "the amount of traffic (workload) handled by the new software version is limited" to "a subset of the servers" while "the rest of the servers aren't impacted". This teaches that test servers form a separate group or subset from production servers. When implementing this canary deployment methodology in Srivastav's virtual cloud network execution environment (Srivastav: pars. [0028]-[0030]), it would have been obvious to deploy this test server group in a first portion of the execution environment, such as a test zone, test region, test subnet, test namespace, or test cluster. Under broadest reasonable interpretation, a "portion of the execution environment" is any distinguishable part, section, area, or zone of the environment, which can include physical portions (e.g., different datacenters or regions), logical portions (e.g., different subnets, or namespaces), or organizational portions (e.g., different deployment groups). Placing the test servers (first network entity) in a first portion such as a test zone is the obvious and natural way to implement Seunghee's teaching of maintaining a separate test subset. Furthermore, it would have been obvious to install the new CA certificate in this same first portion where the test servers are located. When the test servers need to use the new CA certificate (as taught by the combination—test entities receive certificates from the new CA), co-locating the new CA in the same portion/zone as those test servers is the obvious implementation. This provides the test servers access to the new CA and isolates the new CA to the test zone, containing any potential issues to that zone. This is standard practice in cloud infrastructure-deploying resources in the same zone as the entities that use them.).
wherein the current CA certificate is installed in a second portion of the execution environment while performing the set of one or more testing operations with respect to the first network entity (Seunghee: page 5, lines 17-26, teaches that while testing occurs on the subset of servers with the new version, "the rest of the servers" continue normal operations and "aren't impacted". This teaches maintaining production servers as a separate group that continues operating during the testing phase. When implementing this in Srivastav 's virtual cloud network, it would have been obvious to deploy this production server group in a second portion of the execution environment, separate from the first portion where testing occurs. Placing production servers in a second portion such as a production zone is the obvious way to maintain separation between test and production, which is fundamental practice in system administration and cloud computing. Furthermore, it would have been obvious to install the current CA certificate in this second portion where the production servers are located. When production servers need to continue using the current CA certificate during testing (as taught by the combination -production entities continue receiving certificates from the current CA), co-locating the current CA in the same portion/zone as those production servers is the obvious implementation. The limitation "while performing the set of one or more testing operations with respect to the first network entity" describes the timing—that the current CA remains installed in the second portion during the testing phase. This timing is taught by Seunghee's methodology, where production continues normal operations "while" testing proceeds on the subset (Seunghee: page 5, lines 17-26, Both the new CA and current CA are active simultaneously during the testing phase -the new CA in the first portion serving test entities, and the current CA in the second portion serving production entities).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the system of Singh, Srivastav, and Seunghee to install the new CA certificate in a first portion of the execution environment where the first network entity is located, and install the current CA certificate in a second portion of the execution environment while performing testing operations on the first network entity. One of ordinary skill would have been motivated to separate test and production entities into different portions/zones and to co-locate each CA with the entities that use it in order to provide isolation between test and production environments, blast radius control such that issues in testing are contained to the test portion, network segmentation between test and production traffic, independent security policies for each zone, and resource isolation preventing test activities from consuming production resources. These benefits are predictable and represent fundamental best practices in cloud infrastructure design for safely deploying and testing updates. This represents the straightforward application of known cloud deployment practices (separating test and production workloads into different zones) to the canary deployment of CA certificates taught by the combination. The results are entirely predictable: test entities in a test zone using the new CA, and production entities in a production zone using the current CA, with isolation between the zones.
Regarding claim 5, the combination of Singh, Srivastav, and Seunghee teaches the one or more non-transitory computer-readable media of claim 4. The combination of Singh, Srivastav, and Seunghee further teaches, wherein the operations further comprise:
responsive to determining that the set of one or more testing operations is successful (Seunghee: page 7, lines 1-5, checking whether canary deployment operates successfully and then, "If successful, deploy more gNB-CU-UPs with the modified software to handle all traffic".):
installing the new CA certificate in the second portion of the execution environment (Seunghee: page 7, lines 1-5, teaches that after successful testing, "deploy more gNB-CU-UPs with the modified software to handle all traffic"; Singh: par. 0017.),
wherein the second network entity is located in the second portion of the execution environment (Seunghee: page 7, lines 1-5, "more gNB-CU-UPs...to handle all traffic"; Srivastav: pars. 0028-0030).
Regarding claim 6, the combination of Singh, Srivastav, and Seunghee teaches the one or more non-transitory computer-readable media of claim 1. The combination of Singh, Srivastav, and Seunghee teaches orchestrating a testing process where Singh's new CA certificate is deployed for testing on first network entities (test entities) while Singh's current CA certificate continues to be used by second network entities (production entities) in Srivastav's cloud execution environment, using Seunghee's canary deployment methodology to selectively deploy to a subset of entities. The combination does not explicitly teach accessing a CA certificate target list, determining which CA to use based on such a target list.
However, it would have been obvious to one of ordinary skill in the art to implement the combination's selective CA deployment using a CA certificate target list as follows:
accessing a CA certificate target list (When the combination teaches that different network entities use different CA certificates - test entities (first network entity) use Singh's new CA certificate while production entities (second network entity) use Singh's current CA certificate, as determined by Seunghee's canary deployment methodology - the system must have some mechanism to determine which entity should use which CA certificate. Under broadest reasonable interpretation, a "CA certificate target list" is any configuration, data structure, database, file, or mapping that associates network entities with their designated CA certificates. This includes database tables mapping entity identifiers to CA identifiers, configuration files (such as YAML, JSON, or XML files) specifying entity-to-CA associations, in-memory data structures (such as hash tables or dictionaries), certificate policy configurations, service registries, or any other lookup mechanism that maps entities to CAs. "Accessing" such a list means retrieving, reading, querying, or otherwise consulting this configuration or data structure to determine CA assignments. It would have been obvious to implement the combination's selective CA deployment by storing the entity-to-CA associations in such a configuration or data structure - a CA certificate target list under BRI. When the system needs to issue a certificate for an entity, it would access this target list to determine which CA to use. This is a straightforward application of well-known configuration management techniques in software systems. Using a configuration or lookup table to control system behavior based on entity identity is fundamental software design practice that yields predictable results—automated, consistent CA selection based on stored mappings.
determining, based on the CA certificate target list, that the new CA certificate is designated for use in issuing the first entity certificate for the first network entity (Once the system accesses the CA certificate target list as discussed in limitation, it would obviously use that list to determine which CA certificate is designated for each entity. The combination teaches that test entities (first network entity) should use Singh's new CA certificate while production entities use Singh's current CA certificate. When this entity-to-CA assignment is stored in a target list, the system would look up the first network entity in the target list and determine that Singh's new CA certificate is designated for that entity. Under BRI, "determining, based on the CA certificate target list" means using the target list as the basis for the determination -looking up the entity in the list, retrieving the associated CA designation, and thereby determining which CA to use. "Designated for use in issuing the first entity certificate for the first network entity" means that the new CA certificate is assigned, specified, or allocated for use in signing/issuing the certificate for the first network entity. This is simply reading the stored entity-to-CA mapping from the target list and using that information to guide certificate issuance. This represents the obvious and natural use of a configuration or lookup table - store mappings, then consult those mappings when making decisions. The result is entirely predictable: the system automatically selects the correct CA for each entity based on stored configuration.
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the system of Singh, Srivastav, and Seunghee to use a CA certificate target list (a configuration, data structure, or mapping that associates entities with CAs) by accessing this target list when a certificate is needed, and determining from the target list which CA certificate is designated for each entity. One of ordinary skill would have been motivated to use such a target list to provide automated CA selection based on entity identity, centralized configuration management for entity-to-CA associations, flexibility to update CA assignments without code changes, scalability to handle many entities, and reliable, consistent application of CA selection policies. These benefits are predictable and well-known advantages of configuration-driven systems. Using a lookup table or configuration to map entities to resources (here, CAs) is fundamental software design practice.
Regarding claim 7, the combination of Singh, Srivastav, and Seunghee teaches the one or more non-transitory computer-readable media of claim 6. the combination of Singh, Srivastav, and Seunghee teaches orchestrating a testing process using a CA certificate target list (configuration, data structure, or mapping) to determine which CA certificate to use for each entity. Claim 6 addresses accessing the target list and determining that Singh's new CA certificate is designated for the first network entity (test entity). Claim 7 addresses accessing the same target list and determining that Singh's current CA certificate is designated for the second network entity (production entity).
The combination teaches claim 7 as follows:
accessing the CA certificate target list (For the reasons stated in claim 6, the combination renders obvious the use of a CA certificate target list - any configuration, data structure, database, file, or mapping that associates network entities with their designated CA certificates. When the system needs to issue a certificate for the second network entity (production entity), it would access this same target list to determine which CA certificate to use, just as it does for the first network entity in claim 6. The target list contains mappings for all entities in the system - both test entities (first network entity) and production entities (second network entity). Accessing the target list for the second network entity would use the same mechanism described in claim 6: retrieving, reading, querying, or otherwise consulting the configuration or data structure. This is the natural and obvious use of a centralized configuration - it serves all entities in the system, not just a subset. When claim 6 teaches accessing a target list for the first entity, it would be obvious that the same target list would be accessed for the second entity as well, since the purpose of such a centralized configuration is to provide a single source of CA assignment information for all entities.
determining, based on the CA certificate target list, that the current CA certificate is designated for use in issuing the second entity certificate for the second network entity (When the system accesses the CA certificate target list for the second network entity as discussed in limitation above entity. This is simply the mirror image of claim: whereas claim 6 determines that the new CA is designated for the first entity, claim 7 determines that the current CA is designated for the second entity. Both determinations are made by consulting the same target list. This represents the complete and natural implementation of the target list - it stores mappings for all entities (both test and production) and is consulted regardless of which entity needs a certificate. The result is entirely predictable: the system automatically selects the correct CA for each entity based on the stored configuration.
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the system of Singh, Srivastav, and Seunghee to use a CA certificate target list for both the first network entity (claim 6) and the second network entity (claim 7). Just as it is obvious to access the target list and determine the CA for the first entity (claim 6), it is equally obvious to access the same target list and determine the CA for the second entity (claim 7). One of ordinary skill would understand that a centralized configuration or target list serves all entities in the system - it would not make sense to have a target list that only stores information for test entities but not for production entities. The natural and obvious implementation is a single target list containing mappings for all entities, which is accessed whenever any entity (test or production) needs a certificate. The benefits are the same as those articulated in claim 6: automated CA selection, centralized configuration management, flexibility, scalability, and reliable application of CA selection policies. These benefits are predictable and well-known advantages of configuration-driven systems.
Regarding claim 10, the combination of Singh, Srivastav, and Seunghee teaches the one or more non-transitory computer-readable media of claim 1. The combination of Singh, Srivastav, and Seunghee teaches orchestrating a testing process where test entities (first network entity) use Singh's new CA certificate while production entities (second network entity) continue using Singh's current CA certificate in Srivastav's cloud execution environment, using Seunghee's canary deployment methodology. Claim 1 further teaches that after successful testing, the new CA certificate is deployed to production entities (in claim 1) and the current CA certificate is eventually removed from the execution environment (in claim 1). The combination of Singh, Srivastav, and Seunghee teaches subsequent to the set of one or more testing operations having been performed with respect to the first network entity based at least in part on the first entity certificate, and prior to removing the current CA certificate from the execution environment as describe above.
The combination of Singh, Srivastav, and Seunghee further teaches issuing a fourth entity certificate for the first network entity based on the current CA certificate, wherein the fourth entity certificate supersedes the first entity certificate (The combination of Singh, Srivastav, and Seunghee teaches this limitation. During the canary deployment testing process, test entities (first network entity) receive certificates from Singh's new CA certificate for testing purposes. After testing is completed and before Singh's current CA certificate is removed from the system, it would be obvious to issue an additional certificate from Singh's current CA certificate to the test entities. The limitation recites this certificate is "based on the current CA certificate," meaning it is issued from, signed by, or derived from Singh's current CA certificate (the CA that existed before the new CA was deployed). One of ordinary skill would be motivated to issue such a certificate to test entities during the transition period between successful testing and complete removal of the current CA for several reasons. First, Seunghee teaches canary deployment methodology where systems must be prepared to rollback if problems occur. Seunghee teaches that "if not successful, go back to traffic being handled by" the instances running the prior version (Seunghee, page 7, lines 1-5). When applied to Singh's CA certificate deployment in Srivastav's cloud environment, this teaches maintaining the ability to revert to the current CA if issues arise during or after production deployment. Issuing a current CA certificate to test entities provides this rollback capability—if problems occur with the new CA deployment, test entities can revert to using the current CA certificate. Second, during the transition period after production deployment but before complete removal of the current CA, maintaining current CA certificates for test entities provides operational flexibility and ensures the system maintains both CA capabilities before the current CA is permanently removed. This is prudent certificate lifecycle management during CA migration-a straightforward application of known certificate management principles. Third, maintaining current CA capability in test entities during the transition phase represents a separation of roles where production entities move forward to the new CA while test entities maintain current CA capability as a transition bridge and safety mechanism. This division of responsibilities during migration is a predictable system design choice that yields obvious benefits. The phrase "wherein the fourth entity certificate supersedes the first entity certificate" means the fourth certificate replaces or takes precedence over the first certificate as the active certificate for the test entity. This superseding relationship ensures that during the transition period, the test entity actively maintains current CA operational capability while production entities have moved to the new CA. This separation of roles during the transition phase is a predictable system design choice yielding obvious advantages in system flexibility and safety during migration.)
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 Singh, Srivastav, and Seunghee to issue current CA certificates to test entities during the transition period between successful testing and removal of the current CA, where such certificates supersede the new CA certificates previously issued for testing purposes. One of ordinary skill would have been motivated to do this to maintain rollback capability (as taught by Seunghee's canary deployment rollback mechanisms), ensure operational flexibility during the transition period, and provide a transition bridge where test entities maintain current CA capability while production entities move to the new CA. The combination yields predictable results: test entities can revert to the current CA if issues arise with the new CA deployment, the system maintains both CA capabilities during the transition period, and the migration proceeds with appropriate safety mechanisms in place. The benefits are predictable - risk mitigation during CA migration, maintenance of rollback capability beyond the initial testing phase, and separation of concerns where test entities serve as the current CA bridge during production migration.
Regarding claim 12, claim 12 is directed to a method associated with the method claimed in claim 1; claim 12 is similar in scope to claim 1, and is therefore rejected under similar rationale.
Regarding claim 13, claim 13 is similar in scope to claim 2, and is therefore rejected under similar rationale.
Regarding claim 14, claim 14 is similar in scope to claim 3, and is therefore rejected under similar rationale.
Regarding claim 15, claim 15 is similar in scope to claim 4, and is therefore rejected under similar rationale.
Regarding claim 16, claim 16 is similar in scope to claim 6, and is therefore rejected under similar rationale.
Regarding claim 20, claim 20 is directed to a system, comprising: at least one hardware processor (Singh: par: 0011); 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 8-9, 11, and 17-18 are rejected under 35 U.S.C. 103 as being unpatentable over Singh et al., (“Singh,” US 2024/0430249) in view of Srivastav et al. (“Srivastav,” US 2017/0222981), and Yi, Seunghee (“Seunghee,” WO 2023/227228), and further in view of Subramanian et al. (“Subramanian,” US 12,361,110).
Regarding claim 8, the combination of Singh, Srivastav, and Seunghee teaches the one or more non-transitory computer-readable media of claim 1. The combination of Singh, Srivastav, and Seunghee teaches orchestrating a testing process using a CA certificate target list to determine which CA certificate to use for each entity, with test entities receiving certificates from Singh's new CA certificate and production entities receiving certificates from Singh's current CA certificate. The combination of The combination of Singh, Srivastav, and Seunghee teaches , wherein issuing the first entity certificate for the first network entity based on the new CA certificate responsive to determining that the first network entity is designated for performing the set of one or more testing operations comprises: accessing a CA certificate target list; determining, based on the CA certificate target list, that the new CA certificate is designated for use in issuing the first entity certificate for the first network entity (These limitations are similar to limitations of claim 6 which are addressed by claim 6 above). The combination of Singh, Srivastav, and Seunghee does not explicitly disclose
responsive to determining that the new CA certificate is designated for use in issuing the first entity certificate for the first network entity: modifying an epoch date to place in a condition for renewal, a fourth entity certificate having been issued for the first network entity based on the current CA certificate; subsequent to modifying the epoch date to place the fourth entity certificate in the condition for renewal: receiving a request to issue a new entity certificate for the first network entity; issuing the first entity certificate for the first network entity based on the new CA certificate.
However, in an analogous art, Subramanian discloses
modifying an epoch date to place in a condition for renewal, a fourth entity certificate having been issued for the first network entity based on the current CA certificate being the condition for renewal (The combination of Singh, Srivastav, Seunghee, and Subra teaches this limitation. Subramanian teaches a certificate renewal system with a "chaos test mode" that allows testing of certificate properties and renewal processes. Subra teaches that "the certificate renewal service may also request renewal of chaos test mode certificates at an arbitrary time, such as a randomly determined time. This may allow certificates in the chaos test mode to be renewed more frequently than standard certificates, which are typically not renewed until a fixed time period closer to their expiration dates." (Subramanian, col. 2, lines 58-66). Subramanian further teaches that "customers may be permitted to set upper and lower boundaries on the times at which chaos mode certificates are renewed" (Subramanian, col. 3, lines 46-49). Under broadest reasonable interpretation, "epoch date" means any time or date value used as a reference point for certificate lifecycle decisions including expiration, renewal, or validity periods. "Modifying an epoch date" means changing, adjusting, or setting such a time or date value. Subramanian 's teaching of requesting renewal "at an arbitrary time" and allowing certificates "to be renewed more frequently than standard certificates" teaches modifying the renewal time (epoch date) from the standard expiration-based renewal to an accelerated, test-mode renewal. When Subramanian 's chaos test mode is applied to the combination's canary deployment of Singh's CA certificates in Srivastav's cloud environment with Seunghee's testing methodology, it would be obvious to use Subramanian 's accelerated renewal timing for test certificates. The "fourth entity certificate" refers to another certificate issued for the first network entity - under BRI, "fourth" simply means another certificate in the sequence, not necessarily the exact numerical fourth certificate. The claim recites that this certificate was "issued...based on the current CA certificate," which under BRI means issued from or using the current CA certificate. When combined with the teachings, before the testing phase, the first network entity had certificates issued from Singh's current CA certificate. These existing certificates (including a "fourth entity certificate") form the baseline against which the new CA certificate is tested. The modified epoch date establishes the condition that triggers renewal - allowing rapid testing of the new CA certificate's renewal process without waiting for natural certificate expiration.).
receiving a request to issue a new entity certificate for the first network entity (Singh teaches a certificate authority system that issues certificates to network entities. Certificate issuance inherently involves receiving requests from entities that need certificates - this is fundamental to PKI operation. Under BRI, "receiving a request" means the certificate authority system receives, accepts, or obtains a request for certificate issuance or renewal. In the context of the combination with Subramanian 's test mode, when the modified epoch date triggers renewal, the system would receive a renewal request for a new certificate for the first network entity. This is the natural continuation of Subramanian 's accelerated renewal process: after modifying the epoch date to trigger early renewal, the system receives the resulting renewal request. This represents standard certificate renewal workflow - when renewal conditions are met, a renewal request is generated and received by the certificate authority.)
issuing the first entity certificate for the first network entity based on the new CA certificate (the combination of Singh and Seunghee teaches issuing a first entity certificate for the first network entity based on Singh's new CA certificate. Singh teaches a certificate authority system that issues certificates to network entities (Singh, par. 0017). Seunghee teaches canary deployment methodology where "the new software version" is deployed "to a subset of servers for testing" (Seunghee: page 5, lines 7-16). When Seunghee's canary deployment is applied to Singh's CA certificate replacement in Srivastav's cloud environment, this teaches issuing certificates from Singh's new CA certificate to test entities (first network entity) as part of the canary deployment testing process. In the context of claim 8, when the system receives the renewal request triggered by Subramanian 's modified epoch date, it issues the renewed certificate from Singh's new CA certificate -the CA being tested.)
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 Singh, Srivastav, Seunghee, and Subramanian to implement accelerated testing of CA certificate renewal. One of ordinary skill would have been motivated to apply Subramanian 's chaos test mode with modified renewal timing to the combination's canary deployment scenario to enable rapid testing of Singh's new CA certificate's renewal functionality. Without Subramanian 's teaching, testing certificate renewal would require waiting for certificates to approach their natural expiration dates, which could take months or years - impractical for testing purposes. Subramanian 's teaching solves this problem by modifying the renewal timing (epoch date) to trigger renewal at accelerated intervals, allowing comprehensive testing of renewal processes in a practical timeframe. This combination yields predictable results: accelerated validation of the new CA certificate's renewal capabilities. The benefits are predictable - faster testing cycles, more efficient use of testing resources, and earlier detection of potential renewal issues.
Regarding claim 9, the combination of Singh, Srivastav, and Seunghee teaches the one or more non-transitory computer-readable media of claim 1. The combination of Singh, Srivastav, and Seunghee teaches orchestrating a testing process where test entities (first network entity) use Singh's new CA certificate while production entities (second network entity) continue using Singh's current CA certificate in Srivastav's cloud execution environment, using Seunghee's canary deployment methodology. The combination of combination of Singh, Srivastav, and Seunghee further teaches, wherein the operations further comprise: while performing the set of one or more testing operations with respect to the first network entity based at least in part on the first entity certificate does not explicitly disclose
determining, based on an epoch date corresponding to a fourth entity certificate having been issued for the second network entity based on the current CA certificate, that the fourth entity certificate is in a condition for renewal;
issuing the second entity certificate for the second network entity based on the current CA certificate responsive at least in part to determining that the fourth entity certificate is in the condition for renewal, wherein the second entity certificate supersedes the fourth entity certificate.
However, in an analogous art, Subramanian discloses
determining, based on an epoch date corresponding to a fourth entity certificate having been issued for the second network entity based on the current CA certificate, that the fourth entity certificate is in a condition for renewal (The combination of Singh, Srivastav, Seunghee, and Subramanian teaches this limitation. While the canary deployment testing process is ongoing with test entities (first network entity) using Singh's new CA certificate, production entities (second network entity) continue operating with certificates issued from Singh's current CA certificate. These production entity certificates have expiration dates and validity periods that must be monitored for renewal purposes. Subra teaches monitoring certificate expiration dates and determining when renewal is needed. Specifically, Subramanian teaches that "in standard operation, a certificate renewal service may request renewal of those certificates two months prior to expiration of the certificates. For example, for certificates with a thirteen-month validity duration period, a certificate renewal service may request renewal of those certificates two months prior to expiration, which would be at the end of the eleventh month of the certificate validity period." (Subramanian, col. 1, lines 59-65). "Determining...based on an epoch date...that the fourth entity certificate is in a condition for renewal" means checking the certificate's time-based parameters (such as expiration date or validity period) and determining that the certificate needs renewal-for example, because it is approaching expiration. Subramanian s teaching of monitoring certificate validity periods and requesting renewal "two months prior to expiration" teaches determining, based on the certificate's expiration date (epoch date), that the certificate is in a condition for renewal. When Subramanian 's certificate renewal monitoring is applied to the combination's canary deployment scenario, it would be obvious to monitor the expiration dates (epoch dates) of production entities' certificates (issued from Singh's current CA certificate) and determine when they need renewal, even while testing of Singh's new CA certificate is ongoing with test entities. This ensures production entities maintain valid certificates and continue operating without interruption during the testing period);
issuing the second entity certificate for the second network entity based on the current CA certificate responsive at least in part to determining that the fourth entity certificate is in the condition for renewal, wherein the second entity certificate supersedes the fourth entity certificate (the combination of Singh and Seunghee teaches issuing certificates from Singh's current CA certificate to production entities (second network entity). Singh teaches certificate issuance functionality, and Seunghee teaches that production entities (the "rest of the servers" that are not in the test subset) continue using the current version. When these teachings are combined, production entities receive certificates from Singh's current CA certificate. In the context of claim 9, when Subra's renewal monitoring determines that a production entity's certificate needs renewal, the system issues a renewed certificate from Singh's current CA certificate to that production entity. The phrase "wherein the second network entity provides the fourth entity certificate" confirms that the entity requesting renewal presents its existing certificate as part of the renewal process- a standard aspect of certificate renewal where the entity demonstrates possession of the current certificate being renewed. This limitation represents the completion of the certificate renewal workflow for production entities during the testing period -monitoring identifies renewal needs, and the system responds by issuing renewed certificates from the current CA to maintain production operation.).
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 Singh, Srivastav, Seunghee, and Subramanian to implement certificate renewal monitoring and automatic renewal for production entities during canary deployment testing. One of ordinary skill would have been motivated to apply Subramanian 's certificate expiration monitoring and renewal triggering to production entities (second network entity) because during the testing period for Singh's new CA certificate, production entities continue operating with certificates from Singh's current CA certificate, and these certificates have validity periods that may expire during testing. Without monitoring and renewing these certificates, production entities would experience certificate expiration failures, causing service disruptions. Subramanian 's teaching solves this problem by providing a mechanism to monitor certificate expiration dates (epoch dates) and trigger renewal before expiration occurs. The combination yields predictable results: production entities maintain valid certificates and continue operating without interruption while testing of the new CA certificate proceeds with test entities. The benefits are predictable - continuous production operation, avoidance of certificate-related service disruptions, and separation of testing activities from production maintenance.
Regarding claim 11, the combination of Singh, Srivastav, and Seunghee teaches the one or more non-transitory computer-readable media of claim 10. The combination of Singh, Srivastav, and Seunghee teaches issuing a fourth entity certificate for the first network entity based on the current CA certificate, where the fourth certificate supersedes the first entity certificate issued from the new CA. The combination of Singh, Srivastav, and Seunghee further teaches, wherein issuing the fourth entity certificate for the first network entity based on the current CA certificate but does not explicitly disclose “ determining, based on an epoch date corresponding to the first entity certificate, …; ” “determining, based on a CA certificate target list, …; ” “issuing the fourth entity certificate for the first network entity based on the current for use in issuing new entity certificates for the first network entity.”
However, in an analogous art, Subramanian discloses
determining, based on an epoch date corresponding to the first entity certificate, that the first entity certificate is in a condition for renewal (Subramanian teaches certificate lifecycle management including monitoring certificate expiration dates and determining when certificates need renewal. Subra teaches that "in standard operation, a certificate renewal service may request renewal of those certificates two months prior to expiration of the certificates. For example, for certificates with a thirteen-month validity duration period, a certificate renewal service may request renewal of those certificates two months prior to expiration, which would be at the end of the eleventh month of the certificate validity period." (Subramanian, col. 1, lines 59-65). This teaches monitoring certificate validity periods (time-based parameters) and determining when certificates need renewal based on approaching expiration dates. Under broadest reasonable interpretation, "epoch date" means any time or date value used as a reference point for certificate lifecycle decisions including expiration dates, renewal dates, or validity period parameters. An "epoch date corresponding to the first entity certificate" means a time or date value associated with that certificate's lifecycle—such as its expiration date, validity period end date, or renewal trigger point. "Determining...based on an epoch date...that the first entity certificate is in a condition for renewal" means checking the certificate's time-based parameters (such as its expiration date or validity period) and determining that the certificate needs renewal—for example, because it is approaching expiration or has reached a predetermined renewal trigger point. When the combination teaches that test entities (first network entity) have been issued certificates from Singh's new CA certificate (the first entity certificate), and when Subramanian 's certificate expiration monitoring is applied to this scenario, Subramanian teaches monitoring the expiration date or validity period (epoch date) of this first entity certificate and determining when it is in a condition for renewal. Subra's teaching of monitoring certificates and requesting renewal "two months prior to expiration" based on the certificate validity period teaches determining, based on an epoch date corresponding to the certificate, that the certificate is in a condition for renewal.);
determining, based on a CA certificate target list, that the current CA certificate is designated for use in issuing the fourth entity certificate for the first network entity, the CA certificate target list and the epoch date corresponding to the first entity certificate having been updated subsequent to issuing the first entity certificate based on the new CA certificate (When the combination teaches that different network entities use different CA certificates—test entities use Singh's new CA while production entities use Singh's current CA, as implemented through Seunghee's canary deployment methodology—the system must have some mechanism to determine which CA certificate to use for each entity. It would be obvious to implement this determination using a CA certificate target list. Under broadest reasonable interpretation, a "CA certificate target list" is any configuration, data structure, database, file, or mapping that associates network entities with their designated CA certificates. This includes database tables mapping entity identifiers to CA identifiers, configuration files (such as YAML, JSON, or XML files) specifying entity-to-CA associations, in-memory data structures (such as hash tables or dictionaries), certificate policy configurations, or any other lookup mechanism that maps entities to CAs. When the system needs to determine which CA to use for issuing a certificate to an entity, it would obviously consult such a configuration or data structure—a CA certificate target list under BRI. This is a straightforward application of well-known configuration management techniques in software systems, where lookup tables or configuration files are used to control system behavior based on entity identity or system state. The phrase "determining, based on a CA certificate target list, that the current CA certificate is designated for use in issuing the fourth entity certificate" means consulting the target list and determining that Singh's current CA certificate is the designated CA for issuing certificates to the first network entity at this point in the system lifecycle. During the transition period addressed by claim 10 - after successful testing with the new CA and before complete removal of the current CA—the target list would indicate that Singh's current CA is designated for the test entity, reflecting the system's transition state where test entities maintain current CA capability. The alternative phrase "OR by the CA certificate target list that the first entity certificate...has been updated subsequent to issuing the first entity certificate" provides an alternative determination criterion. Under BRI, this means the target list has been modified or updated after the first entity certificate was issued, indicating a change in which CA is designated for the test entity. Either determination criterion—that the current CA is designated per the target list, or that the target list has been updated to reflect changed designations—serves as a basis for issuing the fourth entity certificate. Using a configuration or lookup table to determine which CA to use is obvious as a straightforward application of fundamental software design principles- using stored mappings to control system behavior yields predictable, automated results);
issuing the fourth entity certificate for the first network entity based on the current CA certificate responsive at least in part to determining that (a) the first entity certificate is in the condition for renewal and (b) that the current CA certificate is designated for use in issuing new entity certificates for the first network entity (For the reasons stated in claim 10, Singh teaches certificate issuance functionality, and the combination teaches issuing certificates from Singh's current CA certificate to test entities during the transition period. Claim 11 specifies that this issuance is "responsive at least in part to" the determinations made in limitations. Under BRI, "responsive at least in part to" means that the issuance occurs in response to, is triggered by, or is based on the specified determinations—the determinations serve as conditions or triggers for the issuance action. When the system determines both that the first entity certificate is in a condition for renewal (based on monitoring its epoch date per Subramanian), and that the current CA certificate is designated for the first network entity (based on consulting the target list), these determinations trigger or prompt the issuance of the fourth entity certificate from Singh's current CA certificate. This represents an automated, configuration-driven mechanism for certificate issuance: the renewal need (detected via epoch date monitoring) combined with the CA designation (retrieved from target list lookup) together trigger the system to issue the certificate from the designated CA. This automation is a straightforward combination of certificate monitoring techniques (monitoring expiration dates to detect renewal needs) and configuration management techniques (consulting stored mappings to determine which CA to use), both of which are well-known in certificate management systems. The result is entirely predictable: when a certificate needs renewal and the configuration indicates which CA is designated, the system issues the renewal certificate from the designated CA automatically, without requiring manual intervention.)).
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 Singh, Srivastav, Seunghee, and Subramanian to implement an automated mechanism for determining when to issue the fourth entity certificate based on epoch date monitoring and target list lookup. One of ordinary skill would have been motivated to combine these teachings to provide automated, configuration-driven certificate issuance during the transition period between successful testing and removal of the current CA. Subramanian explicitly teaches monitoring certificate expiration dates (epoch dates) to determine renewal needs. Using a configuration or target list to determine which CA is designated for each entity is an obvious application of fundamental configuration management principles - systems routinely use lookup tables, databases, or configuration files to map entities to resources or determine system behavior based on stored configuration. Combining these familiar elements - certificate expiration monitoring (Subramanian), configuration-based CA designation (target list), and automated triggering based on combined conditions—according to known methods yields entirely predictable results: the system automatically monitors certificate expiration, consults stored configuration for CA designations, and issues certificates accordingly without manual intervention. The benefits are predictable and well-known in the art - automated certificate lifecycle management, configuration-driven CA selection, reduced manual administration overhead, and reliable, consistent application of certificate issuance policies.
Regarding claim 17, claim 17 is similar in scope to claim 8, and is therefore rejected under similar rationale.
Regarding claim 18, claim 18 is similar in scope to claim 9, and is therefore rejected under similar rationale.
Conclusion
THIS ACTION IS MADE FINAL. 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 extension fee 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 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
February 12th, 2026
/LUU T PHAM/Supervisory Patent Examiner, Art Unit 2439