Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
DETAILED ACTION
This non-final action is responsive to application filed on 10/21/2024. In this application, claims 1-20 hare pending, with claims 1, 8 and 15 being independent.
Priority
This application is a continuation of U.S. Patent Application No. 17/585,198, filed on January 26, 2022. The entirety of which is incorporated by reference.
Double Patenting
The nonstatutory double patenting rejection is based on a judicially created doctrine grounded in public policy (a policy reflected in the statute) so as to prevent the unjustified or improper timewise extension of the “right to exclude” granted by a patent and to prevent possible harassment by multiple assignees. A nonstatutory double patenting rejection is appropriate where the conflicting claims are not identical, but at least one examined application claim is not patentably distinct from the reference claim(s) because the examined application claim is either anticipated by, or would have been obvious over, the reference claim(s). See, e.g., In re Berg, 140 F.3d 1428, 46 USPQ2d 1226 (Fed. Cir. 1998); In re Goodman, 11 F.3d 1046, 29 USPQ2d 2010 (Fed. Cir. 1993); In re Longi, 759 F.2d 887, 225 USPQ 645 (Fed. Cir. 1985); In re Van Ornum, 686 F.2d 937, 214 USPQ 761 (CCPA 1982); In re Vogel, 422 F.2d 438, 164 USPQ 619 (CCPA 1970); In re Thorington, 418 F.2d 528, 163 USPQ 644 (CCPA 1969).
A timely filed terminal disclaimer in compliance with 37 CFR 1.321(c) or 1.321(d) may be used to overcome an actual or provisional rejection based on nonstatutory double patenting provided the reference application or patent either is shown to be commonly owned with the examined application, or claims an invention made as a result of activities undertaken within the scope of a joint research agreement. See MPEP § 717.02 for applications subject to examination under the first inventor to file provisions of the AIA as explained in MPEP § 2159. See MPEP § 2146 et seq. for applications not subject to examination under the first inventor to file provisions of the AIA . A terminal disclaimer must be signed in compliance with 37 CFR 1.321(b).
The filing of a terminal disclaimer by itself is not a complete reply to a nonstatutory double patenting (NSDP) rejection. A complete reply requires that the terminal disclaimer be accompanied by a reply requesting reconsideration of the prior Office action. Even where the NSDP rejection is provisional the reply must be complete. See MPEP § 804, subsection I.B.1. For a reply to a non-final Office action, see 37 CFR 1.111(a). For a reply to final Office action, see 37 CFR 1.113(c). A request for reconsideration while not provided for in 37 CFR 1.113(c) may be filed after final for consideration. See MPEP §§ 706.07(e) and 714.13.
The USPTO Internet website contains terminal disclaimer forms which may be used. Please visit www.uspto.gov/patent/patents-forms. The actual filing date of the application in which the form is filed determines what form (e.g., PTO/SB/25, PTO/SB/26, PTO/AIA /25, or PTO/AIA /26) should be used. A web-based eTerminal Disclaimer may be filled out completely online using web-screens. An eTerminal Disclaimer that meets all requirements is auto-processed and approved immediately upon submission. For more information about eTerminal Disclaimers, refer to www.uspto.gov/patents/apply/applying-online/eterminal-disclaimer.
Claims 1-20 rejected on the ground of nonstatutory double patenting as being unpatentable over claims 1-20 of U.S. Patent No. US 12143506 B2. Although the claims at issue are not identical, they are not patentably distinct from each other because:
Examined Application
US12143506 B2
1. A computer-implemented method, the method comprising:
obtaining a digital leaf certificate in a non-isolated cloud computing environment, the digital leaf certificate being rooted to a first root certificate in a non-isolated Public Key Infrastructure (PKI) of trust in the non-isolated cloud computing environment and the digital leaf certificate include a first object identifier value,
wherein the digital leaf certificate is deployed to support establishing the PKI chain of trust rooted in a second root certificate for an isolated cloud computing environment;
storing the digital leaf certificate with the first object identifier value in a storage medium;
configuring a bootstrap executable with a second object identifier value, the second object identifier value matching the first object identifier value, the object identifier value corresponds to the isolated cloud computing environment;
updating a deployment environment with the bootstrap executable configured with the second object identifier value; and
updating a PKI installer in the deployment environment with the second object identifier value,
wherein PKI installer is embedded into the bootstrap executable that is executable to install the PKI chain of trust rooted in the second root certificate for the isolated cloud computing environment,
the second root certificate is distributable in the isolated cloud computing environment to secure communications within the isolated cloud computing environment.
2. The computer-implemented method of claim 1, where:
receiving the digital leaf certificate in the isolated cloud computing environment, the digital leaf certificate being rooted to the first root certificate in a non-isolated PKI chain of trust in the non-isolated computing environment and the digital leaf certificate including the first object identifier value;
obtaining the second root certificate in the isolated cloud computing environment;
signing the second root certificate with the digital leaf certificate to generate a signed blob;
storing the signed blob to a predetermined storage location in the isolated cloud computing environment;
executing the bootstrap executable configured with the second object identifier value;
obtaining the signed blob from the predetermined storage location in the isolated cloud computing environment;
verifying the signed blob with the digital leaf certificate;
when the signed blob is verified, comparing the first object identifier value from the digital leaf certificate to the second object identifier value from the bootstrap executable; and
when the first and second object identifier values match, installing a PKI chain of trust rooted in the second root certificate for the isolated cloud computing environment.
3. The method of claim 2, where the first root certificate in the non-isolated PKI chain of trust is accessible in the isolated environment.
4. The method of claim 3, where the method includes verifying the digital leaf certificate with the first root certificate that is accessible in the isolated environment.
5. The method of claim 2, where the method including:
calculating a first hash value for the second root certificate;
including the first hash value in the second root certificate;
calculating a second hash value for the second root certificate obtained from the signed blob obtained from the predetermined storage location in the isolated cloud computing environment;
comparing the first hash value to the second hash value; and
the step of, when the first and second object identifier values match, installing a PKI chain of trust rooted in the second root certificate for the isolated cloud computing environment comprises:
when the first and second object identifier values match and the first and second hash values match, installing a PKI chain of trust rooted in the second root certificate for the isolated cloud computing environment.
6. The method of claim 1, where the storage medium storing the digital leaf certificate with the first object identifier value comprises a removable storage medium.
7. The method of claim 1, where the first object identifier value is stored as an X.509 property of the digital leaf certificate.
8. One or more non-transitory computer storage media having computer executable instructions stored thereon which, when executed by one or more processors, cause the processors to execute a method, the method comprising:
obtaining a digital leaf certificate in a non-isolated cloud computing environment, the digital leaf certificate being rooted to a first root certificate in a non-isolated Public Key Infrastructure (PKI) of trust in the non-isolated cloud computing environment and the digital leaf certificate include a first object identifier value,
wherein the digital leaf certificate is deployed to support establishing the PKI chain of trust rooted in a second root certificate for an isolated cloud computing environment;
storing the digital leaf certificate with the first object identifier value in a storage medium;
configuring a bootstrap executable with a second object identifier value, the second object identifier value matching the first object identifier value, the object identifier value corresponds to the isolated cloud computing environment;
updating a deployment environment with the bootstrap executable configured with the second object identifier value; and
updating a PKI installer in the deployment environment with the second object identifier value,
wherein PKI installer is embedded into the bootstrap executable that is executable to install the PKI chain of trust rooted in the second root certificate for the isolated cloud computing environment,
the second root certificate is distributable in the isolated cloud computing environment to secure communications within the isolated cloud computing environment.
9. The computer storage media of claim 8, where the method includes:
receiving the digital leaf certificate in the isolated cloud computing environment, the digital leaf certificate being rooted to the first root certificate in a non-isolated PKI chain of trust in the non-isolated computing environment and the digital leaf certificate including the first object identifier value;
obtaining the second root certificate in the isolated cloud computing environment;
signing the second root certificate with the digital leaf certificate to generate a signed blob;
storing the signed blob to a predetermined storage location in the isolated cloud computing environment;
executing the bootstrap executable configured with the second object identifier value;
obtaining the signed blob from the predetermined storage location in the isolated cloud computing environment;
verifying the signed blob with the digital leaf certificate;
when the signed blob is verified, comparing the first object identifier value from the digital leaf certificate to the second object identifier value from the bootstrap executable; and
when the first and second object identifier values match, installing a PKI chain of trust rooted in the second root certificate for the isolated cloud computing environment.
10. The computer storage media of claim 9, wherein the first root certificate in the non-isolated PKI chain of trust is accessible in the isolated environment.
11. The computer storage media of claim 10, where the method includes verifying the digital leaf certificate with the first root certificate that is accessible in the isolated environment.
12. The computer storage media of claim 9, where the method includes:
calculating a first hash value for the second root certificate;
including the first hash value in the second root certificate;
calculating a second hash value for the second root certificate obtained from the signed blob obtained from the predetermined storage location in the isolated cloud computing environment;
comparing the first hash value to the second hash value; and
the step of, when the first and second object identifier values match, installing a PKI chain of trust rooted in the second root certificate for the isolated cloud computing environment comprises:
when the first and second object identifier values match and the first and second hash values match, installing a PKI chain of trust rooted in the second root certificate for the isolated cloud computing environment.
13. The computer storage media of claim 8, where the storage medium storing the digital leaf certificate with the first object identifier value comprises a removable storage medium.
14. The computer storage media of claim 8, where the first object identifier value is stored as an X.509 property of the digital leaf certificate.
15. A computer system, the system comprising:
one or more processors; and
at least one computer storage medium having computer executable instructions stored thereon which, when executed by the one or more processors, cause the one or more processors to perform a method, the method comprising:
obtaining a digital leaf certificate in a non-isolated cloud computing environment, the digital leaf certificate being rooted to a first root certificate in a non-isolated Public Key Infrastructure (PKI) of trust in the non-isolated cloud computing environment and the digital leaf certificate include a first object identifier value,
wherein the digital leaf certificate is deployed to support establishing the PKI chain of trust rooted in a second root certificate for an isolated cloud computing environment;
storing the digital leaf certificate with the first object identifier value in a storage medium;
configuring a bootstrap executable with a second object identifier value, the second object identifier value matching the first object identifier value, the object identifier value corresponds to the isolated cloud computing environment;
updating a deployment environment with the bootstrap executable configured with the second object identifier value; and
updating a PKI installer in the deployment environment with the second object identifier value,
wherein PKI installer is embedded into the bootstrap executable that is executable to install the PKI chain of trust rooted in the second root certificate for the isolated cloud computing environment,
the second root certificate is distributable in the isolated cloud computing environment to secure communications within the isolated cloud computing environment.
16. The computer system of claim 15, where the method includes:
receiving the digital leaf certificate in the isolated cloud computing environment, the digital leaf certificate being rooted to the first root certificate in a non-isolated PKI chain of trust in the non-isolated computing environment and the digital leaf certificate including the first object identifier value;
obtaining the second root certificate in the isolated cloud computing environment;
signing the second root certificate with the digital leaf certificate to generate a signed blob;
storing the signed blob to a predetermined storage location in the isolated cloud computing environment;
executing the bootstrap executable configured with the second object identifier value;
obtaining the signed blob from the predetermined storage location in the isolated cloud computing environment;
verifying the signed blob with the digital leaf certificate;
when the signed blob is verified, comparing the first object identifier value from the digital leaf certificate to the second object identifier value from the bootstrap executable; and
when the first and second object identifier values match, installing a PKI chain of trust rooted in the second root certificate for the isolated cloud computing environment.
17. The computer system of claim 16, where the first root certificate in the non-isolated PKI chain of trust is accessible in the isolated environment.
18. The computer system of claim 17, where the method includes verifying the digital leaf certificate with the first root certificate that is accessible in the isolated environment.
19. The computer system of claim 15, where the storage medium storing the digital leaf certificate with the first object identifier value comprises a removable storage medium.
20. The computer system of claim 15, where the first object identifier value is stored as an X.509 property of the digital leaf certificate.
1. A computer-implemented method for establishing a PKI (Public Key Infrastructure) chain of trust in an isolated cloud computing environment, comprising:
receiving a digital leaf certificate in the isolated cloud computing environment, the digital leaf certificate being rooted to a first root certificate in a non-isolated PKI chain of trust in a non-isolated cloud computing environment and the digital leaf certificate including a first object identifier value,
wherein the digital leaf certificate is received to support establishing the PKI chain of trust rooted in a second root certificate for the isolated cloud computing environment;
obtaining a second root certificate in the isolated cloud computing environment;
signing the second root certificate with a private key of the digital leaf certificate to generate a signed blob;
storing the signed blob to a predetermined storage location in the isolated cloud computing environment;
executing a bootstrap executable configured with a second object identifier value;
obtaining the signed blob from the predetermined storage location in the isolated cloud computing environment;
verifying the signed blob with the digital leaf certificate;
when the signed blob is verified, comparing the first object identifier value from the digital leaf certificate to the second object identifier value from the bootstrap executable;
when the first and second object identifier values match, installing a PKI chain of trust rooted in the second root certificate for the isolated cloud computing environment; and
distributing the second root certificate in the isolated cloud computing environment to secure communications within the isolated cloud computing environment.
2. The computer-implemented method of claim 1, where:
the method includes:
calculating a first hash value for the second root certificate;
including the first hash value in the second root certificate;
calculating a second hash value for the second root certificate obtained from the signed blob obtained from the predetermined storage location in the isolated cloud computing environment;
comparing the first hash value to the second hash value; and
the step of, when the first and second object identifier values match, installing a PKI chain of trust rooted in the second root certificate for the isolated cloud computing environment comprises:
when the first and second object identifier values match and the first and second hash values match, installing a PKI chain of trust rooted in the second root certificate for the isolated cloud computing environment.
3. The method of claim 1, the method including:
obtaining the digital leaf certificate in the non-isolated cloud computing environment;
storing the digital leaf certificate with the first object identifier value in a storage medium;
configuring the bootstrap executable with the second object identifier value, the second object identifier value matching the first object identifier value;
updating a deployment environment with the bootstrap executable configured with the second object identifier value; and
updating InstallPKIroots in the development environment with the second object identifier value.
4. The method of claim 3, where the storage medium storing the digital leaf certificate with the first object identifier value comprises a removable storage medium.
5. The method of claim 3, where the first object identifier value is stored as an X.509 property of the digital leaf certificate.
6. The method of claim 1, wherein the first root certificate in the non-isolated PKI chain of trust is accessible in the isolated environment.
7. The method compute resource provider system of claim 6, wherein the method includes verifying the digital leaf certificate with the first root certificate that is accessible in the isolated environment.
8. One or more non-transitory computer storage media having computer executable instructions stored thereon which, when executed by one or more processors, cause the processors to execute a method for establishing a PKI chain of trust in an isolated cloud computing environment, comprising:
receiving a digital leaf certificate in the isolated cloud computing environment, the digital leaf certificate being rooted to a first root certificate in a non-isolated PKI chain of trust in a non-isolated cloud computing environment and the digital leaf certificate including a first object identifier value,
wherein the digital leaf certificate is received to support establishing the PKI chain of trust rooted in a second root certificate for the isolated cloud computing environment;
obtaining a second root certificate in the isolated cloud computing environment;
signing the second root certificate with a private key of the digital leaf certificate to generate a signed blob;
storing the signed blob to a predetermined storage location in the isolated cloud computing environment;
executing a bootstrap executable configured with a second object identifier value;
obtaining the signed blob from the predetermined storage location in the isolated cloud computing environment;
verifying the signed blob with the digital leaf certificate;
when the signed blob is verified, comparing the first object identifier value from the digital leaf certificate to the second object identifier value from the bootstrap executable;
when the first and second object identifier values match, installing a PKI chain of trust rooted in the second root certificate for the isolated cloud computing environment; and
distributing the second root certificate in the isolated cloud computing environment to secure communications within the isolated cloud computing environment.
9. The computer storage media of claim 8, where the method includes:
calculating a first hash value for the second root certificate;
including the first hash value in the second root certificate;
calculating a second hash value for the second root certificate obtained from the signed blob obtained from the predetermined storage location in the isolated cloud computing environment;
comparing the first hash value to the second hash value; and
the step of, when the first and second object identifier values match, installing a PKI chain of trust rooted in the second root certificate for the isolated cloud computing environment comprises:
when the first and second object identifier values match and the first and second hash values match, installing a PKI chain of trust rooted in the second root certificate for the isolated cloud computing environment.
10. The computer storage media of claim 8, where the method includes:
obtaining the digital leaf certificate in the non-isolated cloud computing environment;
storing the digital leaf certificate with the first object identifier value in a storage medium;
configuring the bootstrap executable with the second object identifier value, the second object identifier value matching the first object identifier value;
updating a deployment environment with the bootstrap executable configured with the second object identifier value; and
updating InstallPKIroots in the development environment with the second object identifier value.
11. The computer storage media of claim 10, where the storage medium storing the digital leaf certificate with the first object identifier value comprises a removable storage medium.
12. The computer storage media of claim 8, where the first object identifier value is stored as an X.509 property of the digital leaf certificate.
13. The computer storage media of claim 8, wherein the first root certificate in the non-isolated PKI chain of trust is accessible in the isolated environment.
14. The computer storage media of claim 13, wherein the method includes verifying the digital leaf certificate with the first root certificate that is accessible in the isolated environment.
15. A computer system that establishes a PKI chain of trust in an isolated cloud computing environment, the system comprising:
one or more processors; and
at least one computer storage medium having computer executable instructions stored thereon which, when executed by the one or more processors, cause the one or more processors to perform a method for establishing a PKI chain of trust in an isolated cloud computing environment, the method comprising:
receiving a digital leaf certificate in the isolated cloud computing environment, the digital leaf certificate being rooted to a first root certificate in a non-isolated PKI chain of trust in a non-isolated cloud computing environment and the digital leaf certificate including a first object identifier value,
wherein the digital leaf certificate is received to support establishing the PKI chain of trust rooted in a second root certificate for the isolated cloud computing environment;
obtaining a second root certificate in the isolated cloud computing environment;
signing the second root certificate with a private key of the digital leaf certificate to generate a signed blob;
storing the signed blob to a predetermined storage location in the isolated cloud computing environment;
executing a bootstrap executable configured with a second object identifier value;
obtaining the signed blob from the predetermined storage location in the isolated cloud computing environment;
verifying the signed blob with the digital leaf certificate;
when the signed blob is verified, comparing the first object identifier value from the digital leaf certificate to the second object identifier value from the bootstrap executable;
when the first and second object identifier values match, installing a PKI chain of trust rooted in the second root certificate for the isolated cloud computing environment; and
distributing the second root certificate in the isolated cloud computing environment to secure communications within the isolated cloud computing environment.
16. The computer system of claim 15, where the method includes:
calculating a first hash value for the second root certificate;
including the first hash value in the second root certificate;
calculating a second hash value for the second root certificate obtained from the signed blob obtained from the predetermined storage location in the isolated cloud computing environment;
comparing the first hash value to the second hash value; and
the step of, when the first and second object identifier values match, installing a PKI chain of trust rooted in the second root certificate for the isolated cloud computing environment comprises:
when the first and second object identifier values match and the first and second hash values match, installing a PKI chain of trust rooted in the second root certificate for the isolated cloud computing environment.
17. The computer system of claim 15, where the method includes:
obtaining the digital leaf certificate in the non-isolated cloud computing environment;
storing the digital leaf certificate with the first object identifier value in a storage medium;
configuring the bootstrap executable with the second object identifier value, the second object identifier value matching the first object identifier value;
updating a deployment environment with the bootstrap executable configured with the second object identifier value; and
updating InstallPKIroots in the development environment with the second object identifier value.
18. The computer system of claim 17, where the storage medium storing the digital leaf certificate with the first object identifier value comprises a removable storage medium.
19. The computer system of claim 15, where the first object identifier value is stored as an X.509 property of the digital leaf certificate.
20. The computer system of claim 15, where:
the first root certificate in the non-isolated PKI chain of trust is accessible in the isolated environment; and
the method includes verifying the digital leaf certificate with the first root certificate that is accessible in the isolated environment.
Claim Rejections - 35 USC § 112
The following is a quotation of the first paragraph of 35 U.S.C. 112(a):
(a) IN GENERAL.—The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor or joint inventor of carrying out the invention.
The following is a quotation of the first paragraph of pre-AIA 35 U.S.C. 112:
The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor of carrying out his invention.
Claims 1, 8 and 15 are rejected under 35 U.S.C. 112(a) or 35 U.S.C. 112 (pre-AIA ), first paragraph, as failing to comply with the written description requirement. The claim(s) contains subject matter which was not described in the specification in such a way as to reasonably convey to one skilled in the relevant art that the inventor or a joint inventor, or for applications subject to pre-AIA 35 U.S.C. 112, the inventor(s), at the time the application was filed, had possession of the claimed invention. The claims 1, 8 and 15 recite “PKI installer” which was not described in original specification. The closet descriptions are paragraph 16 and paragraph 73 describe updating InstallPKiroots in the development environment with the second object identifier and InstallPKIRoots is a library that can be compiled into Bootstrap32.exe.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102 of this title, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 1-6, 8-13 and 15-19 are rejected under 35 U.S.C. 103 as being unpatentable over Beekman et al. (US 2022/0247576, Filed: Feb. 4, 2021), in view of Lange (US 2018/0139044, Pub. Date: May 17, 2018), in view of Kramer et al. (US 2021/0141645, Pub. Date: May 13, 2021), in view of Fan (US 2018/0316660, Pub. Date: Nov. 1, 2018), in view of Ih et al. (US 2020/0021447, Pub. Date: Jan. 16, 2020).
As per claim 1, Beekman discloses a computer-implemented method (Beekman fig. 1), the method comprising:
obtaining a digital leaf certificate in a non-isolated cloud computing environment (Beekman fig.1 and para. [0040], The HW provider certification service 120 may generate the certificate information, including the CK certificate [a digital leaf certificate] and the root certificate and CK, if needed, based on the platform identifier. The certification service 120 may then send the certificate information to the certification server node 114 (arrow 124) via the public network 101 [non-isolated cloud computing environment]), the digital leaf certificate being rooted to a first root certificate in a non-isolated Public Key Infrastructure (PKI) of trust in the non-isolated cloud computing environment (Beekman para. [0036], The HW provider certification service 120 may generate the CK certificate, e.g., by signing the public key portion of the CK with a root key of the HW provider certification service; Beekman para. [0028], If the signing key used to sign the remote attestation is a certification key (CK), then a CK certificate may be used to verify the remote attestation. In this case, the CK certificate may be verified using a root certificate of the manufacturer) and a first object identifier value (Beekman para. [0047], A local attestation value can be generated based on contents of the enclave 256; Beekman para. [0060], The local attestation 260 may include the cryptographic hash and other information, such as an identity of an application, a cryptographic hash of a public key of the application, and so on),
wherein the digital leaf certificate is deployed to support establishing the PKI chain of trust rooted in a second root certificate (Beekman fig. 1-2A and para. [0046], a first node 102 may generate an offline attestation certificate 269 [root certificate]; Beekman para. [0029], an attestation manager may alternatively or additionally provide an “offline attestation certificate” that includes the remote attestation, one of more of the certificates to be used to verify the remote attestation (e.g., the CK certificate), and a signature that can be used to verify contents of the offline attestation certificate; Beekman para. [0043], The first node 102 can send the remote attestation to the second node 130 (arrow 136) for verification. The first node 102 can also send the certificate information, including the CK certificate, attestation key certificate (if present), and root certificate to the second node … The certificates form a certificate chain, which may be stored at the second node 130 as a certificate chain 134; Beekman para. [0086], The processing logic may further provide a digital certificate to the application (block 680). For example, the digital certificate may be issued to the application with a public key of the application) for an isolated cloud computing environment (Beekman fig. 1-2A and para. [0025], The private network may be, e.g., a network that is isolated from public networks, such as the Internet, via an air gap);
storing the digital leaf certificate with the first object identifier value in a storage medium (Beekman fig.2A&8, CK certificate and local attestation value stored in first node 102; Beekman para. [0096], The processing device 830 may use an instruction to use one of its internal cryptographic keys 811 that is based on the identification of the attestation manager 830 to store the data of the application in the memory of the secure enclave of the attestation manager 830. For example, the data may be securely (e.g., encrypted) stored in the storage 851 or memory 852);
configuring a process executable with a second object identifier value (Beekman para. [0083-0084], the method 600 may begin with processing logic receiving a certificate signing request (CSR) from an application ... A digital certificate manager 240 may store known valid attestation values and may compare the attestation of the application included in the CSR with the known valid attestation values), the second object identifier value matching the first object identifier value (Beekman para. [0084], A digital certificate manager 240 may store known valid attestation values and may compare the attestation of the application included in the CSR with the known valid attestation values … The attestation value of the CSR may be valid when the attestation value matches a known valid attestation value), the object identifier value corresponds to the isolated cloud computing environment (Beekman fig. 1&2A, first node 102 in private/isolated network comprises application enclave 256 and para. [0047], A local attestation value can be generated based on contents of the enclave 256; Beekman para. [0060], The local attestation 260 may include the cryptographic hash and other information, such as an identity of an application, a cryptographic hash of a public key of the application, and so on);
the second root certificate is distributable in the isolated cloud computing environment to secure communications within the isolated cloud computing environment (Beekman fig. 1-2A, Offline attestation certificate is distributable in private network 103 para. [0023], Offline attestation may be used, for example, to verify the identity of a node prior to allowing the node to join a cluster, or to verify that an application has not been modified and can be trusted to operate as expected; Beekman para. [0025], The private network may be, e.g., a network that is isolated from public networks, such as the Internet, via an air gap).
Beekman discloses a process executable with a second object identifier value but does not explicitly disclose the process is bootstrap executable.
Beekman does not explicitly disclose:
the digital leaf certificate include a first object identifier value,
configuring a bootstrap executable with a second object identifier value;
updating a deployment environment with the bootstrap executable configured with the second object identifier value; and
updating a PKI installer in the deployment environment with the second object identifier value,
wherein PKI installer is embedded into the bootstrap executable that is executable to install the PKI chain of trust rooted in the second root certificate for the isolated cloud computing environment.
Lange teaches:
certificate include an object identifier value (Lange fig. 1, certificate 110 include enclave attestation 116).
It would been obvious to one of ordinary skill in the art before the effective filling date of the claimed invention to modify Beekman in view of Lange to incorporate a first object identifier value in the digital leaf certificate.
One of ordinary skill in the art would have been motived because it offers the advantage of providing information for providing information for authenticating that the enclave (Lange para. [0017])).
Beekman-Lange does not explicitly disclose:
configuring a bootstrap executable with a second object identifier value;
updating a deployment environment with the bootstrap executable configured with the second object identifier value; and
updating a PKI installer in the deployment environment with the second object identifier value,
wherein PKI installer is embedded into the bootstrap executable that is executable to install the PKI chain of trust rooted in the second root certificate for the isolated cloud computing environment.
Kramer teaches:
configuring a bootstrap executable with an identifier value (Kramer fig. 3A, configuration stage and para. [0031], The container builder 300 may add an identifier 314 (e.g., tag) to the bootstrap execution environment 310 identifying the software application 200 associated with the bootstrap execution environment 310; Kramer para. [0006], The operations further include executing the bootstrap execution environment);
updating a deployment environment (Kramer fig. 4 and para. [0044], After receiving the enhanced execution environment 320 from the data store 150, the method 400 includes, at operation 410, enhancing the bootstrap execution environment 310 based on the enhanced execution environment 320) with the bootstrap executable configured with the second object identifier value (Kramer fig. 3A, configuration stage and para. [0031], The container builder 300 may add an identifier 314 (e.g., tag) to the bootstrap execution environment 310 identifying the software application 200 associated with the bootstrap execution environment 310); and
wherein PKI installer is embedded into the bootstrap executable that is executable ([per specification of examined application, there is no description regarding PKI installer is embedded into the bootstrap executable that is executable. The closet description is paragraph 16 which recites updating InstallPKiroots in the development environment with the second object identifier value and paragraph 73 indicates InstallPKIRoots is a library that can be compiled into Bootstrap32.exe. Therefore, for the purpose of examining, Examiner would interpret PKI installer is a library] Kramer fig. 3B and para. [0044], enhancing the bootstrap execution environment 310 may include installing application dependencies 322 based on the enhanced execution environment 320. Application dependencies 322 may include at least one of a support library, an architecture-specific binary module, or a just-in-time compiled module).
It would been obvious to one of ordinary skill in the art before the effective filling date of the claimed invention to further modify Beekman in view of Kramer for configuring a bootstrap executable with a second object identifier value, updating a deployment environment with the bootstrap executable configured with the second object identifier value and wherein PKI installer is embedded into the bootstrap executable that is executable.
One of ordinary skill in the art would have been motived because it offers the advantage of efficiently configuring and deploying execution environments for software applications (Kramer para. [0001]).
Beekman-Lange-Kramer does not explicitly disclose:
updating a PKI installer in the deployment environment with the second object identifier value;
the bootstrap executable that is executable to install the PKI chain of trust rooted in the second root certificate for the isolated cloud computing environment.
Fan teaches:
updating a PKI installer in the deployment environment with the second object identifier value ([per specification of examined application, there is no description regarding updating a PKI installer in the deployment environment with the second object identifier value. The closet description is paragraph 16 which recites updating InstallPKiroots in the development environment with the second object identifier value and paragraph 73 indicates InstallPKIRoots is a library. Therefore, for the purpose of examining, Examiner would interpret PKI installer is a library]. Fan para. [0048], The correspondence between the inherent attribute identifier of the application package and the authentication certificate is updated and is stored in the authentication certificate information library corresponding to inherent attribute identifiers).
It would been obvious to one of ordinary skill in the art before the effective filling date of the claimed invention to modify Beekman in view of Fan for updating a PKI installer in the deployment environment with the second object identifier value.
One of ordinary skill in the art would have been motived because it offers the advantage of improving accuracy of data (Fan para. [0049]).
Beekman-Lange-Kramer-Fan does not explicitly disclose:
the bootstrap executable that is executable to install the PKI chain of trust rooted in the second root certificate for the isolated cloud computing environment.
Ih teaches:
bootstrap executable that is executable to install the PKI chain of trust rooted in root certificate for computing environment (Ih para. [0070], As described further below with respect to FIG. 3, use of bootstrap certificates, and the associated process flow there with, results in a significant simplification to the conventionally-complex process of establishing a PKI when applied to IoT- and networked-device designs; Ih para. [0250], the PKI infrastructure for first tier 2802 may further include one ECC root CA and 128 or more ECC sub-CAs, which may be manufacturer signers, as opposed to portal-managed. In some embodiments, the PKI infrastructure of first tier 2802 further includes multiple sub-CAs representing one or more other vendors or manufacturers).
It would been obvious to one of ordinary skill in the art before the effective filling date of the claimed invention to modify Beekman in view of Ih for the bootstrap executable that is executable to install the PKI chain of trust rooted in the second root certificate for the isolated cloud computing environment.
One of ordinary skill in the art would have been motived because it offers the advantage of providing improved security (Ih para. [0277]).
As per claim 2, Beekman-Lange-Kramer-Fan-Ih discloses the computer-implemented method of claim 1, Beekman-Lange-Kramer-Ih also discloses where:
receiving the digital leaf certificate in the isolated cloud computing environment (Beekman fig. 1, server node 114 in public network 101 send certificate information to first node 102 in Private network 103 and para. [0040], The certification server node 114 may send certificate information, which may include the CK certificate [digital leaf certificate] and other associated information, such as the platform identifier and certificate revocation lists, to the first node 102; Beekman para. [0025], The private network may be, e.g., a network that is isolated from public networks, such as the Internet, via an air gap), the digital leaf certificate being rooted to the first root certificate in a non-isolated PKI chain of trust in the non-isolated computing environment (Beekman para. [0036], The HW provider certification service 120 may generate the CK certificate, e.g., by signing the public key portion of the CK with a root key of the HW provider certification service; Beekman para. [0028], If the signing key used to sign the remote attestation is a certification key (CK), then a CK certificate may be used to verify the remote attestation. In this case, the CK certificate may be verified using a root certificate of the manufacturer) and the digital leaf certificate (Lange fig. 1, certificate 110 include enclave attestation 116) including the first object identifier value (Beekman para. [0047], A local attestation value can be generated based on contents of the enclave 256; Beekman para. [0060], The local attestation 260 may include the cryptographic hash and other information, such as an identity of an application, a cryptographic hash of a public key of the application, and so on);
obtaining the second root certificate in the isolated cloud computing environment (Beekman fig. 1-2A and para. [0046], a first node 102 may generate an offline attestation certificate 269 [root certificate]);
signing the second root certificate with the digital leaf certificate to generate a signed blob (Beekman para. [0048], the node certification authority 238 may sign the offline attestation certificate 269 in response to a request (arrow 293) and add the signature 284 to the offline attestation certificate 269 (arrow 295));
storing the signed blob to a predetermined storage location in the isolated cloud computing environment (Beekman fig. 2A and para. [0048], the node certification authority 238 may sign the offline attestation certificate 269 in response to a request (arrow 293) and add the signature 284 to the offline attestation certificate 269 (arrow 295); Beekman fig. 2C, First Node 102 comprises memory 232);
executing the bootstrap executable (Kramer fig. 3A, configuration stage and para. [0031], The container builder 300 may add an identifier 314 (e.g., tag) to the bootstrap execution environment 310 identifying the software application 200 associated with the bootstrap execution environment 310; Kramer para. [0006], The operations further include executing the bootstrap execution environment) configured with the second object identifier value (Beekman para. [0083-0084], the method 600 may begin with processing logic receiving a certificate signing request (CSR) from an application ... A digital certificate manager 240 may store known valid attestation values and may compare the attestation of the application included in the CSR with the known valid attestation values);
obtaining the signed blob from the predetermined storage location in the isolated cloud computing environment (Beekman fig. 2A and para. [0048-0049], The offlline attestation certificate 269 may be sent to the first node attestation manager 202 (arrow 272), which may in tum send it to the second node attestation manager 250 on the second node 130 (arrow 273) … The second node attestation manager 250 on the second node 130 may send a verification request, including the offline attestation certificate 269 received from the first node 102);
verifying the signed blob with the digital leaf certificate (Beekman fig.2A and para. [0050], The remote attestation verifier 242 may verify that the remote attestation 270 contains the public key hash digest 259. For example, the remote attestation verifier 242 may verify the digital signature 271 included in the remote attestation using the public key included in the certificate information … The public key may be an attestation public key if the certificate is an attestation certificate, or CK public key if the certificate is a CK certificate, for example);
when the signed blob is verified, comparing the first object identifier value from the digital leaf certificate to the second object identifier value (Beekman para. [0084], A digital certificate manager 240 may store known valid attestation values and may compare the attestation of the application included in the CSR with the known valid attestation values … The attestation value of the CSR may be valid when the attestation value matches a known valid attestation value) from the bootstrap executable (Kramer fig. 3A, configuration stage and para. [0031], The container builder 300 may add an identifier 314 (e.g., tag) to the bootstrap execution environment 310 identifying the software application 200 associated with the bootstrap execution environment 310; Kramer para. [0006], The operations further include executing the bootstrap execution environment); and
when the first and second object identifier values match (Beekman para. [0084], A digital certificate manager 240 may store known valid attestation values and may compare the attestation of the application included in the CSR with the known valid attestation values. In the same or alternative embodiments, the digital certificate manager may provide the received attestation value to another entity (e.g., another application, secure enclave, and/or network server) to determine whether the received attestation value is valid. The attestation value of the CSR may be valid when the attestation value matches a known valid attestation value), installing a PKI chain of trust rooted in the second root certificate (Ih para. [0070], As described further below with respect to FIG. 3, use of bootstrap certificates, and the associated process flow there with, results in a significant simplification to the conventionally-complex process of establishing a PKI when applied to IoT- and networked-device designs; Ih para. [0250], the PKI infrastructure for first tier 2802 may further include one ECC root CA and 128 or more ECC sub-CAs, which may be manufacturer signers, as opposed to portal-managed. In some embodiments, the PKI infrastructure of first tier 2802 further includes multiple sub-CAs representing one or more other vendors or manufacturers) for the isolated cloud computing environment (Beekman para. [0086], The processing logic may further determine that a hash value included in the CSR matches at least one of the known hash values (block 670) ... The processing logic may further provide a digital certificate to the application (block 680). For example, the digital certificate may be issued to the application with a public key of the application.
Similar rationale in claim 1 is applied.
As per claim 3, Beekman-Lange-Kramer-Fan-Ih discloses the computer-implemented method of claim 2, Beekman also discloses where the first root certificate in the non-isolated PKI chain of trust is accessible in the isolated environment (Beekman para. [0049], The CK certificate verifier 244 may verify the CK certificate using a root certificate of the manufacturer or provider of the first node 102).
As per claim 4, Beekman-Lange-Kramer-Fan-Ih discloses the computer-implemented method of claim 3, Beekman also discloses where the method includes verifying the digital leaf certificate with the first root certificate that is accessible in the isolated environment (Beekman para. [0049], The CK certificate verifier 244 may verify the CK certificate using a root certificate of the manufacturer or provider of the first node 102).
As per claim 5, Beekman-Lange-Kramer-Fan-Ih discloses the computer-implemented method of claim 2, Beekman-Ih also discloses where the method including:
calculating a first hash value for the second root certificate (Beekman para. [0058], A local attestation 260 of the contents of the enclave 256 may be generated by computing a cryptographic hash on the contents of the enclave 256 including the application data 258);
including the first hash value in the second root certificate (Beekman fig. 2, certificate 269 including remote attestation 270 including signature of local attestation 271);
calculating a second hash value for the second root certificate obtained from the signed blob obtained from the predetermined storage location in the isolated cloud computing environment (Beekman fig. 2A and para. [0049], The second node attestation manager 250 on the second node 130 may send a verification request, including the offline attestation certificate 269 received from the first node 102; Beekman fig.2A and para. [0050], the remote attestation verifier 242 may verify the digital signature 271 included in the remote attestation using the public key included in the certificate information (e.g., by decrypting the digital signature 271 using a public key included in the certificate information to produce a decrypted hash digest, and determining whether the decrypted hash digest
corresponds to an expected enclave identity hash digest));
comparing the first hash value to the second hash value (Beekman fig.2A and para. [0050], the remote attestation verifier 242 may verify the digital signature 271 included in the remote attestation using the public key included in the certificate information (e.g., by decrypting the digital signature 271 using a public key included in the certificate information to produce a decrypted hash digest, and determining whether the decrypted hash digest corresponds to an expected enclave identity hash digest); and
the step of, when the first and second object identifier values match (Beekman para. [0086], The processing logic may further provide a digital certificate to the application (block 680). For example, the digital certificate may be issued to the application with a public key of the application), installing a PKI chain of trust rooted in the second root certificate (Ih para. [0070], As described further below with respect to FIG. 3, use of bootstrap certificates, and the associated process flow there with, results in a significant simplification to the conventionally-complex process of establishing a PKI when applied to IoT- and networked-device designs; Ih para. [0250], the PKI infrastructure for first tier 2802 may further include one ECC root CA and 128 or more ECC sub-CAs, which may be manufacturer signers, as opposed to portal-managed. In some embodiments, the PKI infrastructure of first tier 2802 further includes multiple sub-CAs representing one or more other vendors or manufacturers) for the isolated cloud computing environment (Beekman para. [0086], The processing logic may further determine that a hash value included in the CSR matches at least one of the known hash values (block 670) ... The processing logic may further provide a digital certificate to the application (block 680). For example, the digital certificate may be issued to the application with a public key of the application comprises:
when the first and second object identifier values match and the first and second hash values match, installing a PKI chain of trust rooted in the second root certificate (Ih para. [0070], As described further below with respect to FIG. 3, use of bootstrap certificates, and the associated process flow there with, results in a significant simplification to the conventionally-complex process of establishing a PKI when applied to IoT- and networked-device designs; Ih para. [0250], the PKI infrastructure for first tier 2802 may further include one ECC root CA and 128 or more ECC sub-CAs, which may be manufacturer signers, as opposed to portal-managed. In some embodiments, the PKI infrastructure of first tier 2802 further includes multiple sub-CAs representing one or more other vendors or manufacturers) for the isolated cloud computing environment (Beekman para. [0084], A digital certificate manager 240 may store known valid attestation values and may compare the attestation of the application included in the CSR with the known valid attestation values. In the same or alternative embodiments, the digital certificate manager may provide the received attestation value to another entity (e.g., another application, secure enclave, and/or network server) to determine whether the received attestation value is valid. The attestation value of the CSR may be valid when the attestation value matches a known valid attestation value; Beekman para. [0086], The processing logic may further determine that a hash value included in the CSR matches at least one of the known hash values (block 670) ... The processing logic may further provide a digital certificate to the application (block 680). For example, the digital certificate may be issued to the application with a public key of the application).
Similar rationale in claim 1 is applied.
As per claim 6, Beekman-Lange-Kramer-Fan-Ih discloses the computer-implemented method of claim 1, Beekman where the storage medium storing the digital leaf certificate with the first object identifier value comprises a removable storage medium (Beekman para. [0024], The certificate information can be copied from the certification service to the first node using a non-network communication medium, such as a removable data storage device).
Per claims 8-13, they do not teach or further define over the limitations in claims 1-6 respectively. As such, claims 8-13 are rejected for the same reasons as set forth in claim 1-6 respectively. Beekman also discloses one or more non-transitory computer storage media having computer executable instructions stored thereon which, when executed by one or more processors, cause the processors to execute a method (Beekman fig. 9).
Per claims 15-19, they do not teach or further define over the limitations in claims 1-4 and 6 respectively. As such, claims 15-19 are rejected for the same reasons as set forth in claim 1-4 and 6 respectively. A computer system, the system comprising: one or more processors; and at least one computer storage medium having computer executable instructions stored thereon which, when executed by the one or more processors, cause the one or more processors to perform a method (Beekman fig. 9).
Claims 7, 14 and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Beekman et al. (US 2022/0247576, Filed: Feb. 4, 2021), in view of Lange (US 2018/0139044, Pub. Date: May 17, 2018), in view of Kramer et al. (US 2021/0141645, Pub. Date: May 13, 2021), in view of Fan (US 2018/0316660, Pub. Date: Nov. 1, 2018), in view of Ih et al. (US 2020/0021447, Pub. Date: Jan. 16, 2020), in view of Bugrov et al. (US 2016/0112406, Pub. Date: Apr. 21, 2016).
As per claim 7, Beekman-Lange-Kramer-Fan-Ih discloses the computer-implemented method of claim 1, Beekman does not explicitly disclose where the first object identifier value is stored as an X.509 property.
Bugrov teaches:
object identifier value is stored as an X.509 property (Bugrov para. [0048], The X.509v3 standard specifies various fields both required and optional for a digital certificate. The X.509v3 standard also permits extensions for including additional information in a digital certificate. An extension field in an X.509v3 digital certificate includes an Object Identifier (OID)).
It would been obvious to one of ordinary skill in the art before the effective filling date of the claimed invention to modify Beekman in view of Bugrov for the first object identifier value is stored as an X.509 property.
One of ordinary skill in the art would have been motived because it offers the advantage of providing information for determine whether the digital certificate may be accepted or must be rejected depending on whether the extension or its value is recognized (Bugrov para. [0048]).
Per claims 14 and 20, they do not teach or further define over the limitations in claim 7. As such, claims 14 and 20 are rejected for the same reasons as set forth in claim 7.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Ocak et al. (US 2021/0342163) Methods For Operation Of A Device, Bootstrap Server And Network Node;
Kinjo et al. (US 20210342895) Communication System, Communication Apparatus, Communication Method, Program And Advertisement Communication System;
Dahlberg (US 20210099428) Systems And Methods For Determining Asset Importance In Security Risk Management.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to VINH NGUYEN whose telephone number is (571)272-4487. The examiner can normally be reached Monday-Friday: 7:30 AM - 5:30 PM.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, KAMAL B DIVECHA can be reached at (571)272-5863. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of published or unpublished applications may be obtained from Patent Center. Unpublished application information in Patent Center is available to registered users. To file and manage patent submissions in Patent Center, visit: https://patentcenter.uspto.gov. Visit https://www.uspto.gov/patents/apply/patent-center for more information about Patent Center and https://www.uspto.gov/patents/docx for information about filing in DOCX format. For additional questions, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/VINH NGUYEN/Examiner, Art Unit 2453
/KAMAL B DIVECHA/Supervisory Patent Examiner, Art Unit 2453
Prosecution Insights