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 .
Specification
The specification filed on October 24, 2024 is accepted.
Drawings
The drawings filed on November 19, 2024 are accepted.
Examiners note: The examiner suggest to incorporate subject matter of dependent claims 2 and/or claim 5 into independent claims to overcome 101 rejections.
Claim Objections
Claims 1-20 objected to because of the following informalities:
Claim 1-20 the examiner suggests to remove the bullet points form the claims.
Claim 1 recites “generating a second request: to generate a second cryptographic secure object characterized by the first security level and to digitally sign a third cryptographic secure object characterized by a second security level falling below the first security level” there is no active step of generating the second cryptographic secure object and digitally signing the third cryptographic secure object. In order to give proper weight to the limitation the examiner suggests that the claim should recite active step for generating the second secure object and signing the third secure object.
Claim 1 recites “generating third request to generate the third cryptographic secure object……and transmitting the third request……” the limitation only recites generating a request and transmitting the request to server but does not involve generating the third secure object by the server.
Claim 1 recites “generating a fourth request to generate fourth cryptographic secure object” and claim 2 recites “generating a fourth request to generate a fifth cryptographic secure object” its unclear whether there are two “fourth request” one for generating fourth secure object and second for generating fifth secure object or there is only on “fourth request” for generating both the fourth and the fifth secure object.
Claim 16 recites “generating a first request to generate a first cryptographic secure object……and to digitally sign a second cryptographic secure object” the claim fails to recites active step for generating the first secure object and digitally signing the second secure object. Similar remarks for claim 20. Appropriate correction is required.
Claim Rejections - 35 USC § 101
35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
Claims 1, 16 and 20 is rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more. The claim recites, generating first, second, third and fourth request for first cryptographic secure object, second cryptographic secure object, third cryptographic secure object and fourth cryptographic secure object respectively. Transmitting these requests, receiving respective cryptographic secure object and signing the cryptographic secure object at given time period.
The limitations generating first, second, third and fourth request for first cryptographic secure object, second cryptographic secure object, third cryptographic secure object and fourth cryptographic secure object respectively. Transmitting these requests, receiving respective cryptographic secure object and signing the cryptographic secure object at given time period is a process that, under its broadest reasonable interpretation, covers performance of the limitations in the mind mentally or physically nothing in the claim precludes the steps from practically being performed in the mind or using paper and pencil. Generating first, second, third and fourth request for first cryptographic secure object, second cryptographic secure object, third cryptographic secure object and fourth cryptographic secure object respectively. Transmitting these requests, receiving respective cryptographic secure object and signing the cryptographic secure object at given time period, under its broadest reasonable interpretation, covers performance of the limitations in the mind. If a claim limitation, under its broadest reasonable interpretation, covers performance of the limitation in the mind but for the recitation of generic computer components, then it falls within the “Mental Processes” grouping of abstract ideas. Accordingly, the claim recites an abstract idea.
This judicial exception is not integrated into a practical application because the claim recites additional element such as security device in communication with server and executing an action based on first, second, third or fourth cryptographic secure object. These elements in the claim are recited at a high-level of generality such that it amounts no more than mere instructions to apply the exception using a generic computer component. Accordingly, this additional element does not integrate the abstract idea into a practical application because it does not impose any meaningful limits on practicing the abstract idea. The claim is directed to an abstract idea.
The claim does not include additional elements that are sufficient to amount to significantly more than the judicial exception. As discussed above with respect to integration of the abstract idea into a practical application, the additional element of devices to generate first, second, third and fourth request for first cryptographic secure object, second cryptographic secure object, third cryptographic secure object and fourth cryptographic secure object respectively. Transmitting these requests, receiving respective cryptographic secure object and signing the cryptographic secure object at given time period, steps amount to no more than mere instructions to apply the exception using a generic computer component see spec para of instant application [0030-0033 and 0178]. Mere instructions to apply an exception using a generic computer component cannot provide an inventive concept. The claim is not patent eligible.
Further recited elements within dependent claims 3, 4, 7-15 and 17-19 taken individually do not amount to “significantly more” than just the abstract idea as previously identified above. Therefore, the claims do not amount to significantly more than the previously defined abstract idea. Some of the evidences of “significantly more” are a) improvement to another technology or field; b) applying judicial exception with or by a “particular machine’; c) transforming particular article/data into different state or thing; d) adding unconventional or non-routine steps, producing useful application; and e) other meaningful limitations beyond generic link to particular technological environment.
As a result, the claims are directed to non-statutory subject matter. See Also Alice, 134 S. Ct. at 2360. Under Alice, that is not sufficient "to transform an abstract idea into a patent-eligible invention." See Alice Corporation v. CLS Bank International, (S.Ct.2014) and Ultramercial, Inc. v. Hulu, LLC. (Fed.
Claim Rejections - 35 USC § 112
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claim 16 rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention. The claim recites at a security device during first time period…. generating a first request to…. digitally sign a second cryptographic secure object. The claim further recites at the second server during the first time period….: generating a third request to digitally sign the second cryptographic secure object based on the firs cryptographic secure object. First, it seems like that the security device and the second server at the same time sending a request to sign the second secure object. It is unclear whether there are two separate signing operation on the second secure object at the same time. Second, the first cryptographic secure object was never generated therefore, the second cryptographic secure object cannot be signed using the first cryptographic secure object. Third, it is unclear who generates the first cryptographic secure object. i.e., the security device, the first server or the second server. Fourth, the security device and the second server are only generating request to sign the second secure object. Therefore, it unclear when and who performs the signing operation.
Claim 16 rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention. The examiner notes that the flow/sequence of the claim unclear. For example, the claim recites “at the second server during the first time period: ……..transmitting the fourth request to the first server….” and the next limitation recites “at the security device during a second time period…….. generating a fourth request….” It is unclear how the fourth request at first time period is transmitted before the fourth request was even generated at second time period.
Next, the claim recites “at a security device during first time period:…… transmitting the second request to a second server…….” Further recites “at the security device during a second time period succeeding the first time period:…..transmitting the second request to the second server……” it is unclear what is the purpose of transmitting the second request twice at different time interval. Does this mean that when the second server fails to generated the second secure object responsive to the second request at first time period, only then transmitting the second request again for generating the second secure object?
Claim 20 rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention. The claim recites “at a security device during first time period:…… transmitting the second request to a second server…….” Further recites “at the security device during a second time period succeeding the first time period:…..transmitting the second request to the second server……” it is unclear what is the purpose of transmitting the second request twice at different time interval. Does this mean that when the second server fails to generated the second secure object responsive to the second request at first time period, only then transmitting the second request again for generating the second secure object?
Dependent claim 17-19 are also rejected under the same rationales as set forth above.
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 and 10-20 are rejected under 35 U.S.C. 103 as being unpatentable over Jones et al (hereinafter Jones) (US 20220116229) in view of Kelley et al (hereinafter Kelley) (US 9230121).
Regarding claim 1 Jones a method comprising, at security device: (Jones on [0003] teaches method for generating digital certificate implemented by processing hardware);
during a first time period: generating a first request to generate a first cryptographic secure object characterized by a first security level (Jones on [0030] teaches the remote system 140 includes the root certificate authority 310R and generates the root certificate 210R. See on [0054] teaches each respective intermediate certificate authority 310N in the chain of intermediate certificate authorities 310N includes a respective intermediate certificate 210N (i.e., first cryptographic secure object) digitally signed by the intermediate certificate authority 310N or the root certificate authority 310R that is immediately higher (i.e., first security level) in the chain of intermediate certificate authorities 310N than the respective intermediate certificate authority 310N. See on [0023] teaches the applicant sends the CSR (i.e., request) to a trusted CA. The CA receives the CSR and independently verifies the information included within the CSR is correct. If the CA believes the information to be correct, the CA signs a digital certificate (with the CA's own private key) that includes the applicant's public key and the other identifying information. The CA then provides the signed digital certificate back to the applicant);
transmitting the first request to a first server via a first communication link (Jones on [0023] teaches the applicant sends the CSR (i.e., request) to a trusted CA. The CA receives the CSR and independently verifies the information included within the CSR is correct. If the CA believes the information to be correct, the CA signs a digital certificate (with the CA's own private key) that includes the applicant's public key and the other identifying information. The CA then provides the signed digital certificate back to the applicant);
receiving the first cryptographic secure object from the first server, the first cryptographic secure object characterized by a first signature associated with the first server (Jones on [0030-0032] teaches the root CA 310R digitally signs the root certificate 210R with a public key 220R owned by the root CA 310R. The root CA 310R maintains the root certificate 210R and issues an intermediate certificate 210Na to a first intermediate CA 310Na in the chain. This certificate includes the root CA ID 230R and the root CA signature 240R. Further teaches when a third party, such as user 12 via user device 10 wishes to communicate with the end-entity 30, the end-entity 30 provides the user device 10 with the certificate. See on [0054] teaches a root digital certificate 210R digitally signed by the root certificate authority 310R. At operation 804, the method 800 includes generating, by the data processing hardware 144, a chain of intermediate certificate authorities 310N. Each respective intermediate certificate authority 310N in the chain of intermediate certificate authorities 310N includes a respective intermediate certificate 210N digitally signed by the intermediate certificate authority 310N or the root certificate authority 310R that is immediately higher in the chain of intermediate certificate authorities 310N than the respective intermediate certificate authority 310N);
and executing a first action based on the first cryptographic secure object (Jones Fig 2 and text on [0033 and 0054] teaches continuing up the chain, the first intermediate CA 310Na issues another intermediate certificate 210Nb to a second intermediate CA 310Nb, intermediate certificate 210Nb includes the signature 240Na and the ID 230Na of the first intermediate CA 310Na. i.e., generating next intermediate certificate based on first intermediate CA is equivalent to executing action);
during a second time period: generating a second request: to generate a second cryptographic secure object characterized by the first security level (Jones Fig 2 and text on [0033 and 0054] teaches continuing up the chain, the first intermediate CA 310Na issues another intermediate certificate 210Nb (i.e., second cryptographic secure object at higher level in the chain as shown in Fig 2 and Fig 3) to a second intermediate CA 310Nb, intermediate certificate 210Nb includes the signature 240Na and the ID 230Na of the first intermediate CA 310Na. i.e., generating next intermediate certificate based on first intermediate CA is equivalent to executing action);
and to digitally sign a third cryptographic secure object characterized by a second security level falling below the first security level (Jones on [0030-0033] teaches each intermediate CA 310N in the chain includes or is associated with a respective intermediate certificate 210, 210Na-n digitally signed by the intermediate CA 310N that is immediately higher in the chain of intermediate CAs 310N than the corresponding intermediate CA 310N. The remote system 140 may use any appropriate signing algorithm to sign the certificates 210. The respective intermediate certificate 210N of the intermediate CA 310N that is highest in the chain is signed by the root CA 310R, thus establishing a chain of trust. The lowest intermediate CA in the chain (i.e., intermediate CA 310Nc in the given example) issues end entity certificates 210L (e.g., X.509 certificates) to an end-entity 30 via, for example, network 20, 20a. Further teaches the intermediate certificate 210Nb also includes the ID 230Nb and the public key 220Nb second intermediate CA 310Nb. This chain continues for any length until a final intermediate CA 310Nn provides an end entity certificate 310L that includes its ID 230Nn and signature 240Nn to the entity 30 i.e., respective intermediate certificates are lower in the chain, The first intermediate certificate is higher level, then comes all the respective certificate, finally the lowest is the end entity certificate as shown in Fig 2 and Fig 3);
transmitting the second request to the first server via the first communication link (Jones on [0023] teaches the applicant sends the CSR (i.e., request) to a trusted CA. The CA receives the CSR and independently verifies the information included within the CSR is correct. If the CA believes the information to be correct, the CA signs a digital certificate (with the CA's own private key) that includes the applicant's public key and the other identifying information. The CA then provides the signed digital certificate back to the applicant);
generating a third request to generate the third cryptographic secure object associated with the second cryptographic secure object (Jones on [0030-0033 and 0036] teaches each intermediate CA 310N in the chain includes or is associated with a respective intermediate certificate 210, 210Na-n digitally signed by the intermediate CA 310N that is immediately higher in the chain of intermediate CAs 310N than the corresponding intermediate CA 310N. The remote system 140 may use any appropriate signing algorithm to sign the certificates 210. The respective intermediate certificate 210N of the intermediate CA 310N that is highest in the chain is signed by the root CA 310R, thus establishing a chain of trust. The lowest intermediate CA in the chain (i.e., intermediate CA 310Nc in the given example) issues end entity certificates 210L (e.g., X.509 certificates) to an end-entity 30 via, for example, network 20, 20a. Further teaches the intermediate certificate 210Nb also includes the ID 230Nb and the public key 220Nb second intermediate CA 310Nb. This chain continues for any length until a final intermediate CA 310Nn provides an end entity certificate 310L that includes its ID 230Nn and signature 240Nn to the entity 30 i.e., respective intermediate certificates are lower in the chain, The first intermediate certificate is higher level, then comes all the respective certificate, finally the lowest is the end entity certificate as shown in Fig 2 and Fig 3);
and transmitting the third request to a second server via a second communication link (Jones on [0023] teaches the applicant sends the CSR (i.e., request) to a trusted CA. The CA receives the CSR and independently verifies the information included within the CSR is correct. If the CA believes the information to be correct, the CA signs a digital certificate (with the CA's own private key) that includes the applicant's public key and the other identifying information. The CA then provides the signed digital certificate back to the applicant);
and during a third time period succeeding the second time period: generating a fourth request to generate a fourth cryptographic secure object based on the third cryptographic secure object (Jones Fig 2- Fig 4 and text on [0033-0038] teaches generating next certificate based on previous certificate i.e., fourth secure object based on third secure object);
transmitting the fourth request to the second server via the second communication link (Jones on [0023] teaches the applicant sends the CSR (i.e., request) to a trusted CA. The CA receives the CSR and independently verifies the information included within the CSR is correct. If the CA believes the information to be correct, the CA signs a digital certificate (with the CA's own private key) that includes the applicant's public key and the other identifying information. The CA then provides the signed digital certificate back to the applicant);
receiving the fourth cryptographic secure object from the second server, the fourth cryptographic secure object: generated by the second server based on the second cryptographic secure object and the third cryptographic secure object and characterized by a third security level (Jones Fig 2- Fig 4 and text on [0033-0038] teaches generating next certificate based on previous certificate and chain of certificate continuous until end entity certificate is generated as show in Fig 2-Fig 4 i.e., fourth secure object based on third secure object and second secure object);
and executing a second action based on the fourth cryptographic secure object (Jones Fig 2- Fig 4 and text on [0033-0038] teaches generating next certificate based on previous certificate and chain of certificate continuous until end entity certificate is generated as show in Fig 2-Fig 4 i.e., the generation of next certificate based on previous certificate is equivalent to action based on secure object);
Although Jones teaches different security level associated with certificates in the chain, but fails to explicitly teach performing action based on third security level exceeding the second security level, however Kelley from analogous art teaches
(Kelley on [col 4 line 50-65] teaches certification protected at different security level. “FIPS 140” is used, it refers primarily to FIPS 140-2, but, in some embodiments, FIPS 140-1 or the forthcoming FIPS 140-3 (currently in draft form) may be used instead. The various FIPS 140 standards are published by the National Institute of Standards and Technology, available online at the website h_t_t_p://csrc.nist.gov/publications/PubsFIPS.html. The FIPS 140-1, FIPS 140-2, and FIPS 140-3 standards i.e., interpreted in view of [0056] of spec where security levels are defined as FIPS 140-1, 140-2 and 140-3).
Thus, it would have been obvious to one ordinary skill in the art before the effective filing date to implement the teaching of Kelley into the teaching of Jones by comparing different level of security associated with certificate. One would be motivated to do so in order to toggle from a first cryptographic operating mode to a second cryptographic operating mode in a highly-available manner based on different security level (Kelley [col 2 line 5-25]).
Regarding claim 2 the combination of Jones and Kelley teaches all the limitations of claim 1 above, Jones further teaches and further comprising, during a fourth time period succeeding the third time period: generating a fourth request to generate a fifth cryptographic secure object characterized by the first security level; transmitting the fourth request to the first server via the first communication link (Jones Fig 2- Fig 4 and text on [0033-0038] teaches generating next certificate based on previous certificate and chain of certificate continuous until end entity certificate is generated as show in Fig 2-Fig 4 i.e., the generation of next certificate based on previous certificate).
Kelley further teaches wherein executing the second action comprises issuing a first command that causes a platform to transition from a first operating mode to a second operating mode based on the fourth cryptographic secure object characterized by the third security level (Kelley on [col 6 line 35-67 and col 8 line 1-40] teaches in response to a user sending FIPS 140 mode toggle request 70 to initial master node 32(a) via network interface 60 in order to toggle the FIPS 140 switch 64 from one cryptographic operating mode to another (e.g., from FIPS 140 OFF to FIPS 140 ON). Further teaches when the initial peer node 32(b) begins to reboot, it will automatically boot up into the second cryptographic operating mode (e.g., FIPS 140 ON) because of the value of FIPS 140 switch 64. Thus, mode flags 43, 47, and 51 of initial peer node 32(b) will be set to the first cryptographic operating mode (e.g., FIPS 140 OFF) prior to rebooting but to the second cryptographic operating mode (e.g., FIPS 140 ON) just after rebooting).
and in response to receiving the fifth cryptographic secure object from the first server, issuing a second command that causes the platform to transition from the second operating mode to the first operating mode based on the fifth cryptographic secure object characterized by the first security level (Kelley on [col 6 line 35-67 and col 8 line 1-40] teaches in response to a user sending FIPS 140 mode toggle request 70 to initial master node 32(a) via network interface 60 in order to toggle the FIPS 140 switch 64 from one cryptographic operating mode to another (e.g., from FIPS 140 OFF to FIPS 140 ON). Further teaches when the initial peer node 32(b) begins to reboot, it will automatically boot up into the second cryptographic operating mode (e.g., FIPS 140 ON) because of the value of FIPS 140 switch 64. Thus, mode flags 43, 47, and 51 of initial peer node 32(b) will be set to the first cryptographic operating mode (e.g., FIPS 140 OFF) prior to rebooting but to the second cryptographic operating mode (e.g., FIPS 140 ON) just after rebooting.)
Thus, it would have been obvious to one ordinary skill in the art before the effective filing date to implement the teaching of Kelley into the teaching of Jones by comparing different level of security associated with certificate. One would be motivated to do so in order to toggle from a first cryptographic operating mode to a second cryptographic operating mode in a highly-available manner based on different security level (Kelley [col 2 line 5-25]).
Regarding claim 3 the combination of Jones and Kelley teaches all the limitations of claim 1 above, Jones further teaches wherein generating the fourth request comprises generating the fourth request in response to absence of the first communication link; and wherein executing the second action comprises bypassing the first action in response to expiration of the first cryptographic secure object; and executing the second action based on the fourth cryptographic secure object (Jones on [0026-0028 and 0054] teaches digital certificates are typically enforced with an expiration time or period of validity. For example, a digital certificate may include a start point of its period of validity and an end point of its period of validity (i.e., its expiration point). After the period of validity has ended, the digital certificate is no longer valid and third parties should no longer accept the certificate as evidence of ownership of the respective public key).
Regarding claim 4 the combination of Jones and Kelley teaches all the limitations of claim 1 above, Kelley further teaches wherein transmitting the first request comprises transmitting the first request to the first server via the first communication link based on a virtual private network; and wherein transmitting the second request comprises transmitting the second request to the second server via the second communication link based on a public network in response to absence of the first communication link (Kelley on [col 3 line 45-55] teaches communication using public and virtual private network).
Regarding claim 5 the combination of Jones and Kelley teaches all the limitations of claim 1 above, Kelley further teaches wherein executing the first action comprises issuing a first command that causes a platform to operate at a nominal operating mode based on a first configuration of the security device according to the first security level based on the first cryptographic secure object; and wherein executing the second action comprises issuing a second command that causes the platform to operate at a degraded operating mode based on a second configuration of the security device according to the third security level based on the fourth cryptographic secure object (Kelley on [col 6 line 35-67 and col 8 line 1-40] teaches in response to a user sending FIPS 140 mode toggle request 70 to initial master node 32(a) via network interface 60 in order to toggle the FIPS 140 switch 64 from one cryptographic operating mode to another (e.g., from FIPS 140 OFF to FIPS 140 ON). Further teaches when the initial peer node 32(b) begins to reboot, it will automatically boot up into the second cryptographic operating mode (e.g., FIPS 140 ON) because of the value of FIPS 140 switch 64. Thus, mode flags 43, 47, and 51 of initial peer node 32(b) will be set to the first cryptographic operating mode (e.g., FIPS 140 OFF) prior to rebooting but to the second cryptographic operating mode (e.g., FIPS 140 ON) just after rebooting).
Thus, it would have been obvious to one ordinary skill in the art before the effective filing date to implement the teaching of Kelley into the teaching of Jones by comparing different level of security associated with certificate. One would be motivated to do so in order to toggle from a first cryptographic operating mode to a second cryptographic operating mode in a highly-available manner based on different security level (Kelley [col 2 line 5-25]).
Regarding claim 6 the combination of Jones and Kelley teaches all the limitations of claim 5 above, Kelley further teaches wherein executing the second action comprises selecting the second action in a set of actions comprising: the first action; the second action; and a third action comprising issuing a third command that causes the platform to transition to a safe state based on a third configuration of the security device according to the second security level (Kelley on [col 6 line 35-67 and col 8 line 1-40] teaches in response to a user sending FIPS 140 mode toggle request 70 to initial master node 32(a) via network interface 60 in order to toggle the FIPS 140 switch 64 from one cryptographic operating mode to another (e.g., from FIPS 140 OFF to FIPS 140 ON). Further teaches when the initial peer node 32(b) begins to reboot, it will automatically boot up into the second cryptographic operating mode (e.g., FIPS 140 ON) because of the value of FIPS 140 switch 64. Thus, mode flags 43, 47, and 51 of initial peer node 32(b) will be set to the first cryptographic operating mode (e.g., FIPS 140 OFF) prior to rebooting but to the cryptographic operating mode (e.g., FIPS 140 ON) just after rebooting. See also on [col 4 line 60-67] teaches Linux kernel 42 may include FIPS 140 extensions 44, which are system calls that are implemented in FIPS 140 safe ways. Linux kernel 43 also contains a mode flag 43, which temporarily stores (in volatile memory) a value that indicates whether the Linux kernel 42 is operating in a FIPS 140-compliant mode).
Thus, it would have been obvious to one ordinary skill in the art before the effective filing date to implement the teaching of Kelley into the teaching of Jones by comparing different level of security associated with certificate. One would be motivated to do so in order to toggle from a first cryptographic operating mode to a second cryptographic operating mode in a highly-available manner based on different security level (Kelley [col 2 line 5-25]).
Regarding claim 7 the combination of Jones and Kelley teaches all the limitations of claim 1 above, Jones further teaches wherein executing the first action comprises authenticating with a second security device based on the first cryptographic secure object by: generating a first message comprising the first cryptographic secure object characterized by the first signature associated with the first server; and transmitting the first message to the second security device; and wherein executing the second action comprises authenticating with a third security device based on the fourth cryptographic secure object by: generating a second message comprising the fourth cryptographic secure object associated with the second cryptographic secure object and the third cryptographic secure object; and transmitting the second message to the third security device (Jones on [0030-0033 and 0036] teaches each intermediate CA 310N in the chain includes or is associated with a respective intermediate certificate 210, 210Na-n digitally signed by the intermediate CA 310N that is immediately higher in the chain of intermediate CAs 310N than the corresponding intermediate CA 310N. The remote system 140 may use any appropriate signing algorithm to sign the certificates 210. The respective intermediate certificate 210N of the intermediate CA 310N that is highest in the chain is signed by the root CA 310R, thus establishing a chain of trust. The lowest intermediate CA in the chain (i.e., intermediate CA 310Nc in the given example) issues end entity certificates 210L (e.g., X.509 certificates) to an end-entity 30 via, for example, network 20, 20a. Further teaches the intermediate certificate 210Nb also includes the ID 230Nb and the public key 220Nb second intermediate CA 310Nb. This chain continues for any length until a final intermediate CA 310Nn provides an end entity certificate 310L that includes its ID 230Nn and signature 240Nn to the entity 30 i.e., respective intermediate certificates are lower in the chain, The first intermediate certificate is higher level, then comes all the respective certificate, finally the lowest is the end entity certificate as shown in Fig 2 and Fig 3).
Regarding claim 10 the combination of Jones and Kelley teaches all the limitations of claim 1 above, Jones further teaches wherein receiving the fourth cryptographic secure object comprises receiving the fourth cryptographic secure object specifying: a first identifier associated with the first server; the first signature associated with the first server based on the second cryptographic secure object; a second identifier associated with the second server; and a second signature associated with the second server based on the third cryptographic secure object (Jones on [0023] teaches a digital certificate applicant generates a key pair (i.e., a private key and a public key) and a certificate signing request (CSR). The CSR includes the public key and other information to be included in the certificate (e.g., the entity's name or identifier, domain name information, contact information, etc.). The applicant sends the CSR to a trusted CA. The CA receives the CSR and independently verifies the information included within the CSR is correct. If the CA believes the information to be correct, the CA signs a digital certificate (with the CA's own private key) that includes the applicant's public key and the other identifying information. The CA then provides the signed digital certificate back to the applicant).
Regarding claim 11 the combination of Jones and Kelley teaches all the limitations of claim 1 above, Jones further teaches further comprising, at the second server: generating the third cryptographic secure object characterized by the second security level; generating a fifth request to digitally sign the third cryptographic secure object based on the second cryptographic secure object, the fifth request comprising the third cryptographic secure object; transmitting the fifth request to the first server via a third communication link; and generating the fourth cryptographic secure object based on the third cryptographic secure object in response to receiving the third cryptographic secure object characterized by the first signature associated with the first server and based on the second cryptographic secure object (Jones Fig 2- Fig 4 and text on [0033-0038] teaches generating next certificate based on previous certificate and chain of certificate continuous until end entity certificate is generated as show in Fig 2-Fig 4 i.e., fourth secure object based on third secure object and second secure object).
Regarding claim 12 the combination of Jones and Kelley teaches all the limitations of claim 11 above, Jones further teaches wherein generating the third cryptographic secure object comprises generating the third cryptographic secure object specifying: a first validity period charactered by a first duration; and a second validity period succeeding the first validity period and characterized by a second duration; and" wherein generating the fourth cryptographic secure object comprises generating the fourth cryptographic secure object based on the third cryptographic secure object during the second validity period and in response to expiration of the first duration (Jones on [0028, 0034-0037 and 0054] teaches The system includes a chain of time-based intermediate certificate authorities (CAs) that are each associated with or include a respective validation time period. The chain of intermediate CAs and respective validation time periods encode an expiration time into the certificates issued by the chain of intermediate CAs. Based on the respective validation time periods. Further teaches Each of these intermediate CAs 310 will only issue certificates 210N, 210L during the period of time within the validation time period 312 associated with the respective intermediate CA 310. For example, the intermediate CA 310Ne.sub.1 may only issue certificates 210L for the 24 hours of Jan. 1, 2020. Once it becomes Jan. 2, 2020, the validation time period 312e.sub.1 will conclude and the validation time period 312e.sub.2 for the intermediate CA 310Ne.sub.2 begins. Similarly, for the time period from Jan. 1, 2020 through Jan. 7, 2020, the intermediate CA 310Nd.sub.1 (“Week 1”) may issue certificates 210N while from Jan. 8, 2020 to Jan. 14, 2020, the intermediate CA 310Nd.sub.2 (“Week 2”) may issue certificates 210N. In some implementations, the respective validation time period 312 of each intermediate CA 310N is shorter than the validation time periods 312 of any intermediate CAs 310N higher in the chain of intermediate CAs 310N than the respective intermediate CA 310N. For example, the validation time period 312 for the “January” intermediate CA 310NC.sub.1 (i.e., one month) is shorter than the validation time period 312 of both of the intermediate CAs 310N higher in the chain (i.e., the Q1 intermediate CA 310Nb.sub.1 and the 2020 intermediate CA 310Na.sub.1) That is, as the chain of intermediate CAs 310N is descended, the validation time period 312 grows shorter).
Regarding claim 13 the combination of Jones and Kelley teaches all the limitations of claim 11 above, Jones further teaches wherein generating the fourth cryptographic secure object comprises generating the third cryptographic secure object specifying: a first validity period charactered by a first duration; and a second validity period succeeding the first validity period and characterized by a second duration; and wherein executing the second action comprises executing the second action based on the fourth cryptographic secure object during the second validity period and in response to expiration of the first duration (Jones on [0028, 0034-0037 and 0054] teaches The system includes a chain of time-based intermediate certificate authorities (CAs) that are each associated with or include a respective validation time period. The chain of intermediate CAs and respective validation time periods encode an expiration time into the certificates issued by the chain of intermediate CAs. Based on the respective validation time periods. Further teaches Each of these intermediate CAs 310 will only issue certificates 210N, 210L during the period of time within the validation time period 312 associated with the respective intermediate CA 310. For example, the intermediate CA 310Ne.sub.1 may only issue certificates 210L for the 24 hours of Jan. 1, 2020. Once it becomes Jan. 2, 2020, the validation time period 312e.sub.1 will conclude and the validation time period 312e.sub.2 for the intermediate CA 310Ne.sub.2 begins. Similarly, for the time period from Jan. 1, 2020 through Jan. 7, 2020, the intermediate CA 310Nd.sub.1 (“Week 1”) may issue certificates 210N while from Jan. 8, 2020 to Jan. 14, 2020, the intermediate CA 310Nd.sub.2 (“Week 2”) may issue certificates 210N. In some implementations, the respective validation time period 312 of each intermediate CA 310N is shorter than the validation time periods 312 of any intermediate CAs 310N higher in the chain of intermediate CAs 310N than the respective intermediate CA 310N. For example, the validation time period 312 for the “January” intermediate CA 310NC.sub.1 (i.e., one month) is shorter than the validation time period 312 of both of the intermediate CAs 310N higher in the chain (i.e., the Q1 intermediate CA 310Nb.sub.1 and the 2020 intermediate CA 310Na.sub.1) That is, as the chain of intermediate CAs 310N is descended, the validation time period 312 grows shorter).
Regarding claim 14 the combination of Jones and Kelley teaches all the limitations of claim 11 above, Jones further teaches wherein generating the fourth request comprises generating the fourth request comprising: a public key associated with the security device; and a second signature based on a private key corresponding to the public key; and wherein generating the fourth cryptographic secure object comprises generating the fourth cryptographic secure object in response to validating the fourth request based on the first public key and the second signature (Jones on [0023-0025] teaches the CA signs a digital certificate (with the CA's own private key) that includes the applicant's public key and the other identifying information. The CA then provides the signed digital certificate back to the applicant).
Regarding claim 15 the combination of Jones and Kelley teaches all the limitations of claim 1 above, Jones further teaches further comprising, at the first server: generating the second cryptographic secure object characterized by the first security level; and digitally signing the third cryptographic secure object based on the second cryptographic secure object (Jones Fig 2- Fig 4 and text on [0031-0034] teaches the remote system establishes a chain of trust 200 between the intermediate certificates 310N by signing each certificate 210 in the chain with the public key 220N of the intermediate CA 310N immediately higher in the chain.)
Regarding claim 16 Jones teaches a method comprising: at a security device during a first time period: (Jones on [0003] teaches method for generating digital certificate implemented by processing hardware);
generating a first request: to generate a first cryptographic secure object characterized by a first security level (Jones on [0030] teaches the remote system 140 includes the root certificate authority 310R and generates the root certificate 210R. See on [0054] teaches each respective intermediate certificate authority 310N in the chain of intermediate certificate authorities 310N includes a respective intermediate certificate 210N (i.e., first cryptographic secure object) digitally signed by the intermediate certificate authority 310N or the root certificate authority 310R that is immediately higher (i.e., first security level) in the chain of intermediate certificate authorities 310N than the respective intermediate certificate authority 310N. See on [0023] teaches the applicant sends the CSR (i.e., request) to a trusted CA. The CA receives the CSR and independently verifies the information included within the CSR is correct. If the CA believes the information to be correct, the CA signs a digital certificate (with the CA's own private key) that includes the applicant's public key and the other identifying information. The CA then provides the signed digital certificate back to the applicant);
and to digitally sign a second cryptographic secure object characterized by a second security level falling below the first security level (Jones on [0030-0033] teaches each intermediate CA 310N in the chain includes or is associated with a respective intermediate certificate 210, 210Na-n digitally signed by the intermediate CA 310N that is immediately higher in the chain of intermediate CAs 310N than the corresponding intermediate CA 310N. The remote system 140 may use any appropriate signing algorithm to sign the certificates 210. The respective intermediate certificate 210N of the intermediate CA 310N that is highest in the chain is signed by the root CA 310R, thus establishing a chain of trust. The lowest intermediate CA in the chain (i.e., intermediate CA 310Nc in the given example) issues end entity certificates 210L (e.g., X.509 certificates) to an end-entity 30 via, for example, network 20, 20a. Further teaches the intermediate certificate 210Nb also includes the ID 230Nb and the public key 220Nb second intermediate CA 310Nb. This chain continues for any length until a final intermediate CA 310Nn provides an end entity certificate 310L that includes its ID 230Nn and signature 240Nn to the entity 30 i.e., respective intermediate certificates are lower in the chain, The first intermediate certificate is higher level, then comes all the respective certificate, finally the lowest is the end entity certificate as shown in Fig 2 and Fig 3);
transmitting the first request to a first server via a first communication link (Jones on [0023] teaches the applicant sends the CSR (i.e., request) to a trusted CA. The CA receives the CSR and independently verifies the information included within the CSR is correct. If the CA believes the information to be correct, the CA signs a digital certificate (with the CA's own private key) that includes the applicant's public key and the other identifying information. The CA then provides the signed digital certificate back to the applicant);
generating a second request to generate the second cryptographic secure object associated with the first cryptographic secure object (Jones Fig 2 and text on [0033 and 0054] teaches continuing up the chain, the first intermediate CA 310Na issues another intermediate certificate 210Nb (i.e., second cryptographic secure object at higher level in the chain as shown in Fig 2 and Fig 3) to a second intermediate CA 310Nb, intermediate certificate 210Nb includes the signature 240Na and the ID 230Na of the first intermediate CA 310Na. i.e., generating next intermediate certificate based on first intermediate CA is equivalent to executing action);
and transmitting the second request to a second server via a second communication link (Jones on [0023] teaches the applicant sends the CSR (i.e., request) to a trusted CA. The CA receives the CSR and independently verifies the information included within the CSR is correct. If the CA believes the information to be correct, the CA signs a digital certificate (with the CA's own private key) that includes the applicant's public key and the other identifying information. The CA then provides the signed digital certificate back to the applicant);
at the second server during the first time period: generating the second cryptographic secure object characterized by the second security level (Jones on [0030-0033] teaches each intermediate CA 310N in the chain includes or is associated with a respective intermediate certificate 210, 210Na-n digitally signed by the intermediate CA 310N that is immediately higher in the chain of intermediate CAs 310N than the corresponding intermediate CA 310N. The remote system 140 may use any appropriate signing algorithm to sign the certificates 210. The respective intermediate certificate 210N of the intermediate CA 310N that is highest in the chain is signed by the root CA 310R, thus establishing a chain of trust. The lowest intermediate CA in the chain (i.e., intermediate CA 310Nc in the given example) issues end entity certificates 210L (e.g., X.509 certificates) to an end-entity 30 via, for example, network 20, 20a. Further teaches the intermediate certificate 210Nb also includes the ID 230Nb and the public key 220Nb second intermediate CA 310Nb. This chain continues for any length until a final intermediate CA 310Nn provides an end entity certificate 310L that includes its ID 230Nn and signature 240Nn to the entity 30 i.e., respective intermediate certificates are lower in the chain, The first intermediate certificate is higher level, then comes all the respective certificate, finally the lowest is the end entity certificate as shown in Fig 2 and Fig 3);
generating a third request to digitally sign the second cryptographic secure object based on the first cryptographic secure object (Jones on [0030-0033] teaches each intermediate CA 310N in the chain includes or is associated with a respective intermediate certificate 210, 210Na-n digitally signed by the intermediate CA 310N that is immediately higher in the chain of intermediate CAs 310N than the corresponding intermediate CA 310N. The remote system 140 may use any appropriate signing algorithm to sign the certificates 210. The respective intermediate certificate 210N of the intermediate CA 310N that is highest in the chain is signed by the root CA 310R, thus establishing a chain of trust. The lowest intermediate CA in the chain (i.e., intermediate CA 310Nc in the given example) issues end entity certificates 210L (e.g., X.509 certificates) to an end-entity 30 via, for example, network 20, 20a. Further teaches the intermediate certificate 210Nb also includes the ID 230Nb and the public key 220Nb second intermediate CA 310Nb. This chain continues for any length until a final intermediate CA 310Nn provides an end entity certificate 310L that includes its ID 230Nn and signature 240Nn to the entity 30 i.e., respective intermediate certificates are lower in the chain, The first intermediate certificate is higher level, then comes all the respective certificate, finally the lowest is the end entity certificate as shown in Fig 2 and Fig 3);
and transmitting the fourth request to the first server via a second communication link (Jones on [0023] teaches the applicant sends the CSR (i.e., request) to a trusted CA. The CA receives the CSR and independently verifies the information included within the CSR is correct. If the CA believes the information to be correct, the CA signs a digital certificate (with the CA's own private key) that includes the applicant's public key and the other identifying information. The CA then provides the signed digital certificate back to the applicant);
and at the security device during a second time period succeeding the first time period:
generating a fourth request to generate a third cryptographic secure object based on the second cryptographic secure object (Jones on [0030-0033 and 0036] teaches each intermediate CA 310N in the chain includes or is associated with a respective intermediate certificate 210, 210Na-n digitally signed by the intermediate CA 310N that is immediately higher in the chain of intermediate CAs 310N than the corresponding intermediate CA 310N. The remote system 140 may use any appropriate signing algorithm to sign the certificates 210. The respective intermediate certificate 210N of the intermediate CA 310N that is highest in the chain is signed by the root CA 310R, thus establishing a chain of trust. The lowest intermediate CA in the chain (i.e., intermediate CA 310Nc in the given example) issues end entity certificates 210L (e.g., X.509 certificates) to an end-entity 30 via, for example, network 20, 20a. Further teaches the intermediate certificate 210Nb also includes the ID 230Nb and the public key 220Nb second intermediate CA 310Nb. This chain continues for any length until a final intermediate CA 310Nn provides an end entity certificate 310L that includes its ID 230Nn and signature 240Nn to the entity 30 i.e., respective intermediate certificates are lower in the chain, The first intermediate certificate is higher level, then comes all the respective certificate, finally the lowest is the end entity certificate as shown in Fig 2 and Fig 3);
transmitting the second request to the second server via the second communication link (Jones on [0023] teaches the applicant sends the CSR (i.e., request) to a trusted CA. The CA receives the CSR and independently verifies the information included within the CSR is correct. If the CA believes the information to be correct, the CA signs a digital certificate (with the CA's own private key) that includes the applicant's public key and the other identifying information. The CA then provides the signed digital certificate back to the applicant);
receiving the third cryptographic secure object from the second server, the third cryptographic secure object: generated by the second server based on the first cryptographic secure object and the second cryptographic secure object; and characterized by a third security level (Jones Fig 2- Fig 4 and text on [0033-0038] teaches generating next certificate based on previous certificate and chain of certificate continuous until end entity certificate is generated as show in Fig 2-Fig 4 i.e., fourth secure object based on third secure object and second secure object);
and executing a first action based on the third cryptographic secure object (Jones Fig 2 and text on [0033 and 0054] teaches continuing up the chain, the first intermediate CA 310Na issues another intermediate certificate 210Nb to a second intermediate CA 310Nb, intermediate certificate 210Nb includes the signature 240Na and the ID 230Na of the first intermediate CA 310Na. i.e., generating next intermediate certificate based on first intermediate CA is equivalent to executing action).
Although Jones teaches different security level associated with certificates in the chain, but fails to explicitly teach performing action based on third security level exceeding the second security level, however Kelley from analogous art teaches
characterized by a third security level exceeding the second security level (Kelley on [col 4 line 50-65] teaches certification protected at different security level. “FIPS 140” is used, it refers primarily to FIPS 140-2, but, in some embodiments, FIPS 140-1 or the forthcoming FIPS 140-3 (currently in draft form) may be used instead. The various FIPS 140 standards are published by the National Institute of Standards and Technology, available online at the website h_t_t_p://csrc.nist.gov/publications/PubsFIPS.html. The FIPS 140-1, FIPS 140-2, and FIPS 140-3 standards i.e., interpreted in view of [0056] of spec where security levels are defined as FIPS 140-1, 140-2 and 140-3).
Thus, it would have been obvious to one ordinary skill in the art before the effective filing date to implement the teaching of Kelley into the teaching of Jones by comparing different level of security associated with certificate. One would be motivated to do so in order to toggle from a first cryptographic operating mode to a second cryptographic operating mode in a highly-available manner based on different security level (Kelley [col 2 line 5-25]).
Regarding claim 17 the combination of Jones and Kelley teaches all the limitations of claim 16 above, Kelley further teaches wherein generating the fourth request comprises generating the fourth request in response to absence of the first communication link; and wherein executing the first action comprises: bypassing a second action associated with the first security level; and executing the first action associated with the third security level (Kelley on [col 6 line 35-67 and col 8 line 1-40] teaches in response to a user sending FIPS 140 mode toggle request 70 to initial master node 32(a) via network interface 60 in order to toggle the FIPS 140 switch 64 from one cryptographic operating mode to another (e.g., from FIPS 140 OFF to FIPS 140 ON). Further teaches when the initial peer node 32(b) begins to reboot, it will automatically boot up into the second cryptographic operating mode (e.g., FIPS 140 ON) because of the value of FIPS 140 switch 64. Thus, mode flags 43, 47, and 51 of initial peer node 32(b) will be set to the first cryptographic operating mode (e.g., FIPS 140 OFF) prior to rebooting but to the second cryptographic operating mode (e.g., FIPS 140 ON) just after rebooting).
Thus, it would have been obvious to one ordinary skill in the art before the effective filing date to implement the teaching of Kelley into the teaching of Jones by comparing different level of security associated with certificate. One would be motivated to do so in order to toggle from a first cryptographic operating mode to a second cryptographic operating mode in a highly-available manner based on different security level (Kelley [col 2 line 5-25]).
Regarding claim 18 the combination of Jones and Kelley teaches all the limitations of claim 17 above, Kelley further teaches wherein bypassing the second action comprises bypassing the second action comprising issuing a first command that causes a platform associated with the security device to operate at a first operating mode based on the first security level; and" wherein executing the first action comprises executing the first action comprising issuing a second command that causes the platform to operate at a second operating mode based on the third security level (Kelley on [col 6 line 35-67 and col 8 line 1-40] teaches in response to a user sending FIPS 140 mode toggle request 70 to initial master node 32(a) via network interface 60 in order to toggle the FIPS 140 switch 64 from one cryptographic operating mode to another (e.g., from FIPS 140 OFF to FIPS 140 ON). Further teaches when the initial peer node 32(b) begins to reboot, it will automatically boot up into the second cryptographic operating mode (e.g., FIPS 140 ON) because of the value of FIPS 140 switch 64. Thus, mode flags 43, 47, and 51 of initial peer node 32(b) will be set to the first cryptographic operating mode (e.g., FIPS 140 OFF) prior to rebooting but to the cryptographic operating mode (e.g., FIPS 140 ON) just after rebooting).
Thus, it would have been obvious to one ordinary skill in the art before the effective filing date to implement the teaching of Kelley into the teaching of Jones by comparing different level of security associated with certificate. One would be motivated to do so in order to toggle from a first cryptographic operating mode to a second cryptographic operating mode in a highly-available manner based on different security level (Kelley [col 2 line 5-25]).
Regarding claim 19 the combination of Jones and Kelley teaches all the limitations of claim 16 above, Jones further teaches further comprising, at the second server during the second time period, generating the third cryptographic secure object based on the second cryptographic secure object in response to receiving the second cryptographic secure object characterized by a signature associated with the first server and based on the first cryptographic secure object (Jones Fig 2- Fig 4 and text on [0033-0038] teaches generating next certificate based on previous certificate and chain of certificate continuous until end entity certificate is generated as show in Fig 2-Fig 4 i.e., third secure object based on first secure object and second secure object).
Regarding claim 20 Jones a method comprising, at a security device: (Jones on [0003] teaches method for generating digital certificate implemented by processing hardware);
during a first time period: generating a first request: to generate a first cryptographic secure object protected at a first security level (Jones on [0030] teaches the remote system 140 includes the root certificate authority 310R and generates the root certificate 210R. See on [0054] teaches each respective intermediate certificate authority 310N in the chain of intermediate certificate authorities 310N includes a respective intermediate certificate 210N (i.e., first cryptographic secure object) digitally signed by the intermediate certificate authority 310N or the root certificate authority 310R that is immediately higher (i.e., first security level) in the chain of intermediate certificate authorities 310N than the respective intermediate certificate authority 310N. See on [0023] teaches the applicant sends the CSR (i.e., request) to a trusted CA. The CA receives the CSR and independently verifies the information included within the CSR is correct. If the CA believes the information to be correct, the CA signs a digital certificate (with the CA's own private key) that includes the applicant's public key and the other identifying information. The CA then provides the signed digital certificate back to the applicant);
and to digitally sign a second cryptographic secure object protected at a second security level falling below the first security level (Jones on [0030-0033] teaches each intermediate CA 310N in the chain includes or is associated with a respective intermediate certificate 210, 210Na-n digitally signed by the intermediate CA 310N that is immediately higher in the chain of intermediate CAs 310N than the corresponding intermediate CA 310N. The remote system 140 may use any appropriate signing algorithm to sign the certificates 210. The respective intermediate certificate 210N of the intermediate CA 310N that is highest in the chain is signed by the root CA 310R, thus establishing a chain of trust. The lowest intermediate CA in the chain (i.e., intermediate CA 310Nc in the given example) issues end entity certificates 210L (e.g., X.509 certificates) to an end-entity 30 via, for example, network 20, 20a. Further teaches the intermediate certificate 210Nb also includes the ID 230Nb and the public key 220Nb second intermediate CA 310Nb. This chain continues for any length until a final intermediate CA 310Nn provides an end entity certificate 310L that includes its ID 230Nn and signature 240Nn to the entity 30 i.e., respective intermediate certificates are lower in the chain, The first intermediate certificate is higher level, then comes all the respective certificate, finally the lowest is the end entity certificate as shown in Fig 2 and Fig 3);
transmitting the first request to a first server via a first communication link (Jones on [0023] teaches the applicant sends the CSR (i.e., request) to a trusted CA. The CA receives the CSR and independently verifies the information included within the CSR is correct. If the CA believes the information to be correct, the CA signs a digital certificate (with the CA's own private key) that includes the applicant's public key and the other identifying information. The CA then provides the signed digital certificate back to the applicant);
generating a second request to generate the second cryptographic secure object associated with the first cryptographic secure object (Jones Fig 2 and text on [0033 and 0054] teaches continuing up the chain, the first intermediate CA 310Na issues another intermediate certificate 210Nb (i.e., second cryptographic secure object at higher level in the chain as shown in Fig 2 and Fig 3) to a second intermediate CA 310Nb, intermediate certificate 210Nb includes the signature 240Na and the ID 230Na of the first intermediate CA 310Na. i.e., generating next intermediate certificate based on first intermediate CA is equivalent to executing action);
and transmitting the second request to a second server via a second communication link (Jones on [0023] teaches the applicant sends the CSR (i.e., request) to a trusted CA. The CA receives the CSR and independently verifies the information included within the CSR is correct. If the CA believes the information to be correct, the CA signs a digital certificate (with the CA's own private key) that includes the applicant's public key and the other identifying information. The CA then provides the signed digital certificate back to the applicant);
and during a second time period succeeding the first time period: generating a third request to generate a third cryptographic secure object based on the second cryptographic secure object in response to absence of the first communication link (Jones on [0030-0033] teaches each intermediate CA 310N in the chain includes or is associated with a respective intermediate certificate 210, 210Na-n digitally signed by the intermediate CA 310N that is immediately higher in the chain of intermediate CAs 310N than the corresponding intermediate CA 310N. The remote system 140 may use any appropriate signing algorithm to sign the certificates 210. The respective intermediate certificate 210N of the intermediate CA 310N that is highest in the chain is signed by the root CA 310R, thus establishing a chain of trust. The lowest intermediate CA in the chain (i.e., intermediate CA 310Nc in the given example) issues end entity certificates 210L (e.g., X.509 certificates) to an end-entity 30 via, for example, network 20, 20a. Further teaches the intermediate certificate 210Nb also includes the ID 230Nb and the public key 220Nb second intermediate CA 310Nb. This chain continues for any length until a final intermediate CA 310Nn provides an end entity certificate 310L that includes its ID 230Nn and signature 240Nn to the entity 30 i.e., respective intermediate certificates are lower in the chain, The first intermediate certificate is higher level, then comes all the respective certificate, finally the lowest is the end entity certificate as shown in Fig 2 and Fig 3);
transmitting the second request to the second server via the second communication link (Jones on [0023] teaches the applicant sends the CSR (i.e., request) to a trusted CA. The CA receives the CSR and independently verifies the information included within the CSR is correct. If the CA believes the information to be correct, the CA signs a digital certificate (with the CA's own private key) that includes the applicant's public key and the other identifying information. The CA then provides the signed digital certificate back to the applicant);
receiving the third cryptographic secure object from the second server, the third cryptographic secure object: generated by the second server based on the first cryptographic secure object and the second cryptographic secure object and protected at a third security level
(Jones Fig 2- Fig 4 and text on [0033-0038] teaches generating next certificate based on previous certificate and chain of certificate continuous until end entity certificate is generated as show in Fig 2-Fig 4 and is associated with certain level in the chain of trust i.e., third secure object based on second secure object and first secure object);
and executing an action based on the third cryptographic secure object (Jones Fig 2- Fig 4 and text on [0033-0038] teaches generating next certificate based on previous certificate and chain of certificate continuous until end entity certificate is generated as show in Fig 2-Fig 4 i.e., the generation of next certificate based on previous certificate is equivalent to action based on secure object).
Although Jones teaches different security level associated with certificates in the chain, but fails to explicitly teach performing action based on third security level exceeding the second security level, however Kelley from analogous art teaches
the second cryptographic secure object and protected at a third security level exceeding the second security level (Kelley on [col 4 line 50-65] teaches certification protected at different security level. “FIPS 140” is used, it refers primarily to FIPS 140-2, but, in some embodiments, FIPS 140-1 or the forthcoming FIPS 140-3 (currently in draft form) may be used instead. The various FIPS 140 standards are published by the National Institute of Standards and Technology, available online at the website h_t_t_p://csrc.nist.gov/publications/PubsFIPS.html. The FIPS 140-1, FIPS 140-2, and FIPS 140-3 standards i.e., interpreted in view of [0056] of spec where security levels are defined as FIPS 140-1, 140-2 and 140-3).
Thus, it would have been obvious to one ordinary skill in the art before the effective filing date to implement the teaching of Kelley into the teaching of Jones by comparing different level of security associated with certificate. One would be motivated to do so in order to toggle from a first cryptographic operating mode to a second cryptographic operating mode in a highly-available manner based on different security level (Kelley [col 2 line 5-25]).
Claim 8 is rejected under 35 U.S.C. 103 as being unpatentable over Jones et al (hereinafter Jones) (US 20220116229) in view of Kelley et al (hereinafter Kelley) (US 9230121) and further in view of Baker et al (hereinafter Baker) (US 20230125983).
Regarding claim 8 the combination of Jones and Kelley teaches all the limitations of claim 1 above, the combination fails to explicitly teach wherein executing the second action comprises: accessing a set of actions associated with a task assigned to a platform associated with the security device, the set of actions comprising the first action and the second action; calculating a first risk score for the first action based on the third security level characterizing the fourth cryptographic secure object; calculating a second risk score for the second action based on the third security level characterizing the fourth cryptographic secure object; selecting the second action in response to the second risk score falling below a threshold risk score and the first risk score exceeding the threshold risk score; and executing the second action, however Baker from analogous art teaches
wherein executing the second action comprises: accessing a set of actions associated with a task assigned to a platform associated with the security device, the set of actions comprising the first action and the second action; calculating a first risk score for the first action based on the third security level characterizing the fourth cryptographic secure object; calculating a second risk score for the second action based on the third security level characterizing the fourth cryptographic secure object; selecting the second action in response to the second risk score falling below a threshold risk score and the first risk score exceeding the threshold risk score; and executing the second action (Baker on [0067, 0068, 0070, 0075, 0084, 0091-0097] teaches performing action based on comparing risk score with threshold risk score).
Thus, it would have been obvious to one ordinary skill in the art before the effective filing date to implement the teaching of Baker into the combined teaching of Jones and Kelley by comparing risk score with threshold limit. One would be motivated to do so in order to manage sensitive data determined based on comparing risk score with threshold (Baker [0005-0008]).
Claim 9 is rejected under 35 U.S.C. 103 as being unpatentable over Jones et al (hereinafter Jones) (US 20220116229) in view of Kelley et al (hereinafter Kelley) (US 9230121) and further in view of Bulusu et al (hereinafter Bulusu) (US 20220329442).
Regarding claim 9 the combination of Jones and Kelley teaches all the limitations of claim 1 above, Jones further teaches wherein generating the fourth request comprises: generating a set of cryptographic keys associated with the security device and including a public key and a private key; generating the fourth request to generate the fourth cryptographic secure object associated with the public key; (Jones on [0023] teaches a digital certificate applicant generates a key pair (i.e., a private key and a public key) and a certificate signing request (CSR). The CSR includes the public key and other information to be included in the certificate (e.g., the entity's name or identifier, domain name information, contact information, etc.). The applicant sends the CSR to a trusted CA. The CA receives the CSR and independently verifies the information included within the CSR is correct. If the CA believes the information to be correct, the CA signs a digital certificate (with the CA's own private key) that includes the applicant's public key and the other identifying information. The CA then provides the signed digital certificate back to the applicant).
The combination fails to explicitly teach storing the private key in a hardware security module of the security device, however Bulusu from analogous art teaches storing the private key in a hardware security module of the security device (Bulusu on [0163] teaches HSM hold private key).
Thus, it would have been obvious to one ordinary skill in the art before the effective filing date to implement the teaching of Bulusu into the combined teaching of Jones and Kelley by storing private key in HSM. One would be motivated to do so in order to secure private key from unauthorized access (Bulusu [0163]).
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
SUBRAMANIAN et al (US 20230300124) is directed towards a certificate management service of a cloud provider network receives a first request to generate a certificate from an electronic device, the first request including an indication of an identity of a user and an identification of a domain name to associate with the certificate. A CA selection policy applicable to the first request is identified, the CA selection policy including a CA selection rule. A CA to generate the certificate is identified by evaluating the CA selection rule, the CA selection rule associates at least a portion of the domain name with the CA.
Sudia (US 20020013898) is directed towards a multi-step signing system and method uses multiple signing devices to affix a single signature which can be verified using a single public verification key. Each signing device possesses a share of the signature key and affixes a partial signature in response to authorization from a plurality of authorizing agents. In a serial embodiment, after a first partial signature has been affixed, a second signing device exponentiates the first partial signature.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to MOEEN KHAN whose telephone number is (571)272-3522. The examiner can normally be reached 7AM-5PM EST M-TH Alternate Fridays.
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, Shewaye Gelagay can be reached at (571)272-4219. 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.
/MOEEN KHAN/Primary Examiner, Art Unit 2436