DETAILED ACTION
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
The present application, filed on May 02, 2025, is accepted.
Claims 1 – 17 are being considered on the merits.
Drawings
The drawings, filed on May 02, 2025, are accepted.
Specification
The specification, filed on May 02, 2025, is accepted.
Double Patenting
No rejection warranted at application’s initial filling time of filling for a patent.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claim 1 – 17 are rejected under 35 U.S.C. 103 as being unpatentable over US 10193690 B1 to Self et al., (hereinafter, “Self”) in view of US 20220231848 A1 to Zhang et al., (hereinafter, “Zhang”) and US 20230021047 A1 to Ammar et al., (hereinafter, “Ammar”).
Regarding claim 1, Self teaches a method for validating at least one cryptographic key performed by a system comprising a processor and non-transitory computer-readable medium storing instructions that, when executed by the processor, cause the system to perform the method, the method comprising: receiving a request to perform an operation using at least one cryptographic key; [Self, col. 17 lines 46 – 56 discloses The process 400 includes receiving a request for a cryptographic key (stage 402). As discussed above, the key generator 206 can receive requests to provide a cryptographic key from the targeted encryption module 202 and the targeted decryption module 204. The process 400 further includes acquiring values of one or more system attributes based on a key generation policy (stage 404). As discussed above in relation to FIGS. 2 and 3, the key generator 206 can acquire values of various system attributes of the computing system 200. The attributes can include, for example, file system attributes 304, network attributes 306, and hardware attributes 308.], but Self does not teach comparing the at least one cryptographic key with one or more key rules to determine that the at least one cryptographic key complies with one or more requirements specified in the one or more key rules, wherein determining that the at least one cryptographic key complies with the one or more requirements specified in the one or more key rules comprises at least one of: determining that a derivative of the at least one cryptographic key comprises at least one specified pattern, and determining that the at least one cryptographic key has a specified relationship with binding data associated with the at least one cryptographic key; validating the at least one cryptographic key based on the determining that the at least one cryptographic key complies with the one or more requirements specified in the one or more key rules; and performing the operation using the at least one cryptographic key based on validating the at least one cryptographic key.
However, Zhang does teach c comparing the at least one cryptographic key with one or more key rules to determine that the at least one cryptographic key complies with one or more requirements specified in the one or more key rules, [Zhang, para. 30 discloses the request is decoded to determine parameters of the request such as parameters of the target instance requesting the key and parameters of the requested key. Additional decoded parameters can include parameters associated with the source instance, for example, to confirm the key exchange request is valid. Once the key request parameters are confirmed, the access policy associated with the request is evaluated. Based on configured access policies, the request may be approved or rejected. For example, access policies can include an exchange frequency parameter to determine how many requests of a particular type should be allowed. In some embodiments, the request may be associated with a one-time approval and subsequent requests of the same type are rejected.] wherein determining that the at least one cryptographic key complies with the one or more requirements specified in the one or more key rules comprises at least one of: determining that the at least one cryptographic key has a specified relationship with binding data associated with the at least one cryptographic key; [Zhang, para. 37 disclose source parameters of the requested key are confirmed. For example, the source cloud instance with the request key is confirmed to match the key source information included in the key exchange request. In some embodiments, the key exchange request includes one or more system identifiers of the key source. The one or more source parameters included in the key exchange request are confirmed, for example, to ensure the key request exchange is directed to the correct key source.] validating the at least one cryptographic key based on the determining that the at least one cryptographic key complies with the one or more requirements specified in the one or more key rules; [Zhang, para. 30 discloses the request is decoded to determine parameters of the request such as parameters of the target instance requesting the key and parameters of the requested key. Additional decoded parameters can include parameters associated with the source instance, for example, to confirm the key exchange request is valid. Once the key request parameters are confirmed, the access policy associated with the request is evaluated. Based on configured access policies, the request may be approved or rejected. For example, access policies can include an exchange frequency parameter to determine how many requests of a particular type should be allowed. In some embodiments, the request may be associated with a one-time approval and subsequent requests of the same type are rejected. The request may also be associated with a time limit or condition that a request must meet to be approved, such as a maximum number of allowed requests and/or allowing all reoccurring requests of a particular type to be approved. In some embodiments, access control lists are used to determine whether the requester is allowed access to the requested key.] and performing the operation using the at least one cryptographic key based on validating the at least one cryptographic key. [Zhang, para. 31 discloses a determination is made whether the key exchange request is approved. In the event the key exchange request is approved, processing proceeds to 311. In the event the key exchange request is not approved, processing proceeds to 313.]
Therefore, it would have been obvious to one of ordinary skills within the art before the effective filling date to combine Zhang’s system with Self’s system, with a motivation for the exchange of cryptographic keys between cloud instances can be automated using a key exchange framework. In various embodiments, a target cloud instance can request an encryption key from a source cloud instance. Based on key exchange configurations, the request can be automated to allow the source cloud instance to securely provide the target cloud instance with the requested encryption key. [Zhang, para. 12]
However, Self in view of Zhang does not teach wherein determining that the at least one cryptographic key complies with the one or more requirements specified in the one or more key rules comprises at least one of: determining that a derivative of the at least one cryptographic key comprises at least one specified pattern, but Ammar does teach wherein determining that the at least one cryptographic key complies with the one or more requirements specified in the one or more key rules comprises at least one of: determining that a derivative of the at least one cryptographic key comprises at least one specified pattern, [Ammar, para. 7 discloses obtaining a set of private key shares and a set of corresponding public key shares, wherein each private key share is generated based on the personal identifier, and wherein at least one of the set of private key shares is generated by a respective one of a set of key-generating parties; generating an identity-based private key based on each of the one or more private key shares;]
Therefore, it would have been obvious to one of ordinary skills within the art before the effective filling date to combine Ammar’s system with modified Self’s system, with a motivation for the exchange of cryptographic keys between cloud instances can be automated using a key exchange framework. In various embodiments, a target cloud instance can request an encryption key from a source cloud instance. Based on key exchange configurations, the request can be automated to allow the source cloud instance to securely provide the target cloud instance with the requested encryption key. [Zhang, para. 12]
Regarding claim 2, modified Self teaches the method of claim 1, wherein determining that the at least one cryptographic key complies with the one or more requirements specified in the one or more key rules comprises determining that the derivative of the at least one cryptographic key comprises the at least one specified pattern, [Self, col. 16 lines 47 – 59 discloses the key generator 206 can use values of one or more attributes to generate a cryptographic key. The number and type or attributes used to generate the cryptographic key can be based on a key generation policy. For example, The key generation policy can specify the particular attributes to be used to generate the cryptographic key. For example, the key generation policy can specify using a combination of the values of three file system attributes 304. In another example, the key generation policy can specify using values of one attribute selected from each of the file system attributes 304, the network attributes 306, and the hardware attributes 308.], but Self does not teach wherein the derivative of the at least one cryptographic key comprises a hash of the at least one cryptographic key.
However, Ammar does teach wherein the derivative of the at least one cryptographic key comprises a hash of the at least one cryptographic key. [Ammar, para. 92 – 97 discloses A trapdoor one-way function can be used to construct a digital signature scheme. In a digital signature setting, each player will have their own secret private key to be used for signing, and a corresponding public key that is used for verification. A digital signature scheme comprises: Key Generation; Alice generates a private key, sk.sub.Alice, from a random pool. Alice derives her public key, PK.sub.Alice, from the private key and publishes it to all parties. Signing Alice signs a message, m, using her private key, sk.sub.Alice, to obtain the signature s,]
Therefore, it would have been obvious to one of ordinary skills within the art before the effective filling date to combine Ammar’s system with modified Self’s system, with a motivation for the exchange of cryptographic keys between cloud instances can be automated using a key exchange framework. In various embodiments, a target cloud instance can request an encryption key from a source cloud instance. Based on key exchange configurations, the request can be automated to allow the source cloud instance to securely provide the target cloud instance with the requested encryption key. [Zhang, para. 12]
As per claim 3, modified Self teaches the method of claim 2, wherein determining that the derivative of the at least one cryptographic key comprises the at least one specified pattern comprises generating the hash of the at least one cryptographic key. [Self, col. 17 lines 4 – 11 discloses a transformation function can include a hash function, which maps data of arbitrary size to data of fixed size. Values of the attributes specified by the key generation policy can have variable lengths, while most cryptographic encryption and decryption algorithms rely on fixed length keys. Therefore, a transformation function, such as a hash function can be useful in transforming the variable length attribute values into a fixed length cryptographic key.]
Regarding claim 4, modified Self teaches the method of claim 1, wherein determining that the at least one cryptographic key complies with the one or more requirements specified in the one or more key rules comprises determining that the derivative of the at least one cryptographic key comprises at the least one specified pattern [Self, col. 16 lines 47 – 59 discloses the key generator 206 can use values of one or more attributes to generate a cryptographic key. The number and type or attributes used to generate the cryptographic key can be based on a key generation policy. For example, The key generation policy can specify the particular attributes to be used to generate the cryptographic key. For example, the key generation policy can specify using a combination of the values of three file system attributes 304. In another example, the key generation policy can specify using values of one attribute selected from each of the file system attributes 304, the network attributes 306, and the hardware attributes 308.], but Self does not teach wherein determining that the derivative of the at least one cryptographic key comprises the at least one specified pattern comprises determining that the derivative of the at least one cryptographic key comprises the at least one specified pattern in a specified location within the derivative of the at least one cryptographic key.
However, Zhang does teach wherein determining that the derivative of the at least one cryptographic key comprises the at least one specified pattern comprises determining that the derivative of the at least one cryptographic key comprises the at least one specified pattern in a specified location within the derivative of the at least one cryptographic key. [Zhang, para. 25 discloses Target cloud instances can utilize the key exchange specification to provide a key exchange request based on the specification. The source instance is configured with key exchange parameters including access policies that determine whether to approve or reject incoming key exchange requests. In some embodiments, the process is implemented at least in part by a key management framework running on the source and target cloud instances.]
Therefore, it would have been obvious to one of ordinary skills within the art before the effective filling date to combine Zhang’s system with Self’s system, with a motivation for the exchange of cryptographic keys between cloud instances can be automated using a key exchange framework. In various embodiments, a target cloud instance can request an encryption key from a source cloud instance. Based on key exchange configurations, the request can be automated to allow the source cloud instance to securely provide the target cloud instance with the requested encryption key. [Zhang, para. 12]
Regarding claim 5, modified Self teaches the method of claim 1, but Self does not teach wherein determining that the at least one cryptographic key complies with the one or more requirements specified in the one or more key rules comprises determining that the at least one cryptographic key has a specified relationship with the binding data associated with the at least one cryptographic key, and wherein the method further comprises receiving the binding data.
However, Zhang does teach wherein determining that the at least one cryptographic key complies with the one or more requirements specified in the one or more key rules comprises determining that the at least one cryptographic key has a specified relationship with the binding data associated with the at least one cryptographic key, and wherein the method further comprises receiving the binding data. [Zhang, para. 23 discloses certain requests can be configured as one-time requests and key exchange tracker 211 can be utilized to track/query how many requests of a particular specification have been received. In various embodiments, key exchange tracker 211 tracks both pending, approved, and rejected requests. Additional data such as the requesting cloud instance, requested key type, requested key encryption, and other key exchange data can be tracked by key exchange tracker 211. In some embodiments, key export approver and access service 213 is utilized to approve or reject received key exchange requests based on configured key exchange settings including key exchange access policies. Key export approver and access service 213 can also track approvals and rejections based on key exchange settings including why certain requests were rejected.]
Therefore, it would have been obvious to one of ordinary skills within the art before the effective filling date to combine Zhang’s system with Self’s system, with a motivation for the exchange of cryptographic keys between cloud instances can be automated using a key exchange framework. In various embodiments, a target cloud instance can request an encryption key from a source cloud instance. Based on key exchange configurations, the request can be automated to allow the source cloud instance to securely provide the target cloud instance with the requested encryption key. [Zhang, para. 12]
Regarding claim 6, modified Self teaches the method of claim 5, but Self does not teach wherein the binding data is received with the at least one cryptographic key.
However, Zhang does teach wherein the binding data is received with the at least one cryptographic key. [Zhang, para. 23 discloses certain requests can be configured as one-time requests and key exchange tracker 211 can be utilized to track/query how many requests of a particular specification have been received. In various embodiments, key exchange tracker 211 tracks both pending, approved, and rejected requests. Additional data such as the requesting cloud instance, requested key type, requested key encryption, and other key exchange data can be tracked by key exchange tracker 211. In some embodiments, key export approver and access service 213 is utilized to approve or reject received key exchange requests based on configured key exchange settings including key exchange access policies. Key export approver and access service 213 can also track approvals and rejections based on key exchange settings including why certain requests were rejected.]
Therefore, it would have been obvious to one of ordinary skills within the art before the effective filling date to combine Zhang’s system with Self’s system, with a motivation for the exchange of cryptographic keys between cloud instances can be automated using a key exchange framework. In various embodiments, a target cloud instance can request an encryption key from a source cloud instance. Based on key exchange configurations, the request can be automated to allow the source cloud instance to securely provide the target cloud instance with the requested encryption key. [Zhang, para. 12]
Regarding claim 7, modified Self teaches the method of claim 5, but Self does not teach wherein the binding data comprises identification information.
However, Zhang does teach wherein the binding data comprises identification information. [Zhang, para. 23 discloses key exchange data 217 is implemented as one or more tables such as database tables hosted by cloud instance 201. Key exchange data 217 can be utilized by one or more components of key management framework 203 such as key exchange tracker 211 and/or key export approver and access service 213 for storing key exchange requests, key specifications, access policies, and/or other key exchange data such as key exchange configuration settings.]
Therefore, it would have been obvious to one of ordinary skills within the art before the effective filling date to combine Zhang’s system with Self’s system, with a motivation for the exchange of cryptographic keys between cloud instances can be automated using a key exchange framework. In various embodiments, a target cloud instance can request an encryption key from a source cloud instance. Based on key exchange configurations, the request can be automated to allow the source cloud instance to securely provide the target cloud instance with the requested encryption key. [Zhang, para. 12]
Regarding claim 8, modified Self teaches the method of claim 7, but Self does not teach wherein the identification information comprises an e-mail address.
However, Zhang does teach wherein the identification information comprises an e-mail address. [Zhang, para. 26 discloses a key exchange specification is created. For example, a source cloud instance is analyzed to identify installed security keys and one or more key exchange specifications are created for each of the identified keys. The specification can include the encryption key type, encryption key cipher, and identifying information of the source cloud instance such as the source hostname and/or system identifier. In various embodiments, a key exchange specification includes a secret token, random number, timestamp, or another appropriate security implementation used at least in part to identify the authenticity of the key exchange specification.]
Therefore, it would have been obvious to one of ordinary skills within the art before the effective filling date to combine Zhang’s system with Self’s system, with a motivation for the exchange of cryptographic keys between cloud instances can be automated using a key exchange framework. In various embodiments, a target cloud instance can request an encryption key from a source cloud instance. Based on key exchange configurations, the request can be automated to allow the source cloud instance to securely provide the target cloud instance with the requested encryption key. [Zhang, para. 12]
Regarding claim 9, modified Self teaches the method of claim 5, but Self does not teach wherein the specified relationship comprises the at least one cryptographic key and the binding data both comprising at least one specified pattern.
However, Zhang does teach wherein the specified relationship comprises the at least one cryptographic key and the binding data both comprising at least one specified pattern. [Zhang, para. 25 discloses Target cloud instances can utilize the key exchange specification to provide a key exchange request based on the specification. The source instance is configured with key exchange parameters including access policies that determine whether to approve or reject incoming key exchange requests. In some embodiments, the process is implemented at least in part by a key management framework running on the source and target cloud instances.]
Therefore, it would have been obvious to one of ordinary skills within the art before the effective filling date to combine Zhang’s system with Self’s system, with a motivation for the exchange of cryptographic keys between cloud instances can be automated using a key exchange framework. In various embodiments, a target cloud instance can request an encryption key from a source cloud instance. Based on key exchange configurations, the request can be automated to allow the source cloud instance to securely provide the target cloud instance with the requested encryption key. [Zhang, para. 12]
Regarding claim 10, modified Self teaches the method of claim 9, but Self does not teach wherein the specified relationship comprises the at least one cryptographic key and the binding data both comprising the at least one specified pattern in a specified location.
However, Zhang does teach wherein the specified relationship comprises the at least one cryptographic key and the binding data both comprising the at least one specified pattern in a specified location. [Zhang, para. 23 discloses both key exchange tracker 211 and key export approver and access service 213 access key exchange data 217. In some embodiments, key exchange data 217 is implemented as one or more tables such as database tables hosted by cloud instance 201. Key exchange data 217 can be utilized by one or more components of key management framework 203 such as key exchange tracker 211 and/or key export approver and access service 213 for storing key exchange requests, key specifications, access policies, and/or other key exchange data such as key exchange configuration settings. Para. 25 discloses Target cloud instances can utilize the key exchange specification to provide a key exchange request based on the specification. The source instance is configured with key exchange parameters including access policies that determine whether to approve or reject incoming key exchange requests. In some embodiments, the process is implemented at least in part by a key management framework running on the source and target cloud instances.]
Therefore, it would have been obvious to one of ordinary skills within the art before the effective filling date to combine Zhang’s system with Self’s system, with a motivation for the exchange of cryptographic keys between cloud instances can be automated using a key exchange framework. In various embodiments, a target cloud instance can request an encryption key from a source cloud instance. Based on key exchange configurations, the request can be automated to allow the source cloud instance to securely provide the target cloud instance with the requested encryption key. [Zhang, para. 12]
Regarding claim 11, modified Self teaches the method of claim 1, but Self does not teach wherein determining that the at least one cryptographic key complies with the one or more requirements specified in the one or more key rules comprises determining that the at least one cryptographic key has a specified relationship with the binding data associated with the at least one cryptographic key, and wherein determining that the at least one cryptographic key has the specified relationship with the binding data associated with the at least one cryptographic key comprises generating a derivative of the at least one cryptographic key.
However, Zhang does teach wherein determining that the at least one cryptographic key complies with the one or more requirements specified in the one or more key rules comprises determining that the at least one cryptographic key has a specified relationship with the binding data associated with the at least one cryptographic key, [Zhang, para. 25 discloses Target cloud instances can utilize the key exchange specification to provide a key exchange request based on the specification. The source instance is configured with key exchange parameters including access policies that determine whether to approve or reject incoming key exchange requests. In some embodiments, the process is implemented at least in part by a key management framework running on the source and target cloud instances.] and wherein determining that the at least one cryptographic key has the specified relationship with the binding data associated with the at least one cryptographic key comprises generating a derivative of the at least one cryptographic key. [Zhang, para. 14 discloses the target instance proceeds by generating a new encryption key and rekeying. For example, new data accessed by the target instance and/or existing encrypted data stored at the target instance can be encrypted using the newly generated encryption key. Similarly, in some embodiments, the source instance can perform rekeying after a key exchange. For example, the source instance can generate a new encryption key for improved security. New data accessed by the source instance and/or existing encrypted data stored at the first instance can be encrypted using the newly generated encryption key.]
Therefore, it would have been obvious to one of ordinary skills within the art before the effective filling date to combine Zhang’s system with Self’s system, with a motivation for the exchange of cryptographic keys between cloud instances can be automated using a key exchange framework. In various embodiments, a target cloud instance can request an encryption key from a source cloud instance. Based on key exchange configurations, the request can be automated to allow the source cloud instance to securely provide the target cloud instance with the requested encryption key. [Zhang, para. 12]
Regarding claim 12, modified Self teaches the method of claim 11, but Self does not teach wherein determining that the at least one cryptographic key has the specified relationship with the binding data associated with the at least one cryptographic key comprises generating a derivative of the binding data.
However, Zhang does teach wherein determining that the at least one cryptographic key has the specified relationship with the binding data associated with the at least one cryptographic key comprises generating a derivative of the binding data. [Zhang, para. 26 discloses a source cloud instance is analyzed to identify installed security keys and one or more key exchange specifications are created for each of the identified keys. The specification can include the encryption key type, encryption key cipher, and identifying information of the source cloud instance such as the source hostname and/or system identifier. In various embodiments, a key exchange specification includes a secret token, random number, timestamp, or another appropriate security implementation used at least in part to identify the authenticity of the key exchange specification.]
Therefore, it would have been obvious to one of ordinary skills within the art before the effective filling date to combine Zhang’s system with Self’s system, with a motivation for the exchange of cryptographic keys between cloud instances can be automated using a key exchange framework. In various embodiments, a target cloud instance can request an encryption key from a source cloud instance. Based on key exchange configurations, the request can be automated to allow the source cloud instance to securely provide the target cloud instance with the requested encryption key. [Zhang, para. 12]
Regarding claim 13, modified Self teaches the method of claim 12, but Self does not teach wherein the derivative of the at least one cryptographic key comprises a hash of the at least one cryptographic key and the derivative of the binding data comprises a hash of the binding data.
However, Zhang does teach wherein the derivative of the at least one cryptographic key comprises a hash of the at least one cryptographic key and the derivative of the binding data comprises a hash of the binding data. [Zhang, para. 29 discloses the request is analyzed to determine whether the request is a valid request and whether the request should be approved or rejected. In some embodiments, a shared token or other security implement is verified. In some embodiments, the received request is received as part of a signed request message and the request signature is verified. Once reviewed, the request is allowed or rejected. In various embodiments, the request is tracked along with the determination of whether the request was allowed or rejected.]
Therefore, it would have been obvious to one of ordinary skills within the art before the effective filling date to combine Zhang’s system with Self’s system, with a motivation for the exchange of cryptographic keys between cloud instances can be automated using a key exchange framework. In various embodiments, a target cloud instance can request an encryption key from a source cloud instance. Based on key exchange configurations, the request can be automated to allow the source cloud instance to securely provide the target cloud instance with the requested encryption key. [Zhang, para. 12]
Regarding claim 14, modified Self teaches the method of claim 12, but Self does not teach wherein the specified relationship comprises the derivative of the at least one cryptographic key and the derivative of the binding data both comprising at least one specified pattern.
However, Ammar does teach wherein the specified relationship comprises the derivative of the at least one cryptographic key and the derivative of the binding data both comprising at least one specified pattern. [Ammar, para. 228 discloses Alice may generate the partial identity-based public key using the key generation described above, i.e. Algorithm 2B. The partial identity-based public key (X.sub.A, Y.sub.A) is generated based on (i.e. is a function of) a set of public key shares P.sub.i that correspond to the set of private key shares D.sub.iA. Here, each public key share P.sub.i corresponds to a respective private key share D.sub.iA in the sense that the public key share P.sub.i is generated based on the respective private key share D.sub.iA, i.e. a public key share P.sub.i is a function of a private key share D.sub.iA. para. 230 discloses Once the identity-based public key PK.sub.A has been generated, Alice 103a and/or PKG 501 generates a blockchain transaction that includes an output comprising the identity-based public key PK.sub.A. The output may be a spendable output, e.g. a pay-to-public-key-hash (P2PKH) output, or it may be an unspendable output, e.g. an OP_RETURN output. Preferably PKG 501 generates the blockchain transaction so that other parties can rely on PKG's identity verification check when using Alice's identity-based public key PK.sub.A.]
Therefore, it would have been obvious to one of ordinary skills within the art before the effective filling date to combine Ammar’s system with modified Self’s system, with a motivation for the exchange of cryptographic keys between cloud instances can be automated using a key exchange framework. In various embodiments, a target cloud instance can request an encryption key from a source cloud instance. Based on key exchange configurations, the request can be automated to allow the source cloud instance to securely provide the target cloud instance with the requested encryption key. [Zhang, para. 12]
Regarding claim 15, modified Self teaches the method of claim 14, but Self does not teach wherein the specified relationship comprises the derivative of the at least one cryptographic key and the derivative of the binding data both comprising the at least one specified pattern in a specified location.
However, Ammar does teach wherein the specified relationship comprises the derivative of the at least one cryptographic key and the derivative of the binding data both comprising the at least one specified pattern in a specified location. [Ammar, para. 228 discloses Alice may generate the partial identity-based public key using the key generation described above, i.e. Algorithm 2B. The partial identity-based public key (X.sub.A, Y.sub.A) is generated based on (i.e. is a function of) a set of public key shares P.sub.i that correspond to the set of private key shares D.sub.iA. Here, each public key share P.sub.i corresponds to a respective private key share D.sub.iA in the sense that the public key share P.sub.i is generated based on the respective private key share D.sub.iA, i.e. a public key share P.sub.i is a function of a private key share D.sub.iA. para. 230 discloses Once the identity-based public key PK.sub.A has been generated, Alice 103a and/or PKG 501 generates a blockchain transaction that includes an output comprising the identity-based public key PK.sub.A. The output may be a spendable output, e.g. a pay-to-public-key-hash (P2PKH) output, or it may be an unspendable output, e.g. an OP_RETURN output. Preferably PKG 501 generates the blockchain transaction so that other parties can rely on PKG's identity verification check when using Alice's identity-based public key PK.sub.A.]
Therefore, it would have been obvious to one of ordinary skills within the art before the effective filling date to combine Ammar’s system with modified Self’s system, with a motivation for the exchange of cryptographic keys between cloud instances can be automated using a key exchange framework. In various embodiments, a target cloud instance can request an encryption key from a source cloud instance. Based on key exchange configurations, the request can be automated to allow the source cloud instance to securely provide the target cloud instance with the requested encryption key. [Zhang, para. 12]
Regarding claim 16, Self teaches a method for validating at least one cryptographic key performed by a system comprising a processor and non-transitory computer-readable medium storing instructions that, when executed by the processor, cause the system to perform the method, the method comprising: receiving a request to perform an operation using at least one cryptographic key; [Self, col. 17 lines 46 – 56 discloses The process 400 includes receiving a request for a cryptographic key (stage 402). As discussed above, the key generator 206 can receive requests to provide a cryptographic key from the targeted encryption module 202 and the targeted decryption module 204. The process 400 further includes acquiring values of one or more system attributes based on a key generation policy (stage 404). As discussed above in relation to FIGS. 2 and 3, the key generator 206 can acquire values of various system attributes of the computing system 200. The attributes can include, for example, file system attributes 304, network attributes 306, and hardware attributes 308.], but Self does not teach comparing the at least one cryptographic key with one or more key rules to determine that the at least one cryptographic key complies with one or more requirements specified in the one or more key rules, wherein determining that the at least one cryptographic key complies with the one or more requirements specified in the one or more key rules comprises determining that the at least one cryptographic key comprises at least one specified pattern; validating the at least one cryptographic key based on the determining that the at least one cryptographic key complies with the one or more requirements specified in the one or more key rules; and performing the operation using the at least one cryptographic key based on validating the at least one cryptographic key.
However, Zhang does teach comparing the at least one cryptographic key with one or more key rules to determine that the at least one cryptographic key complies with one or more requirements specified in the one or more key rules, [Zhang, para. 30 discloses the request is decoded to determine parameters of the request such as parameters of the target instance requesting the key and parameters of the requested key. Additional decoded parameters can include parameters associated with the source instance, for example, to confirm the key exchange request is valid. Once the key request parameters are confirmed, the access policy associated with the request is evaluated. Based on configured access policies, the request may be approved or rejected. For example, access policies can include an exchange frequency parameter to determine how many requests of a particular type should be allowed. In some embodiments, the request may be associated with a one-time approval and subsequent requests of the same type are rejected.] validating the at least one cryptographic key based on the determining that the at least one cryptographic key complies with the one or more requirements specified in the one or more key rules; [Zhang, para. 30 discloses the request is decoded to determine parameters of the request such as parameters of the target instance requesting the key and parameters of the requested key. Additional decoded parameters can include parameters associated with the source instance, for example, to confirm the key exchange request is valid. Once the key request parameters are confirmed, the access policy associated with the request is evaluated. Based on configured access policies, the request may be approved or rejected. For example, access policies can include an exchange frequency parameter to determine how many requests of a particular type should be allowed. In some embodiments, the request may be associated with a one-time approval and subsequent requests of the same type are rejected. The request may also be associated with a time limit or condition that a request must meet to be approved, such as a maximum number of allowed requests and/or allowing all reoccurring requests of a particular type to be approved. In some embodiments, access control lists are used to determine whether the requester is allowed access to the requested key.] and performing the operation using the at least one cryptographic key based on validating the at least one cryptographic key. [Zhang, para. 31 discloses a determination is made whether the key exchange request is approved. In the event the key exchange request is approved, processing proceeds to 311. In the event the key exchange request is not approved, processing proceeds to 313.]
Therefore, it would have been obvious to one of ordinary skills within the art before the effective filling date to combine Zhang’s system with Self’s system, with a motivation for the exchange of cryptographic keys between cloud instances can be automated using a key exchange framework. In various embodiments, a target cloud instance can request an encryption key from a source cloud instance. Based on key exchange configurations, the request can be automated to allow the source cloud instance to securely provide the target cloud instance with the requested encryption key. [Zhang, para. 12]
However, Self in view of Zhang does not teach wherein determining that the at least one cryptographic key complies with the one or more requirements specified in the one or more key rules comprises determining that the at least one cryptographic key comprises at least one specified pattern;, but Ammar does teach wherein determining that the at least one cryptographic key complies with the one or more requirements specified in the one or more key rules comprises determining that the at least one cryptographic key comprises at least one specified pattern; [Ammar, para. 7 discloses obtaining a set of private key shares and a set of corresponding public key shares, wherein each private key share is generated based on the personal identifier, and wherein at least one of the set of private key shares is generated by a respective one of a set of key-generating parties; generating an identity-based private key based on each of the one or more private key shares;]
Therefore, it would have been obvious to one of ordinary skills within the art before the effective filling date to combine Ammar’s system with modified Self’s system, with a motivation for the exchange of cryptographic keys between cloud instances can be automated using a key exchange framework. In various embodiments, a target cloud instance can request an encryption key from a source cloud instance. Based on key exchange configurations, the request can be automated to allow the source cloud instance to securely provide the target cloud instance with the requested encryption key. [Zhang, para. 12]
Regarding claim 17, modified Self teaches the method of claim 16, but Self does not teach wherein determining that the at least one cryptographic key comprises at least one specified pattern comprises determining that the at least one cryptographic key comprises at least one specified pattern in a specified location.
However, Ammar does teach wherein determining that the at least one cryptographic key comprises at least one specified pattern comprises determining that the at least one cryptographic key comprises at least one specified pattern in a specified location. [Ammar, para. 228 discloses Alice may generate the partial identity-based public key using the key generation described above, i.e. Algorithm 2B. The partial identity-based public key (X.sub.A, Y.sub.A) is generated based on (i.e. is a function of) a set of public key shares P.sub.i that correspond to the set of private key shares D.sub.iA. Here, each public key share P.sub.i corresponds to a respective private key share D.sub.iA in the sense that the public key share P.sub.i is generated based on the respective private key share D.sub.iA, i.e. a public key share P.sub.i is a function of a private key share D.sub.iA. para. 230 discloses Once the identity-based public key PK.sub.A has been generated, Alice 103a and/or PKG 501 generates a blockchain transaction that includes an output comprising the identity-based public key PK.sub.A. The output may be a spendable output, e.g. a pay-to-public-key-hash (P2PKH) output, or it may be an unspendable output, e.g. an OP_RETURN output. Preferably PKG 501 generates the blockchain transaction so that other parties can rely on PKG's identity verification check when using Alice's identity-based public key PK.sub.A.]
Therefore, it would have been obvious to one of ordinary skills within the art before the effective filling date to combine Ammar’s system with modified Self’s system, with a motivation for the exchange of cryptographic keys between cloud instances can be automated using a key exchange framework. In various embodiments, a target cloud instance can request an encryption key from a source cloud instance. Based on key exchange configurations, the request can be automated to allow the source cloud instance to securely provide the target cloud instance with the requested encryption key. [Zhang, para. 12]
Conclusion
Pertinent prior art made of record, however, not relied upon:
US 20210243173 A1 to D'Alessandro et al.
“In method of protecting signaling messages in a hop-by-hop network communication link between a source node and a destination node, a source node public digital signature verification key and a respective source node private digital signature key associated with said public digital signature verification key are provided to the source node. The source node public digital signature verification key associated with the source node private digital signature key is also provided to the destination node. The source node builds a message including a sequence of Information Elements, and calculates, for each Information Element, an Information Element hash value. The source node also calculates a sequence hash value of a concatenation of the calculated Information Element hash values, and generates a source node digital signature by digitally signing the calculated sequence hash value. An intermediate node receives and forwards the signaling message to the destination node.”
Any inquiry concerning this communication or earlier communications from the examiner should be directed to Phuc Pham whose telephone number is (571)272-8893. The examiner can normally be reached Monday - Thursday 7:30 AM - 4:30 PM; Friday 8:00 AM - 12:00 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, Linglan Edwards can be reached at (571) 270-5440. 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.
/P.P./Patent Examiner, Art Unit 2408
/LINGLAN EDWARDS/Supervisory Patent Examiner, Art Unit 2408
Prosecution Insights