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 .
On response filed on 11/3/2025, claims 1, 11 were/was amended; no claims were added; claims 7 and 17 were cancelled. As a result, claims 1-6, 8-16, 18-20 are pending, of which claims 1, 11 are in independent form.
Amendment to claims 1 and 11 obviates previous rejection to claims 1 and 11 under 35 USC section 101.
Status of Claims
Claims 1-20 are pending, of which claims 1, and 11 are in independent form.
Specification
The examiner notes that the Specification does not include any URL links and Trademark terms requiring capitalization.
The examiner notes that the abstract is in narrative form and is limited to a single paragraph on a separate sheet within the range of 50 to 150 words in length and that the abstract of the disclosure does not include any legal phraseology.
Allowable Subject Matter
Claims 8-10 and 18-20 are objected to as being dependent upon a rejected base claim, but would be allowable if rewritten in independent form including all of the limitations of the base claim and any intervening claims.
The following is a statement of reasons for the indication of allowable subject matter: The prior arts of record or further search does not teach “wherein the discretionary factor comprises expected energy consumption associated with performance of the cryptographic task, and the discretionary factor indicates first and second time periods when the energy is relatively less, and more, expensive” in claims 8 and 18, “wherein the discretionary factor enables a user to select a time, or a window of time, when the cryptographic task will be performed” in claims 9 and 19, “wherein the cryptographic task is performed at a time when energy needed to perform the cryptographic task is less expensive” in claims 10 and 20, in view of all other limitations of claims 8-10, and 18-20, respectively.
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.
Claim(s) 1-2, 4-6, 11-12, 14-16 is/are rejected under 35 U.S.C. 103 as being unpatentable over Huntley et al. (US 2025/0030559 A1) hereinafter Huntley, in view of Kalle et al. (WO2024015087 A1) hereinafter Kalle.
As to claim 1, Huntley teaches a method, comprising:
receiving a request for performance of a cryptographic task (see para. [0061] “ Application 110 sends requests for cryptographic functionality to crypto provider 120, such as via a software development kit (SDK) 202, which may include methods exposed by an API of crypto provider 120. Cryptographic requests from application 110 (and/or one or more additional applications) are received by crypto router 210, which dynamically selects crypto implementation components 220 for handling the cryptographic requests.”);
associating a cryptographic standard and a user policy with the cryptographic task (see para. [0064] “Crypto router 210 determines whether there are any policies applicable to the crypto request, such as based on whether any contextual information related to the request (e.g., relating to the requesting device, application, and/or user, one or more attributes of an aggregator device, the type of data being encrypted, mathematical operations that are to be performed on the encrypted data, and/or the like) corresponds to a policy. If any policies apply, crypto router 210 will ensure that any cryptographic techniques selected comply with the applicable policies.”);
associating a discretionary factor with the cryptographic task (see para. [0024] “identity the cryptography algorithm from the plurality of cryptography algorithms based on at least one of the following parameters: network security level, network criticality, or energy efficiency), wherein the receiving the request, the associating the cryptographic standard and the user policy, the associating the discretionary factor, and the selecting, are all performed and provided as-a-service to a customer from which the request was received (see Fig. 2 for cryptography as a service provided by the crypto provider 120; see para. [0060] and abstract “…an approach for providing cryptography as a service. Embodiments include receiving, by a cryptographic provider component, policy information. Embodiments include receiving, by the cryptographic provider component, requests from a plurality of applications to perform cryptographic operations, wherein the plurality of applications comprise separate processes from the cryptographic provider component. Embodiments include selecting, by a cryptographic router of the cryptographic provider component, based on the policy information and information associated with the requests, one or more cryptographic implementation components for servicing each request of the requests.”).
Huntley does not explicitly teach but Kalle teaches “selecting, based on the cryptographic standard, the user policy, and the discretionary
factor, a cryptographic mechanism to perform the cryptographic task (see para. [0064] “a seamless selection of the cryptographic algorithm based on context-based parameters and standardized levels for energy efficient operations in wireless communication networks.”; see also para. [0077] “[0077] FIG. 5 illustrates flow chart for one exemplary embodiment of a method for determining a cryptography configuration for the context-based cryptography selection method and system for energy efficient operations, such as the logic embedded within xApp in determining the cryptography configuration. Here, at step 502, the method can include initializing the system parameters and collecting the O-Cloud module 200’ s telemetry information via the 01 and 02 interfaces. Next, at step 504, the method can include receiving the external system context via an application interface (API) or operator inputs which can include network criticality level and applicable security level. Here, the external system context can refer to information that may be unrelated to the network operations or security levels itself. One example of this can be a change in an energy source for a network operation, wherein such change can result from an event, such as a power grid failure, among others. Upon such an event, there can be a change to alternative or temporary energy source, such as a change to sustainable/renewable sources of energy wherein the network system reduces power consumption. Under such a scenario of reduced network power consumption, despite the predetermined rules of selection of a Crypto policy, the lowest energy crypto algorithm is selected in order to comply with the reduced power consumption requirements for the network. Next, at step 506, the method can include determining the Optimal Energy Efficient Cryptography configuration via a table look up / supervised learning or decision tree approach. Next, at step 508, the method can include the O-Cloud module 200 selecting the final cryptography parameters from the cryptography family guidance received from the rApp module 120 and SMO module or framework 100. Next, at step 510, the method can include providing the final policy guidance by the rApp Security application or rApp module 120 to the O-Cloud layer module 200. Further, at step 512, the final cryptography policy can be applied on to the O-Cloud layer module 200. Here, the foregoing process of FIG. 5 can be achieved at a K8S Orchestration Layer, in particular for the Data Encryption at Rest on the cloud platform”).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention, having the teachings of Huntley and Kalle before him or her, to modify the scheme of Huntley by including Kalle. The suggestion/motivation for doing so would have been to select the most desirable and optimal cryptography implementation/mechanism at a cryptography provider based on energy efficiency and policy requirement policy compliance and security criticality of the data being considered, as briefly discussed in Kalle, para. [0014].
As to claim 11, claim 11 includes similar limitations as claim 1 and thus claim 11 is/are rejected under the same rationale as in claim 11.
As to claims 2 and 12, in view of claims 1 and 11, respectively, Huntley teaches wherein the cryptographic task comprises encryption of a group of data (see para. [0037] “For instance, application 110 may make cryptographic function calls (e.g., requesting that an item of data be encrypted), and these function calls may be intercepted by agility shim 114 (e.g., if such a shim is needed) and redirected to crypto provider 120 via the abstracted crypto API 212 exposed by crypto provider 120.”).
As to claims 4 and 14, in view of claims 1 and 11, respectively, Huntley teaches wherein the cryptographic task mechanism comprises a mechanism for encrypting data identified in the cryptographic task (see para. [0037] “For instance, application 110 may make cryptographic function calls (e.g., requesting that an item of data be encrypted), and these function calls may be intercepted by agility shim 114 (e.g., if such a shim is needed) and redirected to crypto provider 120 via the abstracted crypto API 212 exposed by crypto provider 120.”)
As to claims 5 and 15, in view of claims 1 and 11, respectively, Kalle teaches wherein the discretionary factor comprises any one or more of: expected energy consumption associated with performance of the cryptographic task; and expected availability of one or more computing resources for performance of the cryptographic task (see para. [0012], e.g. energy consumption).
As to claims 6 and 16, in view of claims 1 and 11, respectively, Huntley teaches using the cryptographic mechanism to perform the cryptographic task (see para. [0067] “…may then determine which of those policy-compliant techniques are consistent with the resource constraints related to the crypto request. Finally, crypto router 210 may select a cryptographic technique from a subset of available cryptographic techniques that includes those techniques that are both policy-compliant and resource-compliant. For example, crypto router 210 may select the most secure cryptographic technique and/or the most resource-efficient cryptographic technique in the set of policy-compliant and resource-compliant techniques.”; see para. [0068] “The crypto implementation component 220 then performs the selected cryptographic technique in order to encrypt the data, and then returns the encrypted data to crypto router 210. Crypto router 210 then returns the encrypted data to application 110 in response to the cryptographic request and/or provides the encrypted data to one or more separate endpoints (e.g., indicated in the cryptographic request).”).
Claim(s) 3 and 13 is/are rejected under 35 U.S.C. 103 as being unpatentable over Huntley, in view of Kalle, and further in view of Roth et al. (US 2014/0229732 A1) hereinafter Roth.
As to claims 3 and 13, in view of claims 1, and 11, respectively, the combination of Huntley and Kalle does not explicitly teach but Roth teaches wherein the cryptographic task comprises a rekeying operation (see para. [0090] “For example, in some embodiments, key rotation is performed. Key rotation may involve replacing keys with other keys to prevent collection of enough decrypted data to allow practical cracking of a cipher used. If performed at the direction of an entity different from the cryptography service, use of the CreateKey(KeyID) request may cause the cryptography service to create a new key to replace an old key identified by the KeyID. The old key may remain identified by the KeyID, but may, for instance, be only used for decryption (of data that has already been encrypted using the old key) and not for future encryption. As another example, in some embodiments, users of the cryptography service provide their own key identifiers and there is a possibility that two different customers may provide the same identifier. In such instances, the identifier may not uniquely identify a key or even uniquely identify a family of keys. Various measures may be in place to address this. For example, an identity or other information associated with a user of the cryptography service may be used to identify the proper key or family of keys. In still other embodiments the cryptographic service may assign a KeyID randomly, sequentially, or using any other method.”; see also para. [0094] “The ReKey (Ciphertext, OldKeyID, NewKeyID) request, in an embodiment, may be used to cause the cryptography service to encrypt ciphertext under a different key. When the cryptography service cryptography service receives a ReKey (Ciphertext, OldKeyID, NewKeyID) request, it may use a key identified by the OldKeyID to decrypt the specified ciphertext and then use a key identified by the NewKeyID to encrypt the decrypted ciphertext. If a key identified by the NewKeyID does not yet exist, the cryptography service may generate a key to use and associate the generated key with the specified NewKeyID, such as described in connection the Create(KeyID) request described above. In some embodiments, the ReKey operation may be operable to cause data to be transferable between isolated instances of a cryptography service. In some embodiments, a policy might permit a ReKey operation to be performed on a ciphertext but might not permit the same requestor to directly decrypt the ciphertext. In some embodiments, ReKey might support ReKeying a ciphertext from a key identified by a first KeyID within a first account to a key identified by a KeyID within a second account.”).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention, having the teachings of Huntley, Kalle, and Roth before him or her, to modify the scheme of Huntley and Kalle by including Roth. The suggestion/motivation for doing so would have been to select the most desirable and optimal cryptography implementation/mechanism for re-keying operation request at a cryptography provider based on energy efficiency and policy requirement policy compliance and security criticality of the data being considered.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to HEE SONG whose telephone number is (571)270-3260. The examiner can normally be reached on Mon – Fri, 7:30 AM – 5:00 PM.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Eleni Shiferaw can be reached on (571)272-3867. The fax phone number for the organization where this application or proceeding is assigned is 571-273-7291.
Information regarding the status of an application may be obtained from the Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from either Private PAIR or Public PAIR. Status information for unpublished applications is available through Private PAIR only. For more information about the PAIR system, see http://pair-direct.uspto.gov. Should you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative or access to the automated information system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/HEE K SONG/Primary Examiner, Art Unit 2497