DETAILED ACTION
This Office action is in response to the amendment filed on March 6, 2026.
Claims 1-20 are pending.
Claims 1, 3-4, 8, 11-12, 15, and 17 are amended.
The objections to the specification are withdrawn in view of Applicant’s amendments to the specification.
The objection to Claim 3 is withdrawn in view of Applicant’s amendments to the claim.
The 35 USC § 112(b) rejections to Claims 8-14 are withdrawn in view of Applicant’s amendments to the claims.
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 .
Response to Amendment
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, 4, 5, 7, 8, 11, 12, 14, 15, 17, 18, and 20 are rejected under 35 U.S.C. 103 as being unpatentable over US 2017/0364345 (hereinafter “Fontoura”) in view of “AWS Nitro Enclaves: Create isolated environments to protect highly sensitive workloads” (hereinafter “Help Net Security”), US 2017/0195459 (hereinafter “Costa”), US 2007/0074201 (hereinafter “Lee”), and US 9,864,874 (hereinafter “Shanbhag”).
As per Claim 1, Fontoura discloses:
A computer-implemented method for updating software code in a multi-tenant system (paragraph [0288], “One method of coordinating updates in a multi-tenant cloud computing environment […] (emphasis added).”), comprising:
receiving an indication that an updated version of software code to be executed in [a virtual machine] is available for deployment (paragraph [0005], “Some embodiments coordinate updates in a multi-tenant cloud computing environment. An update coordinator receives a first update request from a first update requester specifying a first update to at least part of the cloud computing environment […] Each update request makes a request concerning an update, such as a request that an update be performed as soon as possible […] (emphasis added).”; paragraph [0002], “To deploy their applications in the cloud, tenants install their own operating system images on top of the cloud's virtual machines, then install their application software on top of the operating systems. In an IaaS model, each tenant is responsible both for updates to the operating systems and for updates to the application software the tenant runs (emphasis added).”) [Examiner’s Remarks: Note that Fontoura discloses an update coordinator receiving a request that an update be performed as soon as possible. Fontoura also discloses that application software is deployed on virtual machines. One of ordinary skill in the art would readily comprehend that the update request to perform an update as soon as possible is an indication that an updated version of software code to be executed in a virtual machine is available for deployment.];
tenant of the multi-tenant system (abstract, “Software updates within one or more regions of a multi-tenant cloud are coordinated […] An infrastructure update request may be presented to tenants for approval (emphasis added).”; paragraph [0001], “A cloud environment's computing and storage solutions provide the cloud's users with varied and flexible capabilities to store and process their data in third-party datacenters. The cloud's users are often called “guests” or “tenants”.”);
causing deployment of the updated version of the software code to one or more nodes of the multi-tenant system (paragraph [0294], “[…] coordinating 806 the update requests includes giving a first deployment engine 218 approval to perform [deploy] the first update 810 and giving a second and different deployment engine 218 approval to perform the second update 810 (emphasis added).”; paragraph [0288], “One method of coordinating updates in a multi-tenant cloud computing environment 100 includes (a) an update coordinator 508 receiving 802 a first update request 512 from a first update requester 510 specifying 804 a first update 810 to at least part of the cloud computing environment […] (emphasis added).”; paragraph [0242], ““[…] deployment engines 218 for deploying instances of software in multiple virtual machines [one or more nodes of the multi-tenant system] (emphasis added).”).
Fontoura discloses “receiving an indication that an updated version of software code to be executed in [a virtual machine] is available for deployment” and “tenant of the multi-tenant system” but does not explicitly disclose:
receiving an indication that an updated version of software code to be executed in an isolated execution environment is available for deployment, wherein the isolated execution environment comprises computation resources partitioned from a virtual machine and provides isolated access to information to a respective tenant of the multi-tenant system using the partitioned computation resources.
However, Help Net Security discloses:
wherein the isolated execution environment comprises computation resources partitioned from a virtual machine and provides isolated access to information to a respective [customer] using the partitioned computation resources (page 1, “Amazon Web Services announced the general availability of AWS Nitro Enclaves, a new Amazon EC2 capability that makes it easier for customers to securely process highly sensitive data. AWS Nitro Enclaves helps customers reduce the attack surface for their applications by providing a trusted, highly isolated, and hardened environment for data processing. Each Enclave is a virtual machine created using the same Nitro Hypervisor technology that provides CPU and memory isolation for Amazon EC2 instances […] This isolation means that applications running in an Enclave remain inaccessible to other users and systems, even to users within the customer’s organization (emphasis added).”; page 2, “With AWS Nitro Enclaves, customers simply select an instance type and decide how much CPU and memory they want to designate to the Enclave. AWS Nitro Enclaves provides the flexibility to partition varying combinations of CPU cores and memory, enabling customers to match resources to the size and performance demands of their workloads (emphasis added).”; page 3, “Nitro Enclaves builds on those same security and isolation models that have separated AWS for so many customers, delivering a more efficient method for securely processing highly sensitive data. This means customers can build and innovate faster in a way that still meets the highest bar for security.”).
Fontoura is within the same field of endeavor as the claimed invention regarding the deployment of a software update. Help Net Security is also within the same field of endeavor as the claimed invention regarding the utilization of enclaves that partition computation resources.
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teaching of Help Net Security into the teaching of Fontoura to include “receiving an indication that an updated version of software code to be executed in an isolated execution environment is available for deployment, wherein the isolated execution environment comprises computation resources partitioned from a virtual machine and provides isolated access to information to a respective tenant of the multi-tenant system using the partitioned computation resources.” The modification would be obvious because one of ordinary skill in the art would be motivated to utilize AWS Nitro enclaves as an isolated execution environment since it helps users reduce the attack surface for their applications by providing a trusted, highly isolated, and hardened environment for data processing (Help Net Security, page 1).
The combination of Fontoura and Help Net Security does not explicitly disclose:
determining a unique identifier associated with the updated version of the software code.
However, Costa discloses:
determining a unique identifier associated with the updated version of the software code (paragraph [0182], “The VERSION_ID property may be used, for example, to indicate a unique identifier of the update version (emphasis added).”; paragraph [0197], “In accordance with various aspects of the present disclosure, each update (e.g., software, firmware, and data/configuration information) may be characterized/identified by an associated CURRENT_VERSION parameter, and an associated unique identifier, VERSION_ID, that contains the incremental version of the update […] (emphasis added).”).
Costa is within the same field of endeavor as the claimed invention regarding determining software version identifiers.
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teaching of Costa into the combined teachings of Fontoura and Help Net Security to include “determining a unique identifier associated with the updated version of the software code.” The modification would be obvious because one of ordinary skill in the art would be motivated to ensure different software versions are clearly distinguished to “identify an appropriate and/or plausible update” (Costa, paragraph [0189]).
The combination of Fontoura, Help Net Security, and Costa discloses “a first identifier (Costa, paragraph [0197], “In accordance with various aspects of the present disclosure, each update (e.g., software, firmware, and data/configuration information) may be characterized/identified by an associated CURRENT_VERSION parameter, and an associated unique identifier, VERSION_ID, that contains the incremental version of the update […] (emphasis added).”),” “a second identifier (see previous citation),” and “a unique identifier (see previous citation),” but does not explicitly disclose:
modifying configuration data comprising a first identifier associated with a current version of the software code and a second identifier associated with a previous version of the software code, wherein the modifying comprises updating the second identifier with the first identifier and updating the first identifier with the unique identifier associated with the updated version of the software code.
However, Lee discloses:
modifying configuration data comprising [current version information] of the software code and [previous version information] of the software code, wherein the modifying comprises updating the [previous version information] with the [current version information] and updating the [current version information] with the [updated version of the software code] (Figure 2B: S42, S46; Figure 4B: 460, 480; paragraph [0037] “The component configuration DB may include […] components identifiers, current information on a version of a currently installed [software] component and the memory address of the component recorded in a memory, […], previous information on a version and address before the [software] component is updated, etc. (emphasis added).”; paragraph [0066], “The component configuration information 912 includes state information on an update transaction, component identifiers, and previous information, current information and state information on each component (emphasis added).”; paragraph [0068], “The update engine 913 changes the state information on a component to be updated to "download", changes previous [version] information on the component to current [version] information on the component, deletes the component to store the new version of the component, changes the state information on the component to "update", changes the current [version] information on the component to information on the new [updated] version of the component, changes the state information on the component to "done" to perform the component update (emphasis added).”).
Lee is within the same field of endeavor as the claimed invention regarding tracking software versions across updates.
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teaching of Lee into the combined teachings of Fontoura, Help Net Security, and Costa to include “modifying configuration data comprising a first identifier associated with a current version of the software code and a second identifier associated with a previous version of the software code, wherein the modifying comprises updating the second identifier with the first identifier and updating the first identifier with the unique identifier associated with the updated version of the software code.” The modification would be obvious because one of ordinary skill in the art would be motivated to update stored previous and current version information as well as overwrite an existing current component file with a new file of the updated version of the component to effectively update software in an apparatus having limited memory (Lee, paragraph [0039]).
The combination of Fontoura, Help Net Security, Costa, and Lee discloses “configuration data (Lee, paragraph [0066], ““The component configuration information 912 includes state information on an update transaction, component identifiers, and previous information, current information and state information on each component (emphasis added).”),” “an updated first identifier (Costa, paragraph [0197], “In accordance with various aspects of the present disclosure, each update (e.g., software, firmware, and data/configuration information) may be characterized/identified by an associated CURRENT_VERSION parameter, and an associated unique identifier, VERSION_ID, that contains the incremental version of the update […] (emphasis added).”; paragraph [0204], ““[…] including two DEVICE_TYPE and three HARDWARE_VERSION identifiers, this does not represent a specific limitation of the present disclosure, as a different number or different identifiers may be used in accordance with the present disclosure (emphasis added).”) [Examiner’s Remarks: Note that Costa discloses a current version identifier and unique updated version identifier for each software update. Costa also discloses that different identifiers may be used. One of ordinary skill in the art would readily comprehend that updated identifiers regarding the software’s current and updated versions may be used.],” “an updated second identifier (see previous citation),” and “the current version of the software code and the updated version of the software code (Lee, paragraph [0068], “The update engine 913 […] changes previous [version] information on the component to current [version] information on the component, […] changes the current [version] information on the component to information on the new [updated] version of the component, changes the state information on the component to "done" to perform the component update (emphasis added).”),” but does not explicitly disclose:
generating, based at least in part on the configuration data, an updated key policy, wherein the updated key policy comprises the updated first identifier and the updated second identifier;
updating a key management application programming interface (API) by applying the updated key policy to one or more managed keys, wherein the updated key management API enables the current version of the software code and the updated version of the software code to access the one or more managed keys.
However, Shanbhag discloses:
generating, based at least in part on [a client], an updated key policy, wherein the updated key policy comprises [updating key access limitations or authorizations] (col. 5 lines 52-55 to lines 63-65, “[...] the key management service 105 may be associated with an interface module (not shown) which may enable a client 111 to view, create, update, or otherwise configure policies on keys associated with the client 111 […] The policies may provide explicit limitations (e.g., who cannot use the keys) and/or may provide explicit authorizations (e.g., who can use the keys) (emphasis added).”);
updating a key management application programming interface (API) by applying the updated key policy to one or more managed keys, wherein the updated key management API enables [access to the one or more managed keys] (col. 16 lines 55-59, “For example, a key management service 105 can manage client keys internally and provide a set of APIs for performing client key related operations such as encryption or decryption with respect to encrypted volume keys (emphasis added).”; col. 5 lines 52-67 to col. 6 lines 1-3, “[...] the key management service 105 may be associated with an interface module (not shown) which may enable a client 111 to view, create, update, or otherwise configure policies on keys associated with the client 111 […] The policies may provide explicit limitations (e.g., who cannot use the keys) and/or may provide explicit authorizations (e.g., who can use the keys) […] When a request to perform a cryptographic operation using a key is received, any policies on the key may be accessed and processed to determine if the request can, according to policy, be fulfilled (emphasis added).”; col. 10 lines 47-55, “Upon confirming that the API call conforms to an applicable policy (e.g., the newly created or updated policy permitting the host computing device 110 to obtain the decryption of the encrypted volume key), the key management service 105 performs the requested decryption and transmits to the virtual machine manager 122 a plaintext volume key for encrypting data to be written to the data storage volume and for decrypting data read from the volume (emphasis added).”) [Examiner’s Remarks: Note that Shanbhag discloses a key management service that manages client keys and provides a set of APIs for performing client key related operations (cryptographic operations using managed keys). Shanbhag also discloses a client being able to update policies on client keys that can provide key access limitations/authorizations and confirming that an API call conforms to an applicable policy such as an updated policy. One of ordinary skill in the art would readily comprehend that confirming whether an API call conforms to an updated key policy translates to a key management API being updated due to the updated key policy. As a result, an updated key policy regarding access authorizations applied to one or more keys associated with the client (managed keys) may also update a key management API to enable access to the one or more managed keys through client key related operations.].
Shanbhag is within the same field of endeavor as the claimed invention regarding the use of key management APIs and policies to control the access of managed keys.
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teaching of Shanbhag into the combined teachings of Fontoura, Help Net Security, Costa, and Lee to include “generating, based at least in part on the configuration data, an updated key policy, wherein the updated key policy comprises the updated first identifier and the updated second identifier; updating a key management application programming interface (API) by applying the updated key policy to one or more managed keys, wherein the updated key management API enables the current version of the software code and the updated version of the software code to access the one or more managed keys.” The modification would be obvious because one of ordinary skill in the art would be motivated to enhance security of tenant data by utilizing a key management service to securely manage access to keys (Shanbhag, col. 5 lines 28-30).
As per Claim 4, the rejection of Claim 1 is incorporated; and the combination of Fontoura, Costa, Lee, and Shanbhag does not explicitly disclose:
wherein the computation resources comprise one or more of a kernel, a central processing unit (CPU), and memory.
However, Help Net Security discloses:
wherein the computation resources comprise one or more of a kernel, a central processing unit (CPU), and memory (page 2, “With AWS Nitro Enclaves, customers simply select an instance type and decide how much CPU and memory they want to designate to the Enclave. AWS Nitro Enclaves provides the flexibility to partition varying combinations of CPU cores and memory, enabling customers to match resources to the size and performance demands of their workloads (emphasis added).”).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teaching of Help Net Security into the combined teachings of Fontoura, Costa, Lee, and Shanbhag to include “wherein the computation resources comprise one or more of a kernel, a central processing unit (CPU), and memory.” The modification would be obvious because one of ordinary skill in the art would be motivated to utilize AWS Nitro enclaves and partition the CPU and memory resources to allow users more flexibility in being able to control and match resources to the size and performance demands of their workloads (Help Net Security, page 2).
As per Claim 5, the rejection of Claim 1 is incorporated; and Fontoura discloses “the multi-tenant system,” but the combination of Fontoura, Help Net Security, Costa, and Lee does not explicitly disclose:
wherein updating the key management API comprises:
determining the one or more managed keys based at least in part on identifying, from among a plurality of managed keys, at least one managed key associated with the multi-tenant system.
However, Shanbhag discloses:
wherein updating the key management API comprises:
determining the one or more managed keys based at least in part on identifying, from among a plurality of managed keys, at least one managed key associated with the [client] (col. 9 lines 22-25, “In some embodiments, the key management service 105 may request or allow the client 111 to select the client key from multiple keys associated with the client 111 for policy creation or updating (emphasis added).”; col. 5 lines 38-42, “Illustratively, the key management service 105 can select an appropriate key (e.g., a key managed for a client 111 associated with the request), perform the cryptographic operation using the selected key […] (emphasis added).”).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teaching of Shanbhag into the combined teachings of Fontoura, Help Net Security, Costa, and Lee to include “wherein updating the key management API comprises: determining the one or more managed keys based at least in part on identifying, from among a plurality of managed keys, at least one managed key associated with the multi-tenant system.” The modification would be obvious because one of ordinary skill in the art would be motivated to enhance security of tenant data by utilizing a key management service to securely manage access to keys (Shanbhag, col. 5 lines 28-30).
As per Claim 7, the rejection of Claim 1 is incorporated; and Fontoura discloses “the multi-tenant system,” but the combination of Fontoura, Help Net Security, Costa, and Lee does not explicitly disclose:
wherein each of the one or more managed keys is associated with a different tenant associated with the multi-tenant system.
However, Shanbhag discloses:
wherein each of the one or more managed keys is associated with a different tenant associated with the multi-tenant system (col. 5 lines 30-35, “For example, the key management service [multi-tenant system] 105 may manage keys so that, for a client [tenant] 111, other clients or services [different tenants] do not have access to the client's key(s) and are unable to cause the key management service 105 to use the client's key(s) to perform cryptographic operations (emphasis added).”).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teaching of Shanbhag into the combined teachings of Fontoura, Help Net Security, Costa, and Lee to include “wherein each of the one or more managed keys is associated with a different tenant associated with the multi-tenant system.” The modification would be obvious because one of ordinary skill in the art would be motivated to enhance security of tenant data by utilizing a key management service to securely manage access to keys (Shanbhag, col. 5 lines 28-30).
Claims 8, 11, 12, and 14 are apparatus claims corresponding to computer-implemented method Claims 1, 4, 5, and 7 and are rejected for the same reasons as given in the rejections of those claims.
Claims 15, 17, 18, and 20 are non-transitory computer-readable medium claims corresponding to computer-implemented method Claims 1, 4, 5, and 7 and are rejected for the same reasons as given in the rejections of those claims.
Claims 2, 3, 6, 9, 10, 13, 16, and 19 are rejected under 35 U.S.C. 103 as being unpatentable over Fontoura in view of Help Net Security, Costa, Lee, and Shanbhag as applied to Claims 1, 8, and 15 above, and further in view of US 2023/0179435 (hereinafter “Heinecke”).
As per Claim 2, the rejection of Claim 1 is incorporated; and the combination of Fontoura, Help Net Security, Costa, Lee, and Shanbhag discloses “the unique identifier associated with the updated version of the software code (Costa, paragraph [0197], “[…] an associated unique identifier, VERSION_ID, that contains the incremental version of the update […] (emphasis added).”),” but does not explicitly disclose:
a hash value associated with the isolated execution environment.
However, Heinecke discloses:
a hash value associated with the isolated execution environment (paragraph [0027], “[AWS] Nitro Enclaves creates an isolated execution environment inside an Amazon EC2™ (Elastic Cloud Compute) instance […] An attestation includes information about the enclave environment recorded as hashes of the continuous measurements of the parent instance ID, the enclave image file (container), and the application requesting the attestation (emphasis added).”).
Heinecke is within the same field of endeavor as the claimed invention regarding isolated execution environments.
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teaching of Heinecke into the combined teachings of Fontoura, Help Net Security, Costa, Lee, and Shanbhag to include “a hash value associated with the isolated execution environment.” The modification would be obvious because one of ordinary skill in the art would be motivated to use a hash value to detect changes and verify the integrity of data (Heinecke, paragraph [0032] & paragraph [0047]).
As per Claim 3, the rejection of Claim 2 is incorporated; and the combination of Fontoura, Help Net Security, Costa, Lee, and Shanbhag does not explicitly disclose:
wherein the hash value comprises a hash of an image file of the isolated execution environment.
However, Heinecke discloses:
wherein the hash value comprises a hash of an image file of the isolated execution environment (paragraph [0027], “[AWS] Nitro Enclaves creates an isolated execution environment inside an Amazon EC2™ (Elastic Cloud Compute) instance […] An attestation includes information about the enclave environment recorded as hashes of the continuous measurements of the parent instance ID, the enclave image file (container), and the application requesting the attestation (emphasis added).”; paragraph [0028], “[…] an enclave attestation a includes a sequence attestation s and the signed hash of the image file running on the enclave (emphasis added).”).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teaching of Heinecke into the combined teachings of Fontoura, Help Net Security, Costa, Lee, and Shanbhag to include “wherein the hash value comprises a hash of an image file of the isolated execution environment.” The modification would be obvious because one of ordinary skill in the art would be motivated to use a hash value to detect changes and verify the integrity of data (Heinecke, paragraph [0032] & paragraph [0047]).
As per Claim 6, the rejection of Claim 1 is incorporated; and the combination of Fontoura, Help Net Security, Costa, Lee, and Shanbhag discloses “the first identifier associated with the current version of the software code (Costa, paragraph [0183], “Finally, the value of the CURRENT_VERSION parameter [identifier] may, for example, be used to indicate the software/firmware/data version currently installed and running in the operative system of the NU (emphasis added).”)” and “the second identifier (see previous citation) associated with the previous version of the software code (Lee, paragraph [0037], “The component configuration DB may include […] previous information on a version and address before the [software] component is updated, etc. (emphasis added).”),” but does not explicitly disclose:
a first hash value associated with a first isolated execution environment associated with the current version of the software code, and
a second hash value associated with a second isolated execution environment associated with the previous version of the software code.
However, Heinecke discloses:
a first hash value associated with a first isolated execution environment (paragraph [0027], “[AWS] Nitro Enclaves creates an isolated execution environment inside an Amazon EC2™ (Elastic Cloud Compute) instance […] An attestation includes information about the enclave environment recorded as hashes of the continuous measurements of the parent instance ID, the enclave image file (container), and the application requesting the attestation (emphasis added).”), and
a second hash value associated with a second isolated execution environment (paragraph [0027], “[AWS] Nitro Enclaves creates an isolated execution environment inside an Amazon EC2™ (Elastic Cloud Compute) instance […] An attestation includes information about the enclave environment recorded as hashes of the continuous measurements of the parent instance ID, the enclave image file (container), and the application requesting the attestation (emphasis added).”).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teaching of Heinecke into the combined teachings of Fontoura, Help Net Security, Costa, Lee, and Shanbhag to include “a first hash value associated with a first isolated execution environment associated with the current version of the software code, and a second hash value associated with a second isolated execution environment associated with the previous version of the software code.” The modification would be obvious because one of ordinary skill in the art would be motivated to use a hash value to detect changes and verify the integrity of data (Heinecke, paragraph [0032] & paragraph [0047]).
Claims 9, 10, and 13 are apparatus claims corresponding to computer-implemented method Claims 2, 3, and 6 and are rejected for the same reasons as given in the rejections of those claims.
Claims 16 and 19 are non-transitory computer-readable medium claims corresponding to computer-implemented method Claims 3 and 6 and are rejected for the same reasons as given in the rejections of those claims.
Response to Arguments
Applicant's arguments filed on March 6, 2026 have been fully considered but they are not persuasive.
In the Remarks, the Applicant argues:
First, the Office Action alleges that Fontoura is relevant to "an isolated execution environment," as recited in independent claim 1. Office Action, p. 4 (citing Fontoura " [0002] and [0005]). But Fontoura does not teach or suggest, an "isolated execution environment [that] comprises computation resources partitioned from a virtual machine and provides isolated access to information to a respective tenant of the multi-tenant system using the partitioned computation resources," as recited in amended independent claim 1.
Fontoura is generally directed to "[s]oftware updates within one or more regions of a multi-tenant cloud." Fontoura, Abstract. For example, at portions cited by the Office Action, Fontoura describes "identifying and reducing or eliminating update conflicts between different architectural levels (IaaS level, PaaS level, application level) within a cloud computing environment." Id. 1 [0005]. At other portions cited by the Office Action, Fontoura states that "[t]o deploy their applications in the cloud, tenants install their own operating system images on top of the cloud's virtual machines, then install their application software on top of the operating systems." Id. 1 [0002] (emphasis added). That is, Fontoura discusses tenants installing and updating application software on virtual machines of a cloud computing environment.
However, installing and updating application software on virtual machines of a cloud computing environment, as discussed in Fontoura, does not teach or suggest "receiving an indication that an updated version of software code to be executed in an isolated execution environment is available" in which the "isolated execution environment comprises computation resources partitioned from a virtual machine," and "provides isolated access to information to a respective tenant of the multi-tenant system using the partitioned computation resources," as recited in amended independent claim 1. For example, the cited portions of Fontoura are silent with respect to any "partitioned computation resources" much less teach or suggest an isolated execution environment that "provides isolated access to information to a respective tenant of the multi-tenant system using the partitioned computation resources," as claimed. Thus, for at least these reasons, Fontoura does not teach or suggest the aforementioned features of amended independent claim 1.
Examiner’s response:
Applicant’s arguments with respect to Claims 1, 8, and 15 have been considered but are moot because the new ground of rejection does not rely on any reference applied in the prior rejection of record for any teaching or matter specifically challenged in the argument.
In the Remarks, the Applicant argues:
Second, the Office Action alleges that Shanbhag, Costa, and Lee are relevant to "generating, based at least in part on the configuration data, an updated key policy, wherein the updated key policy comprises the updated first identifier and the updated second identifier," as recited in independent claim 1. But neither Shanbhag, Costa, nor Lee-alone or in any combination-teach or suggest an "updated key policy [that] comprises the updated first identifier [associated with a current version of the software code to be executed in the isolated execution environment] and the updated second identifier [associated with a previous version of the software code]," as recited in independent claim 1.
Shanbhag is generally directed to a data storage management process that includes "managing encrypted data via data storage volumes in conjunction with a service provider computer network that hosts virtual machine instances." Shanbhag, Abstract. At portions cited by the Office Action, Shanbhag describes that a "key management service 105 may facilitate configuration and management of policies for accessing keys." Id., col. 5, 11. 50-67. Shanbhag states that a "policy may, for instance, limit identities of clients, other devices and/or systems that are able to direct use of the key, limit times when the key can be used, limit data on which the keys can be used to perform cryptographic operations, and provide other limitations." Id. (emphasis added). That is, Shanbhag discusses key "policies [that] may provide explicit limitations (e.g., who cannot use the keys) and/or may provide explicit authorizations (e.g., who can use the keys)." Id. (emphasis added).
However, key policies that provide explicit limitations, such as who can use the keys, as discussed in Shanbhag, does not teach or suggest generating an "updated key policy [that] comprises the updated first identifier [associated with a current version of the software code to be executed in the isolated execution environment] and the updated second identifier [associated with a previous version of the software code]," as recited in amended independent claim 1. A key policy providing explicit limitations of what clients, devices, systems times, or data can use the keys is not the same as, nor does it teach or suggest an "updated key policy compris[ing] the updated first identifier and the updated second identifier," as claimed. Nowhere does Shanbhag discuss the key policy as including any identifier associated with any version of software code, much less an "updated first identifier [associated with a current version of the software code] and the updated second identifier [associated with a previous version of the software code]," as recited in amended independent claim 1.
Indeed, the Office Action appears to allege that Costa and Lee are relevant to the "updated first identifier" and "updated second identifier," as recited in independent claim 1. Office Action, pp. 8 and 9 (citing Costa " [0197] and [0204] and Lee IT [0066] and [0068]). But neither Costa nor Lee teach or suggest the claimed features.
As the MPEP explains, "when evaluating the scope of a claim, every limitation in the claim must be considered. USPTO personnel may not dissect a claimed invention into discrete elements and then evaluate the elements in isolation. Instead, the claim as a whole must be considered." MPEP § 2103 (citing Diamond v. Diehr, 450 U.S. 175, 188-89, 209 USPQ 1, 9 (1981)) (emphasis added). In this case, the Office Action has not shown that the cited references teach or suggest each feature of independent claim 1, for at least the reason that the analysis has not considered independent claim 1 as a whole.
For example, Costa is directed to "the remote update and distribution of software, firmware, and/or data in a network of moving things." Costa, Abstract (emphasis added). The cited portions of Costa discuss a network unit (NU) applying updates "characterized/identified by an associated CURRENT_VERSION parameter, and an associated unique identifier, VERSION_ID," among other parameters. Id. 1 [0197]. At other portions cited by the Office Action, Costa states that "a number of factors may be used to partition updates to a particular HARDWARE_VERSION of a NU into one pool or another." Id. 1 [0204].
The Office Action alleges that "one of ordinary skill in the art would readily comprehend that updated identifiers regarding the software's current and updated versions may be used." Office Action, p. 8. But this reasoning is conclusory and unsupported. Costa's VERSION_ID or CURRENT_VERSION parameters do not teach or suggest a "first identifier associated with a current version of the software code [to be executed in an isolated execution environment]," nor a "second identifier associated with a previous version of the software code [to be executed in an isolated execution environment]" that are included in "an updated key policy," as recited in amended independent claim 1. Costa's identifiers track software versions for network units in a network of moving things and are not used in any key policy, much less the claimed "updated key policy." Thus, Costa does not teach or suggest at least the aforementioned features of amended independent claim 1.
Lee discusses "updating software in an apparatus having limited storage." Lee, Abstract. The cited portions of Lee describe a configuration information that includes "component identifiers, previous information, current information and state information on each component," as well as an update engine that shifts the version information during an update transaction. See id. " [0066] and [0068]. However, Lee's previous and current information are used for software updates in devices with limited memory, and are not identifiers included in any key policy. Lee is silent regarding any key management system, key policy, or the use of software version identifiers within a key policy. Accordingly, Lee does not teach or suggest "modifying configuration data comprising a first identifier associated with a current version of the software code and a second identifier associated with a previous version of the software code" where an "updated key policy comprises the updated first identifier and the updated second identifier," as recited in amended independent claim 1.
Examiner’s response:
Examiner disagrees. Applicant’s arguments are not persuasive for at least the following reasons:
First, the Examiner would like to point out that Diamond v. Diehr pertains to evaluating patent eligibility of computer software-related inventions under § 101 and does not have any precedent over a determination of obviousness under 35 U.S.C. § 103. In Diamond v. Diehr, the Court stated that “[i]n determining the eligibility of respondents’ claimed process for patent protection under § 101, their claims must be considered as a whole. It is inappropriate to dissect the claims into old and new elements and then to ignore the presence of the old elements in the analysis. This is particularly true in a process claim because a new combination of steps in a process may be patentable even though all the constituents of the combination were well known and in common use before the combination was made.” Thus, as can be seen, there is no requirement in Diamond v. Diehr that a claim cannot be dissected when making a determination of obviousness under 35 U.S.C. § 103.
Furthermore, the Examiner would also like to point out that the 35 U.S.C. § 103 rejections presented in the Non-Final Rejection (mailed on 12/09/2025) and the instant Office action are resolved on the basis of the factual inquiries of Graham v. John Deere Co., which are the controlling inquiries in any obviousness analysis. And in the 35 U.S.C. § 103 rejection write-up, the Examiner has set forth a) the relevant teachings of the prior art relied upon, preferably with reference to the relevant column or page number(s) and line number(s) where appropriate, b) the difference or differences in the claim over the applied reference(s), c) the proposed modification of the applied reference(s) necessary to arrive at the claimed subject matter, and d) an explanation as to why the claimed invention would have been obvious to one of ordinary skill in the art at the relevant time.
Second, in response to the Applicant’s arguments against the references individually, one cannot show non-obviousness by attacking references individually where the rejections are based on combinations of references. See In re Keller, 642 F.2d 413, 208 USPQ 871 (CCPA 1981); In re Merck & Co., 800 F.2d 1091, 231 USPQ 375 (Fed. Cir. 1986).
Third, Costa discloses an “updated first identifier” and an “updated second identifier.” In paragraph [0197], Costa discloses that each software update may be identified by a current version parameter (first identifier) and unique version identifier (second identifier). As a result, when software is updated, both the current version parameter and unique version identifier would also be updated to characterize/identify the new software update. One of ordinary skill in the art would be motivated to incorporate Costa’s updated identifiers into the combined teachings of Fontoura and Help Net Security in order to ensure different software versions are clearly and easily distinguished which helps effectively identify updates by referring to the identifiers. Lee discloses “configuration data” associated with previous and current software version information in paragraphs [0066 & 0068]. One of ordinary skill in the art would be motivated to incorporate Lee’s configuration data associated with previous and current software version information into the combined teachings of Fontoura, Help Net Security, and Costa in order to use this data to effectively update software even if the apparatus of the software has limited memory. Shanbhag discloses “generating, based at least in part on [a client], an updated key policy, wherein the updated key policy comprises [updating key access limitations or authorizations]” in col. 5 lines 52-55 to lines 63-65. The combination of Fontoura, Help Net Security, Costa, Lee, and Shanbhag discloses the limitation “generating, based at least in part on the configuration data, an updated key policy, wherein the updated key policy comprises the updated first identifier and the updated second identifier” and one of ordinary skill in the art would be motivated to incorporate Shanbhag’s updated into the combined teachings of Fontoura, Help Net Security, Costa, and Lee in order to enhance security of tenant data by utilizing a key management service to securely manage access to keys. Specifically, the combination of Costa, Lee, and Shanbhag discloses generating the key policy based on configuration data and the updated key policy comprising the updated identifiers by combining Shanbhag’s key policy with Costa’s updated identifiers, and Lee’s configuration data.
Therefore, for at least the reasons set forth above, the rejections made under 35 U.S.C. § 103 with respect to Claims 1, 8, and 15 are proper.
In the Remarks, the Applicant argues:
Nor would the person having ordinary skill in the art combine Costa and Lee with Shanbhag to arrive at the features of amended independent claim 1. The Office Action asserts that it would have been obvious to combine these references to "enhance security of tenant data by utilizing a key management service to securely manage access to keys." Office Action, p. 11 (citing Shanbhag, col. 5, 11. 28-30). But the Office Action does not provide an explicit analysis explaining how the version identifiers of Costa or the version updating of Lee would be incorporated into the key policies of Shanbhag to arrive at an "updated key policy [that] comprises the updated first identifier and the updated second identifier," as claimed. Rejections for obviousness cannot be sustained by mere conclusory statements; rather, the Office must articulate its reasoning with rational underpinnings to support the legal conclusion of obviousness. See MPEP 2141(III) (citing KSR Int 'l, Co. v. Teleflex, Inc., 550 U.S. at 418, 82 USPQ2d at 396 (2007)). Here, the Office Action has not explained how or why a person of ordinary skill would incorporate version identifiers from Costa or Lee into the key policies of Shanbhag, particularly where none of these references contemplate the use of software version identifiers within key policies to control access to managed keys.
Examiner’s response:
Examiner disagrees. Applicant’s arguments are not persuasive for at least the following reasons:
First, the Examiner has provided a clear articulation of the reasons why the claimed invention would have been obvious. When a rejection depends on a combination of prior art references, there must be some teaching, suggestion, or motivation to combine the references. See In re Geiger, 815 F.2d 686, 688, 2 USPQ2d 1276, 1278 (Fed. Cir. 1987). Therefore, the Examiner’s rejections of the claims on obviousness grounds are not based on mere conclusory statements because the teaching-suggestion-motivation (TSM) test asks not merely what the references disclose, but whether a person of ordinary skill in the art, possessed with the understandings and knowledge reflected in the prior art, and motivated by the general problem facing the inventor, would have been led to make the combination recited in the claims. See Cross Med. Prods., 424 F.3d at 1321-24. From this it may be determined whether the overall disclosures, teachings, and suggestions of the prior art, and the level of skill in the art—i.e., the understandings and knowledge of persons having ordinary skill in the art at the time of the invention—support the legal conclusion of obviousness. See Princeton Biochemicals, 411 F.3d at 1338 (pointing to evidence supplying detailed analysis of the prior art and the reasons one of ordinary skill would have possessed the knowledge and motivation to combine).
Second, Costa discloses an “updated first identifier” and an “updated second identifier.” In paragraph [0197], Costa discloses that each software update may be identified by a current version parameter (first identifier) and unique version identifier (second identifier). As a result, when software is updated, both the current version parameter and unique version identifier would also be updated to characterize/identify the new software update. One of ordinary skill in the art would be motivated to incorporate Costa’s updated identifiers into the combined teachings of Fontoura and Help Net Security in order to ensure different software versions are clearly and easily distinguished which helps effectively identify updates by referring to the identifiers. Lee discloses “configuration data” associated with previous and current software version information in paragraphs [0066 & 0068]. One of ordinary skill in the art would be motivated to incorporate Lee’s configuration data associated with previous and current software version information into the combined teachings of Fontoura, Help Net Security, and Costa in order to use this data to effectively update software even if the apparatus of the software has limited memory. Shanbhag discloses “generating, based at least in part on [a client], an updated key policy, wherein the updated key policy comprises [updating key access limitations or authorizations]” in col. 5 lines 52-55 to lines 63-65. The combination of Fontoura, Help Net Security, Costa, Lee, and Shanbhag discloses the limitation “generating, based at least in part on the configuration data, an updated key policy, wherein the updated key policy comprises the updated first identifier and the updated second identifier” and one of ordinary skill in the art would be motivated to incorporate Shanbhag’s updated into the combined teachings of Fontoura, Help Net Security, Costa, and Lee in order to enhance security of tenant data by utilizing a key management service to securely manage access to keys. Specifically, the combination of Costa, Lee, and Shanbhag discloses generating the key policy based on configuration data and the updated key policy comprising the updated identifiers by combining Shanbhag’s key policy with Costa’s updated identifiers, and Lee’s configuration data.
Therefore, for at least the reasons set forth above, the rejections made under 35 U.S.C. § 103 with respect to Claims 1, 8, and 15 are proper.
In the Remarks, the Applicant argues:
Further, the asserted modification of Shanbhag is improper because it would change the principle of operation of Shanbhag. See MPEP § 2143.01(VI) (citing In re Ratti, 270 F.2d 810, 813, 123 USPQ 349, 352 (CCPA 1959)). As discussed above, Shanbhag's key policies are directed to controlling which entities (e.g., clients, devices, systems) may use a key, and when and on what data the key may be used. See e.g., Shanbhag, col. 5, 11. 50-67. That is, Shanbhag's policies define access authorizations based on the identity of the requesting entity-not based on identifiers associated with versions of software code. Incorporating software version identifiers into Shanbhag's key policies, as the Office Action proposes, would fundamentally alter the nature of what Shanbhag's policies are designed to control. Shanbhag's policies answer the question "who can use this key?"-not "which version of software code is authorized to access this key?" The proposed modification would thus require Shanbhag's key policies to operate in a manner that Shanbhag does not contemplate, changing the principle of operation of the prior art being modified.
Examiner’s response:
Examiner disagrees. Applicant’s arguments are not persuasive for at least the following reasons:
First, the Examiner would like to point out that the test for obviousness is not whether the features of a secondary reference may be bodily incorporated into the structure of the primary reference; nor is it that the claimed invention must be expressly suggested in any one or all of the references. Rather, the test is what the combined teachings of the references would have suggested to those of ordinary skill in the art. See In re Keller, 642 F.2d 413, 208 USPQ 871 (CCPA 1981). Furthermore, it is well-established that a determination of obviousness based on teachings from multiple references does not require an actual, physical substitution of elements. See In re Mouttet, 686 F.3d 1322, 1332, 103 USPQ2d 1219, 1226 (Fed. Cir. 2012) (citing In re Etter, 756 F.2d 852, 859, 225 USPQ 1, 6 (Fed. Cir. 1985) (en banc)).
Second, the Examiner would also like to point out that the proposed modification or combination of the prior art involves combining the secondary references Help Net Security, Costa, Lee, and Shanbhag into the primary reference Fontoura. Thus, the proposed modification or combination would only involve modifying Fontoura, not Shanbhag.
Third, the Examiner respectfully submits that, in view of the teachings of Fontoura, Help Net Security, Costa, Lee, and Shanbhag, one of ordinary skill in the art would readily recognize that Fontoura’s system that coordinates updates in a multi-tenant cloud computing environment could be modified to include Help Net Security’s AWS Nitro Enclaves, Costa’s identifiers, Lee’s configuration data associated with current and previous software versions, and Shanbhag’s key policy and key management API. Such proposed modification would still render Fontoura’s system to operate as intended because including AWS Nitro Enclaves, identifiers, configuration data, and key policies/key management API would not change the principle of operation of Fontoura’s system that coordinates updates in a multi-tenant cloud computing environment. The features disclosed in Help Net Security, Costa, Lee, and Shanbhag are all software-related and, therefore, would not change the principle of operation of Fontoura. Unlike in Ratti, the Examiner does not believe that the “suggested combination of references would require a substantial reconstruction and redesign of the elements shown” in Fontoura, or a “change in [its] basic principles.” 270 F.2d at 813. Rather, Fontoura, Help Net Security, Costa, Lee, and Shanbhag teach every element of the claimed invention and the combination of the references accords with their teachings.
Therefore, for at least the reasons set forth above, the rejections made under 35 U.S.C. § 103 with respect to Claims 1, 8, and 15 are proper.
Conclusion
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to Feven H. Huruy whose telephone number is (571) 272-3826. The examiner can normally be reached Mon-Fri. 7:30am-3:45pm.
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, Wei Mui can be reached at (571) 272-3708. 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.
/F.H.H./Examiner, Art Unit 2191 /WEI Y MUI/Supervisory Patent Examiner, Art Unit 2191
Prosecution Insights