CTNF 18/968,081 CTNF 86467 DETAILED ACTION Notice of Pre-AIA or AIA Status 07-03-aia AIA 15-10-aia 1. The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA. 2. Claims 1-20 are pending on this application. Claims 1, 8, and 15 are in independent forms. Information Disclosure Statement 4. The information disclosure statements (IDS's) submitted on 01/16/2025 and 03/31/2026 are in compliance with provisions of 37 CFR 1.97. Accordingly, the information disclosure statement is being considered by the examiner. Drawings 5. The drawings filed on 12/04/2024 are accepted by the examiner. Claim Rejections - 35 USC § 103 07-20-aia AIA 6. 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. 07-21-aia AIA 7. Claim s 1-20 are rejected under 35 U.S.C. 103 as being unpatentable over Srivastava et al. US Patent Application Publication No. 2022/0191046 (hereinafter Srivastava) in view of Ezrielev et al. US Patent Application Publication No. 2024/0364740 (hereinafter Ezrielev) . Regarding claim 1, Srivastava discloses a computer-implemented method for controlling communication targets and timing for workloads (Fig. 1, workload component manager 118) running on secure virtual machines (Fig. 1, cluster master VM 112) , the method comprising: “sending, by a secure virtual machine (VM), a first attestation request for a mutual transport layer security (mTLS) certificate issuer and a specified workload to a trusted execution environment” (see Srivastava par. 0026-0028, trust authority 202 can securely transmit a digital certificate (such as, e.g., a Transport Layer Security (TLS) certificate) to each control plane element that is signed using a private key of trust authority 202 and provides cryptographic proof that the control plane element has been successfully attested by trust authority 202. Then,at the time an end-user wishes to submit a new workload to cluster master VM 112 for deployment in virtualized environment 200, the end-user can first verify cluster master VM 112's digital certificate using the published public key/root certificate of trust authority 202. Assuming the certificate verification of cluster master VM 112 is successful, the end-user can submit a specification of the workload and cluster master VM 112 can subsequently verify (via its certificate verification logic 208) the digital certificate of each node agent VM 114 whose host system is designated to run an execution group of the workload. Assuming the certificate verifications of these node agent VMs are successful, trust authority 202 can carry out hardware-based attestation with respect to each worker VM 116 that is created for the purpose of running the workload components of the workload and can securely transmit a digital certificate to the worker VM upon attestation completion); “responsive to a successful attestation, receiving, by the secure VM, a second attestation request from a workload VM to perform the specified workload” (see Srivastava par. 0028, Assuming the certificate verifications of these node agent VMs are successful, trust authority 202 can carry out hardware-based attestation with respect to each worker VM 116 that is created for the purpose of running the workload components of the workload and can securely transmit a digital certificate to the worker VM upon attestation completion. The node agent VM associated with each worker VM can thereafter verify, via its certificate verification logic 210, the worker VM's digital certificate. Finally, assuming the certificate verifications of the worker VMs are successful, the node agent VMs can securely provide any runtime information needed by the worker VMs to their respective workload component managers (e.g., hashes of workload component image disks, etc.) and the workload component managers can proceed with running the workload components, with guest memory encryption enabled in accordance with the attestation process completed for each worker VM); Srivastava does not explicitly discloses upon attesting by the mTLS certificate issuer, sending, to the workload VM, a time-expiring mTLS certificate for performing the specified workload. However, in analogues art, Ezrielev discloses upon attesting by the mTLS certificate issuer, sending, to the workload VM, a time-expiring mTLS certificate for performing the specified workload (see Ezrielev pars. 0018-0020, access services may perform or include basic authentication such as username/password or perform certificate-based authentication using mTLS (mutual Transport Layer Security) via a REST API (Representational State Transfer Application Programming Interface). Authentication performed using mTLS is generally more secure than basic authentication. During an mTLS handshake, the certificate of the admin is validated against the trusted root CA (Certificate Authority). Invalid certificates (CA or server) may cause the mTLS handshake process to fail. Consequently, the requested access may fail or be denied. This may lead to a scenario where the admin does not have access to the access services. For example, an admin may attempt to access the access services and if the admin's certificate has expired, access will be denied or fail. restoring access to the admin and, more specifically, to restoring access to the admin when the admin's certificate is invalid (e.g., expired). This may include installing a new certificate for the admin in the access services). Therefore it would have been obvious to a person of ordinary skill in the art before the effective filing date of the application to Incorporate the teachings of Ezrielev into the system of Srivastava to provide Invalid certificates (CA or server) cause the mTLS handshake process to fail. Consequently, the requested access may fail or be denied. For example, an admin may attempt to access the access services and if the admin's certificate has expired, access will be denied or fail (see Ezrielev par. 0019). Regarding claims 2, 9, and 16, Srivastava in view of Ezrielev discloses the method of claim 1, the computer system of claim 8, the computer program product of claim 15, Srivastava further discloses receiving, by the secure VM, an attestation response from the trusted execution environment, the attestation response including resources for processing the specified workload (see Srivastava par. 0021, each host system 108 includes a control plane element referred to as a node agent VM (reference numeral 114) and one or more worker VMs 116 (each running a workload component manager 118). Generally speaking, at the time an end-user submits a workload for deployment to cluster master VM 112, cluster master VM 112 transmits, to the node agent VM of each host system designated to run an execution group of the workload, a specification of that execution group. This execution group specification identifies, among other things, the workload component(s) which are part of the execution group and the name and storage location of the software image needed to run each workload component); and responsive to the successful attestation, deploying the specified workload on the workload VM (see Srivastava par. 0021, In response, the receiving node agent VM retrieves the software image(s) for the workload component(s) identified in the specification, stages the software image(s) on virtual disk(s), and attaches the virtual disk(s) to a newly created and powered-on worker VM. The workload component manager of the worker VM then begins execution of the workload component(s) within the worker VM using the attached virtual disk(s), thereby completing the workload deployment process. While the workload component(s) are running, the node agent VM may periodically monitor the state of the workload component(s) by querying the worker VM's workload component manager and report that state back to cluster manager VM 112.). Regarding claims 3, 10, and 17, Srivastava in view of Ezrielev discloses the method of claim 2, the computer system of claim 10, the computer program product of claim 16, Srivastava further discloses embedding, by the secure VM, a symmetric key to a contract (see Srivastava par. 0043, Workflow 500 assumes that cluster master VM 112 and node agent VMs 114(1)-(N) have been attested by trust authority 202 and each assigned a public/private key pair and digital certificate in accordance with workflows 300 and 400); and encrypting, by the secure VM, the time-expiring mTLS certificate with the symmetric key (see Srivastava par. 0024, 0042, In response PSP 204 can intercept, throughout the VM's runtime, accesses made by the VM to guest memory and encrypt/decrypt the accessed data using a VM-specific key that is local to the PSP and inaccessible by the host system's central processing unit(s) (CPU(s)). In this way, PSP 204 can keep the contents of the VM's guest memory hidden from the hypervisor, which is untrusted and thus potentially malicious); wherein: the specified workload is deployed with the contract (see Srivastava par. 0020, Each host system 108 includes, in software, a virtualization software layer (i.e., hypervisor) 110 and virtual machines that correspond to the control plane elements and computing nodes of workload orchestration platform 102. For example, host system 108(1) includes a cluster master VM 112 that can be understood as the front-end control plane element of workload orchestration platform 102 and is configured to expose, to external end-users such as application developers, an interface for deploying and running workloads on virtualized environment 100 via platform 102). Regarding claims 4, 11, and 18, Srivastava in view of Ezrielev discloses the method of claim 3, the computer system of claim 10, the computer program product of claim 15, Ezrielev further discloses wherein the time-expiring mTLS certificate is decrypted by the workload VM using the symmetric key extracted from the contract (see Ezrielev par. 0023, During the TLS handshake operation, a client encrypts data using the public key included in a server's certificate. The server will only be able to decrypt the data if the server has the corresponding private key. This process may be performed in both directions from client to server and from server to client. This allows the client to confirm that the server is who the server claims to be and allows the server to confirm that the client is who the client claims to be. This process requires the client and the server to use their respective private keys). Therefore it would have been obvious to a person of ordinary skill in the art before the effective filing date of the application to Incorporate the teachings of Ezrielev into the system of Srivastava to provide Invalid certificates (CA or server) cause the mTLS handshake process to fail. Consequently, the requested access may fail or be denied. For example, an admin may attempt to access the access services and if the admin's certificate has expired, access will be denied or fail (see Ezrielev par. 0019). Regarding claims 5 and 12, Srivastava in view of Ezrielev discloses the method of claim 1, the computer system of claim 8, Ezrielev further discloses responsive to receiving the time-expiring mTLS certificate, performing, by the workload VM, the specified workload (see Ezrielev pars. 0019-0020, During an mTLS handshake, the certificate of the admin is validated against the trusted root CA (Certificate Authority). Invalid certificates (CA or server) may cause the mTLS handshake process to fail. Consequently, the requested access may fail or be denied. This may lead to a scenario where the admin does not have access to the access services. For example, an admin may attempt to access the access services and if the admin's certificate has expired, access will be denied or fail. restoring access to the admin and, more specifically, to restoring access to the admin when the admin's certificate is invalid (e.g., expired). This may include installing a new certificate for the admin in the access services). Therefore it would have been obvious to a person of ordinary skill in the art before the effective filing date of the application to Incorporate the teachings of Ezrielev into the system of Srivastava to provide Invalid certificates (CA or server) cause the mTLS handshake process to fail. Consequently, the requested access may fail or be denied. For example, an admin may attempt to access the access services and if the admin's certificate has expired, access will be denied or fail (see Ezrielev par. 0019). Regarding claims 6, 13, and 19, Srivastava in view of Ezrielev discloses the method of claim 1, the computer system of claim 8, the computer program product of claim 15, Srivastava further discloses the time-expiring mTLS certificate is encrypted with a public key in the mTLS certificate issuer and is decrypted, upon receipt from the secure VM, with a private key in the workload VM (see Ezrielev par. 0023, During the TLS handshake operation, a client encrypts data using the public key included in a server's certificate. The server will only be able to decrypt the data if the server has the corresponding private key. This process may be performed in both directions from client to server and from server to client. This allows the client to confirm that the server is who the server claims to be and allows the server to confirm that the client is who the client claims to be. This process requires the client and the server to use their respective private keys). Therefore it would have been obvious to a person of ordinary skill in the art before the effective filing date of the application to Incorporate the teachings of Ezrielev into the system of Srivastava to provide Invalid certificates (CA or server) cause the mTLS handshake process to fail. Consequently, the requested access may fail or be denied. For example, an admin may attempt to access the access services and if the admin's certificate has expired, access will be denied or fail (see Ezrielev par. 0019). Regarding claims 7, 14, and 20, Srivastava in view of Ezrielev discloses the method of claim 6, the computer system of claim 13, the computer program product of claim 20, Srivastava further discloses receiving, by the secure VM, the public key with the attestation request from the workload VM (see Srivastava par. 0050, Upon determining that the received measurement matches the known correct measurement (which means that the attestation of new worker VM 116(X) is successful), trust authority 202 can assign a public/private key pair and a digital certificate to worker VM 116(X) and transmit these items to PSP 204(X) over the secure communication channel (block 534). This digital certificate can include the public key assigned to worker VM 116(X) and can be signed using a private key of the root certificate owned by trust authority 202, thereby providing cryptographic proof that trust authority 202 has successfully attested worker VM 116(X)). Regarding claim 8, Srivastava discloses a computer system for controlling communication targets and timing for workloads running on secure virtual machines, the computer system comprising: “a processor set” (fig. 2, Platform Security Processor 204(1)-204(N)); “one or more computer-readable storage media” (see Srivastava par. 0067, one or more embodiments can be implemented as one or more computer programs or as one or more computer program modules embodied in one or more non-transitory computer readable storage media); and program instructions stored on the one or more computer-readable storage media to cause the processor set to perform operations comprising: “sending, by a secure virtual machine (VM), a first attestation request for a mutual transport layer security (mTLS) certificate issuer and a specified workload to a trusted execution environment” (see Srivastava par. 0026-0028, trust authority 202 can securely transmit a digital certificate (such as, e.g., a Transport Layer Security (TLS) certificate) to each control plane element that is signed using a private key of trust authority 202 and provides cryptographic proof that the control plane element has been successfully attested by trust authority 202. Then,at the time an end-user wishes to submit a new workload to cluster master VM 112 for deployment in virtualized environment 200, the end-user can first verify cluster master VM 112's digital certificate using the published public key/root certificate of trust authority 202. Assuming the certificate verification of cluster master VM 112 is successful, the end-user can submit a specification of the workload and cluster master VM 112 can subsequently verify (via its certificate verification logic 208) the digital certificate of each node agent VM 114 whose host system is designated to run an execution group of the workload. Assuming the certificate verifications of these node agent VMs are successful, trust authority 202 can carry out hardware-based attestation with respect to each worker VM 116 that is created for the purpose of running the workload components of the workload and can securely transmit a digital certificate to the worker VM upon attestation completion); “responsive to a successful attestation, receiving, by the secure VM, a second attestation request from a workload VM to perform the specified workload” (see Srivastava par. 0028, Assuming the certificate verifications of these node agent VMs are successful, trust authority 202 can carry out hardware-based attestation with respect to each worker VM 116 that is created for the purpose of running the workload components of the workload and can securely transmit a digital certificate to the worker VM upon attestation completion. The node agent VM associated with each worker VM can thereafter verify, via its certificate verification logic 210, the worker VM's digital certificate. Finally, assuming the certificate verifications of the worker VMs are successful, the node agent VMs can securely provide any runtime information needed by the worker VMs to their respective workload component managers (e.g., hashes of workload component image disks, etc.) and the workload component managers can proceed with running the workload components, with guest memory encryption enabled in accordance with the attestation process completed for each worker VM); Srivastava does not explicitly discloses upon attesting by the mTLS certificate issuer, sending, to the workload VM, a time-expiring mTLS certificate for performing the specified workload. However, in analogues art, Ezrielev discloses upon attesting by the mTLS certificate issuer, sending, to the workload VM, a time-expiring mTLS certificate for performing the specified workload (see Ezrielev pars. 0018-0020, access services may perform or include basic authentication such as username/password or perform certificate-based authentication using mTLS (mutual Transport Layer Security) via a REST API (Representational State Transfer Application Programming Interface). Authentication performed using mTLS is generally more secure than basic authentication. During an mTLS handshake, the certificate of the admin is validated against the trusted root CA (Certificate Authority). Invalid certificates (CA or server) may cause the mTLS handshake process to fail. Consequently, the requested access may fail or be denied. This may lead to a scenario where the admin does not have access to the access services. For example, an admin may attempt to access the access services and if the admin's certificate has expired, access will be denied or fail. restoring access to the admin and, more specifically, to restoring access to the admin when the admin's certificate is invalid (e.g., expired). This may include installing a new certificate for the admin in the access services). Therefore it would have been obvious to a person of ordinary skill in the art before the effective filing date of the application to Incorporate the teachings of Ezrielev into the system of Srivastava to provide Invalid certificates (CA or server) cause the mTLS handshake process to fail. Consequently, the requested access may fail or be denied. For example, an admin may attempt to access the access services and if the admin's certificate has expired, access will be denied or fail (see Ezrielev par. 0019). Regarding claim 15, Srivastava discloses a computer program product for controlling communication targets and timing for workloads running on secure virtual machines, the computer program product comprising: a computer-readable storage medium having a set of instructions stored therein which, when executed by a processor, causes the processor to perform a method comprising: “sending, by a secure virtual machine (VM), a first attestation request for a mutual transport layer security (mTLS) certificate issuer and a specified workload to a trusted execution environment” (see Srivastava par. 0026-0028, trust authority 202 can securely transmit a digital certificate (such as, e.g., a Transport Layer Security (TLS) certificate) to each control plane element that is signed using a private key of trust authority 202 and provides cryptographic proof that the control plane element has been successfully attested by trust authority 202. Then,at the time an end-user wishes to submit a new workload to cluster master VM 112 for deployment in virtualized environment 200, the end-user can first verify cluster master VM 112's digital certificate using the published public key/root certificate of trust authority 202. Assuming the certificate verification of cluster master VM 112 is successful, the end-user can submit a specification of the workload and cluster master VM 112 can subsequently verify (via its certificate verification logic 208) the digital certificate of each node agent VM 114 whose host system is designated to run an execution group of the workload. Assuming the certificate verifications of these node agent VMs are successful, trust authority 202 can carry out hardware-based attestation with respect to each worker VM 116 that is created for the purpose of running the workload components of the workload and can securely transmit a digital certificate to the worker VM upon attestation completion); “responsive to a successful attestation, receiving, by the secure VM, a second attestation request from a workload VM to perform the specified workload” (see Srivastava par. 0028, Assuming the certificate verifications of these node agent VMs are successful, trust authority 202 can carry out hardware-based attestation with respect to each worker VM 116 that is created for the purpose of running the workload components of the workload and can securely transmit a digital certificate to the worker VM upon attestation completion. The node agent VM associated with each worker VM can thereafter verify, via its certificate verification logic 210, the worker VM's digital certificate. Finally, assuming the certificate verifications of the worker VMs are successful, the node agent VMs can securely provide any runtime information needed by the worker VMs to their respective workload component managers (e.g., hashes of workload component image disks, etc.) and the workload component managers can proceed with running the workload components, with guest memory encryption enabled in accordance with the attestation process completed for each worker VM); Srivastava does not explicitly discloses upon attesting by the mTLS certificate issuer, sending, to the workload VM, a time-expiring mTLS certificate for performing the specified workload. However, in analogues art, Ezrielev discloses upon attesting by the mTLS certificate issuer, sending, to the workload VM, a time-expiring mTLS certificate for performing the specified workload (see Ezrielev pars. 0018-0020, access services may perform or include basic authentication such as username/password or perform certificate-based authentication using mTLS (mutual Transport Layer Security) via a REST API (Representational State Transfer Application Programming Interface). Authentication performed using mTLS is generally more secure than basic authentication. During an mTLS handshake, the certificate of the admin is validated against the trusted root CA (Certificate Authority). Invalid certificates (CA or server) may cause the mTLS handshake process to fail. Consequently, the requested access may fail or be denied. This may lead to a scenario where the admin does not have access to the access services. For example, an admin may attempt to access the access services and if the admin's certificate has expired, access will be denied or fail. restoring access to the admin and, more specifically, to restoring access to the admin when the admin's certificate is invalid (e.g., expired). This may include installing a new certificate for the admin in the access services). Therefore it would have been obvious to a person of ordinary skill in the art before the effective filing date of the application to Incorporate the teachings of Ezrielev into the system of Srivastava to provide Invalid certificates (CA or server) cause the mTLS handshake process to fail. Consequently, the requested access may fail or be denied. For example, an admin may attempt to access the access services and if the admin's certificate has expired, access will be denied or fail (see Ezrielev par. 0019) . Conclusion 07-96 AIA 8. The prior art made of record and not relied upon is considered pertinent to applicant's disclosure. Ramakrishnan et al. (US 2025/0053440 A1): discloses A system can include a memory and a processing device, operatively coupled to the memory, to perform operations including receiving a workload, selecting, from a set of worker nodes of a cluster environment, a worker node for scheduling of the workload, determining whether the worker node is valid, including determining whether the worker node is trusted, and in response to determining that the worker node is valid, scheduling the workload with the worker node. Buendgen et al. (US 2023/0044731 A1): discloses A trusted execution environment obtains an attestation request. The attestation request includes at least an attestation key. Based on obtaining the attestation request, one or more integrity measurements are computed, and the computing uses at least the attestation key. The one or more integrity measurements are provided to an entity, and the one or more integrity measurements are to be used to verify that a secure guest has been started using a selected secure guest image and selected secure guest metadata. Any inquiry concerning this communication or earlier communications from the examiner should be directed to SAMUEL AMBAYE whose telephone number is (571)270-7635. The examiner can normally be reached M-F 9:00 AM - 6: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, Jeffrey Pwu can be reached at (571) 272-6798. 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. /SAMUEL AMBAYE/Examiner, Art Unit 2433 /JEFFREY C PWU/Supervisory Patent Examiner, Art Unit 2433 Application/Control Number: 18/968,081 Page 2 Art Unit: 2433 Application/Control Number: 18/968,081 Page 3 Art Unit: 2433 Application/Control Number: 18/968,081 Page 4 Art Unit: 2433 Application/Control Number: 18/968,081 Page 5 Art Unit: 2433 Application/Control Number: 18/968,081 Page 6 Art Unit: 2433 Application/Control Number: 18/968,081 Page 7 Art Unit: 2433 Application/Control Number: 18/968,081 Page 8 Art Unit: 2433 Application/Control Number: 18/968,081 Page 9 Art Unit: 2433 Application/Control Number: 18/968,081 Page 10 Art Unit: 2433 Application/Control Number: 18/968,081 Page 11 Art Unit: 2433 Application/Control Number: 18/968,081 Page 12 Art Unit: 2433 Application/Control Number: 18/968,081 Page 13 Art Unit: 2433 Application/Control Number: 18/968,081 Page 14 Art Unit: 2433 Application/Control Number: 18/968,081 Page 15 Art Unit: 2433 Application/Control Number: 18/968,081 Page 16 Art Unit: 2433 Application/Control Number: 18/968,081 Page 17 Art Unit: 2433
Prosecution Insights