Prosecution Insights
Last updated: October 02, 2026
Application No. 18/530,001

MIGRATING SENSITIVE DATA ACROSS CLOUD CONFIDENTIAL COMPUTING ENVIRONMENTS

Final Rejection §103
Filed
Dec 05, 2023
Examiner
TRUONG, LECHI
Art Unit
2194
Tech Center
2100 — Computer Architecture & Software
Assignee
International Business Machines Corporation
OA Round
2 (Final)
87%
Grant Probability
Favorable
3-4
OA Rounds
2m
Est. Remaining
99%
With Interview

Examiner Intelligence

Grants 87% — above average
87%
Career Allowance Rate
776 granted / 889 resolved
+32.3% vs TC avg
Strong +36% interview lift
Without
With
+36.4%
Interview Lift
resolved cases with interview
Typical timeline
3y 0m
Avg Prosecution
25 currently pending
Career history
921
Total Applications
across all art units

Statute-Specific Performance

§101
18.1%
-21.9% vs TC avg
§103
63.8%
+23.8% vs TC avg
§102
4.1%
-35.9% vs TC avg
§112
8.1%
-31.9% vs TC avg
Black line = Tech Center average estimate • Based on career data from 889 resolved cases

Office Action

§103
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 . Claims 1-9, 11-20 are presented for the examination. 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, 15 are rejected under 35 U.S.C. 103 as being unpatentable over Walker(US 20170180341 A1 ) in view of Netsch(US 20210271777 A1) and further in view of Ren( US 20230266957 A1). As to claim 1, Walker teaches A computer-implemented method, comprising: receiving a request to migrate sensitive data from a first volume in a first trusted execution environment (TEE) to a second volume in a second TEE( sophisticated hardware-based security tools such as hardware based random number generators, trusted execution environments, para[0024], ln 6-9/ For example, attestation device 105 may contain a hardware root of trust[trust environment] that is implemented using asymmetric cryptography in trusted execution environment and further include a corresponding asymmetric key signed by a certificate authority (CA), at manufacturing time. By leveraging the trust of this CA, a secure connection may be established between a trusted management system 120 and attestation device 105 in order to provision initial shared secrets, para[0036], ln 20-35/ Fig. 2/ other management system (e.g., 120a-b). User computing devices, as well as other computing systems can interface with management systems (e.g., 120a-b)[trusted environment] , para[0018], ln 5-10/ a management system 120 interacting with attestation devices 105 equipped with sensors 230 and generating log data 245 from the sensor readings can additionally include a log manager 285 and store log data 295 received from the attestation device via a gateway device 110, para[0031], ln 1-6/ Gateway devices (e.g., 110a-b) [trusted environment] can be provided that are capable of communicating with the devices 105a-c, para[0015]/ a trusted gateway device[trusted] (e.g., 110) can be employed during an initialization or configuration of an attestation device (e.g., 105) to allow the management system 120 to provision secret data (e.g., 240) in memory of the attestation device 105. For instance, the management system 120 can send a request [request]to the trusted gateway device 110 identifying that a particular secret is to be provisioned on the attestation device. The gateway 110 can send a signal[request] (e.g., over near field communication channel 226) indicating that a new secret is to be written. The gateway 110 can further send [migrate]data identifying the secrets to the attestation device 105. In some implementations, the gateway 110 (and/or the management system) can send[migrate] the secret in an encrypted or otherwise secured package from which the attestation device is capable of extracting the new secret(s). Securing the provisioning of secrets in the attestation device 105 can utilize and leverage physical security of the device at the time it is provisioned. Accordingly, provisioning secrets can be limited to secured physical environments. In some implementations, the attestation device 105 can further contain a hardware root of trust and a trusted execution environment, which can allow it to reliably attest remotely to the gateway 110, even outside of a secured physical environment, para[0036]/ The secret can be stored in a first portion of the memory, the memory including a second portion, and the second portion of the memory may be non-volatile memory. The memory may be random access memory, para[0114], ln 1-10/ a trusted gateway device used to provision a secret from the management system to an attestation device can be equipped with logic to destroy the secret from its own memory after transmitting[migrate] it to the attestation device and verify destruction of the secret (e.g., to the management system with which it is paired), para[0044],l n 21-28/ a trusted gateway device (e.g., 110) can be employed during an initialization or configuration of an attestation device (e.g., 105) to allow the management system 120 to provision secret data (e.g., 240) in memory of the attestation device 105. For instance, the management system 120 can send a request[request] to the trusted gateway device 110 identifying that a particular secret is to be provisioned on the attestation device. The gateway 110 can send a signal[request] (e.g., over near field communication channel 226) indicating that a new secret is to be written. The gateway 110 can further send[migrate] data identifying the secrets to the attestation device 105. In some implementations, the gateway 110 (and/or the management system) can send[migrate] the secret in an encrypted or otherwise secured package[container] from which the attestation device is capable of extracting the new secret(s), para[0036], ln 1-20/ The management system 120 can assign[migrate] one or more secrets and cause these secrets to be written in a segment of the attestation device's memory , para[0035], ln 6-9). Netsch teaches request to migrate the sensitive data from a first volume in a first trusted to a second volume in a second trust ( Interestingly, when normal authentication mechanisms are combined with authentication information[trust] provided by container builder 310, para[0091], ln 2-6/ The container builder may also provide authentication[trust] information to an intended user of the individualized network service, such as a private address and/or a token, thereby reducing the risk of unauthorized access to the network service, para[0013], ln 7-12/ In a system such as the one of FIG. 4a, data of multiple users may be stored on cloud server 400, e.g., in databases 401 and/or 402. Encryption and/or other security measures may be used to improve data safety , privacy, and/or to prevent data breaches[trust], exploits , or other attempts to get access to user data, para[0040], ln 1-7/ cloud server 514 may instruct[request] container builder 510 to deploy[migrate] a container, and container builder 510 may be configured to provide[migrate] the container image for deployment[migrate], para extracting the sensitive data from the first volume. Preparing the container image beforehand and customizing the container image based on sensitive data 522, , para[0049], ln 12-17/ The container builder retrieves the sensitive data from the database, builds the container image, and provides it for deployment to the cloud service provider. The container image[sensitive] comprises the sensitive data and instructions that, when deployed as a container, cause the container to provide the individualized network service based on the sensitive data. The cloud service provider receives[migrate] such a container image for deployment and deploys it as a container, para[0009], ln 8-17/ For example, cloud service provider may deploy[migrate] container image 140 at a container host such as container host 112, or on a container[volume] platform operating on cloud service provider 111[trust] itself, para[0059], ln 9-16/ container builder 110 may receive an instruction to build a container image for providing an individualized network service based on sensitive data, para[0060], ln 2-6 / when sensitive information from the database is needed, data interface 120 may be asked for it, after which data interface 120 may retrieve it, e.g., ….. Database 121 may be configured as a private database of the container builder, e.g., a local database. For example, database 121 may be accessible through,….. or database 121[volume] may be a local database running at container builder 110[trust], para[0008], ln 4-7/ the storage may include one or more machine-readable storage media such as read-only memory (ROM), random-access memory (RAM), magnetic disk storage media, optical storage media, flash-memory devices, or similar storage media, para[0104], ln 1-10/ The software may be stored in a suitable storage medium, such as a hard disk, a floppy, a memory, an optical disc, etc., para[0120], ln 5-9/ The container builder retrieves the sensitive data from the database, para[0009], ln 10-14 ); generating migration metadata that outlines the sensitive data; generating a new container image having the migration metadata and the sensitive data packaged ( Container builder 110 may build a container image 140 and provide it to cloud service provider 111 for deployment. Cloud service provider 111 may deploy container image 140, for example, on a container host 112. Interestingly, container image 140 may comprise sensitive data 122 and instructions that, when deployed as a container, cause the container to provide the individualized network service based on sensitive data 122, para[0055], ln 2-10/ container image 140 comprises sensitive data 122. For instance, sensitive data may be included in container image 140 in the form of a local database, e.g., image handling unit 132 may add to container image 140 database software and instructions and/or data to set up the database software with sensitive data 122. For example, the database software may be serverless database software such as sqlite. The included database may be a subdatabase of database 121. For example, image handling unit 132 may set up the included database as a subset of tables, columns, and/or rows of database 121 that are needed to provide the individualized network service, e.g., including sensitive data 122. For instance, the data may comprise credentials 441, user data 442, and/or service data 443 as discussed with reference to FIG. 4b. The software in container image 140, e.g., instructions 141, may be set up such that it connects to the local database, e.g., instead of connecting to remote database 121. This may be transparent to the software in container image 140 accessing the database, e.g., other than adjusting the database connection parameters, no other adaptation of the software may be needed to make it use sensitive data 122 from container image 140 instead of from a remote database. However, this is not necessary, e.g., use of local sensitive data may also be achieved by adapting software of container 140 such that it makes use of, e.g., text files instead of a database or such that sensitive data 122 is hard-coded in the instructions, para[0065], ln 1-30/ container image 140 comprises termination instructions 143. Termination instructions 143 may, when deployed as a contain…….. termination instructions 143 may also comprise instructions to delete certain data from the container, e.g., software modules comprising sensitive software assets or sensitive data that does not need to be kept para[0066], ln 1-3/ line 21-24/ building container image 140 may comprise multiple build steps, preparing the container image comprising a first set of build steps and customizing the container image comprising a second set of build steps, the second set of build steps comprising a step of adding particular user credentials and/or sensitive data to the container image, para[0067], ln 5-14 ), and sending the new container image to second TEE (this arrangement improves security[trust], e.g., because the database may be less exposed; e.g., the cloud service provider and/or a container host at which the container is deployed does not need to access the database directly, para[0010]/ In a system such as the one of FIG. 4a, data of multiple users may be stored on cloud server 400, e.g., in databases 401 and/or 402. Encryption and/or other security measures may be used to improve data safety , privacy, and/or to prevent data breaches[trust], exploits , or other attempts to get access to user data, para[0040], ln 1-7/ Container builder 110 may build a container image 140 and provide[sending] it to cloud service provider 111 for deployment. Cloud service provider 111 may deploy container image 140, for example, on a container host 112. Interestingly, container image 140 may comprise sensitive data 122 and instructions that, when deployed as a container, cause the container to provide the individualized network service based on sensitive data 122, para[0055], ln 2-10). It would have been obvious to one of the ordinary skill in the art before the effective filling date of claimed invention was made to modify the teaching of Walker with Netsch to incorporate the above feature because this provide authentication information to an intended user of the individualized network service, such as a private address and/or a token, thereby reducing the risk of unauthorized access to the network service. Walker teaches sending the new container image to second TEE ( attestation device 105 may contain a hardware root of trust[trust environment] that is implemented using asymmetric cryptography in trusted execution environment[trust environment], para[0036], ln 20-35/ Fig. 2The gateway 110 can further send[migrate] data identifying the secrets to the attestation device 105. In some implementations, the gateway 110 (and/or the management system) can send[migrate] the secret in an encrypted[container] or otherwise secured package[container] from which the attestation device is capable of extracting the new secret(s), para[0036], ln 1-20). Ren teaches sending the new container image to the second TEE( generate new container images without changing the original application code. Users can use specific library operating system tools or commands to rebuild the original application image. However, these available systems still use a new container image built to wrap the library operating system artifacts on top of the original image, leading to at least double amount of the original storage space to store each application. Furthermore, for sensitive applications, the rebuild job should run on a customer's TEE, meaning that customers need to have library operating system artifacts and library dependencies present in the customer environment beforehand, para[0031], ln 16-30/ IG. 6 illustrates a workflow 600 of application container deployment in a TEE according to some embodiments. A customer 602, Cloud Service Provider (CSP) 604, TEE Vendor 606, and LSP 608 (which were defined above as second, third, first, and fourth roles, respectively) perform functions in the workflow 600. A container registry 610 can be provided by the CSP 604 and was also described earlier herein as providing a repository to store and access container images, para[0050]/Fig.6 / customers 602 can publish original application container images into the container registry 61., para[0051], ln 23-27/ Fig. 6/ the Container registry 610 are trust environments to send and receive the container image since customer 602 and container registry 510 are located on the TEE 600 as described above/ Fig. 6 ). It would have been obvious to one of the ordinary skill in the art before the effective filling date of claimed invention was made to modify the teaching of Walker and Netsch with Ren to incorporate the above feature because this provides protection of software services, such as through the use of Trusted Execution Environments (TEEs) and attestation. As to claim 15, it is rejected for the same reason as to claim 1 above. Claim(s) 2, 4, 5, 16, 17 are rejected under 35 U.S.C. 103 as being unpatentable over Walker(US 20170180341 A1 ) in view of Netsch(US 20210271777 A1) in view of Ren( US 20230266957 A1) and further in view RENO(US 20200359451 A1). As to claim 2, Reno teaches the migration metadata includes key-value character strings that identify the sensitive data requested to be migrated( The method includes starting a container image load, the container image including at least a secret sub unit and an application sub unit, the application sub unit providing the AMF, determining an input source to provide a secret value for the container, the input source identified by information in the secret sub unit in the container image, and providing the secret value to a destination sub unit of the container, para[0009], ln 4-12/ a secret sub unit defines a set of secret values that are to be determined. For each secret value a ‘name,’ type,“format,”destination,' and ‘prompt’ are defined. The name of the first secret value is the ‘TLS Key’ and the second secret value name is the ‘DB Password.’ The first secret value type is ‘RSA_Private_Key’ (i.e., a cryptographic key) and the second is clear text. The first secret value type is ‘Base64’ (i.e., an ASCII encoding of the key) and the second is a string. The first and second secret values define a destination where each destination includes a type and name. The first and second secret values also define strings to be presented as prompts where the data obtained is from a user via an administrative input. In other embodiments, other fields can be defined such as input sources like secret stores or algorithms either by reference or explicitly within the secret sub unit, para[0062]). It would have been obvious to one of the ordinary skill in the art before the effective filling date of claimed invention was made to modify the teaching of Walker and Netsch with Ren to incorporate the above feature because this provides need to have secured execution environments to prevent the other users from gaining access to our interfering with their programs. As to claim 4, Reno teaches wherein the migration metadata and the sensitive data are packaged in an individual layer in the new container image( para[0007], ln 11-18/ para[0038]/ para[0039], ln 1-10/ para[0056], ln 3-30/ para[0058]) for the same reason as to claim 2 above. As to claim 5, Reno teaches the migration metadata is an image tag assigned to an uppermost layer of the new container image( para[0007], ln 11-18/ para[0038]/ para[0039], ln 1-10/ para[0056], ln 3-30/ para[0058]) for the same reason as to claim 2 above. As to claims 16, 17, they are rejected for the same reasons as to claims 2, 4 above. Claim(s) 3 is rejected under 35 U.S.C. 103 as being unpatentable over Walker(US 20170180341 A1 ) in view of Netsch(US 20210271777 A1) in view of Ren( US 20230266957 A1) and further in view of Ozzie( US 20090150968 A1). As to claim 3, Walker teaches generating migration metadata that outlines the sensitive data, includes: identifying the sensitive data in the first volume requested to be migrated( para[0036], ln 3-11); Netsch teaches identifying remaining sensitive data in the first volume not requested to be migrated( para[0066], ln 20-25) for the same reason as to claim 1 above. Ozzie teaches determining a difference between (i) the sensitive data in the first volume requested to be migrated, and (ii) the remaining sensitive data in the first volume not requested to be migrated; and using the difference to create the migration metadata( the metadata for each contact in the contact store. These stored clean names are then compared to the clean name for the new contact to determine whether the names are equivalent and to generate a name conflict list. In particular, in step 606, a check is made to determine whether additional clean names to be compared remain in the contact store. If no additional names remain, then the name contact list is complete and the process proceeds, via off-page connectors 616 and 618, to step 620 where processing continues as described below. Alternatively, if additional names remain to be processed as determined in step 606, then the process proceeds to step 608 where the next contact is retrieved from the contact store and, in step 610, the clean name for that contact is compared against the new contact clean name. If there is a match as determined in step 612, then that contact is added to a name conflict list as set forth in step 614. ….. metadata of contacts with clean names that conflict with the new contact clean name will be set. When a name conflict bit for a contact is set, then a name conflict icon will be displayed wherever and whenever the contact display name is displayed in the collaborative system's user interface, para[0066] to para[0069]). It would have been obvious to one of the ordinary skill in the art before the effective filling date of claimed invention was made to modify the teaching of Walker, Netsch and Ren with Ozzie to incorporate the above feature because this allows the collaborative system to be up-to-date in terms of certificate expirations. Claim(s) 6, 7, 18, 19 are rejected under 35 U.S.C. 103 as being unpatentable over Walker(US 20170180341 A1 ) in view of Netsch(US 20210271777 A1) in view of Ren( US 20230266957 A1) and further in view of Zhang( US 20230259462 A1). As to claim 6, Zhang teaches the operations are performed by a migration layer producer module in a container engine at the first TEE( FIG. 1 is a schematic diagram of application program migration. In FIG. 1, an example in which application program migration is performed based on a container is used for description. As shown in FIG. 1, a cloud computing system 10 includes a processing node 11, a processing node 12, and a storage node 13. The processing node 11, the processing node 12, and the storage node 13 may all be servers. An application program A deployed in the processing node 11 is located in a container A of the processing node 11, and the processing node 11 may store, in a storage volume A that corresponds to the application program A and that is in the storage node 13, data A corresponding to the application program A. The application program A may be migrated from the processing node 11 to the processing node 12 in a unit of container (where in other words, the container A in which the application program A is located is migrated from the processing node 11 to the processing node 12). After the application program A is migrated from the processing node 11 to the processing node 12, a mounting node of the storage volume A that corresponds to the application program A and that is in the storage node 13 may be switched from the processing node 11 to the processing node 12. In this way, the processing node 12 may use the data A that corresponds to the application program A, para[0092], ln 1-25/ a trusted operating system is configured in the first processing node , the application program includes a trusted application, the first internal keying material is an internal keying material corresponding to the trusted operating system, and the application internal keying material is an internal keying material corresponding to the trusted application.), para[0011]). It would have been obvious to one of the ordinary skill in the art before the effective filling date of claimed invention was made to modify the teaching of Walker, Netsch and Ren with Zhang to incorporate the above feature because this helps ensure security of the secure storage key and helps improve data management flexibility. As to claim 7, Zhang teaches the container engine includes the migration layer producer module and a migration layer consumer module( para[0092], ln 1-25) for the same reason as to claim 1 above. As to claims 18, 19, they are rejected for the same reasons as to claims 6, 7 above. Claim(s) 8, 20 are rejected under 35 U.S.C. 103 as being unpatentable over Walker(US 20170180341 A1 ) in view of Netsch(US 20210271777 A1) in view of Ren( US 20230266957 A1) in view of Bacher ( US 20200250319 A1) in view of Wu(US 20220075760 A1) and further in view of Suarez( US 20170177877 A1). As to claim 6 , Ren teaches receive a container image from a remote TEE ( generate new container images without changing the original application code. Users can use specific library operating system tools or commands to rebuild the original application image. However, these available systems still use a new container image built to wrap the library operating system artifacts on top of the original image, leading to at least double amount of the original storage space to store each application. Furthermore, for sensitive applications, the rebuild job should run on a customer's TEE, meaning that customers need to have library operating system artifacts an environment beforehand, para[0031], ln 16-30/ IG. 6 illustrates a workflow 600 of application container deployment in a TEE according to some embodiments. A customer 602, Cloud Service Provider (CSP) 604, TEE Vendor 606, and LSP 608 (which were defined above as second, third, first, and fourth roles, respectively) perform functions in the workflow 600. At operation 620, customers 602 can publish original application container images into the container registry 610., para[0050]/ to para[0051], ln 15-20/ Fig.6). Bacher teaches parse migration metadata in an uppermost layer of the container image( storing each encrypted set of the blocks may also comprise storing metadata of the first layered software container image. The metadata may comprise environment variables, commands, ports to be used, etc. The metadata may be encrypted or unencrypted, para[0018], ln 2-7/layer of the encrypted container image is a hash value of content of the file, para[0020], ln 1-3/ the proposed concept may allow running software container workloads in an environment to which normally privileged administrators have access and keep the confidentiality of the content of the software container images secure, para[0015], ln 1-5). It would have been obvious to one of the ordinary skill in the art before the effective filling date of claimed invention was made to modify the teaching of Walker ,Netsch and Ren with Bacher to incorporate the above feature because this provides improve the efficiency of computing systems by storing container images as layers, which allows efficient use of storage Wu teaches extract data from the uppermost layer of the container image, use the second layer of the container image to generate a corresponding container; and insert the extracted data into a read/write layer of the corresponding container( create a dmg layer file, corresponding to a dmg file to include the files of one or more layers of a container image (more generally referred to as a disk image layer file; 2) set a property of the dmg layer file to case-sensitive; para[0022], ln 1-7/ to execute a container, the container runtime is configured to: 1) create a dmg layer file, corresponding to a dmg file to include the files of one or more layers of a container image (more generally referred to as a disk image layer file; 2) set a property of the dmg layer file to case-sensitive; 3) mount the dmg layer file in a directory of the file system; and 4) store files for executing the container in the directory, thereby modifying the dmg layer file to include files for executing the container in the dmg layer file. In particular, to store the files for executing the container in the mounted directory, container runtime pulls a container image corresponding to the container from storage (e.g., downloads) and extracts from the container image a plurality of layers. For the first layer, the container runtime creates a first dmg layer file and mounts the first dmg layer file to the directory in the file system. The container runtime then stores the files for the first layer in the mounted directory. Thus, the first dmg layer file includes the files for the first layer. In certain embodiments, the container runtime then duplicates/creates a copy of the first dmg layer file. For example, the copied first dmg layer file can then later be used to build a different container that includes the same first layer, but different subsequent layers without needing to rebuild the first dmg layer file. The container runtime then mounts (if not already mounted) the first dmg layer file (e.g., the original or the copy) to the directory (e.g., the same or another directory). The container runtime then stores the files for the next layer in the mounted directory. Thus, the first dmg layer file now includes the files for the first layer and the next layer, and may now be referred to as the second dmg layer file (as compared to the copy of the first dmg layer file that includes only the files of the first layer). These steps repeat for each next layer until a complete image is built if there are additional layers. The final dmg layer file is then mounted as the root file system for the container. Since the final dmg layer file is a mounted case-sensitive dmg layer file, it is both case-sensitive and achieves the goal of having all the layer files combined to execute the container), para[0022] / FIG. 3A depicts the structure of a container image in a repository. As shown, a delivery file, such as tar file 352, contains a structure 354 that includes a directory of hash-named directories, an index, and a layout. Each hash-named directory 358a-c contains files, sometimes called image digest files, for a particular layer of the image. Accordingly, an image digest file corresponds to a layer of the container image. The hash-named directories 358a-c permit content-addressable access to the files of the layers, para[0032], ln 1-9/ the dmg_layer_file in the temp_mount_directory is un-mounted from the temp_mount_directory , para[0036], ln 21-25). It would have been obvious to one of the ordinary skill in the art before the effective filling date of claimed invention was made to modify the teaching of Walker ,Netsch, Ren and Bacher with Wu to incorporate the above feature because this provides utilizing a disk image file to store files for executing a container. Suarez teaches set a second layer of the container image as an identification for the container image( manifest specifies which layers are associated with the container image , para[0047], ln 6-10/ FIG. 5 illustrates an example 500 of an embodiment of the present disclosure. Specifically, FIG. 5 depicts a scanning mechanism 550 for scanning container images stored in the repository for data defined by users (e.g., malware, sensitive data, trade secret data, etc.). …. uniquely identifies the computer file or a characteristic (e.g., the malware, virus, trade secret, or other vulnerability) being sought, para[0060], ln 1-21/ The system may also obtain or generate a manifest that contains metadata about the set of container image layers corresponding to the specified container image. Individual container image layers may comprise a set of files of the container image., para[0021], ln 8-14). It would have been obvious to one of the ordinary skill in the art before the effective filling date of claimed invention was made to modify the teaching of Walker ,Netsch, Ren, Bacher and Wu with Suarez to incorporate the above feature because this provides improve the efficiency of computing systems by storing container images as layers, which allows efficient use of storage resources. As to claim 20, it is rejected for the same reason as to claim 20. Claim(s) 9 is rejected under 35 U.S.C. 103 as being unpatentable over in view of Netsch(US 20210271777 A1) in view of Bacher ( US 20200250319 A1) in view of Wu(US 20220075760 A1) and further in view of Suarez( US 20170177877 A1). As to claims 9, Netsch teaches receiving, at a first trusted execution environment (TEE), a container image including migration metadata and sensitive data from a remote trusted execution environment (TEE) second TEE ( Interestingly, when normal authentication mechanisms are combined with authentication information[trust] provided by container builder 310, para[0091], ln 2-6/ The container builder may also provide authentication[trust] information to an intended user of the individualized network service, such as a private address and/or a token, thereby reducing the risk of unauthorized access to the network service, para[0013], ln 7-12/ In a system such as the one of FIG. 4a, data of multiple users may be stored on cloud server 400, e.g., in databases 401 and/or 402. Encryption and/or other security measures may be used to improve data safety , privacy, and/or to prevent data breaches[trust], exploits , or other attempts to get access to user data, para[0040], ln 1-7/ cloud server 514 may instruct[request] container builder 510 to deploy[migrate] a container, and container builder 510 may be configured to provide[migrate] the container image for deployment[migrate], para extracting the sensitive data from the first volume. Preparing the container image beforehand and customizing the container image based on sensitive data 522, , para[0049], ln 12-17/ The container builder retrieves the sensitive data from the database, builds the container image, and provides it for deployment to the cloud service provider. The container image[sensitive] comprises the sensitive data and instructions that, when deployed as a container, cause the container to provide the individualized network service based on the sensitive data. The cloud service provider receives[migrate] such a container image for deployment and deploys it as a container, para[0009], ln 8-17/ For example, cloud service provider may deploy[migrate] container image 140 at a container host such as container host 112, or on a container platform operating on cloud service provider 111[trust] itself, para[0059], ln 9-16/ container builder 110 may receive an instruction to build a container image for providing an individualized network service based on sensitive data, para[0060], ln 2-6 / when sensitive information from the database is needed, data interface 120 may be asked for it, after which data interface 120 may retrieve it, e.g., ….. Database 121 may be configured as a private database of the container builder, e.g., a local database. For example, database 121 may be accessible through,….. or database 121 may be a local database running at container builder 110[trust], para[0008], ln 4-7/ the storage may include one or more machine-readable storage media such as read-only memory (ROM), random-access memory (RAM), magnetic disk storage media, optical storage media, flash-memory devices, or similar storage media, para[0104], ln 1-10/ The software may be stored in a suitable storage medium, such as a hard disk, a floppy, a memory, an optical disc, etc., para[0120], ln 5-9/ The container builder retrieves the sensitive data from the database, para[0009], ln 10-14/ Container builder 110 may build a container image 140 and provide it to cloud service provider 111 for deployment. Cloud service provider 111 may deploy container image 140, for example, on a container host 112. Interestingly, container image 140 may comprise sensitive data 122 and instructions that, when deployed as a container, cause the container to provide the individualized network service based on sensitive data 122, para[0055], ln 2-10/ container image 140 comprises sensitive data 122. For instance, sensitive data may be included in container image 140 in the form of a local database, e.g., image handling unit 132 may add to container image 140 database software and instructions and/or data to set up the database software with sensitive data 122. For example, the database software may be serverless database software such as sqlite. The included database may be a subdatabase of database 121. For example, image handling unit 132 may set up the included database as a subset of tables, columns, and/or rows of database 121 that are needed to provide the individualized network service, e.g., including sensitive data 122. For instance, the data may comprise credentials 441, user data 442, and/or service data 443 as discussed with reference to FIG. 4b. The software in container image 140, e.g., instructions 141, may be set up such that it connects to the local database, e.g., instead of connecting to remote database 121. This may be transparent to the software in container image 140 accessing the database, e.g., other than adjusting the database connection parameters, no other adaptation of the software may be needed to make it use sensitive data 122 from container image 140 instead of from a remote database. However, this is not necessary, e.g., use of local sensitive data may also be achieved by adapting software of container 140 such that it makes use of, e.g., text files instead of a database or such that sensitive data 122 is hard-coded in the instructions, para[0065], ln 1-30/ container image 140 comprises termination instructions 143. Termination instructions 143 may, when deployed as a contain…….. termination instructions 143 may also comprise instructions to delete certain data from the container, e.g., software modules comprising sensitive software assets or sensitive data that does not need to be kept para[0066], ln 1-3/ line 21-24/ building container image 140 may comprise multiple build steps, preparing the container image comprising a first set of build steps and customizing the container image comprising a second set of build steps, the second set of build steps comprising a step of adding particular user credentials and/or sensitive data to the container image, para[0067], ln 5-14 / this arrangement improves security[trust], e.g., because the database may be less exposed; e.g., the cloud service provider and/or a container host at which the container is deployed does not need to access the database directly, para[0010]/ In a system such as the one of FIG. 4a, data of multiple users may be stored on cloud server 400, e.g., in databases 401 and/or 402. Encryption and/or other security measures may be used to improve data safety , privacy, and/or to prevent data breaches[trust], exploits , or other attempts to get access to user data, para[0040], ln 1-7/ Container builder 110 may build a container image 140 and provide[sending] it to cloud service provider 111 for deployment. Cloud service provider 111 may deploy container image 140, for example, on a container host 112. Interestingly, container image 140 may comprise sensitive data 122 and instructions that, when deployed as a container, cause the container to provide the individualized network service based on sensitive data 122, para[0055], ln 2-10). Bacher teaches wherein the migration metadata and the sensitive data are packaged together in an uppermost layer of the container image ( Thus, when n=1, the dmg_layer_file(1) includes the contents of the base layer of the container image. In step 414, the function determines whether or not there are more layers needed to create the container image. If so, then the function increments the layer number n in step 416 and, in step 418, calls Add(n−1, n) to add the dmg_layer_file(n−1) to the content of the next layer n to create the dmg_layer_file(n). In step 420, the function optionally saves the dmg_layer_file(n) to a folder so that it can be used as an intermediate result (possibly for other containers), and it can also be used if another layer needs to be added., para[0035], ln 22-33/ storing each encrypted set of the blocks may also comprise storing metadata of the first layered software container image. The metadata may comprise environment variables, commands, ports to be used, etc. The metadata may be encrypted or unencrypted, para[0018], ln 2-7/layer of the encrypted container image is a hash value of content of the file, para[0020], ln 1-3/ the proposed concept may allow running software container workloads in an environment to which normally privileged administrators have access and keep the confidentiality of the content of the software container images secure, para[0015], ln 1-5). It would have been obvious to one of the ordinary skill in the art before the effective filling date of claimed invention was made to modify the teaching of Walker and Netsch with Ren to incorporate the above feature because this provides improve the efficiency of computing systems by storing container images as layers, which allows efficient use of storage Wu teaches extract data from the uppermost layer of the container image, use the second layer of the container image to generate a corresponding container; and insert the extracted data into a read/write layer of the corresponding container( create a dmg layer file, corresponding to a dmg file to include the files of one or more layers of a container image (more generally referred to as a disk image layer file; 2) set a property of the dmg layer file to case-sensitive; para[0022], ln 1-7/ to execute a container, the container runtime is configured to: 1) create a dmg layer file, corresponding to a dmg file to include the files of one or more layers of a container image (more generally referred to as a disk image layer file; 2) set a property of the dmg layer file to case-sensitive; 3) mount the dmg layer file in a directory of the file system; and 4) store files for executing the container in the directory, thereby modifying the dmg layer file to include files for executing the container in the dmg layer file. In particular, to store the files for executing the container in the mounted directory, container runtime pulls a container image corresponding to the container from storage (e.g., downloads) and extracts from the container image a plurality of layers. For the first layer, the container runtime creates a first dmg layer file and mounts the first dmg layer file to the directory in the file system. The container runtime then stores the files for the first layer in the mounted directory. Thus, the first dmg layer file includes the files for the first layer. In certain embodiments, the container runtime then duplicates/creates a copy of the first dmg layer file. For example, the copied first dmg layer file can then later be used to build a different container that includes the same first layer, but different subsequent layers without needing to rebuild the first dmg layer file. The container runtime then mounts (if not already mounted) the first dmg layer file (e.g., the original or the copy) to the directory (e.g., the same or another directory). The container runtime then stores the files for the next layer in the mounted directory. Thus, the first dmg layer file now includes the files for the first layer and the next layer, and may now be referred to as the second dmg layer file (as compared to the copy of the first dmg layer file that includes only the files of the first layer). These steps repeat for each next layer until a complete image is built if there are additional layers. The final dmg layer file is then mounted as the root file system for the container. Since the final dmg layer file is a mounted case-sensitive dmg layer file, it is both case-sensitive and achieves the goal of having all the layer files combined to execute the container), para[0022] / FIG. 3A depicts the structure of a container image in a repository. As shown, a delivery file, such as tar file 352, contains a structure 354 that includes a directory of hash-named directories, an index, and a layout. Each hash-named directory 358a-c contains files, sometimes called image digest files, for a particular layer of the image. Accordingly, an image digest file corresponds to a layer of the container image. The hash-named directories 358a-c permit content-addressable access to the files of the layers, para[0032], ln 1-9/ the dmg_layer_file in the temp_mount_directory is un-mounted from the temp_mount_directory , para[0036], ln 21-25). It would have been obvious to one of the ordinary skill in the art before the effective filling date of claimed invention was made to modify the teaching of Walker and Netsch with Ren to incorporate the above feature because this provides utilizing a disk image file to store files for executing a container. Suarez teaches set a second layer of the container image as an identification for the container image( manifest specifies which layers are associated with the container image , para[0047], ln 6-10/ FIG. 5 illustrates an example 500 of an embodiment of the present disclosure. Specifically, FIG. 5 depicts a scanning mechanism 550 for scanning container images stored in the repository for data defined by users (e.g., malware, sensitive data, trade secret data, etc.). …. uniquely identifies the computer file or a characteristic (e.g., the malware, virus, trade secret, or other vulnerability) being sought, para[0060], ln 1-21/ The system may also obtain or generate a manifest that contains metadata about the set of container image layers corresponding to the specified container image. Individual container image layers may comprise a set of files of the container image., para[0021], ln 8-14). It would have been obvious to one of the ordinary skill in the art before the effective filling date of claimed invention was made to modify the teaching of Walker, Netsch and Ren with Suarez to incorporate the above feature because this provides improve the efficiency of computing systems by storing container images as layers, which allows efficient use of storage resources. Claim(s) 11, 12 are rejected under 35 U.S.C. 103 as being unpatentable over in view of Ren( US 20230266957 A1) in view of Bacher ( US 20200250319 A1) in view of Wu(US 20220075760 A1) in view of Suarez( US 20170177877 A1) and further in view of Zhang( US 20230259462 A1). As to claim 11 , Zhang teaches wherein the operations are performed by a migration layer consumer module in a container engine( FIG. 1 is a schematic diagram of application program migration. In FIG. 1, an example in which application program migration is performed based on a container is used for description. As shown in FIG. 1, a cloud computing system 10 includes a processing node 11, a processing node 12, and a storage node 13. The processing node 11, the processing node 12, and the storage node 13 may all be servers. An application program A deployed in the processing node 11 is located in a container A of the processing node 11, and the processing node 11 may store, in a storage volume A that corresponds to the application program A and that is in the storage node 13, data A corresponding to the application program A. The application program A may be migrated from the processing node 11 to the processing node 12 in a unit of container (where in other words, the container A in which the application program A is located is migrated from the processing node 11 to the processing node 12). After the application program A is migrated from the processing node 11 to the processing node 12, a mounting node of the storage volume A that corresponds to the application program A and that is in the storage node 13 may be switched from the processing node 11 to the processing node 12. In this way, the processing node 12 may use the data A that corresponds to the application program A, para[0092], ln 1-25 ). It would have been obvious to one of the ordinary skill in the art before the effective filling date of claimed invention was made to modify the teaching of Walker, Netsch, Ren and Suarez with Zhang to incorporate the above feature because this This helps ensure security of the secure storage key and helps improve data management flexibility. As to claim 12, Zhang teaches the container engine includes the migration layer consumer module and a migration layer producer module( para[0092], ln 1-25) for the same reason as to claim 1 above. . Claim(s) 13, 14 are rejected under 35 U.S.C. 103 as being unpatentable over Ren( US 20230266957 A1) in view of Bacher ( US 20200250319 A1) in view of Wu(US 20220075760 A1) in view of Suarez( US 20170177877 A1) and further in view of RENO(US 20200359451 A1). As to claim 13, Reno teaches the migration metadata includes key-value character strings that identify the sensitive data ( The method includes starting a container image load, the container image including at least a secret sub unit and an application sub unit, the application sub unit providing the AMF, determining an input source to provide a secret value for the container, the input source identified by information in the secret sub unit in the container image, and providing the secret value to a destination sub unit of the container, para[0009], ln 4-12/ a secret sub unit defines a set of secret values that are to be determined. For each secret value a ‘name,’ type,“format,”destination,' and ‘prompt’ are defined. The name of the first secret value is the ‘TLS Key’ and the second secret value name is the ‘DB Password.’ The first secret value type is ‘RSA_Private_Key’ (i.e., a cryptographic key) and the second is clear text. The first secret value type is ‘Base64’ (i.e., an ASCII encoding of the key) and the second is a string. The first and second secret values define a destination where each destination includes a type and name. The first and second secret values also define strings to be presented as prompts where the data to be obtained is from a user via an administrative input. In other embodiments, other fields can be defined such as input sources like secret stores or algorithms either by reference or explicitly within the secret sub unit, para[0062]). It would have been obvious to one of the ordinary skill in the art before the effective filling date of claimed invention was made to modify the teaching of Walker, Netsch, Ren and Suarez with Reno to incorporate the above feature because this provides need to have secured execution environments to prevent the other users from gaining access to our interfering with their programs. As to claim 14 , Reno teaches the migration metadata is an image tag assigned to an uppermost layer of the new container image( para[0007], ln 11-18/ para[0038]/ para[0039], ln 1-10/ para[0056], ln 3-30/ para[0058]) for the same reason as to claim 2 above. Response to the argument: A. Applicant amendment filed on 9/03/04 has been considered but they are not persuasive: Applicant argued in substance that : (1) “ Current Office Action fail to disclose the limitations "receiving a request to migrate sensitive data from a first volume in a first trusted execution environment (TEE) to a second volume in a second TEE." In other words, Walker fails to disclose migrating sensitive data between TEEs.”. B. Examiner respectfully disagreed with Applicant's remarks: As to the point (1), Walker teaches A computer-implemented method, comprising: receiving a request to migrate sensitive data from a first volume in a first trusted execution environment (TEE) to a second volume in a second TEE( sophisticated hardware-based security tools such as hardware based random number generators, trusted execution environments, para[0024], ln 6-9/ For example, attestation device 105 may contain a hardware root of trust[trust environment] that is implemented using asymmetric cryptography in trusted execution environment and further include a corresponding asymmetric key signed by a certificate authority (CA), at manufacturing time. By leveraging the trust of this CA, a secure connection may be established between a trusted management system 120 and attestation device 105 in order to provision initial shared secrets, para[0036], ln 20-35/ Fig. 2/ other management system (e.g., 120a-b). User computing devices, as well as other computing systems can interface with management systems (e.g., 120a-b)[trusted environment] , para[0018], ln 5-10/ a management system 120 interacting with attestation devices 105 equipped with sensors 230 and generating log data 245 from the sensor readings can additionally include a log manager 285 and store log data 295 received from the attestation device via a gateway device 110, para[0031], ln 1-6/ Gateway devices (e.g., 110a-b) [trusted environment] can be provided that are capable of communicating with the devices 105a-c, para[0015]/ a trusted gateway device[trusted] (e.g., 110) can be employed during an initialization or configuration of an attestation device (e.g., 105) to allow the management system 120 to provision secret data (e.g., 240) in memory of the attestation device 105. For instance, the management system 120 can send a request [request]to the trusted gateway device 110 identifying that a particular secret is to be provisioned on the attestation device. The gateway 110 can send a signal[request] (e.g., over near field communication channel 226) indicating that a new secret is to be written. The gateway 110 can further send [migrate]data identifying the secrets to the attestation device 105. In some implementations, the gateway 110 (and/or the management system) can send[migrate] the secret in an encrypted or otherwise secured package from which the attestation device is capable of extracting the new secret(s). Securing the provisioning of secrets in the attestation device 105 can utilize and leverage physical security of the device at the time it is provisioned. Accordingly, provisioning secrets can be limited to secured physical environments. In some implementations, the attestation device 105 can further contain a hardware root of trust and a trusted execution environment, which can allow it to reliably attest remotely to the gateway 110, even outside of a secured physical environment, para[0036]/ The secret can be stored in a first portion of the memory, the memory including a second portion, and the second portion of the memory may be non-volatile memory. The memory may be random access memory, para[0114], ln 1-10/ a trusted gateway device used to provision a secret from the management system to an attestation device can be equipped with logic to destroy the secret from its own memory after transmitting[migrate] it to the attestation device and verify destruction of the secret (e.g., to the management system with which it is paired), para[0044],l n 21-28/ a trusted gateway device (e.g., 110) can be employed during an initialization or configuration of an attestation device (e.g., 105) to allow the management system 120 to provision secret data (e.g., 240) in memory of the attestation device 105. For instance, the management system 120 can send a request[request] to the trusted gateway device 110 identifying that a particular secret is to be provisioned on the attestation device. The gateway 110 can send a signal[request] (e.g., over near field communication channel 226) indicating that a new secret is to be written. The gateway 110 can further send[migrate] data identifying the secrets to the attestation device 105. In some implementations, the gateway 110 (and/or the management system) can send[migrate] the secret in an encrypted or otherwise secured package[container] from which the attestation device is capable of extracting the new secret(s), para[0036], ln 1-20/ The management system 120 can assign[migrate] one or more secrets and cause these secrets to be written in a segment of the attestation device's memory , para[0035], ln 6-9). Netsch teaches request to migrate the sensitive data from a first volume in a first trusted to a second volume in a second trust ( Interestingly, when normal authentication mechanisms are combined with authentication information[trust] provided by container builder 310, para[0091], ln 2-6/ The container builder may also provide authentication[trust] information to an intended user of the individualized network service, such as a private address and/or a token, thereby reducing the risk of unauthorized access to the network service, para[0013], ln 7-12/ In a system such as the one of FIG. 4a, data of multiple users may be stored on cloud server 400, e.g., in databases 401 and/or 402. Encryption and/or other security measures may be used to improve data safety , privacy, and/or to prevent data breaches[trust], exploits , or other attempts to get access to user data, para[0040], ln 1-7/ cloud server 514 may instruct[request] container builder 510 to deploy[migrate] a container, and container builder 510 may be configured to provide[migrate] the container image for deployment[migrate], para extracting the sensitive data from the first volume. Preparing the container image beforehand and customizing the container image based on sensitive data 522, , para[0049], ln 12-17/ The container builder retrieves the sensitive data from the database, builds the container image, and provides it for deployment to the cloud service provider. The container image[sensitive] comprises the sensitive data and instructions that, when deployed as a container, cause the container to provide the individualized network service based on the sensitive data. The cloud service provider receives[migrate] such a container image for deployment and deploys it as a container, para[0009], ln 8-17/ For example, cloud service provider may deploy[migrate] container image 140 at a container host such as container host 112, or on a container[volume] platform operating on cloud service provider 111[trust] itself, para[0059], ln 9-16/ container builder 110 may receive an instruction to build a container image for providing an individualized network service based on sensitive data, para[0060], ln 2-6 / when sensitive information from the database is needed, data interface 120 may be asked for it, after which data interface 120 may retrieve it, e.g., ….. Database 121 may be configured as a private database of the container builder, e.g., a local database. For example, database 121 may be accessible through,….. or database 121[volume] may be a local database running at container builder 110[trust], para[0008], ln 4-7/ the storage may include one or more machine-readable storage media such as read-only memory (ROM), random-access memory (RAM), magnetic disk storage media, optical storage media, flash-memory devices, or similar storage media, para[0104], ln 1-10/ The software may be stored in a suitable storage medium, such as a hard disk, a floppy, a memory, an optical disc, etc., para[0120], ln 5-9/ The container builder retrieves the sensitive data from the database, para[0009], ln 10-14 /Container builder 110 may build a container image 140 and provide it to cloud service provider 111 for deployment. Cloud service provider 111 may deploy container image 140, for example, on a container host 112. Interestingly, container image 140 may comprise sensitive data 122 and instructions that, when deployed as a container, cause the container to provide the individualized network service based on sensitive data 122, para[0055], ln 2-10/ container image 140 comprises sensitive data 122. For instance, sensitive data may be included in container image 140 in the form of a local database, e.g., image handling unit 132 may add to container image 140 database software and instructions and/or data to set up the database software with sensitive data 122. For example, the database software may be serverless database software such as sqlite. The included database may be a subdatabase of database 121. For example, image handling unit 132 may set up the included database as a subset of tables, columns, and/or rows of database 121 that are needed to provide the individualized network service, e.g., including sensitive data 122. For instance, the data may comprise credentials 441, user data 442, and/or service data 443 as discussed with reference to FIG. 4b. The software in container image 140, e.g., instructions 141, may be set up such that it connects to the local database, e.g., instead of connecting to remote database 121. This may be transparent to the software in container image 140 accessing the database, e.g., other than adjusting the database connection parameters, no other adaptation of the software may be needed to make it use sensitive data 122 from container image 140 instead of from a remote database. However, this is not necessary, e.g., use of local sensitive data may also be achieved by adapting software of container 140 such that it makes use of, e.g., text files instead of a database or such that sensitive data 122 is hard-coded in the instructions, para[0065], ln 1-30/ container image 140 comprises termination instructions 143. Termination instructions 143 may, when deployed as a contain…….. termination instructions 143 may also comprise instructions to delete certain data from the container, e.g., software modules comprising sensitive software assets or sensitive data that does not need to be kept para[0066], ln 1-3/ line 21-24/ building container image 140 may comprise multiple build steps, preparing the container image comprising a first set of build steps and customizing the container image comprising a second set of build steps, the second set of build steps comprising a step of adding particular user credentials and/or sensitive data to the container image, para[0067], ln 5-14 /this arrangement improves security[trust], e.g., because the database may be less exposed; e.g., the cloud service provider and/or a container host at which the container is deployed does not need to access the database directly, para[0010]/ In a system such as the one of FIG. 4a, data of multiple users may be stored on cloud server 400, e.g., in databases 401 and/or 402. Encryption and/or other security measures may be used to improve data safety , privacy, and/or to prevent data breaches[trust], exploits , or other attempts to get access to user data, para[0040], ln 1-7/ Container builder 110 may build a container image 140 and provide[sending] it to cloud service provider 111 for deployment. Cloud service provider 111 may deploy container image 140, for example, on a container host 112. Interestingly, container image 140 may comprise sensitive data 122 and instructions that, when deployed as a container, cause the container to provide the individualized network service based on sensitive data 122, para[0055], ln 2-10). In additional, Ren teaches sending the new container image from first TEE to the second TEE( generate new container images without changing the original application code. Users can use specific library operating system tools or commands to rebuild the original application image. However, these available systems still use a new container image built to wrap the library operating system artifacts on top of the original image, leading to at least double amount of the original storage space to store each application. Furthermore, for sensitive applications, the rebuild job should run on a customer's TEE, meaning that customers need to have library operating system artifacts and library dependencies present in the customer environment beforehand, para[0031], ln 16-30/ IG. 6 illustrates a workflow 600 of application container deployment in a TEE according to some embodiments. A customer 602, Cloud Service Provider (CSP) 604, TEE Vendor 606, and LSP 608 (which were defined above as second, third, first, and fourth roles, respectively) perform functions in the workflow 600. A container registry 610 can be provided by the CSP 604 and was also described earlier herein as providing a repository to store and access container images, para[0050]/ Fig.6 / customers 602 can publish original application container images into the container registry 610., para[0051], ln 23-27/ Fig. 6/ customers 602 and the Container registry 610 are trust environments to receive the container image since customer 602 and container registry 510 are 2located on the TEE 600 as described above/ Fig. 6 ). THIS ACTION IS MADE FINAL. 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. Conclusion US 20170180341 A1 teaches restarting the apparatus causes the secret to be lost, logic executable by the at least one processor device to generate attestation data using the secret that data abstracts the secret, and a communications interface to send the attestation data to another device. US 20210271777 A1 teaches building container images that may comprise multiple build steps, preparing the container image comprising a first set of build steps and customizing the container image comprising a second set of build steps, the second set of build steps comprising a step of adding particular user credentials. US 20200320189 A1 teaches In an implementation, before S410 is performed, the first computer may determine the index information of the security policy, embed the index information of the security policy into the original container image, to obtain the container image. US 20180124055 teaches The container image generator receives a first set of information. The container image generator receives a second set of information, including secure information that requires validation to be accessed. US 20110314561 A1 teaches The method includes generating a context container for storing data objects transferred to the server during a session with a client, creating, from the data objects in the context container. US 20220114249 A1 teaches executing a machine learning (ML) application in a computing environment includes receiving a secret from a trusted execution environment ( TEE) of a user computing device into a TEE of a server. The user computing device is authenticated by an identity and access management service. The TEE validates the secret against a time-limited token. US 20170300697 A1 teaches container images , the method further comprising: receiving, at the container registry, the image of the container, wherein the image as received includes an associated security prerequisite file that includes the set of security criteria. US 20180285210 A1 teaches the container generator 306 can create one or more instances of the container 312 at one or more client computing devices 102. The instances of the container 312 may be instantiated are created based at least in part on a container image created by the image generator 304. Alternatively, or in addition, the container 312 US 20200110830 A1 teaches A container image storage system executing on one or more processor devices receives a container image comprising a plurality of objects. US 20180124055 A1 teaches container image generator receives a first set of information. The container image generator receives a second set of information, including secure information that requires validation to be accessed. The container image generator generates a first container layer, including a first URL associated with the first set of information. Any inquiry concerning this communication or earlier communications from the examiner should be directed to LECHI TRUONG whose telephone number is (571)272-3767. The examiner can normally be reached 10-8 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 Young Kevin can be reached on (571)270-3180. 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. /LECHI TRUONG/Primary Examiner, Art Unit 2194
Read full office action

Prosecution Timeline

Dec 05, 2023
Application Filed
Apr 13, 2026
Non-Final Rejection mailed — §103
Jul 07, 2026
Response Filed
Sep 21, 2026
Final Rejection mailed — §103 (current)

Precedent Cases

Applications granted by this same examiner with similar technology

Patent 12743300
DOUBLE-FLASH SWITCHING DEVICE AND SERVER
2y 9m to grant Granted Sep 22, 2026
Patent 12724638
MANAGEMENT APPARATUS, MANAGEMENT METHOD AND MANAGEMENT PROGRAM
2y 10m to grant Granted Sep 01, 2026
Patent 12717621
TRANSPARENTLY EXECUTING ACTIONS WITHIN A CONTAINERIZED CLOUD ENVIRONMENT
3y 8m to grant Granted Aug 25, 2026
Patent 12705088
Task Repacking
4y 5m to grant Granted Aug 11, 2026
Patent 12675339
WORKLOAD MEASURES BASED ON ACCESS LOCALITY
4y 2m to grant Granted Jul 07, 2026
Study what changed to get past this examiner. Based on 5 most recent grants.

Strategy Recommendation AI-generated — please review before filing

Get a prosecution strategy drawn from examiner precedents, rejection analysis, and claim mapping.
Typically takes 5-10 seconds — AI-generated, attorney review required before filing

Prosecution Projections

3-4
Expected OA Rounds
87%
Grant Probability
99%
With Interview (+36.4%)
3y 0m (~2m remaining)
Median Time to Grant
Moderate
PTA Risk
Based on 889 resolved cases by this examiner. Grant probability derived from career allowance rate.

Sign in with your work email

Enter your email to receive a magic link. No password needed.

Personal email addresses (Gmail, Yahoo, etc.) are not accepted.

Free tier: 3 strategy analyses per month